Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-ii

Actas de las XXII Jornadas de ParalelismoLa Laguna, Tenerife, EspañaEditoresFrancisco AlmeidaVicente BlancoCoromoto LeónCasiano RodríguezFrancisco de Sande7–9 Septiembre 2011

Actas de las XXII Jornadas de Paralelismo JP2011Editores: Francisco Almeida, Vicente Blanco, Coromoto León,Casiano Rodríguez y Francisco de SandeISBN: 978-84-694-1791-1Servicio de Publicaciones. Universidad de La Laguna, Tenerife, 2011Edición: 1 aImpresión: 1 aN o de páginas: 744Formato: 17 x 24Materia CDU: 004 Ciencia y tecnología de los ordenadores. InformáticaReservados los derechos para todos los países de lengua española. De conformidad con lo dispuesto en elartículo 270 y siguientes del código penal vigente, podrán ser castigados con penas de multa y privaci6n delibertad quienes reprodujeren o plagiaren, en todo o en parte, una obra literaria, artística o científica fijadaen cualquier tipo de soporte sin la preceptiva autorización. Ninguna parte de esta publicación, incluido eldiseño de la cubierta, puede ser reproducida, almacenada o trasmitida de ninguna forma, ni por ningún medio,sea éste electrónico, químico, mecánico, e1ectro–óptico, i grabación, fotocopia o cualquier otro, sin la previaautorización escrita por parte de la editorial.Diríjase a CEDRO (Centro Español de Derechos Reprográficos), www.cedro.org, si necesita fotocopiaro escanear algún fragmento de esta obra.COPYRIGHT c○2011 UNIVERSIDAD DE LA LAGUNA.svpubl@ull.esActas de las XXII Jornadas de ParalelismoDerechos reservados c○2011 respecto a la primera edición en español, por LOS AUTORESDerechos reservados c○2011 respecto a la primera edición en español, por UNIVERSIDAD DE LALAGUNA1 a Edición, 1 a ImpresiónISBN: 978-84-694-1791-1Depósito Legal: TF-723-2011http://jp2011.pcg.ull.esCréditos:Diseño de Portada: Jose A. de Luis jobues@yahoo.esMaquetación LATEX: LOS EDITOREScon la clase LATEX‘confproc’ (por V. Verfaille)Impreso en La Laguna — Septiembre 2011

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ComitésCoordinaciónRamón Beivide Palacios (UC)Jesús Carretero Pérez (UCIIIM)José Duato Marín (UPV)Inmaculada García Fernández (UAL)Antonio Garrido Del Solo (UCLM)Emilio López Zapata (UMA)Emilio Luque Fadón (UAB)Pedro de Miguel Anasagasti (UPM)Alberto Prieto Espinosa (UGR)Francisco José Quiles Flor (UCLM)Ana Ripoll Aracil (UAB)Francisco Tirado Fernández (UCM)Mateo Valero Cortés (UPC)Victor Viñals Yúferas (UZ)Comité Organizador (ULL)Alejandro Acosta DíazFrancisco Almeida RodríguezJésica de Armas AdriánVicente Blanco PérezJuan Carlos Castillo CanoLuis Cerrudo ConcepciónAntonio Javier Dorta LorenzoJuan José Fumero AlfonsoCarlos González VilaCoromoto León HernándezIván López RodríguezGara Miranda ValladaresCarlos Alberto Morales DíazRuymán Reyes CastroCasiano Rodríguez LeónElena Sánchez NielsenFrancisco de Sande GonzálezAdrián Santos MarreroEduardo Segredo GonzálezCarlos Segura GonzálezJP2011-iii

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-iv

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011PresentaciónEs un placer para nosotros y un verdadero honor darles la bienvenida a la vigésimo segunda ediciónde las Jornadas de Paralelismo que se celebran por primera vez en Canarias los días 7, 8 y 9 deseptiembre de 2011 en La Laguna. Este evento, con más de dos décadas de tradición, supone elencuentro de numerosos investigadores para intercambiar experiencias que reflejan su trabajo enel ámbito de la computación de altas prestaciones. Por primera vez las Jornadas de Paralelismo secelebran de forma conjunta con las Jornadas de Computación Reconfigurable y Aplicaciones, JCRA.El creciente interés de la comunidad investigadora por todo lo relacionado con el paralelismo y lacomputación de altas prestaciones se ve claramente reflejado en la variedad, calidad y número de trabajospresentes en esta edición de las Jornadas. Este año se han recibido un total de 117 trabajos cuyapresentación se ha organizado en un programa que incluye 24 sesiones de ponencias. Por otra parte,el número de inscritos en las Jornadas asciende a 158 participantes, lo que muestra una vez más, tantoel elevado grado de aceptación del evento como el nivel de consolidación del mismo. Es de destacarque el abanico de tópicos tratado en las jornadas ha ido creciendo con los años y se ha adaptado a lainvestigación que se realiza en nuestro país. El programa cubre una amplia variedad de tópicos queincluyen la supercomputación; las arquitecturas del procesador, multiprocesadores y chips multinúcleo;las redes y sistemas de comunicaciones; los algoritmos y técnicas de programación paralelas;las Tecnologías grid, cluster, cloud computing y plataformas distribuidas; la arquitecturas del subsistemade memoria y almacenamiento secundario; la evaluación de prestaciones; la compilación parasistemas de altas prestaciones; las aplicaciones de la computación de altas prestaciones y la docenciaen arquitectura, tecnología de computadores y programación paralela.Contamos en esta edición con dos conferencias que abordarán temas de investigación de gran actualidady que esperamos que sean de su interés. Por una parte, el profesor de la Universitat Politècnicade Catalunya, D. Antonio González, director del centro Intel-UPC impartirá la conferencia tituladaLess energy is more performance. Asimismo, el profesor D. Marco Danelutto de la Università diPisa, director de Institute of Programming Models de esta universidad y miembro de la red Core-GRID impartirá la charla The multi/many core challenge: a pattern based programming perspective.El programa de las Jornadas incluye también dos mesas redondas con ponentes de gran relevancia.En la primera mesa redonda se debatirá sobre La ley de la ciencia y en la segunda sobre La ProgramaciónParalela en los títulos de Grado y Máster temas ambos que esperamos resulten del máximointerés para los participantes en las Jornadas. Tendremos asimismo oportunidad de asistir en elmarco de las Jornadas a la asamblea de la Sociedad de Arquitectura y Tecnología de Computadores(SARTECO).No queremos acabar esta presentación sin mostrar nuestro agradecimiento a todos los organimos yentidades, públicos y privados, que han colaborado en el desarrollo de estas Jornadas, en concreto,a la Universidad de La Laguna, al Ayuntamiento de San Cristobal de La Laguna, al Cabildo deTenerife, a la Agencia Canaria de Investigación, Innovación y Sociedad de la Información, al Departamentode EIO y Computación, a la Escuela Técnica Superior de Ingeniería Informática de la ULL,a la Facultad de Matemáticas de la ULL, a las empresas Bull e IBM, y por último a los miembrosde los grupos de Computación de Altas Prestaciones y Algoritmos y Lenguajes Paralelos de la ULL,que han prestado su apoyo para la organización de este congreso.Bienvenidos a La Laguna y muchas gracias por su interés y participación en estas XXII Jornadas deParalelismo, que esperamos cumplan con sus expectativas.Comité Organizador de las XXII Jornadas de ParalelismoLa Laguna, 7-9 de septiembre de 2011JP2011-v

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-vi

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Índice de las Actas JP2011Algoritmos y técnicas de programación paralelas3 Una Versión Paralela de la Evolución Diferencial para Predecir Motifs en Cadenas de ADNDavid L. González-Álvarez, Miguel A. Vega-Rodríguez, Juan A. Gómez-Pulido, Juan M. Sánchez-Pérez9 Comparación de Algoritmos Evolutivos Paralelos y Secuenciales para el Alineamiento Múltiple de SecuenciasFernando José Mateus Silva, Juan Manuel Sánchez-Pérez, Juan A. Gómez-Pulido, Miguel A. Vega-Rodríguez15 Evolución Diferencial OpenMP+MPI en Redes Ópticas WDMÁlvaro Rubio-Largo, Miguel A. Vega-Rodríguez, Juan A. Gómez-Pulido, Juan M. Sánchez-Pérez21 Paralelización del algoritmo de bi-mezclaJ.F.R. Herrera, L.G. Casado, I. García, Eligius M.T. Hendrix27 Optimización del Método BST para la Reducción de Modelos en Arquitecturas MultinúcleoPablo Ezzatti, Enrique S. Quintana-Ortí, Alfredo Remón33 Genetic Algorithm to Predict Wavelet Coefficients SignRicardo García, Otoniel López, Pablo Piñol, Miguel Martínez, Manuel P. Malumbres, Antonio Martí39 Resolución del Empaquetado 2D Multiobjetivizado con un Algoritmo Memético ParaleloCoromoto León, Carlos Segura, Eduardo Segredo45 Diseño de Filtros con Técnicas Evolutivas para la Clasificación de Señales de EncefalogramaCoromoto León, Yanira González, Carlos Segura51 Ranking de listas enlazadas en procesadores multicoreHugo Vegas, Thierry Gautier, Carlos García, Manuel Prieto57 Parallelizing Biblio-MetReS, a data mining toolOussama Abdelli, Anabel Usié, Hiren Karathia, Jordi Vilaplana, Francesc Solsona, Rui Alves63 Paralelización de una Plataforma para la Resolución de Problemas NP-completos Mediante Algoritmos EvolutivosJosé M. Lanza-Gutiérrez, Juan A. Gómez-Pulido, Miguel A. Vega-Rodríguez, Juan M. Sánchez-Pérez69 Comparando Modelos Paralelos Basados en Islas para el Problema del Posicionamiento de Antenas MultiobjetivizadoCoromoto León, Eduardo Segredo, Carlos Segura75 Exhaustive Program’s Robustness Analysis against Transient FaultsJoao Gramacho, Dolores Rexachs, Emilio Luque81 Biblioteca de Altas Prestaciones para la Resolución de Problemas Matriciales EstructuradosPedro Alonso-Jordá, Pablo Martínez-Naredo, F.J. Martínez-Zaldívar, José Ranilla, Antonio M. Vidal87 A translator framework for Dynamic Programming problemsAlejandro Acosta, Francisco Almeida, Ignacio PeláezAplicaciones de la computación de altas prestaciones95 Resolviendo el Diseño de Redes para Modelos de Tráfico Reales de Internet Mediante Optimización Multiobjetivoen MultiprocesadoresJosé M. Lanza-Gutiérrez, Juan A. Gómez-Pulido, Miguel A. Vega-Rodríguez, Juan M. Sánchez-Pérez101 A New Tool for Classification of Satellite Images Available from Google Maps: Efficient Implementation inGraphics Processing UnitsS. Bernabé, A. Plaza107 Visibility Map Computation at all Points of a TerrainS. Tabik, L.F. Romero, E.L. Zapata113 Un método de acceso aproximado para alta dimensionalidad y su paralalelizaciónF. Artigas119 Perceptually enhanced INTRA video encoder for high definition/quality servicesM. Martínez-Rach, O. López, Pablo Piñol, Manuel P. Malumbres, J. Oliver125 Equipo paralelo de metaheurísticas para la resolución de un problema real de telecomunicacionesJosé M. Chaves-González, Miguel A. Vega-Rodríguez, Juan A. Gómez-Pulido, Juan M. Sánchez-PérezJP2011-vii

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011131 Determination of traffic control tables by HPCEligius M.T. Hendrix, Siham Tabik, Rene Haijema135 Evaluación del método del Gradiente Biconjugado para matrices dispersas en GPUsG. Ortega, E. M. Garzón, F. Vázquez, I. García141 Paralelización del cálculo de coeficientes del Método de Elementos de Contorno en la resolución de problemasde contacto termoelástico 3DRaquel González, Lidia Sánchez, José Vallepuga147 Iterative procedure to solve thermoelastic contact problems between 3D solids using BEM and OOPA. Suárez, Raquel González, Lidia Sánchez, José Vallepuga153 Evaluación de la Paralelización de un Modelo Hidrodinámico 3DMario C. Acosta, Mancia Anguita, Francisco J. Rueda, F. Javier Fernández-Baldomero159 Paralelización del Análisis de Imágenes con Tensor de Difusión en Resonancia Magnética usando GPUsMoisés Hernández, Ginés D. Guerrero, José M. Cecilia, José M. García, Alberto Inuggi165 Agent-Based Simulation to Optimize Healthcare Emergency DepartmentsEduardo Cabrera, Manel Taboada, Emilio Luque171 Reducción de ruido impulsivo Fijo y Uniforme en imágenes digitales usando las GPUs.M. Guadalupe Sánchez, Vicente Vidal, Jordi Bataller, Alejandro Rivera177 Estrategias de Paralelización de Algoritmos de Razonamiento para Ontologías BiomédicasEduardo J. Cepas, Ginés D. Guerrero, José M. Cecilia, José M. García, Jesualdo FernándezArquitecturas del procesador, multiprocesadores y chips multinúcleo185 Real-Time Task Migration with Dynamic Partitioning to Reduce Power ConsumptionJosé Luis March, Julio Sahuquillo, Salvador Petit, Houcine Hassan, José Duato191 Unified Locality-sensitive Signatures for Transactional MemoryR. Quislant, E. Gutiérrez, O. Plata, E.L. Zapata197 Overriding the Coherence Protocol to Improve Directory CachesB. Cuesta, A. Ros, M.E. Gómez, A. Robles, José Duato203 Overcoming the Scalability Constraints of Coherence Protocols of Commodity SystemsA. Ros, B. Cuesta, Ricardo Fernández-Pascual, M.E. Gómez, Manuel E. Acacio, A. Robles, J. M. García, JoséDuato209 Efficient hardware support for lock synchronization in Many-core CMPsJosé L. Abellán, Juan Fernández, Manuel E. Acacio215 A Cooperative and Scalable Built-In Self-Test Architecture for NoCsC. Gómez, A. Strano, D. Ludovici, M. Favalli, M.E. Gómez, D. Bertozzi, P. López, José Duato221 Modular Distributed Switch: Spreading the Switch along the LinkA. Roca, C. Hernández, José Flich, F. Silla, J. Duato227 Reducing the Energy Consumption of Hardware Prefetching in Many-Core CMPs using Reply PartitioningA. Flores, Manuel E. Acacio, Juan L. Aragón233 Modelling Permanent Fault Impact on Cache PerformanceDaniel Sánchez, Yiannakis Sazeides, Juan L. Aragón, José M. García239 Coherencia de Caché Mediante Árbol Basado en Proximidad y PredicciónAntonio García-Guirado, Ricardo Fernández-Pascual, José M. García245 Explotación de Técnicas de Especialización de Cores para Planificación Eficiente en Procesadores MulticoreAsimétricosJ.C. Sáez, Manuel Prieto, A. Pousa, A. Fedorova251 Optimización MapReduce para uso de los recursos en las arquitecturas multi-core.Tharso Ferreira, Aprigio Bezerra, Antonio Espinosa, Porfídio Hernández, Juan Carlos Moure255 Análisis de los datos privados/compartidos en aplicaciones paralelas sobre CMPsAlfonso Ramos, Antonio García-Guirado, José M. García261 Reconfiguración de la NoC en la Virtualización de CMPsF. Triviño, Francisco J. Alfaro, José L. Sánchez, José Flich, S. GonzálezJP2011-viii

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011267 Beneficios del uso de la Red de Interconexión en la Aceleración de la CoherenciaL.G. Menezo, A. Colaso, P. Prieto, P. Abad, V. Puente, J.A. Gregorio273 Conversion between DPD and RBCD for on-line arithmetic computationSonia González, Carlos García, Julio Villalba277 Multiples Puertos de Inyección en una Red en ChipJ. Camacho, José Flich, José Duato283 A Flexible Hybrid Transactional Memory Multicore on FPGAOriol Arcas, Nehir Sonmez, Osman S. Unsal, Adrián Cristal, Mateo Valero291 An Adaptive Controller to Save Dynamic Energy in LP-NUCAD. Suárez Gracia, T. Monreal Arnal, V. Viñals Yúfera297 Acelerando las simulaciones de sistema completo usando Simics en sistemas multiprocesadorSantos González, Francisco Triviño, Francisco J. Andujar, José L. Sánchez, Francisco J. AlfaroArquitecturas, algoritmos y aplicaciones sobre aceleradores hardware305 Parallelization of the Generalized Hough Transform on GPUJuan Gómez-Luna, José María González-Linares, José Ignacio Benavides, E.L. Zapata, Nicolás Guil311 rCUDA: Uso Concurrente de Dispositivos Compatibles con CUDA de Forma Remota. Adaptación a CUDA 4C. Reaño, A. J. Peña, F. Silla, R. Mayo, Enrique S. Quintana-Ortí, José Duato317 Un nuevo entorno para el uso de GPUsP. Valero, F. L. Pelayo323 Pre-procesamiento de Flujo Óptico Robusto en Hardware GráficoF. Ayuso, G. Botella, C. García, Manuel Prieto, F. Tirado329 Experiencias con Python y CUDA en Computación de Altas PrestacionesSergio Armas, Lionel Mena, Alejandro Samarín, Vicente Blanco, A. Morales, Francisco Almeida335 A Scalable Visualization System for Crowd SimulationsGuillermo Vigueras, Juan M. Orduña, Miguel Lozano, Víctor Fernández-Bauset341 A New Approach to rCUDAJosé Duato, A. J. Peña, F. Silla, J. C. Fernández, R. Mayo, Enrique S. Quintana-Ortí347 Métodos no lineales basados en el gradiente conjugado para GPUsH. Migallón, V. Migallón, J. Penadés353 Búsquedas por Similitud en Espacios Métricos sobre Plataformas Basadas en GPUsRoberto Uribe-Paredes, Pedro Valero-Lara, Enrique Arias, José Luis Sánchez, Diego Cazorla359 Query Processing in Metric Spaces using GPUsR.J. Barrientos, J.I. Gómez, C. Tenllado, Manuel PrietoRedes y comunicaciones367 Desarrollo de un Prototipo para la Notificación Automática de Accidentes de Tráfico usando Redes VehicularesManuel Fogue, Piedad Garrido, Francisco J. Martinez, Carlos T. Calafate, Juan Carlos Cano, Pietro Manzoni373 Hierarchical Analysis of Resilience Benchmarking Results Using LSP: Ad Hoc Networks As a Case StudyJesús Friginal, Juan-Carlos Ruiz, David de Andrés, Pedro Gil379 Protocolo para entrega fiable de contenidos en redes inalámbricas basado en codificación RaptorMiguel Báguena, Carlos T. Calafate, Juan Carlos Cano, Pietro Manzoni385 Evaluating video streaming performance in MANETs using a testbedTim Bohrloch, Carlos T. Calafate, Alvaro Torres, Juan Carlos Cano, Pietro Manzoni391 Statistical Modeling of Transmission Path Loss in Underwater Acoustic NetworksJ. Llor, Manuel P. Malumbres397 Predictive and Distributed Routing Balancing for High Speed Interconnection NetworksC. Núñez Castillo, D. Lugones, D. Franco, Emilio Luque403 Evaluación de una alternativa para aumentar el número de puertos de los conmutadoresJuan Antonio Villar, Francisco J. Andújar, José L. Sánchez, Francisco J. Alfaro, José DuatoJP2011-ix

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011409 Combinando diferentes enfoques para el control de congestión en redes de interconexión de altas prestacionesJesús Escudero-Sahuquillo, E. G. Gran, Pedro Javier García, José Flich, T. Skeie, O. Lysne, F. J. Quiles, JoséDuato415 Un acercamiento a la eficacia de las técnicas de control de congestión en redes de interconexión con topologíasdirectasDaniel Gómez-García, Pedro Javier García, Francisco José Quiles, Jesús Escudero-Sahuquillo, Juan AntonioVillar, José Flich, José Duato421 Peripheral twists for torus topologies with arbitrary aspect ratioEnrique Vallejo, Miquel Moretó, Carmen Martínez, Ramón Beivide427 Performance analysis of an IEEE 802.21 based Vertical Handover protocol using ns-2Johann Márquez-Barja, Carlos T. Calafate, Juan Carlos Cano, Pietro Manzoni433 Mecanismos de Comunicación Eficientes en Redes de Altas Prestaciones para Bibliotecas de Paso de Mensajesen JavaRoberto R. Expósito, Guillermo L. Taboada, Juan Touriño, Ramón Doallo439 Comunicaciones Escalables en Memoria Compartida para Paso de Mensajes en JavaSabela Ramos, Guillermo L. Taboada, Juan Touriño, Ramón Doallo445 Aproximación distribuida de incendios forestales con WSN usando la envolvente convexaM. Ángeles Serna, Aurelio Bermúdez, Rafael Casado, Pawel Kulakowski451 A First Approach to King Topologies for On-Chip NetworksE. Stafford, J.L. Bosque, C. Martinez, F. Vallejo, Ramón Beivide, C. CamareroSistemas Web e Internet459 Incorporación del dinamismo del usuario en un benchmark de comercio electrónicoRaúl Peña-Ortiz, José Antonio Gil, Julio Sahuquillo, Ana Pont467 Servicios Web Semánticos. Una aproximación desde las OntologíasE. González, I. López, E. NielsenTecnología grid, cluster, cloud computing y plataformas distribuidas475 Planificación de DAGS en entornos oportunísticosMaria del Mar López, Elisa Heymann, Miquel Àngel Senar483 QoS en Entornos Grid mediante un Sistema de Meta-planificación por Adelantado basado en SLAsJ. Conejero, L. Tomás, C. Carrión, B. Caminero489 RSA@Cloud: Sistema de Criptoanálisis sobre Infraestructuras CloudAlberto Megía Negrillo, Antonio Molinera Lamas, José Antonio Rueda Sánchez, José Luis Vázquez-Poletti495 Descripción de la Plataforma Formiga CloudFernando Gomez-Folgar, Javier López Cacheiro, C. Fernández Sánchez, Antonio García-Loureiro, R. Valin,Víctor Fernández-Albor501 Planificación de trabajos MapReduce en clusters Hadoop no-dedicadosAprigio Bezerra, Tharso Ferreira, Antonio Espinosa, Juan Carlos Moure, Porfídio Hernández507 Procesamiento de videos usando la nubeA. Morales, Francisco Almeida513 R en la nubeA. Santos, Francisco Almeida, Vicente Blanco, J.C. Castillo519 Comparativa y estudio de distribución de software de cálculo científico en entornos cloud con CVMFSVíctor Fernández-Albor, Ricardo Graciani, Javier López Cacheiro, Fernando Gomez-Folgar, Antonio García-Loureiro, Juan José Saborido525 Multi-Cluster Performance Impact on the Multiple-Job Co-Allocation SchedulingH. Blanco, F. Guirado, J. L. Lérida531 Mr-Cirrus: Implementación de Map-Reduce bajo MPI para la ejecución paralela de programas secuencialesD. Ramet, J. Lago, J. Falgueras, O. Trelles537 AbFS: Sistema de Ficheros AbiertoAntonio F. Díaz, Mancia Anguita, Hugo E. Camacho, Erik Nieto, Julio OrtegaJP2011-x

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011543 Comparación del rendimiento entre los hipervisores XEN y KVM usando virtualización por hardwareIsaac Zablah, R. Valin, Antonio García-Loureiro, Javier López Cacheiro, Fernando Gomez-FolgarArquitecturas del subsistema de memoria y almacenamiento secundario551 A Novel Approach for a Metadata ClusterA. Avilés-Gonález, J. Piernas, P. González-Férez557 Algoritmo de reemplazo para cache de último nivel basado en periodos MRUAlejandro Valero, Julio Sahuquillo, Salvador Petit, Pedro López, José Duato563 A Comparison of Cache Hierarchies for SMT ProcessorsD. Suárez Gracia, T. Monreal Arnal, V. Viñals Yúfera569 Metodología para Analizar y Evaluar los Sistemas de Entrada/Salida ParalelosSandra Méndez, Dolores Rexachs, Emilio Luque575 Memory Hierarchy and Network Co-design through Trace-Driven SimulationMario Lodde, José FlichDocencia en arquitectura, tecnología de computadores y programación paralela583 E-Assessment of Matlab Assignments in Moodle: Application to an Introductory Programming Course for EngineersJulián Ramos, María A. Trenas, Sergio Romero, Eladio Gutiérrez589 Sobre la integración del Curriculum Initiative on Parallel and Distributed Computing en los planes de estudio delGrado en Ingeniería InformáticaFrancisco Almeida, Domingo Giménez, José Miguel Mantas, Antonio M. Vidal595 Experiencias en Docencia de Diseño y Evaluación de ConfiguracionesA.M. Mora, P. García-Sánchez, P.A. Castillo, M.G. Arenas, J.J. Merelo, J. Ortega599 Diseño de un cluster de computadores como actividad para Arquitectura de ComputadoresF. Javier Fernández-Baldomero, Mancia AnguitaEvaluación de prestaciones607 Achieving interactive multiagent simulations over Jason through Java tuningVíctor Fernández Bauset, Francisco Grimaldo Moreno, Miguel Lozano Ibáñez, Juan Manuel Orduña Huertas613 Dynamically Tuning Master/Worker Applications with MATEA. Martínez, A. Morajko619 Análisis de un sistema Android como plataforma para juegos de realidad aumentadaA.L. Sarmiento, M. Amor, C.V. Regueiro, E.J. Padrón625 Un modelo analítico mejorado para la arquitectura CUDAM. Viñas, B.B. Fraguela, M. Amor, Ramón Doallo631 Análisis de Escalabilidad en Aplicaciones Paralelas con Carga de Trabajo No EquilibradaJ.L. Bosque, OD. Robles, P. Toharía, L. Pastor637 Mejorando las aplicaciones de red en arquitecturas multinúcleo heterogéneasA. Ortiz, J. Ortega, Antonio F. Díaz, A. Prieto643 Estimación del efecto de los fallos cache en el rendimiento de aplicaciones paralelasD.R. Martínez, Vicente Blanco, J.C. Cabaleiro, T.F. Pena, Francisco F. Rivera649 Metodología para la sintonización de aplicaciones OpenMP en sistemas multicoreC. Allande, J. Jorba, E. César, A. Morajko655 Herramientas para la monitorización de los accesos a memoria de códigos paralelos mediante contadores hardwareOscar G. Lorenzo, Juan A. Lorenzo, Dora B. Heras, Juan C. Pichel, Francisco F. Rivera661 Evaluación del Benchmark Rodinia en los sistemas del SAIIL. Cerrudo, A. J. Dorta, J. J. Fumero, C. González, L. Grillo, I. López, F. de SandeJP2011-xi

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Computación de altas prestaciones sobre arquitecturas paralelas heterogéneas669 Algoritmos eficientes para la transformada wavelet discreta en multicores y GPUsV. Galiano, O. López, Manuel P. Malumbres, H. Migallón675 Tableless Distributed Routing in Heterogeneous MPSoC SystemsJosé Cano, José Flich, José Duato, Marcello Coppola, Riccardo Locatelli681 Uso del conocimiento de la arquitectura Fermi para mejorar el rendimiento en aplicaciones CUDAYuri Torres, Arturo González-Escribano, Diego R. Llanos687 Estrategias de optimización en diferentes arquitecturas CUDA usando llCoMPR. Reyes, J. J. Fumero, I. López, F. de Sande693 Sistema modular desarrollado en FPGA, para el cálculo de mapas de disparidad de imagenes estereoscópicasS. Ibarra, José Ignacio Benavides, M.H. Calviño699 Estrategias de optimización en GPU y CPU multi-core de modelos SPHJ. M. Domínguez, A. J. C. Crespo, A. Barreiro, M. Gómez-Gesteira705 Implementación del algoritmo de registro no lineal DARTEL sobre una plataforma heterogéneaP. Valero, José Luis Sánchez, Enrique Arias, D. CazorlaCompilación para sistemas de altas prestaciones713 Checkpoint Size Reduction in Application-level Fault Tolerant SolutionsI. Cores, G. Rodríguez, M. Martín, P. González719 Source-to-Source Transformations for Efficient SIMD Code GenerationAlejandro Berna, Marta Jiménez, Jose M. Llabería.727 Índice de AutoresJP2011-xii

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmos y técnicas de programación paralelasJP2011-1

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-2

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Una Versión Paralela de la EvoluciónDiferencial para Predecir Motifs en Cadenas deADNDavid L. González-Álvarez1 Miguel A. Vega-Rodríguez 2 Juan A. Gómez-Pulido 3Juan M. Sánchez-Pérez 4Resumen—La utilidad y la eficiencia de un algoritmo pararesolver un determinado problema de optimizaciónno viene dado solo por la calidad de las solucionesobtenidas, es también importante el tiempo computacionaly los recursos requeridos para su obtención.En este artículo presentamos una implementaciónparalela de la Evolución Diferencial (DE) para resolverel Problema del Descubrimiento de Motifs(PDM). El PDM es un problema de gran importanciabiológica que puede requerir una gran cargacomputacional si analizamos grandes cantidades deinformación genética, por ello, la utilización de paralelismoen maquinas de memoria compartida puedeayudarnos a obtener resultados más rápidamente.Para asegurarnos de que nuestra heurística obtieneresultados relevantes, hemos comparado los resultadosobtenidos con los obtenidos por un algoritmoestándar en la computación evolutiva como es el algoritmoNSGA-II, además de con otros catorce métodosmuy conocidos dentro del campo de la biología. Comoveremos, la estructura del algoritmo lo hace apropiadopara la paralelización, logrando buenos resultadosy eficiencias de hasta un 95%.Palabras clave—Evolución Diferencial, computación paralela, multinúcleo,optimización multiobjetivo, descubrimientode motifs.I. IntroducciónEn los últimos años hemos visto una granevolución en las interfaces de memoria compartida.Actualmente prácticamente todos los compiladoresincluyen las librerías necesarias para desarrollarfácilmente programas paralelos. Entre todasestas interfaces estándares de programación paraleladestacan MPI y OpenMP. MPI es una interfaz dedicadaa la programación de clusters, mientras queOpenMP es el estándar de programación más empleadoen la programación de multiprocesadores conmemoria compartida. En este trabajo aplicamos esteúltimo tipo de paralelismo para resolver un importanteproblema dentro de la bioinformatica, el Problemadel Descubrimiento de Motifs (PDM). Predecirmotifs es uno de los problemas más importantesdentro del análisis de secuencias, y aun nadie ha1 Dpto. Tecnología de Computadores y Comunicaciones,Grupo de Investigación ARCO, Universidad de Extremadura,e-mail: dlga@unex.es2 Dpto. Tecnología de Computadores y Comunicaciones,Grupo de Investigación ARCO, Universidad de Extremadura,e-mail: mavega@unex.es3 Dpto. Tecnología de Computadores y Comunicaciones,Grupo de Investigación ARCO, Universidad de Extremadura,e-mail: jangomez@unex.es4 Dpto. Tecnología de Computadores y Comunicaciones,Grupo de Investigación ARCO, Universidad de Extremadura,e-mail: sanperez@unex.esconseguido resolverlo de una manera eficiente. Estosmotifs son pequeños patrones de ADN, ARNo proteínas que normalmente ejercen la función dePuntos de Unión de Factores de Transcripción endistintos genes (TFBS). Normalmente no son muylargos (alrededor de 30 nucleótidos) y sin espacios,por lo que descubrirlos entre una gran cantidad deinformación biológica en las secuencias de ADN no esuna tarea nada fácil. Para encontrarlos, hemos utilizadouna heurística basada en la Evolución Diferencial(DE) que hemos paralelizado utilizando el interfazOpenMP. Además, hemos implementado tambiénuna versión paralela del algoritmo NSGA-II para asídisponer de un punto de referencia con el que compararlos resultados obtenidos por nuestra propuesta.En este trabajo no solo hemos analizado las eficienciaslogradas por las versiones paralelas de estos dosalgoritmos, sino que también hemos analizado la calidadde los motifs predichos por los algoritmos. Parahacer esto, hemos aplicado diferentes indicadorescomo el Hipervolumen o la Relación de Cobertura, yestadísticas como la Sensibilidad, el Valor de PrediccionesPositivas, el Coeficiente de Rendimiento o elCoeficiente de Correlación. Como veremos, nuestroalgoritmo logra buenos resultados paralelos, ademásde resultados biológicamente relevantes.Este documento se organiza de la siguiente forma.En la siguiente sección explicamos brevemente elPDM. En la Sección III describimos los algoritmospresentados en este trabajo y detallamos comolos hemos paralelizado. La Sección IV muestralos resultados obtenidos por nuestras propuestas,comparándolas con varios algoritmos y métodosbiológicos. Finalmente, la Sección V incluye variasconclusiones obtenidas tras la elaboración de estetrabajo.II. Problema del Descubrimiento de MotifsEl Problema del Descubrimiento de Motifs (PDM)trata de resolver de forma óptima el problema quesupone predecir motifs, aplicado a la tarea específicade descubrir nuevos Puntos de Unión de Factores deTranscripción (TFBS) en secuencias de ADN [1]. LosTFBSs y otros elementos genéticos con una estructuray función específica son conocidos con el nombrede motifs. Para descubrir motifs de una ciertarelevancia biológica debemos satisfacer unos objetivosconcretos a la vez que cumplir ciertas restricciones.Nosotros hemos afrontado el PDM definiendotres objetivos: el tamaño, el soporte y la simila-JP2011-3

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IUn problema de descubrimiento de motifs artificial. Muestra en (a) las secuencias, (b) indica las posicionesiniciales de los motifs candidatos, (c) los motifs candidatos, (d) la tasa de concordancia existente entre cadamotif candidato y el motif consenso ‘TCTTGGAA’ (umbral del soporte en 50%) y (e) las MRP y MFP.(a) (b) (c) (d) (e)1 GAC TCTTGGAC TAATCCTTC -1214 TCTTGGAC 7/8 √ A: 2 0 0 0 0 1 10 52 A GCTTGGAA TTGACTAGTGG -1137 GCTTGGAA 7/8 √ C: 1 10 0 0 0 0 0 33 CAGGGCTCT TCTGTAAA AAA -1266 TCTGTAAA 5/8 √ G: 1 0 1 2 8 9 0 04 TTTA ACTTGGAA AGCACTCA -0434 ACTTGGAA 7/8 √ T: 6 0 9 8 2 0 0 25 ACAATATGAC ACTTGGAC CA -0607 ACTTGGAC 6/8 √ A: 20% 0% 0% 0% 0% 10% 100% 50%6 A CCTTGGAA GTCAACAAAAA -0676 CCTTGGAA 7/8 √ C: 10% 100% 0% 0% 0% 0% 0% 30%7 GCAATTCGTGT TCTTTGAT G -1089 TCTTTGAT 6/8 √ G: 10% 0% 10% 20% 80% 90% 0% 0%8 GGATAT TCTTGGAT TCCTAG -0186 TCTTGGAT 6/8 √ T: 60% 0% 90% 80% 20% 0% 0% 20%9 AGGT TCTGGGAC TTTCCAGA -0887 TCTGGGAC 6/8 √10 AAC TCGTGGAA CGGCACATG -1067 TCGTGGAA 7/8 √ Soporte: 10, Tamaño: 8, Similaridad: 81%ridad del motif. Dado un conjunto de secuenciasS = {S i |i = 1, 2, ..., D} de nucleótidos definidos en elalfabeto B = {A, C, G, T }. S i = {S j i |j = 1, 2, ..., w i}es una secuencia de nucleótidos, donde w i es la longitudde la secuencia. El conjunto de todas las subsecuenciascontenidas en S es {s jii |i = 1, 2, ..., D, j i =1, 2, ..., w i − l + 1}, donde j i es el punto de uniónde un posible motif candidato s j i en la secuencia S i,y l es el tamaño del motif, el primer objetivo a sermaximizado. Para obtener los valores de los otrosdos objetivos tenemos que construir la Matriz de Indicadoresde Posición (MIP) A = {A i |i = 1, 2, ..., D}del motif, donde A i = {A j i |j = 1, 2, ..., w i} es el vectorindicador con respecto a la secuencia S i . A j ies 1 si la posición j en S i es el punto de unióny 0 en caso contrario. Nos referimos al númerode motifs candidatos como |A| = ∑ D ∑ wii=1 j=1 Aj i .También necesitamos encontrar el motif consenso, elcual se extrae de los motifs candidatos. En este trabajoconsideramos un solo motif candidato por secuenciay, solo aquellas secuencias que logren motifscandidatos de cierta calidad (con respecto almotif consenso) se tendrán en cuanta a la hora deformar el motif final. Esto se indica a través delsegundo objetivo, el soporte. Además, S(A) ={S(A) 1 , S(A) 2 , ..., S(A) |A| } es el conjunto de |A| motifscandidatos, donde S(A) i = S(A) 1 i S(A)2 i ...S(A)l ies el i-esimo motif candidato de |A|. S(A) puedetambién expandirse con (S(A) 1 , S(A) 2 , ..., S(A) l ),donde S(A) j = S(A) j 1 S(A)j 2 ...S(A)j |A|es la lista denucleótidos de la j-esima posición del motif candidato.A continuación debemos construir la Matriz deRepeticiones por Posición (MRP) N(A) teniendo encuenta el número de nucleótidos de cada tipo que hayen cada posición de cada motif candidato (A) quehaya superado el valor umbral en el segundo objetivo,el soporte. N(A) = {N(A) 1 , N(A) 2 , ..., N(A) l }y N(A) j = {N(A) j b |b ∈ B}, donde N(A)j b=|{S(A) j i |S(A)j i = b}|. El número de repeticiones delnucleótido dominante en cada posición se normalizaobteniendo la Matriz de Frecuencia por Posición(MFP) ̂N = N(A)|A|. Finalmente, para hallar el valordel último objetivo, la similaridad, debemos calcularel valor medio de las repeticiones de los nucleótidosdominantes en cada columna de la MFP, tal y comose indica en la siguiente expresión:∑ li=1Similaridad(Motif) =max b{f(b, i)}l(1)donde f(b, i) es la puntuación obtenida por el nucleótidob en la columna i de la MFP y max b {f(b, i)}es el número de repeticiones normalizado obtenidopor el nucleótido dominante en la columna i.Para orientar la búsqueda de patrones hacia solucionescon cierta relevancia biológica, hemos incorporadovarias restricciones que deben satisfacer todaslas soluciones obtenidas por nuestros algoritmos.La primera de ellas limita el tamaño de los motifsal rango [7,64], donde 7 es el tamaño mínimo y 64el máximo. En el segundo objetivo hemos establecidoun valor mínimo en el soporte de 2 para losmotifs descubiertos en instancias compuestas por 4o menos secuencias, y de 3 en las demás (más de4 secuencias). Finalmente, hemos aplicado el conceptode complejidad [2]. La complejidad de un motifdebe considerarse para descartar las solucionesmenos complejas y, por lo tanto, menos relevantesbiológicamente hablando. Para ello aplicaremos lasiguiente expresión:Complejidad = log Nl!∏ (ni )!(2)donde N = 4 para secuencias de ADN, l es el tamañodel motif, y n i es el número de nucleótidos del tipoi ∈ {A, C, G, T }.La Tabla I muestra un PDM artificial con motifs detamaño = 8. En este ejemplo, utilizando los motifscandidatos mostrados en las Tablas Ia y Ic obtenemosel motif consenso TCTTGGAA. Con este motifpodemos calcular el valor del segundo objetivo, elsoporte (ver Tabla Id). Las secuencias cuyos motifscandidatos superen o igualen el valor umbral de concordanciaestablecido en 50% (4/8), se tendrán encuenta en este objetivo. En este ejemplo obtenemosun soporte = 10. El último paso es construir la MRPJP2011-4

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.Esquema de la versión paralela de la Evolución Diferencial.y la MFP utilizando los nucleótidos de los motifs candidatosque hayan superado el filtro anterior (umbraldel soporte). Hecho esto, podemos obtener el valorfinal de similaridad aplicando la ecuación (1). Eneste ejemplo obtenemos una similaridad = 0, 8125.III. Descripción de los AlgoritmosParalelosEn este trabajo presentamos una versión paralelade la Evolución Diferencial (DE). Esta nueva versióndel algoritmo la comparamos con otra versión paraleladel algoritmo NSGA-II. El algoritmo DE es unalgoritmo basado en población [3] que optimiza unproblema manteniendo una serie de individuos que secruzan para generar otros nuevos. Todo este procesose realiza aplicando una formulación de cruce y mutaciónmuy sencilla. Para adaptar el funcionamientode este algoritmo al PDM multiobjetivo hemos incorporadoel concepto de Torneos de Pareto, obteniendoun nuevo algoritmo llamado Evolución Diferencialcon Torneos de Pareto (DEPT), descrito en [4]. El interfazde programación OpenMP es el escogido paradesarrollar las versiones paralelas de nuestros algoritmos.Si analizamos el funcionamiento del DEPT ([3]y [4]) podemos comprobar cómo no existe ningunadependencia de datos en el bucle principal, por loque se puede paralelizar en su totalidad. Para ello,hemos incrustado la directiva OpenMP ‘#pragmaomp parallel for’ antes del bucle principal del algoritmo,especificando apropiadamente las variablespúblicas y privadas necesarias. En cada iteración delbucle el algoritmo aplica el esquema de selección especificadoa todos los individuos de la población (individuosobjetivo). Suponiendo una población de 8individuos en una maquina de 8 núcleos, cada núcleoprocesaría solo un individuo objetivo, generando elcorrespondiente individuo de prueba y ejecutando eltorneo de Pareto que enfrentará al individuo objetivocon el individuo de prueba. Nuestra Evolución Diferencialparalela divide cada iteración del bucle principalen diferentes hilos. Si lo explicásemos de formamatemática, diríamos que disponiendo de un sisteman-núcleos y un tamaño de población P S, cada hiloejecuta P S/n iteraciones del bucle principal. En laFigura 1 mostramos una representación grafica delproceso seguido por el algoritmo paralelo suponiendouna población de 32 individuos en un sistema con 8núcleos. En este ejemplo desplegamos 8 hilos, dondecada uno de ellos procesa 4 individuos objetivo encada generación. Es importante saber que hasta quetodos los hilos no hayan terminado su ejecución, lasiguiente generación no comenzará.El segundo algoritmo que hemos paralelizado esel Algoritmo Genético de Ordenación Nodominada(NSGA-II). Este algoritmo es una extensión delAlgoritmo Genético (GA) diseñado para optimizarmúltiples objetivos. En [5] podemos encontraruna descripción detallada del algoritmo. Para paralelizarlohemos seguido la misma metodología queen el algoritmo DEPT, utilizando el interfaz de programaciónOpenMP. En la versión paralela del algoritmoNSGA-II hemos paralelizado la función quegenera la población padre, la función que se encargade generar la población hija utilizando individuos dela población padre, la ordenación nodominada y elcálculo de la distancia de crowding. Para ello hemosvuelto a hacer uso de la directiva ‘#pragma ompparallel for’, definiendo los parámetros necesariospara no sobrescribir ninguna variable. Empleando lamisma formulación matemática que en el algoritmoanterior, en las funciones que generan las poblacionespadre e hija, cada hilo genera P S/n individuos, lograndouna mejora temporal considerable. En lasotras dos funciones (la ordenación nodominada y elcálculo de la distancia de crowding) cada hilo calculael numero de soluciones dominadas o que dominan acada individuo en cada uno de ellos (para despuéspoder ordenarlos según esos datos) y obtener así elcorrespondiente valor de distancia de crowding.Con los dos algoritmos paralelizados podemoscomenzar a hacer comparativas para saber cuál de losdos algoritmos es más apropiado paralelizar. En lasiguiente sección se muestra los resultados (speedupsy eficiencias) obtenidos por cada algoritmo y se analizael comportamiento de ambos en diferentes sistemasmulti-núcleo. Como veremos los primerosresultados indican que el algoritmo DEPT es másapropiado para la paralelización que el algoritmoNSGA-II, logrando eficiencias de hasta un 95%.IV. Evaluación Experimental yComparativasAntes de paralelizar los algoritmos, debemos encontrarlas configuraciones que mejores resultadosobtienen. En esta sección describimos las instanciasutilizadas en nuestros experimentos y mostramos losresultados obtenidos. La metodología seguida y larepresentación de los individuos es la misma que laque utilizada en [4], estableciendo como condiciónde terminación 3000 generaciones en ambos algorit-JP2011-5

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IICaracterísticas de las instancias utilizadas.TABLA IIIMejores configuraciones encontradas.Nombre #Sec. Tamaño Nombre #Sec. Tamañodm01g 4 1500 mus02r 9 1000dm04g 4 2000 mus03g 5 500dm05g 3 2500 mus07g 4 1500hm03r 10 1500 yst03m 8 500hm04m 13 2000 yst04r 7 1000hm16g 7 3000 yst08r 11 1000DEPT Tamaño de la Población 200Probabilidad de Cruce 25%Factor de Mutación 3%Esquema de Selección Aleatorio/1/BinomialNSGA-II Tamaño de la Población 200Probabilidad de Cruce 60%Factor de Mutación 50%Elección de los Padres Torneo BinarioTABLA IVHipervolúmenes obtenidos por los algoritmos.DEPTNSGAIIPeor Media Mejor Peor Media Mejordm01g 76,69% 79,68% 82,41% 80,62% 81,56% 82,27%dm04g 77,26% 79,74% 81,70% 80,22% 81,06% 81,90%dm05g 79,59% 81,95% 84,46% 83,53% 84,41% 85,86%hm03r 61,80% 65,33% 71,91% 42,70% 47,40% 53,38%hm04m 56,87% 61,25% 65,40% 39,30% 43,32% 45,93%hm16g 74,78% 79,72% 85,41% 65,92% 68,12% 70,47%mus02r 67,71% 69,96% 74,69% 57,09% 59,24% 61,72%mus03g 73,73% 77,49% 79,62% 76,38% 77,18% 77,55%mus07g 76,49% 80,58% 87,19% 86,16% 87,01% 88,30%yst03m 71,85% 73,22% 74,98% 63,50% 65,52% 68,10%yst04r 70,66% 74,32% 78,97% 74,29% 74,80% 75,80%yst08r 63,39% 68,03% 75,78% 62,23% 64,87% 67,09%Media 70,90% 74,27% 78,54% 67,66% 69,54% 71,53%TABLA VRelación de cobertura (A ≽ B).A B dm01g dm04g dm05g hm03r hm04m hm16g mus02r mus03g mus07g yst03m yst04r yst08r MediaDEPT NSGAII 44,12% 65,85% 55,17% 97,62% 97,26% 90,00% 94,52% 83,93% 60,87% 93,06% 89,83% 95,24% 80,62%NSGAII DEPT 51,79% 39,29% 48,39% 0,00% 0,00% 0,00% 0,00% 23,75% 42,11% 0,78% 0,00% 0,00% 17,17%mos. Para comparar los resultados obtenidos por losalgoritmos que hemos implementado, además del indicadorHipervolumen, hemos utilizado la Relaciónde Cobertura [6], la cual permite analizar que algoritmoobtiene los mejores frentes de Pareto. En nuestraexperimentación hemos utilizado doce instanciasreales seleccionadas de la base de datos TRANS-FAC [7]. Estos conjuntos de datos tienen diferentespropiedades para asegurar que nuestros algoritmosfuncionan bien con todo tipo de instancias (ver TablaII).Los parámetros configurados y los mejores valoresencontrados para cada uno de ellos se muestran enla Tabla III. El orden en el que estos han sido ajustadoses el mismo que aparece en la Tabla III. Parademostrar que los resultados obtenidos por ambosalgoritmos son relevantes hemos realizado comparativasutilizando diferentes indicadores. La primeracomparativa analiza los resultados obtenidos por ambosalgoritmos utilizando el indicador Hipervolumen.Este indicador mide la región cubierta por las solucionespredichas por cada algoritmo en cada instancia.En la Tabla IV mostramos los Hipervolúmenesobtenidos. Podemos apreciar como en los conjuntosde datos con 4 o menos secuencias (instanciasdm y mus07g) el algoritmo NSGA-II logra mejoresresultados que el DEPT. Vemos también como enlos conjuntos de datos con entre 5 y 7 secuencias(mus03g, yst04r y hm16g) ambos algoritmos obtienenHipervolúmenes similares. Sin embargo, elalgoritmo DEPT obtiene mejores resultados en lasinstancias con 7 o más secuencias. Esto demuestraque el algoritmo DEPT es un algoritmo muy regular,mientras que el algoritmo NSGA-II solo funcionabien en instancias sencillas con pocas secuencias.En la Tabla V aplicamos el segundo indicador,la Relación de Cobertura. Este indicador permitecomparar los resultados individuales obtenidos porambos algoritmos [6], ya que se aplica sobre las solucionesnodominadas descubiertas por los algoritmos.En la Tabla V vemos como las soluciones nodominadasdel algoritmo DEPT cubren el 80.62% delas soluciones nodominadas del algoritmos NSGA-II,mientras que el algoritmo NSGA-II solo logra cubrirJP2011-6

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA VIComparativas de Sensibilidad (nSn) y Valor de Predicciones Positivas (nP P V ) de las soluciones del DEPT.nSnnPPVInstancia Mejor Valor (método) DEPT Incremento Mejor Valor (método) DEPT Incrementodm01g 0,344000 (SeSiMCMC) 0,440000 0,096000 0,344000 (SeSiMCMC) 1,000000 0,656000dm04g 0,022222 (MotifSampler) 0,370370 0,348148 0,032967 (MotifSampler) 0,888889 0,855922dm05g 0,037500 (MEME) 0,293750 0,256250 0,026666 (MEME) 1,000000 0,973333hm03r 0,063725 (MEME) 0,250000 0,186275 0,108333 (MEME) 0,564103 0,455770hm04m 0,005952 (AlignACE) 0,273810 0,267858 0,006060 (AlignACE) 0,333333 0,327272hm16g 0,000000 (-) 0,384146 0,384146 0,000000 (-) 0,666667 0,666667mus02r 0,094827 (MEME) 0,306034 0,211206 0,142857 (MEME) 0,750000 0,607143mus03g 0,281690 (AlignACE) 0,528169 0,246479 0,256410 (AlignACE) 1,000000 0,743590mus07g 0,040000 (ANN Spec) 0,510000 0,470000 0,020942 (ANN Spec) 1,000000 0,979058yst03m 0,340136 (Improbizer) 0,251701 -0,088435 0,700000 (YMF) 0,904762 0,204762yst04r 0,335877 (Consensus) 0,448598 0,112720 0,357142 (MITRA) 0,590909 0,233766yst08r 0,387096 (AlignACE) 0,390681 0,003584 0,786407 (MotifSampler) 0,559524 -0,226884TABLA VIIComparativas de Rendimiento (nP C) y Coeficiente de Correlación (nCC) de las soluciones del DEPT.nPCnCCInstancia Mejor Valor (método) DEPT Incremento Mejor Valor (método) DEPT Incrementodm01g 0,207729 (SeSiMCMC) 0,404762 0,197033 0,330042 (SeSiMCMC) 0,628460 0,298417dm04g 0,013452 (MotifSampler) 0,247525 0,234072 0,013401 (MotifSampler) 0,388252 0,374851dm05g 0,015831 (MEME) 0,211429 0,195598 0,006491 (MEME) 0,399132 0,392641hm03r 0,041800 (MEME) 0,195402 0,153601 0,063601 (MEME) 0,330695 0,267094hm04m 0,003012 (AlignACE) 0,136364 0,133352 -0,000399 (AlignACE) 0,237391 0,237791hm16g 0,000000 (-) 0,274882 0,274882 -0,005203 (MEME) 0,438551 0,443755mus02r 0,060439 (MEME) 0,201258 0,140818 0,097480 (MEME) 0,347446 0,249966mus03g 0,155038 (AlignACE) 0,401070 0,246031 0,222479 (AlignACE) 0,551272 0,328792mus07g 0,013937 (ANN Spec) 0,382114 0,368177 0,006056 (ANN Spec) 0,555691 0,549635yst03m 0,261904 (oligodyad) 0,203488 -0,058417 0,437304 (oligodyad) 0,369000 -0,068304yst04r 0,202765 (Consensus) 0,265152 0,062387 0,322430 (Consensus) 0,430516 0,108086yst08r 0,269103 (MotifSampler) 0,250000 -0,019103 0,470595 (MotifSampler) 0,384898 -0,085698TABLA VIIIRendimiento del DEPT y el NSGA-II utilizando diferentes sistemas multi-núcleo. X es el tiempo medio (ensegundos), S p es el speed-up y E p la eficiencia, para p núcleos.Secuencial 2-Núcleos 4-Núcleos 8-NúcleosDEPT NSGA-II DEPT NSGA-II DEPT NSGA-II DEPT NSGA-IIInstancias X X S 2 E 2 S 2 E 2 S 4 E 4 S 4 E 4 S 8 E 8 S 8 E 8dm01g 139,0 176,6 1,90 95,1% 1,80 90,0% 3,63 90,7% 3,13 78,4% 6,51 81,3% 4,58 57,3%dm04g 139,1 168,6 1,90 94,9% 1,90 95,1% 3,62 90,6% 3,16 79,0% 6,50 81,2% 4,89 61,2%dm05g 107,2 43,2 1,89 94,3% 1,68 84,0% 3,57 89,2% 2,38 59,6% 6,21 77,6% 2,80 35,0%hm03r 150,7 115,6 1,87 93,7% 1,74 86,9% 3,48 87,0% 2,78 69,4% 5,42 67,8% 3,63 45,3%hm04m 130,5 132,3 1,81 90,4% 1,73 86,4% 3,33 83,3% 2,85 71,2% 4,33 54,1% 3,75 46,8%hm16g 156,8 170,6 1,88 94,0% 1,77 88,6% 3,59 89,8% 3,08 77,1% 6,31 78,8% 4,56 56,9%mus02r 177,6 141,7 1,88 93,9% 1,76 88,2% 3,60 90,0% 2,92 73,0% 6,26 78,3% 4,15 51,9%mus03g 131,7 180,8 1,91 95,3% 1,75 87,7% 3,60 90,1% 3,30 82,4% 6,41 80,1% 4,83 60,4%mus07g 173,1 142,3 1,85 92,5% 1,82 90,8% 3,51 87,7% 3,06 76,4% 5,73 71,6% 4,06 50,7%yst03m 175,9 190,1 1,88 94,1% 1,83 91,7% 3,61 90,1% 3,20 80,0% 6,52 81,5% 4,84 60,5%yst04r 172,9 218,2 1,90 94,8% 1,82 91,0% 3,63 90,7% 3,19 79,9% 6,50 81,3% 4,87 60,9%yst08r 200,1 160,6 1,89 94,7% 1,78 89,1% 3,61 90,1% 3,09 77,1% 6,26 78,2% 4,30 53,7%Media 154,6 153,4 1,88 94,0% 1,78 89,1% 3,56 89,1% 3,01 75,3% 6,08 76,0% 4,27 53,4%JP2011-7

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011el 17.17% de las soluciones del DEPT.Podemos observar también como en casi todaslas instancias donde el algoritmo NSGA-II logramejores Hipervolúmenes que el DEPT, este últimologra mayores tasas de cobertura. Esto es debidoal hecho de que el algoritmo NSGA-II logra puntosmás dispersos en sus frentes de Pareto (favoreciendoel Hipervolumen). Sin embargo, las soluciones descubiertaspor el DEPT tienen mejores valores ensus objetivos. La última comparativa pretende demostrarla relevancia biológica de los motifs predichospor nuestro principal algoritmo, el DEPT. Parahacer esto, hemos comparado estas soluciones conlas predichas por otros catorce métodos bien conocidosen el campo biológico, descritos con detalle en[8]. En esta comparativa analizamos la Sensibilidad(nSn), el Valor de Predicciones Positivas (nP P V ), elRendimiento (nP C) y el Coeficiente de Correlación(nCC) de los mejores motifs descubiertos por el algoritmoDEPT, en cada uno de los conjuntos de datos.Comparándolos con el mejor resultado obtenido porel mejor método de entre los catorce anteriormentemencionados. Véase como en las Tablas VI y VIIen casi todas las instancias, los resultados obtenidospor nuestros motifs logran mejores resultados que losobtenidos por el mejor, demostrando así que los resultadosdescubiertos por nuestra heurística tienenuna gran relevancia biológica.Finalmente, en esta sección presentamos los resultadosde la paralelización aplicada sobre los algoritmosDEPT y NSGA-II, utilizando el interfazde programación OpenMP. Es importante destacarque los resultados obtenidos por las versiones paralelasy secuenciales de los algoritmos son los mismos,solo que se obtienen más rápidamente. En laTabla VIII mostramos los tiempos de ejecución, losspeedups y las eficiencias logradas por ambos algoritmos(DEPT y NSGA-II), en distintos sistemas multinúcleo(con 1, 2, 4 y 8 núcleos). En cada experimentohemos calculado el valor medio de speedup yeficiencia de entre 30 ejecuciones independientes, utilizandouna maquina multi-núcleo que dispone de 8núcleos (2,8Ghz y Scientific Linux 5,3). En la TablaVIII vemos como el algoritmo DEPT consigue casiel speedup ideal utilizando los sistemas con 2 y 4núcleos. Vemos también como el algoritmo NSGA-II,aunque consigue eficiencias muy prometedoras (porencima del 75%), obtiene resultados un poco peoresque los logrados por el DEPT. Finalmente, enlas pruebas realizadas con el sistema de 8 núcleos,el algoritmo DEPT mantiene eficiencias mayores del75%, mientras que el algoritmo NSGA-II cae hasta el53,4%. Con estos datos concluimos que el algoritmoDEPT es capaz de obtener soluciones hasta 6 vecesmás rápido (speedup de 6,08) en un sistema con 8núcleos. Por contra, el algoritmo NSGA-II solo escapaz de obtener los resultados 4 veces más rápido(speedup de 4,27). Las diferencias entre ambos algoritmosson considerables siendo el algoritmo DEPTun algoritmo muy adecuado para paralelizar.V. Conclusiones y Líneas FuturasEn este trabajo hemos propuesto una versión paralelade la Evolución Diferencial para resolver elProblemas del Descubrimiento de Motifs (PDM)utilizando la interfaz OpenMP. Los experimentosrealizados con distintos sistemas multi-núcleo demuestranque este algoritmo es apropiado para laparalelización, obteniendo eficiencias de hasta un95%. También hemos desarrollado la correspondienteversión paralela del algoritmo NSGA-II un algoritmoestándar en computación evolutiva. Analizandotodos los resultados podemos concluir quenuestra propuesta paralela obtiene mejores eficienciasy mejores predicciones que el algoritmo NSGA-II. Como trabajo futuro implementaremos y paralelizaremosnuevos algoritmos evolutivos multiobjetivopara resolver el PDM, comparando los resultadosobtenidos con los obtenidos por los algoritmosincluidos en este trabajo.AgradecimientosGracias a la Fundación Valhondo Calaff por elapoyo económico ofrecido a David L. González-Álvarez para realizar este trabajo. Este trabajo estáparcialmente financiado por el Ministerio de Cienciae Innovación y el FEDER (Fondo Europeo de DesarrolloRegional), bajo el proyecto TIN2008-06491-C04-04 (proyecto M*).Referencias[1] P. D’haeseleer, What are DNA sequence motifs?, NatureBiotechnology, vol. 24, no. 4, pp. 423-425, 2006.[2] G.B. Fogel et al., Evolutionary computation for discoveryof composite transcription factor binding sites, NucleicAcids Reseach, vol. 36, no. 21, pp. e142, 2008.[3] K. Price, R. Storn, Differential Evolution - A Simple EvolutionStrategy for Fast Optimization, Dr. Dobb’s Journal,vol. 22, no. 4, pp. 18-24 and 78, 1997.[4] D.L. González-Álvarez, M.A. Vega-Rodríguez, J.A.Gómez-Pulido, J.M. Sánchez-Pérez, Solving the MotifDiscovery Problem by Using Differential Evolution withPareto Tournaments, CEC’10, IEEE Computer Society,Barcelona, Spain, pp. 4140-4147, 2010.[5] K. Deb, A. Pratap, S. Agarwal, T. Meyarivan, A fast andelitist multi-objective genetic algorithm: NSGA II, IEEETransactions on Evolutionary Computation, vol. 6, 182-197, 2002.[6] E. Zitzler, K. Deb, L. Thiele, Comparison of multiobjectiveevolutionary algorithms: empirical results, IEEE Transactionson Evolutionary Computation, vol. 8, no. 2, pp.173-195, 2000.[7] E. Wingender, P. Dietze, H. Karas, R. Knüppel, TRANS-FAC: a database on transcription factors and their DNAbinding sites, Nucleic Acids Research, vol. 24, no. 1, pp.238-241, 1996.[8] M. Tompa, et al, Assessing computational tools for thediscovery of transcription factor binding sites, NatureBiotechnology, vol. 23, no. 1, pp. 137-144, 2005.JP2011-8

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Comparación de Algoritmos Evolutivos Paralelos y Secuencialespara el Alineamiento Múltiple de SecuenciasFernando José Mateus Silva 1 Juan Manuel Sánchez-Pérez 2 , Juan Antonio Gómez-Pulido 2 and MiguelA. Vega-Rodríguez 2 -TISCTGNIGAG-NHVKWYQQLPGResumen—El alineamiento múltiple de secuencias es una delas tareas más comunes en Bioinformática. Es un método quepermite organizar un conjunto de secuencias moleculares con elfin de mostrar sus similitudes y sus diferencias. El uso demétodos exactos, para abordar este problema, está limitado porla gran cantidad de recursos de computación necesarios paraexplorar espacios de soluciones grandes y complejos. AlineaGAes un algoritmo evolutivo desarrollado para realizaralineamiento múltiple de secuencias y constituye, además, unaalternativa para mejorar la exploración y explotación de labúsqueda de soluciones con el fin de encontrar el mejoralineamiento. Este algoritmo se ha desarrollado tanto en formasecuencial como paralela. La versión paralela utiliza elprotocolo MPI y, no sólo aumenta la calidad de las solucionesencontradas sino que las encuentra en menos tiempo. En estetrabajo se comparan las versiones secuencial y paralela deAlineaGA, realizando además una comparación de la calidadde las soluciones obtenidas con las que se encuentran con unade las herramientas mas usadas en el alineamiento múltiple desecuencias - ClustalW2. Los resultados de esta comparaciónpermiten sacar conclusiones sobre la eficacia y aplicabilidad delos algoritmos desarrollados.Palabras clave—Alineamiento múltiple de secuencias,algoritmos genéticos, algoritmos genéticos paralelos, MPI,MPI.NET.UI. INTRODUCCIÓNNA de las tareas más comunes en Bioinformática es elalineamiento de secuencias moleculares. Diversosmétodos de modelización biológica dependen de unalineamiento preciso de las secuencias. Entre estos métodosse encuentran la reconstrucción filogenética, los perfiles y lapredicción de estructuras; y se aplican a diversas áreas comogenómica funcional, estudios evolutivos, modelado deestructuras, experimentos de mutagénesis y diseño defármacos [1]. El alineamiento múltiple de secuencias puedeayudar a comparar la relación de estructuras entre lassecuencias estableciendo conexiones entre sus elementos[2]. Un alineamiento organiza las secuencias de manera queindica donde las secuencias son similares, y donde sondiferentes. En las secuencias se pueden introducir espaciospara encontrar regiones de similitud entre ellas. Estos1School of Technology and Management, Computer Science andCommunication Research Centre, of the Polytechnic Institute of Leiria,Portugal (e-mail: fernando.silva@estg.ipleiria.pt).2Dept. Tecnologías Computadores y Comunicaciones, EscuelaPolitécnica, Universidad de Extremadura, Cáceres, Spain (e-mail:{sanperez, jangomez, mavega}@unex.es).espacios se denominan “gaps” y se representan por el signo“-”. Un alineamiento óptimo es el que exhibe el mayornúmero de correspondencias y el menor número dediferencias, pero este alineamiento puede o no puede serbiológicamente significativo [3]. La Fig. 1 muestra unejemplo de un alineamiento múltiple de secuencias.-RLSCSSIFSS--YAMYWVRQAPGL-LTCTVSFDD--YYSTWVRQPPGPEVTCVVSHEDPQVKFNWYVQ-PGFig. 1. Ejemplo de un alineamiento múltiple de secuencias.Actualmente, hay dos métodos importantes para realizarel alineamiento múltiple de secuencias: el métodoprogresivo y el método iterativo. Sin embargo, elalineamiento múltiple de secuencias se puede realizartambién con algoritmos exactos, que intentan encontrar unaalineación óptima o cuasi-óptima dentro de límites biendefinidos. Sin embargo, este procedimiento está muylimitado por la cantidad de recursos informáticos necesariospara alinear un gran número de secuencias [4].Aunque el enfoque progresivo es el adoptado por lamayoría de las herramientas de alineamiento múltiple desecuencias [5], tiene algunas limitaciones. En este método,el alineamiento se construye alineando progresivamentepares de secuencias según su similitud. Si el cálculo de lasimilitud es incorrecto, tendrá consecuencias en el resultadofinal, que se agravarán gradualmente mientras mássecuencias se añadan al alineamiento [6]. Uno de losejemplos más visibles basados en este método es ClustalW2.0 [7], que es probablemente el programa de alineamientomúltiple de secuencias más utilizado [8].Por el contrario, los métodos iterativos producen unalineamiento y luego lo refinan durante una serie deiteraciones hasta que no pueden hacerse más mejoras. Estosmétodos intentan optimizar una función de puntuación querefleje eventos biológicos de tal modo que optimizando lapuntuación se llegue a un alineamiento correcto [9]. LosAlgoritmos Evolutivos (AE), como p.e los AlgoritmosGenéticos (AGs), tanto secuenciales como paralelos, sonejemplos de métodos iterativos.AlineaGA [10, 11] es un AE que realiza el alineamientomúltiple de secuencias utilizando un AG que incorpora aalgunos de sus operadores genéticos un sencillo método deoptimización de búsqueda local. Está disponible en dosversiones: la secuencial y la paralela. La paralela “ParallelJP2011-9

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011AlineaGA” [12] utiliza la implementación MPI.NET [13]del protocolo de comunicaciones MPI (Message PassingInterface) [14]. A continuación presentamos unacomparación de ambas versiones del algoritmo con el fin desacar conclusiones sobre su eficacia. Aunque en este estudiono se tienen en cuenta los costes de comunicación, ya que secentra en la calidad de las soluciones obtenidas, se presentatambién una comparación entre los tiempos de ejecución delas diferentes versiones del algoritmo. Con el fin decomprender mejor la contribución de AlineaGA en laobtención de alineamientos múltiples de secuencias, tambiéncomparamos la calidad de las soluciones encontradas porambas versiones con las encontradas por ClustalW 2.0 [7] en8 conjuntos de datos o configuraciones de test de BAliBASE[15].II. ANTECEDENTESEn esta sección se introduce la terminología de losconceptos más relevantes relacionados con nuestrapropuesta para resolver el problema del alineamientomúltiple de secuencias.A. Algoritmos GenéticosLos AEs son métodos de búsqueda inspirados en laselección natural y la supervivencia del más apto en elmundo biológico. Se diferencian de las técnicas mástradicionales de optimización porque realizan la búsqueda deuna población de soluciones, y no de una única solución.Los AGs son una categoría de métodos evolutivos debúsqueda que se centran en la optimización de problemascombinatorios. Son procesos de búsqueda robustos yadaptativos, inspirados en eventos naturales, como laherencia genética y la lucha Darwiniana por la supervivencia[16].En los AGs, una población de tamaño fijo de solucionesevoluciona mediante una serie de iteraciones con operadoresgenéticos, como el cruce y la mutación. El cruce combina lascaracterísticas de la población intercambiando segmentoscorrespondientes de dos individuos escogidosaleatoriamente (los padres), y forma dos nuevos individuossimilares (hijos). La mutación por lo general aplica uncambio aleatorio en una solución. Ambos operadores seutilizan con una tasa de probabilidad definida de antemano[17]. Para poder realizar esta evolución, cada solución tieneasociado un valor o “fitness” que refleja su aptitud y que sepuede utilizar para determinar qué soluciones se puedenutilizar para producir nuevos individuos.B. Algoritmos Genéticos ParalelosAunque la paralelización se utiliza para acelerar laejecución de los algoritmos, en el caso de los AGs tambiénse traduce en una mejora de la eficiencia y eficacia comoconsecuencia de su población estructurada [18]. AGs demúltiples poblaciones o múltiples-demes, hacen uso dediferentes subpoblaciones independientes que intercambiansoluciones de vez en cuando. Este intercambio de solucionesse denomina migración y está limitado por diversosparámetros, tales como tasa de migración, que es el númerode individuos que se intercambian entre las subpoblaciones,intervalo de la migración, que indica cuando se realiza lamigración, y topología, que establece como se realiza laconexión entre las subpoblaciones [19].Esta clase de algoritmos, también denominados AGsdistribuidos [18], AGs de grano grueso [19], o AGsparalelos basados en islas (IPGA) [17, 19], son fáciles deimplementar, ya que ejecutan varios AGs independientessimultáneamente, añadiendo subrutinas que se encarguen dela migración. Estos algoritmos paralelos se pueden ejecutaren sistemas multiprocesadores e incluso en sistemasmonoprocesador utilizando tecnologías MPI [14].III. ALGORITMOS ALINEAGAEsta sección explica brevemente las características yoperaciones que realizan los algoritmos desarrollados. Elapartado A) introduce la versión secuencial del AlgoritmoAlineaGA, explicando además características comunes aambas versiones, secuencial y paralela. En el apartado B) seexplican las particularidades de la versión paralela, haciendoénfasis en las cuestiones de migración.A. AlineaGA – Un AE para Alineamiento Múltiple deSecuenciasAlineaGA utiliza una población de soluciones candidatasque evoluciona a lo largo de un determinado número degeneraciones. Los individuos de esta población sonalineamientos múltiples de secuencias, como el representadoen la Fig. 1, donde puede observarse que utiliza una versiónno codificada de los cromosomas. Cada solución se generamediante la colocación de cada secuencia en una línea delarray e insertando a continuación “gaps” de forma aleatoriahasta conseguir que todas las secuencias tengan la mismalongitud. Los pasos que se realizan posteriormente consistenen seleccionar, combinar y mutar las soluciones durante unnúmero definido de generaciones para producir nuevosindividuos (soluciones).En cada generación, todos los individuos de cadasubpoblación se evalúan para determinar su aptitud o“fitness”. Para ello, se utiliza la función suma de pares [20]que se ilustra en (1). También se utiliza una matriz depuntuación (PAM 350) [21] para determinar el costo delalineamiento de cada pareja de aminoácidos. Se emplea, unapenalización de -10 [11] cuando un aminoácido se alineacon un “gap”.n 1 n∑∑−i= 1 j=i+1Sum − of − Pairs = ScoringMatrix(l i, lj) (1)La selección de los padres se realiza según su aptitud, locual significa que los padres más aptos tienen másprobabilidades de reproducirse por medio de una operaciónde cruce. Se ha adoptado una aproximación elitista, según laJP2011-10

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cual se mantiene el 40% de las mejores soluciones de cadageneración. La selección de los restantes individuos serealiza utilizando “torneos” de tamaño 2. Según estemétodo, se cogen aleatoriamente dos individuos de lapoblación y el que tiene mayor aptitud (“fitness”), i.e.puntuación, se selecciona para el cruce. Si ambos candidatostienen la misma aptitud se selecciona el que presente elmayor número de columnas totalmente idénticas.La recombinación de los individuos se realiza utilizandotres operadores de cruce, que se eligen aleatoriamente con lamisma probabilidad de selección. En [11] se da unadescripción detallada de estos operadores.Las mutaciones se producen, introduciendo nuevascaracterísticas en la población, aumentando así la diversidad.Con el fin de no modificar las secuencias y, por tantoinvalidar el alineamiento, los cambios sólo se pueden hacercon los “gaps” y no con los aminoácidos. Por lo tanto,insertar o desplazar “gaps” son las formas más efectivas deintroducir nuevos patrones en la población. Tanto AlineaGAcomo Parallel AlineaGA hacen uso de seis operadores demutación [22]. Cada operador de mutación se selecciona alazar y se aplica a un individuo de acuerdo con laprobabilidad de mutación definida. Si la solución mutada espeor que la original, se puede aplicar una nueva mutación alindividuo mutado. Este proceso puede repetirse hasta quemejore la aptitud, o durante un cierto número de intentospreviamente definidos por el usuario. En nuestros tests, sepermiten un máximo de 2 intentos, lo cual representa unbuen compromiso entre velocidad y robustez, sintransformar completamente los individuos de una solageneración.Se utilizan dos tipos diferentes de operadores demutación: los estocásticos y los avariciosos, que hemosdenominado operadores inteligentes (“Smart”). Losoperadores estocásticos se basan en versiones de estosoperadores ya descritas en la literatura: [23-25].Los operadores inteligentes mejoran las versionesestocásticas hibridándolas con una sencilla estrategia debúsqueda local. Las mutaciones inteligentes sólo producenla mutación si el alineamiento mutado presenta una aptitud opuntuación mejor que la del el original. Estos operadoresutilizan una probabilidad de dirección que determina lainserción/desplazamiento de los “gaps” al principio o al finaldel alineamiento. Esta probabilidad se establece inicialmentepara el centro del alineamiento y se actualiza de acuerdo alos resultados, aumentando la probabilidad deinsertar/desplazar los “gaps” a la izquierda o la derecha delalineamiento. Cada operador intenta mejorar el alineamientoun máximo de 3 veces. En [22] se da una descripción masdetallada de estos operadores.B. Parallel AlineaGAParallel AlineaGA es un IPGA, en el que cadasubpoblación de un número fijo de soluciones evoluciona deforma independiente, intercambiando periódicamenteindividuos entre sí mediante de un proceso denominadomigración. La representación de soluciones, los mecanismosde selección, la forma de evaluación, así como lasoperaciones de cruce y mutación son iguales que losutilizados por AlineaGA. Sin embargo, la diferencia radicaen su proceso de migración.Cada subpoblación se asigna a un proceso diferente quepuede ser ejecutado en procesadores distintos. Se utiliza unatopología en estrella para conectar los procesos. En estatopología, en cada intervalo de migración definido, cadaproceso esclavo envía su mejor individuo al procesoprincipal o maestro y el proceso maestro envía su mejorindividuo a cada proceso esclavo. Estos intercambiossustituyen los peores individuos de cada subpoblación,manteniendo su tamaño sin cambios. Este proceso se realizade forma asíncrona, para evitar los cuellos de botellaoriginados por los procesos más lentos. El procedimiento serepite durante un número fijo de generaciones para encontrarla mejor solución posible entre todas las subpoblaciones.Para llevar a cabo la comunicación entre lassubpoblaciones, se ha utilizado MPI.NET [13] la aplicacióndel protocolo MPI [14]. Esta elección está relacionada con laespecificidad de la plataforma .NET utilizada para ejecutarel algoritmo.IV. TESTS Y RESULTADOSEn esta sección se realiza una breve comparación de losresultados obtenidos con AlineaGA y Parallel AlineaGA.Hemos realizado tests para comprobar la eficiencia deAlineaGA y Parallel AlineaGA con ocho configuraciones detest “Reference 1” de BAliBASE [15]. Cuatro de lasconfiguraciones utilizadas (1aho, 1fmb, 1plc, 1dox)presentan más del 35% de coincidencias entre sussecuencias y las otras cuatro (1fjlA, 1hpi, 1pfc, 1ycc)presentan entre un 20% y un 40% de coincidencias. Paraevaluar el rendimiento de AlineaGA y Parallel AlineaGAhemos determinado el valor de la función de aptitud (sumade-pares)para cada una de las configuraciones de testmencionadas.Debido a la naturaleza estocástica del algoritmo, lascomparaciones se han realizado teniendo en cuenta la mediade los resultados obtenidos en 30 ejecucionesindependientes de cada versión de AlineaGA con cadaconfiguración de test. Además, en el caso de ParallelAlineaGA y con la finalidad de entender mejor el efecto delnúmero de islas en los resultados finales, cada configuraciónde test se ha ejecutado con modelos de 4 y 8 islasrespectivamente.En esta sección también se hace una comparación entrelos resultados obtenidos con AlineaGA, Parallel AlineaGA,ClustalW2 [7] (http://www.ebi.ac.uk/Tools/clustalw2), conlas configuraciones de test de BAliBASE [15].Las dos versiones del algoritmo, secuencial y paralela, sehan escrito en C#, usando .NET Framework 4. Las versionesparalelas usan MPI.NET [13] para la comunicación entre losJP2011-11

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011diferentes procesos. Todas los tests se hicieron en un 2.4GHz CPU Core2 Quad Q6600, con 2 GB de memoria,Windows XP Professional, Service Pack 3.A. Configuraciones de TestA continuación, se comparan los resultados de lasdiferentes versiones utilizadas para resolver el problema delalineamiento múltiple de secuencias utilizando técnicas deComputación Evolutiva.Los parámetros utilizados para las diferentes versiones delalgoritmo son similares y se eligieron en base a los trabajosrealizados con AlineaGA [11] y Parallel AlineaGA [12].Todos los operadores de cruce y mutación se escogieronaleatoriamente con la misma probabilidad de selección encada generación. Sin embargo, el número de generacionesnecesarias para obtener las soluciones es diferente para cadaversión del algoritmo como se indica en la Tabla I.TABLA ICONFIGURACIONES DE TESTParámetros AlineaGA Parallel AlineaGATamaño de Población 100 -Tamaño Subpoblación - 100Intervalo de Migración - 100 generacionesMatriz de Puntuación PAM350 PAM350Método de selección Torneo (Tamaño 2) Torneo (Tamaño 2)Probabilidad de Cruce 0.8 0.8Probab. de Mutación 0.4 0.4Generaciones 2000 1000B. ResultadosA continuación se presentan los resultados de los testsrealizados, teniendo en cuenta el rendimiento global y laevolución de la población.1) Rendimiento: La Tabla II que resume los resultadosobtenidos con AlineaGA y Parallel AlineaGA, permitecomparar la calidad de las soluciones obtenidas con lacalidad de las configuraciones de test de BAliBASE [15] ycon la de las soluciones obtenidas con ClustalW2 [7] para lasmismas configuraciones de test. La columna “Suma de Paresde BAliBASE” presenta la suma de pares de lasconfiguraciones de test de referencia. La columna “Suma dePares de ClustalW2” muestra el valor de la suma de pares delos resultados obtenidos con ClustalW2 [7]. Estos valores seobtuvieron usando la matriz PAM 350 y una penalización deapertura de “gaps” de -10. Las columnas “Suma de Pares deAlineaGA” y “Suma de Pares de Parallel AlineaGA”presentan el promedio de todos los resultados obtenidos enlas 30 ejecuciones de las dos versiones de AlineaGA.Al comparar los alineamientos de BAliBASE con lassoluciones encontradas con ClustalW2, se observa queClustalW2 presenta mejores soluciones para lasconfiguraciones de test: 1fmb, 1fjlA y 1pfc. Para lasconfiguraciones restantes ClustalW2 no alcanza los valoresde las configuraciones de referencia. Con respecto a lassoluciones obtenidas con AlineaGA, sólo lasconfiguraciones 1dox, 1fjlA y 1hpi no superan el valor de lasuma de pares conseguido por BAliBASE. Para las demásconfiguraciones de test AlineaGA se comporta mejor.Con respecto a ClustalW2, AlineaGA presenta mejoresvalores de la suma de pares para las configuraciones: 1fmb,1dox y 1fjlA. Sin embargo al comparar los resultados deClustalW2 con los obtenidos por Parallel AlineaGA seobserva que el modelo de 4 islas se comporta mejor paratodas las configuraciones excepto para: 1dox y 1fjlA, y queel modelo de 8 islas tiene un mejor comportamiento en todaslas configuraciones excepto en: 1fjlA. El modelo de 8 islasde Parallel AlineaGA no supera los valores de lasconfiguraciones de test 1dox, 1fjlA y 1hpi de BAliBASE.Al comparar los resultados de AlineaGA con los deParallel AlineaGA resulta obvio que con las versionesparalelas se obtienen soluciones de mayor calidad. Esto sedebe principalmente a que cuando se utilizan variaspoblaciones, se tiene más capacidad para explorar un mayorárea del espacio de búsqueda, además se aprovechan mejorlos resultados de la búsqueda gracias la migración. Elmodelo de 4 islas presenta mejores resultados que la versiónsecuencial para todas las configuraciones de test.Considerando globalmente la versión paralela de AlineaGAse puede constatar que la configuración de 8 islas logramejores resultados que la configuración de 4 islas. Sinembargo, aunque en los tests realizados no se han tenido encuenta los gastos de comunicación, se observa que laconfiguración de 8 islas tiene el inconveniente de mayorestiempos de ejecución como puede observarse en la Fig. 2.TABLA IIRESULTADOS DE LOS TESTSSuma de Pares deConfiguraciones Suma de Pares Suma de Pares Suma de ParesParallel AlineaGAde Test de BAliBASE ClustalW2 de AlineaGA4 Islas 8 Islas1aho 2015 1644 2016.89 2145.67 2207.771fmb 1706 1780 1769.63 1859.80 1876.231plc 2403 2387 2404.83 2537.53 2590.571dox 1234 1020 833.57 974.40 1162.031fjlA 1740 1770 1366.33 1558.17 1710.031hpi 1208 1087 1142.10 1190.37 1199.431pfc 2216 2231 2422.50 2501.80 2533.331ycc 963 798 971.23 1099.33 1152.20“Suma de Pares de AlineaGA” y “Suma de Pares de Parallel AlineaGA” se obtuvieron por promedio de la suma-de-pares obtenida en 30 ejecuciones deAlineaGA y Parallel AlineaGA, respectivamente.JP2011-12

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Al observar el valor medio de la suma de pares de lapoblación, se puede comprobar que cada isla realiza unabúsqueda diferente, pero su comportamiento es similarcuando las mejores soluciones en todas las subpoblacionescomienzan a ser semejantes.Fig. 2. Comparación de los tiempos de ejecución de AlineaGA y ParallelAlineaGA (en milisegundos).Al comparar los tiempos de ejecución de las diferentesversiones de AlineaGA se observa que cuando se considerael modelo paralelo de 8 islas los tiempos de ejecución sonsimilares a los de su versión secuencial; sin embargo, elmodelo de 4 islas presenta mejores tiempos de ejecución quela versión secuencial para todas las configuraciones de test.No obstante, la obtención de resultados de más calidadconseguidos con el modelo de 8 islas justifica el tiempoextra que necesita para encontrar las soluciones. Lasversiones paralelas de AlineaGA suponen una mejora tantoen la calidad de las soluciones como en los tiempos deejecución (especialmente el modelo de 4 islas) con respectoa su versión secuencial.2) Evolución de la Población: Para ilustrar las diferenciasde comportamiento de las versiones paralelas de AlineaGAcon respecto a la versión secuencial, analizaremos laevolución de la población con una de las configuraciones detest.Las Figuras 3, 4 y 5 comparan la evolución de la aptituddel mejor individuo y la aptitud media de toda la poblaciónpara la configuración de test 1aho en AlineaGA y en lasconfiguraciones de 4 y 8 islas de Parallel AlineaGA. Lasleyendas “Best” se refieren la evolución de la mejor soluciónencontrada. Las leyendas “Pop” se refieren al valor mediode todos los individuos de la población.Al comparar el comportamiento de la población entre lasversiones paralelas y la versión secuencial, está claro que ladiversidad que existe en la población de AlineaGA no escomparable con la de las distintas islas de las versionesparalelas de AlineaGA. Esta diversidad permite quesoluciones similares a las alcanzadas por AlineaGA al finalde la última generación, se puedan conseguir en torno a lageneración 500 en la versión de 4 islas de AlineaGA y entorno a la generación 400 en la versión de 8 islas deAlineaGA. La reducción del número de generacionescontribuye a la reducción de los tiempos de ejecución.Si consideramos sólo la evolución de la población en lasversiones paralelas del algoritmo, se puede observar que,debido a la migración de las mejores soluciones entre lasdiferentes islas, las series que representan la mejor solucióntienen un comportamiento análogo, acabando porsuperponerse tan pronto como en una de las islas se generensoluciones de alta calidad.Fig. 3. Mejor solución de AlineaGA y evolución de la población con laconfiguración de test 1aho.Fig. 4. Mejor solución de Parallel AlineaGA con 4 islas y la evolución de lapoblación con la configuración de test 1aho.Fig. 5. Mejor solución de Parallel AlineaGA con 8 islas y la evolución de lapoblación con la configuración de test 1aho.V. CONCLUSIONESAlineaGA puede encontrar alineamientos múltiples desecuencias de calidad. Sin embargo, su rendimiento losupera Parallel AlineaGA, tanto en calidad de las solucionesencontradas, para los modelos de 4 y 8 islas, como entiempos de ejecución, para el modelo de 4 islas. Sinembargo, ambas versiones pueden encontrar solucionesinteresantes que en la mayoría de los casos testeados, sonmejores que las que se encuentran con ClustalW2 [7].JP2011-13

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011El número de islas en el modelo paralelo es tambiéndecisivo para aumentar la robustez de los resultados.Mientras más islas tenga el modelo se alcanzaran mejoressoluciones que serán más consistentes. Sin embargo esplausible que los costos de comunicación crezcan con elnúmero de islas de los modelos, por lo que este número nodebe descuidarse.AGRADECIMIENTOSEste trabajo ha sido parcialmente soportado por elInstituto Politécnico de Leiria (Portugal) y por el proyectoMSTAR de referencia TIN 2008-06491-C04-04/TIN(MICINN España).REFERENCIAS[1] J. D. Thompson and O. Poch, "Multiple sequence alignment as aworkbench for molecular systems biology," Current Bioinformatics,vol. 1, pp. 95-104, 2006.[2] J. Horng, L. Wu, C. Lin, and B. Yang, "A genetic algorithm for multiplesequence alignment," Soft Computing, vol. 9, pp. 407-420, June 2005.[3] S. K. Pal, S. Bandyopadhyay, and S. S. Ray, "Evolutionary computationin bioinformatics: A review," IEEE Transactions on Systems Man andCybernetics Part C-Appl and Rev, vol. 36, pp. 601-615, September2006.[4] O. Lecompte, J. D. Thompson, F. Plewniak, J.-C. Thierry, and O. Poch,"Multiple alignment of complete sequences (MACS) in the postgenomicera," Gene, pp. 17-30, March 2001.[5] C. Notredame, "Recent evolutions of multiple sequence alignmentalgorithms," PLoS Comput. Biol, vol. 3, p. e123, 2007.[6] C. Notredame, D. G. Higgins, and J. Heringa, "T-Coffee: A novelmethod for fast and accurate multiple sequence alignment," Journal ofMolecular Biology, vol. 302, pp. 205-17, 2000.[7] M. A. Larkin, G. Blackshields, N. P. Brown, R. Chenna, P. A.McGettigan, H. McWilliam, F. Valentin, I. M. Wallace, A. Wilm, andR. Lopez, "Clustal W and Clustal X version 2.0," Bioinformatics, vol.23, p. 2947, 2007.[8] R. C. Edgar and S. Batzoglou, "Multiple sequence alignment," CurrentOpinion in Structural Biology, vol. 16, pp. 368-373, 2006.[9] T. Lassmann and E. L. L. Sonnhammer, "Quality assessment ofmultiple alignment programs," FEBS Letters, vol. 529, pp. 126-130,2002.[10] F. J. M. Silva, J. M. Sánchez Pérez, J. A. Gómez Pulido, and M. Á.Vega Rodríguez, "AlineaGA - A Genetic Algorithm with Local SearchOptimization for Multiple Sequence Alignment," Applied Intelligence,pp. 1-9, 2009.[11] F. J. M. Silva, J. M. Sánchez Pérez, J. A. Gómez Pulido, and M. Á.Vega Rodríguez, "An Evolutionary Approach for Performing MultipleSequence Alignment," in WCCI 2010 IEEE World Congress onComputational Intelligence Barcelona, Spain, 2010, pp. 992-998.[12] F. J. M. Silva, J. M. Sánchez Pérez, J. A. Gómez Pulido, and M. Á.Vega Rodríguez, "Parallel AlineaGA: An Island Parallel EvolutionaryAlgorithm for Multiple Sequence Alignment," in SoCPaR 2010 -International Conference on Soft Computing and Pattern Recognition,Cergy Pontoise, Paris, France, 2010, pp. 279-284.[13] D. Gregor and A. Lumsdaine, "Design and implementation of a highperformanceMPI for C# and the common language infrastructure," inProceedings of the 13th ACM SIGPLAN Symposium on Principles andpractice of parallel programming, Salt Lake City, USA, 2008, pp. 133-142.[14] W. Gropp, E. Lusk, and A. Skjellum, "Using MPI: portable parallelprogramming with the message passing interface," 1999.[15] J. D. Thompson, F. Plewniak, and O. Poch, "BAliBASE: a benchmarkalignment database for the evaluation of multiple alignment programs,"Bioinformatics, vol. 15, pp. 87-88, 1999.[16] Z. Michalewicz, Genetic algorithms + data structures = evolutionprograms - Third, Revised and Extended Edition, 3 ed.: Springer, 1996.[17] L. A. Anbarasu, P. Narayanasamy, and V. Sundararajan, "Multiplemolecular sequence alignment by island parallel genetic algorithm,"Current Science, vol. 78, pp. 858-863, April 2000.[18] E. Alba and J. M. Troya, "A survey of parallel distributed geneticalgorithms," Complexity, vol. 4, pp. 31-52, 1999.[19] E. Cantú-Paz, "A survey of parallel genetic algorithms," CalculateursParalleles, Reseaux et Systems Repartis, vol. 10, pp. 141-171, 1998.[20] M. Murata, J. S. Richardson, and J. L. Sussman, "Simultaneouscomparison of three protein sequences," Proceedings of the NationalAcademy of Sciences of the United States of America, vol. 82, p. 3073,1985.[21] M. O. Dayhoff, R. M. Schwartz, and B. C. Orcutt, "A Model ofEvolutionary Change in Proteins," in Atlas of Protein Sequence andStructure. vol. 5: National Biomedical Research Foundation, 1978, pp.345-352.[22] F. J. M. Silva, J. M. Sánchez Pérez, J. A. Gómez Pulido, and M. Á.Vega Rodríguez, "Optimizing Multiple Sequence Alignment byImproving Mutation Operators of a Genetic Algorithm," in ISDA '09Ninth International Conference on Intelligent Systems Design andApplications, 2009, pp. 1257-1262.[23] J.-T. Horng, C.-M. Lin, B.-J. Liu, and C.-Y. Kao, "Using GeneticAlgorithms to Solve Multiple Sequence Alignments," in Proceedings ofthe Genetic and Evolutionary Computation Conference (GECCO-2000), Las Vegas, Nevada, USA, 2000, pp. 883-890.[24] C. Notredame, E. A. O'Brien, and D. G. Higgins, "RAGA: RNAsequence alignment by genetic algorithm," Nucleic Acids Research, vol.25, pp. 4570-4580, 1997.[25] C. Wang and E. J. Lefkowitz, "Genomic multiple sequence alignments:refinement using a genetic algorithm," BMC Bioinformatics, vol. 6,August 2005.JP2011-14

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evolución Diferencial OpenMP+MPI en RedesÓpticas WDMÁlvaro Rubio-Largo 1 , Miguel A. Vega-Rodríguez 1 , Juan A. Gómez-Pulido 1 yJuan M. Sánchez-Pérez 1Resumen—Hoy en día, la multiplexación por división de longitudde onda (Wavelength Division Multiplexing oWDM) es la tecnología más utilizada para explotarel enorme ancho de banda presente en las redesópticas. Sin embargo, cuando es necesario estableceruna conexión entre un nodo origen y un nodo destino,el problema de enrutamiento y asignación delongitud de onda (Routing and Wavelength Assignmento RWA) aparece. En este trabajo se proponeuna versión híbrida OpenMP+MPI de la EvoluciónDiferencial con Torneos de Pareto (DEPT) para resolverel problema RWA. Hemos estudiado el comportamientode esta versión híbrida de la EvoluciónDiferencial multiobjetivo, con una versión del algoritmoDEPT que únicamente utiliza MPI. En este estudiohemos utilizado la topología real Nippon Telegraphand Telephone (NTT, Japón) y un clúster homogéneocompuesto por 16 nodos multi-núcleo, cadanodo con 8 núcleos (un total de 128 núcleos). Trasrealizar distintos experimentos con 2, 4, 8, 16, 32,64 y 128 núcleos, podemos concluir que la versiónOpenMP+MPI del algoritmo DEPT es altamenteparalelizable, obteniendo una eficiencia media superioral 95%.Palabras clave— Híbrido OpenMP+MPI, EvoluciónDiferencial, Optimización Multiobjetivo, ProblemaRWA, Redes Ópticas.I. IntroducciónEl número de usuarios que utilizan las redesde datos ha crecido de manera exponencial enlos últimos años. Debido a que el ancho debanda de nuestras redes actuales no es suficientepara satisfacer este crecimento exponencial, surge lanecesidad de utilizar fibra óptica.La clave para explotar el enorme ancho de bandade este tipo de redes es introducir concurrencia enlas transmisiones de datos. Este es precisamenteel objetivo de la tecnología de Multiplexación porDivisión de Longitud de Onda (en inglés, WavelengthDivision Multiplexing o WDM), dividir un enlacede fibra óptica en diferentes canales o longitudes deonda [1]. Cuando surge la necesidad de estableceruna conexión entre un nodo origen y un nododestino, aparece un problema de enrutamiento yasignación de longitud de onda. Éste, es conocidoen la literatura como Routing and WavelengthAssignment (RWA) problem.Dado que el problema RWA es un problema deOptimización Multiobjetivo (MOOP) [2], en estetrabajo decidimos utilizar un algoritmo evolutivomultiobjetivo para resolver el problema RWA. Elalgoritmo elegido es la Evolución Diferencial con1 Dpto. Tecnología de Computadores y Comunicaciones,Grupo de Investigación ARCO, Universidad de Extremadura,e-mail: {arl, mavega, jangomez,sanperez}@unex.esTorneos de Pareto [3]. En este trabajo presentamosuna versión paralela de grano fino del algoritmoDEPT y el uso de un clúster multi-núcleo parareducir el tiempo que emplea el algoritmo DEPTen obtener soluciones de calidad. Para conseguireste objetivo, hemos diseñado una versión híbridaOpenMP+MPI de la Evolución Diferencial.Hemos estudiado el comportamiento de estaversión híbrida OpenMP+MPI del algoritmo DEPT,con una versión del mismo que únicamente utilizaMPI, con el fin de demostrar el alto rendimiento denuestra propuesta. En este estudio hemos utilizadola topología real Nippon Telegraph and Telephone(NTT, Japón) y un clúster homogéneo compuestopor 16 nodos multi-núcleo, cada nodo con 8 núcleos(un total de 128 núcleos). Tras numerosos experimentoscon distinto número de núcleos (2, 4, 8,16, 32, 64 y 128), podemos concluir que la versiónOpenMP+MPI del algoritmo DEPT obtiene unaalta eficiencia media (superior al 95%).El resto del artículo se organiza como sigue. Unadefinición formal del problema RWA se presentaen la Sección 2. En la Sección 3 se decribedetalladamente la versión Híbrida OpenMP+MPI dela Evolución Diferencial con Torneos de Pareto. Unestudio experimental exhaustivo de la metaheurísticaparalela se muestra en la Sección 4. Por último,las conclusiones y líneas futuras se muestran en laSección 5.II. Definición Formal del Problema RWAEn este trabajo, una red óptica se representa comoun grafo dirigido G = (V, E, C), donde V es elconjunto de nodos, E es el conjunto de enlaces entrenodos y C es el conjunto de longitudes de ondadisponibles en cada enlace óptico de E.• (i, j) ∈ E : Enlace óptico desde el nodo i al nodoj; i, j ∈ V .• c ij ∈ C : Número de longitudes de onda distintaspor enlace (i, j).• u = (s, d) : Demanda unicast u con nodo origens y nodo destino d, donde s, d ∈ V .• U : Conjunto de demandas unicast.: Longitud de Onda λ asignada a u en (i, j).• u λ i,j• l u : Conjunto de enlaces entre un nodo origen s uy un nodo destino d u ; con la correspondiente λasignada en cada enlace (i, j).• L u : Solución al problema RWA considerando elconjunto de demandas U.JP2011-15

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.Ejemplo ilustrativo del problema RWADebemos tener en cuenta que L u = {l u — l u esel conjunto de enlaces con su correspondiente λ asignada}. Utilizando la definición anterior, el problemaRWA puede ser tratado como un Problema de OptimizaciónMultiobjetivo (Multiobjective OptimizationProblem, MOOP) [2], el cual trata de encontrarla mejor solución L u que minimice simultáneamentelas siguientes funciones objetivo:1. Número de Saltos:y 1 = ∑ ∑u∈U (i,j)∈l uΦ j{ } (1)Φj = 1 si (i, j) ∈ ldondeuΦ j = 0 si en otro caso2. Número de Conmutaciones de Longitudes deOnda (λ):y 2 = ∑ ∑u∈U i∈V ϕ j{ } (2)ϕj = 1 si i ∈ V conmuta λdondeϕ j = 0 si en otro casoAdemás, debemos cumplir la restricción de conflictode longitudes de onda [4]: Dos transmisionesunicast diferentes deben tener diferente longitud deonda si se encuentran en el mismo enlace óptico (i, j).Un ejemplo ayudará a entender la formulación ylas funciones objetivo del problema RWA. Dada latopología de red óptica que aparece en Figura 1,suponer el conjunto de demandas {(0,2), (1,4), (4,0),y (2,3)}; y dos longitudes de onda disponibles en cadaenlace (c ij = 2). Como podemos ver en Figura 1, lasdemandas (0,2), (1,4) y (4,0) no presentan ningunaconversión de longitud de onda; sin embargo, lademanda (2,3) presenta una conversión de longitudde onda en el nodo 4. Además, en Figura 1, sepresentan los cálculos necesarios para obtener elvalor de las funciones objetivo: número de saltos(Y 1 ) y número de conmutaciones de longitud de onda(y 2 ). Aclaramos que la solución presentada (y 1 = 8,y 2 = 1) puede no ser la solución idónea, sin embargo,el objetivo de este ejemplo es ayudar a comprenderla formulación del problema y las funciones objetivodel problema RWA.III. Versión Híbrida OpenMP+MPI de laEvolución DiferencialLa Evolución Diferencial (DE) es un algoritmobasado en población, creado por Rainer Storny Ken Price [5]. Este algorítmo optimiza unproblema manteniendo una población de individuosy generando nuevos individuos mediante un simplemecanismo de cruce y mutación.Algoritmo 1 Pseudocódigo algoritmo DEPT1. P ← GenerarPoblaciónAleatoria(TamañoPoblación)2. EvaluarPoblación(P )3. para g = 0 to MAX-GENERACIONES hacer4. para i = 0 to TamañoPoblación hacer5. x target ← P [i]6. x target ← GenerarIndividuoTrial(x target , S)7. EvaluarIndividuo(x trial )8. /* TORNEO DE PARETO */9. si x trial ≠ x target entonces10. si x target .MOfitness > x trial .MOfitness entonces11. P [i] ← x trial12. sino si x target .MOfitness = x trial .MOfitness entonces13. P ′ ← x target ∪ x trial ∪ SolucionesNoDominadas(P, x trial )14. x target .cd ← DistanciaCrowding(P ′ , x target )15. x trial .cd ← DistanciaCrowding(P ′ , x trial )16. si x target .cd < x trial .cd entonces17. P [i] ← x trial18. fin si19. fin si20. fin si21. fin para22. fin paraEn [3], se presenta una versión multiobjetivodel algoritmo DE. En esta versión se incorpora elJP2011-16

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Versión paralela MPI del algoritmo DEPT(b) Versión paralela OpenMP+MPI del algoritmo DEPTFig. 2.Versiones paralelas de la Evolución Diferencial con Torneos de Pareto (DEPT)concepto de Torneos de Pareto, con el objetivode adaptar la Evolución Diferencial para resolverproblemas multiobjetivo, tales como el problemaRWA. En Algoritmo 1, se muestra el pseudocódigodel algoritmo DEPT. Para una descripción másdetalla de la Evolución Diferencial con Torneos dePareto (DEPT), consultar [3].Dado que el problema RWA es un problema NPcompletoen el que se emplea demasiado tiempoen obtener soluciones de calidad, en este trabajose propone una versión paralela de grano fino delalgoritmo DEPT y el uso de un clúster multinúcleo(el más común hoy en día) para reducir eltiempo de ejecución empleado en este problema decomunicaciones.Por un lado, el Interfaz de Paso de MensajesJP2011-17

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(Message Passing Interface o MPI) tiene la principaldesventaja del excesivo tiempo mal empleado enla comunicación entre los núcleos que disponen dememoria compartida en un clúster multi-núcleo.Por otra parte, la interfaz de programación deaplicaciones para memoria compartida OpenMP nosrestringe ha utilizar los núcleos que compartenmemoria (normalmente no es superior a 8 núcleos,lo cuál no es suficiente [6]).Utilizando ambas tecnologías de forma conjunta(OpenMP+MPI), en este trabajo se propone unaversión híbrida OpenMP+MPI de la EvoluciónDiferencial con Torneos de Pareto, la cuál aprovechalas ventajas de ambas técnicas, obteniendo solucionesde idéntica calidad a las mostradas en [3], pero en untiempo razonable.En Figura 2, presentamos una descripciónilustrativa de cada versión paralela (MPI yOpenMP+MPI). En estos ejemplos, hemos supuestoun clúster homogéneo con 4 nodos (cada nodo con 2núcleos) y un tamaño de población de 16 individuos.Si nos centramos en la versión MPI, ver Figura2(a), para explotar el clúster multi-núcleo es necesariolanzar ocho procesos MPI, uno por cada núcleo.Despúés de esto, el proceso maestro emite a cadaproceso de forma simultánea un mensaje MPI. Estemensaje contiene una copia de la población entiempo t (P t ), ya que es necesaria para generar losnuevos individuos x trial . Cada proceso será capaz deconocer cuantos individuos tendrá que procesar yaque conoce cuantos procesos se encuentran activos(suponemos una distribución homogénea de los individuosde la población entre los procesos). Además,utilizando su propio identificador de proceso, cadaproceso identificará la posición de comienzo. Porejemplo, en Figura 2(a), el proceso con identificador2 comenzará a procesar individuos desde la cuartaposición. Cuando un proceso termina de procesar,éste envía al proceso maestro únicamente los individuosque ha procesado. Finalmente, el proceso maestrocrea la nueva población (P t+1 ) para la siguientegeneración.Por otro lado, la versión OpenMP+MPI, verFigura 2(b), sólo necesita lanzar un proceso MPI porcada nodo del clúster multi-núcleo (cuatro procesosen nuestro ejemplo). La metodología utilizada es lamisma que la explicada anteriormente, sin embargo,una vez que un proceso obtiene su propia copia de lapoblación P t , éste divide la carga de trabajo entre losnúcleos utilizando directivas OpenMP, explotando deesta forma cada nodo del clúster.Como podemos ver, existe una diferencia destacableentre ambas versiones paralelas: la versión MPInecesita el doble de mensajes para explotar el clústermulti-núcleo que la versión OpenMP+MPI, lo quese traduce en el doble de tiempo empleado en comunicacionesentre núcleos, lo que supone una pérdidaconsiderable de rendimiento en este tipo de sistemas.TABLA IMejor configuración encontrada para el algoritmoDEPTDEPTK-caminos-más-cortos (k) 10Tamaño de Población (N) 256Probabilidad de Cruce (CR) 20%Factor de Mutación (F ) 50%Esquema de Selección (S) Best/1/BinIV. Resultados ExperimentalesEn esta sección presentamos varios experimentoscomparando las versiones OpenMP+MPI y MPI dela Evolución Diferencial en un clúster homogéneocompuesto por 16 nodos multi-núcleo, cada nodocuenta con 8 núcleos (un total de 128 núcleos).En este trabajo se ha utilizado una topologíade fibra óptica real, la conocida Nippon Telegraphand Telephone (NTT, Japón), y seis conjuntos dedemandas; para más información acerca de lasinstancias, consultar [7].Las versiones paralelas fueron compiladas utilizandoel compilador gcc 4.1.2 (sin opciones de optimizacióny directivas OpenMP) y MPICH2 v1.0.8.En cada experimento, se han realizado 30 ejecucionesindependientes de 100 generaciones, con el objetivode asegurar cierta relevancia estadística. Losparámetros de configuración del algoritmo DEPT semuestran en Tabla I.En primer lugar, en Tabla II presentamos eltiempo de ejecución del algoritmo DEPT en secuencialpara cada conjunto de datos. Como podemosobservar, la instancia NTT c ij =10, |U|=40 necesitael tiempo más alto, 1229,81 segundos.TABLA IITiempo de Ejecución del algoritmo DEPT (secuencial)en segundosTopología NTTc ij =10, |U|=10 582,05c ij =10, |U|=20 858,98c ij =10, |U|=40 1229,81c ij =8, |U|=10 591,34c ij =8, |U|=20 814,8c ij =8, |U|=30 955,32Con el objetivo de realizar una comparativa justaentre ambas versiones paralelas (OpenMP+MPI yMPI), se han realizado varios experimentos utilizandodiferente número de núcleos: 2, 4, 8, 16, 32,64 y 128. Además, se ha medido por separado eltiempo de comunicación entre procesos y el tiempode computación invertido por cada versión.En Figura 3 se muestran los resultados obtenidospor las heurísticas paralelas para cada conjuntode datos. Como podemos ver, la versión MPIobtiene mayor tiempo de ejecución que la versiónOpenMP+MPI, idependientemente del número denúcleos utilizado. Podemos comprobar que estoJP2011-18

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3.Tiempos de Ejecución de las versiones paralelas del algoritmo DEPT (OpenMP+MPI y MPI)es debido a que la versión MPI invierte muchomás tiempo en comunicaciones entre procesos quela versión híbrida. Además, podemos observar enFigura 3 que la versión OpenMP+MPI no presentatiempo de comunicaciones en los experimentos con2, 4 y 8 núcleos, debido a que esto no es necesarioya que comparten memoria. Con el fin de facilitar lalectura de los gráficos de barra presentados en Figura3, se ha ampliado la zona del gráfico correspondientea los experimentos con 16, 32, 64 y 128 núcleos.Podemos ver que la versión OpenMP+MPI obtieneresultados muy prometedores en todas las instancias.Por ejemplo, en el conjunto de datos NTTc ij =10, |U|=40, con 128 núcleos, la versión híbridaDEPT es capaz de ejecutar 100 generaciones en 11,32segundos, en lugar de 1229,81 segundos en la versiónsecuencial. Esto significa que utilizando la versiónOpenMP+MPI de la Evolución Diferencial con Torneosde Pareto, podemos obtener soluciones de igualcalidad a las presentadas en [3], pero por encima decien veces más rápido.Finalmente, en Figura 4(a) y Figura 4(b) semuestran el valor medio de aceleración y eficienciaobtenido por cada una de las versiones paralelasJP2011-19

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011implementadas en este trabajo.Como podemos ver en Figura 4(a), ambas versionespresentan un comportamiento similar con 2,4 y 8 núcleos, sin embargo, cuando el número denúcleos es incrementado, las diferencias entre ambasheurísticas crecen exponencialmente. De Figura 4(b)podemos extraer las mismas conclusiones: a medidaque aumenta el número de núcleos, la eficiencia dela versión MPI decrece de manera exponencial.Podemos concluir diciendo que el algoritmo DEPTes adecuado para ser paralelizado. Además, teniendoen cuenta que la versión OpenMP+MPI únicamenteacelera la ejecución del algoritmo (obteniendo solucionesde idéntica calidad), es capaz de superar losresultados obtenidos por otras heurísticas publicadasen la literatura ([8] and [9]), como indicamos en [3].de Enrutamiento y Asignación de Longitudes deOnda (RWA). Tras realizar una comparativa entrenuestra versión híbrida y una versión MPI, condistinto número de núcleos: 2, 4, 8, 16, 32, 64 y128, podemos concluir que la versión OpenMP+MPIobtiene resultados muy prometedores (una eficienciamedia de 95%), mientras que en la versión MPI laeficiencia decrece de manera exponencial a medidaque el número de núcleos se incrementa. Deesta forma, utilizando OpenMP y MPI de maneraconjunta para paralelizar el algoritmo multiobjetivoDEPT podemos solucionar el problema RWA en untiempo razonable.Como trabajo futuro, tenemos la intención deaplicar esta versión OpenMP+MPI de la EvoluciónDiferencial a otros problemas de telecomunicaciones,tales como Traffic Grooming. Además, no sedescarta diseñar otros algoritmos evolutivos multiobjetivocon el fin de realizar comparativas derendimiento.AgradecimentosEl presente trabajo ha sido parcialmente financiadopor el Ministerio de Ciencia e Innovación yel FEDER (Fondo Europeo de Desarrollo Regional),bajo el proyecto TIN2008- 06491-C04-04 (proyectoM*). Álvaro Rubio-Largo es becario de investigación(PRE09010) de la Junta de Extremadura (Consejeríade Economía, Comercio e Innovación).(a) Aceleración Media(b) Eficiencia MediaFig. 4. Aceleración y Eficiencia media obtenida por lasversiones paralelas del algoritmo DEPTV. Conclusiones y Trabajo FuturoEn este artículo presentamos una versión HíbridaOpenMP+MPI de la Evolución Diferencial conTorneos de Pareto (DEPT) para resolver el problemaReferencias[1] A. M. Hamad y A. E. Kamal, “A survey of multicastingprotocols for broadcast-and-select single-hop networks,”IEEE Network, vol. 16, pp. 36–48, 2002.[2] K. Deb, Multi-Objective Optimization Using EvolutionaryAlgorithms. New York, NY, USA: John Wiley & Sons,Inc., 2001.[3] A. Rubio-Largo, M. A. Vega-Rodríguez, J. A. Gómez-Pulido, y J. M. Sánchez-Pérez, “A Differential Evolutionwith Pareto Tournaments for solving the Routing andWavelength Assignment Problem in WDM Networks,”Proceedings of the 2010 IEEE Congress on EvolutionaryComputation (CEC 2010), pp. 129–136, 2010.[4] M. Gagnaire, M. Koubaa, y N. Puech, “Network Dimensioningunder Scheduled and Random Lightpath Demandsin All-Optical WDM Networks,” IEEE Journal on SelectedAreas in Communications, vol. 25, no. S-9, pp. 58–67, 2007.[5] R. Storn y K. Price, “Differential Evolution - A SimpleEvolution Strategy for Fast Optimization,” Dr. Dobb,vol. 22, no. 4, pp. 18–24, 1997.[6] A. Rubio-Largo, M. A. Vega-Rodríguez, J. A. Gómez-Pulido, y J. M. Sánchez-Pérez, “Improving optical wdmnetworks by using a multi-core version of differential evolutionwith pareto tournaments,” Distributed Computingand Artificial Intelligence, Springer Berlin / Heidelberg,vol. 79, pp. 629–636, 2010.[7] M. Schaerer y B. Barán, “A Multiobjective Ant ColonySystem for Vehicle Routing Problem with Time Windows,”IASTED International Conference on Applied Informatics,pp. 97–102, 2003.[8] C. Insfrán, D. Pinto, y B. Barán, “Diseño de TopologíasVirtuales en Redes Ópticas. Un enfoque basado en Coloniade Hormigas,” XXXII Latin-American Conference onInformatics 2006 - CLEI2006, vol. 8, pp. 173–195, 2006.[9] A. Arteta, B. Barán, y D. Pinto, “Routing and WavelengthAssignment over WDM Optical Networks: a comparisonbetween MOACOs and classical approaches,” in LANC’07: Proceedings of the 4th international IFIP/ACMLatin American conference on Networking. New York,NY, USA: ACM, 2007, pp. 53–63.JP2011-20

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Paralelización del algoritmo de bi-mezclaJuan F. R. Herrera 1 , Leocadio G. Casado 2 , Inmaculada García 3 y Eligius M. T. Hendrix 4Resumen— Los algoritmos de diseño de mezclas tienencomo objetivo determinar las mezclas de ingredientesque se ajustan a las restricciones de diseñoimpuestas para el producto en cuestión. Estas restriccionespueden ser lineales y/o cuadráticas. Las mezclasdeben ser óptimas, tanto el coste como el númerode ingredientes empleado tiene que ser mínimo. Losfabricantes elaboran una serie de productos a partirde un conjunto dado de materias primas. La escasezen la disponibilidad de estas materias primas introducerestricciones de disponibilidad que alteran la soluciónPareto-óptima. Los autores han desarrolladoalgoritmos de Ramificación y Acotación para resolverproblemas de mezcla en donde la complejidad computacionalse incrementa con la dimensión del producto.Debido a esta complejidad, se abordará el problemade mezcla para la obtención de sólo dos productos.El diseño de mezclas para dos productos es másdifícil que para un único producto porque además deque el diseño de cada producto está sometido a unasrestricciones, el frente de Pareto así como la disponibilidadde materias primas pasa a ser común a ambosproductos. Se debe realizar una combinación finalentre todas las soluciones del primer y el segundoproducto para eliminar las combinaciones de mezclasque no satisfacen los criterios impuestos. El conjuntoresultante puede ser usado como dato de entradadel mismo algoritmo cuando se requieran resultadosmás precisos. El coste computacional de la fase decombinación dependerá del número de elementos delconjunto final de cada producto.Aquí, estudiaremos el coste computacional de lasdiferentes fases del algoritmo de mezcla para dos productosy proporcionaremos versiones hebradas paralas fases más costosas. Los experimentos se han realizadoen una máquina de ocho núcleos con memoriacompartida, usando un problema de tamaño mediopara evitar largos tiempos de ejecución. Los experimentosmuestran que la computación paralela es unaherramienta necesaria para hacer una búsqueda exhaustivaen problemas de grandes dimensiones y demás de un producto.Palabras clave— Memoria compartida, Procesamientoparalelo , Multihebrado, Ramificación y acotación,Optimización global.I. IntroducciónENCONTRAR un diseño robusto y barato paraun producto que satisfaga una serie de restriccionescuadráticas es un problema arduo. Se puedenencontrar descripciones de casos prácticos en [1] y[2], entre otros. En la industria, las compañías puedenutilizar las mismas materias primas para producirvarios productos. Esto complica el proceso debúsqueda de soluciones factibles y robustas si se pretendegarantizar la optimalidad y robustez de la soluciónfinal.1 Dpto. de Arquitectura de Computadores y Electrónica,Univ. Almería, e-mail: juanfrh@ual.es.2 Dpto. de Arquitectura de Computadores y Electrónica,Univ. Almería, e-mail: leo@ual.es.3 Dpto. de Arquitectura de Computadores, Univ. Málaga,e-mail: igarciaf@uma.es.4 Dpto. de Arquitectura de Computadores, Univ. Málaga,e-mail: eligius.hendrix@wur.nl.Los algoritmos de búsqueda exhaustiva para unproblema de diseño de un solo producto son descritosen [3], [4] y [5], mientras que el enfoque para laobtención de dos productos aparece en [6].La Sección I-A describe el problema de mezcla paraun producto y la Sección I-B para dos productos(bi-mezcla). La Sección II describe la versión secuencialdel algoritmo de bi-mezcla y la Sección III describesu modelo paralelo. La Sección IV muestra losresultados computacionales y la Sección V resumelas conclusiones y el trabajo futuro.A. El problema de diseño de un productoEl problema de diseño que nosotros investigamos(Semi-continuous Quadratic Mixture Design Problem,SQMDP) está descrito en [4], donde aparecenrestricciones cuadráticas y semicontinuas. Aquí resumiremoslas principales características del mismo.Las variables x i representan la fracción de la materiaprima i en la mezcla x. El conjunto de posiblesmezclas está matemáticamente definido por elsímplex unitario{}n∑S = x ∈ R n : x i = 1,0; x i ≥ 0 , (1)i=1donde n denota el número de materias primas.El objetivo es encontrar una mezcla x que minimiceel coste del producto, f(x) = c T x, donde el vectorc representa el coste de las materias primas. No sóloel coste del producto debe ser minimizado, sino tambiénel número de materias primas involucradas enla mezcla x dado por ∑ ni=1 δ i(x), donde{1 si xi > 0,δ i (x) =0 si x i = 0.La semicontinuidad de las variables está relacionadacon la dosis mínima aceptable md (minimaldose) de cada materia prima i, de forma que x i = 0ó x i ≥ md. El número de subsímplices resultantes(caras) esn∑( n= 2t)n − 1,t=1donde t denota el número de materias primas en cadasubsímplex. Todos los puntos x en un símplex inicialP u , u = 1, . . . , 2 n − 1, son mezclas del mismo grupode materias primas. El índice u representa el grupode materias primas correspondiente a un símplexinicial P u :n∑u = 2 i−1 δ i (x), ∀x ∈ P u .i=1Los productos deben satisfacer ciertos requisitos.Para problemas de mezcla relativamente sencillos, losJP2011-21

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011x 21,01,0 Una materia primamd0,0mdDos materias primasx 1x 1x2x 3Fig. 1Símplices 2D y 3D sin la región de dosis mínimalímites o restricciones lineales (véase [1], [2] y [7])definen el espacio de búsqueda X ⊂ S.Sin embargo, en la práctica aparecen restriccionescuadráticas [3], [4]. Se define Q como el espacio dondese satisfacen tales restricciones cuadráticas.Además, el resultado debe satisfacer las restriccionescuadráticas cuando aparecen pequeñas variacionesen los porcentajes de la mezcla debido al procesode producción. Dada una mezcla x, se define la robustezde x como R(x) y ésta debe ser mayor o iguala un umbral ε, véase [4].Teniendo en cuenta las consideraciones anteriores,se define SQMDP como:míns.a.f(x), ∑ ni=1 δ i(x)x ∈ X ∩ QR(x) ≥ εEn [3] se describen tests basados en las llamadas✭✭esferas de no factibilidad✮✮, que identifican áreasdonde no se puede encontrar una mezcla factible. En[4] se describe un algoritmo de Ramificación y Acotaciónpara resolver SQMDP usando tests de rechazobasados en restricciones lineales, cuadráticas y de robustez.El problema de encontrar la mejor solución robustase convierte en un problema de Optimización Global,donde resulta complejo garantizar que la solución obtenidaes la global, ya que pueden existir múltiplesóptimos locales y el área factible puede no ser convexao incluso estar dividida en varios compartimentos.En [8] se presentó una versión multihebrada del algoritmopara resolver SQMDP mediante un esquemaAsynchronous Multiple Pool [9], donde se siguió unaestrategia similar a la utilizada en el algoritmo paralelode Optimización Global basado en Aritméticade Intervalos (Local-PAMIGO), publicado en [10].B. El problema de diseño de dos productosEn este artículo, nuestro objetivo es paralelizar elalgoritmo que encuentre las mejores mezclas cuandose pretende diseñar dos productos que compartenmaterias primas. En algunas ocasiones, la industriase enfrenta al problema de la escasez de materiasprimas para los productos que desea elaborar. Esteinconveniente puede ser resuelto mediante el uso deuna dosis mayor de otro ingrediente, aunque esto hagaque la solución óptima para cada producto no seasiempre la solución del problema completo.Tal y como se describe en [6], cada producto tienesu propia demanda y sus propias especificacionesde diseño en forma de restricciones lineales y/ocuadráticas. Una manera común de describir el problemaes identificar un índice j para cada producto,que tiene una cierta demanda D j . La cantidad demateria prima i disponible viene dado por B i . Ahora,la variable de decisión principal x i,j es la fracciónde la materia prima i presente en el producto j.En principio, todos los productos x ∗,j , j = 1, 2,pueden hacer uso de todas las n materias primas;x ∗,j ∈ R n , j = 1, 2. Esto significa que x i,1 y x i,2hacen referencia a fracciones del mismo ingredientepara los productos 1 y 2. Las reservas de materiasprimas se describen a través de las restricciones dedisponibilidad, que vienen dadas por2∑D j x i,j ≤ B i ; i = 1, . . . , n.j=1Por lo tanto, se establece la función de coste deeste problema como:f bi (x ∗,1 , x ∗,2 ) =2∑D j f(x ∗,j ).j=1El otro criterio a minimizar es el número de distintasmaterias primas utilizado en el diseño de losdos productos:ω(x ∗,1 , x ∗,2 ) =n∑δ i (x ∗,1 ) ∨ δ i (x ∗,2 ),i=1donde ∨ denota la operación or bit a bit.Por lo tanto, se define el problema de bi-mezclacomo:mín f bi (x ∗,1 , x ∗,2 ), ω(x ∗,1 , x ∗,2 )s.a. x ∗,1 ∈ X 1 ∩ Q 1 , x ∗,2 ∈ X 2 ∩ Q 2R(x ∗,j ) ≥ ε, j = 1, 2∑ 2j=1 D jx i,j ≤ B i ; i = 1, . . . , nII. Algoritmo para resolver el problemade bi-mezclaResolver el problema de bi-mezcla de una maneraexhaustiva (el método obtiene todas las solucionesJP2011-22

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo 1 B&B1: Inicializar ns := 2 × (2 n − 1)2: Inicializar la lista Λ 1 := {C 1 , . . . , C 2n −1}3: Inicializar la lista Λ 2 := {C 2 n, . . . , C ns }4: Inicializar las listas Q 1 := {} y Q 2 := {}5: while Λ 1 , Λ 2 ≠ {} do6: Seleccionar un símplex C = C k de Λ j7: Evaluar C8: Calcular f L (C) y b L i (C), i = 1, . . . , t k9: if C no puede ser eliminado then10: if C satisface la regla de terminación then11: Almacenar C en Q j12: else13: Dividir C en C ns+1 , C ns+214: C := arg mín{f L (C ns+1 ), f L (C ns+2 )}15: Almacenar {C ns+1 , C ns+2 } \ C en Λ j16: ns := ns + 217: Ir a 718: end if19: end if20: j := (j mód 2) + 121: end while22: return Q 1 y Q 2globales dentro de la precisión establecida) requiereel diseño de un algoritmo de Ramificación y Acotación(Branch & Bound, B&B) específico. Los métodosB&B se caracterizan por cuatro reglas: Ramificación,Selección, Acotación y Eliminación [11], [12]. Sedebe incluir una regla de Terminación para problemasdonde las soluciones vienen determinadas poruna precisión establecida. En los algoritmos B&B,la región de búsqueda es dividida recursivamente enpartes disjuntas (ramificación) sobre las cuales se determinanlos límites de un valor de la solución óptima(acotación). Se define el límite superior global f U comoel valor de la función objetivo de la mejor soluciónε-robusta encontrada hasta ahora. De esta forma, sepueden descartar subconjuntos C k con un límite inferiorfkL de la función objetivo que sean mayores queel límite superior f U , ya que se puede garantizar queno contienen una solución óptima.Una descripción detallada del Algoritmo 1 se puedeencontrar en [6]. El Algoritmo 1 usa una lista detrabajo Λ j y una lista final Q j para cada producto.Aquí resumiremos las características más relevantespara el desarrollo de una versión paralela. Cadasímplex es una región que satisface (1) y sus vérticesson posibles recetas o mezclas (véase la Figura 1).Las reglas B&B usadas en el Algoritmo 1 se describena continuación:Ramificación: Se divide el símplex por el ladomás largo o por aquel lado definido por los vérticesmás caro y más barato.Acotación: Para cada símplex se calculan doslímites inferiores:Coste: f L (C) es el límite inferior del coste de unsímplex C y es proporcionado por el vérticecuyo coste es menor, debido a que los símplicesson convexos y la función de coste es lineal.Cantidad de cada materia prima: b L i (C) es ellímite inferior del uso de cada materia prima ien un símplex C. Este límite inferior es obtenidode manera análoga al límite inferior delcoste.Selección: Se realiza una búsqueda híbrida: combinaciónde la búsqueda en profundidad y labúsqueda ✭✭primero el mejor✮✮. Se selecciona elsímplex más barato, basado en la suma de loscostes de sus vértices, y se realiza una selecciónen profundidad hasta que el símplex no puedaser dividido más (véase el Algoritmo 1, las líneas6, 14 y 17). De esta forma, se pretende reducirel consumo de memoria del algoritmo.Eliminación: Se aplica un conjunto de tests basadosen restricciones lineales, cuadráticas y derobustez a los símplices de un producto, véase[4]. Además, existen otros tests de rechazo dondehay que tener en cuenta ambos productos.Estos tests son los siguientes:Test de disponibilidad: Se defineβi,j L = D j × mín x i (2)x∈C∈Λ j∪Q jcomo el límite inferior de la demanda de materiaprima i en el espacio de búsqueda actualdel producto j. Un símplex C k en el productoj no satisface la restricción de disponibilidadsiD j × b L i (C k ) + β L i,j ′ > B i, (3)donde j ′ hace referencia al otro producto.Test de Pareto: Si se encuentra un par de mezclasfactibles (x, y), siendo x ∈ C ∈ Λ 1 ∪ Q 1e y ∈ C ∈ Λ 2 ∪ Q 2 , con f(x) + f(y) f U ω(x,y) , (5)con x ∈ C k e y ∈ P u,j ′.Terminación: Los símplices no rechazados quealcanzan el tamaño requerido α son almacenadosen Q j .El resultado del Algoritmo 1 es un conjunto demezclas Pareto-óptimas (dentro de la precisión α) ylas listas finales Q j , j = 1, 2, que, además de lasmezclas, contienen los símplices que no han sido rechazados.Durante la ejecución del algoritmo, se actualizanlos límites inferiores βi,j L y ϕL u,j basándose en losJP2011-23

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo 2 Comb1: for j = 1, 2 do2: for all C ∈ Q j no marcado como válido do3: if ∃ C ′ ∈ Q j ′ que satisfaga (6) y (7) then4: Marcar C ′ como válido5: Continuar con el siguiente símplex C{Los restantes C ′ ∈ Q j ′ no son visitados}6: else7: Eliminar C8: end if9: end for10: end forvértices no rechazados, así como el frente de Paretofp U . Por lo tanto, se debe realizar una combinaciónfinal entre los símplices de Q 1 y Q 2 para rechazaraquellos símplices C que no contengan una soluciónPareto-óptima:f L (C) + f L (C ′ ) > f U ω(x,y) ; x ∈ C, y ∈ C′ (6)o no satisfagan la restricción de disponibilidad:b L i (C) + bL i (C′ ) > B i ; i = 1, . . . , n, (7)para todos los símplices C ′ ∈ Q j ′.Esta operación se realiza en el Algoritmo 2. Enla primera iteración (j = 1) del bucle externo, sise encuentra un símplex C ′ ∈ Q 2 que junto con Csatisfaga (6) y (7), C ′ es marcado como válido y noserá procesado en la línea 2 de la siguiente iteración(j = 2).III. Estrategia paralelaEl problema de bi-mezcla se resuelve en dos fases:en la fase B&B se obtienen las listas Q 1 y Q 2con todos los símplices finales para ambos productos(Algoritmo 1) y en la fase Comb se filtran aquellassoluciones no factibles (Algoritmo 2). Como la salidadel Algoritmo 1 es la entrada del Algoritmo 2, laparalelización de ambos algoritmos se puede realizarde forma independiente.El número de símplices finales obtenidos por el Algoritmo1 dependerá de varios factores: la dimensióndel problema, la precisión α de la regla de terminacióny el tamaño de la región factible de cada producto.Experimentos preliminares muestran que estenúmero puede ser relativamente alto. Por lo tanto,el Algoritmo 2 puede ser mucho más costoso computacionalmenteque el Algoritmo 1, siendo la paralelizaciónde esta fase la principal prioridad de esteestudio.El Algoritmo 2 hace uso de un bucle anidado yde las dos listas finales Q 1 y Q 2 . Para cada símplexC ∈ Q j , se busca un símplex C ′ ∈ Q j ′ que satisfaga(6) y (7) de forma que C no se elimine. En el peor delos casos (cuando el símplex C se elimina), la listaQ j ′ se explora completamente (todos los símplicesC ′ ∈ Q j ′ son visitados).Para evitar contención entre hebras en el accesoa la lista enlazada Q j , los símplices no son rechazadossino marcados para ser eliminados posteriormente.De otro modo, la lista podría ser modificada porvarias hebras cuando los símplices son eliminados,haciendo necesario el uso de exclusión mutua.La siguiente notación es necesaria para la descripciónde las distintas estrategias:Pos(C, Q j ): posición del símplex C en Q j .NT h: número total de hebras.Id(T h): identificación de la hebra T h. Los númerosde identificación son consecutivos y comienzanen cero.Existen varias formas de paralelizar el Algoritmo 2mediante el uso de hebras. En este artículo abordaremosdos estrategias:Estrategia 1: Asignar NT h/2 hebras a cada listafinal Q j , j = 1, 2. De este modo, las iteraciones1 y 2 del bucle exterior se llevan a cabo en paralelo,trabajando sobre las dos listas simultáneamente.Esta estrategia requiere que NT h ≥ 2.Cada hebra T h analiza los símplices C ∈ Q jque satisfacen módulo (Pos(C, Q j )/(NT h/2)) =Id(T h). Después de recorrer ambas listas, el borradode los nodos de las listas Q j , j = 1, 2, esrealizado por una hebra para cada lista.Estrategia 2: Asignar NT h hebras al bucle interiorpara llevar a cabo una iteración del bucle exterior.Cada hebra T h analiza los símplices C ∈Q j que satisfacen módulo (Pos(C, Q j )/NT h) =Id(T h). Ahora se pretende procesar sólo una listaen paralelo, borrando los símplices no factiblesantes de procesar la siguiente lista en paralelo.El borrado de los nodos (marcados paratal fin) de Q j es realizado por una sola hebra alfinal de la cada iteración j.La paralelización del Algoritmo 1 es más difícilporque el trabajo computacional pendiente no es conocidode antemano. Un estudio de la predicción deltrabajo en algoritmos de Ramificación y Acotaciónpara problemas de Optimización Global basado enAritmética de Intervalos se puede encontrar en [13].Aunque los autores de este trabajo presentan algoritmosparalelos de Ramificación y Acotación en [10],[14], [15] y [16], estos artículos estudian la paralelizaciónde un único algoritmo B&B. Sin embargo, laresolución del problema de bi-mezcla se puede vercomo dos instancias del mismo algoritmo B&B, unapara cada producto, que comparten β L i,j , ϕL u,j y f U p(véase las Ecuaciones 2, 3, 4 y 5). Cada hebra j trabajacon una lista de trabajo Λ j y una lista final Q j .El problema es determinar cuántas hebras se dedicana cada producto. Aquí, utilizaremos una hebra porproducto para mostrar la dificultad de la fase B&B,dejando para trabajos futuros el uso de un númeromayor de hebras en esta fase.IV. Resultados experimentalesPara evaluar el rendimiento de las distintas versionesdel algoritmo paralelo, se han utilizado unpar de productos de cinco dimensiones, llamadosUniSpec1-5 y UniSpec5b-5. Ambos han sido adaptadosde dos productos de siete dimensiones (UniSpec1JP2011-24

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011y UniSpec5b, respectivamente) tomados de [4], eliminandolos elementos {a i,j ∈ A : i = 6, 7; j = 6, 7}y {b i ∈ b : i = 6, 7} de las restricciones cuadráticas.Este problema ha sido resuelto con una robustezε = √ 2/100, una precisión α = ε y una dosismínima md = 0,03. La demanda de cada productoes D T = (1, 1). La disponibilidad de la materia primauno (RM1) y de RM3 está restringida a 0,62 y0,6, respectivamente; mientras las otras materias notienen limitación alguna.Los algoritmos se han codificado en C y han sidoevaluados en una máquina Dell PowerEdge R810 conun procesador Intel Xeon 1.87 GHz de ocho núcleos,16 GB de RAM y sistema operativo Linux con kernel2.6. Para la creación y el manejo de las hebras, se hautilizado la librería de POSIX Threads. También seha usado la librería LAPACK para algunos cálculosmatemáticos realizados por el algoritmo.La Tabla I proporciona información sobre el esfuerzocomputacional realizado por el algoritmo secuencial(BiBlendSeq) y el algoritmo paralelo (Bi-BlendPar). La Tabla II muestra el tiempo de ejecuciónde BiBlendSeq y BiBlendPar. BiBlendPar utilizaNT h = 2 en la fase B&B. Para la fase Comb,se han usado NT h = 2, 4 y 8 en la Estrategia 1 yNT h = 1, 2, 4 y 8 en la Estrategia 2 (véase la SecciónIII). Los datos mostrados en las Tablas I y II esel valor medio de cinco ejecuciones.La siguiente notación ha sido utilizada para ambastablas:NEvalS: Número de símplices evaluados.NEvalV: Número de vértices evaluados.QLR: Número de símplices rechazados por restriccioneslineales, cuadráticas o de robustez.Pareto: Número de símplices rechazados por eltest de Pareto.Capacity: Número de símplices rechazados porel test de disponibilidad.|Q S |: Número de símplices almacenados en laslistas finales Q j , j = 1, 2.|Q V |: Número de vértices asociados a los símplicesen Q j , j = 1, 2.NT h: Número de hebras creadas.T h j time: El tiempo de ejecución de T h j , j =1, 2, en segundos.Time: El tiempo de ejecución en segundos.Speedup: Aceleración obtenida.La aceleración con respecto al tiempo de ejecuciónde un algoritmo paralelo con p unidades de procesose define como S(p) = t(1)/t(p), donde t(p) es eltiempo de ejecución cuando p unidades de procesoson utilizadas.La fase B&B de BiBlendPar es la misma para lasEstrategias 1 y 2. En esta fase se obtiene una ligeraaceleración en el tiempo de ejecución. No se alcanzauna aceleración lineal debido a la diferencia decomplejidad entre los dos productos: UniSpec1-5 tieneuna región factible definida por unas restriccionescuadráticas de menor complejidad que UniSpec5b-5.En cuanto a la fase Comb, la Estrategia 2 exhi-TABLA IEsfuerzo computacionalFase B&BBiBlendSeq BiBlendParNEvalS 2.536.862 2.537.430NEvalV 168.186 168.299QLR 887.609 888.004Pareto 54.050 54.050Capacity 18.277 18.211|Q S | 308.443 308.465|Q V | 49.317 49.324Fase CombBiBlendSeq BiBlendParPareto 27.284 27.284Capacity 105.499 105.521|Q S | 175.660 175.660|Q V | 24.861 24.861be una buena escalabilidad y aceleración comparadocon BiBlendSeq, obteniéndose una aceleración lineal.Nótese que en esta fase se filtran casi la mitad de lossímplices finales obtenidos en la fase B&B, de ahí sucomplejidad. En cambio, la Estrategia 1 ofrece unaaceleración muy pobre en comparación con la Estrategia2. Uno de los principales motivos es que en laEstrategia 1 no se borran los símplices hasta el final,siendo las listas del mismo tamaño durante toda laejecución del Algoritmo 1. Además, la Estrategia 2evalúa menos comparaciones (evaluación de (6) y posiblemente(7)) entre símplices (una media de 5.421millones) que la Estrategia 1 (5.487 millones).Para el problema de mezcla descrito anteriormente(UniSpec1-5 & UniSpec5b-5), se han encontrado dossoluciones con un número diferente de materias primasinvolucrado: (x ⋆[1]∗,1 , x⋆[1] ∗,2 ) y (x⋆[2] ∗,1 , x⋆[2] ∗,2 ). La primerade ellas hace uso de cuatro materias primas(RM1, RM3, RM4 y RM5):x ⋆[1] =UniSpec1-5 UniSpec5b-5⎛⎞RM1 0,428125 0,146875RM2 0,0 0,0RM3 ⎜ 0,4352344 0,1640625⎟RM4 ⎝ 0,0 0,2328125 ⎠RM5 0,1366406 0,4562500El valor de coste de esta solución es f bi (x ⋆[1]∗,1 , x⋆[1] ∗,2 ) =111,09 + 116,334375 = 227,424375. La segunda solucióninvolucra las cinco materias primas:x ⋆[2] =UniSpec1-5 UniSpec5b-5⎛⎞RM1 0,428125 0,156172RM2 0,0 0,03RM3 ⎜ 0,442344 0,152852⎟RM4 ⎝ 0,0 0,212617 ⎠RM5 0,129531 0,448359El valor de coste de esta solución es f bi (x ⋆[2]∗,1 , x⋆[2] ∗,2 ) =111,033125 + 116,172422 = 227,205547.JP2011-25

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIAceleraciónFase B&B Fase Comb (Estrategia 1) TotalNT h T h 1 T h 2 Time Speedup NT h Time Speedup Time Speedup– – – 7,23 – – 1.991,46 – 1.998,70 –2 0,85 7,09 7,09 1,02 2 1.428,88 1,39 1.436,17 1,392 0,83 7,13 7,13 1,01 4 696,39 2,86 703,52 2,842 0,78 7,00 7,00 1,03 8 338,92 5,88 345,91 5,78Fase B&B Fase Comb (Estrategia 2) TotalNT h T h 1 T h 2 Time Speedup NT h Time Speedup Time Speedup– – – 7,23 – – 1.991,46 – 1.998,70 –2 0,83 7,03 7,03 1,03 1 1.966,51 1,01 1.973,54 1,012 0,81 7,03 7,03 1,03 2 956,01 2,08 936,05 2,082 0,76 6,96 6,96 1,04 4 465,02 4,28 471,98 4,232 0,81 7,00 7,00 1,03 8 228,63 8,71 235,63 8,48V. ConclusionesSe ha estudiado la paralelización de un algoritmocon la finalidad de resolver el problema de diseño dedos productos obtenidos mediante mezcla de materiasprimas para un problema de tamaño medio. Estecaso particular muestra las dificultades de este tipode algoritmos. El algoritmo de bi-mezcla incrementalos retos de la paralelización debido a la utilizaciónde dos algoritmos B&B que comparten información.Además, en los algoritmos de bi-mezcla, se ha de realizaruna combinación de símplices finales después dela fase B&B para descartar regiones no factibles. Estafase de combinación es varios órdenes de magnitudmás costosa computacionalmente que la fase B&B.Por ello, aquí sólo se ha utilizado una hebra por productoen la fase B&B y varias hebras en la fase decombinación. Los resultados muestran aceleracioneslineales en una máquina de ocho núcleos con memoriacompartida cuando se paraleliza el recorrido deuna lista final y después el de la otra, en vez de realizarambos recorridos en paralelo.Nuestra intención es experimentar con problemasde mayor dimensión, intentando reducir su costecomputacional. Otra línea de investigación a continuares desarrollar el algoritmo n-mezcla y su versiónparalela, problema que es de interés para la industria.AgradecimientosEl presente trabajo ha sido parcialmente financiadopor el Ministerio de Ciencia e Innovación(TIN2008-01117), la Junta de Andalucía (P08-TIC-3518) y el Fondo Europeo de Desarrollo Regional(FEDER). Eligius M. T. Hendrix es un investigadorpost-doctoral contratado a través del SubprogramaRamón y Cajal.Referencias[1] J. Ashayeri, A.G.M. van Eijs, and P. Nederstigt, “Blendingmodelling in a process manufacturing: A casestudy,” Eur. J. Oper. Res., vol. 72, no. 3, pp. 460–468,1994.[2] J.W.M. Bertrand and W.G.M.M. Rutten, “Evaluationof three production planning procedures for the use ofrecipe flexibility,” Eur. J. Oper. Res., vol. 115, no. 1, pp.179–194, 1999.[3] L.G. Casado, E.M.T. Hendrix, and I. García, “Infeasibilityspheres for finding robust solutions of blendingproblems with quadratic constraints,” J. Global Optim.,vol. 39, no. 4, pp. 577–593, 2007.[4] E.M.T. Hendrix, L.G. Casado, and I. García, “The semicontinuousquadratic mixture design problem: Descriptionand branch-and-bound approach,” Eur. J. Oper.Res., vol. 191, no. 3, pp. 803–815, 2008.[5] L.G. Casado, I. García, B.G. Tóth, and E.M.T. Hendrix,“On determining the cover of a simplex by spheres centeredat its vertices,” J. Global Optim., pp. 1–11, 2010.[6] J.F.R. Herrera, L.G. Casado, E.M.T. Hendrix, andI. García, “Pareto optimality and robustness in biblendingproblems,” TOP, 2011, Submitted.[7] H.P. Williams, Model Building in Mathematical Programming,Wiley & Sons, Chichester, 1993.[8] L.G. Casado, I. García, J.A. Martínez, and E.M.T. Hendrix,“Shared memory parallel exhaustive search ofepsilon-robust mixture design solutions,” in Volume ofAbstracts of 22nd European Conference on OperationalResearch (EURO XXII), 2007, p. 178.[9] B. Gendron and T.G. Crainic, “Parallel branch-andboundalgorithms: Survey and synthesis,” Oper. Res.,vol. 42, no. 6, pp. 1042–1066, 1994.[10] L.G. Casado, J.A. Martínez, I. García, and E.M.T. Hendrix,“Branch-and-bound interval global optimizationon shared memory multiprocessors,” Optim. Method.Softw., vol. 23, pp. 689–701, 2008.[11] T. Ibaraki, “Theoretical comparisons of search strategiesin branch and bound algorithms,” Int. J. Comput. Inf.Sci., vol. 5, no. 4, pp. 315–344, 1976.[12] L.G. Mitten, “Branch and bound methods: general formulationand properties,” Oper. Res., vol. 18, no. 1, pp.24–34, 1970.[13] J.L. Berenguel, L.G. Casado, I. García, and E.M.T. Hendrix,“On estimating workload in interval branch-andboundglobal optimization algorithms,” J. Global Optim.,2011, Submitted.[14] J.F.S. Estrada, L.G. Casado, and I. García, “Adaptiveparallel interval global optimization algorithms basedon their performance for non-dedicated multicore architectures,”in Parallel, Distributed and Network-BasedProcessing (PDP), 2011 19th Euromicro InternationalConference on, February 2011, pp. 252–256.[15] J.A. Martínez, L.G. Casado, J.A. Alvarez, and I. García,“Interval parallel global optimization with Charm++,”in Applied Parallel Computing. State of the Art in ScientificComputing, Jack Dongarra, Kaj Madsen, and JerzyWasniewski, Eds., vol. 3732 of Lecture Notes in ComputerScience, pp. 161–168. Springer Berlin / Heidelberg,2006.[16] J.F. Sanjuan-Estrada, L.G. Casado, and I. García,“Adaptive parallel interval branch and bound algorithmsbased on their performance for multicore architectures,”J. Supercomput., pp. 1–9, 2011.JP2011-26

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Optimización del Método BST para laReducción de Modelos en ArquitecturasMultinúcleoPablo Ezzatti 1 , Enrique S. Quintana-Ortí 2 and Alfredo Remón 3Resumen— La reducción de modelos es unaherramienta importante en diversas aplicacionescientíficas y de ingeniería. Dada su relevancia, esposible encontrar en la literatura diversos métodospara resolver este problema. Entre ellos destacanlos métodos basados en la descomposición de valoressingulares por sus buenas características numéricas.Pero estos métodos requieren un alto coste computacional,O(n 3 ) operaciones aritméticas en comaflotante, donde n es el orden del modelo original y seencuentra en el rango 10 3 − 10 5 en numerosas aplicacionesprácticas. Consecuentemente, la aplicabilidadde estos métodos está condicionada al uso de arquitecturasy técnicas de computación de altas prestaciones.En este estudio se han desarrollado y evaluado diversasimplementaciones para uno de estos métodos,el método BST, sobre una arquitectura con procesadoresmultinúcleo. Los resultados experimentalesavalan la eficiencia de los códigos desarrollados y suescalabilidad.Palabras clave— Reducción de modelos, sistemasdinámicos lineales, ecuaciones de Lyapunov, métodosSVD, GPUs.I. IntroducciónNUMEROSOS procesos físicos y químicos puedenser descritos mediante modelos matemáticos.Estos modelos pueden ser empleados, por ejemplo,para anticipar el comportamiento del proceso y seaplican con éxito en áreas tan dispares como eldiseño de controladores, la simulación de circuitos oel diseño de estructuras. En particular, considera unsistema lineal invariante en el tiempo que, por ejemplo,describe un proceso físico, definido en el modelode espacio de estados porẋ(t) = Ax(t) + Bu(t), t > 0, x(0) = x 0 ,y(t) = Cx(t) + Du(t), t ≥ 0,(1)donde A ∈ R n×n , B ∈ R n×m , C ∈ R p×n , D ∈R p×m , x 0 ∈ R n es el estado inicial del sistema, y nes el orden del modelo. El objetivo de la reducciónde modelos es encontrar un modelo de orden menorẋ r (t) = A r x r (t) + B r u(t), t > 0, x r (0) = ˆx 0 ,y r (t) = C r x r (t) + D r u(t), t ≥ 0,(2)donde A r ∈ R r×r , B r ∈ R r×m , C r ∈ R p×r ,D r ∈ R p×m , ˆx 0 ∈ R n es el estado inicial del sistema,r es el orden del nuevo modelo, con r ≪ n,1 Centro de Cálculo-Instituto de Computación, Universidadde la República, e-mail: pezzatti@fing.edu.uy2 Depto. de Ingeniería y Ciencia de Computadores, UniversidadJaume I, e-mail: quintana@icc.uji.es3 Depto. de Ingeniería y Ciencia de Computadores, UniversidadJaume I, e-mail: quintana@icc.uji.esy ‖y − y r ‖ es “pequeño”. Es decir, el propósito dela reducción de modelos es obtener un nuevo modelocon un orden menor (r), que potencialmente puedereemplazar el modelo original en posteriores cálculosreportando importantes reducciones de los requerimientoscomputacionales. Mientras que hace unosaños, la reducción de modelos con un espacio deestados en el orden de las decenas de miles o superior,requería del uso de un cluster de computadorascon un número moderado de nodos [1], losprocesadores multinúcleo actuales proporcionan unpoder de cómputo suficiente como para, en tiemposde cómputo razonable, ejecutar la mayor parte de lasoperaciones matriciales requeridas para la reducciónde modelos.En trabajos anteriores tratamos los casos en losque la matriz de espacio de estados A es dispersa [2],una matriz general densa [3], y una matriz banda[4]. En este trabajo nos centramos en el caso enel que la matriz −A es una matriz densa simétricadefinida positiva (en adelante SPD, del inglés SymmetricPositive Definite). En este caso, la estructuray propiedades de la matriz pueden ser explotadaspara reducir el número de operaciones aritméticasnecesarias.La estructura del resto del artículo es la siguiente:en la Sección II se revisan los métodos y bibliotecasempleadas en la reducción de modelos, en laSección III se describe el método de la función signopara la resolución de ecuaciones de Lyapunov, en lasSecciones IV y V se presentan diferentes métodospara la inversión de matrices SPD y las implementacionesde altas prestaciones propuestas para esta operación,finalmente, las Secciones VI y VII muestranlos resultados experimentales y las conclusiones alcanzadasen este trabajo.II. Algoritmos y bibliotecas para lareducción de modelosComo se ha comentado, existen diversos métodospara la reducción de modelos, pero entre ellosdestacan por sus cualidades numéricas los métodosbasados en la descomposición en valores singulares(SVD). Estos métodos se caracterizan por la preserveraciónde importantes cualidades de la matrizde estados, como por ejemplo la estabilidad o la pasividad.Además, estos métodos proporcionan cotasal error introducido por el nuevo modelo. Por contra,su alto coste computacional condiciona su aplicabilidada problemas de dimensión moderada. Elcoste computacional de estos métodos se concentraJP2011-27

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011en la resolución de dos ecuaciones de Lyapunov. Alaplicar el método del truncamiento balanceado a (1),las ecuaciones de Lyapunov que se deben resolver sonAW c + W c A T + BB T = 0,A T W o + W o A + C T C = 0.(3)En general, A es una matriz estable (es decir, todossus valores propios tienen parte real negativa) y consecuentemente,W c , W o son matrices SPDs. Desafortunadamente,W c , W o son densas, cuadradas y de dimensiónn×n incluso a pesar de que A sea una matrizdispersa. Estas ecuaciones pueden ser resueltas mediantemétodos directos [5][6] como los incluidos enla biblioteca SLICOT [7], permitiendo la reducciónde modelos de dimensión reducida (n < 5.000) en lascomputadoras modernas. Problemas de dimensiónmayor, con decenas de miles de variables en el espaciode estados, pueden ser reducidos utilizando elmétodo de la función signo en arquitecturas paralelasde altas prestaciones, por ejemplo mediante las rutinasincluidas en la biblioteca PLiCMR [8][1]. Las dificultadesde explotar la habitual estructura dispersade las matrices que aparecen en las ecuaciones deLyapunov durante su resolución mediante métodosdirectos o mediante el método de la función signo,limita la aplicabilidad de estas dos bibliotecas a problemasde dimensión moderada. No obstante, dichasbibliotecas están completamente basadas en núcleoscomputacionales de bibliotecas de álgebra numéricade altas prestaciones, en particular de las bibliotecasBLAS y LAPACK, reportando un rendimiento nadadesdeñable.III. El método de la función signoEl método de la función signo fue presentado en [9]como un método eficiente para resolver la ecuaciónde Lyapunov estándar. Una de las posibles implementacionesde este método se basa en el métodode la iteración de Newton [10]. A continuación, sedescriben los pasos a seguir en esta variante:Algorithm CECLNC:A 0 ← A, ˜S 0 ← B T , ˜R 0 ← Ck ← 0repeat(A k+1 ← √ 1 Ak 2+ A −1 )k˜S k+1 ← 1 √2[˜Sk ,˜R k+1 ← 1 √2[˜Rk ,k ← k + 1until convergence˜Sk (A −1]˜Rk A −1kk )T ]Al converger, tras j iteraciones, ˜S = √2 1 ˜Sj y˜R = √ 1 ˜Rj 2de dimensiones ˜k o × n y ˜k c × n son, respectivamente,aproximaciones de S y R, de formaque W c = S T S ≈ ˜S T ˜S y Wo = R T R ≈ ˜R T ˜R.Este método es propicio para la resolución de ecuacionesde Lyapunov en las arquitecturas de computaciónmodernas, en las que se dispone de unnúmero elevado de unidades computacionales. Enprimer lugar, presenta una convergencia cuadráticaque asegura un número de iteraciones moderado; ensegundo lugar, presenta un alto nivel de paralelismo,permitiendo extraer gran rendimiento a estas arquitecturas.Cada iteración del algoritmo CECLNC requiereO(n 3 ) operaciones artiméticas en coma flotante, oflops (del inglés floating-point arithmetic operations),donde n es la dimensión de la matriz A. En particular,las cuatro operaciones ejecutadas en cada pasoson:1. Obtener la matriz A −1k, la matriz inversa de lamatriz SPD A k (n 3 flops)2. Calcular la suma de dos matrices simétricas yescalar el resultado (n 2 flops)3. Calcular ˜S k+1 mediante un producto de matrices(n 2 × ˜k o flops)4. Calcular ˜R k+1 mediante un producto de matrices(n 2 × ˜k c flops)Como se puede ver, el coste computacional delalgoritmo descrito se concentra en el cálculo de lamatriz inversa A −1 k . Esta afirmación, basada en elcoste teórico, se refuerza con los resultados experimentalesalcanzados en un trabajo anterior, donde elmismo método era utilizado para resolver una únicaecuación de Lyapunov (pasos 1 a 3) con una matrizde coeficientes general [3]. En dicho trabajo, a pesardel uso de una GPU para acelerar el cómputo dela matriz inversa, esta operación requería de entreel 85% y el 91% del tiempo total de cómputo parados problemas de dimensión 5.177 y 9.699 respectivamente.Además, se dispone de implementaciones optimizadaspara arquitecturas multinúcleo para elresto de las operaciones requeridas por el algoritmoCECLNC. Por ejemplo, pueden utilizarse rutinas de labiblioteca BLAS para calcular los productos de matrices(pasos 3 y 4), o directivas OpenMP para optimizarla suma de matrices y el escalado del resultado(paso 2).Consecuentemente, el desarrollo de una implementaciónoptimizada de la inversión de una matrizSPD es la única herramienta necesaria para alcanzarun resolutor de ecuaciones de Lyapunov de altasprestaciones sobre arquitecturas multinúcleo, y conello, un método eficiente para la reducción de modelos.El resto del artículo se centra en el desarrollo deun núcleo computacional eficiente para la inversiónde matrices SPD sobre arquitecturas multinúcleo.IV. Inversión de matrices SPDEn esta sección revisitamos dos algoritmos diferentespara el cálculo de la matriz inversa de unamatriz SPD. El primer algoritmo se basa en la computaciónde la factorización de Cholesky, mientrasque el segundo algoritmo se basa en el método dela eliminación de Gauss-Jordan [11]. Ambos algoritmospresentan el mismo coste computacional, perolas propiedades del procedimiento de la emilinaciónJP2011-28

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algorithm: [A] := GJE blk v1 (A)„ «AT L A T RPartition A →⋆ A BRwhere A T L is 0 × 0 and A BR is n × nwhile m(A T L ) < m(A) doDetermine block size bRepartition„ «AT L A T R⋆ A BR0→ @where A 11 is b × bA 00 A 01 A 021⋆ A 11 A 12 AW := −A 00 · A 01 SYMMA 11 := A 11 + A T 01 · A 01 GEMMA 11 := chol(A 11 ) POTRFtriu(A 11 ) := triu(A 11 ) −1 TRTRIW := W · A 11 TRMMA 01 := W · A T 11 TRMMA 00 := A 00 + W · W T SYRKA 11 := triu(A 11 ) · triu(A 11 ) T LAUUMendwhileContinue with„ «AT L A T R⋆ A BR0← @A 00 A 01 A 021⋆ A 11 A 12 AFig. 1. Algoritmo por bloques para la inversión de matrices SPD via GJE (Variant 1).Algorithm: [A] := GJE blk v2 (A)„ «ATPartition A → L A T R⋆ A BRwhere A T L is 0 × 0 and A BR is n × nwhile m(A T L ) < m(A) doDetermine block size bRepartition„ «AT L A T R⋆ A BR0→ @where A 11 is b × bA 00 A 01 A 021⋆ A 11 A 12 AA 11 := chol(A 11 ) POTRFtriu(A 11 ) := triu(A −111 ) TRTRIA 01 := A 01 · A 11 TRMMA 00 := A 00 + A 01 · A T 01 SYRKA 01 := A 01 · A 11 TRMMA 12 := A −T11 · A 12 TRMMA 22 := A 22 − A T 12 · A 12 SYRKA 02 := A 02 − A 01 · A 12 GEMMA 12 := −(A 11 · A 12 ) TRMMA 11 := A 11 · A T 12 LAUUMendwhileContinue with„ «AT L A T R⋆ A BR0← @A 00 A 01 A 021⋆ A 11 A 12 AFig. 2. Algoritmo por bloques para la inversión de matrices SPD via GJE (Variant 2).de Gauss-Jordan son más propicias para su ejecuciónsobre arquitecturas paralelas.A. Inversión de matrices mediante la factorizaciónde CholeskyEl método tradicional para calcular la inversa deuna matriz SPD A ∈ R n×n se basa en la factorizaciónde Cholesky y consiste en los tres siguientes pasos:1. Calcular la factorización de Cholesky A =U T U, donde U ∈ R n×n es una matriz triangularsuperior2. Invertir el factor triangular U → U −13. Obtener la inversa mediante el producto de matricesU −1 U −T = A −1Explotando la estructura simétrica de A, el costecomputacional y espacial del algoritmo puede ser reducidoconsiderablemente. En particular, como se hacomentado, el coste computacional es n 3 flops (frentea los 2n 3 flops requeridos para invertir una matrizno-simétrica). Este algoritmo permite implementacionesin-place, de forma que la matriz resultadosobreescribe la matriz original, reportando una im-JP2011-29

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011portante reducción de los requerimientos espaciales.Además, sólo la parte superior de A es referenciadadurante el método, y sólo la parte superior de A −1 esescrita, de forma que se reducen los accesos a memoria.No obstante, con el fin de aumentar las prestaciones,la matriz A se almacena como una matrizcompleta n × n.B. Inversión de matrices basada en el algoritmo dela eliminación de Gauss-JordanEl algoritmo de la eliminación de Gauss-Jordan es,esencialmente, una reordenación de las operacionesejecutadas en el algoritmo tradicional. Por lo tanto,ambos presentan el mismo coste computacional. Lareordenación de operaciones reduce notablemente elnúmero de accesos a memoria requerido, además deproveer un método más propicio para su ejecuciónen arquitecturas provistas con múltiples unidades decómputo, gracias a un mejor balanceo de carga [12].Este método puede ser cuidadosamente diseñadopara explotar la estructura simétrica de la matriz yobtener una implementación in-place.Las Figuras 1 y 2 describen dos algoritmos porbloques basados en la eliminación de Gauss-Jordanutilizando la notación FLAME [13][14]. En ellos, lafunciones m(·) y triu(·) devuelven el número de filasy la parte triangular superior de la matriz argumentorespectivamente, mientras que “⋆” describe bloquesen la parte triangular inferior de la matriz, que noson referenciados en el método. Creemos que el restode la notación es intuitiva. A la derecha de cada operaciónse define el núcleo computacional de BLASque proporciona la funcionalidad necesaria para sucómputo. En ambos algoritmos, la inversa de la matrizsobreescribe la matriz inicial (son, por lo tanto,variantes in-place).En el algoritmo mostrado en la Figura 1 se ejecutanocho operaciones en cada iteración. Dos factoreslimitan las prestaciones de su implementaciónsobre arquitecturas paralelas: en primer lugar, lasnumerosas dependencias de datos entre las operacionesobligan a su ejecución secuencial, en segundo lugar,excepto la actualización del bloque A 00 , el restode operaciones involucran únicamente bloques de dimensiónreducida (teniendo en cuenta que, para aumentarlas prestaciones, el tamaño de bloque b sefija a un valor pequeño comparado con la dimensiónde la matriz, n). Ambos factores limitan el paralelismoinherente de la variante, especialmente durantelas primeras iteraciones del bucle, cuando A 00es también un bloque pequeño.La Figura 2 muestra una segunda variante del algoritmobasado en la eliminación de Gauss-Jordanen la que todos los elementos de la parte triangularsuperior de la matriz son actualizados en cadaiteración. De nuevo, las dependencias de datos obligana serializar la ejecución de la mayor parte de lasoperaciones.De forma que el paralelismo puede ser extraídoúnicamente durante la ejecución de cada operación.En esta variante, las actualizaciones de los bloquesA 00 y A 22 concentran la mayor parte de los cálculos,mientras que el resto de las operaciones involucranbloques pequeños. Esta implementación presentados ventajas respecto a la variante anterior:1. No requiere espacio de almacenamiento adicional2. El coste computacional de cada iteración esconstanteV. Implementaciones de altas prestacionesA. Implementaciones basadas en la factorización deCholeskyEl algoritmo basado en la factorización deCholesky para el cálculo de la matriz inversa deuna matriz SPD (ver la Sección IV-A) se componede tres etapas que deben ser ejecutadas secuencialmente.Esto significa que el paralelismo puede serextraído durante la ejecución de cada etapa pero node la ejecución concurrente de etapas.La biblioteca Intel MKL [15] ofrece rutinas para elcálculo de la factorización de Cholesky de una matrizSPD (rutina potrf, etapa 1) y el cálculo de lainversa de una matriz SPD dado su factor triangular(rutina potri, etapas 2 y 3). De forma que podemosfácilmente obtener una implementación de estealgoritmo, eficiente y paralela, para arquitecturasmultinúcleo, utilizando una implementación multithreadde la biblioteca MKL.B. Implementaciones basadas en el método de laeliminación de Gauss-JordanEn esta subsección describimos dos implementacionespara las sendas variantes del algoritmo GJEpresentadas en la Sección IV.En las dos variantes, la mayor parte de las operacioneshan sido reescritas en forma de productosde matrices. En particular, la operación que precisade un mayor número de flops es una actualizaciónsimétrica de rango-k (un caso particular del productode matrices).La biblioteca MKL incluye implementaciones dealtas prestaciones para este núcleo computacional,así como para el resto de operaciones implicadas enlos algoritmos GJE BLK V 1 y GJE BLK V 2 . Las rutinasGJE v1 y GJE v2 implementan estos algoritmosutilizando los núcleos computacionales de MKL. Elparalelismo es obtenido, de nuevo, en la ejecución decada operación mediante la invocación de las rutinasmulti-thread de MKL. El cómputo concurrentede distintas operaciones está limitado por la dependenciade datos.VI. Resultados experimentalesEn esta sección se evalúan las diferentes implementacionespropuestas en la sección V.Todos los experimentos en esta sección fueron desarrolladosutilizando aritmética IEEE de simple precisión.Se experimentó con matrices SPD de dimensión1.000, . . . , 15.000. Se evaluaron diferentestamaños de bloque (1024, 512, 256, 128, 64 y 32)JP2011-30

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IHardware empleado en los experimentos.Procesadores #cores Freq. L2 Memoria(GHz) (MB) (GB)Intel Xeon X7550 (8×4) 32 2.0 18 124350300LAPACKGJE_V1GJE_V235030025025032 THREADSGFLOPS20015010050GFLOPS2001501005016 THREADS8 THREADS4 THREADS2 THREADS1 THREAD00 2000 4000 6000 8000 10000 12000 14000 16000Dimensión de la matriz00 2000 4000 6000 8000 10000 12000 14000 16000Dimensión de la matrizFig. 3. Rendimiento de las distintas implementaciones de lainversión de matrices SPD.350Fig. 4. Rendimiento de la rutina GJE V1.para cada implementación, pero únicamente los resultadosobtenidos con el tamaño de bloque óptimoson mostrados.La plataforma empleada en los experimentos estáformada por cuatro procesadores Intel Xeon X7550(con 8 cores por procesador) a una frecuencia de 2.0GHz. La tabla I incluye más detalles sobre esta computadora.La mayor parte de las operaciones fueronejecutadas utilizando las rutinas de la biblioteca IntelMKL en su versión 11.0.La Figura 3 muestra las prestaciones obtenidas porla implementación basada en las rutinas LAPACKy las basadas en el algoritmo de la eliminación deGauss-Jordan descritas en la sección anterior. Entodas ellas se emplea 32 threads (uno por cadauno de los núcleos disponibles en la arquitectura).La implementación de la primera variante del algoritmo,GJE V1, es notablemente más eficiente quela implementación proporcionada por LAPACK, especialmenteen la inversión de matrices de gran dimensión(por ejemplo, para matrices de dimensión15.000 es aproximadamente 8× más rápida). No obstante,las mejores prestaciones se obtienen con laimplementación de la segunda variante del algoritmo,GJE V2, superando los 300 GFLOPS para matricesde dimensión 15.000, y siendo más de 10× másrápida que LAPACK. Esto se debe a las propiedadesde esta variante, que la hacen más adecuada para suejecución en computadoras paralelas.La Figura 4 muestra los resultados obtenidos porla variante GJE V1 empleando 1, 2, 4, 8, 16 y 32threads. El uso de más threads reporta un incrementoen las prestaciones considerable, excepto parala inversión de matrices con dimensión superior a8.000 cuando se emplean más de 16 threads. LosGFLOPS3002502001501005032 THREADS16 THREADS8 THREADS4 THREADS2 THREADS1 THREAD00 2000 4000 6000 8000 10000 12000 14000 16000Dimensión de la matrizFig. 5. Rendimiento de la rutina GJE V2.resultados obtenidos demuestran la escalabilidad dela rutina GJE V1.Finalmente, la Figura 5 es la análoga para la varianteGJE V2. Destacar en ella, además de laeficiencia alcanzada, la escalabilidad de la implementaciónGJE V2.VII. ConclusionesSe han presentado diferentes implementaciones dealtas prestaciones para la inversión de matrices SPDen arquitecturas multinúcleo. Esta operación esnecesaria para la reducción de modelos y requierede un alto coste computacional. Por lo tanto, requierede la aplicación de hardware y técnicas decomputación de altas prestaciones. El trabajo incluyela evaluación de dos algoritmos para la inversiónde matrices, el algoritmo tradicional basadoen la factorización de Cholesky, y otro basado en elalgoritmo de la eliminación de Gauss-Jordan, másadecuado para arquitecturas paralelas.JP2011-31

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Diferentes implementaciones de cada algoritmo sehan presentado y evaluado sobre una arquitecturacon 4 procesadores multinúcleo. Las implementacionesdesarrolladas se fundamentan en el uso denúcleos computacionales de altas prestaciones de labiblioteca Intel MKL.Los resultados experimentales demuestran quelas mejores prestaciones se obtienen con las rutinasbasadas en el algoritmo de la eliminación deGauss-Jordan. Las características de este algoritmolo hacen muy propicio para su implementaciónen arquitecturas paralelas, proporcionando un granrendimiento y una notoria escalabilidad.AgradecimientosLos autores quieren agradecer a Francisco Igualpor su soporte técnico, así como a Manuel Ujaldón(de la Universidad de Málaga) por facilitar el accesoa la plataforma hardware empleada para la evaluaciónexperimental de las nuevas rutinas. EnriqueS. Quintana-Ortí y Alfredo Remón recibieron financiacióndel proyecto CICYT TIN2008-06570-C04.Referencias[1] Peter Benner, Enrique S. Quintana-Ortí, and GregorioQuintana-Ortí, “State-space truncation methods for parallelmodel reduction of large-scale systems,” ParallelComputing, vol. 29, no. 11-12, pp. 1701 – 1722, 2003.[2] José M. Badía, Peter Benner, Rafael Mayo, and EnriqueS. Quintana-Ortí, “Parallel algorithms for balancedtruncation model reduction of sparse systems,” in AppliedParallel Computing, vol. 3732 of Lecture Notes inComputer Science, pp. 267–275. Springer Berlin / Heidelberg,2006.[3] Peter Benner, Pablo Ezzatti, Daniel Kressner, Enrique S.Quintana-Ortí, and Alfredo Remón, “A mixed-precisionalgorithm for the solution of Ļyapunov equations on hybridCPU-GPU ¸ platforms,” Parallel Computing, 2010.[4] Alfredo Remón, Enrique S. Quintana-Ortí, and GregorioQuintana-Ortí, “Solution of band linear systems in modelreduction for VSLI circuits,” in Scientific Computing inElectrical Engineering, vol. 11 of Mathematics in Industry,pp. 387–393. Springer Berlin Heidelberg, 2007.[5] R. H. Bartels and G. W. Stewart, “Solution of the matrixequation ax + xb = c [f4],” Commun. ACM, vol. 15, pp.820–826, September 1972.[6] S. J. Hammarling, “Numerical Solution of the Stable,Non-negative Definite Ļyapunov Equation,” IMA Journalof Numerical Analysis, vol. 2, no. 3, pp. 303–323,1982.[7] SLICOT (Control and Systems Library).[8] Peter Benner, Enrique S. Quintana-Ortí, and GregorioQuintana-Ortí, “Balanced Truncation Model Reductionof Large-Scale Dense Systems on Parallel Computers,”Mathematical and Computer Modelling of DynamicalSystems, vol. 6, pp. 383–405, 2000.[9] J.D. Roberts, “Linear model reduction and solution ofthe algebraic Riccati equation by use of the sign function,”Internationa Journal of Control, vol. 32, pp.677–687, 1980, (Reprint of Technical Report No. TR-13, CUED/B-Control, Cambridge University, EngineeringDepartment, 1971).[10] Peter Benner, Enrique S. Quintana-Ortí, and GregorioQuintana-Ortí, “Solving linear-quadratic optimal controlproblems on parallel computers,” Optimization MethodsSoftware, vol. 23, pp. 879–909, December 2008.[11] G.H. Golub and C.F. Van Loan, Matrix Computations,Johns Hopkins University Press, Baltimore, third edition,1996.[12] Paolo Bientinesi, Brian Gunter, and Robert A. van deGeijn, “Families of algorithms related to the inversionof a symmetric positive definite matrix,” ACM Trans.Math. Softw., vol. 35, pp. 3:1–3:22, July 2008.[13] Paolo Bientinesi, John A. Gunnels, Margaret E. Myers,Enrique S. Quintana-Ortí, and Robert A. van de Geijn,“The science of deriving dense linear algebra algorithms,”ACM Trans. Math. Softw., vol. 31, pp. 1–26, March 2005.[14] John A. Gunnels, Fred G. Gustavson, Greg M. Henry,and Robert A. van de Geijn, “Flame: Formal linearalgebra methods environment,” ACM Transactions onMathematical Software, vol. 27, no. 4, pp. 422–455, Dec.2001.[15] Intel Corporation., http://www.intel.com/.[16] Vasily Volkov and James Demmel, “LU¸ , QR ¸ andÇholesky factorizations using vector capabilities ofGPU ¸ s,” Technical Report No. UCB/EECS, vol. 49, May2008.[17] Sergio Barrachina, Maribel Castillo, Francisco D. Igual,Rafael Mayo, Enrique S. Quintana-Ortí, and GregorioQuintana-Ortí, “Exploiting the capabilities of moderngpus for dense matrix computations,” Concurr. Comput.: Pract. Exper., vol. 21, pp. 2457–2477, December 2009.[18] Enrique S. Quintana, Gregorio Quintana, Xiaobai Sun,and Robert van de Geijn, “A note on parallel matrixinversion,” SIAM Jorunal on Scientific Computing, vol.22, no. 5, pp. 1762–1771, 2001.[19] P. Benner, P. Ezzatti, E. S. Quintana, and A. Remón,“Using hybrid CPU-GPU ¸ platforms to accelerate thecomputation of the matrix sign function,” in LectureNotes in Computer Science, 7th Int. Workshop on Algorithms,Models and Tools for Parallel Computing onHeterogeneous Networks – HeteroPar’09, 2009.[20] B.D. Tapley, B.E. Schutz, and G.H. Born, StatisticalOrbit Determination, Elsevier Academic Press, 2004.[21] Nicholas J. Higham, Accuracy and Stability of NumericalAlgorithms, Society for Industrial and Applied Mathematics,Philadelphia, PA, USA, second edition, 2002.[22] Nvidia Corporation, http://www.nvidia.com/cuda/.[23] E. Anderson, Z. Bai, C. Bischof, L. S. Blackford,J. Demmel, Jack J. Dongarra, J. DuCroz, S. Hammarling,A. Greenbaum, A. McKenney, and D. Sorensen,LAPACK Users’ guide (third ed.), Society for Industrialand Applied Mathematics, Philadelphia, PA, USA,1999.[24] A.C. Antoulas, Approximation of Large-Scale DynamicalSystems., SIAM Publications, 2005.[25] V. Mehrmann P. Benner, Dimension Reduction of Large-Scale Systems, Springer-Verlag Berlin Heidelberg, 2005.JP2011-32

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Genetic Algorithm to Predict WaveletCoefficients SignRicardo García and Otoniel López and Pablo Piñol and Miguel Martínez and Manuel P.Malumbres 1 and Antonio Martí 2AbstractMost wavelet based encoders, do not compressthe wavelet coefficients sign because it has been assumedto be inefficient for a long time. However,in the last years several image encoders like JPEG2000 include sign coding capabilities. In this paper,we present a new sign coding approximationwhich uses a genetic algorithm to efficiently predictthe sign of wavelet coefficients. Preliminary resultsshow that, by including sign coding capabilities to anon-embedded encoder, the compression gain is upto 17.35%, being the Rate-Distortion (R/D) performanceimprovement up to 0.25 dB.Keywordssign coding, wavelets, image coding, genetic algorithms.I. IntroductionWAVELET transforms have proved to bevery powerful tools for image compression.Many state-of-the-art image codecs, including theJPEG2000 standard [1], employ a wavelet transformin their algorithms. One advantage is the provisionof both frequency and spatial localization of imageenergy. The image energy is compacted into a smallfraction of the transform coefficients and compressioncan be achieved by coding these coefficients.The energy of a wavelet transform coefficient is restrictedto non-negative real numbers, but the coefficientsthemselves are not, and they are defined byboth a magnitude and a sign. Shapiro stated in [2]that a transform coefficient is equally likely to bepositive or negative and thus one bit should be usedto encode the sign. In recent years, several authorshave begun to use context modeling for sign coding[3][4][5].For example, in [5], A. Deever and S. Hemami examinessign coding in detail in the context of an embeddedwavelet image coder. The paper shows that aPeak Signal to Noise Ratio (PSNR) improvement upto 0.7 dB is possible when sign entropy coding anda new extrapolation technique based on the mutualinformation that biorthogonal basis vectors provideto improve the estimation of insignificant coefficientsare combined. However, the contribution of sign codingby itself to the PSNR improvement is only up to0.4 dB.In [4] the Embedded Block Coding with OptimizedTruncation of the embedded bit-streams (EBCOT),1 Universidad Miguel Hernández, e-mail: r.garcia,otoniel, pablop, mmrach, mels@umh.es2 Universidad Politécnica de Valencia, e-mail:amarti@disca.upv.escore coding tool of the JPEG 2000 standard, encodesthe sign of wavelet coefficients using contextinformation from the sign of horizontal and verticalneighbor coefficients (North, South, East, West directions).Five context are used to model the signcoding stage.In [3], X. Wu presents a high order context modelingencoder. In this coder, the sign and the texturesshare the same context modeling. This modelis based on a different neighborhood for the HL, LHand HH wavelet subbands. For the HL subband,the information of North, North-West, North-East,North-North and South sign is used to predict thecurrent coefficient sign. The neighbors sign informationused for the LH subband are North, North-West, North-East, West-West and East. Finally, forthe HH subband, an inter-band prediction is used besidesthe intra-band prediction used by the HL andLH subbands.Genetic algorithms were first introduced by Hollandin [6] and they are nowadays well known techniquesfor finding nearly optimal solutions of verylarge problems and also, they have been used in imageprocessing [7][8].In a genetic algorithm, the evolution usually startsfrom a population of randomly generated individualsand happens in generations. In each generation,the fitness of every individual in the populationis evaluated by means of a cost function that determinesthe optimal degree we are looking for (i.ecompression rate). Multiple individuals are stochasticallyselected from the current population (basedon their fitness), and modified (recombined and possiblyrandomly mutated) to form a new population.The new population is then used in the next iterationof the algorithm. Commonly, the algorithmterminates when either a maximum number of generationshas been produced, or a satisfactory fitnesslevel has been reached for the population.In this paper, we will design a genetic algorithmto efficiently predict the wavelet coefficient signs. Ifthe sign prediction is really good, a binary entropyencoder will be able to get significant compressionrates. So, our goal is to define a genetic algorithmthat finds out the paremeters of our sign predictorthat achieve the best prediction performance. Asstudied in the literature, the parameters to be foundby our genetic algorithm will be a) the neighbor setthat defines the prediction context, and b) the signvalues (sign patterns) of wavelet coefficient neighborset with the correspondent sign prediction for currentwavelet coefficient.JP2011-33

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011After running the genetic algorithm and configuredthe sign predictor, we will evaluate the impactof the sign coding module in the overall performanceof an image wavelet encoder. In particular, we willuse the LTW wavelet encoder [9] to determine thebit-rate savings for several test images.The remainder of the paper is organized as follows:Section II describes our sign coding approximationand also the genetic algorithm structure. In SectionIII, we show the results of the global encoder system(with sign coding stage) and compare it withSPIHT and JPEG 2000. Finally, in Section IV someconclusions are drawn.II. Wavelet sign predictionMost wavelet image codecs do not consider the useof sign coding tools since the wavelet coefficients locatedat the high frequency subbands form a zeromeanprocess, and therefore equally likely positiveas negative.Schwartz, Zandi and Boliek were the first authorsto consider sign coding, using one neighboring pixelin their context modeling algorithm [10]. The mainidea behind this approach is to find correlations alongand across edges.The HL subbands of a multi-scale 2-D wavelet decompositionare formed from low-pass vertical filteringand high-pass horizontal filtering. The high-passfiltering detects vertical edges, thus the HL subbandscontain mainly vertical edge information. Oppositelydefined are the LH subbands that contain primarilyhorizontal edge information.As Deever explained in [5], given a vertical edge inan HL subband, it is reasonable to expect that neighboringcoefficients along the edge have the same signas the coefficient being coded. This is because verticalcorrelation often remains very high along verticaledges in images. When a low-pass filter is appliedalong the image columns, it results in a series of similarrows, as elements in a row tend to be very similarto elements directly above or below due to the highvertical correlation. Subsequent high-pass filteringalong similar rows is expected to yield vertically correlatedtransform coefficients.It is also important to consider correlation acrossedges, being the nature of the correlation directly affectedby the structure of the high pass filter. ForDaubechies’ 9/7 filters, wavelet coefficient signs arestrongly negatively correlated across edges becausethis filter is very similar to a second derivative of aGaussian, so, it is expected that wavelet coefficientswill change sign as the edge is crossed. Althoughthe discrete wavelet transform involves sub sampling,the sub sampled coefficients remain strongly negativelycorrelated across edges. In this manner, whena wavelet coefficient is optimally predicted as a functionof its across-edge neighbors (e.g. left and rightneighbors in HL subbands), the optimal predictioncoefficients are negative, indicating an expected signchange. This conclusion is general for any waveletwith a shape similar to a second derivative of a Gaussian.To estimate sign correlation in a practical way, wehave applied a 6-level Dyadic Wavelet Transform decompositionof the source image and then a low quantizationlevel to the resulting wavelet coefficients. Asa first approach and taking into account that thesign neighborhood correlation depends on the subbandtype (HL,LH,HH) as Deever assesses in [5], wehave used three different neighbors depending on thesubband type. So, for HL subband, the neighborsused are N, NN and W. Taking into account symmetry,for the LH subband, those neighbors are W,WW, and N. For the HH subband they are N, W,and NW, exploiting the correlation along and acrossthe diagonal edges. This lead us to a maximum of3 3 Neighbor Sign Patterns (NSP) for each subbandtype.TABLE IProbability distribution of neighbor sign patterns(NSPs) of HL 6 subband (8x8 coefficients) in LenaimageC N NN W Occurrences %Probability+ + + + 13 20.31+ + + - 8 12.50- - - + 8 12.50- + + + 6 9.38- - + + 6 9.38Others 23 35.93In Table I we show the NSP probability distributionfor HL 6 subband (from the sixth decompositionlevel) of Lena test image. As shown, the probabilitythat the current coefficient (C) is positive when its N,NN and W neighbors are also positive is around 20%.Besides, if the N and NN neighbors have the samesign and the W neighbor has the opposite sign, thecurrent coefficient (C) has the opposite sign of its Wneighbor with a probability of 25% as shown in rowstwo and three in Table I. The visible sign neighborhoodcorrelation suggest that the sign bits of waveletcoefficients are compressible. Using the previouslymentioned neighborhood for each subband type, wehave developed a genetic algorithm (GA) in order tofind an accurate sign estimation.A. Genetic algorithm for wavelet sign predictionThe goal of the desired genetic algorithm wouldbe to find a table where for each Sign NeigborhoodPattern (V k ) we have a sign prediction (S i,j ) for coefficientC i,j . There is no an univocal relationshipbetween a neighbor sign combination, i.e not alwaysfor a same V k pattern, S i,j is always positive or negative.However, it is possible that for a V k pattern,S i,j is more probably to be positive or negative. But,the problem is still more complex, because a sign predictionfor a neighbor sign pattern could fit well foran image and not for others. Therefore, the idea isto find suboptimal neighbor sign pattern predictionsthat better fit for a representative set of images.JP2011-34

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011The use of genetic algorithms to compress the signof wavelet coefficients is twofold. First, when thenumber of neighbors used to analyze the sign correlationgrows or when there is a great number ofimages to be used in the analysis, the search space isexcessively wide. Second, it is not intuitive to find away of combining the predictions obtained for severalimages.In Figure 1 we show the genetic algorithm pseudocodefor sign prediction. First of all we define eachindividual, containing a sign prediction for each 3 3NSP, then each NSP sign prediction of each individualof the universe is randomly initialized as apositive or negative sign.During evolution, sequences mate and mutate togenerate new sequences in the population and bestsequences are selected for survival on the basis oftheir fitness function. The mating of sequences isperformed through crossover operator, where parentsare randomly selected and its gens (NSPs) are mixed.The best two individuals, the ones that exhibit bestprediction performance, are selected for survival. Individualscan also undergo mutation, where a sequenceprediction is randomly modified.Finally, after performing the maximum iterations,the algorithm finishes, obtaining an optimal/suboptimalsign prediction for each NSP. Wehave performed the fitness evaluation over Lena andBarbara test images, because these images are representativefor both low and high textured imagesrespectively.Individual Structure{//Prediction array for each neighbor sign pattern combinationsign[NSP];//indicates the goodness of the individualfitness;}Individual universe[NUM-POPULATION];function SignPrediction (SubbandType, ImageFiles,mutation Probability)//Initialization phase:sign[NSPs]= random(POSITIVE/NEGATIVE)Initialize(universe, NUM-POPULATION, NSP);//we evaluate each individual of the universe.For each image in ImageFilesEvaluateFitness(SubbandType, ImageFiles, universe);for i=0 to NUM-ITERATIONS//Select the best two individuals from universe for survival.best = SelectBestIndividuals(2);//CrossovercrossPoint=random(NSP);//randomly selects a father and a mother to mix gensSelectFatherAndMother(random(NUM-POLUTATION));universe = MergeFatherAndMother(crossPoint);Mutation(universe, mutation Probability);universe = universe + best;EvaluateFitness(SubbandType, ImageFiles, universe);end//Finally get the best individual.best = SelectBestIndividuals(1);end of functionFig. 1.Genetic algorithm for sign predictionSeveral parameters should be taken into accountwhen training a genetic algorithm: The populationsize, the individuals initialization, the number of iterationsperformed, the mutation probability, thecrossover point, the crossover method, the selectioncriteria of the best sequences to be selected for survival,etc. We have performed lots of tests varyingthese parameters to tune the genetic algorithm.The parameters used to obtain the sign predictionare: population size (100), individuals initialization(ramdomly), number of iterations (1000), mutationprobability (0.001), crossover point (ramdomly) andcrossover method (best two fitness individuals overfour randomly selected parents).After running the genetic algorithm for each subbandtype, we obtain an individual containing theprediction of the current coefficient sign ( SC ˆ i,j [k]),for each NSP (k) of each subband type. So, what weare going to encode is the correctness of this prediction,i.e., a binary valued symbol from SC ˆ i,j [k]·SC i,j(see Table II). In order to compress this binary valuedsymbol, we use two contexts in the arithmeticencoder for each subband type, distributing all signcoding predictions from NSPs between them so asto minimize the zero order entropy of both contexts.The selection criterion is to isolate in one contextthose NSPs with the highest correctness predictionprobability and highest number of occurrences derivedfrom the probability distribution found in theprevious analysis. The rest of them are grouped intothe other context. However, there are certain NSPswith low correctness probability but with a greatamount of occurrences, so we have to heuristicallydetermine the convenience of including them in thefirst context or not.TABLE IISign prediction for HL subband in Lena image forsome NSPsNSP(k) N NN W Prediction( SC ˆ i,j [k])0 * * * -. . .13 + + + +14 + + - +. . .26 - - - +III. Performance EvaluationIn this section we analyze the behavior of the signcoding when implemented on LTW image encoder[9]. This new encoder implementation is called S-LTW. We will also compare the S-LTW encoder versusJPEG2000 (Jasper 1.701.0) and SPIHT (Spiht8.01) in terms of R/D and coding delay. All encodershave been tested on an Intel PentiumM Dual Core3.0 GHz with 2 Gbyte RAM memory.The test images used in the evaluation are: Barbara(512x512), Bike (2560x2048), Boat (512x512),Cafe (2560x2048), GoldHill (512x512), Lena(512x512), Mandrill (512x512), Woman (2560x2048)and Zelda (512x512).In Table III we show the relative compression gainwith respect to the original LTW due only to the signcoding capability for Barbara and Bike test images.As we can see, the maximum sign compression gainJP2011-35

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIISign compression performance at different bit-rates.Bit-rate S-LTW SPIHT %Gain(bpp) #Significant #Bits #Significant #BitsCoefficients Saved Coefficients SavedBarbara (512x512)1 45740 7936 54657 9482 17.350.5 22331 3648 27535 4499 16.340.25 10484 1520 13460 1951 14.500.125 4343 304 6016 421 7.00Bike (2048x2560)1 855266 115200 1371280 184711 13.470.5 412212 64424 798202 124758 15.630.25 198943 30472 366927 56213 15.320.125 91767 11992 162990 21302 13.07P PSNR (d dB)0.5 S-LTW vs SPIHT0.4LTW vs SPIHTS-LTW vs JPEG20000.3LTW vs JPEG20000.20.100-0.10.5 1 1.5 2-0.2-0.3-0.4-0.5Fig. 2.Bit-rate (bpp)PSNR-Gain for Bike imageis 17.35%. Furthermore, we show an estimation ofthe bit savings for SPIHT encoder.TABLE IVCoding delay (seconds).Bit-rate JPEG SPIHT LTW S-LTW(bpp) 2000 Orig.CODING Barbara (512x512)1 0.080 0.042 0.037 0.0230.5 0.076 0.026 0.022 0.0140.25 0.074 0.018 0.013 0.0090.125 0.073 0.014 0.010 0.006CODING Bike (2048x2560)1 2.623 0.920 0.647 0.4300.5 2.543 0.521 0.381 0.2590.25 2.507 0.323 0.224 0.1620.125 2.518 0.221 0.158 0.117In Figure 2 we show the R/D improvement whencomparing original LTW versus JPEG2000/SPIHTand S-LTW versus JPEG2000/SPIHT. As shown,there is an increase in the PSNR difference betweenSPIHT and the new S-LTW encoder, and regardingJPEG2000, we can see than now S-LTW has a minorloss in PSNR than original LTW.Regarding coding delay, the use of a higher contextmodeling in the arithmetic encoder implies a highercomputational cost. In order to compensate the codingspeed loss, we have changed the arithmetic encoderstage by a fast arithmetic encoder [11]. Asit can be seen in Table IV, S-LTW encoder is 49%faster on average in the coding process than SPIHTencoder and 86% faster on average than JPEG2000.Furthermore, S-LTW encoder is even faster than theoriginal LTW version which does not include the signcoding stage (1.5 times faster on average in the codingprocess).IV. ConclusionsWe have presented a genetic algorithm that is ableto find a good sign predictor of wavelet coefficientsign. So, by encoding the sign prediction result (successor failure) with an arithmetic encoder, the signinformation will be highly compacted in the final bitstream.In order to prove our proposal we have implementedthe sign predictor over the non-embeddedLTW encoder. The new S-LTW proposed encoderhas slightly better R/D performance (up to 0.25 dB),or in terms of bitstream, it is able to reduce the bitstreamsize up to 17% for the same quality level.Regarding coding delay, the new image encoder ison average 2 times as fast as SPIHT in the codingprocess and 1.5 times as fast as original LTW due tothe inclusion of a fast arithmetic encoder.AcknowledgementsThanks to Spanish Ministry of education and Scienceunder grant DPI2007-66796-C03-03 for funding.References[1] ISO/IEC 15444-1, “JPEG2000 image coding system,”2000.[2] J.M. Shapiro, “A fast technique for identifying zerotreesin the EZW algorithm,” Proc. IEEE Int. Conf. Acoust.,Speech, Signal Processing, vol. 3, pp. 1455–1458, 1996.[3] X. Wu, “High-order context modeling and embeddedconditional entropy coding of wavelet coefficients for imagecompression,” in Proc. of 31st Asilomar Conf. onSignals, Systems, and Computers, 1997, pp. 1378–1382.[4] D. Taubman, “High performance scalable image compressionwith EBCOT,” IEEE Transactions on ImageProcessing, vol. 9, no. 7, pp. 1158–1170, July 2000.JP2011-36

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011[5] Aaron Deever and Sheila S. Hemami, “What’s your sign?:Efficient sign coding for embedded wavelet image coding,”in Proc. IEEE Data Compression Conf., Snowbird,UT, 2000, pp. 273–282.[6] J.H. Holland, Adaption in Natural and Artificial Systems,University of Michigan Press, 1975.[7] S. Chabrier, C. Rosenberger, B. Emile, , and H. Laurent,“Optimization-based image segmentation by genetic algorithms,”EURASIP Journal on Image and Video Processing,vol. 2008, pp. 1–10, 2008.[8] Sarawat Anam, Md. Shohidul Islam, M.A. Kashem, M.N.Islam, M.R. Islam, and M.S. Islam, “Face recognition usinggenetic algorithm and back propagation neural network,”in International MultiConference of Engineersand Computer Scientists, Hong Kong, 2009.[9] J. Oliver and M. P. Malumbres, “Low-complexitymultiresolution image compression using wavelet lowertrees,” IEEE Transactions on Circuits and Systems forVideo Technology, vol. 16, no. 11, pp. 1437–1444, 2006.[10] Edward L. Schwartz, Ahmad Z, and Martin Boliek,“CREW: Compression with reversible embeddedwavelets,” in In Proc SPIE, 1995, pp. 212–221.[11] Amir Said, “Comparative analysis of arithmetic codingcomputational complexity,” Tech. Rep., Hewlett-PackardLaboratories HPL-2004-75, 2004.JP2011-37

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-38

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Resolución del Empaquetado 2DMultiobjetivizado con un AlgoritmoMemético ParaleloCoromoto León, Carlos Segura y Eduardo Segredo 1Resumen— El problema de corte y empaquetadoes un problema de optimización NP-completo conmúltiples aplicaciones prácticas. En la sesión de competicionesde gecco 2008 se propuso una variante deeste problema. En la misma, los mejores resultadosfueron obtenidos a través de la aplicación de un algoritmomemético mono-objetivo. Posteriores estudioshan revelado que el método propuesto sufre deestancamiento en mínimos locales en diversas instancias.La técnica denominada multiobjetivización escapaz de transformar un problema mono-objetivo enuno multi-objetivo. Puede ser útil para evitar problemasde estancamiento. En este trabajo, el problemaes multiobjetivizado y abordado mediante unalgoritmo memético multi-objetivo. Se han analizadovarias alternativas para multiobjetivizar el problema.Además, se propone una paralelización de dicho algoritmo.Los resultados computacionales han demostradola validez de las propuestas secuenciales yparalelas. Se ha conseguido aumentar la calidad de lassoluciones obtenidas, a la vez que se ha disminuido eltiempo necesario para obtenerlas.Palabras clave— Multiobjetivización, Modelos Paralelelosbasados en Islas, Algoritmos Meméticos,Corte y Empaquetado.I. IntroducciónEL problema de empaquetado es un problema deoptimización combinatoria NP-completo, en elque se pretende empaquetar un conjunto de elementosen un objeto geométrico mayor, optimizando unafunción objetivo. Este problema tiene gran relacióncon el problema de corte, cuyo objetivo es dividiruna determinada pieza en otro conjunto de piezasmás pequeñas. Dada la estrecha relación entre ambosproblemas, en múltiples trabajos se han analizado deforma conjunta, siendo referenciado en dichos casoscomo el problema de corte y empaquetado (Cuttingand Packing - c&p). Los problemas de corte y empaquetadotienen numerosas aplicaciones prácticas,como la carga de contenedores o la optimización dela distribución de piezas en circuitos eléctricos. Durantela sesión de competiciones del gecco 2008 1se propuso una nueva variante de empaquetado 2D(Two-Dimensional Bin Packing Problem - 2dpp) conel objetivo de analizar las fortalezas de distintos algoritmosal abordar dicho problema.Los problemas de c&p han sido ampliamente analizadosen la literatura. Entre las técnicas propuestaspodemos identificar algunas estrategias exactas. Elprincipal inconveniente de dichas técnicas es al alto1 Dpto. de Estadística, I.O y Computación, Universidadde La Laguna, Edificio de Física y Matemáticas, Avda. AstrofísicoFco. Sánchez s/n, 38271 La Laguna, Tenerife, e-mail:(cleon|csegura|esegredo)@ull.es.1 http://www.sigevo.org/gecco-2008/competitions.htmlcoste computacional asociado a las mismas. Conel objetivo de reducir el tiempo requerido para suresolución, se han propuesto diversas paralelizacionesde estos algoritmos. Sin embargo, incluso utilizandotécnicas paralelas, la gran mayoría de instanciasdel problema con interés práctico, no pueden serabordadas utilizando dichas técnicas. Las técnicasaproximadas solventan parcialmente este problema.Entre estas técnicas cabe mencionar la amplia utilizaciónde meta-heurísticas. Concretamente, los AlgoritmosMeméticos (Memetic Algorithms - mas) [1]son una de las técnicas que han obtenido resultadosmás prometedores. Los mas son una sinergia entrelos Algoritmos Evolutivos (Evolutionary Algorithms- eas) y las técnicas de aprendizaje individual.Existen numerosos estudios que han analizado laposibilidad de paralelizar los eas [2] (peas). El modelobasado en islas [3] es una de las paralelizacionesmás populares. Este esquema divide la poblaciónen un conjunto de subpoblaciones independientes.Cada subpoblación constituye una isla, y sobre lamisma se aplica un ea. Además, se integra una fasede migración que posibilita el intercambio de individuosentre las islas. De esta forma, durante lamayor parte de las ejecuciones de un pea cada subpoblaciónes evolucionada de forma independiente,y sólo ocasionalmente, se producen comunicaciones.El modelo basado en islas se ha aplicado también ala paralelización de mas (pmas).La variante del problema de empaquetado propuestaen gecco 2008 fue abordada con múltiplestécnicas. Los mejores resultados para la instanciapropuesta fueron obtenidos mediante un ma monoobjetivo.En [4] se propuso un modelo basado enislas que hace uso de dicho ma. A pesar de que seobtuvieron resultados de alta calidad para la instanciapropuesta en la competición, posteriores estudiosrevelaron que dicho modelo sufre de estancamientoen mínimos locales para otras instancias. Con el objetivode abordar los problemas de estancamiento,se han diseñado una gran cantidad de técnicas [5].Entre ellas cabe destacar la multiobjetivización [6].La técnica denominada multiobjetivización transformaun problema mono-objetivo en uno multiobjetivo.Su principio de funcionamiento es que medianteesta conversión, se pueden cambiar las característicasdel problema, con lo que puede ser útilpara evitar problemas de estancamiento [6]. Sin embargo,también es posible que la nueva versión delproblema sea más compleja [7]. Las técnicas de multiobjevizaciónpueden ser clasificadas en dos tipos:JP2011-39

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011técnicas de descomposición y técnicas de agregación.Las técnicas de descomposición están basadas en dividirla función objetivo original en varias funcionesindependientes. Las técnicas de agregación consideran,junto a la función objetivo original, otras funcionesagregadas de forma artificial.En este trabajo se analizan las ventajas y desventajasde multiobjetivizar el 2dpp. Para ello se hanpropuesto un conjunto de multiobjetivizaciones y seles ha aplicado un ma multi-objetivo. Los resultadosobtenidos han sido comparados con los obtenidos porla mejor técnica secuencial propuesta en [4]. Dadoque la técnica más adecuada ha dependido de lainstancia considerada, no se ha podido demostrarla superioridad de las técnicas mono-objetivo, ni delas técnicas multi-objetivo. Por ello, la aplicaciónde esquemas de resolución de más alto nivel comolas hiperheurísticas, para automatizar la selecciónde qué técnica usar, parece muy prometedor. Estastécnicas han sido ampliamente utilizadas en conjuncióncon los modelos paralelos basados en islas[8]. Por ello, en este trabajo también se analizanla validez del modelo basado en islas con las multiobjetivizacionespropuestas. Los resultados computacioneshan demostrado la validez de la multiobjetivizacióny de la paralelización propuesta.El resto del trabajo se estructura de la siguientemanera: la formación matemática del 2dpp se detallaen la Sección II. En la Sección III se describeel esquema de optimización aplicado. El modelobasado en islas es descrito en la Sección IV. En lasección V se detallan los diferentes experimentos realizadosy se presentan los resultados computacionalesobtenidos. Por último, en la sección VI se presentanlas conclusiones y las líneas de trabajo futuro.II. Formulación Matemática del 2DPPEl problema propuesto durante la competición esuna variante del problema de empaquetado bidimensional.Una instancia del problema viene dada porlos siguientes datos:• Las dimensiones X, Y de una rejilla rectangular.• El número máximo que puede ser asignado en lasceldas de la rejilla: N. En cada celda se debeasignar un número entero en el rango [0, N].• La puntuación asociada a la aparición de cadapareja (a, b), en donde a, b ∈ [0, N]: v(a, b). Lapuntuación asociada a la aparición de (a, b) noes necesariamente igual a la aparición de (b, a).Una solución candidata se constituye asignando acada celda de la rejilla un valor en el rango válido.Por ello, el espacio de búsqueda está formado por(N + 1) X·Y soluciones candidatas. El objetivo consisteen encontrar la asignación de números que maximicela suma de las puntuaciones de las parejasque aparecen en la rejilla. Se considera que unapareja (a, b) aparece en la rejilla, si los números ay b son asignados en casillas vecinas. Dos casillasson vecinas si una está junta a la otra en cualquierfila, columna, o diagonal de la rejilla. Para el cálculoAlgorithm 1 Pseudocódigo de un ma1: Generar población inicial2: Evaluar individual de la población3: while (critero de parada no se cumpla) do4: Selección de padres5: Aplicar operador de crossover con probablidad p c6: Aplicar operador de mutación con probabilidad p m7: Aplicar el proceso de aprendizeje individual con probabilidadp l8: Evaluar los nuevos individuos9: Selección de supervivencia10: end whilede la función objetivo, el valor asociado a la apariciónde cada pareja sólo puede ser contabilizado una vez.De esta forma, el objetivo del problema es encontraruna rejilla G que maximice la función de fitness f.dondef =N∑a=0 b=0N∑v 2 (a, b){0 si (a, b) no son adyacentesv 2 (a, b) =v(a, b) si (a, b) son adyacentesIII. Esquema de OptimizaciónA. Algoritmos MeméticosLos algoritmos meméticos [9], [1] (mas) son unasinergia entre las estrategias poblacionales, y unmétodo de aprendizaje individual. Los mas hanmostrado un rendimiento muy superior a los algoritmosgenéticos tradicionales en varios dominios [10].Existen diferentes versiones de los mas, habiendosido aplicados tanto en entornos mono-objetivo [11],como multi-objetivo [12]. El Algoritmo 1 muestra unpseudocódigo de una estrategia memética integradaen un ea. La principal diferencia respecto a los eases la aplicación de un proceso de aprendizaje individual(línea 7). Existen dos formas principales deintegrar dicho proceso [13]. En el aprendizaje Lamarckianoel genotipo del individuo refleja los cambiosrealizados durante el aprendizaje. Por el contrario,en el aprendizaje de Baldwinian el contenidogenético permanece intacto. Ambos tipos de aprendizajehan aportado beneficios en múltiples campos[14].El proceso de aprendizaje es generalmente computacionalmentecostoso. Por ello, no se suele aplicaren todas las generaciones, sino con una cierta probabilidadp l . En el 2dpp se hace indispensable la aplicacióndel proceso de aprendizaje individual en todaslas generaciones para obtener soluciones de alta calidad.Por ello, en este trabajo se aplicó el proceso deaprendizaje individual en cada generación.En este trabajo se han comparado dos mas deprimera generación [15]. El primero de ellos (Var-PopEA), es la estrategia mono-objetiva presentadaen [4]. Concretamente es un ma que combina un algoritmoevolutivo modificado con selección de tipo(1 + 1), y un aprendizaje individual específicamentediseñado para el 2dpp. El algoritmo comienza comportándosecomo un algoritmo basado en trayecto-JP2011-40

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ria, es decir, se genera una población inicial con unindividuo. Sin embargo, si se detecta que el algoritmoestá sufriendo estancamiento en mínimos locales,se añaden otros individuos a la población, comportándoseentonces como un algoritmo poblacional.El segundo ma analizado en este trabajo es unamodificación del algoritmo evolutivo multi-objetivoNon-Dominated Sorting Evolutionary Algorithm-II(nsga-ii). El único cambio realizado sobre el nsga-iiconsistió en integrar en cada generación la ejecucióndel procedimiento de aprendizaje individual. Esteprocedimiento es integrado tras la fase de variacióngenética. En ambas versiones de los mas los individuoshan sido codificados utilizando un vector bidimensionalde número enteros, G, en donde G(x, y)representa el número asignado a la celda (x, y).B. Aprendizaje Individual para el 2DPPEn general, los mas multi-objetivo hacen usode técnicas de aprendizaje individual multiobjetivo[16]. Sin embargo, dado que el 2dpp ha sidomultiobjetivizado, el interés final es optimizar sólo elobjetivo original. Por ello, se decidió aplicar un procesode aprendizaje mono-objetivo. El proceso deaprendizaje aplicado es de tipo Lamarckiano. Concretamente,se ha realizado utilizando una variantede búsqueda local por escalada. En la misma, el ordenen que los vecinos son explorados es aleatorio,y se acepta cualquier movimiento que mejore a lasolución actual. Finalmente, cuando no existan vecinosque mejoren la puntuación actual, se da porterminado el proceso de aprendizaje individual.El número de vecinos de las soluciones candidatasviene determinado por el número de casillas vecinasde la rejilla. Específicamente, para cada parde celdas vecinas (i, j) y (k, l), se determina cuál esla mejor asignación posible que se podría hacer adichas celdas, considerando que no se pueden modificarlas asignaciones realizadas en el resto de casillas.Para obtener dicha asignación se diseñó un métodoque evita enumerar todas las posibles opciones. Enprimer lugar, se consideran todas las posibles asignacionesn ∈ [0, N] de valores a la casilla (i, j), calculándosela contribución de cada asignación v ij (n).Para el cálculo de este valor se asume que la casilla(k, l) no está asignada. Posteriormente, se realizael mismo proceso para la casilla (k, l), calculándosev kl (n). En este caso se considera que la casilla (i, j)no está asignada. La contribución de fitness que seobtiene al asignar el valor a a la celda (i, j), y el valorb a la celda (k, l), viene dado por:v ij (a) + v kl (b) + v ′ (a, b) − v repdonde v ′ (a, b) es v(a, b) + v(b, a) si la pareja (a, b) noaparece en otra parte de la rejilla, o 0 en caso contrario,y v rep es el valor asociado a aquellas parejasque se produjeron tanto por la asignación de a en(i, j), como de b en (k, l). Un límite superior de lacontribución de fitness viene dado por:v ij (a) + v kl (b) + min(bestV (a), bestV (b))donde bestV (n) es el máximo valor asociado acualquier pareja (n, m), m ∈ [0, N], es decir,max{(v(n, m) + v(m, n)}. Siendo bestF it la mayorpuntuación encontrada para una asignación de lasposiciones (i, j), y (k, l), los únicos valores a ′ , b ′que tienen que ser considerados, son aquellos enlos que se cumple la relación v ij (a ′ ) + v kl (b ′ ) +min(bestV (a ′ ), bestV (b ′ )) > bestF it. El coste computacionalasociado a la generación de individuosse redujo drásticamente descartando aquellas asignacionesen las que la relación anterior no se cumplía.C. Operadores GenéticosEn cada generación del algoritmo descrito se aplicauna fase de variación. En [4] se analizó el comportamientode varios operadores genéticos. En estetrabajo se han aplicado aquellos que obtuvieron losmejores resultados. El operador de cruce es el operadorbidimensional de cruce de subcadenas (ssx- Two-dimensional Sub-string Crossover) propuestoen [17]. Es una extensión del cruce de un punto acromosomas bidimensionales. En primer lugar, se seleccionade forma aleatoria una celda de la rejilla queactuará como celda de división. A continuación, conigual probabilidad, se linealiza el cromosoma por filaso por columnas, y se aplica el operador de cruce deun punto, considerando la celda de división elegida.El operador de mutación utilizado consiste en unamutación uniforme, que incluye información de dominio(umd - Uniform Mutation with Domain Information).En umd inicialmente se genera un númeroaleatorio entre min p m y max p m . A continuación,cada gen es mutado con una probabilidad igual alnúmero generado. El nuevo valor asignado a cadagen es elegido de forma aleatoria entre aquellos valorescuyo fitness asociado - puntuación obtenida porrealizar dicha asignación - no sea cero.D. MultiobjetivizacionesEn este trabajo se han analizado varias formasde multiobjetivizar el 2dpp. Concretamente, hansido multiobjetivizaciones por agregación, en las queademás de utilizar el objetivo original del 2dpp, seha añadido un objetivo alternativo. Tres de las funcionesalternativas hacen uso de la distancia Euclídeaen el espacio de decisión. En estos casos, se intentamaximizar dicha función. El cálculo de la funciónalternativa es realizado de la siguiente forma:• dcn - Distance to the closest neighbour: distanciaal individuo más cercano.• adi - Average distance to all population individuals:distancia media al resto de individuos enla población.• dbi - Distance to the best population individual:distancia al mejor individuo de la población.Además, se analizaron otras dos funciones:• Random: la función alternativa se calcula deforma aleatoria, y se intenta minimizar.• Reverse: se considera la función inversa a lafunción de fitness.JP2011-41

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Primera InstanciaSegunda Instancia5.13e+081.01e+095.12e+081e+09Fitness5.11e+085.1e+085.09e+085.08e+08ADIDBI_THRDCNDBIVarPopEAReverseRandom0 15000 30000 45000 60000 75000Tiempo (s)Fitness9.9e+089.8e+08VarPopEADBI_THRDCN9.7e+08DBIADIRandomReverse9.6e+080 15000 30000 45000 60000 75000Tiempo (s)Fig. 1.Evolución del Fitness para la Primer InstanciaFig. 2.Evolución del Fitness para la Segunda InstanciaAdemás, también se analizó una variante de dbi(dbi thr), consistente en añadir un valor umbralpara penalizar a las soluciones que no cumplanunos requisitos mínimos de calidad. Concretamente,se utiliza un parámetro p, y se penaliza a aquellassoluciones cuyo valor de fitness sea inferior ap∗bestCurrentF it, siendo bestCurrentF it el fitnessdel mejor individuo de la población. La penalizaciónconsiste en asignar el valor 0 a la función alternativa.IV. Modelos Basados en IslasLos modelos basados en islas dividen la poblaciónoriginal en un conjunto de subpoblaciones independientes.Sobre cada subpoblación se aplica una configuraciónde un ma, constituyendo una isla. Generalmente,cada isla es evolucionada de forma independientedurante un cierto tiempo. Sin embargo,dado que los esquemas colaborativos suelen alcanzarmejores resultados, se incluye una fase de migraciónque permite el intercambio de individuos entre islas.Existen diversos tipos de modelos basados en islas[3]. En este trabajo se analiza el modelo homogéneo.En este modelo todas las islas ejecutanuna misma configuración de un ma. La migraciónes uno de los pasos más importantes en este modelo.En este proceso se debe fijar la topología, el númerode individuos a migrar, la probabilidad de migración,y las estrategias de selección y reemplazo.En [4] se aplicó un modelo basado en islas al 2dppmono-objetivo. En dicho caso, las islas ejecutabanconfiguraciones de VarPopEA. La migración se configurócon una topología totalmente conectada, y sehizo uso de esquemas de selección y reemplazo elitistas.Concretamente, sólo se producían migracionescuando se generaban individuos hijos mejores quecualquiera de los individuos de la población padre.En la isla destino, se producía un reemplazamientosi dicho individuo era mejor que todos los individuosde la isla destino. En tal caso, se reemplazaba alindividuo con menor valor de fitness. En este trabajose utiliza una fase de migración similar. Sólose diferencia en que el reemplazamiento es realizadomediante el esquema Elitist Ranking [18]. Este esquemautiliza el operador de crowding del nsga-iipara separar el frente original en subfrentes. Finalmente,se reemplaza un individuo del peor subfrente.V. Resultados ComputacionalesEn esta sección se describen los experimentos realizadospara validar las multiobjetivizaciones y el modelobasado en islas previamente descrito. Los resultadosobtenidos con estas propuestas han sido comparadoscon los obtenidos por sus correspondientesversiones mono-objetivas. Los experimentos han sidoejecutados en una máquina de 4 procesadores amdR○ Opteron TM (modelo 6164HE) a 1.7 GHz, y conuna memoria RAM de 64 GB. Los compiladores utilizadoshan sido gcc 4.4.5, y OpenMPI 1.4.2. Toda lacomparativa ha sido realizada considerando dos instanciasdel 2dpp. La primera viene caracterizada porlos siguientes parámetros: X = 10, Y = 10, N = 99,y contiene 9032 posibles parejas. La segunda es laque se propuso para la competición. Sus parámetrosson los siguientes: X = 20, Y = 20, N = 399, ycontiene 15962 posibles parejas.Dado que los algoritmos considerados en este trabajono son deterministas, cada ejecución se harepetido 30 veces, y las comparativas han sido realizadasaplicando test estadísticos. Primero, se llevaa cabo el test de Shapiro-Wilk para comprobar silos resultados siguen una distribución normal. Encaso afirmativo, se lleva a cabo el test de Levenepara comprobar la homogeneidad de las varianzas.Si los resultados tienen igual varianza, se comparanlos datos con el test anova. En los casos en que losdatos no cumplen con una distribución normal, selleva a cabo el test de Welch. Los test se han llevadoa cabo con un nivel de confianza del 95%.En el primer experimento se analizan el comportamientode las diferentes multiobjetivizacionespropuestas. Se han analizado los resultadosobtenidos con el algoritmo memético multi-objetivoal utilizar las 7 multiobjetivizaciones propuestas enla Sección III-D. En el caso de dbi thr el valorp se fijo a 0.99. Los resultados han sido comparadoscon los obtenidos con la versión mono-objetivadel 2dpp. En dicho caso el algoritmo utilizado esVarPopEA. En todos los casos los algoritmos fueronejecutados durante 24 horas. En los casos multiobjetivizadosse utilizado una población de tamaño 10.El resto de parámetros han sido comunes para todaslas configuraciones. En concreto se utilizaron lasmejores parametrizaciones de VarPopEA publicadasJP2011-42

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fitness5.10e+08 5.13e+08 5.16e+08Primera InstanciaFitness1.000e+09 1.010e+09 1.020e+09Segunda InstanciaMultiIsland MonoIsland ADI VarPopEAMonoIsland MultiIsland VarPopEA DBI_THRFig. 3.Boxplots de la Primera Instancia (12 Horas)Fig. 5.Boxplots de la Segunda Instancia (12 Horas)Primera InstanciaSegunda Instancia11Ratio de Exito0.80.60.40.2MultiIslandMonoIslandADIVarPopEARatio de Exito0.80.60.40.2MonoIslandMultiIslandVarPopEADBI_THR00 5000 10000 15000 20000 25000 30000 35000 40000Tiempo (s)00 5000 10000 15000 20000 25000 30000 35000 40000Tiempo (s)Fig. 4.RLD de la Primer InstanciaFig. 6.RLD de la Segunda Instanciaen [4]. En el operador umd se fijo min p m = 0.1 ymax p m = 0.15. En el operador ssx se utilizó p c = 1.La Figura 1 muestra, para la primera instancia,la evolución del fitness medio de los distintos esquemas.Se puede apreciar que cuatro modelos multiobjetivizadoshan sido capaces de superar a VarPopEA.Los test estadísticos revelan que las diferencias entrelas tres mejores configuraciones multiobjetivizadas yVarPopEA son significativas. La Figura 2 muestrala evolución para la segunda instancia. En este casoVarPopEA es el algoritmo que mejores resultadosobtuvo. Además, las diferencias con respecto a todaslas versiones multiobjetivizadas se confirman estadísticamente.De esta forma, con las parametrizacionesrealizadas, la adecuación o no de las multiobjetivizacionesdepende de la instancia a resolver. Taly como se había mencionado anteriormente, la utilidadde las multiobjetivizaciones es dependiente delproblema e incluso instancia, lo que se ha confirmadocon los resultados obtenidos para el 2dpp.Se hizo además, un segundo experimento, con el finde validar la utilización del modelo basado en islaspara paralelizar el método anterior. Concretamentese hizo uso una comparativa entre dos modelos homogéneos.En el primer de ellos (Mono-Island), encada isla se utilizó la definición original del 2dpp,junto con el VarPopEA. En el otro (Multi-Island),se utilizó en cada isla la multiobjetivización quemejores resultados obtuvo en el primer experimentopara cada instancia. Ambos modelos fueron ejecutadoscon cuatro islas, estableciendo un criterio deparada de 12 horas. La Figura 3 muestra, parala primera instancia, los boxplots de los resultadosobtenidos por las estrategias secuenciales y paralelasa las 12 horas de ejecución. Se puede apreciar queambos modelos paralelos fueron capaces de obtenermejores resultados que los correspondientes secuenciales.Además, también se aprecian las ventajasde utilizar la multiobjetivización para esta instancia.La Figura 5 muestra la misma información parala segunda instancia. Al igual que en la primer instanciala ventaja de los modelos paralelos es clara.Sin embargo, en este caso, los mejores resultadosson obtenidos con los modelos mono-objetivo. Esteanálisis ha demostrado la utilidad de los modelos paralelosen términos de la calidad obtenida al final delas ejecuciones. Sin embargo, es importante cuantificarla ganancia que cada modelo ha conseguidoen relación a su versión secuencial. Para ello se hanutilizado las Run-length Distributions (rld). Lasrld muestran la relación entre el tiempo y el porcentajede veces que un determinado modelo es capazde alcanzar una determinada calidad de soluciones(fitness objetivo). Se calcularon las rld paralos mejores modelos mono-objetivo y multi-objetivo,así como para sus parelizaciones. El fitness objetivose fijó al fitness medio alcanzado por el peor de losmodelos anteriores. La Figura 4 muestra la rld parala primera instancia. Muestra la clara superioridadde los modelos paralelos. Considerando el tiempo requeridopara obtener un 50% de porcentaje de éxitose han obtenido aceleraciones superlineales en amboscasos. Los modelos paralelos han sido capaces deevitar mínimos locales en los que los modelos secuen-JP2011-43

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ciales se estancaban. En la Figura 6 se muestran lasrld de la segunda instancia. En este caso, al considerarun porcentaje de éxito del 50% se han obtenidoaceleraciones de 1.95 para Mono-Island, y de 2.42en Multi-Island. Al considerar otros porcentajes deéxito la aceleración ha variado ligeramente. Concretamente,al utilizar porcentajes entre el 25% y el75%, la aceleración ha variado entre 1.95 y 2.13 paralas versiones mono-objetivas y entre 1.89 y 2.13 enlas versiones multi-objetivas.VI. Conclusiones y Trabajos FuturosEl problema de empaquetado es un problema deoptimización np-completo con múltiple aplicacionesprácticas. En este trabajo se ha abordado una variantedel mismo (2dpp) que fue propuesta en lasesión de competiciones del gecco 2008. Hastael momento, los mejores resultados para el mismohabían sido obtenidos por un algoritmo meméticomono-objetivo denominando VarPopEA. Sin embargo,se sabía que este esquema en ocasiones sufríade estancamiento en mínimos locales. En esteartículo se ha analizado la utilización de la técnicadenominada multiobjetivización, como una estrategiapara facilitar el escape de mínimo locales. Sehan analizado varias multiobjetivizaciones, a las quese les ha aplicado un algoritmo memético basado enel nsga-ii. Los resultados obtenidos han mostradoque multiobjetivizar el 2dpp es útil para algunas instancias,pero no para todas. Por tanto, la técnicamás adecuada depende de la instancia a resolver.Debido a esto, la aplicación de hiperheurística al2dpp parece muy prometedor. Dado que éstas suelenser utilizadas junto con el modelo de paralelizaciónbasado en islas, se ha analizado la adaptación del modelobasado en islas al 2dpp. Concretamente, se haanalizado el modelo homogéneo tanto mono-objetivo,como multiobjetivizado. Los resultados computacioneshan mostrado que esta paralelización ha aportadobeneficios en términos de calidad de solucionesy ahorro de tiempo.El trabajo futuro se enfocará en la aplicaciónde hiperheurísticas paralelas multiobjetivizadas al2dpp. Por ello, sería interesante realizar un estudiode la escalabilidad del modelo basado en islas.Además, dado que los modelos mono-objetivose comportan mejor que los multiobjetivizados paraalgunas instancias, sería interesante desarrollar unahiperheurística que pueda combinar esquemas de optimizaciónmono-objetivos y multi-objetivos.AgradecimientosEste trabajo ha sido financiado con fondos ec(feder) y del Ministerio de Ciencia e Innovación,dentro del ‘Plan Nacional de i+d+i’ con el proyectocon número de referencia tin2008-06491-c04-02.Parte del trabajo también ha sido financiado confondos del Gobierno de Canarias correspondientes alproyecto pi2007/015. El trabajo de Carlos Segura yde Eduardo Segredo ha sido financiado con las becasfpu-ap2008-03213 y fpu-ap2009-0457.Referencias[1] Yew-Soon Ong, Meng-Hiot Lim, Ning Zhu, and Kok WaiWong, “Classification of adaptive memetic algorithms: acomparative study,” IEEE Trans. on Systems, Man, andCybernetics, Part B, vol. 36, no. 1, pp. 141–152, 2006.[2] Enrique Alba, Parallel Metaheuristics: A New Class ofAlgorithms, Wiley-Interscience, 2005.[3] C. A. Coello, G. B. Lamont, and D. A. Van Veldhuizen,Evolutionary Algorithms for Solving Multi-Objective Problems, Genetic and Evolutionary Computation.Springer, 2007.[4] Coromoto Leon, Gara Miranda, and Carlos Segura, “Amemetic algorithm and a parallel hyperheuristic islandbasedmodel for a 2d packing problem,” in Proceedings ofthe 11th Annual conference on Genetic and evolutionarycomputation, New York, NY, USA, 2009, GECCO ’09,pp. 1371–1378, ACM.[5] Fred W. Glover and Gary A. Kochenberger, Handbook ofMetaheuristics (International Series in Operations Research& Management Science), Springer, January 2003.[6] Joshua D. Knowles, Richard A. Watson, and DavidCorne, “Reducing local optima in single-objective problemsby multi-objectivization,” in Proceedings of theFirst International Conference on Evolutionary Multi-Criterion Optimization, London, UK, 2001, EMO ’01,pp. 269–283, Springer-Verlag.[7] Dimo Brockhoff, Tobias Friedrich, Nils Hebbinghaus,Christian Klein, Frank Neumann, and Eckart Zitzler,“Do additional objectives make a problem harder?,” inProceedings of the 9th annual conference on Genetic andevolutionary computation, New York, NY, USA, 2007,GECCO ’07, pp. 765–772, ACM.[8] Carlos Segura, Gara Miranda, and Coromoto León, “Parallelhyperheuristics for the frequency assignment problem,”Memetic Computing, pp. 1–17, 2010.[9] Minh Nghia Le, Yew-Soon Ong, Yaochu Jin, and BernhardSendhoff, “Lamarckian memetic algorithms: localoptimum and connectivity structure analysis,” MemeticComputing, vol. 1, no. 3, pp. 175–190, 2009.[10] Poonam Garg, “A comparison between memetic algorithmand genetic algorithm for the cryptanalysis of simplifieddata encryption standard algorithm,” InternationalJournal of Network Security & Its Applications,vol. 1, no. 1, pp. 34 – 42, April 2009.[11] Q. H. Nguyen, Y. S. Ong, and M. H. Lim, “A ProbabilisticMemetic Framework,” IEEE Trans. EvolutionaryComputation, vol. 13, no. 3, pp. 604–623, 2009.[12] Karthik Sindhya, Ankur Sinha, Kalyanmoy Deb, andKaisa Miettinen, “Local search based evolutionary multiobjectiveoptimization algorithm for constrained and unconstrainedproblems,” in Proceedings of the Eleventhconference on Congress on Evolutionary Computation,Piscataway, NJ, USA, 2009, CEC’09, pp. 2919–2926,IEEE Press.[13] L. Darrell Whitley, V. Scott Gordon, and Keith E. Mathias,“Lamarckian evolution, the baldwin effect and functionoptimization,” in Proceedings of the InternationalConference on Evolutionary Computation. The ThirdConference on Parallel Problem Solving from Nature:Parallel Problem Solving from Nature, London, UK,1994, PPSN III, pp. 6–15, Springer-Verlag.[14] Zhan-fang Zhao Li-xiao Ma, Kun-qi Liu and Ning Li,“Exploring the effects of lamarckian evolution and baldwineffect in differential evolution,” in Communicationsin Computer and Information Science. 2010, vol. 107 ofComputational Intelligence and Intelligent Systems, pp.127–136, Springer.[15] Quang Huy Nguyen, Yew Soon Ong, and Meng Hiot Lim,“Non-genetic transmission of memes by diffusion,” inProceedings of the 10th annual conference on Geneticand evolutionary computation, New York, NY, USA,2008, GECCO ’08, pp. 1017–1024, ACM.[16] Andrzej Jaszkiewicz, “Genetic local search for multiobjectivecombinatorial optimization,” European Journalof Operational Research, vol. 137, no. 1, pp. 50 – 71,2002.[17] Tzung-Pei Hong, Ming-Wen Tsai, and Tung-Kuan Liu,“Two-dimentional encoding schema and genetic operators,”in JCIS. 2006, Atlantis Press.[18] David A. Van Veldhuizen, Jesse B. Zydallis, and Gary B.Lamont, “Considerations in engineering parallel multiobjectiveevolutionary algorithms,” IEEE Trans. EvolutionaryComputation, vol. 7, no. 2, pp. 144–173, 2003.JP2011-44

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Diseño de Filtros con Técnicas Evolutivas parala Clasificación de Señales de EncefalogramaCoromoto León, Yanira González y Carlos Segura 1Resumen— Las interfaces cerebro-máquina (bci,Brain Computer Interface) permiten crear un canalde comunicación directo entre el cerebro humano y uncomputador. En este campo, uno de los principalesproblemas es la clasificación de las señales de encefalograma(eeg) capturadas. Investigaciones previashan demostrado que las técnicas de clasificación mejoransi la señal eeg es preprocesada. Generalmente, elpreproceso se realiza a través de la aplicación de unconjunto de filtros. En este trabajo se han usado algoritmosevolutivos para generar filtros de preprocesadoque optimicen la clasificación. Este esquema hahecho uso de una formulación multi-objetiva del problema.En primer lugar, se ha analizado la influenciade los operadores genéticos en el correcto desempeñode las técnicas. Además, con el objetivo de acelerarla generación de los filtros se ha aplicado un modeloparalelo basado en islas. Los resultados computacionaleshan mostrado la importancia de utilizaruna variación genética adecuada. Además, se ha comprobadola importancia de configurar correctamenteel modelo basado en islas para conseguir reducir eltiempo requerido para obtener filtros adecuados.Palabras clave— Interfaz Cerebro-Máquina, Clasificación,Modelos Paralelos basados en Islas.I. IntroducciónUNA interfaz cerebro-máquina o bci (BrainComputer Interface) es un canal de comunicacióndirecto entre el cerebro humano y un computador[1], [2]. Este tipo de sistemas tienen aplicacionesprácticas en múltiples campos, como en eldiseño de sistemas robóticos [3], en la asistencia a pacienteincapacitados [4], o en la eleboración de videojuegos[5], [6]. Atendiendo a su nivel de intrusismolos sistemas bci se pueden clasificar en invasivos, parcialmenteinvasivos, y no invasivos [7]. Los bcis noinvasivos son los más empleados ya que no requierende cirugía para su utilización. En este grupo de interfaces,los más comunes están basados en el uso delas señales de electro-encefalograma (eeg) emitidaspor las células nerviosas del córtex cerebral. Estossistemas tratan de explotar la relación existente entrelos pensamientos y las señales eeg. Las señaleseeg se capturan mediante la utilización de un conjuntode electrodos dispuestos sobre el cuero cabelludo.Existen estudios que han analizado [8] cómodeben ubicarse estos electrodos, así como su relacióncon los patrones generados. Existen otras señales quetambién pueden ser empleadas por los sistemas bci.Cabe destacar las señales basadas en la magnetoencefalografía(meg) o las imágenes por resonanciamagnética funcional (firm, functional magnetic resonanceimaging).1 Dpto. de Estadística, I.O y Computación, Universidadde La Laguna, Edificio de Física y Matemáticas, Avda. AstrofísicoFco. Sánchez s/n, 38271 La Laguna, Tenerife, e-mail:(cleon|ygonzalez|csegura)@ull.es.El principal reto en los sistemas bci basados eneeg es diseñar un sistema de clasificación que, dadauna señal eeg, permita discriminar entre un conjuntode pensamientos. Dado que la relación entrepensamiento y señales eeg difiere entre personas, lossistemas de clasificación se deben personalizar paracada sujeto. Por este motivo, se suelen empleartécnicas de aprendizaje automático [9], cuyo fin esdiseñar sistemas de clasificación de señales eeg paraun individuo concreto. Estos clasificadores son entrenadosa partir de datos generados por el sujeto através de un aprendizaje supervisado.Generalmente, los datos capturadas por los electrodosson preprocesados con el fin de facilitar laclasificación. Existen tres clases de transformacionescomúnmente usadas: el filtro espacial (L), la transformadade Fourier (FFT, Fast Fourier Transform)y el filtro pasa banda (B). El filtro espacial seaplica sobre la señal en bruto, realizando transformacionesen el dominio del tiempo. La transformada deFourier transforma la señal al dominio de la frecuencia.Finalmente, el filtro pasa banda (B), seleccionalas bandas de frecuencia que van a ser consideradaspor el sistema de clasificación. Generalmente, sólo seconsideran frecuencias entre los 8 y 30Hz.En [10] se aplicó un algoritmo basado en estrategiasevolutivas al diseño automático del filtro espacialy el filtro pasa-banda. Una vez aplicado el filtro,se hacía uso del clasificador lineal de Fisher (fd,Fisher Discriminant). El estudio fue realizado conlas señales eeg publicadas en [11]. A partir de losdatos obtenidos por 32 sensores se debía clasificar laseñal en 3 clases diferentes. Las estrategias diseñadasfueron capaces de generar filtros que alcanzaron tasasde error similares a las obtenidas por filtros generadospor expertos. En este trabajo se analiza laaplicación de un Algoritmo Evolutivo Multi-Objetivo(moea - Multi-objective Evolutionary Algorithms) auna formulación multiobjetiva del bci. El propósitoes diseñar un método que sea capaz de alcanzar erroressimilares o mejores que los ya publicados, y queevite el estancamiento en mínimos locales. En laformulación aplicada se intentan minimizar la tasade error del clasificador y el número de bandas defrecuencia consideradas. La utilización del segundoobjetivo tiene como propósito posibilitar el escape demínimos locales. Sin embargo, dado que el objetivofinal sigue siendo minimizar la tasa de error, los resultadosse han analizado considerando como únicoobjetivo la minimización de dicha tasa. Se ha realizadoun análisis sobre la influencia de los operadoresgenéticos en el correcto desempeño de estas técnicas.La obtención de filtros de alta calidad con laJP2011-45

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011técnica propuesta conlleva realizar ejecuciones delarga duración. Con el fin de reducir el tiempo de ejecuciónde los algoritmos evolutivos (eas), se han propuestovarios modelos paralelos [12]. Entre los modelosexistentes, el modelo basado en islas [13] aportavarios beneficios notables: se adapta fácilmente alas arquitecturas paralelas, permite extender el espaciode búsqueda de soluciones pudiendo evitar lacaída en óptimos locales, y puede ser utilizado juntoa las hiperheurísticas para diseñar métodos de optimizaciónmás generales. Además, han mostradobuen rendimiento y estabilidad en muchas áreas [12].En este trabajo, se ha analizado la adecuación delmodelo paralelo basado en islas para el bci.El resto del artículo se estructura de la siguientemanera: en la Sección II se da una visión de comose realiza el preprocesamiento de la señal eeg. En laSección III se detalla la evolución de los filtros L yB. En la Sección IV se describen los algoritmos evolutivosy operadores géneticos empleados. El modeloparalelo basado en islas se detalla en la Sección V.En la Sección VI se definen los experimentos realizados,y se analizan los resultados computacionalesobtenidos con las técnicas descritas. Finalmente, enla Sección VII se presentan las conclusiones y algunasposibles líneas de trabajo futuro.II. Preprocesamiento Señales eegCon el objetivo de entrenar un clasificador dependientedel usuario, es necesario almacenar los datoseeg generados durante las sesiones de adquisición.Los datos eeg en bruto no se suelen usar directamentepara el entrenamiento, sino que se preprocesancon un conjunto de filtros. Finalmente, se procedecon la fase de aprendizaje del clasificador. Esteproceso se lleva a cabo en modo off-line. Los filtrosobtenidos junto con el clasificador podrán ser usadosmás tarde de forma on-line por el sujeto. Durantela etapa on-line, los datos eeg son primeropreprocesados, luego clasificados, y finalmente usadospara el control de periféricos o dispositivos. Enprácticamente todos los casos de bcis existe un modelode retroalimentación, donde el sujeto observa larespuesta del sistema a las señales producidas porel cerebro. Este circuito cerrado exige un aprendizajemutuo donde la máquina aprende de los datosobtenidos, y el sujeto de la respuesta obtenida.En este trabajo, el preprocesamiento se inicia aplicandoun filtro espacial sobre los datos almacenadosen la sesión de adquisición de datos. A los datosresultantes de este proceso se le aplica la TransformadaRápida de Fourier (fft), transformando laseñal al dominio frecuencial, donde es posible detectarmás fácilmente algunas características, como lasSMR (sensorimotor rythm). Finalmente, se seleccionanlas bandas de frecuencia más relevantes con elfiltro pasabanda. En esta sección, se explica cómo seproduce el preprocesado de la señal asumiendo queel filtro espacial ya ha sido ajustado, y que el filtropasabanda ya ha sido seleccionado. Eliminando,con este último, las frecuencias que no interesan yal mismo tiempo intentando reducir la información aextraer para simplificar la tarea del clasificador.Inicialmente, la señal eeg recogida a partir dec electrodos es discretizada usando una frecuenciade muestreo f, que representa el número de muestrasrecogidas por segundo (Hz). Si la sesión deadquisición dura n segundos, se genera una serie temporalde f ∗ n puntos. En cada instante, sólo unaparte de la señal eeg es considerada. Se denota comoS n a la enésima parte de la eeg. S n es una matriz t xc, donde t = s∗f, siendo s la duración del fragmentode señal seleccionado, y f la frecuencia de muestreo.La primera fase de la etapa de preprocesamiento(filtro espacial) se representa a través de laecuación 1. El filtro espacial L es una matriz c xc ′ . Si c ′ = c entonces, S ′ n tiene el mismo númerode columnas (canales) que la matriz original S n . Elnúmero de canales de S ′ n se reduce en el caso quec ′ < c. En cierto sentido, el filtro espacial L transformael número de canales c original a c ′ .S ′ n = S n ∗ L (1)La segunda fase en el preprocesamiento de la señaleeg consiste en transformar la señal desde el dominiotemporal al dominio frecuencial aplicando lafft. Puesto que la fft es aplicada sobre una parteS ′ n de la señal se ha optado por usar la transformadade Fourier de corta duración (stft, Short Time FastFourier). La aplicación de la stft sobre S ′ n vienerepresentada en la ecuación 2.S ′′n = |F F T (S′ n )| (2)donde el operador || computa el módulo de cadauno de los componentes de la matriz resultante dela fft. La fft devuelve un número complejo, confase y módulo, pero muchas investigaciones realizadassobre el bci tratan únicamente el módulo [14],por lo que en este caso se ha ignorando la fase. S ′′nen la ecuación 2 es igualmente una matriz de t xc ′ , pero ahora las filas de la matriz pertenecen aldominio de la frecuencia. Tras aplicar la transformaciónfft, las filas desde la 1 hasta la t/2 de lamatriz S ′′n representan el conjunto de bandas de frecuencias[0 − f/2]Hz (donde f es la frecuencia demuestreo y t el tamaño de la ventana), con una resoluciónδf = (f/t)Hz. Las bandas de frecuenciascontenidas en la matriz son [0 − δf], [δf − 2 ∗ δf],etc. En ocasiones, la resolución δt es más pequeñade lo necesario, así que es conveniente trabajar conunas bandas de frecuencias más amplias. Es conocido,que las frecuencias fuera del rango [8 − 30]Hzno contienen información fisiológica de interés para elbci. Por lo tanto, únicamente se seleccionan las filasque se encuentran desde ⌈8/δf⌉+1 hasta ⌈30/δf⌉+1.Con el propósito de simplificar la notación, se asumeque S ′ n está compuesta únicamente por aquellas bandasde frecuencias en la que existe información fisiológica.El número de filas restantes en S ′′n est ′ = ⌈8/δf⌉ − ⌈30/δf⌉ + 1.JP2011-46

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011La última fase del preprocesado de la señal eegselecciona el conjunto de bandas de frecuencias másrelevantes para un usuario en particular. Este pasoes representado por el filtro B en la ecuación 3. Bes una matriz con dimensiones iguales a S ′′n , perocompuesta sólo por valores binarios (0 ó 1). Así,si la componente B(i, j) = 0 entonces, S ′′n (i, j)será eliminada del conjunto de bandas de frecuenciasdisponibles. Solamente aquellas componentes de(i, j) con B(i, j) = 1 permanecen intactas.S ′′nS ′′′n= S′′ n ⊗ B (3)La ecuación 4 resume las fases del preprocesadosobre la matriz S n para generar una instancia de entrenamiento.Algorithm 1 Pseudocódigo de un ea1: Generar población inicial2: Evaluar individual de la población3: while (criterio de parada no se cumpla) do4: Selección de padres5: Aplicar operador de crossover con probabilidad p c6: Aplicar operador de mutación con probabilidad p m7: Evaluar los nuevos individuos8: Selección de supervivencia9: end whilesi i pertenece al resto de clases. Cada F D i (x) es unhiperplano representado por F D i (x) = w i ∗ x + b i .La ecuación 5 presenta cómo se clasifica una instanciax empleando el enfoque uno contra todos en elclasificador lineal fd. Se elige el valor i tal que F D ies máximo.F D(x) = arg max i (F D i (x)) = arg max i (w i ∗ x + b i ) (5)I n = flatten(|(F F T (S n ∗ L))| ⊗ B) (4)donde flatten construye una lista con todas componentesde la matriz.III. Evolución del Filtro Espacial ySelección de FrecuenciasEl objetivo de este trabajo es evolucionar el filtroespacial L y seleccionar el conjunto de bandasde frecuencias B, que optimicen la operación de unclasificador C. Ambos filtros son evolucionados deforma conjunta. Con el propósito de resolver elproblema haciendo uso de algoritmos evolutivos sedeben definir, la representación de las soluciones candidatas(cromosoma) y las función de optimización.El cromosoma contiene los parámetros que seránoptimizados, es decir, la matriz de filtro espacial Ly el filtro de selección de frecuencias B. Ambas matricesse codifican de forma directa en el cromosoma.La matriz L está compuesta por número reales, mientrasque la matriz B es un vector de números binarios.Con el fin de evaluar la calidad de los filtrosL y B codificados en el cromosoma, un clasificadorC es construido sobre el conjunto de datos de entrenamientoI n generados a partir de los datos eeg deentrenamiento. El objetivo de la clasificación consisteen identificar a qué clase pertenece un determinadoobjeto (señal en el caso considerado). Unclasificador lineal logra esto tomando una decisión declasificación basada en el valor de una combinaciónlineal de sus características. En este trabajo, se hautilizado el clasificador lineal de Fisher (fd, FisherDiscriminant). Se ha elegido el fd porque estudiosprevios han demostrado que el mismo puede ser unabuena opción para esta área.Con el fin de hacer frente a problemas multiclases,el enfoque de uno contra todos es aplicado para elfd. Un problema de clasificación de N c clases estransformado a N c problemas de clasificación binarios,donde el objetivo es separar la clase i del restode clases. Los clasificadores binarios tienen comoobjetivo diseñar una función de clasificación tal queF D i (x) > 0 si x pertenece a la clase i y F D i (x) < 0En el presente trabajo, las soluciones candidatasson evaluadas acorde a dos objetivos: el error de entrenamientodel clasificador fd y el número de bandasde frecuencias seleccionadas. El error de entrenamientoes el error que se comete al clasificar lasinstancias I n , tras aplicar un determinado preprocesamientoy el discriminante de Fisher. El número debandas de frecuencias seleccionadas es dado por elnúmero de componentes con valor 1 en B. Ambosobjetivos son a minimizar.IV. Algoritmos Evolutivos yOperadores GenéticosLas técnicas de optimización multi-objetivo tratande obtener un conjunto de individuos no dominados,lo más cercano posible al Frente de Pareto.Entre estas estrategias cabe destacar los algoritmosevolutivos multi-objetivo (Multi-Objective OptimizationEvolutionary Algorithms - moeas). Se tratade técnicas que se inspiran en la evolución de lanaturaleza para realizar la optimización. El Algoritmo1 muestra un pseudocódigo de un ea. Losmoeas han demostrado ser métodos adecuados paraabordar problemas de optimización complejos. Estetipo de estrategias se basan en mantener de formaparalela un conjunto de soluciones candidatas queluchan y cooperan entre ellas para mejorar las solucionesobtenidas. La codificación de los individuosconsiste en un string real/binario, con tantos genescomo valores en los filtros L y B. Cada gen binariorepresenta si se selecciona o no una determinadabanda de frecuencia, mientras que los valores realesdeterminan los valores del filtro espacial.Los moeas están basados en unos patrones comunes.Sin embargo, existen diversas formas de llevarestas ideas a la práctica. Por ello han surgido enla literatura una gran cantidad de moeas. Con el finde comprobar la adaptación de estas estrategias albci se escogió Non-Dominated Sorting Genetic AlgorithmII [15] (nsga2), uno de los algoritmos evolutivosmulti-objetivo más populares.Los moeas están basados en una fase de variaciónen la se deben aplicar operadores de cruce y mutaciónJP2011-47

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011a un conjunto de individuos que son seleccionadospor cada estrategia. Tal y como se puede observaren el Algoritmo 1 estos operadores son aplicados conuna probabilidad p c y p m , respectivamente. El funcionamientode estos operadores no viene determinadopor cada algoritmo, sino que se deben escogerde forma independiente. En este trabajo se analizael comportamiento de los algoritmos anteriores haciendouso de diversos operadores de variación. Dadoque el cromosoma está formado por una parte real yotra binaria se han empleado operadores de variaciónde ambos tipos. En el cruce de individuos se hantesteado los operadores de cruce de un punto (opc -One Point Crossover) y el cruce uniforme (ux) parala parte binaria. El cruce en la parte real siempreha sido realizado utilizando el cruce uniforme (ux -Uniform Crossover). En la proceso de mutación deindividuos se ha testeado la mutación uniforme (um)y la mutación polinomial (pol - Polynomial Mutation)para la parte real. En la parte binaria en todocaso se ha aplicado el operador Binary Flip Mutation.V. Modelos Basados en islasLos modelos basados en islas dividen la poblaciónoriginal en un conjunto de sub-poblaciones independientes.Cada sub-población es asociada a unaisla, y sobre cada isla se ejecuta una configuraciónde moea de forma independiente durante un ciertotiempo. Una configuración está constituida porun algoritmo de optimización con sus respectivosparámetros. Generalmente, cada procesador constituyeuna isla, de forma que cada isla evolucionaen paralelo de forma independiente. Sin embargo,dado que los esquemas colaborativos suelen alcanzarmejores resultados, se incluye una fase de migraciónque permite el intercambio de individuos entre islas.Este comportamiento colaborativo añade al esquemabasado en islas la posibilidad de obtener un mejorcomportamiento. Existen cuatro modelos basados enislas diferentes [13]: todas las islas ejecutan la mismaconfiguración (homogéneo), todas las islas ejecutanuna configuración diferente (heterogéneo), cada islaevalúa un subconjunto diferente de funciones objetivoy cada isla representa una región distinta en losdominios del fenotipo o del genotipo. En este trabajose analiza el modelo de islas homogéneo. En este modelotodas las islas ejecutan la misma configuraciónde un moea. En esta clase de modelo paralelo, elproceso de migración que permite el intercambio deindividuos entre islas es esencial. Dado que cadaalgoritmo evolutivo podría explorar regiones del espaciodiferentes, este mecanismo puede permitir enriquecerlas soluciones locales de cada isla, pudiendoobtenerse a la larga una mayor eficiencia en el esquema[16]. Para definir el esquema de migraciónse deben especificar una serie de componentes: latopología de migración (identifica hacía donde migranlos individuos), el ratio de migración (númerode individuos a migrar), el porcentaje de migración(determina con qué frecuencia se migra), la estrate-Error de Entrenamiento (%)Fig. 1.0.380.360.340.320.30.280.26UX_POLUX_UMOPC_POLOPC_UM0.240 1000 2000 3000 4000 5000 6000 7000EvaluacionesEvolución del Porcentaje de Error de Entrenamientogia de selección de individuos a migrar y la estrategiade reemplazamiento en la isla destino. Otra decisiónque puede influir enormemente en los resultados finaleses el tamaño de las subpoblaciones [16]. Algunosautores dividen la población original usada enlos esquemas secuenciales, de forma que la suma delas subpoblaciones sea igual a dicha población original.En otros casos se usan poblaciones tan grandescomo en el esquema secuencial. Cada uno de estosesquemas tiene ventajas y desventajas.VI. Resultados ComputacionalesEn esta Sección se describen los experimentos llevadosa cabo con los diferentes esquemas de optimizaciónpresentados en la Sección IV, así comosus paralelizaciones. Las pruebas se han lanzadoen una máquina con sistema operativo DebianGNU/Linux, 4 procesadores amd R○ Opteron TM(modelo 6164HE) que corren a 1.7 GHz, y con unamemoria RAM de 64 GB. El compilador utilizadoha sido gcc 4.4.5. El compilador mpi ha sido Open-MPI 1.4.2. La validación ha sido realizada utilizandolos datos proporcionados por el instituto de investigaciónIDIAP [11]. Concretamente se ha utilizado elSujeto 1 del conjunto de datos V. Para este sujeto sedisponen de 4 sesiones. Las 3 primeras han sido utilizadascomo conjunto de entrenamiento, mientrasque la última fue utilizada como conjunto de validación.Se han analizado los resultados tanto parael conjunto de entrenamiento como para el conjuntode validación. Ambos análisis han llevado a similaresconclusiones. Por ello, sólo se presentan resultadoshaciendo uso del conjunto de entrenamiento.Dado que los algoritmos considerados en este trabajono son deterministas, cada ejecución se harepetido 30 veces, y las comparativas han sido realizadasutilizando los siguientes test estadísticos [17].Primero, se aplica el test de Shapiro-Wilk para comprobarsi los resultados siguen una distribución normal.En caso afirmativo, se lleva a cabo el test deLevene para comprobar la homogeneidad de las varianzas.Si los resultados tienen igual varianza, secomparan los datos con el test anova. En los casosen que los datos no cumplen con una distribuciónnormal, el test de Welch es aplicado. Los test se hanllevado a cabo con un nivel de confianza del 95%.JP2011-48

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IComparativa Estadística de los Modelos SecuencialesOPC UM OPC POL UX UM UX POLOPC UM ↔ ↑ ↑ ↑OPC POL ↓ ↔ ↔ ↔UX UM ↓ ↔ ↔ ↑UX POL ↓ ↔ ↓ ↔TABLA IIAceleración del Modelo Paralelo Basado en IslasSubPop = 8 SubPop = 30p m = 0.1 1.38 1.30p m = 0.5 1.63 1.44p m = 1 1.7 1.441.21Island-Model (SubP 8)Island-Model (SubP 30)OPC_UMRatio de Exito0.80.60.40.205000 10000 15000 20000 25000 30000 35000 40000 45000Tiempo (s)Fig. 2.Errores de entrenamiento en 22000 sFig. 3.RLD de los mejores modelos secuenciales y paralelosEn el primer experimento se ha analizado el comportamientode los algoritmos evolutivos al ser aplicadosde forma secuencial. Se ha utilizado el algoritmoevolutivo multi-objetivo Non-Dominated SortingEvolutionary Algorithm-II (nsga2). Con el finde analizar la influencia de los operadores genéticosen el correcto desempeño de las técnicas, éste hasido ejecutado con los operadores genéticos previamentepresentados. Concretamente, se han ejecutados4 configuraciones que combinan los operadoresde cruce binario opc y ux, con los operadores demutación real um y pol. El valor p c fue fijado a 1 entodo caso. Por su parte, p m fue fijado a 1 Men para losoperadores de mutación binaria, siendo M el númerode genes de la parte binario, y a 1 Npara los operadoresde mutación real, siendo N el número de genesde la parte real. Estas configuraciones serán referenciadascon la forma X Y , en donde X es el crucebinario utilizado, e Y es la mutación real aplicada.Las configuraciones fueron ejecutadas estableciendocomo criterio de parada la ejecución de 7000 evaluaciones.La Figura 1 muestra la evolución del error deentrenamiento para cada configuración. En la mismapodemos observar que los resultados obtenidos por laconfiguración con mutación um y cruce opc superanal resto de configuraciones. La Tabla I muestra losresultados de los tests estadísticos realizados para estasconfiguraciones con los resultados obtenidos alfinal de las ejecuciones. En cada celda se indicasi la configuración correspondiente a dicha fila esestadísticamente superior (↑), no diferente (↔), opeor (↓), que la configuración correspondiente a lacolumna. Los test estadísticos confirman la superioridaddel modelo opc um, mostrando la importanciade seleccionar correctamente la variación genética.Se hizo además, un segundo experimento, con elfin de validar la utilización del modelo basado enislas para paralelizar el método anterior. Concretamentese aplicó el modelo basado en islas ho-mogéneo, utilizando la mejor configuración encontradaen el primer experimento. Los tests fueron realizadosutilizando cuatro islas. Se ejecutaron seisconfiguraciones diferentes de este modelo, combinandotres valores diferentes de probabilidades demigración, con dos valores diferentes de tamaños delas subpoblaciones. Las probabilidades de migracióntesteadas fueron: 0.1, 0.5 y 1. Los tamaños de lassubpoblaciones fueron 8 y 30. De esta forma, al utilizarel valor 8, la población del método secuencialoriginal se está distribuyendo entre las islas, mientrasque al utilizar el valor 30 se está haciendo crecerla población original. La migración se configuró conuna topología en anillo, y se hizo uso de esquemasde selección y reemplazo elitistas. Concretamente,sólo se producían migraciones cuando se generabanindividuos hijos mejores que cualquiera de los individuosde la población padre. El reemplazamiento enlas islas destino, es realizado mediante el esquemaElitist Ranking [16]. Este esquema utiliza el operadorde crowding del nsga2 para separar el frenteoriginal en subfrentes. Finalmente, se reemplaza unindividuo del peor subfrente. La Figura 2 muestralos boxplots del error de entrenamiento alcanzado en2200 segundos por la mejor configuración secuencial(opc um), y por las cuatro mejores configuracionesparalelas. Se aprecia que las configuraciones paralelasson capaces de alcanzar errores menores que laconfiguración secuencial. Además, los modelos queutilizan tamaños de subpoblación 8 han obtenidoserror ligeramente menores que los que han utilizadosubpoblaciones de tamaño 30. Estos resultados indicanque los modelos paralelos son capaces de acelerarla convergencia a filtros de alta calidad. Sinembargo, dado que éstos están usado más recursoscomputaciones, dicha mejora debe ser cuantificada.Para ello se han utilizado las Run-length Distributions[18] (rld). Las rld muestran la relación entreel tiempo y el porcentaje de veces que un determinadomodelo es capaz de alcanzar una determinadaJP2011-49

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011calidad de soluciones (porcentaje de error). Se calcularonlas rld para la mejor configuración secuencialy para todos los modelos paralelos. El error objetivose fijó al 27, 5%. La Tabla II muestra la aceleraciónde los modelos paralelos respecto al secuencial,considerando el tiempo requerido para obtenerun 50% de éxito. La Figura 3 muestra la rld para elmejor modelo secuencial, y los mejores modelos paralelosfijando los tamaños de subpoblación a 8 y 30.Se puede apreciar que, aunque los modelos paraleloshan permitido acelerar la convergencia a solucionesde alta calidad, dicha aceleración está bastante limitada.Por ello, se hace necesario seguir analizandomás a fondo este modelo, con el fin de hacer un mejoruso de los recursos computacionales.VII. Conclusiones y Trabajos FuturosLas interfaces cerebro-máquina (bci, Brain ComputerInterface) permiten crear un canal de comunicacióndirecto entre el cerebro humano y un computador.En este campo uno de los principales retoses el diseño de algoritmos, capaces de clasificarlas señales eeg en un conjunto de pensamientos delsujeto. Generalmente, antes de aplicar los clasificadores,se preprocesan las señales eeg mediante unconjunto de filtros. En este trabajo, se ha aplicael algoritmo evolutivo multi-objetivo nsga2 paragenerar de forma automática estos filtros. nsga2ha sido aplicado utilizando varias configuraciones devariación genética. Los resultados computacionaleshan mostrado la importancia de seleccionar de formaadecuada los operadores genéticos. Los resultadosobtenidos son similares a los mejores publicadoshasta el momento, de entre aquellas técnicas queusan como entrada directa las señales eeg. Dado elalto coste computacional asociado a cada ejecuciónse ha explorado la posibilidad de utilizar el modeloevolutivo basado en islas. Se escogió este modeloporque se puede hibridizar fácilmente con las hiperheurísticas,con las ventajas que ello conlleva. Serealizó un análisis utilizando diferentes tamaños desubpoblaciones, así como diferentes porcentajes demigración. Los resultados computacionales muestranque se ha conseguido acelerar la generación defiltros de alta calidad. Sin embargo, se hace patenteque el aprovechamiento de los recursos computacionesno ha sido máximo.Los trabajos futuros se centrarán en analizar mása fondo el modelo basado en islas, con el fin deacelerar aún más la computación. Concretamente,se quieren explorar otros esquemas de migración yaque éste generalmente tiene una gran influencia sobrelos resultados obtenidos. Además, sería interesanteanalizar los resultados obtenidos con otros sujetos.Dado que con alta probabilidad, la variacióngenética adecuada depende del sujeto al que se aplicael esquema, utilizar algunos esquemas que hibridizanlos modelos basados en islas con las hiperheurísticasparece prometedor. Esto permitiría disponer de unesquema que de forma automática seleccione la fasede variación genética adecuada.AgradecimientosEste trabajo ha sido financiado con fondos ec(feder) y del Ministerio de Ciencia e Innovación,dentro del ‘Plan Nacional de i+d+i’ con el proyectotin2008-06491-c04-02. Parte del trabajo tambiénha sido financiado con fondos del Gobierno de Canariascorrespondientes al proyecto pi2007/015. Eltrabajo de Carlos Segura ha sido financiado graciasa las beca fpu-ap2008-03213.Referencias[1] Wolpaw JR, Birbaumer N, McFarland DJ, PfurtschellerG, and Vaughan TM, “Brain-computer interfaces forcommunications and control,” Neurophys, pp. 767–791,2002.[2] E.A. Curran and M.J. Stokes, “Learning to control brainactivity: a review of the production and control of eggcomponents for driving braincomputer interface (bci) systems,”Brain Cognition, 51, 2003.[3] Mourino J Millan J del R, Renkens F, and W. Gerstner,“Noninvasive brain-actuated control of a mobile robot byhuman eeg,” IEEE Trans Biomed Eng,51, 2004.[4] R. Singla, R. Pahuja, and S. Pahuja, “Environment controlusing bci,” in Bioinformatics and Biomedical Engineering,2007. ICBBE 2007. The 1st International Conferenceon, july 2007, pp. 1293 –1295.[5] D.P.O. Bos, B. Reuderink, B. Laar, H. Gurkok, C. Muhl,M. Poel, D. Heylen, and A. Nijholt, “Human-computerinteraction for bci games: Usability and user experience,”in Cyberworlds (CW). 2010 International Conference on,pp. 277–281, IEEE.[6] D.P.O. Bos, B. Reuderink, B. Laar, H. Gurkok, C. Muhl,M. Poel, A. Nijholt, and D. Heylen, “Brain-ComputerInterfacing and Games,” Brain-Computer Interfaces, pp.149–178, 2010.[7] Andrea Kubler and Klaus Robert Muller, Toward Brain-Computer Interfacing, MIT Press, 2007.[8] G. Pfurtscheller and F.H.L. da Silva, “Event-related synchronizationof mu rhythm in the egg over the corticalhand area in man,” NeuroScience Letters,174, 1994.[9] G. Dornhege, B. Blankertz, M. Krauledat, F. Losch,G. Curio, and K. R. Muller, “Combined Optimizationof Spatial and Temporal Filters for Improving Brain-Computer Interfacing,” IEEE Transactions on BiomedicalEngineering, vol. 53, no. 11, pp. 2274–2281, Nov.2006.[10] R. Aler, I.M. Galván, and J.M. Valls, “Evolving spatialand frequency selection filters for brain-computer interfaces,”in IEEE Congress on Evolutionary Computation,2010, pp. 1–7.[11] J. del R. Millán, “On the need for on-lin learning in braincomputerinterfaces.,” in Proceedings of the InternationalJoint Conference on Neural Networks, Budapest, Hungary,July, 2004, IDIAP-RR 03-30.[12] Enrique Alba, Parallel Metaheuristics: A New Class ofAlgorithms, Wiley-Interscience, 2005.[13] C. A. Coello, G. B. Lamont, and D. A. Van Veldhuizen,Evolutionary Algorithms for Solving Multi-Objective Problems, Genetic and Evolutionary Computation.Springer, 2007.[14] Guido Dornhege et al. (eds), Towards Brian-ComputerInterfacing, chapter General Signal Processing and MachineLearning Tools for BCI Analysis, MIT Press, 2007.[15] Kalyanmoy Deb, Amrit Pratap, Sameer Agarwal, andT. Meyarivan, “A fast and elitist multiobjective geneticalgorithm: NSGA-II,” IEEE Transactions on EvolutionaryComputation, vol. 6, pp. 182–197, 2002.[16] David A. Van Veldhuizen, Jesse B. Zydallis, and Gary B.Lamont, “Considerations in engineering parallel multiobjectiveevolutionary algorithms,” IEEE Trans. EvolutionaryComputation, vol. 7, no. 2, pp. 144–173, 2003.[17] Janez Demšar, “Statistical comparisons of classifiers overmultiple data sets,” Journal of Machine Learning Research,vol. 7, pp. 1–30, 2006.[18] Holger Hoos, Fachbereich Informatik, Holger H. Hoos,Thomas Stutzle, Thomas Stutzle, Fachgebiet Intellektik,and Fachgebiet Intellektik, “On the run-time behaviorof stochastic local search algorithms for sat,” in In ProceedingsAAAI99, 1999, pp. 661–666.JP2011-50

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Ranking de listas enlazadas en procesadoresmulticoreHugo María Vegas 1 , Thierry Gautier 2 , Carlos García 3 y Manuel Prieto 4Resumen— En este estudio hemos revisado la implementaciónde algoritmos paralelos para el ranking delistas enlazadas en procesadores multicore. Este tipode algoritmos exhibe patrones de acceso a memoriafuertemente irregulares que no se benefician de losmecanismos agresivos que integran las arquitecturasactuales para ocultar los costosos accesos a memoria(caches, mecanismos de prebúsqueda, ...). Debidoa esta característica intrínseca, el rendimiento decualquier algoritmo para el ranking de listas esta limitadopor los accesos a memoria no consecutivos. Enlos algoritmos paralelos los problemas de rendimientose agravan ya que los patrones de acceso irregular suelenprovocar mayor contención por recursos compartidosy por lo tanto, continua siendo un importantedesafío diseñar algoritmos eficientes para esta aplicación.Tras explorar distintas alternativas, nos hemos centradoen el algoritmo de Helman y Jájá. Comoplataforma experimental hemos seleccionado un servidorde memoria compartida con dos procesadores IntelWestmere de seis cores. Se han analizado dosimplementaciones, una de ellas siguiendo el modelode ejecución convencional fork-join soportado por elestándar OpenMP, y otra que utiliza la librería TBB(Threading Building Blocks) de Intel, con la que es posiblerepartir trabajo utilizando work stealing. Comoprincipal aportación mostramos como es posible mejorarla implementación estándar de Helman y Jájá reduciendoel número de accesos a memoria no consecutivos.Las mejoras son notables con ambos modelos,aunque son especialmente significativas para laversión basada en Intel TBB, cuya implementaciónestándar no consigue aceleraciones respecto al algoritmosecuencial.Palabras clave— List Ranking, Helman y Jájá, Algoritmosirregulares, OpenMP, Intel TBB, Workstealing.I. IntroducciónEn este estudio hemos revisado la implementacióndel algoritmo irregular de list ranking en multiprocesadoresde memoria compartida basados en procesadoresmulticore. Los últimos estudios que se hanpublicado sobre este problema se han realizado utilizandoGPUs como plataforma hardware [1]. Sinembargo, a pesar del auge de este tipo de aceleradores,el mercado técnico y comercial en el que encajaeste tipo de algoritmos irregulares, sigue estandodominado por servidores basados en procesadoresmulticore y es útil una revisión de los trabajos previosen sistemas tipo SMP.Después de explorar varias alternativas, nos centramosen el algoritmo de Helman y JáJá [2].1 Grupo ArTeCS, Universidad Complutense de Madrid, e-mail: hugovegas@fdi.ucm.es2 INRIA Rennes, IRISA, e-mail:thierry.gautier@inrialpes.fr3 Grupo ArTeCS, Universidad Complutense de Madrid, e-mail: garsanca@dacya.ucm.es4 Grupo ArTeCS, Universidad Complutense de Madrid, e-mail: mpmatias@dacya.ucm.esExisten estudios previos sobre dicho algoritmo enmúltiples arquitecturas y con diferentes propósitos[3][2][4][5],[6][7][8]. En multiprocesadores de memoriacompartida tipo SMP [4][6], las aceleraciones conseguidashan sido francamente buenas. Sin embargo,nuestros primeros resultados con procesadores multicorede la familia Intel Xeon no fueron tan satisfactorios.La raíz del problema, que es inherente almismo, y que limita la escalabilidad de cualquier algoritmoparalelo de list ranking está en la naturalezairregular del mismo. Como propuesta presentamosoptimizaciones que permiten reducir los accesos noconsecutivos a memoria, mejorando de este modo lalocalidad espacial, lo que permite alcanzar mayoresaceleraciones.Nuestras implementaciones se han desarrolladocon dos tecnologías de paralelización diferentes:OpenMP e Intel TBB. Con la primera exploramos elmodelo de ejecución fork-join y las estrategias convencionalesde paralelización de bucles. Con la segundaanalizamos las posibilidades que nos ofrece elparalelismo dinámico basado en tareas [9]. En amboscasos, las mejoras que hemos conseguido respecto a laimplementación estándar del algoritmo, han sido significativas.La versión basada en OpenMP es la queconsigue mejores prestaciones frente al algoritmo secuencialpero comparativamente, es la versión basadaen Intel TBB la que más se beneficia de nuestraspropuestas.El resto del artículo se compone de las siguientessecciones. El problema de list ranking y el entornoexperimental utilizado se describen con más detallesen las secciones II y III respectivamente. Las estrategiasde implementación que mejores resultadosnos han ofrecido se presentan en la sección IV.Losresultados obtenidos se presentan y analizan en lasección V. Finalmente, concluimos en la sección VIcon un resumen e ideas de trabajo futuro.II. El problema de List RankingLos algoritmos utilizados para resolver el problemade list ranking son ejemplos muy conocidos de algoritmosirregulares cuyas implementaciones paralelaspresentan serias dificultades para conseguir aceleracionessatisfactorias en los multiprocesadores actuales.Entre otros motivos podemos destacar lossiguientes:• Al igual que ocurre en otros algoritmos de naturalezairregular, su escalabilidad está limitadapor patrones de acceso a memoria con poca localidadespacial y por la existencia de dependenciasque sólo pueden revelarse en tiempo deejecución.JP2011-51

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011• La versión secuencial del algoritmo es extremadamentesimple y aunque también exhibelos problemas de localidad espacial inherentes almismo, requiere menos sobrecargas que los algoritmosparalelos.En la Figura 1 ilustramos gráficamente el problema.Dada una lista formada por enlaces arbitrariosalmacenada en un área contigua de memoria,se debe determinar, para cada nodo de la lista,la distancia (número de enlaces) que le separa delprimer elemento (nodo cabecera) de la misma [10].Dado que los nodos sucesores pueden encontrarse encualquier posición del rango de memoria en el quese almacena la lista, el recorrido de la misma requiereaccesos a memoria con escasa localidad, queno se benefician de los típicos mecanismos agresivosque integran las arquitecturas actuales para reducirlas crecientes latencias de acceso a memoria principal(jerarquías de memoria agresivas, mecanismos depre-búsqueda hardware, ...).(1)FirstFirstNULLLa propuesta de Helman y Jájá para resolver enparalelo el problema de list ranking de forma eficientese basa en reducir el tamaño de la lista aO( nlog n) nodos usando para ello un número linealde operaciones. El Algoritmo 1 y la Figura 2 describenla propuesta. Si se asume que el elementocabecera de la lista es desconocido (es el caso quehemos considerado en este trabajo), es necesario unaetapa preliminar que recorre todo el vector en elque se encuantra almacenada la lista, acumulandolos valores nS de todos los nodos, ya que se puededemostrar que el índice del nodo cabecera viene dadopor 1 2n(n − 1) − Z, donde Z es la suma de todos losvalores de los sucesores nS de la lista [2]. Es importantedestacar que este primer recorrido del vectorpuede hacerse con localidad espacial, sin necesidadde recorrer en orden los elementos de la lista.Algorithm 1 Algoritmo de list ranking de Helmany Jáján1: Distribuir la lista de entrada enlog nbloques{Bi}, cada uno con O(log n) nodos seleccionandonlog n − 1 divisores.2: Calcular (en paralelo) el rango de cada uno de losnodos dentro de su bloque (rango local) medianteun algoritmo secuencial óptimo.3: Combinar los rangos locales con un algoritmoparalelo con complejidad O(log n).(2)NULLFig. 1. El problema del list ranking para una lista cuyoselementos están almacenados de forma ordenada en posicionesconsecutivas de memoria (1) y para el caso generalen el que los nodos se encuentran en posiciones arbitrariasde la misma (2)Existen múltiples variantes del problema enfunción del los tipos de datos utilizados. La instanciahabitual que suele estudiarse en la mayoría delos trabajos asume que la lista L esta representadamediante un vector de nodos de tamaño n cuyos elementoscontienen al menos los siguientes campos:struct node{index nS ;index R;} ;siendo nS el índice del nodo sucesor en el vector Ly R el rango del nodo. Inicialmente puede asumirseque el rango de todos los elementos es el mismo exceptopara el último nodo, que puede contener unvalor especial (por ejemplo R = 0 para el primernodo y R = 1 para el resto). Puede asumirse tambiénque para distinguir el final de la lista, el sucesor delúltimo nodo toma el valor nS = -n, mientras que parael resto nS es ≥ 0. Por simplicidad y para facilitarcomparaciones con trabajos previos y futuros, estaes también la instancia del problema de list rankingque hemos estudiado.En [2] se demuestra que en términos de complejidad,el algoritmo es “eficiente”: el número de operacionesque son necesarias para resolver el problemaes, por encima de una constante, el mismo que enel algoritmo secuencial y además el tiempo paraleloesperado viene dado por O( Tseqp), siendo Tseq eltiempo secuencial.En multiprocesadores de memoria compartida,el número de divisores suele ser considerablementemayor que el número de hilos de ejecucióndisponibles p y la opción habitual de implementaciónse muestra en el Algoritmo 2.El algoritmo de list ranking de Helman y JájáFig. 2.Algoritmo de list ranking de Helman y JájáJP2011-52

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algorithm 2 Implementación estándar del algoritmode Helman y Jájá en multiprocesadores dememoria compartida1: Recorrer el vector en el que se almacena la listapara acumular en Z los valores de nS y conocer elnodo cabecera según la expresión 1 2n(n − 1) − Z.2: Distribuir la lista en nlog n sublistas S i escogiendolos correspondientes divisores3: En paralelo y mientras haya sublistas sin procesador,cada uno de los hilos p i disponibles recorrede forma secuencial (e independientemente de losotros hilos), los elementos de la sublista S j paracalcular sus rangos locales (los rangos respectoa la cabecera de la sublista). Provisionalmente,dichos rangos locales se almacenan en los camposL[i].R.4: Calcular de forma secuencial el prefijo de cadauna de las sublistas. El prefijo de cada sublista esel tamaño acumulado de las sublistas anteriores,siendo cero para la sublista que incluye al nodocabecera global de la lista.5: En paralelo y mientras haya sublistas sin procesador,cada uno de los hilos p i disponibles recorrede forma secuencial e independientemente de losotros hilos, los elementos de una sublista S j ,añadiendo el correspondiente prefijo S j .pref alos rangos locales, almacenándose el rango finalen L[i].R.III. Entorno ExperimentalLas características de la máquina que hemos utilizadopara llevar a cabo nuestros experimentos asícomo el compilador y las opciones de optimizaciónutilizadas vienen descritos en la tabla I. Para estudiarel comportamiento de las diferentes implementacionesse utilizó la herramienta oprofile, con la quees posible monitorizar los distintos contadores hardwaredel procesador, y en particular los fallos decache de último nivel.Xeon X5670 2 chips (2,93 GHz)Procesadorx 6 coresL1 Cache (per Core) 32KBL2 Unified Cache 256KBL3 Unified Cache 12MBMemoria 48 GB, 32 GB/s, 3xDDR3-1333Sistema Operativo GNU/Linux 2.6.32-5-amd64Compilador -O3 -openmp -std=c++0xIntel icc 11.0Intel TBB Version 3.0ProfilingoprofileAfinidadsched getaffinityTABLA IInformación del entorno experimentalIntel (TBB) [11] es una librería desarrollada porIntel que ofrece la posibilidad de expresar paralelismoen programas C++ a programadores con poca experienciaen la programación con hilos. El objetivo esmejorar la productividad de los programadores medianteun modelo en el que el paralelismo puede expresarseen alto nivel mediante la definición de tareasque permiten abstraer los detalles de la plataformaen la que trabajamos. La responsabilidad de asignartareas a hilos de ejecución es transparente al programadory reside en la librería. Adicionalmente soportaparalelismo anidado, permite construir componentesparalelos a partir de otros componentes.La arquitectura Westmere del procesador XeonX5670 soporta multithreading simultaneo (hyperthreading).En los experimentos hasta 12 hiloshemos fijado los hilos a cores diferentes y por lotanto no se aprovecha esta capacidad. No obstante,para evaluar los beneficios que reporta, se han hechoexperimentos con 24 hilos en los que se aprovechatoda la capacidad de la plataforma. Para controlarla afininidad hemos usado la llamada al sistemasched getaffinity.IV. Mejorando la localidad en elalgoritmo de Helman y JájáEn esta sección describimos las dos estrategias quemejores resultados nos han dado para aumentar lalocalidad del algoritmo de Helman y Jájá. Ambasestrategias tratan de minimizar los accesos a posicionesde memoria no adyacentes, ya que éste es elproblema más serio (en términos de rendimiento) quepresenta este algoritmo. De hecho, los propios autoresen [2], presentan un modelo de memoria quetiene en cuenta el coste de acceder a posiciones noconsecutivas en memoria con el que derivan los tiemposde ejecución esperados.1. SLIndex: Durante el proceso de cálculo de losrangos locales (etapa 2 del Algoritmo 2), paracada nodo de la lista se registra en un arrayauxiliar (sLindex) el índice de la sublista en laque esta incluido. Guardando esta información,es posible transformar la etapa 4 del Algoritmo 2para que los accesos a la lista sean con localidadespacial. En este caso, cada hilo pi, en lugar derecorrer varias sublistas, actualiza el rango delos nodos consecutivos con índice global [ib, (i+ 1)b) con:L [ i ] . R += S [ sLindex [ i ] ] . pR ;Con esta transformación se puede acceder deforma consecutiva a la lista L. Además, el arrayS en el que se guarda la información de lasdiferentes sublistas estará almacenado en lacache con gran probabilidad ya que inclusopara listas grandes, el número de sublistas esrelativamente pequeño. Como contrapartida,esta implementación requiere un vector adicional(sLindex) para almacenar los ids de lassublistas y se aumentan los accesos totales.2. Rango acumulado: Actualizar provisionalmenteel rango local en la etapa 2 del Algoritmo2 implica n escrituras no consecutivas en L[i].R.En la etapa 4, este valor vuelve a actualizarse.Las escrituras de la etapa 2 puede eliminarse delsiguiente modo:JP2011-53

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Etapa 2: para cada sublista, el hilo correspondienterecorre sus nodos y devuelveúnicamente el último rango local acumulado,sin salvar en L[i].R el valor local de cadauno de sus nodos.(b) Etapa 3: sin cambios. Los prefijos de cadasublista se almacenan en sL[j].pR(c) Etapa 4: en lugar de actualizar los rangosprovisionales, se calcula directamente el rangosglobal de cada uno de los nodos a partirdel rango del nodo predecesor en la correspondientesublista según:L[i].R = sL[j].pR + L[pred(i)].R + 1De esta manera, eliminamos la necesidad de realizarlas n escrituras no contiguas en la segundaetapa y las n lecturas no contiguas en la cuartaetapa.V. ResultadosA. Impacto de la localidadEn primer lugar hemos evaluado cual es el impactode la localidad en el rendimiento final. En la Figura3 ilustramos como varía el tiempo de ejecución en laversión secuencial del algoritmo (un único recorridode la lista siguiendo los índices de los nodos sucesores)en función de como están emplazados los nodosde lista en memoria. Cuando los nodos adyacentesestán almacenados en posiciones consecutivas (listasordenadas), el tiempo de ejecución es un orden demagnitud inferior que cuando los nodos están localizadosen posiciones arbitrarias (listas aleatorias).Fig. 4.Fallos de L3 (miles) con listas ordenadas y aleatoriascon OpenMP para distintos tamaños de lista y denúmero de hilos (THS):Fig. 5. Variación del tiempo de ejecución con el número dedivisores para listas de 1 millón de nodos usando OpenMPFig. 3. Tiempos de ejecución del algoritmo secuencial paralistas ordenadas y aleatoriasLos resultados de la Figura 4 ponen de manifiestola causa de esta variación. El número de fallos decache de último nivel es muy inferior para listas ordenadas.Actualizar GraficaB. Elección del número de divisoresUn aspecto importante del algoritmo de Helman yJájá es la elección del número de sublistas necesariaspara alcanzar los tiempos de ejecución óptimos. Losautores postularon que el tamaño de sublista óptimonlog nes del orden de , siendo n el tamaño de la listaglobal. En las Figuras 5 y 6 exploramos la variacióndel tiempo de ejecución con el número de divisorespara la implementación estándar (los resultadosson similares para las otras versiones) del algoritmoFig. 6. Variación del tiempo de ejecución con el númerode divisores para listas de 64 millones de nodos usandoOpenMPCon Intel TBB el comportamiento es similar (Figuras7 y 8).En definitiva, los resultados obtenidos validan laestimación de Helman y Jájá. No obstante, el rangode valores óptimos es bastante amplio pudiendo trabajarcon una cantidad de posibles divisores válidosmucho mayor. Los resultados que mostramos enel resto del artículo corresponden siempre a valoresobtenidos con número de divisores óptimos.C. Ganancias de la implementación estándarLas Figuras 9 y 10 muestran las ganancias respectoal algoritmo secuencial que se obtienen con la implementaciónestándar del algoritmo de Helman yJájá utilizando OpenMP y la librería Intel TBB res-JP2011-54

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 7. Variación del tiempo de ejecución con el número dedivisores para listas de 1 millón de nodos usando IntelTBBFig. 9. Ganancias de la implementación estándar del algoritmode Helman y Jájá con listas aleatorias utilizandoOpenMPFig. 8. Variación del tiempo de ejecución con el número dedivisores para listas de 64 millones de nodos usando IntelTBBpectivamente. La paralelización con OpenMP establecedos zonas paralelas con #pragma omp parallelfor, una para la etapa de cálculo de los rangoslocales y otra para la fase final de cálculo delos rangos globales. En función del número de divisoresque se hayan seleccionado, las correspondientessublistas se distribuyen entre los hilos disponiblesdinámicamente. Se han explorado varias alternativas,pero en la Figura 9 sólo se indica los resultadosobtenidos utilizando la mejor granularidad (sedistribuyen sublistas individuales). En la versiónIntelTBB la manera de expresar el paralelismo essimilar con la primitiva parallel for(), aunque la notaciónes diferente ya que se utilizan expresionesLambda [12] que mejoran la expresividad. Al igualque OpenMP puede fijarse una granularidad para ladistribución, obteniéndose también los mejores resultadosdistribuyendo sublistas individuales.Con OpenMP las ganancias son razonables.Usando hyperthreading se consiguen ciertos beneficiosadicionales – comparando los tiempos de ejecuciónutilizando 12 y 24 hilos, las mejoras oscilanentre un 11% y un 14% –, aunque inferiores a losvalores reportados en otras aplicaciones en este tipode arquitectura. Es evidente que la competencia entrehilos dentro de un mismo core puede degradarel rendimiento al ejercerse una fuerte presión en lajerarquía de memoria.Con Intel TBB sin embargo, los resultados sonfrancamente malos y en el mejor de los casos solopodemos aproximarnos al tiempo secuencial.Fig. 10. Ganancias de la implementación estándar del algoritmode Helman y Jájá con listas aleatorias utilizando lalibrería Intel TBBD. Ganancias de la implementaciones SLIndex yRango AcumuladoLas Figuras 11 y 12 muestran las ganancias que seobtienen con las implementaciones SLIndex y RangoAcumulado utilizando OpenMP. La versión SLIndexes la que consigue mejores resultados y para listasgrandes supera a la implementación estándar entreun 20% y un 40%. Ambas versiones se beneficiandel hyperthreading, aunque el beneficio porcentual esmayor con Rango Acumulado.Utilizando la librería Intel TBB, los resultados sonequivalentes, es decir SLIndex es también la mejoropción. Pero además, como se muestra en la Figura13), las ganancias si son ahora más razonables y sepuede superar al algoritmo secuencial. No obstante,siguen siendo mejores los resultados con OpenMP.Fig. 11. Ganancias de la implementación SLIndex del algoritmode Helman y Jájá con listas aleatorias utilizandoOpenMPJP2011-55

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de accesos a memoria y existen compromisos que esinteresante analizar. También pretendemos extenderel estudio a sistemas de mayor escala y analizar losposibles beneficios que podrían conseguirse en sistemasheterogéneos.AgradecimientosEl presente trabajo ha sido financiado por losproyectos TIN2008-00508 e Ingenio 2010 ConsoliderESP00C-07-20811.Fig. 12. Ganancias de la implementación Rango acumuladodel algoritmo de Helman y Jájá con listas aleatorias utilizandoOpenMPFig. 13.SpeedUps para listas desordenadas usando TBBVI. ConclusionesEn este trabajo hemos explorado distintas optimizacionesque permiten mejorar el rendimiento delalgoritmo de Helman y Jájá en sistemas multicore.De las distintas alternativas analizadas los mejoresresultados se han obtenido con la versión que denominamosSLIndex. Con esta versión se consiguenreducir los accesos no consecutivos a memoria en laetapa final del algoritmo, a cambio de añadir un vectoradicional y las correspondientes escrituras y lecturasadicionales a dicho vector. Se ha comprobadoque la elección del número de divisores es fundamentalpara conseguir tiempos de ejecución óptimos yque las estimaciones de Helman y Jájá son validas,aunque el rango de divisores óptimo es bastante másamplio. Los mejores resultados se han obtenido siempreutilizando OpenMP. De hecho, el rendimientode la implementación directa del algoritmo con IntelTBB es especialmente pobre y no consigue batir nia la implementación secuencial. Con las optimizacionespropuestas si se ha conseguido que las versionescon Intel TBB obtengan unos resultados razonables.Habilitando hyperthreading se consiguenbeneficios adicionales (entre un 10% y un 20%), perobastante inferiores a los que se consiguen en otrasaplicaciones.Como trabajo futuro pretendemos analizar cual esla mejor opción teniendo en cuenta los compromisosconsumo/rendimiento. Intuitivamente, reducir eltiempo de ejecución lleva asociado una reducción delconsumo debido al componente estático del mismo,pero las diferentes alternativas varían en el númeroReferencias[1] M. Suhail Rehman, Kishore Kothapalli, and P. J.Narayanan, “Fast and scalable list ranking on the GPU,”in ICS ’09: Proceedings of the 23rd international conferenceon Supercomputing, New York, NY, USA, 2009, pp.235–243, ACM.[2] David R. Helman and Joseph JáJá, “Designing practicalefficient algorithms for symmetric multiprocessors,” inSelected papers from the International Workshop on AlgorithmEngineering and Experimentation, London, UK,1999, ALENEX ’99, pp. 37–56, Springer-Verlag.[3] Margaret Reid-Miller, “List ranking and list scan on thecray c-90,” in Proceedings of the sixth annual ACM symposiumon Parallel algorithms and architectures, NewYork, NY, USA, 1994, SPAA ’94, pp. 104–113, ACM.[4] David A. Bader, Sukanya Sreshta, and Nina R. Weisse-Bernstein, “Evaluating arithmetic expressions using treecontraction: A fast and scalable parallel implementationfor symmetric multiprocessors (smps) (extended abstract),”in Proceedings of the 9th International Conferenceon High Performance Computing, London, UK,UK, 2002, HiPC ’02, pp. 63–78, Springer-Verlag.[5] Isabelle Guérin Lassous and Jens Gustedt, “Portable listranking: an experimental study,” J. Exp. Algorithmics,vol. 7, pp. 7–, December 2002.[6] David A. Bader and Guojing Cong, “A fast, parallelspanning tree algorithm for symmetric multiprocessors(smps),” J. Parallel Distrib. Comput., vol. 65, pp. 994–1006, September 2005.[7] David A. Bader, Guojing Cong, and John Feo, “Onthe architectural requirements for efficient execution ofgraph algorithms,” in Proceedings of the 2005 InternationalConference on Parallel Processing, Washington,DC, USA, 2005, pp. 547–556, IEEE Computer Society.[8] David A. Bader, Guojing Cong, and John Feo, “Onthe architectural requirements for efficient execution ofgraph algorithms,” in Proceedings of the 2005 InternationalConference on Parallel Processing, Washington,DC, USA, 2005, pp. 547–556, IEEE Computer Society.[9] Robert D. Blumofe, Christopher F. Joerg, Bradley C.Kuszmaul, Charles E. Leiserson, Keith H. Randall, andYuli Zhou, “Cilk: An efficient multithreaded runtimesystem,” in Journal Of Parallel And Distributed Computing,1995, pp. 207–216.[10] Richard J. Anderson and Gary L. Miller, “A simple randomizedparallel algorithm for list-ranking,” InformationProcessing Letters, vol. 33, no. 5, pp. 269–273, January1990.[11] James Reinders, Intel threading building blocks; outfittingC++ for multi-core processor parallelism, O’ReillyMedia, July 2007.[12] James Reinders, “Parallel for is easier with lambdas,”Disponible online en software.intel.com/enus/blogs/author/james-reinders/,August 2009.JP2011-56

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Parallelizing Biblio-MetReS, a data mining toolOussama Abdelli 1 , Anabel Usié 1,2 , Hiren Karathia 2 , Jordi Vilaplana 1 , Francesc Solsona 1 and Rui Alves 2Abstract—Biblio-MetReS is a single-thread data miningapplication that facilitates the reconstruction ofbiomolecular networks based on automated text miningand analysis of published scientific literature. Thisapplication is very CPU-intensive and, due to the amountof execution tasks, it can be quite slow. Those tasks arerepetitive, and consist in mining the information fromlarge sets of scientific documents, a situation where thetime performance of the application could be improvedthrough paralellization. This paper presents an applicationthat paralelizes Biblio-MetReS. The multithreadingapplication P(aralell)-Biblio-MetReS, splits the workamong copies of the same Java class, each mining acollection of documents obtained in a previous searchphase from different literature sources of Internet.Through this article, we bring to light the performance andscalability topics of multithreaded Java applications onmulti-threading systems in the context of this application.Experimental results corroborate the good performance ofP-Biblio-MetReS, pinpointing specific aspects that stillneed to be improved.Index terms—Multithreading, Scalability, parallelization,pathway reconstruction, data mining.RI. INTRODUCTIONeconstructing molecular networks that areresponsible for regulating biological processes is afundamental task in molecular biology [11]. In recentyears many alternative methods have been proposed toachieve such a reconstruction [1, 2]. One type of methodrelies on the automated analysis of published scientificliterature that is available in public databases over theInternet to identify genes and proteins that co-occur inthe same document(s) [3-10].Given the large number of available documents(included in web pages, databases, journals, etc), it isimpossible for one person to mine all the availableinformation in order to reconstruct networks and circuitsof interest. This justifies the need for a tool such asBiblio-MetReS [14], a data mining application forreconstructing gene/protein networks.Biblio-MetReS is a user-friendly tool implemented inJava, which does on-the-fly analyses of full textscientific documents that are freely available on theInternet, and uses that analysis for automatedreconstruction of literature gene/protein networks. Indoing so, it identifies if genes co-occur in sentences,paragraphs and/or documents. Results showing theobtained networks are depicted in both, graphical andtabular form.1 Dept. d’Informàtica i Enginyeria Industrial, Av. Jaume II 32, 25001Lleida, Universitat de Lleida (UdL), Spain. e-mails:{abdelli.oussama3@gmail.com, jvilaplana@alumnes.udl.cat,francesc@diei.udl.cat}2 Dept de Ciències Mediques Bàsiques & Institut de RecercaBiomèdica de Lleida (IRBLleida), Montserrat Roig 2, 25008 Lleida,Universitat de Lleida (UdL), Spain. e-mails: {ausie@diei.udl.cat,hiren@cmb.udl.cat, ralves@cmb.udl.cat}The on-the-fly feature of Biblio-MetReS permits theaccess to a wide range of documents that is always up todate. This is an advantage with respect to other wellknown data mining tools (iHOP [3], STRING[4,5] andLaitor [6]), which only have access to pre-processed listsof documents, saved in a precompiled database. Themain drawback of Biblio-MetReS is the elevatedexecution time of a reconstruction in Biblio-MetReSwhen compared to applications that pre-process thedocuments.There are two strategies to improve this executiontime. First, one can combine on-the-fly analysis of newdocuments with pre-processed analysis of documentsthat have already been previously mined. This is astrategy that is already being pursued. Second, and dueto the nature of the processes in Biblio-MetReS, it islikely that parallelization of the application willsignificantly improve the on-the-fly processing time.Thus, the main goal of this work is to start theimplementation of the second strategy and reduce theserial execution time of network reconstruction inBiblio-MetReS.Parallel computing is a form of computation in whichmany calculations are carried out simultaneously,operating on the principle that large problems can oftenbe divided into smaller ones, which are then solvedconcurrently ("in parallel"). Parallelism has beenemployed for many years in computer programs, mainlyin high-performance computing. Interest in this strategyhas grown lately due to many factors, such as theincreasing number of multiprocessing computers, theemergence of cloud computing, and the physicalconstraints preventing frequency scaling of serialcomputations.Parallel computer programs are more difficult to writethan sequential ones, because concurrency introducesseveral new classes of potential software bugs, of whichrace conditions are the most common. Communicationand synchronization between the different subtasks aretypically one of the greatest obstacles to getting goodparallel program performance.There are no conceptual differences between a Javaprogram running on a machine with one processor andthe same program running in a machine with two ormore processors; the threads behave exactly the same inboth cases. However, the key difference between singleprocessorand multiprocessor systems is that the first canonly run one thread at a time while the latter cansimultaneously run multiple threads. A workstation canhave multiple, multicore, processors. In this case,several threads can simultaneously be distributed amongthe many processors, and, within each processor, amongthe different cores, that can also be multithreading. Forexample a bi-processor machine with four two-threadingcores can execute an amount of 16 threads in parallel.From now on, we simply refer the multithreadingmachines, without distinguishing what type ofmultithreading that machine can do.JP2011-57

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011There are several different forms of parallelcomputing: bit-level, instruction level, data, andfunctional parallelism. In this work, we mainly exploreddata parallelism.As power consumption (and consequently heatgeneration) by computers has become a concern inrecent years, parallel computing has become thedominant paradigm in computer architecture, mainly inthe form of cluster, grid and multi-core processors. Inthis work we explore the latest, also calledmultiprocessor systems.Our challenge is to profit as much as possible thefeatures of multithreading computers in the execution ofP-Biblio-MetReS, the parallel version of Biblio-MetReS. P-Biblo-MetReS follows a data parallelphilosophy, that is, multiple copies of the same functionprocesses different input data.This paper presents the first results of thisparallelization. Section II introduces the Biblio-MetReSmode of operation and its main features. Section III andIV explains the design and implementation decisions ofP-Biblio-MetReS respectively. A comparison of thecomputational aspects of P-Biblio-MetReS with respectto its serial version is presented and analyzed in sectionV. Finally, section VI presents the conclusions of theanalysis, and section VII discusses future work.Fig. 1. Flowchart of Biblo-MetReS.II. BIBLIO-METRESBiblio-MetReS was implemented in JAVA. Itsworkings are explained in the following (see Fig. 1).First of all, users must register to login into Biblio-MetReS (Fig. 1.1). Next (Fig. 1.2), users must choose anorganism to work with. The application loads all genesfrom this organism that are present in the centraldatabase that contains lists of all annotated genes oforganisms with fully sequenced genomes. The databaseof gene names was built by matching the KEGG [12]gene names to their NCBI [13] names and synonyms.Once the loading is finished, the user is presented withthe main window (see Fig. 1.3), where s/he has to selectthe data sources as well as the genes to be analyzed. Thedata sources are (see Fig. 1 for a detailed list): GeneralEngines (Yahoo, Live Search, Altavista, etc.), LiteratureDatabase (Medline, Pubmed, Biomed Central, etc.) andJournals (Nature, Science, etc.).Once the choices are made and the search is started,the tool identifies and downloads the documents thatcontain the gene names and its synonyms from theselected data sources.Then, Biblio-MetReS parses each document, andanalyses the co-occurrence of genes by identifying theoccurrence in the text of genes that are present in thedatabase. The parsing results are represented as twographs. One of the graphs presents the co-occurrence ofgenes in sentences (Fig. 1.4A) and the other representsthe co-occurrence of genes in paragraphs and documentsJP2011-58

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(Fig. 1.4B). Biblio-MetReS implements parsers forHTM, PDF and ASCII documents.Each node or vertex in the graphs is a gene/proteinand each edge refers to an instance of co-occurrencebetween different genes in sentences, paragraphs, ordocuments. The thickness of the edge is proportional tothe mutual information between two genes and the colorof the edge is proportional to a p-value that measureshow much more enriched is the co-occurrence betweentwo genes in sentences or paragraphs with respect todocuments. See [14] for more details.The whole process described above is done on the fly.The serial time in executing all the Biblio-MetReSprocesses can be very high, and it would strongly benefitfrom parallelization.III. P-BIBLIO-METRESIn this section we describe the main decisions taken inthe design of the parallel version of Biblio-MetReS, P-Biblio-MetReS.As was pointed out in the Introduction, there areseveral forms of parallel computing: bit-level,instruction level, data, and functional parallelism.Biblio-MetReS is written in a high-level language, Java.Parallelization in the bit or instruction level will bealmost impossible. Instead, parallelism was performedin an upper level, at the Java code.As P-Bilbio-MetReS is designed to be executed on amultithreading machine, the following aspects must betaken into account:• We cannot assume that any running thread has thehighest priority. A higher-priority thread may berunning on a different processor.• We cannot assume that a low-priority thread willnot run. There may be enough processors to give ita chance at execution.• We cannot assume that threads of differentpriorities will not be running at the same time.• We cannot assume that a given race conditions canbe ignored, just because it is unlikely to occur. Raceconditions in a multiprocessor system present a realproblem, whereas race conditions in a singleprocessorsystem are more dependent on thescheduling engine of the Java virtual machine.Taking these issues into account, the key question ofthe parallelization problem at hand is a) theidentification of the Java code to be executed in paralleland b) implementing this code in one class (or object)that can be run in multiple threads. Multiple threads arecreated, one for each copy of the object, and then theyare executed in parallel. As all the threads are executedin the same machine, our parallel implementationrequires defining an optimal multithreading policy.Without redesigning a program, the parts of the codewhose execution is most likely to benefit fromparallelization are those where the application is CPUbound - that is, the sets of instructions where theprogram is mainly using processing cycles, and at thesame time E/S resources (network and secondarystorage) are idle -.We discard the parallelization of E/S parts of codebecause Biblio-MetReS does not deal with an amount ofinformation that makes it necessary to increase the speedof access to the secondary storage. If we would want toincrease the network bandwidth, P-Biblio-MetReS couldalso be simultaneously executed in different machines,each with an individual IP. Distributed environments(for example Grid, Volunteer, Cloud or P2P computing)could be considered for such an execution.Thus, first and foremost, we are interested indetermining the CPU bound objects in Biblio-MetReS.By taking into account the class architecture of Biblio-MetReS (see Fig. 2), we identified the objects where a)documents are obtained from different data sources, andb) the parsing of those documents is made as thosewhere the application is CPU-bounded. These objectsare thus the natural candidates to be executedconcurrently in multiple threads.Fig. 2. Class diagram representing relationships betweenclasses used in the parallelization.Second, we must also consider that there is no reasonto execute the serial program ‘Biblio-MetReS’ CPUboundobjects in parallel if, during its run, the programdoes not use 100% of the available single physicalthreads. We should control for this possibility whenchoosing a parallelization policy to execute P-Biblio-MetReS.Third, we are interested in getting the appropriatenumber of threads to be created and executed in parallel,so that an optimal run time is obtained. More precisely,we are interested in understanding the relationshipbetween the available processing power (the number ofhardware threads) and the number of logical threads wecan create at once in order to identify the ratio R optimalbetween the two quantities that optimizes execution timeof the program. Identifying this ratio will allow us tocreate an application that scales well.Because there is, to our knowledge, no systematicmethod to identify R optimal , we test three heuristicpolicies to determine which of these gives the bestperformance:1. The first method (S1) consists in creating a threadfor every search engine. Each thread handles thelinks returned by the search engine. Then, it parsesthe returned documents. The various threads areJP2011-59

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011properly synchronized. Once all the results havebeen collected and processed, information about theco-occurrence of genes is obtained, as well as thecreation of graphs that illustrate the variousrelations between them.2. In the second method (S2), each thread that iscreated parses a number of documents given by theratio between the total number of documents andthe number of physical threads.3. In the third method (S3), the parsing of documentsis divided into synchronized subphases. In eachsubphase, P-Biblio-MeteS creates as many localthreads as physical threads in the system. Eachthread is assigned with one document to beprocessed. This process continues until the overalldocuments are processed.In our case, P-Biblio-MetReS scaling depends onmany factors: the operating system, the Java virtualmachine implementation, the application server, the Javaengine of the virtual machine and the Java applicationitself. We will analyse this in depth in the next section.The procedure for creating threads based on theRunnable interface is as follows:• The RunnableDistributer class implements therunnable interface, providing the run() methodthat will be executed by the thread. This methodcontains the main task that we are executing. Inour case the run method launches the procedure ofparsing documents and returns the results of theanalysis.• We create an object of the Thread class by passingan instance of the class RunnableDistributer asargument to the Thread constructor. The Threadobject now has a Runnable object that implementsthe run() method.• To begin the execution of the thread, we call themethod start(). This method allows the JavaVirtual Machine to call the run method of thethread.V. EXPERIMENTAL RESULTSIV. IMPLEMENTATIONIn this section, the methodologies used inimplementing P-BiblioMetReS are described.P-Biblio-MetReS is implemented in Java. Every threadin Java is created and controlled by the java.lang.Threadclass. A Java program can have many threads, and thesethreads can run concurrently, either synchronously orasynchronously.There are two ways to create threads in java. One is byimplementing the Runnable interface provided by thepackage java.lang.Runnable. The other is by Extendingthe Thread class defined in java.lang.Thread. (seefugure 3)Fig. 3. Classes and methods in the creation of a thread.We implemented the interface java.lang.Runnablebecause it allows for multiple inheritance. This enablessimultaneous creation of threads and facilitates theirmanagement.The experiments have been carried out on a serverwith eight cores and 16GB of Memory (machine 8c), alaptop with a CPU Intel i7 with 4 cores (machine 4c)and 6GB of Memory, and finally a laptop with 2 coresand 4GB of Memory (machine 2c). Windows 7 x64 isused as an OS. In order to avoid miscellaneous influenceskewing the results, the single user mode of OS is used.We have chosen the organism Saccharomyces cerevisiae(budding yeast) to perform our experiments. Theseexperiments consist in reconstructing the network ofgenes that co-occur with the genes FBA1, PGM1,CDC19, which are involved in glycolysis.Concerning the first series of experiments (1), Fig. 4shows the run time of the serial execution of Biblio-MetReS, when executed in just a single threaded mannerin a single core laptop with 2GB of Memory. Fig. 5shows the comparable results for running theparallelized P-Biblio-MetReS, following strategy S1 andcreating a thread for every search engine. This run usedthe 2c machine. A comparison of the two figures showsthat the parallel version obtains moderate gains. This islikely to be due to the fact that each search enginereturns a different number of documents, which areanalyzed in serial manner within that search engines’dedicated thread. Thus, the search engine with theslowest processing time would dominate run time andcause run-time differences between the serial andparallel versions of the program to be smaller than theycould. Nevertheless, further analysis is required to betterunderstand these results.The second series of experiments implement P-Biblio-MetReS using the two remaining strategies describedabove (S2 and S3). Results are shown in Figs 6, 7, and8.One immediate inference that can be drawn is that theoptimal runtime depends on the number of threads anddocuments, independently on the Internet sources used.Above an amount of documents to be parsed, beyond theJP2011-60

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Main Memory limit, the performance decreased in allthe situations (by varying the Internet sources).Fig. 4. Time of execution in single threaded.Fig. 7. Execution times for Biomed Central,Cell and Systems Biology.Fig 5. Time of execution in multi-threaded.The key objective is the finding for the optimalnumber of threads that returns as many documents aspossible that fits in Main Memory. It can be seen in theexperiments as there is an optimal range for the numberof threads that can be launched. This optimal range wasbetween 8 and 16 threads, with 16 being the number ofthreads that provided the fastest runtime in mostexperiments. However, this range of optimality wasalmost flat and differences in runtime using a number ofthreads between 8 and 16 were small.Fig. 8. Execution times for Lycos, Ask andPubmed.Fig. 9. Comparison of execution times between theserial version and the parallel one.Fig. 6. Times for Medline (Database)In other experiment we compare the results obtained inFig. 8 with 16 threads with those for the serial version ofBiblio-MetReS. The gains in run-time by P-Biblio-MetRes with respect to Biblio-MetReS are significant(Fig. 9).Finally, we analyzed the effect of Memory usage onrun-time by varying the number of search enginesbetween 5 and 20,while using policy S3. The number ofdocuments was very high and increased rapidly with thenumber of search engines. The results are shown in Fig.10. At a given point, the increasing in the number ofsearch engines led to the creation of a number of threadsthat was too high. The application ran into out ofmemory errors and crashed, making it clear that it isnecessary to consider hardware memory specificationsJP2011-61

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011to limit the number of threads that can be created inpolicy S3. Thus, policy S3 must be redesigned.Fig. 10. Execution times incrementing the number ofsearching engines.VI. CONCLUSIONSThe essential objective of this study was to decreasethe run time of the application Biblio-MetReS byparallelizing the parsing and analysis of the documentsby the application. In doing so, we wanted to establish astrategy that would be close to optimal in creating theadequate number of threads for decreasing the run timeof the application. Our preliminary results suggest that astrategy that fairly divides the number of documents tobe analyzed by the number of physical hardware threadsthat are available in the machine is, in most cases, thebest policy.VII. FUTURE WORKWe are now planning the design of new efficientscheduling algorithms to distribute the parser phasebetween cores of one node. Once this is accomplished,we will consider clusters of workstations. In doing so,we want to classify documents according to their types(pdf, text or HTML) and sizes. Then schedulingdecisions will try to balance the load between thethreads assigned to the cores according to such aclassification.Future challenges will go in the direction of alsoparallelize the search phase, which is another step that ishighly amenable to parallelization. We will analyze thebest policy for distributing the bandwidth worldwidebetween nodes located in Internet.ACKNOWLEDGEMENTSThis work was supported by the MEyC-Spain undercontracts BFU2007-62772/BMC, BFU2010-17704,TIN2008-05913 and CSD-2007-00050, by Generalitatde Catalunya, through research groups 2009SGR809 and2009SGR145 and the CUR of DIUE of GENCAT, andby the European Social Fund.REFERENCES1. Alves R, Sorribas A: In silico pathwayreconstruction: Iron-sulfur cluster biogenesis inSaccharomyces cerevisiae. BMC Syst Biol 2007,1:10.2. Markowetz F, Spang R: Inferring cellular networks--a review. BMC Bioinformatics 2007, 8 Suppl 6:S5.3. Hoffmann R, Valencia A: Implementing the iHOPconcept for navigation of biomedical literature.Bioinformatics 2005, 21 Suppl 2:ii252-258.4. Hoffmann R, Valencia A: A gene network fornavigating the literature. Nat Genet 2004,36(7):664.5. von Mering C, Jensen LJ, Kuhn M, Chaffron S,Doerks T, Kruger B, Snel B, Bork P: STRING 7--recent developments in the integration andprediction of protein interactions. Nucleic Acids Res2007, 35(Database issue):D358-362.6. Barbosa-Silva A, Soldatos TG, Magalhaes IL,Pavlopoulos GA, Fontaine JF, Andrade-NavarroMA, Schneider R, Ortega JM: LAITOR--LiteratureAssistant for Identification of Terms co-Occurrences and Relationships. BMCBioinformatics 2010, 11:70.7. Kemper B, Matsuzaki T, Matsuoka Y, Tsuruoka Y,Kitano H, Ananiadou S, Tsujii J: PathText: a textmining integrator for biological pathwayvisualizations. Bioinformatics 2010, 26(12):i374-381.8. Krallinger M, Leitner F, Valencia A: Analysis ofbiological processes and diseases using text miningapproaches. Methods Mol Biol 2010, 593:341-382.9. Krallinger M, Valencia A, Hirschman L: Linkinggenes to literature: text mining, informationextraction, and retrieval applications for biology.Genome Biol 2008, 9 Suppl 2:S8.10. Hahn U, Valencia A: Semantic Mining inBiomedicine (Introduction to the papers selectedfrom the SMBM 2005 Symposium, Hinxton, U.K.,April 2005). Bioinformatics 2006, 22(6):643-644.11. McIntosh T, Curran JR: Challenges forautomatically extracting molecular interactionsfrom full-text articles. BMC Bioinformatics 2009,10:311.12. Aoki KF, Kanehisa M: Using the KEGG databaseresource. Curr Protoc Bioinformatics 2005, Chapter1:Unit 1 12.13. Geer LY, Marchler-Bauer A, Geer RC, Han L, He J,He S, Liu C, Shi W, Bryant SH: The NCBIBioSystems database. Nucleic Acids Res 2010,38(Database issue):D492-496.14. Usié A, Karathia H, Solsona F, Alves R. Biblio-MetReS: A Bibliometric Reconstruction Server.ICMSB 2011.JP2011-62

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Paralelización de una Plataforma para laResolución de Problemas NP-completosMediante Algoritmos EvolutivosJosé M. Lanza-Gutiérrez 1 , Juan A. Gómez-Pulido 1 , Miguel A. Vega-Rodríguez 1 , Juan M. Sánchez 1Resumen— El avance científico en todas sus vertientesprovoca la continua aparición de problemas deoptimización NP-completos, los cuales requieren detécnicas específicas para su resolución. Entre lasmetodologías más habituales se encuentran los algoritmosevolutivos. Dado que la implementación de estos algoritmospuede resultar compleja, han surgido plataformas, comoPISA, que facilitan la resolución de problemas deoptimización suministrando algoritmos evolutivos yaimplementados por la comunidad científica. Laherramienta PISA posee una importante deficiencia, y esque no está preparada para ser ejecutada en un sistemaparalelo, algo muy importante hoy día cuando sedemandan grandes esfuerzos computacionales. En esteartículo se propone una metodología de paralelización dePISA, así como un caso de estudio en el que se ha resueltoun problema multi-objetivo para el diseño de redes decomunicaciones, comprobando las ventajas que aporta.Palabras clave—Algoritmos evolutivos, optimizaciónmultiobjetivo, framework PISA, paralelización, MPI,diseño de redes de comunicaciones.EI. INTRODUCCIÓNn muchas áreas científicas aparecen constantementeproblemas complejos de optimización, en los quehay que estudiar el comportamiento de múltiplesfactores de forma conjunta. La incorporación de unelevado número de incógnitas a un problema provocaque el número de posibles soluciones crezcaexponencialmente con respecto a los datos de entrada.Por este motivo, la ciencia de la computación trata deproporcionar técnicas que permitan la resolución de estetipo de problemas, denominados NP-completos [1].Estas técnicas tratan de evitar recorrer todo el espacio desoluciones posibles (como ocurre con las estrategias debúsqueda tradicionales) con el fin de reducir el tiempotomado en su resolución, obteniendo a cambio unasolución lo más cercana posible a la óptima.Una de las primeras técnicas utilizadas con estepropósito fueron las heurísticas. Las heurísticas secentran en la utilización de algoritmos que proporcionanbuenas soluciones en tiempos de ejecución razonables,para problemas concretos [2]. Estas técnicas no aseguran1 Dep. Tecnología de Computadores y Comunicaciones. EscuelaPolitécnica. Campus Universitario s/n, 10003 Cáceres.{jmlanza,jangomez, mavega,sanperez}@unex.es2 A Platform and Programming Language Independent Interface forSearch Algorithms (PISA), web: http://www.tik.ee.ethz.ch/pisa/.3A Framework for Multi-Objective Optimization (JMetal), web:http://jmetal.sourceforge.net/.que los resultados obtenidos sean realmente cercanos alos óptimos. Muchos autores las han utilizado endiversos campos, como por ejemplo Jan et al. [3](desarrollaron una técnica basada en branch and boundpara optimizar el coste de una red sobre unos valores deconfiabilidad concretos) y Ersoy et al. [4] (usaron unatécnica de optimización sobre el retardo medio para eldiseño de redes LAN y MAN interconectadas).Otra de las técnicas habituales son los algoritmosevolutivos, que resuelven problemas de optimizaciónmediante técnicas basadas en la evolución y selecciónnatural [5]. Estos algoritmos son muy populares porqueaportan, en general, buenos resultados. Pueden dividirseen dos tipos; por un lado, los que tratan de optimizar unúnico objetivo; por otro lado, los que tratan de optimizarmúltiples objetivos de forma simultánea. Por ejemplo, yen el ámbito de las telecomunicaciones, podemosencontrar un caso de optimización evolutiva monoobjetivoen Abuali et al. [6] (minimizaron el coste de lared a la vez que consideraban los valores máximos decapacidad) y de optimización evolutiva multi-objetivoen Barnerjee et al. [7] (estudiaron el diseño de redesbasadas en modelos de trafico habituales, mediante laoptimización del coste y el retardo). Los estudios sobreoptimización multi-objetivo están cobrando últimamentemucho interés dada la naturaleza de muchos problemasde optimización del mundo real.No todo son ventajas en la utilización de los algoritmosevolutivos; la principal dificultad es que suimplementación es a veces compleja, puesto quehabitualmente se centran en complejas teoríasmatemáticas. Esto provoca que su utilización quedehabitualmente relegada a ciertos sectores científicosmuy cualificados (informáticos, matemáticos…).Para facilitar el uso de estas técnicas han surgido unaserie de entornos, plataformas o frameworks, para quepersonas no expertas en programación de algoritmos deoptimización evolutivos puedan abordar la resolución deproblemas de optimización. Entre estas plataformas seencuentran PISA 2 y JMetal 3 . Estas plataformas tratan deseparar, por un lado, la implementación del algoritmo deselección (como el NSGA-II -Non-dominated SortingGenetic Algorithm II- [8] o el SPEA-II -Strength ParetoEvolutionary Algorithm II- [9]); y por otro, la definicióndel problema que se desea resolver. La estrategiaconsiste en que el algoritmo de selección seaimplementado por un experto en el ámbito científico delproblema, mientras que el resto de la aplicación puedeser implementada por cualquier persona conconocimientos básicos de programación.JP2011-63

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011En este artículo se ha optado por trabajar con el entornoPISA, debido al peso que tiene en la comunidadcientífica. Una vez estudiadas las características de estaplataforma, se observo cómo no tiene desarrollada unacompatibilidad con su ejecución en sistemas paralelos.Este fue el motivo para abordar la paralelización de laplataforma, y que mostramos en este artículo, con elobjetivo de aprovechar todo su potencial al poderejecutarse en clústeres de computadores paralelos.Como caso de estudio de la estrategia aquí expuesta, seresolvió un problema de optimización multi-objetivopara el diseño de redes de comunicaciones, utilizandopara ello dos algoritmos evolutivos proporcionados porla comunidad de la plataforma.El resto del artículo se estructura como sigue: en lasegunda sección se proporciona una breve descripciónde la plataforma PISA. En la tercera, la propuesta deparalelización del entorno para su utilización enclústeres de computadores paralelos. En la cuartasección se expone un caso de estudio y, por último,relatamos las conclusiones y trabajos futuros.II. DESCRIPCIÓN DE LA PLATAFORMA PISAEn esta sección proporcionamos una breve descripciónde la plataforma utilizada en este trabajo. Para unadescripción más completa, recomendamos consultar lareferencia [10].Como ya se ha mencionado anteriormente, PISA es unaplataforma diseñada para facilitar la resolución deproblemas de optimización mediante la utilización dealgoritmos evolutivos. La plataforma está compuesta portres elementos principales: el optimizador, el monitor yel evaluador de resultados (figura 1).El optimizador se encarga de resolver un determinadoproblema de optimización multi-objetivo mediante lautilización de técnicas evolutivas. Este elemento sedivide a su vez en dos módulos: por un lado, el módulovariator, que contiene detalles específicos del problemaque se desea resolver (representación de la informaciónen forma de cromosomas, funciones de fitness, estrategiaen mutaciones y cruces…); y por otro lado, eldenominado selector, que contiene un algoritmo deselección (como NSGA-II o SPEA-II), que determinarácómo se seleccionan los individuos en su evolución.Cada uno de estos módulos son aplicacionesindependientes que se comunican mediante archivos detexto. El formato de entrada/salida de cada uno de ellosse detalla perfectamente, lo que permite que todos losmódulos sean interoperables, independientemente dellenguaje de programación utilizado.Esta estrategia modular permite, además de lareusabilidad, facilitar la implementación, pues el usuariotan solo debe centrarse en la realización de, al menos, unalgoritmos. De este modo, al experto en algoritmosevolutivos le interesará implementar un nuevo móduloselector, sobre un problema ya desarrollado en lacomunidad, mientras que el experto en el área científicadel problema (biología, por ejemplo) implementará unnuevo problema mediante su correspondiente módulovariator, para así ejecutarlo contra los algoritmosselectores ya desarrollados.Cada uno de estos módulos tiene asociado un archivo deconfiguración que permite ajustar los parámetrosnecesarios, permitiendo definir múltiplesconfiguraciones para un mismo problema. Por ejemplo,para un módulo variator podría ajustarse la probabilidadde cruce, de mutación, el tamaño de la población, elnúmero de iteraciones, etc.A la hora de resolver un problema de optimización bastacon ejecutar cada uno de estos módulos variator yselector con una configuración asociada. Durante laejecución, el control va pasando de un módulo a otromediante la utilización de los archivos intermedios,dando la impresión de que ambos se ejecutan como sifueran un todo. Los pasos seguidos durante la ejecucióndel optimizador son los siguientes (figura 2):• Paso 1: El módulo variator genera la poblacióninicial y calcula los valores de fitness para cadaindividuo.• Paso 2: El módulo selector selecciona losindividuos candidatos a evolucionar en estaprimera iteración.• Paso 3: El módulo variator toma los individuosanteriormente seleccionados y procede arealizar sobre ellos mutaciones y cruces. Elnúmero de individuos en la población semantiene constante, para lo cual se eliminanaquellos no seleccionados previamente.• Paso 4: Una vez más, el módulo selector realizala selección de individuos, volviendo de nuevoal paso 3. El procedimiento finaliza cuando sellega a la condición de parada, normalmente unnúmero determinado de iteraciones.• Paso 5: Se genera el archivo de resultados conel correspondiente frente de Pareto (gráfico deresultado en las técnicas de optimización multiobjetivo).Se notifica al módulo selector que yase ha obtenido la solución y que por tantopuede finalizar su ejecución.Fig. 1. Elementos que conforman la plataforma PISA.Fig. 2. Diferentes estados por los que pasan los módulos queconforman el optimizador durante su ejecución.JP2011-64

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Otro componente importante de la plataforma es elevaluador de resultados (figura 1). Una vez obtenidoslos resultados experimentales, este módulo permitedeterminar si alguno de los algoritmos de selecciónutilizados ofrece un comportamiento significativamentesuperior al resto. Para ello se utilizan indicadoresestadísticos como el hipervolumen o el épsilon, y testsestadísticos (Wincoxon-Sign, Kruscal-Wallis, etc) [11].Por último, el componente denominado monitor (figura1) ejecuta los módulos selector y variator de formasimultánea, ofreciendo la posibilidad de repetir estaejecución repetidas veces, para dar validez estadística.Se profundizará un poco más en la siguiente sección.Como ya se ha comentado, la utilización de estaplataforma sigue una concepción mono-procesadora,evitando que pueda ser ejecutada en un clúster. Por estarazón decidimos ofrecer una alternativa paralela a estecomponente monitor, desarrollando un componente quepermita repartir el trabajo de optimación por todo elclúster, tal y como se explica a continuación.III. PROPUESTA DE PARALELIZACIÓN DEL ENTORNOEn este apartado se detalla la propuesta de paralelizaciónde la plataforma, consistente en sustituir la aplicaciónmonitor por una que funcione de forma paralela.Como puede observarse en el Algoritmo 1, el monitororiginal trata de resolver un problema de optimizaciónmediante la utilización de diversos algoritmos deselección, ejecutando cada uno de ellos en múltiplesocasiones (siempre con la misma configuración) para asíobtener validez estadística en los resultados. Laconcepción secuencial de PISA provoca que el tiempode cómputo necesario se presuma elevado. Nuestra ideaconsiste en aprovechar la capacidad de cálculo de unclúster para aligerar el tiempo de cómputo necesario,aumentando así la productividad del sistema.La estrategia que abordamos requiere de la utilizaciónde dos tecnologías: una librería de paso de mensajesMPI (Message Passing Interface) [20] para lacomunicación entre los procesos y un protocolo para elacceso a sistemas de archivos remotos de forma seguraSFTP (SSH File Transfer Protocol), para obtener losarchivos de resultados de los distintos nodos del clúster.El nuevo monitor se describe en el Algoritmo 2. Paracada módulo selector que se desee utilizar contra unmismo módulo variator se reparten (mediante MPI)desde el nodo principal todas las repeticiones entre cadauno de los nodos del clúster, permitiendo tantasejecuciones por nodo como cores tenga disponible. Unavez finalizada la ejecución en todos los nodos se recogenlos resultados mediante SFTP y se repite elprocedimiento de nuevo para otro algoritmo selector. Lasalida de este monitor es un archivo con las solucionesconcatenadas, al igual que el del monitor original.La forma en la que se reparten las ejecuciones por elclúster depende principalmente del número derepeticiones que se deseen obtener. En la figura 3 puedeobservarse un ejemplo de un clúster con 5 nodos, cadauno de ellos con 4 cores. Si se desean obtener 40repeticiones, deben utilizarse todos los cores del clústerrealizando cada uno de ellos dos ejecuciones. Si porejemplo se desean obtener 20 repeticiones, se utilizaríande nuevo todos los cores, realizando cada uno de ellosuna ejecución. Si fueran necesarias 10, se utilizarían los5 nodos, pero tan solo 2 cores de cada uno; y asísucesivamente.Algoritmo 1 Pseudocódigo Monitor de PISA1: para i toma valores de {selector1, selector2,…,selectorN} hacer2: para j=0 a MAX_REPETICIONES hacer3: Ejecutar módulo variator para una configuración dada4: Ejecutar módulo selector i para una configuración dada5: Esperar que finalicen los módulos6: Escribir el resultado en el archivo de salida i7: fin para8: fin paraAlgoritmo 2 Pseudocódigo del MONITOR propuesto1: Repartir los datos necesarios por el clúster: módulo variator yselector, archivos de configuración, datos del problema… (SFTP)2: para i toma valores de {selector1, selector2,…,selectorN} hacer3: para j=0 a NUM_NODOS hacer4: para k=0 a NUM_CORES hacer5: para z=0 a MAX_REPETICIONES/(NUM_NODOS*NUM_6: CORES) hacer //Repeticiones por core7: Lanzar módulo variator en nodo j (MPI)8: Lanza módulo selector i en nodo j (MPI)9: finpara10: finpara11: finpara12: para j=0 a NUM_NODOS hacer13: para k=0 a NUM_CORES hacer14: para z=0 a MAX_REPETICIONES/(NUM_NODOS*NUM_15: CORES) hacer //Repeticiones por core16: Esperar señal de finalización del nodo j (MPI)17: Obtener el archivo de resultado del nodo j (SFTP)18: Escribir el resultado en el archivo de salida i19: finpara20: finpara21: finpara22: finparaFig. 3. Ejemplo de una distribución de carga con el monitor propuestoComo cabría esperar, la productividad del sistemaaumenta, pues la ejecución de cada uno de estosprocesos de optimización requiere una gran cantidad deciclos de CPU, a cambio de un pequeño tiempo decomunicación entre las máquinas. Este aspecto se tratarádetenidamente en la siguiente sección, en la que,partiendo de un problema real, se analizarán las ventajasde utilizar esta estrategia.JP2011-65

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Las únicas modificaciones necesarias paracompatibilizar el monitor aquí planteado con losmódulos ya desarrollados son dos: la inclusión de lastípicas directivas de inicialización de MPI para ambosmódulos y el envío del mensaje de finalización hacia elnodo principal desde el estado 4 del módulo variator(ver Figs. 1 y 2), ambas muy sencillas.IV. CASO DE ESTUDIOEn esta sección se detalla un caso de éxito en el que seha resuelto un problema de optimización mediante lapropuesta aquí explicada.El problema resuelto consiste en el diseño de redes decomunicaciones para Internet. Es un problema queinvolucra una gran cantidad de factores; entre los máshabituales suelen encontrarse aquellos que afectan alcoste y a la calidad de red (retardo, confiabilidad, etc)[12]. Ambos factores (coste y calidad) son influyentesentre sí. En definitiva, estamos ante un problema deoptimización NP-completo que requiere de técnicasespecíficas que faciliten su resolución [1].Este problema ha sido abordado mediante diversasmetodologías, como por ejemplo heurísticas [3][4] yacitadas en la introducción. No obstante, estas heurísticasno permiten asegurar que las soluciones obtenidasrealmente sean las óptimas, por lo que surgen otrasalternativas: Usando algoritmos evolutivos monoobjetivo,Abuali et al. [6] y Ko et al. [14] optimizan elcoste de la red a la vez que mantienen valores constantesde retardo. Considerando algoritmos evolutivos multiobjegivo,Barnerjee et al. [7] y R. Kumar et al. [15]optimizan sobre el coste y el retardo usando el PCGA.Son precisamente los algoritmos multi-objetivo los quemejor de adaptan a este tipo de problemas [16].En la comunidad PISA existe una serie de algoritmosevolutivos implementados con sus correspondientesmódulos selectores, como por ejemplo: SPEA-II [9],NSGA-II [8], FEMO (Fair Evolutionary MultiobjetiveOptimizer) [17], IBEA (Indicator Based EvolutionaryAlgorithm) [17], etc. Para resolver este problema dediseño se han utilizado los módulos selectores queimplementan los algoritmos NSGA-II y SPEA-II, ambossobradamente conocidos.Como instancia (conjunto de datos que definen elproblema) de prueba se han utilizado únicamente losdatos procedentes de Ko et al. [14], que reproducen lacomunicación entre las diez ciudades chinas máspobladas, puesto que no se ha encontrado otra instanciasuficientemente detallada.A. Detalles de diseño del problemaEn este problema se optimizan los dos factores másimportantes en el diseño de redes de Internet: el coste deinstalación (no de mantenimiento) de la red y el retardode las comunicaciones [12].Una instancia particular de este problema se definemediante el número de nodos de la red (N), la distanciaentre los nodos (D, una matriz de NxN elementos), eltrafico estimado entre los nodos (T, una matriz de NxNelementos), el número de tipos de nodos disponibles (K,con sus características de coste y capacidad), el númerode tipos de enlaces existentes (M, con sus respectivosvalores de coste y capacidad), el coste de losamplificadores de señal (A) y la máxima distancia que laseñal puede viajar a través de la red sin necesidad deamplificación (L). Estos dos últimos parámetros (A y L)son debidos a que se trata de una red de fibra óptica.Las funciones objetivos son dos. Por un lado, el coste dedespliegue de la red y 1 ,, que es definido en base al costede los nodos, el coste de los amplificadores de señal y elcoste de los enlaces. Y, por otro lado, el retardo y 2 , quese establece en base al modelo de tráfico utilizado; eneste caso se ha decidido utilizar Poisson [18], un modelopara redes convencionales. Nótese que con Co NEi sequiere hacer referencia al coste de un determinado nodollamado i, con Co Linki,j al coste de el enlace entre losnodos i y j, y con Cp Linki,j a la capacidad de el enlaceentre los nodos i y j.Dijy Co(NECo )1Link A1ijii j i j L T _ acuij T_ acuiji j CpLinkijy2CpLinkijAmbas funciones objetivo han sido utilizadas en otrosestudios [7] [15].B. Implementación del módulo variatorPara la implementación del módulo variator que defineel problema aquí planteado, se ha seguido al pie de letrala especificación de la plataforma en [10], para asíasegurar la correcta comunicación del módulo con losselectores ya implementados. Se podría hablardetalladamente sobre la codificación de cada uno de losestados de módulo variator, pero debido al escasoespacio disponible tan solo se hablará de los aspectosbásicos de diseño en algoritmos evolutivos.1) Codificación utilizadaLos individuos han sido codificados en forma decromosomas. Cada uno representa una posibletopología-solución. Este cromosoma de longitud fija sedivide en dos partes, como se observa en la figura 4. Laprimera parte es la responsable de definir el tipo de cadauno de los nodos de la red. La segunda representa losenlaces existentes entre los nodos, donde uno indica laexistencia de un enlace y cero lo contrario.Fig. 4. Cromosoma de longitud fija que representa a los individuos delproblema.ijJP2011-66

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20112) Generación de la población inicialLa población inicial es generada mediante una mezclade procesos aleatorios y deterministas. En primer lugar,se asigna de forma aleatoria el tipo a cada uno de losnodos. A continuación, se obtiene el árbol mínimo dedistancias entre todos los nodos, utilizando el algoritmode Prim [19]. Finalmente se añaden de forma aleatorianuevos enlaces al árbol generado. Una vez generado elindividuo, se comprueba que sea una topología válida(ver apartado B-3) y que no se encuentre repetido. Si escorrecto se almacena, en caso contrario, se descarta.3) Evaluación de los individuosPara cada individuo, además de obtener los valores desus correspondientes funciones objetivo, se determina siconforma una solución válida. Para ello se comprueba sicumple con las condiciones del problema: biconexidad(la red debe ser confiable, cada nodo accesible al menosdesde dos rutas diferentes), tipos de nodos válidos(podría haber tipos inexistentes producidos pormutaciones) y si la capacidad de cada enlace essuficiente para el tráfico generado en la red (se utiliza lapropuesta de Dijsktra [19] para obtener los requisitos decada enlace debido al tráfico total de red). Si unindividuo no es válido, su coste y retardo tomaránvalores infinitos, desechándose en iteraciones sucesivas.4) Estrategias en cruces y mutacionesLa recombinación se ha realizado atendiendo a que loscromosomas se encuentran divididos en dos partes biendiferenciadas. Se realiza el cruce entre las primeraspartes de los individuos seleccionando el punto de crucede forma que no modifique la codificación de los tiposde nodos. De este modo, la recombinación de dosindividuos dará lugar a un tercero en el que los tipos denodos posibles serán únicamente los de sus padres; encaso contrario generaría una gran cantidad de individuosinválidos. El punto de cruce en la segunda parte se sitúade forma completamente aleatoria. La mutación tambiénse ha realizado teniendo en cuenta esta mismacircunstancia, realizando un número de mutaciones quepuede ir desde 0 hasta el número de bits totales delcromosoma. El punto de cruce de la primera y segundaparte sigue criterios similares a los de la recombinación.C. Resultados experimentalesEn este apartado se exponen los datos obtenidos en laresolución del problema mediante el módulo variatorimplementado y un par de módulos selectores yaexistentes en la comunidad PISA: NSGA-II y SPEA-II.A la hora de ejecutar la plataforma se ha utilizado elmonitor paralelo propuesto en este artículo, realizandouna comparativa con el ya existente.Todos los experimentos han sido realizados en unclúster de procesadores paralelos compuesto por 5nodos, cada uno de ellos con cuatro procesadores Intel®Xeon a 3.0Ghz y 1 de GB memoria RAM.A la hora de realizar la experimentación se ha utilizadouna sencilla estrategia. Primero se determinan lasconfiguraciones con las que se obtienen los mejoresresultados para cada algoritmo. Después, y en base aestos resultados, se estudia si alguno de los dosalgoritmos ofrece un comportamiento superior al otro.Como se ha selñalado anteriormente, el primer paso dela experimentación consiste en ajustar los parámetrosmás habituales para determinar con qué configuración seobtienen los mejores resultados. Estos parámetros son:número de generaciones, tamaño de la población,probabilidad de cruce y probabilidad de mutación. Estametodología es similar a la propuesta por A. Rubio-Largo et al. [13], en la que, partiendo de unaconfiguración por defecto, se van fijando los valores delos parámetros uno a uno en su valor óptimo, hasta quese han ajustado todos.A la hora de establecer el grado de bondad que tienenlos frentes obtenidos para cada configuración, esnecesario utilizar algún tipo de medida. En este caso seha decidido utilizar una medida habitual en este tipo deestudios: el hipervolumen [11]. A mayor valor dehipervolumen, mejor es la solución. A la hora decalcular este valor de evaluación es necesario definir lospuntos de referencia máximo y mínimo. Así, essuficienet contar con los puntos {1.000.000, 0.9} comomáximo y {0, 0} como mínimo, para las tuplas {coste,retardo}, pues envuelven a todos los frentes obtenidos.TABLA ICONFIGURACIONES IDÓNEAS OBTENIDAS PARA CADA UNO DE LOSALGORITMOSAlgoritmos GeneracionesPoblaciónProb.CruceProb.MutaciónHipervolumenNSGA-II 800 250 0.8 0.5 0.975SPEA-II 800 250 0.6 0.5 0.976TABLA IITIEMPOS DE EJECUCIÓN EN LA UTILIZACIÓN DE AMBOS MONITORESPARA UN NÚMERO VARIABLE DE REPETICIONESTiempo de ejecución (s)SPEA-II NSGA-II Repeti Configuración delSec Par Sec Par ciones clúster480 100 690 150 5 5 nodos con 1 core1000 102 1320 152 10 5 nodos con 2 cores1970 105 2437 151 20 5 nodos con 4 cores2960 201 3658 261 30 5 nodos con 3 coresy 2 repeticiones4050 205 4925 263 40 5 nodos con 4 coresy 2 repeticionesFig. 5. Comparativa entre los tiempos obtenidos en la ejecución deambos monitores, para diferente número de repeticiones.Utilizando las configuraciones mostradas en la tabla 1.JP2011-67

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Siguiendo la metodología comentada, podemos afirmarque los algoritmos ofrecen sus mejores resultados conlas configuraciones expuestas en la Tabla 1, obteniendode media unos hipervolúmenes superiores el algoritmoSPEA-II frente al algoritmo NSGA-II.Este procedimiento se ha realizado utilizando ambosmonitores. Como es de esperar, las conclusionesobtenidas han sido las mismas, puesto que los resultadosobtenidos son exactamente iguales. Lo que sí se ha vistoafectado ha sido el tiempo necesario a la hora deejecutar todas estas pruebas, puesto que para cada unade las configuraciones probadas se han realizado un totalde 20 ejecuciones para obtener validez estadística.Para mostrar de forma sencilla la ventaja que aporta elmonitor propuesto con respecto al ya existente, se harealizado un sencillo experimento (Tabla 2): cadaconfiguración mostrada en la Tabla 1 se ejecuta unnúmero variable de ocasiones (Tabla 2: campoRepeticiones) utilizando ambos monitores (Tabla 2: sectiempo utilizando el monitor original y par para elmonitor propuesto). Dependiendo del número derepeticiones será necesario utilizar una determinadaconfiguración del clúster (como ya se comentó en laaanterior sección). Esta configuración del clúster seespecifica en el campo config.Cluster de la Tabla 2.Como puede observarse en la figura 5 los tiemposproporcionados por el monitor propuesto son muchomenores que los ofrecidos por el monitor original. Elaumento del número de repeticiones provoca una crecidalineal de los tiempos del monitor PISA, mientras quecon el propuesto los tiempos sufren un incrementomucho menor. Además, puede observase cómo paradiferente número de repeticiones (5, 10 y 20) lostiempos obtenidos son casi idénticos; esto se debe a querealmente para los dos primeros valores no se estáexprimiendo al máximo el potencial del clúster, mientrasque para el último sí (Tabla 2). Estas pequeñasvariaciones observadas son fruto de las comunicaciones:a mayor volumen de datos más tiempo de comunicación.Situación similar ocurre con 30 y 40 repeticiones.Como se ha demostrado experimentalmente, laalternativa propuesta en este trabajo supone una granventaja con respecto al sistema actualmente utilizado.V. CONCLUSIONES Y TRABAJOS FUTUROSEn este artículo se propone una paralelización de laplataforma PISA para adecuar su utilización a entornosde computación paralela. Se ha demostrado, mediante laresolución de un problema de optimización multiobjetivopara el diseño de redes, cómo esta propuestaaporta grandes ventajas en la productividad obtenida, alejecutar una determinada configuración del problema enmúltiples ocasiones, lo cual es necesario para dotar devalidez estadística a los resultados. Como línea detrabajo futuro pensamos que esta propuesta podría servalidada contra otros problemas de optimización(módulos variator) ya existentes en la comunidadcientífica, de forma que pueda ser finalmente puesta adisposición de los usuarios para que la utilicenlibremente. Además, podría estudiarse también laposibilidad de utilizar OpenMP [21] para paralelizar eltrabajo dentro de cada nodo directamente.VI. AGRADECIMIENTOSEl presente trabajo ha sido parcialmente financiado porel Ministerio de Ciencia e Innovación y el FEDER(Fondo Europeo de Desarrollo Regional), bajo elproyecto TIN2008-06491-C04-04 (proyecto MSTAR), ypor la Junta de Extremadura, a través de la ayudaGR10025 al grupo TIC015.VII. REFERENCIAS[1] B. Dengiz, F. Altiparmak, y A.E. Smith, Local searchgenetic algorithm for optimal design of reliable networks, IEEE Trans.on Evolutionary Computation, vol.1, Sep.1997, pp. 179-188.[2] A. Mucherino y O. Seref, Modeling and Solving Real-LifeGlobal Optimization Problems with Meta-heuristic Methods, inAdvances in Modeling Agricultural Systems, vol. 25, Boston, MA:Springer US, 2009, págs. 1-17.[3] Rong-Hong Jan, Fung-Jen Hwang, , y , Sheng-Tzong Chen,Topological optimization of a communication network subject to areliability constraint, IEEE Trans. on Reliability, 42, 1993, pp. 63-70.[4] Cem Ersoy and Shivendra S. Panwar, Topological design ofinterconnected LAN/MAN networks, IEEE Journal on Selected Areasin Communications, vol. 11, 1993, pág. 1172--1182[5] C. Coello Coello, Evolutionary algorithms for solvingmulti-objective problems, 2nd ed. New York: Springer, 2007.[6] F.N. Abuali, D.A. Schoenefeld, y R.L. Wainwright,Designing telecommunications networks using genetic algorithms andprobabilistic minimum spanning trees, Proc. 1994 ACM symposiumon Applied computing, Phoenix, Arizona, USA: 1994, págs. 242-246.[7] N. Banerjee y R. Kumar, Multiobjective network design forrealistic traffic models, Proceedings of the 9th annual conference onGenetic and evolutionary computation - GECCO ’07, London,England: 2007, pág. 1904.[8] Kalyanmoy Deb, Samir Agrawal y Amrit Pratap y TMeyarivan, A Fast Elitist Non-dominated Sorting Genetic Algorithmfor Multi-objective Optimization: NSGA-II, Parallel Problem Solvingfrom Nature PPSN VI, 2000.[9] E. Zitzler, M. Laumanns y L. Thiele, SPEA2: Improvingthe strength Pareto evolutionary algorithm, EUROGEN 2001.[10] Stefan Bleuler, Marco Laumanns, Lothar Thiele, EckartZitzler, PISA - A Platform and Programming Languaje IndependentInterface for Search Algorithms, Berlin: Springer, Evolutionary Multi-Criterion Optimization, 2003.[11] Carlos M.Fonseca, Joshua D.Knowles, Lothar Thiele andEckart Zitzler, A Tutorial on the Performance Assessment ofStochastic Multiobjetive Optimizer. Guanajuato, Mexico: EMO, 2005[12] Andrew S. Tanenbaum, Computer Networks, Prentice Hall,2003.[13] A. Rubio-Largo, M.A. Vega-Rodriguez, J.A. Gomez-Pulido, y J.M. Sanchez-Perez, A Differential Evolution with ParetoTournaments for solving the Routing and Wavelength Assignmentproblem in WDM networks, IEEE Congress on EvolutionaryComputation, Barcelona, Spain: 2010, págs. 1-8.[14] King-Tim Ko, Kit-Sang Tang y Cheung-Yau Chan y Kim-Fung Man, , y , Sam Kwong, Using genetic algorithms to design meshnetworks, Computer, vol. 30, Ago. 1997, págs. 56-61.[15] R. Kumar, P.P. Parida, y M. Gupta, Topological design ofcommunication networks using multiobjective genetic optimization,Proceedings of the 2002 Congress on Evolutionary Computation.CEC’02 (Cat. No.02TH8600), Honolulu, HI, USA: , págs. 425-430.[16] C. Coello Coello, Evolutionary algorithms for solvingmulti-objective problems, New York: Springer, 2007.[17] Marco Laumanns, Lothar Thiele, Eckart Zitzler, EmoWelzl y Kalyanmoy Deb Asdf, Running Time Analysis of MultiobjectiveEvolutionary Algorithms on a Simple Discrete OptimizationProblem, London, Springer, 2002.[18] Mohsen Guizani, Ammar Rayes, Bilal Khan and Ala Al-Fuqaha.,Network Modeling and Simulation: A Practical Perspective,Wiley-Interscience, 2010.[19] T. Cormen, Introduction to algorithms, Cambridge Mass.:The MIT Press, 2001.[20] W. Gropp, Using MPI: portable parallel programmingwith the message-passing interface, Cambridge Mass.: MIT Press,1999.[21] B. Chapman, Using OpenMP: portable shared memoryparallel programming. Cambridge Mass.: The MIT Press, 2007.JP2011-68

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Comparando Modelos Paralelos Basados enIslas para el Problema del Posicionamiento deAntenas MultiobjetivizadoCoromoto León, Eduardo Segredo y Carlos Segura 1Resumen— El Problema del Posicionamiento de Antenas– Antenna Positioning Problem (app), es un problemade optimización NP-completo enmarcado en elcampo de las telecomunicaciones. El objetivo es identificarlas infraestructuras necesarias para estableceruna red inalámbrica. En este artículo se ha utilizadouna versión mono-objetivo del mismo. El algoritmoque mejor se comporta actualmente para dicha versiónes una estrategia que incorpora información dependientedel problema. Sin embargo, también se handefinido otros métodos que minimizan el uso de informacióndependiente del problema. En particular, lamultiobjetivización proporciona soluciones de una calidadsimilar a las proporcionadas por estrategias queincorporan información dependiente del problema. Noobstante, se necesita una elevada cantidad de tiempopara converger a dichas soluciones de gran calidad. Elprincipal objetivo del presente trabajo se ha centradoen disminuir el tiempo empleado para resolver el appmediante el uso de técnicas de multiobjectivización.Para ello, se ha aplicado un modelo paralelo basado enislas a dos instancias del app. Además, se han probadodiferentes esquemas de migración para comprobarla robustez de la aproximación. Finalmente, se ha llevadoa cabo un estudio de escalabilidad junto con elmejor esquema de migración. Los resultados computacionaleshan demostrado la validez de la propuesta.Palabras clave— Multiobjetivización, Antenna PositioningProblem, Modelos Paralelos basados en Islas.I. IntroducciónEL Problema del Posicionamiento de Antenas –Antenna Positioning Problem (app) es uno delos principales problemas [1] de optimización queaparecen a la hora de establecer redes de telecomunicacionesmóviles. Consiste en identificar las infraestructurasnecesarias para establecer una red decomunicaciones inalámbrica. El app trata de identificarlas ubicaciones más prometedoras en las queposicionar un conjunto de Estaciones Base – BaseStations (bs) o antenas. Las ubicaciones se seleccionande un conjunto de candidatas. Dependiendo de laformulación del problema, se pueden tener en cuentadiferentes objetivos a optimizar. Los más típicos consistenen minimizar el número de antenas, maximizarla cantidad de tráfico soportado por la red, maximizarla calidad de servicio, y/o maximizar el área decubrimiento. Además, también se pueden considerardiferentes restricciones. Este problema desempeña unpapel muy importante en el ámbito de la industria,la ciencia y la ingeniería, debido a que las solucionesobtenidas afectan en gran medida a los costes, benefi-1 Dpto. de Estadística, I.O y Computación, Universidad deLa Laguna, Edificio de Física y Matemáticas, Avda. AstrofísicoFco. Sánchez s/n, 38271 La Laguna, Tenerife, e-mail:(cleon|esegredo|csegura)@ull.es.cios y otros indicadores relevantes para una empresao negocio. Por ello, se deben diseñar algoritmos de calidadpara resolver este tipo de problemas, dado quetienen un impacto directo sobre dichos indicadores.En el presente artículo, se trata el app. Este problematambién es conocido en la literatura como elproblema del Diseño de Redes de Radio – Radio NetworkDesign (rnd) o el Problema de la Localizaciónde Estaciones Base Transmisoras – Base StationTransmitters Location Problem (bst-l). El app es unproblema np-completo [2]. Varias formulaciones delproblema han sido propuestas [3], la mayoría de ellasmono-objetivo [4]. En [5], el app se trató como unproblema mono-objetivo, transformando el resto deobjetivos en restricciones. En [6], se trató una versióncon varios objetivos y se aplicaron estrategias multiobjetivo.En este trabajo, se ha utilizado la variantemono-objetivo presentada en [7], [8]. En esta versión,la función de fitness tiene en cuenta el cubrimientologrado en la red y el número de bs desplegadas.Se han aplicado muchas estrategias a versionesmono-objetivo y multi-objetivo del app. La mayoríade ellas incorporan información dependiente delproblema. Adaptar estas estrategias a otras variantesdel problema es uno de los principales inconvenientesde las mismas. Por otro lado, dichas aproximacionestienen un enorme coste de diseño asociado. En [9],[5], se diseñaron varias heurísticas a medida paratratar el app. En [7], [8], se aplicaron estrategiasevolutivas a este problema. En [8], se incorporó informacióndependiente del problema en los operadoresde mutación. Una amplia comparativa de técnicasmono-objetivo aplicadas a la versión del app tratadaen este artículo se expuso en [2]. En dicho trabajo,las técnicas que no incorporaban información dependientedel problema obtuvieron soluciones de peorcalidad que las obtenidas por las técnicas que usabaninformación dependiente del problema. No obstante,debido a los inconvenientes de usar aproximacionesbasadas en información dependiente del problema,también se han probado diferentes alternativas quepermiten minimizar la utilización de este tipo de información.En [3], se aplicaron Algoritmos EvolutivosMulti-objetivo – Multi-objective Evolutionary Algorithms(moeas) al app. En dicho artículo se utilizóla formulación matemática de este mismo trabajo,con la diferencia de que el cubrimiento y elnúmero de bs se consideraron como dos objetivos independientes.En este caso, se consiguió mejorar ladiversidad de las soluciones. Sin embargo, los moeasJP2011-69

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011no consiguieron alcanzar valores de fitness tan altoscomo los obtenidos por las técnicas dependientesdel problema. Otra posible alternativa para minimizarel uso de información dependiente del problemase puede encontrar en la multiobjetivización. Eltérmino multiobjetivización se introdujo en [10] parareferirse a la técnica de convertir un problema monoobjetivoen uno multi-objetivo. En [11], un conjuntode aproximaciones basadas en multiobjetivizaciónconvergieron más lentamente a la resolución del appque las técnicas dependientes del problema. No obstante,con ejecuciones más largas, fueron capaces dealcanzar soluciones de similar calidad.Para reducir el tiempo de cómputo, se han propuestonumerosos estudios que consideran la paralelizaciónde moeas [12]. Los Algoritmos EvolutivosMulti-objetivo Paralelos – Parallel MultiobjectiveEvolutionary Algorithms (pmoeas), teniendoen cuenta el paradigma de programación paralelopara el que han sido diseñados, se pueden clasificar[13] en: master-worker, basados en islas o difusión.Cuando se compara con otros modelos paralelos,la aproximación basada en islas aporta dos beneficiosnotables: primero, se adapta fácilmente a lasarquitecturas paralelas, y segundo, permite extenderel espacio de búsqueda de soluciones, tratando de evitarla caída en óptimos locales. Además, los modelosbasados en islas han demostrado su buen rendimientoy su escalabilidad en numerosas áreas [12]. Conceptualmente,la población total de un pmoea se divideen un número determinado de sub-poblaciones,o lo que es lo mismo, se aplica un moea a una subpoblaciónen cada isla de manera totalmente independiente.En cada isla, la población evoluciona demanera aislada la mayoría del tiempo, pero algunasveces, los individuos pueden migrar de una isla aotra. La migración es una operación esencial en estetipo de modelos paralelos, dado que fomenta la cooperaciónentre islas. De ahí que su diseño sea unfactor determinante para obtener un pmoea de altacalidad. En este artículo, se ha comprobado la validezde un modelo híbrido que combina un modelo paralelobasado en islas con técnicas de multiobjetivizaciónaplicadas al app. Para comprobar la robustez de lapropuesta, se ha llevado a cabo una comparativa entrediferentes esquemas de migración incorporadosal modelo. Además, se ha realizado un estudio de escalabilidadde la aproximación, junto con el mejoresquema de migración de la comparativa anterior.El principal objetivo del trabajo ha sido la disminucióndel tiempo empleado por las técnicas basadasen multiobjetivización en alcanzar el mismo nivel decalidad que el obtenido por las estrategias que incorporaninformación dependiente del problema.El resto del artículo se estructura tal y como sigue:la formulación matemática del app se expone en laSección II. En la Sección III se describe el métodode optimización utilizado. La estrategia secuencialse detalla en la Sección III-A. Específicamente, sedescriben los métodos de multiobjetivización y losoperadores genéticos utilizados. En la Sección III-B,se dan los detalles del modelo paralelo basado enislas. A continuación, la Sección IV presenta los resultadoscomputacionales obtenidos durante los experimentos.Por último, se comparten algunas conclusionesy líneas de trabajo futuro en la Sección V.II. Formulación Matemática del appEl app se define como el problema de identificar lasinfraestructuras necesarias para establecer una redde comunicaciones inalámbrica. Esta formulación delproblema trata de maximizar el cubrimiento de unárea geográfica dada, a la vez que trata de minimizarel número de bs desplegadas. Una bs es un dispositivode transmisión de señales de radio que siguenun modelo de onda determinado. La región del áreacubierta por una bs se conoce con el nombre de célula.En la definición del app aquí considerada, una bssólo puede posicionarse en una ubicación de entre unconjunto de potenciales ubicaciones. La formulaciónmatemática de esta versión del app fue propuestaen [7], [8]. La función de fitness viene dada por:f(solucion) = CubrimientoαT ransmisoresObservando la ecuación anterior, se debe seleccionarun valor para α, teniendo en cuenta la importanciaque se le desea dar al cubrimiento en comparacióncon el número de bs desplegadas. Tal y como se propusoen [7], [8], se ha utilizado un valor α = 2.El área geográfica G en la que se debe desplegar lared se discretiza en un número finito de puntos o localizaciones.T am x y T am y representan el número desub-divisiones verticales y horizontales, respectivamente.Expertos en comunicaciones son los encargadosde fijar estos parámetros en función de las característicasdel terreno y de las bs. U es el conjunto delocalizaciones donde puede desplegarse una bs: U ={(x 1 , y 1 ), (x 2 , y 2 ), ..., (x n , y n )}. U[i] hace referencia ala localización i. Las coordenadas x e y de una localizacióni utilizan la notación U[i] x y U[i] y , respectivamente.Se dice que una célula C[i] se encuentracubierta si una bs se encuentra desplegada en la localizacióni. En el presente trabajo, las bs irradianuna señal que sigue un modelo isotrópico. El conjuntoP determina las localizaciones cubiertas por unabs: P = {(∆x 1 , ∆y 1 ), (∆x 2 , ∆y 2 ), ..., (∆x m , ∆y m )}.Por ello, si se despliega la bs i, las localizacionescubiertas por la misma son las siguientes: C[i] ={(U[i] x + ∆x 1 , U[i] y + ∆y 1 ), (U[i] x + ∆x 2 , U[i] y +∆y 2 ), ..., (U[i] x + ∆x m , U[i] y + ∆y m )}. Siendo B =[b 0 , b 1 , ..., b n ] el vector binario que determina las bsdesplegadas, se obtienen las siguientes definiciones:Cubrimiento =T ransmisores = ∑ ni=0 b i∑ tamx∑ tamycubrir(i,j)i=0 j=0tam x×tam y× 100donde:{ 1 Si ∃ i/{(bi = 1) ∧ ((x, y) ∈ C[i])}cubrir(x, y) =0 En otro casoJP2011-70

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011III. Esquema de OptimizaciónA. Aproximación SecuencialEl esquema de optimización con mejor comportamientode [11] ha sido aplicado en este artículo.El esquema se basa en el algoritmo Non-dominatedSorting Genetic Algorithm II (nsga-ii). El app seha multiobjetivizado añadiendo una función objetivoartificial. La multiobjetivización modifica la formadel espacio de decisión de un problema, por loque puede ayudar a evitar la caída en óptimos locales[14]. No obstante, también puede provocar queel problema pase a ser más difícil de resolver [15].Existen dos vías diferentes a la hora de multiobjetivizarun problema. La primera de ellas se basa endescomponer la función objetivo original, mientrasque la segunda consiste en añadir nuevas funcionesobjetivo. La adición de nuevos objetivos se puedellevar a cabo teniendo en cuenta información dependienteo independiente del problema. Para multiobjetivizarel app, se escogió la función de fitness expuestaen la Sección II como primer objetivo, mientrasque para el segundo objetivo se utilizó una funciónartificial que trata de maximizar la diversidadde las soluciones. En [11], se comprobó el rendimientode diferentes funciones artificiales. La que obtuvolos mejores resultados se basa en obtener la distanciaEuclídea al mejor individuo de la población, es decir,aquel que posee el valor de fitness más prometedor.Gracias a que la presión de selección disminuye, algunosindividuos de baja calidad podrían sobrevivirdurante varias generaciones. No obstante, en ciertomomento, podrían ayudar a escapar de óptimos locales.De hecho, la mejor estrategia basada en multiobjetivizaciónpropuesta en [11] fue capaz de obtener,en ejecuciones largas, soluciones de una calidadsimilar a las obtenidas por las estrategias que incorporabaninformación dependiente del problema.El algoritmo nsga-ii hace uso de una fase devariación, la cual consiste en la aplicación de un operadorde cruce y de un operador de mutación. El esquemade optimización aplicado usa los operadoresgenéticos que mejor comportamiento demostraronen [3]. El operador de mutación aplicado ha sido elBit Inversión Mutation. Con este operador, cada gende un individuo se invierte con una probabilidad p m .Por otro lado, el operador de cruce utilizado ha sidoel Geographic Crossover y se ha aplicado con unaprobabilidad p c . Este operador intercambia las bsque se encuentran posicionadas a cierto radio r deuna bs seleccionada al azar. Por último, mencionarque los individuos se han codificado como cadenas binariasde n elementos, donde n representa el númerode posibles localizaciones donde ubicar una bs.B. Aproximación ParalelaSe ha considerado la paralelización para reducir eltiempo de ejecución empleado por la estrategia secuencialdescrita en la Sección III-A durante la obtenciónde soluciones de alta calidad. En concreto,se ha aplicado un modelo paralelo basado en islas.En este tipo de modelos, la población se divide enun número determinado de sub-poblaciones. Cadauna de estas sub-poblaciones se asocia con una isladeterminada, y sobre cada una de ellas se ejecutaun moea o configuración de manera independiente.Generalmente, en cada isla, la población evolucionade manera aislada la mayoría del tiempo. No obstante,añadir cierto comportamiento colaborativo alesquema podría llevar a obtener un mejor comportamiento.Es por ello que se suele incorporar con bastantefrecuencia un esquema de migración que permitetransferir individuos de unas islas a otras.Existen cuatro modelos basados en islas diferentes[13]: todas las islas ejecutan la misma configuración(homogéneo), todas las islas ejecutan una configuracióndiferente (heterogéneo), cada isla evalúaun subconjunto diferente de funciones objetivo y cadaisla representa una región distinta en los dominiosdel fenotipo o del genotipo. La aproximación paralelautilizada en el presente trabajo se basa en el modelode islas homogéneo, con cada isla ejecutando laestrategia expuesta en la Sección III-A.El esquema de migración es un componente esencialen este tipo de modelos paralelos debido a quefomentan la colaboración entre islas. De ahí que sudiseño sea un factor determinante para obtener unbuen rendimiento. Gracias a un buen esquema de migración,el espacio de búsqueda de soluciones se podríaexplorar con más profundidad, y se podrían obtenersoluciones de más alta calidad. Sin embargo, sino se aplica un esquema de migración o dicho esquemase encuentra mal diseñado, el efecto podría llegara ser similar, e incluso peor, al obtenido por un conjuntode moeas ejecutando de forma independienteen un número de procesadores determinado sinque exista ningún tipo de comunicación entre ellos.Los componentes que se deben definir a la hora dediseñar un esquema de migración son los siguientes:la topología de migración (dónde se migran los individuos),el índice de migración (el número máximode individuos que se migran y con qué frecuencia semigra), la estrategia de selección de individuos quese van a migrar desde la isla de origen y la estrategiade reemplazo de individuos en la isla de destino.Dependiendo del esquema de migración utilizado,la forma del espacio de decisión de un problema se veafectada [16]. Por ello, en este trabajo se ha comprobadoel funcionamiento del modelo basado en islascon cuatro esquemas de migración diferentes. Los esquemasse han obtenido gracias a la combinación dediferentes estrategias de selección con diferentes estrategiasde reemplazo. Se han probado dos estrategiasde selección: Elitista (eli) y Aleatoria (rnd).Con la estrategia eli, se selecciona un individuo amigrar si es mejor que cualquiera de los miembros dela población de la generación anterior. La estrategiarnd elige los individuos a migrar de manera aleatoria.Por otro lado, también se han analizado dosestrategias de reemplazo: Elitist Ranking (eli), yAleatoria (rnd). La estrategia eli agrupa los individuosde la población de la isla de destino en diferentesrankings haciendo uso del operador de crowdingJP2011-71

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011117.3Instancia ArtificialInstancia de Malaga117.2164117.1117162Fitness116.9116.8116.7ELI-RNDELI-ELI116.6RND-RNDRND-ELISEQ116.50 5000 10000 15000 20000Tiempo (s)Fitness160158156ELI-RNDELI-ELIRND-RNDRND-ELISEQ0 5000 10000 15000 20000Tiempo (s)Fig. 1. Evolución del Fitness - Modelos Paralelos con 4 IslasFig. 2. Evolución del Fitness - Modelos Paralelos con 4 Islasdel nsga-ii. A continuación, se reemplazan individuosseleccionados aleatoriamente del peor rankingdisponible. Con el esquema rnd, los individuos areemplazar se seleccionan aleatoriamente. Cada unode los cuatro esquemas de migración estudiados enel presente artículo siguen la siguiente nomenclaturapara su identificación: selección – reemplazo. Porejemplo, eli-rnd significa que se ha aplicado un esquemade migración con una estrategia de selecciónelitista y una estrategia de reemplazo aleatoria.IV. Resultados ComputacionalesEn esta Sección se describen los experimentos llevadosa cabo con los diferentes esquemas de optimizaciónpresentados en la Sección III. Las pruebasse han lanzado en una máquina con sistema operativoDebian GNU/Linux, 4 procesadores amd R○Opteron TM (modelo 6164HE) que corren a 1.7 GHz,y con una memoria RAM de 64 GB. El compiladorutilizado ha sido gcc 4.4.5. El compilador mpi ha sidoOpenMPI 1.4.2. Se han analizado dos instanciasdel app. La primera de ellas es una instancia realmodelando la ciudad de Málaga. Esta instancia representaun área urbana de 27.2 km 2 . El terreno seha modelado utilizando una matriz de 450 x 300,donde cada una de las casillas representa una superficiede aproximadamente 15 x 15 m 2 La instanciacuenta con n = 1000 posibles localizaciones paraubicar las bs. La segunda instancia se ha generadoartificialmente. En este caso, el terreno se ha modeladoutilizando una matriz de 287 x 287, y cuentacon n = 349 posibles localizaciones.Debido a la utilización de algoritmos estocásticos,cada ejecución se ha repetido 30 veces. Cada experimentose ha llevado a cabo para cada una de las dosinstancias analizadas. Para poder proporcionar losresultados con suficiente respaldo estadístico, se hanllevado a cabo las comparativas siguiendo el siguienteanálisis. Primero se lleva a cabo el test de Shapiro-Wilk para comprobar si los resultados siguen una distribuciónnormal (Gaussiana) o no. En caso afirmativo,se lleva a cabo el test de Levene para comprobarla homogeneidad de las varianzas. Si los resultadostienen igual varianza, se realiza el anova. En otrocaso, se lleva a cabo el test de Welch. Para distribucionesno Gaussianas, se utiliza el test no paramétricode Kruskal-Wallis que comprueba las medianas delos resultados. Todos los test se han llevado a cabocon un nivel de confianza del 95 %.Para todos los experimentos se ha utilizado la siguienteparametrización: r = 30, p c = 1, p m = 1 n .Los tamaños de población se han fijado a 50 y 100individuos para la instancia artificial y la instanciade Málaga, respectivamente.En el primer experimento se ha realizado un análisisde la robustez del modelo paralelo en términosdel esquema de migración utilizado. El modelo paralelobasado en islas ha incorporado 4 esquemasde migración diferentes, tal y como se ha descritoen la Sección III-B. El modelo paralelo, con cadauno de los esquemas de migración, ha sido ejecutadocon 4 islas y con un criterio de parada de 6 horas.Con todos los esquemas de migración se ha utilizadouna topología de migración totalmente conectada.Además, la probabilidad de migración se ha fijado a0.01, migrando un único individuo cada vez.Las Figuras 1 y 2 muestran la evolución del valorde fitness medio de las aproximaciones secuencial(seq) y paralelas, para la instancia artificial yla instancia de Málaga, respectivamente. El modeloparalelo ha mejorado claramente los resultadosobtenidos por la estrategia secuencial en ambas instancias.También se puede observar como los diferentesmodelos paralelos han obtenido valores de fitnesssimilares. De hecho, los análisis estadísticos han reveladoque las diferencias entre ellos no han sido significativas.No obstante, en ambas instancias, el valorde fitness medio más alto ha sido obtenido por el modeloparalelo que incorpora el esquema de migracióneli-rnd. Al haber obtenido soluciones de alta calidadcon el modelo paralelo, independientemente delesquema de migración utilizado, se ha demostrado larobustez de la propuesta.Debido a que los modelos paralelos han utilizadomás recursos computacionales que la estrategia secuencial,la mejora debe cuantificarse. La Run-lengthDistribution (rld) es una herramienta muy útil parallevar a cabo esta tarea. Una rld muestra la relaciónexistente entre el ratio de éxito y el tiempo. El ratiode éxito se define como la probabilidad de alcanzarcierto nivel de calidad. Las rld se han calculado paralos modelos paralelos y para la estrategia secuencial.En el caso de la instancia artificial, ya que cada modeloparalelo ha sido capaz de alcanzar el mejor valorJP2011-72

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Instancia ArtificialInstancia de Malaga110.80.8Ratio de Exito0.60.4ELI-RNDELI-ELI0.2RND-RNDRND-ELISEQ00 10000 20000 30000 40000 50000 60000 70000 80000Tiempo (s)Ratio de Exito0.60.4ELI-RNDELI-ELI0.2RND-RNDRND-ELISEQ00 10000 20000 30000 40000 50000 60000 70000 80000Tiempo (s)Fig. 3. RLD - Modelos Paralelos con 4 IslasFig. 5. RLD - Modelos Paralelos con 4 Islas1Instancia Artificial1Instancia de Malaga0.80.8Ratio de Exito0.60.4Ratio de Exito0.60.40.2PAR_16PAR_8PAR_400 5000 10000 15000 20000Tiempo (s)0.2PAR_16PAR_8PAR_400 5000 10000 15000 20000Tiempo (s)Fig. 4. RLD - Modelos Paralelos con 4, 8 y 16 IslasFig. 6. RLD - Modelos Paralelos con 4, 8 y 16 Islasde fitness conocido hasta la fecha, dicho valor ha sidoseleccionado como el nivel de calidad a alcanzar.En la instancia de Málaga la varianza de los resultadosha sido superior que en la instancia artificial.De este modo, si se eligiera el mejor valor de fitnessconocido como el nivel de calidad a alcanzar, se obtendríanratios de éxito bajos. Por ello, el nivel decalidad se ha fijado de modo que todos los modelosparalelos sean capaces de alcanzar un ratio de éxitodel 60 %. Las Figuras 3 y 5 muestran las rld de losmodelos paralelos y del modelo secuencial, para lainstancia artificial y la instancia de Málaga, respectivamente.En el caso de la estrategia secuencial, seha considerado un tiempo máximo de ejecución de 24horas. Para los modelos paralelos, el tiempo máximode ejecución considerado ha sido de 6 horas. Las rldhan confirmado la superioridad de los modelos paralelos.En algunos casos se han obtenido factores deaceleración superlineales. Esto se debe a la capacidadde los modelos paralelos para evitar la caída enóptimos locales. Las rld también han mostrado lassimilitudes entre los diferentes modelos paralelos. Apesar de estas similitudes, el modelo paralelo que incorporael esquema de migración eli-rnd ha sido elque mejor se ha comportado.El segundo experimento ha analizado la escalabilidaddel modelo paralelo propuesto. El modelo basadoen islas que incorpora el esquema de migraciónque mejor se ha comportado en el experimento anterior(eli-rnd, referenciado en este nuevo experimentocomo par4) se ha ejecutado con 8 (par8) y 16(par16) islas. Las Figuras 4 y 6 muestran sus rld,para la instancia artificial y la instancia de Málaga.Se ha considerado un tiempo máximo de ejecución de6 horas. Las rld muestran las ventajas de añadir unnúmero de procesadores mayor al modelo paralelo.Los factores de aceleración, tomando como referenciael modelo par4, se han calculado para ratios deéxito que varían entre un 25 % y un 75 %. En el casode la instancia artificial, el factor de aceleracióndel modelo par8 ha variado desde 1.57 a 1.88. Parael modelo par16, el factor de aceleración ha variadoentre 1.62 y 3.57. Para esta instancia se han detectadoproblemas de escalabilidad puntuales. De hecho,los modelos par8 y par16 han obtenido factores deaceleración similares para ciertos ratios de éxito. Noobstante, par16 ha obtenido factores de aceleraciónmás altos para otros ratios de éxito, lo que demuestralas ventajas de aplicarlo. Para la instancia de Málaga,también se han detectado algunos problemas deescalabilidad. El modelo par8 no ha demostrado obtenerninguna ventaja significativa respecto al modelopar4, ya que como puede observarse, las dosrld de estos modelos son muy similares. Sin embargo,los factores de aceleración han aumentado con laaplicación del modelo par16. Dichos factores de a-celeración, tomando como referencia el modelo par4han variado entre los valores 1.42 y 1.9.V. Conclusiones y Trabajo FuturoEl app es uno de los principales problemas de optimizaciónque surgen en el diseño de redes de telecomunicacionesmóviles. En el presente artículo, seha llevado a cabo el análisis de una estrategia híbridaque combina un modelo paralelo basado en islascon diferentes estrategias de multiobjectivizaciónJP2011-73

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011aplicadas al app. La multiobjetivización es una estrategiamás general que aquellas que hacen uso deinformación dependiente del problema. En [11], sepropusieron numerosas estrategias para multiobjetivizarel app. El esquema de optimización estababasado en el algoritmo nsga-ii. La mejor estrategiapara multiobjetivizar el app consistía en calcularla distancia Euclídea al mejor individuo de lapoblación, es decir, aquel con mayor valor de fitness.El peor inconveniente de esta estrategia era el aumentodel tiempo requerido para obtener solucionesde alta calidad, comparándola con las técnicas queincorporaban información dependiente del problema.Para disminuir el tiempo de convergencia, en estetrabajo se ha aplicado un modelo homogéneo basadoen islas. La configuración que se ha ejecutado en lasislas es la mejor encontrada para multiobjetivizar elapp [11]. Las migraciones son una operación esencialen este tipo de modelos paralelos. Por ello, seha llevado a cabo un análisis de la robustez del modeloconsiderando diferentes esquemas de migración.Los resultados computacionales han demostrado larobustez de la propuesta, independientemente del esquemade migración utilizado. Además, el modeloparalelo ha superado los resultados obtenidos porla correspondiente estrategia secuencial. De hecho,se han obtenido factores de aceleración superlinealescuando se ha aplicado el modelo con 4 islas. Tambiénse ha llevado a cabo un análisis de escalabilidaddel modelo paralelo con el esquema de migración quemejores resultados ha obtenido (eli-rnd), variandoel número de islas hasta un máximo de 16. Para ambasinstancias, se han detectado ciertos problemas deescalabilidad. El tiempo invertido en alcanzar solucionesde alta calidad ha disminuido gracias a la incorporaciónde más procesadores. No obstante, estadisminución no ha sido lineal.El trabajo futuro se centrará en la aplicación dehiperheurísticas paralelas al app. Ya que en general,el método de optimización adecuado depende de lainstancia que se desea resolver, la aplicación de hiperheurísticasparece una línea de investigación prometedora.Las hiperheurísticas, en combinación con elmodelo paralelo presentado, permitirían seleccionarde forma automática el método a aplicar en cadaisla. También sería interesante analizar otras instanciasdel app.AgradecimientosEste trabajo ha sido financiado con fondos ec(feder) y del Ministerio de Ciencia e Innovación,dentro del ‘Plan Nacional de i+d+i’ con el proyectocon número de referencia tin2008-06491-c04-02.Parte del trabajo también ha sido financiado confondos del Gobierno de Canarias correspondientes alproyecto pi2007/015. El trabajo de Eduardo Segredoy de Carlos Segura ha sido financiado gracias a lasbecas fpu-ap2009-0457 y fpu-ap2008-03213.Referencias[1] Hervé Meunier, El-Ghazali Talbi, and Philippe Reininger,“A Multiobjective Genetic Algorithm for Radio NetworkOptimization,” in In Proceedings of the 2000 Congresson Evolutionary Computation. 2000, pp. 317–324, IEEEPress.[2] S. P. Mendes, G. Molina, M. A. Vega-Rodríguez, J. A.Gómez-Pulido, Y. Sáez, G. Miranda, C. Segura, E. Alba,P. Isasi, C. León, and J. M. Sánchez-Pérez, “Benchmarkinga Wide Spectrum of Meta-Heuristic Techniques forthe Radio Network Design Problem,” IEEE Trans. Evol.Comput., pp. 1133–1150, 2009.[3] Carlos Segura, Yanira González, Gara Miranda, andCoromoto León, “A Multi-Objective Evolutionary Approachfor the Antenna Positioning Problem,” inKnowledge-Based and Intelligent Information and EngineeringSystems, Rossitza Setchi, Ivan Jordanov, RobertHowlett, and Lakhmi Jain, Eds., vol. 6276 of LectureNotes in Computer Science, pp. 51–60. Springer Berlin /Heidelberg, 2010.[4] Silvio Priem Mendes, Juan A. Gomez Pulido, MiguelA. Vega Rodriguez, Maria D. Jaraiz Simon, and JuanM. Sanchez Perez, “A Differential Evolution Based Algorithmto Optimize the Radio Network Design Problem,”in E-SCIENCE ’06: Proceedings of the SecondIEEE International Conference on e-Science and GridComputing, Washington, DC, USA, 2006, p. 119, IEEEComputer Society.[5] Dong wan Tcha, Young-Soo Myung, and June hyukKwon, “Base Station Location in a Cellular CDMA System,”Telecommunication Systems, vol. 14, no. 1-4, pp.163–173, 2000.[6] El-Ghazali Talbi and Hervé Meunier, “Hierarchical ParallelApproach for GSM Mobile Network Design,” J. ParallelDistrib. Comput., vol. 66, no. 2, pp. 274–290, 2006.[7] E. Alba, “Evolutionary Algorithms for Optimal Placementof Antennae in Radio Network Design,” InternationalParallel and Distributed Processing Symposium,vol. 7, pp. 168, 2004.[8] N. Weicker, G. Szabo, K. Weicker, and P. Widmayer,“Evolutionary Multiobjective Optimization for BaseStation Transmitter Placement with Frequency Assignment,”IEEE Trans. Evol. Comput., vol. 7, no. 2, pp.189–203, 2003.[9] Mohan R. Akella, Rajan Batta, Eric M. Delmelle, PeterA. Rogerson, Alan Blatt, and Glenn Wilson, “BaseStation Location and Channel Allocation in a CellularNetwork with Emergency Coverage Requirements,” EuropeanJournal of Operational Research, vol. 164, no. 2,pp. 301 – 323, 2005.[10] Joshua D. Knowles, Richard A. Watson, and DavidCorne, “Reducing Local Optima in Single-ObjectiveProblems by Multi-objectivization,” in Proceedings of theFirst International Conference on Evolutionary Multi-Criterion Optimization, London, UK, 2001, EMO ’01,pp. 269–283, Springer-Verlag.[11] Carlos Segura, Eduardo Segredo, Yanira González, andCoromoto León, “Multiobjectivisation of the AntennaPositioning Problem,” in International Symposium onDistributed Computing and Artificial Intelligence, AjithAbraham, Juan Corchado, Sara González, and JuanDe Paz Santana, Eds., vol. 91 of Advances in Intelligentand Soft Computing, pp. 319–327. Springer Berlin / Heidelberg,2011.[12] Enrique Alba, Parallel Metaheuristics: A New Class ofAlgorithms, Wiley-Interscience, 2005.[13] C. A. Coello, G. B. Lamont, and D. A. Van Veldhuizen,Evolutionary Algorithms for Solving Multi-Objective Problems, Genetic and Evolutionary Computation.2007.[14] Julia Handl, Simon C. Lovell, and Joshua Knowles, “Multiobjectivizationby Decomposition of Scalar Cost Functions,”in Proceedings of the 10th International Conferenceon Parallel Problem Solving from Nature: PPSN X,Berlin, Heidelberg, 2008, pp. 31–40, Springer-Verlag.[15] Dimo Brockhoff, Tobias Friedrich, Nils Hebbinghaus,Christian Klein, Frank Neumann, and Eckart Zitzler, “DoAdditional Objectives Make a Problem Harder?,” in Proceedingsof the 9th Annual Conference on Genetic andEvolutionary Computation, New York, NY, USA, 2007,GECCO ’07, pp. 765–772, ACM.[16] David A. Van Veldhuizen, Jesse B. Zydallis, and Gary B.Lamont, “Considerations in Engineering Parallel MultiobjectiveEvolutionary Algorithms,” IEEE Trans. Evol.Comput., vol. 7, no. 2, pp. 144–173, 2003.JP2011-74

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Exhaustive Program’s Robustness Analysisagainst Transient FaultsJoao Gramacho *,1 , Dolores Rexachs *,2 y Emilio Luque *,3Abstract — Computer chips implementation technologiesevolving to obtain more performance are increasing theprobability of transient faults. As this probability growsand on-chip solutions are expensive or tend to degradeprocessor performance, the efforts to deal with thesetransient faults in all levels (including the operating systemand even at the application level) are increasing. Softwarebased fault tolerance approaches against transient faultsoften use fault injection experiments to evaluate therobustness of applications with and without their faultdetection or fault tolerance proposals. Those fault injectionexperiments consumes lots of CPU time by running orsimulating the application being evaluated as many timesas necessary to obtain a reasonable valid statisticalapproximation. This paper presents the first step of ourpurpose of exhaustively analyzing program’s robustnessagainst transient faults. We use processor architectureinformation and a program trace to analyze the programrobustness in a one step evaluation without the need oftime consuming executions with fault injection.Keywords — Transient faults, robustness, reliability.TI. INTRODUCTIONhe ever growing die density of computer processorsis one of the great factors of the astonishingimprovements in processing power of the last decades.Computer chips are using smaller components, havingmore transistors, using those transistors with higherdensity and also operating at lower voltage. The sideeffect of such a scenario is that processors are lessrobust than ever against transient faults [1].Transient faults are those faults that might occur onlyonce in a system lifetime and never happen again thesame way. Transient faults in computer systems mayoccur in processors, memory, internal buses and devices,often resulting in an inversion of a bit state (i.e. singlebit flip) on the faulty location [2]. Cosmic radiation,high operating temperature and variations in the powersupply subsystem are the most common cause oftransient faults in computer systems.A transient fault may cause an application tomisbehave (e.g. write into an invalid memory position;attempt to execute an inexistent instruction). Suchmisbehaved applications will then be abruptlyinterrupted by the operating system fail-stop mechanism.Nevertheless, an undetected data corruption is thebiggest risk for applications. It happens when the flippedbit produced by the transient fault generates an incorrectfinal program result that might not be ever noticed.The errors that can be noticed by the transient faultseffect are called soft errors.We consider program’s robustness against transient* Computer Architecture and Operating Systems Department,Universitat Autònoma de Barcelona, Bellaterra (Barcelona), Spain.1 E-mail: joao.gramacho@caos.uab.es2 E-mail: dolores.rexachs@uab.es3 E-mail: emilio.luque@uab.esfaults as the ability of a program, one in presence of atransient fault, to keep running and give a correct resultwhen finish or to stop the execution when a soft error isdetected and inform about it.To evaluate a program robustness against transientfault, we consider that a program, running over andetermined architecture, will have a robustness againsttransient faults represented as a number that can varyfrom zero (0%) to one (100%), where zero implies norobustness at all (the program fail on every tested cases)and one implies the best robustness possible (theprogram gave the correct result or detected the transientfault on every tested cases).In order to test a program behavior in presence oftransient faults, it is common to put a program to betested in an environment designed to allow transient likefault injections. In this way, it is possible to evaluate ifthe program misbehaved in presence of a transient faultor if the program was robust and could finish properly ordetected the injected fault and stopped its executionavoiding the error propagation. These fault injections aremade often by flipping a bit of a processor register in agiven point during program execution.Using program execution in presence of faultinjections to evaluate its behavior can be a timeconsuming task. This is because of the need to executethe program in the fault injection environment as manytimes as needed (varying the fault injection point in timeand where to inject the fault) to have a result withsignificant statistical approximation, as we will show insection II.Our objective in this work is to propose a method tocalculate a program’s robustness, without any faultinjection execution. To do so, in section III we present amethod to calculate the amount of all possible unACEcases of a program running over a given processorarchitecture based a trace of the program execution overthe architecture and information about how thearchitecture instructions deal with processor registers.We want a method to have a precisely calculatedrobustness and also avoid the time consuming task ofdoing hundreds or thousands of program executions intransient fault injection environments.In section IV we present our experimental evaluationby comparing the result of fault injection campaignswith the results obtained using our analysis method andin section V we present our conclusion and explainabout the next steps of our method.II. ROBUSTNESS EVALUATION USING FAULT INJECTIONExperimental methods of injecting transient faults intoa program during its execution were proposed to testpurposed protection mechanisms against transient faults.On those methods, the program being evaluated isexecuted in an environment able to inject a fault in aJP2011-75

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011form of a bit flip on a program architectural state(usually a bit in a processor register). At the end of theprogram’s execution, its result is evaluated to check theeffect caused by the fault into the execution.When the program has finished correctly and haspresented the same result of a fault free execution theprogram’s architectural bit changed by the fault injectionis classified as unACE (unnecessary for anArchitecturally Correct Execution). On the other hand,when the program didn’t finished correctly, or haspresented a result different of the fault free execution,the program’s architectural bit changed by the faultinjection is classified as ACE (necessary for anArchitecturally Correct Execution).If the program being evaluated has some kind of faultdetection mechanism against transient faults theprogram architectural bits changed may trigger the faultdetection mechanism and lead the program to a fail stopavoiding the propagation of the fault effect in theprogram execution. On those cases, instead of beingclassified as ACE, as the execution finished doing a failstop and noticed that a fault happened the programarchitectural bit changed is classified as DUE (DetectedUnrecoverable Error).As changes in the ACE program architectural bits leadto an abnormal program behavior and also could lead toa result different of the obtained by a fault-freeexecution, it is common to classify those bits as SDC(Silent Data Corruption). = 1 (1)To evaluate how reliable a program is in presence oftransient faults with a sufficient large amount ofexecutions with fault injection, we can divide theamount of executions that didn’t failed (those in whichthe program architectural bit changed was classified asunACE or DUE) by total amount of executions withfault injection performed. Also, it is important to have agood distribution in which program architectural bit ischanged on each execution, since it is randomly chosen.The authors of [3] propose a soft error detectionmechanism based on source code transformation rules.The new program (compiled with the source codetransformed with the fault detection mechanism) has thesame functionality as the original program but is able todetect bit-flips in memory and processor registers duringan execution.Evaluating programs with and without their faultdetection mechanism, the authors of [3] performed a setof fault injection experiments where on each execution abit was flipped in processor registers, program codememory region or program data memory region. A totalof 52,728 executions with fault injection wereperformed to evaluate two programs (the original oneand the changed to detect soft errors), 26,364 executionsper program on average.In Error Detection by Duplicated Instructions (EDDI)[4], the authors reduced the amount of SDC cases ofprograms by, during program’s compilation, copyinginstructions but using different processor registers andadding verification for errors by comparing the value ofthe original processor register used by the program withthe value of the processor register used in the newgenerated instruction.Executing a total of four evaluations (the originalprogram, the program with EDDI and the program withthree source code based fault detection mechanisms) pereach of the eight benchmarks evaluated and executing500 simulations with fault injection per evaluation, theauthors of [4] have made a total of 16,000 simulations toaccomplish their work.On Software-Controlled Fault Tolerance [5], theauthors presented a set of transient fault detectiontechniques based on software and also hybrid (based onsoftware and hardware). Each of the proposedtechniques has a different cost/benefit relation byimproving reliability or performance.The first technique presented by [5] is SWIFT(Software Implemented Fault Tolerance) which reducesan application’s amount of SDC cases by changing theprogram during compilation time. The other techniquespresented are all hybrid. The set of those hybridtechniques is called CRAFT (Compiler-Assisted FaultTolerance). In general, reduces the amount of SDC caseseven more than SWIFT and also improve theperformance of the program in comparison withsoftware-only fault tolerance techniques.To evaluate the amount of SDC cases of an applicationwith and without the proposed fault tolerancemechanisms, the authors of [5] executed fault injectionexperiments in a simulator executing all programs to theend using a functional simulator and choosing when andwhere to inject the fault randomly. The authors classifiedthe fault injection simulation result as unACE if theflipped bit wasn’t necessary to the correct architecturalexecution, as DUE if the flipped bit triggered a faultdetection mechanism, or as SDC it the flipped bitgenerated a silence data corruption.The authors of [5] used a benchmark to evaluate howmany fault injections should be necessary to have asignificant statistical approximation of results. Theyexecuted 5,000 fault injection simulations with thebenchmark and observed that the confidence interval ofthe average of the SDC cases was ±2.0% after 946simulations, ±1.5% after 1,650 simulations and ±1.0%after 3,875 simulations.In a total of 10 sets of experiments, the authors of [5]evaluated the robustness of a set of benchmarks bysimulating 5,000 executions with fault injection (exceptfor two SWIFT variations that used 1,000 simulations).In each of 504,000 simulated executions with faultinjection a randomly chosen bit of one of 127 integerprocessor registers of IA64 processor architecture wasflipped.Because of the use of a simulator to execute deprogram with a fault injection, the authors of [5] couldsave some simulation time on the executions where thebit flipped was classified as unACE. On those cases, thesimulation could be interrupted when the simulatorobserved that the flipped bit was re-written with resultsfrom processor logical unit or with a write operationbefore having it content used.Continuing their research in fault tolerance fortransient faults, the authors of [5] propose Spot [6], atechnique to dynamically insert redundant instructions todetect errors generated by transient faults. This insertionwas made in runtime using instrumentation.JP2011-76

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Besides using a different architecture from previouswork (in [6] they used IA32 and protected only the eightgeneral purpose 32 bit registers of the architecture), theauthors didn’t use simulators. All the analysis and faultinjections were made using an instrumentation tool. Theauthors of [6] evaluated 16 benchmarks and executed atotal of 1.03 million fault injections to obtain theirresults (keeping 5,000 executions with fault injection perbenchmark and configuration evaluated).In all related work studied, the execution of a programin a transient fault injection environment could beclassified in terms of basically three labels: unACE,DUE and SDC.To compute a program’s robustness against transientfaults using fault injection we only need to divide theamount of unACE cases, plus the amount of DUE cases,by the amount of executions made in the experiment. = = 1 − (2) If all executions are classified as SDC, the robustnesswill be zero (the minimal robustness allowed). On theother hand, if all executions are classified as unACE orDUE, the robustness will be one (the maximumrobustness allowed).The robustness evaluation method using program’sexecutions with fault injection need a sufficient largeamount of executions varying the fault conditions (time,register and bit) to have a representative statisticalapproximation of the results.One aspect that must be took into account when usingfault injection to evaluate a program’s robustness is thatthis method is data dependent. Faults injected in specificbits of floating point registers can lead to almost nochange in its value depending on its original value. Also,as general purpose registers are often used as pointers tovectors or matrices of data, if this data is homogenous(e.g. a vector filled with ones) there are many changesthat can be done in registers that will make them point toa different memory position but with the same data,masking the fault injection result as unACE.Also, it is known that by using a fault injection basedevaluation of robustness, the amount of executions toevaluate a program will affect the precision ofrobustness obtained [5].Finally, using simulators or dynamicallyinstrumentation to inject fault on every programexecution will increase time needed on each executionin comparison with a time spent by the program runningdirectly in the architecture without instrumentation.III. ANALYZING A PROGRAM’S ROBUSTNESSOur objective is to evaluate a program’s robustnessexhaustively and faster than using fault injectionexecutions, even knowing that our method is based onthe evaluation of the possible effect of a single bit flipfault injection in processor registers of a givenarchitecture.To do so, we will evaluate in this first work the unACEbits of all possible execution points of the program (allpoints of program execution that a fault injection toolcould stop the program execution, perform the faultinjection and let the program finish its execution) for allprocessor registers.This evaluation will be equivalent to running as muchfault injection executions as necessary to test all bits ofall processor registers at any program execution pointbut, instead of performing all this executions, we willuse a program trace generated on a single programexecution and containing all processor instructionsexecuted by the program in the order of execution.At this point of our research we are only evaluating theunACE cases. So, by knowing all unACE bits of aprogram execution, we can calculate the minimalprogram robustness as shown in equation 3.unACE bits 0 = (3)bits evaluatedThe work we have to do is, then, to evaluate allunACE bits of a program prog execution in a givenarchitecture A.From the architecture, we need a set of processorregisters (ProcReg) and a finite non-numerical sequenceRegSize representing the register sizes in bits defined bythe f RegSize function. = , , ⋯ , (4) : ⟼ N = , , ⋯ , Also from architecture, we will need a set of processorinstructions (ProcIns) and a set ProcInsReg containingall ordered pairs of processor instructions and processorregisters of a given architecture. = , , ⋯ , (5) = , , ⋯ , , For each pair processor instruction and processorregister in ProcInsReg set, we will need two nonnumericalsequences: WrittenBits, defined by the f wbitsfunction and ReadBits, defined by the f rbits function.The f wbits function returns a vector of bits equivalent tosetting all bits of the processor register that are writtenby the processor instruction. : × ⟼ (6)The f rbits function returns a vector of bits equivalent tosetting all bits of a processor register that are read by aprocessor instruction. : × ⟼ (7)To know which processor instructions are used by theprogram being evaluated and in which sequence they areexecuted, we need a Trace prog×A as a finite sequencedefined by the function f prog that returns the processorinstruction executed by the program at given executionpoint. : N ⟼ (8) × = , , ⋯ , × Each instruction present on Trace prog×A is equivalent toa point in program execution in which is possible toinject a bit flip fault in a processor register.A. Robust state definitionLet’s consider now robust state a property of aprocessor register in a given point of a programexecution in a form of a vector of bits where all registerJP2011-77

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011bits that we can classify as unACE are set with 1 and allother register bits are cleared (with 0). The robust stateproperty can be defined also by the function f rstate that wewill detail later in this section. : × N ⟼ (9)To help us in the program robustness formula we needto define a function f abits that returns the amount of bitsset (with 1 as its value) in a given vector of bits. : ⟼ N (10)The robustness of a program prog executed over anarchitecture A can be calculated using the formula: × × = ∑ ∑ , × ∙∑ (11)In fact, the robustness of any contiguous part TPart ofthe Trace prog×A sequence (that is also a sequence),starting on point p begin until the point p end can becalculated using the formula: × =∑ ∑ , ∙∑ (12)With the robustness formula presented in equation 12we can calculate the robustness of a single instruction(by making p begin equals p end ) or the robustness of thewhole program (by making p begin equals one and p endequals the number of instructions executed by theprogram) as shown in equation 11.B. Calculating an instruction × register robust stateOur proposed method of calculating the robust state ofa single register in a given execution point of a programis based in the method proposed by the authors of [5] tosave time on those simulations where it was possible tointerrupt a simulation after the fault injection when thesimulator noticed that the flipped bit was classified asunACE.In the mentioned work, the importance of the flippedbit was checked by monitoring the use of the processorregister affected by the injection. The simulator kepttrack of the register after the fault injection.If the processor register was rewritten with resultsfrom processors logical unit (as a result of someoperation that didn’t depend on the processor registeraffected value) or with data from a read operation frommemory (that, also, didn’t depend on the processorregister affected value), the authors assumed that theflipped bit could be classified as unACE and there wasno need to keep running the simulation because they wassure of the fact that the bit flipped by the injectionwasn’t necessary to programs correct execution. Insummary, the unACE cases represent those faultinjections where the flipped bit was discarded beforeused.Besides the fact that we don’t use simulators in ourwork, to check the precedence use of processor registersvalues we have a trace of the executed program with allprocessor instructions in the order they are executed.By analyzing the trace backwards, we can, trace pointby trace point, evaluate the precedence use of processorregisters and then classify its bits (on each trace point)as unACE or no.We assume that all processor registers will have itsrobust state with all bits set (all bits unACE) after theexecution of the last program’s instruction in the trace.At this point, the program has finished its work and afault injected in any bit of any processor register won’taffect programs result. To this robust state just after thelast one present on the evaluated trace we will define thef endstate function. : ⟼ (13) = ∀: 1 ≤ ≤ → = 1Evaluating then the very last executed instruction inthe trace i, we will use the formula presented in equation14 to compute the robust state of processor registers atthis point. = × ; = (14) , = ∨ , ∧∼ , With the presented formula, if the instruction i don’tread from or write to a register reg, the values of f wbitsand f rbits will be zero and the resulting f rstate of theregister will be a copy of its f endstate .If the instruction i evaluated writes on a given registerreg, f wbits will have all its bits set to one. In this case, thevalue of the register in trace points with lower than theevaluated one will be discarded at this point and so wecan assume that at this point (before executing theinstruction i at trace point n) all register bits can beclassified as unACE.If the instruction i evaluated read from a given registerreg, f rbits will have all its bits set to one. In this case, thevalue of the register in trace points with lower than theevaluated one will be needed at this point and so we canassume that at this point (before executing theinstruction i at trace point n) all register bits can beclassified as ACE.We assume that if a processor instruction reads a valuefrom a register, compute and store a result in the sameregister, the order of the operations are first the read andthen the write. But, as we analyze the program tracebackwards, in our formula we first use the f wbits and thenuse the f rbits .All other program trace instructions in which we needto analyze the robust state of processor registers will usea formula that guarantee the order used on the analysis.1 ≤ < × ; = (15) , = , 1 ∨ , ∧∼ , At this point of our analysis we have all formulasneeded to compute the robustness of a program in agiven architecture.IV. EXPERIMENTAL EVALUATIONA. Proof of ConceptIn to check the idea presented in this work, we haveselected a simple example as a proof of concept.We developed a simple exponentiation program for the6502 processor architecture that solves the followingequation: = . The source code of theprogram is shown in Fig. 1.To evaluate the program using fault injection, we firstselected the program input parameters (three to the baseoperand and five to the exponent operand). Then, we ranthe program and stored what we consider a correctresult: 243 in the res memory position.JP2011-78

1Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011; exponentiation.65s.ORG $0200; Store machine code starting hereLDX exponent ; Load the exponent into X registerBEQ ONE ; If it is zero, the result is oneDEXLDA base ; Load the base into accumulator registerBEQ ZERO ; If it is zero, finish the operation with zero as resultSTA res ; Store the accumulator register intoMULT1: STA mul ; Store the accumulator into multiplication resultLDY base ; Load the base into Y registerDEYMULT2: ADC mul ; Add the multiplication result to the accumulatorDEY; Decrement Y registerBNE MULT2 ; Jump if is still multiplyingSTA res ; Store the accumulator into the resultDEX; Decrement X register (exponent)BNE MULT1 ; Jump if is still operating the exponentiationJMP FINISHONE: LDA #$01 ; The result is 1 (zero on exponent)JMP FINISHZERO: LDA #$00 ; The result is 0 (zero on base)FINISH: STA res ; Store the result in byte labelled resBRK; Stop running the programbase: .DB $03 ; Base operandexponent: .DB $05 ; Exponent operantres: .DB $00 ; Result of the operationmul: .DB $00 ; Auxiliar variable to multiplicationFig. 1. Simple exponentiation program source code.The 6502 processor architecture has 11 registers (fourwith eight bits and seven with one bit).The program executed 57 instructions to compute untilthe end. Thinking about a fault injection evaluation,there are 57 different fault injection points to thisprogram with the selected input parameters. On eachfault injection point the architecture has 39 different bitsto be flipped (32 from the four eight bit registers and therest from the seven one bit registers).In order to evaluate the robustness of the programrunning over the presented architecture exhaustively wewill need 2223 program executions with fault injection.Our fault injection experiment used a 6502 simulatorto run the program, pausing its execution at a givenrandomly chosen point and performing a random bit flipin an also randomly chosen processor register. In ourexperiment, we take care of avoid repeating a faultinjection with the same injection point, bit and register.As shown in Fig. 2, we scored a final robustness of49.44% with all 2223 fault injection results. We obtaineda standard deviation of 5% after 266 fault injections,2.5% after 1102 fault injections and 2% after 1738 faultinjections, all with a 95% of confidence.By generating a trace with all program’s instructionsexecuted and analyzing the trace with our methodology,we have built a graph with the program basic blocks andtheir repetition during program’s execution, as shown inFig. 3.100%90%80%70%60%Robustness-stddev+stddevFig. 3. Program source code and basic block execution graph.Evaluating our trace backwards, basic block by basicblock, calculating the robust state and the amount ofunACE bits for every basic clock instruction, weobtained a total of 1099 unACE bits, as show in Fig. 4.In order to compute the robustness using the formulapresented previously in equation 15 is necessary tocalculate the robust bits (unACE bits) of all register ofthe 6502 architecture in all 57 instruction of the programexecution trace.By dividing the amount of unACE bits of the programtrace evaluation (1099) by the amount programinstructions executed (57) multiplied by the sum of allprocessor registers sizes (39), we obtained therobustness evaluated with the analysis as 49.44%.This result was expected to be equal to the evaluationwith fault injection because, in this proof of concept, theevaluated program was sufficiently simple to allow us toperform an exhaustive fault injection campaign coveringall possible bits of all possible processor registers in allprogram execution points.Basic BlocksDescriptionInstructionA X Y N V B D I Z C SRegisters unACE bitsAll registers can be ignored. BREAK 8 8 8 1 1 1 1 1 1 1 8 39 1 39JRead from A: change its robustness to 0. STA $0232 0 8 8 1 1 1 1 1 1 1 8 31 1 31G (->J) Nothing changed. JMP $022B 0 8 8 1 1 1 1 1 1 1 8 31 1 31Read from Z: change its robustness to 0. BNE $020E 0 8 8 1 1 1 1 1 0 1 8 30 1 30Write on X, N and Z: change N and Z robustness to 1 and XF (->G) robustness to 8.DEX 0 0 8 1 1 1 1 1 1 1 8 23 1 23Read on X: change its robustness to 0.Read from A: change its robustness to 0. STA $0232 0 0 8 1 1 1 1 1 1 1 8 23 1 23Read from Z: change its robustness to 0. BNE $0215 0 0 8 1 1 1 1 1 0 1 8 22 4 88Write on Y, N and Z: change N and Z robustness to 1 and Yrobustness to 8.DEY 0 0 0 1 1 1 1 1 1 1 8 15 4 60E (->F) Read on Y: change its robustness to 0.Write on A, N, B, Z and C: change N, B, Z and C robustnessADC $0233 0 0 0 1 1 1 0 1 1 0 8 13 4 52to 1 and A robustness to 8.Read from A, C and D: change its robustness to 0.Read from Z: change its robustness to 0. BNE $0215 0 0 0 1 1 1 0 1 0 0 8 12 4 48Write on Y, N and Z: change N and Z robustness to 1 and Yrobustness to 8.DEY 0 0 0 1 1 1 0 1 1 0 8 13 4 52E (->E) Read from Y: change its robustness to 0.Write on A, N, B, Z and C: change N, B, Z and C robustnessADC $0233 0 0 0 1 1 1 0 1 1 0 8 13 4 52to 1 and A robustness to 8.Read from A, C and D: change its robustness to 0.Write on Y, N and Z: change N and Z robustness to 1 and YDEY 0 0 0 1 1 1 0 1 1 0 8 13 4 52robustness to 8.Read from Y: change its robustness to 0.D (->E) Write on Y, N and Z: change N and Z robustness to 1 and Yrobustness to 8. LDY $0230 0 0 8 1 1 1 0 1 1 0 8 21 4 84Read from A: change its robustness to 0. STA $0233 0 0 8 1 1 1 0 1 1 0 8 21 4 84Read from Z: change its robustness to 0. BNE $020E 0 0 8 1 1 1 0 1 0 0 8 20 3 60Write on X, N and Z: change N and Z robustness to 1 and XF (->D)DEX 0 0 8 1 1 1 0 1 1 0 8 21 3 63robustness to 8.Read from X: change its robustness to 0.Read from A: change its robustness to 0. STA $0232 0 0 8 1 1 1 0 1 1 0 8 21 3 63C (->D) Read from A: change its robustness to 0. STA $0232 0 0 8 1 1 1 0 1 1 0 8 21 1 21Read from Z: change its robustness to 0. BEQ $0229 0 0 8 1 1 1 0 1 0 0 8 20 1 20Write on A, N and Z: change N and Z robustness to 1 and Arobustness to 8. LDA $0230 8 0 8 1 1 1 0 1 1 0 8 29 1 29B (->C)Write on X, N and Z: change N and Z robustness to 1 and Xrobustness to 8.DEX 8 0 8 1 1 1 0 1 1 0 8 29 1 29Read from X: change its robustness to 0.Read from Z: change its robustness to 0. BEQ $0224 8 0 8 1 1 1 0 1 0 0 8 28 1 28A (->B) Write on X, N and Z: change N and Z robustness to 1 and Xrobustness to 8. LDX $0231 8 8 8 1 1 1 0 1 1 0 8 37 1 37unACE bitsRepetitionTotal unACE bitsTotal program unACE bits 109950%40%30%20%10%0%79157235313391469547625703781859937101510931171124913271405148315611639171717951873195120292107Fig. 2. Robustness chart using fault injection experiments.2185Fig. 4. Basic block analysis with the proposed methodology.B. Experimental EvaluationIn order to compare our methodology with a faultinjection campaign we designed a set of experiments tocalculate the robustness against transient faults of fiveprograms: NAS Parallel Benchmark (version 3.3) BT,CG, FT, LU and SP with their smallest class (S).JP2011-79

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011The fault injection environment used in this part f theexperimental evaluation uses a tool based on Intel PIN[7] to flip a single randomly chosen bit of a randomlychosen processor register in an also randomly chosenpoint of a program execution.In order to calculate the selected benchmarksprogram’s robustness against transient faults using themethodology proposed in this work we used a tool basedon Intel PIN [7] to store in a trace file the data collectedduring a program execution. In the stored data are theamount and the order of execution of every executedprogram’s basic block, and also all processorinstructions that compose all stored basic blocks.We also developed a program to read the storedprogram trace and, based on information about howprocessor instructions deal with registers, calculate theprogram’s robustness of each processor register byanalyzing the program trace backwards, as suggests thepresented methodology.As we present in Fig. 5, the calculated robustnessusing our methodology is always lower than thecalculated using fault injection executions or it can behigher (but almost the same) depending on the amountof executions done to calculate de robustness using faultinjection and the random number generator and seedused.Our methodology will score a lower robustnessbecause the approach of using fault injection is moredata dependent than our proposal and can mask possibleDUE and SDC as unACE.On the analysis of the CPU time spent during therobustness calculation using the proposed methodologyin Fig. 6, we used on average almost 60% of the timeneeded to run enough experiments using the besttheoretical fault injection method and achieve 2% ofstandard deviation in the statistical approximation.Also, comparing the CPU time spent during therobustness calculation using the proposed methodologywith a real fault injection environment used based ondynamic instrumentation to inject the faults, we neededon average only 1.22% of the time needed to achieve 2%of standard deviation in the fault injection statisticalapproximation.RobustnessTime (in seconds)100%90%80%70%60%50%40%30%20%10%0%100.000Fig. 5. Our methodology vs. fault injection robustness’s.10.0001.00010010129,88%420,6555,41%57,35%56,05%Fig. 6. Time spent on calculating robustness’s.49,71%BT CG FT LU SP1.205,7469.537,41Our Methodology251,11528,1618.877,20448,8362,34%Fault Injection687,68BT CG FT LU SPOur Methodology15.227,9628,93%143,38161,5239,14%Fault Injection theorical best time to achive 2% of standard deviationFault Injection using instrumentation to achive 2% of standard deviation21.590,25157,9439,18%268,0044,94%28.074,19V. CONCLUSION AND FUTURE WORKEvaluate a program’s robustness against transientfaults by using software based fault injectionenvironments and executing the evaluated program forhundreds or even thousands of times can be anexpensive task by the amount of CPU time needed toobtain a statistical approximation of the desired result,even using any type of parallelism.In this paper we proposed a methodology calculate aprogram’s robustness against transient faults based oninformation about the processor architecture used and onan execution trace of the program running over thearchitecture.The proposed methodology calculate the preciseamount of unACE bits by analyzing the execution tracebackwards and saving time by using the partial results ofrepetitions that happened during program execution.We were able to calculate the robustness almost 41%faster on average than running the programs evaluatedwith the fastest theoretical fault injection mechanismenough times to score 2% of standard deviation of theunACE cases.The next step of our work is to improve ourexperimental evaluation with more benchmarks used bythe referenced work, evaluating both the robustness andthe amount of time needed to do all experimentation.Also, as in this first step of our methodology we onlyclassify the unACE bits, in a next step of our work wewill divide the ACE bits in two classifications: DUE andSDC. By knowing precisely the amount of DUE bits of aprogram will improve even more our robustnessevaluation.ACKNOWLEDGESThis research has been supported by the MICINNSpain, under contract TIN2007-64974.REFERENCES[1] N. J. Wang, J. Quek, T. M. Rafacz, S. J. Patel, “Characterizingthe Effects of Transient Faults on a High-Performance ProcessorPipeline,” in Proceedings of the 2004 International Conferenceon Dependable Systems and Networks, pp. 61—70.[2] R. Baumann, “Soft errors in advanced computer systems,” inDesign & Test of Computers, 2005, vol. 22, pp. 258—266.[3] B. Nicolescu, R. Velazco, “Detecting soft errors by a purelysoftware approach: method, tools and experimental results,” inDesign, Automation and Test in Europe Conference andExhibition, 2003, pp. 57—62.[4] N. Oh, P. Shirvani, E. McCluskey, “Error detection by duplicatedinstructions in super-scalar processors,” in IEEE Transactions onReliability, 2002, vol. 51, pp. 63—75.[5] G. A. Reis, J. Chang, N. Vachharajani, R. Rangan, D. I. August,S. S. Mukherjee, “Software-controlled fault tolerance,” in ACMTransactions on Architecture and Code Optimization, 2005, vol.2, pp. 366—396.[6] G. A. Reis, J. Chang, D. I. August, R. Cohn, S. S. Mukherjee,“Configurable Transient Fault Detection via Dynamic BinaryTranslation,” in Proceedings of the 2nd Workshop onArchitectural Reliability (2006).[7] C. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S.Wallace, V. J. Reddi, K. Hazelwood. “Pin: building customizedprogram analysis tools with dynamic instrumentation” inProceedings of the 2005 ACM SIGPLAN conference onProgramming language design and implementation, pp. 190—200.JP2011-80

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Biblioteca de Altas Prestaciones para laResolución de Problemas MatricialesEstructuradosPedro Alonso-Jordá 1 , Pablo Martínez-Naredo 2 , F.J. Martínez-Zaldívar 3 , José Ranilla 4 yAntonio M. Vidal 5Resumen— Este artículo presenta StructPack, unabiblioteca o conjunto de subrutinas y programas queresuelven sistemas lineales estructurados, sobre arquitecturasde última generación, tanto secuenciales comoparalelas. Es un paquete de software en continuaevolución que actualmente contiene rutinas para laresolución de sistemas con matrices Toeplitz simétricastridiagonales y simétricas. StructPack puede serdescargado desde http://www.inco2.upv.es.Palabras clave— Biblioteca de software, matrices estructuradas,ToeplitzI. IntroducciónEn numerosos problemas de Ingeniería y Ciencia,la computación matricial es útil, esencial y necesaria.A menudo, los tipos de problemas matriciales queaparecen en muchos de ellos son problemas estándarbien conocidos. Las bibliotecas matriciales existentesson una útil herramienta que permiten al especialistade un campo concreto centrarse en resolver su problema,ahorrando horas de programación de rutinasnuméricas con las que éste no suele estar familiarizado.En la actualidad, existe un gran número de bibliotecasmatriciales que cubren un amplio abanicode aplicaciones científicas y tecnológicas. Por citaralgunas de ellas, nos encontramos con: LAPACK[1], ScaLAPACK [2], PETSc [3], SuperLU [4], AR-PACK [5],. . . o implementaciones comerciales comoMatlab [6], Mathematica [7], etc. Las más significativas,por ejemplo las descritas en [1], [2], [3] y[4], están diseñadas para obtener prestaciones óptimassobre computadores paralelos, bien con memoriacompartida o bien con memoria distribuida.Muchas de las bibliotecas matriciales están diseñadaspara una o más clases de matrices. Por ejemplo,LAPACK trabaja con matrices banda o densas ysus rutinas están optimizadas para este tipo de matrices.Similarmente, ARPACK está diseñada paratrabajar con matrices dispersas.Por otra parte, las matrices que surgen en muchosproblemas científicos o técnicos a menudo tie-1 Departamento de Sistemas Informáticos y Computación,Universitat Politècnica de València (Spain), email:palonso@dsic.uvp.es2 Departmento de Informática, Universidad de Oviedo(Spain), email: pmnaredo@gmail.com3 Departamento de Comunicaciones, Universitat Politècnicade València (Spain), email: fjmartin@dcom.upv.es4 Departmento de Informática, Universidad de Oviedo(Spain), email: ranilla@uniovi.es5 Departamento de Sistemas Informáticos y Computación,Universitat Politècnica de València (Spain), email:avidal@dsic.upv.esnen una estructura explícita (matrices estructuradas).Algunos ejemplos típicos de matrices estructuradasson las matrices Toeplitz, Hankel, Vandermonde,Cauchy, matrices circulantes, etc. Existen numerosasáreas en las que a menudo pueden verse estostipos de matrices. Sin ánimo de ser exhaustivospodemos citar: procesado de imágenes y señales engeneral, resolución de ecuaciones diferenciales e integrales,cálculo de funciones spline, análisis de seriestemporales, cadenas de Markov y Teoría de Colas,computación de series de potencias y polinómicas,etc. (véanse como ejemplos las referencias [8], [9],[10], [11], [12]).Existe un cierto vacío en el campo de las bibliotecasmatriciales: el de las matrices estructuradas. Escierto que ello representa un amplio y ambiguo conjuntode métodos de procesado que son dependientesdel tipo de matriz. Asimismo, es difícil concebiruna biblioteca eficiente para un gran número de casosy con cierta coherencia en el uso de la tecnologíacomputacional. En otras palabras, la creación de unabiblioteca de estas característias es un importantedesafío de trascendencia científica y tecnológica.Los precedentes más significativos para esta ideason los desarrollos presentados en Netlib [13] y SLI-COT [14]. El primero es un conjunto de rutinas queresuelven sistemas lineales de ecuaciones que datanprincipalmente de 1982 y llegan a formar parte deNetlib en los 90. El segundo precedente es un conjuntode subrutinas incluidas en el paquete SLICOTpara resolver sistemas de ecuaciones lineales con matricesToeplitz generales, matrices Toeplitz simétricasy definidas positivas y matrices Toeplitz a bloques.Hemos empezado la tarea de desarrollar una bibliotecapara el tratamiento de matrices estructuradas,motivados por su uso en numerosas aplicacionesde Procesado de Señal. La biblioteca, denominadaStructPack, tiene como objetivo la resoluciónde problemas matriciales computacionales típicoscon matrices estructuradas. Estos problemas sonfundamentalmente la resolución de sistemas linealesde ecuaciones lineales, resolución de problemas demínimos cuadrados, cálculo de autovalores y autovectores,y de la descomposición en valores singulares.Algunos de estos problemas han sido tratadospor algunos de los autores durante los últimos años[15], [16], [17], [18], [19]. La biblioteca está concebidapara que pueda ejecutarse sobre arquitecturasparalelas, tanto en entornos de memoria compartidaJP2011-81

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011como en entornos de memoria distribuida. A tal efectose están utilizando en su implementación entornoscomo OpenMP o MPI. También está previsto incorporarsubrutinas que permiten su utilización sobreGPU. Para ello se está utilizando el entorno CUDAde NVIDIA.Dada la amplia variedad de problemas queStructPack trata de abarcar, es inconcebible mostrarlocomo un producto cerrado y finalizado.Así pues, nuestros objetivos de diseño implican eldesarrollo progresivo de distintas rutinas. Esto tambiénpermitirá la retroalimentación necesaria paraasegurar la calidad en los desarrollos.En este artículo presentamos las ideas básicas quehan ayudado a diseñar la biblioteca y mostramosuna perspectiva general de su funcionalidad. Tambiéndescribimos el estado actual de los desarrollospresentes y cuáles son los siguientes a ser incluidos acorto plazo.El resto del artículo está organizado de la siguientemanera: la sección 2 describe algunas característicasgenerales de la biblioteca y algunos problemas que yahan sido resueltos por las rutinas de StructPack; lasección 3 muestra las principales características de lapágina web que permite acceder a la descarga de labiblioteca y a su descripción; la sección 4 presentalas capacidades de la biblioteca y algunos ejemplosde uso; por último, la sección 5 muestra las futuraslíneas de trabajo.II. Resolución de problemas estructuradoscon StructPackStructPack es una biblioteca de rutinas numéricasque resuelven problemas de Álgebra LinealNumérica con matrices estructuradas. Las rutinasestán escritas en Fortran 90/95, pero también puedenser llamadas desde C para lo que se han proporcionadolas interfaces adecuadas. Actualmente, laversión v0.1 está diseñada para un entorno Linuxy optimizada para su uso en CPU de tipo secuencialy multinúcleo, para lo cual se han utilizado lasAPI de OpenMP en su desarrollo. Las versiones paraotros sistemas operativos como Windows u otrosparadigmas de programación como memoria distribuidao para unidades aceleradoras gráficas (GPU),serán añadidas en sucesivas versiones.Los problemas a resolver con StructPack son losproblemas clásicos del Álgebra Lineal Numérica, estoes, la solucion de sistemas lineales de ecuaciones, solucióna los problemas de mínimos cuadrados, cálculode valores y vectores propios y de la descomposiciónen valores singulares. Los algoritmos implementadosen StructPack para resolver los problemas citadosanteriormente actúan sobre diferentes tipos de matrices,como matrices Toeplitz, Hankel, Vandermonde,matrices circulantes, . . . , y en general, sobre matricesque presentan estructura de desplazamiento [9]. Elloincluye casos específicos dentro de cada uno de lostipos previamente indicados, como matrices Toeplitztridiagonales, matrices simétricas definidas positivas,etc.StructPack ha sido diseñado utilizando algoritmoseficientes. Básicamente se utilizan algoritmosque usan las propiedades de desplazamiento de matricesestructuradas, siendo éstos optimizados paraarquitecturas multinúcleo. Para operaciones simplesde complejidad lineal o cuadrática, se han utilizadolos núcleos computacionales BLAS [20]. También seutilizan bibliotecas para el cálculo de la FFT, bien labiblioteca MKL de Intel [21] (si el usuario la proporciona),bien la biblioteca FFT Pack [22]. El códigofuente puede ser compilado bien utilizando compiladoresde dominio público, como GNU gcc [23], bienpor compiladores comerciales como los compiladoresde Intel.Una característica adicional e importante de la bibliotecaes que proporciona comandos para resolverproblemas directamente desde la línea de comandos.Esto proporciona una importante facilidad deuso inicial. StructPack también proporciona ficheros.mex permitiendo su uso en entornos de tipo Octave/Matlab.Actualmente, las rutinas incluidas en la bibliotecapueden ser utilizadas para:Resolver sistemas lineales con matrices de tipoToeplitz tridiagonales y simétricas.Calcular autosistemas y descomposición en valoressingulares de matrices Toeplitz tridiagonalessimétricas.Resolver sistemas lineales de ecuaciones de matricesToeplitz simétricas.Resolver sistemas lineales de ecuaciones de matricesToeplitz no simétricas.Próximamente, serán incorporadas rutinas para calcularvalores y vectores propios de matrices Toeplitzsimétricas.Toda la información sobre StructPack es de dominiopúblico y es accesible en [24]. Las siguientessecciones describen con detalle el contenido dela página web y las características principales deStructPack.III. Descripción de la página webLa estructura de la página web de Struct-Pack está organizada de manera convencional.Así pues, tiene una página “Principal” (“Main page”)y algunas pestañas para la “Instalación” (“Installation”),“Documentacion” (“Documentation”),“Test”, “FAQs”, etc.La página principal muestra una presentación delsitio web, la licencia de uso del software y las novedadesde la última versión. Además, también apareceuna breve descripción de los grupos de investigacióninvolucrados en el desarrollo del paquete, así comolos proyectos relacionados. Los siguientes ítems resumenlas pestañas más relevantes:“Documentation”: aquí se muestra un enlace ala documentación generada del software. En estadocumentación podremos encontrar toda la especificaciónde las API, así como los comandosdisponibles.JP2011-82

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011“Test”: en esta pestaña se muestra cómo ejecutarlos tests de rendimiento para obtener losresultados de tiempos de ejecución y precisióndel paquete instalado en la máquina.“Working Notes”: las notas de trabajo o workingnotes estarán almacenadas en esta pestaña. Estasección contendrá toda la información detalladarelacionada con el paquete completo, con algunassubrutinas, resultados de rendimiento, conclusiones,etc. El acrónimo escogido es SPAWNpor StructPAck Working Notes.“FAQs”: la pestaña de preguntas más frecuentesincluyen cuestiones generales, de instalación,cómo utilizar o programar con StructPack,cuestiones o problemas respecto a diferentes plataformaso sistemas operativos, así como asuntosvarios.“Third Party Software”: o software de terceros,conteniendo esta pestaña enlaces hacia los sitiosweb de todo el software utilizado para producirStructPack. El software está agrupado de lasiguiente manera:• Compiladores: gcc, gfortran, icc and ifort.• Software para el control de versiones:subversion.• Documentación del software generado:doxygen.• Edición de textos: vi (vim, gvim, ...)• Configuración del entorno: libtool, autoconf• Etc.“References”: en esta pestaña podemos encontrarreferencias bibliográficas utilizadas paraproducir StructPack. Se incluyen tanto el trabajoprevio propio en estos problemas algebraicoscomo otras publicaciones relacionadas.Además, se incluyen enlaces hacia otros sitiosweb con contenidos similares.“Installation”: conteniendo las tres típicas seccionesde “How to install” (“Cómo realizar lainstalación”), “Download” (“Descarga”) e “InstallationTest” (“Test de la instalación”). En lasección de “Download” cualquiera de las últimasversiones puede ser escogida y descargada. Lapestaña de “Installation Test” muestra la formade comprobar que la instalación ha sido correcta.En la sección de “How to Install” se muestran todoslos detalles sobre cómo obtener una instalacióncorrecta. Se utiliza un proceso típico de instalaciónbasado en tres pasos: $ ./configure,$ make y $ make install.En el paso de configure se chequea el sistemadonde el paquete va a ser instalado y se crean losoportunos ficheros Makefile para la construccióndel paquete. Algunas opciones, como por ejemplola ruta de instalación, compiladores y bibliotecas,etc., pueden ser especificadas en tiempode configuración si se desea modificar los valorespor defecto de la instalación. El paso Makeconsiste en la compilación y enlazado de todaslas bibliotecas y programas de StructPack. Seconstruyen tanto las versiones estáticas como lasdinámicas de las bibliotecas, a menos que se contraindiqueen el momento de la configuración.Finalmente, el paso de make install traslada elsoftware y la documentación hacia la carpetadestino deseada.Por defecto, los códigos fuente se compilan utilizandolos compiladores de GNU, aunque actualmentelos compiladores de Intel son igualmentesoportados.StructPack ha sido diseñado utilizando algoritmoseficientes que utilizan kernels computacionalesde tipo BLAS para operaciones de complejidadde orden cuadrático o lineal. Así pues, bienuna implementación genérica de BLAS (ésta esla opción por defecto), bien la biblioteca MKLde Intel, bien cualquier otro paquete compatibledebe estar de manera obligatoria previamenteinstalado. StructPack también incluye y utilizabibliotecas para el cálculo de la FFT. Labiblioteca FFT Pack [22] es parte de Struct-Pack, pero el usuario puede utilizar igualmentela solución provista por la biblioteca MKL deIntel.La figura 1 muestra parcialmente la informaciónque proporciona esta pestaña. Para una descripcióndetallada del proceso de instalación se sugiereexaminar [24].IV. Utilización de la biblioteca y de loscomandosActualmente StructPack ofrece la solución a sistemaslineales Toeplitz donde la matriz problemapuede ser simétrica tridiagonal o completamentesimétrica. El usuario tiene dos posibilidades en elmomento de utilizar el paquete para resolver esteproblema: puede implementar su propia aplicaciónutilizando los módulos de la biblioteca proporcionadospor StructPack o puede utilizar comandos disponiblesdesde la consola del sistema operativo pararesolver este problema.La manera más natural de utilizar nuestros móduloses mediante el diseño de una aplicación escritaen Fortran 90. Actualmente, el paquete proporcionalos módulos tpsysv_module (caso completamentesimétrico) y tpsytrid_module (caso tridiagonalsimétrico). Pueden ser utilizados tal y como se muestraen el siguiente ejemplo simplificado:program tpsysv_testuse tpsysv_moduleimplicit nonedouble precision, dimension(100) :: t, x, binteger :: nb = 20logical :: pivoting = .true.call random_number( t )call random_number( b )call tpsysv( t, x, b, nb, pivoting )end program tpsysv_testLa rutina tpsysv obtiene la solución x del sistemalineal Tx = b dada la primera columna (fila) t deJP2011-83

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Installation instructionsT y el vector de la parte derecha de la igualdad b.La aplicación se obtiene enlazando con la bibliotecastructpack.a proporcionada por el paquete.Para su uso en una aplicación escrita en C,el paquete proporciona el fichero de cabeceratpsysv_module.h que debe ser incluido, y el módulode Fortran 90 ctpsysv_module.F90 con el quela aplicación debe ser enlazada. Cada módulo deStructPack que resuelve un problema dado tienesu contrapartida en el módulo correspondiente cuyonombre posee como prefijo la letra c. Este módulo hacede interfaz con C para que sea posible llamar a unarutina ó módulo de Fortran 90 desde la aplicaciónescrita en C. Utiliza el módulo iso_c_binding queproporciona interoperatividad entre C y Fortran. Porejemplo, la rutina ctpsysv puede ser llamada desdecódigo fuente escrito en C manteniendo el nombre,número y tipos de argumentos de la rutina driver allamar y descrita en el módulo, como sigue:subroutine ctpsysv(n, t, x, b, nb, piv ) bind(c)integer(kind=c_int), value, intent(in) :: nreal(c_double), dimension(n), intent(in) :: treal(c_double), dimension(n), intent(out) :: xreal(c_double), dimension(n), intent(inout) :: binteger(kind=c_int), value, intent(in) :: nbinteger(kind=c_int), value, intent(in) :: piv. . .end subroutine ctpsysvEn la actualidad, el paquete proporciona dos comandosque permiten al usuario resolver cada unode los problemas abordados: tpsysv y tpsytrid. Unejemplo de llamada podría ser: tpsysv -n 100 -p.En este ejemplo, el comando resuelve el problemacon una matriz Toeplitz simétrica de orden 100 generadaaleatoriamente. El comando retorna el tiempode ejecución. La opción --help muestra las opcionesdisponibles que permiten especificar al comando, porejemplo, los datos de entrada, guardar la solución enun fichero, etc. Otra información útil que puede retornarel comando es relativa a la precisión de losresultados. Por ejemplo, la siguiente llamada:tpsysv -n 100 -p --raw-results --raw-headers \--random-seed=123retorna algunas estadísticas sobre la precisión de losresultados:# n Time (sec.) Forward error Backward error#===================================================100 0.19 1.16e-13 3.02e-16V. El futuro de StructPackUno de los objetivos de los autores de este paquetees la difusión de su existencia dentro de la comunidadcientífica, así como su mantenimiento. Enel futuro, el equipo de trabajo irá consolidando losmétodos existentes, resolviendo problemas que puedensurgir de su uso por parte de otros investigadores.Respecto a la solución de sistemas lineales,estamos actualmente trabajando en sistemas linealesHermíticos complejos no simétricos de matricesToeplitz. La base matemática, que se utiliza parala implementación eficiente de la rutina que solucionael problema simétrico en sistemas multinúcleos,puede extenderse para la solución de un amplio rangode problemas de tipo Toeplitz, como problemascon estructura Toeplitz a bloques, bloques Toeplitz,Toeplitz+Hankel, etc. Más aún, el problema linealde mínimos cuadrados con matrices de tipo Toeplitztambién se puede resolver con técnicas similares, porlo que serán parte de nuestro software. La extensióna otras clases de matrices estructuradas (no de tipoToeplitz) como Vandermonde también son parte denuestros objetivos.La solución del problema de valores y vectores propiosy del problema de valores singulares involucran-JP2011-84

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011do matrices estructuradas, también es un objetivoimportante de nuestro proyecto. Algunas propuestasestán basadas en la solución de sistemas lineales comolos mencionados anteriormente, por lo que sóloresta incorporarlos a nuestro paquete.AgradecimientosEste trabajo ha sido financiado por el Ministerioespañol de Ciencia e Innovación y por FEDER(proyectos TIN2010-14971, TIN2008-06570-C04-02,TEC2009-13741 y CAPAP-H3 TIN2010-12011-E),Universitat Politècnica de València mediante el “Programade Apoyo a la Investigación y Desarrollo(PAID-05-10)” y la Generalitat Valenciana medianteel proyecto PROMETEO/2009/013.Referencias[1] “Lapack,” http://www.netlib.org/lapack/.[2] “Scalapack,” http://www.netlib.org/scalapack/.[3] “Petsc,” http://www.mcs.anl.gov/petsc/petsc-as/.[4] “SuperLU,” http://crd.lbl.gov/~xiaoye/SuperLU/.[5] “Arpack,” http://www.caam.rice.edu/software/ARPACK/.[6] “Matlab,” http://www.mathworks.com/products/matlab/.[7] “Mathematica,” http://www.wolfram.com/mathematica/.[8] J.R. Bunch., “Stability of methods for solving Toeplitzsystems of equations,” SIAM J. on Scientific and StatisticalComputing, vol. 6, no. 2, pp. 349–364, April 1985.[9] T.Kailath and A.H.Sayed, “Displacement structure:Theory and applications,” SIAM Review, vol. 37, no.3, pp. 297–386, September 1995.[10] T.Kailath and A.H.Sayed, Eds., Fast Reliable Algorithmsfor Matrices with Structure, SIAM, Philadelphia, PA,1999.[11] Dario Bini, “Toeplitz matrices, algorithms and applications,”ERCIM News, , no. 22, July 1995.[12] V.Olshevsky, Ed., Fast Algoritmhs for Structured Matrices:Theory and Applications, SIAM, Philadelphia, 2003.[13] “Netlib,” http://www.netlib.no/netlib/toeplitz/.[14] “Slicot,” http://www.slicot.org/.[15] L. Graciá, P. Alonso, and A.M. Vidal, “Solution of symmetricToeplitz linear systems in GPUs,” in CMMSE’09International Conference on Computational and MathematicalMethods in Science and Engineering, Gijón (Asturias),España, June 2009.[16] A.M. Vidal, V.M. García, P. Alonso, and M.O. Bernabeu,“Parallel computation of the eigenvalues of symmetricToeplitz matrices through iterative methods,” Journalof Parallel and Distributed Computing, vol. 68, pp. 1113–1121, August 2008.[17] M.O. Bernabeu, P. Alonso, and A.M. Vidal, “A multilevelparallel algorithm to solve symmetric Toeplitz linearsystems,” The Journal of Supercomputing, vol. 44, pp.237–256, June 2008.[18] P. Alonso and A.M. Vidal, “Cauchy-like system solutionon multicore platforms,” in PARA 2008 9th InternationalWorkshop on State-of-the-Art in Scientific andParallel Computing, Trondheim, Noruega, May 13 2008,Proceedings of PARA 2008, NTNU.[19] P. Alonso, J.M. Badía, and A.M. Vidal, “Solving theblock-Toeplitz least squares problem in parallel,” Concurrencyand Computation: Practice and Experience, vol.17, pp. 49–67, January 2005.[20] “Blas,” http://www.netlib.org/blas/.[21] “Intel MKL,” http://software.intel.com/en-us/articles/intel-mkl/.[22] “FFTPack,” http://www.netlib.org/fftpack/.[23] “GNU gcc,” http://gcc.gnu.org/.[24] “StructPack,” http://www.inco2.upv.es/structpack.php.[25] Alonso-Jordá P., P. Martínez-Naredo, F.J. Martínez-Zaldívar, J. Ranilla, and Vidal A.M., “Building a libraryfor solving structured matrix problemas,” in Proceedingsof the International Conference CMMSE, Benidorm,Spain, June 26–29 2011.JP2011-85

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-86

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A translator framework for DynamicProgramming problemsAlejandro Acosta 1 , Francisco Almeida 2 and Ignacio Peláez 3Abstract— The advent of multicore systems, joinedto the potential acceleration of the graphics processingunits, has given us a low cost computation capabilityunprecedented. The new systems alleviatesome well known important architectural problems atthe expense of a considerable increment of the programmabilitywall. The heterogeneity, both at architecturaland programming level at the same time,raises the programming difficulties. As a contributionin this context, we propose a development methodologyfor the automatic source-to-source transformationon specific domains. This methodology is successfullyinstantiated as a framework to solve DynamicProgramming problems. As a result of applying ourframework, the end user (a physicist, a mathematicianor a biologist) can express her problem through alatex equation and automatically derive efficient parallelcodes for current homogeneous or heterogeneousarchitectures. The approach allows an easy portabilityto new potential emergent architectures.Keywords— Dynamic Programming problems,Source to source transformation.I. IntroductionCurrent generation of computers is based on architecturesbased on multiple identical processing unitscomposed of several cores (multicores) and it is expectedthat the number of cores per processor beincremented every year. It is also a well know factthat the current generation of compilers is not beingable to transfer automatically the capacity of the newprocessing units to the applications. The situationis further complicated given that current architecturesare of heterogeneous nature, where this multicoresystems can be combined, for example, withthe capabilities of using GPU system as general purposeprocessing architectures. This fact constitutesa severe difficulty that is appearing in the form of abarrier to the programmability.Many are the proposals to tackle with this problem.Leaving aside the proposals based on the developmentof new programming languages, due toinconvenience caused to the user (new learning effortand code reusability), many of the approachesare based in the source-to-source transformation ofsequential code into parallel code or in the transformationof parallel code designed for one architectureinto parallel code for a different one [1], [2],[3]. Another different approach is based in the use ofskeletons. The programmer is provided with a set ofpatterns already parallelized that constitute a frameto develop parallel code, just by supplying sequentialcode [4], [5]. It worth also to mention the reasearch1 e-mail: aacostad@ull.es.2 e-mail: falmeida@ull.es.3 e-mail: ignacio.pelaez@gmail.com.on frameworks devoted to build the former sourceto-sourcetransformers [6], [7].Although technologically impressive, none oftheprojects based in skeletal parallel programming haveachieved significant popularity in the wider parallelprogramming community. However, we claim thatmany of the developments made in the context ofskeletal programming may play an important rolein the automatic code generation based in sourceto-sourcetransformations. An important difficultyin the source-to-source transformation process is totransform sequential code sections into their parallelequivalent sections. That implies that the transformermust know in advance the sections to be parallelized,and how they should be translated, typicallythe user annotates the sections to be transformed.An interesting feature of parallel skeletons is thatthe parallelism is hidden to the end user and is encapsulatedinto parallel patterns. Usually, the user fillsgaps in the skeleton by providing sequential codes.New parallelizations (for new architectures for example)can be developed without any modificationof the sequential code supplied by the user.We have developed a source-to-source translatorbased in skeletons that generates code for many parallelarchitectures. The main goal is that the enduser may obtain parallel code, without any knowledgein programming, just by defining her problemusing a more natural language as the mathematics.An advantage of our approach is that, in general, asource-to-souce transformation from sequential codeto sequential code is semantically easier to developthat a transformation from sequential to parallelcode. That is one of the fundamentals of our project,we automatically fill the sequential gaps in a parallelskeleton starting from a very user friendly specification.The parallelism is automatically provided bythe skeleton and can be very easily extended. Sincemany parallel skeletons have been already developedand they work efficiently in current architectures,once the transformers have been developed, the levelof productivity in terms of parallel code generated ishighly increased.As a proof of concept we apply the methodologyto the dynamic programming technique. As a resultof this research it raises an specification languagefor Dynamic Programming problems that also constitutesa contribution of this work.This remaining of the paper has been structuredas follows: in section II we present the methodologythat we propose to broach the problem, in sectionIII we raise the framework developed in the contextJP2011-87

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011of Dynamic Programming problems and in sectionIV we include some computational results obtainedfrom our tool and point out the high productivityachieved by the approach while keeping the efficiencyat the same time. Finally we end the paper withsome concluding remarks and future lines of work.II. The methodologyUsually, source-to-source translators are used tomake easier the work of developers. The source languageuse to have a higher abstraction level than thetarget language. Many translator have been developedand they typically follow the common structurethat operates in two different phases, the Front-endand the Back-end. In the skeletal based translationwe propose to follow the same structure but introducingnew layers and providing an increased generalabstraction view (Figure 1). The proposal is close tothat presented in [7]. In this case, the code generatedby the Back-ends is the input code for a parallelskeleton. The input code in a parallel skeleton useto be a sequential code that is guarantied to be executedin parallel through the parallel patterns encapsulatedinto the skeleton. This patterns are adaptedto several platforms. New parallel patterns can bedeveloped for new architectures and also the skeletonsare suitable for static and dynamic optimizations.Note that we separate the source to sourcetransformation from the parallelization. The transformationsare only of sequential codes to sequentialcodes, while the parallelizations are abstracted intothe skeletons. The parallel code generated by ourBack-end is suitable to be executed in many parallelarchitectures in terms of the parallel skeleton to becombined for the execution.Using this model, we propose a design structurewhere each of the phases can be overviewed as sourceto-sourcetranslators (Figure 1). The Front-end maybe seen as a source-to-source translator that generatesan intermediate code, and the Back-end receivesas input this source intermediate code and generatethe output. By adding the skeletons the model allowsto develop a source translator, that generates intermediatecode independent from the architecture,and also a second target translator independent fromthe input intermediate language that generates anoutput code adapted and optimized for different architectures.This model is quite flexible since allows the use thesame target translator, and different source translators,to generate parallel code starting from variousinput languages. Or, at the same time, the use or thesame source translator, and different target translators,to produce output code for different skeletalsoftware platforms. The target code generated bythe target translator can be used in many differentparallel architectures just by combining the skeleton.New adapted skeletons can be developed fornew emergent architectures without any change nornew developments in the whole translation process.As a proof of concept we have implemented asource-to-source translator that follows this model(Figure 2). The translator is directed to solve DynamicProgramming problems on parallel architectures.Of course, although the specific developmentof this paper is oriented to the Dynamic Programmingtechnique, the same development model canbe applied to many other contexts.III. The dynamic programming technique: aproof of conceptDynamic Programming (DP) is an importantproblem-solving technique that has been widely usedin various fields such as control theory, operationsresearch, economy, biology and computer science [8],[9]. In DP an optimal sequence of decisions is arrivedat by making explicit appeal to the principle ofoptimality.For example [10], however most of the parallelizationspresented are for specific DP problems (see[11], [12]) or are restricted to limited classes of recurrences.A unified parallel general approach waspresented in [13] as an extension to the work of [14]but the strong theoretical effort introduced in somecases dissuades us from using it as a model for developingparallel tools.In conclusion, generic parallel approaches for DPare limited to classes of problems or they are notsuitable to be assumed by a software component. Itis worth mentioning that another source of difficultiesis the fact that the notation used changes substantiallyfrom one formalization to the other. Inmost of the cases, how to obtain the optimal policyproviding the optimal solution is left outside of theformalizations, and usually remains expressed as anon-formalized, sometimes intuitive, procedure.Analyzing the software approaches for DP, wefound a group of general libraries for combinatorialoptimization problems such as [15], [16]. They areused to supply interfaces for sequential and parallelexecutions but in most of the cases DP is not consideredat all. Next, we can find specific DP sequentiallibraries such as [17], and interesting software approachesderived from laboratories that apply solverssuch as LINGO [18] to DP problems, following particularmethodologies. In [19] we contributed withDPSKEL, a parallel skeleton where many efficientparallelizations for DP on different architectures areoffered to the end user. The end user fills gaps ona C++ sequential code and the parallelism is automaticallyprovided. In [20] we presented DPSPEC,a XML specification for DP problems that could beused as an alternative instead of the C++ interfacefor the DP parallel skeletons. Although for a scientist(a biologist, a physician, or an economist) XMLis easier to manage, it still remains as a non naturalapproach. By other side, the problem of finding theoptimal policy after the optimal value is computedremained unsolved at that moment.As a contribution of this paper, we propose a newspecification language for DP problems that integratesall the elements of the DP technique, includ-JP2011-88

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011… … ...IntermediateCodeOutputCodeInputCodeSourceTranslatorTargetTranslatorSkeletonLanguage DependentFig. 1.PlatformDependentModel for the proposed architectureArchitectureDependenting how to compute the optimal policy. DP problemsusing this specification can be transformed automaticallyinto our parallel skeletons through our intermediatelanguage DPSPEC. To achieve it, DPSPECand the parallel skeletons have been conveniently extended.The input defines a structure where the user candefine the DP problem without any knowledge ofprogramming, using a more natural language as themathematics. The code for this structure is definedusing the L A TEX processor, widely used by thescientific community. The use of LaTeX is just aproof of concept, however from the methodologicalpoint of view, any other language can be translateto the intermediate DPSPEC code, such as MatLab.We define a template where the user can define theproblem to be solved and its parameters. We illustratethis specification using the well known DP approachfor the Knapsack Problem(Table I). As wecan see the input data and solution or a problem aredescribed at the InputData and OutputData sectionsrespectively, the DP recurrence in the sectionDP Recurrence. Note that when this section is defined,the decisions d k,c are included so that the optimalpolicy can be obtained from the specificationpresented in section F ormerDecision.This L A TEX code will be transformed using thetransformer Tex2DPS to DPSPEC. These design issuesmake the subsequent parsing easier and allowfor a better semantic analysis to detect data dependencies,all while adhering as closely as possibleto the user defined equation. The semantic analysisdetermines the traversing mode of the DP table.DPSPEC brings together the elements to describepiecewise defined functions, simple variablesand vectors, arithmetic, logical, relational and maxminoperators, and iterators. DPSPEC is the inputof a second translator (XML2Cpp), which isthe responsible for translating the XML specificationto C++ code. This code supplies the structureof a state and its evaluation through the functionalequations and the DP table is abstracted as a tableof states. DPSKEL provides the table and severalmethods to traverse it during the evaluation ofthe states. These methods allow different traversingmodes (by rows, by columns, by diagonals) andthe user picks the best that doesn’t violate the dependencesof the functional equations. Some recurrencesadmit several traversing modes in terms ofdependences, but the running time may vary fromone mode to the other. In the sequential case, thetraversing mode indicates that the states of the row(column or diagonal respectively) will be processedin sequence, while in the parallel case, the semanticappeals to the evaluation of the row (column ordiagonal respectively) using the whole set of processorssimultaneously. This approach allows to introduceany of the parallelization strategies designed forDP algorithms. The dimensions of the DP table aredependent of the instance and should be given atrunning time. DPSKEL skeleton follows the modelof classes described in the Mallba library and addsthose particular elements related to DP, while keepingthe features of efficiency and easiness of use atthe same time. The concepts of State and Decisionare abstracted into C++ classes required (Requiredsections in Figure 2) to the user. The user describesthe problem and the solution, and the methods toevaluate a state (the functional equation) and to getthe optimal solution. These classes are generated bythe translator XML2Cpp. The classes provided (Providedsections in Figure 2) by DPSKEL will allocateand evaluate the DP table supplying the necessarymethods to return the solution. Implementation detailsare hidden to the user. The flexibility in our approachallows to develop new translators from XMLto another library of skeletons providing new or differentfunctionalities.Since skeletons are defined for different architectures,shared memory, message passing, hybridshared memory/message passing (see Figure 2), themethodology provides a huge portability, specially ifJP2011-89

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE ILatex specification for the Knapsack Problem⎧n ∈ N ⎪⎨C ∈ NInputData ≡p k ∈ N; k ∈ {0 . . . n − 1}⎪⎩w k ∈ N; k ∈ {0 . . . n − 1}# T he number of objects# T he capacity of the Knapsack# T he profit of object k# T he weight of object k{xk ∈ {0, 1}; k ∈ {0 · · · n − 1} # T he solution vectorOutputData ≡n − 1, C# T he index solutionDecisionDef ≡ { d k,c ∈ {0, 1}; k ∈ {0 · · · n − 1}; c ∈ {0 · · · C}# T he decisionsDP Recurrence ⎧ ≡⎨ 0 ⇒ d k,c = 0 if c < w kf k,c = p k ⇒ d k,c = 1 if k = 0 and c ≥ w k⎩max{f k−1,c ⇒ d k,c = 0, f k−1,c−wk + p k ⇒ d k,c = 1} if k ≠ 0 and c ≥ w k⎧# Assign solution k⎪⎨xF ormerDecision ≡ k = d k,c if k ≥ 0 and c ≥ 0# Next decision to assign⎪⎩k − 1; c − (w k ∗ x k ); if k > 0 and c ≥ (w k ∗ x k )SeqOpenMPLatexInputCodeTex2DPSSourceTranslatorXMLIntermediateCodeXml2CppTargetTranslatorOpenCL...MPIHybridRequired ProvidedSkeletonOutputCodeLanguage Dependent Platform Dependent Architecture DependentFig. 2.The proposed software architectureone consider that extending the approach to a newemergent platform, just means to include a new parallelskeleton.IV. Computational ResultsTo validate our methodology and the frameworkthat we have developed, we tested with several DynamicProgramming problems (Table II). Five differentDP recurrences have been considered that arequite representative of wide class of problems. Notethat the data dependences are different in most of theformula considered. That means that different paralleltraverses of the DP table can be required. We justrepresented the DP problems using our L A TEX specificationlanguage and automatically generated theparallel codes. Four parallel skeletons have been considered,the sequential one and parallel versions onOpenMP, MPI and MPI/ULL CALIBRATE. Thislast version is a distributed memory MPI versioncombined with the ULL CALIBRATE library [21]to optimize in run time through dynamic load balancing.The parallel platform used to execute our experimentsis an AMD Opteron 6128 node (4 processors,each processor composed of 8 cores), with 32 coressharing the memory. We have used only 20 of them inour tests. To simplify the experience, the tests havebeen developed using squared matrices of sizes 1000,2000 and 5000. Note that according to the dependencesof problems on Table II, that are graphicallyrepresented in Figure IV, several traversing parallelapproaches can be used to obtain the solution. Theparallel skeletons used compute rows in parallel inthe case of the RAP and KP, the MPP and TCPare processed by computing the diagonals down-topin parallel and in the case of GCP the diagonals arecomputed in parallel top-down.Table III shows the running times of the sequentialexecutions for all the proposed problems. This tableprovides a general view on the granularity of eachJP2011-90

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIDynamic Programming test problemsProblemRecurrence0/1 KnapsackKP f i,j = max{f i−1,j , f i−1,j−wi + p i }Resource Allocation f i,j = p 1,j if i = 1 and j > 0RAP f i,j = max 0≤k 1) and (j > 0)Matrix ParentizationMPP f i,j = min i≤k

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IVRunning times of the RAP for several SkeletonsSkeleton OpenMP MPI MPI+ULL CALIBRATESize# cores # cores # cores2 4 8 16 20 2 4 8 16 20 2 4 8 16 201000 15 9 4 2.4 2 14 9 4 2.4 2 11 5 3 1.7 1.52000 126 73 39 20 16 119 70 37 19 16 81 44 23 12 105000 1993 1153 616 311 257 1882 1093 591 311 255 1304 700 399 180 141TABLE VRunning times for MPP, TCP, KP and GCPProblem MPP TCPSize# cores # cores2 4 8 16 20 2 4 8 16 201000 17 8 3.9 1.9 1.6 18 9 3.7 1.9 1.52000 146 73 41 22 21 143 72 36 22 205000 2659 1358 669 349 386 2596 1344 669 349 373Problem KP GCPSize# cores # cores2 4 8 16 20 2 4 8 16 201000 0.22 0.11 0.06 0.08 0.07 57 32 17 7.3 7.52000 0.86 0.44 0.23 0.24 0.24 480 271 193 74 695000 5.7 2.7 1.4 1.3 1.1 8772 4858 2559 1309 1517References[1] Isaac Dooley, “Automated source-to-source translationsto assist parallel programmers,” M.S. thesis,Dept. of Computer Science, University of Illinois, 2006,http://charm.cs.uiuc.edu/papers/DooleyMSThesis06.shtml.[2] Sain zee Ueng, Melvin Lathara, Sara S. Baghsorkhi, andWen mei W. Hwu, “W.m.w.: Cuda-lite: Reducing gpuprogramming complexity,” in In: LCPC08. Volume 5335of LNCS. 2008, pp. 1–15, Springer.[3] Fred V. Lionetti, Andrew D. McCulloch, and Scott B.Baden, “Source-to-source optimization of cuda c for gpuaccelerated cardiac cell modeling,” in Proceedings of the16th international Euro-Par conference on Parallel processing:Part I, Berlin, Heidelberg, 2010, EuroPar’10,pp. 38–49, Springer-Verlag.[4] Kiminori Matsuzaki and Hideya Iwasaki, “A library ofconstructive skeletons for sequential style of parallel programming,”in In InfoScale 06: Proceedings of the 1st internationalconference on Scalable information systems,volume 152 of ACM International Conference ProceedingSeries. 2006, p. 13, ACM Press.[5] Horacio González-Vélez and Mario Leyton, “A survey ofalgorithmic skeleton frameworks: high-level structuredparallel programming enablers,” Softw. Pract. Exper.,vol. 40, pp. 1135–1160, November 2010.[6] ROSE, “www.rosecompiler.org,” .[7] Siegfried Benkner, Eduard Mehofer, and Sabri Pllana,“Towards an intelligent environment for programmingmulti-core computing systems,” in Proceedings of the2nd Workshop on Highly Parallel Processing on a Chip(HPPC 2008), in conjunction with Euro-Par 2008, August2008.[8] Juliana Nascimento and Warren Powell, “Dynamic programmingmodels and algorithms for the mutual fundcash balance problem,” Manage. Sci., vol. 56, pp. 801–815, May 2010.[9] Alexander Erdelyi and Huseyin Topaloglu, “A dynamicprogramming decomposition method for making overbookingdecisions over an airline network,” INFORMSJ. on Computing, vol. 22, pp. 443–456, July 2010.[10] O. de Moor, “Dynamic programming as a software component,”in Proc. 3rd WSEAS Int. Conf. Circuits, Systems,Communications and Computers, N. Mastorakis,Ed., 1999.JP2011-92[11] R. Andonov, S. Balev, S. Rajopadhye, and N. Yanev,“Otimal semi-oblique tiling and its application to sequencecomparison,” in 13th ACM Symposium on ParallelAlgorithms and Architectures (SPAA), 2001.[12] R. Andonov and S. Rajopadhye, “Optimal OrthogonalTiling of 2-D Iterations,” Journal of Parallel andDistributed Computing, vol. 45, pp. 159–165, September1997.[13] Morales D., ALmeida F., Rodríguez C., Roda J., andDelgado A. Coloma I., “Parallel dynamic programmingand automata theory,” Parallel Computing, 2000.[14] T. Ibaraki, Enumerative Approaches to CombinatorialOptimization, Part II, Annals of Operations Research.Volume 11, 1-4, 1988.[15] J. Eckstein, C. A. Phillips, and W. E. Hart, “PICO:An object-oriented framework for parallel branch andbound,” Tech. Rep., RUTCOR, 2000.[16] B. Le Cun, “Bob++ library illustrated by VRP,” in EuropeanOperational Research Conference (EURO’2001),Rotterdam, 2001, p. 157.[17] B. C. Lubow, “SDP: Generalized software for solvingstochastic dynamic optimization problems.,” Wildlife SocietyBulletin, vol. 23, pp. 738–742, September 1997.[18] P. Lohmander, “Deterministic andstochastic dynamic programming.,”www.sekon.slu.se/ PLO/diskreto/dynp.htm.[19] I. Peláez, F. Almeida, and F. Suárez, “Dpskel: A skeletonbased tool for parallel dynamic programming,” inSeventh International Conference on Parallel Processingand Applied Mathematics, PPAM2007, 2007.[20] Ignacio Peláez, Francisco Almeida, and Daniel González,“An xml specification for automatic parallel dynamicprogramming,” in International Conference on ComputationalScience (1), 2006, pp. 872–875.[21] I. Galindo, F. Almeida, V. Blanco, and J.M. Badía, “Dynamicload balancing on dedicated heterogeneous systems,”in Recent Advances in Parallel Virtual Machineand Message Passing Interface. EuroPVM/MPI 2009,Alexey Lastovetsky, Tahar Kechadi, and Jack Dongarra,Eds., Dublin, Ireland, Sept. 2008, vol. 5205 of LectureNotes in Computer Science, pp. 64–74, Springer Verlag.

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Aplicaciones de la computación de altas prestacionesJP2011-93

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-94

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Resolviendo el Diseño de Redes para Modelosde Tráfico Reales de Internet MedianteOptimización Multiobjetivo enMultiprocesadoresJosé M. Lanza-Gutiérrez 1 , Juan A. Gómez-Pulido 1 , Miguel A. Vega-Rodríguez,Juan M. Sánchez-Pérez 1Resumen—El diseño y optimización de una red decomunicaciones es una tarea compleja que involucra unagran cantidad de factores que son necesarios evaluar,habiéndose demostrado que es un problema NP-complejo.En este artículo se propone su resolución utilizando dosalgoritmos evolutivos: NSGA-II y SPEA-II y enfocando eltrabajo hacia un problema de optimización bi-objetivo(coste, retardo) ejecutado sobre datos reales. Laexperimentación se ha realizado sobre un clúster deprocesadores paralelos utilizando MPI como herramientade comunicación, con el objetivo de aumentar la velocidadde ejecución de las pruebas. Con los datos obtenidos se hapodido determinar, mediante test estadísticos, cómo elalgoritmo SPEA-II ofrece un comportamiento superior alNSGA-II para este determinado problema.Palabras clave—Redes de comunicaciones, optimizaciónmultiobjetivo, algoritmos evolutivos, multiprocesadores.EI. INTRODUCCIÓNL diseño y optimización de una red decomunicaciones es una tarea compleja, puesinvolucra una gran cantidad de factores que sonnecesarios evaluar para obtener una solución queconvenza tanto a usuarios finales (calidad de servicio dela red), como a las entidades que llevan a cabo suimplantación (costes de despliegue / mantenimiento) [1].Entre los factores de optimización más habituales suelentomarse aquellos que afecten al coste y a la calidad de lared (retardo, confiabilidad, disponibilidad…). Ambosfactores influyen entre sí, puesto que la variación encualquiera de ellos hace que el otro se vea afectado. Porejemplo, para reducir el retardo de una red es posibleaumentar la capacidad de algunos de sus enlaces; sinembargo, esto produciría un aumento en el coste total dela red. Por este motivo se hace necesario recorrer todo elespacio posible de soluciones en busca de la soluciónóptima. Al ser un problema de diseño NP-complejo, lasbúsquedas exhaustivas son descartadas, siendo necesarioutilizar otras técnicas que faciliten su resolución [2].Desde que este problema fue definido como unproblema NP-complejo, se han publicado muchostrabajos que tratan de solucionarlo. Comenzando por lasheurísticas, podemos citar los trabajos de Jan et al. [3]1 Dep. Tecnología de Computadores y Comunicaciones. EscuelaPolitécnica. Campus Universitario s/n, 10003 Cáceres.{jmlanza,jangomez, mavega,sanperez}@unex.es(desarrollaron una técnica basada en “branch andbound” para optimizar el coste de la red sobre unosvalores de confiabilidad concretos) y de Ersoy et al. [4](usaron una técnica de optimización sobre el retardomedio para el diseño de redes LAN y MANinterconectadas). Sin embargo, todas estas heurísticas noaseguran que las soluciones obtenidas sean las óptimas;además, la mayoría de ellas optimizan únicamente unobjetivo, por lo que se debe partir el problema en dos.Además de las heurísticas, otros muchos trabajos usanalgoritmos genéticos para optimización mono-objetivo.Así, Abuali et al. [5] minimizan el coste de la red a lavez que consideran los valores máximos de capacidad;Ko et al. [6] optimizan el coste de la red a la vez quemantienen valores constantes de retardo; y Kumar et al.[7] usan estos algoritmos para la expansión de redes decomputadores a la vez que optimizan su disponibilidad.También han sido utilizados los algoritmos genéticosmulti-objetivo, puesto que son los que mejor se adaptana este tipo de problemáticas [8]. Así, Barnerjee et al. [9]estudiaron el diseño de redes basadas en modelos detrafico habituales (self-similiar y Poisson), mediante laoptimización de coste y retardo utilizando el PCGA(Pareto Converging Genetic Algorithm), y R. Kumar etal. [10] trataron la optimización sobre el coste y elretardo usando este mismo algoritmo.Pese a ser la solución más utilizada, existe una grancantidad de algoritmos evolutivos multiobjetivo que aúnno se han usado para solucionar el problema, como porejemplo los conocidos NSGA2 [11] y SPEA2 [12]. Espor ello por lo que se utilizarán para resolver esteproblema de optimización bi-objetivo (coste y retardo).Aunque pudiera parecer extraño (debido al elevadonúmero de publicaciones en este problema),prácticamente no existen instancias públicas (datos quedefinan el problema) que se puedan utilizar a la hora devalidar los resultados, exceptuando una bien conocida:la de las diez ciudades chinas más pobladas [6], siendoésta la instancia utilizada en nuestro trabajo.El resto del artículo se estructura como sigue: la segundasección define el problema y las funciones de fitnessutilizadas. La tercera sección muestra la implementacióndel problema mediante los dos algoritmos mencionados.La cuarta sección expone los resultados obtenidos. En laquinta sección se discute la comparativa con otrostrabajos y, finalmente, en la quinta sección se detallanlas conclusiones y trabajos futuros.JP2011-95

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011II. DISEÑO DE UNA RED DE COMUNICACIONESA la hora de diseñar una red de comunicaciones, existeuna serie de factores que hay que evaluar para obteneruna red adecuada a cada necesidad, como por ejemplo:coste de la red, retardo de las comunicaciones, volumende tráfico, posibilidades de expansión, seguridad, etc.[1]. En este artículo se propone la optimización de la redbasada en los dos factores más importantes: el coste deinstalación (no del mantenimiento) de la red y el retardode las comunicaciones.A. Definición de una instancia del problemaUna instancia particular del problema vendrá definidapor el número de nodos de la red (N), la distancia entrelos nodos (D, una matriz de NxN elementos), el traficoestimado entre los nodos (T, una matriz de NxNelementos), el número de tipos de nodos disponibles (K,con sus características de coste y capacidad), el númerode tipos de enlaces existentes (M, con sus respectivosvalores de coste y capacidad), el coste de losamplificadores de señal (A) y la máxima distancia que laseñal puede viajar a través de la red sin necesidad deamplificación (L). Estos dos últimos parámetros (A y L)son debidos a que se trata de una red de fibra óptica.B. Política de enrutamientoLa matriz de tráfico (T) proporciona la cantidad detráfico estimado entre cada una de las ciudades de lainstancia, considerando que existe una topologíacompletamente conexa.En el caso real, una topología está compuesta por unsubconjunto de todos los posibles enlaces de la red, porlo que se hace necesario redefinir esta matriz de tráficoinicial con las nuevas necesidades surgidas al encaminarla información a través de los enlaces existentes. Estanueva matriz se denomina T_acu. Para esta tarea seutiliza el algoritmo de camino mínimo de Dijsktra [14].La métrica utilizada es la longitud del enlace.C. Funciones objetivoEl coste de despliege de la red y 1 es definido mediante elcoste de los nodos, el coste de los amplificadores deseñal y el coste de los enlaces.El retardo y 2 se establece en base al modelo de tráficoutilizado; en este caso se ha decidido utilizar Poisson, unmodelo para redes convencionales. De este modo, elretardo se mide en base al tamaño de las colas de tráficogenerado en los nodos intermedios de la red [13], puestoque se considera que el retardo generado por los enlacesen la transmisión tiene un valor despreciable. Nótese quecon Co NEi se quiere hacer referencia al coste de undeterminado nodo llamado i, con Co Linki,j al coste de elenlace entre los nodos i y j, y con Cp Linki,j a la capacidadde el enlace entre los nodos i y j.Dijy Co(NECo )1Link A1ij ii j i j L T _ acuij T_ acuiji j CpLinkijy2CpLinkijAmbas funciones objetivo han sido utilizadas en otraspublicaciones [9] [10].ijD. LimitacionesPara que una determinada topología-solución pueda serconsiderada válida debe cumplir una serie derestricciones:• El flujo que atraviesa un enlace no puede sersuperior a la capacidad de dicho enlace. Paraello es necesario tener en cuenta todo el tráficoque atravesará dicho enlace debido al resto denodos de la red.• La red obtenida debe ser confiable. Por ello esnecesario que al menos sea bi-conexa, es decir,que todos los nodos deben ser accesiblesmediante dos rutas alternativas.III. IMPLEMENTACIÓNA. Codificación utilizadaComo es habitual en los algoritmos genéticos, cadaindividuo se definido mediante un cromosoma. Cadaindividuo representa una determinada topología. Elcromosoma, de longitud fija, se divide en dos partes, taly como puede observarse en la figura 1:• La primera parte es la responsable de definir eltipo de cada uno de los nodos de la red (verapartado II-A).• La segunda representa los enlaces existentesentre los nodos, donde uno indica la existenciade un enlace y cero lo opuesto. A la hora derepresentar la topología se ha considerado quelas comunicaciones son bidireccionales, por loque la matriz de adyacencia que define la red essimétrica, permitiendo reducir la cantidad debits a almacenar de NxX a N(N-1)/2.En total se necesitan Nlog 2 K+N(N-1)/2 bits paraalmacenar un individuo.Fig. 1. Cromosoma de longitud fija que representa a los individuos delproblema.B. Población inicialLa población inicial es generada mediante una mezclade procesos aleatorios y deterministas. En primer lugar,se asignan de forma aleatoria el tipo a cada uno de losnodos. A continuación, se obtiene el árbol mínimo dedistancias entre todos los nodos, utilizando el algoritmode Prim [14]. Finalmente se añaden de forma aleatorianuevos enlaces al árbol generado.Una vez generado, el individuo se evalúa paracomprobar si es una topología válida; en caso afirmativose inserta, en caso negativo se descartaría y se volvería arepetir el proceso. Además, se verifica que el individuoJP2011-96

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011no se encuentre duplicado. Estas comprobaciones serealizan con el objetivo de aumentar la velocidad deconvergencia de los algoritmos.C. Evaluación de los individuosCada individuo de la población es sometido a un procesode evaluación en el que, además de determinar el valorde las correspondientes funciones objetivo, se evalúa siel individuo cumple con las limitaciones (Apartado II-Dde este artículo) impuestas al problema.Para ello, primero se comprueba la biconexidad de lared, para que cada nodo sea accesible desde dos rutasalternativas. A continuación se calcula la nueva matrizde tráfico estimado mediante la política de enrutamientoya expuesta (Apartado II-B). Se comprueba que los tiposde nodos asignados a la topología (primera parte delcromosoma) existan y no sean producto de unamodificación producida por una mutación.A continuación se calcula el coste y retardo de la red.Para ello hay que tener en cuenta que la capacidad de undeterminado enlace es la de la menor capacidad de losnodos que une. De este modo, si la capacidad es inferiora la requerida por la matriz de tráfico estimado (T_acu)la solución será inválida. Con esta capacidad seselecciona como enlace el que sea inmediatamentesuperior a este valor; en caso de que no exista, lasolución será considerada una vez más inválida.A las soluciones consideradas inválidas se les asignanvalores infinitos, tanto al coste como al retardo, por loque serán desechadas en iteraciones sucesivas.D. CruceLa recombinación de dos individuos permite laformación de nuevos individuos partiendo del materialgenético de estos progenitores.Puesto que los cromosomas están compuestos por dospartes bien diferenciadas, se ha decidido realizar larecombinación atendiendo a estos criterios:• Cruce en la primera parte. El punto de crucepodría seleccionarse de forma completamentealeatoria, pero entonces se produciría un grannúmero de individuos con tipos de nodosinexistentes que posteriormente seríandescartados. Por ello se ha decidido situar elpunto de corte de forma que no se modifique lacodificación de los individuos. De este modo,la recombinación de dos individuos dará lugar aun tercer individuo en el que los tipos de nodosposibles serán únicamente los de sus padres.• Cruce en la segunda parte: El punto de cruce sesitúa de forma completamente aleatoria.E. MutaciónLa mutación permite facilitar una amplia exploración delespacio de soluciones, evitando que los algoritmosentren en mínimos locales.Al igual que en el cruce, la mutación se realizaatendiendo a la división del cromosoma, realizando unnúmero aleatorio de mutaciones que va desde cero hastael número de bits totales del cromosoma.• Mutación en la primera parte: Si la mutación serealiza sobre la primera parte del cromosoma,no se muta un único bit, puesto que podría darlugar a individuos con tipos de nodosinexistentes que serían descartados. Por ello seha decidido mutar el tipo de nodo porcompleto, generando un número aleatorio entretodos los tipos de nodos existentes.• Mutación en la segunda parte: La mutación escompletamente aleatoria.F. Algoritmos utilizadosPara la resolución del problema aquí propuesto se hanimplementado dos algoritmos evolutivos bienconocidos: NSGA-II y SPEA-II.El algoritmo NSGA-II (Non-dominated Sorting GeneticAlgorithm) se basa en la clasificación de individuos envarias capas o frentes. La clasificación consiste enagrupar a todos los individuos no dominados en unfrente, con un valor de fitness (o adaptabilidad) igualpara todos los individuos. Este valor es proporcional altamaño de la población, para así proporcionar unpotencial reproductivo igual para todos los individuos deeste frente. De esta forma el grupo de individuosclasificados es ignorado y otro frente de individuos nodominados es considerado. El proceso continúa hastaque se clasifican todos los individuos en la población.Esta definición es similar a la del algoritmo NSGA,puesto que el NSGA-II no es más que una evolución delprimero, siendo computacionalmente más eficiente yutilizando un mecanismo elitista consistente enseleccionar los mejores individuos de la unión de laspoblaciones de padre e hijo. El pseudocódigo es elmostrado en la figura 2; para más detalles consultar lareferencia [11].Algoritmo 1 Pseudocódigo NSGA-II1: Inicializar población, P2: Ordenar P, considerando dominancia3: Evaluar individuos de P.4: Aplicar operadores genéticos a P, para tener Q5: para i=0 a MAX_GENERACIONES hacer6: R = P U Q7: Ordenar R, considerando dominancia y obtener frentes, F I8: I = 19: mientras |P i+1 | < N entonces //N, número de individuos en P10: Calcular adaptabilidad de cada individuo en F I11: P t+1 = P t+1 U F I12: I = I + 113: fin mientras14: Ordenar P i+1 , considerando dominancia15: Elegir los primeros N elementos de P i+116: Aplicar operadores genéticos a P i+1 , para tener Q i+117: fin paraEl algoritmo SPEA-II (Strength Pareto EvolutionaryAlgorithm) se caracteriza por la utilización de unamemoria externa (un fichero de texto), a diferencia delanterior, que contiene las soluciones no dominadasencontradas (población externa de no dominados P nd ).En cada generación, se copian los individuos nodominados de P en P nd y se borra de éste las solucionesdominadas. Para cada individuo en el sistema externo, secomputa su valor de fitness mediante una estrategia deasignación fina: considera, para cada individuo, elnúmero de individuos que lo dominan y el número deindividuos por los cuales es dominado. Otra aspectorelevante del algoritmo es la utilización de la técnica del“vecino más cercano” para valorar la densidad,dirigiendo la búsqueda de forma más eficiente. En elJP2011-97

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011algoritmo 2 puede verse el pseudocódigo del SPEA-II;para más detalles consultar la referencia [12].Algoritmo 2 Pseudocódigo SPEA-II1: Inicializar población, P2: para i=0 a MAX_GENERACIONES hacer3: Evaluar individuos de P4: Marcar soluciones no dominadas de P5: Actualizar el conjunto de soluciones no dominadas: P N6: Calcular la adaptabilidad de los individuos de P y P N7: Seleccionar individuos del conjunto P V P N8: Aplicar los operadores de cruzamiento y mutación9: fin paraIV. RESULTADOSEn este artículo se ha resuelto el problema decomunicación entre las diez ciudades chinas máspobladas [6], mediante la utilización de dos algoritmosevolutivos: NSGA-II y SPEA-II.Todos los experimentos han sido realizadas en un clústerde procesadores paralelos compuesto por 5 nodos, cadauno de ellos con cuatro procesadores Intel® Xeon a3.0Ghz y 1 de GB memoria RAM. Para aprovechar estacapacidad de procesamiento se ha desarrollado unsistema paralelo basado en MPI [22] que permite laejecución de múltiples instancias del problemasimultáneamente. De esta forma, si se desea llevar acabo 20 ejecuciones de una misma configuración, selanzan 4 ejecuciones en cada nodo (una por procesador)recogiendo los resultados de cada una a su finalización.Con esta sencilla operación se consigue reducir eltiempo de ejecución casi 20 veces, puesto que el tiempode CPU de una ejecución es muy elevado encomparación con el tiempo de comunicación necesario.A la hora de realizar la experimentación se ha utilizadouna sencilla estrategia: en primer lugar, se handeterminado las configuraciones con las que se obtienenlos mejores resultados para cada algoritmo. Una vezobtenidos, se trata de estudiar estadísticamente si algunode los dos ofrece un comportamiento superior al otro.Como se ha dicho, el primer paso de la experimentaciónconsiste en ajustar los parámetros más habituales paradeterminar con qué configuración se obtienen losmejores resultados. Estos parámetros son: número degeneraciones, tamaño de la población, probabilidad decruce y probabilidad de mutación. Esta metodología essimilar a la de A. Rubio-Largo et al. [15], en la que,partiendo de una configuración por defecto, se vanfijando los valores de los parámetros uno a uno en suvalor óptimo, hasta que se han ajustado todos.A la hora de establecer el grado de bondad que tienenlos frentes obtenidos para cada configuración, esnecesario utilizar algún tipo de medida. En este caso, seha decidido utilizar una medida habitual como es elhipervolumen [16]: a mayor valor, mejor es la solución.Para cada configuración probada se han realizado untotal de veinte repeticiones con el fin de dar validezestadística, obteniendo para cada una de ellas undeterminado frente y por consiguiente un hipervolumen.El valor del campo hipervolumen en las tablas I-II-III-IV no es más que el valor promedio de todos estoshipervolúmenes para una determinada configuración.A la hora de calcular un hipervolumen es necesariodefinir los puntos de referencia máximo y mínimo [16].De forma experimental, se determinó que es suficientecon los puntos {1.000.000, 0.9} como máximo y {0, 0}como mínimo, para las tuplas {coste, retardo}, pues asíse envuelven todos los frentes obtenidos.El procedimiento de ajuste es como sigue:• En primer lugar, se trata de obtener el númerode generaciones idóneo, partiendo de unosvalores por defecto de: población igual a 100,probabilidad de cruce del 50% y de mutacióndel 50%. Este parámetro debe ser el primero enser ajustado, pues tiene una influencia clara enel tiempo de ejecución. En la tabla I puedeobservarse cómo con un valor de 800 es másque suficiente, pues su aumento no supondríauna clara mejoría del hipervolumen obtenido ysí del tiempo de ejecución del experimento. Portanto, se busca balancear el tiempo de ejecucióny la calidad de los resultados.• Una vez ajustado el número de generaciones, elsiguiente parámetro a ajustar es el tamaño de lapoblación (ver tabla II). Este parámetro es elúltimo de los ajustados que incide en el tiempode ejecución. Como puede observarse, paraambos se obtiene el mejor comportamiento conun total de 250 individuos.• A continuación se ajusta la probabilidad decruce, que determinará la probabilidad con laque los individuos serán cruzados. Los mejoresvalores para el NSGA-II y el SPEA-II seobtienen con una probabilidad del 80% y del60% respectivamente (ver tabla III).• Finalmente, se ajusta la probabilidad demutación, que determina la probabilidad con laque los nuevos individuos recibirán mutacionesen sus cromosomas. Ambos algoritmosobtienen sus mejores resultados con un valordel 50% (ver tabla IV).Mediante el procedimiento descrito se han podidodeterminar las configuraciones óptimas para cada uno delos algoritmos (tabla V).Se podría haber incorporado una figura ilustrativa sobrelos frentes de Pareto obtenidos para ambasconfiguraciones, pero la cercanía de ambos frentesrequiere una gran resolución para una visualizaciónaceptable y el tamaño de este documento lo impide.A partir de estas dos configuraciones obtenidas, elsiguiente paso es determinar si, como parece ser, elalgoritmo SPEA-II obtiene mejores resultados que elNSGA-II. Para ello es necesario realizar un estudioestadístico que compruebe si la mejoría lograda por elSPEA-II es significativa.El modo de proceder a la hora de realizar el estudioestadístico es el mostrado en la figura 3 [17]. Para ello,el primer paso consiste en determinar si los datosprocedentes de las treinta ejecuciones, para ambasconfiguraciones, siguen una distribución normal. Paraello utilizamos los test de Shapiro-Wilk [18] yKolmogorov-Smirnov-Lilliefors(K-S) [19]. En ambostest se contrastan las siguientes hipótesis:H 0 : El modelo subyacente a los datos es normal.H 1 : El modelo subyacente a los datos no es normal.JP2011-98

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IAJUSTE DE PARÁMETROS PARA LA OBTENCIÓN DEL NÚMERO DEGENERACIONES IDÓNEOHipervolumen Generaciones Población Prob. Prob.NSGA SPEACruce MutacionII II0.94176 0.93698 100 100 0.5 0.50.94542 0.94674 200 100 0.5 0.50.95160 0.95382 300 100 0.5 0.50.95737 0.95403 400 100 0.5 0.50.95757 0.95493 600 100 0.5 0.50.95753 0.95965 700 100 0.5 0.50.95853 0.96005 800 100 0.5 0.50.95871 0.96028 900 100 0.5 0.50.95871 0.96028 1000 100 0.5 0.5Fig. 3. Modo de proceder a la hora de seleccionar el test estadísticoadecuado a la naturaleza de las muestras.TABLA IIAJUSTE DE PARÁMETROS PARA LA OBTENCIÓN DEL TAMAÑO DE LAPOBLACIÓN IDÓNEOHipervolumen Generaciones Población Prob. Prob.NSGA SPEACruce MutaciónII II0.94728 0.96114 800 50 0.5 0.50.95853 0.96005 800 100 0.5 0.50.96408 0.96067 800 150 0.5 0.50.96081 0.95914 800 200 0.5 0.50.97345 0.97443 800 250 0.5 0.50.96692 0.96822 800 300 0.5 0.50.97047 0.97217 800 350 0.5 0.5TABLA IIIAJUSTE DE PARÁMETROS PARA LA OBTENCIÓN DE LA PROBABILIDADDE CRUCE IDÓNEAHipervolumen Generaciones Población Prob. Prob.NSGA SPEACruce MutaciónII II0.97169 0.97299 800 250 0.01 0.50.97506 0.96807 800 250 0.1 0.50.96985 0.97323 800 250 0.2 0.50.97362 0.96402 800 250 0.3 0.50.97410 0.96645 800 250 0.4 0.50.97345 0.97443 800 250 0.5 0.50.97363 0.97594 800 250 0.6 0.50.97213 0.97434 800 250 0.7 0.50.97516 0.97289 800 250 0.8 0.50.96762 0.96517 800 250 0.9 0.5TABLA IVAJUSTE DE PARÁMETROS PARA LA OBTENCIÓN DE LA PROBABILIDADDE MUTACIÓN IDÓNEAHipervolumen Generacio Población Prob. Prob.NSGA SPEA nesCruce MutaciónII IINSGA-II/ SPEA-II0.96722 0.96802 800 250 0.8 /0.6 0.010.96367 0.96447 800 250 0.8 /0.6 0.030.95990 0.96909 800 250 0.8 /0.6 0.060.96753 0.96593 800 250 0.8 /0.6 0.080.96684 0.97065 800 250 0.8 /0.6 0.10.97060 0.96892 800 250 0.8 /0.6 0.20.96281 0.97299 800 250 0.8 /0.6 0.30.97230 0.96555 800 250 0.8 /0.6 0.40.97516 0.97594 800 250 0.8 /0.6 0.50.97196 0.97027 800 250 0.8 /0.6 0.60.97133 0.97380 800 250 0.8 /0.6 0.70.96669 0.97115 800 250 0.8 /0.6 0.80.97095 0.97513 800 250 0.8 /0.6 0.9TABLA VCONFIGURACIONES IDÓNEAS OBTENIDAS PARA CADA UNO DE LOSALGORITMOSAlgoritmos Generaciones Población Prob. Prob. MutaciónCruceNSGA-II 800 250 0.8 0.5SPEA-II 800 250 0.6 0.5Fig. 4. Gráfico de cajas procedentes del estudio estadístico de lasmuestras procedentes de los algoritmos NSGA-II y SPEA-II.Para ambas pruebas se obtiene un valor-p inferior a 0.05,por lo que hay una fuerte evidencia en contra de lahipótesis nula. Por ello, no podemos asumir que losdatos procedan de un modelo normal.Si se observa el gráfico de cajas expuesto en la figura 4,puede comprobarse cómo existen diferencias entre lasmedianas (marcadas en negro) de ambos algoritmos,siendo superior el SPEA-II al NSGA-II. Pero, ¿es estadiferencia significativa? Para comprobarlo, y dado queno se puede asumir una distribución normal en ningúncaso, como se ha comprobado anteriormente, se utilizaráuna prueba no paramétrica. En este caso se aplica el Testde Wilcoxon [20] puesto que se dispone de dos muestrasrelacionadas (figura 3), en el que se contrastan lassiguientes hipótesis:H 0 : Las dos muestras proceden de poblaciones con lamisma distribución (igual mediana).H 1 : Las dos muestras proceden de poblaciones dedistribuciones diferentes en la tendencia central(diferente mediana).El resultado del Test es un valor-p de 0.001, inferior a0.05, por lo que hay una fuerte evidencia en los datos encontra de la hipótesis nula. Es decir, las dos muestras noproceden de poblaciones con igual mediana, o lo que eslo mismo, existen diferencias significativas entre las dosmuestras.Concluido lo anterior, se hace necesaria la utilización deun test unilateral, que permita concluir cuál de los dosalgoritmos tiene un mejor comportamiento. Para ello seintentará demostrar si el algoritmo NSGA-II es superioral SPEA-II, contrastando las siguientes hipótesis:H 0 : Las muestras procedentes del algoritmo NSGA-II tienen una media superior o igual a la delalgoritmo SPEA-II.JP2011-99

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011H 1 : Las muestras procedentes del algoritmo NSGA-II tienen una media inferior a la del SPEA-II.El resultado del Test es un valor-p de 0.001; al sermenor que 0.05 hay evidencias para rechazar la hipótesisnula. Es decir, se puede concluir con relevanciaestadística que el algoritmo NSGA-II tiene uncomportamiento inferior, en media, al SPEA-II, o lo quees lo mismo, el SPEA-II produce los mejores resultados.V. COMPARATIVAS CON OTROS AUTORESComo ya se ha comentado en la primera sección, elnúmero de instancias públicas para este problema es casiinexistente; tan solo existe una que se encuentre biendescrita, por lo que ha sido la utilizada en este trabajo.La escasez de instancias reales supone un problema a lahora de poder validar nuestras metodologías al compararlos resultados obtenidos con los de otros autores.Además, hay algunos autores que utilizan otrasinstancias no documentadas o bien topologías generadasaleatoriamente. No obstante existen otros trabajos queutilizan la misma instancia que la que hemos adoptado.Así, Ko et al. [6] proporcionan un único valor del par{coste, retardo} como resultado, (obteniéndose mejoresresultados en este artículo). Barnerjee et al [9] y R.Kumar et al [10] ofrecen como resultados unos frentesde Pareto sin especificar ningún tipo de medida decalidad, como el hipervolumen utilizado en por nosotros.VI. CONCLUSIONES Y TRABAJO FUTUROEn este artículo se ha resuelto el problema del diseño deredes para modelos de tráfico de Internet entre las diezciudades chinas más pobladas, utilizando dos conocidosalgoritmos evolutivos: el NSGA-II y el SPEA-II. A suvez, se ha realizado un completo estudio estadístico queha permitido determinar la superioridad del algoritmoSPEA-II sobre el NSGA-II, para esta definición delproblema e instancia concreta. Además, se ha utilizadoeficientemente una estrategia paralela basada en MPI,que permite acelerar la ejecución de las pruebas.Como trabajo futuro planteamos la utilización de unamayor cantidad de instancias, otros modelos de traficoactuales (como Self-Similar[21]) así como otrosalgoritmos evolutivos (como por ejemplo DEPT,Differential Evolution with Pareto Tournaments [15]).VII. AGRADECIMIENTOSEl presente trabajo ha sido parcialmente financiado porel Ministerio de Ciencia e Innovación y el FEDER(Fondo Europeo de Desarrollo Regional), bajo elproyecto TIN2008-06491-C04-04 (proyecto MSTAR), ypor la Junta de Extremadura, a través de la ayudaGR10025 al grupo TIC015.reliability constraint, IEEE Transactions on Reliability, vol. 42, 1993,págs. 63-70.[4] Cem Ersoy and Shivendra S. Panwar, Topological design ofinterconnected LAN/MAN networks, IEEE Journal on Selected Areasin Communications, vol. 11, 1993, pág. 1172--1182.[5] F.N. Abuali, D.A. Schoenefeld, y R.L. Wainwright,Designing telecommunications networks using genetic algorithms andprobabilistic minimum spanning trees, Proceedings of the 1994 ACMsymposium on Applied computing - SAC ’94, Phoenix, Arizona,United States: 1994, págs. 242-246.[6] King-Tim Ko, Kit-Sang Tang y Cheung-Yau Chan y Kim-Fung Man, , y , Sam Kwong, Using genetic algorithms to design meshnetworks, Computer, vol. 30, Ago. 1997, págs. 56-61.[7] A. Kumar, R.M. Pathak, y Y.P. Gupta, Genetic-algorithmbasedreliability optimization for computer network expansion, IEEETransactions on Reliability, vol. 44, 1995, págs. 63-72.[8] C. Coello Coello, Evolutionary algorithms for solvingmulti-objective problems, New York: Springer, 2007.[9] N. Banerjee y R. Kumar, Multiobjective network design forrealistic traffic models, Proceedings of the 9th annual conference onGenetic and evolutionary computation - GECCO ’07, London,England: 2007, pág. 1904.[10] R. Kumar, P.P. Parida, y M. Gupta, Topological design ofcommunication networks using multiobjective genetic optimization,Proceedings of the 2002 Congress on Evolutionary Computation.CEC’02 (Cat. No.02TH8600), Honolulu, HI, USA: , págs. 425-430.[11] Kalyanmoy Deb, Samir Agrawal y Amrit Pratap y TMeyarivan, A Fast Elitist Non-dominated Sorting Genetic Algorithmfor Multi-objective Optimization: NSGA-II, Parallel Problem Solvingfrom Nature PPSN VI, 2000.[12] E. Zitzler, M. Laumanns y L. Thiele, SPEA2: Improvingthe strength Pareto evolutionary algorithm, EUROGEN 2001.[13] Mohsen Guizani, Ammar Rayes, Bilal Khan and Ala Al-Fuqaha.,Network Modeling and Simulation: A Practical Perspective,Wiley-Interscience, 2010.[14] T. Cormen, Introduction to algorithms, Cambridge Mass.:The MIT Press, 2001.[15] A. Rubio-Largo, M.A. Vega-Rodriguez, J.A. Gomez-Pulido, y J.M. Sanchez-Perez, A Differential Evolution with ParetoTournaments for solving the Routing and Wavelength Assignmentproblem in WDM networks, IEEE Congress on EvolutionaryComputation, Barcelona, Spain: 2010, págs. 1-8.[16] Fonseca, C., Knowles, J., Thiele, L., Zitzler, E. , A Tutorialon the Performance Assessment of Stochastic MultiobjectiveOptimizers, EMO 2005.[17] José Otero, Luciano Sánchez Diseños Experimentales yTests Estadísticos, Tendencias Actuales en Machine Learning VCongreso Español sobre Metaheurísticas, Algoritmos Evolutivos yBioinspirados, MAEB 07 Tenerife, Spain 2007[18] Shapiro, S. S. and Wilk, M. B, An analysis of variance testfor normality (complete samples), Biometrika, 52, 3 and 4, (1965) 591-611[19] Chakravarti, Laha, and Roy, Handbook of Methods ofApplied Statistics, Volume I, John Wiley and Sons, (1967). 392-394.[20] Wilcoxon, F. Individual Comparisons by RankingMethods. Bio-metrics 1, (1945) 80-83[21] Sahinoglu Z, Tekinay S, On multimedia networks: selfsimilartraffic and network performance", IEEE CommunicationsMagazine, vol.37, no.1, Jan. 1999, pp.48-52. Publisher: IEEE, USA.[22] W. Gropp, Using MPI : portable parallel programming withthe message-passing interface, Cambridge Mass.: MIT Press, 1999.VIII. REFERENCIAS[1] Andrew S. Tanenbaum, Computer Networks, Prentice Hall,2003.[2] B. Dengiz, F. Altiparmak, y A.E. Smith, Local searchgenetic algorithm for optimal design of reliable networks, IEEETransactions on Evolutionary Computation, vol. 1, Sep. 1997, págs.179-188.[3] Rong-Hong Jan, Fung-Jen Hwang, , y , Sheng-Tzong Chen,Topological optimization of a communication network subject to aJP2011-100

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A New Tool for Classification of SatelliteImages Available from Google Maps: EfficientImplementation in Graphics Processing UnitsSergio Bernabé a and Antonio Plaza aAbstract—In this work, we develop a new parallelimplementation of the k-means unsupervised clusteringalgorithm for commodity graphic processing units (GPUs),and further evaluate the performance of this newlydeveloped algorithm in the task of classifying (inunsupervised fashion) satellite imagery available fromGoogle Maps engine. With the ultimate goal of evaluatingthe classification precision of the newly developedalgorithm, we have analyzed the consensus or agreement inthe classification achieved by our implementation and analternative implementation of the algorithm available incommercial software. Our experimental results, conductedusing satellite images obtained from Google Maps engineover different locations around the Earth, indicate that theclassification agreement between our parallel version andthe k-means algorithm available in commercial software isvery high. In addition, the GPU version (developed usingthe CUDA language available from NVidia TM ) is muchfaster that the serial one (speedup above 30), thusindicating that our proposed implementation allows forlarger scale processing of high-dimensional imagedatabases such as those available in the Google Mapsengine.Keywords—K-means clustering, satellite imagery, GoogleMaps, GPUs, CUDA.TI. INTRODUCTIONHE wealth of satellite imagery [1] available inweb mapping service applications such as GoogleMaps 1 , which now provides high-resolutionsatellite images from many locations around the Earth,has opened the appealing perspective of performingclassification and retrieval tasks via programminglibraries such as SwingX-WS 2 . In fact, the introductionof Google’s mapping engine prompted a worldwideinterest in satellite imagery exploitation [2-4]. Thecombination of an easily pannable and searchablemapping and satellite imagery tool such as Google Mapswith advanced image classification and retrieval featureshas the potential to significantly expand thefunctionalities of the tool and also to allow end-users toextract relevant information from a massive and widelyavailable database of satellite images (the Google Mapsservice is free for non-commercial use).In this paper, we describe a new tool [5] which allowsan unexperienced user to perform unsupervisedclassification of satellite images obtained via Googlea Hyperspectral Computing LaboratoryDepartment of Technology of Computers and CommunicationsUniversity of Extremadura, Avda. de la Universidad s/n, E-10071 Cáceres, Spaine-mail: {sergiobenabe,aplaza}@unex.es.1 http://maps.google.com2 https://swingx-ws.dev.java.netMaps by means of the well-known k-means clusteringalgorithm [6], which can be followed by spatial postprocessingbased on majority voting. The classificationstage has been implemented in parallel using commoditygraphic processing units (GPUs) [7-8], which arespecialized hardware cards that are nowadays widelyavailable in standard PCs. It is important to emphasizethat GPUs offer important advantages in the context ofremote sensing image processing applications. Forinstance, while the price of a next-generation GPUstands at around 400€ (∼600 USD), the price of a clustercan be much higher. At the same time, using a clusterresults in a series of unfavorable conditions from thepoint of view of its implementation as a processingmodule onboard the remote sensing instruments, withcritical issues that can negatively affect the missionpayload (weight, power consumption, heating,maintenance, etc.). In turn, GPUs offer a much morecompact solution, although it is also important to bear inmind the conditions of tolerance of GPUs to extremerequirements in terms of consumption and sensitivity toradiation in space. However, we believe that the GPUsolutions offered in this work will soon exhibit thepotential to be incorporated into remote sensingmissions for onboard processing.Specifically, the GPU implementations reported in thiswork include analyses of consensus or agreement in theclassification achieved by our GPU implementation withregards to an alternative implementation of the k-meansclustering algorithm available in commercial software(ITT Visual Information Solutions ENVI 3 ). In addition,our parallel version of the k-means algorithm–implemented in NVidia TM GPUs using the computeunified device architecture (CUDA) 4 – is shown to bemore than 30 times faster than the serial version. Thisopens the way for exciting new developments andpotentials in efficient processing of large databases ofsatellite images, such as those available from GoogleMaps engine and used in this work for demonstration.The remainder of the paper is organized as follows.Section II describes the classification system that wehave developed for satellite images available in GoogleMaps engine. Section III describes the GPUimplementation. Section IV provides experimentalresults from the viewpoint of classification agreementand parallel performance on an NVidia Tesla C1060GPU. Finally, Section V concludes with some remarksand hints at plausible future research lines.3 http://www.ittvis.com/ProductServices/ENVI.aspx4 http://www.nvidia.com/object/cuda home new.htmlJP2011-101

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011II.CLASSIFICATION SYSTEM FOR SATELLITE IMAGESIN GOOGLE MAPS ENGINEOur classification system for Google Maps imagesconsists of the integration of the different softwaremodules developed (unsupervised classifiers) with thefunctionalities provided by the SwingX-WS libraries, inthe form of a general-purpose desktop application [2].For this purpose, we have resorted to the Javaprogramming language (see Fig. 1), which is a multiplatformenvironment that simplifies porting of our toolto different environments. Specifically, we have resortedto the NetBeans platform 5 , which allows applications tobe developed from a set of modular softwarecomponents called modules. In this framework,applications can install modules dynamically and anyapplication can include the update center module toallow users of the application to download digitallysignedupgrades and new features directly into therunning application. Reinstalling an upgrade or a newrelease does not force users to download the entireapplication again. The platform offers reusable servicescommon to desktop applications, allowing developers tofocus on the logic specific to their application.With the above ideas in mind, Fig. 2 shows differentviews of the developed tool. As shown by Fig. 2, thetool allows selecting an area to be classified, obtainingclassification results in unsupervised fashion, retainingthe classified area at different zoom levels (although theclassification is obtained at the maximum zoom level),and other functionalities such as spatial post-processingof obtained results for increased spatial consistency,managing of the resulting classification and extractedsatellite images, loading/storing of results via file logswhich can be saved in a database, automatic positioningin any latitude and longitude coordinates in the entireGoogle Maps database, overlaying of classificationresults with different views (satellite, map, hybrid), etc.Overall, we feel that the developed tool incorporatesinteresting additional functionalities to the Google Mapsengine (particularly in the possibility of better exploitingthe satellite images available from this tool in differentapplication domains).III.GPU IMPLEMENTATIONGPUs can be abstracted in terms of a stream model,under which all data sets are represented as streams (i.e.,ordered data sets) [4]. Algorithms are constructed bychaining so-called kernels, which operate on entirestreams, taking one or more streams as inputs andproducing one or more streams as outputs. Thereby,data-level parallelism is exposed to hardware, andkernels can be concurrently applied without any sort ofsynchronization.Fig. 2. Different views of the developed tool. Selection of an area to beclassified in New York City (top). Unsupervised classificationresult provided by our implementation of k-means superimposedon the tool (middle). Zoom reduction retaining the classified area(bottom).Fig. 1. Different software modules used for the development of ourapplication.5 http://netbeans.orgThe kernels can perform a kind of batch processingarranged in the form of a grid of blocks, as displayed inFig. 3(a), where each block is composed by a group ofthreads which share data efficiently through the sharedlocal memory and synchronize their execution forcoordinating accesses to memory. This figure alsodisplays how each kernel is executed as a grid of blocksJP2011-102

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011of threads. On the other hand, Fig. 3(b) shows theexecution model in the GPU, which can be seen as a setof multiprocessors. In each clock cycle each processorof the multiprocessor executes the same instruction butoperating on multiple data streams. Each processor hasaccess to a local shared memory and also to local cachememories in the multiprocessor, while themultiprocessors have access to the global GPU (device)memory.In the following we describe the different steps that wefollowed for the development of the GPU version of thek-means algorithm. In our implementation, pixels aredistributed in the form of vectors which store the valuesof the red, green, blue and saturation components. In thefollowing, we assume that images fit in the global GPUmemory. The k-means algorithm calculates theeuclidean distance from each pixel vector to the closestcluster center (centers are initialized randomly). In ourCUDA implementation, we assigned the calculation ofthe distance of each pixel of the image to an independentprocessing thread. This way, each thread calculates ofthe distance between the values of each pixel and thenearest cluster center. Fig. 4 illustrates the kernel thatperforms this operation. Next, we recalculate the centersof each cluster and reassign new pixels to each of theclusters until convergence. This part has not beenparallelized in the GPU, mainly because for a smallnumber of clusters this computation can be performed inthe CPU without representing a dominant factor in theoverall time of the solution.k-means has been conducted by comparing the resultsprovided by our GPU implementation with thoseavailable in a well-known commercial softwarepackage: the ENVI package distributed by ITT VisualInformation Solutions. In our tests, we adopt exactly thesame parameters when running our implementation andthe one available in ENVI software, comparing theresults in terms of the agreement between both solutionsand their computational performance.(a)(b)Fig. 3. Schematic overview of a GPU architecture. (a) Threads, blocksand grids. b) Execution model in the GPU.(c)Fig. 5. (a) Satellite image over the World Trade Center area. (b)Unsupervised classification result provided by our GPUimplementation of k-means. (c) Unsupervised classification resultprovided by ENVI’s implementation of k-means.Fig. 4. Main CUDA kernel developed for the implementation ofk-means algorithm in GPUs.IV.EXPERIMENTAL RESULTSIn this section, we perform an experimental validationof our developed system using satellite images obtainedfrom Google Maps. The experimental validation ofIn the following, we present the obtained results in aspecific case study focused on classification of satelliteimages available from the World Trade Center (WTC)area in New York City. Fig 5(a) shows a satellite imageextracted from Google Maps engine. The resolution ofthe image is quite high, with approximately 5 meters perpixel. Fig. 5(b) shows the unsupervised classificationresult provided by our GPU implementation asJP2011-103

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011compared to the result provided by ENVI’s k-means inFig. 5(c). As shown by Fig. 5, the color labels for ourimplementation and the one available in ENVI aredifferent, but the classification maps are very similar. Inboth cases, the parameters for both algorithms have beenset to exactly the same values, with the number ofclusters set empirically to five. Table I reports theclassification agreement (in percentage) measured aftercomparing our k-means classification map with the oneobtained by ENVI (assuming the latter as the reference).As shown by Table I, the agreement between both mapsis quite high.TABLE IClassification agreement (in percentage) after comparing theclassification map provided by our GPU implementation of k-meanswith the classification map obtained by ENVI’s k-means for the imagein Fig. 5(a).Shadows #1[blue inFig. 5(b)]Shadows#2 [red inFig. 5(b)]Urbanareas #1[yellow inFig. 5(b)]Urbanareas #1[green inFig. 5(b)]Urbanareas #2[orange inFig. 5(b)]Overallagreement78.26 95.49 85.56 90.65 97.39 89.47In a second experiment, we have selected a specificcase study focused on classification of satellite imagesavailable from the Nile river in the north of Cairo(Egypt) (see Fig. 6). The resolution of the image is quitehigh, with approximately 5 meters per pixel. As show byFig. 6, the color labels for our implementation and theone available in ENVI are different, but theclassification maps are very similar. In both cases, theparameters for both algorithms have been set to exactlythe same values, with the number of clusters set to five.Table II reports the classification agreement (inpercentage) measured after comparing our k-meansclassification map with the one obtained by ENVI(assuming the latter as the reference). As shown byTable II, the agreement between both maps is quite high.TABLE IIClassification agreement (in percentage) after comparing theclassification map provided by our GPU implementation of k-meanswith the classification map obtained by ENVI’s k-means for the imagein Fig. 6(a).Soil #1[blue inFig. 6(b)]Water #1[green inFig. 6(b)]Urbanareas #1[orange inFig. 6(b)]Water #2[red in Fig.6(b)]Soil #2[yellow inFig. 6(b)]Overallagreement63.89 96.98 99.74 89.01 94.59 88.47TABLE IIIProcessing times (in seconds) and speedups achieved with regards tothe corresponding CPU for different GPU implementations of thek-means algorithm (using different image sizes and number ofclusters), in Fig. 5(a).(a)Parameters consideredGeForce 9400MGPUTesla C1060 GPUImage sizeNumber ofclustersTime Speedup Time Speedup512 x 512 5 0.252 3.26x 0.145 5.67x512 x 512 64 0.496 7.60x 0.210 17.95x512 x 512 128 0.764 10.29x 0.268 29.33x1024 x 1024 64 3.582 6.18x 0.715 30.97x1024 x 1024 128 4.376 8.76x 1.044 36.69x(b)(c)Fig. 6. (a) Satellite image collected over a stretch of the Nilo river inEgypt (the image is available online through Google Mapsengine). (b) Unsupervised classification result provided by ourGPU implementation of k-means. (c) Unsupervised classificationresult provided by ENVI’s implementation of k-means.TABLE IVProcessing times (in seconds) and speedups achieved with regards tothe corresponding CPU for different GPU implementations of thek-means algorithm (using different image sizes and number ofclusters), in Fig. 6(a).Parameters consideredGeForce 9400MGPUTesla C1060 GPUImage sizeNumber ofclustersTime Speedup Time Speedup512 x 512 5 0.140 3.84x 0.118 4.55x512 x 512 64 0.458 4.79x 0.210 10.46x512 x 512 128 0.592 6.28x 0.223 16.67x1024 x 1024 64 5.153 3.59x 1.046 17.68x1024 x 1024 128 6.467 4.01x 1.254 20.66xJP2011-104

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Finally, we analyze the computational performance ofthe developed GPU implementation with regards to itsCPU (serial) version. In this work, we have used twodifferent CPU-GPU configurations. In the first one, weuse an Intel Core i7 920 CPU with the Ubuntu 9.04Linux operating system and the NVidia Tesla C1060GPU 6 . In the second one, we use an Intel Core 2 DuoP8700 2.53Ghz CPU with the Windows 7 operatingsystem and an NVidia GeForce 9400MGPU 7 . Table IIIand Table IV show the execution times achieved foreach of the CPU-GPU configurations used, as well asthe speedups achieved for different image sizes andnumber of clusters. An important observation is that, aswe increase the image size and number of clusters, thespeedup achieved by the GPUs tends to be moresignificant. For instance, the implementation in the TeslaC1060 GPU achieves a speedup of about 37x withregards to the CPU version for 1024 × 1024 image sizeand 128 clusters in the best case. However, theimplementation in the GeForce 9400M GPU saturatesfor certain image sizes, achieving a speedup of about10x in the best case.V. CONCLUSIONS AND FUTURE RESEARCHIn this work, we have developed a new parallelimplementation of the k-means clustering algorithm inthe context of satellite image processing usingNVIDIA TM GPUs. The algorithm has been implementedusing CUDA, and tested using a recently developedsystem for information extraction and analysis of imagedata sets from Google Maps engine. The algorithm hasbeen evaluated in terms of its agreement withcommercial software in the same context, and alsoanalyzing the speedup with regards to the (optimized)serial implementation of the same code.The main contributions of this study can besummarized as follows:• The proposed method succeeded in obtaining agood agreement in classification with regards tocommercial software.• The GPU implementation obtained a significantspeedup over the optimized serial version, thussupporting large scale tests in the Google Mapsengine.In future work, we will develop other parallelimplementations of the considered algorithm and alsoimprove the clustering procedure by including otherclassifiers such as support vector machines (SVMs),which allow a user to train the classifier by selectingtraining samples from the image to be processed insemi-supervised fashion. Implementations of theproposed methods in OpenCL also represent aninteresting future research line.project, reference AYA2008-05965-C04-02). Fundingfrom Junta de Extremadura (local government) underproject PRI09A110 is also gratefully acknowledged.REFERENCES[1] D. A. Landgrebe, Signal theory methods in multispectral remotesensing, John Wiley and Sons, Hoboken, NJ, 2003.[2] P. Soille, Morphological image analysis: principles andapplications, Springer-Verlag, Berlin, 2003.[3] J. A. Benediktsson, J. A. Palmason, and J. R. Sveinsson,“Classification of hyperspectral data from urban areas based onextended morphological profiles”, IEEE Trans. Geoscience andRemote Sensing 42, pp. 480 - 491, 2005.[4] L. Bruzzone, M. Chi, and M. Marconcini, “A novel transductivesvm for the semisupervised classification of remote sensingimages” IEEE Trans. Geoscience and Remote Sensing 44, pp.3363 - 3373, 2006.[5] S. Bernabe and A. Plaza, “A new system to performunsupervised and supervised classification of satellite imagesfrom google maps,” Proc. SPIE Conference on Satellite DataCompression, Communications, and Processing, vol. 7810, pp.1–10, 2010.[6] J. A. Hartigan and M. A. Wong, “Algorithm as 136: A k-meansclustering algorithm,” Journal of the Royal Statistical Society,Series C (Applied Statistics), vol. 28, pp. 100–108, 1979.[7] J. Setoain, M. Prieto, C. Tenllado, A. Plaza, and F. Tirado,“Parallel morphological endmember extraction using commoditygraphics hardware”, IEEE Geoscience and Remote SensingLetters, vol. 43, pp. 441–445, 2007.[8] J. Setoain, M. Prieto, C. Tenllado, and F. Tirado, “GPU forparallel on-board hyperspectral image processing," InternationalJournal of High Performance Computing Applications 22 (4), pp.424-437, 2008.ACKNOWLEDGEMENTThis work has been supported by the Spanish Ministryof Science and Innovation (HYPERCOMP/EODIX6 http://www.nvidia.com/object/product tesla c1060 us.html7 http://www.nvidia.com/object/product geforce 9400m g us.htmlJP2011-105

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-106

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Visibility Map Computation at all Points of aTerrainL. F. Romero, 1 S. Tabik, 2 E.L. Zapata 3Abstract— The knowledge of visibility informationon a terrain is essential for a large number of currentapplications. There exist several algorithms in theliterature for building visibility maps (VM) but onlyfor one single viewpoint or at most for a very smallnumber of observers. This limitation is due to thehigh computational complexity of the used methods(which is greater than O(N 2 ), where N is the numberof the terrain points) and also to the fact thatsingle-point algorithms cannot efficiently be scaled toall points. We present a novel fast algorithm ableto compute the complete VM where, given a terrainT represented by its regular digital elevation model(DEM), our method produces a continuous VM foreach point of T. In fact, the proposed algorithm combinestwo algorithms, i) a visible heights computationalgorithm that divides the terrain into sectors andcalculated the end of all the visible ring sectors, andii) an algorithm that finds out the start of the visiblering sectors using a low cost calculation. To ease thetheoretical and experimental comparisons with previousworks, we considered the VM for one single observer.The results show that our algorithm is moreaccurate and faster by many orders of magnitude thanthe widely used ArcGis visibility tools.I. IntroductionIN the last decade, new larger DEMs (Digital ElevationModels) of higher precision are being created,for example, a global DEM of the earth’s landsurface of size 15.1015 pixels and precision 3 arc seconds(approximately 90 x 90 m2 at the equator) isnow available in [1]; in addition to a large numberof DEMs of many regions of resolution higher than 1arc second (30 x 30 m2). Moreover, in the next threeyears new global products of higher resolution are expected;TanDEM-X Satellite, launched the 21st June2010, will allow the generation of global DEMs of resolutionhigher than 10 x 10 m2. This advances areproducing a huge need to new fast and efficient GIS(Geographic Information Systems) processing algorithms.An important number of GIS applications on terrainsrepresented by DEMs is concerned with visibility.There exists a wide range of actual applications.Examples include the computation of the minimumnumber of locations that have the largest coverageof a terrain [2], [16] i) for placing radio, TV, Internet,wireless or mobile phones transmitters and receiversin telecommunications, ii) for situating forestfire watchtowers in environmental planning, iii) fordetermining routes for hiking trails in tourism. Recently,visibility analysis is also used for visual impactassessment, such as the impact of aquiculture1 Dpto. Arquitectura de Computadores, Universidad deMalaga, e-mail: felipe@uma.es2 stabik@uma.es3 ezapata@uma.esprojects [4] and wind turbines farms installations [6].It is also used to improve wildlife population size estimationtechniques [5], and in the field of archeology,it is used for the reconstruction of views to and fromhistorical objects and sites [7].Most visibility software, such as the well knownvisibility analysis tools implemented under the commercialArcGIS 9.0 [8], r.los implemented underGRASS 6.2.2 [9] and, many algorithms provided inthe literature [12], [18], [13], [17], [20], [21] computethe parts of a terrain that are visible from a singleviewpoint or at most from a reduced number of observers.However none of these implementations iscapable of computing the VM at all the points of theterrain. The reason behind this limitation is thatthe calculation of VM even for a single point is tooexpensive and has a complexity greater than O(N),where N is the total number of points of the DEM.This means that computing the complete VM at allthe points of the terrain has a complexity greaterthan O(N 2 ).This paper presents a novel algorithm able to computethe VM on the entire terrain with a low cost. Incontrast to most previous algorithms which processall the N points of the DEM in order to produce theVM of one single point, our method finds out the visiblepoints by regions. That is, it looks for the visiblepoints only among a selected set of points, called sector.As the size of the selected set is O(log(N/S)),finding the visible regions over all the terrain has acomplexity of only O(S.N.log(N)), where S is thetotal number of sectors. As far as we know, thisalgorithm is the first in computing the VM for theentire terrain. To make our algorithm comparablewith one of the most used visibility algorithms, ArcGis,we compared the runtimes of computing VM atone single viewpoint. The experimental results showthat our algorithm is largely faster than the visibilityanalysis tool of ArcGis.This paper is organized as follows. A brief descriptionof related works is given in section 2. A detaileddescription of all the algorithmic strategies, necessaryfor carrying out both stages of the algorithm, isprovided in section 3. Numerical and computationalresults are given in section 4 and, finally conclusionsin section 5.II. Related WorksThe problem of computing continuous visibilitymaps with respect to a single viewpoint has beenextensively studied in the literature. Nagy and, Florianiand Magillo provide complete surveys of visibilityalgorithms in [10] and [11] respectively. In thisJP2011-107

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011section we will discuss only those papers more relatedto our own work.Atallah [12] uses a divide-and-conquer algorithmto compute the upper envelope of N segments in theplane with a time complexity of O(Nα(N)logN)),where α is the inverse Ackermann function, a slowgrowing function, nearly constant. This algorithmrecursively divides the line segments into halves, andpairwise merges the resultant upper envelopes viaa sweep line technique. Hershberger [13] improvesAtallah’s algorithm, reaching an optimal complexityof O(NlogN). De Floriani et al. [17] computesthe visibility map on TINs (Triangulated IrregularNetworks) using the front-to-back order intime O(N 2 α(N)).Alternatively, the visibility problem can also besolved using horizon calculation. The approximativemethod of Cabral et al. [20] divides the horizon intoS sectors, and in each sector it determines the elevationof the horizon, considering solely the pointsof the terrain that are in the central line of the sectorwith a computational cost O(S(N 1.5 )). Stewart[21] proposed a more precise and faster algorithmthat computes the approximate horizon for all thepoints of the DEM in the whole sector with a totalcost O(SN(log 2 N +S)) and space O(N(log N)). Finally,Tabik et al. [22] proposed a three-level horizonapproach more than three times faster than Stewartsalgorithm while maintaining the same accuracy.Nevertheless, none of these works produces the visibilitymap at all the points of a terrain.III. Our AlgorithmOur algorithm works in two main phases. Actually,it solves the visibility problem by finding thelimits where the visible regions start and end. In thefirst phase, it searches for the visible heights amongthe points that form the horizon or the profile of theterrain. In particular, it finds the end limits of thevisible regions, of ring sector shapes, in each directionaround the points of the terrain. In the nextphase, it uses a very fast algorithm to calculate thestart limits of those visible ring sectors.A. Visible Heights ComputationIn this section we describe all the algorithmic basisof this stage and the optimizations that makes thewhole algorithm faster.A.1 Profile ComputationThe DEM of a terrain T can be described as aset of N points P i (i = 0, ..., N) of coordinates(x i , y i , z i ), where z i is the height of the point. The algorithmdivides the space around the points P i of theDEM into S sector of azimuth angle 2π Sradians eachone. Each point P i has an associated data structureD Pi which store all points that lie in region s, wheres = 1, ..., S. The profile of a given point is consideredas the sequence of points that have the maximum elevationsin s; together they form a boundary that coversall the points of D Pi . These upper convex hullsFig. 1. Point P i has three visible ring sectors (in light grey) inthe region delimited by sector s. These visible ring sectorsare determined by the set of Start-of-Ring-Sector pointsSRS.s.p and the End-of-Ring-Sector points ERS.s.p.Fig. 2. In direction s, P i and P i+1 belong to the set of Endof-visible-Ring-Sectorspoints of P 0 (i.e., ERS.s. P0 ={P i , P i+1 } ). While in the opposite sector, s ′ , with ŝ ′ =−ŝ, P i and P 0 belong to the End-of-visible-Ring-Sectorsof the point labeled as ”?” (i.e., ERS.s’.? = {P i , P 0 }. Thepoint labeled as ”?” belongs to the set of Start-of-visible-Ring-Sectors of P 0 and it is found in the second stage ofthe algorithm.are calculated by projecting all the points stored inD Pi onto the vertical plane that passes from z-axis.The points that have the maximum tangent (calculatedbetween the projection of P i and each point inD Pi ) are maximum elevations. Moreover, a binarytree, HT , of N leaves is used to store all the profilesof all the points of the DEM during the S iterations.The algorithm processes the points in a previouslydetermined order in such a way that each point findsits profile in HT and simultaneously it is incorporatedas a candidate profile point for the points thatwill be processed in next iterations.A.2 Notion of Visible Ring SectorWe formulate VM computation into determiningwhere the continuous visible regions start and end.Once the space is partitioned into sectors, we proceedto compute the visible areas, of ring sector shapes,in each sector s. A visible ring sector from a givenpoint P is delimited by the set of points where thering sector starts, which we call Start of Ring SectorSRS.s.P , and the set of points where the ring sectorends, which we call End of visible Ring SectorERS.s.P . See Figure 1 for illustration.A.3 Opposite Sector Based OptimizationIn each sector s and for each point P of the terrain,the set SRS.s.P and ERS.s.P must be found.Suppose the algorithm has already calculated theSRS.s.P and ERS.s.P of a specific point P in sec-JP2011-108

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tor s. In future iterations, particularly in the oppositesector s ′ such as ŝ ′ = −ŝ (i.e., ŝ ′ = ŝ + π), thealgorithm will analyze again the point P as possibleSRS.s’ or ERS.s’, in sector s ′ , of its own SRS.s.P andERS.s.P points. For simplicity consider the easy exampledrawn in Figure 2. If the point labeled as ”?”belongs to SRS.s.P 0 , in direction s, thus P 0 may belongto ERS.s’.? in the opposite sector s ′ . Therefore,calculating both SSR and ERS of all the points ofthe DEM is redundant and requires twice as muchcalculation and storage capacity. To eliminate thisredundancy, we first compute and store only the ERSof all the points of the terrain and then in a secondstage use a very fast postprocessing to obtain theSRS points. This approach reduces the storage requirementsand calculation by half.A.4 ERS points ComputationOur algorithm searches for the ERS.s.P i amongthe profile points based on the following assumption.The ERS and SSR points of P belong to the set ofpoints that form P ’s own profile (or hulls) in s. Thiscan be demonstrated mathematically as follows:Lemma:∀Q ∈ D P , if Q ∈ ERS.s.P ⇒ Q ∈ some hull.Proof:suppose Q ∈ ERS.s.P and Q /∈ any hull.this means that ∃!Q ′ such as Q ′ elevation islarger than P elevationwhich implies that Q /∈ ERS.s.PTo determine the ERS.s.P points among the profilepoints, the algorithm processes the profile pointsin the increasing distance order from P . If the tangentbetween the projection of the last profile pointand the current profile point is greater than themaximum angle, the current point is added to theERS.s.P set.A.5 ERS Computation Algorithm SummaryIn summary, our visibility algorithm can be describedas follows:For each sector s in S– We sort all the points of the DEM by a ⊥and b ⊥ in the new system (a ⊥ , b ⊥ , z), wherea ⊥ and b ⊥ are two vectors perpendicular tovectors a and b that delimit sector s. Sincethe target DEMs are regular grids, the sortingoperation can be carried out by counting thenumber of points behind the sweep line usingvery simple trigonometric operations, i.e., theposition number is directly computed. In practicethe time spent in this phase is negligible.We reuse the ordering by b ⊥ in sector i to reorderby a ⊥ in sector i + 1. The new indicesj and k are determined for each point.– For each point P j,k in order of increasing indexj :∗ Add all the points that fall in s to D P∗ Compute the profile points using the Hulltree of P j,k . The structure and processingorder of the tree ensure a highly efficientcomputation since the profile points elevationis always found among the O(logN)leaf-to-root nodes in the tree.∗ Add to tree new candidate as possible profilefor next points. The tree is updated byinserting the heights of the new point P j,k .Index k is used to insert the point in thestructure.∗ Find ERS points among profile points andstore them in the ERS structure.– The points are reordered from their indices jto recover the original ordering.A.6 Start-of-Ring-Sector CalculationOnce all the ERS points are calculated for all thepoints of the terrain, the algorithm proceed to computethe SRS points by sector and by point. In thisstage, each point P looks for the points whose it isend of ring sector and stores them into a data structurethat we call reverse list. In principle, all thepoints that belong to this list are candidates for SRSof P . For illustration consider point P 0 in Figure 2.Among the set of points limited by two consecutiveERS points, P i and P i+1 , the points that have P 0as ERS in the opposite sector and belong to the interval[P i , P i+1 ] are candidates for SSR.s.P 0 . Onlythe point that verifies the following criteria is SRS ofP 0 . It is further than P i and nearer than P i+1 andobviously it is a candidate in the reverse list.This stage is very slight from a computationalpoint of view. For instance, for the terrain shownin Figure 3(a) of size 2000 × 2000 points, the secondstage takes only 33 minutes on a Desktop basedon Intel core2 duo that runs at 3.16 GHz with 3,25GB of main memory. Actually, computing the reverselist takes 3 minutes and calculating SRS takes30 minutes.Due to the discrete nature of the problem, thereverse search method explained above doesn’t ensurethat every ERS matches with its SRS. Alternatively,missed SRSs can be found using a binarysearch among candidates in the current sector, whichis also very fast because, in Stewart’s method, DEMpoints have been already sorted in the required order.IV. Numerical and Computational ResultsSome numerical results of our approach are shownin Figure 3. In particular, Figure 3(b) shows thevisibility map computed on the terrain of the cityof Malaga, Spain, whose DEM is shown in Figure3. The value at each pixel in Figure 4 shows thenumber of visible Km 2 . Dark red color correspondsto points with very high visibility, about 100 visibleKm 2 . Dark blue color corresponds to points withvery low visibility. From this figure, one can observethat higher points don’t necessarily have higher visibility.Actually, some points at the sea level havenotably more visibility than higher interior points.One of the main advantages of the visibility mapsthat our algorithm is able to produce is allowing aJP2011-109

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Elevation map of the city of Malaga, Spain; darkerred and lighter green correspond to points with higher andlower elevations respectively.Fig. 5. The light grey regions indicate the ring sectors visiblefrom a point selected at the sea level in the 2000 × 2000points DEM of the city of Malaga, Spain.Fig. 4. The visibility map of the city of Malaga; darker redand darker blue show higher and lower numbers of visibleKm 2 respectively.global visibility comparison over all the points of theterrain.The precision of the VM calculated by our algorithmonly depends on the resolution of the usedDEM and the considered number of sectors. It can beincreased or decreased depending on the needs of theconsidered application. Notice that the azimuthalsectorization of the viewshed involves a slight linearloss of precision in very distant locations. Thisfact can be appreciated in Figure 5, which showsthe farthest End-of-Ring-Sectors seen at a point selectedfrom the lower right corner (at the sea level) ofthe DEM of the city of Malaga. However, this kindof precision losses is irrelevant in most applicationssince signals intensity is inversely proportional to thesquare of the distance (I = P/4πd 2 , where P is thepower of the signal).The code was implemented in C++ and compiledwith -O3. For performance evaluations, we comparedthe runtime of our algorithm with the runtime of ArcGis[8], one of the fastest and widely used softwarefor viewshed calculation. We performed all experimentson a PC based on Intel core2 duo running at3.16 GHz with 3.25 GB of main memory. Comput-ing the ERS points of all the points of a 2000 × 2000points DEM (of size 8 MB), considering 360 sectors,takes about 6.5 hours. Building the reverse list takes3 minutes and finding the SRS points takes about30 minutes. Storing the ERS points by sector in filestakes 10 minutes resulting in a set of 360 files of a totalsize of about 42 GB. This means that the storagerequirements per point per sector is about 30 bytes.In VM of the city of Mlaga shown is Figure 3(b), theaverage number of ring sectors per point per sectoris equal to 3.1 ring sectors.Taking into account all these measurements, computingthe VM at a single point on a terrain of size2000 × 2000 points using the algorithm we proposedin this work takes only 0.0063 seconds, while ArcGistakes about 10 seconds to compute VM in the sameconditions.V. ConclusionsWe presented a new and fast algorithm that computesthe visibility map on the entire terrain. Theproposed algorithm can be very useful for acceleratinga wide range of visibility based applications.For example it can be used to accelerate siting multipleobservers so as to jointly cover as much terrainas possible described in [15] and for extending thevisibility index calculation, cited in [15], [2], to verylarge radius. The presented algorithm has a timecomplexity O(S.N.log(N)) substantially better thanprevious single-point-visibility algorithms and scalesO(N.log(N)) versus O(N 2 ) for previous algorithms.Moreover, experimental results demonstrate that ourmethod is faster by many order of magnitude thanmost used visibility tools included in ArcGis.AcknowledgementsThis work was supported by the Spanish Ministryof Education and Science throughout Juan dela Cierva Grant and the project TIN2006-01078.References[1] CGIAR-Consortium for Spatial Information ShuttleRadar Topography Mission (SRTM) Database [online].JP2011-110

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Available from: http://srtm.csi.cgiar.org/. 2007.[2] Franklin R. and Ray C. K. Advances in GIS Research:Sixth International symposium on spatial Data handlinghigher isn’t necessarily better: Visibility Algorithms andExperiments. 1994.[3] Floriani, L.D., Magillo, P. Algorithms for visibilitycomputation on digital terrain models. Proceedings ofthe ACM/SIGAPP Symposium on Applied Computing.ACM, New York. 1993.[4] Perez O. M., Telfer T. C. and Ross L. G. Use of GISbasedmodels for integrating and developing marine fishcages within the tourism industry in Tenerife (CanaryIslands) Coastal Management 31(4), 355-366. 2003.[5] Maichak E. J. and Schuler K. L. Applicability of viewshedanalysis to wildlife population estimation AmericanMidland Naturalist 152, 277-285. 2004.[6] Kidner D. B., Rallings P. J., Ware J. A. Parallel processingfor terrain analysis in GIS: Visibility as a case study,Geoinformatica, 1(2), 183–207. 1997.[7] Ogburn D. E. Assessing the level of visibility of culturalobjects in past landscapes Journal of Archaeological Science33, 405-413. 2006.[8] ESRI(Environmental Systems Research Institute) AR-CGIS Software. Version 9.3. 2010.[9] GRASS Development Team Geographic Resources AnalysisSupport System (GRASS) Software, available inhttp://grass.itc.it. 2007.[10] Nagy G. Terrain visibility Computers and Graphycs,8(1), 763–773. 1994.[11] De Floriani L. and Magillo P. Algorithms for visibilitycomputation on terrains: A survey, Environment andPlanning B: Planning and Design 30, 709-728. 2003.[12] Atallah M. Dynamic computational geometry Proceedingof the 24th IEEE Symposium on the Foundations ofComputer science, 92-99. 1983.[13] Hershberger J. Finding the upper envelope of n line segmentsin O(n log n) time, Information Processing Letters,33(4), 169174. 1989.[14] Stewart A.J. Fast Horizon Computation at All Points of aTerrain With Visibility and Shading Applications IEEETransactions on Visualization and Computer Graphics,4(1), 82–93. 1998.[15] Franklin R. Sitting observers on terrain. Symposium onSpatial Data Handeling. 2002.[16] Ben-Shimo Y., Ben-Moshe B., Ben-Yehezkel Y., Dvir A.and Segal M. Automated antenna positioning algorithmsfor wireless fixed-access networks. Journal of Heuristics,13(3), 243–263. 2007.[17] De Floriani L., Falcidieno B. , Nagy G. and PienoviC. Polyhedral Terrain Description Using Visibility Criterianstitute for Applied Mathematics, National ResemvhCouncil, Technical Report (17). 1989.[18] De Floriani L., and Magillo P. Visibility Algorithms onTriangulated Terrain Models International Journal of GeographicInformation Systems, 8(1), 13–41. 1994.[19] Katz M. J. , Overmars M. H., Shairr M. Efficient hiddensurface removal for objects with small union size Proceedingsof the seventh annual symposium on Computationalgeometry, 31–40, New Hampshire, United States 1991.[20] Cabral B., Max N., and Springmeyer R. Bidirectionalreflection functions from surface bump maps ACM SIG-GRAPH Computer Graphics 21, 273–281. 1987.[21] Stewart A.J. Fast Horizon Computation at All Points of aTerrain With Visibility and Shading Applications IEEETransactions on Visualization and Computer Graphics,4(1), 82–93. 1998.[22] S. Tabik, L. F. Romero and E. L. Zapata High PerformanceThree-horizon Composition Algorithm for largescale terrains International Journal of Geographical InformationScience. 25(4), 541–555 2011.JP2011-111

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-112

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Un método de acceso aproximado para muyalta dimensionalidad y su paralelizaciónFernando Artigas Fuentes 1 José Manuel Badía Contelles 2 y Reynaldo Gil García 3Resumen— En este trabajo, proponemos un nuevométodo de acceso aproximado para espacios de muyalta dimensionalidad y especialmente aquellos conmuy alta dispersión de los datos. Está basado enel uso de múltiples grafos como estructura de indexadoy un algoritmo de búsqueda para obtener de unrepositorio de objetos, representados como vectores,aquellos más relacionados a otros objetos usados comoconsultas. Aunque este método es aproximado, muestraun nivel bajo de error. Tiene además un costetemporal muy bajo durante las consultas y está especialmentediseñado para ser ejecutado en paralelo deforma simple y eficiente. Mostramos versiones paralelastanto para la generación de la estructura de indexadocomo para el algoritmo de búsqueda. Se ha paralelizadousando la interfaz OpenMP. Hemos evaluadonuestra propuesta sobre espacios de representación demiles dimensiones obteniendo prestaciones paralelascercanas al óptimo.Palabras clave— métodos de acceso, computaciónparalela, búsqueda aproximada, grafos.I. IntroducciónPARA recuperar información, es muy común quese utilice un método de acceso. Este tiene elobjetivo de organizar los objetos de un repositorio deforma tal que durante las consultas solo sea necesarioacceder a una porción del mismo. Cuanto menor seala porción visitada para cada consulta, más eficienteresulta el método de acceso.La mayoría de los datos que se manejan en la actualidadson descritos mediante un gran número de características,que para los métodos de acceso se conviertenen dimensiones del espacio de representaciónde los datos.Existe en la literatura un conjunto amplio demétodos de acceso capaces de indexar espacios multidimensionales,pero la mayoría sufre un problemaconocido como ”Maldición de la dimensionalidad”[1]. Este provoca que a medida que aumenta ladimensionalidad del espacio de representación delos datos los resultados de la búsqueda se vandegradando hasta convertirse en iguales o peores quepara el caso de búsqueda exhaustiva.Debido a que todos los métodos exactos sufren elproblema antes descrito, para el caso de espacios demuy alta dimensionalidad, se han presentado en laliteratura nuevos métodos que obtienen solucionesaproximadas. Estos métodos utilizan varias técnicasque consisten en relajar las condiciones tanto de laconstrucción de las estructuras de indexado como de1 CERPAMID, Univ. Oriente, Cuba, e-mail:artigas@cerpamid.co.cu.2 Dpto. de Ingeniería y Ciencias de los Computadores, Univ.Jaume I, e-mail: badia@icc.uji.es.3 CERPAMID, Univ. Oriente, Cuba, e-mail:gil@cerpamid.co.cu.las estrategias de búsqueda. Algunas de las técnicasusadas son la reducción de la dimensionalidad delespacio de búsqueda, seleccionando un subconjuntode características más representativas de los objetos,hasta valores más manejables por los métodos ya existentes[2], y la sustitución de los objetos originalespor otros menos complejos que mantengan aproximadamentelas mismas relaciones de vecindad quelos originales [6].Otras propuestas son eficientes manejando un grannúmero de dimensiones, como es el caso del VA-filey los derivados de este [3], [4], [5]. Sin embargo,estos métodos se vuelven ineficientes cuando a la altadimensionalidad de los datos tratados se suma unaalta dispersión de los mismos.En este trabajo proponemos un nuevo métodode acceso que es poco afectado por ambos problemas:la alta dimensionalidad y la alta dispersiónde los datos. El mismo está basado en el uso demúltiples grafos como estructura de indexado y unalgoritmo de búsqueda que, aunque aproximado, permiteobtener un elevado porcentaje de soluciones exactascon un coste temporal muy bajo.Además, la estructura de datos se ha diseñado conel fin de poder construirla y utilizarla en paralelo deforma sencilla y eficiente. Presentamos además unaversión paralela de este método, mediante el uso dememoria compartida y la interfaz OpenMP.El resto del trabajo está organizado como sigue: enla sección 2 se trata con más detalles las propiedadesde los métodos de acceso, en la sección 3 explicamosnuestra propuesta y su paralelización, en la sección 4describimos los experimentos realizados y los resultadosobtenidos. Finalmente en la sección 5 mostramoslas conclusiones de este trabajo.II. Métodos de accesoUn método de acceso está formado por una estructurade indexado, que organiza de alguna maneralos objetos de un repositorio, y una estrategia debúsqueda que debe recorrer los objetos indexados dela manera más eficiente.Un método de acceso necesita además de una medidade comparación entre los objetos que exprese laproximidad entre estos. Esta puede ser una semejanza,que da una medida de en cuanto se parecendos objetos entre sí; o una diferencia, que determinaen cuanto se distinguen. Por lo general como medidade comparación se usa una función de distancia, queademás de expresar lo cercano que están los objetosentre sí, define un espacio métrico.Una función distancia puede expresarse como:dist : Ω d xΩ d → R +JP2011-113

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011donde Ω d es el espacio de representación de los datosy d la dimensionalidad del mismo.Una distancia debe cumplir los siguientes requisitos:Reflexividad: ∀x ∈ Ω d , dist(x, x) = 0Simetría: ∀x, y ∈ Ω d , dist(x, y) = dist(y, x)Desigualdad triangular: ∀x, y, z ∈ Ω d , dist(x, y) ≤dist(x, z) + dist(z, y)Si el espacio de representación usado no es un espaciométrico, entonces es suficiente con que la medidade comparación cumpla con los dos primeros.Debido a que las medidas pueden ser diversas,cuando comparemos dos objetos, nos referiremossimplemente a proximidad, y la denotaremos por Ψ,por lo que se cumple que:∀x, y, z ∈ Ω d , Ψ(x, y) < Ψ(x, z) → sem(x, y) >sem(x, z)∀x, y, z ∈ Ω d , Ψ(x, y) < Ψ(x, z) → dif(x, y)

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo 1 GenerarGrafo(O p , θ)Entrada: O p : subconjunto de vectores a indexar, θ:número mínimo de vecinos directos de cada vérticeen el grafo final.Salida: G p : grafo que indexa a los vectores de entrada.Etapa1. Cálculo del centroide del subconjunto.Se obtiene un nuevo vector como resultado desumar todos los vectores del conjunto dimensiónpor dimensión. El vector resultante tiene valormayor que cero en todas las dimensiones del espaciode representación de este subconjunto.Etapa 2. Descomposición del subconjuntoen una lista ordenada de subconjuntos porsu proximidad con el centroide.A partir de los elementos del subconjunto se obtieneuna lista ordenada en orden decreciente deproximidad con el centroide del subconjunto.Esta lista es dividida en un número predefinido desublistas, que quedarán ordenadas por la proximidadde sus elementos con el centroide.Etapa 3. Construcción del grafo conexo.De los elementos de la primera sublista, se calculael par de elementos más próximos entre sí. Estoselementos forman la primera arista del grafo.Del resto de los elementos de la sublista se calculael elemento que al ser conectado a un par devértices de cualquier arista del grafo provoca elmenor crecimiento en área de esta.Este proceso se repite hasta que todos los elementosde la sublista son conectados al grafo.Los dos pasos anteriores son repetidos para el restode las sublistas, hasta que todos los elementos dela lista original estén conectados en el grafo.Etapa 4. Completar el grafo hasta que cadavértice tenga θ vecinos.En esta etapa se verifica que cada vértice formeparte como mínimo de una cantidad predefinida dearistas. En caso que se detecte un vértice que nocumpla esta condición el mismo es conectado connuevos vecinos más próximos hasta que se cumplala condición.Etapa 5. Calcular los vértices de entrada algrafo.Se determinan aquellos vértices que cumplen quetodos los vértices con los que conforman aristasestán más próximos que estos al centroide del subconjunto,y aquellos vértices que cumplen que todoslos vértices con los que conforman aristas estánmenos próximos que estos al centroide del subconjunto.Finalmente se genera una estructura que contieneal conjunto de vértices (O p ), al conjunto de aristas(A p ) y al conjunto de los vértices identificadoscomo de entrada al grafo (E p ).return G p = (O p , A p , E p ).Algoritmo 2 BuscarKPróximos(R, G, q, k)Entrada: R, el repositorio de objetos iniciales; G =G 1 , G 2 , ..., G N , la lista de los grafos obtenidos medianteel Algoritmo 1; q, el objeto de consulta; yk, el número de soluciones requeridas.Salida: Los k objetos de R más próximos a q segúnΨ.Sea −→ v = ζ(q) la representación vectorial de q.Sean G i = G[i], O i = G i [1],A i = G i [2] y E i =G i [3].Sean S ′= ∅ y N = |G|.for i = 1 → N doSea S i = {( −→ o j,p , ψ j,v )/ −→ o j,p ∈ O i , ψ j,v =Ψ( −→ o j,p , −→ v )}, obtenido mediante kNN(G[i], −→ v ,k)(Algoritmo 3).= S ′ ∪ S iend forSea S ′′ la lista de los elementos de S ′ ordenadade mayor a menor según el valor de ψ j,v de cadaelemento.Sea S = {S ′′ [1], S ′′ [2], ..., S ′′ [k]} las k solucionesmás próximas al objeto de consulta.return {r j /r j ∈ R, r j = ˜ζ(o i,p ), (o i,p , ψ i,v ) ∈ S}.S ′altamente dispersos, con un número suficientementegrande de estos la carga de trabajo de los procesadorestiende a equilibrarse ”de manera natural”.D. Paralelización de las consultasEl proceso de buscar las soluciones parciales queaporta cada grafo al resultado de una consulta escompletamente independiente para cada uno de ellos.Posteriormente es necesario combinar estas solucionesparciales para obtener la solución final, procesoque sigue siendo de naturaleza secuencial y essimilar al descrito para la versión secuencial.Los cambios con respecto al Algoritmo 2 sonmostrados en el Algoritmo 4. Notese que el buclefor se ejecuta en paralelo por todos los procesadoresinvolucrados. Se ha incluido además una seccióncrítica para evitar que más de un proceso actualice elconjunto S ′en el mismo instante, lo que provocaríainconsistencias en el mismo.IV. Análisis experimentalA. Entorno experimentalPara realizar nuestros experimentos usamos unrepositorio de la agencia Reuters con los textos deun gran número de noticias cortas en prensa: lacolección Reuters corpus versión 1 (RCV1-v2) [7].El vector de características −→ o i de cada documentor i fue producido mediante la concatenación de lostextos en los elementos y de losXML originales. El texto fue reducido a caracteresen minúsculas, después de lo cual se realizó sobre losmismos un proceso de tokenización, eliminación depuntuaciones y estemizado. Se eliminaron las palabrasde parada, se sopesaron los términos y finalmentelos pesos fueron normalizados, tras realizaruna selección de características.JP2011-115

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo 3 Función kNNEntrada: G i , estructura de indexado; −→ v , el vectorde consulta; k, la cantidad de soluciones requerida.Salida: KNN, los k objetos más próximos a −→ v .{Determinando los vértices de entrada}.Sean G i = G[i], O i = G i [1],A i = G i [2] y E i =G i [3].Sea S ′= −−→ o k1 ,i, −−→ o k2 ,i, ..., −−−→ o k|S| ,i la lista de elementosde E i , ordenada en orden decreciente de su proximidada −→ v .Sea α ∈ {1, ..., |S|} una constante predefinidaque determina del conjunto S el número real devértices que serán usados como puntos de entradaa la estructura de indexado.{Búsqueda del vecino más próximo a −→ v }.Sea NN = [] una lista vacía.for e = 1 → α do−→ s0 = S ′ [e].repeatSea L la lista ordenada de los elementos de{ −→ o j,i / −→ o j,i ∈ G i , ( −→ s 0 , −→ s j,i ) ∈ A i } en orden decrecientede su proximidad a −→ v .if Ψ(L[1], −→ v ) > Ψ( −→ s 0 , −→ v ) then−→ s0 = L[1].end ifuntil Ψ(L[1], −→ v ) ≤ Ψ( −→ s 0 , −→ v )NN[e] = −→ s 0 .end forOrdenar los elementos de NN en orden decrecientede su proximidad a −→ v .kNN = NN[1].{Búsqueda de los siguientes (k − 1) vecinosmás próximos a −→ v }if k > 1 thenkNN = kNN ∪ { −→ o j,i / −→ o j,i ∈ G i , ( −→ s 0 , −→ o j,i ) ∈ A i }.repeatSea L la lista ordenada de los elementos dekNN en orden decreciente de su proximidada −→ v .Sea L ′ = L[1], L[2], ..., L[t] tal que t =min(k − 1, |L|).kNN = { −→ o j,i / −→ o j,i ∈ L ′ }.Sea ρ = Ψ(L[t], −→ v ) la mínima proximidad entrelos elementos de L ′ y −→ v .for p = 1 → t doSea H p = { −→ o j,i / −→ o j,iA i , Ψ( −→ o j,i , −→ v ) ≥ ρ)}Sea kNN ′ = kNN ∪ H p .end forkNN = kNN ′ .∣until ( ∣kNN ′∣ ∣ ′ ≥ k) ∧ (kNN = kNN)end ifreturn kNN.∈ G i , (L ′ [p], −→ o j,i ) ∈Algoritmo 4 BuscarKPróximosPar(R, G, q, k){...}for i = 1 → N do {en paralelo}Sea S i = {( −→ o j,p , ψ j,v )/ −→ o j,p ∈ O i , ψ j,v =Ψ( −→ o j,p , −→ v )}, obtenido mediante kNN(G[i], −→ v ,k)(Algoritmo 3).Sección crítica: S ′= S ′ ∪ S iend for{...}Se usó de la partición LYRL2004 su conjunto deentrenamiento que contiene 23.149 vectores. El espaciode representación de este conjunto tiene 47.152dimensiones. La matriz de representación de este espaciocontiene una gran número de ceros, debidos ala alta dispersión de los vectores.Todos los experimentos fueron realizados sobre unmultiprocesador SGI Altix 350 con memoria compartida.Esta máquina tiene 8 nodos, cada uno delos cuales tiene 2 procesadores Intel Itanium2, a 1.5GHz. Cada nodo cuenta con 4Gb de memoria localconectadas mediante una red SGI NUMAlink, llegandoa 32 GBytes de memoria compartida.Todos los algoritmos fueron implementadosusando lenguaje C, y fueron compilados con ICC9.0 sobre el sistema operativo Linux. Las versionesparalelas fueron implementas usando la interfazOpenMP.B. Resultados experimentalesPara estudiar el comportamiento de nuestra propuestase generó, para los esquemas secuencial y paralelo,un gran número de estructuras de indexadocon diferentes números de grafos. Para seleccionar elvalor de θ se generaron grafos usando valores entre 10y 90. Finalmente seleccionamos el valor de 50 por serel que garantizó un mejor equilibrio entre la calidadde los resultados y la selectividad del método.Los resultados fueron obtenidos mediante latécnica de validación cruzada 10-fold-cross validation,por lo que se procesaron 10 repositorios distintos.Los valores experimentales mostrados son lospromedios de los obtenidos para cada repositorio.Por cada experimento medimos el coste temporalde la generación de la estructura de indexado para20.000 objetos, el coste temporal de 2.300 consultas,el consumo de memoria principal, la selectividad y ladimensionalidad de cada espacio de representación.La asignación de objetos a los subconjuntos dedatos fue realizada de manera aleatoria.C. Precisión de los resultadosEl primer primer aspecto estudiado fue la calidadde los resultados obtenidos durante las consultas.Los comparamos con los obtenidos con el métodoexhaustivo, que garantiza las soluciones exactas.La Figura 1 muestra que la exactitud de los resultadosse incrementa con el número de grafos usados.El incremento fue desde el 92% de soluciones exactaspara un grafo hasta casi el 97% para 16.JP2011-116

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Precisión de los resultados comparados contra losobtenidos mediante el método exhaustivo.D. Selectividadtra, a medida que se usan más grafos para indexarel repositorio, el tamaño máximo de los espacios derepresentación disminuye. Esto se debe a que cuantosmás grafos son usados, los subconjuntos de datoscontienen menos elementos, y debido a la dispersiónde los datos, van a contener en conjunto menos dimensiones.Esto es así porque aumenta la probabilidadde que en cada submatriz de representación, quecontiene de la matriz original solamente aquellas filasde los vectores que le pertenecen, exista una grancantidad de columnas con todos los valores a 0, encuyo caso esa dimensión del espacio original no setiene en cuenta.La Figura 3 muestra que la máxima dimensionalidaddel espacio de representación disminuyedesde aproximadamente 50.000 dimensiones hastacasi 14.000, cuando se varía el número de grafosdesde 1 hasta 16. Es necesario notar que el problemageneral mantiene siempre la misma dimensionalidad,pero las dimensiones son repartidas de maneraaleatoria entre los grafos. Una misma dimensiónpuede aparecer en más de un grafo.F. Coste temporal de la generación de los grafosFig. 2. Número de objetos evaluados como promedio durantelas consultas, variando el tamaño del repositorio.Como se aprecia en la Figura 2, el número promediode objetos comparados durante las consultasse va estabilizando a medida que se incrementa eltamaño del repositorio, por lo que la selectividad delmétodo crece en igual medida.E. Dimensionalidad del espacio de representaciónFig. 4. Coste temporal para generar los grafos en la variantesecuencial.La Figura 4 muestra el coste temporal cuando losgrafos son generados de manera secuencial, variandoel número de grafos desde 1 hasta 16. Para la versiónparalela usamos, de modo natural, la misma cantidadde procesadores que de grafos generados.Fig. 3. Dimensionalidad máxima obtenida para los espaciosde representación, variando el número de grafos usados.Para analizar la dimensionalidad del espacio derepresentación de cada problema usamos el tamañode los centroides de cada grafo, y tomamos en cadacaso el mayor valor. Por ejemplo, cuando usamosun solo grafo tomamos el tamaño de su centroide,pero cuando generamos más de un grafo medimos eltamaño del centroide de cada grafo y mostramos elmayor valor.La tendencia seguida por la dimensionalidad delespacio es mostrada en la Figura 3. Como se mues-Fig. 5.Aceleración optenida con la versión paralela.La Figura 5 muestra la aceleración optenida conla versión paralela de generación de los grafos. Estamuestra además que se han obtenido superaceleracionesen casi todos los casos. Esto se debe al mejorJP2011-117

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011uso de la estructura de la memoria cuando se usanvarios procesadores que cuando se usa uno solo.G. Consumo de memoria por los grafosFig. 6. Consumo de memoria principal, variando el númerode grafos.La Figura 6 muestra la cantidad de memoria necesariapara almacenar los grafos. Los valores son losmismos tanto para la versión secuencial como parala paralela.Los resultados demuestran que el consumo dememoria se incrementa poco a medida que son usadosmás grafos para indexar el repositorio. Esteincremento lento se debe a que cuantos más grafosson usados cada uno de estos contiene menos objetos,pero cada grafo aporta un consumo adicional debidoa que al mantener la cantidad de vecinos de cadaobjeto igual a θ en cada grafo, el número global deenlaces se incrementa. Además, para cada grafo sealmacena un conjunto de objetos de entrada.H. Coste temporal de las búsquedasFig. 7. Coste temporal para generar los grafos en la variantesecuencial.La Figura 7 muestra el promedio del coste temporalnecesario para evaluar una consulta, variandoel número de grafos, tanto para la versión secuencialcomo para la paralela.Se puede observar que este coste se incrementaa medida que crece el número de grafos. Estoes debido a que se necesita, entre otros aspectos,evaluar un número mayor de vértices de entrada.También se observa que este incremento disminuyedrásticamente en la versión paralela, debido a que sinimportar el número de grafos usados, las consultas acada grafo se solapan en el tiempo. En este caso,el incremento del coste temporal se debe fundamentalmentea la pequeña sección secuencial remanente,en la que se obtiene el resultado final a partir de losparciales obtenidos para cada grafo.V. Conclusiones y trabajo futuroHemos presentado un método de acceso para espaciosde muy alta dimensionalidad basado en el usode multiples grafos como estructura de indexado. Laestrategia de búsqueda que utiliza, aunque da lugara soluciones aproximadas, lo hace con un nivel de errorbajo y con una alta selectividad. Esto provocabajos costes temporales durante las consultas.Como hemos observado a medida que se usan másgrafos en la estructura de indexado la precisión delmétodo se incrementa, aunque el coste temporal delas consultas se incrementa un poco.La estructura de indexado se ha elegido además,porque permite su construcción y utilización en paralelode forma sencilla y eficiente. Los resultados experimentalesdemuestran que se obtienen muy buenasprestaciones con la versión paralela de ambosprocesos.Como trabajo futuro explotaremos las característicasde arquitecturas híbridas, con la combinacióndel uso de memoria compartida y distribuida.AgradecimientosEl presente trabajo ha sido financiado por el DepartamentoIngeniería y Ciencia de los Computadoresde la Universidad Jaume I, Castellón.Referencias[1] H. Samet, Foundations of Multidimensional and MetricData Structures. Morgan Kaufman, ISBN 0123694469,2006.[2] Cortizo, J.C., Giráldez, J.I., Multi criteria wrapper improvementsto naive bayes learning. LCNS, Vol. 4224,2006.[3] Berchtold, S. et al., Independed quantization: an indexcompression technique for high-dimensional data spaces.ICDE’00, pp. 577–588, 2000.[4] Zhenjie Zhang and Beng Chin and Ooi Srinivasan andParthasarathy Anthony and K. H. Tung, Similarity searchon bregman divergence: Towards non-metric indexing, InVLDB, 2009.[5] Ro J. S. Dutra and William A. Pearlman and Eduardo A.B. Da Silva and Senior Member, Successive ApproximationWavelet Coding of 1 AVIRIS Hyperspectral Images, 2010.[6] Edgar Chavez, Karina Figueroa y Gonzalo Navarro, EffectiveProximity Retrieval by Ordering Permutations. IEEETransactions on Pattern Analysis and Machine Intelligence(TPAMI). Vol. 30 No. 9. pp 1647-1658, 2007.[7] Lewis, D. D. et al., RCV1: A new benchmark collection fortext categorization research, Journal of machine learningresearch, num. 5, pp. 361-397, 2004.JP2011-118

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Perceptually enhanced INTRA video encoderfor high definition/quality servicesM. Martínez-Rach, O. López, P. Piñol, M. Perez Malumbres 1 andJ. Oliver 2Resumen— Although inter video coding gets thehighest R/D for general video coding, intra encodersare of particular interest for some applications. Wepropose a simple perceptually enhanced intra-modevideo encoder (PM-LTW) based on the ContrastSensitivity Function (CSF) that gets good performanceby allowing a gracefully quality degradationas compression rate increases. We evaluated theperformance in terms of perceptual quality, memoryconsumption and complexity with H.264/AVC intra,Motion-JPEG2000 and Motion-SPIHT. We employedthe Visual Information Fidelity (VIF) image QualityAssessment Metric (QAM) as video quality metric.The results show that the proposed encoder is competitivewith respect to H.264/AVC at low to mediumcompression rates, and as video resolution increases,it outperforms H.264/AVC. In addition it requiresmuch less memory and exhibits fast encoding rates.Palabras clave— High Definition Video Coding, PerceptualCoding, Contrast Sensitivity FunctionI. IntroductionALTHOUG the use of motion-estimation (interframecoding) achieves much better R/D whencompared to intra-frame coding, there are severalapplications that requires a intra-frame coding approach.Most of the television content productionsrequire recordings in HD to maintain high qualityof picture even though the final transmission is inSD (standard definition) format and after professionalvideo editing processes, where random and frequentframe access and edition is performed. Intraframecoding is desirable as well in many other applicationslike video archiving, high-quality highresolutionmedical and satellite video sequences, applicationsrequiring simple real-time encoding likevideo-conference systems where very low delay is desirableor even for professional or home video surveillancesystems [1] and Digital Video Recording systems(DVR), where the user equipment is usually notas powerful as the headend equipment. So, for theseapplications, computing capability, limited memoryresources and real-time constraints need to be takeninto account. Many wireless applications often useintra coding technologies which exhibits an excellenterror resilience behavior at the price of higher bitrates.The strength of an intra-video coding systemrelies on the ability to efficiently exploit the spatialredundancies of each video sequence frame avoidingcomplexity in the design of the encoding/decodingengines.1 Departament of Physics and Computer Engineering,Miguel Hernandez University - Elche - Spain, e-mail:{mmrach,otoniel,pablop,mels}@umh.es.2 Departament of Computer Engineering, Polytechnic Universityof Valencia - Spain, e-mail: joliver@upv.esIn the context of image and video compression, themost reliable way of measuring the perceived qualityis by performing subjective quality tests. Such subjectivetests were standardized by the Video QualityExperts Group (VQEG) [2]. The Mean OpinionScore (MOS) is a subjective quality metric obtainedfrom a number of human observers, has beenregarded for many years as the most reliable formof quality measurement, and the procedure for doingsuch experiments has been standardized [3]. However,the MOS method is too cumbersome, slow andexpensive for most applications.Many research has been done in order to obtainobjective image and video image QAM based on theknowledge of how our Human Visual System (HVS)perceives quality. QAM are valuable because theyprovide video encoder designers and standard organizationswith means for making meaningful qualityevaluations without convening viewer panels. Themost commonly used quality metric is the PSNRsince it is simple and fast to calculate. HoweverPSNR does not always capture the distortion perceivedby the HVS. In terms of correlation to humanperception it would be preferable to use the MOSvalue as QAM when performing R/D comparisonsbut it would be too cumbersome. Some studies beginto present their results by means of quality assessmentmetrics like MSSIM [4] and VIF [5].Image and video encoders have included much ofthe knowledge of our HVS in the way they processin order to obtain a better perceptual quality of thecompressed sequences. The most widely used characteristicis the contrast adaptability of the HVS.HVS is more sensitive to contrast than to absoluteluminance. The Contrast Sensitivity Function (CSF)relates the spatial frequency with the contrast sensitivity.We propose a intra perceptual video encoder, PM-LTW, based on LTW image codec [6] with the inclusionof CSF in the wavelet transform stage, optimizedand tuned to work at moderate to good video qualitylevels. We propose the use of a CSF weighting matrixapplied to wavelet subbands that preservers a verygood balance between bit-rate and perceptual qualityin all the quantization range. As quality metricfor R/D comparisons, we propose to use the VIF (VisualInformation Fidelity) QAM [7] which has beenproven [8] [9] to have a better correlation with subjectiveperception than other metrics that are usuallyused for this types of comparisons [10] [4]. Weperform a comparison of the PM-LTW perceptualperformance with other intra tuned coding proposalsJP2011-119

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011like H264/AVC, Motion-JPEG2000, Motion-SPIHTand x264.The rest of the paper is organized as follows. Insection II we introduce some advantages of intra coding,in section III we describe how to include the CSFin the encoding process and in section IV we discussabout the convenience of using quality assessmentmetrics. In Section V we describe the codec versionsincluded in the comparison against PM-LTW and weexplain the methods followed to perform the comparisonas well as the results presented, and finally insection VI some conclusions are drawn.II. Advantages of Intra-CodingInter-frame coding uses temporal correlation ofpictures to generate lower bit-rates than intra codingschemes, assuming that the content of successiveframes is similar. When this assumption fails,for example in videos of “still-camera” strobes, fastmotion sport sequences, quick zooms and pans, specialeffects or sequences with short duration eventsand high motion, then the bit-rate savings would bereduced, approaching to bit-rates produced by theintra coding option. Furthermore, the compressiondelay coding in intra mode is much lower than theone produced in inter coding, what should be takeninto account for interactive IPTV applications.In video content editing applications, accessingrandom frames would be natural for intra codingschemes, while inter coding would require decodingseveral frames. Moreover, the quality of reconstructedframes depends only of the frame itselfavoiding error propagation between frames thatwould be considerable when previous frames or partof them are lost or with errors. This also leads to alower degradation of the edited video when multipleeditions of the same sequence are done.Parallel processing is another field where intra codingcan take advantage, since inter coding definesmore data dependencies that causes parallel programmingto be complex and less efficient. Intra onlycompression is very suitable with parallel processingarchitectures, i.e. multi core CPUs, or GPUs.In [11] an experimental study was performed withH.264/AVC and JPEG2000 in order to determine thebenefits of the use of inter frame encoding versus intraframe encoding for Digital Cinema applications.Their results draw that the coding efficiency advantagesof inter frame coding are significantly reducedfor film content at the data rates and quality levelsassociated with digital cinema. This indicatesthat the benefit of inter frame coding is questionable,because it is computationally much more complex,creates data access complications due to the dependenciesamong frames and in general demands moreresources. For lower resolutions their experimentsconfirms that inter frame coding was more efficientthan intra frame coding. These results provide a justificationfor using JPEG2000, or other intra framecoding methods, for coding digital cinema content.Fig. 1.Contrast Sensitivity FunctionIII. Contrast Sensitivity FunctionHVS research offers mathematical models of humanperception. A comprehensive review of HVSmodelsfor quality assessment/image compression isfound in [12]. Most of these models account for thevarying sensitivity over spatial frequency, color, andthe inhibiting effects of strong local contrasts or activity,called masking. Complex HVS-models implementeach of these low level visual effects as a separatestage. Then the overall model consists of thesuccessive processing of each stage. One of the initialHVS stages is the visual sensitivity as a function ofspatial frequency that is described by the CSF.A closed form model of the CSF for luminanceimages [13] is given by:H(f) = 2.6(0.0192 + 0.114f)e −(0.114f)1.1 (1)where spatial frequency is f = (fx 2 + f y 2)1/2withunits of cycles/degree (f x and f y , are the horizontaland vertical spatial frequencies). The frequency isusually measured in cycles per optical degree (cpd),which makes the CSF independent of the viewingdistance.Figure 1 depicts the CSF curve obtained withequation 1, it characterizes luminance sensitivity asa function of normalized spatial frequency. CSF isa bandpass filter, which is most sensitive to normalizedspatial frequencies between 0.025 and 0.125 andless sensitive to very low and very high frequencies.The reason why we can not distinguish patterns withhigh frequencies is the limited number of photoreceptorsin our eye. CSF curves exist for chrominanceas well. However, unlike luminance stimuli, humansensitivity to chrominance stimuli is relatively uniformacross spatial frequency. The work of [13] wasone of the first where it was demonstrated that theMSE cannot reliably predict the difference of the perceivedquality of two images. They propose, by theway of psychovisual experiments, the aforementionedmodel of the CSF, that is well suited and widely used([14][15][16][17]) for wavelet based codecs, thereforewe adopt this model.JP2011-120

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA I50Proposed CSF Weighting matrix48LL LH HH LHL1 1.0 1.1795 1.0000 1.7873L2 1.0 3.4678 2.4457 4.8524L3 1.0 6.2038 5.5841 6.4957L4 1.0 6.4177 6.4964 6.1187L5 1.0 5.1014 5.5254 4.5678L6 1.0 3.5546 3.9300 3.1580PSNR4644424038363432PM_LTWMJASPERMSPHITX264H2643028The granularity of the correspondence between frequencyand weighting value is a key issue. As waveletbased codecs obtain a multiresolution signal decompositionthe easiest association is to find a uniqueweighting value for each wavelet frequency subband.If further decompositions of the frequency domainare done, for example by the use of packet waveletsa finer association could be done between frequencyand weights [18]. The most common way of implementthe CSF curve in wavelet based codecs is by theuse of an Invariant Scaling Factor Weighting [19].In [20], subjective experiments were performed obtaininga model to express the threshold DWT noiseas a function of spatial frequency. Using this modelauthors obtain a perceptually lossless quantizationmatrix for the linear-phase 9/7 DWT. By the use ofthis quantization matrix each subband is quantizedby a value that adjust the overall resulting quantizedimage at the threshold of artifacts visibility.For supra-threshold quantization a uniform quantizationstage is afterwards performed.In [21] authors argued that fixing the quantizationmatrix for at-threshold visibility and then performa uniform quantization to reach a desired bit-ratein the supra-threshold range does not guarantee topreserve the best perceptual quality for the resultingimage. They propose an iterative rate/distortionprocess based on the relationship among contrastof resulting image and the MSE. Again subjectivesupra-threshold experiments were performed for establishinghow the overall contrast sensibility is affectedby supra-threshold quantization impairmentsin each individual wavelet subband.We perform an ISFW implementation of the CSFbased on [14] but increasing the granularity at thesubband level. So we scale the wavelet coefficientsbefore a uniform quantization stage. We obtain theweighting matrix of Table I directly from the CSFcurve (unlike [20] and [21]), by normalizing the correspondingvalues so that the most perceptually importantfrequencies are scaled with higher values,while the less important are preserved. This scalingprocess augment the value of all wavelet coefficients(except LL subband) and therefore the overall bitrateneeded for the transmission of the scaled versionof the image. Our tests reveal that thanks tothe weighting process, the oncoming uniform quantizationstage preserves a very good balance betweenbit-rate and perceptual quality in all the quantizationrange.VIF261.000.950.900.850.800.750.700.650.600.550.500.450.400.350.300.2550010001500200025003000350040004500Bitrate Kb/s500055006000PM_LTWMJASPERMSPIHTX264H264Fig. 2. R/D comparative PSNR and VIF results for ContainerCIF sequenceIV. The use of Quality Assessment MetricsUpper panel of Figure 2 show the PSNR R/D resultsfor the Container CIF sequence of all evaluatedcodecs. While looking at these results, a first conclusioncould be that the algorithms or improvementsincluded in the PM-LTW encoder do not performwell and should be discarded because the quality differencesare too high for any rate. For example, focusingat 3458.15 Kb/s (1.13 bpp) the difference betweenH.264/AVC and PM-LTW is up to 3.32 dB. Infigure 3 the frame number 20 of the Container CIFsequence is presented at this rate for H.264/AVC andPM-LTW. After having a look at these two framesthe difference of 3.32 dB seems too high, that is, oneexpects more visual difference for a numeric distanceof 3.32 dB.Therefore we can not trust how PNSR ranks quality.We need a quality metric on which rely. Lowerpanel of figure 2 the quality is measured in termsof the VIF QAM, the previous conclusion that discardedthe PM-LTW encoder is compromised. Althoughquality assessment metrics are not foolproof,the objective quality values for both encoders are notas distant as before, being this distance closer to theperceived one. Assuming that a quality assessmentmetric is based on a fitting process over a set of MOSvalues, it is worth to use such a metric for comparisonsof different encoder proposals.6500V. Performance AnalysisAll the evaluated encoders working in intra codingmode have been tested on an Intel Pentium Core2 CPU at 1.8 GHz with 6GB of RAM memory.We have selected H.264/AVC (High-10, JM16.1),700075008000JP2011-121

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) PSNR=37.49 dB Bit-rate=3458.15 Kb/s(b) PSNR=41.19 dB Bit-rate=3690.42 Kb/sFig. 3. Frame 20 of the container sequence encoded with a)PM-LTW and b) H.264/AVC INTRATABLA IIQuality levels lower thresholdsLower Thresholds CIF & QCIF ITU & HDVisually lossless 0.93 0.90Excellent 0.87 0.85Good 0.80 0.75Acceptable 0.70 0.60Motion-JPEG2000 (Jasper 1.701.0), Motion-SPIHT(Spiht 8.01), x264 (FFmpeg version SVN-r25117,profile High, level 4.0) and our PM-LTW.The main parameters used for the H264/AVCJM16.1 are: Profile ID: 110; Level ID: 4.1 (forQCIF and CIF) and 5.1 for (ITU and HD1080);IntraProfile: 1; IntraPeriod: 1; IDRPeriod: 1;GrayScale: 1; RateControlEnable: 1; RCUpdate-Mode: 1; CABAC.The main parameters used for the X264 Softwareare: -intra; -pix fmt yuv420p; -vf ”format=gray”; -fpre ”libx264-hq.ffpreset”The test video sequences used in the evaluationare: Foreman, Hall, Container, News, Mobile andPedestrian area. Resolutions were QCIF, CIF, ITU576 and HD 1024.The rates, timing and the distortion values(PSNR) were obtained from the corresponding codeclog file. For getting the memory consumption values,we used the VMMap Sysinternals tool. The frameVIF value was obtained with the matlab VIF sourcecode that can be downloaded from authors web page[22].While comparing encoder proposals it is commonto work within a bit-rates and quality workingranges. As we will focus in perceptual qualitiesstated by users as good and above, first we have to establishthe quality working ranges by means of VIFvalues. We did a simple subjective test with fourobservers in order to define five quality levels, “Visuallylossless”, “Excellent”, “Good”, “Acceptable”and “Bad”. For each sequence, the uncompressed sequenceis present as reference to the viewer togetherwith a sequence compressed at a different bit-rateeach time. Viewers had no knowledge of the bitratebeing evaluated but they know which one is theuncompressed image. They set for each sequence avalue ranging from 0 to 4 with steps of 0.2 points. Avalue of 0.0 is given when the viewer does not detectany differences between the two sequences. A valueof 1 is the lower threshold for the “Excellent” level,being 2 and 3 the corresponding lower thresholds for“Good” and “Acceptable”. When users rank a sequencewith a value higher than 3, this means thatthis sequence is in the “Bad” level. Our study willfocus only on the first four levels, from “Visuallylossless” to “Acceptable”.The subjective test to determine the five qualitylevels was run using different video sequences withdifferent formats and the video codecs defined above.In order to properly choose the video sequences forthe test, we used the encoder that offers the bestR/D behavior, in terms of the VIF quality metric,for each sequence. After analyzing the resultingdata, the VIF value thresholds are obtained foreach level. From the raw data, we detected that observersset the thresholds for each level around differentVIF values depending on the picture size. Forexample, when picture size was CIF or QCIF thelower threshold for the “Good” level was set around0.80 VIF units, but at higher picture sizes it was setaround 0.75 VIF units. In the same way, for smallsize sequences the lower threshold for the “Acceptable”level was set around 0.70 VIF units while forlarger sequences it was set around 0.60 VIF units.Table II resume these values.Figure 4 shows the VIF R/D curve for the HD1080“Pedestrian area” sequence. Regardless of the codec,points of curves with quality values over 0.90 VIFunits could be considered perceptually the same. Focusingon the “Visually lossless” level (above 0.90VIF units) in figure 4, the key issue is then, at whichbit-rate one codec reaches this level and if a bit-ratesaving is obtained by using one codec or another.As previously mentioned, for the “Visually lossless”level all the sequences seem to be the same. The rawvalues told that there is a bit-rate saving (around an8.9%) when using PM-LTW at 56 Mb/s (0.93 VIF)instead of using X264, because for getting the sameVIF quality it needs 61.7 Mb/s. But this, althoughmatematically correct, is not from a perceptual pointof view. In this case, if we reduce the bit-rate for theX264 codec up to 56 Mb/s we get a VIF value of91.6 units, which falls in the same level, being there-JP2011-122

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIIAverage bit-rate savings while comparing the use ofPM-LTW with studied codecs for each quality levelPM-LTW vs QCIF CIF ITU-D1 HDM-JPEG2000Vis. Lossless 7.32% 9.26% 11.88% -Excellent 6.59% 4.03% 10.33% 42.48%Good 7.58% 2.93% 9.05% 17.59%Acceptable 9.08% 4.38% 9.02% 4.51%M-SPIHTVis. Lossless 12.13% 13.76% 19.84% 37.59%Excellent 12.04% 12.82% 18.28% 36.63%Good 12.70% 12.58% 16.32% 31.34%Acceptable 13.15% 12.77% 14.94% 22.87%x264Vis. Lossless -1.68% -1.96% 16.11% 12.11%Excellent -2.51% -2.32% 15.41% 14.09%Good -3.61% -2.63% 14.48% 17.02%Acceptable -5.04% -2.94% 13.98% 19.42%H.264Vis. Lossless -3.04% -2.05% 12.80% 17.86%Excellent -4.97% -4.05% 6.50% 16.68%Good -7.63% -6.72% -2.31% 11.23%Acceptable -10.59% -9.27% -9.06% 2.92%VIF0,980,960,940,920,900,880,860,840,820,800,780,760,740,720,700,680,660,640,620,60PM_LTWMJASPERMSPIHTX264H2641013161922252831343740434649525558616467707376798285Bitrate in Mb/sFig. 4. R/D by means of VIF for the Pedestrian Area HD1080sequencefore indistinguishable form the PM-LTW encoded sequence.So, in this case, no advantage of the use ofPM-LTW is obtained, because the same saving couldbe obtained with the x264 encoder. For getting areal bit rate saving in this level by the use of one encoderinstead of another, both encoders must reachthe “Visually lossless” quality level lower thresholdat different rates.For the rest of levels, the curves corresponding tothe different codecs can not be assumed to be perceptuallythe same, because there were viewers thatperceived some differences between values inside thesame interval. Table III shows the relative bit-ratesavings that in average can be achieved for each ofthe defined quality levels. When comparing our proposalwith Motion-JPEG2000 or Motion-SPIHT andregardless of the frame size and quality level, bit-ratesavings are always achieved. The trend is that thesaving increases with frame size. When focusing inx264 and H.264 and at QCIF and CIF sizes, theiraveraged values for all sequences give a better performancefor all the defined quality levels, being thisTABLA IVTiming differences between PM-LTW & M-LTW due toPerceptual Enhancement (Average frame time inmilliseconds)D Wavelet Coding TotalPM-LTWCIF 3091.9 Kb/s 3.35 12.41 15.76ITU 9113.8 Kb/s 12.24 37.03 49.27HD 45471.3 Kb/s 92.38 231.00 323.37M-LTWCIF 3091.9 Kb/s 3.05 13.36 16.41ITU 9113.8 Kb/s 11.05 41.96 53.01HD 45471.3 Kb/s 85.64 264.64 350.28DifferencesCIF 3091.9 Kb/s 0.30 -0.95 -0.65ITITU 9113.8 Kb/s 1.19 -4.93 -3.74HD 45471.3 Kb/s 6.74 -33.64 -26.910)(log10ames/sec Fra10001001010QCIF(30Hz)at25.6Kb/frameCIF(30Hz)at103.0Kb/frameITU(640X512)(30Hz)at303.7Kb/framePM-LTWM-LTWM-SPIHTM-JPEG 2000X264H264/AVCHD(1920X1024)(25Hz)at1818.8Kb/frameFig. 5. Maximum frame rates in log scale for the differentframe sizessavings greater for H.264 than for x264 in all levels.Looking at ITU video size the PM-LTW performanceincreases as the quality level becomes higher. Whencomparing with x264, PM-LTW achieve lower bitratein all quality levels. However, the improvements withrespect H.264 are only achieved at “Excellent” and“visually Lossless” quality levels.Figure 5 shows the frame rate obtained by the differentencoders being evaluated. As shown, the PM-LTW outperforms the rest of the encoders for anysequence frame size. Regarding memory usage, inFigure 6 we can see the maximum amount in MBytesof the private memory working set needed for eachencoder and sequence size. The bit-rate used for eachresolution are 769.9 Kb/s, 3091.9 Kb/s, 9113.8 Kb/sand 45471.3 Kb/s for QCIF, CIF, ITU and HD respectively.PM-LTW is by far the one which lessmemory needs for all frame sizes. As frame size increasesthese differences are more important. Thismakes the PM-LTW very suitable to encode at highvideo resolutions.VI. ConclusionPM-LTW intra mode video codec is very competitivein terms of perceptual quality and outperformingthe rest of the evaluated encoders for high videoresolutions sequences. Since intra frame encodinghas some advantages over inter frame encoding fora set of applications the proposed encoder is a verygood option for these applications. The use of theVIF QAM instead PSNR in Rate/Distortion com-JP2011-123

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MBytes (log2 scale)5122561286432168421Fig. 6.1,78PM-LTWM_SPIHTM-JASPERX264H2642,302,615,128,022,073,713,956,5820,982,948,347,0710,4662,049,2139,2731,3231,63QCIF CIF ITU HD375,17Memory consumption comparison in MBparisons, reveals that our proposal performs perceptuallyvery good. This, in turn, verify the fact thatusing PNSR while comparing encoding proposals interms of R/D is not recommended, because it couldinduce to wrong conclusions. Our proposal includesthe well known Contrast Sensitivity Function afterthe wavelet transform stage of our encoder performinga perceptual weighting of the obtained waveletcoefficients. We proposed a weighting matrix thatgives a very good R/D behavior in all the bit-raterange. PM-LTW achieves important bit-rate savingsfor the same perceptual quality when comparedwith M-SPIHT or M-JPEG2000 for all the evaluatedsequence resolutions and quality levels. Whencomparing with X264 these savings occurs for theITU resolution but only in the Excellent and Visuallylossless quality levels. As resolution increasesup to HD our proposal achieves bit-rate savings forall the evaluated quality levels being the highest valuesfor the Visually lossless quality level. PM-LTWrequires much less memory than any other encoderbeing the differences higher as resolution increase.For HD resolution requires near 4 times less memorythan M-SPIHT, M-JPEG2000 and X264, and up to40 times less memory than H.264. In addition PM-LTW is also the fastest of the evaluated encodersbeing up to 2.3 times as fast as x264 and 28 times asfast as H.264/AVC intra.This makes PM-LTW a good choice for intra framecoding at high definition/resolution applications.AcknowledgmentThanks to Spanish Ministry of education and Scienceunder grant DPI2007-66796-C03-03 for fundingReferencias[1] Jang-Seon Ryu and Eung-Tea Kim, “Fast intra codingmethod of h.264 for video surveillance system,” IJCSNSInternational Journal of Computer Science and NetworkSecurity, vol. 7, no. 10, October 2007.[2] VQEG, “Final report from the video quality expertsgroup on the validation of objective models of video qualityassessment. phase II,” August 2003.[3] Recommendations of the ITU, Telecommunication StandardizationSector, “Objective perceptual video qualitymeasurement techniques for digital cable television in thepresence of a full reference,” Draft Revised RecommendationJ.144.[4] Z. Wang, A. Bovik, H. Sheikh, and E. P. Simoncelli, “Imagequality assessment: From error visibility to structuralsimilarity,” IEEE Transactions on Image Processing, vol.13, no. 4, 2004.[5] Hamid Rahim Sheikh, Alan Conrad Bovik, and Gustavode Veciana, “An information fidelity criterion forimage quality assessment using natural scene statistics,”IEEE Transactions on Image Processing, vol. 14, no. 12,2005.[6] J. Oliver and M.P. Malumbres, “Low-complexitymultiresolution image compression using wavelet lowertrees,” IEEE Transactions on CSVT, vol. 16, no. 11, pp.1437–1444, November 2006.[7] H. R. Sheikh and A. C. Bovik, “Image information andvisual quality,” Image Processing, IEEE Transactionson, vol. 15, no. 2, pp. 430–444, 2006.[8] M. Martinez-Rach, O. Lopez, P. Piñol, J. Oliver, andM.P. Malumbres, “A study of objective quality assessmentmetrics for video codec design and evaluation,”in Eight IEEE International Symposium on Multimedia,San Diego, California, Dec 2006, vol. 1, ISBN 0-7695-2746-9, pp. 517–524, IEEE Computer Society.[9] H. R. Sheikh, M. F. Sabir, and A. C. Bovik, “A statisticalevaluation of recent full reference image qualityassessment algorithms,” IEEE Transactions on ImageProcessing, vol. 15, no. 11, pp. 3440– 3451, 2006.[10] Francesca De Simone, Mourad Ouaret, Frederic Dufaux,Andrew G. Tescher, and Touradj Ebrahimi, “A comparativestudy of jpeg2000, avc/h.264 and hdphoto,” inProc. of Applications of Digital Image Processing XXX,San Diego, August 2007.[11] Michael Smith and John Villasenor, “Intra-frame jpeg-2000 vs. inter-frame compression comparison: The benefitsand trade-offs for very high quality, high resolutionsequences,” SMPTE Technical Conference and Exhibition,Pasadena, California, October 20-23 2004.[12] Marcus J. Nadenau, Stefan Winkler, David Alleysson,and Murat Kunt, “Human vision models for perceptuallyoptimized image processing – a review,” in PROC. OFTHE IEEE, 2000.[13] J. Mannos and D. Sakrison, “The effects of a visual fidelitycriterion of the encoding of images,” InformationTheory, IEEE Transactions on, vol. 20, no. 4, pp. 525 –536, July 1974.[14] A.P. Beegan, L.R. Iyer, A.E. Bell, V.R. Maher, and M.A.Ross, “Design and evaluation of perceptual masks forwavelet image compression,” in Digital Signal ProcessingWorkshop, 2002 and the 2nd Signal Processing EducationWorkshop. Proceedings of 2002 IEEE 10th, Oct.2002, pp. 88 – 93.[15] A. Gaddipati, R. Machiraju, and R. Yagel, “Steeringimage generation with wawelet based perceptual metric,”in Eurographics, 1997.[16] H. Rushmeier, G. Ward, C. Piatko, P. Sanders, andB. Rust, “Comparing real and synthetic images: Someideas about metrics,” in In Proc. 6th Eurographics Workshopon Rendering, Dublin, Ireland,, 1995, pp. 82–91.[17] Noureddine Moumkine, Ahmed Tamtaoui, and AbdellahAit Ouahman, “Integration of the contrast sensitivityfunction into wavelet codec,” in In Proc. Second InternationalSymposium on Comunications, Control and SignalProcessing ISCCSP, Marrakech, Morocco, March 2006.[18] Xinbo Gao, Wen Lu, Dacheng Tao, and Xuelong Li,“Image quality assessment based on multiscale geometricanalysis,” IEEE TRANSACTIONS ON IMAGE PRO-CESSING, vol. 18, no. 7, pp. 1409–1423, 2009.[19] Marcus J. Nadenau, Julien Reichel, and Murat Kunt,“Wavelet-based color image compression: Exploiting thecontrast sensitivity function,” IEEE TRANSACTIONSON IMAGE PROCESSING, vol. 12, no. 1, 2003.[20] Andrew B. Watson, Gloria Y. Yang, Joshua A. Solomon,and John Villasenor, “Visibility of wavelet quantizationnoise,” IEEE TRANSACTIONS ON IMAGE PRO-CESSING, vol. 6, no. 8, pp. 1164–1175, 1997.[21] D. M. Chandler and S. S. Hemami, “Dynamic contrastbasedquantization for lossy wavelet image compression,”IEEE Transactions on Image Processing, vol. 14, no. 4,April 2005.[22] Hamid R. Sheikh and Alan C. Bovik,“Image information and visual quality,”http://live.ece.utexas.edu/research/quality/VIF.htm.JP2011-124

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Equipo paralelo de metaheurísticas para laresolución de un problema real detelecomunicacionesJosé M. Chaves González 1 , Miguel A. Vega Rodríguez 1 ,Juan A. Gómez Pulido 1 y Juan M. Sánchez Pérez 1Resumen— En este artículo se presenta un estudio llevadoa cabo con una eficiente estrategia paralela aplicada a laresolución de un importante problema real dentro deldominio de las telecomunicaciones: el problema de laasignación automática de frecuencias (FAP –FrequencyAssignment Problem). La obtención de planificaciones defrecuencia eficientes es una tarea compleja y crucial paralos operadores de telefonía actuales. La razón es el númerolimitado de frecuencias con que cuentan dichos operadorespara dar soporte al gran número de comunicaciones que seproducen en la red. El uso de estrategias metaheurísticasen combinación con técnicas basadas en paralelismo hademostrado ser una de las mejores maneras de conseguirresultados de alta calidad en tiempos competitivos. Elequipo paralelo descrito en este trabajo está compuesto porun conjunto de siete metaheurísticas que presentandiferentes comportamientos. Así, algunas son estrategiasbasadas en trayectoria y otras basadas en población, unasson estrategias clásicas y otras muy recientes, o algunaspresentan diseños bio-inspirados y otras están basadas enmodelos probabilísticos. El equipo paralelo está controladopor una hiperheurística (HH) que orquesta el eficientefuncionamiento de todo el sistema. El análisis de losresultados obtenidos demuestra que la utilización de unequipo heterogéneo de estrategias debidamenteconfiguradas obtiene resultados de muy alta calidad en laresolución del problema abordado. De hecho, lasplanificaciones de frecuencia conseguidas por el sistemapropuesto mejoran los resultados de otras publicacionesrelevantes.Palabras clave— Equipo heterogéneo de metaheurísticas,Hiperheurística Paralela, Problema Real de AsignaciónAutomática de Frecuencias, FAP, MPI.EI. INTRODUCCIÓNL problema de la asignación automática defrecuencias (FAP –Frequency Assignment Problem)es una de las tareas más importantes llevadas a cabo enel diseño de redes reales de comunicaciones. De hecho,resulta un trabajo fundamental tanto para los operadoresde telefonía actuales como para los futuros, ya quedebido a las restricciones de ancho de banda quepresenta cada compañía de telefonía, es bien sabido quesólo con una planificación de frecuencias de alta calidadse puede conseguir el máximo partido del reducidorango de frecuencias disponible. Por tanto, debido a surelevancia, el problema FAP ha sido muy estudiado enlas últimas décadas, por lo que en la bibliografía se1 Dpto. Tecnología de los Computadores y de las Comunicaciones,Universidad de Extremadura, Escuela Politécnica de Cáceres, e-mail:{jm, mavega, jangomez, sanperez}@unex.es.pueden encontrar numerosos trabajos donde se utilizandiferentes aproximaciones y una gran variedad demodelos matemáticos para su resolución [1, 2]. Sinembargo, la mayoría de estas publicaciones resuelvenproblemas FAP de tipo benchmark [2], los cuales tienenuna complejidad menor que los problemas basados enredes reales, donde se consideran requisitos y conceptosque son inherentes a dichas redes [3], como son elelevado número de transmisores que se utilizan comosoporte de las comunicaciones o las restricciones en lasque se basan las interferencias producidas en la red.El problema de optimización que surge con el FAP seexplica porque las redes de telefonía actuales disponende un rango de frecuencias muy limitado con el quedeben dar servicio al cada vez mayor número deusuarios que utilizan los servicios de dicha red. Estehecho causa que las frecuencias deban ser utilizadas demanera simultánea en distintos puntos de la red para quesea posible llevar a cabo todas las comunicaciones quese producen. Sin embargo, el solapamiento defrecuencias lleva acarreado interferencias que dificultan,e incluso pueden llegar a anular, dichas comunicaciones.Por esta razón se hace necesario realizar unaplanificación de frecuencias de alta calidad con la que seconsiga maximizar la cobertura en toda la redmanteniendo a la vez unos mínimos aceptables en lacalidad de servicio que ésta ofrece.El FAP es un problema NP-completo, por lo queutilizar algoritmos exactos para resolver instanciasreales del mismo no es factible. Por el contrario, abordareste tipo de instancias con técnicas basadas enbúsquedas heurísticas o estrategias metaheurísticas es, sino obligatorio, una de las mejores opciones paraconseguir planificaciones de frecuencia de alta calidad[4]. Sin embargo, el problema abordado también tieneunas fuertes restricciones temporales, y el uso de estetipo de algoritmos conlleva muchas veces una demorademasiado amplia para los requisitos del mismo. Portanto, el uso de estrategias paralelas que aceleren laobtención de resultados de alta calidad también resultafundamental cuando se trabaja con instancias reales degrandes dimensiones.De esta manera, en este artículo se describe lautilización de un equipo paralelo que hace uso de variasestrategias metaheurísticas para conseguir resultados dealta calidad que resuelvan instancias reales del problemade la asignación automática de frecuencias. Además, seha hecho un estudio de cómo la heterogeneidad de lasestrategias que participan en el equipo redunda en unamejora significativa de los resultados, concluyendo queJP2011-125

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011una configuración adecuada de esta aproximaciónconsigue resultados altamente satisfactorios para elproblema abordado.El resto del artículo se estructura de la siguientemanera: en la Sección II se explican los conocimientosbásicos y la definición formal utilizada para modelar elproblema FAP manejado en nuestro estudio. Acontinuación, en la Sección III, se describe el equipoheterogéneo de metaheurísticas propuesto para resolverel problema. Después se resumen los experimentosrealizados y los resultados obtenidos mediante losmismos en la Sección IV. Finalmente, las conclusiones ylíneas futuras se discuten en la Sección V.II. LA PLANIFICACIÓN DE FRECUENCIAS EN REDES GSMLa planificación de frecuencias es el último paso en eldiseño de una red GSM [5]. Antes de afrontar esteproblema, el diseñador de la red tiene que tratar concuestiones previas, como por ejemplo la localización yconfiguración de las antenas que darán cobertura a la redo configurar el número y orientación de los sectores quetendrá cada antena y la distribución de TRXs(transmisores-receptores) dentro de éstos [6], que sonlos elementos encargados de realizar la comunicación.El número de TRXs que se instalarán en cada sectordependerá de la demanda de tráfico que éste debasoportar. La planificación de frecuencias consiste enasignar un canal (o frecuencia) a cada TRX [3]. Noexiste una única versión del problema de la asignaciónautomática de frecuencias. De hecho, tanto el modelomatemático utilizado para representar el problema [1, 3]como la técnica de resolución aplicada para resolverlovariarán dependiendo del escenario abordado y delobjetivo concreto que se persiga. En este artículo seresuelven dos instancias reales de gran tamaño. Por unalado se aborda la instancia Denver, que incluye 2612TRXs distribuidos en 334 BTSs y únicamente tienedisponibles 18 frecuencias para asignar a todos y cadauno de los TRX de la red. Por otro lado se maneja lainstancia Seattle, que incluye 970 TRXs instalados en503 antenas y únicamente 15 frecuencias diferentes pararealizar la planificación de frecuencias en toda la red. Ala vista de las cifras que se manejan, queda claro queconseguir planificaciones de frecuencias de alta calidades una tarea tan importante como compleja.Por tanto, el problema de optimización surge debido aluso de la misma frecuencia por varios transmisores. Estehecho suele provocar interferencias que pueden llegar areducir la calidad de servicio (QoS) hasta nivelesinsatisfactorios para una red comercial, y esto ha de ser,si no evitado (porque no es posible evitarlo), sí reducidotodo lo posible.Hay varias formas de cuantificar las interferencias quese producen en una red de telecomunicaciones, aunquela más extendida (y la que nosotros utilizamos) es usarlo que se llama la matriz de interferencias, M, de la red[3]. Cada elemento M(i,j) de esta matriz contienebásicamente dos tipos de interferencia: la interferenciaco-canal, que representa la degradación de la calidad deseñal en la red si las celdas i y j operan con la mismafrecuencia; y la interferencia de canal adyacente, que seproduce cuando dos TRXs operan en canales adyacentes(por ejemplo, un TRX opera en el canal f y otro en elcanal f+1 o f-1). Es muy importante que la matriz deinterferencias esté bien ajustada, ya que el objetivo decualquier algoritmo que resuelva el FAP será minimizarla suma de las interferencias expresadas en la matriz M.En la siguiente subsección se explica el modelomatemático que se ha utilizado para modelar elproblema. Dicho modelo fue propuesto en un trabajoprevio, por lo que el usuario que quiera una explicaciónmás completa que la dada en este artículo puedeconsultar la referencia [7].A. Descripción formal del problemaSea T = {t 1 , t 2 ,…, t n } un conjunto de n TRXs, y sea F i= {f i1 ,…, f ik } ⊂ N el conjunto de frecuencias validas quepueden ser asignadas a un TRX t i ∈ T, i = 1,…, n.Nótese que k, que representa la cardinalidad de F i , notiene que ser necesariamente la misma para todos losTRXs. Además, sea S = {s 1 , s 2 ,…, s m } el conjunto de lossectores (o celdas) donde los TRXs están instalados, decardinalidad m. Cada TRX t i ∈ T está instaladoexactamente en uno de los m sectores. Además,llamamos al sector donde un TRX t i concreto estáinstalado como s(t i ) ∈ S. Finalmente, sea la matriz M ={(μ ij , σ ij )} mxm , llamada matriz de interferencias, dondelas dos entradas μ ij y σ ij de la matriz M(i,j) = (μ ij , σ ij )son valores numéricos mayores o iguales que 0. Dehecho, μ ij representa la media, y σ ij es la desviaciónestándar de una distribución de probabilidad gausianaque describe la proporción señal/interferencia (C/I,carrier-to-interference) dentro de la red [8] cuando lossectores i y j operan con la misma frecuencia. Cuantomás alto es el valor de la media, más baja será lainterferencia, y de esta manera mejor la calidad en lacomunicación. Además, es importante señalar que lamatriz de interferencias se define a nivel de sector(celda), porque todos los transmisores instalados en cadasector dan cobertura a la misma área. De esta forma,podemos establecer que una solución al problema FAPse obtiene asignando a cada TRX t i ∈ T una de lasfrecuencias de F i . Diremos que una solución al problema(o una planificación de frecuencias) se define como: p ∈F 1 × F 2 × … × F n , donde p(t i ) ∈ F i es la frecuenciaasignada al TRX t i . El objetivo del algoritmo, y de laplanificación misma, es encontrar una solución p queminimice la siguiente función de coste:C(p)=∑ ∑Csigt∈Tu∈T, u≠t( p,t,u)Para definir la función C sig (p,t,u), vamos a establecerque s t y s u son los sectores en los que los TRXs t y uestán instalados, que son s t =s(t) y s u =s(u). Además, seaμs t s u y σs t s u los dos elementos correspondientes dentrode la matriz de interferencias M(s t ,s u ) con respecto a lossectores s t y s u . De esta forma, C sig (p,t,u) es igual a laexpresión descrita en la ecuación 2.⎧ K⎪Cco( μsts, σu⎨⎪Cadj( μsts, σu⎪⎩ 0stsustsu))si s = s ,si s ≠ s , μtstsusi s ≠ s , μttuuustsup(t)− p(u)< 2> 0, p(t)− p(u)= 0> 0, p(t)− p(u)= 1en otro caso(1)(2)Donde K >> 0 es una constante con un valor muy altoque está definida por el diseñador de la red para hacerJP2011-126

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011indeseable la asignación de la misma o frecuenciasadyacentes a transmisores que sirven dentro del mismoárea (instalados en el mismo sector). Además, dentro dela ecuación 2, C co (μ,σ) representa el coste debido a lasinterferencias co-canal (ecuación 3) mientras queC adj (μ,σ) es el coste en caso de las interferencias decanal adyacente (ecuación 4).CSH− μCco(μ,σ ) = 100(1.0 − Q())(3)σCSH− CACR− μCadj( μ,σ ) = 100(1.0 − Q()) (4)σDonde C SH es un umbral de calidad mínima de la señaly C ACR (rechazo de canal adyacente) mide la habilidaddel receptor a la hora de recibir la señal requerida enpresencia de una señal que no es la requerida en un canaladyacente. Finalmente, Q(z) se define como:Q(z)=∞∫z12πe x 2−2Para una explicación más detallada sobre los costesC co (μ,σ) y C adj (μ,σ) y el modelo matemático utilizado,el lector interesado puede consultar las referencias [1,3], donde se da una explicación más profunda sobre laformulación utilizada.dxIII. EQUIPO PARALELO DE METAHEURÍSTICASEn este artículo se presenta un equipo heterogéneocompuesto por un conjunto de siete metaheurísticas ycontrolado por una hiperheurística (HH) paralela. Elobjetivo de la HH no consiste en solucionar el problemade manera directa, sino en seleccionar el método másadecuado que debe aplicarse ante una determinadasituación. Este método, una metaheurística en nuestrocaso, será el encargado de trabajar con el problema. Enla Fig. 1 se puede observar un diagrama que describe elfuncionamiento general del sistema propuesto.Fig. 1. Diseño del equipo heterogéneo de metaheurísticas.Como se puede observar, tanto las especificaciones delproblema como las instancias que deben manejarse songestionadas por un conjunto de metaheurísticas que han(5)sido especialmente ajustadas para trabajar con el FAP.La tarea de la que se encarga la HH consiste en controlarla salida proporcionada por dichas estrategias paradistribuir de manera adecuada la carga de trabajo deacuerdo con la calidad de los resultados obtenidos porcada algoritmo. La comunicación entre la HH y lasmetaheurísticas no depende de las especificaciones delproblema, ya que la HH únicamente recibe en cadasincronización la mejor solución conseguida por cadametaheurística hasta ese momento, su coste asociado yel identificador del algoritmo que aportó la citadasolución. De acuerdo con dicha información la HHdistribuye la carga de trabajo que cada algoritmo deberáprocesar hasta la siguiente sincronización. Al final delproceso, la mejor solución conseguida por una de lasmetaheurísticas será la solución que devuelva el sistema.Una de las características más interesantes de la HH esque ésta hace que las metaheurísticas realicen subúsqueda en paralelo. Como se expondrá en la siguientesección, los experimentos se han realizado en un clústerde 128 núcleos, por lo que el diseño de la hiperheurísticaparalela saca el máximo partido de los recursosdisponibles. Uno de los núcleos del clúster ejecutará elproceso maestro del sistema (Algoritmo 1), mientras queel resto de núcleos ejecutarán las metaheurísticasdestinadas a resolver el problema propiamente dicho.Por tanto, la HH forma parte de un sistema síncronodonde su tarea es sincronizar y gestionar un equipo dealgoritmos metaheurísticos con el fin de resolver unproblema FAP real.Algoritmo 1 – Pseudocódigo para el proceso maestro de la HH1: vectorProbHH ← inicializar_vectorProbHH2: vectorCores ← asignar_metaheurística_a_cada_core (vectorProbHH)3: lanzar_ejecuciones_esclavos (vectorCores)4: mientras (! condición_de_parada) hacer5: /* El proceso maestro espera a que cada core ejecute su algoritmo */6: /* Cada sincronización → los cores envían la mejor solución al maestro */7: para (j = 0) hasta (j = número_de_cores_configurados) hacer8: vectorSoluciones ← recibir_soluciones_cores (j)9: fin para10: vectorSoluciones ← ordenar_soluciones_fitness (vectorSoluciones)11: vectorProbHH ← actualizar_vectorProbHH (vectorSoluciones)12: vectorCores ← actualizar_vectorCores (vectorProbHH)13: mejorSolucion ← seleccionar_mejor_solucion (vectorSoluciones)14: relanzar_ejecuciones_esclavos (vectorCores, mejorSolucion)15: fin mientras16: devolver seleccionar_mejor_solucion_recibida (vectorSoluciones)El proceso comienza con la distribución homogénea detodas las metaheurísticas incluidas en el sistema, deacuerdo con un vector de probabilidad inicializado parael efecto (líneas 1 y 2). Este vector de probabilidad tienela función de decidir el número de núcleos queejecutarán cada una de las metaheurísticas incluidas enel sistema. Como se puede observar en la Fig. 1 se haseleccionado un conjunto heterogéneo de sietemetaheurísticas que se han considerado representativas.Así, se han seleccionado algunas basadas en población(el algoritmo genético –GA [9], la búsqueda dispersa –SS [10], el algoritmo basado en colonia de abejas –ABC[11] y el aprendizaje incremental basado en población –PBIL [12]) y otras basadas en trayectoria (elprocedimiento de búsqueda adaptativa, aleatoria yavariciosa –GRASP [13], la búsqueda local iterativa –ILS [14] y la búsqueda de entorno variable –VNS [15]).Algunas de ellas son estrategias clásicas, como el GA, yotras son muy novedosas, como el ABC. Otras seJP2011-127

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011caracterizan por una evolución muy rápida (ILS, VNS) obien por una búsqueda bastante intensivas (ABC, GA).En definitiva, tienen diferentes características que lashacen estrategias complementarias en la búsqueda delvalor óptimo del problema con el que se trabaja.En cualquier caso, una vez que todos los algoritmoshan sido repartidos entre los cores, empezarán suejecución (línea 3) hasta que su condición de parada (unlímite temporal) se satisfaga. Por cuestiones de espacio,no se explicará en este artículo el esquema de cadaalgoritmo, si bien es importante indicar que cada uno hasido sometido a un completo ajuste paramétrico para quese ajuste al problema con el que debe trabajar. Elproceso maestro espera hasta que las metaheurísticasterminan su ejecución, en cuyo momento le enviarán lamejor solución encontrada hasta ese momento (línea 8).Cuando todas las soluciones se han recibido, la HH lasordena de acuerdo con su calidad y actualiza el vector deprobabilidad siguiendo un proceso de presión selectiva(líneas 10 y 11). A continuación la hiperheurísticareasigna los algoritmos a los núcleos del clúster deacuerdo con el nuevo vector de probabilidad calculado(línea 12) teniendo en cuenta que ninguna debedesaparecer por completo del sistema. Además, seenviará a cada núcleo la mejor solución conseguidahasta ese momento (líneas 13 y 14) para que losalgoritmos basados en trayectoria (ILS, VNS y GRASP)continúen su ejecución partiendo de dicha solución y losbasados en población (GA, SS, ABC y PBIL) laincluyan a la primera población de soluciones generada.Finalmente, cuando la condición de parada del sistemase satisfaga (línea 4), que como se verá en la siguientesección es un cierto número de sincronizaciones, lahiperheurística devolverá la mejor solución conseguidaal final de proceso (línea 16), que será una planificaciónde frecuencias de alta calidad que de solución alproblema FAP abordado en nuestro estudio.IV. EXPERIMENTOS Y RESULTADOSTodos los experimentos se han llevado a cabo en unclúster homogéneo compuesto por 16 nodos multinúcleo.Cada nodo cuenta con 8 núcleos, lo cual hace untotal de 128 nodos de procesamiento. Además, tal ycomo se especificó en la Sección II de este artículo, sehan utilizado dos instancias reales para realizar losexperimentos (Denver y Seattle), cuya topología puedeobservarse en la Fig. 2. En dicha figura cada triángulorepresenta una antena sectorizada en la que operanvarios TRXs. Denver cuenta con 2616 TRXs yúnicamente 18 frecuencias disponibles, mientras queSeattle consta de 970 TRXs y sólo 15 frecuencias.Debido a la naturaleza estocástica de lasmetaheurísticas, todos los experimentos realizados ennuestro estudio han sido repetidos de maneraindependiente 30 veces, con el fin de validarestadísticamente los resultados obtenidos de maneraempírica. Por otro lado, para detectar diferencias en laejecución de los algoritmos en diferentes periodos detiempo y para poder realizar una comparativa con otrosestudios que resuelven el mismo problema (Tabla I), sehan considerado tres límites temporales: 120, 600, 1800.En este sentido, no se han tenido en cuenta tiemposinferiores a dos minutos porque, debido a la complejidaddel problema, en dichos casos las metaheurísticastendrían demasiado poco tiempo para hacer evolucionarlas soluciones, por lo que los resultados no seríansignificativos. Tampoco se han considerado tiempos queen la mayoría de los casos superaran los treinta minutos,ya que éstos serían excesivos para un problema realdentro del dominio abordado.Fig. 2. Topología de las instancias GSM utilizadas.Los dos experimentos más relevantes realizados con elequipo de metaheurísticas fueron los relevantes alnúmero de sincronizaciones que éste debía realizar y a lacomposición de las metaheurísticas sobre las que seapoyaba. En el primer caso, si el número desincronizaciones es demasiado alto, el sistema gastarádemasiado tiempo en esta tarea, dejando a lasmetaheurísticas sin tiempo suficiente para hacerevolucionar las soluciones. Por el contrario, si serealizan menos sincronizaciones de las debidas, lasmetaheurísticas trabajarán demasiado tiempo de maneraaislada, como islas independientes, por lo que losresultados tampoco serán de tanta calidad comodeberían. Por tanto, para llevar a cabo el ajuste de lassincronizaciones, se llevó a cabo una serie de pruebasutilizando las instancias Denver y Seattle anteriormentemencionadas con el objetivo de determinar la frecuenciaóptima de sincronizaciones que debe realizar la HH paraobtener planificaciones de frecuencia de la mayorcalidad posible. Las Figs. 3 y 4 resumen los resultadosobtenidos con dichos experimentos. Se han realizadopruebas sincronizando el sistema cada minuto, cada 2minutos, cada 5, 10 y 15 minutos. Teniendo en cuentaque la duración total del experimento es de 30 minutossignifica que se han hecho pruebas realizando 29, 14, 5,2 y 1 sincronizaciones respectivamente.Fig. 3. Evolución en los resultados obtenidos para la instancia Seattleutilizando diferentes sincronizaciones.JP2011-128

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Como se puede observar en la Fig.3, los mejoresresultados cuando se aborda la instancia Seattle seobtienen cuando la HH sincroniza las metaheurísticascada 5 minutos, ya que con esta configuración lasplanificaciones de frecuencia generadas tienen un costemenor que los resultados sincronizando cada 2 y cada 10minutos. Sincronizar cada 10 minutos nunca es másprovechoso que cada 5, mientras que un periodo desincronización de 2 minutos sólo es ligeramente mejordurante los 8 primeros minutos de ejecución (donde elsistema sólo se ha sincronizado una vez con laconfiguración de realizar sincronizaciones cada 5minutos). Si se configura al sistema con un númeromayor de sincronizaciones los resultados son tambiénmuy buenos en los primeros minutos de ejecución delalgoritmo (Fig. 3), sin embargo, empeoran mucho trasestos primeros instantes, ya que se invierte demasiadotiempo en la operación de sincronización, por lo que lasmetaheurísticas no tienen tiempo suficiente para hacerque las soluciones evolucionen adecuadamente.número de cores y de metaheurísticas trabajando a lavez), pero que únicamente utilizaba uno de losalgoritmos. La Fig. 5 muestra el resultado de esteestudio comparativo para la instancia Seattle. Como sepuede observar, el equipo heterogéneo mejorasignificativamente los resultados de cualquier equipohomogéneo para cualquier rodaja de tiempo estudiada(entre los 2 y los 30 minutos).Fig. 5. Comparativa de resultados sobre la instancia Seattle entre lahiperheurística paralela (PHH, equipo heterogéneo) y sieteequipos homogéneos formados por la misma metaheurística.Fig. 4. Evolución en los resultados obtenidos para la instancia Denverutilizando diferentes sincronizaciones.Por otro lado, si se analizan los datos para la instanciaDenver (Fig. 4), se puede observar que los mejoresresultados a corto plazo son alcanzados porconfiguraciones que realizan sincronizaciones cada muypoco tiempo (1 o 2 minutos), sin embargo, a partir de los10 minutos, las mejores planificaciones son obtenidas siel sistema se sincroniza cada 5, 10 o incluso 15 minutos.De hecho, si se considera la mejor configuración deDenver para los 30 minutos completos de ejecución, seestablece que la mejor configuración es sincronizar cada10 minutos, sin embargo, si se establece sincronizarcada 5 minutos, el sistema consigue mejores resultadosmedios en muchos más periodos de tiempo, tal y comose puede observar en la Fig. 4, donde la línea de los 5minutos representa la mejor configuración considerandode manera global los 30 minutos de ejecución.Otro aspecto importante con el equipo es determinarlas metaheurísticas que formarán parte de él. Por estarazón se realizó un estudio comparativo para determinarcómo influía en los resultados la heterogeneidad de lasmetaheurísticas incluidas en el equipo. Se realizaronexperimentos comparativos entre un equipo heterogéneode metaheurísticas (que se apoyaba en los sietealgoritmos indicados anteriormente: GA, SS, PBIL,ABC, ILS, VNS y GRASP) con un equipo homogéneoque poseía la misma capacidad de cómputo (mismoEn cuanto a la instancia Denver (Fig. 6), también seproduce una mejora bastante significativa en cualquierperiodo de tiempo si el equipo se encuentra configuradode manera heterogénea, por lo que queda de manifiestola importancia de este parámetro para el funcionamientoóptimo del equipo.Fig. 6. Comparativa de resultados sobre la instancia Denver entre lahiperheurística paralela (PHH, equipo heterogéneo) y sieteequipos homogéneos formados por la misma metaheurística.A. Comparativa con otros autoresEn esta subsección se comparan los resultadosconseguidos por el equipo paralelo diseñado con otrasaproximaciones. La Tabla I resume dicha comparativa,donde se muestran los resultados medios (y desviacionesestándar) de 30 ejecuciones en tres periodos de tiempocuando se aborda la resolución de la instancia Denvercon diversas técnicas. Los trabajos con los que seJP2011-129

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011compara están sujetos a los mismos requerimientos yconsideraciones que el presentado en este documento,por lo que sus resultados representan una fuente decomparación excepcional. Los resultados finalesconseguidos por el equipo paralelo explicado en esteartículo aparecen en la primera línea. Las siguientes filascontienen los datos arrojados por otros estudiosrelevantes (se incluye su referencia correspondiente).Únicamente el trabajo que aparece en la última fila de latabla (GridEA [16]) utiliza un límite temporal diferenteal del resto de estudios, ya que el algoritmo desarrolladoen ese estudio fue limitado por iteraciones en lugar depor un límite temporal. Sin embargo, el estudio se haincluido en la tabla comparativa porque, hasta dondenosotros sabemos, representaba el mejor resultadopublicado en la bibliografía en la resolución de lainstancia Denver hasta que fue superado por losresultados obtenidos con la hiperheurística paralela.Como se puede observar en la Tabla I incluso esosresultados (GridEA [16]), que fueron obtenidos despuésde 1,5 horas de ejecución, han sido superados por losresultados conseguidos por la PHH desarrollada, pero enun tercio del tiempo invertido por el sistema grid (30minutos), y utilizando menos recursos hardware.Como se puede observar, el problema FAP ha sidoabordado por diferentes técnicas metaheurísticas yaproximaciones paralelas en los últimos años, sinembargo, hasta donde sabemos, el equipo paralelopresentado en este artículo mejora los resultadosobtenidos por otros diseños publicados.TABLA ICOMPARATIVA ENTRE LOS RESULTADOS OBTENIDOS POR LAESTRATEGIA DISEÑADA Y OTROS TRABAJOS RELEVANTES120 segundos 600 segundos 1800 segundosx± σ x± σ x± σEquipo paralelo 87100.2±381.2 85167.9±382.9 84527.4±404.7ACO [7] 93978.2±1165.9 91726.4±1002.9 90382.5±935.3EA [7] 108071.9±1723.4 103535.9±1939.7 99862.3±1553.1GRASP [17] 91225.7±1197.2 89369.6±1185.1 88850.6±1075.2GridGRASP [17] 87256.9±2309.2 86772.1±1701.0 85855.3±686.9ACO [18] 93439.5±1318.9 92325.4±1092.8 90649.9±727.5ssGA [18] 89540.4±991.1 87850.8±573.6 86908.9±379.8SS [18] 94199.6±1172.3 93953.9±1178.6 93820.4±1192.3(1+2)EA [18] 92294.0±1407.6 89669.8±1164.8 88574.3±1100.3LSHR [18] 92061.7±585.3 89430.9±704.2 88550.3±497.0Grid EA [16] Resultados obtenidos en 1,5 horas: 84936.3±375.8V. CONCLUSIONES Y TRABAJO FUTUROEn este artículo se presenta un equipo heterogéneo demetaheurísticas para resolver un problema real detelecomunicaciones. En concreto se han abordado dosinstancias reales de gran tamaño del problema de laasignación automática de frecuencias. El análisis de losresultados arroja una doble conclusión. La primeraresalta la importancia de configurar el equipo con unconjunto heterogéneo y equilibrado de metaheurísticas,ya que aunque algunas funcionen de manera máseficiente en algunas circunstancias, otras obtendránmejores resultados en otras (por ejemplo, con distintasmetaheurísticas o diferentes rodajas de tiempo, Figs. 5 y6). En este sentido, el análisis de los resultados nos llevaa concluir que todas las metaheurísticas incluidas ennuestro equipo contribuyen a la evolución global delsistema. Además, ha quedado de manifiesto que la mejorconfiguración en cuanto a sincronizaciones es realizarlascada 5 minutos (Figs. 3 y 4). Finalmente, se ha realizadouna comparación con otros estudios presentes en labibliografía (Tabla I) de la que se puede extraer que losresultados conseguidos por el sistema propuesto mejoranlos resultados de otras publicaciones relevantes.Como trabajo futuro, tenemos la intención de aplicar elequipo diseñado a instancias del problema FAP aúnmayores así como el de abordar otros problemasrelevantes dentro del dominio de las comunicaciones,como el RWA (Routing and Wavelength Assignment,enrutamiento y asignación de longitudes de onda [19]).AGRADECIMIENTOSEl presente trabajo ha sido parcialmente financiado porel Ministerio de Ciencia e Innovación y el FEDER(Fondo Europeo de Desarrollo Regional), bajo elproyecto TIN2008-06491-C04-04 (proyecto M*).REFERENCIAS[1] K. I. Aardal, S. P. M. van Hoesel, et al., “Models and solutiontechniques for frequency assignment problems”, Annals ofOperations Research, 153 (1), 79-129, 2007.[2] FAP Web: http://fap.zib.de/, 2010.[3] A. Eisenblätter, “Frequency Assignment in GSM Networks:Models, Heuristics, and Lower Bounds”, PhD thesis, TechnischeUniversität Berlin, 2001.[4] C. Blum, y A. Roli, “Metaheuristics in CombinatorialOptimization: Overview and Conceptual Comparison”, ACMComputing Surveys, 35, pp: 268-308, 2003.[5] M. Mouly, y M.B. Paulet, “The GSM System for MobileCommunications”. Telecom Publishing, 1992.[6] A.R. Mishra, Fundamentals of Cellular Network Planning andOptimisation: 2G/2.5G/3G... Evolution to 4G, chapter: “RadioNetwork Planning and Optimization”, pp: 21-54, Wiley, 2004.[7] F. Luna, C. Blum, E. Alba, A.J. Nebro, “ACO vs EAs forSolving a Real World Frequency Assignment Problem in GSMNetworks”, GECCO’07, pp: 94-101, 2007.[8] B.H. Walke, “Mobile Radio Networks: Networking, Protocolsand Traffic Performance”, Wiley, 2002.[9] D. E. Goldberg, “Genetic Algorithms in Search, Optimization,and Machine Learning”, Addison-Wesley, 1989.[10] R. Martí, M. Laguna, F. Glover. “Principles of scatter search”,European Journal of Operational Research, 169 (2), 359-372,2006.[11] D. Karaboga, B. Basturk, “A powerful and efficient algorithm fornumerical function optimization: artificial bee colony (ABC)algorithm”, Journal of Global Optimization, Springer, 39, 459-471, 2007.[12] S. Baluja, “Population-based Incremental Learning: A Methodfor Integrating Genetic Search based Function Optimization andCompetitive Learning”. Technical Report CMU-CS-94-163,Carnegie Mellon University, Junio 1994.[13] T.A. Feo, M.G. Resende, “Greedy Randomized Adaptive SearchProcedures”, Journal of Global Optimization, 6, 109-133, 1995.[14] H.R. Lourenço, O. Martin, T. Stützle, Handbook ofMetaheuristics, chapter “Iterated local search”, KluwerAcademic Publishers, 321-353, 2002.[15] N. Mladenovic, P. Hansen, “Variable neighborhood search”,Computers and Operations Research, 24 (11), 1097-1100, 1997.[16] F. Luna, A. J. Nebro, et al., “Solving large-scale real-worldtelecommunication problems using a grid-based geneticalgorithm”, Engineering Optimization, 40 (11), 1067-1084, 2008.[17] J. M. Chaves-González, R. Hernando-Carnicero, et al., “Solvinga Realistic FAP Using GRASP and Grid Computing”. Advancesin Grid and Pervasive Computing (GPC 2009), pp. 79-90, 2009.[18] F. Luna, C. Estébanez, et al., “Metaheuristics for Solving a Real-World Frequency Assignment Problem in GSM Networks”,GECCO’08, pp. 1579-1586, 2008.[19] A. Rubio-Largo, M. A. Vega-Rodríguez, et al., “A DifferentialEvolution with Pareto Torunaments for solving the Routing andWavelength Assignment Problem in WDM Networks”, CEC2010, pp. 129-136, 2010.JP2011-130

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Determination of traffic control tables by HPCEligius M.T. Hendrix, Siham Tabik 1 and Rene Haijema 2Resumen— The concept of traffic control tables(TCT) for an intersection is sketched and a StochasticDynamic Programming model is outlined. The determinationof a TCT by dynamic programming becomesmore cumbersome if more traffic flows and combinationof lights are taken into account. This paper explainshow High Performance Computing (HPC) canbe essential to do this job and sketches the challengesof this research question.Palabras clave— Stochastic Dynamic Programming,traffic control, parallel implementation, Markov chainTABLA ITCT for F2C2 when lights show all-redq 1 q 2 0 1 2 3 4 50 2 2 2 2 2 21 1 2 2 2 2 22 1 1 2 2 2 23 1 1 1 2 2 24 1 1 1 1 2 25 1 1 1 1 1 2Fig. 1.I. IntroducciónSituation F2C2; at most one of two flows gets priorityTraffic lights are introduced at the beginning of theprevious century to make road traffic safer, at placeswhere traffic from different directions cross the sameroad segment, called the intersection or crossing. Bygiving right of way to traffic in some direction(s),cars approaching from other directions need to waitbefore they get priority. By controlling the trafficlights, the overall delay or waiting time of the carscan be kept to a minimum. In literature, the problemis studied by queueing theorist as well as engineers(see [5], [6], [9],[8], [10]). An optimal dynamic policyis not reported except in [4].The basis of optimal traffic control on a singleintersection is what we call a traffic control table(TCT) that prescribes which combination of flowsshould be given the right of way given the amountof cars waiting in every queue. For illustration considerthe simple situation in Figure 1, called in [3]the F2C2 case for having 2-Flows in 2-Combinations.Either the left, or right flow has a green light, or alllights are red to clear the intersection. For the ease ofreasoning, we abstract here from using amber lights.Table I illustrates the concept of a TCT. It marksthe decision of which light to set on green, given thequeue length of both queues, when the light is in theall-red state. In this example λ 2 > λ 1 , such that onequal queue length, it is convenient to give flow 2the right of way. [4] model the generation of such atable as a Stochastic Dynamic Programming (SDP)1 Dpto. Arquitectura de Computadores, Univ. De Málaga,e-mail: eligius, stabik @uma.es.2 Operations Research and Logistics group, Wageningen University,e-mail: rene.haijema@wur.nl.problem in order to find that TCT that minimizesthe expected total waiting time in the system.In Section II, the SDP model is outlined and theiterative process to obtain traffic control tables fromthat. Section III describes the parallel programmingapproach used to exploit multicore systems. SectionIV provides the experimental set up where a computationalillustration is given in Section V. Finally,Section VI concludes.II. TCT by Stochastic DynamicProgrammingThere are numerous ways to model traffic flows.We focus here on a Markov chain view with timeslots are thought of as to be that big that one carcan pass by on a green light, usually taken as twoseconds. The state is described by the vector (q, l),where the vector q tracks the number of cars in eachqueue and l ∈ {0, . . . , ncomb} indicates the state ofthe light, i.e. which of the ncomb combination hasright of way (l = 0 represents the all-red state).The probabilities of going from one state to theother depend on the TCT as well as on the probabilitiesλ j of a car arriving at the queues j (for allj ∈ {1, . . . , nflow}. In order to get a finite statespace to allow numerical computations the queuelength is truncated to a maximum size Q, such thatq j ∈ {0, . . . , Q}.For the F2C2 case of Figure 1, this means that thestate space is 3-dimensional: (q 1 , q 2 , l). The numberof possible states is ns = (ncomb+1)×(Q+1) nflow =3(Q + 1) nflow . Consider the F4C2 case of Figure 2.The state space is 5 dimensional and the number ofstates is ns = 3(Q + 1) 4 . We observe that the numberof states grows exponentially fast in the numberof queues; this called the curse of dimensionalityin solving an SDP problem. Nevertheless up to theF4C2 case, Haijema concludes that an optimal policycan relatively easily be computed on a PC witha single processor. Although the curse of dimensionalityis not resolved by HPC, HPC may stretch thecomputational limit beyond the F4C2 case.To find a TCT that minimizes the expected wait-JP2011-131

| m0Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3.Value function determinationFig. 2.Situation with 4 flows and 2 symmetric combinationsing time we apply the so-called value iteration (VA)algorithm (for details see [7] and [3]). First a costnflow∑function C(q, l) = q j is defined that capturesj=1the waiting time during the coming time slot forthe current state (q, l). Note that by Little’s lawminimizing the expected number of cars waiting alsominimizes the overall expected waiting time. Next aso-called value vector V n (q, l) that gives a valuationfor each state over the next n time slots, is to becomputed for n = 1, 2, 3, . . .. Clearly the cost over0 periods is zero, hence we start the value iterationalgorithm with n = 0 and V n (q, l) = 0 for all states(q, l). Then one determines iteratively optimum decisionsa such thatV n+1 (q, l) = C(q, l) + min E e|a V n (T (q, l, a, e))awhere T is a transformation function that gives thestate at which to arrive when at the current state,the decision a is taken and arrival event e happens.The whole is sketched in Figure 3. Notice thatthe number of possible events is 2 nflow , as at eachqueue, a car may arrive or not. The probabilitiesare determined from the vector of traffic intensities(λ 1 , . . . , λ nflow ). If l = 0, i.e. all lights are red, thedecision a ∈ {1, . . . , ncomb}, i.e. one of the combinationscan be given a green light. In the other cases,there are 2 possibilities; either the light stays as it is,or is put in the all-red state to clear the intersection.Fig. 4.in |max20 30 40 5010Convergence of the span for the F4C2 instance, calculatedby the parallel code on a quad-socket eight-coreIntel X7550 (Beckton).Convergence100 150 200 #iterations 50 0III. Coding Value iterationThe value iteration process requires running the iterationsup to convergence. At each iteration all valuesfor the ns states of V n+1 have to be determined.If l = 0, this requires looking up ncomb × 2 nflow valuesin V n . As we have seen, this is less if one of thecombinations is green. We should look up 2 nflow+1and take the minimum over the two decisions.V n(ns)V n+1(ns)(2,ncomb) {0,…,2 nflow }iFig. 5. Each V n+1 (i) is determined using 2 or ncomb ×Q nflowelements of V n, depending on the state of light.In summary, the iterative process of value iterationfor the TCT generation can be sketched as follows:……The converging part in the process is the differenceV n+1 −V n converging to a constant vector whichrepresents the average waiting time in the system.Practical implementations require the translation ofthe state (q, l) to a state number i and vice versa,such that one works with two arrays with elementsV n+1 (i) and V n (i). The convergence is measured bykeeping hold of the so-called span defined as span =max i (V n+1 (i) − V n (i)) − min i (V n+1 (i) − V n (i)). Thisis illustrated in Figure 4.for(i=0;i < nflows;i++)q[i]=1;while(1){for(i=0;i

0Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011if (max-min

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIArchitecural summary of the multi-core platform used in the experimentsIntel X7550 4 socketscores/socket SMT L1D cache L2 cache L3 cache memory8 yes 8×32KB 8×256KB 1×18MB 128GBexploit the potential of multi-socket multi-core architectures.Preliminary speedups of the data-sharingimplementation have been measured for a mediumsized instance called F4C2.Currently, we are exploring new techniques suchas software prefetching and cache blocking to furtherimprove the performance of the data-sharingimplementation at one Socket level. In addition,we are working on optimizing the communicationsin the data-privatizing implementation to improvethe performance among multiple Sockets. The intentionis to apply the techniques to the F12C4 casegiven in Figure 8. for which no optimum TCT hasbeen derived yet. Updating one value of the valuefunction requires the evaluation of several times 2 12states due to the possible events. Moreover, using aminimum queue length of Q = 2, this has to be donefor 5 × 3 12 = 2.7 mln states. Future investigationwill look at using interpolation to keep the numberof states limited to that number.[3] R. Haijema, Solving large structured markov decisionproblems for perishable inventory management and trafficcontrol, Ph.D. thesis, Univeristy of Amsterdam - TinbergenInstitute - Amsterdam School of Economics, 122008.[4] R. Haijema and J. van der Wal, An MDP decompositionapproach for traffic control at isolated signalized intersections,Probability in the Engineering and InformationalSciences 22 (2008), no. 4, 587–602.[5] G. F. Newell, Approximation methods for queues withapplications to the fixed-cycle traffic light, SIAM Review7 (1965), no. 2, 223–240.[6] M. Papageorgiou, C. Diakaki, V. Dinopoulou, A. Kotsialos,and Y. Wang, Review of road traffic control strategies,Proc. of the IEEE, vol. 91, IEEE, 2003, pp. 2043–2067.[7] M. L. Puterman, Markov decision processes: Discretestochastic dynamic programming, Wiley Series in Probabilityand Mathematical Statistics, 1994.[8] M. S. van den Broek, J. S. H. van Leeuwaarden, I. J. B. F.Adan, and O. J. Boxma, Bounds and approximations forthe fixed-cycle traffic-light queue, Transportation Science40 (2006), 484–496.[9] J. S. H. van Leeuwaarden, Delay analysis for the fixed cycletraffic light queue, Transportation Science 40 (2006),no. 2, 189–199.[10] M. Wiering, J. van Veenen, J. Vreeken, and A. Koopman,Intelligent traffic light control, technical report UU-CS-2004-029, Institute of information and computing sciences,Utrecht University, 2004.Fig. 8.Instance of intersection with 12 flows, 4 combinationsAgradecimientosThis work is supported by grants from the SpanishMinistry of Science and Innovation (TIN2008-01117, TIN2006-01078), Junta de Andalucía (P08-TIC-3518), in part financed by the European RegionalDevelopment Fund (ERDF). Eligius Hendrixis fellow of the Spanish “Ramon y Cajal” contractprogram and Siham Tabik of the “Juan de la Cierva”program, co-financed by the European Social Fund.Referencias[1] The OpenMP API specification for parallel programming,http://openmp.org/wp/openmp-specifications/.[2] Intel Compilers for Linux, http://software.intel.com/enus/articles/intel-c-compiler-professional-edition-forlinux-documentation/(2009).JP2011-134

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evaluación del método del GradienteBiconjugado para matrices dispersas en GPUs.G. Ortega 1 , E. M. Garzón 1 , F. Vázquez 1 , I. García 2Resumen— En una gran variedad de aplicacionesde diferentes disciplinas científicas y relacionadas conla ingeniería, se requiere la resolución de sistemasde ecuaciones no simétricos y complejos. Para resolvereste tipo de sistemas de ecuaciones lineales, elMétodo del Gradiente Biconjugado se considera especialmenterelevante, ya que es capaz de resolver sistemasde ecuaciones complejos y no simétricos. Sinembargo, desde el punto de vista computacional, elmétodo BCG es muy costoso debido a los productosmatriz vector (SpMV) involucrados en dicho algoritmo.Por lo tanto, para acelerar dicho métodoes necesaria la explotación de Computación de AltasPrestaciones (HPC). La computación GPU haemergido como una nueva técnica de HPC que ofreceun paralelismo masivo y, por tanto, puede ser consideradacomo una valiosa herramienta para acelerareste tipo de algoritmos. En este trabajo se muestraque el método BCG puede ser acelerado de una formaeficiente si las operaciones SpMV se computan en laGPU. Hemos considerado dos implementaciones distintasdel método BCG en la GPU: CuBCG SP (basadoen la librería CUSPARSE) y CuBCG ET (basado enla rutina ELLR-T). Ambos desarrollos han sido evaluadospara dos conjuntos de matrices de testeo detipo complejo y real, ambos en simple precisión. Losresultados experimentales han mostrado que ambosmétodos, CuBCG SP y CuBCG ET , obtienen rendimientossuperiores a la implementación con múltiples coresdel BCG. Sin embargo, CuBCG ET alcanza el mejorrendimiento, especialmente para el conjunto de matricesde tipo complejo.Palabras clave—Método del Gradiente Biconjugado,computacion GPU, computación paralela, sistemas deecuaciones lineales.I. IntroducciónEL algoritmo del Gradiente Conjugado (CG) esuno de los métodos iterativos más utilizadospara la resolución de sistemas simétricos positivosdefinidos [1], [2]. Dicho método es especialmenteapropiado para resolver sistemas de ecuaciones linealesen los que intervienen matrices dispersas dedimensiones considerables. Sin embargo, el métodoCG no es adecuado para sistemas no simétricos. Así,el Método del Gradiente Biconjugado (BCG), unageneralización del CG, es capaz de resolver sistemasde ecuaciones lineales simétricos y complejos con suficienteprecisión. Sin embargo, el método BCGrequiere operaciones con un alto coste computacionalen cada iteración. Esto significa un esfuerzoadicional: la utilización de Computación de AltasPrestaciones (HPC) para acelerar la computación delmétodo BCG.Actualmente, las Unidades de Proceso Gráfico1 Dpt. Arquitectura y Electrónica, Universidad deAlmería, e-mail: glortega@ual.es, gmartin@ual.es,f.vazquez@ual.es2 Dpt. Arquitectura, Universidad de Málaga, e-mail:igarcia@ac.uma.es(GPU) son plataformas que ofrecen un paralelismomasivo y, por tanto, pueden resultar de utilidad paraacelerar este tipo de algoritmos. En la literatura sehan implementado y evaluado diversos desarrollos delos métodos CG y BCG [3], [4], [5]. Sin embargo,en este estudio se obtienen mejores rendimientos enel desarrollo de implementaciones HPC del métodoBCG basadas en computaciones GPU.Las arquitecturas GPU pueden trabajar como eficientescoprocesadores de supercomputación y supoder puede ser aplicado a una gran variedad de aplicaciones,en particular en aquellas relacionadas conoperaciones matriciales. Las GPUs constan de cientosde cores que pueden ejecutar de forma colectivamiles de threads de computación. Cada core, llamadoProcesador Escalar (SP), pertenece a un conjuntode unidades multiprocesadoras llamadas MultiprocesadoresStreaming (SM) que componen el dispositivo.Por lo tanto, los últimos avances en latecnología GPU se han centrado en el desarrollo deInterfaces de Programación de aplicaciones (APIs),tales como la Arquitectura Unificada de Dispositivosde Cómputo (CUDA) de NVIDIA, que claramentefacilitan la programación de aplicaciones sobreGPUs. En los últimos años, el uso de las GPUs paraaplicaciones de propósito general ha crecido estrepitosamentedebido a la evolución tanto de las fuentesde programación GPU como de las tecnologías semiconductoras.De este modo, las GPUs han emergidocomo nuevas plataformas de computación que ofrecenun paralelismo masivo y proporcionan un altoratio de rendimiento para la computación científica.Una aproximación para facilitar la programaciónGPU es el uso tanto de rutinas básicas como de librerías,ya que: (1) tienen optimizadas las operacionesmás utilizadas en diversas aplicaciones y (2)pueden ser aceleradas de forma óptima a través de lasGPUs. En esta línea, NVIDIA suministra un amplioconjunto de rutinas relacionadas con diversos tiposde aplicaciones tales como CuBLAS, CuFFT o CUS-PARSE [6].Centrándonos en este estudio, las plataformasGPU nos permiten extender el método BCG parapoder resolver sistemas de ecuaciones lineales demayor dimensión. Esto es debido al hecho de que lacomputación GPU acelera las dos operaciones SpMVrequeridas por el método BCG. Dicha operación esla que tiene un mayor coste computacional en dichoalgoritmo, por lo tanto, puede ser consideradacomo la clave en el desarrollo del método BCG sobreplataformas GPUs. En la literatura es posibleencontrar varias implementaciones de la operaciónSpMV basadas en la computación CUDA [6], [7], [8],JP2011-135

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011[9], [10]. Particularmente, nuestro trabajo se ha centradoen dos kernels de CUDA para computar lasoperaciones SpMV involucradas en el método BCG:(1) el kernel SpMV de la librería CUSPARSE [6] y (2)el kernel ELLR-T, basado en el formato ELLPACK-R [10], [11]. Para realizar una intensa evaluacióndel rendimiento de ambas aproximaciones, hemosutilizado dos conjuntos representativos de matrices(reales y complejas). El estudio comparativo hallegado a la conclusión de que la aproximación delmétodo BCG basada en la rutina ELLR-T alcanzalos mejores rendimientos.La Sección II revisa el método BCG. La Sección IIIintroduce las dos implementaciones del método BCGque se han desarrollado: CuBCG CS , basada en elkernel CUSPARSE, y CuBCG ET , basada en el kernelELLR-T. La Sección IV evalúa ambas aproximacionesen una arquitectura GPU GTX 480. Para ello,se utilizan dos conjuntos representativos de matricesde testeo de tipo real y complejo que tienen distintospatrones de regularidad. Los resultados claramentemuestran que el método BCG basado en la rutinaELLR-T obtiene los mejores rendimientos para todaslas matrices de testeo consideradas. Finalmente,la Sección V resume las principales conclusiones.II. Método del Gradiente BiconjugadoEl Método del Gradiente Biconjugado (BCG) proporcionauna generalización del CG, ya que se reemplazanlas secuencias ortogonales de residuos por dossecuencias mutuamente ortogonales, al coste de proporcionaruna minimización [12], [13].El método BCG (propuesto por Lanczos [14], [15]y discutido por Fletcher [16] y Jacobs [17]) es unmétodo iterativo no estacionario capaz de solucionarsistemas de ecuaciones lineales Ax = b, donde lamatriz A ∈ C N×N puede ser no simétrica. Para elsistema de ecuaciones dado, A denota el coeficiente(disperso) la matriz, b indica el término independientey x es la solución vector.El Algoritmo 1 muestra el pseudocódigo para elMétodo de Gradiente Biconjugado. Además, en dichoalgoritmo también se muestran los órdenes decomplejidad de las operaciones más costosas computacionalmente.Destaquemos que nz denota elnúmero los elementos no nulos de A y N el número defilas. El coste computacional asociado a la operaciónSpMV es el mayor, ya que el resto de las operacionesson productos escalares. Es importante resaltar quecada iteración implica el cómputo de la operaciónSpMV utilizando las matrices A y A T (líneas 9 y13 de Algoritmo 1), donde la operación SpMV sobreA T representa una penalización en el rendimiento delmétodo BCG.III. Implementación del Método delGradiente Biconjugado sobre GPUsEn el algoritmo 1 las operaciones más costosascomputacionalmente son los productos matriz vector(SpMV), especialmente cuando las matrices involucradastienen un número elevado de elementos no nu-Algoritmo 1 Método del Gradiente BiconjugadoEntrada: Definir EP S = Umbral de precisiónSalida: El valor de x (i) .1: Computar r (0) = b − Ax (0) para un inicial x (0)2: Elegir r ′(0) = r (0) ; p ′(0) = 0; p (0) = p ′(0) ; ρ ′(0) = 13: Calcular ∆ (0) = norm2(r (0) ) O(4N)4: for i = 1, 2, ... do5: ρ (i) = (r ′(i−1) , r (i−1) ) O(8N)6: β (i) = ρ (i) /ρ ′(i−1)7: p (i) = r (i−1) + β (i) p (i−1) O(8N)8: p ′(i) = r ′(i−1) + β (i) p ′(i−1) O(8N)9: v (i) = Ap (i) O(8nz)10: α (i) = ρ (i) /(p ′(i) , v (i) ) O(8N)11: x (i) = x (i−1) + p (i) α (i) O(8N)12: r (i) = r (i−1) − v (i) α (i) O(8N)13: r ′(i) = r ′(i−1) − α (i) (A T p ′(i) ) O(8nz + 8N)14: ∆ (i) = norm2(r (i) ) O(4N)15: if ∆ (i) < ∆ (0) EP S then16: return x (i)17: else18: ρ ′(i) = ρ (i)19: end if20: end forlos, nz (ver el coste computacional de cada operaciónen el Algoritmo 1). En cada iteración del métodoBCG, se computan dos operaciones SpMV con lasmatrices A y A T . Como se comentó anteriormente,cuando la operación SpMV utiliza la traspuesta dela matriz el tiempo consumido es mayor. Esto es debidoa las penalizaciones relacionadas con la pérdidade localidad en el acceso a los elementos de A T . Porlo tanto, para superar esta pérdida en el rendimiento,nuestras implementaciones almacenan ambas matrices,A y A T , como dos matrices dispersas distintas.De este modo, se mantiene la localidad en el acceso alos elementos de ambas matrices en todas las operacionesSpMV. Para matrices A de gran dimensión, laalta complejidad computacional del SpMV requierede la explotación de técnicas de Computación de AltoRendimiento. Por lo tanto, nuestro interés se centraen acelerar tanto las operaciones SpMVs como elresto de operaciones con vectores, para así mejorar elrendimiento de todo el método BCG. Las aproximacionesutilizadas para acelerar este algoritmo estánbasadas en la computación GPU, ya que las plataformasGPUs pueden ser utilizadas como un aceleradordel SpMV [6], [11], [18].CUDA es la Interfaz de Programación de Aplicaciones(API) desarrollada por NVIDIA para facilitarla programación de las GPUs. Utilizando la interfazCUDA, la GPU es considerada por el programadorcomo un conjunto de multiprocesadores coninstrucciones SIMT (Simple Instrucción, MúltiplesHilos) [19]. Cada kernel (código paralelo) se ejecutacomo un grupo de hilos organizado como un grid debloques de hilos cuya configuración es definida porel programador, al establecer ciertos parámetros específicos.Uno de estos parámetros es el tamaño delbloque de hilos, a partir de aquí denominado BS.En tiempo de ejecución, los bloques son mapeadosde forma cíclica en los SMs. Los bloques, en turnos,son divididos en conjuntos de hilos llamados warps,el tamaño de warp (ws = 32) está definido por la ar-JP2011-136

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011quitectura. Actualmente, los SMs están compuestospor treinta y dos SPs en las arquitecturas Fermi másextendidas [19], [20].Para optimizar la explotación de la arquitecturaGPU de NVIDIA, el programador tiende a maximizar:(1) el ratio entre el número de warps activospor multiprocesador y el número máximo de (posibles)warps activos; este propósito se puede lograr:eligiendo el valor óptimo de BS, balanceando la cargade trabajo de los hilos y evitando las instrucciones decontrol de flujo que podrían causar la divergencia delos hilos, (por ejemplo, manteniendo los multiprocesadoresen el dispositivo tan ocupados como sea posible);y (2) el ancho de banda de memoria; el manejode la memoria se optimiza cuando el patrón de accesode los diferentes hilos pertenecientes a cada halfwarp(16 hilos) verifica las condiciones de coalescenciay alineamiento. Los accesos a memoria puedenllevarse a cabo en paralelo y la latencia de memoriasería la misma que para un solo acceso. Además, elhecho de utilizar la cache de texturas como memoriacache mejora el rendimiento [19].Aparte de CUDA, NVIDIA proporciona un conjuntode rutinas básicas o librerías (CuBLAS yCuFFT) que aceleran de forma óptima una ampliavariedad de operaciones con matrices sobre GPUs.Se han desarrollado múltiples implementaciones delSpMV basadas en CUDA [6], [7], [8], [9], [10] ya quela operación SpMV es, en realidad, la clave en el desarrollodel método BCG utilizando GPUs.Nosotros hemos seleccionado dos implementacionesCUDA para computar el SpMV con el finde implementar el método BCG sobre GPUs: (1)el kernel incluido en la librería CUSPARSE [6] y(2) el kernel ELLR-T que está basado en el formatoELLPACK-R [10], [11]. La evaluación comparativadescrita en [10] muestra que ELLR-T alcanza unrendimiento mejor que otras aproximaciones para laoperación SpMV sobre GPUs. Sin embargo, la rutinapara computar el SpMV de la librería CUSPARSEno está incluida en el mencionado estudio. En nuestrotrabajo, hemos seleccionado ambos kernels paracomputar la operación SpMV y poder desarrollar elmétodo BCG sobre GPUs.La clave de este artículo es el desarrollo y evaluaciónde las implementaciones del BCG basadasen ambos kernels. En adelante, la implementaciónbasada en la librería CUSPARSE será referenciadacomo CuBCG CS , y la implementación basada en larutina ELLR-T se denominará CuBCG ET . A continuaciónse describen ambas aproximaciones con detalle:• CuBCG CS se basa en la librería CUSPARSEla cual proporciona un conjunto de subrutinasbásicas de álgebra lineal para el manejo de matricesdispersas. El formato utilizado para compactarlas matrices es el de almacenamientocomprimido por fila (CRS). El paradigma dela librería CUSPARSE es el siguiente: se definenmúltiples bloques, B i , en función de la dimensiónde A, donde cada bloque está encargadode procesar un grupo de filas, (G j ). Y acada fila se le asignada un grupo de hilos, T k .Además, se han tenido en cuenta una serie deconsideraciones adicionales para incrementar elrendimiento: (1) ajustar el número de hilos porfila para evitar el desequilibrio entre hilos; (2)alinear hilos por fila para favorecer la coalescenciay (3) utilizar tanto la memoria compartidacomo la memoria de texturas [6].• CuBCG ET se basa en la rutina de ELLR-T cuyoformato es el ELLPACK-R, el cual permite almacenarla matriz dispersa de una forma regular.Para el formato ELLR-T, cada conjuntode T hilos calcula un elemento del vector desalida. El acceso de la matriz a la memoriaglobal es coalescente y alineado. Según el mapeadode los hilos en la computación de cada fila,se pueden ejecutar múltiples configuraciones delformato ELLR-T. Para optimizar el rendimientodel método, los valores de dos parámetros. elnúmero de hilos (T ) y el tamaño de bloque delos hilos (BS), deben modificarse para cada tipode matrices dispersasEn la siguiente sección se muestran los rendimientosobtenidos al evaluar la operación SpMV sobrelos formatos CUSPARSE y ELLR-T, así comopara nuestras implementaciones del método BCG:CuBCG CU y CuBCG ET .IV. EvaluaciónPara evaluar los tiempos de ejecución de nuestrosdesarrollos, hemos empleado dos conjuntos distintosde matrices dispersas sobre la plataforma GPUGeForce GTX 480. Estas matrices de testeo procedende un amplio espectro de disciplinas relacionadascon la ciencia y la ingeniería. Por lo tanto, podemosencontrar tanto matrices regulares y bien estructuras,como matrices con una gran irregularidady desequilibrio en el número de elementos no nulospor fila. La Tabla I ilustra los principales parámetrosde estas matrices: número de filas (N), número totalde elementos no nulos (nz) y promedio de entradaspor fila (Av). Resulta de interés destacar que la dimensiónde todas las matrices es N x N.En los experimentos realizados para evaluar elrendimiento de los kernels CUSPARSE y ELLR-T, para cada matriz de prueba, se ha consideradola configuración óptima de los parámetros T yBS. Además, los productos escalares se han aceleradogracias a la librería CUBLAS. En cuanto alos conjuntos de matrices de tipo real y complejo,los elementos han sido almacenados como uno o dosnúmeros reales, respectivamente.La figura 1 muestra el rendimiento (GFLOPs)de la operación SpMV sobre la plataforma GPUGeForce GTX 480, utilizando los kernels CUS-PARSE y ELLR-T (para tipos de datos reales y complejos).Cada prueba ha consistido en 1000 ejecucionesde la rutina SpMV, obteniendo así tiempos deejecución fiables. Los lenguajes de programación utilizadospara diseñar los códigos han sido C y CUDA.JP2011-137

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA ICaracterísticas de las matrices de testeo.Matriz real N nz Avwbp 16384 3933097 240cant 62451 4007384 64pdb1HYS 36417 4344766 119consph 83334 6010481 72shipsec1 140874 7813404 55pwtk 217918 11634425 53wbp256 65536 31413934 479Matriz compleja N nz Avkim1 38415 933195 24femfilter 74062 1731206 23NN70 729000 5086618 7NN80 1000000 6979798 7NN90 1331000 9292578 7kim2 456976 11330020 24femhifreqcircuit 491100 20239237 41Los resultados de la Figura 1 muestran que losmejores rendimientos para todas las matrices consideradasson alcanzados por ELLR-T. Esto es debidoa que dicho kernel es capaz de adaptarse al patrónde las matrices dispersas involucradas en el sistema,utilizando para ello el parámetro T . El kernel CUS-PARSE, sin embargo, presenta una pobre flexibilidadya que dicho parámetro no puede ser modificado.Es importante resaltar que el rendimiento deambos formatos normalmente incrementa al aumentarel número de elementos no nulos de la matriz.Las mejoras de rendimiento de la operación SpMValcanzadas por los kernels ELLR-T y CUSPARSEdenotan que las implementaciones del método BCGbasado en SpMV ELLR-T y SpMV CUSPARSEpueden obtener buenos rendimientos. Por lotanto, hemos realizado un análisis comparativo delrendimiento de las dos aproximaciones para resolverel método BCG: el método CuBCG CS (basado en elkernel CUSPARSE) y el método CuBCG ET (basadoen el kernel ELLR-T).La Figura 2 muestra el rendimiento (GFLOPs) alcanzadopor los métodos CuBCG CS y CuBCG ETpara la resolución de sistemas de ecuaciones lineales,reales y complejos, respectivamente. Para el objetivode estimar el rendimiento proporcionado por GPUSpara estos métodos, hemos considerado los mismosvalores de los parámetros de la mejor configuraciónpara las operaciones SpMV, cuyo rendimiento se ilustraen la Figura 1.Los resultados mostrados en la Figura 2 ilustranlas siguientes consideraciones: (1) el rendimientoobtenido por ambos métodos aumenta al incrementarseel número de entradas no nulas en la matriz.Este comportamiento sugiere que, en general,conforme la dimensión de las matrices aumente, elrendimiento será mejor (sobre todo para el conjuntode matrices complejas). (2) Para ambos conjuntosde matrices consideradas, los mejores rendimientosson alcanzados por el método CuBCG ET .Fig. 1Rendimiento de la operación SpMV basada en loskernels CUSPARSE y ELLR-T sobre GPU GeForceGTX 480 con dos conjuntos de matrices de testeo(reales y complejas).Para estimar las mejoras proporcionadas por laGPU en las dos implementaciones del método BCG,hemos considerado la versión optimizada del SpMVpara un procesador moderno. Esta implementacióndel método BCG está basada en la librería MKL [21]para el cómputo de las operaciones SpMV sobre unprocesador superescalar actual (Intel Xeon Westmerecon 8 procesadores). La Tabla II muestra los factoresde ganancia obtenidos por los métodos CuBCG CS yCuBCG ET sobre la GPU GTX 480 frente a la ejecucióndel método BCG sobre un procesador de ochonúcleos, considerando los dos conjuntos de matricesde testeo. Los resultados muestran que los factoresde ganancia en ambos desarrollos GPU son mejoresque la implementación multicore. Así, CuBCG CSCuBCG ET toman ventaja del paradigma de programaciónde las GPUs.Para las matrices de testeo consideradas, los speedup alcanzan valores entre 1,95× y 11,60× para elmétodo CuBCG ET y entre 1,03× y 5,07× para elmétodo CuBCG CS . La Tabla II ilustra que el speedup alcanzado por CuBCG ET es siempre mayor queel de CuBCG CS para todas las matrices. Merece lapena destacar que este hecho es más relevante cuandolas matrices son de tipo complejo.JP2011-138

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IISpeed Up para los métodos CuBCG CS y CuBCG ETfrente a la versión multicore (8 cores) del BCGutilizando la librería MKL.Matriz real CuBCG CS CuBCG ETwbp128 3,48 4,44cant 1,76 2,40pdb1HYS 3,43 4,78consph 1,89 2,29shipsec1 3,12 3,99pwtk 1,68 2,62wbp256 4,09 4,41Matriz compleja CuBCG CS CuBCG ETkim1 1,03 1,95femfilter 1,38 3,16NN70 4,94 8,88NN80 5,07 9,27NN90 3,52 11,60kim2 1,90 6,92femhifreqcircuit 2,93 7,25Fig. 2Rendimiento de las aproximaciones BCG (CuBCG CS yCuBCG ET ) sobre GPU GeForce GTX 480 con dosconjuntos de matrices de testeo (reales andcomplejas).V. ConclusiónSe han desarrollado dos implementaciones delmétodo BCG (CuBCG CS y CuBCG ET ) con el objetivode resolver sistemas de ecuaciones lineales nosimétricos y complejos utilizando GPUs. Tanto losproductos escalares como las operaciones SpMV involucradosen las iteraciones del método BCG hansido acelerados utilizando GPUs. Para ello, se handesarrollado dos métodos, CuBCG CS y CuBCG ET ,basados en los kernels CUSPARSE y ELLR-T, capacesde computar la operación SpMV en la GPU,respectivamente. Los resultados de evaluación muestranque el rendimiento para ambas implementacionesdepende fuertemente del patrón de la matrizde coeficientes. Sin embargo, después de un extensoestudio utilizando dos conjuntos de matricesde testeo, se puede concluir que la implementaciónCuBCG ET claramente alcanza el mejor rendimientogracias al hecho de que el kernel ELLR-T en el quese basa, puede ser mejor adaptado a los diferentespatrones de las matrices dispersas. Este hecho esespecialmente relevante para matrices de tipo complejoya que la consideración del espacio complejoenvuelve un mayor número de operaciones en puntoflotante.Además, la evaluación del método CuBCG ET enuna GPU GeForce GTX 480 ha revelado que los factoresde aceleración tienen un rango entre 2× y 12×en comparación con la versión optimizada del métodoBCG que explota el estado del arte de un procesadorsuperescalar con 8 núcleos.Por último, resaltar que nuestra implementaciónCuBCG ET basada en la computación GPU permiteextender la dimensión del sistema de ecuaciones linealesa resolver para así poder tratar con un rangomayor de aplicaciones.AgradecimientosEste trabajo ha sido parcialmente financiado porsubvenciones de la Junta de Andalucía (P08-TIC-3518, P10-TIC-6002) y el Ministerio de Ciencia e Innovación(TIN2008-01117), en parte financiado porel Fondo Europeo de Desarrollo Regional (FEDER).Referencias[1] Gene H. Golub and Charles F. van Van Loan, MatrixComputations (Johns Hopkins Studies in MathematicalSciences)(3rd Edition), The Johns Hopkins UniversityPress, Oct. 1996.[2] Yousef Saad, Iterative Methods for Sparse Linear Systems,Second Edition, Society for Industrial and AppliedMathematics, Apr. 2003.[3] Abhijeet Gaikwad and Ioane Muni Toke, “Parallel iterativelinear solvers on gpu: A financial engineering case,”in Proceedings of the 2010 18th Euromicro Conferenceon Parallel, Distributed and Network-based Processing,Washington, DC, USA, 2010, PDP ’10, pp. 607–614,IEEE Computer Society.[4] Norberto Garcia, “Parallel power flow solutions using abiconjugate gradient algorithm and a newton method: Agpu-based approach,” July 2010, pp. 1–4.JP2011-139

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011[5] Marcin Wozniak, Tomasz Olas, and RomanWyrzykowski, “Parallel implementation of conjugategradient method on graphics processors,” inParallel Processing and Applied Mathematics, RomanWyrzykowski, Jack Dongarra, Konrad Karczewski, andJerzy Wasniewski, Eds., vol. 6067 of Lecture Notesin Computer Science, pp. 125–135. Springer Berlin /Heidelberg, 2010.[6] NVIDIA, “Cuda cusparse library,” Tech. Rep., September2010.[7] M M Baskaran and R Bordawekar, “Optimizing sparsematrix-vector multiplication on GPUs,” Tech. Rep. ResearchReport RC24704, IBM, April 2009.[8] J W Choi, A Singh, and RW Vuduc, “Model-driven autotuningof sparse matrix-vector multiply on GPUs,” inPPoPP ’10: Proceedings of the 15th ACM SIGPLANsymposium on Principles and practice of parallel programming,New York, NY, USA, 2010, pp. 115–126,ACM.[9] NVIDIA, “Cusp library,” Tech. Rep., October 2010.[10] F Vázquez, G Ortega, J J Fernández, and E M Garzón,“Improving the performance of the sparse matrix vectorproduct with GPUs,” in 10th IEEE International Conferenceon Computer and Information Technology. CIT2010. 2010, pp. 1146–1151, IEEE Computer Society.[11] F. Vázquez, J. J. Fernández, and E. M. Garzón, “A newapproach for sparse matrix vector product on NVIDIAGPUs,” Concurr. Comput. : Pract. Exper., vol. 23, pp.815–826, June 2011.[12] R. Barrett, M. Berry, T. F. Chan, J. Demmel, J. Donato,J. Dongarra, V. Eijkhout, R. Pozo, C. Romine,and H. Van der Vorst, Templates for the Solution ofLinear Systems: Building Blocks for Iterative Methods,2nd Edition, SIAM, Philadelphia, PA, 1994.[13] William H. Press, Saul A. Teukolsky, William T. Vetterling,and Brian P. Flannery, “Numerical recipes in c: Theart of scientific computing. second edition,” 1992.[14] C. Lanczos, “An iteration method for the solution ofthe eigenvalue problem of linear differential and integraloperators,” J . Res. Nat. Bur. Stand., vol. 45, pp. 255–282, 1950.[15] Cornelius Lanczos, “Solution of systems of linear equationsby minimized iterations,” J. Res. Natl. Bur. Stand,vol. 49, pp. 33–53, 1952.[16] R. Fletcher, “Conjugate gradient methods for indefinitesystems,” vol. 506, pp. 73–89. Springer Berlin / Heidelberg,1976.[17] D. A. H. Jacobs, “The exploitation of sparsity by iterativemethods in sparse matrices and their uses,” I. S. Duff.,pp. 191–222, 1981.[18] Nathan Bell and Michael Garland, “Implementing sparsematrix-vector multiplication on throughput-oriented processors,”in Proceedings of the Conference on High PerformanceComputing Networking, Storage and Analysis,New York, NY, USA, 2009, SC ’09, pp. 18:1–18:11, ACM.[19] NVIDIA, “Cuda programming guide. version 2.3,” 2009.[20] NVIDIA, “Next generation CUDA architecture. FermiArchitecture,” 2010.[21] INTEL, “Math kernel library. reference manual,” 2009.JP2011-140

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Paralelización del cálculo de coeficientes delMétodo de Elementos de Contorno en laresolución de problemas de contactotermoelástico 3DRaquel González 1 , Lidia Sánchez 2 y José Vallepuga 3Resumen— Este artículo propone varios algoritmosparalelos para la optimización de una aplicación desarrolladaen Fortran para la resolución de problemasde contacto entre sólidos tridimensionales mediante elmétodo de los elementos de contorno (MEC). El usode librerías de funciones paralelas como MPI permitela consecución de grandes mejoras en cuanto a tiempode cálculo de forma sencilla. Los experimentos realizadosen un cluster de memoria distribuida muestranla efectividad de este tipo de programación.Palabras clave— Problemas de contacto termoelástico,Método de los Elementos de Contorno, MPI,paralelización.I. IntroducciónEN los últimos tiempos, se han desarrollado diversasaplicaciones que implementan el Método delos Elementos de Contorno (MEC) aplicado a distintoscampos, como pueden ser la obtención de imágenesde origen electromagnético [1], la resoluciónde problemas de dispersión acústica [2], o, como ennuestro caso, la resolución de problemas de contacto,tanto para el caso bidimensional [3], [4], como para eltridimensional [5]. En [6] se propone un método iterativopara resolver problemas de contacto termoelásticoentre sólidos tridimensionales usando MEC. Apesar de que el MEC hace uso de una cantidad muchomenor de datos y de cálculo que otros métodosnuméricos como el MEF (Método de los ElementosFinitos), sigue requiriendo de grandes cantidades detiempo y de memoria para su ejecución. Por estarazón, se pueden encontrar diversos trabajos queversan sobre la optimización de los cálculos, minimizandoel espacio y tiempo requeridos mediante eluso de sistemas de memoria distribuida, clusters decomputadores, etc.Por ejemplo, para el caso bidimensional, Kreinmeyery Stein [7] realizan una comparativa entre dosimplementaciones paralelas del MEC: una para la resolucióndirecta del sistema de ecuaciones linealesmediante descomposición LU, y otra para la resoluciónde dicho sistema de forma iterativa. Para elcaso tridimensional, Natarajan y Krinshnaswamy [8]implementan MEC de forma paralela para un sistemade memoria distribuida. Para la paralelización,1 Dpto. de Ingenierías Mecánica, Informática y Aeroespacial,Univ. de León2 Dpto. de Ingenierías Mecánica, Informática y Aeroespacial,Univ. de León, e-mail: lidia.sanchez@unileon.es3 Dpto. de Tecnología Minera, Topografía y de Estructuras,Univ. de Leónrealizan el particionamiento de datos mediante eluso de una topología de procesadores (taurus 2D).Bucheau et al. [9] aplican distintas estrategiasde paralelización sobre una matriz comprimida medianteFMM (Fast Multipole Method), como son lavectorización, la programación multihilo en sistemasde memoria compartida, y la programación multiprocesoen sistemas de memoria distribuida. Cunha etal. [10], [11], [12] presentan en sus distintos trabajosla utilización de librerías de programación paralela,Lapack y ScaLapack, para la paralelización de códigosque implementan el MEC tanto en sistemas dememoria compartida, como en sistemas de memoriadistribuida. En ambos casos hacen uso de unatopología de procesadores para el particionamientode datos.En este artículo se detallan un conjunto de implementacionesparalelas del MEC, realizadas medianteel uso de la librería MPI, en un sistema de memoriadistribuida.II. MétodosA. Introducción al problemaLa paralelización se ha realizado sobre un códigodesarrollado en Fortran en [6] para la resolución deproblemas termoelásticos de contacto entre sólidostridimensionales mediante el método de los elementosde contorno. El código está dividido en 3 partesperfectamente diferenciadas:1. La discretización de los sólidos, que en nuestrocaso consiste en generar un malla de elementostriangulares constantes sobre el contorno de dichossólidos.2. El cálculo de los coeficientes, el cual necesita delcálculo de una integral de contorno que se realizadesde cada uno de los nodos sobre cada unode los elementos que forman el contorno. Comoen este caso el método utilizado considera tansólo un nodo por elemento, es necesario resolverN 2 integrales, siendo N el número de elementosque forman el mallado. Este número puedeaumentar en función de:• Las subdivisiones: cuando un nodo se integrasobre un elemento próximo, este elemento sesubdivide con el fin de generar una malla másfina. Esto permite una mejor precisión, perotambién incrementa el número de integrales aresolver.JP2011-141

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011• Las simetrías: cuando un problema presentasimetría, los elementos simétricos no se almacenanen memoria, pero hay que tenerlos encuenta a la hora de realizar los cálculos, yaque no es necesario integrar desde los nodosde estos elementos, pero sí hay que integrarsobre ellos.3. El montaje y resolución del sistema de ecuacioneslineales generado a partir de los coeficientescalculados en el paso anterior. Se tratade un sistema de N × N ecuaciones para el problematérmico de potencial, y de un sistema de3N × 3N ecuaciones para el problema elástico.Cuando se trata de un problema termoelástico,se deben resolver ambos sistemas.B. Cálculo de coeficientesEn este artículo, presentamos una primera aproximaciónpara la paralelización del cálculo de los coeficientes.Este paso es relativamente fácil de abordar,ya que cada una de las integrales de contorno es independientedel resto.Como se ha indicado anteriormente (sección II-A), han de integrarse todos los nodos sobre todoslos elementos, incluido el elemento al que pertenece.Cuando un nodo se integra sobre sí mismo se resuelveuna integral analítica, mientras que si se integra sobreotro diferente, se resuelve una integral numérica.De esta forma, el algoritmo secuencial utilizado seríael detallado en el Algorimo 1.Algoritmo 1 Algoritmo secuencial para el cálculode coeficientes.for i = 1 → N do {desde cada elemento}for j = 1 → N do {sobre cada nodo}if i = j thenIntegralAnalitica(e i )elseIntegralNumerica(e i ,e j )end ifend forend forA partir de éste, se han implementado dos algoritmosdiferentes de distribución del trabajo entre losdistintos procesadores.B.1 Distribución directaEn este primer algoritmo, se distribuye el trabajode uno de los bucles de foma equitativa entre losdistintos procesadores.Si distribuimos el bucle interior, es decir, los elementos,en cada iteración del bucle exterior, se integrael elemento e i sobre N/p nodos, y se envíanlos resultados al procesador maestro (ver Algoritmo2). En este caso el envío y recepción de datos seproduce del orden de N × nEsclavos veces, perola cantidad de datos a enviar es relativamente pequeña(N/nEsclavos) siendo nEsclavos el númerode procesadores esclavos.Algoritmo 2 Algoritmo paralelo. Distribución delbucle interior.for i = 1 → N doif rank ≥ 0 then {si es procesador esclavo}for j = 1 → N/nEsclavos doif i = j thenIntegralAnalitica(e i )elseIntegralNumerica(e i ,e j )end ifPack() {empaqueta los datos para su envío}end forSend(datos,0) {enviamos datos empaquetadosal maestro}else {si es procesador maestro}for j = 1 → nEsclavos doRecv(datos,j) {recibimos datos empaquetadosdesde cada esclavo}Unpack() {desempaquetamos los datos recibidos}end forend ifend forSi distribuimos el bucle exterior, es decir, los nodos,se integran grupos de N/nEsclavos elementossobre N nodos en cada procesador esclavo, y se envíanlos resultados al maestro (ver Algoritmo 3). Eneste caso el envío y recepción de datos se producetan sólo nEsclavos veces, pero la cantidad de datosa enviar es mucho mayor (N/nEsclavos × N).Algoritmo 3 Algoritmo paralelo. Distribución delbucle exterior.if rank ≥ 0 then {si es procesador esclavo}for i = 1 → N/nEsclavos dofor j = 1 → N doif i = j thenIntegralAnalitica(e i )elseIntegralNumerica(e i ,e j )end ifPack() {empaqueta los datos para su envío}end forend forSend(datos,0) {enviamos datos empaquetados almaestro}else {si es procesador maestro}for i = 1 → nEsclavos doRecv(datos,i) {recibimos datos empaquetadosdesde cada esclavo}Unpack() {desempaquetamos los datos recibidos}end forend ifUna comparativa entre estas dos distribuciones semuestra en la figura 1 y en la tabla I. En ella sepuede apreciar que las diferencias entre los tiemposno son muy significativas, pero son algo menores losobtenidos mediante la distribución del bucle interior,JP2011-142

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011a pesar de ser la que mayor comunicación conlleva.Fig. 1. Comparativa de tiempos en función del bucle distribuido.En ambos casos, cuando se emplean 1 ó 2 esclavos,el tiempo de ejecución no mejora respecto al casosecuencial debido a la penalización de tiempo existente enla comunicación con el maestro. A partir de 4 esclavosla mejora es significativa. Con 8 esclavos conseguimos eltiempo mínimo. A partir de 8, la penalización de tiempoen la comunicación vuelve a ser mayor que la mejora quesupone añadir un procesador más para el cálculo.TABLA IComparativa de tiempos de ejecución y porcentajesde reducción en función del bucle distribuidoBucle InteriorBucle ExteriorTiempo % tiempo Tiempo % tiempo0 46,96 100,00 46,96 100,002 56,33 119,97 60,68 129,234 28,75 61,23 31,56 67,216 18,92 40,29 22,57 48,068 4,54 9,68 6,57 13,9910 9,27 19,75 11,60 24,7015 6,45 13,74 11,98 25,5220 6,71 14,29 10,18 21,67B.2 Creación de una topología de procesadoresAlgunos autores proponen la creación de unatopología de procesadores para la distribución delcálculo de coeficientes. Como el objetivo del cálculode estas integrales es el montaje de la matrizdel sistema de ecuaciones lineal, Geng et al. [2] proponendistribuir el montaje de esta matriz, ya seaasignando a cada procesador un bloque de matriz arellenar (para lo cual cada procesador necesita losdatos de todos los elementos), o asignando a cadaprocesador la información de un subconjunto de elementosque colaboran en la formación de la matrizglobal (para lo cual cada procesador necesita teneracceso a toda la matriz).Nuestro programa usa un algoritmo iterativo parala resolución del sistema de ecuaciones lineales, deforma que en cada iteración se monta la matriz delsistema a partir de los resultados de las integrales decontorno, y se resuelve, repitiendo el proceso hastaque la solución converja. Es por esto que, en nuestrocaso, primero realizamos todas las integrales decontorno y guardamos los resultados. A pesar deque esto supone un gasto considerable de memoria,supone también un ahorro considerable en tiempo decómputo, ya que a la hora de realizar el montaje noes necesario volver a resolver las integrales.Para almacenar los resultados, lo que buscamos esrellenar una matriz de coeficientes de la forma⎛⎞A 1,1 · · · A 1,N⎜A =⎝..⎟. ⎠A N,1 · · · A N,Ndonde A i,j es el resultado de la integración del elementoi sobre el nodo j.Para ello, creamos una topología de procesadores⎛P =⎜⎝⎞P 1,1 · · · P 1,C..⎟. ⎠P R,1 · · · P R,Csiendo R el número de filas y C el de columnas.P i,j es cada uno de los procesadores de quedisponemos, y se encargará de integrar N/R elementossobre N/C nodos, o lo que es lo mismo, rellenaruna submatriz de A de N/R × N/C elementos.III. Resultados experimentalesLos experimentos se han realizado en el clusterMPI del supercomputador Caléndula de la Fundacióndel Centro de Supercomputación de Castilla yLeón. El código paralelo se ha programado medianteel uso de funciones de la librería MPI para Fortran.El problema sobre el que se han realizado los experimentosse trata de un problema termoelásticocon simetría respecto al plano YZ, que ha sido discretizadoen un total de 5120 elementos, lo que significaque han de resolverse 5120 × (2 × 5120) integralesde contorno, es decir, cada nodo debe integrarsesobre todos los elementos y sobre sus simétricos.Hasta ahora sólo se ha programado la resolucióndel problema para topologías de procesadorescuadradas, es decir, en las que R = C.La figura 2 y la tabla II muestran una comparativade tiempos entre los dos algoritmos de paralelizaciónprobados.TABLA IIComparativa de tiempos de ejecución y porcentajesde reducción entre la distribución directa y el usode una topología de procesadores (5120 elementos)Distribución directaTopologíaTiempo % tiempo Tiempo % tiempo1x1 46,96 100,00 46,26 100,002x2 37,32 79,48 46,01 99,453x3 5,63 11,98 18,08 39,094x4 5,65 12,04 11,54 24,945x5 4,53 9,65 9,14 19,75JP2011-143

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2. Comparativa entre la distribución directa y el usode una topología de procesadores para 5120 elementos.Desde la topología cuadrada más pequeña, y en relaciónal caso secuencial (1x1), los tiempos de ejecución mejoranprogresivamente, aunque en menor medida que en el casode la distribución directa, donde el balanceo de carga esmejor.Como se puede observar, para un número elevadode procesadores, presenta mejores tiempos el algoritmode distribución directa. Esto se debe a que,como se mencionó en el apartado II-B, cuando se integradesde un elemento sobre sí mismo, la integral esanalítica, y en otro caso numérica. Esto provoca quepara el caso de distribución directa la carga de trabajoesté mejor distribuida, ya que cada procesadordebe integrar los nodos que se le envían sobre el totalde elementos, incluidos ellos mismos, mientras que enel caso de utilizar la topología de procesadores, aquellosque no están situados sobre la diagonal principalen la matriz de procesadores, no realizarán ningunaintegral analítica.Además, para el caso en que la ejecución se realizaen 9 procesadores es mucho mejor el algoritmo dedistribución directa. Esto es resultado de que 2560,que es el número total de elementos, es divisible entre8, que son los esclavos entre los que se reparte lacarga de trabajo en el algoritmo de distribución directa;sin embargo, 2560 no es divisible entre 3, quees el número de procesadores en cada fila y en cadacolumna en el caso de utilizar una topología.La figura 3 y la tabla III muestran una comparativapara un segundo problema, en este caso un problemaelástico sin simetría, en que el número de elementosdel mallado es 4704, por lo que, al no habersimetría, el número de integrales a calcular es 4704 2 .El hecho de que no exista ningún tipo de simetríahace que el número de integrales numéricas a realizarsea menor, lo que a su vez provoca que se acentúenmás las diferencias entre el primer algoritmo, dondeel balanceo de carga es mejor, y el segundo.IV. ConclusionesEn este trabajo se han estudiado distintas implementacionesparalelas del Método de los Elementosde Contorno. Todas ellas presentan mejoras temporalesrespecto al código secuencial, pero, en funcióndel tipo de problema a resolver, puede resultar másinteresante una u otra estrategia. Los experimentosrealizados muestran mejoras de hasta un 90,32% enla paralelización directa del bucle interior, y de unFig. 3. Comparativa entre la distribución directa y el uso deuna topología de procesadores para 4704 elementos. Lareducción del tiempo de ejecución es significativa desdela topología más pequeña. Las diferencias respecto a ladistribución directa son grandes ya que la ausencia desimetría produce un mayor desequilibrio en la carga.TABLA IIIComparativa de tiempos de ejecución y porcentajesde reducción entre la distribución directa y el usode una topología de procesadores (4704 elementos).Distribución directaTopologíaTiempo % tiempo Tiempo % tiempo1x1 20,61 100,00 20,15 100,002x2 18,02 87,42 17,96 89,113x3 0,81 3,91 8,64 42,854x4 2,25 10,91 5,75 28,525x5 1,80 8,73 4,40 21,8186,01% en el exterior (véase tabla I). Una mayoreficiencia se gana cuando se dan condiciones idealesde distribución de datos, es decir, cuando el númerode elementos es múltiplo del número de procesadoresesclavos entre los que se distribuye el cálculo. El usode una topología de procesadores para la distribuciónde los datos presenta mejoras menores pero tambiénsignificativas de hasta un 80,25% (ver tabla II) parael caso ideal en que el número de elementos del malladoes múltiplo del número de procesadores en cadafila y columna de la matriz de la topología, y ademáses un número elevado (matriz de 5×5). El primer algoritmopresenta una mejor distribución de la carga,mientras que el segundo presenta grandes ventajasde cara a crear la matriz del sistema directamente,eliminando el paso intermedio de almacenarlos parasu posterior utilización. Esto puede ser ventajoso enaquellos problemas cuya convergencia se produzca enun número pequeño de iteraciones, y por tanto, nohaya que realizar el cálculo de coeficientes en muchasocasiones.AgradecimientosEste trabajo ha sido realizado gracias al programade becas de formación de Personal Docente e Investigadorde la Universidad de León, y la colaboraciónde la Fundación del Centro de Supercomputación deCastilla y León.JP2011-144

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Referencias[1] Y Ataseven, Z Akalin-Acar, C E Acar, and N G Gençer,“Parallel implementation of the accelerated bem approachfor emsi of the human brain,” Med Biol EngComput, vol. 46, pp. 671–679, 2008.[2] P Geng, J T Oden, and R A van de Geijn, “Massivelyparallel computation for acoustical scattering problemsusing boundary element methods,” Journal of Sound andVibration, vol. 191, pp. 145–165, 1996.[3] T Andersson, B Fredriksson, and B G A Persson, “Theboundary element method applied to two-dimensionalcontact problems,” in New developments in boundaryelement methods. Proceedings of the Second InternationalSeminar on Recent Advances in Boundary ElementMethods. Southampton, England., 1980, pp. 247–263.[4] J A González, Estudio de problemas de contacto incluyendorodadura mediante el método de los elementosde contorno, Ph.D. thesis, Universidad de Sevilla, 2001.[5] A Foces y F París J A Garrido, “Three dimensional frictioncontact using b.e.m.,” in Advances in BoundaryElements XIII, Computational Mechanics Publications.,Springer-Verlag, Ed., 1991.[6] José Vallepuga, Análisis del problema de contactotermoelástico tridimensional sin fricción mediante elmétodo de los elementos de contorno, aplicación enmicro-electrónica, Ph.D. thesis, Universidad de Valladolid,2010.[7] M Kreienmeyer and E Stein, “Parallel implementation ofthe boundary element method for linear elastic problemson a mimd parallel computer,” Computational Mechanics,vol. 15, pp. 342–349, 1995.[8] R Natarajan and D Krishnaswamy, “A case study in parallelscientific computing: the boundary element methodon a distributed-memory multicomputer,” EngineeringAnalysis with Boundary Element, vol. 18, pp. 183–193,1996.[9] André Buchau, Wolfgang Hafla, Friedemann Groh, andWolfgang M Rucker, “Parallelized computation of compressedbem matrices on multiprocessor computer clusters,”The International Journal for Computation andMathematics in Electrical and Electronic Engineering,vol. 24, pp. 468–479, 2005.[10] M T F Cunha, J C F Telles, and A L G A Coutinho, “Parallelboundary elements using lapack and scalapack,” inProceedings of the 14th Symposium on Computer Architectureand High Performance Computing, 2002.[11] M T F Cunha, J C F Telles, and A L G A Coutinho, “Aportable parallel implementation of a boundary elementelastostatic code for shared and distributed memory systems,”Advances in Engineering Software, vol. 35, pp.453–460, 2004.[12] M T F Cunha, J C F Telles, A L G A Coutinho, andJ Panetta, “On the parallelization of boundary elementcodes using standard and portable libraries,” EngineeringAnalysis with Boundary Elements, vol. 28, pp. 893–902,2004.JP2011-145

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-146

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Iterative procedure to solve thermoelasticcontact problems between 3D solids usingBEM and OOPAna M a Suárez Rivero 1 , Raquel González 2 , Lidia Sánchez 3 y J. Vallepuga Espinosa 4Resumen— This paper describes the resolution processin an application developed to solve contactproblems between three-dimensional solids using theBoundary Element Method (BEM). Considering aprevious designed application using OPP (Object OrientedProgramming) techniques, an iterative processto solve thermal, elastic and thermoelastic contactproblems has been implemented and Gauss JordanMethod is used to solve the obtained equation system.The proposed application reduces the executiontime of the previous FORTRAN program as it isshowed for several experiments of thermal, elastic andthermoelastic contact problem resolution between 3Dsolids.Palabras clave— Boundary element method, thermoelasticcontact problems, Gauss Jordan Method,OOP.I. IntroductionTHERE are a lot of researchers that have studiedthe contact problem between solids in the lastfew decades. In the study of this problem, they haveused different numerical methods, as for example,Finite Element Method (FEM) used by Wilson [17],Chan and Tuba [5] o Wriggers [18], or the BoundaryElement Method (BEM) used by Anderson [4]to solve bidimensional contact problems. Gracini[6] uses the theory to solve contact problems betweensolids with axial symmetry. Working withtree-dimensional solids, Emperador [3] applies thismethod to solve elastodynamics problems and Gonzalez[10] applies this method in the resolution ofrolling contact problems. Gracini [6] uses the theoryto solve contact problems between solids with axialsymmetry.The Boundary Element Method has its origins inBetti’s reciprocal theorem and in Somigliana’s identityfrom mid XIXth century. Since sixties, BEMstarted to be applied in the resolution of engineeringproblems [13], and, in 1967, the first research thatdeveloped a program used to solve elasticity problems[14], was published.It is remarkable to say its application is possible touse in different areas, like stress analysis, potentialflow, mechanical fracture, acoustics [9] and electromagnetism[1], [15]. Also, it is possible to be used asa CAD tool for electrical, mechanical or civil engi-1 Dpto. de Ingenierías Mecánica, Informática y Aeroespacial,Univ. de León, e-mail: amsuar@unileon.es.2 Dpto. de Ingenierías Mecánica, Informática y Aeroespacial,Univ. de León, e-mail: raquel.gonzalez@unileon.es.3 Dpto. de Ingenierías Mecánica, Informática y Aeroespacial,Univ. de León, e-mail: lidia.sanchez@unileon.es.4 Dpto. de Tecnología Minera, Topografía y de Estructuras,Univ. de León, e-mail: jvale@unileon.es.neering [2]. Moreover, this method has been used tosolve thermoelastic contact problems between threedimensionalsolids [8].BEM is a method used to solve differential partialequations, so that it can be only used when theproblem can be represented in a differential equationform. The method is derived from the discretizationof an integral equation that is mathematicallyequivalent to the initial partial differential equation.This equation consists of an integral equation thatis defined in the boundary domain and an integralequation that relates the boundary solution with thepoints in the domain. This integral equation is calledboundary integral equation. To solve this equation,a technique that converts this integral into a linearequation system is applied. There is a huge varietyof derivation methods of equation systems that takesas basis the integral equation, which can be appliedto develop a particular boundary element method.However, this new reformulation of the equationcan be only done for some specific types of partialdifferential equations. That is the reason why BEMcan not be only used as a general way, in contrastwith the finite element method or the finite differencesmethod. In spite of that, for those cases whereBEM can be applied, it offers a friendly and efficientnumerical method, more than other ones [2],[16]. BEM consists of meshing solid surfaces. Consequently,fewer nodes are considered, fewer amount ofunknown factors are generated and time execution isreduced [16].In [8], BEM is applied to solve contact problemsbetween three-dimensional solids. Three kinds ofproblems are considered: thermal, elastic and thermoelasticones. An iterative resolution method isproposed and developed using Fortran.The following section describes the problem wedeal with. In section III we present the developedapplication. Section IV shows the experiments andobtained results. Finally, section V gathers theachieved conclusions.II. The thermoelastic contact problem in3DThe thermoelasticity describes solid behavioursthat undergo shape variations as a function of thetemperature. When two solids are contacted, thedistribution of pressures in the contact zone can varywith temperature. If temperature and thermal flowsare known, then, it is possible to determine the realcontact zone between them [8] since generated strainsJP2011-147

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011and stress on the solids can be computed.The most of materials, when their temperature isincreased, they are expanded in a proportional wayto this increment. If it is in a non-define expansion,there is not generated stress on the solid. In contrast,although temperature does not create stresses, thereis a well-known phenomenon named thermal distortion[7]. Such phenomenon curves straight surfacesbecause of the temperature gradient.Those thermoelastic strains are more importantwhen those two solids are in contact, because pressuresin the contact zone are more sensitive to temperaturechanges. If both solids are made by thesame material, curvatures on contact surfaces will beidentical, and the distortion will not have any importance.However, if the distortion capacities of solidsare different, the convexity will increase in the hottersolid, and will decrease in the colder one, causing apressure increment on some regions and a decrementon others.Depending on the distortivities and the directionof the heat flow, two types of contact appear:• Imperfect contact: when the heat flows towardsthe solid with the lesser thermoelasticity distortivity,both systems of lineal equations, thermaland thermoelastic, are coupled by the presenceof a thermal resistance that varies inverselywith the contact pressure.• If heat flows into the material with the larger distortivityis possible to obtain solutions involvinga zone of perfect contact bordered directly byseparation zones. Then, the non linearity is dueto the unknown size of the contact zone.A. DescriptionThe problem is based on two three-dimensionalsolids in contact. Those solids are under a systemof static loads applied in the boundary and a thermalload that is transmitted by conduction inside ofboth solids [8].Depending on the direction of thermal flow, somecontact conditions (perfect or imperfect) are set onthe interface. Stress, movements, temperatures andtemperature gradients on their boundaries are determinedfor both solids.B. Assumed hypothesisThe following hypothesis are assumed to makeeach approach [8]:1. Continuous, homogeneous, elastic and isotropicsolids.2. The conductivity is considered constant for everyrange of temperature used in the problem.3. Short strains and movements.4. Slow temperature variations along the time(quasi-static process).5. Non friction contact.6. Heat transmission by radiation is not considered.C. Problem definitionLet be A and B the two solids considered in eachproblem. Every point y on the boundary of eachsolid is referenced by employing a global coordinatessystem OXYZ, and it is related to a stress array t k j (y)and a displacement array u k j (y) [8]. Moreover, theyhave associated a temperature T k (y) and a thermalgradient q k (y). To solve the problem, boundary isdivided into two areas:1. G (A,B)C, common contact surface for bothsolids.2. G K L , non-contact region of each solid.In general, this boundary division can not beestablished previously since the contact zone canchange during the load process. Therefore, a potentialcontact zone is supposed. Such region includescontact points at the beginning of resolution processand the nearest points that can be in contact in thefinal solution. Resolution process allows us to determinein a iterative way which the actual contact zoneis [8].D. Resolution ProcessFirst we define the type of problem and geometryof the solids that are involved in the problem. Thenwe establish boundary conditions and type of contact.After that, the obtained equation system canbe solved by an iterative process [8]. The resolutionprocess is made up by the following steps:1. Assembly of matrixes equation system Ax=B.2. Resolution of equation system using Gaussmethod.3. Resolution of thermal problem (if it is necessary).4. Resolution of elastic problem (if it is necessary).5. Resolution of thermoelastic problem (if it isnecessary).6. Resolution of the iterative process.III. Application developmentBEMAPEC (Boundary Element Method Appliedto Problems of Elastic Contact) is a Java applicationthat offers a friendly workspace to define andsolve problems between three-dimensional solids usingBEM [11].A. Original BEMAPECBEMAPEC [12] provides an easy way to define thegeometry of solids that are involved in the problem.Those solids are discretized by triangular geometricalmeshes. BEMAPEC also calculates the coefficientsas a result of each element integration that makesup solids. Those coefficients are used in the problemresolution. Finally, BEMAPEC application displaysobtained results graphically using the developmentenvironment OpenGL.JP2011-148

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011B. Improvements on BEMAPEC functionalityUsing the previous version of BEMAPEC [12] wehave developed several improvements. First, we definethe type of problem and the geometry of solidsthat are involved. Then we mesh these solids anddefine boundary conditions and type of contact. Afterthat, BEMAPEC calculates coefficients for eachmeshed element. We build the equation system fromthose coefficients. Finally, the equation system issolved and the whole problem is computed by meansof an iterative process. This last stage, equation systemdefinition and problem resolution, is the functionalityadded to the program.The resolution process comprises the followingsteps:1. Assembly of matrixes equation system Ax=B:the coefficients computed by the integration of eachelement over all the rest, are used to do the assemblyof the A matrix and the B vector for the equation systemAx=B. A and B elements are determined takingin account the solid and the region that each elementbelongs to (contact zone or free zone).2. Resolution of equation system by GaussMethod: to solve the previously obtained equationsystem, it is necessary to use Gauss Method withpivot. This choice is due to effectiveness and efficiencyreasons, so as the intrinsic characteristics ofthe problem that generates a large amount of zerosin A and B.3. Resolution of thermal problem (if it is necessary):this step is considered just for thermal orthermoelastic problems. The process starts with theresolution of the equation system by using the GaussMethod. So we obtain an X vector that is employedto establish boundary conditions in the contact zonefor each element that belongs to the contact surfacesof each solid. This process finishes with the writingof temperature and heat flow parameters related toeach thermal element into a file.4. Resolution of elastic problem (if it is necessary):this stage is carried out for elastic or thermoelasticproblems. First we solve the equation system byGauss Method and the resulting X vector allows usto determine the elastic conditions for each elementof either contact or free zones. Once each element ofboth solids has its boundary condition, relative displacementscan be calculated. Next, every value foreach element of both solids is written in an outputfile. We need now to check the obtained partial results.Firstly, tension checking is made to determinewhich elements are leaving the contact zone. Whenthere are no elements coming into or out from thecontact zone, we write in an output file the new elasticcondition values for every element and the thermalresistance values for those elements that belongto the contact zone.5. Resolution of thermoelastic problem (if it isnecessary): this stage is considered for thermoelasticproblems. In that case, firstly the thermal problemis solved. Then, it is solved the elastic problem.Subsequently, only in the case that contact betweensolids is imperfect, a comparison among thermal resistancesfor those elements that belong to the contactzone is made. If the result of such comparisonis higher than a certain tolerance, thermal resistancevalues will be modified, and process will be repeatedagain.6. Resolution of iterative process (if it is necessary):it could happen, when elastic or thermoelasticproblems are being solved, that some specific conditionscan appear that makes come back to point 1of the resolution, and process would have to be executedagain. Conditions that make the process startsa new iteration depend on the type of problem thatis being solved. So, it is necessary to do the followingdistinction:• Elastic problem: once equation system is solved,results need to be checked. In this case, firstly,tension checking for every element that belongsto the contact zone is carried out. This allows usto determine which elements come out from thecontact zone. Once tension checking is done,if the number of elements that come out fromthe contact zone is zero, interpenetrations arechecked. Interpenetration checking determineswhich elements come into the contact zone.After tension checking is finished, if there is anyelement coming out from the contact zone, theprocess will be repeated. If no-one elementscome out from the contact zone but some elementscome into such zone, the process also willbe repeated.• Thermal problem: in case of thermoelastic problems,process can be repeated because of severalreasons. A reason is the previously explainedone for the elastic problem. Another one is dueto the thermal problem. In that case, the comparisonbetween thermal resistances is carriedout. If the result of this comparison differs fromany tolerance in amount higher than a certainvalue for any element that belongs to the contactzone, the problem will be solved again withthose new resistance values.In short, process will stop when no-one elementcomes into or out from the contact zone (elasticproblem) and thermal resistance differs in an amountlower than a certain value (thermal problem) for everyelement that belongs to the contact zone.IV. Experiments and ResultsWe have carried out several experiments to comparethe execution time for FORTRAN’s applicationversion [8] and BEMAPEC application.A. Thermal problemsProof cases used in the thermal problem are basedon two solids in contact (Fig. 1). Both solids arecubes made up by 640 elements. 128 elements fromeach cube belong to the contact zone. The type ofcontact between solids is perfect, the environmentis vacuum. For those nodes on the potential con-JP2011-149

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tact zone, that remind separated in the final configuration,if it is not considered that energy can takeplace in these zone (vacuum). Reference temperatureis zero. Equation system is made up by 1280equations.1136 equations. In this case, there are not elementscoming into or out from the contact zone in tensionchecking or interpenetrations checking so the processis not repeated5. Proof Case 5: It consists of two solids in contact.Both of them are prisms; solid A is made up by768 elements and solid B is made up by 768 elements.The number of elements that belong to the contactzone is 128 for both solids. Equation system Ax=Bhas 4608 equations. The process is carried out onlyonce.Fig. 1. This figure shows solids of Proof Case 1 on theway they are represented on the BEMAPEC’s applicationgraphical environment. Points are the nodes of each elementobtained after meshing. The grey plane representsYZ symmetry plane.B. Elastic problemsDue to the higher complexity and casuistry in elasticproblems, number of proof cases is higher. Allthe experiments have the following conditions: thetype of contact between solids is perfect, the referencetemperature is zero and the environment is vacuum.For those nodes on the potential contact zone,that remind separated in the final configuration, if itis not considered that energy can take place in thesezone (vacuum). Particular characteristics about eachproof case are shown below:1. Proof Case 1: It consists of two solids in contact.Both of them are prisms; solid A is made upby 384 elements and solid B is made up by 752 elements.The number of elements that belong to thecontact zone is 128 in both cases. Equation systemAx=B has 3408 equations. Resolution process needs5 iterations due to the tension checking.2. Proof Case 2: It consists of two solids in contact(Fig. 2). Both of them are prisms; solid A is madeup by 182 elements and solid B is made up by 218elements. The number of elements that belong to thecontact zone, is 132 for both solids. Equation systemAx=B has 1200 equations. Resolution processrequires 6 iterations due to the tension checking.3. Proof Case 3: It consists of two solids in contact.Both of them are cubes; solid A is made up by200 elements and solid B is made up by 200 elements.The number of elements that belong to the contactzone is 50 in both cases. Equation system Ax=B has1200 equations. In this case, there are not elementscoming into or out from the contact zone in tensionchecking or interpenetrations checking so the processis not repeated.4. Proof Case 4: It consists of two solids in contact.Both of them are prisms; solid A is made upby 656 elements and solid B is made up by 616 elements.The number of elements in the contact zonefor both cases is 128. Equation system Ax=B hasFig. 2. This figure shows solids from Proof Case 2 on theway they are represented on the BEMAPEC’s applicationgraphical environment. Points are the nodes of eachelement obtained after meshing. The white plane representsXZ symmetry plane and the grey one, YZ symmetryplane.C. Thermoelastic problemsAs elastic problems, the number of thermoelasticcase problems is higher. All the cases have the followingcommon conditions: the type of environmentis vacuum and for those nodes on the potential contactzone, that remind separated in the final configuration,if it is not considered that energy can takeplace in these zone (vacuum).1. Proof Case 1: It consists of two solids in contact.Both of them are cubes; solid A is made up by640 elements and solid B is made up by 640 elements.The number of elements of the contact zone is 128for both solids. The type of contact between solidsis imperfect and the reference temperature is zero.Equation system Ax=B has 3840 equations. Resolutionprocess needs 3 iterations due to the thermalpart of the problem.2. Proof Case 2: It consists of two solids in contact.Both of them are cubes; solid A is made up by640 elements and solid B is made up by 640 elements.The number of elements that belong to the contactzone, in both cases, is 128. The type of contact betweensolids is perfect and the reference temperatureis zero. Equation system Ax=B has 3840 equations.Resolution process requires 3 iterations due to theelastic part of the problem, specifically, to the tensionchecking.3. Proof Case 3: It consists of two solids in contact(Fig. 3). Both of them are prisms; solid A is madeup by 384 elements and solid B is made up by 752 elements.The number of elements of the contact zone,in both solids, is 128. The type of contact betweensolids is imperfect and the reference temperature isJP2011-150

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201130. Equation system Ax=B has 3408 equations. Resolutionprocess needs 6 iterations due to the thermalpart of the problem.4. Proof Case 4: It consists of two solids in contact.Both of them are prisms; solid A is made upby 384 elements and solid B is made up by 752 elements.The number of elements that belong to thecontact zone is 128 for both solids. The type of contactbetween solids is imperfect and the referencetemperature is 30. Equation system Ax=B has 3408equations. Resolution process requires 2 iterationsdue to the thermal part of the problem.Fig. 4. This figure shows the execution time comparison of thethermal problem explained. As it is showed, the executiontime in Fortran’s version is bigger than in Java’s version,so, in this case, we have managed a meaningful reductionin execution time.Fig. 3. This figure shows solids from Proof Case 3 as they arerepresented on the BEMAPEC’s application graphical environment.Points are the nodes of each element obtainedafter meshing. The white plane means XZ symmetry andthe grey plane corresponds to YZ symmetry.D. Executed time comparisonPrevious mentioned problems for FORTRAN’s applicationversion and BEMAPEC application aboutexecuted time are displayed as it is shown on thegraphics 4, 5 and 6. When we solved the thermalproblem using JAVA’s application version, we managean improvement because the execution time isreduced. If we analyze results obtained in elasticproblems, we could draw as conclusion that higherthe number of equations which made up the equationsystem is, more significant the reduction in executiontime is. In contrast, when the equation systemis lesser, Java’s application version increase a bit theexecution time, although the difference is not veryimportant.Finally, thermoelastic problems’ behaviour is different.In these problems, it is less important thenumber of equations than the number of iterations.For example, in cases 3 and 4, the number of equationsis the same, but in case 3 there are 4 iterationsmore than in case 2 and we obtained better timeswhen the number of iterations is higher. When thenumber of iterations is less, the execution time ispractically the same.As it is can be observed, the more elements makeup solids, the higher is the difference between times,and therefore, the amount of equations is higher. Inthose cases, Java’s application version is more efficiently.V. Conclusions and Future WorksIn this work, we have used OOP techniques tosolve contact problems between 3D solids. So that,after coefficients have been calculated using the previousversion of BEMAPEC, assembly matrixes ofequation system Ax=B is done. After that, GaussFig. 5. This figure shows the execution time comparison ofelastic problems which have been proved. We managed agreat reduction in cases 1, 4 and 5. However, slightly weget worse the execution time in case 2 and 3. This is dueto our application is more effective when the number ofequations in the equation system is large.Method with pivot is used to solve it because, actually,this is the most efficiently method on resolvingequation systems when the number of them is higher.Then, problem is solved using methods that dependon the type of problem (thermal, elastic o thermoelastic).Process finishes with the writing of obtainedresults into an output file.When equation number that makes up systemequation is large, the execution time for the resolutionproblem is lower in Java’s version than FOR-TRAN’s one. In contrast, when equation system hasfewer equations, the FORTRAN’s version is more efficient.However, in this kind of problems is usual tohave a large number of equations.Further works include to parallelize the resolutionprocess in order to reduce the execution time as wellas using different techniques to solve the equationsystem.VI. AcknowledgementsThis work has been partially supported by the researchgrants program from the University of León(Spain).Referencias[1] Matti Stenroos, Helsinki bem library., [Online]. Available:http://peili.hut.fi/BEM.JP2011-151

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011sis”, Advances in Engineering Software, vol. 37, pp. 248–259, 2006.[17] E. A. Wilson and B. Parsons, Finite element analysis ofelastic contact problems using differential displacements,International Journal for Numerical Methods in Engineering,vol. 2, pp. 387–395. 1969.[18] P. Wriggers, ”Finite element algorithms for contact problems”,Archives of Computational Methods in Engineering,vol. 2, pp. 1–49, 1995.Fig. 6. This figure shows the execution time comparison ofthermoelastic problems. In cases 1 and 3, we manage ameaningful reduction while in cases 2 and 4, the differenceis insignificant.[2] Stephen Kirkup, Boundary element method for laplaceproblems., [Online]. Available: http: //www.boundaryelement-method.com/laplace/manual/chap1/index.htm.[3] J. M. E. Alzola, ”El método de los elementos de contornoen problemas elastodinámicos con simetría de revolución”,Ph.D. dissertation, Las Palmas de Gran Canaria, 1988.[4] T. Andersson, B. Fredriksson, and B. G. A. Persson, ”Theboundary element method applied to two-dimensional contactproblems”, in New developments in boundary elementmethods. Proceedings of the Second International Seminaron Recent Advances in Boundary Element Methods.,Southampton, England., 1980, pp. 247–263.[5] S. K. Chan and I. S. Tuba, ”A finite element methodfor contact problems of solid bodies - part i. theory andvalidation”, International Journal of Mechanical Sciences,vol. 13, pp. 615–625, 1971.[6] E. G. Díaz, ”Formulación e implementación del métodode los elementos de contorno para problemas axisimétricosde contacto. aplicación a la caracterización de la interfasefibra matriz en materiales compuestos”, Ph.D. dissertation,Universidad de Sevilla, 2006.[7] J. Dundurs, ”Distorsion of a body caused by free thermalexpansion”, Mechanics Research Communications, vol. 1,pp. 121–124, 1974.[8] J. V. Espinosa, ”Análisis del problema de contacto termoelásticotridimensional sin fricción mediante el métodode los elementos de contorno, aplicación en microelectrónica”,Ph.D. dissertation, Universidad de Valladolid,2010.[9] L. Gaul and W. Wenzel, ”Acoustic calculations with thehybrid boundary element method in time domain”, Engineeringanalysis with boundary elements, vol. 25, no. 4-5,pp. 259–265, 2001.[10] J. Ángel González Pérez, ”Estudio de problemas de contactoincluyendo rodadura mediante el método de los elementosde contorno”, Ph.D. dissertation, Universidad deSevilla, 2001.[11] R. Gonzalez, J. Vallepuga, y L. Sánchez, ”Desarrollode un entorno en C++ y OpenGL para la resolucio´n deproblemas de contacto entre sólidos 3D”, Congreso deMétodos Numéricos en Ingeniería, 2009.[12] R. González, ”Optimización del método de los elementosde contorno en la resolución de problemas de contactotermoelástico mediante técnicas de paralelismo”, Universidadde León, 2010.[13] H. R. Millwater, ”Probabilistic fracture mechanics analysisusing the boundary element method”, First InternationalSymposium on Uncertainty Modeling and AnalysisProceedings, 1990, pp. 426–431.[14] F. J. Rizzo, ”An integral equation approach to boundaryvalue problems of classical elastostatics”, Quarterly ofApplied Mathematics, vol. 25, pp. 83–95, 1967.[15] M. Stenroos, V. Mäntynen, and J. Nenonen, ”A matlablibrary for solving quasi-static volume conduction problemsusing the boundary element method”, Computermethods and programs in biomedicine, vol. 88, pp. 256–263, 2007.[16] H. Qiao, ”Object-oriented programming for the boundaryelement method in two-dimensional heat transfer analy-JP2011-152

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evaluación de la Paralelización de un ModeloHidrodinámico 3DMario C. Acosta 1,3 , Mancia Anguita 1 , Francisco J. Rueda 2,3 y F. Javier Fernández-Baldomero 1costa, lo que resulta importante para comprender elResumen—Se presenta la implementación paralela de un comportamiento físico y biogeoquímico de modelosmodelo hidrodinámico tridimensional (3D) en un pequeño naturales acuáticos de gran escala.cluster de 3 nodos multi-cores. El programa aprovecha los De igual forma, un coste excesivo de tiempo para3 nodos del cluster usando el estándar MPI y los 4 cores de completar la simulación es inaceptable cuando elcada nodo usando el estándar OpenMP. En este trabajo semodelo SWE forma parte de un sistema de decisión yaanaliza la influencia en las prestaciones de diferentesque en estos casos, los resultados deben obtenerse conconfiguraciones de la plataforma, distintas distribucionesde la carga de trabajo, diferentes métodos de suficiente antelación con el fin de que estos sistemas seimplementación y del uso de procesamiento por bloques. puedan usar para desarrollar y probar estrategias dePalabras clave—Procesamiento paralelo, Sistemas con gestión que puedan minimizar los efectos de desastresmemoria compartida, Sistemas con memoria distribuida, naturales tales como inundaciones o la introducción deHidrodinámica.alguna especie invasiva en la zona.Los modelos usados en sistemas de decisión suelenI. INTRODUCCIÓNejecutarse repetidamente, usando en cada ocasión unA computación de altas prestaciones sigue conjunto de parámetros distinto y/o condiciones deaumentando en la ciencia del agua, se necesitan frontera diferentes con el objetivo de proporcionarLobtener campos de flujo en ecosistemas naturales predicciones futuras del campo de flujo con un grado decon mayor detalle, pero sin que conlleve un coste de confiabilidad satisfactorio.tiempo demasiado elevado.La mayoría de los esfuerzos en la modelización delEstas descripciones detalladas de los campos de flujo, medio ambiente fluido deben tener como objetivoobtenidas bien a partir de simulaciones de algoritmos de mejorar el tiempo de ejecución de los modelostres dimensiones que resuelven las ecuaciones de numéricos existentes, especialmente en plataformas degobierno para el movimiento de flujo o bien a través de bajo coste, para que los estudiosos del agua puedanobservaciones realizadas con técnicas experimentales obtener un detallado y riguroso conocimiento yde alta resolución, han permitido que los científicos comprensión de los procesos físicos de transporte yestudiosos del agua alcancen alguna compresión sobre mezcla que tienen lugar en las aguas de interior y quelos procesos de transporte en aguas de interior [1] [2]: los gestores del agua puedan conseguir prediccioneslagos y deltas. Pero esta comprensión dista aún mucho precisas del flujo ante perturbaciones externas (porde ser completa.ejemplo, la polución) y así obtener estrategias de gestiónMuchos de los modelos hidrodinámicos en un tiempo aceptable.tridimensionales, implementados en un computador para Este trabajo evalúa una implementación paralela de unsimulaciones físicas, se usan en la actualidad en algunos modelo SWE 3D que permite incluso un tiempode los lagos investigados y están basados en la solución aceptable de ejecución en computadores paralelos dede una forma simplificada de las ecuaciones de Navier- bajo coste.Stokes, las ecuaciones de aguas someras (SWE Shallow En la Sección 2 se presenta de forma sintetizada elWater Equations) [3].modelo hidrodinámico paralelizado. A continuación, enLos modelos SWE forman un conjunto simplificado de la Sección 3, se resume el trabajo relacionado realizadoecuaciones con un coste computacional moderado que, hasta la fecha en este campo. En la Sección 4 se realizasin embargo, consumen una gran cantidad de memoria una comparación entre distintos métodos para lay tiempo de cómputo cuando se usan cuadrículas implementación paralela así como distintas formas deespaciales de alta densidad o cuando se usan para realizar la descomposición del dominio de datos. En lasimular el comportamiento de sistemas de agua naturales Sección 5 se indica las características de la plataformadurante un largo periodo de tiempo.utilizada y se resumen los resultados experimentalesEl uso de cuadrículas de alta resolución es necesario, obtenidos. Por último se resumen las conclusiones en lapor ejemplo, para obtener el flujo en determinadas zonas Sección 6.de pequeña escala, como las corrientes cercanas a laII. MODELO HIDRODINÁMICOEl modelo 3D SWE a paralelizado se denomina SI3D1 Dpto. de Arquitectura y Tecnología de Computadores, Univ. [4]. Este modelo, desde su presentación, ha sidoGranada, e-mail: manguita@ugr.es javier@atc.ugr.esampliamente validado, tanto por las soluciones analíticas2 Dpto. de Ingeniería Civil, Univ. Granada, e-mail: frueda@ugr.es como por el conjunto de datos de campo recogidos en3 Instituto Del Água, Univ. Granada, e-mail: marioa@correo.ugr.es una amplia gama de lagos [5].JP2011-153

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011SI3D, está basado en la solución numérica de lasecuaciones de continuidad, Reynolds-average y lasecuaciones de Navier-Stokes para aguas someras demomentum, la ecuación de transporte para latemperatura, y una ecuación de estado que relacionatemperatura con la densidad del fluido. Las ecuacionesfundamentales se integran en un modelo por capasdividido en la horizontal por una serie de capasseparadas por diferentes planos en niveles.Para discretizar estas ecuaciones se usa un algoritmosemi-implícito de tres niveles de diferencias finitascompuesto por pasos iterativos trapezoidal-salto de ranasobre una cuadrícula tradicional de ejes Cartesianos, queintroduce escasa difusión numérica [4]. Este enfoquesemi-implícito está basado en el tratamiento de ondas degravedad y la difusión vertical para evitar limitacionesen el paso de tiempo debido a las condiciones dadas porCouram-Friedrich-Levy y para garantizar la estabilidaddel método [6]. El resto de términos incluyendo laadvección se incluyen explícitamente. Los operadoreslaplacianos se usan para representar mezclas y loscoeficientes constantes de mezcla se usan paraparametrizar el efecto de turbulencias horizontales.Un sistema de dos ecuaciones para turbulenciascalcula los coeficientes de la mezcla en la vertical [7].Los cálculos en cada iteración estudian una a una cadacolumna de agua para generar una matriz pentadiagonalde las ecuaciones del movimiento del agua en lasuperficie libre (η), que resuelve mediante el método delgradiente conjugado precondicionado [4]; de esta formaobtiene los valores de la velocidad horizontal mediantela actualización de los valores de η.III. TRABAJO RELACIONADOSe pueden encontrar en la bibliografía diferentesimplementaciones paralelas de modelos SWE queaprovechan el paralelismo de datos implícito en este tipode aplicaciones. La mayor parte de estasimplementaciones sacan partido de este paralelismo enlas arquitecturas paralelas de memoria distribuida o dememoria compartida usando paradigmas deprogramación de paso de mensajes o de memoriacompartida. Recientemente se han presentadoimplementaciones que aprovechan las arquitecturasSIMD presentes en los procesadores actuales(instrucciones multimedia) y unidades de procesamientode gráficos o GPU.En la bibliografía reciente, hay implementaciones queutilizan el paradigma de paso de mensajes con MPI demodelos en 2D ([8] [9] [10] [1]) y 3D ([11]). Tambiénhay alguna implementación con el paradigma devariables compartidas usando OpenMP; por ejemplo, en[10] se paraleliza el modelo 3D de lattice Boltzmanncon OpenMP. Tanto en las implementaciones devariables compartidas como en las de paso de mensajesse usa descomposición de dominio para dividir la cargade trabajo entre hilos o procesos respectivamente.También, en [12] se presentan la implementación deun modelo SWE 2D que usa las instrucciones SSE delos procesadores de Intel, y en [13] se mejora lasprestaciones de un modelo SWE 2D usando lasinstrucciones multimedia de Intel a través de las libreríasIPP de Intel (Intel Performance Primitives). Hay variasimplementaciones de modelos SWE en GPU, porejemplo en [14] se programa un modelo SWE 2D (doscapas) en una GPU de Nvidia usando CUDA.Los modelos tridimensionales, como SI3D, necesitangrandes cantidades de datos lo que exige la necesidad derecurrir a computación de alto rendimiento. Además, eneste caso la distribución de la carga de trabajo suponeotra dificultad ya que, presenta una distribución irregularen el plano horizontal (primera y segunda dimensión), ala que se añade una tercera dimensión, tambiénirregular, para el plano vertical, dado por la profundidad.En este trabajo se presenta diferentes formas derealizar la implementación paralela de un modelohidrodinámico semi-implícito 3D, en este caso SI3D. Laimplementación realizada combina tanto el paradigmadel paso de mensajes (con MPI) como el paradigma dememoria compartida (con OpenMP). También secomparan variantes en la implementación, en unausando operaciones redundantes (con solapamiento)frente a otra que no las incluye. El solapamientoincrementa el número de operaciones pero por elcontrario reduce el número de comunicaciones. Estetrabajo también analiza la influencia de diferentesconfiguraciones de la plataforma (tales como lastecnologías de Intel HyperThreading, SpeedStep yTurboMode, y la precaptación de datos), así comodiferentes alternativas de descomposición el dominio.Por último, también se han probado distintas opcionesde optimización dadas por el compilador y laimplementación de un procesamiento por bloques.IV. IMPLEMENTACIÓNSe ha trabajado en varias alternativas deimplementación buscando comparar el uso de cálculoredundante frente al uso de más comunicaciones ysincronizaciones (C/S). Los resultados muestran que elcálculo redundante mejora el rendimiento de laimplementación MPI de SI3D y que, sin embargo, parala implementación con OpenMP, el rendimientoaumenta cuando las operaciones redundantes se reducenpara añadir algo de sincronización extra.La figura 1 muestra el diagrama de flujo de la mejorimplementación paralela de SI3D. La etapa 2 no ha sidoparalelizada puesto que supone tan solo un 2% decómputo con respecto a las etapas 1 y 3 juntas en laversión secuencial de SI3D.La sincronización y comunicación (C/S) ocurre tresveces por iteración. La primera se produce cuando elproceso 0 obtiene y resuelve la matriz pentadiagonalpara resolver el movimiento en la superficie libre (η).Una vez resuelta la matriz, el proceso 0 debe volver arepartir estos datos entre el resto de procesos. La terceraocurre al final de cada iteración donde se debenactualizar los valores de u, v y η para el siguiente pasode tiempo intercambiando datos de u, v y η entre losdiferentes procesos. En una implementación sinsolapamiento el número de puntos en los que se debenintercambiar datos se incrementa: habría cuatro en laetapa 1 y cinco en la 3.La implementación paralela de SI3D usadescomposición de dominio para dividir la carga detrabajo entre procesos y hilos, como es usual enaplicaciones de dinámica de fluidos computacional. ElJP2011-154

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Lectura de los datos de entradaDescomposición del dominio paraMPITransmisión de datosSi Step = 1w1f111==2Etapa 1. Obtiene un sistema matricialpara las ecuaciones de momentumx/y, calcula la matriz de coeficientespara la superficie libreTransmisión de la matriz decoeficientesEtapa 2. Resolución del sistema deecuacionesTransmisión de la solución matricialEtapa 3. Resuelve el campo develocidades, transporte escalar y noescalar y asigna los coeficientes dedifusión y viscosidad de turbulencia.Transmisión de datosSi Single = 0Single ==2Si Single = 1==2Actualización dedatos antes de unsalto de ranaStartStepSi Step = 2==2Inicialización del modelo eimpresión de datos para n=0Comienzo de la región paralelaOpenMPEtapa 1. Obtiene un sistema matricialpara las ecuaciones de momentumx/y, calcula la matriz de coeficientespara la superficie libreTransmisión de la matriz decoeficientesEtapa 2. Resolución del sistema deecuacionesTransmisión de la solución matricialEtapa 3. Resuelve el campo develocidades, transporte escalar y noescalar y asigna los coeficientes dedifusión y viscosidad de turbulencia.Transmisión de datosActualización deStep = 2ntrap datos antes de otro==2Si ntrap > totaltrapSi ntrap paso trapezoidal totaliterTermina la región paralela OpenMPEndDescomposición del dominio paraOpenMPniter = niter + 1Figura 1. Diagrama de flujo del algoritmo paralelo.ntrap = ntrap + 1Si niter

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011si se reduce el número de comunicaciones usandosolapamiento entre los subdominios.El número de comunicaciones de tipo send/receive sonmayores si se corta en dos direcciones, como se muestraen la Figura 2(c); aunque el total de datosintercambiados y el número de cálculo redundantepodría ser menor que alguna de las otras dosdistribuciones dependiendo de la geometría particular ydel número de subdominios. Con esta distribución unproceso envía y recibe de más de dos procesos. Losotros dos tipos de distribuciones, el corte estrecho yancho, presentan el mismo número de comunicacionesdel tipo send/receive. En estos dos casos un procesointercambiará datos con uno o dos procesos mientrasque en con la división de la Figura 8(c) un procesopuede intercambiar datos con más de dos procesos.En [15] se comparan las alternativas de la Figura 2(a)y 2(c) usando paso de mensajes (MPI) en un cluster de4 nodos AMD Opteron 2.2 GHz y dos cores cada unoconectados mediante Gigabit Ethernet. Los resultadospara diferentes tipos de simulaciones haciendo uso devarias cuadrículas mostraban un mejor rendimiento si ladescomposición estaba hecha usando el corte en anchoen vez del corte de dos direcciones. [8] compara lasalternativas de la Figura 2(b) y 2(c) usando también pasode mensajes con MPI en un CC-NUMA HP/ConvexExemplar X-Class (SPP2200) con 64 procesadoresdistribuidos en cuatro híper-nodos. Los ochos nodos deun híper-nodo están conectados en red (switch) de 960MB/s de ancho de banda en cada dirección [16]. Siendoesta una red basada en el estándar SCI. Los resultadosmuestran que el corte estrecho da mejores resultados queel de dos direcciones.La alternativa de la 2(c) presenta peor localidad dedatos que las otras dos alternativas. Esto afecta a lasprestaciones, especialmente en la implementación dememoria compartida. Teniendo en cuenta esto y locomentado más arriba, se ha descartado una comparativacon esta alternativa. En el trabajo que aquí se presentase comparan el corte ancho y estrecho tanto en laimplementación de paso de mensajes como la dememoria compartida. Para mejorar la localidad de losdatos, tanto para la distribución del corte en ancho yestrecho, los datos se almacenan en posiciones dememoria contiguas.TABLA IOPCIONES DE OPTIMIZACIÓN ( INTEL COMPILER 11.1 )O2: Expansión en línea, clonación de funciones, optimizaciones clásicas (desenrollado de bucles, copia y propagación deconstantes, renombrado de variables, liberación de memoria inútil) y vectorización (en el que se intentan generar instrucciones de tipoMMX, SSE, SSE2). O2 generalmente se recomienda como opción de optimización para mejorar el tiempo de comunicación.O3: Igual que O2 pero aplicado de una forma más agresiva, con técnicas como precaptación, reemplazamiento para reducirreferencias a memoria, transformaciones de bucles o del acceso a memoria.ipo: Multifile interprocedural optimization (esto, por ejemplo, permite la expansión y clonación de llamadas a funciones definidasen archivos distintos).openmp: Esta opción permite al compilador generar las hilos basándose en las directivas de OpenMP incluidas en el mismocompilador.xSSE4.2 (architecture-specific optimization): Intenta generar instrucciones del tipo MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 ySSE4.2 (vectorización) y puede optimizar la familia de procesadores de Intel Core i7.prof_gen and prof_use (Profile Guided Optimization or PGO): Permite optimizar teniendo en cuenta la referencia real de losdatos en vez de usar datos heurísticos.A. PlataformaV. RESULTADOSLos resultados han sido obtenidos en un pequeñocluster de tres nodos conectados mediante una switchGigabit Ethernet. Cada nodo tiene 6 GB de memoria yun Core i7 CPU920 (del último cuarto del 2008). CadaCore i7 920 se compone de cuatro cores de 2,667 GHz(2 hilos por core si está activado Hyperthreading). cacheL3 de 8 MB compartidos por todos los cores yQuickPath de 4,8 GT/s. El cluster tiene instalado unLinux Fedora 10 (kernel 2.6.27.41)Las comunicaciones del sistema han sido evaluadasmediante un benchmark ping-pong programado conMPI. El ancho de banda de la red obtenido con el testping-pong es de 115 MB/s, cerca de los teóricos 125MB/s.El ejecutable se ha generado con el compilador Fortrande Intel (versión 11) por lo que se ha usado la versiónOpenMP de este compilador. Para paso de mensajes seha usado MPICH 1.3. El código se ha compilado usandodistintas opciones de compilación orientadas a suoptimización y vectorización.En la Tabla I se resume las opciones de optimizaciónusadas. Los tiempos de ejecución obtenidos con O2 yO3 son muy similares, además cuando se añade lasopciones ipo o SSE4.2 a O2 u O3 no se presentancambios perceptibles en el rendimiento. De igual formaPGO no mejora el tiempo de ejecución con respecto auna versión que no usa PGO. Los ejecutables usados enla siguiente sección se han generado con las opciones decompilación O2 y openmp.B. Modelo de PruebaLa aplicación de prueba escogida se trata de unasimulación del lago Tahoe, la meta final de estasimulación es caracterizar las rutas de transporte de laslarvas de especies invasivas (el bivalve Corbiculafluminea, o almeja asiática) desde los puntos cercanos ala costa a otras zonas en el lago, y las condiciones medioambientales a las que podrían estar expuestas durante laruta.Simular un lago del tamaño del lago Tahoe, cuyasdimensiones son de 20x30 km, con un tamaño de lasceldas en la horizontal de O(10) m resulta un problemadesde el punto de vista computacional que sólo puedeser abordado mediante el uso de computadoresparalelos. Para hacerse una idea, la relación entre eltiempo real y el tiempo de ejecución secuencial (unJP2011-156

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Figura 3. Rendimiento de diferentes configuraciones de la plataforma (Segundos por iteración).core) es aproximadamente 1/1. La simulación que sepresenta aquí utiliza una cuadrícula con 95 capas enprofundidad de espesor variable con columnascuadradas de 100mx100m y 50mx50m. A su vez cadacolumna está compuesta por un número de celdillas, entotal 3,663,501 celdillas para las 48,885 columnas delmodelo de baja resolución. Mientras, el modelo demayor resolución tiene 14,654,639 celdillas en 197,781columnas.C. Rendimiento de diferentes configuraciones de laplataforma.En este trabajo se analiza la influencia en elrendimiento de distintas configuraciones de del clusterde tres nodos ACII. El particular se analiza la influenciade la precaptación, el Hyperthreading y la tecnologíaSpeedStep junto con Turbomode de Intel.El precaptador hardware lleva datos a cache conantelación a su uso cuando detecta que un patrón deacceso a memoria se repite. La tecnologíaHyperthreading de Intel permite ejecutar dos hilos porcore. SpeedStep permite al sistema operativo controlar lavelocidad de cada core y TurboMode permite a cadaprocesador funcionar, bajo ciertas condiciones, a mayorfrecuencia que la asignada.La Figura 3 muestra los segundos por iteraciónobtenidos para diferentes configuraciones de laplataforma y diferente número de hilos y/o procesosusados en cada ejecución. Hay que tener en cuenta queno se incluye el tiempo necesario en distribuir los datosal principio de la ejecución y la recolección de datos alfinal ya que no dependen del número de iteraciones y noconsumen un tiempo destacable. En estas pruebas se hautilizado la distribución por corte estrecho y la versiónque añade cálculo redundante.Se asignan 4 hilos a cada nodo, un número mayor dehilos empeora el rendimiento incluso activandoHyperthreading. En la Figura 3, la columna HSTPmuestra los resultados para la configuración que se usapor defecto, en dicha configuración la BIOS y el sistemaoperativo tienen activado Hyperthreading, SpeedStep yTurbomode y el hardware de precaptación. Laconfiguración por defecto del gestor de frecuencia de laCPU (CPUfreq) en el sistema operativo del cluster esondemand; por tanto, el gestor puede variar la frecuenciaentre un mínimo de 1.6 GHz y un máximo de 2.667 GHzdependiendo de la carga, pudiendo la frecuencia máximaincrementarse gracias a la tecnología TurboMode.En cuanto los resultados dados por esta configuraciónen tiempo de ejecución, empeora el rendimiento debidoa la distribución de hilos en los ocho cores lógicos de unmismo nodo. Si Hyperthreading está desactivado mejorael tiempo, pero si además se desactivanSpeedStep/Turbomode o la precaptación el tiempo seincrementa levemente. Comparando la columna -STP y ---P se deduce que hay un incremento de la frecuencia dereloj gracias a TurboMode. La comparación de lascolumnas -STP y -ST- sugiere que el hardware deprecaptación mejora ligeramente las prestaciones. Losresultados presentados a continuación han sidoobtenidos con la configuración -STP y ondemand.Se probó una implementación del procesamiento porbloques en SI3D con el objetivo de reducir los fallos decache y así mejorar la localidad de los datos. En laspruebas realizadas con esta implementación usando elmodelo con celdillas de 100m x 100m y un nodo conhasta 4 hilos se observó una reducción del tiempo deejecución del 4%. Esta técnica solo mejoraba elrendimiento de la implementación marginalmente,aunque no se observó en ningún momento queempeorara el tiempo como en el caso del procesamientopor bloques implementado en [10]. Los resultados en[10] se han obtenido en una plataforma IBM conPower5+ 1.9GHz para un grid de 1024x1024x10 con10.485.760 celdillas, en estos resultados elprocesamiento por bloques mostraba un malcomportamiento en las pruebas realizadas desde 1 a 8procesadores, mientras que mejoraba las prestacionespara 12 y 16 procesadores, siendo este último el númeromáximo de procesadores utilizados [10].Comparaciónentre la distribución de corte ancho y corte estrecho.JP2011-157

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011D. Comparación entre la distribución de corte ancho ycorte estrecho.En ambas distribuciones el número de comunicacionesque presentan son las mismas, sin embargo son detamaño distinto. Además, para la versión MPI concálculo redundante, la distribución para el corte anchoconsta de un mayor número de operaciones redundantesya que el borde del corte ancho es mayor.En la Figura 4 se muestra el tiempo de ejecución poriteración y la ganancia en velocidad para las dosdistribuciones, corte ancho y estrecho. La ganancia en-La implementación a nivel de procesos mejora usandomás solapamiento mientras que presenta mejorestiempos a nivel de hilos cuando dichas áreas desolapamiento se reducen para añadir algo desincronización extra.-Con la implementación paralela, una simulación de 24horas que usan celdillas cuadradas de 50m x 50mrequiere aproximadamente 6 horas si se usa unprocesador (4 hilos) y aproximadamente 2 horas y 30minutos con 3 procesadores (12 hilos). Estos tiemposcontrastan con el tiempo que tarda la simulación con unhilo: de 20 horas y 30 minutos.AGRADECIMIENTOSAl proyecto "Evaluación del riesgo de la expansión dealmeja asiática y el impacto medioambiental en el LagoTahoe. Proyecto: Modelización del transporte de larvas"Financiado por la Estación de Investigación delSuroeste del Pacífico, USDA Forest Service.Figura 4. Comparación de distribuciones en ancho y en estrecho.velocidad mejora en algunos casos en mayor medida conel corte estrecho porque esta distribución tiene un bordede menor tamaño que el dado por el corte ancho, siendoeste borde o zona de solapamiento de un tamaño 25%menor en la distribución con corte estrecho con respectoal corte ancho.VI. CONCLUSIONESEste trabajo presenta y evalúa las prestaciones de unaimplementación paralela con hilos y procesos de unmodelo hidrodinámico semi-implícito tridimensional.De los resultados obtenidos se pueden extraer lassiguientes conclusiones:-La implementación hace un uso positivo de laprecaptación hardware (la precaptación reduce el tiempode ejecución entre un 3% y un 8%) y se obtiene ciertamejora usando el procesamiento por bloques (unamejora de un 4% aproximadamente).-Intel TurboMode reduce en cierta medida el tiempo deejecución (entre un 2% y un 7% aproximadamente).-las prestaciones se reducen considerablemente si laconfiguración por defecto de la BIOS y del sistemaoperativo de la plataforma está activada (el tiempo deejecución se incrementa entre un 40% y un 60%dependiendo del número de procesos o hilos usados).Esto se debe a la asignación de hilos que el sistemaoperativo realiza por defecto entre los ocho coreslógicos de un nodo en el caso de que Hyperthreadingesté activado. Aunque para este caso realizar laasignación de hilos de forma explícita puede solucionarel problema en vez de desactivar el Hyperthreading.-El procesamiento por bloques añadido reduce eltiempo de ejecución levemente.REFERENCIAS[1] B. R. Hodges, J. Imberger, A. Saggio and K. B. Winters,"Modeling Basin-Scale Internal Waves in a Stratified Lake,"Limnology and Oceanography, vol. 45, pp. 1603-1620, Nov., 2000.[2] F. J. Rueda, S. G. Schladow and S. Ó. Pálmarsson, "Basin-scaleinternal wave dynamics during a winter cooling period in a large lake,"J. Geophys. Res., vol. 108, pp. 3097, 03/27. 2003.[3] Haro Ortega, Glòria, "Numerical simulation of shallow waterequations and some physical models in image processing," Open FileReport, B.40014-2005 Universitat Pompeu Fabra., Chapter 2. 2005.[4] P. E. Smith, A Semi-Implicit, Three-Dimensional Model ofEstuarine Circulation. ,Open-File Report 2006-1004. USGS.ed.Sacramento, California: 2006,[5] F. J. Rueda and E. A. Cowen, "The residence time of afreshwater embayment connected to a large lake," Limnol. Oceanogr.,vol. 50, pp. 1638-1653, 2005.[6] V. Casulli and R. T. Cheng, "Semi-implicit finite differencemethods for three-dimensional shallow water flow," Int. J. Numer.Methods Fluids, vol. 15, pp. 629-648, 1992.[7] L. H. Kantha and C. A. Clayson, "An improved mixed layermodel for geophysical applications," J. Geophys. Res., vol. 99, pp.25235-25266, 1994.[8] W. von Bloh, S. Rost, D. Gerten and W. Lucht, "Efficientparallelization of a dynamic global vegetation model with riverrouting," Environmental Modelling & Software, vol. 25, pp. 685-690,6, 2010.[9] P. Rao, "A parallel hydrodynamic model for shallow waterequations," Applied Mathematics and Computation, vol. 150, 2004.[10] M. J. Castro, J. A. García-Rodríguez, J. M. González-Vida andC. Parés, "A parallel 2d finite volume scheme for solving systems ofbalance laws with nonconservative products: Application to shallowflows," Comput. Methods Appl. Mech. Eng., vol. 195, 2006.[11] K. R. Tubbs and F. T. -. Tsai, "Multilayer shallow water flowusing lattice Boltzmann method with high performance computing,"Adv. Water Resour., vol. 32, pp. 1767-1776, 12. 2009.[12] O. Nesterov, "A simple parallelization technique with MPI forocean circulation models," Journal of Parallel and DistributedComputing, vol. 70, pp. 35-44, 1. 2010.[13] D. van Dyk, M. Geveler, S. Mallach, D. Ribbrock, D. Göddekeand C. Gutwenger, "HONEI: A collection of libraries for numericalcomputations targeting multiple processor architectures," Comput.Phys. Commun., vol. 180, pp. 2534-2543, 12. 2009.[14] M. J. Castro, J. A. García-Rodríguez, J. M. González-Vida andC. Parés, "Solving shallow-water systems in 2D domains using FiniteVolume methods and multimedia SSE instructions," J. Comput. Appl.Math., vol. 221, pp. 16-32, 2008.[15] l. A. de, J. Mantas and M. Castro, "Simulation of one-layershallow water systems on multicore and CUDA architectures," TheJournal of Supercomputing, online 10 March 2010. 2010.[16] O. Nesterov, "A simple parallelization technique with MPI forocean circulation models," Journal of Parallel and DistributedComputing, vol. 70, pp. 35-44, 1. 2010.JP2011-158

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Paralelización del Análisis de Imágenes conTensor de Difusión en Resonancia Magnéticausando GPUsMoisés Hernández 1 , Ginés D. Guerrero 1 , José M. Cecilia 1 , José M. García 1 y AlbertoInuggi 2 ,Resumen— Entender la función del cerebro atendiendoa las conexiones existentes entre sus diferentesáreas es uno de los mayores retos de la neuroimagen.Las Imágenes con Tensor de Difusión (ITD) en resonanciamagnética proporcionan información del cerebroque no está presente en ninguna otra modalidadde imágenes. Mucha de esta valiosa informaciónpuede ser extraída solamente con la ayuda de un postprocesamientode los datos adquiridos al paciente. Sinembargo, la necesidad computacional de los algoritmosutilizados hace muy tediosa su práctica, llegandoa tardar el post-procesado en algunos casos más de 24horas para un sólo paciente. En este artículo discutimosla paralelización en la GPU de una herramientade ITD propuesta en el programa FSL del centro FM-RIB de la Universidad de Oxford. Nuestros resultadosdemuestran que se pueden alcanzar grandes aceleracionesen este tipo de aplicaciones (hasta 85x) en comparacióncon las tradicionales CPUs, pudiendo estarambas plataformas en un ordenador de sobremesa ya un coste similar.Palabras clave— GPUs, Bioinformática, ResonanciaMagnética, Imágenes con Tensor de DifusiónI. IntroducciónLAS imágenes con tensor de difusión (ITD) constituyenun método relativamente nuevo en lasimágenes por resonancia magnética (IRM), en el cualse proponen técnicas no invasivas que permiten investigarlas propiedades locales de las fibras de lamateria blanca [1]. Las ITDs son sensibles a la difusiónde las moléculas de agua, las cuales puedenvariar a lo largo de los diferentes tejidos cerebrales,principalmente cuando se encuentran próximasa las zonas de materia blanca, donde el agua se difundecon mayor facilidad a lo largo de sus principalesconexiones. Mediante la aplicación de fuertespulsos magnéticos es posible crear un mapa con lasprincipales direcciones de difusión en cada parte delcerebro, y con el uso del software adecuado conseguirel tracto entre sus diferentes áreas, es decir, la representaciónde una red de interconexión tridimensionaldel cerebro, llamada tractografía. Este procedimientoha sido usado para investigar cambios durante eldesarrollo humano y el envejecimiento, en estudiosde enfermedades neurodegenerativas y de pacientesque tienen ictus u otras otras patologías cerebrales.Bedpost es una aplicación perteneciente al softwareFSL (desarrollada en el Centro de Investigación1 Grupo de Arquitectura y Computación Paralela, Dpto.de Ingeniería y Tecnología de Computadores, Univ.de Murcia, e-mail: {moises, gines.guerrero, chema,jmgarcia}@ditec.um.es.2 Laboratorio de Neurociencia Cognitiva, Dpto. de Psicología,Univ. de Murcia, e-mail: inuggi@um.es.FMRIB de la Universidad de Oxford), que es capazde realizar tractografías. Además, este software tieneun enfoque multi-fibra que puede incrementar deforma significativa su sensibilidad, teniendo la capacidadde reconstruir los tractos dominantes [2]. Suprincipal desventaja es el tiempo de ejecución, dondedependiendo de los parámetros de la secuencia deresonancia magnética, el análisis de un sujeto puedellevar más de 24 horas.Debido a que los estudios pueden llegar a realizarsesobre un gran número de personas, proponemos laparalelización de esta aplicación en una arquitecturamasivamente paralela, como es la de las unidadesgráficas de procesamiento (GPUs). Las GPUs actualesson procesadores masivamente paralelos que soncapaces de soportar varios miles de hilos ejecutándoseen paralelo. Muchas aplicaciones de propósito generalhan sido diseñadas para estas plataformas debidoa su alto rendimiento. El lenguaje que se usapara programar estos dispositivos es C con extensionesCUDA. Las nuevas generaciones de GPU tienenhasta 512 procesadores escalares por chip, pudiendoalcanzar un rendimiento pico teórico de hasta 1TeraFLOP.Hemos paralelizado la aplicación Bedpost en CU-DA, para así aprovechar la gran capacidad de computoque poseen las GPUs. Se han llevado a cabo unconjunto de pruebas variando sus distintos parámetrosde entrada, llegando a obtener una mejora entorno a de 85X respecto al código secuencial.El resto del documento está estructurado como sigue.En la sección II introducimos los conceptos necesariospara entender mejor el resto del contenido:por un lado se describe el modelo de tensor de difusión(apartado II-A); y luego pasamos a comentarbrevemente algunos aspectos de la arquitectura de laGPU y del modelo de programación CUDA (apartadoII-B). En la sección III describimos el algoritmoque es utilizado por Bedpost de forma secuencial.Posteriormente, se detalla la versión paralela implementadaen CUDA en la sección IV. Ambas implementacionesson analizadas mediante un conjunto depruebas en la sección V. Finalmente la sección VImuestra las conclusiones y el trabajo futuro.II. PreliminaresA. Imágenes con Tensor de Difusión (ITD)Las moléculas de agua están en un constante movimientoaleatorio conocido como movimiento brow-JP2011-159

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011niano, que trasladado a un nivel macroscópico produceel proceso de difusión [3].El tejido cerebral humano se puede dividir en tresclases principales: materia blanca, materia gris y fluidocerebroespinal. En la materia gris y el fluido cerebroespinal,la difusión es aleatoria porque las moléculasde agua se mueven en todas las direcciones. Estefenómeno se denomina difusión isotrópica.Sin embargo, en la materia blanca el movimientode las moléculas no conserva esa componente totalmentealeatoria. La materia blanca está formadaprincipalmente por axones, que estan principalmenterecubiertos de mielina. Esta sustancia es una barrerapara el movimiento de la moléculas de agua, y portanto condiciona el movimiento de las mismas. Eneste caso hablamos de difusión anisotrópica [4].El modelo tensor de difusión nos permite modelarla dirección de las fibras nerviosas en cada una de laspartes del cerebro. Gracias a la difusión anisotrópicaes posible observar las direcciones preferenciales dedifusión de las moléculas de agua en la materia blancacerebral, correspondiendo estas direcciones con lasdirecciones que siguen las fibras nerviosas cerebrales,y por tanto permite modelar el tracto cerebral.Los datos de imagen de resonancia magnética cerebralde un sujeto estan compuestos por varias imágenes2D, cada una de las cuales se corresponde con uncorte transversal del cerebro (o slice). Un slice, a suvez, está compuesto por pixels, que representan launidad mínima de la imagen 2D. Asimismo, un voxeles la unidad cúbica mínima que compone el objetotridimensional.El objetivo de las Imágenes con Tensor de Difusión(ITD) es modelar las direcciones del tracto de variasfibras nerviosas cerebrales en cada uno de los voxels.Esto se consigue aplicando dos pulsos de gradientesde campo magnético sobre el tejido cerebral mientrasse produce el proceso de difusión, lo que genera unaseñal de campo magnético asociada a la difusión quese produce durante los dos pulsos. A partir de laseñal obtenida se genera una imagen digital (Imagende Resonancia Magnética). Si se aplican diferentesdirecciones en los gradientes obtendremos una señalcompuesta, a partir de la cual, gracias a métodosde análisis numéricos podremos reconstruir el tensorque describe el proceso de difusión y por consiguientela dirección principal de las fibras en cada voxel [5].El cálculo de estas direcciones está asociado a ciertaincertidumbre, ya que la información se recoge apartir de varias direcciones en los gradientes aplicados,y además se produce un cierto ruido durante laadquisición de la imagen por resonancia magnética.Por tanto, el objetivo se reduce a obtener aquella direccióncon máxima probabilidad de cada una de lasfibras nerviosas que se desea modelar [6].La ecuación 1 muestra el modelado de la señal parala medida de difusión de cada uno de los voxels,después de aplicar los 2 gradientes de difusión con ndirecciones [2, 6–8].S(g) =S 0[(1 −N∑f i ) exp(−bd)+i=1N∑] (1)f i exp(−bd(gv i ) 2 )i=1Donde S 0 es la señal sin difusión, f ∈ [0, 1] es lafracción de volumen de difusión anisotrópica en el voxel;b indica la magnitud y duración de los gradientes,además del tiempo entre el par de gradientes aplicadospara obtener los datos (medido en s/mm 2 ); des la difusividad; g indica la dirección de cada gradienteaplicado; finalmente v describe las orientacionesde una fibra ante los gradientes aplicados. Estasorientaciones viene definidas a partir de operacionestrigonométricas (senos y cosenos).Los parámetros de cada una de las fibras modeladas,los cuales describen su orientación, deben serestimados. Cuando adquirimos los datos de un sujetoconocemos la señal S con la medida de difusión quese ha obtenido, la cual depende de los parámetrosque queremos estimar. El modelo de la señal descritoen la ecuación 1 define la máxima probabilidadde que se produzca la señal obtenida (ya que se haproducido y la conocemos) dados los parámetros quedesconocemos P (señal | parámetros). El teorema deBayes nos permite calcular la probabilidad a posterioriP (parámetros | señal), es decir, dada una señalsaber cual es la probabilidad de que este formadapor unos parámetros concretos. De esta manera sepueden proponer muestras de los parámetros a partirde la distribución a posteriori conjunta utilizandoel algoritmo de Monte Carlo de cadenas de Markov(MCMC). Para ello generamos números aleatorios querepresentan los parámetros a estimar y escogemosquellos que maximicen la probabilidad de alcanzarla señal que se ha obtenido en el tiempo de adquisición[8].Para realizar una buena estimación de los parámetrosen el algoritmo MCMC, se realiza una primeraaproximación donde se utiliza el algoritmo deLevenberg-Marquardt [9, 10].B. La unidad de procesamiento gráfico (GPU))La nuevas unidades de procesamiento gráfico(GPU, Graphics Processing Unit) presentan una arquitecturamasivamente paralela, capaz de manejarmiles de hilos concurrentemente de manera altamenteeficiente tanto para aplicaciones gráficas, como paraaplicaciones de propósito general.En concreto, la línea Tesla de Nvidia para el mercadode altas prestaciones, y en concreto la TeslaC2050, presenta un total de 448 procesadores (oStreaming-Processors, SPs) organizados en 14 multiprocesadores(o Streaming Multiprocessor, SMs) y3GB de memoria principal GDDR5 (llamada deviceo global memory). La GPU se comunica con la CPUa través del bus PCI Express x16 (proporcionandoun ancho de banda de 4 GB/s en cada dirección).JP2011-160

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2. Un hilo secuencial ejecutando n ∗ m voxels de un slice.Fig. 1. Esquema de la arquitectura Fermi de NVIDIA.El lenguaje de programación utilizado para lasGPUs de Nvidia se denomina CUDA (Compute UnifiedDevice Architecture) [11]. El lenguaje CUDA esmuy similar al lenguaje estándar C con la inclusiónde algunas extensiones. En un programa escrito enCUDA podemos diferenciar dos partes principales.La parte host que se ejecuta secuencialmente en laCPU, y la parte device que es ejecutada en la GPU enforma de funciones denominadas Kernels. Un kernelsigue el modelo de ejecución SPMD (Single-ProgramMultiple-Data), donde un gran número de hilos seejecutan en paralelo. El programador organiza estoshilos en bloques de hilos (ver figura 1). Estos hilospueden compartir datos y sincronizarse entre sí, sinembargo, no existen primitivas de sincronización entrehilos de distintos bloques, y la única manera decompartir datos es a través de la memoria principalde la GPU. Además los bloques de hilos se agrupanen Grids. Todos los hilos que forman un Grid ejecutanel mismo kernel.III. Descripción de la aplicación BedpostEn esta sección describimos la aplicación secuencialBedpost perteneciente al software FSL [12],desarrollada en el Centro de Investigación FMRIBde la Universidad de Oxford. El algoritmo 1 muestrael pseudocódigo de la aplicación Bedpost. Todoslos slices asociados con la imagen de un sujeto sonrecorridos secuencialmente procesando cada uno desus voxels (véase figura 2). Este procesado consisteen dos partes bien diferenciadas:1. Aproximación inicial del valor de los parámetrosmediante el algoritmo LevenbergMarquardt.2. El algoritmo de Monte Carlo con cadenas deMarkov (MCMC) para estimar el valor de losparámetros (también descrito en el pseudocódigodel algoritmo 1).En la primera etapa se aproximan los parámetrosa un valor inicial para facilitar que algoritmo MCMCpueda hacer una buena estimación. El mecanismo sebasa en un procedimiento iterativo de optimización.La segunda etapa toma como entrada los valorescalculados en la etapa anterior, aproximando conmás certeza la orientación final de la fibra en cadavoxel. Para ello, se utiliza el algoritmo MCMCdonde se proponen muestras para cada uno de losparámetros, generando para ello números aleatorios(los cuales son ajustados a una distribución normalestándar), aceptando o rechazando la muestra segúnun criterio que viene dado por el valor que toma laecuación 1, la cual se recalcula cada vez que se proponeun nuevo parámetro.El número de parámetros a estimar depende de lacantidad de fibras (f) que deseamos modelar en cadavoxel. Este número viene dado por la ecuación 2+3f.Por defecto f = 2, y f no suele ser mayor de 4, esdecir, tenemos entre 8 y 14 parámetros.Los datos de entrada del algoritmo Bedpost , esdecir, el número de slices, voxels, y gradientes dedifusión viene dado en el tiempo de adquisición delas imágenes de resonancia, según el factor calidad/tiempoque se desee en los datos obtenidos.IV. Diseño de la aplicación Bedpost enCUDAUna primera alternativa de diseño paralelo deBedpost viene motivada por la naturaleza paralelade todos los slices. Esta es la filosofía que siguen losdesarrollares de FSL [13], pudiendo hacer uso de variosprocesadores diferentes mediante el uso de Sun-GridEngine (SGE) [14], procesando cada uno de ellosun slice de manera independiente. Este diseño, sinembargo, implica una gran carga de trabajo a cadaprocesador o hilo de ejecución, y por tanto no seadapta bien al modelo de ejecución CUDA, ya que requierede una paralelización de la aplicación con unagranularidad mucho más fina, para así poder sacarpartido de los miles de hilos que es capaz de ejecutaren paralelo.Un enfoque alternativo de diseño es descender alnivel de voxels. Un slice puede contener miles devoxels, y además se pueden computar de forma independiente,por lo que podríamos tener un hiloJP2011-161

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo 1 Pseudocódigo de la aplicación BedpostBedpost1: para todo slice hacer2: para todo voxel hacer3: LevenbergMarquardt()4: MCMC()5: fin para6: fin paraMCMC1: para i = 0 hasta numIteraciones hacer2: para todo parametro hacer3: sample p = generar random()4: sample p n = normalizar(sample p)5: recalcular senal(direcciones)6: aceptarRechazar(sample p n)7: fin para8: fin paracomputando cada uno de los voxels de un slice deforma paralela tal y como muestra la figura 3. Fig. 3. voxels de un slice, agrupados en x bloques de tamañoy.El diseño del algoritmo de Levenberg-Marquardestá implementado en un único kernels basado enesta idea. Cada hilo de CUDA sea mapeado con unvoxel, encargándose este de adecuar sus valores iniciales.Por lo que tendremos tantos hilos como voxelstenga un slice concreto.Algoritmo 2 Pseudocódigo de la aplicaciónBedpost paralelizada en CUDA.1: para todo slice hacer2: bloqs := voxels/tamBloque13: levenbergKernel(bloqs, tamBloque1)4: genNumsKernel(bloqs, tamBloque1)5: ajuteNumsKernel(bloqs, tamBloque1)6: bloqs := (voxels ∗ direcs)/tamBloque27: mcmcKernel(bloqs, tamBloque2)8: fin paraEl caso del algoritmo MCMC es un poco mas complejo.En este caso, el computo se ha divido en treskernels (véase el algoritmo 2).El primer kernel es encargado de la generación eficientede números aleatorios. En cada iteración delalgoritmo se deben generar varios números aleatorios(dos por cada parámetro) lo que provoca que en slicescon varios miles de voxels se generen cientos demillones de números aleatorios. Estos números songenerados mediante el uso de la librería CURAND [15]de CUDA.Posteriormente, la mitad de los números pseudoaleatoriosque han sido generados antes deben serajustados a una distribución normal estándar. Estose realiza mediante otro kernel para así poder ejecutarun hilo por cada voxel.Finalmente se ejecuta el kernel MCMC. En este caso,el diseño difiere con los planteados anteriormente.Ahora tenemos tantos hilos como direcciones se quierananalizar para cada voxel, repartimos los voxelesentre los bloques (véase la figura 4). De este modoampliamos el número de hilos por bloque hasta alcanzarvalores entre 128 − 256 hilos. La existencia deslices con un número pequeño de voxels hacen queen ciertos casos no se pueda explotar el paralelismode la GPU. Además, este diseño nos beneficia a lahora de recalcular el valor de la ecuación 1, ya quese podrá realizar en paralelo para cada una de lasdirecciones. Fig. 4. m∗n∗direc hilos ejecutados en paralelo para el cálculode m∗n voxels de un slice en direc direcciones, agrupadosen x bloques de tamaño y, donde y es múltiplo de direc.V. Evaluación de los ResultadosEn esta sección se muestran los resultados obtenidosen la ejecución de la aplicación Bedpost delsoftware FSL comparando el tiempo de ejecución entreCPU y GPU.En nuestras pruebas se ha utilizado la versión 4.0de CUDA sobre una GPU Tesla C2050. Esta GPUse encuentra incorporada en un ordenador con dosprocesadores Intel Xeon E5620 a 2.40GHz y con 4GBde memoria principal. Las pruebas en CPU se hanrealizado utilizando un único hilo mapeado a uno delos cores del sistema.Hemos dividido las pruebas en 4 partes, mostrandouna gráfica en escala logarítmica y un análisis delos resultados para cada una de ellas. Estas partesJP2011-162

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011se corresponden con los distintos kernels que se handesarrollado en CUDA:1. Ajuste de los parámetros iniciales conLevenberg-Marquardt.2. Generación de números pseudo-aleatorios.3. Ajuste de los números pseudo-aleatorios obtenidosa una distribución normal estándar.4. Algoritmo MCMC.En la figura 5 se observa el rendimiento de la ejecucióndel algoritmo Levenberg-Marquardt en CPUy GPU, cuya función es ajustar los parámetros inicialesantes de llamar al procedimiento MCMC. Se hanrealizado pruebas para ajustar 8 y 14 parámetros (2y 4 fibras respectivamente) en slices con tamañosdiferentes en cuanto al número de voxels que contienen.Se observa que a mayor número de voxels enun slice (lo que conlleva un mayor número de hilosejecutándose en paralelo en GPU) obtenemos unamejora mayor en la GPU respecto a la CPU, llegandoa ser esta de 20X en el caso de 8 parámetros, yde 56X en el caso de 14 parámetros. Fig. 5. Relación de tiempos en CPU y GPU, en escala logarítmica,al ejecutar Levenberg-Marquardt con 8 y 14parámetros.La comparativa entre el tiempo empleado por laversión paralela y secuencial en cuanto a la generaciónde números pseudo-aleatorios es mostrada en lafigura 6. Como se ha comentado anteriormente, enCPU se ha utilizado la función rand() pertenecientea la librería CSTDLIB de C++, mientras que en GPUse ha utilizado la librería CURAND de CUDA. Como seaprecia en dicha figura, a partir de la generación demás de 5 millones de números aleatorios, resulta máseficiente su generación en GPU, llegando a obteneruna ganancia de 140X con 380 millones de númerosaleatorios.La figura 7 muestra la comparativa de rendimientoCPU y GPU del kernel encargado de realizar el ajustea una distribución normal de los números pseudoaleatoriosobtenidos anteriormente. En este caso, apartir de la generación de 500.000 números empezamosa obtener mejoras en el tiempo de procesamientoen GPU con respecto al código secuencial, llegandoa conseguir una mejora de 14X con 350 millones denúmeros.Por último, en la figura 8 se muestra la comparativa,entre ambas versiones para el tiempo que setarda en ejecutar el algoritmo MCMC y el tiempo total Fig. 6. Comparativa entre el uso de rand() en CPU y la libreríaCURAND en GPU, en escala logarítmica, para generar unconjunto de números aleatorios. Fig. 7. Relación de tiempos en CPU y GPU, en escala logarítmica,al ajustar un conjunto de números a una distribuciónnormal estándar.que requiere la aplicación Bedpost para su ejecucióncompleta (es decir, teniendo en cuenta las 4 fases).En dicha figura se refleja el tiempo en segundos respectoal número de iteraciones que se realizan en elalgoritmo MCMC. Además, se han realizado pruebaspara modelar 2 y 4 fibras (figuras 8a y 8b respectivamente).Las dimensiones de las imágenes que toma elalgoritmo como entrada son de 128∗128∗47∗35, dondelas dimensiones hacen referencia a ancho ∗ alto ∗número de slices ∗ número de direcciones. Se puedeobservar que la mejora del tiempo del algoritmo MCMCy del tiempo total que se obtienen son proporcionales,en este caso, con los datos de entrada antes mencionados.La máxima mejora que se ha conseguidoes de 127X en GPU respecto a CPU al ejecutar elalgoritmo MCMC, mientras que la máxima mejora enel tiempo total de la aplicación Bedpost es de 85X.Además, se han realizado pruebas con otras imágenesde entrada de diferentes tamaños. En la tabla Ise puede observar un resumen de la mejora obtenidapor el algoritmo paralelizado en CUDA frente asu versión secuencial para cada una de las imágenesusadas en nuestras pruebas.VI. Conclusiones y Trabajo FuturoEn este artículo hemos discutido la paralelizacióndel análisis de imágenes con tensor de difusión en resonanciasmagnéticas en la GPU. Para ello, hemosutilizado la aplicación Bedpost incluida en el softwareFSL, desarrollado en el centro de investigaciónFMRIB de la Universidad de Oxford.JP2011-163

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011 (a) 2 Fibras (b) 4 FibrasFig. 8. Comparativa de tiempo total de ejecución de Bedpost y MCMC entre CPU y GPU, en escala logarítmica, con unaimagen de dimensiones 128x128x47 y 35 direcciones diferentes en los gradientes, modelando 2 y 4 fibras, y alternando elnúmero de iteraciones para el algortimo MCMC.TABLA IMáxima mejora obtenida al ejecutar Bedpost en GPUpara diferentes tamaños de imagen respecto a suversión secuencial.DIM. IMAGEN NFIBRAS NITERS MEJORA128x128x47x352 9000 69X4 1125 85X256x256x47x352 4500 60X4 2250 65X128x104x60x622 9000 84X4 2250 83XNuestro análisis experimental en la GPU muestraunos resultados prometedores, llegando a obtenerunas aceleraciones en torno a 85x en comparacióncon el código secuencial.Tras comprobar que la GPU es una arquitecturaadecuada para la paralelización del aplicaciónBedpost, las futuras líneas de investigación irán dirigidasa la paralelización de otros aplicaciones incluidasen el software FSL.AgradecimientosEl presente trabajo ha sido financiado mediantela Fundación Séneca (Agencia Regional de Cienciay Tecnología, Región de Murcia) con la ayuda00001/CS/2007, y también al MEC y la ComisiónEuropea FEDER con las ayudas CSD2006-00046 yTIN2009-14475-C04.Referencias[1] Denis Le Bihan, “Looking into the functional architectureof the brain with diffusion mri,” Nature ReviewsNeuroscience, vol. 4, pp. 469–480, 2003.[2] T.E.J. Behrens, H.Johansen Berg, S.Jbabdi, M.F.S.Rushworth, and M.W. Woolrich, “Probabilistic diffusiontractography with multiple fibre orientations: What canwe gain?,” NeuroImage, vol. 34, no. 1, pp. 144–155, 2007.[3] David Solomon Tuch, Diffusion MRI of complex tissuestructure, Ph.D. thesis, Massachusetts Institute of Technology,2002.[4] MSc. Diwei Zhou, Statistical analysis of diffusion tensorimaging, Ph.D. thesis, University of Nottingham, 2010.[5] J. E. Castro and J. T. Hernández, “Algoritmos aplicadosen el cálculo, análisis y aplicación del tensor de difusión enimágenes médicas de da materia blanca cerebral,” RevistaColombiana de Física, vol. 42, no. 3, 2010.[6] T.E.J. Behrens, H.Johansen-Berg, M.W. Woolrich, S.M.Smith, C.A.M. Wheeler-Kingshott, P.A. Boulby, G.J.Barker, E.L. Sillery, K.Sheehan, O.Ciccarelli, A.J. Thompson,J.M. Brady, and P.M. Matthews, “Non-invasivemapping of connections between human thalamus andcortex using diffusion imaging,” Nature Neuroscience,vol. 6, no. 7, pp. 750–757, 2003.[7] Stamatios N. Sotiropoulos, Processing of Diffusion MRImages of the Brain: From Crossing Fibres to DistributedTractography,Ph.D. thesis, University of Nottingham,2010.[8] Behrens TE, Woolrich MW, Jenkinson M, Johansen-BergH, Nunes RG, Clare S, Matthews PM, Brady JM, andSmith SM., “Characterization and propagation of uncertaintyin diffusion-weighted mr imaging,” MagneticResonance in Medicine, vol. 50, no. 5, pp. 1077–1088,2003.[9] Jesper L.R. Andersson, Mark Jenkinson, and StephenSmith, “Non-linear optimisation,” Tech. Rep. TR07JA1,FMRIB Centre, Oxford, United Kingdom, June 2007.[10] Jesper L.R. Andersson, Mark Jenkinson, and StephenSmith, “Non-linear registration aka spatial normalisation,”Tech. Rep. TR07JA2, FMRIB Centre, Oxford,United Kingdom, June 2007.[11] NVIDIA, NVIDIA CUDA C Programming Guide 4.0,2011.[12] Stephen M. Smith, Mark Jenkinson, Mark W. Woolrich,Christian F. Beckmann, Timothy E.J. Behrens, HeidiJohansen-Berg, Peter R. Bannister, Marilena De Luca,Ivana Drobnjak, David E. Flitney, Rami K. Niazy, JamesSaunders, John Vickers, Yongyue Zhang, Nicola DeStefano, J. Michael Brady, and Paul M. Matthews, “Advancesin functional and structural mr image analysis andimplementation as fsl,” Tech. Rep. TR04SS2, FMRIBCentre, Oxford, United Kingdom, September 2004.[13] Analysis Group FMRIB Oxford UK, “Fmrib softwarelibrary,” http://www.fmrib.ox.ac.uk/fsl/.[14] Inc. Sun Microsystems, “Sun n1 grid engine 6.1 user’sguide,” 2007.[15] NVIDIA Corporation, “Cudacurand library,” 2010.[16] Jorge Ahualli, “Aspectos generales de las secuencias dedifusión de imagen en resonancia magnética,” Revistaargentina de radiología, vol. 74, no. 3, pp. 227–237, 2010.[17] Denis Le Bihan, Jean-François Mangin, Cyril Poupon,Chris A. Clark, Sabina Pappata, Nicolas Molko, and HughesChabriat, “Diffusion tensor imaging: Concepts andapplications,” Journal of Magnetic Resonance Imaging,vol. 13, no. 4, pp. 534–546, 2001.JP2011-164

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Agent-Based Simulation to OptimizeHealthcare Emergency DepartmentsEduardo Cabrera 1 , Manel Taboada 2 y Emilio Luque 3Abstract— Modeling and simulation have beenshown to be useful tools in many areas of the Healthcareoperational management, field in which there isprobably no area more dynamic and complex thanhospital emergency departments (ED). This paperpresents an ongoing research, an Agent-Based modelingand simulation to design a decision support system(DSS) for the operation of Healthcare EmergencyDepartments (ED). This DSS aims to aid EDs managersin setting up strategies and management guidelinesto optimize the operation of EDs. This ongoingresearch is being performed by the Research Groupon Individual Oriented Modeling (IoM) of CAOS inthe University Autonoma of Barcelona (UAB) in closecollaboration with Hospital ED Staff. The simulationmain objective is to optimize the performance of suchcomplex and dynamic Healthcare ED. Optimization isperformed to find the optimal ED staff configuration,which consists of doctors, triage nurses, and admissionpersonnel, i.e. a multidimensional problem. Twodifferent indexes, to minimize patient waiting time,and to maximize patient throughput, were proposedand tested and their results obtained appying an exhaustivesearch technique, yield promising results andbetter understanding of the problem.Keywords— Optimization, healthcare operationalmanagement, emergency department, agent-basedsimulation, decision support systems.I. IntroductionNO wadays, healthcare systems have becomelarge, complex, and quite dynamic environments,particularly Emergency Department (ED).ED is a sui generis unit of hospitals. It is open andfunctioning 24 hours a day, 365 days per year. Typically,ED patients could arrive by walking, or by ambulance,and they undergo a triage, which determinethe acuity of their condition assigning them a prioritylevel. Patients with threatening disease, i.e. highpriority level, are treated almost immediatly by aphysician compared to those patients with less severeinjuries. Then, an initial diagnosis and treatment isproposed, and patients could be admitted into theservice or discharged. EDs have high demand of service,which increases their cost, and they generallyoperate with limited healthcare resources and budget.In the decade leading up to 2006 in the USA,ED visits (patients) have increased by 32%, whereasthe number of EDs have decreased by 4.6%, and thenumber of visits per person increased by 18% [1].Also, in Spain between 2001 and 2007, the visits to1 Dpto. de Arquitectura de Computadores y SistemasOpe-rativos, Universitat Autònoma de Barcelona, e-mail:ecabrera@caos.uab.es2 Tomàs Cerdà Escuela de Ciencia Computacional, UniversitatAutònoma de Barcelona, e-mail: manel.taboada@eug.es3 Dpto. de Arquitectura de Computadores y SistemasOpe-rativos, Universitat Autònoma de Barcelona, e-mail:Emilio.luque@uab.esEDs have increased by 23.2% [2]. Over half of thosevisits to EDs are nonurgent and could be treatedin alternative healthcare settings. Overcrowding ofEDs is a worldwide problem, and as a consequenceof such situation, waiting time increases, affectingquality and speed of care [3]. Despite EDs are underthose huge, and growing demands they suffer severalbudget cuts. Nevertheless, such critical ED servicemust be satisfied with the best quality as quickly aspossible. An obvious solution to this problem is to increasethe capacity of EDs. Such capacity is limitedby the size of the healthcare facility and the availablestaff, which includes physicians, nurses, admissions,and services personnel. However, such straightforwardsolution is not the best approach, and could beunrealizable. Healthcare system heads must maximize,for example, the use of healthcare resources, inorder to minimize patient waiting time and increasepatient satisfaction, whereas being constrained bylimited budget.This paper presents the results of an ongoing researchproject that is being carried out by the ResearchGroup in Individual Oriented Modeling (IoM)in the University Autonoma of Barcelona (UAB),with the participation of the ED head team of theHospital of Sabadell in Cataluña, Spain. The generalobjective of the project is to develop a simulatorof ED’s operation that, used as a decisionsupport system (DSS), could help the heads of EDsto set up strategies, and management guidelines toenhance the performance of such EDs. As a firststep to towards this goal, the main objective of thiswork is to propose a simple but realistic simulationmodel to represent the operation of EDs, in orderto study their optimum performance under certainoperational and economical conditions. The mathematicalformalism of the latter is a multidimensionaloptimization problem which can be stated by equation(1):max / min f(X )subject tox ∈ C(1)where f : C → R, and f(X ) at any X ∈ C cannot beevaluated exactly, and must be estimated via a simulationprocedure by assuming that X is discrete,global sampling from X is possible. The goal is toidentify the staff members of EDs that optimize itsperformance, taking into account the complexity ofEDs and their optimum expected performance needsto be estimated via simulations. However, optimizationvia simulation is a difficult problem [4], as simulationsare usually computationally expensive, i.e.JP2011-165

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011even estimating f(X ) at a single point X ∈ C inequation (1) may require substantial effort. Consequently,only few alternatives can be explored.Herewith, the ED is modeled by an Agent-BasedModel (ABM), in which all rules within the modelconcern the involved agents (in our case the doctors,triage nurses and admission personnel, and the patients),no higher level behavior is modeled. Thesystem behavior emerges as a result of local level actionsand interactions [5]. This model describes thecomplex dynamics found in an ED, representing eachindividual and system as an individual agent. Twodistinct kinds of agents have been identified, activeand passive. Active agents represent the individualsinvolved in the ED, in this case all human actors,such as patients and ED staff (admission staff,nurses, doctors, etc). Passive agents represent servicesand other reactive systems, such as the informationtechnology (IT) infrastructure or services usedfor performing tests. State machines are used to representthe actions of each agent. This takes into considerationall the variables that are required to representthe many different states that such individual(a patient, a member of hospital staff, or any otherrole in the EDs) may be in throughout the course oftheir time in a hospital emergency department. Thechange in time of these variables, invoked by an inputfrom an external source, is modeled as a transitionbetween states. The communication between individualsis modeled as the inputs that agents receiveand the outputs they produce, both implicitly andexplicitly. In order to control the agent interaction,the physical environment in which these agents interactalso has to be modeled, being sufficient to doit as a series of interconnected areas, such as admissions,triage box, the waiting room, and consultationsuits.The remainder of this article is organized as follows;section II describes the related works. The proposedemergency department model is detailed in sectionIII, while the results of initial simulation optimizationsare given in section IV. Finally, in section Vthe conclusions and future work are presented.II. Related worksThe interest on simulating healthcare systems isnot new, in 1979 computer simulations were appliedto hospital systems to improve the scheduling ofstaff members [6], and in another simulation [7] theaim was to quantify the impact that the number ofstaff members, and beds had on patient throughputtime. Moreover, a survey of discrete-event simulation(DES) in healthcare clinics was presented in [8].Although discrete-event simulation is widely usedin simulating healthcare systems, agent technology isa good option in healthcare applications, since it isbetter to characterize the operation of complex systemsas the EDs are. ABM can explicitly model thecomplexity arising from individual interactions thatarise in the real world. Agent-based simulation allowspeople to model their real-world systems in waysthat either not possible or not readily accomodatedusing taditional modeling techniques, such as DESor system dynamics [9]. Previous works modelinghealthcare systems have focused on patient schedulingunder variable pathways and stochastic processdurations, the selection of an optimal mix of patientadmission to optimize the use of resources and patientthroughput [10]. Work has been performed toevaluate patient waiting times under different EDphysician schedules, but only one utilized real data[11] and another one patient diversion strategies [12],both using different degrees of agent-based modeling.There is a relevant article which uses ABM to simulatethe workflow in ED [13]. It focus on triage andradiology process, but not real data was used, theacuity of patients are not consider, and healthcareproviders do not always serve patients in a first-comefirst-servebasis.Simulation optimization is used to improve the operationof ED in [14], using a commercial simulationpackage, and in [15] the authors combine simulationwith optimization, which involves a complexstochastic objective function under a deterministicand stochastic set of restrictions.Finally, an evolutionary multiobjective optimizationapproach is used for dynamic allocation of resourcesin hospital practice [16], while in [17] the authorsfound that agent-based approaches and classicaloptimization techniques complement each other.As stated above, this proposal addresses manyof the issues surrounding the modeling and simulationof a healthcare emergency department using theagent-based paradigm, where the efficiency of agentsin this area has not been totally explored yet. Basicrules governing the actions of the individual agentsare defined, in an attempt to understand micro levelbehavior. The macro level behavior, that of the systemas a whole, emerges as a result of the actionsof these basic building blocks, from which an understandingof the reasons for system level behavior canbe derived [18].III. Emergency department modelAs mentioned above, the Emergency Departmentmodel defined in this work is a pure Agent-BasedModel, formed entirely of the rules governing the behaviorof the individual agents which populate thesystem. Through the information obtained duringinterviews carried out with ED staff at the Hospitalof Sabadell, two kinds of agents have been identified;these are active and passive agents. The activeagents represent people and other entities that actupon their own initiative: patients, admission staff,sanitarian technicians, triage and emergency nurses,and doctors. The passive agents represent systemsthat are solely reactive, such as the loudspeaker system,patient information system, pneumatic pipes,and central diagnostic services (radiology service andlaboratories). All the details of both, active and passiveagents, as well as the communication model, andthe environment where the agents interact are de-JP2011-166

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tailed in [19].A. Problem descriptionIV. OptimizationThe simulator for this work is used as a black boxas described below, includes simple realistic descriptorsof the ED’s: agents, basic physical infrastructure,and operating practices. Nevertheless the morerealistic the simulator is, the better results and optimizationsare. It is implemented by the agentbasedsimulation environment NetLogo [20], whichis well suited for modeling complex systems such asthe EDs. For simplicity, only four different typesof active agents are considered: admission staff (A),nurses (N), doctors (D), and patients. The ED staffhave two kinds of expertise: low and high, labeledas junior, and senior, respectively. Junior staff willrequire more time to accomplish their tasks than seniors,which cost-wise are more expensive (see TableI).The initial scenario adopted for the experiments isto simulate patients moving through a simplified EDphysical infrastructure that includes four primary areas:admissions, triage (up to three boxes), two waitingrooms (one for patients before triage, and theother for patients who have passed the triage process,and are waiting for treatment), and the diagnosisand treatment area (four boxes). The followingbasic patient attributes were assumed. Patientsarrive to the ED by their own, and wait to be attendedin the admission area. Then, patients stay inthe first Waiting Room (WR1), until a triage nursecall them. After the triage process patients pass toa second waiting room (WR2), and stay there untilan available doctor calls them to start the diagnosis,and to prescribe a treatment (which might includelaboratory tests) depending on the patient’s symptoms,and physical condition. Finally, patients aredischarged from the ED. Such simplified ED layoutis shown in Figure 1. Although realistic treatmentis based on the acuity of patients, in this initial simulationpatients we assumed that patients have thesame path throughout the ED. In this experiment aconstant pattern of patients arrival pattern has beenassumed, since we would like first to work with asimpler model. Also it will be assumed that patientsarrive to the ED after a certain time step, and withfour different patients arrival probabilities (P) 20, 40,60, and 80%. Those probability values are used toemulate the randomness of the incoming patients tothe ED.The multidimensional optimization problem consideredin this paper aims to find the optimal EDstaff configuration under certain operational constrains(the optimal solution will correspond to theminimum value of an index which is defined furtherdownin the application experiments). The dimensionof the problem corresponds to: the typesand number of ED staff considered, i.e. doctors(D), triage nurses (N), and admissions personnel (A),which could be, as stated above, junior or senior; theFig. 1: Agent Based Simulator of the simplifiedEmergency Department layout implemented withNetLogo.working time units considered for each of them, theirassociated cost units. The assumed values of each ofthose are shown in the Table I. This represents acombinatorial or multidimensional problem (whereeach variable or in this case ED staff member representsone dimension plus the patients arrival, i.e.the input to the ED). Such combinatorial problemis shown in Table II for doctors -14 cases- (nursesand admission personnel have similar combinations-9 cases for each of them). Taking this into accountspecific scenarios or configurations have to be simulatedseveral times, changing parameters to showthe effect of considering different probabilities of thepatients arrival time, this strategy will allow us togenerate set of results from which particular effectscan be analyzed.TABLE I: Staff members with their associated costs,and working time according to their kind.Agent Cost (e) Time (ticks) # of AgentsSenior (S) Junior (J) Senior (S) Junior (J)Doctor (D) 1,000 500 260 350 1 – 4Nurse (N) 500 350 90 130 1 – 3Admin (A) 200 150 20 35 1 – 3TABLE II: 14 Doctors (D) combination. Two kindsof doctor, Junior (J), and Senior (S). DRi representsDiagnosis Roomi.DR1 DR2 DR3 DR4DJ - - -DS - - -DJ DJ - -DS DS - -DJ DJ DJ -DS DS DS -DJ DJ DJ DJDS DS DS DSDJ DS - -DJ DJ DS -DJ DJ DS DSDJ DJ DJ DSDJ DS DS DSDJ DS DS -Even with this simple setting of an ED the searchspace is large, i.e. the search space has 4,536 (whichJP2011-167

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011results of assuming a combination of two types -junior or senior- of up to 4 doctors, 3 nurses, 3 admissions,and 4 different probabilities of patients arrival,i.e. 14 × 9 × 9 × 4) combinations from whichthe optimal combination that minimizes the desireindex, under some restrictions, will be obtained. Inthe experiments shown in sections IV-B and IV-C theperiod simulated of the ED operation was of 24 hrs.(which represent 25,000 ticks -NetLogo’s time stepforall the experiments, and an average input of 400patients, which is the average incoming patients thatthe heads of ED of the Hospital of Sabadell have reported).Two different indexes were set in order to evaluatethe utility of the Agent-Based ED simulator for optimizingthe resources. Exhaustive search techniquewas used to obtain the optimum in the experimentsreported in sections IV-B and IV-C. All simulationswere done using the simulator described previously,using the NetLogo’s BehaviorSpace tool, serially andusing an IBM cluster, which has 32 compute nodeswith 2 x Dual-Core Intel(R) Xeon(R) CPU 5160 runningat 3.00GHz, with 12 GB of RAM, and 4MB ofL2 share cache (2x2).B. First experimentThe first index aimed to minimize patient waitingtime in the ED, with cost configuration less orequal to 3,500 e. Thus, the first index is expressedmathematically in equation (2).(a) Average patient waiting time for a P = 20%.Min e Time (ticks) # staff D N A1 3,200 428 5 2 S 2 S 1 S2 2,900 428 5 2 S 1 S 2 S3 2,850 428 5 2 S 1 S 1 S, 1 J(b) Staff configurations that have the minimum wt for a P =20%. They are shown as triangles in Figure 2a.Fig. 2: Average patient waiting times graph and theircorresponding table with the optimal staff configurationsfor a P = 20% of patients arrival. Trianglepoints are the minimum.Minimize patient waiting time f(D, N, A)subject to D cost + N cost + A cost = Cost ≤ 3, 500 e(2)The results are shown in Figures 2, 3, 4, and 5;where the circle points are the staff configurationsthat satisfy the restriction, while the triangle pointsare the minimum for each different case of probability,20%, 40%, 60%, and 80%, respectively. Theminimal configurations are presented in Figures 2b,3b, 4b, and 5b, as well as their costs.In Figures 2a and 2b, there are three different staffconfigurations that have the average minimum waitingtime, but with different costs. Also, in the sameFigure 2a, it can be appreciated that there are manyother staff configurations that are quite close to theminimum time, but less expensive.In the other cases, where the probability P of patientsarrival increases, i.e. has higher probability ofpatients arrival, there are only few staff configurationsaround the minimum, or clearly only one. Notonly does the patient arrival increase, but also theminimum average patient waiting time, as expected,as well as the cost of the staff configuration, and alsothe standard deviation of the average patient waitingtime (wt) are shown in Table III. The number ofpatients increases at waiting rooms, both WR1 andWR2 ( shown in Figure 1) at times t1, t2, t3, andt4 (each time represents every 6,250 ticks of simulation),and finally the number of unattended patientsincreases as well. In Table III all these results are(a) Average patient waiting time for a P = 40%.Min e Time (ticks) # staff D N A1 3,150 514 5 2 S, 1 J 1 S 1 J2 3,200 514 7 4 J 2 S 1 S(b) Staff configurations that have the minimum wt for a P =40%. They are shown as triangles in Figure 3a.Fig. 3: Average patient waiting times graph and theircorresponding table with the optimal staff configurationsfor a P = 40% of patients arrival. Trianglepoints are the minimum.shown. It is noticed when the number of patient arrivalprobability is higher, i.e. 80%, patients in thewaiting rooms increases (shown in Table III).C. Second experimentThe second index aims to minimize a compoundindex: cost × time, CT, subject to a time restrictionthat should be less or equal to 428, that is the averageJP2011-168

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Minimize cost × time(CT) f(D, N, A)subject to T ime P =80% ≤ T ime P =20% 428(3)(a) Average patient waiting time for a P = 60%.Min e Time (ticks) # staff D N A1 3,400 790 7 1 S, 3 J 2 J 1 S(b) Staff configurations that have the minimum wt for a P =60%. They are shown as triangles in Figure 4a.Fig. 4: Average patient waiting times graph and theircorresponding table with the optimal staff configurationsfor a P = 60% of patients arrival. Trianglepoints are the minimum.Fig. 6: Results y = cost × time. Triangle points areminimum, and a worthy staff configuration, respectively.This index was set to test the simulator with a nonsimpleobjective function, as well as to find whichED staff configuration yields the best quality of service,i.e. to maximize patient throughput. The Figure6 shows all the search space, 16,632 staff scenarios(which results of assuming a combination of twotypes -junior or senior- of up to 8 doctors, 6 nurses,and 4 admissions, i.e. 44 × 27 × 14). There are manyscenarios that give a good index value, but there aretwo of them that are the most important, as shownin Table IV.TABLE IV: Two worthy staff configurations thatgive almost the same quality of service.(a) Average patient waiting time for a P = 80%.Min e Time (ticks) # staff D N A1 3,350 3,266 7 1 S, 3 J 2 J 1 J(b) Staff configurations that have the minimum wt for a P =80%. They are shown as triangles in Figure 5a.Fig. 5: Average patient waiting times graph and theircorresponding table with the optimal staff configurationsfor a P = 80% of patients arrival. Trianglepoints are the minimum.TABLE III: Results for the best average minimumfor each of the four presented scenarios.P Time σ wt e # attended # unattended # patients at WR1 # patients at WR2(ticks) patients patients t1, t2, t3, t4 t1, t2, t3, t420 428 48 (11%) 2850 83 1 0,0,0,0 0,0,0,040 514 81.5 (15.9%) 3150 182 4 0,0,0,1 0,0,0,060 790 174.5 (22.1%) 3400 290 8 1,1,0,1 3,2,4,180 3266 1670.4 (51.2%) 3350 294 100 8,19,32,43 12,25,37,51waiting time when the patients arrival probabilityis 20%. This index is expressed mathematically inequation (3).Best e Time (ticks) Cost × T ime # attended patients σ wt # staff D N A1 4,000 585.7 2,342,800 378 58.6 (10%) 9 6 J 2 J 1 J2 3,600 1,725.7 6,212,520 340 602.4 (34.9%) 9 5 J 2 J 1 S, 1 JAlthough both staff configurations are almost thesame, they have different minimum average waitingtime, this is why the first staff configuration label asBest 2, despite its lower cost has a worst minimumaverage waiting time. Not only the index is differentand higher, but its standard deviation of patientwaiting time is higher. It is important to notice thata staff configuration a bit more expensive has almost10% lower variation coefficient of the patient waitingtime, as well as almost a third lower index value andminimum average waiting time.V. Conclusions and future workA simple but realistic Agent-Based Model to simulateHealthcare Emergency Departments (ED) hasbeen proposed an applied. The main objective ofthe model is to be used as a tool to help EDs managersin setting up strategies and management guidelinesto optimize the operation of EDs. The modelJP2011-169

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011takes into account the complexity and dynamic natureof the EDs which are difficult to characterize.The model uses Moore state machines based agentswhich act and communicate within a defined layout.The simulations presented here serve to testthe model. Two simulation experiments were carriedout using real data about the staff configurationand the (minimum) physical infrastructure of aHospital ED. Two different indexes were set to evaluatethe operation of the Agent-Based EmergencyDepartment simulator. Even though the search ofthe optimum staff configurations analyzed, 4,536 and16,632 for the first and second experiments, respectively,were performed through an exhaustive searchtechnique (which implies a lot of search time) theresults are encouraging, since not only they are asexpected (larger and more experienced staff lead toshorter average patient waiting time), but also showinteresting results when the waiting time standarddeviation is analyzed. Indeed the simulation experimentsallowed to understand, and analyse better theproblem. However, even with the small problem sizeanalyzed the number of combination is large, as wellas the computing time. Moreover, the resources thatthis problem would demand to perform statisticalanalysis for longer periods (first to reproduce andthen to foretell) are huge. Therefore, a better optimizationapproach rather than exhaustive search,must be used.As future work, an alternative methodologyscheme for optimization is being devised. Thisapproach consists in finding a continuous functionthat describes the Emergency Department operation,which is a discrete and multidimensional problem,and through such function will allow us to obtain theoptimum, or at least reduce the search space. Thus,getting as a result of doing such an intelligent searchwill very likely reduce time and computing resourcesutilized. This scheme would be an intermediate approachbetween an exhaustive search technique anda heuristic one. Moreover, due to the multidimensionalnature of the problem, i.e. large number of individuals,the number of states in the state machineof each individual, and the different time periods, alarge number of values should be computed. Therefore,High Performance Computing will have to beused.AcknowledgmentsThis research has been supported by the MICINNSpain, under contract TIN2007-64974.References[1] Stephen R. Pitts, W. Niska Richard, Xu Jianmin, andW. Burt Catherine, “National Hospital AmbulatoryMedical Care Survey: 2006 emergency department summary,”National health statistics reports, vol. 2008, no.7, August 2008.[2] “Unidad de urgencias hospitalaria. Estándares y recomendaciones,”2010.[3] Andrew P. Wilper, Steffie Woolhandler, Karen E. Lasser,Danny McCormick, Sarah L. Cutrona, David H. Bor, andDavid U. Himmelstein, “Waits To See An Emergency DepartmentPhysician: U.S. Trends And Predictors, 1997–2004,” Health Affairs, vol. 27, no. 2, pp. w84–w95, 2008.[4] Michael C. Fu, “Feature article: Optimization for simulation:Theory vs. practice,” INFORMS Journal onComputing, vol. 14, no. 3, pp. 192–215, 2002.[5] Eric Bonabeau, “Agent-based modeling: Methods andtechniques for simulating human systems,” Proceedingsof the National Academy of Sciences, vol. 99, pp. 7280–7287, May 2002.[6] Walton M. Hancock and Paul F. Walter, “The useof computer simulation to develop hospital systems,”SIGSIM Simul. Dig., vol. 10, no. 4, pp. 28–32, 1979.[7] Charles E. Saunders, Paul K. Makens, and Larry J.Leblanc, “Modeling emergency department operationsusing advanced computer simulation systems,” Annals ofEmergency Medicine, vol. 18, no. 2, pp. 134–140, 1989.[8] J. B. Jun, S. H. Jacobson, and J. R. Swisher, “Applicationof discrete-event simulation in health care clinics:A survey,” Journal of the Operational Research Society,pp. 109–123, February 1999.[9] Peer Olaf Siebers, Charles M. Macal, Jeremy Garnett,D. Buxton, and Michael Pidd, “Discrete-event simulationis dead, long live agent-based simulation!,” Journal ofSimulation, vol. 4, no. 3, pp. 204–210, Sep 2010.[10] Anke K. Hutzschenreuter, Peter A. N. Bosman, IlonaBlonk-Altena, Jan van Aarle, and Han La Poutré,“Agent-based patient admission scheduling in hospitals,”in AAMAS ’08: Proceedings of the 7th internationaljoint conference on Autonomous agents and multiagentsystems, Richland, SC, 2008, pp. 45–52, InternationalFoundation for Autonomous Agents and Multiagent Systems.[11] Spencer S. Jones and R. Scott Evans, “An agent basedsimulation tool for scheduling emergency departmentphysicians,” in AMIA Annual Symposium proceedings,AMIA Symposium, 2008, pp. 338–342.[12] Marek Laskowski and Shamir Mukhi, “Agent-based simulationof emergency departments with patient diversion,”in eHealth, 2008, pp. 25–37.[13] Lu Wang, “An agent-based simulation for workflow inemergency department,” in Systems and InformationEngineering Design Symposium, 2009. SIEDS ’09., 24-24 2009, pp. 19 –23.[14] T. Ruohonen, P. Neittaanmaki, and J. Teittinen, “SimulationModel for Improving the Operation of the EmergencyDepartment of Special Health Care,” in SimulationConference, 2006. WSC 06. Proceedings of the Winter,3–6 2006, pp. 453–458.[15] Mohamed A. Ahmed and Talal M. Alkhamis, “Simulationoptimization for an emergency department healthcareunit in Kuwait,” European Journal of OperationalResearch, vol. 198, no. 3, pp. 936 – 942, 2009.[16] Anke K. Hutzschenreuter, Peter A. Bosman, and HanPoutré, “Evolutionary multiobjective optimization fordynamic hospital resource management,” in EMO ’09:Proceedings of the 5th International Conference on EvolutionaryMulti-Criterion Optimization, Berlin, Heidelberg,2009, pp. 320–334, Springer-Verlag.[17] Jan A. Persson, Paul Davidsson, Stefan J. Johansson,and Fredrik Wernstedt, “Combining agent-based approachesand classical optimization techniques,” in EU-MAS, 2005, pp. 260–269.[18] Hayden Stainsby, Manel Taboada, and Emilio Luque,“Towards an agent-based simulation of hospital emergencydepartments,” in SCC ’09: Proceedings of the2009 IEEE International Conference on Services Computing,Washington, DC, USA, 2009, pp. 536–539, IEEEComputer Society.[19] Manel Taboada, Eduardo Cabrera, Ma Luisa Iglesias,Francisco Epelde, and Emilio Luque, “An agent-baseddecision support system for hospitals emergency departments,”Procedia Computer Science, vol. 4, pp. 1870 –1879, 2011, Proceedings of the International Conferenceon Computational Science, ICCS 2011.[20] U. Wilensky, “Netlogo,” 1999, Northwestern University,Center for Connected Learning and Computer-BasedModeling.JP2011-170

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Reducción de ruido impulsivo Fijo y Uniformeen imágenes digitales usando las GPUs.M. Guadalupe Sánchez 1 Vicente Vidal 2 Jordi Bataller 3 Alejandro Rivera 4Resumen— La gran demanda de aplicaciones entiempo real y gráficos en 3D de alta definición, han hechoque evolucionen no sólo en las implementacionesde gráficos, sino también las aplicaciones de propósitogeneral basada en la GPU. El problema de la reducciónde ruido impulsivo en imágenes a color es unproceso ampliamente estudiado en el campo de procesamientode imágenes. Con este fin, muchos métodosse han propuesto, sin embargo, el coste computacionalen la mayoría de ellos es muy alto si el tamaño dela imagen es grande y se requiere procesamiento entiempo real. En este artículo presentamos un métodopara reducir el ruido impulsivo (modelo de valor fijo yaleatorio), basado en el concepto de peer group. Utilizamosla Unidad de Procesamiento Gráfico (GPU)para obtener una aplicación paralela mejorando la eficienciacomputacional. Los resultados muestran queel problema de la reducción de ruido impulsivo con elmétodo propuesto puede ser paralelizado y es eficienteen calidad, coste computacional y robustez.Palabras clave— Eliminación de ruido, algoritmo paralelo,peer group, GPU, CUDA.I. IntroducciónMUCHOS desarrolladores e investigadores estánencontrando aplicaciones prácticas basadas enlas GPUs (Graphics Processor Units) para acelerarel procesamiento de datos o en cálculos complejos.Las GPUs están especializadas en computación decálculo intensivo y altamente paralelo. En la actualidadmuchas aplicaciones en el procesamiento deimágenes y vídeo requieren un rendimiento en tiemporeal, por ejemplo, en video-vigilancia o en medicina.Las imágenes tienden a ser dañadas debido a sumala adquisición o transmisión a través de un canalcontaminado [1], [2], [3], lo que afecta su procesamiento.Esto hace necesario un proceso previo conla finalidad de eliminar el ruido en la imagen utilizandotécnicas de filtrado.Dos tipos comunes de ruido son, el ruido gaussianoy ruido impulsivo. El más usual es el ruidoimpulsivo, que se presenta durante la transmisión dedatos por un canal contaminado, sensores ruidososo en errores en la captura de los datos. Estos erroressólo afectan a ciertos píxeles de la imagen [3].El modelo más común de ruido impulsivo (Salt yPepper o valor fijo)considera que el impulso es, unvalor extremo en el rango de la señal reemplazandosu valor original. Un segundo tipo es cuando un pixeles reemplazado por un valor aleatorio uniformemente1 Dpto. de Sistemas y Computación, Instituto Tecnológicode Cd. Guzmán, e-mail: msanchez@dsic.upv.es2 Dpto. Sistemas Informáticos y Computación, Univ.Politécnica de Valencia, e-mail: vvidal@dsic.upv.es3 Dpto. Sistemas Informáticos y Computación, Univ.Politécnica de Valencia, e-mail: bataller@dsic.upv.es4 Dpto. Sistemas y Computación, Instituto Tecnológico deCd. Guzmán, e-mail: arivera@itcg.edu.mxdistribuido dentro del rango de la señal [1]. En estetrabajo se aborda el ruido impulsivo de ambos tipos.Por lo general, las técnicas de eliminación de ruidode una imagen tienen dos pasos: la detección y el filtradode los pixeles ruidosos. Algunas técnicas parala detección de píxeles corruptos utilizan el conceptode peer group. El peer group es el conjunto de pixelessimilares a uno dado, de acuerdo a una medidade distancia [4], [5].En este artículo presentamos un algoritmo paralelobasado en el peer group y la norma euclideacomo la métrica de distancia. Nuestro método es unaadaptación de los algoritmos secuenciales presentadosen los paper [3], [6] y [9] para reducir el ruidoimpulsivo, para operar eficientemente en una GPU.Para demostrar que el algoritmo es altamente paralelizabley eficiente en calidad y robustez, se comparanlos costes de cómputo paralelo con los de su versiónsecuencial.El trabajo se organiza de la siguiente manera. Lasección 2 presenta la propuesta del algoritmo paralelopara la GPU. El estudio experimental se muestraen la sección 3. La sección 4 analiza la complejidadcomputacional del algoritmo con el enfoque en la utilizaciónde la memoria de texturas. Por último en lasección 5 se concluye el trabajo.II. Algoritmo paralelo para detectar yeliminar ruido (GPU-PGE)En este estudio, hemos implementado un algoritmoparalelo llamado GPU-PGE (Unidad de ProcesamientoGráfico - Peer Grup con métrica Euclidea),que utiliza la arquitectura GPU para eliminar elruido impulsivo en imágenes digitales. El procesopara eliminar el ruido en las imágenes se ha divididoen dos etapas. En el primer paso (p 1 ) los píxeleserróneos se detectan y en el segundo paso (p 2 ) lospíxeles erróneos son filtrados. En el p 1 los píxelesson etiquetados como corruptos o no corruptos, deacuerdo con el número de píxeles que pertenecen alpeer group P (x i , d). Para determinar el conjuntode elementos que pertenecen al peer group, se utilizala norma euclídea entre los píxeles (vectores) de laimagen a color denotada como ||x i − x j || 2 , donde x ies el píxel central de una ventana W tamaño n x n(n = 3, 5 ...) y el x j es un pixel vecino de x i en W .Por lo tanto, el P (x i , d) representa el conjunto:{x j ∈ W : ||x i − x j || 2 ≤ d} (1)El peer group asociado con el píxel x i en W denota elconjunto de píxeles x j de W , de modo que la normaeuclidiana no exceda a d, donde d > 0. En [4] di-JP2011-171

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011viden la detección de pixeles ruidosos en dos fases,en la primera fase, la imagen la dividen en ventanasdisjuntas y los píxeles son etiquetados como corruptos,no corruptos y no diagnosticados, considerandolos no diagnosticados en la segunda fase. En nuestraimplementación paralela no hemos dividido la imagenen las ventanas disjuntas ya que un solo threadprocesa completamente un pixel. Esto es, hay unthread por cada píxel en la imagen. Así, cada subprocesorealiza la clasificación (corrupto o no corrupto),y por lo tanto, tenemos un solo paso para la fase dedetección.Utilizamos un kernel para ejecutar el paso 1 yotro para el paso 2. El primer kernel ejecuta elalgoritmo 1 GPU-PGE. Cada thread lee los valoresRGB de los píxeles y crea una ventana de tamañon x n para analizarla. Se calcula el peer group, sila cardinalidad es mayor o igual a m, entonces elpixel x i es etiquetado como no corrupto (p n c), delo contrario el píxel es etiquetado como corrupto(p c ). Hemos añadido un byte padding (bp) a cadaconjunto RGB (3 bytes) de la imagen, que se utilizapara almacenar el estado del píxel como corrupto ono corrupto.Algoritmo 1. GPU-PGE p 11. Cada thread analiza un pixel de la imagen2. Cada Thread do3. construye su ventana W de tamaño n × n, centrado enx i ;4. Lee los valores RGB de cada pixel dentro de W ;5. Calcula el peer group P(x i , d), Ecuación (1);6. if ♯P(x i , d)≥ (m + 1) then7. x i es declarado como pixel non-corrupted (p nc);8. escribir p nc en el byte padding bp;9. else10. x i es declarado como pixelcorrupted (p c);11. escribir p c en el byte padding bp;12. end13. endDespués de aplicar el algoritmo 1, obtenemos lospíxeles etiquetados como p c y p nc . Para filtrar lospíxeles etiquetados como p c , el kernel 2 ejecuta elalgoritmo 2 GPU-PGE. Cada thread lee el byte bp,si se trata de un pixel corrupto, entonces aplicamosel método AMF (Filtro de Media Aritmética) de lospíxeles vecinos que no sean corruptos.Algoritmo 2. GPUPGE p 21. Cada thread lee el byte bp2. if pb==p c then3. Accesar al byte bp de los pixeles de W ;4. ∀p nc d W leer los valores RGB;5. Calcular el AMF de los pixeles no corruptos p c;6. Reemplazar el valor RGB con la salida de AMF;7. endIII. Estudio ExperimentalEn esta sección se presentan los resultados experimentalesrealizados en un Mac OS X (Intel Quad-Core Xeon de 2 x 2,26 GHz, 8 GB de RAM) conuna GPU de NVIDIA (GeForce GT 120, 512 MB dememoria).Para evaluar la eficacia del filtro propuesto, hemosutilizado algunas imágenes de la Base de Datos de(KODAK), éstas se muestran en la figura 1. Lasimágenes están en formato RGB con 3 canales y 8bits por canal, donde cada píxel es un vector de componentescon tres valores enteros entre 0 y 255. Estasimágenes fueron contaminados con los dos tipos deruido impulsivo.a b cFig. 1. Imágenes utilizadas. a) Caps 768x512 b) World2400x1200 c) Statua 512x768.El ruido uniforme lo denotaremos como NMγ. Elruido introducido en alguno de sus canales o en todoscon valores uniformemente distribuidos en el intervalo[0,255].El segundo tipo de ruido llamadoSalt and Pepper o valor fijo lo denotaremos comoNMα. En este tipo, el ruido introducido se presentaen algún canal o en todos, cambiando su valor poralguno de los extremos dentro del rango de la señal0 ó 255.El valor m y d dependerán de la intensidad y tipode ruido que se maneje. La Tabla 1 muestra los resultadosóptimos de d. Como podemos ver, el valor ded es menor en imágenes con variedad de colores y esmayor con poca variación del color o colores oscuros.Para las imágenes Caps y Statua con ruido uniformeruido impulsivo, los mejores resultados se obtienencon m = 2. Por el contrario, el ruido fijo tienedos variantes: m = 2 cuando las imágenes tienen unporcentaje una menor o igual al 10% de intensidadde ruido y m = 3 cuando es superior al 10%.Para evaluar el desempeño del filtro paralelo propuesto,usamos las medidas objetivas PSNR (PeakSignal-to-Noise Ratio) y para medir la supresión delruido, MAE (Mean Absolute Error) para medir laconservación de la señal.TABLA IValores Óptimos de d con diferentes densidades deruido impulsivo.Image NM NM NM NM NM NM NM NMα γ α γ α γ α γ5% 5% 10% 10% 20% 20% 30% 30%Caps 45 63 45 51 57 53 51 52Statue 70 70 70 70 70 70 70 65Los resultados experimentales de las tablas 2 y 3han sido comparados con otros filtros, cuyos resultadosestán publicados en el trabajo [4]. Los filtroscon los que han sido comparados son: VMF, FIVF,JP2011-172

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011NAVMF, PGF, FPGF, IPGF y IFPGF y sus resultadosse refieren a la ejecución de forma secuencial.La tabla 2 muestra los resultados obtenidos en calidadcon la imagen Caps y NMγ. La columna GPU-PGE* es una versión de la GPU-PGE si se conoce deantemano que el ruido de la imagen es de tipo valorfijo, trabajando sólo con píxeles que tienen un valorextremo en uno de sus canales.La tabla 3 presenta los resultados de calidad dela imagen Caps con ruido impulsivo valor uniforme.Como podemos ver, en la mayoría de los casos el algoritmoparalelo se elimina mayor cantidad de ruidocomparándolo con los otros filtros.La figura 2 muestra la imagen Caps con 20% deruido impulsivo valor fijo y uniforme, el mapa conlos píxeles corruptos encontrados, y las imágenes resultantesdespués del paso de filtrado.TABLA IIIResultados del filtro en comparación con otros parala imagen Caps corrupta con diferentes densidades deruido impulsivo valor uniforme5% 10% 20%Filter MAE PSNR MAE PSNR MAE PSNRNoisy 4.29 20.75 8.31 17.86 16.77 14.79VMF 2.74 31.68 2.96 31.07 3.54 29.12FIVF 0.32 38.32 0.66 35.11 1.34 31.71NAVMF 0.30 38.98 0.55 36.45 1.28 32.16PGF 0.44 37.59 0.63 36.25 1.20 33.42FPGF 0.41 38.05 0.63 36.35 1.35 32.62IPGF 0.27 39.23 0.52 36.66 1.15 32.62IFPGF 0.38 38.50 0.59 36.78 1.16 33.44GPUPGE 0.33 39.25 0.57 37.04 1.19 33.51TABLA IVTiempo en milisegundos de la ejecuación delalgoritmo con la imagen World, usando acceso a lamemoria globalGPU GPU GPU TotalGPU y%Noise t 1 t 2 Total t 1 y t 2 CPU5% 53.09 36.27 89.36 111.2110% 64.81 57.26 122.08 143.9320% 64.79 75.65 140.45 162.2930% 64.80 82.25 147.06 168.91a b cd e fFig. 2. a) Imagen con un 20% de ruido impulsivo valor fijob) Detección de los pixeles ruidosos c) Imagen Filtradad) Imagen con 20% de ruido impulsivo valor uniforme e)Detección de los pixeles ruidosos f) Imagen Filtrada.TABLA IIResultados del filtro en comparación con otros parala imagen Caps corrupta con diferentes densidades deruido impulsivo valor fijo5% 10% 20%Filter MAE PSNR MAE PSNR MAE PSNRNoisy 2.54 21.76 4.84 18.97 9.97 15.81VMF 2.65 32.11 2.80 31.66 3.05 30.94FIVF 0.31 37.95 0.63 35.22 1.21 32.41NAVMF 0.25 39.87 0.51 36.33 1.16 32.57PGF 0.41 37.43 0.66 34.63 1.28 31.24FPGF 0.39 37.26 0.66 34.16 1.54 29.59IPGF 0.23 39.32 0.41 37.79 0.86 34.91IFPGF 0.35 37.88 0.64 34.18 1.34 31.72GPUPGE 0.30 38.43 0.58 35.16 1.22 32.60GPUPGE* 0.27 39.27 0.51 35.84 1.46 33.67Hemos hecho la detección y filtrado a la imagenWorld, con un 20% de ruido impulsivo valor uniforme.Los valores utilizados para m y d son m = 2y d = 49.Para esta imagen, hemos realizado una comparativade tiempo entre las versión paralela y secuencial.La GPU tiene una memoria física que puede ser utilizadade diferentes maneras, la más común es comouna memoria global compartida. Sin embargo, sepuede utilizar en los modos: memoria local, texturay constante [9]. El acceso a los datos almacenadosen la memoria global tiene mayor latencia que otrosmodos de acceso a los datos. En nuestra aplicación seutiliza el acceso a los datos en la memoria de texturapara mejorar la eficiencia computacional.La tabla 5 muestra el tiempo que tarda en ejecutarel algoritmo GPU-PGE para acceder a los datosde la memoria global sin textura (sT) y la tabla 6, eltiempo que tarda en acceder a la memoria global contexturas (T), para la NMγ con diferentes densidadesde ruido. Se muestra el tiempo que tarda en ejecutarcada paso (cada kernel) en la GPU y el tiempo totalde procesamiento de la GPU y CPU. Como se puedever, cuando usamos la memoria global a través detexturas, el tiempo de procesamiento es, en el peorde los casos 31% menos que el acceso a la memoriaglobal sin texturas. Además, el tiempo que toma lapreparación de la imagen en la CPU y la transferenciade los píxeles de CPU a GPU y viseversa, es enla mayoría de los casos del 28,5% del tiempo total.En la tabla 7 se muestra una comparativa de losresultados obtenidos por el algoritmo en la versiónsecuencial con la versión paralela utilizando la memoriacon o sin texturas. El speedup alcanzado es de12x-13x. La figura 3 muestra que el problema de lareducción de ruido impulsivo es completamente paralelizable.IV. Análisis ComputacionalEn esta sección se presenta el análisis computacionaldel algoritmo GPU-PGE, desde el punto devista de los accesos de memoria y la demanda deoperaciones.Como se mencionó en el anterior capitulo, el procesose ha dividido en dos etapas. Uno para detectarJP2011-173

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA VTiempo en milisegundos en la ejecución del algoritmocon la imagen World con acceso a la memoria globala través de texturasGPU GPU GPU GPU yCPU%Noise t 1 t 2 Total t 1 y t 2 Total5% 23.15 31.64 54.80 76.6310% 23.15 38.40 61.55 83.4820% 23.13 46.65 69.79 91.6230% 23.13 51.58 74.72 96.57TABLA VISpeedup de la versión paralela con respecto a laversión secuencial de la imagen World.GPU y GPU y TotalCPU CPU Sequential Speedup SpeedupsT T sT T%Noise Total Total Total5% 111.21 76.63 939.21 8.44 12.2510% 143.93 83.48 1035.61 7.19 12.4020% 162.29 91.62 1182.71 7.28 12.9030% 168.91 96.57 1284.46 7.60 13.30los pixeles erróneos p 1 y p 2 para el filtrado. Los datosse estructuran en la memoria global, de manera quecada píxel de la imagen se almacena en 4 bytes, tresbytes para almacenar los canales RGB y otro para elpadding. En nuestra aplicación, se consideraron dosenfoques para el acceso a los datos en dos pasos: accesoa la memoria global sin texturas y el acceso a lamemoria global con texturas. El análisis se presentaa continuación:a) Acceso a la memoria global sin texturas (sT ):• p 1 : 3 x n 2 acceso de sólo lectura (sT r) paraobtener los valores RGB de los píxeles en W yun acceso a escritura (sT w) para el cuarto bytede RGB para indicar si el pixel es o no corrupto.Así, la expresión está dada porsT p 1 = (3 × n 2 )sT r + sT w (2)En este paso se realiza el cálculo de la distanciaeuclídea (dE) para determinar los píxeles queforman parte del peer group, y su coste, dE=η×(tres sustracciones, dos adiciones, tres productosy una raíz cuadrada), donde η = n 2 − 1corresponden a los píxeles vecinos de x i .• p 2 : n 2 accesos de lectura para obtener el valor(corrupto o no) que tiene el cuarto byte , 3 x(ηp n c) accesos de lectura para obtener los valoresRGB de todos sus vecinos que no son corruptospara el cálculo de la AMF, y tres accesos deescritura para el nuevo valor RGB y el númerototal de accesos sería,sT p 2 = (n 2 )sT r + (3 × ηp n c)sT R + 3sT w (3)En este paso se calcula la media aritmética deηp n c, el costo es de: AM c = (tres adiciones ytres divisiones) ×p n cEl costo total del uso de la memoria global es:sT = sT p 1 + dE + sT p 2 + AM c (4)b) Acceso a la memoria global con texturas (T):• p 1 : 3 x n 2 accesos de sólo lectura a la memoriade textura (T r) para obtener los valores RGBde los píxeles W , un acceso de escritura a lamemoria global (sT w) para el cuarto byte delconjunto RGB para indicar si el píxel es o nocorrupto. Por lo tanto,T p 1 = (3 × n 2 )T r + 1sT w (5)El coste computacional de la distancia euclídeaes la misma que se presentó en el paso 1 de lamemoria global sin textura.• p 2 : n 2 accesos de lectura a la memoria de texturapara obtener el valor (corrupto o no corrupto),que contiene el cuarto byte del conjunto RGBde W , 3 × (p n c) accesos a la memoria de texturapara obtener los valores RGB de todos susvecinos que no son corruptos para el cálculo deAMF, y tres accesos de escritura para el nuevovalor RGB en la memoria global, es decir,T p 2 = (n 2 )T mr + (3 × p n c)T mr + 3sT w (6)El coste computacional de la media aritméticaes la misma que se presenta en el paso 1 de lamemoria global.El costo total del uso de memoria de acceso globalcon textura,3000CPUGPUT = T s1 + dE + T s2 + AM c (7)msec25002000150010005000 5 10 20 30%noiseFig. 3. Comparación de la ejecución en GPU y CPULos costes presentados en las figuras 5 y 7 sonválidos cuando el número de píxeles que contiene laimagen N pic es menor o igual al número de threads(τ) que se liberan. De lo contrario, algunos threadque se lanzan tienen que trabajar más de una vez, yel coste computacional está dada por,(sT |T ) × β (8)donde β es la parte entera por encima del cociente(N pic ÷ τ) + 1.Los costes totales presentados se corresponden conlos pasos que se realizan cuando los datos están en lamemoria de la GPU. Otro coste computacional es laJP2011-174

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011preparación y transferencia de los datos de la CPUa la GPU, pero dependerá de la arquitectura de laGPU / CPU en uso. Los costes presentados en lastablas 5 y 6 corresponden al total de las operacionesen la GPU, y el total de la CPU y la GPU.V. ConclusionesEn este trabajo presentamos un algoritmo paraleloimplementado para la GPU, que es muy eficiente enlo que respecta a la calidad de la imagen filtrada, asícomo en el coste computacional.El algoritmo utiliza el concepto de peer grouppara eliminar el ruido impulsivo de valor fijo y elvalor uniforme. Tiene dos pasos: en el primero sedetectan los pixeles erróneos. Los píxeles ruidososse corrigen en el segundo paso. El método tieneun comportamiento muy uniforme con respecto a laintensidad del ruido impulsivo del mismo tipo enlos resultados de reducción (PSNR). La eficienciadel proceso se mantiene para los diferentes tipos deimágenes que se utilizan. Los beneficios computacionalesobtenidos en nuestro estudio con la GPUpara hacer frente a este problema, representan unareducción en el tiempo de cálculo de 12x-13x con respectoa la versión secuencial. Por esta razón, hacemosincapié en que la tecnología GPU ofrece mejorassignificativas en velocidad de cálculo y procesamientode alto nivel a un coste cada vez más accesible, porlo que muchas aplicaciones lo están utilizando.AgradecimientosEste estudio ha sido financiado por el MinisterioEspañol de Ciencia e Innovación bajo elproyecto con referencia TIN2008-06570-C04-04, y M.Guadalupe Sánchez agradece a la DGEST- ITCG porla beca concedida a través del programa PROMEP(México).Referencias[1] J. G. Camarena, V. Gregori, S. Morillas, A.Sapena,Fast detection and removal of impulsive noise using peergroup and fuzzy metrics, Journal of Visual Communicationand Image Representation, 19 (2008) 20-29.[2] J.G. Camarena, V. Gregori, S. Morillas and A.Sapena, Some improvements for image filtering usingpeer group techniques, Image Vis. Comput., vol. 28, no.1, pp. 188-201, 2010.[3] J. G. Camarena, V. Gregori, S. Morillas , A. Sapena,Two-step fuzzy logic-based method for impulse noise detectionin colour images, Pattern Recognition Letters 31(2010) 1842-1849.[4] R. Lukac, B. Smolka, K. Martin, K. N. Plataniotis,and A. N. Venetsanopoulos, Vector filtering for colorimaging, IEEE Signal Process. Mag.,vol. 22, no. 1, pp.74-86, Jan. 2005.[5] S. Morillas, V. Gregori, and A. Hervás, Fuzzy PeerGroups for Reducing Mixed Gaussian-Impulse Noise FromColor Images, IEEE Transaction on Image Processing, Vol18 No 7, November 2009.[6] S. Morillas, V. Gregori and G. Peris-Fajarns, Isolatingimpulsive noise pixels in color images by peer grouptechniques, Comput. Vis. Image Underst., vol. 110, no. 1,pp. 102-116, 2008.[7] NVIDIA Corporation, NVIDIA Programming GuideVersion 2.3.1, http://www.nvidia.com/page/home.html,2009.[8] B. Smolka, Peer group switching filter for impulse noisereduction in color images, Pattern Recognition Letters 31(2010) 484-495JP2011-175

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-176

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Estrategias de Paralelización de Algoritmos deRazonamiento para Ontologías BiomédicasEduardo J. Cepas 1 , Ginés D. Guerrero 1 , José M. Cecilia 1 , José M. García 1 y Jesualdo T.Fernández 2Resumen— Actualmente las ontologías son un métodode representación de conocimiento ampliamenteusado, especialmente las relacionadas con conceptosbiomédicos. Sin embargo su desarrollo y uso están limitadospor la gran carga de procesamiento que requieretrabajar con ellas. Gracias al uso de sistemasde computación de altas prestaciones se pueden intentarpaliar estas limitaciones. En este artículo analizamosel proceso de razonamiento con ontologías, yproponemos algunas posibles alternativas para intentaradaptar este razonamiento a un enfoque paralelo.Tras esto evaluamos alguna de las alternativas propuestascon el fin de ver hasta que punto es posibley/o viable su implementación, debido a los problemasinherentes que surgen durante el proceso de paralelización.Palabras clave— Razonadores, Ontologías, FaCT++,Snomed-CT, Tableaux, Paralelismo.I. IntroducciónEL éxito de la Gene Ontology [1] a principios deeste siglo generó un gran interés en el diseño,desarrollo y uso de ontologías biomédicas. Debido aeste interés, se han organizado no solo grupos de interésen desarrollo de ontologías biomédicas sino queorganizaciones como el OBO Foundry [2] han coordinadoel desarrollo de más de 200 ontologías y vocabularioscontrolados biomédicos en los últimos años.Una ontología es una representación formal del conocimientomediante un conjunto de conceptos pertenecientesa un dominio, y las relaciones existentesentre ellos. Para la representación de ontología seusa el Web Ontology Language (OWL) [3], que esel estándar del W3C para el intercambio de contenidossemánticos en la web. Se puede decir que OWLdefine una familia de lenguajes de representación deconocimiento en función de la expresividad de losoperadores lógicos empleados. Dentro de los sublenguajesde OWL, OWL-DL es el más representativopor estar basado en lógica de descripciones, lo cualpermite aplicar razonadores desarrollados para estetipo de lógica a las ontologías, siendo OWL-DL ellenguaje empleado en la mayor parte de ontologíasbiomédicas disponibles en la actualidad.La importancia de las ontologías biomédicas se debea varias razones. Como se ha mencionado antes,existen más de 200 ontologías biomédicas, siendo sinduda la disciplina científica que está más implicaday convencida de los beneficios de disponer de repre-1 Grupo de Arquitectura y Computación Paralela,Dpto. de Ingeniería y Tecnología de Computadores,Univ. de Murcia, e-mail: {ecepasqui, gines.guerrero,jmgarcia}@ditec.um.es.2 Grupo de Tecnologías de Modelado, Procesamiento y Gestióndel Conocimiento, Dpto. de Informática y Sistemas, Univ.Murcia, e-mail: jfernand@um.es.sentaciones formales y procesables por las máquinasdel conocimiento biomédicos. Por otro lado, las ontologíasbiomédicas tienen por lo general un gran tamañoy el volumen de información gestionado poraplicaciones biomédicas es elevado, por lo que se requierede métodos avanzados de gestión de la informacióny el conocimiento. Finalmente, el trabajo deinvestigación biomédico se basa fundamentalmenteen la inferencia a partir de datos y conocimientosprevios, por lo que el soporte de métodos de razonamientoautomático es de vital importancia. Sin embargo,para el uso óptimo de las ontologías biomédicasexisten problemas actualmente no resueltos. Porun lado, las ontologías biomédicas han sido construidascon fin de anotación de resultados experimentalesen vez de para ser empleadas como soporte deinferencias automáticas. Sin embargo, existen métodosen desarrollo para el enriquecimiento semánticode dichas ontologías [4]. Por otro lado, los razonadoresexistentes no responden en un tiempo razonablea las tareas de clasificación demandadas porontologías semánticamente ricas durante el procesode construcción, lo cual limita la implicación de losinvestigadores biomédicos en estos procesos.Es por ello que surge esta investigación, como unestudio sobre el uso de arquitecturas de alto rendimientopara dar soporte a los procesos de construccióny uso de ontologías biomédicas. El presente trabajose centrará en estudiar las posibles estrategiasque se pueden seguir para paralizar estos razonadores,analizando de su viabilidad. El documento seorganiza como sigue: en la sección II introducimoslos conceptos necesarios para entender mejor el restodel documento; posteriormente en la sección IIIse hace un estudio de los razonadores semánticos yse realiza una propuesta para su paralización, cuyaevaluación será llevada a cabo en la sección IV. En lasección V se presenta el estado del arte y finalmentela sección VI muestra las conclusiones y el trabajofuturo.II. PreliminaresLas dos principales funciones de un razonador sonla creación de un modelo a partir de una ontologíay la inferencia de nuevas propiedades no descritas.Para nuestra investigación usamos un razonadorsemántico llamado FaCT++ [6]. Está implementadoen C++ y basa su proceso de razonamiento enun algoritmo de razonamiento altamente optimizado,llamado Tableaux. FaCT++ preprocesa la ontologíade entrada OWL-DL y la transforma en una base deconocimiento (KB), dividida en dos conjuntos: TBoxJP2011-177

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011y ABox. Las TBoxs contienen conceptos que formanparte de la ontología, y se usa para crear un modelode representación del conocimiento a partir de ellos.La ABox contiene los individuos y las relaciones entreellos, haciendo uso de estas para inferir propiedadesy comprobar su consistencia con la ontología.FaCT++ tiene como objetivo principal clasificaruna ontología a partir de su TBox usando un algoritmoTableaux. Para ello se evalúa su organizaciónjerárquica (taxonomía), que es un grafo jerárquicode inclusión en donde cada nodo representa un concepto,y un nodo C es hijo de otro nodo D si existeentre ellos una relación de inclusión C ⊆ D, es decir,C está incluido en D (D es más genérico que C,o C es una especialización de D). Como se verá acontinuación, para construir esta clasificación, se vacalculando el orden parcial de inclusión entre conceptosmediante pruebas de inclusión entre pares deestos.El algoritmo Tableaux trabaja a varios niveles deabstracción y complejidad. En el nivel de abstracciónmás alto FaCT++ trabaja con conceptos. Divide lacolección de conceptos en tres grupos según una seriede propiedades: completamente definidos (CD),no completamente definidos (noCD) y no-primitivos(non-p). Los conceptos CD y noCD no requieren serprocesados mediante el algoritmo Tableaux completopara ser clasificados, mientras los conceptos non-phan de ser procesados por el algoritmo completo, portanto son computacionalmente más costosos de clasificar.Los conceptos no se clasifican en el mismoorden en que aparecen, sino siguiendo un orden quebusca minimizar el número de pruebas que va a necesitarcada concepto para clasificarse.La fase SUB (subsumption) comienza cada vez queun concepto es seleccionado y propuesto para ser clasificado.Consiste en determinar la posición correctadel nuevo concepto dentro del grafo parcial de inclusiónque hay construido hasta ese momento. Paraello se van haciendo pruebas de inclusión entre paresde conceptos, formados por el concepto actual ycada uno de los nodos que forman parte del grafo deinclusión parcial. Estas pruebas siguen un proceso declasificación en dos partes: TopDown que trata de determinarlos padres, y BottomUp que determina loshijos del concepto actual. Sin embargo, el algoritmomás importante a este nivel es la Búsqueda Baader,que va recorriendo el grafo de inclusión actual enun orden concreto, y determinando que pruebas deinclusión hay que llevar a cabo. De esta forma determinacuales son realmente necesarias y lo que es másimportante, el orden en que han de hacerse.Durante la fase de más bajo nivel, fase SAT (satisfiability),cada prueba de inclusión C ⊆ D se lleva acabo instanciando a un razonador, y equivale a comprobarsi la supuesta inclusión se satisface de acuerdoa la KB, es decir, si la contradice o no. La supuestainclusión se satisface si es posible construir un modelode acuerdo a la KB que cumpla la relación C ⊆ D,o por el contrario es inconsistente si durante la construcciónde este modelo se contradicen entre sí variosaxiomas, ya sean los generados o los ya existentes enla KB. La construcción de este modelo implica conocery tener en cuenta la lógica de descripción enque está basada la ontología, ya que este modelo seirá construyendo incrementalmente, aplicando reglasde expansión basadas en los operadores matemáticosque están incluidos en dicha lógica.Inicialmente se parte de la suposición C ⊆ D,a esta premisa se le aplicará la regla de expansióndel operador ⊆ de la lógica subyacente (SHOIN (D)en el caso de OWL-DL y FaCT++), quedando queC ⊆ KB D ≡ (C ⊓ ¬D) no es posible en KB. Actoseguido se aplicaría la regla de expansión correspondienteal operador ⊓, y así sucesivamente. Si seconsigue expandir todas las reglas y terminar el modelosin producir ninguna incoherencia el test SUB escierto, si por el contrario hay alguna contradicción,la suposición inicial C ⊆ D es falsa.Este proceso de creación de un modelo expandiendoreglas es el kernel del razonador FaCT++, y es elproceso más costoso en el que emplea la mayor partede su tiempo de procesamiento. El orden en queestas nuevas reglas se comprueban influye decisivamenteen el tiempo de procesamiento resultante, yaque el coste de aplicar los distintos operadores difiereenormemente entre unos y otros. FaCT++ trata estoestableciendo un orden de aplicación de la nuevas reglasproducidas, las reglas no se expanden en el ordenen que se producen. Para ello se usa una estructurabastante compleja llamada TODO list formada porvarias listas y colas de espera, en donde las reglas seclasifican según el operador lógico que contienen, yse aplican en un orden modificable predefinido medianteprioridades. El orden usado por defecto enFaCT++ es de menor a mayor coste computacional,priorizando siempre los operadores lógicos queimplican menor coste aunque hayan sido añadidosmás tarde que otros de mayor coste. Los operadoresque implican diversificar el modelo, lógicamente, seevalúan los últimos.III. PlanteamientoComo se verá más adelante en el trabajo relacionado,los estudios llevados a cabo sobre opciones deparalelización de algoritmos Tableaux se encuentranen fases poco avanzadas, y no han mostrado grandesprogresos en los últimos años. A continuación, mostraremosun estudio de la posible paralelización dealgoritmo Tableaux según los dos niveles de abstracciónanteriormente comentados.A. Nivel SUB: paralelismo entre pruebas de inclusiónDurante el proceso de clasificación, cuando se vaa añadir un concepto nuevo al grafo parcial de inclusión,se conoce dicho concepto, y todos los nodosque forman dicho grafo. Con lo cual, cuando empiezala clasificación de un concepto se sabe a prioriel máximo número de pruebas que hay que realizarpara clasificarlo, y estas pruebas son perfectamenteparalelizables, ya que su resultado sólo depende deJP2011-178

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011la base de conocimiento KB y no del resultado deotras pruebas, ni del estado del grafo de clasificaciónen cada momento. Este estado del grafo determinaqué tests hay que hacer para clasificar un concepto,cuántos y cuáles son necesarios. Ante esto, algunasposibilidades en paralelo que surgen son:Previamente a la clasificación, calcular en paralelotodas las posibles pruebas de inclusión entrecada par de conceptos de la ontología. Esto implicaque n conceptos necesitarían n ∗ (n − 1)test SUB. Esto supondría realizar muchas operacionesinnecesarias, lo que redundaría en unamejora, si la hubiera, poco significativa.Durante el proceso de clasificación, calcular enparalelo todas las posibles pruebas que comomucho habría que hacer para añadir un concepto.Esto supondría una sobrecarga mucho menorque la posibilidad anterior, ya que como muchohabría que hacer tantas pruebas para cada conceptocomo nodos del grafo hubiera clasificadosen cada momento. Aun así, habría que evaluar sieste enfoque podría llegar a mejorar en algún casoa la versión secuencial FaCT++, que está basadaen heurísticas.B. Nivel SAT: paralelismo dentro de la creación deun modeloUn test SAT se corresponde con la aplicación deuna regla de expansión durante el cálculo de un modelonecesario para realizar una prueba de inclusión.Por norma general estas reglas son dependientes entresí, excepto las no deterministas que producen divergenciasen el modelo. Por lo tanto cambiar el ordenen que se evalúan, o evaluarlas en paralelo suponeun gran riesgo de que el resultado del algoritmo nosea correcto o incluso de que su tiempo de ejecuciónse dispare. Los propios autores de FaCT++, adviertende que no se debe modificar el orden en que sehacen las comprobaciones [6]. Estas limitaciones enel orden se deben, en parte, a intentar minimizar laexpansión del modelo para garantizar la terminaciónsecuencial del algoritmo. Habría que evaluar si enuna arquitectura paralela con mucha mayor potenciade cálculo se podrían relajar estas restricciones,garantizando igualmente la corrección y terminacióndel algoritmo. Por otro lado, surge otro gran problemacuando se empieza la construcción de un modelo,ya que no se dispone de las reglas que hay que aplicar,es decir, qué expansiones hay que hacer, ya quelo único que se tiene al comienzo es una restriccióninicial C ⊆ D y sólo en el momento en que se compruebey se expanda esta restricción se obtendrán lasnuevas restricciones a ser comprobar. Debido a estemotivo, en cada momento tendríamos muy pocas reglasque evaluar en paralelo, ya que se van obteniendoal ir expandiendo el modelo. Para obtener unaposible mejora, al igual que en el caso del paralelismoa nivel SUB, es necesario disponer del orden devarios cientos o miles de reglas, lo cual es bastanteimprobable que suceda. Además, las posibles reglasdisponibles en cada momento, difícilmente serían independientesy habría que tener consideraciones adicionalesque perjudicarían aún más el rendimiento.Una posible opción sería expandir todas las reglasdisponibles a la vez, o expandirlas según el tipo deoperador en que se basen.IV. Evaluación de FaCT++Las ontologías usadas en las pruebas con FaCT++son cuatro: Snomed-CT, Thesaurus, Pombe y Nsennetsu.Snomed-CT [5] es la terminología médica másimportante en la actualidad, ya que constituye la basede conocimiento clínico de mayor uso en el ámbitosanitario. Muestra de su interés es su consideraciónde terminología oficial en varios países, entre ellosEspaña. Aunque su forma de representación nativano es OWL, en este trabajo usamos una conversiónautomática disponible en el Bioportal [7].Thesaurus es la ontología desarrollada por el NCIpara el dominio del cáncer, que también está disponibleen OWL en el Bioportal. Estas dos ontologíasson consideradas referencia en el ámbito biomédicoy no se pueden considerar semánticamente ricas desdela perspectiva de los axiomas y operadores lógicosque incluyen. Se basan fundamentalmente en una taxonomía.Por su parte, Pombe y Nsennetsu son dosontologías generadas automáticamente a partir de losficheros de anotaciones de los genomas de SchizosaccharomycesPombe y Neorickettsia sennetsu Miyayamarespecto de Gene Ontology, usando la versiónenriquecida de Gene Ontology descrita en [4]. Estasdos ontologías se pueden considerar semánticamentericas desde la perspectiva de los axiomas y operadoreslógicos que incluyen, pues contienen bastantepropiedades semántica que relacionan las clases de laontología.A. Descripción de entorno de simulaciónSe han realizado pruebas con la versión FaCT++secuencial, y con una implementación paralela a nivelSUB en OpenMP. Para las pruebas secuenciales se hausado una máquina con dos procesadores Intel XeonCPU E5620 Quad-Core a 2.40GHz. Por otro lado,para las pruebas de la implementación en OpenMPse ha usado un superordenador de memoria compartidadel Centro de Supercomputación de la FundaciónParque Científico de Murcia, cuyas principalescaracterísticas son las siguientes: HP Integrity SuperdomeSX2000 con 64 procesadores Intel Itanium2Dual-Core Montvale a 1.60Ghz y 1.5 TB de memoriacompartida.B. Perfiles de ejecuciónComo se ha dicho, FaCT++ divide los conceptosque forman parte de cada ontología en tres tipos:CD, noCD y non-primitive. El comportamiento delalgoritmo y el perfil de ejecución que se obtiene esdiferente según la composición de la ontología. Segúnel porcentaje de conceptos que hay de cada tipo seobtienen tres perfiles de ejecución:Conceptos CD: no requieren proceso de clasificación,la posición de cada concepto en el grafoJP2011-179

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IResultados de la ejecución del código secuencial de FaCT++Ontología T o ejec. (seg.) n o SUBs n o SATs SUBs/Concepto SATs/SUBSnomed-CT 446,61 15.028.965 1.608.815.309 51,62 107,048Thesaurus 31 410.923 50.590.753 5,13 123,115Pombe 951,19 42.196 10.268.799 1,12 243,36Nsennetsu 1.665,7 2.773 100.612.773 1,15 32,283de clasificación está Completamente Definida enla propia definición de la ontología. Su coste declasificación es muy bajo.Conceptos noCD: no necesitan realizar la faseSUB completa del algoritmo Tableaux, yaque construyendo una caché de conceptos puedenprescindir de la ejecución de la parte Top-Down/BottomUp y de la búsqueda Baader. Aúnasí su coste de clasificación es bastante alto.Conceptos non-primitive: son los más costososde clasificar ya que necesitan razonamiento Tableauxcompleto.C. Versión secuencialLas primeras pruebas realizadas consisten en ejecutarla versión secuencial de FaCT++ con distintasontologías, y así poder analizar sus tiempos de ejecución.Esto nos servirá para tener un punto de partidacon el cual poder comparar futuras versiones paralelas.En la tabla I se muestra un listado de la informaciónrecolectada de la ejecución del código secuencial,teniendo en cuenta los siguientes apartados:Tamaño de la ontología (número de conceptos).Tiempo medio de clasificación.Número de tests SUB y SAT realizados.Número medio de tests SUB necesarios para clasificarun concepto.Número de medio de tests SAT en que se expandeuna prueba SUB.D. Versión paralela en OpenMPEn este apartado se propone la implementación dela segunda opción considerada en el apartado III-A,correspondiente a la paralelización de todas las pruebasde inclusión que se realizan para cada conceptoen el proceso de razonamiento. Dicha implementaciónserá llevada a cabo mediante el lenguaje de programaciónOpenMP [8].Para realizar esta implementación se calculan enparalelo todas las pruebas de inclusión entre un conceptoy todos los nodos del grafo, cambiando el ordenen el que se recorre el grafo parcial de inclusión. Estoconlleva modificar la búsqueda Baader para que simplementese limite a comparar los resultados de laspruebas, en vez de tener que calcularlos. El cálculoparalelo de las pruebas se realiza mediante un bucle,que será fácilmente paralelizado en OpenMP mediantela directiva #pragma omp parallel for.Tras ejecutar este código en el supercomputadorTABLA IITiempos obtenidos por la versión paralela de FaCT++implementada en OpenMP para la ontologíaSnomed-CTVersión Tiempo Pérdida de(minutos) RendimientoSecuencial 7,45 -16 cores 511,73 68,7x32 cores 289,20 38,82x64 cores 181,26 24,33x128 cores 120,84 16,22xcon 16, 32, 64 y 128 cores, podemos comprobar queel mejor tiempo que se obtiene es de 120,84 minutospara la ontología Snomed-CT, frente a los 7,45minutos que emplea su versión secuencial (véase latabla II), es decir, unas 16,22 veces más lento. Esteresultado nos hace plantearnos si realmente se podríallegar a mejorar la versión secuencial con este enfoque,por lo que se ha realizado un estudio teórico alrespecto en el siguiente apartado.E. Estudio teórico de la paralelizaciónVamos a analizar el planteamiento anterior, paraasí comprobar teóricamente si paralelizando laspruebas de inclusión a nivel SUB se podría llegar amejorar a la versión secuencial de FaCT++. Paraello, primero estudiaremos que casos serían el mejory el peor en el algoritmo secuencial.Suponiendo constante el tiempo t de una prueba,que la ontología tiene n conceptos a clasificar, y quese tienen que realizar p(n) pruebas, el tiempo totalen realizar la clasificación secuencial total sería:T secuencial = p(n) ∗ tEl caso pésimo sería cuando cada concepto tieneque compararse con todos los nodos del grafo en esemomento, es decir, el concepto n tiene que realizarn − 1 pruebas, y la suma total de pruebas para nconceptos sería:T peor (n) =n ∗ (n − 1)2∗ tPara el mejor caso, tendríamos que buscar la formadonde cada concepto necesite realizar el mínimonúmero de test posibles para clasificarse. Debido acómo recorre el grafo en el algoritmo Baader, hayJP2011-180

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011que buscar la forma de expandir el grafo, compensandoentre anchura y profundidad.Los resultados para la ontolgía Snomed-CT son lossiguientes:T peor (n) = 16.532.438.203 ∗ t.T F aCT (n) = 15.028.965 ∗ tT mejor (n) = 4.716.324 ∗ t.Como vemos, en el caso óptimo se harían 4,7 millonesde pruebas SUB, en el pésimo 16.532,4 millones,mientras que la búsqueda Baader de FaCT++ realizapoco más de 15 millones de pruebas. Por esteestudio se puede afirmar que la versión secuencial deFaCT++ está muy cercana al caso óptimo, y que vaa ser muy difícil de mejorar mediante su paralelizaciónsin el uso de las heurísticas que, forzosamente,han de aplicarse secuencialmente.Por último, evaluamos cual sería el número de hilosóptimo que debería haber en una aplicación paralela.Para planificar estas pruebas en paralelo consideramosotro parámetro, h = número de hilos, con lo cualel tiempo de clasificación en paralelo será:T paralelo =(p(n) ∗ t)hSegún este planteamiento, para poder igualar eltiempo obtenido en el código secuencial habría queejecutar aproximadamente 1100 hilos en paralelo(T paralelo = T peor (n)/h = T F aCT (n)), claro está, enuna situación ideal donde no haya una sobrecargaproducida por la ejecución paralela de los hilos.V. Estado del arteActualmente y hasta donde nuestro conocimientoalcanza, los trabajos que evalúan posibles alternativassobre como paralelizar un razonador o su procesode clasificación se pueden clasificar en los siguientesenfoques:Ejecutar varias instancias de un razonador:• Procesamiento distribuido.• Particionar en trozos independientes una ontologíay ejecutar un razonador en paralelo concada trozo.Ejecutar una sola instancia de razonador:• Particionar en trozos dependientes una ontologíay ejecutar un sólo razonador, con su algoritmode clasificación en paralelo.• Clasificación en paralelo de reglas independientes.A. Procesamiento distribuidoEn este enfoque se propone ejecutar varias instanciasde un razonador coordinadas mediante un procesamientodistribuido. Existen varios artículos endonde se considera y evalúa esta opción [9, 10]. Enellos se consideran dos posibles opciones: particionamientode datos y particionamiento de reglas. Seafirma que una sola máquina no es suficiente paraprocesar tal cantidad de datos, y que por el contrariouna solución basada en un sistema distribuido es potencialmentemás escalable. Por último se considerantres enfoques actuales de razonamiento paralelo paradatos a escala web, como son los sistemas LarKC,MaRVIN y Reasoning-Hadoop.B. División de la ontología en trozos independientesEn [11] se proponen dos posibles soluciones: dividirontologías en módulos independientes, y por otrolado, rediseñar el proceso de razonamiento a bajo nivel.Se afirma que las ontologías no tienen comportamientomodular y que además los algoritmos de razonamientoestán altamente optimizados, lo que implicamuchas dependencias. Sin embargo considera quelos sistemas modernos, basados en multiprocesadoresde memoria compartida podrían ser una solución, yaque podrían paliar estas dependencias. Pero tambiénse afirma que para poder conseguir una mejora significativasería necesario disponer de un alto númerode operaciones que poder ejecutar en hilos paralelos,lo que obligaría a considerar también operaciones deterministas,las cuales implican un gran número dedependencias.C. Reglas independientesCiertos estudios se centran en analizar las reglasde una lógica de descripción y su comportamiento,intentando buscar aquellas que son independientesentre si.En [12] se indica que las tareas necesarias duranteel cálculo de una prueba de inclusión SUB no son independientes,pero que existen algunas operacionesno deterministas, como son las reglas de disyunción(o-lógico), o las reglas de restricciones de números(“como mucho”) que generan alternativas totalmenteindependientes. Presenta un enfoque para paralelizarel algoritmo de procesamiento de consistenciaABox del sistema RACE, donde usa una cola conprioridad para planificar la ejecución de tareas nodeterministas en distintos hilos (similar a TODO listde FaCT++). Este diseño está orientado a sistemasSMP, donde todos los hilos tienen acceso a una memoriaprincipal y el acceso a la cola de prioridad serealiza de forma sincronizada. Entre sus resultados,se acerca a una mejora 4x con 6-12 hilos en algunoscasos de prueba concretos. En un trabajo posterior[13], se añade una tercera regla no determinista:“qualified number restriction”.D. Particionamiento en trozos dependientes y clasificaciónen paraleloEn [14] se propone un nuevo algoritmo a nivel SUBque sustituye a la búsqueda Baader. Este divide laentrada en particiones dependientes que se procesanen paralelo y une posteriormente los resultados. Serealiza un estudio sobre parámetros influyentes en elalgoritmo, como son el número de hilos a ejecutaren paralelo, el número de conceptos por hilo y lasestrategias para particionar TBox. Su algoritmo seapoya en un preprocesamiento del TBox de entradacon el sistema RACER que prepara la entrada parasu algoritmo. Las pruebas realizadas en paralelo proponenun número muy bajo de hilos (la mayoría conJP2011-181

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20112 y 5).En [15] se continua el trabajo anterior y se especificanalgunos detalles, como es el uso de un únicoárbol global compartido para todos los hilos. Establecenúmero de hilos a 2 y número de conceptos porhilo a 5. Presenta una descripción completa de sunuevo algoritmo de clasificación que se basa en sustituira la búsqueda Baader y preprocesar el TBox deentrada para adaptarlo a sus necesidades. Este nuevoplanteamiento necesita métodos adicionales paragarantizar su completitud y consistencia. Al final seobtiene una mejora de casi 2x con poca sobrecarga.VI. Conclusiones y trabajo futuroEn este documento se ha implementado una versiónparalela del razonador semántico FaCT++. Obteniendocomo resultado unos tiempos de ejecuciónsuperiores a los de la versión secuencial. Esto es debidoa que naturaleza del problema hace que existanuna gran cantidad de dependencias de datos, lo quelo hace muy difícil que su paralelización sea eficiente.Además, FaCT++ hace uso de ciertas heurísticasque consiguen una reducción notoria de su tiempo deejecución, las cuales implican la ejecución secuencialdel código, y por tanto, no pueden ser paralelizadas.El presente trabajo supone una primera aproximacióna un campo sobre el cual no existe aún mucha bibliografía.Ninguna de las alternativas presentadas enel trabajo relacionado está lo suficientemente avanzadacomo para mostrar resultados relevantes. Además,tampoco están orientadas a paralelizar el proceso declasificación en sí mismo. Hay alguna aproximación,pero se basa en particionar la ontología, no en la paralelizacióndel algoritmo.Tras realizar un estudio teórico, estamos en disposiciónde afirmar que para alcanzar una mejoraconsiderable habría que lanzar una gran cantidad dehilos ejecutándose en paralelo. Esto nos lleva a pensaren la utilización de arquitecturas masivamenteparalelas, como es el caso de las GPUs, que están teniendogran acogida en la comunidad científica parala paralelización de diversas aplicaciones.Otra opción de paralelizar la aplicación FaCT++sería hacer un rediseño de la misma pensando ensu paralelización, volviéndola a implementar desdeel principio siguiendo esta filosofía.Harris, M., Hill, D., Issel-Tarver, L., Kasarskis,A., Lewis,S., Matese, J., Richardson, J., Ringwald, M., Rubin, G.,Sherlock, Gene ontology: tool for the unification of biology,Nature Genetics 25, 25–29, 2000.[2] Smith, B., Ashburner, M., Rosse, C.,Bard, J.,Bug, W.,Ceusters, W., Goldberg, L., Eilbeck, K., Ireland, A., Mungall,C., Leontis, N., Rocca-Serra, P., Ruttenberg, A., Theobo foundry: coordinated evolution of ontologies to supportbiomedical data integration, Nat Biotech 25 (1087–0156),1251–1255, 2007.[3] OWL Web Ontology Language, http://www.w3.org/TR/owl-ref (accessed, May, 31th, 2011).[4] J.T. Fernandez-Breis, L. Iannone, I. Palmisano, A. Rector,R. Stevens. Enriching the Gene Ontology via the Dissectionof Labels using the Ontology, NPre-Processor Language.EKAW 2010, Lecture Notes in Computer Science6317, 59–73, 2010.[5] Systematized Nomenclature of Medicine-Clinical Terms,http://www.ihtsdo.org/snomed-ct (accessed, May, 31th,2011).[6] D. Tsarkov and I. Horrocks, FaCT++ description logicreasoner: System description, Proc. of the Int. Joint Conf.on Automated Reasoning (IJCAR 2006), Lecture Notes inArtificial Intelligence vol. 4130, Springer (2006), pp. 292–297.[7] NCBO BioPortal, http://bioportal.bioontology.org(accessed, May, 31th, 2011).[8] The OpenMP Specification, http://www.openmp.org (accessed,May, 31th, 2011).[9] Li P., Zeng Y., Kotoulas S., Urbani J., and Zhong N., TheQuest for Parallel Reasoning on the Semantic Web, Proceedingsof the 2009 International Conference on ActiveMedia Technology, LNCS, 2009.[10] J. Urbani, Scalable and parallel reasoning in the SemanticWeb, The Semantic Web: Research and Applications,2010.[11] Bock, J. Parallel Computation Techniques for OntologyReasoning, The Semantic Web - ISWC 2008. Volume5318/2008 of Lecture Notes in Computer Science., SpringerBerlin / Heidelberg (2008) 901–906.[12] Liebig, T., Muller, F., Parallelizing Tableaux-Based DescriptionLogic Reasoning, On the Move to MeaningfulInternet Systems 2007: OTM 2007 Workshops.Volume4806/2007 of Lecture Notes in Computer Science., SpringerBerlin / Heielberg (2007) 1135–1114[13] T. Liebig, A. Steigmiller, O. Noppens, Scalability viaParallelization of OWL Reasoning, Proceedings of the 4thWorkshop on New Forms of Reasoning for the SemanticWeb: Scalable & Dynamic, Heraklion, Greece, May 2010.[14] M. Aslani and V. Haarslev, Towards parallel classifcationof TBoxes, Proceedings of the 2008 International Workshopon Description Logics (DL-2008), Dresden, Germany,May 13–16, (2008).[15] M. Aslani and V. Haarslev, TBox Classification in Parallel:Design and First Evaluation, Proc. 23rd Int. Workshopon Description Logics (DL2010), CEUR-WS 573, Waterloo,Canada, 2010.[16] I. Horrocks and U. Sattler, A Tableaux Decision Procedurefor SHOIQ, Proc. of IJ-CAI 2005, 2005.AgradecimientosEste trabajo ha sido financiado conjuntamente mediantela Fundación Séneca (Agencia Regional deCiencia y Tecnología, Región de Murcia) con la ayuda00001/CS/2007, y también al MEC y la ComisiónEuropea FEDER con las ayudas CSD2006-00046,TIN2009-14475-C04 y TIN2010-21388-C02-02. Tambiénqueremos agradecer la ayuda prestada por elCentro de Supercomputación de la Fundación ParqueCientífico de Murcia, donde hemos llevado a cabonuestras pruebas.Referencias[1] Ashburner, M., Ball, C., Blake, J., Botstein, D., Butler, H.,Cherry, J., Davis, A., Dolinski, K., Dwight, S., Eppig, J.,JP2011-182

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Arquitecturas del procesador, multiprocesadores y chipsmultinúcleoJP2011-183

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-184

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Real-Time Task Migration with DynamicPartitioning to Reduce Power ConsumptionJosé Luis March, Julio Sahuquillo, Salvador Petit, Houcine Hassan, and José Duato 1Abstract— Nowadays, a key design issue in embedded systemsis how to reduce the power consumption, since batteries have alimited energy budget. For this purpose, several techniques suchas Dynamic Voltage Scaling (DVS) or task migration can be used.DVS allows reducing power by selecting the optimal voltage supply,while task migration achieves this effect by balancing the workloadamong cores.This paper first analyzes the impact on energy due to task migrationin multicore embedded systems with DVS capability andusing the well-known Worst Fit (WF) partitioning heuristic. To reduceoverhead, migrations are only performed at the time that atask arrives to and/or leaves the system and, in such a case, onlyone migration is allowed.The huge potential on energy saving due to task migration, leadsus to propose a new dynamic partitioner, namely DP, that migratestasks in a more efficient way than typical partitioners. Unlike WF,the proposed algorithm examines which is the optimal target corebefore allowing a migration. Experimental results show that DP canimprove energy consumption in a factor up to 2.74 over the typicalWF algorithm.Keywords— Dynamic Partitioning, Task Migration, Power-Aware, Multi-Core, Multi-Thread, Real-Time, Embedded Systems.I. INTRODUCTIONEMBEDDED systems is an important segment ofthe microprocessor market since they are becomingubiquitous in our life. Systems like PDAs, smart phones,or automotive, provide an increasing number of functionalitiessuch as voice communication, navigation, or gaming,so that computational power is becoming more importantevery day. However, increasing computationalpower impacts on battery lifetime, so how to improvepower management is a major design concern.To deal with both computational and power managementrequirements, many systems use multicore processors.These processors allow a better power managementthan complex monolithic processors for the same levelof performance. Moreover, many manufacturers (Intel,IBM, Sun, etc.) deliver processors providing multithreadingcapabilities, that is, they provide support to run severalthreads simultaneously. Some examples of currentmultithreaded processors are Intel’s Montecito [1] andIBM Power 5 [2]. Also, leading manufacturers of the embeddedsector, like ARM, plan to include multithreadingtechnology in next-generation processors [3].A power management technique that is being implementedin most current microprocessors is Dynamic VoltageScaling (DVS) [4]. This technique allows the systemto improve its energy consumption by reducing thefrequency when the processor has a low level of activity(e.g., a mobile phone that is not actively used). In a multicoresystem, the DVS regulator can be shared amongseveral cores, also referred to as global, or private to each1 Department of Computer Engineering (DISCA), UniversitatPolitècnica de València, e-mails: jomarcab@gap.upv.es,{jsahuqui,spetit,husein,jduato}@disca.upv.es.core. In the former case, all cores are forced to workat the same speed but less regulators are required so itis a cheaper solution. The latter case enables more energysavings since each core frequency can be properlytuned to its applications requirements but it is more expensive[5].Energy consumption in systems with a global DVSregulator can be further improved by properly balancingthe workload [6], [7]. To this end, a partitioner module isin charge of distributing tasks according to a given algorithm(e.g., Worst Fit [8] or First Fit) that selects the targetcore to run the task. Unfortunately, the nature of someworkload mixes prevents the partitioner from achieving agood balancing. To deal with this drawback some systemsallow tasks to migrate (move their execution) fromone core to another, which results in energy saving improvements.This work presents a dynamic power-aware partitioner,namely DP, for a multicore multithreaded system that dynamically(at run-time) assigns tasks to cores and allowstask migration to improve energy consumption. Our focusis on tasks presenting real-time constraints, that is,tasks must end their execution before a given deadlineor run during several periods before leaving the system.The proposed partitioner readjusts possible dynamic imbalances(due to new arrivals or exits of tasks) by reallocatingtasks among cores. In this way, the workload canbe more fairly balanced, so system frequency -in manycases- can be reduced, thus enabling further energy consumptionimprovements. In addition, the number of migrationshas been limited in order to reduce overhead.Finally, as the aim of migration is to reduce imbalance,it makes sense to analyze the benefits of applying migrationwhen the workload changes. Three cases havebeen analyzed: both when a task arrives to and leaves thesystem, only when a task arrives to the system, and onlywhen a task leaves the system. Experimental results showthat enabling migration only on arrival in the classicalWF algorithm allows achieving energy improvements ina factor up to 2.18 with respect to the case where no migrationis allowed, while in the proposed DP algorithmthese improvements can be up to 2.74.The remaining of this paper is structured as follows.Section II discusses the related research on energy managementand task migration. Section III describes themodeled system, including the partitioner and the powerawarescheduler. Section IV presents the proposed workloadpartitioning algorithms. Section V analyzes experimentalresults of energy. Finally, Section VI presentssome concluding remarks.JP2011-185

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Modeled system.II. RELATED WORKScheduling in multiprocessor systems can be performedin two main ways depending on the task queuemanagement: global scheduling, where a single taskqueue is shared by all the processors, or partitionedscheduling, that uses a private task queue for each processor.The former allows task migrations since all the processorsshare the same task queue. In the latter case, thescheduling in each processor can be performed by applyingwell-established uniprocessor theory algorithms suchas EDF (Earliest Deadline First) or RMS (Rate MonotonicScheduling). An example of global scheduling forsporadic tasks can be found in [9].In the partitioned scheduling case, research can focuseither on the partitioner or the scheduler. Acting inthe partitioner, recent works have addressed the energyawaretask allocation problem [10], [11], [8]. For instance,Wei et al. [10] reduce energy consumption byexploiting parallelism of multimedia tasks on a multicoreplatform combining DVS with switching-off cores. Aydinet al. [11] present a new algorithm that reserves asubset of processors for the execution of tasks with utilizationnot exceeding a threshold. Unlike our work, noneof these techniques use task migration among cores.Some proposals have been dealing with task migration.Brandenburg et al. [12] evaluate some schedulingalgorithms (both global and partitioned) in terms ofscalability, although no power consumption were investigated.In [13] Zheng divides tasks into fixed and migrationtasks, allocating each of the latter to two cores, sothey can migrate from one to another. Unlike our work, inthis paper there is no consideration about dynamic workloadchanges (tasks arriving to and leaving the system),instead, all tasks are assumed to arrive at the same instant,so migrations can be scheduled off-line. Seo etal. [5] present a dynamic repartitioning algorithm withmigrations to balance the workload and reduce consumption.In [14] Brião et al. analyze how soft tasks migrationaffects NoC-based MPSoCs in terms of deadline missesand energy consumption. These two latter works focuson non-threaded architectures.Regarding the scheduler, in [15] El-Haj-Mahmoud etal. virtualize a simultaneous multithreaded (SMT) processorinto multiple single-threaded superscalar processorswith the aim of combining high performance withreal-time formalism. In order to improve real-time taskspredictability, Cazorla et al. [16] devise an interactiontechnique between the Operating System (OP) and anSMT processor. Notice that these works do not tackleenergy consumption.III. SYSTEM MODELFigure 1 shows a block diagram of the modeled system.When a task reaches the system, a partitioner moduleallocates it into a task queue associated to a core,which contains the tasks that are ready for executionin that core. These task queues are components of thepower-aware scheduler that communicates with a DVSregulator, in charge of adjusting the working frequencyof the cores in order to satisfy the workload requirements.To focus our research, experiments considered a two-coreprocessor implementing three hardware threads each.Processor cores implement the coarse-grain multithreadingparadigm that switches the running threadwhen a long latency event occurs (i.e., a main memoryaccess). Thus, the running thread issues instructions toexecute while the other threads access memory, so overlappingtheir execution. In the modeled system, the issueslots are always assigned to the thread executing the taskwith the highest real-time priority. If this thread stalls dueto a long latency memory event, then the issue slots aretemporarily reassigned until the event is resolved.A. Real-Time Task BehaviorThe system workload executes periodic hard real-timetasks. There is no task dependency and each task has itsown period of computation. A task can be launched to executeat the beginning of each active period, and it mustend its execution before reaching its deadline (hard realtime).The end of the period and the deadline of a task areconsidered to be the same for a more tractable schedulingprocess. There are also some periods where tasks do notexecute since they are not active (i.e., inactive periods).In short, a task arrives to the system, executes severaltimes repeatedly, leaves the system, remains out of thesystem for some periods, and then it enters the systemJP2011-186

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011again. This sequence of consecutive active and inactiveperiods allows to model real systems mode changes.Besides its period and deadline, a task is also characterizedby its Worst Case Execution Time (WCET).This parameter is used to obtain the task utilization:U = W CET . Different partitioning algorithms mayP erioduse this value in the process of allocating incoming tasksto a core, guaranteeing schedulability.B. Power-Aware SchedulerOnce a task is allocated to a core, it is inserted intothe task queue of that core, where incoming tasks are orderedaccording to the EDF policy [17], which priorizesthe tasks with the closest deadlines. Thus, the three taskswith the closest deadlines will be always mapped into thethree hardware threads implemented in each core.The scheduler is also in charge of calculating the targetspeed of each core according to the tasks’s requirements.In this sense, in order to minimize power consumption,each core will choose the minimum frequency that fulfillsthe temporal contraints of its task set. This information issent to the DVS regulator that selects the maximum frequency/voltagelevel among the requested by the cores.The target frequency is recalculated to check if it hasto be updated, but only when the workload changes, thatis, when a task arrives to and/or leaves the system. In theformer case, a higher speed can be required because theworkload increases. In the latter case, it could happen thata lower frequency could satisfy the deadline requirementsof the remaining tasks.Different speed values are considered for the powerawarescheduler, based on the frequency levels of a PentiumM [18] that are shown in Table I. The 5L configurationallows the system to work at any of these five levels,whereas the 3L mode permits running tasks at thehighest, the lowest and the intermediate (300 Mhz) frequency.Futhermore, the overhead of changing the frequency/voltagelevel has been modeled according to thevoltage transition rate in the Pentium M processor, that isapproximately 1mv/1µs [19].IV. PARTITIONING HEURISTICS WITH TASKMIGRATIONThere are several partitioning heuristics that can beused to distribute tasks among cores as they arrive to thesystem. The Worst Fit (WF) partitioning heuristic is consideredone of the best choices in order to balance theworkload, thus improving energy savings [8]. WF balancesworkload by assigning the incoming task to theleast loaded core. If more than one task arrives to the systemat the same time, it arranges the incoming tasks bydecreasing utilization order and assigns them to the coresbeginning with the task with highest utilization. This algorithmwas initially used in partitioned scheduling, thus,TABLE IENERGY (E) USED PER FREQUENCY (F).F[MHz] 500 400 300 200 100E[pJ/cycle] 450 349.2 261.5 186.3 123.8Fig. 2. Task periods and migrations.it does not support task migration among cores by design.Therefore, once WF has assigned an incoming task to agiven core, the task remains in that core until it leaves thesystem (i.e., it has executed all its active periods).A. Extending Worst Fit to Support Task MigrationFigure 2 shows an example of how task migrationcould improve workload balancing. At the beginning ofthe execution (time t0), task 0 and task 1 are the onlytasks assigned to core 0 and core 1, respectively. Task 0presents an utilization around 25% (i.e., its WCET occupiesa quarter of its period), while the utilization of task1 is around 33%. At point t2, task 2, whose utilizationis around 66%, arrives to the system, and the WF algorithmassign it to core 0 (since it is the least loaded core).Consequently, the system would exhibit a high workloadimbalance since the global utilization of core 0 and core1 would be 91% and 33%, respectively. To solve this imbalance,task 0 can be migrated to core 1, providing abetter balance (66% in core 0 versus 58% in core 1).The system can become unbalanced when the workloadchanges, that is, when a task arrives to or leaves thesystem. Thus, migration policies should apply in thesepoints in order to be effective. This leads to three variantsof the WF policy: W F in−out , W F in , and W F out .W F in−out allows migration when a task arrives to orleaves the system, W F in only when a new task arrives,and W F out only when a task leaves the system. To avoidperforming too much migrations, which could lead to excessiveoverhead, we limit the number of migrations performedwhen a task arrives to or leaves the system to onlyone.Figure 3 shows the Migration Attempt (MA) algorithm.This routine calculates the imbalance by subtractingthe utilization of the least loaded core from the utilizationof the most loaded one. This result is dividedby two (since there are two cores) to obtain a theoreticalutilization value that represents the amount of work thatshould migrate to achieve a perfect balancing. Then, itsearches the task in the most loaded core whose utilizationis the closest to this one. Notice that it could happenthat by migrating that task the workload balancing wouldnot improve (e.g., consider a situation where only onetask is assigned to the most loaded core). Therefore, thealgorithm performs the migration only if it improves theworkload balancing.JP2011-187

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111: imbalance ← max core utilization − min core utilization2: target utilization ← imbalance/23: minimum difference ← MAX V ALUE4: for all task in most loaded core do5: if |U task − target utilization| < minimum difference then6: minimum difference ← |U task − target utilization|7: candidate ← task8: end if9: end for10: new max core utilization ← max core utilization − U candidate11: new min core utilization ← min core utilization + U candidate12: new imbalance ← |new max core utilization − new min core utilization|13: if new imbalance < imbalance then14: migrate(candidate)15: end ifFig. 3. Migration Attempt algorithm.B. Dynamic PartitionerThis subsection presents the proposed Dynamic Partitioner(DP). As done by the WF algorithm, DP also arrangesthe tasks arriving to the system by decreasing utilizationorder. However, before assigning any incomingtask to a given core, DP checks how the workload balancingwould become if the incoming task was assignedto the first core. Then, it also calculates the effect ofperforming a migration attempt (as shown in Figure 3).These testings are performed for each core in the system.Finally, the core assignment that provides the best overallbalance is applied. Two versions of DP are considered:DP in and DP in−out . DP in refers to the described DP algorithm,where a migration can be performed only whena task arrives to the system, while DP in−out also performsa migration attempt when a task leaves the system.Figure 4 depicts an example where the DP in heuristicimproves the behavior of W F in . The latter allocates theincoming task to core 0, and then performs a migrationattempt, but in this case, there is not any possible migra-Fig. 4. W F in vs DP in .tion enabling a better workload balancing. Thus, the finalimbalance becomes 20% (i.e., 90% − 70%). In contrast,when DP in is applied, it also checks the result of allocatingthe new task to core 1 (DP in B arrow) and thenconsidering one migration. In this case, the migrationenables a better balance since both cores remain equallyloaded with 80% of utilization, which will be the distributionselected by DP in .To sum up, the main difference between W F in andDP in is that the former selects only one core and performsa migration attempt, whereas the proposed heuristicchecks different cores, and choses the best option interms of workload balance.V. EXPERIMENTAL RESULTSExperimental evaluation has been conducted by extendingthe Multi2Sim simulation framework [20], tomodel the system described in Section III. As stated before,experiments considered a two-core processor implementingthree hardware threads each. Internal corefeatures have been modeled like an ARM11 MPCorebased processor, but modified to work as a coarse-grainmultithreaded processor with in-order execution, twoinstructionissue width, and a 100-cycle memory latency.Benchmarks from the WCET analysis project [21]were used to prepare real-time workload mixes. Thesemixes have been designed taking into account aspectssuch as task utilization, number of repetitions (task periodicity),and the sequence of active and inactive periods.The global system utilization varies in a single executionfrom 35% to 95%, in order to test the algorithms behavioracross a wide range of situations. In addition, all resultsare presented and analyzed for a system implementingthree and five voltage levels.A. Impact of Applying Migrations at Different Points ofTimeThis section analyzes the best points of time to carryout migrations focusing on the standard WF algorithm(no migration is supported) and its variants supportingmigration (W F in−out , W F in , W F out ). Figure 5 showsthe relative energy consumption compared to the energyconsumed by the system working always at theJP2011-188

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) 5L(a) 5L(b) 3LFig. 5. Worst Fit variants comparison for different DVS levels.(b) 3LFig. 6. WF versus DP for different DVS levels.maximum speed for diverse benchmark mixes and DVSconfigurations.As observed, migration can provide huge energy savingswith respect to no migration (WF) regardless whenmigration is applied. For instance, in the 5-level systemwith task migration mixes 2 and 3 improve their energyconsumption in a factor up to 1.33 and 2.18, respectively,when compared with their execution in the same systemwithout migrations. This trend is also followed, althoughto a lesser extent, in the 3-level system.Comparing the three WF versions with task migration,it can be observed that if migration can apply only eachtime a new task arrives instead of when a task terminates,then much higher energy savings can be achieved. Themain reason is that the inter-arrival time standard deviationis higher than that of the inter-leaving time, sinceseveral tasks reach the system at the same time. Interarrivalstandard deviation values of the mixes are 24.48,43.98, and 14.65 Mcycles for mix 1, mix 2, and mix 3,respectively. On the other hand, the inter-leaving timeis, on average, 22.50, 36.40, and 12.32 Mcycles. Finally,W F in−out offers scarce benefits over W F in since it onlyadds a low number of extra migrations.Notice that if the system implements more DVS frequencylevels (5 levels in the figure), then more energysavings can be obtained since the system can select a frequencycloser to the optimal estimated by the scheduler.However, despite this fact, an interesting observation isthat energy benefits due to migration in the 3-level systemcan reach or even surpass the benefits of having the 5-level system without migrations. For example, the energyconsumption of W F out for mix 3 in the 3-level system isaround 11% of the consumption of the baseline, whereasthe same value of WF in the 5-level system is 17%.B. Comparing DP versus WF variantsThis section analyzes the energy improvements oftwo variants of the proposed DP algorithm (DP in andDP in−out ) over the WF algorithm. For comparison pur-poses the best variant of the WF (W F in−out ) with migrationhas been also included in the plots. Figure 6 showsthe results.Results show that, regardless the mix and systemlevel,both variants of DP always consume less powerthan W F in−out . DP in−out achieves, for mixes 2 and3, energy improvements over WF in a factor up to 2.74and 1.56, respectively. Moreover, for mix 1, whereW F in−out is only able to find scarce benefits over WF,the proposed DP improves the energy consumption ofWF around 1.51.For a better understanding of the algorithms behavior,we define the migration rate metric as the number of migrationsperformed by the algorithm divided by the numberof times that the migration algorithm is executed. Forinstance, regarding the in variant of the WF and DP algorithms,the migration rates of W F in are 62%, 54%,and 45% for mix 1, mix 2, and mix 3, respectively; whilefor DP in the corresponding values are 76%, 68%, and73%. This means that the proposal performs migrationsin some cases where the WF is not able to find any candidateto migrate at all.VI. CONCLUSIONSWorkload balancing has been already proved to be anefficient power technique in multicore systems. Unfortunately,unexpected workload imbalances can rise at runtimeprovided that the workload is dynamically changingsince new tasks arrive to or leave the system. To palliatethis situation this paper has analyzed the impact on energyconsumption of task migration combined with workloadbalancing.To prevent excessive overhead, task migration has beenstrategically applied at three different execution timeswhere the workload changes (at task arrival, at task termination,and in both cases). Results with respect tothe WF algorithm showed that applying migration atarrival time can save results in a factor up to around2.18. This results can be slightly improved if migrationJP2011-189

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011is also applied when tasks terminate.Due to the potential of migration, this paper has proposedthe DP algorithm, which achieves much better energyimprovements than classical partitioning algorithmslike WF. The proposal improves energy consumption ina factor of 1.51 in some workloads where WF with migrationsprovides scarce benefits, and energy can be improvedin a factor up to 2.74 in the analyzed workloads.Experimental results also showed that migration canprovide energy consumption improvements with respectto a more complex system with a higher number of frequency/voltagelevels. A final remark is that achievinga better workload balancing by allowing task migrationsnot only results in energy savings, but also allows a widerset of tasks to be scheduled.ACKNOWLEDGMENTSThis work was supported by Spanish CICYT underGrant TIN2009-14475-C04-01, and by Consolider-Ingenio under Grant CSD2006-00046.REFERENCES[1] C. McNairy and R. Bhatia, “Montecito: A Dual-Core, Dual-Thread Itanium Processor,” IEEE Micro, vol. 25, no. 2, pp. 10–20,2005.[2] R. Kalla, B. Sinharoy, and J.M. Tendler, “IBM Power5 Chip: ADual-Core Multithreaded Processor,” IEEE Micro, vol. 24, no. 2,pp. 40–47, 2004.[3] Agam Shah, Arm plans to add multithreading tochip design, ITworld, 2010, [Online]. Available:http://www.itworld.com/hardware/122383/arm-plans-addmultithreading-chip-design.[4] C. Hung, J. Chen, and T. Kuo, “Energy-Efficient Real-Time TaskScheduling for a DVS System with a Non-DVS Processing Element,”in Proceedings of the 27th Real-Time Systems Symposium,Rio de Janeiro, Brazil, 5-8 December 2006, pp. 303–312, IEEEComputer Society.[5] E. Seo, J. Jeong, S. Park, and J. Lee, “Energy Efficient Schedulingof Real-Time Tasks on Multicore Processors,” IEEE Transactionson Parallel and Distributed Systems, vol. 19, no. 11, pp. 1540–1552, 2008.[6] J. Donald and M. Martonosi, “Techniques for Multicore ThermalManagement: Classification and New Exploration,” in Proceedingsof the 33rd Annual International Symposium on ComputerArchitecture, Boston, MA, USA, 17-21 June 2006, pp. 78–88,IEEE Computer Society.[7] J.L. March, J. Sahuquillo, H. Hassan, S. Petit, and J. Duato, “ANew Energy-Aware Dynamic Task Set Partitioning Algorithm forSoft and Hard Embedded Real-Time Systems,” To be publishedon The Computer Journal, 2011.[8] T. A. AlEnawy and H. Aydin, “Energy-Aware Task Allocationfor Rate Monotonic Scheduling,” in Proceedings of the 11th RealTime on Embedded Technology and Applications Symposium, SanFrancisco, CA, USA, 7-10 March 2005, pp. 213–223, IEEE ComputerSociety.[9] S. Kato and N. Yamasaki, “Global EDF-based Scheduling withEfficient Priority Promotion,” in Proceedings of the 14th InternationalConference on Embedded and Real-Time Computing Systemsand Applications, Kaohisung, Taiwan, 25-27 August 2008,pp. 197–206, IEEE Computer Society.[10] Y. Wei, C. Yang, T. Kuo, and S. Hung, “Energy-Efficient Real-Time Scheduling of Multimedia Tasks on Multi-Core Processors,”in Proceedings of the 25th Symposium on Applied Computing,Sierre, Switzerland, 22-26 March 2010, pp. 258–262, ACM.[11] H. Aydin and Q. Yang, “Energy-Aware Partitioning for MultiprocessorReal-Time Systems,” in Proceedings of the 17th InternationalParallel and Distributed Processing Symposium, Workshopon Parallel and Distributed Real-Time Systems, Nice, France, 22-26 April 2003, p. 113, IEEE Computer Society.[12] B. B. Brandenburg, J. M. Calandrino, and J. H. Anderson, “Onthe Scalability of Real-Time Scheduling Algorithms on MulticorePlatforms: A Case Study,” in Proceedings of the 29th Real-TimeSystems Symposium, Barcelona, Spain, 30 November - 3 December2008, pp. 157–169, IEEE Computer Society.[13] Liu Zheng, “A Task Migration Constrained Energy-EfficientScheduling Algorithm for Multiprocessor Real-time Systems,” inProceedings of the International Conference on Wireless Communications,Networking and Mobile Computing, Shanghai, China,21-25 September 2007, pp. 3055–3058, IEEE Computer Society.[14] E. Brião, D. Barcelos, F. Wronski, and F. R. Wagner, “Impact ofTask Migration in NoC-based MPSoCs for Soft Real-time Applications,”in Proceedings of the International Conference on VLSI,Atlanta, GA, USA, 15-17 October 2007, pp. 296–299, IEEE ComputerSociety.[15] A. El-Haj-Mahmoud, A.AL-Zawawi, A. Anantaraman, andE. Rotenberg, “Virtual Multiprocessor: An Analyzable, High-Performance Architecture for Real-Time Computing,” in Proceedingsof the International Conference on Compilers, Architecturesand Synthesis for Embedded Systems, San Francisco, CA,USA, 24-27 September 2005, pp. 213–224, ACM Press.[16] F. Cazorla, P. Knijnenburg, R. Sakellariou, E. Fernández,A. Ramirez, and M. Valero, “Predictable Performance in SMTProcessors: Synergy between the OS and SMTs,” IEEE Transactionson Computers, vol. 55, no. 7, pp. 785–799, 2006.[17] T.P. Baker, “An Analysis of EDF schedulability on a multiprocessor,”IEEE Transactions on Parallel and Distributed Systems, vol.16, no. 8, pp. 760–768, 2005.[18] R. Watanabe, M. Kondo, M. Imai, H. Nakamura, and T. Nanya,“Task Scheduling under Performance Constraints for Reducingthe Energy Consumption of the GALS Multi-Processor SoC,” inProceedings of the Design Automation and Test in Europe, Nice,France, 16-20 April 2007, pp. 797–802, ACM.[19] Q. Wu, M. Martonosi, D. W. Clark, V. J. Reddi, D. Connors,Y. Wu, J. Lee, and D. Brooks, “A Dynamic Compilation Frameworkfor Controlling Microprocessor Energy and Performance,”in Proceedings of the 38th Annual IEEE/ACM International Symposiumon Microarchitecture, Barcelona, Spain, 12-16 November2005, pp. 271–282, IEEE Computer Society.[20] R. Ubal, J. Sahuquillo, S. Petit, and P. López, “Multi2Sim: ASimulation Framework to Evaluate Multicore-Multithreaded Processors,”in Proceedings of the 19th International Symposium onComputer Architecture and High Performance Computing, Gramado,RS, Brazil, 24-27 October 2007, pp. 62–68, IEEE ComputerSociety.[21] Malardalen Real-Time Research Center, Vasteras, Sweden,WCET Analysis Project. WCET Benchmark Programs, 2006, [Online].Available: http://www.mrtc.mdh.se/projects/wcet/.JP2011-190

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Unified Locality-sensitive Signatures forTransactional MemoryR. Quislant, E. Gutierrez, O. Plata and E.L. Zapata 1Abstract— Transactional Memory (TM) systemsmust record the memory locations read and writtenby concurrent transactions in order to detect conflicts.Some TM implementations use signatures forthis purpose, which summarize read and write sets inbounded hardware at the cost of false positives due toaddress aliasing. Signatures are usually implementedas two separate (one for reads and another for writes)per-thread Bloom filters.It is known that the false positive rate increaseswith the size of the transactions, and this have astrong negative impact in the performance of theirconcurrent execution. In a previous work, authorsdeveloped a technique with the aim of reducing theprobability of false positives by exploiting spatial locality.In this paper we propose a new technique basedon joining the two Bloom filters into a single one andpartially sharing the hash function mappings for readsand writes. This unification technique is combinedwith the locality-sensitive one and it is proved thatthe false positive rate is further reduced.This paper proves that unified locality-sensitive signaturesimprove the execution performance of largeconcurrent transactions in most tested codes comparedto separate signatures, without increasing significantlythe required hardware area and with a smallincrement of power consumption.Keywords— Hardware transactional memory, signatures,Bloom filters, memory localityI. IntroductionTRANSACTIONAL Memory (TM) [1], [2]emerges as an alternative to the conventionalmultithreaded programming to ease the writing ofconcurrent programs. TM introduces the concept oftransaction that allows semantics to be separatedfrom implementation. A transaction is a block ofcomputations that appears to be executed withatomicity and isolation. Thus, transactions replacea pessimistic lock-based model by an optimistic oneand solve the abstraction and composition problems.TM systems execute transactions in parallel, committingnon-conflicting ones. A conflict occurs whena memory location is accessed by several concurrenttransactions and at least one access is a write. Therefore,TM systems must record the memory locationsread and written by concurrent transactions in orderto detect conflicts. Some TM implementations usesignatures for this purpose, which summarize readand write sets in bounded hardware at the cost offalse positives due to address aliasing (different memorylocations have the same representation in thesignatures). Signatures are usually implemented astwo separate (one for reads and another for writes)per-thread Bloom filters [3]. Examples of systemsthat use signatures are BulkSC [4], LogTM-SE [5],1 Dept. of Computer Architecture, University of Málaga, e-mail: {quislant, eladio, oplata, zapata}@uma.esSigTM [6], FlexTM [7], and STMlite [8].It is known that the false positive rate increaseswith the size of the transactions, and this have astrong negative impact in the performance of theirconcurrent execution. In a previous work [9], authorsdeveloped a technique with the aim of reducing theprobability of false positives. This technique definesnew hash function mappings so that nearby locatedaddresses share some bits in the Bloom filters, that is,it exploits spatial locality. In this paper we propose anew technique based on joining the two Bloom filtersinto a single one and partially sharing the hash functionmappings for reads and writes without addingsignificant hardware complexity. The rationale behindthis technique is the uneven cardinality thattransactional read/write sets exhibit, where read setsare usually larger than write sets. As a result, thesignature for reads populates much more than theone for writes and, consequently, the false positiverate for the read signature may be high while, at thesame time, the write filter has still a low occupation,with negligible false positive rate. When sharing thefilter, both the read and the write false positive ratescan be equalized. This unification technique is combinedwith the locality-sensitive one and it is provedthat the false positive rate is further reduced.The proposed unified locality-sensitive signatureshave been implemented in the Wisconsin GEMSLogTM-SE simulator [10], in order to evaluate theirperformance, and in CACTI [11] in order to evaluatethe hardware area and energy requirements. Experimentalresults show that the proposed approach isable to reduce the false positive rate and improve theexecution performance in most of the tested codes,without increasing the required hardware area in anoticeable amount and slightly increasing the powerconsumption.The rest of the paper is organized as follows. Innext section we present a background on signatures,describing how they are usually designed and implemented.A brief review of the related work is discussed.In Section III we introduce our proposedunified signature design, discussing its basics, howthey are implemented, and a comparison with theseparate signature design. Section IV presents areaand energy requirements. Section V shows an analysisof our proposed signatures and determines falsepositive rates in different contexts. Next, Section VIpresents the implementation of unified signatures onthe GEMS simulator, and discusses how our novelsignature design may improve the execution performancein several cases.cludes the paper.Finally, Section VII con-JP2011-191

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Read SetSignatureAddress...h0 h1 hk-1Address...h0 h1 hk-1Unified SignatureRS Address... h0 hs-1WS Address... hs h's hk-1 h'k-10 1 1 0 0 1 1 0 ... 0 1 0 10 2 m /k...k single-ported SRAMs of 2 m /k bits0 1 0 1 ... 0 1 0 1 0 1 1 0 ... 0 1 0 10 2 m+1 /kWrite SetSignatureAddress...h'0 h'1 h'k-1Address...h'0 h'1 h'k-1RS Addressh0...hs-1hsWS Addressh's...hk-1h'k-10 1 1 0 0 1 1 0 ... 0 1 0 10 2 m /k...k single-ported SRAMs of 2 m /k bits...s single-portedSRAMs of 2 m+1 /k bits...k-s double-portedSRAMs of 2 m+1 /k bitsFig. 1. Parallel Separate Signatures. Design (left) and implementation(right)Fig. 2. Parallel Unified Signatures. Design (up) and implementation(down).II. Background and Related WorkIn the context of TM, each concurrent thread usesits signatures to record all the memory locations issuedwhen executing inside a transaction. These locationsare sorted out into a read set (RS) and awrite set (WS). Thus, each thread needs a pair ofprivate signatures. As they are used for conflict detectionamongst concurrent transactions, signaturesdo not tolerate false negatives (undetected true conflicts)but may assume a limited amount of false positives(false conflicts). On the other hand, the RS andWS sizes are unknown in advance, therefore, signaturesshould not limit the number of addresses to betracked. In addition, test and insertion of an addressshould be fast operations.Fulfilling the requirements above, Ceze et al. [12]proposed a signature implementation with perthreadBloom filters. These filters were devised totest whether an element is a member of a set in atime and space-efficient way. The Bloom filter comprisesa bit array and k different hash functions thatmap elements into k randomly distributed bits of thearray. At first, all the array bits are set to 0. Insertingan element into the Bloom filter consists insetting to 1 the k bits given by the hash functions.Test for membership consists in checking that thosek bits are asserted.Bloom filters are also known as true or regularBloom filters. Sanchez et al. [13] proposed theparallel Bloom filter as an alternative hardwareefficientimplementation of regular Bloom filters.Whereas the regular filter is implemented as a k-ported SRAM, the parallel one consists of k 1-portedSRAMs, yielding the same or better false positivesrate. The same work concludes that Bloom filtersshould include H3 class hash functions [14], insteadof bit-selection hash functions [15], since they arecloser to random distribution. However, H3 hashingsare hardware expensive and need an XOR treeper hash bit.An alternative hardware-efficient implementationof hash functions, Page-Block-XOR hashing (PBX),has been proposed in [16]. They use the concept ofentropy to find input bits to the hash functions withhigh randomness, allowing to reduce the hardwarecomplexity of those functions. Notary also proposesa technique to reduce the number of asserted bitsin the signature, based on segregating addresses intoprivate and shared sets. Then, only the shared addressesare recorded in the signature. This solutionrequires support at the compiler, runtime/libraryand operating system levels. In addition, the programmermust define which objects are private orshared.Recently, Choi et al. [17] proposed adaptive grainsignatures, that keep the history of transactionaborts and dynamically changes the input bit rangeto the hash functions based on the abort history. Theaim of this design is to reduce the number of falsepositives that harm the execution performance.III. Unified Signature DesignParallel Bloom filters have been proved to yieldsimilar or better performance than regular ones andthey require less hardware [13] [9]. Consequently,regular implementation will not be taken into accountin this paper.Parallel Bloom filters comprise k arrays of 2 m /kbits, each of which is only indexed by its own hashfunction. Figure 1 shows the design and implementationof parallel Bloom signatures. They consist oftwo separate parallel filters to record the read setand write set addresses. Parallel filters can be implementedas single-ported SRAMs, thus saving inhardware area with respect to regular filters whichare implemented as multi-ported SRAMs.The unified counterpart for the parallel separatesignature is depicted in Figure 2. In this case, thebit array is also partitioned into k smaller arrays but(2 m+1 /k)-bit length. Each array is indexed by twohash functions, one for the read set, h [0,k−1] , and theother one for the write set, h ′ [0,k−1] . Consequently,parallel unified filters need 2-ported SRAMs insteadof single-ported ones taking about twice the area ofparallel separate filters. To alleviate this problem,s SRAMs can be made single-ported. This way, anaddress inserted as a read address is also inserted asa write and vice-versa.The motivation behind unified signatures comefrom Table I which shows the percentage of addressesthat have been both read and written inside transactionsfor each benchmark (a description of the simulationenvironment can be found in Section VI-A)with respect to the total number of addresses (with-JP2011-192

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IPercentage of addresses that have been both readand written inside transactions.Bench % Bench %Bayes 51.0 Labyrinth 15.3Genome 16.0 SSCA2 25.0Intruder 7.1 Vacation 8.4Kmeans 48.6 Yada 45.0TABLE IIArea (mm 2 ) and dynamic energy per access (nJ)requirements of parallel separate and parallelunified signatures. 32nm technology. k = 4.AreaEnergyFilter size (2 m ) 4Kbit 16Kbit 4Kbit 16KbitSeparate 0.0084 0.0292 0.0020 0.0047Unified s = 0 0.0191 0.0640 0.0030 0.0081Unified s = 3 0.0098 0.0331 0.0026 0.0068out repetition). About 50% of locations are bothread and written for Bayes, Kmeans and Yada. Overall,about 30% of total locations addressed by eachbenchmark has been both read and written.In order to work out the value of s a trade off betweenhardware requirements and signature performancehas to be carried out. On the one hand, if sis set to k, the unified signature implements k singleportedSRAMs. Thus, such a signature requires thesame hardware than the parallel separate signaturebut it is unable to discriminate between read andwritten addresses and it could degrade the performance.On the other hand, if s is set to 0, the unifiedsignature implements k double-ported SRAMsincreasing the hardware requirements but maximizingthe probabilities of discrimination between readand written addresses. Section VI-B explores everypossible scenario.Finally, hash functions are implemented as H3XOR functions [14] that only comprise a set of XORgate trees per function. XOR gate trees do not requiresignificant area and, moreover, they can be replacedby a single line of XOR gates by using PBXhashing [16].IV. Hardware RequirementsTable II compares the area required by unified andseparate signatures for several filter sizes. “Filtersize” row is the size of one set filter, i.e. 4Kbit meanstwo filters of 4Kbit (for RS and WS) for separate signaturesand one filter of 8Kbit for unified ones. Weused CACTI 6.5 [18] to model the SRAMs using the32nm technology node. Parallel separate signaturescomprise eight single-ported SRAMs (4 for the RSand 4 for the WS) as k = 4, while parallel unifieds = 0 signatures have four double-ported SRAMs.Separate read/write ports are used. Parallel unifieds = 3 signatures have three single-ported SRAMsand only one double-ported SRAM. Ports are dualendedwhich means that two lines are required perbitline.Table II shows that parallel separate signaturesyield the best area and energy numbers. Regardingthe parallel unified s = 0 signature, it is about twicelarger than the parallel separate signature due to itsdouble-ported SRAMs. The parallel unified s = 3configuration, is the closest to the parallel separateone in terms of area. It is only a 13% larger becauseof the double-ported SRAM. However, parallelunified s = 3 signatures outperforms parallel separateones as seen in Section VI-C. Regarding energy,Table II shows a 30% increment in dynamic energyconsumption for parallel unified s = 3 signatures.Concerning the hashing logic area, Sanchez etal. [13] worked out one-fifth of the SRAM area for 4XOR hash functions. This can be halved using PBXhashing [16] without impact in the performance.V. False Positive AnalysisLet A be a sequence of addresses, to be inserted ina single Bloom filter of 2 m bits with k hash functions,whose cardinality is n = Card(A). The false positiveprobability is commonly calculated [13] [9] as:(p FP (m, k, n) = 1 − ( ) )1 − 1 nk k2 . (1)mEq. (1) can be adapted to the locality-sensitivesignature scheme of [9] by considering two supplementaryparameters: f which is the probability of anaddress to be local, that is, near to another one in thesequence, and b which measures the average numberof bits asserted by a local reference with respect to itsclosest neighbor in the sequence. The value of f willdepend on the spatial locality of the program. Thevalue of b can be estimated as b = 1 2 +2· 14 +3· 18 +4· 18for the locality-sensitive signatures defined in [9] withk = 4 hash functions. For such signatures the falsepositive probability is given now by:(p FP LOC(m, k, n, f) = 1 − ( ) )1 − 1 n(1−f)k+nfb k2 .m(2)First, consider separate filters, where the read andwrite sets are stored separately, in order to comparetheir false positive rates to those of the unifiedfilter. Let us define p R = Card(R−R∩W ) andCard(W −R∩W )Card(R∪W )Card(R∪W )p W = as the probability of an addressof the sequence being only read or written, respectively,as a function of the cardinality of the read (R)and write (W) sets. Consequently, n = Card(R∪W ).Also an address in the sequence can be both readand written with probability p RW = Card(R∩W )Card(R∪W ) .Therefore, the false positive probability in each filter,assuming locality-sensitive signatures, can be expressedas:p readFP LOC=p writeFP LOC=(1 − ( ) )1 − 1 n(pR+p RW )¯kk2 ,m(1 − ( ) ) (3)1 − 1 n(pW +p RW )¯kk2 , mwhere ¯k = (1 − f)k + fb ≤ k is the average numberof hash insertions in the locality-sensitive scheme.The effective false positive rate will finally dependon how many checks take place on each separate filter.This way, a mathematical expectation of theJP2011-193

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIISignature scheme, separate (sep) or unified (uni), with the lowest false positive rates according to Eqs. (4)and (5) for several values of the given parameters (Bloom filters with m = 10 and k = 4).❍ f ❍n ❍0.20.8p R = 0.15 p R = 0.25 p R = 0.5p RW = 0.2 p RW = 0.5 p RW = 0.2 p RW = 0.5 p RW = 0.2 p RW = 0.5c R0.2 0.5 0.8 0.2 0.5 0.8 0.2 0.5 0.8 0.2 0.5 0.8 0.2 0.5 0.8 0.2 0.5 0.8128 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni256 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni512 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni768 uni sep sep uni sep sep uni sep sep uni uni uni sep sep uni sep sep uni1024 uni sep sep uni sep sep uni sep sep uni uni uni sep sep uni sep sep uni128 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni256 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni512 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni768 uni uni sep uni uni sep uni uni sep uni uni uni sep uni uni sep uni uni1024 uni uni sep uni sep sep uni uni sep uni uni uni sep uni uni sep sep unifalse positive rate for the separated locality-sensitivesignatures can be expressed as:E[p SEPARATEFP LOC(m, k, n, f)] = c R p readFP LOC+ c W p writeFP LOC.(4)Here c R and c W denote the probability of each filterbeing checked during the sequence of references.This checking pattern is directly linked to the way inwhich the threads inspect the potential data dependencies.It remains unknown until run-time, beingvery dependent on the parallelization strategy andthe input data. Other important issues having influenceon the checking pattern are the coherence protocoland the abort/resume policy of transactions.Regarding unified filters, Eq. (2) is still valid aslong as the k hashing functions used by reads andwrites are disjoint. To make a fair comparison, thesize of the unified locality-sensitive filter must be thesum of the sizes of the separate filters. Thus, the falsepositive probability for this unified locality-sensitivefilter is given byp UNIFIEDFP LOC(m, k, n, f) = p FP LOC (m+1, k, n(1+p RW ), f).(5)In Table III several scenarios are shown for differentvalues of the parameters defined above. Eqs. (4)and (5) have been evaluated with high and low valuesfor the given parameters: locality (f), only readaddresses (p R ), read and written addresses (p RW ),and number of checks in the read filter (c R ). Notethat p R + p RW + p W = 1 and c R +c W = 1. Labels inthe table point out the scheme (separate or unified)with the lowest false positive rate according to equations.In the 66% of the explored scenarios the unifiedscheme beats the separate one. Nevertheless, thescenario which is closer to real workloads is c R = 0.5,i.e. read and write filters are evenly checked, becausethe TM system assures strong atomicity [1] and datarequested to main memory (out of the bounds of TM)must be checked in both filters. Notice that, in thiscase, the unified scheme yields better false positiverates until the filter gets filled in about 2 3of its totalcapacity. With high locality such a limit shifts to 3 4or even disappears.A. MethodologyVI. EvaluationTo evaluate the performance of our unifiedlocality-sensitive signatures we used Simics [19] fullsystem execution-driven simulator along with theTM module GEMS [10] from the Wisconsin MultifacetProject. Simics simulates the SPARC architectureand it is able to run an unmodified copy of aSolaris operating system. Solaris 10 was installed onthe simulated machine and all workloads run on topof it. GEMS’s Ruby module implements the LogTM-SE TM [5] and also includes a detailed timing modelfor the memory system. Ruby was modified to includethe proposed unified signature design describedin Section III.The base CMP system consists of 16 in-order,single-issue cores with a 32KB split, 4-way associative,64B block private L1 cache each. L2 cache isunified, 8MB, 16-bank, 8-way associative, and 64Bblock size. A packet-switched interconnect with 64Blinks connects the cores and cache banks. Cache coherenceimplements the MESI protocol and maintainsan on-chip directory which holds a bit vectorof sharers. Main memory is 4GB.Simulation experiments use perfect signatures (nofalse positives, hardware unimplementable) as thereference. Filter size ranges from 64 bits, whichmatches the word length in SPARC architecture, to8K bits length, which matches the performance ofperfect signatures for the simulated benchmarks. Allfilters use 4 hash functions of the H3 family [14].Same H3 matrices of Ruby were used.The benchmarks belong to the Stanford’s STAMPsuite [20] which is designed for TM research and includesa wide range of applications with emphasison large read and write sets. STAMP workloadshave been adapted to GEMS by applying Luke Yen’spatches from the University of Wisconsin, Madison.Table IV summarizes the input parameters and maintransactional characteristics of the benchmarks.B. Unified Signature ResultsUnified signature motivation and design are describedin Section III. Table III shows that the percentageof addresses both read and written insideJP2011-194

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IVWorkloads: Input parameters and TM characteristicsBench Input #xactTime avg avg max maxin xact |RS| |W S| |RS| |W S|Bayes -v32 -r1024 -n2 -p20 -s0 -i2 -e2 523 94% 76.9 40.9 2067 1613Genome -g512 -s64 -n8192 30304 86% 12.1 4.2 400 156Intruder -a10 -l128 -n128 -s1 12123 96% 19.1 2.5 267 20Kmeans -m40 -n40 -t0.05 -i rand-n1024-d1024-c16 1380 6% 99.7 48.5 134 65Labyrinth -i rand-x32-y32-z3-n64 158 100% 76.5 62.9 278 257SSCA2 -s13 -i1.0 -u1.0 -l3 -p3 47295 19% 2.9 1.9 3 2Vacation -n4 -q60 -u90 -r16384 -t4096 24722 97% 19.7 3.6 90 30Yada -a20 -i 633.2 5384 100% 62.7 38.4 776 510Execution time (normalized to Perfect)706050403020100Execution time (normalized to Perfect)6543210Bayes64 128 256 512 1K 2K 4K 8KSignature size (bits)Labyrinth256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)1.31.251.21.151.11.0510.950.9Execution time (normalized to Perfect)43.532.521.510.50Genome64 128 256 512 1K 2K 4K 8KSignature size (bits)SSCA264 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)20151050Execution time (normalized to Perfect)543210Intruder64 128 256 512 1K 2K 4K 8KSignature size (bits)Vacation64 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)8642Execution time (normalized to Perfect)1.31.251.21.151.11.0510.950.9Kmeans64 128 256 512 1K 2K 4K 8KSignature size (bits)Yada064 128256512 1K 2K 4K 8KSignature size (bits)SeparateUnified s=0Unified s=1Unified s=2Unified s=3Unified s=4Fig. 3. Execution time normalized to perfect signature comparing separate to unified signatures. Parameter s varies from 0(2-ported SRAMS) to 4 (1-ported).transactions is substantial, so we conducted the experimentsto find out the number of hash functionsthat can be shared by read and write filters withoutlosing performance. For that purpose, sharedfunctions range from s = 0, all SRAMs are doubleported,to s = 4, all SRAMs are single-ported whichmeans that every insertion into the read set is alsoan insertion into the write set and vice-versa.Figure 3 shows the execution time of unified signatures.The more read set and write set hash functionsare shared (s > 0) the better results are obtained forall the benchmarks. In fact, the best results are obtainedfor s = 4 in every benchmark except Bayesand Genome, which execution is slowed down about1.25× with respect to separate filters for 8Kbit signatures.Therefore, unified s = 3 signatures should beused instead of s = 4 ones, as these benchmarks arenot pretty sensitive to read and write discriminationbut other might be.C. Unified Locality-Sensitive Signature ResultsLocality-sensitive hashing [9] takes advantage oflocality of reference to store an address stream moreconcisely in a Bloom filter. Locality-sensitive hashfunctions store nearby locations sharing some bits ofthe bit array, thus lowering the occupancy of the filter.For contiguous addresses, the number of hashingoutputs with different values is 1. Addresses withdistance 2 are different in no more than 2 hashingoutputs and, addresses with distance greater than2 k−1 − 1 may have no hashing outputs in common.Figure 4 shows the results of unified s = 3 localitysensitivesignatures. Two possibilities are shown:• L1: This scheme makes that the hash functionsh 3 and h ′ 3 assert less bits in their filter. Thisreduces the false positive rate because of lowoccupancy, but the filter may fail to discriminatereads/writes from nearby located reads/writes.• L2: This scheme is the opposite to L1. In thiscase, h 3 and h ′ 3 behaves as normal but the othersassert less bits. The filter not sharing thehash functions stay the same as in s = 3 configuration,discriminating between locations readand written, and the other filters get the localityimprovement.As Figure 4 shows, results for L1 scheme arepractically the same than those for L2 for everybenchmark except Labyrinth, Genome and Yada.Labyrinth behaves better with L2 for small signaturesand, Genome and Yada get slightly worse resultsfor small signatures and L2. Unified localitysensitivesignatures outperform separate and separatelocality-sensitive ones in most of the cases.VII. ConclusionsWe propose a unified signature design in the contextof transactional memory which keep track ofboth the read and write sets in the same filter withoutadding significant hardware complexity. SeveralJP2011-195

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Execution time (normalized to Perfect)6543210Bayes64 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)43.532.521.510.50Genome64 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)543210Intruder64 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)1.31.251.21.151.11.0510.950.9Kmeans64 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)302520151050Labyrinth256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)1.31.251.21.151.11.0510.950.9SSCA264 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)20151050Vacation64 128 256 512 1K 2K 4K 8KSignature size (bits)Execution time (normalized to Perfect)1086420Yada64 1282565121K 2K 4K 8KSignature size (bits)SeparateLocalityUnified s=3Unified s=3 L1Unified s=3 L2Fig. 4. Execution time normalized to perfect signatures comparing separate, separate locality and unified s = 3 signaturesenhanced with locality hashing (L1 and L2)configurations of unified signatures are analyzed andevaluated. Additionally, unified signatures are enhancedusing locality-sensitive hashing, proposed bythe authors in a previous work.The proposed unified locality-sensitive signatureswere implemented in the Wisconsin GEMS simulator,in order to evaluate their performance, and inCACTI to evaluate the hardware area and energyrequirements. Experimental results show that theunified approach improve the execution performancein most of the tested codes, without increasing therequired hardware area in a noticeable amount, makingof it a good alternative to separate signatures.AcknowledgmentThis work has been supported by the Ministry ofEducation of Spain with project CICYT TIN2006-01078 and by the Junta de Andalucia with projectP08-TIC-04341.References[1] J.R. Larus and R. Rajwar, Transactional Memory, Morgan& Claypool Pub., 2007.[2] M. Herlihy and J.E.B. Moss, “Transactional memory:Architectural support for lock-free data structures,”in 20th Ann. Int’l. Symp. on Computer Architecture(ISCA’93), 1993, pp. 289–300.[3] B.H. Bloom, “Space/time trade-offs in hash coding withallowable errors,” Communications of the ACM, vol. 13,no. 7, pp. 422–426, 1970.[4] L. Ceze, J. Tuck, P. Montesinos, and J. Torrellas,“BulkSC: Bulk enforcement of sequential consistency,”in 34th Ann. Int’l. Symp. on Computer Architecture(ISCA’07), 2007, pp. 278–289.[5] L. Yen, J. Bobba, M.R. Marty, K.E. Moore, H. Volos,M.D. Hill, M.M. Swift, and D.A. Wood, “LogTM-SE: Decouplinghardware transactional memory from caches,”in 13th Int’l. Symp. on High-Performance Computer Architecture(HPCA’07), 2007, pp. 261–272.[6] C.C. Minh, M. Trautmann, J. Chung, A. McDonald,N. Bronson, J. Casper, C. Kozyrakis, and K. Olukotun,“An effective hybrid transactional memory system withstrong isolation guarantees,” in 34th Ann. Int’l. Symp.on Computer Architecture (ISCA’07), 2007, pp. 69–80.[7] A. Shriraman, S. Dwarkadas, and M.L. Scott, “Flexibledecoupled transactional memory support,” in 35th Ann.Int’l. Symp. on Computer Architecture (ISCA’08), 2008,pp. 139–150.[8] M. Mehrara, J. Hao, P.-C. Hsu, and S. Mahlke, “Parallelizingsequential applications on commodity hardwareusing a low-cost software transactional memory,” in ACMSIGPLAN Conf. on Programming Language Design andImplementation (PLDI’09), 2009, pp. 166–176.[9] R. Quislant, E. Gutierrez, O. Plata, and E.L. Zapata,“Improving signatures by locality exploitation for transactionalmemory,” in Int’l Conf. on Parallel Architecturesand Compilation Techniques (PACT’09), 2009, pp.303–312.[10] M.M.K. Martin, D.J. Sorin, B.M. Beckmann, M.R.Marty, M. Xu, A.R. Alameldeen, K.E. Moore, M.D.Hill, and D.A. Wood, “Multifacet’s general executiondrivenmultiprocessor simulator GEMS toolset,” ACMSIGARCH Comput. Archit. News, vol. 33, no. 4, pp. 92–99, 2005.[11] S.J.E. Wilton and N.P. Jouppi, “CACTI: an enhancedcache access and cycle time model,” IEEE Journal ofSolid-State Circuits, vol. 31, no. 5, pp. 677 –688, 1996.[12] L. Ceze, J. Tuck, J. Torrellas, and C. Cascaval, “Bulk disambiguationof speculative threads in multiprocessors,”in 33th Ann. Int’l. Symp. on Computer Architecture(ISCA’06), 2006, pp. 227–238.[13] D. Sanchez, L. Yen, M.D. Hill, and K. Sankaralingam,“Implementing signatures for transactional memory,” in40th Ann. IEEE/ACM Int’l Symp. on Microarchitecture(MICRO’07), 2007, pp. 123–133.[14] L. Carter and M. Wegman, “Universal classes of hashfunctions,” J. Computer and System Sciences, vol. 18,no. 2, pp. 143–154, 1979.[15] M. V. Ramakrishna, E. Fu, and E. Bahcekapili, “Efficienthardware hashing functions for high performancecomputers,” IEEE Trans. on Computers, vol. 46, no. 12,pp. 1378–1381, 1997.[16] L. Yen, S.C. Draper, and M.D. Hill, “Notary: Hardwaretechniques to enhance signatures,” in 41stAnn. IEEE/ACM Int’l Symp. on Microarchitecture (MI-CRO’08), 2008, pp. 234–245.[17] W. Choi and J. Draper, “Locality-aware adaptivegrain signatures for transactional memories,” in IEEEInt’l. Symp. on Parallel and Distributed Processing(IPDPS’10), 2010, pp. 1–10.[18] N. Muralimanohar, R. Balasubramonian, and N. Jouppi,“CACTI 6.0: A tool to model large caches,” Tech. Rep.HPL-2009-85, HP Laboratories, 2009.[19] P.S. Magnusson, M. Christensson, J. Eskilson, D. Forsgren,G. Hallberg, J. Hogberg, F. Larsson, A. Moestedt,B. Werner, and B. Werner, “Simics: A full system simulationplatform,” IEEE Computer, vol. 35, no. 2, pp.50–58, 2002.[20] C. Cao Minh, J. Chung, C. Kozyrakis, and K. Olukotun,“STAMP: Stanford Transactional Applications forMulti-Processing,” in IEEE Int’l Symp. on WorkloadCharacterization (IISWC’08), 2008, pp. 35–46.JP2011-196

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Overriding the Coherence Protocolto Improve Directory CachesBlas Cuesta, Alberto Ros, María E. Gómez, Antonio Robles, and José Duato 1Abstract— Performance of shared-memory multiprocessorsdepends to a large extent on the cachecoherence protocol. Protocols based on directorycaches give excellent performance, but their performanceand scalability is jeopardized by the limitedsize of directory caches along with the increasing sizeof systems. Most memory blocks referred by parallel/sequentialapplications are private and, therefore,do not require coherence maintenance. We proposean approach so that directory caches can take advantageof this fact avoiding the tracking of such privateblocks. Thus, the amount of information that theymust store is considerably reduced, which in turn lowersthe number of directory entries evicted. Since theoperating system helps processors to implement thisapproach, it only requires minor modifications. Simulationresults show that our proposal allows directorycaches to avoid the tracking of about 57% of theaccessed blocks. This contributes to shorten applicationruntime by 15% (when directory cache size ispreserved) or to maintain system performance (whenusing up to eight times smaller directory caches).Keywords— Multiprocessor, cache coherence, directorycache, operating system, coherence deactivation,private blockI. IntroductionTASKS carried out by high-performance sharedmemorymultiprocessors [1] are increasinglycomplex, which generates a demand for larger andmore powerful systems. The performance of thesesystems depends to a large extent on the cache coherenceprotocol. One scalable approach to providecoherence is the use of directory caches [2], [3].Directory caches keep track of all memory blocksstored in processor caches and that information isused to maintain coherence upon processor accessesto shared blocks. To be able to ensure coherent accessesto all memory blocks, when a directory cacheentry is evicted, all the cached blocks associated tosuch an entry are invalidated. Since systems includemore and more processors and cores and the size ofdirectory caches is quite limited, directory caches suffera lot of evictions. As a result, a large amount ofblocks are invalidated from processor caches, whichdegrades system performance.Since enlarging the size of directory caches is not areasonable solution (due to access latency and arearequirements), it is necessary to make the most ofthe available space. To this end, we take advantageof the fact that a significant fraction of the referredmemory blocks are privately used (i.e., accessed byonly one processor [4]). This is illustrated in Figure1, which shows that about 75% (on average) ofthe accessed blocks are private. Since they are notshared, they cannot suffer inconsistencies and, consequently,they do not require coherence maintenance.1 Department of Computer Engineering, UniversitatPolitècnica de València, e-mail: {blacuesa, aros, megomez,arobles, jduato}@gap.upv.esPrivate vs. shared blocks1.00.90.80.70.60.50.40.30.20.10.0PrivateSharedBarnesCholeskyFig. 1.FFTOceanRadiosityRaytrace-optVolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheSPEC-JBBAverageFraction of private versus shared blocks.Therefore, directory caches do not need to keep informationabout private blocks. By doing this, directorycaches will be less demanded and the numberof directory entries evicted (and, in turn, the numberof invalidated cached blocks) can be drasticallyreduced.To identify private blocks without using dedicatedhardware resources, we devise a mechanism aidedby the operating system (OS). The idea is that, bydefault, every new page loaded into main memoryis considered as private (which makes all its blocksbe considered as private as well). While only oneprocessor accesses the blocks within a private page,the page is kept as private and the accesses to themoverride the coherence protocol, which prevents directorycaches from tracking them. However, whenthe OS detects that a processor wishes to access ablock within a private page previously accessed by adifferent processor, the OS triggers a coherence recoverymechanism for the page. This mechanism restoresthe coherence for all the blocks within such apage and, from that moment on, the page is consideredas shared. The accesses to blocks within sharedpages are handled by the coherence protocol, whichenforces their tracking.Simulation results show that, thanks to our proposal,directory caches omit the tracking of about57% (on average) of the accessed memory blocks.This reduces the number of evictions of directorycache entries and, as a result, the number of invalidationsof cached blocks, which leads to cachemiss reductions of about 35%. Doing so, system performanceimproves by about 15% (on average) andenergy consumption is reduced by about 40% (onaverage). Alternatively, simulations also show thata system implementing our proposal performs similarlyto a system that uses directory caches eighttimes larger.The rest of the paper is organized as follows. SectionII discusses the related work. Our proposal isdescribed in Section III. We characterize the simulationenvironment in Section IV and present theevaluation results in Section V. Finally, Section VIdraws some conclusions.JP2011-197

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011P0 P1 MCmemory reference to block AA is in private pagecache miss on private block Anon−coherent request issuecache miss resolvedmemory reference to block AA is in private page, but it should be sharedtrigger the coherence recovery mechanismA is now in shared pagecache miss on shared block Acoherent request issuecache miss resolvedresolve non−coherent missoverride coherence protocol(do not keep trackin directory cache)OSresolve coherent missuse coherence protocol(keep track indirectory cache)Fig. 2. Overview of the proposal. P0 and P1 are processorsand MC is the memory controller. The shaded backgroundindicates that the OS is in charge at that moment.II. Related WorkLike our approach, some proposals use the OSto detect private and shared pages. Hardavellas etal. [4] uses this detection to propose an efficientdata placement policy for distributed shared caches(NUCA). While the mechanism for detecting privatepages is similar to ours, its application is completelydifferent (data placement) and it does not considercoherence aspects. On the other hand, Kim et al. [5]employ OS detection to reduce the fraction of snoopsin token-based protocols. That work is based onthe fact that, although most referred blocks are private,the small fraction of shared blocks accounts formost cache misses. By detecting the shared blocksand their sharing degree, they can replace broadcastmessages by multicast. Unfortunately, this proposalrequires considerable extra hardware, increases thecomplexity, and adds OS overhead.Some proposals [6], [7], [8] use coarse-grain trackingof blocks to filter unnecessary traffic. However,those proposals have high storage requirements, areextremely complex, and entail considerable modificationsof the cache design. Besides, they just aimtraffic reduction.Similarly to our proposal, other works [9], [8] takeadvantage of OS structures. Contrariwise, they keepthe block sharers with the goal of reducing trafficor energy consumption. Unfortunately, those techniquesincrease storage requirements and entail importanthardware modifications, which make themdifficult to implemented in real systems.Zeffer et al. [10], [11] propose a combination ofsoftware and hardware to provide coherence. In particular,a trap-based architecture detects fine-grainedcoherence violations in hardware, triggers a coherencetrap when one occurs, and maintains coherenceby software in coherence trap handlers. In this case,the software overhead is quite high, which considerablyincreases the latency, and extra hardware isrequired to speed up the coherence trap handling.Fensch et al. [12] propose a coherence protocolthat does not require hardware support. It avoids thepossibility of incoherence by not allowing multiplewritable shared copies of pages. However, that proposalrequires release consistency, introduces extraoverhead regarding hardwired systems, and is onlysuitable for CMPs.virtual addressvirtual addresstagtagVVTLB entrypage table entryphysical addressphysical addressdatadataPCPLkeeperFig. 3. TLB and page table entry format. Shaded fields areextra fields. V is the valid bit, P is the private bit, L isthe locked bit, and C is the cached-in-TLB bit.III. Coherence DeactivationIn order to avoid inconsistencies, directory cachestrack all cached memory blocks. However, a significantfraction of them are private and cannot suffer inconsistencies.To avoid this unnecessary informationwhich decreases the effectiveness of directory caches,we propose a technique that dynamically detects privateblocks and avoid their tracking.The general idea is that, by default, every newpage loaded into main memory is considered as private.Cache misses for blocks belonging to privatepages override the coherence protocol. As a result,directory caches do not keep track of them. Whenthe OS detects that two different processors try toaccess blocks within the same private page, it triggersa coherence recovery mechanism that restoresthe coherence status of every block within the privatepage and converts it into shared. From thatmoment on, the page is considered as shared and thememory accesses to its blocks are resolved accordingto the coherence protocol, which ensures their tracking.Figure 2 outlines this. First, P0 references thememory block A, which causes a cache miss. Since Abelongs to a private page, P0 issues a non-coherentrequest, which is served without tracking it. Later,P1 references the same memory block A and a TLBmiss happens. While the OS is handling the miss, itrealizes that the page should become shared. Consequently,it triggers the coherence recovery mechanism.When it finishes, the page becomes shared andthe access to the cache proceeds, resulting in a cachemiss. Since the referred block belongs to a sharedpage, a coherent request is issued, which is trackedby the directory cache.Next sections walk through different key aspectsof our proposal such as the generation and service ofnon-coherent requests (Section III-A), the detectionof shared pages (Section III-B), and the coherencerecovery mechanism (Section III-C).A. Non-Coherent RequestsOn memory references, processors first access theirTLB to translate the virtual addresses of blocks intophysical addresses. As shown in Figure 3, each TLBentry is mainly made up of the virtual address of thepage, the corresponding physical address, and otherproperties associated to the translation. Since someof the bits associated to the translation are not used,we take advantage of two of them to include twonew fields: the private bit (P), which differentiatesbetween private and shared pages, and the locked bit(L), which is used to avoid undesirable race conditions(as explained later in Section III-C).JP2011-198

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MemoryoperationP0 keeperP1 initiatorhome MCHitOperationsuccessfulMiss resolvedFig. 4.HitAccessto cacheYesNon−coherentrequestAccessto TLBMissPrivatepage in TLBMark pageas sharedMissNoMiss resolvedCoherentrequestCoherencerecoveryFaultAdd pagetable entry(private)NoAccess topage tableYesIs this thepage keeper?HitStore page tableentry in TLBPrivate pageBlock diagram of the general working scheme.YesNotrigger coherence recoveryrecovery requestpage P keeper P0lock page P in TLBevict cachedevictionsblocks of Pwait for pendingoperationsset TLB entry to sharedunlock page P in TLBrecovery donepage Pend coherence recoveryset page table entry to sharedOSwrite datato memoryTIMEP is used when a memory reference causes a cachemiss. Hence, if the cache miss is for a block belongingto a private page, a non-coherent requestis issued. Otherwise, a coherent request is issued.Non-coherent requests override the coherence protocoland they are always served by main memory. Inaddition, directory caches do not track them. Thisbehaviour has two primary advantages. First, neithera lookup nor an insertion in the directory cacheis required, which helps to reduce the latency of cachemisses, the contention at memory controllers, andthe energy consumption. Second, directory cachesare not so contended and, therefore, their capacitycan be better exploited to track blocks that reallyneed coherence.B. Detection of Shared PagesAs shown in Figure 3, page tables require threeadditional fields. Private (P) indicates whether thepage is private or shared. If P is set, keeper indicatesthe identity of the only processor that hasaccessed the page blocks. The cached-in-TLB bit(C) indicates whether the keeper field is valid ornot. These extra fields only require extra OS storagespace, which is very small. Particularly, their size is2 + log 2 (N) bits, where N is the number of processorsin the system. Thus, assuming an 8-processorsystem, only 5 extra bits per entry are required.On a page table fault, the OS allocates a new pagetable entry with the virtual to physical address translation.In addition, since every newly loaded page isconsidered as private, P is set and C is cleared indicatingthat the entry is not cached in any TLByet. When a TLB miss takes place in a processor,it retrieves the information from the page table andstores it in its TLB. The extra fields in the page tableare updated inside a critical section during the resolutionof TLB misses according to the following fourpremises: (1) if C is clear (i.e., the page blocks havenot been cached yet), C is set and the identity of theprocessor requesting the page table entry is kept inkeeper; (2) if both C and P are set and keeper matchesthe requester (the keeper processor suffered a TLBeviction and it requires such information again), nochanges are necessary; (3) if both C and P are setand keeper does not match the requester (two differentprocessors are trying to access blocks within thesame private page), the coherence recovery mechanismis triggered and, when it finishes, P is cleared;and (4) if C is set and P is clear (the page is shared),no changes are necessary.Fig. 5. Flushing-based recovery mechanism. P0 and P1 areprocessors and MC is the home node. Solid arrows aremessages due to the recovery mechanism, whereas dashedarrows are messages due to the coherence protocol.Figure 4 depicts all the actions that take place onmemory operations.C. Coherence Recovery MechanismBefore turning a private page into shared, the recoverymechanism has to ensure that the directorycache keeps proper track of every block within thepage. This can be done by two different strategies:(1) not modifying the directory cache and evictingall the page blocks from the keeper’s cache (flushingbasedrecovery) or (2) updating the directory cachewith proper track of every cached block within thepage (updating-based recovery). Next two sectionsexplain these mechanisms in detail.C.1 Flushing-based Recovery MechanismThe simplest way to restore the coherence statusof the blocks belonging to a page that has to becomeshared is by evicting all the page blocks so that thenext time any of them is accessed, the directory cachecan begin to keep proper track of them. This mechanismworks as follows.First, the initiator (node that triggers the coherencerecovery) issues a recovery request for the involvedpage to its keeper, which is obtained from thepage table during the page table fault resolution.Second, on the recovery request arrival, the keeperperforms four operations: (1) it locks the correspondingTLB entry by setting the L bit, which preventsthe keeper from issuing new requests for any of thepage blocks; (2) the keeper performs a cache lookup,flushing (and, if required, writing-back) every cachedblock within the involved page; (3) the keeper checksits MSHR (Miss Status Holding Registers) structureto wait for the completion of the pending misses orevictions for any of the page blocks; and (4) thekeeper marks the TLB entry corresponding to theinvolved page as shared, unlocks it, and sends to theinitiator a recovery done message.Third, when the initiator receives the recoverydone message, the recovery mechanism finalizes andthe page is set as shared in both the page table andthe local TLB. Notice that, during this process, theOS has exclusive access to the involved page table entryand no other processor can access it so that raceconditions cannot take place. Figure 5 illustrates anexample of how this mechanism works.JP2011-199

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011P0 keeperP1 initiatorhome MClock page P in TLBset TLB entry to sharedunlock page P in TLBpage Plook for cachedblocks of Pwait for pendingoperationskeeper P0 page Pcached blocks 1010..0recovery requestrecovery responserecovery donetrigger coherence recoverypage Pkeeper P0end coherence recoveryset page table entry to sharedrecovery target doneOSdirectory cache updatingtagACpage Psharing codeP0P0keeper P0Fig. 6. Updating-based recovery mechanism. P0 and P1 areprocessors and MC is the home node.After completing this process, we know for surethat the blocks belonging to the recovered page arenot cached. Thus, from that moment on, directorycaches can keep proper track of them.C.2 Updating-based Recovery MechanismThe main advantage of the flushing-based recoveryis that its implementation in real systems is feasibleand straightforward. However, the flushing ofall cached blocks may increase the miss rate of processorcaches (this is analyzed in Section V). To addressthis potential drawback, we propose an alternativeimplementation based on updating the directorycache information that works as follows.First, the initiator issues a recovery request to thecorresponding page keeper.Second, the page keeper locks the correspondingTLB entry on the arrival of the recovery request andlooks for the blocks within the page that are presentin its cache. The addresses of those blocks are codedin a bit vector, which is included in a recovery response.After composing the bit vector, the keeperchecks its MSHR structure and waits for the outstandingoperations on any of the page blocks (ifany). Once the pending operations complete, therecovery response is sent to the home memory controller.Third, upon the receipt of a recovery response,the home memory controller proceeds to update itsdirectory cache according to the received bit vector.In particular, it creates a new directory cache entryfor every block cached by the keeper. The sharingcode of every new entry can be easily set becauseit knows that, at that moment, the keeper is theonly one with a valid copy of the block. When thedirectory cache updating finalizes, the home nodesends a recovery target done message back to the pagekeeper.Forth, when the keeper receives the recovery targetdone message, it marks the TLB entry correspondingto the page as shared, unlocks the correspondingTLB entry, and sends a recovery done message tothe initiator, finalizing the recovery process. Figure6 shows an example of how the updating-basedrecovery mechanism works.TIMETABLA ISystem parameters.Memory ParametersProcessor frequency3.2 GHzCache block size64 bytesProcessor cache2MB, 4-wayProcessor cache access latency 2nsDirectory cache256KB, 4-wayDirectory cache access latency 2nsDirectory cache coverage ratio 2×, worst-case 0.25×Memory access latency (local bank) 60nsPage size4KB (64 blocks)Network ParametersNetwork topologyHypercubeData message size68 and 72 bytesControl message size4 and 8 bytesNetwork bandwidth12.8GB/sInter-die link latency2nsInter-processor link latency20nsFlit size4 bytesLink bandwidth1 flit/cycleAfter completing the updating-based recoverymechanism for a page, we know for sure that the directorycache holds proper track of the page blocks.IV. Evaluation MethodologyWe evaluate our proposals with full-system simulationusing Virtutech Simics [13] running Solaris 10and extended with the Wisconsin GEMS toolset [14],which enables detailed simulation of multiprocessorsystems. The interconnection network is modeledwith GARNET [15]. Finally, we also use the Mc-PAT tool [16], assuming a 45nm process technology,to measure energy consumption.For the evaluation of our proposals, we first modela cache coherent HyperTransport system optimizedwith directory caches similar to those of the AMDMagny-Cours. The simulated system has 8 processors(16 cores) and its parameters are shown in TableI. We refer to this system as the base architectureand our proposals are implemented upon it.We simulate a wide variety of parallel workloadsfrom 3 suites (SPLASH-2 [17], ALPBenchs [18], andPARSEC [19]), two scientific benchmarks, and twocommercial workloads [20]. Due to time requirements,we are not able to simulate these benchmarkswith large working sets. Consequently, as done inmost works [7], [21], [12], we simulate the applicationsassuming smaller data-sets. To avoid alteringthe results, we reduce four times the size of both processorcaches and directory caches. Notice that, sincethe size of all the simulated caches are proportionallyreduced, the coverage ratio of directory caches is thesame as in Magny-Cours (2×).All the reported experimental results correspondto the parallel phase of benchmarks. We account forthe variability in multi-threaded workloads by doingmultiple simulation runs for each benchmark and injectingsmall random perturbations in the timing ofthe memory system.V. Performance EvaluationOur proposal is based on the fact that mostreferred blocks are privately used by processors.Crosses in Figure 7 show the fraction of actual privateblocks. As observed, about 75% (on average)of the referred blocks are private. Since our proposalworks at a page granularity, it cannot identifyall the private blocks because, when a page containsJP2011-200

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Private blocks rateNormalized cache miss rate1.00.90.80.70.60.50.40.30.20.10.0FlushingIdealBarnesCholeskyFig. 7.BarnesCholeskyFFTOceanRadiosityRaytrace-optVolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheSPEC-JBBAverageFraction of actual versus detected private blocks.1. Base 2. Flushing 3. Updating1.11.00.90.80.70.60.50.40.30.20.10.0Fig. 8.FFTOceanRadiosity3C Coherence Coverage FlushingRaytrace-optVolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheNormalized cache miss rate classification.SPEC-JBBAverageboth private and shared blocks or just private blocksaccessed by different processors, the page is consideredas shared. Bars in Figure 7 show the fraction ofblocks that our mechanism detects as private. Thus,our proposal detects that 57% on average are privateblocks and the other 18% of the blocks are misclassified.Since directory caches do not track blocks detectedas private, less blocks contend for their entries.Consequently, they suffer fewer evictions and,therefore, less blocks are invalidated from processorcaches. As a result, the processor cache miss rateis reduced by 35% (on average), as Figure 8 shows.This figure illustrates the fraction of cache misses(normalized to the base system) when deactivatingthe coherence and assuming the two proposed recoverymechanisms. Cache misses are classified in fourdifferent groups: 3C misses comprise Cold, Capacity,and Conflict misses; coherence misses refer tothose caused by invalidations due to write requestsissued by other processors; coverage misses are thosecaused by the invalidations issued by the directorycaches due to replacements; and flushing misses aredue to evictions performed by the recovery mechanism.Since our proposal aims at improving theeffectiveness of directory caches, it acts on coveragemisses, which are reduced by about 75% on average.Furthermore, as shown in the figure, contraryto what might be thought, the use of the flushingbasedrecovery mechanism does not entail an increaseof the total number of cache misses with respect tothe updating-based implementation.The reduction of both directory cache evictionsand processor cache misses drastically reduces the coherencetraffic by about 40% on average, as depictedin Figure 9. This figure shows the network trafficgenerated by the assumed cache coherence protocolusing our proposal normalized to the base system.Each bar plots the number of flits transmitted acrossthe interconnection network.The latency of the recovery mechanisms is considerablebecause it includes a search in the cache ofthe page keeper and, in case of the updating-basedmechanism, it also includes several accesses to the directorycache to add the required entries. However,the recovery mechanism is not often used and, there-Normalized network trafficRecovery actions per 1000 misses1.11.00.90.80.70.60.50.40.30.20.10.022.020.018.016.014.012.010.08.06.04.02.00.0BarnesCholeskyBarnesCholeskyFig. 10.FlushingUpdatingFFTOceanRadiosityFig. 9.FlushingRaytrace-optUpdatingFFTOceanRadiosityRaytrace-optVolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheSPEC-JBBAverageNormalized network traffic (in flits).23.2VolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheSPEC-JBBAverageCoherence recovery triggers per 1000 cache misses.fore, its impact on the overall performance is almostunnoticeable. To illustrate this, Figure 10 shows thenumber of times that the coherence recovery mechanismis triggered per 1000 cache misses. On average,this mechanism is only triggered about 3 times per1000 cache misses (up to 23 for the SPEC-JBB application).As a result, cache misses have much moreimpact on the whole runtime of applications than thecoherence recovery mechanism.Mainly due to the reduction in the number of cachemisses, the runtime of applications can be significantlyreduced, as depicted by the bar labeled asflushing in Figure 11. Since the results are quite similarfor both recovery mechanisms, we only show theresults for the mechanism based on flushing. Thus,according to these results, the proposed techniquecan lead to improvements in application runtime ofabout 15% on average. The systems where the storagerequirements are critical can also take advantageof our proposal because, by means of it, the size ofdirectory caches can be drastically reduced while obtaininggood performance. This is illustrated by thebars labeled as DC:2, DC:4, and DC:8, which representthree configurations with a half, a fourth, andan eighth of the base cache size, respectively. We cansee that our proposal allows us to reduce the size ofdirectory caches up to eight times while still maintainingthe execution time of applications similar (onaverage) to that of the base system.Figure 12 shows the dynamic energy consumption.First, the energy consumption of directory cachesis reduced because non-coherent requests do not accessthem. This reduction becomes more significantas the directory cache size decreases. Second, theenergy consumption of memory controllers is alsoreduced. In this case, as directory caches becomesmaller, the number of cache misses increases and,consequently, more accesses to memory controllerswill be required, which increases its consumption.Third, the energy consumption of the interconnectionnetwork lowers because of the reduction in networktraffic. Thus, the overall consumption of thesethree components is reduced by about 40% on average.Although, the overall energy consumption increasesas directory caches become smaller, it is stilllower than that of the base system using directorycaches 8 times larger.JP2011-201

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Normalized execution time1.31.21.11.00.90.80.70.60.50.40.30.20.10.0BarnesFlushingFlushing DC:2CholeskyFlushing DC:4Flushing DC:81.60 2.42FFTOceanRadiosityRaytrace-optVolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheSPEC-JBBAverageFig. 11. Execution time normalized to the base system. DC:2, DC:4, and DC:8 stand for directory caches with their sizedivided by 2, 4, and 8, respectively.Dynamic energy2.01.81.61.41.21.00.80.60.40.20.01. Base 2. Updating 3. Flushing 4. Flushing DC:2 5. Flushing DC:4 6. Flushing DC:8BarnesCholeskyDirectoryCache MemoryController NetworkFFTOceanRadiosityRaytrace-optVolrendWater-NsqTomcatvUnstructuredFaceRecMPGdecMPGencSpeechRecBlackscholesCannealSwaptionsFluidanimatex264ApacheSPEC-JBBAverageFig. 12. Dynamic energy consumption normalized to the base system. DC:2, DC:4, and DC:8 stand for directory caches withtheir size divided by 2, 4, and 8, respectively.3.02The static energy consumption is not shown in Figure12 because it is really tight to application runtime.Besides, in directory caches, it also dependson the directory size. Thus, when using directorycaches 2, 4, and 8 times smaller than that in the basesystem, the static power consumption is reduced by48%, 74%, and 86%, respectively.VI. ConclusionsThe proposal made in this paper aims to improvethe effectiveness of directory caches. It takes advantageof the fact that most referred memory blocksare private and, therefore, they do not require coherencemaintenance. Thus, directory caches do notkeep track of them. Since the amount of informationstored by directory caches is drastically reduced, thenumber of blocks invalidated from processor cachesdue to replacements in directory caches also lowers(by about 57% on average). This contributes to increasesystem performance (15%) or to reduce thestorage requirements of directory caches (8 times).Due to the simplicity of the proposed technique,it can be implemented without modifying the coherenceprotocol or the processor hardware, being itsimplementation feasible in actual systems.AcknowledgmentsThis work has been supported by Generalitat Valencianaunder Grant PROMETEO/2008/060.Referencias[1] P. Conway et al., “Cache hierarchy and memory subsystemof the AMD opteron processor,” IEEE Micro, vol.30, no. 2, pp. 16–29, Apr. 2010.[2] B. W. O’Krafka et al., “An empirical evaluation of twomemory-efficient directory methods,” in 17th Int’l Symp.on Computer Architecture (ISCA), June 1990, pp. 138–147.[3] A. Gupta et al., “Reducing memory traffic requirementsfor scalable directory-based cache coherence schemes,”in Int’l Conference on Parallel Processing (ICPP), Aug.1990, pp. 312–321.[4] N. Hardavellas et al., “Reactive NUCA: Near-optimalblock placement and replication in distributed caches,”in 36th Int’l Symp. on Computer Architecture (ISCA),June 2009, pp. 184–195.[5] D. Kim et al., “Subspace snooping: Filtering snoopswith operating system suport,” in 19th Int’l Conferenceon Parallel Architectures and Compilation Techniques(PACT), Sept. 2010, pp. 111–122.[6] A. Moshovos, “RegionScout: Exploiting coarse grainsharing in snoop-based coherence,” in 32nd Int’l Symp.on Computer Architecture (ISCA), June 2005, pp. 234–245.[7] J. F. Cantin et al., “Improving multiprocessor performancewith coarse-grain coherence tracking,” in 32thInt’l Symp. on Computer Architecture (ISCA), June2005, pp. 246–257.[8] J. Zebchuk et al., “A framework for coarse-grain optimizationsin the on-chip memory hierarchy,” in 40thIEEE/ACM Int’l Symp. on Microarchitecture (MICRO),Dec. 2007, pp. 314–327.[9] N. D. Enright-Jerger et al., “Virtual circuit tree multicasting:A case for on-chip hardware multicast support,”in 35th Int’l Symp. on Computer Architecture (ISCA),June 2008, pp. 229–240.[10] H. Zeffer et al., “TMA: A trap-based memory architecture,”in 20th Int’l Conference on Supercomputing (ICS),June 2006, pp. 259–268.[11] H. Zeffer et al., “A case for low-complexity MP architectures,”in ACM/IEEE Conference on Supercomputing(SC), Nov. 2007, pp. 10–16.[12] C. Fensch et al., “An OS-based alternative to full hardwarecoherence on tiled CMPs,” in 14th Int’l Symp. onHigh-Performance Computer Architecture (HPCA), Feb.2008, pp. 355–366.[13] P. S. Magnusson et al., “Simics: A full system simulationplatform,” IEEE Computer, vol. 35, no. 2, pp. 50–58,Feb. 2002.[14] M. M. K. Martin et al., “Multifacet’s general executiondrivenmultiprocessor simulator (GEMS) toolset,” ComputerArchitecture News, vol. 33, no. 4, pp. 92–99, Sept.2005.[15] N. Agarwal et al., “GARNET: A detailed on-chip networkmodel inside a full-system simulator,” in IEEE Int’lSymp. on Performance Analysis of Systems and Software(ISPASS), Apr. 2009, pp. 33–42.[16] S. Li et al., “McPAT: An Integrated Power, Area, andTiming Modeling Framework for Multicore and ManycoreArchitectures,” in 42nd IEEE/ACM Int’l Symp. onMicroarchitecture (MICRO), Dec. 2009, pp. 469–480.[17] S. C. Woo et al., “The SPLASH-2 programs: Characterizationand methodological considerations,” in 22nd Int’lSymp. on Computer Architecture (ISCA), June 1995, pp.24–36.[18] M. Li et al., “The ALPBench benchmark suite for complexmultimedia applications,” in Int’l Symp. on WorkloadCharacterization, Oct. 2005, pp. 34–45.[19] C. Bienia et al., “The PARSEC benchmark suite: Characterizationand architectural implications,” in 17th Int’lConference on Parallel Architectures and CompilationTechniques (PACT), Oct. 2008, pp. 72–81.[20] A. R. Alameldeen et al., “Evaluating non-deterministicmulti-threaded commercial workloads,” in 5th WorkshopOn Computer Architecture Evaluation using CommercialWorkloads (CAECW), Feb. 2002, pp. 30–38.[21] N. D. Enright-Jerger et al., “Virtual tree coherence:Leveraging regions and in-network multicast tree for scalablecache coherence,” in 41th IEEE/ACM Int’l Symp.on Microarchitecture (MICRO), Nov. 2008, pp. 35–46.JP2011-202

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Overcoming the Scalability Constraints ofCoherence Protocols of Commodity SystemsAlberto Ros 1 Blas Cuesta 1 Ricardo Fernández-Pascual 2 María E. Gómez 1Manuel E. Acacio 2 Antonio Robles 1 José M. García 2 y José Duato 1Abstract— AMD has recently launched the twelvecoreMagny-Cours processors. They include a directorycache that increases the scalability of the coherenceprotocol applied by Opterons. This directorycache uses a 3-bit pointer for identifying the ownernode of a memory block, which prevents Magny-Cours-based servers from being built beyond 8 nodes.In this paper, we propose and develop an externallogic to extend the coherence domain of Magny-Coursprocessors beyond the 8-node limit while maintainingthe advantages provided by the directory cache. Evaluationresults for up to a 32-node system show howthe performance offered by our solution scales withthe increment in the number of nodes. Particularly,we reduce runtime by 47% in a 32-die system respectto the 8-die Magny-Cours system.Keywords— High-performance computing, sharedmemory, cache coherence, directory protocol, coherenceextension, scalability, traffic filtering.I. IntroductionAMD has recently launched the six- and twelvecoreversions of its Opteron processors, codenamedIstanbul and Magny-Cours [1], respectively.These commodity systems increase the number ofcores per processor package with respect to the previousgeneration of Opteron processors. However,the novelty of these systems is the inclusion of a directorycache, called HT Assist Probe Filter (HTA)[2], whose main aim is to reduce the number ofmessages generated by the cache coherence protocol.The Magny-Cours protocol, which is an adaptationof the protocol defined by the coherent HyperTransport(cHT) specification, allows to build asmall cache-coherent shared memory multiprocessor(up to eight dies) in a single board.The addition of the HTA reduces cache miss latencyand coherence traffic, thereby increasing thescalability of the protocol. However, the HTA suffersthe addressing limitations imposed by the cHTspecification, which limits the coherence domain forIstanbul and Magny-Cours processors up to 8 dies(or nodes) [1]. This goes against the current commercialinterest in developing cluster-based HPC systemsable to offer large cache-coherent shared memory addressspaces, such as the SGI Ultraviolet (Altix UV)[3] machines.The addressing limitation of the cHT specificationis solved in the new High Node Count (HNC)HyperTransport specification [4], which extends the1 Dpto. de Informática de Sistemas y Computadores, Univ.Politécnica de Valencia, e-mail: {aros,blacuesa,megomez,arobles,jduato}@gap.upv.es2 Departamento de Ingeniería y Tecnología de Computadores,Univ. Murcia, e-mail: {rfernandez,meacacio,jmgarcia}@ditec.um.escHT specification by encapsulating standard cHTmessages into HNC packets. However, as currentOpteron processors do not implement this extension,the coherence domain remains limited to 8 dies beingrequired an external logic to overcome this limitation.In this work, we present a device, called bridgechip or EMC 2 (Extended Magny-Cours Coherence)chip, that (1) provides a way to efficiently extend thecoherence domain provided by the new generation ofAMD Opteron processors beyond the 8-die limit, (2)maintains the advantages provided by the HTA, and(3) filters additional coherence traffic to enhance theHTA effectiveness. The EMC 2 chip is added to eachboard in the system, replacing one of the existingdies. It manages the communication between dies indifferent boards by performing conversions betweencHT and HNC packets.We have proposed three different implementationsfor the EMC 2 chip that cover a wide set of tradeoffsbetween their area requirements and the amountof traffic filtered by them. Additionally, to improvethe scalability of our design, we have proposed anapproach that reduces the number of replacementsin the HTA.Simulation results show that our proposal allowsto build large-scale shared-memory servers based onthe new-generation Opteron processors, able to exploitthe advantages of the HTA at the overall systemlevel. Particularly, the bridge chip named asEMC 2 -OXSX reduces the average execution time ofthe evaluated applications by 47% for a 32-die systemrespect to the 8-die system allowed by Magny-Cours, while obtaining an excellent compromise betweenarea and traffic requirements.The remainder of this paper is organized as follows.Section II outlines the Magny-Cours cachecoherence protocol. We present our proposals forextending AMD Magny-Cours cache coherence capabilitiesin Section III. We describe our simulationenvironment in Section IV and present the evaluationresults in Section V. Finally, we draw conclusions inSection VI.II. AMD Magny-Cours Cache CoherenceAMD Opteron processors use the cache coherenceprotocol defined by the cHT specification [5]. Thisprotocol was designed to perform efficiently in a systemwith a small number of processors connectedwith tightly-coupled point-to-point HyperTransportlinks. It can be characterized as a directory-basedJP2011-203

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Core 0512kBL2Core 1 Core 2 Core 3 Core 4512kBL2512kBL2512kBL2System Request Interface (SRI)512kBL2Core 5512kBL2Nest 0 Nest 1 Nest NNode 0 Node 1 Node 0 Node 1 Node 0 Node 1Node 2 Node 3 Node 2 Node 3. .Node 2 Node 3L3 tagXBARL3 data array(6MB)EMC 2 chip EMC 2 chipEMC 2 chipMemoryControllerMCT/DCTDRAMFig. 1.DRAMHTAProbeFilter4 HyperTransportTM3 PortsBlock diagram of Magny-Cours dies.protocol without directory information, also knownas Dir 0 B [6]. This lack of directory information reducesthe memory overhead and avoids the latencyof accessing it.Accesses to memory blocks are serialized by theirhome node (memory controller), which will broadcastmessages known as Broadcast Probe (BP). Nodesreply to BPs with Probe Response (PR) messages,which are collected by the requester. Once the requestis satisfied, the requester sends a Source Done(SD) to the home node, which is allowed to proceedwith the next request for the block. The requiredBPs do not excessively increase bandwidth consumptionin small systems. However, as the number ofnodes grows, both the bandwidth consumed and thetime required to receive and process all the PRsincrease dramatically. Finally, writebacks of dirtyblocks are sent to their home node which will replyto the requester with a Target Done (TD) message.Like in the previous case, the transaction ends witha SD.Recent Istanbul and Magny-Cours processors includea small on-chip directory cache [2] called HTAssist Probe Filter (HTA), as shown in Figure 1.The HTA holds an entry for every block from thehome node cached in the system. Each entry has 4bytes which are used to store a tag, a state (EM, O,S1 or S) 1 , and a pointer to the current owner of theblock (3 bits). This information is used to (1) filterunnecessary BPs when no copy of the data is cachedand (2) to replace some BPs with unicast DirectedProbe (DP) messages. In case of a DP, only one response,called Directed Response (DR), is generated.Upon a miss on the HTA, a new entry must be allocated,which may require to replace an existing one.Before performing the replacement, all the cachedcopies of the block identified by the replaced entrymust be invalidated either by a DP (if the replacedentry is in EM or S1 state) or by a BP (if it is in Oor S state).As Figure 1 depicts, a portion (1MB of 6MB available)of the L3 cache is dedicated to HTA entries toavoid adding a large overhead in uniprocessor systems.This provides enough space for 256K entriesorganized in 64K 4-way sets, which are enough fortracking 16MB (256K entries × 64 bytes/block) ofdata cached in the system.1 Blocks are stored in caches according to the MOESI states.Switch FabricFig. 2. Overview of the proposed system. Thick arrows insidethe boards represent x16 cHT links while the narrow onesare x8 cHT links.Since the cHT packet format assumes 3-bit fieldsto identify coherent nodes, Magny-Cours systems arestill limited to 8 dies. The HNC HyperTransportspecification addresses this last problem by extendingthe cHT specification. To this end, it defines theconcept of nest as any addressable entity (which canbe anything from a single processor up to a motherboardcontaining several processors) and an extendedpacket format that can encapsulate standard cHTmessages and uses a nest-based addressing scheme.However, it does not establish how packets shouldbe handled when they move between local and remotedomains. Besides, the HTA imposes an additionallimitation because the pointer used to encodethe current owner of a cached block has only 3 bits,bounding the Magny-Cours systems to a maximumof 8 dies. To overcome these two problems we proposethe EMC 2 chip described in the next section.III. Extending Magny-Cours CoherenceWe assume the system illustrated in Figure 2. Asshown, it comprises several processor boards (referredto as nests). Each nest contains 4 processordies (referred to as nodes) and the EMC 2 bridge chipwhich acts as (1) a network interface controller forthe entire nest, (2) a translator between cHT andHNC packets, and (3) an extension of the HTAs ofthe nodes. Each board includes a consecutive fractionof the physical memory addresses.A. Extending the Coherence DomainTo maintain coherence between nodes in differentnests, we propose the use of the EMC 2 chip, whoseblock diagram is shown in Figure 3. From the pointof view of nodes, the EMC 2 chip is seen as anothernode inside the nest. The EMC 2 chip and all thenodes in a nest are fully connected through a cHTinterconnect. The different nests are connected by anInfiniBand switch fabric and they communicate usingHNC packets encapsulated into InfiniBand packets.Every cHT packet conveys the information of thetransaction it belongs to: the node that initiated thetransaction (SrcNode), its unit (SrcUnit), and a tag(SrcTag). When the EMC 2 chip has to translate acHT packet into a HNC packet it must include the informationabout the associated transaction. To thisend, it adds to the previous information the nest (SrcNest)where the SrcNode is located. In this way,transactions can also be unequivocally identified outsidea nest.JP2011-204

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Internal PortsExternal PortsFig. 3.IBA/HNC AdaptersPendingCommandQueueMSTETTMSHRControlUnitEHTAcHT Packet AdapterHNC/IBA AdaptersExternal Ports Internal PortsBlock diagram of the EMC 2 chip.On a HNC packet arrival belonging to an externaltransaction (i.e., that initiated outside the nest),the EMC 2 chip has to forward it inside the nest asa cHT packet. To avoid conflicts with the existingcHT packets belonging to internal transactions (initiatedinside the nest), the EMC 2 chip associates thegenerated cHT packet with a new internal transactionthat will have a new SrcTag local to its nestand a new SrcNode (the EMC 2 chip identifier itself).On the other hand, when a cHT packet for thatnew transaction arrives to the EMC 2 chip, the HNCpacket to which it is translated restores the originalidentifiers of the external transaction. To supportthese operations, the Matching Store Table (MST)included in the EMC 2 chip (see Figure 3) keeps thematching between the identifiers of external transactionsand those of the internal ones. The numberof MST entries, and consequently, the number of externaltransactions simultaneously in progress in thenest, is bounded by the maximum number of tagsthat can be generated by the cHT specification (i.e.,32 tags). When the MST is full and a new entrycannot be allocated, the incoming packets will haveto be temporally stored in the Pending CommandQueue.The MST entries created by Broadcast/DirectedProbes are valid until the associated response goesback to the EMC 2 chip. However, the entries allocatedby requests remain until the arrival of thecorresponding Source Done. Due to the limited numberof MST entries, if every MST in the system wasfull of the entries allocated by requests, a deadlockscenario could occur. This is because probes wouldbe unable to allocate new entries, and therefore, thepending requests would never complete. To avoid it,the MST must reserve at least one entry for Broadcast/DirectedProbes.Another function of the EMC 2 chip is to collect allthe responses received as a consequence of a probeand transforming them into just one response packet(if needed). To accomplish this task, the EMC 2 chipuses the MST. However, given that MST entries areonly allocated on the arrival of messages belongingto external transactions, we need another table thathelps the EMC 2 chip to collect the responses associatedto internal transactions. This additional table iscalled Extended Tag Table (ETT) and it has 512 entries(32 tags/node × 4 units/node × 4 nodes/nest).Unlike the MST, it is able to store all the transactionsrequesting an entry in it.B. Extending the HTA FunctionalityTo maintain and extend the functionality of theHTAs as well as to reduce the generated coherencetraffic, every EMC 2 chip includes a directory cachecalled Extended HTA (EHTA), as shown in Figure 3.An EHTA tracks the memory blocks whose home islocated in its nest and that may also be cached in aremote node (outside its nest). However, the EHTAis not aware of the blocks only cached inside its nest.Since a HTA only knows the existence of the nodesinside its nest, when the owner is in a remote node,the HTA will think that it is cached by the EMC 2chip. Therefore, the EHTA included in the EMC 2chip will be in charge of tracking the actual locationof the owner, that is, its nest (ownerNest field) andnode (ownerNode field) identifiers. Given that thereare four HTAs per nest and each one holds 256K entries,we will assume 1M entries for each EHTA (64K16-way sets). Doing so will prevent EHTA from limitingthe number of blocks that can be simultaneouslycached outside the home nest below the limitimposed by the local HTAs themselves.In addition to the information of the owner, theEHTA also includes some information that helps it inthe traffic filtering task. In order to cover a wide setof trade-offs between area requirements and amountof filtered traffic, we propose three different EHTAconfigurations.• The EMC 2 chip with the first configuration,called EMC 2 -Base, includes an EHTA that implementsthe same states as the HTA: EM, O,S1, S. These states, that require just two bitsper entry, are the only information used to filtercoherence traffic.• The second configuration, assumed by theEMC 2 -OXSX chip, adds two additional states,OX and SX, which will require three bits forcodifying all the states. These new states areparticularly intended to turn Broadcast Probesinto Directed Probes when all the remote copiesof a certain block are located in the same nest.Notice that on the arrival to the remote nest,the Directed Probe will be turned again into aBroadcast Probe in case of having to invalidatemore than one copy.• The EMC 2 -BitVector chip, which includes thethird EHTA configuration, adds a bit-vector foreach EHTA entry to the first configuration. Thebit-vector includes a bit for every remote nestin the system, indicating if associated block iscached or not in the corresponding nest. Thisallows replace Broadcast Probes with multicastprobes. Although it is the configuration thatfilters more traffic, it needs one extra bit perremote nest for each EHTA entry what makes itthe most area-demanding approach.Since the three EHTA configurations are quite similarwe only show the protocol transitions dependingon the EHTA states for the EMC 2 -OXSX chip becauseit is the one that achieves a better traffic-areaJP2011-205

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIScenarios depending on the HTA state (rows) and the EHTA state (columns).X EM OX O S1 SX S Iowner out owner inEM no copy in/out- - - - -no copy outld / st:DP→DP ld / st: -owner out owner out owner out owner in owner in owner in owner inOno copy outcopies incopies in owner nest copies outcopies in copies in1 copy outcopies incopies out (1 nest)copies incopies outcopies inno copy outcopies inld:DP→DP ld:DP→DP ld:DP→DP ld: - ld: - ld: - ld: -st:BP→DP st:BP→DP* st:BP→BP st:BP→DP st:BP→DP* st:BP→BP st:BP→Filteredowner in memoryowner in memoryS1 - - -1 copy outno copies in- -no copy out1 copy inld: - / st:DP→DP ld / st: -owner in memory owner in memory owner in memory owner in memoryS - - - 1 copy outcopies incopies out (1 nest)copies incopies outcopies inno copy outcopies inld:- / st:BP→DP ld:- / st:BP→DP* ld:- / st:BP→BP ld:- / st:BP→Filteredowner in memoryI - - - - - - no copy in/outld / st: -StateEMOXOS1SXSITABLE IEHTA States of the EMC 2 -OXSX chip.DescriptionOnly the owner’s copy is cached outside the homenest. Other copies may be cached inside.The owner’s copy is cached outside the home nest.Other copies may be cached either in the home nestor in the owner nest.The owner’s copy is cached outside the home nest.Other copies may be cached in any nest.At most one shared copy is cached outside the homenest.Only shared copies cached outside the home nest, allof them located in the same nest.Only shared copies cached outside the home nest.They can be located in any nest.No valid copy of the block cached outside the homenest.trade-off, as we will discuss in Section V. First, TableI describes the possible EHTA states.Table II depicts the different scenarios that canappear depending on the block state in both theEHTA and the HTA. For each combination, it showsa short description of how the block is cached andthe actions performed (if any) under load and storetransactions. The three possible actions are: (1) noaction, (2) turning a Broadcast Probe into a DirectedProbe, and (3) filtering a Broadcast Probe. Noticethat the bold actions entail a reduction in coherencetraffic. In this table, in/out refers to inside/outsidethe home nest, and ld/st to load/store. DP* meansthat the BP turns into a DP, but only while the DPis transmitted between nests. However, when theDP reaches a nest, the DP is turned into a BP (onlyinside that nest).IV. Simulation EnvironmentWe evaluate our proposals with full-system simulationusing Virtutech Simics [7] extended with theWisconsin GEMS toolset [8], which enables detailedsimulation of multiprocessor systems. For modelingthe interconnection network, we have used GARNET[9], a detailed network simulator included in GEMS.Finally, we have also used the CACTI 5.3 tool [10],assuming a 45nm process technology, to measure thearea required by our proposals.For the evaluation of our proposals, we have firstimplemented the Magny-Cours cache coherence protocol.Then we have designed and implementedTABLE IIISystem parameters.Memory ParametersProcessor frequencyCache block sizeAggregate L1+L2 cachesL3 cacheAverage cache access latency (L1+L2+L3)HT assist (probe filter)HT assist access latencyEMC 2 chip processing latencyMemory access latency (local bank)3.2 GHz64 bytes3MB, 4-way5MB, 16-way2ns1MB, 4-way4ns16ns100nsNetwork ParametersIntra-nest topologyFully-connectedInter-nest topologyHypercubeData message size68 or 72 bytesControl message size4 or 8 bytesHyperTransport bandwidth (16 bits, 6.4GT/s) 12.8GB/sInter-die link latency2nsInter-socket link latency20nsInfiniBand bandwidth (12x, 10Gb/s)12GB/sInter-nest communication (one way)150nsFlit size4 bytesLink bandwidth1 flit/cyclethe behavior and the architecture of three differentEMC 2 chips explained in Section III. We have runsimulations from 8 to 32 dies and with 1 and 2 coresper die. For the Magny-Cours (MC ) system we onlysimulate one nest with 8 dies. For the EMC 2 systemwe simulate 4 dies per nest (plus the EMC 2 chip).The parameters assumed for the systems evaluatedin this work are shown in Table III.We have evaluated our proposal with a severalscientific workloads from the SPLASH-2 benchmarksuite [11]: Barnes (16K particles), Cholesky (tk16),FMM (16K particles), Ocean (514×514 ocean) Raytrace(teapot) and Water-Sp (512 molecules). Allthe experimental results reported in this work correspondto the parallel phase of these benchmarks.V. Evaluation ResultsIn this section, we show how our proposals supportmore than 8 dies while scaling in terms of executiontime. Additionally, we compare the threebridge chips proposed in this paper in terms of networktraffic, cache miss latency, execution time, andarea requirements. Since the number of nodes ofthe evaluated configurations is not enough to fill theMST, we do not perform an evaluation of a systemthat employs the unused die identifiers in the nest toincrease the number of available tags since it is notnecessary.JP2011-206

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Local: 28.6%Remote: 71.4%EM 5.9%OS1SIEM OX O S1 SX S I0.3% 0.2% 2.0%1.4% 0.9%EM 11.2% 5.6% 3.5% 0.8%0.0%0.5%0.3%7.9%0.0%0.0% 0.0% 1.9% 0.0%5.9%0.0%0.2%2.6% 0.0% 0.2% 1.9% 0.2% 0.5% 1.2%0.0% 0.0%0.0%0.0%0.0% 0.0% 0.0% 0.0%2.3%O 0.8% 1.2% 14.7% 0.7% 0.5% 2.3% 0.2% 2.4% 2.7% 7.2% 2.4% 0.3% 0.1% 0.0%S1SIRead: 63.7% Write: 36.3%EM OX O S1 SX S I0.0%0.0% 0.0% 0.0% 0.0%6.7%Fig. 4. Characterization of cache misses according to theHTA (vertical) and EHTA (horizontal) states, read/writemisses, and local/remote misses. Results show the averageof all the evaluated benchmarks. Crossed cells representimpossible combinations of states. The darker the colorof a cell is, the higher the miss percentage is. Larger cellsindicate that the EHTA is not reached, and therefore, thestate can be any one of those covered by the cell.A. Cache Miss CharacterizationFirst of all, it is important to characterize the applicationsin order to get an idea of the percentage ofcache misses that can take advantage of the EHTAfiltering capabilities. Figure 4 shows this characterizationfor a 32-die system with the EMC 2 -OXSXchip, as a representative example (see Table II).Our EMC 2 chips can reduce network traffic onlywhen a write miss happens for a block in O or Sstates in the HTA (i.e., when a Broadcast Probe isreceived). On average for the considered applications,this happens for 21.7% of cache misses in a32-die configuration. Depending on the state in theEHTA, the EMC 2 chip can either filter the BroadcastProbe or convert it into a Directed Probe. Note thatfor the remaining misses, the HTA already filters theprobes.B. Network TrafficFor each Broadcast Probe issued by the homenode, we show in Figure 5 the average number ofBroadcast/Directed Probes that arrive to the dies.This number is plotted for systems from 8 to 32 dies,with one core per die, and for the three EMC 2 chipsproposed and the base Magny-Cours system with 8dies. Without any filtering this number should be8, 16, and 32 for 8-, 16-, and 32-die systems, respectively.Since Magny-Cours does not filter BroadcastProbes (due to write misses), the average numberof probes arriving to a die is always 8. However,for the same system size our protocols reduce thisnumber by filtering some probes. Obviously, whenwe consider 8 dies (i.e., 2 nests), there is only oneremote nest, so all EMC 2 chips behave in the sameway. For larger systems, we can see that the more coherenceinformation the HTA stores, the more trafficit filters. Particularly, for a 32-die system we cansee that the average number of received probes isreduced by 23.6% (24.4/32), 49.7% (16.1/32), andAvg. probes received per BP2520151050MC_8EMC2-Base_8EMC2-OXSX_8EMC2-BitVector_8EMC2-Base_16EMC2-OXSX_16EMC2-BitVector_16EMC2-Base_32EMC2-OXSX_32EMC2-BitVector_32Barnes Cholesky FMM Ocean Radiosity Water-Sp AverageFig. 5. Number of probes received for each broadcast probesent by the home die.Normalized miss latency5.04.54.03.53.02.52.01.51.00.50.0MC_8EMC2-Base_8EMC2-OXSX_8EMC2-BitVector_8EMC2-Base_16EMC2-OXSX_16EMC2-BitVector_16EMC2-Base_32EMC2-OXSX_32EMC2-BitVector_32Barnes Cholesky FMM Ocean Radiosity Water-Sp AverageFig. 6.Normalized miss latency.61.6% (12.3/32) for EMC 2 -Base, EMC 2 -OXSX, andEMC 2 -BitVector, respectively.This reduction in the number of probes receivedby the dies has two consequences: (1) the number ofgenerated probe responses is also reduced, and (2)the network congestion and the coherence controllercongestion decreases. They lead to less time waitingfor Probe Responses, and therefore, shorter cachemiss latency, which will results in improvements inexecution time.C. Execution TimeAs we can see in Figure 6, cache miss latencyincreases when we move from MC 8 to EMC 2 8.This is because the latency for transmitting messagesamong nests is higher than among dies. While inMC 8 there are 8 dies in the same nest, in EMC 2 8the 8 dies are distributed in two nests.On the other hand, when we consider a largersystem, the cache miss latency increases. Nevertheless,we reduce the final execution time becausethe applications can be distributed among more dieswhich considerably reduces the workload of each die.Finally, we can observe the reduction in averagecache miss latency achieved for some EMC 2 chipsfor the 32die configuration. Compared to EMC 2 -Base, EMC 2 -OXSX reduces the average miss latencyby 3.7%, and EMC 2 -BitVector by 5.0%. As we canobserve, this percentage is expected to increase forlarger scale configurations. These reductions in cachemiss latency finally translate into improvements inexecution time.Figure 7 shows the normalized execution timewhen we increase the number of dies. We can seethat, although for the 8-die configuration our proposalsbehave worse than MC 8 (due to the internestlatency), when we extend the coherence domainthrough the bridge chip and allow a higher numberof nodes, the execution time of the applications issignificantly reduced. Particularly, EMC 2 -OXSX 32and EMC 2 -BitVector 32 improve MC by 47% on average.Comparing the three proposals in a 32-diesystem, EMC 2 -OXSX and EMC 2 -BitVector obtainsimilar execution time and slightly improve EMC 2 -Base (≈4%).JP2011-207

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Normalized execution time1.41.21.00.80.60.40.20.0MC_8EMC2-Base_8EMC2-OXSX_8EMC2-BitVector_8EMC2-Base_16EMC2-OXSX_16EMC2-BitVector_16EMC2-Base_32EMC2-OXSX_32EMC2-BitVector_32Barnes Cholesky FMM Ocean Radiosity Water-Sp AverageFig. 7.Normalized execution time.TABLE IVSize of the different bridge chips for 32-die systems.Struct Entries Assoc Entry size AreaETT 128 1 540 bits 0.64mm 2MST 32 1 607 bits 0.23mm 2EMC 2 -Base EHTA 1M 16 tag + 8 bits 25.72mm 2EMC 2 -OXSX EHTA 1M 16 tag + 9 bits 25.97mm 2EMC 2 -BitVec EHTA 1M 16 tag + 15 bits 33.38mm 2D. Area RequirementsThe different EMC 2 chips cover a wide trade-offbetween memory requirements and filtered traffic.This section studies the area of these chips and theirtrade-offs for a 32-die configuration.The three chips differ in the size of the EHTA.Its sizes and those of the ETT and MST are describedin Table IV. The EHTA of the EMC 2 -Baseis the one that less bits needs per entry (the tag plus8 bits including state, owner die, and owner nest).The EHTA of the EMC 2 -OXSX needs an extra bitfor codifying the two additional states. Finally, theEHTA of the EMC 2 -BitVector needs seven extra bitsfor storing the vector of remote nests.Figure 8 plots the trade-off of these three chips interms of network traffic and area requirements. Thetotal area of each chip has been calculated by addingthe areas (in mm 2 ) of the three data structurespresented in the chip (without considering controllogic). The normalized network traffic correspondsto the average number of flits transmitted by eachswitch in the whole system for the six benchmarksevaluated in this work, and normalized to EMC 2 -Base. We can observe that, EMC 2 -OXSX reducesthe traffic by 10.6% compared to EMC 2 -Base, whileEMC 2 -BitVector reduces the traffic by 15%. Moreover,the area of EMC 2 -OXSX is very close to thearea of EMC 2 -Base. Therefore, we can conclude thatEMC 2 -OXSX achieves a good compromise betweennetwork traffic and area requirements.VI. ConclusionsIn this paper, we have extended by an externallogic (EMC 2 chip) the coherence domain of the AMDMagny-Cours processors beyond the 8-die limit imposedby both the cHT specification and the ownerfield of the HTA. The proposed chip not only maintainsthe HTA capability to filter the coherence trafficover the entire system, but also filters additionaltraffic, which provides the scalability required tobuild large-scale servers. Evaluation results for up toa 32-node system show how the runtime of the applicationsscales with the number of nodes, reducing theapplication runtime by 47% on average (compared tothe 8-die Magny-Cours system).Normalized network trafficFig. 8.1.00.95EMC0.9EMC-OXSX0.85EMC-BitVector0.825 26 27 28 29 30 31 32 33 34 35Area required (mm2)Traffic-area trade-off for a 32-die system.We have proposed and analyzed three EMC 2 chipconfigurations able to provide different tradeoffs betweenfiltered network traffic and required siliconarea. Particularly in a 32-die system, EMC 2 -OXSXachieves a good compromise between network traffic(10.6% of traffic reduction compared to EMC 2 -Base)and reducing area requirements (22.2% of area reductioncompared to EMC 2 -BitVector).AcknowledgementsThis work has been supported by Generalitat Valencianaunder Grant PROMETEO/2008/060, bySpanish Ministry of Ciencia e Innovación under grant“TIN2009-14475-C04-02”, and by European ComissionFEDER funds under grant “Consolider Ingenio-2010 CSD2006-00046”.References[1] Pat Conway, Nathan Kalyanasundharam, Gregg Donley,Kevin Lepak, and Bill Hughes, “Cache hierarchyand memory subsystem of the AMD opteron processor,”IEEE Micro, vol. 30, no. 2, pp. 16–29, Apr. 2010.[2] Patrick Conway, “Computer system with integrated directoryand processor cache,” U.S. Patent 6868485, Mar.2005.[3] SGI, “Technical advances in the SGI Altix UV architecture,”whitepaper, 2009.[4] Jose Duato, Federico Silla, Sudhakar Yalamanchili, BrianHolden, Paul Miranda, Jeff Underhill, Mario Cavalli, andUlrich Brüning, “Extending HyperTransport protocol forimproved scalability,” in 1st Int’l Workshop on Hyper-Transport Research and Applications (WHTRA), Feb.2009, pp. 46–53.[5] Jonathan M. Owen, Mark D. Hummel, Derrick R. Meyer,and James B. Keller, “System and method of maintainingcoherency in a distributed communication system,” U.S.Patent 7069361, June 2006.[6] Anant Agarwal, Richard Simoni, John L. Hennessy, andMark A. Horowitz, “An evaluation of directory schemesfor cache coherence,” in 15th Int’l Symp. on ComputerArchitecture (ISCA), May 1988, pp. 280–289.[7] Peter S. Magnusson, Magnus Christensson, and JesperEskilson, et al, “Simics: A full system simulation platform,”IEEE Computer, vol. 35, no. 2, pp. 50–58, Feb.2002.[8] Milo M.K. Martin, Daniel J. Sorin, and Bradford M.Beckmann, et al, “Multifacet’s general execution-drivenmultiprocessor simulator (GEMS) toolset,” ComputerArchitecture News, vol. 33, no. 4, pp. 92–99, Sept. 2005.[9] Niket Agarwal, Tushar Krishna, Li-Shiuan Peh, and NirajK. Jha, “GARNET: A detailed on-chip networkmodel inside a full-system simulator,” in IEEE Int’lSymp. on Performance Analysis of Systems and Software(ISPASS), Apr. 2009, pp. 33–42.[10] Shyamkumar Thoziyoor, Naveen Muralimanohar,Jung Ho Ahn, and Norman P. Jouppi, “Cacti 5.1,”Tech. Rep. HPL-2008-20, HP Labs, Apr. 2008.[11] Steven Cameron Woo, Moriyoshi Ohara, Evan Torrie,Jaswinder Pal Singh, and Anoop Gupta, “The SPLASH-2 programs: Characterization and methodological considerations,”in 22nd Int’l Symp. on Computer Architecture(ISCA), June 1995, pp. 24–36.JP2011-208

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Efficient hardware support for locksynchronization in Many-core CMPsJosé L. Abellán, Juan Fernández y Manuel E. Acacio 1Abstract—Synchronization is of paramount importance to exploitthread-level parallelism on many-core CMPs.In these architectures, synchronization mechanismsusually rely on shared variables to coordinate multithreadedaccess to shared data structures thus avoidingdata dependency conflicts. Lock synchronizationis known to be a key limitation to performance andscalability. On the one hand, lock acquisition throughbusy waiting on shared variables generates additionalcoherence activity which interferes with applications.On the other hand, lock contention causes serializationwhich results in performance degradation. Thispaper proposes and evaluates GLocks, a hardwaresupportedimplementation for highly-contended locksin the context of many-core CMPs. GLocks use atoken-based message-passing protocol over a dedicatednetwork built on state-of-the-art technology.This approach skips the memory hierarchy to providea non-intrusive, extremely efficient and fair lockimplementation with negligible impact on energy consumptionor die area. A comprehensive comparisonagainst the most efficient shared-memory-based lockimplementation for a set of microbenchmarks and realapplications quantifies the goodness of GLocks. Performanceresults show an average reduction of 42%and 14% in execution time, an average reduction of76% and 23% in network traffic, and also an averagereduction of 78% and 28% in energy-delay 2 product(ED 2 P) metric for the full CMP for the microbenchmarksand the real applications, respectively. In lightof our performance results, we can conclude thatGLocks satisfy our initial working hypothesis. GLocksminimize cache-coherence network traffic due to locksynchronization which translates into reduced powerconsumption and execution time.Keywords— Many-core CMP, lock synchronization,global line.I. Introduction and MotivationWHILE the number of cores currently offeredin general-purpose CMPs has already goneabove ten (e.g., the 12-core 2-die AMD’s Magny-Cours design [1]), the well-known Moore’s Law statesthat soon there will be available on-chip the resourcesrequired to integrate dozens of cores or even hundredsof them. CMPs of this kind are commonlyreferred to as many-core CMPs. For instance, the experimentalresearch microprocessor: 48-core SinglechipCloud Computer [2].If current trends continue, future many-coreCMP architectures will implement the hardwaremanaged,implicitly-addressed, coherent cachesmemory model [3]. With this memory model, allon-chip storage is used for private and shared cachesthat are kept coherent by hardware. Communicationbetween threads is performed by writing to andreading from shared memory. In order to guarantee1 Departamento de Ingeniería y Tecnología deComputadores, Universidad de Murcia, e-mail:{jl.abellan,juanf,meacacio}@ditec.um.esFig. 1. Potential benefits for Raytrace when using ideal locks.the integrity of shared data structures, most currentsystems support synchronization through a combinationof hardware (such as atomic read-modify-writeinstructions like test&set) and software (higher-levelmechanisms such as locks or barriers implementedatop the underlying hardware primitives) [4]. In thisway, implementations of locks usually rely on sharedvariables which are atomically updated.The use of shared variables for lock synchronizationhas two important implications for performanceand scalability in many-core CMPs. First, the cachecoherence protocol must come into play in order tomaintain the consistency of shared variables acrossall levels of the memory hierarchy. Coherence activitytranslates into traffic injection in the interconnectionnetwork. As a result, an ever-growingamount of resources may need to be devoted to supportlock synchronization as the number of coresin many-core CMPs increases. Moreover, lock acquisitionand release operations timing is deeply affectedby the performance and scalability of the cachecoherence protocol especially under the presence ofhighly-contended locks. Second, lock contention haslong been recognized as a key impediment to performanceand scalability since it causes serialization [5].Consequently, the longer the idle time spent on lockacquisition and release operations, the larger the parallelefficiency reduction.As an evidence, we show in Figure 1 the potentialbenefits to performance when lock synchronizationsdo not involve the cache coherence protocol andhave zero latency. To do that, the Raytrace applicationfrom the SPLASH-2 benchmark suite [6] isrun by using distinct lock implementations (for detailsabout the evaluation see Section III). In eachcase, we highlight in gray the fraction of the executiontime due to the locks. Shared-memory-basedlocks use test-and-test&set (see TATAS bar inFigure 1). In turn, ideal locks (see IDEAL bar in Figure1) do not deal with the cache coherence protocolto eliminate any inherited performance or scalabilityside effect. Besides, lock acquisition and releaseJP2011-209

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011operations take a single clock cycle each to minimizeserialization due to contention. As expected, ideallocks clearly outperform shared-memory-based lockssince the lock acquisition and release operations accountfor a significant fraction of the execution timein Raytrace. However, a post-mortem analysis ofRaytrace lock usage reveals that only 2 out of its 34locks are highly-contended. In this sense, if all thelocks other than the highly-contended ones are implementedusing regular shared-memory-based locks,a reduction in the execution time similar to that ofideal locks is obtained (see TATAS-1 and TATAS-2bars 1 in Figure 1). The latter result suggests thatonly highly-contended locks can truly benefit from amore efficient lock implementation.In this paper, we present and evaluate a newlock synchronization mechanism aimed at acceleratinghighly-contended locks. Our proposal, namelyGLocks, leverages existing global lines technology [7]to deploy a dedicated on-chip global-line-based network.To show the benefits derived from GLocks,we evaluate the performance of several microbenchmarksand real applications from the SPLASH-2benchmark suite [6] on a 32-core CMP simulator [8].Performance results show an average reduction of42% and 14% in execution time for the microbenchmarksand the real applications, respectively. Inaddition, they exhibit an average reduction of 76%and 23% in network traffic, for the microbenchmarksand the real applications respectively, given the factthat GLocks do not deal with the main data network.This traffic reduction also leads to an averagereduction of 78% and 28% in energy-delay 2 product(ED 2 P) metric for the full CMP, for the microbenchmarksand the real applications, respectively.The rest of the paper is organized as follows. Wepresent GLocks in Section II. Section III describesour simulation environment and analyzes the performancebenefits derived from GLocks. Finally, SectionIV presents the main conclusions of our work.II. The GLocks MechanismIn this section, we present our proposal to buildan efficient synchronization mechanism for highlycontendedlocks in many-core CMPs.A. G-line-based NetworkThe GLocks mechanism proposed in this work relieson a G-line-based network as can be observedin the example in Figure 2. For simplicity, we concentrateon a version of the proposed network providingsupport for one lock. As can be observed, theG-line-based network is made up of two kind of components.G-lines (horizontal and vertical finer blacklines), that are used to transmit the signals requiredby the synchronization protocol; and controllers (R,Sx and Cx), that actually implement the synchronizationprotocol.1 TATAS-X means that one (X=1) or two (X=2) of thehighly-contended locks have been implemented as ideal locks.Fig. 2. GLocks architecture for a 9-core CMP with a 2D-meshnetwork.On the one hand, every G-line is a wire that enablesthe transmission of 1 bit of information acrossone dimension of the chip in a single cycle. In thisway, the G-line-based network employs one G-lineper transmitter and lock. Every G-line will be usedto request the associated lock and grant lock acquisitions.In this way, for any 2D-mesh layout the totalnumber of G-lines per lock that would be needed isequal to C − 1, where C is the number of cores ofthe CMP (e.g. 8 G-lines for the 9-core CMP shownin Figure 2).On the other hand, we distinguish two types ofcontrollers: the local controllers (Cx in Figure 2)and the lock managers (R and Sx in Figure 2).The local controllers send and receive signals toand from their corresponding lock managers throughtheir dedicated G-lines (e.g. C1 sends and receivessignals to/from S1). The exception is when the localcontroller is located in the same core as its associatedlock manager. In this case, the functionality of thelocal controller is encapsulated in the lock manager,and communication is performed locally by meansof a flag. For example, S1 monitors not only signalsfrom local controllers 1 and 2 (C1, C2) through theircorresponding G-lines, but also from the local corethrough an internal flag (for clarity, this flag is notshown in Figure 2).Finally, to have a clear understanding of our proposal,we represent the architecture described aboveas the hierarchy shown in Figure 3. In particular, theG-line-based network that our proposal is based oncan be represented as a three-level hierarchy. Theroot of the hierarchy is the primary lock manager.The secondary lock managers would be located atthe intermediate nodes. Finally, the leaves of thehierarchy would be the processor cores (with the localcontrollers). All elements are connected usingG-lines (continuous lines) or locally by means of aninternal flag (dashed lines). The flags (fx and fSx)store the signals sent by the controllers to the correspondinglock manager (primary and secondary). Inthis way, we need flags not only to store the signalssent between Sx and the local controllers (one flagper Cx controller: f1 for C1, f2 for C2, etc.), butalso to store the signals transmitted between R andSx (one flag per Sx controller: fS1 for S1, fS2 forS2, etc.).JP2011-210

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Logical view of the G-line-based network for a 9-coreCMP with a 2D-mesh network.(a) All cores request the lock at the same time (cycle 1).B. Synchronization ProtocolThe synchronization protocol implemented on topof the G-line-based network previously described isbased on the exchange of 1-bit messages (signals)between the local controllers and the lock managers.More specifically, the protocol uses three types ofsignals to perform a lock synchronization. The REQand REL signals, which are sent from the local controllersto their corresponding lock manager to askfor the lock and to release the lock, respectively; andthe TOKEN signal which is sent from a lock managerto a particular local controller to grant access to alock. In addition, these signals are also transmittedbetween primary and secondary lock managers in alock synchronization. In particular, the secondarylock managers ask for the lock by sending the REQsignal to the primary lock manager and receive authorizationfrom the latter through the TOKEN signal.Similarly, after the lock is released, a secondarylock manager notifies the primary one by means ofthe REL signal.Lock managers (both the primary and secondaryones) use a round-robin strategy to grant the lockamong those processor cores which are competingfor becoming the next owner. Let’s assume that allof the cores in Figure 3 send the REQ signal to theircorresponding secondary lock manager at the sametime. In this case, the TOKEN signal granting thelock would be received by Core0 first; then, onceCore0 has released the lock, Core1 would becomethe next holder; and so on, until Core8 is reached.Next, the process would start again from Core0 ifthere are additional pending lock requests. Since theGLocks mechanism is aimed at accelerating highlycontendedlocks we do not expect that the election ofthe strategy to grant the lock in these situations willhave an impact on performance. However, this is akey design point to ensure the fairness expected froma lock implementation [4]. The latter is the reasonwhy we use the round-robin strategy.As an example of how the synchronization protocolworks, Figure 4 presents the case where the 9 coresof the CMP depicted in Figure 2 try to get access tothe lock at the same time. To clarify the explanation,the arrows in the figure mark the sense of thetransmissions. Moreover, each arrow is labeled withthe cycle in which communication occurs, startingwith cycle 1. Finally, we highlight with dark grey(b) Lock is granted to Core0 (cycle 4).(c) Core0 releases the lock (cycle m) and S1 designates Core1to be the next lock holder (cycle m+1 ).(d) Core2 releases the lock (cycle p) and S2 designates Core3to be the next lock holder (cycle p+3 ).Fig. 4. Example of lock synchronization under the GLocksmechanism.the flags that are written and the core that acquiresthe lock in each case.At cycle 0, all cores try to get the lock (see Figure4(a)). To do this, every local controller (Cx inthe figure) sends the REQ signal at cycle 1 to thecorresponding secondary lock manager (Sx in thefigure). As a result, all fx flags would be written,and each Cx would be busy-waiting until the TO-KEN signal is received. At cycle 2, once each Sxdetects that at least one of its fi flags has been written,REQ signals towards the primary lock manager(R in the figure) are sent in order to write the correspondingfSx flags. At this moment, R must makea decision about the secondary lock manager thatwill be granted the lock ownership. This process isJP2011-211

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE ICMP baseline configuration.Number of cores 32CoreCache line sizeL1 I/D-CacheL2 Cache (per core)Memory access timeNetwork configurationNetwork bandwidthLink widthTechnology3GHz, in-order 2-way64 Bytes32KB, 4-way, 2 cycles256KB, 4-way, 12+4 cycles400 cycles2D-mesh75 GB/s75 bytes45 nmshown in Figure 4(b). In this case, R would chooseS1 by following the round-robin scheduling policy alreadydiscussed and would send the TOKEN signalat cycle 3. At cycle 4 and based on the round-robinpolicy, S1 chooses Core0 and sends the TOKEN signalgranting access to the lock. Figure 4(c) showsthe scenario in which an Sx can grant the lock ownershipwithout involving any additional notificationsto R. More specifically, once Core0 releases the lockat cycle m, its controller sends the REL signal (bywriting to the local f0 flag, as we mentioned) to S1.Next, at cycle m + 1, S1 grants the lock ownership(by means of the TOKEN signal) to the next coreby following the round-robin policy from the activefx flags. In this case, Core1 becomes the new lockholder. In the same way, Core2 would be grantedthe lock in cycle n + 1 (m < n). Finally, in Figure4(d) we illustrate the scenario when an S finishesits scheduling because either it has reached the lastactive f or there are no more pending local requestsfor the lock. In this case, S must send the REL signaltowards R, which will choose another availableSj lock manager from those that activated the fSxflags. In the figure, S1 sends the REL signal to R atcycle p + 1 (n < p), which following the round-robinpolicy grants the lock to S2. Finally, S2 sends theTOKEN signal giving access to the lock to Core3 atcycle p + 3.III. EvaluationIn this section we give details of our experimentalmethodology and performance results.A. TestbedIn order to support GLocks, the Sim-PowerCMP [8] performance simulator has beenextended. Sim-PowerCMP is a detailed architecturelevelpower-performance simulation tool that simulatestiled-CMP architectures with a shared L2cache on-chip and a MESI directory-based cachecoherence protocol. Table I summarizes the valuesof the main configurable parameters assumed in thiswork.B. BenchmarksTo evaluate the performance benefits derived fromGLocks, five microbenchmarks and three scientificapplications are used. On the one hand, the microbenchmarks(SCTR, MCTR, DBLL, PRCO andACTR) exhibit different highly-contended accesspatterns to shared data that can be commonly foundin parallel applications. To implement the microbenchmarkswe follow a methodology similar tothe one used in [9]. On the other hand, regardingreal applications, we have considered two programsbelonging to the SPLASH-2 benchmark suite [6](Ocean and Raytrace), and a well-known sorting algorithm(QSORT). These applications were chosensince they present a significant lock synchronizationoverhead due to the existence of highly-contendedlocks 2 . In fact, these locks are accessed followingsimilar patterns to those of the microbenchmarks.We summarize the characteristics of the microbenchmarksand applications used in this work in Table II.For each of them we account for the input size, thetotal number of different locks, the number of theselocks that are highly-contended (H-C Locks), andpoint out the highly-contended lock access patternsin terms of the microbenchmarks they are similar to.C. Lock ImplementationsTo fairly quantify the benefits of our GLocks mechanism,we consider the case that highly-contendedlocks found in the benchmarks previously describedare implemented by using MCS Locks. We use MCSLocks because they are considered one of the mostefficient software algorithms for lock synchronizationunder high contention. In particular, MCSLocks gracefully manage high-contention situationsby having a distributed queue of waiting lock requesters.On the other hand, for the rest of locks(non-contended ones), we employ the Simple Lock algorithmenhanced with the test-and-test&set optimizationdue to it has been shown to lead to lowerlatencies when threads try to acquire a lock withoutcompetition. Finally, since the number of highlycontendedlocks is commonly very small in real applications(up to 2 in the applications evaluated inthis work), we assume that two GLocks are providedat hardware level. We would like to point out thatto determine the contention of locks, we performed apost-mortem analysis of the benchmarks under studywhere locks use the Simple Lock algorithm enhancedwith the test-and-test&set optimization. For furtherdetails of this analysis we refer to [10].D. Performance ResultsIn this section, we evaluate the performance benefitsderived from our GLocks mechanism.D.1 Execution TimeFigure 5 shows the execution times that are obtainedfor the set of benchmarks under study wheneither GLocks or MCS Locks are employed for thehighly-contended locks (GL bars and MCS bars respectively).In particular, execution times have been2 In this work, highly-contended locks are those locks accessedby all threads simultaneously or very close in time.JP2011-212

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIConfiguration of the benchmarks and lock-related characteristics.Benchmark Input Size Locks H-C Locks Access PatternSCTR 1,000 iterations 1 1 -MCTR 1,000 iterations 1 1 -DBLL 1,000 iterations 1 1 -PRCO 1,000 iterations 1 1 -ACTR 1,000 iterations 2 2 -RAYTR teapot 34 2 SCTROCEAN 258x258 ocean 3 1 SCTRQSORT 16384 elements 1 1 PRCOFig. 5.Normalized Execution Time.normalized with respect to those obtained whenMCS Locks are used. Additionally, each bar showsthe fraction of the execution time due to lock andbarrier synchronizations (Lock and Barrier categoriesrespectively), memory accesses (Memory category)and computation (Busy category). Finally,average execution times are shown in separate barsfor the microbenchmarks (AvgM ) and applications(AvgA).Regarding the microbenchmarks, we can observethat our proposal presents an average reduction of42% in execution time (see AvgM ). On other hand,the fraction of the execution time that lock synchronizationconsumes is lower when real applications areconsidered (14% on average). In these cases, mostof the time is spent on computations and memoryaccesses (Busy and Memory categories). The exactextent of the reduction in each case depends onboth: the number of highly-contended locks thateach microbenchmark has (see Table II), and alsothe contention rates exhibited by each lock. In moredepth, the time taken to acquire and release the lockis drastically reduced as derived from the improvementsshown in the Lock category. And second, thefact that our proposal removes from the main datanetwork all extra coherence traffic that a sharedmemory-basedlock implementation would introduce,also has effect on the Barrier category for the ACTRmicrobenchmark.D.2 Network TrafficOur proposal does not generate any coherencemessages on the main data network when perform-Fig. 6.Normalized Network Traffic.ing lock synchronizations. At the end, this translatesinto significant reductions in terms of network traffic.Figure 6 shows the total network traffic acrossthe main data network. In particular, each bar plotsthe number of bytes transmitted through the interconnectionnetwork (the total number of bytes transmittedby all the switches of the interconnect) normalizedwith respect to the MCS case. Each bar isbroken down into three categories: Coherence correspondsto the messages generated by the cache coherenceprotocol (e.g. invalidations and Cache-to-Cachetransfers); Request comprehends messages generatedwhen load and store instructions miss in cache andmust access a remote directory; and finally, Replyinvolves the messages with data.For the microbenchmarks, important reductions innetwork traffic are achieved (76% on average). Onthe other hand, the scientific applications exhibitlower reductions in network traffic (23% on average).These network traffic reductions stem from the fractionof the execution time devoted to lock synchronizationand the amount of network traffic that issaved. For instance, Ocean presents the lowest reductionin network traffic since less than 5% of itsexecution time (see Figure 5) is spent on locks.D.3 Energy EfficiencyFinally, we also consider the benefits in energy efficiencythat our proposal entails. More specifically,we present in Figure 7 the normalized energy-delay 2product (ED 2 P) metric for the full CMP. To accountfor the energy consumed by the GLocks architecture(the G-lines-based network described in Section II-JP2011-213

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 7. Normalized energy-delay 2 product (ED 2 P) metric forthe full CMP.A), we extend the Sim-PowerCMP with the consumptionmodel of G-lines and controllers employedin [11].As in the previous two sections, all results in Figure7 have been normalized with respect to the MCScase. As it can be observed, important improvementsin the ED 2 P metric of the whole CMP areachieved when applying our proposal. In particular,the GLocks mechanism brings average improvementsin ED 2 P of 78% and 28% for the microbenchmarksand real applications, respectively. In general, themagnitude of these savings is directly related to theextents of the improvements in execution time andnetwork traffic previously reported. In more depth,GLocks employ less number of instructions executedper lock acquisition and release operation than MCSLocks, since the latter must deal with a distributedqueue of waiting threads requesting the lock, Obviously,less instructions executed means less energyconsumed in the processor cores. Moreover, since wereduce the latency of lock acquisitions, the busy-waitprocess is also shortened with GLocks. Finally, giventhe fact that our proposal skips the memory hierarchy,we save all the energy derived from coherenceactivity when locks are executed. In particular, weremove all of the L1 cache misses related to lock operationsand the corresponding messages transferredacross the interconnect. This brings reductions inthe energy consumed at the L2 cache banks and theinterconnection network.IV. ConclusionsLock contention is recognized as a key constraintto performance and scalability on many-coreCMPs when trying to exploit thread-level parallelism.In this paper we have proposed GLocks, anew hardware-supported implementation for highlycontendedlocks. GLocks deploys a dedicated on-chipnetwork built with existing technology with minimalimpact on energy consumption or die area. The useof a token-based messaging-protocol atop this networkprovides an extremely efficient and completelyfair behavior. Performance results obtained on a simulated32-core CMP with a 2D-mesh data networkfor a set of microbenchmarks and real applicationscorroborate our statements. An average reduction of42% and 14% in execution time, an average reductionof 76% and 23% in network traffic, and an averagereduction of 78% and 28% in the energy-delay 2 product(ED 2 P) metric for the full CMP are achieved, forthe microbenchmarks and the real applications, respectively.As future work, we plan to complete this studyby extending the applicability of GLocks. First,since the current G-line-based network design limitsthe maximum size of the CMP, it becomes necessaryto somehow extend the mechanism to supportlarger CMPs. To do this, there are two possiblepaths to explore: a hierarchical G-line-basednetwork and longer G-line latencies. Finally, thecurrent GLocks mechanism does not consider multiprogrammedworkloads. To deal with them, a fewGLocks could be statically or dynamically sharedamong all of the workloads.AcknowledgmentsThis work was supported by the Spanish MEC andMICINN, as well as European Comission FEDER funds, underGrants “CSD2006-00046” and “TIN2009-14475-C04”. José L.Abellán is supported by fellowship 12461/FPI/09 from FundaciónSéneca - Agencia de Ciencia y Tecnología de la Regiónde Murcia (II PCTRM 2007-2010). Finally, we would like tothank Fabrizio Petrini for his invaluable contribution at theearly stage of this work.References[1] P. Conway, “Blade Computing with the AMD Magny-Cours Processor,” in Proceedings of the 21 st Symposiumon High Performance Chips, 2009.[2] Single-chip Cloud Computer. [Online]. Available:http://techresearch.intel.com/articles/Tera-Scale/1826.htm[3] J. L. et al., “Comparing Memory Systems for Chip Multiprocessors,”ACM SIGARCH Computer ArchitectureNews, vol. 35(2), pp. 358–368, 2007.[4] D. E. C. et al., Parallel Computer Architecture: A Hardware/SoftwareApproach. Morgan Kaufmann, 1998.[5] N. R. T. et al., “Analyzing Lock Contention in MultithreadedApplications,” in Proceedings of 15 th ACMSIGPLAN Symposium on Principles and Practice ofParallel Programming, 2010.[6] S. C. W. et al., “The SPLASH-2 Programs: Characterizationand Methodological Considerations,” in Proceedingsof 22 nd International Symposium on Computer Architecture,1995.[7] R. C. et al., “Near Speed-of-Light Signaling over On-ChipElectrical Interconnects,” IEEE Journal of Solid StateCircuits, vol. 38(5), pp. 834–838, 2003.[8] A. F. et al., “Sim-PowerCMP: A Detailed Simulator forEnergy Consumption Analysis in Future Embedded CMPArchitectures,” in Proceedings of 21 st International Conferenceon Advanced Information Networking and ApplicationsWorkshops, 2007.[9] R. R. et al., “Transactional Lock-free Execution of LockbasedPrograms,” in Proceedings of 10 th Annual Conferenceon Architectural Support for Programming Languagesand Operating Systems, 2002.[10] J. L. A. et al., “GLocks: Efficient Support for Highly-Contended Locks in Many-Core CMPs,” in Proceedingsof the 25 th IEEE International Parallel & DistributedProcessing Symposium, 2011.[11] T. K. et al., “NoC with Near-Ideal Express Virtual Channelsusing Global-Line Communication,” in Proceedingsof 16 th IEEE Symposium on High Performance Interconnects,2008.JP2011-214

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A Cooperative and Scalable Built-In Self-TestArchitecture for NoCsC. Gómez, M.E. Gómez, P. López, J. Duato 1 , A. Strano, D. Ludovici, M. Favalli, D. Bertozzi 2Abstract— This paper proposes a built-in self-test/self-diagnosisprocedure at start-up of an on-chip network (NoC). ConcurrentBIST operations are carried out after reset at each switch, thus resultingin scalable test application time with network size. The keyprinciple consists of exploiting the inherent structural redundancyof the NoC architecture in a cooperative way, thus detecting faultsin test pattern generators too. At-speed testing of stuck-at faultscan be performed in less than 1200 cycles regardless of their size,with an hardware overhead of less than 11%.Keywords—Network-on-Chip, Test Pattern Generation.I. INTRODUCTIONNoCs are rapidly becoming the reference communicationfabric for multi-core computing platforms both inhigh-performance processors and in many embedded systems[7], [3]. As the integration densities and the uncertaintiesin the manufacturing process keep increasing,complementing NoCs with efficient test mechanisms becomesa key requirement to cope with high defect rates[6], [11]. Above all, the NoC testing infrastructure shouldnot be conceived in isolation, but should be coherently integratedinto a reliability framework taking care of faultdetection, diagnosis and network reconfiguration and recoveryto preserve yield [9].Moreover, wear-out mechanisms such as oxide breakdown,electro-migration and mechanical/thermal stressbecome more prominent in aggressively scaled technologynodes. These breakdown mechanisms occur overtime, therefore the methodology and the infrastructureused for production testing should be designed for re-useduring the system lifetime as well, thus enabling gracefuldegradation of the NoC over time.The detection and identification of failures is the foundationof any reliability framework. Unfortunately, developingsuch a testing infrastructure for a NoC is a seriouschallenge. The controllability/observability of NoClinks and sub-blocks is relatively reduced, due to the factthat they are deeply embedded and spread across the chip.Also, pin-count limitations restrict the use of I/O pinsdedicated for the test of the different NoC components.A number of other concerns were raised in [10] on theuse of external testers for nanoscale chip testing: lack ofscalability of test data volumes, high cost for full clockspeed testing, poor suitability for the extension of productiontesting to lifetime testing. As an effect, a migrationfrom external testers to built-in self-test (BIST)infrastructures was envisioned in [10], and was later confirmedby the large amount of works in the open literaturetargeting scalable BIST architectures for NoC testing [2],[22], [17]. At the same time, the limited fault coveragethat functional and pseudo-random testing can achieve onthe control path of NoC switches when test generatorsare outside the switch has further pushed the adoption ofBIST units at least for such control blocks [8].In this direction, this paper relies on a full BIST strategyfor NoC testing. A key principle of our approachconsists of exploiting the inherent structural redundancyprovided by NoCs. Each switch is comprised of inputports, output ports, arbiters and FIFOs that are duplicatedfor each channel. This feature is used to develop a veryeffective test strategy which consists of testing multiple1 Dept. of Computer Engineering, Universidad Politecnica de Valencia,Spain.2 ENDIF, University of Ferrara, 44100 Ferrara, Italy.identical blocks in parallel and of cutting down on thenumber of test pattern generators. This is done both at theabstraction level of the switch micro-architecture (e.g.,testing of the output port arbiters in parallel) and of theNoC architecture (i.e., testing of all NoC switches in parallel).The inherent parallelism of our BIST proceduremakes our testing infrastructure highly scalable and bestsuited for large network sizes.Four main features differentiate our testing frameworkfrom most previous work. First, we take on the challengeof generating deterministic test vectors on-chip ata limited area overhead. At the same time, this enablesus to report much shorter test application times than typicalpseudo-random testing frameworks and larger faultcoverage in the control path than most functional testingframeworks for NoCs. Second, we account for thetedious problem of faults affecting test pattern generators(TPGs) and provide large coverage for them. This isdone without implementing more hardware redundancybut fully exploiting the existing one by means of a cooperativetesting framework among switches. Third, ourtesting framework targets double and triple stuck-at faultsfrom the ground up, and not as an afterthought, in additionto an almost 100% coverage of single stuck-atfaults. Fourth, our framework is not limited to regular2D meshes, but can be applied to a much wider range ofnetwork topologies.Our BIST procedure is suitable both for productionand for lifetime testing, and is complemented by a builtinself-diagnosis logic distributed throughout the networkarchitecture able to pinpoint the location of detectedfaults in each switch. This diagnosis outcome matchesthe reconfigurability requirements of logic-based distributedrouting and is therefore the stepping stone intoa novel network reconfiguration strategy that will be developedin future work.II. PREVIOUS WORKConsidering the regular and modular structure of onchipnetworks, test strategies previously proposed for systemswith identical cores [14], [23] can be applied tothe NoC. However, both approaches incur a significantoverhead for DfT structures (full-scan and IEEE 1500wrapped cores with registered I/O pins).It is showed in [13] that traditional full-scan andboundary scan strategies like [18], [21], [15], [17] incuran hardly affordable area overhead. [13] also proposes apartial scan technique in combination with an IEEE 1500-compliant test wrapper. Area overhead is greatly reduced,but test application times amount to tens of thousandsof clock cycles and test pattern generation time does notscale.As opposed to using scan paths and wrappers for testaccess, [4] considers the case where test patterns are appliedat the border I/Os of the network. The method wasthen extended in [5] to support fault diagnosis, while theDfT infrastructure was developed in [8]. While very highfault coverage was achieved, the time complexity of thetest configurations is square with respect to the rank ofthe NoC matrix. Moreover, in order to apply test patternsfrom network boundaries at-speed, a large number of testpins are necessary.In [19], it is proposed to add dedicated logic to enableJP2011-215

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011INPUT WESTINPUT EAST...LBDR WESTLBDR EASTARBITER NORTHARBITER SOUTH...OUTPUT NORTHOUTPUT SOUTHFig. 1. Modular structure of the baseline switch architecture. Not allconnections are showed.analysis of response from each FIFO in the switch, howeverno test data is presented. In [16] the possibility torepair the NoC during testing is envisioned, however errorinformation is computed once for all and thus cannothandle situations where the chip slowly degrades.[20] proposes a built-in self-test and self-diagnosis architectureto detect and locate faults in the FIFOs and inthe MUXes of the switches. Unfortunately, the controlpath is left out of the framework.In [2] an automatic go/no-go BIST operation is proposedat start up of a 2D mesh NoC. Low fault coverage isachieved for the switch controller, moreover the methodologyapplies only to a 2D mesh. That idea is evolved in[12], where a fault coverage close to 100% is documentedwith a few thousand clock cycles. However, the area costof the BIST architecture is the main concern of this work.The pattern based testing section from the more generalreliability framework presented in [9] reports a testingmethodology relying on random test pattern generationand signature analysis. Unfortunately, testing takesas large as 200000 cycles with 10000 patterns per test.With respect to previous work, we claim a more efficientuse of NoC structural redundancy for testing anddiagnosis purposes through the use of a cooperative testingframework. With respect to scan-based approaches,we reduce area overhead while at the same time detectingTPG faults. With respect to functional testing solutions,we provide efficient testing of the control path as welland provide better test time scalability. With respect topseudo-random testing, we cut down on the test applicationtime. We also take on the challenge pointed by [2] ofexploiting architecture behavior knowledge to come upwith a set of customized test patterns for NoC components.III. TARGET ARCHITECTUREWithout lack of generality, we use the xpipesLiteswitch architecture [1] to prove viability of our testingmethodology in a realistic NoC setting. The baselineswitch architecture is illustrated in Fig.1. It implementsboth input and output buffering and relies on wormholeswitching. The crossing latency is 1 cycle in the link and1 cycle in the switch itself. Flit width assumed in this paperis 32 bits, but can be easily varied. Without lack ofgenerality, in this paper the size of the output buffers is 6flits, while it is 2 flits for the input buffers.This switch relies on a stall/go flow control protocol. Itrequires two control wires: one going forward and flaggingdata availability (”valid”) and one going backwardand signaling either a condition of buffer filled (”stall”)or of buffer free (”go”).The switch architecture is extremely modular and exposesa large structural redundancy, i.e., a port-arbiter,a crossbar multiplexer and an output buffer are instantiatedfor each output port, while a routing module is cascadedto the buffer stage of each input port. This commonfeature to all switch architectures will be intensively exploitedin this work.We implement distributed routing by means of a routeselection logic located at each input port. Forwardingtables are usually adopted for this purpose, although...they feature poor area and delay scalability with networksize [24]. The possibility to implement logic-based distributedrouting (LBDR) while retaining the flexibility offorwarding tables has been recently demonstrated in [26].In practice, LBDR consists of a selection logic of the targetswitch output port relying on a few switch-specificconfiguration bits (namely routing R xy , connectivity C zand deroute bits dr t ). The number of these bits (14 inthis case) is orders of magnitude less than the size of aforwarding table, yet makes the routing mechanism reconfigurable.Our testing and diagnosis framework has been conceivedto enable a network reconfiguration strategy leveragingthe cost-effective flexibility offered by the LBDRrouting mechanism. An algorithm is reported in [26] forcomputation of the switch configuration bits given thetopology connectivity pattern. This algorithm might beexecuted by a centralized NoC manager and in practiceneeds the list of failed links to recompute the configurationbits for correct routing with the available communicationresources. Failure of a switch input or output portcan be viewed as the failure of the connected link. Ourdiagnosis strategy will therefore target this requirementand will provide an indication of whether input and outputports of a switch are operational.IV. BUILT-IN SELF-TEST/DIAGNOSIS FRAMEWORKThe key idea of our BIST/BISD framework consistsof exploiting the inherent structural redundancy of anon-chip network. We opt for testing the NoC switchesin parallel, thus making test application time independentof network size. Communication channels betweenswitches are tested as a part of the switch testing framework.Each switch can in turn test its manyfold internal instancesof the same sub-blocks (crossbar muxes, communicationchannels, port arbiters, routing modules) concurrently.In fact, all the instances are assumed to be identical,therefore they should output the same results if thereis no fault. As a consequence, the test responses fromthese instances are fed to a comparator tree. This makesthe successive diagnosis much easier. There is a uniquetest pattern generator (TPG) for all the instances of thesame block, thus cutting down on the number of TPGs.Although the principle is similar to what has been proposedin [14], [22], [13], there is a fundamental difference.If the TPG of a set of block instances is affectedby a fault, then the comparison logic will not be able tocapture this since all instances provide the same wrongresponse. To avoid this, a cooperative framework is devised,such that each switch tests the block instances ofits neighboring switches.As an example, a switch tests the incoming communicationchannels from its north/south/west/east neighbors(i.e., it feeds their test responses to its local comparatortree), thus checking the responses to distinct instances ofthe same TPG. This way, a non-null coverage of TPGfaults becomes feasible. Fig.2(a) clearly illustrates thecooperative testing framework for communication channelsand the need for a single TPG instance per switchto feed test patterns to all of its output ports. Faultsin the TPG, in the output buffer, in the link and in theinput buffer will be revealed in the downstream switch.Each switch ends up testing its input links, while its outputlinks will be tested by their respective downstreamswitches.The same principle can be applied for the testingof switch internal block instances associated with eachoutput port: crossbar muxes and output port arbiters.Fig.2(b) shows the case of port arbiters. The main requirementfor testing these instances is that the communicationchannels bringing test responses to the compara-JP2011-216

OUTLBLBActas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TPGTPGTPGSOUTHARBITERDRTPGBUFLINKINBUFCHANNELCOMPARATORTPGTPGEASTARBITERARBITERCOMPARATORWESTARBITERTPGTPGLBDRLBDRCOMPARATORLBDRTPGDRNORTHARBITERTPGTPGTPG(a) Testing communication channels.(b) Testing output port arbiters.(c) Testing LBDR routing logic.Fig. 2. The cooperative and concurrent testing framework saving TPG instances and covering their faults.UPSTREAM SWITCHDOWNSTREAM SWITCHtors in the downstream switches are working correctly.TO LOCALCOMPARATORSTO COMPARATORSClearly, testing these modules can only occur after communicationchannels have been tested. Therefore, thevalidOutput BufferInput Bufferprocedures in Fig.2(a) and Fig.2(b) occur sequentially inTPGDatastall_channel(normal)stall_outstall_in stall_in (normal) stall_channeltime. Should one communication channel result defective,this would not be a problem, since it would not make stall_channelsFrom localTPGof local input portsstall_in (testing)any sense to test and use a port arbiter when the correspondingport is not operational. Crossbar multiplexersstall_channel (testing)associated with each output port are tested in the sameFig. 3. Practical implementation of communication channel testing.way and are hereafter not illustrated in Fig.2 for lack ofspace.the fault may be located either in the input buffer or in theFinally, the methodology can be extended to test block LBDR module, in the connected communication link orinstances associated with each switch input port with even in the output buffer and associated port arbiter andsome modifications. This is the case of the LBDR routing crossbar multiplexer of the upstream switch. This furtherblock. The key idea to preserve the benefits of cooperativeand concurrent testing is to carry test patterns rather ing is that the link is unusable, and this is enough forlevel of detail is not needed, since in any case the mean-than test responses over the communication channels to a global controller to recompute the reconfiguration bitsneighboring switches, where the LBDR instances are for the LBDR mechanism.stimulated and their responses compared (see Fig.2(c)). In the final implementation, other 5 bits will be neededIf the channel is not working properly, then testing and to code the diagnosis outcome because of practical implementationissues, as discussed in section IV-A.use of the downstream routing block is useless, since it isassociated with an input port which will not be used. Common to most current NoC testing frameworks,A BIST engine is embedded into each switch and regulatesthe testing procedure. This latter is in fact splitthe underlying assumption for correct operation of ourBIST/BISD infrastructure is that the reset signal can beinto four phases in time: testing of communication channels,testing of the crossbar, testing of the arbiters, test-synchronously deasserted in all switches of the networkat the same time.ing of the LBDR routing blocks. The serial executionof test phases for the switch internal components is dictatedprimarily by the limited flit width, constraining the Communication channels include input/output buffersA. Testing communication channelsamount of test patterns that can be transmitted at the same and their intermediate links, as illustrated in Fig.3: alltime over the communication channel, and also by the these elements are jointly tested by means of a singlelimited availability of comparators, although in our case TPG and the test patterns are handcrafted for them basedthe former effect comes into play first. As the flit width on knowledge of their behavior.increases, then we can perform more testing operations Our approach in this direction was to expand the finitestate machine (FSM) of the device under test (DUT)in parallel, starting from those components that have alimited amount of primary input/outputs (e.g., the arbiter into all its possible states. Therefore, we have definedwith the LBDR).a sequential test pattern that drives the FSM to each ofA fundamental difference with respect to a lot of previouswork is that we do not rely on pseudo-random testing reaches the expected state for all the test patterns thereits states. In this way, we can ensure that if the FSM(like in [9]), which gives rise to large testing times. We are no faults inside the DUT. As an example, the FSM ofuse deterministic test patterns instead, which are handcraftedfor the specific block under test by exploiting the buffer receives a set of valid flits, the buffer has tothe buffers defines that if the Stall signal is asserted andknowledge of the architecture behavior. This way, the store the flits that it receives until it becomes full. Onereduced number of test patterns enables the serialization test pattern to check this behavior would fill up the bufferof test phases without making test application time skyrocket(see section V-A).whether the output buffer correctly asserts the Full signal.by asserting the Stall signal, and would in the end checkOn a cycle by cycle basis, comparator outputs are fed The datapath is obviously much easier to test by means ofto a diagnosis logic which identifies where exactly the only few test patterns.fault occurred. In our diagnosis framework, each switch From an implementation viewpoint, there are severalchecks whether test responses from its input ports are corrector not. As a consequence, the outcome of the diagno-input of the output buffer directly controllable to the TPGpractical issues. On one hand, we had to make the stallsis is coded in only 5 bits, one for each input port of the to raise its stuck-at fault coverage to almost 100% (seecurrent switch (they would be of course doubled if a tworailcode is implemented to protect them against stuck-at On the other hand, the stall channel signal of the in-Fig.3).faults). A ’1’ indicates that the port is faulty. In practice, put buffer, which lies in the downstream switch, shouldJP2011-217

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TEST PATTERNCOUNTERNEXT PATTERNCLOCK CYCLECOUNTER100101..100010..001100..111001..100011..000001..110101..000111..111110..OUTPUT BUFFER STALLINPUT BUFFER STALLOUTPUT BUFFER WRITEBUFFER INPUT DATADUT RESETFig. 4. TPG for communication channels.be driven by the TPG as well. This would require anadditional wire in the switch-to-switch link. A similarconcern is that the stall out signal from the output buffershould be brought to the comparators in the downstreamswitch, again requiring an additional wire in the link.To avoid the extra wires, we opted for the solution inFig.3: stall channel is driven by the TPG of the downstreamswitch, while stall out is brought to the comparatortree in the upstream switch. From the testing viewpointnothing changes, since all channel TPGs inject thesame patterns synchronously, and so do the comparators.The only difference lies in the fault coverage of TPGfaults, which is likely to be decreased a bit. In fact, those(upstream) TPG faults that can be detected by only monitoringstall out will not be detected, since all the stall outsignals brought to the local comparators will be driven bythe same TPG. Similarly, some faults in the (downstream)TPG will not be detected, since the comparators compareresponses to stall channel signals generated by the samefaulty TPG: the responses will look like the same. Theseimplementation variants, needed to adapt the conceptualtesting scheme to the constraints of the real implementation,will be proven in section V-A to only marginallydecrease fault coverage of the TPGs, while leaving faultcoverage for the communication channel obviously unaffected.The only major implication is that the fault detectionframework becomes even more collaborative: some (veryfew) faults in the channel and/or TPGs are now detectedin the upstream switch comparators instead of the downstreamones. Therefore, other 5 additional diagnosis bitsare needed, flagging a fault in the output port of a switch.The global controller will combine this (OR operation)with the faults detected at the input port of the downstreamswitch to get the complete indication of a faultacross the entire channel.B. TPG for communication channelsA test pattern can be easily generated in hardware byusing a clock cycle counter and some logic to generatethe values of the input signals for the DUT. In order toextend this approach to a TPG able to generate all the testpatterns for a given DUT, we can include an additionalcounter. This latter will indicate the current test patternwithin the test sequence. Figure 4 depicts the resultingconceptual scheme for the channel TPG. The actual gatelevelimplementation depends on the logic synthesis tooland on the synthesis constraints. The two counters act asa FSM driving the control signals of two levels of multiplexing:the first one selects the current test pattern, whilethe second one selects the current clock cycle and associatedinput vector for the buffer.It is however possible to easily compact the combinationallogic, because there are a lot of test patterns thatinclude other test patterns. For instance, by checking theresponse not only at the end of the test pattern, but alsosomewhere in the middle, it is often possible to detectanother fault. This perfectly matches with the capabilityof our BIST framework, which even performs check responseat each clock cycle. Therefore, it is possible in ourimplementation to perform a compaction of test patternsby generating in hardware only those patterns including asubset of the other ones, thus largely saving test time andTPG area.C. Testing Other Internal Switch ModulesA similar process is followed to generate deterministictest patterns for the port arbiters, the LBDR modules andthe crossbar. Also the implementation of their TPGs isidentical, and so are the optimization techniques.Again, the most relevant practical implementation issueconcerns the communication of test patterns or responsesacross the switch-to-switch links for the crossbarand LBDR module. The crossbar outputs 34 bits in responseto a test vector: 32 data bits, 1 valid bit and 1stall bit. The communication channel can only carry 32bits (the valid bit of the channel needs to be permanentlyset to 1 during test vector transmission, while the stallsignal travels in the opposite direction). The two remainingcrossbar signals (valid and stall) which do not fit intothe link can be either transmitted by means of additionallines used only during testing, or alternatively checkedby local comparators, similarly to what has been done forthe communication channel. We took the latter approach,and the results in section V-A again confirm the marginalcoverage reduction on TPG faults. Fault coverage of thecrossbar is not affected at all by this choice.Unlike other modules, test vectors for the LBDR modulesshould be transmitted across the link, and they take31 lines (the primary inputs of the LBDR module). So,they perfectly match with the current flit width, providedthe number of network destinations does not exceed 64.From there on, the test vector width starts growing logarithmicallywith the number of destinations, and additionallines may be required on the link.In contrast, the use of a larger flit width in the network(e.g., 64 bits) would automatically solve the problem. Inthat case, the test patterns of the LBDR block and the testresponses of the arbiter could even be communicated atthe same time over the link. Also, since LBDR moduleand arbiters have only few outputs, their response checkingcould be performed at the same time on the availabletree of comparators, thus cutting down on the test applicationtime (see section V-A).D. Fault detection and diagnosisThe core of the diagnosis unit is given by comparatorswhich can be implemented in two different ways, by usinga level of XORs and an OR gate to provide a singleoutput encoding of the equality test, or by using a two-railchecker TRC (with the second word which is negated).We opted for the TRC approach, which achieves the selftestingand fault-secure properties [27] although leadingto a more complex circuit.In the diagnosis unit we use 10 different comparatorsto compare data from all the possible pairs of switch inputports. A smaller number of comparators could be used.Unless time multiplexing is exploited, this would tradecost for diagnosis capability. The maximum number ofusable comparators also depends on the number of switchI/O ports. In what follows, we will focus on the internalswitches of a 2D mesh for the sake of simplicity (featuring5 I/O ports, including the local connection to thenetwork interface), however all irregular topologies supportedby LBDR and making use of switches with at least3 I/O ports are suitable for our methodology. Obviously,the lower the number of ports, the lower the diagnosiscapability.If we denote two faults in different ports under comparisonas equivalent if they produce the same output sequencein response to the same input stimuli, then ourJP2011-218

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110FAULTY INPUT PORT N0FAULTY OUTPUT PORT N70000BISTINPUT BUFFERNORTHfromallinputportsTOCOMPARATORSCOMPARATORSfromallinputportsTOCOMPARATORSLBDR_NIN_NN_REQ_NARBITERTPG(in inputs_N)DIAGNOSISCROSSBARTPGinputs_Ninputs_SIN_NIN_S0000FAULTY INPUT PORT SFAULTY INPUT PORT WFAULTY INPUT PORT EFAULTY INPUT PORT FROM NI..N_stall_N.N_stall_SARB_NCROSSBARTPGCHANNELTPGFAULTY OUTPUT PORT TO NILBDRTPGN_stallCROSSBARTPGB I S T E N G I N E0000CROSSBAR MUXNORTHFAULTY OUTPUT PORT SFAULTY OUTPUT PORT WFAULTY OUTPUT PORT EFig. 5. BIST-enhanced switch architecture.OUTPUT BUFFERcomparator and diagnosis logic is able to: diagnose thecorrect position of 1 or 2 faulty channels affected byequivalent or non-equivalent faults; diagnose the correctposition of 3 faulty channels affected by non-equivalentfaults; detect the presence of 4 and 5 faulty channels.Anyway, since a 5x5 switch affected by 4 or 5 faults hasto be discarded, we don’t distinguish between these twoscenarios.One might argue that when a communication channelfails, then the following testing phases have less inputsavailable and diagnosis capability reduces. In practice,this effect plays only a minor role, since a fault on a communicationchannel means that also (say) the arbiter ofthat channel should be considered faulty (unusable). So,the diagnosis capability reduces, but also the number ofinput ports to be checked reduces as well.When a switch features only three I/O ports, then thedetection and diagnosis capabilities change as follows.Single stuck-at faults can be diagnosed while doublefaults can be detected, provided they are not equivalent.If they are equivalent, then diagnosis fails. However,when two faults are detected in two ports out of three,the switch should be discarded anyway.As regards the possible presence of faulty comparators,let us first note that any input vector producing less thanfour ones corresponds to faults in less than four comparators(we are neglecting the case where all 5 channels arefaulty and 4 of them have equivalent faults, which is veryunlikely). In case the number of faulty comparators islarger than 3, some configuration exists which may producea wrong diagnosis. Let us note, however, that it issufficient to have a single test vector (not a test sequence)featuring less than four ones to immediately recognizethe presence of faulty comparators because no combinationof faulty channels may produce such response.E. BIST-enhanced switch architectureThe switch architecture enriched with the BIST infrastructureis illustrated in Fig.5. Only one section is reported.The figure is necessarily at a high abstractionlevel, and signal-level connection details previously illustratedin sections IV-A and IV-C are purposely omitted.A test wrapper consisting of multiplexers can beclearly seen, which enables test pattern injection of TPGsin the modules they test. At the output of the input buffer,test patterns are directly fed to the LBDR module, sincethey are carried by the communication channel as normalnetwork traffic. A multiplexer in front of each outputbuffer selects between the switch datapath, the test patternsfrom the LBDR TPG (feeding the LBDR module ofthe downstream switch), the channel TPG (directly feedingthe channel) and the arbiter test responses (checkedin the downstream switch). A BIST engine drives the 4NORTHSwitch Area(um2)6000050000400003000020000100000VANILLA500MHzBISTVANILLA700MHzFig. 6. Area overhead for BIST implementation as a function of targetspeed.100,0%90,0%80,0%70,0%60,0%50,0%40,0%30,0%20,0%10,0%0,0%JP2011-219CHANNEL TPG (ideal) CHANNEL TPG (real) ALLOCATOR TPG LBDR TPG CROSSBAR TPG (ideal) CROSSBAR TPG (real)Fig. 7. Coverage of TPG faults.phases of the testing procedure by acting upon the controlsignals of the test wrapper.During the first three phases (communication channel,crossbar, arbiter testing), outputs of the input buffers areselected to feed the comparator tree, while in the lastphase (LBDR testing), all LBDR outputs are selected.Test response check and diagnosis are performed at eachclock cycle, and result in the setting of 10 bits, indicatingwhether each input/output port is faulty or not.V. EXPERIMENTAL RESULTSWe performed placement-aware logic synthesis andplace&route of a 5x5 switch on an industrial 65nm technologylibrary. The baseline switch architecture of Fig.1is compared with its BIST-enhanced counterpart. Synthesizingfor maximum performance gives approximatelythe same maximum (post-layout) operating speed of 700MHz for both architectures, thus proving that our BISTenabledswitch is capable of at-speed testing.Fig.6 shows the area overhead for BIST implementationas a function of the target speed. Area overhead is11%, which peaks at 21% when maximum performanceis required. In this latter case, the multiplexers on thecritical path are primary targets for delay optimization inexchange for more area.When considering the BIST infrastructure in isolationmost of the overhead comes from the on-chip generationof test patterns (almost 31%) and from the multiplexers(44%) of the test wrapper. Interestingly, although arbitersand LBDR require less test vectors than the communicationchannel, their TPGs are far more complex due tohigher irregularity of their test patterns.Switch sub-block Test patterns Test vectors CoverageComm. channel 58 464 99.4%Arbiter 82 328 97.1%Crossbar 72 72 99.8%LBDR 240 240 98.7%TABLE ICOVERAGE FOR SINGLE STUCK-AT FAULTS.Test CycleCoverageOur 864 - 1104 99.3%[20] 3.88 x 10 2 - 2.89 x 10 3 97.79%[21] 4.05 x 10 5 95.20%[12] 2.74 x 10 3 99.89%[13] 9.45 x 10 3 - 3.33 x 10 4 98.93%[22] 5 x 10 4 - 1.24 x 10 8 N.A.[8] 320 99.33%[9] 200 x 10 3 full (no exact numbers)TABLE IITEST APPLICATION TIME AND COVERAGE OF DIFFERENT TESTINGMETHODS.

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Multiplicity of Fault Injection 2 3 4 5Coverage 99.2% 96.4% 96.6% 96.6%TABLE IIICOVERAGE FOR MULTIPLE RANDOM STUCK-AT FAULTS.A. Fault CoverageTab.1 reports the total number of deterministic test patterns(and test vectors) generated for each tested module,and the associated coverage. This latter was derived bymeans of an in-house made gate-level fault simulationframework: (one or more) faults are applied to any or selectedgate inputs, then our testing procedure is run on theaffected netlist and the diagnosis outcome is comparedwith the expected one.It can be seen that in all cases the coverage for singlestuck-at faults closely tracks 100%. The number of testvectors provides the test application time (in clock cycles).A network with a flit width of 32 bits, as assumedso far, would therefore take 1104 clock cycles for testing,regardless of the network size. If we assume 64 bit flits,then LBDR testing occurs in parallel with arbiter testingand total test time reduces to 864 cycles.These numbers compare favorably with previous work,as Tab.2 shows. Only [20] and [8] in some cases do better.However, [20] does not test the control path while [8]reports 320 cycles for a 3x3 mesh (made of a simplifiedswitch architecture) which however grow linearly withnetwork size. Also, this latter approach makes additionaluse of BIST logic for the control path not accounted forin the statistics.We feel that area overhead is hardly comparable withprevious work since whenever numbers are available, featuresof the testing frameworks are very different (e.g.,control path not tested [20], test patterns generated externally[21], [13], diagnosis missing [21], [12], [13], [22],lack of similar test time scalability [4], [8], NoC architecturewith overly costly links [12]). Moreover, the impactof synthesis constraints is never discussed.Fig.7 reports the coverage of TPG faults. While singlestuck-at faults in the allocator and channel TPGs featurea coverage of roughly 95%, worse results are obtainedfor the LBDR and especially for the crossbar TPGs. Weverified that their lower coverage is a direct consequenceof the low number of test patterns they generate. The designercan then choose whether increasing crossbar TPGarea and having it generate more patterns or dedicating aseparate test phase to TPGs. Also, when comparing realvs ideal coverage of channel and crossbar TPGs, it is possibleto assess the marginal reduction of TPG fault coverageas an effect of the local (instead of remote) check ofsome signals of these modules in the switch they belongto (see section IV-A and IV-C).Since our BIST infrastructure targets multiple stuck-atfaults from the ground up, we characterized fault coveragefor multiple faults as well. We have injected multiplefaults randomly in the gate-level netlist of the switch andchecked the diagnosis response. Fault multiplicity was2,3, 4 and 5 and fault injections for a given multiplicitywere repeated 1000 times, as in [9]. As Tab.3 shows, theproposed BIST framework provides a higher than 96%coverage in every scenario. Interestingly, the coveragesaturates with 4 and 5 faults since the probability to injecterrors in a module already affected by an error becomeshigh.VI. CONCLUSIONSThis work develops a scalable built-in self-test andself-diagnosis infrastructure for NoCs taking full advantageof their structural redundancy through a cooperativetesting and diagnosis framework. Table-less logic baseddistributed routing is the foundation of our approach, andenables network reconfiguration with only 10 diagnosisbits per switch. We prove the achievement of standardfault coverage targets at an affordable area overhead.However, we do more than that: we quantify coverage formultiple faults and aim at the coverage of faults affectingTPGs as well. This latter is a key step forward to makethe move from scan-based approaches to scalable BISTapproaches viable.ACKNOWLEDGEMENTSThis work has been partially supported by the NANOCEuropean Project (FP7-ICT-248972), and by the SpanishGovernment under the grant TIN2009-14475-C04-01.REFERENCES[1] S.Stergiou et al., ”Xpipes Lite: a Synthesis Oriented Design Libraryfor Networks on Chips”, DAC, pp.559-564, 2005.[2] K.Petersen, J.Oberg, ”Utilizing NoC Switches as BIST-Structuresin 2D Mesh Network-on-Chip”, Future Interconnects and Networkon Chip Workshop, 2006.[3] D.Wentzlaff et al., ”On-Chip Interconnection Architecture of theTile Processor”, IEEE Micro, vol.27, no.5, pp.15-31, 2007.[4] J.Raik, V.Govind, R.Ubar, ”An External Test Approach forNetwork-on-a-Chip Switches”, Proc. of the IEEE Asian Test Symposium2006, pp.437-442, Nov. 2006.[5] J.Raik, V.Govind, R.Ubar, ”Test Configurations for DiagnosingFaulty Links in NoC Switches”, Proc. ETS, 2007.[6] M. Mishra and S. Goldstein, ”Defect tolerance at the end of theroadmap”, in ITC, pages 1201-1211, 2003.[7] D. A. IIitzky, J. D. Hoffman, A. Chun and B. P. Esparza, ”Architectureof the Scalable Communications Core’s Network on Chip”,IEEE MICRO, 2007, pp. 62-74.[8] J.Raik, V.Govind, R.Ubar, ”DfT-based External Test and Diagnosisof Mesh-like NoCs”, IET Computers and Digital Techniques,October 2009.[9] V.Bertacco, D.Fick, A.DeOrio, J.Hu, D.Blaauw, D.Sylvester, ”VI-CIS: A Reliable Network for Unreliable Silicon”, DAC 2009,pp.812-817.[10] Y.Zorian, ”Testing the monster chip”, IEEE Spectrum, pp.54-60,1999.[11] Y.Zorian, ”Embedded Memory Test and Repair: Infrastructure IPfor SoC Yield.”, International Test Conference, pp.340-349,2002.[12] K.Peterson, J.Oberg, ”Toward a Scalable Test Methodology for2D-mesh Network-on-Chip”, DATE 2007, pp.75-80, 2007.[13] A.M. Amory, E.Briao, E.Cota, M.Lubaszewski, F.G.Moraes, ”AScalable Test Strategy for Network-on-Chip Routers”, Proc. of ITC2005.[14] K.Arabi, ”Logic BIST and Scan Test Techniques for MultipleIdentical Blocks”, IEEE VLSI Test Symnposium, pp.60-68, 2002.[15] C.Grecu, P.Pande, B.Wang, A.Ivanov, R.Saleh, ”Methodologiesand Algorithms for Testing Switch-Based NoC Interconnects”,IEEE DFT 2005, pp.238-246, 2005.[16] B.Vermeulen, J.Delissen, K.Goossens, ”Bringing CommunicationNetworks on a Chip: Test and Verification Implications”, IEEECommunications Magazine, vol.41-9, pp.74-81, 2003.[17] R.Ubar, J.Raik, ”Testing Strategies for Network on Chip”, inBook: ”Network on Chip”, edited by A.Jantsch and H.Tenhunen,Kluwer Academic Publisher, pp.131-152, 2003.[18] C.Aktouf, ”A Complete Strategy for Testing an on-Chip MultiprocessorArchitecture”, IEEE Design and Test of Computers,vol.19-1, pp.18-28, 2002.[19] Panda et al., ”Design, Synthesis and Test of Networks on Chips”,IEEE Design and Test of Computers, vol.22, issue 8, pp.404-413,2005.[20] S.Y.Lin, C.C.Hsu, A.Y.Wu, ”A Scalable Built-In Self-Test/Self-Diagnosis Architecture for 2D-mesh Based Chip MultiprocessorSystems”, IEEE Int. Symp. on Circuits and Systems, pp.2317 -2320, 2009[21] M.Hosseinabady, A.Banaiyan, M.N.Bojnordi, Z.Navabi, ”A ConcurrentTesting Method for NoC Switches”, DATE, pp.1171 - 1176,2006[22] C.Grecu, P.Pande, A.Ivanov, R.Saleh, ”BIST for Network-on-Chip Interconnect Infrastructures”, VLSI Test Symposium, page 6,2006.[23] Wu, Y. and MacDonald, P., ”Testing ASICs with Multiple IdenticalCores”, IEEE Transactions on Computer-Aided Design ofIntegrated Circuits and Systems, vol. 22-3, 2003, pp. 327-336.[24] S.Rodrigo, S.Medardoni, J.Flich, D.Bertozzi, J.Duato, ”EfficientImplementation of Distributed Routing Algorithms for NoCs”,IET-CDT, pp.460-475, vol.3, issue 5, 2009.[25] Submitted paper under review[26] S.Rodrigo, J.Flich, A.Roca, S.Medardoni, D.Bertozzi,J.Camacho, F.Silla, J.Duato, ”Addressing Manufacturing Challengeswith Cost-Effective Fault Tolerant Routing”, NOCS 2010,pp.35-32, 2010.[27] P.K. Lala, ”Self-checking and fault tolerant Digital Design”, MKPublishers 2001.JP2011-220

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111Modular Distributed Switch: Spreading the Switchalong the LinkAntoni Roca, Carles Hernández, José Flich, Federico Silla, José DuatoAbstract—It is well-known that current Chip Multiprocessor (CMP)and high-end MultiProcessor System-on-Chip (MPSoC) designsare growing in their number of components. Networks-on-Chip(NoC) provide the required connectivity for such CMP andMPSoC designs at reasonable costs. However, as technologyadvances, links become the critical component in the NoC. First,because the power consumption of the link is extremely high withrespect the power consumption of the rest of components (mainlyswitches), becoming unacceptable for long global interconnects.Second, the delay of a link does not scale with technology, thus,degrading the performance of the network.In this paper we present a new switch architecture thatreduces the negative impact of links on the NoC. We call ourproposal distributed switch. The distributed switch moves thecircuitry of a standard switch onto the links. Then, packetsare buffered, routed, and forwarded at the same time they arecrossing the link. Distributing a standard switch onto the linkimproves the trade off between the power consumption and theoperating frequency of the entire network. In contrast, arearequirements are increased. The distributed switch reduces upto 14.8% the peak power consumption while increases its areaup to 22%. Furthermore, the distributed switch is able to increasethe maximum achievable frequency with respect to the standardswitch up to 14.3%.I. INTRODUCTIONAs technology advances, current Chip MultiProcessor(CMP) and high-end MultiProcessor System-on-Chip (MP-SoC) designs are growing in their number of components.This ever growing number of devices demands an efficient interconnectstructure inside the chip. Networks-on-Chip (NoC)have been accepted as an efficient and scalable solution forCMPs and MPSoCs [1]. The idea is quite simple, a pointto-pointnetwork inside the chip is implemented connectingall the devices. In this scenario, and with the expectationsto reach hundreds of cores in the near future, an efficientimplementation of the NoC becomes a challenge. The NoCis built from basic components, as switches and networkinterfaces which are connected by links, thus building thetopology and final network structure.The most basic link implementation is a driver connectedto a wire. The driver is a necessary element that feeds thewire with the required signal. Minimizing the degradation thatthe signal suffers when crossing the wire is mandatory in thedesign phase. However, this basic design is unpractical dueto its huge power consumption. A commonly accepted wayto build a link is to insert several smaller drivers (repeaters)along the link [2]. By introducing the proper number and sizeof repeaters, it is possible to minimize the power consumptionGrupo de Arquitecturas Paralelas , Universitat Politècnica de València, e-mail: anrope2@gap.upv.es.of the link [3]. However, despite the power optimization whenintroducing repeaters along the link, the link interconnectintroduces two major problems. First, its power consumptionis still the main contribution to the total power consumptionof the network. In fact, link power can become unacceptablyhigh, even when using repeaters, thus limiting data bandwidth[4]. Second, link delay is a critical parameter that doesnot improve with process scaling [2], that is, as technologyscales down, the latency of the link becomes the bottleneck ofthe network, degrading the performance of current and futurenetworks.In this paper we present a new switch architecture thatreduces the negative impact of links on the NoC. The maincontribution of our new switch architecture is to move anentire pipelined switch onto the link, thus modifying the finalfloorplan of the network. We distribute along the link the tasksand logic of a switch, that is typically designed by placingall its logic grouped in a single area. We call this proposaldistributed switch. In our distributed switch, the architecture ofthe switch and the link are glued. Packets are buffered, routed,and forwarded at the same time they are crossing the link. Themain benefit of spreading the switch over the link is that thetrade off between the power consumption and the operatingfrequency of the entire network is improved. In particular, upto 14.8% in peak power reduction is achieved.The rest of the paper is organized as follows. Section IIpresents a simple and modular switch, used as the startingpoint for the design of the distributed switch, which is laterpresented in Section III. Then, the link that connects twomodular switches (modular link) and the link that connectstwo distributed switches (distributed link) are designed inSection IV. In Section V an area comparison of the differentswitch architectures is carried out. Section VI analyses andcompares the power consumption of the different proposals.Finally, some conclusions and future work are presented inSection VIII.II. MODULAR SWITCHThe modular switch is a pipelined buffered wormhole switchwith two stages. A complete description and analysis of theswitch can be seen in [5]. The main characteristic of the switchis that each output port is managed independently. That is, eachoutput port has its own circuitry (output port controller) whichis not connected to the circuitry of the rest of output ports,as can be seen in Figure 1(a). This figure shows a modularswitch consisting of five input/output ports. Each input portcan reach any output port direction except the output portthat goes in the same direction of the input port (U turns areJP2011-221

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20112not allowed). Also, the local port connecting the core and theswitch can be reached from any input port. Thus, each outputport works as a 4-to-1 switch. That is, each output port is ableto buffer, route, and forward those packets that request thatoutput port. Figure 1(b) shows the block diagram of an outputport controller. As it can be seen, the output port controllercircuitry – and hence all the switch – is composed of twodifferent modules: the Routing Computation (RC) module, andthe Arbitration-Crossbar (AC) module.ARBITERDATA IN 1DATA IN 2FLOW CONTROLCLKBUFFERFLOW CONTROLDATA_OUTFig. 2. AC module schematic.Fig. 1.(a) Modular switch schematic.Modular switch schematic.(b) Output port controller schematic.The AC module, depicted in Figure 2, is the most importantcomponent in the switch. It performs the arbitration, switchtraversal (crossbar), and buffering stages present in a pipelinedswitch. The simplicity of this module allows the switch to befaster than a simple and canonical switch, as shown in [5].The AC module is a simple two-to-one multiplexer with itsoutput registered. An arbiter decides which input is going to beconnected with the output of the module. The arbiter has beenimplemented using a simple round-robin arbiter. The buffer inthe AC module is able to store two flits. Then, each inputoutputpath of the switch is able to store four flits (two perstage). The buffer is implemented by using a mux-in-first-outbuffer [6]. By using this structure for the buffer, the zeroloadlatency of the modular switch is one cycle per stage,that is, when no contention exists, a flit needs two cycles tocross the modular switch. Finally, Stop&Go flow control hasbeen implemented between modules inside the output portcontroller. This flow control is identical to the flow controlimplemented between modules of different switches. Thestoring capability of the AC module can be set to any value atdesign time. However, if the buffer size of the AC module islower than two, the round-trip-time between modules cannotbe fulfilled and, hence, there is no possibility to transmitconsecutive flits without introducing bubbles. Therefore, theAC module fixes the operating frequency of the output portcontroller and hence, the operating frequency of the entireswitch.The RC module performs the routing computation. Ourswitch is designed to perform a simple XY routing algorithm.Other routing algorithms can be leveraged. Nevertheless, asa deterministic routing is being used in our design, eachRC module is able to perform look-ahead routing [7], whichincreases the overall performance of the switch. Figure 1(b)also shows the pipeline of the switch, where each column ofAC modules represents a different stage. On the other hand,as the RC module is not in the critical path of the switch, theRC has no latency restrictions. In the modular switch, the RCtasks are performed in parallel with the second AC stage (seeFigure 1(b)).The modular switch design requires increasing the resourcesof the switch. In fact, the buffer requirements – and hence thearea – of this modular switch is higher than the area of acanonical switch [5]. In contrast, a higher operating frequencycan be obtained [5]. Another penalty that this switch presentsis the increment in metallizations at the input side of theswitch. Note in Figure 1(a) that each input port is connectedto all output ports. That increment in metallizations increasesthe power consumption of the switch.The switch in Figure 1(a) is intended for 2D meshes.Thus, four ports are used to provide connectivity with theneighbouring switches and the fifth port connects to the localcomputing core. Nevertheless, in order to complete the switchdesign, floorplan needs to be taken into account, in order toknow the link length. In this regard, link length depends on theexact size of the tiles in the CMP chip, as the 2D mesh NoCwill cover all the die area. Thus, in order to avoid designingthe whole tile, which is out of the scope of this paper, weused the MCPAT tool [8] to find out the area required by thetile when synthesized using a 45nm technology node. MCPATtool results show that the tile requires 5.77mm 2 , links being2.4mm long if square tiles are assumed. On the other hand,total die size is slightly larger than 400mm 2 , assuring that itis manufacturable [9].Finally, links are divided into data and flow control sublinks.Data sublink width is set to 8 bytes. Flow control sublink widthis set to 2 bits. Then, the total link width is 66 bits. Flit sizeis set to data link width.A. Critical PathAs each output port controller is independent and identicalto the other output port controllers, fixing the critical path of anoutput port controller is equivalent to fix the critical path of theentire switch. If we analyze the delay of the paths of a switch,we observe that the paths that set the critical path (slowestpath) are those that interconnect two adjacent switches. Thatis, the slowest path in the switch is the data path between twoswitches and the flow control that connects the AC modules oftwo adjacent switches. In both cases, the delay is contributedby a combinational logic that creates the signals and the linkdelay to transmit those signals from one switch to another.JP2011-222

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20113In order to know such delays, the switch has been implementedusing the 45nm technology open source Nangate[10] with Synopsys DC. We have used M1-M3 metallizationlayers to perform the Place&Route with Cadence Encounter.We observe, after synthesizing the modular switch that thecombinational delay of the data path and the flow controlpath are almost identical. The minimum combinational delayreachable by the synthesis tool for those paths is 0.53ns. Then,the critical path (T) of a switch is:T = 0.53ns + link delay (1)where the link delay will be set in order to fullfill the networkrequirements. It is noteworthy to mention, that the modularswitch presented in this paper has a critical path that is up to15% shorter than the critical path of a canonical switch [5].III. DISTRIBUTED SWITCHThe modular switch design presented in the previous sectionhas an interesting property. Each output port has its owncircuitry that is independent from the circuitry of the restof output ports (see Figure 1(a)). This property allows themodular switch presented in Section II to be distributed overthe links while keeping the connectivity of the switch with itsneighbours. That is, it allows to spread the circuitry of eachoutput port controller of the switch along the link that connectsthat output port circuitry with the adjacent switch. Each of thestages of the output port controller is located at half the lengthof the link connecting to the adjacent switch.There are several benefits of distributing the switch over thelink. First, power consumption is reduced without increasingthe delay of the communication between switches. That is,distributing the switch over the link forces the link to bepipelined (distributed link). However, the pipeline of thedistributed link is not only introduced to minimize powerconsumption but to perform the switching tasks. Pipelining thelink minimizes the delay constraints of the link. Then, powerconsumption of the link is reduced. Thus, interconnects canbe designed reducing the power consumption meanwhile thepipeline of a message is not increased.The second benefit of distributing the switch over the linkis that any stage of the pipelined switch is connected to afragment of the link (sublink). Thus, the effects of processvariation over the pipelined switch can be easily minimized, asshown in [11], where a simple technique to reduce the processvariation effects of the switch was presented. Basically, anyperformance variation in the switch is compensated by makingthe link faster, which is a simple and well-known technique.However, this technique could not be used inside a pipelinedswitch [12]. In a distributed switch, any stage of the switch isconnected to a sublink and, therefore, any process variation ofany pipeline stage of the switch can be compensated by thesublink that is connected to. The impact of process variationon the distributed switch is left to future work.Distributing the switch over the link may have a negativeconsequence, as the length of the wires between AC modulesincreases. Remember that in the modular switch, any inputport is connected to all the output port controllers inside theswitch. In the distributed switch, this interconnection becomeslonger because AC stages are separated from each other.This effect can be seen in Figure 3. The figure shows theconnectivity between two modular switches and its equivalentdistributed link. While a typical link has a length of L plus thelength of the wire inside the switch (negligible), the distributedswitch presents six smaller links of length L/2, accountingfor a total of 3L routed wires per distributed link. Then, adistributed link, presents three times more routed wires thanthe equivalent centralized link. Despite the increment in routedwire, the length reduction of each sublink in a distributed linkwill reduce the delay constraint of these sublinks and then,reducing the total power consumption of the distributed link.(a) Link between adjacent modularswitches.Fig. 3.Link scheme for both scenarios.L/2L/2INCREMENTED ROUTEDWIRES(b) Equivalent distributed link.The negative effect of these longer wires is minimizedby using higher metallization layers, achieving low powerconsumption (see Section IV). This is the case of the distributedswitch. In contrast, in the modular switch distancebetween AC modules are shorter as they are inside the switcharea and, hence, they are routed by using lower metallizationlayers which have worse properties, and hence, higher powerconsumption.Figure 4(a) shows the floorplan of a 3x3 2D-mesh withstandard (modular) switches. Note that, each modular switchis suited in a single area, equidistant to other switches.Figure 4(b) shows the floorplan of a 3x3 2D-mesh whendistributed switches are implemented. Interconnection wireshave been omitted for clarity. Note that, the AC modulesof the different distributed switches are spread on the die.Each AC module is connected to AC modules at distance L/2as explained before. Shaded AC modules represent a singledistributed link, as shown in Figure 3(b).The critical path of this switch can be computed in thesame way as the critical path of the modular switch. Thecombinational logic delay of the distributed switch is identicalto the combinational logic of the modular switch and thereforethe delay of the combinational part of the critical path remainsidentical. However, remember that for the distributed switchthe link length is half the length of the modular switch link.The length reduction of the distributed switch sublinks allowsthe designer to reduce the link delay of the distributed sublinkswith respect to the link delay of the centralized links. Similarly,by fixing the same link delay for both sublinks, the distributedsublink consumes less power than the centralized link.JP2011-223

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20114Wire Length 2.4 1.2 0.6Number of repeaters 7 6 3Size of the repeaters 15 6 6TABLE INUMBER AND SIZE OF THE REPEATERS OF A WIRE.(a) Floorplan with standard switches. (b) Floorplan with distributedswitches.Fig. 4.2D mesh floorplan with standard and distributed switches.IV. WIRE DESIGNIn this section we describe the design of the wire betweenswitches for both scenarios: when modular switches are used,and when distributed switches are implemented.Wire delay has been set to 0.47ns to match the operatingfrequency of the switch to 1 GHz (see Section II-A) for boththe modular (or standard) switch and the distributed switch.In contrast, wire length differs from one switch design to theother. As mentioned in Section II, wire length for the modularswitch is set to 2.4mm. For the distributed switch, although thetile is identical, wire configuration is different and, therefore,in practice wire length is divided by two, being 1.2mm (seeSection III). We do not take into account switch area in anyof both designs.We use the higher metallization layers offered by thetechnology (M9-M10) to route the interconnection wires. Themain reason to use the highest metallization layers is that theselayers allow the designer to use lower metallization layers forother purposes, as SRAM. Then, it is possible to route wiresbetween switches over functional modules as SRAM [13], thatis, route wires without using dedicated area for them. Notethat, the repeaters inserted along a wire use the same type ofresources as other functional blocks.Each segment of the wire is represented by a resistor anda capacitor that model the resistance and the capacitanceof this segment of the wire, respectively. In our case, wehave modelled the wire by using the 5-pi wire model [14].We insert repeaters along the wire when needed [2]. Thismethod reduces interconnect delay and signal transition times.In order to minimize the power consumption of a wire, itis necessary to insert the proper number of minimum sizedrepeaters [3] that satisfies the delay constraint imposed by theoperating frequency of the switch. This technique is calledpower-optimal repeater insertion [3]. Table I shows the numberand size (gain) of the repeaters of a wire for different wirelengths, when using the optimal repeater insertion techniquetogether with the wire parameters.V. AREA RESULTSIn this section we analyze the area of the modular anddistributed switch. Remember that both switches are identicalfrom a functional point of view, meaning that both switchesprovide the same output response for an identical input stimuli.Then, there is no difference in performance (at cycle level)when introducing both switches in a network.Table II shows the area occupied by the logic for bothswitches, the repeaters of a link, and the total area occupiedby the switch and the repeaters. As can be seen, the distributedswitch occupies a 13.82% less area than the modular switch.The main reason is that the distributed switch presents a simplerdesign that helps the synthesis tool to optimize the design.Furthermore, the modular switch presents some intermoduleconnectivity resources that the distributed switch does notpresent. Table II also shows the area occupied by the repeatersinserted along the link for a modular, and a distributedlink. As the number of sublinks increases in the distributedlink, the number of repeaters increases. As a consequence,area resources required by distributed switches increase withrespect to the modular switch. Finally, Table II shows wholeswitch area results for the different architectures presented.The area of the whole switch is calculated considering thearea of switch modules and the area of the repeaters of fourlinks. As shown, the distributed switch architecture presents a22% more area than the modular switch.Area (um 2 ) Switch Repeaters TotalModular Switch 28356.72 2697.3 39145Distributed Switch 24437.28 5845.32 47817TABLE IIAREA COMPARISONVI. POWER CONSUMPTIONA. Switch Modules Power ConsumptionTable III shows the total power consumption of a modularswitch and its equivalent distributed switch. Table III showsalso the clock tree power consumption. The power consumptionhas been obtained using the Power Compiler tool bySynopsis. Results shows that the distributed switch has a lowerpower consumption, obtaining a reduction of 11.95%. Thissaving in power is due to the synthesis tool improvementdue to the simplicity of the distributed switch design andthe intermodule connectivity of the modular switch that isnot present in the distributed switch. In the same way, thedistributed switch also achieves a remarkable power reductionin the clock tree. Concretely, clock tree power consumptionof the modular switch is 14.78 mW, whereas the distributedswitch clock tree power is only 12.05 mW, representing a18.47% redutcion of power consumption.Power (mW) Clock tree TotalModular 14.78 71.21Distributed 12.05 62.7TABLE IIIPOWER CONSUMPTION OF A MODULAR AND A DISTRIBUTED SWITCHJP2011-224

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20115B. Wire Power ConsumptionIn this section we analyze the power consumption of a singlewire for different wire lengths, see Table IV. Power consumptionhas been obtained using Cadence Virtuoso. Powerconsumption of a wire depends on the input signal. In theabsence of signal transition, the wire only consumes leakagepower which is negligible. Then, the dynamic power is themain power consumption source. Table IV also shows that asthe length of the wire decreases, the power consumption ofthe wire decreases. In average, this decrement is on average55%.Power Consumption (uW)Wire length (mm) Input transition No input transition2.4 358 0.8001.2 152 0.3500.6 69.3 0.162TABLE IVPOWER CONSUMPTION IN A CLOCK CYCLE FOR DIFFERENT LINK LENGTHSC. Link Power ConsumptionWire power consumption values in Table IV are used tocompute the power consumption of both the modular and thedistributed link (see Section IV). Define N as the total numberof wires in a link. N is set to 66 (see Section IV). Define P s (l)the total power consumption during a clock cycle of a singlewire of length l when there is no input transition (third columnin Table IV). Define P y (l) the total power consumption duringa clock cycle of a wire of length l when there is an inputtransition (second column in Table IV).As shown in the previous section, the power consumptionon a wire depends on the input signal. Additionally, theprobability of having an input signal transition in a link wiredepends on both the link utilization (L u ) and the switchingactivity. Note that the switching activity (α) is defined as theaverage probability of bit transition when flits traverse thelink. Typical values of switching activity are in the range of0.3 − 0.5 [15].In this paper, T is defined as the probability that aninput signal modifies its value. This parameter takes intoconsideration both the probability of transmitting a flit andthe switching activity. Concretely, the value of T is given byT = L u ∗α. Finally, the power consumption of a modular link(P m ) as defined in Section IV is:P m (T ) = N ∗T ∗P y (2.4mm)+N ∗(1−T )∗P s (2.4mm) (2)The power consumption of the modular link has two terms.The first term defines the dynamic power consumption of thelink, whereas the second term defines the link static powerconsumption of the link (when no information is crossing thelink).To measure the power consumption of a distributed link(P d ), it is necessary to remark that a distributed link is madeof six sublinks of length 1.2mm. Thus, when no information iscrossing the link, the static power of the distributed link is thestatic power consumption of six sublinks of length 1.2mm. Incontrast, as mentioned before, the dynamic power consumptionFig. 5.power consumption (mW)252015105distributed linkmodular link00 0.2 0.4 0.6 0.8 1link utilization rate (T)Power consumption of a modular link and a distributed link.depends on the number of flits that crosses the link (defined bythe probability T ). As shown in Figure 3, the distributed linkis two stages long. Thus, any flit that crosses a distributed link,will traverse two small sublinks. Therefore, by assuming thesame traffic rate as in the modular link (defined by probabilityT ), the distributed link is traversed by a number of flits definedby the probability 2 ∗ T . Then, the power consumption of adistributed switch is:P d (T ) = 2 ∗ N ∗ T ∗ P y (1.2mm)+2 ∗ N ∗ (1 − T ) ∗ P s (1.2mm) + 4 ∗ N ∗ P s (1.2mm)Figure 5 shows the average power consumption per clockcycle of a modular and a distributed link for different valuesof T . For high traffic rates (high values of T), the distributedlink consumes less power than the modular link. Concretely,for T = 1, the distributed link is able to save 3.47mW perclock cycle (up to 14.68%). On the contrary, for low trafficrates (low values of T), the higher number of routed wiresin the distributed link causes the distributed link to consumemore power. However, when low traffic rate is present in thenetwork, the main contributor of the power consumption is theleakage power of the link, which is negligible in comparisonwith the dynamic power consumption of those links (seeSection VI-B). For T = 0 the distributed link only consumes138.6uW per clock cycle, while the modular link consumes52.8uW. The difference then is only 85uW per clock cycle.Anyway, for low link utilization rates, the different links overthe network are inactive. In these long inactivity periods, linkscan be turned off reducing power consumption to zero. Insuch network scenario, the link power consumption is mainlydefined by the dynamic power consumption of the link. Inthat case, the distributed link provides a power consumptiondecrement of 14.68%, which is the power consumption savingwhen only the dynamic power consumption is taken intoaccount (T = 1).As described before, the distributed switch achieves betterpower results for low values of link utilization. Moreover,for real application scenarios, we have measured the linkutilization, obtaining that T is, in average, 6%. In that case, thedistributed link reaches a saving top in power consumption of(3)JP2011-225

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20116Fig. 6.operating frequency (GHz)1.61.41.210.8distributed switchmodular switch15 20 25 30 35 40 45 50 55 60peak power consumption (mW)Operating frequency of a modular and a distributed switch.8.7% with respect to the modular link. However, among otherreasons, the peak power of a CMP processor must be keptlower than a threshold, as the increasing heat dissipation inCMP architectures with multiple cores in a single die, maycause an increase of the thermal induced failures [16]. Peakpower saving of the distributed link is 14.68%.VII. OPERATING FREQUENCYIn previous sections we analysed how by reducing linklength, the power consumption of the distributed switch isreduced over the modular switch. The same is true for thepower consumption of the distributed link over the powerconsumption of the modular link. Those results have beenobtained when both scenarios work at the same operatingfrequency in order to allow a fair comparison. However,reducing link length has another important benefit. Whenshortening the link, the minimum link delay – that sets thetotal latency of the switch – can be reduced. That is, givena power budget, the distributed link is able to work at higherfrequencies.Figure 6 shows the operating frequency of the distributedswitch and the modular switch with respect to the powerconsumption of their respective links. Note that, for the sameoperating frequency, the distributed link consumes less powerthan the modular one. Furthermore, the distributed switch isable to reach a maximum operating frequency higher than themodular switch. Concretely, the maximum operating frequencyof the distributed switch is 1.65GHz, whereas the maximumoperating frequency of the modular switch is 1.44GHz or, inother words, the maximum frequency of the distributed switchis 14.3% higher than that of the modular switch.VIII. CONCLUSIONSIn this paper a distributed switch architecture is presented.The distributed switch spreads the circuitry of a typical switcharchitecture along the link. Thus, each stage of a switch islocated at half the distance than in a conventional network.By reducing the distance between modules, the peak powerconsumption of NoC links can be reduced. As a drawback,the number of routed wires is increased.Results confirm that the distributed switch architecture isable to reduce peak power consumption by 14.8% in NoClinks at the expense of a 22% increase in the total area ofthe switch. Moreover, modules of the switch architecture alsosave power. Concretely, the distributed switch modules presenta power consumption reduction of 11.95%.On the other hand, results also show that given a powerbudget the frequency of the distributed switch is always higherthan the frequency of the modular switch. Moreover, themaximum achievable frequency of the distributed switch ishigher. In particular, the maximum operating frequency of thedistributed switch is a 14.3% higher.ACKNOWLEDGEMENTSThis work was supported by the Spanish MEC and MICINN,as well as European Commission FEDER funds, under GrantsCSD2006-00046 and TIN2009-14475-C04. It was also partly supportedby the project NaNoC (project label 248972) which is fundedby the European Commission within the Research Programme FP7.REFERENCES[1] J. Flich et al., Designing Network On-Chip Architectures in theNanoscale Era, ser. Computational Science Series, D. Bertozzi et al.,Eds. Chapman and Hall, 2010.[2] R. Ho, et al., “The future of wires,” in Proceedings of the IEEE, 2001,pp. 490–504.[3] G. Chen et al., “Low-power repeaters driving RC and RLC interconnectswith delay and bandwidth constraints,” IEEE Trans. VLSI Syst., vol. 14,no. 2, pp. 161–172, 2006.[4] D. Schinkel, et al., “Low-power, high-speed transceivers for networkon-chipcommunication,” IEEE Trans. VLSI Syst., vol. 17, no. 1, pp.12–21, 2009.[5] A. Roca, et al., “A low-latency modular switch for CMP systems,”University of Valencia, Tech. Rep., 2011. [Online]. Available:www.disca.upv.es/jflich/techreportmodularswitch.pdf[6] G. de Micheli et al., Networks on Chips: Technology And Tools, ser. InSystems on Silicon. Morgan Kaufmann Pub, July 2006.[7] J.-K. Peir et al., “Look-ahead routing switches for multistage interconnectionnetworks,” J. Parallel Distrib. Comput., vol. 19, no. 1, pp. 1–10,1993.[8] S. Li, et al., “McPAT: an integrated power, area, and timing modelingframework for multicore and manycore architectures,” in MICRO, 2009,pp. 469–480.[9] C. Liu, et al., “Organizing the last line of defense before hitting thememory wall for cmp,” in HPCA, 2004, pp. 176–185.[10] 45nm FreePDK. The Nangate open cell library. [Online]. Available:https://www.si2.org/openeda.si2.org/projects/nangatelib/[11] S. Medardoni, et al., “Variation tolerant NoC design by means of selfcalibratinglinks,” in DATE, 2008, pp. 1402–1407.[12] C. Hernandez, et al., “Improving the performance of GALS-based NoCsin the presence of process variation,” in NOCS, 2010, pp. 35–42.[13] G. Passas, et al., “A 128 x 128 x 24gb/s crossbar interconnecting 128tiles in a single hop and occupying 6% of their area,” in NOCS, 2010,pp. 87–95.[14] I. Benito, “Global interconnects in the presence of uncertainty,” Ph.D.dissertation, University of Massachusetts, 2008.[15] A. Kahng, et al., “Orion 2.0: A fast and accurate noc power and areamodel for early-stage design space exploration,” in Design, AutomationTest in Europe Conference Exhibition, 2009. DATE ’09., 2009, pp. 423–428.[16] Y. Wang, et al., “Temperature-constrained power control for chip multiprocessorswith online model estimation,” in Proceedings of the 36thannual international symposium on Computer architecture, 2009, pp.314–324.JP2011-226

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Reducing the Energy Consumption ofHardware Prefetching in Many-Core CMPsusing Reply PartitioningAntonio Flores, Manuel E. Acacio, and Juan L. Aragón 1Resumen— In this work, we show how to reduce theenergy impact of prefetching techniques in the contextof tiled CMPs. Our proposal is based on ReplyPartitioning, a technique that classifies all coherencemessages into critical and short, and non-critical andlong messages; and the use of a heterogeneous interconnectionnetwork comprised of low-latency wires forcritical messages and low-energy wires for non-criticalones and prefetched lines. Detailed simulations of a16-core CMP show that our proposal obtains improvementsof up to 75% in the energy consumed by theinterconnect (45-50% on average) with almost negligiblecost in terms of execution time (average degradationof 3%).Palabras clave— Tiled Chip-Multiprocessor, Energy-Efficient Architectures, Hardware Prefetching, HeterogeneusOn-Chip Interconnection Network.I. IntroductionTODAY, multi-core architectures are envisionedas the only way to ensure performance improvements.In this way, designs with tens of cores on thedie will be a reality within this decade. Additionally,future many-core CMPs with several tens (oreven hundreds) of processor cores probably will bedesigned as arrays of replicated tiles connected overan on-chip switched direct network [1]. These tiledarchitectures have been claimed to provide a scalablesolution for managing the design complexity, and effectivelyusing the resources available in advancedVLSI technologies. Maybe, one of the best knownexamples of a tiled CMP architecture today is the80-core Intel’s Polaris prototype [2].However, one of the greatest bottlenecks to providehigh performance and energy efficiency in suchtiled CMP architectures is the high cost of on-chipcommunication through global wires [3]. Wang et al.[4] reported that the on-chip network of the Raw processorconsumes 36% of the total chip power. Magenet al. [5] also attribute 50% of overall chip power tothe interconnect. Most of this power is consumed inthe point-to-point links of the interconnect [4]. Thus,wires pose major performance and power consumptionproblems as technology shrinks and total diearea increases.One way to tackle problems due to wire delay is touse latency hiding techniques like hardware prefetching,which eliminates some cache misses and/or overlapsthe latencies of others. Unfortunately, hardwareprefetching significantly increases on-chip communicationsince coherence between the L1 caches of the1 Dpto. Ingeniería y Tec. de Computadores, Univ. Murcia,e-mail: {aflores,meacacio,jlaragon}@ditec.um.es.tiled CMP must be ensured, increasing the powerconsumption of the on-chip interconnect.Another approach to alleviate the negative effectof wire delays and the increasing interconnect powerconsumption is the use of heterogeneous on-chip interconnectionnetworks [6], i.e., an interconnect withlinks comprised of wires with varying physical properties.By tuning wire width and spacing, it is possibleto design wires with varying latency and bandwidthproperties. Similarly, by tuning repeater sizeand spacing, it is possible to design wires with varyinglatency and energy properties. This paper exploressuch an approach by proposing the use of ReplyPartitioning[7], a technique that allows criticalmessages to be transmitted using low latency wiresmeanwhile the rest of messages, including prefetchedlines, are transmitted using low power wires, in thecontext of hardware prefetching. Detailed simulationsof a 16-core CMP show average improvementsof 10% in execution time and 38% in the ED 2 P metricof the interconnect (28% of the full CMP).The rest of this paper is organized as follows. SectionII reviews some related work. Our proposal forefficient message management in tiled CMPs is presentedin section III. Section IV describes the evaluationmethodology and presents the results of theproposed mechanism, and finally, section V summarizesthe main conclusions of the work.II. Related WorkThe on-chip interconnection network is a criticaldesign element in a multi-core architecture and, consequently,it is the subject of several recent works.Among others, Kumar et al. [8] analyze several onchipinterconnection mechanisms and topologies, andquantify their area, power, and latency overheads.Their study concludes that the design choices for theinterconnect have a significant effect on the rest ofthe chip, potentially consuming a significant fractionof the real estate and power budget.Hardware prefetching has been proposed andexplored by many researchers [9][10][11], and iscurrently implemented in many existing systems[12][13]. From mid-sixties, early studies [14] of cachedesign recognized the benefits of prefetching. Hardwareprefetching of separate cache blocks was laterimplemented in the IBM 370/168 and Amdahl 470V[15]. Smith summarizes several of these early approachesin his survey of cache memories [16]. Jouppi[17] introduced stream buffers that trigger succes-JP2011-227

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011sive cache line prefetches on a miss. Chen andBaer [9] proposed variations of stride-based hardwareprefetching to reduce the cache-to-memory latency.Dahlgren et. al. [18] proposed an adaptive sequential(unit-stride) prefetching scheme that adaptsto the effectiveness of prefetching. Ki and Knowles[19] used extra cache bits to increase the accuracyof prefetching. Srinivasan et. al. [20], classifiedprefetches according to whether they reduce or increasemisses or traffic.On the other hand, a reduced number of workshave attempted to exploit the properties of a heterogeneousinterconnection network at the microarchitecturelevel in order to reduce the interconnectenergy share. Beckmann and Wood [21] propose theuse of transmission lines to access large L2 on-chipcaches in order to reduce the required cache areaand the dynamic power consumption of the interconnectionnetwork. In [6], Balasubramonian et al.make the first proposal of wire management at themicroarchitecture level. They introduce the conceptof a heterogeneous interconnect that is comprisedof wires with varying area, latency, bandwidth,and energy characteristics, and they applyit to register communication within a clustered architecture.In particular, cache accesses are acceleratedby sending a subset of the address bits on lowlatencywires to prefetch data out of the L1 D-cache,while non-critical register values are transmitted onlow-power wires. They extend this proposal in [22]with techniques aimed at accelerating cache accessesin large L2/L3 split caches (L2/L3 NUCA architectures)by taking advantage of a lower-bandwidth,lower-latency network.Recently, Cheng et al. [23] applied the heterogeneousnetwork concept to the cache coherence trafficproblem in CMPs. In particular, they proposean interconnection network composed of three setsof wires with varying latency, bandwidth and energycharacteristics, and map coherence messages tothe appropriate set taking into account their latencyand bandwidth needs. They report significant performanceimprovement and interconnect energy reductionwhen a two-level tree interconnect is used toconnect the cores and the L2 cache. Unfortunately,insignificant performance improvements are reportedfor direct topologies (such as the 2D mesh typicallyemployed in tiled CMPs [2]).wires that are routed over memory arrays, as in [8].It can be seen that L-Wires yield a two-fold latencyimprovement at a four-fold area cost. On the otherhand, PW-Wires are designed to reduce power consumptionwith twice the delay of baseline wires (andthe same area cost).More recently, we have proposed in [7] Reply Partitioning,a technique that allows all coherence messagesto be classified into two groups: critical andshort, and non-critical and long. In particular, ReplyPartitioning focuses on replies that carry dataand split them into a critical and short Partial Replymessage that carries the word requested by the processor,in addition to a non-critical Ordinary Replywith the rest of the cache block. Reply Partitioningaims to use a heterogeneous interconnection networkcomprised of low-latency wires for critical messagesand low-energy wires for non-critical ones, which alsoallows for a more balanced workload. Note that inthe original proposal of Reply Partitioning, no hardwareprefetching technique was considered.Finally, in [24] we presented a proposal for carryingout energy-efficient hardware prefetching using lowpowerlinks to transmit most of the additional trafficthat prefetching generates, whereas the remainingtraffic employs baseline wires. Improvements of upto 30% in the power consumed by the interconnectwas obtained with almost negligible cost in terms ofexecution time.III. A Proposal for Efficient MessageManagement in Tiled CMPs withHardware PrefetchingIn this section we present our proposal for improvingthe performance and reducing the energy dissipatedby hardware prefetching in tiled CMPs. Thissection starts with a description of the tiled CMP architectureassumed in this paper, followed by a classificationof the messages in terms of both their criticalityand size when prefetching is employed andends with the description of the proposed mechanism.A. Tiled CMP ArchitecturesTABLA IArea, delay and power characteristics of wireimplementations.Wire Type Relative Latency Relative Area Dynamic Power (W/m) Static Powerα=Switching Factor W/mB-Wire (8X plane) 1x 1x 2.65α 1.0246B-Wire (4X plane) 1.6x 0.5x 2.9α 1.1578L-Wire (8X plane) 0.5x 4x 1.46α 0.5670PW-Wire (4X plane) 3.2x 0.5x 0.87α 0.3074PW-Wire (8X plane) 2x x 0.80α 0.2720Fig. 1.Tiled CMP architecture overview.Table I shows the relative area, delay and powercharacteristics of L- and PW-Wires compared tobaseline wires (B-Wires), as reported in [23]. A65 nm process technology is considered, where 4Xand 8X metal planes are used for global inter-coreA tiled CMP architecture consists of a number ofreplicated tiles connected over a switched direct network(Fig. 1). Each tile contains a processing corewith primary caches, a slice of the L2 cache, and aconnection to the on-chip network. The L2 cache isJP2011-228

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011shared among the different processing cores, but itis physically distributed between them. Therefore,some accesses to the L2 cache will be sent to thelocal slice while the rest will be serviced by remoteslices. In addition, the L2 cache stores (in the tags’part of the local L2 slice) the directory informationneeded to ensure coherence between the L1 caches.On a L1 cache miss, a request is sent down to theappropriate tile where further protocol actions areinitiated based on that block’s directory state, suchas invalidation messages, intervention messages, datawriteback, data block transfers, etc. A stride-basedtechnique is used as prefetcher [9][18][19], with a referenceprediction table (RPT) to keep the informationfor the most recently used memory instructions.The organization of the RPT is depicted in Fig. 2.Table entries contain the address of the memory instruction,the previous address accessed by this instruction,a stride value for those entries which followa stride pattern and a state field which records theentry’s current state. In this paper, we assume aprocess technology of 65 nm, a tile area of approximately25 mm 2 , and a die size in the order of 400mm 2 [1][25]. Further details about the evaluationmethodology and the simulated CMP configurationcan be found in section IV.Fig. 2.PCeffective addressinstruction tag previous address stride stateprefetch addressThe organization of the reference prediction table.B. Classification of messages in Tiled CMP Architectureswith PrefetchingThere are a variety of message types traveling onthe interconnect of a CMP, each one with propertiesthat are clearly distinct. In general, we can classifymessages into the following groups (see Fig. 3):Request messages, that are generated by cache controllersin response to L1 cache misses, or a likelyfuture L1 cache miss when prefetching is considered,and sent to the corresponding home L2 cache to demandprivileges over a memory line. Response messagesto these requests, generated by the home L2cache controller or, alternatively, by the remote L1cache that has the single valid copy of the data, andthey can carry the memory line or not. Coherencecommands, that are sent by the home L2 cache controllerto the corresponding L1 caches to ensure coherence.Coherence responses, sent by the L1 cachesback to the corresponding home L2 in response tocoherence commands. Replacement messages, thatthe L1 caches generate in case of exclusive or modifiedlines being replaced (replacement hints are notsent for lines in shared state).RequestResponseCohe commandCohe responseReplacementSrc Dest Type Control AddressSrc Dest Type MSHR Cache BlockSrcDestType MSHRSrc Dest Type Control AddressSrcSrcDestDestType MSHRType MSHRSrc Dest Type Control AddressCache BlockSrc Dest Type Control Address Cache BlockFig. 3. Classification of messages that travel on the interconnectionnetwork of a Tiled CMP Architecture.Messages involved in the L1 cache coherence protocolshown in Fig. 3 can be classified accordingto their criticality into critical and non-critical messages.We say that a message is critical when it is inthe critical path of the L1 cache miss. In other case,we call the message as non-critical. As expected, delayinga critical message will result in longer L1 cachemiss latencies. On the other hand, slight slowdownsin the delivery of non-critical messages will not causeany performance degradation. Applying Reply Partitioningwe can split reply messages that carry datainto a short critical message containing the sub-blockof the cache requested by the core as well as a longnon-critical message with the whole cache line. Thispartitioning allows for a more energy-efficient use ofthe heterogeneous interconnect since now all shortmessages have been made critical whereas all longmessages have been made non-critical. The formercan be sent through L-Wires whereas the latter canbe sent through PW-Wires. Using this criterion, allmessages related with prefeching could be consideredas non-critical because they deal with data blocksthat will be needed in the future. It is clear thatenergy is saved, theoretically without affecting performanceif the delay imposed is not too high, whenthis kind of messages travel on slower, power-efficientPW-Wires. Critical messages will be sent through L-Wires.Fig. 4 (top) plots the fraction of each messagetype for a 16-core CMP configuration when strideprefetching (K=1, 3) is considered and for the applicationsused in our evaluation (see section IV-A for evaluation details). Results have been normalizedwith respect to a base configuration withoutprefetching. As pointed out before, hardwareprefetching significantly increases on-chip communication.Average increases of about 20% in networktraffic are observed. And, on average, between 18%to 32% of the network traffic is due to prefetching(prefetch requests, their corresponding replies andall coherence traffic involved), whereas the rest hasto do with ordinary messages.Even more interesting is Fig. 4 (bottom) whichshows a breakdown of the network power consumptionfor each message type. Again, results are normalizedwith respect to the network power consump-JP2011-229

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIConfiguration of the evaluated baseline CMParchitecture and applications.CMP ConfigurationProcess technology65 nmTile area 25 mm 2Number of tiles 16Cache line size64 bytesCore4GHz, in-order 2-way modelL1 I/D-Cache32KB, 4-wayL2 Cache (per core) 256KB, 4-way, 6+2 cyclesMemory access time400 cyclesNetwork configuration2D meshNetwork bandwidth75 GB/sLink width75 bytes (8X-B-Wires)Link length5 mmApplicationProblem sizeBarnes-Hut16K bodies, 4 timestepsEM3D 9600 nodes, 5% remote links, 4 timestepsFFT256K complex doublesLU-cont 256 × 256, B=8Ocean-Nonc258 × 258 gridUnstructuredmesh.2K, 5 timestepsWater-spa512 molecules, 4 timestepsFig. 4. Breakdown of the messages that travel on the interconnectionnetwork for a 16-core CMP (top) and percentageof the power consummed in the interconnect by each typeof message (bottom).tion when no prefetching technique is used. Theamount of power consumed in the interconnect associatedwith prefetching traffic ranges from 21-35%depending on K.As previously commented, most of this power isconsumed in the point-to-point links, and therefore,message size plays a major role. In particular,prefetch replies are 67-byte long since they carrycontrol information (3-bytes) and a cache line (64bytes). On the contrary, requests and coherencecommands are 11-byte long since beside control information(3 bytes) they also carry address information(8 bytes). Finally, coherence replies are just3-byte long. The use of a heterogeneous interconnectcomprised of low-latency L-Wires and powerefficientPW-Wires allows for a more energy-efficientinterconnect utilization. However, as the number ofL-Wires is smaller because of their four-fold areacost (relative to baseline wires) only short messagescan take full advantage of them, this includes partialreplies generated by Reply Partitioning mecanishmwith almost negligible cost in terms of execution time(average degradation of 3%)in response to both ordinaryand prefetch requests. On the other hand,since message size has direct impact on the powerdissipated in the interconnect, significant energy savingscan be obtained when long messages, includingprefetched lines, are sent using PW-Wires. It is importantto note that we also split prefetched lines toavoid an increment of late prefetches.IV. Experimental ResultsThis section shows the results that are obtained forour proposal under different scenarios and comparethem against those achieved with the configurationthat employs just B-Wires, which is taken as baseline.A. Evaluation MethodologyThe results presented in this work have been obtainedthrough detailed simulations of a full CMP.We have employed a cycle-accurate CMP powerperformancesimulation tool, Sim-PowerCMP [26],that estimates both dynamic and leakage power andis based on RSIM . In particular, Sim-PowerCMPemploys as performance simulator a modified versionof RSIM that models the architecture of the tiledCMP presented in section III. Sim-PowerCMP alsoimplements already proposed and validated powermodels for both dynamic power and leakage powerof each processing core, as well as the interconnectionnetwork.Table II (top) shows the architecture configurationused across this paper. It describes a 16-core CMPbuilt in 65 nm technology. The tile area has beenfixed to 25 mm 2 , including a portion of the secondlevelcache [1]. With this configuration, links that interconnectrouters configuring the 2D mesh topologymeasure around 5 mm. Table II (bottom) shows theapplications used in our experiments. Barnes-Hut,FFT, LU-cont, Ocean-Nonc and Water-nsq are fromthe SPLASH-2 benchmark suite; Berkeley EM3Dsimulates the propagation of electro-magnetic wavesthrough objects in three dimensions; and Unstructuredis a computational fluid dynamics applicationthat uses an unstructured mesh. Problem sizes havebeen chosen commensurate with the size of the L1caches and the number of cores used in our simulations.All experimental results reported in this workJP2011-230

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011are for the parallel phase of these applications.B. Simulation results and analysisIn this section we analyze the impact of our proposalon both the execution time and the power consumptionfor the inter-core links. All results havebeen normalized with respect to the baseline nonprefetchingconfiguration where only B-Wire, unidirectional75-byte wide links are considered (with theexception of Fig. 7 where results are normalized withrespect to a 16-core CMP with stride prefetching).Fig. 6. Classification of the different types of prefetches observedfor the B-Wire only L- + PW-Wire interconnect.Fig. 5. Normalized execution time for different prefetchingschemes (with and without heterogeneous links) for a 16-core CMP.Fig. 5 shows the normalized execution times withrespect to that obtained for the baseline configurationfor a 16-core CMP without prefetching. In particular,barlines show the normalized execution timesfor the stride-based prefetch technique (K=1, 3) appliedto the L1D private caches. Each prefetcher containsthree separate filter tables: positive unit stride,negative unit stride, and non-unit stride. Once a filtertable entry detects a miss stream, the prefetcherallocates an entry in the stream table and initiatesthe prefetch of K consecutive cache blocks. Forcomparison purposes, the normalized execution timeobtained when only B-Wires are employed is alsoshown. On average, we obtain average improvementsin execution time that range from 5% (K=3)to 8% (K=1) when no heterogeneous network is considered,which demonstrates the convenience of usinghardware prefetching in future many-core CMPs.This improvement has high variability, ranging fromalmost negligible or even a slight degradation forBarnes, Unstructured and Water-SPA to improvementsof 20-25% for em3d and Ocean-Nonc.This observed variability is due to the memory accesspatterns exhibited by the applications. Someapplications, as FFT or LU-Cont, present regularmemory access patterns that lead to high percentageof useful prefetches. as we can see in Fig. 6 (top)where we present a classification of the prefetches. Inthis figure, prefetches are classified into: useful if theprefetched line is accessed before being replaced, lateif other requests coalesce into the MSHR allocatedfor the prefetched line, useless if the prefetched linegets replaced before it is requested by the processor,unnecesary if the prefetch coalesces into a MSHRfor an already-on-the-fly cache miss, and invalidatedif the prefetched line gets invalidated before beingrequested by the processor.On the other hand, applicationssuch as Water shows a high percentage oflate or useless prefetches that lead to negligible improvementsin the execution time.Going back to Fig. 5 again, when heterogeneouslinks are considered, an average slowdown of about3% is observed with respect to the B-Wire-onlyconfiguration with prefetching. This degradationis explained by the additional delay of sending theprefetch replies through PW-Wires. Results showthat 2-5% of the previously useful prefetches are nowclassified as late prefetches, explaining the observedslowdown.Fig. 7. Normalized link enery consumption for stride prefetching(K=1, 3) over L- + PW-Wires links (baseline configuration:16-core CMP with prefetching).However, the benefits of using a heterogeneous interconnectin the context of hardware prefetching, aswe propose, can be noticed when considering the networkenergy dissipation. Fig. 7 plots the normalizedlink energy when Reply Partitioning is used over L-+ PW-Wires links. The baseline configuration is a16-core CMP with the same prefetching configurationbut using only B-Wire links. Reductions of upto 75% are obtained (55-60% on average) and in thiscase the variability among applications is reduced.Better results are obtained, as expected, for K=3 dueJP2011-231

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011to the bigger emphasis on prefetching traffic (as seenin Fig. 4). This leads to more important reductionsin the link energy dissipation when prefetched linesare sent through PW-Wires. These improvementstranslate into average energy reductions of 7% whenthe full CMP is considered.V. ConclusionsIn this work we propose a energy-efficient messagemanagement mechanism for tiled CMPs that consistsof two approaches. The first one is Reply Partitioning,a technique that allows all coherence messagesto be classified into two groups: critical andshort, and non-critical and long. In particular, ReplyPartitioning concentrates on replies that carrydata, including prefethed lines, and splits them intoa critical and short Partial Reply message that carriesthe word requested by the processor and a noncriticalOrdinary Reply with the rest of the cacheblock. The second approach of our proposal is theuse of a heterogeneous interconnection network comprisedof low-latency wires for critical messages andlow-energy wires for non-critical ones which also allowsfor a more balanced workload.Results obtained through detailed simulations of a16-core CMP show that the proposed on-chip messagemanagement mechanism can reduce the energydissipated by the links of the interconnection networkabout 60%, on average, with little impact in the executiontime (degradation of 3%, on average). Finally,these reductions translate into overall CMP energysavings of 7%. These results reveal that correctlyorganizing the interconnection network and properlymanaging the different types of messages through ithave significant impact on the energy consumed byCMPs, especially for next-generation dense CMP architectures.AcknowledgmentsThis work was supported by the Spanish MEC andMICINN, as well as European Comission FEDERfunds, under Grants CSD2006-00046 and TIN2009-14475-C04.References[1] Michael Zhang and Krste Asanovic, “Victim Replication:Maximizing Capacity while Hiding Wire Delay inTiled Chip Multiprocessors,” in Proc. of the 32nd Int’lSymp. on Computer Architecture (ISCA-32), June 2005,pp. 336–345.[2] S. Vangal, J. Howard, G. Ruhl, et al., “An 80-Tile1.28TFLOPS Network-on-Chip in 65nm CMOS,” inSolid-State Circuits Conference (ISSCC’07), 2007, pp.98–589.[3] R. Ho, KW. Mai, and MA. Horowitz, “The Future OfWires,” Proceedings of the IEEE, vol. 89, no. 4, pp. 490–504, April 2001.[4] Hang-Sheng Wang, Xinping Zhu, et al., “Orion: APower-Performance Simulator for Interconnection Networks,”in Proc. of the 35th Int’l Symp. on Microarchitecture(MICRO’02), November 2002, pp. 294–305.[5] Nir Magen, Avinoam Kolodny, Uri Weiser, and NachumShamir, “Interconnect-Power Dissipation in a Microprocessor,”in Proc. of the 6th Int’l Workshop on SystemLevel Interconnect Prediction (SLIP-6), February 2004,pp. 7–13.[6] Rajeev Balasubramonian, Naveen Muralimanohar, et al.,“Microarchitectural Wire Management for Performanceand Power in Partitioned Architectures,” in Proc. of the11th Int’l Symp. on High-Performance Computer Architecture(HPCA-11), February 2005, pp. 28–39.[7] Antonio Flores, Juan L. Aragón, and Manuel E. Acacio,“Heterogeneous Interconnects for Energy-Efficient MessageManagement in CMPs,” IEEE Trans. Comput., vol.59, no. 1, pp. 16–28, 2010.[8] Rakesh Kumar, Victor Zyuban, and Dean M. Tullsen,“Interconnections in Multi-Core Architectures: UnderstandingMechanisms, Overheads and Scaling,” inProc. of the 32nd Int’l Symp. on Computer Architecture(ISCA-32), June 2005, pp. 408–419.[9] Tien-Fu Chen and Jean-Loup Baer, “Effective Hardware-Based Data Prefetching for High-Performance Processors,”IEEE Trans. Comput., vol. 44, no. 5, pp. 609–623,1995.[10] Doug Joseph and Dirk Grunwald, “Prefetching UsingMarkov Predictors,” in Proc. of the 24th Int’l Symp. onComputer Architecture (ISCA’97)), 1997, pp. 252–263.[11] Amir Roth, Andreas Moshovos, and Gurindar S. Sohi,“Dependence Based Prefetching for Linked Data Structures,”SIGPLAN Not., vol. 33, no. 11, pp. 115–126,1998.[12] Glenn Hinton, Dave Sager, et al., “The Microarchitectureof the Pentium 4 Processor,” Intel Technology Journal,vol. 1, 2001.[13] B. Sinharoy, R. N. Kalla, et al., “POWER5 System Microarchitecture,”IBM J. Res. Dev., vol. 49, no. 4/5, pp.505–521, 2005.[14] W. Anacker and C. P. Wang, “Performance Evaluationof Computing Systems with Memory Hierarchies,” IEEETrans. on Computers, vol. 16, no. 6, pp. 764–773, december1967.[15] A.J. Smith, “Sequential Program Prefetching in MemoryHierarchies,” Computer, vol. 11, no. 12, pp. 7–21, 1978.[16] Alan Jay Smith, “Cache Memories,” ACM Comput.Surv., vol. 14, no. 3, pp. 473–530, september 1982.[17] Norman P. Jouppi, “Improving Direct-Mapped CachePerformance by the Addition of a Small Fully-AssociativeCache and Prefetch Buffers,” SIGARCH Comput. Archit.News, vol. 18, no. 3a, pp. 364–373, 1990.[18] Fredrik Dahlgren, Michel Dubois, and Per Stenström,“Sequential Hardware Prefetching in Shared-MemoryMultiprocessors,” IEEE Trans. Parallel Distrib. Syst.,vol. 6, no. 7, pp. 733–746, 1995.[19] Ando Ki and Alan E. Knowles, “Adaptive Data PrefetchingUsing Cache Information,” in Proc. of the 11th Int’lConf. on Supercomputing (ICS’97), 1997, pp. 204–212.[20] Viji Srinivasan, Edward S Davidson, and Gary S Tyson,“A Prefetch Taxonomy,” IEEE Trans. on Computers,vol. 53, pp. 126–140, 2004.[21] Bradford M. Beckmann and David A. Wood, “TLC:Transmission Line Caches,” in Proc. of the 36th Int’lSymp. on Microarchitecture (MICRO-36), December2003, pp. 43–54.[22] Naveen Muralimanohar and Rajeev Balasubramonian,“The Effect of Interconnect Design on the Performanceof Large L2 Caches,” in 3rd IBM Watson Conf. on Interactionbetween Architecture, Circuits, and Compilers(P=ac2), October 2006.[23] Liqun Cheng, Naveen Muralimanohar, et al.,“Interconnect-Aware Coherence Protocols for ChipMultiprocessors,” in Proc. of the 33rd Int’l Symp.on Computer Architecture (ISCA’06), June 2006, pp.339–351.[24] A. Flores, J.L. Aragón, and M.E. Acacio, “Energy-Efficient Hardware prefetching for CMPs Using HeterogeneousInterconnects,” in Proc. of the 18th EuromicroInt’l Conf. on Parallel, Distributed and Network-Based Computing (EUROMICRO-PDP’10), February2010, pp. 147–154.[25] Li Zhao, Ravi Iyer, et al., “Performance, Area and BandwidthImplications on Large-Scale CMP Cache Design,”in Proc. of the 1st Workshop on Chip MultiprocessorMemory Systems and Interconnects (CMP-MSI’07). Inconjunction with HPCA-13), February 2007.[26] Antonio Flores, Juan L. Aragón, and Manuel E. Acacio,“An Energy Consumption Characterization of On-ChipInterconnection Networks for Tiled CMP Architectures,”J. Supercomput., vol. 45, no. 3, pp. 341–364, 2008.JP2011-232

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Modelling Permanent Fault Impact onCache PerformanceDaniel Sánchez 1 , Yiannakis Sazeides 2 , Juan L. Aragón 1 and José M. García 1Abstract—The probability of parametric and wear-out failuresexacerbates due to the increase of static and dynamicvariations. Specifically, caches that dominate the areaof modern processors and are built with minimumsizedSRAM cells are very susceptible to faults.In this paper, we present an analytical model fordetermining the implications on cache miss-rate dueto the use of block-disabling, a mechanism which disablesfaulty portions of the cache, to mitigate randomcell failure. Whereas previous proposals are basedon the simulation of different fault-maps, our modelavoids them and provides exact measures rather thanapproximations.Our evaluation reveals, for the assumptions, programsand cache configuration used in this study,that a relative small number of random fault maps,100-1000, is sufficient to obtain accurate mean andstandard-deviation values for the miss-rate.I. IntroductionOver the past 50 years, technological advanceshave enabled continuous miniaturization of circuitsand wires. Unfortunately, the scaling of device areahas been followed by at least two negative consequences:a slowdown of both voltage scaling andfrequency increase, due to slower scaling of leakagecurrent as compared to area scaling [1], [2] and ashift to probabilistic design and less reliable siliconprimitives as a result of static [3] and dynamic [4]variations.A recently published resilience roadmap underlinesthe magnitude of the problem we are confrontedwith [5]. Table I shows the predicted p fail (probabilityof failure) for inverters, latches and SRAM cellsdue to random dopant fluctuations as a function oftechnology node. This study clearly shows that, forall types of circuits, the p fail increases at a muchfaster rate than the area scaling. However, not all circuitsare equally vulnerable: SRAM cells, which areusually built with minimum-sized devices, are highlymore likely to fail. These alarming trends are leadingto forecast that the performance and cost benefitsfrom area scaling will be hindered unless scalabletechniques are developed to address the power andreliability challenges. Thus, the development of reliabilitytechniques for future processors which areboth scalable and performance-effective is essential,especially for caches that take most of the real-estatein processors and contain numerous SRAM vulnerablecells.One option is to rely on the error-correction-codes(ECC) already in place to detect and correct soft-1 Dept. of Computer Engineering, Univ. of Murcia. e-mail:{dsanchez,jlaragon,jmgarcia}@ditec.um.es2 Department of Computer Science, Univ. of Cyprus. e-mail:yanos@cs.ucy.ac.cyTABLE IPredicted p fail for different types of circuits andtechnologies.Technology Inverter Latch SRAM45nm ≈ 0 ≈ 0 6.1e-1332nm ≈ 0 1.8e-44 7.3e-0922nm ≈ 0 5.5e-18 1.5e-0616nm 2.4e-58 5.4e-10 5.5e-0512nm 1.2e-39 3.6e-07 2.6e-04errors. However, ECC is not a performance-friendlymechanism for permanent errors because, potentially,every access to a faulty block will incur theECC repair overhead. Furthermore, ECC soft-errorcapabilities are reduced when some bits protected bythe ECC code are already faulty. Thus, ECC maynot be the best option to repair a large number ofparametric or wear-out faults in a cache.Another approach is to disable cache portions suchas blocks or words [6], [7], [8] that contain faulty bitsupon permanent error detection (at manufacturingor in the field). These disabled blocks are not replacedwith a spare 1 , which results in a reduction ofcache capacity. Block disabling is an attractive optionbecause of its low overhead, e.g., 1 bit per cacheblock 2 , but the reduced cache capacity can degradeperformance. Therefore, it is important to determinethe performance implications of block disabling toassess its usefulness.Previous block disabling-based studies (such as [7],[9], [10], [11], [12], [13], [14], [15]) rely on the use ofan arbitrary number (small or large) of random faultmaps.Each random fault-map indicates faulty cachecell locations and determines the disabled faultycache blocks. The fault-maps are used either toobtain the performance degradation of a programthrough cycle accurate simulation, or to determinethe impact on miss-rate of a program’s address trace.However, the number of fault maps used in thesestudies is very small as compared to the number ofall possible maps. Therefore, the accuracy of previouswork in predicting expected performance has notbeen established.Our proposition to address this shortcoming is ananalytical model that calculates the Expected MissRatio (EMR) for a given address trace of an application,cache configuration and random probabilityof permanent cell failure. Furthermore, we show1 Disabling can be employed after spares have been exhausted.2 This logical bit needs to be resilient either through circuitdesign or extra protection, because if faulty it renders wholecache faulty.JP2011-233

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011how to obtain the standard deviation for the EMR(SD MR) which provides an indication for the rangeof expected degradation of the cache. Finally, we explainhow to produce a probability distribution forthe EMR for a given number of faulty blocks. Allthese are accomplished without producing or usingfault-maps. This analytical model can be useful formanufacturers to analyze the impact of permanentfaults in caches and tune their designs by using anappropriate number of spares or modifying the granularityof disabling techniques.The model capabilities are demonstrated throughan analysis of the trends of the cache miss-rate meanand standard deviation with smaller feature size (andp fail ) for L1 data caches.The remainder of the paper is organized as follows:Section II presents our model to calculate the EMRand SD MR. In Section III we describe the methodologyand the evaluation results. Finally, Section IVresumes the main conclusions of this work.II. Exact Model for Cache Miss RateBehavior with FaultsIn this section, we present an analytical modelthat can determine the Expected Miss Ratio (EMR),standard deviation of the Miss Ratio (SD MR), and aprobability distribution of miss-ratios (PD MR) for agiven program address trace, cache configuration andrandom probability of permanent cell failure. TheEMR captures the average cache performance degradationdue to random faulty cells. The SD MR providesindication about the range of this performancedegradation, whereas PD MR reveals its shape (distribution).These characteristics can be used to assessthe implications of faults in a cache and comparedifferent cache reliability schemes.A. Assumptions and DefinitionsThe model assumes that permanent faulty cells occurrandomly (uncorrelated) with probability p fail .This random fault behavior is indicative of faults dueto random-dopant-fluctuations [16] and line-edgeroughness[17], two prevalent sources of static variations.The systematic component of process variationmanifests itself at a larger scale (e.g., at thegranularity of microarchitectural units or whole core)and can be addressed by coarse-grain techniques likebody biasing [3]. The random variation occurs at afiner grain and cannot be handled with manufacturingprocess tuning or coarse grain techniques [18].The model presented in this work assumes that thesystematic failures have been addressed and examinesthe implications of random faults in memorycells.A cache configuration is defined by the numberof sets (s), ways per set (n), and block size in bits(k). We consider a block containing one or more permanentlydamaged bits as faulty. In that case, thefaulty block is disabled, reducing the capacity of thecache. Faults are assumed to be detected with postmanufacturingand/or boot time tests, ECC, andbuilt-in self tests. The model is suited for policiesthat induce total priority order in the replacement.In our case, we have focused on a basic LRU policy.Each program address trace is simulated througha cache simulator to obtain, for a given cache configuration,the vector M. This vector contains n + 1elements, an element more than the number of cacheways. M i corresponds to the total misses when thereare only n − i valid ways in each set in the cache.More specifically, M i equals to sum of all the referenceswhich hit in the i least recently used blocksin each set, plus the misses of the fault free cache.For example, M 0 equals to the misses of a fault-freecache, M n represents the misses of a cache in whichevery way is entirely faulty, meaning all accesses aremisses, and M 1 equals to the misses of the fault-freeplus all the hits in the LRU position.B. EMR and SD MRThis section shows how the model obtains theEMR and SD MR given a cell’s p fail , cache configurationand the miss vector of an address trace. Themodel calculates the probability for a cache blockfailure using the following expression (based on wellknownbinomial probability):p bf = 1 − (1 − p fail ) k (1)Although p bf provides information about the fractionof blocks that are expected to fail in the cache,the impact on the miss ratio is unknown, as it dependson the fault location and the amount of accesseswhich maps to faulty block locations. However,with the p bf we can obtain the probability distributionpe i for the number of faulty ways in a set: npe i = p i bfi (1 − p bf ) n−i (2)which provides, for every possible value of i [0...n],the probability of having n−i non-faulty ways. Thisdistribution is very useful because it provides insightabout how likely it is to lose a given numberof ways in a set and, what is more important,it can be used to obtain the expected numberof misses. The expectation of a random variableX = x 0 , x1..., x m in which each possible value hasprobability p = p 0 , p 1 , ..., p m is calculated as:E[X] =mx i · p i (3)i=0In our case, the random variable X corresponds tothe total number of misses for a cache with faults; x icorresponds to the total misses when there are onlyn − i valid ways in each set in the cache; and p i theprobability of having i faulty ways in a set. Therefore,we can express the expectation of the numberof cache misses with disabled blocks as:E misses =nM i · pe i (4)i=0JP2011-234

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011and obtain the expected miss ratio of the cacheusing:EMR = E misses(5)accessesThis simple formula can be used to obtain the exactEMR without using fault-maps. I.e. it determinesthe EMR as if all possible fault-maps for agiven random p fail had been taken into account. Thekey insight behind this formula, expressed better inEq. 2, is that caches have a useful property: for thesame number of faulty blocks f in a set, the reducedassociativity will be the same n − f. I.e., for analyzingblock-disabling, what matters is the number offaulty-ways in a set, not which specific ways in theset are faulty. Thus, the complexity of the problemis reduced.The EMR provides a useful indication about theaverage case performance for a given p fail . However,we have no information about the variation in themiss ratio. Variation is useful for assessing whetherdisabled blocks lead to caches with wide variation(less predictable) miss rate.One way to measure this variation is through thestandard deviation of the MR or SD MR. Unfortunately,the standard deviation cannot be directly obtainedfor the whole cache. However, given that wealready know the probability distribution of faultyblocks in a set, we can calculate variation as:∀j[0...s], V AR E missesj =npe i · (x ij − E missesj ) 2i=0(6)where x ij is the number of misses obtained whenhaving n − i non-faulty ways in the j th set.Although the total EMR is equal to the sum ofindividual sets EMR j :EMR =sEMR j (7)j=1we cannot combine the variation of each set in thesame way. Instead, we compute the deviation for themisses of the whole cache SD MR by using the rootmean square in the form: sV AR EMR jj=1SD MR =(8)accessesC. MR probability distributionThe SD MR only provides the range of deviationof the miss ratio. But, what may be more usefulto know is a probability distribution of cache misses(PD MR) within the deviation range.We propose to build a probability distribution ofmisses in a stepwise manner. We first calculatethe EMR for every possible number of faulty blocks(from 0 to the number of cache blocks), and thenwe combine this information with the probability ofthat given number of faulty blocks to occur.Equation 9, similar to Equation 2, gives the probabilityof x number of faulty blocks, for a given blockprobability failure: s · nxp x bf (1 − p bf ) s·n−x (9)This equation can be evaluated for different x valuesto obtain a probability distribution. Then, weneed to calculate the EMR for every possible numberof faults. So far, this problem has been solvedby means of random fault-maps [9].For a given number of faults, this problem is analogousto selecting at random n balls from an urnthat contains dk balls without replacement, where dis the number of unique colours and k is the numberof balls of each color. The urn represents the cache,the variable n the faults, d the number of blocks andk the number of bits in each block. The mean numberof distinct blocks, u, that contains at least onefaulty cell in a cache with n faulty cells can be approximatedwith high accuracy [19]:u = d − d(1 − p fail ) k (10)This means that we can obtain the PD MR analytically,without fault-maps, by simply using Equation10 to convert the number of faulty blocks to p fail .This, gives us the expression:p faili = 1 − k s · n − xis · n(11)This way, we can calculate which p fail results inx i faults in the cache. Then, every p faili can beused to calculate the EMR associated to each numberof faulty blocks, therefore, generating a probabilitydistribution.A. MethodologyIII. EvaluationThe input to our model is a map of accesses to acache for every application. To produce these mapswe have used an algorithm called all-associativitysimulation [20], previously used in [9]. This algorithmhas a complexity order of O(n 2 ). However,in practice, the complexity is much lower because ofaccess locality, which limits the length of searchesdramatically. Due to space limitations, we have notdiscussed this but refer to [20] for details. It is importantto note, though, that the algorithm is appliedoffline and, with a single run per benchmark, is ableto produce the data our model needs to evaluate anydesired cache configuration.The all-associativity algorithm takes as input atrace of memory requests which converts into a mapof cache accesses for any desired configuration (setsand ways) following a given replacement policy (LRUin our case). This allows us to obtain the number ofaccesses per way and per set within a single run. Theoutput of the algorithm is a matrix in which each rowcorresponds to a set and each column to a positionJP2011-235

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011in the LRU sequence. Each value of the matrix indicatesthe number of accesses to every position inthe LRU sequence for every set. This informationis very useful for offline analysis given that we candetermine the number of misses for a given numberof ways w in our cache by simply adding the accessesfor the last n − w columns of the matrix.We can also use this matrix to compute the misseswith faulty cells. For this purpose, and accordingto Equation 5, we need to calculate the number ofmisses if a given number of ways were disabled inthe cache due to permanent faults. First, we accumulatethe number of accesses in every position perset. Then, we perform the same operation per setto obtain a vector which indicates the exact numberof misses our cache would suffer as a consequence oflosing from 0 to w ways.For our experiments, we have simulated a processorarchitecture by means of Virtutech Simics [21]and GEMS [22]. Simics is a functional simulator executinga Solaris 10 Unix distribution simulating theUltraSPARC-III ISA. GEMS is a timing simulatorwhich, coupled to Simics, provides detailed resultsfor the memory system. We have performed severalmodifications to the simulator to extract cache addresstraces. Then, these traces are used to generatethe map of accesses for every possible cache configurationby means of the all-associativity algorithm asexplained previously.We have conducted our experiments by executingdifferent applications from the SPECcpu-2000 [23](bzip2, gap, gzip, parser, twolf, vpr). Benchmarksare run for 1 billion of cycles. In all cases, the warmingup of caches has been taken into account.The different p fails used for the evaluation of thecaches are shown in Section I with the exception of6.1e-13, which produces virtually no faulty blocks inour experiments. Additionally, we have evaluatedp fail of 1e-03 which is considered in many relatedpapers.B. Random Fault Map MethodologyBefore proceeding to determine the EMR usingthe proposed methodology we determine how wellrandomly generated fault-maps approximate the expectednumber of faults obtained using Eq. 1.In Figure 1 we can see the probability distributionof the number of faulty blocks for different p fails (wehave omitted 7.3e-09 and 1.5e-06 because they offerfrom 0 to 1 and 0 to 4 faulty blocks, respectively)in a 32KB, 2-way associative cache with 558 bits perblock 3 . Results show the estimated faulty blocks obtainedanalytically (analytical line) and by differentnumbers of faulty maps (from 100 to 10 millions). Asit is observed, few faulty maps are not able to capturethe exact behaviour of the analytical model. However,when the number of maps increases (1K mapsor more), the number of faulty blocks becomes moreaccurate. Nonetheless, this study cannot concludehow well random maps approximate the expectedmisses of a cache, since misses directly depend onthe location of faults among the different cache sets.C. EMR and SD MR for SPEC applicationsIn this section we show the calculated EMR andSD MR for several benchmarks and a 2-way 32KBL1 cache with different p fails .Surprisingly we can see in Figure 2 that a smallnumber of faulty maps, 100-1000, is enough to approximatethe EMR and SD MR provided by themodel. The reason for this is the access homogeneityto the different sets of the cache. In other words, forthe applications we have evaluated, there are no particularsets that are clearly more accessed than othersduring the overall execution of the benchmark. Thismakes the EMR and SD MR virtually independentfrom the fault locations and that is the reason whyfault maps are able to provide such good estimations.We establish the cache access homogeneity with astudy of the correlation of accesses between all thesets in our cache by calculating the Pearson correlationcoefficient. When the Pearson coefficient is closeto 0, it means that there is no correlation betweenvariables, whereas when it is close to 1, it means acorrelation between them. We have calculated thematrix of correlations of the number of accesses for a2-way 32KB L1 cache for the evaluated benchmarks.Table II reflects the average value for the Pearson coefficientsas well as its standard deviation. As we cansee, all coefficients are very close to 1, which meansthat the accesses among sets are highly correlated.TABLE IIPearson Coefficient Matrix for each benchmark.Benchmark Mean Pearson Coeff. DEVbzip2 .993 .007gap .9 .086gzip .997 .002parser .998 .003twolf .943 .119vpr .995 .006The key insight from this study is that, becauseof the high correlation, a small number of randomfault maps is sufficient to obtain accurate expectedcache behavior with faults. If data accesses amongsets are not highly correlated, a few fault maps wouldnot be able to provide an accurate prediction of theexpected behaviour with faults.D. PD MR for SPEC applicationsIn Section II-C, we have developed a method tocalculate a PD MR for the expected values of theEMR. As explained, we follow a constructive approach,calculating the different p fail from 0 to nfaulty blocks. Then, for each of these values we calculateits EMR.3 We consider blocks comprised of: 64 bytes for data and 11bits for its ECC, 25 bits for the tag and 7 bits for its ECC,and 3 control bits for valid, disable and dirty states.JP2011-236

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011 (a) (b) (c)Fig. 1. Probability distribution of the number of faulty blocks obtained by our model and by random fault-maps in a 2-wayassociative 32KB cache. (a) (b) (c) (d) (e) (f)Fig. 2. EMR and SD MR for different applications in a 2-way associative 32KB L1 cache with different p fails . (a) (b) (c) (d) (e) (f)Fig. 3.PD MR for different applications and p fails in a 2-way associative 32KB L1 cache.JP2011-237

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011The probability distribution results in Figure 3provides valuable information. As a consequence ofthe increasing number of faulty blocks, the shape ofthe distribution is wider with higher p fails . Within asingle chart we can infer the likelihood of a miss ratein our cache to occur according to the used technologyscale. As a conclusion, this study revealsthat, in the future, the performance of caches will bemore un-predictable due to permanent errors. Thismodel could be used by chip manufacturers to analyticallydetermine what is going to be the expectedpercentage of chips that should be discarded becauseof faulty cells.IV. ConclusionsThis paper proposes an analytical model to determinethe Expected Miss Ratio (EMR) and itsStandard Deviation (SD MR) for a given applicationwhen it is executed in a cache with a randomprobability of cell failure. This analytical model enablesdesigners to perceive the real impact of faultsin caches without the need of executing any experimentswith random fault maps. We have also presentedan analytical model which provides the probabilitydistribution for the EMR which represents anothervaluable information for designers about theshape of the miss-rate distribution of faulty cacheunits for a given process technology.In the evaluation we show, for the benchmarksand configurations used, that the random fault mapmethodology provides high accuracy when using 100-1000 maps for an L1 data cache. This is due to thehigh homogeneity of accesses to the different sets ofa cache which makes the EMR and SD MR virtuallyindependent of the allocation of faults.AcknowledgementsThis work has been jointly supported by the SpanishMEC and European Commission FEDER fundsunder grants “Consolider Ingenio-2010 CSD2006-00046” and “TIN2009-14475-C04-02”. DanielSánchez is also supported by a research grant fromthe Spanish MEC under grant “Consolider Ingenio-2010 CSD2006-00046” and a mobility grant byHiPEAC (FP7 Network of Excellence). The researchleading to this paper is supported by the EuropeanCommission FP7 project “Energy-conscious3D Server-on-Chip for Green Cloud Services (ProjectNo:247779 “EuroCloud”)”.Bibliography[1] S. Borkar, “Design challenges of technology scaling,”IEEE Micro, vol. 19, no. 4, pp. 23 –29, 1999.[2] Y. Taur, “CMOS design near to the Limit of Scaling,”IBM Journal of Research and Development, vol. 46, no.2/3, pp. 213–222, 2002.[3] Shekhar Borkar, Tanay Karnik, Siva Narendra, JimTschanz, Ali Keshavarzi, and Vivek De, “Parameter variationsand impact on circuits and microarchitecture,” inProceedings of the 40th annual Design Automation Conference.2003, pp. 338–342, ACM.[4] Keith Bowman, James Tschanz, Chris Wilkerson, Shih-Lien Lu, Tanay Karnik, Vivek De, and Shekhar Borkar,“Circuit techniques for dynamic variation tolerance,” inProceedings of the 46th Annual Design Automation Conference.2009, pp. 4–7, ACM.[5] Sani R. Nassif, Nikil Mehta, and Yu Cao, “A resilienceroadmap,” in Design, Automation, and Test in Europe,2010, pp. 1011–1016.[6] David A. Patterson, Phil Garrison, Mark Hill, DimitrisLioupis, Chris Nyberg, Tim Sippel, and Korbin VanDyke, “Architecture of a vlsi instruction cache for arisc,” in Proceedings of the 10th Annual InternationalSymposium on Computer Architecture. 1983, pp. 108–116, ACM.[7] G. S. Sohi, “Cache memory organization to enhance theyield of high performance vlsi processors,” IEEE Transactionson Computers, vol. 38, pp. 484–492, April 1989.[8] C. McNairy and J. Mayfield, “Montecito error protectionand mitigation,” HPCRI’05: 1st Workshop on HighPerformance Computing Reliability Issues, in conjunctionwith HPCA’05, 2005.[9] A.F. Pour and M.D. Hill, “Performance implications oftolerating cache faults,” IEEE Transactions on Computers,vol. 42, no. 3, pp. 257 –267, 1993.[10] Philip P. Shirvani and Edward J. McCluskey, “Paddedcache: A new fault-tolerance technique for cache memories,”in Proceedings of the 17TH IEEE VLSI Test Symposium.1999, pp. 440–, IEEE Computer Society.[11] Hyunjin Lee, Sangyeun Cho, and B.R. Childers, “Performanceof graceful degradation for cache faults,” inIEEE Computer Society Annual Symposium on VLSI,2007, pp. 409 –415.[12] Hyunjin Lee, Sangyeun Cho, and B.R. Childers, “Exploringthe interplay of yield, area, and performance inprocessor caches,” in 25th International Conference onComputer Design, 2007, pp. 216 –223.[13] T. Ishihara and F. Fallah, “A cache-defect-aware codeplacement algorithm for improving the performance ofprocessors,” in IEEE/ACM International Conference onComputer-Aided Design, Nov 2005, pp. 995 – 1001.[14] D. Roberts, Nam Sung Kim, and T. Mudge, “On-chipcache device scaling limits and effective fault repair techniquesin future nanoscale technology,” in 10th EuromicroConference on Digital System Design Architectures,Methods and Tools, 2007, pp. 570 –578.[15] N. Ladas, Y. Sazeides, and V. Desmet, “Performanceeffectiveoperation below vcc-min,” in IEEE InternationalSymposium on Performance Analysis of SystemsSoftware, 2010, pp. 223 –234.[16] A.J. Bhavnagarwala, Xinghai Tang, and J.D. Meindl,“The impact of intrinsic device fluctuations on cmos sramcell stability,” Solid-State Circuits, IEEE Journal of, vol.36, no. 4, pp. 658 –665, apr 2001.[17] B. Cheng, S. Roy, G. Roy, F. Adamu-Lema, andA. Asenov, “Impact of intrinsic parameter fluctuationsin decanano mosfets on yield and functionality of sramcells,” Solid-State Electronics, vol. 49, no. 5, pp. 740 –746, 2005.[18] Keith Bowman, David Brooks, Gu-Yeon Wei, and ChrisWilkerson, “Tutorial on design variability: Trends, modelsand design solutions,” in Tutorial at MICRO’08, Nov.2008.[19] S. B. Yao, “Approximating block accesses in databaseorganizations,” ACM Communications, vol. 20, pp. 260–261, April 1977.[20] M. D. Hill and A. J. Smith, “Evaluating associativity incpu caches,” IEEE Transactions on Computers, vol. 38,pp. 1612–1630, December 1989.[21] P. S. Magnusson, M. Christensson, J. Eskilson, D. Forsgren,G. Hallberg, J. Hogberg, F. Larsson, A. Moestedt,B. Werner, and B. Werner, “Simics: A full system simulationplatform,” Computer, vol. 35, no. 2, pp. 50–58,2002.[22] Milo M. K. Martin, Daniel J. Sorin, Bradford M. Beckmann,Michael R. Marty, Min Xu, Alaa R. Alameldeen,Kevin E. Moore, Mark D. Hill, and David A. Wood,“Multifacet’s general execution-driven multiprocessorsimulator (gems) toolset,” SIGARCH Computer ArchitectureNews, vol. 33, no. 4, 2005.[23] J.L. Henning, “Spec cpu2000: measuring cpu performancein the new millennium,” Computer, vol. 33, no.7, pp. 28 –35, July 2000.JP2011-238

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Coherencia de Caché Mediante Árbol Basadoen Proximidad y PredicciónAntonio García-Guirado 1 Ricardo Fernández-Pascual 1 José M. García 1Resumen— Los protocolos de coherencia decaché basados en estructuras enlazadas como listas(SCI) o árboles mantienen la información de comparticiónrepartida entre varios nodos. De esta forma, seconsigue que la memoria necesaria por nodo crezca logarítmicamentecon el número de nodos (n·log(n) paratodo el CMP) en lugar de hacerlo linealmente (n 2 paratodo el CMP) como ocurre en un directorio convector de bits, y además sin perder exactitud comosucede con otros códigos de compartición. Sin embargo,estos esquemas tienen como principal desventajala alta latencia de las invalidaciones que provocan lasescrituras. En este artículo presentamos un protocolode coherencia que utiliza un árbol que, como novedad,tiene en cuenta la distancia entre compartidoresy utiliza predicción de proveedor para obtener los datos.Nuestro protocolo mantiene todos los beneficiosde las estructuras enlazadas a la vez que elimina susinconvenientes, e incluso presenta nuevas ventajas encomparación con otras propuestas.I. IntroducciónCONFORME aumenta el número de procesadoresintegrados en un chip, el mantenimiento de lacoherencia de caché mediante hardware se hace máscostoso. Los mecanismos basados en broadcast sonpoco escalables debido a que necesitan un medio decomunicación totalmente ordenado y compartido portodos (por ejemplo, un bus), lo que complica su usoen chips con decenas de procesadores. A su vez, losmecanismos basados en directorio también presentanproblemas de escalabilidad, siendo el principal problemalos altos requisitos de almacenamiento para lainformación sobre los compartidores de los bloquesde memoria. En el caso del código de comparticiónmás simple, conocido como full-map bit-vector, cadaposible compartidor se codifica como un bit queestá activo si el compartidor tiene una copia del bloque,por lo que su sobrecarga con respecto a la capacidadtotal de la caché del chip es proporcionalal número de procesadores. Otros códigos reducenla sobrecarga a cambio de perder exactitud (lo quegenera tráfico de red innecesario).Hasta ahora, un CMP podía proporcionar coherenciade caché mediante un bus o un directorio simpledebido al reducido número de procesadores que contenía.Sin embargo, los chips actuales ya comienzana integrar decenas de procesadores y, debido a la dificultadde mantener la coherencia para tantos nodos,algunos prototipos han optado por eliminar la coherenciahardware y en su lugar recurrir al uso pasode mensajes para la comunicación entre los distintosprocesadores, lo que complica la tarea del programador.Existen muchas propuestas que intentan solventarlos problemas de escalabilidad del directorio. Algunasse remontan a más de veinte años atrás, comoSCI [1] (Scalable Coherence Interface), que proponía1 Departamento de Arquitectura e Ingeniería deComputadores, Universidad de Murcia, e-mail:{toni,r.fernandez,jmgarcia}@ditec.um.esel uso de una lista enlazada de compartidores de unbloque en la que cada compartidor tenía un punteroque apuntaba al siguiente. Esto reduce la sobrecargaen almacenamiento de la información de coherencia,que en SCI es proporcional al logaritmo del númerode procesadores en el chip. Sin embargo, SCI es muyineficiente al invalidar bloques compartidos por muchosprocesadores, ya que la invalidación no se completahasta que la lista de compartidores es invalidadade manera secuencial. Para mejorar el comportamientode SCI se propusieron esquemas basados enárboles [2, 3, 4, 5] en los que el número de saltos en elcamino crítico de las invalidaciones pasaba a ser proporcionalal logaritmo del número de compartidores.Sin embargo, la gestión de estos árboles no es sencilla.Por ejemplo, la introducción de nuevos compartidorespuede necesitar la reestructuración del árbol, y elreemplazo de un nodo puede requerir la invalidaciónde toda la rama que hay bajo él, lo que incrementael número de fallos de caché de los nodos invalidadosinnecesariamente. Además, las invalidaciones siguensiendo costosas ya que requieren varios saltos en elcamino crítico entre nodos que están en posicionesaleatorias del chip.Nosotros proponemos un nuevo protocolo de coherenciade caché que, manteniendo las ventajas de laslistas y árboles, soluciona sus principales problemasy aporta nuevas e interesantes ventajas. Basándonosen la distancia entre nodos, la información de coherenciase mantiene en un árbol distribuido geográficamentepor el chip, lo que reduce la distancia entrenodos contiguos del árbol y por tanto el tráfico necesariopara su comunicación. Esto permite que el usode predicción en las peticiones de lectura haga queun nodo del árbol cercano físicamente al peticionariopueda proveer el dato.Las aportaciones de nuestra propuesta son las siguientes:Dos nodos consecutivos en el árbol se encuentranpróximos físicamente en el chip. Esto haceque las comunicaciones entre nodos sean másrápidas y generen menos tráfico. Reducimos eltráfico de las escrituras en hasta un 95 % con respectoa un directorio full-map en algunos tiposde fallo.Mediante predicción de destino de las peticionesde lectura podemos obtener el bloque desde unnodo cercano de manera más rápida y generandomenos tráfico. Para permitir esto, cualquiercompartidor puede proporcionar la copia de unbloque cuando recibe una petición de un nuevocompartidor. Reducimos el camino crítico de laslecturas en hasta un 96 % y el tráfico en hastaun 95 % con respecto a un directorio full-map.JP2011-239

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Directorio SCIArbol Arbol basado en proximidadH H H HFig. 1. Información de coherencia en directorio, SCI, árbol y árbol basado en proximidad. L1s con copia del bloque mostradasen gris. Home L2 señalado con una H. Nótese como el árbol basado en proximidad es el único que reduce la distancia entrenodos contiguos.II. Arquitectura Base.Este trabajo utiliza una arquitectura tiled-CMP.En ella, el chip se forma mediante replicación de tiles.Cada tile contiene un core, una caché L1 privaday un banco de la caché L2 compartida. Los bloquesde memoria se mapean a los bancos de L2 usandovarios bits de la dirección de bloque. La L2 a la queun bloque se mapea se llama “home L2”, y contienela información de directorio del bloque si existen copiasdel mismo en las L1s. Utilizamos un esquema deestados MOESI para la coherencia de los bloques dememoria. Los tiles se comunican mediante interfacesde red formando una malla 2D. No obstante, nuestroprotocolo puede aplicarse a cualquier otra arquitecturade memoria compartida.III. Árbol Basado en Proximidad yPredicciónEl árbol binario que contiene los compartidores deun bloque parte del nodo home L2, que almacenaun puntero a la L1 que es raíz del árbol. Las cachésL1 tienen tres punteros asociados a cada entrada decaché: uno para apuntar al nodo padre (puede ser elhome L2 u otra L1) y el resto para apuntar a hastados hijos (que serán cachés L1). Inicialmente noexiste árbol para el bloque. La primera caché L1 queaccede al bloque envía su petición al home L2 y pasaa ser el nodo raíz del árbol. Cuando aparece unnuevo compartidor (una L1 que envía una peticiónde lectura al home L2), la petición se reenvía a laraíz, que provee el dato y almacena la identidad delnuevo compartidor, el cual almacena la identidad delnodo que le contesta en el puntero reservado para elnodo padre en su entrada de caché. Al surgir máscompartidores se llenan los punteros del nodo raíz,y entonces es necesario recorrer el árbol hacia abajo,eligiendo ramas aleatoriamente, hasta encontrarun puntero libre. Cada mensaje enviado hacia abajoen el árbol es asentido por su receptor para evitarcarreras de coherencia. El peticionario además debeesperar a recibir la identidad de su padre (el nodo enel que se encontró un puntero libre) antes de poderreemplazar el bloque. En cualquier caso, la raíz proveeel dato para mantener corto el camino crítico delos fallos de lectura.Al producirse un reemplazo no invalidamos elsubárbol bajo el nodo que reemplaza, sino que utilizamosun mecanismo de reemplazo que reestructurael árbol. En él participan un abuelo, un padre y hastados hijos del padre. Con un intercambio de 7 mensajesse reestructura el árbol de modo que el enlaceentre el abuelo y el padre se sustituye por un enlaceentre el abuelo y uno de sus nietos, y el otro nieto pasaa formar parte del subárbol de su hermano (lo quepuede implicar más mensajes para poder acomodaral hermano en un puntero libre). Este reemplazo esmás costoso que un reemplazo en SCI, pero evita invalidartodo el subárbol bajo el nodo que reemplaza,y previene condiciones de carrera.El hecho de tener la información de coherencia distribuidaen un árbol presenta oportunidades para optimizacionesque no se pueden realizar en enfoquesque mantienen la información de coherencia de unbloque en un único punto. A continuación veremoscómo aprovechar el árbol para enlazar nodos cercanosy para obtener bloques cercanos, y las ventajasque esto nos aporta.A. Proximidad en el ÁrbolUn árbol distribuido en el chip puede crearse demanera que cada par de nodos contiguos se encuentrenfísicamente próximos en el chip. Esto trae importantesventajas en cuanto a tráfico cuando se realizancomunicaciones entre nodos contiguos del árbol,como puede ser el caso de una escritura de un bloqueque debe recorrer el árbol completamente parainvalidar a todos los compartidores, o a la hora derealizar un reemplazo.Hemos optado por una opción sencilla para creary gestionar el árbol que consiste en que, cuando unnodo no tiene punteros libres para almacenar a unnuevo compartidor, envía la información del nuevocompartidor al hijo que se encuentre más cerca físicamentedel nuevo compartidor. Esto hace que, conformebajamos por las ramas del árbol, vayamos encontrandonodos más cercanos entre sí. Un ejemplode la estructura de la información de coherencia enun directorio, en SCI, en un árbol y en nuestro árbolbasado en proximidad puede verse en la Figura 1.Es posible balancear el árbol cuando se produceninserciones o reemplazos para mantener distanciasmínimas entre nodos, pero creemos que las gananciasserán mínimas en comparación con el incremento enla complejidad de la gestión del árbol. Es por elloque hemos optado por no realizar balanceo de ningúntipo.B. PredicciónEl uso de predicción de proveedor ante un fallode lectura en caché puede aprovecharse de la proximidadfísica de los procesadores en el árbol. Unprocesador puede usar a su antiguo padre en el árbolcomo proveedor si es que el padre sigue teniendo unacopia válida del bloque. Como el padre se encuentrafísicamente próximo en el árbol gracias a nuestromecanismo de inserción, el fallo de caché se resolverácon menor latencia y generando menos tráficoque si tuviésemos que acceder al nodo home, que pue-JP2011-240

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Sin prediccionPrediccionPrediccion en arbol basado en proximidadOwnerOwner3−Dato2−Peticion de lectura2−DatoHomeHomeHome1−Peticion de lectura1−Peticion de lectura2−Dato1−Peticion de lecturaPPPFig. 2. Resolución de un fallo de caché sin predicción (introduce un nivel de indirección para acceder al directorio), conpredicción (elimina el nivel de indirección), y con predicción en un árbol basado en distancia (además se accede al dato enun nodo cercano). L1s con copia del bloque mostradas en gris. Nodo peticionario señalado con una P.de estar en cualquier lugar del chip. En caso de unamala predicción (el antiguo padre ya no tiene copiadel bloque) la penalización en distancia recorrida esreducida, ya que el nodo predicho se encuentra cercadel solicitante.El mecanismo para predecir es similar al de Di-Co [6]. Cada nodo tiene una pequeña caché, llamadaL1C$, que contiene predicciones indexadas por direcciónde bloque. Ante un fallo de lectura en caché L1se busca en la L1C$ una predicción para el bloqueal que se desea acceder. Si se encuentra, la peticiónse envía al nodo predicho. Si no es así, la petición seenvía al nodo home.Para obtener buenas predicciones la gestión de laL1C$ es fundamental. Cuando un bloque es reemplazadoen la caché L1, el puntero al padre que habíaen tag del bloque se almacena en la L1C$ como predicciónpara un futuro acceso al bloque. La Figura 2muestra la resolución de un fallo en un directorio,usando predicción y usando predicción en el árbolbasado en distancia.Ante un fallo de escritura la petición siempre sedirige al nodo home, es decir, no se realiza predicción.Esto es así porque el nodo home actúa como puntode serialización de todas las peticiones de escritura, yes a partir de él que se genera la invalidación de todoárbol para poder dar permiso exclusivo de escrituraal nodo peticionario.IV. Metodología.Nuestro objetivo es probar varios protocolos decoherencia en algunos escenarios concretos. Porejemplo, es de especial interés el caso en que un bloquedel que existen muchas copias es escrito por unprocesador, provocando la invalidación de todas lascopias. El mayor problema de SCI es su mal comportamientoen ese escenario concreto, y uno de losobjetivos de nuestra propuesta de árbol es mejorarese caso.Para hacer esto hemos desarrollado una herramientaque nos sirve para poder hacer pruebas deeste tipo manera sencilla. En ella hemos implementadoúnicamente la funcionalidad y las estadísticasdeseadas de los protocolos. Ésta herramienta consideraun único bloque de memoria sobre el que losprocesadores realizan accesos de lectura, accesos deescritura y reemplazos de caché siguiendo algún tipode patrón o distribución estadística de interés. Porsimplicidad, sólo implementamos los fallos y reemplazosde L1, y éstos se resuelven siempre sin necesidadde ir a memoria (consideramos que el bloquesiempre está presente en L2).La mayor ventaja de esta herramienta es que evitamosla complejidad de las condiciones de carrera:las operaciones de memoria de todos los procesadoressobre el único bloque se ejecutan secuencialmente.Gracias a ello sólo debemos implementar la funcionalidadde los protocolos correspondiente al casocomún y simple en que no hay ningún problema derivadode la concurrencia entre accesos. Es por tantomuy simple implementar protocolos en la herramienta,ya que sólo hay que codificar tres operaciones delos mismos: fallo de lectura de L1, fallo de escriturade L1 y reemplazo del bloque en L1.Esta herramienta puede funcionar basándose enuna serie de probabilidades. En ese caso va eligiendoprocesadores aleatoriamente, y usando estas probabilidadesdecide si realizar una lectura (en caso deque la L1 no tenga el bloque), una escritura, o un reemplazo(en caso de sí tener el bloque). También esposible que no se realice ninguna acción. Para modelarel escenario comentado anteriormente se hanajustado las probabilidades de modo que estadísticamentecasi todas las L1s lean el bloque (y tambiénrealicen reemplazos) y en un momento dado se produzcauna escritura de un procesador, lo que provocauna invalidación de casi todas las L1s del chip. Otrosescenarios pueden codificarse de manera similar.Una gran ventaja de nuestra herramienta con respectoa simuladores como GEMS [7] es que podemosrealizar una primera evaluación rápida de laspropuestas. La herramienta nos permite obtener estadísticasde escenarios concretos fácilmente, sin necesidadde crear checkpoints o de crear manualmentetrazas de accesos como entrada al simulador que denlugar al tipo de escenario que nos interese probar.Esta herramienta tiene además otra gran ventaja:al ser tan sencilla y rápida, permite modelar máquinascon gran cantidad de cores. En concreto, paraeste artículo se han realizado pruebas con hasta8192 cores. Los simuladores como GEMS, debidoa su complejidad, sólo permiten modelar máquinasmás modestas (p. ej., 64 cores) si queremos que lassimulaciones se ejecuten en un tiempo razonable (p.ej., menos de una semana) en los nodos de computaciónde los que se dispone actualmente.Una vez realizada una primera exploración y trashaber seleccionado los protocolos más prometedores,como trabajo futuro realizaríamos la implementaciónde estas propuestas en el lenguaje de especificaciónde protocolos SLICC para poder realizar simulacionesdetalladas en GEMS. Esta implementación escompleja y requiere un tiempo considerable. Nuestraherramienta nos permite descartar propuestas pocoprometedoras evitando emplear grandes cantidadesJP2011-241

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Links Camino Critico Lectura200180160140120100806040200dirSCItreetreePredtreeDisttreePredDist4 8 16 32 64 128 256 512 1024 2048 4096 8192Numero de Cores(a) Número medio de enlaces en elcamino crítico de una petición de lectura.Links Camino Critico Escritura50004000300020001000dirSCItreetreePredtreeDisttreePredDist04 8 16 32 64 128 256 512 1024 2048 4096 8192Numero de Cores(c) Número medio de enlaces en elcamino crítico de una petición de escritura.Flits Medios Generados por cada Lectura2000180016001400120010008006004002000dirSCItreetreePredtreeDisttreePredDist4 8 16 32 64 128 256 512 1024 2048 4096 8192Numero de Cores(b) Número medio de flits generados por una petición de lectura.Flits Medios Generados por cada Escritura700000600000500000400000300000200000100000dirSCItreetreePredtreeDisttreePredDist04 8 16 32 64 128 256 512 1024 2048 4096 8192Numero de Cores(d) Número medio de flits generados por una petición de escritura.Fig. 3. Estadísticas para el peor escenario de SCI.de tiempo en implementarlas en simuladores complejos.A. Protocolos evaluados.En nuestra herramienta hemos implementado unprotocolo de directorio básico, el protocolo de listaSCI y cuatro versiones distintas de de protocolos basadosen árboles, a saber:Tree: en lugar de tener una lista como SCI, tenemosun árbol binario. Cuando un nodo no tienepunteros para añadir a un nuevo compartidor,se envía la información por una rama aleatoria.Tree con predicción (treePred): es como el árbolanterior, pero usamos predicción similar a la deDiCo en las peticiones de lectura. Las peticionesse envían al ex-padre del peticionario en el árbol.Las peticiones pueden acertar o fallar (fallaránpor ejemplo si el ex-padre ya no tiene el bloquedebido a un reemplazo o a una escritura deotro nodo), por tanto no estamos utilizando deninguna implementación tipo oráculo para laspredicciones sino una implementación relativamenterealista.Tree con uso de distancia (treeDist): es comoel protocolo tree, salvo que en caso de no tenerpunteros libres para añadir al peticionario se eligela rama con el nodo hijo más cercano al peticionariopara enviarle la información del nuevocompartidor. La idea es que los nodos cercanoslógicamente en el árbol sean nodos cercanos físicamente,para así reducir los flits necesarios ensus comunicaciones.Tree con predicción y distancia (treePredDist):sería la unión de los dos últimos protocolos mencionados.La idea es que al predecir al proveedorusando al ex-padre del peticionario en el árbol,tratándose ahora de nodos cercanos, podemosreducir los flits necesarios en una petición e inclusomejorar el rendimiento.V. EvaluaciónA. Escrituras de bloques muy compartidos.En este escenario se selecciona un tile aleatorio encada acceso. Una vez elegido el tile, se puede producirun reemplazo (en caso de estar el bloque en la L1 deltile), una lectura del bloque (que puede ser local siel bloque está en L1 o traer el bloque a L1 si no loestá) o una escritura. La probabilidad de producir unreemplazo, dado que el bloque esté en la L1, la hemosfijado en un 5/(2 ∗ n) sobre 1, donde n es el númerode cores en la máquina. La probabilidad de produciruna escritura la hemos fijado en un 1/(2 ∗ n) sobre 1.El resto de accesos son lecturas (locales o remotas).Estas probabilidades aseguran que las escrituras seproducen cuando la mayoría de las L1s tienen copiadel bloque, y estas copias deben ser invalidadas. Estepatrón es además bastante interesante en cuanto alas predicciones: el porcentaje de lecturas en las quese realiza predicción es de un 50 %, con un acierto depredicción de un 90 %. Estos valores entran dentrodel rango de lo que consideramos normal en DiCo,que es el protocolo en el que basamos el sistema depredicciones.Como vemos en la Figura 3a, al predecir (tree-Pred), las lecturas se resuelven con un camino críticohasta un 11 % más corto. Esta reducción es mayorsi además tenemos en cuenta la distancia al montarel árbol (treePredDist), llegando hasta un 36 % dereducción, ya que de ese modo el proveedor que espredicho es un nodo cercano.En cuanto a los flits generados al realizar una lectura(Figura 3b), tenemos que los árboles añaden flitsdebido a que la identidad del solicitante debe enviarsepor el árbol hasta encontrar un nodo con punteroslibres. Nótese que estamos hablando de un caso extremoen que el árbol fuera enorme. En cualquier ca-JP2011-242

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Links Camino Critico Lectura200180160140120100806040200dirSCItreetreePredtreeDisttreePredDist4 8 16 32 64 128 256 512 1024 2048 4096 8192Numero de Cores(a) Número medio de enlaces en elcamino crítico de una petición de lectura.Flits Medios Generados por cada Lectura2500200015001000500dirSCItreetreePredtreeDisttreePredDist04 8 16 32 64 128 256 512 1024 2048 4096 8192Numero de Cores(b) Número medio de flits generados por una petición de lectura.Fig. 4. Estadísticas para el mejor caso para árbol.so, al usar distancias para formar el árbol reducimosmuchísimo el número de flits extra, ya que recorrerel árbol supone recorrer nodos cercanos y no nodosa distancia arbitraria, como sucede si no se usa ladistancia.En cuanto a las escrituras, podemos comprobar enla Figura 3c el pésimo rendimiento de SCI. El númerode enlaces en el camino crítico es proporcional alnúmero de nodos en la lista. Por el contrario, en elcaso del directorio tenemos que el camino crítico esproporcional a la raíz cuadrada del número de coresdel chip (ya que esa raíz cuadrada determina ladistancia media entre cores aleatorios), lo que proporcionauna camino crítico mucho menor.Los árboles tienen un camino crítico medio proporcionala la raíz cuadrada del número de coresdel chip multiplicada por el logaritmo del númerode compartidores. A pesar de que esto supone unamejora importante con respecto a SCI, las propuestasde árbol que no usan distancia al montar el árbolse siguen comportando mal en comparación con eldirectorio. Al usar distancia (treeDist, treePredDist)tenemos unos valores para el camino crítico que, aunqueligeramente mayores que los del directorio, estánmucho más cerca del directorio que de SCI o de laspropuestas de árbol que no usan distancia.En cuanto a los flits generados en las escrituras (Figura3d), el directorio, a pesar de tener un caminocrítico muy pequeño, como veíamos anteriormente,produce un número de flits similar al de SCI. Larazón es que en ambos casos se necesitan dos mensajesde control con origen y destino aleatorio porcada L1 a invalidar, por lo que la cantidad de tráficogenerado es muy similar en ambos casos. Los árbolespor sí mismos (tree, treePred) tampoco reducenen nada este número de flits. Es al usar la distanciaentre nodos al crear el árbol (treeDist, treePredDist)cuando conseguimos reducir el tráfico notablemente,y la reducción obtenida es muy considerable: 95 %menos de tráfico que el directorio en las invalidacionesen una máquina con 8192 cores y un 50 % menosde tráfico con tan sólo 64 cores.B. Bloques de sólo lectura.Este escenario comienza con todos los nodos leyendoel bloque. Una vez hecho esto, las hojas del árbolrealizan reemplazos y vuelven a pedir el bloque. Enningún momento se realizan escrituras. Como vemos,el camino crítico de las lecturas (Figura 4a) se mantienecasi constante en treePredDist, ya que siemprese predice un nodo compartidor cercano físicamente,independientemente del tamaño del chip. Esto reduceel camino crítico de las lecturas con respecto al directorio:hasta un 96 % menos de enlaces recorridospara 8192 cores. Además, al contrario que en el escenarioanterior, gracias a la predicción treePredDistgenera notablemente menos tráfico que el directorioy SCI, un 95 % menos.C. Información de coherencia.Pasamos ahora a ver el tamaño de las estructurasutilizadas por los protocolos que estamos evaluandopara almacenar la información de coherencia. EnL2, una entrada de directorio full-map utiliza un bitpor core en cada entrada, mientras que el resto deprotocolos sólo necesitan un puntero a un nodo porentrada. Un puntero tiene un tamaño igual al logaritmoen base dos del número de nodos en el chip.En L1, el protocolo basado en directorio no necesitaalmacenar información sobre compartidores. Porsu parte, SCI necesita dos punteros en los tags deL1 para mantener la lista doblemente enlazada. Laspropuestas de árbol necesitan tres punteros en lostags de L1 (dos para los hijos y uno para el padre).Teniendo en cuenta esto, el overhead del directoriocrece linealmente con el número de cores (almacenamientoproporcional a n 2 para todo el CMP), y eldel resto de protocolos crece logarítmicamente conel número de cores (almacenamiento proporcional an · log(n) para todo el CMP).D. Latencia de escrituras.En el directorio, la latencia de las escrituras conmuchos compartidores tiene un componente que dependelinealmente del número de compartidores, yaque todos los ACKs se reciben en el mismo nodo.Mientras el número de compartidores sea pequeño,éste componente lineal tiene poca incidencia, y elcomponente dominante es la distancia atravesada enel camino crítico, que es proporcional a la raíz cuadradadel número de cores en el chip. Sin embargo,al aumentar el número de cores y compartidores, llegaráun momento en que el componente lineal se impondrásobre el componente proporcional a la distanciaatravesada, y el nodo que recibe todos los ACKsse convertirá en un importante cuello de botella enlas escrituras a datos muy compartidos.Por otro lado, cuando se utiliza un árbol, cada nodorecibe como máximo dos ACKs, correspondientesa sus dos hijos. Con esto se elimina el componentelineal de la latencia de las escrituras, y se evita así elcuello de botella. Como consecuencia, la latencia delas escrituras depende del número de niveles del árbolmultiplicado por la distancia entre nodos adyacentes.Esta latencia es proporcional a log(n) · √n.JP2011-243

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Si además usamos distancia al crear el árbol, losnodos adyacentes en el árbol se encuentran cercanosfísicamente en el chip. Al aumentar el tamañodel chip no aumenta significativamente la distanciaentre dos nodos consecutivos de una rama. Esto locomprobábamos en la Sección V-B, donde al predeciral antiguo padre en las lecturas el tamaño delcamino crítico era independiente del número de cores.Por tanto, la latencia de las escrituras dependeúnicamente del número de niveles en el árbol, que esproporcional a log(n). Al crecer el número de cores enel chip, la latencia lineal de las escrituras en el directoriopasará a ser mayor que la latencia logarítmicadel árbol que usa distancia.VI. Trabajo relacionadoLa propuesta más cercana a nuestro protocolo deárbol basado en proximidad y predicción es la extensiónGLOW [8] para SCI. GLOW propone situaragentes estáticos que actúan como nodos intermediosde un árbol en el que los compartidores de un bloqueson las hojas. Normalmente, los agentes se sitúan enlos nodos en los que se produce un cambio de dimensiónen el routing hacia el nodo home del bloque (seasume un encaminamiento en orden de dimensión)y monitorizan el tráfico que gira en ese nodo. Cadaagente mantiene una lista SCI de los compartidorescuyo tráfico hacia el nodo home gira por primera vezen el nodo del agente. El agente también mantieneuna lista SCI de agentes cuyo tráfico hacia el nodohome gira por primera vez en el nodo del agente,para así formar el árbol. Esto hace que, en una malla,el árbol sólo tenga un nivel intermedio de agentes,ya que sólo se produce un giro para alcanzar elnodo home. En otras topologías (p. ej., hipercubos)pueden existir más giros y por tanto más niveles enel árbol. Los agentes se encargan de interceptar laspeticiones de memoria a bloques muy compartidospara resolverlas más rápidamente obteniendo el datode un compartidor de su lista SCI de compartidores.Esto implica consultar el directorio en el agente paracada petición detectada a bloque altamente compartido.Si la lista SCI local está vacía, el agente envíauna solicitud para añadirse a la lista de agentes delnivel superior y obtener el dato; el dato es enviadoal peticionario (que a su vez puede ser otro agentede nivel inferior), y el peticionario es añadido a lalista SCI local correspondiente del agente (según seaun nodo hoja u otro agente). Este árbol reduce lalatencia media de las lecturas y el camino crítico delas escrituras, ya que aunque siguen existiendo listasque invalidar, estas son más cortas y están formadaspor nodos relativamente cercanos.Sin embargo, GLOW tiene numerosos inconvenientescon respecto a nuestra propuesta, de los cualesnombramos sólo algunos: requiere añadir agentesque necesitan información de directorio para mantenerlas listas SCI (en una malla necesitaríamos unagente por nodo); requiere monitorizar e intervenir eltráfico por parte de los agentes; necesita detectar losbloques altamente compartidos de manera dinámicapara evitar que la intervención del tráfico por partede los agentes afecte negativamente al resto de peticiones;los bloques que no son altamente compartidossiguen usando SCI y no obtienen ningún beneficio; unnodo cercano con copia del dato sólo puede proveerloa un nodo solicitante en caso de que coincidan susagentes, y además con la indirección introducida poruno o varios agentes. En resumen, GLOW es un pasointermedio entre SCI y nuestra propuesta, pero quetiene un mayor coste y es más complejo.VII. ConclusionesHemos presentado un nuevo protocolo de coherenciabasado en árboles, predicción y proximidad, quemantiene las ventajas de los estructuras enlazadas decoherencia como SCI y evita sus principales inconvenientes.Las escrituras a bloques compartidos pormuchos nodos pasan a tener un camino crítico cuyalongitud es similar a la del directorio. Además, nuestroprotocolo aporta nuevas ventajas con respectoal directorio que se hacen más influyentes conformecrece el número de cores en el chip. Gracias al mecanismopara añadir nuevos compartidores en el árbol,que siempre selecciona la rama más cercana al nuevocompartidor, reducimos notablemente el tráfico generadoen la red. Éste se reduce en hasta un 95 %para las escrituras, con respecto a un directorio, enun chip con 8192 cores. Esta creación del árbol basadaen proximidad, unida al mecanismo de predicción,también reduce el camino crítico de los fallos de lecturaen hasta un 96 %, y su tráfico en hasta un 95 %,también para 8192 cores.AgradecimientosEste trabajo ha sido financiado por la FundaciónSéneca (Agencia Regional de Ciencia y Tecnología,Región de Murcia) mediante el proyecto00001/CS/2007, y por el MEC y la Comisión EuropeaFEDER mediante los proyectos “ConsoliderIngenio-2010 CSD2006-00046” y “TIN2009-14475-C04-02”. Antonio García-Guirado también es beneficiariode una beca de investigación del MEC bajoel Plan Nacional de Formación de Profesorado Universitario(FPU AP2008-04387).Referencias[1] D. V. James, A. T. Laundrie, S. Gjessing, and G. Sohi,“Scalable Coherent Interface,” Computer, vol. 23, no. 6,pp. 74–77, 1990.[2] Y.-C. Maa, D. K. Pradhan, and D. Thiebaut, “Two EconomicalDirectory Schemes for Large-Scale Cache CoherentMultiprocessors,” SIGARCH Computer ArchitectureNews, vol. 19, no. 5, pp. 10–18, 1991.[3] H. Nilsson and P. Stenstrom, “The Scalable Tree Protocol- A Cache Coherence Approach for Large-Scale Multiprocessors,”in Proceedings of the 4th International Conferenceon Parallel and Distributed Processing, pp. 498–506,1992.[4] R. E. Johnson, Extending the Scalable Coherent Interfacefor Large-Scale Shared-Memory Mutiprocessors. PhDin Computer Science, University of Wisconsin - Madison,2003.[5] Y. Chang and L. N. Bhuyan, “An Efficient Tree CacheCoherence Protocol for Distributed Shared Memory Multiprocessors,”IEEE Transactions on Computers, vol. 48,no. 3, pp. 352–360, 1999.[6] A. Ros, M. E. Acacio, and J. M. García, “A DirectCoherence Protocol for Many-Core Chip Multiprocessors,”IEEE Transactions on Parallel and Distributed Systems(TPDS), vol. 21, pp. 1779–1792, Dec. 2010.[7] M. M. K. Martin, D. J. Sorin, B. M. Beckmann, M. R.Marty, M. Xu, A. R. Alameldeen, K. E. Moore, M. D.Hill, and D. A. Wood, “Multifacet’s general executiondrivenmultiprocessor simulator (GEMS) toolset,” SI-GARCH Comput. Archit. News, vol. 33, pp. 92–99, November2005.[8] S. Kaxiras and J. R. Goodman, “The GLOW cache coherenceprotocol extensions for widely shared data,” in Proceedingsof the 10th International Conference on Supercomputing(ICS), pp. 35–43, 1996.JP2011-244

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Explotación de Técnicas de Especializaciónde Cores para Planificación Eficiente enProcesadores Multicore AsimétricosJuan Carlos Sáez 1 Manuel Prieto 2 Adrián Pousa 3 Alexandra Fedorova 4Resumen— Los procesadores multicore asimétricoscon repertorio común de instrucciones –AMPs (AsymmetricMulticore Processors)– han sido propuestos recientementecomo alternativa a los multicore simétricosconvencionales –SMP (Symetric Multicore Processors)–.En lugar de integrar en el chip cores del mismotipo, como nos ofrecen actualmente Intel y AMD ensus últimos productos, la idea consiste en combinarmúltiples cores simples con un número reducido decores más complejos. Es una aproximación semejanteal IBM Cell/BE, el ejemplo más destacado a nivel comercialde multicore heterogéneo, pero explícitamentese soporta un repertorio de instrucciones común entodos los cores para simplificar el desarrollo de software.Para transladar los beneficios de los sistemas AMPdirectamente a las aplicaciones es preciso disponer detécnicas que permitan especializar cada tipo de corepara la ejecución de aquellas aplicaciones que hacen deéste un uso más eficiente. Esta especialización puedellevarse a cabo por el planificador del sistema operativo.Nuestro trabajo presenta el planificador CAMP(Comprehensive scheduler for AMPs), que supera lasprincipales limitaciones presentes en otros algoritmosde planificación para AMPs propuestos hasta la fecha.A diferencia de otros algoritmos, CAMP combinala información acerca de las dos características delas aplicaciones que resultan cruciales para garantizaruna planificación efectiva en AMPs: la eficiencia enla utilización de los cores complejos del sistema y sugrado de paralelismo a nivel de hilo. Los resultadosobtenidos en un prototipo de sistema AMP diseñadopor Intel Labs revelan que CAMP es capaz de obtenerbeneficios significativos para un mayor espectrode cargas de trabajo que otros algoritmos propuestosanteriormente.Palabras clave— AMP, procesadores multicoreasimétricos, planificación, sistema operativo.I. IntroducciónLOS procesadores multicore asimétricos (AMPs)han sido recientemente propuestos como una alternativamás eficiente a los multicore simétricos actuales[1], [2]. Los AMPs integran cores que difierenen aspectos microarquitectónicos, área y consumo deenergía pero exponiendo un repertorio de instruccionescomún. Este tipo de procesadores integran dostipos de core: “rápidos” y “lentos”. Los cores rápidosimplementan sofisticadas características microarquitectónicas,como ejecución fuera de orden y especulativa,destinadas a incrementar el rendimientosecuencial. Por el contrario, los cores lentos están caracterizadospor una microarquitectura más simple y1 ArTeCS Group, Univ. Complutense de Madrid, e-mail:jcsaezal@fdi.ucm.es.2 ArTeCS Group, Univ. Complutense de Madrid, e-mail:mpmatias@dacya.ucm.es.3 III-LIDI, Univ. Nacional de La Plata, e-mail:apousa@lidi.info.unlp.edu.ar.4 Simon Fraser University, e-mail: fedorova@cs.sfu.ca.demandan menor área y consumo que los cores rápidosy complejos. Este hecho permite la integraciónde numerosos cores simples en el chip, ofreciendo unelevado paralelismo a nivel de hilo a expensas de unmenor rendimiento secuencial.El potencial de los sistemas AMPs puede explotarsemediante la aplicación de dos técnicas de especializaciónde cores:Especialización de ILP: Consideremos unacarga de trabajo constituida por aplicaciones intensivasen memoria e intensivas en CPU. Lasprimeras provocan frecuentes paradas del pipelinecomo consecuencia de numerosos accesos amemoria, y por tanto, utilizan la CPU ineficientemente.Las segundas hacen un uso más intensivode los recursos del procesador y experimentanun mayor speedup relativo al ejecutaren cores complejos con respecto a cores simples.La especialización de ILP permite maximizar elrendimiento en un AMP dando mayor prioridada las aplicaciones más intensivas en CPU paraejecutarse en cores complejos.Especialización de TLP: Esta técnica se basaen explotar la diversidad en el paralelismo anivel de hilo –TLP (Thread-Level Paralelism)–presente en una carga de trabajo. Consideremosuna carga de trabajo formada por aplicacionesparalelas y secuenciales, o bien, formada exclusivamentepor aplicaciones paralelas con fases secuenciales.Los cores rápidos del sistema AMPpueden usarse para acelerar aplicaciones secuencialeso para mitigar los cuellos de botella secuencialesde las aplicaciones paralelas. Por elcontrario, los abundantes cores lentos pueden reservarsepara ejecutar código paralelo.La explotación de estas técnicas de especializaciónpermite a los AMPs ofrecer un mayor rendimientopor vatio que sus equivalentes simétricos [3], [4]. Noobstante, ningún tipo de especialización puede serexplotado directamente por el hardware, sino que estarea del software de sistema el empleo de políticasde planificación que mapeen los distintos flujos deinstrucciones en los tipos de cores que permitan ejecutarlosde manera más eficiente.Los algoritmos de planificación propuestos hasta lafecha explotan sólo una técnica de especialización (deILP o de TLP), pero nunca ambas. Por este motivo,resultan efectivos únicamente para ciertas cargas detrabajo [5].En este trabajo presentamos CAMP, un algoritmoJP2011-245

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de planificación para AMPs que es capaz de combinarambas técnicas. CAMP toma decisiones de planificaciónen base al factor de utililidad de las aplicaciones,métrica que aproxima, en función del ILP y TLP deuna aplicación, el speedup global que ésta obtendríasi se permite que sus hilos de ejecución utilicen todoslos cores rápidos y complejos en el sistema, conrespecto a una ejecución donde sólo se utilizan coressimples. Para calcular el factor de utilidad de un hilode ejecución es preciso conocer su factor de ganancia,beneficio relativo que este experimenta al ejecutaren un core rápido con respecto a uno lento. En estetrabajo proponemos una metodología para el diseñosistemático de modelos de estimación de factores deganancia.Para la evaluación del planificador CAMP –implementado en el sistema operativo OpenSolaris–utilizamos un prototipo de sistema asimétrico diseñadoen Intel Labs [6]. A diferencia de la asimetríaen rendimiento que se consigue mediante la reducciónde la frecuencia de trabajo en algunos cores –técnicade emulación ampliamente usada por la comunidadcientífica [7], [4], [8], [5]–, este prototipo modela demanera más realista el tipo de asimetría que se suponeestará presente en futuros sistemas asimétricos,donde los cores exhiben diferencias más profundas anivel microarquitectónico [6].Este artículo consta de las siguientes secciones: lasección II analiza trabajos previos sobre planificaciónen AMPs; la sección III presenta el diseño y la implementacióndel algoritmo CAMP; en la sección IVdescribimos el proceso de generación de modelos deestimación de factores de ganancia; en la sección Vse muestran los resultados experimentales obtenidos;finalmente en la sección VI se enumeran las principalesconclusiones de este trabajo.II. Antecedentes y trabajos relacionadosEn esta sección realizamos un análisis de las propuestasprevias comenzando por aquellas que explotanespecialización de ILP. Posteriormente analizamosaquellos trabajos que estudian las capacidadesde los sistemas AMP para mitigar la ley de Amdahl.Kumar y otros [1], [2], hacen uso de los procesadoresAMP para explotar la diversidad de factoresde ganancia 1 –SF (speedup factor)– presente en unacarga de trabajo multiprogramada. Las aplicacionescon SF alto usan efecientemente los recursos hardwarepresentes en los cores rápidos y complejos queestán destinados a la extracción de ILP. Asignandolas aplicaciones con SF alto a los cores complejos ylas aplicaciones con SF bajo a los cores simples, sealcanzan incrementos en el rendimiento de hasta un63 % frente a un SMP de área similar [2].Los algoritmos propuestos por Kumar [2] y Becchi[3] requieren ejecutar las aplicaciones tanto encores simples como complejos para calcular su SF.1 El factor de ganancia (SF) de un hilo de ejecución se defineformalmente como IPS fast /IPS slow , donde IPS fast y IPS slowson el número de instrucciones por segundo (IPS) del hilo encores rápidos y lentos, respectivamente.El factor de ganancia de cada aplicación se aproximamediante el cociente del número de instruccionesretiradas por segundo (IPS) de la aplicación en coresrápidos y lentos. En un trabajo previo detectamosque esta técnica de medición directa de SFs introduceserios problemas de rendimiento, y mostramos quecalcular SFs de esta forma resulta inapropiado en lapráctica [7]. El empleo de técnicas de estimación delfactor de ganancia a partir de medidas de rendimientode la aplicación en un solo tipo de core permitesubsanar las limitaciones de la medición directa delSF [9], [10]. Por este motivo, el planificador CAMPemplea mecanismos de estimación.Los sistemas AMP se han estudiado también comoplataformas para mitigar la ley de Amdahl. Hilly Marty [11] dedujeron modelos teóricos para el speedupen arquitecturas AMP. Annavaram [4] propusoun planificador a nivel de aplicación que asigna acores rápidos las secuenciales explícitas presentes enuna aplicacion paralela, mitigando la ley de Amdahlde manera efectiva. En un trabajo previo presentamosel algoritmo PA (Paralelism-Aware), el primeralgoritmo implementado en un sistema operativo realque explota especialización de TLP [5]. A diferenciade la propuesta de Annavaram, el algoritmo PA ofrecesoporte para cargas de trabajo con múltiples aplicacionesy garantiza la aceleración de fases secuencialesen aplicaciones paralelas de forma totalmentetransparente, sin requerir modicación alguna en elcódigo fuente de la aplicación.III. Diseño e implementaciónLas asignaciones de hilos a cores realizadas porCAMP se llevan a cabo en base al factor de utilidadde cada hilo. Dado un sistema AMP con NFC coresrápidos, el factor de utilidad de un hilo de ejecución–UF (Utility Factor)– es una métrica que permiteaproximar el speedup que la aplicación al que el hilopertenece experimenta si NFC de sus hilos se asignana cores rápidos y el resto a cores lentos, con respectoa una ejecución donde solo se utilizan cores lentos.La fórmula para el UF, que se ha obtenido usandouna aproximación analítica descrita en [12], es de lasiguiente forma:UF =SF − 1(⌊ N threads−1NF C⌋ + 1) 2 + 1 (1)En la fórmula, N threads es el número de hilos deejecución activos de la aplicación. Este valor, que esvisible a nivel de sistema operativo, permite aproximareficientemente el paralelismo a nivel de hilo(TLP) de la aplicación [5]. SF es el factor de ganaciadel hilo de ejecución. La sección IV describe cómoCAMP aproxima el SF en tiempo de ejecución usandolos contadores hardware del procesador.CAMP clasifica los hilos en cuatro clases de utilidad–VERY LOW, LOW, MEDIUM y HIGH– quese asignan en función de sus UFs. Esta aproximaciónbasada en clases permite mitigar algunas imprecisionesen la estimación de los factores de ganancia(SFs), usados para el cómputo del UF, así como pa-JP2011-246

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA I: Correspondencia entre valores del UF yclases de utilidad.ClaseHIGHMEDIUMLOWVERY LOWRango de UFUF ≥ upper thresholdmedium threshold ≤ UF < upper thresholdlower threshold ≤ UF < medium thresholdUF < lower thresholdra dar un mismo trato a aquellos hilos con UFs muysimilares.La asignación de hilos a las clases de utilidad serealiza en función de tres umbrales específicos de plataforma–lower, medium and upper–, que determinanlas fronteras entre las clases. La tabla I muestra lacorrespondencia entre el valor del factor de utilidaddel hilo de ejecución y su clase de utilidad. Las clasesse muestran en la tabla en orden descendente por suprioridad para ejecutarse en cores rápidos, siendo loshilos de la clase de utilidad HIGH los que gozan demayor prioridad. Los cores rápidos se asignan a losdistintos hilos de ejecución siguiendo este orden deprioridad. En el caso de que existan cores rápidos sinasignar a hilos de la clase HIGH, estos cores restantesse asignarán a hilos de clases de menor prioridad. Elresto de hilos se ejecutaran en cores lentos. Excepcionalmente,si el número de hilos HIGH supera alnúmero de cores rápidos, estos cores se repartirán demanera equitativa entre hilos HIGH, utilizando paraello un mecanismo round-robin basado en migracionesperiódicas de hilos propuesto en [10].CAMP reserva una clase de utilidad especial (SE-QUENTIAL BOOSTED) para los hilos de una aplicaciónparalela que ejecutan fases secuenciales de lamisma y exhiben un SF alto (clase HIGH). Estoshilos gozan temporalmente de mayor prioridad paraejecutarse en cores rápidos que el resto de hilos declase HIGH, pertenecientes a aplicaciones monohilo.Este mecanismo ofrece mayores oportunidades paramitigar los cuellos de botella secuenciales presentesen las aplicaciones paralelas [9].IV. Estimación de Factores de GananciaEn esta sección detallamos el proceso de generaciónde un modelo de rendimiento que permite estimarel SF en un prototipo de sistema asimétricodiseñado en Intel Labs [6]. La sección V proporcionamás detalles acerca de esta plataforma y analizalos resultados obtenidos por el planificador CAMPen dicho prototipo.Koufaty y otros detectaron que en este sistemaexisten dos factores que muestran una clara correlacióncon el factor de ganancia [6]. El primer factor esla intensidad en memoria que exhibe la aplicación,que puede aproximarse mediante su tasa de fallos decache de último nivel [9]. El segundo factor está relacionadocon las paradas producidas en el front-enddel pipeline del procesador 2 . La figura 1 muestra lacorrelación entre el SF y estos dos factores para losbenchmarks de la suite SPEC CPU2006. Los datos2 Este factor puede aproximarse monitorizando el número deciclos que la cola de instrucciones está vacía.LLC misses per 1K instructionsinternal stalls per 1K cycles454035302520151050300250200150100500LLC miss rateSpeedup Factormcfastarlbmmilcsoplexgobmkbzip2leslie3dGemsFDTDgcccactusADMlibquantumsjenggromacszeusmpxalancbmksphinx3perlbenchwrfpovraynamdbwavesdealIItontoh264refgamesscalculixhmmer(a) Tasa de fallos de último nivel de cache vs. SFinternal stallsSpeedup Factormcfastarlbmmilcsoplexgobmkbzip2leslie3dGemsFDTDgcccactusADMlibquantumsjenggromacszeusmpxalancbmksphinx3perlbenchwrfpovraynamdbwavesdealIItontoh264refgamesscalculixhmmer(b) Paradas en el front-end del pipeline vs. SFFig. 1: Correlación entre distintas métricas de rendimientoy el SF observado para los benchmarks de lasuite SPEC CPU2006 ejecutando en el prototipo desistema asimétrico.revelan que tanto las aplicaciones intensivas en memoria(alta tasa de fallos de cache) como aquellas confrecuentes paradas en el front-end del pipeline suelenexperimentar factores de ganancia bajos. A pesar dela relevancia de estos resultados, diseñar un modelobasado únicamente en esta tendencia daría lugara graves fallos de predicción –por ejemplo, para elbenchmark gromacs–.En la búsqueda de metodologías sistemáticas paradiseñar modelos de estimación en escenarios complejos,como el que se estudia en este trabajo, exploramosdistintas técnicas de minería de datos usando laherramienta WEKA [13]. WEKA proporciona numerososmétodos para inferir relaciones entre un conjuntode observaciones (o atributos de entrada) y unavariable objetivo. En el problema de estimación deSFs, las observaciones se corresponden con distintosparámetros de rendimiento y la variable objetivo esel SF. Entre los métodos explorados, detectamos quela regresión aditiva [14] permite derivar un modelode estimación preciso para esta plataforma. Además,los coeficientes obtenidos tras el análisis de regresión2.221.81.61.41.212.221.81.61.41.21Speedup FactorSpeedup FactorJP2011-247

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MétricaIPCTABLA II: Métricas seleccionadasLLC miss rateL2 miss rateExecution stallsRetirement stallsDescripciónNúumero de instrucciones retiradaspor cicloNúmero de fallos de cache de últimonivel (L3) por cada mil instruccionesretiradasNúmero de fallos de cache de L2por cada mil instrucciones retiradasNumero de ciclos por cada mil ciclosde procesador en los ningunainstrucción ha finalizado su fase deejecuciónNumero de ciclos por cada mil ciclosde procesador en los que no seretira ninguna instrucciónaditiva permiten establecer un ranking de las métricasexploradas en base a su relevancia. Esta informaciónfacilita la selección del subconjunto de métricasque contribuyen en mayor medida a la aproximacióndel SF, permitiendo una utilización efectiva de loscontadores hardware del procesador.El proceso completo para la generación del modelode estimación puede resumirse en los siguientespasos:1. Seleccionar un conjunto AP de aplicaciones secuencialesrepresentativas y un conjunto M demétricas de rendimiento.2. Ejecutar las aplicaciones de AP en ambos tiposde core para obtener su SF y monitorizar lasmétricas de rendimiento en M usando los contadoreshardware del procesador.3. Construir el modelo de estimación para aproximarel SF desde cada core de la siguiente forma:a) Aplicar regresión aditiva para aproximar el SFusando como training set los SFs obtenidospara las aplicaciones en AP junto con los valoresde las métricas en M.b) Obtener el subconjunto de métricas SM ⊆ Mcon mayores coeficientes de regresión obtenidosen el paso anterior, tal que los contadoreshardware necesarios para monitorizar esasmétricas no exceda el número de contadoreshardware en la plataforma.c) Aplicar regresión aditiva de nuevo para obtenerel modelo de estimación final usando únicamentelas métricas en SM.Como conjunto AP de aplicaciones representativaspara construir el modelo en nuestra plataformaseleccionamos los benchmarks de las suites SPECCPU2006 y CPU2000. La tabla II describe el conjuntoSM de métricas, usado para la construcción delos modelos finales en ambos cores. Las figuras 2ay 2b muestran la comparación entre el SF observadoy el estimado en cores rápidos y lentos, respectivamente.Los resultados revelan una mayor precisiónen los SFs predichos desde el core rápido que desdeel lento. No obstante, este no es un comportamientoinesperado, ya que, intuitivamente, resulta muchomás sencillo predecir qué aplicaciones sufrirían másal reducir ciertas capacidades microarquitectónicasestimated SFestimated SF2.221.81.61.41.2mgrid00 applu00wupwise00perlbmk00crafty00galgel00sixtrack0011 1.2 1.4 1.6 1.8 2 2.2observed SF2.221.81.61.41.2lbm06(a) Estimación en el core rápidogobmk06mgrid00tonto06wupwise00hmmer06calculix0611 1.2 1.4 1.6 1.8 2 2.2observed SF(b) Estimación en el core lentoFig. 2: SFs observados y predichos para losbenchmarks de las suites SPEC CPU2000 y SPECCPU2000. Se proporciona el nombre de aquellas aplicacionescon peores resultados de predicción.en un core (estimación de SF desde el core rápido),que identificar de manera precisa qué programas experimentaríanlos mayores beneficios al añadir hardwareadicional (estimación de SF desde el core lento).Durante el proceso de diseño de CAMP detectamosque las imprecisiones presentes en el modelo deestimación de SF pueden mitigarse utilizando intervalosde SFs, en lugar de emplear directamente elvalor numérico proporcionado por la estimación. Lasfronteras entre los intervalos de SF mencionados semuestran en las figuras 2a y 2b como líneas rojashorizontales.Finalmente, cabe destacar que para realizar unaevaluación más exhaustiva de la efectividad de nuestromodelo, hemos incluido experimentos con cargasde trabajo que incluyen aplicaciones que no han estadoinvolucradas en la generación de los modelos deestimación (sección V).V. ExperimentosPara el análisis del planificador CAMP hemos empleadoun prototipo de sistema asimétrico diseñadoJP2011-248

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA III: Cargas de trabajo multiaplicación constituidaspor aplicaciones secuencialesCT Categorías BenchmarksSR1 2H-2L calculix, gamess, gobmk,milcSR2 2H-2L hmmer, calculix, soplex,astarSR3 1H-1M-2L hmmer, perlbench, soplex,mcfSR4 1H-1M-2L gamess, namd, astar, gobmkSR5 3H-1L hmmer, calculix, gamess,gobmkSR6 1H-3L gamess, sjeng, GemsFDTD,leslie3dSR7 4H hmmer, hmmer, calculix,gamessSR8 4H calculix, calculix, gamess,gamessSR9 2M-2L povray, gromacs, milc, mcfSR10 4L gobmk, gobmk, astar, astarTABLA IV: Cargas de trabajo multiaplicación constituidaspor aplicaciones paralelas y secuencialesCT Categorías BenchmarksMR1 2STH-2STL-1HPH hmmer, calculix,gobmk, astar,wupwise m(8)MR2 2STH-2STL-1HPL hmmer, gamess,soplex, bzip2,EP(8)MR3 2STH-1PSL-1HPH calculix,gamess, BLAST(5),wupwise m(5)MR4 1STH-1STL-1PSM-1HPM hmmer,gobmk, semphy(5),fma3d m(5)MR5 1STH-1STL-1PSM-1PSL calculix, bzip2,semphy(5),BLAST(5)MR6 1STH-1STL-1PSL-1HPH hmmer, astar,bodytrack(5),wupwise m(5)MR7 2STH-1PSM-1PSL calculix,gamess,bodytrack(5),FFTW(5)MR8 2STM-1PSL-1HPH wrf, namd, FFTW(5),wupwise m(5)MR9 3STH-3STL-1PSL hmmer, hmmer,gamess, gobmk,astar, BLAST(6)en Intel Labs [6]. Esencialmente, este prototipo esuna plataforma tipo NUMA con dos procesadoresIntel Xeon E5645 hex-core (Westmere) –doce coresen total–. Cada procesador tiene una cache L3 de6MB compartida por los seis cores de cada chip. Elprimer y segundo nivel de cache son privados a cadacore. La asimetría ha sido introducida en este sistemareduciendo el número máximo de microinstruccionesque pueden retirarse por ciclo en algunos cores. Másconcretamente, los cores “lentos” son capaces de retiraruna microinstrucción por ciclo, mientras que loscores “rápidos” utilizan la configuración de fábrica –pudiendo retirar hasta cuatro microoperaciones porciclo–.En nuestra evaluación hemos empleado dos configuracionesAMP, (1) 2FC-2SC – dos cores rápidos ydos lentos distribuidos en dos chips de tal forma quecada chip incluye un core rápido y uno lento compartiendoun último nivel de cache – y (2) 2FC-10SC –dos cores rápidos y diez lentos en dos chips, dondecada chip contiene un core rápido y cinco lentos –.En esta sección comparamos el rendimiento deCAMP con el de otros tres algoritmos de planificaciónpropuestos previamente. Se trata de los algoritmosPA (Parallelism-Aware) [5] –que explota únicamenteespecialización de TLP–, SFD (SF-Driven)) 3 –que explota especialización de ILP– y RR (roundrobin)[8] –que realiza un reparto equitativo de loscores rápidos del sistema entre todos los hilos–. Todoslos algoritmos evaluados en este trabajo se hanimplementado en el sistema operativo OpenSolaris.Para llevar a cabo un estudio exhaustivo de lasdistintas propuestas, construimos diversas cargas detrabajo multiprogramadas constituidas por aplicacionessecuenciales y paralelas de distintas suites debenchmarks – SPEC CPU2006, SPEC OMP2011,NAS Parallel, Minebench y PARSEC– así comoBLAST –aplicación utilizada en bioinformática– yFFTW –un benchmark científico que realiza la transformadarápida de Fourier–. Las cargas de trabajoestudiadas se dividen en dos grupos. El primero incluyeúnicamente conjuntos de aplicaciones secuenciales(tabla III). El segundo grupo está constituidopor cargas de trabajo con aplicaciones paralelas ysecuenciales (tabla IV).En el proceso de construcción de cargas de trabajorepresentativas, clasificamos las distintas aplicacionesteniendo en cuenta su grado de paralelismo -ST (single-threaded), PS (partially sequential 4 ) o HP(highly parallel) – así como en función de sus factoresde ganancia – H (high), M (medium) o L (low)-. Lacolumna central de las tablas III y IV especifica lacomposición de la carga de trabajo, indicando la clasede cada aplicación en el mismo orden en el que seenumera en la tabla. Por ejemplo, la carga de trabajoSR1 (2H-2L) en la tabla III está compuesta por dosaplicaciones secuenciales con SF alto (calculix ygamess) y dos con SF bajo (gobmk, milc). Del mismomodo, la carga de trabajo MR4 (1STH-1STL-1PSM-1HPM) en la tabla IV incluye dos aplicacionessecuenciales, una con SF alto (STH) y la otracon SF bajo (STL), y dos aplicaciones paralelas deSF medio, siendo la primera de ellas parcialmente secuencial(PSM) y la segunda muy paralela (HPM).La figura 3 muestra la media geométrica de losspeedups obtenidos para las aplicaciones de las cargasde trabajo por cada planificador SFD, PA yCAMP, normalizados con respecto a los tiempos deejecución obtenidos por el algoritmo RR. En un trabajoprevio mostramos que usar RR como baselineproporciona resultados más fiables a la hora de cuantificarel beneficio de los distintas propuestas que utilizarel planificador por defecto de OpenSolaris, queno es consciente de la asimetría en la plataforma [10].A simple vista, podemos apreciar que CAMP consiguemayores beneficios que los otros algoritmos pa-3 Este algoritmo es una variación del algoritmo HASS-D [10].4 Esta clase de aplicaciones abarca aquellas aplicaciones paralelascon fases de ejecución secuencial que constituyen almenos un 20 % de su tiempo de ejecución total.JP2011-249

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201130%25%SINGLE-THREADED APPS. (2FC-2SC)SFD CAMP PASINGLE- AND MULTI- THREADED APPS. (2FC-10SC)gmean speedup over RR (%)20%15%10%5%0%-5%-10%SR1 SR2 SR3 SR4 SR5 SR6 SR7 SR8 SR9 SR10 MR1 MR2 MR3 MR4 MR5 MR6 MR7 MR8 MR9Fig. 3: Speedup medio obtenido por SFD, PA y CAMP con respecto a RR.ra todas las cargas de trabajo. Este resultado es laprincipal contribución de este trabajo.Analizando más detenidamente los resultados obtenidos(figura 3), podemos observar que para cargasde trabajo constituidas por aplicaciones secuenciales(SRx) SFD logra un rendimiento similar a CAMP. Larazón de este comportamiento es que en ausencia deaplicaciones paralelas en la carga de trabajo, la únicamétrica relevante para llevar a cabo la planificaciónes el SF. Tanto SFD como CAMP tienen en cuentaeste factor y ambos se basan en el mismo mecanismode estimación. El algoritmo PA, que no es conscientede los SFs, se comporta como RR –reparte equitativamentelos cores rápidos entre todos los hilos– ypor tanto no ofrece beneficios significativos en esteescenario.Para aquellas cargas de trabajo que incluyen aplicacionesparalelas (MRx), el algoritmo PA es capazde ofrecer mejores resultados en promedio que SFD,llegando a obtener en algunos casos un speedup similara CAMP (MR3, MR4 y MR6). No obstante,PA no es capaz de ofrecer un rendimiento comparablea CAMP para cargas de trabajo que incluyenaplicaciones parcialmente secuenciales (PS) y dondeademás exista una gran diversidad de factores de gananciaen las distintas aplicaciones. Para cargas detrabajo que exhiben estas características, como MR7y MR9, podemos observar diferencias más significativasentre ambos algoritmos de planificación, dondeCAMP supera a PA hasta en un 16 %.VI. ConclusionesEn este trabajo hemos presentado el algoritmode planificación CAMP para procesadores multicoreasimétricos (AMPs), cuya implementación en Open-Solaris ha sido evaluada en profundidad en un prototipode AMP diseñado por Intel Labs. Los resultadosobtenidos muestran que tener en cuenta tanto el paralelismoa nivel de hilo de una aplicación como sufactor de ganancia (SF) resulta esencial a la hora dediseñar una estrategia de planificación que maximiceel rendimiento en AMPs. Estos dos factores permitena CAMP ofrecer un mayor rendimiento que otros algoritmospreviamente propuestos, como SFD y PA,que tienen en cuenta sólo uno de los factores.Los elementos que contribuyen en mayor medida aléxito de CAMP son el factor de utilidad y la técnicaempleada para estimar los factores de ganancia (SFs)de los distintos hilos de ejecución. Este trabajo proponepor primera vez una metodología sistemáticapara facilitar el proceso de desarrollo de modelos deestimación de SF específicos de plataforma.AgradecimientosEl presente trabajo ha sido financiado por el proyectoTIN2008-00508. Agracecemos al Dr. DavidKoufaty el habernos permitido experimentar con elsistema asimétrico diseñado en Intel Labs.Referencias[1] Rakesh Kumar, Keith I. Farkas, Norman Jouppi, et al.,“Single-ISA Heterogeneous Multi-Core Architectures: thePotential for Processor Power Reduction,” in Proc. ofMICRO 36, 2003.[2] Rakesh Kumar, Dean M. Tullsen, Parthasarathy Ranganathan,et al., “Single-ISA Heterogeneous Multi-CoreArchitectures for Multithreaded Workload Performance,”in Proc. of ISCA ’04, 2004.[3] Michela Becchi and Patrick Crowley, “Dynamic ThreadAssignment on Heterogeneous Multiprocessor Architectures,”in Proc. of Computing Frontiers ’06, 2006.[4] Murali Annavaram, Ed Grochowski, and John Shen, “MitigatingAmdahl’s Law through EPI Throttling,” in Proc.of ISCA’05, 2005, pp. 298–309.[5] Juan Carlos Saez, Alexandra Fedorova, Manuel Prieto,et al., “Operating System Support for Mitigating SoftwareScalability Bottlenecks on Asymmetric MulticoreProcessors,” in Proc. of ACM CF’ 10, 2010.[6] David Koufaty, Dheeraj Reddy, and Scott Hahn, “BiasScheduling in Heterogeneous Multi-core Architectures,”in Proc. of Eurosys ’10, 2010.[7] Daniel Shelepov, Juan Carlos Saez, Stacey Jeffery, et al.,“HASS: a Scheduler for Heterogeneous Multicore Systems,”Operating System Review, vol. 43, no. 2, 2009.[8] Tong Li, Dan Baumberger, David Koufaty, et al., “EfficientOperating System Scheduling for Performance-Asymmetric Multi-Core Architectures,” in Proc. of SC’07, 2007, pp. 1–11.[9] Juan Carlos Saez, Alexandra Fedorova, Manuel Prieto,et al., “A Comprehensive Scheduler for Asymmetric MulticoreSystems,” in Proc. of ACM Eurosys ’10, 2010.[10] Juan Carlos Saez, Daniel Shelepov, Alexandra Fedorova,and Manuel Prieto, “Leveraging workload diversity throughos scheduling to maximize performance on singleisaheterogeneous multicore systems,” J. Parallel Distrib.Comput., vol. 71, pp. 114–131, January 2011.[11] M. D. Hill and M. R. Marty, “Amdahl’s Law in theMulticore Era,” IEEE Computer, vol. 41, no. 7, 2008.[12] Juan Carlos Saez, Thread Scheduling on AsimmetricMulticore Systems (Ph.D. dissertation), UCM, 2011.[13] Mark Hall, Eibe Frank, Geoffrey Holmes, Bernhard Pfahringer,Peter Reutemann, and Ian H. Witten, “The WE-KA data mining software: an update,” SIGKDD Explor.Newsl., vol. 11, pp. 10–18, November 2009.[14] Jerome H Friedman, “Stochastic gradient boosting,”http: // www-stat. stanford. edu/ ~ jhf/ ftp/stobst. pdf , 1999.JP2011-250

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Optimización MapReduce para uso de losrecursos en las arquitecturas multi-coreTharso Ferreira, Aprigio Bezerra, Antonio Espinosa, Porfidio Hernández y Juan Carlos Moure 1Resumen— Este artículo presenta una evaluaciónMapReduce y cómo se utilizan los recursos en lasarquitecturas multi-core. Hemos explorado las estructurade datos internas de MapReduce para la creación de datosintermedios, que apuntan a un cuello de botella derendimiento en los procesadores multi-core de memoriacompartida.Presentamos situaciones problemáticas y posibles puntosde mejora, proponiendo una aportación diferente de lasabordadas actualmente en las arquitecturas multi-core.Nos basamos en las ideas originales propuestas por elparadigma MapReduce utilizadas en Hadoop.Nuestro objetivo es definir un modelo para ejecutareficientemente el paradigma MapReduce en arquitecturasmulti-core. Para lograr este objetivo, la idea es definir unaestrategia para optimizar el uso de la memoria compartidaentre los threads que se ejecutan sobre el mismo ydiferentes conjunto de datos.Palabras clave—MapReduce, Multi-core, Threads,Phoenix, Hadoop, Memoria compartida.LI. INTRODUCCIÓNa gestión de recursos en los procesadores multicoreha ganado importancia con la evolución de lasaplicaciones y arquitecturas. Pero esta gestión es muycompleja. Por ejemplo, una misma aplicación paralelaejecutada múltiples veces con los mismos datos deentrada, en un único nodo multi-core, puede tenertiempos de ejecución muy variables. Hay múltiplesfactores hardware y software que afectan alrendimiento. La forma en que los recursos hardware(cómputo y memoria) se asignan a los procesos othreads, posiblemente de varias aplicaciones quecompiten entre sí, es fundamental para determinar esterendimiento. La diferencia entre hacer la asignaciónde recursos sin conocer la verdadera necesidad de laaplicación, frente a asignación con una meta específicaes cada vez mayor. La mejor manera de realizar la esresolverlos automáticamente, con una mínimaintervención del programador resolver el problema de lagestión de recursos.Es importante destacar, que la forma en que laaplicación se ejecuta en una arquitectura nonecesariamente es la más adecuada, y esta situaciónpuede mejorarse a través de la gestión adecuada de losrecursos disponibles. Una apropiada gestión de recursospuede ofrecer ventajas tanto al desarrollador de lasaplicaciones, como al entorno informático donde ésta seejecuta, permitiendo un mayor número de aplicacionesen ejecución con la misma cantidad de recursos. Asímismo, esta gestión de recursos no requeriría introducir1 Departamento de Arquitectura de Computadores y SistemasOperativos, Universidad Autónoma de Barcelona, España, e-mail:tharso.souza, Aprigio.Bezerra, antonio.espinosa@caos.uab.esporfidio.hernandez, juancarlos.moure@uab.esJP2011-251cambios a la aplicación, o a su estrategia operativa.MapReduce [1] es un paradigma creado por Google,originalmente dirigido a los Data Centers. MapReducees un paradigma de programación, desarrollado paraapoyar el procesamiento de grandes conjuntos de datos ycómputo paralelo. La simplicidad de este paradigmaradica en que el programador sólo necesita proporcionaruna implementación secuencial de la aplicación,expresando las funciones Map y Reduce. El siguientepseudocódigo muestra la estructura básica de unaaplicación MapReduce, que cuenta el número deocurrencias de cada palabra en un determinadodocumento. La función EmitIntermediate de Map asignael valor 1 para cada ocurrencia de cada palabra en eldocumento. La función Reduce suma todos los valoresasociados a una determinada clave emitida por lafunción Map.// input: a document// intermediate output: key=word; value=1Map(void *input){for each word w in inputEmitIntermediate(w, 1);}// output: key=word; value=occurencesReduce(String key, Iterator values){int result = 0;for each v in valuesresult += v;Emit(w, result);}El funcionamiento de una aplicación MapReduce tienecomo inicio la ejecución de la fase Map, que distribuyeel procesamiento a aplicar a los datos de entrada de laaplicación. Mediante la partición del archivo de entradaen un número de M bloques, cada tarea Map recibe unode esos M bloques de datos, por lo que la entrada puedeser procesada de forma simultánea en cada uno de losnodos de ejecución.Después de la fase Map, se ejecuta la fase Reduce,donde los Workers utilizan los datos intermediosgenerados por la fase Map. En esta fase también todo elcómputo se realiza en paralelo, sin tener ningunadependencia de datos entre tareas. Los Workers de lafase Reduce suelen realizar algún tipo de operación dereducción, como una suma o clasificación. El resultadode la fase Reduce es escrito en una estructura de datoslocales, produciendo una sola salida. El funcionamientodel paradigma MapReduce se muestra en la figura 1.Actualmente, los chips multi-core se han convertido enmucho más que un procesador, es cada vez más

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011importante explorar toda su capacidad de cómputo. Lasactuales técnicas de programación paralela, hacen usoprincipalmente del envío de mensajes y de la memoriacompartida. Sin embargo estas técnicas son bastantelaboriosas para la mayoría de los desarrolladores, ya quees necesaria la gestión de la concurrencia y el accesocompartido a las estructuras de datos. Dando comoresultado la necesidad de sincronizar la ejecución de losthreads.En la sección II se presentan los trabajos relacionadoscon la ejecución de aplicaciones MapReduce enentornos de memoria compartida. La sección IIIpresenta las principales características de uso derecursos de las aplicaciones MapReduce en entornos deejecución. En la sección IV, se presenta una propuestade gestión del almacenamiento de las claves intermediasgeneradas por las aplicaciones para mejorar surendimiento. Finalmente, la sección V proporciona unabreve descripción de las conclusiones del presentetrabajo.línea funciona como una tabla hash. Phoenix pone cadaclave generada en la fase Map en una estructura enforma de matriz. Hay una fila para división de los datosde entrada y una columna para cada reducer, resultadode aplicar una función hash a cada clave. Esta estructurase muestra en la figura 2 y 3.Durante la fase Reduce, los workers utilizan losvalores generados por la fase Map, separadas porcolumnas [6]. La ventaja de esta forma de distribuciónde los datos, es que son utilizadas diferentes regiones dela memoria, evitando así la necesidad de sincronización.Fig. 2. Uso de la matriz por el Map y el Reduce.Fig. 1. Flujo de datos de una aplicación MapReduce.II.TRABAJO RELACIONADOHay diferentes implementaciones del modeloMapReduce en diferentes tipos de arquitecturas. A partirdel modelo presentado por Google [1], han aparecidoimplementaciones para clusters como Hadoop[2], paraGPUs como MARS[3], o para sistemas con memoriacompartida como Phoenix[4] o Metis[5].A. PhoenixComo una contribución en las arquitecturas multi-corey multi-procesador de memoria compartida, hay sidodesarrollado Phoenix [4]. Phoenix maneja el uso dethreads para la ejecución de tareas Map y Reduce,utilizando la memoria compartida como vía para lacomunicación entre los threads, evitando la copia dedatos[6]. El Scheduler dinámicamente evalúa losprocesadores disponibles y hace la distribución ybalanceo de carga, maximizando la utilización de losrecursos entre las tareas.Phoenix utiliza dos buffers temporales asignados en lamemoria compartida para almacenar los datosintermedios. Inicialmente estos buffers tienen untamaño por defecto, que cambia dinámicamente segúnsea necesario.Para almacenar valores intermedios generados por lafase de Map, Phoenix utiliza una matriz donde cadaJP2011-252Fig. 3. Aplicación de la función hash sobre un conjunto de datos.El problema principal de este modelo, se producedurante la creación de los datos intermedios en la faseMap, donde se puede llegar a necesitar más del espaciodisponible en memoria para almacenar todas las clavesy valores intermedios.B. METISUtilizando Phoenix como base, se desarrolló Metis[6]como una librería de MapReduce con una mejorapropuesta para almacenar los datos intermedios en unaestructura que tiene un buen desempeño con la mayoríade las cargas de trabajo.La idea de Metis es utilizar una estructura"Hash+tree". De esta forma, podemos aprovechar lasventajas de cada una de estas estructuras. Todos losworkers de la fase Map utilizan el mismo tamaño detabla hash, y la misma función hash. Cuando el Map

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011hace la emisión de un par clave/valor, la librería utilizala clave para encontrar la entrada en la tabla hash y lamisma clave para bajar en el árbol. Si la clave ya existe,la librería agrega un nuevo valor a la misma clave, de locontrario una nueva entrada es creada para la clave.III.UTILIZACIÓN DE RECURSOSHemos usado la API de Phoenix, y una aplicación decontar palabras, evaluando el uso de la memoria y elrendimiento en tiempo de ejecución en dos entornosinformáticos diferentes.En el entorno 1, se dispone de un ordenador con unIntel Core 2 Duo de 3.00 GHz en una arquitectura64bits, con 6 GB de memoria. El entorno 2 estácompuesto por una máquina que utiliza 2 Dual-CoreIntel Xeon de 3.00GHz en una arquitectura 64Bits y con12 GB de memoria. También hemos utilizado 6 archivosde entrada, de 1GB hasta 6GB, basándonos en lacantidad de memoria que nuestros entornos teníandisponibles.En la figura 4, se muestra que el uso de la memoria eslínea ascendente, donde los dos principales factores queinfluyen en la curva de la línea son los tamaños de laentrada y la cantidad de memoria disponible. Mientrasque la memoria está disponible, las estructuras creadastienen una magnitud de 2,3 veces el tamaño de laentrada.Fig. 5. Rendimiento de aplicaciones bajo Phoenix.Fig. 6. Requerimientos de memoria de la aplicacion WordCount bajoPhoenix.La estructura en Phoenix para almacenar los datosintermedios está formada por una matriz, donde cadalínea representa una tabla hash. El principal problema deutilizar esta tabla hash, es la imposibilidad de definir deforma estática el tamaño idóneo de esta tabla. Es decir,es difícil predecir cuánto espacio se necesita a priori. Noes posible saber cuál es la ocurrencia de unadeterminada clave. La misma clave puede aparecervarias veces; el número de claves únicas puede sergrande. Y además el tamaño de las claves es difícil depredecir, ya que depende del diseño de la aplicación.IV.SOLUCIÓN PROPUESTAFig. 4. Uso de memoria por la aplicación MapReduce WordCount.La gran ventaja de las aplicaciones MapReduce paralas arquitecturas multi-core es que todas las estructurasde datos intermedios están en los buffers de memoria.El uso de MapReduce en las arquitecturas multi-coretiene un buen desempeño mientras un factor importantees contemplado: memoria disponible.Cuando este factor no se contempla, ninguna estrategiaespecífica es adoptada. El sistema operativo gestiona losdatos y empieza a utilizar el Swap para suplir la falta dememoria. Esta situación claramente perjudica elrendimiento de la aplicación como se muestra en lafigura 5.Se concluye que la estructura de datos intermedioscreada por las aplicaciones MapReduce se convierte enun cuello de botella como se muestra en la figura 6. Estasituación no favorece el rendimiento de las aplicacioneshaciendo uso ineficiente del espacio.JP2011-253MapReduce propone como idea inicial que todas lastareas sean independientes y que trabajen sobreconjuntos de datos disjuntos. Mientras que laspropuestas de soluciones para las arquitecturas multicoreproponen índices, nosotros proponemos utilizar laidea original de MapReduce y substraer el uso de índice,que puede optimizar el uso de los recursos en tiempo yespacio.Nos basamos en Hadoop[2] para proponer unaoptimización que utiliza la memoria de modo que noafecte al rendimiento ofrecido por el paradigmaMapReduce.Durante la ejecución de la fase Map, los workersreciben los datos divididos por una función de división(splitter) y los almacena en un buffer de memoria cuyotamaño sea configurable por el usuario. Cada Mapprocesa estos datos que están en el buffer de memoria ygenera una serie de tuplas clave/valor. En cada nuevaiteración de las tareas Map, se hace una llamada a lafunción combiner, que realiza una pre-agregación de

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011valores para cada clave, con el fin de disminuir lacantidad de datos para procesar y ahorrar espacio enmemoria. Cuando el buffer de la memoria alcanza undeterminado umbral de utilización disponible definidopor el usuario, estos datos deben ser enviados al disco,como se muestra en la figura 7. Antes de enviar los datosal disco se realizará una ordenación en las claves.Fig. 7. Flujo de datos en la fase Map.En la ejecución de la fase Reduce, cargamos los datosque están en el disco en los buffers de memoria de lastareas reduce. Cuando los datos están en la memoria, serealiza una agregación de todos los datos a través de unafunción merge. Si la cantidad de datos ocupa másespacio que la cantidad de memoria disponible, se envíanuevamente al disco después de la fusión.Después de combinar los datos en un conjunto, losdatos son enviados a las tareas Reduce, como se muestraen la figura 8. Los datos de entrada de las tareas Reduceestán ordenados por clave. La salida final de esta fase seescribe directamente en el disco.AGRADECIMIENTOSEl presente trabajo ha sido financiado por el MEC(Ministerio de Educación y Ciencia) mediante elproyecto con referencia TIN2007-64974.REFERENCIAS[1] J. Dean, S. Ghemawat, “MapReduce: simplified data processingon large clusters”, Commun. ACM, 2008.[2] T. White, “Hadoop: The Definitive Guide”, 2009.[3] B. He, W. Fang, Q. Luo, N. K. Govindaraju, T. Wang, “Mars: aMapReduce framework on graphics processors”, Proceedings ofthe 17th international conference on Parallel architectures andcompilation techniques, 2008.[4] R.M. Yoo, A. Romano, C. Kozyrakis, “Phoenix Rebirth:Scalable MapReduce on a Large-Scale Shared-Memory System”,Proceedings of the IEEE International Symposium on WorkloadCharacterization (IISWC), 2009.[5] Y. Mao, R. Morris, M.F. Kaashoek, “Optimizing MapReduce forMulticore Architectures”, MIT technical report MIT-CSAIL-TR-2010-020, 2010.[6] C. Ranger, R. Raghuraman, A. Penmetsa, G. Bradski,C.Kozyrakis, “Evaluating MapReduce for Multi-core andMultiprocessor Systems”, Proceedings of the 13th InternationalSymposium on High-Performance Computer Architecture, 2007.Fig. 8. Flujo de datos en la fase Reduce.V. CONCLUSIONESHemos propuesto un modelo que tiene como ideaprincipal el uso de los recursos en aplicacionesMapReduce bajo una arquitectura multi-core.La idea de este modelo, es evitar la saturación delrecurso de memoria, utilizando el disco comodispositivo auxiliar para el almacenamiento yordenación de las claves intermedias. Sabiendo que paraun conjunto de datos muy grandes, no siempre haymemoria disponible, la idea de utilizar el acceso al discode manera ordenada se convierte en una solución a teneren cuenta y a ser contrastada con el resto de alternativasexistentes.JP2011-254

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Análisis de los datos privados/compartidos enaplicaciones paralelas sobre CMPsAlfonso Ramos 1 Antonio García-Guirado 1 José M. García 1Resumen— En los últimos años se han realizado numerososestudios para mejorar el rendimiento del sistemade memoria de los procesadores debido a la graninfluencia que tiene en el tiempo de ejecución de lasaplicaciones. En este artículo presentamos un estudiode las necesidades de memoria para datos privados ycompartidos en aplicaciones paralelas sobre CMPs anivel de la caché L1 de datos. Además, realizamos unanálisis de un subconjunto de los datos compartidosque tiene un comportamiento especial: se escriben alcomienzo de la aplicación y ya no vuelven a ser escritos.Por último, estudiamos el potencial de mejorade las aplicaciones con un manejo especial de estosdatos, mostrando que, si se tratan adecuadamente, sepodrían obtener mejoras importantes en el tiempo deejecución de las aplicaciones.Palabras clave— Chip Multiprocessor, Caché L1, DatosCompartidos.I. IntroducciónDURANTE los últimos años, los tiled CMPs hancobrado protagonismo debido a su capacidadpara mantener los avances en rendimiento esperadosdentro de unos límites de consumo y complejidad dediseño aceptables. Estos chips están formados por variostiles compuestos por un core, una caché privada,parte de una caché mayor que suele ser compartida yuna interfaz de red que sirve para unir a todos los tilesmediante una red de interconexión. Actualmentese están llevando a cabo numerosas propuestas queresuelven algunos de los retos que plantean estos sistemas.Por un lado, se pretende reducir al máximoel consumo de energía en el chip, y por otro, mejorarel rendimiento de las aplicaciones en la medida de loposible.Uno de los mayores retos es que sigue existiendouna gran diferencia de velocidad entre el procesadory la memoria en los sistemas multiprocesadoractuales. Esto hace que el rendimiento del sistema dememoria tenga un impacto muy grande en el rendimientode las aplicaciones, aportando entre un 60 %y un 80 % del tiempo total de ejecución.Por esta razón, el adecuado manejo de la jerarquíade memoria es uno de los aspectos cruciales para optimizarel rendimiento de un CMP, especialmente enlos niveles más cercanos al procesador que amortiguanel efecto de los costosos accesos a niveles máslejanos. Por este motivo, aspectos como el aprovechamientodel espacio, las políticas de reemplazo y, endefinitiva, el aumento del rendimiento de las cachés(principalmente la caché L1 de datos) han sido algunosde los grandes objetivos en el campo de laarquitectura de computadores en los últimos años.1 Departamento de Arquitectura e Ingeniería de Computadores,Universidad de Murcia, e-mail: alfonso.ramos@um.es,{toni,jmgarcia}@ditec.um.esPor otro lado, es conocido que las necesidades dela sociedad hacen que cada vez se desarrollen aplicacionesque requieren sistemas más potentes, talescomo aplicaciones intensivas en gráficos, servidoresweb con mayores funcionalidades o aplicaciones confines científicos. De esta forma, la carga de trabajode las aplicaciones se encuentra en continuo cambio,y con ello sus necesidades de memoria.Todo esto nos hace llegar a la conclusión de queel estudio del comportamiento de los bloques en lacaché L1 de datos puede permitir una mayor comprensiónde las necesidades de memoria de las aplicacionesactuales, lo que abre vías de estudio interesantespara mejorar el rendimiento de dichas aplicaciones.Así pues, las aportaciones de este artículo son lassiguientes:Realizamos un estudio de las necesidades dememoria de una serie de aplicaciones de variosámbitos a nivel de la caché L1 de datos.Analizamos un subconjunto de los datos compartidosque tienen un comportamiento especial:se escriben al comienzo de la aplicación y novuelven a ser escritos en el resto de la ejecución.Estudiamos el potencial de mejora en el tiempode ejecución de las aplicaciones que puedeproporcionar adecuado manejo de estos datos.Ofrecemos posibles vías de investigación paramejorar el rendimiento de las aplicaciones medianteuna mejor gestión de los distintos tiposde datos.El resto de este artículo se organiza de la siguientemanera: en la Sección 2 comentamos algunos trabajosde interés relacionados con el tratamiento diferenciadode los datos según su tipo; en la Sección3 presentamos un análisis de las necesidades de memoriade los distintos tipos de datos para una seriede aplicaciones; la Sección 4 ahonda en las característicasde los datos compartidos de sólo lecturay el potencial de mejora de rendimiento que puedeproporcionar su tratamiento específico; para finalizar,presentamos nuestras conclusiones.II. Trabajo relacionadoEn los últimos años han aparecido varios estudiossobre los distintos tipos de datos presentes en unaaplicación paralela. Los resultados han sido aprovechadosparar realizar varias propuestas que adaptanel funcionamiento de la caché al patrón de comportamientode los tipos de datos observados. Así se obtienenventajas en rendimiento, se consigue reducir elconsumo, o se simplifica el protocolo de coherencia.JP2011-255

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Reactive NUCA [1] trata de forma diferenciada losdatos privados, los datos compartidos y las instrucciones,y les asigna distintos mapeos a los bancos decaché. Los datos privados se almacenan en el bancode caché local para proporcionar una mejor latenciade acceso. Los datos compartidos se distribuyen entretodos los bancos de caché para evitar réplicas ymaximizar así la capacidad efectiva de la caché. Lasinstrucciones utilizan un nuevo mapeo con centro fijoque proporciona un equilibrio entre replicación ylatencia de acceso. La distinción entre tipos de datosse realiza mediante nuevos campos en la tabla depáginas y el TLB. El resultado es una importantemejora del rendimiento con respecto a usar un únicomapeo.SWEL [2] simplifica la coherencia mediante el tratamientodiferenciado de datos, aprovechando el hechode que los datos que realmente necesitan coherenciasuponen un porcentaje pequeño de los accesos.Los datos privados son traídos a las cachés L1 de losprocesadores. Los datos compartidos de sólo lecturapueden tener copia en todas las cachés L1 del chip.Estas copias son invalidadas mediante broadcast encaso de una escritura. Por último, los datos compartidosde lectura/escritura sólo mantienen una copiaen L2, evitando tener que mantener coherencia, y todoslos accesos de los procesadores provocan el envíode una petición de memoria por la red para accedera la L2. El resultado es que sólo se necesitan tresbits de estado por bloque en L2 y dos bits en L1para mantener el sistema coherente. El rendimientoes similar al de un directorio pero añadiendo muchamenor complejidad al diseño del chip.La arquitectura Nahalal [3] aprovecha la gran cantidadde accesos a datos compartidos para colocarun banco de L2 central para esos datos alrededordel cual se colocan los procesadores. El acceso a estebanco central es muy rápido para todos. Al ladocontrario, cada procesador tiene su propio banco deL2 privada.ASR [4] aplica políticas de replicación de bloquesen caché L2 compartida adaptadas al hecho de quelos datos compartidos son muy accedidos. Así consigueaprovechar tanto la mayor capacidad efectivade un esquema de caché compartida como la menorlatencia de acceso a las réplicas creadas para los bloquesque más beneficio producen por ser muy accedidos.III. Análisis de las necesidades de memoriaLas necesidades de memoria de las aplicacionesestán en constante cambio. Por ello, creemos queidentificar criterios que permitan clasificar los datosrequeridos por las aplicaciones puede convertirse enun elemento diferenciador a la hora de mejorar elrendimiento de las mismas. En este apartado se describeen primer lugar la metodología empleada en laspruebas realizadas. Tras ello, se presenta una clasificaciónde los bloques solicitados por el procesadora la caché L1 de datos. Finalmente, se analiza la in-TABLA IParámetros del sistema.Procesadores 16 UltraSPARC-III+ 3 GHz. 2-vías, in-order.Cache L1Dividida I&D. Tamaño: 16KB.Asociatividad: 4-vías. 64 bytes/bloque.Latencia de acceso: 1 (tag) + 1 (datos) ciclos.Cache L2Tamaño: 512KB cada banco. 8MB total.Asociatividad: 16-vías. 64 bytes/bloque.Latencia de acceso: 12 ciclos.RAMTamaño: 4 GB DRAM.Latencia Memoria 156 ciclos + on-chip delay.Tamaño de Página: 4 KB.Red interconexión Malla bidimensional 4x4. enlaces de 16 bytes.Latencia: 4 ciclos/enlace + 1 ciclo/switch +1 ciclo/router (en ausencia de contención)Tamaño Flit: 16 bytes.Tamaño paquete de control: 1 flit.Tamaño del paquete de datos: 5 flits.TABLA IIConfiguración de los benchmarks.Workload Dominio aplicacion Tamañofft Procesamiento de señales 16K puntosradiosity Gráfica large roomvolrend Gráfica Headblackscholes Análisis financiero simsmallfluidanimate Animación simsmallswaptions Análisis financiero simsmallapache Servidor web 500 clientesjbb Servidor web 1.5 warehouses por tilefluencia de los distintos tipos de datos en el tiempode ejecución de las aplicaciones.A. Metodología de las pruebas.Todas las pruebas han sido realizadas usando elsimulador funcional Simics [5] extendido por el simuladorde temporización GEMS [6]. Para este trabajose ha utilizado una arquitectura NUCA sobreCMPs. La coherencia de caché se mantiene medianteun protocolo de directorio que sigue un esquemade estados MOESI. En la Tabla I se puede apreciaruna descripción más detallada de los parámetros delsistema.La mayoría de las aplicaciones utilizadas pertenecena las suites SPLASH-2 [7] y PARSEC [8] sugeridasen [9]. Además, se han añadido dos aplicacionescomerciales para servidores: apache y jbb. Enla Tabla II se pueden observar con más detalle lasaplicaciones utilizadas, su dominio de aplicación y eltamaño de la entrada.B. Clasificación de los tipos de datos.Si tenemos en cuenta los accesos a la caché L1 dedatos, podemos distinguir claramente dos tipos debloques. Aquellos que son accedidos por un únicoprocesador para realizar lecturas y escrituras (datosprivados), y los que son accedidos por varios procesadorespara realizar lecturas y escrituras (datoscompartidos).No obstante, hemos comprobado que existen algunosdatos compartidos que tienen un comportamientopeculiar. Y es que, a partir de un instantedeterminado cercano al comienzo de la ejecución dela aplicación, no vuelven a ser escritos por ningúnprocesador. Si nos fijamos, estos bloques se comportande forma similar a los bloques del código de laJP2011-256

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011100908070Tiempo dedicado a CPU y MemoriaComp_Lect_EscComp_LectPrivadosCPU% of total6050403020100FluidanimateBlackscholesSwaptionsRadiosityVolrendApacheFFTJBBMediaFig. 1. Porcentaje del tiempo de ejecución empleado en accesos a memoria (dividido por tipos de datos) y cpu.aplicación que son tratados en la caché L1 de instrucciones,pero sólo a partir de un cierto momento.Este momento coincide con el fin de la inicializaciónde las estructuras de datos de la aplicaciones, y estosdatos ya no cambian de valor durante el resto deltiempo de ejecución de las mismas.Llamaremos a estos datos “datos compartidos desólo lectura” de aquí en adelante, y analizaremos sucomportamiento junto al del resto de tipos de datos.De esta forma, los bloques manejados por lacaché L1 de datos quedan clasificados la siguientemanera:Datos privados: son accedidos solamente por unprocesador para lectura y/o escritura.Datos compartidos:• Datos compartidos de sólo lectura: son accedidospor varios procesadores para lectura trasla inicialización de las estructuras de datos.• Datos compartidos de lectura/escritura: sonaccedidos por varios procesadores para lecturay escritura.C. Estudio del peso en el tiempo de ejecución de losdistintos tipos de datos.Pasamos ahora a estudiar qué importancia adquierenlos tipos de datos en el tiempo de ejecución delas aplicaciones, teniendo en cuenta la clasificaciónestablecida en la sección anterior. En la Figura 1 semuestra el porcentaje del tiempo de ejecución empleadopor la CPU y por los accesos a memoria segúnel tipo de dato.Como se puede observar en dicha figura, el tiempoempleado en accesos a memoria es de más de un 70 %de media. Si nos centramos en los distintos tipos dedatos vemos como, de media, cerca de un 35 % deltiempo es empleado en accesos a los datos privados.En torno a un 20 % del tiempo es dedicado a los datoscompartidos de lectura/escritura y más de un 15 %de media del tiempo de ejecución coincide con losaccesos a los datos compartidos de sólo lectura. Vemoscomo estos últimos, datos que tras inicializarseno vuelven a ser escritos, tienen un impacto bastantesignificativo en el tiempo de ejecución de las aplicaciones.Esto es especialmente notable en aplicacionescomo blackscholes o radiosity, en las que aportan másdel 20 % del tiempo de ejecución, y siendo totalmentedeterminantes en jbb, donde prácticamente la mitaddel tiempo de ejecución se consume en accesos a bloquesde este tipo.Así pues, aunque hay aplicaciones como fft o fluidanimateen las cuales representan un porcentaje pequeñodel tiempo de ejecución, alrededor del 5 %, pareceque los datos compartidos de sólo lectura puedentener un gran impacto en el tiempo de ejecución dealgunas aplicaciones. En las siguientes secciones seestudiaran minuciosamente.IV. Estudiando en profundidad los datoscompartidos de sólo lecturaEn este momento, nos preguntamos si los datoscompartidos de sólo lectura podrían tener algún tratamientoespecial que ayudara a mejorar el tiempo deejecución de las aplicaciones. Para responder a estapregunta se deben conocer algunos detalles más acercadel comportamiento de los mismos. Esta seccióntratará estas cuestiones.A. Número de bloques y número de accesos.En primer lugar analizaremos la cantidad de bloquesque son compartidos de sólo lectura y el númerototal de peticiones de memoria que generan. En la Figura2 se muestran el número de accesos y el espacioocupado por los bloques de memoria en la caché L1de datos según el tipo de dato al que pertenecen.Si nos fijamos detenidamente en la Figura 2a podemoscomprobar que el número de bloques de sólolectura representa de media sólo un 10 % del total debloques accedidos durante la ejecución de las aplicaciones.Es más, excepto en volrend y jbb, el númerode bloques de sólo lectura no llega ni al 5 % del totalen ninguna aplicación. Esto es un dato tremendamenteinteresante, ya que, aunque el espacio ocupadopor los datos compartidos de sólo lectura es muypequeño, su peso en el tiempo de ejecución de lasaplicaciones es bastante determinante, como se pudoapreciar en la Figura 1. Por ejemplo, en radiosity yblackscholes el espacio que ocupan estos bloques nollega al 3 %, y sin embargo el impacto que tienen enJP2011-257

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201110090Porcentaje del espacio ocupadoComp_Lect_EscComp_LectPrivado10090Porcentaje accesos a memoriaComp_Lect_EscComp_LectPrivado808070706060% of total5040% of total504030302020101000FluidanimateBlackscholesSwaptionsRadiosityVolrendApacheBlackscholesSwaptionsFluidanimateRadiosityVolrendApacheFFTMediaJBBFFTMediaJBB(a) Porcentaje del tamaño de memoria (número de bloques)según tipo de dato.(b) Porcentaje del número de accesos segúntipo de dato.Fig. 2. Estadísticas del número de accesos y espacio ocupado por los bloques de memoria en la caché L1 de datos según el tipode dato.el tiempo de ejecución supera el 20 %. De forma parecida,en jbb ocupan un 20 % y tienen un peso decasi el 50 % en el tiempo de ejecución.En cuanto al número de accesos, en la Figura 2bvemos que, de media, en torno a un 20 % son destinadosa bloques compartidos de sólo lectura. Porsu parte, los datos privados y compartidos de lecturay escritura son accedidos en torno a un 40 % demedia cada uno. Si comparamos estos datos con losresultados mostrados en la Figura 1, y centrándonosen los datos compartidos de sólo lectura, vemos comopara la mayoría de aplicaciones la frecuencia conque se accede a ellos explica el impacto que tienen enel tiempo de ejecución. Sin embargo, hay dos casosque merece la pena mencionar. En blackscholes, elporcentaje de accesos a los datos es muy superior alimpacto que tienen los mismos en el tiempo de ejecución(50 % frente a 20 % aproximadamente). Estopuede deberse a una buena gestión de los mismos enla caché L1 de datos. Por el contrario, si nos fijamosen JBB, el porcentaje de accesos, de cerca del 25 %,tiene un impacto de en torno al 50 % en el tiempode ejecución. En este caso parece que la caché L1 dedatos no gestiona bien los datos compartidos de sólolectura, para los cuales deben producirse numerososfallos en caché.Parece, por tanto, interesante estudiar la influenciade los datos compartidos de sólo lectura en la tasa defallos de la caché L1. El siguiente apartado estudiaeste aspecto.B. Impacto de los datos compartidos de sólo lecturaen la tasa de fallos de la caché L1 de datos.La Figura 3 muestra la tasa de fallos de la caché L1de datos descompuesta para mostrar la aportación decada tipo de datos en ella. Como podemos observaren esta figura, en torno a un 25 % de los fallos enla caché L1 de datos son producidos por los datoscompartidos de sólo lectura, lo que unido a su granfrecuencia de acceso justifica que estos datos tenganun peso importante en el tiempo de ejecución de lamayoría de las aplicaciones, a pesar del poco espacioque ocupan.Por lo tanto, vemos que las suposiciones sobre elcomportamiento de la L1 hechas en el apartado anteriorson ciertas. En blackscholes hay muchos accesosa datos compartidos de sólo lectura (50 % aproximadamente)pero no tienen tanta importancia en eltiempo de ejecución (sólo un 20 %) porque suponenmuy pocos fallos en caché. En jbb, por el contrario,estos datos tienen un peso tan determinante (50 %)en el tiempo de ejecución, a pesar de que el númerototal de accesos a ellos no es tan grande (20 %),porque la inmensa mayoría de los fallos de L1 se producenen los accesos a estos datos.C. Estudio del potencial de los datos compartidos desólo lectura.Hemos comprobado como los datos compartidos desólo lectura tienen una gran influencia en el tiempode ejecución de las aplicaciones a pesar de su escasotamaño. A continuación vamos a comprobar si, efectivamente,tratando estos datos adecuadamente sepuede conseguir una mejora considerable en el tiempode ejecución de las aplicaciones. Para ello hemosejecutado de nuevo las aplicaciones suponiendo quetodos los accesos a los datos compartidos de sólo lecturaproducen acierto en la caché L1 de datos.Para hacer esto, al lanzar las ejecuciones originalesguardamos las direcciones de memoria de los bloquesdetectados como compartidos de sólo lectura. En laejecución posterior, para calcular el potencial, detectamoslos accesos a estos bloques y directamente asumimosun acierto en L1, e introducimos la latenciade acceso a la caché L1 de datos.Este método puede producir efectos colaterales, yaque en el cálculo del potencial estos bloques no entranrealmente en la caché. Por tanto, el tamaño efectivode la misma se ve ligeramente aumentado debidoa que estos bloques no “ocupan espacio” y los fallospor conflicto con otros bloques se ven ligeramentereducidos. Esto puede provocar cierta mejora adicional.JP2011-258

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011% of total109.598.587.576.565.554.543.532.521.510.50RadiosityVolrendTasa de fallos L1 DatosBlackscholesFluidanimateSwaptionsComp_Lect_EscComp_LectPrivadosApacheFFTJBBMediaFig. 3. Tasa de fallos en caché L1 de datos descompuesto por tipos de datos.% of total10095908580757065605550454035302520151050RadiosityVolrendCota Superior SpeedupBlackscholesRealCota% of total10095908580757065605550454035302520151050Cota Superior SpeedupFluidanimateSwaptionsRealCotaApacheMediaJBBFFTMedia(a) Aplicaciones con un buen potencial.(b) Aplicaciones con un potencial reducido.Fig. 4. Cota superior del tiempo de ejecución de las aplicaciones reduciendo la tasa de fallos en L1 a 0 para los datos compartidosde sólo lectura.No obstante, nuestra intención es mostrar una cotasuperior de la mejora que podríamos obtener siaplicásemos mecanismos para reducir la tasa de fallosde L1 para los escasos bloques compartidos desólo lectura de las aplicaciones.Además, hemos clasificado las aplicaciones segúnsu potencial para explicar qué características de lasestudiadas anteriormente pueden proporcionar unamejora considerable en el tiempo de ejecución ycuáles no. La comparación entre la ejecución normaly la cota superior, suponiendo aciertos en L1 paralos datos compartidos de sólo lectura, puede verse enla Figura 4.En primer lugar, como podemos ver en la Figura4a, podríamos alcanzar hasta un 25 % de mejorade media en aplicaciones con buen potencial: volrend,blackscholes, jbb y radiosity. En algunas de ellas, comojbb, la cota superior es sorprendente, de casi el50 %. Así pues, vemos que existe un margen de mejorabastante amplio, que nos hace pensar que tratandode una manera adecuada los datos compartidosde sólo lectura se pueden conseguir mejoras importantesen estas aplicaciones, incluso aunque no nosacerquemos demasiado a la cota superior.Sin embargo, en la Figura 4b podemos comprobarque no todas las aplicaciones tienen un margende mejora tan amplio. En las aplicaciones fft, fluidanimate,swaptions y apache podríamos alcanzar entorno a un 6 % de mejora media. No obstante, hemosde destacar un hecho relevante, y es que, si observamosde nuevo la Figura 2a, podemos comprobarque el espacio ocupado por los datos compartidos desólo lectura en estas aplicaciones es casi despreciable.En ninguno de los casos supera el 3 % del total.Esto hace pensar que aunque la cota superior no esdemasiado buena, será más fácil acercarse a ella siconseguimos tratar estos datos de forma adecuadagracias a su poca cantidad.Este estudio nos permite analizar cuáles son las característicascomunes que tienen las aplicaciones conun potencial parecido, lo que nos ayudará a identificarlas condiciones que favorecen la existencia dedicho potencial para una aplicación concreta. Comocabía esperar, si miramos de nuevo la Figura 3, vemosque las aplicaciones con un potencial más altoson aquéllas en las cuáles los datos compartidos desólo lectura tienen una influencia mayor en su tasade fallos en L1, independientemente del número deaccesos a este tipo de datos. A simple vista podríaparecer que apache debería tener un potencial mayorsegún esta afirmación. Sin embargo, si nos fijamosdetenidamente, vemos que aunque el porcentaje deJP2011-259

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011fallos que generan dichos datos es alto en comparacióncon otras aplicaciones, queda eclipsado por elgran número de fallos que producen los datos compartidosde lectura y escritura en dicha aplicación.V. ConclusionesHemos analizado la necesidad de memoria para datosprivados/compartidos en aplicaciones paralelassobre CMPs. Además, hemos estudiado en profundidadlos datos compartidos de sólo lectura. Hemoscomprobado que a pesar de que estos datos ocupande media un porcentaje pequeño del espacio totalusado por la aplicación, inferior al 5 % en la mayoríade aplicaciones, estos bloques se acceden frecuentementey tienen un peso muy importante en el tiempode ejecución de las aplicaciones: en torno a un 15 %de media. Este porcentaje es incluso mayor en aplicacionescomo radiosity o blackscholes, donde superael 20 %, y totalmente determinante en JBB, dondesupone cerca del 50 %.Por otro lado, hemos presentado una cota superiorde la posible mejora del tiempo de ejecución de lasaplicaciones suponiendo que los datos compartidosde sólo lectura no fallan en la caché L1, mostrandoque el margen de mejora es amplio. Hemos comprobadoque para las aplicaciones con un buen potencialse obtiene de media un 25 % de mejora como cotasuperior. Esto sugiere que con un buen manejo deestos datos se podría conseguir una mejora real enel tiempo de ejecución notable, aun sin acercarnosdemasiado a la cota. Además, aunque en las aplicacionescon un potencial más bajo se obtiene un 6 %medio de cota superior, hemos comprobado que elespacio ocupado para esos bloques no supera en ningunade ellas el 3 %, lo que nos hace pensar que lamejora real podría acercarse bastante a la cota superior.Hemos visto además que, como cabía esperar,cuanto mayor es el peso en la tasa de fallos en L1de los datos compartidos de sólo lectura, mayor es elpotencial de mejora de la aplicación.Estos resultados nos permiten plantear varias lineasde investigación futuras entre las que se encuentran:El estudio del patrón temporal de acceso a losdatos compartidos de sólo lectura para dar untratamiento especial adecuado a dichos datos.La identificación en el código de la aplicaciónde las estructuras de datos que corresponden alos bloques compartidos de sólo lectura. De estaforma se podría evitar la necesidad de detectardichos bloques en tiempo de ejecución, y en sulugar hacerlo en tiempo de compilación, o inclusodarle al programador la posibilidad de marcardichas estructuras de datos en el momento quesea consciente de que ya no se van a volver aescribir.El tratamiento especial en una estructura distintaa la caché L1 de los datos compartidos desólo lectura.AgradecimientosEste trabajo ha sido financiado por la FundaciónSéneca (Agencia Regional de Ciencia y Tecnología,Región de Murcia) mediante el proyecto00001/CS/2007, y por el MEC y la Comisión EuropeaFEDER mediante los proyectos “ConsoliderIngenio-2010 CSD2006-00046” y “TIN2009-14475-C04-02”. Alfonso Ramos Candel es beneficiario deuna beca de colaboración en el curso 2010/2011 (OrdenEDU/1799/2010 de 29 de junio de 2010) delMinisterio de Educación (B.O.E. de 05 de julio de2010). Antonio García-Guirado también es beneficiariode una beca de investigación del MEC bajoel Plan Nacional de Formación de Profesorado Universitario(FPU AP2008-04387).Referencias[1] N. Hardavellas, M. Ferdman, B. Falsafi, and A. Ailamaki,“Reactive nuca: near-optimal block placement and replicationin distributed caches,” in Proceedings of the 36thannual International Symposium on Computer Architecture,pp. 184–195, 2009.[2] S. H. Pugsley, J. B. Spjut, D. W. Nellans, and R. Balasubramonian,“Swel: hardware cache coherence protocolsto map shared data onto shared caches,” in Proceedings ofthe 19th international conference on Parallel Architecturesand Compilation Techniques, pp. 465–476, 2010.[3] Z. Guz, I. Keidar, A. Kolodny, and U. C. Weiser, “Utilizingshared data in chip multiprocessors with the Nahalalarchitecture,” in SPAA ’08: Proceedings of the twentiethannual Symposium on Parallelism in Algorithms and Architectures,pp. 1–10, 2008.[4] B. M. Beckmann, M. R. Marty, and D. A. Wood,“ASR: Adaptive selective replication for CMP caches,” inIEEE/ACM international Symposium on Microarchitecture,pp. 443–454, 2006.[5] P. S. Magnusson, M. Christensson, J. Eskilson, D. Forsgren,G. Hallberg, J. Hogberg, F. Larsson, A. Moestedt,B. Werner, and B. Werner, “Simics: A full system simulationplatform,” Computer, vol. 35, no. 2, pp. 50–58, 2002.[6] M. M. K. Martin, D. J. Sorin, B. M. Beckmann, M. R.Marty, M. Xu, A. R. Alameldeen, K. E. Moore, M. D.Hill, and D. A. Wood, “Multifacet’s general executiondrivenmultiprocessor simulator (GEMS) toolset,” SI-GARCH Comput. Archit. News, vol. 33, pp. 92–99, November2005.[7] S. C. Woo, M. Ohara, E. Torrie, J. P. Singh, and A. Gupta,“The SPLASH-2 Programs: Characterization and MethodologicalConsiderations,” in Proceedings of the 22th InternationalSymposium on Computer Architecture, (SantaMargherita Ligure, Italy), pp. 24–36, 1995.[8] C. Bienia and K. Li, “Parsec 2.0: A new benchmark suitefor chip-multiprocessors,” in Proceedings of the 5th AnnualWorkshop on Modeling, Benchmarking and Simulation,2009.[9] C. Bienia, S. Kumar, and K. Li, “Parsec vs. splash-2: Aquantitative comparison of two multithreaded benchmarksuites on chip-multiprocessors.,” in IISWC’08, pp. 47–56,2008.JP2011-260

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Reconfiguración de la NoC en la Virtualizaciónde CMPsFrancisco Triviño 1 , Francisco J. Alfaro 1 , José L. Sánchez 1 , José Flich 2 y Santos González 3Resumen— Debido al gran número de nodos que incorporanlos actuales sistemas en chip y el escaso gradode escalabilidad que las aplicaciones logran alcanzar,se espera que aumente el número de aplicacionesque se podrán ejecutar de forma concurrente en unmismo sistema. De esta forma, es posible aprovechargran cantidad de los recursos disponibles. Como consecuencia,se produce un aumento de las interferenciasentre las diferentes aplicaciones y por tanto el rendimientode cada aplicación por separado puede verseseriamente afectado. A nivel de red de interconexión,es posible reducir las interferencias mediante mecanismosde virtualización. Una posible estrategia devirtualización consiste en dividir la red en diferentesparticiones tal que cada una puede ejecutar diferentesaplicaciones.En este trabajo se propone un mecanismo de reconfiguraciónde la red para ofrecer soporte de virtualizaciónbajo escenarios realistas. En dichos escenarios,múltiples aplicaciones entran y salen del sistema continuamente.En este caso, el sistema debe proporcionarmecanismos de reasignación dinámica de recursoscon el fin de satisfacer las necesidades de las aplicaciones.Los resultados de evaluación muestran un buenentorno de virtualización que permite reducir el tiempode ejecución de las aplicaciones.Palabras clave— Chip Multiprocesador, Redes enChip, Virtualización, Reconfiguración.I. IntroducciónCon el fin de aumentar la velocidad de computación,las técnicas actuales de fabricación permitenincluir múltiples nodos de procesamiento en un únicochip. Aunque estos nodos no alcanzan la velocidadque proporciona un único y potente procesador de unnodo, varios de ellos mejoran las prestaciones de formaglobal. Los chip multiprocesador (CMPs) son unexcelente ejemplo de estos sistemas [1], [2].El éxito de los sistemas CMP no sólo depende delnúmero de nodos que incorporan sino también dependede otros recursos tales como el sistema de memoria(caches, memoria principal, protocolo de coherencia,etc.), y el sistema de comunicación. Debido alalto número de componentes a interconectar y parapermitir una configuración eficiente entre los recursos,es necesaria una red de interconexión de altasprestaciones. Este es el caso de las redes en chip (Networkson chip, NoCs) capaces de reducir a valoresaceptablemente bajos los tiempos de transmisión dela información [4].Por otra parte, las aplicaciones actuales muestranbajo grado de escalabilidad. Como ejemplo, el estudiorealizado en [5] revela el poco grado de escalabilidadobtenido por las aplicaciones PARSEC cuando seconsideran todos los componentes involucrados en la1 Grupo de Redes y Arquitecturas de Altas Prestaciones(RAAP), Universidad de Castilla-La Mancha, e-mail:{ftrivino,falfaro,jsanchez}@dsi.uclm.es.2 Grupo de Arquitecturas Paralelas (GAP), Universitat Politècnicade València, e-mail: jflich@disca.upv.es.3 Departamento de Informática, Universidad Peruana CayetanoHeredia,santos.gonzalez.t@upch.pe.arquitectura de un CMP. Del estudio realizado en [5]se puede observar que estas aplicaciones no escalanbien a partir de 16 hilos. Por lo tanto, para aprovechargran parte de los recursos que ofrecen los CMPs,se espera que varias aplicaciones se ejecuten de manerasimultánea. Además, a medida que aumenta elnúmero de nodos, se espera que el número de aplicacionesque se ejecutan de forma simultánea tambiénaumente. Dichas aplicaciones pueden ser de diversaíndole (visión por computador, procesamiento multimedia,animación, simulación, etc.) provocando quelos patrones de tráfico sean completamente impredecibles.En este escenario, múltiples aplicaciones compartentodos los recursos que forman el CMP. Comoconsecuencia, se produce un aumento de las interferenciasentre las diferentes aplicaciones. Así, es evidenteque si los recursos no se asignan de forma eficiente,el rendimiento de cualquier aplicación puedeverse seriamente afectado.A nivel de red, las interferencias se pueden reducirdrásticamente mediante el uso de mecanismos de virtualización.Una red virtualizada consiste en dividirla red en diferentes particiones donde cada particiónpuede ser utilizada para diferentes aplicaciones y flujosde tráfico. No obstante, la clave de esta propuestaes el hecho de no permitir que el tráfico procedentede una aplicación pueda afectar al de otras aplicaciones.En [6] se ha propuesto un mecanismo devirtualización capaz de reducir los efectos negativosque producen las interferencias. En concreto, el mecanismose analizó bajo un escenario estático dondecuatro aplicaciones comparten un CMP en el mismointervalo de tiempo.No obstante, en un sistema real, las aplicacionesentran y salen del sistema continuamente. En un escenariodinámico, se debe permitir la reasignación derecursos de red a diferentes particiones con el objetivode adaptarse a las necesidades de las aplicaciones.Por esta razón, en este trabajo, se propone un mecanismoeficiente de reconfiguración de la red paraofrecer soporte de virtualización bajo escenarios realistas,que tiene por objetivo readaptar la NoC parapermitir la creación de particiones de forma dinámica.Este artículo está organizado de la siguiente manera:la sección II muestra el trabajo relacionado. Enla sección III se describe, en primer lugar, la propuestapara aislar el tráfico de aplicaciones en unaNoC. En segundo lugar, se detalla el mecanismo dereconfiguración de red propuesto. La sección IV presentala evaluación de prestaciones y los resultadosobtenidos. Finalmente, en la sección V se presentanlas conclusiones.JP2011-261

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011II. Trabajo RelacionadoEl concepto de virtualización no es nuevo y ha sidoaplicado de una forma u otra en los sistemas de lacomputación desde principios de 1960. Por ejemplo,actualmente múltiples servidores se implementan enmáquinas virtuales (VM), que se ejecutan en un únicoservidor de altas prestaciones. De esta forma, numerosascargas de trabajo de diferente índole se consolidanen un mismo sistema donde aislar el rendimientohardware se convierte en una necesidad parala ejecución de aplicaciones con ciertas prioridades,que generalmente vienen marcadas por el usuario oadministrador.En el contexto de los CMPs, el diseño del modelode virtualización es un proceso en el que intervienenvarios elementos. Por ejemplo, la virtualización involucraal sistema operativo y a las aplicaciones quese ejecutan en un mismo sistema. El sistema de memoriadebe ser optimizado para minimizar la interferenciaentre las distintas máquinas virtuales paraaislar mejor la carga de las aplicaciones. Para solucionareste problema, Michael R. et al. proponenuna variedad de técnicas [7], todas ellas centradasen las jerarquías de memoria que implementan losCMPs. Otro ejemplo puede encontrarse en [8] dondelos autores abordan la problemática de compartirlos recursos de cache y su utilización para diferentesaplicaciones basándose en parámetros de calidad deservicio. Por desgracia, en todos estos estudios no setiene en cuenta la red de interconexión.En cuanto al sistema de interconexión, en [9] losautores introducen el concepto de NoC virtualizaday presentan algunas ventajas basadas en maximizarlas prestaciones de la red de interconexión, en mejorarla capacidad de tolerancia a fallos, y en reducir elconsumo de energía. Lamentablemente, en este estudiolos autores no detallan una metodología de cómoconseguir una NoC virtualizada y, por tanto, no serealiza ningún estudio de evaluación de prestaciones.En [6], se ha propuesto el uso del mecanismo Logic-Based Distributed Routing (LBDR) [10] como unmétodo eficiente para dividir una NoC en particiones.Concretamente, en este trabajo se analiza unasituación estática donde cuatro aplicaciones se ejecutaal mismo tiempo compartiendo un mismo CMP.Esta situación sólo se corresponde con el inicio delsistema donde se asignan el máximo número de aplicacionesposible en función de los recursos disponibles.En una situación real, las aplicaciones entrany salen del sistema continuamente a medida que losrecursos son liberados de nuevo. Por tanto, en el estudio[6] no se tuvo en cuenta ningún mecanismo dereconfiguración de la red que permita readaptar lasparticiones a nuevas aplicaciones.A. Aislar el TráficoPor lo general, un sistema CMP homogéneoestá compuesto por nodos. Cada nodo contiene unelemento de proceso, memoria cache de diferentes nivelesy el conmutador local que conecta dicho nodoa los nodos vecinos a través de la NoC. Los mensajesgenerados en el procesador se envían al conmutadora través de una interfaz de red. A continuación, elmensaje se mueve al siguiente conmutador en su caminoen función del algoritmo de encaminamiento.El proceso se repite hasta que el mensaje consiguealcanzar su destino. Bajo una situación normal, losenlaces están multiplexados en el tiempo usados porlos mensajes pertenecientes a diferentes aplicacionesque se están ejecutando en un mismo instante. Por lotanto, las aplicaciones compiten por los recursos dered en un entorno caótico donde se producen interferenciasa nivel de red. Este hecho reduce considerablementelas prestaciones obtenidas. Por lo tanto, esmuy importante aislar el tráfico de diferentes aplicacionespara mejorar las prestaciones.En [6] se presenta una NoC virtualizada capaz deseparar el tráfico generado por diferentes aplicacionesmediante la división de la red en diferentes particiones.En esta situación, los enlaces no están multiplexadosentre mensajes pertenecientes a diferentesaplicaciones.Para conseguir una NoC completamente virtualizadase propuso el uso del mecanismo LBDR [10] quepermite la creación de diferentes particiones en unamalla 2D con muy pocos recursos hardware. El mecanismoLBDR está formado por dos conjuntos de bitspor puerto de salida en cada conmutador. Se utilizauna lógica simple a nivel de bloque que contiene variaspuertas lógicas. El primer conjunto consiste enun bit por puerto y permite definir el patrón de conexiónde la partición. Cada puerto de salida tiene unbit, Cx, que indica si un conmutador está conectadoa través del puerto x. Por tanto, los bits de conectividadCn, Ce, Cw, y Cs representan la conectividadde un conmutador con los puertos norte, este, oestey sur, respectivamente. El segundo conjunto consisteen dos bits por puerto y define el conjunto de restriccionesde encaminamiento debido al algoritmo deencaminamiento finalmente implementado. Los bitspara el puerto de salida este son etiquetados comoRen y Res. Indican si los mensajes encaminados através del puerto este pueden tomar la salida por elpuerto norte o por el puerto sur en el siguiente con-III. Virtualización Dinámica de una NoCEn esta sección mostramos como se puede aislarel tráfico de diferentes aplicaciones mediante el usodel mecanismo LBDR. También se detalla la metodologíade reconfiguración capaz de adaptar el mecanismode encaminamiento a las necesidades de lasaplicaciones.Fig. 1. Ejemplo del mecanismo LBDR.JP2011-262

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a)Fig. 2. (a) Segmentación en zig-zag, y (b) bits LBDR para el algoritmo SR en una malla 2D 4x4 con 9 segmentos.(b)mutador, respectivamente. En otras palabras, estosbits indican si los mensajes pueden o no cambiar dedirección en el siguiente conmutador. Para el puertode salida norte los bits son etiquetados como Rne yRnw, para el puerto de salida oeste: Rwn y Rws, yfinalmente para el puerto de salida sur: Rse y Rsw.La figura 1 muestra un ejemplo del mecanismoLBDR donde un CMP de 16 nodos se ha divididoen dos particiones, cada una de 8 nodos. A modo deejemplo, en esta figura se detallan los bits de conectividady de encaminamiento para el conmutador 6.La figura representa con flechas las restricciones deencaminamiento, es decir, el conjunto de dos enlacesconsecutivos que no pueden atravesar los mensajes.En este ejemplo se ha aplicado el algoritmoSegment-Based Routing (SR) [11] en cada particiónpor separado.Nótese que las rutas de comunicación de cada particióndependen del algoritmo de encaminamientousado en la red. Dicho algoritmo debe ser lo suficientementeflexible para permitir particiones irregularesy debe ser diseñado teniendo en cuenta los estrictosrequisitos aplicados a arquitecturas CMP en cuantoa latencia, consumo de energía y área. El algoritmoSR cumple con dichas restricciones.B. Mecanismo de ReconfiguraciónEn esta sección se describe un método efectivo,práctico y rápido para reconfigurar los bits de encaminamientoen una NoC y permitir así la virtualizaciónde los recursos de red (mediante la divisiónde la red en diferentes particiones) en un entornodinámico.En primer lugar hay que tener en cuenta que eltamaño y forma de las particiones son elegidas porun gestor de recursos que, por regla general, se ejecutabajo el sistema operativo. El gestor de recursospuede tener en cuenta diferentes requisitos a la horade asignar recursos a las aplicaciones tales como: laminimización de la latencia de red entre los elementosde proceso, la posición de los controladores dememoria, la reducción de la fragmentación de red,posibles fallos en la red, ahorro de energía, etc. Ennuestro caso, únicamente se tiene en cuenta el númerode hilos que componen las aplicaciones, donde unhilo requiere un nodo. A nivel de red, hay que teneren cuenta que el gestor de recursos es independientedel mecanismo de reconfiguración.Se parte del hecho de que el algoritmo de encaminamientoes SR [11]. Con el algoritmo SR, es posiblepre-configurar un conjunto de bits LBDR parauna malla 2D completa y totalmente conectada. Porejemplo, la figura 2.(a) muestra el resultado de aplicarel algoritmo SR a una malla 4 × 4 1 . Aunque haynumerosas instancias que se pueden obtener del algoritmoSR, se ha elegido segmentar la red y asignarlas restricciones en forma de Zig-Zag de izquierda aderecha empezando de arriba hacia abajo. Este métodoha sido analizado obteniendo buenas prestacionescon respecto a otras segmentaciones alternativas [17].Una vez que se ha obtenido el conjunto de restriccionesde encaminamiento (representadas por flechasen la figura 2.(a)), se calculan los bits del LBDR encada conmutador. Estos bits pueden ser deducidosde forma sencilla teniendo en cuenta la localizaciónde las restricciones de encaminamiento y de conectividaden la red. A modo de ejemplo, la figura 2.(b)muestra los bits para la topología de la figura 2.(a).Teniendo en cuenta la configuración de encaminamientoanterior, y una vez que el sistema operativocomienza a ejecutar aplicaciones, se necesita identificarlas nuevas formas que resultan de la creación denuevas particiones. Por ejemplo, la figura 3.(a) muestrauna situación donde tres aplicaciones han sidoasignadas en el CMP donde los bits del mecanismoLBDR se han adaptado consecuentemente. Primero,los bits de conectividad establecen los limites de lasparticiones (por ejemplo, se configura a 0 el bit deconectividad sur de los conmutadores 2 a 7, mientrasque el puerto norte de los conmutadores 6 al11 se configuran también a 0). Además, las restriccionesde encaminamiento se deben configurar paraevitar ciclos en las particiones. Dichos bits de encaminamientose configuran de forma independiente encada partición. Por ejemplo, el conmutador 5 tieneuna restricción bidireccional en las direcciones estenortey norte-oeste.Cuando se crea una nueva partición, los bits LBDRse revisan y se actualizan acorde con la forma de lanueva partición. La figura 3.(b) muestra un ejemploa partir de la situación inicial de la figura 3.(a)donde las aplicaciones App1 y App3 han completadosu ejecución. Después, una nueva aplicación (App4)solicita 8 nodos y el sistema operativo le asigna los1 No confundir los segmentos SR (líneas punteadas) con lasparticiones (líneas continuas) del mecanismo de virtualización.JP2011-263

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110 1 2 3App1App34 5 6 70 1 2 34 5 6 70 1 2 3App44 5 6 78 9 10 11App212 13 14 158 9 10 11App212 13 14 158 9 10 11App212 13 14 15(a) (b) (c)Fig. 3. (a) Situación inicial, (b) finalizan las aplicaciones App1 y App3 , y (c) comienza la ejecución de la aplicación App4.nodos de 0 al 7 (Figura 3.(c)). En esta situación, losbits del LBDR para los conmutadores 0 a 7 se debenreconfigurar antes de comenzar con la ejecución de laaplicación App4. Como se puede deducir fácilmente,los bits de conectividad norte de los conmutadores6 y 7 se deben reconfigurar para permitir la comunicacióncon todos los nodos de la nueva partición.Lo mismo sucede con los bits de conectividad sur delos conmutadores 2 y 3. Por último, se computan lasrestricciones de encaminamiento para la nueva partición.Téngase en cuenta que este proceso de reconfiguraciónse basa en una reconfiguración estática (nohay tráfico circulando por la red) y afecta sólo a laspartes de la red donde no hay mensajes circulandoa través de los conmutadores ya que las aplicacionesque los estaban usando han terminado su ejecución.Esto es muy importante porque en otro caso podríanaparecer bloqueos. En ese caso, para evitar los bloqueos,se tendría que detener todo el tráfico de la redantes de reconfigurar la función de encaminamiento,o si se quiere evitar drenar la red previamente, se deberíaconsiderar otro mecanismo de reconfiguraciónmás complejo que no afecte el resto de particiones dela red. Gracias al hecho de que no hay interferenciasentre el tráfico perteneciente a diferentes particiones,es posible realizar una reconfiguración local sin queafecte al resto de particiones de la red. En el ejemploanterior, sólo se deben configurar los bits del LBDRde los nodos libres 0 al 7. Por esta razón, el mecanismode reconfiguración siempre asegura una situaciónlibre de bloqueo.IV. Evaluación de PrestacionesEn esta sección, se evalúa mediante simulación elentorno de virtualización, que incluye el mecanismode reconfiguración descrito anteriormente. Para llevara cabo la evaluación hemos utilizado un entornode simulación [3] basado en herramientas existentes yorientado a la evaluación de redes en chip. Dicho entornomodela de forma lo suficientemente detalladauna NoC, así como los diferentes componentes queforman una arquitectura CMP completa (procesadores,sistema de memoria, sistema operativo, aplicacionesreales, etc.).El sistema simulado es un CMP homogéneo de16 nodos. Dicho CMP se estructura en una serie denodos; cada uno contiene un procesador en orden(UltraSparc III), una cache L1 privada para datos yotra para instrucciones, una cache L2 compartida, unconmutador para comunicarlo con el resto de nodos,unidos con una red de interconexión con topología demalla de dos dimensiones. La coherencia entre los diferentesniveles de cache se preserva mediante el protocoloMOESI. En cuanto al acceso fuera del chip seusa la técnica 3D-Stacking [12] por lo que cada nodotiene acceso fuera del chip. Para la red de interconexiónse asume conmutación wormhole con tamañosde colas de 4 bits. El tamaño de flit definido es de 4bytes. Por otra parte, se utiliza el mecanismo LBDRque permite la creación de particiones junto con elalgoritmo de encaminamiento SR [11]. Además, lared opera a la misma velocidad que los procesadores.Por último, para reducir las interferencias entrela cache L2 de diferentes particiones, se obliga a quelos bloques de L2 pertenecientes a una partición seanutilizados por la aplicación que ocupa dicha partición[13]. De esta forma, se consigue aislar el contexto delas aplicaciones a nivel de sistema de memoria.Como carga de trabajo se han utilizado aplicacionesincluidas en los benchmarks SPLASH-2 [14] yPARSEC v2,1 [15]. La suite SPLASH-2 contiene unconjunto de programas que representan una ampliavariedad de aplicaciones científicas y de ingeniería.La suite PARSEC posee una amplia variedad de patronesde computación y comunicación que permitenevaluar las actuales tecnologías de CMP con mayoreficacia.A. EscenariosA fin de evaluar el mecanismo de reconfiguraciónse han considerado diferentes escenarios. En cada escenariose ejecutan 5 conjuntos de aplicaciones diferentes.Cada conjunto de aplicaciones contiene 20aplicaciones seleccionadas de forma aleatoria de losrepositorios de aplicaciones SPLASH-2 y PARSECv2,1. Los requisitos de las aplicaciones están basadosúnicamente en el número de hilos. Se ha consideradoque cada hilo solicita un nodo diferente. Losrequisitos de cada aplicación son elegidos de formaaleatoria desde 2 hasta 8 hilos. El gestor de recursosasigna automáticamente los recursos del CMP alas aplicaciones de forma secuencial. Las aplicacionesson almacenadas en una cola FIFO hasta que elgestor de recursos tiene suficientes recursos para comenzarla ejecución de la siguiente aplicación. Losescenarios se diferencian en el uso que se hace de losrecursos del CMP.JP2011-264

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011El primero consiste en un escenario base (EB) dondecada aplicación utiliza todos los recursos que formanel CMP. En este escenario los hilos que formancada aplicación son distribuidos de forma aleatoria.En este caso no se considera ningún mecanismo devirtualización, y por tanto, el mecanismo de reconfiguraciónno es necesario. Así, el tráfico generado poruna aplicación en concreto se verá afectado por eltráfico generado por otras aplicaciones.El segundo caso evaluado (RV, regiones virtuales)parte del escenario base, pero en este caso, la redse divide para crear regiones de forma dinámica. Eneste escenario, los mensajes generados por diferentesaplicaciones sólo pueden usar los recursos de redpertenecientes a dicha región, por lo tanto, las aplicacionesposeen sus propios recursos de forma dedicadadonde el tráfico de una región no puede cruzarotras regiones. Como el tráfico de las aplicacionesdebe ser aislado, los recursos deben ser asignados deforma contigua. Por esta razón, se utiliza la estrategiade asignación de recursos presentada en [16].Hay que tener en cuenta que el gestor de recursoses independiente del mecanismo de reconfiguración.En este escenario cada aplicación es asignada a unaregión virtual de forma similar que en el ejemplo dela figura 3. Cada partición tendrá diferente tamañodependiendo de los requisitos de la aplicación a ejecutar(número de hilos).Por último, hemos considerado un escenario adicionalcon el objetivo de mostrar el efecto negativoque producen las interferencias en el tráfico de red.Este escenario (DV, dominios virtuales) parte del escenarioRV. Sin embargo, los mensajes pertenecientesa un dominio pueden cruzar los límites de otros dominiospara alcanzar sus destinos. En este escenario,la carga de red se distribuye a lo largo de todo elCMP dependiendo del algoritmo de encaminamientousado y suponiendo, en todo momento, caminosmínimos. Como cabe esperar, en el escenario DV nose aplica el mecanismo de reconfiguración de la redpuesto que no es necesario. En lugar de eso se haaplicado el algoritmo de encaminamiento SR en lamalla completa tal y como muestra la figura 2.(a).Por ultimo, cabe destacar que únicamente se aplicael mecanismo de reconfiguración en el escenarioRV. En este caso, se ha considerado el tiempo deejecución adicional cada vez que se ha aplicado elmecanismo de reconfiguración, el cual depende principalmentedel tamaño de la partición. Con respectoal gestor de recursos, no se ha tenido en cuenta laposible sobrecarga en tiempo de ejecución de dichaestrategia.B. ResultadosEn esta sección se presentan los resultados obtenidosen el proceso de evaluación. Se han ejecutado 5conjuntos de 20 aplicaciones en cada escenario. Puestoque en el escenario EB los hilos son asignados alos nodos de forma aleatoria, cada valor obtenido coneste escenario es el resultado de treinta simulacionesdiferentes, donde el intervalo de confianza se ha establecidoal 95 %.110105100959085807570EB RV DVSet1 Set2 Set3 Set4 Set5Fig. 4. Tiempo de ejecución normalizado.La figura 4 muestra el tiempo de ejecución para losdiferentes conjuntos de aplicaciones (eje-x). El eje-yrepresenta la diferencia en el tiempo de ejecución totalentre los diferentes escenarios (EB, RV y DV). Parailustrar la variación de rendimiento, los resultadosse muestran en términos normalizados comparadoscon el tiempo de ejecución para el caso EB.Para el escenario EB, las aplicaciones compartenla totalidad de los recursos del CMP. En este sentido,se obtiene un comportamiento caótico donde las interferenciasentre el tráfico de diferentes aplicacionesocurren constantemente, lo que termina afectando alrendimiento individual de las aplicaciones.Por otra parte, en el escenario DV se producenmenos interferencias de tráfico que en el escenarioEB y por tanto las prestaciones son mucho mejores.En concreto, el tiempo de ejecución decrece en un14 % (para el conjunto Set3) comparado con el casoEB como se puede ver en la figura 4. Si comparamosRV con DV, a pesar de tener la misma asignaciónde recursos, se obtienen mayores beneficios con RV,puesto que el tiempo de ejecución decrece otro 10 %comparado con el escenario DV (en el conjunto Set3).Aunque el tiempo de ejecución es la métrica másimportante cuando se utilizan aplicaciones reales, enel ámbito de las redes de interconexión son interesantestambién otras métricas como la latencia de redy el uso medio de los enlaces. La figura 5 muestrala latencia media producida en la red (a) y la cargamedia de los enlaces (b) para el conjunto Set1 deaplicaciones, de nuevo en términos normalizados encomparación con el valor obtenido para el caso EB.En este caso, la latencia obtenida para el escenarioEB se incrementa en un 22 % comparada con ladel escenario RV, así como un 13 % para el escenarioDV. La razón principal por la que el escenarioRV obtiene mejores prestaciones se encuentra en elhecho de que el mecanismo de reconfiguración dividela red en diferentes regiones y la distancia mediade los mensajes generados por las aplicaciones se reducede forma significativa. Por tanto, el tráfico decada aplicación tiene muy baja latencia, lo cual estambién una de las razones por las que se obtienemejores tiempos de ejecución. Cuando los orígenesy destinos de los mensajes no están muy próximos,un mensaje debe atravesar nodos intermedios paraalcanzar su destino. Cuando se incrementa el númerode saltos, la probabilidad de interferir con otrosJP2011-265

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111051009590858075EB RV DV(a)Fig. 5. (a) Latencia media normalizada y (b) uso de enlaces.mensajes se incrementa también, lo cual se convierteen un aumento de la latencia. Si se comparan losescenarios RV y DV, y teniendo en cuenta que loshilos han sido asignados a los mismos nodos, las diferenciasson únicamente debidas a las interferenciasentre mensajes.Por otra parte, el uso medio de los enlaces representael uso de la red. Esta métrica se ha calculadoteniendo en cuenta la carga de todos los enlaces desdeel principio de la simulación hasta que todas las aplicacioneshan finalizado su ejecución. Como se puedeobservar, el escenario RV consigue reducir la sobrecargade comunicación y el tráfico producido puestoque aisla completamente el tráfico de las aplicaciones.Por tanto, se reduce significativamente la cargamedia de los enlaces cuando se utiliza el mecanismode virtualización. El escenario RV muestra una reduccióndel 5 % sobre el escenario DV. Por último,aunque únicamente se muestran resultados para elconjunto Set1 de aplicaciones, la tendencia para lalatencia y carga de la red es similar para todos losconjuntos de aplicaciones evaluados.(b)V. ConclusionesEste artículo trata de mejorar el rendimiento delas aplicaciones que se ejecutan de forma simultáneamediante el concepto de virtualización. El mecanismode virtualización permite aislar el tráfico generadopor cada aplicación para reducir la sobrecarga decomunicación debida a interferencias entre mensajespertenecientes a diferentes aplicaciones. En un sistemareal, las aplicaciones entran y salen del sistemacontinuamente. En este caso, la red debe ser capazde asignar recursos de red a diferentes particiones deforma dinámica. Por esta razón, en este trabajo sedescribe un mecanismo de reconfiguración para ofrecersoporte de virtualización bajo escenarios realistasdonde los recursos del sistema son asignados de formadinámica.Se han evaluado tres casos: un modelo base (EB)sin soporte de virtualización y dos modelos basadosen virtualización (RV y DV) donde el primero (RV)aisla completamente el tráfico de las diferentes aplicacionesmientras que el segundo (DV) no aisla eltráfico. Se ha observado que el escenario RV puedesuponer una importante mejora en las prestacionesque el sistema obtiene. En concreto, se ha observadoque el escenario RV reduce (para todos los conjuntosde aplicaciones que hemos simulado) entre un 5 %y un 12 % el tiempo de ejecución comparado con elescenario DV (donde no se aisla el tráfico de aplicaciones).Además, la latencia y carga media de la redsiguen la misma tendencia que el tiempo de ejecución.Este hecho se debe a la eliminación de las interferenciasde tráfico entre mensajes pertenecientesa diferentes aplicaciones puesto que en ambos casosel resto del CMP (principalmente nodos y cache) seha particionado de la misma forma.AgradecimientosEste trabajo ha sido cofinanciado por el MEC yMICINN del gobierno de España, y por fondos FE-DER de la Comisión Europea, con las subvencionesConsolider Ingenio-2010 CSD2006-00046 y TIN2009-14475-C04-03, respectivamente; por la Consejería deEducación y Ciencia de la JCCM con los proyectosPEII11-0229-2343 y POII10-0289-3724, y por el proyectoNaNoC (referencia 248972) que está financiadopor la Comisión Europea dentro del programa de investigaciónFP7.Referencias[1] “Tilera Tile-Gx Product Brief,” 2010. Available:http://www.tilera.com/pdf/PB025-TILE-Gx-Processor-A-v3.pdf[2] S. R. Vangal, et al., “An 80-tile sub-100-W TeraFLOPSprocessor in 65-nm CMOS,” IEEE JSSC, 2008.[3] F. Triviño, F. J. Andujar, F. J. Alfaro, J. L. Sánchez,and A. Ros, “Self-Related Traces: An Alternative to Full-System Simulation for NoCs,” in HPCS, 2011.[4] F. Gilabert, F. Silla, M. E. Gomez, M. Lodde, A. Roca,J. Flich, J. Duato, C. Hernández, and S. Rodrigo, DesigningNetwork On-Chip Architectures in the NanoscaleEra, J. B. D. Flich, Ed. CRC Press, 2010. Available:http://www.crcpress.com/product/isbn/9781439837108[5] F. Triviño, J. L. Sánchez, and F. J. Alfaro, “Effect of theCMP Network on the PARSEC v2.1 Benchmark Suite Scalability,”INAOCMC, 2010.[6] F. Triviño, J. L. Sánchez, F. J. Alfaro, and J. Flich,“Virtualizing network-on-chip resources in chipmultiprocessors,”MICPRO, vol. 35, pp. 230–245,2011.[7] M. R. Marty and M. D. Hill, “Virtual hierarchies to supportserver consolidation,” in ISCA, 2007.[8] F. Guo, et al., “From Chaos to QoS: Case Studies inCMP Resource Management,” SIGARCH Comput. Archit.News, 2007.[9] J. Flich, J. Duato, T. Sødring, Å. G. Solheim, T. Skeie,O. Lysne, and S. Rodrigo, “On the Potential of NoC Virtualizationfor Multicore Chips,” in MuCoCoS, 2008.[10] J. Flich and J. Duato, “Logic-Based Distributed Routingfor NoCs,” IEEE Comput. Archit. Lett., 2008.[11] A. Mejia, J. Flich, and J. Duato, “On the Potentials ofSegment-Based Routing for NoCs,” in ICPP, 2008.[12] B. Black, et al., “Die Stacking (3D) Microarchitecture,”in MICRO, 2006.[13] S. Cho and L. Jin, “Managing Distributed, Shared L2Caches through OS-Level Page Allocation,” in MICRO,2006.[14] S. C. Woo, et al., “The SPLASH-2 programs: characterizationand methodological considerations,” in ISCA, 2005.[15] C. Bienia and K. Li, “PARSEC 2.0: A New BenchmarkSuite for Chip-Multiprocessors,” in MoBS, 2009.[16] A. G. Solheim, O. Lysne, T. Sødring, T. Skeie, andJ. A. Libak, “Routing-contained virtualization based onUp*/Down* forwarding,” in HiPC, 2007.[17] A. Mejia, “Design and Implementation of Efficient TopologyAgnostic Routing Algorithms for InterconnectionNetworks”, PhD dissertation, University of Valencia, 2008.JP2011-266

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Beneficios del uso de la Red de Interconexiónen la Aceleración de la CoherenciaLucía G. Menezo, Adrián Colaso, Pablo Prieto, Pablo Abad, Valentín Puente, José Ángel GregorioResumen—A lo largo de este trabajo se realiza un análisisdel comportamiento de diversas aplicaciones con el fin deevaluar los beneficios que supondría hacer partícipe a lared de interconexión en el protocolo de coherencia de unCMP. La colaboración de la red de interconexión en lagestión de las peticiones que realizan los cores podríaacelerar la resolución de las fases de sincronización de lasaplicaciones, suponiendo de este modo una mejora en elrendimiento global de este tipo de sistemas. Utilizando unentorno basado en el simulador funcional Simics, junto conel simulador de sistemas multiprocesador GEMS y elsimulador detallado de redes de interconexión SICOSYS,se ha determinado el nivel de compartición de los datosatendiendo fundamentalmente a la coincidencia temporalde las peticiones realizadas. Los resultados para unconjunto significativo de aplicaciones muestran unosvalores muy bajos de simultaneidad al enviar peticiones alresto de los procesadores. La media de todas lasaplicaciones analizadas muestra que cuando ocurre unmiss en una cache L1 y se envía una petición al resto decontroladores de coherencia, en promedio, tan solo en un1% de los casos se encuentran una o más peticionespendientes de otros procesadores a la misma dirección y enese intervalo de tiempo.Palabras clave—Coherencia, Redes de interconexión,Sincronización, Sistemas multiprocesadorEI. INTRODUCCIÓNN la actualidad, los avances en la tecnología porsí solos no son suficientes para incrementar elrendimiento de los sistemas de forma notable. Elconsumo limitado de energía o el ancho de bandadisponible hacia el exterior del chip son algunos de losfactores que provocan que las mejoras en muchos casossean casi inapreciables. Por esta razón, los arquitectos decomputadores han optado por conseguir mejoras en elrendimiento mediante la inclusión de varios cores en elinterior del chip (CMPs) fundamentando las mejoras derendimiento en el paralelismo a nivel de thread.Sin embargo, la paralelización de tareas no está libre deproblemas. Es necesaria la sincronización y lacomunicación entre todos los procesadores en el accesoa los recursos compartidos. Dentro de estos recursoscompartidos, uno de los mayores obstáculos en esteaspecto es la multiplicidad de copias que, para unadirección de memoria, se puede encontrar a lo largo dela jerarquía de cache. Esto obliga a disponer en elsistema de algún tipo de mecanismo que garantice unavisión coherente de la jerarquía de memoria. La opciónmás viable, desde el punto de vista de laprogramabilidad del sistema, es optar por unaaproximación hardware. Los controladores decoherencia de cada uno de los niveles de la jerarquía dememoria son los encargados de implementar protocolosGrupo de Arquitectura y Tecnología de ComputadoresUniversidad de Cantabria, Facultad de Ciencias, Santander{gregoriol, acolaso, prietop, abadp, vpuente, monaster}@unican.esJP2011-267de coherencia precisos para garantizar la visióncoordinada de la jerarquía de memoria por parte detodos los cores.El comportamiento de los protocolos de coherenciapuede llegar a marcar una gran diferencia en elrendimiento de los sistemas multiprocesador. Son losresponsables directos de resolver las peticiones querealizan los procesadores y evitan los conflictos quepueden surgir entre ellas debido a las posibles carreraspor el acceso a los datos compartidos.El número de cores integrados en el chip y la topologíautilizada para conectarlos entre sí, son dos parámetrosclave para decidir qué metodología emplear paramantener la coherencia. Por un lado, cuando el númerode procesadores es pequeño, la red de interconexión máseficaz es el bus. Este tipo de redes permite laimplementación de protocolos de coherencia basados enla técnica snoopy. Cuando el número de procesadores esmás alto, la nula escalabilidad en el ancho de banda delbus hace necesario utilizar redes de interconexión comolos crossbars. Sin embargo, si el número deprocesadores sigue creciendo se requieren redes con unaescalabilidad más elevada, como las redes punto a puntotales como mallas, toros, etc.De la misma manera que la red de interconexión debeser diferente según el número de procesadores y ladistribución del sistema de memoria, los protocolos decoherencia también deben implementarse pensando en elsistema en el que van a funcionar. Básicamente, existendos variantes diferenciadas de protocolos de coherencia.Por una parte se encuentran los basados en directorio,donde existe una estructura lógicamente centralizadaque arbitra los accesos a los bloques compartidos entrelos distintos procesadores, serializándolos cuando sonincompatibles, para evitar los conflictos. La ventaja deestos protocolos es que el tráfico escala, pero cuando elnúmero de procesadores es elevado requieren muchoespacio para almacenar la información sobre lacoherencia del sistema o tienen problemas deinclusividad entre los diferentes niveles de la jerarquía.Además, la serialización de las peticiones supone unaumento considerable en la latencia total de laspeticiones debido sobre todo a la indirección que suponeacceder al directorio. Por otra parte, se encuentran losprotocolos de coherencia basados en broadcast. Estetipo de protocolos no requieren de una estructuracentralizada y mantienen la coherencia de maneradistribuida entre todos los controladores. Cuando seutilizan en redes de interconexión no ordenadas comolas mallas o los toros, la aparición de carreras depeticiones y datos son probables, por lo que es necesarioincluir en el protocolo algún mecanismo de evitación ode detección de conflictos.En cualquiera de los dos casos, surge la duda de si lared de interconexión puede contribuir a acelerar laresolución de los conflictos en los accesos a los datoscompartidos. Este trabajo, usando un entorno deevaluación preciso y próximo a la realidad, evalúa

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cuáles son las posibilidades reales de tal aproximación.Aunque de los datos obtenidos se desprende que elvolumen de contención en el acceso a los datoscompartidos no es lo suficientemente intenso como paraque soluciones de este tipo conlleven un beneficiotangible en el rendimiento del sistema, espotencialmente utilizable desde el punto de vista desimplificación del diseño del protocolo de coherencia.El trabajo está estructurado como sigue: la sección 2repasará el trabajo relacionado, la sección 3 presentará elentorno y metodología de evaluación, la sección 4presentará los resultados más significativos y la sección5 mostrará las conclusiones más relevantes.II. TRABAJO RELACIONADOPara obtener alto rendimiento en los sistemas, losprotocolos de coherencia han de ser capaces de permitirmúltiples peticiones pendientes por procesador yposibilitar la ejecución de operaciones concurrentes.Esto supone la aparición de numerosos estadostransitorios y de un comportamiento altamente complejode determinar que dificulta enormemente el trabajo delos arquitectos que los diseñan y verifican, conduciendoocasionalmente a comportamientos imprevisibles de lossistemas, que tienen un alto impacto económico.Por esta razón, van apareciendo trabajos dirigidos asimplificar el diseño y la verificación de dichosprotocolos, incluso a costes elevados. En atomiccoherence [1] por ejemplo, las peticiones simultáneas auna misma dirección de memoria se serializan con unmutex óptico antes de ser emitidas. De esta manera seasegura la eliminación de carreras y por lo tanto seconsigue simplificar considerablemente el protocolo decoherencia. También con el fin de facilitar la validaciónde los protocolos, en fractal coherence [2] se proponeuna nueva metodología en el diseño de arquitecturas,para así poder manejar protocolos de coherenciafácilmente verificables mediante un comportamientofractal.Es precisamente esta necesidad de optimización de losprotocolos de coherencia la que está llevando a muchosarquitectos a hacer partícipe a la red de interconexiónen el protocolo de una u otra manera.Por un lado es posible añadir nuevas funcionalidades alos routers o encaminadores tal y como hacen enSwitchMSHR [3] donde se añaden varios registros parapeticiones pendientes (Miss Status Holding Registers) encada router de la red, con el fin de mantener unseguimiento de las lecturas y conseguir repartir el dato aleer cuando hay más de una petición pendientesimultánea.Otro papel que puede llevar a cabo la red es la derealizar en ella la ordenación de mensajes. Ejemplostales como timestamp snooping [4] o INSO [5],consiguen ordenar los mensajes en los routerspermitiendo la evitación de carreras y por lo tantosimplificando el protocolo, aunque obviamente a costadel rendimiento.En in-network cache coherence [6], los encaminadoresmantienen una estructura lógica que va uniendo loscompartidores de un dato con el fin de redireccionar lasnuevas peticiones hacia donde está dicho dato. Estapropuesta es dependiente del recorrido que realizan laspeticiones. Eliminando esta dependencia, virtual treecoherence [7] también mantiene un seguimiento de loscompartidores de un dato pero sólo los de una regiónamplia y empleando las propiedades del árbol virtualpara forzar el orden entre las peticiones. De las mismasautoras que el anterior trabajo, también proviene lapropuesta de emplear la red de interconexión para filtrarlos mensajes enviados en broadcast por el protocolo decoherencia. Añaden en los routers filtros quedinámicamente rastrean patrones de compartición entrevarios cores. De esta forma, es posible eliminarpeticiones redundantes que se están dirigiendo haciazonas donde no hay compartidores, consiguiendo conello una reducción en la energía consumida [8].En definitiva, cada vez parece más claro que, dada laenorme sinergia existente entre la red de interconexión yel resto de la jerarquía de memoria, resultaráimprescindible hacerla participe en las tareas propias delprotocolo con el fin de mejorar el rendimiento delsistema completo o simplificar el proceso de diseño delos protocolos de coherencia. No obstante, previamentees imprescindible detallar los aspectos sobre los que lared podría incidir para obtener dicha mejora.III. ENTORNO Y METODOLOGÍA DE EVALUACIÓNComo ya se ha mencionado anteriormente, el análisispresentado en este trabajo pretende ayudar a comprendermejor el comportamiento real de las aplicacionesejecutadas en un CMP con el fin de encontrar el modoen el que la red de interconexión pueda colaborar de unamanera directa en el protocolo de coherencia. Dentro deeste análisis se pueden distinguir dos visiones condiferentes perspectivas. Por una parte se ha analizado dequé manera son vistas las peticiones de los procesadorespor la red de interconexión, centrándonos especialmenteen la simultaneidad temporal de esas peticiones. Por otraparte, parece necesario conocer el comportamiento delas aplicaciones estudiadas desde el punto de vista de lasinstrucciones de sincronización y comprobar que dichocomportamiento es coherente con los resultadosanteriores.El sistema con el que trabajaremos, a lo largo de todoel análisis, es un CMP con 8 procesadores conectadosmediante una red de interconexión en malla 4×4. Lajerarquía de memoria tiene 2 niveles de cache. Unprimer nivel privado para cada procesador con L1 dedatos y de instrucciones, de 128 KB cada uno. Además,se dispone de un segundo nivel de cache compartidadividida en 16 bancos de 512 KB cada uno. El protocolode coherencia empleado es un protocolo basado entokens [9] optimizado. En la Fig. 1 se muestra unesquema del sistema simulado.JP2011-268

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1 Esquema general del sistema simulado compuesto por 8 coresy 16 bancos de L2 interconectados mediante routers (R) en unamalla 4×4.El entorno de simulación en el que hemos trabajadoconsta de tres simuladores: Simics [10], GEMS [11] ySICOSYS [12]. Con GEMS es posible simular elsistema de memoria completo. Por su parte, SICOSYSnos permite simular, de manera detallada, elcomportamiento de la red de interconexión.Con el primer conjunto de pruebas se ha determinadola cantidad de peticiones a la misma dirección dememoria que se realizan de forma simultánea por dos omás procesadores y cuáles se realizan de forma única.Para conocer este dato, se han implementado enSICOSYS dos estructuras globales y accesibles paratodos los componentes de la red. Su cometido principales mantener anotadas todas las peticiones que tienenpendientes los procesadores del sistema, de manerasimilar a lo que hace un MSHR dentro del procesador,pero a nivel de red. Una de estas estructuras se utilizapara anotar las peticiones de lectura pendientes y la otrapara mantener las peticiones de escritura. Nosreferiremos a cada una de ellas como pending_reads_map y pending_writes_map para las lecturas yescrituras respectivamente. Cada entrada de estas dosestructuras contiene la dirección de memoria a la que sequiere acceder y un contador que indica el número deprocesadores con esa petición pendiente por resolver.Cuando un procesador desea hacer una operación delectura o de escritura se comprueba en la L1 privada siexiste el bloque necesario. Si no está presente, elcontrolador de L1 envía un broadcast de la peticiónincluyendo como destinatarios del mensaje al resto decontroladores de L1, al controlador de L2 y alcontrolador de memoria principal. En el momento en elque se inyecta el mensaje en la red, se añade la direcciónque está siendo solicitada en el pending_mapcorrespondiente según el tipo de petición y seincrementa el número de peticiones pendientes.Posteriormente se almacena en un histograma el númerode peticiones pendientes del mismo tipo (lectura oescritura) que ha encontrado en la red y, en otroJP2011-269histograma, cuántas peticiones pendientes hay a esadirección de memoria global (tanto de lectura como deescritura). En el momento en el que una petición seresuelve, es decir, el controlador de L1 recibe el bloqueque había solicitado y por lo tanto el procesador puedellevar a cabo la operación pendiente, se decrementa elcontador correspondiente a esa dirección en elpending_map. De esta manera cuantificamos lasincronicidad en el acceso a los datos compartidos porparte de los diversos procesadores.Con estos cálculos, se pretende saber cuánto podríaayudar la red de interconexión a resolver peticionessimultáneas si se dispusiese de la información necesariaalmacenada en los encaminadores.Por otra parte, en paralelo con la monitorización de lared de interconexión, se ha llevado a cabo un análisissobre el comportamiento de sincronización de lasaplicaciones bajo estudio para tener un conocimientomás detallado sobre las instrucciones que se ejecutan enlas aplicaciones empleadas y comprobar que losresultados que “ve” la red son coherentes con dichoscomportamientos de las aplicaciones. Para llevar caboesta tarea se ha analizado el código de sincronizaciónque se ejecuta en cada una de las aplicaciones,entendiendo como código de sincronización el conjuntode instrucciones atómicas ejecutadas e instrucciones deacceso a las secciones criticas (Test and Test-and-Set).Esta simplificación es debida a que, determinar el totalde código de sincronización es una tarea compleja, yaque los bloques de sincronización tienen estructuras muydiferentes en función de si se ejecutan en modo usuarioo supervisor. Por esta razón es necesario aplicar distintastécnicas conjuntamente. Para realizar la instrumentaciónde dichas aplicaciones se ha utilizado el módulo tracerdel simulador Simics. Este módulo nos permite accedera los 32 bits que componen cualquier instrucción de laarquitectura SPARC y clasificarla para su posterioranálisis. Además, Simics proporciona una función paradiscernir entre las instrucciones ejecutadas en modosupervisor y las ejecutadas en modo usuario.TABLA 1. CONFIGURACIÓN DEL SISTEMA EMPLEADO.Núm. de procesadores8 @3GHzNúm. peticiones pendientes 16Ventana de instrucción /Issue Width128/4-wayTamaño del bloque 64 BTamañoL1 (instrucciones y datos)128 KBAsociatividad 4Tiempo de acceso (ciclos) 2Tamaño 512 KBx16banksL2 Asociatividad 16Tiempo de acceso (ciclos) 5Red Topología Malla 4×4En la arquitectura SPARC [13] se pueden distinguirdos tipos de instrucciones atómicas utilizadas para lasincronización y la actualización de memoria llevada a

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cabo por procesos concurrentes: Load-Store UnsignedByte (LdStUB) y Compare-and-Swap (CaS) 1 . Laprimera instrucción es la primitiva atómica originalempleada en el sistema operativo Solaris paraimplementar los locks exclusivos. Básicamente es laclásica instrucción test-and-set que recoge el valor de unbyte de una dirección de memoria en un registro yescribe 0xFF en dicha dirección. Como es sabido, lalimitación de esta instrucción es que, de forma wait-free,únicamente puede resolver la contención de dosprocesos. Por el contrario, la instrucción CAS lo puedehacer con un número ilimitado de ellos. Esta instrucciónemplea una dirección de memoria y dos registros. Alejecutarse compara una palabra en memoria con uno delos registros, si son iguales, la instrucción intercambia elcontenido de la palabra de memoria con el segundoregistro. Ambas instrucciones han sido rastreadasdurante la ejecución.Además de estas instrucciones atómicas, es necesarioidentificar el resto de código dedicado a lasincronización para el acceso único a las seccionescríticas. Debido a la complejidad que supone diferenciartodas las instrucciones dedicadas a sincronización,contabilizaremos únicamente como tales, las lecturas auna dirección física de memoria que es accedida por unainstrucción atómica.IV.EVALUACIÓN DE LOS RESULTADOSA. Cargas de trabajoComo se ha mencionado, para la obtención de losresultados se ha utilizado un entorno de simulaciónbasado en el simulador funcional Simics, junto conGEMS y Sicosys.Los resultados han sido obtenidos de la ejecución de 18cargas de trabajo diferentes, que son las mostradas en laTabla 2. Corresponden a tres benchmarks del tipocliente-servidor, que forman parte de la WisconsinCommercial Workload Suite [14]; las aplicacionesnuméricas de enteros de los NAS ParalellBenchmarks[15]; cuatro de las aplicaciones de la suitePARSEC [16]; y, por último, tres aplicacionesmultiprogramadas de la suite SPEC CPU2006 [17]. Estenúmero alto de aplicaciones proporciona una granvariedad de comportamientos, consiguiendo analizar lasimultaneidad de las peticiones en aplicaciones muyCliente-servidor(WisconsinCommercial Suite)NUMÉRICASCargasmultiprogramadasTABLA 2. CARGAS DE TRABAJO UTILIZADASApache Jbb ZeusNAS BT CGFTISLU MGSP UAPARSECBlackscholes CannealFluidanimate SwaptionsAstar Hmmer Lbmdiferentes, con distinto grado de compartición,contención, tamaño del problema, etc.B. ResultadosA continuación se muestran los resultados obtenidos.En la Fig. 2 se representa el porcentaje de peticiones delectura (GETS) y de escritura (GETX) que realizan doso más procesadores simultáneamente en cada una de lasaplicaciones consideradas.Lo primero que llama la atención de estos resultadoses la poca simultaneidad temporal que existe, es decir,en la gran mayoría de las aplicaciones, prácticamente el100% de las peticiones sobre una dirección de memoriaque se realizan son únicas y no hay ningún otroprocesador que necesite también acceder a ella al mismotiempo. La aplicación que tiene este porcentaje más bajode peticiones únicas es swaptions, donde el 94 % de laslecturas son únicas y el 96% de las escrituras también.En esta aplicación, el 4% de los misses en L1, provocanuna petición al resto cuando hay otro procesador másque también quiere el mismo dato. En menor medida, un1%, otros misses coinciden en la red con otros dosprocesadores. De las PARSEC también destaca, sobrelas demás, las escrituras simultáneas entre dosprocesadores de la aplicación fluidanimate que tambiénalcanzan el 2% de las escrituras globales. En el ladocontrario se encuentra canneal, donde la ejecución decada procesador se mantiene independiente de los demása pesar de que su gran working set es activamentecompartido. Esto ocurre debido a que tan solo unapequeña porción de él entra en la cache haciendo que laprobabilidad de que una línea sea accedida por más deun procesador antes de ser reemplazada sea muy baja.En cuanto a las aplicaciones numéricas, todasmuestran también muy poca simultaneidad en cuanto alas direcciones de memoria accedidas. Esto ocurreporque a pesar de ser aplicaciones muy demandantesdesde el punto de vista de la red de interconexión, cadauna de las peticiones realizadas son independientes delresto. Se aprecia alguna excepción como mg o cg dondehay un porcentaje mayor de escrituras simultáneas pero,de nuevo, no llegan a alcanzar ni el 2% de todas laspeticiones que se realizan a lo largo de la ejecución.También bt por su parte muestra un número elevado delecturas simultáneas, indicando que sí existen datosaccedidos por más de un procesador en el mismointervalo de tiempo.Los datos no resultan nada sorprendentes en lasaplicaciones multiprogramadas, donde el grado decompartición es prácticamente nulo y por lo tanto sí eraesperable obtener valores cercanos a cero en estosbenchmarks.Los que sí resultan algo más sorprendentes son losresultados obtenidos de la ejecución de las aplicacionescliente-servidor. Estas son aplicaciones con un altogrado de compartición y se podría esperar queapareciesen muchas operaciones simultáneas de losdistintos procesadores. Sin embargo, la Fig. 2 muestraclaramente como el acceso a las direcciones de memoriallevado a cabo por los distintos procesadores, nocoinciden en el tiempo en el sistema analizado.1 Existe una tercera instrucción atómica Swap pero que está obsoleta yse mantiene por compatibilidad.JP2011-270

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011%65432108 7 6 5 4 3 2GETSGETXGETSGETXastar hmmer lbm bt cg ft is lu mg sp ua apache jbb zeus blacks cann fluid swapt AVGFig. 2 Porcentaje de peticiones de lectura y escritura que se realizan simultáneamente en el tiempo.%10.1AtómicasSincronización0.010.0010.00010.00001Fig. 3 Porcentaje de instrucciones de sincronización y atómicas del total de instrucciones ejecutadas. (Porcentaje en eje Y en escala logarítmica)Si cambiamos el punto de vista y pasamos a analizarlas instrucciones de sincronización ejecutadas por cadaprocesador podemos comprobar que son totalmentecoherentes con los resultados mostrados anteriormente.En la Fig. 3 se muestran los porcentajes deinstrucciones atómicas e instrucciones de sincronizaciónejecutadas en cada aplicación. Nótese que losporcentajes del eje Y están en escala logarítmica con elfin de poder ver los valores mínimos de sincronizaciónque tienen algunas de las aplicaciones. Los valores sonla media de los 8 procesadores. En el caso de lasaplicaciones numéricas, las instrucciones desincronización son muy bajas, excepto en el caso de cg yde mg que sí se muestra algo más de sincronización perono se llega a alcanzar ni el 0.1% del total deinstrucciones ejecutadas. Para las aplicaciones clienteservidorse puede ver como en todas ellas hay unporcentaje bastante más alto de instrucciones desincronización y atómicas. Esto parece no concordar conlos datos de las peticiones simultáneas de la Fig. 1,donde no se veía simultaneidad en la petición. Sinembargo, la cantidad de instrucciones atómicas esprácticamente la misma que la cantidad de instruccionesde sincronización, lo que significa que, durante laejecución de las aplicaciones, hay muy poca contenciónen el acceso a las secciones críticas. Igualmente, estecomportamiento se puede comprobar en el caso de lasPARSEC, donde también se llega a apreciar un númeroalto, en comparación con la mayoría, de instruccionesde sincronización. En el caso de canneal, la proporciónde instrucciones de sincronización y atómicas esprácticamente la misma, indicando que apenas hayconflictos en los accesos a la entrada de las seccionescríticas y, por lo tanto, sin simultaneidad en lasJP2011-271direcciones de memoria a las que se acceden. En el ladoopuesto se encuentra swaptions, donde casi el 90% de lasincronización está dedicada a los intentos de acceso alas secciones críticas, indicando que sí existen másocasiones en las que hay operaciones simultáneas entremás de un procesador siendo coherente con lo observadodesde el punto de vista de simultaneidad de lasoperaciones en memoria.Independientemente de los casos individuales de cadaaplicación, lo más importante de los resultadosmostrados en este trabajo es la escasa coincidenciatemporal en el acceso a los datos. Desde el punto devista del protocolo de coherencia, de media, el 99% delas peticiones que se envían, lo hacen de forma única ysin existir otro procesador que quiera acceder a la mismadirección de memoria.V. CONCLUSIONES Y TRABAJO FUTUROAnalizados los resultados obtenidos, parece claro que,al no producirse solapamiento en el momento de enviarlas peticiones, implementar cualquier mecanismo en lared de interconexión con el objetivo de resolver posiblesconflictos de acceso a datos compartidos que ocurran enese momento, no parece que vaya a tener ningún efectoen el rendimiento de los sistemas puesto que esassituaciones son muy escasas.Por esta razón, y viendo que la mayoría de laspeticiones son únicas, la participación de la red en elprotocolo de coherencia deberá dirigirse hacia laaceleración en la localización del dato, minimizando conella la latencia de los misses. Si se añade información alos encaminadores sobre la distribución de los datos queestán siendo compartidos sería posible redireccionar

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011peticiones hacia donde la red conoce bien la últimaubicación del dato o bien la más cercana, dependiendode la acción a realizar.Por último, sigue abierta la posibilidad de añadirfuncionalidades de filtrado, evitando el envío demensajes hacia regiones donde la red podría conocer queno se encuentra el dato requerido.[17] SPEC Standard Performance Evaluation Corporation, “SPEC2006.”AGRADECIMIENTOSEl presente trabajo ha sido financiado mediante elproyecto MICINN TIN2010-18159 y la red deexcelencia europea HiPEAC.REFERENCIAS[1] D. Vantrease and N. Binkert, “Atomic Coherence : LeveragingNanophotonics to Build Race-Free Cache CoherenceProtocols,” HPCA - 17 2011 The Seventeenth InternationalSymposium on High-Performance Computer Architecture, 2011,pp. 132-143.[2] M. Zhang, A.R. Lebeck, and D.J. Sorin, “Fractal Coherence:Scalably Verifiable Cache Coherence,” 2010 43rd AnnualIEEE/ACM International Symposium on Microarchitecture,Dec. 2010, pp. 471-482.[3] L.N. Bhuyan and H. Wang, “Switch MSHR : A Technique toReduce Remote Read Memory Access Time in CC-NUMAMultiprocessors,” IEEE Comput. Soc, vol. 52, 2003, pp. 1-16.[4] M.M.K. Martin, D.J. Sorin, A. Ailamaki, A.R. Alameldeen,R.M. Dickson, C.J. Mauer, K.E. Moore, M. Plakal, M.D. Hill,and D.A. Wood, “Timestamp Snooping : An Approach forExtending SMPs,” ASPLOS-IX - Architetural Support forProgramming Languages and Operating Systems, 2000, pp. 1-12.[5] N. Agarwal, L.-S. Peh, and N.K. Jha, “In-Network SnoopOrdering (INSO): Snoopy coherence on unorderedinterconnects,” 2009 IEEE 15th International Symposium onHigh Performance Computer Architecture, Feb. 2009, pp. 67-78.[6] N. Eisley, L.-S. Peh, and L. Shang, “In-Network CacheCoherence,” International Symposium on Microarchitecture,2006.[7] N.D. Enright Jerger, L.-S. Peh, and M.H. Lipasti, “Virtual treecoherence: Leveraging regions and in-network multicast treesfor scalable cache coherence,” 2008 41st IEEE/ACMInternational Symposium on Microarchitecture, Nov. 2008, pp.35-46.[8] N. Agarwal, L.-shiuan Peh, and N.K. Jha, “In-NetworkCoherence Filtering : Snoopy Coherence without Broadcasts,”Ieee Micro, 2009.[9] M.M.K. Martin, M.D. Hill, and D.A. Wood, “Token Coherence:a new framework for shared-memory multiprocessors,” IeeeMicro, vol. 23, 2003, pp. 108-116.[10] Virtutech, “Simics : A Full System Simulation Platform,” IEEE,2002.[11] M.M.K. Martin, D.J. Sorin, B.M. Beckmann, M.R. Marty, M.Xu, A.R. Alameldeen, K.E. Moore, M.D. Hill, and D.A. Wood,“Multifacet’s General Execution-driven MultiprocessorSimulator (GEMS) Toolset,” Computer Architecture News,2005.[12] V. Puente, J.A. Gregorio, and R. Beivide, “SICOSYS: AnIntegrated Framework for Studying Interconnection NetworkPerformance in Multiprocessor Systems,” IEEE Comput. Soc,2002, pp. 15-22.[13] D.L. Weaver, “The SPARC Architecture Manual,” Control,1994.[14] A.R. Alameldeen, M.M.K. Martin, C.J. Mauer, K.E. Moore, M.Xu, M.D. Hill, D. Wood, and D.J. Sorin, “Simulating a $2MCommercial Server on a $2K PC,” Computer, vol. 36, 2003, pp.50-57.[15] H. Jin, M. Frumkin, and J. Yan, “The OpenMP Implementationof NAS Parallel Benchmarks and its Performance,” NASTechnical Report NAS-99-011, NASA Ames Research Center,Moffett Field, CA, 1999.[16] C. Bienia and K. Li, “PARSEC 2 . 0 : A New Benchmark Suitefor Chip-Multiprocessors,” MoBS, 2009.JP2011-272

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Conversion between DPD and RBCD foron-line arithmetic computationSonia González, Carlos García, Julio Villalba. 1Summary— In recent years decimal arithmetic hasgained renewed interest with the ratification of theIEEE 754-2008 Floating-point Standard. It specifiesformats for Decimal Floating-point (DFP) numbersand uses Densely Packed Decimal (DPD) encoding tostore the significand of a DFP number. However, toperform decimal arithmetic operations, DPD conversionsto Binary Coded Decimal (BCD) are needed. Inorder to deal with on-line arithmetic it is necessaryto use redundant number representation which preventsthe carry propagation and allows the computationstarting from the most significant digit (MSD). Inthis paper we consider the Redundant Binary CodedDecimal (RBCD) encoding and presents the design ofa DPD converter to RBCD representation for decimalon-line arithmetic units. The direct conversionproposed in this paper (DPD to RBCD) supposes animprovement over the two steps conversion requiredby a regular computation (DPD to BCD and BCD toRBCD).Keywords— conversion, decimal floating-point, onlinearithmetic, densely packed decimal, redundantbinary coded decimal.I. IntroductionDECIMAL arithmetic is present nowadaysthanks to the ratification of the IEEE 754-2008Floating-point Standard. During last years therehave been a lot of activities in the design of specificdecimal arithmetic units. In fact, processors suchas IBM Power6, Power7, z9 and z10 [10], [5], [11]include decimal floating-point units.The standard includes two basic formats for DecimalFloating-point (DFP) numbers and specifies twoencodings for DFP significands known as the decimaland the binary encoding. The decimal encoding usesthe Densely Packed Decimal (DPD) [3] encoding toencode the significand. The main drawback of DPDencoding is that it is not easy to perform computationswith it. To resolve this problem, a DPDnumber is converted to Binary Coded Decimal representation(BCD) and the operations are carried outusing this representation. Most of the recent proposeddecimal arithmetic units based on DPD encoding[4], [14], [15], [16], [8], [9], [7] are designedassuming this conversion. On the other hand, onlinearithmetic is based on serial computation startingfrom the Most Significant Digit (MSD). To avoidthe chain of carries a redundant representation of thenumbers is used in on-line arithmetic [6]. RedundantBinary Coded Decimal (RBCD) [13] is a redundantdecimal representation where the BCD digits from 0to 9 are represented with the digit set is {-7,...,7}.In order to work with decimal on-line units twosteps are needed to convert from DPD to RBCD:1 Dept. Computer Architecture, University of Málaga, e-mail: sonia,cgarcia,julio@ac.uma.esa conversion from DPD to BCD and from BCD toRBCD. Although the DPD to BCD conversion is fastin hardware, the BCD to RBCD conversion impliesthe chain of a carry between digits. In this paper,we propose a direct conversion DPD to RBCD by thefusion of the tables and equations involved by the twosteps conversion, achieving a faster algorithm.The rest of the paper is organized as follows. SectionII describes the DFP formats specified in theIEEE 754-2008 standard. Section III deals with theRedundant Binary Coded Decimal numbers and theon–line arithmetic requirements. Section IV presentsthe direct conversion from DPD to RBCD. SectionV examines the implementation results, and finally,Section VI presents the summary and conclusions ofthis work.II. Decimal Floating-Point formatDue to the importance of DFP arithmetic, IEEEdeveloped its standard for floating-point arithmetic[1] by including specifications for DFP formats andoperations [1]. With IEEE 754-2008, the value of afinite DFP number, x, is:(−1) Sx × C x × 10 Ex−biaswhere S x is the sign bit, E x is a biased exponent,bias is a constant value that makes E x non-negative,and C x is the significand, which is also referred toas the coefficient. IEEE 754-2008 defines two basicDFP formats, decimal64 and decimal128, withencodings lengths of 64 and 128 bits, respectively.These formats are used to represent a finite subset ofreal numbers including finite numbers, signed infinitiesand two different types of Not-a-Numbers (qNaNand sNaN). In addition, the Standard specifies twoencodings for DFP significands; (1) a binary encoding,known as Binary Integer Decimal (BID), and(2) a decimal encoding, known as Densely PackedDecimal (DPD). With the BID encoding, the significandis represented using an unsigned binary integer.With the DPD encoding the significand is representedusing an unsigned decimal integer, in which threedecimal digits are encoding using ten bits [3]. Witheither encoding, the significand of a DFP number isnot normalized, which means that a single DFP numbermay have multiple representations. More detailson the DFP formats and operations are provided in[1].III. Redundant Binary Coded DecimalnumbersOn–line arithmetic defines algorithms for serialarithmetic operators that receive the inputs and ge-JP2011-273

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011nerate the output starting from the most-significantdigit (MSD first). The serial approach is advantageousbecause of the simplicity of the hardware andthe reduction in number and length of connectionsamong modules. Moreover, the MSD first alternativeallows the implementation of operations, such asdivision and square root, which are difficult to implementleast-significant digit first. The drawback ofthe serial approach is the number of cycles required;however, this can be compensated by the overlap ofthe execution of dependent operations. Thanks toall these characteristics, on-line arithmetic is suitablefor VLSI implementation.vwxstp·q·r (abcd) C out0---- 0100-- 0 a=0 0101-- 0 (bcd) = (pqr) + C in011110 00---- 1100-- 1 a = 1, b = 1 1101-- 1 c = C in0 , d = C in011110 1110-- -11000 - a = r · C in0 , b = r · C in0 111101 - c = r · C in0 , d = r ⊕ C in011111 -TABLE IObtaining (abcd)Xvwxst p·q·u s·t·u (efgh) C out0---- - 0e = 0100-- - 0 (fgh) = (stu) + Cin1110-- - 0011101 0 -e = 0(fgh) = (pqu) + C in100---- - 1100-- - 1 e = 1, f = 1110-- - 1 g = C in1 , h = C in1111101 1 -101-- - - e = u · C in111100 - - f = u · C in111110 - - g = u · C in1111111 - - h = u ⊕ C in1VVxvTABLE IIObtaining (efgh)vstu11Cin140 0 Cin1 s t umux+0+4pqumuxmux1 1Cin1u Cin140 0 Cin1 p q umux+0+uCin1TWWTVVVSXFig. 1.pqr1 1 Cin0Cout140 0 Cin0 p q rmux+0muxabcd+r Cin0Implementation obtaining abcdrCin0To deal with on-line arithmetic it is necessary tohave a number representation system with no carrypropagation. In this way, it is possible to performthe computation starting from the Most SignificantDigit (MSD). This is achieved by carry-save or signeddigit representations.Therefore, to deal with decimal on-line arithmetica decimal redundant number systems is required.The BCD code involved in the DPD format does notfulfill this condition. Thus, a conversion step fromBCD to a redundant decimal system is needed. Acode that meets the required condition and which isSVFig. 2.Cout2efghImplementation obtaining efghdirectly related to BCD code is the Redundant BinaryCoded Decimal (RBCD) defined in [2].A RBCD number is composed by digits of 4bits which represent 15 numbers in the range{−7, −6, ...0...6, 7}. It is a signed digit representationsuch as a positive number is coded as naturalbinary whereas a negative number is coded as two‘scomplement. This code allows the computation withno carry propagation for the decimal addition [2],substraction, multiplication and division [12].The conversion between BCD and RBCD can beperformed with no carry propagation whereas theopposite conversion involves a borrow propagation.Fortunately for the on–line arithmetic computation,the most critical conversion is BCD to RBCD sincethe MSD is required as soon as possible. DPD codeis only used for storage purposes and the conversionfrom RBCD to DPD is performed only when the on–line processing has finished.The conversion from BCD to RBCD is performedby a two steps algorithm [2]. In the first step wedetect if a number is greater or equal to 7 and weJP2011-274

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011vwxst w·x·y s·t·y p·q·y (ijkm) C out0---- 0 - -i = 0(jkm) = (wxy) + C in20101-- - 0 -i = 0(jkm) = (sty) + C in20110-- - - 0 i = 011100 - - 0 (jkm) = (pqy) + C in200---- 1 - -101-- - 1 - i = 1, j = 1 1110-- - - 1 k = C in2 , m = C in211100 - - 1100-- - - - i = y · C in211101 - - - j = y · C in2 111110 - - - k = y · C in211111 - - - m = y ⊕ C in2SWXTVVXVwxyST11WVXFig. 3.Cin24muxvTABLE IIIObtaining (ijkm)0 0 Cin2 w x y0 0 Cin2+1 1 Cin20 0VW+stymux4muxCout3+4muxs t y+muxijkmpqyy Cin2Implementation obtaining ijkm11Cin24yCin20 0 Cin2add the amount of 6 in such a case. This provokesan output carry. In the second step we add the inputcarry to the result of the previous operation.Let (abcd) a generic BCD digit of a BCD-codednumber, and C in and C out the input and outputcarries respectively. The condition for a carrygeneration is c out = a‖(b · c · d) (see [2]), where thesymbol ‖ means the logic OR operation and · is thelogical AND (notice that the carry only depends onthe current digit bits). Thus, the conversion is:Cin0abcdCout1Fig. 4.Cin1efghCout2Cin2ijkmGlobal structure of the conversionmux+0Cout3p q y+First step:c out = a‖(b · c · d) (1){ (abcd) if cout = 0(abcd) =(2)(abcd) + (0110) if c out = 1Second step:(abcd) = (abcd) + c in (3)IV. Direct conversion from DPD to RBCDLet (pqrstuvwxy) the ten bits corresponding to aDPD code. This code is converted to three BCDdigits (abcd)(efgh)(ijkm), in such a way that eachbit of the three BCD digits is obtained as a booleanfunction of the DPD bits. In [1] a table conversion isprovided. On the other hand, conversion from BCDto RBCD is performed by implementation of equations(1) through (3). What we propose is the combinationof the table and the equations to provide adirect table conversion, which is presented in tablesI, II and III. The resulting BCD code is composed bythree digits namely (abcd)(efgh)(ijkm) and they aredirectly obtained from the DPD code (pqrstuvwxy).In the tables the symbol · means the logical ANDoperation, the symbol ⊕ corresponds to the logicalEXOR operation and the symbol + is the arithmeticaddition.From these tables we can see that only logical operationsare required as well as, for some cases, onelevel of 3-bit arithmetic addition to add the inputcarry (for example, in table I for the first case, thebits (bcd) are obtained by the addition of the bits(pqr) and a carry, whereas the bit a=0. Notice thatthe maximum value of (bcd) is 6 and thus the additionof a carry never provokes an output carry). Nevertheless,the BCD to RBCD conversion proposedin [2] involves two additions.The implementation of the direct conversion isshown in Fig. 1,Fig. 2 and Fig. 3 which are relatedto Tables I, II and III respectively. The implementationof Table I requires the use of only twomultiplexers and one 3-bit adder, while the implementationof Table II uses four multiplexers and two3-bit parallel adders, and the implementation of TableIII uses six multiplexers and three 3-bit paralleladders.Fig. 4 shows the global structure of the full conversion.The C in0 is the carry input coming fromthe previous conversion, and the C out3 is the carryoutput produced by the current conversion.V. Experimental resultsThe DPD to RBCD design presented in this paperhave been implemented in Verilog, simulated usingModelSim 6.0, and synthesized using Synopsys DesignCompiler and the TSMC 65nm library in whichone cell unit has an area equal to 1 µm 2 . Also,we have implemented the conversion using two steps(conversion from DPD to BCD [1] plus conversionfrom BCD to RBCD [2]). Table IV shows the implementationresults. Our approach is close to 27%JP2011-275

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011faster than the two steps algorithm. Nevertheless,our design requires about 58% more area than thetwo step processing.The improvement in the time of our algorithm isdue to the fact that we use only one 3-bit paralleladdition operation in comparison with the two serial4-bit additions required by the standard conversion.Notice that the table conversion from DPD to BCDinvolves only logical operations, in such a way thataddition has a high influence in the total computationtime.DPD to RBCDTime AreaTwo steps 0.0744 913Our design 0.0546 1449TABLE IVImplementation resultsVmx and dfu. IBM Journal of Research and Development,51:1–21, November 200u.[11] E. M. Schwarz, J. S. Kapernick, and M. F. Cowlishaw.Decimal floating-point support on the ibm system z10processor. IBM Journal of Research and Development,53(1):4:1 –4:10, 2009.[12] S.Gorgin and G. Jaberipur. Fully redundant decimalarithmetic. In Proc. of 19th IEEE Symposium on ComputerArithmetic (ARITH 2009). IEEE Computer SocietyPress, 2009.[13] B. Shirazi, D.Y.Y. Yun, and C.N. Zhang. Rbcd: redundantbinary coded decimal adder. Computers and DigitalTechniques, IEE Proceedings E, 136(2):156 – 160, March1989.[14] L.-K. Wang and M. J. Schulte. Decimal floating-pointsquare root using Newton-Raphson iteration. In Proceedingsof IEEE International Conference on Application-Specific System, Architectures and Processors, pages309–315, July 2005.[15] L.-K. Wang and M. J. Schulte. Decimal floating-pointadder and multifunction unit with injection-based rounding.In Proceedings of the 18th IEEE Symposium onComputer Arithmetic, Montpellier, France, June 2007.[16] L.-K. Wang and M. J. Schulte. A decimal floating-pointdivider using Newton-Raphson iteration. The Journal ofVLSI Signal Processing, pages 727–739, 2007.VI. Summary and ConclusionIn this paper we have presented a direct conversionbetween DPD and RBCD which makes the computationin an on–line arithmetic system possible. Theproposed system obtains directly the RBCD digitsfrom a DPD data stream starting from the MSD.The fusion of the two steps into one reduces significativelythe computation time of the conversion with amoderate increase of hardware.The fast conversion proposed in this paper canbenefit to all the potential decimal on–line arithmeticalgorithms if these algorithms involve IEEE 754-2008decimal floating point numbers.References[1] American National Standards Institute and Institute ofElectrical and Electronic Engineers. 754-2008 IEEE standardfor floating-point arithmetic,. IEEE Standard, Std754-2008, 2008.[2] D.Y.Y. Yun B. Shirazi and C.N. Zhang. RBCD: redundantbinary coded decimal adder. IEE Proceedings Computerand Digital Techniques, 136:156–160, March 1989.[3] M. F. Cowlishaw. Densely packed decimal encoding. InIEE Proceedings - Computers and Digital Techniques,volume 149, pages 102–104, May 2002.[4] M. F. Cowlishaw. Decimal floating-point: Algorism forcomputers. In Proceedings of the 16th IEEE Symposiumon Computer Arithmetic, pages 104–111, June 2003.[5] A. Y. Duale, M. H. Decker, H.-G. Zipperer, M. Aharoni,and T. J. Bohizic. Decimal floating-point in z9: An implementationand testing perspective. IBM Journal ofResearch and Development, 51(1/2), 2007.[6] M.D. Ercegovac and T. Lang. Digital Arithmetic. MorganKaufmann, 2004.[7] Steven R. Carlough Eric M. Schwarz. Power6 decimaldivide. In Proceedings of the 18th IEEE Symposium onApplication-specific Systems, Architectures and Processors,2007.[8] M. A. Erle, M. J. Schulte, and B. J. Hickmann. Decimalfloating-point multiplication via carry-save addition. InProceedings of the 18th IEEE Symposium on ComputerArithmetic, 2007.[9] B. Hickmann, A. Krioukov, M. A. Erle, and M. Schulte.A parallel ieee p754 decimal floating-point multiplier. InInternational Conference on Computer Designs, pages296–303, October 2007.[10] J. Leenstra, S. M. Mueller, C. Jacobi, J. Preiss, E. M.Schwarz, and S. R. Carlough. Ibm power6 accelerators:JP2011-276

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Multiples Puertos de Inyección en una Red enChipJesús Camacho, José Flich y José Duato 1Resumen—Presentamos una nueva topología de red en chipflexible: la NR-Mesh (Nearest neighboR Mesh). Estatopología puede inyectar y recibir mensajes a travésde varios puertos mediante diferentes conmutadores,con lo que puede reducirse el número de saltos, asícomo el tiempo de apagado de componentes inutilizadosen la red con el ahorro de consumo que ello conlleva.Además otros beneficios que ofrece la toplogíason: reducción de la congestión, soporte eficiente paracomunicación colectiva o tolerancia a fallos.Así mismo proponemos una técnica para ahorrarconsumo mediante un algoritmo de encaminamientoadaptativo, apagando puertos y enlaces inutilizados.Usando la topología NR-Mesh con encaminamientoadaptativo (comparado con la topología 2D-Mesh conencaminamiento determinista) se obtiene una mediade un 7% de reducción en tiempo de ejecución y unamedia de un 75% de reducción en energía consumidapara una red con 16 nodos. Resultados similares sehan obtenido para 32 nodos.Palabras clave— Redes en chip, Topologías, Consumo,Inyección de mensajes, Tolerancia a fallos.I. IntroducciónLos chip multiprocesador de hoy día optan habitualmentepor la conexión entre sus diferentes nodosmediante una malla 2D. Cada nodo se conectaa sus vecinos en las direcciones norte, este, oestey sur. Este diseño es fácil de implementar pues sepuede obtener simplemente replicando cada tile enuna superficie plana. El problema aparece cuando eltamaño de los sistemas aumenta y por tanto la distanciaentre nodos distantes se incrementa notablementeen la malla 2D.En una malla 2D, el algoritmo de encaminamientomás eficiente (teniendo en cuenta la complejidad yel consumo) es DOR (Dimension Order Routing).DOR se utiliza en cada conmutador y no requiereuna lógica excesiva. Los mensajes primero se muevenen una dirección y después en la otra. Por ejemplo,primero X y luego Y, siempre siguiendo ruta mínima.La reducida complejidad de este algoritmo hace queesté muy extendido entre los diseñadores de redes enchip. El problema del mismo reside en la poca flexibilidadque posee, ya que no es capaz de tolerarningún fallo al ofrecer una única ruta entre cada parde nodos, no siendo capaz tampoco de aliviar unasituación de congestión.Una alternativa a DOR es el uso de encaminamientoadaptativo, es decir, los diferentes conmutadorespueden elegir diferentes puertos de salida dependiendodel estado de los mismos (ocupados o no).De esta forma es posible aliviar la congestión local.Normalmente se soportan también rutas mínimas1 Grupo de Arquitecturas Paralelas, Universitat Politècnicade València, e-mail: {jecavil,jflich,jduato}@gap.upv.es.para el encaminamiento adaptativo, haciendo quecada mensaje esté cada vez más cerca de su destino.Sin embargo ahora, la dimensión por la que se muevecada mensaje puede cambiar más de una vez. Paraevitar ciclos es necesario proveer a la red de un canalvirtual adicional que llamamos vía de escape [5].En este artículo proponemos una topología flexiblellamada NR-Mesh (Nearest neighboR Mesh).Dicha topología permite utilizar varias rutas alternativaspara enviar cada mensaje utilizando DOR.La topología NR-Mesh es capaz de enviar y recibirmensajes a través de 4 conmutadores distintos graciasa un interfaz de red modificado que se estudiadetalladamente más adelante. Además, la topologíaNR-Mesh posee un menor diámetro que la malla 2Dy proporciona además un soporte eficiente para la comunicacióncolectiva (debido a que un mismo mensajepuede ser recibido por 4 nodos distintos desdeun mismo conmutador) y para la tolerancia a fallos(debido a que el interfaz de red es capaz de inyectarmensajes a través de diferentes puertos hacia distintosconmutadores).La segunda propuesta que realizamos es la implementaciónde un algoritmo capaz de gestionarel encendido y apagado de puertos y enlaces en lared cuando no es necesario utilizarlos. El algoritmoen cuestión maximiza el tiempo en que los componentesse mantienen apagados para poder ahorrarel máximo consumo posible sin perder prestaciones.Para ello, se utiliza encaminamiento adaptativo ayudadopor la función de selección del interfaz de red.El resto del artículo se organiza de la siguienteforma. En la sección II, se describe el estado del arte.Después, en la sección III, se describe la topologíaNR-Mesh. La sección IV describe el algoritmo parala gestión del consumo. A continuación, en la secciónV, se evalua la nueva topología y los algoritmos descritosanteriormente. Finalmente, en la sección VI seconcluye el artículo.II. Estado del ArteDiferentes topologías han sido propuestas durantelos últimos años. Inicialmente, los diseños y propuestasmás extendidas eran los anillos [15] y las mallas2D [20], [18], [19]. Los esfuerzos por reducir elnúmero de saltos entre fuente y destino se centraronen las mallas concentradas [2] y las redes ’flattenedbutterfly’ [10]. Otros trabajos [6] también han conseguidoreducir el número de saltos mediante ’expresschannels’ [4]. Un análisis completo de variastopologías se muestra en [6].Power gating (’gated-Vdd’) es una conocidatécnica para reducir el consumo estático. En [16] seJP2011-277

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011propone una técnica para desconectar el suministrode componentes (’transistor gating’). Power gatingse puede aplicar a diferentes niveles, desde unidadesde ejecución completas [8] hasta celdas de memoriaSRAM [3]. Para las redes en chip, existen diferentestrabajos que aplican estas técnicas. En [3], powergating se utiliza para apagar los ’buffers’ mediantediferentes políticas. En [13, 14], power gating se utilizaa nivel de canales virtuales. En [17] se utilizapara el apagado de enlaces. En [7], se reduce el consumoestático utilizando el concepto de encendidoy apagado de enlaces [17] con ’power-aware’ en losbuffers [3, 13, 14]. El algoritmo de gestión de consumoen este artículo usa este último concepto. Lasdiferentes propuestas descritas anteriormente cuentannormalmente con la malla 2D, aunque puedenaplicarse potencialmente a la topología NR-Mesh.III. NR-MeshLa Figura 1 muestra en su parte derecha el patrónde conexión entre los nodos finales y los conmutadoresde la topología NR-Mesh. La red utiliza 4 enlacespara conectar cada nodo con 4 conmutadoresdistintos, siempre que sea posible. Esto ofrece mayorconectividad si realizamos una comparación con lamalla 2D debido al mayor número de enlaces internospor los cuáles pueden inyectarse y recibirse mensajesa través de hasta 4 conmutadores distintos. Cabedestacar que los mensajes en tránsito nunca cruzaránlos nodos finales.Cada nodo final incluye un procesador, una cachéde primer nivel y un bloque de caché de segundonivel. Cómo el nodo final está conectado a cuatroconmutadores diferentes, se necesita una lógica adicionalen el interfaz de red para decidir que puertode salida se va a utilizar. Dicha lógica ha sido implementaday testada (ver sección III-B) obteniendolatencias despreciables excepto para los enlaces internosen la NR-Mesh, dónde se requiere un enlacemás largo. Esta lógica se implementa en el nodo final(ver Figura 1). Más adelante, describiremos elalgoritmo de selección que utiliza el interfaz de red.Una propiedad a destacar de la NR-Mesh es su reducidodiámetro. En concreto se reduce un salto pordimensión al utilizar una ruta mínima comparadocon una malla 2D. Esta propiedad permite reducir lalatencia media de los mensajes, así como el tiempode ejecución en aplicaciones reales y el consumo.A. Diseño T ileLa NR-Mesh puede adaptarse fácilmente a undiseño tile, cómo puede observarse en la Figura 1.El conmutador se coloca en la parte inferior derechadel tile y se conecta a 4 nodos distintos, cada unode ellos en un tile diferente. Cada nodo final incluyeuna función de selección. La figura muestra laconexión de los enlaces internos y externos. Cómo sepuede apreciar los enlaces externos se conectan de lamisma forma que en una malla 2D.El diseño seguido contiene el mismo número de nodosy conmutadores que una malla 2D. También, talFig. 1.Diseño tile para la topología NR-Mesh.y como muestra la figura no todos los nodos puedenconectarse a 4 conmutadores, ésto depende de suubicación en la malla. Además, cabe destacar quese podría prescindir de la última fila y columna deconmutadores en la NR-Mesh. Sin embargo, estosconmutadores proporcionan flexibilidad a la hora deencaminar mensajes dentro de la red, aunque estaránapagados la mayor parte del tiempo en condicionesde poco tráfico.B. Algoritmo de InyecciónEl algoritmo de inyección es un componente clavede la topología. Un mensaje puede ser inyectado ala red a través de hasta 4 puertos diferentes. Cabedestacar que no siempre los mensajes inyectados ala red seguirán una ruta mínima. Ésto dependeráde la disponibilidad de cada puerto, aunque siempreserán prioritarios los puertos de ruta mínima. Éstoproporciona una gran flexibilidad a la red.El algoritmo primero crea un conjunto de puertoscon rutas mínimas, y después otro conjunto conrutas no mínimas. Puede ocurrir que todos los puertosestén ocupados, en dicho caso esperaremos al siguienteciclo. En caso contrario el puerto escogidoserá el que inyecte el mensaje a la red hacia el conmutadormás cercano al destino final entre los puertosdisponibles.La Figura 2.(a) muestra 2 ejemplos. En S1, paralos mensajes que van hacia D1, 2 puertos son incluidosen el conjunto de puertos con ruta mínimay 2 en el conjunto de puertos con ruta no mínima,respectivamente. En cambio, para los mensajes quevan desde S2 a D2, sólo un puerto es incluido en elconjunto de puertos con ruta mínima y el resto en elconjunto de puertos con ruta no mínima. Si ningúnpuerto estuviese disponible, se esperaría al siguienteciclo y así sucesivamente hasta encontrar al menosun puerto libre.Una vez uno de los conjuntos mencionados contieneal menos un puerto libre, el algoritmo de seleccióndecide, según lo explicado anteriormente,cual es el mejor enlace para inyectar el mensaje encuestión. Si hay más de una ruta para escoger conel mismo número de saltos, se selecciona uno de lospuertos aleatoriamente. Hay que destacar que la inyecciónde mensajes a la red puede realizarse desde elmismo nodo durante el mismo ciclo a través de 4 conmutadoresdiferentes, siempre que la red lo requieray todos los puertos de inyección estén disponibles.JP2011-278

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Puertos de inyección (b) Ruta no mínimaFig. 2. Diferentes características de la topología NR-Mesh.function encaminamiento deteminista(puerto ent, conm actual,conm dest) : puertovar p: puertovar cp: conjunto de puertosbeginp = puerto minimo xy(conm actual, conm dest)if (libre[p]) return pif (puerto ent==W & y(conm dest)y(conm actual) &x(conm dest)==x(conm actual)+1) cp+=ESif (puerto ent==E & y(conm dest)y(conm actual) &x(conm dest)==x(conm actual)-1) cp+=WSif (puerto ent==S & conm dest en N) cp+=Nif (puerto ent==N & conm dest en S) cp+=Sreturn selecciona libre prioritario(cp)end functionComponente Consumo Cámino crítico Área (µm 2 )Inyección 2.5 µW 0.21 ns 57.40Conm. 3P 34.63 mW 1.00 36,417.96Conm. 4P 49.57 mW 1.00 49,954.71Conm. 5P 63.11 mW 1.00 64,354.10Conm. 6P 76.42 mW 1.00 71,827.22Conm. 7P 88.37 mW 1.00 95,188.55Conm. 8P 102.13 mW 1.00 ns 111,724.72TABLA IResultados de consumo y latencias para el interfaz dered y conmutadores de distinto número de puertos (P).Fig. 3. Algoritmo de encaminamiento determinista para latopología NR-Mesh.function encaminamiento adaptativo(puerto ent, conm actual,conm dest) : puerto, canal virtualvar cp: conjunto de puertosbegincp = puertos disponibles ruta minima(conm actual,conm dest)if (vacio(cp)) return encaminamiento determinista(puerto ent,conm actual, conm dest), canal virtual deterministaelse return aleatorio(cp), canal virtual adaptativoend functionC. Resultados de ImplementaciónFig. 4. Algoritmo de encaminamiento adaptativo para latopología NR-Mesh.El interfaz de red así como un conmutador de 5etapas ha sido diseñado y sintetizado con la libreríade código abierto 45nm Nangate en Verilog. Conmutadorescon diferente número de puertos se handiseñado también, todos ellos a la frecuencia de 1GHz. El consumo total se ha obtenido usando laherramienta P owerCompiler de Synopsys despuésde utilizar la herramienta Place&Route de Cadence.Los resultados para el interfaz de red y conmutadoresdesde 3 a 8 puertos (NR-Mesh) están reflejados en laTabla I. El consumo dinámico también se ha medidopara diferentes cargas, sin embargo los resultadosno varian significativamente puesto que el consumoestático es el principal componente. Los resultadosobtenidos han sido comparados con el modelode consumo Orion-2 [9].Como puede apreciarse, el área y el consumo adicionalen el interfaz de red debido al algoritmo deinyección es despreciable. Además el consumo paraun conmutador de 8 puertos (NR-Mesh) es casi eldoble que para uno de 5 (malla 2D) debido principalmenteal número de buffers. Aun así, este consumose aplica cuando el conmutador está totalmente encendido.De este modo, la nueva topología NR-Meshcombinada con un algoritmo adaptativo, será capazde apagar puertos y enlaces disminuyendo el consumoactual. También cabe decir que la latencia delos mensajes al ser inyectados está muy por debajo delos límites impuestos por los del conmutador, lo quequiere decir que el algoritmo de inyección no representaun cuello de botella a lo largo de la ruta críticadel mensaje inyectado.D. Algoritmo de EncaminamientoEl algoritmo de encaminamiento determinista(Figura 3) con soporte para rutas no mínimas sedescribe a continuación. El algoritmo se ejecutaen cada conmutador para cada mensaje entranteteniendo en cuenta de donde proviene el mensaje,donde está y hacia donde va. Se prioriza la rutamínima, pero si esta está ocupada y un salto extraes posible (debido a que el mensaje puede serrecibido a través de hasta 4 conmutadores distintosen cada nodo final) y el enlace está libre se tomauna ruta no mínima (ver figura 2.(b)). Nótese queaunque varias rutas pueden ser utilizadas como semuestra en dicha figura el encaminamiento utilizadosigue siendo DOR, por lo tanto no es posible que selleven ciclos a cabo. Si ninguno de los puertos posiblesestá libre, entonces la función de selección depuerto de salida se volverá a ejecutar en el siguienteciclo.La topología NR-Mesh también puede utilizar encaminamientoadaptativo (Figura 4). En este caso,al menos 2 canales virtuales son necesarios para desacoplarrutas adaptativas y vias de escape. En nuestrocaso utilizamos un canal virtual para cada caso.El algoritmo primero intenta utilizar el canal adaptativo.Si los posibles puertos que llevan a estoscanales están ocupados, entonces se pasará a encaminamientodeterminista mediante la vía de escape. Enel siguiente salto se puede volver a utilizar encaminamientoadaptativo (asumimos conmutación virtualcut-trough).JP2011-279

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) tolerancia a fallos (b) comunicacióncolectivaFig. 5. Propiedades adicionales en la topología NR-Mesh.E. Propiedades de la Topología NR-MeshLa primera propiedad y más importante es la flexibilidadal inyectar y recibir mensajes hacia / desdediferentes conmutadores basado en el algoritmo deinyección implementado. Esta propiedad será degran utilidad cuando gestionemos el consumo paraapagar componentes inutilizados, sobretodo al utilizarencaminamiento adaptativo. Además, la congestióndentro de la red desaparecerá en gran medida.Otra propiedad es la reducción del diámetro, dehasta un salto por coordenada. Ésto conlleva unamenor latencia y el consiguiente ahorro de consumo.Además, la topología NR-Mesh soporta un altogrado de tolerancia a fallos debido al algoritmo deinyección y el algoritmo de encaminamiento (Figura5.(a)). También soporta la comunicación colectivade una forma muy eficiente gracias a que un mensajepuede ser entregado desde el mismo conmutador hacia4 destinos distintos (figura 5.(b)).IV. Algoritmo de gestión del consumoEl algoritmo de encaminamiento se modificarápara evitar, en la medida de lo posible, los puertosque estén apagados. El algoritmo de gestión delconsumo se puede dividir en tres partes diferenciadas.La primera es decidir cuando un puerto debeapagarse. La segunda es evitar en la medida de loposible los puertos apagados. Por último, queda decidircuando deben encenderse los puertos y enlacesque se encuentran apagados.A. Algoritmo para Apagar un PuertoCada conmutador en la red incluirá una nuevalógica de control (ver Figura 6) que llamaremos PML(’Power Management Logic’), la cual estará a cargode encender y apagar puertos en los conmutadores.Para apagar un puerto se tiene en cuenta el tráficoentrante en el mismo. El PML mide la utilizaciónde cada puerto, calculada como el número de ciclosdurante el cuál no se utiliza. Cuando se llega a ciertoumbral, dicho puerto deberá ser apagado.Para ello, una señal de control se enviará al puertoasociado para notificar al PML que el puerto ha deser apagado mediante ’power gating’. Si todos lospuertos de un conmutador están apagados entoncesFig. 6. Lógica utilizada para el algoritmo de gestión del consumo(PML).la lógica apagará completamente el conmutador, incluyendoel reloj mediante ’clock gating’.El proceso de apagar un puerto tiene un consumoque es compensado por el número de ciclos en que elconmutador está apagado. Sin embargo, para ahorrarconsumo es necesario que el puerto esté apagadoal menos durante 10 ciclos, aunque no existeninguna penalización en el consumo por despertarloantes. Para más detalles ver [8].B. Algoritmo para Encaminar MensajesEl algoritmo de encaminamiento descrito en lasección III-D se modifica en este caso para evitar,siempre cuando sea posible, los componentes apagadosen la red. Para ello, dos cambios son necesarios:el primero es qué el algoritmo ha de saber que puertosen el conmutador están activos y cuáles no (yasea porqué se esté transmitiendo un mensaje o sencillamenteporqué están apagados). El PML mantieneal arbitro actualizado en cada momento.El segundo requerimiento considera el volver a encenderun puerto. Si el algoritmo no encuentra unpuerto disponible, entonces una ruta determinista esnecesaria y el PML notificará mediante la señal ’IPon signal’ al siguiente conmutador que ha de encenderel puerto de entrada correspondiente. Una vezéste haya sido encendido, el mensaje será trasmitidopor la vía de escape.C. Algoritmo para Encender un PuertoEl PML enciende los puertos de entrada cuando lellega la señal ’IP on signal’ del conmutador previo.Hay una pequeña penalización de 1 ciclo al encenderlos enlaces en el conmutador previo, puesto que senecesitan 3 ciclos para ello y no se puede enviar unaseñal al enlace antes de la etapa routing.V. EvaluaciónEn esta sección evaluamos la nueva topología NR-Mesh comparándola con la malla 2D usando encaminamientodeterminista y adaptativo para ambastopologías. La evaluación se realiza en términosde tiempo de ejecución y energía consumida. Esteúltimo parámetro corresponde al consumo empleadodurante todo el tiempo de ejecución de una aplicación.Hay que destacar que el uso del PML seutiliza únicamente con encaminamiento adaptativopara ambas topologías.JP2011-280

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Los umbrales para apagar un puerto son 100 y 200ciclos para 16 y 32 nodos respectivamente. Diferentesumbrales se han estudiado y se han elegido losindicados anteriormente ya que ofrecen una buenarelación entre prestaciones y ahorro de energía.A. Herramienta de SimulaciónLas herramientas de simulación empleadas sonSIMICS [12] y GEMS [11], las cuáles son capaces demodelar un sistema completo. Sin embargo, hemosreemplazado el simulador de red de GEMS por elsimulador gNoCsim, un simulador propio, dónde elconmutador y el interfaz de red han sido diseñadosen Verilog. En la tabla II se muestran los principalesparámetros de simulación. Varias aplicacionesSplash-2 [21] y cargas de trabajo [1] han sido evaluadas.Parámetro Valor Parámetro ValorTamaño L1 128 KB privada Latencia L1 3 ciclosTamaño L2 8MB compartida Latencia L2 6 ciclosProtocolo Directorio Redes virtuales 5Procesadores 16 y 32Parámetros de redConmutadoresTamaño flit 8 bytes Tamaño buffer 10 flitsEnlaces exts 1 ciclo VCs 2Enlaces ints 1 ciclo (2D) Etapas 5Enlaces ints 2 ciclos (NR) Duración etapa 1 cicloTABLA IIParámetros de simulación.En las siguientes subsecciones se analiza el tráficoaceptado y el consumo en régimen de tráficosintético, así como el tiempo de ejecución (en ciclos)y la energía consumida en GEMS, respectivamente.B. Tráfico SintéticoLa Figura 7 muestra las prestaciones (a) y consumo(b) para un sistema de 16 nodos (4 × 4) simuladocon tráfico sintético uniforme.En primer lugar se puede observar en (a) la grancantidad de tráfico aceptada por la topología NR-Mesh en altas cargas. Ésto es debido a que poseeuna bisección mayor y un diámetro menor. Además,en el encaminamiento determinista el tráfico aceptadoes mayor debido a que no hay penalización porencender componentes ni uso de rutas no mínimas,aunque, el objetivo principal de la NR-Mesh es reducirel consumo. En (b) puede observarse comola NR-Mesh consigue un consumo mucho menor ensu versión adaptativa, también superando a la malla2D, excepto para cargas de tráfico muy altas al bordede la saturación.Viendo los resultados de ambos gráficos quedaclaro pues que la mejor combinación es la NR-Meshcon encaminamiento adaptativo, puesto que consiguebuenas prestaciones a bajo consumo.Para 32 (4 × 8) nodos (no mostrado por razonesde espacio), el comportamiento es similar, aunquela NR-Mesh consume algo más sobretodo en el casodeterminista. No es así para el caso adaptativo, queconsigue beneficios similares al sistema de 16 nodos.Fig. 7.(a) tráfico aceptado (flits/ciclo/tile)(b) consumo por flit (W)Comparación con tráfico sintético para 16 nodos.C. Tiempo de Ejecución en GEMSLa Figura 8.(a) muestra el tiempo de ejecuciónpara sistemas de 16 y 32 nodos, respectivamente,para cada topología y algoritmo de encaminamiento.Los resultados se han normalizado al caso deterministapara la malla 2D en cada aplicación. Los resultadosson similares para ambos sistemas (16 y 32nodos).El tiempo de ejecución para el encaminamientoadaptativo aumenta ligeramente debido al uso derutas no mínimas y a la penalización introducidacuando se toma la vía de escape. Sin embargo, esteaumento en el tiempo de ejecución está claramentecompensado por el bajo consumo alcanzado, tal ycomo observaremos en la siguiente subsección.Fijándonos en la NR-Mesh, se pueden apreciargrandes reducciones en el tiempo de ejecución comparándolocon la malla 2D para ambos algoritmosde encaminamiento (determinista y adaptativo).Por ejemplo, Raytrace consigue una reducción en eltiempo de ejecución de hasta un 12%. Además, independientementedel algoritmo utilizado, la topologíaNR-Mesh consigue un tiempo de ejecución menor alde la malla 2D.D. Energía Consumida en GEMSLa Figura 8.(b) compara la energía consumida.Los resultados de nuevo se muestran normalizadosal caso de la malla 2D para cada aplicación.Si comparamos la topología NR-Mesh utilizando elalgoritmo adaptativo propuesto contra la tradicionalmalla 2D utilizando DOR, el ahorro de energía llegahasta un 75% de media para 16 nodos y hasta un69% para un sistema de 32 nodos.JP2011-281

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Tiempo de ejecución(b) Energía consumidaFig. 8. Tiempo de ejecución y energía consumida en aplicaciones reales. Resultados normalizados para la malla 2D determinista.VI. ConclusionesEn este artículo presentamos la topología NR-Mesh, dónde cada nodo se conecta a 4 conmutadoresdiferentes, consiguiendo grandes beneficios enel ahorro de consumo. Además, la latencia media sereduce así como la contención. Otros beneficios sonla tolerancia fallos, además de un soporte eficientepara la comunicación colectiva. Los beneficios de laNR-Mesh explorados en este artículo son la gran flexibilidadque otorga la red para inyectar y extraermensajes habilitando para ello algoritmos de gestióndel consumo.La nueva topología rinde al máximo cuando el encaminamientoadaptativo se combina con el mecanismode power gating, que se utiliza para habilitar/ deshabilitar componentes. Debido a la baja utilizaciónde la red y la flexibilidad de la topología NR,la energía consumida y la reducción en el tiempo deejecucción es de un 75% y un 7% respectivamentepara un sistema de 16 nodos, comparado con unamalla 2D sin gestión del consumo (encaminamientodeterminista sin apagado de componentes). Resultadossimilares se han obtenido para 32 nodos.Como trabajo futuro queremos evaluar nuevastopologías siguiendo la filosofía de inyección múltipleen el interfaz de red.AgradecimientosEste trabajo ha sido financiado por el Ministeriode Educación, el Ministerio de Ciencia e Innovación,y con fondos FEDER de la Comisión Europea, conel proyecto TIN2009-14475-C04-01.Referencias[1] Alameldeen, Alaa R. et al. ”Evaluating Non-deterministicMulti-threaded Commercial Workloads,” in Workshopon Computer Architecture Evaluation Using CommercialWorkloads.[2] J.D. Balfour and W. J. Dally, ”Design Tradeoffs for TiledCMP On-Chip Networks,” in International Conference onSupercomputing, June 2006.[3] X. Chen and L.-S. Peh, ”Leakage Power Modeling and Optimizationin Interconnection Networks,” in InternationalSymposium on Low Power Electronics and Design, pages90-95, August 2003.[4] W. J. Dally, ”Express Cubes: Improving the Performanceof k-ary n-cube Interconnection Networks,” in IEEETransactions on Computers, 40(9):1016-1023, September1991.[5] J. Duato, ”A New Theory of Deadlock-Free AdaptiveRouting in Wormhole Networks,” in IEEE Transactionson Parallel and Distributed Systems, 1993.[6] B. Grot, et. al, ”Express Cube Topologies for On-ChipInterconnects,” in International Symposium on High-Performance Computer Architecture, 2009.[7] K. C. Hale, B. Grot, S. W. Keckler, ”Segment Gatingfor Static Energy Reduction in Networks-on-Chip,” in InternationalWorkshop on Network-on-Chip Architectures,December 2009.[8] Z. Hu at al, ”Microarchitectural Techniques for PowerGating of Execution Units,” in International Symposiumon Low Power Electronics and Design, pages 32-37, August2004.[9] Andrew Kahng, et al, ”ORION 2.0: A Fast and AccurateNoC Power and Area Model for Early-Stage Design SpaceExploration,” in Design Automation and Test in Europe(DATE), Nice, France, April 2009.[10] J. Kim et al, ”Flattened Butterfly Topology for On-chipnetworks,” in International Symposium on Microarchitecture,December 2007.[11] M. Martin et al, ”Multifacet, a general execution-drivenmultiprocessor simulator (GEMS) toolset,” in ComputerArchitecture News, September 2005.[12] Peter S. Magnusson et al., ”Simics: A full system simulationplatform,” in Computer, 35(2):50-58, 2002.[13] H. Matsutani et al, ”Run-time Power Gating of On-ChipRouters Using Look-Ahead Routing.,” in Asia and SouthPacific Design Automation Conference, pages 55-60, January2008.[14] H. Matsutani et al., ”Adding Slow-Silent Virtual Channelsfor Low-Power On-Chip Networks,” in InternationalSymposium on Networks-on-Chip, pages 23-32, April2008.[15] D. Pham et al., ”Overview of the Architecture, CircuitDesign, and Physical Implementation of a First-Generation Cell Processor,” in IEEE Journal of Solid-State Circuits, 41(1):179-196, January 2006.[16] M. Powell et al, ”Gated-Vdd: a Circuit Technique toReduce Leakage in Deep-Submicron Cache Memories,” inInternational Symposium on Low Power Electronics andDesign, pages 90-95, July 2000.[17] V. Soteriou and L.-S. Peh, ”Dynamic Power Managementfor Power Optimization of Interconnection Networks UsingOn/Off Links,” in International Symposium on HighPerformance Interconnects, pages 15-20, August 2003.[18] S. Vangal et al., ”An 80-Tile 1.28 TFLOPS Network-on-Chip in 65nm CMOS,” in International Solid-State CircuitsConference, pages 98-99, February 2007.[19] E. Waingold et al., ”Baring It All to Software: RAWMachines,”in IEEE Computer, 30(9):86-93, September 1997.[20] D. Wentzlaff et al., ”On-Chip Interconnection Architectureof the Tile Processor,” in IEEE Micro, 27(5):15-31,September/October 2007.[21] S. C. Woo, M. Ohara, E. Torrie, J. P. Singh, A.Gupta, A., ”The SPLASH-2 programs: characterizationand methodological considerations,” in 22nd Annual Int.Symposium on Computer Architecture, Italy, June 22 - 24,pp. 24-36, 1995.JP2011-282

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A Flexible Hybrid Transactional MemoryMulticore on FPGAOriol Arcas 1 , Nehir Sonmez 1 , Osman S. Unsal 2 , Adrián Cristal 3 and Mateo Valero 1Abstract— In this paper we present the design andimplementation of an MPSoC built to explore tradeoffsin multicore design space and to evaluate parallelprogramming proposals such as Transactional Memory(TM). Our flexible system, comprised of MIPSR3000-compatible cores is easily modifiable to studydifferent architecture, library and operating systemextensions. For this paper we evaluate a 16-core HybridTransactional Memory implementation based onthe TinySTM-ASF proposal on a Virtex-5 FPGA andwe accelerate three benchmarks written to investigateTM.I. IntroductionA recent alternative for exploring new generationsof multicores is based on building a multiprocessorsystem-on-chip (MPSoC). This approach enables theemulation of large parallel architectures on top ofa reconfigurable FPGA platform whose speed andprocess technology (currently 28 nm) are evolvingfaster than ASIC. Today’s FPGA systems can integratemultiple hard/soft processor cores, multiportedSRAM blocks, high-speed DSP units, andprogrammable I/O interfaces with configurable fabricof logic cells.With the abundance of pre-tested IntellectualProperty (IP) cores available, nowadays it is possibleto prototype large architectures in a full-systemenvironment which allows for faster and more productivehardware research than software simulation.Over the past decade, the RAMP project has alreadyestablished a well-accepted community visionand various novel FPGA architecture designs [4], [6],[8], [13], [17], [22]. Another advantage of FPGA emulationover software simulation is the reduced profilingoverhead and the possibility for a variety ofdebugging options.One direction is to choose a well-known architecturelike MIPS and utilize the commonly-availabletoolchains and library support. Although runninga minimal OS might be acceptable, a deeper softwarestack could have many advantages by providingmemory protection, performing scheduling, aidingdebugging and file system support. Full OS supportcan also be accomplished with a nearby hostcomputer which serves system calls and handles exceptions,instead of implementing them in the FPGAmodel [6].A proposal that has drawn considerable attentionfor programming shared-memory Chip Multi-Processors (CMP) has been the use of Transactional1 Universitat Politècnica de Catalunya, Barcelona SupercomputingCenter2 Barcelona Supercomputing Center3 Barcelona Supercomputing Center, CSIC - Spanish NationalResearch CouncilMemory (TM), an attractive paradigm for deadlockfreeexecution of parallel code without using locks.Locks are prone to deadlock or priority inversionwhile TM provides optimistic concurrency by executingatomic transactions in an all-or-none manner.The programmer encapsulates critical sections insidethe atomic{} construct and the underlying TMmechanism automatically detects data inconsistenciesand aborts and restarts one or more transactions.If there are no inconsistencies, all side effectsof a transaction are committed as a whole.Transactional Memory can be implemented inhardware (HTM) [3], [16], which is fast but resourceboundedwhile usually requiring changes to thecaches and the Instruction Set Architecture (ISA),or software (STM) [9] which can be flexible, runon off-the-shelf hardware, albeit at the expense oflower performance. To have the best of two worlds,there are intermediate Hybrid TM (HyTM) proposalswhere transactions first attempt to run on hardware,but are backed off to SW when HW resourcesare exceeded, and Hardware-assisted STM (HaSTM)which aims to accelerate a software-controlled TMimplementation by architectural means [7], [2].Despite the fact that FPGA emulators of manycomplex architectures of various ISAs have been proposed,only a few of these are on TM research, andonly up to a small number of cores. Furthermore, themajority of these proposals are based on proprietaryor hard processor cores, which imply rigid pipelinesthat can prevent an architect from modifying the ISAand the microarchitecture of the system.In this paper, we present TMbox, a sharedmemoryCMP prototype with Hybrid TM support.More specifically, our contributions are as follows:• A description of the first 16-core implementationof a Hybrid TM that is completely modifiablefrom top to bottom. This implies convenienceto study HW/SW tradeoffs in topics like TM.• We detail on how we construct a multicore withMIPS R3000-compatible cores, interconnect thecomponents in a bi-directional ring with backwardsinvalidations and adapt the TinySTM-ASF Hybrid TM proposal to our infrastructure.• Experimental results and performance comparisonsof STM, HTM and Hybrid TM on threebenchmarks designed to investigate trade-offs inTM. We also discuss the strengths and weaknessesof our approach.The next section presents the TMbox architecture,Section 3 explains the Hybrid TM implementation,Section 4 discusses the limitations and the results ofJP2011-283

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011running three benchmarks on TMbox. Related workis in Section 5 and Section 6 concludes the paper.II. The TMbox ArchitectureThe basic processing element of TMbox is theHoneycomb CPU core, a heavily modified and extendedversion of the Plasma soft core [20]. Thesynthesizable MIPS R2000-compatible soft processorcore Plasma was designed for embedded systemsand written in VHDL. It has a configurable 2/3 stagepipeline, a 4 KB direct-mapped write-through L1cache, and can address up to 64 MB of RAM. Itwas designed to run at a clock speed of 25 MHz,and it includes UART and Ethernet IP cores. Wechose it because it is based on the popular MIPSarchitecture, it is complete and it has a relativelysmall area footprint on the FPGA. Such RISC architectureswith simpler pipelines are more easily customizableand require fewer FPGA resources comparedto a deeply-pipelined superscalar processor, sothey are more appropriate to be integrated into alarger multiprocessor SoC.To effectively upgrade the MIPS R2000-compatible Plasma to our MIPS R3000-compatibleHoneycomb, we designed and implemented twocoprocessors: CP0 that provides support for virtualmemory using a Translation Lookaside Buffer(TLB), and CP1 encapsulating an FPU. We optimizedthe cores to make better use of the resourceson our Virtex-5 FPGAs where it can run at twicethe frequency (50 MHz); we modified the memoryarchitecture to enable virtual memory addressingfor 4 GB and caches of 8 KB; we implementedextra instructions to better support exceptionsand thread synchronization (load-linked and storeconditional) and we developed system libraries formemory allocation, I/O and string functions [21].The Honeycomb core (without an FPU and theDDR controller) occupies 5827 LUTs (Table I) on aVirtex-5 FPGA including the ALU, MULT/DIV andShifter units, the coherent L1 cache and the UARTcontroller, a comparable size to the Microblaze core.The Virtex5-155T FPGA contains 98K LUTs, 212BRAMs, and 128 DSP blocks. The DDR2 controllerthat occupies a small portion of the FPGA (around2%) performs calibration and serves requests [23].Using one controller provides sequential consistencyfor our multicore since there is only one addressbus, and loads are blocking and stall the processorpipeline.A. InterconnectionTo interconnect the cores, we designed and implementeda bi-directional ring as shown in Figure1. Arranging the components on a ring rather thana bus requires shorter wires which eases placementon the chip, relaxing constraints, and is a simpleand efficient design choice to diminish the complexitiesthat arise in implementing a large crossbar onFPGA fabric. Apart from increased place and routetime, longer wires would lead to more capacitance,Table ILUT occupation of componentsComponent 5-LUTs Component 5-LUTsPC next 138 Mem ctrl 156Control 139 Reg File 147Bus mux 155 ALU 157Shifter 201 MULT 497Pipeline 112 Cache 1985TLB 202 TM unit 1242Bus node 619 DDR ctrl 1119UART 77 TOTAL 6946longer delay and higher dynamic power dissipation.Using a ring will also enable easily adding and removingshared components such as an FPU or anyapplication-specific module, however this is out ofthe scope of this work.CPU requests move counterclockwise; they gofrom the cores to the bus controller, eg. CP U i -CP U i−1 - ... - CP U 0 - Bus Ctrl. Requests may bein form of read or write, carrying a type field, a 32-bitaddress, a CPU ID and a 128-bit data field, which isthe data word size in our system. Memory responsesalso move in the same direction; from the bus controllerto the cores, eg. Bus Ctrl - CP U n - CP U n−1- ... - CP U i+1 - CP U i . They use the same channelas requests, carrying responses to the read requestsserved by the DDR Ctrl. On the other hand, movingclockwise are backwards invalidations caused bythe writes to memory which move from the Bus Ctrltowards the cores in the opposite direction, eg. BusCtrl - CP U 0 - ... - CP U i−1 - CP U i . These carry onlya 32-bit address and a CPU ID field. When a writerequest meets an invalidation to the same address onany node, it gets cancelled. Moreover, the caches oneach core snoop and discard the lines correspondingto the invalidation address. We detail how we extendthis protocol for supporting HTM in the nextsection.III. Hybrid TM Support for TMboxTinySTM [9] is a lightweight and efficient wordbasedSTM library implementation in C and C++.It differentiates from other STMs such as TL2 andIntel STM mainly by its time-based algorithm andlock-based design. By default, it compiles andruns on 32 or 64-bit x86 architectures, using theatomic ops library to implement atomic operations,which we modified to include Compare and Swap(CAS) and Fetch and Add (FAA) primitives for theMIPS architecture using load-linked and store conditional(LL/SC) instructions. TinySTM-ASF is ahybrid port that enables TinySTM to be used withAMD’s HTM proposal, ASF [5], which we modifiedto work with TMbox. This version starts the transactionsin hardware mode and jumps to software if(i) hardware capacity is exceeded, (ii) there is toomuch contention or (iii) the application explicitly requiresit. Our hardware design closely follows theJP2011-284

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.An 8-core TMbox infrastructure showing the ring bus, the TM Unit and the processor core.InstructionXBEGIN (addr)XCOMMITTable IIHTM instructions for TMboxDescriptionStarts a transaction and saves the abort address (addr) in TMregister $TM0. Also saves the contents of the $sp (stack pointer)to TM register $TM1.Commits a transaction. If it succeeds, it continues execution. Ifit fails, it rolls back the transaction, sets TM register $TM2 toABORT CONFLICT, restores the $sp register and jumps to theabort address.XABORT (20-bit code) Used by software to explicitly abort the transaction. Sets TMregister $TM2 to ABORT SOFTWARE, restores the $sp registerand jumps to the abort address. The 20-bit code is stored in theTM register $TM3.XLB, XLH, XLW, XSB, XSH, XSW Transactional load/store of bytes, halfwords (2 bytes) or words (4bytes).MFTM (reg), (TM reg)Move From TM: Reads from a TM register and writes to a generalpurpose register.ASF proposal with the exception of nesting support.A new processor model (-march=honeycomb) wasadded by modifying GCC and GAS (the GNU Assembler).This new ISA includes all the R3000 instructionsplus RFE (Return from Exception), LL,SC and the transactional instructions in Figure II.All GNU tools (GAS, ld, objdump) were modified towork with these new instructions.To enable hardware transactions, we extended ourdesign with a per-core TM Unit that contains atransactional cache that only admits transactionalloads and stores. By default it has a capacity of 16data lines (256 bytes). If the TM cache capacity isexceeded, the transaction aborts and sets the TMregister $TM2 to ABORT FULL (explained in thenext section) after which the transaction reverts tosoftware and restarts.A transactional LD/ST causes a cache line to bewritten to the TM Unit. An invalidation of any ofthe lines in the TM Unit causes the current transactionto be aborted. Modifications made to thetransactional lines are not sent to memory until thewhole transaction successfully commits. The TMUnit provides single-cycle operations on the transactionalread/writeset stored inside. A Content AddressableMemory (CAM) is built using LUTs bothto enable asynchronous reads and since BRAM-basedCAMs grow superlinearly in resources. Two BRAMsstore the data that is accessed by an index providedby the CAM. Additionally, the TM Unit can serveLD/ST requests on an L1 miss if the line is found onthe TM cache.A. Instruction Set Architecture ExtensionsTo support HTM, we augmented the MIPS R3000ISA with the new transactional instructions listed inTable II. We have also extended the register file withfour new transactional registers, which can only beJP2011-285

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011LI $11, 5 //set max. retries = 5LI $13, HW_OFLOW //reg 13 has err. codeJ $TX$ABORT:MFTM $12, $TM2 //check error codeBEQ $12, $13, $ERR //jump if HW overflowADDIU $10, $10, 1 //retries++SLTU $12, $10, $11 //max. retries?BEQZ $12, $ERR2 //jump if max. retriesRDdoneRD hitRDcheckRD reqUncachedRDRD MissReadyUncachedRD reqRD reqWR reqRD MissFor WRWRcheckUncachedWR reqRD reqfor WRUncachedWRWR done$TX:XBEGIN($ABORT) //provide abort addressXLW $8, 0($a0) //transactional LD wordADDi $8, $8, 1 //a++XSW $8, 0($a0) //transactional ST wordXCOMMIT//if abort go to $ABORTFig. 2. TMbox MIPS assembly for atomic{a++} (NOPs andbranch delay slots are not included).Abort?Commit/abortTMbusCheckCommit?TMlockBusLock_busFailWaitMemRDRD doneWRbackNo invalidates,MemWriteWaitMemWRWR cancel on invalidateCommit/abortdoneread with the MFTM (move from TM) instruction.$TM0 register contains the abort address, $TM1 hasa copy of the stack pointer for restoring when atransaction is restarted, $TM2 contains the bit fieldfor the abort (overflow, contention or explicit) and$TM3 stores a 20-bit abort code that is provided byTinySTM, eg. abort due to malloc/syscall/interruptinside a transaction, or maximum number of retriesreached etc.Aborts in TMbox are processed like an interrupt,but they do not cause any traps, instead they jump tothe abort address and restore the $sp (stack pointer)in order to restart the transactions. Regular loadsand stores should not be used with addresses previouslyaccessed in transactional mode, therefore it isleft to the software to provide isolation of transactionaldata if desired. LL/SC can be used simultaneouslywith TM provided that they do not accessthe same address.Figure 2 shows an atomic increment in TMboxMIPS assembly. In this simple example, the abortcode is responsable for checking if the transactionhas been retried a maximum number of times, and ifthere is a hardware overflow (the TM cache is full),and in this case jumps to an error handling code (notshown).B. Bus ExtensionsTo support HTM, we added a new type of request,namely COMMIT REQ, and a new response type,LOCK BUS. When a commit request arrives to theDDR, it causes a backwards LOCK BUS message onthe ring which destroys any incoming write requestsfrom the opposite direction, and locks the bus togrant exclusive access to perform a serialized commitaction. All writes are then committed through the“channel” created, after which the bus is unlockedwith another LOCK BUS message, resuming normaloperation. More efficient schemes can be supportedin the future to enable parallel commits [3].C. Cache ExtensionsThe cache state machine reuses the same hardwarefor transactional and non-transactional loadsand stores, however a transactional bit dictates ifLock_bus OKTMwriteInvalidate all writeset entries in cacheWR Commit DoneStart WR commitFig. 3. Cache state diagram. Some transitions (LL/SC) arenot shown for visibility.the line should go to the TM cache or not. Apartfrom regular cached RD/WR, uncached accesses arealso supported, as shown in Figure 3. Cache missesfirst make a memory read request to bring the lineand wait in WaitMemRD state. In case of a store,the WRback and WaitMemWR states manage thememory write operations. While in these two states,if an invalidation arrives to the same address, thewrite will be cancelled. In case of a store-conditionalinstruction, the write will not be re-issued, and theLL/SC will have failed. Otherwise, the cache FSMwill re-issue the write after such a write-cancellationon invalidation.While processing a transactional store inside of anatomic block, an incoming invalidation to the sameaddress causes an abort and possibly the restart ofthe transaction. Currently our HTM system supportslazy version management: the memory is updatedat commit-time at the end of transactions, asopposed to having in-place updates and keeping anundo log for aborting. We also provide lazy conflictdetection which implies that data inconsistenciesare detected only after the speculative data iscommitted to the memory. Each transactional writesuccessfully committed causes an invalidation signal,which aborts the transactions that already havethose lines in the TM cache. So a transaction canonly be aborted due to data conflicts during transactionexecution (between XBEGIN and XCOM-MIT/XABORT).To support HTM, the cache state machine is extendedwith three new states, TMbusCheck, TMlockBusand TMwrite. One added functionalityis to dictate the locking of the bus prior to committing.Another duty is performing burst writesin case of a successful commit which runs throughthe TMwrite-WRback-WaitMemWR-TMwrite loop.The TMwrite state is also responsible for the gangJP2011-286

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011clearing of all entries in the TM cache and the writesetentries that are also found in L1 cache after acommit/abort. To enable this, address entries thatare read from the TM Unit are sent to L1 cache asinvalidation requests, after which the TM cache iscleared in preparation for a new transaction.IV. Experimental EvaluationTMbox can fit 16 cores in a Virtex-5 FPGA, occupying86,797 LUTs (95% of total slices) and 105BRAMs (49%). In this section, we first examine thetrade-offs of our implementation, we then discuss theresults of three TM benchmarks.A. Architectural Benefits and DrawbacksOn the TM side, the performance of our best-effortHybrid TM is bounded by the size of the transactionalcache of the TM unit. Although for this workwe chose to use a small, 16-entry TM cache, largercaches can certainly be supported on the TMbox onlarger FPGAs (keeping in mind the extra area overheadintroduced).In pure HTM mode, all 16 lines of the TM cachecan be used for running the transaction in hardware,however the benchmark can not run to completionif there are larger transactions that do not fit in theTM cache, since there is no hardware or softwaremechanism to decide what to do in this case. Thelargest overhead related to STM is due to keepingtrack of transactional loads and stores in software.The situation can worsen when the transactions arelarge and there are many aborts in the system.In Hybrid TM mode it is desired to commit asmany transactions as possible on dedicated hardware,however when this is not possible, it is also importantto provide an alternative path using softwaremechanisms. All transactions that overflow the TMcache will be restarted in software, implying all workdone in hardware TM mode to be wasted in the end.Furthermore to enable hybrid execution, TinySTM-ASF additionally keeps the lock variables inside theTM cache. This results in allowing a maximum of 8variables in the read/writesets of each transaction asopposed to 16 for pure HTM. Of course this is trueprovided that neither the transactional variables, northe lock variables share a cache line, in which case,in some executions we observed some transactionshaving a read/writeset of 9 or 10 entries successfullycommitting in hardware TM mode.On the network side, the ring is an FPGA-friendlyoption: we have reduced the place and route timeof an 8-core design to less than an hour using thering network, whereas it took more than two hoursusing a shared crossbar for interconnection and wecould not fit more than 8 cores. However, each memoryrequest has to travel as many cycles as the totalnumber of nodes on the ring plus the DDR2 latency,during which the CPU is stalled. This is clearly a systembottleneck: using write-back caches or relaxedmemory consistency models might be key in reducingthe number of messages that travel on the ringto improve system performance.On the processor side, the shallow pipeline negativelyaffects the operating frequency of the CPU.Furthermore larger L1 caches can not fit on ourFPGA, however they could be supported on larger,newer generation FPGAs, which would help the systemto better exploit locality. Having separate cachesfor instructions and data would also be a profitableenhancement.B. Experimental ResultsEigenbench is a synthetic benchmark that can betuned to discover TM bottlenecks. As Figure 4shows, the transactions in EigenBench with 2R+8Wvariables overflow (since TinySTM-ASF keeps thelock variables in the transactional cache) and getrestarted in software, exhibiting worse performancethan STM. However, the 4 read-4 write variable versionfits in the cache and shows a clear improvementover STM.In the SSCA2 results presented in Figure 5, weget an 1-8% improvement over STM because thisbenchmark contains small transactions that fit in thetransactional cache. Although Intruder (Figure 6) isa benchmark that is frequently used for TM, it isnot a TM-friendly benchmark, causing a high rateof aborts and non-scalable performance. However,especially with 16-cores, our scheme achieves in (i)discovering conflicts early and (ii) committing 48.7%of the total transactions in hardware, which results inalmost 5x superior performance compared to directupdateSTM, which has to undo all changes on eachabort. We were unable to run this benchmark onpure HTM because it contains memory operationslike malloc/free inside transactions that are complexto run under HTM and are not supported yet onTMbox.These three benchmarks can benefit from our hybridscheme because they do not run very large transactions,so most of the fallbacks to software causedare due to repeated aborts or mallocs inside transactions.For SSCA2, we see good scalability for up to 8cores, and for Intruder for up to 4 cores. The performancedegradations in STM for Intruder are causedby the fact that the STM directly updates the memoryand as the abort rates increase, its performancedrastically decreases. Furthermore the system performanceis benchmark-dependent: compared to sequentialversions, the TM versions can perform in therange of 0.2x (Intruder) to 2.4x (SSCA2). We willbe looking more into overcoming the limitations ofthe ring bus, improving on the TM implementation(serialized commits) and the coherency mechanism.V. Related WorkFew mostly initial work has been published in thecontext of studying Transactional Memory on FPGAprototypes. ATLAS is the first full-system prototypeof an 8-way CMP system with PowerPC hard processorcores, buffers for read/write sets and per-CPUJP2011-287

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Table IIITM Benchmarks UsedTM BenchmarkEigenbench[11]Intruder[15]SSCA2[15]DescriptionHighly tunable microbenchmark for TM with orthogonal characteristics. We haveused this benchmark (2000 loops) with (i) r1=8, w1=2 to overflow the TM cacheand vary contention (by changing the parameters a1 and a2) from 0–28%, and (ii)r1=4 and w1=4 to fit in the TM cache and vary the contention between 0–35%.Network intrusion detection. A high abort rate benchmark, contains many transactionsdequeuing elements from a single queue. We have used this benchmark with128 attacks.An efficient and scalable graph kernel construction algorithm. We have used problemscale = 12Execution time (seconds)Execution time (seconds)Normalized speedupNormalized speedup98765432100,0265432100,0254,543,532,521,510,50,030,03Fig. 4.Eigenbench - 2R/8W variables0,04 0,06 0,11Contention (%)0,04 0,06 0,11Contention (%)0,21Eigenbench - 4R/4W variables0,210,380,38Eigenbench results (16 cores).01 2 4 8 162,521,510,5Fig. 5.Number of threadsSSCA2 benchmark results.01 2 4 8 16Number of threadsFig. 6.Intruder benchmark results.Hybrid HTMSTMPure HTMSTMHybrid HTMPure HTMHTMHyTMSTMSTMHyTMcaches augmented with transactional read-write bitsand TCC-type HTM support, with a ninth core forrunning Linux and serving OS requests from othercores [17].Kachris and Kulkarni describe a TM implementationfor embedded systems which can work withoutcaches, using a central transactional controlleron four Microblaze cores[12]. TM is used as a simplesynchronization mechanism that can be used withhigher level CAD tools like EDK for non-cache coherentembedded MPSoC. The proposal occupies asmall area on chip, but it is a centralized solutionthat would not scale as we move up to tens of cores.Similarly, the compact TM proposal, composed byoff-the-shelf cores with a software API managingtransactions, can be useful for early validation of programsto TM [19].Recent work that also utilizes MIPS soft cores focuseson the design of the conflict detection mechanismthat uses Bloom filters for an FPGA-basedHTM [14]. Application-specific signatures are comparedto detect conflicts in a single pipeline stage.The design takes little area, reducing false conflicts.The underlying bit-level parallelism used for signaturesmakes this approach a good match for FPGAs.This proposal was the first soft core prototype withHTM albeit only with 2 cores; it is not clear whatis done in case of overflow or how the design wouldscale. Another approach that uses Bloom filters onFPGAs to accelerate STMs on commodity cores waspresented by Casper et al. [2].Ferri et al. proposed an energy-efficient HTM on acycle-accurate SW simulator, where transactions canoverflow to a nearby victim cache [10]. It is a realisticsystem with cache coherence, and non-centralizedTM support, running a wide range of benchmarkson various configurations, however bus-based snoopyprotocol would not scale with more cores, the simulatoris not scalable and would suffer from modellinglarger numbers of processors, and no ISA changes arepossible to the ARM hard CPU core.Recently, an HTM was proposed by C. Thacker forthe Beehive system [24]. In case of overflow the entiretransaction is run under a commit lock withoutusing the transactional hardware. We believe thatsoftware transactions might have more to offer. TheBeehive design also uses a uni-directional ring whereJP2011-288

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011messages are added to the head of a train with thelocomotive at the end [24]. Ring networks are suggestedas a better architecture for shared memorymultiprocessors by Barroso et al. [1] and a cachecoherent bi-directional ring was presented by Oi etal. [18], but as far as we know, using backwardspropagatingwrite-destructive invalidations is a novelapproach. Unlike some of the proposals above, oursystem features a large number of processors andis completely modifiable which enables investigatingdifferent interconnects, ISA extensions or coherencymechanisms.VI. ConclusionsWe have presented a Hybrid TM design, where wefit 16 cores on an FPGA providing hardware supportand accelerating a modern TM implementationrunning benchmarks that are widely used in TM research.The results agree with our insights and findingsfrom other works [15]: Hybrid TM works well whenhardware resources are sufficient, providing betterperformance than software TM. However, whenhardware resources are exceeded, the performancecan fall below the pure software scheme in certainbenchmarks. The good news is that Hybrid TM isflexible; a smart implementation should be able todecide what is best by dynamic profiling. We believethat this is a good direction for further research.We have also shown that a ring network fits well onFPGA fabric and using smaller cores can help buildinglarger prototypes. Newer generations of FPGAswill continue to present multicore researchers withinteresting possibilities, having become so mature asto permit investigating credible largescale systemsarchitecture. We are looking forward to extendingthe TMbox with a memory directory and to usemultiple-FPGAs.References[1] L. A. Barroso and M. Dubois. Cache coherence on a slottedring. In International Conference on Parallel Processing,1991.[2] J. Casper, T. Oguntebi, S. Hong, N. G. Bronson,C. Kozyrakis, and K. Olukotun. Hardware acceleration oftransactional memory on commodity systems. ASPLOS’11, pages 27–38, 2011.[3] H. Chafi, J. Casper, B. D. Carlstrom, A. McDonald,C. C. Minh, W. Baek, C. Kozyrakis, and K. Olukotun.A scalable, non-blocking approach to transactional memory.HPCA ’07, pages 97–108, 2007.[4] D. Chiou, H. Sunjeliwala, H. Sunwoo, J. D. Xu, andN. Patil. FPGA-based Fast, Cycle-Accurate, Full-SystemSimulators. Number UTFAST-2006-01, 15(5):795–825,November Austin, TX, 2006.[5] D. Christie, J.-W. Chung, S. Diestelhorst, M. Hohmuth,M. Pohlack, C. Fetzer, M. Nowack, T. Riegel, P. Felber,P. Marlier, and E. Rivière. Evaluation of AMD’s advancedsynchronization facility within a complete transactionalmemory stack. In EuroSys ’10, pages 27–40,2010.[6] E. S. Chung, E. Nurvitadhi, J. C. Hoe, B. Falsafi, andK. Mai. A complexity-effective architecture for acceleratingfull-system multiprocessor simulations using FPGAs.In FPGA ’08, pages 77–86, 2008.[7] P. Damron, A. Fedorova, Y. Lev, V. Luchangco, M. Moir,and D. Nussbaum. Hybrid transactional memory. ASP-LOS ’06, 2006.[8] N. Dave, M. Pellauer, and J. Emer. Implementing a functional/timingpartitioned microprocessor simulator withan FPGA. WARFP, 2006.[9] P. Felber, C. Fetzer, and T. Riegel. Dynamic performancetuning of word-based software transactional memory. InPPoPP, pages 237–246, 2008.[10] C. Ferri, S. Wood, T. Moreshet, R. Iris Bahar, andM. Herlihy. Embedded-TM: Energy and complexityeffectivehardware transactional memory for embeddedmulticore systems. J. Parallel Distrib. Comput., 70:1042–1052, October 2010.[11] S. Hong, T. Oguntebi, J. Casper, N. Bronson,C. Kozyrakis, and K. Olukotun. EigenBench: A simpleexploration tool for orthogonal TM characteristics.In IISWC’10, 2010.[12] C. Kachris and C. Kulkarni. Configurable transactionalmemory. In FCCM ’07, pages 65–72, April 2007.[13] A. Krasnov, A. Schultz, J. Wawrzynek, G. Gibeling, andP. yves Droz. RAMP Blue: A message-passing manycoresystem in FPGAs. In FPL 2007, pages 27–29, 2007.[14] M. Labrecque, M. Jeffrey, and J. Steffan. Applicationspecificsignatures for transactional memory in soft processors.In ARC 2010, pages 42–54. 2010.[15] C. C. Minh, J. W. Chung, C. Kozyrakis, and K. Olukotun.STAMP: Stanford transactional applications formulti-processing. In IISWC, 2008.[16] K. E. Moore, J. Bobba, M. J. Moravan, M. D. Hill, andD. A. Wood. LogTM: Log-based transactional memory.In HPCA 2006, pages 254–265, 2006.[17] N. Njoroge, J. Casper, S. Wee, Y. Teslyar, D. Ge,C. Kozyrakis, and K. Olukotun. ATLAS: A chipmultiprocessorwith TM support. In DATE’07, pages3–8, 2007.[18] H. Oi and N. Ranganathan. A cache coherence protocolfor the bidirectional ring based multiprocessor. InPDCS’99, pages 3–6, 1999.[19] M. Pusceddu, S. Ceccolini, G. Palermo, D. Sciuto, andA. Tumeo. A compact TM multiprocessor system onFPGA. FPL’10, pages 578–581, 2010.[20] S. Rhoads. Plasma soft core. http://opencores.org/project,plasma.[21] N. Sonmez, O. Arcas, G. Sayilar, O. S. Unsal, A. Cristal,I. Hur, S. Singh, and M. Valero. From Plasma to Bee-Farm: Design experience of an FPGA-based multicoreprototype. In ARC’11, March 23-25 2011.[22] Z. Tan, A. Waterman, R. Avizienis, Y. Lee, H. Cook,D. Patterson, and K. Asanović. RAMP gold: An FPGAbasedarchitecture simulator for multiprocessors. In DAC’10, pages 463 – 468, 2010.[23] C. Thacker. A DDR2 controller for BEE3. MicrosoftResearch, 2009.[24] C. Thacker. Hardware Transactional Memoryfor Beehive. In http://research.microsoft.com/enus/um/people/birrell/beehive/hardwaretransactionalmemory for beehive3.pdf. MSR Silicon Valley, 2010.JP2011-289

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-290

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011An Adaptive Controller to Save DynamicEnergy in LP-NUCADarío Suárez Gracia 1 , Teresa Monreal Arnal 2 , and Víctor Viñals Yúfera 1Abstract— Portable devices often demand powerfulprocessors to run computing intensive applications,such as video playing or gaming, and ultra low energyconsumption to extend device uptime. Such conflictingrequirements are hard to fulfil and appeal foradaptive hardware that only consumes energy whenrequired.LP-NUCA is a tiled cache organization aimedat high-performance low-power embedded processorsthat sequentially looks up for blocks ordered by temporallocality in groups of small tiles. Unfortunately,LP-NUCA has two main dynamic energy wastingsources: (a) blocks are continuously migrating amongtiles even in low locality phases, (b) to reduce cachelatency, the tag and data arrays of the tiles are alwaysaccessed in parallel.This paper proposes a learning-based controllerthat dynamically tunes block migration and cache accesspolicy between parallel and serial. During lowtemporal locality phases the controller drops blocksfrom the LP-NUCA root tile, L1, and forces a serialaccess to the tag and data arrays in the tiles, thusreducing the energy waste. Using a cycle-accuratesimulator and energy estimations derived from an LP-NUCA layout, the proposed controller reduces dynamicenergy by 20% on average for single and multithreadworkloads.Keywords— Cache Hierarchy, Multithreading, Energy,Power, Embedded, NUCAI. IntroductionTHE way people use computers is partially shiftingfrom personal computers with local data tomobile devices with data on the cloud. This “platform”displacement has not carried along “application”changes. Users almost demand the same performancein mobile devices that they used to experiment in desktopcomputers. Giving the same performance levelwith the tight energy constraints of mobile environmentsappeals for adaptive hardware that judiciouslydetects whether it is profitable to invest energy inorder to satisfy the user.One of the most energy-efficient mechanisms toachieve high-performance is the memory hierarchy [1],where several small caches pretend to be an unboundand fast storage thanks to the locality of programs.Non-Uniform Cache Architecture, NUCA, exploits localityat a finer granularity than conventional cachesbecause they enable inter bank block migrations [2].Light Power NUCA, LP-NUCA, is a variant of LightNUCA (L-NUCA) for high-performance low-powerembedded processors, such as those of mobile devices,that conveys blocks through three specialized1 Computer Architecture Group (gaZ). Dpto. de Informáticae Ingeniería de Sistemas. Instituto de Investigación en Ingenieríade Aragón. Universidad de Zaragoza. e-mail {dario,victor}@unizar.es2 Department of Computer Architecture. Universitat Politécnicade Catalunya (UPC). e-mail: teresa@ac.upc.eduNetworks-in-Cache as L-NUCA does [3], [4], but alsoincludes two static techniques for saving dynamicenergy, Miss Wave Stopping and Sectoring. Thesetechniques together with LP-NUCA ad-hoc networkmechanism enable to outperform conventional andstatic NUCA organizations in terms of energy andperformance.The organization of LP-NUCA consists of manysmall tiles behaving as a very large distributed victimcache [5]. Blocks remain ordered by temporallocality (TL), so the L1, renamed root-tile (r-tile),recently evicted blocks have a lower service latencythan those previously evicted. The LP-NUCA designrelies on the temporal locality of programs alongall their execution; hence, when the r-tile evicts ablock, it triggers a chain of dominoes replacement formaintaining the TL block ordering. But an energywasting problem can arise during low TL phases. Duringthem, the r-tile floods the rest of tiles with blocksthat will be seldom requested. Besides, these blocksdegrade older ones that may be re-referenced in thenear future. Moreover, LP-NUCA always accesses inparallel tag and data arrays to reduce cache latency.Since a data array access roughly consumes morethan 5× the energy of the tag in LP-NUCA [4], thisparallel access is a major waste of energy for requestswith high likelihood of being a miss. Ideally, we wouldlike to detect low locality phases to prevent the r-tilefor evicting low locality blocks and to dynamicallyswitch between parallel and serial access in the restof tiles.LP-NUCAs were conceived for single-thread processors;however, to increase their performance ⁄energy ratio,current advanced embedded processors rely onextracting parallelism from multiple threads ratherthan from a single one. For example, the Intel XeonLC3528, the MIPS MIPS32-1004K, or the NetlogicXLP832 simultaneously execute between 2 and 4threads [6], [7], [8]. Traditionally, multi-threadedprocessors (MT) have shared all the cache hierarchy[9] increasing the chances of polluting the cachewith useless blocks and evicting useful blocks fromother threads. LP-NUCA in MT environments wouldsuffer from this problem and would benefit from acontroller able to drop low locality blocks and toretain high locality ones. Finally, in this case wecan expect little performance improvements becausehigh locality threads will experiment more hits in theLP-NUCA.This paper extends LP-NUCA in several significantways. First, we identify that LP-NUCA wastesdynamic energy during low locality phases by continuouslydegrading blocks among tiles and by accessingJP2011-291

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011the tag and data arrays in parallel even when thelikelihood of miss is high. Second, we propose a learningbased mechanism based on local search methodsthat dynamically selects when dropping blocks fromthe cache will harm neither performance nor energy.Third, we employ the same controller to dynamicallyadjust between parallel and serial access to the cachetag and data arrays leveraging from the congestionmanagement support from L-NUCA. Fourth, we showthat the proposed controller requires minimal hardwarefor improving energy consumption with smallgains in performance.The rest of the paper is organized as follows. SectionII presents the adaptive controller. Section IIIdescribes our methodology and simulation environment.Section IV evaluates the results. Section Vcomments on the related work, and Section VI concludesthe paper.II. Adaptive Drop Ratio ControllerFigure 1 shows the LP-NUCA cache organization.Misses in LP-NUCA operate as follows: when the r-tile misses, it allocates an empty way for the incomingblock. When necessary, it evicts a victim block to aneighbour tile with the minimum latency difference.The destination tile, with a transport latency of 3,will repeat the operation to a tile with transportlatency of 4, and this dominoes operation continuesuntil a tile has an empty way or a block is evictedfrom the whole LP-NUCA.to nextcache7 6 5 6 76 4 3 4 65 3 1 3 5ROOTTILEfrom nextL-NUCA levelscache1 2 3processorFig. 1. LP-NUCA basic organization with its three Networksin-Cache:Search in blue, Transport in red, and Replacementin black. The number in the right upper corner ofeach tile represents its service latency assuming single-cycletilesThis chain of evictions keeps blocks ordered by temporallocality but wastes a lot of energy when blocksare not requested before leaving the LP-NUCA. Besides,in their way out, these blocks pollute the tilesand force the evictions of other blocks that may be requestedin the near future causing additional damage.The goal of this work is to find a controller minimizingthe insertion of these polluted blocks from the r-tileinto the rest of tiles. To do so, we propose an AdaptiveDrop Ratio controller able to dynamically detectlow locality phases of programs and choose the optimaldrop rates for all threads in execution. Besides,when dropping all r-tile eviction blocks, the likelihoodof a request becoming a cache miss increases, so thecontroller will switch the access policy of the dataand tag arrays inside tiles from parallel to serial tosave extra power.Now, we explain the controller operation. It keepsa reference state with the drop rates of all the threadsand its value in the desired target function (cachehits, IPC, . . . ). At regular periods, named epochs,the controller changes the drop rate of a single thread(trial), and after N epochs have completed, whereN is the number of threads, it ranks the drop ratetrials accordingly to the target function. The besttrial supersedes the reference when its target valueis better than the reference one. To simplify theimplementation, the drop rate changes at regularsteps, named ∆, and ranges between 0 and 1. A droprate of 0 means all blocks are evicted to the rest oftiles and of 1 means all blocks are dropped 1 . From agiven drop rate, we can move either upwards, adding∆, or downwards, subtracting ∆. To avoid the trial ofboth, we add a variable specifying the direction, andrestrict the trial to this direction. This variable takestwo values, −1 for downwards (↓) and 1 for upwards(↑), making straightforward the implementation ofthe controller. In round-robin fashion, the controllerselects one thread and computes its trial drop rate asdritrial + dir i ∆ where dritrial , and dir irepresent the trial drop rate, the reference drop rate,and the direction of thread i, respectively. At theend of thread i trial epoch, dir i reverts if the reachedtarget is lower than the reference one.= dr refi, dr refiAlgorithm 1: Hill-Climbing algorithm of theADR controllercomputeEpochStatistics();if n epoch % n threads == 0 thenforeach thread doif not isExempted(thread) thenif ifTrialBetterThanRef(thread) thenref[thread].dir = trial[thread].dir;elseref[thread].dir = !trial[thread].dir;endendendif bestTrialBetterThanRef() ormaxEpochsWoutChange() thenrefSt.dr = bestTrialSt.dr;endendn epoch++;setTrialState();Algorithm 1 shows the proposed implementation ofthe ADR controller based on hill climbing with two additionalimprovements: the exemption of threads andthe update of the reference state to avoid temporarymaximums. The penalty of dropping useful blockscan be very high because they can cause processorstalls. So when a thread experiences a few number of1 Dirty blocks require to be sent to the next cache level incopy-back configurations.JP2011-292

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011misses, it is counterproductive his evaluation becausewe will be moving the controller in a flat zone andnot towards the steep areas 2 . Regarding the latter,temporary maximums, we observe from the experimentsthat it is worthy its update either when a trialperforms better or after a given number of epochswithout change. In this work, we empirically fixedthis value to 4× the number of threads in execution.drop rates LP-NUCA# hitsthread 0 thread 1referencestatetrialstatereference# hits0001.00.51.00.5[[1.0,â],[0.5,á]]controllerevaluationepoch i epoch i+1 epoch i+2[[0.5,â],[0.5,á]][[1.0,â],[1.0,á]][[0.5,â],[0.5,â]][[0.0,â],[0.5,â]]drop ratereferencetrialtimeFig. 2. Temporal behaviour of the Adaptive Drop RatioController with an step, ∆, of 0.5For example, Figure 2 shows a controller for a 2thread machine in which the number of LP-NUCAhits is the target function. We assume that thecontroller state is defined as a list of tuples ST =[[dr 0 , dir 0 ], ..., [dr n−1 , dir n−1 ]]. During epoch i, thread0 is the trial thread and is in trial downwards directionstate. Alike, thread 1 is evaluated in epoch i+1with trial upward state. At the end of this epoch, thecontroller observes the target function, LP-NUCAnumber of hits, and epoch i results better than thereference one. So in epoch i+2, dr 1 remains equaland dr 0 reduces in one step keeping the direction.Thread 1 reverses its direction because in epoch i+1the number of hits was lower than in the referenceepoch.TABLE IPossible organizations for the Adaptive DropRatio ControllerEvaluation TriggerTime 1-512K cycles# misses 1 ⁄4-5× r-tile blocksStep Size From 0.1 to 1Target Metric IPC, # hits, reuse rateAuxiliary Tags, m From 0 to 128 entriesExemption Threshold From 5 to 100 MPKITo suggest a good ADR controller design based onhill-climbing, we evaluated the various parameterssummarized in Table I.The first big choice is how to trigger a new epoch,either at fixed intervals of time or after a fixed numberof r-tile misses. On the former, we have experimented2 We could also reevaluate after a number of epochs equalsto the no exempted threads, but the hardware complexity willbe higher.with epochs from 1K to 512K cycles and, on the laterfrom 1 ⁄4 to 5× the number of blocks the r-tile stores 3 .The second big choice is step size; i.e., with an step of0.5 a thread can drop all, half, or none of the evictedblocks. Finally, when a thread reaches the “all drop”state, dr j = 1, the controller requires an heuristic forreturning the injection of evicted blocks into the restof LP-NUCA tiles, dr j = 0. One option is to force thereturn to a state that does not drop all the blocks aftera given number of epochs. Another smarter optionis the introduction of a small auxiliary tags trackingthe last m dropped blocks and lookup for misses inthis structure. When updating the controller state ifseveral requests have matched in the auxiliary tags,automatically that thread leaves the “all drop” state.Also, we can fix the misses per epoch that we requireto evaluate a thread.Finally, Figure 3 shows the behaviour of the controllerexecuting 255.vortex with 179.art during 2millions of cycles. ADR synchronously reevaluatesafter 4096 cycles, has 3 dropping states, and whenthe drop ratio is 1, cache arrays are serially accessed.It includes an auxiliary tag array of 512 entries. Thisconfiguration was the best among all the test of thiswork. The plot includes from top to bottom the numberof committed instructions, the drop ratio indexes,the number of rest of tiles hits, the number of evicted(inserted) blocks into the rest of tiles, and the numberof dropped blocks. 255.vortex, red lines, is anexample of a benchmark that is better to exemptfrom the controller. Its miss rate is very low, and bydropping blocks we could only reduce its performanceand increase the accesses to the next cache level. Onthe contrary, 179.art experiences program phases inwhich it pollutes the cache. For example, before the54M point, the controller drop blocks and keeps usefulblocks inside the cache that are serviced to the r-tile,and then when the miss rate drops again below theexemption threshold, it evicts all the blocks insidethe rest of tiles.A. Hardware CostThe hardware implementation of the AdaptiveDrop Ratio controller requires minimal overhead.Most current processors already include the performancecounters for the target function and we onlyrequire to store the reference state for all the threads,1 bit for the direction plus log 2 (drop ratios), and thetrial configuration. The partial tags only require ansmall SRAM array, consuming little energy, and ifnecessary it could be easily replaced by a bloom filter.Other novelty of this work is the proposal of switchingbetween parallel and serial access to the cachearrays. At first glance, this feature could be hard toimplement, just the opposite is true. The key observationis that when the likelihood of cache miss ishigh only the tag array is accessed. So we can add anextra bit in the Search Network disabling the accessesto the data arrays in the tiles. Misses will propagate3 Assuming a 32KB r-tile organized in blocks of 32B, thereare 1024 blocks in total.JP2011-293

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011CommittedKInstructions42052.5 53 53.5 54 54.5Drop Ratio1.000.500.0052.5 53 53.5 54 54.5Hits900600300052.5 53 53.5 54 54.5R-TILEevicted blocksADR droppedblocksFig. 3.800600400200052.5 53 53.5 54 54.58006004002000vortexart52.5 53 53.5 54 54.5Cycles (Millions)SMT execution of 255.vortex and 179.art with an ADR of 4Kcycles epochs and 3 drop ratiosback-to-back over the fabric. Nevertheless, in the rarecase that a tile hits during a serial access, the dataarray have to be accessed. Since we can not stop therequest propagation in the Search network because itdoes not have any control flow mechanism, we needto re-inject the request in parallel mode. This reinjectionfeature is already supported by LP-NUCAto cope with congestion of the Transport network,when a tile hits and does not have any output transportlink available. Therefore, a serial request hittingin a tile will reset the serial and set the congestionbits, so that the request be reinserted.III. Methodology and SimulationEnvironmentWe employ the same simulation environment,energy estimations, and cache hierarchy organizationsthat previous LP-NUCA work [4]. The baselineprocessor resembles the IBM/LSI PowerPC476FP [10], [11] and executes 1 or 2 threads simultaneously.Table II summarizes the main parameters forthe reference processor and cache hierarchy, includingthe same L1 and L3 caches and either a conventionalL2, a S-NUCA, or an L-NUCA. All caches use LRUreplacement except L-NUCA that employs LRF, leastrecently-filled,and they all have a single read/writeport.Our workload comprises the same embedded domainoriented application than previous work [4].Nevertheless, to get deeper insights from the results,we divide the benchmarks in two groups: low MPKIand high MPKI as table III shows. For the two SMTexperiments we present the results in three groups:low MPKI, medium MPKI, and high MPKI whenboth, one, and none benchmarks of the combinationexhibit a low misses per kilo instruction rate.TABLE IISimulator Micro-architectural parameters. BS, AM,lat, and init stand for block size, access mode, latency,and initiation rate, respectivelyClock Frequency1 GHz Fetch/Decode/ 2Commit widthIssue width 2(IN+ME) ROB / LSQ entries32 / 16+2FPINT/FP/MEM 8 / 8 / 8 branch predictor bimodal +IW entriesgshare, 16 bitMiss. branch 6 Instruction perfectpenaltyCacheL1/L2/L3 8 / 8 / 4 TLB miss latency 30MSHR entriesMSHR secon. 4 Store Buffer/ L2/missesL3 WB size a 8 / 4 / 4L1/r-tile b 32KB–4Way–32B BS, write-through, 2-cyclelat, 1-cycle initL2512KB–8Way–32B BS, serial AM, 4-cyclelat, 2-cycle init, copy-backS-NUCA 2×2 128KB–2Way–32BS, parallel AM, 3-cycle lat, 3-cycle init, copy-backL-NUCA rest 32KB–2Way–32B BS, parallel AM, copyback,levels: 3, total size: of tiles448KBL34MB eDRAM–16Way–128B BS, 14-cycle lat,7-cycle init, copy-backMain Memory 100 cycles/4 cycle inter chunk, 16 Byte busa L2, S-NUCA, L-NUCA, and L3 Write Buffers coalesceentriesb In r-tile, copy-back and write-aroundWe used a similar energy estimations than the previouswork for the battery powered domain in 32nm [4]. In the single thread execution, the simulatorwarms-up caches and branch-predictor for 200Minstructions before starting the cycle-accurate simulation.We follow the same approach that Li et al.for energy and delay measurements in SMT environments[12], and account for all the energy consumedJP2011-294

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIIWorkload selection. I, F, 0, 6 refer to Integer,Floating Point, SPEC CPU2000, and SPEC CPU2006,respectivelyLow MPKI a 186.crafty I0, 255.vortex I0, 177.mesa F0,458.sjeng I6, 482.sphinx3 F6High MPKI 164.gzip I0, 179.art F0, 187.facerec F0,401.bzip2 I6, 445.gobmk I6, 464.h264refI6, 473.astar I6, 453.povray F6a L1 MPKI rate lower than 20 in the baseline processoruntil the last thread commits 100M instructions.IV. Results EvaluationThis section compares the cache organizations presentedin previous section, namely, conventional L2(L2), Static NUCA (SN), LP-NUCA (LP), and twoLP-NUCAs enhanced with two adaptive drop ratiocontrollers: one with synchronous epochs (ADR C)and another with epoch based on the number ofrequest for evictions (ADR R). Both ADR C andADR R have been selected after exhaustively exploringthe controlling design space with the optionsshown in Table I. ADR C re-evaluates the drop ratiosand directions every 4096 cycles, while in ADR Roccurs after 1024 attempts of r-tile evictions (or r-tileprimary misses). Both controllers share the rest ofparameters, namely, 3 dropping states, 512-entry auxiliarytags, and an exemption threshold of 50 MPKIin the rest of tiles.First, we compare the energy consumption, then wecontinue with the execution time, and we finish withenergy-delay results. For the sake of brevity, we onlyshow overall and averaged results, but the individualbehaviours do not differ from the presented one.A. EnergyFigure 4 shows the total energy consumed by allconfigurations. LP-NUCA with the ADR have thebest results regardless the benchmark group and thenumber of threads.If we focus on the last three bars to compare theperformance of the ADR controller we observe thatthe synchronous one performs slightly better thanthe based on the number of replacements. In themore energy demanding benchmarks, high MPKI,the controller reduces energy by 20% on average.B. Execution TimeDropping blocks may reduce LP-NUCA hit ratesand increase execution time, EX. To verify that theproposed ADRs do not affect EX Figure 5 shows thetotal execution time.LP-NUCA shows performance improvements overL2 and SN, and both controllers slightly reduce executiontime because they keep inside the cache usefulblocks that otherwise would be expelled. ADR C andADR R reduces total execution time by 2.14% and2.29%, respectively, in the single-thread environment.Improvements become marginal in the 2 SMT andTotal Energy (mJ)Total Energy (mJ)Fig. 5.7060504030201006005004003002001000Dynamic L2/SN/RESTTDynamic L1/RTStatic L2/SN/RESTTStatic L1/RTL2 SN LP ADR_C ADR_R L2 SN LP ADR_C ADR_RLow MPKIHigh MPKIDynamic L2/SN/RESTTDynamic L1/RTStatic L2/SN/RESTTStatic L1/RTL2SNLPLow MPKIFig. 4.Total Cycles (M)Total Cycles (M)1000800600400200ADR_C0900080007000600050004000300020001000(a) Single ThreadADR_RL2SNLPMed. MPKI(b) 2 SMTADR_CADR_RL2SNLPHigh MPKIEnergy consumption comparisonL2SNLPADR_RADR_CLow MPKIHigh MPKI(a) Single ThreadL2SNLPADR_RADR_CLow MPKI Med. MPKI High MPKI(b) 2 SMTADR_CADR_RTotal Execution Time for the different configurationsreduce to 0.62% and 0.89% for ADR R and ADR C,respectively, because the multi-threading executioncovers the memory stalls.C. Overall System ImpactFinally, we present the sum of the energy-delayof the tested benchmarks. Figure 6 includes the L3energy to show that dropped blocks are not requestedto the L3 increasing the overall energy.Again ADR R and ADR C are the winners in allcategories. LP-NUCA improvements in executiontime reduces the static component with regards toL2 and SN, and the controllers reduce on averagedynamic energy-delay, their target, 7.6% for all butlow MPKI workloads.V. Related WorkArchitects have proposed a plethora of designs tosave cache energy through reconfigurable caches thatJP2011-295

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Energy-Delay (mJ x s)Energy-Delay (mJ x s)35302520151050500450400350300250200150100500Dynamic EDStatic EDL2 SN LP ADR_C ADR_R L2 SN LP ADR_C ADR_RLow MPKIHigh MPKIDynamic EDStatic EDL2SNLPLow MPKIADR_C(a) Single ThreadADR_RL2SNLPMed. MPKI(b) 2 SMTADR_CADR_RL2SNLPHigh MPKIFig. 6. Energy-Delay. This figure includes L3 cache consumptionas wellchange their number of ways, sets, or both at runtime [13], [14], [15], [16]. For an updated state ofthe art please refer to Sundararajan et al. [16]. Previousworks adapt the cache at a finer granularitythan this work, and most proposed techniques canbe easily applied to the LP-NUCA. Contrary to theoriginal LP-NUCA design [4], this work proposes aproactive dynamic technique to save energy while previousones, Sectoring and Miss Wave Stopping, werecompletely static and application agnostic. Besides,this work analyzes SMT workloads which have notbeen extensively studied.Regarding the learning based approach, the HillClimbing algorithm has been employed for distributingresources in SMT processors [17], but not forcache reconfiguration.VI. ConclusionsUltra-portable mobile devices demand quasidesktopperformance with a fraction of energy consumption.Since application behaviour changes duringexecution, processors require adaptive mechanismwasting the minimum amount of energy when necessary.This paper proposes an adaptive controller for LP-NUCA, a tiled organization for high-performance lowpowerprocessors, that automatically decides whencache blocks are not reused and can be dropped reducingthe cache activity. Besides, during high droppingphases, the controller is able to change the cachearray access from parallel to serial further reducingthe energy consumption.With representative workloads, a cycle-accuratesimulator, and implementation based energy estimations,we observe that the proposed controller reducesdynamic energy on average by 20% for single-threadand 2-threaded workloads without increasing the executiontime.ADR_CADR_RAcknowledgementThe authors would like to thank Luis Montesanodel Campo for his helpful comments on the learningstrategies. This work was supported in part by grantsTIN2010-21291-C02-01 and TIN2007-60625 (SpanishGovernment), gaZ: T48 research group (Aragon Governmentand European ESF), Consolider CSD2007-00050 (Spanish Government), and HiPEAC-2 NoE(European FP7/ICT 217068).References[1] Shekhar Borkar and Andrew A. Chien, “The future ofmicroprocessors,” Commun. ACM, vol. 54, pp. 67–77,May 2011.[2] Changkyu Kim, Doug Burger, and Stephen W. Keckler,“An adaptive, non-uniform cache structure for wire-delaydominated on-chip caches,” in Proc. of ASPLOS-X, 2002.[3] Darío Suárez, Teresa Monreal, Fernando Vallejo, RamónBeivide, and Víctor Viñals, “Light NUCA: a proposalfor bridging the inter-cache latency gap,” in Proc. ofDATE’09, 2009.[4] Darío Suárez Gracia, Giorgos Dimitrakopoulos,Teresa Monreal Arnal, Manolis G.H. Katevenis, andVíctor Viñals Yúfera, “LP-NUCA: Networks-in-Cache forhigh-performance low-power embedded processors,” toappear in IEEE Trans.on VLSI Systems, 2011.[5] Norman P. Jouppi, “Improving direct-mapped cacheperformance by the addition of a small fully-associativecache and prefetch buffers,” in Proc. of ISCA’90, 1990.[6] Intel Embedded, “Intel® Xeon® processor C5500/C3500series. Datasheet–Volume 1,” February 2010.[7] MIPS Technologies, “MIPS32® 1004Kcoherent processingsystem (CPS),” 2010.[8] Tom R. Halfhill, “Netlogic broadens XLP family,” MicroprocessorReport, vol. 24, no. 7, pp. 1–11, 2010.[9] D.M. Tullsen, S.J. Eggers, and H.M. Levy, “Simultaneousmultithreading: Maximizing on-chip parallelism,” in Proc.of ISCA’95, 1995.[10] Tom R. Halfhill, “The rise of licensable SMP,” MicroprocessorReport, vol. 24, no. 2, pp. 11–18, 2010.[11] LSI Corporation, “PowerPC processor (476FP)embedded core product brief, http://www.lsi.com/DistributionSystem/AssetDocument/PPC476FP-PB-v7.pdf,” January 2010.[12] Yingmin Li, David Brooks, Zhigang Hu, Kevin Skadron,and Pradip Bose, “Understanding the energy efficiencyof simultaneous multithreading,” in Proc. ISLPED’04,2004.[13] David H. Albonesi, “Selective cache ways: on-demandcache resource allocation,” in Proc. of MICRO’32, 1999.[14] Rajeev Balasubramonian, David Albonesi, Alper Buyuktosunoglu,and Sandhya Dwarkadas, “Memory hierarchyreconfiguration for energy and performance in generalpurposeprocessor architectures,” in Proc. of MICRO’33,2000.[15] Chuanjun Zhang, Frank Vahid, and Walid Najjar, “Ahighly configurable cache architecture for embedded systems,”in Proc. of ISCA’03, 2003.[16] Karthik T. Sundararajan, Timothy M. Jones, and NigelTopham, “Smart cache: A self adaptive cache architecturefor energy efficiency,” in Proc. of SAMOS’11, 2011.[17] Seungryul Choi and Donald Yeung, “Hill-climbing smtprocessor resource distribution,” ACM Trans. Comput.Syst., vol. 27, no. 1, pp. 1–47, 2009.JP2011-296

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Acelerando las simulaciones de sistemacompleto usando Simics en sistemasmultiprocesadorS. González 1 , F. Triviño 2 , F. J. Andujar 2 , J. L. Sánchez 2 , F. J. Alfaro 2Resumen—El uso de simuladores de sistema completopara evaluar el desarrollo de un determinado componenteen un sistema de computación, es una prácticafrecuente. Esto permite obtener mejores resultadosy conclusiones en comparación a una simulación parcialdonde solo se modela una parte del sistema y sedescarta su interacción con el resto del sistema.Sin embargo, realizar una simulación de sistemacompleto trae consigo inconvenientes como un mayortiempo para realizar las pruebas y un mayor consumode recursos. Esto puede generar una demandacreciente proporcional a la complejidad del modelo aanalizar, como se da en la investigación de sistemasmultiprocesador al aumentar el número de procesadoreso al realizar simulaciones en paralelo.En este trabajo se describen las mejoras de rendimientoen términos de tiempo de simulación queofrece la versión 4 del simulador Simics, con la incorporaciónde nuevas tecnologías pensadas para mejorarel uso de sistemas multiprocesador, como es SimicsAccelerator. Se realizan pruebas con el benchmarkPARSEC, midiendo el tiempo de simulación ycomparando el rendimiento con la versión 3 de Simics,analizando las ventajas y desventajas en optar por laactualización de versión.Palabras clave— Simulación, rendimiento, Simics4.I. IntroducciónLA simulación es un método muy usado en la investigacióny diseño de propuestas de arquitecturade computadores al permitir evaluar una variedadde arquitecturas sin tener que construirlas, permitiendola reducción en coste y tiempo de desarrollode un proyecto. Además, con ello se mejoran los procedimientosde validación de nuevos modelos graciasa la sistematización de pruebas, las cuales pueden serreplicadas fácilmente y ejecutadas en paralelo, así comola obtención de resultados.Muchas veces será útil realizar un análisis del comportamientodel sistema en su totalidad incluyendo elprocesador, la memoria, los dispositivos de entrada ysalida, buses, redes y otras interconexiones. Todo ellose puede evaluar de forma conjunta permitiendo laejecución de un sistema operativo y otras aplicacionescomerciales como benchmarks. Esa es la finalidadcon la que surgen los simuladores de sistema completo[1]. Un inconveniente de este tipo de simulacioneses que requieren de mucho tiempo para completarse,debido al gran nivel de detalle del sistema modelado.Así pues, un reto importante es poder reducir almáximo el tiempo de simulación.1 Dpto. de Informática, Univ. Peruana Cayetano Heredia, e-mail: santos.gonzalez.t@upch.pe2 Dpto. de Sistemas Informáticos,Univ. Castilla-La Mancha, e-mail: {ftrivino, fandujar, jsanchez,falfaro}@dsi.uclm.esSimics [4] es una herramienta de simulación de sistemacompleto, capaz de modelar diferentes tipos dearquitecturas. Sin embargo, cuando el sistema es muycomplejo las simulaciones pueden requerir horas o inclusodías en completarse.En este trabajo se revisa la versión 4 de Simicsanalizando sus nuevas características. Éstas surgencomo resultado de las nuevas tendencias en el uso demáquinas multiprocesador y clusters. Una de las másimportantes es la inclusión de Simics Accelerator [2],que permite reducir el tiempo de ejecución haciendoun uso más eficiente del hardware donde se realiza lasimulación.Para determinar cómo influyen las nuevas característicasde Simics 4, se realizarán diversas simulacionesusando el benchmark PARSEC [3], el cualagrupa un largo y variado conjunto de aplicacionesque han sido correctamente paralelizadas con diferentestécnicas. Se trata de ofrecer argumentos parapoder decidir sobre la actualización o no del sistemay dependiendo del modelo a simular poder tomar unadecisión.Este artículo está organizado de la siguiente manera:en la Sección II se incluye una breve descripcióndel simulador Simics 4.2 y de sus características másimportantes. En la Sección III se describe el procesode pruebas para obtener los tiempos de simulación.Finalmente, en la Sección IV se presentan las conclusionesy trabajo futuro.II. SIMICS 4Simics [4] es una plataforma que permite simularun sistema completo lo cual facilita tanto el desarrollode hardware como de software proporcionando lonecesario para la simulación de ambos componentesdentro de un mismo contexto. Como se puede observaren la Figura 1 tanto los requerimientos hardwarecomo los del sistema, cuyo modelado mantieneuna estructura modular, son completamente simuladosen una máquina (host) [1].También se pueden tener varias arquitecturas tantomonoprocesador como multiprocesador y ejecutaren ellas sistemas operativos convencionales, benchmarks,aplicaciones de escritorio, entre otras aplicacionescomerciales. Una de las ventajas que se tienees que se pueden usar cargas de trabajo reales, algoque no se puede hacer con otros simuladores.La versión utilizada para el presente trabajo es laversión 4.2. Entre las principales características conlas que cuenta esta versión se pueden destacar:JP2011-297

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Mejoras en rendimiento y escalabilidad debidoa la inclusión de Simics Accelerator 2.0. Permiteejecutar simulaciones de sistemas distribuidosy máquinas multiprocesador acelerando el desarrollode software y hardware ayudados tambiéncon las herramientas de depuración y checkpointing.Mejoras en los modelos a simular, permitiendola comprensión de los programas a través deun visualizador de rendimiento y facilitando eldiagnóstico de errores.Mejoras en la interfaz de usuario logrando integrarsecon Eclipse a través de plugins parainiciar y controlar las sesiones de Simics. Estohace útil las herramientas y flujos de trabajo deEclipse.Conectividad a través de telnet, un visor de memoriay soporte unicode.TABLA INuevas arquitecturas soportadas por Simics 4.Modelos Procesadores ComponentesIBM PowerPCPPC464FP AMCC464PPC440GXSoC, MemoriaDDR,FLASH,Conectividadserial yEthernetFreescale PowerMPC8347, MemoriaQUICC MPC8360E DDR,II ProFLASH,MPC83xxConectividadserial yEthernetARM Integrator/CPARM926,ARM1136,ARM1176ARM Basic Intel StrongARMMemoriaDDR,FLASH,Conectividadserial yEthernetRAM, ConectividadserialFig. 1. Simulador de sistema completo.Simics 4 soporta nuevos tipos de arquitecturas. Enla Tabla I se pueden observar los nuevos modelos incorporadospara esta versión [4]. Simics, dentro desus nuevas características, también permite realizarsimulaciones híbridas logrando unir modelos de procesadoresde distintos niveles dentro de un sistemasimulado sirviendo tanto para el desarrollo rápidocomo para su validación, y luego poder obtener unanálisis detallado de rendimiento. Este tipo de simulacioneshíbridas están disponibles en los modelos demicroprocesador Freescale QorIQ P4080, y en próximasversiones se podrá tener un API genérico paraque pueda ser aplicado a otras microarquitecturas.De igual forma, pueden usarse nuevas extensionespara Simics como es el soporte en tiempo real delsistema operativo. Así, se permite que Simics puedadetectar cuándo un proceso se inicia, termina yse mantiene activo en el sistema simulado, sirviendocomo herramienta para la detección de errores.Otra de las características que incorpora Simicses la de lograr un puente con los modelos de SystemCpermitiendo que éstos sean incluidos como partedel sistema de simulación de Simics. De esta forma,será posible construir una plataforma virtual quepermita ser ejecutada a través de la interacción demodelos en DML, C, Python y SystemC lograndoque los usuarios puedan construir de manera rápidauna plataforma completa, al facilitar la reutilizaciónde estructuras previamente realizadas sin necesidadde tener que hacer cambios.También es posible trabajar con TLM(Transaction-level modeling) [5] que tiene lapropiedad de realizar la comunicación a través dellamadas a funciones directamente entre los módulossimulados sin tener que interactuar con el kernelsimulado. Esto se realiza en unidades que seanlo más largas posibles, para reducir el número decomunicaciones, y con la menor frecuencia posible.Las versiones anteriores de Simics basaban el rendimientoy escalabilidad con el módulo llamado SimicsCentral [6]. Este módulo administraba la conexiónde nodos heterogéneos de distintas máquinassimuladas, las cuales podían encontrarse en distintoshosts. Así pues, dicho módulo tenía que encargarsede sincronizar el tiempo virtual entre el simuladory el tráfico simulado entre las máquinas. Ahora lanueva versión de Simics reemplaza este módulo de simulacióndistribuida incorporando Simics Accelerator2.0. Este nuevo módulo trae consigo otras venta-JP2011-298

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2. Simulación Multihilo[2]jas adicionales que repercuten en el rendimiento delsistema. A continuación se resumen las principalesventajas que mejoran la velocidad en la simulación.A. Simics Accelerator 2.0Uno de los principales requisitos al realizar simulacioneses que éstas, además de precisas, puedan serrealizadas en el menor tiempo posible. Esto deberíacumplirse incluso simulando sistemas y cargas de trabajograndes sacando provecho del uso de servidoresy clusters.Simics busca este objetivo a través de este nuevomódulo donde se implementan mejoras relacionadascon la decisión en el nivel correcto de abstracción deltiempo, en la metodología de modelado basada entransacciones entre los distintos dispositivos, creaciónde modelos de procesadores rápidos y simulacionesmultihilo [1]. Estas últimas están orientadasa ser aplicadas en la ejecución de modelos más complejos,como se muestra en la Figura 2. Empezandocon un modelo sencillo se simula una máquina en unacomputadora de un solo núcleo. El host provee ciertoporcentaje de procesamiento, lo que equivale a lavelocidad de simulación en términos del rendimientodel sistema global y de cómo es percibido por elusuario.Cuando se realiza un modelo más complejo, de 4máquinas simuladas en el mismo host con el mismopoder de procesamiento, el rendimiento esta vez tieneque ser dividido por la cantidad de máquinas simuladas.Esta vez el usuario percibirá una reducciónde cuatro veces la velocidad de simulación. UsandoSimics Accelerator y un host con cuatro núcleos,el mismo modelo complejo de cuatro máquinas puedeaprovechar la capacidad de procesamiento, ahoramayor en el host, logrando que cada procesador delhost pueda realizar el procesamiento de cada máquinasimulada. Esto producirá para el usuario una percepciónde la misma velocidad que en el caso inicial,como el de una sola máquina simulada en un computadorde un solo núcleo.La memoria compartida es uno de los medios queusa Simics para liberar la demanda de memoria enel sistema a simular. Lo que hace es verificar quelos contenidos dentro de las memorias RAM, ROM,FLASH o del disco simulado no sean redundantes detal forma que no se duplique contenido y sólo se tengauna copia del mismo en la memoria de la máquinaen donde se realiza la simulación.La simulación distribuida que ofrece esta nuevaversión de Simics permite el uso de múltiples hostspara aumentar la escalabilidad y aprovechar mejor eluso de clusters. Esto mejora directamente el rendimientoen la ejecución de múltiples sesiones de Simicsen paralelo, especificándose la cantidad de núcleosque serán usados para cada sesión de Simics, lograndode esta forma escalabilidad, particionando los recursosdel host para la simulación y evitando bloqueosentre las simulaciones.La sincronización es importante cuando se realizauna simulación distribuida. Idealmente los procesospodrían realizarse simultáneamente en tiempo simuladoy en tiempo real pero eso no se puede por la grancantidad de sobrecarga que sería necesaria para lasincronización dejando muy poco tiempo para el trabajoreal. Simics introduce un pequeño retardo quehace que la simulación distribuida no esté completamentesincronizada, a costa de no producir tanta sobrecargapermitiendo que los distintos componentespuedan comunicarse solamente a intervalos especificados,los cuales son definidos desde la configuraciónde la simulación.Simics permite la simulación de máquinas interconectadasmediante una red de área local lográndoseconectar varias máquinas mediante ethernet-links,con las que se modela una red Ethernet a nivel detrama. Esta conexión se puede ver como un cableethernet que va conectado a un dispositivo ethernetJP2011-299

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de la máquina virtual o como un switch/hub al quepueden conectarse varios dispositivos. El tráfico quese envía sobre dicha conexión puede ser TCP/IP ocualquier otro protocolo que funcione en Ethernet.A esta conexión también se le puede añadir ciertosservicios IP simulados mediante una clase llamadaservice-node que proporciona un nodo de red simuladoa modo de servidor y que puede actuar como unrouter IP entre redes.Simics permite mejoras en el modelado de sistemas,lo cual es de suma importancia para obtenermayores beneficios de la simulación, como se puedever en la Figura 3, donde se representan un cluster deprocesadores, SoCS, memorias, placa y demás partesde un sistema interconectados para luego ser combinadosa través de una estructura jerárquica. Todoello usando las herramientas de diseño de dispositivoscon los que cuenta Simics Accelerator.Para poder realizar simulaciones en paralelo se debecumplir con ciertos requisitos como que los modelossimulados no deben compartir memoria y quelas arquitecturas a simular permitan simulación multihilo.Dentro de los modelos ya diseñados, los quepermiten simulación multihilo son el x86-440bx yMPC8641.Una de las razones para comparar las versiones deSimics, es para poder determinar si es conveniente ono realizar la actualización a la versión 4 en los trabajosya desarrollados con la versión 3, teniendo encuenta, por ejemplo, la compatibilidad con otras herramientasque extienden Simics como es el caso deGEMS (General Execution-driven Multiprocessor Simulator)[7]. GEMS es un programa compuesto porun conjunto de módulos que hace posible la simulaciónde sistemas multiprocesadores de forma másdetallada.Básicamente, GEMS está formado por dos módulos:Ruby y Opal. Ruby permite simular la jerarquíade memorias cache, controladores de memoria, bancosde memoria principal y la red que interconectatodos estos elementos. Opal permite la simulacióncon ejecución fuera de orden, para modelar diferentesarquitecturas, desde monoprocesadores hasta multiprocesadorescomo SMPs, CC-NUMAs y CMPs,donde es posible la ejecución de varios hilos de formasimultánea.Si bien originalmente fue desarrollado para el estudiode sistemas de memoria proporcionando modelosde temporización detallados, enfocados a la simulaciónde arquitecturas concretas, ahora tambiénpermite profundizar en otros tipo de investigacionescomo las de redes de interconexión en el chip [8].El inconveniente que por ahora mantiene Simics4es no ser compatible con la actual versión de GEMS2.1.1. En la página de GEMS se cuenta con un parcheexterno que funciona con las versiones 3.0, 3.2, 4.0,4.2, y 4.4. Sin embargo, también se hace mención queéste no ofrece soporte para el módulo Opal y se retirael soporte para la versión Simics2.2, y en caso de quese desee trabajar con estos módulos se sugiere usarla versión de Simics3 [9]. También se indica que elparche no ha sido probado por el equipo de GEMSy no se brindará soporte para el mismo. Según lainformación que se tiene actualmente en los foros yla documentación hay bastantes problemas para laintegración de GEMS con Simics4. Recientemente,GEMS informó de su integración con el simuladorM5 [10], otro simulador de sistema completo, el cualahora se encuentra integrado en un nuevo simuladorllamado GEM5, por lo cual aparentemente GEMSestaría más abocado a dicha integración, dejando unpoco de lado su continuidad con Simics.III. Evaluación de RendimientoEn este trabajo se busca comparar el tiempo desimulación entre las versiones 3 y 4 de Simics, y cómoinfluye la complejidad del modelado al aumentar lacantidad de procesadores en dicho cálculo.A. Arquitectura modeladaFig. 3. Ejemplo de componentes jerárquicos.B. Simics 4 y GEMSPara la realización de las pruebas se usó la arquitecturax86-440BX, la cual puede modelar variossistemas con procesadores x86 y AMD64 basados enel chipset 440BX. “Tango” es la máquina simulada,que viene ya instalada con Fedora Core 5 con soportepara desarrolladores.En la Tabla II se pueden ver las principales característicasde la máquina simulada utilizada para laspruebas. Por el tipo de arquitectura se tiene el límitede un máximo de ocho procesadores en la placabase. En las pruebas se harán mediciones de tiempode simulación en donde se variará la cantidad deprocesadores.JP2011-300

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Resultados de tiempo de simulación de aplicaciones PARSECTABLA IICaracterísticas de la máquina simulada.Modelo x86-440BXSlots para CPU 8 máximo.Dump de disco tango1-fedora5.craffKernel 2.6.15Procesador 2 GHz Pentium 4Disco duro 20GBMemoria RAM 2 GBB. Aplicaciones PARSECPara la evaluación de rendimiento se han realizadopruebas con el benchmark PARSEC, midiendoel tiempo de simulación al ejecutar las aplicacionesque forman esta suite. Para poder realizar la mediciónse hace uso de las Instrucciones Mágicas (MagicInstructions), para lo cual se compiló el benchmarkPARSEC con la opción gcc-hooks y determinar así elmomento en que entra a una fase la ejecución de laaplicación.Dependiendo de la arquitectura, se podrá pasar unvalor a través de las instrucciones mágicas, teniendocomo referencia el archivo magic-instruction.h dondese detalla las instrucciones para cada tipo de arquitecturay para el caso de la arquitectura X86en Simics3 solo se retorna el valor 0 por lo que setendrá que pasar el valor a través de los registros delprocesador de la máquina simulada [11].De todos los programas de la suite PARSEC,aquí se mostrarán resultados de las aplicaciones freqmine(fm), fluidanimate (fa) y x264 (x2).C. Realización de pruebasPara las pruebas se crearon checkpoints base conuna cantidad determinada de procesadores para cadaprueba. Se simularon máquinas con 2, 4 y 8 procesadores.Teniendo en cuenta las diferencias en cómose pasan las instrucciones mágicas en las dos versionesde Simics, para cada una de ellas se compiló elbenchmark con las instrucciones mágicas correspondientes.Una vez compilado el benchmark a través del APIde Simics y con un script en python se recogen lasestadísticas del tiempo de simulación de los distintosprogramas usados. También hay que tener en cuenta,de igual forma que para la instrucciones mágicas, quealgunas funciones ya no son soportadas por el nuevoAPI, como es el caso de la función run(), que se usabadesde la versión de Simics 2 y que aún era compatiblepara la versión de Simics 3. La versión 4 solo soportala función SIM run command().Para la creación de los checkpoints se ha de teneren cuenta que no son compatibles para las versionesanteriores, lo que quiere decir que en caso de quecreemos un checkpoint con la versión de Simics 4 nopodrá ser leída con la de Simics 3. Otro punto a teneren cuenta es que la nueva versión de Simics asignaun código al momento de crear el checkpoint que seguarda en la variable build id en el archivo de configuración.Al migrar un checkpoint este código puededar problemas al no identificar la misma versión porlo que en caso de que sea necesario tendrá que sermodificado.Las imágenes del disco trabajadas entre distintasversiones pueden ser reutilizadas entre versiones, deigual forma las que han sido agrupadas con las diferenciasde disco con la herramienta craff de Simics.Lo único que se tiene que tener en cuenta es la compatibilidadcon las instrucciones mágicas de cada versión.D. ResultadosUna vez realizadas las ejecuciones de las aplicacionesse obtuvieron los tiempos de simulación por cadauna. En la Figura 4 se puede ver el tiempo de simulaciónpara las dos versiones de Simics a estudiar,y para las aplicaciones utilizadas. En las gráficas sepuede apreciar que las simulaciones realizadas con lanueva versión de Simics se completan con un menortiempo de simulación que con la versión anterior. Engeneral, y como parece lógico, al aumentar la cantidadde procesadores el tiempo de simulación tambiénaumenta, lo que se puede apreciar más claramentepara la versión de Simics 3.De las pruebas realizadas, se obtiene un mayor rangode diferencia en el tiempo de simulación para elcaso de la aplicación freqmine. Para este caso se obtieneuna reducción del tiempo de simulación de 61 %para 2 procesadores, 70,1 % para 4 procesadores yJP2011-301

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201185,4 % para 8 procesadores.Por contra, con la aplicación x264 es en donde ladiferencia es menor. En este caso se obtiene un 22,6 %para 2 procesadores, 53,9 % para 4 procesadores y69,6 % para 8 procesadores.En la Figura 5 se puede observar el tiempo totalde simulación para las pruebas realizadas, es decir eltiempo que tomaría haber ejecutado las 3 aplicacionesde la suite simultáneamente. En este caso tenemosuna reducción del tiempo de simulación de 45 %cuando son 2 procesadores, 58 % para 4 procesadoresy 75 % para 8 procesadores.Para las pruebas con 8 procesadores se obtiene cercade un 10 % de mejor rendimiento por cada procesador.En promedio, se puede alcanzar un 60 % dereducción en tiempo de simulación respecto a la versión3.Fig. 5. Tiempos totales de simulación.IV. ConclusionesLas mejoras en cuanto a aceleración de procesos ytiempo de simulación para la nueva versión de Simicseliminan cuellos de botella y mejoran el rendimientoen modelos complejos, realizando varias simulacionesen paralelo y aprovechando el poder de procesamientode un host multinúcleo o incluso un cluster.Las mejoras en cuanto a sincronización de tiemposen la simulación y la administración de informaciónredundante al momento de ejecutar el benchmark llegana reducir en promedio un 60 % de tiempo desimulación para las pruebas realizadas con las aplicacionesfreqmine, fluidanimate y x264 del PARSEC.Y para el caso de una simulación con una máquinacon 8 procesadores se llega a obtener hasta un 10 %de reducción en tiempo de simulación por cada procesador.En general, las mejoras obtenidas por la nueva versiónde Simics4 son muy positivas permitiendo realizarsimulaciones con una mayor cantidad de procesadoressin tener una gran demanda en tiempode simulación, permitiendo así analizar modelos máscomplejos.El punto débil por el momento de la nueva versiónde Simics es la no compatibilidad con otros programasque lo extienden, como es el caso de GEMS, elcual es compatible con la versión 3 de Simics y actualmenteno ofrece soporte para la nueva versión.Además, es posible que no lo tenga en cuenta por suactual trabajo en el nuevo simulador GEM5En el momento de redactar este documento, se estabaindicando un estudio para mejorar las simulacionescon paralelismo de núcleos y su análisis, loscuales dependían del uso de GEMS pero al tener problemaspara la compilación de sus módulos se podríatener en cuenta para un futuro trabajo el análisis delnuevo simulador para las investigaciones con máquinasmultinúcleo.AgradecimientosEste trabajo ha sido realizado gracias a la beca deayudas Universidad de Castilla-La Mancha - BancoSantander para estancias de investigación de profesoresiberoamericanos en la Universidad de Castilla-LaMancha en 2011Referencias[1] Jakob Engblom, Daniel Aarno, and Bengt Werner Full-System Simulation from Embedded to High-PerformanceSystemsl, Processor and System-on-Chip Simulation, pp.25-44 , 2010.[2] Jakob Engblom, Simics Accelerator, in Whitepaper Virtutech,March 2009.[3] Christian Bienia, Sanjeev Kumar, Jaswinder PalSingh,and Kai Li, The PARSEC Benchmark Suite:Characterization and architectural implications, in Proceedingsof the 17th International Conference on ParallelArchitectures and Compilation Techniques, October 2008[4] Simics Models, http://www.virtutech.com/products /simicsmodels[5] Jakob Engblom, Transaction-Level Modeling in Simic, inWhitepaper Virtutech, August 2009.[6] Magnusson, P., Christensson, M., Eskilson, J., Forsgren,D., Hallberg, G., Hogberg, J.,Larsson, F., Moestedt, A.,Werner, B. Simics: A full system simulation platform,Computer, Innovative Technology for Computer Professionals,pp. 50-58, Febrary 2002.[7] Milo M. K. Martin, Daniel J. Sorin, Bradford M. Beckmann,Michael R. Marty, Min Xu, Alaa R. Alameldeen,Kevin E. Moore, Mark D. Hill, and David A. Wood, Multifacet’sgeneral execution-driven multiprocessor simulator(GEMS) toolset,, SIGARCH Comput. Archit.News, vol.33, no. 4, pp. 92-99, 2005.[8] Francisco Triviño, Francisco J. Andujar, Alberto Ros,José L. Sánchez, Francisco J. Alfaro Sistema Integradode Simulación de NoCs, XX Jornadas de Paralelismo LaCoruña(Spain). Septiembre 2009.[9] Multifacet GEMS: External patches for Simics,http://www.cs.wisc.edu/gems/common/release notes/gems2.1.1 patch1 releasenotes.txt[10] The GEM5 Simulator System, http://gem5.org/[11] Virtutech: Simics User Guide forUnix, pp 143-145, Febrary 2008.https://www.simics.net/pub/simics/3.0 fyr609/simicsuser-guide-unix.pdfJP2011-302

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Arquitecturas, algoritmos y aplicaciones sobreaceleradores hardwareJP2011-303

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-304

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Parallelization of the Generalized HoughTransform on GPUJuan Gómez-Luna 1a , José María González-Linares b , José Ignacio Benavides a , Emilio L. Zapata b andNicolás Guil bAbstract–Programs developed under the ComputeUnified Device Architecture (CUDA) obtain the highestperformance rate, when the exploitation of hardwareresources on a Graphics Processing Unit (GPU) ismaximized. In order to achieve this purpose, loadbalancing among threads and a high value of processoroccupancy, i.e. the ratio of active threads, areindispensable. However, in certain applications, anoptimally balanced implementation may limit theoccupancy, due to a greater need of registers and sharedmemory. This is the case of the Fast Generalized HoughTransform (Fast GHT), an image processing technique forlocalizing an object within an image. In this work, wepresent two parallelization alternatives for the Fast GHT,one that optimizes the load balancing and another thatmaximizes the occupancy. We have compared them using alarge amount of real images to test their strong and weakpoints and we have drawn several conclusions about underwhich conditions it is better to use one or another. We havealso tackled several parallelization problems related tosparse data distribution, divergent execution paths andirregular memory access patterns in updating operationsby proposing a set of generic techniques as compacting,sorting and memory storage replication.Keywords–GPU, CUDA, occupancy, load balancing,Generalized Hough Transform.GI. INTRODUCTIONRAPHICS Processing Units (GPUs) haveemerged as general purpose coprocessors inthe last years. An extensive variety ofapplications is nowadays benefiting from theirimpressive potential, especially after the launch ofCUDA [9]. GPUs offer a huge amount of computingthreads, arranged in a Single-Program Multiple-Data(SPMD) model. Such extensive resources make themattractive for general-purpose computations. Thisinterest has boosted the development of GPUprogramming tools, such as CUDA and OpenCL [10].General programming recommendations are optimizingload balancing and increasing processor occupancy.However, depending on the algorithm structure, bothrecommendations cannot be applied simultaneously.Then some kind of tradeoff must be undertaken, since anoptimally balanced implementation may increase the useof registers and the need for sharing data among threads,what decreases occupancy. Moreover, parallelizationbecomes even more challenging, if the algorithmpresents workload-dependent computations and nonlinearmemory references. The former provokes1 Corresponding author: el1goluj@uco.esa Computer Architecture and Electronics Department,University of Córdoba, Córdoba, Spainb Computer Architecture Department, University ofMálaga, Málaga, Spaindivergence among threads, if the layout is not carefullyplanned. The latter affects the locality of references,what entails serialized memory accesses.In this work, we will discuss how performanceproblems caused by previous considerations can bemitigated using suitable strategies. They will beillustrated by implementing an efficient parallelizationof the GHT. We conduct an exhaustive analysis of theprevious considerations that leads us to the followingresults:• We propose compacting and sorting, in order toreduce accesses to global memory and thenumber of executed instructions.• We present two efficient mechanisms fordistributing two sorted lists among blocks andthreads. One of them optimizes the loadbalancing, whilst the other maintains theoccupancy at the highest possible values.• We use replicated sub-histograms per blockwith successful results.The rest of the paper is organized as follows. Section 2depicts the characteristics of regular and irregularapplications. Section 3 presents the GHT. Section 4describes our proposals for an efficient implementationof irregular parts. In section 5, we propose the use ofreplicated sub-histograms per block, in order to improvea voting process. Section 6 presents the executionresults. Finally, section 7 concludes the paper.II. REGULAR AND IRREGULAR PROBLEMSParallelizing any application on any parallel platformrequires programmers to apply a certain level ofabstraction. The change from a sequential conception toa parallel conception is never trivial. However, somealgorithms are regular in the sense that they use linearaddressing and apply the same computation on everyinstance of the input data. This inherent parallelismmakes those algorithms to be easier to implement on aSPMD platform, as is a GPU. In this regard, manyimage and video processing applications exhibit regularcomputation patterns and regular memory accesses. TheCUDA SDK includes some samples of regular imageprocessing.Following the optimization recommendations when aregular problem is parallelized, ensures a goodperformance and impressive speedups on CUDAenabledGPUs. However, achieving an importantimprovement with the implementation of an irregularproblem is always harder. The distribution of work anddata in such algorithms cannot be characterized a priori,because these quantities are input-dependent and evolvewith the computation itself. Algorithms with theseproperties yield performance problems for parallelimplementations, where equal distribution of work overJP2011-305

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011processors and locality of reference are required withineach processor. In this way, programmers shouldcarefully analyze the memory access patterns, in order toavoid penalties due to uncoalescing or bank conflicts.Idle threads and warp divergence should be minimizedby properly planning of work distribution and loadbalancing across threads and blocks.III. PARALLELIZING A COMPLEX IMAGE AND VIDEOPROCESSING APPLICATIONThis work illustrates different strategies to cope withsparse data array access, divergent execution paths andirregular memory access patterns in GPU applicationsusing, as a case study, a version of the GeneralizedHough Transform, called Fast GHT. As it is explainednext, this technique presents regular as well as irregularcomponents.A. The Generalized Hough TransformTemplate matching is a difficult problem with highcomputational requirements. One of the most popularalgorithms for detecting shapes in images is the HoughTransform [8]. Ballard [1] generalized the HoughTransform (GHT) to detect arbitrary shapes, which arerepresented by a template. In the original formulation,called Classic GHT, a feature space (composed of thetemplate contour points and their vectors to a referencepoint) is transformed into a four-dimensional Houghspace (the rotation, scale and displacement of thetemplate in the image). The maximum value in thisHough space corresponds to the rotation, scale anddisplacement parameters of the template in the image.The size of the Hough space and the number of votingoperations can be enormous. Thus, the computation timeof the Classic GHT is very high, making it inappropriatefor real-time applications. A solution to reduce thememory and computational requirements were presentedby Guil et al [6]. In that work, the detection process issplit into three stages by uncoupling the rotation, scaleand displacement calculation using invariantinformation. Three transforms are applied in thisversion, called Fast GHT, to obtain the rotation, scaleand displacement parameters.The invariant features selected in that work arepairings of contour points, p i and p j , whose gradientangles, θ i and θ j, are separated by a given differenceangle ξ . For every pairing a spatial angle, α ij, adistance value, d ij , and reference vectors, r i and r j, arecomputed as shown in Figure 1. The feature space(composed of the pairings with their gradient angles,spatial angles, distances and vectors) is transformed in atwo-dimensional Hough space (the gradient and spatialangles) with every pairing voting in the bin with thesame gradient and spatial angle. The Hough spaces ofthe template and the image can be compared using aspecial cross-correlation function whose maximumvalue is located in the rotation value, β , of the templatein the image.Next, the gradient angles of the pairings in thetemplate are rotated β degrees and a new transform in aone-dimensional Hough space (the scale parameter) isapplied. Every pairing in the template and the imagefeature space with the same gradient and spatial anglesare selected and the quotient of their distances is used tovote in the Hough space. The position of the maximumof the Hough space is the scale parameter. Finally, thereference vectors of the pairings in the template arerotated and scaled using the calculated parameters, and atransform in a two-dimensional Hough space (thedisplacement coordinates) is computed. Pairings withthe same gradient and spatial angles are selected and thevectors superimposed to vote in the Hough space whosemaximum corresponds to the position of the template inthe image.Fig. 1. Variables defined in the GHTLet T be the template, I the image, (x i , y i ) thecoordinates of an edge point p i , ξ the difference angle,O , S and D the Hough spaces to computeorientation, scale and displacement respectively, andmaxi(Μ) a function that returns the index where themaximum value of Μ takes place, the algorithm steps inpseudo-code are1. Compute contour points pi = { xi, yi, θi}in TT T2. For each pairing { pi, pj} with θ i − θ j = ξ ,defT compute p = { α , d , r, r }ijTij ij i j3. For each p T ij increment O ( θi, αij)4. Repeat steps 1, 2, 3 for I to obtain p I ij ,ITdefp IijandOI T5. β = maxi( corr( O , O ))6. Rotate template contour pointsdefTpi = { xi, yi, θi+ β}7.T IFor each { pij, pkl} with θ i = θ k and α ij − α klincrement S ( dij, dkl)8. ς = maxi( S )9. Scale vectors in p Tij using ςT I10. For each { pij, pkl} with θ i = θ k and α ij − α kl,increment D (( xk, yk) + ri), D (( xk, yk) + rj),D (( x , y ) + r) and D (( x , y ) + r)11. ( )i i iδx, δ y = maxi( D )i i jB. Regular computation within the GHTEdge detection and correlation, applied in steps 1 and5 respectively, exhibit a regular parallelism, since asimple workload distribution guarantees a good loadJP2011-306

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2. Our implementation of the GHT: Stages in blue compute the O , S and D Hough spaces; stages in green compact and/or sort theworkloads of the kernels.balance, coalesced memory accesses and, consequently,good performance values. Edge detection is performedusing the widely known Canny algorithm [2]. Theversion of the Canny edge detector, used in this work,was developed by Gómez-Luna et al. [4].Correlation between O T and O I is implementedusing a separable convolution [12]. Correlation isapplied once per each possible rotation angle of thetemplate within the image. Finally, the functionmaxi(M), used in step 5 to obtain β , is performed by akernel which follows the optimizing strategies presentedin the CUDA parallel reduction [7].C. Irregular computation within the GHTComputation of O (steps 2-3), S (steps 6-7) and D(steps 9-10) Hough spaces is not regular. All thesestages have some common features as far as memoryaccesses and work distribution are concerned:• Computation of the three Hough spacesrequires some kind of features comparison,followed by some computation, among theelements of the corresponding input workload,as stated in steps 2, 7 and 10.• The features comparisons in steps 2, 7 and 10need a huge number of memory accesses,which seriously penalizes the performance. Bysorting the input workload, the number ofmemory accesses will be greatly reduced.• O , S and D Hough spaces are generatedduring a voting process. This entails the use ofatomic additions –in shared or global memory,depending on the size of the voting space–,which serialize the execution. In Section V, wepropose the replication of the Hough spaces, inorder to decrease the impact of serialization.Figure 2 shows a scheme of our implementation of theGHT, which is thoroughly described in Sections IV andV. Stages in blue correspond to kernels that perform thecomputation of the O Hough spaces (Search forpairings), the S Hough space (Scale calculation) andthe D Hough space (Displacement calculation). Stagesin green represent the primitives applied for regularizingthe problem by compacting and/or sorting the workloadsof the kernels.IV. EFFICIENT MEMORY ACCESS AND WORKDISTRIBUTIONIn this section, we detail how to re-organize theworkloads, in order to obtain an efficient computation ofthe Hough spaces on the GPU. Then, we propose twomechanisms for efficiently distributing the workloadsamong blocks and threads.A. Re-organizing the workload: compacting andsortingAn efficient implementation of the search for pairingsrequires the compaction of the whole set of contourpoints into a dense list. Thus, for each contour point inthe template or the image, a tuple p i composed of itsgradient direction θ i and its coordinates (x i , y i ) is storedinto a List of Template Edges (LTE) or a List of ImageEdges (LIE). The compact primitive returns a List ofEdges composed by three output arrays: one for thegradient directions and two for the coordinates. Thegradient directions are used to detect pairings and,together with the coordinates, are needed for computingthe angle α ij. The CUDPP library [3] includes acompact primitive based on the prefix sum or scanoperation, that we have used.As it is shown in Figure 2, the List of Edges is theworkload of the kernel that performs the search forpairings. It outputs a List of Template or Image Pairings(LTP or LIP), whose elements are tuples p ij , and aT Itemplate or image O Hough space ( O or O ). LTPand LIP are dense lists used as inputs for the scale andthe displacement calculations. Due to implementationconvenience, tuples p ij in a List of Pairings contain theindex of the pairing in the corresponding O Houghspace ( αθ _ index = αij× 90+ θi), the index of eachcontour point ( pk _ index = yk × width + xk, where widthis the width of the image) and the distance betweenthese paired contour points (d ij ).At this point, we propose a previous sorting of thedense lists, in order to minimize global memoryaccesses. In the search for pairings, the List of Edgescan be sorted by the quantized gradient direction. Then,given a certain value of the quantized gradient direction,this value plus the difference angle (ξ ) determines thepart of the List of Edges where the pairing points lie. Inthe scale and the displacement calculations, the Lists ofPairings are sorted by the αθ _ index , that is, pairingsare grouped in sub-lists with the same α and θ values.B. Work distribution among blocks and threadsIn this sub-section we present two mechanisms forworking with the created sorted lists. Both can beapplied to the search for pairings and to the scale anddisplacement calculations.As it is seen in Figure 2, computing stages (in blue)which generate the Hough spaces use sorted dense listsJP2011-307

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011as inputs. We assume that two lists (List1 and List2) arethe inputs to the computing stages. Specifically, LTPand LIP are List1 and List2 for scale and displacementcalculations and in the case of the search for pairings, aTemplate or Image List of Edges takes the role of bothList1 and List2.We consider a kernel, whose inputs are two dense lists(List1 and List2), which have been sorted by an index I.List1 and List2 are divided into sub-lists, in which everytuple has the same index. Each list has its own constantarray associated (Pointers array), in which the k thelement contains the position of the list where the sublistwith index I equal to k starts. Pointers arrays areplaced in constant memory or texture memory,depending on their size, since they are read-only data.Each block takes one chunk of List1, belonging to asub-list with a certain index I 1 , and loads it in sharedmemory. Each thread loads just one tuple of the chunk,thus the size of the chunk is at most the number ofthreads in a block. Then, the block performs an iterativeprocess with an outer and an inner loop. The outer loopaccesses those chunks of List2, which belong to the sublistwith an index I 2 that fulfills a certain condition withrespect to the index I 1 . The inner loop distributes thework among the threads, which perform somecomputation using one tuple from List1 and anotherfrom List2. The following code summarizes this process:Load chunk of List1 sub-list with I1 in sharedmemory;I2 = function of I1;// Outer loop:For (each chunk of sub-list with I2 of List2)Load chunk in shared memory or registers;// Inner loop:For (depending on mechanism)// Compare and compute:If (Features comparison)Computation(tuple List1,tuple List2);Work distribution within the inner loop can be done intwo ways that are explained next: the first one achievesan optimal load balancing, while the second one focuseson increasing occupancy of the multi-processors.1) Load-balancing (LB) mechanismA load-balancing work distribution must ensure thatevery thread will perform the same number of featurescomparisons or, in other words, the same number ofiterations of the inner loop. The red chunk in Figure 3contains n tuples and the blue chunk contains m. Valuesn and m are less or equal to the number of threads in theblock (block_size). Thus, the number of comparisons isn× m. Thread N performs the N th comparison, the N th +block_size, and so on. This mechanism requires thatevery tuple of the chunk of List2 is available for everythread. Thus, the chunk of List2 is loaded in sharedmemory.2) Save-shared-memory (SSM) mechanismAlthough the former mechanism ensures an optimalload balancing, it requires loading two chunks in sharedmemory. Unfortunately, the occupancy is determined bythe amount of shared memory and registers used by eachthread block, thus load balancing can affect negativelythe efficiency. We propose a new mechanism, SSM,which saves shared memory to increase occupancy.This mechanism, as it can be seen in Figure 4, assignsone tuple of the chunk of List2 to one thread, so thateach thread loads only its tuple in registers. Then, thethread performs the comparisons between its tuple andall the tuples of the chunk of List1. Since usually thenumber of tuples with the same index I is not a multipleof the block size, there will be idle threads in the innerloop. Nevertheless, we expect a good performance dueto the increase of occupancy.V. REPLICATION OF THE VOTING SPACEImplementations of the three stages have also incommon the fact that they perform a voting process,which is the generation of some kind of histogram.Since voting operations entail unpredictable memoryaccesses, efficient implementations use several copies orsub-histograms, in order to reduce conflicts amongthreads, while updating the histogram bins.The CUDA SDK implementations of 64- and 256-binshistograms [11] use, respectively, per-thread and perwarpsub-histograms, which are lied in shared memory.At the end of the process, all the sub-histograms aremerged into a single histogram in global memory.However, the use of per-thread sub-histograms is limitedto those cases in which the number of bins of thehistogram is very small. On the other hand, thedrawback of per-warp sub-histograms, with respect toper-thread, is the use of atomic additions in sharedmemory. Since every thread, belonging to a half-warp,tries to access the same sub-histogram at the same time,serialization is unavoidable.For both reasons, we propose the use of replicated subhistogramsper block in shared memory. Threads of eachblock access more than one sub-histogram. If M subhistogramsper block are declared, thread number Naccesses sub-histogram N%M, where % stands for theoperation modulo. This represents an improvement withrespect to per-warp sub-histograms, since consecutivethreads, belonging to the same warp, access differentsub-histograms, reducing serialization due to atomicadditions. There will be an optimal value of M, whichrepresents a trade-off between reducing serialization,when using atomic additions, and preserving a goodvalue of occupancy.Replication is also useful in global memory, in order toreduce serialization while using atomic functions. In thecase of the displacement calculation, since the DHough space does not fit in shared memory, the wholevoting space is replicated in global memory.VI. EXPERIMENTAL RESULTSIn this section, a thorough analysis of theimprovements achieved by the proposed techniques iscarried out. In addition, the impact of theseimprovements in the final performance of the GHT isevaluated. Thus, we have analyzed the impact of theirregular stages in the total execution times as they arethe most time-consuming ones in the GHT. In fact,computation of O , S and D Hough spaces requiremore than 90% of the execution time while Cannydetection, rotation calculation, compacting and sortinghave negligible execution times. Tests have been madeon a GeForce GTX 280 GPU.JP2011-308

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Load-balancing mechanism: Each thread performs approximately the same number of features comparisons, represented by blackarrows. For the sake of clarity, blocks of 8 threads are represented.Fig. 4. Save-shared-memory mechanism: Each thread performs the features comparisons of one tuple, as indicated by the black arrows.Although the GHT was originally designed to detectarbitrary shapes in two-dimensional images, it can beeasily applied to video processing [13]. We haveselected this real application for the experiments becausevideos provide an assorted database of images to test ourimprovements, especially when the chosen videosbelong to different genres. In Table I the workloads ofthe four videos used in the experiments are shown.These videos have been selected from the MPEG-7Content Set.TABLE ITEST WORKLOADS CHARACTERISTICS. VIDEOS HAVE A RESOLUTIONOF 352× 288 PIXELS. NUMBER OF EDGE POINTS AND PAIRINGS AREAVERAGE VALUES. EACH VIDEO IS CONSISTING IN 4000 FRAMESVideo Edge points Pairings (ξ = 90º)Cycling 2778 78770Movie 1436 13332Basket 5061 140030Drama 2684 54921tuples per sub-list, so that the number of chunks in asub-list changes between 1 and 6.In the case of SSM, the saving of shared memorypermits 5 blocks of 128 threads per multi-processor, onemore than LB. On the other hand, LB guarantees anoptimal load balancing, while SSM will have idlethreads in the last block assigned to a sub-list. Usingblocks of 128 threads, if each sub-list contains T tuples,this last block have only T%128 active threads.A. An exhaustive comparison between the loadbalancingand the save-shared-memory mechanismsWe are not able to assert which of the mechanisms isbetter, since both have their own strong points. For thisreason, we have compared both mechanisms changingthe size and data distribution of a sorted list. Withoutloss of generality, we have used a synthetic sorted list,equally divided among sub-lists with different indexvalues. Each element of the synthetic sorted listemulates a tuple. Since each block works with chunksbelonging to a sub-list, we have changed the number ofFig. 5. Comparison between SSM and LB using a synthetic sorted list.The number of blocks assigned to a sub-list has been changedfrom 1 to 6, as the abscissas showsWe have carried out 55 tests of the SSM and LBmechanisms, changing the number of tuples of the sublists.Figure 5 presents the execution results for thesetests. Abscissas represent the number of 128-tupleschunks per sub-list, which is also the number of blocksworking with the same sub-list. The graph on the topshows the ratio between the execution times of LB andSSM. Values above 1 mean the SSM mechanism runsJP2011-309

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE II.AVERAGE EXECUTION TIMES (MS) OF THE MAIN PARTS OF THE APPLICATION FOR FOUR VIDEOS. THE NUMBER BESIDE THE NAME OF THESTRATEGY REPRESENTS THE REPLICATION FACTOR.Video CannySearch for pairingsScaleDisplacementOrientationLB(1) SSM(2) LB(8) SSM(16) LB(64) SSM(64)Cycling 0.45 1.78 1.66 5.68 86.53 53.10 265.02 210.09Movie 0.46 0.28 0.63 5.66 20.13 18.37 29.93 22.29Basket 0.46 1.13 1.36 5.68 102.38 83.83 198.09 152.28Drama 0.46 0.67 0.99 5.66 49.31 42.00 85.17 60.07faster. The graph on the bottom shows two columns foreach test. The left column (yellow), called “%Lastblock”, represents the percentage of active threads in thelast block assigned to a sub-list, in SSM. The rightcolumn (green), called “%GPU”, stands for thepercentage of active threads in the whole GPU, in SSM.The higher these values the better is the distribution ofthe workload in SSM. Thus, both columns give a hint ofthe computational load balance of SSM.For a number of blocks per sub-list between 1 and 4,there exists a value of “%Last block” which determinesthat the SSM mechanism outperforms the LB onebecause the impact of load unbalance is less importantthan the occupancy value. When the number of blocksper sub-list is 5 or more, the SSM mechanism alwaysperforms better due to the higher occupancy, whichpermits to execute more blocks simultaneously.B. Replication for the generation of Hough spacesIn the search for pairings, the case with 2 replicatedsub-histograms results in 13% improvement with respectto the per-warp approach.The size of the S Hough space is not critical foroccupancy. Such a small size permits to attempt evensub-histograms per thread. The best case is a per blockreplication of 16. It works 28% faster than the per-warpapproach and 109% faster than the per-thread approach.Displacement calculation replicates the D Houghspace in global memory. The best approach is withreplication of 64, obtaining a speedup of 3.2 with respectto the version without replication.C. Comparison among implementationsThe execution times of the different implementationsof the main parts of the application are shown in TableII. Results reflect that the search for pairings performsbetter using the LB mechanism in three of the fourvideos. This makes sense with the conclusions presentedin sub-section VI.A because the size of the sub-lists issmall. If the number of tuples increases, the percentageof idle threads decreases for SSM. In this way, its loadbalancing improves and the occupancy becomes moredecisive. This explains that SSM outperforms LB forscale and displacement calculations, since the Lists ofPairings are much longer than the Lists of Edges.VII. CONCLUSIONSThis work has studied how load balancing andoccupancy impact the performance of an application ona GPU using the CUDA environment. This analysis hasbeen carried out through the parallelization of the FastGeneralized Hough Transform (Fast GHT).We have implemented and compared two generalparallelization strategies. One, called Load Balancing(LB), tries to obtain an optimum load balancing. Anotherone, called Saved Shared Memory (SSM), tries tomaximize processor occupancy by reducing data loadedin shared memory. Results show the SSM mechanismoutperforms the LB one when there is enough input datafor every simultaneous block in the GPU. We have alsominimized the impact of divergent execution paths bycompacting and sorting the input data.Memory accesses conflicts have been addressed in twoways depending on if they were read or write accesses.Read accesses to global memory have been minimizedby sorting input data. Unpredictable write accesses canseriously reduce the performance due to memory bankconflicts and serialization, but by replicating the writearea these conflicts are minimized. We have proposed anew technique that replicates in shared memory data perblock and compared it with the common strategy ofreplicating per warp, obtaining a better performance.Voting spaces are also replicated in global memory withsuccessful results.REFERENCES[1] Ballard, D.H. (1981). Generalizing the Hough transform to detectarbitrary shapes. Pattern Recognition 13 (2): 111-122.[2] Canny, J. (1986). A computational approach to edge detection.IEEE Transactions on Pattern Analysis and Machine Intelligence8 (6): 679-698.[3] CUDPP (2010). CUDA Data Parallel Primitives Library homepage. http://code.google.com/p/cudpp[4] Gómez-Luna, J., González-Linares, J.M., Benavides, J.I. and Guil,N. (2009). Parallelization of a video segmentation algorithm onCUDA-enabled Graphics Processing Units. In proceedings of 15thInternational Euro-Par Conference (Euro-Par’09), pp. 924-935.[5] Green, S. (2007). CUDA particles.http://developer.nvidia.com/object/cuda_sdk_samples.html[6] Guil, N., González-Linares, J.M. and Zapata, E.L. (1999).Bidimensional shape detection using an invariant approach.Pattern Recognition 32 (6): 1025-1038.[7] Harris, M. (2007). Optimizing parallel reduction in CUDA.http://developer.nvidia.com/object/cuda_sdk_samples.html[8] Hough, P.V.C. (1962). Method and means for recognizingcomplex patterns. U.S. Patent 3069654.[9] NVIDIA (2007). NVIDIA CUDA home page.http://www.nvidia.com/cuda[10] OpenCL (2009). OpenCL home page.http://www.khronos.org/opencl[11] Podlozhnyuk, V. (2007a). Histogram calculation in CUDA.http://developer.nvidia.com/object/cuda_sdk_samples.html[12] Podlozhnyuk, V. (2007b). Image convolution with CUDA.http://developer.nvidia.com/object/cuda_sdk_samples.html[13] Sáez, E., González-Linares, J.M., Palomares, J.M., Benavides, J.I.and Guil, N. (2003a). New edge-based feature extractionalgorithm for video segmentation. In proceedings of Image andVideo Communications and Processing (SPIE’03), pp. 861-872.JP2011-310

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011rCUDA: Uso Concurrente de DispositivosCompatibles con CUDA de Forma Remota.Adaptación a CUDA 4Carlos Reaño, Antonio J. Peña, Federico Silla y José Duato 1Rafael Mayo y Enrique S. Quintana-Ortí 2Resumen—Las mejoras realizadas en las GPUs (GraphicsProcessor Units) en la última década han propiciado queéstas sean utilizadas para incrementar el rendimiento enlos sistemas de computación de altas prestaciones. A esterespecto, NVIDIA viene desarrollando desde 2007 unanueva tecnología denominada CUDA (Compute UnifiedDevice Architecture) que permite descargar en la GPU granparte de los cómputos de la aplicación. En general, elprincipal inconveniente de esta tendencia es el aumento deenergía que introducen las GPUs. Si, además, tenemos encuenta que en este tipo de sistemas no se suelen utilizartodos los recursos de las mismas, compartirlas seríabeneficioso en ambos sentidos: menor consumo y mayorutilización. Con el objetivo de proporcionar una soluciónbajo estas premisas nace rCUDA, un marco de trabajo quepermite el uso concurrente de dispositivos CUDA de formaremota.Este artículo describe las experiencias y conclusionesextraídas durante la primera fase de adaptación de rCUDAdesde la versión 3 de CUDA a la nueva versión 4.Palabras clave—CUDA, computación de altasprestaciones, aceleración basada en GPUs, virtualización,clústeres, ahorro de energía.EI. INTRODUCCIÓNN la actualidad, debido a la creciente demanda derequisitos que se les viene exigiendo a las GPUs, sehan realizado grandes avances en el desarrollo de lasmismas, dando lugar a dispositivos con mayor podercomputacional y mayor ancho de banda de memoria quelas CPUs actuales [1]. En las Figuras 1 y 2 podemos vergráficamente una comparativa de dichas característicasentre GPUs NVIDIA y CPUs Intel.La Figura 1 nos muestra cómo mediante el uso de GPUses posible obtener, en algunos casos, una tasa teórica deoperaciones en coma flotante por segundo hasta casi 8veces superior a la de las CPUs más potentes en el año2010. En la Figura 2, por su parte, vemos cómo el anchode banda de memoria teórico de las GPUs sextuplicaba,en el mismo año, al de las CPUs, a pesar de lascrecientes mejoras que estas últimas introducenpaulatinamente para incrementar éste.Figura 2. Ancho de banda de la memoria en CPUs y GPUs.Esta gran potencia de cálculo, junto con la eficiencia enel acceso a memoria, ha motivado la utilización deGPUs en ámbitos distintos a aquellos para los queinicialmente fueron diseñadas: son las llamadas tareas depropósito general, derivando todo ello en la denominadacomputación GPU o GPGPU (General PurposeComputing on GPU). Cabe destacar, en cualquier caso,que las GPUs no son un reemplazo de las CPUs, dadoque solo son útiles para determinados tipos deproblemas en los que la misma operación es aplicadasobre una gran cantidad de datos y con un patrón deacceso determinado.Por otra parte, debido principalmente al gran volumende negocio generado por la industria del videojuego, lasGPUs se han convertido en dispositivos de relativamentebajo coste, proporcionando una potencia de cómputoextraordinaria para la inversión que suponen.Figura 1. Operaciones en coma flotante por segundo en CPUs y GPUs.1 DISCA, Universitat Politècnica de València (UPV), e-mails:{carregon, apenya}@gap.upv.es, {fsilla, jduato}@disca.upv.es.2 DICC, Universitat Jaume I (UJI), e-mails: {mayo, quintana}@icc.uji.es.Todo ello ha provocado que en la actualidad los grandesclústeres de computadores de altas prestaciones seinclinen hacia la utilización de estos dispositivos comouna vía para acelerar determinadas partes del código delas aplicaciones a las que prestan servicio. La propuestade NVIDIA en este sentido es CUDA: una arquitecturaJP2011-311

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de computación paralela que aprovecha la potencia de laGPU para aumentar considerablemente el rendimientode los cálculos, quitándole carga de trabajo a la CPU, lacual puede, de esta manera, dedicarse a otras tareas.Sin embargo, dentro del contexto de la computación dealtas prestaciones, las GPUs presentan el inconvenientedel consumo de energía, el cual puede incrementarsenotablemente con su uso. Si a ello le unimos el hecho deque las aplicaciones en general no suelen utilizar todoslos recursos de las GPUs al completo, compartir GPUsentre varios nodos del clúster parece una solución muyapropiada. A modo de ejemplo, si una aplicación utilizaúnicamente la GPU el 25% del tiempo, podría pensarseen compartir una GPU entre cuatro nodos del clúster.Este principio motiva la aparición de rCUDA (remoteCUDA) [2]. rCUDA es un marco de trabajo para lautilización concurrente de GPUs compatibles conCUDA de forma remota. Dicho marco se basa en lacreación de dispositivos virtuales compatibles conCUDA en aquellos nodos que no poseen una GPU local.Estos dispositivos virtuales representan GPUsfísicamente localizadas en nodos remotos, los cualesofrecen servicios GPGPU. De esta forma, todos losnodos de un mismo clúster pueden beneficiarse de lasGPUs, independientemente de en qué nodos seencuentren éstas físicamente. Al mismo tiempo, sereduce la desventaja, en cuanto a consumo energético serefiere, de introducir una GPU por nodo y se aumenta lautilización de las mismas, haciendo más rentable lainversión económica.La última versión estable de rCUDA da soporte a laversión 3 de CUDA. No obstante, en el mes de mayo de2011 ha sido publicada una nueva versión de CUDA, la4, lo cual ha hecho necesaria una adaptación de la actualimplementación de rCUDA. Una vez finalizada laprimera fase de dicha adaptación, exponemos en elpresente artículo las tareas realizadas, las conclusionesobtenidas y el trabajo pendiente para futuras fases.El resto del artículo está organizado de la siguienteforma: en la sección II describiremos el marco de trabajorCUDA; en la sección III expondremos las diferenciasmás destacables entre las versiones de CUDA 3 y 4; enla sección IV comentaremos las experiencias extraídasdurante la primera fase de adaptación de rCUDA a lanueva versión de CUDA 4; finalmente, en la sección Vcomentaremos las conclusiones obtenidas tras el trabajorealizado y en la sección VI posibles tareas a realizar enel futuro.II. RCUDA: REMOTE CUDATal y como hemos comentado, rCUDA permite el usoconcurrente de GPUs compatibles con CUDA de formaremota. Así, cada nodo en un clúster puede utilizar losaceleradores compatibles con CUDA instalados encualquier nodo del mismo.La arquitectura de rCUDA [2, 3] consiste en un sistemadistribuido cliente-servidor, tal y como podemos ver enla Figura 3.Figura 3. Arquitectura de rCUDA.Desde el punto de vista de los nodos cliente, las GPUsremotas son dispositivos virtuales a los que es posibletener acceso de la misma forma que si éstas estuvieranconectadas directamente en su puerto PCIe (PeripheralComponent Interconnect Express). De hecho, lasaplicaciones no son conscientes de que la GPU a la queestán accediendo no es un dispositivo real sino virtual.Ello es posible gracias a una biblioteca que reemplaza labiblioteca original del Runtime API de CUDA,manteniendo los prototipos de las funciones peroredefiniendo su implementación para que, básicamente,las llamadas a la API de CUDA sean redirigidas al nodoen el que físicamente se encuentra la tarjeta gráfica oacelerador.El servidor, por su parte, es un demonio que se ejecutaen aquellos nodos que ofrecen servicios de aceleraciónGPGPU, es decir, en los nodos con GPU física. Seencarga de recibir, interpretar y ejecutar las peticionesrealizadas por la aplicación a través del cliente remoto.Para cada ejecución remota, un nuevo proceso servidores creado para atender todas las peticiones de un mismocliente y ejecutarlas en un contexto de GPUindependiente. Esto permite, en caso de error fatal(violación de acceso a memoria) en uno de los procesosservidor, la continuidad del resto de procesos, adiferencia de lo que ocurriría en un entorno multi-hilo.La comunicación entre cliente y servidor es llevada acabo mediante la utilización de la API de sockets TCP,aunque para optimizar el intercambio de datos a travésde la red se ha desarrollado un protocolo decomunicación a nivel de aplicación altamenteoptimizado [4].En general, la virtualización de servicios en rCUDAconsiste en redirigir las llamadas de la API de CUDA alnodo con la GPU, como hemos comentado. Este procesoresulta, a grandes rasgos, sencillo de implementar. Noobstante, este no es el caso de las transferenciasasíncronas, las cuales requieren introducir lógicaadicional de mayor complejidad. A continuacióndescribimos este tipo de transferencias másdetalladamente.La complejidad de las transferencias asíncronas radica,fundamentalmente, en dos aspectos:1. Requieren el uso de memoria no paginable.2. Pueden estar asociadas a un stream (secuenciade operaciones que se ejecutan de formaordenada, pero que pueden ejecutarseconcurrentemente o de forma desordenadarespecto a otros streams).JP2011-312

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Para implementar este tipo de servicios se ha optado poruna planificación ―round-robin‖ para tratar el conjuntode streams, y por una estructura FIFO (First In, FirstOut) para tratar las operaciones dentro de un mismostream. Podemos verlo de forma esquemática en laFigura 4.• Código a ejecutar en la GPU, se compilaráempleando la herramienta ―nvcc‖proporcionada por NVIDIA [5].• Código a ejecutar en la máquina, se compilarácon un compilador C/C++ nativo (p. ej. GNUgcc).Podemos encontrar información más detallada respectoa este último punto en [2].Figura 4. Tratamiento de operaciones asíncronas.Cuando el cliente recibe una petición de transferenciaasíncrona, ésta se programa y se retorna el control de laejecución al peticionario. Esto puede ocurrir antes deque la transferencia se haya completado o inclusoiniciado. En función de si el origen y el destino son lamáquina local o la GPU de la máquina remota, podemosclasificar las transferencias asíncronas en los siguientestipos (origen – destino):• Máquina local – máquina local. No implica aldispositivo remoto, por lo que es implementadacomo una operación local.• Máquina local – GPU remota. Una vez todaslas transferencias del dispositivo remoto alcliente dentro del stream han finalizado, serealiza una petición de transferencia al servidory se le envían los datos.• GPU remota – máquina local. Directamente serealiza una petición de transferencia aldispositivo remoto, el cual gestionará cuándo sepuede llevar a cabo la misma. Posteriormente,los datos serán enviados al cliente de formaasíncrona.• GPU remota – GPU remota. Similar al casoanterior con la diferencia de que no se envíandatos al cliente.Así pues, las únicas tareas pendientes tras la ejecuciónde una operación asíncrona son la recepción de los datosresultantes de las transferencias de la GPU remota a lamáquina local. Por esta razón, aquellas transferenciascuyo origen de memoria sea un puntero en la máquinalocal deben esperar a las operaciones pendientes paracompletarse. Para gestionar estas operaciones de formaasíncrona, y permitir así la recepción de datos síncronosy asíncronos por el mismo socket, el cliente utiliza unhilo Posix dedicado y sincronizado con el hilo principalde la ejecución y con el hilo de recepción.De forma similar, existe un hilo de envío en el servidorpara multiplexar el socket y permitir así el envío dedatos tanto síncrono como asíncrono.Por último, comentar que rCUDA sólo soporta la API deC plano y no es posible utilizar extensiones CUDA.Además, el código de las aplicaciones se debe dividiren:III. CUDA 3 Y CUDA 4El desarrollo de CUDA está divido en módulos queagrupan funcionalidades relacionadas entre sí [6].Algunos módulos que ya existían en la versión 3 deCUDA y a los cuales haremos referencia en este artículoson:• Módulo ―Device Management‖: formado porlas funciones que permiten gestionar lasdistintas características de los dispositivosCUDA.• Módulo ―Thread Management‖: permite lagestión de hilos en aplicaciones que utilicenCUDA.• Módulo ―Memory Management‖: contiene lasfunciones necesarias para operar tanto con lamemoria del sistema como con la memoria delas GPUs.También haremos referencia a la biblioteca CUBLAS[7], una implementación de BLAS (Basic LinearAlgebra Subprograms) sobre CUDA proporcionada porNVIDIA.En lo referente a las nuevas características que introducela nueva versión de CUDA con respecto a su anteriorversión 3, quizá la funcionalidad más destacable sea lareferida a la comunicación entre GPUs (NVIDIAGPUDirect v2.0) y al direccionamiento virtual unificadoo Unified Virtual Addressing (UVA) [1, 6]. Acontinuación introduciremos cada uno de ellos, así comootras diferencias reseñables.A. NVIDIA GPUDirect v2.0La versión 2.0 de NVIDIA GPUDirect proporcionanuevas funcionalidades (nuevo módulo ―Peer DeviceMemory Access‖) que permiten la comunicación directaentre dispositivos compatibles con CUDA: acceso amemoria, transferencias y sincronización entre losmismos. Por ejemplo, en la versión anterior de CUDA, ala hora de realizar transferencias de memoria entre dosGPUs instaladas en una misma máquina, era necesariorealizar una copia intermedia en la memoria de la CPU.Sin embargo, ahora es posible realizar transferenciasdirectas entre ambas. Podemos visualizar gráficamenteesta nueva característica en las Figuras 5 y 6.Esta característica sólo es soportada por tarjetas gráficasNVIDIA de la serie Tesla 20 en aplicaciones de 64 bitsbajo sistemas operativos Linux y Windows. En el casode Windows también es necesario tener instalado eldriver TCC (Tesla Computer Cluster) diseñado paranodos que disponen de más de un producto Teslainstalado.JP2011-313

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011del cual una GPU accede a su memoria es el mismo parael resto de GPUs conectadas a la misma máquina.Al igual que ocurría con NVIDIA GPUDirect 2.0, UVAsólo es soportada por tarjetas gráficas NVIDIA de laserie Tesla 20 en aplicaciones de 64 bits bajo sistemasoperativos Linux y Windows con el driver TCCinstalado.Figura 5. Transferencia de memoria entre GPUs en CUDA 3.Figura 6. Transferencia de memoria entre GPUs en CUDA 4.B. Unified Virtual Addressing (UVA)La nueva versión 4 de CUDA proporcionadireccionamiento virtual unificado (nuevo módulo―Unified Addressing‖), el cual permite un marco detrabajo con un único espacio de direcciones para todaslas memorias de las distintas CPUs y GPUs en unmismo computador. En las Figuras 7 y 8 mostramos deforma visual dicha característica.Figura 7. Espacio de memoria sin UVA.Figura 8. Espacio de memoria con UVA.Cabe destacar que con la utilización de UVA, lastransferencias directas entre GPUs que permite NVIDIAGPUDirect v2.0 funcionan de forma transparente, sin sernecesario especificar las GPUs de origen y destino. Ellose debe a que en estos casos el valor del puntero a travésC. Otras diferenciasOtro de los aspectos que introduce la nueva versión esuna mayor facilidad a la hora de utilizar aceleraciónCUDA en las aplicaciones existentes, de tal forma que altratar con espacios de memoria no paginable del sistema,ya no son necesarias reservas de memoria ni copiasadicionales en el entorno CUDA. Por ejemplo, antes eranecesario seguir los siguientes pasos:1. Reservar memoria en CPU (#1).2. Reservar memoria en CPU para que seaaccesible por la GPU (#2).3. Copiar memoria #1 a memoria #2.4. Aplicar aceleración CUDA.5. Copiar memoria #2 a memoria #1.6. Liberar memoria #2.Mientras que ahora es posible ―registrar‖ un espacio dememoria de la CPU para que sea utilizado por la GPU y―desregistrarlo‖ al finalizar la aceleración CUDA:1. Reservar memoria en CPU (#1).2. Registrar memoria #1 para que sea accesiblepor la GPU.3. Aplicar aceleración CUDA.4. Desregistrar memoria #1.Algunas características que también cabe destacar sonlas siguientes:• Posibilidad de compartir GPUs entre múltipleshilos y de acceder a todas las GPUs desde unmismo hilo.• En la versión anterior de CUDA existía laposibilidad de generar el código relativo a unaGPU en un repositorio externo, de forma quepara cada versión compilada con unadeterminada arquitectura se generaba unmódulo diferente. En la nueva versión deCUDA existe la posibilidad de agrupar en unmismo módulo código para diferentesarquitecturas [5], son los llamados ―fatbin‖ (fatbinary).• Respecto a la biblioteca CUBLAS, seproporciona una nueva API que permiteoptimizar el paralelismo entre streams y lasllamadas concurrentes a CUBLAS desdemúltiples hilos.Los cambios referentes a los módulos deinteroperabilidad entre gráficos no los comentaremospuesto que, por el momento, no son objeto del marco detrabajo de rCUDA.IV. ADAPTACIÓN DE RCUDA A CUDA 4En esta sección presentaremos las tareas realizadas y losproblemas encontrados durante el proceso de adaptaciónJP2011-314

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de rCUDA a CUDA 4.En primer lugar, se han realizado las modificacionesnecesarias para que el marco de trabajo de rCUDA fueraoperativo bajo la nueva versión de CUDA. Estasmodificaciones han consistido, básicamente, en laimplementación de la carga de módulos a partir defatbins, puesto que la versión actual de rCUDA utilizalos repositorios externos con el código de losdispositivos comentados en la sección anterior. Lautilización de fatbins tiene la ventaja de que es posibleincluir en un mismo módulo código de un mismodispositivo compilado y optimizado para diferentesarquitecturas, siendo CUDA quién seleccione la versiónmás apropiada.Seguidamente, se han implementado las nuevasfuncionalidades de los distintos módulos que resultabantriviales o con poca complejidad:• Módulo ―Device Management‖: se hanimplementado las funciones que anteriormentese encontraban en el módulo ―ThreadManagement‖ y se han codificado las funcionespara las que no se daba soporte en la anteriorversión de rCUDA.• Módulo ―Memory Management‖: se hancodificado las funciones necesarias pararegistrar/desregistrar memoria de la CPU en elsistema CUDA, así como algunas funcionesasíncronas de inicialización de regiones dememoria de GPU para las que no se dabasoporte en la anterior versión de rCUDA.• Biblioteca CUBLAS: las funciones soportadaspor la antigua versión de rCUDA han sidoadaptadas a la nueva API de dicha biblioteca,manteniendo compatibilidad con la versiónanterior.Cómo se ha comentado en la sección II, rCUDA sólosoporta la API de C plano y también es necesariocompilar el código a ejecutar en la GPU por separado.Así, rCUDA dispone de una SDK similar a la de CUDApero con dichas modificaciones. La siguiente tarea arealizar ha consistido en actualizar los ejemplos de laSDK de rCUDA según los cambios realizados en lapropia SDK de CUDA 4, con el fin de testear el correctofuncionamiento de rCUDA tras las modificacionesrealizadas.Llegados a este punto, restan por implementar lassiguientes características de CUDA 4:• Módulo ―Memory Management‖: nuevasfunciones que permiten la copia de memoriaentre GPUs, tanto de forma síncrona comoasíncrona.• Módulo ―Peer Device Memory Access‖: nuevomódulo para dar soporte a las mejorasintroducidas por la nueva versión 2.0 deNVIDIA GPUDirect, descritas en apartadosanteriores.• Módulo ―Unified Addressing‖: nuevo módulointroducido como consecuencia deldireccionamiento virtual unificado (UVA),también comentado en secciones previas.La adaptación de rCUDA para soportar lascaracterísticas comentadas anteriormente es bastantecompleja teniendo en cuenta la actual implementacióndel propio rCUDA, por lo que requiere de un estudioprevio más profundo que detallamos en la siguientesubsección.A. NVIDIA GPUDirect v2.0 y UVATal y como hemos comentado, rCUDA está pensado,principalmente, para clústeres de computadores de altasprestaciones donde sólo algunos nodos dispondrán deGPU. De esta forma, un nodo podrá acceder a todas lasGPUs de un clúster de la misma manera que si éstasestuvieran físicamente en dicho nodo. Si a ello leañadimos el hecho de que, potencialmente, cada GPUestará en un nodo distinto, el poder realizarcomunicaciones entre distintas GPUs y, además,disponer de un espacio de direccionamiento virtualunificado para todas las GPUs y la CPU del nodocliente, se convierte en un reto mayor que en el casocontemplado en CUDA, tal y como explicaremos acontinuación. En la Figura 9 tratamos de ilustrar estaproblemática.Figura 9. Problemática en la adaptación de rCUDA a CUDA 4.Por un lado, el ofrecer de forma transparente a un nodocliente comunicación directa entre las GPUs a las quetiene acceso en diversos nodos, gracias a rCUDA, vamás allá de las características de CUDA, ya que estaúltima asume que los dispositivos siempre estaránconectados a un mismo nodo. La misma argumentaciónpuede ser utilizada en el caso de querer soportar unespacio de direccionamiento virtual unificado.Por otro lado, rCUDA tiene la limitación de que cadaproceso servidor gestiona únicamente un dispositivo, locual presenta una dificultad añadida.Actualmente, en el proyecto de rCUDA nosencontramos en una fase de análisis sobre cómo resolveresta situación.Entre las soluciones que se están barajando, pareceevidente que una solución final que dé soporte a estasfunciones deberá utilizar un protocolo de comunicaciónentre los procesos servidores, aunque la duda radica ensi disponer de un servidor maestro que realice unagestión global o no. Además, todo indica que seránecesario implementar un mecanismo de señales juntocon regiones de memoria compartida para permitir lacomunicación de servidores dentro de un mismo nodo.JP2011-315

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Esto último podría permitir también resolver unalimitación actual de rCUDA según la cual no es posibleel uso de memoria mapeada (característica llamadazero-copy).Otro punto de vista totalmente opuesto podría ser el nodar soporte a dichas características ya que, como se haindicado previamente, el hecho de que las GPUs esténen diferentes nodos conlleva que estas funcionalidadesno sean las propias de CUDA.Una tercera perspectiva podría ser una soluciónintermedia entre las dos explicadas anteriormente, esdecir, asumiendo que si las GPUs están en máquinasdiferentes no es posible aprovechar al completo lasventajas comentadas de la nueva versión de CUDA,tratar de implementar internamente las nuevasfuncionalidades utilizando las herramientas queproporciona CUDA de forma transparente al usuario.Por ejemplo, como hemos señalado en seccionesprevias, en la nueva versión de CUDA es posiblerealizar copias directas de memoria entre GPUs.Internamente, rCUDA podría dividir dicha operación endos:1. Copia desde la memoria de la GPU origen a lamemoria de la CPU.2. Copia desde la memoria de la CPU a lamemoria de la GPU destino.Esto es, realizar la copia del mismo modo que se haríaen la versión anterior de CUDA, pero de formatransparente al usuario. Esta solución sería ventajosa envarios aspectos. Por un lado, la conversión deaplicaciones de CUDA a rCUDA no requeriría cambiosde código en este sentido. Por otro lado, se estaríaalcanzando uno de los objetivos que pretendían lasnuevas funcionalidades: reducir el código de lasaplicaciones con el consecuente aumento de laproductividad.No obstante, tal y como hemos comentadoanteriormente, éstas y otras cuestiones aún están siendodebatidas y analizadas dentro del proyecto, por lo queaún no se ha alcanzado una decisión definitiva alrespecto.V. CONCLUSIONESEn el presente artículo hemos expuesto los pasosllevados a cabo en la primera fase del proceso deadaptación del marco de trabajo de rCUDA a la nuevaversión 4 de CUDA.Tras finalizar esta primera fase, disponemos de unmarco de trabajo estable pero al que aún le restan porresolver dos aspectos fundamentales introducidos en lanueva versión de CUDA:1. Comunicación directa entre GPUs.2. Espacio de direccionamiento virtual unificadopara las memorias de las GPUs y de la CPU.Actualmente dichos aspectos se encuentran en fase deanálisis y todavía no se ha alcanzado una solucióndefinitiva.VI. TRABAJO FUTUROEntre las posibles tareas a desarrollar en el futuro,además de resolver la problemática comentada ensecciones anteriores, cabe destacar las siguientes:• Portabilidad de rCUDA a sistemas operativosWindows (actualmente únicamente soportasistemas operativos Linux).• Desarrollo de una arquitectura decomunicaciones segmentada que permita elaumento de las prestaciones de rCUDA alaumentar el ancho de banda efectivo entrecliente y servidor.• Soporte nativo para la tecnología InfiniBand [8]que permita evitar el uso de sockets TCP/IP.Este soporte permitiría el uso de rCUDA enmultitud de clústeres que incluyen esta red dealtas prestaciones en lugar de usar Ethernet.• Soporte nativo para la tecnología decomunicaciones en clústeres EXTOLL [9], queproporciona un interfaz de memoria compartiday un interfaz de paso de mensajes muy eficientepara fines tales como compatibilidad conaplicaciones MPI (Message Passing Interface),que podría utilizarse para el envío y recepciónde los mensajes generados por rCUDA.AGRADECIMIENTOSEl personal de la UPV ha sido subvencionado bien porel programa PROMETEO de la Generalitat Valenciana(GVA) bajo el acuerdo PROMETEO/2008/060, o bienpor el Ministerio de Educación (MEC) y el Ministerio deCiencia e Innovación (MICINN) de España bajo elacuerdo CONSOLIDER INGENIO CSD2006-00046. Elpersonal de la UJI, por su parte, ha sido financiado porel Ministerio de Ciencia español, el programa FEDER(número de contrato TIN2008- 06570-C04) y laFundación Caixa-Castelló Bancaixa (contrato númeroP1-1B2009-35).REFERENCIAS[1] NVIDIA, ―NVIDIA CUDA C Programming Guide Version 4.0‖,NVIDIA, 2011.[2] J. Duato, F. D. Igual, R. Mayo, A. J. Peña, E. S. Quintana-Ortí, yF. Silla, ―An Efficient Implementation of GPU Virtualization inHigh Performance Clusters‖, Euro-Par 2009, Parallel Processing— Workshops, vol. 6043 Lecture Notes in Computer Science, p.385–394. Springer-Verlag, 2010.[3] J. Duato, A. J. Peña, F. Silla, R. Mayo y E.S. Quintana-Ortí,―rCUDA: Reducing the Number of GPU-based Accelerators inHigh Performance Clusters‖, High Performance Computing andSimulation, 2010.[4] J. Duato, A. J. Peña, F. Silla, R. Mayo y E.S. Quintana-Ortí,―Performance of CUDA Virtualized Remote GPUs in HighPerformance Clusters‖, International Conference on ParallelProcessing, 2011.[5] NVIDIA, ―The CUDA Compiler Driver NVCC‖, NVIDIA, 2011.[6] NVIDIA, ―CUDA Toolkit Reference Manual‖, NVIDIA, 2011.[7] NVIDIA, ―CUBLAS Library‖, NVIDIA, 2011[8] InfiniBand(SM) Trade Association, ―InfiniBand(TM) ArchitectureSpecification‖, InfiniBand(SM) Trade Association, 2007.[9] N. Nüssle, B. Geib, H. Fröning, and U. Brüning, "An FPGA-basedcustom high performance interconnection network", InternationalConference on Reconfigurable Computing and FPGAs, 2009.JP2011-316

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Un nuevo entorno para el uso de GPUs.Pedro Valero 1 , Fernando L. Pelayo 2Resumen— En este artículo se realiza un análisis sobrela viabilidad primero y las prestaciones después deun nuevo marco de trabajo en el que se usan GPUsen entornos con altos requerimientos de prestaciones,en este sentido se va más allá proponiéndose algunasmejoras en estas arquitecturas que incrementarían laefectividad de estos dispositivos ante estas demandas.Para la parte del análisis se ha llevado a cabo un conjuntode pruebas de ejecución que se consideran estandaren términos computacionales y como resultadode tal análisis, se describen la serie de mejoras que losautores entienden mejorarían de manera significativalas prestaciones de las arquitecturas basadas en GPUen entornos con altos requerimientos de potencia computacional.Palabras clave— Graphics Processing Units (GPU),computación de altas prestaciones (HPC), CUDA(Compute Unified Device Architecture), evaluaciónde rendimiento.I. IntroducciónHoy en día, las actuales GPUs constituyenuna apropiada plataforma paralela para acelerarcualquier aplicación, debido a sus características,número elevado de cores, alto ancho de banda y unalto ratio rendimiento/coste.Las GPUs pueden ejecutar millones de hilos simultaneamente,sin embargo, sólo pueden ejecutarun trabajo o aplicación al mismo tiempo. Si unaaplicación en particular necesitase 512 hilos para suejecución paralela, y teniendo en cuenta que algunasGPUs pueden ejecutar hasta 6.7 × 10 7 hilos, estetrabajo solo utilizaría el 0.0001% de toda la capacidadde la GPU haciendo un uso muy ineficiente de lamisma. Por esa razón, hemos modificado el métodotradicional de utilizar las GPUs con el fin de ejecutarmás de un trabajo al mismo tiempo. Más aún hemosrealizado una comparación de rendimiento entre elmétodo tradicional y nuestra propuesta.Estos dispositivos estan siendo utilizados en lamayoría de los entornos HPC actuales, basta decirque hay tres sistemas de supercomputación en lascuatro primeras posiciones de la lista top 500 [18]los cuales utilizan GPUs (en el primer, segundo ycuarto lugar). Así mismo, las GPUs estan siendo introducidasen entornos GRID [8] y CLOUD [7]. Enestos entornos las GPUs son utilizadas en muy diferentescampos como ciencia fundamental, medicina,astronomía, ingeniería, etc. [7]-[17].Este trabajo se estructura de la siguiente manera:La sección II describe las principales característicasde las actuales GPUs. La sección III presenta unanueva propuesta para un uso más eficientes de las actualesGPUs, más adelante la sección IV muestra losresultados experimentales y análisis de rendimiento1 Inst. de Investigación en Informática, Univ. de Castilla-LaMancha, e-mail: Pedro.ValeroLara@uclm.es2 Dpto. de Sistemas Informáticos, Univ. de Castilla-La Mancha,e-mail: FernandoL.Pelayo@uclm.esllevado a cabo. A continuación, en la seción V losautores describen algunas alternativas con el fin demejorar la eficiencia de estas plataformas para lapropuesta presentada con algunos pequeños cambiossobre la actual arquitectura. Finalmente, la seciónVI resume las conclusiones y esboza el trabajo futuro.II. GPULas GPUs son tradicionalmente utilizadas paraaplicaciones interactivas, sin embargo, sus característicashan permitido la posibilidad de acelerarotro tipo de aplicaciones más generales. Esta tendencíarecibe el nombre de GPGPU (General PurposeComputing on GPU) [1]La principal características de estos dispositivosconsiste en su gran número de cores y por tanto lacapacidad de manejar un alto número de hilos, juntoa un gran ancho de banda interno y una rápida comunicacióncon el procesador a través de un puertode alta velocidad (PCI Express). Debido a todo estolas GPUs pueden alcanzar hasta 10 veces el anchode banda y por atnto una gran superioridad en elcálculo en punto flotante respecto a las plataformastradicionales [2].La arquitectura de GPU esta formada por unnúmero de multiprocesadores (1-30), cada uno deellos con un número de cores (8 ó 32). Todos losprocesadores comparten la misma memoria llamadamemoria global. Además todos los cores de un multiprocesadorpueden acceder a la misma memoria(memoria compartida). Esta memoria sólo es útilcuando muchos hilos ejecutados en el mismso multiprocesadortienen que acceder a las mismas posicionesde memoria; ya que para cargar un datoen memoria compartida es necesario cargarlo desdememoria global. La figura 1 muestra un ejemplo dearquitectura de GPU.En los últimos años, ha habido diferentes iniciativaspara utilizar lenguages orientados a gráficos paraaccelerar partes especificas de códigos utilizandoGPUs [3], [4]. Más recientemente, los fabricantesde GPUs como NVIDIA o AMD/ATI, han desarrolladonuevos lenguajes, por ejemplo, NVIDIA proponeCUDA [6], el cual conforma una plataformasoftware para computación paralela de altas prestaciones.En CUDA los hilos son distribuidos dentro de unamalla de bloques de hilos, todos los bloques de hilostienen el mismo tamaño (número de hilos). Estoshilos ejecutan un código de GPU (kernel) que es lanzadopor la CPU y ejecutado en la GPU.Todos los códigos CUDA estan divididos en dospartes diferentes. El primero es el código de CPU,este código proporciona las instrucciones ejecutadasJP2011-317

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algorithm 2 CUDA pseudocode example 2.Function CPU⊲ Código CPU1: ReservaMemoriaCPU(C-CPU)2: ReservaMemoriaCPU(D-CPU)3: ReservaMemoriaGPU(C-GPU)4: ReservaMemoriaGPU(D-GPU)5: TransferenciaCPU-GPU(C-CPU,C-GPU)6: TransferenciaCPU-GPU(D-CPU,D-GPU)7: Kernel2(C-GPU,D-GPU)8: TransferenciaGPU-CPU(D-GPU,D-CPU)Function kernel2(C,D) ⊲ Código GPU9: i = identificación de hilo10: D[i] = C[i] × D[i]Fig. 1.Arquitectura de GPU.Algorithm 1 CUDA pseudocode example 1.Function CPU⊲ Código CPU1: ReservaMemoriaCPU(A-CPU)2: ReservaMemoriaCPU(B-CPU)3: ReservaMemoriaGPU(A-GPU)4: ReservaMemoriaGPU(B-GPU)5: TransferenciaCPU-GPU(A-CPU,A-GPU)6: Kernel1(A-GPU,B-GPU)7: TransferenciaGPU-CPU(B-GPU,B-CPU)Function kernel1(A,B) ⊲ Código GPU8: i = identificación de hilo9: B[i] = A[i] + 100por la CPU, por ejemplo, reservar memoria en lamemoria principal (CPU) y en la memoria global(GPU), transferencia entre memorias y lanzamientode kernels. Por otro lado, el código de GPU (kernel)provee las instruciones a ser ejecutadas en la GPU,por todos los hilos del kernel.Este modelo de programación se estructura segúnlas etapas:1. Reserva de memoria principal (CPU)2. Reserva de memoria global (GPU)3. Transferencia de memoria principal a global4. Lanzamiento de kernels5. Transferencia de memoria principal a globalIII. Nueva propuestaEsta nueva propuesta busca poder ejecutar más deun trabajo al mismo tiempo en una única GPU. Lascaracterísticas tanto de las actuales GPUs como de laherramienta software CUDA, permiten implementaresta propuesta, ya que cada multiprocesador tiene supropia unidad de control de instrucción.Ejecutar más de un kernel al mismo tiempo fuerzaa unir todos los co´digos de los kernels en uno, así puescada kernel será indexado por uno o varios bloquesde hilos. De esta forma, cada kernel es ejecutado deAlgorithm 3 Ejemplo de propuesta.Function CPU⊲ Código CPU1: ReservaMemoriaCPU(A-CPU)2: ReservaMemoriaCPU(B-CPU)3: ReservaMemoriaCPU(C-CPU)4: ReservaMemoriaCPU(D-CPU)5: ReservaMemoriaGPU(A-GPU)6: ReservaMemoriaGPU(B-GPU)7: ReservaMemoriaGPU(C-GPU)8: ReservaMemoriaGPU(D-GPU)9: TransferenciaCPU-GPU(A-CPU,A-GPU)10: TransferenciaCPU-GPU(C-CPU,C-GPU)11: TransferenciaCPU-GPU(D-CPU,D-GPU)12: Kernel(A-GPU,B-GPU,C-GPU,D-GPU)13: TransferenciaGPU-CPU(B-GPU,B-CPU)14: TransferenciaGPU-CPU(D-GPU,D-CPU)Function kernel(A,B,C,D) ⊲ Código GPU15: i = identificación de hilo16: j = identificación de bloque17: if j = 0 then ⊲ kernel118: B[i] = A[i] + 10019: else if j = 1 then ⊲ kernel220: D[i] = C[i] × D[i]21: end ifforma independiente y simultaneamente con otros.Se requiere un conjunto de condiciones para abordarla implementación:• Cada trabajo debe tener sus propias etapas (1-3)y 5 (sección II).• Un único kernel debe contener todos los kernelsindexados por bloques.• Los kernels deben de ser independientes, es decirdeben de tener sus propios parámetros y soluciones.Con el fin de indicar los cambios realizados paraimplementar nuestra propuesta, se muestran dosdiferentes ejemplos que describen la forma tradicionalde utilizar una GPU (algoritmos 1 y 2). Elalgoritmo 3 está formado por la unión de estos dosalgoritmos, con el fin de ejecutar sus kernels simultaneamente.Estos tres algoritmos muestran las dospartes del código, la parte ejecutada por la CPU yla parte ejecutada por la GPU (kernel).JP2011-318

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA ICaracterísticas de la GPU GTX 285.Característica GTX 285Número de multiprocesadores 30Número de cores 240Frecuencia de reloj 648 MhzFrecuencia de memoria 1242 MhzCapacidad de memoria 1 GBTamaño del bus de memoria 512 bitsAncho de banda 159 GB/sGigaflops 1062.72TABLA IITiempo de ejecución para la multiplicación de unamatriz.Tamaño T. ejecución(ms) M.A.64 0.073 5,632128 0.115 22,528192 0.167 50,688256 0.232 90,112320 0.325 140,800384 0.433 202,752448 0.653 275,968512 1.253 360,448576 1.411 456,192704 2.672 681,472832 3.791 951,808960 5.686 1,267,2001088 8.324 1,627,6481216 12.979 2,033,1521408 19.249 2,725,8881600 27.100 3,520,0001792 39.969 4,415,4881984 51.398 5,412,3522240 72.078 6,899,2002496 98.981 8,566,2722816 148.161 10,903,5523136 194.940 13,522,4323520 274.715 17,036,8003904 374.485 20,956,672IV. Evaluación del rendimientoPara llevar a cabo las pruebas de rendimientohemos utilizado una plataforma basada en GPU conla GPU GTX 285 cuyas características se muestranen la Tabla I. El propósito de estas pruebas es identificarlos factores clave en relación a los resultadosalcanzados.Para realizar la evaluación de rendimiento hemoselegido la multiplicación de matrices, una de las pruebasestandar más aceptadas y costosas computacionalmente.Las matrices utilizadas son cuadradase inicializadas aleatoriamente.Las pruebas se han dividido en dos casos, elprimero de ellos consiste en ejecutar simultaneamentedos multiplicaciones de matrices, el segundocaso consiste en multiplicar cuatro. En ambos casos,se incrementa el tamaño de las matrices con el fin deanalizar el peso de este parámetro. La Tabla II mues-TABLA IIITiempo de ejecución para la ejecución de 2multiplicaciones de matrices simultaneas.Tamaño F.A. S.A. S M.A.64 0.142 0.057 2.49 11,264128 0.23 0.087 2.64 45,056192 0.336 0.128 2.62 101,376256 0.469 0.191 2.45 180,224320 0.645 0.383 1.68 281,600384 0.929 0.523 1.77 405,504448 1.301 0.869 1.49 551,936512 2.475 1.186 2.08 720,896576 2.817 1.588 1.77 912,384704 5.386 2.863 1.88 1,362,944832 7.585 4.571 1.65 1,903,616960 11.360 7.981 1.42 2,534,4001088 18.647 11.449 1.62 3,255,2961216 926.109 14.944 1.74 4,066,3041408 38.759 22.866 1.69 5,451,7761600 55.144 31.930 1.72 7,040,0001792 81.564 44.561 1.83 8,830,9761984 101.733 59.925 1.69 10,824,7042240 144.600 85.764 1.68 13,798,4002496 198.677 118.128 1.68 17,132,5442816 299.409 169.929 1.76 21,807,1043136 392.051 233.500 1.67 27,044,8643520 549.755 329.229 1.66 34,073,6003904 750.115 448.490 1.67 41,913,344tra el tamaño de matriz y el tiempo de ejecución parala multiplicación de una matriz. Las Tablas III y IVmuestran el tiempo de ejecución para los dos casosde prueba, multiplicación de dos y cuatro matricesrespectivamente.Como se muestran en los resultados a mayortamaño de matriz, menor speedup. Uno de los principalesmotivos de este comportamiento son los conflictosde memoria, este hecho ocurre cuando más deun hilo tiene que acceder al mismo banco de memoriasimultaneamente, esto fuerza a que los accesos serealicen de forma secuencial y se pierda eficiencia.Este comportamiento es más común cuando todoslos multiprocesadores comparten la misma memoria(memoria global). En el segundo caso (cuatro multiplicacionesde matrices), la caida del speedup esmayor que en el primer caso, esto se debe a que conun mayor número de trabajos hay un mayor númerode accesos a memoria y por tanto mayor número deconflictos.A través de los resultados obtenidos en las pruebas,hemos demostrado la capacidad de nuestra propuestade ejecutar más de un kernel de forma simultanea.El número de accesos a memoria es uno de los factoresque implican el buen o mal funcionamiento deesta plataforma. Además, hemos encontrado algunasdeficiencias que podrían ser mejoradas, con el fin deobtener una mejor plataforma para la propuesta presentadaen este trabajo:• Todos los multiprocesadores comparten laJP2011-319

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IVTiempo de ejecución para la ejecución de 2multiplicaciones de matrices simultaneas.Tamaño F.A. S.A. S M.A.64 0.284 0.070 4.05 22,528128 0.459 0.198 2.31 90,112192 0.671 0.306 2.19 202,752256 0.940 0.739 1.27 360,448320 1.286 1.174 1.09 563,200384 1.752 1.954 0.89 811,008448 2.621 2.932 0.89 1,103,872512 4.967 4.444 1.11 1,441,792576 5.634 6.121 0.92 1,824,768704 10.757 10.998 0.97 2,725,888832 15.131 18.133 0.83 3,807,232960 22.724 27.195 0.83 5,068,8001088 33.269 39.805 0.83 6,510,5921216 48.028 55.599 0.86 8,132,6081408 74.383 85.898 0.86 10,903,5521600 105.013 124.801 0.84 14,080,0001792 159.711 175.371 0.91 17,661,9521984 200.123 238.672 0.83 21,649,4082240 285.814 342.187 0.83 27,596,8002496 395.214 472.163 0.83 34,265,0882816 603.733 683.050 0.88 43,614,2083136 779.449 936.571 0.83 54,089,7283520 1,099.669 1,326.072 0.82 68,147,2003904 1,499.572 1,815.135 0.82 83,826,688misma memoria debido a ello, cuando muchostrabajos ejecutados en la misma GPU tienenque acceder a memoria se produce una caida delspeedup.• Es necesario transferir datos entre ambas memorias,antes y después de cada ejecución.• Todos los kernels tienen que ser lanzados almismo tiempo, además estos tienen que finalizaral mismo tiempo también.En la siguiente sección, presentamos diferentes opcionespara incrementar el rendimiento, principalmenteatacando los puntos anteriormente detallados.V. Nuevo modeloA partir de aquí, los autores presentan una nuevaarquitectura basada en GPU. Esta sección está estrucutradapor las diferentes opciones seguidas con elfin de obtener un mejor rendimiento para el propósitopresentado en este artículo.A. Gestión de memoriaComo hemos indicado en la anterior sección, losaccesos a memoria pueden ser el principal cuello debotella presente en esta arquitectura. Por esa razón,es necesario una gestión mejor de memoria. En nuestrahumilde opinión, estos dispositivos deberían tenertantos espacios de memoria “privada” como númerode multiprocesadores. Gracias a esto, cada flujo deinstrucciones de cada multiprocesador no interferirácon los demás evitando los conflictos de memoria.Speed upSpeed up32.521.510.5064 960 39044.543.532.521.510.5Tamaño064 960 3904TamañoFig. 2. Speedup para la multiplicación de 2 matrices(izquierda) y 3 matrices (derecha)Según podemos ver en la figura 3, cada multiprocesadortiene sus propia memoria “privada” la cual sólopuede ser accedida por este, y su propio controladorde memoria. Por lo tanto, con esta alternativa cadakernel es independiente de los demás y así los requisitosde memoria de un kenrel no interfiere con losdel resto.B. Comunicación entre CPU y GPULa GPU y CPU estan localizadas en diferentes espaciosy tienen sus propias memorias. La primeraimplicación de este aspecto es la necesidad de transferirlos parámetros desde la memoria principal(CPU) a la memoria global (GPU), y las solucionesdesde la memoria global a la memoria principal.Con el fin de evitar este tráfico es necesario quetanto la CPU como la GPU puedan compartir lamisma memoria. Hoy en día, hay al menos, unejemplo en donde una CPU y un acelerador hardwarecomparten la misma memoria, este es el procesadorCELL (IBM) [19] donde el procesador principal(Power Processor Element, PPE) puede manejarocho procesadores más pequeños (Synergistic ProcessingElements, SPE). La comunicación dentro delCELL puede realizarse mediante memoria compartidao a través de un bus en anillo. Este procesadoralcanza 200 Gflops, un 20% de Gflops de laGTX 285. Actualmente, AMD/ATI está desarrollandouna nueva arquitectura llamada Fusion [20]donde CPU y GPU comparten el mismo espacio.En esta sección presentamos una opción para evitarlas transferencias entre memorias. No es suficienteque la CPU y GPU compartan la mismamemoria, además la CPU debe de tener acceso a todoslos espacios de memoria de la GPU para escribiry leer.JP2011-320

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3.Nueva estructura de memoriaFig. 4.Un nuevo modelo de comunicación entre CPU y GPUComo podemos ver en la figura 4, la CPU y GPUcomparten el mismo espacio de memoria, la CPUcon su controlador de memoria (M.C.CPU) puedeacceder a todos los espacios de memoria, y mantenerla opción mostrada arriba donde cada multiprocesadortenía su propia memoria privada.Debido a esto, no se requiere ninguna trasferenciade datos entre la CPU y GPU, además no esnecesario tener duplicados ni los parámetros ni lassoluciones en diferentes espacios de memoria, lo cualredundaría también en un ahorro energético.C. Gestión de kernelsActualmente, es necesario que la CPU lance todoslos kernels al mismo tiempo, además estos tienen queterminar también al mismo tiempo. Por lo tanto, noes posible utilizar una solución de un kernel particularhasta que todos los kernels terminen. Esto es unadesventaja ya que el trabajo más lento impone sustiempos sobre el resto, puesto que la CPU no puedeutilizar las soluciones hasta que este kernel finalice.Además, debido a la imposición del kernel más lento,tenemos que parte de los recursos computacionales(multiprocesadores y memoria) estan inactivos.Para que podamos utilizar los resultados de loskernels tan pronto como estos esten disponibles, esnecesario un mecanismo que permita a la CPU conocerla finalización de los mismos. Este mecanismopodría ser implementado con una simple cola monitorizadapor la CPU, esta cola (finished jobs queue,FJQ), debería indicar a la CPU el indentificador delos kernels ya acabados, y por tanto la CPU podríautilizar las soluciones de estos, y asignar otros kernelsa los recursos computacionales inactivos.Para ello sería necesario un mecanismo que permitieselanzar los kernels en cualquier momento, envez de tener que ser lanzados todos a la vez. Estopodría ser implementado gracias a un conjunto decolas (jobs queues, JQ), una por multiprocesador,que almacenase los trabajos a ser ejecutados en unmultiprocesador partcular.Gracias a esto, la CPU podría utilizar los resultadosde los kernels tan pronto como estos esténdisponibles. Además es posible lanzar kernels encualquier instante, sin tener que esperar a que el máslento de ellos finalice. Con todo lo anterior se obtendríaun uso sustancialmente más eficiente de losrecursos.Como podemos ver en la figura 5, hay una cola(FJQ) donde todos los multiprocesadores envian laJP2011-321

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 5.Una neva alternativa para ejecutar más de un trabajo en una GPUseñal de finalización de kernel. Esta cola permite ala CPU conocer los kernel acabados y su orden determinación. Por otro lado, cada multiprocesadortiene en su cola JQ nuevos kernels listos para serejecutados.VI. Conclusiones y trabajo futuroEn este trabajo hemos realizado un estudio sobrelas prestaciones de arquitecturas GPUs bajo unascondiciones tales que nos permiten afirmar que esposible ejecutar más de un trabajo en una GPU ynos indican un posible camino a seguir para la optimizacióndel uso de este tipo de dispositivos en entornosde High Performance Computing.Este estudio ha estado basado en el coste computacional,temporal, del producto de matrices cuadradasbajo los requerimientos estandar de este tipo deanálisis.Para alcanzar los resultados mostrados, previamentese muestra la posibilidad de la ejecución demás de 1 trabajo simultaneamente en una GPU. Dehecho, en el modelo más reciente de GPU (FERMI,que no estaba disponible cuando iniciamos la realizaciónde estos estudios) de la firma NVIDIA ya esposible está ejecución simultánea de más de 1 trabajoen una GPU, las diferencias con el modelo queplanteamos siguen siendo importantes, pero el interésdel camino seguido por los autores queda refrendadopor esta decisión comercial.También ha sido necesario identificar que el cuellode botella en la computación en estos dispositivos,radica en los accesos a memoria, lo cual nos ha guiadoen las propuestas de mejora aquí reflejadas. Talespropuestas de mejora está fundamentalemente enfocadasen pequeños cambios a nivel de arquitecturaque, para ser aprovechados necesitan consecuentementede algunos cambios en su modelo de programación.En la actualidad estamos interesados en el análisisde viabilidad real y prestaciones de estas ligeramentemodificadas GPUs.Referencias[1] GPGPU. General-purpose computation using graphicshardware. http://www.gpgpu.org.[2] W.-C. Feng, D. Manocha. High-performance computingusing accelerators, Parallel Computing, Elsevier, 33(2007), 645-647.[3] R.J. Rost. OpenGL Shading Language, Addison-Wesley,2005.[4] W.R. Mark, S.R. Glanville, K. Akeley, M.J. Kilgard. Cg: asystem for programming graphics hardware in a C-like language.SIGGRAPH’03: ACM SIGGRAPH 2003 Papers,pages 896-907, New York, NY, USA, 2003. ACM Press.[5] Pedro Valero, Fernando L. Pelayo. Towards a moreefficient use of GPUs. U.C.L.M. Technical ReportDIAB-11-02-4. http://www.info-ab.uclm.es/trep.php?codtrep=DIAB-11-02-4[6] NVIDIA. NVIDIA CUDA Compute Unified DeviceArchitecture-Programming Guide, Version 2.3 2009,http://www.nvidia.com/object/cuda_home.html.[7] Speeding up pricing complex instruments in the cloud withscifinance. SciComp Inc. http://www.scicomp.com/.[8] GPUGRID. http://www.gpugrid.net.[9] BOINC. http://boinc.berkeley.edu/gpu.php.[10] SETI. http://setiathome.berkeley.edu/cuda.php.[11] Milkyway. http://milkyway.cs.rpi.edu/milkyway_gpu/.[12] AQUA. http://aqua.dwavesys.com/.[13] The Lattice Project. http://boinc.umiacs.umd.edu/.[14] Einstein. http://einstein.phys.uwm.edu/.[15] Collatz. http://boinc.thesonntags.com/collatz/.[16] Primegrid. http://www.primegrid.com/.[17] DNETC. http://dnetc.net/.[18] TOP500. http://www.top500.org/.[19] H. Peter Hofstee. Introduction to the CellBroadband Engine. IBM Corporation. https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/D21E662845B95D4F872570AB0055404D/$file/2053_IBM_CellIntro.pdf.[20] Nathan Brookwood. AMD Fusion Family of APUs: Enablinga Superior, Immersive PC Experience. AMD Corporation.http://sites.amd.com/us/Documents/48423B_fusion_whitepaper_WEB.pdfJP2011-322

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Pre-procesamiento de Flujo Óptico Robusto enHardware GráficoFermín Ayuso 1 , Guillermo Botella, Carlos García, Manuel Prieto y Francisco TiradoResumen—Este trabajo aborda la implementacióneficiente de filtros bioinspirados espaciales y temporalesconstitutivos de etapas previas en la estimación demovimiento mediante modelos de gradiente. Este estudio selleva a cabo con el objetivo de obtener una primeraevaluación en términos de rendimiento que ofrece elhardware gráfico. Esta implementación se ha efectuadousando procesadores gráficos (GPU). Se describen losfiltros, su plausibilidad biológica y así mismo suimplementación óptima aprovechando la arquitecturaparalela que nos brindan las GPUs modernas. Se presentaun estudio de viabilidad en comparación a un procesadorde propósito general actual, por medio de experimentosque tratan de explorar el rendimiento frente a diferentesparámetros de diseño algorítmicos en el contexto demodelos de estimación de movimiento que conforman eltamaño de filtros temporales y espaciales, ordenes deprecisión y flujo de información.Palabras clave— Estimación de Movimiento, ProcesadoDigital de Señal, Hardware Gráfico, CUDA, SistemasBioinspirados, Sistemas en Tiempo-Real. 1LI. INTRODUCCIÓNA estimación de movimiento es un tema muyabordado a lo largo de los últimos años debidoa sus múltiples aplicaciones relativas al procesamientode señal, como tracking, vigilancia, disparidadbinocular, etc. Dentro de este paradigma encontramostres familias representativas de las diferentes técnicas deestimación los modelos de emparejamiento [1], los deenergía [2] y los de gradiente [3]. La primera familiaaplica plantillas dando una idea del ajuste entre unadeterminada ventana de comparación y su ventanaobjetivo dentro de un espacio de búsqueda dado. Losmodelos de energía hacen uso de probabilidades yesquemas bayesianos, de forma que tenemos unadistribución final de soluciones válidas (poblaciones defiltros) no únicas. Podríamos resumir estos dosesquemas como una aplicación de plantillas, buscandode forma ideal un ajuste óptimo entre el movimiento y laplantilla, con problemas no triviales como el contrastedel estímulo, necesitando complejas etapas denormalización.La filosofía de los modelos de gradiente sin embargo,viene dada por una solución a la ecuación deconstricción del flujo óptico:I x I 0x t t1 fermin@fdi.ucm.es,Dept. de Arquitectura de Computadores y Automática.Universidad Complutense de Madrid, España(1)Siendo I la intensidad de la imagen, donde lavelocidad se calcula directamente a través de sendoscocientes de derivadas temporales y espaciales en cadapunto [3]. El contraste varía igualmente en eldenominador y el numerador, resultando un invariante alcontraste sin un coste de cálculo adicional.Por otra parte, la percepción del movimiento desde elpunto de vista sensorial es un tema fundamental parasobrevivir. Existen áreas en el córtex visual cuya únicafunción es detectar movimiento [4]. Uno de los retosactuales todavía no resueltos es una explicaciónplausible de cómo el sistema visual puede calcular lavelocidad del movimiento a partir de los cambiosespaciales y temporales de la imagen proyectada en laretina [5].El modelo neuromórfico en el que se basa este trabajo[6] recoge conocimientos de la biología y la fisiologíacortical y está basado en una estructura de operadoresdiferenciales espaciales y temporales que luego se rotanen el espacio acelerados mediante arquitecturasespecíficas en hardware gráfico [7].Los procesadores de procesamiento gráfico (GPU), seencuentran disponibles en dispositivos de bajo costegracias a la evolución de la industria de los videojuegos.Estos dispositivos están basados en sistemasmultinúcleo con una jerarquía de memoria compleja.Estas plataformas están diseñadas para aprovechar elalto grado de paralelismo de datos en el renderizado deescenas en 3D. Sin embargo, se pueden utilizar hoy endía como coprocesadores paralelos mediante laejecución de un alto número de threadssimultáneamente. A modo de ejemplo empleandotecnología actual, un chip de NVIDIA Tesla C2070alcanza un rendimiento máximo de 1,28 Tera FLOPs,mientras que un procesador Intel i7-975 únicamentepuede completar 55 GigaFLOPs. Esta sorprendentepotencia de cómputo ha servido para llamar la atenciónde muchos programadores y científicos procedentes demúltiples áreas, que están utilizando las GPUs actualescomo sistemas paralelos que permiten acelerar suspropias aplicaciones.II. DESCRIPCIÓN DEL PROBLEMAPartiendo de la idea de este trabajo como una evaluacióninicial de las posibilidades que ofrecen las GPUs enaplicaciones de estimación de movimiento, se planteacomo objetivo inicial implementar tres etapas de preprocesamientode movimiento, común a la familia demodelos de gradiente. Esta máquina será diseñada deforma óptima y eficiente aprovechando la arquitecturaespecífica y el modelo de memoria de una GPU con elJP2011-323

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011fin de aprovechar las ventajas del procesamientoconvolutivo y paralelo que está presente en este tipo dealgoritmos.Estas etapas están fundamentadas en evidencias deexistencia de estos operadores en el sistema visual demamíferos.A. Filtros temporalesHess y Snowden investigaron el procesamiento visualhumano con una serie de experimentos [8] encontrandoevidencias de 3 canales temporales: un canal paso baja,un canal paso banda con frecuencia central aproximadaa 10 Hz y otro paso banda con frecuencia central a 18Hz. Esos 3 canales se pueden modelar por diferenciaciónde una gaussiana en el dominio del logaritmo del tiempo(Fig. 1).Fig. 1. Representación de los tres canales temporales encontrados en elhumano [9] desde el punto de vista de su respuesta impulsiva(arriba) y su comportamiento en frecuencia (abajo).El núcleo será una función que proporcione operadoresderivativos a medida que se derive. Como tal, se usaráuna gaussiana en el espacio temporal logarítmico(log(tiempo)), con α=10, τ=0.2, descrito en la ecuaciónsiguiente:enucleo B. Filtros espaciales(log(t / ) / )e 2( )4(2)En el dominio espacial, la forma de los camposreceptivos de las células en el córtex visual primitivopuede ser modelada con derivadas gaussianas [9]. Amedida que el orden de diferenciación aumenta, lasgaussianas se ajustan a frecuencias espaciales máselevadas, obteniendo un rango de canales espacialesindependientes entre sí, que han sido verificadosexperimentalmente como se ilustra en la Fig. 2 y semodela según la expresión siguiente:2Fig. 2. Representación de gaussiana bidimensional, y susdiferentes derivadas, haciendo uso de la ecuación (1). Filasuperior, derivadas de orden 0,1 y 2. Fila inferior, derivadasde orden 3,4 y 5.2 2( x y nn2d d 2se ( G ) n 0 ndx dx s 2 p (3) 2 2( x y2n2 2s x y 1e Hn Hn 2s 2s2s s 2 p Donde σ representa la anchura de la Gaussiana, H n es elpolinomio de Hermite de orden n. La convolución serealiza de forma separable, usando derivadas tomadas enfilas y columnas respectivamente, debido a laseparabilidad de la gaussiana bidimensional.C. Orientación de los Filtros en el espacio(Steering)Esta etapa representa la proyección de los filtroscalculados previamente en diferentes orientaciones en elespacio. Representamos en la expresión siguiente laexpresión general de las diferentes rotaciones de lagaussiana y sus derivadas. Se denomina n y m el ordende diferenciación en las direcciones x e y, el ánguloproyectado, D el operador derivativo y G O la expresiónde la Gaussiana. Esta expresión se resume en expresarcada filtro orientado como una combinación lineal de losfiltros de su mismo orden de diferenciación, como sedemostró en trabajo previo [10].n nGnm ,( x, y) Dxcos Dysin k0kmm imi Dxsin DycosG0i0 i k nkIII. MODELO FLUJO OPTICO EN GPUEn este trabajo hemos empleado un sistema basado entecnología Tesla de NVIDIA. El sistema cuenta convarias GPUs que se pueden programar empleando elparadigma de programación de CUDA (ComputeUnified Device Architecture). CUDA es un conjunto de (4)JP2011-324

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011herramientas de NVIDIA [7] que incluye un compiladorespecífico para el hardware gráfico.A. Arquitectura de una GPUEl modelo de programación CUDA representa la GPUcomo un coprocesador que puede ejecutar kernels enparalelo y ofrece extensiones para el lenguaje C para (1)mapear los datos de la GPU, (2) la transferencia de datosentre la GPU y la CPU y (3) lanzar dichos kernels.Un kernel CUDA ejecuta unas líneas de código sobre ungran número de hilos en paralelo. Este tipo de sistemasexplotan el concepto SIMT (Single Instruction MutipleThreads), una misma instrucción es ejecutada pormuchos threads con datos de entrada distintos. Lastareas son organizadas mediante bloques CUDA, dondese pueden llegar a lanzar hasta 1024 hilos que puedencooperar entre sí por (1) compartición de datos a travésde una memoria local de baja latencia y (2) lasincronización mediante barreras. Diferentes bloquesCUDA sólo se pueden coordinar a través de los accesosa una memoria global de alta latenciaLa figura 3 muestra un esquema del hardware en unaGPU. Los núcleos de la GPU (procesadores) seorganizan en varios multiprocesadores. Cada uno deestos núcleos integra sus propias unidades funcionales yun registro de gran tamaño que tiene capacidad para laejecución de cientos de hilos concurrentes. Cadamultiprocesador posee una Instruction Unit que controlael lanzamiento de los hilos y de una memoria localcompartida. La jerarquía de memoria también incluyememoria caché de sólo lectura para acelerar el acceso alas texturas y las constantes. La abstracción del bloqueCUDA está estrechamente relacionado con estaorganización: cada bloque de CUDA es ejecutado por unmultiprocesador, que dependiendo de la disponibilidadde recursos pueden mapear varios bloques al mismo.en el hardware. La unidad de programación no es el hiloindividual, sino un grupo de hilos llamados warp. Encada ciclo el planificador elige el siguiente warp aejecutar de forma semejante a la planificación de unprocesador Multihreading de grado fino.Uno de lo factores más significativos que afectan alrendimiento final es el uso eficiente de la jerarquía dememoria. A pesar de que este tipo de hardware permitela ocultación de accesos a memoria de alta latencia aligual que un procesador Multithreading de grano fino, elacceso simultáneamente de un número alto de threads ala DRAM plantea un enorme desafío. Debido a esteproblema, el uso eficiente de la memoria localcompartida y las texturas de sólo lectura sonfundamentales para lograr buenos rendimientos enmuchos algoritmos. Además, el acceso de los threads deun warp debe de ser alineado, porque se traduce en unúnico acceso a memoria reduciendo significativamentela contención con memoria [11].B. Programación del pre-procesamiento de flujoóptico en GPUEn esta subsección se abordará la descripción del mapeodel algoritmo bajo estudio en una GPU. Vamos asuponer que una parte de la película de entrada seadquiere en tiempo real, y que se puede alimentar anuestro sistema con un número de frames considerable.Cada una de las etapas corresponde a un kernel deejecución en la GPU. A continuación se describebrévemente su programación:Etapa de filtros temporalesRespecto a los filtros temporales, hay que hacer unadiscretización de los valores del caso continuo y unposterior ecualizado de forma que la integral de lasdiferentes funciones se ajuste a cero.Fig 4: Paso de una realización de filtro temporal, (siendo t=0,n,L elprimer fotograma, el último y la longitud del filtro) que nos da unarespuesta para el fotograma alfa.Fig. 3. Modelo de programación CUDA. GPU como un coprocesadorque integra varios multiprocesadores y una jerarquía de memoriacompleja.Como se mencionó anteriormente, la creación desubprocesos y la programación se realiza por completoPara realizar su implementación en una GPU hemosconsiderado varias versiones con el ánimo de escoger lamás adecuada. Una primera versión en la cual el filtro seencuentre almacenado en diferentes lugares de lajerarquía de memoria: global, textura o constantes. Yuna segunda versión que almacene la información de losnL fotogramas en memoria global o en memoriacompartida. Por último se estudiará el rendimientoalcanzado de una versión en la que se evalúe laJP2011-325

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011conveniencia de reusar información en la memoriacompartida. Los nL fotogramas involucrados en estaetapa se dividen en bloques de 16x16 que se mapean enun multiprocesador. El procesado de los nL fotogramasen bloques de 16x16 pixeles lo realizan 16x16 threadsde forma que cada hilo realice los cálculos equivalentesal procesado de un píxel de salida. Como salida seobtiene un suavizado temporal, y las derivadas de primery segundo orden respectivamente de la secuenciaoriginal mostrado en la figura 4.Etapa de filtros espacialesPreviamente a esta etapa, se aplica un filtro paso baja,con objeto de suavizar las imágenes y mejorar losresultados de las etapas posteriores. A cada una de lassalidas temporales le aplicamos una "pirámide" espacialde varios filtros (por ejemplo se muestran 10 en la figura5), comprendiendo todas las derivadas de una gaussianabidimensional hasta su tercer orden según se ilustra encada una de las diagonales de la pirámide mostrada en lafigura siguiente.Fig. 5. Pirámide de filtros diferenciales espaciales de orden 0 hasta 3.La implementación en GPU se basa en la creación dedos kernels para procesar el filtrado separable vertical yhorizontal. Tomaremos como punto de partida el códigoSDK de NVIDIA [12] de convolución para imágenes.La principal diferencia radica en que nuestro algoritmoutiliza una convolución centrada. Con el fin deincrementar el grado de paralelismo se elige unadimensión mayor, blockid.x o blockid.y en lanomenclatura de CUDA, en el eje en que realice elfiltrado. Los filtros correspondientes se almacenan en lamemoria de texturas y se aborda el cálculo de forma quela información de salida quede almacenadaconsecutivamente en relación con el orden que seprocesa.Etapa de OrientaciónEsta etapa se basa en una síntesis del filtro F orientado grados. Gracias a la linealidad y conmutatividad de laconvolución, siendo posible sintetizar el filtro orientadoF a partir de los filtros de su base (mismo orden dediferenciación), será posible obtener su respuestaorientada R a partir de su conjunto de respuestasR 1 …R n ., tal y como muestra la expresión siguiente: R F I ( K1F1K2F2 .... KnFn)IKF1 1IKF 2 2I...KnFnI KRKR ...K R1 1 2 2 n n(4)Donde K 1 ,…,K n representan los pesos, I es la imagen deentrada, es la orientación.El cómputo en la GPU se aborda de forma similar a laetapa de filtrado temporal con la diferencia que el vectorde pesos se almacena en memoria compartida.IV.RESULTADOSA. Entorno de simulaciónEl sistema empleado en nuestras simulaciones es unequipo basado con la tecnología Tesla, posee dosprocesadores Intel Xeon E5530 equipados con cuatrocores a 2.40 GHz con 8MB de cache y tecnologíaHyperthreading, conectados a 4 tarjetas gráficas tipoTesla C1060. En este trabajo únicamente se hanempleado un core de una CPU y una GPU. El sistemaoperativo es Debian con el kernel 2.6.38, el compiladores el g++ de GNU versión 4.5.2 usado con las opcionesde compilación -O3 -m64 y para hacer uso del hardwaregráfico se emplea la versión 2.3 de CUDA.La tarjeta gráfica empleada tiene el índice de capacidad(CUDA capabilities) 1.3 que indica que posee 240núcleos de procesamiento con 1024 threads pormultiprocesador. Posee una jerarquía de memoria de4GB para memoria global, 16KB de memoriacompartida y 64KB para la de constantes.B. Resultados de rendimientoComo el objetivo de este trabajo es evaluar losbeneficios potenciales del hardware gráfico en elcontexto de aplicaciones de estimación de movimiento,hemos enfocado esta sección como un estudiopreliminar de las aceleraciones que se pueden alcanzarabordando la implementación de algunas de las etapasmás relevantes del algoritmo.El primero de los análisis que vamos a realizar consisteen observar los beneficios de la arquitectura GPU en laetapa de filtrado temporal. Se han barajado variasimplementaciones que describiremos a continuación:- Base: punto de partida donde la información dela película y los filtros se almacenan en lamemoria global. El particionado de datos ycómputo empleado está descrito en la secciónIII.B.- Global: la información de la película sealmacena en memoria global y el filtro enmemoria de constantes.- Shared: los nL fotogramas para ser filtrados sealmacenan en memoria compartida y el filtrosigue en constantes.- Shared-optimizada: el filtro espacial continúaen memoria de constantes y los nL fotogramasen memoria compartida creando una estructurade buffer circular. El funcionamiento de dichoJP2011-326

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011buffer es el siguiente: a) en t=0 se inicializa conlos fotogramas desde el 1 al nL+1 y b) en t=1 ysucesivos se reemplaza el contenido delfotograma 1 por el del fotograma nL+2. De estaforma se reducen el número de copias en lamemoria compartida y se explota el reuso deinformación.La figura 6 muestra las aceleraciones obtenidas para loscasos anteriormente descritos respecto a la versión enCPU para un conjunto de entradas de diferente tamañode fotograma y nL=7,9 y 15.7, 9, 15 y 31. Según se ha observado empíricamente elnúmero de órdenes espaciales no afectasignificativamente al rendimiento observándoseresultados análogos para otros valores considerados. Endicha figura se perciben mejores rendimientos con filtrosmayores porque es posible explotar mayor cantidad deparalelismo en el cómputo de la convolución llegando alograr aceleraciones cercanas o incluso superiores ax25.908070speedups en filtado temporal30speedup en filtrado espacialSPAC_FILT=4605040302010baseglobalsharedshared-opt25201510532x3264x64128x128256x256032² 64² 128²256² 32² 64² 128²256² 32² 64² 128²256²0CONV=15 CONV=31CONV=7 CONV=23nL=7 nL=9 nL=15Fig. 7. Aceleraciones obtenidas en la etapa de filtrado espacialvariando el tamaño del fotograma y el tamaño del filtro espacial.Fig. 6. Aceleraciones obtenidas en la etapa de filtrado temporalvariando el tamaño del fotograma y el número de fotograma a filtrar(nL).20Speedup en etapa steeringComo se aprecia en la figura las ganancias en tiempo deejecución son importantes sea cual sea la versiónutilizada para GPU. Sin embargo los mejores resultadosse observan cuando los filtros temporales se encuentranalmacenados en memoria de constantes y los fotogramasen global (versión global) alcanzando unasaceleraciones de hasta 85x.Aunque la versión shared y shared-opt deberían lograr apriori mejores resultados porque los tiempos de latenciacon memoria compartida son menores que con memoriaglobal, el hecho de realizar un cómputo sencillo conpocas operaciones, permite alojar los datos directamenteen los registros del multiprocesador (posee hasta 16Kregistros de 32 bits). A modo de ejemplo con nL=15, elkernel opera con 3840 elementos por bloque que comose observa es mucho menor a los 16K de la arquitectura.En dicha figura también se observan aceleracionesimportantes y crecientes con el tamaño del fotograma,tal y como parece esperable ya que el número debloques-CUDA es mayor lo que se traduce en unamayor utilización de los recursos de la GPU.A continuación vamos a evaluar los beneficios de laarquitectura GPU en la etapa del filtrado espacial. Paraello, con el fin de realizar comparaciones con losmismos datos de entrada se ha fijado el tamaño del filtrotemporal nL a 15. Tomando los tamaños de fotogramaidénticos al análisis anterior, se ha estudiado el impactodel tamaño del filtro espacial y como afecta el númerode ordenes en el rendimiento global.La figura 7 muestra las aceleraciones con filtrosespaciales de orden 4, variando el tamaño del mismo a15105064x64 128x128 256x2566 ángulos12 ángulos24 ángulosFig. 8. Aceleraciones obtenidas en la etapa de steering variando eltamaño del fotograma y en número de ángulos.El siguiente análisis corresponde con la etapa de lasderivadas orientadas, o steering. Al ser el cómputo deesta etapa bastante sencillo, puesto que únicamenteconlleva la rotación de las derivadas anteriores yaplicarles una función de pesos según su importanciarelativa, su implementación se fundamenta en almacenarla información de entrada en memoria global. La ideaque subyace es idéntica a conclusión de la etapa dederivadas temporales, el conjunto de datos de entrada sepuede mapear directamente sobre los registros de laarquitectura porque su volumen es escaso haciendo usode la memoria compartida para almacenar el contenidode los pesos.La figura 8 muestra los resultados obtenidos variando eltamaño del fotograma y el número de ángulos cada 60º,30º y 15º (6, 12 y 24 ángulos en la figura). En dichafigura se aprecia que, salvo para el caso de fotogramasJP2011-327

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011pequeños (de 64 2 pixeles), el número de ángulos y laaceleración obtenida son parecidos, resultando ser lamejor configuración la de 24 ángulos y el mayor tamañode fotograma. La razón es obvia, para este caso elvolumen de datos considerado es el más alto, por lo queexiste mayor grado de paralelismo y por ende el gradode utilización de la GPU es máximo.Tabla 1: Rendimiento en una GPU en comparación con una CPU.64²128²256²Inic. GPU F. temporal F. espacial Steering Total(s/pixel) (kpixel/s) (kpixel/s) (kpixel/s) (kpixel/s)CPU 12848 1441 2090 800GPU 9,08E-6 495984 2552 7882 1214CPU 13965 923 1203 503GPU 7,21E-6 1166121 8792 18271 3454CPU 21503 1047 1304 565GPU 2,25E-6 1724632 27557 24183 6530Y por último en la tabla 1 se recogen los rendimientosde cada una de las etapas así como el del procesocompleto para los tamaños de fotograma considerados.La primera columna corresponde al coste deinicialización del problema en la GPU, básicamenteinicialización del hardware, reserva de memoria y envíode información medidos en segundos/píxel. Aunque seobserva que los tiempos por píxel son pequeños estesobrecoste tiene una relevancia importante en el procesofinal que supone un 35-49% del tiempo total, si bien escierto que su impacto se irá disminuyendo a medida quemás etapas del algoritmo se computen en la GPU. Lascolumnas F. Temporal, F. Espacial y Steeringcorresponden a cada etapa analizada medidas enkpixel/s. Es importante reseñar que la etapa steering esla que mayor peso computacional tiene (30% de mediaincluyendo la fase de inicialización de la GPU), por loque la aceleración global vendrá determinada por dichaetapa. Y por último la columna Total muestra elrendimiento global observado en una GPU frente a unCPU en igualdad de condiciones. En dicha columna sehan tenido presentes los sobrecostes de inicializaciónpor lo que se observa una disminución del rendimientorespecto a cada una de las etapas por separado.CONCLUSIONES Y LINEAS FUTURASTeniendo en cuenta los análisis realizados conanterioridad, podemos concluir que el uso del hardwaregráfico como acelerador para aplicaciones de flujoóptico es interesante y abordable pudiendo llegar aalcanzar aceleraciones globales de x12. Sin embargo hayque tener presente sobrecostes derivados de gestión dememoria y envío de información a la GPU que reducesignificativamente los rendimientos.Para alcanzar resultados satisfactorios es crucial haceruna distribución de trabajo adecuada y sobre todoexplotar eficientemente la jerarquía de memoria de laGPU que no es tarea intuitiva.Por otro lado, en este trabajo solamente se ha tenido encuenta el rendimiento, sin embargo al estar trabajandocon un algoritmo expansivo, a medida que crecen lasetapas el consumo de memoria puede llegar a actuarcomo limitador. Con la configuración más demandantese consumen 3.5GB de memoria global acercándonos allímite de su capacidad. Parece indicado explorarmecanismos que reduzcan el número de datos o idearestrategias que exploten el paralelismo existente entreetapas siguiendo la analogía de un procesadorsegmentado.Y por último, como línea futura se prevé la implantacióndel modelo completo de procesado de movimiento degradiente, multicanal y multiescala, considerando surepresentación en colores, no exisitiendo actualmenteninguna implementación del mismo que haga uso dehardware gráfico.AGRADECIMIENTOSEl presente trabajo ha sido financiado mediante elproyecto CICYT-TIN 2008/508 e Ingenio ConsoliderESP00C-07-20811.REFERENCIAS[1] H. Oh, H. Lee, “Block Matching algorithm based on aadaptative reduction of the search area for motionestimation”. Real Time Imaging, vol. 6, pp. 407-414,2000.[2] C. Huang, Y. Chen, “Motion Estimation Method Using a3D Steerable Filter”. Image and Vision Computing, vol13, pp. 21-32, 1995.[3] S. Baker, I. Matthews, "Lucas-Kanade 20 Years On: AUnifying Framework," International Journal of ComputerVision, Vol. 56, No. 3pp. 221 – 255, 2004.[4] V. Bruce, P.R. Green, M.A. Georgeson, “VisualPerception: Physiology, Psychology & Ecology”, thirded., Laurence Erlbaum Associates, Hove, 1996.[5] Claeys, K., Lindsey, D., De Schutter, E., & Orban, G. Ahigher order motion region in human inferior parietallobule: Evidence from fMRI.Neuron, 40, 631-642.(2003).[6] A. Johnston, P.W. McOwan, C.P. Benton, “Biologicalcomputation of image motion from flows overboundaries”. J Physiol. Paris, vol. 97, pp. 325-334, 2003.[7] [on-line] http://developer.nvidia.com/cuda-downloads[8] R. F. Hess, R. J Snowden, “Temporal frequency filters inthe human peripheral visual field”, Vision Research, vol.32, pp. 61-72, 1992.[9] J.J. Koenderink, A.J. Van Doorn, “Representation of localgeometry in the Visual System”, Biol. Cybernetics, 55,pp. 367-375, 1987.[10] G. Botella, “Robust Optical Flow Implementation inReconfigurable Hardware”, PhD Thesis. Dept. ComputerArchitecture, University of Granada (Spain), ISBN 978-84-338-4381-4, 2007.[11] CUDA: Compute Unified Device Architecture., NVIDIACorporation.http://developer.nvidia.com/object/cuda.html, 2007.[12] CUDA C/C++ SDK CODE Samples, NVIDIADepeloper Zone. http://developer.nvidia.com/cuda-ccsdk-code-samplesJP2011-328

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Experiencias con Python y CUDA enComputación de Altas PrestacionesSergio Armas, Lionel Mena, Alejandro Samarín,Vicente Blanco 1 , Alberto Morales y Francisco AlmeidaResumen--- La computación paralela no ha cesado deexplorar nuevos horizontes con el objetivo de obtenermejoras tangibles de rendimiento en la ejecución dealgoritmos de toda clase. Si bien durante muchos añosse ha seguido el camino de innovar en la arquitecturade las CPU y crear software que se aproveche de esosbeneficios, la consolidación de la que vienen disfrutandoen la última década los dispositivos gráficos comohardware de cómputo general es difícil de ignorar.Este cambio de paradigma trae consigo nuevas formasde programar, nuevas herramientas y por supuesto,nuevos desafíos. El hecho de que el lenguaje C y susderivados sean la lingua franca de este tipo de programaciónno debería sorprender a propios ni a extraños,pero otros lenguajes se van haciendo huecopoco a poco. Es el caso de Python, que gracias alwrapper PyCUDA [1] es capaz de ofrecer al programadoracceso a la computación de altas prestacionessobre dispositivos gráficos sin renunciar a la comodidady dinamismo de este lenguaje. El propósito deeste artículo es comprobar las facilidades que prometePyCUDA así como su rendimiento frente a problemasreales.Palabras clave--- Python, CUDA, PyCUDA, Py-CUBLASI. IntroducciónLa capacidad de cómputo de las unidades de procesamientográfico (GPU) ha alcanzado en los últimosaños un desarrollo notable, que ha crecido de maneraparalela a un fuerte incremento en la produccióny demanda de dispositivos que las integran, talescomo smartphones, tablets, etc., además de seguirpresentes en tarjetas gráficas o placas base con cadavez más relevancia. Precisamente, dicho aumento depotencia ha comenzado a hacer atractivo su empleopara la manipulación de cantidades masivas de datosen ámbitos ajenos al del video tales como criptología,biología computacional, cálculo científico etc., que,por su naturaleza paralela, son susceptibles de ejecutarsecon más eficiencia, incluso, que en una CPUtradicional. Esta técnica de usar la GPU en aplicacionesque tradicionalmente se habían ejecutado enCPU recibe el nombre de GPGPU (General-purposecomputing on graphics processing units).A pesar de que existen diversos fabricantes especializadosen dispositivos gráficos que ofrecen algúntipo de framework para desarrollo de aplicacionesparalelas sobre GPGPU, e incluso alternativasmás generales como OpenCL [2], NVIDIA esprobablemente el que más ha apostado por este enfoque.Prácticamente desde los albores de esta computación,ha ido desarrollando un modelo de programacióndenominado CUDA (Compute Unified DeviceArchitecture) [3], que permite al programador1 Dpto. Estadística, I.O. y Computación, Univ. La Laguna,e-mail: vblanco@ull.esejecutar algoritmos casi arbitrarios en sus GPU. Ellenguaje de programación diseñado para ello es unavariación de C que contiene extensiones para trabajarcon la GPU, amén de ciertas restricciones (nopermite recursividad ni punteros a funciones, solopermite números en precisión simple en la mayoríade tarjetas lanzadas al mercado hasta ahora, etc.).El término anglosajón wrapper se emplea en computaciónpara designar, a grandes rasgos, un tipo desoftware que añade una capa de código para traducirde una interfaz existente a otra, generalmente con lafinalidad de ganar portabilidad, sencillez o compatibilidad.PyCUDA, que ha sido desarrollado por AndreasKlöckner 2 , es un ejemplo de esto: ejerce la funciónde interfaz en Python para las funciones nativasescritas en C que proporciona la SDK de NVIDIA.La principal ventaja que representa la utilización dePyCUDA en el desarrollo, en contraposición al usode las funciones propias de NVIDIA bajo C/C++, essin duda la comodidad. PyCUDA permite abstraer,por ejemplo, de todo lo relacionado con la reservay liberación de memoria en el dispositivo, lo cualhubiera representado una carga adicional de trabajodestacable en la versión C/C++. En este artículo seanalizará si las ventajas de utilizar un lenguaje interpretadode muy alto nivel para ejecutar algoritmosen una GPU compensa la menor velocidad inherentea los lenguajes interpretados.II. Acerca del modelo de programaciónCUDAEl diseño de CUDA tiene como el objetivo el desarrollode software que, de manera transparente, escaleel paralelismo de manera que se pueda aprovecharel incremento del número de procesadores al tiempoque mantiene una baja curva de aprendizaje paralos programadores familiarizados con lenguajes estándarescomo el C. Para lograr esto fundamentalmenteposee tres puntos clave:Jerarquía de hilosJerarquía de memoriaSincronizaciones por barreraA. Jerarquía de HilosSe define en base a 3 elementos: hilo, bloque y grid.Así pues, cada grid contiene bloques y estos a su vezcontienen hilos.Por conveniencia, cada hilo se identifica por unvector de tres componentes (x, y, z) denomina-2 Courant Institute of Mathematical Sciences - New YorkUniversity - http://mathema.tician.de/aboutmeJP2011-329

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011C. Sincronizaciones por BarreraComo los distintos hilos colaboran entre ellos ypueden compartir datos, se requieren directivas desincronización. En CUDA se puede especificar unasincronización del tipo barrera, en la que todos loshilos esperan a que los demás lleguen al mismo punto.Fig. 1. Jerarquía de hilos y patrones de accesodo threadIdx, así los hilos pueden identificados porun índice threadIdx unidimensional, bidimensionalo tridimensional, formando a su vez un bloque unidimensional,bidimensional o tridimensional. Estoprovee de una manera natural de realizar cálculossobre elementos tales como un vector o una matriz.B. Jerarquía de MemoriaLos hilos en CUDA pueden acceder a distintasmemorias, unas compartidas y otras privadas. Enprimer lugar tenemos la memoria local privada decada hilo. Cada bloque de hilos posee memoria compartidavisible solo por los hilos del bloque y con elmismo tiempo de vida del bloque. Finalmente cadahilo en cada bloque de cada grid puede acceder a lamemoria global.Adicionalmente existen dos espacios de memoriade sólo lectura accesible por todos los hilos: la memoriade texturas y la memoria de constante, optimizadaspara usos específicos. Las memorias global,de textura y constante persisten mientras el kernelpermanezca en acción.Asi como se puede identificar los hilos dentro deun bloque, se pueden identificar los bloques dentro deun grid, mediante una variable blockIdx que tambiénpuede ser un índice unidimensional, bidimensional otridimensional.D. KernelCUDA extiende el lenguaje permitiendo definirfunciones llamadas kernels, que cuando son invocadas,son ejecutadas N veces en paralelo por N diferentehilos de CUDA. Estas abstracciones permitenun granulado fino en el paralelismo de los datos ylos hilos, conduciendo al programador a dividir elproblema en subproblemas que pueden ser tratadosindependientemente y en paralelo por bloques de hilos,y su vez dividir estos subproblemas en elementosindividuales que pueden ser resueltos en paralelo y demanera cooperativa por todos los hilos de un mismobloque.Esta estructura preserva la expresividad dellenguaje permitiendo que los hilos cooperen en laresolución de cada subproblema, y al mismo tiempopermite la escalabilidad. En efecto, cada bloquede hilos puede ser programado en cualquier núcleode procesamiento que este disponible, en cualquierorden, concurrente o secuencialmente. Por lo quecualquier programa CUDA ya compilado puede ejecutarseen sistemas con distinto número de núcleos deprocesamiento, y solo el sistema de tiempo de ejecucióndebe conocer el dicho número de núcleos físicos.Todo esto desde el punto de vista del programadorconsiste en la extensión del lenguaje con un conjuntoreducido de instrucciones, lo que supone un curva deaprendizaje suave; cabe notar, sin embargo, que a pesarde que CUDA permite la programación de kernelscon pocas restricciones sobre el lenguaje, es necesarioadoptar ciertas pautas a la hora de generar los kernelsde las aplicaciones de interés, ya que de no seguirestas directrices el rendimiento se verá afectado severamente.Existen varias de ellas, pero las más importantesson dos: garantizar la coalescencia en el accesoa memoria (tanto en operaciones de lectura como deescritura) y usar la memoria compartida común a loshilos de un mismo bloque, para aprovechar su mayorvelocidad de acceso en comparación con la memoriaglobal del dispositivo [4]. Si se tienen en cuenta ambascaracterísticas, es muy probable que el kernel encuestión tenga un rendimiento excelente.III. Computación con PyCUDAA. Requerimientos previosAntes de nada, es conveniente mencionar quepara poder utilizar PyCUDA en una determinadamáquina de pruebas, es necesario proveer primero detodo un framework asociado que necesita dicho software.En líneas generales, PyCUDA necesita obviamentede Python instalado en el sistema, así comode NumPy/SciPy y de las librerías boost. Estos a suvez tienen algunas dependencias de software con laJP2011-330

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011b = np . random . randn (16)Aunque las más recientes GPUs soportan númerosen coma flotante de doble precisión, la mayoría delos dispositivos disponibles actualmente sólo soportanprecisión simple, por lo que se impone la siguienteconversión de tipos:a . astype ( np . float32 )b . astype ( np . float32 )Fig. 2. Software necesario para ejecutar PyCUDAque se debe tener cuidado, ya que de la correcta configuraciónde ATLAS y LAPACK, por ejemplo, vaa depender en buena medida el rendimiento posteriorde PyCUDA. Asimismo, para el ejemplo prácticodel desarrollo de un algoritmo de detección demovimiento, se impone la necesidad de disponer dealgunas librerías externas que faciliten sobremanerael manejo de imágenes y videos de manera suficientementetransparente para el usuario, como es el casode PIL y OpenCV; y todo esto en su conjunto debehacer uso de las librerias que proporciona la SDK deNVIDIA. En la figura 2 se representan de maneraclara estas dependencias de software.B. Ejecución de un kernel con PyCUDANo existe una única manera de ejecutar un algoritmoen un dispositivo con PyCUDA y, por supuesto,no todas resultan igual de eficientes. A continuación,se mostrará una sencilla secuencia de instruccionesque ilustran de manera bastante exacta el nivelde abstracción que puede llegar a alcanzarse sinmenoscabo de la eficiencia.En primer lugar, se importan los mínimos paquetesnecesarios para el funcionamiento de PyCUDA:import pycuda . autoinitimport pycuda . driver as cudafrom pycuda . compilerimport SourceModuleConviene hacer notar que aunquepycuda.autoinit se encarga de inicializar eldispositivo (seleccionando el de mayor capacidad decómputo si hay más de uno), así como de crear uncontexto automáticamente, ambos aspectos puedenser configurados manualmente.El siguiente paso consiste en cargar en memorialos datos que se desean procesar. En este punto, resultamuy aconsejable el uso del paquete NumPy dela librería SciPy, pues está provisto del potente tipode dato numpy.array, que facilita la preparación ymanipulación de los datos. En este ejemplo, consideraremosdos arrays aleatorios a y b, cuyas componentesse suman dos a dos sobreescribiendo b con elresultado.import numpy as npa = np . random . randn (16)Una vez cargados los datos en memoria, los siguientespasos son transferirlos al dispositivo y ejecutarel kernel. Con PyCUDA, ambos pasos puedenconcentrar en uno solo, porque en la propia llamadaal kernel puede estar implícita la transferenciade los datos a la memoria del dispositivo si sehace uso de la clase ArgumentHandler disponible enpycuda.driver, la cual está preparada para trabajarcon arrays numpy como argumentos de entrada/salida.kernel = SourceModule ( " " "__global__ void name( f l o a t *a ,f l o a t *b ) {i n t idx = threadIdx . x ;b [ idx ] = b [ idx ] + a [ idx ] ;}" " " )f = kernel . get_function ( " name " )f ( cuda . In ( a ) , cuda . InOut ( b ) ,block =(16 ,16 ,1))C. Overhead inducidoObviamente, el hecho de trabajar con un lenguajeinterpretado como lo es Python, y con un wrappercomo lo es PyCUDA, implica una carga de trabajoextra para el procesador (no directamente relacionadocon el cómputo en GPU) que debe ser analizaday comparada con la misma ejecución nominal en Cpara determinar si este overhead supone un gravamenaceptable o no. En la figura 3 se puede observaruna comparación al ejecutar un filtro de convoluciónseparable [5] tanto en C como en Python + PyCU-DA, separando en cada caso (para distintos tamañosde matrices cuadradas) el tiempo empleado en ejecutarúnicamente el kernel en GPU y el programacompleto (que engloba reserva de memoria, creacionde los arrays aleatorios, instanciacion del kernel, liberacionde memoria... así como el tiempo de ejecucióndel propio kernel en la GPU). Como se puedeobservar, y como era de esperar, los kernels se ejecutansiempre ligeramente más rápidos en C (un 50 %más rápido como mínimo, aunque hay que recordarque en estos niveles se habla de milisegundos paraprocesar matrices cuadradas del orden de 2048x2048elementos). Sin embargo, en el tiempo total de ejecuciónse puede observar como lo que a priori deberíaser una ventaja para C, a partir de 2048x2048 elementosel programa en C tarda de hecho más que elmismo programa en Python. Esto puede deberse aJP2011-331

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Kernel para un filtro de convolución: C y PyCUDAFig. 4. Producto de matrices en CUDA: C y PyCUBLASdiversas razones: en C, los arrays a procesar se rellenancon números aleatorios obtenidos mediante lafunción rand(), mientras que en Python es NumPyel encargado de generar las matrices aleatorias. Esconocida la gran eficiencia de NumPy a la hora demanejar matrices de gran tamaño, por lo que este detallepuede jugar a su favor. Otro posible punto dedivergencia (ya que aunque los programas sean funcionalmenteiguales, evidentemente hay ciertos elementosdel lenguaje que están programados de formadistinta) sea la utilización de los timers propiosde NVIDIA para realizar las medidas en C (a travésde la librería proporcionada por la SDK shrUtils);sería interesante comprobar hasta que punto están ono interfiriendo estos timers particulares en las medicionestotales.En cualquier caso, puede comprobarse como eloverhead que introduce la utilización de Python +PyCUDA no es, en ningún caso, alarmante. Sí quees necesario hacer notar, sin embargo, que en el casode las primeras ejecuciones de algún programa queuse PyCUDA, la fase de carga de los import inicialessí que es importante, llegando a tardar los mismosejemplos de la figura 3 cerca de 2 segundos, y dondela mayoría de los cuales se emplea en la precarga deestas directivas del wrapper: comunicación inicial conel/los dispositivos existentes, selección de dispositivo,carga de la interfaz con el compilador de NVIDIAnvcc, etc.IV. Producto matricialLa manera tradicional de abordar la multiplicaciónde matrices pasa por ejecutar un algoritmo secuencialde complejidad casi cúbica en las mejores implementaciones.Su versión paralela, en cambio, permiteel cálculo simultáneo de las filas de la primera matrizmultiplicando con la correspondiente columna de lasegunda para formar el resultado.BLAS (Basic Linear Algebra Subprograms) es, defacto, una interfaz estándar de programación de libreríasque realizan operaciones básicas de álgebralineal con vectores y/o matrices.Desde su primera publicación, en 1979, numerososfabricantes de hardware han desarrollado versionesaltamente optimizadas de BLAS. También NVIDIAlo ha incluido en el SDK de CUDA para proporcionaruna versión de altas prestaciones para estas operaciones.Dicha implementación ha sido denominadaCUBLAS.Por su parte, PyCUBLAS es un wrapper [6] dePython para CUBLAS creado por Derek Andersonque ha centrado su diseño en la multiplicación degrandes matrices. Dispone, además, de las ventajasya comentadas de Python en cuanto a abstracción,lo que posibilita la ejecución de una operación conmuy pocas líneas de código.import numpy as npfrom pycublas import CUBLASMatrixa = np . random . randn ( width , length ) .astype ( np . float32 )b = np . random . randn ( width , length ) .astype ( np . float32 )a = CUBLASMatrix ( np . mat ( a ) )b = CUBLASMatrix ( np . mat ( b ) )c = a * bEsta sencillez sintáctica podría ser atractiva paraextender el uso de CUDA entre investigadores deotras ciencias cuyos estudios precisen de la manipulaciónde cantidades masivas de datos.En esta sección se confrontan el tiempo de ejecuciónen el dispositivo de una multiplicación de matricescuadradas de diferentes dimensiones, tanto através de PyCUBLAS como de su correspondienteversión nativa en C. No se ha contemplado en la gráficade la figura 4 los tiempos de ejecución en la CPU,puesto que estos llegan a ser hasta 35 millones de vecesmayor en el caso de una matrix de 2048x2048.V. Detección de movimientoTeniendo en cuenta las posibilidades del modeloCUDA exploradas hasta ahora, parece lógico buscaralgún algoritmo que conlleve un esfuerzo computacionalnotable para ir un paso más allá en la exploracióndel uso de Python como vehículo conductorde los programas de cómputo. Una primera consideracióninteresante es el RANSAC [7], un algoritmoutilizado frecuentemente en campos muy diversos,pero no resulta fácilmente acomodable al cómputoJP2011-332

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 5. Jerarquía de clases del detector de movimientoparalelo bajo esta arquitectura debido a que requierede estructuras de datos complejas que además contemplanmúltiples dependencias entre ellas.Finalmente, se ha escogido como objetivo de desarrolloel diseño e implementación de un paquete quepermita aplicar diferentes filtros a una imagen, a unconjunto de imágenes o a un video, en cuyo caso serádescompuesto en sus correspondientes frames. Estepaquete puede utilizarse para acelerar el cálculo deaplicaciones complejas que requieran de la aplicaciónde filtros [8]. En concreto, una de las más interesantesconsiste en un programa de detección de movimiento:a grandes rasgos, toma 2 frames de un video ydiscierne (marcando en color rojo sobre uno de losframes original) las partes en movimiento entre losmismos. Esto mismo se ejecuta de manera iterativael número de veces necesario para realizar la detecciónde movimiento sobre un video compuesto de unamultitud de frames.El paquete Filters desarrollado para este fin seestructura, esencialmente, en torno a dos clases:CUDAHandler, concebido para abstraer de muchosdetalles de la comunicación con la GPU (informalmente,podría considerarse un wrapper del propio Py-CUDA); y Filter, clase abstracta de la que heredancada uno de los filtros implementados. En la figura5, pueden observarse tres clases hijas de Filterque contienen las instrucciones para gestionar tresfiltros necesarios para la detección de movimiento(Difference, Threshold y Erosion), como se explica enla posterior subsección. También se contempla unaclase MotionDetector, encargada de dirigir la detecciónen sí aplicando los filtros frame tras frame y quehace uso del paquete Filters, además por último dela clase VideoHandler que la abstrae de la manipulaciónde las operaciones de gestión de vídeo.A. Implementación del algoritmoEl algoritmo de detección de movimiento más simplese basa en la aplicación de una secuencia de filtrossobre los frames (imágenes) del video [9]. Paraentender el proceso basta con escoger 2 frames consecutivosdel video y aplicar los siguientes pasos:1. Conversión a escala de grises de las 2 imágenes2. Aplicación del filtro de diferencia a las 2 imágenes3. Aplicación del filtro Threshold4. Aplicación del filtro de Erosión5. Mezcla en el canal R de la imagen original conla imagen resultado de los filtrosUna vez obtenidos las 2 imágenes en escala de grises,se procede a aplicar el primer filtro:Filtro de Diferencia: Este filtro consiste en elvalor absoluto de la resta de cada píxel (restandocanal a canal en caso de imágenes de varios canales)de las dos imágenes. Con esto obtenemos las zonasdonde se ha producido movimiento, como se puedeobservar en la primera imagen de la figura 6.Filtro Threshold: La finalidad de este filtro esobtener una imagen binaria donde solo aparecen píxelesblancos o negros. Este filtro compara cada píxelcon un umbral, y si el valor del píxel está por debajose asigna el valor 0 (negro), en caso contrario (porencima del umbral) se asigna el valor 255 (blanco).Así pues, la imagen resultante quedaría como la segundaimagen de la figura 6, donde además se apreciala aparición de ruido a simple vista.Filtro de Erosión: Contenido dentro los llamadosFiltros Morfológicos, este filtro determina si unpíxel se mantiene (se define como blanco) o se elimina(se define como negro). Para sopesar esta decisiónse hace uso de una máscara (definida a conveniencia)que determina los píxeles vecinos a examinar; desdeque al menos uno de estos vecinos esté en negro, seelimina el píxel analizado (operación and lógica. Porel contrario, si todos los píxeles vecinos existen el píxelanalizado permanecerá en blanco. El objetivo deaplicar este filtro es eliminar el ruido expuesto por elfiltro anterior, como se puede apreciar en la terceraJP2011-333

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011la misma como por rendimiento, a cambio de un pequeñoe inevitable overhead inherente a la naturalezainterpretada de Python y al uso de wrappers. Decualquier forma, ese incremento en tiempo es lo suficientementedespreciable para que se pueda ignorarsin temor, máxime si se tiene en cuenta el hecho deque a mayor tamaño del problema, más imperceptiblese torna dicha carga de trabajo adicional. Por último,pero no por ello menos importante, los autoresdesean recalcar que la curva de aprendizaje necesariapara poder manejarse en este entorno con ciertasolvencia es considerablemente más suave que laque conlleva el entorno tradicional de programaciónde CUDA bajo C/C++, lo cual consideran un argumentode suma importancia para atraer usuariospotenciales, ya sean académicos de nueva hornadao investigadores asentados que tienen necesidad decálculo masivo paralelo y que utilizan para ello aplicacionesdesarrolladas hace años en lenguajes comoFORTRAN cuyo mantenimiento se hace cada vezmás inviable. En definitiva, si se tiene intención demigrar estas aplicaciones, Python y PyCUDA conformanuna alternativa perfectamente capaz.Fig. 6. Fases del algoritmo de detección de movimientoimagen de la figura 6.Por último, queda realizar el fundido en el canalR de la imagen original con la imagen resultante deaplicar el filtro de erosión. Este fundido no es más queuna suma de píxel a píxel, obteniendo así el resultadofinal de la figura 6.VI. ConclusionesComo se ha podido observar, implementar la resoluciónde problemas relativamente complejos noes especialmente costoso en tiempo con lenguajesdinámicos como Python. Si a eso se le añade la posibilidadde utilizar todo el potencial de cómputo paraleloque ofrece CUDA a través de wrappers comoPyCUDA, el resultado es una herramienta muy potenteque puede satisfacer las necesidades de investigadoresy científicos en general tanto por madurez deReferencias[1] Andreas Klöckner, Nicolas Pinto, Yunsup Lee, Bryan C.Catanzaro, Paul Ivanov, and Ahmed Fasih, ``Pycuda:Gpu run-time code generation for high-performance computing,''CoRR, vol. abs/0911.3456, 2009.[2] Khronos Group, ``OpenCL - The open standard for parallelprogramming of heterogeneous systems,'' 2011.[3] NVIDIA Corp., ``What is CUDA - NVIDIA DeveloperZone,'' 2011.[4] NVIDIA Corp., ``NVIDIA CUDA C Best PracticesGuide,'' 2010.[5] Victor Podlozhnyuk (NVIDIA Corp.), ``Image Convolutionwith CUDA,'' 2007.[6] Derek Anderson, ``PyCUBLAS - EasyPython/NumPy/CUDA/CUBLAS Integration,'' 2009.[7] Liu Jiayin, Wang Chuang, and Jae Ho Kim, ``Camera motiondetection for conversation scenes in movies,'' in Proceedingsof the 2010 International Conference on Computationaland Information Sciences, Washington, DC, USA,2010, ICCIS '10, pp. 725--728, IEEE Computer Society.[8] Zhiyi Yang, Yating Zhu, and Yong Pu, ``Parallel imageprocessing based on cuda,'' in CSSE (3). 2008, pp. 198--201, IEEE Computer Society.[9] Andrew Kirillov, ``Motion detection algorithms,'' 2007.JP2011-334

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A Scalable Visualization System for CrowdSimulationsGuillermo Vigueras, Juan M. Orduña, Miguel Lozano y Víctor Fernández-Bauset 1Abstract— The visualization system of large-scalecrowd simulations should scale up with both the numberof visuals (views of the virtual world) and thenumber of agents displayed in each visual. Otherwise,we could have large scale crowd simulationswhere only a small percentage of the population isdisplayed. Several approaches have been proposed inorder to efficiently render crowds of animated characters.However, these approaches either render crowdsanimated with simple behaviors or they can only supporta few hundreds of user-driven entities. In thispaper, we propose a distributed visualization systemfor large crowds of autonomous agents that allows thevisualization of the crowd without adding significantoverhead to the simulation servers. The proposed implementationcan be hosted on dedicated computersdifferent from the servers, and it takes advantage ofthe Graphics Processor Unit (GPU) capabilities. Asa result, the performance evaluation shows that thousandsof agents can be rendered without affecting theperformance of the simulation servers. These resultssuggest that the design of the visual client allows toadd multiple visuals for displaying large crowds.Keywords— Distributed simulation, parallel renderingI. IntroductionLA rge scale crowd simulations are becoming essentialtools for many virtual environment applicationsin education, training, and entertainment [1],[2]. In order to deal with the computational complexityof large scale simulations, different proposals havebeen made for achieving both very populated scenes[3] and scalable autonomous behaviors [4], [5]. However,the scalability of autonomous complex agents(crowd simulations) is still an open issue in spite ofthese efforts.In previous works, we proposed a distributed systemarchitecture that can simulate large crowds ofautonomous agents at interactive rates [6], [7], [8],and it can take advantage of the inherent scalabilityof manycore computer architectures [9]. However, inorder to make a truly scalable system for crowd simulations,the visualization system (the module responsibleof rendering the images of the virtual world)should also be addressed. The visualization systemshould scale up with both the number of visuals(cameras focusing on the virtual world) and the numberof agents displayed in each camera. Otherwise,we could have large scale crowd simulations whereonly a small percentage of the population could berendered (displayed).In this paper, we propose a distributed visualizationsystem that allows the visualization of the virtualworld without adding significant overhead to thesimulation servers, regardless of both the number of1 Dpto. de Informática, Univ. de Valencia e-mail:{Guillermo.Vigueras,Juan.Orduna}@uv.esvisuals and the number of agents rendered by eachvisual. In order to achieve this goal, the visualizationsystem consists of a visual client process (VCP)for each camera, and each VCP is hosted on a computerdifferent from the ones hosting the simulationservers. In this way, the connection of the visualclient does not significantly affects the performanceof the simulation system. The proposed implementationmigrates different rendering tasks of the VCPfrom the CPU to the Graphics Processor Unit (GPU)of the hosting computer, reducing the CPU workloadof the visual client and increasing throughput. Also,we use skinned instancing for reducing the renderingworkload. As a result, the performance evaluationshows that thousands of agents can be renderedwithout affecting the performance of the simulationservers. These results suggest that the design of thevisual client allows to add multiple visuals for displayinglarge crowds.The rest of the paper is organized as follows: sectionII shows some related work about visual clientsfor crowd simulations. Section III briefly describesthe distributed architecture for crowd simulationthat was previously proposed, and it shows the scalabilityproblems arising when connecting a VCP tothis kind of systems. Next, section IV describes theproposed implementation for the distributed visualclient, and section V shows the performance evaluationof the proposed implementation. Finally, sectionVI shows some conclusions.II. Related WorkFrom the graphics community, several approacheshave been proposed in order to efficiently rendercrowds of animated characters. Image-based [10] andPoint-based [11] techniques obtain interactive framerates when rendering crowded animated scenes byreducing the geometrical complexity of the 3D charactersmeshes. Other approaches use efficient parallelgraphic techniques to provide interactive graphicsperformance for crowded scenes [12]. Although thesegraphic-based approaches obtain good frame rates,they are not focused on providing scalable architectures.Other proposals [13] combine parallel architectureswith efficient graphic techniques to simulateand to display thousands of individuals. In this case,authors use the Cell processor architecture withoutconsidering scalability issues.From the distributed simulation arena, there havebeen several approaches oriented to handle multiplayergames [14], [15]. Other works use the HLAarchitecture [16] combining classical scene graphswith simulated federations to provide interactiveJP2011-335

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011graphic applications for military and entertainmentpurposes.Although these approaches can provide interactivelatencies and frame rates, required by multiplayergames, they usually can only support a few hundredsof user-driven entities within a simulation.III. A Distributed System for Large-ScaleCrowd SimulationIn previous works, we proposed an architecturethat can simulate large crowds of autonomous agentsat interactive rates [6], [7]. In that architecture, thecrowd system is composed of many Client Computers,that host agents implemented as threads of aClient Process, and one Action Server (AS), executedin one computer, that is responsible for checking theactions (eg. collision detection) sent by agents [6].In order to avoid server bottleneck, the simulationworld was partitioned into subregions and each oneassigned to one parallel AS [7]. A scheme of thisarchitecture is shown in figure 1. This figure showshow the 2D virtual world occupied by agents (blackdots) is partitioned into three subregions, and eachone managed by one parallel AS (labeled in the figureas AS x ). Each AS is hosted by a different computer.Agents are execution threads of a Client Process (labeledin the figure as CP x ) that is hosted on oneClient Computer. The computers hosting client andserver processes are interconnected. Each AS processhosts a copy of the Semantic Database. However,each AS exclusively manages the part of thedatabase representing its region. In order to guaranteethe consistency of the actions near the borderof the different regions (see agent k in figure 1), theASs can collect information about the surroundingregions by querying the servers managing the adjacentregions. Additionally, the associated Clients arenotified about the changes produced by the agents locatednear the adjacent regions by the ASs managingthose regions.The architecture shown in Figure 1 allows to simulatelarge crowds of autonomous agents providing agood scalability. However, it also needs a scalable visualizationmethod in order to render the simulatedcrowd. The visualization system will be in chargeof rendering the simulated world, starting from theinformation generated by the distributed servers. Inorder to provide scalability, the visualization systemshould be designed in a distributed fashion.A feasible way of implementing a distributed visualizationsystem could be the integration of a renderingmodule within each Action Server. In thisway, each AS could visualize its own region of thevirtual world. However, the computational workloadresulting from adding a rendering module to eachAS could result in a performance degradation of thewhole simulation system [17]. Additionally, with thisapproach the number of cameras would be limitedby the number of servers in the system. Instead, wehave followed a different approach, where the visualizationof the simulation is distributed among dif-Fig. 1. General scheme of the distributed simulation systemwith a Visual Client Process.ferent processes, each one denoted as Visual ClientProcess (VCP). Each VCP manages one camera, andit is hosted in a dedicated computer different fromthe ones hosting either CPs or ASs. A VCP can beconnected to several different ASs, depending on thearea of the virtual world covered by the camera ofthe VCP. For example, in Figure 1 the VCP is connectedto both AS 1 and AS 2 , since the projection ofthe camera plane (denoted as MBR Frustum) intersectsthe regions managed by these ASs.In order to efficiently designing the rendering moduleof the VCP, the first step consists of measuringthe workload that the information received from theASs represents for a single VCP. The amount of informationsent by the ASs depends on two factors: thenumber of simulated agents and the acting period ofthose agents (the period of time between two successiveactions requested by an agent). Table I showsthe percentage of CPU utilization in the computerhosting the VCP when increasing both the numberof agents in the MBR Frustum and the acting period.The results were obtained using up to four servers,each one managing 3000 agents (12000 agents in totalfor four servers). In these tests, the VCP wereconnected to the servers and all the agent requestsreceived by the servers were sent to the VCP, i.e. theVCP received updates from 12000 agents when usingfour servers. Table I shows that the VCP workloadexceeds the computational bandwidth of the hostingcomputer when 6000 agents (2 servers) are connectedto the VCP, since the percentage of CPU utilizationreaches 100%. Also, this table shows that the workloadgenerated by the VCP is inversely related to theacting period, as it could be expected.In order to find how the saturation of the CPU affectsthe performance of the VCP, we have measuredJP2011-336

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE ICPU utilization (%) of the computer hosting the VCP.Agents Acting Period (ms.)100 400 700 10003000 69 67 65 556000 100 100 100 1009000 100 100 100 10012000 100 100 100 100the difference between the number of operations sentby the ASs and the number of operations actuallyprocessed by the VCP. Table II shows these data,and it shows that for 3000 agents there are no lostoperations (the CPU hosting the VCP is not saturated,reaching a maximum CPU utilization of 69%for the lowest acting period (100 ms). However, from6000 agents up, the VCP does not process all the requests,depending on the agent period. It is worthmention that for the case of 6000 agents the VCP iscapable of process all the operations received whenusing an acting period of 700 and 1000 ms. However,when simulating 12000 agents the VCP cannot processall the operations, regardless of the agent periodconsidered. These results show that the implementationof the VCP should reduce the CPU utilizationassociated to the graphic tasks as much as possible,in order to increase the VCP throughput.or received from other ASs and CPs are exchangedasynchronously. This means that the AE threadsonly may have to wait when accessing the semanticdatabase.The changes required in the Action Server forconnecting the VCP exclusively affects the InterfaceModule. Figure 2 shows the general scheme of an ActionServer modified for accepting VCP connections.Two I/O threads are created for each VCP connectedto an AS. One of the I/O threads receives, through asocket, the MBR frustum updates sent by the VCP.It must be noticed that the updates received fromthe VCP are not passed to the Crowd AS ControlModule. In this way, the workload added by eachVCP connected to the AS is reduced. The other I/Othread is in charge of forwarding to the VCP theAS replies to agents requests. This thread uses theMBR frustum updates received from the VCP to filterforwarded replies. It simply checks whether anagent falls within the MBR frustum or not (see Figure1). In this way, a VCP can visualize less agentsthan those that form the crowd simulated by the distributedsystem.TABLE IIVisualization requests not processed by the VCP.AgentsActing Period (ms.)100 400 700 10003000 0 0 0 06000 76207 44729 0 09000 205545 238244 61972 012000 433716 391644 157606 19137IV. Distributed Rendering of CrowdSimulationsIn this section we describe the proposed implementationof the Visual Client Process. The proposedapproach for rendering crowd simulation is based onhaving each VCP connected with one or more ActionServers. Therefore, the first step is to modifythe AS scheme proposed in [7] in such a way thatthe information about the agent actions is also sentto the VCPs. Then, an implementation of the VCPaccording to that scheme should be developed.A. Modifications to the Action ServerEach AS process [7] contains three basic elements:the Interface module, the Crowd AS Control (CASC)module and the Semantic Data Base (SDB). The Interfacemodule is in charge of communicating theAS with other ASs and CPs. The main module isthe Crowd AS Control module, which is responsiblefor executing the crowd actions. This module containsa configurable number of threads for executingactions (action execution threads). For an actionexecution thread (AE thread), all messages sent toFig. 2.Scheme of an Action Server with VCP connections.B. Implementation of the Visual Client ProcessThe VCP is mainly composed by two modules: theInterface Module and the Graphic Application Module.Figure 3 shows an schematic view of this process.The Interface Module is in charge of sending updatesof the MBR frustum to the ASs. Also , this moduleshould receive agents updates and pass them to theGraphic Application Module. The Graphic ApplicationModule is in charge of performing the graphictasks. Some of these tasks are executed on the CPUand other ones are executed on the GPU.As shown in section III, it is crucial to reduce asmuch as possible the percentage of CPU utilization inthe computer hosting the VCP in order to minimizethe number of visualization updates not processedby the VCP. In order to achieve this goal, the frustumculling and the determination of the Level OfJP2011-337

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Detail (LOD) are performed by the GPU, like otherapproaches do [18].Additionally, we use Instancing to efficiently rendercrowded scenes [19]. When rendering a 3D mesh,typical graphic APIs issue a Draw call to the graphicpipeline. Each API call has associated a fixed-costoverhead for processing a primitive, regardless of thesize. Due to this API call overhead, the performanceof a graphic application (in terms of Frames PerSecond or FPS) is CPU-bounded instead of GPUbounded.Instancing consists in grouping charactersthat share a 3D mesh into a batch, generating onlyone Draw call. However, when using Instancing charactershave to share both the mesh and the poseat a given time. Since a crowd is composed of autonomousagents, each one has a different pose at agiven time. As a result, the use of Instancing providesnon-realistic movements. In order to solve thisproblem, we have implemented the VCP using theSkinned Instancing technique [20]. This techniquetakes advantage of the new DirectX graphic API,that allows to perform Instancing but generating anidentifier for each instance of the 3D mesh. In thisway, each instance can keep its own properties (i.e.translation, rotation and scale) and the GPU skinningmethod [12] can be independently applied toanimate the character meshes.Figure 3 shows a scheme of the VCP and the differenttasks of each part of the Graphic Module. TheCPU part of this Module acts as an interface withthe user, updating the camera position according tothe MBR frustum. All the MBR frustum updatesare passed to the Interface Module in order to sendthem to the ASs. Additionally, the CPU processesthe agents updates received by the Interface Moduleand formates this data in order to properly performthe skinned instancing on the GPU. Once theGPU part of the Graphic Module receives agents updatesthrough a vertex buffer, it firstly perform theview frustum culling and the LOD determination.As a result, agents that have passed the culling testare grouped by LOD and one GPU buffer is usedto store agents sharing the same LOD. Since we areusing three LODs, three buffers are the input of theSkinned Instanced step. Once the instanced meshesare properly animated, they are rendered.V. Performance EvaluationFig. 3.Scheme of the design of the Visual Client Process.In this section, we show the performance evaluationof the proposed distributed visual client. Likeother distributed systems, the most important performancemeasurements in these systems are latencyand throughput. However, since we are focusing onthe visual client performance and how the integrationof a VCP affects to the overall system (crowdsimulation) performance, we have performed simulationswith different servers and we have measuredboth the response time of the servers and frames rateobtained in the VCP. In order to define an acceptablebehavior for the system, we have considered 250 ms.as the maximum acceptable value for the responsetime, since it is considered as the limit for providingrealistic effects to users in DVEs [21]. For the VCP,we have considered about 30 frames per second as anacceptable frame rate.As a simulation platform, we have used a clusterof computers based on AMD Opteron (2 processors@ 1.56 GHz) with 3.84GB of RAM, executing Linux2.6.9-1 operating system. The interconnection networkin the cluster was a Gigabit Ethernet network.The machine used for the visual client was based onIntel Core 2 Duo @ 2.4 GHz with 4GB of RAM,executing Windows Vista operating system. Thegraphic card within the VCP was a NVIDIA GForce9600M GT. We have performed the distributed simulationsusing up to four computers of the clusterfor hosting an AS each. For that case, we used eightcluster nodes (four of them for hosting the serversand four of them for hosting four clients). Usingthis platform, we have simulated up to twelve thousandagents. The VCP was connected to the serversthrough the cluster network and the number of agentupdates received by the VCP was increased in orderto study the VCP performance.For comparison purposes, we have implementedthree different VCPs. The first one (denoted as SDC,for ”separate draw calls”) does not use Instancingto render the crowd and performs the LOD computationon the CPU. The second version (denotedas iCPU) uses Skinned Instancing and it computesthe LODs on the CPU. Finally, and the third kindof VCP (denoted as iGPU) uses Skinned Instancingand performs the LOD calculations on the GPU. Figure4 shows the CPU load of the different versions ofthe visual client when the number of rendered agentsis increased. In this figure, the X-axis shows theJP2011-338

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011number of rendered characters and the Y-axis showsthe percentage of CPU utilization when executingthe VCP. This figure shows very much higher CPUutilization load for the SDC version than the one requiredfor the iCPU and iGPU versions. This versionof the VCP leads the CPU close to saturation levelsfor 5000 agents due to the absence of Instancing,while the other two versions only require less than a50% of CPU utilization. This figure also shows thatthe iGPU version 3 reduces the percentage of CPUutilization around a 10% respect to the iCPU version.Therefore, the version that provides the bestresults in terms of visual throughput (the maximumnumber of characters that can be rendered) is theiGPU implementation of the VCP.Figure 5 shows the performance of the differentversions of the VCP in terms of FPS. In this figure,the X-axis shows the number of rendered agentsand the Y-axis shows the frame rate achieved by theVCP. It can be seen that both the iCPU and theiGPU versions clearly outperform the SDC version.The reason for that behavior is that the SDC versionsaturates the CPU. However, there is no a significantdifference between the frame rates obtained by theiCPU and the iGPU versions of the VCP becauseboth of them use Instancing. Therefore, they generatethe same number of draw calls. Since the iGPUprovides the best throughput and a similar framerate than the iCPU version, we have used this versionas the VCP implementation for the rest of theevaluation.Fig. 4. CPU utilization for different implementations of theVCP.Once the version of the VCP that provides thebest performance has been selected, the next stephas been to study the performance of that VCP whenit is connected to the crowd simulation system. TableIII shows the performance measurements for theVCP when the number of agents updates receivedfrom the ASs is increased. It can be seen that whenrendering 2000 agents at a good frame rate the CPUutilization is around 87% and no agents updates arelost (all the requests are processed by the VCP). Asthe number of agent rendering requests increases, sodoes the CPU utilization, causing a frame rate decreaseon the VCP but still above acceptable valuesFig. 5. Frame rates for different implementations of the VCP.(higher than 30 FPS). However, from 5000 agents upto 6000 agents the CPU reaches saturation, resultingin agents updates that are not processed and causingthe frame rate to fall below 30 FPS.TABLE IIIPerformance measurements for the VCP whenincreasing the number of agents updates received.Characters rendered2000 3000 4000 5000 6000% CPU 86,7 89,3 94 95,7 98,8FPS 55,4 41,6 34,8 28,4 25,4Lost ops. 0 0 0 34134 57348Finally, we have studied the performance of thesimulation servers when the VCP is connected, inorder to show that the latter one does not have a significanteffect on the servers performance. Figures 6and 7 show the performance of the simulation systemwhen the VCP is connected to a simulation systemconsisting of four servers and the number of agentsupdates sent to the VCP is increased. In these figures,the X-axis shows the number of agents updatesthat the VCP receives. The Y-axis in figure 6 showsthe CPU utilization in the system servers, while theY-axis in figure 7 shows the response time (in ms.)provided to agents (that are executed as threads ofthe client processes).Figure 6 shows that the CPU utilization in the systemservers remains almost constant as the numberof agents rendered by the VCP increases. It startsfrom a CPU utilization of 80% for 2000 agents andfor 6000 agents it does not reach 90%. Since the VCPdoes not lead the system servers to saturation, figure7 shows that they provide an acceptable responsetime (shorter than 250 ms.) up to 6000 agents. Theseresults show that the VCP does no have significanteffects on the performance of the system servers.VI. ConclusionsIn this paper, we have proposed a distributed visualizationsystem that allows the visualization of thevirtual world without adding significant overhead tothe simulation servers. The proposed implementationcan be hosted on dedicated computers differentJP2011-339

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 6. CPU utilization of simulation servers with a connectedVCP.Fig. 7. Response time provided by simulation servers with aconnected VCP.from the servers, and it migrates different renderingtasks of the VCP from the CPU to the GPU of thehosting computer. Also, we use skinned instancingfor reducing the rendering workload. As a result,the performance evaluation shows that thousands ofagents can be rendered without affecting the performanceof the simulation servers. These results suggestthat the design of the visual client allows to addmultiple visuals for displaying large crowds.AcknowledgementsThis work has been jointly supported by the SpanishMICINN, the European Commission FEDERfunds, and the University of Valencia under grantsConsolider-Ingenio CSD2006-00046 and TIN2009-14475-C04-04.references[1] Ameya Shendarkar, Karthik Vasudevan, Seungho Lee,and Young-Jun Son, “Crowd simulation for emergencyresponse using bdi agent based on virtual reality,” inWSC ’06: Proceedings of the 38th conference on Wintersimulation, 2006, pp. 545–553.[2] Dan Chen, Georgios K. Theodoropoulos, Stephen J.Turner, Wentong Cai, Robert Minson, and Yi Zhang,“Large scale agent-based simulation on the grid,” FutureGeneration Computer Systems, vol. 24, no. 7, pp. 658 –671, 2008.[3] Adrien Treuille, Seth Cooper, and Zoran Popovic, “Continuumcrowds,” in SIGGRAPH ’06: ACM SIGGRAPH2006 Papers. 2006, pp. 1160–1168, ACM.[4] A. Iglesias and F. Luengo, “New goal selection schemefor behavioral animation of intelligent virtual agents,”IEICE Transactions on Information and Systems, vol.E88-D, no. 5, pp. 865–871, 2005.[5] Huaglory Tianfield, Jiang Tian, and Xin Yao, “On thearchitectures of complex multi-agent systems,” in Proc.of the IEEE/WIC International Conference on Web Intelligence/ Intelligent Agent Technology,. 2003, pp. 195–206, IEEE Press.[6] M. Lozano, P. Morillo, J. M. Orduña, V. Cavero, andG. Vigueras, “A new system architecture for crowd simulation,”J. Netw. Comput. Appl., vol. 32, no. 2, pp.474–482, 2009.[7] G. Vigueras, M. Lozano, C. Pérez, and J.M. Orduña, “Ascalable architecture for crowd simulation: Implementinga parallel action server,” in Proceedings of InternationalConference on Parallel Processing (ICPP), Los alamitos,CA, USA, 2008, pp. 430–437, IEEE Computer Society.[8] G. Vigueras, M. C. Lozano, J.M. Orduña, andF. Grimaldo, “A comparative study of partitioning methodsfor crowd simulations,” Appl. Soft Comput., vol. 10,no. 1, pp. 225–235, 2010.[9] G. Vigueras, J. M. Orduña, and M Lozano, Advancesin Practical Applications of Agents and Multiagent Systems,chapter A GPU-Based Multi-agent System forReal-Time Simulations, pp. 15–24, Springer Berlin / Heidelberg,2010.[10] Simon Dobbyn, John Hamill, Keith O’Conor, and CarolO’Sullivan, “Geopostors: a real-time geometry/impostorcrowd rendering system,” ACM Trans. Graph., vol. 24,no. 3, pp. 933–933, 2005.[11] Michael Wand and Wolfgang Straßer, “Multi-resolutionrendering of complex animated scenes,” Comput. Graph.Forum, vol. 21, no. 3, 2002.[12] Golam Ashraf and Junyu Zhou, “Hardware acceleratedskin deformation for animated crowds,” in 13th InternationalMultimedia Modeling Conference, MMM. 2007,pp. 226–237, Springer.[13] Craig Reynolds, “Big fast crowds on ps3,” in Proceedingsof the 2006 ACM SIGGRAPH symposium onVideogames, New York, NY, USA, 2006, pp. 113–121.[14] Ashwin Bharambe, Jeffrey Pang, and Srinivasan Seshan,“Colyseus: a distributed architecture for online multiplayergames,” in NSDI’06: Proceedings of the 3rd conferenceon Networked Systems Design & Implementation,Berkeley, CA, USA, 2006, pp. 12–12.[15] Alma V. Martinez, Héctor Rafael Orozco, Félix F. RamosCorchado, and Mario Siller, “A peer-to-peer architecturefor real-time distributed visualization of 3d collaborativevirtual environments,” in 13th IEEE/ACM InternationalSymposium on Distributed Simulation and RealTime Applications, 2009, pp. 251–254.[16] Hua Xiong, Zonghui Wang, Xiaohong Jiang, and JiaoyingShi, “Building high performance DVR via HLA, scenegraph and parallel rendering,” in Proc. of the 2007 ACMsymposium on Virtual reality software and technology,New York, NY, USA, 2007, pp. 141–144.[17] P. Morillo, J. M. Orduña, M. Fernández, and J. Duato,“Improving the performance of distributed virtual environmentsystems,” IEEE Transactions on Parallel andDistributed Systems, vol. 16, no. 7, pp. 637–649, 2005.[18] Hunki Park and Junghyun Han, “Fast rendering of largecrowds using GPU,” in ICEC ’08: Proceedings of the 7thInternational Conference on Entertainment Computing,Berlin, Heidelberg, 2009, pp. 197–202, Springer-Verlag.[19] Tomas Akenine-Möller, Eric Haines, and Natty Hoffman,Real-Time Rendering 3rd Edition, A. K. Peters, Ltd.,Natick, MA, USA, 2008.[20] B. Dudash, “Skinned instancing,” Tech. Rep., NVIDIACorp., February 2007.[21] T. Henderson and S. Bhatti, “Networked games: a qossensitiveapplication for qos-insensitive users?,” in Proceedingsof the ACM SIGCOMM 2003. 2003, pp. 141–147, ACM Press / ACM SIGCOMM.JP2011-340

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A New Approach to rCUDAJosé Duato, Antonio J. Peña, and Federico Silla 1Juan C. Fernández, Rafael Mayo, and Enrique S. Quintana-Ortí 2Abstract— In this paper we propose a first step towardsa general and open source approach for usingGPGPU (General-Purpose Computation on GPUs)features within virtual machines (VMs). In particular,we describe the use of rCUDA, a GPGPU virtualizationframework, to permit the execution ofGPU-accelerated applications within VMs, thus enablingGPGPU capabilities on any virtualized environment.Our experiments with rCUDA in the contextof KVM and VirtualBox on a system equippedwith two NVIDIA GeForce 9800 GX2 cards illustratethe overhead introduced by the rCUDA middlewareand prove the feasibility and scalability of this generalvirtualizing solution.Keywords— CUDA, GPUs, GPGPU, high performancecomputing, virtual machines, virtualization.I. IntroductionMANY-CORE specialized processors and, inparticular, graphics processors (GPUs), are experiencingincreased adoption as an appealing wayof reducing the time-to-solution in areas as diverseas finance [1], image analysis [2], and many others.These hardware accelerators offer a large amount ofprocessing elements and high processor-to-memorybandwidth, so that applications featuring a high rateof computations per data item can attain high performance.In addition, these devices present a relativelyhigh performance/cost ratio, resulting in aninteresting option for HPC (high performance computing).On the other hand, virtualization technologies arecurrently widely deployed, as their use yields importantbenefits such as resource sharing, process isolation,and reduced management costs. Thus, it isstraight-forward that the usage of virtual machines(VMs) in HPC is an active area of research [3]. VMsprovide an improved approach to increase resourceutilization in HPC clusters, as several different customersmay share a single computing node with theillusion that they own it in an exclusive way.Processes running in a VM may also require theservices of a GPU in order to accelerate part oftheir computations. To do so, the GPGPU capabilitiesshould be exposed to VMs so that they canmake use of the real GPU. However, although thereis currently some work on the virtualization of thegraphics application programming interfaces (APIs)of GPUs (e.g., [4]), those efforts are not directlyuseful to expose GPGPU features to virtualized environments.The main cause is that both uses ofGPUs are completely different and, therefore, advancesin one of them do not translate in progress in1 DISCA, Universitat Politècnica de València (UPV), e-mail:{jduato,fsilla@disca.upv.es}, apenya@gap.upv.es.2 DICC, Universitat Jaume I (UJI), e-mail:{jfernand,mayo,quintana}@icc.uji.es.the other. The reason for this is that current GPUslack a standard low-level interface —unlike otherdevices such as storage and network controllers—and, therefore, their use for graphics purposes isapproached by using high-level standard interfacessuch as Direct3D [4] or OpenGL [5], while usingthem for GPGPU requires APIs like OpenCL [6] orNVIDIA CUDA [7], which significantly differ fromtheir graphics-processing oriented counterparts. Onthe other hand, the few efforts done up to now toexpose CUDA capabilities to VMs [8], [9], [10] (1)are incomplete prototypes, (2) make use of obsoleteversions of the GPGPU API, (3) are not general solutions,as they target a particular virtual machinemonitor (VMM), or (4) employ inefficient communicationprotocols between their middleware sides.In this paper we move a step forward in the virtualizationof GPUs for their use as GPGPU acceleratorsby VMs. We propose using an open source, VMMindependent,and communication-efficient way of exposingGPGPU capabilities to VMs featuring a recentGPGPU API version. Our work addressesthe virtualization of the CUDA Runtime API, awidely used GPGPU API supporting the latestNVIDIA GPUs. The framework we employ, namedrCUDA [11], [12], was initially designed to use TCPsockets to communicate a GPU-accelerated processrunning in a computer not having a GPU with aremote host providing GPGPU services, thus providingthe accelerated process with the illusion ofdirectly using a GPU. Note however that althoughthe primary goal of rCUDA was providing a way toreduce the number of GPU-based accelerators in acluster, in this paper we extend its applicability toalso expose CUDA capabilities to VMs running in aCUDA-enabled computer. More specifically, we explorethe benefits of using rCUDA in VMs, rangingfrom a single VM instance to multiple VMs concurrentlyrunning in the same server, equipped with asmall number of accelerators. To do this, we analyzethe execution of a set of CUDA SDK examples ona platform composed of 8 general-purpose cores andtwo NVIDIA cards providing a total of 4 GPUs. Theresults obtained with the Kernel-based Virtual Machine(KVM) and Oracle’s VirtualBox Open SourceEdition (VB-OSE) VMMs using rCUDA are additionallycompared with those of the native environment.Although our solution is also valid for theVMware Server environment, we cannot disclose theresults due to licensing policies.II. Background on CUDA VirtualizationIn addition to rCUDA, which will be described inthe following section, there are other approaches thatJP2011-341

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011pursue the virtualization of the CUDA Runtime APIfor VMs. All solutions feature a distributed middlewarecomprised of two parts: the front-end and theback-end. The former is installed on the VM, whilethe back-end counterpart, with direct access to theacceleration hardware, is run by the host operatingsystem (OS) — the one executing the VMM.vCUDA [10] implements an unspecified subset ofthe CUDA Runtime version 1.1. It employs XML-RPC for the application level communications, whichmakes the solution portable across different VMMsbut, as the experiments in [10] show, the time spentin the encoding/decoding steps of the communicationprotocol causes a considerable negative impacton the overall performance of the solution.On the other hand, GViM [9] uses Xen-specificmechanisms for the communication between bothmiddleware actors, including shared memory buffers,which enhance the communications between user andadministrative domains, at the expense of losingVMM independence. This solution, based in CUDA1.1, does not seem to implement the whole API.Finally, gVirtuS [8] (version 01-beta1) is a toolwith a purpose similar to rCUDA. This version seemsto only cover a subset of the Runtime API v2.3 (e.g.:it lacks 20 out of the 37 functions of the memorymanagement module of this API).In this paper we propose using rCUDA, aproduction-ready framework to run CUDA applicationsfrom VMs, based in a recent CUDA API version(currently 3.1). This middleware makes use of acustomized communications protocol and is VMMindependent,thus addressing the main drawbacks ofprevious works.III. The rCUDA FrameworkrCUDA is intended to provide access to GPUs installedin remote nodes. Hence, this framework offersHPC clusters a way of reducing the total number ofGPUs in the system or, alternatively, to significantlyaccelerate the computations of a traditional clusterby adding a reduced number of accelerators. Inother words, in the former case, by slightly increasingthe execution time of the applications that makeuse of GPUs to accelerate parts of their code, considerablesavings can be achieved in energy, maintenance,space, and cooling. On the other hand, whenadding a few accelerators to a cluster, rCUDA bringsthe possibility of significantly reducing the executiontime of suitable applications with a small impact onthe system energy consumption.As in the case of the software presented in theprevious section, the rCUDA framework is split intotwo major software modules:• The client middleware consists of a collectionof wrappers which replace the NVIDIA CUDARuntime (provided as a shared library) in theclient computer (not having a GPU). Thesewrappers are in charge of forwarding the APIcalls from the applications requesting accelerationservices to the server middleware, and retrievingthe results back, providing applicationswith the illusion of direct access to a real GPU.• The server middleware runs as a service onthe computer owning the GPU. It receives, interprets,and executes the API calls from theclients, employing a different process to serveeach remote application over an independentGPU context, thus attaining GPU multiplexing.Communication between rCUDA components isperformed employing a highly-tuned, TCP-basedapplication-level protocol.The current release of rCUDA (2.0) targets theLinux OS. It implements the CUDA Runtime APIversion 3.1, excluding OpenGL and Direct3D interoperability,as graphics-oriented capabilities are notof interest in this environment. One drawback ofrCUDA is that it lacks support for the C for CUDAextensions, as the CUDA Runtime library comprisessome hidden and undocumented support functions,as reported by the vCUDA developers in [10] 1 .Although there are other GPGPU APIs such asthe CUDA Driver API or OpenCL, rCUDA focuseson the most widely used: the CUDA Runtime, asat the moment applications using CUDA seem toachieve higher performance than when employingOpenCL [13]. These alternatives might be exploredin the future employing tools similar to rCUDA forthese APIs, such as VCL [14] for OpenCL.Note that the NVIDIA CUDA Runtime Libraryalso allows CUDA executions on computers with noCUDA-compatible devices by means of the DeviceEmulation Mode, as GPU kernels are executed bythe CPU emulating the many-core architecture ofthe GPU. However, the resulting overhead is oftenunbearable for complete executions (indeed, this featureis intended for debugging purposes instead of areplacement of a physical accelerator).Readers can find additional details about therCUDA architecture in [11], and a more detaileddescription of the implementation with a discussionon energy consumption implications in [12]. Furtherdetails are available on the Web (www.gap.upv.es/rCUDA, www.hpca.uji.es/rCUDA).IV. rCUDA on Virtual MachinesrCUDA was initially designed to provide access toGPGPU features to computers not owning a GPUby accessing remote computers equipped with thathardware, as explained in the previous section. However,we propose to additionally use this frameworkto access GPUs from VMs. In this case, the VMs areconsidered nodes without a physical GPU, and thehost OS is that acting as a GPGPU server. Hence,the client middleware of rCUDA is installed on theguest OS (that executed by a VM), as a replacementof the NVIDIA Runtime library, while the rCUDAserver is executed on the host OS.1 gVirtuS software is supposed to support the undocumentedfunctions. However, when looking at the corresponding sourcecode, the following advise is found: “Routines not found in thecuda’s header files. KEEP THEM WITH CARE”.JP2011-342

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.rCUDA architecture on a VMM environment.When used with VMs, the communication protocolin rCUDA will make use of the virtual networkdevice to communicate the front-end and back-endmiddleware. Therefore, the network has to be configuredin a way that both the VM and the host OScan address IP packets to each other. Fig. 1 showsan rCUDA architecture diagram modified to reflectits usage in VM environments. We were able to successfullytest the current implementation of rCUDAin KVM, VB-OSE, and VMware Server virtualizationsolutions. However, we were unable to run itin a recent release of the Xen Hypervisor (3.4.3), aswe could not gain access to a recent NVIDIA GPUdriver that worked properly under the modified kernelfor the administrative domain, with the ultimatereason being that this driver is not designed to supportthe Xen environment.With rCUDA, multiple VMs running in the samephysical computer can make concurrent use of allCUDA-compatible devices installed on the computer(as long as there is enough memory on the devices tobe allocated by the different applications). Furthermore,although not addressed in this paper, rCUDAalso allows the usage of a GPU located in a differentphysical computer.In the following section we provide an in-depthanalysis of the use of rCUDA to enable GPGPUcapabilities within VMs. We believe our proposalis the first work describing a VMM-independentproduction-ready CUDA solution for VMs.V. Experimental EvaluationIn this section we conduct a collection of experimentsin order to evaluate the performance of therCUDA framework on a VMM environment. Thetarget system consists of two Quad-core Intel XeonE5410 processors running at 2.33 GHz with 8 GB ofmain memory. An OpenSuse Linux distribution withkernel version 2.6.31 is run at both host and guestsides. The GPGPU capabilities are provided by twoNVIDIA GeForce 9800 GX2 cards featuring a totalof 4 NVIDIA G92 GPUs; the driver version is 190.53.We selected two Open Source VMMs for theperformance analysis: KVM (userspace qemu-kvmv0.12.3) and VB-OSE 3.1.6, with their VMs configuredto make use of para-virtualized network devices.In addition, for load isolation purposes, each VM wasconfigured to make use of only one processor core.All benchmarks employed in our evaluation arepart of the CUDA SDK. From the 67 benchmarksin the suite, we selected 10 representativeSDK benchmarks of varying computationFig. 2.Native vs. KVM and VB-OSE.loads and data sizes, which use different CU-DA features: alignedTypes (AT), asyncAPI (AA),bicubicTexture (BT), BlackScholes (BS), box-Filter (BF), clock (CLK), convolutionSeparable(CS), fastWalshTransform (FWT), image-Denoising (ID), and matrixMul (MM). A descriptionof each benchmark can be found in the documentationof the SDK package [15]. The benchmarkswere executed with the default options, otherthan setting the target device. In addition, benchmarksrequiring OpenGL capabilities for their defaultexecutions (BT, BF, and ID) were executedwith the -qatest argument, in order to perform a“quick auto test”, which does not make use of thegraphics-oriented API. To make the original benchmarkcode compatible with rCUDA, which does notsupport the C for CUDA extensions, the pieces ofcode using these extensions were rewritten using theplain C API (only a 7% of the total effective sourcelines of code required being modified).The execution times reported in the next experimentsare the minimum from 5 executions, in orderto avoid eventual network and CPU noise. They reflectthe elapsed time experienced by the users, fromthe start of the execution of the application till theend of it. The experiments are presented in this sectionin two groups. First, those concerning one VMare presented. Later, we introduce experiments involvingseveral VMs being concurrently executed.A. Single Virtual MachineWe first analyze the performance of the CUDASDK benchmarks running in a VM using rCUDA,and compare their execution times with those of anative environment —i.e., using the regular CUDARuntime library in a non-virtualized environment.The results of this experiment are reported in Fig. 2.It would also be interesting including data for a versionof the benchmarks that makes only use of theCPU. However, as it is difficult to find optimized algorithmsfor CPUs performing the same operationsas all of our benchmarks, and those included in theSDK package are often naive versions, we cannotpresent such a comparison. Nevertheless, it is notstrictly required for understanding the experimentspresented and, additionally, the convenience of usingvirtualized remote GPUs instead of the local CPUwas previously discussed [11].JP2011-343

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Results show that, for the evaluated benchmarks,the combination of KVM + rCUDA performs muchbetter than VB-OSE + rCUDA. The reason for thesedifferences will probably lay on the way each VMMmanages the virtual I/O. However, as the focus ofthe paper is analyzing the feasibility of using GPUsin VMs and not the discussion of a performance comparisonbetween VMMs, we will not pursue furtherthe causes of this difference. Hereafter, for simplicityand brevity, the results for VB-OSE are not furtherdiscussed, as compared with those of KVM they reportsimilar behavior but at a higher scale.Figure 2 shows that the performance of KVM +rCUDA is close to that of the native executions.Therefore, even though the combination KVM +rCUDA pays the penalty for a non-optimized hostguestcommunication, using this general approachis feasible. Unfortunately, we cannot compare theoverhead of the rCUDA-based solution with that ofsolutions based in prior middleware such as GViMor vCUDA because (1) GViM and vCUDA softwareare not publicly available, (2) in their associated papers,CUDA 1.1 was used instead of the more recentversion rCUDA uses, and (3) both used the Xenvirtual platform 2 . On the other hand, we alreadymentioned that we could not get the public versionof gVirtuS working in our test-bed. For referencepurposes, executions up to 5.28 times slower usingvCUDA with respect to those on a native environmentcan be extracted from [10], up to 1.25 in thecase of GViM [9], and up to 7.12 and 2.98 for gVirtuS[8] when using TCP-based and VMM-dependentcommunications, respectively. Nevertheless, as previouslystated, rCUDA aims at attaining a performancesomewhere between those prior prototypeswith the advantage of featuring VMM independence.Fig. 3 specifies the time required by network transfers,thus illustrating that the overhead of KVM +rCUDA mostly originates in the network. Networktransfer times have been measured as the addition ofthe times spent in data sending in both middlewaresides of rCUDA. A conclusion from this experimentis that a shared-memory scheme for communicationsmay improve the performance at the expense of losingVMM independence. However, losing VMM independencewould lead to a significant reduction inthe flexibility provided by rCUDA, which is the mainbenefit of this package. Therefore, in the rest of thissection we will analyze the exact causes for the overheadintroduced by virtual network transfers in orderto know if they can be improved.Fig. 4 relates the dataset size of each benchmarkwith the network transfer time. Note, however, thatas the AA benchmark performs asynchronous memorytransfers, which might be overlapped with CPUand GPU computations, the time spent in networkcommunications might not be proportional to theglobal overhead introduced by those; therefore, the2 NVIDIA GPU drivers supporting up to version 1.1 ofCUDA worked on the Xen dom0, but this is no longer thecase for more recent versions like those used by us.Execution time (s)Time (s)121086420Fig. 3.3.532.521.51NativerCUDA communicationsKVM + rCUDA computationAT AA BT BS BF CLK CS FWT ID MMSDK benchmarkBreakdown of KVM + rCUDA.BS48.3 MB/s107.7 MB/s0.5 FWTBenchmarkCSRegression all0CLK, MM, ID, BT, BF Regression CLK-BF0 50 100 150 200 250 300 350 400Data size (MB)Fig. 4. Dataset size and total network transfer time on KVM.data corresponding to this benchmark is not includedin the figure and skipped during the rest of this section.As shown in the figure, the time spent in networkcommunications seems to be proportional tothe data size of the problem, as other transfers relatedwith the application-level communication protocolbecome negligible for “large” datasets. Nevertheless,as the points for CLK, MM, ID, BT, and BFin Fig. 4 are so close to the axis origins that they cannotbe clearly distinguished, Fig. 5 provides a zoomof the plot area for those points. As can be seen, thepoints in that figure evidence a significantly lowernetwork throughput than AT, CS, FWT, or BS. Inorder to analyze the reason for this lower throughput,we determined the degree of utilization of the bandwidthof the virtual network examining the averagetransfer rates of the memory transfer operations foreach of the benchmarks. Additionally, a simple pingpongtest revealed a peak transfer rate between KVMVMs and the host OS of 126 MB/s. The results ofthis analysis are shown in Table I, illustrating thatin some cases the experienced average transfer rate(TR) was much lower than this value.The bandwidth for the smallest data sizes shownin Table I may be far from the theoretical peak ofthe network due to the intrinsics of the TCP protocol.That is, the cause for these low transfer ratesmay be related with the size of the memory transferoperations and the configuration of the TCP transmissionwindow. Inspecting the source code we determinedthat data transfers are performed in chunksof sizes between 2 KB and 32 MB. Numbers in TableI reveal that the benchmarks that transfer datain chunks smaller than 1 MB yield specially low averagetransfer rates (below 50% of the peak). Toconfirm the relationship between the low bandwidthATJP2011-344

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IAverage transfer rate (TR) obtained for each benchmarkAT BT BS BF CLK CS FWT ID MMData (MB) 413.26 4.25 76.29 5.00 2 · 10 −3 36.00 64.00 2.49 0.08Time (s) 3.53 0.08 0.88 0.12 4 · 10 −4 0.47 0.75 0.06 0.01TR (MB/s) 117.19 52.44 86.61 42.93 6.17 76.55 84.82 44.21 6.91Transfers 13 4 5 5 1 2 2 5 3Chunk 32 MB 1 MB 15 MB 1 MB 2 KB 18 MB 32 MB 512 KB 15-40 KBTime (s)0.120.10.080.060.04107.7 MB/sID48.3 MB/s0.02MMBenchmarkRegression allCLKRegression CLK-BF00 1 2 3 4 5Data size (MB)BTBFTime (ms)2015105MMPing-pong testMaximum TRObtained TTIDCLK00 0.2 0.4 0.6 0.8 1Data size (MB)BFBTFig. 5. Area closest to the coordinate origin in Fig. 4.and the intrinsics of TCP, we next compare the resultsof the ping-pong test for data payload sizes upto 1 MB with the average transfer rates obtainedin our executions. Fig. 6 shows that the transferrates obtained by the ping-pong test vary from 16to a maximum of 119 MB/s. However, the averagethroughputs for the benchmarks are still below thoseobtained with this simple test. Therefore, the reasonmay be that the TCP layer protocol is basedon a transmission window size which is progressively—but not immediately— adapted to the amount oftransferred data. To assess the impact of this phenomenonin our experiments, we performed a carefulanalysis of the time employed by each memory transferoperation. In Fig. 7 we show the transfer times for4 consecutive and identical memory transfers of oneof the benchmarks. As expected, the figure revealsthat the transfer of the first large packet takes significantlylonger time than the following transfers of thesame size, which require times close to those of theping-pong test, as the TCP transfer window is progressivelybeing increased to reach the appropriatesize for that data payload. Therefore, the low averagetransfer rates shown in Table I are explained bythe transport layer protocol particularities regardinghow the window in the transmitter side is managedby TCP. This window management also explains thenetwork overhead in Fig. 3.The network analysis presented above reveals that,in order to obtain faster network transmissions, onthe one hand memory transfer operations should involveas much data as possible and, on the otherhand, the initial TCP window size should be increased.One proposal for future work in rCUDAis to try to artificially open the transmission windowupon the TCP connection establishment. However,as the maximum effective transfer rate of the virtualnetwork is 126 MB/s, when compared to nativeFig. 6. Ping-pong test, peak transfer rate (TR) of the virtualnetwork, and minimum obtained transfer times (TT).Fig. 7.Time (µs)140001200010000800060004000200001 2 3 4Transfer numberID benchmarkPing-pongFour consecutive transfers in ID vs. ping-pong test.solutions, where memory transfers directly use thePCI Express (PCIe) bus (with an effective transferrate around 5.5 GB/s in our tests over a PCIe v2.0x16), the overhead when performing GPGPU over aVM using a virtual network will never be reducedbelow a minimum value. In this regard, the experimentsshow that despite the increase of the throughputwith large data transfers from VMs, the overheadof transferring large amounts of data is higher thanthe benefits obtained with the higher throughput,and proportional to the dataset size. In general, thisoverhead could be reduced with improved support forthe virtual network device from VMM developers.B. Multiple Virtual MachinesTo measure the usability of a highly loaded systemusing rCUDA, we performed some scalability testsrunning up to 8 VMs on the target platform, makinguse of the 4 GPUs of the computer via rCUDA. Theresults were compared with those corresponding toconcurrent executions in a native environment.Fig. 8 shows the results employing from one toeight KVM VMs. The GPUs used by each VM aredistributed in a round-robin fashion as the requiredJP2011-345

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 8.Fig. 9.Time (s)1816141210864201 2 3 4 5 6 7 8Number of VMsATAABTBSBFCLKCSFWTIDMMConcurrency tests on multiple KVM VMs and GPUs.Time (s)1412108642ATAABTBSBFCLKCSFWTIDMM01 2 3 4 5 6 7 8Number of concurrent instances of the benchmarkConcurrency tests on the native environment.number increases. Thus, as soon as 5 or more concurrentVMs are run, the GPUs become a sharedresource. The results show a smooth degradation inperformance up to 4 VMs, as the different instancesare only competing for the network channel and thePCIe bus; from five to eight VMs, the overhead introducedis more evident, as the GPUs also becomea shared resource. For instance, for the AT sample,the most time-consuming benchmark in the set, theoverhead when executed in four VMs is 14.7%, butit raises to 71.4% when the eight VMs are used.On the other hand, the native concurrent testsshown in Fig. 9 —where the different GPUs of thesystem are used following the same policy as in theprior case— present scalability results close to thoseobtained in the VM environment. For reference, theAT sample overhead when running 4 concurrent instancesis 8.9%, reaching 105.9% for 8 instances as,similarly to the VM environment, there is a competitionfor the PCIe bus up to 4 instances, while thereis an additional competition for the GPU resourcesstarting from 5 concurrent instances.Interestingly, in our case studies we noticed betterscalability in rCUDA than in the native environment.As CPU and GPU computation time, inaddition to that of the data transfers across the PCIebus, present no major differences in native and KVMtests (see Fig. 3), the difference in time between bothenvironments is mostly caused by network transfers.VI. ConclusionsrCUDA enables remote CUDA Runtime API calls,thus enabling an application making use of a CUDAcompatibleaccelerator to be run on a host withouta GPU. Thus, this framework can offer GPGPU accelerationto applications running either in a remotehost, or similarly in a VM, where no direct access tothe hardware of the computer is provided.In this paper we have reported a variety of experimentalperformance results based on a set of CUDASDK benchmarks, showing that the rCUDA frameworkcan deliver CUDA-based acceleration supportto multiple VMs running in the same physical serverequipped with several GPUs. The experiments reportedan acceptable overhead —if compared withnative executions— for most applications ready tobe run in a virtualized environment. Our tests revealeda good level of scalability, thus demonstratingthat this solution can be run in a productive systemwith concurrent VMs in execution. In summary, ourresults state that it is possible to provide GPGPUcapabilities with reasonable overheads to processesrunning in a VM, while keeping VMM independence.AcknowledgementsThe researchers at UPV were supported byPROMETEO from GVA (Generalitat Valenciana)under Grant PROMETEO/2008/060, while thoseat UJI were supported by the Spanish Ministryof Science and FEDER (contract no. TIN2008-06570-C04), and by the Fundación Caixa-Castelló/Bancaixa (contract no. P1-1B2009-35).References[1] A. Gaikwad and I. M. Toke, “GPU based sparse gridtechnique for solving multidimensional options pricingPDEs,” in Proceedings of the 2nd Workshop on HighPerformance Computational Finance, 2009.[2] Y. C. Luo and R. Duraiswami, “Canny edge detection onNVIDIA CUDA,” in Computer Vision on GPU, 2008.[3] W. Huang, J. Liu, B. Abali, D. K. Panda, and Y. Muraoka,“A case for high performance computing withvirtual machines,” in ICS, 2006.[4] M. Dowty and J. Sugerman, “GPU virtualization onVMware’s hosted I/O architecture,” in First Workshopon I/O Virtualization, December 2008.[5] H. A. Lagar-Cavilla, N. Tolia, M. Satyanarayanan, andE. de Lara, “VMM-independent graphics acceleration,”in VEE, 2007, pp. 33–43.[6] OpenCL 1.0 Specification, Khronos OpenCL WG, 2009.[7] NVIDIA CUDA Programming Guide Version 3.1, 2010.[8] G. Giunta, R. Montella, G. Agrillo, and G. Coviello, “AGPGPU transparent virtualization component for highperformance computing clouds,” in Euro-Par. 2010.[9] V. Gupta, A. Gavrilovska, K. Schwan, H. Kharche, N. Tolia,V. Talwar, and P. Ranganathan, “GViM: GPUacceleratedvirtual machines,” in 3rd Workshop onSystem-level Virtualization for High Performance Computing,NY, USA, 2009, pp. 17–24.[10] L. Shi, H. Chen, and J. Sun, “vCUDA: GPU acceleratedhigh performance computing in virtual machines,” inIPDPS, 2009.[11] J. Duato, F. D. Igual, R. Mayo, A. J. Peña, E. S.Quintana-Ortí, and F. Silla, “An efficient implementationof GPU virtualization in high performance clusters,” inEuro-Par 2009, Parallel Processing — Workshops, 2010.[12] J. Duato, A. J. Peña, F. Silla, R. Mayo, and E. S.Quintana-Ortí, “rCUDA: Reducing the number of GPUbasedaccelerators in high performance clusters,” inHPCS, June 2010, pp. 224–231.[13] K. Karimi, N. G. Dickson, and F. Hamze, “A PerformanceComparison of CUDA and OpenCL,” ArXive-prints, 2010, Online: http://arxiv.org/pdf/1005.2581v2.[14] A. Barak, T. Ben-Nun, E. Levy, and A. Shiloh, “A packagefor OpenCL based heterogeneous computing on clusterswith many GPU devices,” in PPAAC, 2010.[15] NVIDIA, “NVIDIA CUDA SDK code samples,”http://developer.download.nvidia.com/compute/cuda/3_1/sdk/gpucomputingsdk_3.1_linux.run, 2010.JP2011-346

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Métodos no lineales basados en el gradienteconjugado para GPUsH. Migallón, 1 V. Migallón 2 y J. Penadés 2Resumen— En este artículo se presentan algoritmos paralelospara resolver sistemas no lineales, diseñados para GPUs (GraphicsProccesing Unit), para lo cual se hecho uso de CUDA (ComputeUnified Device Architecture). Los algoritmos propuestos estánbasados tanto en la versión de Fletcher-Reeves del método del gradienteconjugado, como en precondicionadores polinomiales construidosmediante el método por bloques en dos etapas. Se analizandiversas estrategias para la paralelización de dichos algoritmos,así como diferentes formatos de almacenamiento/compresión de lasmatrices dispersas consideradas en este trabajo. Expondremos resultadosnuméricos comparando la ejecución en plataformas paralelasde grano fino (GPU) con la ejecución en plataformas paralelasbasadas en hilos (multiprocesadores de memoria compartida o multicores).Palabras clave—GPGPU, librerías GPU, gradiente conjugado nolineal, precondicionadores paralelos, factorizaciones ILU, métodospor bloques en dos etapas.I. INTRODUCCIÓNSE considera la resolución del sistema no linealAx = Φ(x), (1)donde A ∈ R n×n es una matriz simétrica y definida positiva,y Φ : R n → R n es una función no lineal con ciertaspropiedades. Sea Ψ : R n → R una aplicación no lineal, ysea 〈x, y〉 = x T y el producto interno en R n . El problemade minimización consistente en encontrar x ∈ R n tal queJ(x) = min J(y), (2)y∈Rn donde J(x) = 1 2〈Ax, x〉 − Ψ(x), es equivalente a encontrarx ∈ R n tal que F (x) = Ax − Φ(x) = 0, dondeΦ(x) = Ψ ′ (x).Un método efectivo para resolver el sistema (1), teniendoen cuenta la conexión con el problema de minimización(2), es la versión de Fletcher-Reeves [1] del método delgradiente conjugado no lineal (NLCG), que se detalla acontinuación:Algoritmo 1: (GC no lineal (Fletcher-Reeves))Dado un vector inicial x (0)r (0) = Φ(x (0) ) − Ax (0)p (0) = r (0)Para i = 0, 1, . . . , hasta convergenciaα i =→ (ver a continuación)x (i+1) = x (i) + α i p (i)r (i+1) = r (i) − Φ(x (i) ) + Φ(x (i+1) ) − α i Ap (i)Test de convergenciaβ i+1 = − 〈r(i+1) ,r (i+1) 〉〈r (i) ,r (i) 〉p (i+1) = r (i+1) − β i+1 p (i)1 Dpto. de Física y Arquitectura de Computadores, UniversidadMiguel Hernández, e-mail: hmigallon@umh.es.2 Dpto. de Ciencia de la Computación e InteligenciaArtificial, Universidad de Alicante, e-mail:violeta,jpenades@dccia.ua.es.En el Algoritmo 1 la elección de α i debe minimizar lafunción asociada J en la dirección p (i) . Esto es equivalentea resolver el problema unidimensional de punto cerodJ(x (i) +α ip (i) )dα i12= 0. De la definición de J, se deduce queJ(x (i) + αp (i) ) =〈A(x (i) + α ip (i) ), x (i) + α ip (i)〉 − Ψ(x (i) + α ip (i) ).Por tanto, diferenciando respecto a α i se obtienedJ(x (i) + α ip (i) )dα i=α i〈Ap (i) , p (i)〉 〈− r (i) , p (i)〉 〈+ Φ(x (i) ) − Φ(x (i) + α ip (i) ), p (i)〉 ,donde r (i) = Φ(x (i) ) − Ax (i) es el residuo no lineal.Por otra parte, puede verse que la segunda derivada respectoa α i esd 2 J(x (i) + α ip (i) )dα 2 =i〈Ap (i) , p (i)〉 〈− Φ ′ (x (i) + α ip (i) )p (i) , p (i)〉 .Por lo tanto, si se usa el método de Newton para resolverel problema de punto cero para α i , se obtiene α (k+1)α (k)i− δ (k) , donde (siendo γ = (x (i) + α (k)i p (i) ))δ (k) =dJ(x(i) + α (k)i p (i) )/dα id 2 J(x (i) + α (k)i p (i) )/dα 2 i=i =〈α (k)i Ap (i) , p (i)〉 〈− r (i) , p (i)〉 +〈Φ(x (i) ) − Φ(γ), p (i)〉〈Ap (i) , p (i)〉 − 〈 Φ ′ (γ)p (i) , p (i)〉 .Hay que remarcar que para obtener δ (k) , los productosinternos 〈Ap (i) , p (i) 〉 y 〈r (i) , p (i) 〉 pueden computarseúnicamente en la iteración inicial del método de Newton.Además Ap (i) ha sido calculado en la iteración correspondientedel método del gradiente conjugado.El objetivo del precondicionamiento es mejorar elnúmero de condición (cond) de la matriz del sistema aresolver. Supongamos que M es una matriz simétricay definida positiva que aproxima a A, y fácilmente invertible.Entonces, podemos resolver indirectamente elsistema Ax = Φ(x) resolviendo el sistema M −1 Ax =M −1 Φ(x). Si cond(M −1 A)

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011α i =→ ver algoritmo 1x (i+1) = x (i) + α i p (i)r (i+1) = r (i) − Φ(x (i) ) + Φ(x (i+1) ) − α i Ap (i)Resolver Ms (i+1) = r (i+1)Test de convergenciaβ i+1 = − 〈s(i+1) ,r (i+1) 〉〈s (i) ,r (i) 〉p (i+1) = r (i+1) − β i+1 p (i)Dado que el sistema auxiliar Ms = r ha de resolverseen cada iteración del algoritmo, está solución hade poderse obtener rápidamente. Además, para que elprecondicionador sea efectivo es necesario que M seauna buena aproximación de A. El precondicionamientomediante series truncadas [2] es una técnica común deprecondicionamiento para resolver sistemas lineales, queconsiste en considerar una partición de la matriz A talque,A = P − Q (3)y realizar m iteraciones del proceso iterativo definidopor esta partición, buscando la solución de As = r, ytomando s (0) = 0. Es bien conocido que la solución delsistema auxiliar Ms = r es s = (I + R + R 2 + . . . +R m−1 )P −1 r, donde R = P −1 Q y la matriz de precondicionamientoes M m = P (I + R + R 2 + . . . + R m−1 ) −1(ver [2]).Si además suponemos que A está dividida en p × pp∑bloques, con bloques diagonales de orden n j , n j =j=1n, tal que el sistema (1) puede escribirse como:⎡⎤ ⎡ ⎤ ⎡ ⎤A 11 A 12 · · · A 1p x 1 Φ 1 (x)A 21 A 22 · · · A 2px 2Φ ⎢⎥ ⎢⎥⎣. .. ⎦ ⎣. ⎦ = 2 (x)⎢⎥⎣. ⎦ , (4)A p1 A p2 · · · A pp x p Φ p(x)donde x y Φ(x) están particionados en función deltamaño de los bloques de A. Si consideramos la partición(3) estando P compuesta por los bloques diagonales de Aen la ecuación (4), es decirP = diag(A 11 , . . . , A pp ), (5)realizar m iteraciones del proceso iterativo definido por lapartición (3) para obtener una aproximación de As = r,corresponde a realizar m iteraciones del método de Jacobipor bloques. Por lo tanto, en cada iteración l, l =1, 2, . . . , del método de Jacobi por bloques, ha de resolversep sistemas lineales independientes del tipo,A jj s (l)j = (Qs (l−1) + r) j , 1 ≤ j ≤ p. (6)Por tanto, los sistemas lineales (6) pueden ser resueltospor procesos distintos. Sin embargo, cuando el tamañode los bloques diagonales A jj , 1 ≤ j ≤ p, es grande, esaconsejable utilizar un proceso iterativo para obtener unaaproximación de las soluciones, utilizando por tanto elmétodo en dos etapas; ver por ejemplo [3]. Formalmente,consideramos las particionesA jj = B j − C j , 1 ≤ j ≤ p, (7)y en la l-ésima iteración se realizan, para cada j, 1 ≤j ≤ p, q(j) iteraciones del proceso iterativo definido porlas particiones (7) para obtener una aproximación de lasolución de (6). Por tanto, para resolver el sistema auxiliarMs = r del algoritmo 2, se realizan m pasos dela iteración s (l) = T s (l−1) + W −1 r, l = 1, 2, . . . , m,tomando s (0) = 0, dondeT = H + (I − H)P −1 Q, W = P (I − H) −1 , (8)estando P definido en (5) y H =diag((B1 −1 C 1) q(1) , . . . , (Bp−1 C p ) q(p) ); ver por ejemplo[4]. El siguiente algoritmo muestra el método utilizadopara aproximar el sistema lineal As = r (ver [3]).Algoritmo 3: (Método paralelo por bloques en dosetapas)Dado ( un vector inicial ) s (0) =T(s (0)1 )T , (s (0)2 )T , . . . , (s (0)p ) T , y una secuenciade número de iteraciones internas q(j), 1 ≤ j ≤ pPara l = 1, 2, . . ., hasta convergenciaEn el proceso j, j = 1, 2, . . . , py (0)j = s (l)jPara k = 1 hasta q(j)B j y (k)j = C j y (k−1)j + (Qs (l−1) + r) j() Ts (l) = (y (q(1))1 ) T , (y (q(2))2 ) T , . . . , (y p(q(p)) ) THay que remarcar, que el vector obtenido tras m iteracionesdel algoritmo 3, siendo s (0) = 0, viene dado pors (m) = (I + T + T 2 + . . . + T m−1 )W −1 r donde T yW están definidos en (8). Por tanto, el precondicionadorobtenido mediante el método por bloques en dos etapases M m = W (I +T +T 2 +. . .+T m−1 ) −1 . Para obtenerlas particiones internas, en el método NLPCG, se ha hechouso de factorizaciones incompletas LU, en [5] puedeverse una descripción detallada del algoritmo NLPCG.II. PROGRAMACIÓN PARALELA CON CUDALa arquitectura de una GPU (Graphics ProcessingUnit), está formada por un conjunto de multiprocesadoresdenominados “streaming multiprocessors (SM)”, cadauno de los cuales está compuesto por un conjunto deprocesadores denominados “streaming processors (SP)”.CUDA es el modelo de programación utilizado para explotarel paralelismo de las GPUs, el cual es un modeloheterogéneo que hace uso tanto de la CPU comode la GPU. En el modelo de programación de CUDA(ver por ejemplo [6] y [7]), una aplicación consiste enun programa secuencial principal (o “host”) ejecutadoen la CPU, el cual puede lanzar programas, conocidoscomo “kernels”, en el dispositivo paralelo, es decir enla GPU. Pese a que la CPU sobre la que se ejecuta elprograma host puede ser un multiprocesador de memoriacompartida, con capacidad para ejecutar programas paralelos,desarrollados por ejemplo con OpenMP, sólo unprocesador (o “core”) puede lanzar un kernel, es decir lasllamadas a los kernels deben serializarse. La ejecuciónde los kernels son de tipo SPMD (Single Program MultipleData), que, además, puede utilizar un gran númerode “threads” o hilos. Cada hilo de un kernel ejecuta elmismo programa secuencial, siendo el programador elque debe organizar los hilos de un kernel en bloques,formando estos bloques lo que se conoce como “grid”.Los hilos de un bloque pueden cooperar entre ellos, sin-JP2011-348

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cronizando su ejecución mediante barreras. Las memoriasdisponibles en una GPU son: la memoria global quees la de mayor latencia, la memoria de sólo lectura (“constant”),la memoria de “textura”, la memoria compartiday los registros. La memoria compartida lo es para unbloque, y los registros son propios de cada hilo. Aunque,tanto la memoria “constant” como la memoria “texture”disponen de caché, no han sido utilizadas por la naturalezade nuestro problema.El hardware se ocupa de la organización, creación ymanejo de los hilos. Por ejemplo, la GPU GTX 280dispone de 30 multiprocesadores, pudiendo trabajar hastacon 30K hilos. Para manejar eficientemente esta cantidadde hilos, la GPU utiliza una arquitectura SIMT (SingleInstruction Multiple Thread), ver por ejemplo [6] y [8],en la cual los hilos de un bloque se ejecutan en gruposde 32 hilos, llamados “warps”. Un warp en un momentodado ejecuta una única instrucción en todos sus hilos. Noobstante, los hilos de un warp pueden seguir su propiaejecución, es decir, la ejecución en cada hilo puede serdiferente, siendo mucho más eficiente que todos los hilosrealicen la misma ejecución.III. FORMATOS DE ALMACENAMIENTO DE MATRICESDISPERSASEl producto de una matriz dispersa por un vector(SpMV) es una de las operaciones básicas en los algoritmosvistos en la sección I. Para optimizar esta operaciónhemos considerado varios formatos de almacenamientode matrices dispersas. En concreto, se ha usado el formatoCRS (Compressed Row Storage), el formato ELL-PACK [9] (o ITPACK), y el formato propuesto en [10]denominado ELLPACK-R. Existen multitud de posiblesrepresentaciones de matrices dispersas, cada una con diferentesrequisitos de almacenamiento, diferentes característicasde computación y distintas formas de accedery manipular los elementos de la matriz. Hemos consideradoúnicamente formatos de almacenamiento de matricesdispersas de uso común y que además presentan unbuen comportamiento al computar la operación SpMV enuna GPU.El formato CRS (o CSR), muy común y de propósitogeneral, no presupone nada respecto al patrón de dispersiónde la matriz, y no almacena ningún elemento nonecesario. El formato CRS almacena en posiciones contiguasde memoria los elementos no nulos de la matriz.Este formato utiliza tres vectores, uno de “floats” y dosde enteros. El primero almacena los elementos no nulosde la matriz A agrupados por filas. En el primer vector deenteros se almacena la columna de los elementos no nulos.El otro vector de enteros almacena la posición en laque empieza cada fila en los otros dos vectores, por tantoel último elemento de este vector corresponde al númerode elementos no nulos (NNZ) o a NNZ+1 si el primerelemento es 1 en lugar de 0.El formato ELLPACK [9] fue diseñado para resolversistemas lineales de gran tamaño en arquitecturas vectoriales.Hay que hacer notar que existen ciertas similitudesentre una arquitectura vectorial y la arquitectura deuna GPU. El formato ELLPACK, también denominadoITPACK, usa dos vectores, el primero, de floats, almacenalos elementos no nulos de la matriz; y el segundo,de enteros, almacena el número de columna de cadauno de los elementos no nulos almacenados en el primervector. La dimensión de ambos vectores es, al menos,N ∗ MaxEntriesbyRows, donde N es el número defilas y MaxEntriesbyRows es el número máximo deelementos no nulos por fila en la matriz. Por tanto, eneste formato todas las filas se almacenan ocupando elmismo tamaño, aquellas filas con un número de elementosno nulos inferior a MaxEntriesbyRows, son rellenadascon ceros. Teniendo en cuenta esta estructura, elformato ELLPACK almacena en una estructura regular,similar a una matriz densa, una matriz dispersa. Esta estructuraregular, como se ha dicho anteriormente, es apropiadapara realizar operaciones con matrices dispersas enarquitecturas vectoriales. Sin embargo, si el porcentajede elementos nulos es alto y el patrón de dispersión dela matriz es irregular, respecto al número de elementosno nulos por fila, el rendimiento del formato ELLPACKdisminuye, además de aumentar el tamaño de memorianecesario para almacenar la matriz respecto a otros formatos.La variante del formato ELLPACK, denominadaELLPACK-R [10], fue diseñada con el objetivo de optimizarel producto de una matriz dispersa por un vectoren GPUs. El formato ELLPACK-R está formado porlos mismos dos vectores del formato ELLPACK, más untercer vector de enteros de tamaño N, que almacena elnúmero de elementos no nulos de cada fila, descartando,por tanto, los elementos nulos con los que se han rellenadolas filas con un número de elementos no nulos inferiora MaxEntriesbyRows. En este caso es necesarioque los elementos de cada fila se almacenen por ordencreciente de columna. La ventajas que presenta el formatoELLPACK (ver [10]) para su uso en GPUs son: proporcionaun acceso coalescente a la memoria global, paraello es necesario que las filas estén ordenadas en ordencreciente de número de columna; al igual que los otrosdos formatos vistos, permite una ejecución sin procesosde sincronización entre hilos; reduce los tiempos de esperaentre los hilos de un warp; además, la computaciónrealizada por los hilos de un warp es homogénea.IV. OPERACIONES BÁSICASSegún la descripción del algoritmo 1 y del algoritmo 2,las operaciones básicas para implementar dichos métodosson:• El producto de una matriz dispersa por un vector(SpMV).• Operaciones vectoriales básicas (incluidas en el nivel1 de la librería BLAS [11]).• El producto interno.• La resolución de un sistema LU (método incluidoen SPARSKIT [12]), utilizado únicamente en elmétodo NLPCG.Esta sección está dedicada a describir las diferentes opcionespara realizar las operaciones básicas reseñadas yanalizarlas en el contexto de nuestro trabajo.JP2011-349

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A. Producto matriz dispersa por vectorEl objetivo de utilizar diferentes formatos de almacenamientode matrices dispersas, descritos en lasección III, es optimizar el producto de una matriz dispersapor un vector. El código del kernel que implementala operación SpMV usando el formato CRS no ha sidooptimizado. Para optimizar este código existen dos vías,la primera es utilizar un formato de almacenamiento queoptimice dicho cálculo, opción que sí será considerada; yla segunda vía consiste en modificar la estructura de hiloscon el objetivo de optimizar el acceso a la memoriaglobal de la GPU. Sin embargo, en este segundo caso,las optimizaciones que podrían aplicarse se centran enmatrices con un patrón de dispersión mayor al del ejemploutilizado en nuestro trabajo (ver la sección V). Enel ejemplo utilizado en nuestro trabajo el número típicode elementos no nulos por fila es de 7, y, por ejemplo,las optimizaciones propuestas en [13] necesitan más de32 elementos no nulos por fila para ser aplicadas. Portanto, la vía utilizada para optimizar la operación SpMVserá la utilización de los formatos de almacenamiento dematrices dispersas ELLPACK y ELLPACK-R, las cualesmejoran el patrón de acceso a memoria respecto al formatoCRS.Por otra parte, se ha utilizado la librería CUSPARSE[14] para calcular la operación SpMV. La librería CUS-PARSE es una reciente librería para la ejecución en GPUsde operaciones entre elementos (matrices o vectores) dispersos,y entre elementos dispersos y elementos densos.Actualmente, sólo soporta el formato CRS en el productode una matriz dispersa por un vector.B. Operaciones vectorialesLos operaciones vectoriales, que no implican un procesode reducción, incluidas en los algoritmos 1 y 2, sonla copia de vectores, el producto de un escalar por unvector, la operación axpy (o similar) y el cálculo de lafunción no lineal propia del sistema. La computación deestas operaciones en una GPU ya está optimizada por lapropia arquitectura de la GPU, no obstante intentamosoptimizarlas agrupando varias de ellas en un único kernel.Por otra parte, se ha utilizado CUBLAS [15], versiónde la librería BLAS para su uso con CUDA. El uso deCUBLAS impide la agrupación de varias operaciones enúnico kernel, que era la primera vía de optimización propuesta.C. Producto internoEl proceso de reducción que implica el producto internohace que éste sea una operación especial en CUDA.En la computación en GPUs es necesario mantenerocupados a todos los SM (streaming multiprocessors),además para trabajar con vectores de gran tamaño esnecesario usar muchos bloques de hilos. Para conseguirestos dos propósitos cada bloque realiza el proceso de reducciónde una porción del vector. Dado que CUDA noproporciona mecanismos globales de sincronización quepermitan comunicar resultados parciales entre bloques, secalculan VectorN vectores de ElementN elementos, tal ycomo se propone en la NVIDIA CUDA C SDK. El númerode elementos (ElementN) de cada porción de vector debeser múltiplo del tamaño de un warp, para mantener lasrestricciones de alineamiento de la memoria y el accesocoalescente. Un bloque calcula la reducción de una omás porciones del vector. Además, para evitar procesosde sincronización se trabaja con la memoria compartida,la cual actúa como un acumulador. El tamañode esta memoria compartida (ACCUM N) deber ser potenciade dos y si es posible múltiplo del tamaño de unwarp. Por tanto, cada hilo calcula un elemento del acumuladortrabajando con elementos del vector separadosen ACCUM N elementos. El kernel finaliza realizando unproceso de reducción tipo árbol de los elementos almacenadosen el acumulador y donde sí es necesario realizarprocesos de sincronización entre hilos. Hay que remarcarque la CPU debe finalizar la operación trabajando con losresultados parciales obtenidos, lógicamente el número deresultados parciales obtenidos es igual al número de porcionesde vector (VectorN) con las que se ha trabajado.En nuestros algoritmos hemos agrupado varios productosinternos en único kernel.Por otra parte, la librería CUBLAS proporcionatambién la función que permite el cálculo del productointerno, y teniendo en cuenta que hemos trabajado conla versión optimizada de CUBLAS incluida en el CUDAToolkit 3.2 RC, no se han considerado otras optimizaciones.D. Solucionador LUEn el proceso para resolver un sistema LU cada elementocomputado de la solución es utilizado para elcálculo del siguiente elemento. Por tanto este proceso nodispone de paralelismo inherente de grano fino. Hemosdesarrollado diferentes algoritmos con diversas estrategiaspara resolver el sistema LU en la GPU, pero ningunade ellas ha obtenido buenos resultados. Por lo tanto, lamejor opción ha sido resolver el sistema LU haciendouso de la arquitectura multicore de la CPU, lo cual no hasido del todo efectivo al verse penalizado el algoritmo porel aumento de comunicaciones entre la CPU y la GPU.En la sección V presentaremos resultados haciendo usode CUDA y de OpenMP conjuntamente. En este ámbitohay que remarcar que en el método NLCG, las comunicacionesentre GPU y CPU se reducen a algunos escalaresy los vectores necesarios para completar los procesos dereducción.V. RESULTADOS NUMÉRICOSPara analizar el comportamiento de los métodos propuestos,NLCG y NLPCG, se ha utilizado el multicoreIntel Core 2 Quad Q6600, 2.4 GHz, con 4 GB de RAMy 8 MB memoria caché L2, denominado SULLI, con sistemaoperativo Ubuntu 9.04 (Jaunty Jackalope) para sistemasde 64 bits. La GPU disponible en SULLI es unaNVIDIA GeForce GTX 280. Los códigos de CUDA hansido compilados con el compilador de NVIDIA (nvcc)proporcionado por el CUDA Toolkit 3.2 RC.El ejemplo utilizado en nuestros experimentos es unaecuación en derivadas parciales, no lineal y elíptica,conocida como el problema de Bratu. Este problematridimensional viene dado por∇ 2 u − λe u = 0, (9)JP2011-350

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Speed-up del método NLCG.Fig. 2. Método NLCG vs formato de almacenamiento.donde u es la temperatura y λ es una constante conocidacomo el parámetro de Frank-Kamenetskii; ver por ejemplo[16]. Hay dos posibles soluciones para este problemadado un valor de λ. Una de las soluciones, sencilla deobtener, es cercana a u = 0. Para converger a la otrasolución es necesario partir de un vector inicial cercanoa dicha solución. En nuestro modelo se considera un dominiocúbico 3D de longitud unidad y λ = 6. Para resolverla ecuación (9) usando el método de diferenciasfinitas, consideramos un mallado del dominio formadopor d 3 nodos. La discretización da lugar a un sistema nolineal de la forma Ax = Φ(x), donde Φ : R n → R n esuna aplicación diagonal y no lineal, en la cual la componentei-ésima Φ i de Φ depende únicamente de la componentei-ésima de x. La matriz A es una matriz dispersade orden n = d 3 , siendo el número típico de elementosno nulos por fila de siete, con menos elementos no nulosen aquellos puntos que corresponden a la frontera deldominio físico.El análisis que presentamos se basa en la comparaciónde los tiempos de ejecución utilizando como plataformade computación la GPU GeForce GTX 280, con los tiemposde ejecución en el multicore SULLI. En primer lugarpresentamos resultados para resolver sistemas de variostamaños usando el método NLCG. En la figura 1 semuestra el speed-up utilizando, por un lado OpenMP condiferente número de cores, y por otro la GPU GeForceGTX 280. Lógicamente la GPU es controlada por uno delos cores de SULLI. En esta figura podemos observar quese obtiene un buen speed-up usando los cores disponiblesde SULLI, pero que dicho speed-up no es comparable alobtenido con la GPU, en la cual el valor es superior a 25.Este resultado confirma la expectativa de una muy buenainteracción entre el algoritmo NLCG y la GPU.En la figura 2 se puede ver el comportamiento de los diferentesformatos de almacenamiento de matrices dispersasdescritos en la sección III. Hay que tener en cuenta,que el formato utilizado modifica el kernel que calcula laoperación SpMV. Los mejores resultados se obtienen utilizandoel formato ELLPACK-R, ya que este algoritmono incluye instrucciones de control de flujo que provoquenla serialización de la ejecución de los diferentes hilosde un warp y, además, permite el acceso coalescentea los elementos de la matriz. No obstante, hay que remarcarque el formato ELLPACK-R es el que más memoriarequiere de los formatos vistos, debido al uso del tercerFig. 3. Uso de CUBLAS y/o CUSPARSE en el método NLCG.vector para almacenar el número de elementos no nulosde cada fila, además del rellenado de algunas filascon ceros. Hemos analizado el comportamiento del algoritmoNLCG en función tanto del número de hilos porbloque, como del tamaño del acumulador implementadoen la memoria compartida para calcular el producto interno.La figura 2 presenta resultados utilizando los valoresóptimos para estos dos parámetros, es decir 256 hilospor bloque y un tamaño de ACCUM N igual a 128.Por último, respecto al método NLCG, en la figura 3se muestran resultados haciendo uso de las libreríasCUBLAS y CUSPARSE, librerías incluidas en el CUDAToolkit 3.2 RC. En dicha figura se analiza el uso deCUBLAS y de CUSPARSE por separado y también eluso de ambas librerías conjuntamente. En primer lugar,podemos observar que el uso de CUBLAS presentapeores resultados que si se utiliza únicamente el API deCUDA. Esto es debido a las optimizaciones realizadasagrupando varias operaciones en un único kernel, procesoque no puede llevarse a cabo si se usa CUBLAS. Al contrario,el uso de CUSPARSE obtiene una pequeña mejora.Hay que remarcar que el uso conjunto de CUBLAS yCUSPARSE obtiene resultados aceptables con la ventajaque esconde al usuario la elección de parámetros talescomo el número de hilos por bloque y el tamaño del acumuladorpara el cálculo de operaciones de reducción.En [5] se detalla el comportamiento del algoritmoNLPCG en una plataforma multicore, todos los experimentosrealizados haciendo uso de la GPU muestran queese comportamiento no difiere al cambiar la plataformade computación a una GPU. En resumen, el valor óptimodel número de iteraciones internas y el valor óptimo delnúmero de iteraciones externas es un valor pequeño. Respectoal nivel de llenado de la factorización ILU, se con-JP2011-351

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Método NLPCG, m = 1, q = 1 y n = 884736.nuestros algoritmos, con el objetivo de optimizarlas y deexperimentar algunas librerías disponibles. Hemos podidoconcluir que librerías como CUBLAS y CUSPARSEpueden ofrecer un buen rendimiento. Respecto al formatode almacenamiento de matrices dispersas se concluye quedebe ser seleccionado en función de las características dela plataforma paralela, siendo ELLPACK-R el formatomás eficiente para la ejecución en una GPU. Por último,se han mostrado las diferencias de adaptación de ambosmétodos a las dos arquitecturas paralelas utilizadas, obteniendoen ambos casos mejores resultados trabajando conla GPU que trabajando con el multicore, y además en estecaso el método NLCG explota mejor el paralelismo, obteniendomejores resultados que el método NLPCG.AGRADECIMIENTOSEl presente trabajo ha sido financiado por el Ministeriode Ciencia e Innovación mediante el proyecto TIN2008-06570-C04-04.Fig. 5. Comparación de los métodos NLCG y NLPCG en CPU y GPU,orden del sistema n = 373248.cluye que el valor óptimo es 0 o 1. Trabajando con dichosvalores óptimos, en la figura 4 presentamos resultados delmétodo NLPCG haciendo uso de ambas plataformas decomputación conjuntamente. En dicha figura podemosobservar que el algoritmo NLPCG no se adapta bien alparalelismo ofrecido por la GPU, y que el uso de ambasplataformas tampoco obtiene buenos resultados al versepenalizado, como se ha comentado anteriormente, porel incremento de las comunicaciones entre GPU y CPU.Respecto al resto de parámetros vistos en el algoritmoNLCG, podemos extender las conclusiones obtenidas endicho método al método NLPCG.Por último, si analizamos la figura 5 deducimos queel speed-up obtenido usando la GPU siempre es mayorque usando los cuatro cores disponibles en SULLI. Deeste modo podemos concluir que utilizando una GPU elmétodo NLCG ofrece mejores prestaciones, pero no asíusando un multicore, en cuya caso las mejores prestacioneslas ofrece el método NLPCG.VI. CONCLUSIONESHaciendo uso del modelo de computación GPGPU(General-purpose computing on graphics processingunits) hemos desarrollado la versión de Fletcher-Reevesdel método del gradiente conjugado no lineal, y hemosaplicado, a dicho método, un precondicionador de tipopolinomial basado en los métodos en dos etapas. Sehan comparado los métodos desarrollados con los mismosmétodos desarrollados para OpenMP, y en el casodel método precondicionado se ha utilizado un modelode programación mixto para explotar el paralelismo ofrecidopor la GPU y el paralelismo ofrecido por el multicore.Hemos identificado las operaciones básicas deREFERENCIAS[1] R. Fletcher y C. Reeves, “Function minimization by conjugategradients,” The Computer Journal, vol. 7, pp. 149–154, 1964.[2] L. Adams, “M-step preconditioned conjugate gradient methods,”SIAM Journal on Scientific and Statistical Computing, vol. 6, pp.452–462, 1985.[3] R. Bru, V. Migallón, J. Penadés, y D.B. Szyld, “Parallel, synchronousand asynchronous two-stage multisplitting methods,”Electronic Transactions on Numerical Analysis, vol. 3, pp. 24–38,1995.[4] V. Migallón y J. Penadés, “Convergence of two-stage iterativemethods for hermitian positive definite matrices,” Applied MathematicsLetters, vol. 10, no. 3, pp. 79–83, 1997.[5] H. Migallón, V. Migallón, y J. Penadés, “Parallel nonlinear conjugategradient algorithms on multicore architectures,” in Proceedingsof the International Conference on Computational andMathematical Methods in Science and Engineering, pp. 689–700.2009.[6] J. Nickolls, I. Buck, M. Garland, y K. Skadron, “Scalable parallelprogramming with CUDA,” Queue, vol. 6, no. 2, pp. 40–53, 2008.[7] NVIDIA Corporation, “NVIDIA CUDA C programming guide,”Version 3.2, http://developer.download.nvidia.com/compute/cuda/3_2/toolkit/docs/CUDA_C_Programming_Guide.pdf, 2010.[8] E. Lindholm, J. Nickolls, S. Oberman, y J. Montrym, “NVIDIATesla: A unified graphics and computing architecture,” IEEE Micro,vol. 28, no. 2, pp. 39–55, 2008.[9] D.R. Kincaid y D.M. Young, “A brief review of the ITPACKproject,” Journal of Computational and Applied Mathematics,vol. 24, no. 1–2, pp. 121–127, 1988.[10] F. Vázquez, J.J. Fernández, y E.M. Garzón, “A new approachfor sparse matrix vector product on NVIDIA GPUs,” Concurrencyand Computation: Practice and experience, 2010, DOI:10.1002/cpe.1658.[11] C.L. Lawson, R.J. Hanson, D. Kincaid, y F.T. Krogh, “Basic linearalgebra subprograms for FORTRAN usage,” ACM Transactionson Mathematical Software, vol. 5, pp. 308–323, 1979.[12] Y. Saad, “SPARSKIT: A basic tool kit for sparse matrix computation,”http://www-users.cs.umn.edu/ ∼ saad/software/SPARSKIT/sparskit.html.[13] M. Manikandan y R. Bordawekar, “Optimizing sparse matrixvectormultiplication on GPUs,” Tech. Rep. RC24704, IBM,2008.[14] NVIDIA Corporation, “CUDA CUSPARSE Library,” Tech.Rep. PG-05329-032 V01, 2010, http://developer.download.nvidia.com/compute/cuda/3_2/toolkit/docs/CUSPARSE_Library.pdf.[15] NVIDIA Corporation, “CUDA CUBLAS Library,” Tech.Rep. PG-05326-032 V01, 2010, http://developer.download.nvidia.com/compute/cuda/3_2/toolkit/docs/CUBLAS_Library.pdf.[16] B.M. Averick, R.G. Carter, J.J. More, y G. Xue, “The MINPACK-2 test problem collection,” Tech. Rep. MCS-P153-0692, Mathematicsand Computer Science Division, Argonne.JP2011-352

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Búsquedas por Similitud en Espacios Métricossobre Plataformas Basadas en GPUsRoberto Uribe-Paredes 1 , Pedro Valero-Lara 2 ,Enrique Árias3 , José L. Sánchez 4 , Diego Cazorla 5Resumen— La búsqueda por similitud en espaciosmétricos resulta un problema de gran interés en laactualidad. La estructura de datos métrica Spaghettispermite indexar y realizar búsquedas eficientes sobreun espacio métrico. Sin embargo, para aplicacionesreales donde se requiere procesamiento masivode datos, los tiempos de resolución de una consultaresultan ser elevados. En estos casos, es necesarioaplicar mecanismos que permitan reducir considerablementelos tiempos de búsqueda. En este sentido,la paralelización de estructuras métricas es un campointeresante de investigación. La reciente aparición deplataformas computacionales que incluyen GPU s deproposito general (unidades de procesamiento gráfico)ofrecen grandes capacidades de procesamiento paraleloa un bajo costo. En este artículo se presenta unaversión de la estructura métrica Spaghettis basada enGPU. En una primera etapa, se adapta la estructuraa una plataforma basada en GPU. Posteriormente seanaliza el rendimiento compararando la versión secuencialcontra la implementación basada en GPU,mostrando mejoras significativas en términos de reduccióndel tiempo de respuesta, obteniendo valoresde speed-up cercanos a 10. Por otra parte, también semuestra la ganancia obtenida en función del consumode energía, reduciendo este valor en un 80, 14%.Palabras clave— Bases de Datos, búsqueda por similitud,espacios métricos, estructuras de datos, procesamientoparalelo, GPU, CUDA.I. IntroducciónLA búsqueda de objetos similares sobre un granconjunto de datos se ha convertido en un problemade gran interés. Por ejemplo, una consultatípica para estas aplicaciones es la búsqueda porrango la cual consiste en obtener todos los objetosque están a una determinada distancia del objetoconsultado. A partir de esta operación se puedeconstruir otra, como los vecinos más cercanos. Laaplicación de estas técnicas pueden ser encontradas,en reconocimiento de voz e imagen, en problemasde minería de datos, detección de plagios y muchasotras.1 Departamento de Ingeniería En Computación, Universidadde Magallanes, UMAG, Punta Arenas, Chile. e-mail:roberto.uribeparedes@gmail.com.2 Centro de Investigaciones Energéticas, Medioambientalesy Tecnológicas, Madrid, España. e-mail:pedro.valero@ciemat.es.3 Departamento de Sistemas Informáticos, Universidadde Castilla La Mancha, Albacete, España. e-mail:enrique.arias@uclm.es4 Departamento de Sistemas Informáticos, Universidadde Castilla La Mancha, Albacete, España. e-mail:jose.sgarcia@uclm.es5 Departamento de Sistemas Informáticos, Universidadde Castilla La Mancha, Albacete, España. e-mail:diego.cazorla@uclm.esA. Búsqueda por Similitud en Espacios MétricosLa similitud se modeliza en muchos casos interesantesa través de un espacio métrico, y la búsquedade objetos más similares a través de una búsquedapor rango o de vecinos más cercanos. Un espaciométrico es un conjunto X con una función de distanciad : X 2 → R, tal que ∀x, y, z ∈ X, se debecumplir las propiedades de: positividad (d(x, y) ≥0 and d(x, y) = 0 ssi x = y), simetría (d(x, y) =d(y, x)) y desigualdad triangular (d(x, y) + d(y, z) ≥(d(x, z)).Sobre un espacio métrico (X,d), un conjunto dedatos finito Y ⊆ X, se pueden realizar una seriede consultas. La consulta básica es la consulta porrango. Sea una consulta x ∈ X, y un rango r ∈ R.La consulta de rango alrededor de x con rango r esel conjunto de puntos y ∈ Y, tal que d(x, y) ≤ r.Un segundo tipo de consulta, que puede construirseusando la consulta por rango es, los k vecinos máscercanos. Sea una consulta x ∈ X y un entero k.Los k vecinos más cercanos a x son un subconjuntoA de objetos de Y, donde la |A| = k y no existe unobjeto y ∈ A tal que d(y,x) sea menor a la distanciade algún objeto de A a x.El objetivo de los algoritmos de búsqueda es minimizarla cantidad de evaluaciones de distancia realizadaspara resolver la consulta. Los métodos parabuscar en espacios métricos se basan principalmenteen dividir el espacio empleando la distancia a unoo más objetos seleccionados. El no trabajar con lascaracterísticas particulares de cada aplicación tienela ventaja de ser más general, pues los algoritmosfuncionan con cualquier tipo de objeto [1].Existen distintas estructuras para buscar en espaciosmétricos, las cuales pueden ocupar funcionesdiscretas o continuas de distancia.Algunos son GNAT, MTree, SAT, Slim-Tree, EG-NAT y muchos otros [1].Algunas de las estructuras basan la búsqueda enpivotes y otras en clustering. En el primer caso seseleccionan pivotes del conjunto de datos y se precalculanlas distancias entre los elementos y los pivotes.Cuando se realiza una consulta, se calcula la distanciade la consulta a los pivotes y se usa la desigualdadtriangular para descartar candidatos.Los algoritmos basados en clustering dividen el espacioen áreas, donde cada área tiene un centro. Sealmacena alguna información sobre el área que permitadescartar toda el área mediante sólo compararla consulta con su centro. Los algoritmos de clusteringson los mejores para espacios de alta dimensión,que es el problema más difícil en la práctica.JP2011-353

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Existen dos criterios para delimitar las áreas enlas estructuras basadas en clustering, hiperplanos yradio cobertor (covering radius). El primero divideel espacio en particiones de Voronoi y determina elhiperplano al cual pertenece la consulta según a quécentro corresponde. El criterio de radio cobertor divideel espacio en esferas que pueden intersectarse yuna consulta puede pertenecer a más de una esfera.Un diagrama de Voronoi está definido como lasubdivisión del plano en n áreas, una por cada centroc i del conjunto {c 1 , c 2 , . . . , c n } (centros), tal queq ∈ al área c i sí y sólo sí la distancia euclidianad(q, c i ) < d(q, c j ) para cada c j , con j ≠ i.En los métodos basados en pivotes, se seleccionaun conjunto de pivotes y se precalculan las distanciasentre los pivotes y todos los elementos de la basede datos. Los pivotes sirven para filtrar objetos enuna consulta utilizando la desigualdad triangular, sinmedir realmente la distancia entre el objeto consultay los objetos descartados.• Sea {p 1 , p 2 , ..., p k } ∈ X un conjunto de pivotes.Para cada elemento x de la base de datosY, se almacena su distancia a los k pivotes(d(x, p 1 ), ..., d(x, p k )). Dada una consulta q y unrango r, se calcula su distancia a los k pivotes(d(q, p 1 ), ..., d(q, p k )).• Si para algún pivote p i se cumple que|d(q, p i ) − d(x, p i )| > r, entonces por desigualdadtriangular se tiene que d(q, x) > r, y porlo tanto no es necesario evaluar explícitamented(x, q). Todos los objetos que no se puedandescartar por esta regla deben ser comparadosdirectamente con la consulta q.Las estructuras de tipo árbol utilizan esta técnicaen forma indirecta. El árbol se va construyendotomando el nodo raíz como pivote. Posteriormente elespacio se divide de acuerdo a la distancia de los objetosal pivote. Cada subárbol se construye recursivamentetomando un nuevo pivote de los elementos delsubespacio. Las diferencias radican principalmenteen la forma y tamaño de los espacios. La búsquedarealiza un backtrack sobre el árbol y utiliza la desigualdadtriangular para minimizar los subárboles.Algunas estructuras que utilizan esta técnica son elBKT y sus variantes [1].Otros algoritmos, de tipo arreglo, hacen una implementacióndirecta de este concepto, y se diferencianbásicamente en su estructura extra para reducir elcosto de CPU para encontrar los puntos candidatos,pero no en la cantidad de evaluaciones de distancia.Ejemplos de éstos son: LAESA [2], Spaghettis y susvariantes [3], [4].El aumento de tamaño de las bases de datos y laaparición de nuevos tipos de datos sobre los cuales nointeresa realizar búsquedas exactas, crean la necesidadde plantear nuevas estructuras para búsquedapor similtud o búsqueda aproximada. Así también,las aplicaciones reales requieren que dichas estructuraspermitan ser almacenadas en memoria secundariaeficientemente, como también que poseanmétodos optimizados para reducir los costos de accesosa disco.Finalmente, la necesidad de procesar grandesvolúmenes de datos requiere de incrementar la capacidadde procesamiento y reducir los tiempos debúsqueda promedio. En este contexto, es relevanteel estudio en términos de la paralelización de los algoritmosy distribución de la base de datos.B. Paralelización de Estructuras MétricasEn la actualidad, existen muchas plataformas ymodelos utilizados para la paralelización de estructurasmétricas. En este contexto, la investigación enesta área ha estado enfocada en tecnologías para aplicacionesde memoria distribuida, usando para ellolibrerías de alto nivel como MPI [5] or PVM [6], ymemoria compartida usando directivas de OpenMP[7].Algunos trabajos, [8], [9], se han enfocado a la paralelizaciónde diferentes estructuras métricas sobreplataformas de memoria distribuida usando MPI oBSP, así como también al análisis de la distribuciónde los datos y el balance de la estructura sobre laplataforma.En términos de memoria compartida, [10] proponeuna estrategia para organizar el procesamiento deconsultas sobre espacios métricos en nodos multicores,para ello propone combinar procesamiento deconsultas multihilo totalmente asíncronas con masivamentesíncronas. El cambio entre los modos seajusta a una regla que determina el nivel del tráficode consultas.La mayoría del trabajo previo y actual desarrolladoen esta área se lleva a cabo sobre plataformasclásicas de memoria distribuida y compartida. Sinembargo, nuevas plataformas computacionales hanido ganando significancia en la comunidad científica.Plataformas híbridas basadas en GPU son un ejemplo.En la actualidad existen muy pocos trabajos sobreestructuras métricas en plataformas de este tipo, lamayoría de las soluciones implementadas sobre GPUssólo abordan el problemas de consultas kNN sin utilizarestructuras de datos. En general, las GPUsbásicamente se utilizan para paralelizar búsquedasexhautivas (fuerza bruta) por lo que no se utilizanestructuras métricas [11], [12] y [13].En [11] se propone dividir la base de datos de elementos(A) y la de consultas (B) en submatricesde tamaño fijo. La matriz resultante es una matrizdonde cada elemento representa la distancia entreun elemento de A y uno de B. Cada submatriz de Ces resuelta por un bloque, para lo cual cada bloquecarga a memoria compartida cada submatriz de Ay B para poder escribir las distancias resultantes enla submatriz correspondiente. Cada bloque hará lecturasa device memory de acuerdo a las cantidadesde filas y columnas de las matrices. Teniendo la matrizde distancias resultante, ésta se ordena usandoel CUDA-based Radix Sort [14] para posteriormenteseleccionar los k primeros elementos como resultadoJP2011-354

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011final.En [12] se implementa el algoritmo de fuerza brutay se propone que cada thread resuelva la distancia deun elemento de la base de datos contra la consulta,para luego ordenar el arreglo resultante con una variantedel insertion sort.En general, en los trabajos anteriores la paralelizaciónes aplicada en dos etapas. La primeraconsiste en construir la matriz de distancias, y la segundaen el proceso de ordenamiento para obtenerlos resultados.En [15] se presenta una variante de lo anterior.Este trabajo compara 2 estrategias, la primera, alestilo de los trabajos anteriores. Sin embargo, lasegunda estrategia, llamada Heap Based Reductionpropone resolver una consulta por cada bloque. Despuésde haber calculado todas las distancias parauna consulta (exhaustivamente), envia en cada lanzamientode kernel un solo bloque, manteniendo unheap por cada thread del bloque. Cada heap detamaño k se utiliza para almacenar los k vecinos máscercanos a partir de las distancias entre los elementosde la base de datos y la consulta.En este artículo se presenta una versión de la estructuramétrica basada en pivotes Spaghettis [3] implementadasobre una plataforma basada en GPU.II. SpaghettisSpaghettis [3] es una estructura de datos métricabasada en pivotes y es una variante de LAESA [2].Propone reducir el tiempo de CPU extra necesarioal realizar una consulta utilizando una estructura dedatos en donde las distancias a los pivotes están ordenadaspor separado, construyendo un arreglo porcada pivote, lo que permite realizar una búsquedabinaria en el rango relevante.Si para cada pivote se encuentra el conjunto S i ={x : |d(x, p i ) − d(q, p i )| ≤ r}, i = 1, ..., k entonces lalista de candidatos está dada por la intersección detodos estos conjuntos.A. ConstrucciónDurante la construcción de la estructura, se seleccionanun conjunto aleatorio de pivotes p 1 , ..., p k , loscuales pueden o no pertenecer a la base de datos aindexar. Cada posición en la tabla S i representa aun objeto de la base de datos que tiene un enlace asu posición en la siguiente tabla, la última tabla enlazael objeto a su posición en la base de datos. LaFigura 1 muestra un ejemplo con 17 elementos.B. BúsquedaDurante el proceso de búsqueda, dada un consultaq, un rango r la búsqueda por rango sobre un spaghettistiene básicamente los siguientes paso:1. Se calcula la distancia entre q y todos los pivotesp1, . . . , p k , para luego obtener k intervalos de laforma [a 1 , b 1 ], ..., [a k , b k ], donde a i = d(p i , q) - ry b i = d(p i , q) + r.012250 70000 1111 0000 11110000 111111110000 1111 500001111 20000 1111 0000 11115 105 5 4 5 6 4000 111 000 1116 6 5 0 000 000 111000 1116 13000 111000011110000 1111600001111 11 6 9000011110000 1111600001111 110000 1111 0000 11110000 1111 0000 11117 12 7 11 6 60000 1111 0000 11110000 1111 0000 11118 80000 1111 00000000 1111 0000 11110000 1111 70000 1111 1 7 00000 11110000 11110000 1111 0000 1111 000 1118 9 7 6 7 9000 1110000 1111 0000 1111 000011118 14 0000 1111700001111 7 7 12000 111 000000 111 000 1110000 1111 0000 11118 10 8 10 7 39 15 9 14 8 5101115JP2011-355Pivote 1 Pivote 2 Pivote 3 Pivote 4 Base de Datos10247133160122299142313158412166 16149 810 1513 160 45 1111000111000000 111 6 000 111 21110006 766677779121736811000 000 111000 111111 7 000 111 151110008 10110000 11 8 00 11 1311009 1410 1614 5Objecto 1000000000000000000000000111111111111111111111111Objecto 20000000011111111Objecto 3Objecto 4Objecto 5Objecto 6Objecto 7Objecto 8Objecto 9Objecto 10Objecto 11Objecto 1200000000001111111111Objecto 13Objecto 14000000000000000000000000111111111111111111111111Objecto 150000000011111111Objecto 16Objecto 17Fig. 1. Spaghettis: Construcción y búsqueda. Ejemplopara una consulta q con rangos a los pivotes de{(6, 10), (5, 9), (2, 6), (4, 8)}.2. Los objetos que se encuentren en la intersecciónentre todos los intervalos, se convierten en candidatosa ser respuesta para la consulta q.3. Para cada objeto candidato y, se calcula la distanciad(q, y) y si ≤ r, entonces el objeto y essolución a la consulta.Algoritmo 1 Spaghettis: Algoritmo de Búsqueda.rangesearch(query q, range r)1: {Sea Y ⊆ X, la base de datos}2: {Sea P un conjunto de pivotes p 1 , . . . , p 2 ∈ X}3: {Sea D la tabla de distancias asociadas a q}4: {Sea S el Spaghettis}5: for all p j ∈ P do6: D j ← dist(q, p j )7: end for8: for all y i ∈ Y do9: descartado ← false10: for all p j ∈ P do11: if D j − r > S ij || D j + r < S ij then12: descartado ← true13: break;14: end if15: end for16: if !descartado then17: if dist(y i , q) ≤ r then18: agrega y i al resultado19: end if20: end if21: end forDetalles de la implementación se muestra en el algoritmo1.En la Figura 1 se representa la estructura spaghettisen su forma original. Ésta está construida usando4 pivotes para indexar una base de datos de 17 objetos.Sobre esta estructura se realiza la búsquedacomo sigue. Suponga una consulta q con distancia alos pivotes {8, 7, 4, 6} y rango de búsqueda r = 2 .

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011En la Figura 1 se muestran más oscurecidos los intervalos{(6, 10), (5, 9), (2, 6), (4, 8)} sobre los cuales serealizará la búsqueda. En la misma figura se apreciancon distintos achurados todos los objetos quepertenecen a la intersección de todos los intervalos.Dichos objetos son posibles candidatos a ser solución.Finalmente, para saber si un candidato es respuesta,se debe realizar un cálculo de distancia y determinarsi es menor que el rango de búsqueda.III. Implementación Basada en GPUEl objetivo principal del presente trabajo es desarrollaruna versión basada en GPU para los algoritmosde búsqueda por rango.Este tipo de proceso es altamente paralelizable anivel de datos con un alto requerimiento computacional.Por esta razón, la computación en GPU esmuy usada en orden a acelerar estos procesos debidoel hecho de que las GPUs explotan muy eficientementeel paralelismo a nivel de datos.A. Búsqueda Exhaustiva Basada en GPUDada una base de datos y una consulta, labúsqueda exhaustiva secuencial es un proceso iterativodonde en cada iteración se calcula la distanciaentre la consulta y un elemento de la base de datospara determinar si es o no una solución válida. Laimplementación paralela de este proceso es trivial, ydada las características de las GPUs, consiste en lanzartantos hilos como elementos haya en la base dedatos.Por otro lado, debido a las limitaciones de las actualesGPUs (número de hilos y capacidad de memoria),no es posible calcular simultaneamente todaslas distancias para todas las consultas usando sóloun kernel. Para esta implementación, se considerantantos kernel como consultas, donde cada kernel resuelvecompletamente una consulta.B. Spaghettis Basado en GPUEn orden a obtener mayor rendimiento sobre laGPU, se hicieron modificaciones sobre la estructuraSpaghettis original. La versión presentada en estetrabajo ordena la estructura sólo por el primer pivote,esto permite almacenar contiguamente las distanciasde los objetos a todos los pivotes. Inicialmentela estructura completa entra en el espacio dememoria global de la GPU.La paralelización del algoritmo de búsqueda estádividido en tres partes, cada uno de estas partes correspondea los procesos indicados en la subsecciónII-B.La primera parte resuelve el cálculo de las distanciasentre la query q y cada uno de los pivotes. Paraoptimizar el uso de la GPU, se resuelve en un sololanzamiento de kernel todo el conjunto de consultasQ. El proceso consistió en lanzar un kernel compuestopor una cantidad de hilos igual al número dequeries (|Q|), de esta manera, cada hilo resuelve enforma independiente las distancias de cada query alos pivotes. Como resultado, el kernel genera unamatriz de tamaño |Q| × |P | con las distancias correspondientes.La segunda parte de la paralelización se encargade determinar si un elemento es o no candidato auna query. Para ello se lanza el kernel denominadoKCandidates (ver algoritmo 2) que ejecuta un hilopor cada dato (y i ) en la base de datos y determinasi dicho dato es candidato o no, es decir, este kernelentrega la lista de candidatos para una query. Enel algoritmo 2, S i es la posición i que representa alobjeto y i , el cual es resuelto por el hilo i, cuandoéste es candidato se agrega al conjunto C. En estealgoritmo, cada kernel resuelve completamente unaconsulta.Algoritmo 2 Algoritmo de Búsqueda en CUDA.global KCandidates(range r, Spaghettis S, distancesD, pivots P , candidates C)1: {Sea P el conjunto de pivotes p 1 , . . . , p 2 ∈ X}2: {Sea D la tabla de distancias asociadas a q}3: {Sea C la lista de candidatos para q}4: {Sea i el Id del hilo}5: descartado ← false6: for all p j ∈ P do7: if D j − r > S ij || D j + r < S ij then8: descartado ← true9: break;10: end if11: end for12: if !descartado then13: agrega el elemento y i a C (candidates)14: end ifFinalmente, el último kernel se encarga de determinarcual de los candidados obtenidos en la segundaparte son realmente solución a la consulta q. En estekernel, el numero de hilos corresponde al número decandidatos por cada consulta. Al término del terceerkernel, se obtiene una lista con las soluciones para laconsulta.IV. Evaluación ExperimentalEsta sección presenta los resultados para los algoritmosindicados en la sección anterior. El caso deestudio presentado en este artículo considera que laestructura de datos Spaghettis generada entra completamenteen la memoria global de la GPU.A. Ambiente ExperimentalPara los experimentos mostrados en esta sección,se seleccionó una base de datos que corresponde aun diccionario español de 86.061 palabras. La distanciautilizada fue la distancia de edición, que correspondeal mínimo número de inserciones, eliminacioneso sustituciones necesarias para que una palabrasea igual a otra. La base de datos se divideen dos conjuntos aleatorios, el primero de un 90%de los datos se utiliza para construir la estructuraSpaghettis, el 10% restante se utiliza como consultas.La plataforma de hardware usado fue la siguiente:JP2011-356

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011• CPU: Intel Core 2 Quad de 2.66GHz y 4GB dememoria RAM.• GPU: GTX 285 with 240 cores y una memoriaglobal de 1 GB.B. Resultados ExperimentalesLos resultados mostrados en la presente seccióntienen las siguientes características:• La seleccion de pivotes fue aleatoria.• Se construyeron estructuras con 4, 8, 16 y 32pivotes.• Se realizaron 8.606 consultas sobre una estructuracon 77.455 objetos, por cada experimento.• Para cada consulta se recuperaron los objetos arangos de búsqueda de 1, 2, 3 y 4,• Los tiempos de ejecución mostrados para ambasversiones, secuencial y paralelo, corresponde altiempo total de todo el proceso. Para el caso dela versión paralela, los tiempos de ejecución incluyenlos tiempos de transferencia entre memoriaprincipal (CPU) y el disppositivo de memoriaglobal (GPU).La Figura 2(a) muestra información resumida yel contexto secuencial-paralelo. Se observa que losresultados de la versión basada en CUDA reduce notoriamenteel tiempo, incrementando el rendimiento.Para tener una visión más clara, la Figura 2(b) muestradetalles de los resultados obtenidos sólo para laversión paralela. Como referencia, en ambos gráficosse incluyen los tiempos de las respectivas versionesde búsqueda exhaustiva (Fuerza Bruta Sec. y GPU).En la versión secuencial, se puede observar queal aumentar el número de pivotes se logra mejorarel desempeño de la estructura. También era deesperar que a mayor rango de búsqueda menor elel rendimiento. Lo mismo sucede, en términos detiempo, en la versión paralela.Los graficos de speed-up se muestran en la Figura3. En este caso, se puede observar que las mejorasalcanzan valores cercanos al 9, 5 para los rangosmás altos. Lo anterior indica que para los rangosmayores, donde es menor la cantidad de elementosa descartar, y el comportamiento de la estructurase asemeja a búsqueda exhaustiva, la GPU obtienesu mejor desempeño. En el mismo gráfico se muestrauna prueba para rango 8, a fin de demostrar queel speed-up se vuelve asintótico alrededor del valormencionado anteriormente.Se puede notar también, que hay diferencia notoriadel speed-up para rangos bajos y cantidad de pivotespequeñas versus la estructura con mayor cantidad depivotes. Esto es provocado debido a que la versiónsecuencial para, por ejemplo, 4 pivotes es de muybajo rendimiento versus la versión secuencial de 32pivotes, por lo tanto el speed-up para la estructura32 pivotes secuencial/paralela no es tan buena comola versión de 4 pivotes.Tiempo (seg.)Tiempo (seg.)4500400035003000250020001500100050045040035030025020015010050Costos Totales de Búsqueda, Secuencial vs GPU (n=77.455)Fuerza Bruta Sec.Seq. 04Seq. 08Seq. 16Seq. 32Fuerza Bruta (gpu)P 04 (gpu)P 08 (gpu)P 16 (gpu)P 32 (gpu)01 2 3 4 1 2 3 4Rango de Búsqueda(a) Resultados Secuencial versus GPUCosto Total de Búsqueda sobre GPU (n=77.455; dic. Español)Fuerza Bruta (gpu)P 04 (gpu)P 08 (gpu)P 16 (gpu)P 32 (gpu)01 2 3 4Rango de Búsqueda(b) GPU detallesFig. 2. Resultados comparativos de los costos de búsquedapara el espacio de palabras para la estructura métricaSpaghettis (Spanish Dictionary). Número de pivotes 4,8, 16 y 32, y rango de búsqueda de 1 a 4.C. Consumo de EnergíaEl uso de GPUs puede reducir considerablementelos tiempos de ejecución de distintas aplicaciones,sin embargo, estos modernos dispositivos están compuestospor muchos núcleos de computación (cores),lo que implica un mayor consumo de energía. Deesta manera, el consumo de energía se convierte enun parámetro interesante de considerar al momentode desarrollar código para GPUs.La figura 4 muestra en detalle el consumo de energíapara la versión secuencial ejecutandose en laCPU versus la versión paralela corriendo en la GPU.En este caso, la información mostrada en el gráficocorresponde específicamente a la búsqueda sobre unaestructura con 16 pivotes y rango de búsqueda r =2. Los otros experimentos tuvieron similar comportamiento.La información de la forma y del dispositivoutilizado para la medición de la energía estáexpuesta en detalle en [16].A primera vista, es posible ver que el consumo deenergía de la GPU es más alto que el de la CPU.Sin embargo, debido al hecho de que el tiempo deejecución de la GPU es inferior a la CPU, el consumoglobal de energía es menor.El promedio de la energía eléctrica utilizada porla versión secuencial fue de 130, 38 watts durante589, 60 segundos, proporcionando un consumo deJP2011-357

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Speed Up108642Speed−Up para la Búsqueda (n=77,455 palabras; dic. Español)Fuerza Bruta (gpu)Pivots : 04Pivots : 08Pivots : 16Pivots : 3201 2 3 4 8Rango de BúsquedaFig. 3. Gráficos de Speed-up para el espacio de palabras parala estructura métrica Spaghettis (Diccionario Español).Watts250200150100Consumo energía, Algoritmos Secuenciales vs basados en GPU50promedio GPUpromedio Secuencial00 71.76 589.60Tiempo (seg.)Fig. 4. Consumo de energía promedio para las versiones secuencialy paralelo de la estructura métrica Spaghettis,para el diccionario español.76.872, 048 Joules. La implementación paralela tuvoun promedio de energía eléctrica de 212, 68 watts durante71, 76 segundos, lo que resulta en un consumode 15.261, 9168 Joules. Con lo anterior, se puede decirque el ahorro de energía de la versión paralelasobre la secuencial es de 80.14%.V. Conclusiones y Trabajo FuturoEn este artículo se ha presentado una implementaciónpara búsqueda por similitud sobre espaciosmétricos para la estructura Spaghettis sobre unaplataforma paralela basada en GPU.Las implementaciones realizadas han reducidolos tiempos de ejecución considerablemente, alcanzandovalores para el speed-up que bordean los9.5. En el análisis experimental se consideraronparámetros como, el número de pivotes y los rangosde búsquedas.Importante también es considerar el consumo deenergía, en la cual se obtuvo una reducci”on del80.14% utilizando la plataforma basada en GPU.En la actualidad los autores están realizando experimentossobre otras bases de datos e implementandoversiones multiples plataformas. Comotrabajo futuro se realizarán implementaciones deotras estructuras métricas que puedas servir de comparación,realizar implementaciones sobre plataformashíbridas (multicore + GPUs) y realizar análisisdel comportamiento de las estructuras métricas conotras funciones de distancia, entre otros.AgradecimientosEste trabajo ha sido parcialmente financiado porel proyecto SATSIM (Ref: CGL2010-20787-C02-02).Referencias[1] Edgar Chávez, Gonzalo Navarro, Ricardo Baeza-Yates,and José L. Marroquín, “Searching in metric spaces,”in ACM Computing Surveys, September 2001, pp.33(3):273–321.[2] L. Micó, J. Oncina, and E. Vidal, “A new version of thenearest-neighbor approximating and eliminating search(AESA) with linear preprocessing-time and memory requirements,”Pattern Recognition Letters, vol. 15, pp.9–17, 1994.[3] E. Chávez, J. Marroquín, and R. Baeza-Yates, “Spaghettis:An array based algorithm for similarity queriesin metric spaces,” in 6th International Symposiumon String Processing and Information Retrieval(SPIRE’99). IEEE CS Press, 1999, pp. 38–46.[4] S. Nene and S. Nayar, “A simple algorithm for nearestneighbor search in high dimensions,” IEEE Transactionson Pattern Analysis and Machine Intelligence, vol. 19,no. 9, pp. 989–1003, 1997.[5] W. Gropp, E. Lusk, and A. Skelljum, UsingMPI:Portable Parallel Programming with the MessagePassing Interface, Scientific and Engineering computationSeries. MIT Press, Cambridge, MA, 1994.[6] A. Geist, A. Beguelin, J. Dongarra, W. Jiang,B. Manchek, and V. Sunderam, PVM: Parallel VirtualMachine – A User’s Guide and Tutorial for NetworkParallel Computing, MIT Press, 1994.[7] L. Dagum and R. Menon, “OpenMP: An industrystandardAPI for shared-memory programming,” IEEEComputational Science and Engineering, vol. 5, no. 1,pp. 46–55, 1998.[8] P. Zezula, P. Savino, F. Rabitti, G. Amato, and P. Ciaccia,“Processing m-trees with parallel resources,” inRIDE ’98: Proceedings of the Workshop on Research Issuesin Database Engineering, Washington, DC, USA,1998, p. 147, IEEE Computer Society.[9] Adil Alpkocak, Taner Danisman, and Ulker Tuba, “Aparallel similarity search in high dimensional metric spaceusing m-tree,” in Advanced Environments, Tools, andApplications for Cluster Computing, vol. 2326 of LectureNotes in Computer Science, pp. 247–252. Springer Berlin/ Heidelberg, 2002.[10] Veronica Gil-Costa, Ricardo Barrientos, Mauricio Marin,and Carolina Bonacic, “Scheduling metric-space queriesprocessing on multi-core processors,” Parallel, Distributed,and Network-Based Processing, EuromicroConference on, vol. 0, pp. 187–194, 2010.[11] Quansheng Kuang and Lei Zhao, “A practical GPUbased kNN algorithm,” International Symposium onComputer Science and Computational Technology (ISC-SCT), pp. 151–155, 2009.[12] Vincent Garcia, Eric Debreuve, and Michel Barlaud,“Fast k nearest neighbor search using GPU,” ComputerVision and Pattern Recognition Workshop, vol. 0, pp.1–6, 2008.[13] Benjamin Bustos, Oliver Deussen, Stefan Hiller, andDaniel Keim, “A graphics hardware accelerated algorithmfor nearest neighbor search,” in ComputationalScience (ICCS). 2006, vol. 3994, pp. 196–199, Springer.[14] Nadathur Satish, Mark Harris, and Michael Garland,“Designing efficient sorting algorithms for manycoreGPUs,” Parallel and Distributed Processing Symposium,International, vol. 0, pp. 1–10, 2009.[15] R. J. Barrientos, J. I. Gómez, C. Tenllado, and M. Prieto,“Heap based k-nearest neighbor search on GPUs,”in Congreso Español de Informática (CEDI)), Valencia,Septiembre 2010.[16] Roberto Uribe-Paredes, Pedro Valero-Lara, EnriqueÁrias, José L. Sánchez, and Diego Cazorla, “A GPUbasedimplementation for range queries on spaghettisdata structures,” Tech. Rep., Computing Systems Dept,University of Castilla-La Mancha, Spain, 2010.JP2011-358

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Query Processing in Metric Spaces using GPUsRicardo J. Barrientos 1 , José I. Gómez 1 , Christian Tenllado 1 , Manuel Prieto Matias 1Abstract— Similarity search has been a problemwidely studied in the last years as it can be appliedto several fields such as searching by content in multimediaobjects, text retrieval or computational biology.These applications usually work on very largedatabases that are usually indexed off-line to enableacceleration of on-line searches. Even with indexeddatabases, it is essential to parallelize the on-linequery solving process. In the past, many strategieshave been proposed to parallelize this problemin distributed and shared memory multicore systems.Lately, GPUs have also been used to implement bruteforceapproaches instead of using indexing structures.In this work we propose a GPU based metric-spaceindex data structure for similarity search that outperformsprevious OpenMP and GPU brute-force basedimplementations. We also validate our implementationin the context of real-time systems, when it isnot affordable to wait for thousands of queries to fillthe system before processing them all in parallel.Keywords— Range Queries, Metric Spaces, MetricDatabases, Similarity Search, GPU.I. IntroductionSIMILARITY search has been widely studied inrecent years and it is becoming more and morerelevant due to its applicability in many importantareas. Efficient similarity search is useful in multimediainformation retrieval, data mining or patternrecognition problems. Range search also enablesother relevant operations such as nearest neighborssearch. In general, when similarity search is undertakenby using metric-space database techniques,this problem is often featured by a large databasewhose objects are represented as high-dimensionalvectors. There exists a distance function that operateson those vectors to determine how similar areobjects to a given query object. The distance betweenany given pair of objects is known to be anexpensive operation to compute and thereby the useof parallel computation techniques can be an effectiveway to reduce running times to practical valuesin large databases.In this paper we propose and evaluate efficientmetric-space techniques to solve range search queriesusing GPUs. We have found that obtaining efficientperformance from this hardware, in this applicationdomain, can be particularly difficult since many ofthe metric-space solutions developed for traditionalshared memory multiprocessors and distributed systemscannot be implemented efficiently on GPUs.Our focus is on search systems devised to solvelarge streams of queries. Previous related work hasshown that conventional parallel implementations forclusters and multicore systems that exploit coarsegrainedinter-query parallelism are able to improvequery throughput by employing index data struc-1 ArTeCS Group, Complutense University, e-mail:ribarrie@fdi.ucm.estures constructed off-line upon the database objects.In contrast, on GPUs it is necessary to exploit bothcoarse and fine grained parallelism where the cost ofdata transfers such as pieces of index can hide thebenefits of keeping smartly indexed the database.We studied a number of alternative sequentialmetric-space index data structures and realized thattwo candidates, namely LC and SSS-Index (detailsbelow), were best suited for GPUs as their data organizationand operations resemble computations ontwo-dimensional matrices.Interestingly enough, the LC and SSS indexes havebeen shown to achieve efficient performance in sharedmemory multi-core and distributed memory clusterprocessors by previous work. This allowed us to exposea comparative study of our proposal against optimizedimplementations of the same indexes bothsequentially and in parallel for shared memory usingOpenMP [1].II. Related WorkA metric space (X, d) is composed of an universe ofvalid objects X and a distance function d : X x X →R + defined among them. The distance function determinesthe similarity between two given objectsand holds several properties such as strict positiveness,symmetry, and the triangle inequality The finitesubset U ⊂ X with size n = |U|, is called thedatabase and represents the collection of objects ofthe search space.There are two main queries of interest: RangeSearch [2] and The k nearest neighbors (kNN) [3],[4]. In the former, the goal is to retrieve all the objectsu ∈ U within a radius r of the query q (i.e.(q, r) d= {u ∈ U/d(q, u) ≤ r}), whereas in the latter,the goal is to retrieve the set kNN(q) ⊆ Usuch that |kNN(q)| = k and ∀u ∈ kNN(q), v ∈U−kNN(q), d(q, u) ≤ d(q, v).For solving both kind of queries and to avoid asmany distance computations as possible, many indexingapproaches have been proposed. We havefocused on the List of Clusters (LC ) [5] and SSS-Index [6] strategies since (i) they are two of the mostpopular non-tree structures that are able to prunethe search space efficiently and (ii) they hold theirindexes on dense matrices which are very convenientfor mapping algorithms onto GPUs [7].In the following subsections we explain the constructionof both indexes and describe how rangequeries are solved using them in a sequential way(range searches are simpler than kNN, but manykNN searches are built on them).A. List of Clusters (LC)This index [5] is built by choosing a set of centersc ∈ U with radius r c where each center maintainsJP2011-359

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011a bucket that keeps tracks of the objects containedwithin the ball (c, r c ). Each bucket holds the closestk-elements to c. Thus the radius r c is the maximumdistance between the center c and its k-nearestneighbor.The buckets are filled up sequentially as the centersare created and thereby a given element i locatedin the intersection of two or more center balls remainsassigned to the first bucket that hold it. The firstcenter is randomly chosen from the set of objects.The next ones are selected so that they maximizethe sum of the distances to all previous centers.A range query q with radius r is solved by scanningthe centers in order of creation. For each centerd(q, c) is computed and only if d(q, c) ≤ r c + r, it isnecessary to compare the query against the objectsof the associated bucket. This process ends up eitherat the first center that holds d(q, c) < r c − r, meaningthat the query ball (q, r) is totally contained inthe center ball (c, r c ), or when all centers have beenconsidered.B. Sparse Spatial Selection (SSS-Index)During construction, this pivot-based index [6] selectssome objects as pivots from the collection andthen computes the distance between these pivots andthe rest of the database. The result is a table of distanceswhere columns are the pivots and rows theobjects. Each cell in the table contains the distancebetween the object and the respective pivot. Thesedistances are used to solve queries as follows. For arange query (q, r) the distances between the queryand all pivots are computed. An object x from thecollection can be discarded if there exists a pivot p ifor which the condition |d(p i , x) − d(p i , q)| > r doeshold. The objects that pass this test are consideredas potential members of the final set of objects thatform part of the solution for the query and thereforethey are directly compared against the query byapplying the condition d(x, q) ≤ r. The gain in performancecomes from the fact that it is much cheaperto effect the calculations for discarding objects usingthe table than computing the distance between thecandidate objects and the query.A key issue in this index is the method that calculatesthe pivots, which must be good enough todrastically reduce total number of distance computationsbetween the objects and the query. An effectivemethod is as follows. Let (X, ) be a metricspace, U ⊂ X an object collection, and M the maximumdistance between any pair of objects, M =max{d(x, y)/x, y ∈ U}. The set of pivots containsinitially only the first object of the collection. Then,for each element x i ∈ U, x i is chosen as a new pivotif its distance to every pivot in the current set of pivotsis equal or greater than αM, being α a constantparameter. Therefore, an object in the collection becomesa new pivot if it is located at more than afraction of the maximum distance with respect to allthe current pivots.III. Graphic Processing Units (GPU)GPUs have emerged as a powerful cost-efficientmany-core architecture. They integrate a large numberof functional units following a SIMT model.We develop all our implementations using NVIDIAgraphic cards and its CUDA programming model([7]). A CUDA kernel executes a sequential codeon a large number of threads in parallel. Thosethreads are grouped into fixed size sets called warps 1 .Threads within a warp proceed in a lock step execution.Every cycle, the hardware scheduler ofeach GPU multiprocessor chooses the next warp toexecute (i.e. no individual threads but warps areswapped in and out). If the threads in a warp executedifferent code paths, only those that follow the samepath can be executed simultaneously and a penaltyis incurred.Warps are further organized into a grid of CUDABlocks: threads within a block can cooperate witheach other by (1) efficiently sharing data through ashared low latency local memory and (2) synchronizingtheir execution via barriers. In contrast, threadsfrom different blocks can only coordinate their executionvia accesses to a high latency global memory.Within certain restrictions, the programmer specifieshow many blocks and how many threads per blockare assigned to the execution of a given kernel. Whena kernel is launched, threads are created by hardwareand dispatched to the GPU cores.According to NVIDIA the most significant factoraffecting performance is the bandwidth usage. Althoughthe GPU takes advantage of multithreadingto hide memory access latencies, having hundredsof threads simultaneously accessing the global memoryintroduces a high pressure on the memory busbandwidth. The memory hierarchy includes a largeregister file (statically partitioned per thread) and asoftware controlled low latency shared memory (permultiprocessor). Therefore, reducing global memoryaccesses by using local shared memory to exploit interthread locality and data reuse largely improveskernel execution time. In addition, improving memoryaccess patterns is important to allow coalescingof warp loads and to avoid bank conflicts on sharedmemory accesses.IV. Range QueriesIn this section we describe the mapping of threerange search algorithms onto CUDA-enabled GPUs:a brute-force approach and two index-based searchmethods.All of them exploit two different levels of parallelism.As in some previous papers [8][9] we assumea high frequency of incoming queries and exploitcoarse-grained inter-query parallelism, i.e. we alwayssolve nq queries in parallel. However, we also exploitthe fine-grained parallelism available when solvinga single query. Overall, each query is processed bya different CUDA Block that contains hundreds of1 Currently, there are 32 threads per warpJP2011-360

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011threads (from 128 to 512, depending of the specificimplementation) that efficiently cooperate to solve it.Communication and synchronization costs betweenthreads within the same CUDA Block are rather low,so this choice looks optimal to fully exploit the enormousparallelism present in range search algorithms.We introduced a brute force algorithm which isused as point of comparison with the indexed methods.A. Brute Force AlgorithmThe overall idea is that each CUDA Block processesa different query and within a CUDA Block,each thread computes the distance between the queryand a subset of the elements of the database. Thedatabase is a D × E matrix, where D is the dimensionof its elements and E is the size of the database,which has been uploaded previously to device memory.Queries are also uploaded into device memorybut the threads of each CUDA Block cooperate totransfer their associated query to the shared memoryto accelerate its access, which is the first step.Afterwards, threads compute the distance betweenthe query and the elements of the database followinga Round-Robin distribution. Most work is performedwithin the device function that performs the distancebetween elements and the query. Database elementsare stored column-wise to increase the chances of coalescememory accesses when computing these distancessince that way consecutive threads have toaccess adjacent memory locations.B. List of Clusters ( LC)The data structure that holds the LC index consistsof 3 matrices denoted as CENTER, RC andCLUSTERS. CENTER is a D × N cen matrix (D isthe dimension of the elements 2 and N cen is the numberof centers), where each column represents thecenter of a cluster, RC is an array that stores thecovering radius of each cluster, and CLUSTERS isa D × N clu matrix (N clu is the number of elementsin all the clusters) that holds the elements of eachcluster. Index information is stored column-wise tofavor coalesce memory accesses as in the Brute ForceTechnique.Each CUDA Block processes a different query,which is transferred from device memory to sharedmemory since it is accessed by all its threads whenperforming distance evaluations. Once the query hasbeen saved into the shared memory, a for loop iteratesover the different clusters. Each thread computesthe distance between q and a subset of elementsof CENTER following a Round-Robin distribution.Most work is performed again within thedevice function that performs the distance betweenelements and the query. If distances are lower thanrange, the respective centers cluster are appended tothe list of results. Clusters are marked for exhaustivesearch only if their respective center balls have someintersection with the query ball. A property of this2 For the Spanish database, D is the maximum size of a word.index (given by its construction) is that the exhaustivesearch over a cluster can be pruned if the queryball is totally contained in a given center ball. If thisis the case, then we do not consider the subsequentclusters delimiting the number of clusters.Finally, a for loop processes all the elements of theselected clusters as in the Brute Force technique.C. SSS-IndexThe SSS-Index consists of 3 matrices denotedas PIVOTS, DISTANCES and DB. PIVOTS is aD × N piv matrix (D is the dimension of the elementsand N piv is the number of pivots) where each columnrepresents a pivot, DISTANCES is a N piv ×N DB matrix(N DB = number of elements of the database)where each element is the distance between a pivotand a element of the database, and DB is a D×N DBmatrix where each column represents an element ofthe database. As in the LC, the index informationis stored column-wise to favor coalesce memory accesses.As in the LC, each CUDA Block transfers its associatedquery to shared memory due to its frequentaccess. Once the synchronization ensures the queryhas been copied before access it, each thread performsthe distance evaluations between the queryand a subset of pivots following a Round-Robin distribution.And finally, the rows of DISTANCES aredistributed across threads, that test if their respectiveelements of the database can be discarded. Forevery non discarded element, a distance evaluationis performed.In [6], authors have found empirically that aroundα = 0.4 yields the minimal number of distance evaluations.Our own experiments on GPUs confirm thisbehavior: the more pivots are used (up to a certainthreshold), the less distance evaluations are performed.However, the best performance is obtainedwith just one pivot for vector databases. Indeed themore pivots used, the worst the execution time becomes.Irregularity explains this apparent contradiction:when using more pivots, threads within a warpare more likely to diverge. Moreover, memory accesspattern becomes more irregular and hardware cannotcoalesced them, and this increases the numberof Read/Write operations. Summarizing, less distanceevaluations do not pay off due to the overheadscaused by warp divergences and irregular access patterns.Overall, just one pivot provides the optimalperformance for many of our reference databases.V. Experimental ResultsAll our GPU experiments were carried out on aNVIDIA GeForce GTX 280 which is shipped with30 multiprocessors, 8 cores per multiprocessor, 16KBof shared memory and 4GB of device memory. Thehost CPU is an Intel’s Clovertown processor, composedby 2xIntel Quad-Xeon (2.66 GHz), and in eachcore 32KB of L1 Cache for instructions and 32KB fordatas, each two cores shares the L2 Cache of 4MB,and the RAM is of 16 GB.JP2011-361

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011We have used two different reference databases:Spanish : A Spanish dictionary with 51,589 wordsand we used the edit distance [10] to measure similarity.On this metric-space we processed 40,000 queriesselected from a sample of the Chilean Web which wastaken from the TODOCL search engine. This can beconsidered a low dimensional metric space.Images : We took a collection of images from aNASA database containing 40,700 images vectors,and we used them as an empirical probability distributionfrom which we generated a large collectionof random image objects containing 120,000 objects.We built each index with the 80% of the objects andthe remaining 20% objects were used as queries. Inthis collection we used the euclidean distance to measurethe similarity between two objects. Intrinsic dimensionalityof this space higher than in the previousdatabase, but it is still considered low.In the vector database (Images) the radius usedwere those that retrieve on average the 0.01%, 0.1%and 1% of the elements of the database per query.In the Spanish database the radius were 1, 2 and3. Similar values have been also used in previouspapers [9][8]. In all the proposed methods, the set ofqueries are previously copied to device memory.Regarding the GPU implementation, we performeda wide exploration to obtain the best parametersfor each indexed structure. Regarding LC wefound that 64 elements per cluster is the best optionfor the vector database, while 32 performs thebest in the Spanish database. We already discussedSSS-Index tuning in Section IV-C. The conclusionsthere drawn hold for the Images database, so a singlepivot (α = 0.66) is used. However, for the Spanishdatabase it is better to use 64 pivots (α = 0.5).Figure 1 illustrates the performance characteristicsof our GPU implementations. Brute Force stands forthe exhaustive-search algorithm. LC and SSS-Indexshow the results for the two implemented indexingmechanisms with the parameters indicated above.All figures are normalized to the largest value of eachversion.We first place our attention on the total numberof distance evaluations (Figure 1(a)). Both databasebehaves as expected: indexing mechanisms do significantlydecrease the number of distance evaluationswhen compared to the brute force search method.SSS-Index typically outperforms LC when checkingdistance evaluations. And it does it if we considerthe Spanish database. However, since we just usedone pivot for the Images, LC becomes the winner inthis category. One would expect that running timesmimic the trend exhibited by the distance evaluationsbut results in Figure 1(b) partially contradictsthis intuition: the brute force search algorithm behavesbetter than expected in the Images database.It equals or even improves SSS-Index performance.For the Spanish database changes are not so drastic,but LC becomes the best implementation even if itperforms more distance evaluations.Figure 1(c) has the clue: the brute force techniqueNormalized Average of D.E.Normalized Running TimeNormalized Quantity of Read−Write OperationsD.B. ImagesD.B. Spanish0.80.70.60.50.40.30.20.100.9 1 0.01 0.1 1 1 2 3Percentage of Database RetrievedBrute ForceSSS−IndexL.C.Radii(a) Number of Distance EvaluationsD.B. ImagesD.B. Spanish0.80.70.60.50.40.30.20.100.9 1 0.01 0.1 1 1 2 3Percentage of Database RetrievedD.B Images(b) Running timeBrute ForceSSS−IndexL.C.RadiiD.B Spanish0.80.70.60.50.40.30.20.100.9 1 0.01 0.1 1 1 2 3Percentage of Database RetrievedBrute ForceSSS−IndexL.C.Radii(c) Number of read/write operationsFig. 1. Normalized a) Distance evaluations per query (average)b) Running time and c) Read-write Operations (of32, 64 o 128 bytes) to device memory.has a slightly better memory access pattern overSSS-Index when dealing with the Images database.The alignment of memory access heavily influencesperformance on current GPUs. As stated in SectionIII, when a warp launches misaligned or nonconsecutivememory accesses, hardware is not able tocoalesce it and a single reference may become up to32 separate accesses. The LC shows the best resultson this aspect on both databases, which explains itssuperior performance previously reported.A. Performance of parallel implementationsFigure 2 shows the performance speed-ups of ourGPU indexed implementations over optimized sequentialimplementations. Results are very impressivefor SSS-Index (up to 248x for 1% elements re-JP2011-362

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Speed-Up260240220200180160140120100806040200LCSSS-Index0.01 0.1 1Percentage of Database RetrievedFig. 2. Speed-Up of GPU versions of LC and SSS-Index oversequential counterparts with DB Images.trieved) due to the poor CPU performance of thisindexing mechanisms. But even for the lighter 3 index(List of Clusters) our implementation achievesa 29x speedup, which seems hard to attain with amedium-size multicore server.To prove that last point, we run the same experimentson the multicore system using the OpenMPimplementation presented in [9]. The OpenMP parallelversion scales worse than expected with thenumber of cores: our experimental framework consistsof 8 cores but the parallel implementation isjust 4 times faster than the sequential counterpart,as shown in figures 2 and 3.Given the synchonization-free parallelism exploited,we expected almost linear scaling with thenumber of cores. Indeed, with no aggressive compilationflags, the parallel version scales linearly. TableI shows this behavior for the List of Clusters implementationwhen retrieving 1% of the database foreach query: to increase the optimization level leadsto faster implementations but worsens the speedupmetric when compared with the sequential implementation.All the others experiments followed thesame trend.After aggressive compiler optimizations, the memorysystem becomes even more critical since densityof accesses increases. Even if no inter-thread communicationis present in our implementation, certainlevels of the memory system are shared. The effectof L2 sharing can be estimated when launching 4threads instead of 8. Default thread-to-core assignmentyields a x2.03 speedup factor over the sequentialimplementation. Making the assignment moreL2-cache friendly increases the speedup factor upto x2.5. The common memory controller is anotherbottleneck, since accesses from the 8 cores are issuedconcurrently. Conflicting accesses are then serialized,thus decreasing potential performance gains. Thisresource sharing explains the sub-linear speedup factorobtained.Figure 3 shows the speedups obtained by the GPUimplementation over the 8-core OpenMP version. Asexpected from the above discussion, it mimics the3 The required space to store the LC is equal to the 6% ofthe space required by the SSS-Index.LC No optimization flags With optimization flagsSequential Time 89.46s 21.94s8 cores 11.2 s 4.95sspeedup 7.98 4.43TABLE IExecution times of sequential and parallel versionSpeed-Up(OpenMP based, 8 cores) for List of Clusters.80706050403020100LCSSS-Index0.01 0.1 1Percentage of Database RetrievedFig. 3. Speedup of GPU versions of LC and SSS-Indexover corresponding OpenMP implementations with DBImages.trends of figure 2. SSS-Index benefits much morefrom the two level of parallelism exploited (bothinter- and intra- query parallelism). We achieved amaximum speedup of x76.104 when searching witha radius r = 0.73 (this radius implies to retrieve a1% of the elements of the reference database). LCperformance gains are more modest, but still relevant:from 5.96x to 7.92x depending on the selectedradius. This speedup factor may not lookimpressive taken into account that our GPU has30 multiprocessors on-board, compared with the 8-core Xeon based server used for OpenMP experiments.However, it is important to remind that eachof this NVIDIA multiprocessor is extremely simplerthan the Core/Nehalem michroarchitecture based IntelCPUs; instruction level parallelism is almost notexploited while it represents the main source of performancefor complex out-of-order processors.B. Solving queries on-lineAll results reported so far assume that we knowall the queries to be solved in advanced. For the Imagedatabase, that means that we assume a total of23831 queries in the system before we start solvingthem all in parallel. While this assumption could beadmissible for certain use cases, it could be unaffordablein on-line real-time systems like web searchingfor multimedia contents [11].We performed a productivity test in function ofthe number of queries issued in parallel. Figure 4(a)shows the results for the List of Cluster implementation.The x-axis indicates how many queries arelaunched in parallel (starting in five queries at atime). The y-axis shows the productivity of the systemmeasured in the number of queries processed bysecond. Not surprisingly, the productivity rapidlyJP2011-363

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011increases up to the point where we launch 30 queriesin parallel (remind that the GPU used in the experimentsincludes 30 multiprocessors). Below thatpoint the GPU is underused and the constant penaltyof launching a kernel weights too much. There is aknee at 30 but productivity still slowly increases dueto the GPU multithreading capabilities which allowsto hide long memory latencies effectively. Launchingqueries in batch of 200 is almost at the maximumproductivity achievable with our implementation(anyhow, it is always advisable to launch asmany queries in parallel as possible since it reducesthe number of kernel invocations).Figure 4(b) reviews the speed-up figures for the LCimplementation. The bar labeled Unlimited Batchcorresponds to the LC speed-up bar in figure 3. Itis the upper bound for GPU performance, since allqueries are solved with a single kernel invocation.Bars labeled Batch=30 and Batch=100 correspondswith a scenario where, as soon as we have 30 (resp.100) queries in the system, we launch a kernel tosolve them. Even if the productivity is not at itshighest point, the GPU implementation always outperformsthe OpenMP version. Please note thatOpenMP based implementations are still assumingtheir best-case, i.e. all queries are known from thebeginning, so no dispatching overhead is present. Aspeedup higher than 5x (in average) is achieved whenlaunching just 30 queries in parallel, which representsa very low frequency traffic scenario. Thus, we canconclude that GPUs can be used for on-line queryprocessing in metric spaces as a low-cost high performancealternative to traditional multi CPU implementations.VI. ConclusionsIn this paper we have presented efficient implementationsof suitable indexing mechanisms whichare mapped on CUDA based GPUs. We comparedthem against optimized OpenMP and sequential implementations,overcoming both of them.We found that the optimal parameters in the contextof the GPU, for both List of Clusters and SSS-Index, are extremely different than those found onthe sequential and OpenMP implementations. Inparticular, the best GPU implementation found forSSS-Index uses a single pivot to prune the searchspace, which shows that the SSS algorithm is inefficientsince this pivot is selected at random amongthe database objects.The List of Cluster is the index with best performanceon GPU, achieving a speed-up of 29x over thesequential counterpart, and 7.9x over an optimized8-thread OpenMP implementation.In the context of the processing of stream ofqueries, based on the productivity of our algorithms,we found that solving batches of queries whose sizeequals the number of GPU multi-processors is astrategy able to achieve good speed-up.References[1] Barbara Chapman, Gabriele Jost, and Ruud Van DerPas, Using OpenMP: portable shared memory parallelNumber of Queries/Time1000090008000700060005000400030002000100000 20 40 60 80 100 120 140 160 180 200Number of Queries(a) Productivity solving different number of queriesSpeed-Up876543210Batch=30Batch=100Unlimited Batch0.01 0.1 1Pecentage of Database Retrieved(b) Speed-Up over corresponding OpenMP implementationusing different size of batchFig. 4. a) Productivity (number of queries divided by itscorresponding running time) solving different number ofqueries of the LC over Images database. b) Speed-Upof LC solving a batch of queries (of 30 and 100) at atime over corresponding OpenMP implementation withDB Images.programming, The MIT Press, 2008.[2] Edgar Chávez, Gonzalo Navarro, Ricardo Baeza-Yates,and José L. Marroquín, “Searching in metric spaces,”in ACM Computing Surveys, September 2001, pp.33(3):273–321.[3] D. W. Aha and D. Kibler, “Instance-based learning algorithms,”in Machine Learning, 1991, pp. 37–66.[4] T. Cover and P. Hart, “Nearest neighbor pattern classification,”Information Theory, IEEE Transactions on,vol. 13, no. 1, pp. 21–27, 1967.[5] Edgar Chávez and Gonzalo Navarro, “A compact spacedecomposition for effective metric indexing,” PatternRecognition Letters, vol. 26, no. 9, pp. 1363–1376, 2005.[6] Nieves R. Brisaboa, Antonio Fariña, Oscar Pedreira, andNora Reyes, “Similarity search using sparse pivots forefficient multimedia information retrieval,” in ISM, 2006,pp. 881–888.[7] “CUDA: Compute Unified Device Architecture. c○2007NVIDIA Corporation.,” .[8] R. Uribe and G. Navarro, “Egnat: A fully dynamic metricaccess method for secondary memory,” in Proc. 2ndInternational Workshop on Similarity Search and Applications(SISAP). 2009, pp. 57–64, IEEE CS Press.[9] Veronica Gil Costa, Ricardo J. Barrientos, MauricioMarín, and Carolina Bonacic, “Scheduling metric-spacequeries processing on multi-core processors,” in PDP,Marco Danelutto, Julien Bourgeois, and Tom Gross, Eds.2010, pp. 187–194, IEEE Computer Society.[10] V.I. Levenshtein, “Binary codes capable of correctingdeletions, insertions, and reversals,” in Soviet PhysicsDoklady, 1966, vol. 10, pp. 707–710.[11] Mauricio Marin, Veronica Gil-Costa, CarolinaBonacic, Ricardo Baeza-Yates, and Isaac D. Scherson,“Sync/async parallel search for the efficient designand construction of web search engines,” ParallelComputing, vol. 36, no. 4, pp. 153 – 168, 2010.JP2011-364

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Redes y comunicacionesJP2011-365

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-366

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Desarrollo de un Prototipo para la NotificaciónAutomática de Accidentes de Tráfico usandoRedes VehicularesManuel Fogue 1 , Piedad Garrido 1 , Francisco J. Martinez 1 , Carlos T. Calafate 2 , Juan C.Cano 2 y Pietro Manzoni 2Resumen— Las nuevas tecnologías de la comunicaciónincorporadas al sector automovilístico ofrecenuna oportunidad para conseguir mejorar la asistenciaa los heridos en accidentes de tráfico, reduciendo eltiempo de respuesta de los servicios de emergenciay aumentando la información que éstos disponen sobreel siniestro, con lo que sería posible determinarcon mayor precisión el operativo humano y materialadecuado a la situación. El sistema e-NOTIFY propuestopresenta una arquitectura para dar soporte aestas necesidades, en la cual cada vehículo incorporauna Unidad de a Bordo encargada de detectar y notificarsituaciones de accidente a una Unidad de Controlexterna que se ocupa de estimar su gravedad ydestinar los recursos para su asistencia. El desarrollode un prototipo basado en dispositivos de propósitogeneral con un coste reducido y un nivel de eficienciaadecuado demuestra que este sistema podría reducirnotablemente el tiempo necesario para desplegarlos servicios de emergencia una vez producido elaccidente.Palabras clave— VANET, Sistemas Inteligentes deTransporte, comunicaciones V2V y V2I, accidentes detráfico.I. IntroducciónDURANTE las últimas décadas, el parque automovilísticoexistente alrededor del mundo hasufrido un crecimiento muy notable, aumentando ladensidad del tráfico y provocando que los accidentesde tráfico representen un problema muy grave en lamayoría de los países. Por poner un ejemplo, 2.714personas murieron en las carreteras españolas en elaño 2009, lo que significa una muerte por cada 16.949habitantes [1]. Gran parte de los fallecimientos seproducen en el tiempo comprendido entre el sucesoy la llegada de las asistencias médicas. En un accidentede tráfico, completar la asistencia de los heridosgraves durante la hora inmediatamente posterioral incidente (la llamada Hora de Oro) es crucial paraminimizar los posibles riesgos en la salud de los ocupantes.Por ello, una rápida y eficiente operaciónde rescate tras un accidente de tráfico incrementaríanotablemente la probabilidad de supervivencia de losheridos y reduciría la gravedad de las lesiones. Otrode los principales problemas actuales en la asistenciaa los accidentes de tráfico son las grandes pérdidas,tanto económicas como de tiempo, que se dan al nodisponer de cierta información que permita prever1 Depto. de Informática e Ingeniería de Sistemas,Universidad de Zaragoza, e-mail: {m.fogue, piedad,f.martinez}@unizar.es.2 Depto. de Informática de Sistemas y Computadores, UniversitatPolitècnica de València, e-mail: {calafate, jucano,pmanzoni}@disca.upv.es.el tipo y cantidad de equipamiento médico y técnicoque es necesario enviar a la zona del siniestro.Para una reducción notable del tiempo de asistencia,dos pasos principales deben abordarse: (i) la notificaciónrápida y precisa del accidente al Punto deRespuesta (Public Safety Answering Point, PSAP)adecuado, y (ii) la evacuación rápida y eficaz de losocupantes que se encuentran atrapados en el interiorun vehículo. El primero de estos objetivos puedellevarse a cabo empleando las tecnologías y los sistemasde telecomunicaciones que, recientemente, seha ido incorporando al mundo de la automoción,donde la comunicación móvil y los sistemas GPSson los máximos representantes. Durante los últimosaños, se han realizado numerosos avances en el desarrollode tecnologías de comunicación entre vehículos(V2V), también conocidas como (VANETs o VehicularAd hoc NETworks [2]). Estas tecnologíasestán basadas en sistemas de comunicación de cortoalcance, o Dedicated Short-Range Communication(DSRC) [3], y ofrecen soporte a aplicaciones de seguridadcooperativa entre vehículos. De hecho, seespera que el grupo de trabajo 802.11p apruebeen breve el estándar IEEE 802.11p [4], ofreciendouna solución factible para aplicaciones de seguridadinter-vehicular. Por otra parte, numerosos esfuerzose investigaciones desde el entorno académicoy de la industria han permitido avanzar en el desarrollode tecnologías de soporte a la interacciónvehículo-infraestructura (V2I), de especial relevanciapara aplicaciones de seguridad vial, movilidad ymonitorización.Respecto al segundo de los objetivos, la eficaciade la asistencia de los pasajeros involucrados en unaccidente de tráfico, ésta podría aumentarse notablementesi los servicios de emergencia dispusieran deinformación relevante sobre las condiciones en quesucedió el siniestro antes de desplazarse a la zonadel accidente. Esta información extra se emplearíapara estimar la gravedad de las heridas de los ocupantes,basándose en la información proporcionadapor los sensores del vehículo. Asimismo, disponer demás información permitiría determinar el conjuntoóptimo de recursos humanos y materiales a enviara una situación de accidente, con la consecuente reducciónde costes e incremento de la calidad de asistenciade los heridos.En este trabajo se presenta el sistema e-NOTIFY,diseñado para la detección, notificación y asistenciaautomática de los accidentes viales utilizando las ca-JP2011-367

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.Arquitectura e-NOTIFY basada en combinación de comunicaciones V2V y V2I.pacidades que brindan las nuevas tecnologías de comunicaciónvehicular. Esta propuesta no se centraen reducir el número de accidentes, sino en mejorar laasistencia post-colisión mediante una gestión rápiday eficiente de los recursos de emergencia disponibles,lo cual incrementa las posibilidades de recuperacióny supervivencia para los heridos en accidente detráfico.El resto de este artículo se estructura como sigue.La Sección II incluye la arquitectura del sistema propuesto.La Sección III muestra los pasos para diseñarun prototipo con dispositivos de propósito generalque aporten la funcionalidad requerida por el sistema.La Sección IV presenta el entorno en el que sellevó a cabo la validación del sistema y los resultadosde su evaluación. Por último, la Sección V presentalas conclusiones obtenidas de la realización de estetrabajo.II. Arquitectura del sistema e-NOTIFYLa Figura 1 presenta la estructura básica empleadapara desarrollar el sistema e-NOTIFY. El objetivodel sistema consiste en proporcionar una arquitecturaque permita: (i) comunicación directa entre losvehículos involucrados en el accidente, (ii) el envíoautomático de un conjunto de datos al Centro deCoordinación de Emergencias, y (iii) una evaluaciónpreliminar automática de los daños, tanto enel vehículo, como en los ocupantes basándose en lainformación recibida y los datos sobre accidentes previamenteacaecidos, lo cual permitiría adaptar losrecursos de rescate necesarios para su correcta asistencia.El sistema e-NOTIFY combina comunicacionestanto V2V como V2I para conseguir notificar deforma eficiente una situación de accidente al Centrode Control. Los diferentes vehículos deben incorporaruna Unidad de a Bordo (On Board Unit, OBU)que se encarga de detectar cuándo se ha producidoun impacto peligroso para los ocupantes, de recogerla información disponible de los sensores instaladosen el automóvil y de comunicar la situación a unaUnidad de Control (Control Unit, CU) que se ocuparádel tratamiento del mensaje de aviso y su posteriorenvío. Entre otros aspectos, la CU debe integrarmecanismos de estimación de la gravedad del accidentey de las heridas de los pasajeros, por lo quedebe tener acceso a una base de datos lo más completaposible con información sobre otros siniestros.Esta estimación puede llevarse a cabo con modelos declasificación de minería de datos usando los registrosde bases de datos existentes [5].La definición de las OBUs es de gran importanciapara el sistema propuesto. Este dispositivo debe sertécnicamente y económicamente factible, ya que suimplantación en vehículos de diversa gama podría llegara ser masiva cuando se comiencen a extender lossistemas de comunicación entre vehículos. Además,este sistema debe estar abierto a futuras actualizacionesde software. Aunque en el diseño del hardwarea incluir en los vehículos consistía inicialmenteen sistemas de propósito específico, esta tendenciaestá dirigiéndose hacia sistemas de propósito másgeneral dada la inclusión constante de nuevos servicios.Por tanto, la OBU tiene que incluir suficientesinterfaces que le permitan conectarse al sistema decomunicación.El intercambio de información entre las OBUs y laCU se produce a través de Internet, bien mediantevehículos que tengan instalado un acceso a Internet(mediante UMTS, por ejemplo), o bien alcanzandounidades de infraestructura (Road-Side Units, RSU)que proporcionen este servicio. En el caso de queel vehículo no consiga acceso directo hasta la CUpor sus propios medios, puede generar mensajes dedifusión que serán retransmitidos por los vehículoscercanos hasta que se alcance una de las dos posibilidades.Estos mensajes que se van difundiendo entrelos vehículos en el área cercana al accidente tambiéntienen la función de alertar a los conductores que seJP2011-368

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111050-5Aceleracion (G)-10-15-20-25-30No acc. (15 km/h)Acc. leve (40 km/h)Acc. grave (64 km/h)-350 0.05 0.1 0.15 0.2 0.25Tiempo (s)Fig. 2.Estructura del prototipo de Unidad de a Bordo.Fig. 3. Pulsos de aceleración para diferentes clasificacionesde accidente frontal. Datos propocionados por Applus+IDIADA [10].dirijan a la zona afectada por el siniestro sobre lascondiciones en que se encuentra el vehículo accidentadoy su posible interferencia en el flujo de tráficohabitual.III. Diseño del prototipo e-NOTIFYUsando esta arquitectura como marco de referencia,se ha desarrollado un prototipo empleando dispositivosde propósito general que pueda servir parallevar a cabo pruebas preliminares hasta que la tecnología(como el estándar IEEE 802.11p) y la infraestructura(RSUs) necesaria esté disponible parasu despliegue en un entorno real. La configuración decada uno de los componentes del sistema se detallaa continuación.A. Diseño de la Unidad de a Bordo (OBU)El principal objetivo de una OBU reside en obtenerla información disponible a partir de los sensores instaladosen el vehículo para determinar cuándo se haproducido una situación de peligro que deba ser notificadaal punto de respuesta más cercano, así comoal resto de vehículos cercanos que puedan enfrentarsea esta situación. La estructura del prototipo desarrolladoaparece en la Figura 2, en el cual la unidadempleada es un netbook Asus Eee PC [6] dotado condisco de estado sólido (SSD) para minimizar la posibilidadde deterioro debido al impacto. La posicióny velocidad del vehículo se obtiene mediante un dispositivoGPS Qstarz BT-Q818XT [7] accesible porBluetooth.Cuando se desarrolla un prototipo de Unidad dea Bordo, la conexión con la sensórica del vehículopuede llegar a ser complicada ya que cada fabricantepresenta diferencias en la forma de representar losdatos. Además, gran parte de estos sensores sonanalógicos, de forma que para poder tratar correctamentelos datos proporcionados es necesario realizaruna transformación previa a un formato digital. Estosproblemas se han resuelto empleando un microcontroladorARM mbed NXP LPC1768 [8] que permitegenerar prototipos rápidamente ya que, entreotras funcionalidades, incorpora un compilador parael lenguaje C++, permite leer directamente una entradaanalógica y puede comunicarse con un PC mediantediversas interfaces, entre las que se incluyeUSB y un puerto Ethernet. Otros trabajos ya hanempleado este sistema con éxito en tareas de controlautomático [9].El microcontrolador está programado para recogerperiódicamente los datos de los sensores que permitirándeterminar cuándo un vehículo ha sufridoun accidente que sería necesario informar a las autoridadespertinentes. Básicamente, se trata deacelerómetros y giroscopios que indican la severidadde los golpes recibidos por el automóvil o si ha sufridoun vuelco que haga peligrar la integridad de los ocupantes.La comunicación del microcontrolador conla Unidad de a Bordo se realiza enviando paquetesUDP con frecuencia variable (en las pruebas de funcionamiento,se empleó una frecuencia de 50 paquetespor segundo) a través de la interfaz Ethernet incorporada.La OBU se encarga de recoger los datos enviadospor el microcontrolador y generar una serie temporalcon los valores medidos. La evolución tantoen las medidas de aceleración como en las de inclinaciónrespecto a la horizontal permitirán determinarcuándo el vehículo ha sufrido daños de consideración.El tratamiento de la inclinación es bastantesencillo, puesto que mediciones que se desvíen másde 90 o de la horizontal indicarán que el vehículo havolcado y precisa de medios de rescate. Interpretarlos valores de aceleración es más complicado debidoa que los pulsos que se reciben tienen una duraciónmuy limitada y debe considerarse en su clasificacióntanto su amplitud como su duración. Este efectose aprecia en la Figura 3, en la que aparecen representadosdiferentes pulsos correspondientes a unaccidente frontal de diversa consideración (desde noconsiderarlo un accidente, hasta accidentes severosdonde los ocupantes pueden haber sufrido heridasgraves). Puede apreciarse que el pico de aceleraciónregistrado en el accidente leve supera al máximo en lacolisión grave, aunque la duración de su pulso es mu-JP2011-369

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cho menor. Emplear simples umbrales de aceleraciónregistrada para diferenciar los pulsos no es suficiente,por lo que el enfoque empleado será utilizar el valorde la integral de la función definida como la variaciónde la aceleración respecto al tiempo. Esta aproximaciónsí permite definir umbrales que diferencian consuficiente margen las distintas situaciones. La integralde la función se aproxima mediante el métodonumérico de la regla del trapecio, con la que la integralde una función f definida en una serie n deintervalos regulares es igual a:∫ xnx 0f(x)dx ≈n∑i=1(x i − x i−1 ) f(x i) − f(x i−1 )2(1)La función de la aceleración se comienza a integrarcuando se detecta una medición con valor absolutosuperior a un umbral, que está fijado entre3 y 5 Gs (1 G = 9.80665 m/s 2 ) dependiendo deltipo de impacto (frontal, lateral o trasero) y del segmentoal que pertenece el vehículo. Tras un periodode tiempo (que aproxima la duración del pulso), elvalor de la integral determinará el tipo de accidentedependiendo de si superan o no los límites fijados enlas trazas de prueba. Si el accidente ha sido de suficientegravedad, la OBU pasará a enviar paquetesUDP con información sobre el suceso a sus vecinospara alertar del peligro de la situación. Además, seabrirá una conexión TCP con el punto de respuestapara alertar del accidente y solicitar el envío de unoperativo de emergencia. Para ello, el mensaje transmitidocontendrá tanta información relevante comosea posible sobre el siniestro.B. Estructura del mensaje de avisoLos mensajes que se intercambien entre losvehículos y la Unidad de Control deberían ser concisosy no incluir información irrelevante, pero no deberíanobviar ningún posible dato que pudiera servira los servicios de emergencia para determinar los recursosnecesarios. Así, la información destinada alpunto de respuesta debe incorporar datos sobre lascondiciones en que se produjo el accidente, sobre losocupantes del vehículo y sobre los diversos sistemasde seguridad incluidos. Estos datos están dirigidosa los equipos de asistencia para proporcionarles unavisión más detallada de las condiciones del siniestroantes de llegar a la zona afectada [11]. Para el sistemadiseñado se propone enviar un mensaje quecontenga los siguientes campos, accesibles a travésde los sensores incluidos en el propio vehículo (verFigura 4):TIEMPO (FECHA/HORA)• para informar exactamente sobre el momento delaccidente.LOCALIZACIÓN• posición geográfica del vehículos, para determinarla localización exacta de los heridos.VEHÍCULO-OCUPANTESVehicle &occupantsAccident0 31VehiclespeedTimeLocationFeatures ofthe passengers# passengersseat belts and airbagsaccelerationpoint(s) of impactdirectionpositionFig. 4. Formato de paquete de aviso para el sistema propuesto.• características del vehículos, para adecuar elequipamiento a enviar al escenario del accidentey avisar al equipo de rescate sobre el nivel decomplejidad y peligros.• número de pasajeros, para adecuar el equipomédico requerido para atenderlos.• características de los pasajeros: peso, altura,edad, etc. Mejor cuanta más informaciónesté disponible.• información sobre cinturones de seguridady airbags, para estimar la severidad de los heridos,cómo sucedió el accidente y la gravedad delmismo.ACCIDENTE• velocidad y aceleración del vehículo justoantes del impacto, para estimar la severidad delsiniestro.• punto/s de impacto, es decir, dónde exactamentese ha producido el impacto contra otroobjeto de la vía.• dirección de la fuerza de impacto. Éstees un concepto mecánico. Si consideramos laplanta del vehículo como un reloj, puede describirsela dirección de impacto como una hora:12 para impacto frontal, 3 para impacto lateralderecho, 6 para impacto trasero, etc.• posición del vehículo después de la colisiónpara estimar la gravedad del accidente y avisaral equipo de emergencia sobre la complejidad delrescate.C. Diseño de la Unidad de Control (CU)La Unidad de Control (CU) está asociada al centrode respuesta encargado de recibir las notificacionesde accidente provenientes de las OBUs instaladas delos vehículos. La Unidad de Control se encarga detratar los mensajes de aviso, obtener la informacióncontenida en los mismos y notificar a los servicios deemergencia sobre las condiciones en que se ha producidoel accidente. El prototipo de la Unidad deControl tiene la estructura que aparece en la Figura5.JP2011-370

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 5.Estructura del prototipo de Unidad de Control.Una vez recibido el mensaje, la CU debe almacenarlos datos del accidente en una base de datos pararegistrar que ha sido asistido correctamente. Deberíaexistir a disposición de la CU una base de datosque aporte diferente información sobre los posiblesmodelos y marcas de vehículos existentes en el parqueautomovilístico. Las áreas críticas del vehículoque deben ser evitadas durante procedimientos derescate (por ejemplo, los depósitos de combustible)no están señalizadas en la mayoría de los casos ypodrían causar situaciones de peligro para el personalde emergencia. De esta forma, ante una notificaciónde accidente puede conocerse la información referenteal vehículo siniestrado (manuales de operación,información sobre áreas peligrosas, etc.) antes deque los equipos de rescate lleguen a la zona en la queocurrió.El prototipo de CU incluye una interfaz Web que(con autenticación previa) incluye información sobrelas diversas notificaciones recibidas hasta el momento.De cada una de ellas puede obtenerse informacióndetallada y visual sobre posición y condicionesde los pasajeros (uso de cinturón de seguridad,despliegue del airbag, zonas de corte para laexcarcelación de los ocupantes, etc.), fecha y hora, localizacióndel accidente (con visualización mediantela API de Google Maps [12]), etc. La Figura 6 presentaun ejemplo de un accidente simulado con 3 ocupantes.IV. Validación del sistemaEl prototipo diseñado fue validado en las instalacionesdel Departamento de Seguridad Pasiva deApplus+ IDIADA [10] en Santa Oliva (Tarragona).Estas instalaciones albergan uno de los laboratoriosde choque más sofisticados del mundo y constituyenun centro oficial para la homologación según el programaEuroNCAP [13].Debido al coste de emplear vehículos reales en losexperimentos de choque, las pruebas con el prototipoe-NOTIFY se realizaron empleando una plataforma(conocida como “trineo”) que se desplaza sobre raíleshasta impactar contra una serie de barras metálicasFig. 6. Captura de la interfaz Web con información sobre unaccidente notificado.que simulan la deformación que sufriría la carroceríadel vehículo para amortiguar el golpe. La velocidad ala que se produce el golpe y la configuración de barrasutilizada en el test determinan, respectivamente, laclase de accidente detectado y el segmento al quepertenecería el vehículo que se está simulando.La Figura 7 muestra el trineo utilizado en las pruebas,al cual se fijaron una serie de pesas para completarla simulación del comportamiento de un vehículoconvencional. En la Figura 8 aparecen las fijacionesempleadas para instalar el prototipo de OBU a laplataforma. Los ensayos consistieron en pruebas decolisión frontal (que representaron situaciones de accidentesevero, accidente leve y no accidente), colisiónlateral (situaciones de accidente y no accidente)y colisión trasera (de nuevo, situaciones de accidentey no accidente). La clasificación de la severidad dela colisión viene impuesta por los parámetros queemplea Applus+ IDIADA en los tests EuroNCAP yJP2011-371

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 7. Trineo con el prototipo e-NOTIFY instalado antes deuna prueba de detección de accidente.Fig. 8.Primer plano del prototipo montado sobre el trineo.RCAR [14].El sistema de prueba incluía un ordenador externoal trineo que recibía información periódica (medianteuna red inalámbrica ad hoc) de las mediciones registradaspor la OBU para asegurar el correcto funcionamientodel módulo de lectura, junto con otroordenador que simulaba la Unidad de Control encargadade recibir los mensajes de alerta. La pruebapermitió demostrar que la OBU era capaz de detectarcorrectamente tanto la fuerza como la direccióndel impacto, así como generar un mensaje de avisoadecuado a partir de los datos de los sensores y enviarlomediante la tecnología UMTS a la Unidad deControl en todos los ensayos realizados.V. Conclusiones y Trabajo FuturoEn este artículo se ha presentado el sistema e-NOTIFY, el cual permite mejorar la asistencia delos heridos en accidentes de tráfico, mediante la reduccióndel tiempo de respuesta de los servicios deemergencia y el envío de información relevante sobrelas condiciones del siniestro empleando una combinaciónde comunicaciones V2V y V2I. Esta arquitecturasustituye los mecanismos habituales de notificaciónde accidente, basados en testigos presencialesque pueden aportar información incompleta o incorrectaen un tiempo no adecuado. Además, el desarrollode un prototipo de costo reducido demuestraque es factible la incorporación de este sistemaal parque de vehículos a gran escala, siempre quese disponga de la infraestructura externa adecuada(RSUs, servidores dedicados para el tratamiento delos mensajes de aviso, y bases de datos con informaciónsuficiente sobre accidentes de tráfico y procedimientosde actuación ante siniestros de esta naturaleza).Como trabajo futuro se desarrollará una nuevaversión del sistema utilizando el estándar 802.11p.Además, se pretende realizar un despliegue del sistemaen un entorno real con las OBUs instaladas enlos vehículos, para comprobar el comportamiento delsistema con nodos en movimiento a grandes velocidades.AgradecimientosEl presente trabajo ha sido financiado parcialmentepor el Ministerio de Ciencia e Innovación mediantela Ayuda TIN2008-06441-C02-01, y por laDiputación General de Aragón mediante la Ayuda“Subvenciones destinadas a la formación y contrataciónde personal investigador”.Referencias[1] Dirección General de Tráfico (DGT), “Lasprincipales cifras de la siniestralidad vial.España 2009,” 2009, Disponible en:http://www.dgt.es/portal/es/seguridad vial/estadistica.[2] H. Hartenstein and K.P. Laberteaux, “A tutorial surveyon vehicular ad hoc networks,” Communications Magazine,IEEE, vol. 46, no. 6, pp. 164 –171, june 2008.[3] Hyunseo Oh, Chungil Yae, Donghyon Ahn, and HanbergCho, “5.8 GHz DSRC packet communication system forITS services,” in Vehicular Technology Conference, 1999.VTC 1999 - Fall. IEEE VTS 50th, 1999, vol. 4, pp. 2223–2227 vol.4.[4] Task Group p, “IEEE P802.11p: Wireless access in vehicularenvironments (WAVE),” IEEE Computer Society,2006.[5] Miao Chong, Ajith Abraham, and Marcin Paprzycki,“Traffic Accident Analysis Using Machine LearningParadigms,” Informatica, vol. 29, pp. 89–98, 2005.[6] AsusTek Computer Inc., “ASUS EeePC 901 Review,” 2011, Disponible en:http://www.asus.com/Eee/Eee PC/Eee PC 901.[7] Qstarz International Co., “Qstarz BT-Q818XT Bluetooth GPS: Features andSpecification,” 2011, Disponible en:http://www.qstarz.com/Products/GPS%20Products/BT-Q818XT-F.htm.[8] “MBED NXP LPC1768: Información de referencia,”2011, Disponible en: http://mbed.org/nxp/lpc1768.[9] Kenneth B. Hornfeck, “A Customizable Socially InteractiveRobot with Wireless Health Monitoring Capability,”M.S. thesis, Case Western Reserve University, Cleveland,OH, USA, 2011.[10] Applus+ IDIADA: Instituto de Investigación Avanzadadel Automóvil, “Información y recursos,” 2011,Disponible en: http://www.idiada.es.[11] F.J. Martinez, C.-K. Toh, J.-C. Cano, C.T. Calafate, andP. Manzoni, “Emergency services in future intelligenttransportation systems based on vehicular communicationnetworks,” Intelligent Transportation Systems Magazine,IEEE, vol. 2, no. 2, pp. 6 –20, summer 2010.[12] “Google Maps API Family,” 2011, Disponible en:http://code.google.com/apis/maps.[13] EuroNCAP (European New Car AssessmentProgramme), “Procedimientos de evaluacióny resultados de tests,” 2011, Disponible en:http://www.euroncap.com/testprocedures.aspx.[14] RCAR, the Research Council for Automobile Repairs,“Guías de diseño e información para fabricantes,” 2011,Disponible en: http://www.rcar.org.JP2011-372

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Hierarchical Analysis of ResilienceBenchmarking Results Using LSP:Ad Hoc Networks As a Case StudyJesús Friginal, Juan-Carlos Ruiz, David de Andrés and Pedro Gil 1Abstract— The practical exploitation of ad hoc networkingapproaches in real-life products, such as vehicularad hoc networks and sensor networks, requiresthe definition of benchmarking techniques to guidethe selection of suitable routing protocols which fitin each particular context of use. However, experienceshows that such selection process may requirethe analysis of a wide amount of different results,leading the benchmark user to error-prone interpretations.This paper proposes the use of the Logic Scoreof Preferences (LSP) technique to reduce the complexityof the analysis process. LSP enables the systematisationof measures aggregation and establishesa hierarchical approach to their analysis. Althoughthe approach is general and applicable to many differenttypes of systems, it will be illustrated in thiscontribution through a case study where different implementationsof an ad hoc routing protocol are consideredas eligible for a particular application.Keywords— Logic Score of Preferences, Resiliencebenchmarking, Ad hoc networksI. IntroductionRESILIENCE benchmarks are well-specified procedureswhich enrich the notion of traditionalperformance benchmarking to enable the objectiveevaluation, comparison and selection of componentsand systems in the presence of (accidental and malicious)faults. This increases the complexity of conventionalbenchmarks. Indeed, in addition to thedifferent considered benchmark targets, the workloadrequired to exercise the system, and the performancemeasures defined to characterise the system’sbehaviour, it is also necessary to establish the set offaults that may impact the system regular behaviourduring operation. The notion of faultload appears inthis context. It reflects the faulty conditions thatmight affect the operation of the system, and theset of measures to characterise the system reactionto considered faults in terms of dependability andsecurity [1].From a practical viewpoint, this gives rise to someserious challenges in the analysis of the benchmarkoutputs. The problem appears not only when thecombination of the aforementioned aspects lead toan explosion of results, but also when performing ahierarchical analysis requiring the aggregation of aheterogeneous set of different types of measures likethose related to performance, resilience, consumptionand cost. The complexity associated to thesechallenges usually lead to an error-prone interpretationof the benchmark results and restricts the useful-1 STF-ITACA, Universitat Politècnica de València, e-mail:{jefrilo, jcruizg, ddandres, pgil}@disca.upv.esness of such result for benchmark users with limitedskills in resilience aspects. Independently from theconsidered benchmark target, this problem affectsthe resilience benchmarking of any type of system,ranging from, e.g., databases to VLSI systems.Measures aggregation is a valuable approach toease the analysis of benchmarked systems or components.The goal of measures aggregation is notreplacing the set of measures obtained during benchmarking,but complementing them with a singleglobal score which guides and eases the decision makingof system evaluators. However, although the notionof measures aggregation is well-known and appliedin the community of resilience benchmarking, itis surprising that nowadays there is still a lack of unifiedcriteria when addressing the aggregation of measuresand their subsequent analysis. Accordingly, aspectssuch as how to systematically aggregate suchmeasures to capture information of the overall systemand how to ensure the consistency of interpretationsbetween fine- and coarse-grained measures, arestill open questions requiring further research.In this paper, the aforementioned problems arestudied within the scope of ad hoc networks. Adhoc networks are dynamic self-managed wireless networksmade of nodes which collaborate to maintainnetwork connectivity without requiring any centralisedinfrastructure. According to these promisingproperties, ad hoc networks are increasingly used asan alternative to provide quick and low-cost communications.Nowadays, one can find several examplesof ad hoc networks in our daily lives [2] [3]. Some ofthe most representative examples are Wireless SensorNetworks (WSN) to monitor information of themedia like temperature or humidity; Mobile Ad HocNetworks (MANET) to establish multi-hop communicationsbetween mobile targets like people or vehicles;and Wireless Mesh Networks (WMN), to providelow-cost Internet connection to isolated areas.Routing protocols are essential elements for theoperation of ad hoc networks. In order to establishmulti-hop communications, routing protocols enableany pair of nodes in the network to connect throughintermediate ones acting as routers. Given their criticalrole, the main strengths of such protocols maybecome their main weaknesses since any expositionto accidental or malicious faults (or attacks) couldcompromise the whole behaviour of the network.In our prior work, we took an initial step towardsthe analysis of aggregated measures propos-JP2011-373

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ing a qualitative approach to obtain a global visionof the impact of faults on ad hoc routing protocols,the core components of ad hoc networks [4]. In thispaper we take a step beyond to ease the hierarchicalanalysis of resilience benchmarking results by meansof a mathematical-based technique called Logic Scoreof Preferences (LSP). Introduced by Dujmović in [5],LSP is a fuzzy-logic-based approach that computesthe global score of a component through measuresaggregation, easing the hierarchical analysis of thesystem characteristics.Although this technique has been successfully usedfor the quantitative quality evaluation of a wide varietyof software engineering products (ranging fromsearch engines to web browsers), this is the first attempt,to the best of our knowledge, of applying thistechnique in the domain of resilience benchmarkingand ad hoc networks.The rest of this paper is structured as follows. SectionII reports the different alternatives for measuresaggregation and analysis. Secion III introduces theLSP technique. Section IV applies the LSP techniqueto analyse and interpret the results obtainedfrom a case study where different ad hoc routing protocolsare benchmarked. Finally Section V presentsconclusions.II. Measures-Aggregation ApproachesThe literature offers different graphic and analyticalternatives to synthesise the measures obtained duringthe evaluation of a target system.Kiviat or radar diagrams [6] are a graphical toolwhich represent the results of the benchmark inan easy-to-interpret footprint. Kiviat diagrams canshow different measures using only one diagram and,although some training is required, the comparisonof different diagrams is fairly simple. The scalabilityof Kiviat diagrams enables the representation ofup to tens of measures. However, managing such ahuge amount of information may make difficult theinterpretation and analysis of results.The problem previously stated is solved in [6]throughout the use of an analytical technique namedthe figure of merit, which imposing certain restrictionsto the graph axes, synthesises all the measuresinto a unique value related to the footprint shape.However, the problem associated to this solution, asit happens with most techniques using the mean orthe median, is that valuable information could behidden behind a unique number, and consequently,the comparison between protocols could result quitevague [7].Other approaches, like the presented in [8], characterisethe level of goodness of the measures accordingto their ability to fit with a particular statisticaldistribution. Nevertheless, this approach presentstwo main drawbacks. First, it assumes that a measurefollows the same distribution for all the systems,which may not be true depending on the context ofuse. And second, to understand this type of characterisation,it is necessary to understand the assumedstatistical model, which is not straightforward.Finally, other authors, like Al-Sbou [9], proposethe use of custom formulas for the aggregation ofmeasures obtaining a single score which characterisesthe behaviour of the system. However, these typesof formula definition is based on heuristics and lacksformal foundation and validation.In sum, these methodologies lack the ability of aggregatingmeasures into a meaningful result that: i)is easy to explain and interpret; ii) is representativeof real systems and allows their comparison and ranking,and iii) captures enough information to enablethe hierarchical analysis of measures from coarse tofine-grained measures (and vice-versa).III. Logic Score of PreferencesThe LSP technique computes the global score of asystem through the recursive decomposition of theircharacteristics into subcharacteristics and so on, untilobtaining quantifiable attributes (or measures).However, what makes it interesting with respect toto the rest of approaches presented in Section II accordinga resilience benchmarking viewpoint, is itscapability to navigate from the fine-grained measuresto the coarse-grained scores, without losing the numericalviewpoint of results. Thus, keeping the consistencyin the interpretation and analysis of resultsindependently from the viewpoint (fine or coarse) acquiredby the benchmark user.In general terms, LSP computes the global score(S) of a system using Formula 1.S = (k∑w i s r i ) 1 r /i=1k∑w i = 1 (1)i=1In this formula, each s i represents an elementaryscore (referred to as elementary preference) relatedto each (sub)characteristic of the targeted system.Different criterion functions specify how to quantitativelyevaluate each attribute, i.e., they establishan equivalence between the attribute value and thesystem quality requirements. To cope with this goal,the value of the attribute is scored within a 0-to-100scale, which results in an elementary preference scores i that can be interpreted as the degree of satisfactionof an attribute a i with respect to the qualityrequirements specified by the benchmark performerfor such attribute. Since all the attributes are scoredaccording to the same scale, resulting elementarypreferences are directly comparable. Such equivalencecan be mapped to a discrete function, thusestablishing different quality levels, or to a continuousone. Additionally, as far as the k elementarypreferences that compound the aggregation block definedby each characteristic may not have the sameimportance, a weight w i , illustrating such influence,must be assigned to each elementary preference. Inthis line, it is also necessary to define the degree ofmandatoriness that must be fulfilled for each aggregationblock. The power r, described in detail in[5], represents one logic operator in charge of definingthe type of relationship (from orness to andness)JP2011-374

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011required for the different elementary scores withinthe same aggregation block. In [5], the author definesup to 20 different logic operators which describea mandatoriness------------------------------------------------- Operation Symbolr2r3r4r5gradation among the requirementsof the system. Such gradation ranges from the fullconjunction (logic AND) which illustrates the simultaneityamong all the requirements, to the full disjunction(logic OR) which represents the notion ofreplaceability,SQUAREMEAN DISJUNCTION D+infty+infty+infty+inftyWEAKQD(-) WEAKQD(+) MEDIUMQD STRONGQD(-)D+-5.8026.6757.3167.819STRONGQD(+)D++20.63024.30027.11030.090 DA3.9294.4504.8255.111 D+9.52111.09512.27013.235where meeting just one requirement isenoughARITHMETICMEANA1.0001.0001.0001.000D--1.4491.5191.5651.596 D-+2.7923.1013.3183.479 SQU2.000 D-2.0182.1872.3022.384(see Figure 1).MEDIUMQC STRONGQC(-)C+--1.655-1.550-1.455-1.380 HARMONICMEANHAR-1.000 WEAKQC(+) GEOMETRICMEANGEO0.000 WEAKQC(-) C-+-0.148-0.208-0.235-0.251 CA-0.720-0.732-0.721-0.707 C--0.6190.5730.5460.526STRONGQC(+)C++-9.060-7.639-6.689-6.013 C+-3.510-3.114-2.823-2.606 C-0.2610.1920.1530.129CONJUNCTION C-infty-infty-infty-inftyFig. 1. Aggregation operators proposed by Dujmović, and rvalue for 2, 3, 4 and 5 inputsOnce all the intermediate scores have been computeduntil obtaining a global score, a coarse-grainedanalysis of each target can be performed. Then, theanalysis can be progressively refined using the availableintermediate scores until considering the originalbenchmarking results. The benefit of using LSP relieson the fact that it systematises the way in whichscores are obtained from measures and naturally establishesa hierarchical approach for their analysis.The main concepts of LSP are illustrated throughoutFigure 2.Attributes(Benchmark measures)Fig. 2.AggregationAnalysisW·SW·SW·SW·SMeasures are aggregatedattending to a relationshipestrablished by thebenchmark performerW·SW·SS: Intermediate scoresRepresentation of the LSP techniqueIV. Case StudyAs already stated, LSP is a technique that can beapplied to any type of system or component. TheGlobal Scorecase study proposed in this paper emulates the deploymentof a Wireless Mesh Network (WMN) [10],one of the most extended types of ad hoc network.A. Experimental Set-upOur deployment consisted of 16 wireless nodes (includinglaptops and routers). As previously stated,benchmark users must carefully select the most suitablerouting protocol to provide quality communicationswithout delays nor interruptions. olsrd, developedby the most active and wider communitydevoted to the development of open-source routingprotocols (www.olsr.org), is the most extended implementationof the popular Optimized Link StateRouting (OLSR) protocol. Accordingly, three differentversions of olsrd, using the same configuration,have been selected as benchmarks targets: v.0.4.10(released in 2006), v.0.5.6 (released in 2008) and currentv.0.6.0 (released in 2010).The applicative traffic addressed to exercise thenetwork was defined in terms of synthetic UDP ConstantBit Rate (CBR) data flows of 200 Kbps, similarto the rates observed in daily scenarios [11].In order to recreate some of the most importantproblems in the domain of WMNs [10], we selected asubset of 5 of the most harmful faults (both accidentaland malicious faults or attacks), according to ourprior investigation [4] (see Table I), to be injectedwhile running the workload.TABLE IFaults considered during the experimentationFault Type OriginAmbient noise (A) Accidental NaturalSelective forwarding attack (S) Malicious Human-madeJellyfish attack (J) Malicious Human-madeTampering attack (T) Malicious Human-madeFlooding attack (F) Malicious Human-madeB. Aggregation of MeasuresOnce the benchmark experimental conditions havebeen specified, it is necessary to define the differentmeasures that will be used to assess the quality of theconsidered benchmark target. Conversely to othermeasures-aggregation techniques which are just appliedonce the final measures have been obtained, theLSP technique may assist the benchmark performerto define a comprehensive hierarchical model of measuresapplying a series of refinements. The goal ofthis process is to characterise the quality of the systemthrough a complete and not redundant set ofelemental attributes or variables (a 1 to a n ). This setdefines a block and can contain a different amount ofattributes. This blocks composition continues groupingdifferent characteristics until the global score ofthe system is computed.B.1 Measures SelectionApplying this measures-aggregation strategy in anad hoc network involves characterising this particularsystem through its different characteristics. ForJP2011-375

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011the purpose of this case study we have consideredperformance, resilience and consumption. In addition,different attributes have been identified for eachcharacteristic (as depicted in Figure 3) in order to refinethe proposed model.Fig. 3.Ad hoc network1. Performance1.1. a 1 : Packet loss (%)1.2. a 2 : Delay (ms)2. Resilience2.1. a 3 : Availability (%)2.2. a 4 : Integrity (%)3. Consumption3.1.a 5 : Energy (J)LSP hierarchy illustrating the case studyResulting attributes will be the fine-grained measureswe are able to obtain throughout our benchmarkingexperiments. The description of such measuresis listed in Table II.A detailed description of the testbed used to setupall the nodes, execute the workload, inject the selecteddisturbances, and monitor the system to obtainthe required measurements, may be found at[12].TABLE IISelected measuresPerformance DescriptionPacket loss Avg. % of packets that were lost in a communicationroute. The lower the better.(%)Delay (ms) Avg. time required by a packet to traverse a communicationroute from the source to the destinationnode. The lower the better.resilience DescriptionAvailability(%)Avg. % of time the communication route establishedbetween sender and receiver is ready to beused. The higher the better.Integrity (%) Avg. % of packets whose content has not beenunexpectedly modified. The higher the better.Consumption DescriptionEnergy (J) Avg. energy consumed by a node’s Network InterfaceCard which takes part in a communicationroute. The lower the better.B.2 Fine-grained Experimental ResultsTable III shows the results obtained from experimentation.However, estimating and comparing theimpact of the selected faults on each single measureis a complex task given the lack of criteria to determinethe thresholds which separate the correctfrom the incorrect behaviour of the network in termsof the stated measures. Additionally, it is worthnoting that measures cannot be independently analysed,since this could lead the evaluator to misleadingconclusions, e.g., although some faults like ambientnoise, and selective forwarding attack may benefitnodes by reducing its energy consumption, thiscannot be really considered a benefit for the network,as such faults affect the final service provided to theuser. This fact may favour that the more measureswe consider, the more difficult to obtain an accurateglobal vision of the fault impact on the protocol.TABLE IIIMeasures obtained during experimentationPacket Delay Availabi- Integrity EnergyTarget Fault loss (%) (ms) lity (%) (%) (J)A 27.4 48.2 73.6 100.0 8.2S 39.5 42.0 91.2 100.0 8.0v.0.4.10J 7.6 1086.5 88.7 100.0 10.3T 8.2 39.7 93.1 5.2 10.6F 25.5 62.9 72.1 100.0 15.4A 27.3 55.6 73.4 100.0 8.2S 51.8 55.1 88.6 100.0 7.3v.0.5.6J 9.8 1111.3 88.7 100.0 10.5T 9.9 39.9 90.5 7.7 10.5F 27.1 64.5 71.9 100.0 14.9A 27.1 52.3 72.9 100.0 8.1S 54.1 53.4 89.5 100.0 6.8v.0.6.0J 8.7 1178.8 89.5 100.0 10.9T 9.4 56.5 91.4 7.5 10.6F 26.6 66.6 71.5 100.0 14.6B.3 Definition of the Criterion FunctionsIn order to simplify the application of LSP in ourcase study we have considered two generic continuouscriterion functions, one increasing (see Figure4), to compute the elementary score of the-higherthe-bettermeasures such as availability and integrity,and one decreasing (see Figure 5), to compute thelower-the-bettermeasures such as packet loss, delayand energy consumption.Fig. 4.Fig. 5.s i = c i (a i ) =0,a i X minX max Xi min i100 i , X min ”100,≤Xa i min ia< i i ” X maxia i≥ X max iIncreasing criterion function used in the case studys i = c i (a i ) =100, a i≤X min iX max a100 i i,X max XX min ” a< i ” X maxmin i iii0,a i≥ X max iDecreasing criterion function used in the case studyThese functions are parameterised according tothe bounds (X min and X max ) that delimit the qualitythreshold for a given attribute. The increasingcriterion function applies to those measures whosequality increases as their value does. In such function,X min establishes a threshold below which thevalue of the measure is of 0% of quality, while X maxdefines the threshold from which that value is of100% of quality. The reverse interpretation appliesto the decreasing criterion function.In order to determine the aforementioned thresholds,the evaluator should consider all the networka 1 (Packet loss) ≥100.50* s 1 c1≤45a 2 (Delay)s o 2 1c2≥40≤4000.50*a 3(Availability)≥550.50* s 3 c3 o≤903 S0.45* sa 4 s 4o 3 , 4 (Resilience)(Integrity) ≥950.50* 2≤99c4a 5 s c5 50.45*(Energy)≥110.10*≤15Fig. 6.s 1 , 2(Performance)(Consumption)Aggregation processComplete LSP model applied in our case studyJP2011-376

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011requirements for an acceptable quality of communications,addressing aspects like the number of users,the communication technology, the context of useand the type of service delivered. Depending onsuch aspects, the measures obtained may be interpretedin one way or another. For example, let usconsider the requirements defined in [13] for a votingapplication addressed to enable lecturers to getfeedback from audience in auditoriums or conventioncentres. Regarding the performance constraintsprovided by authors, a packet loss lower than 10%(X min = 10%) would represent an excellent qualitywhereas a packet loss of 45% (X max = 45%)would be in the bounds for an acceptable communication.In the case of delay, the common limitsof a medium quality communication [14] range from40ms to 400ms (X min = 40ms and X max = 400msrespectively). As far as measuring availability, integrityand energy consumption was not a requirementin [14], such thresholds are estimated by theauthors of this paper. Let us consider an acceptableavailability between X min = 75% and X max = 90%(“one nine”) where a downtime of 100 millisecondsper second is good enough for the type of applicationconsidered. Concerning the data integrity, adata corruption affecting more than 1% of packetscan compromise the trustworthiness of a voting application.Accordingly, the thresholds were fixed toX min = 99% and X max = 100%. Finally, regardingthe energy consumption, a previous fault-free experimentationshowed a stationary consumption of10J. In order to compute the thresholds, we assignedthis value to the minimum threshold (X min = 10J)and considered that an increase of 50% would beenough in our case to compute the maximum threshold(X max = 15J). Table IV summarises thesethresholds.TABLE VResults obtained from applying LSP techniqueTarget F ault Performance Resilience Consumptionv.0.4.10v.0.5.6v.0.6.0Globalscore perfaultA 71.73 73.85 100.00 75.23S 43.75 100.00 100.00 70.46J 7.15 100.00 100.00 37.85T 99.49 7.15 100.00 37.73F 72.11 71.08 0.00 47.91A 70.28 73.49 100.00 74.38S 6.81 97.98 100.00 36.89J 7.15 98.13 100.00 37.44T 98.42 7.15 100.00 37.50F 69.44 70.70 2.50 55.71A 71.21 72.57 100.00 74.40S 6.88 99.28 100.00 37.28J 7.15 99.28 100.00 37.69T 97.69 7.15 100.00 37.34F 70.51 69.94 10.00 60.09the characteristics considered in our case study, wehave determined that all of them should be compliantto the thresholds defined. One of the functionswhich fits the best with this requirement is the weakquasi-conjunction (denoted as C− according to theLSP notation), represented by r = 0.261 for two inputs.This operator denotes 60% of mandatorinesswithin the operators scale proposed by Djumović.C. Hierarchical Analysis of ResultsThe multiple intermediate results obtained whenapplying the LSP technique enable to systematisethe analysis of the benchmarking results at differentlevels. Table V lists the scores that represent thequantitative quality, globally and for each selectedcharacteristic, of the considered protocol versions inpresence of representative faults.C.1 Analysis per global qualityAccording to these results, the best candidateto be integrated into the final deployment is olsrdv.0.4.10, as it maximises the global score (51.81%),whereas the other two versions present similar(lower) results, 46.62% and 47.47% respectively.C.2 Analysis per characteristicAlternatively, evaluators may be interested in justfocusing on one particular characteristic to evaluatethe quality of the protocols and, in that case, olsrdv.0.4.10 obtains the best scores for performance(46.24%), olsrd v.0.6.0 is the best option with respectto consumption (66.43%) and there is a tripledraw (around 32%) for resilience.C.3 Analysis per fault typeIf we focused on the behaviour of each protocolin presence of a particular fault, olsrd v.0.4.10 isstill the best option when dealing with ambient noise,and selective forward attacks, but versions 0.5.6 and0.6.0 (in no particular order) take the lead when subjectedto tampering attacks. Regarding the impactof flooding attacks, version 0.6.0 presented the bestresults. Jellyfish attacks impact all the consideredprotocols in the same way and no one could be takenas the best option to face that particular fault.Globalscore51.8146.6247.47TABLE IVExperimental quality thresholds considered in theelementary criterion functionsMeasureCriterion X min X maxfunctionPacket loss (a 1) Decreasing 10% 45%Delay (a 2) Decreasing 40ms 400msAvailability (a 3) Increasing 75% 90%Integrity (a 4) Increasing 99% 100%Energy consumption (a 5) Decreasing 10J 15JB.4 Aggregation of PreferencesIn order to simplify our case study, all the attributes(a i ) have been considered equally significant,thus performing a fair assignment of weights. However, as far as a low consumption is not usuallya mandatory requirement in fixed networks suchas WMNs, we have reduced its weight (0.1 out of 1)with respect to performance (0.45 out of 1) and resilience(0.45 out of 1), which are more important inthis case. If we had considered e.g., a WSN, wherethe reduction of battery consumption is a must, thenthe weight assigned would be much more significant.Regarding the aggregation relationship betweenJP2011-377

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011C.4 SummaryFollowing this analysis, the quality of olsrd v.0.5.6and v.0.6.0 do not really differ in presence of the consideredfaults, and they could be used indistinctlybut when the network is perturbed by flooding attacksor consumption is the main concerns of theevaluator, where v.0.6.0 reacts better. Otherwise,olsrd v.0.4.10 is the best candidate to meet the requirementsestablished for this case study.V. ConclusionsTraditional analysis of results performed duringthe resilience benchmarking of components and systemscan be feasible for those cases where a reducedset of measures is considered. However, as far asthe amount of measures increases, the analysis complexityrises as well. This is an important issue thatcan compromise the analysis thoroughness, despitethe rest of the benchmark process has been correctlycarried out.This paper describes a practical approach to systematisethe analysis of resilience benchmarkingwith a well-known technique in the domain of softwareengineering: the Logic Score of Preferences(LSP). Conversely to other measures-aggregationtechniques, LSP plays an active role during thebenchmark definition. It addresses how to adequatelyselect and gather the types of measures torepresent the system, thus assisting the benchmarkuser to minimise errors during the results interpretation.In this line of reasoning, the case study selectedto illustrate the applicability of this technique hasbeen been focused on the promising domain of adhoc networks, allowing the reader to understand thatthe steps described in the paper can be designed tofit different applications. The LSP technique resultsa very useful approach to overcome the problem ofmeasures scalability and eases a more concise visionof the system. Nevertheless, regarding previous results,the application of this technique requires theadequate definition of the quality thresholds (X minand X max ) for each criterion functions, the weight(w i ) assigned to each score within the same aggregationblock, and the operator type (o i ) in charge of themeasures aggregation. All these aspects highly dependon the applicative context the ad hoc networksis conceived to be deployed.Considering the points previously detailed is a firststep towards the characterisation of the wide amountof applicative domains ad hoc networks are presentin, such as Wireless/Underground and SubaquaticSensor Networks, Wireless Mesh Networks and Mobileand Vehicular Ad hoc Networks, among others.We argue that this type of approaches can be usefulnot only to quantify the impact of faults with respectto the actual application context (where componentsand systems are planned to be deployed),but for the comparison and selection of those targetswhich best fit the system requirements. In the futurework, we ambition to provide evaluators differenttemplates with precomputed parameters that theycould customise for their particular deployments tosemi-automate the application of LSP for the quantitativebenchmarking of ad hoc routing protocols.AcknowledgementsThis work has been funded by the Spanish Ministryof Science and Innovation through the SEMSE-CAP Project (TIN-2009-13825).References[1] Karama Kanoun and Lisa Spainhower, DependabilityBenchmarking for Computer Systems, Wiley and IEEEComputer Society Press, 2008.[2] Hung-Chin Jang, Yao-Nan Lien, and Tzu-Chieh Tsai,“Rescue information system for earthquake disastersbased on manet emergency communication platform,” inInternational Conference on Wireless Communicationsand Mobile Computing (IWCMC), 2009, pp. 623–627.[3] P. Serrano et al., “A CARMEN mesh experience: deploymentand results,” in 10th IEEE WoWMoM, 2009,pp. 1–8.[4] Jesus Friginal, David de Andres, Juan-Carlos Ruiz, andPedro Gil, “On selecting representative faultloads toguide the evaluation of ad hoc networks,” in FifthLatin American Symposium on Dependable Computing(LADC), 2011.[5] J.J. Dujmovic and R. Elnicki, A DMS Cost/Benefit DecisionModel: Mathematical Models for Data ManagementSystem Evaluation, Comparison, and Selection, NationalBureau of Standards, Washington D.C., No. GCR 82-374.NTIS No. PB 82-170150, 1982.[6] M. F. Morris, “Kiviat graphs: conventions and figures ofmerit.,” ACM/Sigmetrics Performance Evaluation Review,vol. 3, no. 3, pp. 2–8, 1974.[7] David de Andres, “Using dependability, performance,area and energy consumption experimental measures tobenchmark ip cores,” in Forth Latin American Symposiumon Dependable Computing (LADC), 2009.[8] Giulio Concas, Michele Marchesi, Sandro Pinna, andNicola Serra, “Power-laws in a large object-oriented softwaresystem,” IEEE Trans. Softw. Eng., vol. 33, pp.687–708, October 2007.[9] Yazeed A. Al-Sbou, Reza Saatchi, Samir Al-Khayatt,Rebecca Strachan, Moussa Ayyash, and MohammadSaraireh, “A novel quality of service assessment of multimediatraffic over wireless ad hoc networks,” in Proceedingsof the 2008 The Second International Conferenceon Next Generation Mobile Applications, Services, andTechnologies, 2008, pp. 479–484.[10] I. F. Akyildiz and others, “Wireless mesh networks: asurvey,” IEEE Radio Communications, vol. 43, pp. S23–S30, 2005.[11] “Hillsdale WMN,” Online: http://dashboard.openmesh.com/overview2.php?id=Hillsdale,2010.[12] David Andrés, Jesús Friginal, Juan-Carlos Ruiz, andPedro Gil, “An attack injection approach to evaluatethe robustness of ad hoc networks,” in IEEE PacificRim International Symposium on Dependable Computing(PRDC), 2009, pp. 228–233.[13] Jasmeet Chhabra et al., “Real-world experiences withan interactive ad hoc sensor network,” in Proceedings ofthe 2002 International Conference on Parallel ProcessingWorkshops, 2002, pp. 143–151.[14] Weiquan Lu, Winston K. G. Seah, Edwin W. C. Peh,and Yu Ge, “Communications support for disaster recoveryoperations using hybrid mobile ad-hoc networks,”in Proceedings of the 32nd IEEE Conference on LocalComputer Networks, 2007, pp. 763–770.JP2011-378

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Protocolo para entrega able de contenidos enredes inalámbricas basado en codicaciónRaptorMiguel Báguena, Carlos T. Calafate, Juan-Carlos Cano, Pietro Manzoni 1Resumen De sobra son conocidos los problemas alos que se tienen que enfrentar los protocolos de comunicaciónen las redes inalámbricas: pérdida de paquetes,mayores retardos, entrega de los paquetes fuera deorden, etc. También es de dominio público las dicultadesque tiene TCP para hacer frente a este tipo deproblemas. Para evitar estos inconvenientes muchosautores han propuesto diversos protocolos basados entécnicas de corrección de errores, como puede ser lacorrección de errores hacia delante (Forward Errorcorrection - FEC), pudiendo recuperar la informacióntransmitida incluso en condiciones de pérdida masivade paquetes. En este trabajo se propone un protocolode comunicación que usa una codicación basadaen códigos Raptor a nivel de aplicación junto con uncontrol de ujo extremo-a-extremo para conseguir unprotocolo inmune a los efectos derivados del uso deun control de ujo basado en ventana deslizante enentornos inalámbricos. El protocolo propuesto se havalidado con un conjunto de pruebas estándar que demuestranla eciencia del protocolo en este tipo deentornos.Palabras clave: redes inalámbricas; códigos Raptor;evaluación del rendimiento.I. IntroducciónLAS tecnologías inalámbricas se están convirtiendoen las grandes protagonistas en el área delas comunicaciones actuales. Esto es debido al grannúmero de ventajas que las comunicaciones inalámbricasofrecen al usuario, como pueden ser una completamovilidad o una ubicuidad de conexión, entreotros. Sin embargo, este nuevo entorno ofreceunas características propias a las que las solucionespropuestas deben adaptarse para conseguir sacarle elmáximo partido. Estas características son una menorcapacidad del canal, un mayor retardo en la entregade paquetes y, en especial, una mayor tasa de pérdidade paquetes durante las transmisiones.La pérdida de paquetes es una característica claveya que inuye especialmente en el rendimiento delprotocolo TCP, que está siendo utilizado actualmentecomo protocolo de transporte en las comunicacionesinalámbricas. Se ha comprobado que laspérdidas normales producidas en el canal pueden serconfundidas con un síntoma de congestión, lo que reducela productividad alcanzada por TCP. Por eso sehan realizado muchos esfuerzos que intentan resolverlos problemas que la pérdida de paquetes ocasionaa las comunicaciones actuales, destacándose dos estrategiasprincipales.1 Departamento de Ingeniería de Sistemas y Computadores,Universitat Politècnica de València, Camino de VeraS/N, 46022, España, mibaal@upvnet.upv.es, {calafate, jucano,pmanzoni}@disca.upv.esLa primera de las estrategias utilizadas para resolverel problema de la pérdida de paquetes es eluso de técnicas de retransmisión. Sin embargo, se hacomprobado que la retransmisión provoca problemasde escalabilidad derivados de los retardos producidospor las retransmisiones. La segunda de estas estrategias,que es la utiliza el trabajo que presentamos, esel uso de técnicas de corrección de errores.El uso de técnicas de corrección de errores en lugarde técnicas de retransmisión nos permite establecerun canal tolerante a pérdidas, con lo que se puede resolverel problema de la pérdida de paquetes evitandola baja escalabilidad de las técnicas de retransmisión.Además, usando técnicas AL-FEC (Application LayerForward Error Correction) podemos establecer elcanal tolerante a pérdidas a nivel de aplicación, ocultandola estrategia al resto de capas, como puedenser IP o transporte.En este trabajo se propone un novedoso sistema decomunicación basado en técnicas AL-FEC que ofreceuna transmisión de datos eciente sobre redes inalámbricas.Nuestra solución usa técnicas de extremoa-extremopara estimar el ancho de banda y establecerasí la tasa de transmisión. Además, evita la retransmisiónde paquetes haciendo uso de un sistemade corrección de errores FEC, los códigos Raptor [1],reconociendo bloques transmitidos correctamente enlugar de los paquetes individualmente, ahorrando asíretardos, esperas y ancho de banda en el canal de retorno.El documento se estructura de la siguiente manera:en la siguiente sección se señalan algunos de los trabajosque también han abordado este problema. Enla sección II se pasa a describir la tecnología Raptorusada en la codicación. La sección IV describe endetalle el protocolo presentado. El conjunto de pruebasrealizado y los resultados obtenidos se presentanen la sección V. Por último, la sección VI presentalas conclusiones del trabajo.II. Trabajos previosLa degradación de prestaciones de TCP sobre redesinalámbricas ha sido un tema estudiado en profundidady se han presentado diferentes propuestaspara intentar mejorar la productividad alcanzadaen este medio. Diferentes estudios [2], [3] realizanpropuestas orientadas a solucionar los problemasde transmisión sobre redes inalámbricas. Entreellas se pueden establecer cuatro grupos principales:soluciones a nivel de enlace, soluciones para la trans-JP2011-379

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011misión de datos sobre redes con una parte cableaday una parte inalambrica, soluciones que modican elprotocolo TCP y soluciones para redes ad-hoc.Dentro del primer grupo, la primera de las solucionesque encontramos es el protocolo AIRMAIL[4], que combina las retransmisiones y la correcciónde errores. También aparece el protocolo snoop [5],[6], que presenta un módulo que analizando la transmisiónes capaz de detectar pérdidas. Otra es Tulip[7], que acelera la retransmisión a nivel de MAC.Para terminar citaremos otras que proponen retrasarel envío de los reconocimiento duplicados [8] o un sistemade retransmisión able a nivel de enlace [9].En el segundo grupo es importante la parte de laspropuestas que afecta al tramo inalámbrico de la red.Por ejemplo, Mobile TCP [10] usa una estructura detres capas que encamina, reconecta y controla la tasade transmisión. Wireless-TCP [11] evita el uso deventanas como control de ujo. Además se han presentadosistemas que usan reconocimientos múltiples[12] que pueden ser completos o parciales.El tercer grupo incluye modicaciones al protocoloTCP. TCP SACK[13] informa de manera precisa alemisor de los paquetes perdidos. SMART [14] combinalas aproximaciones Go-back-n y Selective ACK.Fast Retransmission [15] se centra en las comunicacionesmóviles. TCP-Santa Cruz [16] calcula la congestióndel canal usando los tiempos de llegada yenvío de los paquetes. Además otras técnicas noticanexplicitamente la congestión [17] mediante el bitCE de la cabecera IP o usan tipos de paquetes ICMPadicionales [18] para reiniciar un temporizador o retransmitirun paquete.El último grupo se centra en las redes ad-hoc.TCP-F [19] usa los paquetes RFN y RNN para detenere iniciar la transmisión de paquetes perdidos.TCP ad-hoc [20] dene diferentes estados en el procesoemisor.Nuestra propuesta diere de las anteriores en queusa un sistema de codicación FEC, conocido comoRaptor Codes, a nivel de aplicación para enviar la informacióncodicada, de manera que esta pueda serrecuperada en el destino sin ningún problema aunquese pierdan paquetes. De esta forma no se necesitannodos intermedios en la comunicación, ni modicacionesen el Hardware, ni control de ujo basado enventanas y retransmisiones.III. Los códigos RaptorLos códigos Raptor son códigos de corrección deerrores hacia delante (Forward Error Correction) queoperan a nivel de aplicación y son capaces de recuperarla información transmitida incluso en el casode que se pierdan en parte los paquetes transmitidos.Para conseguir esto es necesario transmitir informaciónredundante tras el conjunto de información inicial.El sistema de codicación Raptor dene comobloque fuente cada una de las porciones de tamañoconstante en la que ha de dividirse la informacióninicial para su procesado. Este bloque de datos seFig. 1. Proceso de codicación Raptordivide para su codicación en símbolos fuente, queson paquetes más pequeños del bloque fuente. Comoilustra la gura 1, el proceso de codicación de lossímbolos se realiza en dos partes. Primero se realizauna pre-codicación para generar los símbolos precodicados.Para generar este primer resultado intermediose lleva a cabo un proceso que realiza unaserie de combinaciones lineales entre los símbolos. Enla segunda fase se lleva a cabo la codicación propiamentedicha, haciendo posible una generación bajodemanda de un ujo ilimitado de símbolos codicados,que serán usados para la recuperación de lainformación transmitida en destino.El proceso en la decodicación es el opuesto. Sevan almacenando los símbolos temporalmente hastaque se haya recibido el número necesario para llevara cabo la recuperación. Éstos se combinan para obtenernuevamente símbolos pre-codicados y, partiendode estos símbolos, se generan los símbolos fuente quese han transmitido. Que la recuperación de la informaciónse lleve a cabo correctamente depende de quese haya recibido una cantidad suciente de símbolos,independientemente de cuales sean estos símbolos, sison consecutivos o no, etc.A diferencia de la técnica de retransmisión, estatécnica necesita añadir símbolos codicados al envíode los datos. Esto nos obliga a enviar informaciónque no siempre es útil, por lo que la eciencia delsistema puede verse ligeramente reducida especialmenteen canales libres de errores. No obstante, eluso de códigos rateless o sin tasa ja de informaciónredundante, como son los códigos Raptor, reduce almínimo la necesidad de envío de esta información derecuperación. También es importante señalar que estaes una técnica que hace un uso intensivo de CPUy memoria. Por ello se ha hecho uso de un sistema decodicación sistemático. Este tipo de codicación secaracteriza por que los símbolos fuente son un subconjuntode los símbolos codicados, frente a los sistemasde codicación no sistemáticos que no tienenesta característica. Esto nos permite recuperar la informacióncon mucho menos esfuerzo en caso de queno se produzcan pérdidas en el canal.JP2011-380

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011En cuanto a la transmisión de cheros de datos,tanto a nivel cableado como inalámbrico, uno de losprotocolos más usados en la actualidad es el protocoloHTTP [21], protocolo que opera a nivel deaplicación. Este protocolo se combina con el protocoloTCP para ofrecer abilidad en la transmisión dedicha información. El problema en este sistema radicaen la incapacidad de TCP para distinguir entrepaquetes perdidos debidos a la congestión y paquetesperdidos debido a las características peculiaresde las redes inalámbricas, ocasionando una sensibledegradación de las prestaciones obtenidas. Debido aesto, se propone una solución alternativa a TCP parael transporte de los datos, sobre el que sería posibleimplementar cualquer protocolo para la transmisiónde cheros, incluido HTTP.Proponemos un nuevo protocolo basado en códigosRaptor. La idea del protocolo es usar técnicasAL-FEC que hagan uso de codicación Raptor sobreel protocolo UDP para establecer una conexióninmune a errores en un canal con pérdidas. Así, evitamostambién la necesidad de retransmisiones, pueslas características de los códigos Raptor nos permitengenerar un ujo de símbolos codicados, a partir delcual podemos recuperar los datos originales sin tenerque preocuparnos por los antiguos.Nuestro protocolo usa además un sistema de estimaciónde ancho de banda extremo-a-extremo paradeterminar el ancho de banda disponible en el canal.Esta estimación se obtiene midiendo el tiempo transcurridoentre la llegada de los paquetes y será remitidaal emisor para que éste ajuste su tasa de envíode paquetes a las condiciones detectadas en el canal.Para realizar la implementación de nuestra propuestase estableció un diseño en cuatro capas comomuestra la gura 2. La capa superior ofrece interfazcon la aplicación usando el esquema clásico desockets, la siguiente capa será la encargada de realizarla codicación, la tercera capa se encargará delcontrol de la tasa de transmisión y la última e inferiorserá la encargada de proporcionar al sistemauna abstracción del canal UDP facilitando así su implementación.Son la capa de codicación Raptor yla capa de control de la tasa de transmisión las queofrecen la mayor relevancia por ser las encargadasde realizar las tareas clave del protocolo. La capa decodicación Raptor ofrece inmunidad a pérdidas, yla capa que realiza control de la tasa de transmisiónaporta la capacidad de adaptarse a los cambios en elcanal.Los detalles del protocolo se describen a continuación.Fig. 2. Estructura en capas del protocolo basado en codicaciónRaptorIV. Un protocolo basado en codificaciónRaptorA. El proceso de codicación y decodicaciónEl proceso de codicación y decodicación se llevaa cabo en la segunda capa, la capa de codicaciónRaptor. Esta capa recibe la información a enviar dela capa de interfaz con la aplicación, realiza la codi-cación y distribuye los paquetes creados a las capasinferiores. Esta capa introduce una cabecera alpaquete con la información necesaria para realizarla decodicación en el otro extremo. Esta cabeceraconsta de cuatro enteros: el número de códigos fuenteen el mensaje original, el identicador del símboloenviado, el identicador del bloque y el tamaño delbloque a recuperar. Esta cabecera es añadida tantoa símbolos fuente como a los símbolos codicados.El proceso llevado a cabo por el emisor en esta capaes el siguiente: El emisor recibe la información atransmitir de la capa superior, divide la informaciónen bloques fuente y estos a su vez en los símbolosfuente. Estos símbolos son empaquetados junto conla cabecera y redirigidos a capas inferiores para suposterior envío. A continuación se comienza con elproceso de codicación propiamente dicho, en el quese van generando símbolos codicados hasta que serecibe por parte del cliente la noticación de que elbloque se ha recuperado correctamente. Una vez estanoticación se ha recibido, el proceso avanza al siguientebloque de información a transmitir y se repiteel proceso nuevamente.El proceso llevado a cabo por el receptor es distintoaunque complementario. El receptor está continuamenteesperando símbolos del emisor, almacenándolosen una memoria temporal. La librería de codicaciónnos permite detectar que el número de bloquesrecibidos es el suciente, momento en el que se iniciael proceso de decodicación. Una vez nalizadoéste, se notica al emisor la correcta decodicacióndel bloque que se estaba transmitiendo.B. Control de la tasa de transmisiónEn las redes inalámbricas, el ancho de banda delcanal, así como los niveles de congestión e incluso laruta seguida por los paquetes son parámetros dinámicosque varían dependiendo de diversos factores. Portanto, se debe usar una técnica de control de la tasade transmisión que se adapte rápidamente a los cambiosque puedan producirse en el canal.La técnica de control de la tasa de transmisión propuestase basa en estimaciones del ancho de bandarealizadas por el receptor durante el proceso de transmisión.Estas estimaciones son realizadas en base alJP2011-381

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011patrón de recepción de los paquetes y enviadas alemisor para que este ajuste la tasa de transmisión.Siguiendo la estrategia que propusimos en un trabajoprevio [22], los paquetes son enviados en ráfagasque superan la capacidad estimada para el canal.De esta forma, si el canal dispone de más ancho debanda del que en principio se estimó, los paquetes llegaránantes de lo esperado, detalle que será detectadopor el receptor que, siguiendo el protocolo, informaráal emisor del nuevo estado del canal. En cambio, siel canal está más congestionado en un determinadomomento, los paquetes llegarán más lentamente.Este hecho también será detectado por el receptorque instará al emisor a reducir su tasa de envío.La implementación del protocolo es la siguiente:el emisor recibe los informes de ancho de banda delreceptor (BW i ) y les aplica un factor de corrección(β), como se muestra en la ecuación 1, para obtenerla tasa objetivo T O i . El parámetro β varía entre 0y 1 y su propósito es reducir ligeramente la tasa detransmisión resultante para evitar saturar el canal,intentando ofrecer espacio al tráco best-eort. Latasa objetivo es la que esperamos medir en el ladodel receptor.Un segundo factor de corrección (α) es aplicado ala tasa objetivo para obtener la tasa de transmisiónde las ráfagas (T R i ), de acuerdo a la ecuación 2. Esteparámetro varía también entre 0 y 1. Esta tasa seráutilizada para ajustar la transmisión de las ráfagasde los paquetes.T O i = β × BW i (1)T R i = 1 α × T O i (2)Cuando una ráfaga es transmitida, se aplica unperiodo de inactividad calculado de manera que, demanera global, la tasa objetivo se mantenga. A nivelglobal obtenemos la tasa de transmisión TO mientrasque para paquetes consecutivos de una misma ráfagaobtendremos la tasa de transmisión TR.C. Detalles de implementaciónLa arquitectura que deseamos implementar hacenecesario un enfoque multihilo para conseguir unasolución eciente y robusta.Para acelerar el desarrollo del protocolo se ha usadocomo esqueleto la implementación de una libreríade comunicaciones, la librería UDT [23], desarrolladaen C++ con soporte para Linux, Solaris y Windows.La librería nos ofrece como apoyo las característicastípicas de las librerías de comunicación, como puedenser un interfaz de sockets o una abstracción del canal,y nos permite así concentrar todos los esfuerzos dedesarrollo en el núcleo de la propuesta.La implementación de Raptor utilizada en la actualversión del protocolo es la distribuida por la empresaDigital Fountain, Inc. 1 liberada bajo una licenciaacadémica, en su versión 11 para Linux. Esta libreríaofrece al programador el esquema clásico de las1 Licensed by Qualcomm Inc.librerías de codicación, permitiéndonos encapsularla funcionalidad de codicación y decodicación endos clases de C++ independientes - codicador y decodicador-, y abstrayendo la funcionalidad en unacapa independiente. Estas clases implementan cadauna el comportamiento de un thread independienteque realiza todo el proceso descrito en secciones anteriores.Es deseable señalar que todo este proceso se realizaa nivel de usuario, limitando la interacción con elkernel al envío de los paquetes UDP.V. Evaluación de la propuestaPara validar el protocolo propuesto, se ha realizadouna comparativa con la solución más ampliamenteutilizada en las redes de computadores para el envíode información, que consiste en una combinación deHTTP y TCP, bajo diferentes condiciones del canal.En ambos casos se ha utilizado un conjunto depruebas idéntico, estableciéndose las mismas condicionesde retardo, error y ancho de banda en elcanal. Como la implementación se ha realizado sobrela plataforma GNU/Linux, y para asegurar que laspruebas son reproducibles, se creó un entorno controladopara pruebas donde se emularon las diferentescondiciones del canal bajo las que se realizarían lasmismas. Este entorno es una caja negra que emulauna conexión de red punto-a-punto plenamente con-gurable. Los entornos emulados son los típicos delas redes inalámbricas en cuanto a pérdidas, retardoy ancho de banda.Para realizar la evaluación se implementó un servidorbajo demanda capaz de utilizar nuestra propuestao HTTP sobre TCP para distribuir información adiferentes clientes. Se ha creado un esquema híbridoque nos permite hacer uso del protocolo basado encodicación Raptor o de una conexión HTTP sobreTCP en función de lo que queramos evaluar. En laspruebas los clientes solicitan a sus correspondientesservidores un chero de gran tamaño y se calcula laproductividad en Mbps para cada uno de los escenarios.En relación a los parámetros α y β, sus valores seestablecieron en 0.5 para el primero de ellos (permitiendoadaptarse a uctuaciones rápidas del canal dehasta un 100 %) y en 0.9 para el segundo (reservandoun 10 % del ancho de banda para evitar saturar elcanal). El tamaño de bloque usado en la codicaciónfue de 10MB.La gura 3 muestra los resultados obtenidos cuandola tasa de error del canal varía de 0 a 10 %. En estejuego de experimentos el ancho de banda del canalse limitó a 2Mbps y el retardo se estableció en 10 ms.Como se puede observar, cuando la tasa de pérdidasdel canal es muy baja el protocolo basado en codicaciónRaptor alcanza únicamente una productividaddel 85 % del sistema basado en TCP. Esta diferenciaes debida a los retardos introducidos por el procesode codicación y decodicación del protocolo presentado,así como al hecho de que se reserva un 10 %del ancho de banda del canal mediante el parámetroβ. Sin embargo, cuando la tasa de error es superiorJP2011-382

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201121.75TCPCodificacion Raptor1816TCPCodificacion Raptor1.514Productividad (Mbit/s)1.2510.75Productividad (Mbit/s)1210860.540.25200 1 2 3 4 5 6 7 8 9 10Tasa de perdida de paquetes (%)00 5 10 15 20 25 30Ancho de banda disponible en el canal (Mbit/s)Fig. 3. Productividad alcanzada conforme varía la tasa deerror del canal.Fig. 5. Productividad alcanzada conforme varía el ancho debanda disponible.Productividad (Mbit/s)21.751.51.2510.750.50.25TCPCodificacion Raptor00 10 20 30 40 50 60 70 80 90 100Retardo (ms)Fig. 4. Productividad alcanzada conforme varía el retardo delcanal.al 4 %, el protocolo basado en codicación Raptorsupera en rendimiento a la solución tradicional. Enparticular, para una tasa de pérdidas de un 10 %, semejora a la implementación sobre TCP en un 122 %.Además, las prestaciones se mantienen mucho másestables en el protocolo propuesto, presentando unacaída de un 12 % cuando pasamos de un 0 % a un10 % de pérdidas frente al 71 % que ofrece la soluciónTCP.La gura 4 muestra los resultados obtenidos cuandose varía el retardo extremo-a-extremo de 0 a100ms, estableciendo una tasa de pérdidas de un 2 %y limitando el ancho de banda disponible a 2Mbps.Para retardos del canal muy bajos (menores de 20ms), la solución implementada sobre TCP se comportamejor que el protocolo basado en codicaciónRaptor debido a las consideraciones detalladas previamente.Sin embargo, para valores superiores a 20ms, se invierten los resultados hasta el punto deque la implementación basada en codicación Raptorofrece una mejora de un 64 %. También puede volvera destacarse la estabilidad de la solución basada encodicación Raptor, que arroja diferencias de un 8 %en el caso peor frente al 50 % de su competidora.La gura 5 muestra la productividad obtenidacuando variamos el ancho de banda disponible enel canal entre 0.5 y 30 Mbps. En este tercer conjuntode experimentos el retardo extremo-a-extremo seestableció en 10 ms y la tasa de pérdidas del canalen un 2 %. En la gura se observa como las pérdidasde paquetes y el retardo tienen un fuerte impactoen el rendimiento de la solución basada en TCP, impidiéndolesuperar el umbral de productividad de los5.44 Mbps. Por el contrario, la solución propuesta,basada en codicación Raptor, escala mucho mejorconforme mejoran las condiciones de ancho de bandadel canal, logrando mejoras signicativas cuando elancho de banda disponible va más allá de los 5 Mbps.En particular, en un canal con un ancho de bandade 30 Mbps, la mejora obtenida bajo las condicionesdenidas anteriormente es de un 207 %.Resumiendo, las pruebas realizadas muestran queambas soluciones presentan una degradación deprestaciones conforme las condiciones del canal empeoran.Sin embargo, la reducción de prestacionesque presenta la solución basada en codicación Raptores en todos los casos mucho menos pronunciadaque la que presenta la solución basada en TCP. Enparticular, la reducción de prestaciones que ofreceesta última puede considerarse excesiva cuando losvalores de retardo o de pérdida de prestaciones sonsignicativos. Estos resultados ponen en evidencia lafalta de efectividad de las implementaciones tradicionalesbasadas en TCP para operar en escenarioscon un alto nivel de pérdidas o con un alto retardo,características éstas propias de escenarios inalámbricos.Por el contrario, la solución basada en codicaciónRaptor mantiene la productividad en un nivelmucho más estable, haciéndose casi inmune a lapérdida de paquetes y mejorando claramente a lassoluciones tradicionales. Las diferencias entre ambasimplementaciones se hacen mucho más pronunciadascuando el canal supera los 5Mbps, poniendo de mani-esto la incapacidad del protocolo TCP para hacerun uso eciente del ancho de banda disponible encanales inalámbricos.VI. ConclusionesLa transmisión de datos en entornos inalámbricos,que típicamente presentan un alto nivel de pérdidade paquetes o de retardo, requieren de nuevas técnicasque sean capaces de mejorar las prestacionesJP2011-383

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011en este tipos de entornos. Los esquemas basados enFEC se han revelado como la solución más adecuadadada su capacidad para evitar las retransmisiones depaquetes perdidos.En este documento se propone un nuevo protocolobasado en una codicación Raptor que es capaz demejorar el rendimiento en la transmisión de cheros,especialmente en entornos con pronunciadas pérdidasde datos. Este protocolo consigue evitar las retransmisionesde paquetes aplicando técnicas FECen la capa de aplicación.Nuestra propuesta realiza un control de la tasa detransmisión basado en las estimaciones de ancho debanda realizadas por el proceso receptor. Nuestrasolución permite al protocolo adaptar rápidamentela tasa de transmisión a la congestión del canal y aotros factores que varian a lo largo del tiempo.La propuesta ha sido implementada sobre un sistemaGNU/Linux. Esta implementación a compararel rendimiento de este nuevo protocolo basado en codicaciónRaptor con la solución basada en el protocoloTCP bajo diferentes condiciones del canal, paralo que se diseñaron y realizaron una serie de experimentos.Los resultados ponen de maniesto la superioridadde la solución propuesta cuando se tratacon altos niveles de retardo y alta tasa de pérdidasen el canal, diferencias que se hacen especialmenteevidentes cuando el ancho de banda del canal se incrementapor encima de los 5 Mbps.AgradecimientosEste trabajo ha sido parcialmente nanciado porel Ministerio de Ciencia e Innovación, España, bajola subvencion TIN2008-06441-C02-01.Referencias[1] A. Shokrollahi, Raptor codes, Information Theory,IEEE Transactions on, vol. 52, no. 6, pp. 25512567,2006.[2] A. Natani, J. Jakilinki, M. Mohsin, and V. Sharma, TCPfor Wireless Networks, Project Report, Univ. of Texasat Dallas, USA, 2001.[3] K. Pentikousis, TCP in wired-cum-wireless environments,IEEE Communications Surveys, vol. 3, no. 4,pp. 214, 2000.[4] E. Ayanoglu, S. Paul, T.F. LaPorta, K.K. Sabnani, andR.D. Gitlin, AIRMAIL: A link-layer protocol for wirelessnetworks, Wireless Networks, vol. 1, no. 1, pp. 4760,1995.[5] H. Balakrishnan, S. Seshan, and R.H. Katz, Improvingreliable transport and hando performance in cellularwireless networks, Wireless Networks, vol. 1, no. 4, pp.469481, 1995.[6] S. Vangala and M.A. Labrador, Performance of TCPover wireless networks with the Snoop protocol, in CON-FERENCE ON LOCAL COMPUTER NETWORKS.Citeseer, 2002, vol. 27, pp. 600604.[7] C. Parsa, TULIP: A link-level protocol for improvingTCP over wireless links, in Wireless Communicationsand Networking Conference, 1999. WCNC. 1999 IEEE.IEEE, 2002, pp. 12531257.[8] M.N. Mehta and N.H. Vaidya, Delayed Duplicate-Acknowledgments: A Proposal to Improve Performanceof TCP on Wireless Links, Tech. Rep., Citeseer, 1998.[9] Z. Jing and N. Zhisheng, A reliable TCP-aware link layerretransmission for wireless networks, in CommunicationTechnology Proceedings, 2000. WCC-ICCT 2000. InternationalConference on. IEEE, 2002, vol. 1, pp. 900905.[10] K. Brown and S. Singh, M-TCP: TCP for mobile cellularnetworks, ACM SIGCOMM Computer CommunicationReview, vol. 27, no. 5, pp. 1943, 1997.[11] P. Sinha, T. Nandagopal, N. Venkitaraman, R. Sivakumar,and V. Bharghavan, WTCP: A reliable transportprotocol for wireless wide-area networks, Wireless Networks,vol. 8, no. 2/3, pp. 301316, 2002.[12] S. Biaz, M. Mehta, S. West, and N.H. Vaidya, TCP overwireless networks using multiple acknowledgements,Texas A&M University, Technical Report 97, vol. 1, pp.97001.[13] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow,RFC2018: TCP Selective Acknowledgement Options,RFC Editor United States, 1996.[14] S. Keshav and SP Morgan, SMART retransmission:Performance with overload and random losses, in IN-FOCOM'97. Sixteenth Annual Joint Conference of theIEEE Computer and Communications Societies. ProceedingsIEEE. IEEE, 2002, vol. 3, pp. 11311138.[15] R. Caceres and L. Iftode, Improving the performanceof reliable transport protocols in mobile computing environments,Selected Areas in Communications, IEEEJournal on, vol. 13, no. 5, pp. 850857, 2002.[16] C. Parsa, Improving TCP congestion control over internetswith heterogeneous transmission media, in NetworkProtocols, 1999.(ICNP'99) Proceedings. Seventh InternationalConference on. IEEE, 2002, pp. 213221.[17] R. Ramani and A. Karandikar, Explicit congestion noti-cation (ECN) in TCP over wireless network, in PersonalWireless Communications, 2000 IEEE InternationalConference on. IEEE, 2002, pp. 495499.[18] S. Goel and D. Sanghi, Improving TCP performanceover wireless links, in TENCON'98. 1998 IEEE Region10 International Conference on Global Connectivity inEnergy, Computer, Communication and Control. IEEE,2002, vol. 2, pp. 332335.[19] K. Chandran, S. Ragbunathan, S. Venkatesan, andR. Prakash, A feedback based scheme for improvingTCP performance in ad-hoc wireless networks, in DistributedComputing Systems, 1998. Proceedings. 18th InternationalConference on. IEEE, 2002, pp. 472479.[20] J. Liu and S. Singh, ATCP: TCP for mobile ad hoc networks,Selected Areas in Communications, IEEE Journalon, vol. 19, no. 7, pp. 13001315, 2002.[21] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,P. Leach, and T. Berners-Lee, Hypertext TransferProtocol HTTP/1.1, RFC 2616, June 1999.[22] Carlos T. Calafate, Pietro Manzoni, and Manuel P.Malumbres, Supporting soft real-time services inMANETs using distributed admission control and IEEE802.11e technology, in The 10th IEEE Symposium onComputers and Communications, La Manga del MarMenor, Cartagena, Spain, June 2005.[23] Y. Gu and R.L. Grossman, Supporting congurable congestioncontrol in data transport services, in Proceedingsof the 2005 ACM/IEEE conference on Supercomputing.2005, IEEE Computer Society.JP2011-384

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evaluating video streaming performance inMANETs using a testbedTim Bohrloch † , Carlos T. Calafate ‡ , Alvaro Torres ‡ , Juan-Carlos Cano ‡ , Pietro Manzoni ‡1Abstract— The complexity of evaluating video deliverystrategies in mobile ad-hoc networks (MANETs)has led most researchers to rely on simulation experimentsalone. However, in most cases, simulationsfail to replicate realistic conditions, and so the resultsobtained and the conclusions drawn from such resultsare not accurate. In this paper we describe a methodologythat allows evaluating the effectiveness of videocodecs in MANETs. Our methodology is based on awell-defined video quality evaluation framework thatconsiders different video codecs and transmission environments.We validate our methodology by comparingthe H.264/AVC and the MPEG-4/ASP videocodecs, showing that, in general, the former outperformsthe later in terms of video quality. For veryhigh loss rates, though, the differences between bothbecome minimal. We also show that the number ofhops between video transmitter and receiver is a decisivefactor affecting performance when the channelexperiences congestion. Moreover, in mobile scenarios,we find that the impact of congestion and routingdelay affects video streaming quality in different manners:while congestion is mainly responsible for randomlosses, routing delay is usually associated withlong loss bursts.Keywords— Video streaming; MANET; QoS;testbed; H.264 / AVC; MPEG-4 / ASP; ad-hocI. IntroductionVIDEO streaming in mobile ad-hoc networks(MANETs) is considered one of the most challengingresearch goals due to the combined effects ofwireless communications characteristics (multipathfading and shadowing, interferences, collisions, etc.)and topology maintenance in the presence of nodemobility, all of which negatively affect on-going videosessions. In particular, topology changes provokeintermittent connectivity, causing large packet lossbursts. Thus, assessing the effectiveness of videotransmission systems in ad-hoc networks is a relevantissue. In the past, most works addressing this issuehave resorted to simulation due to the complexity ofdeploying real testbeds. However, this approach doesnot allow for a thorough validation since results tendto be too optimistic. Additionally, the few works describingreal testbed experiments do not deal withthe IEEE 802.11e technology, which impedes offeringQoS support to video streams.In this work we introduce a methodology basedon emulation that allows evaluating video streamingperformance in real, 802.11e-based MANETs. Theproposed methodology relies on a video quality evaluationframework to assess the effectiveness of differentvideo codecs when transmitted over IP net-1† HfT Leipzig, Germanye-mail: Tim.Bohrloch@gmx.net‡ Universitat Politècnica de València, Spaine-mail: calafate@disca.upv.es, atcortes@batousay.com,{jucano, pmanzoni}@disca.upv.esworks. When focusing on MANET scenarios, wepropose performing an initial evaluation using a controlledpoint-to-point wireless channel to have a clearoverview of the video codec’s error resilience performance.Afterward, static multi-hop communicationscenarios are used to determine of impact of factorssuch as congestion and hop count on performance.Finally, we introduce mobile multi-hop communications,typical of MANET environments, to study theeffects of topology updating delays on the video qualityperceived by the user.To validate our methodology we assess the effectivenessof two well-known video coding standards -H.264/AVC [1] and MPEG-4 Part 2 [2] - followingthe proposed procedure. Experimental results showthat the H.264/AVC codec offers higher video qualityand, more important, they evidence how the differentsources of video data losses in MANETs impactthe video decoding process.This paper is organized as follows: in section IIwe present some related works, evidencing how ourwork differs from previous ones. In section III weintroduce the proposed video evaluation methodology.Section IV describes the video sequences usedfor testing, along with the experimental results obtainedin an emulated point-to-point channel whenvarying the loss rate. The results obtained in ourad-hoc network testbed are then presented in sectionV, comprising both static and mobile scenarios.Finally, section VI presents the main conclusions ofthis paper.II. Related worksIn the literature we can find works addressingvideo streaming performance in MANETs from differentperspectives.Schierl et al. [3] presented a scheme based on RaptorFEC that uses different sources for reliable mediastreaming in MANET scenarios with high route lossprobability. Their evaluation is based on ns-2 simulation.Sheltami [4] evaluates the performance of H.264protocol using two routing protocols: the Neighbor-Aware Clusterhead (NAC) and the Dynamic SourceRouting (DSR) protocols. The author shows thatit is feasible to have video over MANETs within anaverage distance of 6 hops, and requiring 5.5 Mbpson average.Calafate et al. [5] propose a QoS frameworkfor MANETs combining IEEE 802.11e technology, amultipath routing algorithm, and a distributed admissioncontrol algorithm. Their solution was testedvia simulation, and Peak Signal-to-Noise Ratio re-JP2011-385

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Steps involved in obtaining video quality indexes forvideo streaming environments.sults were obtained under different network congestionconditions.More recently, Lee and Song [6] propose an effectivecross layer optimized video streaming algorithmover multi-hop mobile ad hoc networks. Their algorithmattempts to satisfy an end-to-end delay constraint,while maintaining packet loss rate within atolerable range at the receiver.Despite the aforementioned works address problemssimilar to those we focus on this work, our proposaldiffers from previous ones by providing: (i) anIEEE 802.11e enabled MANET testbed, while mostproposals are simulation based, and the real testbedsdeployed (e.g. [7]) lack any QoS support at the MAClayer; (ii) a methodology for assessing video streamingeffectiveness in MANET environments based onemulation.III. Our proposed video evaluationmethodologyIn this section we introduce our methodology toevaluate video streaming effectiveness in MANETswhen relying on different video codecs, and underdifferent network conditions. We first describe thevideo quality measurement framework adopted, includingthe different target video quality metrics.Based on this framework, we then propose differenttransmission environments over which performanceis assessed. In particular, preliminary evaluationsare made using an emulated point-to-point wirelesschannel; the goal is to have a clear characterizationof the video codec’s behavior under different loss conditions.These preliminary evaluations are followedby tests in a real wireless ad-hoc network testbed,both static and mobile, to evaluate the impact ofcongestion, hop count and mobility on performance.A. Video quality measurement frameworkMeasuring the quality of a transmitted video is aprocess that involves several steps. In particular, retrievingvideo quality indexes usually requires doinga frame-by-frame comparison of the original videoagainst the received video, both in the raw format.Figure 1 presents the steps involved in obtainingvideo quality indexes for a specific combinationof video encoder/decoder and transmission channel.The original video is a raw video sequence, typicallyin the YUV 4:2:0 format. The encoding process relieson one of the available video codecs for datacompression prior to transmission. Notice that, toenable a fair performance comparison between differentvideo codecs, it is very important to performdatarate control to get the same target bitrate fortransmission. Otherwise, any qualitative comparisonwould be deemed unfair.For the transmission process, we propose connectinga VLC [8] client to a VLC server through an IPnetwork, since this tool is compatible with a widevariety of formats and video codecs. For the decodingprocess, we can use a tool such as Mencoder [9]to obtain a raw video sequence in the YUV 4:2:0format. In addition, and to account for lost framesin the transmission process, frame freezing is performed.The latter is the process through which asame frame is replicated to fill-in for missing frames,thereby generating a raw video sequence with thesame length as the original one. This is a strict requirementto obtain a meaningful output from thequality measurement process.To determine the impact of the different transmissionimpairments on the quality of streamed videosequences as experienced by the receiver, we haverelied on different metrics. In particular, the metricswe considered were: (i) Peak Signal-to-Noise Ratio(PSNR), (ii) Packet loss ratio, and (iii) Framelosses. According to different authors [7], [10], thisset of metrics is quite adequate in the context ofvideo transmission over lossy IP networks since theyassess video quality from different perspectives. Inparticular, the last two metrics are more appropriateto discriminate between different video transmissionimpairments when losses grow above the 15-20%threshold. Notice that all other video-specific metrics,both objective and subjective, usually fail todifferentiate between different scenarios when transmissionconditions become very poor, experiencinga saturation effect at the lower edge of the metrics’range.In the following sections we describe the differentnetworks introduced in the Transmission processstep according to the proposed evaluation methodology.B. Point-to-point wireless channel emulationOur experiments were made with real workingsoftware for both GNU/Linux and Windows platforms.To make sure that the test sequences wererepeatable and reproducible, we created a controlledtest environment where we emulated different channelconditions. With this purpose, we interconnectedtwo computers using Fast Ethernet, and, using theGNU/Linux traffic control tool (tc), we set the channeldelay and the packet loss ratio. This way, we wereable to emulate different channel conditions to assessthe impact on performance at the application layer.In this process, it is important to highlight that thepacket loss events introduced were completely random,meaning that no loss burst effects were present.In contrast, the wireless ad-hoc network environmentsthat we describe below will mostly introducebursty losses.JP2011-386

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011C. Wireless ad-hoc network testbedTesting video transmission in a real wireless adhocnetwork testbed is a complex task. In fact, themere setup process of such a testbed requires configuringnodes to share the same IEEE 802.11 parameters,as well as being within the same IP network,and running a same routing protocol in casemobility is introduced. Additionally, relying on usersto move mobile terminals around makes the processambiguous by impeding repeatability and strict controlof experiments. Instead, we propose using on theCastadiva tool [11] to setup both static and mobilescenarios in a seamless and straightforward manner,while providing experiment repeatability. Through agraphical user interface, Castadiva allows setting upany static or mobile scenario, defining both the layer2 and layer 3 setup for nodes, providing start/stoptraffic control, and gathering experimental results atthe end.IV. Performance evaluation in lossywireless channelsFollowing the proposed methodology, in this sectionwe proceed with the first set of experimentswhere we assess video streaming performance in apoint-to-point wireless channel under different lossconditions. We first introduce the two video sequencesused as input for our tests, and then presentexperimental results when transmitting in an emulatedwireless channel.A. Selected video codecs and sequencesFor our experiments we used two different videosequences with different characteristics (see table I).The first video sequence, taken from the “Die hard 4”movie, is an action sequence with a very high degreeof motion and many scene changes, being particularlydemanding for video codecs. The second videosequence, taken from the “Sunshine” movie trailer,has less motion and less scene changes, but it has ahigher resolution compared to the first one (720p vs576p). Instead of the standard VQEG [12] video sequences1 , we opted for the aforementioned sequencessince they introduce more scene changes than the latterones. Notice that scene changes cause bandwidthpeaks, which are desirable for our study in order tostress the network.The two video sequences are encoded using boththe H.264/AVC and the MPEG-4 video codecs. Inparticular, we relied on the “XMedia Recode” tool[13] for the video encoding task.B. Experimental resultsIn this first set of experiments the goal was tocompare the error resilience of both video codecs underanalysis when facing different channel conditions.With this purpose we relied on our point-to-pointchannel emulator to introduce a variable loss rate1 Available at: ftp://ftp.crc.ca/crc/vqeg/between video sender and receiver, while setting delayto 10 ms. In our experiments we used both theH.264/AVC and the MPEG-4/ASP (Advanced SimpleProfile) video codecs, setting the target data rateof both video sequences to 900 kbit/s. We variedthe packet loss rate between 0,1% and 10%, sincethis range is deemed adequate by most authors [10]when performing video quality assessment. For eachcombination of video sequence, codec and packet lossrate, we repeated the experiment 10 times. In thecharts that follow, each point represents the meanvalue of these 10 experiments.Figure 2 shows the PSNR results obtained for bothvideo sequences using the two different video codecs.Concerning video sequence #1 (see Figure 2, left), wefound that the H.264/AVC codec achieves an incrementof 2 dBs, on average, compared to the MPEG-4/ASP video codec. With respect to video sequence#2, we find that the differences between both codecs,although initially high (5.9 dB), become negligiblefor packet loss rates above 2%. Compared to videosequence #1, this effect only occurred for a packetloss rate of 10%. Also, we find that the PSNR valuesfor video sequence #2 experience a faster degradationcompared to the first one, and that PSNR valuesat 10% loss are up to 5 dB lower, approaching noiselevels (20 dB threshold).Concerning frame losses, figure 3 shows the impactof packet loss on the frame loss ratio. We cansee that there is some relationship between packetlosses and frame losses. We also find that both videocodecs follow a similar trend, although, for the firstvideo sequence, the MPEG-4/ASP codec performsquite poorly, with a frame loss ratio of 12% when thepacket loss ratio is of 10%. The H.264/AVC codecoffers more consistent operation, achieving a maximumframe loss ratio of 8%, and always maintainingthe frame loss ratio below the packet loss ratio. Thisis the expected behavior, and clearly evidences thesuperior error resilience offered by the H.264/AVCcodec.Overall we find that, although the H.264/AVCcodec is expected to offer a much better performancecompared to its predecessor (MPEG-4/ASP),the PSNR difference becomes somehow attenuatedwhen the packet loss ratio becomes too high. Wealso find that the impact of packet loss on frame lossratio is maintained consistent for H.264/AVC, whileMPEG-4/ASP improved its behavior with a highervideo resolution sequence (#2).V. Performance evaluation in a realwireless ad-hoc network testbedEndowed with the knowledge acquired in the experimentsof the previous section, and followingthe proposed evaluation methodology, we now proceedwith our study by deploying an ad-hoc networktestbed composed of low cost netbooks, allof which are equipped with IEEE 802.11g wirelesscards. The laptops were configured to enable QoSsupport through IEEE 802.11e, meaning that videoJP2011-387

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IDetails about the different video sequences used (source formats).Video sequence Resolution Degree of motion Scene changes Frame rate DurationSequence #1 768×576 high very frequent 25 fps 18 sSequence #2 1280× 720 moderate frequent 25 fps 20 s45H.264/AVCMPEG-4/ASP45H.264/AVCMPEG-4/ASP4040Peak Signal-to-Noise Ratio (dB)3530Peak Signal-to-Noise Ratio (dB)35302525200.1 1 10Packet loss rate (%)200.1 1 10Packet loss rate (%)Fig. 2. PSNR values for video sequence #1 (left) and video sequence #2 (right) when varying the packet loss rate on thechannel.12H.264/AVCMPEG-4/ASP12H.264/AVCMPEG-4/ASP1010Frame loss ratio (%)864Frame loss ratio (%)8642200.1 1 10Packet loss rate (%)00.1 1 10Packet loss rate (%)Fig. 3. Frame loss ratio values for video sequence #1 (left) and video sequence #2 (right) when varying the packet loss rateon the channel.traffic can be transmitted at a higher priority categorycompared to best effort traffic.Due to the complexity of the experiments and thetime involved, the tests presented in this section usevideo sequence #1 alone. We now present experimentalresults considering both a static and a mobiletopology.A. Static topology testsIn this section we perform some experiments in astatic ad-hoc network environment. In our tests weassess performance when varying the number of hopsbetween video transmitter and receiver. For the networkto operate under realistic assumptions, we alsocreate best-effort traffic flows. These flows consist ofconstant bitrate UDP traffic regulated to produce amoderate/high degree of congestion in the network.In particular, each of these background traffic clientswill generate about 8 Mbit/s using 1400 byte packets,although the number of hops associated with eachflow differs (see Figure 4). With this purpose, thevideo streaming client connects to a different streamingserver in each test.Figure 5 shows the packet loss ratio experiencedat different hops for both two video codecs. NoticeFig. 4. Static testbed environment used for multi-hop ad-hocnetwork performance tests.that, since the target bitrate is the same for bothvideo codecs, the packet loss rate is expected to besimilar in both cases. In fact, the differences detectedare mostly related to the variability of the wirelesschannel’s capacity in the presence of other sources ofinterference.Overall, we find that losses grow proportionally tothe hop count, being the most significant growth detectedwhen increasing the hop count from one to twohops. For a greater number of hops, the packet lossratio increase becomes proportionally less significantcompared to this initial growth.Concerning PSNR values, figure 6 (left) shows thatvideo quality at one hop is very good, as expected.JP2011-388

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 6. PSNR values (left) and Frame loss ratio (right) for both video codecs when increasing the number of hops betweensource and destination.Fig. 5. Packet loss ratio values for both video codecs whenincreasing the number of hops between source and destination.However, as the number of hops increases, the PSNRvalues decrease at a rate of about 2 dB per hop for theH.264/AVC video codec. In the case of the MPEG-4/ASP encoded stream, the per-hop decay is greater,although it levels out at three hops (almost no differencecompared to the four hops case).The frame loss results are coherent with the packetloss and PSNR results, again evidencing that theH.264/AVC video codec is again able to offer a betterperformance (see fig. 6, right). Nevertheless, andindependently of which codec is used, we find thatframe losses at high hop counts become excessive forgood quality video streaming.Overall, we find that the H.264/AVC codec offersa consistent improvement compared to the MPEG-4/ASP encoder, and that the number of hops is a factorwhich drastically affects quality when the channelis congested.B. Mobile topology testsThe last target scenario defined in the proposedmethodology is a mobile ad-hoc network environment.The chosen setting is similar to the previoussection, being the main difference that now the videostreaming client will be moving across the scenario.This client is initially located away from the streamingserver (4-hop distance) and, when the experimentbegins, it will start moving towards the streamingserver at a constant speed (10 or 15 m/s in our ex-Fig. 7. Mobile testbed environment used for multi-hop ad-hocnetwork performance tests. Emulated distance betweenstatic stations is of 200 meters.periments), meaning that the hop count will be graduallyreduced (see figure 7). We rely on the OLSRrouting protocol [14] for topology maintenance.In our experiments, we perform tests both withand without background traffic. The former adoptthe same flow characteristics used in the previoussection for the static testbed. Each experiment lastsfor 40 seconds, which in our setting corresponds tomoving the streaming client until it is within rangeof the streaming server (optimal conditions).Table II shows the results obtained for the differentscenarios considered. These results show how mobilityand congestion affect video performance. We findthat, while mobility is the most important sourceof packet losses, congestion has a greater impact onthe average PSNR since losses are more distributedthroughout frames. Another important conclusionthat can be directly drawn from these results is thatpacket losses experienced in the presence of both highmobility and congestion are basically the sum of boththese causes of loss, meaning that mobility and channelcongestion are basically additive factors for thepacket loss metric. In terms of frame loss ratio, thismetric is strictly related to packet losses, where againwe confirm the higher performance offered by theH.264/AVC codec.VI. ConclusionsIn this paper we presented a methodology for assessingvideo streaming quality in MANET environ-JP2011-389

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIExperimental results obtained in the mobile testbed scenario.Video Node speed Background Packet loss PSNR Frame losscodec (m/s) traffic ratio (%) (dB) ratio (%)H.264/AVC 10 NO 0.22 41.52 0.39MPEG-4/ASP 10 NO 0.21 43.36 0.26H.264/AVC 15 NO 22.72 36.62 20.71MPEG-4/ASP 15 NO 22.38 36.69 22.34H.264/AVC 10 YES 8.75 34.40 10.22MPEG-4/ASP 10 YES 8.98 35.42 12.21H.264/AVC 15 YES 31.17 29.24 30.28MPEG-4/ASP 15 YES 32.08 29.19 32.08ments. Our proposal includes a well-defined videoevaluation framework that allows assessing performancewhen combining different video codecs anddifferent transmission scenarios. In particular, wepropose performing the evaluation in several phases,where in the first phase we make an in-depth evaluationin a point-to-point lossy channel to determinethe codec error resilience under different channel conditions,and, in a second phase, performance assessmentanalysis is carried out in a real ad-hoc networktestbed to determine the impact of congestion, hopcount and mobility on performance. Our testbed offersfull QoS support through IEEE 802.11e, and relieson emulation to devise test scenarios under bothstatic and dynamic network conditions.By following our methodology, we comparedthe performance of two state-of-the-art codecs:H.264/AVC and MPEG-4/ASP. The performanceindexes gathered evidence the better performanceof H.264/AVC when compared to MPEG-4/ASP.Nevertheless, we find that the differences betweencodecs become minimal as we increase the packetloss rate and the video resolution. Experimentaltestbed results show that, for a static environment,the amount of losses experienced under moderatebest-effort loads do not compromise video transmission,although video quality may experience a degradationof up to 14 dB when the number of hops increasesfrom one to four hops. In the presence ofmobility, and using the OLSR protocol for routingtasks, we find that performance is quite good whenthe degree of mobility and congestion is low. Whencongestion increases, the video sequence experiencesa significant quality degradation due mostly to randomlosses. Instead, mobility is prone to cause longloss bursts due to route disruption. We also foundthat, in scenarios characterized by both high degreesof mobility and congestion, the video stream experiencesa loss pattern that is basically an additivecombination of the effects of these two parameters.Overall, we find that the proposed methodologyoffers a comprehensive analysis of video streamingperformance in MANETs, allowing to discriminatelosses according to their particular origin so that anyimprovement efforts point to the right direction.AcknowledgmentsThis work was partially supported by the Ministeriode Ciencia e Innovación, Spain, under GrantTIN2008-06441-C02-01.References[1] “Draft ITU-T Recommendation and Final Draft InternationalStandard of Joint Video Specification (ITU-TRec. H.264 | ISO/IEC 14496-10 AVC),” oint Video Team(JVT) of ISO/IEC MPEG and ITU-T VCEG, JVTG050,March 2003.[2] ISO/IEC IS, “Coding of Audio-Visual Objects, Part 2:Visual (MPEG-4),” Information Technology, November2001.[3] T. Schierl, C. Hellge, K. Ganger, T. Stockhammer, andT. Wiegand, “Multi Source Streaming for Robust VideoTransmission in Mobile Ad-Hoc Networks,” in IEEEInternational Conference on Image Processing, Atlanta,GA, USA, Oct. 2006.[4] Tarek Sheltami, “Performance Evaluation of H.264 Protocolin Ad hoc Networks,” Journal of Mobile Multimedia,vol. 4, no. 1, pp. 59–70, 2008.[5] C.T. Calafate, M.P. Malumbres, J. Oliver, J.C. Cano,and P. Manzoni, “QoS Support in MANETs: a ModularArchitecture Based on the IEEE 802.11e Technology,”IEEE Transactions on Circuits and Systems for VideoTechnology, vol. 19, no. 5, pp. 678–692, May 2009.[6] Gyeongcheol Lee and Hwangjun Song, “Cross layer optimizedvideo streaming based on ieee 802.11 multi-rateover multi-hop mobile ad hoc networks,” Mob. Netw.Appl., vol. 15, pp. 652–663, October 2010.[7] M. Martinez-Rach, O. López, P. Piñol, M.P. Malumbres,J. Oliver, and Carlos T. Calafate, “Quality AssessmentMetrics vs. PSNR under Packet Loss Scenariosin MANET Wireless Networks,” in International Workshopon Mobile Video (MV 2007), Augsburg, Germany,2007.[8] The VideoLAN Project, “Vlc: open-source multimediaframework, player and server,” Available at:http://www.videolan.org.[9] The MPlayer Project, “Mplayer - the movie player,”Available at: http://www.mplayerhq.hu/.[10] Janio M. Monteiro, Carlos T. Calafate, and Mario S.Nunes, “Evaluation of the H.264 Scalable Video Codingin Error Prone IP Networks,” IEEE Transactionson Broadcasting, vol. 54, no. 3, pp. 652–659, September2008.[11] Jorge Hortelano, Marga Nacher, Juan-Carlos Cano, CarlosT. Calafate, and Pietro Manzoni, “Castadiva: A Test-Bed Architecture for Mobile Ad hoc Networks,” in 18thAnnual IEEE International Symposium on Personal, Indoorand Mobile Radio Communications (PIMRC’07),Athens, Greece, September 2007.[12] “The Video Quality Experts Group (VQEG),” Availableat: http://www.its.bldrdoc.gov/vqeg/.[13] Sebastian Dorfler, “Xmedia recode 2.2.9.7,” Available at:http://www.xmedia-recode.de/.[14] T. Clausen and P. Jacquet, “Optimized link state routingprotocol (OLSR),” Request for Comments 3626, MANETWorking Group, http://www.ietf.org/rfc/rfc3626.txt,October 2003, Work in progress.JP2011-390

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Statistical Modeling of Transmission Path Lossin Underwater Acoustic NetworksJesús Llor and Manuel Pérez Malumbres 1Abstract—Propagation conditions in an underwateracoustic channel are known to vary in time, causing thereceived signal strength to deviate from the nominal valuepredicted by a deterministic propagation model. Tofacilitate large-scale system design in such conditions (e.g.power allocation), we develop a statistical propagationmodel in which the transmission loss is treated as a randomvariable. By repetitive computation of acoustic field usingray tracing for a set of varying environmental conditions(surface height, wave activity, small displacements oftransmitter and receiver around nominal locations), anensemble of transmission losses is compiled which is thenused to infer the statistical model parameters. A reasonableagreement is found with log-normal distribution whosemean is taken as the nominal transmission loss, and whosevariance appears to be constant for a certain range ofinter-node distances in a given deployment location. Thestatistical model is deemed useful for higher-level systemplanning, where simulation is needed to assess theperformance of candidate network protocols under variousresource allocation policies, i.e. to determine the transmitpower and bandwidth allocation necessary to achieve adesire.Keywords—Underwater acoustics, Acoustic channelmodel, Wireless sensor networks, Network simulation.TI. INTRODUCTIONHE growing need for ocean observation and remotesensing has recently motivated a surge in researchpublications as well as several experimental efforts (e.g.[1]) in the area of underwater acoustic networks. Crucialto these developments is the understanding ofpropagation conditions that define the time-varying andlocation-sensitive acoustic environment, not only fromthe viewpoint of small-scale, rapid signal fluctuationsthat affect the performance of the physical layertechniques, but also from the viewpoint of large-scale,slow fluctuations of the received signal power thataffect the performance of higher network layers. Thisfact has been gaining recognition in the researchcommunity, leading to an increased awareness about theneed for network simulators that take into account thephysics of acoustic propagation [1]-[4]. As a result, thefirst publicly available acoustic network simulators haveemerged [2], and more are likely to come.One of the challenges in the design of underwateracoustic networks is the allocation of power acrossdifferent network nodes. This task is exacerbated by the1 All authors are with the Dept. of Physics and Computer Engineeringat the Miguel Hernandez University (Spain). E-mails: {jllor,mels}@umh.esspatial and temporal variation of the large-scaletransmission loss, and the lack of statistical models thatcapture these apparently random phenomena.While it is well known from field experiments that thereceived power varies in time around the nominal valuepredicted by a deterministic propagation model, little isknown about the statistical nature of these variations.Literature on this topic is scarce; however, several recentreferences indicate that the received signal strengthobeys a log-normal distribution (e.g. [5][6]). A goodsystem design has to budget for signal strengthvariations in order to ensure a desired level of networkperformance (e.g. connectivity), and the budgeting taskcan be made much easier if the statistics of theunderlying process are known.In this paper, we analyze those random variations inthe large-scale transmission loss that are mainlygoverned by the environmental factors such as surfaceactivity (waves) for a particular network scenario. Webegin by employing a prediction model based on theBellhop ray tracing tool [7]. Such a deterministic modelprovides accurate results for a specific geometry of thesystem, but does not reflect the changes that occur as thegeometry changes slightly due to either surface motionor transmitter/receiver motion. Fig.1 illustrates thissituation for a point-to-point link. It shows an ensembleof transmission losses calculated by the Bellhop modelfor a set of varying surface conditions, each slightlydifferent from the nominal.While it is possible in principle to run a deterministicpropagation model for a large number of differentsurface conditions, the underlying computationaldemands are high. In a large network, it is ineffective,and possibly not even feasible, to run a complexprediction model for each packet transmission. Astatistical prediction model then becomes necessary.The goal of our work is to employ an existingdeterministic prediction model (DPM) such as the raytracer [7] to generate an ensemble of channel responsescorresponding to varying propagation conditions in agiven network. Using the so-obtained values, we thenconduct a statistical analysis to obtain the probabilitydensity function (pdf) of the large-scale transmissionloss. The result is a statistical prediction model (SPM)that is easy to employ for network design and analysis.The rest of this paper is organized as follows. In Sec.IIwe outline a specific system example, and discuss thecomputational demands of deterministic propagationmodeling. In Sec.III, we present the results ofdeterministic modeling and develop an underlyingJP2011-391

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011statistical model. In Sec.IV we discuss the implicationsthat statistical modeling can have on networksimulation, and we conclude in Sec.V.6563Transmission Loss (dB)61595755530 500 1000 1500 2000 2500 3000 3500Run Time (seconds)Fig. 1. An ensemble of transmission losses obtained from Bellhopmodel. Solid line indicates the average over the total run time.Dashed lines indicate the values of one standard deviation σ.II. SYSTEM SET-UPThe network of interest is located in coastal watersnear Valencia, Spain, at coordinates 39°48'13.14"N and0°4'34.53"W. It consists of eight nodes arranged in alinear topology, as illustrated in Fig.2.In general, an arbitrary network location can beconsidered, for which the bathymetry, floor sedimentand sound speed profile can be found in the onlinedatabases [8], [9], [10]. In our example, the source isassumed to be at one end, and the rest of the nodes areplaced at different distances ranging from 500m to3,700m. The nodes are at a depth of 10 meters, while thewater depth varies from 25m to 35m within the coveragearea. Table I summarizes the system parameters.We assume a fixed network topology, and vary theparameters that are related to the wave activity (waveheight and wave length). The surface parameters aretaken from historical and prediction values fromNational Geophysical Data Center databases [11], [12].We also account for the fact that an acousticcommunication signal does not consist of a singlefrequency, but occupies a (possibly wide) bandwidth.The overall transmission loss is thus computed over theentire frequency range, which is taken here to be 5 kHz– 15 kHz.Each execution of the Bellhop tool [7] takes about 5minutes on an Intel Core 2 Duo CPU 2.10 GHzprocessor running on a standard laptop computer with 3GB of RAM memory. Considering 14 different waveheights and 14 different wave lengths, i.e. 196 differentscenarios, the complete analysis lasts about 16 hours fora single source location and a single frequency withinthe signal bandwidth.Each simulation run produces the acoustic field valuesin a 5km x 5km x 30m volume, with a resolution of0.33m 3 . The values corresponding to selected receivingnode locations are then extracted, and a statisticalanalysis is performed for each location.Fig. 2. Network deployment in Valencia, Spain.TABLE ISYSTEM PARAMETERSTransmission range 500 m to 3700 m (in steps of ~500 m)Area5000 m x 5000 mSediment floorFrequencyMonthGravel5-15 kHzAugustWave height 1 m to 3 m (in steps of 0.15 m)Wave length 100 m 150 m (in steps of 3.5 m)Water depth25 m to 35 mIII. STATISTICAL PROPAGATION MODELThe statistical propagation model is built bycompiling the transmission loss values obtained from thedeterministic model. The values of transmission loss,expressed in dB (logarithmic scale) are treated asrandom variables, and it is implicitly assumed that allsurface conditions are equally likely.Fig. 3 shows the histogram of the values obtained forNode 2, which is 500 m away from the source, and Fig.4 shows the histogram obtained for Node 3, which is1100 m away from the source. Shown also in thesefigures is a normal distribution with mean and varianceequal to the ensemble averages of the transmission loss(solid curves).18016014012010080604020025 30 35 40 45 50 55 60 65 70Transmission Loss (dB)Fig. 3. Histogram of the transmission loss calculated for Node 2 usingthe deterministic propagation model for varying surfaceconditions.JP2011-392

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Histogram of the transmission loss calculated for Node 3 usingthe deterministic propagation model for varying surfaceconditions.Transmission Loss (dB)16014012010080604020025 30 35 40 45 50 55 60 65 7080706050403020Transmission Loss (dB)500 1100 1600 2100 2600 3200 3700Distance (meters)Fig. 5. Transmission loss mean value and standard deviation (boxed)versus distance.The mean and variance obtained for different rangesfrom the source (different locations of the receivingnode) are shown in Fig.5. We note that the mean valueof transmission loss increases with distance, as dictatedby the energy spreading, assumed here to be cylindrical.The variance, however, does not change much with thedistance. This fact motivates us to assume the samevariance for all the distances considered. Namely, wetake the standard deviation to be the average of allobserved values, 5.91 dB (a negligibly different result isobtained if the variances are averaged).A statistical model is now assumed, which generatesthe transmission loss as a normally distributed randomvariable on a logarithmic scale (or equivalently, lognormallydistributed on a linear scale). The mean valuefor this model can be taken as the ensemble averageobtained from the deterministic model for a givendistance, but another approach is possible as well.Namely, we take the mean transmission loss for thestatistical model to be the value obtained from a singlerealization of the deterministic model for nominalsystem geometry with no waves. The goal in doing so isto further reduce the computational demands involved inbuilding the statistical model for a given deploymentgeometry.NodeTABLE IITRANSMISSION LOSS PARAMETERS OBTAINED FROM THEDETERMINISTIC PROPAGATION MODEL AND STATISTICALPROPAGATION MODELDistance[m]DPMSPMmean [dB] σ [dB] mean [dB] σ [dB]2 500 41.78 6.14 41.653 1,100 47.82 5.91 48.014 1,600 50.83 5.60 50.795 2,100 53.81 6.12 53.806 2,600 56.52 5.74 56.327 3,200 59.01 5.88 58.988 3,700 60.50 5.96 60.41TABLE IIIKULLBACK-LEIBLER DISTANCE.Node Distance [m] KL distance2 500 0.0303 1,100 0.0214 1,600 0.0185 2,100 0.0176 2,600 0.0157 3,200 0.0145.918 3,700 0.013In Table II, we can see that nominal transmission loss(mean value listed for SPM) differs very little from thevalue calculated by ensemble averaging of thedeterministic model’s outputs (mean value listed forDPM). The pdf resulting from the statistical model isshown in Figs.3 and 4 as a dashed curve.We note that the distributions resulting from the twomodels are quite similar. In order to quantitatively judgethe validity of the hypothesized statistical model, wehave calculated the Kullback-Leibler (KL) distance [13]between the pdf estimated from the deterministic model(histogram of Fig.3 and 4) and the Gaussian pdf used forthe statistical model. This distance is zero when the twodistributions are identical. In Table III, we list the KLdistance for every source-destination pair considered.IV. IMPLICATIONS FOR NETWORK PLANNINGThe apparent match between the results ofdeterministic and statistical models motivates the use ofSPM for network design and analysis via simulation.Consider, for example, network simulation over aprolonged interval of time that spans varyingpropagation conditions and involves transmission of alarge number of data packets over multiple hops. Ifdeterministic modeling is used, each packet transmissionrequires one execution of the Bellhop ray tracer, whichsoon becomes excessively long for a growing number ofdata packets (assuming 5 minutes for each Bellhop runand a single frequency, 100,000 packets would takeabout a year). Although the DPM offers an exactsolution for the particular geometry observed at anygiven moment in time, its execution makes thesimulation times unaffordable for benchmarking andtesting of the upper layer protocols.In contrast, a statistical model can take several hoursto compute (16 hours in the example we presented) thepath loss statistical model for the entire networkscenario, but once computed, each realization (packetJP2011-393

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011transmission) requires only a single call to a Gaussianrandom number generator. Moreover, if the networktopology changes slightly, or if a new node is added, thestatistical model needs to be augmented only by thecorresponding set of nominal transmission losses, eachof which requires a single Bellhop run.Most importantly, the statistical model can easily beused to assess transmit power allocation that willguarantee successful data packet reception with adesired level of performance (e.g. link reliability).Namely, the SPM can easily be used to calculate thetransmission loss values that are not exceeded with agiven probability (i.e cumulative distribution function).For example, a 90% transmission loss is that valuewhich is not exceeded for 90% of time, i.e. in 90% ofchannel realizations. Fig.6 shows the 50%, 75% and90% transmission loss for our system example. Weobserve a good match between the values predicted bythe deterministic model, and those of the statisticalmodel. Note that the X% values of the SPM arecomputed analytically, based only on the knowledge ofthe mean and standard deviation.The availability of X% values is significant fordetermining the transmit power necessary to achieve acertain level of performance. Typically, networkplanning is based on the nominal ray trace, i.e. on the50% transmission loss to which some margin may beadded. If transmit power allocation is based on adifferent value, say 90% transmission loss instead of thenominal 50%, data packets will be more likely to reachtheir destinations. More power will be needed at thesame time, but the overall network performance mayimprove. We say may improve, because a highertransmit power also implies higher levels ofinterference. The resulting performance trade-offs aregenerally hard to address analytically, and are insteadassessed via simulation. A statistical propagation modelthat directly links the transmit power to the X%transmission loss then becomes a meaningful and usefultool for system design.Transmission Loss (dB)706560555045DPM 90%SPM 90%DPM 75%SPM 75%DPM 50%SPM 50%400 500 1000 1500 2000 2500 3000 3500 4000Distance (meters)Fig. 6. Transmission loss value that is not exceeded with a givenprobability (50 %, 70%, 90%) is shown versus distance. The solidand dashed curves show the results obtained from thedeterministic and the statistical propagation models, respectively.V. CONCLUSIONSLarge-scale design of an underwater acoustic networkrequires a judicious allocation of the transmit poweracross different links to ensure a desired level of systemperformance (connectivity, throughput, reliability, etc.).Because of the inherent system complexity, simulationanalyses are normally conducted to assess theperformance of candidate protocols under differentresource allocation policies. These analyses are oftenrestricted to using deterministic propagation models,which, although accurate, do not reflect the randomlytime-varying nature of the channel.While it is possible in principle to examine thenetwork performance for a large set of perturbedpropagation conditions, the computational complexityinvolved in doing so is extremely high. To facilitatenetwork simulation in the presence of channel fading,we investigated a statistical modeling approach. Ourapproach is based on establishing the nominal systemparameters for a desired deployment location (waterdepth, sediment composition, operational frequencyrange) and using ray tracing to compute an ensemble oftransmission losses for typical inter-node distances. Anensemble is generated by considering a set of perturbedsurface conditions, defined by varying wave activity(height, period). The so-obtained ensemble is then usedto determine the statistical parameters of a hypothesizedlog-normal distribution of the transmission loss. For arepresentative example of a small network operating ina 5 km x 5 km area with inter-node distances rangingbetween 500 m and 3.5 km, it was found that the meancan be well approximated by the value obtained usingnominal system parameters, while the variance can bemodeled as distance-independent. Models that are moreelaborated and more accurate than the log-normal onecan also be developed using this approach.This kind of statistical modeling allowscomputationally-efficient inclusion of fading effects intoa network simulator. Namely, to assess the averagesystem performance, network operation has to besimulated over a large set of channel realizations (e.g.varying surface conditions). Whereas repeatedcomputation of the ray trace for different hops that eachof the data packets traverses in a given network may becomputationally prohibitive, statistical modelingrequires only a single call to the Gaussian randomgenerator for each packet transmission. The overallsimulation time is thus considerably reduced, allowing asystem designer to freely experiment with varyingprotocols and resource allocation strategies in anefficient manner. The ultimate goal of such experimentsis to choose the best upper-layer protocol suite and torelate the necessary system resources (power,bandwidth) to the propagation conditions, i.e. to thestatistical parameters of the transmission loss (e.g. X%value), which can in turn be easily generated using theproposed method of statistical modelingJP2011-394

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ACKNOWLEDGMENTSThis work was supported by the Ministry of Science andEducation of Spain under Project DPI2007-66796-C03-03.REFERENCES[1] J.A. Rice, W.O. Che, “A Discovery Process for InitializingUnderwater Acoustic Networks,” in Proc. IEEE Sensorcomm,pp.408-415, July 2010.[2] F. Guerra, P. Casari, M. Zorzi, “A performance comparison ofMAC protocols for underwater networks using a realistic channelsimulator,” in Proc. IEEE Oceans Conf, pp.1-8, Oct. 2009.[3] G. Xie, J. Gibson, L. Diaz-Gonzalez, “Incorporating RealisticAcoustic Propagation Models in Simulation of UnderwaterAcoustic Networks: A Statistical Approach,” in Proc. IEEEOceans Conf, pp.1-9, Sept. 2006.[4] J. Llor, M. Malumbres, “Performance Evaluation of UnderwaterWireless Sensor Networks with OPNET,” in Proc. ACMSimutools. ICST, Barcelona, Spain, March 2011.[5] B. Tomasi, P. Casari, L. Badia, M. Zorzi, “A Study ofIncremental Redundancy Hybrid ARQ over Markov ChannelModels Derived from Experimental Data,” in Proc. ACMWUWNet, Woods Hole, MA, Sep. 2010.[6] W.-B. Yang, T.C. Yang, “Characterization and Modeling ofUnderwater Acoustic Communications Channels for Frequency-Shift-Keying Signals,” in Proc. IEEE Oceans Conf, pp.1-6, Sept.2006.[7] M. Porter et al., “Bellhop code.” [Online]. Available: http://oalib.hlsresearch.com/ Rays/index.html.[8] “National geophysical data center, seafloor surficial sedimentdescriptions”. [Online]. Available:http://www.ngdc.noaa.gov/mgg/ geology/deck_41.html.[9] “General bathymetric chart of the oceans”. [Online]. Available:http:// www.gebco.net.[10] “World ocean atlas”. [Online]. Available:http://www.nodc.noaa.gov/ OC5/WOA05/pr_woa05.html.[11] “METEOSIM”, [Online]. Available: http://www.meteosim.com.[12] Puertos del Estado, [Online]. Available: http://www.puertos.es.[13] A. Rényi, Probability Theory. New York: Elsevier, 1970.JP2011-395

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-396

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Predictive and Distributed Routing Balancingfor High Speed Interconnection NetworksCarlos Núñez Castillo, Diego Lugones 1 Daniel Franco,Emilio Luque 2Abstract— Current parallel applications in parallelcomputing systems require an interconnection networkto provide low and bounded communication delays.Communication characteristics such as trafficpattern and communication load change over timeand, eventually, they may exceed available networkcapacity causing congestion and performance degradation.Congestion control based on adaptive routingshould be applied in order to adapt quickly tochanging traffic conditions. Studies on a vast rangeof parallel applications show repetitive behavior andthat they can be characterized by a set of representativephases. This work presents a Predictive andDistributed Routing Balancing technique (PR-DRB)to control network congestion based on adaptive trafficdistribution. PR-DRB uses speculative routingbased on application repetitiveness. PR-DRB monitorsmessages latencies on routers and logs solutionsto congestion, to quickly respond in future similar situations.Experimental results show that the predictiveapproach could be used to improve performance.keywords— Interconnection networks, predictiverouting, parallel applications, application aware routing.I. IntroductionIN the early days of High Performance Computing(HPC) systems, interconnection network highlatency and low bandwidth bottleneck significantlyaffected applications execution. Advances in currentinterconnection technologies such as InfiniBand(IBA) [1] allowed higher transmission rate and lowerlatency, fulfilling with HPC requirements. HPC communicationsare characterized by bursty traffic, asopposite to a constant packet injection [2]. Burstytraffic can produce Hot-Spot situations, where somenetwork resources are congested while others remainsidle. If congestion is not efficiently controlled, messagelatency is increased and performance is degraded.One solution to this problem are the adaptiverouting algorithms. Communication patterns inHPC applications are repetitive [3]. This repetitivenesscould be useful to the routing module in orderto solve future network situations based on past information.We propose a Predictive and DistributedRouting Balancing algorithm (PR-DRB) after consideringrouting algorithm limitations and requirementstogether with applications repetitiveness. Ourmain goal is to reduce latency under repetitive communicationpatterns. PR-DRB is based on DRB[4], but enhanced with a predictive routing module.1 Computer Architecture and Operating Systems Department,UniversitatAutónoma de Barcelona, Spain, e-mail:{carlos.nunez, diego.lugones}@caos.uab.es2 Computer Architecture and Operating Systems Department,UniversitatAutónoma de Barcelona, Spain, e-mail:{daniel.franco, emilio.luque}@uab.esDRB adapt itself to congestion by opening alternativepaths. This stabilization process is costly intime.The main contributions of this work is the capabilityto learn from a parallel application communicationpattern, solve congestion and then use this solutionwhen similar congestion is detected again. Thisapproach allows fast reaction to repetitive congestionpatterns. Repetitive communication patternsalternated with computation is a typical HPC applicationfeature[2], and it represents an applicationphase [3]. Applications alternate between phases,which causes specific traffic patterns (e.g. a set ofsource/destinations pairs) to reappear. PR-DRBstrategy is shown in Fig. 1. During application firstphase, PR-DRB has high latency values (1) becauseit is searching alternative paths. At the end of phase1 (2), latency is stable and the best solutions foundare saved at the source node. Best solutions are identifiedwhen latency curve starts decreasing. Laterphases do not reach its highest historical latencyvalue. Here, PR-DRB has identified similar communicationpatterns again(3) and best paths saved areused(4). PR-DRB approach is to maintain stable latencyvalues during the whole application execution.The rest of this paper is organized as follows. In Sec.2 congestion control, parallel application repetitivenessand their relation to this work are given. InSec. 3 the PR-DRB methodology is described. Sec.4 shows the performance evaluation. Conclusion areexplained in Sec. 5.II. Background and JustificationA. Congestion ControlCongestion control is based on monitoring, detectionand further control. To evaluate congestion,point to point latency [5], buffer occupation level [6]or backpressure [7] are used. One control techniqueis message Throttling [8], that stops (or reduces)packet injection until packets that belong to a congestedarea are delivered. Message throttling keepbuffer occupation bounded but latency is increasedbecause packets must remain at source nodes longer.Finally, congestion control techniques based on adaptiverouting algorithms [4], [9], [10] work by sendingmessages from source to destination through alternativepaths. Adaptive routing advantage is that congestedarea is avoided and message injection is upheld.The overhead resulting from information monitoring,the path changing and the need to guaranteeboth: deadlock freedom [11] and ’in-order’ packetdelivery are some disadvantages.JP2011-397

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011B. Parallel Application RepetitivenessStudies of parallel applications in HPC revealthey have repetitive behavior, based on computingand communications phases [3]. Programs tend tobe written in a modular fashion, and have a verystrong periodic behavior [12]. On Fig. 2 the repetitivebehavior of the NAMD application is shown.This repetitive behavior represented by fundamentalphases of the entire application can lead to situationswhere specific traffic patterns reappear (e.g. a setof source/destination pairs). Representative phasesfrom parallel applications can be extracted with thePAS2P performance prediction tool [3]. For example,the NAS CG benchmark has four representativephases and they consume 99.10% of execution time.Each phase here is repeated 2600 times on averageduring execution. The SMG2000: SemicoarseningMultigrid Solver, also has 4 representative phases,and they consume 99.99% of total execution time.Here, phases 1 to 4 are repeated 1, 1, 1185 and 15times, respectively. Here only phase 3 is relevant tocommunications. SWEEP3D: 3D Discrete OrdinatesNeutron Transport application has approximately 80different phases, but only 5 phases are representativeby consuming 96.17% of total time. Each of thesephases repeats 14874, 14257, 14930, 2062 and 12890times during the application execution.C. JustificationBased on previous examples of communicationpatterns repetitiveness, we can say that High SpeedInterconnection Networks (HSIN) routing performancedepends mostly on the communication patternused and the application mapping of nodes toprocessors. Some routing techniques use static applicationinformation, such as bandwidth, to help performrouting decisions [13]. To improve communicationperformance, hence applications currently runningin the network, a technique capable to combineadaptive algorithms and communication patterns isneeded, so that routing and congestion control canperform as fast as possible and minimize the overhead.III. Predictive-Distributed RoutingBalancingWe propose a routing algorithm, PR-DRB, basedon the study of communication latencies and repetitiveapplication patterns in HPC applications. PR-DRB internals is covered here in more details.A. PR-DRB Working SchemePR-DRB seeks better system response time by usingcached communication information and a set ofalternative paths. The proposed model performs fourbasic tasks: Monitoring, Notification, Path Configurationand Path selection procedures. Monitoring includesthe tasks of latency values accumulation andcontending flows identification, performed at intermediaterouters. Notification is initiated at desti-Latency behavior (s)(1) and (3) Congestion Detected(2) and (4) Stable LatencyHighCongestion(2)Stable latency valueTime (s)PR-DRB(latency)Traffic(1) Application (3) Application ApplicationPhase 1Phase 2Phase nLow Congestion(4)Fig. 1: PR-DRB-ProcessFig. 2: Repetitiveness in Parallel Applicationsnation endnodes. Here, and Acknowledge (ACK)message with path information is created and sentback to source endnode. The third task involves theconfiguration of new alternative paths, according tolatency values. This task is named Metapath Configurationand is also performed at source nodes. Ifthere are saved solutions for a congestion situation,the paths are taken from the saved solution database.Otherwise, new alternative paths are created. Later,the fourth task is accomplished when new messagesare injected into the network. Here, selection procedureschoose best paths among those configured inprevious task.At the monitoring phase, latency values are accumulatedin messages at every intermediate router.The aggregate latency value will be used later at thesource node to identify congested regions. An intermediaterouter contains information about sourcesand destinations currently enqueued. This informationrepresents contending flows for PR-DRB. Congestionand conflictive pattern detection are also performedin the monitoring phase. When aggregatelatency value surpasses a threshold in the path, contendingflows are identified and saved in the messagetogether with latency values. When at destination,an acknowledge message (ACK) with contendingflows and latencies is sent to the source. At theconfiguration phase, calculation of all possible pathsavailable to tackle congestion is performed. Selectionthen performs dynamic path expansion controlled bycongestion level in each source/destination path.Each alternative path is created, schematically, usinga three step path (multi step path, MSP) by selectingtwo intermediate nodes, near by the source(IN1) and destination (IN2) nodes. PR-DRB buildsalternative paths around the original path. Each singlepath is traversed using original routing definedfor the topology. Latency information is used to de-Load (bits/s)JP2011-398

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cide the number of alternative paths and how to distributemessages among these paths. Afterwards, latency,alternative paths used and conflictive communicationpatterns are all cached at source. With thisprocedure, best paths for each source/destinationpair under a particular congestion situation are beingsaved. In future similar congestion situation, thebest known solution will be re-applied directly. PR-DRB working scheme is shown in Fig. 3. Detectionand latency logging as well as the pattern that causedcongestion are shown in Fig. 3 (a). Configuration ofa set of possible start nodes for alternative paths (theMeta path) is shown in Fig. 3 (b), and a set of alternativepaths used at the MSP are shown in Fig.3(c).B. PR-DRB FunctionalityFig. 4 shows PR-DRB functionality. The fourtasks of PR-DRB are also highlighted in Fig. 4.When a source node wants to send some data, depictedin Source Endnode, a message is built andinjected into the network. Then, as seen in MessageRouting, the multi-header message is forwardedthrough intermediate routers. As shown in the Monitoringbox in Fig. 4, the delay suffered in switchbuffers (queuing latency) is logged into the message.If queuing latency values exceeds a threshold whilestill at intermediate routers, contending flows patternsare also logged by PR-DRB. This allows similartraffic pattern recognition in future communications.Once the message reaches destination, as seen in DestinationEndnode, Notification takes place. The Notificationbox depicts the task involved in this procedure.Here, latency as well as conflictive communicationpatterns found are sent back to the source inan acknowledge message (Ack). Not all contendingflows are notified, but only those which contributesmost to congestion. At source nodes latency valueand contending flows are analyzed. The analysis procedureis shown in the Fig. 4, at the Metapath Configurationbox. This module configures alternativepaths to be used accordingly to latency value. If latencydenotes congestion, then new alternative pathsare needed. PR-DRB then looks for an already analyzedcongestion situation. If this is the case, the setof optimal alternative paths used previously is obtainedfrom the database. If no solutions are found,then alternative paths opening procedures are initiated.If latency values denotes congestion stabilization,then alternative paths closing procedures areinvoked. Here, information about contending flowsduring congestion situations is also updated. Basedon parallel application repetitiveness, meta path configurationcan be simplified to use cached informationfrom the first phase of the program execution.Later, when a message is ready to be injected intothe network PR-DRB performs the Path Selection.This module selects a multi step path (MSP) for eachmessage. Here, PR-DRB selects which paths are goingto be used from those configured in the MetapathConfiguration step. A distribution of communicationload over the meta path is accomplished in order toperform the dynamic traffic balancing. Paths havinglower latency values are more frequently used,and they receive proportionally a greater number ofmessages. Path expansion is performed gradually.Given a source node with N alternative paths, let’sbe L c i(i : 1..N) the latency recorded by path Ci. Thealternative path Cx will be selected in the followinginjection according to the probability:p(Cx) =(1/L Cx)∑ Ni=1 1/L Ci(1)When congestion first appears in the network, PR-DRB learns from those situations. As parallel scientificapplication do have repetitive communicationpatterns in time, when PR-DRB identify a similaralready analyzed situation, it looks for a set of optimalpaths into its database of saved solutions. Theprocess of detecting already analyzed situations isbased on similarity. PR-DRB is based on contendingflows comparisons during congestion. As statedin section III-A, a router logs latency values and contendingflows during congestion situations. Whena new packet arrives, congestion level in the pathis evaluated, and contending flows involved are updated.PR-DRB compares the saved list of contendingflows against the new list arriving. Similarity isbased on approximation matching. If some predefinedpercentage of nodes matches in both lists, thenPR-DRB marks this situation as already analyzed.As shown in Fig. 4, a message is forwarded withoutany overhead when the output port is free (thickarrows). Otherwise, packet is queued and latencyis simultaneously accumulated until the message isready to be forwarded again. As PR-DRB is basedon the DRB algorithm, already proposed congestioncontrol technique for Infiniband [11] could be alsoFig. 3: PR-DRB working schemeJP2011-399

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4: PR-DRB-ProcessFig. 5: PR-DRB Final solution savedused. As IBA already has many of the functionalitiesrequired by PR-DRB, integration of the predictivemodule is fairly feasible. For example, IBAswitches already have monitoring functions. Also aprocedure for congestion notification (CN) is availableand path opening procedures can be configuredby the Congestion Control Agents (CCA).C. Contending Flows and Solution RepresentationA complete path expansion process is given in Fig.5. We can see that PR-DRB, for this example, goesthrough three steps in order to find the proper setof alternative paths to alleviate congestion. Thisset of alternative paths conform the best solutionfound so far. In order to reuse the same known solutionafterwards, PR-DRB saves contending flowsand best solutions information. Contending flowspairs (S1-D1, S2-D2) are identified, as well as thepaths opened for this solution (P1, P2, P3). The inforegistered is given in Fig. 5 “Node S1 - Saved Solution”.This diagram corresponds to what the node S1knows about the congestion situation, and the pathsit should open once it contends again against nodeS2. Because the nodes involved in congestion willbe correctly notified, each source involved should fillits own table with particular paths opened for thissituation.D. PR-DRB ConsiderationsThe Ack generation is invoked only when congestionis detected, and its operations are performedwhen messages are waiting in the queue. Hence, computingthese operations and packet delivery are performedconcurrently, as shown in Fig. 4. PR-DRBnode level operations have not a high overhead becausethese operations are performed locally, they aresimple (comparisons and accumulations for latencyevaluation, logging small traffic info), and they donot delay send/receive primitives. During multi steppath creation, deadlock freedom is ensured by havinga separate escape channel for each segment. Withtwo intermediate nodes, one escape channel is usedfrom S to IN1, another from IN1 to IN2, and a thirdone from IN2 to D. This way, each segment definesa virtual network, and the packets change virtualnetwork at each intermediate node. Although eachvirtual network relies on a different escape channel,they all share the same adaptive channel(s). The useof adaptive routing algorithms can cause out of orderdelivery of packets. If an application requires inorderpacket delivery, a possible solution is to reorderpackets at the destination node using the well knownsliding window protocol, as used in other routingpolicies like [9]. The following section presents theperformance evaluation of PR-DRB policy. The evaluationmethodology is designed to compare PR-DRBbehavior against DRB [4], which has been alreadycompared against other traditional algorithms, underdifferent interconnection network scenarios.IV. PR-DRB EvaluationThis section presents the performance evaluationof PR-DRB. Latency is evaluated in order to assessPR-DRB. Latency is the time elapsed since a packetis created until it reaches its destination, and it ismeasured in seconds. Evaluation is divided in twoparts. For the first, simulations were conducted for a64 nodes network arranged in an 8x8 mesh topologyunder hotspot traffic. Second part was conductedfor fat tree topologies with 32 and 64 nodes underdifferent permutation traffic.A. Modeling EnvironmentPR-DRB operations, together with network componentswere modeled [14] using the standard simu-JP2011-400

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011lation and modeling tool OPNET Modeler [15]. OP-NET provides a Discrete Event Simulator (DES) engineand a hierarchical modeling environment. Thisallows defining network components behavior by aFinite State Machine approach (FSM), and it supportsdetailed specification of protocols, algorithms,and queuing policies among others. We have assumedvirtual Cut-through flow control [16]. LinkBandwidth was set to 2Gbps, packet size was set to1024 bits and the size of routers buffers was 2MB.B. Hotspot AnalysisThe first part evaluates network response analysisunder bursty Hot-spot traffic using a mesh topology,to evaluate traffic load distribution. This Hotspotexperiment establishes some fixed destinations toproduces network congestion. Remaining networknodes inject uniform load to create ”noisy” traffic.DRB response to the repetitive bursty traffic is alwaysthe same, due to its inability to learn frompast communications. On the other hand, PR-DRBidentifies repeated communication patterns and usescached solutions to congestion. Figs. 6 and 7 showaverage latency map of the mesh network after theexecution of the whole bursty simulation. The surfaceis the average contention latency at buffers. Fig.6 shows DRB behavior, which exhibits high latencyvalues under congested areas. Also, load distributionat routers in coordinates (x,y) (0,1), (6,2) and(6,4) are high, because DRB uses these routers inits alternative paths. Fig. 7 shows the latency mapfor PR-DRB; where its highest value is lower thanDRB. Better load distribution is accomplished byPR-DRB, because it used the best solutions saved,and unnecessary load at routers are avoided.Fig. 6: Mesh network latency map - DRBFig. 7: Mesh network latency map - PR-DRBC. Analysis with Permutation TrafficIn this section PR-DRB is evaluated against DRB,under the fat tree topology with 32 and 64 nodes.Communication patterns such as: ”Matrix Transpose”and ”Perfect Shuffle” were used. Fig. 8 showslatency behavior with 32 nodes. Fig. 8a and 8bshows the performance under Matrix transpose pattern,with traffic load from 400 to 600 mbps/noderespectively. PR-DRB latency reduction achieved is24% under both load scenarios. The Increased trafficinjection is handled properly by PR-DRB. Propercommunication balancing procedures and packetssent through optimal alternative paths from the beginning,keep congestion at minimum. Under 600mbps/node injection, PR-DRB uses progressivelythe maximum number of alternative paths to delivermessages. For repetitive traffic patterns, maximumpath expansion is done directly. By avoidingintermediate path expansion, unnecessary ACK messagesare not generated and overhead is minimizedat source and intermediate nodes. With at most 4 alternativepaths for these experiments, PR-DRB performsa remarkable lower latency than DRB. Fig. 9ashows results with 64 communicating nodes. Latencyreduction under the perfect shuffle pattern is 32%.Fig. 9b shows the result under the Matrix Transposepattern. Higher traffic load is injected into thenetwork and latency remains bounded. Latency isconsiderable reduced here, around 40%, comparedto DRB. PR-DRB uses less network resources fora given load, because those resources are efficientlyhandled. Recall that PR-DRB will behave similarlyto DRB only under the execution of the first phaseof the parallel application, because in this stage PR-DRB is learning from the paths opening procedures.In later phases of parallel applications, like thoseshown here, PR-DRB will apply directly the best solutionsencountered previously. From approximatelytime 1.015 latency values of both algorithms tend tobecome stable and converge.V. ConclusionIn this paper we proposed the Predictive and DistributedRouting Balancing PR-DRB. This strategyuses alternative paths under congestion situation toreduce latency and increase bandwidth availability,by considering time as well as traffic dynamic behaviorconstraints. Routing algorithms try to adaptparallel applications traffic load to network topology.These applications that run on an HSIN possessrepetitive behavior, and PR-DRB is capable to learnfrom it and save information for later use. PR-DRBhas been developed to fulfill HSIN design objectivessuch as all-to-all connection, and low and uniform latencybetween any pair of nodes under any messagetraffic load. The proposed method is also in line withcurrent approaches used in commercial interconnects(as InfiniBand [1]). Our policy allows heavier communicationload in the network, or in cost-boundedJP2011-401

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) 400 mbps(b) 600 mbpsFig. 8: Permutation patterns - Fat tree 32 nodes. Range from 400 to 600 mbps/node(a) 400 mbps(b) 600 mbpsFig. 9: Permutation patterns - Fat tree 64 nodes.data centers it allows using less network components,because they are more efficiently handled. The evaluationperformed to validate PR-DRB has revealedvery good improvements in latency. Saturation isreduced allowing the use of the network at higherloads. We have shown that PR-DRB is a fast androbust method with a very low overhead. Additionally,PR-DRB is useful for permutation and burstycommunication patterns, which are commonly createdby parallel applications and can produce theworst hot-spot situations. As future work, we planto predict future congestion before it has effectivelyappeared based on latency trend analysis.ACKNOWLEDGMENTThis research has been supported by the MEC-MICINN Spain under contract TIN2007-64974.References[1] Infiniband, “Iba,” http://www.infinibandta.org/, 2011.[2] German Rodriguez et al., “Exploring pattern-aware routingin generalized fat tree networks,” in ICS ’09: Procs ofthe 23rd int. conf. on Supercomputing, New York, USA,2009, pp. 276–285, ACM.[3] A. Wong et al., “Parallel application signature,” CLUS-TER ’09. IEEE Int. Conf. on, vol. 1, pp. 1–4, 2009.[4] D. Franco et al., “A new method to make communicationlatency uniform: distributed routing balancing,” inICS ’99: Procs of the 13th int. conf. on Supercomputing,USA, 1999, pp. 210–219, ACM.[5] D. Lugones et al., “Dynamic and distributed multipathrouting policy for high-speed cluster networks,” in CC-GRID ’09: Procs of the 2009 9th IEEE/ACM Int. Symp.on Cluster Computing and the Grid, USA, 2009, pp. 396–403.[6] P.J. Garcia et al., “Recn-dd: A memory-efficient congestionmanagement technique for advanced switching,”Parallel Proc., Int. Conf. on, vol. 0, pp. 23–32, 2006.[7] Elvira Baydal et al., “A family of mechanisms for congestioncontrol in wormhole networks,” IEEE Trans. ParallelDistrib. Syst., vol. 16, no. 9, pp. 772–784, 2005.[8] Shihang Yan et al., “An enhanced congestion controlmechanism in infiniband networks for high performancecomputing systems,” Adv. Inf. Networks and App., Int.Conf. on, vol. 1, pp. 845–850, 2006.[9] Arjun Singh et al., “Globally adaptive load-balancedrouting on tori,” IEEE Comput. Archit. Lett., vol. 3,no. 1, pp. 2, 2004.[10] Christopher J. Glass et al., “The turn model for adaptiverouting,” SIGARCH Comput. Archit. News, vol. 20, no.2, pp. 278–287, 1992.[11] D. Lugones et al., “Dynamic routing balancing on infinibandnetworks,” in Journal of Comp. Science & Tech.(JCS&T), 2008, Cluster Computing ’08, pp. 104–110.[12] Timothy Sherwood et al., “Basic block distribution analysisto find periodic behavior and simulation points in applications,”in PACT ’01: Procs of the 2001 Int. Conf.on Par. Arch. and Compil. Tech., USA, 2001, pp. 3–14,IEEE Comp. Soc.[13] Michel. Kinsy et al., “Application-aware deadlock-freeoblivious routing,” in ISCA’09: Procs of the 36th annualint. symp. on Comp. arch., USA, 2009, pp. 208–219,ACM.[14] D. Lugones et al., “Modeling adaptive routing protocolsin high speed interconnection networks,” OPNETWORK2008 Conf., 2008.[15] Technologies. OPNET, “Opnet modeler accelerating networkr&d,” http://www.opnet.com, June 2008, OPNET.[16] Jose Duato et al., Interconnection Networks: An EngineeringApproach, Morgan Kaufmann Publishers Inc.,USA, 2002.JP2011-402

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evaluación de una alternativa para aumentarel número de puertos de los conmutadoresJuan A. Villar, Francisco J. Andújar, José L. Sánchez, Francisco J. Alfaro 1 y José Duato 2Resumen— En las redes de interconexión basadasen conmutadores, el aumento del número de puertosde un conmutador conlleva una reducción del númerototal de componentes de la red, lo que provocauna reducción significativa del coste total del sistema.Además, los conmutadores high-radix suponen una alternativainteresante para mejorar el rendimiento dela red en términos de latencia pues reducen el númerode saltos de los paquetes. Sin embargo, existen variosproblemas relacionados con la escala de integraciónpara diseñar estos conmutadores en un único chip.En este artículo se explica y evalúa una alternativa deconstrucción de conmutadores high-radix más allá delos límites permitidos por la escala de integración actual.La idea consiste básicamente en combinar variosconmutadores, cada uno en un chip, obteniendo unconmutador con un número de puertos agregado mayor.Esta propuesta es independiente de la evoluciónde los conmutadores de un único chip y seguirá siendoválida conforme la escala de integración continúeevolucionando. Los resultados de simulación han mostradoque con un diseño adecuado del conmutador, lasredes construidas con conmutadores que implementanesta alternativa pueden alcanzar un rendimiento similaral rendimiento de redes construidas con conmutadoresen un chip que proporcionen el mismo númerode puertos, pero dichos conmutadores no existen enla actualidad en el mercado porque la escala de integraciónno permite construirlos en un único chip.Palabras clave— Conmutadores High-Radix, Redesde Altas Prestaciones, Evaluación de Rendimiento.I. IntroducciónLAS redes de interconexión son un componenteclave para una amplia gama de sistemas multiprocesadorque van desde los supercomputadores achips multinúcleo. Las redes de alto rendimiento sonesenciales para estos sistemas, donde se requiere unafiabilidad alta, además de grandes tasas de transferenciay latencias muy bajas. A menudo, la red deinterconexión es el subsistema que requiere un diseñopersonalizado. Por ejemplo, el superordenadorTianhe-1A [1], número uno del Top500 (noviembre2011), está compuesto por procesadores comunes, yuna red de interconexión personalizada. El diseño dedicha red ha eliminado los cuellos de botella contribuyendosignificativamente al rendimiento global delTianhe-1A.El diseño de la red está determinado por la tecnologíade integración cuyos avances han mejoradosustancialmente el rendimiento de sus componentesbásicos: enlaces y conmutadores. Estos últimos sonresponsables de gran parte del nivel de prestacionesde la red, por lo que son objeto de mayor investiga-1 Departamento de Sistemas Informáticos. Universidadde Castilla-La Mancha. Albacete. España. e-mail:{juanan,fandujar,falfaro,jsanchez}@dsi.uclm.es2 Departamento de Informática de Sistemas y Computadores.Universidad Politécnica de Valencia. Valencia. España.e-mail: jduato@disca.upv.esción. Uno de los principales parámetros que caracterizana los conmutadores es su número de puertos (ogrado), el cual tiene una fuerte influencia en el coste,consumo y rendimiento en todo el sistema.Dado un sistema multiprocesador con un númeroelevado de terminales conectados, aumentar el gradode los conmutadores resulta en una disminución enel número de conmutadores y enlaces de red. Puestoque el coste de la red es proporcional al númerode conmutadores, es evidente que el coste se reducemediante el uso de conmutadores de mayor grado.Por otra parte, el consumo total de la red tambiénse reduce considerablemente, ya que es directamenteproporcional al número de conmutadores en la red.Con respecto al rendimiento, por ejemplo, es evidenteque en términos de latencia el uso de conmutadorescon más puertos implica una reducción enel tiempo medio para transferir datos a través de lared. En particular, con menos conmutadores para conectarel mismo número de terminales se reduce elnúmero de saltos y el número de posibles colisionesde paquetes en la red, y por lo tanto el tiempo queellos emplean para llegar a sus destinos. Además, conmenos conmutadores, el tiempo de procesamiento totalde los paquetes en los conmutadores a lo largo desus caminos también se reduce.Por lo tanto, el diseño de conmutadores con un elevadonúmero de puertos es una opción atractiva paramejorar el rendimiento y reducir el coste de la red deinterconexión, especialmente para sistemas multiprocesadorde gran tamaño. Sin embargo, hay algunosproblemas en el diseño de éstos. Uno de ellos está relacionadocon la complejidad de su lógica pues sevuelve más compleja a medida que aumenta el grado[2]. El equilibrio entre el coste y la eficiencia no esfácil de tratar, requiriendo un estudio profundo sobreesta disyuntiva. Por un lado, el tamaño de algunas estructurasdel conmutador crece cuadráticamente conel grado. Por ejemplo, tal es el caso del espacio de losbuffers [3], o de los planificadores [4]. Por otra parte,las políticas tradicionales de control de flujo tambiénse ven afectadas por el grado del conmutador en dosaspectos [5]: el tiempo roundtrip aumenta drásticamente,y las memorias para el almacenamiento decréditos del control de flujo son linealmente dependientesdel roundtrip. Por otro lado, el número depines del chip (pincount) aumentará lentamente enla próxima década según el ITRS [6], y por tanto elnúmero de puertos aumentará ligeramente. Por otraparte, existen dificultades para aplicar algunas técnicascuando el número de puertos es alto. Así, VirtualOutput Queuing (VOQ) [7] es inviable para los conmutadorescon un grado alto. Para superar estos problemas,se han propuesto diferentes soluciones peroJP2011-403

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011en realidad, éstas están posponiendo el problema paralas generaciones venideras de conmutadores.En cualquier caso, las restricciones de tamaño delconmutador están determinadas principalmente porla escala de integración actual y número de pines delchip. Para ir más allá de los límites de la escala de integración,una solución alternativa para la construcciónde conmutadores high-radix es la combinaciónde varios conmutadores de grado menor.La idea principal es implementar conmutadores dem ′ puertos a partir de varios conmutadores más pequeñosde m puertos. Por ejemplo, un conmutador dem ′ puertos compuesto por dos conmutadores idénticosde m puertos (m ′ /2 < m < m ′ ), interconectadosinternamente por medio de m − m ′ /2 puertos,empleando los puertos restantes para las conexionescon el exterior (figura 1a). Nótese que esta estrategiaseguirá siendo válida conforme la tecnología deintegración continúe evolucionando.Una consecuencia destacable es que el conmutadorresultante ya no es homogéneo. Su rendimiento dependeráde la configuración interna. Así, la interconexiónde los conmutadores internos puede convertirseen un cuello de botella si éstos tienen que soportarla mayoría del tráfico manejado por el conmutador.Por lo tanto, es esencial minimizar el impacto de estecuello de botella, de lo contrario la latencia de lared aumentará. Así, el patrón de conexión a nivel deconmutador 1 (SCP) se convierte en una decisión dediseño importante en la construcción de este tipo deconmutadores. Un patrón arbitrario probablementeproducirá una degradación significativa de prestaciones,y por ello, es necesario determinar el patrón másconveniente para poder extraer el mayor rendimientodel conmutador.En este artículo, se describe y evalúa esta alternativapara obtener conmutadores high-radix. Tambiénse discuten cuestiones clave que determinan su rendimiento.De hecho, se mostrará que el SCP y el anchode banda de comunicación entre los conmutadoresinternos son cruciales para el comportamiento delconmutador. Se debe alcanzar un compromiso entreambos aspectos para obtener diseños de conmutadoreseficientes.Este artículo está organizado como sigue: la secciónII repasa brevemente las propuestas existentessobre conmutadores high-radix. Tras ello, en la secciónIII se dan detalles sobre la alternativa propuestapara la construcción de conmutadores high-radix,y en la sección IV se incluyen los resultados de laevaluación realizada. Finalmente, se aportan algunasconclusiones en la sección V.II. Trabajo RelacionadoEn esta sección se revisan las propuestas existentesde conmutadores high-radix que se han centrado1 En adelante, se diferenciará entre patrón de conexión a nivelde red y patrón de conexión a nivel de conmutador. Elprimero es el patrón de interconexión tradicional utilizado enredes basadas en conmutadores (por ejemplo, la permutaciónbutterfly utilizada para conectar los conmutadores en las redesmultietapa); y el segundo patrón hace referencia a cómo lospuertos externos de un conmutador high-radix se mapean enlos puertos de los conmutadores internos.principalmente en resolver problemas con los diseñostradicionales.El conmutador YARC [8] es el conmutador highradixutilizado por el Cray BlackWidow [9]. Trata deincrementar el número de puertos considerando enlacesmás delgados en lugar de enlaces anchos. Los diseñosde conmutadores tradicionales con pocos puertosno pueden adaptarse a conmutadores high-radixporque los diseños tradicionales emplean una organizacióncentralizada que no escala apropiadamente.Por otra parte, Partitioned Crossbar Input Queued[10] es más reciente y propone una organización internade conmutadores high-radix, y trata con una delas restricciones principales en el diseño de conmutadoreshigh-radix: los excesivos requerimientos dememoria.Con respecto a la alternativa de construcción deconmutadores high-radix combinados por dos conmutadoreslow-radix, el conmutador Sun Blade 6048Infiniband QDR Switched Network Express Module(NEM) [11] ya implementa esta estrategia que permiteconectar hasta 12 blades duales en un único shelf.Cada NEM suministra 12 conexiones por cada unode los dos conmutadores InfiniScale IV de 36 puertos.En total, proporciona 24 conexiones para comunicarsecon los dos nodos por cada blade, y utiliza9 puertos para que los dos conmutadores internos secomuniquen entre ellos. Los 30 puertos restantes (15por InfiniScale IV) se usan como enlaces con otrosNEMs, o conmutadores externos.Por otra parte, la topología Dragonfly [12] utilizaun grupo de conmutadores como router virtual paraincrementar el grado efectivo de la red. Lamentablemente,no se aporta ningún análisis formal del tráficoque cruza el router virtual.En resumidas cuentas, y hasta donde tenemos conocimiento,no hay estudios formales publicados sobrela obtención del SCP óptimo.III. Conmutadores High-Radix medianteConmutadores Low-RadixComo se ha mencionado, es posible construir conmutadoreshigh-radix combinando varios conmutadoreslow-radix. Esta estrategia hace posible adelantarsea la tecnología de integración y acortar drásticamenteel time-to-market. Nótese que esta estrategiaseguirá siendo válida conforme la tecnología deintegración continúe evolucionando.Esta estrategia abre una serie de nuevos problemasque deben estudiarse. En las siguientes secciones, serepasan brevemente estos problemas que han sidoanalizados en [13] de un modo más formal. No obstante,en este artículo también se realiza una cuantificaciónexperimental de su influencia en el rendimientode la red.A. Conmutadores CombinadosEn esta sección se formalizan los conmutadorescombinados mediante una definición general. Trasella, la atención se centra en una subclase particularde conmutadores combinados la cual se usará paramostrar las características de estos conmutadores yJP2011-404

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110...m'-1switch-level connection pattern......0m-1m-m'/20m-10...m'-1switch-level connection pattern......0m-1m-m'/20m-10...m'-1switch-level connection pattern......0m-1m-m'/20m-10...m'-1switch-level connection pattern......0m-1m-m'/20m-1(a) Diagrama de bloquesbásico.(b) Situación ideal.(c) Situación mala.(d) Situación más común.Fig. 1: T -switch: diagrama de bloques y posibles situaciones.para evaluar el rendimiento de las redes construidascon estos conmutadores.Definición 1: Un conmutador combinado, o simplementeC-switch, es un conmutador formado porvarios conmutadores (conmutadores internos) máspequeños interconectados. Los puertos ofrecidos porel C-switch se obtienen a partir de los puertos libresde los conmutadores internos después de que se hayaninterconectado entre sí.Esta definición es muy genérica porque no especificani la cantidad de conmutadores internos ni cuáles su grado. Por tanto, cualquier conmutador obtenidopor combinación de otros conmutadores de menorgrado cae dentro de esta categoría. Sin embargo,existen varias dificultades para construir C-switchesque tengan varios conmutadores internos y un gradoalto de heterogeneidad.Para que la latencia interna sea baja, es preferibleutilizar una topología completamente conectada parala interconexión de todos los conmutadores internos.Conforme el número de conmutadores internos crezca,el número de puertos dedicados a las conexionesentre los conmutadores internos crecerá tan rápidamentecomo el número de puertos destinados a la interconexiónexterior decrecerá, de modo que esta formade construir conmutadores high-radix perderá interés.Por tanto, parece razonable que el número deconmutadores internos no sea muy alto.Por otra parte, un diseño interno sencillo del C-switch se puede alcanzar cuando todos los conmutadoresinternos son idénticos. Aunque este aspecto noes tan restrictivo como el número de conmutadoresinternos, es recomendable que todos los conmutadoresinternos tengan el mismo grado.Un caso interesante es aquel donde los C-switchesse construyen a partir de dos conmutadores internosidénticos. Esta subclase de C-switches todavía ofreceun incremento importante en el número de puertosmientras la topología entre los conmutadores internoses la más simple.Definición 2: Un conmutador gemelo, o simplementeT -switch (Twin), es un conmutador formadopor dos conmutadores internos idénticos de menorgrado interconectados entre sí. Los puertos obtenidospor el T -switch se obtienen a partir de los puertoslibres de sus dos conmutadores internos despuésde que éstos se hayan interconectado entre sí.Considerando que los dos conmutadores internos yel T -switch tienen respectivamente m y m ′ puertos,la figura 1a muestra un diagrama básico de bloquesde un T -switch, donde los conmutadores internos senombran como α y β. Aunque los T -switches parecensimples, hay retos significativos en su diseño. Dosde ellos destacan especialmente: (1) obtener el SCPapropiado para la estructura interna del T -switch,(2) determinar el número adecuado de puertos parainterconectar los conmutadores internos α y β.El SCP tiene una influencia importante en la latenciade los paquetes. El tiempo empleado por lospaquetes para cruzar un T -switch será mínimo cuandosólo crucen uno de los conmutadores internos (αo β). La figura 1b muestra esta situación. Las flechasrepresentan los caminos seguidos por los paquetes yel ancho de la flecha es proporcional a la cantidadde caminos. El peor caso es aquel en el que todoslos caminos cruzan los dos conmutadores internos enel T -switch (figura 1c). Obtener el mejor caso no estrivial y requiere un estudio en profundidad dondedeben considerarse varios factores como por ejemplo,la topología de la red, el algoritmo de encaminamientoy el patrón de tráfico. En [13] se muestraformalmente como se obtiene el patrón de conexiónóptimo considerando dichos factores.Respecto al segundo reto, el número de puertosinternos debe ser tal que evite la aparición de uncuello de botella entre los conmutadores internos α yβ. Obviamente, el número de puertos y el SCP tieneuna clara interdependencia.Las situaciones mostradas en las figuras 1b y 1cson apropiadas para mostrar los retos de diseño delos T -switches, pero la situación más común es lamostrada en la figura 1d, donde los casos anteriorescoexisten. Es esta situación, el objetivo principalcuando se diseña un SCP para los T -switches es minimizarel uso de los puertos que interconectan losconmutadores internos.Por lo tanto, puesto que en muchos casos la comunicaciónnecesitará usar ambos conmutadores internos(eso es, un camino que cruce un T -switch pasarápor los conmutadores α y β), se tiene que evitarque la interconexión entre los conmutadores α y β seconvierta en un cuello de botella. Además, se debedeterminar el número de puertos adecuado para cadaconmutador interno. Está claro que cuanto mayor seael número de puertos usados para interconectar losconmutadores internos menor será la probabilidad deque aparezca un cuello de botella en estos puertos.Sin embargo, y tal como se ha mencionado anteriormente,conforme el número de puertos dedicados ainterconectar los conmutadores α y β aumenta, elJP2011-405

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011grado del T -switch disminuye. Se deberá encontrarun compromiso entre ambos aspectos. Nótese que seestá asumiendo que todos los puertos proveen el mismoancho de banda (de otra forma en lugar de usarel número de puertos se debería considerar el anchode banda total agregado).En resumen, la configuración interna de los T -switches se convierte en un aspecto clave en el diseñode esta clase de conmutadores high-radix. Laconfiguración óptima de un T -switch depende de lascondiciones bajo las que esté funcionando, es decir:tipo de red, topología de red, algoritmo de encaminamiento,patrón de tráfico, etc. A continuación seesboza una metodología para obtener la mejor configuraciónde esta clase de conmutadores cuando seusan en redes de interconexión de altas prestaciones.El propósito de esta metodología es determinar elSCP óptimo para los T -switches.B. Metodología para Configurar ConmutadoresCombinadosNuestra metodología para determinar el SCP óptimopara C-switches consiste en los siguientes pasos:Análisis de los caminos en la red. El propósito deeste paso es determinar las conexiones necesariasen cada C-switch a nivel de red y la cantidadde veces que se utilizan todas ellas teniendo encuenta todos los posibles caminos usados por lospaquetes.Clasificación del conmutador. Dependiendo delas características y carga de la red, se puedenobtener una o varias configuraciones diferentespara los C-switches. En este paso, los C-switchesse agrupan según los requisitos de conexión, ypor tanto, se distinguirán varios tipos de C-switches.Como resultado del paso anterior, puede sucederque varias de las posibles conexiones en elC-switch soporten uno o más caminos, y sin embargo,al mismo tiempo existan conexiones quenunca se establezcan.En la topología fat-tree, por ejemplo, los C-switches de diferentes etapas pueden requerirdistintos SCPs, y lo mismo puede ocurrir con losC-switches de la misma etapa. Cuando se dé unpatrón de tráfico simple y se emplee un algoritmode encaminamiento que balancee la carga,es probable que todos los C-switches de la redpuedan configurarse con el mismo SCP.Configuración del conmutador. A partir de losrequisitos de conexión y dado un número de conmutadoresinternos de un C-switch, este últimopaso consiste en encontrar el SCP óptimo paracada tipo de C-switch, intentando minimizar eluso de los enlaces que interconectan los conmutadoresinternos.En [13] se ha aplicado dicha metodología a un casoparticular: topología k-ary n-tree, algoritmo de encaminamientodeterminista, y patrón de tráfico uniforme.Como resultado, se ha obtenido la configuraciónóptima para todos sus C-switches.IV. Evaluación de RendimientoEn esta sección se evalúa el potencial de los C-switches estudiando los T -switches. La evaluación seha realizado por simulación y se ha centrado en losdos aspectos clave que se discutieron anteriormente:el SCP, y el ancho de banda disponible entre losconmutadores internos.En las siguientes subsecciones, en primer lugar sedescribe el modelo de red simulado, y a continuaciónse establecen las diferentes configuraciones de red ylos SCPs empleados en las simulaciones. Finalmente,se aportan y analizan en detalle los resultados de lassimulaciones obtenidos.A. Modelo SimuladoPara llevar a cabo la evaluación se ha utilizadoun simulador detallado conducido por eventos que escapaz de modelar distintos tipos de redes basadas enconmutadores, y en particular, T -switches.Se ha elegido la topología k-ary n-tree que es unasubclase particular de los fat-trees. Se ha seleccionadoporque actualmente es una de las más usadasentre los supercomputadores del Top500.Se ha implementado el algoritmo deterministaDESTRO [14] a nivel de red. Se ha considerado interesanteeste algoritmo por sus características: unaimplementación en hardware sencilla, tiempo de encaminamientoreducido y reparto de paquetes en orden.Además, DESTRO es capaz de balancear uniformementeel tráfico en la red y de reducir la contenciónen la red. Como carga de red se ha asumidoun patrón de tráfico uniforme porque es uno de lospatrones clásicos utilizados en este tipo de evaluaciones.Con respecto a los conmutadores, según lo mencionadoen la sección III, se han simulado T -switches.En este estudio de evaluación, debido a los fuertes requisitostemporales sólo se han simulado T -switchesde 32 puertos. Estos conmutadores se forman con dosconmutadores internos de 24 puertos cada uno, de loscuales 16 puertos se utilizan para la comunicación delT -switch con el exterior y 8 puertos se destinan parala comunicación de los dos conmutadores internos(m = 24 y m ′ = 32 en la figura 1). Se han consideradoconmutadores internos de 24 puertos porqueestán disponibles en el mercado (por ejemplo, el chipInfiniScale III [15]). No obstante, actualmente la herramientade simulación se está mejorando para quesoporte conmutadores de mayor grado.Se han evaluado redes de distinto tamaño. Debidoa la limitación de espacio, aquí sólo se han incluidolos resultados para las redes de 4096 terminales.Otras suposiciones son que los conmutadores soportanvirtual output queuing a nivel de conmutador;todos los enlaces son bidireccionales y tienen unancho de banda de 1 GByte/s; existe un planificadorround-robin por puerto de salida; el tamaño de paquetees de 2 KBytes; todos los buffers tienen unacapacidad para almacenar 64 paquetes, entre otros.JP2011-406

..................Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110k/2-1k/2k-1(a) Patrón óptimo.k3k/2-13k/22k-10k-1k2k-1(b) Patrón arbitrario y/omaloFig. 2: Patrones de conexión a nivel de conmutador.B. Casos de EstudioA fin de evaluar la viabilidad y potencial de losconmutadores combinados, se ha estimado el rendimientode la red descrita en la sección IV-A, considerandoT -switches con el SCP que se ha demostradosiguiendo la metodología propuesta en la secciónIII-B que es el óptimo 2 para los T -switches bajolas condiciones de simulación (esta red se etiqueta enlas figuras como O-BMIN). Tras ello, el rendimientode esta red se compara con el rendimiento alcanzadopor una red equivalente que emplea conmutadores enun chip del mismo grado que los T -switches. Dichared será referenciada como U-BMIN y representa unacota superior de rendimiento.Además, para poner de manifiesto la importanciadel SCP también se ha considerado otro caso de estudioque representa a un patrón arbitrario y/o malo,referenciado como B-BMIN en la figuras. Las redesde los casos O-BMIN y B-BMIN usan T -switchescon los patrones de conexión a nivel de conmutadorOSCP y BSCP, respectivamente. Ambos patronespueden verse en la figura 2 para un T -switch arbitrariode k×k puertos y r puertos internos entre losconmutadores internos. También se incluye un cuartocaso de estudio: una red (L-BMIN) que conecta lamisma cantidad de terminales, pero con conmutadoresen chip de menor grado que también son viablescon la escala de integración actual.Otro propósito de esta evaluación es saber si ladiferencia de rendimiento entre los casos de estudioes significativa, y en caso afirmativo, medirla.Obsérvese que aunque en todos los casos la redinterconecta 4096 terminales, los casos U-BMIN, O-BMIN y B-BMIN, son redes 16-ary 3-tree formadaspor un total de 768 conmutadores de 32 puertos. Sinembargo, la red del caso L-BMIN es una 8-ary 4-treecon 2048 conmutadores de 16 puertos cada uno.C. Resultados de SimulaciónSe han realizado dos tests distintos. El primero sirvepara medir la diferencia de rendimiento entre losdistintos casos de estudio mencionados anteriormente.Recuérdese que el objetivo global de esta evaluaciónes identificar problemas potenciales que limitanla eficiencia de los T -switches (y en general de losC-switches).La figura 3 muestra los valores medios de la productividady latencia con los intervalos de confianzaal 95 % de 30 simulaciones para cada nivel de carga.Se pueden observar algunos detalles:2 Debido a la falta de espacio, aquí no se han incluido lascorrespondientes demostraciones, que está disponibles en [13].Normalized Throughput (%)JP2011-407100806040U−BMIN20O−BMINB−BMINL−BMIN00 0.2 0.4 0.6 0.8 1Normalized Load(a) Productividad.Network Latency (cycles)10000800060004000U−BMIN2000O−BMINB−BMINL−BMIN00 0.2 0.4 0.6 0.8 1Normalized Load(b) Latencia.Fig. 3: Resultados del primer test para todos los casosde estudio.Cuando se ha considerado el SCP óptimo, lared basada en T -switches (O-BMIN) es capazde ofrecer un rendimiento similar al que ofrecela red (U-BMIN) cuyos conmutadores high-radixse integran en un único chip. Por tanto, los conmutadorescombinados se confirman como unabuena alternativa para la construcción de conmutadoreshigh-radix.Sin embargo, la red B-BMIN alcanza el puntode saturación con sólo el 40 % de la carga. Elrendimiento dispar obtenido es debido al hechode que los T -switches configurados con el patrónBSCP producen que la longitud del camino dela mayoría de los paquetes se incremente en unsalto extra. De tal modo, también se confirmaque es esencial la determinación en cada casodel SCP óptimo para cada tipo de conmutadorcombinado.Cuando se comparan los casos U-BMIN y L-BMIN, se ha observado que la latencia en el casoL-BMIN es superior a la latencia en el casoU-BMIN (por ejemplo, un 14 % al 50 % de carga).Este incremento es causado porque la redL-BMIN tiene una o más etapas que la red U-BMIN, por lo que los caminos son más largos.Además, se puede ver que el número de puertosdestinados para la interconexión entre los conmutadoresinternos α y β no producen ningúntipo de degradación en el rendimiento de la red.En el primer test se han empleado 8 puertos decada conmutador interno para la interconexión entreellos. Sin embargo, se necesita asignar un número depuertos suficiente para disponen de ancho de bandaentre los conmutadores internos, pero al mismo tiempoevitar sobredimensionar esta cantidad. De no lograrse,es probable que se produzca una degradaciónde prestaciones en la comunicación entre el interiory el exterior del T -switch. Para encontrar el mismoóptimo de puertos, se ha realizado un segundo testque estima cómo dicha cantidad de puertos influyeen el rendimiento global de la red.En la figura 4 se pueden ver los resultados de productividadde la red cuando la carga de la red está al80 % para todos los casos de estudio excepto paraL-BMIN. A fin de realizar el segundo test, se ha configuradoel simulador para que varíe el número depuertos entre los conmutadores internos entre 1 y16, mientras que el número de puertos al exterior semantiene constante.De modo similar al primer test, se pueden resaltar

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Normalized Throughput (%)10080604020U−BMINO−BMIN0B−BMIN0 2 4 6 8 10 12 14 16Number of Internal PortsFig. 4: Productividad de la red en función del númerode puertos entre los conmutadores internos.algunos detalles importantes en este segundo test:Se puede determinar el número mínimo de puertosentre los conmutadores internos para evitarla creación de un cuello de botella entre dichosconmutadores. Se puede observar que el SCP esel factor clave que influye en el rendimiento globaly en cambio, el número concreto de puertosno es tan relevante.Cuando el número de puertos entre los conmutadoresinternos pasa de 4, O-BMIN alcanza elmismo rendimiento que U-BMIN. Sin embargo,cuando se considera B-BMIN, el cuello de botellano desaparece hasta que el número de puertosentre los conmutadores internos es igual a laaridad del T -switch (k = 16).Es importante remarcar que en los resultadosmostrados en la figura 3 el número de puertosentre los conmutadores internos es 8, pero cuandoel T -switch se configura con el SCP óptimosólo son necesarios 4 puertos para alcanzar lasprestaciones máximas. En tal caso, estos 4 puertosextra podrían emplearse en la comunicacióncon el exterior en lugar de hacerlo para la comunicaciónentre conmutadores internos, y portanto, el grado del T -switch se incrementará deun modo más efectivo.V. ConclusionesEn este artículo se ha descrito una alternativa parala construcción de conmutadores high-radix consistenteen combinar varios conmutadores low-radix.Aunque aparentemente es simple, esta estrategiaplantea unos retos de diseño claves a fin de que estosconmutadores high-radix alcancen su mejor rendimiento.En este sentido, se han discutido aspectosimportantes relacionados con la estructura internade esta clase de conmutadores.Los puertos ofrecidos por estos conmutadores seobtienen a partir de los puertos de sus conmutadoresinternos con los que se construye el conmutador.Las conexiones internas entre ambos grupos de puertosdetermina el patrón de conexión que se convierteen crucial para el comportamiento del conmutadorhigh-radix. Por otra parte, también es esencial poderdeterminar la interconexión más apropiada paraevitar la aparición de un cuello de botella entre losconmutadores internos.Para comprobar el potencial de esta alternativase han evaluado varias redes bajo ciertas condicionespara medir su rendimiento. Son redes construidascon conmutadores de un único chip y también sehan considerado redes con T -switches. Los resultadosde las redes con T -switches y el patrón de conexiónóptimo, se han visto que son idénticos que las redescon conmutadores construidos con conmutadores enun único chip. Además, los resultados han puesto demanifiesto la importancia de seleccionar un númeroadecuado de puertos para la interconexión entre losconmutadores internos.AgradecimientosEste trabajo ha sido cofinanciado por el MEC yMICINN de España, fondos FEDER de la ComisiónEuropea, con subvenciones “Consolider Ingenio-2010CSD2006-00046”y“TIN2009-14475-C04”; y la Juntade Comunidades de Castilla-La Mancha con proyectos“PEII 11-0229-2343”y“POII 10-0289-3724”.Referencias[1] J.J. Dongarra, “TOP500 Supercomputer Sites,” 10/2010.[2] H. Wang, L.-S. Peh, and S. Malik, “Power-driven design ofrouter microarchitectures in on-chip networks,” in Proc.of the 36th annual IEEE/ACM International Symposiumon Microarchitecture, Washington, DC, USA, 2003[3] M. Gusat, F. Abel, F. Gramsamer, et al., “Stability degreeof switches with finite buffers and non-negligible roundtriptime,” International Conference on Computer, Communicationand Networking, vol. 27, no. 5–6, 2003.[4] C. Minkenberg, F. Abel, P. Muller, et al. “Control pathimplementation for a low-latency optical HPC switch,” inProc. of the 13th Symposium on High Performance Interconnects,Washington, DC, USA, 2005, HOTI’05, pp.29–35, IEEE Computer Society.[5] C. Minkenberg and M. Gusat, “Speculative flow control forhigh-radix datacenter interconnect routers,” Parallel andDistributed Processing Symposium, International, vol. 0,pp. 1–10, 2007.[6] “International Technology Roadmap for Semiconductors.2010,” www.itrs.net/Links/2010ITRS/Home2010.htm.[7] W.J. Dally, “Virtual-channel flow control,” IEEE Transactionson Parallel and Distributed Systems, vol. 3, no.2, pp. 194 –205, mar 1992.[8] J. Kim, W.J. Dally, B. Towles, and A.K. Gupta, “Microarchitectureof a high-radix router,” SIGARCH Comput.Archit. News, vol. 33, no. 2, pp. 420–431, 2005.[9] S. Scott, D. Abts, J. Kim, and W.J. Dally, “The BlackWidowhigh-radix Clos network,” SIGARCH Comput. Archit.News, vol. 34, no. 2, pp. 16–28, 2006.[10] G. Mora, J. Flich, J. Duato, et al., “Towards an efficientswitch architecture for high-radix switches,” in Proc.of the 2006 ACM/IEEE symposium on Architecture fornetworking and communications systems, New York, NY,USA, 2006, pp. 11–20, ACM.[11] “Sun datacenter Infiniband switch 36, Sun datacenter Infinibandswitch 72, Sun datacenter Infiniband switch 648:Architecture and deployment,” April 2010.[12] J. Kim, W.J. Dally, S. Scott, and D. Abts, “Technologydriven,highly-scalable Dragonfly topology,” in ISCA ’08:Proc. of the 35th Annual International Symposium onComputer Architecture, Washington, DC, USA, 2008, pp.77–88, IEEE Computer Society.[13] J.A. Villar, F.J. Andújar, F.J. Alfaro, J.L. Sánchez,and J. Duato, “An alternative for building highradixswitches: Formalization and configuration methodology,”Tech. Rep. DIAB-11-02-1, Dpt. of ComputingSystems. University of Castilla-La Mancha,2011, www.dsi.uclm.es/descargas/thecnicalreports/DIAB-11-02-1/diab-11-02-1.pdf.[14] C. Gómez, F. Gilabert, M.E. Gómez, P. Lopez, and J.Duato, “Deterministic versus adaptive routing in fattrees,”Los Alamitos, CA, USA, 2007, IEEE ComputerSociety.[15] Mellanox Technologies Inc., “Infiniscale III 3rd generationinfiniband switch architecture,” www.mellanox.com/related-docs/prod_silicon/PB_InfiniScale_III.pdf.JP2011-408

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Combinando diferentes enfoques para elcontrol de congestión en redes deinterconexión de altas prestacionesJesus Escudero-Sahuquillo 1 , Ernst Gunnar Gran 2 , Pedro Javier Garcia 1 , Jose Flich 3 ,Tor Skeie 2 , Olav Lysne 2 , Francisco Jose Quiles 1 and Jose Duato 31 Dept. Sistemas Informáticos, Universidad de Castilla-La Mancha. E-mail:{jesus.escudero, pedrojavier.garcia, francisco.quiles}@uclm.es2 Simula Research Laboratory. Oslo (Noruega). E-mail:{ernstgr, tskeie, olav.lysne}@simula.no3 Dept. de Informática de Sistemas y Computadores, Universitat Politècnica de València. E-mail:{jflich,jduato}@gap.upv.esResumen— Muchos de los mecanismos más populares para el cuando el paquete en cabeza de una cola está detenidocontrol de congestión en redes de interconexión de altas prestacionesse ajustan a uno de dos enfoques básicos: la limitacióny bloquea el avance de los paquetes situados detrás de el.de inyección en las fuentes generadoras de tráfico en la red Nótese que esta situación afecta con mayor gravedad a loso el aislamiento explícito de los flujos congestionados en colas flujos de paquetes que van dirigidos hacia otros puertosdinámicamente asignadas para ellos. Ambos enfoques presentan inconvenientes,si bien éstos son diferentes en cuanto a su naturaleza yde salida distintos al solicitado por el paquete en cabezade la cola, ya que estos otros puertos pueden estar libres.su repercusión en las prestaciones de la red. En este artículo se presentauna nueva propuesta que combina la limitación de inyección Estos flujos “no congestionados” se convierten en flujosy el aislamiento explícito de flujos congestionados. Dicha propuesta “víctimas” de la congestión [3].es capaz de extraer lo mejor de ambos enfoques, dando como resultadouna reacción rápida ante los efectos efectos negativos deEl control de la congestión (CC) es, en definitiva, unala congestión y una mayor escalabilidad. Además, esta propuesta tarea clave en el diseño de las redes de interconexión.minimiza los problemas de los enfoques independientes.Aunque en los últimos tiempos se han propuesto variosPalabras clave— Redes de Interconexión, Encaminamiento Distribuido,HoL-blocking, Control de Congestión.gestión (ver sección II), hay dos de ellos que han tenidoenfoques para resolver los problemas asociados a la con-I.una especial aceptación. Por un lado, destaca la limitaciónde inyección de las fuentes que generan la con-INTRODUCCIÓNEN las redes de interconexión de altas prestaciones actualesla congestión puede disminuir el rendimiento de red basadas en la especificación InfiniBand [4]. Porgestión, que actualmente está presente en las tecnologíasglobal de la red, y por tanto el del sistema que interconectadicha red, si no se toman las medidas apropiadas.En este sentido, la congestión es simplemente el resultadode una carga de tráfico dentro de la red que supera prolongadamenteotro lado, existe otro enfoque basado en el aislamientoexplícito de flujos congestionados, usando para ello recursosadicionales asignados dinámicamente para almacenardichos flujos [5], [6].la capacidad de los enlaces y buffers en ciertos En concreto, la limitación de inyección consiste en de-puntos (Hot-Spots). Además, las redes de interconexión tectar un punto de congestión e informar a las fuentesde altas prestaciones actuales requieren alta productividady latencias mínimas en la transmisión de paquetes, su tasa de inyección. De esta forma las fuentes elim-que contribuyen a generar ese punto para que reduzcanpor lo que no se permite el descarte y retransmisión de los inan el árbol de congestión, así como el HoL-blockingmismos. A esto hay que unir que los diseños de red actualesreducen el número de componentes y recursos para Sin embargo, entre la detección de la congestión y el mo-que surge por la presencia de dicho árbol de congestión.reducir coste y consumo, por lo que nos encontramos con mento en que las fuentes comienzan a reducir el árbolque la red alcanza su punto de saturación con una carga transcurre un intervalo de tiempo que podría ser muy elevado,ya que para cuando la tasa de inyección se reduzcade tráfico menor. En este contexto, la congestión aparecey se propaga dentro de la red con mucha más facilidad y, la congestión puede haber remitido, o bien cuando dichasi no se toman las medidas oportunas, las prestaciones de tasa se recupere, la congestión a vuelto a surgir. Estala red de interconexión se verán seriamente afectadas. situación, denominada “efecto sierra” como se describeEspecíficamente, dentro de un conmutador la congestiónaparece cuando varios paquetes solicitan elmismo puerto de salida. En general, mientras uno de estospaquetes cruza hacia dicho puerto de salida, los otrosmás adelante, se produce por la lenta reacción ante lacongestión y ocasiona que el HoL-blocking y sus efectosnegativos no desaparezcan por completo de la red yafecten al rendimiento de la misma.deben esperar en sus respectivas colas. Esta situación de Por otro lado, el enfoque basado en aislar“contención”, si se prolonga en el tiempo, produce quelas colas con paquetes “detenidos” se llenen rápidamente,generándose así la “congestión”. En las redes sin descartede paquetes (como es el caso de la mayoría de tecnologíasde red de interconexión actuales), el control de flujoimpide el envío de paquetes hacia conmutadores con susexplícitamente los flujos congestionados no eliminael árbol de congestión en sí, sino que detecta la congestióny, de forma instantánea, aisla en colas especialesasignadas dinámicamente los flujos congestionados (losárboles de congestión), para que no interfieran con losflujos de paquetes no congestionados. De esta maneracolas llenas. Por tanto, la congestión se propaga desde se elimina de forma sustancial el HoL-blocking. Esteeste conmutador “raíz” hacia las fuentes que están enviandopaquetes hacia dicho conmutador, formando losllamados “árboles de congestión” [1].La presencia de los árboles de congestión introduceen la red el principal efecto negativo de la congestión:el Head-Of-Line (HoL) blocking, que puede limitar elrendimiento de un conmutador hasta en un 58% de suenfoque reacciona de forma instantánea a la apariciónde la congestión, pero necesita un número suficiente decolas especiales en cada puerto, para aislar todos losposibles flujos congestionados. Si dicho número de flujossobrepasa el número de colas disponibles en ese puerto,no todos podrán ser aislados y generarán HoL-blocking,que afectará al rendimiento de la red de interconexión.valor máximo [2]. En general, el HoL-blocking aparece EnJP2011-409este artículo se describe CCFIT (Combined

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Congested-Flow Isolation and Throttling) [7], unatécnica de CC basada en la combinación de los enfoquesmencionados que ofrece sus ventajas y minimiza sus inconvenientes.Por un lado, el aislamiento de los flujoscongestionados en colas especiales reacciona de formainmediata a la congestión y elimina el HoL-blocking, inclusoantes de que los nodos fuente sepan que hay congestióndentro de la red. Por otro lado, la limitaciónde inyección elimina el árbol de congestión y reduce laposibilidad de que aparezcan muchas ramas de árbolesde congestión distintos en un mismo puerto. Por tanto,se reduce la posibilidad de que el número de colas especialespor puerto sea insuficiente. CCFIT mejora elrendimiento de los dos enfoques en los que está basado,y es una técnica eficiente y escalable al mismo tiempo.El resto de este artículo se organiza como sigue: lasección II describe las diferentes propuestas en el campodel control de congestión (CC); la sección III describela nueva propuesta CCFIT y en la sección IV se evalúansus prestaciones. Finalmente, la sección V muestra lasconclusiones de este trabajo.II. TRABAJOS RELACIONADOSEl control de congestión (CC) basado en la inhibiciónde la inyección es un enfoque bastante popular cuya ideabásica, como se ha descrito, es detectar la congestión queaparece en la red dentro de los propios conmutadores, einformar a los nodos fuente para que reduzcan su tasa deinyección de tráfico. Esta filosofía de “bucle cerrado” esbásica para muchas de las técnicas propuestas, las cuales,por otro lado, también presentan diferencias entre ellas.Por ejemplo, las notificaciones de congestión se puedenenviar a todos los nodos origen [8] o sólo a los nodos quegeneran la congestión [9]. Otros mecanismos propuestosnotifican la congestión sólo a los nodos locales directamenteconectados al conmutador donde se detecta la congestión[10]. La manera de notificar a los nodos fuente deesta situación y la política de reacción de las fuentes anteesas notificaciones varía según las técnicas. Por ejemplo,hay estrategias que reducen la inyección cuando sereciben las notificaciones de congestión y la aumentanconforme ésta va desapareciendo [11], [12].En este sentido, la limitación de inyección de la nuevapropuesta CCFIT se inspira en el mecanismo propuestoen la especificación InfiniBand (IB) [4] (evaluado en [13],[14]). En concreto, IB define dos bits en la cabecera delpaquete para notificar la congestión. Si un paquete contribuyea la congestión, el bit FECN (Forward ExplicitCongestion Notification) se activa en su cabecera. Estebit permanece activo hasta que el paquete alcanza su destino.Cuando un destino recibe un paquete “marcado”con el bit FECN, genera una notificación de congestióncuya cabecera contiene el bit BECN (Backward ExplicitCongestion Notification) activo. Cualquier nodo fuenteque recibe un paquete con el bit BECN activo reducirá sutasa de inyección de tráfico según el algoritmo establecidoa tal efecto, con el objetivo de reducir de la maneramás rápida posible el árbol de congestión.Aunque este mecanismo de CC de IB es capaz de eliminarde la red el árbol de congestión, presenta un serioproblema: el retardo entre la detección de la congestión yla reacción de las fuentes para reducir la tasa de inyecciónocasiona que el mecanismo no funcione de forma inmediata.Por tanto, la reducción de la inyección puede estarbasada en información obsoleta del estado de la red.Un enfoque distinto al anterior se basa en eliminar elHoL-blocking sin eliminar el árbol de congestión, medianteel aislamiento de los flujos congestionados, de maneraque, si estos no interfieren con los flujos no congestionados,la congestión no será perjudicial [1].Existe un gran número de técnicas que atacan directamenteal HoL-blocking. Muchas de ellas establecen colasen cada puerto del conmutador, para separar paquetes dediferentes flujos. Por ejemplo, una técnica muy conocidadentro de este campo es Virtual Output Queues (VOQs),bien a nivel de conmutador (VOQsw) [15], o bien a nivelde red (VOQnet) [16]. Mientras la primera versión requieretantas colas por puerto como puertos tenga el conmutador,la segunda establece tantas colas como nodosdestino haya en la red. En este sentido, VOQnet eliminacompletamente el HoL-blocking, ya que en cada puertoguarda todos los paquetes dirigidos a un mismo destinodentro de una misma cola y, por tanto, los paquetes dirigidosa destinos distintos no interfieren entre sí. Nóteseque VOQnet no escala con el tamaño de la red. Porotro lado, VOQsw requiere un número reducido de colasy guarda un paquete en una cola u otra en función delpuerto de salida solicitado. Aunque VOQsw es escalablecon el tamaño de la red y elimina el HoL-blocking dentrodel conmutador donde surge la congestión, el problemasurge cuando esa congestión se propaga hacia otros conmutadores.Por tanto, VOQsw reduce sólo parcialmenteel HoL-blocking, al igual que otras técnicas similarescomo Dynamically Allocated Multi-queues (DAMQs)[17], Destination-Based Buffer Management (DBBM)[18], Dynamic Switch Buffer Management (DSBM) [19]y Output-Based Queue-Assignment (OBQA) [20].Todas estas técnicas no identifican explícitamente losflujos de paquetes congestionados, sino que separan “ciegamente”paquetes de flujos diferentes tanto como esposible en función del número de colas del que disponenen cada puerto. Es decir los flujos congestionadostienen la misma probabilidad de ser aislados que el restode flujos y, por tanto, la efectividad en eliminar el HoLblockingdepende del número de colas por puerto. Por elcontrario, existen otras técnicas que detectan e identificande forma explícita los flujos de paquetes congestionados,para aislarlos en colas especiales que se asignan de formadinámica a estos flujos. Este aislamiento beneficia a losflujos no congestionados que no sufrirán HoL-blockingde forma significativa, ya que no interfieren con los flujoscongestionados. Además, puesto que los flujos nocongestionados pueden compartir colas sin sufrir HoLblockingrelevante, se reduce el número de colas necesariaspara eliminar el HoL-blocking. Esta es la estrategiabásica seguida por Regional Explicit Congestion Notification(RECN) [5], [3], Regional Explicit CongestionNotification-Input Queued (RECN-IQ) [21] and Flow-Based Implicit Congestion Notification (FBICM) [6].Aunque estas técnicas son bastante efectivas presentanciertos inconvenientes. El más importante es que elnúmero de colas especiales por puerto para los flujos congestionadoses limitado y puede no ser suficiente paramanejar todas las ramas de los diferentes árboles de congestiónque aparecen en un puerto determinado bajo ciertascondiciones de tráfico. Evidentemente, estas situacionesno se dan de forma general en todos los puertos dela red. Sin embargo, una rama de un árbol de congestiónque no sea aislada puede generar HoL-blocking y lastrarel rendimiento global de la red.En conclusión, nótese que dos de los enfoques máspopulares para el CC (limitación de inyección y aislamientode flujos congestionados) presentan inconve-JP2011-410

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Organización de los Puertos de Entrada con CCFIT.nientes, como ya se ha mencionado. En este artículo sedescribe y evalúa CCFIT, que combina ambos enfoquesy consigue minimizar sus respectivos problemas.III. DESCRIPCIÓN DE LA TÉCNICA CCFITCCFIT se basa en el mecanismo de inhibición de inyecciónespecificado en IB y en FBICM, una de lastécnicas que aislan explícitamente los flujos congestionados.Por tanto, se supone el uso de los bits FECN y BECNen los paquetes, el uso de encaminamiento distribuidoy el uso de conmutadores IQ (Input-Queued), donde lasmemorias existen sólo en los puertos de entrada.A. Arquitectura del ConmutadorComo, por un lado, CCFIT incluye la limitación de inyeccióny, por otro, aisla flujos congestionados, los conmutadoresCCFIT son responsables tanto de detectar lacongestión y notificarla a los nodos fuente, como de aislarlos paquetes congestionados lo más rápidamente posible.Básicamente, al detectar la congestión, el conmutadordebe establecer el puerto correspondiente como congestionadoy activar el bit FECN de los paquetes que pasanpor él. Además, el conmutador debe asignar en los puertosde entrada una colas aparte (CFQs) donde guardar lospaquetes dirigidos al puerto de salida congestionado.Al igual que FBICM, CCFIT no limita el número depuertos por conmutador, y cada memoria RAM de unpuerto de entrada se organiza según el diagrama de lafig. 1, dividiéndose en dos tipos de colas: una cola NFQ(Normal Flow Queue) para almacenar los paquetes nocongestionados, y un conjunto reducido de colas CFQ(Congested-Flow Queues) para los congestionados.Al igual que FBICM, CCFIT usa memorias CAM(Content-Addressable Memory), situadas en los puertosde entrada y en los de salida, que se encargan de almacenarla información de los flujos congestionados y el estadode las CFQs. Nótese que cada línea de una CAMde un puerto se asocia con una CFQ de dicho puerto.Aunque los puertos de salida no tienen ni NFQ ni CFQs,CCFIT necesita una memoria CAM para propagar la informaciónde congestión desde el puerto de entrada delconmutador vecino al que está conectado ese puerto desalida hasta los puertos de entrada del conmutador local.En referencia al arbitraje de los puertos de entrada,CCFIT usa iSlip [22], un algoritmo de tipo Round-Robin(RR) que consigue un arbitraje igualitario dentro del conmutador(como se demuestra en [14]). En concreto, unpuerto de entrada que solicita un puerto de salida, noobtendrá el acceso hasta ese mismo puerto hasta que todoslos demás puertos de entrada que solicitan el mismopuerto de salida, hayan sido atendidos. Hay otros detallesacerca de la igualdad y equidad en la planificación que semejoran con iSlip y el mecanismo de inhibición de inyecciónen el que se basa CCFIT ([7]).B. Arquitectura de los Nodos de ProcesamientoFig. 2. Arquitectura de los Nodos de Procesamiento.activo debe, a la mayor brevedad, notificar al nodo emisorde ese paquete acerca de la situación de congestión, paraque ajuste lo antes posible su tasa de inyección. Paraello, devuelve un paquete de notificación de la congestión(CNP) con el bit BECN activo 1 . La fig. 2 muestra la arquitecturade los nodos de procesamiento que proponeCCFIT, que permite generar el tráfico, emitir/recibir losBECNs y reducir/ajustar la tasa de inyección de tráfico.De ahora en adelante nos referiremos a los nodos deprocesamiento como IAs (Input Adapters).En la figura se observa que los IAs tienen tantas colasde admisión de paquetes generados (AdVOQs) comonodos hay en la red. No hay HoL-blocking en la generación,ya que cada cola AdVOQ i guarda sólo los paquetesdirigidos hacia el destino i. Como en los puertosde entrada de los conmutadores, los IAs tienen unamemoria RAM de salida dividida en colas (una NFQ yvarias CFQs) y una memoria CAM. Cada IA incluye estructurasespecíficas para la limitación de la inyección,según el mecanismo de CC de IB. En concreto, la tasa deinyección de un flujo congestionado se reduce aplicandoun retardo IRD (Injection Rate Delay) entre dos paquetesconsecutivos. Cada IA guarda una lista de posiblesIRDs en una tabla llamada CCT (Congestion Control table),y cada AdVOQ i guarda un índice (CCTI) a esa tabla(IRD i = CCT [CCT I[i]]). Los valores de la CCT serellenan con el criterio de que, a mayor índice, mayor esel retardo de inyección, y mayor debe ser la inhibición dela tasa de inyección de los paquetes de esa AdVOQ i . Alrecibirse un BECN, el CCTI aumenta en tantas unidadescomo establece el parámetro CCTI Increase. Por tanto,el IRD i aumenta si se reciben varios BECNs. Por el contrario,el CCTI se reduce en una unidad cuando un temporizador(configurado con el parámetro CCTI Timer) expira.Por tanto, al no recibirse BECNs, el IRD de esaAdVOQ i disminuye. Finalmente, la tabla LTI (Last Timeof Injection) se encarga de guardar el instante de tiempoen el que una AdVOQ i inyectó un paquete por última vez.Mediante una política RR, el árbitro del IA inspeccionalas AdVOQs, y usa el LTI, junto con el IRD, para decidirsi el paquete en cabeza de una AdVOQ i se puede inyectaro no. Además, dicho árbitro utiliza la CAM del IA parasaber si un árbol de congestión concreto llega hasta dichoIA, en cuyo caso no se inyectan paquetes. De esta forma,la tasa de inyección de los flujos congestionados se reducecuando hay congestión y se incrementa cuando éstadesaparece. En la Sección III-C se muestra un ejemplodel comportamiento de CCFIT en los IAs.Al igual que la inhibición de inyección tipo IB, un nodo 1 El paquete BECN tiene prioridad en los conmutadores a la hora dede procesamiento que recibe un paquete con el bit FECN ser transmitido, y sólo se puede guardar en las NFQs.JP2011-411

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011C. Funcionamiento de CCFITLa fig. 3 muestra un ejemplo del funcionamiento deCCFIT. En el conmutador B (Evento #2) se detecta unpunto de congestión al sobrepasar la NFQ el umbral dedetección, por lo que se asigna una CFQ para aislar elflujo de paquetes dirigidos a ese punto y una línea CAMque se usa para al almacenar la localización de ese punto(según el destino del paquete en cabeza de la NFQ) 2 .CCFIT utiliza el mismo mecanismo de postprocesamiento(Evento #3) que FBICM, el cual detectasi un paquete en la cabeza de la NFQ está congestionadoy, en ese caso, lo mueve hacia su CFQ correspondiente.En caso contrario, el paquete se mantiene en la NFQ,desde donde será encaminado hacia el puerto de salidasolicitado. El post-procesamiento deja en la cabeza dela NFQ los paquetes no congestionados, eliminando asíel HoL-blocking. Además, este mecanismo decide quécola, bien NFQ o bien CFQs, puede transmitir el paquetehacia el puerto de salida solicitado.Por otra parte, el post-procesamiento se encarga de decidirsi un puerto de salida debe entrar en el estado de“congestionado” y así marcar paquetes 3 . Para cada CFQalojada en la raíz del árbol de congestión (es decir, a unsalto del puerto de salida congestionado), CCFIT mira elnivel de ocupación de la CFQ y, si éste sobrepasa ciertoumbral (“High”), el puerto de salida correspondiente seactiva como congestionado, y éste comenzará a marcarpaquetes (activando el bit FECN). Sin embargo, si elpuerto hubiese entrado en ese estado previamente, CCFITaumenta su contador de puertos de entrada que apuntanal puerto congestionado. En cambio, si el nivel de ocupaciónde una cola decrece hasta cierto umbral (“Low”),dicho contador disminuye en una unidad. Cuando estecontador llega a cero, el puerto deja de estar en estado“congestionado” y, por tanto, de marcar paquetes. Nóteseque, si una cola está a dos o más saltos del punto congestionado(e.g. fig. 3, CFQ 0 del P2 en el conmutador A),su puerto de salida asociado no entrará en el estado congestionadoy no se marcarán paquetes en dicho puerto.Para la propagación de la información de congestión,CCFIT sigue la misma política que FBICM, basada en uncontrol de flujo Stop/Go (Eventos #4 y #5) entre las CFQde diferentes conmutadores, a lo largo del camino quesigue una rama de un árbol de congestión. Así, CCFITaisla los flujos congestionados y elimina el HoL-blockinggenerado por los árboles de congestión. Como FBICM,cuando la congestión remite, CCFIT desaloja los recursosasignados de forma dinámica y distribuida (Evento #6).La fig. 4 muestra un ejemplo del comportamiento delos IAs que usan CCFIT. En concreto, un IA está conectadocon el conmutador A, que acaba de detectar unasituación de congestión (Eventos del #1 al #4), similar ala de la figura anterior, pero la información de congestiónse propaga desde el conmutador A hacia un IA.Si se activa el bit FECN de los paquetes que pasanpor el puerto congestionado P3 del conmutador A, el IArecibirá notificaciones BECN (Evento #6). Al recibir unBECN, CCFIT calcula la AdVOQ i que envía paquetescongestionados hacia el destino generador del BECN (denotadopor i), e incrementa el CCTI[i] en una unidad.Esto produce que el IRD i se incremente para la AdVOQ i2 Al igual que FBICM, CCFIT sólo guarda en cada línea CAM el destinodel paquete como información de congestión. Se puede consultarinformación adicional acerca de las líneas CAM de FBICM en [6], [23].3 El bit FECN se activará o no dependiendo de los parámetrosPacket Size (tamaño mínimo de los paquetes a marcar) y Marking Rate(tasa de marcado de paquetes congestionados).y se reduzca su tasa de inyección. Además, el valor deTimer[i] (fig. 2) se inicializa con el valor CCTI Timery, cuando dicho timer expira (Evento #7), el CCTI[i]se decrementa en una unidad y el IRD i se reduce. Portanto, la tasa de inyección se aumenta. Nótese que, siuna situación de congestión es prolongada, se recibiránnumerosos BECNs y por tanto los IRD i de los destinosi congestionados se aumentarán, limitándose así la inyecciónhacia esos puntos. El árbitro del IA toma la decisiónde qué paquete debe inyectarse (Evento #8), segúnuna política RR entre todas las AdVOQs, el IRD i y elúltimo instante en que cada AdVOQ i transmitió (LTI[i]).De este modo, CCFIT reduce la tasa de inyecciónpara los destinos congestionados durante las situacionesde congestión y elimina los árboles de congestión de lared. Los recursos que ocupan esos árboles (principalmenteCFQs y líneas CAM), se liberan de forma rápiday quedan disponibles para aislar nuevos árboles de congestión.Cuando la congestión desaparece la tasa de inyecciónse incrementa. Por otro lado, el mecanismo deinhibición de inyección de CCFIT necesita ajustar ciertosparámetros, al igual que se hace en IB. Un estudio másexhaustivo de la configuración de dichos parámetros sepuede consultar en [7], [13], [14].IV. EVALUACIÓNLa principal contribución de CCFIT es el aumento significativode sus prestaciones si se compara con FBICM ola técnica CC de IB (limitación de inyección), sobre todoen situaciones de congestión persistente y con muchosárboles de congestión. En estos casos FBICM se quedasin CFQs, y la técnica de inhibición de la inyección reaccionade forma muy lenta a la congestión, produciéndoseun “efecto sierra” en la productividad, debido a esa lentitud.En esta sección se evalúan las prestaciones de CCFITque se han obtenido mediante simulaciones.En primer lugar, la herramienta de simulación es unsimulador dirigido por eventos, programado en lenguajeC + +, que modela redes de interconexión a nivel de ciclo,nodos finales, enlaces, etc. Además, para nuestrosexperimentos, se ha modelado una red de interconexiónde 64 nodos con patrón de conectividad 4-ary 3-tree yenlaces de 2.5 GBytes/s, 48 conmutadores IQ de grado8 puertos, con Virtual Cut-Through (VCT) como políticade conmutación, control de flujo basado en créditos y iSlipcomo algoritmo de planificación. El encaminamientoes distribuido, determinista, basado en tablas y usa el algoritmoDESTRO [24]. Además, las memorias de lospuertos de entrada de los conmutadores son de 64 KB yel tamaño de paquete es de 2048 bytes.Por otro lado, se han modelado tres escenarios detráfico para la anterior configuración de red, con un 25%de los nodos de procesamiento que generan 1, 4 y 6árboles de congestión respectivamente, entre los instantesde tiempo [1ms,2ms]. Estos escenarios sirven para comprobarque CCFIT aisla y elimina los árboles de congestióncuando no hay CFQs suficientes. Finalmente, sehan modelado las siguientes técnicas de CC:* Una cola (1Q) por puerto que guarda todos los paquetes.Al no existir eliminación de HoL-blocking, 1Qpermite evaluar la red en el peor de los casos.* FBICM. Se usan 2 CFQs por puerto de entrada.* Limitación de inyección (ITh). Se asumen 8 VOQs(Virtual Output Queues, ya que el grado de los conmutadoreses de 8 puertos. Los umbrales High/Low (fijadosa 4 y 2 paquetes), así como los demás parámetros de losIAs, se han fijado tal y como se analiza en [14]).JP2011-412

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Ejemplo de funcionamiento de CCFIT en los Conmutadores.* CCFIT asume 2 CFQs por puerto de entrada y usalos mismos valores, para los parámetros de limitación deinyección de los IAs, que la técnica ITh. Nótese que sólo2 CFQs aislarán flujos de paquetes y pondrán puertos desalida en estado congestionado, mientras que la técnicaITh usa 8 VOQs, para el mismo cometido.* VOQnet (teóricamente la más efectiva) necesitamemorias de mayor tamaño por puerto de entrada, ya quecada memoria se divide en 64 colas (64 nodos destinoposibles). Si consideramos las restricciones del controlde flujo, tamaño de paquete y ancho de banda del enlace,el tamaño mínimo de la cola será de 4 KB y las memoriasserán de 256 KB. Por tanto VOQnet es poco realistay sólo se modela para obtener la máxima productividadteórica de la red con eliminación del HoL-blocking.A. Análisis de la ProductividadLa fig. 5 muestra la productividad global de la red enfunción del tiempo, para la red y el patrón de tráfico descritosanteriormente. En general, se aprecia claramentecómo CCFIT (con 2 CFQs por puerto) consigue un buencomportamiento, aún cuando el número de árboles decongestión pasa de 1 a 6. En la fig. 5a (un único árbolde congestión), FBICM con 2 CFQs tiene recursos suficientespara almacenar los arboles de congestión. Nóteseque además del árbol de congestión generado, puedenaparecer situaciones de congestión eventuales (que surgeny desaparecen de forma muy rápida), las cuales introducencierto HoL-blocking que sólo puede eliminarsecon una técnica que reaccione rápidamente ante la congestión.La técnica ITh, que además tiene 8 VOQs porpuerto, no es capaz de reaccionar tan rápido a la situaciónde congestión como FBICM o CCFIT. Por otro lado, VO-Fig. 4. Ejemplo de funcionamiento de CCFIT en los IAs.JP2011-413Qnet alcanza la máxima productividad pero, como se hadescrito, a costa de usar 64 colas por puerto y memoriasde 256 KB, mientras CCFIT y las otras técnicas usanmenos colas y menos memoria. En todos los casos, elesquema 1Q consigue los peores resultados, ya que se veafectado por el HoL-blocking.Al aumentarse el número de árboles de congestión enla red (fig. 5b), FBICM no tiene CFQs suficientes paraalmacenar todos los árboles de congestión que aparecenen la red y, por tanto, surge HoL-blocking que lastra susprestaciones. Por otra parte, CCFIT mejora sustancialmenteel comportamiento de FBICM, gracias al efecto dela limitación de la inyección, que es capaz de liberar lasCFQs y líneas CAM asignadas, antes de que sean necesariaspara aislar nuevos árboles de congestión. Finalmente,ITh reacciona mejor ante este tipo de tráfico, conrespecto al escenario de la fig. 5a, pero se puede observarclaramente la oscilación su eficiencia (el “efecto sierra”).Finalmente, con 6 árboles de congestión en la red (fig.5c), se obtienen conclusiones similares. Este patrón detráfico representa una situación donde el tráfico congestionadose balancea mejor en la red (téngase en cuentaque hay 6 árboles repartidos en un 25% de tráfico congestionado).Nuevamente CCFIT mejora a FBICM, mientrasITh necesita más tiempo para ajustar la tasa de inyección.En conclusión, CCFIT mejora sustancialmente otrosenfoques de CC, incluido FBICM, máxime si los árbolesde congestión en la red no pueden ser aislados en lasCFQs disponibles; consigue liberar las CFQs utilizadasde forma más rápida, gracias a la limitación de inyeccióny, por tanto, esas CFQs pueden ser usadas para aislarnuevos flujos congestionados de forma inmediata.

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Productividad de la red (normalizada)0.80.70.60.50.40.30.20.11QIThFBICM-2CFQCCFIT-2CFQVOQnet00 1e+06 2e+06 3e+06 4e+06 5e+06Tiempo (nanosegundos)(a) 1 Árbol de Congestión.Productividad de la red (normalizada)0.80.70.60.50.40.31Q0.2IThFBICM-2CFQ0.1CCFIT-2CFQVOQnet00 1e+06 2e+06 3e+06 4e+06 5e+06Tiempo (nanosegundos)(b) 4 Árboles de Congestión.Fig. 5. Productividad vs. Tiempo (Configuración #3, Tráfico #4).Productividad de la red (normalizada)0.80.70.60.50.40.31Q0.2IThFBICM-2CFQ0.1CCFIT-2CFQVOQnet00 1e+06 2e+06 3e+06 4e+06 5e+06Tiempo (nanosegundos)(c) 6 Árboles de Congestión.V. CONCLUSIONESEn la actualidad, las redes de interconexión de altasprestaciones son más simples y sencillas, ya que se handiseñado con el objetivo de ahorrar coste y consumo.Esto ocasiona que la congestión surja y se propague conmás facilidad, de un modo más rápido, lo que hace necesarioel uso de mecanismos de control de la congestión.De entre todos los enfoques propuestos para el controlde la congestión, destacan la inhibición de la inyeccióny el aislamiento explícito de los flujos congestionados.El primer enfoque reduce el árbol de congestión paraminimizar su principal efecto negativo, el HoL-blocking,pero entre el momento en que se detecta la congestión, yel momento en que se reduce el árbol existe un retardosignificativo. Por otro lado, el segundo enfoque aislade forma inmediata los árboles de congestión, usandopara ello colas especiales, dinámicamente asignadas atal efecto, con lo que elimina completamente el HoLblocking.Sin embargo, dichos recursos, al ser limitados,no pueden almacenar todos los árboles de congestión.En este artículo se ha descrito CCFIT (CombinedCongestion-Flow Isolation and Throttling, una nuevatécnica que combina ambos enfoques de control de congestión,y que está pensada para mantener las ventajasde ambos y minimizar sus inconvenientes. En concreto,CCFIT reacciona de forma inmediata a la congestión, aislandolos árboles de congestión. A su vez, la limitaciónde inyección reduce el árbol de congestión y libera losrecursos utilizados para el aislamiento de esos árbolesde congestión de forma más rápida, tal y como ha demostradola evaluación de prestaciones.AGRADECIMIENTOSEste trabajo ha sido parcialmente financiado por elMEC y el MICINN, así como por la Comisión Europeaa través de los fondos FEDER, mediante los proyectosCSD2006-00046 y TIN2009-14475-C04. Además,también ha sido parcialmente financiado por la JCCM,mediante los proyectos PEII11-0229-2343, POII10-0289-3724 y la beca de doctorado A08/048.REFERENCIAS[1] Pedro J. García, J. Flich, J. Duato, I. Johnson, Francisco J. Quiles,and F. Naven, “Dynamic evolution of congestion trees: Analysisand impact on switch architecture,” Proc. 1st HiPEAC Conf., pp.266–285, November 2005.[2] M. J. Karol, M. G. Hluchyj, and S. P. Morgan, “Input versusoutput queueing on a space-division packet switch,” IEEE Trans.on Commun., vol. COM-35, pp. 1347–1356, 1987.[3] Pedro J. García, J. Flich, J. Duato, I. Johnson, Francisco J. Quiles,and F. Naven, “Efficient, scalable congestion management forinterconnection networks,” IEEE Micro, vol. 26, no. 5, pp. 52–66,September 2006.[4] InfiniBand Trade Association, InfiniBand architecture specification.Release 1.2.1, Nov. 2007.[5] J. Duato, I. Johnson, J. Flich, F. Naven, Pedro J. García, and T. Nachiondo,“A new scalable and cost-effective congestion managementstrategy for lossless multistage interconnection networks,”in Proceedings of the 11th Symposium on High Performance ComputerArchitecture (HPCA), 2005.[6] J. Escudero-Sahuquillo, Pedro J. García, Francisco J. Quiles,J. Flich, and J. Duato, “FBICM: Efficient congestion managementfor high-performance networks using distributed deterministicrouting,” in LNCS Series - 15th Conference on High PerformanceComputing - (HiPC 2008), Bangalore, India, December.[7] J. Escudero-Sahuquillo, E. G. Gran, Pedro J. García, J. Flich,T. Skeie, O. Lysne, F. J. Quiles, and J. Duato, “Combiningcongested-flow isolation and injection throttling in hpc interconnectionnetworks,” in Proceedings of the 40th InternationalConference on Parallel Processing (ICPP 2011), Taipei, Taiwan,september 2011.[8] M. Thottetodi, A.R. Lebeck, and S.S. Mukherjee, “Self-tunedcongestion control for multiprocessor networks,” in Proc. of 7th.HPCA, February 2001.[9] J.H. Kim, Ziqiang Liu, and A.A. Chien, “Compressionless routing:a framework for adaptive and fault-tolerant routing,” Paralleland Distributed Systems, IEEE Transactions on, vol. 8, no. 3, pp.229 –244, Mar. 1997.[10] Elvira Baydal and Pedro López, “A robust mecahnism for congestioncontrol: Inc,” in Euro-Par, 2003, pp. 958–968.[11] Santos J. R, Y. Turner, and G. J. Janakiraman, “End-to-end congestioncontrol for InfiniBand,” in INFOCOM, 2003.[12] Joan-Lluís Ferrer, Elvira Baydal, Antonio Robles, Pedro López,and José Duato, “On the influence of the packet marking andinjection control schemes in congestion management for MINs,”in Euro-Par, 2008, pp. 930–939.[13] E.G. Gran, M. Eimot, S.-A. Reinemo, T. Skeie, O. Lysne, L.P.Huse, and G. Shainer, “First experiences with congestion controlin InfiniBand hardware,” in Parallel Distributed Processing(IPDPS), IEEE International Symposium on, 2010, pp. 1–12.[14] Ernst Gunnar Gran, Eitan Zahavi, Sven-Arne Reinemo, Tor Skeie,Gilad Shainer, and Olav Lysne, “On the relation between congestioncontrol, switch arbitration and fairness,” in InternationalSymposium on Cluster, Cloud and Grid Computing (CC-Grid 2011) [Pending of publishing].[15] T. Anderson, S. Owicki, J. Saxe, and C. Thacker, “High-speedswitch scheduling for local-area networks,” ACM Transactions onComputer Systems, vol. 11, no. 4, pp. 319–352, November 1993.[16] W. Dally, P. Carvey, and L. Dennison, “Architecture of the Aviciterabit switch/router,” in Proc. 6th Hot Interconnects, 1998, pp.41–50.[17] Y. Tamir and G.L. Frazier, “Dynamically-allocated multi-queuebuffers for vlsi communication switches,” IEEE Transactions onComputers, vol. 41, no. 6, June 1992.[18] Teresa Nachiondo, Jose Flich, and Jose Duato, “Buffer managementstrategies to reduce hol blocking,” IEEE Transactions onParallel and Distributed Systems, vol. 21, pp. 739–753, 2010.[19] Wladek Olesinski, Hans Eberle, and Nils Gura, “Scalable alternativesto virtual output queueing,” in Proc. IEEE InternationalConference on Communications, 2009.[20] J. Escudero-Sahuquillo, Pedro J. García, Francisco J. Quiles, andJ. Duato, “An efficient strategy for reducing head-of-line blockingin fat-trees,” in 16th International Euro-Par Conference, Ischia,Italy, september 2010, pp. 413–427.[21] G. Mora, Pedro J. García, J. Flich, and J. Duato, “RECN-IQ:A cost-effective input-queued switch architecture with congestionmanagement,” in Proc. ICPP, 2007.[22] N. McKeown, “The iSLIP scheduling algorithm for input-queuedswitches,” IEEE/ACM Transactions on Networking, vol. 7, no. 2,pp. 188–201, Apr. 1999.[23] J. Escudero-Sahuquillo, Pedro J. García, Francisco J. Quiles,J. Flich, and J. Duato, “Cost-effective congestion management forinterconnection networks using distributed deterministic routing,”in Proc.16th International Conference on Parallel and DistributedSystems (ICPADS 2010), Shanghai, China, december 2010.[24] C. Gomez, F. Gilabert, M.E. Gomez, P. Lopez, and J. Duato, “Deterministicversus adaptive routing in fat-trees,” in Workshop onCommunication Architecture on Clusters, as a part of IPDPS’07,March 2007, p. 235.JP2011-414

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Un acercamiento a la eficacia de las técnicasde control de congestión en redes deinterconexión con topologías directasDaniel Gómez-García 1 , Pedro Javier García 1 , Francisco José Quiles 1 , JesúsEscudero-Sahuquillo 1 , Juan Antonio Villar 1 , José Flich 2 , José Duato 21 Dept. Sistemas Informáticos, Universidad de Castilla-La Mancha. E-mail:{Daniel.Gomez,PedroJavier.Garcia,Francisco.Quiles,Jesus.Escudero,JuanAntonio.Villar}@uclm.es2 Dept. de Informática de Sistemas y Computadores, Universitat Politècnica de València. E-mail:{jflich,jduato}@gap.upv.esResumen—Las redes de interconexión juegan un papel cada díamás importante en el rendimiento global de los sistemas de computaciónparalela y de comunicaciones. De hecho, hoy en día, la redde interconexión suele limitar el rendimiento global del sistema. Asu vez, las prestaciones de la red se ven afectadas por la apariciónde situaciones de congestión. En redes sin descarte de paquetes, laaparición de situaciones de congestión degrada gravemente la productividadde la red, debido a que los flujos no congestionados seven afectados por la lentitud del avance de los flujos congestionados,que hacen que los primeros avancen más despacio de lo quedeberían. Esto es un caso particular del fenómeno conocido comobloqueo de cabeza de línea (HoL blocking).Aunque se han propuesto muchas técnicas para reducir o eliminarel HoL blocking, sólo algunas se consideran realmente eficientesy escalables. Sin embargo, habitualmente la evaluación de estastécnicas se ha realizado solamente en redes multietapa. En esteartículo se realiza una comparación entre las técnicas más comunesde eliminación del HoL blocking mediante resultados de simulaciónobtenidos en escenarios que modelan redes directas, de cara a comprobarla validez de estas técnicas para estas topologías.Palabras clave—Redes de Interconexión; Control de Congestión;Topologías DirectasFig. 1HOL BLOCKING DEBIDO A LOS FLUJOS CONGESTIONADOSI. INTRODUCCIÓNEN los últimos años las redes de interconexión hanido jugando un papel cada vez más importante enel rendimiento global de los sistemas de computación paralelay de comunicaciones. Hoy en día, los principalessistemas cuyo rendimiento depende en gran medida de lared de interconexión son: procesadores masivamente paralelos(MPPs), sytem area networks (SANs), clusters dePCs y estaciones de trabajo, routers IP y redes en chip(NoCs). De hecho, el rendimiento global de estos sistemasse encuentra limitado por las prestaciones de la redde interconexión que posee.Uno de los fenómenos que más impacto puede teneren las prestaciones de una red es la aparición de situacionesde congestión. Estas situaciones se dan cuando variosflujos de datos dentro de la red requieren simultánea ypersistentemente los mismos recursos para alcanzar susdestinos. En una red sin pérdidas, como es el caso de lamayoría de tecnologías de red actuales, la eliminación depaquetes no está permitida, por lo que cuando las colasde los conmutadores que se encuentran en ese camino sellenan, el control de flujo propaga la congestión “haciaatrás” en el camino de los datos. Cuando esto sucede, elrendimiento de la red se degrada rápidamente. Estas situacionesde congestión se han evitado tradicionalmentesobredimensionando la red de interconexión, pero en laactualidad esta práctica se ha vuelto inviable debido a losaltos costes y al alto consumo de los componentes de in-terconexión de la red.De hecho, las redes de interconexión actuales, debido arestricciones económicas, de consumo y de memoria, sondiseñadas usando el mínimo número de componentes dered posible. Esto nos lleva a una mayor probabilidad deque aparezcan situaciones de congestión. Debido a esto,usar técnicas de control de congestión en redes de interconexiónse ha vuelto prácticamente imprescindible. Eneste sentido, se han propuesto varias técnicas que tratande evitar la aparición de situaciones de congestión o deeliminarlas cuando aparecen (por ejemplo, la inhibiciónde inyección [1]).Cabe aclarar que, desde nuestro punto de vista, la congestiónen sí no es el problema. El problema real llegacuando los flujos congestionados y los no congestionadoscomparten recursos de la red (colas, enlaces). Concretamente,cuando las colas de los conmutadores almacenanpaquetes pertenecientes a flujos congestionados y no congestionados,los primeros hacen que los flujos no congestionadosavancen por la red a la misma velocidad que lohacen los congestionados. En general este efecto es uncaso particular del fenómeno conocido como bloqueo decabeza de línea (HoL blocking) y se puede observar en lafigura 1. Cabe remarcar que en los esquemas de colas enlos que éstas no son compartidas, los flujos de paquetesno congestionados no se ven afectados por el HoL blocking.Para eliminar el HoL blocking se han propuesto mu-JP2011-415

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011chas técnicas, como pueden ser: Virtual Output Queuesa nivel de red (VOQnet) [2], Virtual Output Queues a nivelde conmutador (VOQsw) [3], Destination-Based BufferManagement (DBBM) [4], Regional Explicit CongestionNotification (RECN) [5], Flow-Based Implicit CongestionManagement (FBICM) [6], Output-Based QueueAssignment (OBQA) [7] o Dynamically Allocated Multiqueues(DAMQS) [8].Entre todas las técnicas mencionadas, probablementelas técnicas que más económica y satisfactoriamente eliminanel HoL blocking son RECN y FBICM. Estas técnicascomparten el mismo planteamiento y son capaces dereducir en gran medida los efectos perjudiciales del HoLblocking sin requerir una gran cantidad de recursos extra.El funcionamiento básico de ambas propuestas será explicadoen la siguiente sección.Sim embargo, ambas técnicas han sido evaluadas casiexclusivamente en redes multietapa. La finalidad de esteartículo es evaluar diversas técnicas para reducir el HoLblocking en topologías directas tipo malla o toro, de caraa comprobar si las ventajas del enfoque seguido porRECN y FBICM se mantienen en estas topologías.El resto del artículo se organiza así: en la sección II,se resume el funcionamiento de las técnicas de controlde congestión RECN y FBICM. Luego, en la sección IIIse verán los resultados de las simulaciones realizadas yse comentarán los resultados obtenidos. Por último, en lasección IV se exponen las conclusiones y las motivacionespara seguir trabajando en esta línea.II. RECN Y FBICMEsencialmente, la diferencia entre las técnicas RECN yFBICM radica en que RECN ha sido propuesto para redesque usan encaminamiento fuente, mientras que FBICMasume el uso de encaminamiento distribuido deterministabasado en tablas. La segunda diferencia más importanteentre ambos recae en la arquitectura de conmutadorusada. Mientras que FBICM ha sido específicamente diseñadopara conmutadores IQ (Input Queued, o colas solamenteen los puertos de entrada), existen versiones deRECN tanto para conmutadores IQ como para conmutadoresCIOQ (Combined Input and Output Queued, o concolas tanto en los puertos de entrada como en los de salida).Aparte de estas diferencias y algún otro detalle, elfuncionamiento básico es el mismo.Ambas propuestas se basan en la misma idea clave:si el HoL blocking es eliminado completamente, puedeser que la congestión siga existiendo en la red, pero esinocua. Hay que tener en cuenta que si los flujos no congestionadosno se ven afectados por los congestionados,todos los flujos de datos de la red cruzarán la red a lavelocidad máxima que ésta permita. Teniendo en cuentaesto, ambas técnicas tratan de eliminar el HoL blockingsiguiendo los mismos procedimientos básicos: se detectaexplícitamente el punto donde se está produciendo lacongestión y luego se separan los flujos congestionadosy los no congestionados asignando dinámicamente colaspara almacenar únicamente los paquetes de los flujoscongestionados. De esta manera se evita el HoL blockingproducido por los paquetes congestionados a los que nolo están. Por otro lado, los paquetes no congestionadospueden seguir compartiendo colas entre ellos sin que elloproduzca un HoL blocking significativo. De esta forma,estas técnicas no requieren demasiadas colas para atacarel problema del HoL blocking, siempre teniendo en menteque al aumentar el tamaño de la red, el número de flujosde paquetes que pasan por un punto de la red aumenta.La detección de la congestión se produce cuando laocupación de una cola en un puerto de entrada de un conmutadoralcanza un cierto nivel, al que llamaremos nivelde detección. Llegar a este nivel indica que puede haberciertos paquetes que no están avanzando tan rápido comodeberían y eso puede llevarnos al desbordamiento de lacola.Una vez detectada la situación de congestión, el procesode aislamiento del flujo de paquetes congestionadoscomienza: se asigna una nueva cola para aquellos paquetescuyo puerto de salida sea el puerto que se ha detectadocomo punto de congestión. Para la gestión de la nueva colase creará también una nueva entrada en una MemoriaDireccionable por Contenido (CAM). Esta CAM almacenarála ruta hasta el punto de congestión, bien de maneraexplícita (RECN) o bien implícita (FBICM).Cuando la congestión persiste durante un largo periodode tiempo, estas nuevas colas creadas para almacenarlos paquetes de los flujos congestionados, pueden, a suvez, llegar a un nivel muy alto de ocupación y sufrir peligrode desbordamiento. Para evitar esta situación se usaun umbral de “Stop”. Una vez que una cola alcanza estepunto, la información de congestión debe ser propagada alos conmutadores precedentes. Con esta información, unconmutador que la recibe sabe que hay un conmutador enel siguiente salto que está al límite de su capacidad paraalmacenar paquetes congestionados de una cola concreta,lo que le lleva a asignar él una cola para almacenar lospaquetes de este flujo congestionado y a parar su envíohasta que se reciba una señal de “Go“. Con este mecanismode propagación conseguimos aislar los flujos depaquetes congestionados a lo largo de su camino hasta elpunto donde son generados, evitando así el HoL blockingque pueden producir los no congestionados.Finalmente, cuando la congestión va desapareciendo,otro mecanismo se encarga de liberar las colas que yano son necesarias. De esta forma estas colas pueden serreutilizadas para almacenar los paquetes de nuevos flujoscongestionados que puedan aparecer.Se ha demostrado que tanto RECN como FBICM eliminande manera eficiente el HoL blocking [5] [6], perotambién cabe decir que estas técnicas han sido evaluadasbásicamente en Redes de Interconexión Multietapa (MultistageInterconnection Networks, MINs). En la siguientesección se evalúa la validez de este enfoque en redes directas.III. EVALUACIÓN EN REDES DIRECTASA. Entorno de simulaciónLos siguiente resultados y figuras han sido obtenidosmediante simulación. Para ello se ha utilizado un simuladorad-hoc, dirigido por eventos, que modela redesde interconexión a nivel de ciclo. Este simulador es capazde modelar las diferentes técnicas de reducción delHoL blocking como VOQnet, VOQsw, DBBM, RECN yJP2011-416

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIPATRONES DE TRÁFICO SINTÉTICO EVALUADOSTráfico uniformeTrafico Hot-SpotCaso % Fuentes Destino Tasa de generación % Fuentes N o Destinos Tasa de generación Tiempo inicio Tiempo fin1 100 % aleatorio incremental 0 % - - - -2 75 % aleatorio 100 % 25 % 1 100 % 1000µS 1300µSTABLA ICONFIGURACIONES DE RED EVALUADASCaso Tamaño Topología N o Conmutadores1 8x8 Malla 2D 642 8x8x8 Malla 3D 5123 8x8 Toro 2D 644 8x8x8 Toro 3D 512FBICM. Aparte de modelar los diferentes mecanismos,nuestro simulador también es capaz de modelar diferentestopologías de red, entre las que usaremos las topologíasdirectas mostradas en la tabla I.En todas las configuraciones de red se han modeladoenlaces bidireccionales segmentados con 2.5 GByte/s deancho de banda y 4 nanosegundos de retardo, tanto paraenlaces entre conmutadores, como para enlaces entrenodos finales y conmutador.Para todas la redes evaluadas el algoritmo de encaminamientoes dimension-order routing [9]; por lo tanto, lainformación necesaria para encaminar un paquete está situadaen los conmutadores y está basada en tablas de encaminamiento.Debido a esto y a que los resultados obtenidosen otros estudios para las técnicas RECN y FBICMson muy similares, para las comparativas de las simulacionesusaremos solamente la técnica FBICM. Como seha explicado en la sección II, el funcionamiento básico esel mismo para ambas técnicas.La arquitectura de los conmutadores modelados sigueel esquema IQ (Input Queued), donde las memorias dedatos están presentes sólo en los puertos de entrada. El tamañode dicha memoria se ha dejado en 128 KB (menospara VOQnet, donde depende directamente del tamaño dela red) y su organización depende del mecanismo de eliminaciónde HoL blocking elegido. Para las simulacionesse han modelado las siguientes técnicas de eliminacióndel HoL blocking: Single Queue (1Q), que usa una únicacola por puerto (no elimina el HoL blocking pero muestrala eficiencia pura del algoritmo de encaminamientodeterminista); DBBM, con 8 colas por puerto de entrada;VOQsw, que usa una memoria con 4 colas por puerto parala configuración 1 y 3; y 6 colas por puerto para la configuración2 y 4. VOQnet necesita tantas colas por puertocomo destinos hay en la red. Esta última técnica suponeuna elevada complejidad a la hora de ser implementada,y sólo se ha considerado como referencia de la máximaeficacia teórica en la eliminación del HoL blocking.Respecto a la política de conmutación, se ha modeladoVirtual Cut-Through en todos los conmutadores.Además, la política de control de flujo está basada encréditos. Dentro de cada conmutador se ha modelado un“crossbar” multiplexado con una aceleración de 1 (estoes, el ancho de banda del enlace es el mismo que el delcrossbar).Los nodos finales están conectados a los conmutadoresmediante adaptadores de red (Input Adapters, IAs).Cada IA se modela con un número de fijo de colas de generación(una por cada destino), donde se depositan lospaquetes correspondientes a cada mensaje generado conel objetivo de eliminar el HoL blocking antes de la inyección.Los IAs también tienen un número determinado decolas de inyección que siguen el mismo esquema que lascolas de los puertos de entrada de los conmutadores. Portanto, un mensaje es descompuesto en paquetes y guardadoen una cola de generación asignada para su destino,y después el árbitro interno del IA llevará los paquetesa la cola de inyección correspondiente (el tamaño de lospaquetes es de 2048 bytes).Respecto a la carga de tráfico, se han usado los patronesde tráfico sintético descritos en la tabla II. Básicamente,se han modelado dos tipos de tráfico sintético: tráficocompletamente uniforme (caso 1), donde la tasa de inyecciónde todos los nodos varía desde un 0 % hasta un100 % del ancho de banda del enlace; y tráfico congestionado“Hot-Spot” (caso 2), donde un porcentaje de losnodos fuente (en concreto un 25 %) inyecta tráfico a unúnico destino, con el objetivo de crear una situación persistentede congestión, mientras las fuentes restantes (un75 %), inyectan tráfico uniforme. Estos patrones de tráficose han usado para obtener resultados en función deltiempo (caso 1) y resultados en función de la carga (caso2). Ambos patrones de tráfico se han aplicado a todas lasconfiguraciones de red de la tabla I.Además, se han usado trazas reales de tipo autorelacionado,basadas en el conjunto de aplicaciones LINPACK(HPL) [10], que es uno de los tests estándar para clasificarlos supercomputadores del Top-500 [11]. Las trazas LIN-PACK han sido generadas modificando la herramienta decaptura de trazas de la librería MPE (Multi-ProccessingEnvironment) incluída en MPICH, para así poder registrartodos los mensajes punto-a-punto, incluyendo aquellosde las operaciones colectivas, que no se incluían pordefecto [12]. Aunque este tipo de trazas producen sólouna congestión moderada en la red, es suficiente para obtenerresultados que muestren el rendimiento de las diferentestécnicas evaluadas. Falta decir que este tipo detráfico sólo lo tenemos disponible para tamaños de red de64 nodos. Respecto al patrón de tráfico real utilizado, suevaluación es diferente, pues la carga a la que somete a lared este tipo de tráfico no es suficiente para producir congestión.Con este tipo de tráfico lo que se hace es evaluarel tiempo total que se tarda en ejecutar toda la traza conlas diferentes técnicas de control de congestión y compararlasentre ellas para ver la ganancia real de utilizar una uotra técnica. Como ya se ha comentado, al no producirse,JP2011-417

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110.70.5Eficiencia de red (normalizada)0.60.50.40.30.21QDBBM0.1FBICMVOQsw0VOQnet0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Trafico Generado NormalizadoEficiencia de red (normalizada)0.450.40.350.30.250.20.151Q0.1DBBMFBICM0.05VOQsw0VOQnet0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Trafico Generado Normalizado(a) Configuración de red 1(b) Configuración de red 20.80.8Eficiencia de red (normalizada)0.70.60.50.40.31Q0.2DBBM0.1FBICMVOQsw0VOQnet0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Trafico Generado NormalizadoEficiencia de red (normalizada)0.70.60.50.40.31Q0.2DBBM0.1FBICMVOQsw0VOQnet0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Trafico Generado Normalizado(c) Configuración de red 3(d) Configuración de red 4Fig. 2EFICIENCIA DE RED NORMALIZADA EN FUNCIÓN DE LA CARGA. PATRÓN DE TRÁFICO 1con este tipo de tráfico, mucha congestión en la red, lasmejoras ofrecidas por las técnicas evaluadas no son tanvisibles como cuando se crea una gran congestión en lared.Finalmente, aunque el simulador ofrece muchas métricas,la evaluación se ha basado en una de las principalesmétricas consideradas para la medición del rendimiento:la productividad (normalizada). Por tanto, en los siguientesapartados se analizará por medio de esta métrica elrendimiento ofrecido por la red, para cada una de las propuestasde eliminación del HoL blocking.B. Resultados para tráfico uniformeLa figura 2 nos muestra la eficiencia de red en funciónde la carga. Estas 4 configuraciones de red mostradas sontodas las configuraciones de la tabla II. En la figura 2a vemosque después de VOQnet, la técnica FBICM es la quemás tarda en saturar, ya que ésta es capaz de aislar mejorlos flujos congestionados. El resto de técnicas se comportanalgo peor, como DBBM, aunque con sus 8 colas porpuerto de entrada también consigue eliminar en parte elHoL blocking. Las técnicas más básicas como VOQsw o1Q presentan los peores rendimientos. En la figura 2b laproductividad alcanza valores más bajos debido a que eltamaño de la red es mayor que el de la figura 2a, entonceslos caminos para llegar de un punto a otro de la red sonmás largos y ello provoca que los árboles de congestiónsean más mayores también y afecten más al rendimientode la red. Con tráfico uniforme, una de las característicasde los árboles de congestión que se forman es que éstosdesaparecen muy rápido, pues no se insiste en enviar tráficopor una zona determinada de la red. Esto favorece acualquier técnica en general, pues la red no sufre demasiadolos problemas derivados de la aparición de árbolesde congestión.Se puede observar rápidamente que las figuras 2c y 2dson bastante similares a las anteriores. En estos casos, supunto de saturación es más alto debido a que, al tener másconexiones, los árboles son más grandes y la red aceptamás trafico antes de saturarse. Vemos en la figura 2c queFBICM aguanta mejor el punto de saturación, no cayendosu rendimiento, aunque cuando el tamaño de la redaumenta (figura 2d), la productividad de todas las técnicascae algo más en todos de los casos. En el caso másconcreto de FBICM, el problema radica en que el númerode árboles de congestión aumenta y las colas especialesno son suficientes para guardar todos los flujos congestionadosque pasan a través de un punto (no sin necesitaruna gran cantidad de colas). Es decir, a mayor tamaño dela red hay un mayor número de árboles de congestión,además de que se pueden extender en mayor medida debidoa que el árbol de congestión tiene más caminos porlos que expandirse. Todo esto, junto a las característicasdel algoritmo de encaminamiento, hacen que, incluso contráfico uniforme, los árboles de congestión tarden un mayortiempo en desaparecer y provoquen un mayor decaimientoen la eficiencia de la red.C. Resultados para tráfico Hot-SpotLa figura 3 nos muestra ahora la eficiencia de la reden función del tiempo. Todas las configuraciones de redmostradas son nuevamente las 4 configuraciones de la ta-JP2011-418

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110.60.6Eficiencia de red (normalizada)0.50.40.30.21QDBBM0.1Generacion de Hot-Spot FBICMVOQsw0VOQnet0 2e+06 4e+06 6e+06 8e+06 1e+07Tiempo (nanosegundos)Eficiencia de red (normalizada)0.50.40.30.20.1Generacion de Hot-Spot1QDBBMFBICMVOQswVOQnet00 2e+06 4e+06 6e+06 8e+06 1e+07Tiempo (nanosegundos)(a) Configuración de red 1(b) Configuración de red 20.70.7Eficiencia de red (normalizada)0.60.50.40.30.21QDBBM0.1Generacion de Hot-SpotFBICMVOQsw0VOQnet0 2e+06 4e+06 6e+06 8e+06 1e+07Tiempo (nanosegundos)Eficiencia de red (normalizada)0.60.50.40.30.20.1Generacion de Hot-Spot1QDBBMFBICMVOQswVOQnet00 2e+06 4e+06 6e+06 8e+06 1e+07Tiempo (nanosegundos)(c) Configuración de red 3(d) Configuración de red 4Fig. 3EFICIENCIA DE RED NORMALIZADA EN FUNCIÓN DEL TIEMPO. PATRÓN DE TRÁFICO 2bla II, aunque ahora se estudia la eficiencia de las técnicasevaluadas cuando se produce un ”Hot-Spot” claro ypersistente en un punto de la red. Como se describió anteriormente,para producir este “Hot-Spot“, el 25 % de lasfuentes de la red mandan tráfico dirigido a un sólo nodode la red durante 300µS desde el instante 1000µS.Como se puede observar en todas las figuras, en el momentoen el que se produce la congestión, el rendimientode las técnicas decae en mayor o menor medida. Para elcaso de la figura 3a, sucede algo similar a lo que pasabapara tráfico uniforme en la figura 2a. En este caso VOQnetno se ve afectado por el árbol, pues separa totalmentetodos los flujos de datos. FBICM tampoco acusa en granmedida la congestión, pero esto es debido a que la red espequeña y es capaz de aislar correctamente los flujos congestionados;aun así queda bastante por debajo de VOQnet.El mismo razonamiento se podría dar en DBBM, yaque éste también es capaz de aislar bien los flujos congestionadosgracias a sus 8 colas por puerto de entrada.El esquema peor parado en todos los casos es 1Q, puesno es capaz de eliminar el HoL blocking en absoluto, ycuando los árboles son muy grandes, como sucede en lostoros, este esquema se ve aún más afectado.Respecto a la configuración de red de la figura 2b seve cómo VOQnet no tiene ninguna pérdida en el rendimientoen el momento del ”Hot-Spot”. Esto es debido,como ya se dijo en la sección anterior, a que VOQnet escapaz de aislar todos los árboles de congestión. Luego seobserva cómo FBICM junto a DBBM son capaces de aislarmejor los flujos congestionados, pero en redes grandesvolvemos a sufrir el problema de la falta de colas para aislartodos los flujos congestionados. Analizando ahora losresultados para toros en las figuras 3c y 3d se observa lagran diferencia y la principal motivación de este artículo(y del futuro trabajo). Como se ve en la figura 3c, sies posible aislar todos los flujos congestionados, como esel caso de FBICM, el rendimiento no se ve penalizado.En caso de que no sea posible, la aparición de árbolesde congestión, junto a las topologías de tipo toro en lasque estos árboles son mayores, da lugar a un rendimientobastante pobre. Si aparte de esto, aumentamos el tamañode la red a unas dimensiones más acordes a una gran redde interconexión (como la de la figura 3d), vemos queel rendimiento de FBICM también cae debido a que noes capaz de albergar tantos destinos en sus CFQs comodebería. Esto nos lleva a la conclusión de que este algoritmono es escalable con respecto al tamaño de la red ypor ende debemos buscar soluciones más óptimas a esteproblema.D. Resultados para tráfico realLa evaluación de trazas reales la hemos realizado a partirde las razas LINPACK, que han sido descritas en elapartado III-A. El tiempo total de ejecución ha sido normalizadocon respecto al caso más lento, que como erade esperar es el obtenido por el esquema 1Q, pues en estecaso no se aplican mecanismos de eliminación del HoLblocking. Con estos resultados se pueden ver comparadoslos diferentes tiempos de ejecución y se ve claramentecómo VOQnet es la que menos tiempo consume (≈3 %menos), pues es la técnica que elimina completamente elHoL blocking. Cabe comentar que estos resultados estánJP2011-419

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4TIEMPO NORMALIZADO DE EJECUCIÓN DE TRAZAS LINPACKrealizados en una red de tipo malla de tamaño 8x8, lo queinfluye también en que el resto de técnicas mejoren a 1Q,pero su mejoría no sea muy grande.Puede parecer que las diferencias no son significativas,pero hay que tener en cuenta que, aparte del tamaño dela red utilizada, este tipo de trazas no someten a la reda una gran carga. Esto hace que no se produzca muchacongestión en la red y por eso la aparición del fenómenodel HoL blocking es menos probable. Por ello las técnicasestudiadas no mejoran en gran medida con respecto alpeor resultado.IV. CONCLUSIONESLas técnicas actuales basadas en aislar explícitamentelos flujos congestionados presentan problemas en redesdirectas debido a que al aumentar el tamaño de la red,el número de flujos de paquetes que pueden pasar porun punto aumenta. Esto puede producir una cantidad importantede árboles de congestión distintos en un mismopunto, llegando a alcanzar el número máximo de colasespeciales que podemos reservar, pues la memoria de losconmutadores no es infinita. Este problema puede verseclaramente si consideramos el tipo de árboles de congestiónque se forman en esta clase de redes, que tienden aser más largos y ramificados, como el que se muestra enla figura 5, lo que hace aumentar el número de flujos congestionadosen un punto de la red. Este hecho nos animaa replantear las técnicas basadas en el aislamiento de flujoscongestionados, que han sido orientadas a topologíasindirectas del tipo MIN, para intentar optimizarlas en redesdirectas. Como trabajo futuro se plantea el estudiomás a fondo del rendimiento de las técnicas basadas enel aislamiento de flujos congestionados y el posible desarrollode nuevas técnicas orientadas desde el principio altratamiento del problema del HoL blocking en topologíasdirectas.AGRADECIMIENTOSEste trabajo ha sido parcialmente financiado por elMEC y el MICINN, así como por la Comisión Europeaa través de los fondos FEDER, mediante los proyectosCSD2006-00046 y TIN2009-14475- C04. Además, tambiénha sido parcialmente financiado por la JCCM, mediantelos proyectos POII10-0289-3724, PEII11-0229-Fig. 5FLUJOS CONGESTIONADOS EN UNA MALLA O TORO2343 y la beca de doctorado A10/002.REFERENCIAS[1] J. Escudero-Sahuquillo, E. G. Gran, Pedro J. García, J. Flich,T. Skeie, O. Lysne, F. J. Quiles, and J. Duato, “Combiningcongested-flow isolation and injection throttling in hpc interconnectionnetworks,” in Proceedings of the 40th International Conferenceon Parallel Processing (ICPP 2011), Taipei, Taiwan, september2011.[2] W. Dally, P. Carvey, and L. Dennison, “Architecture of the Aviciterabit switch/router,” in Proc. of 6th Hot Interconnects, 1998, pp.41–50.[3] T. Anderson, S. Owicki, J. Saxe, and C. Thacker, “High-speedswitch scheduling for local-area networks,” ACM Transactions onComputer Systems, vol. 11, no. 4, pp. 319–352, November 1993.[4] Teresa Nachiondo, Jose Flich, and Jose Duato, “Buffer managementstrategies to reduce hol blocking,” IEEE Transactions onParallel and Distributed Systems, vol. 21, pp. 739–753, 2010.[5] Pedro J. García, J. Flich, J. Duato, I. Johnson, Francisco J. Quiles,and F. Naven, “Efficient, scalable congestion management forinterconnection networks,” IEEE Micro, vol. 26, no. 5, pp. 52–66,September 2006.[6] Jesús Escudero-Sahuquillo, Pedro Javier García, FranciscoJosé Quiles, José Flich, and José Duato, “Cost-effectivecongestion management for interconnection networks usingdistributed deterministic routing,” in ICPADS ’10: Proceedingsof the 16th International Conference on Parallel and DistributedSystems, Shanghai, China, 2010.[7] Jesús Escudero-Sahuquillo, Pedro Javier García García, FranciscoJosé Quiles Flor, José Flich Cardo, and José Duato Marín,“Cost-effective queue schemes for reducing head-of-line blockingin fat-trees,” Concurrency and Computation: Practice & Experience,2011.[8] Y. Tamir and G.L. Frazier, “Dynamically-allocated multi-queuebuffers for vlsi communication switches,” IEEE Transactions onComputers, vol. 41, no. 6, June 1992.[9] Herbert Sullivan and T R Bashkow, “A large scale, homogeneous,fully distributed parallel machine, i,” SIGARCH Comput. Archit.News, vol. 5, no. 7, pp. 105–117, 1977.[10] J. Dongarra, “Performance of various computers using standardlinear equations software,” Tech. Rep. Computer Science TechnicalReport Number CS-89-85, University of Tennessee, KnoxvilleTN, 37996, http://www.netlib.org/benchmark/performance.ps.[11] Top 500 List, ,” Web Page at: http://www.top500.org.[12] F. J. Ridruejo, A. Gonzalez, and J. Miguel-Alonso, “Trgen: Atraffic generation system for interconnection network simulators,”in Proceedings of the 2005 International Conference on ParallelProcessing Workshops, Washington, DC, USA, 2005, ICPPW ’05,pp. 547–553, IEEE Computer Society.JP2011-420

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Peripheral twists for torus topologies witharbitrary aspect ratioEnrique Vallejo 1 , Miquel Moretó 2 , Carmen Martínez 3 , and Ramón Beivide 4Abstract—A torus is a common topology used insupercomputer networks. Asymmetric Tori suffer fromresource usage imbalance, which translates to reducedperformance. Twisted Tori employ a twist in theperipheral links of one or more dimensions to improve thetopological parameters and overall performance ofasymmetric networks. 2D and 3D twisted tori with aspectratios 2:1 and 2:1:1 have been studied in detail.However, commercial machines do not necessarilyemploy those aspects ratios. In this work we present anearly study of the effect of peripheral link twisting inmultidimensional twisted tori with arbitrary aspect ratios.We observe that, in the general case, it is impossible to finda specific twist that minimizes all the interestingtopological parameters of the network. We also introduce arequirement for the use of several twists inmultidimensional torus with adaptive routing.Keywords—Twisted torus, network topologyAI. INTRODUCTION 1234N N-dimensional torus is the Cartesian productof N rings. The torus topology has been widelyemployed for the interconnection of large-scalesupercomputers, since it provides competitivetopological properties, it fits naturally to the taskmapping of many supercomputing problems and issimple to understand from the programmer's view.Symmetric tori are built from rings of the same length,what under uniform traffic leads to a balanced use of thenetwork resources. A restriction of symmetric tori is thatthe number of nodes must be a certain power, D N , whereD is the number of nodes in the ring.Asymmetric (or mixed-radix) tori are those generatedfrom the product of N rings with different lengthsD 1 , D 2 , . . . , D N . This builds a torus topology withvariable number of network nodes, D 1 × D 2 ×. . .× D N ,and thus has been commonly used in commercialmachines such as the IBM BlueGene [1], the Cray XK6[5] or the Tofu interconnect in the K computer [2],currently the Top1. There are several reasons to useasymmetric torus, ranging from desiring a given numberof network nodes, increasing the size of an existingmachine or even mechanical limitations such as in theCray T3D network [6]. However, asymmetric tori sufferfrom congestion in the longest dimension, what cancause performance bottlenecks in the network. Underrandom uniform traffic, the average number of hopstraversed on each dimension of the torus is proportionalto its length, but the number of links per dimension oneach router is constant. Therefore, the links on thelongest dimension are the first ones to reach saturation,limiting the performance of the overall network. Othertypes of traffic are also limited by the differencebetween the different lengths.The use of a twist in the peripheral links of one of thedimensions was first proposed in [7] as a mechanism toimprove the topological properties and the performanceof the network. Subsequent work [3], [4] has formallycharacterized such topology, called Twisted Torus (TT),in the specific cases of 2: 1 (2D) or 2: 1: 1 (3D) aspectratios. Specifically, 2: 1 Rectangular Tori (RT) havetwice as many nodes in the long dimension than in theshort one; therefore, under uniform traffic, the links inthe long dimension are saturated, but the utilization ofthe links in the shortest dimension is limited to 50% [4].In this case, the optimal twist is the length of the shortdimension: Adding a twist of a columns to theperipheral vertical links of a 2a × a RT regains thesymmetry of the X and Y dimensions, and allows for fulllink utilization. The resulting layout of these topologiesis presented in Figure 1 for a 8 × 4 torus. The twistedvertical links in Figure 2 modify the node distancedistribution and resulting link utilization, leading tothroughput increases of 50% under uniform traffic.Other traffic patterns are also improved with differentfactors [4].Fig. 1. 8 × 4 Rectangular Torus.1Grupo de Arquitectura y Tecnología de Computadores,Universidad de Cantabria. Email: enrique.vallejo@unican.es2Dep. Arquitectura de Computadores, UPC. Email:mmoreto@ac.upc.edu3Grupo de Arquitectura y Tecnología de Computadores,Universidad de Cantabria. Email: carmen.martinez@unican.es4Grupo de Arquitectura y Tecnología de Computadores,Universidad de Cantabria. Email: ramon.beivide@unican.esFig. 2. 8 × 4 Rectangular Twisted Torus, with a twist of 4 columns.JP2011-421

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Recent technological improvements have largelyincreased the router pin bandwidth, allowing theconstruction of high-degree routers [5]. In the case ofusing torus topologies, this leads to the construction ofmulti-dimensional torus. Nowadays, machines using 5Dor 6D torus are already being deployed, such as thenewest BlueGene/Q [9] or the Tofu 6D torus [2]. Anyasymmetry in the dimensions of these topologies is evenmore important, since under uniform traffic it is thesingle longest dimension which limits performance.The optimal application of twists to the peripherallinks of asymmetric torus of arbitrary aspect ratio hasnot been studied yet. In this paper we present an earlystudy of the topological properties of asymmetrictwisted torus based on exhaustive search of the optimaltwist values. Specifically, this paper has two maincontributions:• We perform an exhaustive search of the optimaltwist values and observe that there is no singletwist that optimizes all the relevant topologicalparameters of asymmetric tori with arbitraryaspect ratio, such as diameter, average distanceor link imbalance.• We show how certain combinations of twists ina multidimensional twisted tori lead totopologies which are not node-symmetric, andthus do not allow for adaptive routing.The rest of the paper is organized as follows. InSection II we introduce the parameters and notation thatwill be used in the rest of the paper. Section III studiesthe twist values that optimize different networkparameters of 2D TT, showing that for arbitrary aspectratios there is no optimal twist for all parameters.Section IV deals with multiple twists inmultidimensional TT, showing that not any combinationof twists leads to node-symmetric networks. Finally,Section V concludes the paper and presents the ongoingwork.II. NOTATION AND NETWORK PARAMETERSIn this paper, we consider N-dimensional torus.Typical values for N are N = 2 for the RectangularTorus (RT) or N = 3 for the Prismatic Torus (PT),following the terminology introduced in [4]. Highervalues of N lead to Hypertorus (HT), or, in general, toruswith N dimensions.The different dimensions are typically labeled usingthe letters X, Y and Z. The number of nodes on eachdimension will be denoted as d X , d Y , d Z . Withhypertorus the dimensions are typically labeledD 1 , D 2 … , D N and the size of each dimensiond 1 , d 2 , … , d N . The aspect ratio represents the relationbetween the number of nodes on the differentdimensions.Node labeling — Each node in the network will belabeled with a tuple (x, y, z) or (x 1 , x 2 , … , x N ), witheach element indicating the coordinate in thecorresponding dimension in the range [0, d i ). Anexample of this notation in a 2D torus is shown inFigures 1 and 2, with d X = 8 and d Y = 4 .Peripheral links — In a traditional torus, a link indimension J joins nodes with coordinates(x 1 , … , x j , … , x N ) and (x 1 , … , (x j ± 1) mmm d J , … , x N ).It can be observed that the modulo operation is onlyused for peripheral links, and that peripheral linksalways join nodes from the same row or column.Peripheral twists — A twisted peripheral link breaksthe previous rule. We will use the expression t JJ to referto the twist of dimension J over the dimension K withJ ≠ K. A nonzero value in t JJ means that the peripherallink on dimension J also modifies the coordinate indimension K. The modification is called the value of thetwist, or skew. Specifically, considering only thedimensions J and K, the node with coordinates d J −1, x K will be connected with 0, x K + t JJ mmmmalong the peripheral link on dimension J. The twist t JJdoes not modify other coordinates.The example in Figure 2 shows a 2D Twisted Toruswith d X = 8, d Y = 4, t XX = 0 (no twist on the horizontalperipheral links) and t YY = 4. Observe how the node (0,3) is connected to (4, 0), while node (0,0) is connectedto (4,3). In an N-dimensional torus the number ofpossible twists is N(N − 1), regardless their value. For2D, these are only t XX and t YY . For 3D, these aret XX , t XX , t YY , t YY , t ZZ and t ZZ . In general, we will onlycite those twists that are nonzero.Considering this notation, the previous work in [4]studied three different twisted topologies:• Rectangular Twisted Tori (RTT): A 2Dtwisted torus with d X = 2a, d Y = a andt YY = a.• Prismatic Twisted Tori (PTT): A 3D twistedtori with d X = 2a, d Y = d Z = a and t YY = a.• Prismatic Doubly Twisted Tori (PDTT): A 3Dtwisted tori with d X = 2a, d Y = d Z = a,t YY = a and t ZX = a.The interest of the peripheral twists relies on the factthat they allow modifying the topological parameters ofthe interconnection network, and thus its performance,without altering the internal mesh interconnectionpattern. In order to quantify the performanceimprovement or penalty derived from the introduction ofa certain twist, we need to measure its effect.The key performance indicator of any network is theexecution time of a set of parallel applicationsappropriately tuned. However, such execution timedepends on many factors, such as the data partitioningand task mapping mechanisms employed, which shouldalso depend on the specific topology being used. Suchstudy is out of the scope of the current paper. In order toperform an early evaluation, synthetic random uniformtraffic is typically used, which reflects on average thetopological parameters of the network. The mostinteresting topological parameters will be:Diameter — denoted k, it is the length of the longestminimum path between any two nodes in the network.The diameter of the network conditions the maximumlatency in the network. Then, it can also affect thelatency of certain operations, such as collectiveoperations implemented using broadcast trees.JP2011-422

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011The diameter in a traditional torus without twists is thesum of the diameters of the individual rings, k = k X +k y + k Z + ⋯. However, when a twist is applied on anyof the dimensions the diameter must be recalculatedfrom the resulting distance distribution.Average distance — denoted k, it is the averagelength of all minimum paths. The average distance is anindicator of the base network latency, this is, the latencywithout congestion in the network.The average distance will be an indicator of themaximum throughput in the network. The lower thenumber of hops a packet has to travel, the higher thenumber of packets accepted.In a torus topology there are different classes of links,separated according to their dimension. The averagedistance k can be divided into the individual averagedistances per dimension, k = k X + k Y + k Z + ⋯. Eachof these individual distances represents the averagenumber of hops that a packet has to traverse along thelinks in a given dimension. Since there are the samenumber of links on each dimension, the highest averagedistance per dimension will indicate the dimension thatwill first suffer from saturation and will limitperformance.In a perfectly balanced network all the individual perdimensiondistances are the same. However,asymmetries in the network dimensions lead to differentaverage distances per dimension. The application of atwist on the peripheral links of a torus modifies theaverage distances per dimension; the selection of theappropriate twist to minimize these distances is studiedin this paper.Based on the average distances per dimension, wedefine two additional metrics:Maximum Average distance per dimension —denoted maxk ı . This value is the maximum of theindividual distances k X , k Y , k Z , …. As argued before, thisparameter will determine the saturation limit of thenetwork; therefore, the expected throughput depends onthis value as discussed in [4].Imbalance — The imbalance is defined here as thequotient I = N×max(k ) ı. Ideally, I = 1 meaning that allklinks are equally used. A high imbalance value meansthat there is a significant deviation in the usage of thenetwork dimensions.distances in the network. Even more, the twist equals thelength of the shorter dimension, what might bebeneficial for the resource balancing. This conditiononly occurs when the aspect ratio is 2: 1.In this section we study for different aspect ratios howeach of these network parameters varies with theselected twist. We will focus on the 2D TT. Our initialtests showed that the results are similar for differentnetwork sizes when the aspect ratio is similar. Then, wewill fix the number of rows in the topology to a constantreference value (for example d Y = 12 in ourexperiments), and vary the number of columns d X fromd Y to 4 · d Y , to sweep an aspect ratio ranging from 1: 1to 4: 1.For each configuration, we explore the topologicalparameters of the network with all the possible twistsfrom t YY = 0 to t YY = d X /2 (higher values lead tosymmetric results). With each twist, we use a breadthfirstsearch algorithm to find the shortest paths betweennode 0 and any other node in the TT. For each of theseshortest paths, we record the number of hops perdimension, and when the same destination can bereached by different routes, we average the result amongthem all. With all the routes in the network we calculatethe diameter, average distance, maximum averagedistance per dimension and network imbalance for eachpossible twist t YY . Finally, we calculated the twist thatoptimized each of the four parameters of interest.The next plots show the results for each parameter. Oneach graph we plot the results corresponding to fourtwisting strategies:- Not using a twist, t YY = 0, labeled no_tw.- The optimum twist for that given parameter,opt_tw.- The twist equals half of the longest dimension,t YY = d X /2, labeled tw_mid.- The twist equals the shortest dimension, t YY = d Y ,labeled tw_rows.Figure 3 shows the results for the diameter. The linesfor no_tw and opt_tw are shown in gray. We observe thatthere is a significant improvement in the diameter whenthe optimum twist is applied, especially as the aspectratio grows. It can be also observed that the twist thatprovides the optimum diameter is the one with t YY =The application of a certain twist will modify thedistance distribution in the network, and all the previousparameters with it. The next section presents a search forthe optimum twists in terms of the different topologicalparameters introduced in this section.III. OPTIMUM TWISTS FOR 2D TORUS WITHARBITRARY ASPECT RATIOIn this section we focus on 2D Twisted Torus (TT)with d X ≥ d Y (with more nodes on the X dimension thanin the Y dimension), and a single twist of dimension Yover dimension X. The work in [4] proves that theoptimal twist in terms of the previous parameters for a2a × a Twisted Torus is t YY = a. This twist equals themiddle of the longest dimension, connecting the firstcolumn with the middle one, thereby reducing theFig. 3. Diameter of a network with different twisting strategies, asthe aspect ratio increases from 1:1 to 4:1. The number of rowsis always 12.JP2011-423

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Diameter of a network with different twisting strategies,as the aspect ratio increases from 1:1 to 4:1, normalized to theoptimum value on each case. The number of rows is always 12.Fig. 5. Average distance with different twisting strategies, as theaspect ratio increases from 1:1 to 4:1, normalized to theoptimum value on each case. The number of rows is always 12.240%Normalized Imbalance220%200%180%160%140%120%opt_twno_twtw_midtw_rows100%Fig. 6. Maximum partial distance with different twisting strategies,as the aspect ratio increases from 1:1 to 4:1, normalized to theoptimum value on each case. The number of rows is always 12d X /2, labeled tw_mid. Finally, we can observe how withd X = 24 columns, the three values meet: this isprecisely the 2: 1 aspect ratio network studied in [4].How much diameter reduction can we expect from anoptimum twist? Figure 4 shows the previous plots,normalized to the value obtained in each case with theoptimum twist. It is clear that a twist equal to half thelongest dimension always provides the optimum value interms of diameter, and that the diameter can be reducedin more than 40%.Figures 5 to 7 show the results of the other threeparameters of interest, in all cases normalized to theoptimum value per network size.Figure 5 shows the results for the average distance. Asimilar study was already presented in [3]. As with thediameter, the twist to the middle of the longestdimension provides the best performance, except for thecase of a very high aspect ratio. The improvement overthe RT increases from 5% to 40% as the aspect ratiogrows. In the case of the twist tw_rows, the performanceremains within 5% of the optimal value for aspect ratioslower than 3: 1, increasing to up to 14% for larger aspectratios.The maximum partial distance per dimension ispresented in Figure 6. It is very relevant the highdifference between the original, untwisted torus, and the80%12 16 20 24 28 32 36 40 44 48Columns (dX)Fig. 7. Imbalance of a network with different twisting strategies, asthe aspect ratio increases from 1:1 to 4:1, normalized to theoptimum value on each case. The number of rows is always 12.best result that can be obtained. Depending on the aspectratio, the original torus is more than an 80% slower interms of throughput (which depends on this parameter).A proper twist reduces the maximum distance perdimension and increases throughput. With a twist oftw_rows or tw_mid, this metric is within 10% of theoptimal twist, and within 5% of the optimal twist foraspect ratios lower than 3: 1.Finally, Figure 7 shows the imbalance. If no twist isused, the imbalance grows linearly with the aspect ratioas expected. When the proper twist is applied, the usageof the links on each dimension can be almost perfectlybalanced. Also, it is interesting to notice that from aspectratio 2: 1, the tw_rows approach obtains the optimumresult.All the previous figures have presented the results ofthe different parameters; however, the specific twist thatobtains the best result in each case was not presented.Figure 8 shows the twists that get the best results foreach of these 4 parameters.From this figure we can observe that, in general, for agiven aspect ratio there is no single twist value thatoptimizes all the network parameters. For example,diameter and average distance are approximatelyoptimum with tw_mid. However, for large aspect ratiosthe optimum twist to reduce the average distanceJP2011-424

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 8. Optimal twist value for each parameter with different aspectrations. The number of rows is always 12.decreases. Regarding the maximum partial distance perdimension (which conditions the performance undersaturation) we observe that the optimum skew is similarto tw_mid. up to aspect ratios close to 2: 1, but it laterdecreases. Finally, it is really interesting that the bestimbalance in a network with aspect ratio higher than2: 1 is provided by the tw_rows approach, regardless thenumber of columns.The interesting conclusion to be drawn from thisfigure is that for arbitrary topologies there is no singletwist value that minimizes all the interestingperformance related metrics. For example, this impliesthat, with a large aspect ratio such as 4:1, there is a twistthat provides a higher throughput under saturation(maximum partial distance lower) although the traffic isnot as balanced as possible (best imbalance); bycontrast, the balanced approach makes the same usage ofboth horizontal and vertical channels, but since theoverall average distance in that case is higher, theperformance is lower.IV. USE OF MULTIPLE TWISTSSection III studies the selection of an optimum twist ina 2D Twisted Torus (TT) depending on differenttopological parameters of interest. However, the study inthat section assumes a 2D TT with d X ≥ d Y and a singletwist t YX . The first assumption can be done without anyloss of generality; the selection of the twist (dimensionY over dimension X) is the one that reduces the averagedistance on the longest dimension X. A similar studyusing t XY does not provide better results.In this section we consider the case of applyingmultiple twists to the same torus network. We willinitially study the case in 2D (similarly to [3]), and thenconsider higher dimensions.The graph in Figure 9 represents a 4 × 4 TT withtwists t XY = −1 and t YX = 1. Thus, all the peripherallinks have some twist.Although the topological parameters of this graphcould be studied as in the previous section, the problemnow is that the graph is not node-symmetric. The nodesymmetryproperty in a graph of this kind implies thatthe routing between any pair of nodes source anddestination can be computed from the difference of theircoordinates, rather than considering the whole topologyand the specific identity of the source and destinationFig. 9. 4 × 4 Twisted Torus with t XX = −1 and t YY = 1.nodes. Specifically, without node-symmetry the routingfunction cannot be performed by means of a routingrecordcomputed at the source node, and adaptiverouting is not allowed.We show this case with an example similar to the onein [3]. Consider the graph in Figure 9 and the routingfrom node (0,2) to (3,0). One possibility is to go up(Y +) to the intermediate node (0,3) and then left (X −)to the destination node (3,0) through the peripheraltwisted link. However, if the sequence of jumps isfollowed in the opposite order, then the first jump goesleft (X −) to (3,3) using a peripheral link, and then up(Y +) to (0,0) using another peripheral link. The finalnode differs depending on the order of the dimensionsfollowed, because the number of peripheral twisted linksvaries and each peripheral link modifies the othercoordinate. Therefore, routing in the graph of Figure 9must be either table-based, or use source routing withfull knowledge of the network topology, what restrictsmany of the benefits of the torus topology.We consider now the case of multiple twists inmultidimensional torus. Cámara et al present in [4] two2a × a × a 3D twisted torus topologies using one twist(PTT, t YX = a) or two twists (PDTT, t YX = a andt ZX = a). Both cases are node-symmetric, so they do notsuffer from the restrictions considered above for the 2DTT with two twists.The obvious question now is, which combinations oftwists break the node-symmetry of a torus topology?The following result characterizes it.Theorem — A multidimensional twisted torus is notnode-symmetric if there exists a dimension J such thatt IJ , t JJ ≠ 0 for some other dimensions I and K.Proof — The lack of node-symmetry can be proven byfinding a source node from which a sequence of jumpsleads to different destination nodes depending on theorder of the jumps.Assume the condition is true. For simplicity, we willassume t IJ , t JJ > 0. First, we consider the case I ≠ K.Specifically, we will only consider the node labels(i, j, k); the rest of coordinates, if they exist, shouldremain constant. The source node of the proof will bed I − 1, d J − t IJ − 1,0 and the routing record (1,1,0).If the jump on dimension I is taken first, a twistedperipheral link will be used to reach the intermediatenode 0, d J − 1,0. The second jump on the dimension JJP2011-425

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011uses another twisted peripheral link, leading to thedestination node 0, 0, t JJ .By contrast, if the jump on dimension J was takenfirst, then an internal link goes to d I − 1, d J − t IJ , 0,and the second jump on I goes through a twistedperipheral link to (0,0,0).Finally, the case of I = K also leads to a graph whichis not node-symmetric, as presented in the example ofFigure 9 with I = K = X. As in the previous case, if weconsider the source node d I − 1, d J − t IJ − 1 androuting record (1,1), we will reach destination nodest IJ , 0 or (0,0) depending on the order of the jumps. ∎We conjecture that the condition in the previoustheorem is sufficient and necessary, but do not have aformal proof yet.With the previous theorem we can consider thenumber of combinations of twists that maintain thenode-symmetry for an N-dimensional torus. The numberof possible twists is N(N − 1) as discussed in Section II.However, with node-symmetry there will be at mostN − 1 concurrent twists; otherwise, some dimensionwill necessarily have a twist in its peripheral links andreceive the effect of a twist in another dimension, whatbreaks the node-symmetry according to the theorem. Wewill consider the lower-grade cases next.In the 2D case there are two possibilities, t XY or t YX ,but not both twists simultaneously. We can assumewithout loss of generality that the topology is set so thatall twists are applied over lower-order dimensions (anyother combination will be isomorphic), so the onlysingle possible twist to study will be t YX .In the 3D torus there are two combinations of twotwists: (t YX , t ZX ) and (t ZX , t ZY ). The first one wasapplied for torus with 2: 1: 1 aspect ratio in [4] to buildthe PDTT. We do not know of any use of the secondcombination in previous work. Also, there are threedegenerated cases when one of these twists is 0: t YX , t ZXand t ZY . Without forcing a dimension order in the twists,the number of combinations would be much higher.For multidimensional torus, the combinations of validtwists grows very quickly. Any study to optimize theparameters of the network using twists should considerall these possibilities with all their possible values. Thus,an empirical study based on a breadth-first searchappears very costly as the number of dimensions grow.V. CONCLUSIONS AND FUTURE WORKIn this paper we have identified four topologicalparameters of torus topologies that condition differentaspects of the network behavior. The use of twists insome of the peripheral links modifies these topologicalparameters and can improve the performance of thenetwork, but in the general case, it is impossible tooptimize all of the parameters at the same time becausethe required twists differ.We have also introduced a clear notation for the twistsand criteria to consider which combinations of twistsbuild node-symmetric networks from multidimensionaltorus, which are expected to be more used in the nearfuture.We have many lines of ongoing work. A formal proofof the conjecture in Section IV is critical to validate thework. Also, the high number of combinations ofpossible twists (and their specific values) formultidimensional torus makes an empirical study likethe one in this paper not feasible. It would be interestingto formalize the twisted torus topology and study itsproperties using graph theory.Regarding the impact on performance, we havediscussed how the applications should be aware of theunderlying topology to optimize data partitioning andtask mapping. Performing these tasks for amultidimensional torus with arbitrary twists is nottrivial, and currently under study.ACKNOWLEDGMENTThis work has been sponsored by the Ministry ofScience and Innovation under Projects TIN2010-21291-C02-02 and TIN2007-60625, the HiPEAC network ofExcelence and the Supercomputing and e-scienceConsolider Project.REFERENCES[1] N.R. Adiga, M.A. Blumrich, D. Chen, P. Coteus, A. Gara, M.E.Giampapa, P. Heidelberger, S. Singh, B.D. Steinmacher-Burow,T. Takken, M. Tsao, and P. Vranas, “Blue Gene/L TorusInterconnection Network,” IBM J. Research and Development,vol. 49, nos. 2/3, pp. 265-276, 2005.[2] Y. Ajima, S. Sumimoto, T. Shimizu, "Tofu: A 6D Mesh/TorusInterconnect for Exascale Computers," Computer, pp. 36-40,November, 2009[3] J. M. Cámara, “Desplazamiento de enlaces periféricos paramejorar las prestaciones de redes toroidales con dimensionesdesiguales”. PhD dissertation. Santander, 2010.[4] J. M. Camara, M. Moreto, E. Vallejo, R. Beivide, J. Miguel-Alonso, C. Martinez, J. Navaridas, "Twisted Torus Topologiesfor Enhanced Interconnection Networks," IEEE Transactions onParallel and Distributed Systems, pp. 1765-1778, Dec. 2010.[5] Cray Inc. Cray XK6 specifications, available online athttp://www.cray.com/Products/XK6/Specifications.aspx,Retrieved June 2011.[6] J. Kim, W. Dally, B. Towles, A. Gupta. “Microarchitecture of aHigh-radix Router,” Proceedings of the 32nd InternationalSymposium on Computer Architecture (ISCA-32), pp. 420–431,Madison,WI June 2005[7] S. Scott and G. Thorson, “The Cray T3E network: adaptiverouting in a high performance 3D torus”, IEEE HotInterconnects, 1996.[8] C. H. Sequin. 1981. “Doubly twisted torus networks for VLSIprocessor arrays”. In Proceedings of the 8th annual symposiumon Computer Architecture (ISCA '81). IEEE Computer SocietyPress, Los Alamitos, CA, USA, 471-480.[9] T. Budnik, B. Knudson, M. Megerian, S. Miller, M. Mundy, W.Stockdell. "Blue Gene/Q Resource Management Architecture",3 rd IEEE Workshop on Many-Task Computing on Grids andSupercomputers (MTAGS10), 2010.JP2011-426

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Performance analysis of an IEEE 802.21 basedVertical Handover protocol using ns-2Johann Márquez-Barja, Carlos T. Calafate, Juan-Carlos Cano and Pietro Manzoni 1Abstract— Currently, due to the ubiquity of wirelesstechnologies, users demand continuous connectivityguaranteeing the Quality of Service (QoS) requiredfor their communications. In order to choosethe best network among different alternatives, theIEEE 802.21 standard has been developed. It offersresources to perform Vertical Handover (VHO)among heterogeneous wired and wireless networks.We present experiments in order to evaluate the verticalhandover performance when relying on the IEEE802.21 standard in scenarios where Wi-Fi, WiMAXand UMTS technologies are available. Experimentalresults show that a technology-aware vertical handovermechanism is able to achieve an adequate performancewhen traffic congestion is low.Keywords— IEEE 802.21, Wi-Fi, WiMAX, UMTS,Vertical handover (VHO), Vertical Handoff, RoamingI. IntroductionNOWADAYS there are different wireless accesstechnologies allowing users to stay “always on”.Mobile computing is demanded to perform our tasksand duties, which can be as simple as reading thenews, or as complex as medical monitoring applications.Due to the mobility offered by wireless technologies,users not only demand continuous connectivity,but also QoS for their communications. Under the“always best connected” paradigm [1], users demandto be connected while they cross over the coverageof the access points of different technologies. Tofulfill their requirements, Vertical Handover (VHO)techniques make possible to switch from one wirelesstechnology to another in a seamless manner, offeringmobile users the possibility of remaining connectedunder certain QoS criteria. Figure 1 illustrates theconcept of VHO where a mobile device crosses differentcoverage areas, seamlessly switching from onetechnology to another. The complete VHO processtakes into account service continuity, network discovery,network selection, security, mobility management,and QoS issues [2], focusing mostly on the latter.In this work we present a performance evaluationof a technology-aware Vertical Handover DecisionAlgorithm (VHDA) which takes into account theavailability and network capacity as its main decisionparameters in a scenario composed of multiple accesspoints of Wireless Fidelity (Wi-Fi), Worldwideinteroperability for Microwave Access (WiMAX),and Universal Mobile Telecommunications System(UMTS) technologies. In this scenario, the mobile1 Universitat Politècnica de València, Cami de Vera, s/n,46022 Valencia, España. {jomarba, calafate, jucano,pmanzoni}@disca.upv.esFig. 1.Horizontal and Vertical Handover.devices are able to connect to these technologies byrelying on multi-interfaces under the IEEE 802.21standard [3]. We evaluate the VHO latency, throughput,packet loss, and the end-to-end latency in orderto assess the effectiveness of the VHO process.The rest of this paper is organized as follows: SectionII presents the most relevant works in the literaturecovering VHDA and VHO strategies. Anoverview of the VHO is also presented in Section III.Section IV presents a description of the VHDA used.The simulation framework set used for experimentationis described in Section V. Performance evaluationresults are presented in Section VI. Finally,Section VII presents the conclusions of this researchwork.II. Related WorkIn the late nineties, the first approaches offeringconnectivity among heterogeneous networks were introducedby Stemm and Katz [4]. These authorsdeveloped an application based on Mobile IP androuting which was able to manage handovers amongdifferent networks such as the IBM Infrared WirelessLAN, the AT&T WaveLAN and the Metricom RicochetNetwork as in-building, campus, and wide areaunderlying wireless technologies, respectively.Nowadays, several works can be found in the literatureand industry covering VHO among differenttechnologies such as Wi-Fi, Wireless BroadbandJP2011-427

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(WiBro), WiMAX, UMTS and Low Earth Orbit(LEO). Due to the broad variety of solutions forthese technologies, no single VHO technology embracesthem all. Nevertheless, the IEEE 802.21Working Group is working on the Media IndependentHandover Services Protocol [3] which providesa homogeneous function-interface between heterogeneousnetwork technologies.De la Oliva et al. [5] present a study case where themobile terminal is capable of operating in conjunctionwith the IEEE 802.21 protocol. Although theproposed scenario only considers Wi-Fi and UMTSas underlying wireless networking technologies, theuse of the Received Signal Strength (RSS) and theservices offered by the IEEE 802.21 present a usefulevaluation when the VHO is initiated by themobile node (Mobile-Initiated Handover (MIHO))evaluating the VHO Latency as well as the VHOPacket loss. Nevertheless, Buburuzan and Nyamen[6] present an evaluation of VHO initiation processeseither initiated by the mobile node (MIHO) or thenetwork (Network-Initiated Handover (NIHO)) whendealing with WiMAX and Wi-Fi technologies underthe IEEE 802.21 protocol. A VHO evaluation basedon the performance of the Session Initiated Protocol(SIP) in an inter-domain and inter-technology scenariopowered by the IEEE 802.21 is presented byDutta et al. [7], showing the performance of theVHO while voice is being transmitted and evidencingthe continuity of the service and the effect of theVHO latencies.Our work focuses on three technologies: Wi-Fi,WiMAX and UMTS, and it uses a VHDA whichtakes into account not only the RSS and the IEEE802.21 services, but also the capacity offered by thedifferent technologies. We have used Constant BitRate (CBR) traffic in order to evaluate VHO in aninter-domain and inter-technology scenario evaluatingVHO latency, end-to-end latency, packet loss,and throughput.III. VHO OverviewIn the literature we can find VHO proposals [8],[9] that divide the complete VHO process into threephases: i) Handover information gathering, ii) Handoverdecision, and iii) Handover execution. Figure2 shows the interactions among these three phases.Every phase is in charge of performing some specificduties. The handover information gathering phasecollects information from diverse sources of the systemsuch as network properties, access points, mobiledevices, and user preferences. The handover decisionphase is one of the most critical processes duringthe handover. Once the gathered informationis processed by the VHDA, the resulting process decidesWhen and Where to trigger the handover. Thisdecision takes into account several parameters in orderto choose the best candidate network to handoverto. Concerning algorithms that allow evaluatingmulti-parameters, we can find techniques suchas fuzzy logic, neural networks, and pattern recognition,among others [10]. Finally, the execution phasecommits the VHO itself, leaving the first networkand attaching to the access point of the second network;this process must be done seamlessly, reachinglow latencies and minimal packet loss. Usually,to manage mobility at this phase, the Mobility forIP (MIP) protocol is used in order to guarantee theseamless feature.Fig. 2.Handover Management Procedure.A. Media Independent Handover Function (MIHF)The MIHF protocol defined by the IEEE 802.21standard establishes the messages exchanged betweenpeer MIH entities for handover, offering a commonmessage payload across different media (802.3,802.11, 802.16, Cellular). The standard refers aslower layers to the technology dependent components,and as upper layers to the requesting modules.These lower layers can be accessed by different functionsto retrieve information for detecting, preparingand executing the VHO, while the upper ones demandthat information; therefore, the latter are alsoreferred to as the Media Independent Handover User(MIHU). The MIHF offers to both lower and upperlayers a Service Access Point (SAP) in order toexchange the service messages. Figure 3 shows thebasic 802.21 architecture. The basic services offeredby the MIHF are briefly described below:A.1 Media Independent Event Service (MIES)This service detects the changes on the lower layers,e.g. changes on the physical and data link layer.The MIHF notifies events occurring in the lower layersto the MIHUs as they have requested. The MIEScovers events such as:• State change events (link up, link down, link pa-JP2011-428

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011rameter changes).• Predictive events (link going down).• Network initiated events (load balancing, operatorpreferences).A.2 Media Independent Information Service (MIIS)The MIIS allows the MIHF to discover its networkenvironment gathering information that the upperlayers make use of to make decisions. The informationelements refers to the list of available networks,location of Point of Attachment (PoA), operator ID,roaming partners, cost, security, QoS, PoA capabilities,and Vendor specific information, among others.A.3 Media Independent Command Service (MICS)The MICS allows the MIHU to take control overthe lower layers through a set of commands. Withthe information gathered by the MIES and MIIS, theMIHU decide to switch from one PoA to another.The commands allow not only to execute the handover,but to set different parameters in the lowerlayers elements. Depending on which entity has thehandover control, some services are more useful thanothers. The following commands are typically usedby the MICS:• MIH Handover Initiate. Used between networkand mobile device.• MIH Handover Prepare. Used between the oldnetwork (PoA) and the new network.• MIH Handover Commit. Used between networkand mobile device.• MIH Handover Complete. Used between networkand mobile device and network to network.A.4 AmendmentsIn order to fully provide handover services, the802.21 must be implemented into network devicesand mobile devices. The media specific amendmentsrequired by MIHF are defined as follows• Container for MIH messages for 802.11 are definedin the 802.11u [11]• Container for MIH messages for 802.16 are definedin the 802.16g [12]• The 3GPP-SAE (System Architecture Evolution)is working for 3GPP. [13]• The IEFT MIPSHOP (Mobility for IP: Performance,Signaling and Handoff Optimization) ishas defined the Transport for MIH Protocol [14]• 802.3 is desired.IV. Overview of the Vertical HandoverDecision Algorithm (VHDA)The VHO process considered in our experimentsuses the IEEE 802.21 standard at the first phase inorder to gather information, notify events and executecommands. For the decision phase, we haveused a VHDA that considers the availability and thebandwidth offered for the decision making process.Figure 4 shows the state diagram of the VHDA whenUpper Layers (L3 and above)SIP MIPv4 MIPv6 HIP ....Mobility ManagementMIHEventsLinkEventsMIH_SAPSmartTriggersMIH_Link_SAPMIH UsersMIHCommandsLinkCommandsLower Layers (L2 and below)Handover Management802.21 MIH FunctionHandoverMessagesInformationServiceInformationServiceProtocol and Device Hardware802.3 802.11 3GPP 802.16Fig. 3.InformationServiceIEEE 802.21 Architecture.selecting a candidate network to switch to. As observed,the MIHF set at the User Equipment (UE) iscontinuously sensing the interfaces. When an eventis triggered, and depending on the type of event, theVHDA performs different routines and subroutinesbased in MICS and MIES in order to select the bestcandidate network, or simply chooses the UMTS networkby default, due to the full UMTS coverage. Finally,considering the execution phase of the VHOprocess, we use Mobility support for Internet Protocolv.6 (MIPv6) to manage the mobility issues. Itis important to emphasize that the 802.21 events:LINK UP and LINK DOWN, determine the behaviorof the VHDA. When a LINK DETECTED eventoccurs, the user equipment will trigger other eventssuch as LINK UP if the technology detected is ableto offer more bandwidth, negotiating with the newbase station for the IP address; MIPv6 is in chargeof this negotiation and notification to different componentsof the system. All these processes requirecomplex actions which imply latency. On the otherhand, when a LINK DOWN event is detected, onlya notification is performed by the MIPv6 agent sincethe interface was already configured in a previousLINK UP. So, there is no added latency to theseprocesses.V. Simulation frameworkConsidering networking in general, there are severaltools for simulation. Nevertheless, consideringVHO in particular, there are only a few simulationtools available. To address this shortage, the NationalInstitute of Standards and Technology (NIST)has developed a tool for seamless mobility [15] based....JP2011-429

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111500UMTSDistance (m)1200AWiMAX(1)Wi-Fi(2)Wi-Fi(1)WiMAX(2)Wi-Fi(3)900600ComponentFig. 4.VHDA state diagram.TABLE IVHO scheme components.Wi-FiWiMAX UMTSAccess Point 3 2 1Theoretical Bw 54 70 5(Mbps)Bw offered (Mbps) 28.2 16.3 2.7Advertisement Interval100 5000 -(ms)Coverage (m) 250 500 1000in a widely used simulator for wired and wireless networks:the Network Simulator (ns-2). The NISTmobility package for the ns-2 allows to simulate Wi-Fi, WiMAX, and UMTS technologies, as well asperforming handovers among these technologies ina seamless manner. Moreover, it allows operatingunder the IEEE 802.21 standard offering most of itsfeatures.For our experiments we have evaluated the VHDAby setting up a scheme considering three wirelesstechnologies: Wi-Fi, WiMAX, and UMTS. Our scenariois a square area of 3000 m 2 area where 6 accesspoints (1 node B for UMTS, 2 base stationsfor WiMAX, and 3 access points for Wi-Fi) havebeen deployed. Each element of the network has anMIH entity to manage the 802.21 protocol directives.Table I presents the elements and the configurationused. Moreover, Figure 5 shows the scenario used forour studies where the user equipment demands CBRtraffic. The mobile terminal has always UMTS connectivityand, while it moves, it discovers new wirelessnetworks; it performs a VHO if any of the newnetworks offers a higher performance, or if the networkbeing used disappears. Since our work focuseson VHO itself, the coverage areas of each technologydoes not extend over a very large area to avoid longperiods under only one technology. Figure 6 presentsthe position of each access point and its coveragearea. The initial position for the user equipment isrepresented by point A; the user equipment moves tothe right in a straight line across the different coverageareas at a constant speed of 3 meters per second.0 300 600 900 1200 1500 1800 2100 2400 2700 3000 3300Distance (m)Fig. 6.Wireless technologies coverage areas.VI. Performance evaluationTo evaluate the performance of the VHO schemewe used the following metrics: i) latency, ii) throughput,iii) and packet loss. In order to obtain reliableresults, we performed several experiments varyingrandomly the seed. By obtaining several simulationresults per test we assure that the obtained meanvalues are within strict confidence intervals.Concerning VHO performance, there exist differentpoints of view about the evaluation metrics tobe used in order to perform an accurate analysis.However, it is important to establish two evaluationlines: the underlying wireless technologies and theVHO itself.A. Wireless Technologies performanceIn order to evaluate the performance of each wirelessnetwork, we evaluated the performance experiencedby a mobile terminal throughout the simulationtime. Figure 7 shows the network being usedwhen moving along the scenario at a speed of 3m/s. For the period of time that the user equipmentis connected to a network, the throughputreached is the maximum for each technology. Figure8 clearly shows the throughput reached by each networkwithin a certain period of time. Wi-Fi offers thehighest bandwidth, reaching up to 28.2 Mbps. ThenWiMAX offers up to 11 Mbps, while UMTS offers a2.04 Mbps datarate. These values confirm the trendof the results obtained in one of our previous works[16]. Concerning latency, Figure 9 presents the delayperformance of each wireless network throughout thesimulation time. As observed, UMTS takes an averageof 29.96 ms to deliver one packet, while WiMAXand Wi-Fi offer lower latencies: 0.81 and 0.23 ms,respectively.B. VHO performanceFinally, we have performed several simulations toevaluate the performance of the VHO itself. Weevaluate VHO latency and the undelivered packets.Table II shows the latency we obtained forevery VHO process. When it is associated with aLINK UP event, the latencies vary between 1.71 and8.40 milliseconds depending on the technologies involved.Concerning the VHO latency associated withJP2011-430

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011RouterRNCUMTSServerWiMAX(1)Wi-Fi(1)Wi-Fi(2)WiMAX(2)Wi-Fi(3)User EquipmentFig. 5.VHO scheme.1000UMTS WiMAX Wi-FiWireless TechnologiesUMTSWiMAXWi-FiLatency per packet (ms)1001010 200 400 600 800 1000 1200Time (s)Fig. 7. Wireless technologies usage.0.10 200 400 600 800 1000 1200Time (s)Fig. 9. Wireless technologies latency.Throughput (kbps)30000250002000015000100005000UMTS WiMAX Wi-Fi00 200 400 600 800 1000 1200Fig. 8.Time (s)Wireless technologies throughput.LINK DOWN events, we can observe that latenciesreached by the latter processes are between 0.04 and0.11 milliseconds. The difference among these latenciesis due to the number of processes performed,as mentioned before. Concerning packet loss, TableII also presents the number of packets that havenot been delivered while the VHO process was beingperformed. The amount of undelivered data isrelated to the bandwidth available at the new network.As shown in the referred table, VHO processesthat switch from a network with higher bandwidth toa network with lower bandwidth experience a higheramount of packet losses.The results were obtained under “best-case” conditions,since there are no other user equipmentsrequesting services or decreasing the performanceof the available networks. Therefore, the resultingmean values of the different metrics measured mustbe considered as optimistic results, in order to avoidany erroneous conclusion.VII. ConclusionsIn this paper we have performed several experimentsin order to evaluate a technology-aware VHDAwhich considers availability and capacity of the networkfor the decision making process. The frameworkused for experimentation is based on the NetworkSimulator (ns-2), allowing us to evaluate theVHO process under the IEEE 802.21 standard.Experiments showed that VHO processes reachhigher latencies when dealing with newly discoveredcandidate networks due to the processes triggeredin order to perform a seamless VHO. Concerningpacket loss, VHO processes drop packets due to therestriction of bandwidth availability whenever downgradingfrom a network to another. Results were optimisticdue to the “best-case” conditions offered bythe different wireless technologies, since at the scenariono other traffic was decreasing the performanceof each network.We conclude that different improvements canbe suggested to outperform the current evaluatedVHDA whenever the conditions differ from thoseconsidered in this paper. In particular, high degreesof congestion, as well as other parameters (user preferences,mobile capabilities, etc.), will require a moreJP2011-431

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IISimulation results.VHO Event Type ofEventVHO Latency(ms)UMTS-WiMAX(1) Link Up 6.51043 0WiMAX(1)-Wi-Fi(1) Link Up 1.71175 0Wi-Fi(1)-WiMAX(1) Link Down 0.04578 81WiMAX(1)-UMTS Link Down 0.11723 679UMTS-WiFi(2) Link Up 1.75597 0Wi-Fi(2)-WiMAX(2) Link Up 8.40820 0WiMAX(2)-Wi-Fi(3) Link Up 1.88742 0Wi-Fi(3)-UMTS Link Down 0.10205 664UndeliveredPacketssophisticated decision algorithm.AcknowledgmentsThis work was partially supported by the Ministeriode Ciencia e Innovación, Spain, under GrantTIN2008-06441-C02-01.References[1] E. Gustafsson and A. Jonsson, “Always best connected,”IEEE Wireless Communications, vol. 10, no. 1, pp. 49–55, Feb. 2003.[2] Yu C. Chen, Ja H. Hsia, and Yi J. Liao, “Advanced seamlessvertical handoff architecture for WiMAX and WiFiheterogeneous networks with QoS guarantees,” ElsevierComputer Communications, vol. 32, no. 2, pp. 281–293,Feb. 2009.[3] “IEEE standard for local and metropolitan areanetworks- part 21: Media independent handover,” Tech.Rep., 2009.[4] Mark Stemm and Randy H. Katz, “Vertical handoffs inwireless overlay networks,” Springer Mobile Networksand Applications., vol. 3, no. 4, pp. 335–350, 1998.[5] Antonio De-La-Oliva, Telemaco Melia, Albert Vidal,Carlos J. Bernardos, Ignacio Soto, and Albert Banchs,“IEEE 802.21 enabled mobile terminals for optimizedWLAN/3G handovers: a case study,” ACM Mobile Computingand Communications Review, vol. 11, no. 2, pp.29–40, 2007.[6] Teodor Buburuzan and Liliane N. Nyamen, “Performanceevaluation of an enhanced IEEE 802.21 handovermodel,” in 1st Workshop on Wireless Broadband Accessfor Communities and Rural Developing Regions, Karlstad,2008.[7] Ashutosh Dutta, Subir Das, David Famolari, YoshihiroOhba, Kenichi Taniuchi, Victor Fajardo, Rafa M. Lopez,Toshikazu Kodama, and Henning Schulzrinne, “Seamlessproactive handover across heterogeneous access networks,”Springer Wireless Personal Communications,vol. 43, no. 3, pp. 837–855, Nov. 2007.[8] Meriem Kassar, Brigitte Kervella, and Guy Pujolle, “Anoverview of vertical handover decision strategies in heterogeneouswireless networks,” Elsevier Computer Communications,vol. 31, no. 10, June 2008.[9] E. Stevens-Navarro, Yuxia Lin, and V. W. S. Wong, “AnMDP-based vertical handoff decision algorithm for heterogeneouswireless networks,” IEEE Transactions onVehicular Technology, vol. 57, no. 2, pp. 1243–1254, 2008.[10] Anita Singhrova and Nupur Prakash, “A review of verticalhandoff decision algorithm in heterogeneous networks,”in 4th ACM International Conference on mobiletechnology, applications, and systems, New York, NY,USA, 2007, pp. 68–71.[11] IEEE 802.11, “IEEE P802.11u: Interworking with externalnetworks Task Group U,” IEEE Computer Society,2004.[12] IEEE 802.16, “IEEE P802.16g: Management plane proceduresand services (MobileMan),” IEEE Computer Society,2007.[13] 3GPP, “3GPP-SAE: Third generation partnershipproject - system architecture evolution,” 2006.[14] MIPSHOP, “IETF mobility for ip: Performance, signalingand handoff optimization,” 2004.[15] Advanced Network Technology Division- NationalInstitute of Standards and Technology,“Seamless and Secure Mobility,”http://www.antd.nist.gov/seamlessandsecure/.[16] Johann Marquez, Carlos T. Calafate, Juan-Carlos Cano,and Pietro Manzoni, “Evaluating the performanceboundaries of Wi-Fi, WiMAX and UMTS using the NetworkSimulator ns-2,” in 5-th ACM Workshop on PerformanceMonitoring and Measurement of HeterogeneousWireless and Wired Networks, Oct. 2010, pp. 25–30.JP2011-432

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Mecanismos de Comunicación Eficientes enRedes de Altas Prestaciones para Bibliotecasde Paso de Mensajes en JavaRoberto R. Expósito, Guillermo L. Taboada, Juan Touriño y Ramón Doallo 1Resumen— Este trabajo presenta el diseño e implementaciónde mecanismos de comunicación eficientesen redes de altas prestaciones para bibliotecas depaso de mensajes en Java. El auge de las arquitecturasclúster y el aumento exponencial del númerode núcleos en los procesadores actuales hacen quesea necesario el uso de middleware de comunicacióneficiente para obtener la mayor escalabilidad posibleen las aplicaciones paralelas y distribuidas, especialmenteen presencia de redes de altas prestaciones. Entreestas redes de interconexión de clusters destacanInfiniBand, Myrinet y High Speed Ethernet (10/40Gigabit Ethernet). Las especiales características deJava para computación paralela, entre las que destacanun completo soporte multithread y de comunicacionesen red, han favorecido el desarrollo de bibliotecasJava para computación de altas prestaciones(HPC), entre las que destaca el paradigma de paso demensajes en Java (MPJ). No obstante, las bibliotecasMPJ adolecen, al igual que las soluciones estándar enJava, de soporte directo y eficiente sobre redes de bajalatencia. La evaluación experimental de los mecanismosde comunicación desarrollados en este trabajoha mostrado aumentos significativos del rendimientocomparados con las soluciones previamente existentesen Java.Palabras clave— Java, Paso de Mensajes, Clúster,Redes de Altas Prestaciones, InfiniBand, Myrinet,High Speed Ethernet, Remote Direct Memory Access(RDMA).I. IntroducciónEL lenguaje de programación Java es ampliamenteutilizado en el ámbito académico así comoen la industria por sus especiales características talescomo seguridad, robustez, portabilidad, expresividad,sencillez, gestión automática de memoria yuna mayor productividad derivada de su orientacióna objetos, lo que le ha llevado a convertirse enuna de las plataformas de desarrollo de aplicacionesmás extendidas de la actualidad. No obstante, enámbitos donde el rendimiento es crítico, como encomputación de altas prestaciones (HPC), no es tanpopular, aunque su rendimiento se ha ido incrementandosignificativamente al pasar de una ejecucióninterpretada a la compilación a código nativo entiempo de ejecución realizada por compiladores JIT(Just-In-Time) y máquinas virtuales HotSpot. Deesta forma, Java alcanza rendimientos similares a loslenguajes compilados a código nativo, convirtiéndoseen una alternativa competitiva en HPC.Una de las arquitecturas paralelas más populareshoy en día en HPC es el clúster, un sistema de memo-1 Grupo de Arquitectura de Computadores, Dpto. deElectrónica y Sistemas, Universidade da Coruña, e-mail:rreye,taboada,juan,doallo@udc.es.ria distribuida escalable y económico formado porcomponentes comerciales que presenta una buena ratiocoste/rendimiento. Entre los modelos de programaciónde memoria distribuida, la interfaz de pasode mensajes MPI (Message Passing Interface) es lamás popular y usada por la mayoría de las aplicacionesHPC, habiéndose convertido en el estándar defacto para desarrollar aplicaciones paralelas portables,tradicionalmente utilizando los lenguajes C yFortran. El auge de las arquitecturas clúster yel aumento exponencial del número de núcleos enlos procesadores actuales hacen que sea necesario eluso de middleware de comunicación eficiente paraobtener la mayor escalabilidad posible en las aplicacionesparalelas y distribuidas, especialmente enpresencia de redes de altas prestaciones (también denominadasredes de baja latencia y alto ancho debanda). Entre estas redes de interconexión de clustersdestacan InfiniBand, Myrinet y la familia HighSpeed Ethernet (10/40 Gigabit Ethernet).Por otro lado, las especiales características de Javapara computación paralela, entre las que destacanun completo soporte multithread y de networkingjunto con su importante popularidad, han favorecidoel desarrollo de numerosas bibliotecas para paso demensajes MPJ (Message-Passing in Java). En esteaspecto, la evaluación de las bibliotecas MPJ másimportantes [1], analizando los distintos mecanismosde comunicaciones que implementan, ha constatadoque no soportan de forma eficiente las redes de interconexiónde clusters de baja latencia.Este artículo presenta el diseño e implementaciónde mecanismos de comunicación eficientes en redes dealtas prestaciones para bibliotecas de paso de mensajesen Java. Estos han sido integrados en la bibliotecaF-MPJ [2] con el fin de analizar experimentalmentela eficiencia de los mecanismos desarrollados yasí poder comparar su rendimiento respecto de otrasimplementaciones, utilizando para ello diversos clusterscon distintas redes de baja latencia (InfiniBand,10 Gigabit Ethernet, y Myrinet).II. Paso de Mensajes en JavaEl paradigma de paso de mensajes es el másutilizado en programación paralela, debido a suportabilidad, escalabilidad y relativamente buenrendimiento. En los lenguajes compilados a códigonativo MPI es la interfaz estándar para bibliotecasde paso de mensajes. En cuanto a Java, existen numerosasbibliotecas MPJ [1], aunque en este caso noJP2011-433

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011existe una interfaz estándar, con lo que la mayoríahan optado por implementar su propia API, similara la de MPI. Actualmente, MPJ Express [3] y nuestrabiblioteca F-MPJ [2] son los proyectos MPJ másactivos.El soporte para paso de mensajes sobre redes dealtas prestaciones suele estar implementado en dispositivosde comunicaciones a bajo nivel que proporcionanoperaciones de comunicación básicas. Ejemplosde APIs implementadas en lenguajes compiladosson ADI (Abstract Device Interface) y BTL (ByteTransfer Layer), utilizadas en las implementacionesMPICH2 [4] y OpenMPI [5], respectivamente. En elcaso de MPJ xdev es el API utilizada por MPJ Express,proporcionando operaciones básicas sobre lasque implementar las comunicaciones MPJ. Sin embargo,xdev utiliza una capa de buffering [6] adicionalen la comunicación que limita de forma importantesu rendimiento y escalabilidad, siendo este el principalcuello de botella de MPJ Express. La bibliotecaF-MPJ solventa este problema presentando unanueva API, xxdev, mostrada en la Figura 1, que extiendexdev permitiendo la comunicación directa decualquier objeto serializable en Java en lugar de estarrestringida a bufers MPJ como en MPJ Express,además de presentar un diseño más modular y extensible.public c l a s s Device{s t a t i c public Device n e wInstance ( S t r i n g impl ) ;P rocessID [ ] i n i t ( S t r i n g [ ] a r g s ) ;P rocessID i d ( ) ;void f i n i s h ( ) ;Request i s e n d ( Object msg , PID dst , int tag ,int c n t x t ) ;Request i r e c v ( Object msg , PID src , int tag ,int c n txt , S t a t u s s ) ;void send ( Object msg , PID dst , int tag ,int c n t x t ) ;S t a t u s r e c v ( Object msg , PID src , int tag ,int c n t x t ) ;Request i s s e n d ( Object msg , PID dst , int tag ,int c n t x t ) ;void sse n d ( Object msg , PID src , int tag ,int c n t x t ) ;S t a t u s i p r o b e (PID src , int tag , int c n t x t ) ;S t a t u s probe (PID src , int tag , int c n t x t ) ;Request peek ( ) ;}Fig. 1.API pública de la clase xxdevIII. Mecanismos de Comunicación Eficientesen Redes de Altas PrestacionesEsta sección presenta el diseño e implementaciónde los mecanismos de comunicación para las redesde altas prestaciones soportadas eficientemente en F-MPJ.A. Myrinet/High Speed EthernetMyrinet es una red de interconexión de clusters dealtas prestaciones desarrollada por Myricom [7] queproporciona latencias reducidas, en torno a 3-8 µs yaltos anchos de banda, 2 Gbps en Myrinet 2000 y10 Gbps en Myri-10G. Myrinet Express (MX) [8] esla biblioteca de comunicación de bajo nivel y altasprestaciones que proporciona Myricom para su utilización,tratándonse de un API con una semánticaorientada al paso de mensajes. La presencia deMyrinet en el Top500 [9] se ha visto notablemente reducidaen los ultimos años, hasta el punto que Myricomha diseñado sus últimos productos (Myri-10G)para ser compatibles a nivel físico con 10 GigabitEthernet, y que gracias al protocolo MXoE (MX overEthernet) es totalmente compatible con Myrinet anivel de API utilizando MX.Open-MX [10] es una implementación open-sourcedel API MX para su utilización sobre redes HighSpeed Ethernet, fundamentalmente 10/40 GigabitEthernet, que además proporciona compatibilidadcon el protocolo MXoE. Esto nos permite desarrollarel dispositivo de comunicación siguiendo la especificacióndel API MX, y poder utilizarlo con unatarjeta de red Ethernet genérica, sin necesidad delhardware especializado de Myricom. Su compatibilidada nivel de API permite su uso en redes Myrinet oen redes Ethernet utilizando los productos de Myricom.Como Open-MX está desarrollado en lenguajeC es necesario el uso de la interfaz nativa de Java,JNI (Java Native Interface), para su soporte en Java.A.1 Dispositivo en Java sobre MX: omxdevEl código Java para el dispositivo de comunicacionespara Myrinet/High Speed Ethernet debe implementarla interfaz xxdev. Cada método de comunicacióndelega en el método nativo correspondientede la biblioteca MX a través de JNI, encargándosede la obtención de referencias así como del manejo delos parámetros. Esto permite minimizar al máximoel código JNI, eliminando posibles problemas derivadosde su uso. Es necesario el uso de la función deJNI denominada GetPrimitiveArrayCritical, la cualpermite obtener un puntero directo a los datos a enviarevitando así copias intermedias que degraden elrendimiento. De esta forma, cuando se hace un envíode tipos de datos primitivos se evita la serialización,que quedaría reservada al envío de los restantes objetosJava.B. InfiniBandInfiniBand es una tecnología de interconexión entrenodos de computación en clusters y dispositivosde E/S que permite formar una red de área de sistemao SAN (System Area Network), que destacaen entornos HPC ya que es actualmente la red máspopular en las primeras 100 posiciones del Top500.La arquitectura definida por InfiniBand es independientedel sistema operativo y de la plataforma. Algunascaracterísticas destacadas de InfiniBand sonel acceso directo a memoria remota, conocido comoRDMA (Remote Direct Memory Access), y tambiénel soporte de las clásicas operaciones Send/Receive,así como operaciones atómicas, soporte en hardwarede operaciones multicast y QoS (Quality of Service).Al contrario que en otras especificaciones, la arquitecturade InfiniBand no estableció una APIJP2011-434

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011estándar. En su lugar, define la funcionalidad quela tarjeta de red debe proporcionar al sistema operativoen términos de la interfaz verbs. Esta interfazespecifica la funcionalidad de la capa de transporte,siendo su implementación más extendida y utilizadala proporcionada por la OpenFabrics Alliance [11],denominada InfiniBand Verbs API (IBV), un APIde bajo nivel disponible sólo en C, lo cual fuerza denuevo al uso de JNI para implementar un soportedirecto y eficiente del API de IBV en Java.Al tratarse IBV de una capa inmediatamente porencima del hardware, proporciona operaciones debajo nivel sobre la tarjeta de red. La semánticarequerida por la API xxdev difiere mucho de lasemántica ofrecida por IBV, al contrario de lo quesucedía con la biblioteca MX. Es por ello que seha desarrollado una biblioteca intermedia en C similara MX utilizando IBV, denominada IBVX, conuna semántica orientada al paso de mensajes lo quepermitirá una implementación más fácil desde Java,minimizando de esta forma el código JNI requerido.C. Biblioteca IBVXIBVX (IBV Express) es la biblioteca en C quehemos desarrollado para comunicaciones eficientesen paso de mensajes sobre IBV. El API que ofreceIBVX, presentada en la Figura 2, ofrece primitivas decomunicación punto a punto tanto bloqueantes comono bloqueantes, así como comunicaciones síncronas oasíncronas. Así, es posible implementar el API xxdevde forma más sencilla desde Java, que se limitará auna fina capa wrapper sobre IBVX.I B V I n i t ( char ∗∗pNames , int ∗ p orts , int nprocs ,int myRank ) ;I B V F i n a l i z e ( ) ;IBV Isend ( void ∗ buf , int s i z e , int dst , int tag ,int c n txt , Request ∗ r ) ;IBV Isse n d ( void ∗ buf , int s i z e , int dst , int tag ,int c n txt , Request ∗ r ) ;IBV Irecv ( void ∗ buf , int s i z e , int src , int tag ,int c n txt , Request ∗ r ) ;IBV Send ( void ∗ buf , int s i z e , int dst , int tag ,int c n t x t ) ;IBV Ssend ( void ∗ buf , int s i z e , int dst , int tag ,int c n t x t ) ;IBV Recv ( void ∗ buf , int s i z e , int src , int tag ,int c n txt , S t a t u s ∗ s ) ;IBV Wait ( Request ∗ r , S t a t u s ∗ s ) ;IBV Test ( Request ∗ r , S t a t u s ∗ s ) ;IBV Iprobe ( int src , int tag , int c n txt , S t a t u s ∗ s ) ;IBV Probe ( int src , int tag , int c n txt , S t a t u s ∗ s ) ;Request∗ IBV Peek ( ) ;Fig. 2.API de la biblioteca IBVXC.1 Protocolos de Comunicación en IBVXUsualmente las bibliotecas de paso de mensajesimplementan internamente dos protocolos de comunicación(véase Figura 3):• Eager: se trata de un protocolo de envío inmediato,de manera que el emisor hace el envíosin esperar a que el receptor haya invocadopreviamente su correspondiente recepción, asumiendoque tiene suficiente espacio para almacenarel mensaje, con lo cual no necesita unaautorización explícita de envío.• Rendezvous: se trata de un protocolo de envíoacordado, ya que existe una negociación (handshaking)previa al envío en la que el receptorautoriza al emisor el envío del mensaje, usandopara ello mensajes de control.Fig. 3.Protocolos de envío en paso de mensajesEl ligero sobrecoste debido a la copia de los datoscon el protocolo eager es asumible en el caso de mensajesde pequeño tamaño a fin de obtener latenciaslo más reducidas posible. Dicho objetivo coincidecon las propiedades de las operaciones Send/Receivede InfiniBand, utilizadas usualmente en mensajes dereducido tamaño. No obstante, el requisito en Infini-Band de que todos los bufers usados en las comunicacionesestén registrados, siendo el registro una operacióncostosa, supone una importante penalizaciónen el rendimiento de este protocolo que es atajadamediante el uso de un pool de bufers prerregistradospor proceso para las operaciones de envío, ademásde un pool de bufers prerregistrados para las recepcionespor cada proceso con el que se comunica, utilizadospara la copia de los datos a enviar/recibir.El protocolo rendezvous es utilizado para el envíode mensajes largos, para los cuales es crítico evitarla copia de datos, lo que es posible mediante operacionesRemote Direct Memory Access (RDMA)para implementar un protocolo Zero-Copy donde seenvíen directamente los datos del búfer origen albúfer destino, sin copias intermedias a los bufers delpool de envíos y recepciones. Como para el uso delas operaciones RDMA es necesario conocer tanto ladirección de memoria destino como la clave remotaque nos permita el acceso a la misma, es necesarioque haya un intercambio de estos parámetros previoal envío de los datos. Es por ello que se puedeaprovechar el handshaking previo al envío del mensajeque contiene los datos que existe en el protocolorendezvous y mediante la operación RDMA Write seescribe el mensaje directamente en la memoria delproceso destino.C.2 Dispositivo en Java sobre IBV: ibvdevEl dispositivo Java que implementa la interfazxxdev para el soporte de InfiniBand se implementade forma análoga al dispositivo omxdev. En efecto,la biblioteca IBVX se ha diseñado de tal modo quelos métodos de ibvdev deleguen directamente en suscorrespondientes métodos nativos (IBVX).JP2011-435

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IDescripción de los clusters utilizados en la evaluación del rendimientoClúster Ubicación Nodos Procesador Memoria RedPlutón Univ. A Coruña 16 2 Intel Xeon E5520 Quad-core 8GB InfiniBand DDR (16 Gbps)Plutón Univ. A Coruña 2 2 Intel Xeon E5440 Quad-core 16GB 10 Gigabit EthernetDAS-4 VU Amsterdam 74 2 Intel Xeon E5620 Quad-core 24 GB InfiniBand QDR (32 Gbps)Marenostrum BSC-CNS 2560 2 IBM PowerPC 970MP Dual-core 8GB Myrinet 2000 (2 Gbps)Latencia (µs)8580757065605550454035302520151050Punto a Punto (IB DDR − Plutón)Intel MPI − IBVF−MPJ (ibvdev) − IBVMPJE (niodev) − IPoIB14 16 64 256 1K 4K 16K 64K 256K 1M 4M 0111098765432Ancho de Banda (Gbps)Latencia (µs)302826242220181614121086420Punto a Punto (10GbE − Plutón)Intel MPIF−MPJ (omxdev) − MXMPJE (mxdev) − MX14 16 64 256 1K 4K 16K 64K 256K 1M 4M 01098765432Ancho de Banda (Gbps)Tamaño del Mensaje (bytes)Tamaño del Mensaje (bytes)Latencia (µs)6560555045403530252015105Punto a Punto (IB QDR − DAS4)Intel MPI − IBVF−MPJ (ibvdev) − IBVMPJE (niodev) − IPoIB204 16 64 256 1K 4K 16K 64K 256K 1M 4M 028262422201816141210864Ancho de Banda (Gbps)Latencia (µs)363432302826242220181614121086420Punto a Punto (Myrinet 2000 − Marenostrum)MPICH−MXF−MPJ (omxdev) − MXMPJE (mxdev) − MX0.24 16 64 256 1K 4K 16K 64K 256K 1M 4M 02.221.81.61.41.210.80.60.4Ancho de Banda (Gbps)Tamaño del Mensaje (bytes)Tamaño del Mensaje (bytes)Fig. 4.Rendimiento de las operaciones punto a punto de paso de mensajes en redes de altas prestacionesIV. Evaluación del RendimientoEl rendimiento de los mecanismos de comunicacióndesarrollados ha sido evaluado en cuatro escenarioscon distintas redes de interconexión cuyas característicasresumidas se presentan en la Tabla I. Lasbibliotecas MPJ evaluadas han sido F-MPJ v0.1 yMPJ Express 0.38 en todos los sistemas, mientrasque las bibliotecas MPI utilizadas son Intel MPI version4 [12] en Plutón y DAS-4, y MPICH-MX [7] enel Marenostrum. Los benchmarks utilizados para laevaluación de su rendimiento en operaciones puntoa punto y colectivas son los Intel MPI Benchmarkspara MPI, y su versión equivalente para MPJ la cualhemos desarrollado debido a la inexistencia de benchmarksadecuados para la evaluación en bibliotecasMPJ.A. Comunicaciones Punto a PuntoLa Figura 4 muestra los resultados del rendimientode las comunicaciones punto a punto en los cuatroescenarios evaluados. Tanto en InfiniBand (QDRy DDR) como en 10 Gigabit Ethernet, los resultadosobtenidos por F-MPJ son muy superiores alos obtenidos por MPJ Express, tanto en términosde latencia como en ancho de banda, obteniendorendimientos similares a Intel MPI. En Myrinet,F-MPJ sigue obteniendo resultados muy similaresa los de la biblioteca MPI, MPICH-MX, aunqueen este caso el margen de mejora con respecto aMPJ Express es inferior debido al reducido anchode banda que proporciona la red utilizada (2 Gbps),limitándose al beneficio obtenido a unos 0.5 Gbpsen términos de ancho de banda en mensajes largos,mientras que para mensajes cortos F-MPJ obtiene lamitad de latencia que MPJ Express.B. Comunicaciones ColectivasLa Figura 5 presenta los resultados de rendimientopara las primitivas Broadcast y Allreduce en elclúster Plutón con 128 procesos (IB DDR), sobre elclúster DAS-4 con 512 procesos (IB QDR) y sobreel MareNostrum con 512 procesos (Myrinet 2000).Los datos transferidos son arrays de bytes, evitandode este modo la serialización ya que puede penalizarde forma importante el rendimiento y el objetivo deesta evaluación es mostrar el rendimiento de las comunicacionescolectivas. La métrica utilizada es elancho de banda agregado que tiene en cuenta la cantidadtotal de información transferida por cada primitiva.Los resultados han sido obtenidos utilizandoel máximo número de núcleos disponibles por nodo,8 en el caso del clúster Plutón y el DAS-4, y 4 enel caso del MareNostrum. Los resultados de MPJExpress han sido obtenidos únicamente en el clústerPlutón debido a que su runtime presenta problemascon los sistemas de colas del DAS-4 y el MareNostrum.En las gráficas del clúster Plutón se observa claramentecomo la mejora obtenida por F-MPJ para lascomunicaciones punto a punto, implementando en elJP2011-436

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Ancho de Banda Agregado (Gbps)600500400300200100Rendimiento Broadcast 128 Procesos (Plutón)Intel MPI − IBVF−MPJ (ibvdev) − IBVMPJE (niodev) − IPoIB01K 4K 16K 64K 256K 1M 4MTamaño del Mensaje (bytes)Ancho de Banda Agregado (Gbps)500400300200100Rendimiento Allreduce 128 Procesos (Plutón)Intel MPI − IBVF−MPJ (ibvdev) − IBVMPJE (niodev) − IPoIB01K 4K 16K 64K 256K 1M 4MTamaño del Mensaje (bytes)Ancho de Banda Agregado (Gbps)2000180016001400120010008006004002000Rendimiento Broadcast 512 Procesos (DAS−4)Intel MPI − IBVF−MPJ (ibvdev) − IBV1K 4K 16K 64K 256K 1M 4MTamaño del Mensaje (bytes)Ancho de Banda Agregado (Gbps)1200110010009008007006005004003002001000Rendimiento Allreduce 512 Procesos (DAS−4)Intel MPI − IBVF−MPJ (ibvdev) − IBV1K 4K 16K 64K 256K 1M 4MTamaño del Mensaje (bytes)Ancho de Banda Agregado (Gbps)400300200100Rendimiento Broadcast 512 Procesos (MareNostrum)MPICH−MXF−MPJ (omxdev) − MX01K 4K 16K 64K 256K 1M 4MTamaño del Mensaje (bytes)Ancho de Banda Agregado (Gbps)500400300200100Rendimiento Allreduce 512 Procesos (MareNostrum)MPICH−MXF−MPJ (omxdev) − MX01K 4K 16K 64K 256K 1M 4MTamaño del Mensaje (bytes)Fig. 5.Rendimiento de las operaciones colectivas en Plutón, DAS-4 y MareNostrumdispositivo ibvdev el soporte eficiente de InfiniBand,aumenta significativamente el rendimiento de las comunicacionescolectivas en relación a MPJ Express.No obstante, a pesar de que el rendimiento de lasoperaciones punto a punto de F-MPJ es muy similaral de Intel MPI, el rendimiento de las colectivas deMPI supera significativamente (en promedio dobla)el rendimiento de las colectivas de F-MPJ, a pesar deque estas últimas implementan algoritmos altamenteescalables [13]. La principal causa de esta reducciónde rendimiento se halla en la mayor variabilidad delos tiempos (jitter) en Java, cuyo impacto se multiplicaen las operaciones colectivas implementadas envarios pasos, como por ejemplo en algoritmos basadosen árbol.C. NAS Parallel BenchmarksLos benchmarks NPB (NAS -NASA AdvancedSupercomputing- Parallel Benchmarks) son un conjuntode kernels computacionales y aplicaciones, querepresentan las partes con mayor carga computacionalde simulaciones de dinámica de fluidos. Estoscódigos fueron utilizados por la NASA para la evaluacióndel rendimiento en el ámbito de sus necesidadesde supercomputación. En el ámbito Java, seha desarrollado una implementación para paso demensajes en Java de los NPB denominada NPB-MPJ [14].Las Figura 6 muestra los resultados obtenidos pordos kernels representativos de los NPB, CG (ConjugateGradient) y FT (Fourier Transform), parala Clase C en términos de MOPS (Millones de OperacionesPor Segundo) ejecutados sobre los clustersPlutón, DAS-4 y el MareNostrum. Las principalesconclusiones que se pueden extraer de estos resultadosson que F-MPJ mejora significativamente elrendimiento de MPJ Express, llegando a obtener enPlutón en torno a un 50% de mejora para CG y un400% de beneficio para FT, gracias a la mayor escalabilidadde F-MPJ. Comparando el rendimientode los NPB-MPJ con sus equivalentes en MPI podemosapreciar que los resultados de CG son competitivosusando hasta 64 núcleos gracias a obtener resultadosmuy similares en un núcleo, sufriendo unamenor escalabilidad a partir de ese punto. En cambio,para FT el rendimiento de Java es muy inferioral del código nativo (Fortran) ya que en un núcleoNPB-MPJ FT obtiene 705 MOPS frente a los 1388MOPS del código nativo. Este factor condiciona elrendimiento de este benchmark ya que aunque F-MPJ presenta una escalabilidad similar a la de IntelMPI los resultados del código Java están en torno ala mitad del rendimiento del FT MPI.V. ConclusionesEl rendimiento y la escalabilidad de las comunicacionesson aspectos de crucial importancia paralas arquitecturas clúster multi-core, especialmente enpresencia de redes de baja latencia. Este artículo presentael diseño de los mecanismos de comunicaciónpara el soporte eficiente de redes de baja latencia enJava, permitiendo mejorar el rendimiento de aplicacionesJava en computación de altas prestaciones, unámbito en el que todavía es una opción emergente.JP2011-437

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MOPS20000180001600014000120001000080006000400020000CG Clase C (Plutón)Intel MPI − IBVF−MPJ (ibvdev) − IBVMPJE (niodev) − IPoIB1 8 16 32 64 128Número de núcleosMOPS50000450004000035000300002500020000150001000050000FT Clase C (Plutón)Intel MPI − IBVF−MPJ (ibvdev) − IBVMPJE (niodev) − IPoIB1 8 16 32 64 128Número de núcleosMOPS70000600005000040000300002000010000Intel MPI − IBVF−MPJ (ibvdev) − IBVCG Clase C (DAS−4)MOPS25000020000015000010000050000Intel MPI − IBVF−MPJ (ibvdev) − IBVFT Clase C (DAS−4)016 32 64 128 256 512Número de núcleos016 32 64 128 256 512Número de núcleos2500020000CG Clase C (MareNostrum)MPICH−MXF−MPJ (omxdev) − MX120000100000FT Clase C (MareNostrum)MPICH−MXF−MPJ (omxdev) − MXMOPS1500010000MOPS800006000040000500020000016 32 64 128 256 512Número de núcleos016 32 64 128 256 512Número de núcleosFig. 6.Rendimiento de los NPB para los kernels CG y FT en Plutón, DAS-4 y MareNostrumLos dispositivos de comunicación a bajo nivel parapaso de mensajes implementados son conformes alAPI xxdev, lo que ha permitido su integración deforma transparente en la biblioteca F-MPJ. La evaluaciónexperimental de su rendimiento, tanto de lascomunicationes punto a punto como de las colectivas,así como su impacto en aplicaciones a nivel de kernel/aplicaciónha mostrado aumentos significativosdel rendimiento. En efecto, se han obtenido mejorasde hasta dos órdenes de magnitud en comparacióncon soluciones previamente existentes en paso demensajes en Java, llegándose a obtener resultadoscompetitivos en comparación con MPI. Esta evaluaciónse llevó a cabo en escenarios representativos,evaluándose el rendimiento de F-MPJ en clusters conlas redes de interconexión InfiniBand DDR y QDR,10 Gigabit Ethernet y Myrinet.AgradecimientosEste trabajo ha sido financiado por el Ministeriode Ciencia e Innovación de España en el marcodel proyecto TIN2010-16735 y por el Programa deConsolidación y Estructuración de Unidades de InvestigaciónCompetitivas de la Consellería de Educaciónde la Xunta de Galicia. Agradecemos alBarcelona Supercomputing Center (BSC-CNS) el accesoal MareNostrum. We also gratefully thank AdvancedSchool for Computing and Imaging (ASCI) ofthe Vrije University Amsterdam for providing accessto the DAS-4 cluster.Referencias[1] G.L. Taboada, J. Touriño, and R. Doallo, “Java forHigh Performance Computing: Assessment of CurrentResearch and Practice,” in Proc. 7th Intl. Conf. onthe Principles and Practice of Programming in Java(PPPJ’09), Calgary, Alberta, Canada, 2009, pp. 30–39.[2] G.L. Taboada, J. Touriño, and R. Doallo, “F-MPJ: ScalableJava Message-passing Communications on ParallelSystems,” Journal of Supercomputing, 2011 (In press,http://dx.doi.org/10.1007/s11227-009-0270-0).[3] A. Shafi, B. Carpenter, and M. Baker, “Nested Parallelismfor Multi-core HPC Systems using Java,” Journalof Parallel and Distributed Computing, vol. 69, no. 6, pp.532–545, 2009.[4] “MPICH2,” http://www.mcs.anl.gov/research/projects/mpich2.[5] “Open Source High Performance MPI Library,” http://www.open-mpi.org.[6] M. Baker, B. Carpenter, and A. Shafi, “A Buffering Layerto Support Derived Types and Proprietary Networks forJava HPC,” Scalable Computing Practice and Experience,vol. 8, no. 4, pp. 343–358, 2007.[7] “Myricom Website,” http://www.myri.com.[8] “MX User’s Guide,” http://www.myri.com/scs/MX/doc/mx.pdf.[9] “Top 500,” http://www.top500.org.[10] B. Goglin, “High-Performance Message Passing overGeneric Ethernet Hardware with Open-MX,” ParallelComputing, vol. 37, no. 2, pp. 85–100, 2011.[11] “OpenFabrics Alliance Website,” http://www.openfabrics.org.[12] “Intel R○ MPI Library,” http://www.intel.com/go/mpi.[13] G.L. Taboada, S. Ramos, J. Touriño, and R. Doallo,“Design of Efficient Java Message-passing Collectives onMulti-core Clusters,” Journal of Supercomputing, vol.55, no. 2, pp. 126–154, 2011.[14] D.A. Mallón, G.L. Taboada, J. Touriño, and R. Doallo,“NPB-MPJ: NAS Parallel Benchmarks Implementationfor Message-Passing in Java,” in Proc. 17th EuromicroIntl. Conf. on Parallel, Distributed, and Network-BasedProcessing (PDP’09), Weimar, Germany, 2009, pp. 181–190.JP2011-438

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Comunicaciones Escalables en MemoriaCompartida para Paso de Mensajes en JavaSabela Ramos, Guillermo L. Taboada, Juan Touriño, Ramón Doallo 1Resumen— Este artículo presenta el middleware decomunicaciones en memoria compartida smpdev, integradoen nuestra implementación de paso de mensajesen Java, Fast MPJ (F-MPJ). El continuo aumentodel número de núcleos por procesador pone de manifiestola necesidad de un soporte eficiente de comunicacionespara programación paralela no sólo a nivelde clúster, sino que optimice también las comunicacionesintra-nodo. Sin embargo, el aprovechamientoeficiente del potencial de los procesadores multinúcleomediante el uso de threads en Java requiere un importanteesfuerzo por parte del programador, mientrasque smpdev permite trabajar con un mayor nivelde abstracción utilizando un API de comunicacionesmediante paso de mensajes, simple, pero a la vez potente.Además, el paso de mensajes no está limitado asistemas de memoria compartida, lo que permite explotarmás eficientemente los recursos hardware. Enefecto, smpdev permite sustituir el uso de procesos yprotocolos de comunicaciones en red por threads ytransferencias en memoria compartida. La evaluacióndel rendimiento de smpdev muestra un incremento deprestaciones con respecto a soluciones similares enJava para paso de mensajes en memoria compartida,con un rendimiento próximo al obtenido con lenguajescompilados a código nativo (e.g., C o Fortran),llegando a superarlos en algunos casos.Palabras clave— Paso de Mensajes en Java (MPJ),Memoria Compartida, Arquitecturas Multinúcleo,Computación de Altas Prestaciones (HPC), Evaluacióndel RendimientoI. IntroducciónJAVA es una alternativa emergente en Computaciónde Altas Prestaciones [1] (HPC) a pesarde que en sus inicios fue especialmente criticadopor su bajo rendimiento computacional [2]. Sin embargo,hoy en día, y gracias a los avances en la tecnologíade la máquina virtual de Java (JVM) y a lacompilación Just-In-Time (JIT), capaces de generarcódigo nativo eficiente a partir del bytecode independientede la plataforma, el rendimiento de Javaes tan solo un 30% inferior al de los lenguajes compiladosa código nativo (e.g., C o Fortran) [1] [3].Además, Java proporciona algunas características interesantespara programación paralela como son uncompleto soporte multithread y de comunicacionesen red, manejo automático de memoria, independenciade la plataforma, portabilidad, seguridad, orientacióna objetos, un API extenso y una amplia comunidadde desarrolladores, siendo el lenguaje másusado en los ámbitos académico y empresarialLa opción preferida a la hora de programar clusterses el paradigma de paso de mensajes debido a suescalabilidad y relativo buen rendimiento. No obstante,en Java esta opción no suele aprovechar el1 Grupo de Arquitectura de Computadores, Dpto. deElectrónica y Sistemas, Universidade de A Coruña, e-mail:{sramos, taboada, juan, doallo}@udc.esmultithreading para intercambiar mensajes mediantetransferencias en memoria compartida, evitando queprocesos del mismo nodo utilicen protocolos de comunicaciónen red. Esta situación resulta crítica conel aumento del número de núcleos por procesador,que hace crecer la demanda de soluciones escalablesde programación paralela para memoria compartida.El multithreading de Java permite aprovechar elpotencial de las arquitecturas de memoria compartidaa costa de incrementar la complejidad de programación,ya que es el programador el que tieneque gestionar los threads, tareas y el acceso y mantenimientode estructuras compartidas de datos. Eneste artículo presentamos un dispositivo de comunicacionesen memoria compartida que, de forma mássencilla y a más alto nivel, explota el multithreadingproporcionando una interfaz de paso de mensajes.Además, se integra en una biblioteca de pasode mensajes de manera que el uso de un dispositivode memoria compartida o distribuida es transparenteal usuario, aumentando así la portabilidad del códigodesarrollado.La estructura del artículo es la siguiente: laSección II describe soluciones existentes para programaciónparalela en memoria compartida. LaSección III se centra en el diseño e implementacióndel dispositivo smpdev. La Sección IV presenta unaevaluación del rendimiento comparando smpdev conotro dispositivo de memoria compartida para pasode mensajes en Java, Java threads y con bibliotecasnativas MPI y OpenMP. Finalmente, la Sección V resumelas principales aportaciones y conclusiones deeste trabajo.II. Proyectos RelacionadosEl paso de mensajes es el paradigma de programaciónparalela más ampliamente difundido. Enlenguajes nativos, como C y Fortran, existen distintasbibliotecas que implementan la interfaz estándarMPI y están mayoritariamente optimizadas para sistemasde memoria distribuida. No obstante, el aumentodel número de núcleos por procesador ha idofavoreciendo el desarrollo de soluciones orientadas aaprovechar las arquitecturas de memoria compartidaempleando paso de mensajes. Destaca el proyectoMPICH2 [4] que incluye varios dispositivos de comunicaciónque explotan el uso de memoria compartidacomo ssm, shm o sshm. También incorpora un subsistemade comunicaciones, denominado Nemesis [5],que optimiza los dispositivos orientados a memoriadistribuida para mejorar el rendimiento y la escalabilidadde los mismos en arquitecturas de memoriacompartida.JP2011-439

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Otra aproximación a la hora de sacar partido alos procesadores multinúcleo es utilizar OpenMP oPOSIX threads (pthreads), aunque su carencia desoporte para memoria distribuida limita las aplicacionesa sistemas de memoria compartida. Existen,no obstante, soluciones para ejecutar códigoOpenMP en sistemas de memoria distribuida peroque, o bien se basan en traductores que obtienencódigo MPI a partir de directivas OpenMP, o bien seejecutan en sistemas de Memoria Distribuida Compartidao DSM’s [6] [7].Las principales implementaciones en Java de interfacessimilares a OpenMP son JOMP [8] y JaMP [9].Ambos sistemas son 100% Java y están basados enthreads, con la diferencia de que el segundo empleautilidades de concurrencia, superando ciertos problemasde eficiencia de JOMP. JaMP forma parte deJackal [10], una máquina virtual de Java de memoriacompartida-distribuida (Java Distributed SharedMemory, DSM) y su principal problema es la faltade portabilidad.El soporte a comunicaciones en red y multithreadingde Java lo convierten en una opción interesantepara la programación de arquitecturas de memoriacompartida. No obstante, el uso del API de threads ylas herramientas de concurrencia exigen conocimientosde programación a bajo nivel y concurrencia, ylos códigos desarrollados no sirven para ejecutarseen entornos de memoria distribuida. El proyectoParallel Java (PJ) [11] proporciona varias abstraccionessobre estas utilidades de concurrencia, implementandotambién el paradigma de paso de mensajespara memoria distribuida proporcionando una interfazpropia.A. Paso de Mensajes en Java (MPJ)En cuanto al paso de mensajes en Java (MPJ) [1],los proyectos más relevantes en términos de adopciónpor parte de la comunidad HPC son mpiJava [12],MPJ Express [13]y F-MPJ [14].La biblioteca mpiJava [12] es un wrapper a MPIque proporciona comunicaciones eficientes sobre unabiblioteca nativa, por lo que podría utilizar optimizacionesde MPI para memoria compartida. Sin embargo,presenta problemas de inestabilidad derivadosdel wrapping y es incapaz de aprovechar los sistemasmultinúcleo a través de multithreading debido a queno es thread-safe.MPJ Express [13] es una implementación MPJ100% Java. Este proyecto es actualmente el más activoen cuanto a adopción por la comunidad HPC,documentación disponible y presencia en entornosacadémicos y de producción. MPJ Express es threadsafey tiene un diseño modular, incluyendo una arquitecturaconfigurable de dispositivos de comunicaciónque permite combinar la portabilidad de los dispositivos100% Java (de memoria compartida y usando elpaquete New IO, Java NIO) con el alto rendimientodel soporte a Myrinet (a través de la biblioteca nativade comunicaciones Myrinet eXpress, MX). Además,incluye un dispositivo multithread de memoria compartida[15].Nuestra implementación MPJ, Fast MPJ (F-MPJ) [14] proporciona soporte a redes de altasprestaciones de forma directa. F-MPJ incluye unabiblioteca de colectivas MPJ escalables [16]. El middlewarepresentado en este artículo, smpdev se haintegrado en F-MPJ y las principales diferencias quepresenta con respecto a la implementación del dispositivomultithread de memoria compartida de MPJExpress están el manejo de colas y el buffering.III. Dispositivo de Comunicación Eficienteen Memoria Compartida: smpdevA. Dispositivos de Comunicación en F-MPJEl uso de dispositivos configurables de comunicacionesa bajo nivel para soporte a redes dealtas prestaciones está ampliamente extendido enlas bibliotecas nativas de paso de mensajes comoMPICH2. Asimismo, MPJ Express y F-MPJtambién proporcionan diferentes dispositivos de comunicacionespara distintas tecnologías de intercomunicación.Los dispositivos de F-MPJ siguen el APIxxdev [14] (ver Figura 1), que evita el bufferingde datos soportando envíos/recepciones directos decualquier objeto serializable, al contrario que xdev,el API extendida por xxdev y adoptada por MPJExpress, que opera sobre una capa propia de buffering.El API xxdev está compuesto por operacionesbásicas como las comunicaciones punto a punto bloqueantes(send, recv) y no bloqueantes (isend, irecv),e incluye comunicaciones síncronas (ssend, issend).No maneja abstracciones de paso de mensajes de altonivel como grupos y comunicadores y, por ello, utilizaProcessID en lugar de rangos, pues el objetoProcessID identifica unívocamente a un elementodel dispositivo.public abstract class Device {static public Device newInstance(String deviceImpl);public int[] init(String[] args);public int id();public void finish();public Request isend(Object buf,int dst,int tag);public Request irecv(Object buf,int src,int tag,Status stts);public void send(Object buf,int dst,int tag);public Status recv(Object buf,int src,int tag);public Request issend(Object buf,int dst,int tag);public void ssend(Object buf,int dst,int tag);public Status iprobe(int src,int tag,int context);public Status probe(int src,int tag,int context);public Request peek();}Fig. 1.API of the xxdev.Device classLa Figura 2 muestra los dispositivos de comunicacionesincluidos en F-MPJ. Actualmente, estosestán implementados sobre capas nativas de comunicacionesaccedidas mediante JNI, como Open-MXJP2011-440

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(omxdev) e InfiniBand Verbs (IBV, ibvdev), y socketssobre la pila TCP/IP (iodev y niodev), ademásdel que se presenta en este artículo, smpdev, implementadomediante threads Java.B. Implementación de smpdevEl dispositivo multithread de F-MPJ, smpdev, utilizathreads Java para ejecutar procesos MPJ, lo cualpermite aprovechar las transferencias de datos enmemoria compartida para llevar a cabo las comunicacionespunto a punto.B.1 Cargadores de ClaseEl uso de threads requiere el aislamiento del espaciode nombres para cada thread en ejecución, dejantouna zona compartida en la que puedan llevara cabo el intercambio de mensajes. Este manejo sebasa en la implementación de un cargador de clase amedida tal y como se hace en MPJ Express [15].Podemos establecer dos grupos de clases atendiendoa las necesidades de aislamiento de las mismas.Las clases de la aplicación del usuario y las clasesde más alto nivel de la biblioteca, así como algunarelacionada con la gestión del dispositivo, tienen queestar aisladas para proporcionar la abstracción deprocesos MPJ sobre threads. Las variables estáticasde esas clases, por tanto, no deben compartirse entrelos distintos threads. Sin embargo, es necesario ungrupo de clases compartidas que permitan la comunicaciónmediante transferencias en memoria compartida.Una máquina virtual de Java (JVM) identificacada clase cargada por su nombre cualificado completoy su cargador de clase, haciendo, pues, que cadacargador defina su propio espacio de nombres. Paraaislar a los threads, cada uno de ellos es creado pormedio de cargador de clase propio y a medida, elcual gestionará las clases no compartidas. La JVMhace uso de una jerarquía de cargadores en la que elprimero al que se recurre es el que existe por defectoen el sistema, por lo que éste cargará todas las clasesque tenga a su alcance. Esto implica que debemoslimitar su Classpath de forma que sólo tenga accesoa los paquetes compartidos. Así, cuando el cargadordel sistema no sea capaz de encontrar una clase, laJVM acudirá al cargador a medida de cada thread.B.2 Colas de MensajesLas operaciones de comunicaciones punto a puntodelegan en clases compartidas que manejan colas demensajes pendientes para gestionar los envíos y lasrecepciones. A cada thread se le asignan dos colas,una para los mensajes recibidos y otra para los queespera recibir pero todavía no han llegado.El acceso a cada par de colas está sincronizadopara evitar inconsistencias. Cuando un thread envíaun mensaje chequea si hay alguna petición de recepciónen la cola del thread destino. Si encuentrauna coincidencia, copia el mensaje en su destino y lapetición se marca como completada. Cuando no hayninguna coincidencia, inserta una petición en la colade enviados. Dependiendo del protocolo de envío, elemisor copiará o dejará una referencia a su propiomensaje. El proceso de recepción sigue este algoritmopero a la inversa. El receptor comprueba sucola y, si hay alguna petición de envío coincidente,completa la comunicación, si no, encola una peticiónde recepción.La Figura 3 muestra, de forma gráfica, un ejemplode cómo se llevarían a cabo un par de comunicaciones.En la imagen superior, el Thread 0 envía elmensaje de forma previa a que el destino haya solicitadola recepción por lo que deja en la cola unapetición de envío. Es el receptor el que obtiene lapetición y copia el mensaje cuando recibe. En la inferior,el receptor inicia la comunicación y es el emisorel que encontrará la petición en la cola y completarála comunicación. Los números de secuencia indicanel orden en el que se realiza cada acción. En todoslos casos, la identificación del mensaje se realiza através de la identificación del emisor, una etiquetade usuario y un contexto que maneja el dispositivo.Send (data)Thread 0data1iddataSend (data)Thread 0dataUnexpectedRecvQueue4PostedRecvQueueUnexpectedRecvQueuePostedRecvQueueiddataUnexpectedRecvQueueiddata53PostedRecvQueueX2??PostedRecvQueue6UnexpectedRecvQueueX ? 13id6 52?4idid7Recv (data)Thread 1Recv (data)Thread 1Fig. 3. Shared memory queues for communications in smpdev.Todo envío de mensaje ha de recurrir a serializaciónexcepto cuando se trata de arrays de tiposprimitivos. Esto es debido a que es Serializablees una interfaz más extensamente cumplida queCloneable y que presenta conflictos menores conla estructura de cargadores de clase. Así, el objetoa enviar es serializado utilizando el cargadorde clase local del emisor, pero si la deserializaciónse hace mediante la función ObjectInputStreamdel JDK, que usa el cargador del sistema por defecto,la JVM considera que el objeto deserializadoes una instancia de una clase diferente y lanza laexcepción ClassNotFoundException. Para superaresta limitación, se usa una clase desarrollada a medidaque sobreescribe el método resolveClass() deObjectInputStream [15], obteniendo el cargador localal thread y usándolo para cargar la clase medianteJP2011-441

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MPJ ApplicationsF−MPJ Librarydevice layeromxdevibvdevniodev/iodevsmpdevJVMJNIJava SocketsJava Threadsnative commsOpen−MXIBVTCP/IPMyrinet/EthernetInfiniBandEthernetShared MemoryFig. 2.F-MPJ communication devices on shared memory and cluster networksel método Class.forName(). Para que esta aproximaciónfuncione, es necesario tener en cuenta quela ejecución de la deserialización tiene que llevarsea cabo en el thread local, es decir, en el receptor.Esto es relevante para las comunicaciones no bloqueantes,en las que cualquiera de los threads queestá esperando a que se complete puede hacer la comunicaciónefectiva.IV. Evaluación del RendimientoA. Configuración ExperimentalEn esta evaluación se han utilizado dos máquinas.La primera de ellas (“Nehalem”) cuenta con 2 procesadoresIntel Xeon E5520 quad-core Nehalem y 8Gbytes de RAM, con Sistema Operativo Linux CentOS5.3 y la JVM Sun JDK 1.6.0 23. La segunda(“Magny Cours”) es una máquina con 4 procesadoresAMD “Magny Cours”, cada uno con 12 núcleos (48núcleos en total) y 128 Gbytes de RAM. El SistemaOperativo es Linux CentOS 5.5, y la JVM Sun JDK1.6.0 05.Las implementaciones MPJ evaluadas son F-MPJ(release interna) y MPJ Express versión 0.38, ademásde las bibliotecas Intel MPI v.4.0.0.028 (usado enmáquina “Magny Cours”), OpenMPI v1.4.2 (en“Magny Cours”) y v1.3.3 (en “Nehalem”), y MVA-PICH2 r3510 (en “Nehalem”). Para OpenMP se hausado el compilador gcc v.4.3.4.B. Micro-benchmarking de Primitivas Punto aPuntoEl micro-benchmarking en Java se ha llevado acabo con nuestra propia suite, similar a los Intel MPIBenchmarks (IMB) utilizados para bibliotecas MPI,debido a la falta de una suite de benchmarking adecuadapara MPJ.La Figura 4 presenta el rendimiento de un benchmarkde PingPong entre dos procesos/threads dentrode un mismo nodo mostrando la latencia para mensajesde tamaño inferior a un Kbyte y el ancho debanda para mensajes mayores. Para la transferenciade datos se han utilizado arrays de bytes evitando elcoste de la serialización de objetos. Las opciones medidasson F-MPJ y MPJ Express con sus respectivosdispositivos smpdev y las distintas implementacionesMPI utilizando su soporte para memoria compartida.Tal y como se ve en las gráficas, la latencia deMPJ Express es bastante superior a la de las demásopciones, todas por debajo de los 5 µs. En cuantoal ancho de banda, también se queda por debajo,Latency (µs)Point-to-Point Java Communication Performance (Nehalem)8024F-MPJ (smpdev)MPJE (smpdev)7522MVAPICH27020OpenMPI6560185516501445124035103082562041510201 4 16 64 256 1K 4K 16K 64K 256K 1M 4M516M 0Message Size (Bytes)Point-to-point Java Communication Performance (Magny Cours)Latency (µs)4540F-MPJ (smpdev)MPJE (smpdev)IntelMPI 435242230201825162014121510810654204 16 64 256 1K 4K 16K 64K 256K 1M 4M 16M 0Message size (Bytes)Fig. 4. Message-passing point-to-point performance on sharedmemory.302826mientras que el dispositivo de memoria compartidapresentado en este artículo supera ampliamente elrendimiento de todas las demás. Esto es así porqueestá optimizado para que el intercambio de mensajesentre threads se realice mediante copias de arrays,aprovechando de este modo la arquitectura de memoriacompartida. La diferencia de ancho de banda entrediferentes procesadores se debe a la arquitecturadel procesador y a la asignación de threads a cores,ya que hay una probabilidad bastante elevada de quese ejecuten en núcleos de distintos procesadores dentrodel mismo nodo. La pérdida de rendimiento apartir de 1 Mbyte con 8 núcleos, o de 256 Kbytescon 48, se puede superar mediante la segmentaciónde mensajes lo cual permite incrementar la localidadde los datos.C. Micro-benchmarking de Primitivas ColectivasLa Figura 5 presenta el ancho de banda agregadode una operación collectiva representativa (broadcast)utilizando todos los núcleos disponibles en “Nehalem”(8) y “Magny Cours” (48). La selección delBandwidth (Gbps)Bandwidth (Gbps)JP2011-442

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ancho de banda agregado como métrica es debido aque tiene en cuenta la cantidad global de datos transferidos.No obstante, no hay resultados de MPI paratamaños superiores a 4 Mbytes debido a limitacionesde la suite de benchmarking (IMB).Aggregated Bandwidth (Gbps)Aggregated Bandwidth (Gbps)Fig. 5.20018016014012010080604020F−MPJ (smpdev)MPJE (smpdev)MVAPICH2OpenMPIBroadcast on Nehalem (8 cores)01K 4K 16K 64K 256K 1M 4M 16MMessage Size (Bytes)8070605040302010Broadcast on Magny Cours (48 Cores)F−MPJ (smpdev)MPJE (smpdev)IntelMPI 401K 4K 16K 64K 256K 1M 4M 16MMessage Size (Bytes)Message-passing broadcast primitive performanceLos resultados de F-MPJ superan ampliamente alos obtenidos con MPJ Express, gracias a que se evitael uso de buffering y a la optimización de las operacionescolectivas mediante algoritmos específicos [16].En la comparación con MPI, el resultado es más irregular.En “Nehalem” la implementación del broadcastutiliza copias directas del mensaje a transmitir(“pull”), obteniendo elevados anchos de banda, llegandoa superar significativamente el rendimiento deMPI. En “Magny Cours” se utiliza otro tipo de algoritmobasado en árbol que elimina el cuello de botellaen el acceso al thread raíz (el que tiene el mensajea transmitir), balanceando de este modo la carga decomunicaciones. En este caso, se supera el ancho debanda de MPI con mensajes mayores de 4 Kbytes,siendo en general mayor el beneficio de F-MPJ conmensajes grandes y el de MPI con tamaños de mensajepequeños.D. Impacto en el Rendimiento de KernelsEl impacto de smpdev en la escalabilidad de aplicacionesreales ha sido analizado con los NAS ParallelBenchmarks (NPB), seleccionados por ser losmás utilizados en la evaluación de lenguajes, bibliotecasy middleware para HPC. Existen implementacionespara MPI, OpenMP, códigos híbridosMPI/OpenMP y para MPJ (NPB-MPJ) [17]. Dentrode los NPB, se han seleccionado CG (ConjugateGradient), FT (Fourier Transform), IS (Integer Sort)y MG (Multi-Grid), y, además de las opciones presentadasen los otros apartados, se han recogido resultadospara OpenMP y Java threads. Los resultadosse han obtenido en el sistema “Magny Cours”utilizando hasta 32 núcleos (los benchmarks necesitanun número de threads/procesos que sea potenciade 2), y se muestran en términos de speedup en laFigura 6 con el objetivo de evaluar su escalabilidad.En la Tabla I se incluyen los resultados en millonesde operaciones por segundo (MOPS) obtenido en unnúcleo para Java y C/Fortran, a efectos de compararsu rendimiento en términos absolutos. Con el dispositivode memoria compartida de MPJ Express no sehan podido obtener datos para FT y MG debido aque los tamaños de mensaje excedían lo permitidopor sus buffers.TABLA INPB performance (in MOPS) on one coreCG FT IS MGJava 224.069 461.850 42.826 530.351C/Fortran 201.31 711.38 58.61 847.59El principal problema de escalabilidad del dispositivodesarrollado se encuentra en MG, donde presentauna escalabilidad significativamente inferior ala de MPI. Sin embargo, en los restantes benchmarksse obtiene un resultado similar al de MPI, aunqueen FT se obtenga una escalabilidad algo menor enJava, y en IS con 32 núcleos. No obstante, tantoen términos de escalabilidad como de rendimientoen términos absolutos de MPI y F-MPJ son comparables,lo cual pone de manifiesto que el pasode mensajes en Java puede conseguir resultados eficientesque ayuden a superar la tradicional diferenciade rendimiento entre Java y los lenguajes nativos.OpenMP presenta una escalabilidad similar a MPIen CG y FT, quedándose por debajo de F-MPJ enMG e IS (salvo en IS con 32 núcleos, en donde F-MPJ pierde escalabilidad). La implementación conthreads en Java presenta una escalabilidad reducidadebida a la pobre implementación de esta versión delos NPB, ya que F-MPJ, haciendo uso también dethreads, es capaz de obtener mejores prestaciones.V. ConclusionesEste artículo presenta smpdev, un dispositivode comunicación en memoria compartida que haceuso del multithreading para aprovechar el paralelismoinherente a los procesadores multinúcleo.Este dispositivo, integrado en F-MPJ, permite alusuario abstraerse de la programación con threadsaprovechando de forma eficiente las arquitecturas dememoria compartida y, a la vez, disponer de códigosportables y ejecutables en sistemas de memoria distribuida.La evaluación del rendimiento de smpdevmuestra que la solución de paso de mensajes enmemoria compartida propuesta alcanza resultadoscomparables a los obtenidos con bibliotecas nativasMPI, llegando a superarlas en ciertos casos. Estopone de manifiesto que Java es una alternativa degran interés para HPC.JP2011-443

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Speedup16141210864F−MPJ (smpdev)Java ThreadsOpenMPIOpenMPCG Class C24 8 16 32Number of CoresSpeedup12111098765432F−MPJ (smpdev)Java ThreadsOpenMPIOpenMPFT Class C14 8 16 32Number of Cores1412F−MPJ (smpdev)Java ThreadsOpenMPIOpenMPIS Class C2520F−MPJ (smpdev)Java ThreadsOpenMPIOpenMPMG Class C10Speedup86Speedup151042504 8 16 32Number of Cores04 8 16 32Number of CoresFig. 6.NAS parallel benchmaks performance on quad-socket Magny Cours systemAgradecimientosEste trabajo ha sido financiado por el Ministeriode Ciencia e Innovación de España en el marco delproyecto TIN2010-16735 y una beca de Formaciónde Profesorado Universitario del Ministerio de Educación(AP2009-2112). We gratefully thank the AdvancedSchool for Computing and Imaging (ASCI) ofthe Vrije University Amsterdam for providing accessto the “Magny Cours” system.Referencias[1] G. L. Taboada, J. Touriño, and R. Doallo, “Java forHigh Performance Computing: Assessment of CurrentResearch and Practice,” in Proc. 7th Intl. Conf. on Principlesand Practice of Programming in Java (PPPJ’09),Calgary, Alberta, Canada, 2009, pp. 30–39.[2] B. Blount and S. Chatterjee, “An Evaluation of Java forNumerical Computing,” Scientific Programming, vol. 7,no. 2, pp. 97–110, 1999.[3] A. Shafi, B. Carpenter, M. Baker, and A. Hussain, “AComparative Study of Java and C Performance in twoLarge-scale Parallel Applications,” Concurrency andComputation: Practice and Experience, vol. 21, no. 15,pp. 1882–1906, 2009.[4] P. Ekman and P. Mucci, “Design Considerations forShared Memory MPI Implementations on Linux NUMASystems: An MPICH/MPICH2 Case Study,” AdvancedMicro Devices, July 2005.[5] D. Buntinas, G. Mercier, and W. Gropp, “Implementationand Evaluation of Shared-Memory Communicationand Synchronization Operations in MPICH2 using theNemesis Communication Subsystem,” Parallel Computing,vol. 33, no. 9, pp. 634–644, 2007.[6] A. Basumallik, S.-J. Min, and R. Eigenmann, “ProgrammingDistributed Memory Sytems Using OpenMP,”in Proc. 12th Intl. Workshop on High-Level ParallelProgramming Models and Supportive Environments(HIPS’07), Long Beach, CA, USA, 2007, pp. 1–8.[7] D. Millot, A. Muller, C. Parrot, and F. Silber-Chaussumier, “STEP: A Distributed OpenMP forCoarse-Grain Parallelism Tool,” in Proc. 4th Intl. Confon OpenMP in a new era of parallelism (IWOMP’08),West Lafayette, IN, USA, 2008, pp. 83–99.[8] J. Bull, M. Westhead, and J. Obdržálek, “TowardsOpenMP for Java,” in Proc. 2nd European Workshopon OpenMP (EWOMP’00), Edinburgh, UK, 2000, pp.98–105.[9] M. Klemm, M. Bezold, R. Veldema, and M. Philippsen,“JaMP: an Implementation of OpenMP for a Java DSM,”Concurrency and Computation: Practice and Experience,vol. 19, no. 18, pp. 2333–2352, December 2007.[10] R. Veldema, R. F. H. Hofman, R. A. F. Bhoedjang, andH. E. Bal, “Run-time Optimizations for a Java DSM Implementation,”Concurrency and Computation: Practiceand Experience, vol. 15, no. 3-5, pp. 299–316, 2003.[11] A. Kaminsky, “Parallel Java: a Unified API for SharedMemory and Cluster Parallel Programming in 100%Java,” in Proc. 9th Intl. Workshop on Java and Componentsfor Parallelism, Distribution and Concurrency(IWJacPDC’07), Long Beach, CA, USA, 2007, pp. 1–8.[12] M. Baker, B. Carpenter, G. Fox, S.-H. Ko, and S. Lim, “mpiJava: an Object-Oriented Java Interface to MPI,”in Proc. 1st Intl. Workshop on Java for Parallel andDistributed Computing (IWJPDC’99), San Juan, PuertoRico, 1999, pp. 748–762.[13] A. Shafi, B. Carpenter, and M. Baker, “Nested Parallelismfor Multi-core HPC Systems using Java,” Journalof Parallel and Distributed Computing, vol. 69, no. 6, pp.532–545, 2009.[14] G.L. Taboada, J. Touriño, and R. Doallo, “F-MPJ: ScalableJava Message-passing Communications on ParallelSystems,” Journal of Supercomputing, , no. In press(DOI: 10.1007/s11227-009-0270-0), 2011.[15] A. Shafi, J. Manzoor, K. Hameed, B. Carpenter, andM. Baker, “Multicore-enabling the MPJ Express MessagingLibrary,” in Proc. 8th Intl. Conf. on Principlesand Practice of Programming in Java (PPPJ’10), Vienna,Austria, 2010, pp. 49–58.[16] G. L. Taboada, S. Ramos, J. Touriño, and R. Doallo,“Design of Efficient Java Message-Passing Collectives onMulti-core Clusters,” The Journal of Supercomputing,vol. 55, no. 2, pp. 126–154, 2011.[17] D.A. Mallón, G.L. Taboada, J. Touriño, and R. Doallo,“NPB-MPJ: NAS Parallel Benchmarks Implementationfor Message-Passing in Java,” in Proc. 17th EuromicroIntl. Conf. on Parallel, Distributed, and Network-BasedProcessing (PDP’09), Weimar, Germany, 2009, pp. 181–190.JP2011-444

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Aproximación distribuida de incendios forestalescon WSN usando la envolvente convexaM. Ángeles Serna 1 , Aurelio Bermúdez 1 , Rafael Casado 1 , Pawel Kulakowski 2Resumen—La monitorización de fenómenos físicos es uno delos campos de aplicación más prometedores de las redesinalámbricas de sensores. Este trabajo se centra en obtener laforma de un incendio forestal. En este tipo de aplicaciones, lainformación captada por los nodos de la red normalmente setransmite a los extremos de la misma, donde finalmente seprocesa. Sin embargo, aquí supondremos que los nodos de lared son capaces de colaborar entre ellos con el fin de obteneruna aproximación del incendio forestal de manera totalmentedistribuida. En este artículo se proponen y analizan dostécnicas para realizar esta aproximación. La primera hace unuso intensivo de recursos, mientras que la segunda incorporauna técnica de agregación, reduciendo sus requerimientos.Palabras clave— Wireless sensor networks, Environmentalmonitoring, Situation management, Forest fire modeling,Convex hull. I. INTRODUCCIÓNUNO de los usos más prometedores de las redesinalámbricas de sensores (WSNs, wireless sensornetworks) [14] es su aplicación a lo que recientemente seestá denominando como “gestión de situaciones” (situationmanagement) [12]. Se trata de escenarios dinámicos eimpredecibles, donde un complejo sistema distribuidodesplegado sobre un área extensa capta datos en tiemporeal de un gran número de fuentes de información dediversa naturaleza. El objetivo final del sistema esproporcionar apoyo en la toma de decisiones. Por logeneral, el papel de la WSN consiste en obtener unarepresentación o modelo de algún fenómeno físico.Un ejemplo de este tipo de aplicaciones es el sistemaEIDOS (Equipamiento Informático Destinado a laOrientación y Seguridad) [8], en el que una WSN de grantamaño es desplegada desde el aire sobre el área afectadapor un incendio forestal, con el fin de recoger datosambientales y calcular un mapa del incendio. Este mapa sesuministra directamente a los bomberos, que estánequipados con dispositivos móviles. El modelo de fuego esobtenido por los nodos de la red de una maneracompletamente distribuida y colaborativa, a partir de suslecturas y sin la participación de ninguna estación base.En el diseño actual de EIDOS, la primera tarea realizadapor cada nodo consiste en determinar su localización. Ésta1 Instituto de Investigación en Informática de Albacete, Departamento deSistemas Informáticos, Universidad de Castilla–La Mancha.{angeles.serna, aurelio.bermudez, rafael.casado} @uclm.es.2 Department of Telecommunications, AGH University of Science andTechnology. kulakowski@kt.agh.edu.plpuede ser proporcionada por un receptor de GPS (GlobalPositioning System), o estimada por medio de un procesodistribuido de localización [7]. A partir de ese momento,cada vez que el fuego alcanza la posición de un nodo, sedispara un proceso de diseminación de dicha posición, demodo que cada nodo de la red recibe información sobre elevento. Con este fin, se han analizado diversas técnicas dedifusión en [21].En este artículo se presentan y analizan dos formas deprocesar la información recibida por cada nodo durante elproceso de difusión. La primera consiste en almacenartodos los datos recibidos. Como resultado, en cadamomento todos los nodos de la red conocen el conjunto depuntos alcanzados por el fuego. Obviamente, unarepresentación del fuego obtenida a partir de estos datos esbastante exacta. El segundo método es nuestra principalcontribución. Consiste en aplicar una técnica distribuida deagregación de datos [4], con el fin de obtener un modelomás compacto de fuego. En particular, se propone utilizaruna representación del incendio basada en la envolventeconvexa [20]. Como se verá en la sección de evaluación,este enfoque reduce el consumo de memoria en los propiosdispositivos de la red y la sobrecarga introducida en elmedio inalámbrico compartido, manteniendo al mismotiempo la fidelidad en la representación del fuego.El resto del trabajo se organiza de la siguiente forma. Enprimer lugar, la Sección II presenta un estado del arte sobremonitorización de fenómenos físicos con redesinalámbricas de sensores. A continuación, en la Sección IIIse describe el funcionamiento de las técnicas consideradasen este estudio para la aproximación de un incendioforestal. Posteriormente, la Sección IV presenta diversosresultados de simulación que nos permitirán realizar unanálisis comparativo de ambas técnicas. Finalmente, laSección V presenta las conclusiones de nuestrainvestigación y esboza el trabajo futuro.II. TRABAJOS RELACIONADOSEn la literatura existen muchas propuestas para estimar oaproximar el contorno (también el borde o el límite) de unfenómeno físico mediante el uso de redes de sensores.Algunos ejemplos son [1] [3] [11] [18] [22]. Sin embargo,aunque algunas de estas propuestas son en partedistribuidas (por lo general emplean clustering), todos estosmecanismos requieren la participación de una estación baseen algún momento del proceso.JP2011-445

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011La técnica presentada recientemente en [15] también sebasa en un nodo raíz para obtener el contorno delfenómeno. Sin embargo, es particularmente interesantedebido a que incorpora una estrategia para minimizar lasnecesidades de comunicación. En esta propuesta, lossensores intercambian información solo cuando elfenómeno observado no se comporta como se esperaba. Noobstante requiere programar los nodos sensores con unmodelo del fenómeno (llamado tiny model).Además de la envolvente convexa, hay muchas otraspropuestas para representar de forma compacta la forma deun fenómeno físico a partir del conjunto de posicionesdonde se ha detectado su presencia. En [17], los autoresanalizan el uso de líneas y curvas de Bézier para laaproximación de un conjunto de puntos proporcionados poruna WSN. En [6] se utiliza un conjunto de polígonos pararepresentar el contorno del fenómeno, siendo el número devértices empleado un parámetro especificado por elusuario. Por último, existen otros modelos analíticos máscomplejos, como los diagramas de Voronoi [11], kernellinear regression [10], y Gaussian kernel estimation [13],que también se han propuesto para modelar los datosobtenidos por los sensores.III. APROXIMACIONES PARA EL FUEGOEn esta sección se detallan los mecanismos propuestos eneste trabajo para obtener el mapa de un incendio forestal.En primer lugar, se establecen algunas hipótesis generales.A continuación, se describe la técnica de difusión empleadapara transmitir la detección del incendio a toda la red.Sobre la capa de diseminación anterior se puede definir unacapa de representación del fuego. En este trabajo, seanalizan dos aproximaciones distintas a este nivel: elmodelo puntual y el modelo basado en envolvente convexa.A. SuposicionesSuponemos que la WSN se despliega desde el aire. Estoimplica que la topología de la red resultante será irregular ydesconocida.Supondremos que cada nodo conoce su ubicacióngeográfica una vez que cae al suelo. Ésta puede serobtenida mediante un receptor de GPS integrado, o pormedio de la ejecución de un proceso de localización previo(fuera del alcance de este trabajo). Dicha ubicación (p) serádifundida a toda la red en el momento en el que el sensordetecte la llegada del fuego. Además, todos los nodos quereciban el mensaje de difusión (m p ) almacenarán en algunaestructura de datos interna la posición p del iniciador, juntocon una referencia temporal (descrito más adelante).Los nodos no mantienen ninguna estructura jerárquica nidisponen de información sobre la topología de la red(incluyendo la cantidad de vecinos o su ubicación).Por último, en cuanto a la radio, suponemos el empleo deantenas omnidireccionales ideales, que dan lugar a áreas decobertura circulares. En todos los casos empleamos laFig. 1. Perímetro del nodo J cubierto por un mensaje recibido de I.misma potencia de emisión, por tanto los círculos decobertura serán del mismo tamaño.B. Algoritmo de DiseminaciónComo mecanismo de difusión, hemos implementado elalgoritmo ABBA (Area-based Beaconless Algorithm) [19].Este mecanismo se basa en el concepto de perímetrocubierto por los mensajes recibidos. Por ejemplo, en la Fig.I1, el nodo J ha recibido un mensaje m p del nodo I, enrelación a una determinada posición p. La porción deperímetro cubierto por la transmisión (c p ) viene dada por laintersección de dos círculos, y se denota por la diferenciaentre los ángulos inicial () y final (). A continuación, elnodo J puede recibir nuevas copias (m K p , m L Ip ,...) de m pdesde vecinos diferentes (K, L,...). Estas copias generannuevos fragmentos cubiertos en su perímetro, que puedenser total o parcialmente fusionados. Por otra parte, el hechode utilizar círculos con el mismo radio garantiza que, comomucho, habrá dos segmentos por cubrir dentro de dichoperímetro, lo cual reduce la cantidad de informaciónalmacenada en cada nodo. En este caso, c p representará lasuma de ambos segmentos.Cuando un nodo recibe un mensaje de difusión de unvecino, éste no se retransmite instantáneamente. El nodoestablece un retardo (d p ) tras el cual procederá aretransmitir el mensaje, según la expresión d p = (c p /360) xd max , donde c p es el ángulo (en grados) cubierto y d max es unlímite superior predefinido para este retardo. Después,cuando el temporizador expira, se reenvía el mensaje. Sinembargo, la recepción de copias del mismo mensaje antesde que d p termine modificará c p y d p , lo que retrasará latransmisión de nuevo. Por último, el reenvío del mensaje secancela si c p = 360º, es decir, si el perímetro ha sidocubierto completamente por las transmisiones de otrosvecinos.Obviamente, este algoritmo requiere que cada nodomantenga una lista donde almacenar los mensajespendientes de ser retransmitidos, junto con el perímetro nocubierto por otras copias. En adelante, nos referiremos aesta estructura de datos como TL (Lista de Transmisiones).Nótese que, para que un nodo que recibe una informaciónpueda actualizar el perímetro cubierto por el emisor, esnecesario que el mensaje incluya explícitamente la posicióndel emisor. Evidentemente, esto introduce una sobrecargaadicional en las comunicaciones.JP2011-446

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011C. Modelo PuntualEn esta propuesta, cada nodo almacena en una listainterna todas las posiciones de fuego recogidas por la red.Nos referiremos a esta estructura de datos como PL (Listade Posiciones). Cuando se recibe un nuevo punto de fuego,se inserta en TL, y no se inserta en PL hasta que se eliminade TL. Esto ocurre cuando se ha transmitido correctamenteo cuando se cancela. La Fig. 2 (b) muestra el aspecto delfuego (a) cuando se aproxima mediante este modelo.D. Modelo basado en Envolvente ConvexaLa principal diferencia entre este enfoque y el modelopuntual es que, en este caso, PL sólo contiene lasposiciones que forman la envolvente convexa.Cuando se recibe un nuevo punto de fuego, éste se insertaen TL y PL simultáneamente. Si el nuevo punto estáincluido en la envolvente convexa, se ignora. De locontrario, el punto está fuera de la envolvente, y suinclusión modifica su perímetro. Además, la actualizacióndel perímetro puede implicar la eliminación de otros nodosen el mismo. La Fig. 2 (c) muestra el aspecto del fuego (a)cuando se aproxima usando este modelo.Este enfoque reduce los recursos en los nodos de red. Sila información recibida contribuye a su modelo actual delincendio, los nodos almacenan y reenvían esta información.En otro caso, no es necesario ni transmitirla ni almacenarla.IV. EVALUACIÓNEn esta sección, se analizan las dos propuestas descritasanteriormente. En primer lugar, se presenta el entorno de# of correct cells100009000800070006000500040003000200010000-1000(a) Propagación del fuego (b) Puntual (c) Envolvente convexaFig. 2. Aproximaciones del fuego.FarsitePunctual R5Punctual R4Punctual R3Punctual R2Punctual R1simulación. A continuación, se establece un criterio paraevaluar la calidad de los modelos obtenidos. Antes decomparar ambas propuestas, la aproximación puntual seajusta con el fin de obtener su mejor rendimiento. Lacomparativa se centra en la precisión, los recursosconsumidos, y la escalabilidad de los dos enfoques.A. Entorno de SimulaciónUsamos un entorno de simulación de área forestal [9]desarrollado para el sistema EIDOS , que permite desplegaruna WSN, propagar un incendio forestal, situar a losbomberos en una localización concreta y ver la evoluciónde los frentes de llama que ellos perciben. Esta herramientase compone de varios módulos independientes einterconectados, que comparten información a través deuna base de datos global MySQL. En primer lugar se utilizaFarsite [5] para simular un incendio en un área forestalconcreta, usando datos geográficos, medioambientales y devegetación reales. A continuación, la aplicación EIDOS seejecuta en cada nodo de la red en un simulador de WSN(desarrollado en Python / TOSSIM [16]).Con el fin de obtener resultados realistas, el simuladorincorpora un modelo de interferencia, ruido y el modelo deFriis de propagación de la señal. Se ha modelado la radioque incorporan los motes Iris de Crossbow [2], con unapotencia de transmisión de 3 dBm y potencia mínima derecepción de -90 dBm, obteniendo un radio de coberturapróximo a los 87 metros. También se supone que todos losnodos de la red están equipados con un receptor de GPS.En cada simulación, se despliega de forma aleatoria unared de sensores sobre un área de 1000×1000 metros. Se han0 1 2 3 40 1 2 3 4Time(h)Time(h)(a) Valores absolutos(b) Valores normalizadosFig. 3. Calidad de la aproximación (Farsite vs modelo puntual) (tamaño de red: 500 nodos).# of correct cells1,510,50-0,5-1-1,5FarsitePunctual R5Punctual R4Punctual R3Punctual R2Punctual R1JP2011-447

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Fuego real (d) Radio = 3 (e) Radio = 4Fig. 4. Aproximación del modelo puntual a través de círculos.considerado tamaños de red de 200, 300, 400, 500, 600,700, 800, 900 y 1000 nodos, con un grado de conectividadasociado de 4.4, 6.5, 8.7, 11.06, 13.16, 15.37 17.58, 19.75 y22.07 respectivamente. Durante la ejecución de cadasimulación, el fuego alcanza a todos los nodos de la red(quemándolos progresivamente). Cada vez que un nododetecta la proximidad del fuego (por medio de un aumentobrusco en la temperatura captada), procede a difundir suposición a toda la red. Para la ejecución del mecanismo dedifusión el parámetro d max se ha fijado en 5 segundos.Finalmente, para incrementar la representatividad de losresultados, cada experimento se ha repetido varias vecespara cada tamaño de red y técnica de aproximación,presentándose aquí los valores medios obtenidos.B. MetodologíaEl simulador Farsite representa el área en que se haextendido el fuego "original" como un raster (o grid)llamado TOA (Time Of Arrival). El valor de cada celda delraster proporciona la hora de llegada del fuego a su centro,y se puede definir como t burning =TOA(celda), asumiendoque un valor infinito indica que el fuego nunca haalcanzado esa posición. La información del TOA permiteanalizar cómo se propaga el fuego a lo largo del tiempo. Enparticular, dado un tiempo t, una celda se quema cuandot≤TOA(celda). En la Fig. 3 (a), la serie "Farsite" muestra lacantidad de celdas quemadas a medida que avanza eltiempo. El eje horizontal representa el tiempo. Como elincendio forestal se extiende sobre un área de 1000×1000metros y el tamaño de la celda es de 10×10 metros, elnúmero máximo de celdas quemadas es igual a 10000.A efectos comparativos, cada aproximación deberíapresentar sus resultados utilizando la misma representación.Una vez que se tienen dos archivos TOA, TOA Farsite yTOA model , se estima la calidad de la aproximación pormedio del número de celdas con fuego correctamentedetectadas en cada instante.C. Resultados1) Ajuste del Modelo PuntualEn el modelo puntual explicado en la Sección III, el fuegose representa como una colección de puntos de fuegorecopilados por la red. Este modelo supone que el fuegoestá activo en los alrededores de cada una de estaslocalizaciones. En nuestro análisis, consideraremos que lazona quemada viene dada por el conjunto de círculoscentrados en dichas localizaciones. La Fig. 4 muestra variasaproximaciones puntuales de un incendio, obtenidasmediante el uso de círculos con radios de 1 a 5 celdas. Acontinuación, se analiza la influencia del tamaño de estoscírculos en la exactitud del modelo resultante.Además de la serie "Farsite", la Fig. 3 (a) muestra lacantidad de celdas quemadas aproximadas correctamentepor el modelo puntual, usando círculos con radios de 0 a 5celdas. La Fig. 3 (b) muestra los mismos resultados, peronormalizados a la cantidad real de celdas quemadas (segúnFarsite). Los valores negativos representan que la cantidadde celdas quemadas detectadas incorrectamente supera lacantidad de las detectadas correctamente. De ambasgráficas, se puede concluir que los círculos pequeñosrepresentan el fuego mejor al inicio de la simulación. Porotra parte, después de dos horas, el fuego es lo bastanteamplio como para estar mejor representado con círculosmás grandes. Además, para el círculo R5 (el radio mayor),las mejoras obtenidas en incendios extensos no compensael error inicial, cuando se aproxima un conato de incendio.Por esta razón, se seleccionan los círculos R3 y R4(descartando los círculos R0, R1, R2 y R5) como los másadecuados para representar el fuego en el análisis siguiente.2) Precisión de la AproximaciónUna vez que la representación puntual se ha ajustado a R3y R4 con el fin de obtener resultados óptimos, se comparaesta aproximación con la basada en envolvente convexa. LaFig. 5 muestra los resultados de la misma forma que la Fig.3. Podemos ver que la envolvente convexa muestra un buencomportamiento medio. Durante los primeros 30 minutos,# of correct cells100009000800070006000500040003000200010000-1000FarsitePunctual R4Convex HullPunctual R30 1 2Time(h)3 40 1 2 Time(h) 3 4(a) Valores absolutos(b) Valores normalizadosFig. 5. Calidad de la aproximación (Farsite vs modelo puntual y envolvente convexa) (tamaño de red: 500 nodos).# of correct cells1,210,80,60,40,20-0,2-0,4-0,6-0,8FarsitePunctual R4Convex HullPunctual R3JP2011-448

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Memory Required (PL items)400350300250200150100500PunctualConvex Hull0 1 2 3 4Time (h)Fig. 6. Consumo de memoria (tamaño de red: 500 nodos).es la mejor representación. Después de eso, se puedeobservar una clara reducción en su exactitud (t = 1,2 horas).La razón es que la envolvente convexa no asimila bien loscambios repentinos en la dirección del viento. Por último,cuando el fuego se extiende sobre el área, su precisiónaumenta de nuevo. Después de dos horas de simulación, laaproximación basada en envolvente convexa supera a R3 ymuestra un comportamiento similar a R4.3) Recursos Consumidos en la WSNEn el modelo puntual, cada nodo de la WSN almacenatodos los puntos recogidos en la lista PL (ver sección III.C).Por el contrario, para el modelo basado en envolventeconvexa sólo son relevantes los puntos situados en elperímetro del incendio, mientras que los puntos interioresse descartan.La Fig. 6 muestra la cantidad media de puntosalmacenados en PL a lo largo del tiempo, para una red de500 nodos. Se debe tener en cuenta que los recursosconsumidos en la aproximación puntual son independientesdel tamaño del círculo utilizado, y que son proporcionalesal tamaño de la red. En la gráfica podemos ver que, enmedia, sólo se han recibido 360 puntos (en lugar de 500puntos) después de 5 horas de simulación. Esto se debe ados razones. La primera es que el incendio forestal nocubre toda la zona de despliegue y, en consecuencia, haynodos que no detectan el fuego. La segunda razón es que amedida que el fuego avanza y los nodos se queman, la redestá cada vez más desconectada, lo que reduce la eficaciade las correspondientes difusiones.# of correct cells9000800070006000500040003000200010000FarsitePunctual R4Punctual R3ConvexHull0 5 10 15 20 25Connectivity DegreeFig. 7. Calidad de la representación para diferentes densidades.Por otro lado, la figura muestra que la aproximaciónbasada en envolvente convexa requiere muy poca memoriaen los dispositivos. Además, estos requisitos son constantesy no dependen del tamaño de la red.4) Escalabilidad de las PropuestasA continuación, se analiza la escalabilidad de lasaproximaciones al modificar la cantidad de nodosdesplegados en la misma zona y, en consecuencia, variandoel grado de la red. En la Fig. 5 (b) se observa que, despuésde 3 horas los resultados normalizados llegan a un estadode equilibrio. Por esta razón, los resultados siguientes sehan obtenido tras 3 horas de simulación.La Fig. 7 muestra la cantidad de celdas del TOAdetectadas correctamente por las diferentes propuestas enfunción del grado de la red. Como se esperaba, todos losalgoritmos obtienen mejores aproximaciones al aumentar ladensidad de la red. Se puede notar que las redes densasproporcionan resultados muy similares, cercanos al óptimo.Por otra parte, el rendimiento de las aproximacionespuntuales se degrada significativamente cuando se ejecutansobre los despliegues poco densos. Por el contrario, laaproximación basada en la envolvente convexa es menossensible a este hecho, obteniendo los mejores resultados.La Fig. 8 muestra la cantidad media de puntosalmacenados (elementos en PL) después de 3 horas, enfunción del tamaño de la red. Podemos ver que la memoriaconsumida por la aproximación puntual aumentalinealmente con el tamaño de la red. La razón es que lacantidad de puntos de fuego aumenta de manera lineal conel tamaño de la red, y en esta aproximación se almacenatoda la información recibida. Por otro lado, la aproximaciónbasada en envolvente convexa escala perfectamente,porque los recursos necesarios son constantes y nodependen del tamaño de la red. La razón es que el conjuntode puntos involucrados en el perímetro se mantienerelativamente estable, mientras que la cantidad de puntosdescartados (debido a que se encuentran contenidos en laenvolvente) aumenta linealmente con el tamaño de la red.Finalmente, la Fig. 9 muestra el efecto de los mecanismosde aproximación sobre el medio inalámbrico, a través de lacantidad de mensajes enviados (a), retransmisionespendientes (b), y colisiones (c) por nodo, en función delgrado de la red. Como se mencionó anteriormente, laMemory Required (PL items)8007006005004003002001000PunctualConvexHull0 5 10 15 20 25Connectivity DegreeFig. 8. Consumo de memoria para diferentes densidades.JP2011-449

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Sent messages per node300250200150100500PunctualConvex Hull0 5 10 15 20 25Connectivity Degreeaproximación puntual retransmite todos los puntosrecopilados. Por lo tanto, en las gráficas, los mensajesenviados, retransmisiones pendientes, y colisiones debenmostrar el mismo comportamiento que el consumo dememoria analizado en la Fig. 8.Por otra parte, en el modelo basado en envolventeconvexa la cantidad de mensajes enviados no es sensible ala densidad de la red. Podemos concluir que una gran partede los puntos de fuego descartados en la Fig. 8 fueroneliminados durante el proceso de inserción en la envolventeconvexa, antes de su retransmisión. Como consecuencia,tenemos una baja sobrecarga, debida a los pocos puntos delperímetro del incendio. Obviamente, dado que este enfoquereduce la cantidad total de mensajes a transmitir, tambiénse reducen las retransmisiones pendientes y las colisiones.V. CONCLUSIONES Y TRABAJO FUTUROEn este trabajo se han propuesto y analizado dos métodosdistribuidos de aproximación de incendios forestalesusando redes de sensores. En el modelo puntual, cada nodoalmacena y transmite toda la información que recibe de lared. A diferencia del anterior, en el modelo basado enenvolvente convexa los nodos procesan la informaciónrecopilada, descartando aquella que no es relevante. Laevaluación de estas técnicas ha demostrado que el uso de laenvolvente convexa consume menos recursos en los nodosy en el medio compartido, proporcionando además unabuena aproximación al fuego real.Como trabajo futuro, tenemos previsto mejorar la formade representar el fuego. Por ejemplo, se puede reducir lacantidad de puntos necesarios en redes muy densas.Además, nos planteamos emplear mejores aproximacionespara incendios no convexos. Aprovechar la informaciónsobre las posiciones a las que no ha llegado el fuegotodavía y enriquecer el modelo con información sobre elcomportamiento reciente del incendio (velocidad,dirección, etc.) son otros trabajos futuros.VI. AGRADECIMIENTOSEste trabajo ha sido financiado conjuntamente por elMinisterio de Educación y Ciencia (MEC), el Ministerio deCiencia e Innovación (MICINN) y el Fondo Europeo deDesarrollo Regional (FEDER) y el Programa UNITE FP7bajo los proyectos CSD2006-00046 y TIN2009-14475-Pending retransmissions per node181614121086420PunctualConvex Hull0 5 10 15 20 25Connectivity DegreeCollisions per node302520151050PunctualConvex Hull0 5 10 15 20 25Connectivity Degree(a) Mensajes (b) Retransmisiones pendientes (c) ColisionesFig. 9. Sobrecarga en el medio para distintas densidades.C04; y por la Junta de Comunidades de Castilla–LaMancha bajo el proyecto PII1C09-0101-9476.VII. REFERENCIAS[1] Chintalapudi, K.K. and Govindan, R. 2003. Localized edge detection in sensorfields. Ad Hoc Networks (September 2003), 273–291.[2] Crossbow Technology, Inc. 2011. http://www.xbow.com/[3] Duttagupta, S., Ramamritham, K., and Ramanathan, P. 2006. Distributedboundary estimation using sensor network. In IEEE International Conf. onMobile Ad-hoc and Sensor Systems. 316–325.[4] Fasolo, E., Rossi, M., Widmer, J., Zorzi, M. In-network aggregationtechniques for wireless sensor networks: a survey. IEEE WirelessCommunications, 14, 2 (April 2007), 70–87.[5] Fire.org. 2011. http://fire.org/[6] Gandhi, S., Hershberger, J., and Suri, S. 2007. Approximate Isocontours andSpatial Summaries for Sensor Networks. In 6th International Conference onInformation Processing in Sensor Networks. IPSN’07. 400–409.[7] García, E. M., Bermúdez, A., and Casado, R. 2011. Range-Free Localizationfor Air-Dropped WSNs by Filtering Neighborhood Estimation Improvements.In Int. Conf. on Computer Science and Information Technology. 325–337.[8] García, E. M., Bermúdez, A., Casado, R., and Quiles, F. J. 2007. CollaborativeData Processing for Forest Fire Fighting. In adjunct poster/demo proceedingsof the 4th European Conference on Wireless Sensor Networks. 3–4.[9] García, E. M., Serna, M. A., Bermúdez, A. and Casado, R. 2008. Simulating aWSN-based Wildfire Fighting Support System. In IEEE Int. Symposium onParallel and Distributed Processing with Applications. ISPA’08. 896–902.[10] Guestrin, C., Bodik, P., Thibaux, R., Paskin, M., and Madden, S. 2004.Distributed regression: an efficient framework for modeling sensor networkdata. In Int. Symposium on Information Processing in Sensor Networks. 1–10.[11] Ham, M. I. and Rodriguez, M. A. 2010. A Boundary ApproximationAlgorithm for Distributed Sensor Networks. International Journal of SensorNetworks, 8, 1 (2010), 41–46.[12] Jakobson, G., Buford, J. F., and Lewis, L. 2010. Guest Editorial: SituationManagement. IEEE Communications Magazine, 48, 3 (March 2010), 110–111.[13] Jin, G. and Nittel, S. 2008. Toward Spatial Window Queries over ContinuousPhenomena in Sensor Networks. IEEE Transactions on Parallel andDistributed Systems, 19, 4 (April 2008), 559–571.[14] Karl, H. and Willig, A. 2005. Protocols and Architectures for Wireless SensorNetworks. Wiley.[15] King, K. and Nittel, S. 2010. Efficient Data Collection and Event BoundaryDetection in Wireless Sensor Networks Using Tiny Models. In 6th Int. Conf.on Geographic Information Science. GIScience'10. 110–114.[16] Levis, P., Lee, N., Welsh, M. and Culler, D. TOSSIM: accurate and scalablesimulation of entire TinyOS applications. In 1st ACM Conf. on EmbeddedNetworked Sensor Systems. SenSys 2003. 126–137.[17] Li, Y., Loke, S.W., and Ramakrishna, M.V. 2007. Performance Study of DataStream Approximation Algorithms in Wireless Sensor Networks. In Int. Conf.on Parallel and Distributed Systems. ICPADS 2007. 1–8.[18] Liao, P. K., Chang, M. K., and Jay Kuo, C.C. 2007. A Cross-Layer Approachto Contour Nodes Inference with Data Fusion in Wireless Sensor Networks. InProc. of IEEE Wireless Communications and Networking Conf. 2773–2777.[19] Ovalle-Martínez, F. J., Nayak, A., Stojmenovic, I., Carle, J., and Simplot-Ryl,D. 2006. Area-based beaconless reliable broadcasting in sensor networks.International Journal on Sensor Networks, 1, 1/2 (January 2006), 20–33.[20] Preparata, F. P., Hong, S.J. Convex Hulls of Finite Sets of Points in Two andThree Dimensions. Communications of ACM, 20, 2 (February 1977), 87–93.[21] Serna, M. A., García, E. M., Bermúdez, A., and Casado, R. 2010. InformationDissemination in WSNs Applied to Physical Phenomena Tracking. Int. Conf.Mobile Ubiquitous Computing, Systems, Services and Technologies. 458–463.[22] Zhu, X., Sarkar, R., Gao, J., and Mitchell, J.S.B. 2008. Light-weight ContourTracking in Wireless Sensor Networks. In 27th IEEE Conf. on ComputerCommunications. INFOCOM 2008. 1175–1183.JP2011-450

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A First Approach to King Topologies forOn-Chip NetworksE. Stafford 1 E. Stafford 2 J.L. Bosque 3 , C. Martínez 4 , F. Vallejo 5 , R. Beivide 6 , C. Camarero 7Abstract— In this paper we propose two new topologiesfor on-chip networks that we have denoted as kingmesh and king torus. These are a higher degree evolutionof the classical mesh and torus topologies. In aking network packets can traverse the networks usingorthogonal and diagonal movements like the king on achess board. First we present a topological study addressingdistance properties, bisection bandwidth andpath diversity as well as a folding scheme. Second weanalyze different routing mechanisms. Ranging fromminimal distance routings to missrouting techniqueswhich exploit the topological richness of these networks.Finally we make an exhaustive performanceevaluation comparing the new king topologies withtheir classical counterparts. The experimental resultsshow a performance improvement, that allow us topresent these new topologies as better alternative toclassical topologies.Keywords— Hoja de estilo, LATEX, Jornadas de Paralelismo.I. IntroductionALTHOUGH a lot of research on interconnectionnetworks has been conducted in the lastdecades, constant technological changes demand newinsights about this key component in modern computers.Nowadays, networks are critical for managingboth off-chip and on-chip communications.Some recent and interesting papers advocate fornetworks with high-radix routers for large-scale supercomputers[1][2].The advent of economical opticallinks enables this kind of topologies that uselong global wires. Although the design scenario isvery different, on-chip networks with higher degreethan traditional 2D meshes or tori have also beenrecently explored[3]. Such networks entail the use oflong wires in which repeaters and channel pipeliningare needed. Nevertheless, with current VLSI technology,the planar substrate in which the network isgoing to be deployed suggests the use of 2D meshliketopologies. This has been the case of Tilera[4]and the Intel’s Teraflop research chip[5], with 64 and80 cores arranged in a 2D mesh respectively. Forthcomingtechnologies such as on-chip high-speed signallingand optical communications could favor the1 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: esteban.stafford@gestion.unican.es2 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: esteban.stafford@gestion.unican.es3 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: joseluis.bosque@unican.es4 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: carmen.martinez@unican.es5 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: fernando.vallejo@unican.es6 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: ramon.beivide@unican.es7 Dpto. Electrónica y Computadores, Univ. Cantabria, e-mail: cristobal.camarero@alumnos.unican.esuse of higher degree on-chip networks.This paper proposes an intermediate solution. Weanalyze networks whose degrees double the radix ofa traditional 2D mesh while preserving an attractivelayout for planar VLSI design. We study degree eightnetworks in which a packet at a given node can travelin one hop to any of its eight neighbours just like theking on a chessboard. Thus, we denote them kingmeshes and king tori. In this way, we adopt a moreconservative evolution towards higher radix networkstrying to exploit the advantages while avoiding theuse of long wires. The simplicity and topologicalproperties of these networks offer tantalising featuresfor future on-chip architectures: higher throughput,smaller latency, trivial partitioning in smaller networks,good scalability and high fault-tolerance.The use of diagonal topologies has been consideredin the past, in the fields of VLSI[6], FPGA[7] and interconnectionnetworks[8]. Also mesh and toroidaltopologies with added diagonals have been considered,both with degree six[9] and eight[10].The kinglattice has been previously studied in several papersof Information Theory[11].The goal is to explore the suitability of king topologiesto constitute the communication substrate offorthcoming on-chip parallel systems. With this ideain mind, we present the foundations of king networksand a first attempt to unleash their potential. Themain contributions of our research are the following:i) An in-depth analysis of the topological characteristicsof king tori and king meshes.ii) The introduction and evaluation of king tori,not considered previously in the literature.iii) A folding scheme ensuring king tori scalability.iv) An adaptive and deadlock-free routing algorithmfor king topologies.v) A first performance evaluation of king networksbased on synthetic traffic.The remainder of this paper is organized as follows.Section II is devoted to define the network topologiesconsidered in this paper. The most relevant distanceparameters and the bisection bandwidth arecomputed for each network and a folding methodis considered for networks with wrap-around links.Section III tackles the task of finding routing algorithmsto unlock the networks’ potential high performance,starting with simple minimum-distance algorithmsand evolving to more elaborate missroutingand load balancing techniques. Section IV presentsa first performance evaluation of these networks. Finally,Section V concludes the paper highlighting itsmost important findings.JP2011-451

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011II. Description of the TopologiesIn this Section we define and analyze distanceproperties of the network topologies considered inthis paper: square meshes, square king meshes,square tori and square king tori. Then, we obtain expressionsfor significant distance parameters as wellas the bisection bandwidth. Finally, we considerlay-out possibilities minimizing wire length for thosetopologies with wrap-around edges.As usual, networks are modeled by graphs. Verticesrepresent processors and edges represent thecommunication links. In this paper we will only considersquare networks, as sometimes networks withsides of different length result in an unbalanced use ofthe links in each dimension[12]. Therefore, in the followingwe will obviate the adjective “square”. Hence,for any of the networks considered here the numberof nodes will be n = s 2 , for any integer s > 1.By M s we will denote the usual mesh of sides. This is a very well-known topology which hasbeen deeply studied. A mesh based network of degreeeight can be obtained by adding new links suchthat, any packet not only can travel in orthogonaldirections, but also can use diagonal movements.Will denote by KM s the king mesh network, whichis obtained by adding diagonal links (just for nonperipheralnodes) to M s .Note that both networks are neither regular norvertex-symmetric. The way to make this kind of networkregular and vertex-symmetric is to add wraparoundlinks so that every node has the same numberof neighbors. We will denote as T s the usual torusnetwork of side s. The torus is obviously the fourdegree regular counterpart of the mesh. Then, KT swill denote the king torus network, that is, a kingmesh with new wrap-around links in order to obtainan eight degree regular network. Another way to seethis network is as a torus with extra diagonal linksthat turn the four degree torus into an eight degreenetwork. In Figure 1 an example of each is shown.In an ideal system, transmission delays in the networkcan be inferred from its topological properties.The maximum packet delay is given by the diameterof the graph. It is the maximum length over allminimum paths between any pair of nodes. The averagedelay is proportional to the average distanceof every pair of nodes of the network. In Table I werecord these parameters of the four networks considered.The diameter and average distance of meshand torus are well-known values[13]. The distanceproperties of king torus were presented in [14].An specially important metric of interconnectionnetworks is the throughput, the maximum data ratethe network can deliver. In the case of uniform traffic,the throughput is bounded by the bisection. Accordingto [13], in networks with homogeneous channelbandwidth, as the ones considered here, the bisectionbandwidth is proportional to the channel countacross the smallest cut that divides the network intotwo equal halves. This value represents an upperbound in the throughput under uniform traffic.Fig. 1. Examples of Mesh, King Mesh, Torus and King TorusNetworks.Network M s KM S T s KT sDiameter 2s s s ⌊ s 2 ⌋Average Distance ≈ 2 3 s ≈ 7 15 s ≈ s 2≈ s 3Bisection Bandwidth 2s 6s 4s 12sTABLE ITopological ParametersIn Table I, values for the bisection for mesh andtorus are shown, see [13]. The obtention of the bisectionbandwidth in king mesh and torus is straightforward.Note that a king network doubles the numberof links of its orthogonal counterpart but has threetimes the bisection bandwidth.In a more technological level, physical implementationof computer networks usually requires similar,if not constant, link lengths. In the contextof networks-on-chip, mesh implementation is fairlystraightforward. A regular mesh can be lade out witha single metal layer. Due to the crossing diagonallinks, the king mesh requires two metal layers.However tori have wrap-around links whose lengthdepend on the size of the network. To overcome thisproblem, a well known technique is graph folding. Astandard torus can be implemented with two metallayers. Our approach to folding king tori is basedon the former but because of the diagonal links fourmetal layers are required. As a consequence of thefolding, √ the length of the links is between two and8 in king tori. This seems to be the optimal solutionfor this kind of networks. Figure II shows a8 × 8 folded king torus. For the sake of clarity, thefolded graph is shown with the orthogonal and diagonallinks separated.Now, if we compare king meshes with tori, we observethat the cost of doubling the number of linksJP2011-452

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2. Folding of King Torus Network. For the sake of clarity,the orthogonal and diagonal links are shown in separatesgraphs.gives great returns. Bisection bandwidth is 50%larger, average distance is almost 5% less and diameterremains the same. In addition, implementationof a king mesh on a network-on-chip is simpler, asit does not need to be folded and fits in two metallayers just like a folded torus.III. RoutingThis section explores different routing techniquestrying to take full advantage of the king networks.For simplicity it focuses on toroidal networks assumingthat meshes will have a similar behaviour. Ourdevelopment starts with the most simple minimumdistance routing continuing through to more elaborateload balancing schemes capable of giving highperformance in both benign and adverse traffic situations.Enabling packets to reach their destination in directnetworks is traditionally done with source routing.This means that at the source node, whenthe packet is injected, a routing record is calculatedbased on source and destination using a routing function.This routing record is a vector whose integercomponents are the number of jumps the packetmust make in each dimension in order to reach itsdestination.In 2D networks routing records have two components,∆ X and ∆ Y . These components could be usedto route packets in king networks, but the diagonallinks, that can be thought as shortcuts, would neverbe used. Then it is necessary to increase the numberof components in the routing record to accountfor the greater degree of these new networks. Thuswe will broaden the definition of routing record as avector whose components are the number of jumpsa packet must make in each direction, not dimension.Thus, king networks will have four directions,namely X and Y as the horizontal and vertical, Z forthe diagonal y = x and T for the diagonal y = −x.A. Minimal RoutingTo efficiently route packets in a king network,we need a routing function that takes source anddestination nodes and gives a routing record thatmakes the packet reach its destination in the minimumnumber of jumps. Starting with the 2D routingrecord, it is easy to derive a naive king routingrecord that is minimal(Knaive). From the four componentsof the routing record, this routing functionwill not use two of them. Hence, routing records willhave, at most, two non-zero components, one is orthogonaland the other is diagonal. The algorithm issimple, consider (∆ X , ∆ Y ) where ∆ X > ∆ Y > 0.The corresponding king routing record would be(δ X , δ Y , δ Z , δ T ) = (∆ X − ∆ Y , 0, ∆ Y , 0). The rest ofthe cases are calculated in a similar fashion.In addition to being minimal, this algorithm balancesthe use of all directions under uniform traffic, akey aspect in order to achieve maximum throughput.The drawback, however, is that it does not exploitall the path diversity available in the network. Pathdiversity is defined as the number of minimal pathsbetween a pair of nodes a, b of a network. For meshand tori will denote it as |R ab |.( )|∆x | + |∆ y ||R ab | =.|∆ x |Similarly, in king mesh and tori the path diversityis:( ) |∆x ||RK ab | =|∆ y |2( nn∑( )( )n 2n − 2jwhere = (−1)k)j j n − k − j2j=0Thus, the path diversity for king networks is overwhelminglyhigher than in meshes and tori. Take forexample ∆ x = 7, ∆ y = 1, this is the routing recordto go from the white box to the gray box in Figure1. In a mesh the path diversity would be R ab = 8while in a king mesh RK ab = 357.Now, the corresponding Knaive routing record is(δ X , δ Y , δ Z , δ T ) = (6, 0, 1, 0). This yields only 7 alternativepaths, so 350 path are ignored, this is evenless than the 2d torus. This is not a problem underuniform and other benign traffic patterns but onadverse situations a diminished performance is observed.For instance, see the performance of 16 × 16torus with 1-phit packets in Figure 3. The throughputin uniform traffic of the Knaive algorithm is 2.4times higher than that of a standard torus, whichis a good gain for the cost of doubling network resources.However, in shuffle traffic, the throughputis only double and under other traffic patterns evenless.A way of improving this is increasing the path diversityby using routing records with three non-zerocomponents. This can be done by applying the notionthat two jumps in one orthogonal direction canbe replaced by a jump in Z plus one in T withoutaltering the path’s length. Based on our experimentswe have found that the best performance is obtainedwhen using transformations similar to the following.⌊δX(δ X , 0, δ Z , 0) → (3⌋ ⌊δX, 0, δ Z +3⌋ ⌊δX,3⌋)Being this an enhancement of the Knaive algorithmwe denote it EKnaive. It is important to noteJP2011-453

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Throughput (phits/cycle/node)16x16 king torus, uniform traffic1.210.80.60.40.200 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8Offered load (phits/cycle/node)Throughput (phits/cycle/node)1.210.80.60.40.216x16 king torus, shuffle trafficRouting2d torusKnaiveEKnaiveKmissKBugal00 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8Offered load (phits/cycle/node)Fig. 3.Throughput comparison of the various routing algorithms in 16 × 16 toroidal networks.Routing Record Path(δ X , δ Y , δ Z , δ T ) Diversity(6,0,1,0) 7(4,0,2,1) 105(2,0,3,2) 210(0,0,4,3) 35theoretical 357TABLE IIAlternative routing records for (6,0,1,0) withcorresponding path diversitythat it is still minimum-distance and gives more pathdiversity but not all that is available. Continuingwith our example, this algorithm will give us 210 ofthe total 357 paths (See Table II).As can be seen in Figure 3, the EKnaive routingrecord improves the throughput in some adverse trafficpatterns due to its larger path diversity. Howeverthis comes at a cost. The inherent balance in thelink utilization of the Knaive algorithm is lost, thusgiving worse performance under uniform traffic.B. MisroutingIn the light of the previous experiences, we findthat direction balancing is key. But is it importantenough to relax the minimum distance requirement?In response to this question, we have developed anew routing function whose routing record may havefour non-zero components. Forcing packets to useall directions will cause missrouting as the minimumpaths will no longer be used. Thus we name thisapproach Kmiss.Ideally, to achieve direction balance, the four componentsshould be as close as possible. However thiswould cause path lengths to be very long. A compromisemust be reached between path length and componentsimilarity. With Kmiss, the routing recordis extracted from a table indexed by the 2D routingrecord. The table is built so that the components ofthe routing records do not differ more than 3.The new function improves the load balance regardlessof the traffic pattern and provides packetswith more means to avoid local congestion. In additionit increases the path diversity.Experimental results as those shown in Section IVshow that this algorithm gives improved throughputin adverse traffic patterns but the misrouting diminishesits performance in benign situations. Figure 3shows that Kmiss is still poor in uniform traffic, butgives the highest throughput under shuffle.C. Routing CompositionIn essence, we have a collection of routing algorithms.Some are very good in benign traffic butperform badly under adverse traffic, while others arereasonably good in the latter but disappointing inthe former. Ideally, we would like to choose whichalgorithm to use depending on the situation. Betteryet would be that the network switches from one toanother by its self. This is achieved to a certain extentin Universal Globally Adaptive Load-balancing(UGAL)[15]. In a nutshell what this algorithm doesis routing algorithm composition. Based on localtraffic information, each node decides whether apacket is sent using a minimal routing or the nonminimalValiant’s routing [16], composing a betteralgorithm that should have the benefits of both ofthe simple ones.As we show next, KBugal is an adaptation ofUGAL to king networks and bubble routing withtwo major improvements. On one hand, for the nonminimalrouting, instead of Valiant’s algorithm, weuse Kmiss routing. This approach takes advantageof the topology’s path diversity without significantlyincreasing latency and it has a simpler implementation.On the other hand, the philosophy behindUGAL resides in estimating the transmission time ofa packet at the source node based on local information.Thus selecting the shortest output queue lengthamong all profitable channels both for the minimaland the non-minimal routings. In the best scenario,the performance of KBugal is the best out of the twoindividual algorithms, as can be seen in Figure 3.The use of bubble routing allows deadlock-free operationwith only two virtual channels per physicalchannel in contrast to the three used by originalUGAL. In order to get a better estimation, KBugaltakes into account the occupation of both virtualJP2011-454

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Throughput (phits/cycle/node)8x8 networks, throughput2.521.510.500 0.5 1 1.5 2 2.5 3Offered load (phits/cycle/node)Latency (cycles)302826248x8 networks, latency22Topology20king_meshking_torus18meshtorus160 0.2 0.4 0.6 0.8 1Offered load (phits/cycle/node)Fig. 4.Throughput and latency of king topologies with Knaive compared to mesh and tori under uniform traffic.45uniform traffic 8x8 king torus45complement traffic 8x8 king torus45butterfly traffic 8x8 king torus404040Latency (cycles)353025Latency (cycles)353025Latency (cycles)353025202020150 0.2 0.4 0.6 0.8 1Offered load (phits/cycle/node)150 0.2 0.4 0.6 0.8 1Offered load (phits/cycle/node)150 0.2 0.4 0.6 0.8 1Offered load (phits/cycle/node)Throughput (phits/cycle/node)uniform traffic 8x8 king torus2.521.510.500 0.5 1 1.5 2 2.5 3 3.5 4Offered load (phits/cycle/node)Throughput (phits/cycle/node)complement traffic 8x8 king torus0.90.80.70.60.50.40.3ROUTINGKnaive0.2 Kmissugal0.1KBugal00 0.5 1 1.5 2 2.5 3 3.5 4Offered load (phits/cycle/node)Throughput (phits/cycle/node)butterfly traffic 8x8 king torus10.90.80.70.60.50.40.30.20.100 0.5 1 1.5 2 2.5 3 3.5 4Offered load (phits/cycle/node)Fig. 5.Throughput and latency of routings on 8 × 8 king tori under different traffic patterns.channels together for each profitable physical channel.The reason behind this is fairly simple. Consideringthat all virtual channels share the same physicalchannel, the latency is determined by the occupationof all virtual channels, not only the one it isinjected in.IV. EvaluationIn this section we present the experimental evaluationcarried out to verify the better performanceand scalability of the proposed networks. This isdone by comparing with other networks usually consideredfor future network-on-chip architectures, asare the mesh and torus with size 8 × 8. The samestudy was made with 16 × 16 networks, but due totheir similarity to 8 × 8 and lack of space, these resultsare not shown.All the experiments have been done on a functionalsimulator called fsin[17]. The router model is basedon the bubble adaptive router presented in [18] withtwo virtual channels. As we will be comparing networksof different degree, a constant buffer space willbe assigned to each router and will be divided amongall individual buffers. Another important factor inthe evaluation of networks are the traffic patterns.The evaluation has been performed with syntheticworkload using typical traffic patterns. Accordingto the effect on load balance, traffic patterns can beclassified into benign and adverse. The former naturallybalances the use of network resources, like uni-JP2011-455

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011form or local, while the latter introduces contentionand hotspots that reduce performance, as in complementor butterfly. Due to space limitations, only theresults for three traffic patterns are shown as theycan represent the behaviour observed on the rest.These are uniform, bit-complement and butterfly.Figure 4 shows the throughput and latency of kingnetworks using Knaive compared to those of 2d toriand meshes. It proves that the increased degree ofthe king networks outperforms their baseline counterpartsby more than a factor two. The averagelatency on zero load is reduced according to the averagedistance theoretical values. Packets are 16-phitlong, thus making the latency improvement less obviousin the graphs. Observe that king meshes havesignificantly better performance than 2d tori, bothin throughput and latency.Figure 5 presents an analysis of the different routingtechniques under the three traffic patterns andfor 8 × 8 king tori and meshes. Comparing the resultsof networks with different sizes highlights thatthe throughput per node is halved. This is due to thewell known fact that the number of nodes in squarenetworks grows quadratically with the side while thebisection bandwidth grows linearly.For benign traffic patterns, the best results aregiven by Knaive routing. However in adverse traffic,a sensible decrease in performance is observed,caused by the reduced path diversity. As mentionedin Section III this limitation is overcome by theKmiss routing. In fact this routing yields poor performanceunder benign traffic pattern but very goodunder the adverse ones.Our composite routing algorithm KBugal gives thebest average performance on all traffic patterns. Inthe benign situations the throughput is slightly lessthan Knaive. And under adverse traffic, performanceis similar to the Kmiss routing, being even better insome situations. The results show that KBugal givesbetter performance than its more generic predecessorUGAL. As can be seen, under benign traffic aimprovement of 15% is obtained and between 10%(complement) and 90% (butterfly).V. ConclusionIn this paper we have presented the foundations ofking networks. Their topological properties offer tantalisingpossibilities, positioning them as clear candidatesfor future network-on-chip systems. Noteworthyare king meshes, which have the implementationsimplicity and wire length of a mesh yet better performancethan 2d tori. In addition, we have presenteda series of routing techniques specific for kingnetworks, that are both adaptive and deadlock free,which allow to exploit their topological richness. Afirst performance evaluation of these algorithms undersynthetic traffic has been presented in which theirproperties are highlighted. Further study will be requiredto take full advantage of these novel topologiesthat promise higher throughput, smaller latency,trivial partitioning and high fault-tolerance.AcknowledgmentThis work has been funded by the Spanish Ministryof Education and Science (grant TIN2007-68023-C02-01, Consolider CSD2007-00050) and bythe HiPEAC European Network of Excellence.References[1] J. Kim, W.J. Dally, S. Scott, and D. Abts, “Technologydriven,highly-scalable dragonfly topology,” SIGARCHComput. Archit. News, vol. 36, no. 3, pp. 77–88, 2008.[2] S. Scott, D. Abts, J. Kim, and W.J. Dally, “The blackwidowhigh-radix clos network,” SIGARCH Comput. Archit.News, vol. 34, no. 2, pp. 16–28, 2006.[3] J. Kim, J. Balfour, and W. Dally, “Flattened butterflytopology for on-chip networks,” in MICRO 07: Proceedingsof the 40th Annual IEEE/ACM International Symposiumon Microarchitecture, Washington, DC, USA,2007, pp. 172–182, IEEE Computer Society.[4] D. Wentzlaff, P. Griffin, H. Hoffmann, L. Bao, B. Edwards,C. Ramey, M. Mattina, C.-C. Miao, J.F.B. III,and A. Agarwal, “On-chip interconnection architectureof the tile processor,” IEEE Micro, vol. 27, pp. 15–31,2007.[5] S.R. Vangal, J. Howard, G. Ruhl, S. Dighe, H. Wilson,J. Tschanz, D. Finan, A. Singh, T. Jacob, S. Jain,V. Erraguntla, C. Roberts, Y. Hoskote, N. Borkar, andS. Borkar, “An 80-tile sub-100-w teraflops processor in65-nm cmos,” Solid-State Circuits, IEEE Journal of, vol.43, no. 1, pp. 29–41, 2008.[6] M. Igarashi, T. Mitsuhashi, A. Le, S. Kazi, Y.T. Lin,A. Fujimura, and S. Teig, “A diagonal interconnect architectureand its application to risc core design,” IEICTechnical Report (Institute of Electronics, Informationand Communication Engineers), vol. 102, no. 72, pp. 19–23, 2002.[7] A. Marshall, T. Stansfield, I. Kostarnov, J. Vuillemin,and B. Hutchings, “A reconfigurable arithmetic array formultimedia applications,” in FPGA 99: Proceedings ofthe 1999 ACM/SIGDA seventh international symposiumon Field programmable gate arrays, New York, NY, USA,1999, pp. 135–143, Acm.[8] K.W. Tang and S.A. Padubidri, “Diagonal and toroidalmesh networks,” Computers, IEEE Transactions on, vol.43, no. 7, pp. 815–826, 1994.[9] K.G. Shin and G. Dykema, “A distributed i/o architecturefor harts,” in Computer Architecture, 1990. Proceedings.,17th Annual International Symposium on, 1990,pp. 332–342.[10] WH Hu, SE Lee, and N. Bagherzadeh, “Dmesh: adiagonally-linked mesh network-on-chip architecture,”nocarc, 2008.[11] I.S. Honkala and T. Laihonen, “Codes for identificationin the king lattice,” Graphs and Combinatorics, vol. 19,no. 4, pp. 505–516, 2003.[12] J.M. Camara, M. Moreto, E. Vallejo, R. Beivide,J. Miguel-Alonso, C. Martinez, and J. Navaridas,“Twisted torus topologies for enhanced interconnectionnetworks,” IEEE Transactions on Parallel and DistributedSystems, vol. 99, no. PrePrints, 2010.[13] W. Dally and B. Towles, Principles and Practices ofInterconnection Networks, Morgan Kaufmann PublishersInc., San Francisco, CA, USA, 2003.[14] C. Martinez, E. Stafford, R. Beivide, C. Camarero,F. Vallejo, and E. Gabidulin, “Graph-based metrics overqam constellations,” Information Theory, 2008. ISIT2008. IEEE International Symposium on, pp. 2494–2498,2008.[15] A. Singh, Load-Balanced Routing in InterconnectionNetworks, Ph.D. thesis, 2005.[16] L.G. Valiant, “A scheme for fast parallel communication,”SIAM Journal on Computing, vol. 11, no. 2, pp.350–361, 1982.[17] FJ Ridruejo Perez and J. Miguel-Alonso, “Insee: Aninterconnection network simulation and evaluation environment,”2005.[18] V. Puente, C. Izu, R. Beivide, JA Gregorio, F. Vallejo,and JM Prellezo, “The adaptive bubble router,” J. ParallelDistrib. Comput., vol. 61, no. 9, pp. 1180–1208, 2001.JP2011-456

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Sistemas Web e InternetJP2011-457

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-458

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Incorporación del dinamismo del usuario en unbenchmark de comercio electrónico 1Raúl Peña-Ortiz, José Antonio Gil, Julio Sahuquillo, Ana Pont 2Departament d’ Informàtica de Sistemes i Computadors (DISCA), Universitat Politècnicade València,Valencia, SpainResumen— En los últimos años venimos asistiendoa un aumento en la cantidad de servicios ofrecidos através de la World Wide Web (Web). Estos servicioshan ido evolucionando paulatinamente, desde losprimitivos servicios estáticos de primera generación,hasta las complejas y personalizadas aplicaciones webactuales, en las que el usuario es algo más que unmero espectador y se ha convertido en un creadorde contenido dinámico. Esta evolución ha producidoa su vez una evolución en las pautas de comportamientode estos usuarios, que resultan cada vez másdinámicas. Consecuencia directa de la evolución de laWeb es la necesidad de nuevas herramientas para unaevaluación de prestaciones más acorde con las característicasdinámicas de la misma; herramientas quedeben ser capaces de representar el comportamientodinámico del usuario en la generación de la carga web.Este trabajo presenta un nuevo entorno de pruebacapaz de incorporar generación de carga dinámica enla evaluación de prestaciones de sistemas de comercioelectrónico basados en web. Con tal fin, se ha partidodel reconocido benchmark de comercio electrónicoTPC-W y se ha integrado la generación de cargadinámica proporcionada por el generador GUER-NICA, aprovechando sus cualidades a la hora de caracterizary reproducir carga web basada en los patronesdinámicos del comportamiento del usuario.El nuevo entorno ha sido validado contra TPC-W,mostrando resultados similares cuando no se consideradinamismo en la caracterización de la carga.Palabras clave— Evaluación de prestaciones web,generador de carga web, carga web dinámica, modeladodel comportamiento dinámico del usuario.I. IntroducciónLos servicios ofertados a través de la World WideWeb (Web) han sufrido una constante evolución enlos últimos años debido a los incesantes cambios dela tecnología web, lo que ha propiciado la apariciónde nuevos tipos de comportamiento en los usuariosde la Web [1].En los primitivos servicios estáticos de la primerageneración, la Web suponía un medio de bajo costepara compartir información de escasa o nula privacidad,y la información era principalmente de tipotexto, con un pequeño porcentaje de imágenes embebidas.El usuario tipo de esta Web era un meroespectador que se limitaba a consultar informacióny navegar de acuerdo a los enlaces que encontrabaen las páginas visitadas [2]. Posteriormente, los contenidosdinámicos alcanzaron gran auge, dando lugara la segunda generación de servicios basados en web.1 Este trabajo ha sido parcialmente financiado por el Ministeriode Ciencia e Innovación en el proyecto TIN2009-08201.2 Emails: rpenya@upvnet.upv.es, jagil@disca.upv.es,jsahuqui@disca.upv.es, apont@disca.upv.esEsta generación se caracterizó por fuertes cambiosen sus infraestructuras y arquitecturas (p.e., nuevossistemas de información basados en web, soportadospor servidores de aplicaciones y bases de datos) quepermitieron la generación, interrogación y almacenamientodinámicos de información; dinamismo quese extendió al comportamiento del usuario [3], a suspautas de navegación (más dinámicas y personalizadas),y por lo tanto al tráfico generado por lasmismas [4]. En la actualidad, nos encontramos conuna nueva oferta servicios donde el usuario ha dejadode ser únicamente consumidor de información,para pasar a participar activamente en la creaciónde contenidos personalizados y en la difusión o recomendaciónde los mismos [2].Como todo sistema en continuo cambio, tanto ensus aplicaciones como en las infraestructuras que lassustentan, los estudios de evaluación de prestacionesson pieza clave para presentar propuestas apropiadascuando se diseñan nuevos sistemas web [5] (p.e., serviciosweb, servidores web, proxies o políticas de distribuciónde contenidos). Todo proceso de evaluaciónde prestaciones debe emplear modelos de carga precisosy representativos para garantizar la validez delos resultados. En el caso de la Web, el dinamismoimplícito en el comportamiento de sus usuarios dificultael diseño de modelos capaces de representar lasnavegaciones reales.En trabajos previos [6] introdujimos un nuevomodelo para caracterizar carga web dinámica, denominadoDweb. Este modelo está basado en el comportamientodinámico del usuario y permite representarsu capacidad para cambiar su comportamientoa lo largo del tiempo, adoptando dinámicamentediferentes roles (p.e., surfer, buscador o comprador)y por lo tanto navegando la Web de diferentes maneras.El generador de carga GUERNICA fue implementandotomando como base Dweb.En el presente trabajo proponemos un nuevobenchmark web con capacidad para generar cargadinámica. Este nuevo entorno toma como base elreconocido benchmark TPC-W en el que se ha integradoel proceso de generación de carga de GUER-NICA, con el fin de dotarle de la capacidad de caracterizary generar carga web dinámica a través deDweb.El resto del artículo se estructura como sigue. Lasección II discute las razones que nos han llevadoa realizar esta nueva propuesta de benchmark web.Las secciones III y IV presentan y validan nuestraJP2011-459

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011propuesta, respectivamente. Finalmente, exponemosalgunas conclusiones finales y trabajo futuro en lasección V.II. Motivación y trabajo relacionadoLa necesidad de modelos de carga basados en elcomportamiento del usuario [7] aparece con la crecienteimportancia de las aplicaciones web. Estanecesidad es especialmente relevante en los entornosde comercio electrónico, donde la caracterizacióndel comportamiento del usuario no es sólo objetivode la evaluación de prestaciones web, sino quetambién juega un importante papel en términos defidelización de clientes. En este tipo de aplicacionesse pone de manifiesto, entre otras, las siguientes características:i) importancia de la información crítica;ii) elevado porcentaje de contenido dinámico y personalizado;iii) necesidad en la calidad del servicioy calidad del producto que se ofrece a los usuariosque son tratados como clientes potenciales; y iv) incorporaciónde tecnología de última generación. Enconsecuencia, la utilización de modelos imprecisos enla evaluación de aplicaciones de comercio electrónicopuede derivar en conclusiones incorrectas que suponganacciones inapropiadas sobre las prestaciones delsistema y sobre el desarrollo de negocio.Floyd et al. [8] describen los inconvenientes deevaluar las prestaciones web mediante modelos decarga analíticos, debido principalmente al componentedinámico de la carga y a la gran diversidad deparámetros que influyen en la caracterización de losmodelos analíticos (e.g., diferentes protocolos, tiposcaracterísticos de tráfico, patrones de navegación enlos usuarios, etc). En general, los retos actuales en lacaracterización de la carga web son: i) el modeladodel comportamiento dinámico del usuario [7], ii) ladefinición de los roles que el usuario juega cuandonavega la web [9] y iii) la representación de los continuoscambios de rol [10].Existen pocos aunque interesantes esfuerzos paradefinir el comportamiento del usuario con el fin decaracterizar carga web representativa de cierto tipode aplicaciones. Menascé et al. [11] introdujeron elCustomer Behavior Model Graph (CBMG) que describepatrones de comportamiento del usuario en lacarga relativa a aplicaciones de comercio electrónico.Duarte et al. [12] aplicaron este modelo para definirla carga de la blogsfera; Shams et al. [13] extendieronCBMG para reflejar las dependecias existentes entrelas peticiones HTTP de una navegación y entre losdatos relativos al contexto de la misma. Benevenutoet al. [14] introdujeron el modelo Clickstream paracaracterizar el comportamiento del usuario en las redessociales. Sin embargo, estos modelos sólo caracterizanla carga web en paradigmas o aplicacionesde propósito específico, y no abordan el segundo ytercero de los retos mencionados anteriormente. Estasdeficiencias nos motivaron a proponer un modelode carga de propósito general denominado Dweb[6], que nos permite considerar modelos del comportamientodinámico del usuario en la caracterizaciónde la carga. Dweb representa el dinamismodel usuario de forma precisa teniendo en cuenta lostres retos mencionados.Los estudios de evaluación de prestaciones web sonsoportados por software dedicado, que tiene el objetivode validar la calidad de servicio de un sistemabajo condiciones de carga específicas definidas normalmentepor modelos de carga. Existen varios tiposde software dedicado a la evaluación de prestaciones,de entre los cuales podemos destacar los benchmarksy los generadores de carga. Los primeros persiguenreproducir las condiciones de carga típicas del entornode trabajo habitual, con el fin de constatar siel sistema evaluado cumple con las pautas de calidadestablecidas. Los segundos buscan la generación deun número de peticiones HTTP lo suficientementeimportante como para conseguir una degradaciónsignificativa de la calidad del servicio, que podría llegara la denegación del mismo. De entre todas lasherramientas software evaluadas en un trabajo previo[15], el benchmark TPC-W es el mejor entornode pruebas representativo de un sistema de comercioelectrónico, mientras que GUERNICA es el únicogenerador que reproduce de forma precisa la cargaweb dinámica, a través del uso que hace de Dweb.TPC-W reproduce múltiples sesiones concurrentesde clientes sobre una librería on-line, pero no generacarga dinámica precisa porque sólo incluye unarepresetación parcial del comportamiento dinámicodel usuario basada en el uso del modelo CBMG.En consecuencia, en el presente trabajo proponemosun nuevo benchmark para entornos de comercioelectrónico con capacidad para caracterizar ygenerar carga web dinámica. Este benchmark sediseña como una extensión de TPC-W en cuya arquitecturase introduce la generación de carga dinámicabasada en Dweb mediante la integración del núcleode GUERNICA.III. Integración TPC-W y GUERNICAEl desarrollo del benchmark ideado se ha realizadode acuerdo a tres premisas. En primer lugar,el benchmark debe definir y reproducir de formaapropiada y precisa la carga dinámica. En segundolugar, debemos obtener un entorno que facilite lasmedidas de aquellas métricas de rendimiento, tantoen la parte cliente como en la parte servidor, imprescindiblesen los estudios de evaluación de prestacionescuando contemplamos diferentes cargas web.Finalmente, el benchmark debe proporcionar un entornorepresentativo de los sistemas web transaccionalesque se han establecido en los últimos años.De entre todas las alternativas de generación decarga web evaluadas en trabajos anteriores [15],TPC-W es el único benchmark que se ciñe a lamayoría de las premisas anteriores, pero aunque contemplael comportamiento dinámico del usuario en lacaracterización de la carga, no lo hace de forma precisa.Consecuentemente, proponemos una extensiónde TPC-W en la que se contempla el uso de GUER-NICA para generar carga web dinámica de formaJP2011-460

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011apropiada, lo que nos permite cumplir con las trespremisas.La sección III-A presenta las principales característicasde TPC-W y de la implementación seleccionadacomo base de nuestro desarrollo. Posteriormente,presentamos las principales funcionalidadesde GUERNICA y su arquitectura básica en la secciónIII-B. Finalmente, la sección III-C introduce la arquitecturade integración entre TPC-W y GUER-NICA que nos habilita a contemplar de forma apropiaday precisa carga dinámica en los estudios en losque emplear el benchmark.A. TPC Benchmark TM WTPC Benchmark TM W (TPC-W) es un benchmarkde web transaccional que simula las principalesactividades de un sitio web de comercioelectrónico, concretamente de una tienda de libroson-line [16]. El benchmark reproduce la carga generadapor múltiples sesiones concurrentes de clientessobre una aplicación web que se encarga de servirlos contenidos estáticos y dinámicos asociados a lasactividades de consulta y venta de la tienda.TPC-W proporciona un entorno estándar, independientede la tecnología de implementación, de laarquitectura y de la infraestructura, que ha sido altamentecontrastado y aceptado por la comunidadcientífico-técnica en numerosos estudios de evaluaciónde prestaciones web [17], [18], [19]. Comotodo benchmark de comercio electrónico, TPC-Wpresenta una arquitectura cliente-servidor, recogidaen la Figura 1. Los agentes software ubicados en laparte cliente (Remote Browser Emulators) son los encargadosde generar carga sobre la aplicación de comercioelectrónico del servidor (E-commerce server).Con el fin de reproducir una carga web representativa,los agentes simulan el comportamiento que deberíatener un usuario real al navegar por el sitioweb. El servidor alberga el sistema bajo prueba(Server Under Test), que se compone de: i) un servidorweb y su sistema de almacenamiento de objetosestáticos, y ii) un servidor de aplicaciones y una basede datos para la generación de contenido dinámico.La pasarela de pagos (Payment Gateway Emulator)representa la entidad encargada de autenticar a losusuarios y autorizar sus pagos. Los tres componentesprincipales de la arquitectura comunican entre sí através de una red de interconexión dedicada.Para nuestros propósitos, adoptamos una implementaciónJava de TPC-W realizada por el ComputerArchitecture Group de la UW-Madison [20].Como muestra la Figura 2, la parte cliente de suarquitectura está concebida como una aplicación deconsola y proporciona dos interfaces relacionadas conel proceso de generación de carga: i) el agente softwareencargado de simular a los clientes (EB), y ii)la factoría de agentes (EBFactory), cuya función esla de crear y configurar los agentes proporcionados.Estas interfaces actúan como punto de extensión ypermiten personalizar la caracterización de la cargaweb. La parte del servidor se ha desarrollado comoFig. 1.Arquitectura TPC-WFig. 2. Componentes principales en la implementación Javade TPC-Wuna aplicación web compuesta por un cojunto deServlets que se encargan de recoger las peticionesde los clientes y acceder a la base de datos para poderservirlas.B. GUERNICAGUERNICA (Universal Generator of DynamicWorkload under WWW Platforms) es un softwaregenerador de carga web resultado de la cooperacióndel Grupo de Investigación en Arquitectura y Prestacionesde la Web de la Universitat Politècnica deValència y la empresa Intelligent Software Components.La principal característica de GUERNICA es eluso que hace de los conceptos del modelo Dweb (Dy-Fig. 3.Principales componentes en GUERNICAJP2011-461

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011namic web workload model) [6] a la hora de definirel comportamiento del usuario, lo que le permite resolvercompletamente los tres retos planteados en lacaracterización de la carga dinámica. El conceptode navegación define el comportamiento del usuariomientras interactúa con la web y facilita la caracterizacióndel dinamismo del usuario en sus navegaciones.Por otro lado el concepto de test de cargase asocia a un conjunto de navegaciones que definenlos posibles comportamientos de un usuario y proporcionaun mecanismo para modelar estos comportamientosy los posibles cambios contemplados.GUERNICA se presenta como un conjunto de tresaplicaciones principales: generador de carga (workloadgenerator client), evaluador de rendimiento(performance evaluator client) y planificador de lostest de prestaciones (performance tests planner),que permiten independizar y distribuir en diferentesnodos las principales actividades de los procesosde evaluación de prestaciones y evaluación funcionalde una aplicación web. Estas tres aplicacionesse definen dentro de una arquitectura basadaen componentes, recogida en la Figura 3. El elementocentral de la arquitectura, GUERNICA.core,es el encargado de implementar el proceso de generaciónde carga basado en Dweb. Los conceptosde test de carga y navegación están representadosrespectivamente por las interfaces WorkloadTesty WorkloadNavigation. El componente encargadode simular el comportamiento de los usuariosrecibe el nombre de NavigationEngine; su configuraciónse expresa en términos de los conceptosde Dweb y se almacena en un repositorio de nombreWorkloadTestRespository. El acceso centralizadoa GUERNICA.core se lleva a cabo a través delCoreManager.C. Arquitectura de integraciónLa arquitectura de integración entre TPC-W yGUERNICA (TGI) se recoge en la Figura 4. Dichaarquitectura se organiza en tres capas. La capa superiorestá definida por la parte cliente de TPC-W,que proporciona las dos interfaces principales del procesode generación de carga (EB y EBFactory), detalladasen secciones previas. La capa inferior estárelacionada con el proceso de generación de cargaen GUERNICA, introducido en la sección anterior.Finalmente, la capa intermedia define la integraciónentre TPC-W y GUERNICA, la cual es suministradacomo una librería Java independiente de TPC-W yde nombre TGI. Esta librería implementa un nuevotipo de agente generador de carga (i.e., DwebEB)que usa el núcleo de GUERNICA para reproducir elcomportamiento dinámico de los usuarios en el procesode generación de carga. A fin de simplificarla implementación de este agente, un nuevo motorde carga (i.e., DwebExecutorEngine) ha sido implementadopara llevar a cabo el proceso de generación.Adicionalmente, una nueva factoría de agentes (i.e.,DwebEBFactory) se ha desarrollado para controlar laconfiguración, creación y gestión de las instancias delnuevo agente en el entorno de TPC-W.Fig. 4.Arquitectura de TGIIV. Validación de TGIPara poder explotar con garantías en trabajos futurosel nuevo benchmark, lo hemos validado contraTPC-W, considerando una configuración específicade entorno experimental para la cual se han medidosus principales métricas de rendimiento. Las SeccionesIV-A y IV-B describen el entorno experimentaly las métricas de rendimiento, respectivamente.La validación se detalla en la Sección IV-C.A. Entorno experimentalLa configuración utilizada en el entorno experimentalpara llevar a cabo la validación, sigue las pautasde una arquitectura tradicional cliente-servidor,que en nuestro caso consiste en un Servidor UbuntuLinux como back-end y un Cliente Ubuntu Linuxcomo capa de front-end. El back-end ejecuta la aplicaciónservidor de TPC-W, cuya base es una aplicaciónweb Java (TPC-W web app) que está desplegadaen el servidor de aplicaciones Tomcat. Las peticionesa contenido estático, es decir las imágenes, sonservidas directamente por el servidor web Apache.Las peticiones a contenido dinámico son redirigidasa Tomcat. La aplicación web se encarga de servir estaspeticiones dinámicas accediendo a la informaciónalbergada en la base de datos MySQL. Por otro lado,en el front-end se ejecuta la aplicación del benchmarkasociada a la generación de carga. Tanto laaplicación de back-end como la de front-end se ejecutansobre el entorno Java SUN 5.0 (JRE 5.0). LaFigura 5 ilustra el entorno experimental y detalla elhardware y software empleados.Dada la arquitectura en capas del entorno experimental,el ajuste de los diferentes parámetros delsistema, tanto del servidor como de los generadoresde carga, ha supuesto un punto fundamental paragarantizar que los posibles cuellos de botella de la infraestructuraempleada no distorsionan la validaciónJP2011-462

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 5.Entorno experimentalrealizada. Se ha empleado una configuración deTPC-W que contempla gran cantidad de artículos yclientes potenciales, concretamente 100.000 artículosy hasta 100 clientes potenciales registrados al seguirlas reglas de escalabilidad del benchmark. Estascondiciones experimentales nos han obligado a revisarel ajuste del acceso a la base de datos (p.e., eltamaño del pool de conexiones), del servicio de contenidoestático por parte de Apache (p.e., el númerode workers que sirven peticiones HTTP), o del serviciode contenido dinámico por parte de Tomcat(p.e., el número de hilos para proporcionar contenidodinámico). En la validación del entorno, para cadatipo de carga de trabajo hemos realizado medidasde las métricas de rendimiento durante varias repeticionesde los experimentos, con el fin de recopilarsus valores de una manera precisa y representativa.Cada una de estas ejecuciones se compone de unafase de calentamiento de 15 minutos seguida de unafase de medición de 30 minutos.B. Métricas de rendimientoLa Tabla I resume aquellas métricas derendimiento medidas en nuestro estudio. Lasprincipales métricas consideradas desde el punto devista del cliente son el tiempo de respuesta (WIRT)y el total de peticiones por página. En el servidor,nuestro estudio recoge las estadísticas del servidorque son requeridas por la especificación de TPC-W(p.e., utilización de la CPU, actividad de la E/S de labase de datos, actividad de la E/S del sistema o lasestadísticas el servidor web) y además añade otrasestadísticas opcionales. Las métricas recogidas seorganizan en dos grupos de acuerdo a su naturaleza:i) métricas de los principales recursos hardwaredel sistema, y ii) detalles del rendimiento de losprincipales componentes software del back-end. Conel fin de estandarizar el proceso de evaluación deprestaciones empleamos un middleware llamadocollectd 1 que nos permite realizar una medidaperiódica.C. Resultados experimentalesLa validación del benchmark, requerida previamentea su explotación con garantías en estudiosde evaluación de prestaciones, se ha realizado con-1 http://collectd.org/tra TPC-W con el fin de contrastar las principalesfuncionalidades y comportamiento de ambas implementaciones.Con este fin, identificamos un sitio webde validación a partir del mapa web de la librería onlineasociada a TPC-W.Según la especificación de TPC-W, el CBMG completopara la librería on-line se compone de 14páginas únicas y de la probabilidad de transición entreellas. Existen tres tipos de escenarios posibles:shopping, browsing, y ordering. Para ilustrar el procesode validación de nuestro benchmark, hemos seleccionadoel escenario browsing que se compone deuna actividad de navegación muy significativa frentea la escasa actividad asociada a la compra de libros(ordering). Basado en este escenario, el sitio webde validación se reduce a las páginas del proceso debúsqueda (i.e., Home, Search request, Search resulty Product detail page) y las transiciones entre ellas.La Figura 6 detalla el CBMG simplificado parael sitio web de validación, mostrando las diferentespáginas del proceso de búsqueda (Home, Search request,Search result y Product detail page) entre lasque pueden transitar los usuarios, y las transicionespermitidas por los arcos del grafo. Los números sobrelos arcos indican la probabilidad de transiciónentre las dos páginas conectadas. Así por ejemplo,la probabilidad de ir a la Product detail page desdela página Search results es del 0.6195. El significadode esta probabilidad hace referencia a que despuésde una búsqueda, sin tener en cuenta si la misma hadevuelto resultados o no, la Product detail page esvisitada en el 61.95% de los casos. El libro a cuyodetalle se accede será un resultado de la búsqueda ouno de los libros miembros del banner de novedadesincluido en la mayoría de páginas de la librería. Estasprobabilidades han sido inferidas a partir de losumbrales definidos por la especificación de TPC-Wpara el escenario browsing. Destacamos que hemosmodelado el mismo tipo de carga usando únicamenteel concepto de navegación de Dweb y desactivandoel resto de parámetros del modelo que nos permitencaracterizar el dinamismo.En las pruebas de validación, hemos contrastadoestas dos aproximaciones de caracterización de carga.Únicamente se consideran 50 agentes en la generaciónde carga debido a que la implementaciónJava de TPC-W adoptada presenta algunas limitacionesen el proceso de generación, que le impidenJP2011-463

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IMétricas de rendimientoRecurso Métrica DescripciónClienteWIRTReqpageW IRT W IRT =Web Interaction Response Time (WIRT) se define en TPC-W como t2 − t1, dondet1 es el tiempo medido en el agente generador de carga antes de enviar al servidorel primer byte de la primera petición HTTP en la interacción web, y t2 es eltiempo medido en el agente generador de carga después de recibir el último bytede la respuesta a la última petición HTTP que completa la interacción web con elservidor.Requests per Page (Reqpage) es el número total de peticiones por página que sonservidas con éxito.∑∑i∈P ages W IRT i ∗Req i.i∈P ages Req iServidorLas métricas para los principales recursos hardware incluyen la utilización paraHardware Memoria UmemoryCPU U CP UDiscoU disk , X disktodos ellos, y la productividad para el disco y la red de interconexión.Red InterconexiónU net , X netApache {X, CP U, MEM} apache Los detalles de rendimiento de los principales componentes software del servidorSoftware Tomcat {X, CP U, MEM} tomcatincluyen: productividad, uso de la memoria y de la CPU por parte del componente,procesos o hilos de ejecución del componente, etc.MySQL{X, CP U, MEM} mysql1.0 Home1.0 Product detail 1.00.36750.6195 Searchrequest0.013 SearchresultsFig. 6. Caracterización de la carga de trabajo en la validacióngenerar más carga de forma efectiva aunque consideremosmás de 50 agentes. Las medidas han sido realizadasdurante 50 ejecuciones con el fin de obtenerresultados apropiados con un nivel de confianza del99%.Las Figuras 7 y 8 muestran los resultados más significativos,de entre todas las métricas medidas en losexperimentos, para las cargas definidas con CBMGy Dweb.Ambas cargas generan un número similar de peticionesa página, como muestra la Figura 7(a). Concretamente,la carga modelada por Dweb produce un1% menos de peticiones que la carga definida porCBMG, pero esta diferencia no influye en el tiempode respuesta, que es virtualmente el mismo en amboscasos, tal y como muestra la Figura 7(b).Por otro lado, el servidor se caracteriza por un pobrenivel de estrés, representado por una baja utilizaciónde los principales recursos hardware. LaFigura 8(a) denota un bajo nivel de utilización dela CPU y la memoria en ambos casos. El tráficoentrante y saliente no provoca más de un 3% de utilizaciónde la red para ambas cargas, como ilustra laFigura 8(b). Por otra parte, la utilización del discoes demasiado pequeña (inferior al 0.5%) para ser representadagráficamente en ambos casos.Los resultados de las pruebas de validaciónnos permiten demostrar que Dweb y GUERNICApueden ser empleados en los estudios de evaluaciónde prestaciones como alternativa a los modelos decarga tradicionales.1.0V. ConclusionesLa evolución de la World Wide Web, desde losprimitivos servicios estáticos de la primera generaciónhasta las complejas y personalizadas aplicacionesweb actuales, es motivo de otra evolución,la de las pautas de comportamiento de sus usuarios.Usuarios que han dejado de comportarse comomeros cosumidores de información y han pasado aparticipar activamente en la creación y difusión decontenidos web dinámicos. Consecuentemente, losusuarios actuales se caracterizan por un comportamientomás dinámico que debe ser contempladoen los modelos de caracterización de carga y en lasherramientas que los utilizan para la evaluación deprestaciones web.En trabajos previos [6] introducimos un nuevomodelo, denominado Dweb, para caracterizar cargaweb dinámica de una forma más precisa, e implementamosel generador de carga GUERNICA en base adicho modelo.El presente trabajo introduce un nuevo entornode prueba capaz de incorporar generación de cargadinámica en la evaluación de prestaciones de sistemasde comercio electrónico basados en web. Con talfin, se ha partido del reconocido benchmark de comercioelectrónico TPC-W y se ha integrado la generaciónde carga dinámica proporcionada por Dweby GUERNICA. El nuevo entorno ha sido validadocontra el propio TPC-W.Como trabajo futuro pensamos demostrar quenuestro modelo de carga es una alternativa másvaliosa porque es capaz de reproducir el comportamientodinámico del usuario en la caracterizaciónde la carga web. Con tal fin, debemos cuantificarel efecto de usar carga dinámica en los estudios deevaluación de prestaciones web.JP2011-464

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Peticiones a página de usuario(b) WIRTFig. 7.Métricas desde el punto de vista del cliente(a) Utilización de la CPU y la memoria(b) Utilización de la red de interconexiónFig. 8.Métricas desde el punto de vista del servidorReferencias[1] P. Rodriguez, “Web Infrastructure for the 21st Century”,WWW, 2009.[2] G. Cormode and B. Krishnamurthy, “Key differences betweenWeb 1.0 and Web 2.0”, First Monday Journal, 2008.[3] T. O’Reilly, “What is Web 2.0. Design Patterns and BusinessModels for the Next Generation of Software”, 2005.[4] G. Abdulla, Analysis and Modeling of World Wide WebTraffic, Ph.D. thesis, May 1998.[5] P. Barford and M. Crovella, “Generating representative webworkloads for network and server performance evaluation”,SIGMETRICS, 1998.[6] R. Peña-Ortiz, J. Sahuquillo, A. Pont, and J.A. Gil Salinas,“Dweb model: representing Web 2.0 dynamism”, ComputerCommunications Journal, 2009.[7] P. Barford, A. Bestavros, A. Bradley, and M. Crovella,“Changes in Web client access patterns: Characteristics andcaching implications”, WWW, 1999.[8] S. Floyd and V. Paxson, “Difficulties in simulating the Internet,”IEEE/ACM Transactions on Networking, 2001.[9] H. Weinreich, H. Obendorf, E. Herder, and M. Mayer, “Offthe beaten tracks: exploring three aspects of web navigation”,WWW, 2006.[10] S. Goel, A. Broder, E. Gabrilovich, and B. Pang, “Anatomyof the long tail: ordinary people with extraordinary tastes”,SDM, 2010.[11] D.A. Menascé and V.A.F Almeida, Scaling for E-Business:Technologies, Models, Performance, and Capacity Planning,2000.[12] F. Duarte, B. Mattos, J. Almeida, V.A.F Almeida, M. Curiel,and A. Bestavros, “Hierarchical characterization and generationof blogosphere workloads”, Tech. Rep.,2008.[13] M. Shams, D. Krishnamurthy Ph.D, and B. Far, “A modelbasedapproach for testing the performance of web applications”,SOQUA, 2006.[14] F. Benevenuto, T.R de Magalhães, M. Cha, and V.A.FAlmeida, “Characterizing user behavior in online social networks”,IMC, 2009.[15] R. Peña-Ortiz, J. Sahuquillo, J.A. Gil Salinas, and A. Pont,“WEB WORKLOAD GENERATORS: A survey focusing onuser dynamism representationa”, WEBIST, 2011.[16] “TPC BENCHMARK(TM) W Specification. Version 1.8”,Tech. Rep., 2002.[17] R.C. Dodge Jr, D.A. Menascé, and D. Barbará, “Testinge-commerce site scalability with TPC-W”, CMG, 2001.[18] C. Amza, A. Chanda, and A. Cox, “Specification and implementationof dynamic web site benchmarks”, IISWC, 2002.[19] D.F. García and J. García, “TPC-W e-commerce benchmarkevaluation”, Computer Journal, 2003.[20] H.W Cain, R. Rajwar, M. Marden, and M.H Lipasti, “Anarchitectural evaluation of Java TPC-W”, HPCA, 2001.JP2011-465

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-466

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Servicios Web Semánticos. Una aproximacióndesde las OntologíasIván López Rodríguez, 1 Esther González Rodríguez, 2 Elena Sánchez Nielsen 3Resumen— Debido al enorme crecimiento de contenidosque ha sufrido la Web en los últimos años,cada vez resulta más difícil encontrar una informaciónen concreto. Como solución ha surgido la WebSemántica, para permitir a las máquinas entendercómo se organiza la información contenida en la web.Idéntica ha sido la problemática del descubrimiento einvocación de los servicios web publicados. ¿Podríaaplicarse la semántica también al mundo de los serviciosweb? En este trabajo se hace un estudio de laviabilidad de este enfoque y cómo aplicarlo en un casode estudio concreto: “Turismo en la isla de Tenerife”.Palabras clave— Servicios Web, Semántica, Ontologías,WSDL, RDF, SPARQL.I. IntroducciónEn los últimos años, la Web ha crecido deforma exponencial en dimensión y capacidad.Paradójicamente, esta imparable evolución es, desdehace algún tiempo, uno de sus principales problemasa la hora de localizar una información concreta. Similarha sido la dinámica de los servicios web. Mientrasque las funcionalidades que ofrece la Web se hanvisto mejoradas considerablemente con el nacimientode esta tecnología, el gran número de servicios surgidosdio lugar a que su descubrimiento, invocación ycomposición, no resultara un proceso óptimo.Los servicios y sus proveedores se catalogan enrepositorios de forma análoga a como se organiza lainformación telefónica de empresas y particulares enlas páginas blancas y amarillas. Se pueden localizartodos los servicios de una compañía o buscar unoconcreto a partir de su nombre. Este sistema es muydeficiente de cara al usuario final, pues implica conocerla empresa o el nombre del servicio web, lo cualno es habitual, ya que el usuario busca por palabrasque describan la solución a su problema. Sin embargo,incluso conociendo dichos datos, los serviciosweb resultantes tras una búsqueda serían numerososy es el usuario quien debe determinar el servicio desu interés.La semántica aporta la solución organizativanecesaria para mejorar de forma considerable lasbúsquedas, ya que permite la interoperabilidad entresistemas informáticos reduciendo la mediación delusuario. Dentro del campo de los servicios web, estetrabajo propone algunas mejoras semánticas a travésdel uso de sinónimos y relaciones jerárquicas entreconceptos. El uso de sinónimos permite hallar unservicio usando diferentes palabras clave, ya que se1 D.E.I.O.C., Universidad de La Laguna, e-mail:ilopezro@ull.es.2 D.E.I.O.C., Universidad de La Laguna, e-mail:alu3179@etsii.ull.es.3 D.E.I.O.C., Universidad de La Laguna, e-mail:enielsen@ull.es.puede representar que el concepto “x”es equivalentea “y”(muy útil para incorporar soporte idiomático).Por otro lado, se pueden relacionar conceptos comunesa un dominio de forma jerárquica, lo cual esde gran utilidad para devolver resultados apropiadoscuando la búsqueda del usuario no proporcionaninguno o para ofrecer resultados alternativos. Asímismo, es posible alcanzar un nivel mayor de refinamientoen las búsquedas si se realizan uniones eintersecciones con los resultados de varios conceptos,ejecutando en una sola consulta sentencias complicadas.Esto evita que sea el usuario el que tenga quefiltrar de entre todos los resultados, aquellos que sonde su interés.Como se puede apreciar, la adición de semántica serevela como una poderosa herramienta que permiteal usuario final hacer un mejor uso de los serviciosweb anotados semánticamente. A lo largo de las siguientessecciones se explicará en más detalle cómolograrlo.Fig. 1: Web tradicional.Tras la introducción, el resto del trabajo se organizacomo sigue:1. Se hace un breve recorrido temporal relacionandola Web con los servicios web y explicandocomo, en ambos casos se ha optado porla semántica para continuar su desarrollo.2. El núcleo del trabajo comprende un casopráctico en el que se aborda la recopilación deun conjunto de servicios web relacionados conel sector servicios. Más concretamente, con elturismo en la isla de Tenerife.3. A continuación, se presentan las conclusionesque se pueden inferir sobre la adición desemántica a un campo en constante explotacióncomo son los servicios web.4. Por último, se comentan las principales líneasde trabajo abiertas.II. Estado del arteLos principales problemas actuales de la Web son:la sobrecarga de contenidos y la heterogeneidad deJP2011-467

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011las fuentes de información con el consiguiente problemade interoperabilidad. La Web Semántica[5]ayuda a resolver todos estos problemas permitiendoa los usuarios delegar tareas en el software. Graciasa la semántica de la Web, el software es capaz deprocesar su contenido, razonar con éste, combinarloy realizar deducciones lógicas para resolver problemascotidianos de interoperabilidad. Para entendercómo se ha llegado hasta aquí, se hace un breve resumende la situación actual de las partes implicadasen el presente trabajo:A. Servicios WebEn Internet, la arquitectura orientada a servicios,se concretó como servicios web. Éstos permiteninterconectar procesos, independientementedel lenguaje con el que fueron escritos o sobre laplataforma sobre la que se estén ejecutando.En general, estos servicios son accesibles a travésde su descripción sintáctica en WSDL (Web ServiceDescription Language), con la cual un usuario puedeconocer las funciones con las que cuenta el servicioweb; así como el número y tipo de parámetros, tantode entrada como de salida. En concreto, se definenlos tipos de los datos que se transmitirán en los mensajes(types), los propios mensajes (message), el ordende intercambio de dichos mensajes (portType)y, por último, una descripción más concreta de losportType (binding).Fig. 2: Web Semántica.Sin embargo, al igual que pasó con la Web, el crecientenúmero de servicios web que se publican dificultalas búsquedas óptimas. Por ello, se crearondirectorios UDDI (Universal Description Discoveryand Integration), estándares de información acercade los servicios web para permitir su descubrimiento,aunque resultan insuficientes.B. Web SemánticaHasta el momento, el concepto conocido de la Web,es el de un almacén ingente de información donde noexiste un formato común y sólo es inteligible paralas personas (ver figura 1). Es debido a estas limitacionesque evolutivamente surgió la Web Semántica.Por ello, todos los trabajos para la mejora de la Webestán orientados a convertir esa información (sólo accesiblea través de búsquedas por palabras clave) enconocimiento. Esto quiere decir que las aplicacionesy agentes software encontrarán el significado de losdatos gracias a la metainformación (ver figura 2).El concepto de Web Semántica se basa en quelas máquinas comprendan el significado de la informacióndisponible en ella. Puesto que es muydifícil dotar a las máquinas de inteligencia artificialcapaz de comprender el lenguaje de las personas,se ha optado porque sean éstas quienes representenlos datos en un lenguaje formal que permitaa los agentes inteligentes usar dicha informaciónpara extraer inferencias lógicas. Estos lenguajes sontambién conocidos como lenguajes de representacióndel conocimiento. Se expresan a través de las ontologías.C. OntologíasSon la herramienta que posibilita la representacióndel conocimiento. Es decir, permiten la definición deconceptos comunes para los desarrolladores que necesitancompartir información de un dominio específicoo área de conocimiento. Más concretamente, unaontología está compuesta por definiciones de conceptosbásicos y las relaciones existentes entre ellos, expresadasde forma que sean interpretables por lasmáquinas. Además, esto ofrece importantes ventajasa las personas, como son:• Compartir la forma de interpretar cierta informaciónentre personas y agentes software.• Reutilizar el conocimiento de un dominio.• Realizar inferencias a partir del conocimiento existentepara obtener nueva información.• Separar el conocimiento del dominio delconocimiento operacional.Para la representación del conocimiento, la WebSemántica utiliza RDF, SPARQL y OWL. Estosmecanismos ayudan a convertir la Web en una infraestructuraglobal en la que es posible compartir yreutilizar datos entre diferentes usuarios.• RDF (Resource Description Framework) proporcionainformación descriptiva simple sobre losrecursos que se encuentran en la Web y se utiliza,por ejemplo, en catálogos de libros, directorios,colecciones personales de música, fotos,eventos, etcétera.• SPARQL (SPARQL Protocol and RDF QueryLanguage) es un lenguaje de consulta sobreRDF, que permite hacer búsquedas sobre los recursosde la Web Semántica utilizando distintasfuentes datos. Tiene un comportamiento similara SQL pero, a la hora de trabajar con la información,lo hace a través de RDF. Por lo tanto,las consultas SPARQL acceden a la informaciónen el formato de tripleta establecido en RDF: sujeto,propiedad, valor; a diferencia de SQL quelo hace con tablas y columnas.• OWL es un mecanismo que extiende a RDF-S (RDF Schema) y se utiliza para desarrollartemas o vocabularios específicos en los que asociaresos recursos. Lo que hace OWL es proporcionarun lenguaje para definir ontologías estructuradasque puedan ser utilizadas a travésde diferentes sistemas. Las ontologías son uti-JP2011-468

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011lizadas por los usuarios, las bases de datos ylas aplicaciones que necesitan compartir informaciónespecífica perteneciente a un campo determinado,como puede ser el de las finanzas, lamedicina, el deporte, etcétera.D. Servicios Web SemánticosHasta ahora, los servicios web sólo se definían demanera sintáctica gracias al lenguaje ampliamenteutilizado WSDL. Éste permite que se enumerenlas funciones que componen el servicio, el númerode parámetros que recibe cada función y su tipo,pero resulta limitado ya que, la simple definiciónsintáctica no almacena información sobre el significadode dichas funciones: ¿qué hacen?, ¿para quésirven?. Por esa misma razón, realizar búsquedas deservicios web es una tarea ardua y no es posible queagentes software puedan, de forma autónoma, usarestos servicios. Para solucionar todos estos problemasse debe añadir una descripción de más alto nivelal servicio web, es decir, una descripción semántica.Existen dos alternativas para añadir metadatos alos servicios: los servicios que están expresadossemánticamente y los servicios que añaden anotacionessemánticas a las sintácticas. En estetrabajo se ha optado por seguir la segunda aproximación,utilizando las ontologías para realizar las anotacionessemánticas sobre las sintácticas (definiciónde los servicios web).Los servicios web enriquecidos con la semánticapermiten construir escenarios en los que se hace posible:• Descubrir servicios web automáticamente.• Invocar servicios web automáticamente.• Componer e interoperar con otros servicios webautomáticamente.• Monitorizar servicios web automáticamente.El trabajo desarrollado se centra en el primerpunto y, para ilustrar las posibilidades reales, se harealizado un caso práctico.III. Caso de Estudio: Provisión de ServiciosWeb Semánticos en el DominioTurísticoCon el fin de evaluar el rendimiento de las tecnologíassemánticas, se propone como caso de estudiocrear una herramienta para localizar serviciosturísticos localizados en el contexto geográfico de laisla de Tenerife (Tenerife e-Tourist MarketPlace). Enla figura 3 se puede ver una representación del problema.El objetivo final de este caso de estudio secentra en el proceso de catalogación y búsqueda deservicios web en el dominio propuesto. Con este fin,se evalúan y optimizan las búsquedas de serviciosmediante la incorporación de búsquedas semánticasen lugar de las tradicionales búsquedas por palabrasclaves.En el caso de estudio que se plantea, lametodología empleada para facilitar la búsqueda deservicios web relacionados con los servicios turísticos,Fig. 3: Modelo del caso de estudio.se basa en catalogar cada uno de los servicios web enla ontología. Por lo tanto, el primer paso consiste encrear una ontología que modele el abanico de categoríasque definen las posibles preferencias y opcionesde un turista. En la figura 4 se pueden ver algunasde las categorías creadas para ello. Las clases serelacionan jerárquicamente entre sí y, una vez modeladala ontología, es necesario anotar en la categoríacorrespondiente todos los servicios web ofrecidos alusuario final.La ontología desarrollada durante este trabajadoha sido modelada haciendo uso del software Protégé,un entorno de desarrollo de ontologías, de códigoabierto y libre distribución que permite editar ontologíasy bases de conocimiento que pueden ser exportadasa diferentes formatos, como son: OWL,RDF y XML Schema.Para realizar las búsquedas pertinentes en dichaontología, se puede almacenar en un fichero tipoOWL (adecuado para estructuras pequeñas). Sinembargo, es mucho más eficiente y robusto exportarlaa una base de datos con estructura tipo Jena.Jena es un framework creado para facilitar el desarrollode aplicaciones semánticas. Entre otras posibilidadespermite al programador interactuar con informaciónen formato RDF y realizar consultas enformato SPARQL como la que se presenta a continuación:String queryString = ”PREFIX tf: ”+ ”SELECT ?item ?name ” + ”WHERE ” + ”{ ”+ ”?item tf:Name ?name . ”+ ”FILTER regex(?name, ’” + wordIn + ”’, ’i’) . ”+ ”} ”;Listing 1: Consulta SPARQL.A. Algoritmo de búsqueda por nombreEl primer, y más simple, tipo de búsqueda consisteen introducir sólo palabras clave pero sin indicarninguna categoría de servicio. Se realiza entoncesuna búsqueda por nombres entre todos losítems almacenados en la base de datos. Es la opciónmás costosa computacionalmente. La relevancia deun servicio se calcula como el número de coincidenciasocurridas entre el nombre de dicho servicio y lasJP2011-469

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011palabras introducidas por el usuario.B. Algoritmo de búsqueda por claseEl segundo tipo de consulta es aquella en la queel usuario selecciona una o más clases pero no introduceninguna palabra clave. Por lo tanto, en el resultadoaparecerán todos los servicios que pertenezcana algunas de las clases seleccionadas. Sin embargo,hay que aclarar que las clases existentes relacionadascon las zonas geográficas (Norte, Sur, Metropolitanay todos sus descendientes) son tratadas de formadistinta. Esto es así para ajustar correctamente elnúmero de resultados devueltos tras una consulta,lo cual se ilustra con el siguiente ejemplo. Si elusuario introduce como términos de búsqueda “hotelesapartamentos”en los resultados deberían aparecertodos los servicios que pertenezcan a ambas clases.Es decir, la unión de ambos conjuntos. Pero si elusuario introduce “hoteles orotava”y se muestra launión de ambos conjuntos en la búsqueda aparecerían,además de todos los hoteles en La Orotava(el objetivo buscado), todos los servicios ubicados enLa Orotava: parques temáticos, gimnasios, museos...lo cual no sería el comportamiento esperado. Esto esasí porque, como existe una clase que hace referenciaa un denominador geográfico como es Orotava, sedebería de mostrar la intersección de ambos conjuntos.Este es el motivo porque el que se deben detratar de diferente forma los nombres de lugares opuntos cardinales.C. Algoritmo de búsqueda por clases y nombreEs una opción de búsqueda en la que el usuariopuede marcar una o varias clases así como introduciruna o varias palabras claves. El sistema buscará,de entre todos los servicios ofrecidos en cada clase,aquellos que coincidan con las palabras claves.Para la implementación se ha creado un métodoque se encarga de lanzar las sucesivas búsquedas delas palabras claves por todas las clases marcadas porel usuario en la interfaz gráfica y restringiendo losresultados por cada zona seleccionada.D. Algoritmo de búsqueda inteligenteEn este caso se implementan búsquedas idénticasa las anteriores pero sin que el usuario tenga queintroducir manualmente qué palabras indican clasesy cuáles nombres.El primer paso es filtrar la entrada proveniente delusuario eliminando palabras que no aportan informaciónsemántica, como los artículos, las preposiciones,las conjunciones, etc. Este procedimiento serealiza tanto para el idioma español como para elinglés.El siguiente problema a abordar es capturar elnombre de las clases a partir de la entrada delusuario. La dificultad estriba en que se puede definirel concepto de muy distintas maneras. Para hacerreferencia a la clase Hotel se puede escribir “Hotel”,“Hotels”o “Hoteles”. Todas estas palabras seleccionaránla clase “Hotels”en la búsqueda. Paralograr dicho efecto se almacena en la ontología unaserie de sinónimos (tanto en inglés como en español)para cada clase.Como ejemplo, si se introduce la búsqueda “palacehoteles en puerto”, el sistema sabrá que hay que buscarla palabra “palace”en los servicios que desciendande la clase “Hotels”y “Puerto de la Cruz”.Fig. 4: Ontología.Al trabajar con el buscador en el apartado debúsquedas sin asistencia, aparece un problema. Esimposible encontrar un servicio cuyo nombre ya existapara una clase. En caso de querer localizarun bar llamado “La Cruz”mediante la búsqueda “lacruz”el sistema eliminará la palabra “la”por superfluay cambiará “cruz”por la clase “Puerto de laCruz”. Para evitar este comportamiento que, aunquedeseable en la mayoría de los casos, se puede convertiren un impedimento, se ha introducido un carácterespecial:• El símbolo de cierre de exclamación (“!”) cuandoantecede a una palabra evita que ésta se transformeen una llamada de clase y quede comopalabra clave de búsqueda.Así, una búsqueda con el término “!cruz”arrojaráservicios cuyo nombre incluya esa palabra.Otro aspecto que se comprobó que se podía mejorarson los campos de búsqueda. Hasta ahora sebuscaba en el campo “Name”de los servicios. Estoes suficiente para la mayoría de las búsquedas. Perodado que en la ontología se puede almacenar muchamás información, como el número de estrellas de loshoteles, el precio medio por noche en un alojamiento,la dirección del archivo WSDL, etcétera, sería un errorno refinar las búsquedas usando estos campos.Para lograr búsquedas más eficientes se incluyóotro carácter especial: el signo de cierre de interrogación(“?”). De esta forma, el siguiente ejemplode búsqueda introducida por un usuario “hotelpuerto ?category>=3 ?pricepernight

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011probando cada resultado buscando los hoteles quecumplieran con sus requerimientos (más de tres estrellasy menos de 60 euros).Otro ejemplo, haciendo uso del campo WSDL seríael siguiente: “turquesa ?WSDL

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011una herramienta que proporciona una interacciónsencilla y cómoda con la definición de la ontología.Al finalizar el trabajo, se dispone de una herramientaque permite localizar semánticamente serviciosweb relacionados con el turismo en Tenerife yque además, es fácilmente ampliable a cualquier zonageográfica o, incluso, a otras áeras del conocimientoque no sean el turismo. Es importante resaltar queel código está diseñado para soportar, sin necesidadde modificaciones, una ampliación de la ontología.Los nombres de las clases y sus sinónimos no estánincrustados en el código sino que se leen en el momentoque se carga la ontología. Además, se permiteal usuario introducir búsquedas tanto en inglés comoen español (incluidas palabras con acentos y ’ñ’).Otro de los puntos fuertes del buscador son lascarácteres especiales como “!”y, especialmente “?”,que permiten buscar servicios por un atributo dado(no sólo por nombre). Esto contribuye a realizarbúsquedas más complejas y abre la posibilidad deañadir nuevas búsquedas (ampliando la ontología)sin modificar el código. Por ejemplo, si se añaden losservicios que representan cines y uno de los atributoses si los recintos están adaptados a personasminusválidas o no, se podría realizar la siguientebúsqueda: “cines ?minusvalido=1”, que devolveríalos cines que están adaptados para minusválidos.Finalmente, se ofrecen una serie de búsquedas recomendadaspara cada perfil de usuario. Dependiendode su rango de edad, de su liquidez económica yde algunas otras características sobre el propio viaje(como duración o método de transporte preferido)se le ofrecerán unos servicios u otros. En el casode no aportar información personal, se le asocia unperfil estándar llamado “None”, en el que se agrupanalgunos servicios de interés general o “serviciosrecomendados estándar”. Además, en estasbúsquedas recomendadas, se extraen aquellas palabrasrelacionadas con zonas geográficas, en el casode que existan, y se recalcula la relevancia para queaparezcan en los primeros puestos los servicios localizadosen esas cercanías. De esta forma se pretendeofrecer al usuario servicios que puedan serle de utilidaden la zona de su interés.Es importante resaltar que, basándose en la inmadurezde las herramientas y en el bajo númerode estudios en este sentido, la semántica aplicada alos servicios web es un terreno relativamente nuevo yque necesita tiempo aún para implantarse con tantafuerza como los servicios web lo han hecho.V. Líneas de trabajo abiertasLa semántica es un campo relativamente nuevoy en constante desarrollo por lo que cuenta con unabanico enorme de líneas abiertas. En relación conla herramienta presentada en este trabajo, se puedecontinuar la investigación por tres vías principales:• Razonador semántico: es posible implementarun razonador que tenga como entrada ellenguaje natural y que devuelva como salidalas palabras clave y las clases en las que sedebe realizar la búsqueda. Por ejemplo, anteuna entrada como “Tengo hambre”podría sugerirrealizar una búsqueda en la clase “Food”(enla que están englobadas las clases “Restaurants”y“Taverns”, así como sus correspondientessinónimos en todos los idiomas.• Búsquedas recomendadas: actualmente sehan establecido un conjunto de categorías recomendadassegún el perfil del usuario y las característicasdel viaje, pero esto es sólo un ejemplode uso de dichas búsquedas. Se podríanutilizar para intentar arrojar resultados adecuadoscuando la búsqueda principal fracasa.Por ejemplo, si una búsqueda como “OrotavaMartiánez”no devuelve ningún resultado sepodría cambiar por “North Martiánez”pues laclase “North”engloba todos los municipios delnorte y es más probable encontrar algún resultado.• Inferencia del perfil: obtener el perfildel usuario (ver figura 6) automáticamente através de sus consultas. Los resultados delas búsquedas contienen información acerca dequiénes son sus clases padres. Si los resultadosse engloban, mayoritariamente, bajo la clase“Youth”se le puede asignar ese perfil al usuarioen lugar del perfil por defecto (“None”). De estaforma se conseguirían unos resultados recomendadosmás en concordancia con los intereses delusuario.AgradecimientosEste trabajo ha sido parcialmente financiado porel Ministerio de Educación y Ciencia (Ref. TIN2008-06570-C04-C03) a través del proyecto COPABIB.Agradecer también la inestimable ayuda proporcionadapor la profesora D a . Elena Nielsen, directoradel presente trabajo.Referencias[1] S. Vinoski, Web Services Interactions Models, Part 1:Current Practice, IEEE Internet Computing, Vol 6, N o 3,pp. 89-91, 2002.[2] Tim Berners-Lee, What the Semantic Web can representhttp://www.w3.org/DesignIssues/RDFnot.html[3] Rudi Studer, Stephan Grimm, Andreas Abecker (Eds.),Semantic Web Services. Concepts, Technologies and Applications,Springer-Verlag, 2007.[4] M. Horridge, H. Knublauch, A. Rector, R. Stevens, C.Wroe, A Practical Guide To Building OWL OntologiesUsing The Protégé-OWL Plugin and CO-ODE Tools Edition1.0 http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf[5] Karin Breitman, Marco Casanova, Walter Truszkowski,Semantic Web: Concepts, Technologies and Applications,Springer-Verlag, 2007.[6] Miguel Ángel Abián, El futuro de la web: XML,RDF/RDFS, ontologías y la Web semánticahttp://www.javahispano.org/contenidos/archivo/156/El_futuro_de_la_Web.zip[7] Asunción Gómez, Oscar Corcho, Ontology languages forthe Semantic Web, IEEE Intelligent Systems, vol17, issue1, pp. 54-60, 2002.JP2011-472

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Tecnología grid, cluster, cloud computing y plataformasdistribuidasJP2011-473

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-474

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Planificación de DAGS en entornosoportunísticosMaria del Mar López, Elisa Heymann, Miquel Àngel Senar1Resumen—Las aplicaciones tipo workflow tienen granvolumen de cómputo y necesidad de transferencia deun importante volumen de datos con lo cual su tiempode finalización es elevado. Para reducir este tiempode finalización, es necesario ejecutarlas en diferentesmáquinas interconectadas entre sí a través de unared. Para obtener un buen tiempo de finalizacióno makespan del DAG, es importante asignar correctamentesus tareas a las máquinas disponibles del entornode ejecución. El encargado de realizar la asignaciónde las tareas a las máquinas es el planificador.El principal problema de un planificador estático esque no tiene en cuenta los cambios que ocurren en elentorno de ejecución durante la ejecución del DAG.Para solucionar este problema, se ha realizado unplanificador dinámico, el cual toma información sobreel comportamiento de las tareas que finalizan su ejecucióny el entorno de ejecución, y, reacciona ante loscambios detectados auto-adaptando la planificación delresto de tareas pendientes de ejecución. El objetivode este trabajo es reducir la sobrecarga producida alrealizar excesivas auto-adaptaciones sin empeorar elmakespan. Para reducir la sobrecarga, el algoritmo seauto-adapta solo cuando se estima que habrá ganancia.Las políticas propuestas se han simulado y posteriormenteimplementado en un entorno real y engeneral se ha obtenido una reducción de la sobrecargasuperior a un 20%Palabras clave— Entornos oportunisticos, workflow,planificaciónI. IntroducciónEL trabajo se centra en aplicaciones donde se definentareas y un flujo de datos entre ellas. Elflujo de datos implica que existe un orden de ejecuciónde las tareas. A estas aplicaciones se lasdenomina workflow. Los DAGS representan workflowsque no tienen circuitos. Actualmente existenmuchas aplicaciones workflow científicas con elevadotiempo de cómputo y elevadas transferencias dedatos. [19], [20]Si se ejecutan estos workflows de forma secuencial(una tarea detrás de otra en la misma máquina) eltiempo de finalización es elevado (del orden de horas,días o semanas). Con el objetivo de reducir el tiempode ejecución del workflow, las tareas se ejecutan endiferentes máquinas de manera concurrente.Para poder ejecutar las tareas del workflow enparalelo se utilizan un conjunto de máquinas interconectadasa través de una red. A este conjunto demáquinas y red se la denomina escenario en adelante.La principal característica del escenario es la heterogeneidadde sus máquinas.Para obtener un buen makespan es necesariorealizar planificación de las tareas del DAG alas máquinas disponibles del entorno de ejecución.1 Dpto. de Arquitectura de Computadores, Univ.Autónoma de Barcelona, e-mail: mmar@caos.uab.es.Elisa.Heymann,miquelangel.senar@uab.es.Antes de planificar las tareas se debe obtener informacióndel entorno de ejecución (característicasde las máquinas disponibles y de la red). Posteriormentese realiza la planificación. Esta planificaciónse denomina estática, tiene en cuenta el entorno deejecución antes de realizar la planificación sin considerarposibles alteraciones que en él se produzcan.Los entornos oportunísticos tienen un comportamientodinámico. Esto presenta un problema a laplanificación estática, pues el escenario puede cambiardurante la ejecución del DAG. Los cambios quese producen en el escenario son: desaparición deuna máquina, aparición de una nueva máquina ymodificación de las características de una o variasmáquinas.Como consecuencia del dinamismo de los escenariosoportunísticos se ha desarrollado un algoritmo deplanificación dinámica. Esta planificación dinámicase adapta a los cambios ocurridos en el escenario durantela ejecución del DAG. Este proceso lo denominamosauto-adaptación.El proceso de auto-adaptación a los cambios ocurridosen el escenario genera una sobrecarga enla política de planificación dinámica. Esta sobrecargase produce como consecuencia de recalcularlos parámetros utilizados por la política de planificacióndinámica en la asignación de las tareas a lasmáquinas y en ejecutar el algoritmo de planificación.Este trabajo tiene como principal objetivo el dealcanzar un buen makespan en la planificación delDAG reduciendo la sobrecarga producido por lapolítica de planificación dinámica.La política dinámica planifica las tareas independientesdel DAG. Se denominan tareas independientesaquellas que ya han satisfecho sus dependenciasde datos. Cuando una tarea finaliza su ejecuciónse comprueba si aparece alguna nueva tarea independientepara planificarla. Se repite este procesohasta completar la planificación de todas las tareasdel DAG.Durante la ejecución de las tareas independientesdel DAG se implementan tres pasos con el objetivode reducir la sobrecarga producido por la autoadaptacióndel algoritmo.1. La monitorización gestiona dos eventos independientes:tiempo real de ejecución de las tareascríticas y largas del DAG y, los cambios en el escenario.Las tareas largas son tareas no críticas, peroque tienen un peso elevado en el DAG. Monitorizarel escenario, denominado captura en adelante,consiste en obtener información de las máquinasdisponibles cada cierto periodo de tiempo. El pe-JP2011-475

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011riodo definido entre dos capturas consecutivas de escenarioes dinámico, se adapta a los cambios observadosen capturas anteriores.2. La detección se encarga de evaluar la informaciónobtenida en la monitorización. Si la informaciónproporcionara una mejora en el makespan setiene en cuenta en la planificación de las tareas pendientesde ejecución del DAG.3. La reacción ocurre en caso que la detecciónconsidera que es necesaria. La reacción implementalos siguientes pasos: capturar el nuevo escenario, calcularlos nuevos tiempos estimados de las tareas pendientesde ejecución del DAG y obtener nuevas tareascríticas y largas de las tareas pendientes de ejecucióndel DAG tras aplicar los cambios detectados.Estos tres pasos (monitorización, reacción y detección)se realizan durante la ejecución del DAGy tras la finalización de ciertas tareas independientes(esto se explica mas adelante). Para planificarlas tareas independientes del DAG se ha creado unanueva política de planificación estática, denominadaCLTHEF (Critical Long Task HEFT).Posteriormente, a la política de planificaciónestática CLTHEFT se le han añadido mejoras convirtiéndolaen dinámica. Para ello se han integradolos tres pasos (monitorización, detección yreacción) explicados anteriormente dentro del algoritmoCLTHEFT. Esta política dinámica se denominaSAHEFT (Self Adapting HEFT).Para evaluar la política de planificación dinámicaSAHEFT se ha desarrollado un simulador. El simuladorha servido para realizar un estudio exhaustivode los casos que proporcionan un buen makespan reduciendola sobrecarga.Posteriormente se han planificado y ejecutadoDAGS reales de forma estática (CLTHEFT) ydinámica (SAHEFT) en un entorno oportunísticoreal. El número de máquinas disponibles del entornode ejecución varía de 14 a 50 todas ellas interconectadasa través de una red. Estas máquinas estángestionadas por el gestor de colas Condor. Las aplicacionesreales ejecutadas son Montage [12], Blast[13] y Ligo [14].Las características de cada máquina del entornose obtienen a través del comando condor status [15]del gestor de colas de Condor. Para medir el anchode banda de la red se ha utilizado la herramientaNetwork Weather Service [16] la cual proporcionainformación de la red. Para ejecutar los DAGS realesse ha utilizado la herramienta Schedflow [17].El resto del articulo se estructura de la siguientemanera: En la sección 2 se explica la política estáticadesarrollada, la sección 3 explica nuestra políticadinámica, en la sección 4 se muestra la experimentaciónsimulada y real, en la sección 5 se hacereferencia a los trabajos relacionados, y finalmenteen la sección 6 se muestran las conclusiones.II. Política estáticaLa política CLTHEFT obtiene las tareas críticas ylas tareas largas del DAG. Las tareas críticas formanparte del camino crítico del DAG y son las tareas maspesadas del DAG. El camino crítico hace referencia alcamino del DAG que tardará mas en finalizar su ejecución(desde alguna tarea inicial hasta alguna tareafinal del DAG).Las tareas largas son tareas que no forman partedel camino crítico, pero que tienen un elevado e importantepeso en el DAG. Puede darse el caso queen un nivel de independencia del DAG existan masde una tarea larga. En consecuencia, un DAG puedetener mas de un camino largo. La figura 1 muestrael algoritmo implementado para la obtención de lastareas largas del DAG.Fig. 1.Algoritmo para la obtención de tareas largasSe destaca que si el número de tareas críticas ylargas es superior al 50% respecto a las tareas totalesdel DAG, los caminos largos no se tienen en cuenta.Para la obtención de tareas críticas, la políticaCLTHEFT se basa en la heurística CPOP [6]. Laslíneas que no aparecen en negrita de la figura 2muestran el algoritmo CLTHEFT. En primer lugarse calcula el camino crítico y los caminos largos, seobtienen las características de las máquinas y se ordenande mas rápidas a mas lentas. Seguidamente seobtienen las tareas independientes del DAG. Mientrasqueden tareas pendientes de planificación delDAG, el algoritmo CLTHEFT planifica la tareacrítica independiente en primer lugar a la máquinamás rápida disponible. Si tras la ejecución de la tareacrítica aparece una nueva tarea crítica independientele asigna la mejor máquina disponible. Seguidamente,ordena las tareas largas según su peso y lasplanifica a las máquinas mas rápidas. Cuando noquedan tareas independientes ni críticas ni largas, ordenael resto de tareas según su prioridad (basándoseen HEFT) y las planifica en función de una políticabase. Las políticas bases implementadas en el algoritmoCLTHEFT son: aleatoria, min-min, max-miny HEFT. Cada una de estas políticas base asignala tarea a una máquina determinada, y la políticaCLTHEFT obtiene dicha asignación para planificarJP2011-476

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011las tareas no críticas ni largas.La política CLTHEFT necesita tres parámetros deentrada: el DAG que se planifica, los tiempos decómputo y comunicación estimados de las tareasdel DAG y el escenario de ejecución. Los tiempos decómputo estimados se calculan en función de tiemposobtenidos de ejecuciones reales en una única máquinay de las características de las máquinas. El escenariode ejecución se captura un instante antes de realizarla planificación.El tiempo de comunicación estimado se obtiene enfunción del ancho de banda de la red y del volumende datos que se van a transferir de una máquina aotra del escenario.III. Política dinámicaLa política dinámica, denominada SAHEFT, planificade forma estática las tareas independientes delDAG, monitoriza el escenario y el comportamientode las tareas críticas y largas durante su ejecución,y según lo observado se auto-adapta a los cambiosdetectados para planificar las siguientes tareas independientes.El principal objetivo de la política dinámica es elde obtener un buen makespan del DAG con una sobrecargabaja. El proceso de auto-adaptación generasobrecarga debido a que se tienen que volver acalcular todos los parámetros de entrada del planificador.Los parámetros de entrada son: tiempos decómputo estimados, orden de prioridad de las tareasno críticas ni largas, nuevos caminos críticos y largos,y la reordenación de las máquinas (de mas rápida amas lenta).Este trabajo realiza un estudio sobre cuando esnecesario o no realizar auto-adaptación. Claramenteeste proceso de auto-adaptación se ha de realizar elmínimo número de veces, pero hay situaciones en lasque es indispensable para obtener una mejora significativaen el makespan del DAG.El trabajo diferencia dos situaciones que aparecendurante la ejecución del DAG, que son las siguientes:1. El tiempo de finalización real de una tarea nocorresponde con el estimado.Únicamente se analiza el tiempo final real de ejecuciónde las tareas críticas y largas. Cuando ocurreesta situación, se consideran dos casos posibles. Elprimero es que el tiempo real de ejecución de latarea crítica o larga sea menor que el tiempo estimado.Cuando se da esta situación no se realizaauto-adaptación debido a que la máquina que se estimabarápida se comporta mas rápido en la realidad.Tener en cuenta este cambio no modifica significativamentela planificación de las siguientes tareascríticas ni largas pendientes de ejecución, con lo queno se obtendrá una mejora importante del makespan.El segundo caso se da cuando el tiempo real deejecución de la tarea crítica o larga es mayor queel estimado. En este caso sí que se debe realizarauto-adaptación, pues significa que la estimación dela máquina adonde se envió la tarea crítica o largano era correcta. La máquina que se estimaba comorápida es lenta en la realidad, y este hecho se debeconsiderar en la planificación del resto de tareas pendientesde ejecución del DAG. Al tener este dato encuenta se mejorará el makespan.2. Cambios en el entorno de ejecución (escenario).Se clasifican los cambios en el escenario en trestipos: desaparición de una máquina, aparición deuna máquina y modificación de las características deuna máquina (una máquina rápida pasa a lenta o alrevés). A continuación se explica como reacciona lapolítica SAHEFT tras monitorizar cada caso:a) Desaparece una máquinaAnte esta situación se reacciona siempre, pues evidentemente,nunca se debe enviar una tarea del DAGa una máquina inexistente.b) Aparece una máquinaAnte esta situación se reacciona en función de lascaracterísticas de la máquina nueva que aparece. Sila nueva máquina es rápida y se prevé que será beneficiosapara la ejecución de las siguientes tareasindependientes, se la debe tener en cuenta. En casocontrario, la nueva máquina no se considera.Para decidir si es necesaria o no realizar autoadaptaciónse obtiene el máximo grado de paralelismodel DAG, se ordenan las máquinas del nuevoescenario de mas rápidas a mas lentas, y se obtienela posición que ocupa la nueva máquina en la lista demáquinas ordenadas. Si esta posición es mayor que elgrado máximo de paralelismo del DAG, la máquinano se tiene en cuenta. En caso contrario si que se considerala nueva máquina y se realiza auto-adaptaciónc) Una máquina lenta pasa a rápida o al revésLa decisión de reaccionar cuando se detecta algunamodificación en las características de una o variasmáquinas se realiza implementando el mismo algoritmodel caso anterior (caso en el cual aparece unanueva máquina).La política SAHEFT no realiza capturas del escenarioal finalizar algunas tareas del DAG. Las capturasse realizan en periodos dinámicos. Estos periodosdinámicos se adaptan a los cambios detectadosentre una captura de escenario y la siguiente. El periodomínimo entre dos capturas consecutivas no esinferior a 10 minutos, y el periodo máximo no excede60 minutos.El periodo entre capturas se realiza mediante elsiguiente algoritmo: Inicialmente, se realizan capturasde escenario cada 10 minutos. Si se detectancambios importantes entre una captura y la siguientese decrementa el periodo entre capturas en 5 minutos,sino se incrementa el periodo en 5 minutos. Loscambios entre dos capturas de escenario consecutivasse consideran importantes cuando conllevan a realizarauto-adaptación, estos casos son: se da una elevadavariación entre ambos escenarios (superior al5%), aparece una máquina rápida o desaparece algunamáquinaLa figura 2 muestra el algoritmo dinámicoSAHEFT. Las líneas de la figura 2 que no están ennegrita muestran el algoritmo estático CLTHEFT.Las líneas que aparecen en negrita en la figura 2JP2011-477

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011corresponden a las modificaciones realizadas al algoritmoCLTHEFT para convertirlo en dinámico.A medida que finalizan las tareas planificadas, sealmacenan sus tiempos reales de ejecución en la listaTe. La variable Tc almacena las tareas críticas, lavariable Tl almacena las tareas largas, la variable Malmacena la lista ordenada de máquinas disponibles(de más rápidas a mas lentas), la variable Ti almacenalas tareas independientes del DAG, la variableTnc almacena las tareas que no son ni críticas nilargas. La variable periodo almacena el tiempo quedebe transcurrir entre dos capturas consecutivas deescenario.La política SAHEFT monitoriza el escenario y laejecución de las tareas críticas y largas. En funciónde lo detectado, decide si se debe realizar autoadaptación,y reacciona ante los cambios observados.la línea 7 el algoritmo comprueba si debe realizaruna nueva captura de escenario al transcurrir el periododefinido. En caso afirmativo, la realiza. Enla línea 8 se comprueba si con el nuevo escenario seobtendrá una mejora en el makespan al realizar autoadaptación.Para saber esto se aplican los pasos explicadosen la sección correspondiente a cambios enel entorno de ejecución de este capítulo. En casoafirmativo, en la línea 10 indica que se debe realizarauto-adaptación. Posteriormente, desde la línea 13hasta la 17 determina cual será el nuevo periodo decaptura para el siguiente escenario según los cambiosobservados.Fig. 3.Funcion monitorizacion y deteccionFig. 2.Algoritmo dinamico SAHEFTLa figura 3 muestra el algoritmo que integra lamonitorización y la detección. En primer lugar, talcomo indica la línea 3, el algoritmo comprueba si hafinalizado alguna tarea crítica o larga. En caso afirmativo,tal como muestra la linea 5, obtiene el porcentajede error cometido en la estimación respectoa la realidad, y decide realizar auto-adaptación. EnIV. ExperimentaciónSe han realizado dos tipos de experimentación:simulada y real. La experimentación simulada haservido para estudiar los casos y las condiciones enlas que se reduce la sobrecarga de la política dinámicaobteniendo un buen makespan. La experimentaciónreal ha servido para validar la política dinámica delsimulador en un escenario real. Seguidamente se explicanlas experimentaciones realizadas.1. Experimentación simuladaSe han simulado varios escenarios heterogéneos.En los escenarios simulados existen máquinas rápidasy lentas. Cada máquina del escenario tiene asociadoun benchmark que es el que determina la prestaciónde la máquina. El número de máquinas del escenariosimulado se calcula de forma aleatoria, comprendidoentre 5 y 55 máquinas.El porcentaje de máquinas rápidas varía en cadaescenario, entre un 20% hasta un 50% respecto alnúmero total de máquinas del escenario.Cada tarea del DAG tiene asignado un tiempo decómputo y de comunicación estimados. El tiempode cómputo estimado se genera de forma aleatoriapara una máquina con unas características (benchmark)determinadas. A esta máquina se la denominamáquina de referencia. A partir de los tiemposde cómputo estimados de cada tarea del DAG enJP2011-478

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011la máquina de referencia, se calculan los tiempos decómputo estimados de todas las tareas del DAG entodas las máquinas del escenario. El cálculo de lostiempos de cómputo estimados en todas las máquinasdel escenario se realiza en función del benchmark decada una de ellas. El tiempo estimado de cada tareasdel DAG varía entre 100 a 1100 segundos.El tiempo de comunicación estimado de cada tarease obtiene en función del volumen de datos que envíao recibe una tarea del DAG y el ancho de banda dela red. El ancho de banda de la red se calcula deforma aleatoria entre 60 y 70 MBps. El volumen dedatos que envían o reciben las tareas del DAG sonvalores comprendidos entre 1 y 15 MBytes.El simulador genera diferentes escenarios cuandofinaliza el periodo definido entre captura y captura.La probabilidad de realizar alguna modificación en elnuevo escenario es 1/2. Los escenarios nuevos simuladosimplementan los tres casos posibles:a) Modificación de las características (benchmark)de algunas máquinasEl número de máquinas que sufren variación noexcede del 5%.b) Aparición de algunas máquinasSe selecciona de forma aleatoria una máquinacualquiera del escenario (sin tener en cuenta si esrápida o lenta) y se le aplica una variación positivao negativa a su benchmark de un 10% a un 20%. Seasigna un nombre a esta nueva máquina y se la añadeal escenario.c) desaparición de algunas máquinasSe selecciona una máquina del escenario aleatoriamente(sin considerar si es rápida o lenta) y se laelimina del nuevo escenario.Para poder evaluar los resultados del simulador sehan utilizado tiempos sintéticos de ejecución paracada tarea del DAG. Estos tiempos sintéticos delsimulador equivalen a los tiempos que se obtienentras aplicar las políticas de planificación en escenariosreales. Estos tiempos sintéticos se han generadoaplicando variaciones positivas o negativas comprendidasentre un 0% a un 20% a los benchmarks de lasmáquinas del escenario.La Tabla 1 muestra los resultados obtenidos delsimulador tras aplicar la política SAHEFT a losDAGS Montage, Blast y Ligo. En el entorno deejecución los tiempos estimados y sintéticos difierenentre un 10% a un 20%. Esto significa que hayun error comprendido entre un 10% a un 20% enlos tiempos estimados de ejecución de las tareas delDAG. La variación entre escenarios consecutivos eselevada, motivo por el que el periodo entre capturases cada 600 segundos. En la primera filade la tabla se muestra el makespan de la políticaestática HEFT, la segunda fila muestra el makespande la política dinámica SAHEFT realizando autoadaptaciónsiempre, tras finalizar una tarea críticao larga en caso que se cometa un error superiora un 5% en la estimación y siempre que se capturaun nuevo escenario. La tercera fila muestra elmakespan resultante de la política SAHEFT al prevermejora. La cuarta fila muestra la sobrecarga producidaal realizar adaptación siempre. La sobrecargahace referencia al número de veces que la políticadinámica realiza adaptación. La quinta fila muestrala sobrecarga producida al realizar auto-adaptaciónúnicamente cuando se considera imprescindible paramejorar el makespan del DAG. La sexta fila muestrael porcentaje de ganancia en el makespan de nuestrapolítica dinámica SAHEFT respecto a la políticaestática HEFT. Finalmente, la séptima fila muestrael porcentaje de reducción de la sobrecarga al realizarauto-adaptación únicamente al prever mejoraen el makespan respecto a realizar auto-adaptaciónsiempre.TABLA IMakespan y sobrecarga en escenarios simuladosPolítica Montage Ligo BlastHEFT 4906 8715 6619Mak siempre 2772 5427 4006Mak necesario 2772 5427 4019Ov adaptación 5 12 10Ov necesario 3 7 5% ganancia mak 43,49 37,72 39,47% reducción ov 40 41,66 50Como se observa en la Tabla 1, al aplicar la políticaSAHEFT realizando siempre auto-adaptación oúnicamente al ser necesario, el makespan obtenido essimilar. El porcentaje de mejora del makespan planificandocon SAHEFT respecto a HEFT es superiora 35% en los tres DAGS. Sin embargo, como muestranla cuarta y quinta fila de la tabla, la sobrecargadifiere en ambos casos. Al realizar auto-adaptaciónúnicamente al detectar que se mejora el makespandel DAG, la sobrecarga se reduce en mas de un 40%.Como se ha explicado, esta tabla simula un entornodonde se comete un error en la estimación comprendidoentre un 10% a un 20%. Se han simuladoentornos donde el error cometido en la estimación espequeño (comprendido entre 0% a 10%) y la variabilidadentre escenarios consecutivos no excede el 5%siendo las probabilidades de aparición y desapariciónde máquinas muy bajas, sobre 1/100. En estos entornos,el porcentaje de mejora del makespan al realizarauto-adaptación es muy bajo, del orden de un5%. La reducción de la sobrecarga es significativa,del orden de 40%.2. Experimentación realSe dispone de máquinas heterogéneas interconectadasa través de una red. El número de máquinasdisponibles del escenario no es constante, varía entre14 hasta 50 máquinas.Para obtener la información de las máquinasdisponibles del escenario y sus características (benchmarken MFlops) se ha utilizado el comando condorstatus que proporciona el gestor de colas Condor.Para obtener la información del ancho de bandade la red se ha utilizado la herramienta NWS.A través de NWS se ha detectado que la red queJP2011-479

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011interconecta las máquinas es homogénea, el anchode banda medido entre diferentes máquinas de la redestá comprendido entre 65Mbps hasta 76Mbps. Espor este motivo que el trabajo está orientado más acómputo que a comunicación.Para ejecutar la política dinámica SAHEFT seha utilizado la herramienta SchedFlow. La políticaSAHEFT envía una planificación de las tareas independientesa SchedFlow, y éste es el encargadode monitorizar si durante la ejecución de las tareasdel DAG ocurre algún problema. Si es así, avisa alplanificador de SchedFlow que ejecutará de nuevo lapolítica SAHEFT.Se ejecutaron las aplicaciones workflow Montage,Blast y Ligo. Tal como indicaba el simulador, se hacomprobado que la política SAHEFT ejecutada duranteel fin de semana o por la noche no presenta unaelevada mejora en el makespan respecto a HEFT (delorden del 5%), debido a que las máquinas no sufrenmodificación alguna. Sin embargo, cuando se ejecutanlos DAGS durante el día, la política SAHEFTmejora el makespan de la aplicación sobre un 15%,dependiendo del DAG que se ejecute, y de las modificacionesocurridas en el escenario.La Tabla 2 muestra uno de los resultados realesobtenidos con la planificación dinámica de los tresDAGS. En el entorno de ejecución las máquinasvarían durante la ejecución del DAG, y hay un elevadoerror en los tiempos estimados de cómputo delas tareas de cada uno de los DAGS.Se han realizado pruebas en escenarios poco variablescon un porcentaje de error en el tiempo decómputo estimado respecto al real menor del 2%.En estos escenarios el makespan de los DAGS trasaplicar SAHEFT respecto al makespan obtenido mediantela política estática CLTHEFT es similar.TABLA IIMakespan y sobrecarga en escenarios realesPolítica Montage Ligo BlastHEFT 9784 8535 2220Mak siempre 8137 7952 2132Mak necesario 8052 8000 1845Ov adaptación 22 24 19Ov necesario 11 13 8% ganancia mak 17,7 6,36 16,9% reducción ov 50 45,83 57,9V. Trabajo relacionadoLas políticas estáticas de planificación de workflowsse dividen en dos categorías, las más simplesque planifican los DAGS por nivel de independenciade sus tareas y las más complejas, que analizan todoel DAG antes de realizar la planificación.Del grupo de las políticas de planificación mas simplesse han estudiado las siguientes: random, minmin[1], max min [2] y sufferage [4]. Se han implementadoy evaluado con el simulador [18] y se haconcluido que, de todas ellas, la política sufferage esla que proporciona un mejor makespan del DAG.Del grupo de las políticas estáticas de planificacióncomplejas, se han estudiado las siguientes: HEFT[3], BMCT [5] y CPOP. Normalmente la políticaHEFT es la que proporciona mejor resultado en elmakespan del DAG [7], [8]. Es por este motivoque, para la experimentación de la política dinámicaen DAGS reales, se ha utilizado como política baseHEFT. Se ha adaptado la política HEFT para queplanifique las tareas independientes. El hecho de utilizarde política base HEFT es el de garantizar unode los mejores resultados en la planificación estática.Durante la realización de la política dinámicaSAHEFT, se han estudiado las políticas dinámicasAHEFT y ALSS que trabajan en entornos grid [9],[10], [11]. Las políticas AHEFT y ALSS replanificantodas las tareas pendientes de ejecución en caso quese considere necesario. El hecho de replanificar lastareas pendientes de ejecución genera sobrecarga enel sistema debido a que se tiene que planificar comomínimo dos veces dichas tareas. Con el objetivo dereducir la sobrecarga generada al replanificar las tareas,nuestra política dinámica planifica una únicavez a cada tarea del DAG.VI. ConclusionesEl objetivo principal de nuestro trabajo es el deproporcionar un buen makespan para cualquier DAGreduciendo la sobrecarga. Para ello se han estudiadodiferentes políticas de planificación estáticasy se han comparado entre ellas. Se han realizadopruebas de DAGS reales en entornos heterogéneosgestionados bajo Condor y se ha obtenido una mejorplanificación con la política estática HEFT. Durantela ejecución de las aplicaciones se ha observado unalto dinamismo en el entorno de ejecución y es poreste motivo que se ha visto la necesidad de implementaruna política dinámica que se adapte a loscambios que se producen en el escenario durante laejecución de un DAG.Para implementar la política dinámica se ha desarrolladouna política estática de planificación llamadaCLTHEFT. La política estática CLTHEFTplanifica en primer lugar las tareas críticas del DAGy posteriormente las tareas largas del DAG a lasmejores máquinas disponibles del entorno. Finalmente,las tareas no críticas ni largas se planificansegún una heurística base estática (min-min,maxmin,aleatoria, o HEFT).La política CLTHEFT proporciona un makespansimilar al de la política HEFT. Esto se ha verificadovía simulación y a través de ejecuciones de DAGSen un entorno real. Posteriormente, se han añadidomejoras a la política CLTHEFT hasta convertirla endinámica.La política dinámica, denominada SAHEFT, tieneun inconveniente importante: al detectar algún erroren la estimación del planificador y reaccionar anteeste error, se genera sobrecarga. Considerando elerror detectado, el planificador debe actualizar susJP2011-480

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011parámetros de entrada y adaptarse al cambio producido.Es por este motivo que nuestro trabajotrata de reducir la sobrecarga de la política dinámicagarantizando un buen makespan del DAG.A través del simulador se realizó un estudio exhaustivode cuales son los casos que proporcionanun mejor makespan tras finalizar un DAG y cualesno. Este estudio se ha integrado en el algoritmo quedecide si se debe o no realizar auto-adaptación.Finalmente se han ejecutado DAGS reales con lapolítica SAHEFT en escenarios heterogéneos mediantela herramienta SchedFlow.De la experimentación real se concluye que, en casoque los escenarios sufran variaciones importantes yque el error que se cometa en la estimación seasuperior a un 5%, la política SAHEFT mejora elmakespan mas de un 15% respecto a HEFT. La reducciónde sobrecarga que proporciona SAHEFT esimportante, del orden de 40% o superior respectoal hecho de reaccionar siempre ante la detección decualquier cambio.AgradecimientosEste artículo ha sido financiado por el MEC-MICINN Spain mediante el proyecto TIN2007-64974tional Journal of Computer Science and Network Security,VOL.9 No.4, April 2009[14] D.A. Brown, P.R. Brady, A. Dietz, J. Cao, B. Johnsonand J. McNabb, A case study on the use of workflow technologiesfor scientific analysis: gravitational wave dataanalysis, Workflows for e-Science, Springer (2006).[15] Douglas Thain, Todd Tannenbaum, and Miron Livny,Distributed Computing in Practice: The Condor Experience,Concurrency and Computation: Practice and ExperienceVolume 17. Issue 2-4. pp: 323-356, 2005[16] Rich Wolski, Forecasting Network Performance to SupportDynamic Scheduling Using the Network Weather Service,High Performance Distributed Computing, 1997.Proceedings. The Sixth IEEE International Symposiumon, pp 316-325, 1997[17] Gustavo Martinez, Elisa Heymann, Miguel Angel Senar,Emilio Luque, Barton P. Miller Using SchedFlow for PerformanceEvaluation of Workflow Applications Workflowsin Support of Large-Scale Science (WORKS), 5th Workshopon, pp. 1-8, 2010[18] Maria M. Lopez, Elisa Heymann, Miguel Angel Senar,Analysis of Dynamic Heuristics for Workflow Schedulingon Grid Systems, ispdc, pp.199-207, Proceedings ofThe Fifth International Symposium on Parallel and DistributedComputing (ISPDC’06), 2006[19] W.M.P. van der Aalst, K.M. van Hee and G.J. Houben,Modelling and Analysing Workflow using a Petri-netBased Approach, 2nd Workshop on Computer-supportedCooperative Work, Petri Nets Related Formalisms, pp. 31-50,1994.[20] Jia Yu and Rajkumar Buyya A Taxonomy of WorkflowManagement Systems for Grid Computing, Journal ofGrid Computing Volume 3, Numbers 3-4, 171-200, 2005Referencias[1] Min-You Wu, Wei Shu, Hong Zhang. Segmented Min-Min:A Static Mapping Algorithm for Meta-Tasks on HeterogeneousComputing Systems., 9th Heterogeneous ComputingWorkshop, 2000, pp. 375-385, 2000.[2] Y.-K. Kwok, I. Ahmad, Static scheduling algorithms forallocating directed task graphs to multiprocessors., ACMComputing Surveys, 31(4), pp. 406-471, 1999.[3] H. Topcuoglu, S. Hariri, and M.Y. Wu. Performance-Effective and Low-Complexity Task Scheduling for HeterogeneousComputing., IEEE Trans. Parallel and DistributedSystems, Vol. 13, no. 3, pp. 260-274, 2002.[4] A. Mandal et al. Scheduling Strategies for MappingApplication Workflows onto the Grid. In 14th IEEESymposium on High Performance Distributed Computing(HPDC 2005). IEEE Computer Society Press, pp. 4, 2005.[5] R Sakellariou, H Zhao. A Hybrid Heuristic for DAG Schedulingon Heterogeneous Systems. Proc. Of the 13th HeterogeneousComputing Workshop (HCW 04), pp. 111,2004.[6] H Topcuoglu, S Hariri, Min-You Wu. Task SchedulingAlgorithms for Heterogeneous Processors. Eighth HeterogeneousComputing Workshop, hcw,pp.3-14, 1999.[7] Louis-Claude Canon and Emmanuel Jeannot A Comparisonof Robustness Metrics for Scheduling DAGs on HeterogeneousSystems, IEEE International Conference onCluster Computing, pp.558-567, 2007[8] Louis-Claude Canon and Emmanuel Jeannot, Rizos Sakellariouand Wei Zheng, Comparative evaluation ofthe robustness of DAG scheduling heuristics, GridComputing,pp.73-84, 2008,[9] R Sakellariou, H Zhao, A low-cost rescheduling policy forefficient mapping of workflows on grid systems. ScientificProgramming, 12 (4), pp. 253-262, Dec. 2004.[10] Zhifeng Yu and Weisong Shi, An Adaptive ReschedulingStrategy for Grid Workflow Applications, Proceedings ofthe 21st IPDPS 2007.[11] Sung Ho Chin,Taeweon Suh,Heon Chang Yu, Adaptiveservice scheduling for workflow applications in Service-Oriented Grid, The Journal of Supercomputing Volume52, Number 3, 253-283, 2009[12] Berriman, G. Laity, A. and et al, Montage: The Architectureand Scientific Applications of a National VirtualObservatory Service for Computing Astronomical ImageMosaics, In. Proc. of Earth Sciences Technology Conference,Maryland USA, 2006[13] Enis Afgant and Purushotham Bangaloret, DynamicBLAST a Grid Enabled BLAST, IJCSNS Interna-JP2011-481

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-482

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011QoS en Entornos Grid mediante un Sistema deMeta-planificación por Adelantado basado enSLAsJavier Conejero, Luis Tomás, Carmen Carrión, Blanca Caminero 1Resumen— El establecimiento de acuerdos entre losusuarios y las entidades que gestionan los recursosGrid es todavía un reto. Se necesita una entidad encargadade la comunicación con los usuarios, con el objetivode establecer los contratos de uso de los recursosy también de implementar técnicas de renegociación.Por otro lado, se deben implementar mecanismos quedecidan si la calidad de servicio (QoS) solicitada puedeser proporcionada y, en tal caso, asegurar que dichoacuerdo se cumple.Una forma de incrementar la probabilidad de logrardicha QoS es mediante la planificación de trabajos poradelantado. Esto significa que los trabajos son planificadoscon un tiempo de antelación sobre su propiotiempo de ejecución. De esta forma, es mas fácil queel recurso apropiado este disponible para ejecutar lostrabajos cuando llegue su turno. Así pues, este artículopresenta un solución, implementada sobre Globusy el metaplanificador GridWay, para proveer QoS mediantedicho tipo de planificación. Aparte de esto,los mecanismos necesarios para gestionar la comunicaciónentre los usuarios y el sistema son presentadose implementados mediante contratos basados en la especificaciónWS-Agreement.Palabras clave—Meta-planificador, Grid, QoS, SLAs,WS-Agreement.I. IntroducciónEn sistemas altamente variables y heterogéneos,como es el caso de los entornos Grid, los recursospueden estar distribuidos entre múltiples dominiosy bajo diferentes políticas de administración, loque hace extremadamente difícil proporcionar QoS alos usuarios. Por esto, la infraestructura Grid debeproporcionar los servicios necesarios para una planificacióndel uso de los recursos automática, quese encargue de este proceso de manera transparentea los usuarios [1]. A este sistema se le llama“meta-planificador” [2]. Sin embargo, el proceso deplanificación se complica debido a que generalmenteel meta-planificador no tiene control, ni siquieracompleto conocimiento, de los recursos del sistema,ni su red de interconexión. Esto significa que no siemprees posible realizar reservas de uso en esos recursospara ejecutar los trabajos, y por lo tanto, no esposible asegurar que dicho recurso va a finalizar laejecución de un determinado trabajo a tiempo.Como las reservas no son siempre factibles, la ideaprincipal se basa en intentar asegurar que un recursoestará disponible cuando un trabajo lo necesite ypara ello se realiza una planificación por adelantadodel uso de dichos recursos. Esta planificación puedeser vista como el primer paso del algoritmo de reservapor adelantado, en el cual se seleccionan tanto el1 Instituto de Investigación en Informática de Albacete(I 3 A), Universidad de Castilla-La Mancha, e-mail:{FJavier.Conejero, Luis.Tomas, MariaBlanca.Caminero,Carmen.Carrion}@uclm.esrecurso como el periodo de tiempo en el que se ejecutaráel trabajo, pero sin llegar a hacer reserva físicaalguna del recurso. De este modo, el sistema necesitaestimar el estado futuro de los recursos y cuantodurará la ejecución. Para ello, se han implementadoalgunas técnicas de predicción.Por otro lado, y teniendo en cuenta que elrendimiento del sistema de meta-planificación será elque repercuta en la visión que el usuario tenga delfuncionamiento del sistema, es necesario desarrollarmecanismos para gestionar la interacción entreambos. Para ello se usan contratos del tipo ServiceLevel Agreements (SLAs [3]).Hoy en día, la economía actual está mostrando unatendencia hacia economías orientadas a servicios. Estatendencia requiere nuevos mecanismos para gestionary potenciar de forma eficiente el uso de recursoscomputacionales. Y está principalmente promovidopor motivos económicos y de negocios, donde sonnecesarios mecanismos para la negociación de acuerdoslegales [4]. Debido a este interés, muchos esfuerzosse han dedicado a tratar de resolver este problemaen entornos Grid; pero el trabajo más importante hasido la especificación WS-Agreement (Grid ResourceAllocation Agreement Protocol) para SLAs, consideradaestándar de facto. Como resultado, muchosproyectos Grid actuales están interesados en la implantaciónde SLAs (p. ej. AssessGrid [5], Brein [6],y SLA@SOI [7] entre otros).Para nuestro propósito, los SLAs representan unaformalización del proceso de emisión de trabajos paralos Grids. Además, son el mecanismo fundamentalpara la representación formal de las restriccionestemporales asociadas a cada trabajo. Esta informaciónes necesaria en el proceso de meta-planificaciónpor adelantado.En conclusión, la principal contribución presenteen el artículo es una solución construida sobre elmeta-planificador GridWay para proporcionar QoSmediante el desarrollo de meta-planificaciones poradelantado y con una interfaz de usuario basada enWS-Agreement. El uso de esta propuesta permiteque los trabajos finalicen su ejecución cumpliendocon sus deadlines gracias a algunas heurísticas queestiman el estado futuro de los recursos y cuanto duraránlas ejecuciones de los trabajos en ellos.Este artículo se organiza de la siguiente manera.Varios trabajos relacionados son presentados en laSección II. En la Sección III se define el sistema demeta-planificación por adelantado basado en SLAs.Después se muestra la metodología usada para lle-JP2011-483

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011var a cabo el proceso de comunicación con los usuariosmediante contratos SLA en la Sección IV. Finalmente,las conclusiones obtenidas y las posibles lineasde trabajo futuro son detalladas en la Sección V.II. Trabajo RelacionadoProporcionar QoS en entornos Grid es todavía unproblema que está siendo ampliamente investigadopor una gran variedad de proyectos basados en reservaspor adelantado: como GARA [8], Grid CapacityPlanning [9], o VIOLA [10], entre otros. Ésta técnicatiene un inconveniente: no todos los recursos puedenser reservados. Debido a esta limitación, nuestro trabajopretende explotar la planificación por adelantadoen vez de la reserva de recursos por adelantado.La meta-planificación por adelantado requiere realizarpredicciones sobre el estado futuro de los recursosy sobre la duración de los trabajos en estosrecursos. Una visión global de algunas técnicasde predicción se puede encontrar en [11]. Algunosejemplos aplican modelos estadísticos a ejecucionespasadas [12] y heurísticas basadas en las característicasde los trabajos y recursos [13]. En [12], se muestraque aunque la carga exhibe propiedades complejas,es predecible consistentemente a partir del comportamientopasado. En [13], se evalúan varios modelosde series lineales temporales para la predicción decarga de CPU. En nuestro trabajo, se utiliza unatécnica basada en datos históricos, dado que ha sidodemostrado que provee mejores resultados comparadoscon las funciones lineales [14].Este tipo de planificación necesita disponer de unaestructura de datos apropiada para gestionar todala información de forma eficiente. Hay varias estructuraspara la gestión de esta información, como GridAdvanced Reservation Queue [15] (GarQ). Pero eneste trabajo se utilizan los árboles rojo–negro dadoque proveen acceso eficiente a la información sobreel uso de recursos, como ha sido demostrado en [16].Por otro lado, los SLAs son importantes hoy endía. Se han realizado muchos esfuerzos en camposcomo: su gestión [17], implicaciones con la QoS [18],explotación de la virtualización y semántica [19]y especialmente en su estandarización. El avancemás importante en el ámbito de los SLAs ha sidola especificación WS-Agreement [20], consideradaestándar de facto, donde la estructura y mecanismospara desplegar los SLAs en un sistema, desdeun punto de vista global, son definidos. Pero graciasa una reciente revisión de la especificación [21],ha sido definido un nuevo protocolo de negociaciónque introduce el concepto de renegociación. Este conceptose define como una interacción múltiple entreel usuario y proveedor de servicios para conseguirmejores acuerdos. Pero WS-Agreement no es la únicaespecificación disponible; SLAng [22] y WSLA [23]son alternativas, pero debido a su falta de soporteno son recomendables.Debido a la importancia de los SLAs, muchosproyectos están interesados en su implantación [24].La mayoría de ellos implementan WS-Agreement,como SLA@SOI [7], AssessGrid [5] y Brein [6]. Elprimero de ellos está orientado en la implantaciónde SLAs en infraestructuras orientadas a servicios(SOIs) desde un punto de vista genérico. Assessgridy Brein tienen un propósito común, que es potenciarlos entornos computacionales Grid en entornos de negociosy sociedad. Sin embargo, Assessgrid se centraen la evaluación de riesgos, mientras que Brein secentra en la gestión eficiente de los Grids basándoseen técnicas de inteligencia artificial, web semántica ysistemas inteligentes. Otro proyecto importante dentrode este ámbito es WSAG4J(WS-AGreement forJava [25]). Consiste en una implementación genéricade la especificación WS-Agreement. Está diseñadopara agilizar el desarrollo y facilitar la depuración deservicios y aplicaciones basadas en WS-Agreement.No todos los proyectos implementan la especificaciónWS-Agreement para la gestión de SLAs. Unejemplo de esto es NextGrid [26].III. Meta-Planificación por AdelantadoEn un entorno Grid real muchos recursos nopueden ser reservados debido a que no todos losgestores locales lo permiten. También existen otrotipo de recursos, como el ancho de banda, que soncompartidos entre varios dominios administrativoshaciendo su reserva extremadamente complicada.Este es el principal argumento para llevar a cabouna planificación por adelantado del uso de los recursosen vez de reservas por adelantado. Esto significaque el sistema necesita anotar las decisionesprevias para poder tomar decisiones en el futuro sinque se produzcan solapamientos en las ejecuciones.Con todo esto, nuestro sistema de planificación siguelos siguientes pasos (ver Figura 1):1) El usuario envía una petición al meta-planificadorde su dominio administrativo local a través de ungestor de SLAs (ver Sección IV). Cada SLA (peticiónde ejecución de un trabajo) debe proporcionaruna tupla con la información sobre la aplicación y losparámetros de QoS: (in file, app, t s, d). in file contienelos ficheros de entrada requeridos para ejecutarla aplicación app. En este estudio, los parámetros deQoS vienen especificados por el tiempo de inicio, t s(tiempo en el que el trabajo puede empezar a ejecutarse),y el deadline, d (tiempo en el que el trabajodebe haberse ejecutado).2) El meta-planificador se comunica con el Gap Managementpara obtener el recurso y el intervalo detiempo en el que ejecutar el trabajo. Los heurísticospresentados tienen en cuenta el estado predichopara el recurso (tanto recurso computacional comored), los trabajos que ya han sido planificados y losrequisitos de QoS del trabajo.3) Si no es posible alojar el trabajo en los recursosdel propio dominio cumpliendo las QoS deseadas,empieza una comunicación con otros metaplanificadoresde otros dominios. Para realizar estascomunicaciones eficientemente se pueden usar técnicasbasadas en sistemas P2P (como se propusieronen [27], [28], entre otros).4) Si aún así no es posible ejecutar el trabajo con laQoS solicitada, un proceso de renegociación es ini-JP2011-484

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1. Proceso de Meta-Planificación por Adelantadociado entre el usuario y el gestor de SLA para intentardefinir requisitos de QoS que puedan ser proporcionados.Recalcar que este proceso de renegociación,así como todo el proceso de interacción con los usuariosse lleva a cabo mediante SLAs (Sección IV detallala implementación de los SLAs).Como muestra la Figura 1, puede haber más de unmeta-planificador en cada dominio administrativo, sibien es cierto que tienen que comunicarse con el mismoGap Management, ya que tiene la información sobreel uso futuro de los recursos de ese dominio. Sinembargo, los recursos pueden dividirse en subconjuntos,haciendo esta propuesta altamente escalable.Esto representa un escenario ideal, en el que todoslos trabajos son enviados a través del Gap Management.Sin embargo, esta no es la regla en los entornosGrid, donde los recursos están compartidos entre losusuarios e incluso entre diferentes organizaciones virtuales(VOs). Por esta razón, con el fin de tener encuenta la carga que no es enviada a través del metaplanificador,son necesarias estimaciones acerca delestado futuro de los recursos.La funcionalidad del meta-planificador por adelantadoha sido implementada como una capa sobreel meta-planificador GridWay [2], llamada SA–layer(Scheduler in Advance Layer) [14] (ver Figura 2).Dicha capa usa las funcionalidades proporcionadaspor GridWay para el descubrimiento y monitorizaciónde recursos, envío, ejecución y monitorizaciónde los trabajos, etc. Además, la información referentea previas ejecuciones de los trabajos, y al estadode la red y los recursos, se almacena en dos basesde datos, DB Executions y DB Resources, respectivamente.El uso de los recursos se divide en intervalos detiempo, llamados slots. Así, el sistema tiene que planificarel uso futuro de los recursos alojando los trabajosen un recurso en un tiempo específico (usandouno o más slots contiguos). De este modo, se necesitanestructuras de datos para mantener una trazade los slots usados (Data Structure en la Figura 2).En este trabajo se usan árboles rojo–negro [16] comoestructura de datos, con el objetivo de identificareficientemente los slots adecuados, sin tener que examinartodos los periodos libres. La razón de elegireste tipo de estructura es que el camino más largo dela raíz a las hojas no es más de dos veces el más corto.Así pues, el árbol se mantiene balanceado, y comoFig. 2. Capa de Planificación por Adelantado (SA–layer).resultado de ello, insertar, borrar o buscar en él tieneun peor caso proporcional a la altura del árbol (O(logn)). La idea de usar este tipo de árboles fue propuestaen [16]. Sin embargo, su propuesta no tiene en cuentala fluctuación en el rendimiento de los recursos.Además, los autores asumen que los usuarios tienenun conocimiento previo sobre la duración de los trabajos,lo cual no es siempre cierto en un entorno Grid.Nuestro trabajo no hace esas suposiciones, por lo quenecesita un mecanismo para estimar la duración delos trabajos en los recursos (Predictor en Figura 2)y por lo tanto saber cuantos slots hacen falta para laejecución de un determinado trabajo en un recurso.A. Predicción del Tiempo de EjecuciónEl hecho de que los recursos presenten unrendimiento diferente hace muy difícil las tareas depredicción de duración de los trabajos en ellos. Ylo que es peor, las características de rendimientopueden cambiar para las diferentes aplicaciones. Poresto, se necesita estimar el estado futuro de los recursosy teniendo esto en cuenta, estimar el tiempo necesariopara completar un trabajo en un recurso paraun intervalo de tiempo específico. Con el objetivo dehacer esas predicciones tan precisas como sea posible,los tiempo necesarios para la propia ejecución deltrabajo y los tiempos necesarios para completar lastransferencias son calculados por separado. Además,el sistema tiene en cuenta las características de lostrabajos, la potencia y uso de la CPU de los recursosy el estado de la red. Para ello, se implementa unatécnica basada en una función Exponential Smoothing[29] que calcula el estado futuro de las CPUs delos recursos y el estado futuro de los enlaces de red.Teniendo en cuenta esas informaciones sobre el estadodel Grid, una estimación para el tiempo de ejecuciónes calculado usando la información de ejecucionesprevias, como se muestra en el Algoritmo 1.Este algoritmo usa los tiempos de ejecuciones previasde la aplicación app en el recurso R i para calcular sutiempo de ejecución medio incluyendo los tiempos deencolado (línea 8). Después de esto, la predicción sobreel estado futuro de la CPU es calculado usandola función de Exponential Smoothing (línea 9). Condichas informaciones, la media del tiempo de ejecuciónobtenida es ponderada usando la informaciónpredicha para el estado de la CPU (línea 10). La formade calcular los tiempos necesarios para completarlas transferencias es bastante similar. El ancho debanda medio predicho para el intervalo en el que eltrabajo tiene que ser ejecutado es otra vez calculadousando la función Exponential Smoothing. Con es-JP2011-485

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo 1 Estimación del tiempo de ejecución(ExecT Estimation)1: Sea R = conjunto de recursos conocidos por GridWay {R 1 ,R 2 ,. . . ,R n}2: Sea app el trabajo a ser ejecutado3: Sea initT el tiempo de inicio del trabajo4: Sea d el deadline del trabajo5: Sea ExecutionT ime(app, R i ) j el j tiempo de ejecuciónpara la aplicación app en el recurso R i6: Sea ES cpu(DB Resources Ri , initT, d) la función exponentialsmoothing que calcula el % de CPU libre en elrecurso R i entre el tiempo initT y d7: Sea CP U free(R i , initT, d) el % de CPU libre en el recursoR i desde el tiempo ∑initT hasta dnj=18: ExecutionT ime =i) jn9: CP U free(R i , initT, d) = ES cpu(DB Resources Ri ,initT, d)10: ExecutionT ime = ExecutionT ime ∗ (2 −CP U free(R i , initT, d))11: devuelve ExecutionT imeAlgoritmo 2 Estimación del tiempo del trabajo1: Sea R i = un recurso2: Sea app = el trabajo a ejecutar3: Sea initT = tiempo de inicio del trabajo4: Sea d = deadline del trabajo5: Sea size IN = el número de bytes de entrada a ser transferidos6: Sea size OUT = el número de bytes de salida a ser transferidos7: for cada R i que tenga un hueco do8: P rolog = T ransT Estimation(R i , initT, d, size IN )9: Epilog = T ransT Estimation(R i , initT, d, size OUT )10: ExecT = ExecT Estimation(R i , app)11: if RT (R i ) < 0 then12: ExecT = ExecT + |RT (R i )|13: end if14: JT Ri = P rolog + ExecT + Epilog15: end forta información junto con la cantidad total de bytes atransferir, se estima el tiempo necesario para completardichas transferencias.Finalmente, las predicciones obtenidas son ponderadasteniendo en cuenta la confianza en los recursosescogidos. Esta información sobre la confianza escalculada siguiendo el Algoritmo 2. Con la informaciónsobre las estimaciones de tiempos de ejecucióny transferencias, junto con la confianza en el recursoR i , definido como RT (R i ), el tiempo de ejecución esajustado (línea 12) y la estimación para el tiempototal del trabajo, JT Ri , es calculada (línea 14).La confianza en los recursos se obtiene usando laEcuación 1:∑ nj=(n−N)RT (R i ) =(Estimated (j,i) − Real (j,i) )N(1)siendo Estimated (j,i) el tiempo total estimado parala ejecución del trabajo j en el recurso R i ; y Real (j,i)el tiempo total real para el trabajo j en el recurso R i .La salida de esta función es la media de los errorescometidos en las últimas N predicciones y es usadopara ajustar las predicciones de los trabajos que seejecuten en ese recurso. Como resultado, la confianzaen las estimaciones depende de como de confiablesea el comportamiento del recurso. Los beneficios deeste ajuste de las predicciones usando el factor deconfianza fueron evaluadas en [14], dónde se pusode manifiesto la bondad de esta técnica. Así pues,ahora estamos mezclando las técnicas de estimaciónpresentadas en [14] y [29] con el fin de obtener unaspredicciones más precisas.Es importante destacar que dichas prediccionessólo son calculadas en el caso de que un hueco seaencontrado en un recurso. De esta forma, no hayque calcular los tiempos para todos los recursos delsistema, lo que sería muy ineficiente. Por otro lado,cuando un recurso abandona el sistema por cualquierrazón, los trabajos planificados para ser ejecutadosen él, son replanificados a otros recursos. Esta característicaes importante dada la dinamicidad de losGrids. Esta tarea es llevada a cabo por el móduloJob Rescheduler (ver Figura 2). Finalmente, destacarque este trabajo esta centrado en trabajos simples,si bien es cierto que como trabajo futuro se quiereaumentar la funcionalidad para poder manejar flujosde trabajos, así como pilot jobs.IV. Service Level Agreements (SLAs)Una vez que la ejecución de un trabajo puede serasegurada con suficiente precisión, el siguiente pasoes establecer comunicación con el usuario para alcanzarun acuerdo sobre la ejecución. Este proceso serealiza mediante acuerdos de nivel de servicio (ServiceLevel Agreements (SLAs)). El concepto de SLAse define como un contrato entre usuario y proveedorde servicios, donde se definen explícitamente lasexpectativas, obligaciones e implicaciones legales [3].Es decir, en ellos se representa la QoS que el usuarioespera recibir. Además, los SLAs son el principalmecanismo para mejorar la expansión comercial delos Grids, debido fundamentalmente a su soportepara los modelos pay–per–use y al hecho de representarun documento legal en la negociación [30].Formalmente, el uso de SLAs refuerza la relaciónentre usuario y proveedor de servicio de dos maneras:mediante un acuerdo legal que debe ser cumplido ycomo un acuerdo que puede ser negociado. La negociaciónimplica que el proveedor de servicio tienela posibilidad de decidir si los requisitos del usuariopueden ser satisfechos y, en la medida de lo posible,negociar con él para alcanzar un acuerdo mejor.Actualmente, el estándar más importante y ampliamenteutilizado en el ámbito de SLAs es WS-Agreement. La última versión de la especificación fuepublicada en Marzo de 2007 [20]. En ella se definentodos los aspectos relacionados con la creación, estructuray gestión de los SLAs. WS-Agreement defineun esquema básico para los acuerdos (ver Figura3). Cada acuerdo tiene un identificador (Nombre)y un Contexto. En el Contexto se especifica todala información relativa al propio acuerdo, como: informaciónrelativa al proveedor de servicios, etc. Elbloque Términos está formado por dos subbloques:el primero de ellos, Términos de servicio, contiene lainformación relativa a los servicios/recursos que vana ser provistos (p. ej. número de máquinas, arquitecturade la CPU, etc.); y el segundo, Términos degarantía, contiene los niveles de servicio que debenser garantizados para cada servicio/recurso especifi-JP2011-486

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Estructura de SLAcado en los Términos de servicio (ej. 2 (máquinas),x86 64 (arquitectura de la CPU), etc.). Finalmente,el bloque Restricciones de creación contiene las limitacionesde la negociación.En Enero de 2011, una revisión de la especificaciónWS-Agreement fue publicada [21], extendiendo elproceso de negociación. El protocolo de negociacióndefinido en la especificación básica contempla únicamenteun proceso de negociación simple, donde elusuario pide una plantilla de negociación al proveedorde servicios, la rellena con la QoS que esperarecibir y la envía al proveedor de servicios; el cualacepta o rechaza el SLA. Pero con la reciente revisión(ver Figura 4), la renegociación es posible gracias aun bucle entre el usuario y el proveedor de serviciosprevia aceptación de una oferta. Esto permite alcanzarun acuerdo mejor para ambos participantes.La definición de los Términos en cada SLA noestá definido en la especificación WS-Agreement, porello, su definición se deja a cargo del proveedor deservicios. Él es el encargado de especificar los términospara sus propias necesidades (p. ej. hardware,restricciones temporales o restricciones relacionadascon el trabajo). Estos términos pueden ser muy numerososy diferentes entre sí, pero hay varios de ellosque suelen aparecer: relacionados con el hardwarenecesario (como el número de máquinas o la cantidadde RAM entre otros), y más importantes, relacionadoscon restricciones temporales. Estas restriccionessuelen aparecer como start–time y duración (odeadline). Pero es posible definir nuevos términospara mejorar el conocimiento sobre los trabajos yexplotarlos en el proceso de meta-planificación.Para este propósito, cada SLA emitido a esteframework debe seguir la especificación WS-Agreement (ver Figura 3). Por ello, los Términosde servicio especificados en cada SLA sonlos parámetros de ejecución para el proceso demeta-planificación. Estos términos son fundamentalmente:trabajo, (app, in file), start-time (t s) ydeadline (d)). El bloque Nombre sólo especifica unidentificador de fácil reconocimiento para los humanos,mientras que el bloque Contexto contiene dosparámetros fundamentales: template-id, identificadorde la plantilla de negociación para identificación internay proveedor de servicio para la identificacióndel proveedor de servicio. Esta estructura está abiertaa una futura extensión de los parámetros definidos.Finalmente, no se prevee la utilización de las Restriccionesde creación.Este framework implementa la especificación WS-Agreement y es posible interactuar con él a través deun portal web (ver Figura 5). Este portal ofrece loscampos a rellenar de una plantilla de negociación.Pulsando el botón “Submit”, la información de loscampos se transfiere a un SLA y es enviado al gestorde SLAs. El resultado de la petición se muestra alusuario a través del mismo portal, y si la emisión deltrabajo ha sido satisfactoria, devuelve el EPR (End-Point Reference) del acuerdo. La monitorización delos SLAs y la extensión del proceso de negociaciónrepresenta el próximo hito de nuestro trabajo.Hay varias ventajas que se desprenden del uso deSLAs en nuestro sistema, y especialmente de la implantaciónde la especificación WS-Agreement. Principalmente,representa una formalización del procesode emisión de trabajos. Además, son el mecanismopara una representación formal de las restriccionestemporales que el usuario requiere y que nuestro Gridtiene que respetar.Finalmente, los SLAs son mensajes XML (especificadoen WS-Agreement), por ello pueden ser fácilmentemanejados en entornos web. Además, tecnologíascomo Gridsphere [31] pueden ser utilizadaspara el desarrollo de nuevos entornos web. Para, deesta manera, ocultar la complejidad del sistema alusuario, el cual tiene la posibilidad de interactuarcon el Grid a través de un portal web.V. Conclusiones y Trabajo FuturoVarias investigaciones intentan proveer QoS enGrids mediante reservas por adelantado, aunque lareserva de recursos no siempre es posible en estos entornos.Por esto, este artículo propone un frameworkcon capacidad para negociar SLAs y planificar poradelantado para mejorar la QoS de los servicios ofrecidos.Sin embargo, este tipo de planificación requiereestimar si una aplicación puede ser ejecutada antesdel deadline especificado por el usuario. Por ello, esnecesario afrontar varios retos, como la predicción deltiempo necesario para la ejecución de los trabajos enlos recursos.Por este motivo, el sistema se ocupa del comportamientodinámico de los recursos asociados al Grid,su uso, y las características de los trabajos. Además,este sistema tiene en cuenta la precisión en las últimaspredicciones para calcular su confianza en cadarecurso.Además, implementa un gestor de SLAs para permitirla interacción con el usuario y ofrecer la capacidadde negociar SLAs entre usuario y proveedor deservicios. Este módulo se encarga de la comunicaciónentre el sistema, interactuando con el SA–Layer, y losusuarios; y hace posible proveer QoS a los usuarios deforma contractual (a través de los SLAs). Asimismo,cada SLA puede especificar más información relativaal trabajo que puede ser utilizada en el proceso demeta-planificación.Una interesante dirección a seguir en futuras investigacioneses el desarrollo de técnicas para mejorarlas estimaciones de los tiempos de transferencia.JP2011-487

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Protocolo de negociacióndefinido por WS-AgreementPor esta razón, es interesante intentar reservar anchode banda de la red, cuando sea posible. Además, eldesarrollo de algoritmos para planificar datos comosi de otro recurso se tratara es considerado trabajofuturo. Finalmente, otro punto sobre el que se planeatrabajar es la mejora del gestor de SLAs para hacermás eficiente la planificación teniendo en cuenta loscostes asociados o la reducción de energía.AgradecimientosEste trabajo ha sido apoyado conjuntamente por el MECy MICINN Español y la Comisión Europea (fondos FEDER)a través de los proyectos “Consolider Ingenio-2010 CSD2006-00046”, “TIN2009-14475-C04” y a través de una beca FPI asociadaal proyecto “TIN2009-14475-C04-03”. Conjuntamentecon la JCCM a través del proyecto “PII1C09-0101-9476”.Referencias[1] U. Schwiegelshohn and et al. Perspectives on gridcomputing. Future Generation Computer Systems,26(8):1104–1115, 2010.[2] E. Huedo, R. S. Montero, and I. M. Llorente. A modularmeta-scheduling architecture for interfacing with pre-WSand WS Grid resource management services. Future GenerationComputing Systems, 23(2):252–261, 2007.[3] J. Padgett, K. Djemame, and P. Dew. Grid-Based SLAManagement. In Proc. of the European Grid Conference(EGC), Amsterdam, The Netherlands, 2005.[4] V. Stantchev and C. Schröpfer. Negotiating and EnforcingQoS and SLAs in Grid and Cloud Computing. InProc. of the 4th Intl. Conference on Advances in Gridand Pervasive Computing (GPC), Geneva, Switzerland,2009.[5] AssessGrid. Web page at http://www.assessgrid.eu,Accedido: 1 de Abril, 2011.[6] EU-Brein. Web page at http://www.eu-brein.com/, Accedido:1 de Abril, 2011.[7] SLA@SOI. Web page at http://sla-at-soi.eu/, Accedido:2 de Abril, 2011.[8] A. Roy and V. Sander. Grid Resource Management,chapter GARA: A Uniform Quality of Service Architecture,pages 377–394. Kluwer Academic Publishers, 2003.[9] M. Siddiqui, A. Villazón, and T. Fahringer. Grid capacityplanning with negotiation-based advance reservationfor optimized QoS. In Proc. of the 2006 Conference onSupercomputing (SC), Tampa, USA, 2006.[10] O. Waldrich and et al. A meta-scheduling service for coallocatingarbitrary types of resources. In Proc. of the6th Intl. Conference on Parallel Processing and AppliedMathematics (PPAM), Poznan, Poland, 2005.[11] M. Dobber, R. van der Mei, and G. Koole. A predictionmethod for job runtimes on shared processors: Survey,statistical analysis and new avenues. Performance Evaluation,64(7-8):755–781, 2007.[12] P. A. Dinda. The statistical properties of host load. ScientificProgramming, 7(3-4):211–229, 1999.[13] H. Jin, X. Shi, W. Qiang, and D. Zou. An adaptive meta-Fig. 5. Portal Webscheduler for data-intensive applications. Intl. Journal ofGrid and Utility Computing, 1(1):32–37, 2005.[14] L. Tomás, A. C. Caminero, C. Carrión, and B. Caminero.Network-aware meta-scheduling in advance with autonomousself-tuning system. Future Generation ComputerSystems, 27(5):486–497, 2011.[15] A. Sulistio, U. Cibej, S. K. Prasad, and R. Buyya. GarQ:An efficient scheduling data structure for advance reservationsof grid resources. Int. Journal of Parallel Emergentand Distributed Systems, 24(1):1–19, 2009.[16] C. Castillo, G. N. Rouskas, and K. Harfoush. On thedesign of online scheduling algorithms for advance reservationsand QoS in grids. In Proc. of the Intl. Paralleland Distributed Processing Symposium (IPDPS), LosAlamitos, USA, 2007.[17] W. Theilmann and L. Baresi. Multi-level SLAs for HarmonizedManagement in the Future Internet, chapter Towardsthe Future Internet, pages 193–202. IOS Press,2009.[18] I. Brandic and et al. Advanced QoS Methods forGrid Workflows Based on Meta-Negotiations and SLA-Mappings. In Proc. of the 3rd Workshop on Work owsin Support of Large-Scale Science, Austin, USA, 2008.[19] J. Ejarque and et al. Exploiting semantics and virtualizationfor SLA-driven resource allocation in serviceproviders. Concurrency and Computation: Practice andExperience, 22(5):541–572, 2010.[20] A. Andrieux and et al. Web Services Agreement Specification(WS-Agreement). Technical report, 2007.[21] O. Waeldrich and et al. WS-Agreement Negotiation Ver.1.0. Technical report, 2011.[22] D. Davide Lamanna, J. Skene, and W. Emmerich. Slang:A language for defining service level agreements. In Proc.of the Intl. Workshop of Future Trends of DistributedComputing Systems, Los Alamitos, USA, 2003.[23] WSLA. Web page at http://www.research.ibm.com/wsla/, Accedido: 14 de Abril, 2011.[24] M. Parkin, R. M. Badia, and J. Martrat. A comparisonof sla use in six of the european commissions fp6 projects.Technical Report TR-0129, 2008.[25] WSAG4J. Web page at http://packcs-e0.scai.fraunhofer.de/wsag4j/, Accedido: 1 de Abril, 2011.[26] NextGrid. Web page at http://www.nextgrid.org/, Accedido:2 de Abril, 2011.[27] A. Caminero, O. Rana, B. Caminero, and C. Carrión.Network-aware heuristics for inter-domain metaschedulingin grids. Journal of Computer and SystemSciences, 77(2):262 – 281, 2011.[28] A. Di Stefano and et al. A P2P strategy for QoS discoveryand SLA negotiation in Grid environment. FutureGeneration Computer Systems, 25(8):862–875, 2009.[29] L. Tomás, A. Caminero, C. Carrión, and B. Caminero.Exponential Smoothing for network-aware metaschedulerin advance in Grids. In Proc. of the 6th Intl.Workshop on Scheduling and Resource Managementon Parallel and Distributed Systems (SRMPDS), SanDiego,USA, 2010.[30] D. Armstrong and K. Djemame. Towards Quality of Servicein the Cloud. In Proc. of the 25th UK PerformanceEngineering Workshop, Leeds, UK., 2009.[31] Gridsphere. Web page at http://www.gridsphere.org/,Accedido: 15 de Abril, 2011.JP2011-488

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011RSA@Cloud: Sistema de Criptoanálisis sobreInfraestructuras CloudAlberto Megía Negrillo 1 , Antonio Molinera Lamas 1 , José Antonio Rueda Sánchez 1 yJosé Luis Vázquez-Poletti 2Resumen—Este artículo describe un sistema queaprovecha las virtudes de la computación Cloud y elparalelismo para la factorización de números grandes, basede la seguridad del criptosistema RSA. Se demuestra que,mediante el uso de diferentes algoritmos matemáticos defactorización de números considerablemente grandes deforma paralela sobre varias máquinas en la infraestructurade Cloud público de Amazon, se puede alcanzar unresultado óptimo en términos de tiempo, coste y unamétrica que relaciona a ambos.Palabras clave—Cloud, RSA, criptoanálisis, paralelismo,Amazon.LI. INTRODUCCIÓNA criptografía es el estudio de los principios y lastécnicas por las cuales la información puedeocultarse en textos cifrados para después ser reveladapor usuarios autorizados empleando la clave privada,pero en el que es imposible o inviablecomputacionalmente para una persona que no estéautorizada para ello. Su objetivo principal, por tanto, esmantener en secreto un texto original, a salvo depersonas no autorizadas que intentan obtener lainformación de dicho texto.Se denomina criptoanálisis al conjunto de técnicas quese usan para recuperar los mensajes cifrados sinconocimiento de la clave. Los criptoanalistas tratan decomprometer la seguridad de un criptosistema.Un criptosistema [1] es una quíntupladonde „M‟ representa el conjunto de todos los mensajessin cifrar, ‘C’ representa el conjunto de todos losposibles mensajes cifrados, ‘K’ representa el conjunto declaves que se pueden usar en el criptosistema, ‘E’ es lafamilia de funciones que se aplica a cada elemento de‘M’ para obtener un elemento de ‘C’. Análogamente,‘D’ es el conjunto de transformaciones de descifrado, laoperación inversa a ‘E’. Todo criptosistema ha decumplir la siguiente condición:donde‘m’ es un mensaje original.Denominamos criptosistemas simétricos o de claveprivada a aquellos que emplean la misma clave tantopara cifrar como para descifrar textos. Loscriptosistemas asimétricos o de clave pública, por elcontrario, emplean una doble clave: una pública y otra1 Facultad de Informática, Universidad Complutense de Madrid,e-mail:[alberto.megia.negrillo|amlamas|jarueda]@estumail.ucm.es2 Dpto. de Arquitectura de Computadores, Universidad Complutensede Madrid, e-email: jlvazquez@fdi.ucm.esprivada, las cuales se usan para codificar y decodificarrespectivamente. En estos sistemas, el conocimiento dela clave pública no ha de permitir obtener la claveprivada.En la actualidad, el sistema RSA es el criptosistema declave pública más extendido. Su seguridad estáestrechamente ligada al problema de la factorización deun número entero, esto es, la dificultad para factorizarun número compuesto grande [2]. Hasta la fecha delpresente documento no se conoce un algoritmo defactorización de números enteros eficiente, y en elloreside la seguridad de RSA.La computación Cloud es un tipo de computaciónindependiente de la localización del usuario, en la queservidores compartidos proveen recursos, software y/odatos en función de la demanda deseada en cadamomento (capacidad conocida como escalabilidad), sinque el usuario tenga la necesidad de tener conocimientosacerca de los servicios que le son proporcionados [3].Esta tecnología se presenta como la evolución natural dela creciente expansión del empleo de la virtualización, lacomputación orientada a servicios y el concepto de éstacomo un servicio público más, como puedan ser el aguay la electricidad, entre otros.Este nuevo modelo significa la industrialización de lacomputación [4] y, por cuestiones económicas y detiempo, es una clara alternativa a los centros de datos.Éstos últimos siempre han permitido añadir o liberarrecursos, pero nunca se ha podido hacer con tal grado deautomatización y “a la carta” en función de lasnecesidades y circunstancias de trabajo.El servicio de la tecnología de computación Cloudrequiere una combinación de hardware y softwareencaminada a suministrar un servicio a un númeroconsiderable de usuarios. Dependiendo del servicioproporcionado, algunos elementos constituyentes sonconfigurados por el proveedor del servicio o se dejan adisposición de las necesidades del cliente: esta elecciónes dependiente de las diferentes capas de servicio:infraestructura, plataforma y software (IaaS, PaaS ySaaS) [5].Se necesitan importantes recursos físicos para tenercapacidad de cómputo y almacenamiento así como unared que encamine la información que estas máquinasprocesan hacia las terminales de los usuarios, sinimportar dónde se encuentren. También hace falta unsistema operativo que gestione dichos recursos paradotar a cada cliente de su propia máquina remotaconfigurada a su elección. Para ello, a bajo nivel debehaber una capa que soporte las tareas de múltiplesusuarios independientes que no son propietarios de laJP2011-489

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011máquina pero sí emplean una fracción de ella para sutrabajo: a este concepto se le llama virtualización [6].Este software simula la existencia de un conjunto demáquinas virtuales dentro de una misma máquina físicay a la vez monitoriza su estado a través de un hipervisor,que asigna recursos y establece prioridades a cada unade ellas.El objetivo del sistema presentado en este artículoreside en sentar las bases que permitan la ejecuciónparalela de cualquier implementación de un algoritmo defactorización de números en la nube. También sepretende demostrar el potencial de la computación ennube para desarrollar trabajos de investigación científica[7] o de ámbito empresarial de grandes dimensiones enun tiempo óptimo sin la necesidad de invertir sumasimportantes en la instalación de una infraestructurafísica de computación, implementando para ello unaherramienta que predice cuáles son los recursosnecesarios para desempeñar cierta tarea de formaóptima.Para describir el proceso de la consecución de éstospropósitos, se dará un breve repaso sobre los aspectosmás relevantes de este estudio. En la sección II sedescriben los algoritmos implementados para laestructura principal. A continuación se detallarán losdatos más significativos de la infraestructura Cloudempleada para computar esta tarea (Amazon EC2) en lasección III, para luego profundizar en la arquitectura enla que se divide el sistema implementado: „Engine‟ y„Forecaster‟ (sección IV). Por último, en las secciones Vy VI se dan a conocer tanto el análisis de los resultadosexperimentales como las conclusiones extraídas a partirde los mismos y el trabajo futuro.iteraciones, correspondientes a la cantidad de númerosque se comprueban.B. Criba cuadráticaEste algoritmo es más sofisticado que el anterior. Fuepublicado en 1981 por C. Pomerance [9], extendiendolos conceptos de „congruencia de cuadrados‟ [8] y la„Criba de Eratóstenes‟ [10].En él, buscamos números enteros ‘x’ e ‘y’ tales queperoPara encontrarestos resultados, jugamos con una función definidacomo y tratamos deencontrar suficientes de forma que el producto de suscorrespondientes valores sea igual a un cuadrado.Por lo tanto(1)Conseguidos los dos cuadrados, sólo nos quedacalcular el máximo común divisor de la suma o la restade ambos y del número a factorizar, obteniendo con unaprobabilidad de un factor no trivial de „n‟.El algoritmo se divide en cuatro fases:1. Configuración de parámetros.2. Proceso de criba.3. Construcción y reducción de la matriz.4. Solución.Para paralelizar este algoritmo se sigue la misma ideaque en la división por tentativa, creamos sub-intervalosde búsqueda sobre el intervalo de criba, con unas ligerasmodificaciones.(2)II. CRIPTOANÁLISIS: ALGORITMOSLos algoritmos implementados por el sistema son elalgoritmo de división por tentativa y la criba cuadrática.Se ha escogido el primero porque es altamenteparalelizable y, al ser eficiente únicamente paranúmeros pequeños , podemos estudiar ladistribución de sus cálculos en la nube y exponer losbeneficios obtenidos sobre dicho algoritmo. La eleccióndel segundo se debe principalmente a que permitetrabajar con tamaños de clave aún más grandes que en ladivisión por tentativa, y además se paraleliza de maneraanáloga a este.A. División por tentativaEs el algoritmo de factorización más fácil e intuitivo.La idea es buscar el número primo más pequeño ‘p’ quedivide a ‘n’, el número a factorizar, probando a dividireste último por todos los números primos desde el „2‟hasta ‘n’ [8].En la práctica, la propiedad más interesante de estealgoritmo es su facilidad para dividir el trabajo enbúsquedas sobre sub-intervalos de forma totalmenteindependientes, pudiendo asignar tareas de exploración adistintas máquinas, trabajando en paralelo.Para facilitar la paralelización, se comprueban todoslos números impares empezando desde el siguiente a „2‟,éste inclusive. El algoritmo ejecutaIII. INFRAESTRUCTURA CLOUD EMPLEADAUn ejemplo de enfoque típico de infraestructura Cloudes Amazon EC2 3 , basada en una colección de servidoresde propósito general conectados por red estándar de árealocal (LAN) mediante tecnologías de conmutación. Enla capa superior, el modelo de infraestructura comoservicio (IaaS) [5] se construye donde los usuariostienen acceso a los recursos del sistema, mediante redesvirtuales y los anteriormente mencionados servidores.Por otra parte, la plataforma de software devirtualización [6] es ampliamente considerada como elfactor clave para IaaS, ya que debe proporcionar a losusuarios un entorno de software estándar sencillo demanejar, además de un control “multi-tenancy” (o demúltiples clientes) a los administradores del servicio.La nube pública de Amazon EC2, ofrece sus serviciosdesde cinco regiones diferentes, dos estadounidenses,una europea y dos asiáticas. Amazon EC2 pone adisposición de sus usuarios una amplia gama demáquinas virtuales que pueden ser instanciadas endistintas modalidades. Dichas modalidades o tipos deinstancias dependerán de la memoria y del número denúcleos por máquina virtual como se detalla en la TablaI. El usuario puede escoger aquella que mejor se ajuste asus requisitos con respecto a la utilización de losrecursos. Cuando un usuario no precisa más de su uso,3 http://aws.amazon.com/es/ec2/JP2011-490

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011fácil integrarlo en ella mediante la elaboración desólo tiene que apagar la máquina virtual contratada. Sin4 http://aws.amazon.com/es/ec2/pricing/7 http://www.shoup.net/ntl/embargo, el acceso a una infraestructura de módulos „envoltorio‟ que ejecuten los nuevoscomputación casi infinita no es gratuito. Cada instanciaproporciona una cantidad planificada de capacidad decálculo dedicada, facturada por horas de uso.algoritmos.Además, la arquitectura está diseñada de tal forma que,aparte de trabajar con máquinas instanciadas de AmazonEC2, se puede hacer uso de cualquier otra máquinaTABLA ICARACTERÍSTICAS DE LAS DIFERENTES TIPOS DE MÁQUINASLinux a través de Internet.La arquitectura principal está desarrollada paraOFRECIDAS POR AMAZON EC2. U.C DEFINE LA UNIDAD DE CÁLCULOplataformas tipo Linux. La estructura está implementadaen lenguaje Perl, el cual facilita el manejo de archivos, yDE EC2 POR NÚCLEO, EQUIVALENTE A 1,0-1,2 GHZ DE UNse apoya en otros lenguajes como C/C++ para el diseñoPROCESADOR 2007 OPTERON O 2007 XEON.de los algoritmos de factorización.Tipo Maquina Núcleos U.C Memoria Plataforma Precio/ Cabe destacar la siguiente dependencia en la máquinahora cliente:SSH-PASS 5 — Utilidad diseñada para ejecutar SSHSmall 1 1 1.7 GB 32 bit $ 0.085 de forma no interactiva, esto es, sin necesidad deLarge 2 2 7.5 GB 64 bit $ 0.34introducir la autentificación cada vez que se realiza unaconexión entre dos máquinas. El módulo principalHigh CPUutiliza la versión „v1.04‟.2 2.5 1.7 GB 32 bit $ 0.17MediumLos algoritmos han sido implementados usando lassiguientes bibliotecas gratuitas:High CPU8 2.5 7 GB 64 bit $ 0.68 GMP 6 — Biblioteca para aritmética de precisiónExtra Largearbitraria, operaciones entre números enteros con signo,números racionales y números en coma flotante,necesaria para trabajar con grandes números. El tamañoLa métrica utilizada para la elección del tipo de límite lo impone la cantidad de memoria de la máquinamáquina que más se adecúa a la ejecución de nuestros en la que se trabaja. Ideal para aplicacionesalgoritmos se escoge en función del tiempo, coste y criptográficas. El módulo principal utiliza la versiónrendimiento.„v5.0.1‟.Como veremos más adelante, el tiempo de uso NTL 7 — Librería de alto rendimiento implementadadepende del número a factorizar y de la máquina virtual en C++ que provee estructuras de datos y algoritmos(número de núcleos, unidades de cálculo, etc.). El coste para manipular enteros de longitud arbitraria y conde la utilización de las máquinas por hora difiere según signo, además de matrices, vectores, polinomios sobrela región escogida 4 . Para el desarrollo de nuestros enteros y sobre campos finitos. Es perfectamentealgoritmos hemos escogido máquinas virtuales de la integrable con GMP para aprovechar las característicasregión de Virginia del Norte, debido a su precio más de rendimiento de este.económico. El rendimiento es el coste dividido por el El „Engine‟ se divide en dos partes:tiempo, por tanto la elección de la máquina virtual más 1. Conexión. En la primera parte, se realiza laadecuada será aquella que tenga mejor rendimientoconexión entre el cliente y los distintossegún la naturaleza de cada algoritmo.servidores. Inicialmente se establece unaconexión segura y no interactiva con todas ellosIV. ARQUITECTURA DEL SISTEMALa arquitectura del sistema se divide en dos módulosindependientes: „Engine‟ y „Forecaster‟.A. ‘Engine’mediante el intercambio de claves RSAgeneradas en el momento para después copiarel ejecutable del algoritmo de factorización atratar y el envoltorio que lanza dichoejecutable.El módulo principal distribuye distintas tareas entretodas las máquinas disponibles, a las cuales se accedemediante la lectura de un archivo que contiene su2. Tareas. En la segunda parte se distribuyen entrelos servidores de forma cíclica las distintastareas en las que se ha dividido el problemadirección IP y la dupla usuario/contraseña del sistema.para su correspondiente algoritmo deSe basa en un modelo cliente-servidor, en el cual lamáquina en la que reside la aplicación será denominadacliente y el resto de máquinas que ejecutan el algoritmode factorización tendrán el rol de servidores.factorización. Cada vez que una tarea escompletada por un servidor, éste envía unfichero de resultados al cliente. Cuando elfactor es encontrado, se detiene la ejecución.Para mantener con carga de trabajo todos los núcleosB. ‘Forecaster’de la CPU de cada servidor, el sistema desarrolla unaasignación dinámica de las tareas en el cual se verifica el Este módulo proporciona una herramienta muy útilestado (libre u ocupado) de cada núcleo que garantiza un para calcular una estimación de cuantas máquinas demáximo aprovechamiento de los recursos.Amazon EC2 se deben contratar y/o durante cuántoSu diseño es modular, por lo que si se desea tiempo para realizar una tarea de factorizaciónimplementar un algoritmo de factorización nuevo es5 http://sourceforge.net/projects/sshpass/6 http://gmplib.org/JP2011-491

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011determinada en función de uno de los siguientesparámetros: tiempo, número de máquinas disponibles,presupuesto disponible, o la mejor relacióncoste/rendimiento.Tras configurar las preferencias, el programa nosmuestra un gráfico que determina la relación entre laclave y el tiempo necesario para obtener sus factores yun informe con los resultados en función de los datos deentrada.Distinguimos cinco estrategias de predicción según elparámetro de estimación indicado. En todas ellas elusuario deberá indicar el tipo de máquina a utilizar, osolicitar el tipo de máquina con el que se consigue elresultado óptimo. Las estrategias son:Tiempo — El usuario introduce el tiempo máximo(en horas) que tendrá el algoritmo de factorizaciónindicado para procesar una clave elegida por élmismo. Como salida se muestra el número demáquinas virtuales mínimo y su coste asociadopara dicho límite temporal.Número de máquinas — En este caso se introduceel número de máquinas que se desea utilizar en lafactorización y la clave a factorizar. Como salidaobtenemos el tiempo y precio necesarios para laclave dada con dicho número de máquinas.Coste — Como su propio nombre indica, estaestrategia estima el número de máquinas y eltiempo que necesita ese número de máquinas enfactorizar la clave con el coste límite elegido por elusuario.Óptima (C/R) — En esta modalidad se realiza unasimulación óptima. De entre todas lasconfiguraciones de tipo y número de máquinas,elige la que tiene la mejor relacióncoste/rendimiento. Este concepto se explicará en elsiguiente apartado.Manual — En esta estrategia se da total libertad alusuario para configurar los parámetros de lapredicción, incluido el tamaño de las subtareas enla que se divide el trabajo total.V. RESULTADOS EXPERIMENTALESPara llevar a cabo los experimentos relacionados conla estimación del tiempo y presupuesto que requierecierta tarea representativa, primero llevamos a cabo elestudio del comportamiento del algoritmo de la divisiónpor tentativa en cada tipo de máquina de Amazon. Paraello, se escogen distintos tamaños de clave y se ejecutael algoritmo, obteniendo la recta de regresión queexplica su comportamiento. Los resultados estánrecogidos en la Figura 1.Fig. 1. “Tiempos de ejecución del algoritmo división por tentativa paradiferentes tamaños de clave en las máquinas instanciadas deAmazon. Éstas funciones expresan la relación entre el número defactores que se deben probar para una clave determinada y elnúmero de horas de ejecución”Una vez definida la recta de regresión que describe elcomportamiento del algoritmo en cada tipo de instanciapara tareas individuales, se puede generalizar laecuación del tiempo total T para el modelo deparalelización resultante de dividir el trabajo defactorizar cierta clave en un determinado número desubtareas mediante la siguiente ecuación:Donde es la función resultante de lasregresiones obtenidas en la Figura 1, I e i son elintervalo total y el intervalo procesado en cada subtarearespectivamente, es el número de máquinasvirtuales instanciadas en el experimento y elnúmero de núcleos de cada instancia.El tiempo total de ejecución no es la única condición atener en cuenta a la hora de elegir una configuraciónóptima. Es necesario establecer una relación entre eltiempo T y su coste asociado, cuyo valor resultante es:Donde es el coste del uso del tipo de instanciaelegida por hora tal y como se describe en la Tabla 1. Ala variable T se le aplica la función techo debido a quelos precios corresponden a cada hora de uso de lamáquina solicitada.La configuración óptima está determinada por labúsqueda de un compromiso entre el tiempo y el costedenominado Coste/Rendimiento (C/R) [11]. Estarelación se obtiene al multiplicar ambos parámetros y laconfiguración más conveniente corresponde a su valormínimo:(3)(4)(5)Donde las variables corresponden a las fórmulas 3 y 4y a la instancia seleccionada.El valor óptimo de C/R se alcanza cuando el númerode instancias utilizado hace que el tiempo de uso de cadamáquina instanciada sea exactamente de una hora.JP2011-492

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Tras obtener el mejor C/R para cada máquina,podemos evaluar cuál de ellas es mejor y averiguar elnúmero de máquinas virtuales necesarias para el trabajototal en el mejor caso con la expresión anterior. El valorde I está determinado por el tamaño de la clave, cuyovalor es igual a. (6)Para estas estimaciones, el tamaño de cada tarea „i‟ hasido:(7)Los valores mínimos de C/R se alcanzan con diferentenúmero de máquinas según el tipo de instancia elegido.La Figura 3 muestra los valores de C/R y número demáquinas virtuales óptimos para el ejemplo considerado.Los valores del coste son muy aproximados al valor deC/R obtenido ya que el tiempo está ajustado aaproximadamente una hora (0.95 horas = 57 minutos).Donde „k’ es el número de tareas asignadas a cadanúcleo de cada máquina. Tras considerar distintosvalores para ‘k’ llegamos a la conclusión que cuantomayor sea su valor, mejor será el rendimiento de lamáquina, ya que el tiempo de ejecución resultante T esmenor. Esto deriva en un menor valor de “i” y por tantomás subtareas y transferencias de archivos de lasmismas, por lo que se ha limitado el aumento del valorde ‘k’ de tal manera que el producto(elnúmero de tareas por máquina) sea 120 para evitar unexceso de tráfico de archivos resultado entre lasmáquinas, de tal forma que no se superen un margen de3 minutos permitido en el caso de que cada transacciónimplique un valor aproximado de un segundo de retardo.Se establece una franja de seguridad de un minuto,dejando dos minutos para transferencias entre máquinas.Para valores de claves muy grandes el número deinstancias necesarias puede ser muy elevado, lo cualimplica un problema: Amazon EC2 sólo permiteinstanciar un número máximo de 20 máquinas a la vez.Para la adquisición de más instancias ha de solicitarse aAmazon mediante un formulario justificando lanecesidad de las mínimas.En la Figura 2 se puede ver un ejemplo de búsquedadel tipo de instancia óptima para una clave. En ellaobservamos que al mayor uso de instancias mejor C/R.Pero a partir del momento en que se alcanza el valoróptimo de C/R, éste empieza a crecer, haciendoineficiente el uso de más instancias.Fig. 2. “Comparación de C/R para todas las instancias de AmazonEC2, para una clave igual a 57695605808471080739826972481, ycon un valor k de 120. La gráfica del interior ilustra los puntos devalor óptimo de C/R para los cuatro tipos de instanciasestudiadas.”Fig. 3. “Comparación de C/R óptimo fijando el tiempo de ejecución en57 minutos para todas las instancias de Amazon EC2, para losmismos valores de clave y k de la Figura 2.”Analizando las instancias de tipo „Small‟ y „Large‟ seobtienen valores C/R similares, pero el número deinstancias de tipo Small cuadruplica al número demáquinas de tipo „Large‟, debido a que el número deunidades de cálculo EC2 en la instancia „Large‟ es 4,mientras que la „Small‟ consta sólo de una unidad. Estarelación entre unidades de cálculo puede observarsetambién entre la familia de instancias „High CPU‟, conuna proporción de unidades de cálculo de uno a cuatro,para la ‟Medium‟ respecto de la „Extra Large‟.Elegir un tipo de instancia se traduce a elección depagar más por la infraestructura o disminuir el nivel deparalelismo. Viendo la Figura 3, la instancia de tipo„Small‟ es la solución más cara pero con el mayornúmero de núcleos trabajando simultáneamente (6711).En la instancia tipo „Large‟ el número de núcleos es lamitad (3374), pero con un coste similar. Las instanciasde tipo „High CPU‟ realizan la misma tarea con unnúmero de núcleos similar a la instancia „Extra Large‟,sin embargo el coste es mucho menor. En concreto elprecio para „High CPU Medium‟ es $267,42, y para„High CPU Extra Large‟ es $287,65.Observando los resultados obtenidos, determinamosque el tipo de instancia óptima es la „High CPUMedium‟, debido al mayor aprovechamiento de lacapacidad de cálculo de sus núcleos. Con respecto a lasinstancias „Large‟ y „High CPU Extra Large‟ seconsigue realizar la tarea de factorización con un costemás económico empleando un número de núcleossimilar.VI. CONCLUSIONES Y TRABAJO FUTUROLa computación Cloud es el paradigma de lacomputación distribuida que reúne las mejores virtudesde las tecnologías desarrolladas sobre este campo, talescomo los modelos de clúster, Intranet Computing,Internet Computing, P2P y Grid [12]. Esta nuevatecnología, gracias al desarrollo de la virtualización, laarquitectura de red orientada a servicios e Internet,JP2011-493

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011es que dispone de 33.5 unidades de cálculo, muy porpermite un alto grado de rendimiento y disponibilidad,8 http://aws.amazon.com/hpc-applications/#HPCEC2balanceo de carga y escalabilidad así como elasticidad,lo que permite personalizar la cantidad de recursosdisponibles rápidamente, dando una sensación de accesopor demanda a recursos de computación infinitos. Unencima de todos los tipos vistos anteriormente. Suaplicación en el campo de la factorización reduciríaconsiderablemente los tiempos de ejecución de cadatarea.rendimiento medio mayor, unido a la posible Por último, y motivado por la amplia oferta en elportabilidad de la información y el ahorro que supone noabordar gastos de mantenimiento y actualización sonotras cualidades que posicionan esta tecnología a lavanguardia de la computación distribuida.En la actualidad, el criptoanálisis de un sistema RSAmercado de computación Cloud, se extenderá lafuncionalidad del „Forecaster‟ a otros proveedoresdistintos de Amazon, como pueden ser Windows Azure(Microsoft), Salesforce, Netmagic y Google, entre otros,así como se adaptará la predicción al uso de distintossigue requiriendo enormes cantidades de potencia tipos de máquinas a la vez, favoreciendo lacomputacional. La computación Cloud nos abre unanueva ventana hacia la factorización eficaz ofreciendoheterogeneidad de la infraestructura y obteniendomejores resultados para la métrica C/R.acceso a dicha capacidad de cálculo bajo demanda delusuario, dándole la posibilidad de saber en cadaVII. AGRADECIMIENTOSmomento el precio de la potencia demandada.Esta investigación ha sido financiada por los proyectosNuestro sistema puede ser utilizado para evaluar laHPCcloud (TIN2009-07146) y MEDIANETseguridad de una clave RSA determinando el coste(S2009/TIC-1468).necesario para comprometer su resistencia.El uso del Cloud para la paralelización de tareas,VIII. REFERENCIASsupone grandes ventajas y mejoras, sobre todo en[1] M.J. Lucena López, Criptografía y seguridad en computadores,función del tiempo, ya que permite a cualquier usuarioversión 4-0.7.51. 11 de Junio de 2008. Universidad de Jaén.un mayor acceso de capacidad de computación. En [2] J. Buchmann, Introduction to Cryptography, Second Edition.nuestro sistema se puede observar como la factorización ISBN: 978-0-387-21156-5.de números grandes, en concreto de claves RSA, [3] Lutz Schubert ,The Future of Cloud Computing Opportunities forEuropean Cloud Computing Beyond 2010. Public Version 1.0,conlleva demasiado tiempo. Este tiempo se reduce de2010.forma considerable con el empleo de Cloud.[4] R. Buyya, C. Shin Yeo, S. Venugopal, J. Broberg & I. Brandic,Por otra parte, con vistas a continuar la investigación Cloud computing and energing IT plataforms: Vision, hype, andde algoritmos de factorización sobre infraestructuras reality for delivering computin as the 5th utility, FutureGenetarion Computer Systems vol. 25, Issue 6, Pag. 599-616,Cloud, el sistema desarrollado dispone de un altoJune 2009.potencial en cuanto a posibilidades de ampliación, [5] M. Armbrust, A. Fox, R. Griffith, A.D. Joseph, R. Katz, A.gracias a que el „Engine‟ está diseñado de forma Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, & M.modular, lo cual permite la inclusión de diferentes Zaharia. A view of Cloud Computing, Communications of theACM, vol. 5 3 no. 4., April 2010programas ejecutables en el que se implementen otros[6] R. Figueiredo, P.A. Dinda, J. Fortes, Guest Editors' Introduction:algoritmos matemáticos destinados a factorizar números Resource Virtualization Renaissance, Computer, vol.38, no.5,de aún mayor magnitud que la división por tentativa y la pp. 28- 31, May 2005.criba cuadrática, como por ejemplo el GNFS. La [7] G. Juve, E. Deelman, K. Vahi, G. Mehta, B. Berriman, B.P.Berman, P. Maechling, Scientific workflow applications oninclusión de uno o varios nuevos algoritmos a elegir enAmazon EC2, Workshop on Cloud-based Services andel „Forecaster‟ supondría aún menos dificultades.Applications in Conjunction with 5th IEEE InternationalAdemás, dado el carácter multiplataforma de los Conference on e-Science, e-Science‟09, 2009.lenguajes empleados (Perl, C, Java) para el desarrollo de [8] Arjen K. Lenstra, Integer Factoring, Designs, Codes andCryptography, 19, 101-128, 2000.los diferentes módulos de los que consta el sistema, sería[9] C. Pomerance, The Quadratic Sieve Factoring Algorithm,muy provechoso y relativamente sencillo adaptar el Departament of Mathematic, University of Georgia. Eurocript,sistema a un entorno independiente de la plataforma y de 1981.la arquitectura en el cual el cliente y los servidores se [10] C. Pomerance, A Tale of Two Sieves, 1996.[11] J.L. Vazquez-Poletti, G. Barderas, I.M. Llorente, P. Romero. Acomunicasen entre sí sin importar el sistema operativoModel for Efficient Onboard Actualization of an Instrumentalde las distintas máquinas (UNIX, Windows, Mac).Cyclogram for the Mars MetNet Mission on a Public CloudGracias a la modularidad de la plataforma, se Infrastructure. In Proc. PARA2010: State of the Art in Scientificdesarrollarán otros algoritmos de factorización capaces and Parallel Computing, Reykjavik (Iceland), June 2010, LectureNotes in Computer Science, Volume in press, 2011.de aprovechar los beneficios de la nube para la[12] I. Foster, Yong Zhao, I. Raicu, S. Lu, Cloud Computing and Gridparalelización de sus cálculos. Uno de los algoritmos Computing 360-Degree Compared, Grid Computingmás interesantes para esta tarea es GNFS („General Environments Workshop, 2008. GCE „08, vol., no., pp.1-10, 12-Number Field Sieve‟ / Criba General en el Campo de 16 Nov. 2008.Números), que es más rápido que la Criba Cuadráticapara tamaños de clave superiores a 110 dígitos.Amazon nos da la posibilidad de utilizar una nuevafamilia de instancias, lanzada en el año 2010 ydenominadas “Instancias de cálculo en clúster 8 ”,especialmente adecuadas para aplicaciones de cálculo dealto rendimiento (HPC). Su característica más relevanteJP2011-494

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Descripción de la Plataforma Formiga CloudFernando Gomez-Folgar 1 , Javier López Cacheiro 1 , Carlos Fernández Sánchez, 1 AntonioGarcia-Loureiro 2 , Raúl Valin 2 y Víctor Fernández-Albor 3Resumen— En la actualidad, diversos organismospúblicos, como universidades, institutos y colegios,disponen de elevados recursos computacionales, principalmenteen sus aulas de informática, que acumulanuna gran potencia computacional. Su utilizaciónqueda restringida única y exclusivamente a sus respectivosusuarios, por lo que su aprovechamiento esrelativamente bajo, teniendo en cuenta su potencialde uso.La creación de una infraestructura común que permitaagregar los recursos computacionales de diversasorganizaciones, utilizando las tecnologías Cloud yGrid, posibilitaría su reutilización para efectuar tareasde cálculo de distintas áreas de investigación,y por otra su uso en los procesos de enseñanza yaprendizaje, por medio del despliegue de máquinasvirtuales creadas de forma específica por los profesoresque imparten diferentes cursos.En este trabajo se presenta la plataforma FormigaCloud que tiene por objetivo la agregación de los recursoscomputacionales de diversas organizaciones enuna infraestructura Cloud común accesible desde unainterfaz Web única. Esta interfaz facilitará a los administradoresla gestión de la plataforma, y a los profesoresy alumnos la gestión de sus propios recursosvirtuales. La arquitectura de esta nueva infraestructurase presenta en este artículo.Palabras clave— Cloud computing, Grid, simulación,virtualización.I. IntroducciónCON el elevado incremento de la potencia de loscomputadores tanto organismos públicos comoempresas disponen de ordenadores que acumulan unagran potencia computacional. Sólo la Universidad deSantiago de Compostela (USC) dispone de 1800 ordenadoresen sus aulas de informática. Durante elproyecto Formiga se desarrolló una plataforma gridvirtual que permite la reutilización de estos ordenadoresen tareas de cálculo científico [1], [2]. Estaplataforma fue implantada con éxito en las aulas devarias facultades de la Universidad de Santiago deCompostela, y fue puesta a disposición de los investigadorespara realizar, entre otras, simulaciones detratamientos de radioterapia, nanodispositivos, asícomo cálculos de dinámica molecular.Hoy en día, las tecnologías Cloud están siendo objetode interés tanto para las organizaciones públicascomo para las privadas [3], lo que ha permitido unrápido desarrollo de las mismas. Debido al auge deestas tecnologías [4]-[9] es posible proporcionar funcionalidadesadicionales a la plataforma Formiga permitiendoofrecer la infraestructura como un servicio(IaaS). Formiga Cloud es una nueva plataforma que1 Dpto. de Sistemas, Centro de Supercomputación de Galicia(CESGA), e-mail: (fgfolgar, jlopez, carlosf)@cesga.es.2 Dpto. de Electrónica y Computación, Universidad de Santiagode Compostela, e-mail: (antonio.garcia.loureiro,raul.valin)@usc.es.3 Grupo de Física de Partículas, Universidad de Santiago deCompostela, e-mail: victormanuel.fernandez@usc.es.permitirá agrupar recursos físicos de diferentes institucionesu organizaciones bajo una nueva infraestructuracomún compartida, accesible desde una interfazWeb 2.0 única.La plataforma Formiga Cloud no sólo permitirá larealización de cálculos científicos, sino también cursosen los que los alumnos podrán desplegar unamáquina virtual previamente creada por el profesoro incluso crear una propia. Además, permitiráque los alumnos situados en aulas que cuentan conequipos informáticos modestos realicen sus prácticasempleando, de forma sencilla, nodos de computaciónmás potentes que se encuentren en lugares remotos,sin la necesidad de cambiar físicamente de ubicación.De este modo, se fomenta la reutilización de los recursoscomputacionales disponibles.En este artículo se describe la plataforma FormigaCloud y su estructura es la siguiente: En la secciónII se describe el diseño de la plataforma. La secciónIII presenta el gestor CloudStack, empleado paraconstruir la plataforma Formiga Cloud. A continuación,en la sección IV se describe el portalDIRAC, que es el middleware que permite la uniónde la plataforma Formiga Cloud con la infraestructuragrid. La sección V describe las redes de interconexiónde la plataforma y, finalmente, se presentanlas conclusiones en la sección VI.II. Diseño de la plataforma Formiga CloudFormiga Cloud es una plataforma que empleará lastecnologías Grid y Cloud y que permitirá a distintasorganizaciones unirse en una infraestructura común,de tal forma que el administrador de cada sitio podrágestionar sus recursos a través del portal FormigaCloud. Además, la plataforma Fomiga Cloud permitiráa los investigadores ejecutar cálculos científicos,y a los profesores y alumnos la realización de cursosmediante la utilización de Máquinas Virtuales (MVs)a medida.La plataforma Formiga Cloud presenta los siguientescasos de uso:Administradores: Los administradores de las aulaspodrán gestionar sus recursos en la plataformaFormiga Cloud. Para ello, dispondrán de una interfazsencilla.Profesores: Los profesores de los cursos que seimparten en las aulas de informática podrán gestionarsus máquinas virtuales y la distribución deéstas, es decir, podrán efectuar el despliegue de unnúmero de ellas a su elección, así como las plantillasde éstas. Además, dispondrán de una interfazsencilla que les permitirá efectuar la gestión de susrecursos virtuales.Alumnos: Los alumnos podrán gestionar susJP2011-495

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011máquinas virtuales; además, podrán controlar lasplantillas de éstas y dispondrán de una interfaz sencillaque les permitirá efectuar la gestión de estoselementos.Investigadores: Los investigadores podrán ejecutary gestionar sus propios trabajos de cálculocientífico, gracias a la interoperabilidad de laplataforma con la infraestructura grid.La arquitectura de la plataforma Formiga Cloud semuestra en la figura 1 y está formada principalmentepor tres componentes:• Gestor CloudStack• Portal grid DIRAC• Gestor de la red de interconexiónEn las siguientes secciones veremos en más detallecada uno de ellos.Fig. 1.Arquitectura Formiga Cloud.III. Gestor CloudStackEn la actualidad, existen diversos gestores Cloud“open-source” que permiten crear Clouds privados,públicos e híbridos, como, por ejemplo, OpenNebula[10], Eucalyptus [11] y CloudStack [12]. Despuésde haber efectuado un estudio de evaluación y comparaciónentre los gestores Cloud [13] mencionadosanteriormente, se ha seleccionado CloudStack comogestor Cloud para la plataforma Formiga Cloud, pordisponer de una interfaz Web sencilla y completa, asícomo múltiples modos de configuración de la red delas MVs. Ambas funcionalidades son fundamentalespara la plataforma Formiga Cloud.Hay que señalar que CloudStack es una plataforma“open-source” de Cloud desarrollada por Cloud.com,que permite implementar cualquier tipo de Cloud:público, privado e híbrido.CloudStack gestionará los recursos físicos de laplataforma Formiga Cloud de forma elástica, incluyendola creación, el despliegue y la configuraciónde las nuevas zonas pertenecientes a las organizacionesque se adherirán a la plataforma, así como lainstalación y gestión de las MVs que se ejecutaránen la nueva infraestructura común.A continuación, se efectúa una descripción de laarquitectura de CloudStack y sus funcionalidades.También se presenta un componente adicional queserá necesario desarrollar dentro del proyecto ycuya función será la adaptación de CloudStack a laplataforma de aulas de informática.A. Arquitectura de CloudStackCloudStack está formado a su vez por cinco componentes,como se muestra en la figura 2: Nodos deComputación (NC), Clústeres, Pods, Zonas de disponibilidady el Servidor de Gestión.Los nodos de computación son los recursos computacionalesque tienen instalado alguno de los hipervisoressoportados por la plataforma y que permitenejecutar las Máquinas Virtuales (MV). Representanbloques básicos que permiten escalar la capacidad delCloud. El administrador tiene la potestad de poderañadirlos en cualquier momento para proporcionaruna mayor capacidad para albergar MVs. Los nodosde computación no son visibles para el usuariofinal (profesores y alumnos) y, por lo tanto, éste nopodrá determinar en cuál de ellos se está ejecutandosu MV.Los clústeres representan el segundo nivel para elescalado físico. Un clúster es un grupo de nodos decomputación que emplean el mismo hipervisor y que,además, comparten el mismo almacenamiento primario.Los Pods representan el tercer nivel para el escaladode los recursos. Un Pod es simplemente unacolección de clústeres.Las zonas de disponibilidad están formadas poruna colección de Pods e implican algún tipo de aislamientofísico y redundancia. Destacar que existela posibilidad de que los propios administradores delas aulas den de alta sus propias zonas empleandoCloud Zone [12]. Ello les permitirá agregar sus recursoscomputacionales a la nueva plataforma y, a suvez, efectuar las tareas de administración. Hay queseñalar que las zonas de disponibilidad son visiblespara el usuario final.El servidor de gestión, mediante la interfaz Web,permite gestionar el Cloud por completo.B. FuncionalidadesEn este apartado vamos a analizar las funcionalidadesdesde el punto de vista de los usuarios, loshipervisores soportados, el almacenamiento, las redesde las máquinas virtuales, las máquinas virtuales, lasinterfaces de gestión y los agentes de computación.Usuarios: CloudStack permite gestionar tres rolesde usuario: administrador CloudStack del dominioraíz, administrador CloudStack de dominio y usuariosno privilegiados.El administrador del dominio raíz puede efectuarlas tareas administrativas de todo el Cloud deFomiga Cloud.JP2011-496

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2.Arquitectura CloudStack.El administrador de dominio puede efectuar las tareasadministrativas para los usuarios pertenecientesúnica y exclusivamente a su dominio.Los usuarios no privilegiados, en nuestro caso profesoresy alumnos, podrán gestionar sus propios recursosvirtuales, como, por ejemplo, sus máquinasvirtuales.Hipervisores soportados: CloudStack soporta loshipervisores KVM [15], Xenserver [14] y VMwarevSphere [16].Almacenamiento: CloudStack emplea dos tipos dealmacenamiento: almacenamiento primario y almacenamientosecundario.El almacenamiento primario se emplea para almacenarel disco raíz de las máquinas virtuales, asícomo los volúmenes adicionales de datos. El almacenamientoprimario se registra con el clúster de losnodos de computación. Debe existir al menos unode ellos para cada uno de los clústers. Los discosraíz de los volúmenes de las MVs se crean enél de forma automática cuando los usuarios inicianlas máquinas virtuales, y se eliminan, también deforma automática, cuando éstos las destruyen. Losvolúmenes de datos de las MVs se pueden crear,conectar, desconectar y eliminar de forma dinámicabajo demanda.El almacenamiento secundario se emplea para almacenarplantillas, snapshots de MVs, así comoimágenes ISO. Debe estar ubicado en la mismazona de disponibilidad que las MVs a las que sirve.Además, debe haber exactamente uno por cada unade las zonas de disponibilidadRedes de las MVs: CloudStack proporciona a lasMVs distintos modos de red entre los que se incluyeel modo de red directo y el modo de red virtual.En el modo de red directo, las MVs obtienen lasdirecciones IP de la subred local, de tal forma que severían de la misma manera que una máquina físicade la infraestructura.En el modo de red virtual, CloudStack proporcionaun router virtual que actúa como puerta de enlacepara las MVs de cada una de las cuentas de usuario.El router virtual, además de efectuar NAT, proporcionalos servicios de DNS y DHCP a las MVs delusuario. Hay que señalar que, en el modo de red virtual,el router virtual puede configurarse para redireccionarel tráfico de Internet a las MVs a eleccióndel usuario. Por su parte, el tráfico de red de Internettambién puede balancearse entre un conjunto deMVs configurable por el usuario.Máquinas virtuales: CloudStack permite efectuarla instalación de las MVs por medio de la interfazWeb empleando una imagen ISO de instalación delsistema operativo. Las MVs emplean el formatoQCOW (Qemu Copy-On-Write). CloudStack proporcionala posibilidad de definir MVs de alta disponibilidadque se mantendrán activas sin intervenciónalguna por parte del administrador o del usuario.Además, hay que señalar que CloudStack permiteacceder a la interfaz gráfica de las MVs empleandola interfaz Web.Interfaces de gestión: CloudStack dispone de unainterfaz Web completa y sencilla. Ésta proporcionaráel acceso completo al Cloud de la plataforma FormigaCloud a los administradores del sistema, mientrasque para los profesores y los alumnos proporcionaráun acceso restringido que les permitirá, única y exclusivamente,gestionar sus respectivos recursos virtuales.CloudStack no dispone de interfaz de comandos,aunque proporciona una API REST que permiteacceder a todas sus funcionalidades.Agentes de computación: El agente de computaciónes un módulo que se instalará en cada unode los ordenadores de las distintas aulas y que permitiráa CloudStack efectuar la gestión del hipervisordel nodo de computación. Por tanto, el agente decomputación se encargará de gestionar las MVs quese encuentran bajo su supervisión y control.C. Planificador Formiga CloudLa adhesión en la plataforma Formiga Cloud de losrecursos computacionales pertenecientes a múltiplesorganizaciones, que emplean diferentes políticas deseguridad, de mantenimiento y de utilización de recursos,implica que no pueda garantizarse a priorisu disponibilidad para su utilización en la nueva infraestructuracomún.Los planificadores de despliegue de los gestoresCloud no están diseñados para tener en cuenta lasJP2011-497

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011particularidades de este entorno multiorganizacional,como, por ejemplo, la disponibilidad de los nodos enfunción del contexto de utilización de los mismos.El planificador FomigaCloud se integrará enCloudStack y se diseñó para adaptarse de forma automáticay trasparente a los entornos heterogéneos,y permitirá gestionar el despliegue de las máquinasvirtuales en los nodos de computación de la nuevainfraestructura común. Para ello, empleará técnicasheurísticas que permitirán determinar el nodo decomputación más adecuado en cada momento parala ejecución de las máquinas virtuales, teniendo encuenta el tiempo de disponibilidad de cada uno de losnodos de computación, esto es, el tiempo estimadodurante el cual se espera que el nodo de computaciónva a estar disponible para su utilización por parte dela nueva infraestructura común, así como el tiempode utilización en el pasado de las distintas máquinasvirtuales.A la hora de seleccionar el nodo en el que se desplegarála máquina virtual, el planificador emplearálos datos de la utilización en el pasado de los distintosnodos de computación, lo que permitirá estimarel tiempo de disponibilidad esperado para cada unode ellos. Análogamente, el planificador estimará eltiempo esperado que la máquina virtual permaneceráactiva, basándose en los datos históricos de su utilización,y seleccionará el nodo cuyo tiempo de disponibilidadesperado sea superior al tiempo requeridode utilización de la máquina virtual.Hay que señalar que uno de los usos principales dela plataforma será la realización de cursos medianteel despliegue de máquinas virtuales. Además, éstassuelen emplearse de forma periódica y se mantienenencendidas apenas unas pocas horas. Esta circunstanciapropicia que el planificador FormigaCloudpueda optimizar la utilización de aquellos nodos decomputación cuyo nivel de disponibilidad es bajo, albergandoaquellas máquinas virtuales que se adaptena su disponibilidad estimada, reduciéndose, así, elnúmero de migraciones necesarias de las MVs entrelos distintos nodos para mantenerlas en su estadooperativo. El planificador Formiga Cloud permitiráobtener el mayor nivel de servicio en infraestructurasen las que la disponibilidad de los nodos de computaciónno está garantizada.IV. Portal DIRACDIRAC (Distributed Infrastructure with RemoteAgent Control) [17] es un middleware grid que permitela gestión y el envío de trabajos de computacióna infraestructuras grid basadas en gLite [18], o mediantela utilización de sus propios recursos. DIRACproporciona una solución grid completa [19] para lagestión de los trabajos, así como para el almacenamientode los datos, y permite efectuar un usoconfiable de los recursos disponibles.En la plataforma Formiga Cloud, este portal seencargará de gestionar los trabajos de los investigadoresen la infraestructura grid virtual. Su integracióncon CloudStack hará posible la gestión bajodemanda de MVs configuradas como Worker Nodes(WN) de Grid.DIRAC posee su propio framework para facilitar laintegración con distintos tipos de sistemas basados enSOA, así como su propio protocolo de comunicaciónsegura, denominado DISET (DIRAC Secure Transport),que confiere una mayor seguridad al usuarioutilizando los mecanismos de autenticación de GSI(Grid Secure Infrastructure). Por otra parte, permitela configuración de reglas de autorización conla granularidad adecuada tanto para usuarios comopara grupos. Hay que señalar que DIRAC disponede un Servicio de Configuración (SC) que permitegestionar todos sus servicios y agentes. Éste se encuentraaccesible a través del portal Web DIRAC, yposibilita que el administrador pueda efectuar la configuraciónde servicios y funcionalidades de usuariospertenecientes a diferentes grupos.El WMS (Workload Management System) deDIRAC se ocupa de las tareas de la programaciónmediante la utilización de Genenic Pilot Jobs. Estemétodo de planificación, que soluciona muchos delos problemas causados por la utilización de recursoscomputacionales distribuidos inestables, consisteen la creación, con un certificado proxy de administrador,de un trabajo genérico denominado PilotJob por medio del cual se ejecutarán los trabajos deusuario.Algunos de los servicios más importantes deDIRAC, como son el sistema de gestión de datos,el servicio de monitorización, el central Job Monitoringy el Accounting Service, se describirán a continuación.El sistema de gestión de datos de DIRAC proporcionaa los usuarios un servicio de almacenamientoempleando el protocolo DISET, lo que le confiere seguridaden el almacenamiento de los datos. DIRACestá preparado para utilizar el denominado LCGFile Catalog [20] (Large Hadron Collider ComputingGrid File Catalog) que puede ser accesible a travésmúltiples servidores de sólo lectura. Además, poseesu propio File Catalog (FC) que se utiliza en el sistemade gestión de producción. El FC de DIRACdispone de la clase Replica Manager que permite encapsulartodas las operaciones relacionadas con lagestión y el manejo de archivos.El servicio de monitorización recopila los informesde actividad de todos los servicios de DIRAC y susagentes, y presenta los datos de múltiples formas,por ejemplo, gráficos históricos o informes agregados.Es interesante señalar que durante la ejecución deltrabajo hay un agente local ejecutándose en paralelocon la aplicación del usuario que tiene el cometidode enviar la información acerca del progreso de lamisma al servicio central Job Monitoring.El servicio central Job Monitoring recopila informaciónacerca del estado de los trabajos y la guardaen una base de datos en la que almacena todos losestados en los que se han encontrado aquellos.El Accounting Service efectúa la contabilidad deluso de los recursos a nivel de las cuentas de usuario.JP2011-498

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011El portal Web de DIRAC permite que el usuariopueda efectuar la monitorización de los trabajos yla descarga de sus respectivos archivos de salida quehan sido procesados en los nodos de cálculo. Porotra parte, el portal Web proporciona una interfazamigable y segura para la administración de DIRAC,así como para la gestión de producciones y trabajosde usuario.La interfaz de usuario de DIRAC proporcionaráa los investigadores una serie de comandos y scriptspara el envío, la monitorización y la gestión de trabajosen el Grid virtual de las aulas. La Interfaz deUsuario (IU) permitirá el envío de los trabajos pormedio de un canal seguro, mediante la creación de uncertificado de proxy en la propia máquina a partir delcertificado del usuario.V. Gestor de red de interconexiónLa adhesión a la plataforma Formiga Cloud de losrecursos computacionales pertenecientes a diversasorganizaciones presenta dificultades derivadas de lautilización de diferentes políticas de configuración ygestión de la red, como, por ejemplo, el empleo dedirecciones IP privadas o públicas.El gestor CloudStack requiere que las conexionessean iniciadas desde el servidor de gestión hacia losnodos de computación de las diferentes zonas de disponibilidad.En el caso de que los nodos de computaciónempleen direcciones IP públicas, el gestorCloudStack podría gestionarlos de forma directa sinmayores complicaciones, salvo las derivadas de la implantaciónde las medidas de seguridad necesariaspara evitar que los nodos pudiesen verse comprometidos.Sin embargo, este modo de comunicacióndel servidor de gestión de CloudStack imposibilitala conexión con los nodos de computación de aquellasinfraestructuras de red que emplean NAT comomedio de conexión a Internet. Además, algunas organizacionespodrían hacer uso del mismo rango dedirecciones IP privadas entre las diferentes aulas, encuyo caso el uso de VPNs, como medio de interconexiónde los nodos de computación con el servidorde gestión de CloudStack, no sería posible a causade los rangos IP solapados. Por ejemplo, el servidorde gestión de CloudStack por medio de la VPNse estaría intentando conectar a un nodo cuya direcciónIP privada pudiera estar siendo utilizada pormúltiples nodos de computación al mismo tiempo.Para solventar estas limitaciones se evaluará el usode Cloud Kit [21], que permite que sean los nodosde computación los que inicien la conexión con elservidor de gestión de CloudStack y no al revés. Deesta forma, no sería necesario efectuar modificaciónalguna en la infraestructura de red existente parapermitir que los nodos de computación de aquellasorganizaciones, cuyas redes empleen NAT para alcanzarInternet, puedan establecer la conexión conel servidor de gestión Cloud.Existe una complicación adicional causada por lautilización de NAT por parte de las MVs para alcanzarInternet, ya que los usuarios de las mismas nopodrían conectarse a sus servicios, como, por ejemplo,ssh, desde una red ajena a la infraestructura. Eneste caso, sería necesario proporcionar un mecanismoque les permitiese establecer la conexión y hacer usode estos servicios desde el exterior. Cabe destacarque se está trabajando con los desarrolladores deCloudStack para proporcionar la mejor solución enrelación a la conectividad del usuario final con suMV.VI. ConclusionesLa plataforma Formiga Cloud, empleando tecnologíasCloud y Grid, permitirá la agregaciónde los recursos computacionales de entornos heterogéneos,independientemente del modo de red utilizado(público o privado), en una infraestructuracomún accesible desde una interfaz Web centralizadaque facultará a los administradores gestionarla plataforma, y a los profesores y alumnos gestionarsus propios recursos virtuales.La plataforma Formiga Cloud empleará Cloud-Stack como gestor Cloud y DIRAC para gestionarlos trabajos de los investigadores. Sin embargo, losplanificadores de despliegue de los gestores Cloud noestán diseñados para tener en cuenta las particularidadesde este entorno multiorganizacional, como, porejemplo, la disponibilidad de los nodos en función delcontexto de utilización de los mismos. Por este motivo,se desarrollará el Planificador FormigaCloud,que empleará técnicas heurísticas que permitirán determinarel nodo de computación más adecuado, eneste entorno heterogéneo, para ejecutar las máquinasvirtuales. La integración de DIRAC con Cloud-Stack permitirá efectuar la gestión bajo demanda demáquinas virtuales configuradas como Worker Nodesde Grid.La plataforma Formiga Cloud permitirá elaprovechamiento de recursos computacionales infrautilizadospara su uso en tareas de cálculo, asícomo en los procesos de enseñanza y aprendizaje. Elobjetivo final es poder realizar un mejor uso de losrecursos computacionales disponibles por las organizaciones.AgradecimientosEl presente trabajo ha sido financiado por la Xuntade Galicia mediante los proyectos 09TIC001CT eINCITE08PXIB206094PR, y por el Gobierno deEspaña (MCYT) mediante el proyecto TEC2010-17320.Referencias[1] J. López et al., “FORMIGA/G-FLUXO: Adding computerlabs to the Grid”, 3rd Iberian Grid InfrastructureConference, Valencia, pp. 237-246, May 2009.[2] R. Valin et al., “Gridification of a nanodevice Monte Carlosimulator for the FORMIGA project”, 3rd Iberian GridInfrastructure Conference, Valencia, pp. 109-116, May2009.[3] K. Stanoevska-slabeva, T. Wozniak and S. Ristol, Gridand Cloud Computing: A Business Perspective on Technologyand Applications, Springer, Germany, 2010.[4] C. Babcock, Management Strategies For The Cloud Revolution,McGrawHill, USA, 2010.JP2011-499

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011[5] T. Mather, S. Kumaraswamy and S. Latif, Cloud Securityand Privacy, O’REILLY, Sebastopol, 2009.[6] B.J.S. Chee and C. Franklin, Cloud Computing. Technologiesand Strategies of the Ubiquitous Data Center, CRCPress, Boca Raton, 2010.[7] R.L. Krutz and R.D. Vines, Cloud Security, Wiley PublishingIndianapolis, 2010.[8] J.W. Rittinghouse and J.F. Ransome, Cloud Computing:Implementation, Management, and Security, CRC Press,Boca Raton, 2010.[9] A.T. Velte, T.J. Velte and R. Elsenpeter, Cloud Computing:A Practical Approach, McGrawHill, USA, 2010.[10] OpenNebula, http://opennebula.org[11] Eucalyptus, http://open.eucalyptus.com[12] CloudStack, http://www.cloud.com[13] F. Gomez-Folgar et al., “An Open-source Cloud ManagementPlatform Comparison”, 5th Open Cirrus Summit,Moscow, 2011. (Artículo aceptado).[14] D.E. Williams, Virtualization with Xen: Including XenEnterprise,XenServer, and XenExpress, Syngress, USA,2007.[15] KVM, http://www.linux-kvm.org[16] VMWare, http://www.vmware.com[17] A.Tsaregorodtsev et al, “DIRAC, The LHCb Data Productionand Distributed Analysis System”, Proceedings ofthe CHEP 2006 Conference.[18] gLite, http://glite.cern.ch[19] A.Tsaregorodtsev et al, “DIRAC: a community grid solution”,Journal of Physics: Conference Series, vol. 119-6,July 2008.[20] LCG FIle Catalog, https://svnweb.cern.ch/trac/lcgdm[21] RightScale, http://www.rightscale.comJP2011-500

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Planificación de trabajos MapReduce en clustersHadoop no-dedicadosAprigio Bezerra, Tharso Ferreira, Antonio Espinosa, Juan Carlos Moure y Porfídio HernándezResumen—A partir del análisis realizado de lasaplicaciones bioinformáticas de tipo read-mapping (DataIntensive Computing), en clusters Hadoop no-dedicados;nuestro trabajo se centra en la propuesta de planificadoresde trabajos para este tipo de entornos, que tengan encuenta las características de las aplicacionesbioinformáticas. Nuestra propuesta concreta deplanificación, consiste en aprovechar: por parte de lasaplicaciones, la necesidad de compartición de los archivos(genomas de referencia por las aplicaciones de readmapping)y por parte del entorno de planificación(framework Hadoop), la posibilidad de reutilización de lamáquina virtual Java, utilizada para la ejecución de lastareas MapReduce en los nodos de procesamiento. Todoello, sin comprometer el rendimiento de las aplicacioneslocales, ejecutadas en cada nodo.Nuestra propuesta muestra mejoras del 17%, cuando sele compara con la política por defecto del frameworkHadoop.Palabras clave—Hadoop, MapReduce, Read-Mapping,cluster no-dedicado, planificación de trabajos.LI. INTRODUCCIÓNas mejoras recientes en el ancho de banda y latenciapara redes LAN, la infrautilización de los entornosde estaciones de trabajo cuando se utilizanexclusivamente a tareas interactivas, y el bajo costo delos mismos, compitiendo en prestaciones con lossistemas masivamente paralelos (MPP); han hecho delos clusters de estaciones de trabajo, una arquitecturaatractiva para diversas cargas: secuenciales interactivasy paralelas.Por otro lado, los avances en los estudios genéticos estánproporcionando volúmenes de datos inmensamenteelevados, creándose repositorios de información queimplícitamente contemplan un conocimiento histórico denuestra evolución. Estos datos necesitan ser procesadosy analizados; y se ha hecho evidente, que el únicoentorno para darle solución es la Computación de AltasPrestaciones. Este nuevo tipo de aplicaciones, intensivasde datos y cómputo; abre una nueva línea deinvestigación; en el diseño de sistemas más adecuadospara su tratamiento, modelos de programación ygestores de recursos.La idea del trabajo tiene como objetivo, diseñar uncluster de naturaleza no-dedicada, con capacidad para laejecución eficiente de aplicaciones paralelas DIC, deltipo read-mapping; con prestaciones aceptables, sinperturbar en exceso la respuesta del sistema a la cargalocal de los nodos del cluster. Nuestra propuestaconcreta de planificación consiste en aprovechar: porparte de las aplicaciones; la necesidad de comparticiónde los archivos (genomas de referencia para lasDepartamento de Arquitectura de Computadores y Sistemas OperativosUniversidad Autónoma de Barcelona, Edif. Q. Campus UAB. 08193Bellaterra. Barcelona. abezerra, tsouza,aespinosa@caos.uab.esaplicaciones de read-mapping) y por parte del entornode planificación (framework Hadoop); la posibilidad dereutilización de la máquina virtual Java, utilizada para laejecución de las tareas MapReduce en los nodos deprocesamiento. La Figura 1 presenta un cluster Hadoopno-dedicado, con carga local y carga paralela inyectadaal cluster a través de una capa global de planificación detrabajos.Las siguientes secciones describen la propuestarealizada. La sección II presenta el paradigma deprogramación MapReduce [1]. La sección III describe elframework Hadoop [17][18], su sistema de archivosdistribuidos y como gestiona la ejecución de trabajos enun entorno paralelo. En la sección IV, se realiza unadescripción de aplicaciones de BioInformática del tipoRead Mapping [19] desarrolladas bajo el paradigma deprogramación Mapreduce, desarrollada por nuestrogrupo de investigación. En la sección V, se presenta lapolítica de planificación de trabajos propuesta. En lasección VI, se describen los experimentos realizados ylos resultados obtenidos. En la sección VII se presentanlas conclusiones del trabajo.Fig. 1. Entorno paralelo no-dedicado.II.MAPREDUCEMapReduce es un paradigma de programaciónorientado a datos, donde el programador especifica elflujo de tratamiento de los datos de entrada; esteprocesamiento, se especifica mediante la utilización dedos funciones: Map y Reduce que serán ejecutadas enparalelo.El paradigma MapReduce se expresa mediante laconstrucción de dos funciones: Map y Reduce, definidasambas con respecto a datos estructurados en pares(clave, valor). En la función Map los datos de entradason procesados y es generada una lista de paresintermedios (clave, valor). A continuación la funciónJP2011-501

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Reduce se aplica sobre estas tuplas intermedias y hace laagrupación de los valores que tienen la misma clave.La Figura 2, representa un esquema del flujo de datos,para la ejecución de una aplicación de contar palabras enun texto, utilizando el paradigma MapReduce.Fig.3 Framework Hadoop.Fig. 2. Esquema MapReduce para la aplicación WordCount en unCluster Hadoop.III.HADOOPHadoop es un framework altamente configurabledesarrollado en el proyecto Apache y que implementaMapReduce inspirado en la propuesta de Google [1] [3].Es un sistema de código abierto, e implementado enJava. Otras implementaciones del paradigmaMapReduce, han aparecido en la literatura paradiferentes arquitecturas como Cell B.E [4], GPUs [5] yprocesadores multi-core [6].El framework Hadoop realiza de forma automática ladivisión y distribución de los archivos de entrada, laplanificación de los trabajos entre los nodos del entornoparalelo, el control de fallos de los nodos y gestiona lanecesidad de comunicación entre los nodos del cluster.Hadoop se ejecuta sobre un sistema de archivosdistribuidos, Hadoop Distributed File System – HDFS,que se soporta a su vez sobre el sistema de ficherosnativo, y donde la fiabilidad del sistema es obtenida porla replicación de datos, y la posibilidad de poder utilizarejecución especulativa de las tareas. Son utilizados dosdemonios para hacer la gestión de los datos: namenode ydatanode. La arquitectura de planificación de Hadoopobedece a un modelo master/worker: Job Tracker (en elnodo master) y Task Tracker (en los nodos Workers). Elplanificador de trabajos está diseñado en móduloscargables que permite la implementación de nuevaspolíticas de planificación de trabajos y la sustitución deestos módulos de planificación de manera sencilla. LaFigura 3 muestra la distribución del sistema en un nododel cluster.A. Hadoop Distributed File System – HDFSHDFS es el sistema de archivos distribuidosimplementado por Hadoop y se monta en el sistema dearchivos de cada máquina del cluster. Cuando se cargaun archivo en el sistema, HDFS hace la división delarchivo en bloques menores con tamaño definido por elgestor del sistema (por defecto de 64 MB) bajo un factorde replicación, también definido por el gestor delsistema. Esta replicación de cada bloque de archivoademás de permitir un mejor control de tolerancia afallos, aumenta la posibilidad de garantizar la localidadde datos, cuando Hadoop hace la distribución de tareasen el cluster. La Figura 4 presenta una distribución debloques de un fichero de entrada, a lo largo de los nodosdel cluster.Fig. 4 Distribución de datos en HDFS.JP2011-502

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011B. Planificación de trabajos en HadoopLa planificación de las aplicaciones en Hadoop, serealiza de forma dinámica, siguiendo un modelomaster/worker para la distribución de tareas, a lo largode los nodos del cluster.La gestión de los trabajos en un cluster Hadoop serealiza por dos demonios: Job Tracker (en el nodomaster) y Task Tracker (en los nodos Workers). Lostrabajos MapReduce presentados al cluster soninyectados al sistema en una cola gestionada por el JobTracker. El orden de ejecución de estos trabajos esdefinido por la política de planificación de trabajos deHadoop. Por defecto esta política es basada en una coladel tipo FIFO.Los trabajos encolados son divididos por Hadoop en unconjunto de tareas Map y Reduce. Para cada tarea se leasocia una partición de los datos de entrada, que mapeala ubicación del bloque de archivo que se localiza enuno de los nodos del cluster. El planificador Hadoopintenta asignar las tareas a los mismos nodos, dondeestán ubicados los bloques de datos.Cuando un nodo del cluster está listo para empezar unatarea, envía un heartbeat al master (Job Tracker),informando de su estado. Posteriormente, Hadoop buscauna tarea que maneje un bloque de datos ubicado en elmismo nodo. Si no la encuentra, envía para el nodo laprimera tarea encolada. Si la encuentra, envía la tarea alnodo que hizo la solicitud. Para cada tarea recibida, eldemonio local (Task Tracker) crea una máquina virtualJava para ejecutarla. Cuando un nodo local finaliza sutarea, el Task Tracker elimina la maquina virtual einforma, a través de un heartbeat, de su estado al JobTracker, que realiza la asignación de una nueva tarea. LaFigura 5 presenta la planificación de trabajos en unentorno Hadoop.conteste al Job Tracker en un intervalo de tiempodeterminado, se marcará como en estado de fallo. Todaslas tareas Map que han sido iniciadas pero nofinalizadas, serán planificadas una vez más. Lasversiones más recientes de Hadoop, también hacencheckpoints periódicos de las estructuras de datosexistentes en el Job Tracker. En caso de que ocurra unfallo en este, se puede ejecutar un nuevo Job Tracker, apartir del último checkpoint realizado.IV.APLICACIONES DE BIOINFORMÁTICALas aplicaciones DIC, consideradas en este trabajo, sebasan en la búsqueda de similitudes entre secuenciasgenéticas localizadas en un archivo de referencia, y enun conjunto de archivos de consulta. Las aplicacionesread-mapping se caracterizan por manejar grandesvolúmenes de datos de entrada. El genoma humanocompleto consta de 3,7 Gigas de pares de bases, yademás, las secuencias genéticas existentes en losarchivos de consulta pueden ocupar centenas de Gigas oTerabytes en disco.Otra característica de las aplicaciones del tipo read -mapping es el fuerte paralelismo de datos. Es común deestos programas, dividir el archivo de consulta enarchivos menores. Cada archivo de consulta constituyeun trabajo independiente, aunque comparten el mismoarchivo de referencia, para realizar la búsqueda desimilitudes entre las secuencias genéticas.La Figura 6 presenta el flujo de datos para unaaplicación del tipo read-mapping desarrollada bajo elparadigma MapReduce, utilizando un archivo dereferencia de 4 Gigabytes, y un archivo de consulta de 5Megabytes.Fig.6 Flujo de datos de una aplicación read-mapping.V. POLÍTICA PROPUESTASe propone, una política de planificación de trabajosMapReduce en clusters Hadoop no-dedicados. Estapolítica de planificación deberá gestionar con reserva derecursos, la mezcla eficiente de cargas localescontroladas que varían en el espacio y tiempo, y cargasparalelas de aplicaciones DIC.Fig.5 Planificación de trabajos en Hadoop.Hadoop proporciona un mecanismo de control defallos. El Job Tracker, verifica periódicamente lafinalización de las tareas. En caso de que una tarea noNuestra propuesta concreta de planificación, consiste enaprovechar: por parte de las aplicaciones, la necesidadde compartición de los archivos (genomas de referenciapor las aplicaciones de read-mapping) y por parte delentorno de planificación (framework Hadoop), laposibilidad de reutilización de la máquina virtual Java,utilizada para la ejecución de las tareas MapReduce enlos nodos de procesamiento.JP2011-503

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A. Planificación de trabajos MapReduceLos trabajos paralelos se componen de aplicaciones debioinformática del tipo read-mapping desarrolladas bajoel paradigma MapReduce. Los distintos trabajoscomparten el mismo archivo de referencia. La políticade planificación propuesta intenta sacar provecho de estacaracterística utilizando afinidad entre tareas dediferentes trabajos. Cuando un nodo worker, envía unheartbeat al nodo master informando que está listo paraempezar una nueva tarea, Hadoop busca entre las tareasdel primer trabajo encolado, una tarea que aceda albloque de datos ubicado en este nodo. Si hay slots libresen el mismo nodo, la política propuesta evalúa lostrabajos encolados en busca de tareas que accedan almismo bloque del archivo de referencia. Si se encuentrauna tarea de otro trabajo que acceda el mismo bloque dedados de entrada, esta tarea también es asignada al nodoworker.Otra característica de la política propuesta es reutilizarlas máquinas virtuales Java para tareas distintas. Cuandoel demonio local – Tasktraker – inicializa una maquinavirtual Java para ejecutar una tarea, la política propuestapermite que esta máquina virtual sea reutilizada, cuandola tarea es finalizada en el nodo. El propósito de estacaracterística, es el ahorro de tiempo de arranque yfinalización de las máquinas virtuales Java,especialmente cuando hay un gran número de tareas aejecutar. La Figura 7 presenta un esquema de la políticade planificación propuesta.B. Reserva de RecursosGarantizar que las aplicaciones del usuario local no seven afectadas en sus prestaciones, implica la necesidadde reservar los recursos necesarios para su ejecucióneficiente.La técnica propuesta por nuestra política deplanificación, para permitir la mezcla de carga local ycarga paralela en el mismo nodo del cluster no-dedicado,es la reserva de recursos mediante el uso de containers.La política presentada propone el uso de controlgroups– los cgroups para hacer reserva de recursos enlos nodos del cluster. Linux implementa containers através de los cgropus. Los recursos de cada nodo sedividen en subsistemas y se crean una jerarquía dearchivos – los cgroups. En cada cgroup se definenporcentajes de uso de correspondientes subsistemas.Para cada cgroup se puede asignar aplicaciones, usuarioso procesos, definiendo de esta manera cómo será el usocompartido de los recursos del cluster.Los clusters no-dedicados utilizados en laboratoriosinformáticos ejecutan carga local muy controlada. Estacarga varía en el tiempo (horas) y en el espacio. El retode la política de planificación propuesta, es utilizardistintos cgroups, con diferentes configuraciones de usode recursos, que serán utilizadas por cada nodo amedida que la carga local cambie.Fig.7 Esquema de la política de planificación de trabajos propuestaVI.EXPERIMENTOS Y RESULTADOSPara la ejecución de los experimentos fue utilizado uncluster no dedicado, compuesto por PC´s de sobremesa einterconectado mediante una red de interconexión a100Mbits/segundo.Este cluster está constituido por nueve máquinashomogéneas. Desde la perspectiva Hadoop, el sistemaestá formado por un nodo Master y 8 máquinasrealizando tareas de Worker. La planificación detrabajos, y la gestión del sistema de archivos por HDFS -Hadoop Distributed File System, se centraliza en el nodomaster. Fue utilizado Hadoop en su versión 20.2, Javaen su versión jdk1.6.0_16 y como sistema operativoUbuntu en su versión 9.10.La Figura 8 presenta los tiempos de ejecución de unaaplicación MapReduce del tipo read-mapping. Eltamaño de los datos de entrada ha sido de 4,5 Gigabytes.En cada nodo por defecto, fueron definidos dos slotspara tareas Map y dos slots para tareas Reduce. Eltrabajo ha sido dividido en 62 tareas Map y 16 tareasReduce en una primera ejecución. A continuación seejecutarán con 8, 4 y 2 tareas Reduce. La primeracolumna de la figura 8, presenta los tiempos deejecución del trabajo sin reutilizar la máquina virtualJava, y la segunda columna presenta los tiempos deejecución reutilizando la máquina virtual Java. Losresultados muestran una ganancia de aproximadamenteel 5% en los tiempos de ejecución.La Figura 9 presenta los tiempos de finalización(makespan), cuando fueron ejecutados en paralelo ochotrabajos distintos del tipo read-mapping. Cada trabajoJP2011-504

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011utiliza su propio archivo de consulta y los ocho trabajoscomparten entre ellos el mismo fichero de referencia.El tamaño de los datos de entrada también ha sido de 4,5Gigabytes. En cada nodo por defecto, fueron definidosdos slots para tareas Map y dos slots para tares Reduce.El trabajo ha sido dividido en 62 tareas Map y 8 tareasReduce.resultados de los primeros experimentos utilizando lapolítica propuesta, demuestran una disminución en eltiempo de makespan de trabajos MapReduce encoladosen el cluster Hadoop, comparados con los valores de lapolítica de planificación por defecto. En una primeraaproximación, los resultados obtenidos, muestran laviabilidad de nuestras propuestas. No obstante, en esteapartado, se deberá completar la experimentación,incorporando más aplicaciones y casos de usoAGRADECIMIENTOSEl presente trabajo ha sido financiado por el MEC(Ministerio de Educación y Ciencia) mediante elproyecto con referencia TIN2007-64974.Fig.8 Política sin reutilización de JVM x Política con reutilización deJVMLa primera columna de la figura 9, presenta lostiempos de ejecución del trabajo de la política pordefecto del framework Hadoop. La segunda columnamuestra los tiempos de ejecución, reutilizando lamáquina virtual Java. La tercera columna, presenta losresultados de la política de planificación propuesta. Losresultados muestran una ganancia de aproximadamentede 5% en el tiempo de makespan cuando se compara lareutilización de la maquina virtual Java con la políticapor defecto de Hadoop. Y muestra una mejora del 17%,cuando se compara la política de planificaciónpropuesta, con la política por defecto del frameworkHadoop.Fig.9 Comparativa de rendimiento al aplicar la política propuestaVII.CONCLUSIONESLa política propuesta está basada en dos aspectos; laplanificación de trabajos paralelos MapReduce, y lareserva de recursos utilizando containers, para permitirla mezcla de cargas locales con cargas paralelas.Hasta ahora, ha sido implementado la planificación detrabajos paralelos MapReduce. Esta implentación estábasada en dos puntos: la afinidad de tareas de trabajosdistintos que compartan el mismo bloque de archivo deentrada y la reutilización de máquinas virtuales. LosREFERENCIAS[1] Dean, Jeffrey and Ghemawat, Sanjay MapReduce: simplifieddata processing on large clusters. ACM, 2008, Commun. ACM,Vol. 51, pp. 107-113.[2] Zaharia, M.; Konwinski, A.; Joseph, A.D.; Katz, R.; Stoica, I.Improving MapReduce Performance in HeterogeneousEnvironments. 2008, in 8th USENIX Symposium on OperatingSystems Design and Implementation, (OSDI'08).[3] Lämmel, Ralf. Google's MapReduce programming model --Revisited. Elsevier North-Holland, Inc., 2008, Sci. Comput.Program., Vol. 70, pp. 1-30.[4] Kruijif, M.; Sankaralingam, K. MapReduce for the Cell B.E.Architecture. 2007, Technical Report, TR1625, The Universityof Wisconsin-Madison.[5] He, Bingsheng, et al. Mars: a MapReduce framework on graphicsprocessors. 2008, in Proceedings of the 17th internationalconference on Parallel architectures and compilation techniques.[6] Ranger, Colby, et al. Evaluating MapReduce for Multi-core andMultiprocessor Systems. 2007, in Proceedings of the IEEE 13thInternational Symposium on High Performance ComputerArchitecture.[7] Fischer, M.J.; Su, X.; Yin, Y. Assigning tasks for efficiency inHadoop: extend abstract. 2010, in ACM Sysmposium onParallelism in algorithms and architectures. (ACM-SPAA’10).[8] Ibrahim, S.; Jin, H.; Cheng, B.; Cao, H.; Wu, S; Qi, L.; Cloudlet:towards mapreduce implementation on virtual machines. 2009,ACM International Symposium onn High performancedistributed computing. (ACM-HPDC’09).[9] Isard, M.; Prabhakaran, V.; Currey, J.; Wieder, U.; Talwar, K.;Goldberg, A. Quincy: fair scheduling for distributed computingclusters. 2009 , in Symposium on Operating systems principles(ACM -SOSP '09).[10] Kim, S.; Han, H.; Jung, H.; Eom, ,H.; Yeom, H. Harnessing inputredundancy in a MapReduce framework. 2010, in Symposium onApplied Computing. (ACM – SAC’10).[11] Luo, Y.; Guo, Z.; Sun, Y.; Qiu, J.; Li, W.W. A HierarchicalFramework for Cross-Domain MapReduce Execution. 2011, InHigh Performance Distributed Computing (ACM – HPDC’11).[12] Qin, A.; Tu, D.; Shu, C.; Gao, C. Xconveryer: guarantee hadoopThroughput via Lightweight OS-Level Virtualization. 2009,Eighth International Conference on Grid and CooperativeComputing. (IEEE-GCC’09).[13] Shafer, J.; Rixner, S.; Cox, A.L. The Hadoop distributedfilesystem: Balancing portability and performance. 2010, IEEEInternational Symposium on Performance Analysis of Systems &Software. (IEEE –ISPASS’10).[14] Stephen S.; Pötzl, H.; Fiuczynski, M. E.; Bavier, A.; Peterson, L.Container-based operating system virtualization: a scalable,high-performance alternative to hypervisors. SIGOPS Oper. Syst.Rev. 41, 3 (March 2007).[15] Xie, J.; Yin, S.; Ruan, X. Ding, Z.; Tian, Y.; Majors, J.;Manzanares, A.; Qin, X. Improving MapReduce performancethrough data placement in heterogeneous Hadoop clusters. 2010,IEEE International Symposium on Parallel & DistributedProcessing, Workshops and Phd Forum. (IEEE-IPDPSW’10).JP2011-505

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011[16] Zaharia, M.; Konwinski, A.; Joseph, A.D.; Katz, R.; Stoica, I.Improving MapReduce Performance in HeterogeneousEnvironments. 2008, 8th USENIX Symposium on OperatingSystems Design and Implementation. (OSDI'08).[17] Apache Hadoop. Retrived April 20, 2010, from ASF:http://hadoop.apache.org/core/.[18] Gunarathne, T,; Wu, T.; Qiu, J.; Fox, G. Cloud ComputingParadigms for Pleasingly Parallel Biomedical Applications.2010, in 19 th ACM International Symposium on HighPerformance Distributed Computing. (ACM – HPDC’10).[19] Schatz, M.C. Cloudburst: highly sensitive read mapping withMapReduce. Bioinformatics 2009 25(11):1363-1369JP2011-506

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Procesamiento de vídeos usando la nubeA. Morales 1 y F. Almeida 2Resumen— Este trabajo recoge el diseño delframework VideoMante. Se trata de un frameworkgeneralista orientado al entendimiento de vídeo. Elproyecto se aborda como un proyecto interdisciplinaren el que se integran la computación en paraleloy distribuida, los algoritmos y las operacionesde análisis de imagen y visión y los lenguajes yherramientas orientadas a la programación y fusiónen ambos contextos. Como resultado preliminarse presenta como caso de uso un problema muyfrecuente en el ámbito de la visión por computadory el procesado de vídeos, que es la detección deobjetos en movimiento. Sin embargo, la metodologíapropuesta es extensible a otros casos de uso, comoel retocado de fotogramas o la realidad aumentada,sin mas que cambiar las funciones usadas. Semuestra, además, un análisis de rendimiento delas tecnologías seleccionadas y su versatilidad enentornos secuenciales y paralelos.Palabras clave— Computación paralela, análisis devídeo, python, octave, OpenCV, OpenMP.I. IntroducciónLOS dispositivos de captación de imágenes yvídeos han incrementado progresivamente lacantidad de datos que proporcionan. Cada vezse dispone de mayor resolución en fotografías yvídeos, en términos del número de píxeles o delnúmero frames por segundo (FPS) que ofrecen.Los límites de la tecnología comercial rondanlos 7500 FPS a resolución 1000x1000 o millonesde FPS a resoluciones de 100x100. Aunque sedispone de una amplia bibliografía orientada aldesarrollo de algoritmos y operaciones para eltratamiento de vídeo, a estas resoluciones se vuelvealtamente costosa su manipulación en términoscomputacionales, más aún cuando se requierensoluciones en tiempo real.Simultáneamente, la potencia de cómputo de lossistemas paralelos y distribuidos disponible, muy porencima de los sistemas embebidos y de escritorio,no parece que esté siendo aprovechada como unaforma generalizada y eficaz con la que abordartales operaciones e incrementar el alcance de losresultados.En este trabajo se presenta el proyecto, yresultados preliminares, para el desarrollo delframework generalista VideoMante orientadoa la manipulación y el entendimiento devídeos. VideoMante aprovecharía los recursosde computación de altas prestaciones actualmentedisponibles y su acceso a través de redes comoInternet. Nuestro esfuerzo trata, por tanto, defusionar varios universos:• Imágenes de alta definición1 Dpto. de Estadística e Investigación Operativa,Universidad de La Laguna, e-mail: amorales@ull.es.2 Dpto. de Estadística e Investigación Operativa,Universidad de La Laguna, e-mail: falmeida@ull.es.• Sistemas de cómputo paralelo y distribuido• Algoritmos eficientes en el área de visión cuyasalida se proporciona a procedimientos queextraen conclusiones de alto nivelEl objetivo principal es el de extraer deforma automática información contenida en elvídeo que resulta difícil de obtener a través demétodos tradicionales. Por ejemplo: obtenerestadísticas del tráfico en una rotonda, analizandoel comportamiento de cada individuo, a partir delvídeo proporcionado por una cámara de observaciónde tráfico.Hasta donde nosotros conocemos, no existeningún framework de caracter generalista orientadoal entendimiento de vídeos basado en Servicios Web yOpenCV. La mayoría de los trabajos y herramientashacen referencia a frameworks realizados ad-hoccon su propio juego de instrucciones, por ejemplo,basados en tecnologías GRID [8] o apoyándose enesqueletos [9] [10]. Nuestra propuesta pretende irun paso más allá y aprovechar tecnologías estándary ligeras ampliamente difundidas. Se propone, porejemplo, utilizar la librería OpenCV ampliamentevalidada, la baja barrera de entrada del lenguajepython, así como las tecnologías que se apoyan enservicios web, más genéricas que las alternativasencontradas.La estructura del trabajo es la que sigue: lasección II muestra el diseño de VideoMante comoun framework generalista, la sección III plantea uncaso de uso de VideoMante sobre el problema de ladetección de movimiento en vídeo, mostrando lastecnologías y las pruebas realizadas, se finalizarácon las secciones de resultados computacionales yconclusiones, secciones IV y V respectivamente.II. MetodologíaEl diseño propuesto para VideoMante puede verseen la figura 1. Se observan un nodo maestro yun conjunto de N nodos esclavos con el mismoconjunto de software instalado. El nodo maestroes el encargado de orquestar el proceso según lascapacidades de los nodos esclavos. Por lo generallos nodos esclavos serán principalmente de cómputo,pero si existe hardware de entrada (una cámara devídeo) o de salida (una pantalla), en estos nodospriorizarán las funciones de captura o reproducción.De igual forma, se considerarían también entradao salida, la tarea de descomponer un fichero devídeo local en frames para su procesado, así comocomponerlo nuevamente a un vídeo o enviarlo a unservidor de streaming. Por último, se observa quelos nodos comparten un modulo de almacenamientoque actúa como repositorio de trabajos y resultados.Los paquetes de software instalados en los nodosJP2011-507

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011CámaravídeoFicherovídeoN xOpenCVSinglecoreNodo adquisición / cómputoOpenCFEsclavoC C++ Python Octave AlgoritmosFig. 1.OpenMPMulticoresotrasGPU PlataformaAlmacenamiento distribuidoLibreríasservicioswebEsquema del frameworkNodo maestroOpenCFMaestroServidorstreamingFicherovídeoesclavos, con los que el usuario podrá elaborarlos algoritmos de visión o de codificado de vídeos,los podemos clasificar en tres conjuntos diferentesatendiendo a su tecnología:• Lenguajes compilados, como C o C++, conlibrerías de visión como OpenCV [3], deprocesado de vídeos como libffmpeg [4], olibrerías paralelas como OpenMP [5]. En estaprimera aproximación nos centramos en C,OpenCV y OpenMP.• Lenguajes interpretados generalistas, comopueden ser python o perl, que algunos disponende librerías para visión, o que pueden servircomo lenguaje pegamento. En este caso se haescogido python por tener diferentes estilos deintegración con C y OpenCV.• Lenguajes interpretados orientados a cálculonumérico, como pueden ser octave o matlab, quedisponen de librerías para su uso en visión. Eneste caso se ha escogido Octave por su caráctergratuito.Como herramienta de comunicación entresistemas, se contempla OpenCF [1] , que permitiráservir y consumir algoritmos y funcionalidadesutilizando servicios web. Y por otro lado, parael paso de binarios (imágenes fuente e imágenesresultado) se pretende evaluar sistemas de archivosdistribuidos, como NFS u otros más adaptadosa la nube. No obstante no se evaluarán en estapublicación.Respecto a la arquitectura hardware subyacentese evalúa el uso de máquinas convencionales con unúnico núcleo y procesadores multinúcleo. En estaetapa no se evaluará el uso de GPUs pero es unobjetivo inmediato.La integración de este abanico de tecnologías,ligeras y escalables, permitiría resolver problemasde análisis de vídeo proporcionando soluciones entiempo real. El rendimiento y la latencia vendrándados por el problema concreto a resolver, el númerode equipos y las condiciones de la red.Desde el punto de vista de la computación de altasprestaciones, los objetivos de VideoMante puedenresumirse como:• Arquitectura distribuida: OpenCF en el nodomaestro y en los esclavos (comunicación usandoservicios web)• Arquitectura paralela, OpenMP en los nodos conmultinúcleo• Control centralizado de todas las ejecucionesy los parámetros desde el nodo maestro(planificador)• Librerías compartidas: OpenCV (visión),libffmpeg (vídeos)• Código en diferentes lenguajes: C, C++, python,octave, etc• Imágenes y vídeos en almacenamientodistribuido transparenteDesde el punto de vista del análisis de vídeo y dela visión por computador, el objetivo se concreta enla implementación de las siguientes funcionalidades,acorde a unas interfaces preestablecidas que puedanreusarse:• Lectura de vídeo (tanto de fichero como decámara)• Detección de fondo (varios métodos)• Detección de objetos (segmentacion)• Posición 2D de los objetos (p.ej: centroide)• Posición 3D de los objetos (mapeo 2D-3D)• Composición de varios frames en uno• Sobreimpresión de resultados (p.ej: trazas, encentroide)• Generación de vídeo (tanto a fichero como astreaming)Para que el usuario final de VideoMante obtengalas siguientes ventajas:• Programación modular con parámetrosconfigurables• Escalado del problema agregando más nodos,más núcleos o más GPUs• Interfaz gráfica unificada (escritorio o web)Claramente las funcionalidades propuestasconstituyen un conjunto básico de operacionesque podrá ser extendido con métodos de mayorcomplejidad.III. Caso de uso: detección de objetos enmovimientoComo caso de uso para esta primera contribución,se ha elegido un problema muy frecuente en el ámbitode la visión por computador y el procesado de vídeos,como es la detección de objetos en movimiento. Sinembargo, la metodología propuesta es extensible aotros casos de uso, como pueden ser el retocado defotogramas o la realidad aumentada, sin más quemodificar las funciones utilizadas.La manera habitual de detectar el movimiento esutilizando un conjunto de fotogramas previos paradeterminar el fondo, y sustraer dicho fondo delfotograma para analizar qué se ha movido. Aunquela detección de fondo es un campo maduro envisión, a día de hoy se siguen investigando nuevastécnicas. Se han elegido algunas de las tradicionales,y una implementación particular de una técnica másreciente:JP2011-508

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011• Media: El fondo se calcula como la mediade un conjunto de fotogramas en el pasado,calculada haciendo la media pixel a pixel. Elnúmero de fotogramas elegidos, su disposición yla importancia (peso) de cada uno suelen venirdados por el problema.• Mediana: Este algoritmo es similar al anterior,pero realiza el cálculo de la mediana en vez delcálculo de la media. En el caso anterior el objetoen movimiento forma parte del valor de la media,aquí se descarta siempre que el fondo se hayavisto en más del 50% de los fotogramas.• RANSAC: El RANSAC (RANdom SAmpleConsensus) [6] es un algoritmo creado enlos años 80 para ajustar modelos a datosexperimentales y ha sido aplicado a la detecciónde fondo [7]. Mejora al algoritmo que aplica lamediana puesto que su concepto de similitudes más flexible, y permite detectar fondo queaparece en menos del 50% de los fotogramas.Hemos mejorado la propuesta de este algoritmoy parametrizado el RANSAC de forma diferentepara conseguir un mejor comportamiento ymenor costo computacional.Comparación de lenguajes y técnicasEn un primer análisis, se ha implementado elmétodo de la mediana con diferentes combinacioneslenguajes y técnicas de programación. Las técnicasutilizadas han sido las siguientes:• octave-2d: Octave considera a las imágenescomo matrices 2D. La forma trivial detratamiento consiste en utilizar dos buclesanidados que recorren los diferentes elementos(x,y) de la matriz y hacer uso de la funciónmedian para calcular el valor correspondiente.• octave-3d: Se genera una matriz 3D que seconstruye apilando en el eje Z todas las imágenes2D, y se realiza la mediana sobre dicho eje Zutilizando la función median.• python-pyOpenCV: Se utilizan los bindingspyOpenCV para acceder a las imágenesy se utilizan dos bucles para recorrer loselementos (x,y) aplicando la función medianaimplementada directamente en python.• python-ctypes: Se aplica igual que el casoanterior, pero utilizando en esta ocasión losbindings ctypes.• C-cvget2d: Se realizan dos bucles para recorrerlos diferentes elementos (x,y), utilizando lafunción cvGet2D para obtener el valor de lospixels, y la función qsort para obtener lamediana.• C-punteros: Se aplica igual que el caso anterior,pero utilizando aritmética de punteros paraobtener el valor de los pixels.• python-c-punteros-total: Se aplica el casoC-punteros, se ha compilado en una DLL yse ha usado desde python con los bindings dectypes.• python-c-punteros-neto: Se aplica el casopython-c-punteros-total, pero midiendosolamente el tiempo de ejecución, y omitiendoel tiempo carga del intérprete.Ejecución secuencial/paralelaEjecutar cualquiera de los tests anteriores en unamáquina con una arquitectura de múltiples núcleos,a priori, no presenta ninguna mejora respecto deuna arquitectura secuencial, puesto que ninguno delos lenguajes utilizados se adapta en función delhardware subyacente.Octave presenta una librería multicore quepermite su ejecución en forma de múltiples hilos,pero su uso no es trivial.Python proporciona soporte para hilos en sulenguaje. Pero en su implementación actual, elinterprete CPython (el habitual usado en Linux,Windows o Mac) no está programado de formathread-safe y utiliza un semáforo global llamado GIL(Global Interpreter Lock) para evitar que dos hilospuedan modificar un mismo objeto. Las llamadas alibrerías en C no están afectadas del uso del GIL,siempre que no usen objetos del espacio de python.De igual forma se pueden usar procesos en vez dehilos, que no se ven afectados (usando la libreríamultiprocessing). Otros interpretes como Jython(java) no están afectados tampoco. La libreríaPyCuda también puede ofrecer un amplio abanicode nuevas posibilidades para la realización de códigoque poder sumar a las funcionalidades exportadas através de los servicios web.C ofrece soporte multinúcleo través de la libreríaOpenMP y sus directivas de compilación (#pragma).Esto presenta un handicap de cara al desarrollodel proyecto. Lenguajes como python resultancómodos como pegamento para invocar funciones delibrerías en C, y también para realizar operacionesde alto nivel, como podría ser el módulo de serviciosweb. Sin embargo, son incapaces por sí mismos deejecutarse con un paralelismo eficaz.Como solución se propone implementar lassecciones que se ejecutarán en la arquitecturamultinúcleo en C y el resto en python.#pragma omp p a r a l l e l#pragma omp f o r s c h e d u l e ( dynamic )f o r ( y = y i ; y < yf ; y++) {f o r ( x = x i ; x < xf ; x++) {// dentro de e s t a f u n c i ó n se// r e c o r r e l a coordenada zcalcula metodo ( imagenes , x , y ) ;}}Fig. 2.Código paralelizado de ejemploIV. Resultados ComputacionalesEn esta sección planteamos la experienciacomputacional realizada con el fin de validarJP2011-509

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011nuestras propuestas. En primer lugar analizamos elrendimiento de los distintos lenguajes y técnicas yposteriormente analizamos el rendimiento del casoparalelo.Análisis de rendimiento de lenguajes y técnicasEntrada: 4 fotogramas (42, 53, 64 y 75) de1440x1080 pixels en color, correspondientes a de unvídeo de 6 segundos a 25 FPS que muestra una escenade coches en movimiento (figura 3). Los fotogramasfueron escogidos con los objetos en movimientoen posiciones diferentes para que resultase sencillocalcular el fondo.Fig. 3.Fotogramas usados para el análisis de rendimientoCaracterísticas del equipo:• Procesador: AMD64 Turion MK36 2.0GHz• Cache: 64+64KB L1 - 512KB L2• Memoria: 2GB DDR2 667MHzVersiones del software: GCC 4.3.2, octave 3.0.1,OpenCV 1.0.0, python 2.5.2.En la tabla I se presentan como resultados lostiempos medios obtenidos para tres ejecucionesdiferentes del algoritmo de la mediana. En todos loscasos se lanza previamente una primera ejecucióncon el fin de asegurar que tanto ejecutables, libreríase imágenes, se encuentran en la memoria cache delsistema operativo.Se observa que los lenguajes interpretados por símismos resultan ineficientes en términos del tiempode ejecución para realizar cálculos. De ellos, el quemejores tiempos ha presentado es octave debido aque posee una función específica para el cálculo dela mediana tridimensional. Obviando esa operación,el acceso a arrays de python ha resultado ser másrápido que el de octave. Por otro lado está laimplementación C, donde, si la programación serealiza con ciertos trucos se puede conseguir explotarel rendimiento al máximo. Y por último se observaque el híbrido python-c aporta unos resultadoscomparables a la programación en C directamente,siempre que excluyamos los tiempos de carga delintérprete de python, lo que lo convierte en unaalternativa viable dadas las facilidades de desarrolloque ofrece python.TABLA IResultados de comparación de lenguajes y técnicasC-punterospython-c-punterospython-c-punteros-totalC-cvget2doctave-3dpython-ctypespython-pyOpenCVoctave-2dAnálisis de rendimiento del caso paralelo0.85 sg0.86 sg1.76 sg1.86 sg9.04 sg85.1 sg59.4 sg483 sgEntrada: 147 fotogramas de 1440x1080 pixels encolor correspondientes a un vídeo de 6 segundos a 25FPS que muestra una escena de un partido de tenis.Características del equipo:• Procesador: Intel Core 2 Quad Q6600 2.4GHz.• Cache: 128+128KB L1 - 8MB L2• Memoria: 4GB DDR2 667MHzLa tabla II muestra el tiempo de ejecución ensegundos invertido por los diferentes métodos enprocesar el vídeo de entrada y obtener el vídeode salida. El procesado se hace íntegramente enmemoria, habiéndose excluido el tiempo de lecturay el de escritura.TABLA IIResultados de ejecución paralela con OpenMP. Tiempode ejecución en segundosMétodo 1 núcleo 4 núcleos aceleraciónMedia 4.22 sg 1.34 sg 3.14Mediana 18.24 sg 4.67 sg 3.90RANSAC 148.83 sg 37.96 sg 3.92Como muestra de ejemplo, en la figura 4 se apreciaun fotograma del vídeo de una composición donde semuestra el vídeo original y los tres vídeos resultadosde la ejecución anterior.Se observa que con esta forma híbrida deproceder, podemos conseguir aceleraciones bastantebuenas. El método RANSAC y Mediana son máscomplicados computacionalmente que el de la Media,y observamos que las aceleraciones son mayores.Esto es así puesto que la proporción de códigoeficiente en C que se ejecuta es mayor. Aunqueel método RANSAC es computacionalmente máscostoso, presenta la ventaja de que los resultadosson mejores en general, y en especial cuando elfondo permanece poco tiempo visible.A la vista de los resultados y a modo de síntesisse propone la combinación python (cuanto menosposible) y C. Es importante seguir la máxima deque los cálculos sean implementados en C y dejaral lenguaje interpretado la labor de llamada. Lasaplicaciones presentan aceleraciones óptimas en elrango de procesadores considerados.JP2011-510

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Diferentes métodos de detección de fondo aplicados ypresentados en simultáneoOpenCV (Open Source Computer Vision)http://opencv.willowgarage.com/wiki/[4] Varios autores FFmpeg http://www.ffmpeg.org/[5] The OpenMP Architecture Review Board TheOpenMP API specification for parallel programminghttp://openmp.org/[6] M.A. Fischler and R.C. Bolles. Random sample consensus:A paradigm for model fitting with applications to imageanalysis and automated cartography. Communications ofthe ACM, 24(6):381–395, 1981.[7] H. Wang and D. Suter. A novel robust statistical methodfor background initialization and visual surveillance.Computer Vision–ACCV 2006, pages 328–337, 2006.[8] F.J. Seinstra, J.M. Geusebroek, D. Koelma, C.G.M.Snoek, M. Worring, and A.W.M. Smeulders, “Highperformancedistributed video content analysis withparallel-horus,” Multimedia, IEEE, vol. 14, no. 4, pp.64–75, 2007.[9] J. Sérot and D. Ginhac, “Skeletons for parallel imageprocessing: an overview of the skipper project,” Parallelcomputing, vol. 28, no. 12, pp. 1685–1708, 2002.[10] C. Nicolescu and P. Jonker, “A data and task parallelimage processing environment,” Parallel Computing, vol.28, no. 7-8, pp. 945–965, 2002.V. ConclusiónComo conclusión podemos decir que hemosrealizado el diseño del framework VideoMante quepropone una estrategia genérica con la que abordarproblemas del análisis de imagen y procesamientode vídeo. El framework requiere de la integración dediversos lenguajes y herramientas de programación,de algoritmos y operaciones necesarias para abordarproblemas de visión y de la computación paralelay distribuida para conseguir tiempos de respuestafactibles. En estos momentos disponemos de unprimer prototipo funcional y esperamos en el futuropoder cubrir las siguientes funcionalidades:• Computacional– Paralelización usando OpenMP– Cliente y servidor OpenCF– Almacenamiento compartido– Planificador de tareas• Visión– Lectura y escritura de vídeos– Detección fondo (fijo y móvil)– Detección objeto y sus coordenadas 2D– Múltiples frames con texto y dibujos• Calculos– Transformacion 2D-3D– Cálculo de velocidad y trayectoriasVI. AgradecimientosEste proyecto ha sido parcialmente financiado confondos (FEDER) por los proyecto TIN2008-06570-C04-03 del plan nacional I+D+I del MEC y porel proyecto SolSubC200801000307 del Gobierno deCanarias.Referencias[1] Francisco Almeida, Vicente Blanco Pérez, Carlos Delgado,Francisco de Sande, and Adrián Santos, “Idewep: Webservice for astronomical parallel image deconvolution,” J.Network and Computer Applications, vol. 32, no. 1, pp.293–313, 2009.[2] ULL Parallel Computing Group. Open computationalframework. http://opencf.pcg.ull.es/[3] Intel Corporation, Willow Garage, et all.JP2011-511

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-512

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011R en la nubeJuan Carlos Castillo, Francisco Almeida, Vicente Blanco, Adrián Santos 1Palabras clave Computación en paralelo, sistemasheterogéneos, servicios webs, cloud computing,lenguajes interpretados, RResumen Una de las principales metas de los entornosorientados a cloud computing es la de ofrecerel acceso a recursos distribuidos mediante interfaces ytecnologías basados en servicios web. OpenCF es unaherramienta que comparte estos objetivos y que puedeser utilizada com plataforma de desarrollo con la queofertar el hardware y software como servicio. En estetrabajo incorporamos las rutinas del paquete estadísticoR a un portal de cómputo basado en OpenCF.Asismimo, contemplamos la opción de que el usuariopueda lanzar sus propios scripts de ejecución R através del portal y además que estos scripts puedanser incorporados, por usuarios no expertos, al portalde cómputo como un servicio más. La propuesta quehacemos requiere la gestión de la automatización y dela incorporación dinámica de servicios.I. IntroducciónActualmente, los entornos basados en Cloud Computingpresentan las siguientes características [1]:dominios de administración múltiple, heterogeneidad,escalabilidad, y dinamicidad o adaptabilidad.Sistemas de gran escala añaden la dicultad de gestionargran cantidad de recursos. Estándares enservicios web proveen un incremento en el nivel deusabilidad, extensibilidad e interoperabilidad entreparejas de servicios. La adopción de estas tecnologíasen el contexto de Grid y Cloud Computing ha mejoradoel uso eciente de los recursos computacionales.Proyectos como Globus [2] o OpenCF [3], [4], [5] hansido generados basados en tecnologías de serviciosweb para gestionar recursos computacionales: monitorizaciónde sistemas o gestión y planicación detareas entre otras.Open Computational Framework (OpenCF) facilitael acceso a recursos de computación de altasprestaciones para aquellos usuarios que lo deseen.La idea principal es erradicar la barrrera tecnológicay de conocimiento a la que se enfrentanlos usuarios cuando intentan acceder a los Sistemasde Computación de Altas Prestaciones (High PerformanceComputing Systems o HPCS). OpenCF haadoptado extensiblemente la tecnología de serviciosweb para su implementación. Monitorización delrendimiento de sistemas o descripción de recursoscomputacionales son ofertados a los usuarios comoservicios web. Propone desacoplar en diferentes serviciosweb las tareas desarrolladas por un planicador,desde que estos servicios pueden ser usadosen aplicaciones cliente de terceros. Su composiciónnos lleva a un meta-planicador distribuido basadoen una plataforma de servicios web que proporcionaun amplio rango de aplicaciones. Monitorización de1 Dept. de Estadística. I.O. y Computación. Universidad deLa Laguna e-mail: falmeida@ull.esFig. 1OpenCF ofreciendo servicios de descubrimiento,monitorización y planificación para systemas HPCsistemas, caraterización de la carga, descripción delos HPC o políticas de planicación de tareas puedeser implementadas como servicios web estándar.Uno de los principales problemas a los que seenfrentan los usuarios de los HPC es la portabilidadde sus aplicaciones o scripts. La compilaciónde código fuente o ejecución de archivos binariosestá fuertemente ligada a la plataforma donde sequiera operar, limitando la capacidad de pluralidadde las infraestructuras existentes. Los lenguajes interpretados(como Perl, Matlab, IDL, Mathematicao Python) son una alternativa bastante robusta parasortear este problema, puesto que el rendimiento enestos lenguajes ha ido aproximándose poco a poco alde los lenguajes compilados [6].En este trabajo presentamos las modicacionesen la arquitectura tenidas en cuenta para soportarejecución de tareas de lenguajes interpretados(poniendo como caso de uso el lenguaje R [7]). Lasolución propuesta permite la generación automáticade servicios, así como la incorporación de nuevosservicios de forma dinámica. El usuario incorporaríanuevos servicios de cómputo que quedaríandisponibles para otros investigadores.Es trabajo se ha estructurado como sigue: lasección II introduce la infraestructura OpenCF,hablaremos brevemente de los lenguajes interpretadosen III, y el soporte de estos lenguajes (enel caso particular de R) en OpenCF será cubiertoen la sección IV. Finalmente concluimos el trabajocon algunas consideraciones y comentarios acerca delproyecto en IV-C.JP2011-513

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2La arquitectura OpenCF.II. La arquitectura OpenCFEs importante conocer la arquitectura de OpenCF,pues es la plataforma sobre la que se ha trabajado.La arquitectura software de OpenCF se muestra enla gura 2. Tal y como se enuncia en [3], [4], [5]destaca por un diseño modular: módulo servidor ymódulo cliente. Los módulos pueden ser extendidosindependientemente e incluso reemplazados paraproveer nuevas funcionalidades sin alterar el restode componentes del sistema (como por ejemplo, elmódulo servidor de PyOpenCF adaptado al GAE??). El cliente y el servidor implementan las trescapas inferiores de la pila que describen los serviciosWeb: Descripción de Servicios, Mensajería XML yTransporte. El cuarto nivel, Descubrimiento de Servicios,no ha sido implementado por motivos de seguridad.Por tanto, los administradores de sistemasiguen controlando el acceso por parte de los clientesa las plataformas paralelas a través de técnicas tradicionalesde autenticación.A. Módulo clienteEl módulo cliente es la interfaz entre el usuarional y el sistema. Los usuarios se registran en elsistema a través de un formulario. Alguno de loscampos requeridos son necesarios por motivos de seguridad,mientras que el resto son utilizados parala gestión de tareas. Esta información estará almacenadaen la base de datos asociada al módulo. Acontinuación se muestra la lista de submódulos delcliente.• La Base de datos almacena la información deusuarios, servidores, tareas, cheros de entraday salida, etc. Se ha implementado una base dedatos relacional MySQL a la que se accede mediantescripts en PHP• El Procesador de Peticiones consiste en unainterfaz web a la que el usuario puede acceder yobtener la lista de aplicaciones disponibles comotareas en los distintos servidores que tiene acceso.Cada entrada en la lista muestra una pequeñadescripción de la rutina y los servidoresque la ofrecen. Cuando la ejecución de una tareaes solicitada, el servidor es seleccionado implícitamenteacorde a unas reglas de planicación.Los parámetros de entrada se insertan en unformulario XHTML generado dinámicamente apartir de la descripción del servicio.• El Recolector gestiona la salida de las tareasgenerada por el servidor. El servidor notica alusuario mediante un email cuando la tarea naliza.El estado de las tareas ejecutadas puede serconsultado también en la interfaz web, así comoobtener los cheros de salida de la tarea una veznalizada ésta. Además, se ofrece la posibilidadde cancelar tareas no nalizas o eliminar registrode las ya concluídas.B. El servidorEl servidor gestiona todo lo relacionado con tareas,ofertándolas como servicios web y controlandosu estado y ejecución. Requiere de un servidor web(normalmente Apache) para la gestión de consultas.Cuando una consulta es requerida por un cliente, elservidor web crea un hilo de ejecución independientecon una nueva instancia del módulo servidor.• El Procesador de Consultas consiste en unconjunto de scripts PHP responsables de distribuirlas tareas por los diferentes componentes.Las consultas direccionadas por el sistemacomputacional son enviadas a la interfazde gestión de colas, y el resto de consultasson servidas por el procesador de consultas.El servicio web también es generado y ofertadopor este módulo. El documento de descricpiónde servicios (WSDL) es automáticamente generadoy actualizado por la clase NuSOAP de PHP.Esta clase también maneja la encapsulación demensajes SOAP de los paquetes.• La Interfaz de Gestión de Colas controla lainteracción con el sistema de colas del HPCS. Elservidor necesita conocer cómo una tarea puedeser ejecutada y como consultar el estado de unatarea en ejecución en el sistema. Para ello, dosmétodos de la clase OpenCFJob de PHP hande ser reescritas y adaptadas para cada servidor.Estos métodos permiten la ejecución deuna tarea bajo la cola del sistema y la consultade su estado. Además, una descripción XML decada rutina es necesaria para describir la tarea.• El Generador de scrips produce los scriptsnecesarios para la ejecución de las tareas bajoJP2011-514

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011distintos sistemas de colas. Está compuestopor un conjunto de plantillas más un motor deprocesamiento para generar el script. Diferentesplantillas son necesarias para cada una de losgestores de colas soportados. La plantilla esinstanciada en un script funcional por el motorde procesamiento mediante la sustitución deun conjunto de campos predeterminados. Estoscampos son obtenidos de los datos de entradadel servicio, del documento de descrpciónde servicios XML y de la información de usuarioguardada en la base de datos del cliente.• El Launcher es la interfaz entre OpenCF y el sistemaoperativo, lanza en segundo plano la tareaa ejecutar, obtiene su identicador y desbloqueala consulta realizada por el cliente. La implementaciónestá basada en Perl para hacerla independientede cada arquitectura. En futurasversiones y relativo a gestión de usuarios y grupos,este módulo será el responsable de colectary reportar la información tanto de usuario comode grupo conforme a los recursos del sistema.• El Recolector es la interfaz que despacha los resultadosproducidos por las distintas ejecucionesde las tareas. Una vez una tarea es nalizada,la cola del sistema automáticamente envía unemail al usuario y mueve los cheros de salidaa un directorio de descargas para que pueda serdescargado por el recolector del cliente.III. Lenguajes interpretadosEl aumento de lenguajes interpretados comoPython, VisualBasic, MATLAB, IDL, Maple yMathematica para el desarrollo de algoritmos, prototipos,análisis de datos e interfaces grácas deusuario (GUI) representa una tendencia importanteen la ingeniería de software. Sin embargo, utilizar loslenguajes interpretados en un HPCS actualmente esun reto en ámbitos académicos y cientícos. Desdeel punto de vista del ámbito cientíco, la mayoríade las soluciones proporcionadas a problemas abordadoscon lenguajes interpretados suelen solucionesparciales, como por ejemplo utilizar un lenguaje interpretadopara establecer un cálculo y luego interactuarcon un núcleo de cálculo escrito en un lenguajecompilado (por ejemplo, C, C++, Fortran) [8]. Sinembargo, esta tendencia ha ido cambiando en los últimosaños y podemos encontrar soluciones integralesa problemas con alto grado de cómputo en lenguajesinterpretados, como por ejemplo SOLVCON [9], unentorno software en python para resolver ecuacionesdiferenciales parcialmente hiperbólicas. El paqueteestadístico R es un ejemplo de herramienta basadaen lenguajes interpretados que está ampliamente difundido,es usado por cientícos en general y pormatemáticos y estadísticos en particular. En funciónde los datos de entrada el cómputo a desarrollarpuede requerir el uso de HPCS, este hecho justi-ca la aparición de una interfaz de R para MPI [10].Nos proponemos en este trabajo la incorporación dellenguaje R [7] en la plataforma OpenCF con distintasfuncionalidades. Mediante estas funcionalidades, elusuriario podrá lanzar sus scripts en una máquina decálculo de una forma amigable que oculta los detallesde implementación inherentes a la dinámica de losHPCS. Con nuestra estrategia los códigos desarrolladospor un usuario se incorporían dinámicamentea la plataforma para que puedan ser utilizados porotros usuarios.IV. R en la nubeLa mayoría de los entornos de desarrollo basadosen servicios web ofrecen facilidades para incluir serviciosa los que se puede acceder a través de unainterfaz web. Sin embargo, es cierto que estos entornosno proveen mecanismos automáticos generalespara añadir nuevos servicios web desde códigos deusuarios. Típicamente, exportar un servicio implicareescribir o adaptar el servidor de servicios web ydescribir el servicio a través de una interfaz XML,implicando en la práctica una tarea laboriosa paradesarrollar por parte del programador. Cuando elnúmero de servicios web es limitado es una tareaabordable; sin embargo, cuando el número de serviciosa gestionar supera un cierto tamaño (cientos omiles de servicios), se debe negociar con herramientasautomáticas para poder gestionar dichos servicios.Unos de los problemas encontrados durante el diseñode OpenCF es el trabajo necesario para añadirnuevos servicios al mismo. Si el número de rutinasque queremos ofertar es limitado el trabajo deañadirlas es asumible, únicamente se ha de denir ladescripción del trabajo y comprobar que el códigocumple con los requisitos de OpenCF. Sin embargo,si deseamos trabajar con un número mayor de trabajos(cientos o incluso miles), tenemos que crearun mecanismo automatizado para llevar a cabo estatarea.La solución desarrollada está basada en el análisisdel código fuente de las rutinas a exportar como trabajos.Se han analizado varias librerías que acometeneste trabajo. Generalmente, estas librerías trabajananalizando el código fuente y generando unadescripción XML. Esta manera de trabajar se ajustasin problemas a OpenCF ya que la descripción de lostrabajos usadas también está basada en XML. A losumo lo único necesario sería realizar alguna transformaciónXSLT de la salida generada por la libreríapara ser traducida al esquema usado por OpenCF.El objectivo de adaptar OpenCF para poder ejecutarlenguajes interpretados no fue sino el comienzode un amplio camino por recorrer. Con R se consiguióuna plataforma de pruebas para la generacióndinámica de servicios webs, así como otras utilidades(ejecución de código subido por el usuario y ofertaslas principales funciones de R como servicios web).Los principales problemas que se encontraron fueronlos siguientes:• Identicar las rutinas que han de ser exportadascomo servicios. La lista de servicios a exportardebe ser conocida previamente.JP2011-515

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3Lista de servicios agregadosFig. 4Ejecución de un nuevo servicio• Identicar los tipos de datos asociados a los servicios.Los usuarios nales deberán introducirlos argumentos del servicio a ejecutar a travésde la interfaz web del cliente. Una especicacióngenérica es necesaria para desarrollar la interfazde servicios, y lo sucientemente simple para serabordable en la práctica por un usuario normal.• Es muy dicil distinguir entre argumentos desalida y entrada a una rutina únicamente analizandola cabecera de la rutina. Podríamosdesarrollar una heurística basada en el uso deconst, punteros, etc. pero se debería ajustar acada tipo de código. Otra solución consiste enanotar los códigos, por ejemplo, haciendo uso deuna sintaxis dada en los comentarios para describircada uno de los argumentos (por ejemploJP2011-516

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 5Listado y ejecución desde consolaFig. 6Agregar un nuevo servicio dinámicamente.basada en javadoc, etc.).• Generar la interfaz de servicios, la informaciónde ayuda para el usuario y el código binario paraofrecer los nuevos servicios.A. Principales funciones de R como servicios webHaciendo uso del script get.xml.py escrito enpython y haciendo uso de la librería rpy (que integrapython y R), se consiguió parsear la documentaciónde R y generar para cada función un chero XMLque describe dicha función como servicio web (esdecir, especicando sus argumentos de entrada, desalida, descricpiones y nombre del servicio). Comoejecutable se escribió un wrapper en perl para ejecutaruna llamada a la función seleccionada de R conlos argumentos pasados por el servicio web (wrapper.func.pl).Con esto se agregaron como servicioweb algunas de las funciones de R del paquete basey del paquete utils. Los pasos a seguir para agregaruna nueva función son:1. Ejecutar el script get.xml.py pasándole comoargumento en paquete de R donde se encuentrala función func.name.2. Copiar el chero func.name.xml al directorioxml del servidor OpenCF.3. Ejecutar el binario bim/addjob.pl pasándolecomo argumento la ruta al xml anterior.JP2011-517

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20114. Como resultado se obtendrá un cherofunc.name.php en el directorio problems delservidor. Asegurarse de que tiene permisos deejecución.5. Realizar una llamada al nuevo servicio webdesde un cliente para comprobar el funcionamientocorrecto.No todas las funciones de R pueden ser ofrecidascomo servicio web (por ejemplo, los operadores aritméticos).Para evitar servicios incorrectos, se guardaun listado de funciones no compatibles como serviciosweb para evitar la generación de cheros XMLincorrectos. Una lista de funciones añadida medianteeste procedimiento puede ser consultada en lagura 3. Como ejemplo, puede verse en la gura 4 elformulario generado para la función media.B. Ejecución de scripts de R en OpenCFUn objetivo fundamental del proyecto es que elusuario pueda lanzar sus propios scritps a la máquinade cómputo. Con el script rwrapper.script.pl se consiguióejecutar scripts de R proporcionados por elusuario de forma aislada. Para ello, se ha creado unchero XML describiendo el servicio en cuestión, querequiere del nombre del script principal a ejecutar ydel chero R o un chero .zip con los scripts necesariospara la ejecución del principal. La ejecucióndel script R aportado como entrada podría generarvarios cheros de resultados. Es por ello que comoresultado del servicio, el usuario descarga un cherocomprimido que contiene los resultados y además lapropia entrada del servicio. La gura 5 muestra lainterfaz en modo línea de comandos de OpenCF quepermite lanzar los trabajos de forma remota. Se observael servicio executerscript que permite lanzar suejecución. Los pasos a seguir para su uso son:1. Ejecutar el servicio web con los parámetrosnecesarios2. El wrapper prepara el entorno de ejecución yejecuta el script, generando los resultados oportunos.3. Descargar los resultados.C. Generación dinámica de servicios webEl objetivo de la generación dinámica de serviciosen OpenCF es dotar a los servidores de una mayoroferta de servicios de forma automática o semiautomática.Este servicio permite a un usuario denirun nuevo servicio web que ejecuta un script R subidoal servidor por él. Para agregar un nuevo servicio, senecesita el script (o scripts) en R y un chero XMLque describa el trabajo, como muestra la imagen 6.La manera de elaborar un nuevo servicio web constade tres pasos:1. Generar el script (o scripts) en R2. Hay que elaborar un chero XML que describael trabajo a servir.3. Ejecutar la tarea de agregar servicios dinámicamentecon los parámetros anteriores4. Comprobar que el servicio se agregó correctamente.Con esto conseguimos un nuevo servicio web presenteen el servidor donde se lanzó la ejecución listopara ser llamado por los clientes de OpenCF.V. ConclusiónTecnologías basadas en servicios web han emergidocomo alternativa tecnológica para los portales webcomputacionales. Facilitando el acceso a recursosdistribuidos a traves de interfaces web mientras quese asegura la seguridad simultáneamente es una delas principales metas en la mayoría de las herramientasy entornos de desarrollo existentes. OpenCF,el entorno de desarrollo computacional Open Sourceque hemos desarrollado, comparte estos objetivos yañade otros, como portabilidad, generidad, modularidady compatibilidad con un amplio rango de Sistemasde Computación de Alto Rendimiento. Con laincursión de los lenguajes interpretados hemos añadidoun valor extra a OpenCF ampliando considerablementelas posibilidades para los usuarios nales,haciendo la plataforma aún más independiente y exibleen cuanto se reere a la gestión de tareas porparte de los administradores y a la ejecución de lasmismas por parte de los usuarios. Con la posibilidadde agregar servicios web de forma dinámica se consigueun mayor grado de libertad y participación porparte de los usuarios, agilizando aún más el procesopara poder ejecutar una tarea desde 0 en los HPCS.AcknowlegementsEste trabajo ha sido parcialmente subvencionadopor la EC F(EDER) y la MICINN Española (PlanNacional de I+D+I, TIN2008-06570-C04-03).Referencias[1] Mark Baker, Rajkumar Buyya, and Domenico Laforenza,Grids and grid technologies for wide-area distributedcomputing, Softw., Pract. Exper., vol. 32, no. 15, pp.14371466, 2002.[2] Globus Toolkit: Open source software toolkit for buildingGrid systems,http://www.globus.org.[3] OpenCF project webpage, http://opencf.pcg.ull.es/.[4] A. Santos, F. Almeida, and V. Blanco, Lightweightweb services for high performace computing, in EuropeanConference on Software Architecture ECSA2007,Madrid, Spain, Sept. 2007, number 4758 in Lecture Notesin Computer Science, Springer-Verlag, Berlin, Heidelberg.[5] Francisco Almeida, Vicente Blanco, Carlos Delgado,Francisco de Sande, and Adrian Santos, IDEWEP: Webservice for astronomical parallel image deconvolution,JNCA, vol. 32, pp. 293313, Jan. 2009.[6] Tia Newhall and Barton P. Miller, Performance measurementof interpreted programs, Lecture Notes inComputer Science, vol. 1470, pp. 146156, 1998.[7] R project, R is a free software environment for statisticalcomputing and graphics., .[8] Jeremy Kepner, Maya Gokhale, Ron Minnich, AaronMarks, and John DeGood, Interfacing interpreted andcompiled languages to support applications on a massivelyparallel network of workstations (mp-now), ClusterComputing, vol. 3, pp. 3544, January 2000.[9] Yung-Yu Chen, software framework for solving hyperbolicpartial dierential equations, 2011.[10] Mpi package for r, http://www.stats.uwo.ca/faculty/yu/Rmpi/.JP2011-518

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Comparativa y estudio de distribución de softwarede cálculo científico en entornos cloud con CVMFSVíctor Fernández-Albor 1 , Ricardo Graciani 2 , Javier López Cacheiro 3 , Fernando Gomez-Folgar 4 ,Antonio García-Loureiro 5 , Juan José Saborido 6Resumen 1 — En entornos de procesado de datos que usansistemas distribuidos cada grupo de investigación suelenecesitar un software específico para acceder ytransformar los datos existentes. Ello necesita a menudoser descargado e instalado en el propio sistema para poderhacer frente a la correcta ejecución del trabajo. Tiene, portanto, mucho interés el despliegue de una infraestructuraque automatice la descarga de software, que asegure supresencia en todos los nodos de ejecución con laposibilidad de ser gestionado externamente por unadministrador de versiones, que sea auto-actualizable yque se pueda aplicar también a entornos virtualizados.Todo ello permitiría acelerar la ejecución de trabajos,especialmente cuando éstos son cortos, y además reducir elconsumo de ancho de banda de la subred correspondiente.CVM File System (de aquí en adelante CVMFS) es unsistema de archivos compatible con tales escenarios. Es unsoftware diseñado para recuperar fácilmente archivosdesde un servidor HTTP, y que ha sido diseñado por elCERN para dar acceso al software de los experimentos deLHC en máquinas virtuales. Posee la peculiaridad de quese puede montar como un sistema de archivos normal através de archivos en espacio de usuario (FUSE). Debido aque los archivos se comparten a través de un servidor web,puede hacer uso de servidores proxy Squid para reducir lalatencia dentro de una misma subred y redistribuir lacarga del servidor central. CVMFS posee una cachepropia que, añadida a la cache del servidor proxy HTTP,completa un sistema flexible de descarga de ficheros. Acontinuación se presenta la arquitectura, implementación ypruebas de esta solución basada en CVMFS.Palabras clave—Distribución de software, CVMFS,Cálculo en la nube, Cloud Computing, Grid, Cálculocientífico.I. INTRODUCCIÓNEn la actualidad existe un gran número de grupos deinvestigadores que para poder ejecutar sus trabajos decálculo, por medio de sistemas distribuidos, necesitanemplear software específico que normalmente no seencuentra instalado en los nodos de computación.1Grupo de Física de Partículas, Universidad de Santiago deCompostela (USC), e-mail: victormanuel.fernandez@usc.es2 Dpto. de Estructura y Constituyentes de la Materia (UB),e-mail:graciani@ecm.ub.es3Dpto. de Sistemas, Centro de Supercomputación de Galicia(CESGA), e-mail: jlopez@cesga.es4Dpto. de Sistemas, Centro de Supercomputación de Galicia(CESGA), e-mail: fgfolgar@cesga.es5Dpto. Electrónica y Computación, Universidad de Santiago deCompostela, e-mail: antonio.garcia.loureiro@usc.es2Grupo de Física de Partículas, Universidad de Santiago deCompostela (USC), e-mail: Juan.Saborido@usc.esHabitualmente, es el propio usuario el encargado deefectuar la instalación y gestión de este softwareadicional, ya que es necesario para efectuar sussimulaciones, y ello repercute en el tiempo necesariopara ejecutar sus tareas de cálculo que vendrá dado porel máximo de los tiempos tanto de instalación delsoftware en los nodos, como de ejecución en losmismos:maxi ∈ N Dmaxj ∈ S iT ij + t iN D = {1,2…,M}S i = {1,2…,N i }N i = Número máximo de trabajos en el nodo iT ij = Tiempo de ejecución del trabajo j en el nodo it i = Tiempo de instalación del software para ejecuciónde trabajos en el nodo iM = Número total de nodosi = Nodo en el que ha corrido un determinado trabajoj = Número de trabajos en un nodoCon lo cual con el incremento del tiempo deinstalación del software, va a incrementarse el tiempototal de finalización de trabajos de usuarios.A partir de la colaboración con el proyecto Formiga, enel que varios grupos de usuarios van a ejecutar sustrabajos en un entorno virtualizado haciendo uso derecursos ociosos de aulas de informática, nace lanecesidad de crear una infraestructura que permita queesos trabajos obtengan de forma dinámica y escalable elsoftware que necesitan. La solución se encuentra en laherramienta CVMFS, que emplea catálogos de ficherospara establecer un sistema de archivos de solo lectura através del protocolo HTTP. Los archivos se transfierenen primer lugar a la caché local del nodo. En CVMFS unvolumen específico se identifica por su URL HTTP. Elmontaje de un volumen incluye la descarga del catalogode archivos, que contiene la información global sobreque archivos son servidos a través de HTTP. Lasversiones de software las mantiene inmutables, dándoselugar a nuevas versiones a partir de las actualizaciones yparches. Por otra parte, los archivos de catálogo degrandes volúmenes son divididos en múltiplessubcatálogos creando así versiones más básicas.Actualmente, CVMFS provee el software a distintosgrupos de usuarios del CERN, y está integrado en losJP2011-519

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011centros de procesos de datos del TIER-0 y TIER-1. Laforma en la que CVMFS trabaja, permite que se puedadesplegar en cualquier tipo de entorno. Por lo tanto, apriori parece la herramienta idónea para que distintosgrupos de usuarios, minimicen sus tiempos de ejecuciónpermitiéndoles emplear el software que necesitan, sin lanecesidad de descargarlo directamente.En este artículo se pretende analizar y compararlos resultados obtenidos empleando CVMFS frente a ladescarga directa y la instalación del software por partedel usuario. El presente artículo está organizado de lasiguiente forma: la segunda sección describe el CVMFS;en la tercera, se detalla la infraestructura y el desplieguede CVMFS; en la cuarta sección se describen laspruebas realizadas; en la quinta, los resultados;finalmente, las conclusiones se incluyen en la sextasección.II.DESCRIPCIÓN DEL CERNVM FILE SYSTEMEl sistema CVMFS ha sido optimizado para ladistribución del software de los distintos grupos detrabajos del CERN, y ha sido implementado como unsistema de archivos en espacio de usuario (FUSE).CVMFS ha sido diseñado para crear un árbol dedirectorios en un servidor web de solo lectura, de talforma que en el lado del cliente solo se requeriráconectividad HTTP/HTTPS al servidor web. CVMFSrealiza un cacheado en distintos niveles, de tal formaque archivos y metadatos se almacenan en la caché deldisco local así como en los servidores de respaldo HTTPintermedios, permitiendo que sea escalable hasta un grannúmero de clientes.El procedimiento de construir, instalar y validarlas versiones de software es responsabilidad de un gestorde versiones. Una vez realizadas estas tareas, se recrea elárbol de directorios dentro del repositorio de CVMFS.Este repositorio posee un formato particular cuyocontenido es un almacenamiento direccionabledenominado ―Shadow tree‖. La creación del repositorioincluye la creación de los catálogos de archivo,compresión de archivos, y cálculo de los hashes. Porotra parte, los archivos se almacenan de forma local,dentro de una caché en el servidor, como fragmentos dedatos SHA1. Se hace esto con el fin de explotar laredundancia y utilizar el SHA1 como llave a la hora dedescargar archivos. Esto permite evitar ciertasrestricciones firewall, como por ejemplo, lasprohibiciones de descarga de archivos root.exe. Una vezrealizadas estas tareas, el nuevo software es publicado através del servidor CVMFS.La publicación típica CVMFS sigue los siguientespasos:Crear los cambios necesarios en el ―shadow tree‖,añadir nuevos directorios, path de binarios, etc.Probar la instalación de software.Ejecutar la opción de sincronización con los nuevospaquetes añadidos.Publicar a través del servidor web en el directoriopúblico.Fig. 1. Proceso para la publicación de una nueva versión dentro delrepositorio de software. Una vez finalizado el proceso desincronización de CVMFS, está disponible a través de HTTP.III.INFRAESTRUCTURA Y DESPLIEGUE DELREPOSITORIO DE CVMFSPara poseer una infraestructura de pruebas lomás realista posible, en la que poder comprobar tanto lasescalabilidad de la solución, como el montaje rápido ydinámico de las versiones de software científico, ypensando en poder emplear la solución a un entorno deaulas virtualizado, hemos desplegado la infraestructurasobre un entorno heterogeneo de pruebas, donde, por unlado, se tiene un aula virtualizada en el Centro deSupercomputación de Galicia, por otro los nodos de uncluster local al repositorio en la Universidad deSantiago, y por último, nodos externos en la Universidadde Barcelona.A. Universidad de Santiago de CompostelaPara poder poner en contexto las pruebas,vamos a explicar un poco la infraestructura con la que secuenta. Por un lado, tenemos el repositorio CVMFS quees servido a través de Tomcat en una máquinaperteneciente al clúster del TIER-2 de LHCb de laUniversidad de Santiago de Compostela, dentro delmismo se desplegará un proxy HTTP Squid, con elobjetivo de minimizar los tiempos de respuesta, en casode saturación del servidor principal. Hay que tener encuenta que toda la infraestructura va a tener un sistemacacheado que va a intentar minimizar los tiempos dedescarga y montaje de los sistemas de ficheros. Estesistema de cachés estará integrado desde el propiorepositorio o servidor HTTP, que tendrá su cachéinterna, pasando por el proxy, hasta el propio nodo conla caché local en donde también existirá un tiemporesidual perteneciente, a la interacción con FUSE. Lainterconectividad de todos los nodos se realizará conSwichs de 100Mb/s.JP2011-520

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011B. Centro de Supercomputación de GaliciaPor otra parte, en el Centro deSupercomputación de Galicia, se tendrá un aula con unmáster del gestor de CloudStack, que permitirá levantarun sistema virtualizado en los nodos a través de una redde 1Gb/s, desde la cual, se habilita una de las máquinascon un servidor proxy para mejorar el escalado dentro dela misma subred.C. Universidad de BarcelonaContaremos con nodos de cálculo normales,que nos van a permitir comprobar escalado en largasdistancias, donde la latencia de redes de área extensa, esun factor importante a tener en cuenta.El tipo de nodos con los que se va a trabajarson, listados en función del organismo al que pertenecenserán:1) Universidad de Santiago: servidoresDELL PowerEdge SC1425, con dos procesadoresPIV Xeon a 2.8 Ghz y 1 GB de RAM por procesador(Fig.2.).2) Centro de supercomputación: en el aulavirtualizada, las máquinas anfitriones serán del tipoIntel(R) Core(TM)2 Duo E6750 @ 2.66GHz, siendolas máquinas virtuales de 2 Cores, con 1GB de RAMy 5GB de disco.3) Universidad de Barcelona: Dual Core AMDOpteron(tm) Processor 256 @ 1,7 GHz, 2 GB deRAM y 4 Cores.Fig. 2. Proceso para la publicación de una nueva versión dentro delrepositorio de software. Una vez finalizado el proceso desincronización de CVMFS, está disponible a través de HTTP.El modelo anterior (Fig.2.) tiene todos loselementos necesarios para asegurar una escalabilidad,soportando miles de clientes CVMFS con la fiabilidadexigida por un sistema de archivos, y el rendimientosobre el tipo de red más común en redes de área local,como las de las aulas de informática.IV.DESCRIPCIÓN PRUEBAS REALIZADASLas siguientes pruebas tienen la intención demedir la sobrecarga de CVMFS bajo las cargas detrabajo típicas en cálculo científico.Para la realización de estas pruebas se hautilizado un programa de análisis de datos utilizado engrupos de Física de Altas energías denominado ROOT(TablaI). ROOT, que está formado por librerías desoftware y un programa orientado a objetos desarrolladopor el CERN, y fue desarrollado para el análisis de físicade partículas, conteniendo varias característicasespecíficas de este campo. Debido al amplio número deficheros que utiliza ROOT, es la herramienta perfectapara utilizarla en las pruebas de software. El programaque se va a utilizar en ROOT ―rf202_extendedmkfit.C‖es un software de pruebas que va a permitir generardatos a partir de un modelo numérico, mediante unafunción con una serie de parámetros, la cual variará paraajustarlos a otro modelo completamente distinto. Estonos permite modificar el número de eventos con el finde ajustar mejor el modelo.La tabla I muestra algunas de las propiedadesde CVMFS o ROOT, donde podemos ver, la cantidad dearchivos con los que se va a trabajar o el tamaño decaché con el que vamos a contar.TABLA ICARACTERÍSTICAS DE LOS PROGRAMAS ROOT Y CVMFS EN CUANTOVersiónA TAMAÑO Y CANTIDAD DE ARCHIVOSTamañototalen MBROOT v.5.28 218(56 tar.gz)Número dearchivosTamaño mediode los archivosen KB4630 2.5CachéCVMFS v.0.2.61 69 628 4.0En las pruebas que se realizarán, se hará lacomparativa de CVMFS contra la descarga directa delsoftware desde el mismo servidor HTTP. El servidor dearchivos que se ejecuta es Apache 2.2.3, mientras que elservidor proxy HTTP es Squid en su versión 2.6,teniendo el repositorio CVMFS almacenado en una zonade solo lectura de los nodos, y utilizando la versión deScientific Linux 5.5. Las máquinas virtuales utilizanhipervisores KVM, y se cuenta con la pérdida constanteen la región del 5%.Para compararlo a partir de un estado conocido y demanera reproducible, todas las cachés serán borradas encada una de las baterías de pruebas, obteniendo losresultados con la denominada ―caché fría‖, y eligiendoel peor de los resultados en cada caso. Con esto lo quequeremos comprobar es la pérdida de rendimiento queexistiría en un posible caso real, en donde un usuario,nunca haya lanzado sus trabajos en uno o varios nodos,esta parece la simulación más realista ya que se puedecomparar a su vez con las pruebas de descarga directa,JP2011-521

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011en donde el usuario tampoco va a poseer el softwarecacheado cuando efectúa la descarga.Y para que las pruebas aún sean lo más realista posible,las primeras baterías de pruebas se realizarán lanzandoprimero un trabajo por nodo, mientras que las siguientessimulaciones se lanzará un trabajo por Core, para poderver el incremento de carga en caso de ejecutar distintostrabajos diferentes sobre los nodos de cálculo. En todoslos casos, las ejecuciones empezarán de formasimultánea en todos los nodos, por cada batería depruebas que se realice.El algoritmo de ejecución para las pruebas semuestra en las tablas II y III.V. RESULTADOSUna vez realizadas las pruebas anteriormentedescritas, procederemos a dividirlas en 2 tipos distintos,dependiendo de si se ejecuta ROOT como un procesoindependiente en cada uno de los nodos de cálculo, o sise ejecuta como un proceso por el número de Cores quetenga el nodo sobre el que se desea ejecutar. Habrá quetener en consideración el impacto del ancho de bandaen redes de área amplia, donde la latencia será máselevada que en redes de área local.TABLA IILÓGICA DEL PROGRAMA UTILIZADO PARA REALIZAR LAS PRUEBAS DEENVÍO DE SOFTWARE A TRAVÉS DE CVMFSTest 1: Uso CVMFSInput: node listOutput: time resultsif multicore execution then;ejecutar una iteración en cada core de un nodotime A ← mount CVMFSset envtime B ← run rf202_extendedmkfitelseejecutar una iteración en cada nodotime A ← mount CVMFSset envtime B ← run rf202_extendedmkfitif node execution finish thenget_results()umount CVMFSborrar caché Squid en cada Subnetborrar caché cvmfs en cada nodoreturn worst_result;TABLA IIILÓGICA DEL PROGRAMA UTILIZADO PARA REALIZAR LAS PRUEBAS DEENVÍO DE SOFTWARE DESCARGADO DE UN SERVIDOR HTTPTest 2: Descarga directaInput: node listOutput: time resultsif multicore execution then;ejecutar una iteración en cada core de un nodotime A ← download rootset envtime B ← run rf202_extendedmkfitelseejecutar una iteración en cada nodotime A ← download rootset envtime B ← run rf202_extendedmkfitif node execution finish thenborrar caché Squid en cada Subnetreturn worst_result;Cada una de las pruebas se realizará varias veces paracontrastar todos los resultados, y verificar que nohubiese ocurrido ningún tipo de error de saturación opicos de la red, que les pudiese haber afectado.Fig. 3. Comparativa del tiempo de ejecución de un trabajo por nodo enuna red de área local, entre la descarga directa del software y elmontaje de CVMFS.El tiempo real de CVMFS (Fig. 3.) es un pocomás bajo en comparación con el tiempo de descarga einstalación directa de un usuario, hay que tener encuenta que en este tipo de pruebas casi no se sufresobrecarga HTTP, ya que éstas se realizan íntegramenteen una red de baja latencia, dentro todo de la mismasubred, siendo este un caso ideal de distribución desoftware. En un caso más realista, tanto la descargadirecta, como el repositorio de software, necesitarán deservidores HTTP de respaldo para mejorar laescalabilidad.Fig. 4. Comparativa del tiempo de ejecución de un trabajo por core enuna red de área local, entre la descarga directa del software y elmontaje de CVMFS.En la Figura 4 se observa claramente, como alincrementar el número de peticiones de software, lasaturación de la red aumenta, influyendo en el tiempo deJP2011-522

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011descarga, ya sea en CVMFS o en la descargadirectamente del paquete. Por tanto, el incremento detiempo en la ejecución de programas de cálculocientífico, va a tener una relación directa con el númerode envíos de trabajos simultáneos dentro de una mismasubred. La escasa sobrecarga que se origina en CVMFS,al descargar la aplicación necesaria para ejecutar eltrabajo del usuario, podría verse reducida en unasituación realista. Si trabajos del mismo tipo, corriesensobre el mismo nodo, ocasionaría que parte del softwarenecesario ya estuviese cacheado localmente. EnCVMFS, se controla por otro lado la descarga demúltiples copias del mismo archivo mediante un controlseguro de su contenido (SHA1-Cache), evitando así larepetición de la descarga, debido a que los archivosduplicados se detectan automáticamente, lo que resultaen menos espacio consumido por la caché local, ymenos tráfico de red. En estas pruebas, no se hacontemplado esa opción en CVMFS, ya que la caché seborra en cada una de las iteraciones de pruebas.En estos dos últimos casos no se contemplan ningún tipode efectos externos sobre la latencia, ya que el entornode pruebas está controlado y el repositorio deCERNVM, se encuentra dentro de la red de área local,sobre la cual se efectúan.Fig. 6. Comparativa del tiempo de ejecución de un trabajo por core enuna red de área local virtualizada, entre la descarga directa delsoftware y el montaje de CVMFS.En la Figura 6 se puede comprobar lasaturación de descarga directa de archivos, incrementadapor el número de nodos de la red, donde alcanza picosde 6 minutos en el peor de los casos, mientras que con elsistema de archivos CVMFS, el incremento es menospronunciado. La suma de tiempos de redes de alta y bajalatencia, sumado a la limitación de la red de 100Mb delrepositorio de software, hacen que la descarga delsoftware en los nodos virtuales sea un problema deescalado a la hora de ejecutar múltiples aplicaciones ennodos de cálculo científico.Fig. 5. Comparativa del tiempo de ejecución de un trabajo por nodo enuna red de área local virtualizada, entre la descarga directa delsoftware y el montaje de CVMFS.Se puede comprobar en la Figura 5 cómo lostiempos reales finales son sensiblemente mejores con eluso de CVMFS. El efecto del servidor HTTP derespaldo Squid reduce el tiempo y la sobrecarga de redde alta latencia a través de la que se obtiene el softwarede CVMFS. Este es producido en su mayor parte por ladescarga de ficheros no cacheados en cada una de lasrepeticiones. En un entorno en el cual, la cachéestuviese llena, en el caso de aplicaciones que utilizasenel mismo software, el contorno de la línea de la gráficade CVMFS debería de ser más lineal, y no denotar unincremento tan pronunciado. Por otro lado, se ha podidocomprobar, que el tiempo de descarga es sensiblementemayor a los primeros casos de pruebas expuestos, peroel resultado final, la suma de todos los tiempos, se vereducido debido al tiempo de ejecución del software enlos nodos virtuales.Fig. 7. Comparativa del tiempo de ejecución de un trabajo por nodo enuna red de área local virtualizada y sin virtualizar, entre la descargadirecta del software y el montaje de CVMFS.En la Figura 7, se puede comprobar que elescalado es independiente de la mezcla de redes connodos virtuales o nodos normales, habiéndose echo laspruebas aumentando en partes iguales el número denodos a escalar, tanto virtuales como normales.JP2011-523

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 8. Comparativa del tiempo de ejecución de un trabajo por core enuna red de área local virtualizada y sin virtualizar, entre la descargadirecta del software y el montaje de CVMFS.En la Figura 8, el incremento también vamarcado por latencia en estas pruebas. En la descargadirecta de archivos, ésta se ve incrementada por elnúmero de nodos de la red, donde alcanza picos de 6minutos en el peor de los casos, mientras que con elsistema de archivos CVMFS, el incremento es menospronunciado, aunque existe un cierto repunte al final,originado por la saturación de la red, ya que el tiempo enla descarga de archivos se ha visto incrementado.usuario que a través de un único punto en común van aser servidos de una forma fácil y dinámica, en donde elusuario, independientemente del grupo al quepertenezca, va a ver reducidos sus tiempos definalización de trabajos, y tendrá la posibilidad de teneractualizado su software en todo momento. Al utilizar elprotocolo estándar HTTP para todas las comunicaciones,se puede cachear eficientemente el software a distribuir,de tal forma que es indiferente la localización física delos nodos de cálculo, mostrando, así, una clara ventajacon respecto a la descarga e instalación del software porparte del usuario. Este estudio demuestra una clarasuperioridad competitiva en cuanto a tiempos totales,para un usuario que necesita enviar múltiples trabajos,en entornos virtuales o nodos normales, que veráreducido su tiempo si lo utiliza, en vez de descargarlodirectamente al nodo desde el que se ejecute el trabajo.Con lo cual, la aplicación testeada favorece la mejora detiempos para su utilización en entornos de aulasinformáticas virtualizadas, de varios grupos de usuarios,que emplean software de instalación distinto entre ellos.AGRADECIMIENTOSAl proyecto y a la gente de Formiga-Cloud, a través delcual, se hizo necesario este estudio.Marcos A. Seco, por su colaboración en el desarrollo delas pruebas.REFERENCIASFig. 9. Distintas pruebas del tiempo de ejecución de un trabajo desde laUniversidad de Barcelona.En la Figura 9, la latencia de las redes de áreaextensa vuelve a ser la causa del incremento en eltiempo de finalización de un trabajo. En comparación eltiempo se reduce a casi la mitad indiferentemente delnúmero de trabajos a ejecutar en un nodo.VI.CONCLUSIONES[1] Jakob Blomer, T Fuhrmann , ―A Fully Decentralized File SystemCache for the CernVM-FS‖, Proceedings of 19th InternationalConference on , vol., no., pp.1-6, 2-5 Aug. 2010, doi:10.1109/ICCCN.2010.5560054, 2010[2] B Segal et al., "LHC Cloud Computing with CernVM",Proceedings of the XIII. International Workshop on AdvancedComputing and Analysis Techniques in Physics Research(ACAT10), Jaipur, 2010[3] A Harutyunyan et al., ―Dynamic virtual AliEn Grid sites onNimbus with CernVM‖, J. Phys, 2010[4] P Buncic et al., ―CernVM – a virtual software appliance for LHCapplications‖, J. Phys. , 2010[5] P Buncic et al., "A practical approach to virtualization in HEP",The European Physical Journal Plus, 2011[6] Portable Analysis Environment using Virtualization Technology,Jakob Blomer,December 2010[7] An alternative model to distribute VO specific software toWLCG sites: a prototype at PIC based on CernVM file system,Cern, GDB meeting, Elisa Lanciotti, November 2010[8] Jeffrey Katcher, PostMark:File System Benchmark, 2008[9] Don Capps, Analyzing NFS Client Performance with IOzone,2009[10] CloudStack, http://www.cloud.com[11] IOzone Filesystem Benchmark, http://www.iozone.org[12] LHC Grid http://lcg.web.cern.ch/lcg/[13] CernVM http://cernvm.cern.ch/portal/En la ejecución de tareas de cálculo científicoes importante la conclusión de aquellas en el menortiempo posible, siendo la instalación del propio softwarepara la ejecución por parte del usuario, uno de losfactores que más pueden incrementar este tiempo. ConCVMFS, se ha demostrado tanto en entornosvitualizados como en nodos de cálculo reales, como sepuede crear una infraestructura para varios grupos deJP2011-524

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Multi-Cluster Performance Impact on theMultiple-Job Co-Allocation SchedulingHéctor Blanco, Eloi Gabaldón, Fernando Guirado, Josep Lluís Lérida,1Abstract—Multi-cluster environments are composed of multipleclusters of computers that act collaboratively, andthus allow computational problems to be treated thatrequire more resources than those available in a singlecluster to be dealt with. However, the complexityof the scheduling process is greatly increased by theheterogeneity of resources and the co-allocation process,which distributes the tasks of parallel jobs acrosscluster boundaries. In a previous work, the authorspresented a new scheduling strategy made up of a jobselection function and a linear programming modelto find the best simultaneously allocation for multiplejobs from the system queue on a heterogeneous multicluster,by applying co-allocation when necessary.In this paper the effectiveness of our proposedscheduling strategy is evaluated under multiple configurationsfor the multi-cluster environment (computationheterogeneity and network availability) andcompared with other co-allocation strategies from theliterature. The results showed that co-allocation hasa negative effect on the response times when the networkavailability is low. On the other hand, the useof the multiple-job allocation contributes to maximizethe multi-cluster resources usage. By this, our strategywas able to adapt to different multi-cluster configurationsobtaining better scheduling decisions thanthe other schedulers.Keywords—Job Scheduling, Multi-Cluster Heterogeneityand Performance, Co-Allocation, Mixed IntegerProgrammingI. IntroductionComputation problems that require more computationalresources than those offered by a single justcluster can be resolved by the use of multiple clustersin a collaborative manner. These environments,known as multi-clusters, are distinguished from gridsby their use of dedicated interconnection networkswith a known topology and more predictable performance[1].A critical aspect of exploiting the resources in amulti-cluster environment is the challenge of schedulingparallel jobs across different clusters [2]. This allocationstrategy, known as co-allocation, can maximizethe job throughput by reducing the queue waitingtimes, and thus, jobs that would otherwise waitin the queue for local resources can begin their executionearlier, improving system utilization and reducingaverage queue waiting time [2][3]. However,mapping jobs across the cluster boundaries can resultin rather poor overall performance when co-allocatedjobs contend for inter-cluster network bandwidth.Additionally, the heterogeneity of processing andcommunication resources increases the complexity ofthe scheduling problem [4][5].The scheduling strategies with co-allocation inmulti-cluster environments have generated great interestin recent years. The performance of differentscheduling strategies using co-allocation based on jobqueues was analyzed in [2]. This work concludedthat unrestricted co-allocation is not recommendedand limiting the component sizes of the co-allocatedjobs improves performance. Some other studies dealtwith co-allocation by developing load-balancing techniques[6][7], selecting the most powerful processors[8] or minimizing the inter-cluster links usage [4].These studies share the optimization of a single performancemetric, such as the computing capabilityor the communication links usage, without finding acompromise between these. In order to fill this gap, anew analytical model was presented in [9] that measuresthe execution time of parallel applications byconsidering the resource availability of both processorsand communication resources.A common issue in those previous works is thatjobs are allocated individually, considering all theavailable resources for them without taking otherjobs in the waiting queue into account. In orderto solve this problem, in [3] we presented a newscheduling strategy, named PAS for Package AllocationStrategy. This strategy selects those jobs fromthe waiting queue that can be concurrently executedwith the available resources. Once the package ofjobs is selected, a Mixed-Integer Programming model(MIP) is responsible for finding the best possible resourceallocation for them. The PAS strategy wasevaluated for a predetermined multi-cluster environmentwith different kinds of workload. The resultsshow that applying the PAS strategy, the responsetimes were lower compared with the most commonscheduling strategies in the literature, making betteruse of the resources and preventing the saturation ofthe inter-cluster links.An important result observed in [3] is that the performanceof scheduling strategies is very sensitive tothe availability of resources. In a multi-cluster madeup of different clusters with heterogeneous and nondedicatedresources, the availability of resources andtheir capabilities are decisive for the performance ofthe scheduling strategies. Given this, it is necessaryto conduct a more detailed analysis to determine theeffect of the structure of the multi-cluster environmentand the availability of resources on the effectivenessof the previously-tested scheduling strategies.In the present paper, we evaluated thoroughly themulti-cluster configuration and resource availabilityon the effectiveness of different scheduling strategies.We assess the parallel application performance obtainedfor a fixed workload by varying the processorheterogeneity between clusters and the availablebandwidth on the communication links. We con-JP2011-525

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.Diagram of a multi-cluster topologyducted this evaluation using the Package AllocationStrategy (PAS) that we proposed in [3] and comparingthe results with those obtained for the schedulingstrategies presented by Jones [4] and Naik [8].The rest of the paper is organized as follows. InSection II, the multi-cluster and parallel applicationperformance model used in this paper is presented.In Section III, we present our scheduling strategyfor multiple-job co-allocation in a multi-cluster environment.Section IV shows the experimentation resultsobtained from comparison with other schedulingstrategies in the literature by varying the heterogeneityand availability of the multi-cluster resources.Finally, the conclusions are presented inSection V.II. Multi-cluster ModelAdvances in computational and communicationtechnologies have made it economically feasible toconglomerate multiple clusters of heterogeneous networkedresources leading to the development of largescaledistributed systems known as multi-cluster systems.Generally, multi-cluster systems can be classifiedinto super-clusters and cluster-of-clusters. Agood example of super-cluster systems is DAS-2 [10],which is characterized by a large number of homogeneousprocessors and heterogeneity in communicationnetworks. In contrast, cluster-of-clusters areconstructed by interconnecting multiple single clustersystems. Thus heterogeneity may be observed incommunication networks as well as processors. TheLLNL [11] multi-cluster system, which is built by interconnectingof four single clusters is an example ofcluster-of-clusters system.A commonly used model for representing the generalstructure for multi-cluster systems is presentedin Figure 1. The system is made up of as a collectionof arbitrary sized clusters {C 1 ..C α }, each cluster i iscomposed of N i processors of type T i , i = 1, ..., C,where T i could be different for each cluster. Also,Clusters are connected to each other through singlededicatedlinks {L ∞ ..L α }, by means of a centralswitch.In the present work, we focus our discussion on thecluster-of-clusters system where heterogeneity maybe observed in both resources processors and communicationnetworks. Thus, we need a model thatconsiders this feature to assess the performance ofparallel applications more accurately.A. Analytic Performance modelIn [9] we presented a new performance model forparallel jobs that defined the execution time by consideringboth the availability and heterogeneity ofthe processors and communication networks. Thismodel defines the execution time (T e ) of a paralleljob in a heterogeneous and non-dedicated environmentas its execution time in a dedicated environment(T e ) delayed by a slowdown factor (SD) producedby the heterogeneity and non-dedicated natureof the slowest allocated resources, and expressed byequation 1.T e = T e · SD (1)The slowdown of a parallel application dependson the capacity and availability of both processingresources and communication network, and thus, wecan express SD based on its processing SP and communicationSC slowdowns by equation 2.SD = σ · SP + (1 − σ) · SC (2)where σ denotes the relevance of the processingtime with respect to the communication time of thecorresponding job. The details of the calculation ofthe SP and SC values are presented below.A.1 Processing CharacterizationWe assume that parallel job tasks are generallysimilar in size and executed separately, and thus,the job execution time is bounded by the slowestallocated resource. Taking this into account, the jobprocessing slowdown (SP ) is obtained from the allocatedresource with maximum processing slowdown,expressed by equation 3.SP j = max{SP r |r ∈ P | } (3)where P | denotes the set of processing nodes allocatedto job j. In heterogeneous and non-dedicatedenvironments, the computing resources capabilitiescan be quite different. To measure these differences,we use the Effective Power metric (Γ r ) defined in [9],which relates the computing power of each resourcewith its availability. Thus, Γ r = 1 when resource rhas full capacity to run tasks at full speed, otherwiseΓ r < 1. Assuming this, the processing slowdownof such resource SP r is inversely proportional to itsEffective Power weight, SP r = (Γ r ) −1 .A.2 Communication CharacterizationThe parallel job co-allocation consumes a certainamount of bandwidth across inter-cluster networklinks (BW j k). These are shown by equation 4.( )BW j k(t = j k · P NBW j) n j T·− tj kn j T − 1 , ∀ k ∈ 1..α(4)where n j Tis the total number of tasks of the job j,t j kdenotes the total number of tasks allocated to clusterC k and P NBW j is the average per-node bandwidthrequirement by job j from the jobs. The firstJP2011-526

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011term in the equation is the total bandwidth requiredby all the nodes associated with job j in cluster C k .The second term represents the communication percentageof job j in other cluster nodes (not in C k )that will use the inter-cluster link k.The saturation degree of inter-cluster links relatesthe available bandwidth of each link (ABW k ) withthe bandwidth requirements of the allocated parallelapplications, which is calculated by equation 5.BWk sat = ABW k∑j,k BW j k∀ k ∈ 1..α (5)When the required bandwidth is lower than theavailable, the link is not saturated and the communicationswill not suffer delays. Otherwise, thenetwork link is saturated, drastically reducing theperformance of all the jobs sharing the link. Thus,the job communicating slowdown (SC) is obtainedfrom the slowest, most saturated, communicationlink used by the job, calculated as the inverse of thesaturation bandwidth with equation 6.SC j = max{(BW satk ) −1 |k ∈ 1..α} (6)The goodness of this analytic performance modelwas its ability to capture the performance for eachindividual application based on the characteristicsand load conditions of the multi-cluster environment.Thus, we can use this slowdown model as a performancemetric from parallel application point ofview, allowing the scheduler to take best allocationresourcedecisions according to stablished criteria.III. Multiple-Job Co-allocation StrategyA common feature of most on-line schedulingstrategies in cluster, multi-cluster and grid environmentsis the individual allocation of resources to applications.First, the scheduler selects the next job tobe executed according to a priority criterion. Whenthere are insufficient resources to run the selectedjob, the scheduler can wait for the release of enoughresources in order to follow a First Come First Served(FCFS) schema, or select a new job from the waitingqueue that can be executed with the availableresources by applying such a schema as Fit ProcessorsFirst Served (FPFS) or backfilling, etc. Oncea job is selected, it is individually allocated to themost appropriate resources according to the establishedcriteria.However, allocating the best available resources toa job without considering the requirements of therest of the jobs in the waiting queue can impair theperformance of future allocations and therefore theoverall system performance. With the aim of overcomingthis drawback, in [3], we proposed a twophasescheduling strategy, named Package AllocationScheduling (PAS). Firstly, a Job Package Selectionfunction determines those suitable jobs in the waitingqueue that will be allocated simultaneously. Secondly,a Mixed-Integer Programming (MIP) modelreturns the allocation that minimizes their globalslowdown while preventing the saturation of theinter-cluster links and applying co-allocation whenit is necessary.A. Job Package SelectionThe main aim of the selection function is to packagethe most suitable jobs from the waiting queueto be executed simultaneously, according to certaincriteria established in terms of desired system performanceobjectives. The job package selection function(F) can be expressed as P CK = F(Q, R, C) whereQ is the set of jobs in the waiting queue, R the set ofmulti-cluster resources and C the criteria to be metby resources to allocate the job package.There is a wide variety of criteria that can be appliedfrom the point of view of resource utilizationor the nature of the parallel applications. In thepresent work, in order to assess the effects of themulti-cluster configuration and resource availabilityon the scheduling strategies, we selected the mostcommonly used criterion which selects the set of jobsin the waiting queue that fits the free multi-clusterresources, and is expressed as∑∃ P CK ⊆ Q | τ | |R ′ ||∈PCKwhere P CK is the subset of jobs from the waitingqueue (Q) whose total number of tasks is less than,or equal to, the multi-cluster resources in R ′ , whichrepresents the subset of multi-cluster resources (R ′⊆R) that meet the criteria (C), which, in our case, arethose resources non-assigned to other parallel jobs.B. MIP Allocation ModelOnce a package of waiting jobs was selected, thePAS Strategy must allocate the most suitable resourcesaccording to established performance criteria.Using the slowdown model expressed by equation2 as a parallel application performance metricand defining the resource allocating problem as aMixed-Integer programming model, as in [3], we obtainedan allocation model that minimizes the globalresponse time for the target job package.The goodness of the PAS strategy was its abilityto obtain the best resources for each parallel job consideringthe other applications that can be executedconcurrently in the multi-cluster environment, andthus reducing the global response times while makingbetter use of the resources and also preventingthe saturation of the inter-cluster links.However, the effectiveness of the scheduling strategiesin these dynamic and heterogeneous environmentsis highly sensitive to the multi-cluster configurationand its availability. Therefore, it is necessaryto conduct a thorough analysis of the effect ofthese parameters on the effectiveness of the schedulingstrategies, allowing the scheduler to adjust accordingto the system characteristics and its status.In the next section, we assess the effects of the resourceheterogeneity and availability on the effectivenessof the scheduler decisions.JP2011-527

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011IV. ExperimentationIn this section, we present an experimental evaluationof the impact of the multi-cluster performanceon the effectiveness of the co-allocation schedulingstrategies in heterogeneous multi-cluster environments.The main goal of this evaluation was to determinethe scheduler ability to adapt its decisionsto take advantage of the multi-cluster performancecharacteristics and then obtain the best performancefor the proposed workload. For this, we proposed apredetermined workload that was fixed for all theexperimentation process, and was scheduled on differentmulti-cluster configurations.The experimental study was carried out by modifyingtwo main parameters such as the BisectionBandwidth (BSBW ) and the degree of heterogeneity(H). The first parameter BSBW , measured in Gigabytes/second(GB/s) [1], assessed the effect of thecommunication rate between two halves of the communicationsystem. It determines the worst-case performanceon a particular network, since it is relatedto the cost of moving data from one side of the systemto other. We chose values in the range of 0.1GB/sto 1.1GB/s, representing a low to high transmissioncost. This parameter would affect the schedulers toavoid jobs co-allocation when the network added ahigh communication slowdown. The second parameter,the multi-cluster heterogeneity degree H, meantthe percentage of difference of the effective power betweenthe individual clusters. Thus we defined threedifferent configurations, H = 10% (low heterogeneity,near to a homogeneous multi-cluster), H = 50%(there were significant differences) and H = 90% (extremeheterogeneity). The effective power is an importantfactor for the schedulers because the use ofthe most powerful resources allows to reduce the jobexecution times, obtaining free resources as quicklyas possible and then reducing the overall waitingtimes. On the other hand, this parameter is in conflictwith the available bandwidth because for obtainingthe best computing resources in many cases it isnecessary to apply co-allocation.The experimentation was done with our strategyPackage Allocation Scheduling (PAS) as a basis,and the results were compared with two other coallocationstrategies from the literature. The first,presented by Jones in [4], named CBS for ChunkBig Small, tries to co-allocate a “large chunk” (75%of the job tasks) to a single cluster in an attemptto avoid inter-cluster link saturation. The second,presented by Naik in [8], named JPR for Job Preferenceson Resources, allocates parallel jobs selectingthe most powerful resources, co-allocating themwhen is needed. Both of these use a FCFS (FirstCome First Served) scheduling policy, the same thatwe used in our selection function to compare the differentallocation strategies properly. For an accuratecomparison, both techniques were implemented byusing a MIP model using the CPLEX solver package.The multi-cluster environment was made up of4 clusters composed of 24, 16, 16 and 8 nodes, inter-Number of jobs100 jobsAvg. exec. time170 time unitsInterarrival time (Li’04) weibull (λ = 82.6 , k = 0.6)Job sizes (Lublin’03) gamma (α = 4.04, β = 0.77),”power of two” prevalenceJob actual runtime(Li’04) weibull (λ = 200 , k = 1)Comm.requ. P NBW( j =(Jones’05)4(njTBSBW)(n j T )2TABLA IWorkload parametersconnected by a Gigabit network.A. Workload characterizationA detailed characterization of a super-cluster waspresented in [12], where different distribution functionswere obtained from the characterization ofthe behavior of different real cluster environments.Based on the results of this study and also takinginto account the considerations made by Lublin [13]and Jones [4] about the size of the jobs and the characterizationof the communications requirements respectively,we have defined the most representativeworkload for a cluster-of-clusters according to theliterature. As can be seen in Table 1, the definedworkload is made up of 100 jobs with an interarrivaltime defined by a weibull distribution with parametersλ = 82.6 and k = 0.6, the job runtime was characterizedby a weibull distribution with parametersλ = 200 and k = 1, and an average execution timeof 170 seconds. The jobs sizes were characterized bya gamma distribution with parameters α = 4.04 andβ = 0.77 and adjusted to fit the prevalence of ”powerof two” job sizes as is observed by Lublin in [13]. Finally,the communication requirements (PNBW ) ofthe jobs were defined as proposed by Jones in [4].Figure 2 depicts the distribution functions used todefine the workload used in this experimentation.B. Experimental resultsIn order to determine the effectiveness of the coallocationscheduling strategies, we firstly evaluatedthe average response time for the predefined workload.The results obtained are shown in Figure3 for the three H configurations and for each onevarying the BSBW parameter. For the H = 10%case study, where the multi-cluster is approximatelyhomogeneous, two different tendencies can be observed.When the BSBW is lower than 0.6, therewas enough bandwidth for all job communications,and thus, all schedulers obtained similar results.However, when the BSBW increased, JPR couldnot obtain an adequate allocation because its maingoal was to obtain the most powerful computationresources without taking the communication overheadinto account. PAS and CBS obtained similarresults as they tried to reduce the network usage.However, PAS also selected the best computationresources from the multi-cluster, and this allowed itto slightly reduce the average response time.For the H = 50% and H = 90% case studies,the impact of the different effective power capabil-JP2011-528

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2.Workload characteristicsFig. 3.Response Time.ities among the clusters became an important factor.When the BSBW was lower than 0.6, PASand JPR were able to take advantage of the heterogeneouscomputation resources, obtaining lowerresponse times. The worst results were obtained byCBS because its main goal was to reduce the networkusage by forcing jobs to be allocated on individualclusters, without considering the computingcapabilites. When the BSBW increased, as inthe previous case JPR became worse. CBS continuedavoiding the use of the network communicationswhile PAS was also able to select the computationresources that allowed the job execution times to bereduced.From this results we conclude that the most sensitiveparameter for the job response time is the networkavailability. When the network is available (below0.6), for each H case study, the network availabilityhas no effect on the response time. However,when it is less available (over 0.6), the use ofinter-cluster links reduces even more the availablebandwidth. Then, in order to get better responsetimes, the schedulers should provide allocations thatreduce as much as possible the inter-cluster communications.Next, with the aim to determine how the schedulerstreated the availability of the network, we evaluatedhow many jobs were co-allocated by each one.It is important to take into account that the coallocatedjobs are those that could be more affectedby the low network availability. In Figure 4, thenumber of co-allocated jobs for each case of studyis presented. As can be observed, the JPR wasthe scheduler with the higher degree of co-allocation,60% of the total jobs present in the workload. Thiswas due to its need to obtain the best computationresources, irrespectively of the network availability.The opposite case was CBS with an overall 14% ofco-allocated jobs, as it tried to allocate at least the75% of the job tasks to the same cluster. The PASstrategy took both, heterogeneity and network availability,into account in order to reduce the job responsetime. In this case, the number of co-allocatedjobs was adapted to the multi-cluster characteristics.When the BSBW was low, it was able to co-allocatemore jobs. However, when BSBW increased, andthe communication slowdown penalized the responsetime, the degree of co-allocation was reduced forcingthe jobs to be maintained inside the individual clusterswhen its size (number of tasks) allowed this.The obtained results demonstrated that the coallocationhas an important performance impact onthe response times when network availability decreases.By this, the schedulers should take this effectin their allocation decisions into account in orderto improve the parallel applications performance.Finally we studied the effect of the multiple-joballocation done by PAS, (both JPR and CBS, arenot capable of doing multiple allocation). By usingmultiple-job allocation, PAS tries to maximize themulti-cluster resource usage and minimize the jobpackage execution time.The total number of jobs that were selected by theJob Package Selection is shown in Figure 5. As canbe seen, despite there could be enough free computationnodes among the multi-cluster, the numberof jobs treated together decreased when the BSBWincreased. This was because PAS tried to avoid asmuch as possible the saturation of the network andthis implies the use of the co-allocation just onlywhen it is profitable.Finally, these experimental results corroborateJP2011-529

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4.Co-Allocation jobs.that the most important multi-cluster parameter isthe network availability. The more available it is,the lower effect it has on the response time. Otherwise,when the network is low available, the benefitsof having high effective power on the computationnodes are less noticeable. By this, the bestperformance results were obtained when the schedulerstried to avoid as much as possible the interclustercommunication links. On this situation, PASobtained the best results adapting the multiple-jobco-allocation to the resources availability.Fig. 5.Number of jobs treated in a multiple allocation.V. ConclusionsIn order to obtain the best performance, the schedulersneed to be able of taking the dynamic availabilityon the multi-cluster resources into account. Tocorroborate this hypothesis, we evaluated the impactof the network availability and computation heterogeneityon the effectiveness of the scheduling process.We compared our strategy, Package AllocationScheduling (PAS), with two other co-allocationstrategies from the literature,CBS for Chunk BigSmall and JPR for Job Preferences on Resources.The results demonstrated that co-allocation has anegative effect on the response times when the networkavailability is low, and it must be used just onlywhen it is profitable. On the other hand, the use ofthe multiple-job allocation contributes to maximizethe multi-cluster resources usage while reducing theworkload response times. By this, our Package AllocationStrategy, which is composed of both a JobPackage Selection and Multiple-Job Allocation, wasable to adapt to the different multi-cluster configurationsand thus obtaining better scheduling decisionsthan the compared schedulers.Finally, we consider that the multi-cluster schedulersneed to take care not only of the current availablebandwidth, but also to estimate how muchbandwidth will be available after their schedulingdecisions in order to obtain better results for the responsetimes.Acknowledgements This work was supported by theMEC-Spain under contract TIN2008-05913 and the CUR ofDIUE of GENCAT and the European Social Fund.References[1] B. Javadi, M.K. Akbari, J.H. Abawajy, A performanceModel for Analysis of Heterogeneous Multi-Cluster Systems,Parallel Computing,vol.32(11-12), pp.831–851,2006.[2] A.I.D. Bucur, D.H.J. Epema, Schedulling Policies forProcessor Coallocation in Multicluster Systems, IEEETPDS, vol.18(7), pp.958–972, 2007.[3] H. Blanco, A. Montañola, F. Guirado, J. Lérida FairnessScheduling for Multi-Cluster Systems Based on LinearProgramming., 10th International Conference Computationaland Mathematical Methods in Science and Engineering(CMMSE’10), vol.1, pp.227-239, June 2010[4] W. Jones, W. Ligon, L. Pang, D. Stanzione, Characterizationof Bandwidth-Aware Meta-Schedulers for Co-Allocating Jobs Across Multiple Clusters, Journal of Supercomputing,vol.34(2), pp.135–163, 2005.[5] J.Abawajy, S.Dandamudi, Parallel Job Scheduling onMulticluster Computing Systems, IEEE Int. Conf.CLUSTER’03,pp.11–18, 2003.[6] E.M.Heien, N.Fujimoto, K.Hagihara, Static Load Distributionfor Communicative Intensive Parallel Computingin Multiclusters, IEEE PDP’08,pp.321-328, 2008.[7] C. Yang, H. Tung, K. Chou, W. Chu Well-Balanced AllocationStrategy for Multiple-Cluster Computing, IEEEInt. Conf. FTDCS’08, pp.178–184, 2008.[8] V.K. Naik, C.Liu, L.Yang, J.Wagner, Online ResourceMatching for Heterogeneous Grid Environments,IEEE/ACM Int. Conf. CCGRID’05,vol.2,pp.607–614,2005.[9] J.L. Lérida, F. Solsona, F. Giné, J.R. García, P.Hernández, Resource Matching in Non-dedicated MulticlusterEnvironments, In VECPAR’08, pp.160–173,2008.[10] The DAS-2 Supercomputer. Available from:http://www.cs.vu.nl/das2[11] The Livermore National LaboratoryMulti-cluster system., Available from:https://computing.llnl.gov/tutorials[12] H. Li, D. Groep, L. Wolters. Workload Characteristicsof a Multi-cluster Supercomputer, Job Scheduling Strategiesfor Parallel Proc., JSSPP’04, pp.176-193, 2005.[13] U.Lublin, D.G. Feitelson. The workload on parallel supercomputers:modeling the characteristics of rigid jobs.,J.Parallel Distr.Comp., vol.63(11),pp.1105-1122, 2003.JP2011-530

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Mr-Cirrus: Implementación de Map-Reduce bajo MPI para la ejecuciónparalela de programas secuencialesDaniel Ramet 1 , Juan Lago 2 , Johan Karlsson 1 , Juan Falgueras 3 y Oswaldo Trelles 1Resumen—Este documento presenta la aplicaciónMr-Cirrus (Map-Reduce High Level Clouds) quepermite la ejecución de programas secuenciales, sinninguna modificación interna, trabajando encolaboración para producir un resultadocoordinado en entornos de red, computación ennube (cloud computing) y multiprocesadores. Elmarco de desarrollo se basa en el paradigma Map-Reduce y ha sido implementada bajo MPI. De estaforma, muchas aplicaciones bioinformáticas (sobrelas 200 actualmente incluyendo Dotplots,comparación de secuencias, PAML, Muscle,MAFFT, MrBayes y BLAST) pueden escalarse através de su ejecución paralela, sin necesidad deinstalaciones específicas o de alto coste, ni necesidadde conocimientos de programación en entornosmultiprocesador. Se han realizado pruebasintensivas en diferentes tipos de procesos condiferentes cargas computaciones y patronescomputacionales, con resultados satisfactorios.Palabras clave— MapReduce, Cloud Computing,MPI, bioinformática, escalabilidad.encargadas de procesar los datos moleculares sonestrictamente regulares, pero cuyo problema actual esel manejo de los nuevos volúmenes de datos y que porlo tanto se adaptan perfectamente a una ejecuciónparalela. Así, por ejemplo, la ejecución de unabúsqueda por semejanza entre una secuencia problemay una colección de secuencias escala linealmente con elnúmero de secuencias en la base de datos, sin ningunadependencia de datos con respecto al orden decomparación ni a la completitud de los datos acomparar en el caso de repartir el proceso en variossubprocesos que produzcan resultados parciales.La tercera razón viene motivada por el éxito delparadigma Map-Reduce [10] en entornos decomputación de alto rendimiento. Su facilidad de usomatiza de forma efectiva la falta de programadoresespecializados en construir software de altorendimiento. Se estima que menos del 1% de losdesarrolladores de software a nivel mundial estánentrenados en computación paralela, y dar el salto a ellano es en absoluto trivial.LI. INTRODUCCIÓNA computación en la nube o “cloud computing” [1]ha reinventado el tradicional Centro de Datos (datacenter) para la prestación de servicios computacionales,con una rápida introducción y aceptación en distintossectores y ámbitos de actividad [2]. Esto es así en granmedida porque la computación en la Cloud promete, yen muchas situaciones lo consigue, recortes en loscostes operativos y de capital en la gestión de losrecursos computacionales de las instituciones por elahorro en la adquisición de la infraestructura a cambiode alquilar un recurso de pago-a-demanda segúnconsumo de los recursos (computación,almacenamiento, ancho de banda, etc) y evitando lagestión de las tareas de mantenimiento y puesta a puntodel centro de datos. Hay proveedores de servicios enCloud (como por ejemplo Google App Engine [3],Microsoft Azure [4], IBM Smart Cloud [5] y AmazonEC2 [6]) que ofrecen cantidades importantes de CPU yalmacenamiento bajo un software de gestión robusto ysobre cuyas plataformas es relativamente simpleinstalar una infraestructura en cuestión de minutos [7].Por otra parte, el espectacular incremento en laproducción de datos moleculares (del orden de los Teray Petabytes) [8,9] y la necesidad de analizar múltipleshipótesis bajo diversos escenarios hace que el análisisde datos genómicos en la biología actual requiera deuna potencia computacional que debe ser buscada en lacomputación paralela. También debemos tener presenteque una buena parte de las aplicaciones bioinformáticas1. Dpto. de Arquitectura de Computadores, Universidad de Málaga. dramet, tjkarlsson, ortrelles@uma.es2. Dpto. de Innovación y Tecnología, Fundación IAVANTE. juan.lago@iavante.es3. Dpto. de Lenguajes y Ciencias de la Computación, Universidad de Málaga. juanfc@uma.esJP2011-531En este contexto, el objetivo principal de este trabajoes proporcionar un marco de ejecución de aplicacionessecuenciales, con la premisa de no modificarlas enabsoluto, en varias instancias paralelas. El esquema sebasa en un gestor de la ejecución que hace a la vez delanzador de instancias, y dos programas externos paraasignar la carga sobre las instancias (map); y pararecolectar los resultados parciales y producir unresultado integrado final (reduce). En ambos casos setrata de programas relativamente simples y que nodemandan habilidades de programación paralela.Para validar y evaluar el sistema se han elegido dosaplicaciones representativas en el área de labioinformática; una con un gran número de tareasindependientes de pequeños volúmenes de datos(búsquedas por semejanza) y la otra con una sola tareapero un gran volumen de datos (matrices de puntos).Estas aplicaciones presentan muchas de lascaracterísticas de los procesos actuales en genómica;elevada E-S, gran consumo de memoria y demanda deCPU. Su evaluación nos proporciona informaciónimportante para portar al entorno un gran conjunto deaplicaciones con estructura computacional similar.II. MÉTODOS Y SISTEMASA. El gestor de instanciasEl diseño del esquema de gestión de la ejecuciónparalela de programas secuenciales se ha representadoen la figura 1. Un proceso maestro es el encargado dela creación de las instancias (servidores) que a su vez

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011invocan al proceso secuencial de acuerdo a lasespecificación que el maestro ha leído del fichero demapeo. Los procesos secuenciales ejecutan trabajosparciales e informan de su finalización al servidorquien maneja sus comunicaciones con el maestro, yquien a la finalización de todos los procesos servidoresinvoca el proceso de reducción o recolección deresultados parciales.Una secuencia genómica S n es una cadena desímbolos {x 1 , x 2 , ..., x n } que pertenecen al alfabeto delADN (x i ⊂ A {A, C, G, T}). La matriz de puntos es unode los métodos más antiguos de comparación desecuencias moleculares [11]. En términos simples, setrata de una representación visual del parecido entredos secuencias. Una se dispone en horizontal y la otraen vertical y la matriz de puntos se construyecomparando cada símbolo de ambas secuencias,ubicando un punto en la celda de intersección decoordenadas cuando los elementos son iguales. De estaforma, las regiones de las secuencias que comparten unparecido sustancial aparecerán como fragmentosdiagonales en la matriz. El método estándar parareducir el ruido de los parecidos aleatorios de pequeñosfragmentos utiliza una ventana deslizante de undeterminado tamaño, de forma que solo resulte en unpunto los fragmentos en la ventana cuyo parecidosupere un umbral prefijado.Hay muchas y antiguas extensiones a estametodología básica, que incluyen la fijación interactivadel umbral [12], [13], filtros estadísticos y el uso dediversos símbolos para discriminar las señales [14], eluso de colores para representar la información [15], yse ha extendido la capacidad interactiva [16, 17],incluyendo aplicaciones Web [11], con las típicascapacidades de navegación.Fig. 1. En la parte superior se esquematiza el proceso deasignación o distribución de la carga (map) y la generación delos scripts de ejecución. Un proceso maestro con los respectivosservidores, en el centro, se encargan de realizar las tareasparciales; para finalmente en un proceso de reducción producirel resultado integrado final (reduce).Tanto los procesos de distribución de recursos comolos de colección de resultados se especifican a través deficheros que pueden ser producidos automáticamentepor pequeños y simples programas de distribucióncolecciónde la carga. Estos son los únicos programasque necesitan ser escritos para completar el sistema ymuchas veces corresponden a conjuntos o lotes decomandos del sistema operativo.El proceso maestro está preparado para ser tolerante alos fallos de procesos, redistribuyendo la carga noresuelta y para lanzar la totalidad de las instancias porpartes o etapas de acuerdo a los recursos disponibles.Ello permite el diseño con distribuciones de carga detamaño variable a fin de reducir el coste deplanificación, y mejorar la sincronización final de losprocesos para tareas de baja regularidad.B. Las aplicaciones a implementar1) Las matrices de puntosEstas referencias nos permiten analizar algunosaspectos computacionales. Estrictamente hablando, lapropuesta inicial que realiza la comparación a nivel desímbolo, no requiere las secuencias ni la matriz depuntos en memoria. Bastaría con tener una de lassecuencias o parte de ella en memoria e ir trabajandoun símbolo a la vez de la segunda secuencia, paramostrar en una pantalla un punto o no. Sin embargo, yael uso de la ventana deslizante requiere al menos partede la segunda secuencia en memoria. Finalmente, lainteractividad sobre la matriz de resultados requiereque las aplicaciones gestionen la matriz de puntos enmemoria. Esto era posible porque se trabajaba sobre lassecuencias relativamente pequeñas que se disponían(genes o genomas de pequeños virus de algunos pocosKB).Sin embargo, hoy en día se dispone de informaciónde genomas completos de organismos superiores, entreellos el humano, con algunos GB de símbolos (elgenoma humano sobrepasa los 3 GB y sus cromosomasson de algunos cientos de MB). Aún por separado,tanto el cálculo como la visualización de la matriz depuntos representan grandes retos computacionales. Porejemplo, la comparación de dos genomas medios debacterias de 3 Mb, en un equipo capaz de comparar 100MB, usando una ventana de un solo símbolo necesitaríaalrededor de 25 horas, [16]. Cada incremento de unaunidad en el tamaño de la ventana representaría un díamás de tiempo de computación. Por otra parte, lasaplicaciones de análisis interactivo requieren la matrizen memoria. En [18] propusimos gestionar la matriz adistintos niveles de resolución llegando a manejarmatrices con algunos, notables para su momento,cientos de KB de longitud. Más adelante, en [15] seJP2011-532

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011presenta una aplicación para visualizar grandesalineamientos y en [19], se hizo en Web.2) Comparación de secuencias biológicasLa comparación de secuencias biológicas esposiblemente la aplicación de mayor uso enbioinformática. En esencia, dada una secuenciaproblema y una colección de secuencias conocidas, setrata de identificar aquellas secuencias en la colecciónque más se parezcan a la secuencia problema. De estasrelaciones se pueden inferir relaciones evolutivas,estructurales o funcionales entre las secuencias. Entérminos más formales, dada una secuencia S Q y unconjunto de secuencias D = {S 1 , S 2 , ..., S n } se debecomparar S Q contra cada una de las secuencias delconjunto D a fin de identificar aquellas S i , i ∈ {1…n}.III. RESULTADOSA. Los procesos de distribución y reducciónLos procesos de asignación de carga a procesos(Map) y colección de resultados (Reduce) se handiseñado para que puedan ser preparados de formaexterna tanto a la aplicación secuencial como al gestorde la ejecución.En el primer caso de estudio, la matriz de puntos seconstruye para dos secuencias S x y S y , por lo que ladistribución de carga más simple es la de repartir elespacio computacional L x × L y , donde L x y L y son laslongitudes de las secuencias respectivas. Para ello, separte cada una de las secuencias en N x y N y trozos paraluego invocar el programa para cada combinación S i yS j ∀ i=1... N x ; y j=1...N y ), lo que producirá resultadosparciales RES(i,j) que serán unidos por un proceso deReducción para producir la super-matriz final. Esinteresante indicar que este proceso genera además losscripts que permiten lanzar directamente las instancias(incluso en una máquina monoprocesadora).que las tareas que involucren a las secuencias largasgobernarán la eficiencia del sistema.Por ello, la distribución de la base de datos (conjuntoconocido de secuencias) no solo es importante, sinoque debe realizarse de forma que minimice la latenciade inicio (con mínimo de lanzamiento de instancias) yfacilite la sincronización de finalización mediante, enambos casos, de las tareas livianas al inicio y final delprocesamiento en paralelo.El coste de planificación está asociado al número detareas a distribuir (en nuestro caso especialmente por lalatencia de lanzar una nueva instancia) y al “tamaño”de las últimas tareas a distribuir. La planificaciónguiada (Guided Self Scheduling) se planteó esteproblema. Dado un número n de instancias a crear enparalelo, la mejor solución en la que permite a todas lasinstancias finalizar con una diferencia máxima de Bunidades de tiempo, siendo B el tiempo necesario pararealizar un bloque básico de tareas. El razonamiento esel de asignar en la i-ésima distribución x i bloques,dejando suficientes bloques para distribuir a los n-1instancias. Para conseguirlo, sea N el número debloques de tareas, entonces x i queda definido por:x i = | R i / n |R i+1 = R i - x i donde R 1 = NNosotros propusimos una modificación de estadistribución bajo la observación de que las tareasgrandes que se generan en las primera iteraciones (vertabla 1) produce una gran latencia tanto por ellanzamiento de la instancia pero especialmente por lallegada de los datos, llegando a producir inclusoTABLA 1TAMAÑOS DE LOS BLOQUES A DISTRIBUIR USANDO GSS YNUESTRO GSS MODIFICADO (GSS-MOD) PARA N=100 Y 4PROCESADORES.El segundo caso, búsquedas de secuencias porsemejanza, presenta dos variantes. Una primera sepresenta cuando se dispone de varias secuencias S Q(Q=1...N) y por tanto la primera distribución es la derepartir cada una de las secuencias a cada proceso. Enel segundo caso se trata de procesar una sola secuenciaS Q que se compara contra todas las secuencias delconjunto, por lo que en este caso lo natural es distribuirla colección de secuencias.Se debe observar que ambas soluciones pueden a suvez combinarse para formar una tercera opción queconsistiría en separar secuencias y distribuir también elconjunto de secuencias conocidas.Es importante destacar que la primera variante puedepresentar serios problemas de eficiencia cuando elnúmero de secuencias problema (S Q ) es muy pequeño,y cuando las diferencias de longitud de las secuenciasen dicho conjunto sean significativas, lo que suponeJP2011-533

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011inanición en las últimas instancias (este hecho fueconfirmado en los experimentos del trabajo de Google[10]). Estas modificaciones se traducen en los siguientecálculos:x i = | R i / n |x -i+1 = x iR i+1 = R i - x i siendo R 1 = N / 2B. EvaluaciónPara evaluar la solución propuesta hemos utilizado elcluster de la Red Española de Supercomputación,ubicado en el Centro de Bioinnovación de laUniversidad de Málaga. Este cluster de memoriadistribuida de la marca IBM está compuesto por 256nodos JS20-IBM, cada nodo con 2 CPU IBM PowerPCsingle-core 970FX de 64bits a 2GHz, y 1 TB dememoria distribuida. La programación se ha realizadoen C, usando la librería de paso de mensajes MPI.Para las primeras pruebas realizadas sobre laaplicación de matrices de puntos, se han usado dossecuencias de aproximadamente 1 MB de longitud, delas cepas APS y BPS de la bacteria Buchneraaphidicola (el primer genoma eucariota secuenciado enEspaña); y también variaciones en tamaño de estassecuencias para observar el comportamiento conreferencia al espacio computacional a distribuir. Para lasegunda aplicación se ha seleccionado un conjunto desecuencias de la base de datos swissprot (80 milsecuencias) y se han seleccionado de ella 100secuencias que serán usadas como conjunto problema(estas secuencias fueron a su vez eliminadas delconjunto conocido de secuencias). En cada una de laspruebas se han utilizado diferente número de instanciasde los procesos a fin de evaluar la escalabilidad. Latabla 2 muestra los resultados de las pruebas donde sepuede apreciar que se han utilizado distintos tamañospara validar la eficacia de la propuesta ante diferentestamaños de carga.Fig. 2. Composición de los resultados parciales del proceso de lamatriz de puntos, utilizando para ello dos secuencias de 2 y 3KBde longitud con diferente particionado.matrices parciales que conforman la matriz de punto dedos secuencias, obtenidas por seis procesos diferentes.Finalmente en la figura 3 se muestran los tiempos y lagráfica de aceleración correspondientes para los testsrealizados. Para la aplicación de las Matrices de Puntos,se han usado los genomas de las bacterias BuchneraTABLA 2DETALLES DE LOS CONJUNTOS DE PRUEBA. TAMAÑO DE LASSECUENCIAS EN LOS DOTPLOTS Y DE LOS CONJUNTOS PROBLEMAEN LAS BÚSQUEDAS POR SEMEJANZA.ACELERACIÓN2 PE 4 PE 8 PE 16 PE 32 PE 64 PEÓptima 2,00 4,00 8,00 16,00 32,00 64,00Dotplot Buchnera 2,00 3,87 7,58 14,17 25,13 53,06Frag. E.Coli y B.Subtilis 1,96 3,80 7,84 15,84 31,04 61,44Fragmentos Buchnera 1,95 3,78 8,00 16,00 31,68 59,58Blast 161.000 singletons 1,98 3,96 7,88 15,74 30,86 56,66Los programas se han comprobado a fin de confirmarque reproducen los resultados originales como semuestra en la figura 2, en la que se muestran las seisFig.3. Resultados de aceleración en las implementacionespropuestas, en las que se observa un comportamiento cercano alideal tanto para el proceso de la matriz de puntos, para la obtenciónde todos los fragmentos mayores que una longitud mínima (a partirde ahora, Fragmentos), y para el Blast en ejecuciones de casosreales. Para el caso de los Dotplots y Fragmentos, estos resultadoscorresponden a las secuencias Buchnera APS y BPS (600 KB),mientras que para Blast se han utilizado un conjunto de 120.000contigs y 161.000 singletons que hacen las veces de secuenciasproblema. Para conjuntos de datos mayores, los resultados sonincluso mejores, demostrando la escalabilidad de la solución, tal ycomo se puede ver en la ejecución de Fragmentos para las bacteriasE. Coli (4,5 MB) y B. Subtilis (4,1 MB). Para datos de tiempos, verla tabla 3.JP2011-534

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA 3DETALLES DE LOS DATOS DE TIEMPO ASOCIADOS A LAS IMPLEMENTACIONES PROPUESTAS (CONTINUACIÓN FIGURA 3).Dotplot BuchneraTIEMPO2 PE 4 PE 8 PE 16 PE 32 PE 64 PEÓptimo 03:21:48 01:40:54 00:50:27 00:25:14 00:12:37 00:06:19Map-Reduce 03:19:47 01:44:17 00:53:07 00:30:00 00:15:20 00:07:24Fragmentos E. Coli y B. Óptimo 50:40:00 25:20:00 12:40:00 06:20:00 03:10:00 01:35:00Subtilis Map-Reduce 51:40:00 26:40:00 12:49:25 06:21:40 03:14:50 01:38:00Fragmentos BuchneraBlast 161.000 singletonsÓptimo 01:05:00 00:32:30 00:16:15 00:08:08 00:04:04 00:02:02Map-Reduce 01:06:37 00:34:17 00:16:15 00:08:08 00:04:06 00:02:10Óptimo 00:58:10 00:29:05 00:14:33 00:07:17 00:03:39 00:01:50Map-Reduce 00:58:37 00:29:21 00:14:46 00:07:24 00:03:47 00:02:02APS y BPS de algo más de 600 KB de longitud;mientras que en las Comparaciones por Semejanza, sehan utilizado 161.000 secuencias (singletonsprocedentes de un proceso de ensamblaje) que soncontrastadas contra 120.000 grupos (contigs) desecuencias. También se han realizado pruebas con unacarga de datos mayor como son las bacterias E. Coli yB. Subtilis de más de 4 MB de longitud mediante lacomparación por semejanza. Los resultados indican queestas implementaciones escalan linealmente con elnúmero de procesadores con aceleraciones cercanas ala máxima. Se ha probado el rendimiento paravolúmenes de datos o carga computacional menor, ycomo cabría esperar, cuando el número de procesadorescrece, la carga por proceso no es suficiente paracompensar la latencia de inicio de los procesos y, portanto, el número de procesadores debe fijarse enfunción de la carga para alcanzar buenos rendimientos.IV. CONCLUSIONESLa computación en la Cloud abre nuevasoportunidades para acercar la computación de altorendimiento a laboratorios que requieren procesargrandes cantidades de datos pero que no disponen deinfraestructura computacional adecuada. Por otra parte,la bioinformática ha despegado como una línea deinvestigación en la que el desarrollo de software tieneque lidiar con el problema de los grandes conjuntos dedatos. Existe una gran diversidad de aplicaciones eneste campo, pero en su práctica totalidad estánpreparadas para una ejecución secuencial y unascondiciones que ya han dejado de estar presentes.Este documento se centra en el desarrollo de unmarco de trabajo que permita la reutilización de estasaplicaciones en entornos paralelos, exigiendo que no setoque el código secuencial ya que muchas de ellas sonaplicaciones bastante antiguas aunque válidas (legacyapplications). El desarrollo es en idea sencillo, aunquerequiere una programación eficiente y cuidadosa paramanejar situaciones de conflicto, como es el fallo deprocesos, su sincronización, y el balanceo de la carga.Los mayores problemas encontrados, como era deesperar, han sido en el ámbito de la E-S. Para el caso deredes de ordenadores, siempre es posible utilizar losdiscos locales para evitar el cuello de botella en elsistema de almacenamiento al concurrir a él cientos ypotencialmente miles de procesos. Cuando no sedispone de este sistema distribuido de almacenamiento,el cuello de botella impide escalar bien a la aplicación.Por ello en algunos casos es necesario abordar tanto lareformulación como el diseño de nuevo software.También es cierto que el sistema es válido paraaplicaciones que deben llevar adelante una serie detareas más o menos homogéneas y que procesos de unasola tarea y con grandes dependencias de datos, son enprincipio difíciles de adecuar a este entorno. Sinembargo, una estimación realizada en nuestro grupo,calcula que no más del 20% de los programasbioinformáticos tienen este diseño, por lo que laaproximación sigue siendo válida para el granporcentaje de aplicaciones bioinformáticas.Aunque las aplicaciones presentadas en estedocumento tienen un patrón de cálculo bastante regular(en el caso de los dotplots se ha usado un código defuerza bruta) la introducción de heterogeneidad en lastareas (que no la de interdependencias) es aúnmanejable vía el uso de una distribución de carga másinteligente (guiada, por ejemplo) con resultadossatisfactorios. Por tanto, no hay dependencia con laoptimización de los cálculos que puedan introducirnuevas versiones de los algoritmos.Finalmente, el desarrollo de este entorno de trabajopermitirá llevar a una ejecución paralela a cientos deprogramas en el ámbito bioinformático, abriendonuevas oportunidades para el análisis de datos y para laciencia en general.AGRADECIMIENTOSEste trabajo ha sido parcialmente financiado por elInstituto Nacional de Bioinformática, plataforma delInstituto de Salud Carlos III; la Acción Integrada delPrograma Nacional de Internacionalización de la I+D;Subprograma: Acciones Integradas 2009; Ministerio deCiencia e Innovación. Referencia AT2009-0025 y elprograma Virtual Multidisciplinary EnviroNmentsUSing Cloud Infrastructures, FP7-VENUS-C(www.venus-c.eu).REFERENCIAS[1] Armbrust M, Fox , et al. Above the Clouds: A Berkeley View ofCloud Computing. Technical reportJP2011-535

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-536

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011AbFS: Sistema de Ficheros AbiertoAntonio F. Díaz 1 , Mancia Anguita 1 , Hugo E. Camacho 1 , Erik Nieto 1 , Julio Ortega 1Resumen—AbFS es un sistema de ficheros distribuidoque permite que se compartan los dispositivos dealmacenamiento local de bajo coste que tienen loscomputadores de un cluster. Se ha implementado en elnúcleo de sistema operativo. La implementación de lagestión de metadatos de AbFS mezcla en la mismaestructura el espacio de nombres y los atributos, y combinahash, tablas, estructuras jerárquicas y caches. Con estaúltima combinación evita los problemas que presentan lasimplementaciones basadas en hash y las basadas en tablas.AbFS usa caches de metadatos y de datos en los clientes.Las caches comparten el mismo protocolo demantenimiento de coherencia y aprovechan las estructurasde cache de Linux reduciendo, de esta forma, lacomplejidad añadida. En este trabajo se presenta, ademásde una breve descripción de la implementación de lagestión de metadatos y de las caches en el cliente, algunosresultados experimentales. Estos resultados muestran lasbuenas prestaciones de las implementaciones propuestas.Palabras clave—Sistemas de ficheros distribuidos,metadatos, cache de datos, cache de metadatos.AI. INTRODUCCIÓNctualmente resulta asequible disponer de unconjunto de PC o servidores conectados a través deuna red. El almacenamiento local de estoscomputadores se puede compartir por las aplicacionesque ejecutan usando sistemas de ficheros distribuidoscomo PVFS [1], Lustre [2] o Ceph [3]. Al igual queestos sistemas de ficheros, AbFS permite que todos loscomputadores de un cluster puedan compartir losdispositivos de almacenamiento que tienen directamenteconectados.Un sistema de ficheros distribuido como AbFS,teniendo en cuenta que aprovecha el almacenamiento debajo coste disponible en los nodos de cómputo y que sepueden conectar estos nodos con redes de prestacionessimilares a las redes de área de almacenamiento o SAN(Store Area Networks), puede potencialmente ofrecer unalmacenamiento de bajo coste que compita enprestaciones con los almacenamientos sistemas deficheros basados en SAN, como IBM GPFS [4], RedHatGFS [5], SGI CXFS, Oracle OCFS o PolyServe.Para poder alcanzar unas altas prestaciones yescalabilidad, el sistema de ficheros tiene que conseguir,además de unas altas prestaciones en el acceso a losdatos, también en los accesos a metadatos. Hay quetener en cuenta que las peticiones de acceso a metadatospueden suponer más del 50% de todas las peticionesgeneradas [6],[7],[8]; por tanto, las prestaciones de losaccesos a metadatos son importantes y para que escalen,especialmente en sistemas grandes, se deberían distribuirentre múltiples servidores de metadatos.La gestión de metadatos no sólo incluye el acceso alespacio de nombres, a los atributos de los ficheros y alas direcciones de los bloques, también sincronizaactualizaciones concurrentes, controla los accesos ymantiene consistencia entre los datos de usuario y losmetadatos de los ficheros.AbFS utiliza cache en los clientes y servidores paramejorar las prestaciones en la lectura y escritura demetadatos y de datos. No todas las aplicaciones sebenefician del uso de cache de datos; el sistema deficheros Google File System [9], por ejemplo, no usacache de datos en los clientes porque no resulta rentablepara la mayor parte de su carga de trabajo. Pero hayaplicaciones que se benefician de esta cache porquepresentan proximidad espacial y temporal en los accesoso porque constan de varios programas que se comunicana través de ficheros.En este trabajo se presenta la implementación y lasprestaciones de la gestión de metadatos y de la cache dedatos en los clientes de AbFS. Las implementaciones sehan realizado en el kernel. Los resultadosexperimentales se han obtenido con un prototipo delsistema de ficheros de 64 bits completo que usa extentpara la gestión de bloques.El resto de este trabajo se ha organizado en variassecciones. La Sección II presenta la implementación dela gestión de metadatos y sus prestaciones evaluadas enel prototipo de AbFS implementado. La Sección IIIresume la implementación de la cache en los clientes ymuestra las prestaciones de la cache de datos en elprototipo. Por último, la Sección IV resume lasconclusiones del trabajo presentado y el trabajo futuro.II. GESTIÓN DE METADATOSA. Implementación de la gestión de metadatosAbFS es un sistema de ficheros simétrico; es decir, loscomputadores en una plataforma con AbFS pueden ser ala vez clientes, servidores de datos y servidores demetadatos. No obstante, podría configurarse para quealgunos nodos no compartan sus dispositivos dealmacenamiento (Fig. 1), podrían ser sólo clientes.Igualmente puede haber nodos que actúen sólo comoservidores.AbFSImagen única del almacenamientoRedAbFSAbFS1 Dpto. Arquitectura y Tecnología de Computadores, Universidad deGranada, e-mail: {afdiaz,manguita,hcamacho,enieto,jortega}@atc.ugr.esFig. 1. Sistema AbFSJP2011-537

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Todos los componentes de AbFS (inodos, ficheros, etc.)están compuestos de bloques lógicos de 4KB. Elidentificador de un bloque lógico consta de 64 bits, 12de esos bits identifican el volumen donde se encuentraalmacenado y los 52 bits restantes el bloque dentro delvolumen. El volumen es una partición en un disco.AbFS utiliza tres estructuras para gestionar losmetadatos: una tabla de volúmenes, una tabla dedelegación y una estructura inodos. La estructura deinodos realmente está fundida con la estructura dedirectorio; están ambas, por tanto, almacenadas juntas endisco. Se ha hecho así para ahorrar tiempo porque unapetición de acceso a la estructura de directorios suelevenir seguida de una petición de acceso a los atributosdel fichero al que se accede. Las tablas de delegación yla de volúmenes están replicadas en todos los nodos.Un servidor de datos y metadatos puede contenervarios volúmenes como refleja la Fig. 1. La tabla devolúmenes relaciona cada volumen con el servidordonde se encuentra.En la Fig. 2 se puede ver un ejemplo de tabla dedelegación, en este caso con 32.768 entradas. En lafigura también aparecen las sub-tablas de la estructurade inodos. Cada inodo en una estructura de inodos ocupa512 bytes.El descriptor interno de un fichero o de un directorio esel identificador del inodo donde se encuentran susmetadatos. Usando una función hash (Fig. 2) se obtieneel descriptor interno de un fichero a partir de su nombreexterno (lógico) y del descriptor interno de su directoriopadre. El descriptor interno o identificador del inodo secompone de:• N bits de delegación que identifican la entrada delinodo en la tabla de delegación o tabla hash. N es 15bits en la Fig. 2. Esta entrada informa del volumen yde la sub-tabla dentro de éste donde se encuentra elinodo.• 32-N bits que identifican al inodo dentro de la subtablaa la que apunta la entrada del inodo en la tablade delegación.N es un valor máximo, se pueden usar menos bits si elnúmero de volúmenes es reducido; es decir, en realidadse usa un hash extensible [10] para permitir unredimensionado de bajo coste de la tabla de delegación.El tamaño de la tabla de delegación va a depender, portanto, del número de volúmenes; es decir, del tamaño delsistema. En el ejemplo de la Fig. 2 hay 32.768 entradasen la tabla de delegación y 16 volúmenes. En el sistemade ficheros IBM GPFS[4] y en la implementación demetadatos propuesta en [11] se utiliza un hash extensiblepara la gestión de grandes directorios.Como se ha mencionado, cada entrada en la tabla dedelegación apunta a un volumen y a una sub-tabla deinodos dentro de ese volumen (apunta al primer bloquede la sub-tabla). El número de sub-tablas de un volumeny, por consiguiente, el número de entradas de la tabla dedelegación asignadas a un volumen, depende de sutamaño. AbFS reparte las entradas aleatoriamente entrelos volúmenes teniendo en cuenta sus tamaños. Tiene encuenta el tamaño porque asume que la capacidad dealmacenamiento de un servidor está relacionada con susprestaciones. De esta forma distribuye la gestión demetadatos entre los servidores para que quedebalanceada. AbFS distribuye ficheros entre volúmenesen lugar de distribuirlos entre servidores de metadatos.En el caso de las implementaciones basadas en hash yFig. 2. Delegation table and inode subtablesJP2011-538

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tabla de [12] se distribuyen ficheros entre servidores demetadatos y en la de [11] se distribuyen subdirectoriosentre servidores de metadatos.Si se añade un nuevo volumen se modifican algunasentradas de la tabla de delegación para que algunosinodos migren al nuevo volumen, la migración se hacepara mantener balanceada la gestión de metadatos. Eluso de la tabla de delegación evita que añadir volúmenesimplique redistribuir todos los inodos entre todos losvolúmenes como ocurre en la implementación demetadatos del sistema de ficheros Vesta [13]. En estesistema de ficheros se usa una hash para distribuir losficheros entre los servidores de metadatos. La hash usacomo entrada el nombre absoluto (camino completo) delfichero. El servidor de metadatos se obtiene calculandoel módulo de esta salida con respecto al número deservidores. Dada la implementación, cuando se añade unservidor, puede cambiar el resultado del módulo.Obsérvese que sólo cuando se desconoce elidentificador de inodo de un fichero (se ejecuta unlookup) es cuando éste se obtiene a partir delidentificador inodo de su directorio padre y de sunombre usando una función hash (Fig. 2). En [12] y en[11] se usa una implementación basada en una funciónhash y una tabla, pero como entrada a la función hash seutiliza el camino completo (nombre absoluto) delfichero. AbFS usa el nombre del fichero en lugar delcamino completo y mantiene el identificador de inododel directorio padre constante por lo que, cuando serenombra el directorio, evita la redistribución de datosentre volúmenes ya que no cambia la salida de lafunción hash.Para mejorar las prestaciones adicionalmente,especialmente con un número de ficheros elevado, AbFSusa más de un nivel de hash/tabla para localizar la subtabladel inodo buscado. Los inodos de una sub-tabla(Fig. 2) están indexados en una estructura de hasta tresniveles para obtener un acceso rápido.B. Resultados experimentalesLos resultados experimentales mostrados en esteapartado se han obtenido con doce nodos, cada uno condos procesadores Quad-Core Intel Xeon E5450 de 3GHz y 16GB RAM, conectados con un conmutadorInfiniband MT25418 de Mellanox usando IPoIB.Para la evaluación de prestaciones se ha usado elbenchmark mdtest. En la entrada de mdtest se haespecificado que cada cliente genere tres directorios y50.000 ficheros/directorios en cada uno. Con mdtest sepueden evaluar las prestaciones de las operaciones demetadatos más comunes, como son la creación y laoperación stat de ficheros y directorios. Utiliza MPI parala coordinación y sincronización entre nodos.En la Fig. 3 se pueden ver las prestaciones para lacreación de ficheros y directorios usando 12 nodos. Seisde ellos se usan como servidores (de datos y metadatos).Como clientes se pueden usar los doce nodos (el total declientes depende del número de procesos). La Fig. 4muestra las prestaciones para stat con la mismaconfiguración. Como se puede observar en estas figuras,las prestaciones escalan linealmente hasta que se usanlos 12 clientes, es decir, hasta 12 procesos. El escaladose frena cuando se supera el número de clientes porquelos procesos de un cliente compiten por los recursos.Fig. 3. Prestaciones de la creación (operaciones por segundo) dedirectorios y ficheros con 12 nodos: 6 servidores, 12 clientesFig. 4. Prestaciones de stat (operaciones por segundo) de directorios yficheros con 12 nodos: 6 servidores, 12 clientesFig. 5. Prestaciones de creación (operaciones por segundo) dedirectorios y ficheros con 12 nodos: 6 servidores más 6 clientesFig. 6. Prestaciones de stat (operaciones por segundo) de directoriosy ficheros con 12 nodos: 6 servidores más 6 clientesJP2011-539

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Esto se puede ver con más claridad en las Figuras 5 y 6,en las que se muestran las prestaciones para creación(Fig. 5) y para stat (Fig. 6) con 12 nodos, seis de ellosservidores y los otros seis clientes.Las prestaciones de la gestión de metadatos en AbFSson claramente mejores que las prestaciones de Lustre(1.6, 20) [14, 15], PVFS [16] y Ceph [3] encontradas enla bibliografía. Los resultados de [15] se han obtenido en70 clientes con Pegasus+ blades de 4 procesadoresQuad-Core AMD Opteron(tm) 8380 16GB RAM y unservidor de metadatos Sun Fire X4540 (Thor) con 2Quad-Core AMD Opteron(tm) 2356 64GB RAM. Lamáxima velocidad de creación de directorios y ficherosalcanzada con Lustre 2.0 usando mdtest es de unos7.500 y unos 900 operaciones/segundo, respectivamente.Para stat las prestaciones son de unos 25.800operaciones/segundo para directorios y 25.000 paraficheros. Estas versiones de Lustre aún no distribuye lagestión de metadatos entre varios servidores, el uso deun único servidor de metadatos limita las prestaciones(tiene otro servidor de metadatos, pero lo usa derespaldo). Se prevé que Lustre 3 distribuya la gestión demetadatos entre varios servidores.III. CACHE EN CLIENTESA. Implementación de la cacheAbFS utiliza cache en los clientes para mejorar lasprestaciones en la lectura y escritura de datos ymetadatos. Aprovecha la cache de buffer de dispositivode Linux para implementar la cache de datos del clientey las caches de metadatos de Linux (inode y dentry) paraimplementar las caches de metadatos en los clientes. Deesta forma no ha sido necesario añadir capas extras paraimplementar estas caches. La cache de datos aprovechala lectura adelantada (pre-captación) que implementaVFS (Virtual File System) para la cache de buffer dedispositivo.Usar caches mejora las prestaciones porque reducen eltiempo de acceso a los datos por estar más cerca y,adicionalmente, también porque disminuyen los accesosal servidor y, por tanto, su congestión. En AbFS, lascaches reducen la congestión de los servidores y de lascaches del servidor también cuando se abre un ficheropara escritura. El primer nodo que abre un fichero paraescritura es el propietario del fichero. Se consiguereducir la congestión porque los clientes que escriben enel fichero combinan las escrituras en la cache delpropietario en lugar de ir al servidor y porque losclientes leen, cuando hay propietario, de la cache delpropietario en lugar de leer del servidor. En estasituación, es decir, cuando hay propietario, la cachetiene unas prestaciones similares a la cache cooperativabasada en home de [17]. Como se puede deducir AbFSañade comunicaciones cliente-cliente y servidorservidora las comunicaciones cliente-servidor utilizadasen sistemas de ficheros basados en el modelo clienteservidor,como NFS.La Fig. 7 resume el protocolo de coherencia de cacheen el cliente. Aunque los bloques de la cache de bufferNº Estado Evento Comentario Sig. estado1 (C) Interno al nodo: lookup o dir-create Inodo compartido (S)2 (C) Interno al nodo: fichero create Nodo gana la propiedad del inodo (E)3 (C)Interno al nodo: lookup, o abre el fichero y está yaabierto para escritura en otro nodoNodo no gana la propiedad del inodo (I)4 (S)Externo al nodo: invalidación.Interno al nodo: lookup, o abre fichero y otro nodo Nodo no gana la propiedad del inodo (I)tiene la propiedad del mismo5 (S)Interno al nodo: abre el fichero para escribir (1 er nodoque lo abre para escribir)Nodo gana la propiedad del inodo (E)6 (E)Interno al nodo: cierra el fichero abierto paraescrituraInodo compartido y escritura al servidor (S)7 (E) Servidor deniega propiedad Excepción (I)8 (I) Interno al nodo: lookup, o abre el fichero para leer Inodo compartido (S)9 (I)Interno al nodo: abre el fichero para escribir (1 ernodo que lo abre para escribir)Nodo gana la propiedad del inodo (E)Fig. 7. Resumen del protocolo de coherencia de cache basado en propietarioJP2011-540

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de dispositivo son de 4KB, el bloque en el protocolo demantenimiento de coherencia es un fichero (se aplica alinodo). Un inodo en la cache del cliente o del servidorpuede estar en uno de estos estados:• (C)lear: el inodo no está en la cache (puede existir endisco). Es el estado inicial de todos los inodos.• (E)xclusivo: los datos y metadatos del inodo sonválidos únicamente en esta cache, es decir, en lacache del nodo propietario. Los otros nodos no tienencopias válidas. El nodo propietario es el primer nodoque abre un fichero para escribir en él.• (S)hared o compartido: los datos y metadatos delinodo son válidos en este cache y pueden ser válidostambién en las caches de otros nodos.• (I)nválido: los datos y metadatos del inodo soninválidos.B. Resultados experimentalesLas ejecuciones se han realizado en la misma plataformautilizada en los test de la Sección II.La Fig. 8 ilustra sobre la ventaja de usar la cache dedatos. Los tiempos de lectura y escritura se reducen enun 97% aproximadamente si los datos se encuentran enla cache. Las prestaciones mejoran más que con la cacheque hemos implementado desde cero para el sistema deficheros PVFS [18].IV. CONCLUSIONESEste trabajo muestra unas buenas prestaciones de laimplementación de gestión de metadatos del sistema deficheros AbFS. Así, por ejemplo, con 12 nodos, 6servidores y hasta 12 clientes, se consiguen más de65.000 operaciones por segundo para creación dedirectorios, más de 90.000 para creación de ficheros,más de 5.500.000 para operaciones stat de directorios ymás de 5.800.000 para stat de ficheros.Igualmente muestra las buenas prestaciones de laimplementación de cache de datos en los clientes deAbFS, que aprovecha la cache de buffer de dispositivode Linux. Las caches de metadatos y datosimplementadas permiten escritura en la cache sinintervención del usuario ya que mantienen coherencia.Como trabajo futuro se pretende realizar experimentoscon un mayor número de nodos y comparaciones en laFig. 2. Prestaciones de la cache de datos. wr_no_cache y rd_no_cacheson escrituras y lecturas, respectivamente, sin cache. wr_cache yrd_cache son escrituras y lecturas, respectivamente, en la cachemisma plataforma con otros sistemas de ficheros, comoCeph, Lustre y PVFS.AGRADECIMIENTOSLos autores agradecen a Catón Sistemas Alternativos susoporte y a la Fundación Centro de Supercomputaciónde Castilla y León (FCSCL) el acceso a uno de loscluster del supercomputador Caléndula. Este trabajo hasido financiado parcialmente por el proyecto TEC2010-15396.REFERENCIAS[1] P. H. Carns, W. B. Ligon III, R. B. Ross and R. Thakur, "PVFS: Aparallel file system for linux clusters," in Proceedings of the 4thAnnual Linux Showcase and Conference, 2000, pp. 317-327.[2] P. J. Braam, "The Lustre Storage Architecture," November, 2002.[3] S. A. Weil, S. A. Brandt, E. L. Miller, D. D. E. Long and C.Maltzahn, "Ceph: A scalable, high-performance distributed filesystem," in OSDI '06: Proceedings of the 7th Symposium onOperating Systems Design and Implementation, Seattle,Washington, 2006, pp. 307-320.[4] F. Schmuck and R. Haskin, "GPFS: A shared-disk file system forlarge computing clusters," in FAST '02: Proceedings of the 1stUSENIX Conference on File and Storage Technologies, Monterey,CA, 2002, pp. 19.[5] S. R. Soltis, T. M. Ruwart and M. T. O'Keefe, "The global filesystem," in Proceedings of the Fifth NASA Goddard Conferenceon Mass Storage Systems and Technologies, 1996, pp. 319-342.[6] J. K. Ousterhout, H. Da Costa, D. Harrison, J. A. Kunze, M.Kupfer and J. G. Thompson, "A trace-driven analysis of the UNIX4.2 BSD file system," in SOSP '85: Proceedings of the TenthACM Symposium on Operating Systems Principles, Orcas Island,Washington, United States, 1985, pp. 15-24.[7] D. Roselli, J. R. Lorch and T. E. Anderson, "A comparison of filesystem workloads," in ATEC '00: Proceedings of the AnnualConference on USENIX Annual Technical Conference, San Diego,California, 2000, pp. 4-4.[8] SPEC, "SPECsfs2008 user's guide v. 1.0," Standard PerformanceEvaluation Corporation (SPEC), 6585 Merchant Place, Suite 100,Warrenton, VA 20187, USA, 2008. 2008.[9] S. Ghemawat, H. Gobioff and S. Leung, "The google file system,"in SOSP '03: Proceedings of the Nineteenth ACM Symposium onOperating Systems Principles, Bolton Landing, NY, USA, 2003,pp. 29-43.[10] R. Fagin, J. Nievergelt, N. Pippenger and H. R. Strong,"Extendible hashing---a fast access method for dynamic files,"ACM Trans.Database Syst., vol. 4, pp. 315-344, 1979.[11] M. Xiong, H. Jin and S. Wu, "FDSSS: An efficient metadatamanagement scheme in large scale data environment," in FifthInternational Conference on Grid and Cooperative ComputingWorkshops, GCCW '06, 2006, pp. 71-77.[12] S. A. Brandt, E. L. Miller, D. D. E. Long and Lan Xue, "Efficientmetadata management in large distributed storage systems,"Proceedings 20th IEEE/11th NASA Goddard Conference on MassStorage Systems and Technologies, MSST 2003., pp. 290-298,2003.[13] P. F. Corbett and D. G. Feitelson, "The vesta parallel file system,"in High Performance Mass Storage and Parallel {I/O}:Technologies and Applications, H. Jin, T. Cortes and R. Buyya,Eds. New York, NY: IEEE Computer Society Press and Wiley,2001, pp. 285-308.[14] W. Turek and P. Calleja, High Performance, Open Source, DellLustre Storage System. White Paper. Dell - University ofCambridge, 2010.[15] P. Kondekar, MDS Performance Analysis. Sun Microsystems,2009.[16] J. M. Kunkel and T. Ludwig, "Performance evaluation of thePVFS2 architecture," in 15th EUROMICRO InternationalConference on Parallel, Distributed and Network-BasedProcessing, 2007, pp. 509-516.[17] I. Hwang, S. Maeng and J. Cho, "Home-based CooperativeCache for parallel I/O applications," Future Generation ComputerSystems, vol. 22, pp. 633-642, 2006/4.[18] H. E. Camacho, E. Nieto, M. Anguita, A. F."Client cache for PVFS2," in 1st International Conference onJP2011-541

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Parallel Distributed and Grid Computing (PDGC),2010, pp. 38-43.JP2011-542

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Comparación del rendimiento entre loshipervisores XEN y KVM usando virtualizaciónIsaac Zablah por hardware1 , R. Valin 2 , A. García-Loureiro 2 , Javier López Cacheiro 3 , Fernando Gomez-Folgar 3Resumen 1 — El presente artículo muestra los resultadosobtenidos tras ejecutar un conjunto de benchmarks enanfitriones y máquinas virtuales gestionadas con loshipervisores Xen y KVM. La finalidad fue determinar cuálde ellos era más eficiente para las aplicaciones tipo quepretendemos ejecutar en la infraestructura computacionaldel proyecto Formiga Cloud. En los resultados obtenidos,se observó que las máquinas virtuales de Xen presentan unmejor rendimiento con aplicaciones de cálculo que lasmáquinas virtuales de KVM, mientras que para laspruebas de escritura en disco, el rendimiento de lasmáquinas virtuales de KVM es mejor que el de lasmáquinas virtuales de Xen.Palabras clave— Benchmarks, XEN, KVM, máquinasvirtuales, hipervisores.I. INTRODUCCIÓNDurante los últimos años hemos asistido a undesarrollo notable de las infraestructuras Cloud, asícomo de los fundamentos tecnológicos que permiten suimplementación, entre los que se destacan laarquitectura orientada a servicios (SOA) y lavirtualización Hardware y Software [1]. En el caso delas tecnologías de virtualización, éstas son uno de losprincipales fundamentos del modelo Cloud conocidocomo infraestructura como servicio (IaaS), basado en lagestión de los recursos hardware.El proyecto Formiga Cloud [2] propone la creación deuna infraestructura Cloud, basada en el modelo IaaS,que permita el aprovechamiento de los recursoscomputaciones de las aulas de informáticapertenecientes a las universidades para su uso tanto entareas docentes como en tareas de cálculo científico.En el marco de este proyecto, se detectó la necesidadde realizar una evaluación del rendimiento de loshipervisores compatibles con la infraestructura FormigaCloud. Esto es debido a que es necesario utilizar latecnología de virtualización, para poder sacar provechode los ordenadores disponibles dentro de una institucióndurante los períodos de inactividad. Con lo anterior, sepretende instalar sistemas virtualizados que se gestionende forma remota y en los que se pueda implementar unaarquitectura de computación distribuida, para que seanempleados con fines relacionados a la computaciónintensiva. Además, la infraestructura también estará1 Sistema de Difusión de Radio y Televisión – Universidad NacionalAutónoma de Honduras, e-mail: mrzablah@unah.tv2 Dpto. Electrónica y Computación, Universidad de Santiago deCompostela, e-mail: raul.valin@usc.es, antonio.garcia.loureiro@usc.es3Dpto. de Sistemas, Centro de Supercomputación de Galicia(CESGA), e-mail: jlopez@cesga.es, fgfolgar@cesga.esdisponible para fines docentes, permitiendo a losprofesores y alumnos desplegar máquinas virtuales(MV) bajo demanda.Para este estudio se han seleccionado los hipervisoresXen 4.0.2-rc3 con Linux kernel 2.6.32.37, sobre CentOS5.6 (Xen4), Xen 3.1.2-238.9.1.el5 con Linux kernel2.6.18-238.9.1.el5xen sobre CentOS 5.5 (Xen3) y KVMsobre Ubuntu 10.04.2 LTS con Linux kernel 2.6.32-31-server en combinación con la versión de qemu-kvm0.12.3(KVM), ya que son compatibles con lainfraestructura propuesta. Ambos son de código abiertoy se encuentran entre los más ampliamente utilizados enla computación de altas prestaciones. Para evaluar surendimiento se han ejecutado una serie de benchmarksestandarizados para estos fines, y se ha utilizado,también, una aplicación de computación intensiva. Hayque señalar que la finalidad de evaluar dos versionesdistintas de Xen es tasar sus respectivos rendimientos ysu repercusión en las MV. Adicionalmente, se evaluó unsistema con el kernel original de la distribución CentOS5.5, cuya versión es 2.6.18-238.12.1.el5, para conocer deigual forma los cambios de rendimiento al tenerinstalado el kernel Xen.En este trabajo se han evaluado tres aspectosesenciales en lo que se refiere a la comparación delrendimiento de la máquina virtual con la máquina física.El primero, la capacidad de cálculo usando LINPACK[3], el segundo, la evaluación de la entrada/salida deldisco duro por medio de una medición de la tasa detransferencia de escritura empleando IOZone [4] y,finalmente, la evaluación del rendimiento cuando seemplea una aplicación de cálculo científico.Este artículo se ha dividido en las siguientes secciones:en la sección dos se realiza una breve descripción de loshipervisores usados. En la sección tres se hace unadescripción de los benchmarks empleados. En la seccióncuatro se describen los resultados obtenidos y,finalmente, en la sección quinta se plantean y discutenlas conclusiones del trabajo realizado.II.DESCRIPCIÓN DE LOS HIPERVISORESEl hipervisor Xen [5] es una herramienta utilizadapara implementar la tecnología de virtualización, y quepermite la ejecución en las MV de una gran variedad desistemas operativos como, por ejemplo, Linux, BSD oWindows, entre otros. En su última versión [6],introduce optimizaciones en la gestión de cargas detrabajo, disminuyendo la latencia en aplicaciones de redy audio, entre otras. Actualmente, Xen permite utilizar eljuego de instrucciones más reciente de los procesadoresINTEL, como las llamadas “Advanced VectorJP2011-543

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011eXtension, AVX”, entre otras. Se implementa a través deun kernel modificado con el soporte de virtualización.Xen puede ejecutarse en modo paravirtualizado, dondese requiere adaptar el sistema operativo de la máquinavirtual (huésped), o en modo de virtualización completa,que no requiere efectuar modificaciones en el softwaredel huésped.El hipervisor KVM (Kernel Virtual Machine) [7],opera por medio de una serie de módulos cargadosdurante el arranque del sistema operativo, convirtiendo atodo el sistema en un gestor de virtualización, adiferencia de otros hipervisores que reescriben partes delsistema operativo creando un kernel personalizado. Conestos módulos, se ha logrado simplificar la gestión yaumentar el rendimiento de los entornos virtualizados,de manera que cada MV se ejecuta como un procesodentro del sistema operativo. KVM requiere para suejecución contar con un microprocesador con soportepara virtualización por hardware [8].III.DESCRIPCIÓN DE LOS BENCHMARKSCon la finalidad de evaluar y comparar el rendimientode las máquinas virtuales con las respectivas máquinasfísicas, se han seleccionado los siguientes benchmarks:IOZone [4]: es un benchmark sintético que se utilizapara conocer la medida de rendimiento del disco en losprocesos de lectura y escritura. Se ha utilizado unapartición al final del disco duro de 20 GB en la que seescribe el fichero temporal de esta aplicación, evitando,de esta forma, que los resultados se viesen alterados porescribir en distintas zonas del disco. La versiónempleada es la 3.385.Linpack [3]: es un benchmark sintético que se utilizapara conocer el rendimiento del sistema en cuanto acálculo. Fue desarrollado en el Argone NationalLaboratory por Jack Dongarra en 1976, y es uno de losmás usados a nivel científico [9]. Su característicafundamental es que hace un uso intensivo de lasoperaciones de punto flotante, y sus resultados son muydependientes de la capacidad de la unidad de puntoflotante (FPU) de los sistemas evaluados. Para esteartículo se utilizó la distribución del Linpack versión10.3.3 que Intel tiene disponible como parte de susherramientas Math Kernel.Simulador de Nanodispositivos MOSFET: es unaaplicación de cálculo científico utilizada en el campo dela simulación de tipo Monte Carlo [10] para dispositivossemiconductores. Se ha aplicado al estudio detransistores MOSFET (Metal Oxide SemiconductorField Effect Transistor), que son los dispositivoselectrónicos más utilizados en la industria electrónicahoy en día, ya que han permitido alcanzar una mayorcapacidad de integración en los diseños de circuitospermitiendo fabricar procesadores de mayorrendimiento.IV.RESULTADOSEn esta sección se muestran los resultados de laejecución de las distintas pruebas de rendimiento. Seempleó un ordenador TOSHIBA Qosmio X500 con unprocesador Intel Core i7 Q720 @ 1.60Ghz, con 4GB deRAM y disco duro de 500GB de 7200RPM SATAIIpara las pruebas del hipervisor KVM. Para las pruebascon el hipervisor Xen se empleó un ordenador conprocesador Intel Xeon E5520 @ 2.27GHz, con 16GB deRAM y disco duro de 500GB de 7200RPM.Las características de configuración de las MV y delos sistemas anfitriones se describen a continuación:• Se desactivó la memoria SWAP tanto en lossistemas anfitriones como en las máquinasvirtuales.• En todas particiones se empleó el formatoEXT2.• Se utilizó la misma cantidad de memoria RAMpara la ejecución de las pruebas en todos lossistemas (1GB).• Se desactivó la funcionalidad deHyperthreading del microprocesador y ademássólo se ha empleado un núcleo en todas laspruebas.• En el caso de la prueba de IOZone, se utilizóuna partición ubicada al final del disco duro, demanera que todas las pruebas se ejecutaron enlas mismas condiciones (en la misma región deldisco).• Se desactivó la utilidad CPUSpeed, que vieneintegrada en varias distribuciones de Linux.• Todos los sistemas operativos se utilizaron ensu versión de 64bits.• En el caso de KVM, se empleó la utilidad “virtmanager”para gestionar las máquinas virtualesy, además, en ellas se emplearon loscontroladores VirtIO [11].A continuación, se presentan los resultados para cadauno de los benchmarks realizados:A. Prueba con LinpackEn esta prueba se utilizó un tamaño de problema y dedimensiones de 5000, con valores de alineación de4KBytes. Linpack proporciona una medida promedio dela capacidad de procesamiento en unidades deGigaFLOPS (GFlops). Los resultados absolutos semuestran en la Tabla 1:SISTEMAGFlopsRESULTADOSTiempo (s)Anfitrión KVM 8.61 57.30MV KVM 5.54 85.07Anfitrión NoXen 8.36 59.49Anfitrión Xen3 8.44 59.59MV Xen3 6.76 74.47Anfitrión Xen4 8.16 60.95MV Xen4 8.12 61.13Tabla 1: Resultados con LINPACKLos resultados de la Tabla 1 muestran que en el casode la MV en KVM tiene una pérdida de rendimiento de3.07 GigaFLOPS respecto al anfitrión; requiriendo laJP2011-544

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011MV sólo 27.77 segundos adicionales para completar laprueba. En Xen3, La MV fue menos eficiente que elanfitrión, perdiendo 1.68 GigaFLOPS y requiriendo14.88 segundos adicionales para completar la prueba. EnXen4, los rendimientos fueron muy parecidos entre laMV y el anfitrión, donde se presentó una mínimapérdida de 0.04 GigaFLOPS por parte la MV. Esimportante mencionar que el anfitrión Xen3 obtuvoresultados más altos en este benchmark que el anfitriónsin el kernel de Xen, superando a éste por 0.08GigaFLOPS. Sin embargo, el anfitrión Xen4 rindiómenos que el sistema con kernel original perdiendo 0.20GigaFLOPS.El rendimiento en GigaFLOPS de los sistemasevaluados siguió el comportamiento que muestra laGráfica 1:Gráfica 1: Comportamiento de los sistemas evaluados conLinpackEn cambio, el comportamiento relativo que existeentre las MV/anfitriones y entre los anfitriones y lamáquina sin modificar se muestra en la Tabla 2:MÁQUINA VIRTUALRENDIMIENTO RESPECTO ALANFITRIÓN (%)MV KVM 64.34%MV Xen3 80.09%MV Xen4 99.51%SISTEMAANFITRIÓNRENDIMIENTO RESPECTO ALANFITRIÓN SIN KERNELMODIFICADO(%)Anfitrión KVM 103.00%Anfitrión Xen3 101.00%Anfitrión Xen4 97.61%Tabla 2: Valores relativos porcentuales obtenidos entre lasmáquinas virtuales y sus respectivos anfitriones, y de estoscon el sistema con kernel sin modificar (Anfitrión NoXen).del anfitrión KVM, éste obtuvo 3% más rendimiento queel sistema original sin modificaciones. Lo mismosucedió con el anfitrión con Xen3 que aumentó 1%. Encambio, el anfitrión con Xen4 perdió 2.39% derendimiento frente al sistema sin modificaciones.B. Prueba con IOZoneCon el test de acceso al disco, se evaluó la tasa detransferencia para completar un proceso de escritura deun archivo de 4GB. La prueba se realizó en unapartición dedicada ubicada al final del disco duro. Losresultados se muestran en la Tabla 3:SISTEMATasa deEscrituraKbytes/sRESULTADOSTasa de Re-EscrituraKbytes/sAnfitrión KVM 47273 50416MV KVM 45494 46906Anfitrión NoXen 95605 67530Anfitrión Xen3 92744 66445MV Xen3 47026 31639Anfitrión Xen4 86836 95387MV Xen4 49797 61480Tabla 3: Tasas de transferencia en escritura y re-escrituraen IOZone.En la Tabla 3, el mayor rendimiento en la tasa deescritura lo obtuvo el sistema con el kernel sinmodificar, y en la tasa de re-escritura el mejor resultadofue el del anfitrión con Xen4. En KVM, la MV obtuvoun rendimiento en la tasa de escritura de 1779 Kbytes/sinferior al anfitrión, y en la tasa de re-escritura sucediólo mismo pero con una diferencia de 3510 Kbytes/s. Eneste caso, hay que señalar que el controlador VirtIOemplea por defecto caché, para la gestión delalmacenamiento, en modo Writethrough y ello repercuteen los resultados obtenidos. En el caso Xen3, la MVpresentó una diferencia de rendimiento de 45718Kbytes/s en tasa de escritura y de 34806 Kbytes/s entasa de re-escritura inferior al anfitrión. Lo mismosucedió con Xen4, donde la MV obtuvo diferencias de37039 Kbytes/s en tasa de escritura y de 33907 Kbytes/sen tasa de re-escritura frente al anfitrión. Todos losanfitriones presentaron rendimientos inferiores que lamáquina con el kernel sin modificar.En la Gráfica 2 se muestran las tasas de transferenciade los sistemas evaluados (anfitriones y MV), tomandocomo valor de comparación la tasa de transferencia dedatos en los procesos de escritura y re-escritura.En la Tabla 2 se muestra una pérdida de rendimientode la MV con respecto al anfitrión inferior a un 1% en elcaso del hipervisor Xen4. Por otra parte, para el Xen3 laMV pierde 19.91% del rendimiento obtenido por suanfitrión. En cambio, con KVM la MV perdió un35.66% de rendimiento frente a su anfitrión. En el casoGráfica 2: Resultados de la prueba de IOZone.JP2011-545

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011El comportamiento relativo que existe entre lasMV/anfitriones y entre los anfitriones y la máquina sinmodificar se muestra en la Tabla 4:MÁQUINA VIRTUALRENDIMIENTO RESPECTO ALANFITRIÓN (%)Tasa deEscrituraTasa de Re-EscrituraMV KVM 96.24% 93.04%MV Xen3 50.71% 47.62%MV Xen4 57.35% 64.45%SISTEMAANFITRIÓNRENDIMIENTO RESPECTO ALANFITRIÓN SIN KERNELMODIFICADO(%)Tasa de Re-EscrituraTasa deEscrituraAnfitrión Xen3 97.01% 98.39%Anfitrión Xen4 90.82% 141.25%Tabla 4: Resultados relativos entre MV y anfitriones. Seincluye la relación entre los anfitriones con Xen y lamáquina con kernel sin modificar.En la Tabla 5, la MV en KVM requirió de 876.47segundos adicionales más que el anfitrión paracompletar la prueba. En caso de Xen3, la MV necesitóde 440.353 segundos más que el anfitrión y en Xen4 laMV requirió de 373.11 segundos más que el anfitrión.Entre las MV la más eficiente fue la de KVM al igualque el anfitrión; superando a la misma máquina con elkernel sin modificar.La Gráfica 3 representa las diferencias en los tiemposnecesarios para completar la prueba de nanodispositivos:En la Tabla 4, la MV en KVM obtuvo un rendimiento3.76% menor en escritura y 6.96% menor en re-escrituracon respecto al anfitrión. Para el caso de Xen3, ladiferencia entre los sistemas fue de un 49.29% enescritura y de un 52.38% en re-escritura obteniendomenos rendimiento la MV frente a su anfitrión. En elcaso de Xen4, las diferencias entre ambos sistemasfueron más pronunciadas, de forma que en modoescritura el sistema invitado presentó un 42.65% menosrendimiento que el anfitrión, y en el modo re-escritura elsistema invitado presentó 35.55% menos. Entre losanfitriones, el que presentó un mejor rendimiento en latasa de escritura fue Xen3 respecto al sistema sinmodificaciones, y en la tasa de re-escritura el anfitriónXen4 superó por 41.25% al sistema sin modificaciones.No se ha incluido en la comparación el anfitrión conKVM debido a diferencias importantes de hardwareexistentes con la máquina que ejecuta el kernel sinmodificar.C. Prueba con el Simulador de NanodispositivosMOSFETEn esta prueba se somete a todo el sistema a unaevaluación de la aplicación de cálculo científico quedescribimos en la sección anterior. El resultado de lamisma se cuantifica con el tiempo que requiere elsistema para obtener la simulación, de manera quecuanto menor sea el tiempo empleado mejor será elresultado. Los resultados se muestran en Tabla 5:SISTEMARESULTADOSTiempo (s)Anfitrión KVM 3600.89MV KVM 4477.36Anfitrión NoXen 4406.59Anfitrión Xen3 4901.35MV Xen3 5341.71Anfitrión Xen4 4486.63MV Xen4 4859.74Tabla 5: Resultados de la simulación de nanodispositivos.Gráfica 3: Tiempo (s) para completar prueba deNanodispositivos MOSFET en los sistemas evaluados.Los rendimientos relativos entre MV, anfitriones ymáquina con kernel sin modificar se encuentran en laTabla 6:PORCENTAJE DE TIEMPOMÁQUINA VIRTUAL ADICIONAL REQUERIDORESPECTO AL ANFITRIÓN (%)MV KVM 24.34%MV Xen3 8.98%MV Xen4 8.31%SISTEMAANFITRIÓNRELACION DE TIEMPONECESITADO PARA LAPRUEBA RESPECTO ALANFITRIÓN SIN KERNELMODIFICADO (%)Anfitrión Xen3 111.23%Anfitrión Xen4 101.82%Tabla 6: Resultados relativos entre los sistemas evaluados.Los resultados de la Tabla 6 muestran que en el casode la máquina virtual sobre KVM requirió un 24.34%más de tiempo para completar la simulación que elsistema anfitrión, a diferencia de la MV sobre elhipervisor Xen3 que requirió 8.98% más tiempo que suanfitrión, mientras que Xen4 sólo requirió un 8.31% másde tiempo que su anfitrión. En el caso del anfitrión Xen3requirió 11.23% más tiempo y en Xen4 los tiemposfueron casi iguales, solo requiriendo un 1.82% más detiempo para completar la prueba.En la Gráfica 4 se representa la pérdida de rendimientorelativa entre la MV y el anfitrión para los hipervisoresJP2011-546

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011evaluados, y para cada uno de los benchmarksempleados. En el caso de las pruebas de escritura y reescritura,la MV en KVM presentó rendimiento relativosuperior con respecto a la MV de Xen3 45.53% para leprueba de escritura y de un 45.42% para la prueba de reescrituray en relación a la MV en Xen4 de un 38.89%para la prueba de escritura, y de un 28.58% para la reescritura.Para las pruebas de Linpack y el simulador denanodispositivos la MV de Xen4 tiene mejorrendimiento que la MV de KVM, apreciándose para eltest de Linpack una diferencia de un 34.65% y en el testdel simulador de nanodispositivos una diferencia de un11.88%. Al comparar los resultados entre la MV enXen4 y la MV en Xen3; se observa que la nueva versióndel hipervisor ha mejorado en varios aspectos; demanera que en la prueba de IOZone en tasa de escrituraobtuvo un resultado 6.64% mejor y en la tasa de reescrituraha obtenido un 17.28% mejor. En el caso de laprueba de Linpack, la MV en Xen4 apenas mostrópérdida con el anfitrión, mientras que la MV con Xen3perdió un 19.91%.diferencia con la MV con Xen3), ya que requirióúnicamente un 8% más tiempo que el anfitrión paracompletar la simulación; siendo mucho más eficienteque la MV en KVM.En general, podemos concluir que las MV que seejecutan con el hipervisor Xen mostraron un mayorrendimiento en las tareas evaluadas que estabanrelacionadas con el cálculo y procesamiento intensivo.En cambio, la situación es distinta en cuanto a la tasa detransferencia de escritura en disco, en la cual la MVsobre KVM mostró un mejor rendimiento que la MV deXen.Finalmente, según los resultados obtenidos, se observauna diferencia considerable en el rendimiento de lasmáquinas virtuales dependiendo de si la aplicación haceun mayor uso del disco o del procesador. Por lo tanto,sería conveniente, como trabajo futuro, analizar lascausas de estas diferencias, y en caso de que no fueraninevitables se podría seleccionar previamente elhipervisor con el que desplegar la máquina virtual enfunción del tipo de aplicación que se desee ejecutar.Probablemente esta situación sea causada por lapresencia de los controladores VirtIO que mejoran estafuncionalidad.AGRADECIMIENTOSEl presente trabajo ha sido financiado por la Xunta deGalicia mediante los proyectos 09TIC001CT eINCITE08PXIB206094PR, y por el Gobierno de España(MCYT) y fondos FEDER mediante el proyectoTEC2010-17320.Gráfica 4: Resultados de la pérdida de rendimiento entrela MV y el anfitrión para Xen y KVM.V. CONCLUSIONESEste trabajo se ha centrado en comparar el rendimientode los hipervisores Xen y KVM. Para ello, se hanejecutado tres test correspondientes a los benchmarksIOZone y Linpack, y de la aplicación de cálculocientífico de simulación Monte Carlo denanodispositivos MOSFET. Éstos se han ejecutado enlos anfitriones y máquinas virtuales gestionadas por loshipervisores de código abierto Xen y KVM,compatibles con el diseño del proyecto Formiga Cloud.En el test Linpack, la MV que se ejecutó con elhipervisor Xen4 presentó el mayor rendimiento; ya quela diferencia con el anfitrión fue menor del 1%.En el test de IOZone se evaluó la tasa de transferenciaen modo Escritura en la cual la MV bajo KVM presentóla menor pérdida respecto al anfitrión, siendo ésta de tansólo un 3.76%. En cambio, los resultados obtenidos conla MV en Xen3 y Xen4, en la misma prueba, mostrabanuna pérdida mucho más pronunciada. Cuando se evaluóla tasa de transferencia en modo Re-Escritura, la MV enKVM sólo perdió un 6.96% frente al anfitrión, siendomucho más eficiente que la MV en Xen3 y Xen4.En el test de cálculo científico, presentó un mayorrendimiento la MV en Xen4 (aunque con muy pocaREFERENCIAS1. Zhang, Liang-Jie, et al. Hot Topics in CloudComputing. IT Professional, Septiembre 2010, Vol. 12,pp. 17-19.2. Gomez-Folgar, F., et al., An e-Scienceinfraestructure for nanoelectronic simulations based ongrid and cloud technologies., Electron Devices (CDE),2011 Spanish Conference, pp. 1-4, 8-11.3. INTEL Corp. . INTEL Math Kernel Library.http://software.intel.com/en-us/articles/intel-mathkernel-library-linpackdownload/?wapkw=(intel+linpack).4. Benchmark, IOZone File System. IOZone.org.http://www.iozone.org.5. Xen.org. Xen Hypervisor Web Site.http://www.xen.org/files/Xen_4_1_Datasheet.pdf.6. Xen Hypervisor 4.1 Release.http://blog.xen.org/index.php/2011/03/25/xen-4-1-releases/.7. Habib, Irfan. Linux Journal. Virtualization withKVM. http://www.linuxjournal.com/article/9764.8. M. Tim Jones, EMULEX Corp. IBM -DeveloperWorks. Discover The Linux KErnel VirtualMachine.http://www.ibm.com/developerworks/linux/library/llinux-kvm/.9. Lilja, David J. Measuring Computer Performance.s.l. : Cambridge University Press, 2004.JP2011-547

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201110. Knuth, D.E. The Art of Computer Programming,Vol. 2. s.l. : Addison-Wesley, 1997.11. M. Tim Jones, EMULEX Corp. IBM -DeveloperWorks. VirtIO: Marco de Virtualización deE/S para Linux.http://www.ibm.com/developerworks/ssa/linux/library/lvirtio/index.html.JP2011-548

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Arquitecturas del subsistema de memoria yalmacenamiento secundarioJP2011-549

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-550

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111A Novel Approach for a Metadata ClusterAna Avilés–González, Juan Piernas and Pilar González–Férez 1Resumen— This paper presents the design and implementationof a metadata cluster based on a newenhanced type of OSD device, the OSD+ device, whichsupports both data objects and directory objects. Unlikethe “data” objects of a traditional OSD device, adirectory object stores file names and attributes, andsupports metadata–related operations. Thanks to theOSD+ devices, metadata of a parallel file system canbe managed by all the devices of the system, improvingthe performance and scalability of the metadataoperations. Our metadata cluster’s performance hasbeen evaluated and compared with that achieved byLustre. The results show that: our proposal obtains abetter throughput than Lustre when both use a singlemetadata server, getting improvements of more than60–80%, and it scales with the number of OSD+s.I. IntroductionThe avoidance of bottlenecks is critical in moderndistributed storage systems to achieve the desiredfeatures of high performance and scalability. Thesesystems deal not only with a large volume of data butalso with an increasing number of file. Accordingly,an efficient metadata management becomes a fundamentalaspect of a system storage’s architecture toprevent such bottlenecks [1].Although metadata is usually less than 10% ofthe overall storage capacity of a system, its operationsrepresent between 50% and 80% of all the requests[2]. Metadata operations are also very CPUconsuming: a single metadata server can easily beoverloaded by a few clients. Hence, to improve theperformance and scalability of metadata operations,a cluster of servers is needed. PVFS [3] and Ceph [4],e.g., use a small set of servers as a metadata cluster.In this paper, we propose the use of OSD devices[5] as metadata servers by extending the typeof objects and operations an OSD supports. Specifically,the new devices, that we call OSD+, supportdirectory objects. Unlike objects found in a traditionalOSD (referred here as data objects), they storefile names and attributes and support metadata–related operations. OSD+s allow us to design a newparallel file system called FPFS (Fusion Parallel FileSystem) which combines data and metadata serversinto a single type of server capable of processing allI/O operations. By using all the available storagedevices as both data and metadata servers we gainseveral advantages: hardware resources are betterused; administration costs are reduced; and metadataperformance and scalability are improved.Because nowadays there are no commodity OSDbaseddisks available, their implementation is doneby means of mainstream computers which export anOSD-based interface, and use a regular local file systemto store objects. We take advantage of this fact1 University of Murcia (Spain), email: ana.aviles,piernas, pilar@ditec.um.esby directly mapping directory–object operations inFPFS to directory operations in the local file system,exporting many of its features, and reducingthe possible overhead of the OSD+ implementation.Our OSD+s can be seen as members of two separateclusters: a data and a metadata cluster. Sincemodern file systems already have a good data performanceand failure recovery, FPFS’s data clusterworks as and borrows ideas from them. For the metadatacluster, however, our goal is to provide a servicebetter than that produced by existing file systems.Therefore, this work specially focuses on the designand implementation of such a service in FPFS.In order to leverage the new features providedby the OSD+ devices, the FPFS metadata clusterspreads directories (and its corresponding objects)across the OSD+s. This is done by hashing directorypathnames. Clients use the same hashing to directlycontact the OSD+ which hosts the directory objectserving a given metadata request. Due to the hashingtechnique, renames and permission changes mayaffect the location and accessibility of a large numberof directories. In this case, a lazy approach [6] isused for dealing with these operations.Given that some metadata operations affect morethan one directory and, hence, more than one OSD+,two key aspects of the metadata cluster design arethe atomicity of the operations, and the coordinationof the OSD+s. Indeed, this coordination allows theOSD+ devices to provide a global metadata service.We have evaluated our metadata cluster and comparedits performance with Lustre [7]. The experimentalresults show that a single OSD+ can easilyimprove the throughput of a Lustre metadata serverby more than 60–80%. They also prove that our implementationscales with the number of OSD+s.II. Related WorkAn important issue regarding the metadata managementis where to store the metadata. Ceph [4]uses objects located in the OSDs themselves, althoughthe management is handled by a small setof servers which contact the OSDs to read and writemetadata. Ali et al. [8] explore the use of OSD devicesto store and partially manage directories. Theysave directory entries as attributes of empty objects,and introduce a new OSD operation to make attributechanges atomic. But, they do not discussother important issues: the directory distribution,the handling of renames and permission changes, andthe atomicity of operations involving several OSDs.FPFS addresses these topics through the directoryobjects, making OSDs capable of storing and managinga complete directory hierarchy.The distribution of the file system namespaceJP2011-551

2Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011across metadata servers is crucial to make a balanceduse of resources and to achieve a good performance.It also determines scalability problems related to certainmetadata operations or changes in the clusterdue to additions, removals or failures of servers.Static Subtree Partition, used by Coda [9],AFS [10], etc., statically assigns portions of the filehierarchy to metadata servers. This preserves directorylocality, but is vulnerable to distribution imbalancesas the file system and workload change. A variantis Dynamic Subtree Partition, used by Ceph [4],which delegates authority for subtrees of the directoryhierarchy to different metadata servers. Periodically,busy servers transfer subtrees to other non–busy servers.Hashing approaches can be used [11], [6], [12] toimprove metadata distribution, but present severaldrawbacks like the loss of directory locality and massivedata migration due to a cluster size change ora rename. Lazy Hybrid (LH) [6] mitigates the migrationwith a metadata look–up table (MLT) whichmaps hash value ranges to servers ids. Further, it applieslazy policies to defer a migration until the datais next accessed. It also includes a dual–entry accesscontrol list (ACL) to avoid directory traversals whenchecking access permissions.Features introduced by LH have been widelyborrowed by schemes such as Dynamic Hashing(DH) [12] or MHS [11]. DH combines lazy policiesand an MLT with several new strategies to dynamicallyadjust the metadata distribution. MHS is adirectory hashing scheme that uses LH’s access controlmechanisms; it avoids data migrations due torename operations by assigning to every directory aunique id which never changes (a global index tableis used for this purpose).III. The Metadata Cluster: DesignThe metadata cluster uses the OSD+ devices toprovide a high performance and scalable metadataservice. It also takes advantage of them to providereplication and fault tolerance, and to tackle withsome metadata issues like directory renames, linksand permission changes, in a consistent and atomicmanner.A. Metadata DistributionOur proposal distributes the directory objects (thefile–system namespace) across the metadata clusterto make metadata operations scalable with thenumber of OSD+s. The distribution is based onCRUSH [4], a deterministic pseudo–random functionthat guarantees a probabilistically balanced distributionof objects through the system. For a directory,CRUSH outputs its placement group (PG), a list ofdevices made up of a primary node and a set of replicas.These devices are chosen according to weightsand placement rules that restrict the replica selectionacross failure domains. So, potential sources offailures and load imbalance are avoided with no needof extra structures. As input, CRUSH receives an integerwhich results from hashing the full pathnameof the directory.Hash partition strategies present different scalabilityproblems during cluster resizing, renames andpermission changes. In case of adding and removingnodes in the cluster, our design avoids the metadatamigration or imbalance through CRUSH. Likewise,for minimizing renames management, permissionchanges, and links, FPFS employs lazy techniques[6]. Nevertheless, it is important to note that,in our case, renames and permission changes onlyaffect directories. As the experimental results willshow, these operations are infrequent in directories.This fact, along with the use of lazy techniques andCRUSH, will further minimize the impact of theseoperations on the metadata cluster performance.Although directory objects are scattered across thecluster, the directory hierarchy of the parallel filesystem is also maintained to provide standard directorysemantics (e.g., when listing directory entries),and to determine file and directory access permissions(they are determined from the root directory).B. Directory RenamesWhenever a directory name changes, so does itslocation as well as the location of the underlying directoriesin the hierarchy. This can incur in a massivemigration of metadata. To minimize the migrationimpact, lazy policies, similar to those used by LH [6],are applied. Unlike LH, file renames do not involvemetadata migration, because their locations do notdepend on their pathnames.Rename requests are sent to the parent directoriesof the corresponding target directories. When therename of a directory occurs, the OSD+ of its parentdirectory broadcasts the rename to inform theother OSD+s in the cluster. Accordingly, when anOSD+ receives an operation on a directory whosepathname has changed, but whose object has notbeen migrated yet, instead of returning an error, theOSD+ starts the migration of the object to carry outthe operation.Figure 1 shows this migration process. First, afterobtaining the list of servers containing the directoryobject (steps 1 and 2), the client contacts one targetOSD+ (step 3). Then, the failed request forces theOSD+ to migrate the object by looking in the log,and contacting the source OSD+ (step 4). Once themigration is done (step 5), the initial operation is carriedout and the result is returned to the client (step6). Due to a previous rename, the source OSD+ maynot contain the directory object either. The processis then repeated recursively, moving backwards untilthe directory object is found and migrated.C. Permission ChangesTo directly determine access permissions and avoiddirectory traversals, dual–entry ACL are used [6].Given a directory, one ACL contains its permissions,whereas the other represents its path permissions(these are the intersection of the directory’s own per-JP2011-552

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20113HashCRUSHFig. 1.Directory object migration.Fig. 2. Access to a directory containing a symbolic link./usr/new is a soft link to /usr/old.missions and its parent’s path permissions). UnlikeLH, only directories have dual–entry ACLs in FPFS.A file’s permissions are derived from its ACL, andits directory’s dual–entry ACL.When checking permissions, the OSD+ containingthe target directory object searches in the metadatalog for invalidations along the requested objectpath. If they exist, the parent directory is accessedto get its dual–entry ACL. Once permissions are updated,the requested ACL is calculated. Since parent’spermissions might also be invalid, this processis repeated recursively until the changed directory isreached, or an updated directory is reached. Permissionsare updated in a lazy fashion, minimizing thepart of the hierarchy traversed.D. LinksPlacing directories by hashing their pathnamespresents the problem of locating the correct OSD+sfor paths that include symbolic links. Any access toa subtree of the linked directory hierarchy will fail, asit happens with a renamed directory whose objectshave not been migrated.LH [6] proposes the creation of shortcuts to dealwith files whose pathnames contains symbolic links.A shortcut to one of these files is created the firsttime the file is accessed by traversing the directoryhierarchy. Any subsequent access to the same filewill use the shortcut. But this approach presentstwo problems: shortcuts take up space and, moreimportantly, when the access to a file fails, there isno way to know if the failure is due to a missingfile or the existence of symbolic links in the name.This ambiguity always produces the traversal of thedirectory hierarchy up to the root directory whenaccessing to any missing file.Our proposal for symbolic links does not suffer themissing file problem of LH. In FPFS, a symbolic linkis treated as a directory rename. The differences arethat: any access to a directory containing a symboliclink never produces the migration of the directory,and a client accessing one of these directories receivesthe resolved path to contact with the original OSD+(see Fig. 2).E. AtomicityAn important aspect is that all the metadata operationsmust be atomic to provide a coherent view.When a metadata operation is performed by a singleOSD+ (e.g., create, unlink, etc.), the backend filesystem itself guarantees its atomicity, POSIX semantics,and atomicity when clients access in parallel.However, there are operations, such as rename,mkdir or rmdir, which usually involve two OSD+s.Now, atomicity is guaranteed by means of the backendfile system, and a three–phase commit protocol(3PC) [13] where one node acts as the coordinatordirecting the remaining nodes or participants.IV. The Metadata Cluster: ImplementationA prototype of the metadata cluster has been builton a Linux environment. Each OSD+ is a user–space multithreaded process, running on a mainstreamcomputer, which uses a conventional file systemas storage backend. The Linux syscall interfaceis used to access the backend file system, whichmust be POSIX–compliant and support extended attributes.Our FPFS implementation not only exploitsthe underlying file system’s features (atomicity,errors checking, etc.), but also exports them tothe parallel file system.For every new established connection from anFPFS client or another OSD+, one thread islaunched. It lasts as long as the communicationchannel remains open; hence, performance is improveddue to the absence of connection establishmentand termination handshakes, associated witheach message. In the current implementation, connectionsuse TCP/IP and UDP/IP protocols.A. Directory ObjectsInternally, a directory object is implemented as aregular directory whose path is its directory pathnamein the parallel file system. Thus, the directoryhierarchy is imported within each OSD+ by replicatinga partial namespace of the global hierarchy.To preserve the hierarchy, directory objects maintainan entry for every file and subdirectory theycontain. Hence, several types of directories are differentiatedthrough extended attributes: a first type toimplement directory objects; a second one to maintainthe hierarchy (e.g., the subdirectories); a thirdto internally construct the paths of the directoriesobjects; and finally, temporal directories to keep renamedmetadata which has not been migrated yet.JP2011-553

4Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Figure 3 shows how an FPFS’ directory hierarchyis mapped to a four–OSD+s cluster. Directory objects(marked with o) are stored along with theirfiles and subdirectories (identified by h). Note thata directory object and the corresponding parent’s directoryobject are usually placed in different OSD+s,except for /home/usr1, where both objects meet, bychance, in the same OSD+. Fig. 3. Implementation of the parallel file system hierarchyin the OSD+ devices.B. Client–OSD+ InteractionCommunication between clients and OSD+s is establishedvia TCP/IP connections and request/replymessages. As requests, FPFS supports the most frequentlyused metadata operations (see Sec. V-A):mkdir, rmdir, opendir, readdir, create, unlink,open, close, lookup, stat, utime and rename.A client request is usually sent to the OSD+ storingthe parent’s directory object. For instance, if aclient opens /home/usr2/docs/info.pdf, it sends amessage to the OSD+ containing the directory objectof /home/usr2/docs.When an operation involves several OSD+s, theone contacted by the client carries out the operationcollaborating with other OSD+s. For example,when creating /home/usr2 (see Fig. 3), OSD+ 1,which contains /homeo, initially creates the directory/home/usr2 h . If the creation is successful, OSD+ 2concludes the request creating the directory object/home/usr2o.C. Files and Data ObjectsA file’s metadata is initially stored as an emptyfile in its parent directory. This improves operationslike stat, since the directory entry and its metadataare in the same OSD+. Clients are able to see allthe usual attributes (timestamps, mode, etc.) andextended attributes stored in the empty file.To make a fair comparison with Lustre (seeSec. V), FPFS also creates data objects for files.They are implemented as regular files in the OSD+s.Each data object has an id which is stored as an extendedattribute in the file’s metadata, and is composedof 2 values: object name, and OSD+ where itis stored.D. LogsLazy techniques implementation requires eachOSD+ to store a metadata log with permissionchanges and directory renames. All the incomingrequests are first checked against this log to providea coherent and consistent reply to clients accessingmetadata that may not have been updated. Asidefrom the metadata log, the three–phase commit protocolemploys another log to rollback in case of failure.Both logs are sync’ed to disk every 5 seconds.V. Experimental ResultsThe performance of the proposed FPFS’s metadatacluster has been evaluated and compared withLustre by using different benchmarks. This sectionsdescribes those benchmarks, the system under testand the achieved experimental results.A. System under Test and BenchmarksThe testbed system is a cluster made up of 16 computeand 1 frontend nodes. Each compute node hastwo Intel Xeon E5420 Quad-core CPUs at 2.50GHz,4GB of RAM, and two Seagate ST3250310NS disksof 250GB. One of the disk has a 64-bit Fedora Core11 distribution which supports version 1.8.2 of Lustre.The other one is exported as either an FPFSOSD+ or a Lustre MDS–MGS/OST server. The interconnectis a Gigabit network with a D-Link DGS-1248T switch.Experiments use up to 8 compute nodes. ForFPFS, two configurations are set up: one with 1OSD+, and another with 4 OSD+s. Both use Ext4as the backend file system. For Lustre, only one configurationis set up with 1 node running all its services(MGS/MDS, and one OST), equivalent to ourconfiguration with one OSD+. As clients, 1 to 4nodes are used depending on the test.Since the metadata performance depends on theformatting options, FPFS has been formatted withthe same options Lustre uses in its underling file system.In order to evaluate and compare the performanceof FPFS and Lustre in metadata workloads, threebenchmarks have been carried out:• HP Trace: it is a 21-hour trace which is, inturn, a subset of a 10-day trace of all file systemaccesses done by a medium-sized workgroup usinga 4-way HP-UX time-sharing server attachedto several disk arrays and a total of 500 GB ofstorage space [14]. The selected period coversfrom 6am on the fifth trace day to 3am on thenext day, one of the most active.Table I provides an overview of the metadatarequests in the trace. Since we are only interestedin metadata operations, data operationsare omitted.The trace is replayed by a multithreaded programwhich allows us to simulate a system withconcurrent metadata operations. The programtakes into account possible dependencies betweenmetadata operations.• Creation/traversal of a directory tree: thisbenchmark is made up of two tests: one thatcreates directory hierarchies with empty regularfiles, and another one which traverses those hierarchies.Every directory hierarchy is created byuncompressing the source tree of a Linux kernelJP2011-554

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20115TABLA IOverview of the 21-hour HP trace.Operation type Count Operation type CountLookup 13908189 File rename 7683Stat 2827387 Mkdir 7389Open 2572124 Rmdir 6973Unlink 67883 Directory rename 5Create 417552.6.32.9, whose files have been truncated to zerobytes. In these tests, each process accesses itsown copy of the Linux source tree.• Metarates: program [15] for evaluating therate at which metadata transactions are performed.It measures aggregate transaction rateswhen multiple processes (coordinated by MPI)read or write metadata concurrently. Our experimentsuses 640000 files in total, distributedinto as many directories as processes. The programtests the performance achieved by eachsystem for three types of metadata transactions:create–close, (in our tests, without calling fsyncbefore closing a file), stat, and utime calls.The results shown for every system configurationare the average of five runs of each benchmark. Confidenceintervals are also shown as error bars, for a95% confidence level. The disk is formatted betweenruns, and unmounted/remounted between the directorytree creation and traversal tests. The number ofclient processes per benchmark varies from 1 to 256processes, in powers of two.For any benchmark, the scalability is calculatedfrom 1 and 4 OSD+s results. Also, FPFS and Lustre’sperformances are compared using one node aseither an OSD+ or a Lustre server containing bothan MDS/MGS and OST service.B. HP TraceAlthough Lustre is a full-fledged parallel file systemand FPFS only implements an incomplete metadataservice, both roughly perform the same operations.This fact, along with the large performancedifferences in this benchmark (see Fig. 4.(a)) whichreaches 82% for 16/32 threads, ensures that FPFSrepresents a significant improvement with respect toLustre in time-sharing environments.These differences are mainly due to the thin layerFPFS adds on top of the backend file system, whichdirectly translates FPFS requests into backend filesystem ones, producing little overhead. Instead, Lustreadds several abstraction layers. Moreover, we useExt4 while Lustre uses a customized Ext3 (ldiskfs).FPFS’s scalability (see in Fig. 4.(b)), reaches 2.43for 32 threads. This value is smaller than the ideal4, due to the dependencies between metadata operationsin the trace, which limit the parallel executionof operations. However, as the number of threadsincreases, the number of possible ongoing metadataoperations also grows. Accordingly, scalability is betterfor a large number of threads, showing that FPFScan properly deal with large time-sharing systems.C. Creation/Traversal of a Directory TreeFigure 4.(c) shows FPFS’s improvement over Lustreis around 70% for both tests, but the improvementof directory traversal plummets from 64 processeson. This is due to a default Ext4’s optionwhich is unset in ldiskfs by default. The flag flex bgbenefits the directory traversal for high number ofprocesses, but makes the directory creation worse.So, to get an optimum performance, depending onthe workload, the formatting options can be changed,as well as the backend file system. Thanks to thisflexibility, FPFS can be adjust to get the best performance,while Lustre is not so adaptable.The scalability achieved in the directory tree creation(see Fig. 4.(d)) is not as high as in HP tracesfor small amount of clients due to a network trafficincrease when there are four OSD+s. This incrementis produced by the mkdir and create operations inFPFS, since they involve two OSD+s and so messageexchanges between them (see Sec. III-E). Yet,despite of the additional messages, FPFS reaches abetter scalability as the number of clients grows.D. MetaratesPerformance results of metarates transactions areshown in Fig. 4.(e). FPFS’ gain is larger for a fewprocesses, and decreases with the number of processesfor the create test. One of the reason is thatFPFS manages large directories better than Lustre.Although the number of files is fixed, there are asmany directories as processes are run, so the lesserthe number of processes, the higher the number offiles per directory.FPFS also greatly reduce the application time forthe stat and utime transactions, but the results donot depend on the number of processes. These transactionsfirst create the files, and then perform thecorresponding operations. Accordingly, thousands ofinodes and directory entries are already in the operatingsystem’s caches and, hence, the performance islimited by CPUs and network bandwidth, and notby hard disks or directory sizes. Lustre, however,makes a less efficient use of the system caches andits abstraction layers introduce a larger overhead.In this test, FPFS achieves a super-lineal scalability(see Fig. 4.(f)), mainly due to the use of the operatingsystem’s write–back caches, and the number ofprocesses itself: when having more processes, the increaseof OSD+s reduces the application time and, inJP2011-555

6Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Improvement over Lustre (%)100806040200HP Trace1 2 4 8 16 32 64 128 256# of threads (clients)Improvement over Lustre (%)100500-50-100Creation/Traversal of a directory treeCreationTraversalCreation (-O ^flex_bg)Traversal (-O ^flex_bg)1 2 4 8 16 32 64 128 256# of processes (clients)Improvement over Lustre (%)100806040200CreationStatUtime(a) (c) (e)Metarates1 2 4 8 16 32 64 128 256# of processes (clients)Speedup43.532.521.510.50HP Trace1 2 4 8 16 32 64 128 256# of threads (clients)Speedup76543210Creation/Trasversal of a directory treeCreationTrasversal1 2 4 8 16 32 64 128 256# of processes (clients)Speedup121086420File creationStatUtime(b) (d) (f)Metarates1 2 4 8 16 32 64 128 256# of processes (clients)Fig. 4. Improvement obtained by FPFS 1 OSD+ over Lustre 1MDT/OST: (a) HP Trace; (c) Creation and raversalof a Directory Tree; (e) create-close, stat and utime transactions. FPFS Scalability for 1 OSD+ and 4 OSD+s: (c)Improvement obtained by FPFS over Lustre; (d) FPFS Scalability.turn, the number of write operations to disk duringthe tests. Further, the pending metadata writes incache do not affect the application time, which benefitscreate and utime transactions. Also, the largertotal cache size provided by four OSD+s decreasesthe number of metadata reads from disk, which alsoimproves stat and utime transactions.VI. Conclusions and Future WorkWe have introduced OSD+, a new type of OSD devicewhich supports both data and directory objects.While data objects store data of any type and supportread and write operations, directory objectsimplement directories and support metadata–relatedoperations (create, unlink, mkdir, etc). By usingOSD+s, data and metadata of a parallel file systemcan be managed by all the OSD+s in a cluster, improvingits performance and scalability.The paper also presents the implementation ofa metadata cluster based on OSD+s, and discusssome design and implementation issues like directorydistribution, rename operations, file permissionchanges, and atomicity. Our implementation’s performancehas been compared with Lustre’s. The resultsshow that our proposal easily outperforms aLustre metadata server by more than 60–80%, andthat it scales with the number of OSD+s.AcknowledgmentWork supported by the Spanish MEC andMICINN, as well as European Comission FEDERfunds, under Grants CSD2006–00046 and TIN2009–14475–C04.Referencias[1] Swapnil Patil and Garth Gibson, “Scale and concurrencyof giga+: File system directories with millions of files,”in In Proc. of the 9th USENIX Conference on File andStorage Technology (FAST’11), Feb. 2011, pp. 15–30.[2] D. Roselli, J. Lorch, and T. Anderson., “A comparisonof file system workloads,” in Proc. of the 2000 USENIXAnnual Tech. Conf., June 2000, pp. 41–54.[3] R. Latham, N. Miller, R. Ross, and P. Carns., “A nextgenerationparallel file system for linux clusters,” Linux-World, pp. 56–59, Jan. 2004.[4] S. Weil., Ceph: reliable, scalable, and high-performancedistributed storage, Ph.D. thesis, University of California,Santa Cruz, (CA), Dec. 2007.[5] M. Mesnier, G. R Ganger, and E. Riedel, “Object-basedstorage,” IEEE Commun. Magazine, pp. 84–90, Ago.2003.[6] S. A. Brandt, E. L. Miller, D. D. E. Long, and L. Xue.,“Efficient metadata management in large distributedstorage systems,” in Proc. of the 20 th IEEE/11 th NASAGoddard Conf. on Mass Storage Systems and Technologies,2003.[7] P. J. Braams, “High-performance storage architectureand scalable cluster file system,” 2008.[8] N. Ali, A. Devulapalli, D. Dalessandro, P. Wyckoff, andP. Sadayappan., “An OSD-based approach to managingdirectory operations in parallel file systems,” in IEEEInternational Conf. on Cluster Computing, 2008.[9] M. Satyanarayanan, J. J. Kistler, P. Kumar, M. E.Okasaki, and E. H. Siegel., “Coda: A highly available filesystem for a distributed workstation enviroment,” IEEETrans. on Computers, vol. 39, no. 4, pp. 447–459, 1990.[10] J. H. Morris, M. Satyanarayanan, M. H. Conner, J. H.Howard, D. S. Rosenthal, and F. D. Smith., “Andrew: Adistributed personal computing enviroment,” Commun.ACM, vol. 29, pp. 184–201, March 1986.[11] J. Wang, D. Feng, F. Wang, , and Chengtao Lu., “MHS:A distributed metadata management strategy,” in TheJournal of Systems and Software, July 2009.[12] L. Weijia, X. Wei, J. Shu, and Weimin Zheng., “Dynamichashing: Adaptive metadata management for petabytescalefile systems,” in Proc. of the 14th IEEE / 23rdNASA Goddard Conf. on Mass Storage Systems andTechnologies, May 2006.[13] D. Skeen and M. Stonebraker, “A formal model of crashrecovery in a distributed system,” IEEE Trans. on SoftwareEngineering, vol. 9, pp. 219–228, May 1983.[14] L.P. Hewlett-Packard Development Company, “Fstrace,”2002.[15] University Corporation for Atmospheric Research,“metarates,” 2004.JP2011-556

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmo de reemplazo para cache de últimonivel basado en periodos MRUAlejandro Valero, Julio Sahuquillo, Salvador Petit, Pedro López y José Duato 1Resumen— El diseño de la jerarquía de memoria esun aspecto importante en los microprocesadores actuales.Muchos trabajos de investigación se centranen el último nivel de cache, el cual se diseña para ocultarla elevada latencia de acceso a la memoria principal.Para reducir los fallos de capacidad y de conflicto,estas caches forman estructuras de memoria grandescon un gran número de vías.Para explotar la localidad temporal, el algoritmo dereemplazo típicamente implementado en caches es elLRU. Sin embargo, para caches con un gran númerode vías, su implementación es costosa en términos deárea y consumo de potencia. De hecho, el uso de LRUno es conveniente en caches de último nivel porqueno pueden lidiar con la localidad temporal. Esto sedebe a que las caches de último nivel no ven todoslos accesos a memoria. Además, los bloques debendescender hasta la última posición de la pila LRU paraser reemplazados.En este trabajo se muestra que la mayoría de losbloques no se vuelven a referenciar una vez han dejadola posición MRU. Más aún, la probabilidad de volvera ser referenciados no depende siempre de la posiciónque ocupan en la pila. Basándose en estas observaciones,se define el número de periodos MRU (pMRU)de un bloque como el número de veces que un bloqueocupa la posición MRU mientras permanece en lacache, y se propone el algoritmo de reemplazo pMRU,que selecciona la víctima entre aquellos bloques quetienen un solo pMRU. También se proponen variacionesde este algoritmo para explotar la recencia deinformación.Los resultados experimentales muestran que, en lamedia, la mejor versión de algoritmo pMRU obtieneuna reducción de MPKI de un 19% comparado conLRU. Además, la versión más sencilla tan sólo necesita2 bits de estado por bloque independientementede la asociatividad de cache. Por consiguiente, la complejidadhardware y el coste de actualizar estos bitsse reduce significativamente comparado con LRU.Palabras clave— Algoritmo de reemplazo en caches,caches de último nivel, periodo MRU.I. IntroducciónLOS arquitectos de computadores han implementadomemorias cache [1] desde finales de los años60 para mitigar la diferencia de velocidad existenteentre el procesador y la memoria principal. Este problemase solventó al principio mediante el uso deun solo nivel de cache, pero conforme la diferenciade velocidad ha sido mayor, se han requerido másniveles para no degradar las prestaciones. El primernivel (cache de L1) es el más cercano al procesadory se diseña para conseguir velocidad alta de accesoa memoria, mientras que el segundo o tercer nivel(si existe) se diseña para ocultar en la medida delo posible la latencia elevada debido al acceso a lamemoria principal, que conlleva cientos de ciclos deprocesador en los microprocesadores actuales.1 Grupo de Arquitecturas Paralelas, Universitat Politècnicade València, e-mails: alvabre@gap.upv.es, {jsahuqui,spetit, plopez, jduato}@disca.upv.es.Las prestaciones del sistema dependen en gran medidade las prestaciones de la jerarquía de memoria.Es por ello que muchos trabajos de investigación sehan centrado en mejorar las prestaciones de la cache,aunque normalmente lo han hecho en un solo nivelde cache (L1, L2 o L3). Algunos ejemplos son lastécnicas de load-bypassing, way-prediction o prefetching,que han sido ampliamente investigadas e implementadasen muchos productos comerciales. Aunqueestas técnicas se han implementado en procesadoresmonolíticos, la presión del controlador de memoriaes mayor en sistemas multinúcleo. Por tanto, lasprestaciones relativas a la jerarquía de memoria engeneral, y de la cache de último nivel en particular,son un aspecto importante en los microprocesadoresactuales.Las caches de último nivel forman una estructurade memoria grande entre cientos de KB y decenas deMB [2], para así reducir los fallos de capacidad. Másaún, se prevé que esta capacidad aumente conformeel tamaño de los transistores continúe reduciéndoseen las futuras tecnologías. Además, las caches deúltimo nivel implementan un gran número de vías(p.e., 16 vías) para reducir los fallos de conflicto.En general, las caches explotan la localidad temporalmediante el algoritmo de reemplazo LRU (LeastRecently Used). Este algoritmo actúa como una pilaque contiene el bloque MRU (Most Recently Used)en la primera posición y el bloque LRU en la última,siendo este último bloque la víctima cuando se requiereespacio. Aunque este algoritmo resulta eficienteen caches de L1 con poca asociatividad, encaches de último nivel con asociatividad mayor como8 y 16 vías, la implementación del algoritmo LRUtradicional es demasiado compleja. Esto conduce aque se hayan propuesto aproximaciones a LRU, perolas prestaciones obtenidas se apartan de las del LRUtradicional [3]. Por otra parte, las prestaciones deLRU se encuentran lejos de las obtenidas por el algoritmode reemplazo óptimo conocido como algoritmode Belady [4], que reduce los fallos de cache a unmínimo teórico eligiendo como víctima el bloque quese referenciará más tarde en el futuro.Existen varias razones que explican por qué el algoritmoLRU no obtiene buenas prestaciones en cachesde último nivel con pilas grandes. En primer lugar,los accesos a memoria que resultan en acierto en lacache de L1 quedan ocultos a la cache de último nively se pierde la localidad temporal. En segundo lugar,LRU sufre el efecto conocido como cache thrashingen aquellas aplicaciones donde la cantidad de datoses mayor que la capacidad de cache disponible, resultandoen accesos de bloque cíclicos. Estos blo-JP2011-557

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ques recorren la pila sin ser utilizados de nuevo ycuando se requieren ya han sido reemplazados. Porúltimo, LRU fuerza que un bloque tenga que llegarhasta la última posición para ser la víctima de reemplazo.Esto puede afectar a las prestaciones debido aque, como los resultados experimentales mostrarán,muchos bloques almacenados en L2 no vuelven a serutilizados de nuevo. Por ejemplo, en una cache de16 vías, un bloque que deja la posición MRU y novuelve a ser referenciado, no será la víctima hastaque se hayan completado quince accesos a bloquesmapeados en el mismo conjunto. Esto significa queotros bloques más útiles pueden ser elegidos comovíctima y por tanto, degradar las prestaciones. Algunostrabajos de investigación actuales han atacadoeste problema prediciendo cuando un bloque puedeser candidato a reemplazo antes de que llegue a laposición LRU [5] [6]. Otros trabajos manejan losreemplazos mediante la gestión de una cola para losbloques [7]. En estos casos, la víctima proviene de laprimera o última posición de la cola.La mayoría de bloques no se referencian otra vezcuando dejan la posición MRU. Además, la probabilidadde un bloque de ser referenciado otra vez nodepende siempre del orden que ocupa en la pila LRU.Esto significa que, en general, el orden de acceso noes importante para las aplicaciones en caches con ungran número de vías porque la probabilidad no disminuyeconforme el bloque desciende por la pila. Sinembargo, la política LRU necesita un número de bitsde estado por bloque considerable para mantener elorden de la pila.En este trabajo se define el número de periodosMRU (pMRU) de un bloque como el número de vecesque un bloque accede a la posición MRU durante sutiempo de vida. Teniendo en cuenta que la mayoríade bloques exhiben un pMRU, este trabajo proponeel algoritmo pMRU con el objetivo de explotar estecomportamiento para mejorar las prestaciones. Losbloques que muestran un pMRU serán consideradosen el reemplazo, seleccionando uno de ellos al azar.De esta manera, la complejidad del algoritmo se reducerespecto a LRU y otras propuestas recientes.También se propondrán variantes de este algoritmoque exploten la recencia de información.El algoritmo pMRU propuesto mejora las prestacionesrespecto a LRU y otros algoritmos propuestosrecientemente. La mejor versión del algoritmo entérminos de prestaciones se refiere como pMRU-b3,y consigue reducir el MPKI en un 8% y 19% comparadocon el algoritmo reciente llamado DC-Bubbley LRU, respectivamente. Para finalizar, la propuestarequiere menos bits de estado que LRU, ya que los algoritmospMRU no necesitan mantener todo el ordende la pila. Por ejemplo, para una cache de 16-vías,la versión más sencilla del algoritmo pMRU tan sólonecesita 2 bits de estado por bloque, mientras queLRU requiere 4. Además, el número de bits de estadoque se deben actualizar en el peor caso de cadapolítica es 3, 4 y 30 para pMRU, DC-Bubble y LRU,respectivamente.El resto del artículo se organiza de la siguientemanera: la Sección II muestra algunos trabajos relacionados.La Sección III discute la motivación delpresente trabajo. La Sección IV presenta el algoritmobasado en periodos MRU. La Sección V analizalos resultados experimentales. La Sección VI discutela complejidad hardware de los algoritmos estudiadosy finalmente la Sección VII presenta las conclusionesmás relevantes.II. Trabajos relacionadosExisten gran cantidad de trabajos que han centradosus esfuerzos en las políticas de ubicación yreemplazo de los bloques para mejorar las prestacionesde la jerarquía de cache. Estos trabajos lospodemos dividir en tres categorías: uso de informaciónsobre el comportamiento de los bloques encaches de L1, mejora de las prestaciones de la políticaLRU en caches de L2 y propuestas que utilizan estructurashardware diferentes a una pila para manejarla estrategia de reemplazo.En el primer grupo se encuentra la propuesta NTSde Tyson et al. [8] y la propuesta MAT de Johnsonet al. [9]. La primera propuesta marca un bloquecomo cacheable basándose en el comportamiento delmismo en el pasado, mientras que la segunda clasificalos bloques como temporales o no temporales segúnel comportamiento de los mismos durante sus tiemposde vida. Rivers et al. [10] propone explotar elcomportamiento basándose en la dirección efectivade los datos referenciados así como en el contador deprograma de la instrucción de carga.Otros trabajos se centran en mejorar las prestacionesde la política LRU, principalmente en L2. Porejemplo, el pseudo-LRU trata de reducir la complejidadhardware del LRU tradicional. Otros trabajospredicen el bloque a reemplazar en lugar delLRU. En [5], la propuesta de Lin y Reinhardt predicecuando reemplazar un bloque antes de que llegue a laposición LRU. Esto se consigue utilizando un contadorque almacena el número de accesos al mismo conjuntodurante un intervalo de acceso a una línea decache. Si el contador llega a superar un valor umbral(aprendido del comportamiento previo de la línea), lalínea asociada es candidata a ser reemplazada. Otraspropuestas mejoran las prestaciones de LRU con unalgoritmo LRU modificado [11] [12] [13] o medianteuna pila pseudo-LIFO [6].El esquema Bubble, propuesto por Zhang yXue [7], es una propuesta interesante clasificada enla última categoría. Esta propuesta hace uso de unacola en lugar de una pila. Los bloques entrantes sealojan en el final de la cola, que es la localidad querepresenta la menor frecuencia de acceso. Los bloquespromocionan hacia la cabeza de la cola conformeson referenciados. La víctima se elige del finalo la cabeza de la cola según si el acceso previo alconjunto resultó en un fallo o acierto de cache, respectivamente.Este trabajo también presenta unatécnica de divide-y-vencerás, que divide los conjuntosen grupos de bloques independientes que aplicanJP2011-558

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IPorcentaje de bloques con un solo pMRU para cada aplicación de SPEC2000 en una cache de L2 de 1MB-16vías.ammp applu apsi art bzip2 crafty eon equake facerec fma3d galgel gap gcc100% 93% 35% 95% 35% 15% – 80% 85% – 15% 65% 75%gzip lucas mcf mesa mgrid parser perlbmk sixtrack swim twolf vortex vpr wupwise56% 61% 89% 65% 21% 40% – 29% 68% 34% 32% 59% 92%el algoritmo Bubble de manera independiente. Estapolítica se conoce como DC-Bubble. Cuando se requiereespacio, se elige un grupo al azar, reduciendode este modo la complejidad frente a LRU y el efectode cache thrashing.III. MotivaciónCuando se utiliza el algoritmo LRU, un bloqueque no se referencia desciende paso a paso por lapila hasta que se aloja en la posición LRU. Duranteeste descenso, la referencia a este bloque hace quevuelva a ocupar la posición MRU. Para caches con ungran número de vías, la probabilidad de retorno a laposición MRU no se distribuye de manera uniformeen las posiciones de la pila. La Figura 1 muestra losresultados para una cache de L2 de 1MB-16vías. Eltérmino pos2 hace referencia a la posición siguientea la MRU en la pila, pos3 a la posición siguientea pos2, etcétera. Debido a restricciones de espacio,pos5-7 hace referencia a las posiciones comprendidasentre la quinta y la séptima, etcétera. Nótese que laprobabilidad de referencia en la posición MRU no seha tenido en cuenta.Aunque en algunas aplicaciones, los bloques másreferenciados son aquellos cercanos a la posición LRU(pos16 ), la mayoría de cargas presentan una probabilidadalta de retorno en bloques cercanos a laposición MRU. En general, se puede concluir quemantener todo el orden de la pila LRU no es importanteen caches con un gran número de vías. Sinembargo, la política LRU requiere un número significantede bits (4 por bloque en una cache de 16-vías)para mantener todo el orden de la pila.IV. Algoritmo basado en periodos MRUEsta sección presenta en primer lugar el conceptode periodo MRU (pMRU) y después detalla en quéconsiste el algoritmo basado en pMRU.Los conceptos de tiempos de vida y muerte de unbloque [14] han sido muy utilizados en la investigación.El tiempo de generación define el tiempotranscurrido desde que un bloque entra en la cachehasta que se reemplaza. Este tiempo se puede dividiren los tiempos de vida y muerte de un bloque.El primero se refiere al tiempo desde que el bloqueentra en la cache hasta la última referencia al mismo.El segundo alude al tiempo desde la última referenciahasta que se reemplaza.La Figura 2 ilustra el concepto de pMRU en el contextodel tiempo de vida del bloque A. Asumiendola política LRU, A se aloja en la posición MRU entiempo t1. El bloque permanece en esta posiciónmientras es accedido. Después, deja esta posiciónporque el bloque B se referencia. En este momentose dice que A ha finalizado su primer pMRU. Pasadocierto tiempo, A es accedido otra vez, con lo quevuelve a la posición MRU e inicia su segundo pMRU.La marca t2 indica el final de este pMRU que coincidecon el último acceso a A. El tiempo de muerteempieza en este punto y acaba en la marca t3 cuandoel bloque A es expulsado.Con el objetivo de explorar el potencial del conceptopMRU sobre el algoritmo LRU, se ha obtenidoel porcentaje de bloques que presentan un solopMRU cuando son reemplazados. La Tabla I muestralos resultados para el conjunto de aplicaciones deSPEC2000 [15] y una cache de L2 de 1MB-16vías. Enlíneas generales, la mayoría de aplicaciones presentanun porcentaje elevado de bloques con un pMRU. Lasaplicaciones que no presentan valor son aquellas enlas que todos los fallos de L2 contabilizados son forzosos(ver Sección V).El algoritmo basado en pMRU hace uso de la informaciónde un pMRU o múltiples de cada bloque.Para ello, requiere un bit por bloque (pMRU-bit) queindica si el mismo ha experimentado un pMRU o varios.El algoritmo funciona como sigue. Cada vez queun bloque entra en la cache, el valor de su pMRU-bitasociado se actualiza a ’0’ para indicar que su primerpMRU ha empezado. El bloque es candidato a serreemplazado cuando deja la posición MRU por vezprimera. Después, si el bloque se referencia de nuevo,Fig. 1. Probabilidad de un bloque de ser referenciado en laposición X utilizando LRU.Fig. 2. Tiempo de generación del bloque A.JP2011-559

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIIPorcentaje de fallos forzosos para cada aplicación de SPEC2000 en una cache de L2 de 1MB-16vías.ammp applu apsi art bzip2 crafty eon equake facerec fma3d galgel gap gcc0% 24% 75% 0% 5% 28% 100% 100% 4% 100% 2% 100% 12%gzip lucas mcf mesa mgrid parser perlbmk sixtrack swim twolf vortex vpr wupwise100% 30% 2% 63% 22% 16% 100% 15% 25% 1% 50% 34% 80%TABLA IIParámetros de la máquina.Política issuePredictor de saltosNúcleo del microprocesadorPenalización predictorAncho fetch, issue y commitTamaño ROB (entradas) 256# Int. ALUs 4# FP ALUs 4Jerarquía de memoriaFuera de ordenHybrid gshare/bimodal:gshare: 14-bits de historiaglobal y 16K contadoresde 2-bitsbimodal: 4K contadoresde 2-bits y selector depredictor con 4Kcontadores de 2-bits10 ciclos4 instr/cicloPuertos memoria 4Cache datos/instr. L1 16KB-2vías, 64B-líneaLatencia L11 cicloCache unificada L21MB-16vías, 128B-líneaLatencia L26 ciclosLatencia memoria200 ciclosvuelve a ser el MRU y empieza otro pMRU. Esto seindica marcando su pMRU-bit a ’1’. De esta manerael bit indica que el bloque ha tenido varios pMRU.Este algoritmo tiene como objetivo seleccionarpara reemplazo aquellos bloques que han tenido unpMRU. Si un bloque exhibe buena localidad, acudirámás de una vez a la posición MRU y no será candidatoa reemplazo. Para que el hardware sea simple,la víctima se selecciona al azar entre aquellos bloquesque tienen un pMRU excepto el bloque MRU. Si nohay ningún candidato, la víctima se selecciona al azarentre todos los bloques del conjunto excepto el MRU.Por otro lado, como se ha visto en la Figura 1, almacenarel orden de los últimos bloques accedidospuede ser importante en términos de prestacionespara la mayoría de aplicaciones. Por ello se definela familia de algoritmos pMRU-bX, que extiende lapropuesta original para explotar el comportamientopMRU y la recencia de información. En este caso,se mantiene el orden de los últimos X bloques referenciadosy no son candidatos para reemplazo. Porejemplo, el algoritmo etiquetado como pMRU-b2 noconsidera como candidatos el bloque MRU y el inmediatamenteposterior. Nótese que pMRU-b1 se refiereal algoritmo original. La complejidad se reducerespecto a LRU porque estos algoritmos no necesitanguardar todo el orden de la pila.V. Evaluación experimentalEsta sección presenta el entorno de simulación ylas aplicaciones utilizadas en la evaluación de losFig. 3. MPKI de los algoritmos pMRU, Bubble y LRU enuna cache de 1MB-16vías.algoritmos, los cuales han sido modelados en unaversión extendida del simulador SimpleScalar [16].Los resultados experimentales han sido obtenidosconfigurando el simulador para el juego de instruccionesAlpha y lanzando las aplicaciones de SPEC2000,que se evalúan utilizando las entradas ref, ejecutando1000M de instrucciones antes de recolectarestadísticas y simulando posteriormente 500M deinstrucciones con detalle. La Tabla II muestra losparámetros arquitectónicos utilizados en los experimentos.Las aplicaciones que no estresan la cache de L2 hansido eliminadas del estudio. Para ello, se ha obtenidoel porcentaje de fallos forzosos de cada aplicación. LaTabla III muestra los resultados para una cache de L2de 1MB-16vías. Se ha prescindido de las aplicacionescon un porcentaje de fallos forzosos mayor que un75% o con un MPKI menor que uno 1 .A. Prestaciones del algoritmo pMRUEsta sección evalúa las prestaciones del algoritmopropuesto. Para ello, sus prestaciones han sido comparadascontra las obtenidas con el algoritmo LRUy la reciente propuesta del algoritmo Bubble. LaFigura 3 muestra el MPKI de las políticas analizadas.El algoritmo pMRU obtiene, en la media, losmejores resultados y reduce el MPKI en un 6% y 15%comparado con Bubble y LRU, respectivamente. Sepuede observar que la propuesta obtiene los mejoresresultados en aquellas aplicaciones que presentan unMPKI elevado.Cabe analizar con detalle los resultados obtenidoscon las aplicaciones ammp y art. En la primera, elMPKI es 68.7, 63.5 y 49.7 en los algoritmos LRU,Bubble y pMRU, respectivamente. En art, el algoritmopMRU reduce el MPKI en un 37% respectoa LRU. El MPKI tan elevado de LRU puede expli-1 Las diferencias en MPKI observadas para todos los algoritmosanalizados en este trabajo son menores que 0.4 en lasaplicaciones eliminadas.JP2011-560

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011carse mediante los resultados de la Figura 1. En elcaso de ammp, los bloques que se encuentran en posicionesalejadas de la MRU, es decir, los bloques queLRU reemplaza tienen una gran probabilidad de retorno.El comportamiento de art se puede razonarde la misma manera. Además, de acuerdo con losresultados de la Tabla I, la mayoría de bloques deestas cargas se llevan a la cache y no se vuelven areferenciar una vez abandonan la posición MRU. Elalgoritmo propuesto obtiene los mejores resultadosporque reemplaza rápidamente estos bloques y tratade mantener los que vuelven a ser referenciados enposiciones no-MRU.B. Mejorando las prestaciones del algoritmo pMRUAunque la política pMRU consigue mejores resultadosen algunas aplicaciones comparado con LRU,no lo consigue con otras cargas. Esto puede explicarsemediante el hecho de que el algoritmo pMRUoriginal no tiene en cuenta la recencia de información.Este problema se ataca mediante los algoritmospMRU-bX. La Figura 4 muestra los resultadosvariando X entre 1 y 4.La política pMRU-b3 muestra, en la media, unMPKI mejor que las otras variantes. De nuevo,la razón puede ser explicada mediante los resultadospresentados en la Figura 1. Comparado conlos algoritmos pMRU-b1 y LRU, pMRU-b3 reduceel MPKI en un 4% y 19% en la media, respectivamente.Nótese que incrementar X no siempre mejoralas prestaciones. Este el caso, por ejemplo, de facerec.La razón es que la probabilidad de accedera bloques localizados en la cuarta posición es muybaja en la mayoría de aplicaciones. Por tanto, el hechode que estos bloques no sean considerados comocandidatos para el reemplazo provoca que otros bloquescon mayor probabilidad de retorno (localizadosen posiciones inferiores) puedan ser reemplazados deforma errónea.C. Dividiendo los conjuntos en gruposEl algoritmo Bubble fue diseñado también paradividir los bloques de los conjuntos en grupos y asíresolver sus problemas. En un fallo de cache, se eligede manera aleatoria un grupo del conjunto y se seleccionael bloque víctima de ese grupo. Esta seccióncompara las prestaciones de las políticas Bubbley pMRU aplicadas en grupos. Se ha utilizado elprefijo ’DC’ para denotar esta técnica de divide-yvencerás.Cada grupo está compuesto por 4 bloquesporque Bubble obtiene los mejores resultadoscon este número. Así, en una cache de 16-vías cadaconjunto está formado por 4 grupos.Nótese que hemos tenido sólo en cuenta los algoritmosDC-pMRU-b1 y -b2 porque -b3 considera siempreun solo candidato para reemplazo. La Figura 5muestra los resultados. Se puede observar que DCpMRU-b1obtiene mejor MPKI que -b2 y DC-Bubbleen la media.En resumen, los mejores resultados son aquellosobtenidos con la política pMRU-b3 trabajando enconjuntos de 16-vías. Esta versión obtiene una reducciónde un 8%, 10% y 19% comparado con DC-Bubble, Bubble y LRU, respectivamente. Además, lapropuesta aplicada en condiciones adversas (DC) obtienemejores resultados que DC-Bubble (reducciónde MPKI en un 4% en la media).VI. Complejidad hardwareEsta sección analiza la complejidad hardware delos algoritmos estudiados en base al número de bitsde estado por bloque y el número máximo de estosbits que cambian su valor en el peor caso de cadaalgoritmo.La política LRU requiere log 2 (n) bits por bloque(contadores LRU) para mantener el orden de la pilaen una cache asociativa por conjuntos de n-vías. Enel peor caso, es decir, un acierto en la vía LRU o unfallo de cache, se deben actualizar todos los contadores,lo que supone un cambio de valor de 30 bitsen una cache de 16-vías.Por otra parte, el algoritmo pMRU más sencilloreduce el número de bits a 2 por bloque independientementede la asociatividad de cache. Estos bitsson el pMRU-bit y un bit adicional para indicar elbloque MRU (MRU-bit). En el peor caso, sólo se requiereactualizar el valor de 3 bits. Además, eligiendola víctima al azar entre los candidatos se reduce lacomplejidad del circuito. Con todo, la propuesta reduceen gran medida el consumo energético de losbits de estado.Los algoritmos de la familia pMRU-bX requierenY = ⌈log 2 (X+1)⌉ bits de estado para indicar el ordende los últimos X bloques referenciados. PorFig. 4. MPKI de los algoritmos pMRU-bX, variando X entre1 y 4.Fig. 5. MPKI de los algoritmos pMRU-b1, pMRU-b2 y Bubbleaplicados en grupos.JP2011-561

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ejemplo, para las políticas pMRU-b2 y -b3, se necesitan3 bits de estado (2 MRU-bits y un pMRU-bit).En el peor caso, es decir, un fallo de cache o el accesoa un bloque no incluido en los últimos X, laspolíticas pMRU-b2 y -b3 sólo actualizan 5 y 7 bits,respectivamente.En contraste con los algoritmos propuestos, Bubblerequiere tantos bits de estado como LRU porquedebe mantener todo el orden de los bloques. Además,se requiere un bit adicional por conjunto para indicarsi el acceso anterior fue un acierto o un fallo. En elpeor caso, esto es dos fallos consecutivos, deben actualizarsehasta 26 bits de estado.Finalmente, dividir los conjuntos en grupos resultabeneficioso en términos de número de bits de estado.Aunque DC-Bubble requiere el bit por conjunto aligual que Bubble, en una cache de 16-vías y 4 bloquespor grupo, sólo se necesitan 2 bits de estado porbloque. En cada grupo, 4 bits cambian su valor enel caso de dos fallos consecutivos. Aplicando pMRUen grupos, DC-pMRU-b1 sólo necesita un pMRU-bity otro MRU-bit por bloque y puede prescindir delbit por conjunto, con lo cual reduce la complejidadrespecto a DC-Bubble. En el peor caso, sólo se actualizan3 bits de estado.VII. ConclusionesEn este trabajo se han presentado algoritmos basadosen el concepto de periodo MRU (pMRU) con elobjetivo de que sean aplicados en caches de últimonivel. Se ha definido el número de pMRU de unbloque como el número de veces que ese bloque ocupala posición MRU. Además, se ha observado que utilizandoel algoritmo LRU, la mayoría de los bloquestienen un solo pMRU en el momento en que sonreemplazados. En este trabajo también se ha evaluadola probabilidad de un bloque de retornar a laposición MRU estando en una posición no-MRU. Losresultados han mostrado que la mayoría de aplicacionesexhiben una probabilidad de acceso alta envías cercanas a la MRU, pero esta probabilidad nodisminuye siempre conforme los bloques se acercan ala posición LRU.Basándose en estas ideas, se ha propuesto el algoritmopMRU que trata de seleccionar como víctimaaquellos bloques con un solo pMRU. En su versiónmás sencilla, sólo requiere un bit por bloque para indicaruno o varios pMRU y otro bit adicional paraindicar cual es el bloque MRU. Con objeto de simplificarel circuito, la víctima entre los candidatos conun pMRU excepto el bloque MRU se selecciona alazar. Si todos los bloques presentan varios pMRU,la víctima se selecciona al azar entre los bloques no-MRU.Los resultados experimentales han mostrado que,en la media, el MPKI se reduce en un 15% respectoa LRU. Esta reducción se eleva hasta un 37% enalgunas aplicaciones. Para tener en cuenta el hechode que existe una probabilidad de acceso elevadaen vías cercanas a la MRU, se ha explorado sobreel algoritmo pMRU que los últimos X bloques referenciadosno sean candidatos en el reemplazamiento.Los resultados han mostrado que fijando X = 3 lareducción de MPKI es de un 8% y 19% comparadocon DC-Bubble y LRU, respectivamente. Además, elalgoritmo pMRU más sencillo reduce la complejidadhardware comparado con DC-Bubble y LRU. Estealgoritmo sólo necesita 2 bits de estado por bloque yactualiza como máximo 3 bits en el peor caso, mientrasque DC-Bubble y LRU requieren 2 y 4 bits deestado por bloque, respectivamente. En el peor caso,DC-Bubble actualiza 4 bits y LRU actualiza 30 bits.AgradecimientosEl presente trabajo ha sido financiado mediantelos proyectos CICYT TIN2009-14475-C04-01y Consolider-Ingenio CSD2006-00046.Referencias[1] A. J. Smith, ”Cache Memories,” ACM Computing Surveys,vol. 14, pp. 473-530, 1982.[2] R. Kalla, B. Sinharoy, W. J. Starke, and M. Floyd,”Power7: IBM’s Next-Generation Server Processor,”IEEE Micro, vol. 30, pp. 7-15, 2010.[3] J.-L. Baer, Microprocessor Architecture: From SimplePipelines to Chip Multiprocessors, Cambridge UniversityPress, 2010[4] L. A. Belady, ”A Study of Replacement Algorithms forVirtual-Storage Computer,” IBM Systems Journal, vol.5, no. 2, pp. 78-101, 1966.[5] W.-F. Lin and S. Reinhardt, ”Predicting Last-Touch Referencesunder Optimal Replacement,” in Technical ReportCSE-TR-447-02, University of Michigan, 2002.[6] M. Chaudhuri, ”Pseudo-LIFO: The Foundation of a NewFamily of Replacement Policies for Last-level Caches,” inProceedings of the 42nd Annual IEEE/ACM InternationalSymposium on Microarchitecture. 2009, pp. 401-412.[7] C. Zhang and B. Xue, ”Divide-and-Conquer: A BubbleReplacement for Low Level Caches,” in Proceedings of the23rd International Conference on Supercomputing. 2009,pp. 80-89.[8] G. Tyson, M. Farrens, J. Matthews, and A. R. Pleszkun,”A Modified Approach to Data Cache Management,” inProceedings of the 28th Annual International Symposiumon Microarchitecture. 1995, pp. 93-103.[9] T. L. Johnson, D. A. Connors, M. C. Merten, and W.-M.W. Hwu, ”Run-Time Cache Bypassing,” IEEE Transactionson Computers, vol. 48, pp. 1338-1354, 1999.[10] J. A. Rivers, E. S. Tam, G. S. Tyson, E. S. Davidson, andM. Farrens, ”Utilizing Reuse Information in Data CacheManagement,” in Proceedings of the 12th InternationalConference on Supercomputing. 1998, pp. 449-456.[11] H. Dybdahl, P. Stenström, and L. Natvig, ”An LRUbasedReplacement Algorithm Augmented with Frequencyof Access in Shared Chip-Multiprocessor Caches,” ACMSIGARCH Computer Architecture News, vol. 35, pp. 45-52, 2007.[12] S. Jiang and X. Zhang, ”LIRS: An Efficient Low InterreferenceRecency Set Replacement Policy to ImproveBuffer Cache Performance,” in Proceedings of the 2002ACM SIGMETRICS International Conference on Measurementand Modeling of Computer Systems. 2002, pp.31-42.[13] W. A. Wong and J.-L. Baer, ”Modified LRU Policiesfor Improving Second-Level Cache Behavior,” High-Performance Computer Architecture, vol. 0, pp. 49, 2000.[14] D. Wood, M. D. Hill, and R. E. Kessler, ”A Model for EstimatingTrace-Sample Miss Ratios,” in Proceedings of the1991 ACM SIGMETRICS International Conference onMeasurement and Modeling of Computer Systems. 1991,pp. 79-89.[15] Standard Performance Evaluation Corporation, availableonline at http://www.spec.org/cpu2000[16] D. Burger and T. M. Austin, ”The SimpleScalar ToolSet, Version 2.0,” ACM SIGARCH Computer ArchitectureNews, vol. 25, pp. 13-25, 1997.JP2011-562

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A Comparison of Cache Hierarchies for SMTProcessorsDarío Suárez Gracia 1 , Teresa Monreal Arnal 2 , and Víctor Viñals Yúfera 1Abstract—In the multithread and multicore era, programsare forced to share part of the processor structures.On one hand, the state of the art in multithreadingdescribes how efficiently manage and distributeinner resources such as reorder buffer or issuewindows. On the other hand, there is a substantialbody of works focused on outer resources, mainly onhow to effectively share last level caches in multicores.Between these ends, first and second level caches haveremained apart even if they are shared in most commercialmultithreaded processors.This work analyzes multiprogrammed workloadsas the worst-case scenario for cache sharing amongthreads. In order to obtain representative results, wepresent a sampling-based methodology that for multiplemetrics such as STP, ANTT, IPC throughput,or fairness, reduces simulation time up to 4 orders ofmagnitude when running 8-thread workloads with anerror lower than 3% and a confidence level of 97%.With the above mentioned methodology, we compareseveral state-of-the-art cache hierarchies, and observethat Light NUCA provides performance benefitsin SMT processors regardless the organization of thelast level cache. Most importantly, Light NUCA gainsare consistent across the entire number of simulatedthreads, from one to eight.Keywords— Cache Hierarcy, Multithreading, Simulation,Sampling, NUCAI. IntroductionMULTITHREADING (MT) is supported by anample spectrum of current processors devotedto uneven computing segments such as: embedded,high throughput, or high performance. Examplesof representatives from these segments areNetlogic XLP832 (4-way multithreading, 8-cores), OracleSPARC T3 (8-way multithreading, 16-cores), orIBM POWER7 (4-way multithreading, 4-6-8 cores),respectively [1], [2], [3].All previous examples share a powerful multilevelcache hierarchy with large Last Level Caches (LLC),and only the XLP832 departs from the conventionalorganization including a ring for communicating theprivate L2 caches, the eight L3 cache banks, andthe four DDR ports. While these LLCs seem ableto accommodate the multiple working sets of SMTexecution, sharing in the levels close to the processorsproves to be more complex. On one hand, L1 andL2 caches deal with the latency-power vs. size tradeoff.On the other hand, MT architectures add a newtrade-off, number of threads in execution vs. miss rate.With many threads, cache misses can be toleratedexecuting instructions from other threads, but as1 Computer Architecture Group (gaZ). Dpto. de Informáticae Ingeniería de Sistemas. Instituto de Investigación en Ingenieríade Aragón. Universidad de Zaragoza. e-mail {dario,victor}@unizar.es2 Department of Computer Architecture. Universitat Politécnicade Catalunya (UPC). e-mail: teresa@ac.upc.eduthe number of threads grows, the collective workingset becomes larger and more changing, resulting inmiss ratios potentially harmful to performance. Thelarger their number, the larger and size changing thecollective working set becomes and the larger themiss rate. So when the miss rate reaches a criticalvalue in which threads execution fails to overlap, theprocessor stalls and has the same problem that singlethread machines.SMT architectures may be favored by caches designedto support working set awareness such us theL-NUCA [4]. L-NUCAs belong to a family of cacheorganizations that has received much attention forimproving cache performance: Non-Uniform CacheArchitecture (NUCA) [5]. The seminal NUCA worktargets the wire delay problem 1 , and proposes themelting of the L2 and L3 caches into a meshed arrayof caches banks. Nevertheless, to the best of ourknowledge, there is little work on evaluating NUCAwith simultaneous multithreading processors (SMT).Part of the complexity of assessing multiple cachehierarchies lies in the required simulation framework.So to carry out the experiments, we propose a simpleyet efficient MT simulation methodology ensuring theaccuracy of the results abreast with a sort simulationtime. The methodology is based on statisticalsampling, and contrary to other alternatives does notrequire a prior long profiling of the applications.This work gives two main contributions. The firstone is introducing a powerful methodology to evaluateMT architectures. The second one is the comparisonand evaluation of several state-of-the-art cache hierarchyorganizations driven by the SPEC CPU2006benchmark suite. From the results, we conclude thatregardless the number of threads L-NUCAs outperformconventional multibanked and dynamic NUCAorganizations, both in terms of throughput and fairness.The rest of the paper is organized as follows. SectionII elaborates on previous work. Section IIIpresents the proposed evaluation methodology. SectionIV describes our experimental framework andthe hierarchies under test. Section V comments onthe results, and Section VI concludes the paper.II. BackgroundTullsen, Eggers, and Levy in their SMT seminalwork compare the performance of private and sharedL1 caches (for both instruction and data) and observethat regardless the number of threads (from 1 to 8)shared data caches are the best choice and private1 The wire delay is longer than the bank delay and representsmost part of the total cache latency in LLCs.JP2011-563

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011instruction ones are only preferable for the 8-threadcase [6]. Also they point out that shared cachesdo not require any special hardware for coherencesupport. Then, Tullsen and Brown observed that inmany cases when a thread experiences a very longlatency operation, such as a cache miss, it is better toflush the resources of the stalled thread rather thankeeping them ready [7].Hily and Seznec studied how secondary cache bandwidthlimited SMT performance in a trace-drivenenvironment [8]. They point out that the larger thenumber of executed threads the larger the L1 cachesize has to be. Besides, when the number of threadsincreases, the memory references generated by thesimultaneous execution of independent threads exhibitless spatial locality than that of a single thread,increasing conflict misses.Block size is more criticalthan associativity and as the number of threads rise,it is preferable to keep small block sizes (16 to 32BS).To improve SMT performance, Settle et al. definea cache partitioning scheme based on column caching[9]. Two policies can control the partitioning: (a)synchronous in which each 1 million cycles, the partitionis heuristically set for the next interval. (b)asynchronous in which the LRU algorithm is affectedby some thread reuse counters.Nemirovsky and Yamamoto analyzed the effect ofvarying cache capacity, associativity, and line sizeon miss rate for multistreamed architectures [10].They observe that increasing both cache capacity andassociativity reduces miss ratio specially for smallcaches and that large block size increase miss ratio.The Multithreaded Virtual Processor (MVP) isa coarse-grain multithreaded system with softwaresupport that explicitly forces context switching onlong latency events such as cache misses, I/O, orsynchronization [11]. The evaluation comprised parallelworkloads, and they show that when threadsshare a few data, the increment in miss rate affectsperformance.Garcia et al. studied several data cache organizationsfor multithreaded processors using a tracedrivenenvironment [12]. In accordance with otherauthors [8], [13], they observe that large associativitiesreduce inter-thread misses and that XOR-basedplacement reduces inter-thread miss rate in somecases. Besides, they proposed several organizationscombining the hash-rehash caches and static cachesplitting.Sarkar and Tullsen proposed two strategies to minimizeinter-object data cache misses at compilationtime [14]. Lopez et al. studied control strategies forreconfigurable caches in SMT GALS processors witha limited set of SPEC CPU2000 benchmarks. Theyconclude that the best control strategy to maximizeperformance is the harmonic mean of the per-threadweighted access time [15], [16].Several authors have proposed SMT methodologiesfor selecting representative mixes of programs.Raasch and Reinhardt propose to profile individualapplications and with the extracted characteristicschoose the most representative pairs [17]. By combiningthe pairs, they also generate 4-thread workloads.Van Biesbrouck et al. proposed a methodology consideringall starting phases and points but it requiresa complex profiling and an advanced work flow togather the results [18].On the contrary our approach neither require profilingnor complex output information gathering, butit does not consider multiple starting points by default.Nevertheless, since we employ last simulationpolicy 2 , faster programs execute multiple times untilthe slower ones finishes, so they run together startingat different points.Finally, our proposal cares about how to selectrepresentative mixes of multiprogrammed workloadsand not when to finalize simulations for obtainingaccurate metrics. In fact, this work pairs perfectlymethods such as FAME [19].III. A Simple Statistic-based Methodologyfor Multiprogrammed WorkloadsThe generation of simulation traces is always a timeconsuming and costly process. Single program tracesextracted with solid approaches such as SimPointsor SimFlex provide accurate simulation results [20],[21]; however, no guidelines are found in the literatureabout how to obtain a representative set ofthread mixes from representative samples of threadindividuals. Our goal is to provide a simple methodto efficiently simulate multiprogramed workloads formultiple metrics.The key idea is instead of executing all possiblecombinations for a given number of threads, to executea representative sample based on statisticalsampling [22], [21] so that simulation time reducesby several orders of magnitude while keeping measurementsbelow a given error within a confidencelevel large enough. In this work, we focus on mixescomposed of different threads (combinations withoutrepetition), but the proposed methodology can beused with repetition as well.Fig. 1.selection ofmetrics of interestset preliminarysample sizerunsimulationserror withinconfidenceintervalyesresultsreadyselection ofmicro-architecturalconfigurationsincreasesample sizeFlowchart of the proposed methodologyFigure 1 shows the required steps to obtain thesample:Selection of metrics of interest: For exampleif we want to compare the impact of different cache2 Simulation finishes when all threads have executed at least100M instructions.noJP2011-564

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011hierarchies on SMT processors we can take adjustedSTP and ANTT, IPC throughput 3 , and fairness [23],[24].ST P =n∑i=1IP C througput =CP IiSPCP IiMP , ANT T = 1 nn∑i=1CP I MPiCP I SPi(n∑min iIP C i , fairness =i=1maxiCP I MPiCP I SPi(CP I MPiCP I SPiMP and SP refer to the multithreaded and singlethreadedexecution of a program.Selection of micro-architectural configurations:Pick some of the configurations to be analyzed.In general those with lower performance arepreferable because they tend to experiment the highestvariances of the metrics. In our cache hierarchycomparison, we can take a conventional multibankedorganization, a dynamic NUCA, and a light NUCA.Set preliminary sample size: In this step, wehave to choose a sample size—the larger the numberof threads, the lower this value [25]—, and then, torandomly pick the combinations of programs for theirsimulation. This value should be big enough [22],larger than 30 at least, but tractable in the desiredsimulation environment.Run simulations: Run the selected combinationsand compute the sample size for your given confidenceinterval with the next formula [22]:( ) 2 100 × z × sn =(1)r × xwhere n, z, s, r, and x stand for the sample size,normal variate of the confidence interval, error (in%), sample standard deviation, and population mean,respectively.Error within confidence level?: Check if theobtained n is lower of equal than your preliminarysample size. If not, pick some different extra combinations,run them, and repeat the last steps until theresults are ready.Once a sample size has been established, all the configurationsunder test must be run in order to checkthat their results also fit within the confidence interval.Adding new configurations require the same procedure,so if the initial selection of micro-architecturalconfigurations is carefully done, the sample size willnot grow.IV. Comparing SMT cache HierarchiesA. Common Baseline ParametersWe have heavily extended Simplescalar 3.0d [26]for Alpha with: Simultaneous Multithreading Support[6], Reorder buffer and three issue windows (IW)for integer, floating point, and memory instructions,speculative wake-up support and selective recovery3 IPC throughput is advantageous because it allows anabsolute comparison among configurations. We can useIPC throughput whenever mixes are made from independentthreads, because then no unpredictable instruction spinningcan arise; e.g., before entering a critical section.))(as in the Intel Pentium 4 [27]), one-cycle payloadand register file stages, accurate timing models fornon-blocking caches, write buffers, buses, networkcontention, flow control, and request arbitration. Forthe rest of parameters see Table I.TABLE IBaseline Processor ConfigurationFetch ICOUNT.2.8Decode / Commit Width 4Branch bimodal + gshare, ROB / LSQ 198 / 96Predictor 16 bitIssue 4 (INT + MEM) + Issue 64(INT) / 32Width 4 (FP)Queues (FP & MEM)FunctionalUnits4 INT + 4 FP ALU, 2 INT MULT + 4 FPMULT/DIVL1 cache 64KB-4Way-32B BS-2ports-LRU, Lat 2, Init.Rate 1L2 128KB:1MB-8Way-32B BS-1port-LRUD-NUCA 128KB:512KB-4Way-128B BS-1port-LRU, 8columnsL-NUCA 2:5Levels-16KB-4Way-32B BS-1port-LRFL3 8MB-16W-128B BS-1port-LRU, 8 banksMainMemoryFirst chunk: 200 cycles, 4-cycle inter chunk,16B wiresThread fetch is prioritized based on the ICOUNTpolicy [28]. Structures such as ROB, IWs, STB,WB,. . . are shared among threads. To avoid starvationat commit, a thread can not occupy morethat three quarters of L2/L-NUCA/D-NUCA WriteBuffers. Threads commit in Round Robin fashionwith a maximum of 4 instructions committed by allthe threads (RR.4.X), where X corresponds to thenumber of threads in execution [28].B. Cache Memory OrganizationsFocussing in the first and second cache levels, wehave selected three very distinct organizations. Thefirst one is the baseline, corresponding to a conventional3-level hierarchy with a 4-banked L2 cache,and an 8-banked, 8-MB L3 cache, see Figure 2.In any cycle, the L2 cache can start servicing upto two L1 load misses from the MSHR, the rest ofbanks can simultaneously begin the processing of awrite buffer entry, and two whole cache blocks canbe in transit to the L1 MSHR. For this configuration,we tested L2 sizes from 128KB to 1MB organized ineither 1, 2, 4, and 8 banks. The output crossbar hasa fixed latency of 2 cycles with an initiation rate of 1in configurations with 2 or more banks.L2_0mshrL2 bank0 L2 bank1 L2 bank2 L2 bank3L2: fetch-on-missL1: fetch-on-missFig. 2.L2_1mshrL1cache ports(a) Loadsto/fromnext cache levelL2_2mshr...L1 mshrL2_3mshrL2_0mshrL2 bank0 L2 bank1 L2 bank2 L2 bank3wb0 wb1 wb2 wb3L2: copy-back,fetch-on-writeL1: write-through,write-aroundL2_1mshrL1cache ports(b) Storesto/fromnext cache levelL2_2mshrBaseline L2 cache organization with 4 banksThe second hierarchy replaces the L2 and L3 cachesby a dynamic NUCA (D-NUCA) [5], Figure 3, inL2_3mshrJP2011-565

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011DN bank0 DN bank1 DN bank2 DN bank3 DN bank4 DN bank5 DN bank6 DN bank7............DN bank0 DN bank1 DN bank2 DN bank3 DN bank4 DN bank5 DN bank6 DN bank7............entries as threads are simultaneously executing. Asstated by Hily and Seznec, bandwidth can be thelimiting factor of the cache hierarchy in SMT [8], andthe larger the number of banks (up to 8), the biggerthe performance.D-NUCA: fetch-on-missL1: fetch-on-missL1cache ports...L1 mshrFig. 3. Multibanked Dynamic NUCA. A block can be mappedto any of the columns surrounded by a dashed linewhich its original interface with the L1 cache andshared mapping have been replaced by a crossbar toprovide more bandwidth and by a simple mapping 4 ,respectively. As in the conventional organization,there is a write buffer for each column. In this waywe can inject the same number of requests per cycle,so the conventional hierarchy can be considered asa particular case of a NUCA with a single row andwithout the partial tags [5].The last one is Light NUCA (L-NUCA) [4], butalso modified to provide more bandwidth, see Figure4. Changes include widening the search linksfrom word to block size (from 8 to 32B), increasingthe write buffer size to match the rest of organizations(the buffer in between the r-tile and the rest oftiles). Besides the replacement buffers are managedwith an improved back-pressure policy, so that theeviction of blocks from the r-tile does not stall untilthe replacement buffer of the r-tile becomes full.We tested 2 organizations based on L-NUCA, oneincluding the same L3 than the baseline organization,and another in which the LLC is a dynamic NUCA,similarly to previous work [4].level 2tilelevel 2tileRESTT tilesL-NUCAmiss queueto next cache levellevel 2tileRTcache portsRESTT: no-fetch-on-missRT: fetch-on-missRT mshr(a) Loads...level 2tilelevel 2tilefrom nextcache levellevel 2tilelevel 2tileRESTT tilesnext cachewblevel 2tileRTcache ports(b) StoresRESTT: copy-back,write-aroundRT: copy-back,write-aroundin-flightstoreshift reg.RESTTwblevel 2tilelevel 2tileFig. 4. 2-level L-NUCA load and store logical organization.For the sake of clarity, the Figure includes neither allnetwork nor control flow linksDuring the setup or the organizations, we observedtwo interesting design details helping to maximizeperformance. First, regarding the priority of L1/rtilemisses, loads should have priority over writesexcept when a miss hits in the write buffer 5 in whichcase priorities are reversed until the requested datacan be served by the cache. Second, a centralizedwrite buffer reduces performance except when thenumber of entries at each distributed write buffer isvery small. As an approximate rule of thumb, eachbank requires a coalescing write buffer with as many4 A block can only reside in one column.5 Write buffers do not provide data.C. WorkloadsOur multiprogrammed workload comprises combinationsof 2, and 4, 6, and 8 programs from SPECCPU2006 without repetition, namely, all benchmarksbut 483.xalanbmk [29]. For this type of study, multiprogramedloads are preferable over parallel onesbecause they stress more the memory hierarchy sincethere is no sharing among threads. For each program,we have selected a representative trace consisting of100 million instruction following the SimPoint guidelines[20]. Simulations terminate when all threadshave executed at least 100M instructions, last policy,but program statistics are gathered for the first 100M.V. Experimental ResultsA. Sample Sizes and Simulation TimeTable II shows the number of all combinations withoutrepetition of our traces executing 2, 4, 6, and 8threads, the average time required for running onecombination of programs 6 , and the sample size requiredto obtain accurate results, with an error lessthan 3% with a 97% confidence level for all configurationsunder test. This means for example thatin 97 of 100 times a randomly chosen sample of 251combinations will have an error than 3% in all themetric compared to the whole population of 6-threadscombinations (37674). For the 2 threads case, we executeall combinations because total execution timeis affordable. Nevertheless, as we increase the numberof threads, our methodology obtains savings insimulation time of ×93, ×150, and ×9743, for 4, 6,and 8 threads, respectively.TABLE IISample sizes varying the number of threads# Threads2 4 6 8Total combinations 378 20475 37674 3108105Avrg. sim. time (min) 18.5 45.7 60.4 90.5Sample size — 220 251 319Table II provides the minimum sample size for allmetrics of interest with an error less than 3%, inour case: STP, ANTT, IPT throughput, and fairness.Since fairness represents the ratio between the minimumand maximum slowdowns, it has the largestvariance, and, hence, determines the required samplesize.If we focus on a single number of threads, for example4, we can show the sample size of the bestconfigurations from each organization as table IIIdoes. L2, NC-IxJ, LNI, LNI-NC-JxK correspond6 This value is for the L-NUCA + D-NUCA simulator, theslowest in our simulation framework, in an Intel Nehalem 2.33GHz.JP2011-566

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011to the conventional baseline, D-NUCA with I columnsand J rows, L-NUCAs with I levels, and L-NUCAscombined with D-NUCAs organizations, respectively.Besides, each configuration includes its total size forthe L2 and L-NUCAs and the size of their banks forD-NUCA.TABLE IIISample sizes for the different metrics andconfigurations in 4SMT executionMetricIPCSTP ANTT Throughtput FairnessL2-256KB-8Banks 126 111 85 162L2-1MB-8Banks 126 113 90 160NC-8x2-512KB 111 132 119 218NC-8x4-256KB 118 141 128 220LN3-240KB 103 96 51 194LN4-448KB 103 96 51 193LN2-NC-8x2 104 96 48 189LN2-NC-8x4 105 97 47 188LN3-NC-8x2 106 96 46 210LN3-NC-8x4 103 95 47 211Irrespective of the organization, we observe thatthe required sample size follows a common trend:computing IPC throughput requires small sizes whilefairness, due to its greater variance, requires doublingor even quadrupling the sample size. STP and ANNTlie in a middle ground. Across all organizations, IPCthroughput is the metric giving the more unevensample sizes, meaning that L-NUCA organizationsachieve less IPC variability among individual threadcombinations. From these results, we conclude thatin general adding a different configuration to test doesnot require a large investment in new simulations forthe preexisting configurations. Finally, fairness is theonly metric that requires more samples as the numberof threads rise. While many threads are able to keepall functional units busy, they tend to bother eachother starving some of them. Conclusions are similarfor other number of threads, and we do not showthem for the sake of brevity.B. STP, ANTT, IPC throughput, and FairnessFigure 5 shows the results for the four metrics ofinterest for the best configuration of each hierarchyorganization. STP and ANTT are metrics relative tothe performance of a single thread system aimed atprograms that may expend time in spin-lock loops,which is not our case [24]. In both metrics, L2 overpassesthe rest of hierarchies from 4 threads andbeyond, and the L-NUCA ones dominates in the 2thread case. This results are mostly due to the factthe L2 has the worst IPC in single-thread mode andthe maximum IPC for all configurations is 4, so L2 relativeslowdowns are smaller as the number of threadrises.IPC throughput is an absolute metric representingthe amount of committed instructions per unit oftime. LN+NC achieves the best results regardlessthe number of threads close followed by LN. Thesmall difference between them is mostly due to theNUCA partial tags not present in the L3 [5]. As thenumber of threads and bandwidth demand increase,the L2 overpasses the NC.Fairness is defined as the quotient between theprograms that have suffered the lowest and the highestslowdowns. A value of zero means complete starvationof one thread,and a value of one means all threadsexperience the same slowdown.VI. ConclusionsThe adoption of thread level parallelism as themainstream way to continue improving the performancepace of computers requires novel mechanismand the reevaluation of those which are well establishedsuch as cache hierarchies. While large LastLevel Caches have received a lot of attention in recentyears, first and second levels have remained apart.This work analyzes multiple state-of-the-art cachehierarchies executing multiprogramed workloads from2 to 8 threads. In order to provide accurate resultsin a reasonable amount of time, we propose a samplingbased methodology reducing simulation timeby up 4 orders of magnitude for 8 thread workloads,respectively. These savings do not occur at the costof fidelity because their error is less than 3% for a97% confidence level for a high variance metric suchas fairness.From the analysis we observe that regardless ofthe Last Level Cache and the number of threads, L-NUCA provides the more efficient solution in termsof both throughput and fairness.AcknowledgementThis work was partially supported by grantsTIN2010-21291-C02-01 (Spanish Government andEuropean ERDF), gaZ: T48 research group(Aragón Government and European ESF), ConsoliderCSD2007-00050 (Spanish Government), and HiPEAC-2 NoE (European FP7/ICT 217068).References[1] Tom R. Halfhill, “Netlogic broadens XLP family,” MicroprocessorReport, vol. 24, no. 7, pp. 1–11, 2010.[2] J. L. Shin, K. Tam, D. Huang, B. Petrick, H. Pham,Changku Hwang, Hongping Li, A. Smith, T. Johnson,F. Schumacher, D. Greenhill, A. S. Leon, and A. Strong,“A 40nm 16-core 128-thread cmt sparc soc processor,” inProc. IEEE Int. Solid-State Circuits Conf. Digest of TechnicalPapers (ISSCC), 2010, pp. 98–99.[3] Ron Kalla, Balaram Sinharoy, William J. Starke, andMichael Floyd, “Power7: Ibm’s next-generation serverprocessor,” IEEE Micro, vol. 30, pp. 7–15, 2010.[4] Darío Suárez, Teresa Monreal, Fernando Vallejo, RamónBeivide, and Víctor Viñals, “Light NUCA: a proposalfor bridging the inter-cache latency gap,” in Prooceedingsof the 12 th Design, Automation and Test in EuropeConference and Exhibition (DATE’09), April 2009.[5] Changkyu Kim, Doug Burger, and Stephen W. Keckler,“An adaptive, non-uniform cache structure for wire-delaydominated on-chip caches,” in Proceedings of the 10thinternational conference on architectural support for programminglanguages and operating systems (ASPLOS-X).October 2002, pp. 211–222, ACM Press.[6] D.M. Tullsen, S.J. Eggers, and H.M. Levy, “Simultaneousmultithreading: Maximizing on-chip parallelism,” inProceedings. 22nd Annual International Symposium onComputer Architecture, Jun 1995, pp. 392–403.[7] Dean M. Tullsen and Jeffery A. Brown, “Handling longlatencyloads in a simultaneous multithreading processor,”in MICRO 34: Proceedings of the 34th annualJP2011-567

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011adjusted STP21.510.5L2NCLNLN+NCadjusted ANTT54321L2NCLNLN+NC01 2 4 6 8Number of Threads01 2 4 6 8Number of Threads43.53L2NCLNLN+NC10.8L2NCLNLN+NCIPC Throughput2.521.510.5Fairness0.60.40.201 2 4 6 8Number of Threads01 2 4 6 8Number of ThreadsFig. 5. Results for the best configuration of each organization: L2, NC, LN, and LN+NC correspond to the L2-256KB,NC-8x4-256KB, LN3-240KB, and LN2-NC-8x4, respectivelyACM/IEEE international symposium on Microarchitecture,Washington, DC, USA, 2001, pp. 318–327, IEEEComputer Society.[8] Sébastien Hily and André Seznec, “Contention on 2 ndlevel cache may limit the effectiveness of simultaneousmultithreading,” Tech. Rep. 1086, IRISA, fébrier 1997.[9] Alex Settle, Dan Connors, Enric Gibert, and AntonioGonzález, “A dynamically reconfigurable cache for multithreadedprocessors,” J. Embedded Comput., vol. 2, no.2, pp. 221–233, 2006.[10] Mario Nemirovsky and Wayne Yamamoto, “Quantitativestudy of data caches on a multistreamed architecture,” inIn Workshop on Multithreaded Execution, Architectureand Compilation, 1998.[11] Hantak Kwak, Ben Lee, Ali R. Hurson, Suk-Han Yoon,and Woo-Jong Hahn, “Effects of multithreading on cacheperformance,” IEEE Transactions on Computers, vol. 48,pp. 176–184, 1999.[12] Montse García, José González, and Antonio González,“Data caches for multithreaded processors,” in Proc. ofthe Workshop on Multithreaded Execution, Architectureand Compilation, 2000.[13] Sébastien Hily and André Seznec, “Standard memory hierarchydoes not fit simultaneous multithreading,” in Proceedingsof the 2 nd Workshop on MULTI-THREADEDEXECUTION, ARCHITECTURE and COMPILATION(MTEAC-2), 1998.[14] Subhradyuti Sarkar and Dean M. Tullsen, “Data layoutfor cache performance on a multithreaded architecture,”in Transactions on high-performance embedded architecturesand compilers III, Per Stenström, Ed., chapter Datalayout for cache performance on a multithreaded architecture,pp. 43–68. Springer-Verlag, Berlin, Heidelberg,2011.[15] Sonia López, Steve Dropsho, David H. Albonesi, OscarGarnica, and Juan Lanchares, “Dynamic capacity-speedtradeoffs in smt processor caches,” in Proceedings ofthe 2nd international conference on High performanceembedded architectures and compilers, Berlin, Heidelberg,2007, HiPEAC’07, pp. 136–150, Springer-Verlag.[16] Sonia Lopez, Oscar Garnica, David H. Albonesi, StevenDropsho, Juan Lanchares, and Jose I. Hidalgo, “Adaptivecache memories for smt processors,” Digital SystemsDesign, Euromicro Symposium on, vol. 0, pp. 331–338,2010.[17] Steven E. Raasch and Steven K. Reinhardt, “The impactof resource partitioning on smt processors,” in Proceedingsof the 12th International Conference on Parallel Architecturesand Compilation Techniques, Washington, DC,USA, 2003, PACT ’03, pp. 15–, IEEE Computer Society.[18] Michael Van Biesbrouck, Lieven Eeckhout, and BradCalder, “Representative multiprogram workloads for multithreadedprocessor simulation,” in IEEE WorkloadCharacterization Symposium. September 2007, pp. 193–203, IEEE Computer Society.[19] F.J. Cazorla, A. Pajuelo, O.J. Santana, E. Fernandez,and M. Valero, “On the problem of evaluating the performanceof multiprogrammed workloads,” IEEE Trans. onComputers, vol. 59, no. 12, pp. 1722 –1728, 2010.[20] Greg Hamerly, Erez Perelman, Jeremy Lau, and BradCalder, “Simpoint 3.0: Faster and more flexible programanalysis,” in Proceedings of Workshop on Modeling,Benchmarking and Simulation, 2005.[21] Thomas F. Wenisch, Roland E. Wunderlich, Michael Ferdman,Anastassia Ailamaki, Babak Falsafi, and James C.Hoe, “Simflex: Statistical sampling of computer systemsimulation,” IEEE Micro, vol. 26, pp. 18–31, July 2006.[22] Raj Jain, The Art of Computer Systems PerformanceAnalysis: Techniques for Experimental Design, Measurement,Simulation, and Modeling, John Wiley & Sons,Inc., April 1991.[23] Ron Gabor, Shlomo Weiss, and Avi Mendelson, “Fairnessand throughput in switch on event multithreading,” inProceedings of the 39th Annual IEEE/ACM InternationalSymposium on Microarchitecture, Washington, DC, USA,2006, MICRO 39, pp. 149–160, IEEE Computer Society.[24] S. Eyerman and L. Eeckhout, “System-level performancemetrics for multiprogram workloads,” Micro, IEEE, vol.28, no. 3, pp. 42 –53, may. 2008.[25] M. Ekman and P. Stenstrom, “Enhancing multiprocessorarchitecture simulation speed using matched-pair comparison,”in Proceedings of the IEEE International Symposiumon Performance Analysis of Systems and Software,2005, Washington, DC, USA, 2005, pp. 89–99, IEEEComputer Society.[26] Todd Austin and Doug Burger, SimpleScalar Tutorial(for tool set release 2.0), SimpleScalar LCC, 1997.[27] Glenn Hinton, Dave Sager, Mike Upton, Darrell Boggs,Doug Carmean, Alan Kyker, and Patrice Roussel, “Themicroarchitecture of the Pentium R○ 4 processor,” IntelTechnology Journal, vol. 1st quarter, pp. 1–13, 2001.[28] Dean M. Tullsen, Susan J. Eggers, Joel S. Emer, Henry M.Levy, Jack L. Lo, and Rebecca L. Stamm, “Exploitingchoice: instruction fetch and issue on an implementablesimultaneous multithreading processor,” in Proceedings.23nd Annual International Symposium on Computer Architecture,New York, NY, USA, 1996, vol. 24, pp. 191–202, ACM.[29] John L. Henning, “Spec cpu2006 benchmark descriptions,”SIGARCH Comput. Archit. News, vol. 34, no. 4, pp. 1–17,2006.JP2011-568

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Metodología para Analizar y Evaluar los Sistemasde Entrada/Salida ParalelosSandra Méndez, Dolores Rexachs y Emilio LuqueDepartamento de Arquitectura de Computadores y Sistemas OperativosUniversitat Autònoma de Barcelona, Barcelona, España{sandra.mendez,dolores.rexachs,emilio.luque}@uab.esResumen—El aumento de las unidades de procesamiento enlos clústers, los avances en velocidad y potencia de cómputo yla creciente complejidad de las aplicaciones científicas demandanmayores exigencias a los sistemas de Entrada/Salida de los computadoresparalelos. En este trabajo se propone una metodologíapara el análisis de las prestaciones de E/S en los clústers decomputadores, que permita analizar cómo afectan diferentesconfiguraciones a la aplicación. La metodología contempla lacaracterización del sistema de E/S a distintos niveles: dispositivo,sistema y aplicación; configuración de diferentes elementos quetienen impacto en las prestaciones y evaluación teniendo encuenta tanto la aplicación como la arquitectura de E/S.Index Terms—E/S Paralela, Arquitectura de E/S, Librerías deE/S, Almacenamiento MasivoI. INTRODUCCIÓNEl aumento de las unidades de procesamiento en losclústers, los avances tanto en velocidad como en potencia decómputo de las unidades de procesamiento y la creciente complejidadde las aplicaciones científicas que utilizan cómputo dealtas prestaciones demandan mayores exigencias a los sistemasde Entrada/Salida (E/S) de los computadores paralelos. En muchoscasos, debido al gap que existe entre las prestaciones delcómputo y el sistema de E/S, éste se vuelve el cuello de botellade los sistemas paralelos. Para poder ocultar el gap se debenidentificar los factores que influyen en las prestaciones. Estolleva a plantear las siguientes preguntas: ¿Las aplicacionesdeben adaptarse a la E/S? ¿El administrador debe configurarun sistema de E/S que se adapte a los requerimientos de lasaplicaciones de forma transparente? ¿Qué factores de E/S influyenen el rendimiento? ¿Cómo configurar el sistema de E/Spara adaptarse a las requisitos de las aplicaciones? Respondera estas preguntas no es trivial. Las aplicaciones se comportande forma diferente y si bien los programadores o diseñadorespueden realizar las modificaciones necesarias para realizareficientemente las operaciones de E/S, estas modificacionesson específicas para una aplicación y computador paralelo.Por otro lado, sacar mayores prestaciones al sistema de E/Srequiere que el programador conozca todos los niveles del E/S.Para utilizar eficientemente el sistema de E/S de un clústeres necesario conocer su capacidad de E/S para determinar sipuede cumplir con los requisitos que exigen las aplicacionescientíficas intensivas en E/S. Con este objetivo en mente estetrabajo presenta una metodología que permite analizar lasprestaciones del sistema de E/S centrándose en las caracteristicasde las aplicaciones científicas intensivas de E/S y en laconfiguración de la arquitectura de E/S.La metodología propuesta consta de una fase de caracterización,análisis de la configuración de E/S y evaluación de lasprestaciones. La fase de caracterización se centra en obtenerlos requisitos de E/S de la aplicación, evaluar el ancho debanda y la latencia en cada uno de los niveles implicados,sistema de fichero, red de interconexión, librería de E/S ydispositivos de E/S. En la fase de análisis de la configuraciónse identifican los factores que pueden ser configurables yque tienen impacto en las prestaciones que da el sistemade E/S, se analizan a nivel de sistema de fichero, red deinterconexión, y redundancia de datos y servicio, a partir deestos factores y los requisitos de la aplicación se puede analizary comparar las distintas configuraciones de E/S que puedenser implementadas en el clúster. Para evaluar el impacto dela configuración de E/S del clúster se evalúa el impacto enlos índices de prestaciones de la aplicación y se determinala ineficiencia analizando la diferencia con los valores picocaracterizados.Este trabajo se estructura en las siguientes secciones, los trabajosrelacionados se presentan en la sección 2, la metodologíapropuesta se presenta en la sección 3, los experimentos realizadosen la sección 4, el modelo que da soporte al proceso deanálisis se presenta en la sección 5, y finalmente, en la sección6 las conclusiones y trabajos futuros son reportados.II.TRABAJOS RELACIONADOSExisten varios estudios realizados para evaluar las prestacionesde la E/S de los computadores paralelos. La tendenciaactual es trabajar tanto en entornos reales como en entornossimulados a partir de trazas. Dado que las prestaciones delsistema de E/S depende del software y hardware estos estudiosson realizados para configuraciones de E/S de computadoresparalelos específicos. En [1] se realiza una caracterizaciónde la E/S de las aplicaciones del supercomputador Jaguarformado por máquinas CRAY, presentan una herramienta quepermite generar trazas de las operaciones de E/S para aplicacionesMPI. A partir de estas trazas se pueden identificarlas zonas que pueden ser optimizadas a nivel de E/S. En[2] se presenta un trabajo donde se da un orden al análisisque realizan, considerando los factores de número de clientes,tamaño y número de stripe. Estos estudios se realizaron sobreCRAYs para mejorar las prestaciones de su sistema de E/S. Eltrabajo presentado en [3] realiza un análisis de prestacionesJP2011-569

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Figura 2. Fase de CaracterizaciónFigura 1. Metodología para evaluar las prestaciones del sistema de E/Scentrándose en la configuración de la E/S para mostrar laeficiencia del sistema de E/S del supercomputador Red Storm,presenta un estudio de los límites teóricos de la arquitecturade E/S y realizan pruebas de prestaciones para file-per-processy shared-file a nivel de arquitectura. En [4] se describe elsimulador SIMCAN, que permite estudiar el comportamientoen ambientes distribuidos complejos con varios propósitos, ladetección de los cuellos de botellas del sistema, cálculo delgrado de escalabilidad del sistema y probar la prestaciones deaplicaciones sin usar el sistema real.En los casos anteriores el estudio se realiza sobre una arquitecturay no se consideran directamente las características dela aplicación relacionandolos con los recursos que se tendríanque asignar de acuerdo a esas necesidades. La propuesta deeste trabajo es analizar el sistema de E/S teniendo en cuentael impacto en las distintas aplicaciones.III.METODOLOGÍA PROPUESTALa metodología propuesta consta de 3 fases (figura 1): Caracterización,Análisis de la configuración de E/S y Evaluación.Las prestaciones del sistema de E/S están en función deltiempo de ejecución y el tiempo de E/S de las operacionesde E/S de la aplicación sobre una determinada configuracióndel sistema de E/S. Dado que las prestaciones pueden dependerde las características de la aplicación y del sistema de E/S, secaracteriza la aplicación y el sistema de E/S (incluyendo losdispositivos de E/S) para determinar los posibles puntos deineficiencia y además proporcionar información para buscarla configuración que mejor se adapte a los requisitos dela aplicación. Si bien en este trabajo se destaca la fase decaracterización, ésta es la base para poder determinar en unfuturo los puntos de ineficiencia.III-A. CaracterizaciónLa fase de caracterización esta destinada a obtener losfactores de la aplicación, sistema paralelo de E/S y dispositivosde E/S que brinden la información necesaria para poderrealizar la comparación entre los valores experimentales ylos caracterizados. En la figura 2 se muestra la informaciónFigura 3. Sistema de E/S del Clúster Aohyperque se obtiene en la fase de caracterización. Para explicarel proceso de caracterización se aplica la metodología parael problema del Block Tridiagonal(BT), considerando la E/S(IO), del NAS Parallel Benchmark (NAS) [5]. El sistema deE/S que se analiza corresponde al clúster de la figura 3 quepresenta las siguientes características: 8 nodos de cómputoAMD Athlon(tm) 64 X2 Dual Core Processor 3800+, memoriaRAM de 2GB y un disco de 150 GB para acceso local ysistema de fichero linux ext4; 1 servidor NFS con un RAID 1(2 discos) con capacidad=230GB y un RAID5 (3 discos) constripe=256KB y capacidad=917GB ambos con write-cacheenabled (write back); una red de comunicación y otra de datosde 1Gbps Ethernet.III-A1. Aplicación Científica: Se obtienen sus requisitosde E/S (cuadro I), se determina el tipo, cantidad y tamaño delas operaciones de E/S a nivel de librería. Esta informaciónes usada en la fase de evaluación para determinar si lasprestaciones de la aplicación están limitadas por el sistemade E/S o por la aplicación.Para realizar la caracterización de la aplicación se desar-ParametersnumF ilesnumIO readnumIO writebk readbk writenumIO seeknumIO createnumIO opennumIO closenumP rocesosCuadro ICARACTERÍSTICAS DE LA APLICACIÓNDescriptionNúmero de archivos que usa la aplicacióncantidad de operaciones readcantidad de operaciones writetamaño de bloque para readtamaño de bloque para writecantidad de operaciones seekcantidad de operaciones createcantidad de operaciones opencantidad de operaciones closenúmero de procesos en las operaciones de E/SJP2011-570

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Cuadro IICARACTERÍSTICAS DE NAS BT-IOParámetros MPI POSIXnumF iles 1 1numIO read 640 320 y 320numIO write 640 320 y 320bk read 10 MB 4MB y 16MBbk write 10 MB 4MB y 16MBnumIO seek 0 638numIO create 0 1numIO open 32 32numIO close 32 32numP rocesos 16 16Figura 4. Caracterización del Sistema de E/Srolló una extensión del trazador de la herramienta PAS2P[6] para obtener información de E/S a nivel de proceso.Para obtener los patrones de acceso de la aplicación y lasoperaciones a nivel de POSIX I/O se utiliza la herramientaDARSHAN [7]. En el cuadro II se muestra la caracterizaciónrealizada para NAS BT-IO para la clase C en el subtipo full.III-A2. Sistema Paralelo de E/S: El sistema paralelo escaracterizado a nivel de librería de E/S y sistema de ficheros(local, distribuido o paralelo).Se caracterizan los bandwidth e IOPs en cada uno de losniveles, como se puede observar en figura 4. Para los sistemasde ficheros se pueden utilizar los benchmarks IOzone [8] y/obonnie++ [9] y para las librerías se puede utilizar b eff io[10] o IOR [11].La caracterización del sistema paralelo y los dispositivos dealmacenamiento se hicieron con IOzone (cuadro III). En estecaso el factor limitante para el ancho de banda va a ser lalibrería de E/S.Las operaciones se realizaron sobre un archivo del doblede tamaño que la memoria de los nodos de cómputo y de lamemoria del nodo de E/S variando los tamaños de bloques de32KB a 16MB. Para la librería de E/S se uso IOR configuradopara 8 segmentos con tamaños de bloques de 16MB a 128MBy para tamaños de transferencia de 32 a 256 KB para 8Cuadro IIISISTEMA DE E/S DE AOHYPERMedida en MB/seg read write read write read writehome home raid1 raid1 raid5 raid5Librería de E/S 27 48 28 48 29 48Filesystem Local 68 85 133 113 273 193Filesystem Distribuido 47 50 48 50 47 50Cuadro IVRED DE INTERCONEXIÓN PARA EL CLUSTER AOHYPERTamaño de PaqueteDatos(ms) Com(ms)64 a 1024 bytes 0.16 0.262048 bytes 0.26 0.284096 bytes 0.36 0.328192 bytes 0.56 0.4816384 bytes 0.99 0.5432768 bytes 1.82 0.9165515 bytes 3.55 1.58y 16 procesos. En el caso de la red de interconexión seusaron simples medidas a través del comando de sistema pingvariando el tamaño del paquete −s y −c cantidad de paquetesy tomando valores medios. Las pruebas se realizaron desde losnodos de cómputo al nodo de E/S para la red de comunicacióny para la de datos (IV).III-B.Análisis de la Configuración de E/SPara hacer un análisis del impacto de la configuración en eltiempo de E/S se evaluan los componentes que se presentanen la figura 4. Por lo general, el usuario no conoce en detalleel sistema de E/S, confía que el sistema paralelo procesesus solicitudes de E/S y después espera recuperar los datosprocesados cuando lo requiera. En este trabajo se plantea queuna aplicación puede usar de diferentes formas el conjunto derecursos de la configuración existente, en función de los recursosutilizados se crea lo que llamamos una subconfiguración,donde se han dado valores determinados a distintos parámetrosdel sistema, y que tienen impacto en las prestaciones y serándiferente en cada subconjunto. Por lo tanto, se debería poderasignar a la aplicación aquella subconfiguración más eficiente.III-B1. Identificación de Factores de E/S configurables:Se analizan las capas de librería de E/S y arquitectura deE/S. El cluster Aohyper tiene como filesystem local ext4 yun servidor NFS para datos compartidos. En cuanto a la redde interconexión se identifican el número y tipo de red deinterconexión que tiene el cluster. Si existen más de una redse pueder elegir con cuales trabajar por medio de las libreríasde paso de mensaje.Otra aspecto que se puede considerar es la selección delnivel de redundancia. De acuerdo al nivel de protección anteslos fallos de los dispositivos de E/S se puede elegir un RAID 1,RAID 5 u otro nivel. Esto implica el uso de recursos extras ydependiendo de los patrones de accesos de las aplicaciones, laredundancia puede penalizar las prestaciones que la aplicaciónpercibe.III-B2. Selección de subconfiguraciones de E/S: Una vezevaluados estos parámetros se puede seleccionar un conjuntode subconfiguraciones del cluster y evaluar las prestacionesque ofrecen a la aplicación. En el ejemplo se realiza el análisisutilizando 3 subconfiguraciones: un sistema de E/S sin RAID(llamada NFS en la figura 6), uno con RAID 1 y otro conRAID5, se han realizado pruebas haciendo otra selecciónde recursos, por ejemplo utilizando 1 ó 2 redes, diferentesconfiguraciones de RAID SW sobre los discos locales, peropara el ejemplo se describe el comportamiento utilizando 3subconfiguraciones.JP2011-571

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Figura 5. Fase de EvaluaciónIII-C.EvaluaciónUna vez completadas las fases de Caracterización y Análisisde la configuración de E/S se debe probar la aplicación sobrecada subconfiguración. En la figura 5 se muestran los pasosconsiderados para hacer la evaluación.III-C1. Configuración del Entorno de Evaluación: Lapreparación del entorno de evaluación implica establecer losparámetros para: aplicación científica, librerías de E/S y arquitecturade E/S. Para nuestro ejemplo, la aplicación elegidaes NAS BT-IO en su clase C, la librería MPI es MPICH y serealizará la prueba sobre las 3 subconfiguraciones.III-C2. Índices de E/S Paralela: Los índices consideradospara la fase de evaluación son tiempo de ejecución (duraciónde la ejecución de la aplicación), tiempo de E/S (tiempo quelleva hacer las operaciones de lectura y de escritura), IOPs(Cantidad de operaciones de E/S por segundo) y el throughput(cantidad de Megabytes transferidos por segundos para lasoperaciones de E/S).III-C3. Análisis de la relación factores e índices de E/S:Los IOPs y el throughput se comparán con los valoresobtenidos en la etapa de caracterización. Si las prestacionesque la aplicación obtiene son próximos a algunos de los elementosdel conjunto A = {bw lib , bw mpi , bw fs , bw net , bw disk }será necesario analizar las características de ese componentedel sistema de E/S porque puede estar limitando las prestacionespara la aplicación. Para el ejemplo de NAS BT-IO, en lafigura 6 se puede ver los tiempos de E/S, tiempos de ejecucióny las tasa de transferencia que la aplicación percibe para 16procesos para la clase C para las 3 subconfiguraciones. Elanálisis es realizado para el subtipo full (con colectivas de E/S)y simple (sin colectivas). En la figura 6(a), tiempo expresadoen minutos, se observa una tasa de transferencia baja, laaplicación esta usando el 50 % de la tasa de transferenciaproporcionada por la librería de E/S que es el valor más bajoen el sistema de E/S. Esto se debe a que la aplicación realiza4.199.040 writes y 4.199.040 reads con tamaño de bloque de1600 bytes y 1640 bytes. Lo que reporta una penalizaciónmuy elevada por las solicitudes de read y write (expresadasen minutos). En la figura 6(b), tiempo expresado en segundos,muestra el subtipo full donde las solicitudes son realizadasen forma colectiva. Para tamaños de write y read de 10MB sealcanza una tasa de transferencia de 50 MB/seg, el 100 % de latasa de transferencia que se obtiene como pico en el filesystemdistribuido. Otro aspecto que se ha detectado en la fase de(a) Tiempos NAS BT-IO sin colectivas de E/S(b) Tiempos NAS BT-IO con colectivas de E/SFigura 6. Resultados Experimentales para NAS BT-IOCuadro VSISTEMA DE E/S DEL CLUSTER BMedida en MB/seg read writeraid5 raid5Librería de E/S 32 51Filesystem Local 260 200Filesystem Distribuido 89 79caracterización es la velocidad de las redes de interconexión yse observa como la red de datos baja las prestaciones cuandoel tamaño de paquete se incrementa, también se observó queun nodo de cómputo esta trabajando al 25 % de velocidad conrespecto a los otros. El proceso de caracterización permite vervarios aspectos del sistema E/S que afectan las prestacionesdel sistema y permite determinar que recursos se asignan parareducir las penalizaciones.IV.EXPERIMENTACIÓNPara evaluar la metodología se realizó una evaluación delNAS BT-IO en un clúster diferente, que denominamos clústerA compuesto por 32 nodos de cómputo: 2 x Dual-Core Intel(R)Xeon(R) 3.00GHz, 12 GB de RAM , disco 160GB SATA yDual Gigabit Ethernet. Un nodo front-end que hace de servidorNFS: Dual-Core Intel(R) Xeon(R) 2.66GHz, 8 GB de RAM,RAID 5 de 1.8 TB y Dual Gigabit Ethernet. La caracterizacióndel sistema de E/S del clúster A se presenta en el cuadro V.La prueba realizada con IOR para evaluar la librería de E/S espara 8 segmentos, tamaño de bloque de 256MB y un tamañode transferencia de 256KB.En la figura 7 se muestra las prestaciones para el benchmarkNAS BT-IO para un número variable de procesos. Para elJP2011-572

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Tiempos NAS BT-IO sin colectivas de E/SParámetrosBW readBW writetime opentime closenumF ilesnumIO readnumIO writebk readbk writenumIO opennumIO closek r, k w, k o, k cCuadro VIPARÁMETROS DEL MODELO DE E/S DE LA APLICACIÓNDescripciónbandwidth para read en el sistema de E/Sbandwidth para read en el sistema de E/Stiempo para open en el sistema de E/Stiempo para close en el sistema de E/SNúmero de archivos que usa la aplicacióncantidad de operaciones readcantidad de operaciones writetamaño de bloque para readtamaño de bloque para writecantidad de operaciones opencantidad de operaciones closefactor para ajustar el modelo (a determinar)T execution = T compute + T io (1)(b) Tiempos NAS BT-IO con colectivas deE/SFigura 7. Tiempos de ejecución, tiempo de E/S y tasa de transferencia.subtipo simple del NAS BT-IO (figura 7(a)) para 16 procesosen el clúster A, la aplicación tiene una tasa de transferenciade 1.2 MB/seg, este valor es el 2 % para write y 4 % pararead del pico que entrega el sistema para la librería de E/S.En la figura 7(b) el subtipo full logra pasar la barrera de lalibrería de E/S con una tasa de transferencia de 45MB/segque es el 90 % para write y 140 % para read. Los cuadros deprestaciones para el Clúster A (cuadro V) y Aohyper (cuadroIII para RAID 5) muestran que el clúster A tiene mayoresprestaciones para la librería y el filesystem distribuido. Sinembargo, el NAS BT-IO en el subtipo simple tiene mejoresprestaciones en el clúster Aohyper. Pero el subtipo full tienesimilares prestaciones en ambos clústers. Del análisis realizadose puede observar que el menor tiempo de E/S se logra con unatasa de transferencia de 54MB/seg. En ambos clúster esta es latasa de transferencia que consume NAS BT-IO para hacer lasoperaciones de E/S para la clase C. De aquí también podemosobservar que Aohyper es mejor para aquellas aplicaciones quetengan un patrón de acceso similar a NAS BT-IO simple.V. MODELO DE E/S DE LA APLICACIÓNPara dar soporte a este proceso de Evaluación del sistemade E/S y al diseño de subconfiguraciones (para responder apreguntas del tipo ¿qué pasaría si se cambia un parámetrode la configuración?) se esta elaborando un modelo de E/Sque permita ayudar a buscar la configuración más eficientepara la aplicación. Para esto se expresa el tiempo de E/S dela aplicación en función de los valores caracterizados en lametodología de evaluación. A continuación se presenta unmodelo preliminar de E/S para una aplicación con un proceso.Para realizar el estudio de la E/S de un aplicación científicase hizo un análisis similar al que se hace para el cómputo. Seplantea un modelo de la E/S para una aplicación con 1 procesoy después se extenderá el modelo para n procesos. El tiempode ejecución de una aplicación se puede expresar como en laecuación 1.Las primeras preguntas que se plantean son ¿Cuanto impactael tiempo de E/S a las prestaciones de la aplicación? ¿Laaplicación usa eficientemente el sistema de E/S? ¿El sistemade E/S es eficiente para una aplicación determinada? Pararesponder estas preguntas se hace un estudio de la E/S de laaplicación. Se expresan los requisitos de E/S en un modeloque permita determinar las prestaciones que la aplicaciónpercibirá en función de los valores obtenido durante la etapade caracterización. Para esto se expresa el tiempo de E/S de laaplicación en función de los requisitos de E/S y BW obtenidosen el camino de E/S. Este modelo se plantea primero para unproceso para después extenderlo a n procesos. Se consideranlas operaciones read, write, open y close. El tiempo de E/Spara una aplicación con un solo proceso se presenta en laecuación 2.T io = T open + T read + T write + T close (2)Debido a que los tiempos más influyentes durante la ejecuciónen aplicaciones limitadas por la E/S son las reads (ecuación3) y writes (ecuación 4), el estudio se centra en estos tiempos.El significado de cada parámetro se presenta en el cuadroVI.Para cada configuración se aplica el modelo para BW min =mín(A) donde A = {bw lib , bw mpi , bw fs , bw net , bw disk }.T read = numIO read ∗ ( bk readBW read) + k r (3)T write = numIO write ∗ ( bkwriteBW write) + k r (4)El tiempo de E/S esperado en una configuración para lecturay escritura se muestra en las ecuaciones 5 y 6.bk readT read = numIO read ∗ () + kr (5)BW read (Cn)T write = numIO write ∗ (bk writeBW write(Cn)) + kr (6)donde BW read (Cn) y BW write (Cn) son los valores observadosdurante la fase de caracterización para la configuración n.La configuración que menor T io proporcione será consideradaJP2011-573

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Figura 9. Error RelativoFigura 8. Comparación Modelo de E/S y experimentosla más eficiente para la aplicación. Se define el error absolutoerror abs = |¯x − x| y relativo error rel = 100 ∗ ( error absx) paradeterminar la desviación con respecto a las prestaciones reales.Donde, ¯x son valores para T write y T read en el modelo de E/Sde la aplicación y x son medidas obtenidas en los experimentospara cada configuración de E/S.El modelo se evaluó para una aplicación sintética intensivade E/S que realiza 4000 write y 3985 read para diferentestamaños de bloques que van desde 1024 KB hasta 8192 KBgenerando de archivos de 4 GB a 32 GB. La aplicación trabajasobre un archivo en el que escribe en forma secuencial. Laúnica parte de cómputo que realiza es una suma de matrices.La evaluación se hizo para el Clúster Aohyper (cuadro III) sinRAID, con RAID1 y con RAID5. En la figura 8 se muestra eluso del modelo con los valores de la caracterización para cadaconfiguración y valores observados en la experimentación. Elmodelo debe determinar, sin ejecutar la aplicación en cadasubconfiguración, la subconfiguración más eficiente para laaplicación. El estudio se centra en el comportamiento de laaplicación. En la figura 9 se pude observar los errores relativosy se observa como se reduce cuando el tamaño archivo seincrementa.Como se esperaba esta aplicación tiene mejores prestacionesen RAID5 (figura 8). Pero el error esta entre el 10 % y 60 %.Esto indica que se debe refinar el modelo para considerarque factores estan influyendo en la prestaciones y no se estánconsiderando.VI.CONCLUSIÓNSe ha propuesto una metodología para el análisis de prestacionesde E/S para computadores paralelos que ha permitidoestablecer pautas para el análisis, identificación de factoresconfigurables y evaluar las prestaciones para diferentes configuraciones.La metodología contempla la caracterización delsistema de E/S a distintos niveles: dispositivo, sistema yaplicación; análisis de la configuración de diferentes elementosque tienen impacto en las prestaciones y evaluación teniendoen cuenta tanto la aplicación como la arquitectura de E/S. Estametodología se aplicó en dos clústers para el benchmark NASBT-IO. Se evalúo las características de ambos sistemas de E/Sy se pudo determinar como influyen en las prestaciones quela aplicación percibe. Por otro lado, se presenta un modelopreliminar para la E/S de una aplicación. Este modelo estaen función de las características de la aplicación y el sistemade E/S que se realiza en la metodología de evaluación. Estemodelo se está elaborando para determinar que configuraciónde E/S cumple con los requisitos de eficiencia del usuario,teniendo en cuenta el comportamiento de E/S de la aplicaciónen un sistema determinado.AGRADECIMIENTOSEste trabajo ha sido subvencionado por MICINN-Españaproyecto TIN 2007-64974REFERENCIAS[1] P. C. Roth, “Characterizing the i/o behavior of scientific applications onthe cray xt,” in PDSW ’07: Procs of the 2nd int. workshop on Petascaledata storage. USA: ACM, 2007, pp. 50–55.[2] M. Fahey, J. Larkin, and J. Adams, “I/o performance on a massivelyparallel cray xt3/xt4,” in Parallel and Distributed Procs, 2008. IPDPS2008. IEEE Int. Symp. on, 14-18 2008, pp. 1 –12.[3] J. H. Laros et al., “Red storm io performance analysis,” in CLUSTER’07: Procs of the 2007 IEEE Int. Conf. on Cluster Computing. USA:IEEE Computer Society, 2007, pp. 50–57.[4] A. Núnez, et al., “Simcan: a simulator framework for computer architecturesand storage networks,” in Simutools ’08: Procs of the 1st Int.Conf. on Simulation tools and techniques for communications, networksand systems & workshops. Belgium: ICST, 2008, pp. 1–8.[5] P. Wong and R. F. V. D. Wijngaart, “Nas parallel benchmarks i/o version2.4,” Computer Sciences Corporation, NASA Advanced Supercomputing(NAS) Division, Tech. Rep., 2003.[6] A. Wong, D. Rexachs, and E. Luque, “Extraction of parallel applicationsignatures for performance prediction,” in HPCC, 2010 12th IEEE Int.Conf. on, sept. 2010, pp. 223 –230.[7] P. Carns et al., “24/7 characterization of petascale i/o workloads,” inCluster Computing and Workshops, 2009. CLUSTER ’09. IEEE Int.Conf. on, 31 2009-sept. 4 2009, pp. 1 –10.[8] W. D. Norcott, “Iozone filesystem benchmark,” Tech. Rep., 2006.[Online]. Available: http://www.iozone.org/[9] R. Coker, “Bonnie++ filesystem benchmark,” Tech. Rep., 2001.[Online]. Available: http://www.coker.com.au/bonnie++/[10] R. Rabenseifner and A. E. Koniges, “Effective file-i/o bandwidth benchmark,”in Euro-Par ’00: Procs from the 6th Int. Euro-Par Conference onParallel Procs. London, UK: Springer-Verlag, 2000, pp. 1273–1283.[11] . S. J. Shan, Hongzhang, “Using ior to analyze the i/o performance forhpc platforms,” LBNL Paper LBNL-62647, Tech. Rep., 2007. [Online].Available: www.osti.gov/bridge/servlets/purl/923356-15FxGK/JP2011-574

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Memory Hierarchy and Network Co-designthrough Trace-Driven SimulationMario Lodde 1 , José Flich 1Abstract— CMP systems are usually designed andevaluated through simulation tools. The NoC and thecache memory architecture are two key componentsthat tightly interact; changing parameters of one ofthese components affect the performances of the otherone, so they should be modeled and tuned consideringhow they interact. In this paper we propose gMem-NoCsim, a simulation platform which allows to modelboth the NoC and the cache hierarchy and rapidlyrun trace-driven simulations.Keywords— CMP, NoC, cache memory, coherenceprotocols, simulationI. IntroductionAS VLSI technology advances an increasing numberof transistors can be be integrated into thesame chip. Instead of building powerful and complexprocessors, designers have shifted to multicoredesigns where several and simpler cores are includedinto the same chip. The main reason for this shiftis the power dissipation and energy consumption ofcomplex processors. In these chip multiprocessorsystems (CMPs) each simpler processor core usuallyhas its own cache memory hierarchy. Additionally,one or more memory controllers are included in thechip to manage off-chip accesses. All these componentsare interconnected through an on-chip built-innetwork, referred to as network-on-chip (NoC)[1][2].The NoC has to provide a very large bandwidth andultra low latencies to avoid introducing a bottleneckin inter-processor communications.A tile-based design is appealing when designing aCMP system. An elemental block or tile is designedand replicated all over the same die, forming a tilematrix. Each tile includes one or more cores, a subsetof their cache memories, a network interface and aswitch that interconnects the tiles through a networkof point-to-point links, typically a 2D mesh. The tilebaseddesign provides scalability and reduces designtime and design and verification costs since a singletile is designed instead of the whole chip. Figure1 shows a possible CMP design with 16 tiles, eachone with one core, two separate private L1 caches, ashared L2 cache bank, and a switch. Two memorycontrollers are attached to two of the tiles at thecorners of the chip.Most current CMP systems support a sharedmemoryprogramming model where main memoryis seen by all the processors. This model is simplerand convenient to programmers as communicationbetween processors is implicitly performed by shar-1 Dpto. de Informática de Sistemas y Computadores, UniversitatPolitecnica de Valencia, e-mail: mlodde@gap.upv.es,jflich@disca.upv.es.ing variables between processes. A coherence protocolneeds to be designed and implemented to keepcoherency between multiple copies of the same memoryblock spread over the caches in the chip. On theother hand, in the message-passing model the programmerexplicitly needs to care about sending messagesbetween processors, and a coherence protocoldoes not need to be implemented.The design of the coherence protocol is key for thescalability of the CMP design. Indeed, the protocolneeds to be scalable to allow building larger systems,specially in a tiled CMP design. As technologyadvances it is appealing to use the same tile-baseddesign and simply increase performance by addingmore tiles to the chip. Scalability of the coherenceprotocol should come in terms of keeping memoryaccess latency, area implementation cost, and powerconsumption. Indeed, the increased memory accesslatency of the coherence protocol (due to indirection)and the area overhead (to keep the coherence info)are seen as the major issues that may prevent sharedmemoryCMP systems from scaling to hundred corenodes.In a shared-memory CMP chip most of the trafficthrough the NoC comes from the cache coherenceprotocol. The network must service packetssent between caches and to/from memory controllers.Therefore, the coherence protocol influences the waythe NoC has to be designed. A proper NoC designshould minimize the impact of message deliveringto the protocol (reduced access latencies andenough data bandwidth) while optimizing its design(low area and power consumption costs). In otherwords, the NoC design should be driven by the coherenceprotocol design. On the other hand, thenetwork may influence the way the coherence protocolis implemented. As an example, the access tothe memory controllers and the access to L2 cachebanks can be influenced by the topology chosen tointerconnect the tiles. Indeed, both the network andthe coherence protocol should be co-designed.II. MotivationSimulation is usually the preferred method for performanceexploration when designing different CMPcomponents (including the coherence protocol andthe NoC). With simulations, accurate models canbe built and performance metrics can be extracted(e.g. network throughput and access latency for theNoC and average memory access and total executiontime for the coherence protocol). Many differentsimulation platforms are being used by the community,most of them handcrafted and specialized inJP2011-575

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.Tile-based CMP design with 16 tiles on a 4 × 4 mesh configuration.a particular CMP component. Usually, the NoC ismodeled in isolation without considering the coherenceprotocol. Synthetic traffic patterns or messagetraces captured from higher-level system models aretypically used. These methods do not take into accountthe implications of the memory hierarchy onthe on-chip network. Vice-versa, different coherenceprotocol analysis take into consideration a given andstatic on-chip network configuration, thus not benefitingfrom the real potential impact of co-designingboth components.A proper CMP simulation model should detail thememory hierarchy of the CMP system: the numberand organization of cache banks of on-chip cache,their access latency, and the cache coherence protocolused to ensure data consistency. At the same timethe simulation platform should model the on-chip interconnectionnetwork, which should be co-designed,co-simulated and evaluated together with the memoryhierarchy system. Indeed, their behavior andperformance are tightly coupled.There are different simulation platforms that enablemodeling both components. One such widelyused platform is SIMICS/GEMS [3][4], which is commonlyused to model and evaluate the memory hierarchy.SIMICS/GEMS models the entire CMP systemincluding the Operating System (OS), the application/benchmarkbeing run, the CMP hardware resourcesand even the on-chip network (via the GAR-NET network simulator [5]). With this environment,however, simulation overhead is prohibitively largeand simulation experiments take from hours to weeksdepending on the simulation benchmark analyzed.Indeed, various benchmark suites have been releasedto the community to evaluate the performanceof multiprocessor and CMP systems, such as Splash-2 [6] or PARSEC [7]. These benchmarks include differentapplications and kernels that are representativeof common real applications of multiprocessorsystems, being appealing for a proper evaluation ofCMPs. Indeed, these benchmarks are available forGEMS/SIMICS and are commonly used.However, synthetic patterns still pose an interestingflavor, as their use permit a rapid exploration ofthe component being analyzed. Indeed, by meansof synthetic traffic patterns on-chip networks can beanalyzed in a wide range of load conditions, evenif the final application will not demand such loads.In some way, the system is evaluated in the fullrange of possible higher-level demands. Uniformtraffic distributions together with specific patternslike bit-complement, tornado, or hot-spot traffic patternsare the mostly used ones in the on-chip community.Some of them have been acknowledged torepresent well-known and representative applicationtraffic patterns. However, still, such traffic patternsdo not take into account the memory hierarchy.When considering the memory hierarchy, a largenumber of parameters may influence the final systemperformance. Those memory parameters, togetherwith the on-chip network parameters, mustbe fine-tuned to better understand how they affectthe system performance. Complete and accurate designspace exploration with full-system simulationlike GEMS/SIMICS becomes unfeasible and unpracticaldue to its large simulation time. Furthermore,exploration of large CMP systems (beyond 64 cores)is nowadays out of reach of these simulation platforms(memory requirements and exponential simulationtime).In this paper we propose gMemNoCsim, a tracedrivensimulation approach which includes both theon-chip network model as well the memory hierarchysystem (including different layers of caches, and anyconfiguration of memory controllers). Input memoryreferences (e.g. load and stores) instead of messagereferences are taken as an input for the simulator.Memory traces are obtained from real applications(SPLASH-2) and synthetic memory access patternsare defined as well, which allow a rapid performanceexploration of both the memory hierarchy (with thecoherence protocol) and the on-chip network.With gMemNoCsim any critical parameter of boththe network and the memory hierarchy can be specifiedby the user. Whenever a memory access is readby the simulator, the required coherence actions areperformed possibly injecting messages into the onchipnetwork. The behavior of the coherence proto-JP2011-576

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011col is defined by the proper FSM easily described interms of states, events and actions to be performed.Thus, different coherence protocols can easily be defined.The rest of the paper is organized as follows.In Section III the simulation platform is described.Then, in Section IV we show some examples of theresults obtained with the platform for different networkand memory hierarchy configurations. Finally,Section V concludes the paper.III. Simulation Platform DescriptionA. Overall Platform OrganizationFigure 2 shows the overall gMemNoCsim platformorganization. Two main layers exist and communicatewith each other. The memory layer which modelsthe memory hierarchy (cache structures and thecoherency protocol) and the on-chip network layerwhich models the on-chip network.Fig. 2.Overall simulation platform organizationThe trace files are the input of the simulator (readby the memory layer). A trace file is used per eachmodeled core in the CMP system (to keep processorindependence). Trace files are independent of eachother, although memory access dependencies can beadded between load and store operations of differentprocessors (described later). Whenever a trace entryis read, the memory layer performs the coherence actionsspecified in the protocol configuration file whichdescribes the cache coherence protocol. The memorylayer may issue one or several packets into thenetwork (e.g. an L1 miss triggering an access to aremote L2 cache bank), thus, communicating withthe network layer. This layer, in turn, simulates cycleby cycle as the packet crosses the network. Whenthe packet reaches its destination the network layertriggers an event at the memory layer. Then, thememory layer evolves as specified by the cache coherenceprotocol.The memory model blocks the processor on eachload and store operation (in-order processors are assumed).Also, a processor is blocked if the load operationhas an input dependency with a store operation(included in the trace). The load will progress oncethe store operation is performed. Whenever a memoryaccess is performed by a processor, the processoris unblocked and the next memory access is readfrom the trace. The simulation ends when there areno more traces to read and all the cores have receivedthe data they requested.The simulator is cycle accurate and both layersadvance at the same pace, cycle by cycle. Table Isummarizes the current parameters the simulationplatform supports in the definition of the memoryand network models.B. Memory Access TracesMemory access traces are defined per each processorand follow a simple format. A trace file is madeof memory access entries, with one access per entry.Each entry defines the following fields:• Memory address. The global memory address ofthe access.• Type of access. Either load, store, or fetch operation.• Time. Represents the amount of time the processorperforms internal operations between theprevious memory access and the current one.• Output dependency. Allows to define an outputdependency between a store operation anda load operation. A value of -1 means no outputdependency.• Input dependency. Allows to define an input dependencybetween a load operation and a storeoperation. A value of -1 means no input dependency.• Number of output dependencies. Indicates howmany processors will have a dependency withthis access.Memory dependencies allow keeping the originalflow of the application. For instance, synchronizationbarriers and spin lock operations can easily be modeledwith memory dependencies. Figure 3 shows anexample of a barrier synchronization by several processors.The figure shows the definition of the tracefile for each processor (address field is omitted).Fig. 3.Traces describing a barrier synchronizationMemory access traces can easily be obtained fromreal applications. Indeed, SIMICS/GEMS can beused to output all the memory references of a givenapplication under the assumption of an ideal memoryand network model. Memory dependencies can easilyJP2011-577

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Memory parametersNetwork parametersParameter Values Parameter ValuesCoherence protocol Invalidation-based Topology tipe mesh, ring, customL1 and L2 sets any Packet size anyL1 and L2 ways any Flit size anyL1 and L2 cache latency any Flow control stop&go, VCTlite, credits, mixedL1 and L2 tag latency any Virtual networks anyVirtual channelsanyBroadcast supportY/NRouting typeXY, lbdrTABLE IMemory and network parameters supported in gMemNoCsim.be obtained by inspecting the final file and matchingreferences to the same address. This, however, isleft for future work. In addition, synthetic memoryaccess traces can easily be obtained, enabling theevaluation of different coherence protocols in wellknownmemory access patterns. Figure 4 shows anexample of memory traces for a migratory sharingpattern (an address is updated sequentially by a setof processors).4-stage switch. Flit size is set to four bytes. Aninvalidation-based coherence protocol is modeled.Figure 5 shows the average execution time whenthe number and location of memory controllers inthe chip are varied. Memory controllers are locatedat the corners of the chip except for the 4mc centercase where is placed at the center of each 2×2 quadrantin the chip. As can be noticed, the location andthe number of memory controllers does not pay anexcessive overhead. We have a modest reduction inexecution time of 3% when moving from one memorycontroller in a corner to four memory controllersspread through the chip.Fig. 4.Traces describing a migratory sharing patternIV. A Brief Evaluation Experience withgMemNoCsimIn this section we provide the results for a briefexploration of parameter definitions for a CMP system.The gMemNoCsim simulation platform is usedin both synthetic memory access patterns and tracesobtained from SPLASH-2 applications. Two syntheticpatterns are evaluated. In the first one eachprocessor issues a random memory access every 10cycles, whereas in the second one the memory accessesare performed on every cycle (stress scenario).In both cases, 70% of the accesses are loads andfetches. For the applications we get the traces for fft,lu, raytrace, volrend, watersp, barnes, fmm, ocean,and radiosity. We provide average results for all thesescenarios in a set of configurations described next.The default configuration is a 2D mesh with 16 tiles,each with two private 64KB L1 caches (instructionsand data), a shared 512KB L2 bank, and a pipelinedFig. 5. Average execution time for different number and locationof memory controllers. Flit size is 4 bytes. Onevirtual channel.The previous result has been achieved with flitsize set to 4 bytes and with no virtual channel supportat switches. In Figure 6 we can see the resultswhen the number of virtual channels available is upgradedto four. Now, the average execution time isslightly reduced by 5%. We can conclude that thenumber of virtual channels and the number of memorycontrollers help in the same direction alleviatingthe network. Maximum performance improvement isachieved with four memory controllers and with fourvirtual channels but not representing a large benefit.Now, in Figure 7 we can see the impact of theflit size on execution time. This time we can see alarge impact as execution time is reduced by almost20% on average when flit is widened to 32 bytes.Indeed, same results are obtained for 64-byte flits.In those cases the network latency is highly reduced(and also the contention within the network) thusJP2011-578

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 6. Average execution time for different number of memorycontrollers. Flit size is 4 bytes. Four virtual channels.slower cache configurations. Execution time is impactedwhen caches are 4X time slower than the defaultcase (6% performance degradation). With evenslower caches we detect a 15% performance degradation.The cache size, however, does not impact muchon execution time. Indeed, the size of the L1 cacheis more important than the size of the L2 cache. Onaverage, performance is degraded by 4% when usingsmaller L1s and 2% when using L2s. The combinedeffect raises 8% performance degradation.reducing execution time. From this figure we candeduce that the flit size is a major design parameterfor the CMP system.Fig. 9. Average execution time for different cache configurations.One memory controller. One virtual channel.4-byte flit size.Fig. 7. Average execution time for different flit sizes. Onememory controller. One virtual channel.Next, in Figure 8 we can see the performanceachieved when different topologies when different flitsizes are used. In particular, the 2D mesh (case 1mc),rings and concentrated meshes (four cores attachedto the same switch) are evaluated. We can see howthe limited bandwidth of the ring impacts on executiontime by almost 20% overhead. However, thering can obtain good results (no performance overhead)if the flit size is tuned to 8 bytes. Thus, weget similar performance when comparing a 4-byte flit2D mesh with a 8-byte flit ring. Also, we can noticehow the lower average hop count of the concentratedmesh helps in reducing execution time by 4% andfurther attain 20% performance improvement withmoderate flit sizes (8-byte flits).Fig. 8. Average execution time for different topologies andflit sizes. One memory controller. One virtual channel.Finally, Figure 9 shows the impact on executiontime of a different configuration in the L1/L2 cachememories. In particular, we use smaller and/orA. A Coherence Protocol Analysis ExampleAs a final example, we provide here a first evaluationof a cache coherence protocol design analysis.In particular, the migratory sharing pattern of somevariables can be efficiently tracked by the coherenceprotocol with a minor modification. In a migratorysharing pattern processors read and write a sharedvariable in a sequential order [8]. In an standard coherenceprotocol the variable is shared between theprocessor that wrote the variable and the processorthat now has a miss read. This is unneficient asthe processor will write the variable that is in sharedmode, thus, will need exclusive ownership before performingthe write. In contrast, the coherency protocolcan be modified in order to detect the migratorysharing pattern. Upon a read miss, the coherenceprotocol reassigns ownership of the memory block.The copy in the L1 of the former producer is invalidatedand exclusive ownership is provided to the newsharer. Thus, when performing the write no coherenceactions will be required. Figure 11 shows themain coherence protocol changes performed to supportmigratory sharing. Normally incoming read requestfor a private block are forwarded to the ownerL1 cache, and the block becomes shared, as in Figure10. When the L2 detects a migratory sharing pattern,an incoming read request is forwarded to theowner as a write request: the current owner will invalidateand send the block with exclusive grants tothe requestor.Table II shows some results obtained with a syntheticbenchmark that exploits the migratory sharingpattern. In particular, 20000 memory accesses (50%loads and 50% writes) are issued by all the processorsJP2011-579

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 10.Managing read requests for a private blockherency protocols are defined with the simple definitionof events, actions, and transitions, easily codedin a text-based file and following simple rules. Thenetwork is also defined with many parameters as thetopology, the routing algorithm, and the pipelinedswitch design.gMemNoCsim has been developed to overcome theproblem of long simulation time required by complexsystem-wide environments like GEMS/SIMICS.With gMemNoCsim, memory access traces are usedto speed up simulation time. To keep simulationaccuracy we instrument the traces with the inclusionof memory access dependencies which temporarilyblock processors following synchronization eventsand barriers. As future work we plan to analyzethe impact of memory dependencies computation onsimulation accuracy. Also, we plan to use the platformas an effective tool for network and memoryhierarchy co-design.AcknowlegmentThis work was supported by the Spanish MEC andMICINN, as well as European Commission FEDERfunds, under Grant TIN2009-14475-C04-01. It wasalso partly supported by the project NaNoC (projectlabel 248972) which is funded by the European Commissionwithin the Research Programme FP7.Fig. 11. Managing read requests when a migratory sharingpattern has been detected by the L2 cache bankto the same memory location (variable). Reads andwrites are performed sequentially following the migratorysharing pattern. As can be seen, executiontime is halved by the improved coherency protocol.Indeed, practically all the write operations have beenperformed in the updated protocol in the exclusivemode, thus having exclusive access and not requiringany coherence action to be performed. This translatesalso to half the number of packets injected intothe network.V. ConclusionsIn this paper we have presented the gMemNoCsimsimulator. Memory coherency and on-chip networkcan be co-designed with the new tool as it allows adetailed and accurate modeling of both components.Besides, memory controllers are also modeled. Co-Inv. Inv. with MSCycles 1269949 645099Stores in Shd mode 9999 1Stores in Excl mode 1 9999Injected packets 229997 110021L1 misses 19999 10001L1 hits 1 9999TABLE IIStatistics for two different protocolimplementations in gMemNoCsimReferences[1] Luca Benini, Giovanni De Micheli Networks on chips:technology and tools, Academic Press, 2006.[2] Jose Flich, Davide Bertozzi Designing Network On-ChipArchitectures in the Nanoscale Era, Chapman & Hall/CrcComputational Science Series, 2010.[3] P. S. Magnusson, M. Christensson, and J. Eskilson, et al.Simics: A full system simulation platform., IEEE Computer,35, Feb. 2002. IEEE Computer, 35, 2002.[4] M. M. Martin, D. J. Sorin, and B. M. Beckmann, et al. .Multifacet general execution-driven multiprocessor simulator(GEMS) toolset., Computer Architecture News, 33,2005 .[5] Niket Agarwal, Li-Shiuan Peh and Niraj K. Jha. Garnet:A Detailed Interconnect Model Inside a Full-SystemSimulation Framework, CE-P08-001, Dept. of ElectricalEngineering, Princeton University, 2008.[6] S. C. Woo, M. Ohara, E. Torrie, J. P. Singh, and A. Gupta.The SPLASH-2 programs: Characterization and methodologicalconsiderations., 22nd Int. Symp. on ComputerArchitecture (ISCA), 1995.[7] Christian Bienia, Sanjeev Kumar, Jaswinder Pal Singhand Kai Li. The PARSEC Benchmark Suite: Characterizationand Architectural Implications, Proceedings ofthe 17th International Conference on Parallel Architecturesand Compilation Techniques, 2008.[8] Per Stenstrom, Mats Brorsson, Lars Sandberg An adaptivecache coherence protocol optimized for migratory sharing,ISCA ’93 Proceedings of the 20th annual internationalsymposium on computer architecture , 1993.JP2011-580

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Docencia en arquitectura, tecnología de computadores yprogramación paralelaJP2011-581

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-582

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011E-Assessment of Matlab Assignments inMoodle: Application to an IntroductoryProgramming Course for EngineersJulián Ramos, María A. Trenas, Sergio Romero, Eladio Gutiérrez 1Abstract — This article introduces a novel extension forMoodle supporting the automatic verification of codeswritten in Matlab. It has been applied when teaching thebasics of imperative programming in a course aimed atchemical engineering students. The extension derives fromthe module CTPracticals, originally developed by theauthors to enable the automatic assessment of VHDLassignments in Moodle. Several major changes have beenmade, mainly in the automatic verification engine, in thecore of the system, and in several user interfaces. Themodule partially frees teachers from the repetitive task ofverifying assignments, allowing them to invest more timeassisting students and tackling new pedagogical objectives.An anonymous student survey proved that students aresatisfied with the system because they find the feedbackand the constantly updated view of the status of theirassignments helpful.Keywords — Learning Management Systems (LMS),Moodle, E-Assessment / Computer Aided Assessment(CAA), Programming Teaching, Matlab.FI. INTRODUCTIONundamentals of Computers is a subject taught duringthe first course of the Chemical Engineering studiesin the academic program of the University of Málaga(Spain), with 6 European credits, 3 of which arepractical. It should be mentioned that each learningcredit defined by the European Credit Transfer System(ECTS) involves about 25 hours of student work. Astandard ECTS academic year consists of 60 credits,which means a total workload of about 1500 hoursduring two semesters.The practical component is aimed at acquiring thebasic programming skills required in chemicalengineering. The Matlab programming language waschosen due to its learnability and its wide application inscience and engineering. Because students find itdifficult to verify their codes and solutions, a continuousassessment plan is required. However, providingstudents with frequent feedback had previously been atime-consuming task, as the teachers could onlymanually verify the assignments [1].In such situations, e-assessment and computer-aidedassessment (CAA) can make the teacher’s work moreeffective, as shown by numerous experiences andstudies in the literature, including both the software [2,3, 5, 6] and the hardware side of the Computer Science1 Department of Computer ArchitectureUniversity of Málaga, 29071 Málaga, Spaine-mail: {julian, matrenas, sromero, eladio}@uma.es.teaching [7, 8]. An overview of the diverse proposalsand systems for the automatic verification ofprogramming activities can be found in [9] and [10].Nevertheless, as pointed out in [9], it becomes difficultto adopt automatic verification in general due to the lackof interoperability of the different approaches, whichhave been developed for specific contexts. Additionally,following the students’ progress requires not only agood assessment mechanism but also an effectiveadministration. In fact, learning management systems(LMS) are taking a significant role in the currenteducational landscape. Through web interfaces, theyprovide support for a wide collection of activities,including forums, assignments and quizzes, andeffective strategies for class management, such asgradebooks or student annotations.The module CTPracticals [11, 12] is the result of theauthors’ effort to integrate CAA features into an LMS,particularly Moodle (Modular Object-Oriented DynamicLearning Environment) [13]. Originally, the module wasdesigned to support digital logic labworks in the contextof a course on computer organisation. It introduces anadvanced interface to manage assignments, submissionsand assessments, and it automates the verification of theVHDL-based designs submitted by students, providingdetailed feedback from results for both teachers andstudents. Moodle is open-source software, with amodular organisation and interface that facilitates thedevelopment of new modules and activities [14].According to moodle.org, there were about 50,000validated sites in December 2010, and, in particular, it isthe platform used by the Virtual Campus of theUniversity of Málaga.This article describes how CTPracticals has beenextended to support courses whose practical work isbased on Matlab assignments. The next section presentsthe course organisation and how CTPracticalsinfluences the applied teaching methodology. Then,there is a brief review of the main interfaces andfunctionality of the module, common for both VHDLand Matlab-based lab works. Section 4 focuses on thechanges undertaken in the verification engine. Thearticle ends with some evaluation results andconclusions.II. COURSE ORGANISATION AND METHODOLOGYBecause Fundamentals of Computers is an introductorycourse targeted to chemical engineering students, theprogramming language Matlab was chosen to introducebasic programming skills. It has most of the desiredfeatures: it is easy to learn and use (compilation is notnecessary), and it is widely used in science andJP2011-583

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011engineering. During the course, students will use it tosolve mathematical problems commonly found inchemical engineering, including basic algorithms, linearand nonlinear regression, equations, equation systems,and differentiation. Later, students will be able to applythese skills in higher-level courses.Because the course belongs to the first semester of theirfirst academic year, students have no prior programmingknowledge. The first classes are devoted to explainingthe basics of Matlab syntax and its interfaces. Differentgraphical representations, both in two and threedimensions, are presented in implicit and parametricform as a first application. Afterward, they learn thebasic flow control statements of imperativeprogramming: sequential, alternative, and iterative.Finally, they apply this knowledge by implementingsmall programs and practicing with functions providedby Matlab for statistical and numerical calculation.Two sorts of programming exercises are proposed toachieve these instructional objectives:Graphical representation of both data andmathematical expressions: Students mustimplement a script that generates or reads theinput data and represents this data graphically,according to some specifications (2-D or 3-Dplotting, axis scale, line colours, drawing shapes).Programming of simple functions: Students mustprogram simple functions that take certain inputparameters and should return some output valuescalculated according to the specification.An example of a labwork specification comprising bothkinds of exercises is included in Figure 2.As usual, a correct exercise is the one fulfilling all thespecified requirements. However, students find itdifficult to verify their labworks, and more personalisedsupervision of student work becomes necessary. Theycan now submit their labworks using the CTPracticalsmodule, whose automatic verification engine comes intoplay to make it feasible.On one hand, students can immediately see the state oftheir labwork. The teachers are able to configure thelevel of this automatic feedback, as shown in Section 4,and when this feedback information will be provided.Teachers can decide on these details based on theirteaching objectives, which will differ in various stagesof a course. Due to the students' inexperience,immediate feedback with a deeper level of detail isrequired in the first stages, encouraging the demand forteacher tutoring. However, feedback should be graduallyreduced in subsequent stages as students graduallyimprove their verification skills. These features ofCTPracticals lead the students to identify theirknowledge gaps and resolve their doubts through groupor personal tutoring sessions with the teacher. Thestudents can collaborate in their solution through theMoodle forums (as shown in Figure 1).On the other hand, as the tool expedites the verificationof the labworks, teachers gain more time to advisestudents. When individual problems are detected, notonly is personalised attention to the students improvedduring the laboratory sessions but personal tutoringappointments can also be established. The Moodlescheduler module can be used to make theseappointments (Figure 1). Moreover, because the moduleallows the teacher to have a global view of the groupevolution, it is possible to detect general problemsencountered by the students, which can be analysed andexplained in special class sessions if necessary. TheMoodle forums are also a great help (see Figure 1).Figure 1: Teacher’s view of a typical Moodle course includingCTPracticals activities.III. MODULE FEATURESThis section will briefly review the interfaces andfunctionality of the module that have remainedunchanged after its extension to Matlab labworks. Thereader may refer to [12] for further details. CTPracticalsis fully integrated in the Moodle system together withthe other modules available in a standard installation. Itinvolves two different elements: the activity moduleitself and a control block (see Figure 1). The moduleallows one to define the different activity instances thatwill appear inside the course sections. The control block,on a side panel, provides access to control actions. Boththe activity instance and the control block have differentbehaviours for teachers and students.The student's view of a CTPracticals activity is shownin Figure 2(a). Basically, it allows students to submittheir practical work and to find information aboutassignments. This information includes the definition ofthe assignment, including its specifications and deadline,and the feedback and results obtained from theautomatic verification process. Knowing whether asolution is right or wrong according to specificationswill be of special interest for the students. In addition,the module manages students in teams, each of whichhas a unique identifier. An option of the side controlblock allows students to make up new teams or join anexisting one with the permission of the current members.The activity view for the teacher (Figure 2(b)) isslightly more complex. It consists of three tabs: practicalassignments, testers, and submissions. Remarkablefeatures include;Practical assignments: The teacher may configuredifferent parameters for each practical assignment:the submission deadline, the score, or anexpression forcing the name of the file thestudents will have to submit. Other configurableaspects are order of appearance and scope (publicin this course or in the whole Moodle site). TheJP2011-584

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011teacher can also restrict the visibility of the resultsby controlling if the automatic feedback will beshown to the student immediately aftersubmission, if it will be delayed until a given dateor if it will remain totally hidden.although one of them must be marked as thedefault.Submissions: A submission instance is defined foreach pair team/practical assignment. It embracesthe file(s) submitted by a team for eachassignment and all report files and statusinformation generated after the verification of thesubmitted labwork. The teacher can inspect allthese elements to obtain an overall picture of thestudents’ progress. It is also possible to manuallyadd a short feedback message to the student.Other administrative functionalities, such as statisticreports (through the options course at a glance andstatistics), the management of the student teams(maximum number of members, deadline for its setup), and the updating of the Moodle gradebook withthe activity scores, are accessed through the sidecontrol block (Figure 1).(a)Figure 3: Teacher view for creating and managing the testers.(b)Figure 2: Activity views for students (a) and teachers (b).Testers: This feature is used by the verification engineto check if a submitted labwork fulfills thespecifications. It is possible to add new testers orto edit previously created ones (Figure 3).Moreover, teachers can share testers or reuse theones defined in preceding courses. Testers may beenabled or disabled by the teacher. If disabled,they will not be applied by the verification engine.An interesting feature is that several testers maybe defined for the same practical assignment,IV. VERIFICATION ENGINE FOR MATLABThe automatic verification engine is in the core of theCTPracticals module. Students submit the requestedMatlab source files (.m) as one .zip file. The verificationengine uncompresses the submission and then runs theMatlab sources. According to the execution outputs,which are compared to a reference correct output, thestatus result of verification (right/wrong) is generatedtogether with the corresponding feedback information.The verification process takes place in three phases [9]described in Table I. To extend the CTPracticalsfunctionality to Matlab labworks, changes werenecessary in the first two phases.At the time of submission, the verification process isautomatically triggered using the default tester.Additionally, it can be manually started by the teacher inbatch mode, which may be useful when some changeshave been introduced after submitting or if severaltesters have been defined for a same assignment. Apractical assignment can be resubmitted an unlimitednumber of times until the deadline expires. The feedbackinformation includes not only the result (right/wrong)but also possible format errors in sources (static analysisJP2011-585

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011phase), a comparison between the execution output andthe reference result in a nicely printed format (dynamicanalysis phase) and a log of the whole verification. Thelatter two items are helpful in finding the cause of errors.A more extended log with internal execution details isavailable to teachers and administrators.1. Static analysis phaseSubmission format errorSyntax errorPlagiarism avoiding2. Dynamic analysis phaseFunctionalityEfficiencySecuritySemiautomatic verification3. Feedback phaseResults and logsMetricsWork promotionTABLE IFEATURES OF THE CTPRACTICALS VERIFICATION PROCEDURE.Does the submitted .zip contain required files?Bad scripts are detected via try-catch Matlab statement.Filenames (.zip and its contents) and scripts can be based on the team’s identifierin order to restrain plagiarism.Using Matlab on command line the tester script is invoked and will launchexecution of submissions.Script execution time is stored for statistical purposes.Script execution into a chroot sandbox prevents possible system crashes.A manual mode allows the instructor to introduce his own verification results ifnecessary.A differences file resulting from comparison of the student’s output with areference right output, together with a log of execution.Assessment metrics are integrated in the Moodle gradebookThe immediate availability of results can be restricted, in order to preventstudents from falling into trial-and-error attempts.The definition of the tester is given by both theverification script (command file) and a reference outputfile (correct result file), as shown in Figure 3. It must becarefully carried out because the accuracy andhelpfulness of the verification will depend on it. Asimple example of tester design is shown in Figure 4,with an outline of the verification flow and one scenarioof how the tester works on the submitted works. Theoutput of the verification script, which in turn invokesthe student Matlab source, is compared with thereference file. The output can include simple numericalvalues (Figure 4(c)) or more complex messages obtainedfrom a test carried out inside the verification script itself(Figure 5). The reference file must be designedaccordingly. At this point, it is possible to control thedegree of detail of the feedback information that will begenerated for the student. It depends on the number ofvalues/messages that the teacher decides to output whendesigning the verification script.As shown, verifying Matlab functions with numericaloutputs is quite straightforward, but the codesperforming graphical data representations requireanother approach. The comparison of the visualappearance of two plots is not at all trivial [15].However, it is possible to use another more precise andefficient approach with the handler that Matlabassociates with each graphical plot (see example inFigure 5). This handler contains information aboutvalues, coordinates, colour, drawing line features, axisscale, and so on. These attributes can be compared withthe expected ones without the need for any graphicaldisplay output.Figure 4: Tester design and verification flow: verification script (b)and reference file (c) for a given assignment specification (a). Afterverifying the student’s submission, the status (OK/wrong) is available,together with a difference html output (d) and a log of the process (e).JP2011-586

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011that had been previously enrolled in the course. Theiropinion was of special interest to compare the newmethodology with respect to the previous one.Figure 6: Weekly distribution of the submissions during the course.Figure 5: Example of a more complex tester: verification script (a)and reference file (b). The assignment must compute a quadratic fittingfor the specified data and represent them in a plot.V. EVALUATIONThis section presents the authors’ experience applyingthe CTPracticals module in the teaching of the practicalcomponent of Fundamentals of Computers, as describedin Section 2. The module is currently running on adepartmental server using Moodle version 1.9. It hasbeen used extensively since the second semester of theacademic year 2007 for VHDL lab works. The Matlabextension described in this contribution was madeavailable to students at the beginning of the academicyear 2009/10. Specifically, 56 enrolled students,distributed into two classrooms, followed the practicalsessions of Fundamentals of Computers.Figure 6 corresponds to the distribution of the numberof submissions since the course started. Altogether, 30practical mini-assignments of increasing difficulty wereproposed during the course. The most complexproposals involved the development of Matlab codes ofno more than fifty lines. The distribution follows atypical shape with multiple peaks, which correspond tosubmissions near deadlines and periods of lower activityin holiday seasons. The submissions with format errorsor that are wrong, according to specifications, need to beresubmitted. Students can resubmit them as many timesas they want until the deadline expires for a givenassignment. Observe that the ratio of correctsubmissions with regard to erroneous ones increases asthe course progresses. Two causes may explain this fact:students are trained on the use of the system, and, mostimportantly, they gain increasingly more programmingskills.To evaluate the degree of satisfaction of students whenusing the CTPracticals module, an anonymous opinionpoll was carried out. Table II summarises the results foreach questionnaire item on a Likert scale from one tofive. The first block of questions was intended toevaluate the experience for all the enrolled students. Thesecond block of questions was addressed to the studentsAccording to the marks, it can be concluded thatstudents were in generally pleased with the system. ItemA.7 had a lower punctuation; students find it difficult tounderstand the feedback output of the automaticverification. They expected more direct messages, suchas “you must fix this one”, which would lead them touse the evaluator as a debugger, working on a trial anderror basis. To prevent this usage, teachers are able tocontrol the depth of the feedback and the date forpublishing, especially for more advanced labworks.After all, students find it very difficult to verify theircodes and solutions, and one of the objectives of thecourse is to bridge this gap.In previous years, students were provided with ananswer book. Thus, students would routinely copy theanswer to an exercise, without making the effort toarrive at the solution on their own and verify andsubsequently amend the intermediate malfunctioningsolutions. Looking at the poll results (item B.3), it isremarkable that, previously enrolled students derivemore motivation from CTPracticals in verifying theirlabworks than from simply looking in the answer book.Finally, a positive influence on the academicperformance was observed after the use of theaforementioned teaching methodology based on the useof the CTPracticals Moodle module. During theacademic year 2009/10, the number of students passingthe exam (marks greater than 5/10) was about 60%higher than in the previous year. After all, today'sstudents are moving comfortably in the field of newtechnologies. The CTPracticals module, as a part of alearning platform, fits this way of thinking and working,and it provides elements that students expect, such as anintegrated tracking of practical work and nearlyimmediate feedback.VI. CONCLUSIONSDeveloped by the authors and fully integrated in theMoodle platform, CTPracticals is a module that allowsthe remote automatic verification of the student'slabwork with an effective administration of results.Originally, the module was aimed at the automaticverification of VHDL-based assignments, but it has beenextended to support Matlab programming. Thisextension involved modifications of the verificationengine of the module and several of its interfaces.As described in this work, some importantmethodological changes were introduced into anintroductory computing course given in the first year ofChemical Engineering. Not only did it considerablyJP2011-587

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011improve some organisational aspects of the course, but itwas able to motivate students to accomplish theirlabworks correctly. The automatic verification featureincreases the dynamism of laboratory; students canknow the state of their labworks immediately, andteachers have, at all times, an overall picture of theirstudent group, which improves their feedback andallows them to tackle new pedagogical objectives.In addition, the module can mitigate some negativeeffects commonly associated with automatic assessmentsystems. Because it is possible to control both the depthand the date for publishing the feedback results, the riskof students using the system on a trial-and-error basiscan be mitigated. Plagiarism may be controlled to someextent as well; submitting copies is more difficult if theteacher defines testers and filenames as a function of theuser's identifier.TABLE IIDISTRIBUTION AND AVERAGE OF MARKS FOR THE STUDENT QUESTIONNAIRE (1=STRONGLY DISAGREE, 5=STRONGLY AGREE)A. Questions for all currently enrolled students: 1 2 3 4 5 Avg.A.1. I consider it is important for a chemical engineer to learn computer programming 5% 5% 24% 35% 31% 3.8A.2. Comparing with other subjects, I find programming a difficult task 5% 3% 8% 30% 54% 4.2A.3. I have a positive global opinion of the CTPracticals module 3% 3% 38% 32% 24% 3.7A.4. I find easy to learn how to use the system 5% 11% 14% 22% 48% 4.0A.5. I have discovered errors in my labworks that otherwise would have remained hidden for 5% 3% 27% 35% 30% 3.8meA.6. I find automatic feedback after labwork submission quite fast 5% 8% 14% 35% 38% 3.9A.7. I find automatic feedback reports are quite understandable 11% 16% 43% 24% 6% 3.0A.8. I find the automatic feedback useful in order to check my labwork 8% 0% 35% 32% 25% 3.6A.9. I think that system feedback helps me to amend my labwork 11% 22% 35% 22% 10% 3.0A.10 I find the availability of my labworks without time or place restrictions quite useful 3% 5% 8% 32% 52% 4.2B. Questions for students enrolled in the course on previous years: 1 2 3 4 5 Avg.B.1 This year, I find that it is easier to learn Matlab 0% 23% 31% 15% 31% 3.5B.2 I have accomplished the exercises more quickly 0% 15% 38% 15% 32% 3.6B.3. I find CTPracticals more motivating in order to verify my labworks, than just looking to 0% 8% 38% 8% 46% 3.9the answers bookB.4. I find it easier to check the correctness of my labwork 0% 8% 23% 62% 7% 3.7VII. DEMONSTRATION SITEA demo site is available at http://guac.ac.uma.es/demo[User: demouser, password: demo].REFERENCES[1] Amelung M., Piotrowski M. and Rösner D. EduComponents:experiences in e-assessment in computer science education.ITICSE’06: Proceedings of the 11th annual SIGCSE conference onInnovation and technology in computer science education, ACM,2006; 88–92.[2] Malmi L., Korhonen A. and Saikkonen R. Experiences inautomatic assessment on mass courses and issues for designing virtualcourses. SIGCSE Bulletin 2002; 34(3):55–59.[3] Douce C., Livingstone D. and Orwell J. Automatic test-basedassessment of programming: A review. Journal on EducationalResources in Computing 2005; 5(3):4:1–13.[4] Rößling, G., Joy, M., Moreno, A., Radenski, A., Malmi, L.,Kerren, A., Naps, T., Ross, R. J., Clancy, M., Korhonen, A., Oechsle,R., and Iturbide, J. Á. Enhancing learning management systems tobetter support computer science education. SIGCSE Bulletin 40, 4;2008, 142-166.[5] Barchino R., et al. Assessment design: A step towardsinteroperability. Computer Applications in Engineering Education.May 2009; DOI: 10.1002/cae.20363.[6] Liu X. A new automated grading approach for computerprogramming. Computer Applications in Engineering Education. Oct2010; DOI: 10.1002/cae.20494[7] Rodriguez, S. et al. Computer-based management environment foran assembly language programming laboratory. ComputerApplications in Engineering Education, April 2007; 15(1): 41-54.[8] Kurmas Z. Improving student performance using automatedtesting of simulated digital logic circuits. ITiCSE ’08: Proceedings ofthe 13th annual conference on Innovation and technology in computerscience education, ACM, 2008; 265–270.[9] Ala-Mutka K. A survey of automated assessment approaches forprogramming assignments. Computer Science Education, 2005;15(2):83–102.[10] Chatzopoulou, D.I. and Economides, A.A. Adaptive assessmentof student's knowledge in programming courses. Journal of ComputerAssisted Learning, Aug. 2010; 26(4):258-269.[11] Corbera, F., Gutiérrez, E., Ramos, J., Romero, S., and Trenas, M.A. Development of a new Moodle module for a basic course oncomputer architecture. SIGCSE Bull. 40, 3, Aug. 2008; 349-349.[12] Gutierrez E., Trenas M.A., Ramos J., Corbera F. and Romero S.A new Moodle module supporting automatic verification of VHDLbasedassignments. Computers and Education, Feb 2010; 54(2):562–577.[13] Moodle site. URL: http://moodle.org.[14] Moore J. and Churchward M. Moodle 1.9 ExtensionDevelopment. Pack Publishing. April 2010.[15] English J. Automated assessment of GUI programs using JEWL.Proceedings of the 9th annual SIGCSE conference on innovation andtechnology in computer science education, ACM New York, NY,USA, 2004; 137–141.JP2011-588

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Sobre la integración del Curriculum Initiativeon Parallel and Distributed Computing enlos planes de estudio del Grado en IngenieríaInformáticaFrancisco Almeida 1 Domingo Giménez 2 José-Miguel Mantas 3 Antonio M. Vidal 4Resumen— Recientemente el Technical Committeeof Parallel Processing (TCPP) de IEEE realizó unapropuesta de contenidos sobre Computación Paralelay Distribuida a incluir en los estudios universitarios.En este artículo se analiza la inclusión de los distintostópicos del NSF/TCPP Curriculum Initiative on Paralleland Distributed Computing en los planes de estudio delGrado de Ingeniería informática.Palabras clave— Computación Paralela, Grado de IngenieríaInformática, Planes de Estudios.I. IntroducciónLOS estudios de informática en España estánsiendo reorganizados. Han cambiado de una organizaciónen dos carreras técnicas de tres cursosy una superior de cinco cursos a un único Gradode Ingeniería Informática (GII) de cuatro cursos.La mayoría de las universidades españolas tienenaprobado el plan de estudios del GII, y en el curso2010/2011 han puesto en marcha el primer o los dosprimeros cursos.Por otro lado, debido a los avances tecnológicos, lacomputación paralela se ha difundido ampliamente.En la actualidad este tipo de computación ya nose encuentra sólamente en clusters de ordenadoresy en supercomputadores, sino que se ha convertidoen el tipo de computación de los sistemas computacionalesestándares: los ordenadores personales y losportátiles son sistemas multicore e incluyen tarjetasGPU que se pueden programar en paralelo. Debido ala gran importancia actual de la computación paralela,el IEEE Technical Committee on Parallel Processing[1] ha lanzado una iniciativa para definir lostópicos de computación paralela y distribuida quedeberían incluirse en los curricula de los estudios universitariosde informática.Por todo esto, consideramos que en este momentoes conveniente discutir cómo se están integrando ycómo se podrían integrar en los GII los tópicos sobreparalelismo incluidos en la propuesta del TCPP;y en este artículo analizamos la situación de lostemas de paralelismo en el GII en varias universidadesespañolas en relación con la propuesta del1 Dpto. de Estadística, Investigación Operativa y Computación,Univ. La Laguna, e-mail: falmeida@ull.es2 Dpto. de Informática y Sistemas, Univ. Murcia, e-mail:domingo@um.es3 Dpto. de Lenguajes y Sistemas Informáticos, Univ.Granada, e-mail: jmmantas@ugr.es4 Dpto. de Sistemas Informáticos y Computación, Univ.Politécnica de Valencia, e-mail: avidal@dsic.upv.esTCPP.Los autores de este artículo estamos colaborandoen los últimos años en temas de docencia del paralelismo,en particular con la elaboración de un librode introducción a la programación paralela [2], yartículos sobre docencia del paralelismo [3]. El librose publicó en 2008, pero su escritura comenzó en el2004, y desde entonces la computación paralela haexperimentado un gran cambio, principalmente conla generalización del uso de multicores y la popularizaciónde las GPUs y su uso como sistemas decómputo de propósito general. Así, con la popularizacióny universalización de los sistemas paralelosdebemos repensar la forma en que se debe impartirel paralelismo, y en este sentido hemos presentadoen mayo de 2011 un poster dentro del workshopEduPar11 [4], organizado por el IEEE TCPPy dedicado a la docencia de la programación paralela.Este trabajo es una versión extendida de dichoposter, y presenta nuestra visión sobre la situaciónde la programación paralela en el GII en las universidadesespañolas. Los autores trabajamos en diferentesuniversidades (Granada, La Laguna, Murciay Politécnica de Valencia), y llevamos varios añosimpartiendo docencia de programación paralela endistintos niveles, y trabajando en diferentes líneasdentro de la computación paralela, por lo que entendemosque nuestra visión no es una visión local,sino que es múltiple, aunque desde el campo de laprogramación y la computación.El artículo está organizado de la siguiente forma.En la sección 2 discutimos nuestras ideas generalessobre la situación actual y la deseable de la docenciade la programación paralela en los estudios de informáticaen la universidad española. En la sección3 analizamos los tópicos de paralelismo que aparecenen los planes de estudio del GII de las universidadesdonde impartimos docencia, y comparamosla situación con la que consideramos deseable y conla propuesta del TCPP. En la sección 4 se analizacómo se tratan en nuestras universidades los diferentestópicos de paralelismo de la propuesta delTCPP. En la sección 5 se resume el trabajo realizadoy se proponen posibles colaboraciones para ampliarla discusión sobre la inclusión de temas de paralelismoen los GII.JP2011-589

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011II. Ideas sobre contenidos de ComputaciónParalela en los estudios universitariosde informáticaLas ideas generales de nuestra propuesta coincidencon las de otras propuestas y estudios:• Los contenidos de computación paralela enlos curricula de informática están aumentandogradualmente [5], y normalmente se organizanen la misma forma que en las universidadesdonde trabajan los autores:– se introducen nociones de sistemas paralelos encursos de arquitectura de computadores,– aparecen algunos cursos introductorios de concurrenciao programación paralela (en algunoscasos optativos),– y se encuentran cursos optativos de computaciónparalela en algunas especialidades oen estudios de máster.Pero los sistemas computacionales son en la actualidadsistemas paralelos, y la introducción ala computación paralela debería ser obligatoriapara todos los estudiantes del Grado de IngenieríaInformática.• No está clara (y nosotros no tenemos ningunasolución) la forma en que se debería introducirla programación paralela en los primeros nivelesde los estudios universitarios, pero parece claroque debería introducirse de alguna manera: loslibros más populares de algoritmos [6], [7] incluyencapítulos sobre algoritmos paralelos enlas últimas ediciones, y el curriculum de ACM[8] menciona la necesidad de introducir la computaciónparalela entre los tópicos obligatorios,aunque no da ninguna indicación de cómo se incluirían.• Las nociones básicas de sistemas paralelos se introducennormalmente en cursos de arquitecturasde ordenadores en los diferentes cursosde los estudios de informática, pero en programaciónparalela la situación es diferente, yusualmente se ignora en las asignaturas obligatorias,o se introduce separada de los cursosdonde se estudian conceptos de programaciónsecuencial (cursos de programación o de estructurasde datos y de algoritmos). Esto produceuna separación entre lo que estudian los futurosprofesionales de la informática y los entornos enlos que trabajarán en su vida profesional: lossistemas computacionales a los que tendrán accesoson paralelos, y por tanto deberían estudiarsistemas paralelos y también conceptos de programaciónparalela.Así, nuestra propuesta (que coincide con otraspropuestas, lo que difícilmente podría ser de otramanera dada la situación actual) es incluir tópicosobligatorios de programación paralela desde losprimeros cursos en los curricula del Grado de IngenieríaInformática, incluyendo de forma progresivanociones de paralelismo en los sucesivos cursos, conalgún curso obligatorio sobre paralelismo (sistemas,arquitecturas, programación, concurrencia, etc.) ycursos optativos de paralelismo dependiendo de la especializaciónpor la que se decante cada estudiante.El curriculum del IEEE TCPP de Computación Paralelay Distribuida significa una oportunidad paradiscutir cómo debe realizarse la inclusión de los conceptosde paralelismo en los curricula del GII. Por lotanto, comparamos la propuesta del TCPP [1] con lanuestra [3] y con la situación en las cuatro universidadesdonde trabajamos.III. La Computación Paralela en el Gradoen Ingeniería InformáticaLa figura 1 resume de forma gráfica nuestra propuestasobre la inclusión de conceptos de ComputaciónParalela en el Grado en Ingeniería Informática.Las ideas generales son:Fig. 1. Propuesta de organización de contenidos de ComputciónParalela en el Grado en Ingeniería Informática.• Los conceptos básicos de paralelismo no deberíanintroducirse mucho después de los de programaciónsecuencial (por ejemplo, se podríanintroducir en el segundo año de los estudios), yse deberían tratar tanto en cursos de arquitecturay tecnología de computadores como en cursosde programación. Los cursos de arquitecturase representan en azul en la figura, los de programaciónse representan en verde, y los contenidoscorrespondientes de paralelismo se representanen azul o en verde oscuro.• Los conceptos básicos de concurrencia, herramientasde programación paralela y de computacióndistribuida se incluirían en cursos dearquitecturas y de programación, y posiblementepodría haber algún curso específico (representadoen rojo en la figura) para estudiarestos conceptos más en profundidad.• Algunos aspectos algorítmicos del paralelismo(representados en amarillo) se incluirían en elúltimo semestre común, posiblemente dentro dealgún curso de programación o de concurrencia.• En las cinco especializaciones (Ingeniería deComputadores, Ingeniería del Software, Computación,Tecnología de la Información y Sis-JP2011-590

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011temas de Información) se incluirían aspectosdistintos de paralelismo, con diferentes orientacionessegún la especialidad:– En la intensificación de Ingeniería de Computadoresincluiríamos especialización en arquitecturasparalelas, herramientas de programacióncentradas en la explotación desistemas paralelos, y algunos aspectos deprogramación y metodologías, principalmentecentrados en la aplicación de la supercomputacióna la solución eficiente de problemascientíficos, y una parte dedicada a laintegración de distintos aspectos del paralelismo,por ejemplo a la planificación e implementaciónde la organización física y lógica deun laboratorio de supercomputación.– El énfasis en la especialidad de Ingenieríadel Software se pondría en el estudio deherramientas para computación distribuiday gestión de la web, y en la tecnología ymetodología de la programación paralela.– En la intensificación de Computación se estudiaríanalgunos aspectos algorítmicos de laprogramación paralela.– En la especialidad de Tecnologías de la Informaciónse tratarían algunos aspectos tecnológicosde la computación distribuida, especialmentedesde el punto de vista de lossistemas, pero también con algunos aspectoslógicos.– Finalmente, en la intensificación de Sistemasde Información se estudiarían algunos aspectosde los sistemas distribuidos y la programaciónparalela, principalmente estudiando laintegración de diferentes tópicos, pero sin laimplementación física propia de la especialidadde Ingeniería de Computadores.A continuación resumimos y comentamos brevementela situación en nuestras cuatro universidades.Las figuras 2 (Granada), 3 (La Laguna), 4 (Murcia)y 5 (Politécnica de Valencia) muestran unavisión aproximada de la situación del paralelismoen los planes de estudio del GII en estas universidades.Los planes de estudios están ya aprobados,pero en el curso 2010/2011 se han puesto en marchaúnicamente el primer o los dos primeros cursos de losestudios de grado, por lo que las figuras representansólo una aproximación a la realidad, pues la profundidada la que se tratará cada tópico depende de unaserie de factores y no puede conocerse hasta que esténimplantados todos los cursos. Las figuras las hemosgenerado a partir de los planes de estudio, y consultandoa profesores y departamentos que han participadoen la elaboración de los planes y que seránlos responsables de la impartición de los temas relacionadoscon el paralelismo una vez se hayan puestoen marcha todas las asignaturas.Comparamos nuestra propuesta con la situaciónen las cuatro universidades:• Todas las universidades incluyen conceptos deFig. 2. Organización de contenidos de Computación Paralelaen el Grado en Ingeniería Informática en la Universidadde Granada.Fig. 3. Organización de contenidos de Computación Paralelaen el Grado en Ingeniería Informática en la Universidadde La Laguna.computación paralela en asignaturas de tecnologíay arquitectura de ordenadores, empezandoen el segundo año de los estudios.• La situación es muy diferente en las asignaturasde programación, donde la programación secuencialno se estudia siempre junto con conceptosde programación paralela, y cuando seincluye programación paralela es normalmentesólo en un semestre y al final de los cursos comunes.En las universidades de Granada, LaLaguna y Politécnica de Valencia se estudian algunosaspectos de programación paralela dentrode asignaturas generales de programación, en lossemestres tercero (Granada), quinto (Valencia)o sexto (La Laguna).• La mayoría de las universidades incluyen enel segundo curso del GII alguna asignaturaespecífica sobre computación paralela o distribuida,donde se estudian los conceptos básicosde la concurrencia, sistemas distribuidos y paralelosy herramientas. La única universidad queincluye una cierta orientación de metodologíaJP2011-591

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4. Organización de contenidos de Computación Paralelaen el Grado en Ingeniería Informática en la Universidadde Murcia.programación paralela en Granada y Murcia.• En la Universidad Politécnica de Valencia se incluyentópicos de programación paralela en la intensificaciónde Computación, donde se estudiannociones de computación distribuida y de herramientasde programación paralela. Al contrariode lo que proponemos, no se incluyen tópicos dealgoritmos paralelos. La única universidad queincluye algunos aspectos de algoritmos paralelosen esta intensificación es la de La Laguna.• En la intensificación de Tecnologías de la Informaciónse tratan algunos aspectos de computacióndistribuida, con más énfasis en sistemas(Murcia) o en aspectos lógicos (Granaday La Laguna). La Universidad de Granadatambién incluye un módulo de integración de aspectosfísicos y lógicos del paralelismo.• Las universidades de Granada y La Laguna incluyenen la intensificación de Sistemas de Informaciónlos mismos tópicos de computacióndistribuida que en la de Tecnologías de la Información.IV. Tópicos de paralelismo en la propuestadel IEEE TCPPFig. 5. Organización de contenidos de Computación Paralelaen el Grado en Ingeniería Informática en la UniversidadPolitécnica de Valencia.de la programación paralela es la de Granada.La Universidad de La Laguna incluye estostópicos en un curso de programación en el sextosemestre.• La Universidad de Granada es la única que incluyealgunos aspectos de algoritmos paralelosen los cursos comunes.• Todas las universidades incluyen intensificaciónen arquitecturas paralelas y herramientas deprogramación paralela en la especialidad de Ingenieríade Computadores, pero ninguna incluyeun módulo dedicado a integrar los diferentes aspectosdel paralelismo. En la Universidad deMurcia se contemplan algunos aspectos de programaciónparalela, y en la Politécnica de Valenciase intensifica en programación paralela ysus aplicaciones.• En las universidades de Granada, La Laguna yMurcia se incluyen tópicos de computación paralelaen la intensificación de Ingeniería del Software,y los tópicos que se tratan correspondena programación distribuida en las tres universidades,y adicionalmente de metodología de laEn esta sección analizamos la inclusión en losplanes de estudio del GII de los diferentes tópicos quese incluyen en la propuesta del IEEE TCPP sobrela computación paralela en estudios de informática.La propuesta del TCPP analiza una gran cantidadde tópicos, y para nuestro análisis se han agrupadoalgunos tópicos, de manera que se generan tablasmás pequeñas. Para cada uno de los tópicos analizamossi se trata en las asignaturas comunes delGII, y con qué profundidad se trata. Volvemos aseñalar que nuestras conclusiones son muy subjetivas,pues la mayoría de las asignaturas no se estánimpartiendo todavía. También analizamos la intensificaciónen cada uno de los tópicos que se realiza encada una de las especialidades. Al igual que se haceen la propuesta del TCPP, agrupamos los tópicosen Arquitectura, Programación, Algoritmos y TemasTransversales. El análisis se resume en las figuras 6(Arquitectura), 7 (Programación), 8 (Algoritmos) y9 (Temas Transversales), donde los tópicos aparecenen inglés por su correspondencia con la propuesta delTCPP. En todas las figuras, los colores verde, amarilloy rojo representan la profundidad con la que setrata cada uno de los tópicos en las asignaturas comunes.Verde significa que el tópico es una partecentral de alguna asignatura común, amarillo indicaque el tópico se trata en alguna asignatura común,pero que no es parte central de ninguna, y rojo indicaque no se incluye en ninguna de las asignaturas comunes.Para los tópicos que se tratan someramente(amarillo) se indican las especialidades en las quese estudian en más profundidad. En nuestra propuesta,cuando se incluye un tópico en una intensificacióndebe tratarse como parte central en algunaasignatura (C, de core). Para cada universidad, se indicapara cada tópico tratado en una intensificaciónJP2011-592

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011si se trata en profundidad en alguna asignatura (C),o si no se profundiza en él (N, de non-core).Fig. 8. Tópicos de Algoritmos en el Grado de IngenieríaInformática.Fig. 6. Tópicos de Arquitectura en el Grado de IngenieríaInformática.Fig. 9. Tópicos de temas transversales en el Grado de IngenieríaInformática.Fig. 7. Tópicos de Programación en el Grado de IngenieríaInformática.Comentamos los tópicos que aparecen en las figuras:• Pensamos que todos los tópicos de arquitecturasparalelas deben tratarse en las asignaturas comunes,y prácticamente todos se tratan con lasuficiente profundidad en las cuatro universidades.El único tópico que no se trata tan enprofundidad es el de Heterogeneidad.• Los tópicos básicos de programación paralela(nociones básicas de concurrencia,sincronización, hilos, comunicaciones,cliente/servidor, etc.) deberían tratarse enprofundidad en asignaturas obligatorias, juntocon algunas herramientas de programaciónparalela tanto de memoria compartida comode paso de mensajes, y algunos conceptosde medidas de prestaciones. El resto de lostópicos de programación también se trataríanen asignaturas obligatorias, pero en menorprofundidad. En todas las universidades seintensifica suficientemente en estos tópicos enla especialidad de Ingeniería de Computadores,pero la única universidad que parece cubrirnuestra propuesta en las asignaturas comuneses la de Granada, mientras que la situación enel resto de universidades está lejos de lo queconsideramos deseable.• La situación en cuanto a los tópicos de algoritmoses incluso peor. Consideramos que todosestos tópicos deben ser obligatorios para todoslos estudiantes, y que la mayoría de ellos deberíantratarse en profundidad. Muchos de estostópicos no se tratan en las asignaturas comunesen nuestras universidades, y la propuesta quehacemos para las especialidades se cubre sóloparcialmente. Las universidades de Granada,Murcia y Politécnica de Valencia incluyen estostópicos en la especialidad de Ingeniería de Computadores,y las de Granada y Murcia tambiénlos incluyen en la de Ingeniería del Software. Laúnica universidad que trata estos temas en la especialidadde Computación es la de La Laguna.• La situación en cuanto a temas transversales ogenerales es más diversa. Algunos tópicos deberíantratarse en profundidad en asignaturasJP2011-593

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011comunes, y de otros se podrían dar algunas ideasbásicas. Adicionalmente, proponemos intensificaciónen las especialidades (excepto en la deComputación) en algunos de los que no se tratanen profundidad en los cursos comunes. En laUniversidad Politécnica de Valencia la mayoríade los tópicos se tratan en profundidad en asignaturascomunes, y en las otras universidadesla mayoría de los tópicos que no consideramosfundamentales no aparecen en asignaturas comunes,pero se tratan en las especialidades.V. Conclusiones y posibles colaboracionesEn este trabajo hemos realizado una revisión delos contenidos de computación paralela en los planesde estudio del Grado en Ingeniería Informática encuatro universidades (Granada, La Laguna, Murciay Politécnica de Valencia), y se ha analizado eltratamiento previsible en las asignaturas comunesy en las distintas especialidades de los diferentestópicos que se incluyen en la propuesta del IEEETCPP. El estudio es parcial y aproximado: comprendesólo cuatro universidades y se están impartiendoúnicamente el primero o los dos primeros cursosdel grado.Consideramos que la situación actual de la computación(que se ha convertido en paralela al ser paralelosloc componentes básicos de los sistemas computacionalesactuales), junto con la reorganizaciónde los estudios universitarios de informática y laaparición de la propuesta del IEEE TCPP, hace quesea conveniente repensar cómo y qué contenidos decomputación paralela se deben incluir en los planesde estudio del GII. Hemos identificado algunas deficiencias(en nuestra opinión) de la planificación de lacomputación paralela en los estudios de informáticaen España, y realizamos algunas propuestas paracorregir esas deficiencias.Nuestro análisis es parcial, aproximado y sesgado(nuestro punto de vista está condicionado por lo quecada uno de nosotros entendemos como computaciónparalela), por lo que proponemos a otros profesoresque puedan estar interesados en la docencia del paralelismoque compartan su experiencia con nosotros,por ejemplo, corrigiendo nuestra visión de la organizaciónde la docencia de la computación paralela enlas universidades analizadas, haciendo propuestas demodificación de nuestra propuesta, haciendo análisissimulares para otras universidades, etc. La finalidadde este trabajo es propiciar la discusión (y consecuentementela mejora) sobre cómo enseñar computaciónparalela, de manera que formemos a nuestrosalumnos para trabajar con el tipo de sistemascon los que se van a encontrar al acabar sus estudios.Este trabajo ha sido parcialmente financiado porla Consejería de Educación de la Región de Murcia(Fundación Séneca, 08763/PI/08) y por el Ministeriode Ciencia e Innovación (TIN2008-06570-C04).Queremos agradecer a los compañeros de los distintosdepartamentos de informática de las universidadesde Granada, La Laguna, Murcia y Politécnicade Valencia que nos han asesorado en la identificaciónde las asignaturas donde se tratan o tratarán losdistintos tópicos que aparecen en la propuesta delTCPP.Referencias[1] IEEE Technical Committee on Parallel Processing,http://tcpp.cs.gsu.edu/.[2] Francisco Almeida, Domingo Giménez, José Miguel Mantasy Antonio M. Vidal, Introducción a la programaciónparalela, Paraninfo Cengage Learning, 2008.[3] Domingo Giménez, Francisco Almeida, José Miguel Mantasy Antonio M. Vidal, “Sobre la situación de la programaciónparalela en los grados de informática,” ReVisión:Revista Hispanoamericana de Educación Universitaria dela Informática, vol. 3, no. 1, pp. 11–21, 2010.[4] Francisco Almeida, Domingo Giménez, José-Miguel Mantasand Antonio M. Vidal, “On the integration ofthe Curriculum Initiative on Parallel and DistributedComputing in the Spanish university system,” inFirst NSF/TCPP Workshop on Parallel and DistributedComputing Education (EduPar-11), 2011.[5] David J. Meder, Victor Pankratius and Walter F.Tichy, http://www.multicore-systems.org/separs/downloads/GI-WG-SurveyParallelismCurricula.pdf,2008.[6] G. Brassard and P. Bratley, Fundamentals of Algorithms,Prentice-Hall, 1996.[7] Thomas H. Cormen, Charles E. Leiserson and Ronald L.Rivest, Introduction to Algorithms, The MIT Press, 1990.[8] ACM, Curricula recommendations, http://www.acm.org/education/curricula-recommendations.AgradecimientosJP2011-594

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Experiencias en Docencia de Diseño yEvaluación de ConfiguracionesA.M. Mora, P. García-Sánchez, P.A. Castillo, M.G. Arenas, J.J. Merelo, J. Ortega 1Resumen— El presente trabajo expone las experienciasdocentes de los profesores de la asignatura Diseñoy Evaluación de Configuraciones (optativa de las IngenieríasTécnicas en Informática en la Universidad deGranada), durante los últimos cinco años. Dicha asignaturaestá encuadrada dentro del área de Arquitecturay Tecnología de Computadores y tiene como objetivomostrar una metodología para la evaluación deprestaciones (o rendimiento) de un computador. Sedivide, a grandes rasgos, en tres partes: la primer dedicadaa los monitores (encargados de medir la cargade un ordenador), la segunda enfocada a la mejora deprestaciones (de un equipo informático), y la últimadedicada a la reproducción de la carga de un computador(los llamados benchmarks). Del mismo modo, enel artículo se presentan una serie de herramientas utilizadaspara gestionar dicha asignatura, así como parafacilitar, tanto a los alumnos, como al profesor, todaslas tareas propias de la misma.Palabras clave— Diseño y Evaluación de Configuraciones,Docencia, Benchmark, Monitor, Rendimiento,Profiler, Wiki, BlogI. IntroducciónLA asignatura Diseño y Evaluación de Configuracionestiene como objeto de estudio los sistemasinformáticos, es decir, cualquier sistema queuse medios informáticos, abarcando, todos los sistemassituados en diferentes niveles del modelo decapas OSI [12]: desde la más baja, la física, hasta lamás alta, la de aplicación; junto con las diferentes capasde un sistema operativo. Desde el punto de vistade esta asignatura, un sistema puede ser tanto unchip, una tarjeta de red, o una red completa, comoun programa que ofrezca servicios en esa red, o elprograma junto con todo el sistema necesario paraejecutarse.Durante el ciclo de vida de un sistema informático,resulta muchas veces necesario evaluar sus prestacioneso rendimiento, habitualmente con el objetivode mejorarlas o bien de comparar diversos sistemasinformáticos entre sí. Esa evaluación de prestacionesse debe hacer de forma objetiva, a fin de poder comparardistintos valores a lo largo del tiempo o bienel mismo valor para diversos sistemas informáticos.Tales mediciones pueden servir también para identificarlos problemas que tiene un sistema informático,con el objetivo de solucionarlos.Esta asignatura se ha convertido en los últimosaños en una de las más exitosas en cuanto al númerode alumnos matriculados dentro de las asignaturasoptativas de las Ingenierías Técnicas Informáticas enla Universidad de Granada. Gran parte de su éxito1 Departamento de Arquitectura de Computadores.ETSIIT, CITIC. Universidad de Granada. e-mail:{amorag,fergu,pedro,mgarenas,jmerelo}@geneura.ugr.es,julio@atc.ugr.esse basa tanto en la novedosa forma de evaluación alos alumnos, no fundamentada en exámenes, sino ensu trabajo en clase, como en la orientación que se hadado a la misma, primando la parte práctica sobrela teórica. Otro factor relevante ha sido la formade trabajo, centrada en el uso de herramientas webampliamente conocidas y extendidas, a la par quellamativas para los alumnos (como Sistemas web deayuda a la docencia, Wikis, Blogs o Foros).En este trabajo detallareos la estrategia de evaluación,así como el modo de funcionamiento e integraciónde las herramientas en la asignatura.II. Diseño y Evaluación de ConfiguracionesEn esta sección se describen los temas teóricos yprácticos de la asignatura.A. TeoríaA.1 Tema 1: Sistemas informáticos y su evaluación.En este primer tema se analizan las diferentesmagnitudes observables de un sistema informático ycomo se pueden medir, con una serie de ejemplos queindican como se hace en diversos sistemas operativos,como UNIX y Windows.Inicialmente se realiza una introducción a los sistemasinformáticos y las fases en la evaluación deestos sistemas. El siguiente apartado explica cómoelegir las métricas [7] de prestaciones y las distintastécnicas de evaluación. El último apartado deeste tema explica cómo monitorizar la carga de unsistema y explica varias formas de hacerlo utilizandovarios monitores, tanto para monitorizar el hardware(ver Figura 1), como el software (mediante un profiler)[6].A.2 Tema 2: Representación gráfica de las prestacionesde los sistemas.Para presentar y analizar los resultados obtenidosde la ejecución de un monitor sobre un sistema,o una comparativa entre varios sistemas, normalmentese usa algún tipo de gráfico, como por ejemplográficos de barras de evolución temporal (las llamadasstrip chart). Más habitualmente, para resumirel rendimiento de todo el sistema se suele usarun diagrama de Gantt [11], [4], o bien un gráfico deKiviatt [4].En esta parte de la asignatura también se explicanalgunos de los errores comunes en la representacióngráfica de resultados, así como unas reglas y consejospara realizar dichas representaciones gráficas.JP2011-595

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.Monitor de Windows NT. Este monitor da información del sistema en tiempo real.A.3 Tema 3: Mejora de prestaciones.Este tema está principalmente dedicado a examinarqué elementos pueden fallar (o estar sujetos aerror) en un equipo informático [5], principalmenteUnix o Windows NT, qué herramientas se usan parael diagnóstico, y una vez diagnosticado, qué medidashay que tomar para mejorar las prestaciones.• Gestión de carga y prestaciones en el sistemaoperativo• Políticas de gestión del sistema• Mejora de prestaciones de la CPU• Sintonización de la memoria• Mejora de prestaciones en entrada/salida• Optimización de un servidor webA.4 Tema 4: Caracterización de la carga: benchmarks.En este tema se explica qué es lo que se tiene quetener en cuenta para medir la carga de un equipo, yqué es un benchmark [6], el cual es un programa oconjunto de programas que evalúan las prestacionesde un sistema informático, reproduciendo una cargade trabajo genérica o específica en dicho sistema informático.Al proceso de comparar dos o más sistemasmediante la obtención de medidas se le denominabenchmarking.En general, para evaluar las prestaciones de unsistema informático es necesario conocer y caracterizarpreviamente cuál es la carga de trabajo, comose habrá visto en temas anteriores. Sin embargo, enmuchos casos tal carga no se conoce de antemano,es difícil de caracterizar o es suficientemente ampliacomo para considerarla una carga genérica.En esta sección se explican los pasos para diseñar oescoger un buen benchmark, siguiendo lo propuestopor [10], así como los tipos que existen y las métricasy errores más comunes. Finalmente se presentan algunosejemplos de benchmarks, como son los propuestospor la SPEC 1 (Standard Performance EvaluationCorporation) o LINPACK, que son los utilizadospara medir la lista de los computadores máspotentes o Top 500 2 .B. PrácticasEsta sección explica las distintas prácticas que losalumnos deben realizar para superar la asignatura.Por regla general, para realizar estas prácticas hayque seguir la metodología de la asignatura, es decirproponer un objetivo, hacer medidas, diagnosticar,proponer una solución, volver a tomar medidas, ycomparar el sistema viejo con el sistema nuevo.B.1 Práctica 1: Búsqueda de recursos relacionadoscon la asignatura.Esta primera práctica consiste en buscar sitios webo referencias bibliográficas (libros, revistas, artículos,noticias, etc) o cualquier otra fuente donde se puedaencontrar información útil relacionada con los temastratados en la asignatura.B.2 Práctica 2: Instalación y configuración de sistemasde medición de prestaciones.Utilizando los recursos de la práctica anterior, estapráctica consiste en descargar de Internet monitores(de prestaciones), y configurarlos e instalarlos paramedir las prestaciones del ordenador personal delalumno o bien de los ordenadores de las aulas deprácticas.B.3 Práctica 3: Uso de un profiler.Se hará uso de uno de estas herramientas paraevaluar las prestaciones de un programa propio re-1 http://www.spec.org2 http://www.netlib.org/benchmark/top500.htmlJP2011-596

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011alizado en cualquier lenguaje, y ver en qué puntosse está empleando más tiempo, para que, a partir deahí, se busquen modos de mejorarlo. Se tendrá quebuscar cómo configurarlo, como hacerlo funcionar, yfinalmente, usarlo. La Figura 2 muestra la ejecuciónde un profiler sobre un programa Java realizado porun alumno.B.4 Práctica 4: Uso de programas de monitorizaciónde un sistema.Esta práctica consiste en la definición de unacarga computacional, y la utilización de herramientasde monitorización del sistema para visualizar cómoejercita al sistema esas cargas. Estas herramientaspresentan medidas del mismo en tiempo real,permitiendo medir y cuantificar su carga, medir suevolución y predecir su comportamiento. La herramientade monitorización la elegirá el alumno enfunción de lo hecho en otras prácticas (especialmentela segunda) y de su adecuación para las magnitudesque desee medir.B.5 Práctica 5: Mejora de las prestaciones de unsistema.Se trata de poner en práctica lo aprendido en elTema 3 de la asignatura sobre mejora de prestacionesde sistemas informáticos y aplicarlo a un caso determinado.Por ejemplo, modificar un programa paraque consuma menos recursos o cambiar la configuraciónde un servidor web para que procese mejor lacola de peticiones. Una vez establecido el objetivo, setomarán medidas de, al menos, un aspecto, antes derealizar ningún tipo de diagnóstico, con la carga detrabajo con la que se vaya a hacer la práctica. Ésteserá el sistema base. En función de esto, se decidiráqué medidas tomar para mejorar las prestaciones delsistema.B.6 Práctica 6: Programación de un benchmarkportable.En ella se hace énfasis en la programación independientede la máquina, y se trata de, utilizandoun lenguaje de alto nivel, comparar las prestacionesde diferentes máquinas o de la misma con diferentessistemas operativos. En resumen, el alumno realizaráun programa en un lenguaje de alto nivel que permitamedir y comparar las prestaciones de dos sistemas.Comparar, por ejemplo, diferentes equiposcon diferentes sistemas operativos, o el mismo equipocon dos sistemas operativos diferentes. Como entodas las prácticas, hay que establecer claramentecuál es el objetivo del benchmark, obtener resultados,analizarlos, presentarlos y obtener un índiceque indique qué sistema es mejor para los objetivosplanteados.C. EvaluaciónLa evaluación de la asignatura se realiza comosigue:• 1/6 de la nota será nota de clase (participaciónen actividades y ejercicios de autoevaluación)• 2/6 de la nota corresponderá a la media ponderada(por sesiones) de la nota obtenida enprácticas• 3/6 de la nota será la correspondiente a un trabajofinal, entregado al término de las clases,que agrupará todo lo aprendido para evaluar ymejorar un sistema a elección del alumno, perode cierta ’entidad’Como se puede ver, no existe ningún tipo de examena lo largo de la asignatura y únicamente sevalora el trabajo de los alumnos (tanto en clase,como en casa). Este tipo de evaluación resulta bastanteexitosa y, a tenor de lo demostrado por losalumnos, éstos retienen gran parte de los contenidos(conocimientos adquiridos).III. Herramientas utilizadas en laasignaturaEsta asignatura ha sido pionera en varias facetasde compaginación de herramientas y utilidades webdentro de las clases, permitiendo, e incluso fomentandoel uso del ordenador portátil en las aulas (llegandoincluso a proveer de varios de estos portátilesa los alumnos).El objetivo que se persigue es el de involucrarlosen mayor medida en las clases, haciendo que tomenapuntes y notas en un Wiki de la asignatura (páginaweb dinámica en la que se generan contenidos entrelos usuarios de la misma) (http://dyec-ugr.wikispaces.com/), que todos los demás (incluidoel profesor) podrán consultar y completar posteriormente.El uso de wikis en docencia ha sido estudiadopor [1], entre otros. De esta forma, el conocimientogenerado (siguiendo la filosofía de los wikis) va siendocada vez más completo y riguroso, uniendo además elpunto de vista que los alumnos le quieran dar parafacilitar su comprensión. Los alumnos encargadosde estas labores reciben parte de la nota de participaciónen clase como premio.El profesor además, hace uso de dicho Wiki paraponer ejemplos y ejercicios, que los alumnos realizan,comentan y corrigen. Esta experiencia ha demostradoser ampliamente aceptada en la comunidadestudiantil, como puede verse en [3], [2].Por otra parte, otro aspecto fomentado es lacreación de Blogs de alumnos, en los que se describanlas inquietudes, intereses, enlaces y trabajos de losmismos en relación a la asignatura. Esto suele teneruna buena acogida, y de hecho, muchos siguen manteniendosu blog en adelante. Además, se insta a losalumnos a que hagan la entrega de sus prácticas enformato HTML (páginas web), pudiendo colgarlas enel futuro en un servidor web.La otra herramienta utilizada es SWAD: SistemaWeb de Apoyo a la Docencia (http://swad.ugr.es)[9], [8], una plataforma libre de teleformación desarrolladay utilizada en la Universidad de Granada enlos últimos 11 cursos académicos. SWAD integra diversasfunciones de apoyo al aprendizaje, a la docenciay a la gestión de los datos de los estudiantes. Entreellas el acceso a información sobre las asignaturasJP2011-597

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2.Captura de pantalla del profiler para Java incluido en el editor NetBeans.(guía docente, horarios, bibliografía,...), la descargade documentos (transparencias, relaciones de problemas),las listas y fichas de alumnos y profesores, losforos de discusión, la asignación de actividades, laautoevaluación mediante exámenes interactivos o laconsulta individual de calificaciones.En dicha plataforma se hace el seguimiento de losalumnos, la publicación de los temarios y guionesde prácticas, la entrega de ejercicios, trabajos yprácticas, y la publicación (con consulta individual)de la notas.Respecto al software a utilizar en la asignatura,todo el propuesto y presentado en secciones anterioreses software libre (o tiene alternativa libre), dehecho se fomenta también la búsqueda de nuevas utilidadesde libre distribución, con lo que el coste parael alumno es nulo.Todas estas herramientas y las peculiaridades oventajas del sistema de evaluación, hacen de la asignaturauna de las más populares entre las optativas,contando generalmente con un gran número de alumnosen cada curso académico.IV. Conclusiones y Trabajos FuturosEn este trabajo se ha presentado la asignaturaDiseño y Evaluación de Configuraciones (optativa delas Ingenierías Técnicas en Informática en la Universidadde Granada), encuadrada dentro del área deArquitectura y Tecnología de Computadores.En este trabajo se detallan los temarios teóricos yprácticos de la misma, así como las estrategias docentesutilizadas en su impartición en los últimos cursos.Con la entrada de los títulos de Grado, esta asignaturaacabará extinguiéndose, para dar entradaa dos asignaturas directamente relacionadas, Ingenieríade Servidores y Servidores Web de AltasPrestaciones, en las cuales se espera poder utilizarlas mismas herramientas y aplicar las estrategias docentesque hemos presentado.AgradecimientosEste trabajo se ha llevado a cabo dentro de losproyectos TIC-3903 de la Junta de Andalucía y CEIBioTIC GENIL (CEB09-0010) del Programa CEI delMICINN (PYR-2010-13).Referencias[1] Bergin, J. Teaching on the wiki web. En ITiCSE ’02:Proceedings of the 7th annual conference on Innovationand technology in computer science education, pages 195–195, New York, NY, USA, 2002. ACM Press.[2] Merelo-Guervós, J.J. Castillo, P.A. y Priento, A. Integraciónde una asignatura en Internet: el caso de Diseño yEvaluación de Configuraciones. En Actas JENUI´01, VIIJornadas de Enseñanza Universitaria de la Informática,2001.[3] Merelo, J.J., Hassan-Montero, C., Tricas, F. y Jiménez,J.L. Anonym: SWECAI: Sistema web centrado en elalumno inteligente. En Actas de las XIII Jornadas deEnseñanza Universitaria de Informática (JENUI), pages1–2, 2007.[4] Jain, R. The art of computer systems performance analysis:techniques for experimental design, measurement,simulation, and modeling, volume 491. Wiley New York,1991.[5] Lilja, D.J. Measuring Computer Performance. CambridgeUniversity Press United Kingdom;, 2000.[6] Loukides, M.K. System performance tuning. O’Reilly &Associates, Inc. Sebastopol, CA, USA, 1996.[7] Molero, X., Juiz,C., y Rodeño, J. Evaluación y modeladodel rendimiento de los sistemas informáticos. Pearson Education,2004.[8] Cañas, A. Díaz, A.F. y Priento, A. Sistema de serviciosweb de apoyo a la docencia y gestión de una asignatura.Actas de las VIII Jornadas de Enseñanza Universitariade la Informática (JENUI’2002), 2002.[9] Cañas, A. y Ortigosa, E.M. y Aragón, Y. La plataformaSWAD como recurso docente para la innovación educativa.En Congreso internacional sobre el profesoradoante el reto de las nuevas tecnologías en la sociedad delconocimiento, 1235.[10] Puigjaner, R., Serrano, J.J. y Rubio, A. Evaluación yexplotación de sistemas informáticos. Síntesis, 1993.[11] Wikipedia. Diagrama de gantt.http://es.wikipedia.org/wiki/Diagrama de Gantt.[12] Zimmermann, H. Osi reference model. IEEE Transactionson Communications, 28(4):425–432, April 1980.JP2011-598

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Diseño de un cluster de computadores comoactividad para Arquitectura de ComputadoresF. Javier Fernández-Baldomero 1 y Mancia Anguita 1Resumen— Esta contribución describe una actividad deaprendizaje basado en proyectos realizada los dos últimosaños en una asignatura universitaria de Ingeniero enInformática, consistente en el diseño, compra, montaje,instalación, configuración y explotación de un pequeñocluster de computadores orientado a cálculo científico. Eldiseño inicial consistió en 3 nodos Core i7 con switch KVMy GbE montados en rack. El segundo año se añadió unservidor SAN y un switch Infiniband. Se describe elmétodo aplicado para desarrollar y evaluar la actividad, elcluster diseñado por los estudiantes y su configuraciónsoftware, así como los resultados de encuestas de opiniónde los estudiantes que participaron, posibles variacionespara futuras ediciones de la experiencia, y las conclusionesalcanzadas con la realización del proyectoPalabras clave— Aprendizaje basado en proyectos,Clusters, Computación paralela.EI. INTRODUCCIÓNL Aprendizaje por Proyectos [8] es un métododocente ampliamente reconocido por su capacidadpara estimular la participación de los estudiantes ymantenerlos motivados hacia la asignatura. Comocaracterísticas básicas distintivas del método se puedendestacar el menor énfasis en la enseñanza mecánica ymemorística para dedicarse a un trabajo más retador ycomplejo, el enfoque interdisciplinario (apropiado a untrabajo complejo) en lugar de orientado al área oasignatura, y el trabajo cooperativo frente al individual.Adoptar el método puro de Aprendizaje basado enProyectos implicaría una fuerte coordinación entre elprofesorado de las distintas asignaturas implicadas [5][9], y eventualmente una reforma completa en laestrategia docente de la titulación. En este trabajo hemosoptado por introducir un pequeño proyecto voluntario ennuestra asignatura “Arquitectura de Computadores II”(ACII) de 5º curso de Ingeniero en Informática, con laintención obvia de mejorar la motivación de losestudiantes, y en segundo término para observar laactitud de los mismos ante lo que podría ser una prácticade las nuevas asignaturas en los próximos planes deestudio de los Grados.En la Sección II se resume en qué consiste el trabajo ycómo se puntúa. En las secciones III y IV se muestra elresultado (hardware y software) del proyecto, esto es, elcluster diseñado por los estudiantes y su configuraciónsoftware. La Sección V muestra los resultados de lasencuestas rellenadas por los estudiantes. Por último, laSección VI resume posibles variaciones del proyecto yla Sección VII las conclusiones.1 Dpto. Arquitectura y Tecnología de Computadores, Universidad deGranada, e-mail: {jfernand,manguita}@ugr.esII. ENUNCIADO, EVALUACIÓN Y DESARROLLO DE LAACTIVIDADAl plantearse como actividad voluntaria y nopresencial, el enunciado se proporcionó anticipadamentea los estudiantes a través de la web de los profesores [6].Básicamente, se proponía diseñar el cluster orientado ala ejecución de aplicaciones científicas en un plazo de 5semanas, para posteriormente instalarle el S.O., pasarlebenchmarks (para comprobar si las prestaciones eran lasesperadas según el diseño) y que diera tiempo a ejecutaren él las prácticas de programación paralela de laasignatura antes de que acabara el curso. Las prácticasde la asignatura estaban orientadas principalmente a laprogramación paralela y evaluación de prestacionesaunque en la asignatura también se estudian loscomponentes de un computador paralelo. Lafinanciación de 3.650€ corrió a cargo del Plan deInnovación Docente de la UGR [7].Las normas de evaluación de la asignatura se alteraronde la forma indicada en la Tabla 1. Las ventajas para losestudiantes que participaran eran un menor umbral paraaprobar, y un tope de nota algo mayor (11 puntos). Sejustifica esta bajada del umbral y subida del máximo enque el estudiante tiene que dedicar horas de trabajo de laasignatura al proyecto del cluster en lugar de al resto deactividades de la asignatura.TABLA 1. PUNTUACIÓN DE ACII EN LOS CURSOS 08/09 Y 09/10.2008 / 2009 2009 / 2010resto clase grupo clusterActividad max umbral max umbral max umbralExamen 7.0 3.5 5.0 1.5 7.0 3.00Prácticas 3.0 1.5 3.0 1.0Proy. Cluster 3.0 1.03.0 1.25Suma 10.0 5.0 11.0 3.5 10.0 4.25Se decidió añadir 3 puntos adicionales, por el trabajorealizado en el Proyecto Cluster (2p) y un cuestionariofinal sobre el mismo (1p), mantener los 3 puntos deprácticas, y prorratear a 5 puntos el examen de teoría.A pesar del cambio de umbrales en la encuesta delcurso 2008/09 los estudiantes que participaron en elproyecto cluster opinaron que el trabajo era excesivo.Por este motivo, en el curso 2009/10, hemos preferidoplantear el proyecto (instalación, configuración,evaluación y explotación del cluster) como alternativa alas prácticas normales (Tabla 1). La alternativa sedenominó “Centro de Procesamiento de Datos”, dando aentender que esta actividad u otras similares podríanpracticarse en la futura asignatura de Grado de dichonombre.Para supervisar el desarrollo de la actividad se hautilizado el sistema SWAD de la UGR [1] [2] [3],JP2011-599

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011aprovechando el foro para comunicación profesoresestudiantes(Figura 1) y la zona común de archivos paraentregar documentos de trabajo (Figura 2). En el curso08/09 se enviaron 16 trabajos y 348 posts (58 de losprofesores).La web de la actividad [6] sugería unas cuantasactividades que los estudiantes podían realizarautónomamente (Tabla 2) y apuntaba algunas webs defabricantes y vendedores de donde obtener informaciónpara realizar los diseños. La web se ha utilizado tambiénpara ir anotando comentarios y resumiendo lasaportaciones realizadas a lo largo del proyecto.La experiencia del curso 2008/09 ha permitidoaquilatar de forma más precisa la cantidad de trabajo quelos estudiantes consideran apropiada para 3 puntos decalificación, de forma que en el curso 2009/10 sólo se haplanteado la instalación, configuración, evaluación yexplotación del cluster ya montado. Las actividades serealizaban presencialmente en horario de prácticas ytutorías, sobre el cluster real, anotando los profesores lastareas en las que cada estudiante participabaactivamente. Los estudiantes realizaron su informe [4]como documento GoogleDocs, también enlazado en laweb del Proyecto [6].Ya sea como actividad voluntaria adicional (curso2008/09) o alternativa (2009/10) a las prácticasnormales, nos ha sucedido que pocos estudiantesescogen el proyecto, razonando que implica realizar mástrabajo que las prácticas normales para obtener la mismanota. En el curso 2008/09 participaron 15 estudiantes deun total de 150 (10%), y en el 2009/10, 7 de un total de134 (5%).En el curso 2008/09 la etapa de diseño colaborativo enel foro no convergió a un diseño consensuado. Habíados opiniones distintas: una que apuntaba adquirir nodoscon una buena GPU a consta del resto de componentes,y la otra que opinaba lo contrario argumentando unamejor relación prestaciones/precio. Lo que se hizofinalmente es agrupar a los estudiantes en dos grupos yque cada uno presentara una propuesta detallada yjustificada por escrito apoyándose en el trabajo realizadoen el foro. Paradójicamente, los dos diseños entregadosfueron virtualmente idénticos (hay que tener en cuentaque el foro se discutieron las prestaciones y precio detodos los componentes: procesador, chasis, fuente dealimentación, cables, etc.).La etapa de instalación de software tuvo másincidencias, lo cual sirvió de argumento para dedicarleplena atención en el curso siguiente (sección 4).Básicamente, nos proponíamos elucidar si dichasincidencias se debían a una falta de habilidades de base,o a un exceso de tarea. Ambos motivos podrían sercausa de la baja participación. En el curso 2009/10 seresaltó que el proyecto consistía exclusivamente eninstalar, configurar y evaluar el cluster, y administrarlodurante el periodo de explotación (las últimas semanasdel curso) para que los restantes compañeros pudieranejecutar en él los programas paralelos realizados comoprácticas. Como ya se ha indicado, las actividades se hanrealizado presencialmente, anotando el profesor laparticipación de cada estudiante. Los estudiantes nomostraron discrepancias con el desarrollo del proyectodurante las sesiones presenciales.Figura 1. Foro SWAD usado para el diseño, curso 2008/09.Figura 2. Zona común de trabajos SWAD, curso 2008/09.TABLA 2. ALGUNAS CTIVIDADES DEL PROYECTO (08/09), Y SUPUNTUACIÓN APROXIMADA.Actividadpuntosaportar componente, precio, caract.técnicas (en el foro) 0.1-0.3matizar aportación previa (€, caract. o conceptos clase) 0.1-0.3encontrar defectos de diseño en aportaciones previas 0.1-0.2encontrar oferta similar a diseño aportado 0.1-0.2relacionar faceta diseño con conceptos estudiados clase 0.1-0.2documentar instalacion / configuración de software 0.3tarea de instalación / configuración de un software 0.3otrassegúnIII. CLUSTER DISEÑADO POR LOS ESTUDIANTESEn el curso 2008/09 se realizó una reunión tras losdiseños presentados por los dos grupos de estudiantescon el fin de afinar algunos detalles, tras la cual serealizó la primera compra por un precio de 3000€ aprox.(Tabla 3). El resto del presupuesto se liquidóposteriormente, tras haber montado el cluster ycomprobado su correcto funcionamiento. El colchón de500€ hubiera permitido reponer algún componente vitalsi se hubiera estropeado durante el montaje. Al no surgirninguna contingencia, se utilizó para darle un acabadoprofesional al equipo (Tabla 4). En la Figura 3 se puedever el cluster ACII con todos los componentes instalados(incluyendo los detalles de acabado como termostato,panel de parcheo, cepillos pasacables…), las puertasJP2011-600

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011retiradas y los nodos parcialmente extraídos. Es posibleapreciar un antiguo switch FastEthernet (del que ya sedisponía) entre el panel de parcheo y el switch GbE,muy útil para comparar prestaciones.TABLA 3. COMPONENTES BÁSICOS DEL CLUSTER ACII.ComponenteCPU Intel Core i7-920Placa Madre ASUSP6T SEKit Memoria 6GBDDR3 1066 KVR-N7K3Switch GbE TL-SG1016Tarjeta GbE D-Link DGE-530Tcant precio3 734,973 662,313 284,971 76,991 18,99TABLA 4. DETALLES DE ACABADO DEL CLUSTER ACII.Componente cant precioGuías lateralestelescópicasPanel de parcheo24x RJ-45HerramientaImpacto3 91,111 63,281 27,42cable parcheo1m 4 4,84bolsa tornilleríaM6TermostatoDigital 1U1 26,261 137,47cable RJ-45 Cat63mKVM Level-OneKVM-0410cable KVM PS/21.8mHDD 500GBSATA-II4 15,081 89,004 16,003 143,97Regleta 19” 6tomasPasacable 1Ucepillo/peineAnilla guiacable1U horizontalAnilla guiacable1U verticalCable TwisTies30m1 49,962 50,348 31,688 31,681 2,96Total 517,00Grabador DVDSATA1 24,44Lector DVD SATA 2 27,84FuenteAlimentación500WTarjeta VGA PCIeGF7200 256MB3 84,873 76,77Monitor LCD 19”LG W1941STeclado LogitechPS/2Ratón Logitechóptico PS/21 99,991 7,541 5,40Armario 19” 22U 1 434,90Caja Rack 19” 4U 3 236,70Regleta 19” 8tomas1 48,60Total 3089,33Figura 3. El cluster ACII con los detalles de acabado.JP2011-601

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011IV. CONFIGURACIÓN SOFTWAREAunque en el curso 2008/09 se realizaron trabajosescritos sobre instalación de software, en la etapa deinstalación surgieron incidencias difíciles de reconducir.Restrospectivamente, deberíamos haber previsto el casoen que el responsable de una instalación no la lleva acabo, ya sea por falta de tiempo o cualquier otra razón.Para distinguir si este problema se debió a un excesode tarea o a una carencia formativa (y aprovechando queel cluster ya estaba montado), al año siguiente laactividad se simplificó, limitándose a instalación,configuración, evaluación y explotación del cluster.Para evitar la situación de que un solo estudiantepudiera bloquear el proceso de instalación, se propusorepartir el trabajo de forma que al menos dos estudiantesse responsabilizaran de cada tarea. Aunque losestudiantes prefirieron organizarse entre ellos,comprometiéndose a que el cluster estuviera operativoen la fecha indicada.Para evitar la situación del estudiante que hace untrabajo escrito sin sentirse comprometido a que elproceso de instalación y configuración descrito debafuncionar, o a que se deban resolver los problemas quesurjan más tarde relacionados con su uso, se propusoque todo el trabajo fuera presencial, y que se fueragenerando un diario o bitácora, para disponer de unareferencia que permitiera reproducir todo el trabajorealizado.En el curso 2009/10 los estudiantes que escogieron elproyecto realizaron la instalación del Sistema OperativoDebian con servidor DHCP y firewall IPTables, clonadode nodos con CloneZilla, paso de mensajes con Open-MPI, sistema de colas Torque, monitorización Ganglia yautentificación LDAP. No dio tiempo a probar ningúnbenchmark, debido fundamentalmente a la cantidad desesiones dedicadas a instalar Torque y LDAP. Losprofesores sugirieron la instalación de algunadistribución Linux más apropiada para servidores, comoCentOS, pero los estudiantes prefirieron Debian.El cluster estuvo operativo en la fecha indicada sin quese produjeran incidencias durante las sesionespresenciales.V. RESULTADO DE LAS ENCUESTAS DE OPINIÓNEn ambos cursos, 2008/09 y 2009/10, se invitó a losestudiantes a rellenar un cuestionario anónimo destinadoa evaluar en qué medida se habían alcanzado losobjetivos del proyecto, y si se debía mantener elpróximo curso, con o sin modificaciones, o se deberíaeliminar. Estos objetivos del cuestionario se lescomunicaban explícitamente a los estudiantes en elpropio formulario. Las preguntas del cuestionario sepueden ver en la Tabla 5.De los 12 estudiantes que entregaron la encuesta en elcurso 2008/09, casi la mitad eran matriculados deprimera vez (5 de 12), frente al 100% (6 de 6) del curso2009/10. En la Tabla 6 se resumen las respuestas másfrecuentes, junto con su frecuencia. En general, losestudiantes opinan que la actividad les ha permitidoaprender y se debe mantener.En atención a las opiniones 2008/09, en 2009/10 seredujo drásticamente la cantidad de trabajo a realizar (ala parte software exclusivamente), se bajaron losumbrales mínimos, no se prorrateó el examen final, y sereplanteó el proyecto como unas Prácticas alternativas(en sustitución de las “normales”). Los 6 estudiantes queentregaron el cuestionario anónimo volvieron a opinarmayoritariamente que debería darse más nota, y que lapuntuación es injusta en comparación con las otrasPrácticas. Las calificaciones obtenidas se resumen en laTabla 7, para mostrar que no se trata de un caso deevaluación cicatera por parte del profesoradoRetrospectivamente, no se debería haber dado tantaimportancia a las opiniones positivas en 2008/09 sobrela libertad para escoger tarea, y se debería haberintervenido frecuentemente durante las sesiones (sindarle tanta importancia al ambiente distendido) pararecapitular sobre los hitos alcanzados y los quequedaban por cumplir. Cubrir las competencias de esteproyecto en una asignatura con temario propio resolveríamuchas de estas objeciones (participación, puntuación,organización, etc.).Por tener una cierta idea de la popularidad que pudieraalcanzar la web del Proyecto Cluster, se le añadió en sudía (Julio 2009) el tracker para las analíticas Google. Elnúmero de visitas que alcanzó en pocos meses nos hizoconsiderar la posibilidad de traducirla a inglés (Sept.2009). Ambas versiones de la web muestran distintaestacionalidad, como se puede comprobar en susgráficas de visitas (Figura 4, Figura 5). La versiónespañola ha llegado a acercarse recientemente a 50visitas semanales, mientras que la inglesa llegó a 40 elpasado 2º cuatrimestre, y no se consulta tanto en losprimeros cuatrimestres (15-20 visitas semanales, verFigura 5 a izquierda y derecha del tramo con más visitas,2º cuatrimestre 2010).TABLA 5. CUESTIONARIO ANÓNIMO DEL PROYECTO CLUSTER.Pregunta¿Es el primer año cursando la asignatura?El proceso de diseño cluster le ha permitido aprenderSe debe mantener este trabajo en la asignaturaJustifique 2 anteriores respuestas¿Qué es lo que más le ha gustado?¿Por qué?¿Qué cambiaría?En la forma de calificar al estudiante…¿qué cambiaría? ¿qué conservaría?VI. POSIBLES VARIANTES DE LA ACTIVIDADformatos/n-2…2-2…2librelibrelibrelibrelibreEn vista a futuras variaciones del proyecto, se puedeargumentar (mediante las encuestas recolectadas) quelos estudiantes desean una planificación rigurosa conhitos marcados en donde se obtenga puntuación que seconozca sobre la marcha, sobre un plan de trabajopreviamente fijado por los profesores. Sólo un pequeñoporcentaje de estudiantes prefiere un trabajo con máslibertad, frente a la mayoría que preferiría cambiar laorganización de la experiencia (5 de 6 en 2010). Laparadójica poca satisfacción con la nota obtenida (sólo 4de 12 en 2009, 2 de 6 en 2010, siempre 66%insatisfecho) indica que estos temas debieran cubrirse enuna asignatura con temario (y calificación) propios.La variación que quedaría por intentar sería realizarunos diarios detallados de instalación, temporizados porlos profesores, para eliminar radicalmente el argumentoJP2011-602

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA 6. RESULTADOS DE LA ENCUESTA ANÓNIMA.2008/2009 2009/2010Universo 12 6Primer año 41.7% (5 de 1er año / 7 repetidores) 100% (6 de 1er año)Aprender 1.42 (-2:1 -1:0 0:0 1:3 2:8) 1.50 (-2:0 -1:0 0:0 1:3 2:3)Mantener 1.33 (-2:1 -1:0 0:0 1:4 2:7) 1.33 (-2:0 -1:0 0:0 1:4 2:2)frec. respuesta frec. respuestajustificación 5x aplicar teoría 2x trabajo satisfactorio, interesante4x temas no cubiertos en otras asignaturas,motiva, interesa, es voluntario2x trabajo diferente,no cubierto en otras asignaturas3x aprender mediante la práctica,2x se aprende de los compañerostrabajar en grupogustado más 6x el clúster ha sido realforo (por su nivel, formato, ambiente)3x desarrollar capacidades profesiónútil para un futuro empleo3x los gruposaprender sobre componentes2x ver el cluster funcionandoir resolviendo problemas instal. / config.2x libertad para todo2x entorno distendido(escoger tarea, proponer componentes)qué cambiaría 6x que haya más participaciónmucho trabajo para tan poca nota4xque quede más claro al principio losobjetivos, puntuación, lista tareas,y que no es competitivo5x2xorganizar mejor: falta experiencia,material apoyo, difícil aprenderque sea más guiado, menos libertadgrupos más pequeños: 7→5 máx.sesiones todas en Laboratoriono en tutorías (probl. espacio)instalar Infiniband2xforma calificar 4x en general, correcta 4x más nota, injusto respecto otra Práctica2x se debe conocer la nota4x puntuar no según resultados,sobre la marcha, tras la aportaciónsino según esfuerzo / aprendizaje2x bajar más los umbrales, o quitarloscomentario 3x estoy satisfecho satisfecho con nuestro trabajo,he aprendido bastantes cosas2x espero que otros estudiantesagradecer dedicación profesor y flexibilidadpuedan beneficiarse tambiéndesarrollo trabajo2x se debe conocer la notasobre la marcha, tras la aportaciónhay que ser más realista, no da tiempo, montar2 SO es de locos, o menos objetivos o más notatanta libertad da quebraderos cabeza,obligando (Debian, Torque) se ahorraría tiempoTABLA 7. CALIFICACIONES DEL PROYECTO CLUSTER.curso notas media2008/09 3.0 3.0 3.0 3.0 3.02.9 2.6 2.5 2.4 2.41.9 1.8 1.8 1.4 1.4 2.412009/10 3.0 2.9 2.8 2.7 2.62.5 2.5 2.71Figura 4. Analíticas Google de la web del Proyecto [6] (español).Figura 5. Analíticas Google de la web del Proyecto [6] (inglés). El tramocon más visitas es el 2º cuatrimestre de 2010.de que es demasiado trabajo para tan poca nota. Losestudiantes que demostraran haberlos leído previamente(por ejemplo, respondiendo preguntas verbales o untest), tendrían derecho a intentar realizar la instalación yconfiguración descrita en ellos, en las fechas indicadasen la temporización. Se podría ofrecer la posibilidad deabandonar el proyecto durante el curso, si consideranque la nota que van obteniendo no es suficiente, y otrapráctica alternativa les resultara más interesante.VII. CONCLUSIONESDurante los cursos 2008/09 y 2009/10 hemosconseguido poner en contacto a un total de 22estudiantes con el tipo de supercomputador más habitualactualmente, el cluster de computadores, salvando lasdiferencias en cuanto a cantidad y categoría de loscomponentes (nodos sobremesa en lugar de servidor,prestaciones y tamaño del switch, etc.). Las actividadesrealizadas han ido desde el propio diseño y montajehasta la instalación y configuración del software desistema y middleware asociado. Los estudiantesconsideran en grado bastante alto que la actividad les haservido de aprendizaje y se debe mantener.La realización de este proyecto en estas fechas ha sidooportuna, ya que nos ha permitido detectar unascompetencias que no se están cubriendo en nuestrosactuales planes de estudio y que están presentes en losnuevos Grados, llevándonos a proponer dos nuevasasignaturas que podrían incorporar este tipo de prácticas,“Ingeniería de Servidores” y “Centro de Procesamientode Datos”. La primera, obligatoria de rama a impartir en3er curso, se va a dedicar al diseño, montaje, instalacióny evaluación de un servidor de gama baja, y la segunda,obligatoria de la especialidad Ingeniería deComputadores, al diseño y evaluación de un servidor degama media/alta. Las competencias específicas delJP2011-603

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Grado de Informática a las que contribuye estaexperiencia son (CVE: BOE-A-2009-12977):• E1: Capacidad para concebir, redactar, organizar,planificar, desarrollar y firmar proyectos en elámbito de la ingeniería en informática que tenganpor objeto, de acuerdo con los conocimientosadquiridos, la concepción, el desarrollo o laexplotación de sistemas, servicios y aplicacionesinformáticas.• E4: Capacidad para definir, evaluar y seleccionarplataformas hardware y software para el desarrolloy la ejecución de sistemas, servicios y aplicacionesinformáticas.• E6: Capacidad para concebir y desarrollar sistemaso arquitecturas informáticas centralizadas odistribuidas integrando hardware, software y redes.La experiencia adquirida nos servirá de referencia enel diseño de las prácticas de estas asignaturas.Añadir a las conclusiones, para acabar, que podemosafirmar que la relación prestaciones/precio del clusterdiseñado superó con creces lo que podía ofrecer en sumomento una empresa por el presupuesto con el que secontaba, entre otro motivos porque se adquirieron loscomponentes (procesador, memoria, placa, armario, etc.)por separado en Internet donde estaban más baratos.[7] Fernández, F.J., Anguita, M. Memoria del Proyecto Clúster.http://serin.ugr.es/unidad_innovacion_docente/memorias/08-08.doc. Convocatoria de Proyectos de Innovación Docente 2008:http://innovaciondocente.ugr.es/pages/convocatoria-2008.[8] Railsback, J. Project-Based instruction: Creating excitement forlearning. Northwest Regional Educational Laboratory, “ByRequest” series, 2002.[9] Valero García, M., Navarro, J.J. FAQ sobre la adaptación deasignaturas al EEES: docencia centrada en el aprendizaje delestudiante. In: ReVisión, vol.1, no.2, AENUI, 2008. Disponibleonline en http://aenui.net/ReVision/. Consultar en concreto elpenúltimo párrafo en la sección §3.10.AGRADECIMIENTOSAgradecemos la ayuda del Plan de Innovación Docentede la UGR, que nos ha permitido diseñar un cluster quepodremos reutilizar en cursos futuros para seguirintentando motivar a los estudiantes, así como la ayudadel Plan de Apoyo a la Docencia Práctica, que nos hapermitido adquirir la infraestructura Infiniband añadidaposteriormente a dicho cluster. Agradecemos también lacolaboración del proyecto de investigación TEC2010-15396 CITYC.Agradecemos especialmente a los estudiantes PabloOrantes, Ignacio Robles, Luis Quesada y Manuel Martín(2008/09), y Juan Pablo Chinea y Rubén Ramos(2009/10) su valiosa colaboración y encomiable interéspor el buen término del proyecto.REFERENCIAS[1] Cañas, A., Calandria, D.J., Ortigosa, E.M. et al. SWAD: WebSystem for Education Support. In: Computers and Education: E-learning - from Theory to Practice, Chapter 12, pp. 133-142,ISBN 978-1-4020-4913-2, Springer, 2007.[2] Cañas, A., Díaz, A.F., Prieto, A. Sistema de servicios web deapoyo a la docencia y gestión de una asignatura. In: Actas de lasVIII Jornadas de Enseñanza Universitaria de la Informática(JENUI'2002), pp. 611-614, 2002.[3] Cañas, A., Ortigosa, E.M., Fernández, F.J., Anguita, M., et al.SWAD (Sistema Web de Apoyo a la Docencia). In: Actas del 6ºSimposio Internacional de Informática Educativa (SIIE’04),2004.[4] Chinea, J.P., Ramos, R. et al (estudiantes ACII 2009/10). InformeACII: Puesta en marcha y configuración de un clúster conDebian 5.0. Documento GoogleDoc disponible enhttps://docs.google.com/Doc?docid=0Aane43447qy1ZGRxMmp6MjdfNWRwMjNkcWZr.[5] Comellas, F., González-Cinca, R., Santamaría, E. Simulación:Un curso innovador en los estudios de Aeronáutica. In:ReVisión, vol.2, no.2, AENUI, 2009. Disponible online enhttp://aenui.net/ReVision/.[6] Web del Proyecto Cluster, con su enunciado:http://atc.ugr.es/~javier/docencia/Proyecto_Cluster.html. Versióninglesa http://atc.ugr.es/~javier/docencia/Project_Cluster.html.JP2011-604

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evaluación de prestacionesJP2011-605

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-606

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Achieving interactive multiagent simulationsover Jason through Java tuningVíctor Fernández-Bauset, Francisco Grimaldo, Miguel Lozano y Juan M. Orduña 1Resumen— Java-based simulation environments arecurrently used by many multiagent systems (MAS),since they mainly provide portability as well as aninteresting reduction of the development cost. However,this kind of MAS are rarely considered when developinginteractive applications with time responseconstraints. This paper analyses the performance providedby Jason, a well-known Java-based MAS platform,as a suitable framework for developing interactivemultiagent simulations. We show how to tuneboth the heap size and the garbage collection of theJava Virtual Machine in order to achieve a good performancewhile executing a simple locomotion benchmarkbased on crowd simulations. Furthermore, thepaper includes an evaluation of Jason’s performanceover multi-core processors. The main conclusion derivedfrom this work is that, by means of Java tuning,it is possible to run interactive MAS programmed usingJason.Palabras clave— Jason, Java, simulation, interactive,multiagent.I. Introduction and Related workMAS platforms capable of handling a largeamount of complex autonomous agents at interactiveresponse times are required by interactivemultiagent applications such as crowd simulationsand massive online games. Usually, these kinds ofsimulations involve a high number of agents (e.g.pedestrians) interacting in a shared environment. Interactivity,in turn, requires the use of parallel techniquesthat allow to validate and to execute the actionsrequested within a limited period of time (commonly,250 ms [1]).Java-based simulation environments are currentlybeing used by many MAS, since they mainly provideportability as well as an interesting reductionof the development cost. However, this kind of MASare rarely considered when developing interactive applicationswith time response constraints, becauseof Java being normally less efficient than other languagessuch as C or C++. This situation requestsperforming a specific Java tuning to be able to tacklethis type of applications. In this paper, we show theJava tuning carried out for the purpose of evaluatingthe performace of Jason [2], a well-known Java-basedMAS platform. The aim of this tuning is to adjustboth the heap size and the garbage collection of theJava Virtual Machine in order to satisfy the temporalrequirements of interactive multiagent simulations.Therefore, the results presented in this paper willalso be of great value to those researches consider-1 Computer Science Department, University ofValencia, Dr. Moliner 50, (Burjassot) Valencia,Spain. E-mail: victor.fernandez-bauset@uv.es,francisco.grimaldo@uv.es, miguel.lozano@uv.es,juan.orduna@uv.es.ing Java-based simulation environments suitable fordeveloping interactive multiagent applications.When developing this kind of interactive MASthree layers are normally considered: the computerarchitecture, the MAS platform and the graphical engine(if any). At the low level, different distributedcomputer architectures have been applied in order toallow massive interactive simulations to scale up withthe number of agents by simply adding new hardware(e.g. networked-server, P2P, etc.). For instance,a new approach has been presented for PLAYSTA-TION3 which supports simulation of simple crowdsof up to 15000 individuals at 60 frames per second[3]. Parallel simulation, based on classical Reynolds’sboids [4], has been also integrated in a PC-Clusterwith MPI communication [5] to finally produce smallsimulations (512 boids). At the top level, the graphicalengine of the application must render the visualizationat interactive frame rates. The computergraphics community generally represents the MASas a particle system with local interactions [6], [7],though, few works include socially complex and autonomousbehaviors [8]. However, they are not normallybased on standard agent architectures.In the middle level, the MAS platform is in chargeof providing the required data flow to the graphicalengine while efficiently using the computationalresources. Thus, it constitutes a key middlewarethat highly influences the global performance andthe scalability of the system. It mainly addressestwo important issues: modeling the behavior of theagents as well as their parallel lifecycle execution.Java is a popular language providing built-in supportfor concurrency that is commonly used by MAS platforms.Although Java performance has been studiedfrom different perspectives, probably the mostusual is to tune server applications running on largemulti-processor servers [9]. There are more specificworks focused on the evaluation of Java-based multiagentplatforms [10], [11], [12]. However, none ofthem deals with providing interactivity to the correspondingMAS. Some researchers have been also testingthe performance and scalability of a few existingMAS platforms [13], showing a lack of both importantissues in many of them. In a previous work [14],the authors analysed Jason’s architecture and evaluatedits performance under both centralised and distributedinfrastructures. Regardless the infrastructure,the results showed that the execution optionshad to be reviewed in order to achieve a more equilibratedresponse time distribution, an aspect that wehave covered in this work.The rest of the paper is organized as follows. Sec-JP2011-607

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tion II briefly reviews Jason’s centralised infrastructureand describes the locomotion benchmark usedfor the evaluation. Section III demonstrates how totune Java in order to run interactive multiagent simulationsover Jason. Finally, section IV shows theperformance obtained with different multi-core processors.II. Test descriptionThe goal of this work is to evaluate Jason as asuitable framework for running interactive multiagentsimulations. Jason is a Java-based interpreterfor an extended version of AgentSpeak, a BDI agentorientedlogic programming language [2]. Jason providesthree infrastructures to execute a MAS: Centralised,SACI and JADE. Whereas the Centralisedinfrastructure places all the components of the MASin the same host, it is also possible to distributethese components in several hosts using either SACIor JADE technologies. For the sake of simplicity,this paper focuses on the Centralised infrastructurebut the results obtained are fully applicable for bothdistributed infrastructures.Jason’s Centralised infrastructure can be seen infigure 1. Here the environment has its own executionthread and it is provided with a configurablepool of threads (PThE) devoted to executing the actionsrequested by the agents. In this way, the enviromentis able to deal with several agent requestsconcurrently. In turn, each agent owns by defaulta thread in charge of executing the agent reasoningcycle. In this manner, all the agents can run concurrentlywithin the MAS. As such, this approach couldlimit the number of agents that can be executed,since the total number of threads would be limited bythe Java Virtual Machine (JVM) heap size. However,Jason offers the possibility to optionally add anotherconfigurable pool of threads (PThA), so that the setof agents can share a smaller number of executionthreads but reducing the level of concurrency. Thenumber of threads in both PThE and PThA is initialisedduring the start-up of the MAS and it is notchanged along its execution. By default, the PThEholds 4 threads whereas the PThA is disabled, sothat each agent will have its own execution thread.In a previous work, we tuned both the PThE and thePThA in order to obtain the best performance [14].The main issue to be tackled when running interactivemultiagent simulations is that of being able ofefficiently handling a massive and concurrent actionprocessing. In this paper, we have used a locomotiontestbed. Here, a set of wanderer agents requestmovement actions to a grid-like environment, whichreplies with the result of the execution, as can beseen in figure 2. Wanderer agents are written inAgenSpeak and they cyclically execute the followingsteps: (i) take start time, (ii) request a random movementto the enviroment, and (iii) take finish time.On the other hand, the environment executes eachmovement action in a synchronized manner to ensurethe world consistency. That is, the environmentFig. 1.Jason architecture at its centralized infrastructureFig. 2. Action example between the environment and thewanderer agentsperforms a simple collision test and informs whetherthe action can be carried out (i.e. Ok) or it cannot(i.e. Failure), when it would lead to a collisionsituation.The performance evaluation carried out along thepaper measures the environment response time andthe percentage of CPU utilization consumed whilerunning the locomotion benchmark. These measurementsrepresent respectively latency and throughput,the two performance parameters commonly consideredwhen evaluating networked-based distributedcomputer platforms [15]. We define the ResponseTime (RT ) as the time elapsed between an agentasking for an action and receiving the reply fromthe environment. Our simulations stop when all theagents have performed 500 movements or cycles, butwe discard the first 200 cicles when computing theaverage response time (RT ). Thus, we measure thesystem behavior at full load, since the first measurementsare distorted due to the agent creation phase.As stated above, we are interested in exploring theperformace of Jason’s Centralised infrastructure indepth. Thus, both the environment and the agentsare run on the same host. The results for the Centralisedinfrastructure shown in [14] indicated that,when simulating 1000 wanderer agents, the 70% ofthe agents were able to act within 85 ± 264 ms. Thatis, even though the low value of RT (85 ms) indicatedthat many actions were processed very fast,there were a few agents that must wait more than250 ms for their actions to be executed. This problemwith the high standard deviation of the responseJP2011-608

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. Influence of the Java Garbage Collection on the responsetimetime (σ RT ), found all over the measures in [14], is addressedin the following section.III. Java tuningThe source of the high standard deviation of theresponse time of Jason-based MAS can be envisonedin figure 3. The figure shows that the average responsetime per agent cicle (RT c ) peaks periodically.This points to a process that stops the system wheneverit is executed: the Java Garbage Collection.Thus, we have carried out Java Performance Tuningin order to provide some general recommendationsfor running interactive multiagent simulations overJason. It should be noticed, though, that the optimaltuning parameters will finally depend on theapplication and on the hardware underneath.In this section, we show the results obtained whenexecuting the testbed defined in section II over anAMD Dual-Core Opteron processor with 4 Gb ofRAM, running a 64-bit version of Linux and theSun’s HotSpot TM Java Virtual Machine (JVM) release1.6.0 07. From version 1.5, this JVM has incorporateda technology to begin to tune itself, referredto as Ergonomics. Even though Ergonomics significantlyimproves the performance of many applications,optimal results often require manual tuning.There are two main aspects that have to be tunedin order to enhance Java performance: the heap sizeand the garbage collector (GC) [16]. Regarding theformer, by default, the initial heap size is 1/64th ofthe machine’s physical memory and the maximumheap size is 1/4th of the machine’s physical memory.In our case, this would mean using 64 Mb and1 Gb respectively. However, Java performance canbe enhaced by increasing the maximum heap size,as shown in figure 4. This figure shows the totalamount of time consumed by the garbage collectionwhen we use diferent GCs and increase the heap sizewhile simulating 2500 agents. This time is computedby adding the times needed to complete every invocationto the GC. Besides, we have set minimum andmaximum heap sizes equal for a faster startup. Notehow, regardless of the GC being used, the total GCtime strongly decreases when increasing the heap sizeup to 2 Gb. Further on, the gain is very low com-Fig. 4. Garbage colletion time needed for different heap sizesand GCs.pared to the fact of being using almost the wholephysical memory.With respect to the garbage collectors, Sun’sHotSpot TM JVM allows the programmer to chooseamong three of them: serial, throughput and concurrentlow pause collector. Whereas the serial GC is asequential collector, the throughput GC uses multiplethreads to collect garbage in parallel and it is suitablefor applications with a large number of threads allocatingobjects, such as the one being tested in thispaper. On the other hand, the concurrent GC doesmost of the collection concurrently with the executionof the application and it is appropriate for applicationsthat benefit from shorter GC pauses. Additionally,Java GCs organize the object memory intotwo generations: young (recently created objtects)and tenured (older objects). Java allows to set theratio between the young and tenured generation bymeans of the JVM command-line option NewRatio.For more details on Java garbaje collection, see [16].Bearing all this informacion in mind, we have executedour benchmark using every GC available. Figure4 shows the most relevant results that we haveobtained. The line named Serial corresponds to thetotal amount of time consumed by the garbage collectionwhen simulating 2500 agents using the serialGC. The Parallel line relates to the use of thethroughput GC only for the collection of the younggeneration. In turn, the ParallelOld line refers to theuse of the throughput GC for the collection of boththe young and the tenured generation. For space reasons,we skip the results obtained with the concurrentGC since they are up to ten times higher thanthose obtained with the rest of the GCs, both for thetotal GC time and for the average response time. Aswe can observe, the serial GC behaves worse thanany configuration of the throughput GC. Moreover,parallelizing the collection of the tenured generationdoes not fasten but actually slows garbage collectionwhen the heap size is less than 2.5 Gb. This meansthat there is not a problem with the collection of oldobjects but with the young ones. The reason behindthis fact relies on how Jason represents agent’s beliefsand actions. Both are implemented as objectsthat are discarded and created again whenever thereis a change in a belief or a new action is requestedJP2011-609

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011throughput GC whenever your hardware has atleast 2 CPUs in order to reduce GC pause times.Besides, check whether you need the defaultnumber of collector threads (equal to the numberof processors) or you can save any, thus reducingthe workload of the whole machine.• Increase the size of the young generation up tothe size of the tenured generation (NewRatio=1)to decrease the need for slow major collections.Fig. 5. Performance when varying the number of threads usedby the throughput GCto the environment. As each wanderer agent continuouslyasks the environment for movement actionsand changes its position, we can imagine the hugeamount of objects that “die young”. Thus, enlargingthe young generation will benefit garbage collection.The default NewRatio for the Server JVM is 2.That is, the tenured generation occupies 2/3 of theheap while the young generation occupies 1/3. Alarger young generation could accommodate manymore short-lived objects, decreasing the need for slowmajor collections. Meanwhile, the tenured generationwould still be large enough to hold many longlivedobjects. According to this, the line labeled asParallel-n=1 in figure 4 shows that we can obtain thelowest garbage collection times by using the throughputGC for the collection of the young generationalong with the minimum ratio possible between thegenerations (i.e. NewRatio = 1). Hence, half of theheap for the young generation and the other half forthe tenured generation.Finally, we have evaluated the effect of the numberof threads devoted to collect garbage when usingthe parallel throughput GC. By default, this GCuses as many garbage collector threads as the numberof processors available. Though, the number ofthreads can be tuned manually through the Parallel-GCThreads command-line option. For this test, wehave used a 16-core computer and we have varied thenumber of collector threads from 2 up to 16. Besides,we have tuned Java so it runs efficiently with 2 Gbof heap size and the NewRatio set to 1. Figure 5shows the values obtained for the average responsetime (RT ) plus its standard deviation (σ RT ) when increasingthe number of agents simulated. Evidently,the worst values are obtained when only 2 threadsare used for garbage collection. However, in our testit is not necessary to use as many threads as thenumber of cores, since we get the same results for 8and 16 GC threads.Summing up, we can state the following generalrecommendations for running interactive multiagentsimulations over Jason:• Enlarge the heap size as much as possible withoutachieving the amount of physical memoryavailable. In addition, set minimum and maximumheap sizes equal for a faster startup.• Parallelize garbage collection by using theIV. Performance EvaluationIn this section we analyse the results obtainedwhen running the benchmark described in section IIon the following distributed shared memory (DSM)multi-core computers: 2-Core (AMD Dual-CoreOpteron, 1.6 GHz, 4 GB RAM), 4-Core (AMD Quad-Core Opteron, 1.0 GHz, 8 GB RAM), 8-Core (Intel8-Core Xeon, 2.6 GHz, 16 GB RAM) and 16-Core(AMD Dual-Core 8218, 1.0 GHz, 32 GB RAM). Allof them run the same 64-bit version of Linux and theSun’s HotSpot TM JVM release 1.6.0 07.Table I shows the performance obtained when simulatingfrom 2500 to 5500 wanderer agents on thecomputers described above. The results for 1-corewere obtained through the taskset Linux command.When running the benchmark, we have followed theJava tuning recommendations stated in section III.Therefore, we have used the throughput GC for thecollection of the young generation with a number ofcollector threads equal to the number of cores. Besides,we have tuned Java so it runs with 4 Gb ofheap size and we have set NewRatio to 1. The leftcolumn in Table I shows the percentage of CPU utilizationmeasured during the execution of the simulation.The central column (RT ) shows the averageResponse Time in milliseconds for the actionsrequested by the agents when the system is at fullload, as explained in section II. Finally, the right columnshows the standard deviation of this ResponseTime (σ RT ).The results shown in Table I demonstrate that wecan run interactive multiagent simulations over Jason,since the values of the RT plus the σ RT aregenerally under the reference value of 250 ms. Asit was also expected, the CPU utilization decreasesas the number of cores increases. For instance, if wecompare the results obtained for 3500 agents on eachcomputer, it can be seen that the more cores in thecomputer, the lower the percentage of CPU utilization(the single CPU is shown only as a reference).However, the response time does not behave the sameway. Instead, whereas the RT values for the 2-Corecomputers are around a few milliseconds, the RT forthe computers with 4 up to 16 cores reaches tensof milliseconds. The worsening of the response timeoccurs in all the computer being tested, althoughit has a minor impact in the 8-Core computer becauseit has the highest processor speed. This factindicates that, beyond two cores, the default configurationused by Jason does not properly scale upwith the number of processor cores. Thus, a deeperJP2011-610

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IPerformance obtained for Jason framework overdifferent computersCores-Agents CPU(%) RT (ms) σ RT (ms)1-1500 89,53 44,59 101,641-3500 90,01 40,39 189,571-5500 89,98 71,97 178,421-7500 87,87 85,93 193,031-9500 65,97 98,33 2196,682-1500 89,17 3,92 28,842-3500 91,13 5,55 27,592-5500 92,00 9,01 35,382-7500 91,10 10,39 79,092-9500 59,72 47,79 1152,104-1500 76,25 51,97 20,814-3500 81,11 132,88 50,714-5500 81,48 201,90 76,894-7500 83,35 290,71 118,304-9500 84,24 386,35 488,378-1500 59,88 31,01 8,588-3500 67,75 73,82 22,658-5500 72,09 114,10 40,628-7500 74,56 146,27 58,268-9500 74,92 185,81 278,0016-1500 39,77 57,38 9,6016-3500 46,45 145,86 38,1016-5500 48,27 242,87 62,2316-7500 57,58 282,57 85,7316-9500 57,51 253,53 534,66study must be carried out in order to allow it to takeadvantage of the multi-core processors.Although a fine tuning of the Jason framework formulti-core processors is beyond the scope of this paper,we have analysed the issue shown in Table I inorder to clarify the path for future work. We thinkthat the reason behind this problem is thread contextswitching. Even though the Java Virtual Machineschedules its threads to run them as fast as possible,there is no guarantee of which core a given thread willbe assigned to for execution. The operating systemkernel can assing one single thread to different coresduring its execution time, thus provoking thread migrations.The probability of migration increases withthe number of cores in the processor, in such a waythat the overhead due to thread migrations couldexceed the benefits of having more cores for executingthe threads in parallel. To verify this hypothesis,we have measured the number of migrations (i.e.changes in the core assigned for execution) sufferedby the threads along the simulation. To detect migrations,we have used a system call retrieving thestate of the Java threads periodically and we haveanalysed the core where they were located.Figure 6 shows the total number of thread migrationscounted while executing the same simulationsthat produced the results of Table I. We can observehow the number of migrations is proportional to thenumber of cores in the computer. Since a thread mi-Fig. 6.Number of thread migrationsgration is a time consuming task, the high number ofmigrations produced by computers with more than2 cores can explain the behavior shown in Table I.Nevertheless, it should be noticed that these resultsdo not guarantee the absence of other still hiddenaspects that could prevent the system from properlyscaling with the number of processor cores. In orderto fully exploit the degree of parallelism offered bymulti-core processors, tuning the processor affinityof Jason must be done.V. Conclusions and Future workIn this paper, we have evaluated Jason as a suitableJava-based MAS platform for developing interactivemultiagent simulations. We have shown howto tune the Java heap size as well as the gargabecollector in order to enhance the performance of thesimulations. Even though the optimal tuning parameterswill finally depend on the application and onthe hardware underneath, we have state some generalrecommendations for minimizing the impact ofgarbage collection. Therefore, the results presentedin this paper will also be of great value to those researchesconsidering other Java-based simulation environmentsfor developing interactive multiagent applications.The paper also includes a first evaluationof Jason’s performance over multi-core processors.As future work, we plan to carry out a deep studyof the Jason framework in order to properly scale itup with the number of processor cores. Then, tuningthe Java processor affinity will be required to exploitthe degree of parallelism offered by multi-core processors.AgradecimientosThis work has been jointly supported by theSpanish MEC and the European CommissionFEDER funds, under grants Consolider-Ingenio 2010CSD2006-00046 and TIN2009-14475-C04-04..Referencias[1] Miguel Lozano, Pedro Morillo, Juan Manuel Orduna, andVicente Cavero, “On the design of an efficient architercturefor supporting large crowds of autonomous agents,”in Proceedings of IEEE 21th. International ConferenceJP2011-611

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011on Advanced Information Networking and Applications(AINA’07), 2007, pp. 716–723.[2] R. H. Bordini, J. F. Hübner, and M. Wooldrige, ProgrammingMulti-Agent Systems in AgentSpeak using Jason,Wiley, 2007.[3] Craig Reynolds, “Big fast crowds on ps3,” in Proc. ofthe 2006 ACM SIGGRAPH symposium on Videogames.2006, pp. 113–121, ACM.[4] Craig W. Reynolds, “Flocks, herds and schools: A distributedbehavioral model,” in SIGGRAPH ’87: Proc.of the 14th annual conference on Computer graphics andinteractive techniques. 1987, pp. 25–34, ACM.[5] Bo Zhou and Suiping Zhou, “Parallel simulation of groupbehaviors,” in WSC ’04: Proceedings of the 36th conferenceon Winter simulation. 2004, pp. 364–370, WinterSimulation Conference.[6] Simon Dobbyn, John Hamill, Keith O’Conor, and CarolO’Sullivan, “Geopostors: a real-time geometry/impostorcrowd rendering system,” ACM Trans. Graph., vol. 24,no. 3, pp. 933–933, 2005.[7] Adrien Treuille, Seth Cooper, and Zoran Popovic, “Continuumcrowds,” in SIGGRAPH ’06: ACM SIGGRAPH2006 Papers. 2006, pp. 1160–1168, ACM.[8] Nuria Pelechano, Jan M. Allbeck, and Norman I. Badler,“Virtual crowds: Methods, simulation, and control,”Synthesis Lectures on Computer Graphics and Animation,vol. 3, no. 1, pp. 1–176, 2008.[9] Jack Shirazi, Java Performance Tuning, O’Reilly, 2003.[10] E. Cortese, F. Quarta, and G. Vitaglione, “Scalabilityand performance of JADE message transport system,”in AAMAS Workshop on AgentCities, 2002.[11] Robert Tobias and Carole Hoffman, “Evaluation of freejava-libraries for social-scientific agent based simulation,”Journal of Artificial Societies and Social Simulation, vol.7, no. 1, 2004.[12] Cynthia Nikolai and Gregory Madey, “Tools of the trade:A survey of various agent based modeling platforms,”Journal of Artificial Societies and Social Simulation, vol.12, no. 2, pp. 2, 2009.[13] Luis Mulet, Jose M. Such, and Juan M. Alberola,“Performance evaluation of open-source multiagent platforms,”in Proc. of the fifth international joint conferenceon Autonomous agents and multiagent systems. 2006, pp.1107–1109, ACM.[14] Victor Fernández, Francisco Grimaldo, Miguel Lozano,and Juan Manuel Orduña, “Evaluating Jason for distributedcrowd simulations,” in Proc. of the 2nd. InternationalConference on Agents and Artificial Intelligence.2010, vol. 2, pp. 206–211, INSTICC Press.[15] J. Duato, S. Yalamanchili, and L. Ni, InterconnectionNetworks: An Engineering Approach, Morgan Kaufmann,2002.[16] Oracle Sun Depeloper Network, “Java Tuning WhitePaper,” 2010, Available at http://java.sun.com /performance/reference/whitepapers/tuning.html.JP2011-612

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Dynamically Tuning Master/WorkerApplications with MATEAndrea Martínez, Anna Morajko, Eduardo César and Joan Sorribes 1Abstract— Programming parallel/distributed applicationsis a difficult task that requires a high degreeof knowledge and expertise, especially to achieve thepotential performance offered by HPC. Analysis andtuning tools can be helpful for automatically improvingapplications performance, but these tools mustbe adapted to the application’s characteristics. Inparticular, dynamic analysis and tuning tools are necessaryfor applications that vary their behaviour atexecution time. MATE is a tool, based on performancemodels, which can automatically and dynamicallytune parallel applications. This work presentsthe integration of a theoretical performance model ofMaster/Worker applications into MATE. This modeltakes into account the main performance problemsof Master/Worker applications: load balancing andusing an appropriate number of workers. This knowledgeis encapsulated in MATE in a component calleda tunlet. It implements the specific logic necessaryto overcome these performance problems in terms ofmeasurement points, performance functions, and tuningpoints/actions. The experimentation shows theeffectiveness of using performance models for dynamicallytuning parallel applications. However, theanalysis process included in MATE presents seriousscalability problems that must be addressed to makeit efficient in large scale systems.Keywords— dynamic performance analysis; dynamicand automatic tuning; performance models; parallel/distributedcomputingI. IntroductionCURRENTLY , software applications are used tosolve complex problems in a number of differentareas of science and engineering. Many of these problemshave very high computing requirements thatcan only be addressed through parallel/distributedprocessing. Therefore, performance is usually themost important issue related to parallel applications.In this work, we apply a methodology, based on performancemodels, for automatically and dynamicallytuning the performance of parallel applications. Inparticular, we focus on the implementation and integrationof a performance model for Master/Workerapplications in MATE.When a programmer develops a parallel application,he or she wishes to achieve a level of performanceclose to the expected theoretical performance.Unfortunately, this is not usually the case becausethe development of this type of applications is a complexand difficult task that involves knowledge of parallelprogramming models, communication librariesand/or operating system features.With the aim of increasing the performance oftheir applications, developers must undertake a per-1 Computer Architecture and Operating Systems Department,CampusBellaterra (08193) Barcelona, Spain,e-mail: amartinez@caos.uab.es, ania.morajko@uab.es,eduardo.cesar@uab.es, joan.sorribes@uab.esformance improvement process. This process includes3 successive phases: monitoring, analysis andtuning. First, during the monitoring phase, informationabout the application behaviour is captured.Then, by studying this information, the analysisphase involves looking for bottlenecks, deducing theircauses, and tries to determining what the correct actionsto eliminate the problems are. Finally, in tuningphase these actions are applied to the applicationto solve the problems and improve performance.As a result, developers must be familiar with the application,the software layers involved, and the behaviourof the system on which it is executed.Various approaches and tools have been developedto support the performance improvement process [1][2]. In particular, one of these approaches is the automaticand dynamic tuning of the application withoutstopping, recompiling, or rerunning it. This typeof performance tuning approach is especially recommendedfor applications that behave differently dependingon input data, or may even change theirbehaviour during each execution. In such cases, it isnot worth carrying out a post-mortem performanceanalysis and tuning because conclusions based on oneexecution may be invalid for another. An automaticand dynamic performance tuning process must considerseveral aspects to be useful and efficient. First,it requires an efficient analysis to make decisions ina short period of time. Second, the overhead causedby the whole process must be minimised to avoidexcessive application intrusion.MATE (Monitoring Analysis and Tuning Environment)is a tool that implements this approach. It isable to automatically and dynamically tune a parallel/distributedapplication using the knowledge providedby a performance model. The remainder of thiswork is organised as follows. Section 2 briefly describesMATE. In Section 3, we present an overviewof the performance model developed for dynamicallytuning Master/Worker applications. Section 4 explainsthe integration of the performance model intoMATE. In Section 5 we present the results of theexperiments conducted using MATE to improve theperformance of a Master/Worker application. Section6 presents the related work in automatic anddynamic tuning. And finally, Section 7 details theconclusions of this study.II. MATEMATE [3] is a tool that performs monitoring, analysis,and tuning of MPI parallel applications. Itsobjective is to improve the performance of a parallelapplication at run-time, by adapting it to theJP2011-613

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011variable conditions of the system. First, at runtimeMATE instruments the application to gatherinformation about its behaviour. During the analysisphase MATE receives events, searches for bottlenecksand specifies solutions for solving the performanceproblems encountered. Finally, the applicationis dynamically modified by applying the givensolutions. MATE uses dynamic instrumentation [4]to modify the application at run-time, so it does notneed to be recompiled or restarted.MATE is composed of the following modules whichcooperate to control and improve the application’sperformance [5]:• The Application Controller (AC) is a daemonthat controls the execution and the dynamic instrumentationof each individual MPI task.• The Analyzer is a centralised process that carriesout the application performance analysis,and decides on monitoring and tuning. It automaticallydetects existing performance problemson the fly and requests appropriate changes toimprove the application’s performance.• The Dynamic Monitoring Library (DMLib) is ashared library that is dynamically loaded by theAC in the application tasks to facilitate collectingdata and delivering it to the Analyzer.Performance models constitute the knowledge usedby MATE to conduct the performance analysis process.Each performance model is encapsulated inMATE in a piece of software called a tunlet. Eachtunlet implements the logic to overcome a particularperformance problem by encapsulating informationabout it in the following terms:• Measurement points, which are the places inthe application code where the instrumentationmust be inserted to gather information aboutthe application’s performance.• Performance functions, which are a set of expressionsthat model the application’s behaviour.• Tuning points,which are the points of the applicationsthat can be changed by a tuning actionto improve its performance.III. Master/Worker Performance ModelThe goal of performance analysis is to identify andsolve the application performance problems. Thisprocess may be supported by a performance modelthat can be a combination of analytical expressionsand heuristics. The parameters needed for evaluatingthe model correspond to the measurements gatheredduring the application execution. We haveimplemented and integrated into MATE a tunletwith the Master/Worker performance model describedin [6]. It is designed for Master/Worker iterativeapplications, where all process repeatedly performsall operations. In every iteration, the masterdistributes tasks to a specific number of workersand then waits for the results before the next iteration.Workers processes calculate the results andsend them back to the master. The condition ofthe iteration-based application behaviour implies theexistence of a significant number of iterations andpersistent performance problems between iterations.This performance model includes two phases tosolve Master/Worker application performance problems:a load balancing strategy, and an analyticalmodel to evaluate and predict the appropriate numberof workers for the application. In the followingsubsections we summarise both phases, and how torepresent them in terms of the knowledge organisationrequired by MATE.A. Load BalancingLoad balancing techniques try to avoid that someprocesses complete their processing before others.Some of these techniques are based on distributingthe tasks in portions of decreasing size called batches.In particular, we have implemented the strategycalled Dynamic Adjusting Factoring (DAF) [7]. Thistechnique divides the task set into different sizedbatches using a partition factor x i whose value isdynamically adapted to the current load conditionsof the application through expressions (1) and (2).This factor depends on the mean µ C and standarddeviation σ C of task processing C, and the numberof workers N. Table I shows the Dynamic AdjustingFactoring strategy definition, represented accordingto the MATE knowledge requirements.TABLE IDefinition of the load balancing strategyParametersPerformancefunctionsTuningpoints/actions- N, number of workers- C, task processing time, msPartition factor of the first batch of theiteration:√ )x 0 = 1 +(σ C N/2 /µ C (1)Partition factor of the remainingbatches of the iteration:√ )x i = 2 +(σ C N/2 /µ C (2)Partition factor. Its value can bemodified throughout the iteration.B. Adapting the Number of WorkersFor determining the appropriate number of workersof the application, we have used the performanceindex Pi proposed in [6]. This index relates the executiontime to the efficient use of resources in orderto maximise the performance without wastingresources. Following the requirements of knowledgerepresentation in MATE, the definition of this tuningstrategy is presented in Table II.The parameters m 0 and λ are statically configuredtaking into account the characteristics of the computingplatform . The total communication volume,V , is calculated as the sum of task sizes sent/receiveto/from workers, and finally the total computationtime, T c , is obtained by adding the computation timeof workers in an iteration.IV. Tunlet ImplementationTo dynamically tune the performance of Master/Workerapplications, we have developed a tun-JP2011-614

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIDefinition of the adjust number of workers strategyParametersPerformancefunctionsTuningpoints/actions- m 0 , start up time per message, in ms- λ, communication cost per byte, inms/byte.- V , total communication volume, in bytes.- T c, total computation time,in ms.Performance index for different number ofworkers x:P i(x) = xT t(x) 2T c/µ C (3)At the execution time of one iteration forx workers:⌊((x−1)α+1)λV Tc⌋T t(x) = 2m 0 + /µ x C (4)The number of workers. Its value can bemodified at the beginning of each iteration.let that integrates the tuning strategies presented inSection III.Technically, a tunlet is a library that encapsulatesthe information about a performance problem, implementinga particular tuning technique. Its implementationmust use the Dynamic Tuning API [3]provided by the MATE’s Analyzer module.Earlier works featuring MATE show applying separatetuning techniques to load balancing [8] or toadapting the number of workers [9]. It is worth notingthe complexity of the developed tunlet as it encapsulatestwo tuning phases, taking into account theinteractions between them. In particular, the phasefor adapting the number of worker considers that theapplication is balanced.For the proper development of the tunlet, its definitionshould include the identification and interpretationof a set of elements related to the performancemodel and the type of the applications understudy. From the point of view of the performancemodel, the following must be defined: measurementpoints, analytic performance functions and tuningpoints/actions. With respect to the application, inour work we have taken into consideration:• The programming model followed by the applications.• The variables or values that can be manipulated,with the aim of locating variables to tune.• The functions whose execution must be detectedto gather behavioural information.In order to implement the tunlet based on the presentedMaster/Worker performance model, we havefollowed a tunlet design and development process [10]consisting of four steps which are explained in the followingsubsections.A. Identify Application ActorsThe designed tunlet needs information about thedifferent types of application processes that cooperateto solve a concrete problem. This knowledge isrequired because each type of process should be instrumenteddepending on the role that it plays in theapplication. The application to be tuned follows aMaster/Worker paradigm, so, two types of processcan be identified: the master and N workers.B. Identify Measurement PointsTo evaluate the performance model it is necessaryto determine which points in the application execution- measurement points - must be monitored withthe aim of collecting behavioural information aboutthe application to calculate the parameters of themodel’s analytical expressions, which are shown inTables I and II.The measurement points are located in either theentry to or exit from a function. One value is extractedof each of these points. However some parametersrequire multiple values and therefore multiplemeasurement points in order to be calculated.C. Identify EventsEvents are messages in which the values extractedat the measurement point are sent to MATE’s Analyzermodule. These events are explicitly definedwithin the tunlet. Multiple values obtained at thesame measurement point can be encapsulated in asingle event and these values will be used by the Analyzermodule in order to calculate the parameters forevaluating the performance model.Table III presents the relationship between eventsand measurement points required by the analysisprocess. For each measurement point the table showsthe actor, the function where it is situated, whetherit is the entry to or exit from this function and thevalue which will be obtained.D. Identify the Tuning Points and ActionsThe last step consists of identifying the specificvariables that will be modified by MATE at runtime.Consequently, a Master/Worker application mustinclude a variable indicating the partition factor tobe applied to the set of tasks for the load balancingstrategy, and a variable indicating the currentnumber of workers. Once MATE has taken all measurementsto calculate the parameters of the analyticalexpressions, the performance model can beevaluated, and depending on the results of this evaluation,the adequate point to modify the associatedvariable should be determined.For the load balancing strategy, the evaluation ofthe expressions is triggered when two separate eventsare received by the Analyzer:• Start iteration, because at the beginning of theiteration, the tunlet has gathered all the informationfor calculating the mean µ C and standarddeviation σ C of the task processing timefor the previous iteration. This allows the calculationof the partition factor values for thefirst and second batch of the current iteration.• End computing worker, because then, the tunletcan verify if the information about the processingtime of each worker that has participated inthe computation of a particular batch has beencollected. If so, the tunlet can calculate the partitionfactor for the following batches taking intoaccount the current load balancing conditions.JP2011-615

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIIRelationship between events and the required measurement point by the analysis processParametersMeasurement PointsActor Function Location Value obtainedEventsNumber ofGlobal sendMasterworkers Nto workersEntry #workers Start iterationReceive tasksClock time,WorkerEntryTask processing from master #tasks from masterStart computingtime, CSend tasksWorkerto masterExit Clock time End computingSend toMaster sendsMasterEntry #tasks to worker iTotal communication worker i to workervolume, VReceive tasksMaster receivesMasterExit #tasks from worker ifrom worker ifrom workerReceive tasksWorkerTotal computationfrom masterEntry Clock time Start computingtime, T cSend tasksWorkerto masterExit Clock time End computingThen, the tuning action can be invoked and thepartition factor modified at any time during the iteration.On the other hand, for adjusting the numberof workers, the evaluation of the expressions is triggeredwhen the Start iteration event arrives to theAnalyzer. At this moment, the tunlet has all the requiredinformation from the previous iteration (T c ,V , λ, and m 0 ). If the number of workers calculatedby the Analyzer differs from the current number ofworkers, the tuning action is invoked between twoiterations, and the predicted number of workers willbe used in the next iteration.V. Experimental ResultsIn this section, we present the experimental resultsobtained to validate the efficiency of the developedtunlet when it is integrated into MATE fordynamically tuning of Master/Worker applications.To conduct the experiments, we selected a computationallyintensive Forest Fire Propagation parallelapplication called Xfire [11]. It is a Master/WorkerMPI application that simulates fire line propagationfollowing the Andre-Viegas model [12]. It iterativelycalculates the next position of the fire line consideringthe current fire line position and environmentaspects, such as weather, wind, vegetation, topology,etc. In each iteration, the master distributesthe fire line among the workers and waits for the results.Then, it composes the new fire line and startsthe next iteration. Workers calculate the evolution ofthe received fire line and send it back to the master.The application presents computational imbalance,with processing time differences between 20% and100% among workers.Experiments were conducted on a 33 node homogenouscluster running 3.00 GHz Intel Xeon Dual-Core processors, SuSE Linux 10, and connected bydual Gigabit Ethernet. The experiments were performedusing 2, 4, 8, 16 and 31 workers. In eachexperiment, each worker, the master, and the Analyzerwere executed on a dedicated node. We haveconducted our experiments using four scenarios:1. Xfire was executed for different numbers of workerswithout tuning.2. Xfire was executed with MATE, but only tuningthe load balancing following the DAF algorithm.The initial partition factor was 0.5, andduring the execution this value was adjusted tothe load balancing conditions.3. Xfire was executed with MATE, but only tuningthe number of workers. The applicationstarted with two workers, and during the executionthis number was changed according to themodel described in Section III.4. Xfire was executed with MATE applying theentire developed tunlet, i.e., Xfire was tunedusing the load balancing strategy and adjustingthe number of workers.Table IV summarises the results obtained. Thecomparison of the execution times obtained for scenario1 and 2 shows that dynamic tuning of the partitionfactor improves Xfire performance only for 4workers. For a greater number of processes the tuningprocess loses effectiveness due to two main reasons:• Centralised performance analysis carried out byMATE’s Analyzer module.• Frequent partition factor tuning.Regarding the first reason, when the number ofprocesses increases, the number of events received bythe Analyzer also increases. It is related to the factthat the applied load balancing strategy is quite conservative,which means low partition factors around[0.2-0.4]. This leads to a finer grained distributionof tasks, increasing the number of events generatedby worker processes. This behaviour causes the processessending events to the Analyzer to block untilthe Analyzer is able to receive the event.To measure the overhead introduced by MATE anew experiment was conducted with two new scenarios.In the first, Xfire was executed for three differentcases: a) without workload fragmentation, b) with astatic partition factor of 0.5 and c) with a static partitionfactor of 0.2. The cases b and c have been executedto analyse the behaviour of Xfire with a finergrained distribution of tasks. In the second scenario,Xfire was executed with MATE but without tuningthe application, using the same static partition factorsas in the first scenario. This means that eventsare generated and sent to the Analyzer, but the partitionfactor and the number of workers are not tunedJP2011-616

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IVExecution time of Xfire in the different scenariosScenario#Workers2 4 8 16 311 48.08s 24.38s 13.67s 8.75s 6.08s2 40.69s 20.17s 14.89s 20.27s 20.69s3 Starting with two workers 8.49s4 Starting with two workers 25.01sduring the application execution.The results shown in Figure 1 indicate that forlow partition factors, when increasing the number ofworkers, the number of events generated by themincrease significantly. In this situation, MATE isnot able to handle all received events and introducesa large overhead. Therefore, it can be deducedthat MATE presents a bottleneck as the applicationgrows, due to the centralised analysis process [13].The second cause that leads to problems in the tuningprocess is related to the implemented load balancingstrategy in the tunlet. It is characterised byapplying a technique that tries to adapt the partitionfactor to the current conditions of the application.Figure 2 shows the partition factor variation overfive iterations of Xfire execution. According to theload balancing strategy, it is observed that the partitionfactor used for the iterations’ first batch is significantlyhigher than the remaining factors along theiteration. This happens because the remaining partitionfactors are calculated following a more conservativeestimation that compensates for workers that arebusy when the corresponding tasks are distributed.This continuous adaptation during the iterationimplies changes of the the partition factor valuein the application using dynamic instrumentation,which means intrusion into the master process, generatingoverhead in application execution.Regarding scenario 3, starting with two workers,MATE receives the data for each iteration, evaluatesthe performance model, and detects the need foradding or removing workers. Figure 3 shows howcomputational load variations cause changes in thenumber of workers in the application. These variationsare due to varying condition in the weather,wind, vegetation or topology as the fire line progresses,and consequently the calculation of the newfire front may have a greater or lesser complexity. Itcan be observed that the execution time of Xfire withMATE is close to the best execution time obtainedby different fixed number of workers, even taking intoFig. 2.Partition factor over five iterations of Xfire executionaccount the overhead introduced by MATE.When all the functionality implemented in the tunletis applied to Xfire, in scenario 4, the effect of theoverhead introduced by the tuning tool is once againnoticeable, especially due to the characteristics of theload balancing strategy.Taking into account the results obtained, the currentcentralised version of MATE would be usefulfor applications which have data dependent behaviouror change during each execution, beingcomputationally expensive and presenting long runtimes.Thus the overhead that centralised performanceanalysis can generate (management of eventsand instrumentation) may be offset by the cost ofre-run the applicationVI. Related WorkMATE presents an approach that automaticallyand dynamically improves the performance of parallelapplications. This approach is based on the useof dynamic instrumentation and performance modelsas the intelligence engine of the analysis process. Currently,there are other tools which perform dynamictuning processes.Autopilot [14] is a project for dynamic performancetuning in heterogeneous environments. It isbased on the use of real-time techniques, which dynamicallyadapt the system to different demands andresource availability. Similar to MATE, Autopilotmonitoring process is based on dynamic integrationof sensors, which extract information about the application.The information analysis and decision proceduresare performed using fuzzy logic. The applicationtuning is done by dynamically inserting actua-Fig. 1. Execution time of the conducted experiments in orderto study the MATE overheadFig. 3. Evolution of the number of workers with a variablecomputational loadJP2011-617

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tor processes that adjust the application behaviour.This requires knowledge about the application.Active Harmony [15] is a framework, which allowsdynamic adaptation of an application to the networkand available resources using automatic adjustmentof algorithms, data distribution and load balancing.Its structure is based on a client-server model. Theclient is the harmonised application, which sends performanceinformation to the server. The server performsthe tuning based on this information. In thistool, the monitoring process gathers measures forvarious libraries with the same functionality. Then,it uses heuristic techniques to explore the applicationoptimisation space and to adjust the tuning values.Thetuning process is based on choosing the bestimplementation among the libraries.PerCo [16] is a framework for performance monitoringin heterogeneous environments. It is ableto manage the distributed execution of applicationsusing migrations, for example, in response to changesin the runtime environment. PerCo monitors executiontimes and reacts according to a control strategyto adapt the performance when significant changesoccur in the application behaviour. The performanceanalysis and tuning process is performed using historicaldata, and combining time series and data adjustmentmethods.The main difference between MATE and presentedtools is in the analysis phase. In MATE, the analysisis based on performance models, whereas Autopilot,Active Harmony and PerCo use fuzzy logic, heuristictechniques, and historical data and time seriesrespectively.VII. Conclusions and future workAchieving high performance for parallel applicationsis a complicated task that requires a high degreeof experience, especially when dealing with applicationswith dynamic behaviour, or those runningon heterogeneous systems. In these cases, the automaticand dynamic tuning performance is the mostadequate approach. MATE is a tool that implementsthis approach for tuning applications’ performance.In this work, the implementation of a theoreticalperformance model for Master/Worker applicationsand its integration into MATE has been presented.MATE has been extended to improve applicationperformance by balancing the load and determiningthe appropriate number of workers. The performancemodel has been encapsulated in a MATEcomponent called a tunlet. To correctly design anddevelop the tunlet, it has been necessary to identifyand interpret the relation between the performancemodel, the type of tuned application, and the tuningtool. The developed tunlet can be used to tune otherapplications based, as in the case of Xfire, on iterationsand a Master/Worker paradigm. It would onlybe necessary to adapt the application to the tuningprocess, adjusting the names of certain functions andtuning variables.The experimental results show the effectivenessof the use of performance models for dynamicallytuning parallel applications. However, the experimentsalso show that MATE has scalability problems,which are related to the volume of data collectedand the centralised performance analysis. Ourcurrent work [17] is focused on studying how to distributethe performance analysis and implement anew version of MATE with architecture capable ofovercoming the current scalability barriers.AcknowledgmentThis research has been supported by the MICINN-Spainunder contract TIN2007-64974.References[1] M. Geimer, F. Wolf, B. Wylie, E. Ábrahám, D. Becker,and B. Mohr, “The SCALASCA Performance ToolsetArchitecture,” in Int. Workshop on Scalable Tools forHigh-End Computing, Kos, Greece, 2008, pp. 51–65.[2] S. Benedict, V. Petkov, and M. Gerndt, “PERISCOPE:An Online-based Distributed Performance AnalysisTool,” in Int. Workshop on Parallel Tools for HPC,2009.[3] Morajko A., Dynamic Tuning of Parallel/DistributedApplications, Ph.D. thesis, Universitat Autònoma deBarcelona, 2003.[4] B. Buck and J.K Hollingsworth, “An API for RuntimeCode Patching,” The Int. Journal of High PerformanceComputing Applications, vol. 14, pp. 317–329, 2000.[5] A. Morajko, T. Margalef, and E. Luque, “Design andImplementation of a Dynamic Tuning Environment,” J.Parallel Distrib. Comput., vol. 67, pp. 474–490, 2007.[6] E. Cesar, A. Moreno, J. Sorribes, and E. Luque, “ModelingMaster/Worker Applications for Automatic PerformanceTuning,” Parallel Comput., vol. 32, no. 7, pp.568–589, 2006.[7] I. Banicescu and V. Velusamy, “Load Balancing HighlyIrregular Computations with the Adaptive Factoring,” inProc. of IPDPS Conference, 2002.[8] A. Morajko, P Caymes-Scutari, T. Margalef, andE. Luque, “Automatic Tuning of Data Distribution UsingFactoring in Master/Worker Applications,” in Int. Conferenceon Computational Science, 2005, pp. 132–139.[9] A. Morajko, E. César, P. Caymes-Scutari, T. Margalef,J. Sorribes, and E. Luque, “Automatic Tuning of Master/WorkerApplications,” in Euro-Par, 2005, pp. 95–103.[10] P. Caymes-Scutari, A. Morajko, T. Margalef, andE. Luque, “A Methodology for Transparent KnowledgeSpecification in a Dynamic Tuning Environment,” Software:Practice and Experience, 2011.[11] J. Jorba, T. Margalef, E. Luque, J. Andre, and D. Viegas,“Application of Parallel Processing to the Simulation ofForest Fire Propagation,” in Proc. of ICFFR, Coimbra,Portugal, 1998, vol. II.[12] J.C.S. André and D.X. Viegas, “A Strategy to Model theAverage Fireline Movement of a light-to-medium IntensitySurface Forest Fire,” in Proc. of ICFFR, Coimbra,Portugal, 1994, pp. 221–242.[13] P. Caymes-Scutari, A. Morajko, T. Margalef, andE. Luque, “Scalable Dynamic Monitoring, Analysis andTuning Environment for Parallel Applications,” J. ParallelDistrib. Comput., vol. 70, no. 4, pp. 330–337, 2010.[14] R. Ribler, J. Vetter, H. Simitci, Huseyin Simitci, andDaniel A. Reed, “Autopilot: Adaptive Control of DistributedApplications,” in Proc. of IEEE Symposium onHPDC, 1998, pp. 172–179.[15] C Tapus, I-Hsin Chung, and J.K Hollingsworth, “ActiveHarmony: Towards Automated Performance Tuning,” inProc. from the Conference on High Performance Networkingand Computing, 2003, pp. 1–11.[16] K.R Mayes, M. Luján, G. D. Riley, J. Chin, P. V.Coveney, and J. R. Gurd, “Towards Performance Controlon the Grid,” Philosophical Transactions: Mathematical,Physical and Engineering Sciences, vol. 363, no. 1833,pp. 1793–1805, 2005.[17] A. Morajko, A. Martinez, E. Cesar, and J. Sorribes,“MATE: Towards Scalable Automated and Dynamic PerformanceTuning Environment,” in Proc. PARA 2010,Reykjavik, 2010.JP2011-618

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Análisis de un sistema Android comoplataforma para juegos de realidad aumentada.Andrés L. Sarmiento, Margarita Amor, Carlos V. Regueiro y E. J. Padrón 1Resumen— En este trabajo analizamos las capacidadesde un smartphone con Android. El objetivo esdeterminar las facilidades y limitaciones que ofrecela plataforma para desarrollar juegos de realidad aumentadaque integren imágenes virtuales con el mundoreal usando la información obtenida mediante lacámara y los sensores de posicionamiento. El análisisque se presenta cubre tres campos: las capacidades deposicionamiento de los dispositivos móviles actuales,la información obtenida mediante la cámara y las facilidadesde síntesis de gráficos. El rendimiento, medidoen términos de fotogramas por segundo y latencia, hasido probado en diferentes dispositivos. Se ha desarrolladoun juego de realidad aumentada como ejemplode aplicación, tratando de combinar calidad, rendimientoy velocidad de respuesta.Palabras clave— Realidad aumentada, Android, posicionamiento,visión artificial.I. IntroducciónLOS teléfonos inteligentes (smartphones) reúnencaracterísticas tales como teléfono móvil, agendaelectrónica, navegador GPS, cámara de fotos oconsola de videojuegos. Existen cuatro o cinco sistemasoperativos para estos teléfonos inteligentes. Elsistema Android [1] presenta un contexto opensourcecon un entorno de desarrollo multiplataforma.La realidad aumentada (RA) es una de las aplicacionesque se ha implantado sobre los dispositivosmóviles [2]. Las propuestas disponibles sobre la plataformaAndroid se pueden clasificar en tres tipos.Por una parte aplicaciones que geoposicionan objetosvirtuales en el mundo real usando los sensoresde orientación y el GPS [3–5]. La información de losobjetos a posicionar se encuentra precalculada y nose requiere excesiva precisión en el posicionamientoy orientación del smartphone.En un segundo tipo de aplicaciones los elementosse generan en una escena virtual que se muestra enla pantalla del móvil [6,7]. Se utilizan los movimientosdel dispositivo y su orientación respecto al campomagnético terrestre y al centro de la Tierra (gravedad)para establecer o actualizar el punto de vistade la escena que se muestra en la pantalla.Una tercera aproximación utiliza la visión artificial[8–10]. Procesan la imagen percibida y utilizanesta información para situar modelos virtuales. Habitualmenteusan marcadores (tags) para interpretarmejor la imagen. Existen muy pocas aplicaciones deeste tipo en Android y las pocas que existen no sonmás que meras demostraciones técnicas.En este trabajo pretendemos avanzar en ésta últimalínea, ya que en un entorno dinámico y comple-1 Grupo de Arquitectura de Computadores, Universidadeda Coruña, e-mails: margamor@udc.es, cvazquez@udc.es,emilioj@udc.esjo, parece que la mejor manera de integrar la informaciónsintética con el entorno inmediato es utilizartanto los datos de la cámara como los datos deposicionamiento del dispositivo (GPS, brújula, acelerómetros).Obviamente, ello implicará mayor cargacomputacional y mayor complejidad de la aplicación.Dado que Android es relativamente nuevo, hacerun análisis de viabilidad de la aplicación que se quieredesarrollar es obligatorio.II. Análisis de las capacidades de unsistema Android con OpenGL ESEn esta sección se presenta el análisis de la plataformaAndroid. Los dispositivos usados (tabla I)cubren la mayor parte de las posibilidades del mercadoactual. En primer lugar, se realiza un análisisde la información que se puede extraer del entorno apartir de los datos de la cámara. En segundo lugar,se presenta un estudio de las posibilidades de posicionamientoy seguimiento del dispositivo móvil ensu entorno. En tercer lugar, se comprueban las posibilidadesde rendering en tiempo real de modelosrealistas.A. Captura y procesado de la imagenEn el caso de que solo se quiera visualizar la imagenobtenida mediante la cámara, ésta se añade alas capas mostradas por la aplicación, cosa que Androidhace de forma muy eficiente. En caso de que sedeseen procesar los datos obtenidos, las imágenes aprocesar se obtendrán en el formato especificado alconfigurar la cámara. En el caso de los dispositivosde prueba solo es aceptado el formato YUV.Procesar imágenes es muy costoso computacionalmentecon lo que es imprescindible realizarlo en unhilo distinto al que ejecuta la interfaz gráfica paraevitar que ésta se congele y deje la aplicación en unestado de no respuesta. Por otra parte, también esrecomendable programar tal procedimiento en códigosnativos como C o C++ e integrarlo usando elNDK [11] proporcionado en Android, ya que se consiguenmejoras en la velocidad de ejecución, de hastael 400 %.Como primer paso de nuestro análisis hemos estudiadola frecuencia máxima a la que se pueden capturarimágenes para comprobar el límite superior delrendimiento. El resultado en el Motorola Milestonecon la versión 2.1 de Android ha sido 9,3 fps configurandola cámara a 30 fps de frecuencia máxima y8,8 fps configurando la cámara a 10 fps de frecuenciamáxima. Estos resultados no son excesivamentebuenos para nuestros objetivos.JP2011-619

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA I: Características técnicas de los smartphones usados en los experimentos.Motorola Milestone GeeksPhone One Samsung Galaxy SAndroid 2.1 Eclair 2.2 Froyo 2.2 FroyoCPU ARM Cortex A8 ARM11 Samsung550 MHz 528 MHz Hummingbird 1 GHzGPU PowerVR SGX 530 integrado CPU PowerVR SGX 540Memoria 256 MB 256 MB 512 MBPantalla 3.7” 854x480 3.2” 400x240 4” 800x480GPS Si Si SiAcelerómetros Si Si SiBrújula Si No SiCámara Si Si SiTABLA II: Fotogramas por segundo para captura deimagen, decodificación y visualización.Max. FPSTamaño imagen Milestone-30 Milestone-10560×320 3,25 3,90280×320 3,90 4,45280×160 4,50 4,95140×160 4,60 5,1015×15 4,65 5,15TABLA III: Fotogramas por segundo para capturade imagen, decodificación y visualización en dispositivoscon Android 2.2.GeeksPhoneGalaxy STamaño Max. FPS Tamaño Max. FPS400×240 3,9 800×480 5,70200×240 4,5 400×480 7,10200×120 5 400×240 8100×120 5,50 200×240 8,7515×15 5,80 15×15 9,20Como segundo paso, hemos extendido nuestro estudioa la visualización de imágenes en pantalla. Paraello, en Android, la imagen tiene que estar codificadaen RGB. Como los dispositivos de prueba solo entregabanlas imágenes codificadas en formato YUV, espreciso recodificarlas. En la tabla II se muestran losresultados obtenidos en un Milestone. El tamaño dela imagen que otorga la cámara del Milestone no esigual al de la pantalla, por lo que el SO la escala automáticamente.Como se puede comprobar el valormáximo es de 5,15 fps, lo que imposibilita mostrar enpantalla una secuencia fluida de imágenes. Ademásse ha observado que las imágenes se visualizan conuna latencia aproximada de 2 segundos. Los mejoresresultados se obtienen configurando la cámara a10 fps, lo cual es razonable porque se evita saturar laaplicación con imágenes que no es capaz de procesar.Aunque existe una apreciable mejora en la capturareduciendo el tamaño de la imagen (25 % fps con 1/4de la imagen) el resultado es inferior a 5 fps.En una tercera fase hemos segmentado la imagenpor colores. Los resultados obtenidos son muy similaresa los de la tabla II lo cual indica que el mayorcoste se centra en la captura y posterior recodificaciónde las imágenes para su visualización.De los resultados se puede concluir que la frecuenciade procesamiento es baja, aún implementandotodas las mejoras propuestas para ganar eficiencia,tales como procesar la imagen en un hilo aparte yusando la herramienta NDK. Parece que este comportamientoes debido a la ineficiencia del sistemaoperativo para tratar imágenes. Por cada imagencapturada se reserva la memoria necesaria, se guarda,se procesa y se elimina la referencia a dicha porciónde memoria [12]. En Java no se libera la memoriaautomáticamente, sino que el recolector de basura oGC (Garbage Collector) se encarga de hacerlo. Esteproceso es muy costoso y poco eficiente. En Androidconsume entre 100 y 300 milisegundos. Al no reutilizarla memoria asignada a cada imagen el recolectorde basura debe activarse muy a menudo.La versión 2.2 de Android incluye nuevos métodosque permiten especificar el buffer al que se copiala imagen, eliminando así la necesidad de reservar yliberar memoria para cada imagen capturada.Los resultados de las pruebas se muestran en latabla III.En el Galaxy S la mejora es de 50 % (de3,90 a 5,70) teniendo en cuenta un aumento del 50 %en el tamaño de las imágenes a procesar. El retardode visualización de las imágenes también ha bajadoa aproximadamente 1 segundo. Sin embargo, siguesiendo imposible trabajar en tiempo real únicamentecon las imágenes obtenidas por la cámara. Es necesariala ayuda de otros sensores para conocer el estadodel smartphone en el mundo que lo rodea.B. Sensores de posicionamiento integradosEn esta sección se analizan las posibilidades de posicionamientode un smartphone mediante el uso deacelerómetros, brújulas, GPS y triangulación de redde telefonía. Se describe cada sensor y los resultadosobtenidos en un Milestone, siendo similares en elresto de dispositivos.Un acelerómetro mide la aceleración a la que se vesometido, es decir, el cambio en su velocidad. Nor-JP2011-620

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3: Modelo de prueba en OpenGL ES.Fig. 1: Valores obtenidos por los acelerómetros delMotorola Milestone mientras el usuario camina.Fig. 2: Valores obtenidos por las brújulas del MotorolaMilestone.malmente un dispositivo contiene tres acelerómetros,uno en cada eje. Los acelerómetros se pueden utilizarpara saber la posición relativa del dispositivo conrespecto al suelo, suponiendo que la fuerza de la gravedades la fuerza dominante. La precisión no es muyalta, pero es aceptable para la mayoría de las aplicaciones.En la figura 1 se muestran los datos cuandoel usuario coge el móvil en vertical y avanza en línearecta. El eje Z es el de avance, el Y es el perpendicularal suelo y el X es el lateral. En la figura 1 sereconoce un patrón regular de casi un paso cada segundo(crestas en el eje Y ). En el eje X se observa elmovimiento lateral según cada pisada. Movimientosalgo más complejos serían difíciles de reconocer.Una brújula digital mide la dirección de los camposmagnéticos presentes en su entorno, especialmente elcampo magnético de la Tierra. Normalmente en losdispositivos móviles se integran tres brújulas colocadasen cada eje del espacio [13]. En la figura 2 semuestran los resultados obtenidos en un giro bruscoen un sentido y volver a la posición inicial con un giromucho mucho más suave, durante unos 3 segundos.Se puede observar que la brújula se adapta lentamenteante cambios bruscos, generando medidas incorrectas.Ante giros suaves la brújula es mucho másfiable.Para calcular la orientación del dispositivo en An-droid se recomienda recoger la información de losacelerómetros y las brújulas. Un aspecto interesantede este método es que se le puede indicar que posicióntendrá por defecto el móvil durante el uso de nuestraaplicación, es decir, la posición relativa de sus tresejes con respecto al mundo real, lo que permitirá obtenermedidas más precisas para esa configuraciónespecífica. Como hemos visto, ante cambios suavesel cálculo de la orientación del dispositivo en su entornoes relativamente fiable. Sin embargo, determinarel desplazamiento (cambio de posición y orientación)es mucho más complicado y sensible a errores,ya que es necesario integrar dos veces la aceleraciónmedida después de eliminar la fuerza de la gravedad(según la orientación calculada por la brújula).El GPS es un sistema de posicionamiento portriangulación vía satélite. Puede ser usado en todoel mundo siempre que haya el suficiente número desatélites visibles. Dentro de un edificio las medidasson poco precisas y mayoritariamente no hay cobertura.Las medidas obtenidas indican la posición deldispositivo en la esfera terrestre, contando con unaprecisión de unos pocos metros. Además no proporcionainformación fiable sobre la orientación o inclinacióndel dispositivo. Por otra parte, se ha observadoque los datos se generan con un retraso de entre 1y 2 segundos. La precisión del sistema es de 10 metrosen exteriores. Por todo ello, no es posible posicionary mover con realismo objetos virtuales próximos aldispositivo.El posicionamiento por red calcula la posición portriangulación usando la cobertura de la red de telefoníamóvil. Este sistema tiene aun menos precisiónque el GPS. A su favor cuenta con que tiene un tiempode inicialización mucho menor y consume menosbatería, ya que no utiliza ninguna otra señal que lade telefonía. Otra de sus ventajas es que puede serusado en interiores, lugares donde el GPS no tieneun buen funcionamiento. De cualquier modo, ambossistemas no son excluyentes.C. Síntesis de gráficos en AndroidEl API para la síntesis de gráficos incluido en Androides OpenGL ES [14]. Una de las principales característicasde la versión para sistemas empotradosde OpenGL es que solo existe un tipo de primitivasJP2011-621

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IV: Análisis del rendimiento de OpenGL ES en un sistema Android.Frecuencia (fps)Puntos GeeksPhone Milestone Galaxy SC1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C43 K 35 35 35 33 30 30 30 30 55 55 55 559 K 18 19 19 15 30 29 29 28 55 55 55 5515 K 12 10 10 10 29 26 26 25 55 55 55 5530 K 8 - - - 25 22 22 19 55 55 55 5575 K - - - - 18 15 15 12 55 53 53 50100 K - - - - - - - - 55 44 44 41que es el triángulo. Con el objetivo de analizar el rendimientoobtenido en la síntesis de gráficos, se hanrealizado distintos experimentos con los dispositivosde la tabla I.La primera prueba consistió en comprobar el rendimientoa medida que se iban aumentando el númerode primitivas a sintetizar. Los resultados para elmodelo de la figura 3 se muestran en la columna C1de la tabla IV. Se puede observar que efectivamenteel rendimiento empeora a medida que aumenta elnúmero de polígonos que se sintetiza salvo para elGalaxy S, en el que se percibe una pérdida de rendimientoa partir de los 300K puntos.En la columna C2 de la tabla IV se ven los resultadosde añadir una textura a los modelos. La inclusiónde texturas mejora notablemente el aspecto visualdel entorno virtual a costa de suponer una pérdidamínima de eficiencia, como mucho de un 17 % cuandose utiliza un modelo de 75.000 puntos en el Milestone.En la columna C3 de la tabla IV se presentan losresultados de las pruebas de inclusión de transparencias.Su presencia apenas tiene influencia con respectoa la síntesis con texturas.En la columna C4 de la tabla IV se muestran losdatos al incluir iluminación. En este caso el rendimientollega a decrecer un 24 % para el Milestone enuna escena con 30K puntos. Esta pérdida de rendimientoes debida a los cálculos adicionales para determinarel color de cada píxel de la escena. Hay quedefinir las luces presentes en la escena, indicando suposición, tipo, color e intensidad y se debe dotar denormales a cada vértice del modelo.De los posibles métodos de animación hemos analizadola inclusión de morphing [15]. Esta técnica consisteen, disponiendo de un modelo inicial y de unmodelo final, calcular mediante interpolación los estadosintermedios de los puntos que componen dichomodelo en una metamorfosis entre ambos modelos.La técnica tiene un gran coste computacional, ya quepara cada fotograma se debe calcular la posición decada uno de los puntos que componen el modelo.Para probar el rendimiento después de incluir estaopción se utilizó el modelo, de unos 800 puntos y 300polígonos, que se muestra en la figura 4, con texturase iluminación. La tabla V muestra los fps para variasescenas con el modelo de la figura 4 replicado variasveces. Sin embargo, los resultados obtenidos aplican-TABLA V: Comparativa de escenas con modelosestáticos contra escenas con modelos dinámicos.Puntos GeeksPhone Milestone Galaxy Sest anim est anim est anim800 40 21 30 30 55 551,6 K 32 14 30 25 55 552,4 K 27 10 30 18 55 554 K 21 6 30 10 55 518 K - - 27 5 55 2912 K - - - - 55 2016 K - - - - 55 15Fig. 4: Animación mediante técnicas de morphing. Ala izquierda el estado inicial y a la derecha el estadofinal.do morphing gozan de gran calidad, por lo que sepuede optar por incluirlo con modelos de 1.6K enel Milestone y de 8K en el Galaxy S para dotar demayor realismo a la escena creada.D. DiscusiónUna vez realizado este primer análisis de la plataformase obtienen varias conclusiones. Por una parte,se ha comprobado el funcionamiento de los sensoresde posicionamiento integrados. Los acelerómetros yla brújula obtienen resultados relativamente fiablescon errores no demasiado grandes. El GPS presentaun error demasiado grande para usarlo en una aplicacióncomo la que se propone en este trabajo, quenecesitaría conocer desplazamientos de, como máximo,un metro.Por otra parte, se ha descubierto una gran carenciaen cuanto al tratamiento de imagen en la plataforma,principalmente en cuanto a la latencia. Lasaplicaciones de realidad aumentada más habitualesen otros entornos hacen un análisis complejo de laJP2011-622

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA VI: Frecuencia en fps de la aplicación en susdistintos estados.(a) BatGhost(b) HulkGhostMilestone GeekPhone Galaxy SEstado Cám Ogl Cám Ogl Cám OglImagen +síntesis 3,25 15 2,75 8 4,1 35Imagen +morphing 2,75 8 2,5 3 3,6 23Síntesis 30 21 44Morphing 28 17 41(c) EmGhostFig. 5: Modelos tridimensionales.(d) SuperGhostFig. 6: Detección de eventos en el juego.información obtenida de la cámara y ubican los objetosvirtuales usando principalmente esa fuente deinformación. En vista de los resultados obtenidos ennuestro análisis, este tipo de aplicaciones se hacen actualmenteinviables en los dispositivos Android probados.Por último, en cuanto a la síntesis de gráficos, seha observado que existen limitaciones de tamaño yen la complejidad del modelo que se puede visualizar.Por los resultados obtenidos en las pruebas realizadas,se ha comprobado que el hardware gráficoresulta lo suficientemente potente como para representarmodelos no muy complejos usando texturase iluminación. Por ello, para la aplicación se usarántodas las capacidades estudiadas para intentar crearunos modelos gráficos atractivos pero limitando lacomplejidad del modelo para obtener tiempo real.III. Juego de RA en un sistema AndroidLa aplicación que se pretende crear es un juegoque, analizando la imagen tomada por la cámara entiempo real, determine la presencia de enemigos queel jugador deberá cazar. Para buscar un enemigo sedebe encontrar un objeto real de un color determinado.Cada tipo de enemigo aparece ante un tipo deevento distinto. Con ese objetivo del juego, un primerrequisito será mostrar elementos virtuales sobrela imagen obtenida de la cámara. Dichos elementosdeberán simular encontrarse en el mundo real, por loque ante un movimiento de la cámara ellos deberánmoverse también. Se pretende cazar los enemigos,que reaccionan de manera distinta ante cada disparo.Cuando se da caza a un enemigo, se obtiene unarecompensa en forma de puntos y de un número aleatoriode disparos extra. Por otra parte, si un enemigonos golpea perderemos una vida. Cuando nuestronúmero de vidas sea cero se perderá la partida.Existirán varios tipos de enemigos, con distintosmovimientos y características de rendering cada unode ellos: BatGhost (figura 5a), fue diseñado comoejemplo de animación por partes. Sus alas se muevenindependientemente dando sensación de aleteo,HulkGhost (figura 5b) fue diseñado como ejemplode animación mediante técnicas de morphing consistenteen un parpadeo, abriendo y cerrando su ojo,EmGhost (figura 5c) se diseñó pensando en crear unenemigo que rebotase, saltando por encima del jugadory SuperGhost (figura 5d) se diseñó con el objetivode crear un enemigo que se moviese en torno al jugador,mientras se acerca cada vez más a él.A la hora de ejecutar la síntesis de gráficos medianteOpenGL ES, el sistema operativo se encargaautomáticamente de hacerlo en un hilo distinto alprincipal, permitiendo de este modo desacoplar suejecución. Siguiendo las recomendaciones dadas porlos desarrolladores de Android [16], se ha evitado lallamada a métodos a través de una interfaz, eliminandolas interfaces incluidas por motivos de facilitarla reusabilidad del código, por necesitar más tiempopara realizarse. Además se ha intentado en la mayormedida posible las reservas de memoria, evitandocrear objetos nuevos y utilizando en la medida de loposible tipos de datos primitivos.IV. Resultados experimentalesEn esta sección se presenta el rendimiento obtenidocon la aplicación en términos de fotogramas porsegundo. En la tabla VI se muestran los resultadosobtenidos calculando el rendimiento de los aspectoscríticos de la aplicación durante una serie de ejecucionestípicas.En el Motorola Milestone la frecuencia de procesadode imágenes de la cámara varía de los 3,25 fpscuando no se encuentran enemigos visibles a los 2,75fps cuando hay un enemigo animado con morphing.Por otra parte, la síntesis de gráficos presenta unaJP2011-623

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011frecuencia de refresco de unos 15 fps, cayendo hastalos 8 fps con un solo modelo animado presente en laescena.En el GeeksPhone One la frecuencia de procesadode imágenes es algo menor, situándose en un máximode 2,75 fps. Como se observa, la mayor pérdida en elrendimiento se nota en el apartado gráfico. Mientrasse está procesando la imagen tomada de la cámara,los valores de síntesis de gráficos son un 50 % menosque los valores obtenidos con el Motorola Milestone.En el Galaxy S los resultados son mejores, obteniendouna frecuencia de procesado de imagen entre3,6 y 4,1 fps junto con una frecuencia de síntesis degráficos de 35 fps en síntesis de modelos estáticos y23 con un modelo animado, siendo en este apartadográfico en donde más se percibe la mejoría.Por otra parte, y debido también a la pérdida derendimiento en el procesado de la imagen, el retardode las imágenes obtenidas desde la cámara ha aumentado,situándose en esta aplicación en valores cercanosa los 2 segundos.Como se ha comentado anteriormente, se ha decididootorgar movimiento propio a los enemigos, nopermaneciendo anclados a la posición en la que sehan detectado. Teniendo esto en cuenta, y que solose permite un único enemigo simultáneamente, sepuede evitar el procesado de la imagen cuando existeun enemigo activo. Con esto se ha conseguido unamejora notable en cuanto al rendimiento de la síntesisde gráficos, consiguiendo unos 30 fps en el Milestone,unos 21 fps en el GeeksPhone y unos 44 fps en elGalaxy S, unos números suficientemente altos comopara conseguir una fluidez muy aceptable en el juego.V. conclusionesEn este trabajo se presenta un estudio de las capacidadesde los smartphones que incluye un análisisde sus posibilidades de posicionamiento en su entorno.Podemos concluir que obtener la orientacióndel dispositivo es relativamente sencillo y fiable, peroconocer el desplazamiento del dispositivo se hacemuy complicado. Calcularlo mediante los valores obtenidospor los acelerómetros es poco fiable (por loserrores cometidos en la doble integración) y, por otraparte, los sistemas de geolocalización tienen un margende error demasiado grande (unos 10 metros) paranuestros requisitos.Otro punto del estudio ha sido comprobar qué informaciónse puede extraer de la cámara y con qué limitaciones.El número de fotogramas que se puedenvisualizar es de menos de 6 por segundo. Incluir otrosprocesamientos (como la segmentación por colores)no tiene un impacto apreciable. La principal limitaciónes la latencia con la que se visualiza la imagen:cerca de un segundo en el mejor de los casos.Con respecto a la síntesis de imágenes con la libreríaOpenGL ES, se ha probado la inclusión detexturas, iluminación y transparencias, observandoun rendimiento aceptable en escenas de hasta 15Kpuntos en un móvil de gama media como el MotorolaMilestone. La utilización de morphing implica unapérdida de rendimiento de más del 20 % cada vez quese dobla la cantidad de puntos.Para mostrar las posibilidades de los smartphonesutilizados se ha implementado un juego sencillo derealidad aumentada. El rendimiento final obtenidodel juego es de 3,25 imágenes extraídas de la cámarapor segundo y de 28 fps en la síntesis de gráficos enun dispositivo de gama media-alta como el MotorolaMilestone. Estos resultados mejoran en un móvil conmás potencia como el Samsung Galaxy S (con 4,1imágenes procesadas por segundo y 35 fps de síntesis)y empeoran notablemente en uno menos potentecomo el GeeksPhone One (2,75 imágenes procesadaspor segundo y síntesis a 8 fps).AgradecimientosDeseamos agradecer a la Xunta de Galicia por lafinanciación de los proyectos 08TIC001206PR, INCI-TE08PXIB105161PR e INCITE08PXIB262202PR yal Ministerio de Ciencia e Innovación, cofinanciadopor fondos FEDER de la Unión Europea, por losproyectos TIN2010-16735 y TIN2009-07737.Referencias[1] Marko Gargenta, Learning Android, O’Reilly, first edition,2011.[2] Daniel Wagner and Dieter Schmalstieg, “Making augmentedreality practical on mobile phones,” IEEE ComputerGraphics and Applications, vol. 29, no. 3, 2009.[3] Google Inc., “Google navigation for mobile,”http://www.google.com/mobile/navigation, Última visita:05/01/2011.[4] Layar, “Layar reality browser,” http://www.layar.com,Última visita: 05/01/2011.[5] “Spectrek,” http://www.spectrekking.com, Última visita:05/01/2011.[6] MADfirm, “Sky siege,” http://madfirm.com, Última visita:14/01/2011.[7] Quest-Com, “Droidshooting,”http://www.quest-com.co.jp, Última visita: 14/01/2011.[8] Hirokazu Kato, “Artoolkit,” http://www.hitl.washington.edu/artoolkit,Adaptado a Android por Igarashi, Atsuoen 2010, Ultima visita: 05/01/2011.[9] Novarama SL., “Invizimals,”http://www.invizimals.com, Última visita: 05/01/2011.[10] Parrot SA., “Ardrone,” http://ardrone.parrot.com, Últimavisita: 05/01/2011.[11] “Android NDK,” http://developer.android.com/sdk/ndk,Última visita: 25/05/2011.[12] “Android Google Code. Issue 2794: Camera previewcallback memory issue,”http://code.google.com/p/android/issues/detail?id=2794,Última visita: 10/01/2011.[13] “Asahi Kasei Microdevices. 3-axis electronic compass,”http://www.asahi-kasei.co.jp/akm/en/index.html, Últimavisita: 10/01/2011.[14] Dave Astle and Dave Durnil, OpenGL ES Game Development,Thomson Course Technology, first edition,2004.[15] Tomas Akenine-Möller, Eric Haines, and Naty Hoffman,Real-Time Rendering, A K Peters, third edition, 2008.[16] Chris Pruett, “Writing real time games for android,”http://www.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html,May 2009, Últimavisita: 05/01/2011.JP2011-624

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Un modelo analítico mejorado para laarquitectura CUDAM. Viñas 1 B.B Fraguela 1 M. Amor 1 y R. Doallo 1Resumen— Este artículo presenta la implementaciónde un modelo analítico para la estimación del tiempode ejecución de aplicaciones CUDA sobre una GPU.Este trabajo se basa en un modelo previo de una arquitecturaTesla que trata de estimar los ciclos de ejecuciónde una aplicación basándose en un análisis delcódigo. El modelo puede servir al programador comouna guía de las mejores opciones de implementaciónpara un determinado problema. En este trabajo sehan confrontado los tiempos estimados por el modelocon las mediciones sobre una tarjeta concreta y sedescriben algunas deficiencias detectadas en el modelooriginal. Por otra parte, y esto constituye la principalaportación de este trabajo, se ha extendido el modeloa casos que no fueron contemplados originalmente,como la gestión del ancho de banda consumido en losaccesos a memoria o el grado de coalescencia en losaccesos a memoria global.Palabras clave— GPU, CUDA, GPGPU, modeloanalítico, kernelI. IntroducciónLOS procesadores gráficos o GPUs (Graphics ProcessingUnits) hoy en día se utilizan para ejecutartareas computacionales genéricas, conociéndoseeste uso como GPGPU (o GPU de computaciónpropósito general) gracias al soporte que ofrecen alenguajes de programación como CUDA [1] de Nvidia,u OpenCL [2].Si bien aparecen constantemente nuevos lenguajesde programación que buscan reducir el tiempoque dedican los programadores a escribir programasparalelos, aún se necesita emplear mucho tiempo yesfuerzo en optimizar estos programas. Por otra parte,las especificaciones detalladas del hardware y losestudios del rendimiento teórico proporcionan informaciónque puede ser usada por el programador parala optimización de aplicaciones. En esta línea se hanpropuesto trabajos de elaboración de modelos parael análisis del rendimiento de las GPUs [3], medianteel análisis de programas [4] o mediante el empleo demicro-benchmarks [5], [6], [7].Una herramienta muy útil para ayudar a los desarrolladoresa identificar los cuellos de botella del rendimientoen un sistema computacional son los modelosanalíticos. Éste es el caso del modelo que inspiraeste trabajo [8] y que se detallará en la Sección II. Elmodelo original se aplicó a pequeños códigos de pruebas,sin embargo su utilización en códigos reales haproporcionado estimaciones bastante alejadas de losciclos reales de ejecución. En este artículo se proponeun conjunto de correcciones de las deficiencias delmodelo original y extensiones al mismo, que logran1 Grupo de arquitectura de computadores (GAC), Univ. de ACoruña (UDC), e-mails: {moises.vinas, basilio.fraguela,margamor, ramon.doallo}@udc.esuna aproximación mucho más ajustada del modeloresultante a los tiempos reales de ejecución tal comose verá en la Sección IV.El contenido de este artículo se distribuye de lasiguiente forma: en la Sección II se explica el modeloanalítico original; la Sección III presenta las deficienciasencontradas en el modelo original, sus correccionesy las extensiones aportadas. En la Sección IV sepresentan y valoran los resultados obtenidos. Finalmente,en la Sección V se exponen y argumentan lasprincipales conclusiones.II. Modelo analítico basado en elparalelismo de warpsLa arquitectura CUDA es una arquitectura multihilo,en la que el trabajo asociado a un kernel esllevado a cabo por un conjunto de hilos. Este conjuntode hilos, se estructura siguiendo una jerarquíade tres niveles lógicos. En la cima de esta jerarquíase encuentra el grid, que representa a todo el trabajoa realizar. Un grid se divide en bloques de hilosque son ejecutados en paralelo. Cada uno de estosbloques está formado por múltiples hilos donde cadauno de ellos calcula un resultado final. Existe unconcepto que se situaría entre el nivel de los hilosindividuales y el bloque de hilos, el warp. El warp esun subconjunto de hilos del bloque que comparten algunaspropiedades que no comparten con el resto dehilos del bloque, como por ejemplo el contador de instrucción,de tal forma que todos los hilos de un warpejecutan una única instrucción al mismo tiempo. Estajerarquía de hilos está soportada en la GPU porun conjunto de múltiples procesadores. Cada procesador,en adelante SM (Streaming Multiprocessor),puede ejecutar varios warps alternándose en el tiempomientras uno o más warps está esperando porvalores de memoria. Esto permite ocultar el coste deejecución de los warps que se están ejecutando concurrentemente.El modelo presentado en [8] se basa en conocercuántas peticiones de memoria pueden ser servidasjuntas (Memory Warp Parallelism o MWP),y cuántos warps pueden ser ejecutados juntos mientrasun warp está esperando por valores de memoria(Computation Warp Parallelism o CWP). El modelousa estos dos conceptos para estimar las distintassituaciones que pueden darse en la ejecución de uncódigo en GPU. Para ello, se define tramo de computacióncomo el período de tiempo durante el cual seejecutan instrucciones de un warp en un SM. Análogamente,se define tramo de espera de memoria comoel período de tiempo durante el cual las peticiones amemoria de un warp están siendo servidas.JP2011-625

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Así pues, MWP será el número máximo de warpspor SM que pueden acceder a memoria global simultáneamentedurante el período de tiempo desdeque un SM ejecuta una instrucción de memoria paraun warp, hasta que todas las peticiones de memoriapara ese mismo warp sean servidas. MWP está determinadopor el ancho de banda de memoria, porel paralelismo a nivel de bancos de memoria y por elnúmero de warps ejecutándose en un momento dado.Por otra parte CWP se definirá como el número dewarps que el SM puede ejecutar durante un tramo deespera de memoria más uno. Este uno es añadido paracontabilizar al propio warp que estaba esperandopor valores de memoria.Fig. 1: Ejemplo para 8 warps activos con CWP mayorque MWPA. Casos de ejecuciónEn este subapartado se explica el método de estimacióndel modelo empleando los conceptos deMWP y CWP. Dada una ejecución en una GPU,pueden darse las siguientes situaciones: que CWP seamayor que MWP, que MWP sea mayor que CWP oque MWP sea igual al número de warps activos.A.1 CWP es mayor que MWPLos ciclos de ejecución en este caso pueden calcularseusando la siguiente ecuación:#A W SMExec cycles = Mem cycles× +Comp p×MW P (1)MW Pdonde Comp p es el número de ciclos de cada tramode computación y se obtiene como:Comp cyclesComp p = (2)#Mem instsdonde Comp cycles es el número de ciclos de computaciónpor cada warp (véase la Ecuación 19 en [8] parasu cálculo), y #Mem insts es el número de instruccionesde memoria que ejecuta un thread. #A W SMse define como el número de warps activos por SM(#Active warps per SM en el texto original). Esteparámetro depende de las características del dispositivohardware tales como el número de registrosusados por SM, cantidad máxima de bloques activospor SM o el tamaño máximo de memoria compartidaque se puede usar por SM. Finalmente, Mem cycleses el número de ciclos de espera de memoria de cadawarp, y se halla ponderando los ciclos de esperade memoria de cada tipo de acceso (coalescente o nocoalescente) por el número de accesos de cada tipo.En la Figura 1, se muestra un ejemplo con CWPmayor que MWP para 8 warps en ejecución y contodos los tramos de computación y tramos de esperade memoria de warps diferentes. En este ejemplo elsistema puede recibir de memoria los datos de doswarps simultáneamente, y un tramo de computaciónes aproximadamente un tercio de uno de espera dememoria. Así, el SM puede terminar los tramos decomputación de 3 warps durante un tramo de esperade memoria de un warp (esto es, MWP es 2y CWP es 4 en este caso). Como resultado, 6 tramosde computación están completamente solapadosFig. 2: Ejemplo para 8 warps activos con MWP mayorque CWPcon dos tramos de espera de memoria. Por ello, sólo2 computaciones y 4 tramos de espera de memoriacontribuyen a los ciclos totales de ejecución.A.2 MWP es mayor que CWPLos ciclos totales de ejecución, en este caso, puedenser calculados usando la siguiente expresión:Exec cycles = Mem L + Comp cycles × #A W SM (3)donde Mem L son los ciclos de ejecución por cadatramo de espera de memoria.Este caso se ilustra con CWP=4 y MWP=8, en laFigura 2. Al igual que en la Figura 1 no existe ningunadependencia entre los distintos warps, por loque se pueden ejecutar sin ninguna restricción. Lostramos de espera de memoria están todos completamentesolapados con otros tramos de computación yde espera de memoria de otros warps excepto el últimowarp. Los ciclos de ejecución totales son la sumade 8 tramos de computación más un único tramo deespera de memoria.A.3 MWP igual al número de warps activosSi una aplicación no tiene suficiente número dewarps, el sistema no puede aprovechar el paralelismode warps disponible. MWP y CWP no pueden sermayores que el número de warps activos en un SM.En este caso, los ciclos de ejecución pueden sercalculados usando la siguiente ecuación:Exec cycles = Mem cycles+Comp cycles+Comp p×(MW P − 1)(4)JP2011-626

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3: Ejemplo de la evolución del sistema cuandoMWP es igual al número de warps activos: (a) 1 warp(b) 2 warpsEn la Figura 3(a) se muestra un ejemplo en el quese ejecuta un único warp activo por SM (CWP yMWP son 1). Todas las ejecuciones se efectúan deforma secuencial. Así, los ciclos de ejecución totalesson la suma de los tramos de computación y de memoria.En la Figura 3(b) se muestra la ejecución dedos warps con MWP = CWP = 2. Debido al bajonúmero de warps activos, en este ejemplo los SMsestán inactivos dos tercios del tramo de espera dememoria. El tiempo de ejecución total es aproximadamentela mitad de la suma de todos los tramos decomputación y de espera de memoria.III. Extensiones al modelo originalPodemos clasificar las mejoras propuestas sobre elmodelo presentado en [8] en dos grupos. Por un lado,está la corrección de partes del modelo que no seajustaban a la arquitectura CUDA: tratamiento delos accesos por halfwarp y de los accesos no coalescentes;y por otro lado las extensiones a fin de consideraraspectos de dicha arquitectura no contemplados enel modelo original: ponderación de lecturas y escrituras,tratamiento de las sentencias condicionales o eltratamiento del acceso a memoria de texturas y constante.También se incluyen en este apartado algunasdeficiencias encontradas en el modelo original paralas cuales nos limitaremos sólamente a describirlasya que su modelado no sería trivial.A. Tratamiento de los accesos por halfwarpEl parámetro #Coal per mw se define en [8] comoel número de transacciones de memoria que necesitaun warp para acceder a sus datos en memoria cuandose trate de un acceso coalescente. Este parámetro,toma siempre el valor uno. Según el algoritmo decálculo de la coalescencia expuesto en [9], el númerode transacciones necesarias para cubrir un warp (32hilos) son dos y no una como afirman los autores delmodelo. En consecuencia se cambió el nombre y elconcepto de esta variable por el de #Coal per mhwde tal forma que ahora sí puede tomar valor igual auno como mínimo, pues cuenta las transacciones porhalfwarp.El modelo define la variable #Uncoal per mw comoel número de transacciones necesarias para cubrirun tramo de espera de memoria originado por un accesono coalescente. Para mantener la coherencia entrelas variables #Coal per mw y #Uncoal per mw,y dado que ahora la primera variable está considerandoaccesos las transacciones por halfwarp, se decidiócambiar el rango de la segunda variable quedandolimitado inferiormente por 2 y superiormentepor 16 (2 y 16 transacciones por halfwarp, respectivamente).Por tanto se decidió cambiar también elnombre y significado de #Uncoal per mw por el de#Uncoal per mhw.B. Accesos no coalescentesEl parámetro L B W (Load bytes per warp en elmodelo original) es una media del número de bytesa los que accede un warp. Este valor se usa en elmodelo para conocer el MWP máximo limitado porel ancho de banda consumido por cada warp. Losautores describen este parámetro como “número debytes por cada warp” y se obtiene como:L B W = Datasize(typically. 4B) × #T W (5)donde #T W es el número de hilos por warp.La ecuación anterior simplifica algunos aspectosde la arquitectura CUDA. En primer lugar, esteparámetro depende del número de transacciones necesariopara cubrir un determinado warp. En segundolugar, también se debería tener en cuenta el tamañode esas transacciones, pues no es lo mismo quesean transacciones de 32 bytes que de 128 bytes. Finalmente,como cada tramo de espera de memoriatendrá propiedades distintas (grado de coalescenciao tamaño de segmentos), se deberá tener en cuentatambién el número de accesos a memoria. La correcciónse refleja en la siguiente expresión:L B W =#A M∑i=1((#T 0∑j=1T S ij)+#A M(#T 1∑j=1T S ij))En primer lugar, se trata de una media a nivel dewarp con lo que es necesario conocer el número deaccesos a memoria que ocurren por cada warp. Paraello, el sumatorio principal itera por los accesosa memoria (#A M) y se divide la cantidad de bytesaccedidos por todo el warp entre el número de accesos.Se obtiene así una media del ancho de bandaconsumido por cada tramo de espera de memoria. Ensegundo lugar, #T refleja el número de transaccionesnecesario por cada acceso a memoria medidas paracada halfwarp. Es un factor importante, ya que noes lo mismo accesos con 16 transacciones de 32 bytespor halfwarp, que accesos con 2 transacciones de 32bytes por transacción. Finalmente, T S ij se refiereal tamaño del segmento j en el acceso a memoria i.Los tamaños de segmento se hallan también con elalgoritmo de coalescencia [9].(6)JP2011-627

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011C. Ponderación de lecturas y escriturasSe ha comprobado que existe una diferencia de rendimientoentre los accesos de lectura y de escritura.Para llegar a la conclusión anterior, se realizaronpruebas cuyo código era básicamente una o variasescrituras y se confrontaron los tiempos obtenidoscon los hallados en otras pruebas con igual estructurapero sustituyendo las escrituras por lecturas. Esteestudio concluyó que la sustitución de una lecturapor una escritura significaba un notable aumento deltiempo de ejecución.Con el objetivo de ponderar el ancho de bandaconsumido por los distintos accesos a memoria segúnse trate de escrituras y lecturas, se decidió gravar elancho de banda teórico en función del tipo de acceso.La ecuación que pondera el ancho de banda es:AB avg = AB teórico ×w read+peso×AB teórico ×w write (7)donde#Mem inst readw read =#Mem insts#Mem inst writew write =#Mem instsy el valor de la variable peso fue hallado comparandoresultados de pruebas que contenían lecturas con losresultados de esas mismas pruebas tras sustituir esaslecturas por escrituras.D. Sentencias condicionalesEl concepto de divergencia aparece ligado a la ejecuciónde sentencias condicionales en una GPU. Sitodos los hilos de un warp tienen el mismo resultadoal evaluar la condición del salto, no habrá efectoalguno sobre el rendimiento normal, esto es, el SMejecutará una única instrucción para los 32 hilos. Sino es así, cada uno de los posibles caminos que tengaese salto, será serializado desactivando los hilosque no estén en el camino que se esté ejecutando enese momento. Cuando todos los caminos alternativosse hayan completado, los hilos convergerán a unúnico camino de ejecución. La ejecución secuencialde instrucciones ligado a la aparición de divergenciasupone un importante impacto en el rendimiento.Los autores del modelo original advertían que elcoste de ejecutar instrucciones de salto condicionalno era modelado en detalle. Se sugería que se contasenlas instrucciones de las dos ramas del salto tantosi se cumplía la condición de salto como si no, conel fin de obtener un límite superior en los ciclos deejecución.En este trabajo se siguieron las siguientes reglascuando se encontraba un bloque de código condicionalen un código:Condición no trivial (dependiente de datoso de cálculos): se procede de la forma habitual,separando las que sean de computación, accesoa memoria o sincronización para cada una de lasdos ramas. Se asume pues, la ejecución de ambasramas por todos los hilos.(8)(9)Condición trivial (dependiente del identificadorde hilo): Se procede como en el caso anteriorpero multiplicando el conteo de instruccionespor un factor que indique el porcentaje dehilos de un bloque que ejecutan dicha rama decódigo. Los bloques de código condicionales paralos cuales se produzca divergencia dentro de loshilos de un warp se tratarán igual que los casosde condición no trivial.E. Acceso a memoria de texturas y constanteEl modelo explicado en la Sección II, no consideraestos tipos de acceso a memoria. Debido a su importancia,en este trabajo se ha optado por abordarestos tipos de acceso.Para conseguir un buen rendimiento de la arquitecturaCUDA es clave hacer un uso adecuado de lajerarquía de memoria. Esto implica tratar de aprovecharal máximo la memoria on-chip (memoria compartida,constante y caché de texturas) en detrimentode la memoria off-chip (memoria global, memorialocal y memoria de texturas). Por tanto las memoriason-chip serán muy utilizadas, a pesar de lo cual en[8] no se contemplan ni se proporcionan guías paramodelar los accesos a las mismas. Con las siguientesconsideraciones se consigue aproximar, o al menosgeneralizar el modelo, para abordar casi toda la jerarquíade memorias.En primer lugar, los accesos a memoria de texturascercanos (localidad espacial) en tiempos cercanos(localidad temporal) van a repercutir en mejorestiempos gracias al uso de la caché de texturas. Nvidiarecomienda el uso de memoria de texturas cuando losaccesos a memoria global son no coalescentes y puedenmejorar su rendimiento si dichos accesos cumplenla localidad espacial de la que se beneficia lamemoria de texturas. Para el caso de accesos coalescenteslas diferencias de tiempo entre usar memoriaglobal o usar memoria de texturas se ha mantenidoen la mayoría de las pruebas realizadas por debajodel 10 %, sólo superando ligeramente esta cifra parael caso de accesos “espacialmente cercanos”. Desafortunadamente,el hecho de determinar si se trata deaccesos cercanos en momentos cercanos es demasiadocomplejo a partir de un código fuente. En este estudiose consideró la misma latencia para los accesos amemoria de texturas que para los accesos coalescentesa memoria global, aún siendo conocedores de laimprecisión cometida.En segundo lugar, dadas las características de lamemoria constante, la cual es cacheable y tan rápidacomo la utilización de registros si todos los hilos deun halfwarp leen la misma dirección, se consideraráneste tipo de accesos como instrucciones de computaciónde cara al modelo.F. Deficiencias del modelo originalA continuación presentamos las deficiencias encontradasen el modelo original. Se trata de dos imprecisionesdetectadas en la metodología del modeloanalítico, que influirán en el ajuste de los resultadosJP2011-628

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4: Retrasos adicionales debidos a la sincronizaciónde threads tras cada acceso a memoriadel modelo respecto a los tiempos de ejecución reales.F.1 Barrera de sincronizaciónUna instrucción de sincronizaciónsyncthreads() provoca que todos los warpsde un bloque activo se detengan hasta que todos loswarps de ese mismo bloque alcancen esa instrucción.La Figura 4 muestra el modelado de sincronizaciónconsiderado en [8]. Los warps que aparecen en lafigura son los warps activos, los cuales componenlos bloques activos. Por lo tanto, son warps que nonecesariamente pertenecen al mismo bloque, si bienserá así en la mayoría de los casos. A la hora deestimar los ciclos de ejecución se dijo, y así se puedever en la imagen, que la instrucción de sincronizaciónprovocaba el retraso de todos los warps activos. Estoes cierto si sólo hay un único bloque activo. En casocontrario, esa barrera de sincronización no debieraretrasar a todos los warps activos sino sólo a los quepertenecen al bloque cuyos warps hayan ejecutadouna instrucción de sincronización.F.2 Tramos de computación desbalanceadosTodos los escenarios de ejecución de warps activospresentados en [8] para explicar las ecuaciones decontabilización de los ciclos de ejecución en el modelo,se basan en tramos de computación aproximadamenteiguales. Es decir, cuando se tienen dos tramosde computación por warp, el segundo tramo es igualal primero. Esto no ocurre en la realidad por lo queesta simplificación puede conducir a la obtención deresultados incorrectos.IV. Resultados experimentalesLa GPU utilizada en este trabajo ha sido la NVI-DIA GTX 295. Esta GPU está constituida en realidadpor dos GPUs con 240 núcleos cada una, haciendoun total de 480 núcleos. Otros parámetrosrelevantes de este dispositivo, en particular de caraal modelo, son: 1,242 GHz de frecuencia de reloj,223,8 GB/s de ancho de banda a memoria para todoel dispositivo, y 111,9 GB/s para cada una de lasdos GPUs (son dos espacios de memoria totalmenteindependientes). La GPU NVIDIA GTX 295 esun dispositivo de capacidad de computación 1.3. Estedato será tenido en cuenta en varios puntos delmodelo tales como el número de hilos máximo porSM, el tamaño máximo de memoria compartida o elmáximo número de registros usados por cada bloquede hilos.Familia de pruebasDesviaciónmodelo extendidosumavectores 13,64 %saxpy 6,97 %simplePitchLinearTexture 0,95 %matrixMul 54,25 %sepia 23 %reduction 27,6 %FDTD 5,73 %Dct8x8 1,8 %BlackScholes 41 %Fractal 41,95 %TABLA I: Diferencias entre el tiempo estimado conel modelo extendido y el tiempo real para las distintasfamilias de pruebasPor otra parte, hay tres parámetros del modelomuy ligados a la arquitectura concreta a modelarque se obtienen mediante experimentación en [8]:Mem LD, Departure del coal y Departure del uncoal.Los autores del modelo calcularon estos valores paralos dispositivos con los que realizaron sus pruebas,entre ellos, la GPU NVIDIA GTX 280. Para este trabajose han tomado los datos de esta tarjeta, pues esun dispositivo muy semejante a la GTX 295.En lo que resta de sección se va a validar el modelocon un conjunto de 111 pruebas agrupadas enfamilias haciendo, cada una de ellas, énfasis en losdistintos componentes del modelo. La Tabla I muestraen su primera columna, el nombre de las familiasde pruebas realizadas. La segunda columna muestrala desviación entre el tiempo real y el tiempo estimadopor el modelo extendido para cada familia depruebas. Estos resultados se obtuvieron tras haberleaplicado al modelo las extensiones y correcciones propuestasen este trabajo. Pese a que la desviación enalgunos casos es considerable, debe tenerse en cuentaque el error pronosticado (13.3 %) por los autores delmodelo original sobre códigos de prueba mucho mássencillos supera de forma notable este error mediopara nuestros códigos tal y como se puede ver en lastablas mostradas a continuación.En las Tablas II y III se muestra la desviaciónde una serie de pruebas para el modelo extendidoy se confronta con la desviación obtenidapara esas mismas pruebas con el modelo originaltal y como fue propuesto en [8]. La pruebasumavectores2Lecturas suma dos vectores en untercero, sumavectores3Lecturas suma 3 vectores enun cuarto vector y sumavectoresEscritura escribedatos en un único vector sin ser necesaria ningunalectura de memoria global. Análogamente laspruebas saxpyUncoal se distinguen entre ellas por elnúmero de accesos y/o el tipo de accesos. Se puedeapreciar que aunque en error se quede fuera del rangoanunciado, en el modelo extendido se comete unerror mucho menor que en el modelo original.En resumen, las pruebas realizadas en este trabajocon el modelo original arrojaron una desviaciónJP2011-629

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Prueba Modelo ModeloNombre stride original extendidosumavectores2Lecturas 3 13,97 % 8,14 %sumavectores2Lecturas 5 13,82 % 8,96 %sumavectores3Lecturas 3 13,75 % 8,73 %sumavectores3Lecturas 5 14,34 % 9,17 %sumavectoresEscritura 3 29,21 % 18,74 %sumavectoresEscritura 5 47,05 % 20,98 %TABLA II: Desviaciones del modelo original y extendidopara pruebas de la familia sumavectoresPrueba Modelo ModeloNombre stride original extendidosaxpyUncoal 3 31,32 % 6,94 %saxpyUncoal 5 42,11 % 7,13 %saxpyUncoal 7 41,93 % 6,83 %saxpyUncoal2 3 6,82 % 4,02 %saxpyUncoal2 5 26,28 % 3,24 %saxpyUncoal2 7 26,2 % 3,13 %saxpyUncoal4 1 127,03 % 13,6 %saxpyUncoal5 1 91,77 % 3,5 %saxpyUncoal6 1 82,84 % 7,69 %TABLA III: Desviaciones del modelo original y extendidopara pruebas de la familia saxpymedia cercana al 35 % (un 21.7 % más que la desviaciónpronosticada por los autores) mientras quela desviación media obtenida para un total de 111pruebas realizadas con el modelo extendido ha sidode 19,31 %.Finalmente, la Tabla IV muestra la aplicaciónpráctica de los resultados de este trabajo mediantetres configuraciones de la prueba saxpyUncoal correspondientesa tres estrategias de implementacióndel mismo código. Vemos cómo el modelo extendidono sólo se acerca más al tiempo real, sino que ademáses capaz de determinar cuál será la versión más eficientede las tres configuraciones, en este caso, la destride = 3. Es decir, el modelo permite seleccionarcon éxito entre varias alternativas para la realizaciónde una computación más eficiente, siendo por tantoútil para guiar optimizaciones automáticas efectuadaspor un compilador, o para ayudar al programadora seleccionar el mejor código para su aplicación.En la tabla podemos ver que sin embargo, el modelooriginal no tiene la suficiente precisión como parapoder desempeñar este papel con éste código deejemplo.V. ConclusionesTras un análisis del modelo propuesto en [8] se observóque sus predicciones se alejaban en ocasionessignificativamente del tiempo de ejecución real. Sehan propuesto varias mejoras al modelo, cambiandola unidad de transacciones de memoria de warp porhalfwarp, y modificando el cálculo del tráfico en bytesque origina un acceso no coalescente, así comostride GPU Modelo Desviación Modelo Desviación(µs) original original extendido final(µs)(µs)3 219,584 150,82 45,6 % 204,35 6,94 %5 260,544 150,82 72,75 % 241,97 7,13 %7 259,712 150,82 72,19 % 241,97 6,83 %TABLA IV: Tiempos y desviaciones para tres configuracionesde saxpyUncoal en el modelo original yel modelo extendidoel ancho de banda teórico en función del número deescrituras que exista en el programa y la contabilizacióndel número de instrucciones en los bloquescondicionales; y por último, el tratamiento de los accesosa memoria de texturas y constantes tambiénha sido incluido en el modelo extendido. El error delmodelo original, en torno al 35 %, excede notablementeel error cometido por la versión extendida delmodelo desarrollado en este trabajo, que se sitúa enel 19,31 %.Si bien a veces la predicción del modelo se aleja deltiempo real de ejecución medido, la evolución comparativade sus predicciones ha sido siempre análogaa la de los tiempos de ejecución reales en los casosanalizados. Por ello, este modelo ha probado ser fiablea la hora de ayudar a decidir qué estrategias decodificación CUDA son las más apropiadas para undeterminado código.AgradecimientosEste trabajo ha sido financiado por la Xunta deGalicia bajo los proyectos INCITE08PXIB105161PRy 08TIC001206PR, y por el Ministerio de Ciencia eInnovación con fondos FEDER de la Unión Europea(proyecto TIN2010-16735).Referencias[1] NVIDIA. CUDA Compute Unified Device Architecture,v3.0 edition, 2010.[2] Khronos OpenCL Working Group. The OpenCL Specification,2009.[3] S.S Baghsorkhi, M. Delahaye, S.J. Patel, W.D. Gropp andW.W. Hwu. An adaptative performance modeling tool forgpu architectures. In Proceedings of the 15 th ACM SIG-PLAN Symposium of Principles and Practice of ParallelProgramming (PPoPP 2010), pages 105–114, 2010.[4] A. Singh J. W. Choi and R. W. Vuduc. Model-drivenautotuning of sparse matrix-vector multiply on GPUs. InProceedings of the 15th ACM SIGPLAN symposium onPrinciples and practice of parallel programming (PPoPP2010), volume 45, pages 115–126, 2010.[5] H. Wong, M.-M. Papadopoulou, M. Sadooghi-Alvandi, A.Moshovos. Desmystifying GPU microarchitecture throughmicrobenchmarking. In 2010 IEEE int. symp. on performanceanalysis of systems software (ISPASS), pages 235–246, 2010.[6] R. Taylor and X. Li. A micro-benchmark suite for AMDGPUs. In 2010 39th international conference on parallelprocessing workshops (ICPPW), pages 387–396, 2010.[7] Y. Zhang and J.D. Owens. A quantitative performanceanalysis model for GPU architectures. In Proc. of the17th IEEE Int. Symposium on High-Performance ComputerArchitecture (HPCA 17), 2011.[8] S. Hong and H. Kim. An analytical model for a GPUarchitecture with memory-level and thread-level parallelismawareness. In Proc. of the 36th Int. Symposium onComputer Architecture (ISCA ’09), 2009.[9] Nvidia. CUDA programming guide, 2010.JP2011-630

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Análisis de Escalabilidad en AplicacionesParalelas con Carga de Trabajo No EquilibradaJose Luis Bosque 1 , Oscar D. Robles 2 , Pablo Toharia 2 , y Luis Pastor 2Resumen En los sistemas paralelos actuales y futuroscon un gran número de nodos de cómputo la escalabilidades una propiedad del sistema (arquitecturamás aplicación) tan importante como el rendimiento.Por otro lado es ampliamente conocido el impactodel equilibrio de carga de trabajo en el rendimientode una aplicación paralela. Este artículo estudia larelación entre la escalabilidad de un sistema paraleloy el equilibrio en su carga de trabajo. Se proponey valida un modelo teórico, evolución de la funciónde isoeciencia, que permite modelar y predecir conprecisión esta relación. Finalmente, se presentan unaevaluación empírica del modelo así como una serie deconclusiones obtenidas de dicha validación.Palabras clave Escalabilidad, Modelos Teóricos,Equilibrio de carga.I. IntroducciónEN los últimos años, gracias a la arquitecturamulti-core el número de cores en los supercomputadoresse ha visto incrementado drásticamente.En la última lista del top500 (Noviembre 2010 [1])aparecen ya 12 máquinas con más de 100.000 cores.Esto ha hecho que la escalabilidad de las aplicacionesparalelas sea un factor que ha ganado gran importanciaen su diseño e implementación, por encimaincluso del rendimiento.Por otro lado, está ampliamente reconocido que elequilibrio de carga de trabajo tiene un fuerte impactosobre el rendimiento de un sistema paralelo y por lotanto sobre su eciencia [2]. Según la función deisoeciencia [3] la escalabilidad de un sistema paralelo(computador+aplicación) se dene en términosdel incremento necesario de carga de trabajo que setiene que producir, al aumentar el número de procesadores,para que la eciencia se mantenga constante.Por lo tanto, si la escalabilidad se dene en funcióndel tamaño del problema, es decir del número de operacionesque hay que realizar, podemos preguntarnoscuál será el impacto de un desequilibrio de carga detrabajo en una aplicación sobre su escalabilidad.En todos los trabajos presentados hasta la fecha[3], [4], [5], [6], [7] para modelar y evaluar la escalabilidadde sistemas paralelos se considera, ya sea deforma implícita o explícita, que la carga de trabajoestá perfectamente equilibrada entre los nodos delsistema. Esta hipótesis es poco realista porque, enprimer lugar, obliga a que la carga de trabajo sea continuae innitamente divisible y por otro lado, existenmúltiples fuentes de desequilibrio en sistemas paralelos,como pueden ser una mala distribución inicial,1 Dpto. de Electrónica y Computadores, Universidad deCantabria, e-mail: joseluis.bosque@unican.es.2 Departamento de ATC y CCIA, UniversidadRey Juan Carlos, e-mail:{oscardavid.robles,pablo.toharia,luis.pastor}@urjc.es.la existencia de sistemas no dedicados, en los que lasprestaciones de los nodos pueden variar a lo largodel tiempo de ejecución de la aplicación, o bien laexistencia de sistemas heterogéneos.Este artículo presenta una nueva expresión parala función de isoeciencia que permite modelar lacarga de trabajo desequilibrada, es decir una funciónde isoeciencia más general que pueda aplicarsea sistemas paralelos en los que la carga de trabajopueda estar equilibrada o desequilibrada. Hastadonde conocen los autores este es el primer trabajoque pone de maniesto este problema y que, por lotanto, propone una solución adecuada. A pesar deser eminentemente teórico, este resultado tiene ungran impacto en el diseño e implementación de aplicacionesparalelas.A partir de la nueva versión de la función de isoecienciase plantean una serie de estudios teóricos, delos que se obtienen ciertas propiedades de escalabilidadde los sistemas paralelos, considerando tanto lasobrecarga de comunicación como la debida al equilibriode carga. Finalmente se ha llevado a cabo unaevaluación experimental para validar y vericar lavalidez y corrección de los modelos propuestos.II. Escalabilidad de sistemas paralelos condesequilibrio de carga de trabajoA. Modelo del Desequilibrio de carga de trabajoPartimos de un modelo de sistema compuestopor un conjunto de m nodos, denotados por N =n 1 , · · · , n m interconectados entre sí. Todos los nodosson idénticos y tienen las mismas prestaciones. Lacarga de trabajo que se va a ejecutar en una aplicaciónviene determinada por un conjunto de operacionesbásicas que se pueden realizar en paralelo.Dicha carga de trabajo viene caracterizada por sutamaño, que denominaremos W , y se puede descomponeren una serie de unidades de cómputo.Para parametrizar su rendimiento denimos la potenciade cómputo (p) de cada uno de estos nodoscomo la cantidad de operaciones básicas por unidadde tiempo que es capaz de ejecutar.Si la carga de trabajo es continua e innitamentedivisible, el sistema estaría completamente equilibradoasignando a cada nodo la misma carga detrabajo, es decir w i = W m. En ese caso, asumiendoque no existen otras sobrecargas debido a la comunicaciónentre procesos, el tiempo de ejecución de todoslos nodos debe ser el mismo, y viene dado por lasiguiente expresión: T CP U = Wp·m ∀ n i con i ∈ 1...mSin embargo, en aplicaciones reales la carga de trabajono se puede dividir innitamente, por lo que laJP2011-631

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011asignación de carga de trabajo a cada nodo debe serun número entero. Esto da lugar a una asignaciónde carga de trabajo que no cumple por completo laexpresión anterior y que por lo tanto hace que lostiempos de ejecución sean diferentes en los distintosnodos. Existen aplicaciones en las que la unidad deasignación es una estructura de datos compleja y porlo tanto estas diferencias pueden ser grandes.Por lo tanto, en el caso desequilibrado habrá nodosque ejecutarán menos carga de la que les corresponderíaen una asignación óptima y otros a los que lestocará más. Denotamos ∆w i (puede ser positivo onegativo, para indicar más o menos carga que la óptima)la diferencia de carga de trabajo que tiene queprocesar un nodo con respecto a la carga de trabajoque se le asignaría si el equilibrio fuera perfecto. Eneste caso, la carga de trabajo asignada a cada nodoes w i = W m + ∆w i Y por lo tanto el tiempo de ejecuciónde un nodo, sin tener en cuenta las sobrecargasde comunicación (es decir el tiempo de CPU) vendríadado por la expresión:T CP U =Wm + ∆w i⇒ T CP U =Wpm · p + ∆w ip(1)Denotemos ahora T qi al tiempo empleado por elprocesador N i para procesar su carga de trabajo adicionalrespecto a la carga óptima, es decir T qi = ∆wip .Sea T q = max m i=1 { ∆wip} el tiempo empleado por elnodo que más tiempo invierte en procesar su excesode carga respecto a la distribución óptima, y que porlo tanto termina el último su trabajo (sin tener encuenta las sobrecargas debidas a comunicación). Lasobrecarga puede ser un valor constante, puede dependerde la carga de trabajo total W , o bien delnúmero de procesadores m, por lo que la deniremoscomo T q (W, m). Considerando además un tiempo desobrecarga T o (m), su tiempo de respuesta será:T R =Wp · m + T q(W, m) + T o (W, m) (2)Es importante hacer notar que así como T o aumentacon el número de procesadores en todos loscasos (a lo sumo permanece constante), T q puede disminuiral aumentar m. Esto es posible ya que podemospartir de un sistema con pocos procesadores ymuy desequilibrado, con lo que tiene un gran impactoen el tiempo de respuesta, y a medida que seincrementa el número de nodos se puede equilibraral poder hacerse un reparto mejor de los datos.B. Función de isoecienciaPara obtener la función de isoeciencia debemosen primer lugar calcular la expresión de la eciencia,que depende del tiempo secuencial y del paralelo.El tiempo secuencial necesario para resolver unproblema de tamaño W en el sistema propuesto esT S = W p, es decir toda la carga de trabajo ejecutadaen un único procesador con potencia de cómputo p.El tiempo paralelo es el presentado en la Ecuación2. Sustituyendo estos valores en la denición de eciencia,se obtiene:E =T ST R · m = 11 + m·p·(To+Tq)WPor lo tanto, para sistemas paralelos escalables laeciencia se puede mantener estable si el cocientem·(T q+T o)W, mantiene a su vez un valor constante en laexpresión anterior. A partir de ahí podemos obteneruna expresión que determine cómo debe evolucionarla carga de trabajo al escalar el sistema para que laeciencia se mantenga constante:m · p · (T q + T o )W= 1 − EE ⇒ W = E1 − E ·m·p·(T q+T o )ESea K = p ·1−Euna constante que depende delvalor de eciencia inicial. Entonces la función deisoeciencia que modela el desequilibrio en la cargade trabajo se puede expresar de la siguiente forma:W = K · m · (T q + T o ) (3)Es decir, el desequilibrio de carga se puede modelarcomo una sobrecarga más del sistema, de formaequivalente a como se consideran los tiempos de comunicación.En este caso el factor T q = ∆wmpes eltiempo adicional que tarda el procesador que tienemayor tiempo de ejecución, sobre el tiempo que emplearíasi estuviera equilibrado. Este factor, multiplicadopor la potencia de cómputo del sistema, determinael tiempo global desaprovechado en todo elsistema y por lo tanto su eciencia.Finalmente, una cuestión importante que hay queremarcar es que en un sistema paralelo, incluso sinsobrecarga de comunicación, el desequilibrio de cargade trabajo implica que el sistema no sea perfectamenteescalable. Por otro lado, aunque se modelacomo un tiempo de sobrecarga adicional que debesumarse a los tiempos de comunicación tiene una peculiaridadimportante. Mientras que la sobrecargasiempre crece al escalar el sistema, el desequilibriopuede variar de forma inversamente proporcional alnúmero de nodos. Es decir, un sistema inicialmentemuy desequilibrado puede variar a uno menos desequilibradocuando se escala.III. Influencia del Desequilibrio de Cargade Trabajo en la EscalabilidadDe la expresión anterior (Ecuación 3) se puedendeducir una serie de propiedades que relacionan laescalabilidad de un sistema paralelo con la evolucióndel desequilibrio, al escalar el sistema. Un sistemasería perfectamente escalable si T q = T o = 0. Estoes, si no existe sobrecarga de comunicación ni desequilibriode carga de trabajo, el sistema escala perfectamentey no es necesario aumentar el tamaño delproblema con el número de procesadores (siempreque todo procesador tenga asignada una parte decarga de trabajo, es decir w i > 0 ∀ i ∈ 1 . . . m).En esta sección se presentan una serie de propiedadesJP2011-632

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de escalabilidad de sistemas paralelos en función dela variación de T q y considerando T o = 0. Es decir,se estudia cómo afecta la evolución del desequilibriode carga de trabajo a medida que el sistema escalasu tamaño. La hipótesis de que T o = 0 no es realistaen la mayor parte de las aplicaciones, pero nos sirvepara aislar el efecto del desequilibrio en estos estudiosteóricos. En todos los casos consideramos unsistema paralelo de partida denido por S(m, W ) yun sistema escalado S ′ (m ′ , W ′ ), ambos con T o = 0.Si la carga de trabajo en S y S ′ se reparte entre losprocesadores, con un desequilibrio T q = c, es decirconstante e independiente de m y W , entonces elsistema es escalable sii la carga de trabajo crece deforma proporcional al número de procesadores en elsistema, es decir W es O(m).Sea T q = c ∈ R, constante para todo m y W . Lafunción de isoeciencia para este caso es:W = K·m·T q ⇒ W = K ′·m, con K ′ = K·c (4)Por lo tanto W= K ′ ·m, es decir W debe crecer deforma lineal con la potencia de cómputo del sistema,independientemente del desequilibrio del mismo.Por otro lado, si el desequilibrio depende de formalineal del número de procesadores T q = c 1·m+c 2 , conc 1 , c 2 ∈ R, y no hay ninguna sobrecarga adicional,entonces el sistema será escalable sii el tamaño delproblema crece como una función O(m 2 ). La pruebade esta armación es trivial y se obtiene reemplazandoT q en la Ecuación 3.Si la carga de trabajo en ambos sistemas se repartecon un desequilibrio que depende de forma inversamenteproporcional del número de procesadores, esdecir, T q = c1 m , con c 1 ∈ R, entonces el sistema seráperfectamente escalable ya que la función de isoecienciaes constante independientemente del tamañodel sistema, es decir W es O(K). Es necesario remarcarque si W > m, esta situación contradice lacota inferior estimada por [3] para la función de isoeciencia.Si la carga de trabajo en ambos sistemas se repartecon un desequilibrio que depende de forma lineal deltamaño del problema T q = c 1 · W , con c 1 ∈ R, entoncesel sistema es no escalable ya que al aumentarla carga de trabajo se incrementa el desequilibrio yla eciencia nunca se puede mantener constante.Finalmente, si el desequilibrio depende de formainversamente proporcional al tamaño del problemaT q = c1W , con c 1 ∈ R, entonces es trivial demostrarque el sistema será escalable sii el tamaño del problemacrece como una función de O( √ m). De nuevoen este caso el crecimiento es inferior al lineal, quees el límite inferior para los sistemas perfectamenteequilibrados, establecido por [3].IV. Combinando Sobrecarga yDesequilibrioFinalmente, en esta sección se propone un estudioteórico sobre el impacto que estos dos factores,comunicación y desequilibrio, tienen de forma combinadaen la escalabilidad de las aplicaciones paralelas.Sea un sistema paralelo S(m, W ) y un sistema escaladoS ′ (m ′ , W ′ ). La carga de trabajo se reparte entodos los casos de forma proporcional al número deprocesadores con un desequilibrio determinado porT q . Para analizar su escalabilidad según el modelopropuesto se debe modelar tanto su sobrecarga decomunicación como el comportamiento del desequilibrioa medida que se escala el sistema. Por ejemplo,si al escalar el sistema de S a S ′ , tanto el desequilibriocomo la sobrecarga son constantes e independientesde m y W , es decir T q = c 1 , y T o = c 2 , con c 1 , c 2 ∈ R,el sistema es escalable sii el tamaño del problema Wcrece de forma linealmente proporcional al númerode procesadores, es decir W es O(m).La demostración es sencilla a partir de la funciónde isoeciencia presentada en la sección anterior.W = K ·m·(T q +T o ) = K ·m·(c 1 +c 2 ) ⇒ W = K ′·mdondeK ′ = K · (c 1 + c 2 )Por lo tanto W es O(m), es decir debe crecer deforma lineal con el número de procesadores, independientementedel desequilibrio de la aplicación. Engeneral, en sistemas con una sobrecarga debida a lacomunicación entre procesos y un desequilibrio constante,entonces el desequilibrio no tiene ningún efectoen la escalabilidad del sistema. Sólo afecta a la ecienciamáxima que se puede alcanzar pero no a suevolución respecto al número de nodos, por lo que noafecta a la escalabilidad.Finalmente, un último ejemplo que puede resultarde interés considerando un sistema en el que eldesequilibrio crece de forma inversamente proporcionalal número de procesadores (T q = c1 m), mientrasque la sobrecarga de comunicación crece de formalineal también respecto al número de procesadores(T o = c 2 · m, siendo c 1 y c 2 ∈ R). En este caso puededemostrarse que W debe crecer también de formacuadrática respecto al número de procesadores, esdecir W es O(m 2 ).V. Evaluación ExperimentalEn esta sección se presentan una serie de experimentoscon el objetivo de conrmar empíricamentela hipótesis planteada en este artículo sobre la in-uencia del desequilibrio de carga en la escalabilidadde sistemas paralelos. Por otro lado, se trataráde validar el modelo de escalabilidad propuesto enpresencia de situaciones de desequilibrio de carga detrabajo, así como las propiedades enunciadas en lassecciones anteriores. El sistema sobre el que se realizanlos experimentos es un cluster de la Universidadde Cantabria denominado Altamira. Está compuestopor 256 nodos biprocesador conectados mediante unared Myrinet a 1 Gbps. Para cada uno de los casospresentados se realizarán una serie de experimentosvariando el tamaño del sistema y la carga de trabajoa resolver, realizando varias muestras por caso y midiendoen cada uno los tiempos de respuesta y comunicación.A continuación se obtienen los valores deeciencia para cada sistema y carga de trabajo. DeJP2011-633

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201110.90.82.5e+062e+06Linear IsoefficiencyIsoefficiency O(m^2)0.7Efficiency0.60.5Efficiency = 0.830.4m=20.3m=4m=80.2m=16m=320.1m=64m=12800 500000 1e+06 1.5e+06 2e+06 2.5e+06Workload (W)Workload (W)1.5e+061e+0650000000 20 40 60 80 100 120 140Number of Processors (m)(a) Evolución de la Eciencia.(b) Función de isoecienciaFig. 1.Función de isoeciencia para el benchmark Proporcional_mesta forma obtenemos una curva de evolución de laeciencia con la carga de trabajo, para cada tamañodel sistema.A. Validación del Modelo de DesequilibrioPara validar el modelo de escalabilidad en presenciade desequilibrio de carga de trabajo se han desarrolladouna serie de benchmarks ad hoc en los que noexiste sobrecarga de comunicación y por lo tanto sonperfectamente escalables, es decir tienen su funciónde isoeciencia constante O(K), con K ∈ R. Esto escierto siempre que la carga de trabajo esté perfectamenteequilibrada. Por lo tanto, partimos de la ecienciaque obtiene el benchmark en 2 nodos, y vemoscuál es su evolución a medida que el sistema se escala.En una situación de carga de trabajo equilibrada laeciencia debería mantenerse constante para todaslas conguraciones. Sin embargo veremos en estecaso que la función de isoeciencia cambia a medidaque se introducen distintos niveles de desequilibrioen el sistema y se vericará el modelo propuesto. Elvalor de todas las constantes utilizadas en los experimentosdepende tanto de las prestaciones de losnodos como de la naturaleza del problema, y todoslos valores se han medido sobre la implementaciónsecuencial de los distintos benchmarks.Se consideran cuatro variaciones distintas de la distribuciónde carga de trabajo que serán las siguientes:• Proporcional_m: Desequilibrio de carga proporcionalal número de procesadores, T q = c · m.• Inverso_m: Desequilibrio inversamente proporcionalal número de procesadores, T q = c m .• Proporcional_w: Desequilibrio de carga proporcionala la carga de trabajo, T q = c · W .• Inverso_w: Desequilibrio inversamente proporcionala la carga de trabajo, T q = c W .La gura 1(a) presenta la evolución de la ecienciaa medida que aumenta la carga de trabajo paradiferentes tamaños del sistema para el test Proporcional_m.Como se puede observar todos alcanzanla eciencia de partida (0.83) por lo que el sistema esescalable. La gura 1(b) muestra la función de isoecienciaobtenida respecto a una función lineal. ComoEfficiency10.90.80.70.60.5m=20.4m=4m=80.3m=16m=320.2m=64m=1280.10 10000 20000 30000 40000 50000 60000 70000Workload (W)Fig. 2. Evolución de la Eciencia con la carga de trabajo parasistemas con diferente número de nodosse puede apreciar la función de isoeciencia sigue unacurva parabólica, de forma que el tamaño del problemadebe crecer cuadráticamente con la carga detrabajo. Esta situación corresponde a la predicciónrealizada por el modelo teórico presentado en la secciónIII.La tabla I muestra los resultados obtenidos parala evolución de la eciencia en el test Inverso_m.La eciencia permanece prácticamente constante, entorno a 0.50, independientemente del tamaño delproblema y del número de nodos. Por lo tanto, lafunción de isoeciencia asociada a esta situación debeser constante y el sistema es perfectamente escalable,tal y como predice el modelo.La gura 2 presenta la evolución de la ecienciaen función de la carga, para el benchmark Proporcional_w.Se observa que dado un tamaño concretola eciencia permanece prácticamente constante alaumentar la carga de trabajo. Por otro lado, al aumentarel tamaño del sistema no se puede mantenerla eciencia constante, sea cual sea la carga de trabajo.Así pues, por la propia denición de la funciónde isoeciencia el sistema no es escalable.Por último, la gura 3 presenta la evolución de laeciencia (g. 3(a)) y la función de isoeciencia (g.3(b)) para un desequilibrio que varía de forma inver-JP2011-634

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IEvolución de la eficiencia para el benchmarks (Inverso_m).W 2 Nodos 4 Nodos 8 Nodos 16 Nodos 32 Nodos 64 Nodos 128 Nodos1024 0.500 0.503 0.499 0.496 0.497 0.495 0.4854096 0.500 0.503 0.502 0.499 0.498 0.498 0.49816384 0.500 0.501 0.499 0.501 0.502 0.499 0.49665536 0.500 0.498 0.499 0.501 0.498 0.500 0.502262144 0.500 0.501 0.502 0.500 0.500 0.503 0.500samente proporcional a la carga de trabajo, respectoa una función de isoeciencia lineal. Todos los nodosalcanzan la eciencia de partida por lo que se puedearmar que el sistema es escalable. La función deisoeciencia obtenida es O( √ m), muy por debajo delo que sería un crecimiento lineal.De estas cuatro situaciones se pueden obtener unaserie de importantes conclusiones. En primer lugarqueda claro el gran impacto que tiene el desequilibriode carga de trabajo en la escalabilidad de un sistemaparalelo. Efectivamente, de los resultados presentadosse desprende que el mismo sistema paralelo puedetener comportamientos de escalabilidad muy distintosen función del reparto de la carga de trabajo quese realice, llegando incluso a poder convertirse en unsistema no escalable, aunque no tenga ninguna sobrecargade comunicación. Por otro lado, los cuatro casospresentados sirven para validar la corrección delmodelo propuesto en este artículo. Todos los casoshan sido analizados de forma teórica en la sección IIIy los resultados obtenidos coinciden perfectamentecon las predicciones teóricas efectuadas.B. Inuencia del Desequilibrio en un Sistema conSobrecarga de ComunicaciónFinalmente en esta sección se verica la precisióndel modelo teórico en un benchmark que introducetanto desequilibrio de carga como sobrecarga de comunicación.La comunicación es 1 a m, por lotanto proporcional al número de procesadores, es decirT o = c 2 · m. Por lo tanto, la función de isoecienciaclásica, sin tener en cuenta el desequilibriode carga, es O(m). Se presentan, a modo deejemplo, dos situaciones de desequilibrio: desequilibriode carga constante, (T q = c 1 ) y desequilibrio decarga inversamente proporcional al número de procesadores(T q = c1 m). Por lo tanto, si tenemos en cuentalas dos fuentes de sobrecarga el modelo de escalabilidadpresentado predice una función de isoecienciade O(m 2 ). La gura 4 presenta los resultadosobtenidos experimentalmente, mostrando en amboscasos la función de isoeciencia obtenida.La gura 4(a) muestra dos resultados que se hanobtenido para la función de isoeciencia en funciónde la relación existente entre los valores de T o y T q .Estos resultados muestran el impacto que tienen enla escalabilidad del sistema los valores de las constantesc 1 y c 2 . Si estos valores son similares, comunicacióny desequilibrio tienen el mismo impacto en laescalabilidad y por lo tanto la función de isoecienciaes cuadrática respecto al número de procesadores, esdecir O(m 2 ) como indica el modelo propuesto. Sinembargo, si c 1 ≫ c 2 la inuencia de la comunicaciónes prácticamente despreciable y no tiene apenas in-uencia en la función de isoeciencia. Por ello, el resultadoobtenido es una función de isoeciencia constante,aunque con una pendiente ligeramente mayorque 0 que sería el caso de escalabilidad ideal. Estecomportamiento se debe a que al ser T q ≫ T o elefecto del crecimiento lineal de T o es prácticamentedespreciable respecto a T q y en consecuencia no tieneapenas inuencia en la eciencia, siendo el valor deT q el que domina el comportamiento de la eciencia.Un efecto similar podemos observar en la gura 4(b)para el caso de T q = c m . Cundo c 1 y c 2 tienen valoressimilares, la función de isoeciencia pasa a sercuadrática, como predice el modelo.VI. Conclusiones y Trabajos FuturosEs bien conocido el fuerte impacto que el equilibriode carga tiene en el rendimiento de aplicacionesparalelas. Este artículo demuestra por primera vezque esto también es cierto en relación a la escalabilidad.Efectivamente, la primera y mayor aportaciónque se realiza en este artículo es que si no se tiene encuenta el desequilibrio de carga de trabajo a la horade evaluar la escalabilidad de un sistema paralelolas predicciones pueden ser completamente erróneas.Muchos autores han propuesto modelos de escalabilidad,como ha quedado recogido en la introducción,pero ninguno de ellos contempla esta situación.Este comportamiento hay que incorporarlo a lasherramientas de trabajo. En este artículo se ha propuestouna sencilla modelización matemática del desequilibrioentre los nodos de un sistema paralelo. Elmodelo permite tratar el desequilibrio de carga comouna sobrecarga más del sistema, similar en su concepcióna la sobrecarga de comunicación. De estaforma es muy sencillo incorporar este factor en lafunción de isoeciencia, para predecir la escalabilidadde sistemas paralelos desequilibrados.Con la nueva versión de la función de isoecienciaes posible analizar la inuencia que tiene el desequilibrioen la escalabilidad de sistemas paralelos, yver su relación con la sobrecarga de comunicación.Se han presentado, a modo de ejemplo, una serie deanálisis teóricos de los cuales se obtiene al menosun resultado destacable: en sistemas desequilibradossi la variación del desequilibrio es inversamenteproporcional a la carga de trabajo o al número deprocesadores, la escalabilidad del sistema puede sersub-lineal. Este resultado contradice la cota inferiorpropuesta por Grama et al. [3] que proponen comolímite inferior para la función de isoeciencia Θ(m).JP2011-635

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 201110.8700006000050000Linear growthIsoefficiency O(m^1/2)Efficiency0.6Eficiency = 0.800.4m=2m=4m=80.2m=16m=32m=64m=12800 1000 2000 3000 4000 5000 6000 7000 8000Workload (W)Workload (W)4000030000200001000000 20 40 60 80 100 120 140Number of Processors (m)(a) Evolución de la Eciencia.(b) Función de isoecienciaFig. 3.Función de isoeciencia para el benchmark Inverso_w1.2e+061e+06c1 >> c2c1 ~ c21.2e+061e+06c1 >> c2c1 ~ c2Workload (W)800000600000400000Workload (W)80000060000040000020000020000000 20 40 60 80 100 120 140Number of Processors (m)(a) Desequilibrio constante (T q = c 1 )00 20 40 60 80 100 120 140Number of Processors (m)(b) Desequilibrio inversamente proporcional al número deprocesadores (T q = c 1m)Fig. 4.Isoeciencia: benchmark con sobrecarga de comunicación y desequilibrio de carga de trabajoEl modelo se ha validado experimentalmente medianteuna serie de benchmarks sintéticos. En todoslos experimentos realizados la correlación entrelas predicciones teóricas y los resultados empíricoses excelente. Por lo tanto, se puede armar que elmodelo presentado queda validado y vericado porestos experimentos. Otro aspecto importante que sedesprende de los experimentos es la importancia delvalor relativo de las dos sobrecargas (comunicacióny desequilibrio). Al ser la función de isoeciencia unanálisis de complejidad sólo se queda con la tendenciade la función al aumentar el número de procesadores.Esto es válido si todas las fuentes de sobrecarga sonhomogéneas y presentan constantes similares. Peroen los resultados presentados se ha visto que si unade las sobrecargas tiene un valor mucho mayor quela otra entonces una de ellas puede dominar el comportamientodel sistema en los rangos de número denodos que nos movemos en la actualidad.El trabajo futuro se centra en analizar aplicacionesreales y obtener una metodología de trabajo que permita,la modelización del desequilibrio de carga detrabajo propuesto en este artículo. Asimismo, setratará de extender este resultado a sistemas paralelosheterogéneos donde los problemas de equilibriode carga de trabajo son más frecuentes y complejos.AgradecimientosEste trabajo ha sido parcialmente nanciado porel Ministerio de Educación y Ciencia (proyectosTIN2010-21289, TIN2010-21291-C02-02, ConsoliderCSD2007-00050 y Cajal Blue Brain project) así comopor la Red Europea de Excelencia HiPEAC.Referencias[1] The top500 project, November 2010,http://www.top500.org.[2] Ananth Grama, Anshul Gupta, George Karypis, and VipinKumar., Introduction to Parallel Computing (Second Edition),PEARSON - Addison-Wesley, 2003.[3] Ananth Y. Grama, Anshul Gupta, and Vipin Kumar, Isoeciency:measuring the scalability of parallel algorithmsand architectures, IEEE parallel and distributed technology:systems and applications, vol. 1, no. 3, pp. 1221,Aug. 1993.[4] J. Chen and V. Taylor, Mesh partitioning for distributedsystems, Proceedings of Seventh IEEE Int. Symposiumon High Performance Distributed Computing, July 1998.[5] Luis Pastor and Jose L. Bosque, Eciency and scalabilitymodels for heterogeneous clusters, in Third IEEE Int.Conference on Cluster Computing,, Los Angeles, California,Octubre 2001, pp. 427434.[6] A. Ya. Kalinov, Scalability of heterogeneous parallel systems,Programming and Computer Software, vol. 32, no.1, pp. 17, 2006.[7] Y., X.-H. Sun, and M. Wu, Algorithm-system scalabilityof heterogeneous computing, Journal of Parallel and DistributedComputing, vol. 68, no. 11, pp. 14031412, 2008.JP2011-636

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Mejorando las aplicaciones de red enarquitecturas multinúcleo heterogéneasAndrés Ortíz 1 ; Pablo Cascón 2 ; Julio Ortega 2 ; Antonio F. Díaz 2 ; Alberto Prieto 2Resumen— Los nodos con varios procesadores,posiblemente heterogéneos y/o multinúcleo, suponennuevos desafíos y oportunidades para acelerar lasaplicaciones que requieren comunicaciones connecesidades de anchos de banda elevados. Muchas de lasmejoras posibles para incrementar el ancho de bandaestán relacionadas con la explotación del paralelismodisponible en los nodos, gracias a la presencia de variosnúcleos de procesamiento. Dicho paralelismo no sólopuede aprovecharse para mejorar las prestaciones de laaplicación sino también para reducir la sobrecargaasociada a la interfaz de red. Este trabajo analiza algunasalternativas para distribuir la interfaz de red en losdiferentes núcleos de procesador disponibles en el nodo.Dichas alternativas incluyen el uso de procesadoresmultinúcleo heterogéneos así como el uso deprocesadores de red y la explotación de la afinidad entrela ubicación interfaz de red (proximidad a la memoriadonde se almacenan las diferentes estructuras de datos) ylas características específicas de la arquitectura del nodo.LA interfaz de red distribuida que proponemosproporciona mejoras en el ancho de banda y en lalatencia. Esta propuesta ha sido evaluadaexperimentalmente mediante la implementación de unsistema de prevención contra intrusos (IPS).Palabras clave— Afinidad de interrupción, Sistema deprevención contra intrusos, Interfaz de red, Afinidad deprocesador, Simics.EI. INTRODUCCIÓNN los últimos años, ha sido más difícil reducir eltiempo por ciclo de reloj y a la vez incrementar elnúmero medio de instrucciones por segundo (IPC) que seejecutan en un núcleo de procesamiento, con el fin deaprovechar (de acuerdo con la ley de Moore) el aumento delnúmero de transistores que pueden incluirse dentro de uncircuito integrado. De esta forma, la mejora limitada quepuede obtenerse en el número de instrucciones completadaspor unidad de tiempo y les restricciones de potencia handeterminado una tendencia hacia arquitecturas con múltiplesnúcleos en un chip [1]. Además, teniendo en cuenta la ley deAmdalh, también es interesante el uso de chips multinúcleoheterogéneas que incluyen núcleos con arquitecturasdiferentes para proporcionar la aceleración de partes de laaplicación que presentan diferentes tipos de paralelismo. Almismo tiempo, dichas arquitecturas permiten aprovecharmejor el área disponible en el chip y mejorar la eficienciaenergética [2,3].1 Departamento de Ingeniería de Comunicaciones, Universidad deMálaga, e-mail: aortiz@ic.uma.es.2 Departemanto de Arquitectura y Tecnologia de Computadores,Universidad de Granada, e-mail: julio@atc.ugr.es,afdiaz@atc.ugr.es, aprieto@ugr.es.Precisamente, la interfaz de red (los elementoshardware/software utilizados para conectar el computador ala red) determina las prestaciones de los servidores de red ylas aplicaciones distribuidas que requieren grandes anchos debanda a la vez que bajas latencias. Por ejemplo, paraaprovechar todo su potencial, las técnicas de virtualizaciónrequieren arquitecturas de red virtualizadas eficientes quedescansan sobre interfaces de red de altas prestaciones talescomo las interfaces de red multicola (CDNA) [4], propuestaspara aprovechar los procesadores multinúcleo [5]. Además,la disponibilidad de enlaces de red con gran ancho de banda(multigigabit Ethernet, Infiniband, etc.) [6] han desplazado elcuello de botella en el camino de comunicación de la red alos nodos, debido a la sobrecarga de comunicación porcambios de contexto, procesamiento de la pila de protocolos,múltiples copias de datos, e interrupciones.La presencia de múltiples procesadores (homogéneos oheterogéneos) en los nodos, incluyendo arquitecturasmultinúcleo con diferentes perfiles de cache y buses de E/Smejorados, proporcionan nuevas posibilidades para escalar lainterfaz de red. De hecho, el uso de varios procesares en elcomputador para reducir la sobrecarga de comunicación enlas CPU que ejecutan la aplicación ha sido propuesto ennumerosos trabajo. Así, la externalización de protocolosmediante offloading u onloading [7, 8] son técnicas bienconocidas. Mientras la técnica de offloading utilizaprocesadores incluidos en la tarjeta de red (NIC) para elprocesamiento de los protocolos de red, el onloading utilizaprocesadores de propósito general en un procesadormultinúcleo o en un SMP. Ambas alternativas contribuyen aliberar ciclos en los procesadores que ejecutan la aplicación,dado que desplazan la sobrecarga de comunicación a otroprocesador. Sin embargo, cada alternativa tiene sus pros ysus contras. Por ejemplo, el offloading sólo proporcionamejoras cuando la velocidad del procesador principal essimilar a la del procesador incluido en la NIC (que procesa elprotocolo de red). Por otro lado, la API para comunicar laNIC con la CPU principal puede ser demasiado compleja,especialmente con la pila de protocolos TCP. Además,aunque el onloading explota la tendencia actual a lasarquitecturas multinúcleo o a los nodos multiprocesador, eluso de núcleos más simples y eficientes en cuanto a potenciay área, añadidos a una CPU de propósito general, tambiénpuede acelerar las funciones de red pero con menor coste enárea y una mayor eficiencia en potencia [9]. Este sería elcaso de los procesadores de red, normalmente basados enmicroarquitecturas heterogéneas.De esta forma, hay varias propuestas [10, 11] que intentancombinar los beneficios del offloading y del onloading paraacelerar el procesamiento de la red aprovechando laexistencia de varios procesadores en el nodo (no sólo en laNIC).La paralelización de los protocolos de red y la explotacióndel paralelismo presente en las interfaces de redprogramables también han sido analizadas [12, 13]. Lasdiferentes estrategias que pueden utilizarse para paralelizarprotocolos se han considerado en [12], donde se muestraque, aunque el paralelismo a nivel de paquete que se puedeconseguir en una conexión TCP es limitado, lasJP2011-637

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011oportunidades de paralelizar el procesamiento puedenincrementarse en el caso de múltiples conexiones. En [13],se evalúan las prestaciones obtenidas con elparticionalmiento de tareas estáticas para aprovechar lapresencia de dos procesadores incluidos en una NICespecífica, utilizando la mejora proporcionada por elservidor web httpd con diferentes cargas de trabajo. Otroesquema de particionamiento estático se presenta en [14],donde se describe una versión paralela de protocolo de pasode mensajes (EMP). En [15], se demuestra que una mapeoadecuado de los procesos de una aplicación entre losdiferentes núcleos y la NIC puede corregir el desequilíbriocreado por el procesamiento de los protocolos de red,minimizando los fallos de cache y mejorando lasprestaciones globales. Esta idea de crear afinidad deprocesos y de interrupciones a procesadores específicos se haconsiderado en [16-18]. Los experimentos realizados en[16], relacionados con las ventajas de utilizar arquitecturasque tienen en cuenta la localidad de los datos y la afinidad delos procesadores han puesto de manifiesto que estaspropuestas mejoran las prestaciones proporcionadas por lastécnicas de offloading y onloading. Además, en aplicacionesque utilizan varias hebras [17, 18] pueden obtenerseimportantes mejoras con esquemas de planificación conafinidad. El trabajo [17] muestra mejoras no sólo en elnúmero de conexiones que pueden ser procesadasconcurrentemente sino también en el ancho de banda de lasconexiones individuales. En [18] se presenta un esquema deplanificación de los procesos de red para decidir elprocesador óptimo dependiendo de la carga de losprocesadores, la distribución de cache y los perfiles decomunicación de las aplicaciones. El problema de la latenciade memoria en el contexto de las interfaces de red ha sidotambién considerado en trabajos como [19, 20]. En [19] seconcluye que en la mayoría de los escenarios, incluso parapaquetes pequeños e interfaces que implementan cerocopias,tamaños de cache grandes y niveles de asociatividadmayores pueden mejorar las prestaciones de lascomunicaciones (principalmente en el caso de TCP). En [20]se analizan los mecanismos utilizados por los procesadoresde red para superar los cuellos de botella de memoria y seconcluye que las caches de datos y las estrategias multihebrapueden cooperar para alcanzar grandes anchos de banda entarjetas de red programables.En este trabajo, se evalúan diferentes configuraciones paradistribuir las aplicaciones de red entre los procesadoresdisponibles en el nodo. Dichas configuraciones secorresponden con alternativas para implementar la interfazde red utilizando procesadores multinúcleo, en el nodo o enla NIC, incluyendo microarquitecturas multinúcleoheterogéneas tales como los procesadores de red. Así,después de esta introducción, la Sección 2 describe lasconfiguraciones propuestas para nuestra interfaz distribuiday basada en afinidad. Después, en la Sección 3 se presentanlas principales características de los sistemas de prevencióncontra intrusos (IPS) utilizados para evaluar lasconfiguraciones y la Sección 4 proporciona loscorrespondientes resultados experimentales. Finalmente, laSección 5 muestra las conclusiones y las líneas futuras deinvestigación de este trabajo.II. CONFIGURACIONES DE LAS INTERFACES DE REDEn esta sección, se describen las configuracionespropuestas para distribuir la aplicación y la interfaz de redcon el fin de aprovechar los diferentes procesadorespresentes en el nodo.ApplicationbufferUser MemoryApplicationbufferUser MemorySpace65577NICSystem CPUCPU0sk_buff4DMA areaSystem MemorySpace(a)CPU2sk_buffNICIRQIRQCPU1 3CPU032NICMemoryNICRing BufferNICmemory21NetworkData transferHardware interrupt (IRQ)Software interrupt (SoftIrq)CPU0 controls the transference1Network46 Data transferHardware interrupt (IRQ)DMA areaSoftware interrupt (SoftIrq)CPU1 controls the transferenceSystem MemorySpace(b)Fig. 1. Recepción de paquete por la interfaz de red base (a); y porla interfaz de red distribuida propuesta (b)La Figura 1 muestra los principales pasos para la recepcíónde un paquete en el sistema base tomado como referenciapara determinar las mejoras alcanzadas por las diferentesconfiguraciones que se han analizado. En la Figura 1a,después de que un nuevo paquete llegue a la NIC 1, éstacopia el paquete desde la memoria de la NIC al área deDMA localizada en la memoria principal, 2, donde laCPU0 almacena el paquete en estructuras sk_buff. Latransferencia 2 se realiza una vez que el anillo de DMA dela NIC está lleno. En otras palabras, estamos utilizandocoalescencia de interrupciones [9] en el sistema base parareducir el número de interrupciones. Después de 2, se envíauna interrupción hardware a la CPU principal par informarde que hay disponibles nuevos paquetes para ser procesados3, y el driver copia los datos en estructuras sk_buff 4.Después, el sistema operativo planifica una softirq para elprocesamiento de paquetes TCP 5. El mecanismo softirq,disponible desde el Kernel 2.4 de Linux, permite laejecución de tareas prorrogables hasta el correspondienteevento software [21]. Dado que pueden enviarse diferentessoftirq a los distintos procesadores del nodo, varias hebras deprocesamiento TCP/IP pueden ejecutarse en paralelo envarios procesadores. Cuando la softirq ha procesado elprotocolo, la CPU0 almacena los datos, 7, en los buffers deaplicación localizados en el espacio de memoria de usuario,6.La Figura 1b muestra la forma en que se lleva a cabo larecepción de paquetes en nuestra interfaz de red híbrida (i.e.,implementa elementos de las técnicas de onloading yoffloading). Aquí, el procesador CPU2 está incluido en laNIC y ejecuta los protocolos de red. El procesador CPU1recibe las interrupciones y ejecuta el driver de la mismaforma que lo hace la interfaz de red con onloading. Además,la CPU1 es capaz de ejecutar otras tareas como las llamadasJP2011-638

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011al sistema para copiar los datos desde los sockets TCP a losbuffers de la aplicación. Así, en el modelo híbrido no semolesta a la CPU0 mientras se está recibiendo datos. Portanto, como la CPU0 ejecuta la aplicación (y está únicamentecentrada en ser el consumidor de datos), el ancho de bandaalcanzado podría ser mayor que el ancho de banda alcanzadocon las interfaces de red con offloading u onloading.Así, en la Figura 1b, después de recibir un paquete 1, laNIC lo almacena en su buffer en anillo. Cuando dicho bufferestá lleno o la transferencia del paquete ha finalizado, lospaquetes se copian desde el buffer en anillo a la memoria dela NIC. Entonces, la NIC realiza una transferencia de DMAal área de DMA en la memoria principal, 2, y envía unainterrupción hardware a la CPU1, 3. Esta interrupción causala ejecución de la función do_irq() [21], que llama a lacorrespondiente rutina de interrupción definida en el driverdel dispositivo para copiar los datos en las estructurassk_buff , 4, [21]. Entonces, el driver ejecuta una softirq [21]en la CPU2, 5, para procesar los paquetes de acuerdo conlos parámetros de las estructuras sk_buff.Los parámetros en las estructuras sk_buff corresponden alos protocolos utilizados en las capas altas (en este casoTCP). Una vez que se ha procesado la pila de protocolos, losdatos se copian al Socket TCP. Entonces, la CPU1 copia, 7,los datos desde el Socket TCP a los buffers de la aplicación,a través de la correspondiente llamada al sistema, 6.Una alternativa que ha sido considerada para la CPU2, enla Figura 1b, es una microarquitectura multinúcleo usual enprocesadores de red. Los procesadores de red (NP) soncircuitos programables que proporcionan recursos rápidos yflexibles para las funciones de comunicación a altavelocidad. Dichos procesadores incluyen múltiples núcleoscon características multihebra que hacen posible aprovecharel procesamiento paralelo en las interfaces de red. En estetrabajo, hemos utilizado el procesador de red Intel IXP2855[22, 23] que incluye 16 coprocesadores (llamadosMicroEngines) optimizados para el procesamiento depaquetes, y un núcleo de propósito general (Intel XScale quepresenta una arquitectura RISC compatible con laarquitectura ARM).En una interfaz de red distribuida, es muy importante teneren cuenta el problema del muro de memoria. En las técnicasque asocian la mayoría del trabajo de procesamiento delprotocolo TCP/IP a un núcleo mientras los procesos de laaplicación se ejecutan en otras CPU o núcleos disponibles enel sistema, puede suceder que los datos que tenga queprocesar el la pila de protocolos se encuentren en una cacheL1 o L2 diferente a la que almacena el código del protocolo.Esta situación produce fallos de cache que degradan elrendimiento global del servidor [12]. Para resolver esteproblema, en este trabajo proponemos el uso de diferentesperfiles de cache así como de distribución de procesos einterrupciones de acuerdo con su afinidad.Para ejecutar el driver de la NIC en una CPU específica,hemos forzado la petición de interrupciones a dicha CPU.Esto se ha implementado utilizando la característica deafinidad de interrupciones proporcionada por el kernel 2.6 deLinux mediante smp_affinity [25], que contiene la máscarade interrupciones para la programación del APIC (AdvancedProgrammable Interrupt Controller). Es posible solicitar unaIRQ a un procesador específico, que puede ejecutar el driverde la NIC y la pila de protocolos. Aunque hay otraspropuestas para la distribución dinámica de lasinterrupciones, tales como irqbalance [21], lo que se buscaes que se soliciten las IRQ a la misma CPU donde lacorrespondiente softirq se va a encolar.La Figura 2 muestra los perfiles de procesador y cachepara las diferentes configuraciones de interfaz de redconsideradas. En la Figura 2a, los procesos de aplicación hansido distribuidos para equilibrar la carga entre las diferentesCPU. En esta configuración, llamada hybrid(1), CPU0 yCPU1 comparten la cache L2 mientras que la CPU2 procesala pila de protocolos y tiene su propia memoria cache. Porotro lado, los procesos de aplicación pueden ser ejecutadospor cada una de las CPU presentes en el nodo, y ladistribución de esos procesos la decide el planificador delsistema operativo. Al mismo tiempo, las interrupciones seredirigen a la CPU1, que ejecuta el driver de la NIC. Estapropuesta podría ser potencialmente causa de fallos de cachey, por tanto, de un gran número de ciclos de CPU perdidos alcargar datos desde la memoria principal, especialmentecuando el servidor se encuentre bajo una gran carga detrabajo. De esta forma, hybrid (2) en la Figura 2b, utiliza unperfil de cache diferente para las CPU que procesan elsistema operativo y los procesos de la aplicación delservidor, respectivamente. Además, las interrupciones se hanredirigido a la CPU2 para evitar que la interfaz de redinterrumpa a la CPU que ejecuta los procesos del servidor.Por otro lado, los procesos de red relacionados con lasaplicaciones de usuario se han asignado a la CPU1. Así, estaCPU no se interrumpe, ni por la interfaz de red, ni por otrasfuentes de interrupción.Al mismo tiempo, se ha considerado una cache L2unificada. Esta propuesta resuelve el problema de lalocalidad de cache, dado que la cache utilizada por la CPU2,la cual procesa la pila de protocolos, se comparte con laCPU1, la cual ejecuta los procesos de la aplicación,resultando en una disminución de los fallos de cache. Estadistribución del hardware se podría corresponder con unaNIC integrada en un microprocesador multinúcleo [27].Finalmente, la Figura 2c muestra la configuración npNICque utiliza una NIC basada en un procesador de red. En estecaso, las funciones de red se procesan aprovechando lasventajas de tener múltiples núcleos, optimizados para elprocesamiento de paquetes, que están incluidos en lamicroarquitectura del procesador de red.OS +User processesCPU0 CPU1 CPU2L1OS +User processesCPU0 CPU1 CPU2L1L2User +Networkprocesses +NIC driverL1User +networkprocessesL1L2TCP/IPNICTCP/IP +NIC driverL1NICmem.NICmem.(a)Network(b)NetworkOS +User processes +NIC driverCPU0L1L2TCP/IP +NetworkProcessesNICNICmem.Fig. 2. Configuraciones para las interfaces de red propuestas (a)hybrid(1); (b) hybrid(2); (c) npNICNP(c)NetworkIII. IMPLEMENTACIONES EN EL NODO DE SISTEMAS DEPREVENCIÓN DE INTRUSOSPara comparar las prestaciones de las diferentesconfiguraciones de interfaces de red distribuidas que hemosanalizado, se ha considerado un sistema de prevención deintrusiones (IPS). Un IPS necesita analizar la cabecera y elcontenido del paquete para detectar comportamientos nodeseados. También se requiere que la función implementadapor el sistema de prevención de intrusiones se actualice connuevos procedimientos de detección debido a la evolución delos ataques de red. Dado que esta aplicación requiere altasprestaciones de procesamiento y flexibilidad, un buencandidato para implementar dicho sistema es un procesadorde red. La configuración más común de los sistemas IPSconsiste en monitorizar todo el tráfico entrante a la red deuna organización, mediante un computador que ejecute elJP2011-639

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011software IPS conectado a la conexión principal a Internet dedicha organización. Los paquetes que provienen de Internetson analizados por el sistema IPS, y se procesan antes de quealcancen la red y los sistemas de la organización.Normalmente, los paquetes se reciben mediante una NICestándar, son procesados en la CPU que decide si el paquetedebe continuar hacia la red de la organización o debe serdescartado. Esta implementación tiene la desventaja de quetodos los paquetes deben ser procesados por la CPU. Esteprocesamiento puede llegar a consumir demasiados recursosde la CPU y en el caso de que la tasa de paquetes sea muyalta, el IPS puede verse forzado a descartar paquetes yafectar el rendimiento de la organización. Nuestra propuestaconsiste en mover el IPS, parcial o totalmente, desde elnúcleo dedicado a las aplicaciones, a otro núcleo en un nodomultinúcleo o en la NIC.Así, en el caso de utilizar una interfaz de red distribuida,teniendo en cuenta la Figura 1b, la implementación delsistema IPS funciona como se indica a continuación.Después de recibir un paquete, 1, la NIC lo almacena en unbuffer en anillo. Entonces los paquetes se copian a lamemoria de la NIC, y después, al área de DMA en lamemoria principal, 2. Una vez que el paquete está en el áreade DMA, la NIC envía una interrupción hardware (IRQ) a laCPU1, 3, causando la ejecución de la rutina de atención a lainterrupción (ISR). Dicha rutina copia el paquete recibido auna estructura sk_buff , 4, [26]. Entonces, después deejecutar la función netif_rx(), que encola una softirq, seejecuta el código del IPS en la CPU1. Este código examinano sólo la cabecera del paquete sino también el contenido ydecide si el paquete puede ser aceptado y enviado a las capassuperiores del protocolo, o no. Si el IPS decide dejar que elpaquete siga viajando, se encola una softirq [26] en la CPU2,5, para procesar el paquete de acuerdo con los parámetrosde las estructuras sk_buff, y utilizando las rutinas ip_rcv(), ytcp_rcv() o udp_rcv().Una vez que la pila de protocolos ha sido procesada, losdatos se copian a un Socket INET (dado que hemos trabajadocon TCP/IP) [26] y la CPU1 copia, 7, los datos desde elINET Socket a un Socket BSD donde la aplicación puedeacceder a los datos a través de la correspondiente llamada alsistema, 6. Así, el código del IPS se ejecuta en el espacio dekernel, capturando los paquetes entrantes en una etapa muytemprana del proceso de recepción de paquetes, evitando laejecución de rutinas de más alto nivel para la comprobaciónde las reglas del IPS.Cuando la NIC basada en el procesador de red IXP2855 seutiliza para implementar el IPS (Figura 2c), un MicroEnginese dedica a la recepción de paquetes mientras que otro seencarga de la transmisión (con la ayuda de otros dos), dosMicroEngines gestionan la comunicación con el nodo através del bus PCIe y otro MicroEngine se utiliza para elprocesamiento de los paquetes. Este MicroEngineprecisamente, ejecuta el código del IPS y descarta aquellospaquetes que no cumplan con las reglas establecidas, deforma que no alcancen la CPU principal del nodo. No hay,en este caso, estructuras de datos compartidas, dado que lasreglas del IPS están escritas en el propio código, y no hayuna estructura de memoria compartida por las hebras (8 ennuestro prototipo).operativo, como las aplicaciones comerciales. Para ello, seha simulado una arquitectura [10] que contiene procesadoresde propósito general así como dos niveles de memoria cache.Más específicamente, la cache L1 ha sido dividida en cachede instrucciones y de datos, cada una con 256 líneas de 64bytes, y una política write-through. La cache L2 utiliza 8192líneas de 128 bytes. La asociatividad implementada en lacache L1 de instrucciones, L1 de datos y L2 es de 2, 4 y 8líneas respectivamente. En todos los casos, se utiliza unapolítica LRU de reemplazo y un protocolo de coherencia decache MESI.La implementación del IPS que se ha simulado en Simicsutiliza un kernel 2.6 de Linux [24] y está basada en elmódulo netfilter [25, 26]. Sin embargo, las reglas han sidoescritas en el código y el cambio de las mismas requiere lamodificación del mismo. La implementación se ha realizadoen un módulo para el kernel 2.6 de Linux que puede sercargado y descargado en tiempo de ejecución.Throughput improvement (%)Latency improvement (%)20001800160014001200100080060040020010090807060504030201000IPS on Hybrid (1)IPS on Hybrid (2)IPS on npNIC1 10 100 1000 10000 100000 1+e06Packet size (bytes)(a)1 10 100 1000 10000 100000 1e+06Packet size (bytes)(b)IPS on Hybrid (1)IPS on Hybrid (2)IPS on npNICFigura 3. Comparación de mejoras en ancho de banda (a) y latencia (b)IV. CONFIGURACIÓN EXPERIMENTAL Y RESULTADOSLos resultados experimentales han sido obtenidos mediantesimulación, y mediante la ejecución del código IPS en unsistema que incluye una NIC NFE-i800 basada en elprocesador de red IXP2855. El modelo de simulacióncorrespondiente a la interfaz de red distribuida ha sidoconstruido utilizando el simulador de sistema completoSimics [10], de forma que se simula no sólo el hardware,sino también el software, que comprende tanto el sistemaJP2011-640

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011npNIC-based IPS 1000 MbpsHybrid(1) IPS 1000 MbpsHybrid(2) IPS 1000 MbpsBase IPS 600 MbpsBase IPS 700 MbpsBase IPS 1000 Mbps4 10810 0 10610 102npNIC-based IPS 1000 MbpsHybrid(1) IPS 1000 MbpsHybrid(2) IPS 1000 MbpsBase IPS 600 MbpsBase IPS 700 MbpsBase IPS 1000 MbpsPacket Size(bytes)Packet Size (bytes)0 10 0 10 2 10 4 10 6 10 8Figura 4. Comparación de la latencia para tráfico corrupto (a); ycomparación del ancho de banda para tráfico corrupto (b)Como se muestra en la Figura 3, la implementación delIPS utilizando npNIC proporciona mejores valores de anchode banda y latencia, con respecto al sistema base, parapaquetes de tamaño pequeño. Este comportamiento puedeexplicarse dado que la npNIC permite una interacción másdirecta con la red y puede reaccionar a los paquetes entrantessin la intervención del sistema operativo. De esta forma, laactual implementación de npNIC está recomendada parapaquetes de tamaño pequeño, los cuales suelen ser losresponsables de altas latencias si tiene que viajar por losbuses del sistema hasta llegar a la CPU principal.00Both (Legitime+Corrupt)LegitimeBoth (Legitime+Corrupt)LegitimePacket Size (bytes)0.40.2001.41.210.80.6100080060040020010 0 10 2 10 4 10 6 10 8Packet Size (bytes)0100080060040020010 0 10 2 10 4 10 6 10 8Figura 5. (a) Latencia para tráfico legítimo y corrupto+legítimocon sistema base. (b) Latencia para tráfico legítimo ycorrupto+legítimo con npNIC01000800600400200Latency (s)Throughput (Mbps)Throughput (Mbps)Throughput (Mbps)Cuando el tamaño de los paquetes se incrementa, lasalternativas híbridas proporcionan mejores resultados, dadoque dichas alternativas asignan recursos según el perfil de laaplicación, determinado por la sobrecarga de computación,el tamaño del paquete y la cantidad de tráfico entrantecorrupto. Además, la alternativa hybrid(2), la cual utilizatécnicas basadas en afinidad, proporciona incluso mayorganancia. Por otro lado, para tamaños de paquete muygrandes (>2Mbits), las tres alternativas proporcionanresultados similares aunque la implementación npNIC ofreceresultados ligeramente mejores que las alternativas híbridas.Aunque el IPS se comporta de forma similar en ambos casos,las diferencias entre las prestaciones proporcionadas pornpNIC y las interfaces híbridas pueden explicarse por lascaracterísticas específicas de la npNIC en la ejecución delcorrespondiente código IPS paralelo.La Figura 4 proporciona comparaciones en latencia (Figura4a) y ancho de banda (Figura 4b) cuando se inyecta tráficocorrupto a diferentes tasas. Como puede verse, lasimplementaciones npNIC e híbridas claramente mejoran elsistema base, ofreciendo mejores prestaciones para 1Gpbs detráfico corrupto que el sistema base para 700 Mbps de tráficocorrupto. La Figura 5 compara las latencias obtenidas contráfico corrupto y con tráfico no corrupto en la configuraciónnpNIC. Por otro lado, en la configuración base, cuando haytráfico corrupto y no corrupto, la latencia se degradaseriamente respecto a la latencia que se obtiene cuando sólohay tráfico legítimo (Figura 5b).V. CONCLUSIONES Y TRABAJO FUTUROEn este trabajo se ha utilizado un sistema de prevención deintrusiones para comparar algunas interfaces de reddistribuidas que aprovechan los múltiples procesadoresdisponibles en el nodo, incluyendo un procesador dedicadoen la NIC que puede corresponder con un procesador de red(una arquitectura heterogénea multinúcleo), así como unesquema de afinidad de interrupciones para conseguir unadistribución eficiente de la carga de trabajo.Se han analizado tres configuraciones diferentes,hybrid(1), hybrid(2) y npNIC, que aprovechan el paralelismopresente en el nodo y que tienen en cuenta la localización delos datos de las correspondientes aplicaciones de red. Losresultados proporcionados en la Sección 4 muestran cómo laconfiguración npNIC es más eficiente para paquetespequeños mientras que las interfaces híbridas se comportanmejor con paquetes grandes (>10000 bytes). Además, laconfiguración npNIC proporciona mejores prestaciones bajoaltas cargas de trabajo (i.e.: altas tasas de tráfico corrupto),ya que es posible aprovechar el paralelismo presente en elprocesador de red, evitando que paquetes corruptos de grantamaño viajen a través de los buses del sistema.Hay diferentes situaciones experimentales que podrían seranalizadas para proporcionar una mejor caracterización delcomportamiento, y desarrollar nuevas mejoras para lasalternativas descritas. Por ejemplo, cuando se inyectanpaquetes corruptos a una tasa baja, el procesamiento de losprotocolos de red podría realizarse de forma concurrente conla ejecución del IPS. Además, nuevas mejoras en el núcleode Linux podrían mejorar nuestras interfaces de red híbridas.De esta forma, el planificador podría ser modificado paracontrolar dinámicamente las colas de softirq de acuerdo conla carga de las CPU. Por otro lado, la implementación delIPS podría mejorarse utilizando un sistema de predicción depatrones corruptos o atacantes, lo cual proporcionaría unprocesamiento especulativo de los eventos y, comoconsecuencia, una reacción más rápida del IPS, al aceptar odescartar paquetes, o simplemente para clasificar lospaquetes según una escala de sospecha.JP2011-641

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011AGRADECIMIENTOSEl presente trabajo ha sido financiado mediante elproyecto DSIPA-BIO , SAF2010-20558 (Ministerio deCiencia e Innovación).REFERENCIAS[1] Catanzaro, B.; et al.:”Ubiquitous parallel computing fromBerkeley, Illinois, and Stanford”. IEEE Micro, pp.41-55.March/April, 2010.[2] Kumar, R.; et al.:”Heterogeneous Chip Multiprocessors”. IEEEComputer, vol. 38, pp.32-38. November, 2005[3] Hill, M.; Marty, M.:”Amdahl’s law in the Multicore Era”. IEEEComputer, Vol.41, pp.33-38. July, 2008.[4] Willmann, P.; Shafer, J.; Carr, D.; Menon, A.; Rixner, S.; Cox,A.L.; Zwaenepoel, W.:”Concurrent Direct Network Access forVirtual Machine Monitors”. Proc. Intl. Symposium on High-Performance Computer Architecture, February, 2007.[5] Rixner, S.:”Network virtualization: breaking the performancebarrier”. ACM Queue, pp.36-52. January/February, 2008.[6] Balaji, P.; Feng, W.; Panda, D.K.:”Bridging the Ethernet-Ethernotperformance gap”. IEEE Micro, pp.24-40. May-June, 2006.[7] Shivam, P.: Chase, J.S.:”On the elusive benefits of protocoloffload”. SIGCOMM’03 Workshop on Network-I/O convergence:Experience, Lesons, Implications (NICELI). August, 2003.[8] Regnier, G. et al.:”TCP onloading for data center servers”. IEEEComputer, pp.48-58. November2004.[9] Wun, B.; Crowley, P.:”Network I/O Acceleration inHeterogeneous Multicore Processors”. In Proceedings of the 14thAnnual Symposium on High Performance Interconnects (HotInterconnects). August, 2006.[10] Ortiz, A.; Ortega, J.; Díaz, A. F.; Prieto, A.:”A newoffloaded/onloaded network interface for high performancecommunication”. 17 th Euromicro Intenational Conference onParalell, Distributed and Network-based Processing. PDP 2009,February 2008.[11] Shalev, L.; Marhervaks, V.; Machulsky, Z.; Biran, G.; Satran, J.;Ben-Yehuda, M.; Shimony, I.: “Loosely Coupled TCPAcceleration Architecture”. Proceedings of the 14 th IEEESymposium on High-Performance Interconnects (HOTI). 2006.[12] Nahum, E.M.; Yates, D.J. ; Kurose, J.F.; Towsley,D.:”Performance issues in parallelized network protocols”. Proc.Of the Operating Systems Design and Implementation, pp. 125-137, 1994.[13] Kim, H.; Pai, V.S.; Rixner, S.: ”Exploiting task-level concurrencyin a programmable network interface”. Proc. of the ACMPPoPP’03, 2003.[14] Shivam, P.; Wyckoff, P.; Panda, D.:”Can user-level protocols takeadvantage of Multi-CPU NICs?”. Proc. Intl. Parallel andDistributed Processing Symp. (IPDPS’02), pp.64-69. April, 2002.[15] Narayanaswamy, G.; Balaji, P.; Feng, W.:”An Analysis of 10-Gigabit Ethernet Protocol Staks in Multicore Environments”. 15 thIEEE Symp. On High-Performance Interconects (HOTI’07),pp.109-116, 2007.[16] Foong, A.; Fung, J.; Newell, D.: “An in-depth analysis of theimpact of processor affinity on network performance”.Proceedings of the 12 th IEEE International Conference onNetworks. 2004.[17] Salehi, J.; Kurose, J.; Towsley, D.: “The efectiveness of Affinitybasedscheduling in multiprocessor network protocol processing”.IEEE/ACM transactions on networking. Vol 4, nº4. pp. 516-530.1996.[18] Jan, H.; Jin, H.-W.: “MiAMI: Multi-Core Aware ProcessorAffinity for TCP/IP over Multiple Network Interfaces”. 17 th IEEESymposium on High Performance Interconnects. HOTI 2009.[19] Bruijn, W. de; Bos, H.:”Model-T: “Rethinking the OS for terabitsspeeds”. Workshop on High-Speed Networks (HSN2008),INFOCOM’2008, 2008.[20] Mudigonda, J.; Vin, H.M.; Yavatkar, R.:”Overcoming thememory wall in packet processing: hammers or ladders?”. Proc. ofthe ACM ANCS’05, 2005[21] Irqbalance daemon. GNU General Public License (GPL) version2. http://irqbalance.org/[22] Johnson, E.J.; Kunze, A.R.: ”IXP2400/2800 Programming. TheComplete Microengine Coding Guide”. Intel Press, 2003.[23] Netronome: “NFE-i800 Network Acceleration Card”, 2006.www.netronome.com/pages/acceleration-cards[24] Love, R.: “Linux kernel development”. Novell Press. Secondedition. 2005.[25] Netfilter framework. www.netfilter.org[26] Benvenuti, C.: “Understanding linux network internals”. O’Reillymedia. First edition. 2006.[27] Binkert, N.; et al.:”Integrated network interfaces for highbandwidthTCP/IP”. Proc. Of the 2006 ASPLOS Conference.December, 2006.JP2011-642

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Estimación del efecto de los fallos cache en elrendimiento de aplicaciones paralelasD. R. Martínez 1 , V. Blanco 2 , J. C. Cabaleiro 1 , T. F. Pena 1 y F. F. Rivera 1Resumen— Este artículo presenta una metodologíapara caracterizar la influencia de los fallos cache enel rendimiento de aplicaciones paralelas, que está basadaen los modelos analíticos proporcionados por elentono TIA, obtenidos mediante técnicas de selecciónde modelos. En particular, esta metodología proporcionauna estimación de la influencia de los fallos cacheen el rendimiento de una aplicación, a partir de modelosanalíticos del tiempo de ejecución y del númerode fallos cache. Como caso de estudio, esta metodologíaha sido aplicada en dos versiones del productoparalelo de matrices.Palabras clave— Rendimiento, selección de modelos,fallos cache, aplicaciones paralelas.LOS fallos cache tienen una influencia significativaen el rendimiento de las aplicaciones. Sinembargo, es difícil determinar su influencia real enel rendimiento de una aplicación concreta, porquesu efecto se solapa con otros elementos. El objetivode este trabajo es la presentación de una metodologíaautomática para caracterizar, utilizando mecanismosde selección de modelos, la influencia de losfallos cache en el rendimiento de aplicaciones paralelas.Las diferentes aproximaciones existentes paramodelar los fallos cache se basan en modelos analíticos[1] o en simulaciones [2]. Sin embargo, estas aproximacionesmodelan el número de fallos cache desdeun punto de vista cuantitativo, pero no proporcionaninformación de la influencia real de los fallos cacheen el rendimiento de las aplicaciones.La estructura de este artículo se describe a continuación.En la sección I se presentan las bases teóricasen las que se fundamenta el mecanismo de selecciónde modelos utilizado. El entorno de análisis TIAy el mecanismo de selección de modelos, basado enel criterio de información de Akaike, se describen enla sección II. La metodología para la caracterizaciónde la influencia de los fallos cache en el rendimientode una aplicación se describe en la sección III.En la sección IV se muestra un caso de estudio y seanalizan los resultados. Finalmente, se presentan lasprincipales conclusiones de este trabajo.I. Selección de modelos con AICEl criterio de información de Akaike (An InformationCriterion, AIC) [3] proporciona un método simpley objetivo para determinar el modelo que mejorcaracteriza los datos experimentales. Este criterio sedefine como:AIC = −2 log(L(̂θ)) + 2K (1)1 Dpto. de Electrónica y Computación, Univ. Santiagode Compostela, e-mail: {diego.rodriguez, jc.cabaleiro,tf.pena, ff.rivera}@usc.es2 Dpto. de Estadística e Investigación Operativa, Univ. LaLaguna, e-mail: Vicente.Blanco@ull.esdonde log(L(̂θ)) es el logaritmo de la máxima verosimilitud,que permite determinar los valores de losparámetros libres de un modelo estadístico, y K es elnúmero de parámetros libres del modelo. Aunque nojustifica las bases teóricas en las que se fundamenta,es posible hacer una interpretación heurística de (1).Esta interpretación considera el primer término deesta ecuación como una medida de la calidad con laque el modelo se ajusta a los datos experimentales,mientras que el segundo sería una penalización quese incrementa con la complejidad del modelo. Por lotanto, este criterio ofrece un valor objetivo que, demanera relativa, cuantifica simultáneamente la precisióny sencillez del modelo.El criterio de información de Akaike formula elproblema de selección de modelos como una búsquedadel modelo que presente un menor valor AIC, entreun conjunto de modelos candidatos. Los pesosde Akaike (ω AIC ) proporcionan un mecanismo paracuantificar la calidad de la selección de modelos medianteAIC. Estos pesos se basan en las diferenciasAIC (∆ AIC ), que permiten ordenar los modelos segúnsu calidad. La diferencia AIC de un modelo i se definecomo:∆ AICi = AIC i − AIC min (2)donde AIC min es el menor valor AIC dentro del conjuntode modelos candidatos. Las diferencias ordenanlos modelos según su distancia con el mejor modelo,pero no aportan información acerca de la calidaddel mejor modelo. Los pesos de Akaike proporcionanuna estimación de la calidad de un modelo. En particular,dado un conjunto de modelos candidatos detamaño R, el peso de Akaike del modelo i es:ω AICi )i = exp (− 1 2 ∆AICR∑exp (− 1 2 ∆AIC r )r=1(3)Este valor puede ser interpretado como la probabilidadde que el modelo i sea realmente el mejor modeloen el conjunto escogido, suponiendo que uno de losmodelos considerados es el mejor modelo.II. Entorno de AnálisisEl entorno de análisis TIA (Tools for Instrumentacionand Analysis) [4] consta de dos fases. En laprimera fase, denominada fase de instrumentación,el usuario instrumenta el código fuente de una aplicacióny la información acerca del rendimiento, obtenidadurante la ejecución de la aplicación, es almacenadaen ficheros XML. La segunda fase, denominadafase de análisis, utiliza la información procedentede múltiples ejecuciones instrumentadas paraJP2011-643

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011generar un modelo analítico del rendimiento de laaplicación bajo estudio mediante análisis estadísticosexhaustivos [5].El proceso de obtención de modelos estadísticosde aplicaciones paralelas implementado en la fase deanálisis del entorno TIA está basado en la selecciónde modelos mediante AIC [6]. Este proceso realiza unanálisis AIC sobre un conjunto finito de modelos candidatos,generados a partir de información suministradapor el usuario. El resultado final es el modeloque presente el AIC más bajo, así como informaciónacerca del análisis que permita al usuario hacer unavaloración del resultado obtenido.El conjunto de modelos candidatos (MC) es el elementofundamental para garantizar la calidad delproceso de selección AIC. La responsabilidad de estatarea recae inicialmente sobre el usuario, que debeproporcionar un conjunto de modelos adecuado.En particular, se ha diseñado un mecanismo de descripciónpara representar un conjunto de modelosmediante una estructura de dos niveles. Esta descripcióndefine un modelo global y considera comoelementos del conjunto de modelos todos los posiblesmodelos anidados derivados del modelo global.Los elementos constitutivos del nivel más interno delanidamiento son las diferentes variables (métricas oparámetros) que a priori tienen influencia en el comportamientodel experimento. El nivel más externodel anidamiento está formado por conjuntos disjuntosde estas variables.Este agrupamiento de las variables permite definir,de manera implícita, una nueva lista de variablesderivadas formada por todos los posibles productos(denominados términos) de variables pertenecientesa diferentes conjuntos. En esta lista también se consideraque cada grupo contiene implícitamente el elementoidentidad. El modelo global que define el conjuntode modelos está formado por la suma de todoslos términos, con sus correspondientes coeficientes.Para una descripción que genere N términos, el modeloglobal tendrá la siguiente estructura, que no representamás que la combinación lineal de todos lostérminos considerados:M global = ∑ iC i T i ,i = 1, 2, . . . , Ndonde T i representa el término i-ésimo y C i su correspondientecoeficiente de ponderación. En cualquiercaso, una vez definidos los diferentes conjuntosde variables primarias, la construcción del modeloglobal, incluyendo la generación de términos, esautomática. En este proceso, el usuario únicamentenecesita determinar los conjuntos de variables primarias.En un entorno R, esta estructura de conjuntosse puede implementar mediante una lista de listas,que denominamos Lista Inicial (LI), en la que cadalista interior contiene las variables asociadas a cadaconjunto. Para complementar este mecanismo, seha considerado una extensión que permite al usuariocontemplar otros términos aparte de los generadosautomáticamente a través de los grupos de variablesprimarias.Una vez determinado el conjunto de modelos candidatos,se realiza la selección de modelos con AIC.En primer lugar, se ajustan todos los modelos a losdatos experimentales y se obtiene, para cada modelo,una aproximación de segundo orden de AIC [7]. Elmodelo que presente un menor valor de AIC se propondrácomo mejor modelo. A partir de los valoresAIC de todos los modelos candidato, se calculan lospesos de Akaike (ω AIC ), pero también se proporcionala importancia relativa de cada uno de los términosconsiderados (ω+ AIC ). La importancia relativa de unavariable predictora j será la suma de los pesos deAkaike de todos los modelos que contengan j comovariable predictora. Con esta información, el usuariotendrá la capacidad de valorar si el modelo propuestoes adecuado para caracterizar el comportamientode la aplicación bajo estudio.III. Estimación de la influencia de losfallos cacheAunque la métrica más habitual, en términos deanálisis del rendimiento, es el tiempo de ejecución,el entorno TIA proporciona al usuario la capacidadde obtener modelos estadísticos de rendimiento decualquier métrica disponible a través de los driversde TIA. En concreto, el driver PAPI proporciona elmecanismo apropiado para medir diferentes aspectosdel rendimiento de la memoria cache en los microprocesadoresactuales como, por ejemplo, el númerode fallos cache de lectura/escritura en los diferentesniveles [8].Los fallos cache no se pueden utilizar para predecirel tiempo de ejecución, ya que esta métrica esdesconocida antes de ejecutar la aplicación. Sin embargo,utilizando el entorno TIA, es posible obtenerun modelo de los fallos cache que pueda utilizarse entareas de predicción. Por otro lado, si se identifica lacontribución de los fallos cache al modelo del tiempode ejecución, se puede determinar la influenciade estos en el rendimiento de la aplicación. Utilizandoel entorno TIA, se ha diseñado una metodologíapara modelar la influencia de los fallos cache en eltiempo de ejecución de una aplicación paralela. Encualquier caso, esta metodología no está restringidaúnicamente a la caracterización de los fallos cache,sino que podría aplicarse a cualquier otro parámetroarquitectural cuyo valor no se conozca antes de laejecución de una aplicación.En primer lugar, el tiempo de ejecución y el númerode fallos cache son medidos a través de los driversde TIA, así como otros parámetros de ejecución de laaplicación paralela como, por ejemplo, el número deprocesos o el tamaño de problema. Una vez conocidoslos valores experimentales de las diferentes métricasy parámetros de rendimiento, se obtienen los modelosestadísticos del tiempo de ejecución y de losfallos cache mediante el método de selección de modelosimplementado en la fase de análisis del entornoTIA. Por un lado, el modelo de los fallos cache se obtienecomo una función de los diferentes parámetrosde ejecución medidos. Por otro lado, se construye elJP2011-644

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011modelo del tiempo de ejecución como una función delos parámetros de ejecución y de los fallos cache. Esdecir, los fallos cache se consideran como un nuevoparámetro de ejecución independiente. La variableque caracteriza los fallos cache en la expresión delmodelo del tiempo de ejecución podrá ser sustituidapor el correspondiente modelo. Por lo tanto, la expresiónfinal del tiempo de ejecución de la aplicaciónsólo dependerá de los parámetros de ejecución. Porlo tanto, estas expresiones pueden evaluarse antes deejecutar la aplicación, proporcionando un mecanismoadecuado para la predicción del rendimiento dela aplicación.IV. Caso de estudioLa estimación de la influencia de los fallos cache enla ejecución de aplicaciones paralelas ha sido evaluadaen dos versiones diferentes del producto paralelode matrices. En particular, estas dos versiones utilizannúmeros en punto flotante de simple precisióny las comunicaciones entre los diferentes procesos serealiza a través de funciones MPI. La figura 1 muestrael pseudo-código de estas dos versiones, donde eltamaño de las matrices es N × N, siendo P el númerode procesos. En ambos casos, se ha supuesto quela distribución de las matrices X e Y se ha realizadoen un paso previo y que el reparto de la matriz X hasido realizado por bloques, de forma equitativa, entrelos diferentes procesos implicados. Por un lado, elcaso A, representado en la figura 1(a), muestra unasituación en la que todo el trabajo computacional serealiza intensivamente antes de iniciar el envío de losresultados parciales, mediante una única comunicacióncolectiva. Por otro lado, el caso B, representadoen la figura 1(b), muestra una situación en la que elnúmero de comunicaciones es muy elevado, ya quecada fila de la matriz Z es enviada al proceso raízinmediatamente después de calcularse en el procesocorrespondiente. Por lo tanto, las diferencias entre losdos casos están en el número y tamaño de las funcionesglobales de comunicación (MPI_Gather), queenvían los resultados parciales de la matriz resultadoal proceso raíz. El caso A realiza una única comunicaciónglobal en la que envía la matriz completa,mientras que en el caso B, se realizan N/P comunicacionesglobales y en cada una de ellas se envían P filasde la matriz resultado. Se han incluido las funcionesMPI_Barrier, antes y después de cada función de comunicación,para reducir los posibles solapamientosentre la comunicación y la computación.Ambos códigos han sido instrumentados utilizandolos drivers PAPI, MPI y NWS del entorno TIA.El driver PAPI ha sido utilizado para obtener losfallos cache registrados durante las distintas ejecuciones.Asimismo, para obtener una mayor precisión,el tiempo de ejecución ha sido medido utilizando elobservable PAPI_REAL_USEC del driver PAPI. El driverMPI es necesario para la correcta gestión de losobservables obtenidos con PAPI. El driver NWS seha utilizado para obtener el estado de la red de comunicación,proporcionando el ancho de banda y laFOR i in 1:(N/P) /* Parallel loop */FOR j in 1:NZ i,j =0FOR k in 1:NZ i,j +=X i,k *Y k,jEND FOREND FOREND FORMPI BarrierMPI Gather(Z)MPI Barriera) Caso A, cómputo intensivoFOR i in 1:(N/P) /* Parallel loop */FOR j in 1:NZ i,j =0FOR k in 1:NZ i,j +=X i,k *Y k,jEND FOREND FORMPI BarrierMPI Gather(Z i,∗ )MPI BarrierEND FORb) Caso B, comunicación intensivaFig. 1. Pseudo-códigos del producto paralelo de matricesTABLA IValores numéricos de los parámetros experimentalesParámetroValoresNúmero de procesadores 2, 3, 4, 5, y 6Dimensión de la matrices 300, 400 y 500Velocidad de la red 10, 100 y 1000 Mbpslatencia efectiva de la red justo antes de la ejecuciónde los códigos.Los códigos instrumentados han sido ejecutados enun cluster de seis nodos conectados a través de unared Gigabit Ethernet. El controlador de la interfazde red de los nodos permite al usuario modificar lavelocidad de la red, por lo que se han consideradotres situaciones de red diferentes, utilizando diferentesparámetros en la configuración de este controlador.Los nodos del cluster están equipados con procesadoresIntel R○ Pentium R○ 4. Este procesador disponede 2 niveles de cache: L1 de 32 KB (16 KB dedatos) y L2 de 1 MB. La latencia asociada a un falloen el nivel L2 es, aproximadamente, un orden demagnitud mayor que la latencia del nivel L1 [9], porlo que sólo consideraremos los fallos de nivel L2 eneste estudio. Cada aplicación ha sido ejecutada contres tamaños de matriz diferentes para cada configuraciónde velocidad de la red de interconexión ynúmero de procesos. La tabla I muestra, para cadaparámetro experimental, los valores utilizados en esteestudio. Para cada configuración experimental sehan realizado cuatro ejecuciones independientes dela aplicación instrumentada.A. Modelo del número de fallos cache L2Teniendo en cuenta que la principal causa de falloscache L2 es el volumen de operaciones MAC (multiplicary acumular), los límites de los diferentes lazosdeberían ser los factores fundamentales a tener enJP2011-645

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011cuenta para la construcción de la lista inicial (LI) delmétodo de selección de modelos del entorno TIA. Comola estructura de lazos es similar en los dos casos,la lista inicial propuesta para ambos casos es:{ } N {N 2 , N }PEl primer elemento de la lista, { N P}, se correspondecon el tamaño de lazo más externo. El segundoelemento, {N 2 , N}, representa el número de instruccionesMAC que se ejecutan en cada instancia de losdos lazos internos. El modelo del número de falloscache de nivel L2, que denominamos Φ, obtenido automáticamentemediante la selección de modelos implementadaen TIA, se muestra en la tabla II paralos dos casos considerados.Los elevados pesos de Akaike indican que, dentrodel conjunto de modelos candidatos seleccionado, estosmodelos son una buena aproximación del comportamientoreal de los fallos cache de nivel L2. Encualquier caso, existe una notable similitud entre lasexpresiones de los dos modelos ya que los coeficientesde los términos dominantes en las expresiones ( N 3N 2Py N PP ,) son similares. Este hecho indica de que lasuposición inicial, al respecto de que el número defallos cache de nivel L2 es independiente de las comunicaciones,es correcta.B. Modelo del tiempo de ejecuciónPara construir la lista inicial (LI) del proceso de selección,en ambos casos, se han analizado de maneraindependiente las secciones de cómputo y comunicación,porque el solape entre ambas es prácticamentenulo por el uso de las funciones MPI_Barrier.Por un lado, al análisis de los factores de cómputoen ambos casos es similar, ya que ambas aplicacionesejecutan el mismo número ( N 3P) de operacionesMAC. Además, podemos considerar que el coste dela gestión de los lazos es despreciable. La influenciade los fallos cache también deber ser tenida en cuentaen el tiempo de ejecución en esta sección de cómputo,ya que, de acuerdo con la suposición consideradaen la obtención de los modelos Φ, los fallos cacheestán correlacionados con la ejecución de las instruccionesMAC. Se supondrá que la influencia de losfallos cache de nivel L2 es directamente proporcionalal número total de fallos cache, que es un dato experimentalproporcionado por el driver PAPI (variablePAPI_L2_TCM). En este análisis se utilizará el símboloφ para referirse al número total de fallos cache denivel L2 medidos a través de este driver.Por otro lado, la contribución de las comunicacionesal rendimiento de los distintos códigos merece unanálisis detallado, porque las principales diferenciasentre ambos códigos reside precisamente en el númeroy tamaño de las comunicaciones. En concreto, losparámetros relacionados con el número de llamadas alas funciones de comunicación y los parámetros relacionadoscon el coste de cada comunicación han sidoconsiderados de manera independiente. El númerototal de comunicaciones colectivas (MPI_Gather) esigual al producto de los límites de los lazos externosa la propia función. En el caso A no hay ningúnlazo exterior, mientras que en el caso B la funcióncolectiva está dentro de un lazo cuyo límite es N P .El análisis del coste asociado a cada funciónMPI_Gather no es inmediato, ya que el rendimientoreal depende de las características de la red de interconexióny del algoritmo de comunicación, es decir,de la topología de las comunicaciones punto a puntoimplementadas internamente en la función colectiva.El rendimiento de las comunicaciones punto a puntopuede modelarse mediante los parámetros de latencia(α) y ancho de banda (1/β), de acuerdo con elmodelo de Hockney [10]. Sin embargo, el algoritmode comunicación colectiva es, a priori, desconocido eincluso podría cambiar dinámicamente según el tamañode mensaje. En este caso, para cubrir varias posibilidades,se consideran los caminos críticos de losalgoritmos lineal y binomial (⌈log 2 P ⌉ y P , respectivamente),que determinan el tiempo teórico máximode la función de comunicación. La conexión entre elmodelo de Hockney y los distintos algoritmos se realizasiguiendo la misma aproximación que Pjěsivac-Grbovíc et ál. [11]: la latencia multiplica el caminocrítico del algoritmo y el ancho de banda divide eltamaño de mensaje global de la función colectiva,esto es, el tamaño de la matriz Z. El tamaño globalde cada comunicación colectiva es N 2 en el caso A yN en el caso B. Además, tanto los caminos críticosde los dos algoritmos considerados como el tamañoglobal de la función colectiva han sido consideradoscomo variables individuales y, de este modo, se tieneen cuenta la posibilidad de que los parámetros delmodelo de Hockney no influyan significativamente enel rendimiento de los códigos.Teniendo en cuenta las consideraciones previas, lalista inicial utilizada en el caso A es:{N 2 , N 2} { } N3 ∗β , ⌈log 2 P ⌉, α⌈log 2 P ⌉, P, αPP , φmientras que para el caso B sería:{ } { NN, N } { } N3 ∗P β , ⌈log 2 P ⌉, α⌈log 2 P ⌉, P, αPP , φEl asterisco{que aparece } en el último elemento deNestas listas,3P , φ en ambos casos, indica que estasvariables deben ser considereadas directamente comotérminos en el proceso de selección de modelos.La tabla III muestra los modelos seleccionados entreel conjunto de modelos candidatos correspondiente,obtenidos automáticamente mediante el métodode selección de modelos de TIA.Los términos asociados al número de operacionesMAC y al número de fallos cache son muy similaresen ambos casos, aunque ligeramente menores enT B respecto de T A . Esta pequeña diferencia es consecuenciadirecta de la menor influencia de estos factoresen el tiempo de ejecución del caso B. El coste delas comunicaciones colectivas es mayor que el costeasociado al cálculo de una fila de la matriz resulta-JP2011-646

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLA IIModelo del número de fallos cache de nivel L2, obtenido automáticamente con el entorno TIACaso Modelo Error ω CMA Φ A = 0,144 N 3B Φ B = 0,154 N 3P −98 N 2P −0,39N 2 +16400 N P +130N 37.4 0.999P −102 N 2P +0,9N 2 +17000 N P −230N 26.7 0.981TABLA IIIModelos del tiempo de ejecución, obtenidos automáticamente mediante con el entorno TIACaso Modelo Error ω CMA T A (µs) = 18,7 N 2β + 0,18N 2 − 4000⌈log 2 P ⌉ + 40000α⌈log 2 P ⌉ − 27000αP + 0,0154 N 3P + 0,19φ 4.4 % 0.418BT B (µs) = 21 N 2P β + 970 N β + 14000⌈log 2 P ⌉ − 130000α⌈log 2 P ⌉ + 100 N P ⌈log 2 P ⌉++ 800 N P α⌈log 2 P ⌉ + 0,0142 N 33.5 % 0.0246P + 0,13φdo y, por lo tanto, la función colectiva es el factordominante en cada iteración del lazo más externo.A diferencia de los modelos Φ A y Φ B , estos modelospresentan unos pesos de Akaike relativamentebajos que indican, a priori, una calidad pobre de losresultados. En cualquier caso, la importancia relativade los diferentes términos considerados, proporcionadapor el entorno TIA, permite que el usuario analicela calidad de estas expresiones y las modifique consecuentemente.La tabla IV muestra la importanciarelativa de los diferentes términos considerados en laobtención de los modelos del tiempo de ejecución enlos casos A y B. Únicamente se muestran los términoscon una importancia relativa mayor que 0,5. Enel caso A, seis de los siete términos que aparecen enel modelo comparten el valor máximo de importanciarelativa, lo que evidencia que el modelo T A esrealmente una aproximación adecuada del comportamientoreal de la aplicación. En el caso B, aunqueel modelo es muy preciso para caracterizar los datosexperimentales, el peso de Akaike es muy pequeño eneste caso. Es posible que, en este caso, los modelosconsiderados en el conjunto de candidatos no reflejenadecuadamente el comportamiento del caso B,aunque la mejor aproximación sea el modelo T B .C. Influencia de los fallos cache en el tiempo de ejecuciónEn los casos considerados, la influencia de los falloscache L2 en el tiempo de ejecución se puede estimarcombinando los modelos obtenidos para los fallos cache(tabla II) y los modelos del tiempo de ejecución(tabla III). Tanto en el caso A como en el caso B,la contribución de los fallos cache L2 en el tiempode ejecución total de la aplicación se identifica en elsumando correspondiente al término φ. Por lo tanto,el coeficiente de estos términos proporciona el costeTABLA IVImportancia relativa de los modelos T A y T BCaso ACaso Bω+ M término ω+ M términoN0.91872N0.9003β βN0.91873N0.90032P P β0.9187 φ 0.8800 φ0.9187 N 2 N0.87763P0.9187 α⌈log 2 P ⌉ 0.8667 α⌈log 2 P ⌉N0.9187 αP 0.8246 P α⌈log 2 P ⌉0.5615 ⌈log 2 P ⌉ 0.7728 ⌈log 2 P ⌉N0.5003 P 0.5424 P ⌈log 2 P ⌉efectivo por cada fallo en la cache de nivel L2: 0,19µs/fallo y 0,13 µs/fallo en los casos A y B, respectivamente.La figura 3 muestra la estimación del porcentajede tiempo de ejecución asociado a los falloscache L2, en ambos casos. Estos datos han sido obtenidosutilizando los modelos T y Φ para caracterizar,respectivamente, el tiempo de ejecución y los falloscache L2. Por lo tanto, estas estimaciones han sidocalculadas a partir de los parámetros de ejecución N,P , α y β.En el caso A, la influencia de los fallos cache L2es prácticamente insignificante cuando la dimensiónde la matriz es 300 o 400, pero alcanza un 10 % deltiempo de ejecución cuando la dimensión de la matrizes 500. En el caso B se puede observar un comportamientosimilar, aunque la contribución es mayorcuando la dimensión de la matriz es 400. Aunque lainfluencia de los fallos cache disminuye con el númerode procesos, el ritmo de decrecimiento es menoral aumentar el ancho de banda de la red. Además,en ambos casos, la importancia de los fallos cachees prácticamente constante cuando la velocidad dela red es 1000 Mbps. Ambos efectos están asociadosJP2011-647

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20112 3 4 5 610 Mbps100 Mbps1000 Mbps% of execution time105matrix size30040050002 3 4 5 6Number of processors2 3 4 5 6Fig. 2. Estimación del porcentaje de tiempo de ejecución asociado a los fallos cache L2 en el caso A2 3 4 5 610 Mbps100 Mbps1000 Mbps% of execution time105matrix size30040050002 3 4 5 6Number of processors2 3 4 5 6Fig. 3. Estimación del porcentaje de tiempo de ejecución asociado a los fallos cache L2 en el caso Bal hecho de que el coste individual de cada comunicacióndisminuye al aumentar el ancho de banda dela red y, por lo tanto, la importancia de las comunicacionesen el coste total de la aplicación se reduceconsecuentemente.V. ConclusionesEn este artículo se propone una nueva metodologíapara obtener una estimación de la influencia de losfallos cache en el rendimiento de una aplicación. Estametodología está basada en los modelos analíticosproporcionados por mecanismo de selección de modelos,basado en el criterio de información de Akaike,que ha sido implementado en el entorno TIA. Comocaso de estudio, en este artículo se presentan losresultados obtenidos con esta metodología para diferentesversiones del producto paralelo de matrices.AgradecimientosEste trabajo ha sido financiado por fondos FEDERy por el Ministerio de Educación y Ciencia (proyectosTIN2008-06570-C04-03 y TIN2010-17541), por laXunta de Galicia (proyecto 2010/28) y por las redesHiPEAC, CAPAP-H y GHPC.Referencias[1] D. Andrade, M. Arenaz, B.B. Fraguela, J. Touriño, andR. Doallo, “Automated and accurate cache behavioranalysis for codes with irregular access patterns,” Concurrencyand Computation: Practice and Experience, vol.19, no. 18, pp. 2407–2423, 2007.[2] R. A. Uhlig and T. N. Mudge, “Trace-driven memorysimulation: A survey,” ACM Computing Surveys, vol.29, no. 2, pp. 128–170, 1997.[3] H. Akaike, “A new look at the statistical model identification,”IEEE Transactions on Automatic Control, vol.19, pp. 716–723, 1974.[4] Diego R. Martínez, Vicente Blanco, Marcos Boullón,José Carlos Cabaleiro, Casiano Rodríguez, and FranciscoF. Rivera, “Software tools for performance modeling ofparallel programs,” in IEEE International Parallel andDistributed Processing Symposium, 2007, IPDPS.[5] Diego R. Martínez, Vicente Blanco, Marcos Boullón,José Carlos Cabaleiro, and Tomás F. Pena, “Analyticalperformance models of parallel programs in clusters,” inParallel Computing: Architectures, Algorithms and Applications,2007, ParCo.[6] Diego R. Martínez, Julio L. Albín, José Carlos Cabaleiro,Tomás F. Pena, Francisco F. Rivera, and Vicente Blanco,“El criterio de información de Akaike en la obtención demodelos estadísticos de rendimiento,” in XX Jornadasde Paralelismo, 2009.[7] Kenneth P. Burnham and David R. Anderson, ModelSelection and Multimodel Inference. A PracticalInformation-Theoretic Approach, Spring Science + BussinessMedia, LLC, 2002.[8] S. Browne, J. Dongarra, N. Garner, G. Ho, and P. Mucci,“A portable programming interface for performance evaluationon modern processors,” International Journal ofHigh-Performance Computing Applications, vol. 14, no.3, pp. 189–204, 2000.[9] J. C. Pichel, D. B. Heras, J. C. Cabaleiro, and F. F.Rivera, “Increasing data reuse of sparse algebra codeson simultaneous multithreading architectures,” Concurrencyand Computation: Practice and Experience, vol.21, no. 15, pp. 1838–1856, 2009.[10] R. Hockney, “The communication challenge for MPP:Intel Paragon and Meiko CS-2,” Parallel Computing,vol. 20, pp. 389–398, 1994.[11] J. Pjěsivac-Grbovíc, Towards Automatic and AdaptiveOptimizations of MPI Collective Operations, Ph.D. thesis,University of Tennessee, 2007.JP2011-648

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Metodología para la sintonización deaplicaciones OpenMP en sistemas multicoreCésar Allande 1 , Josep Jorba 2 , Eduardo César 1 y Anna Morajko 1Resumen—Las aplicaciones científicas en entornos HPC hande ser capaces de utilizar los procesadores multicorede forma eficiente. Surge la duda de cómo explotarlos recursos evitando ineficiencias debidas principalmentea la compartición de recursos por parte delprocesador. Es necesario proporcionar herramientascapaces de minimizar los problemas de rendimiento,mediante la detección, medición y predicción defactores de rendimiento. Usando técnicas de sintonizacióndinámica se puede proporcionar transparenciay además obtener mejoras de rendimientogeneral de la aplicación.En este trabajo se propone una metodología parael análisis y sintonización de aplicaciones OpenMP enentornos multicore. La sintonización dinámica se produceen base a la predicción de comportamiento proporcionadapor modelos de rendimiento, provistos deinformación obtenida en la caracterización del sistemay durante la monitorización de factores dinámicos derendimiento.Palabras clave— OpenMP, análisis de rendimiento,modelo de rendimiento, multicore, paralelismo dedatos, paralelismo de tareasI. IntroducciónLa limitación en la capacidad de integración detransistores ha generado la necesidad de aumentarlas prestaciones mediante la agregación de másunidades de proceso, desembocando en la era multicore.La tendencia parece indicar que la evoluciónde las nuevas generaciones de procesadores pasará,en gran medida, por un aumento ingente de núcleosen el chip. Los fabricantes estudian la viabilidad dediseños de 48 [1], o hasta 100 cores[2]. Por no mencionarlos sistemas GPU [3] o APU [4], con cifrasdel orden de cientos de núcleos por procesador. Laaparición de estos procesadores genera cierta controversiarespecto a si ¿será posible utilizar de formaeficiente estos recursos?. Es cierto que existen importantesproblemas a resolver en el diseño de estosprocesadores, como el cuello de botella que representala memoria. Una barrera que hasta el momentose ha intentado minimizar mediante jerarquíasde memorias multinivel. Sin embargo, a nivel de softwarees muy costoso ajustar la aplicación a nivel decache para maximizar el rendimiento. Además, estosajustes son difícilmente portables entre plataformascon distintos procesadores.Sea como fuere, los sistemas multicore ya estándisponibles. Más del 99% de los 500 mejores sistemasde computación de altas prestaciones [5] disponen de1 Departamento de Arquitectura de Computadores y SistemasOperativos, Universitat Autònoma de Barcelona,e-mail: callande@caos.uab.es, eduardo.cesar@uab.es,anna.morajko@uab.es2 Estudis d’Informàtica, Multimèdia i Telecomunicacions,Universitat Oberta de Catalunya, e-mail: jjorbae@uoc.eduprocesadores multinúcleo. Sin embargo, ¿en qué medidase utilizan de forma eficiente los recursos multicoreen los centros de HPC?Por una parte, los modelos multicore han aumentadonotablemente el rendimiento potencial de lossistemas, pero para poder utilizar estos recursos, lasaplicaciones deben ejecutarse en paralelo. Los modelosde programación nos permiten expresar en ciertogrado el paralelismo de las aplicaciones. Sin embargo,dependiendo del tipo de aplicación, no siempreva a ser posible extraer el mismo nivel de paralelismoentre la aplicación y el sistema hardware.La aplicación puede tener restricciones en el gradode paralelismo que limiten la eficiencia. Asimismo,el modelo de programación, encargado de la gestiónde recursos, y que proporciona a la aplicación unnivel de abstración de estos dispositivos, puede noaprovechar de forma eficiente los recursos multicoredebido a una gestión inadecuada. Uno de los modelosde programación más extendidos y que ademáspermite explotar los recursos multicore es OpenMP.Por tanto, en el estudio de la metodología parala sintonización de aplicaciones se deberán analizarfactores de rendimiento en base a las aplicaciones,aquellos generados por el modelo de programación ylos originados a nivel del sistema hardware.Este trabajo se estructura en las siguientes secciones,un análisis general del rendimiento en entornosmulticore se presenta en la sección II. Lametodología propuesta se describe en la sección III.En la sección IV se analizan dos casos de uso parala metodología propuesta, que ha desembocado en ladetección de dos factores de rendimiento candidatos.La experimentación para la evaluación del impactode los factores de rendimiento candidatos se detallanen la sección V. Finalmente, en la sección VI sereflejan las conclusiones y el trabajo futuro.II. Análisis de rendimientoDesde el punto de vista de la arquitectura, una característicacomún de los sistemas multicore, es queestán definidos como sistemas de memoria compartida.Eso significa que los recursos tienen una visióncomún de la memoria principal. Diferentes recursosde cómputo pueden acceder a los mismos datos dememoria. Por tanto, deben aplicar políticas de accesoconcurrente. Además, en los sistemas multicoreexisten problemas debidos a la interconexión entrecores dentro del chip. La compartición de recursosdel procesador, como son los niveles jerárquicos dememoria cache, precisan de un ajuste en cuanto sepretenda obtener el mejor rendimiento posible. Unaaproximación a un modelo de rendimiento en baseJP2011-649

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011a la caracterización del sistema de memoria es presentadaen [6], que presenta una caracterización delsistema hardware mediante microbenchmarks paradeterminar el ancho de banda de acceso a memoriaprincipal y así, poder predecir qué sistema hardwarees más apropiado para la ejecución de una aplicaciónespecífica.Por otra parte, a nivel de software, las aplicacionescientíficas del entorno de HPC son aquellas que debidoa su complejidad requieren un gran tiempode ejecución sobre las arquitecturas de los ordenadoresactuales. Las aplicaciones son ejecutadas enentornos paralelos para obtener su ejecución en elmenor tiempo posible. Estas aplicaciones, de formageneral, presentan patrones de comportamiento comuneso paradigmas de programación paralela. Debidoa su propia naturaleza, cada paradigma de programaciónparalela presenta sus propios problemasde rendimiento. Por tanto, los patrones de la aplicacióndeben ser caracterizados para poder ajustar elsistema en la medida de lo posible. De los paradigmasde programación paralela más utilizados en entornosHPC podemos identificar los tipos Master-Worker, Pipeline, SPMD (Single Program MultipleData) y Divide&Conquer.Finalmente destacar que, no únicamente van aexistir problemas de rendimiento a nivel de aplicacióncientífica y arquitectura hardware. El encargadode gestionar la ejecución de la aplicaciónparalela y la asignación a los recursos es la libreríadinámica del modelo de programación. A este nivel,existen problemas generados en el desajuste de losrequisitos de la aplicación y los recursos multicore.Existe cierta diversidad de modelos de programaciónque explotan las arquitecturas de memoria compartida.Entre los más extendidos están OpenMP, Cilk,Intel TBB.En este trabajo vamos a analizar algunos problemasde rendimiento en el modelo de programaciónOpenMP.A. Modelo de programación OpenMPEl modelo de programación OpenMP es unestándar que permite abstraer la utilización dethreads. Cabe destacar que es un modelo de programaciónmuy utilizado en los entornos HPC. Además,favorece su análisis el hecho de existir implementacionesde código abierto.Los factores de rendimiento conocidos a nivel deineficiencias de la gestión de la librería, vienen determinadospor las primitivas del modelo y por lagestión del propio paradigma de aplicación. Lasprimitivas de OpenMP pueden hacer referencia a unmodelo de paralelismo de datos o a un modelo deparalelismo de tareas.En la reciente definición del estándar OpenMPversión 3.0, se agrega el paradigma de tareas, queamplia las posibilidades de paralelismo con OpenMP.Este es un paradigma concurrente, que en entornosmulticore permite la ejecución paralela de tareas. Siademás, las tareas son independientes, el modelo permitela ejecución de tareas fuera de orden, permitiendola finalización previa de tareas instanciadasdespués de otras, generando un balanceo de la aplicación.Habiendo descrito algunas características del modelode programación, será necesario evaluar el verdaderoimpacto en ejecuciones reales. Por tanto, esnecesario definir las herramientas del estado del arteque van a permitir la obtención de la informaciónpara el análisis de los factores de rendimiento.B. Estudio del sistemaEn el estado del arte, existen diferentes kernels deaplicaciones científicas representativas del entorno deHPC. Entre ellas se han considerado aquellas expresadascon el modelo OpenMP, o aquellas que permitenanalizar aspectos referentes a OpenMP.• Caracterizar aplicaciones científicas; lasbenchmark suites seleccionadas representan alas aplicaciones científicas representativas delentorno de HPC. Pertenecen a núcleos de aplicacionescientíficas reales.1. BOTS (Barcelona OpenMP Tasks Suite)[7];conjunto de benchmark basados en el modelode tareas: uts, strassen, sparselu, sort,nqueens, health, floorplan, fft, alignment2. Parsec (Princeton Application Repository forShared-Memory Computers)[8]; suite para elanálisis de aplicacionse basadas en OpenMP,pthreads y TBB. De las cuales blackscholes,bodytrack, freqmine, y ferret contienen referenciasa OpenMP.3. NPB (NASA Parallel Benchmark Suite)[9];suite de la NASA con núcleos de aplicacionescientíficas, de las que contienen definiciónexclusiva OpenMP: IS (Integer Sort) y DC(Data Cube).4. MRI segmentation [10]; núcleo de unaaplicación científica para la segmentación deimágenes de resonancia magnética. Benchmarkdesarrollado dentro del departamentoCAOS (UAB).• Caracterizar el modelo de programación;mediante pruebas de estrés sobre las primitivasde la librería, es posible obtener medidas paradiferentes parámetros de configuración del modelode programación OpenMP.1. UTS (Unbalanced Tree Search)[11]; benchmarkpara la búsqueda exhaustiva en unárbol altamente desbalanceado. Expresadoen un paradigma de programación Divide&Conquer.Permite la emulación de unmodelo de tareas con varias configuracionespara la gestión de tareas..2. ASC Sequoia; del LLNL (Lawrence LivermoreNational Laboratory); benchmark utilizadoen la caracterización del supercomputadorSequoia. De esta suite es posible utilizarel benchmark CLOMP [12] para la caracterizaciónde la librería de OpenMP, y medir overheadsy rendimiento.JP2011-650

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20113. Sphinx (Integrated parallel microbenchmarksuite); del LLNL. Test de rendimientoOpenMP mediante sphinx omp.4. EPCC (Edimburgh Parallel Computing Center)[13];microbenchmarks para la evaluciónde rendimiento OpenMP para la versión delestándar 2.5 .• Caracterización de hardware; para la descripcióndel sistema hardware mediante pruebasde estrés dinámico.1. ASC Sequoia; del LLNL (Lawrence LivermoreNational Laboratory); realiza pruebasde estrés del sistema de memoria accediendoa diferentes tamaños de datos y con diferentedistribución para la obtención de anchos debanda: STREAM, STRIDE y AMGmk.C. Herramientas para el análisis de OpenMPLas siguientes herramientas permiten instrumentaraplicaciones OpenMP, generar resúmenes otrazas, visualizar trazas y generar análisis postmortem.1. Instrumentación; Para la instrumentaciónde OpenMP es posible utilizar herramientascomo Extrae (Barcelona Supercomputing Center)que permite generar trazas para la herramientaParaver. Además, Papi (PerformanceApplication Programming Interface) [14]permite obtener información del hardware deforma dinámica. Opari[15] (OpenMP PragmaAnd Region Instrumentator) proporciona informacióndinámica de las estructuras y primitivasOpenMP.2. Tracing/Profile; La aplicación instrumentadaproporciona información a las herramientasOmpp[16] (Basado en instrumentacion deOpari), TAU[17] y Extrae.3. Visualización y análisis; Para la visualizaciónde trazas Paraver (BSC), y las herramientasde analisis Scalasca [18] y Dimemas.D. Herramientas para la integración del modelo derendimientoNuestro objetivo es sintonizar dinámicamente. Portanto, son necesarias herramientas para la monitorizacióny sintonización dinámica de la librería queimplementa la gestión dinámica del modelo de programación.1. libgomp; Es posible integrar la lógica de sintonizaciónde forma manual sobre el códigofuente de la librería libgomp de GNU. Paramejorar la portabilidad, es posible utilizarherramientas de sintonización dinámica comoDyninst[19] o Intel Pin[20].2. Framework MATE (Dynamic PerformanceTuning Environment)[21]; permite la sintonizacióndinámica basada en modelos derendimiento. Requiere la descripción del elementotunlet para la integración del modelo derendimiento y las políticas de sintonización.E. Entornos de experimentaciónLas herramientas de simulación han de permitiranalizar la escalabildad y arquitecturas de la próximageneración de procesadores multicore.1. Graphite[22]; entorno de simulación paraleloque permite la simulación de hasta 1024 cores2. AMD SimNow/Cotson[23]; entorno de simulaciónsecuencial que permite la simulaciónde hasta 64 cores.III. Metodología para la detección deineficienciasComo se ha comentado anteriormente, OpenMPpermite cierta flexibilidad para poder expresar diferentesparadigmas de programación paralela. Poreste motivo, existe la necesidad de evaluar a nivel deaplicación los diferentes patrones de forma aislada.Cada paradigma conlleva implícitamente cuellos debotella que dependiendo de la arquitectura podrántener mayor o menor afectación en el rendimiento.Por otro lado, la implementación específica del modelode programación puede contemplar alternativasde diseño. Existen decisiones de diseño sobre aspectosno detallados en la definición del estándar. Lasvariabilidades en la implementación pueden afectaral rendimiento dependiendo de aspectos relativos ala asignación de trabajos y gestión de recursos. Porejemplo, la utilización de estrategias de gestión de tareasmediante la utilización de recursos de memoriacentralizados o estrategias de gestión descentralizadas.La diversidad de contextos requiere un estudiopara cada configuración.Por tanto, se ha definido una metodología parael estudio de factores de rendimiento basada en unmodelo en espiral que ha de permitir la definiciónanalítica de modelos de rendimiento para factoresde rendimiento, así como la propuesta y modeladode soluciones a factores de rendimiento del modeloexistente. Se ha propuesto un modelo en espiralpor la necesidad de evaluar de forma independientecada factor de rendimiento y poder verificar su impactode forma aislada. Las nuevas iteraciones ala metodología nos permitiran agregar un mayor alcancey precisión a la metodología.Se definen a continuación las etapas:1. Definir el contexto del estudio En estaetapa se delimita el contexto de estudio. Sedefine el paradigma de programación paralelaa evaluar, las herramientas de benchmark quehan de permitir caracterizar el problema y lapreparación del entorno de ejecución.2. Identificar factores de rendimiento Teniendoen cuenta que existen factores derendimiento en los niveles de aplicación, modelode programación paralela y hardware. Seanaliza una funcionalidad de OpenMP o unparadigma de programación paralela y se analizanlas ineficiencias de la aplicación para diferentesconfiguraciones. Tras la detección deineficiencias en base a la definición de varias con-JP2011-651

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011figuraciones, se obtiene un factor de rendimientocandidato.3. Evaluación del impacto de los factoresde rendimiento Para la evaluación del impactose mide empíricamente el tiempo de ejecuciónde las configuraciones posibles del factorde rendimiento, y se determina qué configuraciónobtiene mayor speedup y eficiencia. Severifica mediante simulación que es posible reproducirel problema de rendimiento obtenidoen el entorno real. Posteriormente, se analizamediante simulación el impacto del factor derendimiento para arquitecturas con gran númerode cores.4. Modelo de rendimiento o alternativade diseño y modelado Modelar el factorde rendimiento o proponer una alternativade diseño conjuntamente con su modelo derendimiento. Este proceso requiere la recopilaciónde las medidas y configuraciones para elfactor de rendimiento y buscar una relación quepermita predecir el comportamiento en un entornodinámico.5. Verificación del modelo de rendimientoIntegrar el modelo de rendimiento mediante lasherramientas de sitonización que permitan actuara nivel de la librería dinámica de OpenMP.Verificar mediante la sintonización dinámica sila predicción permite conseguir una mejora respectoa la ejecución sin sintonizar. Posteriormente,analizar el overhead debido a la instrumentacióny sintonización dinámica y verificar laprecisión del modelo generado. Posteriormente,se valida el modelo en un entorno de simulación,mediante la simulación del modelo sobre una arquitecturacon alto número de cores.IV. Casos de usoEn esta sección se muestran dos casos de uso de lametodología presentada anteriormente.A. Paralelismo de datosEn el modelo de paralelismo de datos existen factoresde rendimiento relacionados con la gestión delreparto de iteraciones en bucles paralelizados, primitivasde acceso concurrente a memoria y la asignaciónde threads sobre cores en base a datos afines paraminimizar fallos de cache.Respecto al reparto de iteraciones de bucles paralelizados,para una carga de trabajo desbalanceada,es posible en OpenMP aplicar tres estrategias de planificación:static, dynamic y guided.La estrategia de planificación estática reparte lasiteraciones en base al factor denominado chunksize.Previo al cómputo, se realiza la asignación de rangosde iteraciones para cada thread. La reparticiónde rangos altamente desbalanceados va a afectar alrendimiento de la aplicación.La planificación dinámica reparte iteraciones detamaño chunksize bajo demanda. Cuando un threadfinaliza la ejecución de las iteraciones asignadas, solicitanuevas iteraciones. Esta estrategia mejorael balanceo de carga. Sin embargo, tiene unpequeño overhead en los accesos concurrentes parala demanda de nuevas iteraciones, que afectará alrendimiento si los accesos son muy frecuentes o siintervienen un gran número de threads.El método guiado reparte bajo demanda grupos deiteraciones, empezando con tamaños grandes hastallegar a un tamaño chunksize definido por el usuario.Esta estrategia puede conseguir una mejora en el balanceoy pretende minimizar los problemas de las estrategiasanteriores.Por otro lado, existen factores de rendimiento enla utilización de las primitivas de acceso a memoria.Las diversas directivas OpenMP ofrecen diferentefuncionalidad y rendimiento en el acceso concurrente.Sin embargo, dependiendo de la aplicación no siempreserá posible utilizar la directiva con menor overhead.También existe en algunas implementaciones delmodelo de programación, aunque fuera del estándarde definición de OpenMP, la posibilidad de definirel orden de asignación de threads sobre los coresen base a la afinidad. Mediante esta definición, esposible asignar threads con regiones afines sobre mismosniveles de memoria para minimizar los fallos decache. Gracias a esta definición, también es posibleevitar problemas de falsa compartición. Éstos problemasocurren cuando threads en niveles diferentesde la jerarquía de memoria compiten por los mismosdatos, y aunque ejecutados de forma paralela, la disputaen el acceso concurrente a los datos serializa laejecución y además añade un alto overhead debido aconstantes fallos de cache y migración de datos.B. Paralelismo de tareasLos factores de rendimiento en este paradigmaestán relacionados con la gestión de tareas de la implementaciónOpenMP. Existen dos estrategias principalmente.El modelo centralizado dispone de unacola compartida que almacena las tareas, a dónde losthreads ociosos acceden de forma concurrente para laobtención de tareas. El otro modelo, está basado encolas descentralizadas. Cada thread cuenta con unacola local. Cuando un thread queda ocioso calculamediante una función (e.g. random) el identificadorde un thread sobre el que acceder a su cola localpara iniciar el robo de tareas, este thread es llamadovíctima.En el modelo de gestión centralizada, se presentaun problema de rendimiento en base al acceso concurrentea la cola. Este factor puede ser más significativocuantos más threads existan en el sistema.Por tanto, el tiempo de acceso concurrente limita elrendimiento.En la gestión descentralizada existen dos factoresde rendimiento principalmente. El primero consisteen la posible ineficiencia en identificar al threadvíctima con suficiente carga de trabajo. Las diferentesimplementaciones suelen utilizar una lógica simple.Por ejemplo, mediante una función aleatoria oJP2011-652

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011seleccionando la víctima en el thread vecino. Paraminimizar la búsqueda de cargas es posible, al identificaruna víctica, robar un conjunto de tareas. Existeen esta solución un factor de rendimiento a tener encuenta, la decisión del número de tareas que van aser migradas de una cola a otra.V. Evaluación del impactoSe ha desarrollado un estudio de impacto para losfactores de rendimiento candidatos presentados anteriormente.A. Paralelismo de datosEl contexto inicial se ha centrado en el análisis dela gestión de iteraciones en el paralelismo de bucles.Se ha analizado una aplicación embarazosamenteparalela, basada en la segmentación de imágenes deresonancia magnética. El algoritmo tiene la caracterísitcade segmentar cortes 2D de una imagen tridimensional.Por tanto, es posible paralelizar los cortesde forma independiende. Ha sido candidato para laevaluación de las primitivas de paralelismo de buclesde OpenMP, que permite definir tres estrategiasde planificación de iteraciones. Las estrategiasse diferencian entre aquellas que favorecen un balancede carga dinámico o guiado bajo demanda, yla planificación estática que minimiza el overhead dela gestión dinámica mediante una preasignación inicialde iteraciones.Fig. 1. Caracterización de las cargas F y Z del BenchmarkMRI SegmentationPara la evaluación del impacto se ha realizado unaejecución en un nodo con 8 cores. Teniendo 2 procesadoresIntel Xeon E5504 de 4 cores a 2GHz y 8GBytes de memoria. Se han evaluado diferentes cargasde trabajo. En la figura 1 se puede observar eltiempo de ejecución serie, para cada corte de la imagen,de las cargas etiquetadas en la figura como F yZ. Cada corte corresponde a una iteración del buclegestionado con OpenMP. Se ha verificado como lasestrategias de planificación tienen una afectación enel rendimiento, y que dependerá de las característicasde carga de trabajo. En la figura 2 se presenta elspeedup de la carga etiquetada F. En esta gráficase puede observar que el rendimiento no ha escaladode forma adecuada, obteniendo una eficiencia para 8threads del 56% en la estrategia estática y del 53%en la estrategia guiada. La estrategia dinámica seha adaptado mejor a la carga desbalanceada, obteniendopara todos los casos una eficiencia superior al90%.Por tanto, es posible mejorar el rendimiento si seobtiene una caracterización de las cargas de trabajo,o utilizando una estrategia dinámica. Para analizarel impacto de estas estrategias en entornos con altaescalabilidad se utilizará la simulacion en trabajosfuturos.Fig. 2. Speedup obtenido en las estrategias de planificaciónpara la carga de datos etiquetada FB. Paralelismo de tareasSe ha evaluado el impacto de las estrategias deplanificación en el modelo de paralelismo de tareasmediante el benchmark UTS. Este benchmark generamediante un algoritmo recursivo un árbol detareas altamente desbalanceado. La implementacióndel benchmark UTS permite su ejecución mediantevarios modelos de programación.Para la evaluación del rendimiento se ha ejecutadoel benchmark en su versión de paso de mensajesMPI que proporciona dos tipos de planificación detareas. La centralizada (WorkSharing) y descentralizada(WorkStealing). El nodo de cómputo disponede dos procesadores Intel Xeon E5504 a 2GHz y 8GBytes de memoria, con un total de 8 cores pornodo.La estrategia WorkSharing o centralizada disponede una cola compartida que genera concurrecia en laobtención de tareas. La estrategia WorkStealing odescentralizada, donde cada proceso dispone de unacola local y en caso de inanición se accede a los procesosvecinos para la solicitud de tareas mediante unalgoritmo de polling adaptativo. El benchmark tienepor defecto el factor de robo de tareas definido en 20tareas por robo.En la gráfica 3 la estrategia centralizada no consiguebalancear rápidamente la carga de trabajo paraun pequeño número de cores y, sin embargo, obtieneel mejor rendimiento para el máximo númerode cores. A su vez, la estrategia descentralizada obtieneun mejor balance de carga de forma generalpara cualquier número de procesos, pero la localizaciónde víctimas y transferencia de tareas limitasu rendimiento. Sin embargo es necesario evaluarel algoritmo para un mayor número de procesadoresy cores para determinar la tendencia general de laspolíticas. Este estudio se analizará mediante simulaciónen trabajos futuros.JP2011-653

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3. UTS scheduling. Experimento T1L con generación de102.181.082 tareasPor otra parte, ha sido posible analizar el factorde robo de tareas de la planificación de descentralizada.Mediante la ejecución del benchmark UTS ensu configuración OpenMP de memoria compartida,se ha evaluado el impacto de rendimiento en el ajustedel factor de tamaño de robo de tareas. Se ha realizadouna ejecución con tamaños de número de robosde 1 a 50. En la figura 4 se muestra un detalle delárbol T1 con la localización del mínimo. Este valoróptimo se encuentra entre 10 y 25 para el conjuntode árboles evaluado.Fig. 4. Ejecución exhaustiva del benchmark UTS para laidentificación del tamaño óptimo de robo de tareasSin embargo, este valor de robo de tareas vienedeterminado por un sistema donde las tareas tienenel mismo peso de cómputo. En trabajos futuros seevaluará un sistema donde las tareas tengan heterogeneidaden el cómputo para analizar la variabilidaddel tamaño óptimo de robo de tareas.VI. ConclusionesEn este artículo se ha propuesto una metodologíabasada en el análisis de cuellos de botella en aplicacionesOpenMP, mediante la detección de factores derendimiento, evaluación del impacto y generación deun modelo predictivo. Se ha iniciado la metodologíaanalizando los factores de rendimiento basados en lasestrategias de planificación de iteraciones de buclesparalelos y planificación de tareas. Se ha evaluado elimpacto para las arquitecturas disponbles mediantela experimentación y se ha determinado la necesidadde utilizar herramientas de simulación que permitiránevaular el impacto de estos factores en arquitecturasmulticore de próxima generación.AgradecimientosEste estudio de investigación está enmarcado enel Proyecto Computación de Altas Prestaciones y suAplicación a la Ciencia e Ingeniera Computacional,financiado por el MEC (Ministerio de Educación yCiencia) con referencia TIN2007-64974.Referencias[1] Intel, “Single chip-cloud computer project,” .[2] “Tilera,” http://www.tilera.com.[3] “Next generation cuda architecture,”http://www.nvidia.com/object/fermi architecture.html.[4] “The amd fusion family of apus,” http://fusion.amd.com.[5] “Top 500 list, november 2010,”http://www.top500.org/lists/2010/11.[6] Samuel Williams et al., “Roofline: an insightful visualperformance model for multicore architectures,” Commun.ACM, vol. 52, pp. 65–76, April 2009.[7] A. Duran et al., “Barcelona openmp tasks suite: A set ofbenchmarks targeting the exploitation of task parallelismin openmp,” in Parallel Processing, 2009. ICPP ’09. Int.Conf. on, sept. 2009, pp. 124 –131.[8] Christian Bienia et al., “The parsec benchmark suite:characterization and architectural implications,” in Proceedingsof the 17th Int. Conf. on Parallel architecturesand compilation techniques, USA, 2008, PACT ’08, pp.72–81, ACM.[9] D. H. Bailey et al., “The nas parallel benchmarks,” Tech.Rep., The Int. Journal of Supercomputer Applications,1991.[10] John Ashburner and Karl J. Friston, “Voxel-basedmorphometry–the methods,” NeuroImage, vol. 11, no.6, pp. 805 – 821, 2000.[11] Stephen Olivier et al., “Uts: An unbalanced tree searchbenchmark,” in Languages and Compilers for ParallelComputing, George Almási, Calin Cascaval, and PengWu, Eds., vol. 4382 of Lecture Notes in Computer Science,pp. 235–250. Springer Berlin / Heidelberg, 2007.[12] Greg Bronevetsky et al., “Clomp: Accurately characterizingopenmp application overheads,” in OpenMP in aNew Era of Parallelism, Rudolf Eigenmann and Bronisde Supinski, Eds., vol. 5004 of Lecture Notes in ComputerScience, pp. 13–25. Springer Berlin / Heidelberg,2008.[13] “The epcc microbenchmarks page,”http://www.epcc.ed.ac.uk/research/openmpbench/.[14] J. Dongarra et al., “A portable programming interfacefor performance evaluation on modern processors,” Int.Journal of High Performance Computing Applications14: 189, 2000.[15] Bernd Mohr et al., “Design and prototype of a performancetool interface for openmp,” The Journal of Supercomputing,vol. 23, pp. 105–128, 2001.[16] Karl Fürlinger and Michael Gerndt, “A profiling tool foropenmp,” in OpenMP Shared Memory Parallel Programming,2008, pp. 15–23.[17] Sameer S. Shende et al., “The tau parallel performancesystem,” The Int. Journal of High Performance ComputingApplications, vol. 20, pp. 287–331, 2006.[18] Markus Geimer et al., “The scalasca performance toolsetarchitecture,” in Concurrency and Computation: Practiceand Experience, 2010, pp. 702–719.[19] Gregory Lee et al., “Dynamic binary instrumentation anddata aggregation on large scale systems,” Int. Journal ofParallel Programming, vol. 35, pp. 207–232, 2007.[20] Chi-Keung Luk et al., “Pin: building customized programanalysis tools with dynamic instrumentation,” inProcs. of the 2005 ACM SIGPLAN conf. on Programminglanguage design and implementation, USA, 2005,PLDI ’05, pp. 190–200, ACM.[21] Anna Morajko et al., “Mate: Dynamic performance tuningenvironment,” Euro-Par 2004 Parallel Processing,pp. 98–107, 2004.[22] J.E. Miller et al., “Graphite: A distributed parallel simulatorfor multicores,” in High Performance ComputerArchitecture (HPCA), 2010 IEEE 16th Int. Symposiumon, jan. 2010, pp. 1 –12.[23] Eduardo Argollo et al., “Cotson: infrastructure for fullsystem simulation,” SIGOPS Oper. Syst. Rev., vol. 43,pp. 52–61, January 2009.JP2011-654

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Herramientas para la monitorización de losaccesos a memoria de códigos paralelosmediante contadores hardwareOscar G. Lorenzo, Juan A. Lorenzo, Dora B. Heras, Juan C. Pichel y Francisco F. Rivera 1Resumen— En este trabajo se presenta el desarrollode una serie de herramientas que facilitan, especialmenteen códigos paralelos, tanto la programación delos contadores EARs (Event Address Registers) de losprocesadores Itanium 2 como el acceso y lectura de lainformación ofrecida por ellos. En concreto, se handesarrollado las siguientes herramientas:Una herramienta que permite la inserción en unprograma paralelo del código de monitorización y programaciónde los contadores hardware de una formasencilla e intuitiva. Se han realizado dos versiones,una ejecutable desde la línea de comandos, que tomacomo entrada un programa paralelo y devuelve comosalida el programa paralelo con el código de monitorizaciónañadido, y otra con una interfaz gráfica queañade el código de monitorización de forma gradualsegún lo requiera el usuario.Otra herramienta que toma como entrada la informaciónobtenida por el código paralelo monitorizado,y muestra la información obtenida por los contadoreshardware de forma amigable y clara, pero a la vez exhaustivay detallada. Esta herramienta permite ajustarel nivel de detalle, de modo que se puede elegirdesde una vista global de los accesos a memoria, hastauna muestra detallada evento a evento.Se ha realizado un estudio de estos desarrollos sobrediversos problemas paralelos irregulares de memoriacompartida en el supercomputador FinisTerrae,centrándose en el producto matriz dispersa vector.Aunque el trabajo se ha realizado en el entorno delFinisTerrae, las herramientas obtenidas son de aplicacióngeneral para cualquier otro sistema basado enprocesadores Itanium 2, que disponen de contadoreshardware, tanto mono como multiprocesador.Palabras clave— Contadores hardware, códigos irregulares,monitorización.I. IntroducciónUNO de los ámbitos donde la gestión de la memoriay el aprovechamiento de los ciclos de la CPUes más importante es el de la supercomputación.Para que un código paralelo se ejecute de forma correctay eficiente, su programación ha de ser muycuidadosa, teniendo en cuenta las características arquitectónicas,y en particular el comportamiento delos accesos a la memoria.El hecho de que el paradigma de computación enmemoria compartida esté presente extensivamente,desde plataformas como teléfonos móviles hasta PCs,ha determinado que librerías como OpenMP [1], quenacieron junto con los grandes supercomputadoresmultiprocesador, sean hoy estándar en cualquier distribución.Pese a todo el cambio de paradigma desdela programación secuencial a la paralela no es simple,y aún queda mucho por hacer.1 Grupo de Arquitectura de Computadores, Departamentode Electrónica y Computación, Univ. de Santiago deCompostela, e-mail: {oscar.garcia,juanangel.lorenzo,dora.blanco,juancarlos.pichel,ff.rivera}@usc.es,Es por todo esto que los fabricantes de microprocesadoresintegran en sus diseños de alta gama contadoreshardware (CH) [2] en aplicaciones que son utilizadaspor programadores no solamente restringidasa la caracterización del rendimiento de los procesos.Por ejemplo, son de gran utilidad en la depuraciónde códigos paralelos, para encontrar aquellos puntosdel código donde el programa sobrecarga ciertasCPUs o deja sin trabajo a otras, etc. Incluso puedenser usados para modificar los programas en tiempode ejecución de manera que sean más productivos[3][4].La familia de procesadores Itanium 2 ofrece untipo particular de CH denominado EARs [2] que ofreceninformación sobre eventos asociados a los accesosa memoria a nivel de las direcciones virtuales, y enlos que se basan los incluidos en los procesadores másmodernos de Intel. Esta información incluye, entreotros, la presencia de fallos de TLB, fallos a diferentesniveles de memoria caché, latencias de acceso, etc,para cada dirección virtual. Esta información puederesultar muy valiosa al programador, pero accedera ella resulta complejo y tedioso. En este trabajomostramos diversas herramientas que facilitan el usode estos CH.II. Los contadores hardware en elFinisterraeEl supercomputador FinisTerrae [5] es un sistemaintegrado por nodos de memoria compartidacon una arquitectura SMP NUMA. Está compuestopor 142 nodos de computación HP Integrityrx7640 [6] con 16 núcleos Itanium Montvale y 128GB de memoria cada nodo, 1 nodo HP IntegritySuperdome, con 128 núcleos Itanium Montvale y1.024 GB de memoria, y 1 nodo HP IntegritySuperdome, con 128 núcleos Itanium 2 y 384 GBde memoria. La memoria de estos procesadoresestá compuesta por tres niveles de memoria caché.Además, las diferentes velocidades de acceso a lamemoria principal local frente a la remota hacen queel tiempo de acceso a los datos sea uno de los aspectosque más influye en el rendimiento de los códigosparalelos de memoria compartida, sobre todo en loscódigos que presenten accesos irregulares.El procesador Itanium2 Montvale tiene una jerarquíade memoria en tres niveles. En cada core, elprimer nivel consta de dos memorias de 16KB, unapara datos y otra para instrucciones. El nivel 2 presentauna caché L2 de 256KB dedicada únicamentea los datos, y una caché L2 de 1MB para instruc-JP2011-655

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 1.El procesador Itanium 2 Montvale.ciones. El tamaño de la caché del tercer nivel varíadentro de cada familia entre 1,5 MB y 24 MB. Eneste trabajo nos centramos en el nivel 1 de caché dedatos, ya que en ella se producirán la mayoría de losfallos caché de datos para su posterior detección porlos CH. La latencia mínima de un fallo en la L1 esde 5 ciclos, que se produce cuando el dato está enla L2 de caché. Mientras que si está en el nivel 3 lalatencia pasa a ser de, al menos, 14 ciclos. Los datosen punto flotante se guardan directamente en el nivel2 de caché, por lo que su lectura siempre provoca unfallo en le nivel 1. Los EAR utilizados para capturarfallos caché permiten detectar éstos con latencias deal menos 4 ciclos, por lo que con su lectura se podrándetectar potencialmente todos ellos.La TLB consta de dos niveles y se divide en TLBde instrucciones y de datos. Cada TLB de nivel 2soporta 32 registros de traducción por cada procesador.La familia Itanium dispone de una PMU (PerformanceMonitoring Unit). Esencialmente consiste enuna serie de registros y contadores hardware que contieneninformación sobre lo que ocurre en la CPU durantela ejecución de instrucciones. Estos se dividenprincipalmente en registros de configuración (PMC),que son programables y guardan información sobrelo que almacenan los otros registros, y los registrosde datos o PMD, que pueden ser leídos para obtenerinformación sobre la ejecución de las instrucciones.La PMU es un subsistema sincronizado con estadoglobal, donde todos los contadores se pueden iniciaro detener al mismo tiempo.La PMU puede filtrar los eventos que captura demúltiples maneras, por ejemplo, por nivel de privilegio,por el código de la instrucción o por direccionesde memoria virtual.Los Event Address Registers (EAR) son un tipo especialde estos contadores hardware presentes en lafamilia Itanium. Obtienen información sobre las direccionesde memoria accedidas y sus latencias. LosEARs ofrecen una manera de obtener informacióndetallada de los fallos de caché, TLB y ALAT cuandose producen. Por cada evento capturado se guarda enlos registros de la PMU la dirección de la instrucciónque provocó el acceso a memoria, la dirección de lamemoria virtual que provocó el fallo y la latencia dela recuperación de la dirección en los fallos de L1. Elfallo en niveles superiores se deduce de su latenciade resolución. También puede obtenerse el nivel deTLB donde se resolvió la traducción. Dentro de losfallos de TLB se pueden detectar fallos en cada unode sus niveles.Los registros de la PMU pueden configurarse manualmente.De esta manera los EARs pueden serconfigurados para capturar tan solo los eventos deinterés. Para eventos de fallo caché se puede definirtanto la latencia mínima de resolución del fallo, convalores fijos desde 4 a 4096, como el tipo de caché,si datos o instrucciones. En este trabajo nos hemoscentrado en los fallos en la caché de datos, generalmentede latencias bajas. En la práctica se debeguardar la latencia en un registro PMC e indicar alprocesador el tipo de evento considerado en otro diferente(entre fallos en la caché de instrucciones, falloen la caché de datos, fallo en la TLB o fallo en laALAT). Los EARs no pueden capturan los accesos acaché que no provoquen fallo, así como los accesos deescritura. Debe tenerse en cuenta de que funcionana través de un proceso de muestreo, lo que significaque no es posible capturar sistemáticamente todoslos eventos que se producen. Es necesario indicar ala PMU el período de muestreo deseado.Para realizar la programación de las PMUs yobtener los resultados de la ejecución de los códigosse ha usado la librería libpfm2[7] y la interfaz de comunicaciónperfmon2[7]. Libpfm es una librería deayuda que puede ser usada para la creación de herramientasde monitorización de CPUs. La librería contienetoda la información sobre las PMU específicasde cada modelo de procesador, por ejemplo los nombresy códigos de los eventos y de las diferentes variablesde estos. El programador tan solo tiene que indicaren las funciones lo que se quiere medir y estasdeterminan el modo de programar la PMU. La in-JP2011-656

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011terfaz perfmon2 es un subsistema de monitorizacióndel rendimiento para Linux para obtener acceso a loscontadores, programarlos y leerlos.Esta librería soporta tanto a la familia de procesadoresItanium como las familias X86-64 y P6, asícomo a procesadores de otras marcas (AMD o ARM).La interfaz de la librería manipula eventos usandodescriptores opacos, por ejemplo enteros simples.III. Herramienta de instrumentaciónPreparar un programa paralelo para que realice lamonitorización de los EAR requiere el uso de diversasfunciones de la libpfm para encontrar los contadoresespecíficos, así como sus valores requeridos. Utilizarlos contadores hardware en un sistema paralelo presentadiversos inconvenientes, uno de los cuales es lanecesidad de trabajar con contadores presentes enlos procesadores individuales en arquitecturas quepueden tener un gran número de ellos, lo que implicala programación de todos. Realizar las lecturasexactas que requerimos puede ser complicado y costoso.Al ejecutar en paralelo varios hilos o procesosresulta complicado identificar en qué procesador seubicarán, o incluso si no serán migrados durante laejecución.En principio el hecho de que todos los procesadoressean iguales (como ocurre en el FinisTerrae), y portanto con la misma programación, simplifica el procesoen cierta medida, ya que se pueden programarlos EARs de la misma manera desde cada hilo. Lamonitorización en sí de los otros procesadores puedeser llevada a cabo por otro hilo. Esto complica laprogramación y seguimiento, ya que dificulta saberdonde se está ejecutando cada parte del código. Resultamás sencillo que cada hilo se monitorice a símismo, así se puede comprobar fácilmente qué CPUy qué hilo que realizó cada operación. Pese a todoesta auto-monitorización no está exenta de problemas.El más obvio es que el rendimiento de la aplicaciónbaja, ya que el hilo ocupa parte de su tiempoen la monitorización; sin embargo este tiempo sueleser de escasa relevancia.La herramienta desarrollada resuelve el problemade añadir el código de monitorización necesario paratrabajar con los EAR de forma lo más automáticaposible en un programa paralelo. La automatizaciónno puede ser total, pues el usuario debe poder indicarel evento a capturar o el punto de inicio de lamedición en el código, pero simplifica en gran medidaesta tarea. Para cada evento se guarda la direcciónde memoria cuyo acceso lo provocó, la dirección enmemoria de la instrucción cuya ejecución lo provocó,la CPU donde se produjo y el dato medido (latenciade la operación en casos de fallo caché o nivelde resolución en fallos de TLB). El código debe serañadido en unos puntos concretos del programa amonitorizar. Esta inserción puede dividirse en trespartes (Figura 2):• Código Previo: Este código precede tanto a laprogramación de los contadores como a su lectura.Incluye las librerías usadas y la definiciónde diversas constantes necesarias para el funcionamientodel código en general, así como lasdeclaraciones de variables y funciones globales(principalmente de lectura de los D-EARs) queson usadas posteriormente.• Código de Inicio: Este código precede exactamenteal inicio de la monitorización, y debe encuadrarseen la misma sección paralela. Incluyetanto la inicialización de la librería libpfm comola programación de los contadores de cada PMU,y acaba con la orden de inicio del muestreo.• Código de Finalización: Este código se encargade finalizar el muestreo, es decir que sigue al finalde la parte del programa que se desea medir.Se encarga también de procesar la informaciónque pueda faltar. La herramienta de instrumentalizaciónusa esta caracterización en su diseño.Fig. 2.Programa paralelo instrumentado.Se ha desarrollado una interfaz gráfica que insertael código de monitorización dentro del código fuentedel programa a medir. Las razones para crear unaversión gráfica para esta herramienta son esencialmentedos. Por un lado la funcionalidad de la herramientagráfica facilita su uso por usuarios poco especializados.Por otro lado la interfaz gráfica reduce lasposibilidades de que el usuario cometa errores. Conesta versión ya no es necesario editar el fichero fuentea modificar, pues la propia herramienta incluye uneditor de textos, pudiéndose indicar directamente enel programa los puntos donde insertar el código, yvisualizar los efectos de esa inserción.También limitala posibilidad de que el usuario introduzca argumentosinválidos para el código de libpfm, ya que estosson controlados automáticamente por la interfaz.JP2011-657

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 3.Herramienta de visualización. Histograma Detallado.La herramienta gráfica permite realizar la inserciónde cada sección de código de monitorizaciónde manera separada. De este modo cada inserción esun caso de uso, y la inserción del código de inicio incluyela selección de argumentos. El usuario tambiénpuede abrir un fichero fuente, guardar el código resultantetras todas las modificaciones y elegir el idiomaen que funcionará la aplicación.IV. Herramienta de visualización deresultadosLos datos obtenidos por el código de monitorizaciónno resultan prácticos de estudiar directamente.En primer lugar debido a la gran cantidad deeventos que pueden ser capturados en una sola ejecuciónde un programa, y en segundo lugar porquelo realmente interesante es el conjunto de datos ensu totalidad, no cada evento en particular; de estemodo es necesario procesar la información obtenida.Los datos que se guardan de cada evento son los dedirección de memoria del dato accedido, dirección dememoria de la instrucción, CPU en la que ocurreel evento y dato de latencia o tipo de fallo TLB.Adicionalmente, se guarda en un archivo separado elnombre del evento estudiado, el rango de memoriadonde se capturó y el número de hilos de ejecucióndel código medido. Con estos datos se puede hacerun estudio completo de los accesos a la memoria.Para estudiarlos se puede usar herramientas de monitorizacióny visualización y de análisis matemáticoy estadístico [8][9][10][11], como Matlab, Octave oR. Sin embargo es preferible usar una herramientamás sencilla y con menos opciones, pero más especializadaen el problema, que permita obtener unavista rápida y general de éste, a la vez que permiteentrar en más nivel de detalle. Una herramientaasí evita el uso de programas complejos y potencialmentedifíciles de manejar, mientras que su especializaciónpermite adaptar todas sus funcionalidades alproblema en cuestión, facilitando su uso. Por ello hasido desarrollada una herramienta de visualizaciónde resultados.La funcionalidad principal de la herramienta es lade ordenar los eventos capturados en grupos según ladirección de memoria que los provoca, y mostrarlosconjuntamente en un histograma delimitado por lasdirecciones inicial y final del rango de memorias estudiado.De este modo se permite al usuario obteneruna visión general y gráfica de los accesos a memoriade su programa.El histograma puede ser refinado apetición del usuario, por ejemplo, utilizando para sucreación tan solo los eventos provocados por cierta instruccióno CPU, o modificando el número y tamañode los grupos, para aumentar o reducir el nivel dedetalle. En el caso de los eventos de fallo caché el histogramapuede mostrar las latencias medias de cadagrupo de direcciones. La herramienta lee desde losficheros de datos los eventos procesados, y los guardaen memoria.Los histogramas que se pueden visualizar son lossiguientes:• Histograma de Ocurrencias: Muestra el númerode eventos individuales agrupados según la direcciónde memoria a que hagan referencia. Enel caso de los eventos TLB se utilizan distintoscolores para cada tipo de fallo.• Histograma de Latencias: Muestra la latenciamedia de cada clase de direcciones de memoria.• Histograma General: Puede ser de latencias o denúmero de ocurrencias. Muestra todo el rangode memoria, ajustando el histograma de modoque se vea entero en la ventana de la aplicación.Se puede modificar el número de clases para hacerlomás o menos ajustado.• Histograma Detallado: Puede ser de latenciaso de número de ocurrencias. Muestra todo elJP2011-658

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011rango de memoria, ajustando el número de direccionesde memoria por grupo. Cuando existenmuchos datos se muestra un histograma generalpequeño para mejorar la navegación (Figura3).V. Caso de estudio: Producto matrizdispersa vectorEl producto matriz dispersa vector (SpMxV), es unaoperación básica del álgebra matricial, de especialrelevancia en aplicaciones prácticas. En métodos iterativosde resolución de grandes sistemas de ecuaciones,el SpMxV se ejecuta en un lazo con un ciertonúmero de iteraciones, de manera que caracterizar elcomportamiento del acceso a los datos es importantepara entender el rendimiento en su ejecución. Laparalelización del SpMxV es relativamente sencilla, sepueden distribuir las filas y/o columnas de la matrizentre los procesadores. De este modo cada procesadortendrá a su cargo el cálculo de una parte delvector resultado (Figura 4). Al trabajar con matricesdispersas las irregularidades de los datos hacenque el reparto no resulte equitativo en cuandoal número de columnas o filas, que es el mismo paracada procesador. De este modo las CPUs con mayorcarga de trabajo provocan un mayor número de falloscaché, y se puede caracterizar el comportamientodel FinisTerrae usando diferentes matrices.esta manera no se capturan eventos que tengan lugaren la inicialización de los vectores o en la lecturade la matriz, por ejemplo. En este estudio se puedever como OpenMP reparte el trabajo entre los hilos,como la dispersión de los datos de la matriz dispersaafecta a las operaciones y como la PMU del procesadorcaptura los eventos.Para la realización de este estudio se seleccionóun conjunto de matrices dispersas del repositoriode MatrixMarket [12]. La selección de matrices sellevó a cabo de modo que se obtuviera un conjuntolo más variado posible. En primer lugar se limitóla selección a matrices cuadradas por simplicidad,y se decidió escoger tres grandes grupos en funciónde su tamaño. Dentro de cada uno de estos gruposse eligieron matrices tanto simétricas y asimétricas,así como matrices en banda y no en banda. Se encontrarondos matrices con distinta densidad de entradasdistintas de cero de cada tipo dentro de esteespectro de posibilidades. Dada la cantidad de datosobtenidos tan solo se mostrará aquí el estudio detalladopara dos de estas matrices.En la familia Itanium 2 las lecturas de datos enpunto flotante no pasan por el nivel 1 de las cachéde datos, sino que se leen directamente del nivel 2.De este modo, ya que el vector V (ver Figura 4)del problema está formado por números reales, todaslas lecturas a V provocan un fallo caché con unalatencia mayor de 4 ciclos, y pueden ser capturadaspor los EARs, estando limitado el número de accesosdetectados únicamente por el procedimiento demuestreo necesario para la lectura y escritura de estoscontadores. Nótese que los accesos al vector Vestán regidos por la indirección dada por el patrónde la matriz dispersa A, ya que en el SpMxV tan solose accede a las posiciones de V que coincidan conelementos distintos de cero de A.Fig. 4.Reparto de la matriz dispersa entre hilos.El objetivo principal de este estudio es comprobarcómo con el uso de los contadores EAR y las herramientasdesarrolladas se puede obtener una imagenútil del comportamiento de los accesos a memoriacompartida de un programa paralelo. El estudioconsiste en la ejecución del programa SpMxV con diferentenúmero de hilos y capturando en cada ejecucióneventos EAR, utilizando el código de monitorización.Nótese que no se ha pretendido sacar conclusionesdel estudio del comportamiento obtenido, sinomostrar las capacidades de las herramientas desarrolladas.La captura de eventos comienza en cada casojusto antes de la operación matricial principal delprograma, y finaliza justo en su terminación. DeEn las Figuras 5 y 6 se pueden observar los accesosde lectura al vector V realizadas por cadahilo, mostrados con la herramienta de visualización.Cada histograma muestra el rango total de direccionesde V y cada barra el número de lecturas capturadas(ocurrencias del evento data cache lat 4,es decir, evento de fallo caché con latencia de resoluciónmayor de 4 ciclos) en cada clase. Estos datoshan sido obtenidos mediante la instrumentación delcódigo SpMxV con la herramienta de instrumentalización,con un periodo de muestreo de 50. Se pudecomprobar fácilmente cómo la estructura de la matrizinfluye en la dispersión de los accesos. Ya que lamatriz bcsstk18 (Figura 5(a)) presenta un patrón enbanda, los accesos al vector V de los 4 hilos involucradosestán concentrados en posiciones diferentes. Sinembargo para la matriz psmigr 1 (Figura 6(a)), quepresenta un patrón más distribuido, se observa unreparto más uniforme entre los hilos, aunque existeuna ligera componente en banda como se aprecia enun auge de accesos en esa zona para cada hilo.JP2011-659

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Matriz bcsstk18(a) Matriz psmigr 1(b) Hilo 1 (c) Hilo 2(b) Hilo 1 (c) Hilo 2(d) Hilo 3 (e) Hilo 4Fig. 5. Fallos caché por dirección, el eje x representa el rangode memoria de V . Reparto de la matriz bcsstk18.(d) Hilo 3 (e) Hilo 4Fig. 6. Fallos caché por dirección, el eje x representa el rangode memoria de V . Reparto de la matriz psmigr 1.VI. ConclusionesLas herramientas desarrolladas facilitan la obtencióny estudio de datos ofrecidos por los contadoresEAR de los procesadores Itanium 2. Con lainformación ofrecida por los EAR se pueden caracterizarlos accesos a memoria durante la ejecución deun programa paralelo. El uso de las herramientasdesarrolladas exige un cierto grado de familiaridadcon el estudio de los contadores PMU para su uso,pero facilita la inserción de código, y ya que estecódigo es completamente modificable por el usuariose puede adaptar a un buen número de sistemas, arquitecturaso problemas. La herramienta de muestrade datos simplifica el estudio estadístico de los eventoscapturados, al ofrecer las funcionalidades más importantesrelativas al tratamiento de la informaciónobtenida por los contadores. Mediante el estudio delSpMxV, se ha comprobado que los datos obtenidosmediante el uso de los EAR sirven para modelar laejecución de un programa paralelo gracias al estudiode sus accesos a memoria. Esta información esvaliosa para que el programador pueda mejorar elrendimiento de sus aplicaciones.AgradecimientosEste trabajo ha sido parcialmente financiado por elproyecto del MEC TIN 2010-17541, y por los proyectosde la Xunta de Galicia 2010/28 y 09TIC002CT.Así mismo, los autores agradecen el soporte ofrecidopor el CESGA.Referencias[1] The OpenMP API specification for parallel programming,http://openmp.org.[2] download.intel.com/design/Itanium2/manuals/30806501.pdf,Dual-Core Update to the Intel Itanium 2 Processor ReferenceManual.[3] J. C. Pichel, D. B. Heras, J. C. Cabaleiro, and F. F.Rivera, “Increasing data reuse of sparse algebra codeson simultaneous multithreading architectures,” Concurrencyand Computation: Practice and Experience, vol.21, no. 15, pp. 1838–1856, 2009.[4] J. C. Pichel, D. E. Singh, and J. Carretero, “Reorderingalgorithms for increasing locality on multicore processors,”in Proc. of the IEEE Int. Conf. on High PerformanceComputing and Communications, 2008, pp. 123–130.[5] Galicia Supercomputing Center, http://www.cesga.es.[6] HP Integrity rx7640 Server Quick Specs, http://h18000.www1.hp.com/products/quickspecs/12470div/12470 div.pdf.[7] Perfmon2 monitoring interface, http://perfmon2.sourceforge.net.[8] Sameer S. Shende and Allen D. Malony, “The Tau parallelperformance system,” International Journal of HighPerformance Computing Applications, vol. 20, no. 2, pp.287–311, Summer 2006.[9] W. E. Nagel, A. Arnold, M. Weber, H.-Ch. Hoppe, andK. Solchenbach, “VAMPIR: Visualization and analysis ofmpi resources,” Supercomputer, vol. 12, pp. 69–80, 1996.[10] Jesus Labarta, Sergi Girona, Vincent Pillet, Toni Cortes,and Luis Gregoris, “Dip: A parallel program developmentenvironment,” in Euro-Par’96 Parallel Processing,Luc Bougé, Pierre Fraigniaud, Anne Mignotte, and YvesRobert, Eds., vol. 1124 of Lecture Notes in ComputerScience, pp. 665–674. Springer Berlin / Heidelberg, 1996,10.1007/BFb0024763.[11] Performance Application Programming Interface(PAPI), http://icl.cs.utk.edu/papi/.[12] Matrix Market, http://math.nist.gov/MatrixMarket/.JP2011-660

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Evaluación del Benchmark Rodinia en lossistemas del SAIILuis Cerrudo, Antonio J. Dorta, Juan J. Fumero, Carlos González, Lucas Grillo,Iván López, Francisco de Sande 1Resumen— Cada vez es más frecuente el concurso deaceleradores hardware en sistemas de computación dealtas prestaciones de coste medio/bajo. Para algunosproblemas el incremento de prestaciones en estetipo de sistemas heterogéneos resulta espectacular.Utilizando como base el benchmark Rodinia, eneste trabajo realizamos una amplia experienciacomputacional utilizando los sistemas de cómputo dealto rendimiento disponibles en el Servicio de ApoyoInformático a la Investigación de la ULL.Palabras clave— Rendimiento, Evaluación, Rodinia,CUDA, OpenMP, Sistemas heterogéneos, multi-coreI. IntroducciónLa Computación de Altas Prestaciones (CAP) seencuentra en la actualidad inmersa en un rápidoproceso de cambio. El rango de arquitecturasdisponibles para altas prestaciones se ha ampliadoconsiderablemente con la irrupción en escena delos aceleradores hardware. Aunque las GPUsson capaces hoy en día de alcanzar muy altosrendimientos y la computación de propósito generalsobre GPUs (GPGPU) está siendo estudiada deforma muy activa en la actualidad, el desarrollo deaplicaciones para GPGPU sigue resultando una laboraltamente especializada, debido fundamentalmentea la carencia de herramientas adecuadas paraprogramar este tipo de arquitecturas heterogéneas.OpenCL [1] es un nuevo estándar que representaun esfuerzo para crear una interfaz común deprogramación para dispositivos heterogéneos. En elmomento de escribir este trabajo, el estándar aúnno ha sido ampliamente adoptado por fabricantes nidesarrolladores.CUDA [2] es una alternativa más madura yextendida, aunque solamente soporta dispositivosde NVIDIA. CUDA permite a los desarrolladoresde aplicaciones para CAP reimplementar suscódigos utilizando GPUs. A pesar de la relativasimplicidad del desarrollo de aplicaciones CUDA,es difícil alcanzar el máximo rendimiento de laarquitectura debido a los grandes esfuerzos encodificación, depuración y optimización necesariosen este entorno.También Intel ha introducido su propio lenguajedestinado a programar aceleradores hardware, ArBB[3]. El lenguaje permite rápidos desarrollos SIMDy la reescritura de códigos preexistentes no resultacompleja.En el grupo de Computación de Altas Prestacionesde la ULL estamos desarrollando yacf [?], un entorno1 Servicio de Apoyo Informático a la Investigación (SAII)Universidad de La Laguna, 38271–La Laguna, Spain e-mail:{saii}@ull.esde compilación fuente a fuente para el lenguaje llc[4], un lenguaje paralelo de alto nivel en el que elparalelismo se expresa mediante directivas similaresa las de OpenMP. Recientemente hemos desarrolladoun backend para CUDA [5] en nuestro compilador yestamos trabajando en el desarrollo de un backendpara OpenCL.Ante esta intensa actividad investigadora enla computación de altas prestaciones medianteutilización de aceleradores gráficos surgen preguntascomo: ¿qué problemas se pueden resolver de formaeficiente y alcanzando altas prestaciones con este tipode sistemas heterogéneos? ¿cómo han de optimizarsetanto las CPUs como los aceleradores gráficos paracolaborar de forma óptima? ¿Qué características sonnecesarias tanto en la arquitectura hardware comoen el modelo de programación de estos sistemas?En un intento de contribuir a clarificar estascuestiones, el grupo del profesor Skadron de launiversidad de Virginia ha propuesto el BenchmarkRodinia [6]. En este trabajo presentamos el resultadode la evaluación de los sistemas del SAII utilizando elbenchmark Rodinia. Los objetivos que perseguimoscon esta experimentación son varios:• Caracterizar la infraestructura computacionaldisponibles en el SAII• Hacer disponible esta información a los usuariosactuales y potenciales de los sistemas del SAII• Incrementar nuestro conocimiento sobre lasaplicaciones que componen el benchmarkEl resto de este trabajo se organiza comosigue: la sección II presenta la suite Rodinia, conuna explicación de los códigos que componen elbenchmark. La sección III contiene una descripciónde los recursos computacionales usados, así comode la metodología que hemos seguido al realizarlos experimentos. Los resultados experimentalesobtenidos en nuestra evaluación se muestran en lasección IV. Finalmente en la seccion V presentamoslas conclusiones del trabajo.II. El benchmark RodiniaNo es difícil encontrar benchmarks orientados aevaluar las prestaciones de aplicaciones de CAP depropósito general sobre arquitecturas basadas enCPUs. Entre los más relevantes podemos mencionarSPEC CPU [7], EEMBC [8], SPLASH-2 [9], o Parsec[10]. El benchmark Parboil [11] representa unesfuerzo para evaluar aplicaciones sobre GPUs, perosu conjunto de tests así como su diversidad es másreducido que el de Rodinia.JP2011-661

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011En el ámbito de la evaluación de sistemasheterogéneos una característica esencial apartede la diversidad de tests es la disponibilidad deimplementaciones tanto para CPUs multi-núcleocomo para GPUs. Con estas condiciones, una delas pocas alternativas a Rodinia está representadapor el benchmark SHOC [12] que se centra en testsprogramados en OpenCL. En este trabajo hemosoptado por utilizar Rodinia debido a que fue elprimer benchmark de estas características en estardisponible y también porque el rendimiento sobreGPUs de NVIDIA es superior utilizando CUDA queOpenCL [13], pero no descartamos utilizar otrasalternativas en el futuro.La selección de los tests individuales quecomponen el benchmark Rodinia ha estado guiadapor la taxonomía introducida en [14], en laque el espectro de aplicaciones susceptibles deprecisar CAP se caracteriza atendiendo a 13diferentes modelos (dwarfs), cada uno de los cualesrepresenta un determinado patrón de cómputoy comunicaciones común a toda una clase deaplicaciones relevantes. De este modo se persigueque estos 13 modelos estén representados en elbenchmark. Aparte de la diversidad de modelos,también se ha buscado que los tests correspondana diversos dominios de aplicación: bioinformática,minería de datos, simulaciones físicas, proceso deimágenes, reconocimiento de patrones, etc.Describimos brevemente a continuación cada unode los tests de Rodinia que hemos utilizado ennuestros experimentos. Información adicional sobrecada uno de ellos se puede encontrar en los propiostrabajos del grupo del profesor Skadron [6].Back Propagation (BP): Es un algoritmo deentrenamiento para redes neuronales. La aplicaciónque se incorpora en el Benchmark se compone dedos etapas: la primera de ellas, Forward Phase,en la que los valores a la entrada se propaganhacia adelante para calcular la salida y la segunda,Bacward Phase, en el que se calcula el error entre lasalida de la red y la que debería haberse obtenido,propagándose hacia atrás.Breadth-First Search (BFS): Es un algoritmo pararecorrer o buscar elementos en un grafo, aunquefrecuentemente se usa sobre árboles. Se comienzaen la raíz (eligiendo algún nodo como elemento raízen el caso de un grafo) y se exploran todos losvecinos de este nodo. A continuación para cada unode los vecinos se exploran sus respectivos vecinosadyacentes, y así hasta que se recorra todo el árbol.CFD: Es un algoritmo del ámbito de la mecánicade fluidos computacional. Resuelve las ecuaciones deEuler en tres dimensiones para fluidos compresiblesen volúmenes finitos.Heartwall (HW): Es una aplicación que detectacambios de forma de las paredes del corazón de unratón. Recibe como entrada un vídeo de ultrasonidosdel corazón de dicho animal y realiza múltiplesoperaciones (detección de bordes, transformacionesmorfológicas, filtro SRAD) para detectar la paredinterna y externa del corazón. Una vez detectados,el programa sigue los cambios de las paredes en lossucesivos frames del vídeo.Hotspot (HS): Algoritmo que estima latemperatura en cada zona de un procesadorbasándose en su arquitectura y en medidas depotencia. La entrada del programa son lastemperaturas y potencias iniciales y la salida es latemperatura media de cada zona del procesador.K-means (KM): Es uno de los algoritmos nosupervisados más simples para resolver el conocidoproblema del clustering. El objetivo es clasificar uncierto número de observaciones en un conjunto declusters de modo que cada observación pertenezcaal cluster que tenga la media más cercana. Cada vezque se añade un dato a un cluster se recalculan suspropiedades y se sigue iterando hasta converger.Leukocyte (LC): Aplicación médica cuyo objetivoconsiste en detectar y seguir la trayectoria de losleucocitos (glóbulos blancos) en un vídeo de los vasossanguíneos grabado a través de un microscopio. Enla aplicación, las células se detectan en los primerosfotogramas del vídeo y se siguen a través de losfotogramas posteriores.Descomposición LU (LUD): La descomposición LUes un algoritmo para calcular las soluciones deun conjunto de ecuaciones lineales. El núcleo delalgoritmo descompone una matriz como productode una matriz triangular inferior por una matriztriangular superior.Needleman-Wunsch (NW): Se trata de un métodode optimización para el alineamiento de unasecuencia de ADN. Dicho alineamiento consiste enorganizar las secuencias de ADN de modo que laspartes más similares estén enfrentadas entre sí. Elalgoritmo NW es un método global (se intenta alinearla secuencia completa) basado en programacióndinámica. Se utiliza una matriz de sustituciónpara asignar puntuaciones según las coincidenciaso diferencias entre los aminoácidos. Usando dichamatriz el algoritmo calcula el alineamiento óptimo.Particlefilter (PF): El filtro de partículas es unestimador estadístico de la posición de un objeto quese obtiene a partir de medidas de esta posición quecontienen ruido, así como de la trayectoria del objetoen un entorno bayesiano. El PF tiene multitud deaplicaciones prácticas: seguimiento de vehículos enun vídeo o compresión de vídeo son algunas de ellas.La implementación específica que se incluye en elbenchmark está optimizada para el seguimiento decélulas; específicamente leucocitos y células del tejidomiocardial.SRAD: Es un algoritmo que usando ecuaciones enderivadas parciales trata de eliminar las manchas deuna imagen tratando de preservar las característicasimportantes de la imagen. SRAD es ampliamenteutilizado en ultrasonidos y aplicaciones de imágenesde radar.Streamcluster (SC): Para un conjunto de puntosde entrada, el algoritmo genera un númeropredeterminado de grupos que cumplen que laJP2011-662

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011distancia de cada punto a su centroide es la menor.Se trata de hacer particiones que minimicen laheterogeneidad de los datos de los que se componecada una de las particiones.En la versión original ya aparecen los tests LC,SRAD, HS, BP, NW, KM, SC, y BFS, mientras que LU, HW,CFD, y PF fueron añadidos con posterioridad [15].III. El entorno computacionalLa Tabla I sintetiza las características de los4 sistemas en los que se han llevado a cabo losexperimentos. tarja es un servidor Bull NovaScale4040, tajinaste es un cluster que consta de7 nodos de cómputo, cada uno de ellos con 2microprocesadores de doble núcleo, lo que haceun total de 4 núcleos por nodo, y un total de 28procesadores de cómputo. Para los experimentosen OpenMP se ha usado un único nodo detajinaste. bejeque es un sistema de memoriacompartida con un total de 32 cores. Por últimogaroe es una estación de trabajo con 4 cores y8 threads de ejecución a la que están conectadaslas dos tarjetas gráficas cuyas características másrelevantes se muestran en la Tabla II. Las dos GPUscorresponden a la generación actual (Fermi) y laanterior de la línea profesional (Tesla) de NVIDIA.Para las ejecuciones en OpenMP se hanutilizado dos máquinas con procesadores Intelde 2 arquitecturas diferentes y otras dos conprocesadores AMD. Todas las ejecuciones CUDA sehan realizado en la estación garoe usando solamenteuna de las dos GPUs en cada ejecución.Característica Tesla C2050 Tesla C1060Chip T20 T10Número de núcleos 448 240Frecuencia del núcleo 1,15 GHz 1,30 GHzMemoria 3 GB 4 GBFrecuencia de la memoria 1,5 GHz 0,8 GHzTasa de transferencia 144 GB/s 102 GB/sGFLOPs (simple) 1030 GFlop/s 933 GFlop/sGFLOPs (doble) 515 GFlop/s 78 GFlop/sConsumo 247 W 187 WTABLA IIGPUs utilizadas en los experimentosEn cuanto a los compiladores, se han utilizado lasúltimas versiones (4.3.5 y 11.0 respectivamente) delos compiladores gcc e icc en el caso de las versionessecuenciales y OpenMP de los códigos, mientras quepara la versión CUDA hemos utilizado la versión 4.0,V0.2.1221 del compilador nvcc de NVIDIA.Para los resultados que se presentan en estetrabajo, todos los tests han sido compilados deforma uniforme utilizando las siguientes opciones decompilación:• -O3 para las versiones secuenciales de los códigos• -O3 (-fopenmp | -openmp) para las versionesOpenMP• -O3 para la versión CUDAHemos realizado experimentos adicionales probandodiferentes opciones de compilación específicas decada arquitectura, que no se presentan en estetrabajo por razones de espacio.En cuanto a los tamaños de entrada para cadauno de los tests del benchmark, por razones decompatibilidad de nuestros resultados con losobtenidos por los autores de Rodinia, hemosrespetado los tamaños de entrada que figuran enel benchmark tal como se descarga de la web deRodinia [16].IV. Resultados ExperimentalesPor razones de espacio es imposible reflejaral completo en este trabajo los resultados de laexperiencia computacional que se ha realizado. Asípues, intentaremos mostrar aquellos resultados quepuedan parecer más relevantes y que permitan sacarconclusiones sobre los experimentos.El primer tipo de experimentos que se realizaró fuela ejecución de la versión OpenMP de todos los testsdel benchmark. La Figura 1 muestra la aceleraciónde los tests BFS, NW, SRAD y HS compilados con gcc enbejeque. Observamos ya que nos encontramos contres patrones de comportamiento: aplicaciones comoSRAD que presentan una buena escalabilidad para elnúmero de cores seleccionado, otras como BFS que noescalan en absoluto y un tercer grupo, representadoen esta gráfica por NW y HS cuya escalabilidad eslimitada. Resultados muy similares se observaroncuando el compilador utilizado fue icc en lugar degcc.La Figura 2 compara las aceleraciones obtenidasen tarja y tajinaste con 4 núcleos. Podemosconcluir que las paralelizaciones en OpenMP detodos los códigos siempre resultan beneficiosas,logrando aceleraciones que en promedio podemosestimar de un factor 1.5 para la mayoría de los tests,y alcanzando valores superiores a 3.5 para los testsmás favorables.La figura 3 muestra la aceleración obtenida concada una de las GPUs disponibles con respecto a laversión OpenMP compilada con gcc con 32 threadsejecutada en bejeque. La mejora del rendimientoal utilizar los aceleradores hardware es para algunoscasos de un factor de 10, mientras que para otroscasos, la mejora no es tan importante. Para lamayoría de los tests, las versiones CUDA de loscódigos mejoran claramente el rendimiento. Losresultados para el compilador icc siguen un patrónsimilar, pero en este caso, el factor de mejora de lostests más beneficiados por el concurso de las GPUsllega a alcanzar un factor de 60.La Figura 4 muestra para cada uno de lostests del benchmark y para cada una de las dosGPUs disponibles el porcentaje del tiempo total deejecución que se emplea en cómputo en la CPU,Entrada/Salida, transferencias de memoria entreHost y dispositivo así como el tiempo de ejecucióndel kernel CUDA.En la Figura queda patente a primera vista ladiversidad de los diferentes tests. Algunos sonJP2011-663

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tarja tajinaste bejeque garoeNúmero de procesadores 4 2 8 1Núcleos por procesador 2 4 4Procesadores Intel Itanium 2 AMD OpteronProcessor 275AMD OpteronProcessor 6128Frecuencia 1.5GHz 2.2 GHz 2 GHz 2.8 GHzCaché L1 32 KB 64KB 512 KB 128 KBCaché L2 256 KB 1024MB 4096 MB 1024 MBMemoria RAM 16 GB 4 GB 129 GB 4 GBTABLA ISistemas utilizados en los experimentosIntel Core i7CPU 930Fig. 1Aceleración para 4 de los tests en su versión OpenMP compilados con gccintensivos en E/S como HS y otros en tiempo decómputo en la GPU como LC. Esta diversidad encajacon el propósito de los autores de Rodinia a lahora de elegir los tests del benchmark de modoque fueran representativos de una gran variedad decampos de aplicación. Sea cual sea la optimizaciónque se pretenda evaluar, habrá un test en el que,presumiblemente, ésta tendrá una gran incidencia.Por ejemplo, en caso de mejorarse las transferenciasde memoria entre el host y la tarjeta gráfica es deesperar una mejora importante del rendimiento deltest HW. Sin embargo, la misma mejora apenas tendráincidencia en el test LUD, por ejemplo. También seobserva que el rendimiento de la nueva placa Fermies mejor que el de su antecesora en la mayoría delos tests. El porcentaje de tiempo de cómputo en laGPU se reduce en el caso de la Fermi excepto en unúnico test (SC). Sin embargo, la mejora en algunoscasos, como SRAD, PB o PF, es significativa.V. Conclusiones• Sería conveniente asegurar la posibilidad derepetición de resultados con una arquitecturaconcreta utilizando Rodinia. Para ello es precisoal menos unificar criterios en cuanto al modo enque se realiza la toma de tiempos a la hora deejecutar un determinado test del benchmark.• Conectar una tarjeta gráfica a cualquier pequeñomulticomputador es una forma muy asequiblede mejorar de forma sensible el rendimiento deciertas aplicaciones paralelas. Antes de invertiresfuerzo y dinero en esta vía, es convenientecaracterizar la aplicación que pretendemosacelerar, puesto que no todas las aplicacionesson susceptibles para mejorar rendimiento eneste tipo de sistemas heterogéneos.• Un aspecto nada desdeñable a la hora detrabajar con este tipo de sistemas heterogéneoses su falta de programabilidad. Si desarrollarutilizando MPI u OpenMP pueden suponer unesfuerzo para usuarios no expertos en CAP,las dificultades se incrementan a la hora dedesarrollar, depurar y sintonizar aplicacionesprogramadas tanto en CUDA como en OpenCL.AgradecimientosEste trabajo ha sido parcialmente subvencionadopor el la Comisión Europea a través de los fondosJP2011-664

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 2Comparativa de aceleraciones de las versiones OpenMP de cada test en tarja y tajinasteFig. 3Aceleración de las versiones CUDA en cada una de las GPUs con respecto a la versión OpenMP con 32 núcleosen bejequeJP2011-665

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Fig. 4Caracterización del tiempo de ejecución de la versión CUDA de cada test en la Tesla C1060 (izquierda) y TeslaC2050 (derecha).FEDER y del Plan Nacional de I+D+I del MEC,(TIN2008-06570-C04-03).Referencias[1] Khronos Group, “OpenCL the open standard for parallelprogramming of heterogeneous systems,” 2008.[2] John Nickolls, Ian Buck, Michael Garland, and KevinSkadron, “Scalable parallel programming with CUDA,”Queue, vol. 6, no. 2, pp. 40–53, 2008.[3] Intel, “Sophisticated library for vector parallelism: Intelarray building blocks,” 2010.[4] A. J. Dorta, P. López, and F. de Sande, “Basic skeletonsin llc,” Parallel Computing, vol. 32, no. 7–8, pp. 491–506, sep 2006.[5] Ruymán Reyes and F. de Sande, “Automaticcode generation for gpus in llc,” The Journal ofSupercomputing, 2011.[6] Shuai Che, Michael Boyer, Jiayuan Meng, DavidTarjan, Jeremy W. Sheaffer, Sang-ha Lee, and KevinSkadron, “Rodinia: A benchmark suite for heterogeneouscomputing,” in IEEE International Symposium onWorkload Characterization, Oct. 2009.[7] The Standard Performance Evaluation Corporation(SPEC), “SPEC Home Page,” 2011,http://www.spec.org.[8] Embedded Microprocessor Benchmark Consortium,“EEMBC Home Page,” 2011, http://www.eembc.org/.[9] Steven Cameron Woo, Moriyoshi Ohara, Evan Torrie,Jaswinder Pal Singh, and Anoop Gupta, “The SPLASH-2 programs: characterization and methodologicalconsiderations,” SIGARCH Comput. Archit. News, vol.23, pp. 24–36, May 1995.[10] Christian Bienia, Sanjeev Kumar, Jaswinder Pal Singh,and Kai Li, “The PARSEC benchmark suite:characterization and architectural implications,” inProceedings of the 17th international conference onParallel architectures and compilation techniques, NewYork, NY, USA, 2008, PACT ’08, pp. 72–81, ACM.[11] “The Parboil benchmark suite Home Page,” 2011,http://impact.crhc.illinois.edu/parboil.php.[12] Anthony Danalis, Gabriel Marin, Collin McCurdy,Jeremy S. Meredith, Philip C. Roth, Kyle Spafford,Vinod Tipparaju, and Jeffrey S. Vetter, “The scalableheterogeneous computing (shoc) benchmark suite,” inArchitectural Support for Programming Languages andOperating Systems, 2010, pp. 63–74.[13] Kazuhiko Komatsu, Katsuto Sato, Yusuke Arai, KentaroKoyama, Hiroyuki Takizawa, and Hiroaki Kobayashi,“Evaluating performance and portability of openclprograms,” in The Fifth International Workshop onAutomatic Performance Tuning, June 2010.[14] Krste Asanovic, Ras Bodik, Bryan ChristopherCatanzaro, Joseph James Gebis, Parry Husbands,Kurt Keutzer, David A. Patterson, William LesterPlishker, John Shalf, Samuel Webb Williams, andKatherine A. Yelick, “The landscape of parallelcomputing research: A view from Berkeley,” Tech. Rep.UCB/EECS-2006-183, EECS Department, University ofCalifornia, Berkeley, Dec 2006.[15] Shuai Che, Jeremy W. Sheaffer, Michael Boyer,Lukasz G. Szafaryn, Liang Wang, and Kevin Skadron,“A characterization of the rodinia benchmark suitewith comparison to contemporary cmp workloads,” inProceedings of the IEEE International Symposium onWorkload Characterization (IISWC’10), Washington,DC, USA, 2010, IISWC ’10, pp. 1–11, IEEE ComputerSociety.[16] “The Rodinia benchmark suite Home Page,” 2011,http://lava.cs.virginia.edu/Rodinia/.JP2011-666

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Computación de altas prestaciones sobre arquitecturasparalelas heterogéneasJP2011-667

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-668

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Algoritmos eficientes para la transformadawavelet discreta en multicores y GPUsV. Galiano, O. López, M.P. Malumbres y H. Migallón 1Resumen— En este trabajo se analiza el comportamientodel rendimiento para un conjunto de algoritmosutilizados en el cálculo de la transformada waveletdiscreta 2D (2D-DWT) utilizando tanto OpenMP sobreplataformas de memoria compartida o multinúcleo,como CUDA (Compute Unified Device Architecture)sobre GPUs (Graphics Processing Unit). Losalgoritmos propuestos se basan en el uso de filtros deconvolución y en la transformada lifting. Además, secompara el rendimiento obtenido por nuestros algoritmosfrente al reciente algoritmo SMDWT (SymmetricMask-based Wavelet Transform) en plataformasde memoria compartida; y frente a algoritmos basadosen las propuestas de la SDK de CUDA cuando seusa una GPU como plataforma de computación.Palabras clave— CUDA, OpenMP, transformadawavelet, codificación de imagen, algoritmos paralelosIntroducciónDurante la última década, se ha profundizadoen diferentes algoritmos de compresión de imágenespara evitar las conocidas limitaciones de los algoritmosbasados en bloques tales como la DCT [1](transformada discreta del coseno), siendo ésta latécnica de compresión más utilizada hasta el momento.Algunas de las alternativas propuestas estánbasadas en técnicas más complejas como la codificaciónfractal o la cuantización vectorial, mientrasotras simplemente proponen el uso de una transformadamatemática diferente y más flexible. La transformadaDWT (transformada discreta wavelet) se haconsolidado como una herramienta muy potente parala compresión de imágenes y un gran número de codificadoresde imágenes actuales, incluyendo el estándarJPEG2000, utilizan esta transformada en susalgoritmos (ver por ejemplo [2], [3]).Sin embargo, a pesar de los beneficios implícitosdel uso de la transformada wavelet, se presentannuevos problemas relacionados tanto con el incrementode la complejidad, como con el acceso intensivoa memoria, lo que conlleva un incremento enlos tiempos de ejecución. De hecho, en la implementaciónclásica de la transformada DWT [4], ladescomposición de la imagen se realiza mediante unfiltrado convolucional, cuya complejidad aumenta enfunción de la longitud del filtro utilizado. Además,en el cálculo de la transformada DWT, para cadanivel de descomposición se realizan dos pasadas a laimagen, una por filas y otra por columnas, por lo quees necesario almacenar toda la imagen en memoria.Por otra parte, en la transformada DCT, al realizarsepor bloques, el requisito de memoria no es unproblema incluso para imágenes de gran tamaño.1 Dpto. Física y Arquitectura de Computadores,Univ. Miguel Hernández, e-mail:{vgaliano,otoniel,mels,hmigallon}@umh.esEl esquema lifting [5], [6] es, probablemente, elalgoritmo más estudiado para realizar un cálculo eficientede la transformada wavelet. Dicho algoritmoutiliza menos coeficientes en los filtros, proporcionandouna implementación más rápida de la transformada.Además, este esquema reduce la memorianecesaria, ya que los coeficientes wavelet calculadosson almacenados en la matriz de datos original, evitandode esta manera la necesidad de otra matrizpara almacenar dichos coeficientes wavelet. Hay quetener en cuenta que los coeficientes wavelet calculadosdeben almacenarse en posiciones separadas dentrode la matriz de datos, las bajas frecuencias por unlado y las altas por otro, este reordenamiento de coeficientesproduce conflictos en el uso de la memoriacaché. Por otra parte, se han propuesto otros algoritmospara el cálculo de la transformada waveletcon el fin de reducir los requisitos de memoria, comopor ejemplo los algoritmos basados en bloques [7] olos basados en línea [8]. Estas propuestas aumentanla flexibilidad del algoritmo para imágenes de grantamaño y reducen los requisitos de memoria. Recientemente,en [9], los autores presentan un nuevométodo denominado Symmetric Mask-based DiscreteWavelet Transform (SMDWT). Este algoritmo realizael cálculo de la transformada como si se tratasede una convolución matricial, de manera que utilizacuatro matrices, una para cada subbanda (LL, HL,LH y HH), con la intención de reducir los cálculosrepetitivos necesarios en el algoritmo tradicional. Eneste esquema, la transformada 2D-DWT se realiza enuna sola pasada. Además, este algoritmo permite elcálculo independiente de una única subbanda.En el diseño de codificadores de imagen y vídeobasados en la transformada wavelet, una de las tareascomputacionalmente más costosa es la transformadawavelet puesto que suele emplear entre el 30%y el 50% del tiempo total de codificación (dependiendodel tamaño de la imagen y del número deniveles de decomposición wavelet). Por lo tanto, esvital reducir el tiempo de cálculo de la transformada2D-DWT desarrollando codificadores eficientes queaprovechen recursos computacionales disponibles encada computador. En este sentido, la mayor parte decomputadores actuales incluyen procesadores multinúcleode manera que un algoritmo eficiente debepoder aprovechar la capacidad de cálculo en paraleloutilizando simultáneamente varios o todos los núcleosde dichos procesadores. Por otro lado, las GPUs seencuentran cada vez más presentes en los equiposde consumo, por lo que también deben considerarsepara aprovecharlas como plataformas de cómputo.En este artículo, realizaremos unas optimizacionesJP2011-669

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011para el cálculo en paralelo sobre los métodos descritosen [4] y [5]. Nuestro principal objetivo esla optimización del uso de la memoria y la mejoradel rendimiento mediante la utilización de arquitecturasmultinúcleo, es decir utilizando plataformas dememoria compartida. Además, se diseñarán para suejecución en GPUs mediante CUDA, los mismos algoritmosdesarrollados para arquitecturas multinúcleo.Hay que remarcar que los algoritmos desarrolladospara GPUs requieren de un uso eficiente dela memoria, en particular los algoritmos diseñadosse basan en el uso de la memoria compartida de laGPU. Además, se presentarán nuevos métodos basadosen las propuestas incluidas en [10], comparándolostanto a nivel de rendimiento como a nivel derequisitos de memoria.I. Transformada Discreta Wavelet (DWT)La transformada DWT obtiene un esquema dedescomposición multirresolución para señales de entrada.La señal original se transforma inicialmenteen dos subbandas de frecuencia (bajas y altas frecuencias).En la transformada clásica, la descomposiciónse realiza mediante un filtro digital pasobajo H y un filtro digital paso alto G. Ambos filtrosse diseñan utilizando la función de escalado Φ(t) ylos correspondientes coeficientes wavelet Ψ(t). El algoritmoreduce el nivel de muestras de la señal a lamitad. En filtros FIR no recursivos y con longitudL, la función de transferencia de H y G se puederepresentar del siguiente modo:H(z) = h 0 + h 1 z −1 + h 2 z −2 + h 3 z −3 (1)G(z) = g 0 + g 1 z −1 + g 2 z −2 + g 3 z −3 (2)A. Transformada Wavelet Lifting (LDWT)Uno de los inconvenientes de la DWT es el incrementode los requisitos de memoria debido a su algoritmobasado en la convolución de filtros. Una propuestaque reduce el tamaño de memoria necesariaen el cálculo de la transformada es el esquema lifting[5]. El principal beneficio en este esquema es lareducción del número de operaciones necesarias pararealizar la transformada wavelet, comparándolo conel algoritmo convolucional clásico. El orden de reducciónen el esquema lifting depende del tipo detransformada wavelet a realizar, tal y como se indicaen [11].En el esquema clásico, el procesado in-situ de losdatos no es posible ya que cada muestra original senecesita para el cálculo de los coeficientes en sus vecinos.Por lo tanto, se necesita una nueva matriz paraalmacenar los coeficientes resultantes, duplicando, deesta manera, los requisitos de memoria. No obstante,en el esquema lifting se implementa una computaciónin-situ sin necesidad de memoria adicional alguna.Además, el esquema lifting se puede ejecutar sobreun número impar de muestras mientras que en elalgoritmo clásico se necesita de un número par demuestras.Usaremos el algoritmo euclídeo para factorizar lamatriz en varias fases mediante una secuencia alternativade matrices triangulares superiores e inferiores.En (3), las variables h(z) y g(z) representan lainversa de los filtros paso bajo y paso alto respectivamente.Dichos filtros se dividen en una parte impary otra par para generar una matriz P (z), como semuestra en (4).g (z) = g e(z2 ) + z −1 g o(z2 )h (z) = h e(z2 ) + z −1 g o(z2 ) (3)( )he (z) gP (z) =e (z)h o (z) g o (z)(4)Mediante el algoritmo euclídeo, de manera recursiva,encontraremos los máximos comunes divisoresde la parte par e impar de los filtros originales. Deeste modo, h(z) y g(z) forman un filtro complementarioque se puede factorizar en tres pasos tal y comose muestra a continuación,P (z) =m∏i=1(1 si (z)0 1) (1 0t i (z) 1) ( )k 0(5)0 1/kdonde s i (z) y t i (z) representan los polinomios deLaurent correspondientes a los pasos de predicción yactualización respectivamente, y k es una constantedistinta de cero.El proceso completo consiste en una primera transformaciónaproximada, uno o más pasos de prediccióny una posterior actualización y normalizaciónde los coeficientes. En la primera transformación,las muestras de entrada se dividen en dos conjuntosde datos, las muestras pares y las impares. Deeste modo, si consideramos {X i } = {Φ n,p } como lasmuestras de entrada en el nivel de descomposición n,definimos:{s0i}= {X2i }{d0i}= {X2i+1 }(6)Por tanto, en un paso de predicción, cada muestraen { }d 0 i se reemplaza por el error cometido en lapredicción { } de esa muestra con respecto a las muestrass0i :d 1 i = d 0 i − P ({ s 0 })i(7)mientras que en el paso de actualización, cada muestraen { s 0 i}se actualiza por{d1i}:s 1 i = s 0 i + U ({ d 1 })i(8)Después de m sucesivos pasos de actualización ypredicción, se obtienen los coeficientes de escaladoy wavelet del siguiente modo:{Φ n+1,p } = K 0 × {s m i }{Ψ n+1,p } = K 1 × {d m i }(9)Un caso especial de filtro wavelet es el filtroDaubechies 9/7. Este filtro se utiliza frecuentementeJP2011-670

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011en compresión de imagen (ver por ejemplo [3], [12]),y se ha incluido en el estándar JPEG2000 [2]. Eneste trabajo, todos los algoritmos desarrollados paracálculo de la transformada DWT utilizan este filtro.Los coeficientes de los filtros de descomposiciónDaubechies 9/7 h[n] y g[n] son:h [n] = 0.026749, −0.016864, −0.078223, 0.266864, 0.602949,0.266864, −0.078223, −0.016864, 0.026749g [n] = 0.091272, −0.057544, −0.591272, 1.115087,− 0.591272, −0.057544, 0.091272,mientras que la descomposición basada en lifting resulta:( ( ) ) ()1 α 1 + z−11 0P (z) =0 1 β (1 + z) 1( ( ) ) () ( )1 γ 1 + z−11 0 ζ 00 1 δ (1 + z) 1 0 1/ζ(10)donde α = −1.586134342, β = −0.052980118, γ =0.882911075, δ = 0.443506852 y ζ = 1.230174105.B. Symmetric Mask-based Wavelet Transform(SMDWT)En [9], los autores presentan una novedosa formade calcular la transformada wavelet tratando de reducirla complejidad computacional. La transformadaSMDWT se realiza mediante una convoluciónmatricial utilizando cuatro matrices derivadas del filtroDaubechies 9/7 con coeficientes en coma flotante.En el esquema lifting 2D LDWT se requiere de uncálculo en sentido vertical y otro en sentido horizontal,y para cada uno de estos cálculos se debenrealizar cuatro pasos: división, predicción, actualizacióny escalado. Por el contrario, las cuatro bandasen la transformada 2D SMDWT se pueden obtenerde forma independiente mediante cuatro matrices detamaños 7 × 7, 7 × 9, 9 × 7 y 9 × 9 en el caso del filtroDaubechies 9/7.II. Transformada Wavelet multinúcleoHemos utilizado la convolución basada en el filtroDaubechies 9/7 con el objetivo de desarrollar unacomputación de la transformada 2D-DWT propuestaen [4] de forma paralela y optimizada. Por otrolado, hemos utilizado el algoritmo lifting propuestopor Sweldens en [5], para optimizar la transformadalifting (2D-LWT).En los filtros basados en la convolución,necesitaremos un espacio de memoria adicionalpara almacenar la fila o columna de la actualconvolución, mientras que en la transformada liftingnecesitaremos un espacio de memoria adicionalpara almacenar una fila y una columna. Debemosdestacar que el algoritmo SMDWT requiere el dobledel tamaño de la imagen.Hemos utilizado OpenMP [13] como herramientade desarrollo de algoritmos paralelos en arquitecturasmultinúcleo. La plataforma multinúcleo utilizada esun Intel Core 2 Quad Q6600 2.4 GHz, con 4 núcleos,Tamaño Número Tamaño extra de memoriade imagen de núcleos Conv. Lifting1 520 1024512×512 2 1040 20484 2080 40961 2056 40962048×2048 2 4112 81924 8224 163841 4104 81924096×4096 2 8208 163844 16416 32768TABLA INúmero de píxeles en memoria necesarios utilizandofiltros de cuatro “taps”.denominado SULLI. Cada proceso calcula la transformadawavelet de un bloque de filas y de un bloquede columnas, hay que tener en cuenta que se creantantos procesos como núcleos hay disponibles. Portanto, cada proceso (o núcleo) requiere un extra dememoria para realizar la transformada, lógicamenteel tamaño total de memoria adicional necesaria aumentaal aumentar el número de núcleos utilizados.Debemos destacar que el resultado de los coeficienteswavelet se puede almacenar en el espacio de memoriaocupada por la imagen original, evitando, de estemodo, duplicar los requisitos de memoria. La Tabla Imuestra la memoria adicional en píxeles utilizada porcada uno de los algoritmos dependiendo del númerode núcleos utilizados. El peor caso se da para imágenespequeñas que, no obstante, requieren menosdel 2% de memoria adicional, siendo para el resto decasos inferior al 1%. Hay que remarcar que la memoriaadicional necesaria en el algoritmo SMDWT esel tamaño de la imagen. Los datos mostrados enla Tabla I ilustran una imagen con niveles de grisesrepresentados mediante coma flotante.El sistema operativo de SULLI es Ubuntu 9.04(Jaunty Jackalope) para sistemas de 64 bits. Hemosutilizado el compilador GNU gcc incluido en gcc4.3.3, las opciones de compilación utilizadas paraarquitecturas multinúcleo han sido “-O3 -m64 -fopenmp”. Para CUDA el compilador utilizado esnvcc incluido en el CUDA Toolkit 3.2 RC, siendo lasopciones de compilación utilizadas “-O3 -m64”.Hemos adaptado los algoritmos para obtener elmejor rendimiento en arquitecturas multinúcleo, teniendoen cuenta que estos algoritmos realizan unuso intensivo de memoria. En la figura 1 se muestranlos tiempos de cálculo necesarios para obtenerla transformada wavelet mediante convolución y liftingpara imágenes de diferentes tamaños: 512 × 512,2048 × 2048, y 4096 × 4096. No obstante, el cuellode botella en el acceso a memoria provoca pérdidasde eficiencia en el cálculo, ya que para imágenes pequeñasel cómputo asociado a cada fila y a cadacolumna es muy pequeño. Sin embargo, con imágenesgrandes se obtienen eficiencias casi ideales parael caso de 2 núcleos y muy buenas en el caso de 4 núcleos.Además, hemos comparado nuestros algoritmoscon la reciente propuesta para el cálculo de laJP2011-671

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(a) Convolución(a) 2 Núcleos(b) LiftingFig. 1. Tiempo de computación de los algoritmos convolucióny lifting para arquitecturas multinúcleo.(b) 4 NúcleosFig. 2. Comparación entre los algoritmos basados en laconvolución y en la transformada lifting y el algoritmoSMDWT.DWT, denominada “Symmetric Mask-based DWT”(SMDWT), introducida en [9] y que propone un enfoquenovedoso. Hemos desarrollado el método descritoen [9] y además, hemos paralelizado dicho algoritmo.En la figura 2 mostramos una comparaciónde los tiempos de cálculo para los algoritmos deconvolución, lifting y SMDWT utilizando 2 y 4 núcleos.Como se puede observar, nuestros algoritmos,tanto el basado en la convolución como el basado enla transformada lifting, presentan mejor rendimientoque el algoritmo SMDWT, obteniendo un factor demejora de hasta 2, 5. Hay que remarcar, que los autoresen [9] proponen el algoritmo SMDWT tantopara reducir la complejidad computacional como porla capacidad de dicho algoritmo para obtener deforma independiente cualquiera de las cuatro subbandas(LL, LH, HL o HH).Algunas aplicaciones requieren únicamente del cálculode la subbanda LL. En la figura 3 presentamosla misma comparación que en la figura 2 pero calculandoúnicamente la subbanda LL cuando se utilizael algoritmo SMDWT. Hay que remarcar que el comportamientode nuestros algoritmos computando lascuatro subbandas es similar al comportamiento delalgoritmo SMDWT computando únicamente la subbandaLL.III. Transformada Wavelet basada en GPUsEn las secciones anteriores hemos comprobadoque los algoritmos desarrollados para plataformas dememoria compartida que calculan la transformada2D DWT obtienen buenos rendimientos. A continuación,nos preguntamos en esta sección si se puedemejorar ese rendimiento con otro tipo de arquitectura,en particular con el uso de GPUs. Los procesadoresgráficos (GPU) están basados en un con-junto de unidades multinúcleo llamadas multiprocesadoresde streaming (SM) que contienen cada unade ellas un conjunto de procesadores de streaming(SP). CUDA es un modelo de computación heterogéneoque involucra tanto a la CPU como a la GPU.En la programación paralela con CUDA [14], [15],una aplicación consiste en un programa secuencial,ejecutado en el procesador host, que puede ejecutarprogramas, conocidos como kernels, en el dispositivoparalelo, es decir en la GPU. Además, el procesadorhost puede ser un sistema multinúcleo ejecutandocódigos paralelos, aunque en este caso únicamenteuno de los núcleos podrá realizar llamadas a los kernelde la GPU, o más específicamente las llamadas alos kernels deben serializarse. Un kernel es un programaSPMD (Single Program Multiple Data) quese ejecuta con un número elevado de hilos o threads.Cada hilo ejecuta el mismo programa secuencial. Elprogramador organiza los hilos en una malla de bloquesde hilos. Los hilos de un bloque determinadopueden colaborar entre ellos mediante mecanismosde sincronización y mediante los diferentes nivelesde memoria de los que dispone una GPU: la memoriaglobal, que es la de mayor latencia; la memoriaconstante de sólo lectura; la memoria de texturas;la memoria compartida; y los registros. La memoriacompartida es visible por todos los hilos de unbloque, mientras que los registros son propios de cadahilo. Hay que tener en cuenta que CUDA no proporcionamecanismos globales de sincronización.Con el objetivo de implementar el algoritmobasado en la convolución presentado en la sección IIsobre una GPU, debemos tener en cuenta que el elementoclave es la memoria compartida. Usaremosesta memoria compartida para almacenar la copiade datos de la fila o la columna con la que esténJP2011-672

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Ancho / (M+1) BloquesApronApronA Ap pr ro on nA Ap pr ro on nA Ap pr ro on nA Ap pr ro on nApronApronA Ap pr ro on nA Ap pr ro on nA Ap pr ro on nA Ap pr ro on nAlto Bloques(a) 2 NúcleosM cols44(a) Convolución por filasAncho BloquesApronApron(b) 4 NúcleosFig. 3. Comparación entre los algoritmos basados en la convolucióny en la transformada lifting y el cálculo de lasubbanda LL con el algoritmo SMDWTApronApronApronApronApronApronApronApronApronApronAlto/ (N+1) Bloques3trabajando los hilos de un bloque. Por otra parte,almacenaremos en la memoria constante los coeficientesh[n] y g[n] descritos anteriormente. En estealgoritmo cada kernel de CUDA es llamado con unnúmero de bloques, y con un número de hilos porbloque. El número de bloques debe ser igual o superiora la dimensión mayor de la imagen, que será obien el número de filas o bien el número de columnas.Cada bloque calcula una sola fila o columna,copiando dicha fila o columna en la memoria compartidade la GPU. El tamaño de la memoria compartidaen la NVIDIA GTX 280 es únicamente de16KB.Uno de los principales objetivos conseguidos medianteeste algoritmo propuesto ha sido minimizarlos requisitos de memoria, de este modo almacenaremoslos coeficientes wavelet resultantes en el espaciode memoria de la imagen. Por otro lado, losmétodos incluidos en la SDK de CUDA [10] utilizantres veces el tamaño de la imagen. Estos métodosrealizan la convolución en dos pasos: en el primerpaso calculan la convolución por filas y almacenanlos coeficientes obtenidos en la memoria global dela GPU; y en el segundo paso calculan y almacenanla convolución por columnas en otro espacio dela memoria global de la GPU. Se puede reducir losrequisitos de memoria en un tercio si los coeficienteswavelet obtenidos en el segundo paso son almacenadosen el espacio ocupado por la imagen original. Porotra parte, basándonos en la SDK de CUDA hemosdesarrollado dos métodos de la implementación descritacomo convolución clásica (véase [10], [16]), elprimero de ellos, utilizando la memoria global de laGPU (CUDA-Mem 9/7 ), y el segundo, utilizando lamemoria de tipo textura (CUDA-Text 9/7 ).Tal y como se propone en [10], el comportamientoN rows(b) Convolución por columnasFig. 4. Distribución por bloques en la memoria compartidade la GPUen estos métodos se puede mejorar considerablementeoptimizando el acceso a memoria para evitarlos conflictos (memory coalescence). Para poderoptimizar el acceso a memoria, los filtros de la convolucióndeben ser separables en dos pasos, es decir,una convolución por filas y otra por columnas,por tanto la convolución SMDWT descrita en la secciónI-B no podría optimizarse con este sistema. Elfiltro Daubechies 9/7 se divide en una convoluciónpor filas y una posterior convolución por columnas,por tanto es un filtro separable. Hemos implementadouna convolución (CUDA-Sep 9/7 ) que mejora elrendimiento mediante a) la reducción de las lecturasde un mismo píxel, b) acceso coalescente a memoria,c) alto rendimiento de la memoria compartida, y d)la reducción del número de hilos en espera.Esta convolución separable se realiza en dos pasos,uno por filas y otro por columnas. Cada pasose compone de dos etapas, una carga inicial de losdatos desde la memoria global de la GPU a la memoriacompartida del bloque, y una etapa posterior enla cual cada hilo calcula y almacena los resultadosobtenidos en la memoria global. En la etapa inicialde carga de datos se almacenan en la memoria compartidalos píxeles asignados a cada bloque, M enconvolución por filas y N en columnas, además sonnecesarios un determinado número de píxeles contiguosal bloque considerado, el número de píxelescontiguos necesarios viene dado por (filtersize −3JP2011-673

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Tiempo (s.)Fig. 5.0,0300,0250,0200,0150,0100,0050,000512 x 512 2048 x 2048 4096 x 4096CUDA-Conv 9/7 0,0008 0,0068CUDA-Mem 9/7 0,0011 0,0063 0,0240CUDA-Text 9/7 0,0016 0,0077 0,0269CUDA-Sep 9/7 0,0005 0,0026 0,0088Tiempos de ejecución sobre GPUs con CUDA1)/2, en particular para el filtro Daubechies 9/7 sonnecesarios 4 píxeles contiguos en cada extremo paralas filas y 3 píxeles para las columnas. En la figura 4,estos bloques contiguos y pertenecientes a otros bloquesse han representado en gris y señalizados como“Apron”.En la etapa de cálculo, tal y como se puedever en la figura 4, cada hilo lee los datos desde lamemoria compartida y los almacena en su correspondienteposición de la imagen final. De este modo,hilos consecutivos acceden a posiciones de memoriaconsecutivas por lo que no existen conflictos en el accesoa la memoria compartida (una descripción másdetallada puede verse en [10]).En la figura 5, comparamos los tiempos de ejecuciónobtenidos para la transformada 2D-DWTutilizando las cuatro implementaciones propuestasen CUDA: la implementación en CUDA del algoritmobasado en la convolución descrito en la secciónI (nombrado como CUDA-Conv 9/7 ); la implementacióndel algoritmo básico descrito en la SDKde CUDA utilizando tanto la memoria global (nombradocomo CUDA-Mem 9/7 ) como utilizando texturas(nombrado como CUDA-Text 9/7 ); y el algoritmo,descrito en esta sección, que optimiza el accesoa memoria basado en filtros separables (nombradocomo CUDA-Sep 9/7 ). En la figura 5 podemosobservar que los tiempos obtenidos con el algoritmopropuesto CUDA-Conv 9/7 son similares a losobtenidos con las implementaciones CUDA-Mem 9/7y CUDA-Text 9/7. Sin embargo, sí obtenemos unamejora considerable al optimizar el acceso a la memoriacompartida usando filtros separables. Por ejemplo,el factor de mejora obtenido por el algoritmoCUDA-Sep 9/7 es 2, 7 para un tamaño de imagen de4096 × 4096, .IV. ConclusionesHemos presentado varios algoritmos para el cálculode la transformada discreta wavelet, basadostanto en la convolución como en la transformadalifting, en sistemas multinúcleo y en arquitecturasGPU. Además, hemos comparado nuestras propuestascon otras propuestas recientes como la citadaSMDWT. El speed-up obtenido en sistemas multinúcleoes de 1, 9 utilizando dos procesadores y entre2, 4 y 3, 4 usando cuatro procesadores. Hemosquerido trasladar estos resultados obtenidos en sistemasmultinúcleo a arquitecturas con procesadoresgráficos, trasladando la memoria temporal de almacenamientode la fila o columna a la memoria compartidade la GPU. El speed-up en la GPU respectoa un sistema multinúcleo ha sido superior a 20. Porotro lado, hemos comparado el rendimiento obtenidoen la GPU con otras propuestas de implementacionessimilares en CUDA.Como conclusión, nos gustaría destacar que a)el uso de una arquitectura multinúcleo mejora elrendimiento considerablemente en el cálculo de laDWT, y b) obtenemos una ganancia muy considerableen GPUs que puede ser incluso mejorada conun acceso optimizado a la memoria compartida.AcknowledgementsEl presente trabajo ha sido financiado por el Ministeriode Educación y Ciencia mediante el proyectoDPI2007-66796-C03-03 y por el Ministerio de Educacióny Ciencia mediante el proyecto TIN2008-06570-C04-04.Referencias[1] K. Rao and P. Yip. Discrete cosine transform: Algorithms,advantages, applications. In Academic Press,USA, 1990.[2] ISO/IEC 15444-1. JPEG2000 image coding system, 2000.[3] A. Said and A. Pearlman. A new, fast and efficientimage codec based on set partitioning in hierarchicaltrees. IEEE Transactions on Circuits, Systems andVideo Technology, 6(3):243–250, 1996.[4] S. G. Mallat. A theory for multi-resolution signal decomposition:The wavelet representation. IEEE Transactionson Pattern Analysis and Machine Intelligence,11(7):674–693, July 1989.[5] W. Sweldens. The lifting scheme: a custom-design constructionof biorthogonal wavelets. Applied and ComputationalHarmonic Analysis, 3(2):186–200, April 1996.[6] W. Sweldens. The lifting scheme: a construction of secondgeneration wavelets. SIAM Journal on MathematicalAnalysis, 29(2):511–546, March 1998.[7] Y. Bao and C.C. Jay Kuo. Design of wavelet-basedimage codec in memory-constrined environment. IEEETrans. on Circuits and Systems for Video Technology,11(5):642–650, May 2001.[8] C. Chrysafis and A. Ortega. Line-based, reduced memory,wavelet image compression. IEEE Transactions onImage Processing, 9(3):378–389, March 2000.[9] Chih-Hsien Hsia, Jing-Ming Guo, Jen-Shiun Chiang, andChia-Hui Lin. A novel fast algorithm based on smdwt forvisual processing applications. In Circuits and Systems,2009. ISCAS 2009. IEEE International Symposium on,pages 762 –765, May 2009.[10] V. Podlozhnyuk. Image convolution with cuda, June2007.[11] I. Daubechies and W. Sweldens. Factoring wavelet transformsinto lifting steps. Fourier Analysis and Applications,4(3):247–269, 1998.[12] J.M. Shapiro. Embedded image coding using zerotrees ofwavelet coefficients. IEEE Transactions on Signal Processing,41(12), December 1993.[13] OpenMP Architecture Review Board. Openmp c andc++ application program interface, version 2.0. March2002.[14] J. Nickolls, I. Buck, M. Garland, and K. Skadron. Scalableparallel programming with cuda. In Queue, volume6, pages 40–53, 2008.[15] NVIDIA Corporation. Nvidia cuda c programming guide.version 3.2.[16] Ian Buck. Gpu computing with nvidia cuda. In ACMSIGGRAPH 2007 courses, SIGGRAPH ’07, New York,NY, USA, 2007. ACM.JP2011-674

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Tableless Distributed Routing inHeterogeneous MPSoC SystemsJosé Cano 1 , José Flich 1 , José Duato 1 , Marcello Coppola 2 , Riccardo Locatelli 2Abstract—In application-specific SoCs, the irregularity of thetopology ends up in a complex implementation of therouting algorithm, usually relying on routing tablesimplemented with memory structures. As system sizeincreases, the routing table increases in size with nonnegligibleimpact on power, area and latency overheads.In this paper we propose a routing mechanismfor application-specific SoCs able to implement in anefficient manner (without requiring routing tables andusing a small logic block in every switch) a routing algorithmin those irregular networks. The mechanismrelies on a tool that maps the initial irregular topologyof the SoC system into a logical regular structurewhere the mechanism itself can be applied. We providedetails of both the mapping tool and the routingmechanism. Evaluation results show the effectivenessof the mapping tool as well as the low area and timingrequirements of the mechanism.Keywords—Systems-on-Chip, Networks-on-Chip, Routing.I. IntroductionAs technology advances, systems-on-chip (SoC)designs become more complex with the inclusion ofmany IP components. Tens (and in the near futureseveral hundreds) of elements need to be connectedwithin the same chip, thus requiring an efficient onchipinterconnect. Usually, the system design is customizedtaking into account the future applicationthat will be running on top of it. Traffic patternsare known in advance, and the interconnect is customizedtoo. The net result of such design approachis a network within the chip [1] [2] with no regularshape and with varying switch complexities and linkbandwidths. Figure 1 shows an example where IPblocks are connected by using an on-chip networkwith 28 switches. As can be observed, the networktopology is totally irregular and heterogeneous.Two key pillars of an interconnect are the topologyand the routing algorithm. The topology sets thephysical connection pattern between end nodes and,as indicated previously, in application-specific SoCsystems is usually irregular. The routing algorithm,on the other hand, sets the paths that messages needto take within the network. Once the topology is set,then, the routing algorithm needs to be applied andmessages need to be instructed about the paths tofollow. In order to implement the routing algorithmtwo trends can be followed: source routing and distributedrouting [3].1 Grupo de Arquitecturas Paralelas , Universitat Politècnicade València. E-mail: jocare@gap.upv.es, {jflich,jduato}@disca.upv.esSTMicroelectronics , Grenoble, France. E-mail:{marcello.coppola, riccardo.locatelli}@st.comFig. 1. Example of a complex irregular topology for anapplication-specific SoC system. P means producers andC means consumers.Today, the majority of application-specific SoCsystems in current products are using irregulartopologies based on well-known on-chip technologies(examples are Spidergon STNoC [4], Arteris NoC [5],Sonics MicroNetwork [6] and AMBA [7]). Those irregularsolutions are mainly based on source routingand address decoding, and normally need a compleximplementation of the routing algorithm (with routingtables using memory structures). Indeed, thelack of regularity in the topology prevents simplificationsin the routing algorithm design. As systemsize increases, the routing table increases in sizewith non-negligible impact on power, area and latencyoverheads (for a comparison between logicbasedrouting and tables, refer to [8]).In this paper we address the implementation ofthe routing algorithm in application-specific SoC systemswhere the topology is set by the application,thus being totally irregular. The aim is to design amechanism (LBDRx) that enables the use of tablelessdistributed routing on every switch with a constantand reduced logic cost, regardless of systemsize. We also provide a tool able to map the initialirregular topology into a logical regular structurewhere the LBDRx approach can be used. By doingthis, the routing algorithm can be efficiently implementedin the SoC design with no need of routingtables and with no topology change.There has been considerable work on routing algorithmsfor irregular NoCs [9] [10] [11]. However,none of the solutions allow the implementation of distributedrouting algorithms in irregular NoCs topologieswith no routing tables and minimum logic.The rest of the paper is organized as follows. SectionII describes the concrete contribution of the paperin a preliminary subsection, in order to clarifyJP2011-675

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011and focus the description of the mechanism and themapping tool. Then, we describe the LBDRx mechanismto cover practical topologies from SoC designs.In Section III we describe the mapping tool. Finally,in Section IV we provide evaluation results and concludethe paper in Section V.II. LBDRx descriptionThe description of the proposed LBDRx mechanismwill be presented as an evolution from the basicLBDR mechanism [8] previously proposed (withlow coverage for complex irregular topologies) to themost enhanced version (with full coverage to all thecomplex topologies analyzed).A. Preliminary: Basic IdeaIn regular networks, e.g. a 2D-mesh network, theregular connectivity pattern is useful when designingthe routing algorithm. Indeed, with the Dimension-Order routing (DOR), the implementation is quitestraightforward as messages are forwarded with minimalpaths first in the X direction and then in theY direction. Thus, there is no need for a routing table,only a set of gates is enough. This renders to anefficient implementation of the routing algorithm interms of area, power, and delay.If we consider small irregularities on 2D-mesh networks,for instance due to manufacturing defects,then the inherent irregularity complicates the routingimplementation. For instance, DOR is no longervalid as some paths are not possible now. However,other routing algorithms are still suitable for suchtopologies, for instance, topology-agnostic routingalgorithms like up*/down* [12]. Their implementationis usually performed with routing tables. Effortsto provide efficient implementations of such algorithmsin those irregular topologies have been performedin the recent years.One important method is LBDR, which collapsesall the routing information required on every switchon a small set of bits, thus reducing significantly implementationcosts. LBDR still relies on the factthat the topology is a 2D-mesh network but withsome missing links. Adding some bits enables LBDRto successfully deal with the irregularity induced bymissing links. However, LBDR still relies on the factthat every switch has at most four links connectingneighboring switches (at North, East, West, or Southdirections). LBDR uses, as DOR does, the coordinatesof the destination switch in the message andthe coordinates of the current switch, to computethe appropriate set of output ports. Thus, LBDRstill benefits from the original 2D-mesh layout.In this paper, what we propose is the extensionand applicability of the LBDR concept to trulyapplication-specific and irregular networks (as an examplesee Figure 1). The approach we follow is tomap the topology into a 2D grid (notice, however, wedo not change the initial topology). Once the topologyis mapped, we need to provide coordinates to everyswitch in the network. Based on the coordinatesof the destination switch and the current switch, thederived LBDR logic will decide the output port thatneeds to be used to forward the packet towards itsdestination. In order to correctly map the topologyinto a 2D grid, we have developed a mapping algorithmthat will search the space of combinations andwill deliver the most suitable ones, always guaranteeingdeadlock freedom and connectivity.Due to the mapping performed, and because of thehigh irregularity we will find, some switches will requirea varying number of ports to connect to otherswitches, and in that situation some links will connectswitches not placed closely in the 2D grid. Thiskind of connectivity has not been provided by theoriginal LBDR mechanism, and thus, requires modifications.In this paper, we further extend LBDR forits support in this kind of mappings.B. LBDR Extension: LBDRxWe start the description with the mechanism requiredat every switch to deal with the irregulartopologies. In order to be concise, we take as a referencethe mapping of the initial topology (Figure 1)that appears in Figure 2. This mapping is obtainedwith the mapping tool that will be described in thenext section. The mapping is representative of allthe connectivity patterns between switches that weneed to address in this section.Fig. 2.Mapping example for the initial topology.As we can see in the figure, there are switches withvarying connectivity patterns with other switches.For instance, switch 1, mapped at row 2 and column2, is connected to switches 4, 2, and 21 with differentlink mapped lengths. In particular, mapped length oflinks are 2 hops for links connecting to switches 2 and4, and 3 hops for the link connecting to switch 21.In addition, links with the same number of mappedhops have different orientations/directions, thus, beingdifferent. This is the case for link connecting toswitch 4 which is located one hop north and one hopwest from switch 1, and link connecting to switch 2that is two hops north.As previously described, LBDR relies on switcheswith up to four ports, and each one connectingswitches in one direction in the 2D mesh plane (N,JP2011-676

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011E, W and S). Also, the maximum distance coveredwith a link is 1 hop in the 2D grid. Thus, links withhigher mapping lengths are not supported. In orderto overcome this limitation, LBDRx allows forswitches with up to 20 ports for connecting to otherswitches (ports used to connect end nodes are excluded).Also, any of these ports can be configuredas a 1-hop port, a 2-hop port, or a 3-hop port. AX-hop port connects two switches that are at mappingdistance X. In order to uniformly refer to X-hopports, we define additional directions. In particular,20 different directions are supported, and each of the20 possible ports of the switch can be configured toany of the 20 directions. Figure 3 shows all the possibleport directions supported by LBDRx.Fig. 4.Logic of LBDRx.Fig. 3.Possible directions in LBDRx.Simplified versions of the mechanism can be conceivedby restricting the type of ports that can besupported. For instance, the LDBR mechanism isembedded in the proposed mechanism when only 1-hop ports are allowed. Another implementation isallowing 1-hop and 2-hop ports only, thus obtaininga LBDR2 mechanism. Therefore, the LBDRx proposalcan be seen as a method to further extend theconnectivity of switches when mapped on a 2D grid.As we will see in the evaluation section, LBDR3 isenough to map all the tested topologies, thus notrequiring a more complex implementation.It is worth mentioning that, although 20 ports areallowed on every switch, not all of them need to beimplemented. Indeed, only a subset of ports will beimplemented, e.g. switch 1 at Figure 2 will be implementedwith only 3 output ports.The logic required for LBDRx is shown in Figure4. The mechanism relies on some configuration bits(will be hardwired) grouped in two sets: routing bitsand connectivity bits. Routing bits indicate whichrouting options can be taken (set the routing algorithm),whereas connectivity bits indicate whethera switch is connected with its neighbors (set themapped topology). As we support 20-port switches,at maximum we will have 20 connectivity bits perswitch. We represent the connectivity bit for a portX as C x , where X can be a possible direction of anymapped port (N, E, W, S, NN, NE, ..., NNE, ...).The routing bits R xy (where x and y can be n, e,w, and s) indicate whether messages routed throughthe x output port may take at the next switch they port. In other words, these bits indicate whethermessages are allowed to change direction at the nextswitch. The value of these bits is computed in accordanceto the applied routing algorithm and to preventdeadlock while still guaranteeing connectivity.In order to simplify the routing logic, no new routingbits are used except those already defined in LBDR:R ne , R nw , R en , R es , R wn , R ws , R se , R sw . Noticethat routing bits are used only between 1-hop links.By default, the LBDRx mechanism will assume messagescan take 2-hop and 3-hop links without restrictionalong their path without risk of inducing deadlock.The mapping strategy described in section IIIwill guarantee in those cases the absence of deadlocks.Although allowing more routing bits wouldlead to greater flexibility, we noticed that they arenot needed in order to reach our objective (shown inthe evaluation section). This will also help to keep alow implementation cost of the mechanism.Routing logic of LBDRx is divided into two parts(see Figure 4). The first part of the logic computesthe relative position of the message’s destination.For this, two comparators are used and coordinatesof the current switch (X curr and Y curr ) are comparedwith the coordinates of the message’s destination(X dst and Y dst ) located in the message header.At the output of this logic one or two signals may beactive (e.g. if the packet’s destination is in the NWquadrant then N’ and W’ signals are active at thesame time). Note also that packets forwarded to thelocal port are excluded from the routing logic.Additionally, four extra signals (NN’, EE’, WW’and SS’) are computed. These signals are set to oneif the message’s destination is at least two hops awayin the corresponding direction (if NN’ is active, thenat least two hops must be performed in the N directionto get closer to its destination). These signalscan be easily computed with additional comparatorsbetween the current and the destination coordinates.Notice that in some situations different signals willbe active at the same time, for instance signals NN’and N’. These cases are filtered in the second partof the logic. Higher priority will be given to largerJP2011-677

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011hop ports. We refer to the signals produced by thecomparators as intended direction signals.The second part of the logic consists of a logic unitat each output port in the switch. Figure 4 shows thedetails. The logic is divided in three parts in orderto address the logic for the different type of outputports (1-hop, 2-hop, and 3-hop ports). Notice that3-hop ports have the highest priority followed by 2-hop ports. This means that if a 3-hop output port iseligible for routing a message then, ports with lowermapping length will not be considered. To implementthis priority scheme, two control signals (2hopand 3hop signals) are used. Besides this, the logic tocompute 2-hop and 3-hop ports is quite straightforward.Indeed, a port X is eligible if the port existsin the switch (C x bit is set), and the message’s destinationis in the same direction of the output port(direction signals). As an example, output port NNEis eligible for routing if the message’s destination isin the NNE direction (signals NN’ and E’ are set).The logic for 1-hop ports is, however, slightly morecomplex. It deals also with the routing bits. Thelogic, in this case (excluding the priority signals) isimplemented with two inverters, four AND gates andone OR gate. The logic filters out the routing optionsthat could lead to deadlock situations (by using therouting bits). Obviously, connectivity bits and prioritysignals are used in combination with the previouslogic. The logic for the 1-hop output ports is thesame used in LBDR.As a final remark for the LBDRx routing mechanism,its success depends strongly on the mappingperformed for the topology. Therefore, the mappingtool described in the next section, is a key element toguarantee applicability of the LBDRx mechanism.III. Mapping ToolIn this section we describe the mapping tool requiredby the LBDRx mechanism. The mapping toolis adapted to different versions of LBDRx routing,e.g. with 3-hop links, 2-hop links, and with/withoutnon-minimal path support. The mapping tool takesas an input the topology and the type of LBDRx supportand outputs several possible solutions, each ofthem able to be used with the target LBDRx version.Indeed, the mapping tool (see Figure 5) provides forany possible solution the set of configuration bits togetherwith the mapping coordinates of every switchinto a 2D grid. It is worth highlighting that themapping tool does not physically change the topology,indeed it only logically maps the topology ontoa 2D grid. In the next subsections we describe thedetails of each stage along with an example.C. Support for Non-minimal Mapped PathsThe previous logic guarantees minimal path routingin the mapped topology. As each output port isused when the destination is located in the same directionof the output port, then every hop performedguarantees the message will get closer to its destination.However, there are mapping cases that can notbe solved with only minimal path support. As anexample, in the mapped topology shown in Figure2, a message going from switch 1 (mapped in row 2and column 2) requires a mapped non-minimal pathto reach switch 23, as it needs to be forwarded SSWand then NNW. This fact simply renders the mappedtopology as unsupported by LBDRx (Figure 4).One possible solution is to discard the mappedtopology and obtain one that guarantees all thepaths will follow minimal paths. However, in somecomplex topologies, this kind of mappings will simplynot exist. To solve this problem in a smooth way,and allowing much more flexibility to the mechanism,we introduce a small additional logic on every switchto allow such non-minimal path support. The logicforces messages to take a non-minimal port (deroute)whenever the LBDRx logic fails in routing the message(in our example, port SSW). The logic requiresa configuration register of size 5 bits (to select an outputport out of maximum 20 ports) per switch. It isworth mentioning that deroutes need to be computedin accordance to the routing algorithm, as they mustnot introduce cycles that could lead to deadlocks.Fig. 5.Mapping tool.A. Compute Mapping of SwitchesThe first stage provides an initial mapping of theswitches into a 2D grid. Some basic assumptions areconsidered:1. Only switches are considered for the mapping,thus not considering end nodes.2. The 2D-mesh diameter will be minimized andmade as square as possible.3. Every possible mapping of switches onto the 2Dmesh is explored and further analyzed in the followingstages (most of them will result in mappingsnot supported by LBDRx).Fig. 6.Example of two initial mappings.As an example, Figure 6 shows two possible mappingscorresponding to the example topology providedin Figure 5. At first sight we cannot deducewhich one can be supported. For this, we need tocompute the connection pattern.JP2011-678

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011B. Compute the Connection PatternThe connection pattern considers only links connectingswitches (switch-to-switch links) and the directionof each link (unidirectional links are considered).Several restrictions are enforced in this step(considering LBDR2):1. Any switch has at maximum 12 outgoing portsand 12 incoming ports, possibly having lessnumber of ports, and not necessarily the samenumber of input and output ports.2. In every switch one possible direction out of 12can be taken through a single output port. Thedirections are the ones supported by LBDR2 (2-hop and 1-hop links depicted in Figure 3).Taking into account the previous restrictions,mappings with link lengths longer than the targetedLBDRx version will become not valid. Figure 7(a)shows the connectivity pattern for the previous twomapping cases. As can be seen, the second mappingcase is not compatible with LBDR2 since it containsa 3-hop link. Notice however, that if we use LBDR3both mappings are, then, supported.Fig. 7. Example of (a) connectivity pattern applied to twodifferent mappings, and (b) mapped topology with therouting algorithm applied.C. Compute a Proper Routing AlgorithmOnce we have obtained a correct mapping we needto check whether the mapped topology contains cyclesor not. In order to avoid them, it will be necessaryto apply a routing algorithm. In our case, therouting algorithm used is the Segment-Based Routing(SR) [13], a technique that divides the networkinto segments and puts a routing restriction in eachsegment. A routing restriction is placed between twoconsecutive links and prevents any message from usingboth links sequentially. Drawing routing restrictionsis a way of representing a routing algorithmsince restrictions establish the allowed paths. In orderto compute the routing restrictions, only 1-hoplinks in the mapped topology are assumed. As commentedabove, this assumption simplifies the LBDRxlogic and still allows to reach our objective of avoidingcycles.In the first mapping in Figure 7(a), a cycle can beformed between switches 0, 3, and 2 in the counterclockwise direction. Figure 7(b) shows the validmapped topology with the unidirectional routing restrictionapplied at switch 2. Notice that LBDRxcomputes the routing bits from the routing restrictionsdefined by the routing algorithm.D. Check Deadlock-Freedom and ConnectivityThe last step of the mapping tool is to verify themapping is deadlock-free and guarantees the connectivityof the initial topology. The routing algorithmapplied in the previous step ensured deadlockfreedombetween 1-hop links, thus, now it must bechecked along 2-hop and 3-hop links. On the otherhand, when applying the routing algorithm and whennot using deroutes, some pair of end nodes may beunconnected. The reason is because LBDRx withoutderoutes relies exclusively on minimal paths. Therefore,a routing restriction may lead to a path beingrouted non-minimally. At this stage, the tool iterateson all the communicating flows of the application(a flow is defined as the path from a producer toa consumer). For each flow, the tool searches a validLBDRx path using the connectivity and routing bitsset by the mapped topology. If for a flow there isno connectivity, then, the mapping is not valid andwe will need either to search a new mapping or usederoutes.On success of a mapping topology, the final outputis the mapping of each switch into the 2D gridand the configuration (connectivity, routing and deroute)bits. Notice that the mapping tool succeeds ifat least one mapping solution is obtained. Also, if nomapping solution exists for a grid size, the mappingtool extends the grid by one row and/or column thushaving much larger flexibility. Figure 2 shows a successfuldeadlock-free mapping for the initial topologydepicted in Figure 1 where connectivity betweenswitches is assured (LBDR3 with deroutes was used).IV. EvaluationIn this section, we provide a comprehensive evaluationof LBDRx. First, we show the results (TableI) of applying the mapping tool to different sets oftopologies with increasing complexity. The mappingtool was run in AMD Opteron (2,8 Ghz dual core,8Gb RAM) computers.Grid size Correct Deroutes TimeType 1 4x4 >10.000 not needed 3-5 mType 2 5X5 >100.000 not needed 10-15 mType 3 5X6 >100.000 not needed 30-45 mType 4 5X7 >100.000 10-15 1-2 hFig. 1 5X7 578.952 13-15 2 hTABLE ITopology mappingsThe main purpose was to compute the number ofcorrect mappings generated for every analyzed topologyand the time required to complete the procedure.In each case, the table shows the minimum grid sizeneeded to map the topology (4x4, 5x5, ..., 5x7), thenumber of correct mappings obtained, and the averagenumber of deroutes used (per mapping), if necessary.Note that correct mappings will be those whichmet the restrictions imposed by the LBDRx versionapplied in each case. In the last column the compu-JP2011-679

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011tation time to complete the entire process is shown.This time depends mainly on the complexity of eachtopology, and for these examples ranges from someminutes to several hours.In second place, all the LBDRx versions are comparedbetween them and with an example using routingtables from an implementation cost and efficiencyviewpoint, with a glance at scalability properties.LBDRx versions were designed and synthesized withthe 45nm Nangate opensource library, and routingtables by using Memaker. In Figure 8, we observehow differences between all the LBDRx versions areslight in terms of area. When compared with a RAMmemory of 256 entries, the LBDRx versions are muchcompact (notice the logarithmic scale). For delay(Figure 9), although similar, the LBDRx versionshave lower access latency.Fig. 8.Fig. 9.Routing Module Area.Routing Module Delay.V. ConclusionsIn this paper we have presented LBDRx, a seriesof routing mechanisms (with support to non-minimalpaths) for application-specific SoC systems where thetopology is totally irregular. The main goal of LB-DRx is to enable the use of table-less distributedrouting on every switch with a constant and reducedlogic cost, regardless of system size. Moreover, wepresented a mapping tool able to obtain differentmappings of the same irregular topology onto a 2Dgrid. The tool is key for the application of the LB-DRx mechanism.The provided results demonstrate the applicabilityof the mapping tool onto a wide set of topologies. Inall cases, a valid mapping was achieved, thus routingtables were replaced by the LBDRx mechanism. Implementationcosts also showed the benefits of suchreplacement.As future work we plan to further explore the LB-DRx mechanism and the mapping tool, focusing onperformance issues. Different mappings could endup in different performance numbers. Thus, we planto optimize the tool to provide the best mapping forthe target application.AcknowledgmentsThis work was supported by the Spanish MECand MICINN, as well as European ComissionFEDER funds, under Grant CSD2006-00046. Itwas also partly supported by the COMCAS project(CA501), a project labelled within the frameworkof CATRENE, the EUREKA cluster for Applicationand Technology Research in Europe on NanoElectronics.Finally, the authors would like to thank AntoniRoca for his assistance in the Area-Delay comparisontests.References[1] Luca Benini and Giovanni De Micheli, Networks onChips: Technology and Tools, Morgan Kaufmann PublishersInc., San Francisco, CA, USA, 2006.[2] Jose Flich and Davide Bertozzi, Designing Network On-Chip Architectures in the Nanoscale Era, CRC Press,Inc., Boca Raton, FL, USA, 2010.[3] Jose Duato, Sudhakar Yalamanchili, and Ni Lionel,Interconnection Networks: An Engineering Approach,Morgan Kaufmann Publishers Inc., San Francisco, CA,USA, 2002.[4] Marcello Coppola, Miltos D. Grammatikakis, RiccardoLocatelli, Giuseppe Maruccia, and Lorenzo Pieralisi,Design of Cost-Efficient Interconnect Processing Units:Spidergon STNoC, CRC Press, Inc., Boca Raton, FL,USA, 2008.[5] Inc. Arteris, “Arteris noc,” http://www.arteris.com/,2010, [Online; accessed 31-August-2010].[6] Drew Wingard, “Micronetwork-based integration forsocs,” in In Proceedings of the 38th Design AutomationConference, 2001, pp. 673–677.[7] ARM Ltd., “The advanced microcontroller bus architecture(amba),” http://www.arm.com/products/systemip/amba/,2010, [Online; accessed 01-September-2010].[8] José Flich, Samuel Rodrigo, José Duato, Simone Medardoni,and Davide Bertozzi, “Efficient implementation ofdistributed routing algorithms for nocs,” in IET Computersand Digital Techniques. 2009, pp. 460–475, IET.[9] M. K. F. Schafer, T. Hollstein, H. Zimmer, andM. Glesner, “Deadlock-free routing and componentplacement for irregular mesh-based networks-on-chip,” inProceedings of the 2005 IEEE/ACM International conferenceon Computer-aided design (ICCAD ’05). 2005,pp. 238–245, IEEE Computer Society.[10] Bolotin, E., Cidon, I., Ginosar, R., and Kolodny, A., “Efficientrouting in irregular topology nocs,” Tech. Rep.CCIT 554, Israel Institute of Technology, Technion Departmentof Electrical Engineering, 2005.[11] Igor Loi, Federico Angiolini, and Luca Benini, “Synthesisof low-overhead configurable source routing tables fornetwork interfaces.,” in DATE. 2009, pp. 262–267, IEEE.[12] D. Gelernter, “A dag-based algorithm for prevention ofstore-and-forward deadlock in packet networks,” IEEETrans. Comput., vol. 30, pp. 709–715, October 1981.[13] Flich, J., Mejia, A., López, P., and Duato, J., “Regionbasedrouting: an efficient routing mechanism to tackleunreliable hardware in networks on chip,” in 1stACM/IEEE Int. Symp. Networks on Chip (ISNOC),2007.JP2011-680

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Uso del conocimiento de la arquitectura Fermipara mejorar el rendimiento en aplicacionesCUDAYuri Torres, Arturo González-Escribano y Diego R. Llanos 1Resumen— Las unidades de procesamiento gráfico(GPUs) actualmente están jugando un papel muy importantecomo aceleradores para cómputo de propósitogeneral. La implementación de códigos paralelos dealto rendimiento en GPUs es una tarea recomendadapara programadores experimentados, debido al altogrado de dificultad de explotar eficientemente el usode los sus recursos. La elección del tamaño y la formade los bloques de hilos son decisiones importantes yaque tienen un impacto muy significativo sobre el rendimientode las aplicaciones. La arquitectura Fermi deNVIDIA introduce nuevos criterios a la hora de seleccionarlos tamaños y la geometría de los bloques dehilos. En este artículo mostramos un estudio de dichoscriterios, así como una guía general para seleccionarun bloque de hilos apropiado para diferentes tipos deaplicaciones.Palabras clave— CUDA, Fermi, auto-tuning, GP-GPU.I. IntroducciónLAS unidades de procesamiento gráfico (GPUs)han conseguido ser una importante plataformacomputacional en muchos campos científicos talescomo computación masiva de datos o computaciónbiomédica. Entre las principales ventajas de estosdispositivos destaca el bajo coste operacional, la facilidady sencillez ofrecida por los entornos de programacióny el alto potencial de rendimiento.La programación basada en el modelo GPGPU(computación GPU de propósito general) ha sidosimplificada al introducir modelos de programacióncomo CUDA [1]. Sin embargo, explotar eficientementeestos dispositivos implica utilizar un elevado conocimientode la arquitectura para aplicar adecuadamentetécnicas de optimización de código.Fermi [2] [3] [4] es la última arquitectura desarrolladapor la compañía NVIDIA para dispositivosGPUs. Comparada con versiones anteriores, Fermiintroduce varias mejoras que influyen significativamenteen las estrategias básicas de optimización existentesen las optimizaciones de códigos para GPU.Por ejemplo, explotar la coalescencia, maximizar laocupación de los multiprocesadores (SMs), la precargade datos y el unrolling. También introduce laposibilidad de configurar su nueva memoria caché L1.La elección del tamaño y la geometría del bloquede hilos es una de las decisiones más importantes a lahora de implementar cualquier código de alto rendimientoen dispositivos GPU. Actualmente, el tamañoy la geometría de los bloques son típicamente seleccionadosmediante prueba y error sin conocimiento1 Dpto. de Informática, Univ. de Valladolid, e-mail:{yuri.torres|arturo|diego}@infor.uva.esprevio de los posibles efectos que puedan causar sobrela arquitectura.En este artículo se presenta un estudio prácticode la arquitectura Fermi orientado a la elección deltamaño y la geometría de los bloques de hilos. Sedescribe un nuevo enfoque para determinar el mejorbloque de hilos y la mejor configuración de la memoriacaché L1 para diferentes tipos de aplicaciones.Los resultados de estudio experimental muestranla utilidad del enfoque y como el conocimiento de laarquitectura hardware de estos dispositivos se puedeexplotar para utilizar más eficiente sus recursos.El resto del artículo está organizado de la siguienteforma: en la sección 2 se comentan los detalles introducidospor la arquitectura Fermi comparándoloscon las versiones anteriores. En la sección 3 se discutecómo la arquitectura afecta significativamente ala hora de seleccionar el tamaño y la geometría delbloque de hilos. En la sección 4 se describe el diseñode experimentos con el objetivo de verificar nuestrashipótesis. En la sección 5 se detalla el banco depruebas utilizado. En la sección 6 se muestran losresultados obtenidos mientras que en la sección 7 serefleja el trabajo relacionado. Finalmente, la sección8 contiene las conclusiones de este artículo.II. Arquitectura NVIDIA FermiFermi es la última generación de arquitecturas CU-DA [2] [3]. Esta nueva arquitectura incluye operacionesde doble precisión, soporte para la corrección deerrores, un incremento en la rapidez de los cambiosde contexto y de las operaciones atómicas, y una jerarquíatransparente de memorias caché L1/L2 con laposibilidad de desactivar la L1 o ampliar su tamañoa costa de reducir la memoria compartida explícitamentemanejable por el usuario. Esta sección discutelos detalles de la arquitectura Fermi más significativospara nuestro estudio.A. Memorias caché L1/L2En arquitecturas pre-Fermi cada SM tenía 16 KBde memoria compartida manejable explícitamentepor el usuario, sin presencia de memorias caché. Fermiintroduce dos memorias caché transparentes (L1y L2). La memoria L1 es configurable por el usuario.Por defecto tiene 16 KB de caché L1 y 48 KB de memoriacompartida, pero se puede configurar antes delanzar cada kernel para tener 48 KB de caché L1 y 16KB de memoria compartida. La memoria caché L2es de tamaño fijo con 768 KB de capacidad. Hastala llegada de Fermi el tamaño de los segmentosJP2011-681

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Shared MemoryL2 CacheDRAML1 Cache48 or 16 Kb 16 or 48 KbP0 P1 P2 P3 P4 P5256 bytesThread384 bits768 Kb1.5 GbFig. 1. Jerarquía de memoria Fermi (NVidia GTX-480).de transacción de memoria eran de 32, 64 y 128 Bytes.Sin embargo, en Fermi son de 128 ó 32 Bytes,dependiendo de si la caché L1 está activa.B. Bloque de hilos, Warps y SMsFermi dobla el número de registros por SM (32KB). El número de procesadores (SPs) por SM hasido multiplicado por cuatro (32 SPs). En Fermi elnúmero máximo de hilos por bloque es 1024, mientrasque el máximo número de hilos concurrentes enun SM es 1536.C. Conflictos en memoria globalActualmente en Fermi la memoria global de estosdispositivos está distribuida en 5 ó 6 bancos con suscorrespondientes controladores independientes. Unproblema frecuente a la hora de implementar códigosparalelos sobre arquitecturas pre-Fermi era el partitioncamping [5]. Este problema surge cuando hilosconcurrentes activos en cualquier SM solicitan segmentosde memoria diferentes pertenecientes al mismobanco de memoria global. Ello implica una serializaciónde dichas transacciones. Con la introducciónde las cachés L1 y L2 en Fermi, este problema se aliviócuando los mismos segmentos de transacción sesolicitan una y otra vez.III. selección del tamaño y la geometríadel bloque de hilosEn esta sección discutimos cómo los detalles dela arquitectura Fermi afectan a las decisiones de losprogramadores respecto al tamaño y geometría delos bloques de hilos, así como a la configuración dela memoria caché L1.A. Tamaño de bloque de hilosA.1 Maximizar ocupaciónEn CUDA el factor ocupación de un SM es el ratioentre el número de warps presentes en el mismo yel número máximo de warps soportados por un SM(48 warps en Fermi). Maximizar la ocupación es importantepara ocultar las latencias en los accesos amemoria global.Para obtener máxima ocupación es necesario seleccionarun tamaño de bloque de hilos apropiado.La arquitectura Fermi soporta 1024 hilos por bloque,1536 hilos por SM y un máximo de 8 bloquesresidiendo simultáneamente en un SM. Por lo tanto,el tamaño de bloques de hilos debe ser inferior o iguala 1024, a la vez divisor entero de 1536 y el máximonúmero de hilos del SM dividido entre el tamaño delbloque no puede exceder de 8. Por ello concluimosque los únicos tamaños de bloques de hilos que maximizanla ocupación son 192, 256, 384, 512 y 768.Finalmente, cuando se va a lanzar un kernel quenecesita menos de 192 hilos por el número de SMsen el dispositivo, puede ser recomendable escoger tamañosde bloques más pequeños, que no consiganmaximizar la ocupación. De esta forma, se aumentael número de bloques y se distribuyen mejor el conjuntode hilos entre los SMs, aumentando el grado deparalelismo global.A.2 La coalescencia y la carga de accesos a memoriaLa coalescencia es una técnica de implementaciónpara conseguir que hilos consecutivos de un warp,cuando solicitan memoria global, pidan direccioneslógicas contiguas. Esta técnica permite minimizar elnúmero de segmentos de transacción solicitados a lamemoria global. La coalescencia es especialmente importanteen aquellos códigos donde existe un alto ratiode accesos a memoria.Una técnica común para facilitar la programaciónde la coalescencia es utilizar estructuras de datosalineadas con el número de hilos por warp y el tamañode los segmentos de transacción. Para reducirlas probabilidades de la aparición de partition camping,es también aconsejable usar estructuras de datosque estén perfectamente alineadas con el númerode controladores de memoria global del dispositivoGPU. Por ejemplo, facilita la programación el escogerarrays de enteros o floats cuya última dimensiónes múltiplo de 32 y a la vez del número de bancos.Para kernels de CUDA donde prevalezca el patrónde acceso coalescente y un alto ratio de accesos a memoria(uno o más accesos a memoria por operaciónaritmética), consideramos que utilizando bloques de192 hilos se obtendrán los mejores resultados por dosmotivos: (1) se maximiza la ocupación, (2) se consigueel mayor número de bloques concurrentes porSM (8). De esta forma, cuando los warps de un bloquevan terminando este se desaloja lo antes posiblepor tener un menor número de warps. Por tanto, lacantidad de warps que están activos en el SM se mantieneen el máximo (48) la mayor cantidad de tiempoposible dando más oportunidades a la ocultación delas latencias.Kernels de programas como la multiplicación dematrices, a pesar de su coalescencia, presentan característicasdiferentes. Tienen mucha carga computacionalpor hilo y reutilizan datos en segmentos dememoria requeridos previamente. En este caso se esperaque aumentar el tamaño de bloque hasta 768 hilos(mayor tamaño de bloque que maximiza la ocupa-JP2011-682

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ción) mejore el rendimiento ya que se explota mejorla reutilización reduciendo el número de segmentosde transacción solicitados.A.3 Accesos no coalescentesEn códigos cuyo patrón de acceso a memoria globalno es coalescente el número de segmentos de transacciónque solicita un warp se ve incrementado significativamente,incrementando a su vez la probabilidadde conflictos en los bancos de memoria global (partitioncamping).Para reducir el cuello de botella provocado por lacantidad de segmentos de transacción solicitados amemoria global, proponemos dos estrategias básicas:(1) desconectar el uso de la memoria caché L1, ya quede esta forma, el tamaño de los segmentos se reducea una cuarta parte y (2) disminuir el tamaño de bloquereduciendo la ocupación para reducir el númerode segmentos solicitados por SM en un periodo detiempo dado.B. La forma de los bloquesPara un tamaño de bloque de hilos dado existendiferentes posibles geometrías, con el mismo ratio deocupación. Para la misma ocupación cada posiblegeometría tiene un impacto diferente sobre la coalescencia,los conflictos en los bancos de memoria y loscuellos de botella en los accesos a la memoria global.En programas cuya codificación explota eficientementela coalescencia, los mejores resultados se obtendráncon bloques de hilos cuyo número de columnassea múltiplo de 32 (tamaño del warp). Las peticionesde memoria global de cada warp coincidencon segmentos de memoria completos, minimizandola cantidad de segmentos a transferir.IV. Diseño de experimentosEn esta sección introducimos el diseño de los experimentosrealizados para verificar las hipótesis previamentepresentadas. Para ello, programamos unaserie de benchmarks en CUDA y los ejecutamos condiferentes tamos de bloque.Los benchmarks discutidos en esta sección incluyen:una reducción de vectores, suma de matrices,una modificación de suma de matrices para simularun aumento de carga, multiplicación de matrices ycopias de datos con accesos dispersos y aleatorios sobrearrays bidimensionales.Para todos nuestros benchmarks consideramosbloques de diferentes tamaños, hasta 1024 hilos(el máximo en permitido en Fermi). Escogemos unnúmero de elementos por dimensión para la geometríadel bloque que es potencia de dos, o potenciade 2 multiplicada por 3. Así conseguimos todas lascombinaciones de geometrías que maximizan la ocupacióny otros tamaños de bloque más pequeños.Para el problema unidimensional de reducción devectores se utiliza 4096 × 1023 elementos. Considerandoque cada hilo trabaja sobre dos elementos, estopermite bloques de 32 hilos o más sin superar elnúmero máximo de bloques por dimensión soportadospor Fermi (65535).Para el resto de benchmarks usamos matrices cuadradasde 6144 elementos por dimensión. Este tamañoes suficientemente pequeño como para alojar3 matrices en la memoria global del dispositivo.Además, las cardinalidades de cada dimensión sonmúltiplo del número de bancos de memoria globalde nuestro dispositivo, así como de las dimensionesde las geometrías probadas.Los experimentos han sido ejecutados sobre la tarjetaNvidia GeForce GTX 480. El sistema es un Intel(R)Core(TM) i7 CPU 960 3.20GHz de 64 bitscon 6 GB de memoria principal. El sistema operativousado es UBUNTU desktop 10.10 (64 bits). Eldriver de CUDA utilizado es el correspondiente a laversión 3.0 del toolkit.V. BenchmarksEn esta sección describimos los benchmarks clasificadospor tipo de aplicación.A. Accesos coalescentesEl primer benchmark es una reducción de vectorbasado en uno de los ejemplos del SDK de CUDA.Ha sido necesario modificarlo para poder variar el tamañodel bloque. El kernel de este código aplica unareducción de dos elementos por cada hilo, escogidosde forma coalescente en cada warp. El kernel se lanzavarias veces con la mitad de bloques cada vez hastaterminar la reducción.El segundo es un código trivial de suma de matricesdonde cada hilo está asociado al cálculo deuna posición de la matriz resultado. Esto implica 3accesos a memoria por cada hilo (dos de lectura yuno de escritura). Implica un patrón de acceso a memoriacompletamente coalescente sin reutilización deningún elemento. En este caso, cada warp necesitaúnicamente un segmento de transacción de 128 bytespara las 32 peticiones realizadas por los hilos deun warp en cada acceso.Se ha escogido también un código trivial de multiplicaciónde matrices [1] donde cada hilo calcula elproducto escalar de una fila de la primera matriz yuna columna de la segunda. A pesar de ser un algoritmosencillo presenta un patrón de acceso diferenteen cada una de las tres matrices utilizadas. La combinaciónde los diferentes patrones produce un efectocomplejo de analizar.B. Accesos no coalescentesSe ha construido un benchmark sintético, denominadoaccesos dispersos regulares diseñado con elobjetivo de crear un patrón de acceso disperso sobrela memoria global del dispositivo, de tal forma quecada hilo pida un segmento de transacción diferente.Cada hilo pide un elemento entero que se encuentraa 32 posiciones de memoria global de distanciadel anterior. Una vez accedido al elemento deseadose incrementa su valor y se almacena en la posiciónJP2011-683

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011siguiente, que está en el mismo segmento de transacción.También se utiliza una variante del benchmark anteriordenominado accesos aleatorios. Cada hilo calculaun par de valores aleatorios, los cuales sirvenpara determinar la posición a la que se accede enuna matriz. Al igual que el benchmark anterior elespacio de hilos tiene tantos elementos como la matriz.Cada hilo realiza alrededor de 20 operacionesaritméticas para el cálculo de los índices aleatorios.VI. Resultados experimentalesEn esta sección presentamos los resultados obtenidospor nuestros benchmarks, estudiando su relacióncon los detalles de la arquitectura Fermi comentadosen secciones previas.A. Acceso coalescenteA.1 Kernels pequeños sin reutilización de datosEn la tabla I se muestran los tiempos de ejecuciónde la reducción de vectores. Por el tamaño de datosde entrada escogido, el número de hilos por bloquetiene que ser como mínimo de 32. La implementaciónde la reducción presenta un patrón coalescente, dondeno existe reutilización de datos entre hilos y cadahilo apenas tiene carga computacional, únicamentepara calcular las posiciones de trabajo en el vector.La tabla I confirma el resultado general predicho enla sección III: el mejor tamaño de bloque es el menorque maximiza la ocupación, es decir 192.La tabla II muestra los tiempos de ejecución parala suma de matrices con las diferentes geometríasconsideradas. Los resultados correspondientes a bloquesde hilos que maximizan la ocupación de los SMsestán resaltados en negrita. Los resultados son similaresal caso anterior, obteniendo el mejor tamañode bloque en 192 hilos. El tiempo de ejecución crecerápidamente al reducir el número de columnas pordebajo de 32 y no aprovecharse el efecto de coalescencia.No se reflejan en la tabla bloques con menosde 8 columnas por problemas de espacio. Siguen latendencia esperada.Los experimentos realizados desactivando lacaché L1 no muestran un impacto significativo sobrelos resultados. Se reduce la cantidad de datos porsegmento a cambio de aumentar proporcionalmenteel número de éstos.A.2 Reutilización intensiva de datosEn la tabla III se muestran los resultados para lamultiplicación de matrices. Con menos de 32 columnasde hilos, el tiempo de ejecución aumenta rápidamenteya que el patrón de acceso ya no es coalescenteen la primera matriz (se omiten dichos resultados enla tabla). Debido a la reutilización de los datos de lasdos matrices de entrada, bloques más grandes tienenmás posibilidades de reutilizar las mismas líneas decaché. Los mejores resultados se obtienen con 768 hilos,los bloques más grandes que maximizan la ocupación.Respecto a la geometría, para bloques de hilos conel mismo tamaño los mejores resultados se obtienenreduciendo el número de filas aumentando correspondientementeel número de columnas. Esta tendenciase mantiene hasta geometrías de una fila donde lostiempos vuelven a incrementarse debido a que en estealgoritmo domina la pérdida completa la reutilizaciónde los datos de la segunda matriz de entrada.B. Accesos no coalescentesLa tabla IV muestra los tiempos de ejecución paraeste benchmark. Es un kernel sin un patrón de memoriacoalescente y con muy poca carga de computacionalpor hilo. Como se discutió en la sección III-A.3 este tipo de códigos funcionan mejor por debajode máxima ocupación. Esto es debido a que: (1) laslatencias producidas por la gran cantidad de segmentossolicitados no se pueden ocultar con el máximonúmero de warps por SM, es decir, 48 y (2) reduciendoel número de warps por SM se decrementael número total de segmentos solicitados simultáneamente,aliviando el cuello de botella que serializa losaccesos a memoria global.Por último en la tabla V se observan los resultadosobtenidos para el código con accesos aleatorios.Este algoritmo utiliza demasiados recursos por SM,por lo que bloques de 1024 hilos llevan a una ocupaciónnula, marcados con asteriscos en la tabla. Esteprograma tiene una carga media en cuanto a operacionesaritméticas por acceso a memoria se refiere.Las latencias de los accesos se balancean con el tiempode cómputo en otros warps. Por tanto, los mejoresresultados vuelven a obtenerse con los bloques máspequeños de máxima ocupación (192 hilos). Al nohaber coalescencia, los resultados dependen exclusivamentedel tamaño de bloque, no de su geometría.La desactivación de la caché L1 reduce el tamañode los segmentos de transacción a una cuarta parte.Por tanto, en patrones dispersos o aleatorios dondeapenas exista reutilización de segmentos, un menortamaño de estos disminuye el tráfico de datos entrelas distintas memorias y alivia los cuellos de botella.En el caso de accesos dispersos regulares se consigueuna mejora de rendimiento de entre 20-40 % para diferentestamaños de bloques. Para los accesos aleatorios,la mejora no es significativa ya que la alta cargacomputacional en los warps se solapa con los tiemposde trasferencia.VII. Trabajo relacionadoLa estrategia más común a la hora de implementarun código CUDA es seleccionar bloques de hiloscuyos tamaños consigan maximizar la ocupación delos SMs. El objetivo de maximizar la ocupación esreducir las latencias en los accesos a memoria global[1]. Este trabajo sigue la tendencia habitual deseleccionar bloques cuadrados cuyas cardinalidadesson potencias de dos con el objetivo de facilitar laimplementación de los códigos. El impacto de geometríasno cuadradas, así como las cardinalidades delas dimensiones correspondientes a potencias de tres,JP2011-684

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ColumnsRows 32 48 64 96 128 192 256 384 512 768 1 0241 1,1087 0,9048 0,7893 0,6852 0,6582 0,6268 0,6358 0,6312 0,6330 0,6635 0,7885TABLA IReducción de vector. Execution times (ms.)ColumnsRows 8 12 16 24 32 48 64 96 128 192 256 384 512 768 1 024128 9.0196 6.3564 5.49 5.48 5.7848 5.24 5.60 4.0032 4.86 4.80 3.36 3.88 4.2324 4.70 4.68 3.28 4.17 3.0716 5.05 4.43 3.23 3.45 3.04 3.38 4.1412 5.42 4.58 3.28 3.55 3.02 3.43 3.058 6.05 4.97 3.42 3.41 2.96 3.05 2.95 3.17 4.456 7.18 5.52 3.87 3.53 2.95 3.06 2.94 3.46 3.194 9.70 6.73 5.06 3.92 3.11 3.10 2.90 3.00 3.05 3.19 4.443 11.94 8.48 6.16 4.64 3.53 3.12 2.89 2.96 2.95 3.35 3.182 16.43 11.43 8.55 6.12 4.54 3.68 3.08 2.93 2.93 2.95 2.96 2.99 3.951 29.97 20.24 15.16 10.51 7.74 5.73 4.40 3.49 3.08 2.89 2.89 2.91 2.94 3.01 3.94TABLA IISuma de matrices. Execution times (ms.)ColumnsRows 32 48 64 96 128 192 256 384 512 768 1 02432 644124 584216 5218 6094 657912 5121 6478 59798 4982 5862 5265 5479 64706 4860 5775 5293 5940 54574 6177 4746 4855 4898 4915 4743 60663 7960 5918 4653 4928 4649 5421 45202 11890 8121 6103 4415 4339 4325 4450 4288 61721 23730 16086 12073 8399 6967 5855 5866 5909 6120 5951 7223TABLA IIImultiplicación de matrices. Execution times (ms.)ColumnsRows 8 12 16 24 32 48 64 96 128 192 256 384 512 768 1 024128 12.896 12.664 12.5 12.6 12.648 12.4 12.4 12.532 12.2 12.3 12.3 12.3 12.324 12.1 12.1 12.1 12.1 12.116 11.8 11.9 11.9 12.0 12.0 12.0 11.912 11.6 11.7 11.8 11.8 11.8 11.8 11.88 11.2 11.4 11.5 11.7 11.7 11.7 11.7 11.7 11.66 10.8 11.1 11.2 11.5 11.6 11.6 11.6 11.5 11.64 11.5 11.5 11.5 11.1 11.3 11.5 11.5 11.5 11.5 11.5 11.23 10.2 10.4 10.5 10.9 11.0 11.3 11.4 11.4 11.4 11.3 11.42 10.2 9.9 10.0 10.5 10.6 11.0 11.1 11.3 11.4 11.3 11.3 11.3 10.91 12.8 11.4 10.0 9.7 9.9 10.4 10.5 10.8 11.0 11.3 11.3 11.3 11.2 11.2 11.1TABLA IVAccesos regularmente dispersos. Execution times (ms.)JP2011-685

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011ColumnsRows 32 48 64 96 128 192 256 384 512 768 1 02432 *24 347.2716 388.41 345.63 *12 334.81 367.85 347.798 330.47 332.90 388.28 347.56 *6 324.86 325.46 334.77 369.78 347.234 325.50 347.18 330.47 334.99 388.41 347.18 *3 328.07 357.41 324.82 327.35 334.75 369.59 347.302 370.40 326.11 325.48 324.88 330.43 334.72 388.42 347.17 *1 634.43 490.32 370.41 328.04 325.47 324.82 330.43 334.80 388.49 347.45 *TABLA VAccesos aleatorios. Execution times (ms.)no están suficientemente estudiadas.Wynters, en [6], muestra una implementación trivialde la multiplicación de matrices donde se pruebanvarios tamaños de bloques. Este es otro ejemplodonde no se consideran las geometrías rectangulares.Además, este trabajo está basado en arquitecturaspre-Fermi.En [7] y [8] se muestran implementaciones de variosproblemas variando una serie de parámetros significativostales como el tamaño de bloque, el tamañode los datos de entrada, la precarga de datos y lacarga de trabajo por hilo entre otros. La informacióndel rendimiento obtenido en estas pruebas se analizapara reducir el espacio de búsqueda y ayudar alprogramador a seleccionar la configuración óptima.De nuevo, este trabajo sólo considera arquitecturaspre-Fermi.Sobre Fermi, en [9], muestra cómo la jerarquíade memoria caché introducida por esta arquitecturamejora significativamente la localidad de los datosaumentando el rendimiento global de las aplicaciones.Sin embargo, este trabajo no estudia como serelacionan los efectos producidos por las memoriascaché con los diferentes tamaños y geometrías de losbloques de hilos.VIII. ConclusionesHoy en día desarrollar códigos que consigan explotareficientemente las capacidades de los dispositivosGPU sigue siendo un trabajo muy complicado ya quees necesario conocer estrechamente la arquitectura decada dispositivo.Una de las decisiones más importantes a la horade desarrollar códigos para estos dispositivos esla elección apropiada de los parámetros globales deconfiguración. Dichos parámetros incluyen el tamañoy la geometría del bloque, así como configuración lamemoria caché L1. Estas elecciones presenta un impactosignificativo sobre el rendimiento global de lasaplicaciones, explicables a partir de las característicasde la arquitecta del dispositivo GPU.La arquitectura Fermi introduce nuevas característicashardware que impiden reutilizar el conocimientoadquirido con las versiones anteriores. Estetrabajo presenta un estudio y evaluación inicial dela arquitectura Fermi para ayudar a determinar laconfiguración óptima.La elección de los parámetros globales están estrechamenterelacionados con la implementación decada problema. En este artículo mostramos que unestudio combinado del conocimiento de la arquitecturaGPU y las características propias de la implementacióndel código puede significativamente ayudar enla elección del tamaño y la geometría del bloque dehilos, así como en la configuración de la memoriacaché L1.AgradecimientosEsta investigación está parcialmente financiadapor el Ministerio de Industria (CENIT MARTA,CENIT OASIS, CENIT OCEANLIDER), Ministeriode Ciencia y Tecnología (CAPAP-H3 network,TIN2010-12011-E) y el proyecto HPC-EUROPA2(N o :228398).Referencias[1] David B. Kirk and Wen-mei W. Hwu, Programming MassivelyParallel Processors: A Hands-on Approach, MorganKaufmann, Feb. 2010.[2] NVIDIA, “Whitepaper: NVIDIA’s next generationCUDA compute architecture: Fermi,” 2010,http://www.nvidia.com/object/fermi architecture.html,Last visit: Nov, 2010.[3] NVIDIA, “Fermi Architecture HomePage,” Last visit: August 2, 2010,http://www.nvidia.com/object/fermi architecture.html.[4] NVIDIA, “Nvidia cuda programming guide 3.0 fermi,”2010.[5] Paulius Micikevicius Greg Ruetsch, “Nvidiaoptimizing matrix transpose in cuda,”http://developer.download.nvidia.com/compute/cuda/3 0/sdk/website/CUDA/website/C/src/transposeNew/doc/MatrixTranspose.pdf, June 2010, Last visit: Dec 2,2010.[6] Erik Wynters, “Parallel processing on nvidia graphics processingunits using cuda,” J. Comput. Small Coll., vol. 26,pp. 58–66, January 2011.[7] Shane Ryoo, Christopher I. Rodrigues, Sam S. Stone,John A. Stratton, Sain-Zee Ueng, Sara S. Baghsorkhi,and Wen-Mei W. Hwu, “Program optimization carvingfor GPU computing,” Journal of Parallel and DistributedComputing, vol. 68, no. 10, pp. 1389–1401, Oct. 2008.[8] Sara S. Baghsorkhi, Matthieu Delahaye, Sanjay J. Patel,William D. Gropp, and Wen-mei W. Hwu, “An adaptiveperformance modeling tool for gpu architectures,” SIG-PLAN Not., vol. 45, pp. 105–114, January 2010.[9] Changyou Zhang Xiang Cui, Yifeng Chen and Hong Mei,“Auto-tuning dense matrix multiplication for GPGPUwith cache,” in Proc. ICPADS’2010, Shanghai, China,Dec. 2010, pp. 237–242.JP2011-686

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Estrategias de optimización en diferentesarquitecturas CUDA usando llCoMPRuymán Reyes, Juan José Fumero, Iván López, Francisco de Sande 1Resumen— Debido al uso cada vez más extendido deaceleradores hardware en entornos de Computaciónde Altas Prestaciones, científicos e ingenieros inviertenmucho tiempo optimizando códigos para estetipo de plataformas. Los fabricantes por su parte,producen nuevas versiones de estos dispositivos cadapocos años. La cuestión que se desprende de estoes: ¿merece la pena optimizar dichos códigos? ¿Oes preferible esperar a que la siguiente versión delhardware incremente el rendimiento de nuestros programas?En este trabajo se muestran los efectosde aplicar diferentes técnicas de optimización ampliamenteconocidas en tecnología de compiladores, aun conjunto de códigos, mostrando cómo afectan alrendimiento en las nuevas arquitecturas. Realizar unaoptimización manual de los diferentes códigos seríauna labor inasumible si no contáramos con alguna herramientade prototipado rápido, como llCoMP, que permiteque la generación de código se realice de formasemi-automática. Esperamos que tanto nuestro trabajoexperimental como las conclusiones obtenidasa raíz de él, sirvan de orientación a desarrolladoresCUDA.Palabras clave— GPGPU, CUDA, llc, optimizaciónI. IntroducciónLa Computación de Altas Prestaciones (CAP) estáevolucionando a pasos agigantados. El número dearquitecturas capaces de alcanzar altos rendimientosse ha incrementado notablemente [1] en los últimosaños.Simultáneamente el precio de estas arquitecturasse ha reducido, posibilitando construir sistemas conun coste muy razonable por GFLOP. Sistemas constituidospor varios nodos donde cada nodo está compuestoa su vez por varios procesadores multi-núcleoson comunes hoy en día. La llegada de aceleradoreshardware como las GPU incrementan el rendimientosin incrementar el coste por GFLOP.No obstante, el uso generalizado de máquinasheterogéneas multicore o manycore, con complejasjerarquías de memoria, requieren de desarrolladoresdedicados para extraer su máximo potencial.El pico de rendimiento teórico disponible en ellases difícilmente alcanzado con las herramientas y libreríasdisponibles en la actualidad. Si bien losusuarios con mayores necesidades de cómputo soncientíficos e ingenieros dedicados a resolver problemascomputacionalmente costosos, ellos no cuentancon la experiencia requerida para manejar las herramientasdisponibles para programar estas arquitecturasemergentes. Es clave para el avance de la cienciauna mejora sustancial en la programabilidad deestas arquitecturas, y facilitar a usuarios no expertosun uso más eficiente de las mismas.1 Dept. de E. I. O. y Computación Universidad de La Laguna,38271–La Laguna, Spain e-mail: {rreyes}@ull.esNo hay que olvidar que incluso es posible quelos desarrolladores expertos no estén adecuadamentepreparados para explotar adecuadamente estos sistemas.Por ejemplo, los aceleradores hardware comolas tarjetas gráficas, tienen una arquitectura variableentre diferentes versiones del mismo dispositivo. Sibien es cierto que el esquema global es el mismo, yque el modelo de programación de alto nivel es relativamentepoco variable entre versiones, no hay queolvidar que para extraer el máximo rendimiento decada nueva versión del dispositivo, el desarrolladordebe conocer todas sus peculiaridades.Tanto OpenMP como MPI no fueron diseñadospara la actual heterogeneidad de los sistemasdisponibles, y, aunque existen esfuerzos para mejoraresta situación ([2]), estos aún están lejos de convertirseen una solución estandarizada.La situación particular en el campo de los aceleradoresgráficos es más diversa. Aunque el estandar defacto para la programación de estos dispositivos hasido CUDA [3], a través de una interfaz C con extensionespropietarias, este está únicamente disponiblepara tarjetas del fabricante NVIDIA. Intel ha desarrolladosu propio lenguaje para aceleradores gráficos:ArBB [4]. Este nuevo lenguaje permite desarrollosSIMD más veloces y una fácil transformación de loscódigos existentes. OpenCL [5] pretende ser un estandarindependiente del fabricante, que intenta proporcionaruna interfaz común para la programaciónde distintos dispositivos heterogéneos. A pesar de suinmadurez, parece un firme candidato a convertirseen uno de los lenguajes estrella para programar unnúmero cada vez mayor de dispostivos hardware.El objetivo de este trabajo es usar nuestrolenguaje, llc, y su compilador, llCoMP, como herramientasde prototipado rápido para estudiar diferentescasos de optimización de bucles. El impactode estas optimizaciones en el rendimiento son usadaspara realizar una comparativa utilizando tres arquitecturasCUDA diferentes. Los resultados puedenservir como guía para los desarrolladores que buscanmejorar el rendimiento de sus programas usandoarquitecturas CUDA, elevando su productividad através de la reducción del tiempo dedicado al desarrollodel código fuente.Las dos contribuciones más importantes de estetrabajo son las siguientes:(1) Se revela como una de las primeras comparativasentre las nuevas FERMI y sus arquitecturaspredecesoras.(2) Se presenta llCoMP, una herramienta deprototipado rápido capaz de generar semiautomáticamentecódigo y optimizaciones paraJP2011-687

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011CUDA.El resto de este trabajo se organiza como sigue:En la sección II se hace un resumen de las principalescaracterísticas de llc. A continuación describen lasprincipales técnicas de optimización disponibles en ellenguaje en la sección III. En la sección IV se estudiala aplicación de algunas de estas optimizaciones acasos prácticos. Se muestran allí códigos de ejemploimplementados en llc así como algunos resultadoscomputacionales para que el lector se haga una ideade las características y posibilidades del lenguaje ysu compilador. Por último, se ofrecen algunas conclusionesy líneas de trabajo abiertas en la secciónV.II. El lenguage llc y su compiladorllc es un lenguage paralelo de alto nivel en el queel paralelismo se expresa mediante directivas de compilaciónal estilo de OpenMP. La mayor parte de lasdirectivas de éste son aceptadas, aunque se han hechoalgunos añadidos para aumentar la expresividadsemántica del lenguaje y permitir al desarrollador dellc expresar con mayor legibilidad las particularidadede su código.Nuestro propósito con llc y su compilador llCoMPno es incrementar la diversidad de lenguajes y entornosde programación disponibles para CAP. Alcontrario, presentamos una forma simple de desarrolloenfocado a diferentes arquitecturas para disminuirla brecha entre ingenieros de sistemas y desarrolladoresde aplicaciones CAP. Las extensiones dellc o las técnicas implementadas en llCoMP puedenservir de guía a desarrolladores mainstream de caraa la resolución de los problemas de programabilidadde los sistemas actuales.llCoMP es un compilador source-to-source que traducecódigo C anotado con directivas llc en códigoparalelo de alto nivel. Aunque llc soporta losconstructos paralelos más comunes - forall, sections,pipelines y task queues -, la nueva versión del backendde CUDA llCoMP solo soporta bucles forall,aunque otros constructos están bajo estudio paraser incluídas en futuras versiones. Puesto que todaslas directivas y cláusulas de OpenMP son reconocidaspor llCoMP, a partir de un mismo códigofuente pueden generarse diferentes binarios (secuencialo paralelos) dependiendo del compilador seleccionadopara traducir el código generado por nuestrocompilador.La nueva versión del compilador llc puede serconsiderada como un extractor de kernels de CUDAa partir de constructos OpenMP, aunque preferimosconsiderarla como una herramienta de prototipado.llCoMP representa una capa software intermediaentre llc y diferentes backends para este lenguaje.El compilador ha sido diseñado con el propósito deque abordar implementaciones para diferentes arquitecturasdestino no requiera demasiado esfuerzo.llCoMP se ha implementado usando Python con unenfoque orientado a objetos. Para el frontend, hemosusado el módulo pycparser [6] para construir una representaciónintermedia del código C. La arquitecturasofware desarrollada nos permite escribir un conjuntode transformaciones source-to-source que posibilitanla escritura de kernels CUDA a partir de la informaciónextraída del código llc original.Además del enfoque clásico del desarrollo de entornosde programación para CAP, donde la facilidadde uso está destinada al usuario, nuestra propuestatambién está dirigida a arquitectos de hardware.Creemos que un rápido desarrollo del backendes la clave para la adopción de una nueva arquitectura,y la implementación de una gran variedadde arquitecturas es esencial para la adaptación deun compilador. Si un nuevo backend para un compiladorse puede implementar en pocas semanas, elhardware se puede evaluar en menos tiempo por ungran número de usuarios, facilitando por tanto laadopción de un nuevo hardware.Para posibilitar un proceso rápido de construcciónde backends introducimos el concepto de plantillas.Las plantillas capturan los patrones paralelos máshabituales. El compilador se ayuda de un conjuntode herramientas que, partiendo de la representaciónintermedia y de un análisis del código fuente, permitengenerar códigos eficientes para la plataformadestino.llCoMP traduce el código de entrada a su árbolsintáctico (AST) correspondiente. Este AST setransforma posteriormente para convertirlo en unarepresentación intermedia. Sobre esta representaciónintermedia se trabajará para aplicar cualquier transformacióny así poder generar código CUDA, MPI,etc. Para poder hacer transformaciones, se usan algunospatrones de software. Por ejemplo, para buscarun nodo en el AST, se usa el patrón Filter. Unavez que se se ha encontrado un determinado nodo, sele puede aplicar un mutador que es la sustitución deese nodo por otro (patrón Mutator). Tras aplicar lastransformaciones necesarias mediante filtros y mutadores,el AST resultante se procesa mediante la claseWriter para producir el código correspondiente.Las transformaciones implementadas a través delpatrón Mutator pueden realizarse utilizando plantillasen lugar de implementarlas en código python.Una plantilla es un fragmento de código escrito enel lenguaje destino, que se modifica en función deciertos parámetros de entrada. Este código es interpretadoy traducido a la representación intermedia,y a continuación se inserta en el punto adecuado delAST. El diseño del backend utilizando plantillas decódigo facilitará la implementación futura de nuevosbackends.La inicialización y la reserva de memoria son operacionescomunes para todos los tipos de dispositivoshardware. Cada una de estas operaciones identificaun patrón y éste se implementa a través de una plantillade código. Para manipular estas plantillas e insertarnuevo código en el AST llCoMP agrupa esteconjunto de operaciones en una interfaz común. Actualmente,los patrones implementados son:• Inicialización del dispositivo:contiene tareasJP2011-688

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011como identificación del disposivo o la asignaciónde recursos.• Invocación del kernel: el código que se ha deparalelizar es extraído del código fuente llc yel compilador lo inserta en el punto especificadopor el arquitecto hardware.• Liberación de recursos.Aunque una implementación directa en CUDAsiempre obtendrá mejor rendimiento, hay ocasionesen las que puede resultar más productivo desarrollaren llc y obtener el código CUDA usando nuestrocompilador. Es más, si se necesita obtener unmayor rendimiento, se puede modificar manualmenteel código generado por nuestro compilador y así producircódigo más eficiente.III. Optimizaciones en el backend de CUDAllCoMP permite seleccionar la plataforma parala cual se generará código a través de la directivapragma omp target [7], cuyo parámetro es el identificadorde la plataforma: CUDA, MPI o SMP seleccionadapor el programador para el código destinode la región anotada. En caso de que el desarrolladorelija CUDA como plataforma destino podráhacer uso de diferentes optimizaciones disponibles enllCoMP.Para mantener la consistencia de memoria tras laejecución de una región paralela, llCoMP copia todaslas variables asociadas al ámbito de la región paralelahacia y desde la tarjeta gráfica. Este comportamientose puede modificar a través de las cláusulascopy in y copy out que permiten al programadorindicar explícitamente las variables que han de sercomunicadas, reduciendo de este modo las transferenciasde memoria.Revisamos a continuación las optimizaciones implementadasen la actualidad.A. Optimización de buclesLa optimización de bucles es un aspecto crucial ala hora de mejorar el rendimiento de cualquier aplicaciónparalela. llCoMP pone a disposición del programadortres tipos de optimizaciones sobre bucles:• Desenrollado. Mediante la directiva pragmaunroll el programador anota los bucles que hande ser desenrollados. La cláusula factor de estadirectiva indica el factor de desenrollado.• Intercambio. Supuesto que no hay dependenciasen el cuerpo de dos bucles anidados, el intercambiode bucles puede en ciertos casos mejorarel rendimiento. La directiva pragma llcinterchange permite en llc indicar al compiladorque intercambie entre sí dos bucles anidados.• Fusión. La cláusula COLLAPSE recibe comoparámetro un número positivo que indica alcompilador cuántos bucles debe fusionar antesde paralelizar el bucle resultante. El backend deCUDA genera kernels 2D para todos aquellosbucles anotados con esta cláusula.TABLA I: Plataformas utilizadas en los casos de estudioNombre Ilion Peco ZapeManuf. Intel Intel AMDModelo Q9500 E5520 Phenom 9550Núcleos 4 4 4Hilos 4 8 4L2 (Mb) 6 1 2L3 (Mb) - 8 2Reloj (GHz) 2.83 2.26 2.20Placa 9800GT C1060 GTX 480Memoria (Gb) 3 4 4B. Reducciones en paraleloLa cláusula de reducción que se puede añadir a ladirectiva pragma omp for señala al compilador quedebe inyectar código específico para llevar a cabo unareducción. llCoMP añade una plantilla genérica yoptimizada tomada de [8].C. Ajuste de los parámetros de ejecución del kernelEl número de hilos por bloque a la hora de ejecutarun kernel de CUDA debe ser escogido cuidadosamentepues puede influir de manera notable enel rendimiento.Los usuarios de llCoMP han de especificar elnúmero de hilos que ejecutarán un bloque de códigoparalelo. Usando esta información y, tras un análisisde los bucles, el compilador calcula el número de bloquesadecuado para ejecutar el kernel. El número dehilos se especifica mediante la variable de entornoLLC GPU NUM THREADS.IV. Casos de estudioCon el fin de estudiar diferentes técnicas de optimizaciónde bucles en arquitecturas CUDA, presentamosla implementación en llc de tres aplicaciones:Mandelbrot, Jacobi y una simulación de dinámicamolecular. El código fuente de estos ejemplos estádisponible en la web del proyecto [9]. Todos loscódigos operan con números flotandes de doble precisión.Las ejecuciones se han realizado en tres plataformasdiferentes detalladas en la tabla I. Nótese quecada sistema es completamente diferente. En lasgráficos se ha medido el tiempo de ejecución delos kernels de CUDA sin contabilizar las transferenciasde memoria (excepto cuando el problema lo requiere).En algunos resultados se compara tambiénla diferencia de rendimiento entre ejecutar un códigoOpenMP en la CPU y el código CUDA correspondienteejecutado en la GPU. Nuestro propósito esmostrar la importante mejora obtenida añadiendouna tarjeta gráfica a un pequeño multiprocesador.Además, el consumo de esta combinación de multiprocesador+aceleradortiene potencialmente un consumomenor que un sistema multinodo de equivalentepotencia.JP2011-689

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011A. Cálculo del área del conjunto de MandelbrotEl conjunto de Mandelbrot es el dominio de convergenciade la serie compleja Z n = Z n−1 2 + C.Usando el método Monte-Carlo, el algoritmo del Listado1 calcula una estimación de dicha área.Cando llCoMP genera el código CUDA, localizaregiones paralelas precedidas por la directiva omptarget seguida de la indicación CUDA (línea 1).Una vez detecteda esta situación, el compiladorañade los patrones de transferencia de datos en elcódigo generado y encapsula el cuerpo del bucle enun kernel de CUDA. Finalmente, se insertan los patronesde lectura de datos y liberación de recursos.En el código se puede ver, por ejemplo, como seutiliza la cláusula reduction de OpenMP, que activarála generación de un kernel especializado parareducción en el momento de la traducción, tal ycomose comentó en la sección III.El kernel implementado en llCoMP [8] usa direccionamientosentrelazados y realiza la primera sumamientras se cargan los datos desde la memoria global.Estas mejoras aprovechan el dispositivo para realizarla reducción y minimizan la cantidad de informaciónque requiere ser transferida entre host y dispositivo.lanzamiento del kernel (hilos, número de bloque ycantidad de memoria compartida por bloque). Laúnica herramienta proporcionada por NVIDIA paraeste propósito es la calculadora de ocupación deCUDA [10]. La Figura 1 muestra cómo difieren estosparámetros de una tarjeta a otra. Nuestra experienciasugiere que encontrar la combinación óptima noes trivial.B. Método de JacobiUna cuestión clave en CUDA para mejorar elrendimiento es reducir las transferencias de datos entreel host y el dispositivo.Listado 2: Bucle de Jacobi realizado en llc/OpenMP1 while ((k < maxit ) && ( error > tol )) {2 error = 0.0;3 # pragma omp target device ( cuda )copy_in (uold , f, u) copy_out (u)4 # pragma omp parallel shared (uold , u,...) private (i, j, resid )5 {6 # pragma omp for7 for (i = 0; i < m; i ++)8 for (j = 0; j < n; j ++)9 uold [i][j] = u[i][j];10 # pragma omp for reduction (+: error )11 for (i = 0; i < (m - 2); i ++) {12 for (j = 0; j < (n - 2); j ++) {13 resid = ...14 ...15 error += resid * resid ;16 }17 }18 }19 k ++;20 error = sqrt ( error ) / ( double ) (n * m);21 }Fig. 1: Comparativa, en tres arquitecturas distintas,del tiempo de cómputo del área del conjunto deMandelbrot usando distinto número de hilos para untamaño de problema de 16384 puntos.La Figura 1 muestra, para las tres plataformasCUDA examinadas, el tiempo de ejecución necesariopara calcular el área del conjunto de Mandelbrot variandoel número de hilos por bloque.Es importante resaltar que, para un dispositivodado, incrementar la ocupación de los multiprocesadorespuede resultar una mejor manera de optimizarel rendimiento que usar un elevado númerode hilos. Aunque pueda resultar contrario a la intuición,en algunas situaciones, se ha obtenido unmejor rendimiento con un pequeño número de hilosen relación con el tamaño del bloque. Con unmenor número de hilos, un mayor número de bloquespueden ser asignados al mismo multiprocesadory, por consiguiente, más bloques pueden ser ejecutadosconcurrentemente.Esta es una de las razones por las que es tan importanteelegir cuidadosamente los parámetros deEl código del Listado 2 es el bucle del método deJacobi en llc y OpenMP. En la línea 3 se especificael dispositivo sobre el que se ejecutará el bucle paralelode las líneas 7 a la 11. Las cláusulas copy iny copy out de la directiva de la línea 3 indican lasregiones de memoria que serán transferidas a y desdeel dispositivo.Fig. 2: Aceleración del código Jacobi para distintostamaños de entrada (Las dimensiones de las matricesson N × N), usando la Tesla C1060La figura 2 mide el impacto en el rendimiento deesta característica de llc comparando una imple-JP2011-690

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Listado 1: Cálculo del áera del conjunto de Mandelbrot llc1 # pragma omp target device ( cuda ) copy_in (c)2 # pragma omp parallel for reduction (+: numoutside ) private (i,j,ztemp ,z) shared (nt ,c)3 {4 numoutside = 0;5 for (i = 0; i < npoints ; i ++) {6 z. creal = c[i]. creal ;7 z. cimag = c[i]. cimag ;8 for (j = 0; j < MAXITER ; j ++) {9 ztemp = (z. creal * z. creal ) - (z. cimag * z. cimag ) + c[i]. creal ;10 z. cimag = z. creal * z. cimag * 2 + c[i]. cimag ;11 z. creal = ztemp ;12 if (z. creal * z. creal + z. cimag * z. cimag > THRESOLD ) {13 numoutside ++;14 break ;15 }16 } /* for j */17 } /* for i */18 }mentación pura en OpenMP (8 hilos, uno por core)con el código CUDA generado por llCoMP especificando(etiqueta CUDA v2) las transferencias dememoria con dichas cláusulas y sin hacerlo (etiquetaCUDA v1).En nuestra estrategia de traducción sincronizamoslas memorias de host y dispositivo al final de cadaregión paralela. Dentro de una región paralela asumimosque las posiciones de memoria ubicadas en elhost no cambian.El bucle anidado del método de Jacobi es un buencandidato a optimizarse utilizando fusión de bucles.Cuando el backend CUDA de llCoMP encuentradicha cláusula genera un kernel 2D. La coordenada xrepresenta el primer bucle y la coordenada y representalas iteraciones del segundo bucle. Esta implementaciónproduce hilos CUDA más ligeros, reducelos conflictos en el acceso a memoria e incrementala granularidad. Sin embargo, debe ser escogida concuidado la configuración para lanzar el kernel paramejorar el rendimiento, como se puede observar enla Figura 3. Los resultados computacionales que utilizanintercambio de bucles no producen mejoras significativasdel rendimiento.C. Dinámica molecular (MD)El código MD calcula la energía y fuerzas de unsistema formado por N partículas. El problema requierenumerosas iteraciones para obtener una aproximacióna la solución, cuya exactitud está determinadapor el incremento temporal escogido para lasimulación.En cada paso de la simulación el algoritmo realizados operaciones básicas: calcular y actualizar. Laactualización se realiza mediante un bucle for queactualiza las posiciones, velocidades y aceleracionesde las partículas.Desde el punto de vista computacional, la rutinade cálculo es más costosa que la de de actualización.Con este problema pretendemos estudiar la mejorcombinación GPU/CPU para el código paralelo. Denotandoa la CPU con C y a la GPU con una G.Hemos medido el rendimiento de cuatro versiones diferentesdel código:CC: las dos rutinas en la CPU (código puroOpenMP)GG: las dos rutinas en la GPU (código puroCUDA)GC: cálculo en la GPU y actualización en la CPUCG: cálculo en la CPU y actualización en la GPUFig. 3: Aceleración en el código Jacobi usando lacláusula COLLAPSE(2). Los parámetros óptimos paraejecutar el kernel dependen de la arquitectura.Fig. 4: Aceleración del código MD para diferentesestrategias de paralelización usando Tesla C1060 yocho hilos OpenMPJP2011-691

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011La figura 4 muestra la aceleración obtenida paratres tamaños diferentes del problema (número departículas, np). El mejor rendimiento se da cuandolas dos rutinas se ejecutan en la GPU. Para loscódigos híbridos OpenMP/CUDA, la mejor elecciónes alojar la parte más costosa en la GPU.A este código se le pueden aplicar una gran variedadde optimizaciones. Una de las más obvias esdesenrrollar los bucles en la rutina de cálculo. Otraposibilidad es fusionar los bucles de la función de actualizacióndado que hace un uso intensivo de memoriay se reduciría el número de accesos a ésta por hilo,disminuyendo así las posibilidades de conflicto. Enla gráfica 5 se observan, para cada arquitectura, losefectos de las diferentes optimizaciones. Para cadaarquitectura se buscó la mejor configuración posiblepara ejecutar el kernel del algoritmo.Fig. 5: Mejoras en el rendimiento usando desenrolladoy fusión de bucles en las arquitecturas evaluadasV. Conclusiones y líneas de trabajoabiertasDurante los últimos años, las arquitecturas compatiblescon CUDA han sufrido una gran evolución,siendo constante la mejora en el rendimiento. Sinembargo, parte de los trabajos de optimización realizadospara las primeras arquitecturas compatiblesse revelan ahora como ineficaces, ya que en versionesmás recientes no son necesarias, ya sea por la incorporaciónde memorias adicionales, o por la posibilidadde ejecutar con un mayor número de threads.Los desarrolladores interesados en los aceleradoreshardware deberían centrar sus esfuerzos en técnicasavanzadas de optimización que pudieran ser útiles enversiones futuras de la arquitectura. En particular,utilizar kernels 2D para operar con matrices pareceuna buena forma de mejorar el rendimiento de loscódigos en nuevas arquitecturas.Nuestro estudio se ha visto enormemente facilitadogracias al uso de llCoMP. Sin esta herramienta, elesfuerzo requerido para implementar los códigos presentadosen la sección anterior y sus optimizacionesen las diferentes arquitecturas nos hubiese impedidopresentar los resultados a tiempo para ser útiles.Las distintas técnicas de optimización implementadas(o pendientes de finalizarse en el momentode la escritura de este trabajo) en el nuevo backenddel compilador de llc permiten testear fácil yrápidamente diferentes técnicas de optimización paracualquier código. La pérdida de rendimiento con respectoa una implementación directa en CUDA estáclaramente justificada por la significativa reduccióndel esfuerzo de desarrollo.Además, el uso de llCoMP permite descubrirfácilmente la técnica de optimización más adecuada,lo que redunda en un aumento de la productividaddel desarrollador. Nuestro compilador está diseñadopara ser flexible y portable. Esperamos además quecon la experiencia adquirida durante el desarrollo delbackend de CUDA la incorporación de nuevos backend(como OpenCL, por ejemplo) no requiera demasiadosesfuerzos.Actualmente trabajamos en los siquientes aspectos:• Incrementar el número de algoritmos paralelizadosusando llCoMP, prestando especial atencióna aquellos que tengan una aplicación prácticareal.• Estudiar e implementar nuevas optimizacionesque permitan mejorar el rendimiento del códigogenerado.AgradecimientosEste trabajo ha sido parcialmente financiado porla UE (FEDER), MEC (proyecto TIN2008-06570-C04-03) y el Gobierno de Canarias (ACIISI, proyectoSolSubC200801000285). Los resultados computacionaleshan sido obtenidos usando los sistemas delgrupo HPCA de la UJI.Referencias[1] André Rigland Brodtkorb, Christopher Dyken, Trond R.Hagen, Jon M. Hjelmervik, and Olaf O. Storaasli, “Stateof-the-artin heterogeneous computing,” Scientific Programming,vol. 18, pp. 1–33, 2010.[2] Ayguadé, E. et. al., “Extending OpenMP to survivethe heterogeneous multi-core era,” International Journalof Parallel Programming, vol. 38, no. 5-6, pp. 440–459,2010, cited By (since 1996) 0.[3] John Nickolls, Ian Buck, Michael Garland, and KevinSkadron, “Scalable parallel programming with CUDA,”Queue, vol. 6, no. 2, pp. 40–53, 2008.[4] Intel, “Sophisticated library for vector parallelism: Intelarray building blocks,” 2010.[5] Khronos Group, “OpenCL the open standard for parallelprogramming of heterogeneous systems,” 2008.[6] Eli Bendersky, “Pycparse,” 2009.[7] Ayguadé, E. et. al., “A proposal to extend the OpenMPtasking model for heterogeneous architectures,” inIWOMP’09, Dresden, Germany, 06/2009 2009, Springer,vol. 5568, pp. 154–167, Springer.[8] M. Harris, “Optimizing parallel reduction in CUDA,”2007.[9] “llc Home Page,” 2011, http://llc.pcg.ull.es.[10] NVIDIA Corp., “Cuda occupancy calculator, 2007.,”2007.JP2011-692

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Sistema modular desarrollado en FPGA, para elcálculo de mapas de disparidad de imágenesestereoscópicas.Salvador Ibarra 1 , J. Ignacio Benavides 2 y M. Hernández Calviño 3Resumen— La solución del problema decorrespondencia, para encontrar la profundidad de loscomponentes de una escena a partir de dos imágenes, esfundamental en los sistemas de visión estereoscópica.Este problema ha sido extensamente estudiado dandocomo resultado le creación de una gran cantidad dealgoritmos de correspondencia estereoscópica. Decidirque algoritmo debe ser utilizado depende de laaplicación particular, debiendo hacer una evaluaciónobjetiva en cuanto a la precisión, tiempo de cómputo yrecursos utilizados que demanda la aplicación. Con eldesarrollo de nuevas tecnologías de hardware como es elcaso de los FPGAs, se ha creado un enorme interés enimplementar, sobre ellas, aplicaciones de visiónestereoscópica para sistemas de tiempo real. En el marcodel diseño e implementación de un sistema de visiónestereoscópica que pueda ser integrado en un dispositivoautónomo móvil, resulta necesario desarrollaraplicaciones que permitan evaluar que tipo dealgoritmos presentan mejores características cuando sonimplementados en hardware. Aquí presentamos unsistema que permite evaluar, de manera sencilla yeficiente, diferentes algoritmos de correspondenciaestereoscópica. Los resultados obtenidos indican que laherramienta diseñada proporciona informaciónsuficiente para evaluarlos en dos aspectos básicos, suoperación y los recursos utilizados. La herramienta debede ser todavía mejor optimizada para obtener resultadosprecisos del tiempo de cómputo, sobre todo parasistemas de tiempo real.Palabras clave— Correspondencia estereoscópica,FPGA, Controlador de Memoria.EI. INTRODUCCIÓNl uso de la visión estereoscópica para recuperarinformación tridimensional de una escena y calcularla profundidad de la misma, se ha convertido en un temade interés en los últimos años en el campo de la visiónartificial. Sus características en términos de fiabilidad,exactitud, costo, rangos de operación, la han convertidoen un método ampliamente usado en áreas como larobótica, vehículos autónomos no tripulados,aplicaciones de seguridad, interface hombre máquina,entre otros.1 Unidad Académica de Ingeniería Eléctrica, Universidad Autónoma deZacatecas, Zacatecas,México, e-mail:sibarra@intranet.uaz.edu.mx.2 Depto. De Arquitectura de Computadores, Electrónica y TecnologíaElectrónica, Escuela Técnica Superior, Universidad de Córdoba,Córdoba, España, e-mail: el1bebej@uco.es.3 Facultad de Física, Universidad de la Habana, La Habana, Cuba,email: mhernan@fisica.uh.cu.Existen una gran cantidad de sistemas que debido a suscaracterísticas, deben de realizar el cálculo de laprofundidad de la escena en tiempo real. Por ejemplo unsistema de navegación implantado sobre un dispositivoautónomo móvil debe de ser capaz de analizar el estadode una escena en el orden de milisegundos, con elpropósito de que su módulo de navegación pueda tomardecisiones y evadir los obstáculos que se interponenentre él y la meta a alcanzar.El presente proyecto tiene como objetivo, desarrollaruna plataforma modular que permita evaluar diferentesalgoritmos, implementados en hardware decorrespondencia estereoscópica, de tal forma que searelativamente sencillo el cambio de métrica deevaluación de la correspondencia estéreo. El resto deldocumento está dividido de la siguiente manera: En lasección 2, se muestran y discuten los resultados deimplementaciones previas. La sección 3, describe lascaracterísticas de la visión estereoscópica y dada lanecesidad del uso de los bancos de memoria externa a laFPGA, la utilización de los controladores de memoria,que tienen los FPGAs de la presente generación, dadaslas características de las placas de desarrollo actuales. Lasección 4, muestra cómo fue diseñado el sistema y lainteracción de sus partes. La sección 5, muestra yexplica los resultados del desarrollo e implementaciónde los elementos del proyecto, así como de suintegración final. La sección 6, discute los resultadosobtenidos. La sección 7, dentro del marco de un trabajoincremental, se propone diferentes alternativas quepermitan el desarrollo de un sistema que evalúeeficientemente la aplicación de los algoritmos decorrespondencia estereoscópica en sistemas de tiemporeal.II.MARCO CONCEPTUALA. Geometría del Sistema EstereoscópicoEl uso de la visión estereoscópica es una alternativapara encontrar la profundidad de una escena basada enun par de imágenes cuyos centros ópticos se encuentranseparados ligeramente entre sí. La separación que existeentre dos puntos correspondientes en el par de imágenesestereoscópicas, permite conocer la distancia a la que seencuentran los objetos del centro óptico de los sensoresde visión. En la medida que los objetos estén más cercadel centro óptico de los sensores, se encontraran másseparados en las respectivas imágenes estereoscópicas.Conociendo los parámetros de las cámaras y habiendoencontrado la distancia que separa un punto en un par deimágenes estereoscópicas, la profundidad del mismoJP2011-693

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011puede ser calculada obteniendo el inverso de ladisparidad calculada para ese punto. En la figura 1 setiene que C L y C R representan los centro ópticos de lascámaras derecha e izquierda respectivamente, X L y X Rrepresentan la distancia del centro óptico reflejado en laimagen al lugar donde el punto es reflejado en la imagenrespectiva, T es la distancia entre las dos cámaras y f esla longitud focal de la cámara. Entonces la disparidaddel punto P está dada pord = X L - X R (1)Para determinar la profundidad de la escenatridimensional usando los puntos de disparidad quecorresponden a ambas imágenes, basados en lageometría de la cámara, se puede usar la siguienteexpresión.Z = f ∙ (T/d) (2)Entonces dado lo anterior, el problema fundamentalconsiste en encontrar la correspondencia exacta entredos puntos. La correspondencia estereoscópica es elproceso por el cual dado un punto en la escena 3-D sellega a determinar cuál es su proyección en sendasimágenes del par estereoscópico. Existen diferentestécnicas para encontrar la correspondenciaestereoscópica, las cuales se dividen principalmente entécnicas basadas en el área de las imágenes y técnicasbasadas en las características de las imágenes. Delmismo modo existen diferentes métricas para el cálculode dicha disparidad. Algunas de estas pueden serfácilmente paralelizadas e implementadas en hardwarede tal modo que permiten al análisis de sistemas entiempo real, tal es el caso de la métrica de Suma de losvalores absolutos de las diferencias.Fig. 1 Geometría de un sistema estereoscópicoFuente (V. Simhadri, 2009)B. Controladores de Memoria ExternaCada día es más común encontrar desarrollosde sistemas de visión estereoscópica basados en FPGA,lo que no es de extrañar dadas las excelentescaracterísticas que éstas proveen para el desarrollo deeste tipo de sistemas. Por otro lado, existen aplicacionesque requieren del uso de grandes cantidades dememoria, siendo insuficiente la memoria que proveenlos FPGAs, por lo que resulta común hoy en día,encontrar tarjetas de desarrollo que adicionan memoriasde última generación. Así mismo los FPGAs, proveencores controladores de memoria para su uso.En los sistemas actuales los circuitos lógicosprogramables, tienen la capacidad de conectarse con unagran variedad de tipos de memoria como pueden ser,SDRAM, DDR, DDR2, DDR3, entre otras. Dado queresulta complicado el desarrollo de controladoresespecíficos para cada tipo de memoria, las compañíasdesarrolladoras de dispositivos lógicos programables,han optado por desarrollar controladores de memoriaque le permitan al usuario un acceso sencillo y eficientea memoria. Tal es el caso de Xilinx que ha desarrolladoel Multi-Port Memory Controller (MPMC) que permiteel acceso a memoria por parte diferentes procesadores operiféricos implementados al interior del FPGA [9].El MPMC es un controlador de memoria multipuerto,que dependiendo del tipo de FPGA en que seimplemente puede controlar hasta 8 puertos. Cada unode estos puertos puede ser parametrizable y se puedeseleccionar por cada puerto hasta siete interfacesdiferentes de comunicación. El MPMC actúa como elcontrolador y el árbitro que permite en un momentoespecífico la interacción de uno de los ocho puertos conla memoria, por medio de elementos FIFO de cadapuerto. Cada una de las interfaces de comunicaciónpermite diferentes modos de acceder a la memoria, perouna vez que el MPMC por medio de sus líneas decontrol, indica que tiene atrapados la dirección y el dato,el dispositivo asociado a éste puede enviar o solicitar elsiguiente dato.Una de las interfaces provistas por el MPMC, es laNative Port Interface (NPI), que es la interface nativadel controlador, permite transferencia de datos en 32 o64 bits, y diferentes modos de transferencia como son elmodo sencillo, modo burst y el modo de cacheline,permitiendo de forma simultánea la lectura y escriturade datos de los FIFOs del controlador. Por lo sencillo deesta interface puede ser prácticamente adaptada a casicualquier protocolo de comunicación.III.TRABAJOS PREVIOS RELACIONADOSSi bien en los últimos años se han desarrollado unconjunto de propuestas Software, para la solución delproblema de correspondencia estereoscópica, el avanceen las tecnologías de los dispositivos lógicosprogramable, especialmente las FPGAs, ha permitidoque se desarrollen una serie de propuestas hardware,basadas en ellas, debido a las características que estospresentan tales como: su capacidad de cómputo enparalelo, su capacidad de reconfiguración y laposibilidad de utilizar bloques de memoria interna comoelementos de almacenamiento de imágenes. Estaspropuestas hacen énfasis en aspectos en los que eldesarrollo de sistemas de visión estereoscópica basadosen FPGA permite ayudar, especialmente si estos seránutilizados en aplicaciones de tiempo real. En [1] sepresenta un algoritmo de correspondencia estéreoimplementado en hardware. Utilizando como métrica decosto y agregación la suma de los valores absolutos delas diferencias. Posteriormente, el resultado es refinadoJP2011-694

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011por medio de un proceso que utiliza un autómata celular.Los resultados muestran que el algoritmo puede serimplementado eficientemente en hardware y que elcálculo de la profundidad de las escenas se ajusta a lostiempos demandados por sistemas de tiempo real. En[2], se presenta un sistema de tiempo real desarrolladoen hardware para la extracción del mapa de profundidad,su propuesta utiliza el filtro de la mediana para elcálculo de predicciones y decidir qué tan parecido es unframe con respecto al anterior, de tal modo que puedenminimizar el tiempo de cómputo, los resultados indicanque el consumo de tiempo es 56 veces menor conrespecto a la misma implementación realizada ensoftware.La implementación del algoritmo de suma de losvalores absolutos de las diferencias (SAD), en sistemasde tiempo real, para resolver el problema de encontrar lacorrespondencia estereoscópica, ha sido tratada pordiversos autores. En [3] se presenta el diseño de unaarquitectura basada en la FPGA de Altera Stratix IIusando ventanas de 4 x4 y profundidad de 90 pixeles. Sudiseño alcanza un procesamiento de 85 fps en imágenesde 1024 x 1024 pixeles. En [4], se presenta un sistemabasado en una FPGA de Xilinx Virtex II, que procesanimágenes provenientes de tres cámaras con tamaños deventana de 15 x 15 y rango de disparidad de 32 pixeles,alcanzando un procesamiento de 100 fps., sobreimágenes de 320 x 240 pixeles. En [5] utilizando unsistema basado en FPGA procesa imágenes de 512 x 512pixeles con una disparidad de 255 pixeles, usandotamaño de ventanas de 5 x 5, alcanzando unprocesamiento de 25.6 fps. Por su parte en [6], sepresenta una implementación que además de cumplircon los parámetros de los sistemas de tiempo real,muestra tener una buena exactitud, alcanzando unprocesamiento de 60 fps. sobre imágenes de 750 x 400pixeles con un rango de disparidad de 60 pixeles ytamaño de ventana de 23 x 23.La implementación de medidas no-paramétricas ensistemas de tiempo real es evaluada en [7] queimplementa la transformada no paramétrica Censussobre imágenes de 512 x 480 pixeles usando un rango dedisparidad de 52 pixeles y tamaño de ventana de 7 x 7,obteniendo un procesamiento de 200 fps. En [8] sepresenta una implementación basada en FPGA de latransformada no paramétrica Census con tamaño deventana de 7 x 7, con una disparidad máxima de 64pixeles, sobre imágenes de 640 x 480 pixeles,alcanzando en procesamiento de 130 fps.IV.ESTRUCTURA DEL PERIFERICOEl desarrollo de este trabajo, está fundamentado en lacreación de un conjunto de periféricos que son añadidosa un sistema controlado por el procesador embebidoMicroBlaze (MB) dentro de un FPGA Spartan 6 LX45Tde Xilinx. Aunque las funciones que realiza elprocesador sobre los dispositivos son mínimas, seprovee de una interface con la cual la interacción con losperiféricos es sencilla, aunado a esto se aprovechanrutinas de uso común desarrolladas en trabajosanteriores [10], [11].La figura 2 muestra el diagrama general del sistema,donde se puede observar al MB conectado por medio delProcessor Local Bus (PLB) al controlador serie RS232.Esta conexión tiene como principal objetivo, por unlado, tener un medio por el cual se puedan controlar losdiferentes dispositivos que se le conectan al sistema ypor otro, monitorear cuando así sea necesario, lasseñales provenientes de estos dispositivos.Fig. 2 Diagrama General del sistema de correspondenciaestereoscópicaSe ha desarrollado una interface hacia el controladorPLB, por medio de la cual se puede acceder hasta a 8registros diferentes de escritura de 32 bits cada uno, delmismo modo la interface provee la circuitería necesariapara poder leer un dato proveniente de uno de ochoregistros de entrada de 32 bits. Esta interface permiteindependizar los periféricos desarrollados, delcontrolador PLB. El acceso a los registros deentrada/salida de la interface se logra realizando unallamada a la dirección base más el desplazamiento delregistro. La figura 3 muestra el diagrama esquemático deeste módulo.Los trabajos anteriormente mencionados, logranalcanzar las frecuencias de procesamiento indicadas,debido principalmente a dos situaciones, 1- tienen unflujo de datos de entrada que no proviene de memoriasino de sensores ópticos y 2-utilizan elementos internosde la FPGA para almacenar el flujo de datos en pipeline.Fig. 3 Interface con el bus PLBJP2011-695

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Como se mencionó anteriormente el MPMC cumplecon el objetivo de ser la interfaz entre la memoriaexterna del sistema y los diferentes dispositivos querequieran de ella. En el sistema desarrollado se puedeobservar que se tiene acceso a la memoria externa pordos vías, una vía es por medio del controlador ProcessorLocal Bus (PLB) utilizado principalmente por el MBpara acceder a datos e instrucciones, la otra vía es por laNative Port Interface (NPI) que es utilizada por elperiférico encargado de generar las direcciones dememoria de donde se quieren tomar los datos de lasimágenes estéreo previamente almacenadas y donde sequiere guardar la información del mapa de disparidad,información generada por el módulo de cálculo de lasuma de las diferencias absolutas.Del mismo modo que se desarrolló la interface con elcontrolador PLB, se desarrolló una interface decomunicación con el controlador de memoria MPMC enel modo NPI de 32 bits. Esta interface permite lalectura/escritura en memoria externa una vez quepreviamente han sido registrados tanto la dirección delectura/escritura como el dato a ser enviado a memoria.En la figura 4, se observa esta interface. La máquina deestados genera las señales de control necesarias paraleer/escribir un dato de 32 bits en memoria por mediodel NPI, en el caso de la escritura toma 5 ciclos de relojen efectuarla, en el caso de la lectura el tiempo puedevariar siendo mínimo de 5 ciclos, esto se debe a que elcontrolador y por la política de arbitraje seleccionada(round robin), puede estar atendiendo las solicitudes delMB por el puerto PLB.disparidad. El otro módulo es el encargado de hacer alcálculo de la disparidad basado en un algoritmo queutiliza como métrica de medida la Suma del valorabsoluto de las diferencias (SAD).La generación de direcciones de memoria es realizadapor un módulo que consta de dos elementos como semuestra en la figura 5. El primer modulo genera lalógica necesaria para el cálculo de la coordenadas (x,y)del elemento que se desea almacenar o recuperar de lamemoria. El cálculo de estas coordenadas se efectúabasado en las necesidades de datos requeridos por losalgoritmos de cálculo de disparidad que obtienen mapasdensos. El segundo módulo genera la dirección efectivade memoria de donde el dato será recuperado oalmacenado, basado simplemente en una dirección basey las coordenadas del (x,y) del sistema. Por ejemplo, sise tiene una imagen sintética de 388 x 288 pixeles[tomada de, 13] y se desea recuperar el dato de lacoordenada (x=10, y=20) a partir de la memoria base88000000hex, el módulo realiza el cálculo mostrado enla figura 6, dando como resultado la dirección real dememoria 88019850hex que es de donde se tomará eldato.Fig. 5 Generador de dirección efectiva de memoriaFig. 4 Interface con el MPMC en el modo NPIUna vez que se han registrado la dirección y el datoque se desean leer/escribir en memoria, se manda unaseñal de inicio a la máquina de estados que controla elproceso, adicionalmente se le indica si el proceso que sequiere efectuar es de lectura o de escritura (LNE=1Lectura, LNE=0 Escritura). La máquina de estadosresponde que el proceso terminó satisfactoriamente conuna señal de LF=1 en caso de que el proceso sea delectura, o con una señal de EF=1 en caso del queproceso sea de escritura.El elemento principal del sistema, es un periférico quepermite calcular al mapa de disparidad de dos imágenesestéreo almacenadas en memoria. Este periférico estádividido en dos módulos, uno encargado de controlar ygenerar las direcciones de memoria para tomar los datoscon los que se calculará la disparidad, así como paragenerar las direcciones donde se almacenara el mapa deEl cálculo de la disparidad es realizado por el móduloque se muestra en la figura 7, este módulo cargainicialmente la ventana izquierda de 3x3 de acuerdo alos datos que le provee el puerto NPI a su vezalimentado por el generador de direcciones,posteriormente de la misma forma es cargada la ventanaderecha y se calcula la suma de diferencias absolutas,teniendo como resultado el primer mínimo,posteriormente se cargan tres elementos nuevos para lanueva ventana derecha y se calcula la segunda diferenciaabsoluta, este valor se compara con el anterior y si esmenor que el mínimo anterior, se ha encontrado unnuevo mínimo, el valor del mínimo y su posición sonalmacenados en registros para su posterior utilización,el proceso se repite para una disparidad máxima de 32posiciones. Una vez terminado el proceso, el resultadoes la posición donde se encontró la mínima diferenciaabsoluta. Este valor es almacenado en el mapa dedisparidad..Fig. 6 Cálculo de la dirección efectivaJP2011-696

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011V. RESULTADOS DE LA IMPLEMENTACIÓNLos periféricos desarrollados que integran el sistemafueron probados inicialmente de forma independiente yfinalmente fueron integrados en un sistema embebidocontrolado por el MB. El controlador de la interfacePLB fue probado exhaustivamente y se logro unacomunicación total con sus registros.Fig. 7 Cálculo de la Suma del valor absoluto de las diferencias y de lamínima diferenciaLa interface con el puerto nativo, permite queregistrados la dirección y el dato que se quiere escribir,se genere una señal de control que permita acceder amemoria externa y almacenar el dato, lo mismo se logrópara el proceso de lectura de datos. El hecho de registrarpreviamente la dirección y el dato, hace necesarioagregar un estado adicional a la máquina de estados quecontrola la interface, lo cual añade un ciclo de reloj alproceso de lectura/escritura de los datos.El periférico que calcula el mapa de disparidad, fuecomparado con una implementación desarrollada porsoftware con la misma plataforma, los resultadosmuestran que se logra obtener un mapa de disparidadsemejante, tal como se muestra en la figura 9. Se puedeobservar que existe un pequeño incremento de falsospositivos en la implementación por hardware debidoprincipalmente a la precisión de datos utilizados en estaimplementación. El desarrollo del periférico se realizósiguiendo el algoritmo SAD de forma estrictamenteprocedimental, sin ningún tipo de optimización. En unaprimera aproximación, tomando cada uno de los pixelesconforme estos se van necesitando y sin almacenar datosque puedan se reutilizados, los resultados obtenidosmuestran que la implementación hardware, si bien esmás rápida que la implementación de software, no logralos requerimientos mínimos necesarios para un sistemaque trabaje en tiempo real, ya que solo puede procesar1.17 fps teniendo imágenes de 384 x 288 pixeles, conuna disparidad máxima de 32 pixeles y un tamaño deventana de 3 x 3. Una segunda implementación,utilizando el modo de lectura de burst del NPI leyendo32 palabras, permite un acceso más eficiente a memoria.Los datos son almacenados en BRAM para tres líneas dela imagen, y los datos de las líneas inferiores sonreutilizados de tal forma que se realizan menos accesos amemoria de forma que reducen el cuello de botella, deforma que se pueden procesar 16.57 fps, tiemposuficiente para algunas aplicaciones de tiempo real. Esposible de forma sencilla duplicar o cuadruplicar elnúmero de frames por segundo, añadiendo estructuras enparalelo que permitan realizar el cálculo del SADmínimo en varias regiones de la imagen de formasimultanea.VI.CONCLUCIONESLas interfaces que se desarrollaron, tanto para elacceso al bus PLB, como para el acceso al puerto nativodel MPMC en su modalidad de 32 bits, dejan por unlado, interactuar de forma sencilla con estoscontroladores y por otro lado, en el momento de diseño,la manipulación de los controladores es más ordenada,permitiendo aislar efectivamente los elementos dediseño, con lo cual el proceso de detección y correcciónde errores (debugging) resulta menos complicado. Sibien el objetivo final del proyecto es desarrollar unsistema de visión que cumpla con los requisitos detiempo real, la herramienta, en su estado actual, resultaefectiva porque permite probar diferentes algoritmos,con el modelo desarrollado, aislando el acceso a losdatos del propio algoritmo. A partir de ahí se pueden sepuede comenzar a diseñar estrategias que permitanlograr el requisito de velocidad en los sistemas detiempo real.Fig. 9 Mapas de disparidad resultantes de las implementaciones desoftware y hardwareSe ha logrado una independencia entre lamétrica que se desea utilizar para el cálculo de ladisparidad de un sistema estéreo, y el módulo quegenera las direcciones de memoria donde están lasimágenes estereoscópicas. De este modo es posibleprobar una amplia variedad de métricas que generanmapas de disparidad densos, utilizando el mismomódulo de direccionamiento. Por otro lado es posible demanera rápida y sencilla cambiar el tamaño de lasimágenes y la disparidad con la cual se desea realizar elcálculo.En la primera implementación que se realizo enhardware, se puede observar claramente que el cuello debotella se encuentra en el acceso a memoria, debido alque el controlador consume por lo menos 5 ciclos dereloj en entregar un dato. Se puedo observar quecambiando de protocolo para el acceso a memoria yteniendo elementos de almacenamiento que permitan reusar datos que ya han sido previamente cargados, sepuede incrementar significativamente la cantidad deframes por segundo que se pueden procesar. Si a loanterior se le agregan arquitecturas en paralelo paracalcular el SAD mínimo en diferentes regiones de lasimágenes, el incremento aún es mayorJP2011-697

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Puesto que el objetivo del sistema que se presenta, esla evaluación de los algoritmos de correspondenciaestereoscópica en sistemas de tiempo real, en estemomento el sistema diseñado resulta una herramientaadecuada para probar diferentes métricas de visiónestereoscópica, así como también probar diferentesvalores de disparidad y tamaños de ventana, aunquecomo ya se explico no alcanza a procesar una imagencambiante en tiempo real por el cuello de botella queimpone la utilización del MPMC. Una vez analizadoslos algoritmos tanto en precisión como en consumo derecursos, se pasará a la etapa de optimización delsistemaVII.TRABAJO FUTUROPara el trabajo futuro se prevé expandir lasposibilidades del periférico, de forma tal que permitaconfigurar las características principales para el mapa dedisparidad como son, el tamaño de las imágenes, el nivelde disparidad, el tamaño de las ventanas entre otros.En el marco de referencia de desarrollar un sistema entiempo real que permita a un dispositivo autónomomóvil, navegar en un entorno desconocido, resultanecesario optimizar el periférico que calcula el mapa dedisparidad. Una de las posibles vías, es implementar unaarquitectura de memoria interna al FPGA, de tal modoque permita un acceso más eficiente a memoria y que reuseparte de los datos que ya han sido previamentecargados en el periférico.Conference on Computer Vision and PatternRecognitionWorkshps, 2006.[8] A. Naoulou, J. Boizard, J. Yves, M. Devy, “Analternative to sequential architectures to improve theprocessing time of the stereovision algorithms”,Proceedings of the International Conference on FieldProgrammable Logic and Applications”, 2006.[9] Xilinx, “Multi-Port Memory Controller (MPMC)(v6.02.a)”,http://www.xilinx.com/support/documentation/ip_documentation/mpmc.pdf, Xilinx, 2011.[10] M. Calviño, “Ambiente para la depuracion y pruebade aceleradores de hardware”, Jornadas de Paralelismo,Castellon, España, 2008[11] S. Ibarra, M. Calviño, J. Benavides, “Diseño yevaluación de un acelerador hardware configurable pararealizar la convolución, acoplado como periférico alMicroblaze”, XXI Jornadas de Paralelismo, Valencia,España, 2010[12] V. Simhadri, Y. Osturk, “RASCor: An associativehardware algorithm for real time stereo”, Computers andElectrical Engineering, Vol. 35, pp. 459-477, Elsevier,2009.[13] D. Scharstein, R. Szeliski, Middlebury StereoDatasets, http://vision.middlebury.edu/stereo/data/REFERENCIAS[1] L. Nalpantidis, G. Ch. Sirakoulis, and A. Gasteratos,“A Dense Stereo Correspondence Algorithm forHardware Implementation with Enhanced DisparitySelection”, SETN '08 Proceedings of the 5th Hellenicconference on Artificial Intelligence: Theories, Modelsand Applications, pp. 365-370, Springer-Verlag Berlin,Heidelberg, 2008.[2] Dong-Sun Kim, Sang-Seol Lee and Byeong-HoChoi, “A Real-Time Stereo Depth Extraction Hardwarefor Intelligent Home Assistant Robot”, IEEETransactions on Consumer Electronics, Vol. 56, Issue 3,pp. 1782-1788, Octubre 2010.[3] C. Cuadrado, A. Zuolaga, J. Martin, J. Laizaro, J.Jimenez, “Real time stereo visión processing system in aFPGA”, Proceedings of the IEEE 32 nd AnnualConference on Industrial Electronics, 2006[4] L. Mingxiang , J. Younde, “Stereo system onprogrammable chip (SVSoC) for small robotnavigation”, Proceedings of the IEEE /RSJ InternationalConference on Intelligent Robots and Systems, 2006 .[5] S. Perri, D. Colonna, P. Zicari, P. Corsonello, “SADbasedstereo matching circuit for FPGAs”, Proceedingsof the 13 th IEEE international Conference onElectronics, Circuits and Systems, 2006[6] K. Ambrosch, W. Kubinger, “Accurate hardwarebasedstereo vison”, Computer Vision and ImageUnderstanding, pp. 1303-1316, Elsevier, 2010.[7] J. Woodfill, G. Gordon, R. Buck, “The TyzxDeepSea high speed stereo vision system, a taskable,embedded stereo camara”, Proceedings of the 2006JP2011-698

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Estrategias de optimización en GPU y CPUmulti-core de modelos SPHJ.M. Domínguez, A.J.C. Crespo, A. Barreiro y M. Gómez-Gesteira 1Resumen—En este trabajo se presenta unaimplementación del modelo de dinámica de fluidos SPHpara CPU y GPU. Se explica cuáles son los problemas quepresentan cada implementación y las estrategias deoptimización aplicadas para mejorar el rendimiento en estemétodo concreto, aunque aplicables a muchos otrosproblemas. Los resultados muestran importantes mejorasconseguidas en cada arquitectura y una comparativaobjetiva entre las implementaciones más eficientes de CPUy GPU.Palabras clave—High Performance Computing, GPU,OpenMP, SPH, Smoothed Particle Hydrodynamics,Dinámica de fluidos.EI. INTRODUCCIÓNL método Smoothed Particle Hydrodynamics (SPH)es un método sin malla lagrangiano desarrollado enlos años 70 en astrofísica [1]. Desde entonces se haaplicado a varias ramas de la ingeniería, pero su usodestaca particularmente en el estudio de 1 lahidrodinámica de problemas de superficie libre, comoflujos violentos e interacción entre olas y estructuras.Permite simular escenarios sin necesidad de construircostosos modelos a escala, además de proporcionardatos difíciles de medir en un modelo real.SPHysics es una implementación del modelo SPH paraestudiar los flujos de superficie libre. Es producto delesfuerzo de investigadores de Johns Hopkins University(U.S.A.), Universidad de Vigo (España) y TheUniversity of Manchester (Reino Unido). Consiste en uncódigo open-source escrito en Fortran que se puededescargar en www.sphysics.org. Sin embargo, estemodelo posee un coste computacional muy elevado porlo que pequeñas simulaciones de unos segundos puedenrequerir varios días de cálculo. Por esta razón y pararealizar simulaciones con el tamaño necesario pararepresentar casos reales en un tiempo asequible, esimprescindible desarrollar implementaciones quepuedan explotar el paralelismo de los sistemas hardwaredisponibles en el mercado.Las CPUs (Central Processing Units) actuales secaracterizan por poseer múltiples cores (núcleos deprocesamiento) por lo que es posible repartir la carga decomputo de un programa entre los distintos cores,dividiendo también así el tiempo de ejecución. Por otrolado, las GPUs (Graphics Processing Units) son una1 EPHYSLAB Environmental Physics Laborarory, Universidad deVigo, Campus As Lagoas s/n 32004 Ourense, e-mail:jmdominguez@uvigo.esnueva tecnología importada de la industria de losvideojuegos que se puede utilizar para la computacióncientífica gracias a su arquitectura paralela. Haciendouso de estas tecnologías se ha desarrollado un nuevocódigo llamado DualSPHysics, implementado en C++con OpenMP (Open Multi-Processing) y CUDA(Compute Unified Device Architecture), capaz deejecutarse en CPU y GPU. La validación de este códigocon un experimento real puede encontrarse en [2]. Másinformación sobre el proyecto DualSPHysics puedeencontrarse en la web www.dual.sphysics.org, mientrasque diferentes aplicaciones y animaciones pueden verseen www.vimeo.com/dualsphysics.Obtener el máximo rendimiento de estas arquitecturasparalelas no es trivial, en especial cuando se trata deGPUs. En este trabajo se presenta una serie deestrategias de optimización para CPU y GPU aplicadasal método SPH, pero que pueden ser adoptadas pormuchos otros métodos. También se muestra unacomparativa de rendimiento entre CPU multi-core yGPU lo más objetiva posible.II.IMPLEMENTACIÓN DEL MODELO SPHSPH es un método sin malla donde el fluido sedescribe mediante un conjunto de nodos distribuidos enel espacio (a los que llamaremos partículas) en donde seregistran diferentes propiedades físicas (masa, densidad,velocidad, posición, presión). Las ecuacioneshidrodinámicas de movimiento de cada partícula fluidase integran en el tiempo y las magnitudes físicasrelevantes se calculan para cada partícula como unainterpolación de los valores de las partículas máscercanas. Las leyes de conservación de la dinámica defluidos se expresan de forma discreta usando ecuacionesintegrales en lugar de la forma de ecuacionesdiferenciales. En el caso de los contornos, sólo seresuelven las ecuaciones de conservación de la masa yse calcula cómo evoluciona su presión, pero no seintegran las ecuaciones de movimiento. De este modoexisten dos tipos de partículas, fluidas y contorno, y lainteracción entre ellas también requiere diferentesoperaciones.Las principales características del método SPH sedescriben de forma detallada en [3] y [4]. Aquí sedescribirán sólo las cuestiones principales relacionadascon la implementación. Conceptualmente, un códigoSPH se trata de un proceso iterativo que consta de trespasos principales:JP2011-699

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20111. Lista de vecinos (LV): Las partículas sólointeractúan con las partículas de alrededorsituadas a una determinada distancia, por lo que eldominio se divide en celdas de ese tamaño parareducir la búsqueda de vecinos a las celdasadyacentes. Para ello se ha implementado la listaCell-linked descrita en [5]. Como existen dos tiposde partículas (contorno y fluido), que convienemantener agrupadas, en realidad se crean doslistas independientes, una para cada tipo.2. Computo de fuerzas (CF): Cada partícula sólobusca a sus partículas vecinas dentro de su propiacelda y dentro de las celdas contiguas, y trasverificar que están dentro del radio de acción secalculan las fuerzas de interacción entre ellas.Como la interacción contorno-contorno no esnecesaria sólo se realizan interacciones fluidofluido(F-F), fluido-contorno (F-C) y contornofluido(C-F).3. Computo de paso (CP): Una vez que las fuerzasentre partículas han sido calculadas, todas lasmagnitudes físicas de las partículas se actualizanen función de estas fuerzas, para el siguiente pasode tiempo.El caso de estudio empleado en este trabajo consiste enel colapso de un volumen de agua debido a la gravedady su interacción con una estructura rectangular (verfigura 1). Un caso de estudio similar se ha empleadopara mostrar la precisión del modelo SPHysics en [6].Fig. 1. Distintos instantes en la evolución del fluido en el caso deestudio.Como ya se comentó el método SPH es muy costosoen tiempo de cálculo. Esto es debido a que en laaproximación de fluido débilmente compresible de SPH,el tiempo de cada paso es muy reducido (de 10 -5 a 10 -4segundos) lo cual obliga a tener que realizar muchospasos para obtener un segundo de simulación. Por otrolado, el número de pares de partículas que interactúanentre sí es muy elevado. Así para el caso de estudio, con1 millón de partículas se necesitan más de 26,000 pasosde tiempo para completar 1.5 segundos de simulaciónfísica, y cada partícula tiene una media de 300 partículasvecinas con las que interactúa. Esto hace que el paso CFse lleve más del 99% del tiempo en una ejecución enCPU single-core y un 96% en GPU. Por ello todos losesfuerzos para reducir el tiempo de ejecución deben serenfocados en reducir el coste de esta parte del código.III.ESTRATEGIAS DE OPTIMIZACIÓN EN CPUCada partícula posee una conjunto de magnitudes(posición, velocidad, densidad,...) almacenadas cada unaen un array. En cada paso de tiempo en LV se determinala celda en la que está cada partícula, para despuésordenar las partículas en función de dicha celda. Estoproporciona dos ventajas importantes: Al reordenar losdatos de las partículas según su celda se aumenta laproximidad en memoria entre las partículas que van ainteraccionar, y por otro lado permite identificar laspartículas de una celda simplemente como un rango. Deesta forma en CF la interacción se realiza entre celdas,es decir, todas las partículas de una celda con todas lasde otra celda. Como el tamaño de celda coincide con ladistancia máxima de interacción (a la que llamaremos2h) sólo es necesario que una celda interactué consigomisma y con las de alrededor, comprobando para cadapar de partículas si están dentro de la distancia deinteracción o no.Algunas de las optimizaciones que se pueden realizarsobre la implementación en CPU son las siguientes:A. Uso de la simetría en el cálculo de fuerzasAl computar la fuerza que ejerce una partícula i sobreotra partícula j, se puede obtener la fuerza de j sobre isimplemente cambiando el signo. Esto permite reducir ala mitad el número de interacciones que es necesarioevaluar. Para ello, en 3D cada celda sólo interactuarácon 13 celdas y parte de sí misma, en lugar de 27.B. División en celdas más pequeñasUsar celdas de un tamaño 2h provoca que gran partede los pares de partículas que se evalúan no requierancomputar la interacción por estar a mayor distancia de larequerida, siendo así vecinos potenciales pero no reales.En la figura 2 puede verse como reduciendo el tamañode las celdas es posible aumentar el porcentaje devecinos reales. Sin embargo esto también conlleva unaumento del número total de celdas, así como las celdascon las que debe interactuar cada una. Debido a estosólo es rentable usar celdas de tamaño h, con lo que seconsigue aumentar la proporción de vecinos reales del19% al 31%.60%50%40%30%20%10%0%0 250,000 500,000 750,000 1,000,000NCells 2hCells 2h/2Cells 2h/3Cells 2h/4Fig. 2. Porcentaje de vecinos reales frente a potenciales según eltamaño de celda y el número de partículas (N).C. Uso de instrucciones SSELas CPUs actuales disponen de unos conjuntos deinstrucciones especiales (SSE, SSE2, SSE3,...) de tipoSIMD (Single Instruction, Multiple Data) con las que sepueden hacer operaciones sobre conjuntos de datos.Utilizando estas instrucciones es posible realizar unaoperación básica (suma, resta, multiplicación, división,comparación,...) sobre 4 números reales (de precisiónsimple) de forma simultánea. Otra ventaja es que suJP2011-700

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011traducción a código máquina es directa por lo queproporciona un mayor rendimiento. Sin embargopresenta algunas desventajas importantes; sólo esaplicable en casos concretos, cuando los cálculos sepueden realizar en packs de 4 valores, es bastantecomplicado usarlas de forma eficiente y su codificaciónes muy engorrosa. Estas instrucciones se aplicaronfundamentalmente al cálculo de fuerzas entre partículas,agrupando previamente los pares de interacción en packsde 4.D. Programación multi-core con OpenMPHoy en día las CPUs disponen de varios cores ounidades de procesamiento, por lo que es fundamentaldistribuir la carga de cálculo de una aplicación entretodos ellos para maximizar el rendimiento de la CPU. Laopción elegida fue el interfaz de programación paralelaOpenMP, ya que se trata de un modelo de programaciónportable y flexible, cuya implementación no suponegrandes cambios en el código.Se aplicó paralelismo a diversas partes del código peroen el cálculo de fuerzas es donde su uso tiene mayorimportancia. En el paso CF se probaron distintasaproximaciones pero la que mejor resultados aportaconsiste en repartir las celdas entre todos los hilos deprocesamiento disponibles. Cada hilo se encarga derealizar la interacción de cada una de sus celdas con susvecinas guardando las fuerzas resultantes en un arraypropio, y posteriormente se acumulan las fuerzascalculadas por cada hilo en un único array. Paraconseguir que el reparto de carga entre los hilos seaequilibrado se utiliza una planificación dinámica enbloques de 10 celdas que son asignados a los hilos amedida que estos quedan libres de carga.IV.ESTRATEGIAS DE OPTIMIZACIÓN EN GPUSe parte de una implementación híbrida donde sólo CFes implementada en GPU, ya que esta parte del códigoconsume más del 99% del tiempo de ejecución en CPU(single-core). Debido a que la memoria de la GPU esindependiente de la memoria de la CPU, siempre que sedesee procesar datos en la GPU es necesariotransferirlos previamente, y una vez completado elproceso realizar otra transferencia para recuperar losresultados obtenidos de la GPU. Esto supone que pararealizar un paso de tiempo es necesario realizar lassiguientes fases: (i) generar la lista de vecinos en CPU,(ii) transferir datos de las partículas y su división enceldas a la GPU, (iii) calcular las fuerzas en GPU, (iv)recuperar la fuerzas calculadas en GPU y (v) actualizarmagnitudes de las partículas para el siguiente paso detiempo.En GPU la forma de calcular las fuerzas difiere de laimplementación en CPU, ya que en lugar de hacer lainteracción de una celda completa de partículas con susceldas vecinas, en GPU cada partícula busca todos susvecinos recorriendo todas las celdas contiguas ademásde la propia. De esta forma a cada hilo de ejecución enGPU (thread) se le asigna una partícula y sólo se encargade calcular las fuerzas para esta partícula. Con estaaproximación no es posible aplicar la simetría en elcálculo de fuerzas ya que varios hilos podrían intentarmodificar la misma posición de memoriasimultáneamente originando un error. Este problemapodría evitarse mediante el uso de barreras desincronización, pero entonces, dejaría de ser rentabledebido a su elevado coste.Los problemas principales que presenta estaimplementación son:1. Transferencias CPU-GPU: Como ya se explicó, alser una implementación parcial en GPU, esnecesario realizar varias transferencias de datosentre CPU y GPU por cada paso de tiempo que secalcula, lo cual limita significativamente elrendimiento de la GPU.2. Divergencia: En CUDA los hilos se agrupan enconjuntos de 32 threads llamados warp. Cuando seejecuta una operación sobre un warp, los 32threads realizan dicha operación de formasimultánea. Pero debido a bifurcacionescondicionales en el código, no todos los hilospueden realizar la misma operación. Entonces lasdistintas operaciones se realizan secuencialmenteocasionando una pérdida importante derendimiento. Este problema se da en CF porquecada thread tiene que evaluar para su partícula quévecinos potenciales son reales, antes de proceder acalcular la fuerza, y descartar al resto.3. Acceso irregular a memoria: De formasimplificada, el acceso a la memoria global de laGPU se realiza en bloques de 32, 64 o 128 bytes,por tanto el número de accesos para satisfacer unwarp depende fundamentalmente de si los datossolicitados están agrupados o no. Para más detallesobre el acceso a la memoria global se puedeconsultar [7]. En CF, pese a que los datos estánordenados según la celda de las partículas, no esposible acceder a memoria de forma regular yaque cada partícula tiene distintos vecinos y portanto cada thread tendrá que acceder a distintasposiciones de memoria que no siempre estaránpróximas a las del resto del warp.4. Desbalanceo de carga: En CUDA los warps seejecutan en grupos llamados bloques. Cuando unbloque entra en ejecución se le asignan unosrecursos que no estarán disponibles para otrosbloques hasta que su ejecución se complete.Debido a que cada partícula puede tener distintonúmero de vecinos, es posible que un thread tengaque realizar muchas más interacciones que elresto, y así mantener un warp en ejecuciónmientras que el resto de threads del mismo warp eincluso del bloque pueden haber terminado. Estoreduce el rendimiento ya que provoca un usoineficiente de los recursos de la GPU.Con el fin de evitar o al menos minimizar losproblemas descritos anteriormente se realizaron lassiguientes optimizaciones:A. Implementación completa en GPUPara minimizar las transferencias entre CPU y GPU sepuede implementar todo el proceso en GPUmanteniendo todos los datos en la memoria de la GPU.Esto permite reducir drásticamente el número detransferencias, ya que sólo sería necesario recuperar losresultados concretos que se deseen y cada muchos pasosJP2011-701

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011de tiempo. Por otro lado, al implementar LV y SU en laGPU también se consigue reducir su tiempo deejecución.Como en el caso de la implementación en CPU losdatos de las partículas (posición, velocidad,...) sonalmacenados en arrays, pero dentro de la memoria de laGPU. En el paso LV en GPU primero se calcula la celdaque le corresponde a cada partícula. Después se usa laimplementación de RadixSort de NVIDIA [8] paraobtener cuál debe ser su posición al ordenar laspartículas según su celda, y a partir de estas nuevasposiciones se obtienen todos los vectores de datosordenados. Por último se crea un vector de índicesdonde se almacena, para cada celda, la posición queocupa (en los arrays de datos) la primera y últimapartícula de dicha celda. La implementación de SU enGPU es sencilla ya que sólo hay que actualizar lasmagnitudes de las partículas según las fuerzas aplicandouna fórmula.B. Maximizar la ocupación de la GPULa ocupación es la relación entre el número de warpsactivos y el máximo posible por SM (StreamingMultiprocessor). Debido a que el acceso a la memoriaglobal de la GPU en CF es muy irregular, esfundamental tener la mayor cantidad de warps activos,ya que esta es la forma de ocultar las latencias delacceso a la memoria y mantener el hardware lo másocupado posible. El número de warps activos dependede: los registros que necesita un kernel (procedimientoque se ejecuta en la GPU), características de la GPU(consultar tabla I) y del número de hilos por bloquecuando se ejecuta un kernel.Con esta optimización el tamaño de bloque es ajustadosegún los registros del kernel y las características delhardware, para lograr la mayor ocupación posible. En lafigura 3 puede verse como en una GPU sm13 para 35registros usando 256 threads se consigue 25% deocupación, frente al 44% conseguido con 448 threads.TABLA ICARACTERÍSTICAS DE LAS GPUS SEGÚN COMPUTE CAPABILITY.Especificaciones técnicas 1.0 1.1 1.2 1.3 2.xMáx. de threads por bloque 512 1024Máx. de bloques activos por SM 8Máx. de warps activos por SM 24 32 48Máx. de threads activos por SM 768 1024 1536Máx. de registros 32-bit por SM 8 K 16 K 32 K100%80%60%40%20%0%20 25 30 35 40 45 50 55Registerssm12-13 (256 threads)sm20-21 (256 threads)sm12-13 (varying threads) sm20-21 (varying threads)Fig. 3. Ocupación de la GPU según el número de registros necesarios,para un tamaño de bloque variable o fijo de 256 threads.C. Reducir los accesos a memoria globalUna forma de reducir el número de accesos a lamemoria en el kernel de CF consiste en agrupar algunosdatos y evitar leer valores que se puedan calcular a partirde otros. De esta forma se pasa de usar 6 arrays (pos yvel de 12 bytes y rhop, csound, tensil y prrhop de 4bytes), a usar 2 únicos arrays (pos+prrhop y vel+rhopde 16 bytes cada uno).D. Simplificar la búsqueda de vecinosEn el kernel de interacción cada thread tiene quebuscar los vecinos de su partícula, para ello deberecorrer todas las partículas de su propia celda y todaslas de alrededor (en total 27 celdas). Este proceso sepuede extraer del kernel de interacción si previamente secalcula cuales son los rangos de partículas con las queva a interaccionar cada celda. Como las partículas estánordenadas según su celda y las celdas en los ejes X, Y yZ, se pueden utilizar 9 rangos de partículas para las 27celdas. Al disponer de estos rangos, el kernel deinteracción se simplifica bastante, reduciéndose losaccesos a memoria y la divergencia en los warps,además también se reduce el uso de registros del kernello que permite aumentar la ocupación de la GPU. Sinembargo esto provoca un mayor consumo de la memoriaya que se necesitan 144 bytes por cada celda.E. Fusionar interacciones F-F con F-CEl acceso a la memoria global de la GPU es dosórdenes de magnitud más lento que el acceso a losregistros. Por esta razón, para minimizar estos accesos,cada thread empieza guardando en registros todos losdatos necesarios de su partícula, así sólo necesita leer dela memoria los datos de las partículas con las queinteractúa. Lo mismo se hace para acumular las fuerzas,éstas se acumulan en registros y sólo al final se escribenen memoria global.Sin embargo y tal como se explicó en el apartado II,las partículas están divididas en 2 grupos (contorno yfluido) y para calcular todas las fuerzas es necesariorealizar tres interacciones (F-F, F-C y C-F). Esto suponeque los datos de las partículas asociadas a los threads seleen 2 veces (cuando interaccionan con otras partículasfluido y cuando lo hacen con las contorno), y lo mismoocurre con la escritura de los resultados en memoriaglobal. Para evitar esto, en el mismo kernel se hace lainteracción del fluido con el fluido y después con elcontorno, leyendo los datos al principio y escribiendolos resultados al final.F. Simplificar el kernel de interacción C-FAl no poder aplicar la simetría en el cálculo de fuerzasse puede implementar un kernel específico para lainteracción C-F, ya que para las partículas contorno sólose necesita calcular una pequeña parte de los datos quese necesitan para las de fluido. Sin embargo esto nosupone una gran mejora debido a que el número departículas contorno es muy inferior al de fluido y portanto su impacto en el rendimiento no es destacable. Enla figura 4 se muestra la proporción de partículas decontorno frente al total del caso empleado en estetrabajo.JP2011-702

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011100%80%60%40%20%0%0 500,000 1,000,000 1,500,000 2,000,000Fig. 4. Proporción de partículas contorno en el caso de estudio.G. Dividir en celdas más pequeñasNComo ya se explicó en la implementación en CPU,consiste en dividir el dominio en celdas de tamaño h enlugar de 2h con el fin de aumentar la proporción devecinos reales del 19% al 31%. Esto además de reducirla cantidad de pares de partículas que se evalúan,también reduce el problema de la divergencia. Elinconveniente es que aumenta el consumo de memoriaya que el número de celdas se multiplica por 4 y elnúmero de rangos de partículas que se compruebandurante la búsqueda de vecinos de cada partícula pasa de9 a 25 (consumiendo 400 bytes por celda).V. RESULTADOSA continuación se presentan los resultados obtenidosen CPU y en GPU al ir aplicando todas lasoptimizaciones comentadas en los apartados anteriores.Las simulaciones se han ejecutado bajo un sistemaoperativo Ubuntu 10.10 de 64 bits. Las característicasdel hardware empleado para la obtención de tiempos enCPU son: INTEL Core i7 940 a 2.93 GHz, 6 GB deRAM DDR3 a 1333 Mhz, Placa base GA-EX58-UD3RGIGABYTE. Para los tiempos en GPU se utilizó unatarjeta NVIDIA GTX 480 (dedicada sólo a cálculo),cuyas características son: 15 Multiprocesadores, 480cores, 1536 MB de memoria GDDR5 y Computecapability 2.0.Tanto para CPU como para GPU, los resultadosmuestran el speedup (rendimiento versión mejorada /rendimiento versión básica) conseguido al comparar elrendimiento de la versión básica (sin ningunaoptimización) con otras donde se incluyen lasoptimizaciones explicadas. El rendimiento se mide enpasos de tiempo computados por segundo.En la figura 5 se muestra la mejora de rendimientoconseguida en CPU, según el número de partículas de lasimulación (N), tras aplicar las tres primeras mejorasexplicadas en el apartado III. Para 300,000 partículas seconsigue un speedup de 2.26 con respecto a la versióndel código sin optimizaciones.2.52.01.51.00 100,000 200,000 300,000NSSE(h)SSE(2h)Simetria(h)Simetria(2h)Fig. 5. Speedup conseguido en CPU single-core aplicando lasoptimizaciones descritas en el apartado III. El speedup de SSEincluye el uso de la simetría y el valor entre paréntesis es eltamaño de celda.La figura 6 muestra los resultados con OpenMP. Enesta figura se observa como el uso de 8 hilos hace subirel speedup de 2.26 a 9.56 (hay que tener en cuenta quela CPU cuenta con 4 cores reales, 8 al tenerhyperthreading activado). Otro detalle significativo esque los speedups aumentan con el número de partículas.9.07.05.03.01.00 100,000 200,000 300,000N8 Threads4 ThreadsSingle-coreFig. 6. Speedup conseguido en CPU multi-core con respecto a laimplementación sin optimizaciones. En todos los resultados seaplico la simetría, instrucciones SSE y h como tamaño de celda.En la figura 7 se muestra el speedup logrado en GPUal implementar las mejoras explicadas en el apartado IV.Cada línea de la grafica corresponde al resultado deaplicar una nueva optimización además de las anteriores.Puede verse cómo para 2 millones de partículas seconsigue duplicar el rendimiento aplicando todas lasoptimizaciones hasta la F. Con la optimización G (usoceldas de tamaño h) sólo hay resultados hasta 1.8millones de partículas ya que las necesidades dememoria son mayores que la capacidad de la GPUempleada.2.52.01.51.00 500,000 1,000,000 1,500,000 2,000,000NG-Cells(h)F-SimpleCBE-FusionD-NeighSearchC-GlobalMemB-OccupancyA-FullGPUFig. 7. Speedup conseguido en GPU al ir aplicando todas las mejorasdescritas en el apartado IV. El speedup de cada optimizaciónincluye a todas las anteriores.Una comparativa entre CPU y GPU puede verse en lafigura 8. Se muestra el speedup conseguido con laimplementación más eficiente en GPU frente a la másrápida de CPU Single-core y Multi-core de 8 threads. Eltiempo de ejecución y los pasos de cálculo realizadospueden verse en la tabla II.60504030201000 500,000 1,000,000NGPU vs Single-coreGPU vs 8 ThreadsFig. 8. Speedup de la versión GPU más optimizada frente a la másrápida de CPU.JP2011-703

Runtime (h)Memory (Gb)Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011VersiónCPUSingle-coreCPU8 ThreadsTABLA IIRESULTADOS DE SIMULACIONES EN CPU Y GPU.Partículas Tiempo Pasos/seg. Pasos503,492 14.6 h 0.38 19,8551,011,354 40.7 h 0.18 26,493503,492 3.4 h 1.64 19,8221,011,354 9.5 h 0.78 26,492GPU 503,492 0.3 h 21.18 19,8301,011,354 0.7 h 10.12 26,480Como ya se explicó anteriormente la implementaciónmás eficiente en GPU tiene un consumo muy elevado dememoria, por lo que el máximo de partículas que sepuede alcanzar es de 1.8 millones en una GTX 480. Paraevitar esta limitación en el código DualSPHysics seimplementaron tres versiones; una con todas las mejoras(FastCells(h)), sin la optimización D (SlowCells(h)) ysin las optimizaciones D y G (SlowCells(h)). Estopermite simular hasta 9 millones de partículas comopuede verse en la figura 9.1.51.00.50.00 2,500,000 5,000,000 7,500,000 10,000,000NSlowCells(2h)SlowCells(h)FastCells(h)Fig. 9. Consumo de memoria (en GBytes) para distintas versiones deGPU.En la figura 10 se muestran los tiempos de ejecuciónde las tres versiones GPU y de las versiones Single-corey Multi-core de CPU. Puede verse como las versionesGPU con menor consumo de memoria presentan unmenor rendimiento, aunque siguen siendo mucho máseficientes que las CPU.10864200 2,500,000 5,000,000NCPU Single-coreCPU 8 threadsSlowCells(2h)SlowCells(h)FastCells(h)Fig. 10. Tiempos de ejecución (en horas) para distintas versiones enCPU y GPU.GPU. Cabe destacar que estas optimizaciones sellevaron a cabo para la aplicación de un modelo SPH,pero la mayoría pueden ser aplicadas a muchos otrosproblemas.Finalmente se presentó una comparativa derendimiento real entre GPU y CPU, donde se utilizó elcódigo más optimizado para cada arquitectura sobre unhardware actual (CPU i7 940 a 2.93 GHz y GPU GTX-480). Se obtuvo un speedup cercano al 60 comparandoGPU con CPU Single-core, y de 13.3 con CPU Multicorede 8 threads.Es necesario seguir investigando cómo mejorar elrendimiento, fundamentalmente en GPU donde todavíahay varios inconvenientes que se pueden intentarmejorar. De todas formas, para reducir tiempos deejecución y aumentar el tamaño de las simulaciones esimprescindible implementar una versión con MPI que sepueda ejecutar en clústeres de CPUs y GPUs.AGRADECIMIENTOSEl presente trabajo ha sido financiado por la Xunta deGalicia, Programa de Consolidación e Estructuración deUnidades de Investigación (Grupos de ReferenciaCompetitiva) cofinanciado por European RegionalDevelopment Fund (FEDER).REFERENCIAS[1] R. A. Gingold y J. J. Monagham, “Smoothed particlehydrodynamics: theory and application to non- spherical stars”,Mon Not R Astr Soc 181: 375-389, 1977.[2] A. J. C. Crespo, J. M. Dominguez, A. Barreiro, M. Gómez-Gesteira y B. D. Rogers, “GPUs, a new tool of acceleration inCFD: Efficiency and reliability on Smoothed ParticleHydrodynamics methods”, PLoS ONE, doi:10.1371/journal.pone.0020685, 2011.[3] M. Gómez-Gesteira, B. D. Rogers, R. A. Dalrymple y A. J. C.Crespo, “State-of-the-art of classical SPH for free-surfaceflows”, Journal of Hydraulic Research, 48 Extra Issue, 6–27,2010.[4] M. B. Liu y G. R. Liu, “Smoothed Particle Hydrodynamics(SPH): an Overview and Recent Developments”, Arch ComputMethods Eng 17: 25-76, 2010.[5] J. M. Dominguez, A. J. C. Crespo, M. Gómez-Gesteira and J. C.Marongiu, “Neighbour lists in Smoothed ParticleHydrodynamics”, International Journal for Numerical Methodsin Fluids, doi: 10.1002/fld.2481, 2010.[6] M. Gómez-Gesteira y R. Dalrymple, “Using a 3D SPH methodfor wave impact on a tall structure”, Journal of Waterway, Port,Coastal, and Ocean Engineering, 130(2), 63-69, 2004.[7] NVIDIA Corporation, NVIDIA CUDA Programming Guide Ver.3.2, 2010.[8] N. Satish, M. Harris, y M. Garland, “Designing Efficient SortingAlgorithms for Manycore GPUs”, In Proceedings of IEEEInternational Parallel & Distributed Processing Symposium2009, 2009.VI.CONCLUSIONES Y TRABAJO FUTUROSe presentó un código basado en el método SPH parala simulación dinámica de fluidos con unaimplementación CPU y otra GPU. Sobre cadaimplementación se mostró que el cómputo de fuerzas erala parte más costosa en tiempo. Una vez analizadoscuales eran los problemas que presentaba cadaimplementación, se aplicaron una serie deoptimizaciones para minimizarlos y mejorar elrendimiento. Con estas optimizaciones se logrómultiplicar la velocidad por 10 en CPU y por 2.6 enJP2011-704

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Implementación del algoritmo de registro nolineal DARTEL sobre una plataformaheterogéneaPedro Valero 1 , José L. Sánchez 2 , Enrique Arias 2 y Diego Cazorla 2Resumen— Actualmente, en el campo de la imagenmédica, los métodos de registro deformable estánadquiriendo cada vez más importancia, debido a lavaliosa información que aportan. Estos métodos sonutilizados en un gran número de tareas críticas comoen diagnósticos, planificación de cirugía o radioterapia,etc. Sin embargo, estos métodos consumen untiempo de ejecución considerable, por lo que es importanteobtener nuevas implementaciones que reduzcandicho tiempo. Las actuales GPUs disponende un elevado número de núcleos y ancho de banda,convirtiéndose en un excelente dispositivo para conseguirel propósito de acelerar aplicaciones. En estetrabajo se presenta una nueva implementación de unode los algoritmos de registro deformable más utilizados,DARTEL. Los resultados experimentales muestranuna redución del tiempo de ejecución, siendo laimplementación en GPU hasta 4 veces más rápida quela implementación secuencial. Una directa consecuenciade estos resultados es, en última instancia, proveeruna mejor atención médica.Palabras clave—Imagen médica, registro deformable,DARTEL, GPU.I. IntroducciónEL registro de imagen es el proceso de alinear geométricamentedos o más imágenes de la mismaescena, tomadas en diferentes instantes, desde diferentespuntos de vista, o por diferentes sensores. Hoyen día, el registro de imágenes es utilizado en clasificaciónmultiespectral, monitorización del medio ambiente,pronóstico del tiempo, integración de informacióndentro de sistemas de información geográfica,localización de objetivos, calidad de control automática,etc. Se han publicado diversos resúmenessobre métodos de registro de imagen [1], [2].En el campo de imagen médica, el registro de imagenes el proceso de alinear imágenes cuyas característicaspuedan ser relacionadas [3]. Este procesopuede ser intra-operativo, aplicado a diferentesimágenes del mismo paciente, o inter-operativo,aplicado a diferentes imágenes de diferentes pacientes.El especialista médico utiliza el registro deimágenes para diferentes tareas críticas tales como,diagnósticos, planificación de cirugía o radioterapia,verificación de dosis, cirugía guiada por imagen,seguimiento del progreso de la enfermedad o respuestaal tratamiento, registro basado en atlas, etc.El registro alinea imágenes aplicando transformacionesgeométricas a una de ellas para igualarla a1 Inst. de Investigación en Informática, Univ. de Castilla-LaMancha, e-mail: Pedro.ValeroLara@uclm.es2 Dpto. de Sistemas Informáticos, Univ. de Castilla-La Mancha, e-mail: jose.sgarcia, enrique.arias,diego.cazorla@uclm.esotra. Estas técnicas pueden agruparse en técnicas deregistro rígido o técnicas de registro deformable. Elregistro rígido solo permite transformaciones rígidas,como rotaciones y traslaciones. En el otro caso, elregistro deformable utiliza técnicas como transformacioneselásticas para corregir deformaciones quelos métodos rígidos no pueden corregir.El algoritmo “Diffeomorphic Anatomical RegistrationThrough Exponentiated Lie algebra”, DARTEL[4], [5], es uno de los más sofisticados y comunmenteutilizados en este campo. DARTEL forma parte dela herramienta software “Statistical Parametric Mapping”(SPM) [6], la cual fue originalmente desarrolladapara el mapeo paramétrico estadístico de datosPET (Positron Emission Tomography) y fMRI (functionalMagnetic Resonance Imaging). Uno de los usosmás habituales de DARTEL consiste en realizar elregistro basado en atlas para imágenes cerebralesen tres dimensiones. Este proceso es computacionalmentemuy costoso, y se requieren nuevas implementacionesmás eficientes y rápidas.Estas circunstancias, es decir, el importante esfuerzocomputacional requerido y la necesidad de tiemposrápidos de respuesta, unido a la organización inherentementeparalela de los datos de las imágenesnos conducen al uso de la computación paralela comoalternativa más adecuada para mejorar este tipode aplicaciones.Hoy en día la computación heterogénea es una alternativaque se adecúa bastante bien a las altasnecesidades computacionales que tienen algunas aplicaciones.En particular, las plataformas basadas enGPUs tienen un excelente ratio rendimiento/coste,y por ello están siendo ampliamente utilizadas paraacelerar aplicaciones de propósito general (GPGPU)[7], [8].Se han llevado a cabo varios estudios en el campodel registro de imagen con el uso de GPUs. Sin embargo,sólo un número limitado de ellos se centran enregistro deformable [9], [10]. La GPUs han sido utilizadasprincipalmente en registro rígido como en lageneración de “Digital Reconstructed Radiograph”(DDR) [11], [12], [13], [14], [15].En este trabajo, se presenta una implementacióndel algoritmo de registro deformable DARTEL parauna plataforma heterogénea basada en GPU. A díade hoy, y según conocen los autores, no existe ningunaimplementación de DARTEL basada en GPU.El trabajo sigue la siguiente estructura: La sección2 presenta el algoritmo DARTEL. En la sección 3JP2011-705

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011se describe la implementación de DARTEL basadaen GPU. En la sección 4 se muestra el análisis derendimiento llevado a cabo. Finalmente, en la sección5 se resumen las conclusiones.II. DARTELComo se ha mencionado en la sección anterior,DARTEL es un algoritmo de registro deformablepara imagen médica. DARTEL se divide en dospartes (Figura 1). La primera consiste en obteneruna plantilla a partir del atlas. La plantilla muestralas características en común de los pacientes queforman el atlas. Normalmente, estos pacientes compartenla misma patología. La segunda parte consisteen obtener una imagen deformada a partir dela plantilla procedente de la primera parte, y nuevasimágenes pertenecientes a otros pacientes (una porpaciente). De esta manera, es posible detectar si unpaciente sufre la misma patología compartida por todoslos pacientes que forman el atlas.DARTEL utiliza imágenes segmentadas en materiablanca y gris, por lo cual, en primer lugar, esnecesario segmentar las imágenes de cada pacientedel atlas. Este proceso no forma parte de DARTEL,y debe ser llevado a cabo antes de aplicar dicho algoritmo.La primera parte (Create Template) es un procesoiterativo en donde a partir de una plantilla inicial yun conjunto de imágenes (Atlas) se crea la plantillafinal. Para cada imagen del altas se crea un “campode flujo” el cual codifica cómo cada imagen debeser deformada para ajustarse mejor a la forma de laplantilla. Cuando se obtiene la plantilla, se realiza unproceso de suavizado (Smooth). Este proceso se llevaa cabo para obtener una plantilla más precisa.La segunda parte se divide en dos etapas. Laprimera consiste en generar los campos de flujo (ExistingTemplate). La siguiente se realiza para obtenerlas imágenes deformadas (Create Warped). Paracada imagen de entrada se genera una imagen deformada.III. Implementación paralela de DARTELpara GPUComo se menciona en la sección I, las actualesGPUs están siendo ampliamente utilizadas para aceleraraplicaciones de propósito general. Uno de losmotivos de utilizar estos dispositivos para este fin, esla aparición de nuevas herramientas software que permitental uso. Una de las más utilizadas hoy en día esCUDA [16]. En CUDA, los cálculos son distribuidosen una malla o grid de bloques de hilos. Todos losbloques de hilos tienen el mismo tamaño (número dehilos). Estos hilos ejecutan el código destinado a laGPU, denominado kernel. La dimensiones de la mallay de los bloques de hilos deben ser cuidadosamenteelegidos para maximizar el rendimiento de la GPU.CUDA incluye herramientas de desarrollo softwareC/C++, librerías de funciones, mecanismos de monitorizacióno perfilado, . . . , todo ello formando unaApplication Programming Interface (API) propia.Se han paralelizado las partes computacionalmentemás costosas de DARTEL las cuales consumenalrededor del 73 % del tiempo total de ejecución. Acontinuación, se detallan cada una de estas partes:DARTEL utiliza la estrategia del algoritmo llamado“Large Deformation Diffeomorphic MetricMapping” (LDDMM) [17], el cual trata unagran deformación como una composición de secuenciasde deformaciones más pequeñas. Cadapequeña deformación es indicada por una matrizde deformación. Una de las partes más costosasconsiste en inicializar este conjunto de matrices.Las matrices Jacobianas codifican el estiramiento,corte y rotación que forma la deformación.Una fase importante consiste en calcular las deformaciones,las cuales se obtienen a partir de lacomposición de las deformaciones o composiciónJacobiana.No es posible utilizar métodos tradicionales paraalmacenar todo el conjunto formado por las matricesde deformación debido a las limitacionesde memoria. Por esa razón, DARTEL utiliza laaproximación llamada “full multigrid” (FMG)[18] para almacenar estas matrices. Este métodoconsiste en comprimir la información almacenadapor las matrices de deformación, aplicandociertas operaciones matemáticas.Algorithm 1 Pseudocódigo de DARTELTemplate, FlowField[n] :DARTEL Template Creation (Atlas[n], Flow-Field[n], Template)FlowFields[n] : DARTEL Warped Creation (Images[n],Template)1: while ( doi < n)2: Small Deformations()3: Jacobian Composition()4: FMG() ⊲ Full Multigrid Method5: i++6: end whileComo se puede ver en el código del Algoritmo 1,DARTEL es un proceso iterativo. Hay tantas iteraciones(n) como imágenes en el atlas en el caso de laprimera etapa, y tantas como imágenes de entradaen la segunda etapa. El pseudocódigo sólo muestralas funciones paralelizadas y su orden.Cada punto de la imagen tiene asociado un conjuntode matrices, según el algoritmo LDDMM utilizadopor DARTEL. Cada función consiste en aplicar elmismo conjunto de operaciones matemáticas sobrelas matrices asociadas a cada punto de la imagen.Así pues, estas funciones consisten en un proceso iterativocon tantas iteraciones como puntos de la imagen(m).Cada iteración es independiente ya que el procesamientode cada punto no depende del procesamientode los demás. Por esa razón, es posible explotarel nivel de paralelismo de datos del algoritmo, ejecutandotodas las iteraciones de forma simultánea.JP2011-706

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Create TemplateExisting TemplateCreate WarpedInput Images (Atlas)Input ImagesWhite and grey mattersegmentationWhite and grey mattersegmentationDARTELWarpedSegmented Images (Atlas)Segmented ImagesCreate Initial TemplateDARTELDARTELFlow FieldsFlow FieldsTemplateSmoothTemplateFig. 1. Etapas para generar una plantilla y una imagen deformada utilizando el algoritmo DARTEL.Debido a los requisitos de DARTEL y al tamaño delos datos utilizados (imágenes médicas cerebrales entres dimensiones), no es posible computar todas lasimágenes o un conjunto de ellas al mismo tiempo.Por lo tanto, sólo se explota el paralelismo a nivelde datos de los puntos de cada imagen. Además, esnecesario un alto número de transferencias entre lasmemorias de CPU y GPU.Las llamadas a las funciones paralelas son similaresa la implementación secuencial pero es necesario indicarel número de hilos que ejecutan el código de lafunción. El número de hilos está dado por el númerode puntos de la imagen (Algoritmo 2).Se han llevado a cabo ciertas optimizaciones centradasen maximizar la utilización de los núcleos,minimizar la sobrecarga de las trasferencias entre lasmemorias de la GPU y CPU, y utilizar los registrosen la mayor medida posible.IV. Evaluación de RendimientoEn esta sección se presenta la evaluación derendimiento de la implementación de DARTE parala plataforma basada en GPU.Se han utilizado imágenes en tres dimensiones, cadauna consistente en un conjunto de imágenes endos dimensiones (capas), correspondientes a las vistasaxial, sagital y coronal. Para los casos de prueba,DARTEL ha generado imágenes en tres dimensiones(plantilla e imagen deformada) con los sigu-Algorithm 2 Pseudocódigo de la versión basada enGPU de DARTELTemplate, FlowField[n] :DARTEL Template Creation (Atlas[n], Flow-Field[n], Template)FlowFields[n] : DARTEL Warped Creation (Images[n],Template )1: while do (i < n)2: CPU-GPU Data transferences ⊲ Input data3: Small Deformations kernel< m >()4: GPU-CPU Data transferences ⊲ Outputdata5: CPU-GPU Data transferences6: Jacobian Composition kernel< m >()7: GPU-CPU Data transferences8: CPU-GPU Data transferences9: FMG kernel< m >() ⊲ Full MultigridMethod10: GPU-CPU Data transferences11: i++12: end whileientes tamaños, 60 imágenes en la vista axial, 60imágenes en la vista sagital, y 72 imágenes en la vistacoronal. Por tanto, las imágenes de la vista axial sonde 60×72 píxeles, las imágenes de la vista sagital sonde 60 × 72 píxeles, y las imágenes de la vista coronalson de 60×60 píxeles. Finalmente, cada imagen tiene(60 × 72) 2 × 60 × 60 = 67, 184, 640, 000 píxelesJP2011-707

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011La plataforma utilizada está formada por unaCPU CPU Intel Core 2 Quad (Q9400)-2.66 GHz y4GB de memoria principal, y una GPU GForce GTX285 GPU con 240 núcleos y 1GB de memoria devídeo.Los resultados experimentales se muestran entérminos de tiempo de ejecución en segundos yspeedup para ambas implementaciones, secuencial yparalela. Otra métrica que hemos utilizado es el consumoeléctrico. Las medidas del consumo se han realizadoutilizando el sistema descrito en [19].Para la primera parte, se ha utilizado un atlas con30 imágenes diferentes en tres dimensiones. Las pruebashan consistido en 11 ejecuciones con diferentesnúmero de imágenes de entrada, desde 20 a 30. Parala segunda parte, las pruebas han consistido en 4ejecuciones diferentes, desde 1 a 4 imágenes de entrada.La Tabla 1 muestra el número de imágenes(N.I.),tiempo de ejecución para la implementaciónsecuencial (T.S.), tiempo de ejecución para la implementaciónparalela (T.P.), y speedup (S.). La Figura2 muestra la tendencia del speedup para ambaspartes de DARTEL (primera - arriba y segunda -abajo).Primera Parte DARTELN.I. T.S.(s) T.P.(s) S.20 7,723.83 1,964.89 3.9421 8,125.09 2,063.98 3.9422 8,515.01 2,163.36 3.9423 8,909.4 2,258.36 3.9524 9,306.92 2,346.53 3.9725 9,678.8 2,448.9 3.9526 10,042.6 2,533.49 3.9627 10,436 2,641.68 3.9528 10,810.5 2,730.54 3.9629 11,253.7 2,839.41 3.9630 11,589.1 2,938.78 3.95Segunda Parte DARTEL1 374.39 88.92 4.212 751.47 177.42 4.233 1,128.48 256.54 4.244 1,496.84 355.25 4.21TABLA ITiempo de ejecución para ambas implementaciones yspeedup obtenido.Realmente, no toda la implementación de DAR-TEL ha sido paralelizada, De hecho, después de realizarun estudio de perfilado las tres partes con mayorcoste computacional son las mostradas en el Algoritmo1. Según este estudio, las operaciones correspondientesal Small Deformations representan,aproximadamente, el 3.75 % del tiempo total de ejecución;la Jacobian Composition representa cerca del40 % del tiempo total de ejecución; y el FMG representael 28.7 % del tiempo total de ejecución. Estasfases son similares en ambas partes, representando almenos el 73 % del tiempo total de ejecución.Tratando cada una de estas operaciones de formaindependiente, el speedup para Small Deformationses de hasta 24×; el speedup para JacobianComposition es de hasta 13, 5×; y el speedupSpeedupSpeedup54.543.5320 3054.543.5Número de imágenes31 2 3 4Número de imágenesFig. 2. Speedup total alcanzado.para FMG es de hasta 2, 6×.Sin embargo, la parte secuencial del algoritmo evitaobtener un mejor rendimiento. De hecho, hemosobtenido una implementación con un speedup mediode 3.95 para la primera parte, y de 4.22 para la segunda.Por otro lado, la Figura 3 muestra el consumoeléctrico para ambas partes (primera - arriba y segunda- abajo) de DARTEL. Los resultados correspondenal primer caso de la Tabla 1 para cada parte.En los demás casos el resultado sigue la misma tendencia.Como se puede observar en la Figura 3, lospicos de consumo de la implementación basada enGPU son mayores que en la implementación secuencial.Estos picos corresponden a las transferencias entrela memoria de la CPU y la memoria de la GPU.Sin embargo, el valor medio de la implementaciónbasada en GPU es ligeramente superior al de laimplementación secuencial. Por lo tanto, la implementaciónparalela consume menos energía que laimplementación secuencial debido a la significativareducción en tiempo de ejecución.Para la primera parte, el consumo de energíamedio para la implementación secuencial ha sido de134.47 w durante 7723.8 s con un gasto total de1,038,619.39 J; para la implementación paralela hasido de 170.78 w durante 1964.8 s con un gasto totalde 335,548.54 J. De otra manera, en la segunda parteel consumo medio para la implementación secuencialha sido de 134.66 w durante 374.3 s con un consumoJP2011-708

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011VatiosVatios300250200150100SecuencialParalelaMedia SecuencialMedia Paralela500 1964.8 7723.8300250200150100Tiempo(s)SecuencialParalelaMedia SecuencialMedia Paralela500 88.9 374.3Tiempo(s)Fig. 3. Consumo de energía de DARTEL.total de 50,403.24 J y para la implementación paralelaha sido de 173.75 w durante 88.9s con lo quese obtiene 15,446.38 J. Por lo tanto, se han conseguidounos beneficios del 67.69 % y del 69.35 % para laprimera y segunda parte respectivamente.V. ConclusionesEl análisis de imagen en el ámbito de la medicinaes una disciplina cada vez más imprescindible,siendo los algoritmos de registro deformable unos delos más importantes por la valiosa información queofrecen. En este trabajo se ha presentado un nuevaimplementación del algoritmo de registro deformableDARTEL que acelera el tiempo de ejecución con respectoa la versión secuencial disponible. Dicha implentaciónha sido obtenida para una plataformaheterogénea basada en GPU, haciendo uso de CU-DA. DARTEL realiza un registro basado en atlas deimágenes cerebrales en tres dimensiones. Las principalesfunciones de DARTEL consisten en procesarun gran conjunto de matrices asociadas a los puntosde las imágenes. Se ha explotado el paralelismoa nivel de punto ya que el procesamiento asociadoa cada uno de ellos es independiente del aplicado alresto. Los resultados obtenidos muestran una significanteredución en tiempo de ejecución y en consumoeléctrico, que en media suponen factores de 4 y 3,2respectivamente.AgradecimientosEste trabajo ha sido parcialmente financiado por elproyecto AlzTools (Ref: TSI-020110-2009-362) concedidopor el Ministerio de Industria, Turismo yComercio.Referencias[1] L.G. Brown, A survey of image registration techniques,ACM Computing Surveys 24, 326-376 (1992).[2] B. Zitová, J. Flusser, Image registration methods: a survey,Image and Vision Computing 21, 977-1000 (2003).[3] J. V. Hajnal, D. L. Hill, D. J. Hawkes, Medical ImageRegistration, CRC Press (2001).[4] J. Ashburner, A fast diffeomorphic image registration algorithm,NeuroImage 38, 95-113 (2007).[5] J. Ashburner, Computational anatomy with the SPM software,Magnetic Resonance Imaging 27, 1163-1174 (2009).[6] SPM, Statistical Parametric Mapping Framework, http://www.fil.ion.ucl.ac.uk/spm/.[7] GPGPU, General-purpose computation using graphicshardware, http://www.gpgpu.org.[8] J. D. Owens, D. Luebke, N. Govindaraju, M. harris, J.krüger, A. E. Lefohn, T. Purcell, A survey of generalpurposecomputation on graphics hardware, ComputerGraphics Forum 26, 80-113, (2007).[9] C. Vetter, C. Guetter, C. Xu, R. Westermann, Non-rigidmulti-modal registration on the GPU, Medical Imaging2007: Image Processing vol. 6515, pp. 651228 (2007).[10] G. C. Sharp, N. Kandasamy, H. Singh, M. Folkert, GPUbasedstreaming architectures for fast cone-beam CT imagereconstruction and Deamons deformable registration,Physics in Medicine and Biology 52(19), 5771-5783, 2007.[11] A. Khamene, R. Chisu, W. Wein, N. Navab, F. Sauer, Anovel projection based approach for medical image registration,WBIR, vol. 4057, pp. 247-256 (2006).[12] F. Ino, J. Gomita, Y. Kawasaki, K. Hagihara, A GPG-PU approach for accelerating 2-D/3-D rigid registrationof medical images, Parallel and Distributed Processingand Applications (ISPA), vol. 4330, pp. 939-950 (2006).[13] A. Khamene, P. Bloch, W. Wein, M. Svatos, F. Sauer,Automatic registration of portal images and volumetricCT for patient positioning in radiation therapy, MedicalImage Analysis, pp. 96-112 (2006).[14] K. Kim, S. park, H. Hong, Y. G. Shin, Fast 2D-3D registrationusing GPU-based preprocessing, 7th InternationalWorkshop on Enterprise Networking and Computing intHealthcare Industry, pp. 139-143 (2005).[15] O. Sadowsky, J. D. Cohen, R. H. Taylor, Rendering tetrahedralmeshes with higher-order attenuation functions fordigital rediograph reconstruction, IEEE Visualization, pp.303-310 (2005).[16] NVIDIA, NVIDIA CUDA Compute Unified DeviceArchitecture-Programming Guide, Version 3.1 2009,http://www.nvidia.com/object/cuda_home.html.[17] M. F. Beg, M. I. Miller, A. Trouvé, L. Younes, Computinglarge deformation metric mapping via geodesic flows ofdiffeomorphisms, Computer Vision 61, 139-157 (2005).[18] H. W. Press, S. A. Teukolsky, W. T. Vetterling, B. P.Flannery, Numerical recipes in C, 2nd ed. CambridgeUniv. Press, 1992.[19] Roberto Uribe Paredes, Pedro Valero Lara, EnriqueArias Antúnez, José Luis Sánchez García, Diego CazorlaLópez, GPU-based implementation for Range Queries onSpaghettis Data Structures, Technical Report DIAB-10-12-1, Computing Systems Dept., University of Castilla-LaMancha (2010).JP2011-709

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-710

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Compilación para sistemas de altas prestacionesJP2011-711

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011JP2011-712

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Checkpoint Size Reduction in Application-levelFault Tolerant SolutionsIván Cores, Gabriel Rodríguez, María Martín and Patricia González 1Abstract— Systems intended for the execution oflong-running parallel applications should providefault tolerant capabilities, since the probability of failureincreases with the execution time and the numberof nodes. Checkpointing and rollback recovery isone of the most popular techniques to provide faulttolerancesupport. However, in order to be useful forlarge scale systems, current checkpoint-recovery techniquesshould tackle the problem of reducing checkpointingcost. This paper addresses this issue throughthe reduction of the checkpoint file sizes. Different solutionsto reduce the size of the checkpoints generatedat application level are proposed and implemented ina checkpointing tool. Detailed experimental resultson a multicore cluster show the effectiveness of theproposed methods.Keywords—Fault Tolerance; Checkpointing; ParallelProgrammingI. IntroductionCurrent trends in high-performance computing(HPC) systems show that future improvements inperformance will be achieved through increases insystem scale. Todays large computational problemscan be solved in clustered multi-core systems withcore numbers in the range of one-hundred thousandto one million and more. However, as parallel platformsincrease their number of resources, so does thefailure rate of the global system [1]. Thus, programmerswill need a way to ensure that not all computationdone is lost on machine failures.Many fault tolerance methods for parallel applicationsexist in the literature, checkpoint-recovery [2]being one of the most popular. It periodically savesthe computation state to stable storage, so that theapplication execution can be resumed by restoringsuch state. The overhead of saving checkpoints todisk is the main performance cost in checkpointrecoverymethods.Most existing checkpoint systems are implementedat the operating system level. In system-level checkpointing(SLC) the whole state of the processes (programcounter, registers and memory) are saved tostable storage. The most important advantage ofthis approach is its transparency. However, checkpointingto a parallel file system is expensive at largescale [1], [3]. Moreover, I/O bandwidths of largescalefacilities do not increase as quickly as their computationalcapability [4]. Therefore, complete SLCof large parallel machines could become impracticable.A more attractive alternative for current andfuture HPC systems is application-level checkpointing(ALC), where the application program saves and1 Computer Architecture Group, Universityof A Coruña, Spain. E-mail:{ivan.coresg,grodriguez,mariam,pglez}@udc.esrestores its own state, which allows to store onlyuserspace data.The aim of this paper is to evaluate different techniquesto reduce the checkpoint sizes and, thus, thecomputational and/or I/O cost of checkpointing inALC approaches. The rest of the paper is organizedas follows. Section II proposes different techniques tooptimize the checkpoint sizes in ALC solutions. SectionIII explains the implementation details of thosetechniques on an ALC tool. Section IV evaluates theperformance of the proposed methods. Section V describesrelated work. Finally, Section VI concludesthe paper.II. Checkpoint Size Optimization onApplication-Level CheckpointingThe majority of the checkpointing tools proposedin the literature work at the system level. The basicdifference between SLC and ALC, in terms of statefile size optimizations, surges from the fact that SLCsees the application memory as a single continuum,while ALC distinguishes a disperse set of contiguousmemory blocks, each containing memory allocated toone or more variables. The exact number depends onthe aliasing relationships of the application data.The following sections deal with the utilization ofdifferent checkpoint size optimization solutions intoan application-level approach focusing on its applicationto array variables. In the context of ALC, morenoticeable gains can be achieved by applying optimizationtechniques only to array variables. Applyingthem also to scalar variables results in minimaldifferences in state file sizes and adds performanceoverhead derived from the analyses required to instrumentthe target optimizations.A. Live variable analysisThe knowledge of application memory in ALC canbe used to select those variables that are live duringthe creation of state files, avoiding storage ofdead variables. Depending on the considered application,applying this technique can significantlyreduce checkpoint file sizes.The identification of these variables can be performedat compile-time through a standard live variableanalysis. A variable x is said to be live at agiven statement s in a program if there is a controlflow path from s to a use of x that contains no definitionof x prior to its use. The set LV in of livevariables at a statement s can be calculated usingthe following expression:LV in (s) = (LV out (s) − DEF (s)) ∪ USE(s)JP2011-713

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011where LV out (s) is the set of live variables after executingstatement s, and USE(s) and DEF (s) arethe sets of variables used and defined by s, respectively.The live variable analysis should take intoaccount interprocedural data flow.Checkpoints in application-level approaches areusually triggered by an explicit call to a checkpointfunction in the application code. This guaranteesthat checkpoints are not performed during a systemcall, which may have internal state unknown to thecheckpointer, but rather inside user-level code. Inthis way, checkpoint callsites are limited and knownat compile time, which allows for the live variableanalysis to be bounded and not span the whole applicationcode. For each checkpoint callsite c i , it is onlynecessary to store the set of variables which are livewhen the control flow enters the callsite, LV in (c i ).Live variables should be marked for inclusion in futurecheckpoints right before the checkpoint callsite.Variables that become dead following the control flowmay be unmarked, further reducing the sizes of futurecheckpoint files.B. Incremental checkpointing and zero-blocks exclusionThe most popular technique for checkpoint file sizereduction in SLC approaches is incremental checkpointing[5], [6], [7]. This technique involves creatingtwo different types of checkpoints: full and incremental.Full checkpoints contain all the application data.Incremental checkpoints only contain data that haschanged since the last checkpoint. Usually, a fixednumber of incremental checkpoints is created in betweentwo full ones. During a restart, the state isrestored by using the most recent full checkpoint file,and applying in an ordered manner all the differencesbefore resuming the execution.There exist in the literature different solutionsto implement incremental checkpointing in SLC approaches.One of them is to use the virtual memorypage protection mechanisms [5]: upon startinga checkpoint, pages to be saved are marked as readonly.When the page is effectively saved into thecheckpoint its original status is recovered. When theapplication tries to write to a read-only page, therace condition is resolved by the fault handler. Anotheroption is to use a kernel-level memory managementmodule that employs a page table dirty bitscheme [7]. The third classical choice is the hashbasedcheckpoint [6], which uses a secure hash functionto obtain a unique identifier for each block ofapplication memory to be written into state files.This value is stored and compared against the valuecalculated for the same block upon creating a newcheckpoint. If the two hash values differ, the blockcontents have changed and it is stored again in thenew checkpoint file.In ALC it is unadvisable to track changes to memoryblocks using the virtual memory page protectionmechanism or dirty bits as array variables donot necessarily start at page boundaries. Evaluating0 1 2 3 4 5 6 7 8 9 ...H-0 H-1 H-2 H-3 H-4 H-5 H-6 H-7 H-8 H-9...0 1 2 6 7 9 ...0 1 2 3 4 5 6 7 8 9 ...H-0 H-1 H-2*H-3*H-4*H-5*H-6* H-7 H-8 H-92 3 4 5 6Data blockFig. 1.HDDEmpty blockHDDCheckpoint 2(Incremental)Block modifiedsince last ckpt.Checkpoint 1(Full)0H-0Block idHash valueMemory of array AContinueexecutionMemory of array AConstruction of an incremental checkpointMark ofempty blockmemory changes for each array as a whole is also unadvisable,following the locality principle. The bestcompromise is to divide array variables into chunksof memory of a previously specified size, assumed tobe constant, and control changes into these chunksusing a secure hash function. The calculated hashvalue for each chunk of memory is stored in memoryand used for comparison when creating incrementalcheckpoints.When working with real scientific applications itis well known that quite often many elements of thearrays are null, resulting in memory blocks that containonly zeros. Therefore, a possible optimizationto further reduce the checkpoint file size is to avoidstorage of those zero-blocks. In addition to controlthe changes into memory blocks, the hash functionmay be used to detect zero-blocks. Once a zero-blockis detected, instead of dumping it into the checkpointfile, a small marker is saved indicating that this blockis zero. During restart this marker is identified andthe target memory is filled with zeros, which recoversthe original state at a negligible cost in terms ofboth performance and disk usage. The constructionof an incremental checkpoint is depicted in Figure 1.The process of restarting from incremental checkpointsis shown in Figure 2. The last available fullcheckpoint is restored first, and the updates containedin each incremental checkpoint are then appliedin an ordered manner.III. ImplementationThe techniques described in Section IIhave been implemented on CPPC [8], anopen-source checkpointing tool available fromhttp://cppc.des.udc.es under GPL license.A. CPPC overviewCPPC is an application-level checkpointing toolfocused on the insertion of fault tolerance into longrunningmessage-passing applications. It is designedwith special focus on portability: it uses portablecode and protocols, and generates portable checkpointfiles, allowing for execution restart on differentJP2011-714

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 20110 1 2 6 7 9 ...0 1 2 3 4 5 6 7 8 9 ...Data blockFig. 2....Empty blockHDDCheckpoint 1(Full)Checkpoint 2 (Incremental)HDD2 3 4 5 6Overwritten blockStep 1Step 2Memory of array AMark ofempty blockRestart from an incremental checkpointRestartFig. 3. Integration of a parallel application with the CPPCframeworkarchitectures and/or operating systems.CPPC appears to the user as a compiler tool anda runtime library. The integration between the applicationand the CPPC framework is automaticallyperformed by the CPPC compiler, a source-to-sourcetool that converts an application code into an equivalentversion with added checkpointing capabilities.The global process is depicted in Figure 3. At compiletime, the CPPC compiler instruments the codeby inserting calls to the CPPC library. At runtime,the application will send petitions to the CPPC controller.From the structural point of view, the controllerconsists of three basic layers: a facade, thatkeeps track of the state to be stored when the nextcheckpoint is reached; the checkpointing layer, whichgathers, manages and puts together all data to bestored into the state files; and a writing layer whichdecouples the other two layers from the specific fileformat used for state storage. Currently CPPC providesa writing plugin based on the Hierachical DataFormat 5 (HDF5) [9], a hierarchical data format andassociated library for the portable transfer of graphicaland numerical data between computers.B. Live variable analysisThe live variable analysis explained in Section II-Aconstitutes one of the passes of the CPPC compiler.It does not currently perform optimal bounds checksfor pointers and arrays variables. This means thatsome arrays and pointers are registered in a conservativeway: they are entirely stored if they are usedat any point in the re-executed code.When dealing with calls to precompiled procedureslocated in external libraries, the default behavior isto assume all parameters to be of input type. Therefore,all not previously included variables containedin the set LV in (s p ), being s p the analyzed procedurecall, will be marked for inclusion.C. Incremental checkpointing and zero-blocks exclusionFor the implementation of incremental checkpointing,the HDF-5 writer was modified to divide arrayvariables into blocks of memory. The size ofthese memory blocks may have a great impact on theperformance of the incremental checkpointing technique.CPPC allows the user to choose the size tobe applied to each particular application.The new HDF-5 writer also calculates the hashvalues of the memory blocks. The choice of thehash function impacts the correctness, since manyhash functions present a significant probability ofcollisions, that is, situations where a memory blockchanges from one checkpoint to the next checkpointbut its hash value remains the same. Secure hashfunctions should be used to implement reliable incrementalcheckpointing techniques [10]. The implementationof incremental checkpointing in CPPC allowsthe user to choose between different secure hashfunctions, such as MD5 or SHA.The calculated hash functions are used to detectboth zero-blocks that can be excluded in thenext checkpoint and changes in the memory blocksfrom previous checkpoints. In order to detect zeroblocksthe calculated hash values are compared to theknown hash value of a zero-block. To detect changesin the memory blocks, the hash values calculated inprevious checkpoints have to be stored to be comparedwith the new ones. In our implementation,the hash codes are stored into main memory ratherthan in disk, to improve the performance of the technique.Only the modified blocks with non-zero elementswill be stored in the checkpoint file. In order to enablefull data recovery during restart, an identifier isstored in the checkpoint file for each modified memoryblock, including zero-blocks (see Figure 1 andFigure 2). This identifier indicates the original positionof the block in memory relative to the start ofthe array. CPPC uses the high-order bit of the identifierto mark the zero-blocks that are not includedin the checkpoint file but should be restored in thisstep.In addition to the checkpointing mechanism, therestart mechanism has also been modified to complywith incremental checkpointing as described inSection II-B. The last available full checkpoint is restoredfirst and the modifications contained in theassociated incremental checkpoints are orderly updated.IV. Experimental ResultsThis section assesses the impact of the describedoptimization techniques in the size of the checkpointJP2011-715

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE ICheckpoint sizes per process (in MB)IncrementalNPB SLC ALC Base LiveVar Full Incr. 1 Incr. 2BT (B.4) 175.98 109.95 109.76 106.48 95.02 95.02CG (C.8) 219.85 151.65 66.33 58.74 2.48 2.48EP (C.8) 67.42 1.18 1.04 1.04 1.04 1.04FT (C.8) 962.93 768.14 640.10 640.18 512.15 512.15IS (C.8) 354.52 288.12 288.10 192.18 46.48 47.95LU (B.8) 93.51 27.16 26.69 26.62 20.03 20.03MG (C.8) 502.15 435.89 435.85 303.25 303.04 303.04SP (B.4) 168.55 102.35 102.25 96.36 77.33 77.33files and in the execution time overheads. A multicorecluster was used to evaluate our proposal. Itconsists of 16 nodes, each one of them powered bytwo Intel Xeon E5620 quad-core CPUs with 16 GBof RAM. The cluster nodes are connected throughan Infiniband network. The front-end is powered byone Intel Xeon E5502 quad-core CPU with 4 GB ofRAM. The connection between the front-end and theexecution nodes is an Infiniband network too. Finally,the working directory is mounted via NFS andis connected to the cluster by a Gigabit Ethernetnetwork.The application testbed was comprised of the eightapplications in the MPI version of the NAS ParallelBenchmarks v3.1 [11] (NPB from now on). These arewell-known and widespread applications that providea de-facto test suite. Out of the NPB suite, the BT,LU and SP benchmarks were run using class B, whilethe rest were run using class C due to memory constraints.The experiments can be divided into two blocks.The first block analyzes the checkpoint size optimizationobtained using the proposed techniques.The second block evaluates the execution overheadcaused by the computation of the hash functions, andthe restart overhead caused by the restart mechanismin the incremental technique. All the experimentswere run on a single node using all the 8 cores, exceptfor BT and SP, that run over 4 cores, as they requirea square number of processes. All the checkpointfiles were stored into the working directory mountedvia NFS.A. Checkpoint file sizesThe reduction in checkpoint file size is the maingoal of the techniques described in this work. TableI allows to compare the checkpoint file size reductionobtained by the different techniques. Thefirst column shows results for a SLC approach. Thesecond column shows results for an ALC approachwithout applying any optimization technique (basecase), that is, all the user variables are stored inthe checkpoint file. The remaining columns showresults for checkpoint file sizes when using the livevariable analysis and the incremental checkpointingtechnique proposed in this paper. Two incremen-TABLE IICheckpoint latency (in s)IncrementalNPB ALC Base LiveVar Full Incr. 1BT 5.65 5.42 5.55 5.26CG 14.24 6.52 5.42 0.39EP 0.05 0.07 0.05 0.03FT 89.56 62.25 65.40 50.29IS 26.48 26.81 17.10 4.95LU 2.68 2.78 2.50 1.87MG 39.36 37.89 28.24 27.33SP 5.05 5.37 5.21 4.30tal checkpoints were created after a full checkpoint.As can be seen, ALC obtains better results than theSLC approach and its checkpoint files can be furtherreduced using the optimization techniques proposedin this paper.Live variable analysis significantly reduces checkpointfile sizes for CG (56.26% of reduction) and obtainsa considerable gain in FT (16.7%). It can beconcluded that this technique may have great influenceon reducing file sizes for certain applicationsand, as it introduces overhead only at compile time,no application can be adversely affected by its use.The incremental checkpointing proposed in thispaper achieves important file size reductions for almostall the applications. Note that reductionsachieved in the full checkpoint relative to the livevariable technique are due to the elimination of zeroblocks.These reductions may vary with the size ofthe memory block. Table I shows results for memoryblocks of 8K elements, where reductions respect tothe base case range from 3% (BT) to 60% (CG) forthe full checkpoint and from 12% (BT) to 98% (CG)for the incremental checkpoints.B. Checkpoint latencyTable II shows the checkpoint latency obtained forthe different NPB applications. The checkpoint latencyis defined as the ellapsed time between the callto the checkpointing function and the return of controlto the application. The experiments were repeated10 times for each application and the mini-JP2011-716

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011TABLE IIIRestart times (in s)NPB ALC Base LiveVar Zero Incr.BT 4.44 5.22 4.55 11.15CG 11.71 6.02 4.56 4.54EP 0.10 0.09 0.09 0.24FT 58.36 48.80 49.92 156.46IS 22.03 22.05 15.01 20.83LU 2.08 2.04 2.08 4.90MG 33.12 33.12 23.81 66.14SP 4.31 4.32 4.08 9.42mum time obtained is reported.The main goal of the experiment is to measure theoverhead introduced by the computation of the hashfunctions and the inspections needed to create theincremental checkpoint. The hash function selectedin CPPC for these experiments was MD5. From theresults, it can be observed that the overhead introducedby the incremental checkpointing technique ishidden by the gain obtained from the reduction incheckpoint size. Results for the creation of the fullcheckpoint in the incremental technique allow alsoto assess the gain obtained when solely applying thezero-blocks exclusion.In general, both the live variable analysis, whoseoverhead is moved to compile time, and the incrementalcheckpointing technique with zero-blocks exclusion,perform better than the base approach. Insome cases the reduction in checkpoint overhead canbe as high as 30 − 40% (CG or IS).CPPC can be configured so that the checkpoint isbuilt in parallel with the execution of the applicationby creating new threads. Thus, the application executiondoes not have to be stalled until the checkpointsare created and the above latencies may behidden.C. Restart overheadRestart times are shown in Table III. The restarttime includes the read of the checkpoint files and therestart of the application to the point where the thecheckpoint was dumped. Again, at least 10 executionswere performed for each application and theminimum time obtained is reported. The memorywas freed before each execution to avoid the effectof page cache and to guarantee that checkpoint filesare read from disk.Column labeled as “Zero” shows the restart overheadwhen there is no incremental checkpoint file butthe full one. These results allow to evaluate the overheadwhen applying only the zero-blocks exclusion,which is always less than the overhead of the baseapproach.The incremental checkpointing technique presentsa high overhead at restart compared to the others.This is due to a larger volume of data to be movedand read in the case of incremental checkpointing(that can be calculated as the sum of the last threecolumns of Table I). A possible approach to reducethis overhead would be to bring together thefull checkpoint file and the incremental ones into anunique file at the checkpoint server before a restartis required. The number of incremental checkpointswill have a great influence in the restart overhead.There exist studies [12] that provide a model to determinethe optimal number of incremental checkpointsbetween two consecutive full checkpoints.V. Related WorkThe live variable analysis, presented in Section II-A, can be seen as a complementary approach tomemory exclusion techniques proposed by Plank etal. [13].As regards incremental checkpointing, as mentionedin Section II-B, there exist in the literaturea number of techniques to implement it in SLC [5],[6], [7], [14], [15], [16]. The implementation proposedin this paper is inspired by the hash-based approaches[6], [16] but it is intended for ALC. Usingan application-level approach reduces drastically thenumber of memory blocks to be checked in runtimeand, thus, the overhead of the approach. The reductionin the number of analyzed blocks implies also areduction in the size of the hash tables to be stored.This reduction allows to store these tables into mainmemory instead of disk, reducing even more the overheadof the technique. Additionally, the size of thegenerated checkpoint files is reduced through the detectionand elimination of zero-blocks.The idea of not storing zero-blocks has a certainsimilarity to the technique used in the SLCtool Berkeley Lab’s Checkpoint/Restart (BLCR) Library[17] to exclude zero pages, that is, those thathave never been touched and logically contain all zeros.Other alternative present in the literature to reducethe checkpoint size is data compression. Itwas implemented, for instance, in the CATCH compiler[18] and ickp checkpointer [19]. Experimentalresults show that compression significantly reducescheckpoint sizes. However, the potential benefits ofcompression for reducing the overhead of checkpointingdepend on the time required to compress data,the compression rate and the ratio of processor speedto disk speed.CATCH also implements adaptive checkpoint,that is, it uses a heuristic algorithm to determinethe optimal places, in terms of checkpoint size, toinsert checkpoints. This technique could be usefulfor programs with large variations in memory usage.All the techniques mentioned so far focus on reductionof the checkpoint file sizes. Another wayto reduce the computational and I/O cost of checkpointingis to avoid the storage of checkpoint files onthe parallel file system. In [20] Plank et al. proposedto replace stable storage with memory and processorredundancy. Some recent works [21], [22], [23] haveadapted the technique, known as diskless checkpointing,to contemporary architectures. The main draw-JP2011-717

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011back of diskless checkpoiniting is its large memoryrequirements.VI. Concluding RemarksThis work has analyzed different alternatives toreduce the size of the checkpoint files generated inALC approaches: live variable analysis, zero-blockselimination and incremental checkpointing. Thetechniques have been implemented in an ALC tool,CPPC, obtaining important file size reductions.The reduction of the checkpoint sizes will be particularlyuseful for parallel applications with a largenumber of parallel processes, where the transferenceof a large amount of checkpoint data to stable storagecan saturate the network and cause a drop inapplication performance.The results have shown that incremental checkpointingis the most effective of the three exploredmethods in terms of checkpoint size reduction. However,global storage requirements increase for thistechnique as it is necessary to keep stored at leastone full checkpoint and all the incremental ones associated.Additionally, it complicates the restart,resulting in an overhead that may become importantdepending on the number of incremental checkpointsand the characteristics of the network. The resultsindicate that merging the checkpoint files beforerestarting could significantly reduce restart times.As regards live variable analysis and zero-blockelimination techniques, the checkpoint size reductionsobtained are not as significant, however, theydecrease globally the storage demand and are ableto reduce the overhead of both the checkpoint filewriting and the restart phase. At present, our implementationof the live variable analysis does notperform optimal bounds checks for pointer and arrayvariables. This means that they are entirely storedif they are used at any point in the re-executed code.Thus, there is still room for future optimizations inthis compilation analysis.AcknowledgmentThis research was supported by the Ministry ofScience and Innovation of Spain (Project TIN2010-16735) and by the Galician Goverment (Project10PXIB105180PR).References[1] Bianca Schroeder and Garth A Gibson, “Understandingfailures in petascale computers,” Journal of Physics:Conference Series, vol. 78, no. 1, pp. 012022, 2007.[2] E.N. Elnozahy, L. Alvisi, Y.-M. Wang, and D.B. Johnson,“A survey of rollback-recovery protocols in messagepassingsystems,” ACM Computing Surveys, vol. 34, no.3, pp. 375–408, 2002.[3] Franck Cappello, “Fault tolerance in petascale/ exascalesystems: Current knowledge, challenges and researchopportunities,” International Journal of High PerformanceComputing Applications, vol. 23, no. 3, pp. 212–226, 2009.[4] Kamil Iskra, John W. Romein, Kazutomo Yoshii, andPete Beckman, “Zoid: I/o-forwarding infrastructure forpetascale architectures,” in Proceedings of the 13th ACMSIGPLAN Symposium on Principles and practice of parallelprogramming. 2008, PPoPP ’08, pp. 153–162, ACM.[5] J. S. Plank, J. Xu, and R. H. B. Netzer, “Compresseddifferences: an algorithm for fast incremental checkpointing,”Tech. Rep. CS-95-302, University of Tennessee, Departmentof Computer Science, Aug. 1995.[6] S. Agarwal, R. Garg, and M. S. Gupta, “Adaptive incrementalcheckpointing for massively parallel systems,”in Proceedings of the 18th Annual International Conferenceon Supercomputing (ICS’04), Saint Malo, France,26 June–01 July 2004, pp. 277–286, ACM, New York.[7] R. Gioiosa, J. C. Sancho, S. Jiang, and F. Petrini, “Transparent,incremental checkpointing at kernel level: a foundationfor fault tolerance for parallel computers,” in Proceedingsof the ACM/IEEE SC2005 Conference on HighPerformance Networking and Computing (SC’05), Seattle,WA, USA, 12–18 November 2005, IEEE ComputerSociety Press, Los Alamitos.[8] G. Rodríguez, M.J. Martín, P. González, J. Touriño, andR. Doallo, “CPPC: A compiler-assisted tool for portablecheckpointing of message-passing applications,” Concurrencyand Computation: Practice and Experience, vol.22, no. 6, pp. 749–766, 2010.[9] The HDF5 Group, “HDF-5: Hierarchical Data Format,”http://www.hdfgroup.org/HDF5/. Last accessedJune 2010.[10] Hyo-Chang Nam, Jong Kim, SungJe Hong, and SungguLee, “Secure checkpointing,” Journal of Systems Architecture,vol. 48, pp. 237–254, 2003.[11] National Aeronautics and Space Administration, “TheNAS Parallel Benchmarks,” http://www.nas.nasa.gov/Software/NPB, Last accessed June 2010.[12] Nichamon Naksinehaboon, Yudan Liu, Chokchai (Box)Leangsuksun, Raja Nassar, Mihaela Paun, andStephen L. Scott, “Reliability-aware approach: An incrementalcheckpoint/restart model in hpc environments,”in Proceedings of the 2008 Eighth IEEE InternationalSymposium on Cluster Computing and the Grid, 2008,pp. 783–788.[13] J.S. Plank, M. Beck, and G. Kingsley, “Compiler-assistedmemory exclusion for fast checkpointing,” IEEE TechnicalCommittee on Operating Systems and ApplicationEnvironments, vol. 7, no. 4, pp. 10–14, 1995.[14] E.N. Elnozahy, D.B. Johnson, and W. Zwaenepoel, “Theperformance of consistent checkpointing,” in ReliableDistributed Systems, 1992. Proceedings., 11th Symposiumon, Oct. 1992, pp. 39 –47.[15] J. S. Plank, M. Beck, G. Kingsley, and K. Li, “Libckpt:Transparent Checkpointing under Unix,” in Usenix WinterTechnical Conference, January 1995, pp. 213–223.[16] Hyo-Chang Nam, Jong Kim, SungJe Hong, and SungguLee, “Probabilistic checkpointing,” in Fault-TolerantComputing, 1997. FTCS-27. Digest of Papers., Twenty-Seventh Annual International Symposium on, June 1997,pp. 48 –57.[17] Laurence Berkeley National Laboratory, “BerkeleyLab Checkpoint/Restart,” https://ftg.lbl.gov/CheckpointRestart/. Last accessed December 2010.[18] C.-C.J. Li and W.K. Fuchs, “Catch-compiler-assistedtechniques for checkpointing,” in Fault-Tolerant Computing,1990. FTCS-20. Digest of Papers., 20th InternationalSymposium, June 1990, pp. 74 –81.[19] James S. Plank and Kai Li, “ickp: A consistent checkpointerfor multicomputers,” IEEE Parallel Distrib.Technol., vol. 2, pp. 62–67, June 1994.[20] J. S. Plank, K. Li, and M. A. Puening, “Diskless checkpointing,”IEEE Transactions on Parallel and DistributedSystems, vol. 9, no. 10, pp. 972–986, October1998.[21] Zizhong Chen, Graham E. Fagg, Edgar Gabriel, JulienLangou, Thara Angskun, George Bosilca, and Jack Dongarra,“Fault tolerant high performance computing bya coding approach,” in Proceedings of the tenth ACMSIGPLAN symposium on Principles and practice of parallelprogramming, New York, NY, USA, 2005, PPoPP’05, pp. 213–223, ACM.[22] Leonardo Arturo Bautista Gomez, Naoya Maruyama,Franck Cappello, and Satoshi Matsuoka, “Distributeddiskless checkpoint for large scale systems,” ClusterComputing and the Grid, IEEE International Symposiumon, vol. 0, pp. 63–72, 2010.[23] Ge-Ming Chiu and Jane-Ferng Chiu, “A new disklesscheckpointing approach for multiple processor failures,”IEEE Transactions on Dependable and Secure Computing,vol. 99, no. PrePrints, 2010.JP2011-718

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Source-to-Source Transformations for EfficientSIMD Code GenerationAlejandro Berna 1 , Marta Jiménez 1 , Jose M. Llabería 1AbstractIn the last years, there has been much effort in commercial compilersto generate efficient SIMD instructions-based code sequencesfrom conventional sequential programs. However, thesmall numbers of compilers that can automatically use theseinstructions achieve in most cases unsatisfactory results. Therefore,the code often has to be written manually in assembly languageor using compiler built-in functions to achieve highperformance. In this work, we present source-to-source transformationsthat help commercial vectorizing compilers to generateefficient SIMD code. Experimental results show that excellentperformance can be achieved. In particular, for the problem ofmatrix product (SGEMM) we almost achieve as high performanceas hand-optimized numerical libraries. Our source-tosourcetransformations are based on the scalar replacement andunroll and jam transformations presented by Callahan et all. Inparticular, we extend the use of scalar replacement to vectorialreplacement and combine this transformation with unroll and jamand outer loop vectorization to fully exploit the vector registerlevel and thus to help the compiler to generate efficient SIMDcode. We will show experimentally the effectiveness of our proposal.Categories and Subject DescriptorsD.3.4 [Processors]: compilers, optimization: C.1.2 [MultipleData Stream Architectures (Multiprocessors)]: Singleinstruction-stream,multiple-data-stream processors (SIMD)General TermsAlgorithms, Performance.KeywordsSIMD; vectorization; source-to-source transformations; registertiling;1. IntroductionThe ISA of all today´s microprocessors has been extended withmultimedia instructions [9]. Multimedia extensions follow theSIMD paradigm by exploiting wide data paths and functionalunits that simultaneously operate on narrow data paths of packeddata elements (relatively short vectors that reside in memory orregisters). The number of packed data elements (VL) supportedby the SIMD instructions has been increased with each microprocessorgeneration, going from 64 bits data registers in thePentium II with the MMX technology to the 256 bits data registersin Sandy Bridge with the AVX1 technology. Moreover,SIMD extensions have also evolved in number of instructions1 Departament d’Arquitectura de Computadors, Universitat Politècnica deCatalunya, Barcelona, Spain, e-mail:{aberna, marta, llaberia}@ac.upc.eduand data types. MMX technology has 57 SIMD instructions andhandles only integer data types while AVX1 technology has hundredsof instructions and handles both integer and floating-point(single and double) data types[12][20].SIMD instructions are useful in multimedia and signalprocessing applications [23][30], but also in scientific and numericalapplications [1][8][18]. They offer higher performance, agood performance/power ratio, and better resource utilization.However, compilers still do not have good support for SIMDinstructions due to the difficulty of automatically vectorizingconventional sequential programs. The few commercial compilersthat can automatically use these instructions achieve in mostcases unsatisfactory results.To overcome the lack of adequate compiler support for SIMDextensions, often the code has to be written manually in assemblylanguage or using compiler built-in functions [12]. However,these methods, although very effective, are tedious, error proneand result in highly machine-specific code, so that porting anapplication to a new target processor requires significant programmingeffort.Manufacturers have tried to minimize the complexity of writingSIMD optimized codes by providing numerical libraries (suchas MKL [11]) that attain high performance under their particularmicroprocessor. However, not all applications can take advantageof these libraries and there are many situations in which none ofthe routines provided can specifically solve the task at hand.We believe that restructuring a code to better exploit SIMDcapabilities should be the job of a compiler. Compilers, not programmers,should handle the machine-specific details required toobtain high performance on each particular architecture. Algorithmshould be expressed in a natural machine-independentform and the compiler should apply the appropriate transformationto optimize the resulting code.In this paper, we present high level (source-to-source) transformationsthat help actual commercial vectorizing compilers togenerate efficient SIMD code on scientific numerical applications.The proposed transformations are simple enough to besuitable for automatic implementation by compilers.Our proposal is based on an effective use of the vector registers.As already known, the existence of a gap between memoryand CPU performance made effective use of the register file imperativefor excellent performance. It is well-known that theallocation of array values that exhibit reuse to registers can significantlyimprove the memory performance of programs. However,in many production compilers array references are left asreferences to main memory rather than references to registersbecause the data flow analysis used by the compiler is not powerfulenough to recognize most opportunities for reuse in subscriptedvariables.Callahan et all in [5] presented a source-to-source transformation,called scalar replacement, that exposed the reuse availablein array references in an innermost loop. They also showed experimentallyhow another loop transformation called unroll andJP2011-719

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011jam, could expose more opportunities for scalar replacement bymoving reuse across an outer loop into the innermost loop.In this work, we will apply the idea of scalar replacement andunroll and jam to vectorized loop nests and show experimentallytheir effectiveness. We refer as vectorial replacement to the scalarreplacement transformation applied to SIMD vectorized loopnests.Summarizing, the contribution of this paper are the following:An approach that combines 3 source-to-source transformations(outer-loop vectorization, unroll and jam ofvectorized loops and vectorial replacement) that helpcompilers to generate efficient SIMD code in scientificnumerical applications.Experimental evaluation exhibiting the impact of thesetransformations using simple kernels of loop nests on aNehalem platform.The rest of this paper is organized as follows: Section 2 explainsprevious work related to source-to-source loop transformations.Section 3 describes our approach to help the compiler tovectorize outer loops and to apply unroll and jam and vectorialreplacement. Section 4 gives an extended example using matrixproduct kernel. In Section 5 we show performance results of ourapproach compared to scalar version, inner-loop vectorized versionsand vendor supplied numerical libraries. Finally, Section 6concludes.2. Related WorkLittle published work exists which directly deals with high levelcode transformation techniques for processors with SIMD capabilities.Several researchers [3][7][15][19][21][24] have workedon vectorizing compilers, but not on high level (source-to-source)code transformations to help compilers to generate efficientSIMD codes. These researchers focus on automatically identifyvectorizable section of code and generate appropriate SIMD instructions.Their proposals are low level optimizations to be implementedinside compilers. Our work instead proposes highlevel transformations for generating efficient SIMD code whilewaiting for commercial compilers to implement novel approachesfrom previous researchers.Moreover, most of these auto-vectorization approaches focuson innermost loops [7][15][24] or block vectorization [4]. OnlyNuzman et all in [19] deals with outer loop vectorization andshow its effectiveness. Their proposal consists on implementingin-place outer loop vectorization inside the GCC compiler. Incontrast, we perform outer loop vectorization as a high level(source-to-source) transformation.Aditionally, Callahan et all in [5] presented a source-to-sourcetransformation, called scalar replacement, that exposes the reuseavailable in array references in an innermost loop. They alsoshowed experimentally how another loop transformation, calledunroll and jam, could expose more opportunities for scalar replacementby moving reuse across an outer loop into the innermostloop. In our work, we extend the use of scalar replacementand unroll and jam to SIMD vectorized loop nests and show experimentallytheir effectiveness. We do not know any previouswork that extends these techniques for SIMD codes.Finally, there exist several hand-coded numerical libraries optimizedfor SIMD processors [11][25] that achieve very highperformance for some particular class of microporcessors and forsome particular functions. However, as already mentioned, notall applications can take advantage of these libraries and thereare many situations in which none of the routines provided canspecifically solve the task at hand. Our techniques, instead, canbe applied to more general codes.3. Source-to-Source Code TransformationsOur approach to combine source-to-source transformations proposedin this work are based on three observations. First, weobserve that commercial compilers only perform inner loop vectorization.However, in most codes it is necessary to vectorizeouter loops to achieve high performance.Second, we observe that compilers are not able to unroll andjam loops with non unit stride. As we will see later, optimizingtransformations like register tiling [6][13][14] requires innerloops to be fully unrolled. Therefore, when combining registertiling with vectorization it sometimes becomes necessary to fullyunroll strip-mined (non-unit stride) loops and jam together theinner (vector) loops.Third, we observe that compilers are not able to allocate adjacentarray values to vector registers and exploit the reuse availablein array references in an innermost loop. However, it is wellknownthat the allocation of array values that exhibit reuse toregisters can significantly improve the memory performance ofprograms [6][13][14].In the next subsections we show how we solve these threecompilers limitations by applying source-to-source transformations.For the rest of this section and for simplicity, we assumethat loop nests are fully permutable and perfectly nested, andloop bounds are constants. For handle more general loop boundsthat are max or min functions of surrounding loop iteration variables,we would need to use the theory of unimodular transformationswhen performing loop permutation [16] and Index SetSplitting [29] for making sure that a particular loop perform aconstant number of iterations.We also assume that previous analysis to decide which loopsshould and could be vectorized has already been performed. Thispaper only focuses on the code generation phase of source-tosourcetransformations. Dependence and decision analysis toknow if transformations are legal and to decide which loop is thebest candidate to vectorize are out of the scope of this paper[2][17][22][23][26][27].3.1 Outer Loop VectorizationLet consider the following loop nest:for ( i1=L1; i1

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011for ( i=L; i

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Source codevoid cross_add(float *A, float *B,int dimi, int dimj){long int i, j, vi;for (i=0; i

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Source codevoid multiply(float* A, float* B,float* C, int dimi,int dimk, int dimj){long int i, j, k;for (i = 0; i < dimi; i++)for (j = 0; j < dimj; j++)for (k = 0; k < dimk; k++)C[i*dimj+j]+=A[i*dimk+k]*B[k*dimj+j];}ASM..LOOP_I:.....LOOOP_K:movq %rbx, %rcxmovq %r14, %rcxmovss (%r12,%rbp,4), %xmm0shufps $0, %xmm0, %xmm0..LOOP_J:movups (%rdx,%rcx,4), %xmm1movups 16(%rdx,%rcx,4),%xmm2mulps %xmm0, %xmm1mulps %xmm0, %xmm2addps (%rsi,%rcx,4), %xmm1addps 16(%rsi,%rcx,4),%xmm2movaps %xmm1, (%rsi,%rcx,4)movaps %xmm2, 16(%rsi,%rcx,4)addq $8, %rcxcmpq %r10, %rcxjb ..LOOP_Jaddq %r9, %r15incq %rbpcmpq %r8, %rbpjb ..LOOP_K...jb ..LOOP_IFigure 6. Matrix product. The left column shows the sourcecode and the right the assembly code.the loop nest (no matters which is the original loop order) makingloop j the innermost loop. Since icc only performs inner loopvectorization, this loop order allows icc to vectorize loop j.Moreover, loop j is unrolled by a factor of 8 (2 vectors). Finally,icc also exploits the reuse of the invariant reference of matrix Ain the inner loop j by loading it only once in a vector registerduring the execution of loop j.Our objective in this section is to generate an efficient codethat fully exploits the register level of the memory hierarchy andthe SIMD capabilities of the target machine. To this end, we firstapply register tiling [6][14][26] to the source code as shown inFigure 7a. BI and BJ are the tile sizes in dimension i and j, respectively,and their values depend on the available SIMD registersand their sizes on the target architecture. For simplicity andwithout loss of generalization, we assume dimi and dimj to bemultiple of BI and BJ, respectively.It is well-known that loop tiling [16] is loop transformationthat a compiler can use to automatically create block algorithms.The advantage of block algorithms is that, while computing withina block, there is a high degree of data locality, allowing betterregister, cache or memory hierarchy performance. Loop tiling forany memory level can be implemented by combining two wellknowntransformations: strip-mining and loop interchange. However,the implementation of tiling for the register level requiresan extra phase not needed for other memory levels. Since registersare only addressable using the register number, it is necessaryto fully unroll the loops that traverse the iterations inside theregister tiles. Therefore, in our example of Figure 7a, it is necessaryto fully unroll loops i and j to exploit the register level. Atlast, scalar replacement [5][6] can be used to eliminate redundantloads and stores in the new unrolled loop body.When combining register tiling with vectorization we needfirst vectorize the desired loop (loop j, in our example) beforefully unroll the register tile. Thus, the outer loop j is vectorizedas explained in subsection 3.1. We apply strip-mining to loop jwith a step size of VL and then permute the resulting elementlong int ii, jj, i, j, k; a)for (ii = 0; ii < dimi; ii+=BI)for (jj = 0; jj < dimj; jj+=BJ)for (k = 0; k < dimk; k++)for(j = jj; j < jj+BJ; j++)for(i = ii; i < ii+BI; i++)C[i*dimj+j]+=A[i*dimk+k]*B[k*dimj+j];loop of VL iterations to become the innermost (the vector statement).The resulting code is shown in Figure 7b assuming BJ ismultiple of VL for simplicity.As already mentioned, now it is necessary to fully unroll theloops that traverse the iterations inside the register tile (loop iand j in Figure 7b). To fully unroll the strip-mined loop j weperform unroll and jam as explained in Section 3.2. The resultingcode is shown in Figure 8a, assuming BI = 2 and BJ=2*VL.At this point icc vectorizes dimension j keeping loop k as innermostloop. However, icc does not remove redundant vectorloads and stores from the new unrolled loop body. As we can seein Figure 8c, the elements of C are loaded and stored in eachiteration of loop k unnecessarily. Therefore we need to applyvectorial replacement to reference C as explained in section 3.3.Figure 8b shows the resulting source code using pointers as temporaryvariables to identify the adjacent array references. We cansee in Figure 8d how icc is now able to remove redundant memoryinstructions.Summarizing, by combining register tiling with the source-tosourcetransformations proposed in Section 3, we help icc compilerto generate efficient code that fully exploit the register leveland the SIMD capabilities of the target machine.5. Performance ResultsFirst details of our evaluation environment are presented includinga description of the architecture, compiler and kernels used.Then, kernel performance is described and analyzed.5.1 Evaluation environmentAll kernels in this study have been executed in the same machineand compiled by the same version of the icc with the same flagsand options.Target architecturelong int ii, jj, i, j, k, vj; b)for (ii = 0; ii < dimi; ii+=BI)for (jj = 0; jj < dimj; jj+=BJ)for (k = 0; k < dimk; k++)for(j = jj; j < jj+BJ; j+=VL)for(i = ii; i < ii+BI; i++)for(vj=j; vj

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Source codelong int ii, jj, k, vj; a)for (ii = 0; ii < dimi; ii+=2)for (jj = 0; jj < dimj; jj+=2*VL)for (k = 0; k < dimk; k++)#pragma ivdepfor(vj=jj; vj

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011Device Size Associativity/#L1 I-Cache 32 KB 4-wayL1 D-Cache 32 KB 8-wayL2 Cache 256 KB 8-wayL3 shared Cache 8 MB 16-wayTLB1 32 entries 4-wayTLB2 512 entries 4-wayGeneral Purpose 64-bit-wide 16 registersRegisters (GPRs)XMM registers 128-bit-wide 16 registersTable 1. Memory hierarchy of the Intel Xeon E5520.Description Loop depth ISCross addition of 2 vectors (Figure 1) 2 RectangularRectangular matrix product (Figure 6) 3 RectangularTriangular matrix product (Figure 9) 3 TriangularTable 2. Characteristics of the evaluated kernels.void multiply(const float *restrict A,const float *restrict B,float *restrict C,int dimi,int dimk,int dimj){long int i,j,k;for(k = 0; k < dimk; k++)for(i = k; i < dimi; i++)for(j = k; j < dimj; j++)C[i*dimj+j] += A[i*dimk+k] * B[k*dimj+j];}Figure 9. Triangular matrix product.We can observe that vector executions (ORI, SIMD andSIMD+VR) obtain always better performance than scalar executions(Scalar). On the other hand, SIMD version is still far awayto the ORI version because SIMD does not apply vectorial replacement,performing therefore excessive redundant memoryoperations inside the innermost loop. Finally, it can be seen thatSIMD+VR outperforms ORI version because better register reuseis done.Figure 10b shows the performance obtained for the rectangularmatrix product. In the ORI version (code of Figure 6) of thiskernel, icc was able to vectorize loop j (inner loop vectorization)and unroll it by a factor of 8 (2 vectors). Again, icc was also ableto perform scalar replacement to reference A of the loop body. Inthe other three versions (Scalar, SIMD and SIMD+VR) registertiling has been applied with tile sizes 6 and 8 for dimension i andj, respectively. Moreover, in the Scalar and SIMD+VR versionscalar and vectorial replacement has been respectively applied.In this case, ORI version again performs better than the Scalarversion since it is vectorized. However, the SIMD version performsslightly better than the ORI version because SIMD exploitsbetter the register level due to the register tiling transformation.Although SIMD version does not perform vectorial replacement,it exploits reuses of accesses to A and B inside the register tile.Finally version SIMD+VR again obtains highest performancesince it highly reduces the memory operations (it avoids loadsand stores of C in the innermost loop). Moreover, we can alsosee in Figure 10b that the performance of SIMD+VR starts todecrease at problem size of 216. For medium problem sizes,tiling only at the register level can substantially increase TLBmisses and cache misses are not moderated. This problem canbe solved by performing tiling also for higher levels of the memoryhierarchy.Figure 10c shows the performance obtained for the triangularmatrix product. In the ORI version of this kernel, icc was notable to vectorize because it does not support non-rectangular loopstructure, but it applies scalar replacement to reference A in theinnermost loop j. In the other three versions (Scalar, SIMD andSIMD+VR) we apply tiling at the register level with tile sizes 6and 8 for dimensions i and j respectively and use Index SetSplitting [29] to distinguish loop nests that traverse (nonrectangular)boundary tiles from loop nests that traverse (rectangular)non-boundary tiles. These later loop nests can be vectorizedand fully unrolled.In this kernel, both ORI and Scalar versions are executed inscalar. The slight difference in performance between them is dueto the loop order. The loop order in ORI version is ikj and thereforereference to A exhibit reuse between different iterations ofthe innermost loop. In the ORI version, the loop body containsthree memory operations (1 load from B and C and 1 store fromC). However, the loop order in Scalar version is ijk and thusreference to C exhibit reuse between different iterations of theinnermost loop. In this version, the loop body only contains twomemory operations (1 load from A and B).Again, we can also see in Figure 10c that SIMD version obtainbetter performance than ORI and Scalar versions thanks tothe vector execution, but SIMD+VR outperforms them. In allthree kernels, the SIMD version shows speedup of around 2xover the Scalar version and the SIMD+VR version obtains anadditional 2x speedup over the SIMD version.Finally, we want to point out the difference in performancefor small problem sizes between the triangular and the rectangularmatrix product kernels. We can observe that SIMD+VR obtainsvery high performance for small problem sizes (from 24 to196) in the rectangular matrix product while the same versionobtains very low performance in the triangular matrix product.The reason is that for very small problem sizes, the executiontime wasted on boundary tiles in the triangular matrix product issignificant and these tiles are not vectorized and unrolled.a) b) c) d)Figure 10. a) Performance of cross addition of 2 vectors. b) Performance of rectangular matrix product. c) Performance of triangular matrix product.d) Performance of SGEMM for the ATLAS and MKL hand-optimized libraries and our best code (SIMD+VR + cache tiling).JP2011-725

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011At last, we compare our optimized codes against handoptimizedassembly-written numerical libraries. Figure 10dshows the SGEMM performance obtained by ATLAS [25] andMKL [11] and the performance obtained by our optimized rectangularmatrix product. To do a fairly comparison, we add cachetiling to the SIMD+VR version of Figure 10d. Cache tiling iseffective for reducing the capacity cache miss rate and moderatingTLB misses. Thus, for medium matrix sizes that do not fit atthe cache level it achieves the same performance level as forsmaller sizes.We can see that MKL achieves the peak performance of acore (2.26GHz * 4 Single Precision Floating Point elements perinstruction * 2 instructions per cycle = 18,08 GFLOPS). On theother hand, ATLAS and SIMD+VR+Cache achieve a performanceof 14 GFLOPS approximately (77% of the peak performance).We can also observe in Figure 10d that for large matrix sizesATLAS achieves slightly better performance than our optimizedversion. The reason is that ATLAS copies the matrices into smallcontiguous blocks in memory in order to minimize TLB missesand cache conflicts. In our optimized version we do not use datacopying. However, for small problem sizes, our optimized codeoutperforms ATLAS.Summarizing, results show that source-to-source optimizedcodes can almost achieve the same performance as handoptimizedassembly-written codes.6. ConclusionsSIMD instructions are so far not really exploited by compilers formedia processors. Taking advantage of such instructions is onlypossible if processor-specific assembly routines or compiler intrinsicsare used, resulting in low portability of software.The optimizations proposed in this paper are high-level(source-to-source) transformations that help compilers to generateefficient SIMD code. We have seen that the SIMD+VR versionobtains speedups of around 4x over the Scalar version.Working at the source level prevent us from controlling manyof the low level transformations typically performed by the compiler’sback-end (instruction scheduling, register allocation, etc.)making it difficult (if not impossible) to generate the optimalcode. By integrating these transformations inside a productioncompiler, we could achieve even more better performance.AcknowledgmentsThis research has been supported by an Intel-UPC ResearchGrant, the Spanish Ministry of Education (contract no. TIN2007-60625), and the European Union (under the HiPEAC-2 Networkof Excelence, FP7/ICT 217068).References[1] D. Aberdeen, and J. Baxter. EMMERALD: a fast matrix-matrix multiplyusing Intel’s SSE instructions, J. Concurrency Comput.: Pract.Exp., 13, 103-119, 2001.[2] U. Banerjee. Dependence analysis for supercomputing. Norwell, Mass.Kluwer Academic Publishers, 1988.[3] A. Bik. The Software Vectorization Handbook. Applying MultimediaExtensions for Maximum Performance". Intel Press. 2004.[4] A. Bik, M. Girkar, P. M. Grey, and X. Tian. Automatic Intra-RegisterVectorization for the Intel Architecture. Int. J. Parallel Program. 30, 2,65-98. April 2002.[5] D. Callahan, S. Carr, and K. Kennedy. Improving register allocationfor subscripted variables. PLDI '90. pp. 53-65. June 1990.[6] S. Carr. Memory-hierarchy management. Ph.D. Thesis, Rice University,February 1993.[7] G. Cheong, M.S. Lam, An optimizer for multimedia instruction sets, in:The Second SUIF Compiler Workshop, Stanford University, USA,1997.[8] Y.F. Fung, M.F. Ercan, T.K. Ho, and W.L. Cheung. A parallel solutionto linear systems. Microprocess. Microsyst., 26, 39-44, 2002.[9] M. Hassaballah, S. Omran, and Y. B. Mahdy. A Review of SIMDMultimedia Extensions and their Usage in Scientific and EngineeringApplications. The Computer Journal, Vol. 51 (6): 630-649. January2008.[10] Intel Corporation. Intel C/C++ Compiler User and Reference Guide.Order Number 304968-023US.[11] Intel Corporation. Intel Math Kernel Library Reference Manual. OrderNumber 630813-038US.[12] Intel Corporation (2010). Intel Advanced Vector Extensions ProgrammingReference. Order Number 319433-009, December 2010.[13] M. Jimenez, J. Llaberia, A. Fernandez. On the Performance of Handsvs. Automatically Optimized Numerical Codes. HPCA-6 IEEE ComputerSociety, January 2000, p. 183-194[14] M. Jimenez, J. Llaberia, A. Fernandez. Register Tiling in NonrectangularIteration Spaces. "ACM transactions on programming languagesand systems", Juliol 2002, vol. 24, núm. 4, p. 409-453.[15] A. Krall and S. Lelait. Compilation Techniques for Multimedia Processors.Int. J. of Parallel Programming. 28, 4, 347-361. August 2000.[16] M. Lam, E. Rothberg, and M. Wolf. The Cache Performance and Optimizationof Blocked Algorithms. ASPLOS'91, pp. 63-74, 1991.[17] D. Maydan, J. Hennessy and M. Lam. Efficient and exact data dependenceanalysis. PLDI’91, pp. 1-14, June 1991.[18] A. Muezerie, R.J. Nakashima, G. Travieso, and J. Slaets. Matrix calculationswith SIMD floating point instructions on x86 processors.HPCA’01, pp. 50-55, September 2001.[19] D. Nuzman, A. Zaks. Outer-loop vectorization: revisited for shortSIMD architectures. PACT '08, pp.2-11, 2008.[20] A. Peleg, U. Weiser. MMX Technology Extension to the Intel Architecture,IEEE Micro, Vol. 16, No. 4, pp. 42-50, August 1996.[21] I. Pryanishnikov , A. Krall , N. Horspool. Compiler optimizations forprocessors with SIMD instructions. Software—Practice & Experience,v.37 n.1, p.93-113, January 2007[22] W. Pugh. "A practical algorithm for exact array dependence analysis".Communications of the ACM, Vol. 35, No. 8, pp. 102-114, 1992.[23] P. Ranganathan, S. Adve, and N. P. Jouppi. Performance of image andvideo processing with general-purpose processors and media ISA extensions.ISCA '99, 124-135, 1999.[24] N. Sreraman and R. Govindarajan. A vectorizing compiler for multimediaextensions. J. of Parallel Programming, 28, 363-400. 2000.[25] R. C. Whaley, A. Petitet, J. Dongarra. Automated Empirical Optimizationof Software and the ATLAS project, Parallel Computing, 27(1-2):3-35, 2001.[26] M. Wolf and M. Lam. A data locality optimizing algorithm. PLDI’91,pp. 30-44, June 1991.[27] M. Wolf, D. Maydan and D.K. Chen. "Combining loop transformationsconsidering caches and scheduling". MICRO-29, pp. 274-286, December1996.[28] M. Wolf. Improving locality and parallelism in nested loops. Ph.D.Thesis, Stanford University, 1992.[29] M. Wolfe. High performance compilers for parallel computing. Addison-WesleyPublishing Company, 1996.[30] C.-L. Yang, B. Sano, and A. R. Lebeck. Exploiting Parallelism inGeometry Processing with General Purpose Processors and Floating-Point SIMD Instructions, IEEE Transactions on Computers, 49(9),934-946, September 2000.JP2011-726

Índice de AutoresAAbad, P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Abdelli, Oussama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Abellán, José L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Acacio, Manuel E.. . . . . . . . . . . . . . . . . . . . . . .203, 209, 227Acosta, Alejandro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Acosta, Mario C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Alfaro, Francisco J. . . . . . . . . . . . . . . . . . . . . . . 261, 297, 403Allande, C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649Almeida, Francisco . . . . . . . . . . . . . . 87, 329, 507, 513, 589Alonso-Jordá, Pedro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Alves, Rui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Amor, M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619, 625Andrés, David de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Andujar, Francisco J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Andújar, Francisco J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Anguita, Mancia . . . . . . . . . . . . . . . . . . . . . . . . 153, 537, 599Aragón, Juan L.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227, 233Arcas, Oriol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Arenas, M.G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595Arias, Enrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353, 705Armas, Sergio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329Arnal, T. Monreal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291, 563Artigas, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Avilés-Gonález, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551Ayuso, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323BBarreiro, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699Barrientos, R.J.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359Bataller, Jordi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Bauset, Víctor Fernández. . . . . . . . . . . . . . . . . . . . . . . . . .607Beivide, Ramón . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421, 451Benavides, José Ignacio . . . . . . . . . . . . . . . . . . . . . . 305, 693Bermúdez, Aurelio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445Berna, Alejandro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719Bernabé, S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Bertozzi, D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Bezerra, Aprigio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251, 501Blanco, H. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525Blanco, Vicente . . . . . . . . . . . . . . . . . . . . . . . . . 329, 513, 643Bohrloch, Tim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Bosque, J.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451, 631Botella, G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Báguena, Miguel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379CCabaleiro, J.C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643Cabrera, Eduardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Cacheiro, Javier López . . . . . . . . . . . . . . . . . . .495, 519, 543Calafate, Carlos T. . . . . . . . . . . . . . . . . . . 367, 379, 385, 427Calviño, M.H.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .693Camacho, Hugo E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Camacho, J.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277Camarero, C.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .451Caminero, B.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483Cano, José . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675Cano, Juan Carlos . . . . . . . . . . . . . . . . . . 367, 379, 385, 427Carrión, C.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483Casado, L.G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Casado, Rafael . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445Castillo, C. Núñez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Castillo, J.C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513Castillo, P.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595Cazorla, D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705Cazorla, Diego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Cecilia, José M.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159, 177Cepas, Eduardo J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Cerrudo, L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661Chaves-González, José M.. . . . . . . . . . . . . . . . . . . . . . . . .125Colaso, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Conejero, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483Coppola, Marcello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675Cores, I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713Crespo, A. J. C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699Cristal, Adrián . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Cuesta, B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197, 203César, E.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .649DDoallo, Ramón . . . . . . . . . . . . . . . . . . . . . . . . . . 433, 439, 625Domínguez, J. M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699Dorta, A. J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661Duato, J.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221Duato, José . 185, 197, 203, 215, 277, 311, 341, 403, 409,415, 557, 675Díaz, Antonio F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537, 637EEscudero-Sahuquillo, Jesús . . . . . . . . . . . . . . . . . . . 409, 415Espinosa, Antonio . . . . . . . . . . . . . . . . . . . . . . . . . . . 251, 501Expósito, Roberto R.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433Ezzatti, Pablo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27FFalgueras, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531Favalli, M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Fedorova, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Fernández, J. C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Fernández, Jesualdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Fernández, Juan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Fernández-Albor, Víctor . . . . . . . . . . . . . . . . . . . . . . 495, 519Fernández-Baldomero, F. Javier . . . . . . . . . . . . . . . 153, 599Fernández-Bauset, Víctor . . . . . . . . . . . . . . . . . . . . . . . . . 335Fernández-Pascual, Ricardo . . . . . . . . . . . . . . . . . . . 203, 239Ferreira, Tharso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251, 501Flich, José . . . . . . . . . . . . 221, 261, 277, 409, 415, 575, 675Flores, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Fogue, Manuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Fraguela, B.B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625Franco, D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Friginal, Jesús. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373Fumero, J. J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661, 687

GGaliano, V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669García, C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323García, Carlos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 273García, I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 135García, J. M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203García, José M. . . . . . . . . . . . . . . . . 159, 177, 233, 239, 255García, Pedro Javier . . . . . . . . . . . . . . . . . . . . . . . . . . 409, 415García, Ricardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33García-Guirado, Antonio . . . . . . . . . . . . . . . . . . . . . 239, 255García-Loureiro, Antonio . . . . . . . . . . . . . . . . 495, 519, 543García-Sánchez, P.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595Garrido, Piedad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Garzón, E. M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Gautier, Thierry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Gil, José Antonio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Gil, Pedro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Giménez, Domingo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589Gomez-Folgar, Fernando . . . . . . . . . . . . . . . . . 495, 519, 543González, C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661González, E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467González, P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713González, Raquel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141, 147González, S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261González, Santos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297González, Sonia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273González, Yanira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45González-Escribano, Arturo . . . . . . . . . . . . . . . . . . . . . . . 681González-Férez, P.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .551González-Linares, José María . . . . . . . . . . . . . . . . . . . . . 305González-Álvarez, David L. . . . . . . . . . . . . . . . . . . . . . . . . . 3Gracia, D. Suárez . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291, 563Graciani, Ricardo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .519Gramacho, Joao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Gran, E. G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Gregorio, J.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Grillo, L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661Guerrero, Ginés D. . . . . . . . . . . . . . . . . . . . . . . . . . . . 159, 177Guil, Nicolás. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305Guirado, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525Gutiérrez, E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Gutiérrez, Eladio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583Gómez, C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Gómez, J.I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Gómez, M.E. . . . . . . . . . . . . . . . . . . . . . . . . . . . 197, 203, 215Gómez-García, Daniel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415Gómez-Gesteira, M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699Gómez-Luna, Juan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Gómez-Pulido, Juan A.. . . . . . . . . . . . .3, 9, 15, 63, 95, 125HHaijema, Rene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Hassan, Houcine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Hendrix, Eligius M.T. . . . . . . . . . . . . . . . . . . . . . . . . . 21, 131Heras, Dora B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Hernández, C.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221Hernández, Moisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Hernández, Porfídio . . . . . . . . . . . . . . . . . . . . . . . . . . 251, 501Herrera, J.F.R.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Heymann, Elisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Huertas, Juan Manuel Orduña . . . . . . . . . . . . . . . . . . . . . 607IIbarra, S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693Ibáñez, Miguel Lozano. . . . . . . . . . . . . . . . . . . . . . . . . . . .607Inuggi, Alberto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159JJiménez, Marta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719Jorba, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649KKarathia, Hiren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Kulakowski, Pawel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445LLago, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531Lamas, Antonio Molinera . . . . . . . . . . . . . . . . . . . . . . . . . 489Lanza-Gutiérrez, José M. . . . . . . . . . . . . . . . . . . . . . . . 63, 95León, Coromoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 45, 69Llabería., Jose M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719Llanos, Diego R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681Llor, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Locatelli, Riccardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675Lodde, Mario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575Lorenzo, Juan A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Lorenzo, Oscar G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Lozano, Miguel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335Ludovici, D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Lugones, D.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397Luque, Emilio . . . . . . . . . . . . . . . . . . . . . . . 75, 165, 397, 569Lysne, O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Lérida, J. L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525López, I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467, 661, 687López, Maria del Mar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475López, O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119, 669López, Otoniel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33López, P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215López, Pedro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .557MMalumbres, Manuel P.. . . . . . . . . . . . . . . .33, 119, 391, 669Mantas, José Miguel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589Manzoni, Pietro . . . . . . . . . . . . . . . . . . . . 367, 379, 385, 427March, José Luis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Martinez, C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451Martinez, Francisco J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Martí, Antonio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Martín, M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713Martínez, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613Martínez, Carmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Martínez, D.R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643Martínez, Miguel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Martínez-Naredo, Pablo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Martínez-Rach, M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Martínez-Zaldívar, F.J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Mayo, R.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311, 341Mena, Lionel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329Menezo, L.G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Merelo, J.J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595Migallón, H. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347, 669

Migallón, V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Mora, A.M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595Morajko, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613, 649Morales, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329, 507Moreno, Francisco Grimaldo . . . . . . . . . . . . . . . . . . . . . . 607Moretó, Miquel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Moure, Juan Carlos . . . . . . . . . . . . . . . . . . . . . . . . . . 251, 501Márquez-Barja, Johann . . . . . . . . . . . . . . . . . . . . . . . . . . . 427Méndez, Sandra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569NNegrillo, Alberto Megía . . . . . . . . . . . . . . . . . . . . . . . . . . . 489Nielsen, E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467Nieto, Erik. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .537OOliver, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Orduña, Juan M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335Ortega, G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Ortega, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595, 637Ortega, Julio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Ortiz, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637PPadrón, E.J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619Pastor, L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631Pelayo, F. L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Peláez, Ignacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Pena, T.F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643Penadés, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Petit, Salvador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185, 557Peña, A. J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311, 341Peña-Ortiz, Raúl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Pichel, Juan C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Piernas, J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551Piñol, Pablo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 119Plata, O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Plaza, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Pont, Ana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459Pousa, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Prieto, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637Prieto, Manuel . . . . . . . . . . . . . . . . . . . . . . . 51, 245, 323, 359Prieto, P.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267Puente, V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267QQuiles, F. J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Quiles, Francisco José . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415Quintana-Ortí, Enrique S. . . . . . . . . . . . . . . . . . 27, 311, 341Quislant, R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191RRamet, D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531Ramos, Alfonso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Ramos, Julián . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583Ramos, Sabela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439Ranilla, José . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Reaño, C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Regueiro, C.V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619Remón, Alfredo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Rexachs, Dolores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 569Reyes, R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687Rivera, Alejandro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171Rivera, Francisco F. . . . . . . . . . . . . . . . . . . . . . . . . . . 643, 655Robles, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197, 203Robles, OD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631Roca, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Rodríguez, G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713Romero, L.F.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107Romero, Sergio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583Ros, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197, 203Rubio-Largo, Álvaro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Rueda, Francisco J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Ruiz, Juan-Carlos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373SSaborido, Juan José . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519Sahuquillo, Julio . . . . . . . . . . . . . . . . . . . . . . . . 185, 459, 557Samarín, Alejandro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329Sande, F. de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661, 687Santos, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513Sarmiento, A.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619Sazeides, Yiannakis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233Segredo, Eduardo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 69Segura, Carlos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39, 45, 69Senar, Miquel Àngel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Serna, M. Ángeles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445Silla, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221, 311, 341Silva, Fernando José Mateus . . . . . . . . . . . . . . . . . . . . . . . . . 9Skeie, T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Solsona, Francesc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Sonmez, Nehir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Stafford, E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451Strano, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Suárez, A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Sáez, J.C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Sánchez, C. Fernández . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495Sánchez, Daniel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Sánchez, José Antonio Rueda . . . . . . . . . . . . . . . . . . . . . . 489Sánchez, José L. . . . . . . . . . . . . . . . . . . . . . . . . 261, 297, 403Sánchez, José Luis . . . . . . . . . . . . . . . . . . . . . . . . . . . 353, 705Sánchez, Lidia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141, 147Sánchez, M. Guadalupe . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Sánchez-Pérez, Juan M. . . . . . . . . . . . . . . 3, 15, 63, 95, 125Sánchez-Pérez, Juan Manuel . . . . . . . . . . . . . . . . . . . . . . . . . 9TTabik, S.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107Tabik, Siham. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131Taboada, Guillermo L.. . . . . . . . . . . . . . . . . . . . . . . .433, 439Taboada, Manel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Tenllado, C.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359Tirado, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Toharía, P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631Tomás, L.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483Torres, Alvaro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385Torres, Yuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681Touriño, Juan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433, 439Trelles, O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531Trenas, María A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583Triviño, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Triviño, Francisco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297UUnsal, Osman S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Uribe-Paredes, Roberto . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Usié, Anabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57VValero, Alejandro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .557Valero, Mateo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Valero, P.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317, 705Valero-Lara, Pedro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Valin, R. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495, 543Vallejo, Enrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Vallejo, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451Vallepuga, José . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141, 147Vega-Rodríguez, Miguel A. . . . . . . . . . 3, 9, 15, 63, 95, 125Vegas, Hugo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Vidal, Antonio M.. . . . . . . . . . . . . . . . . . . . . . . . . . . . .81, 589Vidal, Vicente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Vigueras, Guillermo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335Vilaplana, Jordi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Villalba, Julio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Villar, Juan Antonio . . . . . . . . . . . . . . . . . . . . . . . . . . 403, 415Viñas, M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625Vázquez, F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Vázquez-Poletti, José Luis . . . . . . . . . . . . . . . . . . . . . . . . 489YYúfera, V. Viñals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291, 563ZZablah, Isaac. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543Zapata, E.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107, 191, 305