modelo de procesamiento paralelo en arquitecturas heterog...
TRANSCRIPT
Modelo de procesamiento paralelo
en arquitecturas heterogeneas para
regresiones lineales multivariables
Trabajo de grado para optar por el tıtulo de Magister en
ciencias de la informacion y las comunicaciones
Cristian Rojas
Dirigido por: PhD. Nelson Enrique Vera
Facultad de ingenierıa
Universidad Distrital Franciso Jose Caldas, Bogota D.C.
Enero 2019
c© por Cristan Alejandro Rojas , 2019
Todos los derechos reservados.
ii
A Martha Quintero, Isabel Rojas y Gabriela Casas.
A mis amigos Andres Cobos, Gabriel Mora, Yeison Sanchez y Steven Sierra por su
confianza y respaldo en tiempos dificiles.
iii
Agradecimientos
Al Centro de Computo de Alto Desempeno (CECAD) de la Universidad Distrital
por proporcionar los recursos computacionales para realizar este proyecto.
A la Universidad Javeriana, EMGESA y el profesor Efraın Dominguez por
proporcionar los datos para evaluar el modelo.
A mi director Nelson Enrique Vera por su guıa y asesoria para desarrollar este
proyecto.
iv
“Work it harder, make it better, do it faster, make us stronger“ Daft Punk
v
Resumen
La generacion de modelos de regresion lineal multiple demanda una seleccion
exhaustiva de las variables regresoras que permiten obtener un alto nivel de precision
en las tareas de prediccion. Este proceso de seleccion representa un alto reto
algorıtmico y computacional, debido a que es necesario obtener y evaluar cada uno
de los posibles modelos para poder seleccionar de forma eficiente el mas preciso.
En este trabajo se creo un modelo de procesamiento paralelo para parametrizar
modelos de regresiones lineales multivariables, utilizando arquitecturas heterogeneas:
HMMMR (Heterogeneous Model for Massive Multilinear Regressions). HMMMR fue
disenado orientado a explotar los beneficios de las capacidades de computo paralelo de
GPUs mediante el uso de estructuras de datos y operaciones matriciales optimizadas
para realizar calculos en batch. El objetivo principal de HMMMR es hacer una
seleccion de un subconjunto de predictores que presenten mejores resultados en una
regresion lineal para una determinada variable objetivo.
La implementacion de HMMMR muestra superioridad en el tiempo de calculo de
regresiones dado que se hace un uso mas eficiente de las capacidad de procesamiento
en batch de la GPU. Para los datasets evaluados (29332215 y 46626033 regresiones
con datos limnıgraficos y pluviograficos de las cuentas de Betania y Quimbo) la
implementacion de HMMMR llego a ser hasta 9.8 y 5.06 veces mas rapida que la
implementacion en una plataforma homogenea.
Disponibilidad: https://github.com/carojasq/HMMMR .
vi
Indice general
Lista de Tablas X
Lista de Figuras XI
1. Introduccion 1
1.1. Problema de investigacion . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Marco teorico 9
2.1. Ciencia de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Flujo de trabajo tıpico en la ciencia de datos . . . . . . . . . . 9
2.1.2. ¿Que algoritmos se utilizan en la ciencia de datos? . . . . . . . 11
2.1.3. ¿Por que es difıcil obtener modelos de regresion lineal multiva-
riable? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. Computacion heterogenea paralela . . . . . . . . . . . . . . . . . . . . 19
2.2.1. ¿Que es la computacion heterogenea paralela? . . . . . . . . . 19
2.2.2. Fundamentos de OpenCL . . . . . . . . . . . . . . . . . . . . 23
vii
2.2.3. Fundamentos de CUDA . . . . . . . . . . . . . . . . . . . . . 35
2.3. Estandares y modelos computacionales para el procesamiento algebrai-
co lineal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.1. BLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.2. Implementaciones de BLAS . . . . . . . . . . . . . . . . . . . 41
2.3.3. CUBLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.4. Intel MKL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.5. clMathLibraries . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3. Estado del arte 47
3.0.1. ¿Que antecedentes existen de soluciones de aceleracion para
la obtencion de modelos de clasificacion y/o prediccion en la
ciencia de datos? . . . . . . . . . . . . . . . . . . . . . . . . . 47
4. HMMMR (Heterogeneous Model for Massive Multilinear Regres-
sions) 50
4.1. Procesamiento multi-core I . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2. Procesamiento many-core . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3. Procesamiento multi-core II . . . . . . . . . . . . . . . . . . . . . . . 64
4.4. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5. Evaluacion del modelo 67
5.1. Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.1. Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.2. Obtencion de metricas . . . . . . . . . . . . . . . . . . . . . . 68
5.1.3. Herramientas comparadas . . . . . . . . . . . . . . . . . . . . 68
5.1.4. Equipo de computo . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.5. Set de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3. Analisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
viii
5.3.1. Tiempo de ejecucion . . . . . . . . . . . . . . . . . . . . . . . 72
5.3.2. Uso de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6. Discusion 76
6.1. Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.1. Modelo HMMMR . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.2. Libreria informatica . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Bibliografıa 81
ix
Indice de tablas
1.1. Metodologia de desarrollo del proyecto. . . . . . . . . . . . . . . . . . 6
2.1. Modo como los objetos de memoria son asignados y accedidos por el
host y/o una instancia de un kernel. . . . . . . . . . . . . . . . . . . . 32
2.2. Tipos de SVM y sus principales caracterısticas. . . . . . . . . . . . . 34
5.1. Resultados procesamiento data set A. . . . . . . . . . . . . . . . . . . 71
5.2. Resultados procesamiento data set B. . . . . . . . . . . . . . . . . . . 71
x
Indice de figuras
1.1. Factores de aceleracion en diferentes aplicaciones. Nvidia (2018a) . . 4
2.1. Diagrama de Venn de la ciencia de datos (Conway, 2013). . . . . . . . 10
2.2. Flujo de trabajo tıpico en la ciencia de dato(O’Neil and Schutt, 2013). 10
2.3. Ejemplo clasificacion usando KNN(Wu et al., 2014). . . . . . . . . . . 13
2.4. Hiperplano que separan los datos de entrada(Opencv, 2013). . . . . . 13
2.5. Hiperplano optimo(Opencv, 2013). . . . . . . . . . . . . . . . . . . . 14
2.6. Funcion kernel(Opencv, 2013). . . . . . . . . . . . . . . . . . . . . . . 15
2.7. Funcion kernel(Giovanni and Velasquez, 2014). . . . . . . . . . . . . . 15
2.8. Factor de correlacion de Pearson (r). . . . . . . . . . . . . . . . . . . 17
2.9. Plataforma heterogenea tıpica (Vera Parra et al., 2018). . . . . . . . . 21
2.10. Logotipo de OpenCL (Khronos, 2013) . . . . . . . . . . . . . . . . . . 22
2.11. Modelo de plataforma de OpenCL (Vera Parra et al., 2018). . . . . . 24
2.12. Ejemplo de un NDRange con N=2. (Vera Parra et al., 2018). . . . . . 26
2.13. Identificadores y tamanos en un NDRange (Vera Parra et al., 2018). . 27
2.14. Tipos y regiones de memoria desde el punto de vista de OpenCL
(Vera Parra et al., 2018). . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.15. Lenguajes de programacion y APIs soportadas por CUDA. (Cuda, 2015) 35
2.16. Escalabilidad automatica de CUDA: Los bloques de hilos se distribuyen
de forma homogenea entre los SMs (Stream Multiprocessors). (Cuda,
2015) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.17. Ejemplo de definicion y llamado de un kernel (Cuda, 2015). . . . . . . 37
xi
2.18. Malla de bloques de hilos (Cuda, 2015). . . . . . . . . . . . . . . . . . 38
2.19. Ejemplo de definicion y llamado de un kernel con una malla bidimen-
sional conformada por bloques bidimensionales de hilos. (Cuda, 2015) 39
2.20. Jerarquıa de memoria en CUDA (Cuda, 2015). . . . . . . . . . . . . . 40
2.21. Programacion heterogenea (Cuda, 2015). . . . . . . . . . . . . . . . . 41
2.22. Programacion heterogenea (Wikipedia, 2018). . . . . . . . . . . . . . 43
4.1. Flujo de datos HMMMR . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2. Ejemplo de archivo de archivo de entrada . . . . . . . . . . . . . . . . 53
5.1. Resultados de tiempo de ejecucion usando data set A . . . . . . . . . 72
5.2. Resultados de tiempo de ejecucion usando data set B . . . . . . . . . 73
xii
Capıtulo 1
Introduccion
Dado que con el desarrollo de la tecnologıa actual se encuentran ahora disponibles
como nunca antes grandes cantidades de datos de diversos campos del conocimiento
y aplicaciones, por esta razon que la ciencia de datos se ha convertido en una de
las disciplinas emergentes mas relevantes del siglo XXI. El uso de tecnicas tales
como el analisis exploratorio de datos y modelamiento y algoritmos hacen de la
ciencia de datos una herramienta efectiva para la toma de decisiones y extraccion
de conocimiento para organizaciones e investigadores. Dada la creciente cantidad
de datos que actualmente se recolectan cada vez se incrementan los requerimientos
computacionales para realizar el analisis de los mismos, pudiendo tomar desde horas
hasta dıas o semanas en completarse. Adicional a los costos de tiempo, cuando
se cuenta con grandes cantidades de datos a procesar se debe contar con grandes
capacidades computacionales, por ejemplo, un cluster con miles de nucleos para
procesar la informacion. Teniendo en cuenta que muy pocas personas u organizaciones
cuentan con estos recursos se hace necesario encontrar una manera eficiente y de
bajo costo para procesarlos. Con la llegada de estandares como OpenCL se ha dado
paso al uso de arquitecturas heterogeneas que involucran aceleradores de diferentes
tipos como: GPUs (Graphical Processing Units), DSPs (Digital Signal Processors),
FPGA (Field-Programmable Gate Array), entre otros. Las ventajas del uso de estas
1
arquitecturas para el procesamiento de datos se enfocan en la posibilidad de contar
con miles de procesadores por unidad, permitiendo que un computador estandar
o una laptop sea capaz de tener altas capacidades de procesamiento. Trabajos
previos se han focalizado en ciertos aspectos especıficos de algoritmos de ciencias de
datos, por ejemplo, arboles y bosques de decision, metodo de Monte Carlo, modelos
bayesianos, regresiones lineales, redes neuronales, agrupamiento (clustering), analisis
de componentes principales, entre otros. Sin embargo, los alcances de estos trabajos
se ven limitados debido que la mayorıa de las las implementaciones generadas no son
reusables. En este proyecto se propone la creacion de un modelo de procesamiento
sobre arquitecturas heterogeneas para paralelizar la parametrizacion modelos de
regresion lineal multivariables, junto con una implementacion de estos algoritmos
en forma de una biblioteca informatica. Esta biblioteca informatica sera extensible,
de facil uso, y libre permitiendo ası que un usuario no familiarizado con arquitecturas
heterogeneas sea capaz de hacer uso de ellas de una manera transparente, de tal
manera que se puedan optimizar procesos y reducir tiempos de procesamiento del
analisis de datos. Este proyecto permitira a otros investigadores y usuarios extenderlo
con nuevos procedimientos, con el objeto de crear un conjunto de bibliotecas
informaticas para la ciencia de datos.
1.1. Problema de investigacion
1.2. Justificacion
La ciencia de datos es una de las disciplinas academicas emergentes mas relevantes
en estos primeros anos del siglo XXI. La ciencia de datos consiste en la extraccion
de conocimiento a partir de los datos, esto mediante la recoleccion, preparacion,
pre-procesamiento, analisis, visualizacion y preservacion de grandes cantidades de
informacion Saltz and Stanton (2017). Una de las principales razones por las que
el analisis de datos es importante para una organizacion se debe a que representa
2
una pieza clave para la toma de decisiones dentro de la misma Dhar (2013). Por
lo general, cuando se cuenta con gran cantidad de datos para hacer un analisis se
realiza un muestreo de los datos con el fin de reducir el conjunto de datos a analizar.
Sin embargo, uno de los mayores limitantes es el costo computacional requerido
(tiempo, equipos disponibles) para hacerlo, pueden existir casos en los que puede
tomar desde horas hasta dıas Drignei et al. (2008). Para reducir este tiempo de
procesamiento se suele hacer uso de clusters con miles de procesadores, sin embargo, el
uso de estas infraestructuras esta limitado tanto por costos como por disponibilidad.
Recientemente se han dado avances en el uso de arquitecturas heterogeneas en vez
del uso de CPUs para el procesamiento de grandes conjuntos de datos. La figura 1.1,
evidencia la aceleracion de ejecucion que se logra conseguir cuando se paraleliza de
forma eficiente un proceso: hasta 1000 % en el area de fısica, hasta 4700 % para el
alineamiento de secuencias biologicas y hasta un 19700 % en el area de finanzas. Con el
uso de estas tecnologıas ahora es posible hacer un analisis de datos que anteriormente
se hacıa en un cluster con miles de cores, en un solo nodo computacional, el cual
puede ser una laptop o un computador de estandar que cuenta con una GPU la cual
a su vez cuenta con miles de cores para el procesamiento de los datos Lee et al. (2010).
Otra de las mayores dificultades para el uso de arquitecturas heterogeneas es su
dificultad de programacion, no permitiendo ası que un usuario final o programador
estandar pueda acceder a sus ventajas. Este proyecto plantea el diseno de un modelo
y la implementacion de una biblioteca informatica libre, de facil uso y extensible, para
reducir los tiempos y los costos de procesamiento de datos en el caso de regresiones
lineales multivariables.
3
1.3. Objetivos
1.3.1. Objetivo General
Crear un modelo de procesamiento paralelo para parametrizar modelos de
regresiones lineales multivariables, utilizando arquitecturas heterogeneas.
1.3.2. Objetivos especıficos
Disenar un modelo de procesamiento paralelo para determinar los parametros
estimadores de modelos de regresiones lineales multivariables, utilizando proce-
samiento paralelo en arquitecturas heterogeneas.
Disenar e implementar una biblioteca informatica libre, de facil uso y extensible,
con los procedimientos de regresiones lineales multivariables en arquitecturas
heterogeneas
Evaluar el modelo propuesto mediante la medicion del desempeno de las
bibliotecas informaticas implementadas.
Figura 1.1: Factores de aceleracion en diferentes aplicaciones. Nvidia (2018a)
4
Generar proyecciones y prospectivas de uso e innovacion (mejoras, optimizacion
y transformacion) del modelo propuesto.
1.4. Hipotesis
El proceso de calculo masivo de regresiones lineales multivariables es mas eficiente
al hacer uso de computacion heterogenea.
1.5. Metodologıa
La tabla 1.1 describe la metodologıa usada para el desarrollo de este proyecto.
5
Tabla
1.1
:M
etodol
ogia
de
des
arro
llo
del
pro
yect
o.
FA
SE
OB
JE
TIV
OA
CT
IVID
AD
ES
PR
OD
UC
TO
DIS
EN
O
Dis
enar
un
model
ode
pro
cesa
mie
nto
par
alel
o
par
adet
erm
inar
los
par
amet
ros
esti
mad
ores
de
model
osde
regr
esio
nes
linea
les
mult
ivar
iable
s,uti
liza
ndo
pro
cesa
mie
nto
par
alel
o
enar
quit
ectu
ras
het
erog
enea
s.
Rev
isio
nbib
liog
rafica
de
imple
men
taci
ones
sim
ilar
es
exis
tente
sM
odel
o
dis
enad
o.R
evis
ion
bib
liog
rafica
de
regr
esio
nes
linea
les
mult
ivar
iable
s
Defi
nir
un
model
ode
pla
tafo
rma/
mem
oria
/eje
cuci
on.
Dis
enar
un
algo
ritm
ode
pro
cesa
mie
nto
par
alel
opar
a
model
osde
regr
esio
nlinea
l
mult
ivar
iable
.
IMP
LE
ME
NT
AC
ION
Dis
enar
eim
ple
men
tar
una
bib
liot
eca
info
rmat
ica
libre
,
de
faci
luso
yex
tensi
ble
,co
n
los
pro
cedim
iento
sde
regr
esio
nes
linea
les
mult
ivar
iable
s
enar
quit
ectu
ras
het
erog
enea
s.
Model
arla
sbib
liot
ecas
info
rmat
icas
ades
arro
llar
.N
ucl
eode
bib
liot
ecas
-
info
rmat
icas
con
su
deb
ida
docu
men
taci
on.
Art
ıculo
publica
ble
en
revis
tain
dex
ada
por
Col
cien
cias
Defi
nir
un
lengu
aje
de
pro
gram
acio
npar
alel
a
par
aar
quit
ectu
ras
het
erog
enea
s.
6
Con
stru
irel
conju
nto
de
bib
liot
ecas
info
rmat
icas
.
Docu
men
tar
las
bib
liot
ecas
info
rmat
icas
.
Publica
rla
slibre
rıas
.
EV
AL
UA
CIO
N
Eva
luar
elm
odel
opro
pues
to
med
iante
lam
edic
ion
del
des
emp
eno
de
las
bib
liot
ecas
info
rmat
icas
imple
men
tadas
.
Defi
nir
un
met
odo
de
eval
uac
ion
de
her
ram
ienta
sde
regr
esio
nes
linea
les
mult
ivar
iable
sC
ompar
ativ
ode
des
emp
eno
de
her
ram
ienta
sD
efinir
elin
stru
men
tode
eval
uac
ion
yco
mpar
acio
n
auti
liza
r.
Defi
nir
las
her
ram
ienta
s
de
refe
renci
apar
ala
eval
uac
ion.
Defi
nir
los
conju
nto
sde
dat
os
uti
liza
dos
par
ala
eval
uac
ion.
7
PR
OY
EC
CIO
N
Gen
erar
pro
yecc
iones
y
pro
spec
tiva
sde
uso
ein
nov
acio
n
(mej
oras
,op
tim
izac
ion
y
tran
sfor
mac
ion)
del
model
o
pro
pues
to.
Cre
aruna
bol
sade
pro
yect
os
pro
pues
tos
par
ala
inte
grac
ion
de
nuev
ospro
cedim
iento
sde
cien
cia
de
dat
osen
bib
liot
eca
info
rmat
ica
des
arro
llad
a.
Bol
sade
pro
yect
os
pro
pues
tos
par
ala
exte
nsi
onde
funci
onal
idad
.
8
Capıtulo 2
Marco teorico
2.1. Ciencia de datos
La ciencia de datos es un campo interdisciplinar influenciado principalmente por
las matematicas, la estadıstica y las ciencias de la computacion, que tiene como objeto
la extraccion de conocimiento mediante el analisis de grandes volumenes de datos.
(Conway, 2013) propone un diagrama de Venn que define a la ciencia de datos como la
interseccion entre 3 grandes areas: el conocimiento formal matematico y estadıstico,
las habilidades de “hacker” que sin necesidad de un conocimiento formal aportan
capacidades para entender, acceder y manipular la tecnologıa y sus algoritmos con el
proposito de obtener datos, y finalmente la experticia en metodologıas de investigacion
que permiten identificar problematicas y formular preguntas e hipotesis adecuadas
(ver figura 2.1).
2.1.1. Flujo de trabajo tıpico en la ciencia de datos
Un tıpico flujo de trabajo en la ciencia de datos incluye: recoleccion, preparacion,
analisis, visualizacion, administracion y preservacion de grandes cantidades de datos
y/o informacion (ver figura 2.2).
9
Requerimiento de datos : Durante esta etapa se analizan cuales seran las entradas
de datos necesarias basados en los requerimientos del analisis que se esta
llevando a cabo o de las necesidades de la organizacion y/o cliente.
Figura 2.1: Diagrama de Venn de la ciencia de datos (Conway, 2013).
Figura 2.2: Flujo de trabajo tıpico en la ciencia de dato(O’Neil and Schutt, 2013).
10
Recoleccion de datos :Los datos son recolectados de varias fuentes.
Procesamiento de datos :Los datos que fueron obtenidos inicialmente deben ser
procesados u organizados para realizar el analisis.
Limpieza de datos :Una vez procesados y organizados, los datos puede que esten
incompletos, contengan duplicados o contengan errores. La limpieza de datos es
el proceso de prevenir y corregir estos errores de tal manera que no afecten el
posterior analisis.
Analisis exploratorio de datos :Una vez los datos estan limpios, pueden ser
analizados. La estadıstica descriptiva tal como un promedio, media, desviacion
puede ayudar a entender los datos. La visualizacion de datos puede ayudar a
examinar los datos en un formato grafico.
Modelamiento y algoritmos : Formulas matematicas o modelos llamados algorit-
mos deben ser aplicados con el fin de identificar las relaciones entre las variables,
tales como correlacion o causacion.
Producto de datos :Es una aplicacion de computador la cual toma entrada de
datos y genera salidas, alimentando ası su entorno.
Comunicacion:Una vez los datos fueron analizados, estos pueden ser reportados
en muchos formatos a los usuarios de tal manera que se satisfagan sus
requerimientos iniciales (Kanaan, 2014)).
2.1.2. ¿Que algoritmos se utilizan en la ciencia de datos?
Los principales algoritmos utilizados en la ciencia de datos buscan desempenar
tareas tales como la clasificacion o la prediccion mediante el aprendizaje de maquina.
El termino “aprender” en el dominio de las maquinas hace referencia a generalizar
comportamientos a partir de una informacion suministrada en forma de ejemplos.
De acuerdo a la forma que “aprenden” las maquinas, los algoritmos se puede
11
clasificar en supervisados y no supervisados. En el aprendizaje supervisado los datos
traen relacionado un objetivo mientras que en el no supervisado los datos no traen
ninguna relacion explicita con algun objetivo. Los algoritmos que utilizan aprendizaje
supervisado (vecinos mas cercanos, maquinas de vectores de soporte, arboles de
decision, regresion. entre otros) normalmente cumplen funciones de clasificacion
o regresion, mientras que los no supervisados (modelos gausianos, aprendizaje
multiple, estimacion de densidad, entre otros) cumplen funciones de agrupamiento.
A continuacion se realiza una breve descripcion de algunos ejemplos de algoritmos de
aprendizaje de maquina supervisados utilizados en la ciencia de datos.
Vecinos mas cercanos (K-NN)
Es un metodo de clasificacion supervisada no parametrico que permite estimar la
funcion de densidad de probabilidad o la probabilidad a posteriori de que un elemento
pertenece a una clase determinada. El calculo de esta probabilidad se basa en analizar
a que clase pertenecen los k vecinos mas cercanos. Para determinar cuales son los
vecinos mas cercanos se utiliza generalmente la distancia euclidiana. Un buen ejemplo
para esclarecer el funcionamiento de KNN es su uso en la clasificacion de clientes de
bancos en confiables o no para realizarles un credito. En la figura 2.3 el cliente a ser
clasificado se denota con el cuadro verde, mientras que los clientes que han realizado
creditos y no los han pagado con la estrella roja y aquellos que si pagaron con el
triangulo azul. Si se emplea un k = 5, serıa mas probable que el cliente pague debido
a que 3 de sus 5 vecinos tambien pagaron. Si se emplea un k = 10, serıa mas probable
que el cliente no pague debido a que 6 de sus 10 vecinos tampoco pagaron.
Maquinas de vectores de soporte (SVM)
Tecnica de aprendizaje supervisado creada por (?) que permite realizar tareas de
clasificacion y de regresion mediante la creacion de hiperplanos que separan los datos
de entrada.
12
Un hiperplano es un plano de n-1 dimensiones que divide en dos a un plano
n dimensional. En la figura 2.4 se muestran algunos hiperplanos (en este caso
rectas) que dividen en dos el plano bidimensional donde se encuentran unos datos de
Figura 2.3: Ejemplo clasificacion usando KNN(Wu et al., 2014).
Figura 2.4: Hiperplano que separan los datos de entrada(Opencv, 2013).
13
entrenamiento (cuadros y cırculos). SVM permite encontrar el hiperplano que mejor
separe los datos de entrenamiento, es decir aquel que presente una mayor margen
hacia los datos de cada una de las clases (ver figura 2.5).
Cuando los datos no son separables linealmente, SVM ofrece unas funciones kernels
que permiten llevar los datos a una dimension superior donde si sean separables (ver
figura 1.6).
Arboles de decision
Los arboles de decision son un metodo de aprendizaje supervisado no parametrico
utilizado para la clasificacion y la regresion. Su funcion es crear un modelo que
prediga el valor de una variable objetivo mediante el aprendizaje de reglas simples de
decision inferidas a partir de las caracterısticas de los datos. Esas reglas se representan
mediante un grafo (ver figura 2.7) y son una serie de condiciones aplicadas a los
atributos de los datos. Los nodos iniciales o intermedios del grafo representan atributos
de los datos, las aristas representan las condiciones que deben cumplir para tomar
Figura 2.5: Hiperplano optimo(Opencv, 2013).
14
ese camino y los nodos finales representan la decision de regresion o clasificacion a
tomar.
Para seleccionar el orden de cada uno de los atributos en el arbol, se utilizan
metricas de la teorıa de informacion, tales como, cantidad de informacion, entropıa y
ganancia de informacion.
Figura 2.6: Funcion kernel(Opencv, 2013).
Figura 2.7: Funcion kernel(Giovanni and Velasquez, 2014).
15
Regresion
Los metodos de regresion estudian la construccion de modelos para explicar o
representar la dependencia entre una variable respuesta o dependiente (Y) y la(s)
variable(s) explicativa(s) o independiente(s), X. Si la relacion entre esos dos tipos de
variables es lineal y el numero de variables explicativas o independientes es de 1, la
regresion es simple lineal, en el caso de que la relacion sea lineal pero haya mas de
una variable explicativa la regresion es lineal multivariable.
La regresion lineal simple se modela mediante la ecuacion 2.1; donde ε es el error
generado por valores aleatorios. Si ε es despreciado el modelo se reduce a la ecuacion
de una recta donde β0 es el corte con el eje Y y β1 es la pendiente. β0 y β1 son llamados
estimadores y se calculan normalmente por el metodo de mınimos cuadrados con el
fin de reducir el error entre los valores reales y los generados por la ecuacion de la
recta.
y = β0 + β1x+ ε (2.1)
La precision de las predicciones realizadas con este modelo dependera del grado
de asociacion lineal existente entre las variables y la bondad del ajuste de la recta de
regresion a los datos observados. Para medir este grado de linealidad y esta bondad
de ajuste se utilizan dos coeficientes: el de correlacion lineal de Pearson y el de
determinacion. En la figura 2.8 se pueden observar varios valores de coeficientes de
correlacion.
¿Que son las regresiones lineales multivariables y cual es su importancia
en la ciencia de datos?
En el mundo real la mayorıa de variables son muy difıciles de predecir de
forma precisa a partir de solo otra variable; normalmente el comportamiento de un
parametro depende de multiples variables, unas con mayor peso que otras. Esto hace
16
que la regresion lineal simple no sea suficiente para modelar y predecir la mayorıa de
variables reales.
Como solucion a la situacion anterior, la ciencia de datos presenta las regresiones
lineales multivariables tambien conocidas como regresiones lineales multiples. Este
tipo de regresion intenta modelar la relacion entre dos o mas variables regresoras y
una variable de respuesta mediante el ajuste de una ecuacion lineal con los datos
observados (ver ecuacion 2.2). Cada valor de la variable independiente x es asociado
con un valor de la variable dependiente y (Yale, 1998). En una regresion lineal
multiple, hay p variables explicativas, y la relacion entre la variable dependiente
y las variables regresoras es representada mediante la siguiente ecuacion:
yi = β0 + β1x1i + β2x2i + β3x3i + ...+ ε (2.2)
En donde β0 es el termino constante y β1, β2. . . βp son los coeficientes que
relacionan las variables explicativas p con las variables de interes.
Figura 2.8: Factor de correlacion de Pearson (r).
17
Una regresion lineal multiple puede ser vista como una extension de regresiones
lineales sencillas, donde hay p variables regresoras, o una regresion lineal simple
puede verse como un caso especial de un regresion lineal multiple con p=1. El
termino ”lineal.es usado porque en las regresiones lineales multiples se asume que y
esta directamente relacionado con una combinacion lineal de las variables regresoras
(Tranmer and Elliot, 2008).
El objetivo principal de un analisis de regresion lineal multiple consiste en la
estimacion de los parametros. Para estos parametros estimadores se busca que se
minimicen:
S(β) =n∑
i=1
ε2i =n∑
i=1
(yi − y)2)
n∑i=1
(yi − ˆbeta0 − ˆbeta0x1i − ...− ˆβkxik
La solucion al estimador por mınimos cuadrados para β es:
β = (XTX)−1XTY
Cabe tener en cuenta que esta solucion solo es valida cuando existe la inversa
(XTX)−1, esta matriz inversa solo existe cuando todas las variables regresoras son
linealmente independientes (Pineda et al., 2013).
2.1.3. ¿Por que es difıcil obtener modelos de regresion lineal
multivariable?
Es evidente que la complejidad del proceso de obtencion del modelo aumenta
a medida que el numero de variables regresoras aumenta, principalmente porque
por cada nueva variable regresora se tendra un nuevo estimador β por calcular. Sin
embargo este no es el reto a solucionar, el verdadero problema aparece cuando no se
tiene certeza de cuales son las variables regresoras que permiten calcular con precision
la variable a predecir. Si se tiene un conjunto de n posibles variables regresoras,
18
habra una cantidad∑p
i=1
(ni
)de posibles modelos de regresion lineal multivariable
que permitiran predecir la variable deseada. El verdadero reto a solucionar desde el
punto de vista algorıtmico y computacional es obtener y evaluar cada uno de esos
posibles modelos para poder seleccionar de forma eficiente el mas preciso.
2.2. Computacion heterogenea paralela
En este capıtulo se realiza una revision conceptual de la computacion heterogenea
y de sus estandares y modelos de programacion mas comunes: OpenCL y CUDA. Se
abordan los modelos de plataforma, ejecucion y memoria de OpenCL y se exponen
los fundamentos de CUDA en cuanto a modelo de programacion, jerarquıa de hilos,
jerarquıa de memoria y programacion heterogenea. modelos de programacion tales
como CUDA y OpenCL.
2.2.1. ¿Que es la computacion heterogenea paralela?
A traves de la historia de la computacion, el paradigma de desarrollo y evolucion
de los procesadores se habıa enfocado en el aumento de su capacidad de computo
mediante el incremento de la frecuencia de reloj, con el objeto de ejecutar una
mayor cantidad de instrucciones en el menor tiempo posible. Sin embargo, desde
2003 debido al consumo de energıa y los problemas de disipacion de calor que limitan
la construccion de procesadores que aumenten la frecuencia de reloj y el nivel de
actividades productivas que puede ejecutarse en cada periodo de reloj en un unico
procesador, se cambio el enfoque integrando multiples unidades de procesamiento
en un mismo chip para aumentar el poder de procesamiento (de Antonio and
Marina, 2005). Gracias al desarrollo de estos procesadores se abrio la posibilidad
de resolver problemas computacionales que antes hubieran sido imposibles (Alba,
2005). Estos problemas deben ser solucionados de una manera distinta a como se
resuelven linealmente, tomando un problema cualquiera se divide en un conjunto
19
de sub-problemas para resolver estos simultaneamente sobre diferentes unidades de
procesamiento.
De acuerdo a lo expuesto en el parrafo anterior, en la actualidad el desarrollo de
sistemas de procesamiento se ha enfocado en producir dispositivos con la capacidad de
ejecucion simultanea de dos manera diferentes: La primera opcion es el diseno de CPUs
multi-core, optimizadas para reducir el tiempo de ejecucion de procesos secuenciales
(lactency cores); la segunda opcion, es el diseno de sistemas de procesamiento many-
thread, como por ejemplo las GPUs (Unidades de Procesamiento Grafico) optimizadas
para mejorar el desempeno (menos tiempo y menos consumo de energıa electrica) en
la ejecucion de procesos paralelizables (throughput cores). Debido a que la mayorıa de
problemas computacionalmente intensivos poseen procesos tanto secuenciales como
paralelizables, en los ultimos anos se ha iniciado el proceso de integracion de los
sistemas multi-core y los sistemas many-thread en plataformas computacionales
denominadas heterogeneas (Kirk and Hwu, 2012).
Una plataforma de computacion heterogenea se define como un sistema conforma-
da por lo menos de dos tipos diferentes de procesadores, normalmente, con el objeto de
incorporar capacidades de procesado especializadas para realizar tareas particulares
(Shan, 2006). Un sistema heterogeneo se conforma habitualmente por una o mas
CPU(s) que cumple(n) la funcion de unidad de procesamiento principal (llamado
generalmente Host) y uno o mas dispositivos de procesamiento diferentes, como
por ejemplo GPUs (Graphics Processing Units), DSPs (Digital Signal Processors),
FPGAs (Field Programmable Gate Arrays), que cumple(n) la funcion de aceleradores
(ver figura 2.9). Tambien se puede encontrar la integracion de dos o mas tipos de
procesadores en un solo Chip, por ejemplo un APU (accelerated processing unit) es
un microprocesador que integra una CPU multinucleo y una GPU mediante un bus
de alta velocidad.
Ası como la heterogeneidad entre dispositivos de procesamiento representa una
ventaja al ofrecer capacidades de procesado especializadas para realizar tareas
particulares, tambien representa una gran desventaja desde el punto de vista
20
del desarrollo. La heterogeneidad entre dispositivos de procesamiento se centra
principalmente en la diferencia entre arquitecturas de conjuntos de instrucciones
ISA (Instruction Set Architecture), por tal motivo cada uno de los tipos de
dispositivos podra contar con modelos, paradigmas y herramientas de programacion
totalmente diferentes, lo que conlleva a procesos de desarrollo separados con tortuosas
integraciones.
Los limitantes en la integracion de procesos de desarrollo para los diferentes tipos
de dispositivos que pueden estar involucrados en un sistema heterogeneo se han
comenzado a mitigar con la creacion de estandares de plataformas y modelos de
programacion tales como CUDA y OpenCL.
OpenCL (Open Computing Language) es un estandar abierto y libre para la
programacion paralela de proposito general sobre plataformas heterogeneas compues-
tas por CPUs (host) y otros dispositivos (aceleradores) tales como GPUs, DSPs,
FPGAs, entre otros (ver logo en la figura 2.10). El objetivo de OpenCL es abstraer
cualquier sistema heterogeneo y presentarlo como una unica jerarquıa de 4 modelos
Figura 2.9: Plataforma heterogenea tıpica (Vera Parra et al., 2018).
21
(plataforma/memoria/ejecucion/programacion) que permita integrar el proceso de
desarrollo (GROUP et al., 2017).
OpenCL consiste en un framework conformado por una API (Application
Programming Interface) y un lenguaje de programacion multiplataforma. Este
framework presenta las siguientes caracterısticas:
Soporta ambos modelos de programacion paralela: datos y tareas.
Utiliza un subconjunto de ISO C99 con extensiones para el paralelismo.
Define requisitos numericos consistentes basados en IEEE 754
Define un perfil de configuracion para dispositivos portables y embebidos.
Permite la interaccion eficiente con OpenGL, OpenGL ES y otras APIs graficas.
Como se menciono arriba, OpenCL se define totalmente mediante una jerarquıa
de 4 modelos: plataforma, memoria, ejecucion y programacion. A continuacion se
describen los modelos de plataforma, de ejecucion y de memoria (la parte basica del
modelo de programacion se explica en la parte II del presente libro mediante ejemplos
fundamentales).
Figura 2.10: Logotipo de OpenCL (Khronos, 2013)
22
2.2.2. Fundamentos de OpenCL
El modelo de plataforma de OpenCL consiste en un host conectado a uno o varios
dispositivos OpenCL (ver figura 2.3). Un dispositivo esta conformado por uno o mas
unidades de computo CUs (Compute Units), que a su vez estan divididas en elementos
de procesamiento PEs (Processing Elements).
Una aplicacion OpenCL esta conformada por dos tipos de codigos: un codigo de
host que se ejecuta sobre las CPUs de acuerdo al modelo nativo de su plataforma y
un codigo kernel que es suministrado del host a los dispositivos como comandos para
que sean ejecutados por los elementos de procesamiento.
Modelo de plataforma
El modelo de plataforma de OpenCL consiste en un host conectado a uno o varios
dispositivos OpenCL (ver figura 2.11). Un dispositivo esta conformado por uno o mas
unidades de computo CUs (Compute Units), que a su vez estan divididas en elementos
de procesamiento PEs (Processing Elements).
Una aplicacion OpenCL esta conformada por dos tipos de codigos: un codigo de
host que se ejecuta sobre las CPUs de acuerdo al modelo nativo de su plataforma y
un codigo kernel que es suministrado del host a los dispositivos como comandos para
que sean ejecutados por los elementos de procesamiento.
Modelo de ejecucion
El modelo de ejecucion de OpenCL se basa en dos unidades de ejecucion: Un
programa host que se ejecuta en la(s) CPU(s) y un programa kernel que se ejecuta
en el(los) dispositivo(s) OpenCL. El trabajo de computo programado en los kernels
es realizado por ıtems de trabajo, los cuales se reunen en grupos de trabajo para la
ejecucion de dicho trabajo. La interaccion entre el host y los dispositivos se habilita
mediante un contexto y se realiza a traves de comandos.
23
Contexto: Los kernels son ejecutados bajo un ambiente definido por un contexto
el cual es creado y administrado por el host. Dicho ambiente incluye los siguientes
recursos:
Dispositivos: Uno o mas dispositivos OpenCL.
Objetos kernel: Funciones OpenCL (con sus argumentos asociados) que se
ejecutan en los dispositivos.
Objetos programa: Programa fuente y ejecutable que implementa a los kernels.
Objetos memoria: Variables visibles al host y a los dispositivos.
Cola de comandos : El contexto descrito arriba habilita al host para que interactue
con los dispositivos, esta interaccion se realiza mediante una cola de comandos
Figura 2.11: Modelo de plataforma de OpenCL (Vera Parra et al., 2018).
24
(command-queue). Existira una cola de comandos por cada dispositivo con el que
se requiera interactuar. De acuerdo a la funcionalidad cumplida, los comandos son
clasificados en tres tipos: Comandos para poner en cola un kernel que se va a ejecutar
(comandos Kernel-enqueue), comandos para la transferencia de datos (comandos
memory) y comandos para procesos de sincronizacion (comandos synchronization).
Adicional a las colas que reciben los comandos enviados por el host, existen
tambien colas alojadas en el lado de los dispositivos que reciben comando enviados
por un kernel que se encuentre ejecutandose en un dispositivo. Estos comandos son
usados para que un kernel (padre) tenga la capacidad de enviar a ejecucion otro kernel
(hijo).
Todos los comandos, sin importar que provengan del host o de un kernel pasan
por seis estados: en cola (queued), suministrado (submitted), listo (ready), corriendo
(running), finalizado (ended) y completo (complete). Los comandos comunican sus
estados a traves de objetos denominados eventos.
Multiples colas de comandos pueden estar presentes en un mismo contexto y
multiples colas de comandos puede ejecutar comandos de forma independiente. Para
la sincronizacion de comandos provenientes de varias colas el host utiliza los eventos
para definir puntos de sincronıa.
Instancia de un kernel : Se le llama instancia de un kernel a la integracion de 3
componentes: el kernel, los valores de los argumentos asociados a dicho kernel y un
espacio indexado definido cuando el kernel es enviado para su ejecucion.
Cuando una instancia de un kernel es enviada para su ejecucion, cada funcion de
dicho kernel es ejecutada por un punto del espacio indexado definido; estas funciones
son llamadas ıtems de trabajo (work-items) y son integradas en grupos de trabajo
(work-groups) para su administracion por parte del dispositivo. Un ıtem de trabajo
se puede identificar de dos formas: mediante un ID global basado en las coordenadas
dentro del espacio indexado o mediante un ID local a un grupo de trabajo.
Espacio indexado - NDRange: El espacio indexado definido para un kernel en
OpenCL es llamado NDRange y corresponde a un espacio N-dimensional, donde N
25
puede tomar el valor de 1, 2 o 3. El NDRange se conforma de grupos de trabajo
que a su vez estan conformados por ıtems de trabajo. Estos ıtems de trabajo se
pueden sincronizar entre sı exclusivamente entre un mismo grupo de trabajo; la
sincronizacion entre ıtems de diferentes grupos de trabajos es imposible debido al
modelo de memoria, explicado mas adelante. En la figura 5.4 se muestra un ejemplo
de un NDRange con N=2.
Un NDRange es definido por 3 arreglos de enteros, cada uno con tamano N (un
valor por cada dimension):
Un arreglo para indicar el tamano del espacio indexado en cada dimension. En
el ejemplo mostrado en la Figura 2.12 sera un arreglo de dos valores [12,12].
Un arreglo para indicar el valor inicial del ındice en cada dimension. Este arreglo
representa una especie de offset en el ındice de cada dimension (este valor es
denominado F). Por defecto los ındices se inician en cero (0).
Un arreglo para indicar el tamano de los grupos de trabajo en cada una de las
dimensiones. En el ejemplo mostrado en la Figura 2.12 sera un arreglo de dos
valores [4,4].
Figura 2.12: Ejemplo de un NDRange con N=2. (Vera Parra et al., 2018).
26
El ID global de cada uno de los ıtems de trabajo sera una tupla N-dimensional,
con valores en el rango, F a F mas el numero de ıtems en cada dimension menos uno
(1).
El tamano de los grupos de trabajo no necesariamente debe ser el mismo en todas
las dimensiones. En el caso que en alguna de las dimensiones el tamano global no
sea divisible por el tamano del grupo de trabajo se generaran dos regiones, una con
grupos de trabajo con el tamano definido por el programador y otra region con grupos
de trabajo de tamano menor para completar exactamente el tamano global requerido.
Esto se puede presentar en cualquiera de las dimensiones, de tal manera que si se tiene
un arreglo con N = 3, podrıan existir 8 tamanos diferentes de grupos de trabajo.
La forma de identificar cada uno de los ıtems y grupos de trabajo y la forma de
representar los diferentes tamanos en un NDRange es ilustrado en la Figura 2.13.
El ID global de un ıtem de trabajo se puede obtener a partir de su ID local,
siempre y cuando se tenga el offset, el ID y el tamano del grupo de trabajo:
Figura 2.13: Identificadores y tamanos en un NDRange (Vera Parra et al., 2018).
27
(gx, gy) = (wx ∗ Sx+ sx+ Fx,wy ∗ Sy + sy + Fy)
La cantidad de grupos de trabajo puede obtenerse a partir del tamano global y el
tamano del work-group:
(Wx,Wy) = (ceil(Gx/Sx), ceil(Gy/Sy))
Si se desea obtener el ID del work-group al cual pertenece un ıtem de trabajo
se debe contar con el ID global y local del ıtem, con el offset y con el tamano del
work-group:
(wx,wy) = ((gx–sx–Fx)/Sx, (gy–sy–Fy)/Sy)
Modelo de memoria
El modelo de memoria de OpenCL define la estructura, el contenido y el
comportamiento de la memoria expuesta por una plataforma OpenCl y usada por
un programa OpenCL. Este modelo se conforma de 4 componentes:
Regiones de memoria: Las diferentes memorias visibles tanto para el host como
para los dispositivos que tcomparten un contexto.
Objetos de memoria: Es el contenido de la memoria global. Son objetos definidos
por la API de OpenCL.
Memoria Virtual Compartida SVM (Shared Virtual Memory): Es un espacio
virtual direccionado expuesto tanto para el host como para los dispositivos
dentro de un contexto.
Modelo de consistencia: Reglas que definen cuales valores son observados
cuando multiples unidades de ejecucion cargan datos de la memoria. Tambien
se determinan las operaciones atomic/fence que restringen el orden de las
operaciones de memoria y definen las relaciones de sincronizacion.
Regiones de memoria: Desde el punto de vista de OpenCL existen dos tipos de
memoria: Memoria de host y memoria de dispositivo (ver figura 2.14).
28
Memoria de host: Es la memoria directamente disponible para el host (la
estructura y comportamiento de esta memoria no es definida por OpenCL). La
transferencia de objetos de memoria entre el host y los dispositivos se realiza a
traves de funciones de la API de OpenCL o mediante una interfaz de memoria virtual
compartida.
Memoria de dispositivo: Memoria directamente disponible para los kernels ejecu-
tados en un dispositivo OpenCL. La memoria de dispositivo se divide en cuatro (4)
regiones:
Memoria global: Esta region de memoria permite el acceso para lectura/escritura
a todos los ıtems de trabajo de todos los grupos de trabajo que se ejecutan sobre
algun dispositivo dentro de un contexto.
Figura 2.14: Tipos y regiones de memoria desde el punto de vista de OpenCL(Vera Parra et al., 2018).
29
Memoria constante: Una region de la memoria global que se mantiene constante
durante la ejecucion de una instancia de kernel. El host asigna e inicializa objetos
de memoria colocados en la memoria constante.
Memoria local: Una region de memoria local a un grupo de trabajo. Esta region
de memoria se puede utilizar para asignar las variables que son compartidos por
todos los ıtems de trabajo pertenecientes a un grupo.
Memoria privada: Una region de memoria exclusiva a un ıtem de trabajo. Una
variable definida en una memoria privada de un ıtem de trabajo no sera visible
para ningun otro ıtem.
Las memorias locales y privadas siempre estan asociados con un dispositivo
especıfico. Las memorias globales y constantes, se comparten entre todos los
dispositivos dentro de un contexto dado. Un dispositivo de OpenCL puede incluir
una memoria cache para apoyar el acceso eficaz a estas memorias compartidas.
Objetos de memoria: El contenido de la memoria global son objetos de memoria.
OpenCL define tres tipos de objetos de memoria: bufer (buffer), imagen (image) y
tuberıa (pipe).
Bufer: Objeto almacenado como un bloque contiguo de memoria y usado como
un objeto de proposito general para mantener datos en un programa OpenCL.
Los valores almacenados en un bufer pueden ser de tipos primitivos (enteros,
flotantes), vectores o estructuras de datos definidas por el usuario. Un bufer
puede ser manipulado a traves de punteros de forma similar como se manipula
un bloque de memoria en C.
Imagen: Objeto usado para almacenar imagenes de una, dos o tres dimensiones
en los formatos estandar utilizados por las aplicaciones graficas. Un objeto
imagen es un tipo de dato opaco que no puede ser visto directamente a traves
de punteros en el codigo del dispositivo.
30
Tuberıa: Objeto usado para organizar los datos en una estructura de tipo FIFO
(first in, first out) con el proposito de facilitar el paso de datos procesados de
un kernel a otro.
La asignacion y acceso a los objetos de memoria dentro de las diferentes regiones
de memoria varıa entre el host y los ıtems de trabajo ejecutandose sobre un dispositivo
(ver tabla 2.1).
31
Tabla
2.1
:M
odo
com
olo
sob
jeto
sde
mem
oria
son
asig
nad
osy
acce
did
osp
orel
hos
ty/o
una
inst
anci
ade
un
kern
el.
Host
Kern
el
Asi
gnaci
on
Acc
eso
Asi
gnaci
on
Acc
eso
Glo
bal
Asi
gnac
iondin
amic
aA
cces
ode
lect
ura
/esc
ritu
raa
bufe
re
imag
enes
per
ono
atu
ber
ıas.
Asi
gnac
iones
tati
cap
orla
sva
riab
les
del
pro
gram
aA
cces
ode
lect
ura
/esc
ritu
ra
Const
ante
Asi
gnac
ion
din
amic
aA
cces
ode
lect
ura
/esc
ritu
raA
sign
acio
nes
tati
ca.
Acc
esoa
solo
lect
ura
Loca
lA
sign
acio
ndin
amic
aSin
acce
soA
sign
acio
nes
tati
ca.
Asi
gnac
iondin
amic
apar
ake
rnel
hij
os
Acc
eso
de
lect
ura
/esc
ritu
ra.
Sin
acce
soa
mem
oria
loca
lde
kern
elhij
osP
rivada
Asi
gnac
ion
din
amic
aSin
acce
soA
sign
acio
nes
tati
ca.
Acc
eso
de
lect
ura
/esc
ritu
ra
32
Memoria virtual compartida (SVM - Shared Virtual Memory): Una de las grandes
novedades de OpenCL 2.0 es el soporte a una memoria virtual compartida, llamada
SVM por su sigla en ingles. SVM extiende la region de memoria global dentro de la
memoria de host, permitiendo el direccionamiento virtual compartido entre el host y
todos los dispositivos dentro de un contexto.
Hay tres tipos de SVM definidos por OpenCL:
SVM - Bufer de grano grueso: Permite que el direccionamiento virtual compar-
tido ocurra con una granularidad de objetos de memoria bufer; esto es similar
a lo que se hacıa sin contar con una SVM. La diferencia entre un SVM bufer de
grano grueso y un No-SVM bufer es simplemente que el host y los dispositivos
comparten punteros de memoria virtual.
SVM - Bufer de grano fino: Permite que el direccionamiento virtual compartido
ocurra con una granularidad de cargas o almacenamientos individuales dentro
de los bytes de un objeto de memoria bufer.
SVM - Sistema de grano fino: Permite que el direccionamiento virtual compar-
tido ocurra con una granularidad de cargas o almacenamientos dentro de los
bytes en cualquier parte de la memoria de host.
En la tabla 2.2 se realiza un resumen de los tipos de SVM y sus principales
caracterısticas, tales como la granularidad de lo compartido, el modo de asignacion
de memoria y el mecanismo para asegurar la consistencia.
33
Tabla
2.2
:T
ipos
de
SV
My
sus
pri
nci
pal
esca
ract
erıs
tica
s.
Gra
nula
ridad
de
loco
mpart
ido
Modo
de
asi
gnaci
on
de
mem
ori
aM
eca
nis
mo
para
ase
gura
rla
consi
stenci
a
Act
ualiza
ciones
explı
cita
sentr
eel
host
ylo
sdis
posi
tivos?
Bufe
rN
o-S
VM
Ob
jeto
sd
em
emor
iaO
pen
CL
(bu
fer)
clC
reat
eBu
ffer
(fu
nci
onqu
ecr
eau
nob
jeto
de
mem
oria
bu
fer)
Pu
nto
sd
esi
ncr
oniz
acio
nd
elh
ost
sob
reel
mis
mo
oen
tre
dis
pos
itiv
os
Si,
atr
aves
de
com
and
osM
apy
Un
map
SV
M-
Bufe
rde
gra
no
gru
eso
Ob
jeto
sd
em
emor
iaO
pen
CL
(bu
fer)
clS
VM
All
oc
fun
cion
par
aas
ign
aru
nbu
fer
SV
M,
qu
ep
ued
ese
rco
mpar
tid
op
orel
hos
ty
tod
oslo
sd
isp
osit
ivos
enu
nco
nte
xto
Op
enC
L)
Pu
nto
sd
esi
ncr
oniz
acio
nd
elh
ost
entr
ed
isp
osit
ivos
Si,
atr
aves
de
com
and
osM
apy
Un
map
SV
M-
Bufe
rde
gra
no
fino
Byte
sd
entr
od
elo
sob
jeto
sd
em
emor
iaO
pen
CL
(bu
fer)
clS
VM
All
oc
Pu
nto
sd
esi
ncr
oniz
acio
nm
asop
erac
ion
esat
omic
sN
o
SV
M-
Sis
tem
ade
gra
no
fino
Byte
sd
entr
od
ela
mem
oria
de
hos
t(s
iste
ma)
Mec
anis
mos
par
aas
ign
arm
emor
iad
ehos
t(E
j:m
allo
c)P
unto
sd
esi
ncr
oniz
acio
nm
asop
erac
ion
esat
omic
sN
o
34
2.2.3. Fundamentos de CUDA
CUDA es una plataforma de computacion paralela de proposito general y un
modelo de programacion. Su principal objetivo es habilitar el uso de GPUs NVIDIA
para soluciona problemas computacionales complejos de una forma mas eficiente que
como se hace sobre una CPU Cuda (2015). CUDA incluye un entorno de software que
permite a los desarrolladores usar C como un lenguaje de alto nivel. Tambien soporta
otros lenguajes de programacion y APIs como se puede observar en la figura 2.15.
Modelo de programacion de CUDA
El modelo de programacion de CUDA se soporta sobre 3 abstracciones claves:
jerarquıa de grupos de hilos, memorias compartidas y barreras de sincronizacion,
que se presentan al programador como un conjunto mınimo de extensiones de
Figura 2.15: Lenguajes de programacion y APIs soportadas por CUDA. (Cuda,2015)
35
lenguaje. Estas abstracciones guıan al programador a dividir el problema en sub-
problemas gruesos que pueden resolverse de forma independiente en paralelo mediante
bloques de hilos, y cada sub-problema en piezas mas finas que se pueden resolver
cooperativamente en paralelo por todos los hilos dentro del bloque.
El modelo es escalable de forma automatica, en el sentido que los bloques de hilos
no van sujetos al numero de multiprocesadores de la GPU. La ejecucion de los bloques
se adapta al numero de multiprocesadores disponibles. Ver figura 2.16.
Kernels : CUDA extiende C de tal forma que el programador pueda definir
funciones denominadas kernels, que cuando sean llamadas, se ejecuten N veces en
paralelo por N diferentes Hilos CUDA. El numero de hilos a ejecutar la funcion se
define en el momento de llamar el kernel. En la figura 2.17 se puede observar un
ejemplo de definicion y llamado de un kernel.
Figura 2.16: Escalabilidad automatica de CUDA: Los bloques de hilos se distribuyende forma homogenea entre los SMs (Stream Multiprocessors). (Cuda, 2015)
36
Jerarquıa de hilos : En CUDA los hilos se pueden agrupar en bloques de 1, 2
o 3 dimensiones y a su vez esos bloques se pueden agrupar en mallas de 1, 2 o
3 dimensiones. En la figura 2.18 se puede observar una grilla de 2 dimensiones
conformada por bloques de hilos tambien de 2 dimensiones.
El numero de hilos por bloque y el numero de bloques por malla se determinan
en el momento de llamar el kernel. Dentro del kernel tanto los bloques como los hilos
tienen un identificador que se puede acceder a traves de una variable (built-in). Para
el caso de los bloques la variable es blockIdx y para el caso de los hilos es threadIdx.
Adicionalmente se puede acceder a la dimension de los bloques mediante la variable
blockDim.
En el ejemplo de la figura 2.19 se definen bloques de tamano 16x16 (256 hilos), que
se agrupan en una malla bidimensional definida de tal forma que hallan suficientes
bloques como para disponer de un hilo por cada elemento de la matriz a procesar.
Jerarquıa de memoria: Las memorias con las cuales se cuenta en CUDA se
organizan de forma jerarquica de acuerdo a su visibilidad. Cada hilo tiene una
memoria privada de uso exclusivo, cada bloque de hilos tiene una memoria compartida
Figura 2.17: Ejemplo de definicion y llamado de un kernel (Cuda, 2015).
37
a la cual pueden acceder todos los hilos de un bloque pero no los de otros bloques, por
ultimo todos los hilos sin importar de que bloque sean pueden acceder a una memoria
denominada global. Adicional a esta memoria global existen otras dos memorias de
acceso general para todos los hilos pero unicamente para su lectura, estas memoras
son la de textura y la constante.
En la figura 2.20 se pueden observar los diferentes tipos de memoria en CUDA
con su visibilidad por parte de los hilos, los bloques y las mallas.
Programacion heterogenea: El modelo de programacion de CUDA asume que sus
hilos se ejecutan en un dispositivo separado fısicamente que actua como co-procesador
del host donde se ejecuta el programa C desde el cual se llaman los kernels. Para el
caso de tener una CPU y una GPU, esta ultima actuara como co-procesador del host
CPU.
El modelo tambien asume que tanto la GPU como la CPU poseen su propio espacio
de memoria independiente en la DRAM y se refiere a estos espacios como memoria de
Figura 2.18: Malla de bloques de hilos (Cuda, 2015).
38
dispositivo y memoria de host respectivamente. En la figura 2.21 se puede observar
el concepto de programacion heterogenea: un programa en C que ejecuta de forma
secuencial codigo serial que es ejecutado en el host y codigo paralelo que es ejecutado
en el dispositivo (GPU).
2.3. Estandares y modelos computacionales para
el procesamiento algebraico lineal
2.3.1. BLAS
BLAS (Basic Linear Algebra Subprograms) es una especificacion que describe
un conjunto de operaciones de fundamentales de algebra lineal. Algunas de las
Figura 2.19: Ejemplo de definicion y llamado de un kernel con una mallabidimensional conformada por bloques bidimensionales de hilos. (Cuda, 2015)
39
operaciones definidas en esta especificacion son: adicion de vectores, multiplicacion
de escalares, productos punto, combinaciones lineales, entre otras
Los subprogramas BLAS estan clasificados en 3 niveles que corresponden al orden
cronologico de la publicacion y la complejidad de las operaciones.
Nivel 1
Este nivel define solo operaciones vector-vector y fue publicado en la presentacion
original de blast (1979)Lawson et al. (1979) . Algunas de las operaciones definidas
en este nivel son: Suma de vectores (axpy), producto punto (dot), multiplicacion por
constante (scal), entre otras.
Nivel 2
Este nivel define operaciones matriz - vector y fue publicado en 1988Dongarra
et al. (1988). Algunas de las operaciones definidas son: producto matriz-vector (gemv),
Figura 2.20: Jerarquıa de memoria en CUDA (Cuda, 2015).
40
solucionador de un sistema de ecuaciones lineales con una matriz triangular (tbsv),
entre otros BLAS (2018).
Nivel 3
Este nivel define operaciones matriz-matriz y fue publicado en 1990. Algunas de las
operaciones definidas son: producto matriz-matriz (gemm), multiplicacion de matrices
cuando una matriz es simetrica (symm), entre otros.
2.3.2. Implementaciones de BLAS
Aunque no es un estandar esta especificacion es el estandar de facto en cuanto
a rutinas de bajo nivel en bibliotecas de algebra lineal. Aunque la especificacion es
general, las implementaciones de esta a menudo son optimizadas para adaptarse y
aprovechar algunas caracterısticas de diferentes arquitecturas de computo con el fin
Figura 2.21: Programacion heterogenea (Cuda, 2015).
41
de mejorar la velocidad de procesamiento. Algunas de las implementaciones de BLAS
son:
ACML:AMD Core Math Library. Disenada para procesadores AMD Athlon y
Opteron. No es actualmente mantenida por AMD.
ATLAS : Automatically Tuned Linear Algebra Software. Es una implementacion
Open Source para C y Fortran 77. Una de las principales caracteristicas es que
es portable y optimiza su ejecucion para una arquitectura especifica.
cuBLAS : Implementacion de BLAS optimizada para GPUs NVIDIA.
clBLAS : Implementacion de BLAS en OpenCL.
Intel MKL: Intel Math Kernel Library. Soporta arquitecturas de 32 y 64 bits.
Incluye optimizaciones para procesadores Intel Pentium, Xeon, Xeon Phi.
Netlib BLAS : Implementacion oficial de referencia. Esta escrita en Fortran 77.
Sun Performance Library : Implementacion de BLAS optimizada para arquitec-
turasD SPARC, AMD64 y Core. Funciona bajo Solaris y Linux.
2.3.3. CUBLAS
La biblioteca Nvidia CUBLAS es una implementacion acelerada mediante GPU
(funciona sobre Nvidia CUDA) de BLAS. Esta implementacion permite hacer uso de
los recursos computacionales de las GPU (Graphic Processing Unit) NVIDIA Nvidia
(2018b).
Estructuras de datos
CUBLAS usa una estructura de datos column-major.el cual es uno de los metodos
para almacenar arreglos multidimensionales es un almacenamiento lineal (como en el
caso de la memoria RAM).
42
En el orden column-major, los elementos de la misma columna quedan alma-
cenados en secciones contiguas de la memoria. En el caso del orden row-major los
elementos de la misma fila quedan contiguos en la memoria.
En la figura 2.22 muestra la estructura de almacenamiento column-major 2.order-
major”.
Este orden de datos de la una mayor compatibilidad con la implementacion
original de BLAS en Fortran. Sin embargo, dado que C y C++ usan row-major las
aplicaciones implementadas no pueden hacer uso de la semantica nativa para arrays
multidimensionales.
Otras caracteristicas
CUBLAS no solo cuenta con subrutinas de BLAS. Adicionalmente, incluye algunas
subrutinas similares a BLAS y que extienden su funcionalidad. Incluye subrutinas
como: Escalar dos vectores y sumarlos (axpby) , calcular la factorizacion LU (Lower
Figura 2.22: Programacion heterogenea (Wikipedia, 2018).
43
and Upper) de una matriz (getrf), calcular inversa de una matriz LU(getri), entre
otros.
Ademas de contar con la implementacion de las rutinas BLAS, CUBLAS cuenta
implementaciones ”batch”de algunas de dichas subrutinas. Estas implementaciones
permiten hacer uso del poder de computo paralelo SIMD de las GPU NVIDIA
mediante la ejecucion de algunas operaciones de manera masiva, es decir, procesando
varias matrices o vectores en la misma operacion. Algunas de las subrutinas
que cuentan con implementacion batched son: Factorizacion QR (geqrfBatched),
Factorizacion LU(getrfBatched), multiplicacion de matrices(gemmBatched), calculo
de la inversa de una matriz LU (getriBatched).
2.3.4. Intel MKL
Intel MKL (Math Kernel Library) es una biblioteca que contiene rutinas de
matematica con codigo optimizado para correr en las nuevas generaciones de
procesadores Intel. Aunque esta libreria es de Intel tambien permite ser ejecuta
en procesadores no Intel. sEsta biblioteca contiene rutinas optimizadas de BLAS,
LAPACK, FFTs (Transformada rapida de fourier), entre otras.
Paralelismo
Las mejoras de desempeno de Intel MKL se deben gracias al paralelismo proveido
por SMP (Symmetric Multiprocessing Performance). Este tipo de procesamiento se
produce cuando dos o mas procesadores identicos estan connectados y pueden accede
a la misma memoria principal.
Existen varias formas de explotar las capacidad de computo paralelo en esta
biblioteca:
El usuario puede administrar los hilos en el programa y distribuir las operaciones
en los hilos basado en descomposicion de datos, descomposicion por dominio
o alguna otra tecnica de paralelizacion. Cada hilo puede usar por separado
44
cualquier funcion disponible en MKL dado que esta biblioteca esta disenada
para ser thread-safe (cada hilo funciona correctamente durante la ejecucion
simultanea en muchos hilos)
Mediante el uso de FFT y las rutinas BLAS nivel 3. Estas implementaciones
han sido paralelizadas y no requieren ser alteradas para aprovechar las mejoras
de multiprocessin. Dado que los hilos son llamados y administrados por MKL,
la aplicacion no necesita ser recompilada para ser thread-safe.
Mediante el uso de rutinas de LACPACK. Estas rutinas estan implementadas
para el procesamiento de precision simple y doble.
https://software.intel.com/en-us/mkl-developer-reference-c-parallelism
2.3.5. clMathLibraries
clMathLibraries es un conjunto de rutinas matematicas que estan disenadas
para ser ejecutadas sobre OpenCL. clMathLibraries esta compuesto de las siguientes
implementaciones:
clFFT : Biblioteca que contiene funciones de la transformada rapida de fourier
(FFT). Esta biblioteca esta optimizada para ejecutarse sobre procesadores grafi-
cos AMD. Esta biblioteca provee soporte para transformaciones 1D, 2D, 3D y
adicionalmente permite procesamiento en batch. https://github.com/clMathLibraries/clFFT
clBLAS : Biblioteca que contiene implementaciones de rutinas BLAS para ser
ejecutadas en OpenLC. Esta biblioteca contiene implementaciones BLAS nivel
1, 2 y 3. clBLAS no oculta or envuelve las interfaces de OpenCL, por lo tanto
permite a usuario(desarrollador) la adminitracion del estado de OpenCL Knox
et al. (2018).
clRNG : Libreria que contiene metodos para la generacion uniforme de numeros
aleatorios L’Ecuyer et al. (2015).
45
clSPARSE :Libreria que contine implementaciones de BLAS para el tratamiento
de matrices y vectores esparcidos (que contienen gran cantidad de ceros)
Greathouse et al. (2016).
46
Capıtulo 3
Estado del arte
3.0.1. ¿Que antecedentes existen de soluciones de aceleracion
para la obtencion de modelos de clasificacion y/o
prediccion en la ciencia de datos?
En los anos recientes se han hecho algunos avances en cuanto al analisis de datos
con arquitecturas heterogeneas. Sin embargo, debido a la amplitud del campo cada
uno de los avances se concentra en procedimientos especıficos. A continuacion se listan
algunos de los procedimientos implementados:
Implementacion de bosques y arboles de decision
Sharp (2008), sin que en el momento existiera OpenCL, logro hacer una
implementacion de arboles y bosques de decision para el contexto de reconocimiento
de objetos. Para realizar esto, los autores mapean la estructura de datos de un
bosque de decision sobre array de texturas 2D. Posteriormente se navega a traves
del bosque para cada punto en los datos de entrada en paralelo haciendo uso de un
pixel shader. Para entrenar el bosque se calculan las respuestas del data set de entrada
a un conjunto de caracterısticas candidatas. Cuando se evaluo la herramienta para
47
reconocimiento de objetos se encontro que los resultados son identicos a los obtenidos
por CPU, pero solo usando el 1
Analisis de componentes principales (PCA) en OpenCL
Bowden (2010) implemento un algoritmo en OpenCL para el analisis de componen-
tes principales (PCA). El algoritmo usado para dicho analisis fue NIPALS (Nonlinear
estimation by Iterative Partial Least Square). En esta implementacion y artıculo se
muestran los tiempos requeridos por iteracion para problemas de diferentes tamanos
definidos. Adicionalmente se discuten varios pasos para la optimizacion del codigo,
migrando del uso de una sola GPU al uso de varias GPUs en el mismo nodo, y desde
ahı hacia multiples GPUs en diferentes nodos.
Mapas auto organizados de Kohonen
Los mapas autoorganizados de Kohonen son variantes de las redes neuronales
artificiales; en este caso las redes poseen un aprendizaje no supervisado competitivo.
(McConnell et al., 2012) hacen la implementacion de mapas autoorganizados de
Kohonen con OpenCL y CUDA hallando aceleraciones de 3 a 32 veces comparado
con el enfoque tradicional.
Algoritmos de agrupamiento
Los algoritmos de agrupamiento, (por ejemplo, el de busqueda del k vecino mas
cercano - KNN) son problemas bien conocidos asociados con muchas aplicaciones
tales como la clasificacion, estimacion de propiedades estadısticas, etc. El problema es
que el tamano del tiempo de computo tiene un crecimiento polinomico dependiendo
del tamano del set de datos. (Garcia et al., 2008) implementaron el algoritmo del
”k vecino mas cercano”haciendo uso de CUDA. Los resultados muestran que para
esta aplicacion es especıfico se lograron factores de aceleracion de hasta 120 veces.
Otros autores como Kohlhoff et al. (2011), implementaron una biblioteca informatica
48
llamada CAMPAIGN de codigo abierta con algoritmos de analisis mediante agrupa-
miento (clustering). CAMPAIGN esta escrita en C para CUDA”para GPUs Nvidia.
Esta librerıa provee aceleracion de 2 ordenes de magnitud respecto a algoritmos de
agrupamiento basados en CPU. Algunos de los algoritmos implementados son: k –
means, k-medoids k-centers (una variante de K-medoids), agrupamiento jerarquico y
mapas autorganizado de Kohonen.
Monte Carlo en OpenCL
Lee et al. (2010) hicieron la implementacion para algunas clases de algoritmos de
Monte Carlo en los cuales es posible paralelizar la simulacion. En un set canonico
de simulaciones estocasticas, incluyendo metodos de cadena de Markov Monte Carlo
(MCMC) basados en poblaciones, se encontro aceleraciones desde 35 hasta 500 veces
comparado con la ejecucion tradicional en un nodo de computo. Algebra Lineal usando
OpenCL Rup et al (2010) proponen ViennaCL. VienaCL es una librerıa de algebra
lınea de codigo abierto para realizar calculos en arquitecturas de varios nucleos (GPUs,
MIC) y procesadores multi-core. La librerıa esta escrita en C++ y soporta CUDA,
OpenCL y OpenMP. Esta librerıa habilita de manera simple y a alto nivel el acceso
a amplios recursos computacionales en arquitecturas paralelas tales como GPUs y
esta principalmente enfocada a operaciones comunes de algebra lineal (BLAS nivel 1,
2 y 3). Tambien provee solucionadores iterativos con precondiciones opcionales para
sistemas de ecuaciones grandes. Algunas de las operaciones provistas por ViennaCL
y que pueden ser de utilidad para el desarrollo de este proyecto son: multiplicacion
de matrices, traspuesta de matrices, inversa de matrices, operaciones con numeros
escalares y solucion de sistemas de ecuaciones lineales.
49
Capıtulo 4
HMMMR (Heterogeneous Model
for Massive Multilinear
Regressions)
HMMMR (Heterogeneous Model for Massive Multilinear Regressions) es un
modelo que permite calcular regresiones lineales multivariables masivamente de
manera eficiente haciendo uso de computacion heterogenea (procesamiento multi-core
y many-core).
El objetivo principal de HMMMR es hacer una seleccion de un subconjunto
de predictores que presenten mejores resultados en una regresion lineal para una
determinada variable objetivo.
HMMMR como se ve en la Figura 4.1 esta disenado para ejecutarse en plataformas
multi-core/many-core. Cada una de las etapas esta disenada para ejecutarse de
manera eficiente en la plataforma adecuada. Adicionalmente, HMMMR cuenta con
estructuras de datos disenadas para ser procesadas en lotes con el fin de optimizar el
uso de los recursos computacionales.
Como se ve en la Figura 4.1 se divide a grandes rasgos en 3 etapas de
procesamiento: Multi-core I, Many-core y Multi-core II.
50
La etapa multi-core I se encarga principalmente de realizar la carga de datos desde
un archivo (A), generar las combinatorias de posibles modelos usando i predictores
(B), calcular el tamano maximo de batch (C) y generar las matrices de entrada con
los datos a procesar en la plataforma many-core (D). Durante esta etapa se itera
desde 1 hasta el maximo de predictores mp a evaluar, generando matrices de iguales
dimensiones por cada modelo a evaluar cuando se usan i predictores. La importancia
Figura 4.1: Flujo de datos HMMMR
51
de agrupar estos datos de entrada usando matrices de dimensiones similares radica
en poder hacer uso de las capacidades de procesamiento en batch de la plataforma
many-core. Cuando el numero total de regresiones a evaluar excede el tamano maximo
del batch nbi > 1, esta etapa tambien se hace cargo de generar los datos de entrada
por cada batch a procesar. Los detalles de esta etapa pueden ser vistos en la seccion
4.1.
La etapa many-core es la que conlleva mayor esfuerzo de procesamiento ya que
se encarga del calculo de las regresiones y sus metricas. Durante esta por cada batch
de regresiones producido por la etapa multi-core I se hace inicialmente el calculo de
los coeficientes de las regresiones (E) y con dichos coeficientes se calculan los valores
pronosticados (F) para finalmente evaluar el desempeno de las regresiones (G). Los
detalles de esta etapa pueden ser vistos en la seccion 4.2.
La etapa multi-core II recibe las regresiones y sus metricas que fueron calculadas
durante la etapa many-core con el fin de realizar un filtro de los modelos descartados
(H) y posteriormente realizar la seleccion de los mejores modelos (I). Los detalles de
esta etapa pueden ser vistos en la seccion 4.3.
4.1. Procesamiento multi-core I
A) Carga de datos de entrada
En este proceso los datos son cargados desde un archivo en formato CSV en el
cual cada columna corresponde a una de las variables (predictores y objetivo) . Este
archivo debe contener np+1 columnas donde np es el numero de predictores. El
numero de filas de este archivo corresponde al numero de observaciones n.
Las primeras np columnas de este archivo corresponden a los datos de los
predictores y la ultima columna corresponde a los datos de la variable objetivo (Ver
figura 4.2).
Los datos extraıdos del archivo CSV son almacenados en dos estructuras de datos:
52
Matriz de datos de predictores
X =
x(1,1) x(2,1) x(3,1) . . . x(np,1) 1
x(1,2) x(2,2) x(3,2) . . . x(np,2) 1...
......
. . ....
...
x(1,n−1) x(2,n−1) x(3,n−1) . . . x(np,n−1) 1
x(1,n) x(2,n) x(3,n) . . . x(np,n) 1
Figura 4.2: Ejemplo de archivo de archivo de entrada
53
X es una matriz compuesta de p + 1 columnas y n filas, donde p es el numero total
de posibles variables predictoras y n es el numero de observaciones. Las primeras
p columnas de la matriz contienen los datos de las variables predictoras. La ultima
columna es anadida durante el proceso carga de datos y corresponde a un vector de
unos que se usa de apoyo en caso de que se requiera anadir una constate al modelo.
Vector de datos de la variable objetivo
Y =
y1
y2...
yn−1
yn
El vector Y contiene n observaciones de la variable objetivo.
B) Generacion de combinatorias de predictores
En cada iteracion i de este proceso se construyen todos los posibles modelos de re-
gresion Mi a evaluar que contengan un mismo numero de predictores correspondiente
a i. Este proceso se ejecuta mp veces, donde mp es el numero maximo de predictores
a evaluar.
Mi =
(P
i
)Por cada iteracion i son generados Si posibles modelos donde:
Si =|np|!
i!(|np| − i)!
Cada una de las combinaciones de predictores generadas corresponde a un posible
modelo m(i,n) donde i es el numero de predictores usado en cada iteracion y n es el
ındice del modelo en el conjunto de modelos de i predictores.
m(i,n) = [P1, P2, ..., Pi]
54
En caso de que se requiera anadir una constante al modelo, a todo modelo m(i,n)
se le agregara la constante 1 a su conjunto de predictores.
m(i,n) = [P1, P2, ..., Pi,1]
El conjunto de modelos Mi son los modelos posibles generados durante la iteracion
i y estos a su vez son el insumo para la generacion de las matrices de entrada.
Mi =
m(i,1)
m(i,2)
...
m(i,Si−1)
m(i,Si)
C) Calculo del tamano maximo de batch
Para hacer un uso optimo de las capacidades de computo en lote que provee la
GPU es necesario determinar el numero de regresiones que puede hacer al tiempo este
dispositivo. Este numero depende directamente de la memoria disponible en la GPU
y se determina en funcion de las estructuras de datos de entrada, intermedias y de
salida que estaran en la GPU durante el proceso del calculo de los coeficientes y las
metricas de las regresiones.
A continuacion se listan las variables que se deben almacenar en memoria y la
cantidad de numeros escalares que contiene cada una de ellas. En la siguiente lista n
corresponde al numero de observaciones y p al numero de predictores que se usaran
en las regresiones.
Estructuras de datos de entrada
X: Matriz con datos de predictores. Card(X) = (n ∗ p)
XT : Matriz transpuesta de datos de predictores.Card(XT ) = (p ∗ n)
Y : Vector de datos observados de la variable objetivo.Card(Y ) = (n)
55
Estructuras de datos intermedias
XTX: Producto de XT con X. Card(XTX) = (p ∗ p).
XTY : Producto de XT con Y. Card(XTY ) = (p).
(XTX)−1: Inversa del producto de XT con X. Card((XTX)−1) = (p ∗ p).
Estructuras de datos de salida
Metric: Valor escalar con el valor de la metrica.
B: Coeficientes beta. Card(B) = (p)
Y . Vector de resultados de la regresion. Card(Y ) = (n)
Teniendo en cuenta las estructuras de datos a usar en el proceso, es posible
calcular el numero total de numeros escalares y los bytes en memoria requeridos por
cada regresion. Cabe tener en cuenta que los posibles tipos de datos para almacenar
estos valores escalares son float32 y float64 siendo sus tamanos 4 bytes y 8 bytes
respectivamente.
spr = Card(X) + Card(XT ) + Card(Y ) + Card(XTX) + Card(XTY ) +
Card((XTX)−1) + Card(Metric) + Card(B) + Card(Y )
spr = np+ np+ n+ p2 + p+ p2 + 1 + p+ n
spr = 2np+ 2n+ 2p2 + 2p+ 1
bpr = spr ∗ bps
En donde:
bpr: Bytes requeridos por cada regresion
spr: Numero de escalares por cada regresion
bps: Numero de bytes por escalar.
Sabiendo de antemano la cantidad de bytes que requerira cada regresion (bpr) y
la cantidad de memoria disponible en gpu (mgpu) , se realiza el calculo del tamano
de lote optimo (mbs) aproximando el numero a un multiplo de 1000.
56
mbs = (mgpu/bps)− ((mgpu/bps)mod1000)
En donde:
mgpu: Memoria en bytes disponible en GPU.
mbs: Tamano maximo del batch.
Es posible tambien determinar el numero de batches nb que se requerira para
procesar Si regresiones para i predictores.
nb = Si/mbs
Nota: Para las siguientes secciones de este capitulo se asume mbs > Si y nb = 1,
es decir, el tamano del batch maximo (mbs) es menor que el numero de regresiones
posibles para i predictores y por ende todas las regresiones pueden ser procesadas en
un solo batch.
Cabe aclarar que la implementacion del modelo si considera los casos donde mbs <
Si y nb > 1, en dicho escenario se hace necesario repetir los procesos (D, E, F, G, H)
en lotes de maximo mbs regresiones por iteracion.
D) Generacion de matrices de entrada
Durante este proceso se extraen los datos de los predictores para cada uno de las
posibles combinatorias de modelos m(i,n), cada una de estas posibles combinatorias
de modelos produce a su vez una matriz Xm(i,n)conteniendo los datos del modelo a
evaluar.
Xm(i,n)=
x(P1,1) .. x(Pi,1) 1
x(P1,2) .. x(Pi,2) 1...
. . . .....
x(P1,n−1) .. x(Pi,n−1) 1
x(P1,n) .. x(Pi,n) 1
57
Una vez se produce cada matriz de entrada Xm(i,n)para todos los modelos en Mi,
las matrices son organizadas unas sobre otras en una estructura de datos vectorial.
XMi=
Xm(i,1)
Xm(i,2)
...
Xm(i,Si−1)
Xm(i,Si)
Notese que en la matriz XMi
todos los modelos contienen el mismo numero de
predictores. La importancia de usar el mismo numero de predictores radica en poder
organizar los datos de entrada de cada modelo en una estructura de datos que haga
uso eficiente de memoria y que permita ser procesada en lotes.
Dado que el primer paso para realizar una regresion requiere multiplicar la matriz
Xm(i,n)por su transpuesta, es necesario generar dichos datos. Para este proceso, se
transponen cada una de las matrices Xm(i,n)dando lugar al vector de matrices XT
Mi.
XTMi
=
XTm(i,1)
XTm(i,2)
...
XTm(i,Si−1)
XTm(i,Si)
Tambien se hace necesaria la generacion del vector de la variable objetivo. Dado
que siempre se tiene la misma variable objetivo para cada posible modelo, basta con
usar un vector conteniendo Si veces el vector de la variable objetivo.
YMi=
Y
Y...
Y
Y
58
En este punto ya se cuenta con los datos de entrada para procesar las regresiones
de manera paralela en GPU.
4.2. Procesamiento many-core
E) Calculo de coeficientes en batch
Durante este proceso se calculan los coeficientes de regresion (β) de cada uno de
las posibles combinaciones de modelos. Para calcular dichos coeficientes se hace uso
de la formula:
β = (XTX)−1XTY
Las operaciones que se realizan en este proceso estan definidas en BLAS y
LAPACK, por tanto librerıas de procesamiento matematico como MKL (Math kernel
library) de Intel y Cublas de Nvidia contienen implementaciones eficientes adaptadas
al set de instrucciones del procesador de cada fabricante. Cabe aclarar que para aplicar
el modelo propuesto en el presente trabajo, dichas librerıas deben contar con soporte
de procesamiento en lote (Como lo hacen la anteriormente mencionadas).
Inicialmente las matrices XMi, XT
Miy YMi
son copiadas desde la memoria del host
hacia la memoria de la GPU.
A continuacion se realiza la multiplicacion de matrices entre (XMi, XT
Mi) y (
XTMi
, YMi), para esta operacion se hace uso de la subrutina GEMM (General Matrix
Multiply) del estandar BLAS en su version en lote, esto permite realizar paralelamente
esta operacion.
XTMiXMi
=
XTm(i,1)
Xm(i,1)
XTm(i,2)
Xm(i,2)
...
XTm(i,Si−1)
Xm(i,Si−1)
XTm(i,Si)
Xm(i,Si)
59
XTMiYMi
=
XTm(i,1)
Y
XTm(i,2)
Y...
XTm(i,Si−1)
Y
XTm(i,Si)
Y
En la siguiente paso se realiza el calculo de la inversa para cada uno de los
productos XTm(i,j)
Xm(i,j)que fueron calculados en el paso anterior. Esta operacion
se realiza mediante factorizacion LU (O descomposicion lower-upper) a traves de las
subrutinas getrf y getri defininas por LAPACK pero en su version batched.
(XTMiXMi
)−1 =
(XTm(i,1)
Xm(i,1))−1
(XTm(i,2)
Xm(i,2))−1
...
(XTm(i,Si−1)
Xm(i,Si−1))−1
(XTm(i,Si)
Xm(i,Si))−1
Cabe notar que todas las matrices a las cuales se les esta calculando inversa
son cuadradas. Sin embargo, no todas ellas son invertibles, esto dado que la matriz
puede ser singular debido a colinealidad entre los datos. Para detectar dichos casos la
definicion subrutinas getrf y getri de LAPACK que especifican un codigo de retorno
en caso de que no haya sido posible calcular la inversa de la matriz, este codigo de
retorno posteriormente sera usado para hacer el filtro de modelos no validos.
Finalmente, se realiza el producto entre (XTm(i,j)
Xm(i,j))−1 y XT
m(i,j)Y para cada
modelo m(i,j) con el fin de obtener los coeficientes de la regresion Bm(i,j).
Bm(i,j)= (XT
m(i,j),Xm(i,j)
)−1XTm(i,j)
Y
El resultado de la anterior operacion es un vector BMide vectores Bmi,j
que
contiene los coeficientes para el modelo m(i,j).
60
BMi=
(XTm(i,1)
Xm(i,1))−1XT
m(i,1)Y
(XTm(i,2)
Xm(i,2))−1XT
m(i,2)Y
...
(XTm(i,Si−1)
Xm(i,Si−1))−1XTY
(XTm(i,Si)
Xm(i,Si))−1XT
m(i,Si)Y
=
Bm(i,1)
Bm(i,2)
...
Bm(i,Si−1)
Bm(i,Si)
En este punto del proceso ya se cuenta con los coeficientes beta correspondientes
a cada modelo m(i,j).
F) Calculo de Ys pronosticados
En este proceso se calculan los valores pronosticados a partir de los coeficientes
calculados para cada uno de los modelos.
Para calcular los valores pronosticados Y basta con multiplicar la matriz
conteniendo los datos de los predictores por los coeficientes del modelo.
Ym(i,j)= Xm(i,j)
Bm(i,j)
Este proceso se hace en lote para cada uno de los modelos produciendo como
resultado el vector YMique contiene a su vez vectores con los datos calculados haciendo
uso de los coeficientes.
YMi=
Xm(i,1)Bm(i,1)
Xm(i,2)Bm(i,2)
...
Xm(i,Si−1)Bm(i,Si−1)
Xm(i,Si)Bm(i,Si)
=
Ym(i,1)
Ym(i,2)
...
Ym(i,Si−1)
Ym(i,Si)
Estos valores posteriormente seran usados para el calculo de alguna metrica de
desempeno del modelo, en este caso se usara RMSE para evaluar el modelo.
61
G) Calculo de metrica de desempeno
En este proceso se usan los valores observados Y y los valores pronosticados Y
para evaluar la precision del modelo. En el presente modelo la metrica escogida para
calcular la precision del modelo fue RMSE (Error medio cuadratico) que indica que
tan cerca estan los datos pronosticados a los datos reales, sin embargo es posible
implementar otro tipo de metrica que se quiera evaluar.
RMSE =
√∑ni=1(yi − yi)2
n
El primer paso para el calculo del RMSE es el calculo del cuadrado de la diferencia
de los valores observados contra los valores pronosticados. El calculo de la diferencia
se hace a traves de la subrutina axpy definida en el estandar BLAS. Para el calculo de
los cuadrados se implemento un kernel que calcula el cuadrado elemento a elemento.
Cabe notar que en este caso no es necesario que la operacion se haga de manera batch,
ya que solo hay una dimension de datos y la operacion se hara elemento a elemento.
Y − Y =
(ym(i,1)1
− y1)2
(ym(i,1)2 − y2)2
(ym(i,1)3 − y3)2
...
(ym(i,Si)1 − y1)2
(ym(i,Si)2 − y2)2
(ym(i,Si)3 − y3)2
Una vez se cuenta con la diferencia de cuadrados, es necesaria hacer la sumatoria
de las diferencias para cada modelo. Dado que las diferencias al cuadrado de todos
los modelos se encuentran en el mismo vector, es necesario calcular cada una
de las sumatorias independientemente. Este problema de la sumatoria, puede ser
solucionado en lote mediante la multiplicacion de cada vector por un vector de unos
de igual cantidad de elementos.
62
∑t
n=1(Ym(i,1)n, − Yn)...∑t
n=1(Ym(i,Si)n, − Yn)
=
(ym(i,1)1
− y1)2
(ym(i,1)2 − y2)2
(ym(i,1)3 − y3)2
[ 1 1 1]
...(ym(i,Si)
1 − y1)2
(ym(i,Si)2 − y2)2
(ym(i,Si)3 − y3)2
[ 1 1 1]
Dando como resultado la sumatoria de los cuadrados de las diferencias en cada
una de las regresiones como un valor escalar.
(ym(i,1)1
− y1)2
(ym(i,1)2 − y2)2
(ym(i,1)3 − y3)2
[ 1 1 1]
...(ym(i,Si)
1 − y1)2
(ym(i,Si)2 − y2)2
(ym(i,Si)3 − y3)2
[ 1 1 1]
=
(ym(i,1)1
− y1)2 + (ym(i,1)2− y2)2 + (ym(i,1)3
− y3)2...
(ym(i,Si)1 − y1)2 + (ym(i,Si)
2 − y2)2 + (ym(i,Si)3 − y4)2
Con el valor de las sumatorias calculado, se dividen cada una de las sumatorias
en n (numero de datos observados o pronosticados). Esta division se hace a traves de
la multiplicacion escalar de cada valor del vector por 1/n. Finalmente se calcula la
raız cuadrada de cada elemento. Ninguna de esta operaciones es necesaria hacerla en
lote ya que se calcula elemento a elemento.RMSEm(i,1)
...
RMSEm(i,Si)
=
√∑n
i=1(Ym(i,1)n,−Yn)
n...√∑n
i=1(Ym(i,si)n,−Yn)
n)
63
4.3. Procesamiento multi-core II
H) Filtro de modelos descartados
En este proceso se copian los resultados de las regresiones de la memoria de la
GPU a la memoria del host. Dichos resultados incluyen: valores observados, valores
simulados, coeficientes, metricas de desempeno y los resultados de las operaciones de
inversa. Estos ultimos, indican si fue posible o no realizar la operacion de inversa
de una matriz para un modelo determinados, si la operacion no se pudo realizar de
manera correcta el codigo de retorno es 0.
Haciendo uso del retorno de dicha funcion es posible descartar por completo
aquellos posibles modelos en los cuales no fue posible realizar la regresion.
I) Seleccion de mejores modelos
Durante este proceso se usan los resultados de las regresiones (especificamente
el RMSE) con el fin de escoger el conjunto de predictores que mejores resultados
presentan para las regresiones multivariables.
Cabe aclarar que dichos resultados carecen de diagnostico y por ende posterior a
este proceso se recomienda hacer un filtro de los modelos seleccionados a traves de
otros analisis estadısticos que permitan diagnosticar la regresion (Multicolinealidad,
no linealidad, significancia estadıstica de las variables, entre otros). Sin embargo,
notese que este analisis estadıstico solo debe ser ejecutado sobre un sub conjunto de
combinatorias de predictores de menor tamano que todas las posibles combinatorias
de predictores.
4.4. Implementacion
HMMMR es un modelo agnostico a la tecnologıa, es decir, puede implementarse
sobre cualquier arquitectura CPU/GPU. En este caso, HMMMR fue implementado
sobre tecnologıas Nvidia R©. ya que esta tecnologıa cuenta con una mayor participacion
64
(66.3 %) vs su competidor AMD (33.7 %) en el mercado de graficas discretos Teske
(2018).
Para la implementacion del modelo se seleccionaron las siguientes tecnologıas.
Python: Lenguaje de programacion libre y multiproposito.
Numpy : Biblioteca informatica de python que cuenta con estructuras de datos
que soportan arrays y matrices multidimensionales. Esta biblioteca usa tipos de
datos que permiten gestionar la memoria de una manera eficiente.
Pycuda: Libreria que permite acceder a el API de computo paralelo de CUDA.
Cublas : Libreria que implementa subrutinas definidas en el estandar BLAS y
LAPACK. Algunas de estas subrutinas cuentan con versiones de procesamiento
en batch. Las subrutinas usadas de esta libreria fueron:
• cublasSaxpy/cublasDaxpy Implementaciones en lote de la subrutina axpy
del estandar BLAS. Se utiliza para calcular suma de vectores. cublasSaxpy
y cublasDaxpy son usados para numeros flotantes de 32 y 64 bits
respectivamente.
• cublasSgemmBatched/cublasDgemmBatched : Implementaciones en lote de
la rutina GEMM de BLAS para la multiplicacion de matrices. cublasS-
gemmBatched y cublasDgemmBatched son usados para numeros flotantes
de 32 y 64 bits respectivamente.
• cublasSgetrfBatched/cublasDgetrfBatched Implementaciones en lote de la
subrutina getrf del estandar LAPACK. Calcula la factorizacion LU de
una matriz. cublasSgetrfBatched y cublasDgetrfBatched son usados para
numeros flotantes de 32 y 64 bits respectivamente.
• cublasSgetriBatched/cublasSgetriBatched Implementaciones en lote de la
subrutina getri del estandar LAPACK. Calcula la inversa de una matriz LU
factorizada. cublasSgetriBatched y cublasSgetriBatched son usados para
numeros flotantes de 32 y 64 bits respectivamente.
65
La implementacion de HMMMR esta disponible en el siguiente repositorio
Repositorio en GitHub de HMMMR.
66
Capıtulo 5
Evaluacion del modelo
En este capitulo se evaluan los resultados de la implementacion del modelo
propuesto.
5.1. Metodologia
Para evaluar los resultados de la implementacion del modelo heterogeneo HMMMR
se decidio comparar contra una implementacion que solo hace uso de las capacidades
de computo de la CPU.
5.1.1. Metricas
Las siguientes metricas son recolectadas para evaluar el desempeno de las
herramientas:
Uso de memoria: Maximo uso de memoria de host o de GPU.
Tiempo total : Tiempo total de calculo de las regresiones. En esta metrica se
tiene en cuenta unicamente el tiempo de calculo de la regresion y se excluyen
otros tiempos como el tiempo de carga de datos, de generacion de matrices, de
escritura de resultados, etc.
67
5.1.2. Obtencion de metricas
Con el fin de obtener las metricas anteriormente descritas se hizo uso de algunas
herramientas adicionales para el monitoreo de dichos datos.
Uso de memoria
Esta metrica fue continuamente monitoreada a traves de las siguientes herramien-
tas:
Memoria de host : SAR(System Activity Report), esta herramienta permite
recolectar varias metricas del sistema (operaciones IO, uso de memoria, trafico
de red).
Memoria de CPU : Nvidia-smi(NVIDIA System Management Interface), per-
mite recolectar metricas (Temperatura, Uso de memoria, uso de GPU) de
dispositivos fabricados por Nvidia.
Tiempo de calculo de la regresion
Para tomar esta metrica se hizo uso del modulo line profiler de Python . Este
modulo permite monitorear el tiempo de ejecucion de cada lınea de codigo. En este
caso solo se tiene en cuenta el tiempo de ejecucion del metodo que esta calculando la
regresion.
5.1.3. Herramientas comparadas
Las implementaciones comparadas en esta evaluacion difieren en la plataforma
que usan para ejecutarse.
68
Implementacion de HMMMR
Esta implementacion se ejecuta sobre una plataforma hetorogenea (CPU/GPU).
Esta implementacion se realizo con Python, Numby y PyCuda. Ver los detalles de la
implementacion en la seccion 4.2.
Implementacion en CPU
Existen diferentes bibliotecas que permiten realizar el proceso de calculo de
regresiones (Scikit, Scipy, Sklearn, entre otras). Sin embargo, con el fin de realizar
una evaluacion mas objetiva, se opto por desarrollar una implementacion que realice
exactamente las mismas operaciones que el modelo HMMMR. Dicha implementacion
hace uso eficiente de las operaciones y estructuras de datos de Numpy.
5.1.4. Equipo de computo
El equipo de computo sobre el cual se ejecuto esta evaluacion de desempeno
pertenece al Centro de Computo de Alto Desempeno (CECAD) de la Universidad
Distrital. A continuacion se listan las caracterısticas del equipo.
Sistema Operativo: CentOS Linux release 7.5.
Almacenamiento: SSD Intel 480GB.
Memoria ram: 128GB.
Procesador : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz.
Tarjeta grafica: Nvidia Tesla K80.
5.1.5. Set de datos
El set de datos utilizados para realizar la evaluacion de este modelo son datos
reales de tipo hidrologico.
69
El set de datos proviene del Sistema PRONOS el cual es un sistema de monitoreo
de los embalses Betania y Quimbo (Ubicados en el departamento del Huila, Colombia)
y pertenece a EMGESA y la Universidad Javeriana.
Este set de datos esta compuesto de medidas de niveles, y precipitaciones
recolectados en distintas estaciones de monitoreo y su frecuencia es horaria.
La razon principal por la cual se escogio este data set para evaluar el modelo,
es que actualmente el Sistema PRONOS usa CLAO (Combinaciones Lineales
Adaptativamente Optimas) Calle et al. (2010) con el fin de hallar los mejores modelos
para pronosticar el nivel futuro de un rio. CLAO, genera combinaciones de posibles
predictores y evalua esos posibles modelos con el fin de escoger el modelo que mejores
resultados presente. Dado su similitud con HMMMR, este es un data set ideal para
evaluar el modelo.
Para contemplar un mayor numero de variables en esta evaluacion, 2 data sets
fueron generados.
Set de datos A: Contiene 53 predictores y 100 observaciones.
Set de datos B : Contiene 83 predictores y 300 observaciones.
Adicionalmente, tambien se vario el numero de predictores maximos usados en
cada evaluacion (2,3,4,5,6).
5.2. Resultados
La tabla 5,1 muestra los metricas obtenidas para el set de datos A. La tabla 5,2
muestra los metricas obtenidas para el set de datos B.
70
Tabla
5.1
:R
esult
ados
pro
cesa
mie
nto
dat
ase
tA
.
Max
Pre
dic
tors
Tot
alR
egre
ssio
ns
Max
Bat
chSiz
eT
ime
(ns)
Mem
(GP
U)
ME
M(C
PU
)T
ime
per
regr
essi
on(n
s)C
PU
240
95N
/A45
3223
N/A
285.
5111
0.68
GP
U2
4095
1230
000
1609
210
9148
0.03
392.
97C
PU
312
1575
N/A
9885
669
N/A
253.
7881
.31
GP
U3
1215
7598
1000
3689
724
2597
3058
.68
30.3
5C
PU
426
7676
5N
/A22
9885
493
N/A
1613
.05
85.8
8G
PU
426
7676
581
5000
4399
5217
1046
628
273.
7616
.44
CP
U5
4662
6033
N/A
4418
0097
52N
/A20
167.
1894
.75
GP
U5
4662
6033
6960
0087
0745
993
1057
038
027.
9818
.68
Tabla
5.2
:R
esult
ados
pro
cesa
mie
nto
dat
ase
tB
.
Max
Pre
dic
tors
Tot
alR
egre
ssio
ns
Max
Bat
chSiz
eT
ime
(ns)
Mem
(GP
U)
ME
M(C
PU
)T
ime
per
regr
essi
on(n
s)C
PU
214
85N
/A19
0465
N/A
286.
3212
8.26
GP
U2
1485
3638
000
1325
412
9230
1.96
892.
53C
PU
326
289
N/A
2180
889
N/A
301.
1182
.96
GP
U3
2628
928
8300
019
7514
090
593.
2775
.13
CP
U4
3425
40N
/A28
8767
78N
/A69
3.10
84.3
0G
PU
434
2540
2380
000
4212
985
1455
4035
.58
12.3
0C
PU
535
0505
0N
/A30
6416
827
N/A
1831
.92
87.4
2G
PU
535
0505
020
2100
024
2938
2510
485
2880
1.20
6.93
CP
U6
2933
2215
N/A
2033
3487
41N
/A93
54.1
269
.32
GP
U6
2933
2215
1751
000
2092
7489
010
515
3867
6.09
7.13
71
5.3. Analisis de resultados
5.3.1. Tiempo de ejecucion
Para evaluar esta metrica tomaremos como indicador principal el tiempo promedio
de calculo por regresion. Las figuras 5.1 y 5.2 muestran los resultados de evaluacion
de tiempo de ejecucion para el data set A y B respectivamente.
Para ambos sets de datos se encuentra que el tiempo de ejecucion por cada
regresion tiene un comportamiento constante en el caso de la implementacion hecha
en numpy. Aunque los promedios de tiempo de calculo por regresion son similares, es
notable un pequeno aumento en el tiempo de ejecucion a medida que mas predictores
son agregados. Los tiempos promedio de calculo por cada regresion fueron 71,39 ns y
94,24 para el data set A y B respectivamente.
Para ambos data set cuando la cantidad de regresiones a calcular es menor que
el maximo posible tamano de lote (mbs), el desempeno de la implementacion de
HMMMR es inferior a la implementacion en numpy.
Figura 5.1: Resultados de tiempo de ejecucion usando data set A
72
A medida que se aumenta el numero de regresiones a calcular y cuando este es
mayor que el tamano maximo de lote, el desempeno de la implementacion de HMMMR
es superior a la implementacion de numpy. Una vez que el numero de regresiones es
superior al tamano maximo del batch, el tiempo promedio para el calculo de cada
regresion fue de 7,25 ns y 18,61 ns para el set de datos A y B respectivamente.
La implementacion en numpy es superior cuando el tamano maximo de batch
es mayor al numero de regresiones a realizar es una subutilizacion de recursos de
la GPU. A medida que aumenta el numero de regresiones a calcular y que este es
superior al tamano maximo de batch es notable la superioridad de desempeno de la
implementacion de HMMMR. Algunas razones para el anterior comportamiento son:
Subutilizacion de recursos de la GPU cuando el tamano del batch es menor a
el tamano maximo posible.
Figura 5.2: Resultados de tiempo de ejecucion usando data set B
73
Cuando se hace un llamado para procesar en GPU se requiere una comunicacion
entre el host y el dispositivo para enviar el proceso a ejecutar. Este proceso no
sucede cuando se realiza el calculo solo en CPU.
De la anterior informacion podemos concluir que al procesar una mayor cantidad
de regresiones el desempeno de HMMMR es superior a la implementacion de numpy.
La implementacion de HMMMR puede llegar a ser hasta 9.8 y 5.06 veces mas rapida
que la implementacion en numpy para el set de datos A y B respectivamente.
5.3.2. Uso de memoria
Memoria GPU
Para ambos data set la cantidad de memoria usada depende del numero total
de regresiones y el tamano maximo de batch. Es evidente que cuando el numero
total de regresiones a realizar es menor que el tamano maximo de batch, el uso total
de memoria de GPU es menor a su capacidad total. Para ambos data sets, una
vez el numero de regresiones mayor al tamano maximo de batch, se hace evidente
un uso similar de memoria en todos los casos (10466, 10570, 10485, 10515). Este
comportamiento se debe a que la formula para calcular el tamano maximo de batch
intenta hacer uso eficiente de la memoria disponible en el dispositivo.
No hay metricas de este tipo para la implementacion en numpy dado que no hace
uso de GPU.
Memoria del host
En el caso de la implementacion de HMMMR es evidente un uso mayor de memoria
comparado con la implementacion en numpy. La razon principal para este elevado
uso de memoria es la construccion de las estructuras de datos de entrada que seran
copiadas a la GPU y las estructuras de datos de salida conteniendo los resultados que
son copiadas desde la GPU.
74
En el caso de la implementacion en numpy es evidente un menor consumo de
memoria, la razon principal para este consumo es que en el caso de numpy las
regresiones son calculadas una a una, y por ende no se hace necesario construir grandes
estructuras de datos en memoria.
Para ambas implementaciones es evidente que el uso de memoria incrementa segun
el numero de regresiones total a calcular. Este comportamiento se debe a que todos
los resultados de las regresiones son almacenados en memoria antes de ser organizados
para posteriormente ser escritos a disco.
5.3.3. Conclusiones
En cuanto al tiempo de ejecucion, se evidencio la superioridad de la implementa-
cion de numpy cuando el numero total de regresiones es bajo (menor que el tamano
maximo de batch). Cuando el numero de regresiones aumenta, la implementacion de
HMMMR muestra superioridad dado que se hace un uso mas eficiente de las capacidad
de procesamiento en batch de la GPU. En dichos casos la implementacion de HMMMR
puede llegar a ser hasta 9.8 y 5.06 veces mas rapida que la implementacion en numpy
para el set de datos A y B respectivamente.
En cuanto al uso de memoria, para ambas implementaciones y ambos data set
se evidencia mayor uso de memoria a medida que el numero total de regresiones
va aumentando. La razon para dicho uso de memoria es el almacenamiento de los
resultados de las regresiones en memoria antes de ser organizados y escritos a disco.
HMMMR en todos los casos implica un mayor uso de memoria. La razon principal
para dicho resultado es que las matrices de entrada y los resultados de salida deben
ser almacenados en la memoria del host. Este uso de memoria depende directamente
de la cantidad de regresiones que se ejecutan en el mismo batch.
75
Capıtulo 6
Discusion
6.1. Aportes
A continuacion se describen los principales aportes producto de este proyecto.
6.1.1. Modelo HMMMR
HMMMR es un modelo compuesto de un flujo de procesamiento para plataformas
many-core/multi-core que cuenta con estructuras de datos adaptadas para dichas
arquitecturas.
Flujo de procesamiento
El flujo de procesamiento de datos de HMMMR hace uso de arquitecturas many-
core y multi-core para el calculo de las regresiones.
Las operaciones tales como la carga de datos de entrada, el calculo de tamano
maximo de batch, filtro de modelos descartados y seleccion de los mejores
modelos son mas eficientes de ejecutar en arquitecturas multi-core dado que
son operaciones sencillas y que se ejecutan solo una vez.
76
Las operaciones tales como la generacion de combinatorias de predictores y la
generacion de matrices de entrada son mas eficientes de ejecutar en arquitecturas
multi-core dada la velocidad de acceder y escribir a memoria.
Las operaciones tales como el calculo de coeficientes , calculo de valores
pronosticados y calculo de metricas de desempeno requieren un computo mas
intensivo. Esto, junto a el numero de veces que se requiere ejecutar esta misma
operacion y a la caracteristica de los datos que se estan procesando hace
que del procesamiento many-core sea una alternativa mas eficiente para el
procesamiento de los datos.
Estructuras de datos
Las estructuras de datos que componen HMMMR estan disenadas para permitir
un procesamiento en lote de las regresiones y hacer un uso eficiente de memoria. En
general, las operaciones requeridas para realizar las operaciones en lote, requieren una
agrupacion vertical de las matrices a operar.
Agrupacion vertical de matrices/vectores : Las matrices de mismo tamano son
agrupadas un estructura de datos vectorial que les permite ser operadas con
otras matrices en lote. A continuacion, se muestra un ejemplo en el cual cada
una de las matrices Xmi,nson multiplicadas por su traspuesta.
XMi=
Xm(i,1)
Xm(i,2)
...
Xm(i,Si−1)
Xm(i,Si)
XT
Mi=
XTm(i,1)
XTm(i,2)
...
XTm(i,Si−1)
XTm(i,Si)
77
XTMiXMi
=
XTm(i,1)
Xm(i,1)
XTm(i,2)
Xm(i,2)
...
XTm(i,Si−1)
Xm(i,Si−1)
XTm(i,Si)
Xm(i,Si)
Algoritmo
Calculo de tamano maximo de batch: Mediante el precalculo de la memoria que
cada regresion ocupara en GPU fue posible calcular el tamano maximo adecuado
de batch de tal manera que se puedan calcular el mayor numero de regresiones
paralelamente.
Agrupacion por numero de predictores :La agrupacion de regresiones que usen
el mismo numero de predictores permite contar con matrices de igual tamano
lo cual conlleva a un uso eficiente de memoria y un aprovechamiento de las
capacidades de calculo en lotes.
Sumatoria en batch mediante multiplicacion de matrices : En la fase final del
calculo del RMSE (ver 4.2) se hacia necesario realizar la sumatoria de todos los
elementos de los contenidos de cada uno de los vectores. Hacer esta operacion
vector por vector en la plataforma many-core es ineficiente ya que subutiliza
sus capacidades de computo. Por ello, esta sumatoria se expreso mediante el
producto del vector con un vector de unos.
78
∑t
n=1(Ym(i,1)n, − Yn)...∑t
n=1(Ym(i,Si)n, − Yn)
=
(ym(i,1)1
− y1)2
(ym(i,1)2 − y2)2
(ym(i,1)3 − y3)2
[ 1 1 1]
...(ym(i,Si)
1 − y1)2
(ym(i,Si)2 − y2)2
(ym(i,Si)3 − y3)2
[ 1 1 1]
=
(ym(i,1)1
− y1)2 + (ym(i,1)2− y2)2 + (ym(i,1)3
− y3)2...
(ym(i,Si)1 − y1)2 + (ym(i,Si)
2 − y2)2 + (ym(i,Si)3 − y4)2
6.1.2. Libreria informatica
La implementacion de HMMMR conllevo a un desarrollo de una libreria informati-
ca que contiene funciones en lote tales como:
Producto de matrices en lote.
Suma masiva de vectores.
Inversa de matrices en lote.
Otra de las ventajas de esta libreria es que se adapta al tipo de dato que se
este procesando en el momento. Los tipos de datos soportados por las funciones
actualmente implementadas son:
float32 : Numero flotante de 32 bits.
float64 : Numero flotante de 64 bits.
complex64 : Numero complejo de 64 bits.
complex128 : Numero complejo de 128 bits.
Esta libreria esta licenciada con licencia MIT y por ende es posible agregar nuevas
funcionalidades. La librerıa esta disponible en: Repositorio en GitHub de HMMMR .
79
6.2. Trabajos futuros
Durante el desarrollo de este proyecto se encontro la posibilidad de complementarlo
con los siguientes proyectos.
Implementacion en otras tecnologıas : Este mismo modelo puede ser implemen-
tado en otras tecnologıas que permitan su ejecucion en plataformas de fabricante
diferente a Nvidia. Una posible tecnologıa para implementarlo es OpenCL, esto
permitirıa el uso del modelo en dispositivos AMD.
Modelo heterogeneo para el analisis estadıstico: Como se menciono en 4.3 la
salida de este modelo no cuenta con una validacion estadıstica. Un potencial
trabajo futuro es disenar un modelo que permita realizar los calculos para el
analisis estadıstico en arquitecturas heterogeneas.
Extender la libreria a otras aplicaciones : Actualmente la librerıa implementada
solo cuenta con soporte para regresiones lineales multivariables. Sin embargo,
es posible extender su funcionalidad a otros tipos de aplicaciones tales como:
regresiones logısticas, arboles de decision, bosques aleatorios, entre otros.
80
Bibliografıa
Alba, E. (2005). Parallel metaheuristics: a new class of algorithms, volume 47. John
Wiley & Sons. 19
BLAS (2018). Developer reference for intel math kernel
library - fortran. https://software.intel.com/en-us/
mkl-developer-reference-fortran-blas-level-2-routines. 41
Bowden, J. C. (2010). Application of the opencl api for implementation of the
nipals algorithm for principal component analysis of large data sets. In e-Science
Workshops, 2010 Sixth IEEE International Conference on, pages 25–30. IEEE. 48
Calle, E. A. D., Angarita, H., and Rivera, H. (2010). Viabilidad para pronosticos
hidrologicos de niveles diarios, semanales y decadales en colombia. Ingenieria e
Investigacion, 30(2):178–187. 70
Conway, D. (2013). The data science venn diagram.(2013). http://drewconway.
com/zia/2013/3/26/the-data-science-venn-diagram. xi, 9, 10
Cuda, C. (2015). Programming guide, 2014. URl: http://docs. nvidia.
com/cuda/cuda-c-programming-guide/(visited on 04/10/2017). xi, xi, xi, xii, xii,
xii, xii, 35, 36, 37, 38, 39, 40, 41
de Antonio, M. and Marina, L. (2005). Computacion paralela y entornos heterogeneos.
19
81
Dhar, V. (2013). Data science and prediction. Communications of the ACM,
56(12):64–73. 3
Dongarra, J. J., Duff, I., Hammarling, S., and Du Croz, J. (1988). A set of level 3 basic
linear algebra subprograms: Model implementation and test programs. Technical
report, CM-P00068673. 40
Drignei, D., Forest, C. E., Nychka, D., et al. (2008). Parameter estimation for
computationally intensive nonlinear regression with an application to climate
modeling. The Annals of Applied Statistics, 2(4):1217–1230. 3
Garcia, V., Debreuve, E., and Barlaud, M. (2008). Fast k nearest neighbor search
using gpu. arXiv preprint arXiv:0804.1448. 48
Giovanni, G. and Velasquez, V. (2014). Una aproximacion conceptual a la
implementacion de arboles de decision en la minerıa de datos espaciales. xi, 15
Greathouse, J. L., Knox, K., Po la, J., Varaganti, K., and Daga, M. (2016). clsparse:
A vendor-optimized open-source sparse blas library. In Proceedings of the 4th
International Workshop on OpenCL, page 7. ACM. 46
GROUP, K. et al. (2017). Opencl 2.2 api specification. 22
Kanaan, S. H. (2014). Doing data science. 11
Khronos, O. (2013). The open standard for parallel programming of heterogeneous
systems. URL: https://www. khronos. org/opencl. xi, 22
Kirk, D. B. and Hwu, W.-m. W. (2012). Programming massively parallel processors:
A hands-on approach. 20
Knox, K. et al. (2018). clblas. https://github.com/clMathLibraries/clBLAS.
Accessed: 2018-05-14. 45
82
Kohlhoff, K. J., Sosnick, M. H., Hsu, W. T., Pande, V. S., and Altman, R. B. (2011).
Campaign: an open-source library of gpu-accelerated data clustering algorithms.
Bioinformatics, 27(16):2321–2322. 48
Lawson, C. L., Hanson, R. J., Kincaid, D. R., and Krogh, F. T. (1979). Basic
linear algebra subprograms for fortran usage. ACM Transactions on Mathematical
Software (TOMS), 5(3):308–323. 40
Lee, A., Yau, C., Giles, M. B., Doucet, A., and Holmes, C. C. (2010). On the utility
of graphics cards to perform massively parallel simulation of advanced monte carlo
methods. Journal of computational and graphical statistics, 19(4):769–789. 3, 49
L’Ecuyer, P., Munger, D., and Kemerchou, N. (2015). clrng: a random number
api with multiple streams for opencl. report, http://www. iro. umontreal.
ca/ lecuyer/myftp/papers/clrng-api. pdf. 45
McConnell, S., Sturgeon, R., Henry, G., Mayne, A., and Hurley, R. (2012). Scalability
of self-organizing maps on a gpu cluster using opencl and cuda. In Journal of
Physics: Conference Series, volume 341, page 012018. IOP Publishing. 48
Nvidia (2018a). Beyond3d - nvidia cuda introduction. http://www.beyond3d.com/
content/articles/12/5. xi, 4
Nvidia (2018b). Dense linear algebra on gpus. https://developer.nvidia.com/
cublas. 42
O’Neil, C. and Schutt, R. (2013). Doing data science: Straight talk from the frontline.
.O’Reilly Media, Inc.”. xi, 10
Opencv, D. t. (2013). Introduction to support vector machines.(2014).
http://www.swarthmore.edu/NatSci/mzucker1/opencv-2.4.10-docs/doc/
tutorials/ml/introduction_to_svm/introduction_to_svm.html. xi, xi, xi,
13, 14, 15
83
Pineda, G. L., Fleites, G. L., and Cervantes, H. J. R. (2013). Analisis de regresion
para la estimacion del secuestro de carbono organico en suelos. 18
Saltz, J. S. and Stanton, J. M. (2017). An introduction to data science. SAGE
Publications. 2
Shan, A. (2006). Heterogeneous processing: a strategy for augmenting moore’s law.
Linux Journal, 2006(142):7. 20
Sharp, T. (2008). Implementing decision trees and forests on a gpu. In European
conference on computer vision, pages 595–608. Springer. 47
Teske, D. (2018). Nvidia corporation: A strategic audit. 65
Tranmer, M. and Elliot, M. (2008). Multiple linear regression. The Cathie Marsh
Centre for Census and Survey Research (CCSR), 5:30–35. 18
Vera Parra, N. E. et al. (2018). Modelo de procesamiento paralelo en arquitecturas
heterogeneas para la construccion de grafos en el ensamblaje de-novo de genomas.
xi, xi, xi, xi, xi, 21, 24, 26, 27, 29
Wikipedia (2018). Row- and column-major order — Wikipedia, the free
encyclopedia. http://en.wikipedia.org/w/index.php?title=Row-%20and%
20column-major%20order&oldid=856491158. [Online; accessed 24-November-
2018]. xii, 43
Wu, J., Cui, Z., Sheng, V. S., Shi, Y., and Zhao, P. (2014). Mixed pattern matching-
based traffic abnormal behavior recognition. The Scientific World Journal, 2014.
xi, 13
Yale, U. (1998). Multiple linear regression. http://www.stat.yale.edu/Courses/
1997-98/101/linmult.htm. 17
84