Esqueletos Algorítmicos para Paralelismo de Tarefas em Sistemas Multi-GPU

Transcrição

1 Esqueletos Algorítmicos para Paralelismo de Tarefas em Sistemas Multi-GPU Fernando Alexandre, Ricardo Marques, and Hervé Paulino CITI / Departamento de Informática Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa Caparica, Portugal Resumo A crescente utilização de Unidades de Processamento Gráfico (GPUs) na computação de caráter geral levanta questões de desempenho e de escalabilidade. Para responder a estes requisitos de forma efetiva, cada vez mais se recorre à utilização colaborativa de vários GPUs num só sistema. Esta abordagem introduz, no entanto, novos desafios, tal como a decomposição do domínio do problema e a gestão da possível heterogeneidade dos dispositivos. Neste contexto assume particular relevância a proposta de abstrações que escondam a complexidade da programação destes sistemas. Existe já algum trabalho na área, mas este restringese ao paralelismo de dados. Por conseguinte, neste artigo abordamos a utilização de uma biblioteca de esqueletos algorítmicos, Marrow, para a exploração de paralelismo de tarefas em sistemas computacionais com estas características. Os resultados são promissores, apresentado a escalabilidade esperada nos sistemas testados. 1 Introdução O GPU tem, cada vez mais, assumido um papel de relevo na resolução de problemas que possam beneficiar de paralelismo centrado nos dados, exemplos são o processamento numérico, a prospeção de dados (data-mining), simulações físicas, entre outros [1]. Com a crescente popularidade deste paradigma surgiu a necessidade de lidar com questões de escala e melhorar o desempenho, em termos de tempos de resposta e de quantidade de trabalho efetuado por unidade de tempo. Por conseguinte, emergiu recentemente uma nova tendência que recorre à utilização colaborativa de múltiplos GPUs dentro de uma só máquina [2, 3]. As plataformas base para computação de caráter geral em GPUs - GPGPU (General Programming on Graphics Processing Units) - OpenCL [4] e CUDA [5] oferecem algum suporte para computação em múltiplos dispositivos. No entanto, o nível de abstração é bastante baixo; o nível de conhecimentos de programação paralela exigido no contexto de um único dispositivo são subsequentemente amplificados. Além da gestão explícita dos espaços de memória e a orquestração Este trabalho foi parcialmente financiado pela FCT-MCTES através do PEst- OE/EEI/UI0527/ Centro de Investigação em Informática e Tecnologias e utilizou equipamento adquirido no âmbito dos projectos PTDC/EIA-EIA/102579/2008 e PTDC/EIA-EIA/111518/2009.

2 das operações que devem ser executadas pelos dispositivos, o programador deve agora também assumir a responsabilidade de decompor a computação pelos diversos GPUs, possivelmente heterogéneos, e considerar detalhes arquiteturais, como a eventual partilha de barramentos (bus) pelos mesmos. Neste contexto torna-se imperativo a proposta de abstrações que, por um lado, escondam a complexidade da programação destes sistemas computacionais, e por outro, sejam úteis na resolução de problemas que beneficiem de execução com múltiplos GPUs. Esta área tem recebido particular atenção, com várias propostas a endereçar o paralelismo de dados [6, 7], que mapeia naturalmente no modelo de execução subjacente. No que se refere à exploração do paralelismo de tarefas, a área é muito recente e com muitos desafios por endereçar, particularmente no contexto multi-gpu. Que seja do nosso conhecimento, para além da biblioteca Marrow [8] que será a base deste trabalho, apenas é suportado o encadeamento de tarefas, pipelining, sem suporte multi-gpu em [9] ou restrito a um dado domínio, como o processamento de streams em [10, 11]. O Marrow é uma biblioteca de esqueletos algorítmicos para a orquestração de computações OpenCL. Destaca-se das restantes disponíveis para GPGPU [6,7,12 14] por ser a primeira a suportar esqueletos para paralelismo de tarefas e propor o aninhamento destes mesmos esqueletos como ferramenta para a criação de árvores de computação de complexidade arbitrária. Nesta medida, o objetivo deste trabalho é permitir que computações Marrow possam executar em vários GPUs num só nó computational, com particular ênfase no paralelismo de tarefas. Pretende-se utilizar esqueletos algorítmicos para usufruir da capacidade de abstração da complexidade inerente às computações paralelas, delegando ao sistema de execução a decomposição da computação, a adaptação de acordo com a heterogeneidade dos dispositivos e endereçar possíveis otimizações nas transferências de dados entre os múltiplos espaços de memória. As contribuições deste trabalho são portanto: 1 - a proposta de esqueletos para paralelismo de tarefas em sistemas multi-gpu, tirando partido do aninhamento de esqueletos para o cálculo de computações complexas (Secção 3); 2 - um sistema de execução capaz de distribuir a computação de uma tarefa por múltiplos dispositivos, possivelmente heterogéneos (Secção 4); 3 - uma avaliação comparativa do desempenho dos esqueletos propostos relativamente à execução num único GPU (Secção 5). 2 Biblioteca de Esqueletos Algorítmicos Marrow Marrow é uma biblioteca de esqueletos algorítmicos com o objetivo de orquestrar computações OpenCL em vários GPUs. Para criar computações complexas, o Marrow suporta aninhamento de esqueletos algorítmicos, sendo que este pode ser representado através de uma árvore onde os nós intermédios introduzem comportamentos sobre a sua sub-árvore até chegar às folhas, que contém as computações OpenCL (kernels). Os esqueletos algorítmicos escolhidos para in-

3 Pipeline Pipeline Pipeline Estágio 1 Estágio 2 Estágio 4 Estágio 5 Figura 1. Aninhamento de pipelines. clusão na biblioteca têm em conta a sua utilidade na área de GPGPU, sendo que os seguintes são suportados: Pipeline define uma sequência de computações dependentes pelos dados, em que os dados de saída resultantes de um estágio são passados para a entrada da computação seguinte. Os dados intermédios entre dois estágios são mantidos no respetivo GPU de forma a evitar transferências de dados desnecessárias e caras. Uma instância deste esqueleto suporta apenas dois estágios. É no entanto possível utilizar aninhamento para criar estruturas com um número arbitrário de estágios, como apresentado na Figura 1. Loop permite a execução iterativa de uma computação de acordo com uma condição de paragem definida pelo programador. O esqueleto permite modelar os comportamentos dos esqueletos For e While [15] que diferem pelo facto que a condição de paragem pode depender dos dados intermédios da iteração corrente (While) ou não (For). Ambas as variantes do esqueleto suportam aninhamento. Map permite aplicar uma árvore de computação em paralelo a um conjunto de dados. MapReduce é uma extensão do Map que permite que um passo posterior de redução seja este executado no GPU, utilizando internamente um Pipeline, ou no CPU. Nenhum destes esqueletos permitem aninhamento pois precisam de deter controlo sobre os dados residentes na memória do host para iniciar a execução e transferências de dados. Exemplo de Programação A Listagem 1 apresenta a um exemplo que faz uso de um Pipeline com dois estágios de computação, sendo o primeiro um FFT (Fast Fourier Transformation) e o segundo, o seu inverso. A árvore de computação é construída de baixo para cima, iniciando-se com a criação das folhas, instâncias de KernelWrappers que representam as computações em si (kernels, linha 2), seguindo-se o aninhamento incremental nos esqueletos desejados (linha 3 4). Uma vez criada, a arvore de computação pode receber múltiplos pedidos de execução. Estes recebem como argumento o conjunto de dados (composto por escalares e/ou vetores) sobre o qual a árvore vai ser aplicada. Vetores em Marrow são instâncias da classe Vector, que abstrai as operações de decomposição necessárias para a execução multi-gpu (linhas 6 9). A função de submissão (linha 11) devolve imediatamente a referência ao objeto Future que permite à aplicação esperar pelo fim da execução da árvore, tal como acesso aos dados resultantes.

4 1 // Computation Tree Allocation 2 std :: unique_ptr < IExecutable > fft ( new KernelWrapper( kernelfile, " fft1d_512 ", ininfo, outinfo, globalworksize )); 3 std :: unique_ptr < IExecutable > ifft ( new KernelWrapper( kernelfile, " ifft1d_512 ", ininfo, outinfo, globalworksize )); 4 std :: unique_ptr < IExecutable > pipe ( new Pipeline (fft, ifft )); 5 // Request skeleton executions ; Vector Creation 6 std :: vector <std :: shared_ptr <Vector >> inputvectors (1) ; 7 inputdata [0] = std :: shared_ptr <Vector >( new Vector ( input, sizeof ( cl_float2 ), size )); 8 std :: vector <std :: shared_ptr <Vector >> outputvectors (1) ; 9 outputdata [0] = std :: shared_ptr <Vector >( new Vector ( output, sizeof ( cl_float2 ), size )); 10 // Execution Requests 11 future = pipe -> write ( inputvectors, outputvectors ); 12 // Wait for results ; Computation tree de - allocation : delete pipe Listing 1. Pipeline de FFTs e a sua operação inversa 3 Orquestração do Loop e Pipeline Nesta secção é descrita a orquestração necessária para a implementação dos esqueletos para paralelismo de tarefas presentes no Marrow, nomeadamente Loop e Pipeline, seguido de considerações relacionadas ao aninhamento de esqueletos. Condição Step (2) (4) Loop GPUs (5) Input (1) Computação (3) Output (6) Sistema de Execução Figura 2. Orquestração do Loop GPUs Input Stage1 Middle Stage2 Output Pipeline (1) (2) Sistema de Execução (3) (4) Figura 3. Orquestração do Pipeline Orquestração do Loop A Figura 2 apresenta os passos principais na execução do Loop. Os dados são inicialmente transferidos para os GPUs (1). De seguida, iniciam-se as iterações, seguido pelo teste da condição (2), sendo que se assume que a condição é inicialmente válida. A condição de paragem pode ou não depender do conjunto de dados de saída da computação, assemelhando-se a um For e While respetivamente. Caso esta for verdadeira é lançada a execução das árvores de computação nos GPUs (4). É utilizada uma função de step para evoluir os valores necessários pela condição de paragem (5), e imediatamente a seguir é efetuada uma sincronização de dados que tenham sido modificados pela função

5 step (1) e são trocados os dados de entrada com os dados de saída em preparação da próxima iteração (6). Para suportar múltiplos GPUs, o While precisa garantir que os passos relacionados à função de evolução step sejam sincronizados entre as várias tarefas, para esta ser apenas calculada uma vez, e apenas quando os dados de todas as partições estão disponíveis. Orquestração do Pipeline A Figura 3 ilustra os passos principais da orquestração realizada pelo Pipeline. Este começa por transferir os dados de entrada para os vários GPUs (1), seguindo-se a computação sequencial dos dois estágios (2 e 3), sendo que os resultados do primeiro, já presentes nos GPUs, são utilizados como dados de entrada do segundo. Por fim, os resultados da segunda execução são transferidos para a memória principal (4). Em ambos os esqueletos é necessário que exista compatibilidade nos dados de entrada e saída, nomeadamente entre dois estágios do Pipeline e na entrada e saída do Loop. Uma consideração importante, é que esta compatibilidade tem de transpor para as várias decomposições criadas pelo Marrow. Aninhamento de Esqueletos O aninhamento permite a criação de computações complexas através da composição de um número arbitrário de esqueletos aninhados, apenas limitada pela quantidade de memória disponível nos GPUs. Que seja do nosso conhecimento, o Marrow é o único sistema a suportar este nível de composicionalidade no contexto GPGPU, o que levanta uma série de desafios. O suporte de aninhamento requer que os esqueletos tenham comportamentos diferenciados, dependendo se se encontram, ou não, na raiz da árvore de computação. Tal deve-se ao facto de todo o controlo sobre a computação e interação com o hospedeiro estar concentrado na raiz. Desse modo, o fluxo da computação e da partilha dos dados desce ao longo da árvore. A raiz é responsável por transferir os dados (do e para o hospedeiro) e por desencadear a computação, orquestrando subsequentemente a(s) sua(s) sub-árvore(s) (emitindo pedidos de execução e comunicando as necessárias referências para dados) de acordo com o comportamento que fatoriza. Estas sub-árvores assumem, por sua vez, essas mesmas responsabilidades perante a sua descendência, até que seja atingindo uma folha, caso em que a computação associada é executada. 4 Sistema de execução Nesta secção apresentamos a arquitetura e modelo de execução do Marrow. A arquitetura, representada na Figura 4, está organizada em três camadas principais, sendo que cada uma só tem visão da camada abaixo. O programador apenas tem acesso à camada da biblioteca de esqueletos, possibilitando a criação de árvores de computação, com esqueletos ou computações OpenCL (KernelWrapper), com a ajuda de um conjunto de contentores que descrevem os tipos de dados válidos para uma computação OpenCL. A camada de execução é utilizada pela biblioteca para lidar com a plataforma, seja para a decomposição do domínio, utilizando

6 Aplicações Biblioteca de Esqueletos MapReduce Loop Pipeline Tipos de Dados Kernel Map For Vector KernelWrapper Sistema de Execução KernelBuilder Scheduler Excepções Contentores PartitionInfo ExecutionPlatform Task Launcher Auto-Tuner Task Dispositivos OpenCL Figura 4. Arquitectura do Marrow o Auto-Tuner, para distribuir tarefas pelos GPUs com o Scheduler ou para o lançamento de tarefas com o TaskLauncher. Por sua vez, o modelo de execução (Figura 5) está dividido em dois estágios principais: decomposição estática do domínio e pedidos dinâmicos de execução. O primeiro é iniciado com a criação do Skeleton (1) que desencadeia um pedido ao Scheduler para a decomposição das suas estruturas de entrada/saída (2). Para levar a cabo tal tarefa, o Scheduler recorre a dados de desempenho predeterminados (3), recolhidos no ato de instalação da biblioteca utilizando o Shoc Benchmark Suite [16]. A descrição das partições é de seguida organizada numa estrutura (4), que é guardada na informação associada às respetivas computações (KernelWrapper) aninhadas na árvore de computação (5). O segundo estágio inicia quando o programador submete um pedido execução ao esqueleto algorítmico, fornecendo o conjunto de dados ao qual quer aplicar a computação (6). É criado e devolvido um objeto Future (7, 8) que permite o acesso ao estado da computação (se terminou, ou não) tal como para acesso aos dados quando esta acaba. O programador pode então escolher esperar que a computação acabe (9), ou continuar execução até precisar dos resultados. O pedido é então submetido para o Scheduler, que utilizando as já criadas (10), adicionaas às filas de tarefas de cada GPU para serem executadas (11). A emissão dos comandos de execução e transferência de dados para o GPUs está a cargo do TaskLauncher. Para tal, este dispõe de um conjunto de threads que consomem os pedidos de execução da fila (12), transferem os dados de entrada para o dispositivo alvo e emitem os pedido de execução (13). Por fim quando todas as tarefas associadas a um pedido de execução terminam, o TaskLauncher notifica o Future que a computação acabou (14), que por sua ver notifica qualquer aplicação bloqueada à espera dos resultados (15). 4.1 Decomposição do Domínio A decomposição estática dos dados de entrada é efetuada utilizando o módulo Auto-Tuner, que permite a utilização de dados empíricos de desempenho para criar cargas de trabalho adequadas para os GPUs presentes no sistema. Neste contexto, o Auto-Tuner calcula o desempenho relativo entre todos os GPUs e as partições são criadas de acordo com este rácio. O desempenho relativo é na

7 Decomposição Estática de Domínio (9) (15) (8) Future Aplicação Skeleton (1) (6) (5) (7) Skeleton Pedido Dinâmico de Execução Partições GPU #1: P11 P12... P1n GPU #2: P21 P22... P2n (14) (2) Ref. (4) (10) Sistema de Execução (3) Scheduler (11) T(P1n)... T(P12) T(P11) T(P2n)... T(P22) T(P21) TaskLauncher (13) (12) GPU #1 GPU #2 Figura 5. Fluxo de execução do Marrow. realidade calculado em duas métricas: cálculo de precisão simples e dupla. A classificação no Marrow de que métrica utilizar não é perfeita, visto que o Auto-Tuner apenas tem acesso aos tipos de dados dos argumentos e não é analisado o código da computação OpenCL. Dado que apenas consideramos neste trabalho computações com paralelismo de dados e operações do tipo stencil (com fronteiras partilhadas) não são ainda suportadas, tem de existir uma correspondência entre os conjuntos de dados de entrada e de saída. Para ajudar o utilizador é possível, no entanto, definir um tamanho indivisível, pelo qual o Auto-Tuner adere de forma a possibilitar restrições na decomposição dos dados. 5 Resultados Experimentais Esta secção tem o objetivo de avaliar o desempenho dos esqueletos Marrow para paralelismo de tarefas quando transpostos de um para um para vários GPUs. Não comparamos com computações OpenCL puras, dado que Ricardo et al. já o fizeram em [8] com bons resultados. Começamos por descrever os casos de estudo escolhidos, seguido de uma breve discussão sobre o impacto do barramento PCIe na performance geral de aplicações em GPUs e finalmente são apresentados os resultados dos casos de estudo. Neste contexto, apresentamos quatro testes. O primeiro caso de estudo é um encadeamento de filtros de imagem, constituído por dois pipelines e três filtros, nomeadamente Gaussian Noise, Solarize e Mirror. Estes requerem que seja decomposto por tamanho de linha sendo que esta restrição é passada como tamanho indivisível ao Auto-Tuner. O segundo é um conjunto de Fast-Fourier Transformations (FFTs) de 512kB cada, adaptados do Shoc Benchmark Suite. Este é composto por um Pipeline em que o primeiro estágio é o FFT e o segundo é a sua inversa. É designado a cada GPU um certo número de FFTs, sendo que é utilizado o tamanho de um FFT como o tamanho indivisível para decomposição no Auto-Tuner.

8 Pipeline de filtros FFT N-Body (pixels) (MBytes) (número de corpos) Input parameter size S 1 tempo de execução (ms) S 2 tempo de execução (ms) Tabela 1. Tempos de execução com um GPU em milisegundos. O terceiro e último caso de estudo é uma simulação N-Body em que são iterativamente calculados os efeitos de forças num sistema de dinâmico de corpos (bodies). Este é decomposto pelo número de partículas (uma região) a calcular por cada decomposição. Visto que este teste precisa de acesso a todos os outros corpos do sistema, é necessário que todo o conjunto de entrada esteja disponível em todos os GPUs na sua integralidade, tal como a sincronização ao fim de cada iteração da simulação. Este caso de estudo é implementado utilizando um Loop com uma condição de paragem semelhante a um For. A única diferença é que é necessário forçar a sincronização dos dados de entrada para todos os GPUs, simplesmente marcando-os como modificados na função de evolução step. Foram utilizados dois sistemas distintos para avaliar os casos de estudos: S 1 S 2 tem um Intel(R) Xeon(R) E GHz, com uma motherboard ASUS P6T7, 12 GB de RAM, e três GPUs: duas NVidia Tesla C1060 e uma NVIDIA Quadro FX A configuração dos GPUs é C1060 :: FX3800 :: C1060. tem um Intel(R) Core(TM) i7-3930k 3.20GHz, com uma motherboard ASUS P9X79 PRO, 32 GB de RAM, e duas AMD Radeon HD É importante notar que o S 2 ao contrário do S 1 suporta uma configuração com duplo x16 PCIe possibilita fatores de aceleração escalarem linearmente na transferência de dados para dois GPUs versus um único GPU. Este facto foi confirmado com o nosso benchmark de transferência de dados. Em contraste, o S 1, apesar de apresentar um melhoramento na taxa de utilização do barramento PCIe, este não é linear, apresentando ganhos de 40% quando se utiliza dois GPUs e 54% quando se utiliza os três. Desempenho Os casos de estudo têm o objetivo de avaliar a nossa abordagem em termos da escalabilidade. Os tempos de execução estão limitados ao tempo entre a submissão e obtenção dos resultados, excluindo o tempo de inicialização e tempos de decomposição do domínio. Este último apenas calculado uma vez, e tem um tempo de execução mínimo, sem ultrapassar 0.15ms. A Tabela 1 apresenta os tempos base de execução usando um GPU. Na Figura 6 podemos ver os fatores de aceleração de múltiplos GPUs para os quatro casos de estudo apresentados previamente, em relação à execução no Marrow utilizando apenas um GPU. Cada caso de estudo foi executado 500 vezes, as suas durações foram guardadas e ordenadas e apenas temos em conta um terço dos valores situados no meio da lista.

9 2.00 Fator de Aceleração ^2 4096^2 8192^2 128 MB 256 MB 512 MB Pipeline de Filtros (pixels) FFT (tamanho dos dados) N- Body (número corpos) (S1) 2 GPUs (S1) 3 GPUs (S2) 2 GPUs ^2 4096^2 8192^2 3 GPU 2 GPU 1 GPU 3 GPU 2 GPU 1 GPU 3 GPU 2 GPU 1 GPU 0% 20% 40% 60% 80% 100% Execução Transferência de dados e orquestração Figura 6. Fatores de aceleração versus execução com um GPU. Figura 7. Decomposição do pipeline de filtros de imagem em S1. Sendo que no sistema S 1, temos um conjunto de GPUs heterogéneos, o desempenho relativo calculado pelo Marrow para o tamanho das partições é: C1060 (36%) :: FX 3800 (27%) :: C1060 (37%). Desta forma o fator de aceleração máximo para dois e três GPUs 1.75 e 2.70 respetivamente. Estes, no entanto, são os valores ótimos que não têm em conta o barramento PCIe partilhado entre os três GPU, limitando mais os fatores de aceleração possíveis em problemas com tamanhos significativos de transferências. Na Figura 7 podemos observar a decomposição do tempo de execução numa computação limitada pela transferência de dados, sendo que esta relação entre tempo de computação e tempo de transferência é indiretamente proporcional ao número de GPUs. No nosso conjunto de casos de teste, o pipeline de filtros de imagens tem esta característica, sendo que apresentam os melhores resultados em problemas de tamanho médio com um fator de aceleração máximo de 1.85 com três GPUs. O FFT, em contraste, tem um peso de computação mais significante, que se pode ver na escalabilidade constante, apesar de não ser linear, sendo o valor mais elevado de A simulação N-Body, utiliza um algoritmo O(N 2 ), apresentando uma carga computacional extrema, que contabiliza entre 88% (para problemas pequenos) e 98% (para um número elevado de corpos). Para ter melhor performance, este tira partido de memória local de cada grupo de trabalho no GPU para otimizar o acesso aos dados em memória global. Esta característica implica que o tamanho do trabalho de grupo local tem um papel importante no desempenho desta computação. O Auto-Tuner neste momento não tenta otimizar este parâmetro, sendo que neste momento os grupos de trabalho são forçados para serem múltiplos de 64 (variando no tamanho, de acordo com o tamanho da partição). Esta é uma medida temporária, e proporciona um tradeoff entre granularidade da decomposição dos conjuntos de dados (mantendo alguma precisão em relação à proporção de desempenho dos GPUs) e o tamanho dos grupos

10 de trabalho locais possíveis. Este facto pode-se observar na escalabilidade, por vezes super-escalabilidade, mas que não se aplica a todos os casos devido à flutuação implícita do tamanho dos grupos locais de trabalho presente no sistema S 1. No caso do sistema S 2, devidos aos GPUs serem homogéneos, temos resultados consistentes, visto que o tamanho do grupo local de trabalho se tornar constante dado haver decomposições iguais, este possibilita uma escalabilidade proporcional ao tamanho do problema, sendo interessante mencionar que obtém um fator de aceleração 1.77 para corpos neste caso de estudo apesar de este caso não estar apresentado devido à instabilidade do desempenho no S 1 no estado corrente do Marrow. Esta escalabilidade deve-se à elevada capacidade de computação dos GPUs, que se pode observar na Tabela 1 em relação às placas presentes em S 1. Em geral os tempos de execução no S 2 apresentam um grau de escalabilidade melhor, devido, não só à potência já mencionada dos GPUs, mas também do facto de existirem barramentos PCIe dedicados. Tal como no N-Body, todos os testes escalam proporcionalmente com o tamanho do conjunto de dados, mostrando fatores de aceleração perto ou acima de Trabalho Relacionado Já existe alguma investigação de construções pipeline no contexto GPGPU, nomeadamente Lime [9], StreamIt [10] e NMM [11]. O Lime é uma linguagem compatível com o Java que permite computação em sistemas com um único GPU de forma transparente. Pipelines são possíveis utilizando uma operação nova (=>), encadeando filters, a unidade de computação. O StreamIt e NMM são trabalhos que tiram partido de stream processing, um modelo de programação que permite a computação de fluxos contínuos de dados. Ambos suportam múltiplos GPUs, e as computações podem ser representadas utilizando um grafo orientado, onde cada nó é uma computação. No StreamIt o grafo é particionado, utilizando um algoritmo iterativo de coarsening/uncoarsening que permite a partição do grafo tendo em conta os requisitos de cada nó e analisando os caminhos dos dados. Esta abordagem permite também minimizar a migração de dados entre GPUs. O NMM suporta clusters, sendo que se baseia no alto número potencial de GPUs disponíveis para distribuir apenas um nó de computação do grafo para cada GPU. Existe um alto nível de migração de dados neste sistema, sendo que é necessário que cada nó de computação seja pesado o suficiente para que o overhead da transferência seja minimizado. No contexto dos esqueletos algorítmicos, não existe nenhum sistema que implemente Pipeline nem Loop no contexto GPGPU. Do nosso conhecimento, apenas três bibliotecas suportam computação em múltiplos GPUs. O primeiro é o SkelCL [6] que oferece um conjunto de esqueletos que tira partido de paralelismo de dados, nomeadamente Map, Reduce, Zip e Scan. Para o suporte multi-gpu, o SkelCL usa decomposição estática dos conjuntos de dados e distribui estas usando políticas predeterminadas. O segundo é o SkePU [7] que se foca também em esqueletos que tiram partido de paralelismo de dados tais como Map, Reduce e variantes do Map, MapOverlap

11 e MapArray. O seu suporte para múltiplos GPU é conseguido através de integração do StarPU [17]. Este utiliza paralelismo de tarefas com work-stealing num ambiente com vários GPUs e clusters. O terceiro é o Muesli [18], que suporta clusters com múltiplos cores e GPUs usando CUDA. Os esqueletos suportados são Pipeline, Farm, DivideAndConquer, BranchdAndBound, Fold, Map, Scan e Zip, sendo que apenas os quatro últimos são suportados para execução GPU. O Pipeline é semelhante ao presente no Marrow, podendo ser utilizado para a orquestração explícita de execuções em CPUs, no entanto, este não tem suporte para GPUs. Não existe muita informação sobre o funcionamento das execuções com múltiplos GPUs, e o código disponível não apresenta suporte para execução GPU. No entanto, pela informação existente consegue-se concluir que todo o particionamento e agendamento de tarefas é delegado ao programador. O Marrow distingue-se das bibliotecas de esqueletos mencionadas ao implementar esqueletos novos (Pipeline e Loop) no contexto GPGPU utilizando múltiplos GPUs. O modelo interno de execução do Marrow assemelha-se vagamente ao presente no SkePU, pois ambos utilização paralelismo de tarefas internamente. Em relação aos trabalhos de processamento de fluxos de dados, há uma diferença obvia em modelo de programação, sendo que o Marrow é mais flexível nos tipos de computação possíveis pelo programador. 7 Conclusões Neste trabalho apresentamos o Marrow, uma biblioteca de esqueletos algorítmicos, para a execução de computações complexas em sistemas contendo múltiplos GPUs. Do nosso conhecimento o Marrow é a primeira biblioteca de esqueletos algorítmicos a implementar, neste contexto, esqueletos que tiram partido de paralelismo de tarefas, nomeadamente o Loop e Pipeline. Os resultados apresentam escalabilidade significativamente consistente, exceto no caso do N-Body, que introduz novas considerações relacionadas a ambientes com GPUs heterogéneos, que não são ainda consideradas no Marrow. Estas estão intrinsecamente associadas ao tamanho do grupo local de trabalho quando se utiliza a memória local para implementar técnicas de caching. Discutimos também o impacto que a configuração do barramento PCIe tem em vários tipos de computação, através dos dois sistemas apresentados na avaliação do Marrow, em que um sistema está equipado com barramentos PCIe dedicados a cada GPU, e o outro tem um barramento partilhado entre três GPUs. O Marrow está ainda em desenvolvimento pelo que existem ainda vários tópicos de investigação a endereçar. Uma nova abordagem seria a designação de tarefas utilizando work-stealing. É também possível melhorar a decomposição do domínio de duas formas: (1) introduzindo otimizações relativas à configuração dos grupos locais de trabalho e (2) decompondo a árvore de computação e distribuindo-a pelos GPUs. Esta última abordagem implica também a utilização de técnicas que minimizem a migração de dados, devido ao elevado custo inerente ao barramento PCIe.

12 Referências 1. hgpu.org: High performance computing on graphics processing units - Applications. (consultado em Junho 2013) 2. Gu, L., Li, X., Siegel, J.: An empirically tuned 2D and 3D FFT library on CUDA GPU. In: ICS 10, ACM (2010) Lalami, M.E., Baz, D.E., Boyer, V.: Multi GPU implementation of the simplex algorithm. In: HPCC 11, IEEE (2011) Munshi, A., et al.: The OpenCL Specification. Khronos OpenCL Working Group. (2009) 5. NVIDIA Corporation: NVIDIA CUDA. home_new.html (last visited in June 2013) 6. Steuwer, M., Kegel, P., Gorlatch, S.: Towards High-Level Programming of Multi- GPU Systems Using the SkelCL Library. In: IPDPSW 12, IEEE Computer Society (2012) Dastgeer, U., Enmyren, J., Kessler, C.: Auto-tuning SkePU: a multi-backend skeleton programming framework for multi-gpu systems. In: IWMSE 11, ACM (2011) Marques, R., Paulino, H., Alexandre, F., Medeiros, P.D.: Algorithmic skeleton framework for the orchestration of GPU computations. In: Euro-Par Number 8097 in Lecture Notes in Computer Science, Springer-Verlag (2013) Dubach, C., Cheng, P., Rabbah, R.M., Bacon, D.F., Fink, S.J.: Compiling a highlevel language for GPUs: (via language support for architectures and compilers). In: PLDI 12, ACM (2012) Huynh, H.P., Hagiescu, A., Wong, W.F., Goh, R.S.M.: Scalable framework for mapping streaming applications onto multi-gpu systems. In: PPOPP 12, ACM (2012) Repplinger, M., Slusallek, P.: Stream processing on GPUs using distributed multimedia middleware. Concurrency and Computation: Practice and Experience (2011) Ernsting, S., Kuchen, H.: Algorithmic skeletons for multi-core, multi-gpu systems and clusters. IJHPCN 7(2) (2012) AMD Corporation: Bolt C++ Template Library. tools/heterogeneous-computing/ (consultado em Junho 2013) 14. Hoberock, J., Bell, N.: Thrust: A parallel template library (consultado em Junho 2013) 15. González-Vélez, H., Leyton, M.: A survey of algorithmic skeleton frameworks: high-level structured parallel programming enablers. Softw., Pract. Exper (2010) Danalis, A., Marin, G., McCurdy, C., Meredith, J.S., Roth, P.C., Spafford, K., Tipparaju, V., Vetter, J.S.: The scalable heterogeneous computing (SHOC) benchmark suite. In: GPGPU 10, ACM (2010) Augonnet, C., Thibault, S., Namyst, R., Wacrenier, P.A.: StarPU: A unified platform for task scheduling on heterogeneous multicore architectures. In: Euro-Par 09, Springer (2009) Ernsting, S., Kuchen, H.: Algorithmic skeletons for multi-core, multi-gpu systems and clusters. Int. J. High Perform. Comput. Netw. (2012)