Modelo de estimación de speedup factor mediante umbralización en multicores asimétricos

Transcripción

1 Modelo de estimación de speedup factor mediante umbralización en multicores asimétricos Reporte Técnico Adrian Pousa 1 Juan Carlos Saez 1 Instituto de Investigación en Informática LIDI Argentina. Facultad de Informática Universidad Complutense de Madrid España.

2 Introducción Los procesadores multicore asimetricos AMPs (Asymmetric Multicore Processors) han sido propuestos como alternativa de bajo consumo a los procesadores multicores simétricos convencionales. Los AMPs combinan cores rápidos y complejos, de elevado consumo, con cores lentos y simples de consumo reducido. En este reporte utilizamos la arquitectura asimétrica de Intel QuickIA. Esta arquitectura esta compuesta por un procesador Xeon X55 y un procesador Atom N33, ambos con dos cores cada uno proporcionando una arquitectura asimétrica F-S dos cores rapidos (Xeon) y dos cores lentos (Atom). Dentro del sistema operativo, el planificador debe mapear a los cores rápidos aquellas aplicaciones que obtienen un mayor beneficio al ejecutarse en los cores rápidos con respecto a ejecutar en cores lentos. Nos referiremos a este beneficio como speedup de la aplicación en el AMP. El speedup de una aplicación secuencial sobre AMP se conoce también como speedup factor y se define como: SF= IPS fast IPS slow Donde IPS son las tasas de instrucciones por segundo alcanzados en el core rápido (IPS fast ) y en el core lento(ips slow ). Se ha demostrado que los planificadores que se basan en modelos de estimación de SF obtienen SFs mas precisos e introducen menor sobrecarga que las estrategias que requieren el muestreo del IPS en ambos tipos de cores. Nuestro objetivo es obtener un modelo de estimación para que el planificador pueda aproximar el SF de una aplicación secuencial utilizando los contadores hardware del procesador del core donde la aplicación se está ejecutando. Trabajos previos en el área han intentado estimar el SF buscando correlaciones entre el SF y otras métricas de rendimiento que se pueden obtener mediante los contadores hardware del procesador. Obtener un modelo para QuickIA no resulta sencillo porque no existe una correlación clara entre el SF y otras métricas. Para diseñar el modelo de estimación en este escenario complejo, exploramos distintas técnicas de minería de datos usando la herramienta WEKA. WEKA proporciona numerosos métodos para inferir relaciones entre un conjunto de observaciones (o atributos de entrada) y una variable objetivo. En el problema de estimación de SFs, las observaciones se corresponden con distintos parámetros de rendimiento y la variable objetivo es el SF. Entre los métodos explorados, detectamos que la regresión aditiva permite derivar un modelo de estimación preciso para esta plataforma. Para simplificar el volumen de datos proporcionados a WEKA fue necesario la detección de fases SF durante la ejecución de una aplicación, es decir, detectar fases de ejecución de una aplicación sobre un determinado tipo de core donde el SF se mantiene constante o en valores próximos. El proceso de generación del modelo se puede resumir en 5 pasos que a continuación se detallan.

3 Paso 1: Selección de aplicaciones y métricas de rendimiento El primer paso para la generación del modelo es seleccionar las aplicaciones secuenciales y las métricas de rendimiento que van a ser tenidas en cuenta para estas aplicaciones. Las aplicaciones secuenciales utilizadas pertenecen a la suite de benchmarks SPECCPU y nos referiremos al conjunto de estas aplicaciones como APPS. Paso : Ejecución de aplicaciones y obtención de métricas El segundo paso consiste en ejecutar de a una las aplicaciones en cada tipo de core y obtener los valores de las métricas de rendimiento durante su ejecución. Por lo tanto, se toma una aplicación A de APPS, luego se ejecuta A en un tipo de core (por ejemplo el core rápido), durante su ejecución se van obteniendo mediante los contadores hardware las medidas de rendimiento en ese tipo de core, terminada la ejecución se procede de la misma manera en el otro tipo de core (el core lento). Es importante destacar, que la cantidad de métricas utilizadas exceden el número de contadores hardware de los procesadores de la arquitectura, por lo tanto es necesario ejecutar mas de una vez la aplicación en el mismo tipo de core para obtener la totalidad de las medidas de rendimiento. Paso 3: Detección de fases de SF de ejecución El tercer paso parte del SF obtenido de la ejecución de cada aplicación A. Si consideramos el SF de A a lo largo del tiempo este puede verse como una señal. SF obtenido de la ejecución del benchmark MCF SF Tiempo La idea de este paso es detectar en una aplicación A fases de ejecución en las cuales el SF se mantiene constante o bien no ha cambiado en forma significativa. Para esto hemos aplicado una técnica de umbralización que describimos a continuación. Para cada aplicación A en APPS se toma el mínimo y el máximo SF alcanzado, de esto se obtiene

4 un segmento definido como S(A) = SFmax(A) SFmin(A): SF Luego se consideran U umbrales (U>=) de manera de dividir el segmento en U-1 partes iguales, que llamaremos subsegmentos, cada uno de tamaño p = S(A) / (U-1). Cada subsegmento estará comprendido entre dos umbrales, el primer subsegmento estará comprendido entre los umbrales SFmin y SFmin+p, el segundo subsegmento lo estará entre SFmin+p y SFmin+p, el tercero entre SFmin+p y SFmin +3p; y así siguiendo hasta el último segmento que estará comprendido entre SFmin+(U-1)p y SFmax. En la siguiente figura mostramos el segmento dividido considerando U= Tiempo S(A) S(A) Una vez determinados los umbrales, a cada valor de SF se le da el valor del umbral mas cercano, es

5 decir dado un valor de speedup factor x en un instante de tiempo t, SF(t) = x, comprendido entre los umbrales a y a+p, a <= x <= a+p, entonces: SF(t) = a SF(t) = a+p ; si x esta mas próximo de a que de a+p ; si x esta mas próximo de a+p que de a Un ejemplo de como quedaría la detección de fases sería: Como puede observarse la técnica aproxima las fases lo suficientemente bien aunque pueden percibirse picos dados por fases de una longitud muy corta. Por lo tanto, aquellos valores que pertenecen a fases de una longitud menor a una ventada V dada no se consideran.

6 Paso : Fases de métricas a partir de las fases de SF Una vez obtenidas las fases de ejecución de SF para cada benchmark se procede al cuarto paso, en el cual se calculan las medias geométricas de los valores de SF comprendidos en cada fase. Para el modelo no solo se calculan las medias geométricas de los valores de SF por fase, sino también las medias geométricas de los valores de las distintas métricas por cada fase. Se utilizó la media geométrica dado que permite minimizar el impacto de los picos. Paso 5: Generación del modelo en WEKA En la busqueda de metodologías sistemáticas para diseñar modelos de estimación en escenarios complejos, como el que se estudia en este trabajo, exploramos distintas técnicas de minería de datos usando la herramienta WEKA. WEKA proporciona numerosos métodos para inferir relaciones entre un conjunto de observaciones (o atributos de entrada) y una variable objetivo. En el problema de estimación de SFs, las observaciones se corresponden con distintos parámetros de rendimiento y la variable objetivo es el SF. Entre los métodos explorados, detectamos que la regresión aditiva permite derivar un modelo de estimación relativamente preciso para esta plataforma. WEKA genera dos modelos de estimación de SF basados en regresión aditiva: uno para estimar el SF desde el core rápido y otro desde el core lento. Es importante destacar que, al generar los modelos, WEKA descarta automáticamente aquellas métricas menos relevantes para el modelo. Precisión del modelo La siguiente figura muestra la comparación entre el SF observado y el estimado en ambos tipos de cores para un subconjunto de aplicaciones de SPEC CPU en el Intel QuickIA:

7 Los modelos generados requieren que el planificador monitorice las siguientes métricas en tiempo de ejecución: instrucciones por ciclo, fallos y accesos al último nivel de cache por cada 1K instrucciones, fallos de predicción de saltos por cada 1K instrucciones y fallos de ITLB/DTLB por cada 1M instrucciones. Dado el escaso número de contadores hardware en la plataforma ha sido necesario recurrir a la multiplexación de eventos en la implementación.