INF Programação Distribuída e Paralela

Transcrição

1 INF Programação Distribuída e Paralela Trabalho Final Multiplicação de Matrizes com APIs de Programação Paralela Cristiano Medeiros Dalbem John Gamboa Introdução Neste trabalho comparamos diferentes APIs de programação concorrente em termos de sua programabilidade, ou seja, as facilidades e dificuldades que ela apresenta para a programação, assim como sua eficiência e escalabilidade em benchmarks. Para ajudar a fazer as comparações utilizamos implementações de Multiplicação de Matrizes, um problema que além de ser comum em computação também serve como um símbolo para as vantagens e importância de computação paralela. // C = A * B for (int i = 0; i < size; ++i) { for (int j = 0; j < size; ++j) { for (int k = 0; k < size; ++k) { c[i][j] += a[i][k] * b[k][j]; Listagem 1: Implementação básica do problema de multiplicação de matrizes em C. Nos capítulos seguintes, discutimos separadamente cada uma das APIs e os resultados obtidos em cada uma delas. As implementações todas recebem duas variáveis de entrada: o tamanho das matrizes a serem multiplicadas e o número de threads executando ao mesmo tempo. Para uma mesma combinação de valores de entrada, executamos o algoritmo três vezes e calculamos a média dos tempos resultantes das três execuções. Essa média foi então utilizada na geração dos gráficos apresentados nas seções a seguir. OpenMP De todas implementações paralelas do problema, a de OpenMP sem dúvida foi a mais fácil e rápida. A API oferece uma maneira muito prática e intuitiva de criar blocos paralelos, baseado no uso de pragmas nos locais do programa onde queremos que haja paralelização. Inclusive, são oferecidas diretivas específicas pra paralelizar construções comuns da linguagem, como no nosso caso, a diretiva for.

2 A diretiva for irá fazer automaticamente todo o trabalho de (1) disparar as threads necessárias (2) dividir o trabalho do loop entre elas e (3) sincronizá-las ao final do bloco. double sum; int i,j,k; #pragma omp parallel for shared(a,b,c) private(i,j,k,sum) num_threads(num_threads) for (i = 0; i < size; ++i) { for (j = 0; j < size; ++j) { sum = 0; for (k = 0; k < size; ++k) { sum += a[i][k] * b[k][j]; c[i][j] = sum; Listagem 2: Implementação de multiplicação de matrizes em OpenMP. Dos vários controles disponíveis na API nós utilizamos muito poucos. São eles: shared: como o nome indica, determina quais variáveis são compartilhadas por todas threads. Aqui evitamos maiores overheads e complicações de programação deixando as matrizes de input e a de output em memória compartilhada. private: determina variáveis locais ao escopo de cada thread. Neste caso, os valores dos iteradores e da variável sum não serão compartilhados entre as threads (ainda que o valor inicial dos iteradores serão automaticamente controlados pela diretiva do OMP). num_threads: limita o número de threads que serão disparadas por esse bloco. É importante ressaltar uma pequena otimização feita nesse código. Ao invés do loop mais interno atualizar o valor em c[i][j] a cada multiplicação, utilizamos uma variável local a cada thread (sum) para guardar valores parciais, dessa forma diminuindo o overhead de sincronização das threads que seria necessário para sincronizar o uso da variável c[i][j]. Resultados Testes executados em uma máquina AMD Athlon II X4 630 (4 cores) com 5.8 GiB de RAM. Ubuntu

3 Gráfico 1 Neste gráfico percebemos já as linhas gerais dos comportamentos da implementação pra cada diferente configuração. Como era de se esperar, a solução sequencial ( 1 thread ) é a que consome mais tempo, com uma curva cuja inclinação é bem mais acentuada mas sem perder a cara de exponencial. Em seguida, em ordem decrescente de tempos, estão a execução com 2 threads e 3 threads. A partir de 4 threads não há diferença significativa, o que ocorre pois a máquina rodando os testes possuía 4 cores. Um comportamento interessante observado nos resultados de OpenMP é que não há perda de eficiência pra mais do que 4 threads. Isso seria esperado pois os custos de gerenciamento das threads - criação, destruição, alocação - iria superar o speedup garantido por essa paralelização. A única explicação que encontramos pra isso é que OpenMP de alguma maneira gerencia o excesso de threads, seja limitando o número máximo delas, seja escalonando-as-as de maneira inteligente e não simplesmente passando esse controle ao S.O.. Em MPI tal comportamento não será observado. No gráfico de Speedup, temos os mesmos resultados que já observamos no gráfico de Tempo. Como era de se esperar, os valores são crescentes em proporção ao número de threads, chegando próximo no limiar de 4, que é o número de cores do processador. Consideramos irrelevantes o ranking das execuções a partir de inputs de tamanho 1800x1800.

4 No gráfico de Eficiência temos informações novas e interessantes. Percebemos que a melhor eficiência no uso de paralelismo é da implementação com 2 threads, seguido por perto por 3 e 4 threads, quase empatadas. Depois, como era de se esperar, a eficiciência cai drasticamente para maiores números de threads, já que se torna crescentemente menos eficiente usar mais threads do que cores. MPI Message Passing Interface, ou MPI, é uma API de propósitos mais genéricos que OpenMP. Ela serve como um padrão multi-plataforma para implementação de troca de mensagens em aplicações multithread. Sendo uma API mais genérica, a conversão da implementação de multiplicação de matrizes demandou um esforço maior. Enquanto OpenMP se encarrega se criar e dividir inteligentemente o trabalho entre as threads, em MPI a comunicação e o código executado por cada thread ficam explícitos no código. Não foi possível demonstrar na nossa implementação, mas a biblioteca oferece funções mais sofisticadas do que simples primitivas de send e receive. As chamadas primitivas de Comunicação Coletiva englobam funcionalidades comuns no âmbito de programação paralela/distribuída, sempre envolvendo dispersão e coleta de dados entre threads e operações a serem realizadas sobre esses dados de maneira concorrente. Entretanto, essas primitivas não oferecem maior poder computacional, e são úteis principalmente para melhorar a legibilidade do código, clareando a ideia por trás do algoritmo. Nossa implementação se baseia num conceito simples de Master/Worker Threads. A primeira thread (id = 0) se encarregará de dividir igualmente os dados das matrizes pelas worker threads (as próximas n-1 threads). Sendo assim, a lógica da divisão de tarefas, ou seja, da paralelização da aplicação, se encontra no código da thread mestre, enquanto que o trabalho pesado está no código das threads trabalhadoras. // Receive data from Master MPI_Recv(&offset, 1, MPI_INT, source, 1, MPI_COMM_WORLD, &status); MPI_Recv(&rows, 1, MPI_INT, source, 1, MPI_COMM_WORLD, &status); MPI_Recv(&a, rows*input_size, MPI_DOUBLE, source, 1, MPI_COMM_WORLD, &status); MPI_Recv(&b, input_size*input_size, MPI_DOUBLE, source, 1, MPI_COMM_WORLD, &status);

5 // Matrix multiplication for (k=0; k<input_size; k++) for (i=0; i<rows; i++) { c[i][k] = 0.0; for (j=0; j<input_size; j++) c[i][k] = c[i][k] + a[i][j] * b[j][k]; // Send off results MPI_Send(&offset, 1, MPI_INT, 0, 2, MPI_COMM_WORLD); MPI_Send(&rows, 1, MPI_INT, 0, 2, MPI_COMM_WORLD); MPI_Send(&c, rows*input_size, MPI_DOUBLE, 0, 2, MPI_COMM_WORLD); Listagem 3: Código executado pelas n-1 threads trabalhadoras na implementação de Multiplicação de Matrizes em MPI. Resultados Testes executados em uma máquina AMD Athlon II X4 630 (4 cores) com 5.8 GiB de RAM. Ubuntu Alguns resultados não puderam ser obtidos por limitações de memória da máquina e de limitações da implementação, a qual optamos por manter sem muitas otimizações. Assim como na implementação em OpenMP, temos resultados progressivamente melhores quanto mais threads adicionamos. Entretanto, ao contrário da implementação anterior, percebemos que a partir dum dado momento (50 threads) o acréscimo nesse número começa a não valer mais a pena e os custos de gerenciamento das threads vão tomando conta do tempo de execução total.

6 É interessante notar que a partir de 4 threads temos melhoras crescentes de desempenho até 15 threads, e provavelmente além. Isso se deve provavelmente porque foram utilizadas primitivas de comunicação bloqueantes, que fazem com que uma thread trabalhadora não use todo seu tempo de CPU apenas para operações matemáticas. Tendo um pool de threads de sobra, garantimos que o processador será sempre ocupado por quem está de fato trabalhando, enquanto threads que estão esperando por confirmação de recebimento de mensagens estarão dormindo. O gráfico de eficiência mostra que há um excelente aproveitamento do paralelismo, tendo o pico de eficiência com 4 threads. OpenCL OpenCL é uma plataforma portável de desenvolvimento de programas paralelos, frequentemente voltados a alto desempenho, através da qual é possível delegar tarefas a placas

7 gráficas ligadas ao computador. É interessante notar que placas gráficas não são os únicos periféricos que podem se aproveitar no uso de OpenCL. Um programa em OpenCL é um típico programa em C. Em geral, o código faz uma série de chamadas que preparam o ambiente para uma posterior execução do código paralelo, ocorrida no periférico (no nosso caso, na GPU). O código paralelo (chamado, daqui em diante, de kernel) é escrito em uma linguagem muito parecida com C99, exceto por algumas pequenas modificações. Para a multiplicação de matriz, utilizamos o seguinte kernel: // OpenCL Kernel kernel void matrixmul( global float* C, global float* A, global float* B, int wa, int wb) { // 2D Thread ID // Old CUDA code //int tx = blockidx.x * TILE_SIZE + threadidx.x; //int ty = blockidx.y * TILE_SIZE + threadidx.y; int tx = get_global_id(0); int ty = get_global_id(1); // value stores the element that is computed by the thread float value = 0; for (int k = 0; k < wa; ++k) { float elementa = A[ty * wa + k]; float elementb = B[k * wb + tx]; value += elementa * elementb; // Write the matrix to device memory each thread writes one element C[ty * wa + tx] = value; Listagem 4: Kernel da multiplicação de matrizes em OpenCL O kernel foi então chamado com diferentes tamanhos de bloco. O bloco indica o número de threads rodando simultaneamente na GPU, e é configurado no programa através de parâmetros passados pela linha de comando. O usuário deve passar o tamanho do bloco em x e em y, e o número de threads no bloco será x*y. Uma restrição imposta pela API do OpenCL é que os tamanhos em x e em y das matrizes a serem multiplicadas sejam divisíveis pelos tamanhos em x e em y do bloco. Por esse motivo é que os tamanhos dos blocos utilizados foram frequentemente potências de 2, salvo em dois dos casos testados. É também por essa causa que não pudemos usar os mesmos tamanhos de matrizes utilizados nos testes com MPI e OpenMP. Outra dificuldade encontrada foi o fato de que havia um limite no número de blocos a serem executados pela placa gráfica. Ao exceder esse limite, a chamada à execução do kernel OpenCL

8 retornava a constante CL_OUT_OF_RESOURCES. É interessante notar também que aos exemplos presentes no site da Nvidia falta um Makefile, a ausência do qual nos causou-nos dificuldade em usá-los. Em versões anteriores dos mesmos exemplos pudemos encontrar o Makefile faltante. Resultados Testes executados em uma GPU Nvidia G210M, com 16 CUDA cores e 256Mb de RAM. Ubuntu Alguns resultados não puderam ser obtidos por limitações de hardware e limitações da implementação, a qual optamos por manter sem muitas otimizações. A imagem acima mostra os tempos encontrados para diferentes números de threads. As curvas encontradas assemelham-se àquelas encontradas quando da utilização das outras APIs. Nota-se um ganho de performance próximo do ideal ao utilizarmos um número baixo de threads. À medida que esse número aumenta, nos aproximamos de um limite a partir do qual passamos a não mais ganhar, mas perder, ao aumentarmos o número de threads.

9 O gráfico de Speedup mostra de maneira clara que esse limite, apesar de próximo, mesmo assim ainda não foi atingido. É interessante notar que a eficiência segue a tendência das outras APIs e permanece maior quando o número de threads é menor. Pode-se dizer que em execuções com muitas threads são poucas as que realmente executam algum trabalho ou que trazem algum ganho substancial em performance.

10 CUDA CUDA é uma API plataforma de desenvolvimento de programas paralelos exclusivamente em placas gráficas produzidas por sua criadora: a Nvidia. Bem como acontece com OpenCL, sua principal concorrente, um programa em CUDA utiliza uma linguagem muito próxima de C, exceto por algumas adições. O nvcc, que compila código em CUDA, delega a compilação de código não relacionado à placa gráfica (normalmente chamada de device) ao compilador existente no ambiente de programação (frequentemente, o gcc) e se limita a compilar código para o device. Um programa em CUDA geralmente segue o mesmo padrão já descrito de um em OpenCL: é feita uma série de chamadas a funções que preparam o ambiente para a execução do kernel, que é então executado em paralelo na GPU. O kernel utilizado em nossa implementação é muito parecido com aquele utilizado na implementação em OpenCL: // CUDA Kernel global void matrixmul( float* C, float* A, float* B, int wa, int wb) { // 1. 2D Thread ID int tx = blockidx.x * blockdim.x + threadidx.x; int ty = blockidx.y * blockdim.y + threadidx.y; // value stores the element that is computed by the thread float value = 0; for (int i = 0; i < wa; ++i) { float elementa = A[ty * wa + i]; float elementb = B[i * wb + tx]; value += elementa * elementb; // Write the matrix to device memory each thread writes one element C[ty * wa + tx] = value; Listagem 5: Kernel da multiplicação de matrizes em CUDA Em CUDA, um bloco é um conjunto de threads a ser rodado paralelamente na GPU. Cada Streaming Multiprocessor presente na placa gráfica suporta até 8 blocos rodando ao mesmo tempo, contanto que haja recursos para que todas as threads dos 8 blocos executem. Se não houver recursos suficientes (como memória ou registradores), o CUDA runtime seleciona um número menor de blocos a serem executados ao mesmo tempo. O número máximo de threads em um mesmo bloco é 512, distribuídas em até 3 dimensões (x, y, e z). Para fazermos nossas medidas, o kernel foi chamado com diferentes tamanhos de bloco tanto em x quanto em y. Novamente, tivemos de garantir que o tamanho das matrizes a serem multiplicadas tenham tamanhos divisíveis pelos tamanhos dos blocos. Para manter a consistência com OpenCL, os mesmos tamanhos de bloco foram utilizados. Esses valores (tamanho das matrizes e tamanho em x e em y dos blocos) podiam ser passados como parâmetro ao programa. Uma dificuldade encontrada foi o erro

11 the launch timed out and was terminated, que ocorria sempre que o kernel demorava tempo demais para executar. Buscas na internet nos levaram à conclusão de que eliminar o erro envolveria a necessidade de outra placa gráfica ligada ao mesmo computador. Por essa causa, não conseguimos medir o tempo para matrizes muito grandes e blocos muito pequenos. Resultados Testes executados em uma GPU Nvidia G210M, com 16 CUDA cores e 256Mb de RAM. Ubuntu O gráfico acima mostra os tempos para variados números de threads por bloco. Como se pode ver, o número de amostras foi bastante limitado, dadas as dificuldades que tivemos. Mais: não tínhamos certeza de o quanto aumentar o número de threads num mesmo bloco aumentaria a performance, dado que o CUDA runtime poderia escalonar mais de um bloco para rodar ao mesmo tempo quando o número de threads em cada bloco fosse pequeno o suficiente. É possível perceber, porém, um expressivo ganho de performance conforme o número de threads no bloco aumenta, o que parece indicar que há somente um bloco rodando de cada vez. Os tempos absolutos de cada execução, mesmo assim, foram bastante altos, excedendo em muito os tempos encontrados ao usarmos OpenCL. Além disso, havíamos lido que a performance de implementações em CUDA é frequentemente melhor que a de implementações em OpenCL, já que CUDA poderia aproveitar melhor a arquitetura das placas gráficas ao não se preocupar com portabilidade (apesar de isso não ser uma regra). Ainda: se o número de blocos executando ao mesmo tempo (o qual, como dito, era regido pelo CUDA runtime) poderia ser maior que um, como é possível que a performance da implementação em CUDA tenha sido tão ruim?

12 Ao discutir sobre essas questões na apresentação, concluímos que talvez o problema estivesse no fato de a nossa implementação não utilizar dos artifícios disponibilizados pela arquitetura CUDA para melhorar a performance dos acessos à memória, que temos como principal suspeita da queda da performance. Como já discutido, preferimos manter a implementação simples, dado que esta não é o nosso foco no trabalho. Apesar de não tão expressivos, os Speedups seguem o mesmo padrão daqueles da implementação em OpenCL: o aumento do número de threads causa um aumento no Speedup; o número de threads com que conseguimos executar o algoritmo não alcança o limite a partir do qual o ganho de performance começa a diminuir.

13 A eficiência, contrariando nossas expectativas, não seguiu a regra: execuções com mais threads tiveram melhores resultados. Conclusão Os gráficos gerados para essa seção foram feitos levando em conta os tamanhos de matrizes que melhor representavam o comportamento geral dos experimentos. OpenMP MPI Na comparação entre as duas APIs de paralelização para processadores multicore obtivemos resultados semelhantes, com apenas alguns detalhes interessantes a se comentar.

14 Percebe-se claramente como OpenMP gerencia de alguma forma o excesso do número de threads, dando valores muito parecidos para quando temos mais threads do que cores. Em MPI há uma melhora gradual até alcançar um limiar onde o overhead do gerenciamento do alto número de threads começa a piorar a performance da aplicação como um todo. OpenMP obteve na média resultados melhores que MPI. Porém, a partir de 4 threads a gerência do excesso de threads em OpenMP ocasionou num pior aproveitamento em comparação com MPI. Dessa maneira, MPI obteve valores máximos de speedup melhores (com 8 e 15 threads).

15 No gráfico de eficiências percebemos que OpenMP foi mais inteligente na divisão de carga de trabalho do que o método utilizado em MPI. Isso se nota até que o número de threads supere o de cores, depois disso os melhores speedups do programa em MPI resultam em eficiências melhores. No geral OpenMP oferece formas muito mais intuitivas para paralelizar aplicações, e para o caso de Multiplicação de Matrizes (que é um caso simples) permitiu boa eficiência no uso de recursos de computação concorrente. Como vantagem, MPI permite maior customização na forma como a computação será dividida entre as threads, então seria mais recomendável para aplicações onde a performance é muito importante. OpenCL CUDA O gráfico a seguir mostra uma comparação dos tempos encontrados em diferentes execuções da multiplicação de matrizes de tamanho 512x512.

16 Aqui, ficam evidentes as diferenças de performance entre as implementações em CUDA e OpenCL. Reiteramos que é muito provável que as diferenças de tempo não estejam relacionadas à API, mas às implementações, que, apesar de similares, provavelmente utilizam de forma diferente os recursos da GPU. Os gráficos de Speedups e Eficiência somente refletem o que os outros gráficos anteriormente já apresentaram, demonstrando a superioridade da implementação em OpenCL em relação à implementação em CUDA.

17 Apesar da performance inferior, OpenCL mostrou-se muito mais difícil de programar. Consideramos a implementação em CUDA muitíssimo mais clara, legível e intuitiva de programar. Foi também mais fácil encontrar o CUDA SDK e documentação relacionada a CUDA. Por outro lado, enquanto não houve qualquer comportamento estranho ao rodar o programa em OpenCL, o computador frequentemente travava ao longo da execução dos programas em CUDA, destravando somente após o seu fim.