Proposta de Melhoria de uma Implementação Paralela para GPUs Usando CUDA - Estudo de Caso em Modelo Atmosférico

Proposta de Melhoria de uma Implementac¸˜ao Paralela

para GPUs Usando CUDA - Estudo de Caso

em Modelo Atmosf´erico

Fabiano Cassol de Vargas∗, Matheus Beniz Bieger†, Claudio Schepke 1_{Laborat´orio de Estudos Avanc¸ados (LEA) – Curso de Ciˆencia da Computac¸˜ao}

Universidade Federal do Pampa (UNIPAMPA) CEP: 97.546-550 – Alegrete – RS – Brasil

{cassol.fabiano,matheusbieger,schepke}@gmail.com

Resumo. O uso de aceleradores do tipo GPUs ´e uma alternativa para agregar performance a aplicac¸˜oes que demandam uma grande quantidade de proces-samento. Tal arquitetura requer t´ecnicas de programac¸˜ao bastante espec´ıficas, uma vez que ´e necess´ario distribuir a tarefa paralela a cada kernel executado em GPU. Nesse sentido, este artigo investiga quais aspectos devem ser observados para garantir a maximizac¸˜ao do uso dos recursos computacionais em GPUs. Como estudo de caso, utilizou-se um prot´otipo de uma aplicac¸˜ao de modelagem atmosf´erica. A partir da realizac¸˜ao de an´alises de ocupac¸˜ao da GPU e profile da aplicac¸˜ao ´e poss´ıvel constatar que o desempenho paralelo est´a relacionado com a modelagem apropriada do conte´udo executado em cada kernel CUDA.

1. Introduc¸˜ao

Em diversas ´areas da Computac¸˜ao Cient´ıfica existem algoritmos que geram alto custo computacional. Uma alternativa para acelerar a execuc¸˜ao destes algoritmos consiste na execuc¸˜ao concorrente do c´odigo, tornando a obtenc¸˜ao das soluc¸˜oes num´ericas fact´ıvel ou obtidas em um tempo de processamento aceit´avel. Por causa disso, diversas aplicac¸˜oes encontram-se em constante desenvolvimento, com diversas alterac¸˜oes de c´odigo, acom-panhando as mais recentes tendˆencias nos sistemas computacionais de alto desempenho. Estas aplicac¸˜oes s˜ao imprescind´ıveis para diversos aspectos do cotidiano, economia e progresso da ciˆencia, como ´e o caso do controle de tr´afego, previs˜ao de precipitac¸˜ao, monitoramento de pacientes m´edicos, entre outros tipos de problema/aplicac¸˜ao.

Atualmente, tem-se visto profundas transformac¸˜oes na estrutura das arquiteturas computacionais. Aceleradores altamente especializados, tais como GPUs, com v´arios n´ucleos simples de processamento tˆem sido amplamente utilizadas como uma soluc¸˜ao eficiente e vi´avel na busca por maior poder de processamento. Assim, em diversas publicac¸˜oes s˜ao mencionados ganhos significativos de desempenho (200_{×) em relac¸˜ao} a uma vers˜ao sequencial para o caso de aplicac¸˜oes simples. Por´em, tais implementac¸˜oes s˜ao recentes e apresentam resultados preliminares ou ainda n˜ao aplicados a aplicac¸˜oes com grande demanda computacional.

∗_{Bolsista do Programa Institucional de Bolsas de Iniciac¸˜ao Cient´ıfica do Conselho Nacional de}

Desen-volvimento Cient´ıfico e Tecnol´ogico - PIBIC/CNPq 2013.

†_{Bolsista do Programa Institucional de Bolsas de Iniciac¸˜ao Cient´ıfica do Conselho Nacional de}

Aplicac¸˜oes com grande demanda de processamento tradicionalmente s˜ao desen-volvidas utilizando interfaces padr˜ao de programac¸˜ao com diversas implementac¸˜oes, tais como o MPI (Message-Passing Interface) em mem´oria distribu´ıda (multi-computadores e multi-processadores) e OpenMP em mem´oria compartilhada (multi-processadores e multi-core). Um desafio recorrente ´e portar aplicac¸˜oes pr´e-existentes para processado-res especializados (GPGPUs) uma vez que nem todos os trechos de c´odigo beneficiam-se desbeneficiam-se tipo de paralelismo. Fazer uso desbeneficiam-se tipo de arquitetura requer aspectos de programac¸˜ao distintos, e que, portanto, devem ser investigados apropriadamente para ga-rantir a maximizac¸˜ao do aproveitamento dos recursos computacionais.

Neste sentido, o objetivo deste trabalho ´e identificar poss´ıveis estrat´egias para melhorar o desempenho de uma aplicac¸˜ao de modelagem atmosf´erica cujos m´etodos s˜ao executados em GPUs. Trata-se do Ocean-Land-Atmosphere Model (OLAM) [Walko and Avissar 2008], criado por Robert L. Walko e Roni Avissar na Duke Uni-versity. A identificac¸˜ao de tais estrat´egias, implementadas em CUDA, pode auxiliar na maximizac¸˜ao do uso das GPUs para outros tipos de aplicac¸˜ao similares.

Este artigo est´a dividido em 7 sec¸˜oes. A pr´oxima sec¸˜ao aborda o uso da interface de programac¸˜ao CUDA. Na Sec¸˜ao 3 s˜ao apresentados os trabalhos relacionados. Os am-bientes de teste e recursos utilizados s˜ao descritos na Sec¸˜ao 4. Na Sec¸˜ao 5 ´e feita uma an´alise de desempenho via profiling dos testes realizados. Com base nos resultados obti-dos, propostas de melhorias s˜ao discutidas na Sec¸˜ao 6. Por fim, a conclus˜ao do trabalho ´e apresentada juntamente com as expectativas para trabalhos futuros.

2. Trabalhos Relacionados

Nos trabalhos de [Osthoff et al. 2011] e [Osthoff et al. 2012], s˜ao realizados diversos ex-perimentos sobre o OLAM implementado com diferentes interfaces de programac¸˜ao pa-ralela, como MPI, OpenMP e CUDA. Nos testes realizados com o OLAM implementado com MPI e CUDA, foi constatado que o desempenho da aplicac¸˜ao diminui para mais de dois processos MPI. Al´em disso, ´e dito que para melhorar a performance para esta implementac¸˜ao ´e necess´ario aprimirar a c´opia de dados entre a mem´oria da CPU e a mem´oria da GPU. O fato ´e que o OLAM possui muita dependˆencia entre essas c´opias de mem´oria e as func¸˜oes executadas em GPU, o que ´e um gargalo de desempenho, visto que ´e poss´ıvel sobrepor c´opias de mem´oria com execuc¸˜ao em GPU.

Em [Vargas and Schepke 2014], foram feitos as primeiras an´alises que originaram o estado do trabalho atual. Os resultados iniciais mostraram que a aplicac¸˜ao n˜ao demons-trou ganho de desempenho relevante, obtendo apenas um speedup pr´oximo de 2.

No trabalho de [Rosso et al. 2013], o modelo OLAM, implementado com MPI, foi testado com diferentes casos de teste, onde varia-se o tempo de simulac¸˜ao do globo antes e depois de realizar refinamento em tempo de execuc¸˜ao. Foi concluido que o OLAM tem seu desempenho melhorado a medida que mais processos MPI executam a aplicac¸˜ao, e que o refinamento dinˆamico da malha influencia diretamente no tempo de execuc¸˜ao dos casos de teste.

J´a nos estudos de [Pydd et al. 2014], o OLAM, tamb´em implementado com MPI, foi testado com tempos iguais de simulac¸˜ao antes e depois do refinamento dinˆamico da malha terrestre. Foi constatado que o tempo de execuc¸˜ao diminui pela metade quando se usa o dobro de processos MPI.

3. Ambiente de Testes e Recursos Utilizados

Foi utilizada uma Workstation Dell Precision T7600 com dois Intel Xeon E5-2650 de 2.00GHz. S˜ao duas GPUs instaladas. A Tesla C2075 [NVIDIA Tesla C2075 2011] pos-sui 448 n´ucleos CUDA de 1147 MHz, mem´oria de 6GB GDDR5 de 1566 MHz e barra-mento de mem´oria de 384 bits. A Quadro 5000 [NVIDIA Quadro 5000, 2013] possui 352 n´ucleos CUDA de 1026 MHz, mem´oria de 2,5GB GDDR5 de1494 MHz e barramento de mem´oria de 320 bits. Comum a ambas as GPUs: Compute Capability 2.0; 32 n´ucleos por multiprocessador; 32.768 registradores por bloco de threads; m´aximo de 1.024 threads por bloco; m´aximo de 1.536 threads por multiprocessador.

Como recursos para realizar profiling da aplicac¸˜ao, foram utilizados o nvprof e o NVIDIA Visual Profiler, parte do [NVIDIA CUDA Tool Kit 2014]. O nvprof foi utilizado para executar o programa e coletar dados que ajudassem a analisar o seu desempenho. Os dados de sa´ıda foram direcionados para um arquivo que pudesse ser importado no NVIDIA Visual Profiler, o qual provˆe uma interface gr´afica intuitiva de grande ajuda na an´alise dos dados coletados.

Outra ferramenta utilizada ´e a CUDA GPU Occupancy Calculator da NVIDIA, feita no Microsoft Excel, para c´alculo de ocupac¸˜ao de GPU, dispon´ıvel juntamente com o [NVIDIA CUDA Tool Kit 2014]. Informando na planilha a capacidade de computac¸˜ao da GPU, o n´umero de threads por bloco e o n´umero de registradores utilizados por thread (obtido com a opc¸˜ao --ptxas-options=-v para o compilador), a planilha calcula a ocupac¸˜ao de cada multiprocessador da GPU para um determinado kernel.

4. An´alise de Desempenho e Testes

Os testes iniciais apresentados por [Vargas and Schepke 2014], realizados nas GPUs cita-das na Sec¸˜ao 3, mostraram que o modelo Tesla C2075 obteve melhores resultados devido `as suas configurac¸˜oes de hardware (n´ucleos CUDA, mem´oria, etc) superiores. Com base neste fato, esta GPU foi adotada para os trabalhos posteriores com o modelo OLAM.

Ap´os a avaliac¸˜ao anterior, foi feita uma revis˜ao geral da aplicac¸˜ao, visando identi-ficar poss´ıveis problemas. Nesta revis˜ao, ao analisar as opc¸˜oes de compilac¸˜ao e execuc¸˜ao do programa, foi feita uma alterac¸˜ao. O parˆametro -arch, que define para qual arquite-tura a aplicac¸˜ao ser´a compilada, deve estar de acordo com a capacidade de computac¸˜ao da GPU a ser utilizada. Na Sec¸˜ao 3, vimos que o dispositivo Tesla C2075 possui ca-pacidade de computac¸˜ao 2.0 (arquitetura Fermi), logo sua arquitetura ´e identificada pela opc¸˜ao -arch=sm 20. Por´em, a aplicac¸˜ao estava sendo compilada com -arch=sm 35 (ca-pacidade de computac¸˜ao 3.5 - arquitetura Kepler), o que n˜ao ´e recomendado segundo o CUDA Compiler Drive NVCC - Reference Guide[NVIDIA NVCC 2013], pois o conjunto de instruc¸˜oes ´e diferente entre as arquiteturas e a compatibilidade n˜ao ´e garantida. Com isso, passa a ser usado -arch=sm 20, de modo a garantir a correta execuc¸˜ao do programa conforme a arquitetura da GPU utilizada.

Posteriormente, foi realizada uma an´alise utilizando a CUDA GPU Occupancy Calculatorda NVIDIA. S˜ao implementados trˆes kernels na aplicac¸˜ao, e compilando com a opc¸˜ao --ptxas-options=-v, foram retornados os seguintes n´umeros de registradores: ker-nel1, 63 registradores; kernel2, 63 registradores; e kernel3, 35 registradores. Analisando a planilha, notou-se que a ocupac¸˜ao dos multiprocessadores da GPU, para blocos de 1.024

Figura 1. Resultados. Aplicac¸ ˜ao compilada com -arch=sm 20.

threads, era 0% para todos os kernels. Sabendo que o n´umero de registradores por mul-tiprocessador da GPU ´e de 32.768, blocos de 1.024 threads para os kernels da aplicac¸˜ao n˜ao executam. Por exemplo, 1.024 threads multiplicadas por 35 registradores do kernel3 ´e igual a 35.840 registradores, logo, um bloco desse tamanho n˜ao pode ser atribuido a um multiprocessador por necessitar de mais registradores do que o dispon´ıvel. O mesmo c´alculo vale para os outros dois kernels, que necessitam 63 registradores.

Para provar o que se concluiu na an´alise da planilha, foram executados os seguin-tes casos de seguin-teste: o modelo foi configurado para executar com duas resoluc¸˜oes horizon-tais distintas para a malha global, sendo 100km e 50km; para cada resoluc¸˜ao, utilizou-se blocos de threads de tamanhos diferentes, sendo 128, 256, 512 e 1.024 threads. No total s˜ao oito casos de teste e para todos o tempo de simulac¸˜ao do globo terrestre ´e 12 horas. Os resultados s˜ao vistos na Figura 1, onde percebe-se que o tempo de execuc¸˜ao para as simulac¸˜oes cujos kernels s˜ao lanc¸ados com blocos de 1.024 threads ´e consideravelmente menor do que os demais. De acordo com a planilha da NVIDIA, blocos de 1.024 threads n˜ao executam por demandarem mais registradores do que o dispon´ıvel em hardware. Isso implica na n˜ao execuc¸˜ao em GPU, o que prejudica os resultados, pois apenas o c´odigo de CPU ´e executado. Devido a isso, o tempo de execuc¸˜ao para os casos de 1.024 thre-ads refletem a execuc¸˜ao em CPU bem como as c´opias de mem´oria entre CPU e GPU, sem processamento em GPU. De modo a concretizar tal expectativa, outra an´alise foi necess´aria.

O pr´oximo passo foi realizar profiling da aplicac¸˜ao utilizando o nvprof. As informac¸˜oes foram direcionadas para um arquivo de sa´ıda que pode ser importado no NVI-DIA Visual Profiler. Esta ferramenta permite analisar uma linha do tempo da execuc¸˜ao da aplicac¸˜ao, bem como dos kernels, onde percebeu-se que, de fato, n˜ao foram executados os kernels com blocos de 1.024 threads, apenas os menores (128, 256 e 512 threads). Na Figura 2, observa-se a timeline da execuc¸˜ao do programa, onde um retˆangulo destaca os trˆes kernels, mostrando que os mesmo executam. J´a na Figura 3, a timeline n˜ao mostra nenhum kernel executado, de acordo com o que se esperava a partir da an´alise realizada com a planilha da NVIDIA.

Figura 2. Timeline do NVIDIA Visual Profiler para a aplicac¸ ˜ao com blocos de 128 threads para todos os kernels.

Figura 3. Timeline do NVIDIA Visual Profiler para a aplicac¸ ˜ao com blocos de 1.024 threads para todos os kernels.

5. Propostas de Melhorias

Reduzir o n´umero de c´opias entre a mem´oria da CPU e a mem´oria da GPU ´e um fator de grande impacto para se acelerar o desempenho de uma aplicac¸˜ao CUDA. Nas Figuras 2 e 3 percebe-se que as c´opias de mem´oria s˜ao frequentes, pois elas ocorrem intercaladas com as chamadas dos kernels, como observado nas linhas espec´ıficas de MemCpy (c´opias de mem´oria) e Compute (execuc¸˜ao dos kernels) - o mesmo ´e representado em apenas uma linha mais abaixo, no Stream Default. Realizar a c´opia de v´arios dados de uma s´o vez traz vantagens quanto `a vaz˜ao de dados que pode ser maximizada.

CUDA permite a execuc¸˜ao concorrente de c´opia de mem´oria ass´ıncrona com execuc¸˜ao de kernels na GPU. Conforme j´a observado nos trabalhos de [Osthoff et al. 2011] e [Osthoff et al. 2011] sobre o OLAM, a n˜ao implementac¸˜ao disso gera um gargalo na performance da aplicac¸˜ao. Assim, uma proposta ´e tentar eliminar as dependˆencias de dados que existem na implementac¸˜ao atual do prot´otipo do modelo OLAM e implementar essas duas tarefas concorrentemente. Para isso, uma outra ac¸˜ao pode ser necess´aria: analisar os dados que s˜ao computados em cada kernel e reestruturar os kernels, podendo divid´ı-los em mais func¸˜oes. Com isso, al´em de c´opia de mem´oria ass´ıncrona, haveria mais kernels executando na GPU, havendo a possibilidade de execu-tarem concorrentemente entre eles se eliminadas as dependˆencias de dados.

6. Conclus˜ao e Trabalhos Futuros

Aplicac¸˜oes que demandam alto desempenho podem beneficiar-se com o surgimento de novas arquiteturas paralelas, como ´e o caso de GPUs. No entanto, neste caso ´e necess´ario o uso de uma interface de programac¸˜ao apropriada, como CUDA, que exige a reescrita e a adaptac¸˜ao de c´odigo. De forma espec´ıfica, neste artigo investigou-se algumas propostas de modificac¸˜ao de c´odigo para uma aplicac¸˜ao atmosf´erica implementada para GPUs.

Para tanto, foram feitas observac¸˜oes da taxa ocupac¸˜ao de processamento dos mul-tiprocessadores, an´alise via profiling, propostas de pequenas alterac¸˜oes de c´odigo, como o uso de memcpy ass´ıncrono, e propostas de modificac¸˜ao maiores, como a reestruturac¸˜ao dos kernels, tentando prover mais processamento concorrente para a GPU e eliminar de-pendˆencia de dados entre os kernels.

Como trabalhos futuros, pretende-se avaliar o impacto dessas modificac¸˜oes no desempenho da aplicac¸˜ao. Tais estrat´egias podem ser expandidas para outros modelos atmosf´ericos, bem como aplicac¸˜oes similares, tais como as que utilizam a t´ecnica de decomposic¸˜ao de dom´ınios.

Referˆencias

NVIDIA CUDA Tool Kit (2014). NVIDIA CUDA Tool Kit - Webpage. NVIDIA NVCC (2013). CUDA Compiler Driver NVCC - Reference Guide. NVIDIA Tesla C2075 (2011). NVIDIA Tesla C2075 - Webpage.

Osthoff, C., Schepke, C., Panetta, J., Grunmann, P. J., Dias, P. L. S., Kassick, R. V., Boito, F. Z., Navaux, P. O. A., Lopes, P. P., Fabricio, and Souto, R. P. (2011). GPU for Accelerators Performance Evaluation on Atmosphere Model’s Application System. In Proceedings of XXX Iberian-Latin-American Congress on Computational Methods in Engineering, 2011, Ouro Preto. Mecanica Computacional Vol. XXX.

Osthoff, C., Souto, R., Dias, P. S., Panetta, J., and Lopes, P. (2012). Atmospheric Model Cluster Performance Evaluation on Hybrid MPI/OpenMP/Cuda Programming Model Platform. In Proceedings of XXI International Conference of the Chilean Computer Science Society.

Pydd, E. B., Karlinski, T. R., and Schepke, C. (2014). Avaliac¸˜ao de Desempenho do Modelo OLAM 3.0 com Processos MPI em Arquitetura de Mem´oria Compartilhada. In XIV Escola Regional de Alto Desempenho do Estado do Rio Grande do Sul - ERAD/RS 2014.

Rosso, J. P., Schepke, C., and Vargas, F. C. (2013). Avaliac¸˜ao de Desempenho do Refina-mento Dinˆamico de Malhas em Modelo Climatol´ogico Global. In Proceedings of XIV Workshop em Sistemas Computacionais de Alto Desempenho - Workshop de Iniciac¸˜ao Cient´ıfica (WSCAD-WIC).

Vargas, F. C. and Schepke, C. (2014). Avaliac¸˜ao de Desempenho de uma Implementac¸˜ao com CUDA do Ocean-Land-Atmosphere Model. In XIV Escola Regional de Alto De-sempenho do Estado do Rio Grande do Sul - ERAD/RS 2014.

Walko, R. L. and Avissar, R. (2008). The Ocean-Land-Atmosphere Model (OLAM). Part I: Shallow-Water Tests. Monthly Weather Review, 136:4033–4044.