Padrões e Frameworks de Programação Paralela em Arquiteturas Multi-Core

Transcrição

1 Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Programa de Pós-Graduação em Ciência da Computação Padrões e Frameworks de Programação Paralela em Arquiteturas Multi-Core Dalvan Griebler Orientador: Luiz Gustavo Fernandes Relatório Técnico N o 064 Porto Alegre, Janeiro de 2011

2 Resumo A computação paralela vem crescendo rapidamente em termos de desempenho, um dos adventos é o modelo arquitetural multi-core. Entretanto, não bastam estar disponíveis tais arquiteturas multiprocessadas, se estas não são exploradas devidamente. A maior parte dos programadores de código sequencial se negam a dedicar seus esforços para trabalhar com este paradigma, pela complexidade apresentada no tratamento de problemas. Depuração, condições de corrida, sincronização de threads ou processos e controle de acesso aos dados são exemplos de fatores críticos para estes ambientes paralelos. Novas maneiras de abstrair a complexidade em lidar com estes sistemas estão sendo estudadas, a fim de que a programação paralela seja algo comum para os desenvolvedores de software. Neste sentido, o objetivo deste trabalho é estudar e fazer um levantamento teórico sobre os mecanismos utilizados para melhorar a programação paralela em ambientes multi-core. Padrões paralelos vêm sendo o alvo de constantes estudos com intuito de padronizar a programação paralela. A padronização foi um dos primeiros passos em direção a melhores implementações para o espaço de projeto de algoritmos paralelos. No entanto, uma implementação eficiente com estes padrões nem sempre é possível. Depende do programador se a modelagem e os cuidados com relação ao acesso de dados foram corretamente tratados. Padrões paralelos determinísticos tornaram-se o mais atual objeto de pesquisa no cenário de programação paralela (multi-core). O propósito deles é possíbilitar o desenvolvimento de programas eficientes mantendo uma única ordem na execução, similar ao que se tem nos algoritmos sequenciais. Além disso, fornecem determinismo na execução dos programas eliminando a necessidade de condições de corrida. O desenvolvimento de frameworks passou a ser uma solução para ajudar os programadores nesta tarefa, abstraindo parte da complexidade em lidar com os problemas frequentes, visando rapidez e facilidade na aprendizagem e desenvolvimento de programas paralelos.

3 Lista de Figuras 2.1 Encontrando Concorrência. Adaptado de [1] Estruturas de Algoritmos. Adaptado de [1] Estruturas de Apoio. Adaptado de [1] Mecanismos de Implementação. Adaptado de [1] Map Parallel Pattern Reduction Parallel Pattern Superscalar Sequences Parallel Pattern Pipeline Parallel Pattern Nesting Parallel Pattern Scan Parallel Pattern Recurrences Parallel Pattern Partition Parallel Pattern Speculation Selection Parallel Pattern Gather Parallel Pattern Search Parallel Pattern Stencil Parallel Pattern Scatter Parallel Pattern Permutation Scatter Parallel Pattern Atomic Scatter Parallel Pattern Merge Scatter Parallel Pattern Priority Scatter Parallel Pattern Pack Parallel Pattern Expand Parallel Pattern Split Parallel Pattern Arquitetura FastFlow. Extraído de [2] Intel Parallel Studio. Extraído de [3]

4 Lista de Tabelas 2.1 Relacionamento entre os padrões de estruturas de apoio e ambientes de programação. Extraído de [1] Relacionamento entre os padrões de estruturas de apoio e padrões de estrutura algoritmos. Extraído de [1]

5 Lista de Símbolos e Abreviaturas SPMD Single Process, Multiple Data 11 SIMD Single Instruction, Multiple Data 11 NUMA No Uniform Memory Access 13 MPI Message Passing Interface 21 OpenMP Open MultiProcessor 21 3

6 Sumário LISTA DE FIGURAS 1 LISTA DE TABELAS 2 LISTA DE SÍMBOLOS E ABREVIATURAS 3 Capítulo 1: Introdução Motivação e Objetivos Organização do Trabalho Capítulo 2: Padrões de Programação Paralela Encontrando Concorrência Padrão de Decomposição de Tarefas Padrão de Decomposição de Dados Padrão de Grupo de Tarefas Padrão de Ordenção de Tarefas Padrão de Compartilhamento de Dados Padrão de Avaliação de Projeto Estrutura de Algoritmo Padrão de Paralelismo de Tarefas Padrão de Divisão e Conquista Padrão de Decomposição Geométrica Padrão de Recursão de Dados Padrão de Pipeline Padrão de Coordenação Baseada em Eventos Estruturas de Apoio Padrão SPMD (Single Program, Multiple Data) Padrão Mestre/Escravo Padrão de Paralelismo de Laço

7 2.3.4 Padrão Fork/Join Padrão de Compartilhamento de Dados Padrão de Compartilhamento de Fila Padrão de Array Distribuído Escolhendo Padrões para o Projeto de Algoritmos Paralelos Mecanismos de Implementação Gerenciamento de Threads e Processos Sincronização Comunicação Capítulo 3: Programação Paralela com Padrões Estruturados e Determinísticos Padrões de Computação Paralela Map Pattern Reduction Pattern Superscalar Sequences Pattern Pipeline Pattern Nesting Pattern Scan Pattern Recurrences Pattern Partition Pattern Speculative Selection Pattern Padrões de Gerenciamento de Dados Paralelos Gather Pattern Search Pattern Stencil Pattern Scatter Pattern Permutation Scatter Pattern Atomic Scatter Pattern Merge Scatter Pattern Priority Scatter Pattern Pack Pattern Expand Pattern Split Pattern Capítulo 4: Frameworks para Programação Paralela Multi- Core FastFlow TBB (Threading Bulding Blocks)

8 4.3 SWARM (SoftWare and Algorithms for Running on Multicore) Intel Parallel Studio Capítulo 5: Conclusão 49 6

9 1 Introdução A indústria de processadores tem como objetivo melhorar o desempenho computacional através do emprego de diversas formas de paralelismo. Para tanto, hardwares paralelos estão presentes nos principais equipamentos ou plataformas computacionais atuais. Estações de trabalho, servidores, supercomputadores, ou até mesmo sistemas embarcados fazem parte desta exploração de paralelismo para prover maior desempenho em suas respectivas plataformas. Esta abordagem de baixo nível de paralelismo direciona o desenvolvedor para mecanismos de programação mais complexos e com pouca portabilidade. Somente um pequeno número de programadores encara este desafio, a grande maioria não se sujeita a aprender e trabalhar neste nível. Até mesmo programadores profissionais tentam ignorar a programação paralela, pelos problemas que esta abordagem necessita tratar nos mais diversos ambientes de arquiteturas. Computadores em um contexto geral já suportam multithreading ou multicore. A decomposição de tarefas e de dados é uma forma de abstrair a complexidade na exploração de paralelismo destes processadores. Sendo que o escalonamento das threads ou processos é de responsabilidade do sistema operacional realizar a distribuição da carga entre os elementos de processamento. Mesmo havendo esta abstração, desenvolver programas paralelos não é uma tarefa trivial. Implica que o programador entenda da arquitetura alvo para que sejam possíveis maiores níveis de escalabilidade e eficiência. Além disso, os ambientes arquiteturais estabelecem diferentes formas e abordagens de paralelismo, desde o controle de acesso a dados para o nível de memória compartilhada até a comunicação entre processos em memória distribuída. Padrões paralelos e padrões de projeto auxiliam o programador na análise de requisitos e nos cuidados em relação a programabilidade dos algoritmos paralelos. Padrões de projeto direcionam o desenvolvimento de programas para uma das melhores soluções paralelas, baseados em uma metodologia. Enquanto isso, padrões paralelos, especificam e definem a estrutura algorítmica, tratando as questões de acesso aos dados e os detalhes do ambiente arquitetural a ser paralelizado, provendo maior eficiência na utilização dos recursos disponíveis. Enquanto interfaces de programação implementam alguns padrões paralelos, 7

10 alguns padrões são usados para fazer a modelagem do programa. Com as interfaces de programação disponíveis, é possível abstrair parte dos detalhes de programação paralela para a exploração de paralelismo em ambientes computacionais. Entretanto, a programação neste contexto ainda não é um atrativo ou simplesmente motiva os programadores a implementar softwares para estas arquiteturas, pois exigem que o programador domine os conceitos da programação paralela e dos detalhes de implementação. Um dos problemas está na dificuldade de se programar em paralelo. Pensar em paralelo exige maior esforço do programador para tratar os problemas de coerência e sincronização, para os quais, a depuração é um processo bastante custoso. Sendo esta uma das fases que exige mais do programador, pois este procedimento é manual e poucas ferramentas ou interfaces fornecem mecanismos de depuração de código inteligentes para a detecção rápida das inconsistências do programa. Outro problema está na exploração do paralelismo disponível. Os padrões paralelos e padrões de projetos utilizados na programação até o momento, não proporcionam mecanimos bons o suficiente, a ponto de explorar o máximo de paralelismo. Isso porquê, em programas paralelos podem ocorrer dependências causais, estas podem gerar uma sobrecarga de acesso aos dados ou na sincronização de processos ou threads. 1.1 Motivação e Objetivos O recente mercado de estações de trabalho e servidores vem aumentando gradativamente a quantidade de núcleos e processadores, elevando ainda mais o paralelismo e a complexidade em lidar com estas arquiteturas de hardware. É necessário a disponibilidade de mecanismos que estejam preparados para fornecer escalabilidade e explorar o máximo de paralelismo possível para estas arquiteturas, conhecidas como multi-core. Como um dos problema enfrentados na atualidade por programadores referese à complexidade em desenvolver programas paralelos, uma abordagem estruturada tende a ser útil para reduzir a complexidade no desenvolvimento de programas, particularmente relevante para arquiteturas multi-core, onde existe uma grande potencial de paralelismo. Entretanto, para tornar os programas paralelos mais confiáveis e eficientes, podem ser usados padrões de algoritmos determinísticos. Sendo que estes, enquanto melhoram a produtividade através de padrões espertos, específicos e da combinação deles, também podem direcionar os desenvolvedores inexperientes e profissionais a desenvolverem softwares com maior eficiência e escalabilidade. Além disso, é possível melhorar a exploração de paralelismo nos algoritmos, pois alguns padrões determinísticos, se implementados corretamente, podem eli- 8

11 minar os gargalos e a sobrecarga de programas paralelos. Isso porquê, padrões determinísticos oferecem determinismo e consistência através de uma única ordem de execução. Tendo conhecimento do funcionamento dos padrões específicos, uma das possibilidades é fazer a combinação deles, a fim de resultar em soluções eficientes para direcioná-los em aplicações específicas, isso pode ser feito usando padrões estruturados determinísticos ou não determinísticos. Padrões paralelos contribuem na padronização do desenvolvimento de algoritmos paralelos. Estes são uma forma de abstrair parte da complexidade, podendo servir de suporte para a criação de frameworks com alto nível de abstração, simplificando na programabilidade de algoritmos paralelos como um todo. Sendo esta uma das grandes necessidades dos programadores nos dias de hoje. Com base na motivação e nos problemas elencados até então, o trabalho tem por objetivo realizar um estudo sobre o projeto de algoritmos paralelos, padrões paralelos e um breve levantamento de alguns frameworks para ambientes de programação multi-core. 1.2 Organização do Trabalho Este trabalho está organizado em sete capítulos: O Capítulo 1, faz uma introdução dos atuais problemas encontrados para arquiteturas de processadores multi-core e as motivações para a realização de pesquisas nesta área. Em seguida é dado início ao contexto de padrões de programação paralela no Capítulo 2, descrevendo as fases ou espaços de projeto de algoritmos paralelos, bem como os padrões utilizados em um contexto geral de algoritmos paralelos. No Capítulo 3 são estudados os padrões de programação paralela estrutura e determinística, onde são abordados essencialmente os padrão que resolvem os problemas mais frequentes em ambientes multi-core. Para fins de conheciementos da disponibilidade de frameworks, o capítulo 4 traz alguns dos principais frameworks utilizados na programação multi-core. Ao final, o capítulo 5 relata as conclusões sobre o presente o trabalho. 9

12 2 Padrões de Programação Paralela Um padrão de programação é uma solução genérica para problemas encontrados frequentemente na computação [4]. Padrões de programação apareceram com o surgimento das primeiras linguagens de programação no fim da década de 60/início da década de 70 [5]. Os padrões sequenciais são tradicionalmente divididos em dois grupos: padrões de controle de fluxo e padrões de gerenciamento de dados. Dentre os padrões de controle de fluxo destacam-se: sequência, seleção, iteração e recursão. Os padrões de gerenciamento de dados mais usados são: leitura de acessos aleatório, alocação de pilha e alocação dinâmica de memória. Alto desempenho e paralelismo necessitam que programadores entendam da arquitetura de software para que possam identificar tarefas independentes e dados em aplicações. Nesse cenário, resolver ou organizar pedaços de código em uma implementação paralela é uma tarefa difícil. No entanto, a exploração de estratégias de paralelismo tem motivado a obtenção de desempenho em programas computacionalmente intensivos. A utilização de padrões de programação paralela surge como uma alternativa viável para auxiliar no desenvolvimento de programas paralelos. Os padrões de programação são descritos ou implementados a partir de um padrão de linguagem. A linguagem ajuda explorar várias abordagens para a computação levando à solução de problemas encontrados enquanto é desenvolvido um software paralelo [6]. Os principais padrões de linguagem são compostos de: Padrões Estruturados: descrevem a estrutura global de uma computação, onde incluem-se padrões como, pipe, filtros, agente e repositórios, map, reduction, grafos de tarefas estáticas, entre outros. Padrões Computacionais: descrevem várias classes importantes da computação que surgem da computação intensiva, como álgebra linear e barreira. 10

13 Padrões de Estratégia Algoritmica: descrevem a maneira de decompor a computação dentro de unidades paralelas, nos quais são incluídos paralelismo de dados, especulação e paralelismo em pipeline. Padrões de Estratégia de Implementação: descrevem a maneira de implementar a computação paralela e suas correspondentes estruturas de dados, como paralelismo de laço, SPMD (Single Process, Multiple Data), mestreescravo e compartilhamento de fila. Padrões de Execução Concorrente: descreve a partir do mais baixo nível do padrão de linguagem, maneira na qual existe a integração com hardware paralelo. Por exemplo, SIMD (Single Instruction, Multiple Data), pool de threads e troca de mensagens. Com o uso de padrões de linguagem, torna-se mais fácil o entendimento de aplicações que são escritas de forma paralela, e também na construção de ferramentas que auxiliam na exploração do paralelismo. Para tanto, frameworks podem ser criados a partir destes padrões, com a finalidade de facilitar aos programadores a implementação de software paralelo [1]. Este capítulo descreve as quatros fases de desenvolvimento de programas paralelos. A primeira fase, referece-se ao espaço de projeto Encontrando Concorrência, onde o programador trabalha em um problema para identificar a concorrência disponível, usando esta para o projeto de algoritmo paralelo. Na segunda fase, trata do espaço de projeto Estrutura de Algoritmo, no qual o programador trabalho em um alto nível para organizar um algoritmo paralelo. Em seguida, na terceira fase, o espaço de projeto Estruturas de Apoio, trata de como os programas paralelos podem ser organizados e as técnicas usadas para o gerenciamento de dados compartilhados. A quarta e última fase de desenvolvimento, o espaço de projeto Mecanismos de Implementação, observa as construções de um software específico para implementar um programa paralelo. O estudo sobre estas fases de projeto baseia-se principalmente nos autores de [6], [7], [8], [9], [10], [1], [11], [4], [12], [13], [14] e [15], para descrever os conceitos no decorrer deste capítulo. 2.1 Encontrando Concorrência O desenvolvimento de algoritmos paralelos não é uma tarefa simples e fácil. Antes de modelar um algoritmo paralelo, deve-se fazer o levantamento da aplicação, identificando o problema a ser resolvido. Se paralelizar passa a ser vantajoso, pode-se estudar quais padrões paralelos podem ser implementados na aplicação. 11

14 Figura 2.1: Encontrando Concorrência. Adaptado de [1] Assim, o primeiro passo do projeto de algoritmo paralelo começa a partir dos padrões de concorrência. A Figura 2.1 ilustra três grupos de padrões correspondentes a este espaço de projeto. O grupo de padrões de decomposição tem por objetivo quebrar um problema em pedaços de forma a executar concorrentemente. Os padrões de análise de dependência operam entre eles e possivelmente podem revisar os padrões de decomposição. Já o grupo de padrões de avaliação de projeto direcionam o projeto de algoritmo para uma avaliação (testando se o melhor padrão foi aplicado), antes de encaminhar para o próximo espaço de projeto Padrão de Decomposição de Tarefas No padrão de decomposição de tarefas, o problema é visto como um fluxo de instruções que podem ser quebrados em tarefas que são executadas concorrentemente [10]. O programador deverá identificar quais são os pontos (que geram tarefas) a serem paralelizados no algoritmo, levando em conta os seguintes aspectos: Flexibilidade: permitir que o número e o tamanho de tarefas possa ser parametrizado para diferentes números de processadores. Eficiência: garantir que não ocorra overhead pelo gerenciamento de dependência das tarefas, e que o número de tarefas não seje maior que o número de unidades de processamento. Simplicidade: tornar possível a depuração e a manutenção o mais simples possível. O padrão de decomposição de tarefas pode ser usado em aplicações como: imagem médica; multiplicação de matrizes e dinâmica molecular. 12

15 2.1.2 Padrão de Decomposição de Dados A decomposição de dados foca nos dados exigidos pelas tarefas e como pode ser decomposto em pedaços separados. Isso só é eficiente se os pedaços de dados podem operar independentemente. Algoritmos de decomposição de dados fazem o uso eficiente da memória e (em ambientes com memória distribuída) usam menor largura de banda. Mas, ocorre maior sobrecarga de comunicação durante a execução de partes concorrentes, sendo também mais complexa a sua decomposição. Máquinas NUMA (No Uniform Memory Access) se mostram vantajosas na decomposição de dados [8]. Ao começar a decomposição de dados, deve-se identificar as estruturas de dados definidas pelo problema e verificar o que pode ser quebrado em pedaços, que podem executar concorrentemente. Por exemplo, computação baseada em vetores (quebrar em segmentos o vetor) e estrutura de dados recursiva (decompor em sub-árvores) [1]. Para isso, é necessário levar em conta os seguintes aspectos: Flexibilidade: o tamanho e o número de pedaços de dados devem ser flexíveis, de maneira a suportar um sistema paralelo amplo, onde a partir da parametrização define-se a granularidade, sendo que esta varia de acordo com o hardware. Eficiência: a decomposição torna-se eficiente quando a quantidade de pedaços não causa a sobrecarga no gerenciamento de dependência. Para tanto, um algoritmo paralelo deve balancear a carga entre as threads ou processos. Simplicidade: decompor dados é complexo, o que torna a depuração difícil. Esta decomposição geralmente requer um mapeamento global dentro de uma tarefa local. Faz-se este mapeamento abstrato a fim de isolar e testar. A decomposição de dados também pode ser realizada em aplicações como: imagem médica, multiplicação de matrizes e dinâmica molecular. Sendo que a granularidade é mais fina se comparado com a decomposição de tarefas Padrão de Grupo de Tarefas Este padrão corresponde aos padrões de decomposição de dados e tarefas. No entanto, descreve a primeira etapa na análise de dependências. Um aplicação pode ser dividida em problemas, onde cada problema se utiliza de tarefas para resolvê-lo. Para isso, é possível criar grupos de tarefas que são agrupados correspondentes a seus devidos problemas. Mostra-se benéfico na análise de dependência das tarefas, pois o controle passa a ser realizado nos grupos (quando um grupo termina um outro grupo pode começar a ler). Caso um grupo de 13

16 tarefas trabalhe junto com uma estrutura de dados compartilhada, a sincronização é necessária em todo grupo. Se existem restrições entre as tarefas, podem ocorrer casos como: dependência temporal; coleção de tarefas executam ao mesmo tempo e tarefas podem ser independentes umas das outras dentro do grupo [12]. Para identificar as restrições e grupos de tarefas, deve-se olhar primeiramente como o problema original foi decomposto, em seguida verificar se outro grupo compartilha a mesma restrição, e ao final, identifica-se as restrições entre os grupos de tarefas [1] Padrão de Ordenção de Tarefas A ordenação de tarefas consiste na segunda etapa de análise de dependências, objetivando-se a identificar como os grupos de tarefas podem ser ordenados para atender as retrições entre as tarefas. Para tanto, a ordenação deve ser restrita o suficiente para satisfazer todos os requisitos que resultam em um projeto correto. Também, a ordenação não deve ser mais restrita que ela precisa ser. De forma a contribuir na ordenação das restrições, é importante observar a necessidade do dado por um grupo de tarefas, antes de ele poder executar. Também podem ser considerados serviços externos que promovem a ordenação de restrições e notar quando uma ordenação não existe [6] Padrão de Compartilhamento de Dados Um algoritmo paralelo consiste basicamente de: uma coleção de tarefas que executam concorrentemente, uma decomposição de dados correspondente a uma solução de tarefas concorrentes e também sobre a dependência entre as tarefas, que devem ser gerenciadas para permitir uma execução segura [1]. O objetivo deste padrão é o compartilhamento de dados entre os grupos de tarefas e determinar o acesso de dados compartilhados de maneira correta e eficiente. Para garantir estes fatores, o algoritmo deve prever questões como: condição de corrida, geração de sincronização excessiva e overhead de comunicação (em sistemas distribuídos). Em um primeiro instante, os dados são compartilhados entre as tarefas (padrão de decomposição de dados), no qual, os dados são decompostos em blocos e o compartilhamento de dados é realizado entre estes blocos. No padrão de decomposição de tarefas se torna mais complicado, pois é necessário tratar os dados passados dentro ou fora da tarefa e tratar quando um dado é atualizado no corpo da tarefa. O programador fica responsável por conhecer as formas de uso do compartilhamento de dados, para as quais inclui-se: somente leitura, eficazmente local 14

17 (operações com matrizes), leitura e escrita, acumulação e múltipla leitura/somente escrita Padrão de Avaliação de Projeto Este padrão consiste na última etapa para encontrar concorrência, visando preparar o programa para o próximo espaço de projeto [6]. A decomposição do problema original e análise pode ser feita com: uma decomposição de tarefas que identifica tarefas que podem executar concorrentemente; uma decomposição de dados que identifica o local dos dados para cada tarefa; uma maneira de agrupamento de tarefas e ordenação de grupos para satisfazer restrições temporais, e análise de dependências entre tarefas. Entretanto, a partir destes termos o padrão se objetiva a encontrar qual é a melhor decomposição do problema para produzir um projeto de ótima qualidade, baseando-se na avaliação de três aspectos: Adequação para a plataforma alvo: para a escolha da plataforma alvo, devem ser levados em conta a quantidade de processadores disponíveis, como são compartilhadas as estruturas de dados entre os elementos de processamento, identificar como a arquitetura alvo implica sobre o número de threads ou processos e como as estruturas de dados são compartilhadas entre elas, e ao final, analizar o tempo gasto trabalhando em uma tarefa, sendo que o tempo deve ser ótimo quando for lidar com dependências. Qualidade de projeto: a qualidade de projeto requer que sejam mantidos em mente as características da plataforma alvo, avaliando as dimensões de flexibilidade, eficiência e simplicidade. Preparação para a próxima fase de projeto: o projetista quando se deparar com avaliação deste aspecto, deve considerar a regularidade das tarefas e suas dependências de dados, interação entre as tarefas (síncrono ou assíncrono) e se as tarefas são agrupadas da melhor maneira. 2.2 Estrutura de Algoritmo Uma estrutura de algoritmo requer eficiência, simplicidade, portabilidade e escalabilidade [1]. Porém, estes termos causam conflitos, como por exemplo, eficiência com portabilidade. Alguns programas necessitam ser escritos com características específicas, o que não torna possível a portabilidade. Outro caso de conflito é eficiência com 15

18 simplicidade, pois geralmente se usa paralelismo de tarefas, para o qual, em alguns casos é necessário o uso de algoritmos de escalonamento complexos, que dificultam o entendimento. No entanto, um bom projeto de algoritmo deve estabelecer um balanço entre abstração e portabilidade para uma determinada arquitetura alvo. Figura 2.2: Estruturas de Algoritmos. Adaptado de [1]. A Figura 2.2 demonstra a organização do espaço de projeto, sendo este organizado em três grupos de padrões paralelos. O princípio de organização implica na concorrência, na qual são descritos termos de tarefas e grupos de tarefas, dados e ordenação entre grupos de tarefas. A fim de encontrar um algoritmo estruturado que representa como este mapeamento de concorrência é realizado dentro das threads ou processos. O projeto de algoritmo paralelo faz o uso de múltiplas estruturas de algoritmos, os quais estão dividido nos seguintes grupos: Organização por Tarefa: possui duas alternativas quando a execução de tarefas é a melhor organização. Uma é o padrão de paralelismo de tarefas, usado quando é possível juntar em um conjunto linear em qualquer número de dimensões. A segunda alternativa é o padrão de divisão e conquista, utilizado em casos onde as tarefas são enumeradas por um procedimento recursivo. Organização por Decomposição de Dados: a escolha deste grupo parte do princípio que o mesmo deve ter entendimento da concorrência, visando o padrão de decomposição geométrica (processamento linear e bem aplicado para paralelismo em computação baseada em grades) e o padrão de recursão de dados (recursão de estruturas de dados, i.e árvore binária). Organização por Fluxo de Dados: consiste na forma em como o fluxo de dados é imposto na ordenação em grupo de tarefas. Para tanto, pode ser escolhido o padrão pipeline, quando o fluxo de dados entre os grupos de tarefas é regular, o sentido é em uma direção e não muda no decorrer do 16

19 algoritmo. Para o padrão de coordenação baseado em eventos o fluxo de dados é irregular, dinâmico e imprevisível. Nas próximas subseções será detalhado cada um dos padrões contidos nos grupos de organização por tarefas, organização por decomposição de dados e organização por fluxo de dados, conforme estão ilustrados na Figura Padrão de Paralelismo de Tarefas Quando se trata de paralelismo de tarefas, ao desenvolver uma aplicação deve-se observar e analisar como as tarefas são definidas, as dependências entre elas e o escalonamento delas. As tarefas, na decomposição de um problema, deveriam existir pelo menos tantas quanto unidades de processamento, de preferência mais, para obter maior flexibilidade no escalonamento [13]. Também é importante que a computação associada com as tarefas seja larga o suficiente para equilibrar a sobrecarga com o gerenciamento e manipulação de dependências. Um dos maiores impactos no padrão de paralelismo de tarefas é a dependência, isso envolve questões como o compartilhamento de dados e grupos de tarefas. Na maioria dos casos os algoritmos se tornam mais complexos e perdem eficiência [7]. Para isso, ao desenvolver um programa, é importante que o programador esteja preocupado com estas questões, procurando remover dependências e separando-as se possível. O escalonamento parte da ideia de balancear a carga entre os processadores, mantendo um equilíbrio de tarefas entre as threads ou processo. Esta atribuição de tarefas aos processadores, pode ser realizado estaticamente (determinando no início da computação como e quanto é usado a thread ou processo, e esta se mantem até o fim) ou dinamicamente (variando a distribuição entre as threads ou processos, conforme procede a computação). O paralelismo de tarefas pode ser baseado em laços, isso implica que as tarefas são baseadas nas iterações dos mesmos. Neste caso, a melhor solução é realizar a operação deste em paralelo. Deve-se tomar cuidado com uma grande quantidade de tarefas, pois pode gerar muita dependências entre elas. A questão de replicação de dados também é um fator crítico no paralelismo de tarefas, pois necessita de muito controle (ocorrendo um réplica na variável local, uma para resolver as tarefas independentes e uma para recombinar os resultados em um único resultado) [13]. 17

20 2.2.2 Padrão de Divisão e Conquista O padrão de D&C (Divide and Conquer) consite em dividir o problema em subproblemas menores, resolvendo-os, independentemente e fundindo todas as subsoluções em um problema [12]. Isso é resolvido de forma recursiva, tendo como objetivo explorar a eficiência na resolução do problema. Ao contrário do padrão de paralelismo de tarefas, D&C quase não explora concorrência entre as tarefas e os subproblemas também possuem seções de partir e fundir. Em ambientes de memória distribuída, os subproblemas são gerados por um processo ou thread e executados por outro. As tarefas são geradas dinamicamente e cuidados como a sobrecarga na comunicação devem ser levados em consideração. Em alguns níveis de recursão não é vantajoso criar novos processos para subdividir o problema, pois de certa forma o problema é pequeno e é resolvido mais rápido de forma sequencial. Como o problema é dividido em subproblemas e depois é feita uma fusão destes, existe o custo da comunicação para subdividir e depois juntar todos estes subproblemas Padrão de Decomposição Geométrica A decomposição geométrica se objetiva em dividir um região geométrica em subregiões geométricas [14]. Para vetores, esta decomposição pode ser de uma ou mais dimensões, e os sub-vetores resultantes são chamados de blocos e denominados de pedaços as sub-estruturas e as sub-regiões. Havendo a decomposição de dados em pedaços, implica que sejam atualizadas as operações nas tarefas, onde cada tarefa representa a atualização de um pedaço e estas executam concorrentemente. Em certos casos, alguns pontos necessitam da atualização de outros pedaços, para tanto, a informação deve ser compartilhada entre os pedaços para completar a atualização. Este padrão pode trabalhar em conjunto com os padrões de decomposição de tarefas (quando a atualização para cada pedaço pode ser feita sem dados a partir dos pedaços) ou D&C (quando a estrutura de dados pode ser distribuída e recursiva) Padrão de Recursão de Dados Para os problemas de lista, árvores ou grafos, o padrão de recursão de dados pode atuar, visando explorar paralelismo para obter maior desempenho. O padrão de D&C também trabalha com recursão de dados, mas sem grande potencial de concorrência. No entanto, o objetivo é reformular estas operações, com a finalidade 18

21 de que o programa possa operar concorrentemente em todos os elementos da estrutura de dados e também operar recursivamente [1]. Um dos principais desafios deste padrão é aplicar a mudança do algoritmo orginal para explorar a concorrência, isso implica que em todos os níveis da estrutura exista concorrência entre os processos. Para isso, cada nó comunica-se com o raiz ou com o pai dele. O padrão de recursão de dados é semelhante ao D&C, porém, acrescenta a concorrência na estrutura de dados Padrão de Pipeline O padrão pipeline consiste de uma computação baseada em estágios, podendo ser visto como uma sequência de dados através de uma sequência de estágios [7]. O pipeline é introduzido em CPUs modernas para explorar o paralelismo, executando várias instruções concorrentemente. Exemplo disso é o comando shell "cat arquivo grep brasil wc", sendo que este é executado em três estágios do pipeline, com um processo para cada comando (cat, grep e wc) [1]. Na definição de estágios de um pipeline, cada processo deve conhecer a quantidade de estágios do pipeline para que cada estágio saiba a partir da contagem do número de elementos, o momento de parar e quando o dado foi processado. No entanto, alguns fatores implicam no desempenho deste padrão: A concorrência é limitada pelo número de estágios, isso pode implicar em um overhead de comunicação, pois é necessário organizar a computação a um determinado número de estágios, uma boa modelagem poderá evitar este tipo de problema. Este padrão possui um melhor desempenho se todos os estágios do pipeline possuem capacidade computacional igual, pois se alguns estágios variam sua capacidade, os que possuem menos recursos criam um gargalo para o rendimento do pipeline. O padrão também opera melhor se o tempo requisitado para encher e esvaziar o pipeline é menor comparado ao tempo de execução global, sendo que este é influenciado pelo número de estágios (mais estágios, mais tempo de encher e esvaziar). Para estruturar a computação, pode-se usar o modelo SPMD e usar o ID (identificador) de cada processo, para escolher uma opção para cada caso correspondendo a um estágio do pipeline. Na representação do fluxo de dados entre os elementos do pipeline, para ambientes de troca de mensagem, refere-se a comunicação para que os processos possam se sincronizar. Em cada mensagem é possível enviar uma grande quantidade de dados, reduzindo assim, o número de mensagens trocadas entre os processos. 19

22 Em ambientes onde a troca de mensagem não é uma boa alternativa, os estágios do pipeline podem ser conectados explicitamente com canais buferizados, implementando por exemplo, filas compartilhadas entre os enviadores e recebedores de tarefas, usando o padrão de compartilhamento de fila Padrão de Coordenação Baseada em Eventos Ao contrário do padrão de pipeline, a coordenação baseada em eventos não opera estritamente em uma estrutura linear, não possui restrições que um fluxo de dados seja apenas de uma maneira, e as iterações são irregulares e algumas vezes com intervalos imprevisíveis. Um exemplo disso é uma garagem de lava-carros. Esta por sua vez, possui duas máquinas de lavar carro e uma fila de atendimento. Cada carro poderá ficar um determinado tempo usando o recurso e se ainda a limpeza não for concluída, o carro volta para a fila de atendimento, para passar novamente pela máquina de lavar carro e assim sucessivamente, até que o carro esteja limpo. Os carros que estão na fila ganham o recurso quando a máquina não está ocupada e quando chegou a sua vez. Para fluxos de dados usa-se eventos, onde cada evento contém uma tarefa que gera o evento e uma tarefa que processa o evento. Isso porquê, um evento deve ser gerado antes que ele seja processado, os quais definem restrição de ordenação entre as tarefas, onde a computação de cada tarefa consite de processamento de eventos [1]. A estrutura básica de cada tarefa consiste no recebimento de um evento, processamento dele e possivelmente gerâ-lo. Para representar o fluxo de evento, estão associados a comunicação e a computação de sobreposição, de modo geral, a comunicação é assíncrona dos eventos em que uma tarefa pode criar (enviar) um evento, e então continuar sem esperar por um destinatário para receber um evento. Em ambientes de memória distribuída, um evento pode ser representado por uma mensagem enviada assincronamente a partir da tarefa, gerando o evento para a tarefa que irá processá-lo. Já em ambientes de memória compartilhada, uma fila pode ser usada para simular a troca de mensagens, onde uma fila pode ser acessada por mais de um tarefa e deve ser implementada de forma a permitir o acesso seguro e concorrente. Na coordenação baseada em eventos, deve se ter cuidado com problemas de deadlock, escalonamento e alocação de processo (um processo por elemento de processamento) e uma eficiente comunicação de eventos. O cuidado com relação a comunicação deve ser maior para ambientes de troca de mensagem. 20

23 2.3 Estruturas de Apoio O espaço de projeto de estruturas de apoio descreve construções ou estruturas de software que suportam os algoritmos paralelos. O espaço de projeto está representado em dois grupos de padrões conforme ilustra a Figura 2.3, nos que representam a abordagem de estrutura dos programas e nos que representam o uso de estrutura de dados. Figura 2.3: Estruturas de Apoio. Adaptado de [1] Nada impede que se use outro padrão para implementar uma estrutura, como por exemplo, Mestre/Escravo utilizar Fork/Join ou SPMD. Isso significa que estes padrões não representam unicamente uma maneira de estruturar um programa paralelo. Para um programador MPI (Message Passing Interface), todos os programas de padrões estruturados são derivados do padrão SPMD. Entretanto, para um programador OpenMP (Open MultiProcessor) existe uma enorme diferença entre programas que utilizam identificadores de threads (padrão SPMD) para programas que expressam a concorrência em nível de laço (padrão de paralelismo de laço) [12]. Geralmente, todos os programas que utilizam padrões estruturados enfrentam alguns problemas básicos, tais como: Clareza e Abstração: refere-se a forma que o algoritmo está escrito no código fonte. Uma abstração clara é importante para escrever um código corretamente e auxiliar na depuração. Escalabilidade: diz respeito a quantidade de processos que um programa paralelo pode eficientemente utilizar. Restringindo-se a concorrência disponível no algoritmo, implica no limite de processadores que podem ser usados, e o overhead pode contribuir para baixar e limitar a escalabilidade. 21

24 Eficiência: está diretamente realacionada com desempenho do programa em relação ao programa sequencial. Sustentabilidade: refere-se na facilidade de se modificar, depurar e verificar um software e em relação a sua qualidade. Afinidade do Ambiente: é a relação do programa com o ambiente de programação e a escolha do hardware. Equivalência Sequencial: esta situação corre quando um programa produz resultados equivalentes, quando executa com vários processos tal como em um único processo Padrão SPMD (Single Program, Multiple Data) Em um programa que utiliza o padrão SPMD, todos os processos executam o mesmo programa, mas cada processo tem seu próprio conjunto de dados [7]. Os processos podem seguir caminhos diferentes dentro de um programa. Pode ser usado para descrever e estruturar os padrões do espaço de projeto da estrutura de algoritmos paralelos. O padrão SPMD é melhor aplicado quando usado em casos de integração numérica e dinâmica molecular. Este é constituído por alguns elementos básicos que compõem sua estrutura: Inicialização. Obtenção de um único identificador. Execução do mesmo programa em cada processo, usando o identificador único para diferenciar comportamento em diferentes processos. Dados distribuídos. Finalização Padrão Mestre/Escravo No padrão mestre/escravo, o processo ou thread mestre, configura uma certa quantidade de processos ou threads trabalhadoras e um saco de tarefas. Os trabalhadores executam concorrentemente cada trabalho, removendo uma tarefa do saco de tarefas e processando-a, até que todas sejam processadas [7]. No contexto do programa, o processo mestre inicia a computação, depois configura o problema e cria o saco de tarefas, para então enviar aos escravos, que por 22

25 sua vez, inicializam e computam o resultado e, se a computação estiver terminada, devolvem ao processo mestre. Enquanto os escravos trabalham, o mestre fica esperando para coletar os resultados de cada um dos escravos, e após esse processo, cabe a ele terminar o programa. Para [1] este padrão é relevante para problemas que utilizam paralelismo de tarefas quando não existe dependência entre as tarefas, e também pode ser usado com o padrão fork/join para casos onde o mapeamento de tarefas nas threads ou processos é indireto Padrão de Paralelismo de Laço Este padrão tem como propósito encontrar maneiras para programas que possuem estruturas baseadas em laço, possam processar em paralelo, ou seja, transformar um programa serial, cujo o tempo de execução é determinando por um conjunto intensivo do processamento de um laço, onde diferentes iterações, são executadas em paralelo. Segundo [1], é particularmente relevante usar o paralelismo de laço para programas OpenMP executando em computadores com memória compartilhada, e problemas que utilizam padrões de paralelismo de tarefas e decomposição geométrica. A implementação do padrão de paralelismo de laço usando OpenMP implica nas seguintes etapas: Encontrar gargalos: fica a cargo do programador identificar os laços no código para combinar e encontrar o desempenho necessário para cada subproblema. Eliminar dependência na realização do laço: consiste em eliminar operações de escrita e leitura que provocam uma sessão crítica. Paralelizar o laço: dividir as iterações entre as threads ou processos. Otimizar o escalonamento do laço: as iterações devem ser escalonadas para executarem nas threads ou processos, a fim de obter o balanceamento de carga. Mesclar laços: situação onde o problema de uma sequência de laços que possui limites consistentes de laço, onde estes podem frequentemente ser mesclados em um único laço com iterações mais complexas. Reunir laços alinhados: normalmente é possível reunir laços alinhados em um único laço, com uma grande combinação de iterações. 23

26 2.3.4 Padrão Fork/Join Padrão Fork/Join é baseado no conceito de processo pai e processos filhos. Um processo pai pode criar vários processos filho dinamicamente, quando um processo terminar, ele executa join e acaba, e os demais processos filhos continuam sua execução [15]. Este padrão é usado em exemplos que usam recursividade, como o padrão D&C. Com o produto da execução do programa o problema é divido em subproblemas e novas tarefas são recursivamente criadas para executar concorrentemente os subproblemas, cada uma destas tarefas pode se tornar um subdivisor. Quando todas as tarefas forem criadas para fazer uma divisão, elas terminam e se juntam com a tarefa pai, e a tarefa pai continua a computação. Parafaseando [1], o padrão fork/join é relevante para programas Java executando em computadores com memória compartilhada e para problemas que usam padrões como D&C e Recursão de Dados. O OpenMP pode ser usado efetivamente com padrões quando o ambiente OpenMP suporta alinhamento de regiões paralelas. Os problemas que usam o padrão fork/join, possuem o mapeamento de tarefas em threads ou processos de diferentes maneiras: Mapeamento direto de tarefa: nesse mapeamento existe uma tarefa por processo ou thread. Para cada nova subtarefa criada, novas threads ou processos são criados para manipulá-las. Na maioria dos casos, existe um ponto de sincronização onde a tarefa principal espera pelo término das subtarefas, conhecido como join. Mapeamento indireto de tarefa: neste mapeamento existe uma certa quantidade de threads ou processos trabalhando em um conjunto de tarefas. A ideia é a criação estática de threads ou processos antes de começar as operações de fork/join. O mapeamento de tarefas em threads ou processos então ocorre dinamicamente usando uma fila de tarefas. Neste tipo de mapeamento, não é possível que threads ou processos criam e destruam a si mesmos, mas podem simplesmente mapear para tarefas criadas dinamicamente conforme necessitarem. Sua implementação é complicada e geralmente resultam em programas eficientes com bom balanceamento de carga. Algoritmos de ordenação de vetores como mergesort, podem ser implementados usando mapeamento direto ou indireto de tarefas Padrão de Compartilhamento de Dados A manipulação de dados é normalmente compartilhada por mais de um processo, onde o compartilhamento de dados implica em um conjunto de tarefas operando 24

27 concorrentemente. Operar com dados compartilhados pode ser considerado como um dos aspectos que propicia o programador a cometer erros no projeto de algoritmos paralelos. Entretanto, é importante uma boa abordagem que enfatiza a simplicidade e uma abstração, e só assim partir para abordagens mais complexas se necessário, para obter um desempenho aceitável. A primeira etapa no projeto do algoritmo é identificar se este padrão é realmente necessário. Se é importante o uso deste padrão, pode-se começar a definir uma abstração e os tipos de dados, como por exemplo, no padrão de compartilhamento de fila, inicialmente apenas se inclui operações como colocar na fila um elemento e tirá-lo. Somente após concluir estas operações, inclui-se novas operações de manipulação na fila compartilhada [12]. É necessário que o algoritmo paralelo implemente um protocolo de controle de concorrência apropriado com: Um em um tempo de execução: em ambiente de computação com memória compartilhada, as operação são tratadas como parte de uma única sessão crítica, e usa o protocolo de exclusão mútua, para garantir que apenas uma thread ou processo executa a sessão crítica. Conjunto de operações sem interferência: esta abordagem é usada para melhorar o desempenho começando pela análise de interferência entre as operações, tratanto questões onde uma operação pode enferir com ela mesma, ou mais que uma tarefa executa a mesma operação (por exemplo, mais que uma tarefa tira um elemento da fila ao mesmo tempo). Leitura/Escrita: é usado para casos onde é possível particionar operações em conjuntos disjuntos, levando em consideração o tipo de interferência. Neste caso, algumas operações podem alterar dados e outras somente ler dados, sendo assim, é possível atribuir as tarefas a conjuntos, em que somente realizam leitura e outras para realizar a alteração de dados. Redução do tamanho da sessão crítica. É uma outra maneira de melhorar o desempenho analisando a implementação de operações com mais detalhes. Identificando se o tamanho da seção crítica pode ser reduzido em pequenas partes. Este tipo de ação pode facilmente provocar erros de programação, sugere-se que seja feito, apenas se necessáro para melhorar o desempenho e simplificar a abordagem. Alinhamento de locks. Esta técnica faz o uso híbrido das abordagens de redução do tamanho da seção crítica com operações sem interferência. Neste contexto, geralmente são criadas duas funções de bloqueio ("locka"e "lockb", onde a variável A requer lockb e a variável B requer locka). 25

28 2.3.6 Padrão de Compartilhamento de Fila O padrão de compartilhamento de fila tem por objetivo tratar o problema da execução concorrente de threads e processos em uma fila compartilhada. A implementação de algoritmos paralelos requer uma fila que é compartilhada entre processos ou threads. Uma das situações mais comuns é a necessidade de um fila de tarefas implementada no padrão Mestre/Escravo. Para não haver erros na programação é importante prover uma abstração bem clara e tornar a verificação da fila compartilhada simples, para identificar se esta está corretamente implementada. Em alguns casos podem ser crescentes as chances de processos e threads permanecerem bloqueados esperando acesso à fila e limitar a concorrência disponível. É importante destacar que, mantendo uma única fila para sistemas com hierarquia de mémoria mais complicada (por exemplo, máquinas NUMA e clusters), pode causar overhead na comunicação, mas para resolver este problema, pode-se usar filas múltiplas ou ditribuídas, eliminando os gargalos. Na implementação do projeto de uma fila compartilhada, pode-se seguir os mesmos requisitos de projeto de padrão de compartilhamento de dados [1]. Inicialmente deve-se prover a abstração do tipo de dados para definir os valores que esta fila pode pegar e o conjunto de operações. Em seguida, deve-se considerar o protocolo de controle de concorrência, começando da maneira mais simples, um em um tempo de execução, para então aplicar os refinamentos direcionando esta metodologia para este padrão Padrão de Array Distribuído O padrão de array distribuído é normalmente usado na computação científica, para dividir um determinado array de maneira a processsá-lo em paralelo entre processos e threads, no qual, são calculadas equações diferenciais e isso requer o uso de arrays muito grandes [15]. Este padrão é importante quando o algoritmo usa o padrão de decomposição geométrica e para estrutura do algoritmo o padrão SPMD. Na plataforma NUMA, onde cada elemento de processamento tem acesso a todas as memórias locais, o tempo de acesso varia. Não é necessário especificar a distibuição do array para cada plataforma, mas mesmo assim é importante gerenciar a hierarquia de memória. Devido a isso, em máquinas NUMA, programas MPI podem algumas vezes serem melhores do que algoritmos similares que implementam multithread para manter páginas de memória próximos aos processadores que irão trabalhar com este array. Questões como balanceamento de carga, gerenciamento de memória (pode trazer bom desempenho quando feio o uso correto da hierarquia de memória) e 26

29 abstração (clareza em como os arrays estão divididos entre os processo ou threads e mapeados) podem resultar em uma implementação com bons resultados, aproveitando bem os recursos disponíveis. A abordagem para este padrão é particionar o array em blocos e mapeá-los em processos ou threads. Cada processo ou thread tem a mesma quantidade de trabalho e todos as threads ou processos deixam compartilhado um único endereço, cada bloco do processo ou thread armazena em um array local e para acessar os elementos do array distribuído é realizado usando índices no array local. As Tabelas 2.1 e 2.2 são classificadas na escala de zero a quatro estrelas ( ). Estas tabelas têm por objetivo auxiliar o programador na escolha da combinação de padrões e na escolha do padrão com relação o ambiente de programação para o projeto de programas paralelos. Tabela 2.1: Relacionamento entre os padrões de estruturas de apoio e ambientes de programação. Extraído de [1] OpenMP MPI Java SPMD Paralelismo de Laço Mestre/Escravo Fork/Join Tabela 2.2: Relacionamento entre os padrões de estruturas de apoio e padrões de estrutura algoritmos. Extraído de [1] Paralelismo de Tarefas Divisão e Conquista Decomposição Geométrica Recursão de Dados Pipeline Cordenação Baseada em Evento Escolhendo Padrões para o Projeto de Algoritmos Paralelos SPMD Paralelismo de Laço Mestre/Escravo Fork/Join Analisando as Tabelas 2.1 e 2.2, os padrões SPMD e Mestre/Escravo são os mais flexíveis e podem ser usado em todas as combinações, mas não significa que estes são os melhores padrões para todos os casos, cada padrão é combinado com determinado padrão e o número de estrelas ( ) determina o quão eficiente e boa é a combinação. 27

30 2.4 Mecanismos de Implementação O mecanismo de implementação é a última etapa do espaço de projeto de algoritmos paralelos, sendo este o mais alto nível de construção para organizar programas paralelos, este está dividido em três grupos conforme ilustra a Figura 2.4: gerenciamento de threads e processos, sincronização e comunicação. Figura 2.4: Mecanismos de Implementação. Adaptado de [1] As próximas seções relatam os três mecanismos de implementação, que não são padrões, mas fazem parte do projeto de algoritmos paralelos, referindo-se ao gerenciamento de threads e processos, sicronização e comunicação Gerenciamento de Threads e Processos O processo é um objeto que carrega um contexto em algum lugar no sistema, isso inclui memória, registradores, buffers. Em um sistema, diferentes processos pertencem a diferentes usuários. Já uma thread é um processo leve, uma coleção de threads está contido em um processo. Recursos como memória são compartilhados entre as threads, na qual a comunicação entre elas, pertence ao mesmo processo. Threads e processos podem ser criados e destruídos. Threads são mais simples e não exigem muitos ciclos de máquina para serem criadas, por outro lado, os processos são mais custosos, pois quando um processo é criado, é dele exigido que se carregue todas as informações necessárias para definir um lugar no sistema no qual irá atuar. API s como OpenMP, Pthread, Java e MPI possuem funções de criação de threads e processos, abstraindo grande parte da complexidade em lidar com esta abordagem de programação [9] Sincronização No gerenciamento de threads e processos, a sincronização ocorre quando se deseja manter uma ordem na execução dos eventos [11]. As API s OpenMP, Pthread, Java e MPI implementam isso em suas funções, sendo que este é realizado tratando os seguintes fatores: 28

31 Sincronização e cercas de Memória: no ambiente computacional de memória compartilhada, threads e processos podem executar uma sequência de instruções que são lidas e escritas na memória compartilhada atomicamente. Também pode ser visto como uma sequência de eventos atômicos, os quais intercalam a partir de diferentes threads ou processos. As cercas de memória são usadas na sincronização para garantir que processos ou threads tenham uma visão consistente da memória. No contexto de threads, um programa cheio de condições de corrida pode não ser vantajoso. Barreiras: são o mais alto nível para tratar a sincronização de threads e processos. As barreiras são usadas para garantir que um conjunto de threads ou processos não proceda antes que todos cheguem a um determinado ponto. Exclusão Mútua: o objetivo é garantir que threads ou processos não interferem entre si, pois em situações que se tem recursos compartilhados entre eles, dois ou mais processos ou threads podem tentar atualizar um dado compartilhado, podendo gerar conflito. O acesso a seção crítica é controlado usando exclusão mútua, onde uma thread ou processo progride, enquando os outros ficam esperando até que a seção crítica seja desbloqueada Comunicação Para que a troca de informações ocorra entre as threads e processos, é necessário a comunicação, esta pode ser realizada usando mensagens. Uma mensagem pode conter dados sobre a mensagem e outras informações. A troca de mensagens pode ser feita de duas formas: de uma origem específica para um destino específico e múltipla troca de mensagem entre processos ou threads em uma única comunicação (comunicação coletiva). Na comunicação coletiva estão envolvidas diferentes operações, como o mecanismo de broadcast, barreiras e redução [12]. Esta redução consiste em reduzir uma coleção de itens de dados para um único item de dados, para então combinar os itens de dados com uma operação binária, assiciativa ou comutativa (i.e, soma, produto, maior elemento, menor elemento, entre outras). 29

32 3 Programação Paralela com Padrões Estruturados e Determinísticos Um padrão paralelo determinístico é o resultado da combinação de distribuição de tarefas e acesso a dados [4]. Os modelos de programação normalmente suportam apenas um pequeno número de padrões ou padrões que são implementados em baixo nível (implementação em hardware). Na teoria, um sistema que suporta padrões determinísticos e permite a sua composição, tende a resultar em implementações eficientes para uma grande variedade de arquiteturas [5]. Isso porque o objetivo principal é prover altos níveis de escalabilidade e desempenho e, fornecer uma camada de abstração sobre os mecanismos de paralelismo que implementam características de hardware. São crescentes os eforços na padronização da programação paralela em um alto nível de abstração para que seja possível o desenvolvimento de software em larga escala. Padrões paralelos determinísticos são uma alternativa para cobrir esta lacuna em ambientes computacionais de memória compartilha (arquiteturas multi-core). Padrões determinísticos implicam em uma maior facilidade de manutenção, pois a criação de condições de corrida não se tornam necessárias. Além disso, possuem escopo limitado para introdução das condições de corrida e simplicam o entendimento, a depuração e os testes, por oferecer determinismo e consistência através de uma única ordem de execução. Aplicações que são orientadas a padrões paralelos podem proporcionar alta produtividade, pois os padrões derivam a partir de casos que ocorrem normalmente em aplicações, onde o subconjunto de padrões é universal para uma aplicação e pode especificar os domínios específicos [14]. Isso possibilita ao programador simplificar a aprendizagem em escrever programas eficientes, focando-se apenas no que interessa: paralelismo e localização dos dados. Modelos de programação também podem ser baseados nestes padrões paralelos, a fim de complementar na automatização de uma implementação eficiente. 30

33 Plataformas de programação, também podem usar padrões estruturados, com o propósito de deixar claro o entendimento do desenvolvedor de software ao que se refere a coerência de memória. As abordagens de paralelismo de tarefas e paralelismo de dados são usadas nos padrões determinísticos, que estão divididos em dois grupos: padrões de computação paralela e padrões de gerenciamento de dados paralelos. Neste capítulo serão detalhados os dois grupos de padrões determinísticos com seus respectivos padrões, levantando essencialmente os mais importantes e mais usados para o desenvolvimento de programas paralelos. Para tanto, o estudo se baseia nos autores de [5], [12], [16], [17], [18], [19], [14], [1], [4] e [20]. 3.1 Padrões de Computação Paralela Os padrões de computação paralela estão classificados por categorias: categoria dos padrões que operam nos valores de dados, categoria dos padrões de acesso a dados e a categoria dos padrões que não podem acessar dados. Os quais são frequentemente combinados com outros padrões e, a maioria dos padrões descritos nas próximas subseções acessam e atualizam dados de maneira específica Map Pattern O padrão Map é aplicado em iterações de laço quando não há dependência entre as iterações, para as quais, um conjunto de índices do laço são gerados e a computação é realizada independente para um único índice [5]. Esta computação não permite que a comunicação seja realizada com outra. Para tanto, no final do Map, existe uma barreira implícita e então outras operações podem depender da saída das operações de Map como um todo. Mecanismos paralelos em nível de processos ou threads incluem instruções superscalar, pipeline e operações de cálculo ou memória paralela tais como, múltiplos cores e instruções vetorizadas. Figura 3.1: Map Parallel Pattern. 31

34 A partir de uma simples estrutura de paralelismo representado pelo Map tornase possível automatizar a geração de implementações eficientes, que exploram múltiplos mecanismos ao mesmo tempo. Exemplo disso, é ilustrado na Figura 3.1, onde se implementa um processador dual-core com um vetor de 4 elementos e 4 ciclos de pipeline. Map pode dar origem a outros padrões através das iterações (i.e paralelismo de laço), mesmo se existe a dependência entre as iterações do laço. Entretanto, se existir independência entre as iterações de um laço, maior será a chance de obter a execução paralela [18]. As operações de Map são também combinadas com operações de leitura e escrita aleatória, que podem gerar padrões de entrada e saída de dados para tornar o acesso restrito a múltiplas entradas e saídas, e operações com vizinhos. Conforme a Figura 3.1, o Map replica uma funcão sobre todos os elementos de um conjunto de índices (i.e A = map(f,b)). Este pode ser abstrato ou associado com os elementos de um array. Isso substitui o uso específico de iterações em programas sequenciais, onde são processados todos os elementos de uma coleção de operações independentes Reduction Pattern Um Reduction se utilizada de um operador de associatividade, sendo este usado para todos os elementos de uma coleção reduzindo para um único elemento [19]. A Figura 3.2 ajuda a entender o funcionamento deste padrão, onde "f"são os elementos. Podendo ser usado por exemplo, para encontrar o menor valor de um array (b = reduce(f,b)). Figura 3.2: Reduction Parallel Pattern. O padrão Reduction é combinável com outros padrões para prover maior eficiência no desenvolvimento de programas paralelos, por exemplo, multiplicacão 32

35 de matrizes, no qual, o padrão pode ser visto como um Map de Reductions sobre partições formadas a partir de linhas e colunas Superscalar Sequences Pattern No padrão Superscalar Sequences uma operação é executada por vez, desta forma, para que uma operação comece sua execução a anterior deverá estar finalizada [5]. Entretanto, se uma sequência de operações pode ser reordenanda respeitando as dependências de dados, pode-se explorar formas de paralelismo de tarefas. Um exemplo prático de uso do padrão de Superscalar Sequences é chamar várias funções em sequência, como pode ser visto no código abaixo: B = f(a); G = g(e,f); C = g(b); P = p(b); E = f(c); Q = q(b); F = h(c); R = r(g,p,q); Com a sequência de invocação das funções definidas é possivel gerar o grafo ilustrado na Figura 3.3, resultante da relação da dependência dos dados conforme a ordem da chamda de funções do código acima. Figura 3.3: Superscalar Sequences Parallel Pattern. Mesmo que o padrão trabalha somente com uma operação de cada vez, neste caso algumas operações são executadas em paralelo, como os elementos p e q, f e h. Para tanto, a entrada do grafo {g,f,h,g} é executado em paralelo com o subgrafo {p,q}. Sendo assim, se o sistema permite identificar as dependências de dados é possível explorar o paralelismo. Neste padrão não são possíveis: operações de laços e algumas linguagens que possuem características como ponteiros globais para acessar qualquer coisa na 33

36 memória, gerando dependências globais. Isso deve ser evitado para não haver erros na construção do grafo e das execuções paralelas Pipeline Pattern O pipeline também se adapta nos padrões determinísticos, pois suas características de operação se enquadram no grupo de padrões computacionais. Por tanto, o padrão pipeline é um conjunto de tarefas executando simultaneamente (estágios) fazendo um relacionamento produtor-consumidor [1]. A Figura 3.4 exemplifica o funcionamento de um pipeline com três estágios. Figura 3.4: Pipeline Parallel Pattern. Ao contrário do padrão Superscalar Sequences, no pipeline não é necessário que uma operação acabe para que outra comece. O padrão pode ser uma boa alternativa para paralelizar codecs com compressão e também para processamento de vídeo Nesting Pattern Nesting é considerado um padrão com alocação de dados baseado em pilha, que possui propriedades com boa coerência de dados [5]. A implementação de Nested de forma recursiva contribui para resolver o problema de paralelismo de tarefas. Figura 3.5: Nesting Parallel Pattern. O Padrão Nesting pode ser chamado através da chamada de padrões paralelos dentro de outros padrões. Por exemplo, usando um Map ou Reduction dentro de 34

37 uma função usando outro Map ou Reduction. Isso gera uma hierarquia de grafo de tarefas, que em alguns casos torna-se necessário expandir paralelismo adicional. Este padrão é classificado como paralelismo de tarefas e de dados, pois sua estrutura como mostra a Figura 3.5, é composta da fusão com outros padrões determinísticos como, Map, Speculative Selection e Superscalar Sequence, os quais podem ser combinados com outros padrões como Reduction Scan Pattern O padrão Scan é mais apropriado para organizar, mas tende a ser usado na implementação interna de outros padrões paralelos [19]. Se um algoritmo serial é realizado em uma dimensão em um laço, se torna interessante verificar quais são as suas dependências para poder converter em um Scan. Aplicações que utilizam Scan incluem manipulação de estruturas de dados para que possam ser usados na computação de posições de objetos antes de um Gather ou Scatter. Mais precisamente, pode ser eficiente quando usado em implementações com o padrão Pack e Split [5]. Entretanto, este padrão requer um operador de associatividade, como por exemplo, uma aplicação do Scan é com "add". Nesta aplicação, pode ser usada pesquisa binária para gerar amostras aleatórias de acordo com uma probabilidade específica. A Figura 3.6 exemplifica o funcionamento do Scan com pesquisa binária. Figura 3.6: Scan Parallel Pattern. A pesquisa binária pode ser realizada usando um vetor auxiliar booleano, para comparar se a operação em uma determinada região na memória pode ser efetuada. O vetor booleano é dado como uma entrada paralela (identificando os dados a serem usados), mas em uma aplicação real, este vetor pode ser uma entrada para outro Scan ou uma operação paralela. 35

38 3.1.7 Recurrences Pattern Recurrences normalmente ocorrem no código sequencial devido ao uso de dependências na execução do laço, as quais, em alguns casos podem ser paralelizadas. A execução de fatias paralelas pode ser realizada usando paralelismo com Map ou wavefront [17]. Conforme ilustra a Figura 3.7, a implementação de Recurrences pode fazer o uso de blocos para obter desempenho. Figura 3.7: Recurrences Parallel Pattern. Este padrão pode ser combinado com outros padrões, por exemplo, se combinado com o padrão pipeline implementa a computação wavefront e também pode ser combinado com o padrão Superscalar Sequence. Exemplos usando o padrão Recurrences incluem filtros recursivos e vários algoritmos de fatoração de matrizes Partition Pattern Patitions podem ajudar no desempenho em arquiteturas com mamória NUMA, onde os algoritmos podem ser designados para enfatizar a localidade dos dados aproveitando o particionamento para deixar os dados mais próximos da memória. Neste contexto, as partições não movem dados, elas apenas são uma forma de visualizar a organização. Figura 3.8: Partition Parallel Pattern. 36

39 Conforme a Figura 3.8, uma coleção de dados é quebrada em blocos sem sobrepor as regiões. Nestes blocos são atribuídas coleções para cada um dos blocos (partições) e estas realizam operações de leitura e escrita sem causar condições de corrida (somente uma tarefa acessa uma determinada partição). O padrão Patition pode operar com partições regulares (mesmo tamanho) e irregulares (tamanhos diferentes) [16]. As caches são divididas em blocos com diferentes tamanhos e a memória virtual está organizada em páginas e, o compartilhamento de dados entre os processadores é gerenciado em blocos. O projetista de software ao usar o padrão Partition deve evitar dependência na memória física, escrevendo algoritmos de maneira genérica parametrizando o tamanho das partições Speculative Selection Pattern Speculative Selection é o padrão que faz a ecolha de resultados a partir de uma ou duas alternativas baseadas em tarefas, onde ambas as alternativas de escolha podem executar em paralelo enquanto as condições estão no processo de avaliação, conforme é exemplificado na Figura 3.9. Figura 3.9: Speculation Selection Parallel Pattern. Este padrão também pode se tornar mais trabalhoso do que um programa sequencial, porém é bom para trabalhar com condições complexas [5]. Quando as condições forem avaliadas, uma delas deve ser descartada, isso é benéfico para a redução do tempo de execução do algoritmo. Em uma implementação prática, Speculation pode ser usado se existem processadores que estão inativos. O uso deste padrão é aconselhável quando um recurso computacional está inativo, ou quando as tarefas são um fator crítico. 3.2 Padrões de Gerenciamento de Dados Paralelos Os padrões deste grupo trabalham na organização de acesso aos dados. Comumente, estes padrões são associados com os padrões do grupo de padrões de com- 37

40 putação paralela. Isso porquê, para implementações eficientes, elas são frequentemente imperativas para um padrão de acesso a dados, os quais são vistos como a fusão de padrões paralelos Gather Pattern Uma operação Gather realiza leitura aleatória de um conjunto de elementos a partir da memória [12]. O padrão Gather pode ser visto como uma leitura sequencial de memória combinado com o padrão Map. Usando-se leitura aleatória dentro de uma função usada em um Map, resulta em um Gather realizando operações em paralelo. Figura 3.10: Gather Parallel Pattern. Conforme ilustrado na Figura 3.10, o padrão Gather executa a leitura de localização aleatória (computação) em um array, e não em ponteiros globais. O padrão também usa semântica, onde antes de efetuar uma operação de escrita deve haver uma operação de leitura no kernel, de forma a evitar condições de corrida. É possível ter o Gather estático ou dinânico. Para um Gather estático podese permitir reordená-lo para obter maior desempenho. Caso ele for dinâmico, se diminui a latência para não ultrapasar os limites dos recursos disponíveis Search Pattern Padrão Search é semelhante ao padrão Gather, porém realiza a recuperação de dados a partir de um banco de dados combinando o conteúdo [5]. O paralelismo está na pesquisa de elementos chaves em paralelo ou pela pesquisa realizada em diferentes partes de um banco de dados. Um exemplo usando Search é representado na Figura 3.11, uma pesquisa é realizada, e então, é feita a redução de todos os elementos com o mesmo identificador em um array. Este padrão é adotado pelo google map-reduce para o mecanismo de busca [20]. 38

41 3.2.3 Stencil Pattern Figura 3.11: Search Parallel Pattern. Stencil é encontrado em várias aplicações, mas é mais usado em aplicações de processamento de imagem e simulação e possui soluções explícitas para particionar equações diferenciais [5]. Usado também em simulações e reconstruções sísmicas, tal como processamento de imagem. Figura 3.12: Stencil Parallel Pattern. Uma implementação eficiente de Stencil vai depender do número de otimizações. Uma implementação em baixo nível se torna bastante complexa, mas pode ser significativamente melhor que uma implementação ingênua em termos de desempenho e eficiência. Como pode ser visto na Figura 3.12, Stencil utiliza uma janela deslizante sobre um faixa, onde por padrão se tem saídas próximas a partir do Stencil e normalmente estas saídas compartilham entradas. E para este padrão, uma otimização a ser realizada é a manipulação das fronteiras entre os blocos, de forma a garantir (organizar), que não se tenha blocos de leitura inválidos. Neste caso, torna-se vantajoso o ganho de desempenho com a memória, pois é possível realizar a leitura da cache e enviar leituras novamente (obtendo leitura redundante) economizando a memória principal do sistema. Entretanto, com um 39

42 Stencil multidimencional, é possível ter paralelismo o suficiente e não há problema em sacrificar um pouco para obter maior desempenho na memória. Uma boa orientação pode depender no layout dos dados na memória, bem como a forma do stencil Scatter Pattern O padrão Scatter é a combinação de Map e escrita aleatória [5]. Neste sentido, ele opera com escrita de dados para uma localização aleatória em uma coleção, conforme pode ser visto na Figura 3.13, podendo sobreescrever qualquer dado que já foi armazenado. Figura 3.13: Scatter Parallel Pattern. Scatter quando usado dentro de Map torna-se uma operação paralela. Porém, como é possível sobreescrever um dado que já esteja armazenado podem ocorrer condições de corrida quando duas escritas estão ocorrendo no mesmo endereço (colisão). Entretanto, para se obter um Scatter determinístico torna-se necessário o uso de regras determinísticas para resolver as possíveis colisões. É possível obter algumas variantes a partir de Scatter dependendo de como as colisões são resolvidas. As variantes de Scatter serão explicadas em seguida Permutation Scatter Pattern Esta derivação de Scatter não opera concorrentemente se houver colisões. Como pode ser visto na Figura 3.14, cada elemento de uma coleção acessa ou escreve no endereço correspondente. Figura 3.14: Permutation Scatter Parallel Pattern. 40

43 O padrão Permutation Scatter pode ser implementado em termos de um scatter inseguro, mas é possível através deste produzir resultados incorretos se usado de maneira errada. Isso se implementado com escrita duplicada em um mesmo endereço. Entretando, é necessário que se use mecanismos de depuração e cuidados com a implementação (o programador pode pensar que pode usar o mesmo endereço) Atomic Scatter Pattern Este padrão resolve colisões mas não de forma determinística, onde somente um resultado é mantido em uma determinada saída quando ocorre uma colisão, de acordo com o ilustrado na Figura Figura 3.15: Atomic Scatter Parallel Pattern. O uso do padrão Atomic Scatter resultará em programas não determinísticos. Para tanto, a implementação de Atomic Scatter é boa se necessário o uso de bloqueios para que se possa preservar escritas atômicas Merge Scatter Pattern Merge Scatter utiliza operadores associativos para resolver um caso de colisão. Para isso, fica a cargo do programador gerenciar estes operadores associativos e as colisões. No entanto, esta regra pode ser usada para combinar valores dispersos com saída de dados em um array. Figura 3.16: Merge Scatter Parallel Pattern. 41

44 A Figura 3.16 demonstra a operação do padrão Merge Scatter usando associatividade na escrita. Quando ocorre uma operação são usados operadores que não são associativos como, a leitura, modificação e escrita Priority Scatter Pattern Priority Scatter atribui para todos os elementos paralelos uma prioridade. Conforme pode ser visto na Figura 3.17, deterministicamente as colisões são tratas, determinado o vencedor baseado na prioridade. Figura 3.17: Priority Scatter Parallel Pattern. Um Priority Scatter é bastente útil, pois a ordenação serial do corpo de um laço pode ser usado para gerar regras não ambíguas. Isso significa que um laço com operações Scatter pode convergir no padrão Priority Scatter. Este padrão pode ser referência para implementação de padrões em diferentes maneiras. Uma das maneiras é não tornar possível a colisão com outras threads Pack Pattern Pack é usado para eliminar espaço em um lugar da coleção que está escasso e pegar a taxa variável de saída de um Map [5]. Possui também como entrada, uma condição booleana, onde os elementos de uma coleção de entrada podem ser descartados se forem falsos e colocar em uma coleção de saída eliminando as aberturas, conforme é exemplificado na Figura As entradas que não são descartadas são empacotadas em uma única coleção em uma sequência contínua sem saídas mantendo a ordem original. Para isso, a saída de um elemento pode ser vazia, assim um sistema suportando Pack precisa permitir a representação de coleções vazias. O padrão Pack implementado sozinho não é uma boa solução de paralelismo, mas se fundido com Map pode obter bons resultados em termos de desempenho. Enquanto Map implementa as funções sobre todos os elementos de uma coleção, por outro lado, Pack pode ser implementado como um modo de saída para um Map, onde uma flag pode ser usada para verificar se cada saída de Map pode ser 42

45 Figura 3.18: Pack Parallel Pattern. mantida ou descartada, evitando assim, usar largura de banda de memória para a saída de elementos Expand Pattern O padrão Expand também é resultante da combinação de Map com modos de saídas. Ao contrário de Pack, as saídas podem ser diferentes não apenas 0 e 1. Como pode ser visto na Figura 3.19, toda saída pode conter um número variável e os elementos são encapsulados em uma sequência simples mantendo-se a ordem e a forma sobre cada sub-grupo. Figura 3.19: Expand Parallel Pattern. Expand se torna desafiante quando não se tem conhecimento do tamanho da saída em uma progressão. Por outro lado, dispõe formas de alocação dinâmica de memória, que pode ser muito útil, mas não é possível fazer a pré-alocação das saídas. Entretanto, uma solução é colocar fronteiras (limites) no número total de elementos que podem ser gerados a partir de cada posição. 43

46 Split Pattern Split também é uma variante do padrão Pack, porém não descarta os elementos baseados em condições booleanas, ao invés disso, é possível embalá-los na metade superior do conjutno de saída [16]. Para tanto, a ordem de entrada é mantida, conforme é ilustrado na Figura Figura 3.20: Split Parallel Pattern. Neste padrão o tamanho total da saída é sempre o mesmo que o da entrada, podendo ser implementado executando duas vezes e fundindo os dois resultados. Entretanto, esta implementação pode ser mais eficiente se usado o padrão Pack, pois este padrão é determinístico e a implementação pode explorar a coerência de espaço. 44

47 4 Frameworks para Programação Paralela Multi-Core Este capítulo faz um breve estudo e levantamento dos principais frameworks de programação paralela para ambientes multi-core. Nesta breve abordagem são levantadas as principais características, bem como o suporte e licença de uso dos frameworks. 4.1 FastFlow FastFlow é um framework de programação paralela para ambientes multi-core baseado em mecanismos de sincronização não bloqueantes. Composto por uma pilha de camadas, que se resume em aplicações com memória compartilhada [21]. Este tem por finalidade fornecer abstração para promover alto nível de programação paralela e programação eficiente para aplicações multi-core, o qual é orientado para aplicações de streaming. Figura 4.1: Arquitetura FastFlow. Extraído de [2]. A Figura 4.1 apresenta a pilha de camadas sendo esta a arquitetura do Fast- Flow [2]. Através desta arquitetura são caracterizadas cada uma das camadas, 45