Análisis energético de Memoria Transaccional Software en procesadores de bajo consumo

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Grado en Ingeniería de Computadores Análisis energético de Memoria Transaccional Software en procesadores de bajo consumo Energy consumption analysis of Software Transactional Memory on low power processors Realizado por Emilio Villegas Fernández Tutorizado por Rafael Asenjo Plaza y Alejandro Villegas Fernández Departamento Arquitectura de Computadores UNIVERSIDAD DE MÁLAGA MÁLAGA, Julio de 2016 Fecha defensa: El Secretario del Tribunal Resumen: Tradicionalmente, en programas multi-hilo, los mecanismos de exclusión mútua se implementan mediante el uso de cerrojos, que garantizan que únicamente uno de los hilos accede a la sección de código en la que se manipulan dichos datos. La Memoria Transaccional (TM) es una alternativa a los cerrojos enfocada a obtener un mejor rendimiento y proporcionar mayor facilidad de programación. TM puede implementarse por software o hardware, siendo las alternativas software más convenientes en términos de flexibilidad y portabilidad. Trabajos recientes han analizado y propuesto soluciones de TM en las que el consumo energético es un factor a tener en cuenta. Buena parte de estos trabajos se realizan sobre simuladores de hardware o sobre procesadores orientados a la computación de altas prestaciones; los estudios sobre hardware físico orientado al bajo consumo no han sido explorados aún. Encontrar soluciones TM software energéticamente eficientes en procesadores actuales de bajo consumo, como pueden ser los incorporados en dispositivos móviles y empotrados, es un campo de investigación abierto. Este proyecto realiza el análisis energético de una librería TM software existente en el mercado sobre un dispositivo de bajo consumo basado en procesadores ARM. El principal objetivo es proporcionar métricas de rendimiento y energía sobre el comportamiento energético de dicha librería en el procesador mencionado. Un objetivo adicional es la instrumentación de benchmarks de prueba, lo cual proporciona una herramienta indispensable para realizar futuras investigaciones en el área. Palabras claves: Eficiencia Energética, Memoria Transaccional. Procesadores Multi-núcleo Abstract: Traditionally, in multi-threaded programs, mutual exclusion mechanisms are implemented using locks. Locks guarantee that only one thread accesses the section of code that manipulates shared data. Transactional Memory (TM) is an alternative to locks that intends to obtain better performance and ease programming. TM can be implemented in software or hardware. Software implementations are more convenient in terms of portability and flexibility. Recent research propose TM solutions where energy consumption is a key factor to take into account. Most of the research is done using simulators or high-performance processors, but not on lowpower processors. The design of energy-efficient TM solutions for low-power processors (such as the ones present in mobile devices) is an open research field. This project analyzes a software TM library running on a device that features a low-power ARM processor using a set of well-known TM applications. The main goal is to provide energy and performance metrics of the library and the applications on such processor. An additional goal is to provide the instrumentation of the applications, which can be used for future research projects. Keywords: Energy efficiency, Transactional Memory, Multi-core Processors. ´ Indice general 1. Introducci´on 9 1.1. Motivaci´on.................................... 9 1.2. Objetivos .................................... 11 1.3. Estadodelarte ................................. 12 1.4. Tecnolog´ıas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4.1. STAMP ................................. 13 1.4.2. TinySTM ................................ 15 1.4.3. Lenguajes de script . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4.4. CyC++ ................................ 16 1.4.5. L A T EX .................................. 16 1.5. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2. Desarrollo 19 2.1. Librer´ıadeenerg´ıa ............................... 19 2.1.1. Puntodepartida ............................ 19 2.1.2. Interfaz gen´erica C++ . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.3. Implementaci´on de la interfaz IEnergy . . . . . . . . . . . . . . . . 23 2.1.4. Adaptador de la librer´ıa C++ a C . . . . . . . . . . . . . . . . . . 24 2.2. Instrumentaci´on de la librer´ıa TinySTM y de las aplicaciones STAMP . . . 27 2.2.1. Compilaci´on de TinySTM y STAMP en ARM . . . . . . . . . . . . 27 2.2.2. Pruebas iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3. Instrumentaci´on de las aplicaciones . . . . . . . . . . . . . . . . . . 29 2.2.4. Instrumentaci´on de las funciones . . . . . . . . . . . . . . . . . . . 30 3. Evaluaci´on 31 3.1. Metodolog´ıa experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.1. Aplicaciones............................... 31 3.1.2. Procesadores y m´etricas . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.3. Automatizaci´on de las pruebas . . . . . . . . . . . . . . . . . . . . . 32 3.2. Resultados experimentales . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1. Evaluaci´on secuencial . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2. Evaluaci´on TinySTM . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7 3.2.3. An´alisis del cluster little . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.4. An´alisis del cluster big . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.5. An´alisis de ambos clusters . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.6. Comparativa entre ambos clusters . . . . . . . . . . . . . . . . . . . 40 3.2.7. An´alisis del consumo de las funciones . . . . . . . . . . . . . . . . . 42 4. Conclusiones 45 4.1. Conclusiones de los experimentos . . . . . . . . . . . . . . . . . . . . . . . 45 4.2. Conclusiones del trabajo de fin de grado . . . . . . . . . . . . . . . . . . . 45 4.3. Trabajofuturo ................................. 46 8 Cap´ıtulo 1 Introducci´on A lo largo de este primer cap´ıtulo de la memoria se explican las motivaciones que nos han llevado a realizar este trabajo de fin de grado, los objetivos del trabajo, el estado del arte, las tecnolog´ıas que se utilizan y la forma en la que se estructura la memoria. 1.1. Motivaci´on Actualmente podemos encontrar dispositivos m´oviles y empotrados en una gran variedad de entornos. Estos dispositivos tienen una serie de restricciones. En ocasiones dependen de una fuente de alimentaci´on integrada, por ejemplo una bater´ıa, lo que hace que el consumo deba ser el menor posible para prolongar su duraci´on. Otra restricci´on es la temperatura. En casos como los tel´efonos m´oviles, la temperatura debe ser baja para un uso c´omodo por parte del usuario. Adem´as de cumplir con los casos anteriores, el dispositivo debe presentar un rendimiento aceptable para las tareas que se le encarguen. Fabricantes de procesadores como ARM se est´an centrando en la creaci´on de procesadores de bajo consumo energ´eticamente eficientes. Mediante la creaci´on de la arquitectura multi-n´ucleo big.LITTLE [1] logran mantener un equilibrio en el consumo de energ´ıa, temperatura y rendimiento. Esta arquitectura incorpora dos conjuntos de n´ucleos: unos m´as potentes orientados al rendimiento y otros n´ucleos con menor capacidad de c´alculo pero energ´eticamente m´as eficientes. Llamaremos a estos conjuntos de n´ucleos clusters, concretamente cluster big ycluster little. Los n´ucleos de ambos clusters comparten la misma ISA y el acceso a la misma memoria principal, esto permite la ejecuci´on de una aplicaci´on en cualquiera de los clusters. Para aprovechar las capacidades de estos procesadores, las aplicaciones deben ser programadas con un dise˜no multi-hilo. Esto puede suponer un reto para los programadores al tener que sincronizar los hilos de ejecuci´on para acceder a datos compartidos. La porci´on de c´odigo que accede a estos datos, conocida como secci´on cr´ıtica, debe garantizar la exclusi´on mutua en su acceso por parte de los hilos de ejecuci´on. La exclusi´on mutua se implementa de forma tradicional utilizando cerrojos. Un cerrojo de grano grueso ga9 TinySTM tiene opciones de compilaci´on distintas para utilizar los 4 modos anteriores. Por defecto utiliza la opci´on de compilaci´on WRITE BACK ETL que utiliza los modos writeback con encounter-time locking. 1.4.3. Lenguajes de script El primer lenguaje de scripts utilizado en este trabajo es Python [3]. Python es un lenguaje interpretado multiplataforma. Fue creado a finales de los 80 por Guido van Rossum y administrado por Python Software Foundation. Permite a los programadores adoptar varias formas de programaci´on: programaci´on orientada a objetos, programaci´on imperativa y programaci´on funcional. Es un lenguaje de alto nivel con una sintaxis que permite tener c´odigos f´aciles de leer. Actualmente existen varias versiones de Python, la versi´on 2 y versi´on 3. Se siguen trabajando sobre ambas versiones ya que la versi´on 3 no es compatible con la 2 y surgi´o para modificar elementos del dise˜no de Python. En la actualidad su uso se extiende desde peque˜nos scripts a servidores que trabajan de forma ininterrumpida. Existen diversas librer´ıas para Python, concretamente matplotlib [24] es utilizada para producir figuras como pueden ser gr´aficas de una forma sencilla. Otro lenguaje utilizado es Bash (Bourne Again SHell). Bash es una Shell de Unix y un lenguaje de comandos, escrito por Brian Fox para el proyecto GNU. Bash surge como reemplazo del Bourne Shell. Es capaz de ejecutar todas sus instrucciones sin ninguna modificaci´on. Bash permite adem´as el c´alculo de enteros, redirecciones de entrada y salida, uso de expresiones regulares y caracteres especiales. 1.4.4. C y C++ El lenguaje C fue desarrollado en un principio por Dennis M. Ritchie. Es un lenguaje imperativo, dise˜nado para ser compilado. La primera estandarizaci´on del lenguaje fue en ANSI (ANSI C) y posteriormente como est´andar ISO. Con esto, si los programas creados siguen el est´andar, ser´an portables entre plataformas y arquitecturas. Es un lenguaje d´ebilmente tipado. Dispone de estructuras de lenguajes de alto nivel pero a la vez permite el control a muy bajo nivel. Permite el acceso a memoria de bajo nivel mediante punteros. El lenguaje C++ fue dise˜nado a mediados de los 80 por Bjarne Stroustrup. Su creador quer´ıa incluir en el lenguaje C mecanismos para la manipulaci´on de objetos. Por lo tanto es un lenguaje de programaci´on multiparadigma. C++ permite redefinir operadores y crear nuevos tipos que se comporten como tipos fundamentales. 1.4.5. L A T E X L A T EXes un sistema de composici´on de textos. Suele ser utilizado en la creaci´on de art´ıculos, tesis y libros t´ecnicos. L A T EXpermite al autor del documento centrarse ´unicamente en el contenido de este, haciendo que no tenga que preocuparse por detalles del 16 formato. En la elaboraci´on de un documento existen dos etapas: en la primera mediante un editor de texto, se escriben las ordenes y el contenido que se quiera escribir. En la segunda, hay que procesar este archivo para mostrar la salida correspondiente. 1.5. Estructura de la memoria En este primer cap´ıtulo, introducci´on, se han tratado los puntos de motivaci´on y objetivos del trabajo. Adem´as, se realiza el estudio del estado del arte donde se analiza el trabajo relacionado y los antecedentes. Finalmente, en el apartado de tecnolog´ıas utilizadas, se explican los diferentes lenguajes utilizados, librer´ıa de TM TinySTM y los benchmarks de STAMP. En el cap´ıtulo 2, desarrollo, se trata el punto de partida de la librer´ıa de energ´ıa, pasando por toda la adaptaci´on hasta tener una librer´ıa portable con la que instrumentar el c´odigo. A continuaci´on, se trata el proceso de instrumentaci´on de STAMP utilizando la librer´ıa, explicando la compilaci´on tanto de la librer´ıa, TinySTM y STAMP. Adem´as, se llevan a cabo pruebas para comprobar el funcionamiento de la instrumentaci´on realizada. En el cap´ıtulo 3, evaluaci´on, se explica la metodolog´ıa experimental, el proceso que se ha seguido para realizar los diferentes experimentos. Adem´as, se presentan los resultados obtenidos en los experimentos. En el cap´ıtulo 4, cerramos esta memoria con las conclusiones de los experimentos, del trabajo de fin de grado y el trabajo futuro. 17 18 Cap´ıtulo 2 Desarrollo 2.1. Librer´ıa de energ´ıa 2.1.1. Punto de partida Como punto de partida tenemos la librer´ıa Energy Meter v1.0, desarrollada en el Departamento de Arquitectura de Computadores en un trabajo previo. La librer´ıa proporciona acceso a los datos obtenidos en los sensores INA2311del dispositivo. El lenguaje de programaci´on en el que se ha desarrollado es C. La librer´ıa incluye la definici´on de dos tipos de struct. El primero de ellos, struct energy sample, almacena los datos del medidor, as´ı como la energ´ıa consumida total. En el segundo, struct em t, se almacenan las mediciones instant´aneas de energ´ıa. Es importante saber que el medidor recoge muestras peri´odicamente. Si el tiempo de muestreo es mayor que el tiempo de ejecuci´on del c´odigo instrumentado, la medici´on ser´a incorrecta. El tiempo m´ınimo para el muestreo, que adem´as es el valor por defecto de la librer´ıa, es de 50 milisegundos. Para instrumentar una aplicaci´on mediante el uso de esta librer´ıa, se deben utilizar las siguientes funciones: struct energy sample ∗energy meter init(int sample rate, int debug), donde sample rate es el periodo de tiempo entre muestras y la opci´on debug hace que se muestre informaci´on adicional durante la ejecuci´on. Esta funci´on inicializa el medidor de energ´ıa. void energy meter start(struct energy sample ∗sample) lanza el hilo que se encarga de muestrear la energ´ıa consumida y, desde este momento, empieza a contar el tiempo de muestreo. void energy meter stop(struct energy sample ∗sample) detiene la ejecuci´on del hilo que muestrea y es en este momento cuando se guardan los datos totales muestreados en sample. 1http://www.ti.com/lit/ds/symlink/ina231.pdf 19 void energy meter printf(struct energy sample ∗sample1, FILE ∗fout) se utiliza para, una vez detenido el muestreador, escribir en un fichero o en pantalla la informaci´on del cluster little, cluster big, memoria, GPU y el tiempo de ejecuci´on. void energy meter destroy(struct energy sample ∗sample) se encarga de liberar correctamente la memoria utilizada. Una vez completado todo el proceso de muestreo debe llamarse al final de la aplicaci´on. void energy meter read(struct energy sample ∗sample, struct em t ∗read) toma una muestra de la energ´ıa consumida en todo el chip en el mismo instante de la llamada. void energy meter diff(struct energy sample ∗sample, struct em t ∗start diff ) toma una muestra de la energ´ıa consumida y calcula la diferencia con la que recibe como par´ametro, y sustituye el valor de la misma. Es ´util para medir la energ´ıa entre dos puntos del c´odigo. void energy meter read printf(struct em t ∗read or diff , FILE ∗fout) muestra la informaci´on de la energ´ıa consumida en el chip en las muestras proporcionadas como par´ametro. Adem´as de las funciones detalladas, la librer´ıa contiene varias macros en C para sumar dos muestras de energ´ıa y para inicializar los valores de las muestras de energ´ıa a cero. En todas las funciones anteriores, el par´ametro de entrada struct energy sample * sample se refiere a la estructura que contiene los datos del medidor correctamente inicializados. En la Figura 2.1 se muestra un diagrama de las funciones aportadas por la librer´ıa. Figura 2.1: Diagrama de la librer´ıa Energy Meter v1.0 2.1.2. Interfaz gen´erica C++ Pensando en la adaptaci´on de la librer´ıa de energ´ıa, escrita en C, se decide realizar una implementaci´on utilizando una interfaz gen´erica mediante clases de C++. Aunque las aplicaciones a instrumentar (STAMP) est´an escritas en C, el objetivo es proporcionar una interfaz C++ para dar soporte a aplicaciones escritas en este lenguaje y facilitar el 20 trabajo futuro. Adem´as, la creaci´on de esta interfaz permite que, una vez instrumentadas las aplicaciones, s´olo haya que cambiar la implementaci´on de la interfaz para que la instrumentaci´on siga funcionando. Por ejemplo, para utilizar un procesador Intel, habr´ıa que crear una implementaci´on de esta interfaz que acceda a los contadores de energ´ıa proporcionados por este fabricante, pero no habr´ıa que modificar el c´odigo instrumentado. No es obligatoria la implementaci´on de todos estos m´etodos, pero debe observarse cuales son las utilizadas en el c´odigo ya instrumentado para su correcto funcionamiento. La interfaz define los siguientes m´etodos: IEnergy(): constructor de la clase, normalmente est´a vac´ıo. Se proporciona un m´etodo para crear instancias de la clase. static IEnergy ∗create(): este m´etodo se debe implementar para devolver una instancia de la clase que implementa la interfaz. Al ser est´atico no es necesario que tengamos el objeto creado para realizar la llamada. Su acceso es a trav´es de la interfaz y no a trav´es de la clase implementada. Con esto se hace que el c´odigo instrumentado no se tenga que modificar cuando cambiemos de librer´ıa. void energy initialize (): este m´etodo se debe implementar para inicializar las estructuras y variables de nuestra librer´ıa. void energy start() : este m´etodo se debe implementar para que el muestreador comience a funcionar. void energy stop(): este m´etodo se debe implementar para detener el muestreador. void energy destroy(): este m´etodo se debe implementar para liberar memoria al final de la ejecuci´on. void energy printf(FILE ∗out): este m´etodo se debe implementar para escribir en out la informaci´on del muestreador. void energy sample start(): este m´etodo se debe implementar para comenzar una medici´on parcial, por ejemplo para medir el consumo antes y despu´es de una llamada a una funci´on. void energy sample stop(int acc): este m´etodo se debe implementar para detener la medici´on parcial, debe llamarse siempre despu´es de energy sample start(). El par´ametro acc se puede utilizar para acumular la diferencia de consumo en la variable dando el valor 1, o por el contrario, para sustituir el valor dando el valor 0. Si se desea medir el valor de varios trozos de c´odigo y obtener un total, se deben acumular todos los consumos le´ıdos (ver Figura 2.2a). Si se desea solamente medir un trozo, se debe sustituir el valor de la variable anterior (ver Figura 2.2b) void energy sample clear(): este m´etodo se debe implementar para inicializar en cualquier momento el valor del medidor parcial. double energy sample getCPU(): este m´etodo se debe implementar para obtener en cualquier momento la energ´ıa consumida por la CPU de una medici´on parcial. double energy sample getGPU(): este m´etodo se debe implementar para obtener en cualquier momento la energ´ıa consumida por la GPU de una medici´on parcial. 21 double energy sample getMEM(): este m´etodo se debe implementar para obtener en cualquier momento la energ´ıa consumida por la memoria de una medici´on parcial. double energy sample getTIME(): este m´etodo se debe implementar para obtener en cualquier momento el tiempo de ejecuci´on de una medici´on parcial. // Creaci ´on de l a i n s t a n c i a IEnergy ∗e = IEnergy : : create () ; // Inicializaci´on e−>energy initialize(); // Lanzar e l muestreador e−>energy start () ; // Aqu´ı comienza primera zona // de c´o digo a muestrear e−>ener gy samp le start () ; /∗ ∗Se cci ´on de c´o digo a muestrear ∗/ // Terminamos la primera zona // de muestreo y s u sti tuy e // e l v alo r a n t e r i o r e−>energy sample stop(0) ; /∗ ∗C´o digo que no se qu ier e muestrear ∗/ // Aqu´ı comienza segunda zona // de c´o digo a muestrear e−>ener gy samp le start () ; /∗ ∗Se cci ´on de c´o digo a muestrear ∗/ // Terminamos la segunda zona // de muestreo y acumulamos // e ste nuevo consumo al ya // l e i d o anteriormente e−>energy sample stop(1) ; // Se muestra e l consumo acumulado e−>energy sample printf ( stdout ) ; // Se para e l muestreador e−>energy stop() ; // Se l i b e r a memoria e−>energy destroy () ; (a) Medici´on del consumo de varios trozos de c´odigo de forma acumulativa. // Creaci ´on de l a i n s t a n c i a IEnergy ∗e = IEnergy : : create () ; // Inicializaci´on e−>energy initialize(); // Lanzar e l muestreador e−>energy start () ; // Aqu´ı comienza primera zona // de c´o digo a muestrear e−>ener gy samp le start () ; /∗ ∗Se cci ´on de c´o digo a muestrear ∗/ // Terminamos la primera zona // de muestreo y s u sti tuy e // e l v alo r a n t e r i o r e−>energy sample stop(0) ; // Se muestra e l consumo de e ste trozo e−>energy sample printf ( stdout ) ; /∗ ∗C´o digo que no se qu ier e muestrear ∗/ // Aqu´ı comienza segunda zona // de c´o digo a muestrear e−>ener gy samp le start () ; /∗ ∗Se cci ´on de c´o digo a muestrear ∗/ // Terminamos la segunda zona // de muestreo e−>energy sample stop(0) ; // Se muestra e l consumo de es ta zona e−>energy sample printf ( stdout ) ; // Se para e l muestreador e−>energy stop() ; // Se l i b e r a memoria e−>energy destroy () ; (b) Medici´on del consumo de varios trozos de c´odigo sin acumular. Figura 2.2: Ejemplo del uso de energy sample start y energy sample stop para instrumentar una o varias secciones de c´odigo. Los ejemplos de la Figura 2.2 muestran varios c´odigos. En uno de ellos (Figura 2.2a), se miden varias secciones de c´odigo diferentes y se muestra la suma el consumo en el chip 22 en ambas secciones. En el otro (Figura 2.2b), se miden por separado dos secciones, y al final de cada secci´on se muestra el consumo en el chip. Es importante observar el uso del par´ametro acc del m´etodo energy sample stop en ambos casos. A continuaci´on en la Figura 2.3 se presenta el diagrama de la interfaz IEnergy. Figura 2.3: Diagrama de la interfaz gen´erica en C++. 2.1.3. Implementaci´on de la interfaz IEnergy Una vez dise˜nada la interfaz, se define una implementaci´on de esta. La implementaci´on la realiza la clase COdroidEnergy utilizando las funciones y tipos de datos proporcionados en la librer´ıa Energy Meter v1.0. Adem´as, implementa las mediciones acumulativas tanto en energ´ıa como en tiempo ya que la librer´ıa original no proporciona este soporte. Para ello se declaran variables para cada dato proporcionado, es decir, energ´ıa consumida en A7, A15, memoria y GPU, y tiempo parcial. El siguiente listado describe los detalles de implementaci´on de cada m´etodo. El constructor de la clase se ha decidido dejar vac´ıo, ya que se utiliza un m´etodo para la creaci´on e inicializaci´on de instancias. El m´etodo est´atico create devuelve una instancia de la clase COdroidEnergy. A este m´etodo se accede a trav´es de la interfaz IEnergy en el c´odigo instrumentado. Al ser est´atico no es necesario tener el objeto creado para realizar la llamada. El m´etodo energy initialize inicializa el medidor de energ´ıa y las variables para las mediciones parciales, utilizando llamadas a energy meter init y la macro init em proporcionadas por Energy Meter v1.0, y a la funci´on energy sample clear. 23 Los m´etodos energy start,energy stop,energy destroy yenergy printf llaman a las funciones equivalentes proporcionadas por la librer´ıa Energy Meter v1.0. El m´etodo energy sample start llama a la funci´on de la librer´ıa que lee la energ´ıa consumida hasta ese mismo instante. Adem´as, guarda el instante de tiempo en el que se llama a la funci´on. El m´etodo energy sample stop recibe un par´ametro acc. Mediante llamadas a la librer´ıa, calcula la diferencia de energ´ıa consumida y el tiempo de ejecuci´on desde la ´ultima vez que se llam´o al m´etodo energy sample start. En funci´on del par´ametro acc este valor sustituye al anterior o se acumula, y su significado es el mismo que el definido en la interfaz. El m´etodo energy sample clear inicializa los valores sobre los que guardamos datos de mediciones parciales. El m´etodo energy sample printf muestra los valores de las mediciones parciales realizadas. Recibe como par´ametro el flujo de salida deseado. Los m´etodos energy sample getCPU,energy sample getGPU,energy sample getMEM y energy sample getTIME devuelven los datos de las mediciones parciales de CPU, GPU, Memoria y el contador de tiempo, respectivamente. En la Figura 2.4 se muestra el diagrama de la clase COdroidEnergy. Implementa la interfaz IEnergy utilizando las funciones proporcionadas por la librer´ıa Energy Meter v1.0. Figura 2.4: Diagrama de la clase COdroidEnergy. 2.1.4. Adaptador de la librer´ıa C++ a C Una vez definida una implementaci´on de la interfaz IEnergy, podemos utilizarla para instrumentar aplicaciones escritas en C++. Durante el desarrollo de este trabajo se ha 24 decidido instrumentar el c´odigo del conjunto de aplicaciones STAMP, que en este caso est´an escritas en C. En lugar de utilizar la implementaci´on C original de la librer´ıa de energ´ıa (esto es, Energy Meter v1.0) se ha decidido crear una serie de funciones en C que, siguiendo el patr´on de dise˜no adaptador, permitan utilizar una implementaci´on C++ de la interfaz IEnergy. El motivo es poner en pr´actica la filosof´ıa de dise˜no de la interfaz IEnergy: debe servir para, de forma gen´erica, instrumentar c´odigo para realizar mediciones de energ´ıa. Las implementaciones de esta interfaz deben estar escritas en C++, mientras que las aplicaciones que deseen utilizarla deben estar tambi´en escritas en C++, o bien, implementar un adaptador adecuado. En la implementaci´on de cada una de estas funciones se hace uso del tipo Energy, este tipo est´a definido como un puntero a void. De esta forma podemos transformar el tipo Energy mediante un casting en la implementaci´on de la interfaz IEnergy. Al tener acceso a la interfaz, se puede llamar a los m´etodos implementados anteriormente. void energy init (const Energy ∗e) void energy start(const Energy ∗e) void energy stop(const Energy ∗e) void energy destroy(const Energy ∗e) void energy printf(const Energy ∗e, FILE ∗out) void energy sample start(const Energy ∗e) void energy sample stop(const Energy ∗e, int acc) void energy sample printf(const Energy ∗e, FILE ∗out) void energy sample clear(const Energy ∗e) double energy sample getCPU(const Energy ∗e) double energy sample getGPU(const Energy ∗e) double energy sample getMEM(const Energy ∗e) double energy sample getTIME(const Energy ∗e) Para la compilaci´on de la librer´ıa de energ´ıa se ha realizado un script en Bash que facilita el trabajo. La librer´ıa externa debe colocarse en el directorio lib, dentro de un subdirectorio con el nombre de la librer´ıa externa. Por ejemplo, en este caso la librer´ıa se coloca en /lib/energy−meter/. La librer´ıa externa debe disponer de un fichero Makefile que haga posible su compilaci´on mediante el comando make. Para compilar la librer´ıa de energ´ıa se debe ejecutar el comando ./compile.sh <directorio−librer´ıa−externa>, por ejemplo ./compile.sh energy−meter . Adem´as, para facilitar la compilaci´on de STAMP, se ha creado un fichero Defines.energy.mk. En este fichero se encuentran rutas y dependencias necesarias para que STAMP compile con la librer´ıa de energ´ıa. Para ello hay que incluir en el Makefile de cada una de las aplicaciones STAMP a compilar una l´ınea que referencia a este fichero: include ../../ energy/Defines.Energy.mk. La instrumentaci´on de un c´odigo escrito en C mediante el adaptador se puede ver en la Figura 2.5. El c´odigo muestra el consumo de energ´ıa y el tiempo de ejecuci´on de una 25 con TinySTM ya que han funcionado sin problemas. Adem´as, estas aplicaciones poseen diferentes caracter´ısticas en cuanto a tama˜no de los datos que trata, longitud de transacciones, etc... (ver Tabla 1.1). Para evaluar la ejecuci´on secuencial se han evaluado aquellas aplicaciones que han funcionado sin problemas. La aplicaci´on bayes ha sido excluida porque, como se ha comentado anteriormente, presenta diferencias notables en los tiempos de ejecuci´on entre distintas ejecuciones. 3.1.2. Procesadores y m´etricas Primero se ejecutan las aplicaciones dejando que el planificador del sistema operativo decida d´onde planificar los hilos de ejecuci´on. Por defecto, el planificador coloca las aplicaciones que utilizan de 1 a 4 hilos en el cluster big y es a partir de este n´umero cuando empieza a utilizar ambos clusters. Mediante el comando taskset1seleccionamos los n´ucleos sobre los que se ejecutan los hilos de las aplicaciones. Para utilizar este comando adecuadamente, tenemos que averiguar el identificador de cada uno de los n´ucleos de cada cluster. En nuestro caso, el sistema operativo ha asignado los ´ındices 0, 1, 2 y 3 para el cluster little (A7) y los ´ındices 4, 5, 6 y 7 para el cluster big (A15). Hay que tener en cuenta que aunque no tengamos ejecutando la aplicaci´on en ciertos n´ucleos, estos generan un consumo residual. Durante cada uno de los experimentos se examinan 3 m´etricas. En primer lugar, el tiempo de ejecuci´on de la secci´on de c´odigo que utiliza transacciones. En segundo lugar, la energ´ıa medida en Julios, que es la medida proporcionada por la librer´ıa de energ´ıa. Finalmente, se calcula el EDP [27] (Energy-Delay Product) con los valores de tiempo y energ´ıa medidos. El c´alculo a realizar es la multiplicaci´on de la energ´ıa total consumida en la ejecuci´on de la aplicaci´on por el tiempo empleado (esto es, EDP = Energ´ıa ×Tiempo). El EDP se utiliza como m´etrica de la eficiencia energ´etica: a menor valor de EDP significa una mayor eficiencia. En cada experimento se llevan a cabo 10 ejecuciones y con los datos obtenidos se realiza un promedio de esas 10 ejecuciones. Durante los experimentos, en las mismas condiciones, los valores medidos son consistentes, es decir no hay una variaci´on significativa en dos ejecuciones diferentes de una misma aplicaci´on. 3.1.3. Automatizaci´on de las pruebas Para realizar las pruebas se han realizado varios scripts en Bash que automatizan el proceso. Los scripts son tests .sh,energy tests high e .sh,energy tests low e .sh,energy tests high .sh y energy tests low .sh. Igualmente, para la visualizaci´on de los resultados de forma num´erica y gr´afica se han creado scripts en Python llamados parseTests.py ygenerate++.py. La Figura 3.1 muestra el ´arbol de directorios sobre el que trabajan estos scripts para generar lanzar los experimentos y generar los resultados. 1http://linux.die.net/man/1/taskset 32 <directorio de trabajo> graph generate++.py input output STAMP energy tests high e.sh energy tests high.sh energy tests low e.sh energy tests low.sh etest <aplicaci´on> tests.sh parseTests.py energy testsNTX.txt <aplicaci´on>.csv <aplicaci´on2> ... Figura 3.1: ´ Arbol de directorios creado para la evaluaci´on El script tests .sh sirve para ejecutar las pruebas para una aplicaci´on concreta. Este script se encuentra replicado en el directorio de cada aplicaci´on y est´a dise˜nado para recibir 4 argumentos. Una llamada a este script tiene la forma ./ tests .sh <N> <P> <C> <A> El argumento <N>indica el (N)´umero de hilos a utilizar, pudiendo recibir los valores 1, 2, 4 u 8. El argumento <P>indica el n´umero de (P)ruebas a realizar. Los resultados de las P pruebas se almacenan en el mismo fichero de salida uno tras otro. El argumento <C>indica la (C)ontenci´on en los par´ametros de entrada. Los valores posibles son high para seleccionar el par´ametro ++ en STAMP o low para el par´ametro +. El argumento <A>indica la (A)finidad de los hilos de ejecuci´on a los n´ucleos. Es una cadena de la forma 0,1,2,3,4,5,6,7 en la que se indican los ´ındices de los n´ucleos que queremos utilizar. Los resultados de las pruebas se escriben en el subdirectorio ./energy/ con el nombre de fichero testsNTX.txt siendo Xel n´umero de hilos utilizados. Por ejemplo, para ejecutar las pruebas de intruder, se debe entrar a su directorio y utilizar el comando ./ tests .sh 4 10 high 0,1,2,3 . Este comando lanza intruder utilizando 4 hilos, realiza un total de 10 pruebas, utiliza la configuraci´on ++ proporcionada por STAMP y selecciona los n´ucleos 0, 1, 2 y 3 correspondientes al cluster little (A7). Los resultados de esta prueba se escriben en el fichero ./energy/testsNT4.txt, que contiene los datos de 10 pruebas. Si se ejecu33 ta de nuevo el mismo comando ( ./ tests .sh 4 10 high 0,1,2,3 ), el fichero ./energy/testsNT4.txt no se reemplaza, sino que los resultados de las nuevas pruebas se a˜naden al final de dicho fichero. Los scripts energy tests high e .sh,energy tests low e .sh,energy tests high .sh yenergy tests low .sh lanzan una bater´ıa de pruebas en las que se ejecutan todas las aplicaciones, con distinto n´umero de hilos. Los scripts energy tests high e .sh,energy tests low e .sh lanzan 1, 2 y 4 hilos de ejecuci´on, mientras que energy tests high .sh yenergy tests low .sh lanzan 1, 2, 4 y 8 hilos de ejecuci´on. Los indicadores low yhigh sirven para distinguir la contenci´on en la entrada de cada prueba. Un ejemplo de llamada a estos scripts es ./ energy tests high e .sh <P> <A>, donde: El argumento <P>indica el n´umero de (P)ruebas a realizar en cada aplicaci´on. El argumento <A>indica la (A)finidad de los hilos de ejecuci´on a los n´ucleos. Es una cadena de la forma 0,1,2,3,4,5,6,7 en la que se indican los ´ındices de los n´ucleos que queremos utilizar. Los 4 scripts descritos anteriormente tienen los mismos argumentos de entrada. Estos scripts llaman al script tests .sh que se encuentra en el directorio de cada aplicaci´on. Todos estos scripts hacen una llamada a otro, parseTests.py, que se explica a continuaci´on, para generar ficheros csv con los resultados de los experimentos. Los ficheros csv generados se copian al directorio ./ etest/. Por ejemplo, para lanzar 10 pruebas con 1, 2 y 4 hilos utilizando la opci´on ++ y utilizando el cluster big, se debe ejecutar el siguiente comando: ./ energy tests high e .sh 10 4,5,6,7 . Para hacer la misma prueba pero con 1, 2, 4 y 8 hilos, utilizando ambos clusters se debe ejecutar el siguiente comando: ./energy tests high .sh 10 0,1,2,3,4,5,6,7 . Se˜nalar que estos 4 scripts borran los resultados anteriores que el script tests .sh pudiese haber generado (esto es, se eliminan los ficheros testsNTX.txt descritos anteriormente). Para el tratamiento de los resultados se han realizado 2 scripts en Python. El primer script convierte los ficheros de salida al formato csv, mientras que el segundo lee estos ficheros para representar los resultados de forma resumida en formato texto y gr´aficamente. A continuaci´on se detalla el funcionamiento de estos scripts. El primer script est´a situado en el directorio de cada aplicaci´on y se llama de la forma ( ./parseTests.py <F> <H>). Este script lee los ficheros testsNTX.txt, generado por las aplicaciones, y lo convierte a formato csv. El argumento <F>indica el nombre del (F)ichero de salida. El argumento <H>indica con qu´e n´umero de (H)ilos se ha realizado el experimentos. Debe tener el valor 3 si el experimento se ha realizado con 1, 2 y 4 hilos, o bien 4 si se ha realizado con 1, 2, 4 y 8 hilos. Por ejemplo, situados en el directorio de la aplicacion intruder la ejecuci´on del comando ./parseTests.py salida 3 genera el fichero ./energy/salida.csv con los datos de los experimentos almacenados en ./energy/testsNT1.txt,./energy/testsNT2.txt y./energy/testsNT4.txt. 34 El script generate++.py, situado en el directorio ./graph/ es el encargado de leer todos los csv generados y crear las gr´aficas a partir de ellos. En este directorio existe un ´arbol de subdirectorios en los que hay que copiar los ficheros de entrada que se encuentran en ./ etest/. Este ´arbol de subdirectorios contiene un directorio input en el que se deben colocar los ficheros csv de entrada y un directorio output en el que generate++.py genera los ficheros de texto (en formato txt) y gr´aficos de salida (en formato pdf). 3.2. Resultados experimentales 3.2.1. Evaluaci´on secuencial En primer lugar, se ejecutan las aplicaciones seleccionadas utilizando la forma secuencial (esto es, sin utilizar TinySTM). Esta ejecuci´on se realiza con un solo hilo y, por tanto, s´olo existen dos experimentos: ejecutar en el cluster little o ejecutar en el cluster big. En la tabla 3.2 se muestra el promedio de los resultados obtenidos al ejecutar las 4 aplicaciones que evaluamos en secuencial, utilizando el cluster big. Aplicaci´on T.E.A15 C.E.A15 EDPA15 intruder 42.1697s 80.1944J 3381.7769 labyrinth 97.9596s 273.6930J 26810.8741 ssca2 19.2961s 35.1619J 678.4915 vacation 44.3644s 84.6508J 3755.4857 Tabla 3.2: Tiempo de ejecuci´on en segundos (T.E.), consumo de energ´ıa en Julios (C.E.) y Energy-Delay Product (EDP) obtenidos en los experimentos secuenciales en el cluster big (A15). En la tabla 3.3 se muestra el promedio de los resultados obtenidos al ejecutar las 4 aplicaciones que evaluamos en secuencial, utilizando el cluster little. Aplicaci´on T.E.A7C.E.A7EDPA7 intruder 63.5022s 71.2247J 4522.9262 labyrinth 268.6831s 314.9532J 84622.6043 ssca2 30.5778s 34.4065J 1052.0772 vacation 65.1864s 73.1984J 4771.5504 Tabla 3.3: Tiempo de ejecuci´on en segundos (T.E.), consumo de energ´ıa en Julios (C.E.) y Energy-Delay Product (EDP) obtenidos en los experimentos secuenciales en el cluster little (A7). Observando ambas tablas comprobamos que los tiempos de ejecuci´on obtenidos en el cluster big son menores, puesto que tienen m´as potencia de c´omputo. En cuanto a 35 energ´ıa consumida por la aplicaci´on, el cluster little resulta m´as eficiente para todas las aplicaciones salvo labyrinth. El motivo es que el cluster big ejecuta mucho m´as r´apido esta aplicaci´on y consigue un ahorro de energ´ıa a pesar del mayor gasto de potencia. Observando el EDP, observamos que en todas aplicaciones es mayor en el cluster little. Esto significa que el ahorro de energ´ıa que obtenemos al utilizar este cluster no compensa que los tiempos de c´omputo sean mayores con respecto al cluster big. 3.2.2. Evaluaci´on TinySTM Para la evaluaci´on de TinySTM se realizan 3 pruebas. En la primera, se lanzan las 5 aplicaciones seleccionadas utilizando los n´ucleos little (A7). En la segunda, se lanzan utilizando los n´ucleos big (A15). Ambas pruebas se realizan con 1, 2 y 4 hilos. Finalmente, se lanzan pruebas dejando que el planificador decida: con 1, 2, 4 hilos selecciona los n´ucleos big y con 8 hilos ambos clusters. Una vez realizadas las pruebas se analizan los resultados obtenidos en el cluster little, cluster big y ambos a la vez. Adem´as, se realiza una comparativa entre ambos clusters. La Tabla 3.4 contiene los resultados num´ericos obtenidos de la evaluaci´on utilizando 4 hilos. Estos resultados se completan y se comentan de forma gr´afica en las siguientes subsecciones. Aplic. T.E.A7T.E.A15 C.E.A7C.E.A15 EDPA7EDPA15 intruder 87.0s 127.3s 120.9J 635.9J 10517.8018 80977.3776 kmeans 22.3s 37.5s 31.9J 187.7J 714.0321 7044.2739 labyrinth 91.4s 34.5s 136.9J 295.9J 14993.9341 10228.2794 ssca2 32.6s 35.6s 45.9J 171.8J 1501.6922 6120.4337 vacation 138.3s 271.7s 188.2J 1317.0J 26042.5344 357935.0756 Tabla 3.4: Tiempo de ejecuci´on en segundos (T.E.), consumo de energ´ıa en Julios (C.E.) y Energy-Delay Product (EDP) de las aplicaciones sobre los distintos clusters utilizando 4 hilos. 3.2.3. An´alisis del cluster little La Figura 3.2 muestra los resultados de tiempos de ejecuci´on del cluster little. En cuanto a tiempo de c´omputo, TinySTM muestra una buena escalabilidad en los n´ucleos A7. En todos los experimentos la reducci´on en tiempo es aproximadamente del 50 % utilizando 2 hilos y del 70 % utilizando 4 hilos (seg´un la media geom´etrica), respecto al uso de 1 hilo. 36 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.2: Tiempo de ejecuci´on normalizado a 1 hilo en cluster little. En la Figura 3.3 se muestra el consumo de energ´ıa de las aplicaciones en el cluster little. Igual que la anterior, esta presenta una reducci´on de aproximadamente 50 % al utilizar 2 hilos y 70 % al usar 4 hilos respecto al consumo de 1 hilo. Los procesadores A15 no se est´an utilizando lo que resulta en un consumo de energ´ıa reducido. 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.3: Consumo de energ´ıa normalizado a 1 hilo en cluster little. En la Figura 3.4 se muestra el Energy-Delay Product. Se ve una reducci´on del 70 % aproximadamente al utilizar 2 hilos y del 90 % al utilizar 4 hilos respecto a 1. 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.4: EDP normalizado a 1 hilo en cluster little. 37 En conclusi´on, para las aplicaciones evaluadas y utilizando TinySTM en el cluster little, es beneficioso aumentar el n´umero de hilos de ejecuci´on para mejorar tanto en tiempo de ejecuci´on como la eficiencia energ´etica. 3.2.4. An´alisis del cluster big La Figura 3.5 muestra los tiempos de ejecuci´on normalizados en el cluster big. En este caso la media geom´etrica muestra que existe una reducci´on de aproximadamente 60 % utilizando 2 hilos y del 54 % utilizando 4 hilos, respecto al uso de 1 hilo. Por tanto, aunque existe cierta escalabilidad en las aplicaciones, no es tan pronunciada como la que se produce en el cluster little. 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.5: Tiempo de ejecuci´on normalizado a 1 hilo en cluster big. La Figura 3.6 muestra los consumos de energ´ıa normalizados en el cluster big. Este cluster no es tan eficiente en t´erminos de energ´ıa como el cluster little. Se observa que aplicaciones como intruder,kmeans yvacation muestran un incremento en el consumo energ´etico cuando utilizan los 4 n´ucleos. Observando la media geom´etrica, por lo general aumenta el consumo de energ´ıa en las 5 aplicaciones al utilizar 4 hilos. 124 Number of threads 0.00 0.28 0.56 0.84 1.12 1.40 intruder++ 124 Number of threads 0.00 0.32 0.64 0.96 1.28 1.60 kmeans++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.00 0.32 0.64 0.96 1.28 1.60 vacation++ 124 Number of threads 0.00 0.24 0.48 0.72 0.96 1.20 Geometric mean Figura 3.6: Consumo de energ´ıa normalizado a 1 hilo en cluster big. La Figura 3.7 muestra el EDP. Como resultado del elevado consumo de energ´ıa, el 38 EDP no resulta ´optimo en todas las aplicaciones utilizan 4 hilos. Las aplicaciones intruder, kmeans yvacation encuentran un EDP m´as eficiente utilizando ´unicamente 2 hilos. 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.7: EDP normalizado a 1 hilo en cluster big. La media geom´etrica muestra que, en cuanto a tiempos de c´omputo, es preferible utilizar 4 hilos para la mayor´ıa de aplicaciones. Sin embargo, utilizar 4 hilos resulta en un consumo de energ´ıa superior en comparaci´on con el uso de 2 hilos. Estas diferencias se compensan en el EDP. Apenas existe diferencia en el promedio del EDP comparando la ejecuci´on con 2 y 4 hilos. 3.2.5. An´alisis de ambos clusters En los datos mostrados a continuaci´on se utilizan hasta 8 hilos con el objetivo de utilizar ambos clusters. Antes de ejecutar las aplicaciones, observamos el comportamiento del sistema operativo en cuanto a planificaci´on de hilos. Durante las pruebas hasta 4 hilos, el sistema operativo planifica utilizando el cluster big, y es cuando introducimos los 8 hilos cuando comienza a planificar con ambos clusters. La Figura 3.8 muestra, hasta 4 hilos de ejecuci´on, un rendimiento similar a la mostrada en la Figura 3.6. Es cuando se incrementan los hilos hasta 8 cuando se observa que los tiempos de ejecuci´on mejoran. Como se ha comentado anteriormente, la planificaci´on de los 4 primeros hilos se realiza sobre el cluster big, y no se aprecian diferencias en los tiempos de c´omputo. Al incrementar el n´umero de hilos hasta 8 se comienza a utilizar el cluster little, lo cual reduce los tiempos de c´omputo. La Figura 3.9 muestra, igual que la anterior, un rendimiento similar al del cluster big mientras se utilizan hasta 4 hilos. Se observa que existe una mejora en el consumo de energ´ıa de todas las aplicaciones excepto en kmeans d´onde empeora ligeramente respecto al uso de 1 y 2 hilos. La Figura 3.10 refleja el EDP, calculado respecto a las 2 gr´aficas anteriores. Como se ha comentado anteriormente, siempre existe una mejora utilizando 8 hilos en cuanto a tiempos de ejecuci´on. En la gr´afica de consumo de energ´ıa kmeans empeora utilizando 8 39 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.8: Tiempo de ejecuci´on normalizado a 1 hilo utilizando ambos clusters. 1248 Number of threads 0.00 0.28 0.56 0.84 1.12 1.40 intruder++ 1248 Number of threads 0.00 0.32 0.64 0.96 1.28 1.60 kmeans++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 1248 Number of threads 0.00 0.32 0.64 0.96 1.28 1.60 vacation++ 1248 Number of threads 0.00 0.24 0.48 0.72 0.96 1.20 Geometric mean Figura 3.9: Consumo de energ´ıa normalizado a 1 hilo utilizando ambos clusters. hilos, cuando los dem´as mejoran. Este empeoramiento del consumo de energ´ıa no tiene impacto en el EDP de kmeans. El EDP mejora utilizando ambos clusters en todos los casos. 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 labyrinth++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 1248 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.10: EDP normalizado a 1 hilo utilizando ambos clusters. 3.2.6. Comparativa entre ambos clusters En las siguientes Figuras se muestra una comparativa entre los clusters little y big. Las m´etricas se representan utilizando el cociente A7/A15: valores mayor que 1 significan que 40 hay mejor rendimiento en el cluster big y valores menores que 1 hay un mejor rendimiento en el cluster little. En la Figura 3.11 se muestra el resultado de la operaci´on TiempoEj.A7/TiempoEj.A15. Utilizando un hilo de ejecuci´on obtiene mejor rendimiento el cluster big gracias a su potencia de c´alculo. Conforme aumenta el n´umero de hilos, en rendimiento empieza a cambiar a favor del cluster little. La aplicaci´on labyrinth es una excepci´on, se observa que en todos los casos, respecto al tiempo, tiene un mejor rendimiento el cluster big dado que requiere mayor potencia de c´alculo. 124 Number of threads 0.00 0.24 0.48 0.72 0.96 1.20 intruder++ 124 Number of threads 0.00 0.28 0.56 0.84 1.12 1.40 kmeans++ 124 Number of threads 0.0 0.6 1.2 1.8 2.4 3.0 labyrinth++ 124 Number of threads 0.00 0.24 0.48 0.72 0.96 1.20 ssca2++ 124 Number of threads 0.00 0.24 0.48 0.72 0.96 1.20 vacation++ 124 Number of threads 0.00 0.28 0.56 0.84 1.12 1.40 Geometric mean Figura 3.11: TiempoEjecuci´onA7/TiempoEjecuci´onA15 En la Figura 3.12 se muestra el resultado de la operaci´on ConsumoEn.A7/ConsumoEn.A15. En todos los casos excepto en labyrinth con 1 hilo de ejecuci´on, el cluster little produce mejores resultados que el cluster big. Esta aplicaci´on en concreto se beneficia de la mayor potencia de c´alculo del cluster big, por lo que logra terminar antes y reducir su consumo energ´etico. 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 intruder++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 kmeans++ 124 Number of threads 0.00 0.24 0.48 0.72 0.96 1.20 labyrinth++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 ssca2++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 vacation++ 124 Number of threads 0.0 0.2 0.4 0.6 0.8 1.0 Geometric mean Figura 3.12: ConsumoEnerg´ıaA7/ConsumoEnerg´ıaA15 En la Figura 3.13 se realiza la operaci´on EDPA7/EDPA15. Se comprueba una mayor eficiencia en el cluster little excepto en labyrinth, donde se observa que el cluster big es m´as apropiado. Dado que de las aplicaciones utilizadas labyrinth es la ´unica que presenta transacciones largas y modificar una gran cantidad de datos (ver Tabla 1.1), necesita 41 [10] N. L. Binkert, R. G. Dreslinski, L. R. Hsu, K. T. Lim, A. G. Saidi, and S. K. Reinhardt. The M5 simulator: Modeling networked systems. IEEE Micro, 26(4):52–60, July 2006. [11] 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. In 2007 IEEE 13th International Symposium on High Performance Computer Architecture, pages 97–108, Feb 2007. [12] Luke Dalessandro, Michael F Spear, and Michael L Scott. NOrec: Streamlining STM by Abolishing Ownership Records - PPoPP ’10. pages 67–77, 2010. [13] Dave Dice, Ori Shalev, and Nir Shavit. Transactional Locking II. In Distributed Computing, volume 4167, pages 194–208. Springer, 2006. [14] Nuno Diegues, Paolo Romano, and Lu´ıs Rodrigues. Virtues and limitations of commodity hardware transactional memory. In 23rd Int’l. Conf. on Parallel Architectures and Compilation Techniques (PACT’14), pages 3–14, 2014. [15] Aleksandar Dragojevi´c, Rachid Guerraoui, and Michal Kapalka. Stretching transactional memory. In ACM Sigplan Notices, volume 44, pages 155–165. ACM, 2009. [16] P. Felber, C. Fetzer, P. Marlier, and T. Riegel. Time-based software transactional memory. IEEE Trans. on Parallel and Distributed Systems, 21(12):1793–1807, 2010. [17] Pascal Felber, Christof Fetzer, and Torvald Riegel. Dynamic performance tuning of word-based software transactional memory. In 13th ACM SIGPLAN Symp. on Principles and Practice of Parallel Programming (PPoPP’08), pages 237–246, 2008. [18] Cesare Ferri, Amber Viescas, Tali Moreshet, Iris Bahar, and Maurice Herlihy. Energy implications of transactional memory for embedded architectures. Workshop on Exploiting Parallelism with Transactional Memory and other Hardware Assisted Methods (EPHAM’08), 2008. [19] E. Gaona, R. Titos-Gil, M. E. Acacio, and J. Fern´andez. Dynamic serialization: Improving energy consumption in eager-eager hardware transactional memory systems. In 2012 20th Euromicro International Conference on Parallel, Distributed and Network-based Processing, pages 221–228, Feb 2012. [20] Epifanio Gaona-Ram´ırez, Rub´en Titos-Gil, Juan Fern´andez, and Manuel E Acacio. Characterizing energy consumption in hardware transactional memory systems. In Computer Architecture and High Performance Computing (SBAC-PAD), 2010 22nd International Symposium on, pages 9–16. IEEE, 2010. 48 [21] Bart Haagdorens, Tim Vermeiren, and Marnix Goossens. Information Security Applications: 5th International Workshop, WISA 2004, Jeju Island, Korea, August 23-25, 2004, Revised Selected Papers, chapter Improving the Performance of SignatureBased Network Intrusion Detection Sensors by Multi-threading, pages 188–203. Springer Berlin Heidelberg, Berlin, Heidelberg, 2005. [22] Tim Harris, James Larus, and Ravi Rajwar. Transactional Memory, 2nd. Morgan & Claypool Publishers, USA, 2010. [23] Maurice Herlihy and J. Eliot B. Moss. Transactional memory: Architectural support for lock-free data structures. In 20th Ann. Int’l. Symp. on Computer Architecture (ISCA’93), pages 289–300, 1993. [24] J. D. Hunter. Matplotlib: A 2D graphics environment. Computing In Science & Engineering, 9(3):90–95, 2007. [25] F. Klein, A. Baldassin, G. Araujo, P. Centoducatte, and R. Azevedo. On the energyefficiency of software transactional memory. In Proceedings of the 22Nd Annual Symposium on Integrated Circuits and System Design: Chip on the Dunes, SBCCI ’09, pages 33:1–33:6, New York, NY, USA, 2009. ACM. [26] Nasser A. Kurd, Muntaquim Chowdhury, Edward Burton, Thomas P. Thomas, Christopher Mozak, Brent Boswell, Praveen Mosalikanti, Mark Neidengard, Anant Deval, Ashish Khanna, Nasirul Chowdhury, Ravi Rajwar, Timothy M. Wilson, and Rajesh Kumar. Haswell: A family of IA 22 nm processors. J. Solid-State Circuits, 50(1):49– 58, 2015. [27] James H Laros III, Kevin Pedretti, Suzanne M Kelly, Wei Shu, Kurt Ferreira, John Vandyke, and Courtenay Vaughan. Energy delay product. Energy-Efficient High Performance Computing, pages 51–55, 2013. [28] C. Y. Lee. An algorithm for path connections and its applications. IRE Transactions on Electronic Computers, EC-10(3):346–365, Sept 1961. [29] P. S. Magnusson, M. Christensson, J. Eskilson, D. Forsgren, G. Hallberg, J. Hogberg, F. Larsson, A. Moestedt, and B. Werner. Simics: A full system simulation platform. Computer, 35(2):50–58, Feb 2002. [30] 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 multiprocessor simulator (gems) toolset. SIGARCH Comput. Archit. News, 33(4):92–99, November 2005. 49 [31] Chi Cao Minh, Jaewoong Chung, C. Kozyrakis, and K. Olukotun. Stamp: Stanford transactional applications for multi-processing. In Workload Characterization, 2008. IISWC 2008. IEEE International Symposium on, pages 35–46, Sept 2008. [32] Kevin E Moore, Jayaram Bobba, Michelle J Moravan, Mark D Hill, David A Wood, et al. Logtm: log-based transactional memory. In HPCA, volume 6, pages 254–265, 2006. [33] Tali Moreshet, R Iris Bahar, and Maurice Herlihy. Energy-aware microprocessor synchronization: Transactional memory vs. locks. Fourth Annual Boston-Area Architecture Workshop, page 21, 2006. [34] R. Narayanan, B. Ozisikyilmaz, J. Zambreno, G. Memik, and A. Choudhary. Minebench: A benchmark suite for data mining workloads. In 2006 IEEE International Symposium on Workload Characterization, pages 182–188, Oct 2006. [35] Wenjia Ruan, Yujie Liu, and Michael Spear. STAMP Need Not Be Considered Harmful. pages 1–7, 2014. [36] J. Ruppert. A delaunay refinement algorithm for quality 2-dimensional mesh generation. Journal of Algorithms, 18(3):548 – 585, 1995. [37] S. Sanyal, S. Roy, A. Cristal, O. S. Unsal, and M. Valero. Clock gate on abort: Towards energy-efficient hardware transactional memory. In Parallel Distributed Processing, 2009. IPDPS 2009. IEEE International Symposium on, pages 1–8, May 2009. [38] Wikipedia. Red bayesiana — wikipedia, la enciclopedia libre. https://es. wikipedia.org/w/index.php?title=Red_bayesiana&oldid=90838441, 2016. [Internet; descargado 3-junio-2016]. 50