Evaluación del consumo energético de la memoria transaccional en procesadores heterogéneos

Evaluaci´on del Consumo Energ´etico de la Memoria Transaccional Software en Procesadores Heterog´eneos Emilio Villegas, Alejandro Villegas , ´ Angeles Navarro, Rafael Asenjo, Oscar Plata1 Resumen—Actualmente existe una enorme cantidad de dispositivos y sistemas, como ordenadores port´atiles y tel´efonos m´oviles, que dependen de una bater´ıa para su funcionamiento. Como consecuencia, el hardware que incorporan debe ser energ´eticamente eficiente. La industria, para soportar este mercado, est´a desarrollando procesadores con el objetivo de reducir su consumo energ´etico. Por ejemplo, ARM propone la arquitectura big.LITTLE como un procesador multi-n´ucleo heterog´eneo: unos n´ucleos m´as r´apidos para aplicaciones orientadas al rendimiento, y otros m´as lentos orientados a la eficiencia energ´etica. Puesto que todos los n´ucleos acceden a la misma memoria f´ısica, las aplicaciones multi-hilo deben recurrir a alg´un tipo de sincronizaci´on para coordinar el acceso a los datos compartidos. La memoria transaccional (TM) es una soluci´on optimista para ofrecer sincronizaci´on de hilos concurrentes en memoria compartida. En TM se permite el acceso en paralelo a los datos compartidos y, mediante un mecanismo de detecci´on de conflictos, se puede garantizar la exclusi´on m´utua. Para beneficiarse de las ventajas que ofrece TM, as´ı como de las caracter´ısticas de los procesadores heterog´eneos de bajo consumo, es necesario que las soluciones de TM tengan en cuenta los requisitos energ´eticos y de rendimiento de las aplicaciones en consonancia con lo que ofrece el procesador. Como paso inicial, hay que comprender el rendimiento y consumo energ´etico de las soluciones TM actuales. Para ello, hemos realizado una evaluaci´on de consumo y rendimiento de una librer´ıa de TM software, TinySTM, sobre un procesador del tipo big.LITTLE. Los resultados revelan una buena escalabilidad en los n´ucleos de bajo consumo para la mayor´ıa de las aplicaciones evaluadas. Sin embargo, la aplicaci´on con mayores requerimientos de c´omputo resulta ser energ´eticamente m´as eficiente en los n´ucleos orientados al rendimiento, a pesar de su mayor consumo. Palabras clave— Memoria transaccional software, Procesadores heterog´eneos, Eficiencia energ´etica. I. Introducci´ on Hoy d´ıa podemos encontrar dispositivos m´oviles y empotrados en una gran variedad de entornos. Ejemplos son los tel´efonos m´oviles, ordenadores port´atiles, controladores e infinidad de aplicaciones del Internet of Things. Todos estos dispositivos deben ser energ´eticamente eficientes. En primer lugar, suelen depender de una fuente de alimentaci´on integrada (por ejemplo, una bater´ıa). En segundo lugar, el entorno en el que se sit´uan puede tener restricciones en cuanto a su consumo y temperatura. Por ejemplo, la energ´ıa disipada (y, por tanto, la temperatura) de un tel´efono m´ovil debe ser baja para que sea c´omodo de utilizar por parte del usuario. 1Universidad de M´alaga, Andaluc´ıa Tech, Dept. Arquitectura de Computadores, 29071 M´alaga. e-mail: emi- [email protected], a[email protected], [email protected], [email protected], [email protected] Conforme el mercado de este tipo de dispositivos crece, la industria se est´a centrando en dise˜nar procesadores de bajo, consumo energ´eticamente eficientes. Concretamente, ARM desarrolla procesadores que se utilizan en dispositivos en los que debe mantenerse un equilibrio entre consumo de energ´ıa, temperatura y rendimiento. Para conseguir este equilibrio, han desarrollado la arquitectura multi-n´ucleo llamada big.LITTLE [1]. Esta arquitectura incorpora dos conjuntos de n´ucleos: unos n´ucleos m´as r´apidos, orientados al rendimiento, y otros n´ucleos con menor capacidad de c´alculo pero energ´eticamente m´as eficientes. Estos n´ucleos est´an organizados en 2 clusters que llamamos cluster big ycluster little, respectivamente. Los n´ucleos de ambos clusters implementan el mismo ISA y tienen acceso a la misma memoria f´ısica, por lo que una aplicaci´on puede ejecutarse en cualquiera de los clusters indistintamente. Por tanto, las aplicaciones con altos requerimientos de c´omputo ser´an (probablemente) planificadas en el cluster big, mientras que aquellas sin estos requerimientos pueden ejecutarse en el cluster little. Las aplicaciones deben ser programadas con un dise˜no multi-hilo para que aprovechen las capacidades de los procesadores multi-n´ucleo. Programar este tipo de aplicaciones puede ser un reto para los programadores, especialmente cuando se necesita sincronizaci´on entre 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 m´utua en su acceso por parte de los hilos de ejecuci´on. La exclusi´on m´utua se implementa de forma tradicional utilizando cerrojos. Un cerrojo de grano grueso garantiza que ning´un hilo puede acceder a la secci´on cr´ıtica si alguno de ellos ya se encuentra ejecut´andola. Normalmente, esto tiene un gran impacto en el rendimiento de la aplicaci´on ya que puede producir una serializaci´on innecesaria si se necesita acceder a la secci´on cr´ıtica frecuentemente pero, dentro de ella, acceden a posiciones de memoria diferentes. Para obtener un mayor rendimiento en estos casos se puede recurrir a una implementaci´on de cerrojos de grano fino. En ella se protegen individualmente las posiciones de memoria (o las variables u objetos), de forma que puede accederse de forma paralela a la secci´on cr´ıtica ´unicamente si van a modificarse datos disjuntos. Con esta implementaci´on se pretende explotar un mayor paralelismo de la aplicaci´on pero, a cambio, se requiere un esfuerzo de programaci´on mucho mayor. Por ejemplo, com- probar la correci´on de esta implementaci´on y que no existan deadlocks ni livelocks es una tarea dif´ıcil. La Memoria Transaccional (TM) [2] se ha propuesto como una alternativa optimista a los cerrojos para implementar secciones cr´ıticas. Con TM, utilizamos transacciones para definir las secciones cr´ıticas. Las transacciones pueden ejecutarse en paralelo, pero los accesos a memoria que se realizan dentro de ellas deben ser registrados. Si dos o m´as transacciones han accedido a la misma posici´on de memoria y, al menos, un acceso es de escritura se registra un conflicto. En caso de conflicto, s´olo una de las transacciones tiene permitido continuar o terminar su ejecuci´on. El resto debe deshacer (o descartar) los cambios especulativos en memoria y reiniciar su ejecuci´on. La idea es que las transacciones proporcionen al programador una interfaz similar al uso de cerrojos de grano grueso, pero un rendimiento similar a los cerrojos de grano fino. Adem´as, la implementaci´on de TM debe asegurar la correci´on (esto es, que no existan deadlocks y el progreso est´e garantizado). En las ´ultimas d´ecadas se han propuesto varias soluciones TM implementadas en hardware [3] y algunos procesadores multi-n´ucleo actuales incorporan este soporte [4]. Adem´as de las soluciones hardware, se han propuesto numerosas soluciones software en forma de librer´ıas [5], [6], [7], [8], [9]. Por ´ultimo, tambi´en han aparecido soluciones h´ıbridas que combinan las caracter´ısticas de los TM software y hardware [10]. Adaptar las soluciones TM existente a los procesadores multi-n´ucleo heterog´eneos de bajo consumo es un objetivo importante para los pr´oximos a˜nos. Existen ya algunos an´alisis y propuestas de TM que tienen en cuenta el consumo de energ´ıa de los procesadores [11], [12], [13], [14], [15], [16], [17]. Sin embargo, estas propuestas no tienen en cuenta los procesadores multi-n´ucleo heterog´eneos y est´an enfocadas a procesadores homog´eneos. Adem´as, ninguna de las propuestas existentes considera la evaluaci´on sobre un sistema real: en todas ellas, tanto hardware como software, se han utilizado simuladores para estimar el consumo energ´etico. En este art´ıculo evaluamos un sistema TM software (STM) ampliamente utilizado, TinySTM [5], [6], sobre la plataforma Odroid-XU3 [18], que incorpora un procesador tipo big.LITTLE. Para ello, hemos utilizado un conjunto de aplicaciones provenientes del STAMP [19] benchmark suite y los sensores de energ´ıa disponibles en el dispositivo. El objetivo es analizar el comportamiento de la librer´ıa sobre este tipo de procesadores y obtener datos e infraestructura sobre la que hacer propuestas futuras de TM con restricciones energ´eticas. II. Antecedentes A. Arquitectura big.LITTLE de ARM La arquitectura heterog´enea big.LITTLE de ARM est´a pensada para adaptarse a todo tipo de escenarios, incorporando n´ucleos de alto rendimiento y otros de bajo consumo. Seg´un sus propios datos [1], esto permite ahorrar hasta un 75 % de energ´ıa en Mali GPU (600 Mhz) 2Gbyte LPDDR3 Memory (933 Mhz) Cortex-A15 Quad (2 Ghz) Cortex-A7 Quad (1,4 Ghz) A15 Core A15 Core A15 Core A15 Core 2Mbyte L2 Cache A7 Core A7 Core A7 Core A7 Core 512Kbyte L2 Cache Exynox 5422 Processor Fig. 1: Diagrama del procesador Exynox 5422 disponible en la plataforma ODROID-XU3. escenarios de bajos requerimientos de c´omputo e incrementar hasta un 40 % el rendimiento en aplicaciones multi-hilo. En su primera generaci´on, los n´ucleos de bajo consumo pertenecen a la familia Cortex-A7, mientras que los n´ucleos de alto rendimiento pertenecen a la familias Cortex-A15 o Cortex-A17. En su segunda generaci´on, los n´ucleos de bajo consumo son de las familias Cortex-A35 o Cortex-A53, y los de alto rendimiento son de las familias Cortex-A57 o Cortex-A72. Los n´ucleos de cada tipo est´an organizados en 2 clusters. Por ejemplo, una configuraci´on t´ıpica de la primera generaci´on son 4 n´ucleos CortexA7 (para el cluster little) y 4 n´ucleos Cortex-A15 (para el cluster big). Ambos clusters incorporan una jerarqu´ıa cache coherente de dos niveles. B. ODROID-XU3 El dispositivo que hemos utilizado para la evaluaci´on es ODROID-XU3 [18]. Este dispositivo incorpora un procesador Samsung Exynos 5422, basado en la arquitectura big.LITTLE de ARM de primera generaci´on. El procesador tiene 4 n´ucleos CortexA7 en el cluster little y 4 n´ucleos Cortex-A15 en el cluster big, con 512 Kbytes y 2 Mbytes de cache L2, respectivamente. El sistema incorpora una GPU MALI-T628 y 2 Gbytes de memoria DDR3. El sistema operativo instalado sobre el dispositivo es Linux odroid 3.10.59+. Adem´as, se incluyen monitores INA231 de corriente/energ´ıa1capaces medir el consumo de energ´ıa del cluster big, cluster little, GPU y memoria. Estos sensores de energ´ıa son accesibles desde el directorio /sys del sistema de ficheros. Los datos proporcionados no son acumulativos, sino instant´aneos. Hemos desarrollado una librer´ıa que accede a dichos sensores y proporciona el consumo energ´etico. Para ello, esta librer´ıa dedica un hilo de ejecuci´on a leer estos sensores e integrar sus valores utilizando el reloj de tiempo real del sistema. Una vez que este hilo est´a ejecutando, podemos utilizar las funciones que proporciona para medir la energ´ıa consumida por las distintas secciones de nuestro c´odigo. La resoluci´on de estas medidas es de 100 milisegundos. 1http://www.ti.com/product/ina231 C. TinySTM TinySTM [5], [6] es una librer´ıa de TM software ampliamente utilizada (disponible en http:// tmware.org/tinystm). Su implementaci´on est´a basada en timestamps y trabaja a nivel de palabra de memoria. Para la gesti´on de transacciones, TinySTM incorpora varios modelos. En el modelo write-back, los cambios especulativos en memoria se almacenan en un buffer hasta el final de la transacci´on, momento en el que se hacen definitivos si no existen conflictos. En el modelo write-through, los cambios especulativos se guardan directamente en memoria y los valores antiguos (que deben restaurarse en caso de conflicto) se guardan en un log. En el modelo commit-time locking, se utilizan cerrojos durante la finalizaci´on (commit) de la transacci´on para proteger las posiciones que est´an siendo actualizadas. El caso contrario (esto es, los cerrojos se deben obtener en cada acceso a memoria en lugar de al final de la transacci´on) se llama encounter-time locking. Durante nuestros experimentos hemos utilizado la configuraci´on por defecto de TinySTM, que emplea las opciones write-back y encounter-time locking. Por ´ultimo, hemos observado que TinySTM utiliza la librer´ıa atomic ops para la implementaci´on de algunas de sus funcionalidades. Una versi´on reducida de esta librer´ıa viene incluida en TinySTM pero, sin embargo, no puede ser utilizada en arquitecturas ARM. El motivo es que algunas de sus funciones est´an especialmente programadas para otro tipo de arquitecturas. Afortunadamente, el sistema operativo Linux odroid 3.10.59+ incorpora esta librer´ıa compilada para procesadores ARM. D. STAMP benchmark suite El conjunto de aplicaciones STAMP [19] es muy popular a la hora de evaluar distintos sistemas de TM, tanto software como hardware. Incluye, en total, ocho aplicaciones de diferentes dominios: ciencia, ingenier´ıa, seguridad, aprendizaje computacional, etc. . . Para cada aplicaci´on se pueden definir diversos par´ametros de entrada con el objetivo de enfatizar las diferentes caracter´ısticas del TM a evaluar. Adem´as, se incluyen unos conjuntos de datos y par´ametros de entrada por defecto que facilitan la comparaci´on de distintos TM. III. Evaluaci´ on de energ ´ ıa y rendimiento. A. Dispositivo Como dispositivo para nuestras pruebas hemos escogido el ODROID-XU3. La tabla I resume las caracter´ısticas de este dispositivo explicadas anteriormente. B. Benchmarks Hemos seleccionado 5 aplicaciones de las disponibles en el STAMP benchmark suite: intruder, kmeans,labyrinth,scaa2, and vacation. Por defecto, hemos utilizado los par´ametros de entrada ++, tal y como se definen en [19]. Las aplicaciones kmeans Caracter´ıstica Descripci´on CPU Samsung Exynos-5422 : Cortex-A15 y Cortex-A7 big.LITTLE Memoria principal 2 Gbyte LPDDR3 RAM 933MHz GPU Mali-T628 MP6 Almacenamiento 32GB Sandisk iNAND Extreme Medici´on de energ´ıa Sensores separados para el cluster big, el cluster little, GPU y memoria. S.O. Linux odroid 3.10.59+ TABLA I: Sistema ODROID-XU3 utilizado durante la evaluaci´on. y vacation disponen, a su vez, de entradas de baja y alta contenci´on. Para nuestros experimentos hemos utilizado las entradas de alta contenci´on. En la tabla II se resumen las principales caracter´ısticas de las aplicaciones evaluadas. De las aplicaciones disponibles, 3 han sido excluidas por diferentes motivos. En bayes se obtienen resultados irregulares tras varias ejecuciones del programa, por lo que decidimos excluirla de la evaluaci´on. Este problema ha sido documentado con anterioridad en [20]. La aplicaci´on genome presenta problemas de sincronizaci´on cuando se utiliza m´as de un hilo de ejecuci´on para su evaluaci´on. En yada se producen errores de falta de memoria para el conjunto de datos de entrada ++. Actualmente estamos investigando estos problemas. C. Instrumentaci´on del c´odigo Por defecto, el c´odigo de STAMP est´a instrumentado con contadores de tiempo para medir el rendimiento de las distintas aplicaciones. Para nuestros experimentos, hemos desarrollado una librer´ıa de instrumentaci´on propia y hemos reemplazado la incorporada en STAMP. Esta librer´ıa proporciona acceso a los sensores de energ´ıa mencionados anteriormente: cluster big, cluster little, GPU y memoria. Adem´as, se ha a˜nadido un contador de tiempo de ejecuci´on. Se ha comprobado que los resultados de este ´ultimo y los proporcionados en la librer´ıa que STAMP Aplicaci´on Longitud de transacci´on Conjuntos de lectura y escritura Tiempo en transacci´on intruder Corta Medios Medio kmeans Corta Peque˜nos Bajo labyrinth Larga Grandes Alto ssca2 Corta Peque˜nos Bajo vacation Media Medios Alto TABLA II: Aplicaciones utilizadas en la evaluaci´on. incorpora por defecto no tienen una variaci´on significativa. Por ´ultimo, como el objetivo es comprobar la energ´ıa consumida por todo el sistema, nuestros experimentos miden la energ´ıa de los cuatro sensores, integramos el consumo instant´aneo a lo largo del tiempo de ejecuci´on para cada uno de ellos y retornamos su suma. D. Resultados experimentales Durante los experimentos, examinamos tres m´etricas. En primer lugar, medimos el tiempo de ejecuci´on normalizado al tiempo empleado por un hilo utilizado la librer´ıa TinySTM. En segundo lugar, medimos la energ´ıa consumida por la ejecuci´on completa de cada aplicaci´on. De nuevo, esta segunda medida est´a normalizada a la ejecuci´on de un s´olo hilo utilizando TinySTM. Por ´ultimo, calculamos el EDP (Energy-Delay Product) con los datos anteriores. El EDP tiene en cuenta tanto el tiempo de ejecuci´on como la energ´ıa consumida por la aplicaci´on: valores peque˜nos muestran una mayor eficiencia. Para cada una de las m´etricas (tiempo de ejecuci´on, energ´ıa consumida y EDP) se han representado las medias geom´etricas de las cinco aplicaciones evaluadas. En cada experimento se han llevado a cabo diez ejecuciones y se ha calculado el valor promedio para cada una de las m´etricas. No obstante, los resultados obtenidos han sido consistentes en cada una de las diez ejecuciones. La normalizaci´on de cada m´etrica se ha llevado a cabo utilizando una ejecuci´on de TinySTM con un ´unico hilo. No se ha utilizado para esta comparaci´on una versi´on secuencial del c´odigo ya que la instrumentaci´on es distinta y los resultados pueden no ser comparables con los obtenidos por TinySTM. La implementaci´on de TinySTM est´a optimizada para otras arquitecturas y ´unicamente resulta competitiva (en t´erminos de velocidad y consumo energ´etico) para la aplicaci´on labyrinth. Sin embargo, el objetivo es evaluar la escalabilidad, tanto energ´etica como de rendimiento, de TinySTM en una arquitectura heterog´enea, pero no su comparaci´on con otras implementaciones de las aplicaciones. D.1 Resultados de la ejecuci´on En la tabla III se muestran los tiempos de ejecuci´on y consumo de energ´ıa de las aplicaciones utilizando cuatro hilos en los clusters big y little. En los siguientes apartados se representan gr´aficamente y se comentan estos resultados. D.2 An´alisis del cluster little La figura 2 muestra los resultados de la evaluaci´on del cluster little. En cuanto al tiempo de ejecuci´on (fig. 2.a), TinySTM muestra una buena escalabilidad en los n´ucleos Cortex-A7 en todas las aplicaciones. La misma afirmaci´on se aplica al consumo de energ´ıa (fig. 2.b) y EDP (fig. 2.c). Por ejemplo, utilizar cuatro hilos de ejecuci´on proporciona una reducci´on del EDP en torno al 90 %, seg´un la media geom´etrica calculada. Recordar que el consumo de energ´ıa (y, por tanto, EDP) se miden para el procesador comAplicac. T.E.A7T.E.A15 C.E.A7C.E.A15 intruder 87.0 127.3 120.9 635.9 kmeans 22.3 37.5 31.9 187.7 labyrinth 91.4 34.5 136.9 295.9 ssca2 32.6 35.6 45.9 171.8 vacation 138.3 271.7 188.2 1317.0 TABLA III: Tiempo de ejecuci´on en segundos (T.E.) y consumo de energ´ıa en Julios (C.E.) de las aplicaciones sobre los distintos clusters utilizando cuatro hilos. pleto: el hecho de que los procesadores Cortex-A15 no est´en siendo utilizados resulta en un consumo de energ´ıa reducido. D.3 An´alisis del cluster big La figura 3 muestra los resultados de la evaluaci´on del cluster big. En este caso, el escenario es diferente si lo comparamos con el cluster little. Los tiempos de ejecuci´on (fig. 3.a) muestran escalabilidad, aunque de manera inferior al cluster little. Adem´as, los n´ucleos Cortex-A15 no son tan eficientes como los CortexA7 en t´erminos de energ´ıa (fig. 3.b). Por ejemplo, las aplicaciones intruder, kmeans y vacation muestran un incremento en el consumo energ´etico cuando se activan los cuatro n´ucleos. Como resultado de este incremento en el consumo, el EDP (fig. 3.c) no resulta ´optimo en todas las aplicaciones cuando ejecutan cuatro hilos. Las aplicaciones mencionadas anteriormente (intruder, kmeans y vacation) encuentran un EDP m´as eficiente utilizando ´unicamente dos hilos, lo cual aumenta levemente su tiempo de ejecuci´on en comparaci´on con la utilizaci´on de cuatro hilos. La media geom´etrica nos muestra que, en cuanto a tiempo de ejecuci´on, es preferible utilizar cuatro hilos para la mayor´ıa de aplicaciones. Sin embargo, utilizar cuatro hilos resulta en un consumo de energ´ıa un 20 % superior en comparaci´on con el uso de dos hilos. Estas diferencias se compensan m´utuamente en el EDP: no existen diferencias apreciables en el EDP promedio comparando la ejecuci´on utilizando dos hilos o cuatro hilos. D.4 Evaluaci´on de ambos clusters La figura 4 muestra la evaluaci´on de las aplicaciones cuando incrementamos el n´umero de hilos hasta ocho con el objetivo de utilizar ambos clusters. Antes de ejecutar estas aplicaciones, observamos el comportamiento del sistema operativo en cuanto a planificaci´on de hilos. Durante nuestros primeros experimentos hemos comprobado que, utilizando cuatro hilos de ejecuci´on o menos, el sistema operativo los planifica en el cluster big tan pronto como detecta alg´un tipo de carga computacional. En el momento que se utilizan los ocho hilos de ejecuci´on, el sistema operativo decide hacer uso del cluster little junto al cluster big. Los resultados de tiempos de ejecuci´on (fig. 4.a) muestran que, hasta cuatro hilos, la aceleraci´on es similar al uso del cluster big. Cuando 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 a. Tiempo de ejecuci´on normalizado a un hilo. 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 b. Consumo de energ´ıa normalizado a un hilo. 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 c. EDP normalizado a un hilo. Fig. 2: Evaluaci´on del cluster little. incrementamos el n´umero de hilos hasta ocho podemos observar que los tiempos de ejecuci´on mejoran. Adem´as, el consumo de energ´ıa (fig. 4.b) mejora respecto al uso de ´unicamente el cluster big en todas las aplicaciones salvo kmeans, d´onde empeora ligeramente. Sin embargo, este ligero aumento no tiene impacto en el EDP (fig. 4.c), ya que la mejora en los tiempos de ejecuci´on compensa el incremento de consumo de energ´ıa. Por tanto, utilizar ambos clusters mejora el EDP en todos los casos. 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 a. Tiempo de ejecuci´on normalizado a un hilo. 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 b. Consumo de energ´ıa normalizado a un hilo. 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 c. EDP normalizado a un hilo. Fig. 3: Evaluaci´on del cluster big. D.5 Comparaci´on entre los clusters little y big La figura 5 muestra una comparativa entre los clusters little y big. Para el tiempo de ejecuci´on (fig. 5.a) representamos el cociente TiempoEjec.A7/TiempoEjec.A15. Valores mayores que 1 muestran un mejor rendimiento en el cluster big, mientras que los menores de 1 muestran un mejor rendimiento en el cluster little. La ejecuci´on de la aplicaci´on utilizando un ´unico hilo muestra que el cluster big obtiene mejores tiempos gracias a su po- 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 a. Tiempo de ejecuci´on normalizado a un hilo. 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 b. Consumo de energ´ıa normalizado a un hilo. 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 c. EDP normalizado a un hilo. Fig. 4: Evaluaci´on utilizando ambos clusters. tencia de c´alculo. Conforme el n´umero de hilos aumenta, el rendimiento empieza a cambiar a favor del cluster little. Dado que el cluster big es capaz de reintentar las transacciones abortadas m´as r´apidamente, tambi´en se produce un aumento significativo de aquellas que vuelven a tener alg´un conflicto durante dichos reintentos. Concretamente, en kmeans, intruder y ssca2 se produce un aumento del 71 %, 34 % y 56 %, respectivamente, en el n´umero de transacciones abortadas cuando las ejecutamos sobre el cluster 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 a. TiempoEjec.A7/TiempoEjec.A15. 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 b. ConsumoEnerg.A7/ConsumoEnerg.A15. 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.6 1.2 1.8 2.4 3.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 c. EDPA7/EDPA15. Fig. 5: Comparativa entre los clusters little y big. big en comparaci´on con el cluster little. Tal aumento en el n´umero de reintentos no puede ser compensado por la mayor potencia de c´alculo del cluster big, por lo que el cluster little resulta m´as eficiente. La aplicaci´on labyrinth es una excepci´on a lo dicho anteriormente: dado que requiere gran potencia de c´alculo, es capaz de aprovechar los recursos que el cluster big pone a su disposici´on. Adem´as, la variaci´on en el n´umero de transacciones abortadas es de apenas un 4 %, por lo que no se produce ning´un efecto negativo sobre el tiempo de ejecuci´on. La misma comparativa se realiza para el consumo de energ´ıa (fig. 5.b) realizando la operaci´on ConsumoEnerg.A7/ConsumoEnerg.A15. En todos los casos, salvo labyrinth con un s´olo hilo, el cluster little produce mejores resultados que el cluster big. Para el EDP (fig. 5.c) comprobamos una mayor eficiencia del cluster little salvo en labyrinth, donde el cluster big es m´as apropiado. Dado que labyrinth presenta transacciones largas que modifican gran cantidad de datos, requiere una gran potencia de c´alculo. Los n´ucleos Cortex-A15 son capaces de proporcionar esta potencia y amortizar el mayor consumo de energ´ıa. IV. Trabajo relacionado Recientemente se han realizado an´alisis del consumo de energ´ıa de TM sobre distintos tipos de procesadores y se han propuesto soluciones a partir de los resultados de dichos an´alisis. Gaona et al. [11] caracterizan el consumo de energ´ıa de dos TM hardware. Adem´as, proponen la serializaci´on din´amica de transacciones en hardware con el objetivo de reducir la energ´ıa consumida [12]. Esto lo consiguen tratando de minimizar el trabajo especulativo que se desaprovecha cuando las transacciones encuentran conflictos y deben abortar. Del mismo modo, Moreshet et al. [13] y Ferri et al. [21] realizan an´alisis energ´eticos de TM hardware utilizando simuladores. Sus resultados muestran una mejora en el consumo energ´etico comparado con el uso de soluciones de exclusi´on m´utua basadas en cerrojos. Baldassin et al. [14], [15] caracterizan la librer´ıa de TM software TL2 [9] sobre procesadores homog´eneos de bajo consumo basados en la arquitectura ARMv7 utilizando simuladores. Adem´as, proponen una soluci´on basada en la variaci´on din´amica del voltaje y el escalado de la frecuencia del procesador con el objetivo de reducir el consumo de energ´ıa. Sobre la misma plataforma, Klein et al. [16] proponen una estrategia basada en memoria scratch-pad para reducir el consumo energ´etico. Para ello, tambi´en han utilizado simuladores para estimar la energ´ıa consumida. Sanyal et al. [17] proponen el uso de t´ecnicas de clock-gating para reducir el consumo de energ´ıa en TM hardware y mejorar su rendimiento. En la investigaci´on previa no se han analizado procesadores con n´ucleos heterog´eneos como los de la arquitectura big.LITTLE. En este trabajo nos centramos en analizar TM software sobre este tipo de procesadores. Adem´as, dado que la plataforma hardware sobre la que realizamos nuestros experimentos nos proporciona sensores de consumo energ´etico, podemos obtener mediciones reales de la eficiencia energ´etica de la librer´ıa evaluada. Por contra, todos los an´alisis anteriores se han realizado utilizando simuladores. V. Conclusiones y trabajo futuro En este art´ıculo presentamos el an´alisis de una librer´ıa TM software ejecutada sobre un procesador multi-n´ucleo heterog´eneo basado en la arquitectura big.LITTLE de ARM. Nuestra evaluaci´on muestra que la escalabilidad de la librer´ıa, en t´erminos de rendimiento y energ´ıa, es mejor sobre el cluster little compuesto de cuatro n´ucleos Cortex-A7. Sin embargo, una de las aplicaciones analizadas (labyrinth) ha mostrado mejor rendimiento y una utilizaci´on m´as eficiente de la energ´ıa (esto es, menor EDP) en los n´ucleos Cortex-A15. En todos los casos, utilizar simult´aneamente el cluster big y el cluster little con ocho hilos de ejecuci´on resulta en una mejor´ıa en el rendimiento y la eficiencia energ´etica. Nuestro trabajo futuro se enfoca en utilizar los resultados e infraestructura expuestos en este art´ıculo para construir un planificador para aplicaciones que utilizan TM sobre procesadores heterog´eneos. El objetivo es permitir que las aplicaciones basadas en TM puedan situarse en los n´ucleos que les permitan obtener mayor eficiencia energ´etica. Adem´as, planeamos realizar un an´alisis m´as exhaustivo de la librer´ıa TinySTM (esto es, determinar el consumo de las funciones que TinySTM proporciona). Este segundo an´alisis nos permitir´a dise˜nar mejoras en la librer´ıa enfocadas al aprovechamiento de los recursos de los procesadores heterog´eneos. Agradecimientos Este trabajo ha sido realizado gracias a la financiaci´on de los proyectos TIN2013-42253-P del Ministerio de Econom´ıa y Competitividad, y P12-TIC-1470 y P11-TIC-08144 de la Junta de Andaluc´ıa. Referencias [1] “ARM big.LITTLE technology,” http://www. arm.com/products/processors/technologies/ biglittleprocessing.php. [2] 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), 1993, pp. 289–300. [3] Tim Harris, James Larus, and Ravi Rajwar, Transactional Memory, 2nd Ed., Morgan & Claypool Publishers, USA, 2010. [4] 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, vol. 50, no. 1, pp. 49–58, 2015. [5] Pascal Felber, Christof Fetzer, Patrick Marlier, and Torvald Riegel, “Time-based software transactional memory,” IEEE Trans. on Parallel and Distributed Systems, vol. 21, no. 12, pp. 1793–1807, 2010. [6] 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), 2008, pp. 237–246. [7] Aleksandar Dragojevi´c, Rachid Guerraoui, and Michal Kapalka, “Stretching transactional memory,” in 30th ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI’09), 2009, pp. 155–165. [8] Luke Dalessandro, Michael F. Spear, and Michael L. Scott, “NOrec: Streamlining STM by abolishing ownership records,” in 15th ACM SIGPLAN Symp. on Principles and Practice of Parallel Programming (PPoPP’10), 2010, pp. 67–78. [9] Dave Dice, Ori Shalev, and Nir Shavit, “Transactional Locking II,” in Distributed Computing, vol. 4167, pp. 194–208. Springer, 2006. [10] Nuno Diegues, Paolo Romano, and Lu´ıs Rodrigues, “Virtues and limitations of commodity hardware transactio- nal memory,” in 23rd Int’l. Conf. on Parallel Architectures and Compilation Techniques (PACT’14), 2014, pp. 3–14. [11] Epifanio Gaona-Ram´ırez, Rub´en Titos-Gil, Juan Fern´andez, and Manuel E Acacio, “Characterizing energy consumption in hardware transactional memory systems,” in 22nd Int’l. Symp. on Computer Architecture and High Performance Computing (SBAC-PAD’10), 2010, pp. 9–16. [12] Epifanio Gaona, Rub´en Titos-Gil, Manuel E. Acacio, and Juan Fern´andez, “Dynamic serialization: Improving energy consumption in eager-eager hardware transactional memory systems,” in 20th Euromicro Int’l. Conf. on Parallel, Distributed and Network-based Processing (PDP’12), 2012, pp. 221–228. [13] Tali Moreshet, R Iris Bahar, and Maurice Herlihy, “Energy-aware microprocessor synchronization: Transactional memory vs. locks,” Fourth Annual Boston-Area Architecture Workshop, p. 21, 2006. [14] Alexandro Baldassin, Felipe Klein, Guido Araujo, Rodolgo Azevedo, and Paulo Centoducatte, “Characterizing the energy consumption of software transactional memory,” IEEE Computer Architecture Letters, vol. 8, no. 2, pp. 56–59, Feb 2009. [15] Alexandro Baldassin, Joao P.L. de Carvalho, Leonardo A.G. Garcia, and Rodolfo Azevedo, “Energyperformance tradeoffs in software transactional memory,” in 24th Int’l. Symp. on Computer Architecture and High Performance Computing (SBAC-PAD’12), 2012, pp. 147–154. [16] Felipe Klein, Alexandro Baldassin, Guido Araujo, Paulo Centoducatte, and Rodolfo Azevedo, “On the energyefficiency of software transactional memory,” in 22nd Ann. Symp. on Integrated Circuits and System Design: Chip on the Dunes (SBCCI’09), 2009, pp. 33:1–33:6. [17] Sutirtha Sanyal, Sourav Roy, Adrian Cristal, Osmand S. Unsal, and Mateo Valero, “Clock gate on abort: Towards energy-efficient hardware transactional memory,” in IEEE Int’l. Symp. on Parallel Distributed Processing (IPDPS’09), 2009, pp. 1–8. [18] “ODROID — Hardkernel,” http://www.hardkernel. com/main/products/prdt_info.php?g_code= G140448267127. [19] Chi Cao Minh, Jaewoong Chung, Christoph Kozyrakis, and Kunle Olukotun, “STAMP: Stanford transactional applications for multi-processing,” in IEEE Int’l. Symp. on Workload Characterization (IISWC’08), 2008, pp. 35–46. [20] Wenjia Ruan, Yujie Liu, and Michael Spear, “STAMP need not be considered harmful,” in 9th ACM SIGPLAN Workshop on Transactional Computing (TRANSACT’14), 2014, pp. 1–7. [21] 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.