Descargar el archivo PDF

Transcripción

Sobre la programación paralela de un algoritmo de optimización por cúmulo de partículas en un dispositivo GPU multi-hilos
G. A. Laguna-Sánchez, M. Olguín-Carbajal, N. Cruz-Cortés, R. Barrón-Fernández
Sobre la programación paralela de un algoritmo
de optimización por cúmulo de partículas en un
dispositivo GPU multi-hilos
(Recibido: 15 de agosto de 2011; aprobado: 26 de septiembre de 2011)
Resumen
Este trabajo presenta los principales resultados y recomendaciones prácticas que resultan de un estudio reciente sobre algunas
variantes paralelas de un algoritmo de optimización por cúmulo de partículas (PSO), puestas en práctica en una unidad de
procesamiento de gráficos (dispositivo GPU), con capacidad para administrar múltiples hilos (multi-hilos), empleando CUDA
(Arquitectura unificada de dispositivo computador), el modelo de programación paralela para estos casos. Se demuestra
que, con la ayuda de un dispositivo GPU multi-hilos, es posible obtener versiones paralelas del algoritmo PSO por medio
de una programación paralela simple y directa, aprovechando el poder de cómputo de un dispositivo GPU que puede ser
equivalente a un cluster en una computadora personal convencional. En particular, se ofrecen recomendaciones prácticas
para el buen uso de un dispositivo GPU multi-hilos. El algoritmo PSO es una alternativa bien conocida para resolver problemas de optimización global con base en una heurística bio-inspirada, que por su naturaleza poblacional resulta ideal para
su programación paralela. El algoritmo PSO tiene buen desempeño, baja complejidad computacional y pocos parámetros.
Estas técnicas heurísticas han sido extensamente estudiadas en los últimos veinte años y, aún hoy, la comunidad científica
está interesada en alternativas tecnológicas que aceleren estos algoritmos a fin de aplicarlos a problemas más grandes y
más complejos.
Palabras clave - GPU multi-hilos, PSO, GPU de uso general, programación paralela, optimización global.
Gerardo Abel Laguna Sánchez: Doctor en Ciencias de la Computación, [email protected]. Departamento de Ingeniería Eléctrica, Universidad
Autónoma Metropolitana – Iztapalapa, Av. San Rafael Atilxtco 186 Iztapalapa, (C.P. 09340), México, D.F., México.
Mauricio Olguín Carbajal: Doctor en Ciencias de la Computación, [email protected], Instituto Politécnico Nacional IPN, Av. Luis Enrique
Erro S/N, Unidad Profesional Adolfo López Mateos, Zacatenco, Delegación Gustavo A. Madero (C.P. 07738), México, D.F., México.
Nareli Cruz-Cortés: Doctora en Ciencias, [email protected]. Centro de Investigación en Computación - CIC, Instituto Politécnico Nacional – IPN,IPN,
Av. Juan de Dios Bátiz, Esq. Miguel Othón de Mendizabal | Col. Nueva Industrial Vallejo Delegación Gustavo A. Madero (C.P. 07738), México, D.F,
México.
Ricardo Barrón-Fernández: Doctor en Ciencias de la Computación, [email protected] de Investigación en Computación - CIC, Instituto Politécnico Nacional – IPN Centro de Investigación en Computación CIC-IPN. Av. Juan de Dios Bátiz, Esq. Miguel Othón de Mendizabal, Col. Nueva
Industrial Vallejo Delegación Gustavo A. Madero (C.P. 07738), México, D.F, México.
El artículo es resultado del proyecto de investigación SIP-20100379 (IPN) “Graficación, ondeletas y sus aplicaciones”, financiado mediante recursos de
la SIP-IPN, el fondo I0013/91434 (CONACyT) y la beca de doctorado #210397 (CONACyT), del que resultó una tesis doctoral desarrollada al interior
del grupo de investigación del Laboratorio de Inteligencia Artificial del Centro de Investigación en Computación del Instituto Politécnico Nacional.
Intekhnia | Vol. 6 | No. 2 | Julio - diciembre de 2011 | ISSN: 1900-7612 | pp. 59 - 74
59
On a Parallel Programming of Particle Swarm
Optimization Algorithm in a Multithreading GPU
Device
Abstract
This article presents the main results and practical issues from a recent study about some parallel variants for a Particle
Swarm Optimization (PSO) algorithm, implemented on a Graphic Process Unit (GPU) device with multi-thread support
and using CUDA (Compute Unified Device Architecture), the most recent model of parallel programming for these cases.
It is shown that, with the help of a multithreading GPU, it is possible to significantly improve the PSO algorithm performance by means of a simple and straightforward parallel programming, getting the computing power similar to a cluster
in a conventional personal computer. Particularly, we expose some practical considerations in order to get a good GPU
application. PSO algorithm is a well known alternative for global optimization based on a bio-inspired heuristic, which,
as a population-based one, is a good candidate to be parallelized. PSO algorithm has good performance, low computational complexity and few parameters. These heuristic techniques have been widely studied in the last twenty years and the
scientific community is still interested in technological alternatives that accelerate these algorithms in order to apply them
to bigger and more complex problems.
Keywords – Multithreading GPU, PSO, general purpose GPU, parallel programming, global optimization.
Em relação a programação paralela de um
algoritmo de otimização por conglomerado de
partículas em um dispositivo GPU multi-hilos
Resumo
Este trabalho apresenta as principais conclusões e recomendações práticas resultantes de um estudo recente de algumas
variantes paralelas de um algoritmo de otimização por conglomerado de partículas (PSO), implementado em uma unidade
de processamento gráfico (GPU dispositivo), capaz de gerenciar múltiplos hilos (multi-hilos), usando CUDA (Arquitectura
unificada de dispositivo computador ), o modelo de programação paralela para esses casos. se mostra que com a ajuda de
um dispositivo GPU ulti-hilos é possível obter versões paralelas do algoritmo PSO através de uma programação paralela
simple e direta paralela, aproveitando o poder de computação do dispositivo GPU que pode ser equivalente a um cluster
em um computadorpessoal convencional. Em particular, nós fornecemos recomendações práticas para o uso adequado de
um dispositivo GPU multi-hilos. O algoritmo PSO é uma alternativa bem conhecida para resolver problemas de otimização
global baseado em uma heurística bio-inspirados heurística, que pela sua natureza é ideal para a programação paralela. O
algoritmo PSO tem bom desempenho, baxa complexidade computacional e poicos parâmetros. Estas técnicas heurística têm
sido extensivamente estudadas nos últimos 20 anos e ainda hoje, a comunidade científica está interessada em alternativas
tecnologias que aceleram estes algoritmos, a fim de aplicar a problemas maiores e mais complexos.
Palavras - chave – GPU multi-hilos, PSO, GPU de uso geral, programação paralela, otimização global.
60
I. Introducción
Algunas técnicas bio-inspiradas, como el cómputo evolutivo
[1], optimización por colonia de hormigas [2][3] y PSO
[4], fueron propuestas como alternativas para solucionar
problemas de optimización difíciles, obteniendo soluciones aceptables en un tiempo razonable. Debido a que
estas técnicas trabajan con una población de individuos,
pueden probar diferentes soluciones en forma simultánea,
siguiendo reglas específicas y usando procesos estocásticos
subyacentes. Estas técnicas heurísticas han sido aplicadas
en prácticamente todos los campos del conocimiento, obteniendo buenos resultados, incluso al ejecutarse en computadoras personales comunes (por ejemplo, ver [5]). Aquí
se entiende por “buenos resultados” a la combinación de
encontrar soluciones muy cercanas al óptimo en un tiempo
razonable o, como suele decirse formalmente, en “tiempo
polinomial”. Las técnicas heurísticas obtienen soluciones
aceptables en un tiempo “razonablemente corto”, comparadas con los métodos tradicionales tales como las técnicas
deterministas y enumerativas. Estas últimas pueden resultar
poco prácticas, especialmente al solucionar problemas de
optimización difíciles, ya que prueban cada una de las posibles soluciones de un problema. No obstante, el tiempo
“razonable”, que las técnicas heurísticas pueden consumir,
puede estar en el orden de segundos, minutos, o hasta horas, según el problema. De este modo, los algoritmos más
simples, como PSO, se han hecho muy atractivos debido a
su baja complejidad computacional, que resulta en tiempos
de ejecución más cortos. Sin embargo, en los casos donde
se necesita obtener una solución de tiempo real, hasta los
algoritmos más simples pueden parecer lentos. Esta situación ha motivado la búsqueda de nuevas formas de acelerar
el desempeño de estas heurísticas.
Recientemente, se ha propuesto explotar el poder computacional disponible en las tarjetas gráficas de las computadoras
personales, a fin de solucionar problemas de propósito general [6], surgiendo, con ello, la idea del dispositivo GPU de
procesamiento de propósito general (GPGPU, por sus siglas
en inglés). Desde entonces, tanto los fabricantes como los
desarrolladores han considerado esta nueva aplicación de la
computación como un área de investigación prometedora,
considerando la amplia variedad de posibles aplicaciones
que pueden aprovechar el paralelismo disponible en los
dispositivos GPU actuales.
Desde que los primeros algoritmos bio-inspirados fueron
reportados, la idea de su programación paralela fue vista
como una consecuencia lógica de su naturaleza poblacional [7]. En particular, para el caso de un algoritmo PSO,
podemos usar los modelos paralelos desarrollados para
algoritmos evolutivos [8]: el modelo global, el modelo de
isla y el modelo de difusión. En este trabajo se presentan
algunas variantes paralelas para el algoritmo PSO: dos variantes globales y una que se denominó “incrustada”, todas
puestas en práctica en un dispositivo GPU multi-hilos. Se
reportan los resultados obtenidos usando el modelo de programación CUDA, que permite al programador escribir el
código con el enfoque de múltiples hilos, además de ofrecer
operaciones paralelas en la memoria gráfica [9]. La idea
principal es mostrar que, con la ayuda de un dispositivo GPU
multi-hilos, es posible mejorar el desempeño de algoritmo
PSO secuencial en forma considerable, por medio de una
programación paralela simple y directa, con lo que se logra
el poder computacional de un cluster en un computadora
personal convencional.
Este trabajo es organizado como sigue. En la Sección II se
presenta el trabajo relacionado encontrado en la literatura
especializada. En la Sección III se hace una semblanza histórica y se bosqueja la arquitectura general del dispositivo
GPU. En la Sección IV se ofrece una breve descripción
del algoritmo PSO. En la Sección V se presentan algunas
consideraciones prácticas en nuestra realización. En la
Sección VI se presentan los resultados experimentales y
en la Sección VII se discuten los mismos. Finalmente, en
la Sección VIII se ofrecen las conclusiones de este trabajo.
II. Trabajo relacionado
La programación paralela, por lo general, implica la migración de un código secuencial existente hacia alguna
arquitectura paralela, distribuida o, incluso, concurrente. El
algoritmo PSO no es la excepción y encontramos reportes,
sobre las primeras tentativas de aprovechar su paralelismo
implícito, tan solo algunos años después de su presentación
en 1995 [4]. Por ejemplo, el trabajo de J.F. Schutte en 2003
61
[10]. No obstante, el interés sobre la programación paralela
de PSO es todavía un tema muy actual, lo que es evidente en
algunos trabajos de investigación recientes, donde proponen
aplicar algoritmos PSO paralelos para solucionar problemas
de optimización muy complejos (ver [11], [12] y [13]).
En la literatura especializada, podemos encontrar propuestas
de paralelismo con diversos enfoques para cada heurística.
Aunque un enfoque básico es el de procesos concurrentes
que corren en sólo un procesador (ver [14]), la mayor parte
de las realizaciones paralelas son por lo general diseñadas
para ser ejecutadas en sistemas distribuidos (es decir, varios
procesadores en una red). En estos sistemas distribuidos
la sobrecarga (overhead), debida a la intercomunicación
entre los diferentes procesadores, es un factor que afecta
significativamente el desempeño de la aplicación paralela.
A causa de esto, es comprensible que algunas realizaciones
paralelas para PSO fueran propuestas adoptando estrategias
de comunicación (como en [15], [16] y [17]). Incluso,
recientemente, es posible encontrar propuestas para la
programación paralela del algoritmo PSO con el enfoque
de vectores paralelos, en [18][19].
Finalmente, debemos notar que la mayor parte de los primeros trabajos sobre la programación paralela de algoritmos
poblacionales en un dispositivo GPU se centraron, por razones históricas, en los algoritmos evolutivos y genéticos (ver
[20], [21], [22] y [23]). En algunos casos las experiencias
obtenidas fueron aplicadas, más tarde, a la programación
paralela del algoritmo PSO (como en [24]). Sin embargo,
es hasta hace muy poco tiempo que se presentó el primer
estudio empírico, en cuanto a la programación paralela de
alguna heurística poblacional en un dispositivo GPU, explotando el enfoque de múltiples hilos concurrentes con el
nuevo modelo de programación paralela CUDA [25]. Esto
en consideración de que CUDA, como herramienta de programación paralela, fue introducida muy recientemente [26].
III. Unidad de procesamiento de gráficos
(dispositivo GPU)
A. Breve semblanza histórica
El dispositivo seleccionado, para probar las variantes paralelas propuestas para el algoritmo PSO, es undispositivoGPU
62
comúnmente usado como coprocesador gráfico en sistemas
de vídeo con altos requerimientos de cómputo, como es
el caso de la mayoría de los juegos de vídeo actuales. Un
dispositivoGPU tiene su fundamento en la arquitectura del
procesador vectorial, que permite la ejecución de operaciones matemáticas en múltiples datos de forma simultánea.
En contraste, los procesadores de los CPU comunes no
pueden manejar más de una operación al mismo tiempo.
Al principio, los procesadores vectoriales eran comúnmente
usados en computadoras científicas [27], pero más tarde
fueron desplazados por arquitecturas de múltiples núcleos.
Sin embargo, no fueron completamente eliminados porque
muchas arquitecturas para gráficos realizados por computadora, tales como los dispositivos GPU, los usan como la
base de su hardware.
Así, la gran demanda de juegos y producciones de vídeo de
aspecto realista en tiempo real ha llevado a la producción
de dispositivos GPU más poderosos y ha impulsado a los
fabricantes de tarjetas de vídeo a desarrollar arquitecturas
con múltiples núcleos, administración de múltiples hilos
y con un poder computacional similar al de la primera supercomputadora vectorial Cray. Actualmente, la tendencia
en el desarrollo de los dispositivos GPU permite prever
la consolidación de un nuevo modelo de programación
paralela, donde el dispositivo GPU no sólo aumenta su
original capacidad del cómputo paralelo sino que, además,
adquiere un papel más preponderante como administrador
de múltiples hilos [28].
B. Arquitectura del dispositivo GPU
El dispositivo GPU usado en este trabajo es el de la tarjeta
NVIDIA GeForce 8600GT, con una arquitectura unificada
de gráficos y cómputo que el fabricante llama Tesla, y que
se conforma por un arreglo escalable de múltiples procesadores (multiprocesador) con administración de múltiples
hilos (ver Figura 1). Cada multiprocesador consiste en ocho
núcleos de procesamiento, una unidad de instrucciones
multi-hilos y memoria compartida en el circuito integrado.
Cada multiprocesador controla la creación, administración
y ejecución de los hilos activos en el hardware, con capacidad para cientos de hilos (teóricamente hasta 512), todo
dentro del concepto denominado por NVIDIA como “una
instrucción - múltiples hilos” (SIMT, por sus siglas en in-
glés) [28]. Ya que el multiprocesador asigna cada hilo a un
núcleo y cada hilo es ejecutado independientemente de los
demás, con su propia dirección de instrucciones así como
registros de estado, NVIDIA ofrece algunas herramientas
de programación con funciones enfocadas en el manejo y
optimización de múltiples hilos.
Figura 1. Arquitectura del dispositivo GPU NVIDIA empleado
multiprocesador disponible. Con CUDA, en el programa,
se arranca la ejecución de los kernel paralelos mediante la
siguiente sintaxis extendida de llamada a función:
kernel<<<dimGrid, dimBlock>>>(...parámetros...);
dondedimGrid y dimBlock son parámetros especializados
que especifican, respectivamente, la dimensión (en bloques)
de la rejilla de procesamiento paralelo y la dimensión (en
hilos) de los bloques.
Figura 2. Jerarquía de la memoria del GPU NVIDIA
Fuente: NVIDIA [28].
Fuente: NVIDIA [28].
La herramienta de programación CUDA está diseñada para
soportar el esquema de “una instrucción - múltiples hilos”,
de tal manera que múltiples hilos pueden ser ejecutados
sobre muchos datos. La herramienta CUDA permite que
los programadores escriban el código paralelo usando
lenguaje C estándar mas algunas extensiones de NVIDIA.
La herramienta CUDA permite organizar el paralelismo en
un sistema jerárquico de tres niveles: rejilla, bloque e hilo.
El proceso comienza cuando el procesador anfitrión (CPU
anfitrión) invoca una función para el dispositivo GPU, llamada kernel, luego de lo cual se crea una rejilla (o arreglo)
con bloques de múltiples hilos, para distribuirla en algún
Durante la ejecución del kernel, los hilos tienen acceso a
seis tipos de memoria dentro del dispositivo GPU, según la
siguiente jerarquía (o niveles de acceso), predefinidos por
NVIDIA (ver Figura 2):
•
Memoria global. Es una memoria de lectura/escritura
y se localiza en la tarjeta del dispositivo GPU.
•
Memoria para constantes. Es una memoria rápida
(cache) de lectura y se localiza en la tarjeta del dispositivo GPU.
•
Memoria para texturas. Es una memoria rápida (cache)
de lectura y se localiza en la tarjeta del dispositivo GPU.
•
Memoria local. Es una memoria de lectura/escritura
para los hilos y se localiza en la tarjeta del dispositivo
GPU.
63
•
Memoria compartida. Es una memoria de lectura/escritura para los bloques y se localiza dentro del circuito
integrado del dispositivo GPU.
•
Memoria de registros. Es la memoria más rápida, de
lectura/escritura para los hilos y se localiza dentro del
circuito integrado del dispositivo GPU.
La memoria compartida y los registros son los más rápidos,
pero su tamaño está limitado porque es memoria ubicada
dentro del circuito integrado. Por otra parte, la memoria
localizada en la tarjeta del dispositivo (local, global, para
constantes y para texturas) es grande pero presenta mayor
latencia en los accesos, en comparación con la memoria
alojada dentro del circuito integrado. Ya que el multiprocesador ejecuta paralelamente los hilos en grupos de
32, llamados “tejidos” (warp), los hilos pueden tener un
acceso más eficiente a la memoria global, siempre que este
acceso se realice en bloques de justo la “mitad de un tejido” (half-warp), mediante lecturas/escrituras simultáneas
de/a memoria, fusionadas en una sola transacción en masa
(coalesced) de memoria, ya sea de 32, 64, o 128 bytes [28].
C. Programación paralela del dispositivo GPU
Es muy importante hacer énfasis en que, debido a los tiempos relativamente grandes de retardo (latencia) y al bajo
ancho de banda en las trasferencias de memoria, entre la
computadora anfitrión y el dispositivo GPU, es altamente
recomendable dividir la aplicación, de tal manera que cada
parte del sistema (hardware) haga únicamente el trabajo que
mejor realiza. El uso del dispositivo GPU es recomendado
únicamente cuando [28][29]:
- La complejidad de las operaciones justifica el costo de
mover datos, de y hacia el dispositivo GPU. El escenario
ideal es aquel en el que muchos hilos ejecutan una cantidad
considerable de trabajo. Entonces, ya que las transferencias
deben ser minimizadas, los datos deberían mantenerse en
el dispositivo GPU tanto como sea posible.
- La aplicación tiene numerosos datos que pueden ser
calculados simultáneamente en paralelo. Esto típicamente
involucra operaciones aritméticas sobre un gran conjunto de
datos, donde la misma operación puede ser realizada sobre
miles de elementos al mismo tiempo.
64
- La aplicación puede ser dividida en operaciones simples,
que pueden ser asignadas a numerosos hilos ejecutándose
en paralelo.
- El tamaño de los tipos numéricos, usados para variables
y arreglos dentro del código del dispositivo GPU, son
congruentes tanto con los patrones de memoria como con
las instrucciones aritméticas más ágiles, a fin de alcanzar
el mejor desempeño del dispositivo GPU (por ejemplo, el
empleo de accesos de memoria en masa, así como el uso
de tipos enteros, flotantes de precisión simple y funciones
aritméticas intrínsecas compatibles).
Con estas consideraciones en mente, lo primero que se tiene
que hacer es determinar cuál es la parte del código secuencial que mejor se puede programar en forma paralela usando
el dispositivo GPU, de acuerdo con las recomendaciones
de arriba. Típicamente se elige como posibles candidatos
a todos los segmentos de código que son especialmente
demandantes de recursos computacionales (tanto tiempo
de procesamiento como memoria). Finalmente, se procede
a delegar al dispositivo GPU aquellos segmentos de código que cumplen con las recomendaciones prácticas antes
mencionadas.
Típicamente, una aplicación y código con CUDA debe
incluir los siguientes pasos:
1.- El computador (CPU) anfitrión llama al cuerpo principal
del programa (main()).
2.- Se reserva memoria dentro del dispositivo GPU.
3.- Se copian los datos del CPU anfitrión al dispositivo GPU.
4.- El CPU anfitrión llama a la función kernel.
5.- El dispositivo GPU ejecuta el código paralelamente.
6.- Se copian los resultados de vuelta a la memoria del
CPU anfitrión.
7.- Se libera la memoria reservada dentro del dispositivo
GPU.
La aplicación, así conformada, delega al dispositivo GPU
la ejecución paralela de tantos hilos como lo determina el
tamaño de la rejilla de bloques y el tamaño de cada bloque
de hilos. Concretamente, cuando se arranca la ejecución
del kernel se define tanto el número de hilos por bloque
(blockDim) como el número de bloques que conforman a la
rejilla (gridDim). La multiplicación de estos dos parámetros
resulta en el total de hilos que serán administrados por el
multiprocesador que el sistema designó para la ejecución
del kernel. En todo esto, se asume que el multiprocesador
puede ejecutar concurrentemente, cuando mucho, el número
de hilos en un solo bloque. Sin embargo, el multiprocesador
puede planificar la ejecución de un número total de hilos
que rebase, por mucho, al tamaño de un solo bloque. Esto
lo logra distribuyendo el trabajo de todos los bloques, durante los intervalos de tiempo disponibles, conforme se va
presentando la oportunidad.
IV. El algoritmo de optimización por cúmulo de
partículas
La idea principal del algoritmo de PSO consiste en el movimiento de partículas o individuos que “vuelan” en busca
de un óptimo global en un espacio n-dimensional en forma
cooperativa. En cada una de las iteraciones del algoritmo
se actualiza la posición de las partículas mediante una
regla simple donde el movimiento del individuo, aunque
esencialmente aleatorio, está bajo la influencia de su propia experiencia (aprendizaje individual) y por el ambiente
(influencia social) [30].
El algoritmo fue originalmente propuesto por Kennedy y
Eberhart [4], en 1995, y trabajaba con la posición x y el
cambio de la posición v (que fue llamado velocidad, por
analogía) para cada partícula. Más tarde, el algoritmo fue
mejorado por Shi y Eberhart [31], en 1998, introduciendo el
concepto de la inercia w. Denotando pbx la solución con la
mejor aptitud encontrada por la partícula, hasta el momento,
y gbx la solución con la mejor aptitud global encontrada
dentro de la población, hasta el momento. Entonces el algoritmo PSO puede ser descrito como sigue [32]:
A. Algoritmo 1
1.-Inicializar cada partícula de la población en forma aleatoria, obteniendo los valores para los vectores n-dimensionales
de posición x y velocidad v.
2.-Calcular la aptitud de la posición xi de cada partícula. Si
la aptitud actual es mejor que pbx, entonces actualizar a pbx.
3.-Determinar la posición de la partícula con la aptitud más
alta y actualizar, en su caso, agbx.
4.-Para cada dimensión d, de cada partícula i, actualizar la
velocidad v según Ec. (1):
donde C1 y C2 son constantes que ponderan, respectivamente, la influencia del aprendizaje de individuo y la influencia
social. r1 y r2 son variables aleatorias, entre 0 y 1 que representan el libre albedrío en movimiento de cada partícula. w
es la inercia del sistema calculada según Ec. (2):
(2)
donde Wmax, Wmin, itermax e iter son, respectivamente, el valor
máximo para la inercia, el valor mínimo para la inercia, el
número máximo de iteraciones y la iteración actual.
(1)
5.-Actualizar la posición x de cada partícula según Ec. (3):
(3)
6.-Repetir los pasos 2-5 hasta alcanzar la condición de
terminación (ya sea número de iteraciones o precisión).
V. Puesta en práctica de las variantes paralelas
del algoritmo PSO en el Dispositivo GPU
En lo general, el proceso de programación paralela de un
algoritmo poblacional con un dispositivo GPU multi-hilos
65
comprende las etapas sugeridas por Ian Foster [33]: división, agrupamiento, comunicación y mapeo. En la división,
los datos, que corresponden y representan a los individuos
que conforman la población, se reparten entre los hilos de
procesamiento. En el agrupamiento, se identifican los datos
asociados a cada individuo. En el tercer paso, se comunican
los individuos mediante el uso de la memoria compartida
del dispositivo GPU. Finalmente, en el mapeo, las tareas
ejecutadas por un individuo se asignan a un hilo.
Al respecto de la clasificación de los modelos de programación paralela para el algoritmo PSO, se adoptó por la misma
clasificación propuesta para los algoritmos evolutivos [8]:
1.-Variante paralela con enfoque global. Existe un procesador principal (maestro) y varios esclavos. En este modelo,
el maestro distribuye a los esclavos el trabajo relativo a la
evaluación de la función de aptitud.
2.-Variante paralela con el enfoque migratorio (también
llamado enfoque de islas). En este modelo, la población es
dividida en varias sub-poblaciones (demes) de tal manera
que diferentes procesadores manejan el mismo algoritmo
en cada sub-población. Finalmente, después de un cierto
tiempo (llamado época), los procesadores pasan a una etapa
de intercomunicación donde intercambian información y
comparten las soluciones encontradas hasta el momento.
3.-Variante paralela con enfoque de difusión. Este puede
ser visto como un caso extremo del modelo de islas, donde
la población de cada isla es sólo un individuo y donde hay
tantas islas como individuos existentes.
Partiendo de dicha clasificación, se programaron algunas
variantes paralelas para el algoritmo PSO que se detallan
adelante. El objetivo principal fue programar variantes paralelas para el dispositivo GPU que emplearan código CUDA
en vez de los antiguos métodos, complejos y laboriosos,
que trabajan únicamente con operaciones paralelas en la
memoria gráfica (texturas, etc.). Esto con el fin de evaluar
la mejora en el desempeño que podría ser alcanzada por el
dispositivo GPU, mediante una estrategia de programación
paralela relativamente simple. Así, las variantes paralelas
propuestas en este trabajo se diferencian de las que se
presentan en [24] porque no se emplea el antiguo estilo de
66
programación paralela del dispositivo GPU, que se enfoca
más bien en emplear operaciones paralelas sobre múltiples
datos, lo que se conoce como enfoque SIMD (“una instrucción - múltiples datos”) [9]. En cambio, las aplicaciones
paralelas propuestas aquí trabajan con el nuevo modelo de
programación paralela CUDA, concebido para aprovechar
la característica de administración de multi-hilos de los
dispositivos GPU de NVIDIA, lo que permite manejar múltiples hilos concurrentes en forma muy eficiente. NVIDIA
llama esta característica SIMT (“una instrucción - múltiples
hilos”) [28] y se ofrece como una característica adicional
a las tradicionales operaciones paralelas sobre la memoria.
Este nuevo modelo de programación ofrecido con la herramienta CUDA permite a los programadores escribir códigos
paralelos para el dispositivo GPU de forma más natural, con
lo que el dispositivo GPU se convierte en una verdadera
herramienta para la programación paralela de propósito
general. De hecho, se prevé que este nuevo modelo de la
programación paralela sea la referencia para la especificación futura de un modelo de programación universal que
hará posible la programación paralela que programa, no
sólo en los dispositivos GPU, sino en cualquier arquitectura
de múltiples núcleos o plataforma de súper cómputo que
aparezca en el futuro [9][26][ 28].
Así las cosas, las tres variantes paralelas para el algoritmo
PSO que se reportan aquí son: dos variantes globales y una
más que se denominó “incrustada” en vista de que ésta es
una variante especial del modelo de difusión. Respecto del
enfoque global, tenemos dos variantes que fueron programadas en el dispositivo GPU:
1.-Global_ev: Donde se programa en forma paralela únicamente al proceso de evaluación de la función objetivo
(función de aptitud).
2.-Global_ev+up: Donde se programan en forma paralela
todos los cálculos matemáticos, tanto para la función de
aptitud, como para la velocidad, posición e inercia.
A la tercera variante paralela, considerando que el modelo
de difusión es un caso extremo del enfoque de isla, decidimos llamarla variante incrustada porque en este caso,
excluyendo la inicialización, todo el algoritmo PSO corre
en el dispositivo GPU, de tal manera que puede ser visto
como una caja negra, desde el punto de vista de procesador
anfitrión. Más aún, mientras que en el modelo de difusión
hay un procesador por partícula, en nuestra variante incrustada se emplea un hilo, y no un procesador, por partícula.
Se programó como código de referencia al Algoritmo 1,
el algoritmo secuencial de PSO, ejecutándose en un solo
núcleo y un solo hilo del dispositivo GPU, a fin de evaluar
en forma justa el desempeño de variantes paralelas. En
todas las variantes paralelas se empleó la misma estrategia
de programación, que consistió en la creación de un hilo por
cada partícula PSO. La regla fue sustituir todos los lazos
secuenciales (especialmente aquellos donde las iteraciones
estaban en función del número de partículas) por una sola
llamada al kernel multi-hilos. Con ello, el algoritmo PSO
secuencial y sus variantes paralelas tienen esencialmente la
misma estructura. No obstante, mientras que en los lazos del
código secuencial, cada iteración es independiente la una
de las otras, en el código paralelo, tales lazos pueden ser
directamente transformados en kernels paralelos, donde las
operaciones de cada iteración del lazo original se realizan
por un hilo independiente [9].
En la Figura 3 se representa la estructura del algoritmo
PSO secuencial que se programó para ser ejecutado por un
solo núcleo de procesamiento dentro del dispositivo GPU.
Podemos observar los siguientes bloques funcionales [30]:
- Inicialización de la población. Aquí se inicializa cada
partícula de la población en forma aleatoria.
- Evaluación de función de aptitud.
- Comparación. Se determina si un individuo tiene mejor
aptitud que el mejor registrado.
- Imitación (actualización). Cada individuo actualiza su
posición, tanto por la influencia de su propia experiencia
como por el ambiente social.
Figura 3. Estructura de algoritmo PSO secuencial
Fuente: Autores.
Intencionalmente, a fin de ilustrar cómo se realiza la programación paralela en forma directa, el código secuencial ha
sido organizado destacando los lazos que están en términos
de número de partículas. La idea principal es crear un hilo
por cada partícula PSO. Note que en la realización práctica de la variante secuencial del algoritmo PSO (Figura 3)
todos los módulos funcionales son ejecutados, para todas
las partículas, en un solo núcleo e hilo del dispositivo GPU.
En la primera de las variantes paralelas, Global_ev, sólo
se programa en forma paralela al módulo de evaluación de
la función de aptitud (Figura 4). Note que el lazo correspondiente fue sustituido por una llamada a un kernel que
distribuye el trabajo en múltiples hilos dentro del dispositivo
GPU. En la segunda variante paralela, Global_ev+up, se
distribuye al dispositivo GPU todo cálculo aritmético, sustituyendo al módulo de evaluación de la función de aptitud
y al módulo de actualización de posición por las llamadas
a los kernel asociados (Figura 5). Finalmente, en la tercera
variante paralela, la denominada incrustada, únicamente el
módulo de inicialización se ejecuta en el procesador anfitrión (Figura 6), ya que hay llamadas a los kernel asociados
con los módulos de evaluación, comparación y de imitación,
todo ello realizado dentro del dispositivo GPU hasta que se
alcanza la condición de terminación.
67
Figura 4. Estructura de la variante de Global_ev para el
algoritmo PSO paralelo
En todo esto, deben tomarse en cuenta algunas consideraciones prácticas para lograr una realización funcional del
algoritmo PSO paralelo en un dispositivo GPU:
A. Sobrecarga (overhead)
Fuente: Autores.
Figura 5. Estructura de la variante Global_ev+up para el
algoritmo PSO paralelo
El dispositivoGPU presenta cierta sobrecarga de comunicación debido a las transferencias de memoria entre el CPU
anfitrión y el dispositivo GPU. Como estas transferencias
son relativamente lentas, cualquier código paralelo para un
dispositivoGPU debe minimizar su empleo. Considerando
la sobrecarga de comunicación, es de esperarse que las variantes globales (Global_ev y Global_ev+up) resulten más
lentas que la incrustada, debido a los intercambios de información entre el CPU anfitrión y el dispositivo GPU durante
la ejecución del algoritmo. El intercambio de información es
necesario, sobretodo en lo relativo a las variantes globales,
ya que el procesador anfitrión debe conocer la información
generada, tanto en el módulo de actualización como en el
de evaluación, antes de tomar cualquier decisión.
B. Sincronización
Fuente: Autores.
Figura 6. Estructura de la variante incrustada para el algoritmo
PSO paralelo
Antes de cualquier alternativa de toma de decisión, por
ejemplo durante el proceso de comparación, todos los hilos
que se ejecutan deben estar sincronizados en los puntos donde se requiere disponer la información sin ambigüedad. Este
punto es de particular importancia cuando los hilos tienen
que comunicarse entre sí para compartir la información,
como lo es en nuestro caso.
C. Competencia
Se debe tener cuidado al trabajar con variables globales que
pueden ser revisadas simultáneamente por varios hilos. Se
necesitan medidas precautorias apropiadas para enfrentar
exitosamente este problema. Específicamente, en el algoritmo PSO esta situación puede presentarse con la variable
que aloja el índice al mejor global. En estos casos, es una
buena práctica emplear una estrategia de comunicación del
tipo maestro-esclavo, adicional a la sincronización de los
hilos, a fin de garantizar que sólo uno de los hilos actualiza
las variables globales con base en la información de todos
los demás.
Fuente: Autores.
68
D. Generación de números aleatorios.
Este es un tema fundamental para la correcta operación del
algoritmo PSO y se hace especialmente crítico cuando la
generación de los números aleatorios es realizada dentro
del dispositivo GPU. Es necesario garantizar que cualquier
llamada a la función rand(), o equivalente que se ejecuta
dentro del dispositivo GPU, generará números aleatorios
de buena calidad (números diferentes para cada llamada
y para cada hilo). Si dicha condición no se garantiza, ello
podría provocar que el algoritmo no converja debido,
fundamentalmente, a una diversidad pobre. Es justamente,
por lo antes expuesto, que en la realización de la variante
incrustada el módulo de inicialización permanece fuera
del dispositivo GPU. Específicamente, las semillas para los
números aleatorios son inicializadas por el anfitrión a razón
de una por cada hilo creado.
1) F01 - Función de Rosenbrock generalizada. (Ec. (4))
con dimensiones n= 30, 60, 120.
2) F02 - Función de Rastrigin Generalizada.(Ec. (5))
VI. Experimentos y resultados
A. Procedimiento experimental
Los experimentos fueron realizados en una computadora
personal con procesador Duo Core de Intel con sistema
operativo Linux, que en este trabajo llamamos el CPU anfitrión. El dispositivo GPU es una tarjeta gráfica NVIDIA
GeForce 8600GT, con 256 Mbytes de la memoria de trabajo
y 4 multiprocesadores, cada uno con 8 núcleos, para hacer
un total de 32 núcleos de procesamiento.
El objetivo esencial es evaluar el desempeño de las variantes paralelas propuestas para PSO en comparación con la
variante secuencial. El desempeño se midió en función de la
complejidad de la función de aptitud, el número de partículas
y el número de iteraciones [25], pero aquí únicamente se
reportan los resultados más representativos, en particular
los que están en términos del número de partículas. Los
algoritmos fueron probados para solucionar algunas conocidas funciones de referencia (bench mark) de optimización
global y numérica [34]. Las siguientes funciones fueron
seleccionadas porque todas ellas son multi-modales y
presentan una complejidad significativa en lo relativo a la
evaluación de la aptitud [27]:
(4)
(5)
3) F03 - Función de Griewank Generalizada. (Ec. (6))
(6)
Los siguientes experimentos fueron realizados para medir el
desempeño de cada una de las variantes PSO programadas:
experimento A, Mediciones del tiempo relativo de procesamiento consumido por cada uno de los módulos funcionales
(es decir, el de evaluación, comparación y actualización)
dentro del algoritmo PSO secuencial; y experimento B,
medición, para cada una de las variantes paralelas de PSO,
del desempeño en función de número de partículas.
69
El objetivo de experimento A es medir, como una referencia,
el tiempo de procesamiento consumido por cada uno de los
módulos funcionales dentro del algoritmo PSO secuencial.
En este experimento los parámetros del algoritmo PSO fueron fijados a 30 dimensiones, 20 vecinos, y 2000 iteraciones,
mientras que se varió el número de partículas. La variante
PSO secuencial fue ejecutada múltiples veces para cada
una de las 3 funciones de referencia probadas, obteniendo
el tiempo promedio consumido, en segundos, para cada
uno de los módulos funcionales, así como la proporción,
en porcentaje, del tiempo total consumido. Los resultados
de este experimento permitieron determinar, en forma empírica, cuáles eran los módulos del algoritmo PSO que más
convenía programar en forma paralela.
El experimento B se realizó para probar la dependencia del
desempeño de las variantes PSO en términos de uno de sus
parámetros fundamentales: el número de partículas.
Después de observar que la optimización de la función de
referencia F03 era la que más tiempo de procesamiento tomaba a la variante secuencial de PSO, se eligió a ésta para
reportar sus resultados a fin de ilustrar el comportamiento
general observado durante la optimización de las tres funciones de referencia probadas.
B. Métricas de desempeño para el procesamiento
paralelo
A fin de evaluar y graficar el desempeño de todas las variantes paralelas de PSO, se definieron las siguientes métricas:
- El aceleramiento, que mide la reducción alcanzada en el
tiempo de ejecución, y
- la eficiencia, que mide el aprovechamiento de los núcleos
de procesamiento disponibles.
Primero, definimos el costo computacional, C, como el
tiempo de procesamiento (en segundos) que consume un
algoritmo. Entonces, el rendimiento computacional, V, se
define como el inverso del costo computacional, según se
observa en Ec. (7):
70
El aceleramiento, S, es entonces un índice que mide qué
tan rápida es la variante de interés en comparación con la
variante de referencia, ver Ec. (8):
(8)
donde
es el rendimiento de la variante paralela de interés y
es el rendimiento de la variante de referencia, en
nuestro caso, la variante secuencial.
Finalmente, definimos la eficiencia paralela E como la razón
que resulta de dividir el aceleramiento entre el número de
núcleos de procesamiento, según se muestra en Ec. (9):
(9)
donde n es el número de núcleos de procesamiento en el
dispositivo GPU (en nuestro caso, 32 núcleos).
VII. Discusión de resultados
A. Experimento A
Se obtuvieron las mediciones del tiempo relativo de procesamiento consumido por cada uno de los módulos funcionales (es decir, evaluación, comparación y actualización)
dentro de la variante secuencial de PSO. Los resultados
experimentales mostraron que, después de optimizar la
tres funciones n-dimensionales de referencia (F01, F02 y
F03), la evaluación de función de aptitud consumió una
proporción relativamente baja del tiempo de procesamiento
total, en comparación con los cálculos empleados durante la
actualización de la velocidad y de la posición (Tabla 1). Esto
se debe a que las operaciones de actualización, aunque con
menor complejidad aritmética, son calculadas más veces que
la evaluación de función de aptitud. Además, el proceso que
genera los números aleatorios puede consumir una cantidad
significativa del tiempo de procesamiento cuando el mismo
procesador que ejecuta el algoritmo PSO es también quien
genera los números aleatorios.
(7)
Tabla 1. Distribución del costo computacional en función del número de partículas
Función
F01
F02
F03
Costo de
evaluación
2.84 %
27.54 %
39.86 %
Proporción del tiempo de ejecución total con 30 dimensiones, 2000 iteraciones
Partículas
64
256
Costo de comparación
Costo de
Costo de comparación Costo de
y actualización
evaluación
y actualización
evaluación
96.59 %
3.03 %
97.25 %
2.03 %
70.34 %
26.93 %
69.38 %
27.16 %
55.24 %
41.31 %
55.81 %
14.88 %
Fuente: Autores.
1024
Costo de comparación y
actualización
97.28 %
69.43 %
35.93 %
Así, los resultados experimentales permiten afirmar que,
para los tres problemas de optimización n-dimensionales,
representados por F01, F02 y F03, la mayor parte del tiempo
de procesamiento del algoritmo PSO es consumido por las
tareas de actualización (posición y velocidad) y no por la
tarea de evaluación de la función de aptitud.
Resumiendo, los resultados experimentales permiten afirmar
que el desempeño de las variantes paralelas Global_ev y
Global_ev+up es menor que el de la incrustada, lo que se
debe, fundamentalmente, a la sobrecarga de comunicación
que resulta de los intercambios de información entre el
computador anfitrión y el dispositivo GPU.
B. Experimento B
Figura 7. Tiempo de procesamiento consumido por las variantes
de PSO, durante la optimización de F03, como función del
número de partículas
Se obtuvieron las mediciones de la dependencia del desempeño, para cada una de las variantes paralelas de PSO, en
términos de número de partículas. En la Figura 7 Se observa
que el desempeño de la variante incrustada es prácticamente invariante al incremento en el número de partículas.
En general, los resultados experimentales muestran que el
desempeño mejora cuando el número de operaciones matemáticas distribuidas al dispositivo GPU también aumenta.
En lo relativo al error (la diferencia entre la solución encontrada y el óptimo), observamos, en todas las variantes, que
al aumentar las iteraciones es posible obtener una solución
muy cercana al óptimo global. Por ejemplo, al fijar 10,000
iteraciones como un punto de partida, se observó que la
variante secuencial tenía un error pequeño y muy uniforme
[25]. Es notable cómo la variante incrustada comienza
con un error ligeramente mayor que las otras variantes,
pero cuando aumenta el número de iteraciones, la solución
obtenida logra la misma precisión para 30,000 y 60,000
iteraciones que, por otra parte, se ejecuta en tan sólo una
fracción del tiempo consumido por la variante secuencial, a
pesar de realizar el mismo número de iteraciones. De hecho,
con 60,000 iteraciones la variante incrustada tiene un error
inferior que el secuencial, con las mismas iteraciones, en
una relación de 5 a 1 [25].
Fuente: Autores.
C. Discusión sobre las métricas de desempeño
En general, el comportamiento observado es consistente
para todas las funciones de referencia probadas. Los resultados experimentales permiten afirmar que el desempeño de
las variantes paralelas mejora notablemente conforme más
cálculos son distribuidos al dispositivo GPU. Las métricas
de desempeño para todas las variantes paralelas de PSO se
presentan en las Figuras 8 y 9.
71
Figura 8. Aceleramiento para las variantes paralelas de PSO
como función del número de partículas
En general, podemos apreciar un mejor desempeño de las
variantes paralelas con relación a la variante secuencial.
Por ejemplo, la optimización de la función de Griewank
generalizada (F03, con elevado costo computacional,
para 60 dimensiones, 60,000 iteraciones y 256 partículas)
le toma 214.13 segundos a la variante secuencial, 136.3
segundos a la variante de Global_ev, y 39.89 segundos a
la variante Global_ev+up. Pero la variante incrustada, la
mejor variante, fue ejecutada en tan solo 7.66 segundos, lo
que representa un aceleramiento de 27.97, comparado con
la variante secuencial, y una eficacia de prácticamente 1
(recuerde que en nuestro caso el dispositivo GPU se compone de 32 núcleos).
Fuente: Autores.
VII. Conclusión y trabajo futuro
Figura 9. Eficiencia para las variantes paralelas de PSO como
función de número de partículas
Fuente: Autores.
Comparando las Figuras 8 y 9, podemos notar que al
aumentar el número de partículas, la eficiencia para las
variantes Global_ev y Global_ev+up se mantiene prácticamente constante, pero se incrementa el aceleramiento.
Esto se debe a que la sobrecarga de comunicación aumenta
proporcionalmente al número de partículas en el caso de
estas variantes (Global_ev y Global_ev+up). En contraste,
la variante incrustada aumenta su eficiencia al aumentar el
número de las partículas.
72
En este trabajo se presentaron los resultados y recomendaciones prácticas que emanan de un estudio reciente relativo
al desempeño de tres variantes paralelas del algoritmo de
optimización por cúmulo de partículas (PSO) en un dispositivo GPU multi-hilos, usando a CUDA como el más
reciente modelo de programación paralela. Los resultados
experimentales muestran que con estas herramientas computacionales es posible obtener códigos paralelos, para un
algoritmo poblacional dado, con una mejora significativa
en el desempeño y mediante una programación paralela
simple y directa.
En general, se demuestra que un código paralelo que únicamente aprovecha la característica multi-hilos del dispositivo
GPU (es decir, exclusivamente la distribución del trabajo en
hilos, sin usar operaciones paralelas en datos múltiples), por
lo menos, produce un aceleramiento proporcional al número
de núcleos del dispositivo GPU, comparado con el algoritmo
secuencial corriendo en un sólo hilo de un único núcleo, con
lo que se obtiene el poder de cómputo de un cluster en una
computadora personal convencional. También se demuestra
que el desempeño total del dispositivo GPU mejora cuando
aumenta la cantidad de tareas simples distribuidas en los
hilos del dispositivo GPU. Este comportamiento se observa
en el desempeño de las tres variantes paralelas propuestas,
pero es más evidente en la variante incrustada, donde el
desempeño alcanzado es considerablemente mejor.
Finalmente, se prevé que el desarrollo de los dispositivos
GPU y su nuevo modelo de programación paralela, en
un futuro cercano, haga realidad el sueño de disponer
de súper-cómputo científico en computadoras personales
convencionales.
En futuras investigaciones se prevé emplear la totalidad
de las capacidades del dispositivo GPU, es decir, emplear
operaciones paralelas sobre múltiples datos además de la
capacidad de administrar múltiples hilos, para aumentar aún
más el desempeño de los algoritmos paralelos propuestos.
VIII. Referencias
[1] A. E. Eiben and J.E. Smith, Introduction to Evolutionary Computing, Natural Computing Series Springer,
2003.
[2] M. Dorigo and T. Stützle, The Ant Colony Optimization Metaheuristic: Algorithms, Applications, and
Advances, Handbook of Metaheuristics, Kluwer
Academic Publishers, 2002, pp. 251-285.
[3] M. Dorigo and K. Socha, “Ant Colony Optimization”,
in Handbook of Approximation Algorithms and Metaheuristics, T.F. Gonzalez, Ed., Chapman & Hall, 2007,
pp. 26.1-26.14.
[4] J. Kennedy and R. Eberhart, “Particle Swarm Optimization”, in Proceedings of IEEE Conference on Neural
Networks, 1995, pp. 1942-1948.
[5] E. Tsang and P. Isasi, “Editorial Special Issue: Computational Finance and Economics”, IEEE Transactions
on Evolutionary Computation, Vol. 13, No. 1, pp. 1-2.
2009.
[6] J. Owens et al., “A Survey of General-purpose Computation on Graphics Hardware”, Computer Graphics
Forum, Vol. 26 No. 1, pp. 80-113. 2007.
[7] E. Cantú-Paz, Efficient and Accurate Parallel Genetic
Algorithms, Kluwer, 2000.
[8] M. Belal and P. El-Ghazawi, “Parallel Models for
Particle Swarm Optimizers”, International Journal
of Intelligent Computing and Information Sciences,
IJICIS, Vol. 4 No. 1, pp. 100-111, January, 2004.
[9] J. Nickolls et al., “Scalable Parallel Programming
with CUDA”, ACM Queue, pp. 40-53, March/April,
2008.[En Línea] Disponible en http://mags.acm.org/
queue/20080304/?u1=texterity.
[10] J.F. Schutte et al., “Parallel Global Optimization with
the Particle Swarm Algorithm”, International Journal
for Numerical Methods in Engineering, Vol. 61 No.
13, pp. 1-24, 2003.
[11] N. Jin and Y. Rahmat-Samii, “Parallel Particle Swarm
Optimization and Finite-difference Time-domain
(PSO/FDTD) Algorithm for Multiband and Wideband Patch Antenna Designs”, IEEE Transactions on
Antennas and Propagation, Vol. 53 No. 11, pp. 34593468, November, 2005.
[12] S. Cui and D. Weile, “Application of a Parallel Particle Swarm Optimization Scheme to the Design of
Electromagnetic Absorbers”, IEEE Transactions on
Antennas and Propagation, Vol. 53 No. 11, pp. 36163624, November 2005.
[13] H. Ma et al., “Research on Parallel Particle Swarm
Optimization Algorithm Based on Cultural Evolution
for the Multi-level Capacitated Lot-sizing Problem”,
in Proceedings IEEE Control and Decision Conference, July 2008, pp. 965-970.
[14] S. Baskar and P.Suganthan, “A Novel Concurrent
Particle Swarm Optimization”, in Proceedings IEEE
Congress on Evolutionary Computation, 2004, pp.
792-796.
[15] J. Chang et al., “A Parallel Particle Swarm Optimization Algorithm with Communication Strategies”,
Journal of Information Science and Engineering, Vol.
21 No. 4, pp. 809-818, 2005.
[16] L. Bo et al., “Parallelizing Particle Swarm Optimization”, IEEE Pacific Rim Conference on Communica-
73
tions, in Computers and Signal Processing, PACRIM,
Aug.2005, pp. 288-291.
[17] S. Mostaghim et al., “Multi-objective Particle Swarm
Optimization on Computer Grids”, in Proceedings of
the 9th Annual Conference on Genetic and Evolutionary Computation, July 2007, pp. 869-875.
[18] K. Parsopoulos et al., “Multiobjective Optimization
Using Parallel Vector Evaluated Particle Swarm
Optimization”, in Proceedings of the IASTED International Conference on Artificial Intelligence and
Applications (AIA), July 2007, pp. 869 - 875.
[19] I. Schoeman and A. Engelbrecht, “A Parallel Vectorbased Particle Swarm Optimizer, Adaptive and
Natural Computing Algorithms”, in Proceedings of
the International Conference in Coimbra. 2005, pp.
268-271.
[20] S. Harding and W Banzhaf, “Fast Genetic Programming on GPUs”, in Proceedings of the 10th European
Conference on Genetic Programming, ser. Lecture
Notes in Computer Science, M. Ebner et al., Eds.,
Vol. 4445, April 2007, pp. 90-101.
[21] S. Harding and W. Banzhaf, “Fast Genetic Programming and Artificial Developmental Systems on
GPUs”, in Proceedings of the 21st International Symposium on High Performance Computing Systems and
Applications, May 2007, p. 2.
[22] W. B. Langdon and W. Banzhaf, “A SIMD Interpreter
for Genetic Programming on GPU Graphics Cards”,
in EuroGP, ser. LNCS, Vol. 4971, March 2008, pp.
73-85.
[23] D. Robilliard et al., “Population Parallel GP on the
G80 GPU”, in Lecture Notes in Computer Science,
Vol. 4971, 2008, pp. 98-109.
[24] J. Li et al., An Efficient Fine-grained Parallel Particle
Swarm Optimization Method Based on GPU-acceleration, International Journal of Innovative Computing,
Information and Control, Vol. 3 No. 6(B), p. 1707,
Dec 2007.
74
[25] G. Laguna, M. Olguín, N. Cruz, R. Barrónand J. Álvarez, “Comparative Study of Parallel Variants for a
Particle Swarm Optimization Algorithm Implemented
on a Multithreading GPU”. Journal of Applied Research and Technology (JART). ISSN: 1665-6423.
Vol.7 No.3, pp. 292-309, 2009.
[26] T. Halfhill, “Parallel Processing with CUDA”, Microprocessor Report, www.MPRonline.com, 2008. [En
Línea] Disponible en http://www.nvidia.com/docs/
IO/55972/220401_Reprint.pdf.
[27] A. Mzoughi, O. Lafontaine, and D. Litaize, “Performance of the Vectorial Processor VECSM2* Using
Serial Multiport Memory”, in Proceedings of the 10th
International Conference on Supercomputing, 1996,
pp. 390-397, Toulouse Cedex, France.
[28] NVIDIA CUDA C Programming Guide, Version 3.2,
NVIDIA Corporation, California, USA, 2010.
[29] CUDA C best practices guide, version 3.2. NVIDIA
Corporation, California, USA, 2010.
[3e0]J. Kennedy and R. Eberhart, Swarm Intelligence,
Morgan Kaufmann Academic Press, 2001.
[31] Y. Shi and R. Eberhart, “A Modified Particle Swarm
Optimizer”, in IEEE International Conference on
Evolutionary Computation Proceedings, May, 1998,
pp. 69-73.
[32] M. O’Neill, and A. Brabazon, “Self-Organising Swarm
(SOSwarm)”, Soft Comput, Vol.12, pp. 1073-1080,
Jan. 2008.
[33] Foster Ian, Designing and Building Parallel Programs:
Concepts and Tools for Parallel Software Engineering,
Addison Wesley, 1995.
[34] E. Mezura-Montes, J. Velázquez-Reyes and C. A.
Coello-Coello, “A Comparative Study of Differential
Evolution Variants for Global Optimization”, GECCO, July 2006, pp. 485-492.

Descargar el archivo PDF

Transcripción

Documentos relacionados

Python + CUDA = PyCUDA

Equipos de Cálculo LinuxVixion basados en GPU

Cuda Básico Parte

Primera parte

Proyecto Fin de Carrera - IIT - Universidad Pontificia Comillas

Arquitectura de Computadores II GPU