Benchmarking OpenCL, OpenACC, OpenMP y CUDA: productividad de

programación, rendimiento y consumo de energía

Suejb Memeti 1 Lu Li 2 Sabri Pllana 3 Joanna Kolodziej 4 Christoph Kessler 5

Preimpresión

Resumen

Muchos sistemas de computación paralela modernos son heterogéneos en su nivel de nodo. Dichos nodos pueden
comprender CPU y aceleradores de uso general (como GPU o Intel Xeon Phi) que proporcionan un alto rendimiento con
características adecuadas de consumo de energía. Sin embargo, aprovechar el rendimiento disponible de arquitecturas
heterogéneas puede ser un desafío. Hay varios marcos de programación paralelos (como OpenMP, OpenCL, OpenACC,
CUDA) y seleccionar el que es adecuado para un contexto de destino no es sencillo. En este artículo, estudiamos
empíricamente las características de OpenMP, OpenACC, OpenCL y CUDA con respecto a la productividad, el rendimiento
arXiv: 1704.05316v1 [cs.DC] 18 de abril de 2017

y la energía de la programación. Para evaluar la productividad de la programación utilizamos nuestra herramienta propia
CodeStat, lo que nos permite determinar el porcentaje de líneas de código que se requirió para paralelizar el código
utilizando un marco específico. Utilizamos nuestra herramienta x-MeterPU para evaluar el consumo de energía y el
rendimiento. Los experimentos se llevan a cabo utilizando el paquete de pruebas SPEC estándar de la industria y el paquete
de pruebas Rodinia para la computación acelerada en sistemas heterogéneos que combinan los procesadores Intel Xeon E5
con un acelerador de GPU o un coprocesador Intel Xeon Phi.

1. Introducción

Los sistemas informáticos en paralelo modernos pueden comprender procesadores de varios núcleos y de varios núcleos en su nivel de nodo. Los

procesadores de varios núcleos pueden tener dos o más núcleos y, por lo general, se ejecutan a una frecuencia más alta que los procesadores de muchos

núcleos. Si bien los procesadores de múltiples núcleos son adecuados para tareas de propósito general, los procesadores de muchos núcleos (como Intel

Xeon Phi [4] o GPU [12]) comprenden un mayor número de núcleos de frecuencia más baja que funcionan bien en tareas específicas.

Debido a sus diferentes características, los ingenieros a menudo combinan procesadores de varios núcleos y de muchos núcleos para
crear los denominados nodos heterogéneos que pueden, si se utilizan con cuidado, dar como resultado un alto rendimiento y eficiencia
energética. Yan y col. [20] destacan la importancia de la ejecución eficiente a nivel de nodo de programas paralelos también para los
futuros sistemas informáticos a gran escala [1]. Sin embargo, utilizar los recursos disponibles de estos sistemas en la mayor medida posible
requiere un conocimiento avanzado de arquitecturas de computación paralela y marcos de programación muy diferentes [18, 9].

Algunos de los marcos de programación paralelos ampliamente utilizados para sistemas heterogéneos incluyen OpenACC
[19], OpenCL [16], OpenMP [13] y NVIDIA CUDA [11]. El desafío para el

1 Universidad de Linnaeus, 351 95 Växj¨

ö, Suecia, suejb.memeti@lnu.se
2 Universidad de Linköping, 581 83 Link¨
öping, Suecia, lu.li@liu.se
3 Universidad de Linnaeus, 351 95 Växj¨
ö, Suecia, sabri.pllana@lnu.se
4 Red informática académica y de investigación (NASK), 01045 Varsovia, Polonia, jokolodziej@pk.edu.pl

5 Universidad de Linköping, 581 83 Link¨

öping, Suecia, christoph.kessler@liu.se

1
Figura 1: Una descripción general de nuestra infraestructura para la evaluación de lenguajes de programación paralelos para sistemas acelerados.

El desarrollador del programa debe elegir uno de los muchos marcos de programación paralela disponibles que cumpla en el contexto
específico los objetivos con respecto a la productividad, el rendimiento y el consumo de energía de la programación. El trabajo existente
ha estudiado sistemáticamente la literatura sobre sistemas acelerados por GPU [10], comparado la productividad de programación de
OpenACC y CUDA usando un grupo de estudiantes para paralelizar códigos secuenciales [7], o kernels usados para comparar el
tiempo de ejecución de implementaciones basadas en OpenCL y CUDA.

En este documento, comparamos cuatro marcos de programación bien conocidos para sistemas heterogéneos: OpenMP,
OpenACC, OpenCL y CUDA. Además de la suite de referencia estándar de la industria SPEC Accel [5], utilizamos la popular
suite de referencia Rodinia [3] para evaluar la productividad de la programación, la eficiencia energética y el rendimiento.
Usamos nuestra herramienta desarrollada para este estudio CodeStat cuantificar el esfuerzo de programación para paralelizar
las suites de referencia en estudio. Además, desarrollamos x-MeterPU es una extensión de MeterPU, que nos permite medir el
rendimiento y el consumo de energía en sistemas que se aceleran con Intel Xeon Phi y GPU. Presentamos y discutimos los
resultados obtenidos en dos sistemas informáticos heterogéneos: Emil que comprende dos procesadores Intel Xeon Phi E5 y un
coprocesador Intel Xeon Phi, y Ida que tiene dos procesadores Intel Xeon Phi E5 y una GPU GTX Titan X.

El resto del artículo se estructura de la siguiente manera. La Sección 2 describe nuestro enfoque, herramientas e infraestructura para
programas de evaluación comparativa desarrollados con OpenMP, OpenCL, OpenACC y CUDA. Los resultados de la evaluación experimental
utilizando los conjuntos de pruebas comparativas SPEC y Rodinia se describen en la Sección 3. La Sección 4 analiza el trabajo relacionado.
Concluimos el artículo en la Sección
5.

2 Nuestra metodología y herramientas

En esta sección, describimos nuestro enfoque y las herramientas que hemos desarrollado para comparar marcos paralelos para
sistemas heterogéneos. Nuestro enfoque se basa en el uso de paquetes de referencia estándar de la industria para evaluar el
esfuerzo de paralelización, el rendimiento y el consumo de energía. La Figura 1 muestra nuestra infraestructura para la evaluación de
lenguajes de programación paralelos para sistemas acelerados que incluye herramientas de medición CodeStat y x-MeterPU,
conjuntos de pruebas de referencia Rodinia y SPEC Accel, y sistemas heterogéneos Ida y Emil.

2
 Tabla 1: Características principales de OpenACC, OpenMP, OpenCL y CUDA.

OpenACC OpenMP OpenCL CUDA

- datos paral- - datos paral- - datos paral- - datos paral-

lelismo lelismo lelismo lelismo
Paralelismo - asincrónico - asincrónico - asincrónico - asincrónico
paralelismo de tareas paralelismo de tareas paralelismo de tareas paralelismo de tareas

- solo dispositivo - host y dispositivo - host y dispositivo - solo dispositivo

- jerarquía de memoria

- jerarquía de memoria- archy - datos y - jerarquía de memoria- - jerarquía de memoria-

chy computación chy chy

Arquitectura
- datos explícitos vinculante - datos explícitos - datos explícitos
abstracción
cartografía y - explícito datos cartografía y cartografía y
movimiento cartografía y movimiento movimiento
movimiento
Sincronización - barrera
- reducción - barrera;
- reducción - barrera
- unirse - reducción
zation - unirse

Marco im- Directivas del compilador Directivas del compilador Extensión C / C ++ Extensión C / C ++
plementación para C / C ++ y para C / C ++ y Fortran
Fortran

La Tabla 1 resume las principales características de los lenguajes paralelos que se consideran en nuestro estudio: OpenMP [13],
OpenACC [19], OpenCL [16] y CUDA [11]. OpenMP y OpenACC se implementan en gran medida como directivas del compilador para
C, C ++ y FORTRAN, que ocultan significativamente los detalles de la arquitectura del programador. OpenCL y CUDA se implementan
como bibliotecas de software para C y C ++ y exponen al programador a detalles arquitectónicos de bajo nivel. Con respecto al
soporte del paralelismo, todos los marcos considerados admiten el paralelismo de datos y el paralelismo de tareas asincrónicas.
Mientras que OpenMP y OpenCL proporcionan patrones de paralelización tanto para CPU host de múltiples núcleos como para
dispositivos acelerados de muchos núcleos, OpenACC y CUDA admiten medios de paralelización solo para aceleradores como las
GPU NVIDIA [20].

2.1 CodeStat: una herramienta para cuantificar el esfuerzo de paralelización

Para cuantificar el esfuerzo de programación requerido para paralelizar un código, hemos desarrollado nuestra herramienta, llamada CodeStat.
CodeStat toma como entrada un archivo de configuración y el código fuente. El archivo de configuración contiene una lista de extensiones de
archivo válidas (como,. c, .cpp, .cu, .cl, ...), y una lista de llamadas a métodos específicos del marco, o directivas del compilador (como, # pragma
omp, proc bind, o
omp set num hilos en OpenMP).
CodeStat analiza el código buscando sentencias de código específicas del marco proporcionadas en el archivo de
configuración y proporciona como salida el número total de líneas de código (LOC) y el número de LOC escritas en OpenMP,
OpenCL, OpenACC o CUDA.
Los archivos de configuración para OpenMP, OpenCL, OpenACC y CUDA son proporcionados por CodeStat. Se pueden admitir
otros marcos de programación simplemente creando un nuevo archivo de configuración y agregando las instrucciones de código
específicas del marco a la lista. La lista de declaraciones para un lenguaje de programación dado generalmente se proporciona en la
documentación correspondiente o guías de referencia.

3
2.2 x-MeterPU: una herramienta para medir el rendimiento y el consumo de energía

Para medir el tiempo de ejecución y el consumo de energía de los sistemas acelerados por GPU utilizamos MeterPU [8]. MeterPU es
un paquete de software C ++ que implementa su API de medición genérica pero simple. MeterPU permite medir fácilmente diferentes
métricas (por ejemplo, tiempo, energía) en diferentes componentes de hardware (por ejemplo, CPU, DRAM, GPU). Utilizando la
plantilla y las características de metaprogramación de C ++, la sobrecarga de MeterPU es bastante baja e imperceptible. Permite
modelar y ajustar fácilmente la energía, además de que también permite una transición suave para el software de ajuste heredado (por
ejemplo, SkePU [8]) de optimización de tiempo a optimización de energía si algunas suposiciones utilizadas para el modelado de
tiempo no se violan para el modelado de energía.

Para medir el tiempo de ejecución y el consumo de energía del Intel Xeon Phi, hemos desarrollado nuestra herramienta,
denominada x-MeterPU. x-MeterPU admite mediciones de energía tanto para modelos de programación nativos como para modelos
originales de Intel Xeon Phi. Es capaz de detectar automáticamente el entorno de ejecución, por lo que se utiliza una única función de
API para las mediciones de aplicaciones nativas y fuera de servicio. Para medir la energía de aplicaciones basadas en fuera de
servicio, utilizamos el micsmc utilidad, mientras que micras La herramienta se utiliza para medir la energía de las aplicaciones nativas.

De manera similar a MeterPU, el uso de x-MeterPU es muy simple. los comienzo() y detener() Los métodos se utilizan para encerrar las
regiones de código que se van a medir. los obtener valor () La función se utiliza para recuperar el consumo de energía (en Jules). Además del
consumo total de energía, x-MeterPU devuelve un archivo de registro que contiene todos los datos de energía con marcas de tiempo exactas, lo
que permite la producción de varios gráficos.

3 Evaluación

En esta sección, evaluamos experimentalmente los marcos de programación paralelos seleccionados utilizando varias
aplicaciones y arquitecturas de referencia. Describimos:

• el entorno de experimentación, incluida la configuración de hardware, aplicaciones de referencia y métricas de

evaluación;

• los resultados de la comparación de OpenMP, OpenACC, OpenCL y CUDA con respecto a la productividad de la
programación, el rendimiento y el consumo de energía.

3.1 Entorno de experimentación

En esta sección, describimos el entorno de experimentación utilizado para evaluar los marcos de programación paralela
seleccionados en sistemas heterogéneos. Describimos la configuración del hardware, las aplicaciones de referencia
consideradas y las métricas de evaluación.

3.1.1 Configuración de hardware

Para la evaluación experimental de los marcos de programación paralelos seleccionados, utilizamos dos sistemas heterogéneos de un
solo nodo.
Emil es un sistema heterogéneo que consta de dos CPU de propósito general Intel Xeon E5-2695 v2 en el host y un dispositivo de
coprocesamiento Intel Xeon Phi 7120P. En total, el host está compuesto por 24 núcleos, cada CPU tiene 12 núcleos que admiten dos
subprocesos por núcleo (conocidos como núcleos lógicos) lo que equivale a un total de 48 subprocesos. El dispositivo Xeon Phi tiene 61
núcleos que funcionan a una frecuencia base de 1,2 GHz, cuatro subprocesos de hardware por núcleo, lo que equivale a un total de 244

4
 Tabla 2: Los detalles de configuración del sistema para Emil y Ida.

Ida Emil

Especificaciones Intel Xeon E5 GPU GeForce Intel Xeon E5 Intel Xeon Phi

Escribe E5-2650 v4 GTX Titan X E5-2695 v2 7120P

Frecuencia central 2,2 - 2,9 GHz 1 - 1,1 GHz 2,4 - 3,2 GHz 1,2 - 1,3 GHz
# de núcleos 12 3072 12 61
# de los hilos 24 / 24 244
Cache 30 MB / 30 MB 30,5 MB
Mem. Banda- 76,8 GB / s 336,5 GB / s 59,7 GB / s 352 GB / s
ancho
Memoria 384 GB 12 GB 128 GB 16 GB
TDP 105 W 250 W 115 W 300 W

hilos. Uno de los núcleos lo utiliza el sistema operativo Linux ligero instalado en el dispositivo.

Ida es un sistema heterogéneo que consta de dos CPU de propósito general Intel Xeon E5-2650 v4 en el host y una GPU
GeForce GTX Titan X. Similar a Emil, Ida tiene 24 núcleos y 48 subprocesos en el host, mientras que el dispositivo GPU tiene 24
multiprocesadores de transmisión (SM) y en total 3072 núcleos CUDA que funcionan a una frecuencia base de 1 GHz. Las
principales características de Emil y
Ida se enumeran en la tabla 2.

3.1.2 Aplicaciones de referencia

En este artículo hemos considerado una serie de aplicaciones diferentes de las suites de referencia SPEC Accel y Rodinia. El
paquete de pruebas Accel Standard Performance Evaluation Corporation (SPEC) se centra en el rendimiento de aplicaciones
informáticas en paralelo intensivas que utilizan sistemas acelerados. Proporciona una serie de aplicaciones para OpenCL y
OpenACC. De manera similar, la suite de pruebas de Rodinia proporciona varias aplicaciones diferentes para OpenMP,
OpenCL y CUDA.

Si bien SPEC Accel proporciona un total de 19 aplicaciones OpenCL y 15 OpenACC, hemos seleccionado solo 14
aplicaciones OpenCL y 3 OpenACC, mientras que Rodinia ofrece 25 aplicaciones; sin embargo, hemos seleccionado solo 19 de
ellas para utilizarlas en la experimentación (ver tabla 3). Los criterios de inclusión durante el proceso de selección de aplicaciones
son: (1) la necesidad de tener al menos dos implementaciones de la misma aplicación en diferentes frameworks de programación,
o suites de referencia, y (2) aplicaciones que sean compilables en nuestros sistemas. Para comparar el rendimiento de los marcos
de programación paralelos seleccionados, hemos utilizado las siguientes aplicaciones de referencia de la suite de referencia
SPEC Accel y Rodinia:

• Método Lattice-Boltzmann (LBM) - es un solucionador de ecuaciones diferenciales parciales (PDE) en dinámica de fluidos.
El punto de referencia SPEC Accel proporciona la implementación OpenCL y OpenACC de esta aplicación.

• MRI-Q - es una aplicación que se utiliza para la construcción de resonancias magnéticas en medicina. Las implementaciones OpenCL y
OpenACC de esta aplicación son proporcionadas por SPEC Accel benchmark.

• Plantilla 3D - un código de plantilla que representa el solucionador de PDE iterativo de Jacobi en termodinámica. Esta
aplicación se implementa utilizando OpenCL y OpenACC como parte del benchmark SPEC, y la implementación CUDA
como parte del Rodinia Benchmark. Desafortunadamente, no existe una implementación de OpenMP.

5
 • Amplitud-primera-búsqueda (BFS) - es un problema de recorrido de grafos, que se usa comúnmente para encontrar la ruta
más corta entre dos nodos.

• Solucionador de dinámica de fluidos computacional (CFD) - un solucionador de las ecuaciones de Euler tridimensionales utilizadas en la
dinámica de fluidos.

• HotSpot - es una aplicación conocida en simulación física para la estimación térmica del procesador basada en la
arquitectura y las mediciones de potencia simuladas.

• Descomposición LU (LUD) - es una aplicación paralela para calcular un conjunto de ecuaciones lineales.

• Needleman-Wunsch (NW) - La aplicación se utiliza en bioinformática, que es un enfoque de optimización no lineal para
alineamientos de secuencias de ADN.

• Árbol B + - es una aplicación que atraviesa árboles B +. B + Tree representa datos ordenados que permiten la inserción y
eliminación eficientes de elementos del gráfico.

• Eliminación gaussiana (GE) - es un algoritmo de álgebra lineal densa que resuelve todas las variables en un sistema
lineal calculando el resultado fila por fila.

• Pared del corazón - es otra aplicación de imágenes médicas que se utiliza para rastrear el movimiento del corazón del ratón
sobre numerosas imágenes de ultrasonido.

• K significa - es una aplicación de minería de datos que se utiliza para la agrupación basada en dividir el grupo en
subgrupos y calcular los valores medios de cada subgrupo.

• LavaMD - es una aplicación de dinámica molecular que calcula el potencial y la reubicación de partículas dentro de un
gran espacio 3D.

• Disposición anisotrópica reductora de manchas (SRAD) - es un algoritmo de procesamiento de imágenes basado en PDE para
aplicaciones de diagnóstico por imágenes ultrasónicas y de radar.

• Propagación hacia atrás (BP) - es un algoritmo de aprendizaje automático que se utiliza durante el proceso de entrenamiento de
una red neuronal en capas.

• k-Vecino más cercano (k-NN) - es una aplicación de minería de datos que se utiliza para encontrar los k vecinos más cercanos de un
conjunto de datos no estructurados.

• Miocito - es una aplicación de simulación utilizada en medicina para modelar el miocito cardíaco (que es una célula del músculo
cardíaco) y simular su comportamiento.

• Filtro de partículas (PF) - es una aplicación de imágenes medial que se utiliza para rastrear leucocitos y células miocárdicas.
Sin embargo, este algoritmo se puede utilizar en diferentes dominios, incluida la videovigilancia y la compresión de video.

• Streamcluster (SC) - es una aplicación de minería de datos que se utiliza para la agrupación en línea de un flujo de entrada determinado.

BFS, CFD, HotSpot, LUD y NW se implementan mediante OpenCL OpenMP y CUDA. La implementación de OpenCL es
proporcionada por las suites de referencia SPEC Accel y Rodinia. SPEC Accel no proporciona ninguna implementación de
OpenACC para estas aplicaciones. B + Tree, GE, HW, Kmeans, LavaMD y SRAD se implementan utilizando OpenCL y CUDA.
Si bien la implementación de OpenCL la proporcionan ambos puntos de referencia, la implementación de CUDA la proporciona
Rodinia. Se implementan BP, k-NN, leucocitos, miocitos, PathFinder, PF y SC

6
Tabla 3: Las aplicaciones consideradas de las suites de referencia SPEC Accel y Rodinia.

SPEC Accel Rodinia

Solicitud Dominio OpenCL OpenACC OpenMP OpenCL CUDA

LBM Dinámica de fluidos X X

MRI-Q Medicamento X X
Plantilla Termodinámica X X
BFS Algoritmos de gráficos X X X X
CFD Dinámica de fluidos X X X X
HotSpot Simulación de física X X X X
LUD Álgebra lineal X X X X
noroeste Bioinformática X X X
B + Árbol Buscar X X X
GE Álgebra lineal X X X
Heartwall Imagenes medicas X X X
K significa Procesamiento de datos X X X
LavaMD Dinámica molecular X X X
SRAD Procesamiento de imágenes X X X
BP Reconocimiento de patrones X X
k-NN Procesamiento de datos X X
Miocito Simulación biológica X X
PF Imagenes medicas X X
CAROLINA DEL SUR Procesamiento de datos X X

utilizando OpenCL y CUDA, y sus implementaciones son proporcionadas por la suite de pruebas de Rodinia.

En las páginas web de documentación de SPEC Accel [15] y Rodinia [14] se encuentran disponibles información adicional y detalles
de implementación para cada una de las aplicaciones de referencia consideradas.

3.2 Métricas de evaluación

En esta sección, discutimos las métricas de evaluación consideradas para la comparación de los marcos de programación
paralela seleccionados, incluido el esfuerzo de programación requerido, el desempeño y la eficiencia energética.

3.2.1 Productividad de programación

Para evaluar cuantitativamente el esfuerzo de programación requerido para paralelizar un programa, usamos nuestra herramienta llamada CodeStat ( consulte
la Sección 2.1). Usamos CodeStat para determinar las líneas totales de código
LOC total y la fracción de líneas de código LOC par escrito en OpenCL, OpenACC, OpenMP o CUDA para una aplicación determinada.
Definimos el esfuerzo de paralelización de la siguiente manera,

Esfuerzo par [%] = 100 ∗ LOC par/ LOC total (1)

3.2.2 Rendimiento y consumo de energía

Usamos el tiempo de ejecución ( T) y la Energía ( MI) para expresar el rendimiento y el consumo de energía. T se define como la
cantidad total de tiempo que una aplicación necesita desde el inicio hasta el final de la ejecución, mientras que mi se define
como la cantidad total de energía consumida por el sistema (incluidas las CPU host y los aceleradores) desde el principio hasta
el final de la ejecución.

Los datos para el tiempo de ejecución y el consumo de energía se recopilan utilizando la herramienta xMeterPU (consulte la
Sección 2.2). Para recopilar dichos datos, se creó un archivo de clase contenedora. los

7
Tabla 4: El esfuerzo de programación necesario para paralelizar el código se expresa como una fracción de las líneas de código escritas
en OpenCL, OpenACC, OpenMP o CUDA. Las líneas de código restantes están escritas en C / C ++ de uso general.

SPEC Accel Rodinia

OpenCL [%] OpenACC [%] OpenMP [%] OpenCL [%] CUDA [%]

LBM 3,21 0,87

MRI-Q 5.70 0,64
Plantilla 4,70 0,61
BFS 6,95 4.86 9.07 12,50
CFD 5.83 2.53 9.00 8.08
HotSpot 4,75 2,67 13.18 8,20
LUD 5.78 2.30 9,72 7.82
noroeste 6.56 18.34 8,85
B + Árbol 4.89 6,79 4.51
GE 9,63 14.21 9,76
Heartwall 5.34 6,74 3,97
K significa 2,80 2,67 2.17
LavaMD 4.61 9.24 7.74
SRAD 7.81 13.00 10.28
BP 12.21 5,95
k-NN 15,83 5,07
Miocito 8.25 1,21
PF 17,83 9.47
CAROLINA DEL SUR 5,81 2,66

El flujo de control de esta clase es el siguiente: (1) iniciar los contadores de tiempo y energía; (2) ejecutar sincrónicamente los
comandos de referencia; y (3) detener los contadores de tiempo y energía y calcular el tiempo total de ejecución y el consumo de
energía del sistema.

3.3 Resultados

En esta sección, comparamos OpenMP, OpenACC, OpenCL y CUDA con respecto a (1) productividad de programación y (2)
rendimiento y consumo de energía.

3.3.1 Productividad de programación

La Tabla 4 muestra el esfuerzo de paralelización como porcentaje de líneas de código escritas en OpenCL, OpenACC, OpenMP o CUDA
que se utilizan para paralelizar varias aplicaciones de los conjuntos de pruebas de referencia Rodinia y SPEC Accel. Usamos la Ecuación
1 en la Sección 3.2.1 para calcular el porcentaje de líneas de código.

Resultado 1: Programar con OpenCL requiere mucho más esfuerzo que programar con OpenACC para el paquete de
pruebas SPEC Accel.
Basado en el código OpenCL y OpenACC disponible para LBM, MRI-Q, y Plantilla del paquete de pruebas SPEC Accel,
podemos observar que, en promedio, OpenACC requiere aproximadamente
6,7 × menos esfuerzo de programación en comparación con OpenCL.

Resultado 2: Programar con OpenCL en promedio requiere aproximadamente dos veces más esfuerzo que programar con
CUDA para la suite de referencia Rodinia.
Con respecto a la comparación entre OpenCL y CUDA usando las aplicaciones en la suite de pruebas de Rodinia, excepto
la implementación de BFS, en promedio CUDA requiere 2 ×
menos esfuerzo de programación que OpenCL.

8
 Resultado 3: programar con OpenMP requiere menos esfuerzo que programar con OpenCL y CUDA.

Según los datos recopilados para las implementaciones de OpenMP, OpenCL y CUDA de BFS, CFD, HotSpot, y LUD de la suite
de referencia Rodinia, podemos observar que, en promedio, OpenMP requiere 3.6 × menos esfuerzo de programación en comparación
con OpenCL, y alrededor de 3.1 × menos esfuerzo de programación en comparación con CUDA.

Resultado 4: el factor humano puede afectar la fracción de líneas de código utilizadas para paralelizar el código.
Por ejemplo, la implementación OpenCL de BFS en el paquete de pruebas SPEC Accel comprende un 6.95% de líneas de
código OpenCL, mientras que la implementación en Rodinia comprende
9.07% Líneas de código OpenCL. También se pueden observar diferencias en el esfuerzo de paralelización para
CFD, HotSpot, LUD, NW, B + Tree, GE, Heartwall, Kmeans, LavaMD, y SRAD.

3.3.2 Rendimiento y energía

Las Figuras 2, 3, 4 y 5 muestran los tiempos de ejecución y el consumo de energía para varias aplicaciones de las suites de
referencia SPEC Accel y Rodinia en Emil e Ida.
Resultado 5: El rendimiento y el comportamiento del consumo de energía de OpenCL y CUDA dependen de la aplicación.
Para el conjunto de pruebas de Rodinia, para algunas aplicaciones, OpenCL funciona mejor, sin embargo, hay varias aplicaciones
en las que CUDA funciona mejor.
La Figura 2 muestra el tiempo de ejecución y el consumo de energía de las implementaciones OpenCL y CUDA de NW, B +
Tree, GE, Heartwall, Kmeans, LavaMD, SRAD, BP, k-NN, Myocyte, PF, y CAROLINA DEL SUR del conjunto de pruebas de Rodinia
en el sistema acelerado por GPU Ida. Los resultados muestran que la implementación de OpenCL de siete de las 12 aplicaciones,
incluidas NO, GE, LavaMD, SRAD, BP, k-NN, y CAROLINA DEL SUR funcionan mejor que sus correspondientes implementaciones
CUDA.

Mientras que para la mayoría de las aplicaciones, incluidas Árbol B +, GE, SRAD, BP, k-NN, Miocito,
y CAROLINA DEL SUR, el rendimiento de OpenCL y CUDA es comparable, para algunas aplicaciones como
noroeste y LavaMD hay una gran diferencia de rendimiento donde OpenCL funciona mejor que CUDA, mientras que para Heartwall,
K significa, y PF las implementaciones de CUDA funcionan mejor que sus contrapartes de OpenCL.

Resultado 6: La implementación de OpenMP de CFD, HotSpot y LUD ejecutada en Emil, funciona significativamente más
lento que la implementación de OpenCL y CUDA correspondiente ejecutada en Ida.
La Figura 3 muestra la comparación de OpenMP, OpenCL y CUDA con respecto al tiempo de ejecución y el consumo de
energía utilizando la suite de referencia Rodinia. La figura 3a muestra el tiempo de ejecución de CFD, HotSpot, y LUD aplicaciones.
La implementación OpenMP de estas aplicaciones se ejecuta en el sistema acelerado Intel Xeon Phi Emil, mientras que las
versiones OpenCL y CUDA se ejecutan en el sistema acelerado por GPU Ida. Podemos observar que los tiempos de ejecución
de las versiones OpenCL y CUDA son comparables, mientras que la implementación de OpenMP es significativamente más
lenta. Tenga en cuenta que las CPU host de Emil son Intel Xeon E5-2695 v2, mientras que las CPU host de Ida son del tipo
E5-2650 v4. Además, el coprocesador Intel Xeon Phi 7120P en Emil es la primera generación de la arquitectura Intel Xeon Phi
(conocida como Knights Corner).

Resultado 7: OpenMP, OpenCL y CUDA tienen un rendimiento y un consumo de energía comparables en Ida.

La Figura 4 muestra la comparación de OpenMP, OpenCL y CUDA con respecto al tiempo de ejecución y el consumo de
energía utilizando el BFS de la suite de referencia Rodinia. Podemos observar un rendimiento comparable, donde OpenCL es un
poco más rápido que OpenMP, que es un poco más rápido que CUDA. De acuerdo con los resultados mostrados en la Tabla 4, la
versión de OpenMP requiere que se escriba la fracción más pequeña de líneas de código (4.86%), mientras que OpenCL
requiere

9
 1,2 2,5 25 21,98 3,5
3,02
0,99 2,05
1 3
2 1,74 20
15,90 2,5
0,8
1,5 15 2
Hora [s]

Hora [s]

Hora [s]

Hora [s]
0,6 0,52
1,5 1,24
1 10
0,4
1
0,5 5
0,2 0,5

0 0 0 0
OpenCL CUDA OpenCL CUDA OpenCL CUDA OpenCL CUDA

noroeste B + Árbol GE Heartwall

25 60 52,57 45 0,25 0,22

21,25 37,51 38,53
40 0,20
50
20 35 0,2

40 30
15 0,15
25
Hora [s]

Hora [s]

Hora [s]

Hora [s]
30
20
10 0,1
20 15

5 3,36 10 0,05
10 5,55
5
0 0 0 0
OpenCL CUDA OpenCL CUDA OpenCL CUDA OpenCL CUDA

K significa LavaMD SRAD BP

0,25 0,8 dieciséis 14,63 6 5,31

0,21 0,68
0,19 0,7 14
0,57 5
0,2 4,19
0,6 12
4
0,15 0,5 10 8,41
Hora [s]

Hora [s]

Hora [s]

Hora [s]
0,4 8 3
0,1 0,3 6
2
0,2 4
0,05
1
0,1 2
0 0 0 0
OpenCL CUDA OpenCL CUDA OpenCL CUDA OpenCL CUDA

k-NN Miocito PF CAROLINA DEL SUR

(un momento

UPC GPU 285,64

300 600 5000 4404,54 800 682,07
494,22
700
250 500 4000
189,10 3237,24 600
363,42
200 400
3000 500
338,37
Energía [J]

150 300 400

Energía [J]

Energía [J]

Energía [J]
2000 300
100 200
200
50 100 1000
100
0 0 0 0
OpenCL CUDA OpenCL CUDA OpenCL CUDA OpenCL CUDA

noroeste B + Árbol GE Heartwall

3797,87 9172,48 12500,27 112,60

4000 10000 14000 11633,67 120 105,29
3500 12000
8000 100
3000 10000
80
2500 6000 8000
2000 60
Energía [J]

Energía [J]
Energía [J]

Energía [J]

4000 6000
1500
40
643,51 1423,39 4000
1000
2000 20
500 2000
0 0 0 0
OpenCL CUDA OpenCL CUDA OpenCL CUDA OpenCL CUDA

K significa LavaMD SRAD BP

1136,80
140 120,16 250 3500 2931,40 1200
114,98 196,32
120 188,16 3000 916,95
200 1000
100 2500
1776,23 800
80 150 2000
Energía [J]

600
Energía [J]

Energía [J]
Energía [J]

60 100 1500
400
40 1000
50 200
20 500
0 0 0 0
OpenCL CUDA OpenCL CUDA OpenCL CUDA OpenCL CUDA

k-NN Miocito PF CAROLINA DEL SUR

(b) Consumo de energía

Figura 2: Una comparación de OpenCL y CUDA con respecto a (a) tiempo de ejecución y (b) consumo de energía. Los
resultados se obtienen para varias aplicaciones del conjunto de pruebas de Rodinia (Tabla 3) en el sistema acelerado por GPU Ida
( Tabla 2).

10
 7000
30 UPC Acelerador 5793,48
24,56 6000
25
5000 4324,71
18,20
20
3369,18

Energía [J]
4000
Hora [s]

15
3000
1749,981494,59
10 6,46 2000
4,86 4,16
3,44 3,73 3,53 3,71 761,59 818,01 1137,77 666,34
5 1000

0 0

OCL-Ida

OCL-Ida

OCL-Ida
OMP-Emil

CUDA-Ida

OMP-Emil

CUDA-Ida

OMP-Emil

CUDA-Ida
OCL-Ida

OCL-Ida

OCL-Ida
OMP-Emil

CUDA-Ida

OMP-Emil

CUDA-Ida

OMP-Emil

CUDA-Ida
CFD Hotspot LUD CFD Hotspot LUD

(un momento (b) Consumo de energía

Figura 3: Una comparación de OpenMP, OpenCL y CUDA con respecto a (a) el tiempo de ejecución y (b) el consumo de
energía utilizando la suite de referencia Rodinia (Tabla 3). La versión OpenMP (OMP) de CFD, HotSpot, LUD se ejecuta en el
sistema acelerado Intel Xeon Phi Emil ( Tabla 2); mientras que las versiones OpenCL (OCL) y CUDA de CFD, HotSpot, LUD se
ejecutan en el sistema acelerado por GPU Ida.

1,8 UPC GPU

1,58 1,59 400
1,51 342,48
1,6 333,90 328,02
350
1,4
300
1,2

1 250
Hora [s]

Energía [J]

0,8 200

0,6 150

0,4
100
0,2
50
0
OpenMP OpenCL CUDA 0
OpenMP OpenCL CUDA
BFS
BFS

(un momento (b) Consumo de energía

Figura 4: Una comparación de OpenMP, OpenCL y CUDA con respecto a (a) el tiempo de ejecución y (b) el consumo de
energía usando la aplicación BFS de la suite de pruebas de Rodinia (Tabla
3) en Ida.

11
 80000
250 224,79 UPC GPU
70000

200
60000

150 50000

Energía [J]
Hora [s]

40000
100 82,40
30000

50 32,29 31,61 20000

15,67 11,12
10000
0
OpenCL OpenACC OpenCL OpenACC OpenCL OpenACC 0
OpenCL OpenACC OpenCL OpenACC OpenCL OpenACC
LBM MRI-Q Plantilla
LBM MRI-Q Plantilla

(un momento (b) Consumo de energía

Figura 5: Una comparación de OpenCL y OpenACC con respecto a (a) tiempo de ejecución y (b) consumo de energía. Los
resultados se obtienen utilizando LBM, MRI-Q y Stencil del paquete de pruebas SPEC Accel (Tabla 3) en el sistema acelerado
por GPU Ida ( Tabla 2).

9.07% y CUDA 12.5% de las líneas de código específicas del marco correspondiente.
Resultado 8: OpenCL funciona mejor que OpenACC para el paquete de pruebas SPEC Accel en Ida.
La Figura 5 muestra la comparación de OpenCL y OpenACC con respecto al tiempo de ejecución y el consumo de energía
utilizando el LBM, MRI-Q, y Plantilla del paquete de pruebas SPEC Accel en el sistema acelerado por GPU Ida. Podemos observar
que la implementación de OpenCL de LBM y MRI-Q es significativamente más rápida que la implementación de OpenACC
correspondiente, mientras que para la implementación de Stencil los resultados son comparables. Sin embargo, de acuerdo con los
resultados mostrados en la Tabla 4, la escritura de código para OpenCL exige un esfuerzo significativamente mayor que la escritura de
código OpenACC.

4 Trabajo relacionado

En esta sección, destacamos ejemplos de investigación que aborda aspectos de programación de sistemas informáticos
heterogéneos y posicionamos este artículo con respecto al trabajo relacionado.
Su et al. [17] compare el rendimiento de OpenCL y CUDA utilizando cinco núcleos: filtro de Sobel, filtro de Gauss, filtro de
mediana, estimación de movimiento y estimación de disparidad. El tiempo de ejecución de las implementaciones basadas en CUDA
fue 3.8% - 5.4% más rápido que las implementaciones basadas en OpenCL.

Kessler y col. [6] estudian tres enfoques para la capacidad de programación y la portabilidad del rendimiento para sistemas
informáticos heterogéneos: la biblioteca de programación esqueleto SkePU, el sistema de tiempo de ejecución StarPU y la extensión del
lenguaje O C oad C ++. Los autores razonan sobre las ventajas de cada uno de estos enfoques y proponen cómo podrían integrarse
juntos en el contexto del proyecto PEPPHER [2] para lograr la capacidad de programación y la portabilidad del desempeño.

Mittal y Vetter [10], proporcionan una cobertura completa de literatura sobre sistemas informáticos acelerados por GPU. En
este contexto, los autores examinan la literatura sobre sistemas de ejecución, algoritmos, lenguajes de programación,
compiladores y aplicaciones.
Li y col. [7] estudiar empíricamente la productividad del programador en el contexto de OpenACC con CUDA. El estudio
que involucró a 28 estudiantes a nivel de pregrado y posgrado se realizó en la Universidad de Auburn en 2016. Los estudiantes
recibieron el código secuencial de dos programas y tuvieron que paralelizarlos utilizando tanto CUDA como OpenACC. De 28
estudiantes, solo una fracción pudo completar correctamente las tareas utilizando CUDA y OpenACC. Los autores concluyen
que OpenACC permite a los programadores acortar el tiempo de desarrollo del programa en comparación con CUDA. Sin
embargo, los programas desarrollados con CUDA se ejecutan más rápido que

12
sus homólogos de OpenACC lo hacen.
Este artículo complementa la investigación relacionada con un estudio empírico de cuatro marcos ampliamente utilizados
para programar sistemas heterogéneos: OpenCL, OpenACC, OpenMP y CUDA. Utilizando las suites de referencia estándar de
facto SPEC y Rodinia, estudiamos la productividad, el rendimiento y el consumo de energía. Nuestras herramientas de medición
CodeStat y x-MeterPU que desarrollamos para este estudio nos permiten abordar sistemas acelerados con Intel Xeon Phi y
GPU.

5 Resumen

Hemos presentado un estudio de productividad, rendimiento y energía para OpenMP, OpenACC, OpenCL y CUDA. A modo de
comparación, utilizamos las suites de referencia SPEC Accel y Rodinia en dos sistemas informáticos heterogéneos: Emil que
comprende dos procesadores Intel Xeon Phi E5 y un coprocesador Intel Xeon Phi, y Ida que tiene dos procesadores Intel Xeon
Phi E5 y una GPU GTX Titan X.

Nuestras principales observaciones incluyen: (1) programar con OpenCL requiere mucho más esfuerzo que programar con
OpenACC para el paquete de pruebas SPEC Accel; (2) programar con OpenCL en promedio requiere aproximadamente dos
veces más esfuerzo que programar con CUDA para la suite de referencia Rodinia; (3) el factor humano puede afectar la
fracción de líneas de código para paralelizar el código; (4) OpenMP, OpenCL y CUDA tienen un rendimiento y un consumo de
energía comparables en Ida; y (5) OpenCL se desempeña mejor que OpenACC para la suite de referencia SPEC Accel en Ida;
(6) la programación con OpenMP requiere menos esfuerzo que la programación con OpenCL y CUDA.

El trabajo futuro abordará las nuevas arquitecturas de Intel Xeon Phi y NVIDIA GPU. Además de los puntos de referencia de Rodinia
y SPEC, planeamos utilizar aplicaciones del mundo real.

6 Reconocimiento

Este artículo se basa en el trabajo de COST Action IC1406 Modelado y simulación de alto rendimiento para aplicaciones de Big
Data (cHiPSet), con el apoyo de COST (Cooperación europea en ciencia y tecnología.

Referencias

[1] E. Abraham, C. Bekas, I. Brandic, S. Genaim, EB Johnsen, I. Kondov, S. Pllana y

AA Streit. Preparación de aplicaciones HPC para exaescala: desafíos y recomendaciones. En 18a Conferencia
Internacional sobre Sistemas de Información en Red (NBiS), páginas 401–406, septiembre de 2015.

[2] S. Benkner, S. Pllana, JL Tra ff, P. Tsigas, U. Dolinsky, C. Augonnet, B. Bachmayer,

C. Kessler, D. Moloney y V. Osipov. PEPPHER: Uso eficiente y productivo de sistemas informáticos híbridos. Micro,
IEEE, 31 (5): 28–41, septiembre de 2011.

[3] S. Che, M. Boyer, J. Meng, D. Tarjan, JW Sheaère, S.-H. Lee y K. Skadron. Rodinia:
Una suite de referencia para la informática heterogénea. En IISWC 2009., páginas 44–54. IEEE,
2009.

[4] G. Chrysos. Intel © R Coprocesador Xeon Phi: la arquitectura. Informe técnico de Intel, 2014.

[5] G. Juckeland, W. Brantley, S. Chandrasekaran, B. Chapman, S. Che, M. Colgrove, H. Feng,

A. Grund, R. Henschel, W.-MW Hwu y col. Spec accel: un conjunto de aplicaciones estándar para

13
 medir el rendimiento del acelerador de hardware. En Taller internacional sobre modelización de rendimiento, evaluación
comparativa y simulación de sistemas informáticos de alto rendimiento, páginas 46–67. Springer, 2014.

[6] C. Kessler, U. Dastgeer, S. Thibault, R. Namyst, A. Richards, U. Dolinsky, S. Benkner,

JL Tr ff y S. Pllana. Aspectos de programabilidad y portabilidad del rendimiento de sistemas heterogéneos de múltiples núcleos.
En 2012 Diseño, Exposición de la conferencia de pruebas de automatización en Europa (FECHA), páginas 1403–1408, marzo de
2012.

[7] X. Li, P.-C. Shih, J. Overbey, C. Seals y A. Lim. Comparación de la productividad del programador
en OpenACC y CUDA: una investigación empírica. Revista Internacional de Ciencias de la Computación, Ingeniería y
Aplicaciones (IJCSEA), 6 (5): 1–15, 2016.

[8] Lu Li y Christoph Kessler. MeterPU: una API de abstracción de medición genérica que permite
Selección de backend esqueleto ajustada a la energía. Revista de supercomputación, páginas 1–16, 2016.

[9] S. Memeti y S. Pllana. Aceleración del análisis de la secuencia de adn utilizando intel (r) xeon phi (tm).
En 2015 IEEE Trustcom / BigDataSE / ISPA, volumen 3, páginas 222–227, agosto de 2015.

[10] S. Mittal y JS Vetter. Un estudio de las técnicas de computación heterogéneas cpu-gpu. ACM
Encuestas de Computación (CSUR), 47 (4): 69, 2015.

[11] NVIDIA. Guía de programación CUDA C. http://docs.nvidia.com/cuda/

cuda-c-guía-de-programación /. Consultado: 2017-03-06.

[12] NVIDIA. ¿Qué es la informática acelerada por GPU? http://www.nvidia.com/object/

what-is-gpu-computing.html. Consultado: 2017-04-03.

[13] OpenMP. Especi fi caciones OpenMP 4.0. http://www.openmp.org/specifications/. C.A-

cesado: 2017-03-10.

[14] Rodinia. Rodinia: aceleración de aplicaciones informáticas intensivas con aceleradores, diciembre
2015. Último acceso: 10 de abril de 2017.

[15] SPEC. Spec accel: Léame primero. https://www.spec.org/accel/docs/readme1st.html#

Q11. Consultado: 2017-04-10.

[16] JE Stone, D. Gohara y G. Shi. OpenCL: un estándar de programación paralela para het-
sistemas informáticos erógenos. Computación en ciencia e ingeniería, 12 (1-3): 66–73, 2010.

[17] C.-L. Su, P.-Y. Chen, C.-C. Lan, L.-S. Huang y K.-H. Wu. Resumen y comparación de
tecnología opencl y cuda para gpgpu. En 2012 IEEE Asia Pacific Conference on Circuits and Systems, páginas 448–451,
diciembre de 2012.

[18] A. Viebke y S. Pllana. El potencial de intel (r) xeon phi para supervisado deep
aprendiendo. En 2015 IEEE 17th International Conference on High Performance Computing and Communications, páginas
758–765, agosto de 2015.

[19] S. Wienke, P. Springer, C. Terboven y D. an Mey. OpenACC: Primeras experiencias con

Aplicaciones del mundo real. En Actas de la 18a Conferencia Internacional sobre Procesamiento Paralelo, Euro-Par'12,
páginas 859–870, Berlín, Heidelberg, 2012. Springer-Verlag.

[20] Y. Yan, BM Chapman y M. Wong. Una comparación de heteroge-

modelos de programación neous y manycore. https://www.hpcwire.com/2015/03/02/
una-comparación-de-modelos-de-programación-heterogéneos-y-muchos-núcleos /, Marzo de 2015.
Consultado: 2017-03-31.

14