USO DE PARALELISMO DE DADOS EM ALGORITMOS DE PROCESSAMENTO DE IMAGENS UTILIZANDO HASKELL

Transcrição

1 PEDRO RIBEIRO MENDES JÚNIOR Orientador: Lucília Figueiredo Co-orientador: David Menotti USO DE PARALELISMO DE DADOS EM ALGORITMOS DE PROCESSAMENTO DE IMAGENS UTILIZANDO HASKELL Ouro Preto Dezembro de 2012

2 Universidade Federal de Ouro Preto Instituto de Ciências Exatas Bacharelado em Ciência da Computação USO DE PARALELISMO DE DADOS EM ALGORITMOS DE PROCESSAMENTO DE IMAGENS UTILIZANDO HASKELL Monografia apresentada ao Curso de Bacharelado em Ciência da Computação da Universidade Federal de Ouro Preto como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. PEDRO RIBEIRO MENDES JÚNIOR Ouro Preto Dezembro de 2012

3 UNIVERSIDADE FEDERAL DE OURO PRETO FOLHA DE APROVAÇÃO Uso de Paralelismo de Dados em Algoritmos de Processamento de Imagens Utilizando Haskell PEDRO RIBEIRO MENDES JÚNIOR Monografia defendida e aprovada pela banca examinadora constituída por: Dr. Lucília Camarão de Figueiredo Orientador Universidade Federal de Ouro Preto Dr. David Menotti Gomes Co-orientador Universidade Federal de Ouro Preto Dr. José Romildo Malaquias Universidade Federal de Ouro Preto Ouro Preto, Dezembro de 2012

4 Resumo O crescente desempenho dos processadores de computadores modernos deve-se ao uso de número cada vez maior de cores, unidades de processamento vetorial e GPUs. Desenvolver programas que explorem os recursos de processamento paralelo dessas arquiteturas de modo a obter maior desempenho é uma tarefa bastante complexa. Por esse motivo, diversas pesquisas têm sido desenvolvidas no sentido de prover ferramentas que possibilitem explorar esse paralelismo, sem grande sobrecarga de complexidade adicional para o programador e sem grande sacrifício no desempenho obtido. Linguagens funcionais, tais como Haskell, têm sido apontadas como um ambiente promissor para o desenvolvimento de mecanismos de automatização de paralelismo e diversas pesquisas recentes têm sido desenvolvidas nesse sentido, em particular as extensões Data Parallel Haskell e Repa, que exploram paralelismo de dados. Paralelismo de dados explora a execução simultânea de uma mesma instrução sobre diferentes dados, em diversos processadores. Esse tipo de paralelismo é útil na melhoria de desempenho de aplicações que processam grandes volumes de dados, sendo as mesmas operações aplicadas sobre subconjuntos desses dados individualmente. Tal característica ocorre frequentemente, por exemplo, em aplicações de processamento de imagens. Este trabalho constitui um estudo de recursos para explorar paralelismo que vêm sendo desenvolvidos na linguagem Haskell, e sua adequação para implementação de uma aplicação frequentemente usada em processamento de imagens, o cálculo da árvore de componentes conectados de uma imagem. Abordar esse problema específico nos pareceu interessante, já que não é evidente como pode ser explorado paralelismo, com a linguagem Haskell, na solução deste problema. Os resultados do nosso estudo podem ser resumidos do seguinte modo: ficou evidente que a extensão para paralelismo Data Parallel Haskell não pode ser utilizada no algoritmo para o cálculo da árvore de componentes conectados utilizado em nossa análise. A implementação do mesmo algoritmo com a extensão Concurrent Haskell, que permite programação concorrente utilizando threads explícitas foi comparada com implementações em C++ e MATLAB. A eficiência da implementação utilizando Concurrent Haskell não é superior à implementação em C++ com PThreads. i

5 Abstract The increasing performance of modern computer processors are caused by the use of increasing number of cores, units vector processing, and GPUs. To develop programs exploiting parallel processing capabilities of these architectures in order to obtain higher performance is a quite complex task. For this reason, several studies have been developed in sense of providing tools allowing to explore this parallelism, without large overhead of additional complexity to the programmer and without great sacrifice in the obtained performance. Functional languages such as Haskell, have been identified as one promising environment for developing automation mechanisms for parallelism. Several recent studies have been developed in this direction, in particular the Data Parallel Haskell extension and Repa library, which exploit data parallelism. Data parallelism exploits the simultaneous execution of the same instruction on different data on multiple processors. This kind of parallelism is helpful to improve the performance of applications that process large volumes of data, where same operations are applied to subsets of data individually. This characteristic occurs frequently, for example in digital image processing applications. This work is a study of resources for exploring parallelism that have been developed in the Haskell language, and their suitability for implementation of an application often used in image processing: the calculation of the connected components tree of an image. Addressing this problem in particular seemed interesting, since it is not clear how parallelism can be exploited, using Haskell, in solving this problem. The results of our study can be summarized as follows: it became evident that the Data Parallel Haskell extension for parallelism can not be used in the algorithm for calculation of connected components tree used in our analysis. The implementation of the same algorithm with the Concurrent Haskell extension, that allows concurrent programming using explicit threads, was compared with C++ and MATLAB implementations. The Concurrent Haskell efficiency is not superior to the C++ implementation using PThreads. ii

6 Dedico este trabalho a todos os professores e colegas que contribuíram para a minha boa formação acadêmica durante o período de graduação. iii

7 Agradecimentos Agradeço primeiramente aos meus pais, por terem sido os primeiros a abrir-me os caminhos para a realização de meus propósitos. Sou muito grato por todo o esforço realizado para me manter na cidade de Ouro Preto e permitir que eu cursasse uma graduação sem passar por dificuldades que impossibilitaria a realização de alguns dos mesmos propósitos. Não tenho dúvidas quanto à nobreza de seus sentimentos e muito me impressiona a força de sua realidade. Longe de poder retribuir tudo, agradeço ao meu orientador David Menotti, por sua paciência e perseverança para comigo e por constantemente dar mostras de confiança em minha capacidade, apesar de eventualmente dar mostras de tristeza quando não aproveito devidamente as oportunidades. Penso que a maior parte da bagagem acadêmica que trago hoje comigo, se deveu aos elementos prodigalizados sem restrições por David Menotti. Neste sentido, mais um motivo de minha gratidão é ter ele me permitido estabelecer uma amizade que potencializa qualquer transmissão de conhecimento entre duas mentes. Muitos agradecimentos também à minha orientadora Lucília Figueiredo pela oportunidade de realizar um curso de programação funcional na Holanda. Essa foi talvez a experiência acadêmica mais interessante de meu período de graduação. Agradeço aos meus amigos Rodrigo Bauerfeld e Murilo Mizutsu pela disposição que tiveram de criar um bom ambiente de moradia em Ouro Preto. Este ambiente, além de possibilitar o desenvolvimento de qualquer estudo universitário, propicia conhecimentos de várias naturezas e principalmente os que se relacionam à existência humana e sua evolução integral. Este ambiente que criamos foi o fator que mais influenciou no meu desenvolvimento humano durante o período de graduação. Sem dúvida, agradeço aos meus amigos Victor Hugo e Antônio Carlos pelos momentos passados juntos no laboratório e pela troca de conhecimentos obtidos fora do contexto das disciplinas. iv

8 Sumário 1 Introdução 1 2 Paralelismo em Haskell 4 3 Cálculo da Árvore de Componentes Conectados 7 4 Implementação paralela do cálculo da CCT em Haskell Data Parallel Haskell Concurrent Haskell Experimentos e Resultados 17 6 Conclusões 20 Referências Bibliográficas 22 Apêndice 25 v

9 Lista de Figuras 1.1 Diferença entre (a) um problema de problema de Processamento Digital de Imagens convencional e o (b) problema de Processamento Digital de Imagens escolhido Classificação dos tipos de paralelismo apresentado por Jones et al. (2008) evidenciando a transformação que ocorre na etapa de vetorização do código Custo típico de uma aplicação baseada na Árvore de Componentes Conectados [Matas et al. (2008)] Exemplo de uma imagem e sua Árvore de Componentes Conectados. Fonte: [Matas et al. (2008)] Exemplo de uma (a) imagem com a (b) computação parcial da Árvore de Componentes Conectados em cada linha e (c) sua Árvore de Componentes Conectados Exemplo de como é realizado o paralelismo na etapa de fusão das Árvores de Componentes Conectados pelo algoritmo de Matas et al. (2008). Cada etapa deve esperar a anterior terminar para começar. Por exemplo, as fusões mostradas em (b) devem esperar as fusões mostradas em (a). Em cada etapa, as fusões que são representadas com uma linha ziguezagueante ocorrem de maneira paralela Imagens utilizadas para testes e suas dimensões vi

10 Lista de Tabelas 5.1 Resultados de tempo de execução das implementações em Haskell, C++ e MATLAB, em segundos. O número máximo de threads utilizadas na execução da implementação paralela do código em C++ é o número de linhas da imagem. A implementação em MATLAB apresenta tempo mínimo de execução de duas horas para o algoritmo paralelo Resultados mais minuciosos de tempo de execução das implementações em Haskell, C++ e MATLAB, em segundos. Haskell seq. se refere à execução da implementação sequencial em Haskell. Haskell 1, Haskell 2 e Haskell 4 se referem às execuções do algoritmo paralelo em Haskell com uma, duas e quatro threads, respectivamente. C++ seq. e C++ par. se referem ao tempo de execução das implementações sequenciais e paralelas, respectivamente, na linguagem C vii

11 Lista de Algoritmos 1 Algoritmo 1D para a computação parcial da point-tree Algoritmo 2D para a computação da point-tree viii

12 Lista de Códigos 4.1 Possível implementação do algoritmo para a construção unidimensional da Árvore de Componentes Conectados caso não houvessem as restrições apresentadas, ou caso a adição de um novo elemento no array paralelo pudesse ser realizada sem a cópia do array original Trecho do código que introduz paralelismo e sincroniza as execuções Implementação em Haskell do algoritmo de Matas et al. (2008) Implementação em C++ do algoritmo de Matas et al. (2008) Implementação em MATLAB do algoritmo de Matas et al. (2008) ix

13 Capítulo 1 Introdução Este trabalho visa estudar oportunidades de explorar a capacidade de processamento paralelo dos computadores modernos em algoritmos de Processamento Digital de Imagens (PDI) e estudar a eficiência das implementações destes algoritmos em linguagem de programação funcional. Neste trabalho, a linguagem escolhida foi Haskell [Jones (2002)]. A arquitetura dos computadores modernos, inclusive PCs, é baseada em múltiplos processadores, sendo um exemplo particularmente importante o de Unidades de Processamento Gráfico (GPUs - Graphics Processing Unit) [Keller et al. (2012)], constituídas de dezenas de processadores, e altamente eficientes para a manipulação de imagens gráficas. A estrutura altamente paralela de GPUs as torna também mais efetivas do que as CPUs de propósito geral para algoritmos nos quais podem ser explorados o processamento de grandes blocos de dados em paralelo. Existem trabalhos no sentido de estender a linguagem Haskell de modo a tornar mais simples expressar esse tipo de algoritmo [Chakravarty et al. (2011)]. Apesar disso, a utilização das GPUs ainda tem algumas desvantagens como, por exemplo, a instabilidade dos frameworks e a dificuldade de depuração do código [Grozea et al. (2010)] Várias formas de paralelismo podem ser exploradas na execução de programas. O mais comum é o paralelismo de controle, no qual se criam explicitamente threads que executam paralelamente e cujo processamento é sincronizado por meio de mensagens, locks ou outros mecanismos de sincronização [Pacheco (2011)]. O paralelismo de dados consiste na execução simultânea de uma mesma instrução em diferentes porções de um conjunto de dados, sendo esta abordagem particularmente promissora para o emprego de grande número de processadores [Chakravarty et al. (2007)]. O trabalho pioneiro de Blelloch (1996) em NESL (NESted-parallel Language) mostrou que é possível combinar um modelo de programação bastante flexível Paralelismo de Dados Aninhados (NDP - Nested Data Paralelism) com um modelo de execução eficiente e de grande escalabilidade Paralelismo Plano de Dados (FDP - flat data paralelism) ampliando o leque de possibilidades para explorar paralelismo em programas. Essa abordagem é implementada em Data Parallel Haskell (DPH) [Chakravarty et al. (2007); Jones et al. (2008)], um 1

14 1. Introdução 2 dos frameworks de programação que prepusemos estudar, que consiste em uma extensão do compilador Glasgow Haskell Compiler (GHC) [GHC (2012)] da linguagem Haskell e de suas bibliotecas, de maneira a embutir na linguagem o NDP. Uma área na qual parece ser particularmente fértil explorar essa forma de paralelismo para obter implementações eficientes e em que o esforço do programador para realizá-las pode ser diminuído por meio de uma ferramenta de paralelização automática é a área de PDI [Seinstra e Koelma (2004)]. Alguns exemplos de sucesso na implementação de algoritmos convencionais paralelos para PDI utilizando tais ferramentas são reportados, por exemplo, em Bräunl (2000); Seinstra e Koelma (2004); Abramov et al. (2010); Lippmeier e Keller (2011). É reportado na literatura várias implementações bem sucedidas de algoritmos convencionais de PDI, como por exemplo, detecção de bordas, smoothing, dithering e segmentação [Bräunl (2001)], utilizando ferramentas de paralelismo automático [Keller et al. (2010); Lippmeier e Keller (2011)]. Por isso, optamos por analisar o benefício das extensões e bibliotecas quanto à implementação de algoritmos não tracionais de PDI. Queremos mencionar com a expressão algoritmos não convencionais os algoritmos cuja entrada é uma imagem, mas que a saída corresponde a uma outra estrutura qualquer, como por exemplo uma árvore. Utilizamos então o algoritmo de PDI proposto por Matas et al. (2008) para a geração de Árvore de Componentes Conectados (CCT - Connected Component Tree), como sendo a aplicação base na análise das bibliotecas. Classificamos esse método como sendo não convencional, dado que seu resultado não é uma imagem e sim uma árvore, como representado na Figura 1.1b. Na Figura 1.1 representamos a diferença entre um algoritmo convencional, como é o caso de um algoritmo de detecção de bordas, e um algoritmo não convencional, como é o caso do algoritmo de Matas et al. (2008) para o cálculo de CCT. Avaliamos as extensões Data Parallel Haskell (DPH) e Concurrent Haskell (CH) na implementação de um algoritmo não convencional de PDI, mostramos que DPH não pode ser (a) Método convencional de Processamento Digital de Imagens. (b) Entrada e saída do método de Processamento Digital de Imagens escolhido para trabalho. Figura 1.1: Diferença entre (a) um problema de problema de Processamento Digital de Imagens convencional e o (b) problema de Processamento Digital de Imagens escolhido.

15 1. Introdução 3 utilizado no algoritmo para o cálculo da CCT [Matas et al. (2008)] que propomos utilizar, apresentamos uma implementação paralela deste algoritmo utilizando CH e apresentamos comparações com implementações em C++ e MATLAB. No Capítulo 2 apresentamos uma revisão da literatura referente às extensões analisadas, outras bibliotecas de paralelismo e implementações bem sucedidas de algoritmos de PDI. No Capítulo 3 apresentamos o problema do cálculo da CCT e o algoritmo de Matas et al. (2008). No Capítulo 4 apresentamos uma análise das extensões da linguagem Haskell para paralelismo e concorrência. No Capítulo 5 apresentamos os experimentos realizados e os resultados obtidos. Por fim, no Capítulo 6 apresentamos as conclusões obtidas com a realização deste trabalho.

16 Capítulo 2 Paralelismo em Haskell Este capítulo descreve, de maneira sucinta, as principais extensões da linguagem Haskell para implementação de algoritmos paralelos, destacando diferenças entre a maneira de pensar e implementar algoritmos em linguagens funcionais em contraposição às linguagens imperativas, mais comumente usadas. Vale ressaltar que Haskell é uma linguagem de alto nível, que provê recursos para que paralelismo de dados seja automaticamente implementado pelo compilador, sem que o programador tenha que se preocupar explicitamente com o balanceamento de dados entre os processadores disponíveis na máquina, além de oferecer bibliotecas de comandos paralelos usuais. Haskell oferece grande oportunidade para construção de abstrações, inclusive para programação concorrente e paralela [Marlow (2012)]. Por isso, as extensões em Haskell possuem uma grande diferença entre si na maneira de utilizá-las. Em Haskell, é possível realizar uma grande diferenciação entre programação paralela e programação concorrente, diferenciação essa que normalmente não é tão evidenciada em linguagens com paradigma imperativo. A programação paralela nos dá um grande benefício, que é poder ter implementações que utilizam mais de um processador mesmo sem perder o determinismo [Marlow et al. (2011)], obtendo assim uma maior facilidade de realizar testes e comprovar que o programa está correto, uma vez que a implementação de uma função deste tipo em Haskell gerará código puro [Jones e Singh (2009)]. Em um programa paralelo estamos preocupados com a eficiência, pois a tarefa é aproveitar, em uma determinada computação, a maior quantidade dos recursos de processamento disponíveis, enquanto que em um programa concorrente o foco é a estrutura do programa, de modo a permiti-lo interagir com múltiplos agentes externos [Marlow et al. (2011); Marlow (2012)]. Por exemplo, poderíamos querer um programa concorrente, mesmo que ele seja executado em somente um processador, para que ele possa realizar cálculos e receber requisições externas ao mesmo tempo, sem que a espera por requisições impeça a utilização do processador para realizar os cálculos. Neste sentido, procuramos avaliar tanto as extensões voltadas para o paralelismo quanto para concorrência. A extensão que mais nos chamou a atenção para explorar paralelismo em Haskell para Pro- 4

17 2. Paralelismo em Haskell 5 cessamento Digital de Imagens (PDI) foi o Data Parallel Haskell (DPH). DPH é uma extensão em desenvolvimento da linguagem Haskell, que provê bibliotecas para suportar paralelismo de dados aninhados (NDP) [Jones et al. (2008)]. Uma vez que o desenvolvimento desta extensão acontece no nível do compilador, DPH permite o desenvolvimento de código paralelo com sintaxe semelhante à sintaxe de um código sequencial (em versões futuras do compilador GHC, a sintaxe poderá ser a mesma, ou seja, a biblioteca realiza o paralelismo do código de maneira automática e independentemente do programador) [Jones et al. (2008); DPH (2012)]. O paralelismo no DPH é realizado com base no chamado array paralelo. Do ponto de vista do usuário a implementação utilizando DPH é semelhante à uma implementação sobre listas em Haskell, com algumas pequenas diferenças de notação: Um array paralelo de elementos do tipo e é denotado por [:e:], de maneira semelhante à notação [e], usada para denotar uma lista de elementos do tipo e; Funções de ordem superior, como map, filter e unzip, tem o sufixo P adicionado em cada nome (ficam mapp; filterp e unzipp); Parallel array comprehensions recebem também uma pequena modificação na sintaxe. Enquanto uma list comprehension pode ser escrita por [x y x < list, y < [1, 2, 3]] o equivalente para arrays paralelos é denotado por [ :x y x < list, y < [:1, 2, 3 : ] : ] Na implementação do DPH, existe uma etapa de vetorização do código (code vectorization), que consiste em transformar o código com NDP do DPH em código com paralelismo plano de dados (FDP). Na Figura 2.1 é mostrado onde acontece tal vetorização. Na Figura 2.1 também é mostrado uma divisão dos tipos de paralelismo apresentados por Jones et al. (2008). Paralelismo de tarefas (task parallelism) se refere à utilização de threads de maneira explícita, com a sincronização via locks e mensagens. Paralelismo de dados (data parallelism) é dividido entre duas formas de paralelismo: FDP e NDP. FDP (normalmente referenciado como simplesmente paralelismo de dados) é a forma de paralelismo em que operações sequenciais são aplicadas em um volume de dados de forma paralela. Enquanto isso, uma das ideias do NDP é permitir a aplicação de operações paralelas de forma paralela em um volume dados. A princípio, a utilização do DPH em algoritmos de PDI (algoritmos baseados em matriz) nos pareceu promissor, dado que o DPH trabalha sobre os arrays paralelos [Jones et al. (2008)] e uma imagem é basicamente representada como um array de arrays. Uma vez que o DPH é um framework em desenvolvimento e o NDP está sendo pela primeira vez implementado em

18 2. Paralelismo em Haskell 6 uma linguagem de propósito geral, são necessários testes em diversas áreas, e a área de PDI também se inclui entre elas. Na Seção 4 apresentamos as observações realizadas quanto ao uso da extensão DPH no algoritmo para o cálculo de Árvore de Componentes Conectados (CCT) proposto por Matas et al. (2008), mostrado a impossibilidade de utilizá-la na implementação deste algoritmo. Repa [Keller et al. (2010); Lippmeier e Keller (2011)] é uma biblioteca em Haskell específica para PDI, que contém implementações de algoritmos para, por exemplo, convolução, operações sobre matrizes, transformadas do espaço de cor RGB para grayscale, etc. Uma vez que um de nossos objetivos é realizar a implementação de algoritmos não convencionais de PDI em Haskell para também observar a facilidade de extensão da biblioteca com operações não previstas de antemão pela mesma, decidimos por não utilizar Repa, por ser uma biblioteca que embute o paralelismo na estrutura de dados, atrapalhando assim a extensão de operações aplicadas de maneira não sequencial [Repa (2012); Keller et al. (2010)]. A extensão Concurrent Haskell (CH) do compilador Haskell, proposta por Peyton Jones et al. (1996), também foi avaliada neste trabalho. CH provê suporte para programação com threads explícitas e uma mônada MVar para abstrair a comunicação de baixo nível. Segundo Marlow (2012), pode-se pensar em MVar como uma caixa que ou está vazia ou está cheia, ou seja, uma thread pode colocar em um MVar no máximo um elemento, e a próxima operação, realizada por qualquer thread, deverá ser de retirada. Essas operações na mônada MVar são realizadas atomicamente. Como será mostrado na Seção 4, juntamente com o CH utilizamos a estrutura MVector da linguagem Haskell para representar a imagem. Figura 2.1: Classificação dos tipos de paralelismo apresentado por Jones et al. (2008) evidenciando a transformação que ocorre na etapa de vetorização do código.

19 Capítulo 3 Cálculo da Árvore de Componentes Conectados Para que pudéssemos estudar as evidências favoráveis ou não favoráveis da linguagem Haskell voltada para paralelismo em algoritmos de PDI, optamos por escolher uma aplicação de PDI não convencional. Com isso, queremos dizer que o problema escolhido, cálculo de CCTs, possui algoritmos [Matas et al. (2008)] que não utilizam simplesmente operações de convoluções, aplicação de filtros, etc. O algoritmo escolhido de Matas et al. (2008) (Algoritmos 1 e 2) realiza acesso aos pixels da imagem de maneira não sequencial e a posição de acesso é definida em tempo de execução com base nos valores dos pixels. O cálculo da CCT é um modelo que está se tornando bastante comum para analisar imagens em tons de cinza [Wilkinson et al. (2008)], que provê uma representação hierárquica de imagens e com várias aplicações, como por exemplo, segmentação, detecção e caracterização de objetos [Perret et al. (2010)]. Por causa disso, são necessários algoritmos que possam fazer o cálculo da CCT mais eficientemente. Como é mostrado na Figura 3.1, em uma aplicação típica que utiliza a CCT o maior custo computacional acontece no cálculo da CCT. A motivação da implementação de algoritmos paralelos para o cálculo da CCT é justamente diminuir este custo. A CCT é uma estrutura hierárquica que provê informações dos componentes conectados Figura 3.1: Custo típico de uma aplicação baseada na Árvore de Componentes Conectados [Matas et al. (2008)]. 7

20 3. Cálculo da Árvore de Componentes Conectados 8 em uma imagem com qualquer limiar de binarização. Segundo Najman e Couprie (2006), os conjuntos de níveis são os conjuntos de pontos (pixels) com nível acima de um determinado limiar. Então, definindo mais formalmente a CCT: os componentes conectados de um conjunto de nível podem ser organizados em uma estrutura de árvore, graças à relação de inclusão, e esta árvore chamamos de CCT. Um exemplo de construção da CCT a partir da imagem da Figura 3.2a é mostrado na Figura 3.2b. Pode ser observado, tanto na imagem quanto na CCT que uma binarização com o maior limiar, resultaria em dois componentes conectados (o pixel 2 e o pixel 6). O mesmo ocorre com o segundo e o terceiro maiores limiares. A partir do quarto maior limiar, a imagem terá um único componente conectado. Matas et al. (2008) representa a CCT como uma matriz com o mesmo tamanho da imagem de entrada, que chamamos de point-tree. Cada elemento da matriz corresponde a um pixel da imagem e contém as coordenadas de seu pai. A raiz da point-tree terá uma coordenada não válida para indicar que não possui um pai. Esta representação da CCT é claramente apropriada, dado que tanto a atualização do valor de um ponto, quanto a verificação de seu conteúdo se dá de maneira direta (O(1)). Em Haskell evitamos a utilização de árvores dado que tanto a atualização quanto a verificação de um valor da point-tree não seria de forma direita. Assim, procuramos implementações que mantivessem a mesma ordem de complexidade de um algoritmo em linguagem imperativa. Existem três classes principais de algoritmos para cálculo de CCT: algoritmos baseados em inundação [Salembier et al. (1998)], algoritmos ascendentes [Najman e Couprie (2006); (a) Imagem de origem. (b) Árvore de Componentes Conectados. Figura 3.2: Exemplo de uma imagem e sua Árvore de Componentes Conectados. [Matas et al. (2008)]. Fonte:

21 3. Cálculo da Árvore de Componentes Conectados 9 Berger e Géraud (2007); Berger e Widynsky (2005)] e algoritmos sobre uma dimensão [Menotti et al. (2007)]. Os algoritmos que trabalham sobre uma dimensão podem ser adaptados para trabalharem em duas ou mais dimensões [Salembier et al. (1998)]. Este também é o caso do algoritmo que utilizamos na realização deste trabalho. Isso faz com que os algoritmos sejam claramente paralelizados. O algoritmo de Matas et al. (2008) consegue o paralelismo nas etapas de construção parcial da CCT para cada dimensão e na etapa de fusão dos resultados parciais, dado que os cálculos das CCTs em cada dimensão acontecem de maneira independente e a fusão dos resultados parciais também pode ser parcial e independente. A função build1d apresentada no Algoritmo 1 é responsável pela construção unidimensional da CCT. Como pode ser visto nessa função, a computação sobre um pixel de uma linha da imagem f só é possível após a computação sobre os pixels anteriores, ou seja, os pixels mais à esquerda, já que a pilha utilizada representa o resultado de tal computação. Com isso, nota-se que essa função não pode ser paralelizada. Como é mostrado na Figura 3.3b, após a construção das CCTs nas linhas da imagem utilizando a função build1d, obtém-se uma point-tree onde cada linha é uma CCT independente. Note que na point-tree da Figura 3.3b cada nó de cada linha sempre aponta para um nó da mesma linha e cada linha contém um nó raiz. Para criar uma nova CCT a partir da fusão entre duas CCTs, utiliza-se a função merge apresentada no Algoritmo 2. Duas operações de fusão de CCTs podem ocorrer paralelamente se não compartilharem uma mesma CCT parcial, pois durante a fusão as CCTs são alteradas. Isto é mostrado na Figura 3.4a, onde cada linha ziguezagueante representa uma operação de fusão realizada pela função merge. Essa mesma Figura 3.4a mostra o máximo de operações de junção possível para uma imagem de 11 linhas (0 a 10) em uma primeira etapa. Cada etapa apresentada na Figura 3.4 mostra o máximo possível de operações paralelas de junção. Observe que a fusão apresentada na Figura 3.4c não pode ocorrer paralelamente à (a) Imagem de origem. (b) Árvore de Componentes Conectados para cada linha da imagem. (c) Árvore de Componentes Conectados para a imagem toda. Figura 3.3: Exemplo de uma (a) imagem com a (b) computação parcial da Árvore de Componentes Conectados em cada linha e (c) sua Árvore de Componentes Conectados.

22 3. Cálculo da Árvore de Componentes Conectados 10 Algorithm 1 Algoritmo 1D para a computação parcial da point-tree. Require: imagem f : V line R Ensure: point-tree par : V line V line { V = {0... W 1 {0... H 1 line {0... H 1 número de linhas a serem processadas V line = {0... W 1 {line = {(i, j) V ; j = line procedure build1d(line : integer) r : point (0, line); for p : point (1, line), (W -1, line) do if f(r) < f(p) then StackPush(r); r p; else if f(r) = f(p) then par[p] r; else loop q : point StackLast(); if f(q) < f(p) then par[r] p; r p; break; else if stackempty() or f(q) = f(p) then par[r] q; par[p] q; r q; StackPop(); break; else par[r] q; r q; StackPop(); end if end loop end if end for while not StackEmpty() do par[r] StackLast(); r StackLast(); StackPop(); end while par[r] r é raiz end procedure (a) Primeira etapa. (b) Segunda etapa. (c) Terceira etapa. (d) Quarta etapa. Figura 3.4: Exemplo de como é realizado o paralelismo na etapa de fusão das Árvores de Componentes Conectados pelo algoritmo de Matas et al. (2008). Cada etapa deve esperar a anterior terminar para começar. Por exemplo, as fusões mostradas em (b) devem esperar as fusões mostradas em (a). Em cada etapa, as fusões que são representadas com uma linha ziguezagueante ocorrem de maneira paralela.

23 3. Cálculo da Árvore de Componentes Conectados 11 Algorithm 2 Algoritmo 2D para a computação da point-tree. Require: imagem f : V a,b R Require: point-tree par : V a,b V a,b { Ensure: point-tree par : V a,b { V a,b = {0... W 1 {a... b = {(i, j) V ; a j b function levroot(x : point) if x é raiz then return x; else if f(x) = f(par[x]) then par[x] levroot(par[x]); return par[x]; else return x; end if end function procedure connect(x, y : point) x levroot(x); y levroot(y); if f(y) > f(x) then swap(x, y); end if while x y do if par[x] = then par[x] = y; x = y; else z : point levroot(par[x]); if f(z) > f(y) then x z; else par[x] y; x y; y z; end if end if end while end procedure procedure merge(border : integer) for all vizinhos x, y entre as linhas (border-1) e border do connect(x, y); end for end procedure fusão mostrada na Figura 3.4d, dado que compartilhariam uma mesma CCT parcial. Após a última fusão, obtém-se a CCT da imagem. Na Figura 3.3c apresentamos um exemplo de CCT para a imagem de entrada da Figura 3.3. Observe que na CCT da Figura 3.3c existe somente uma raiz, pois a CCT representada se refere a imagem toda.

24 Capítulo 4 Implementação paralela do cálculo da CCT em Haskell Neste capítulo, investigamos as dificuldades encontradas na tentativa de usar DPH para implementação paralela do cálculo de CCT. Tal análise é apresentada na Seção 4.1. Na Seção 4.2 apresentamos a extensão CH, suas características e a implementação do algoritmo de Matas et al. (2008) utilizando-a. 4.1 Data Parallel Haskell Como foi mencionado na Seção 2, o DPH foi a extensão que mais nos chamou a atenção para explorar o paralelismo em Haskell em aplicações de PDI, dado sua implementação do modelo de paralelismo de dados aninhados (NDP). A princípio, a área de PDI aparentava ser bastante fértil para explorar tal modelo de paralelismo, dado que esse tipo de paralelismo é baseado totalmente na utilização de arrays paralelos e imagens digitais são basicamente representadas como arrays de array de pixels. A característica mais importante e que mais chama a atenção no DPH é a possibilidade de criação de código semelhante a um código sequencial, de modo que o compilador realiza o paralelismo automaticamente. Isso é possível uma vez que o DPH faz uso dos arrays paralelos de modo análogo a listas em Haskell; com base nos arrays paralelos, o código é transformado depois, pelo compilador, para paralelismo plano de dados (FDP). Uma vez que o paralelismo é realizado implicitamente, é necessário que o acesso ao array paralelo seja realizado por meio de uma API, para que possa ser realizada a vetorização do código [Jones et al. (2008)]. O processo de vetorização é realizado pelo compilador (estendido com o DPH) e tem como objetivo transformar um código no modelo de paralelismo de dados aninhados (código DPH) para um código com o modelo de FDP para que, em fim, o código termine de ser compilado pelo GHC sem a extensão DPH. Representamos tal etapa de vetorização na Figura

25 4. Implementação paralela do cálculo da CCT em Haskell 13 A principal limitação do DPH que inviabiliza a implementação do algoritmo para gerar a CCT no DPH, é o fato de que não é possível utilizar código não paralelo (não passível de ser vetorizado ) embutido em um código paralelo a ser vetorizado. Esta limitação do DPH é evidenciada levando em consideração que o DPH possui seu prelude [Jones (2002)] próprio [Chakravarty e Keller (2001)] e que obrigatoriamente deve ser utilizado ao invés do prelude do Haskell, ou seja, as funções definidas no prelude do DPH são projetadas de modo a ser vetorizadas durante a etapa de vetorização representada na Figura 2.1. Por outro lado, a API fornecida pela biblioteca do DPH não possui funções capazes de expressar as computações necessárias para implementar a função build1d utilizando os arrays paralelos (a API da versão do DPH que utilizamos é apresentada no Apêndice deste trabalho). Ao utilizar a biblioteca DPH, não é possível utilizar o tipo lista no mesmo módulo, ou seja, o tipo lista não é passível de ser vetorizado. Para evidenciar as limitações do DPH, no Código 4.1 apresentamos uma possível implementação da função build1d caso fosse possível a utilização do tipo lista em um código a ser vetorizado. Neste código, utilizaríamos as funções updatep 1, replicatep, indexedp e lengthp (veja Apêndice), além dos operadores redefinidos no prelude do DPH. Observe que no Código 4.1, o tipo lista poderia ser substituído pelo array paralelo caso a atualização (ou adição) de um novo elemento pudesse ser realizada em O(1). Na computação da CCT em uma dimensão do algoritmo de Matas et al. (2008) há a necessidade de realizar tal computação utilizando funções não previstas pela API do DPH. Mas isso implica inserção de código que não pode ser vetorizado dentro de código que deve ser vetorizado. Logo, o compilador não poderá fazer a vetorização. Com isso, observamos que as etapas sequenciais não podem ser realizadas por fora do DPH (utilizando outras estruturas não previstas pelo vetorizador do DPH), nem podem ser realizadas dentro do DPH (utilizando os arrays paralelos), o que impossibilita a utilização do DPH para esta aplicação. Por esses motivos, foi possível verificar que sua biblioteca de NDP, em seu atual estágio de desenvolvimento, ainda não oferece recursos apropriados para a implementação de algoritmos que exigem etapas de computação não passíveis de serem paralelizadas antes de realizar o paralelismo sobre os resultados destas computações. Isso nos levou a nosso primeiro resultado, um tanto quanto negativo. 4.2 Concurrent Haskell Dada a natureza do algoritmo escolhido, optamos por implementá-lo utilizando biblioteca de concorrência, juntamente com a biblioteca Mutable Vector, ao invés de bibliotecas de paralelismo de dados. Essa forma de implementação de paralelismo introduz dificuldades adicionais para garantia de determinismo e, por consequência, realização de testes e prova 1 A última versão do DPH ( ) não mais possui a função updatep :: [:a:] -> [:(Int, a):] -> [:a:] em sua API. Utilizamos neste trabalho a versão do DPH.

26 4. Implementação paralela do cálculo da CCT em Haskell 14 Código 4.1: Possível implementação do algoritmo para a construção unidimensional da Árvore de Componentes Conectados caso não houvessem as restrições apresentadas, ou caso a adição de um novo elemento no array paralelo pudesse ser realizada sem a cópia do array original. build1d : : [ : Int : ] > [ : Int : ] build1d line = updatep ( replicatep (lengthp line ) 0) $ fromlist $ build emptystack (line! : 0) (line, 1) [ ] where line = indexedp line build : : Stack (Int, Int) > (Int, Int) > ([:(Int, Int):], Int) > [(Int, Int)] > [(Int, Int)] build s r (ps, i ) l i >= lengthp ps = finish s r l otherwise = let (s, r, l ) = step s r (ps! : i ) in build s r (ps, i+1) ( l ++ l ) step : : Stack (Int, Int) > (Int, Int) > (Int, Int) > (Stack (Int, Int), (Int, Int), [(Int, Int)]) step s r@( ir, vr) p@(ip, vp) = let q@(iq, vq) = stacklast s in if vr < vp then (stackpush s r, p, [ ] ) else if vr == vp then (s, r, [( ip, ir )]) else if stackempty s vq < vp then (s, p, [( ir, ip )]) else if vq == vp then (stackpop s, q, [( ir, iq ), (ip, iq )]) else let (s, r, l ) = step (stackpop s) q p in (s, r, [( ir, iq )] ++ l ) finish : : Stack (Int, Int) > (Int, Int) > [(Int, Int)] > [(Int, Int)] finish s r@( ir, _) l stackempty s = l ++ [( ir, 1)] otherwise = finish (stackpop s) q ( l ++ [( ir, iq )]) where q@(iq, _) = stacklast s

27 4. Implementação paralela do cálculo da CCT em Haskell 15 de que o código está correto, pois é necessário o uso de uma mônada de estados (no caso, a mônada IO). No algoritmo de Matas et al. (2008) (Algoritmos 1 e 2) para cálculo da CCT, as alterações realizadas na point-tree em construção ocorrem de maneira não sequencial e dependente do fluxo de execução do mesmo. Isso define a natureza do algoritmo (mencionada anteriormente) que nos motiva a realizar a implementação utilizando MVector juntamente com a extensão Concurrent Haskell (CH). Com a utilização do MVector, a estrutura de dados, no caso um vetor, deixa de ser imutável, o que possibilita a atualização de componentes em um dado MVector. A extensão Concurrent Haskell provê quatro primitivas que possibilitam seu uso: newemptymvar : : IO (MVar a) takemvar : : MVar a > IO a putmvar : : MVar a > a > IO () forkio : : IO () > IO ThreadId Um objeto do tipo MVar a pode ser pensado como uma referência para a localização onde se encontra o elemento de tipo a [Peyton Jones et al. (1996)]. A localização pode ser alterada com putmvar e o elemento pode ser acessado usando takemvar. A função newemptymvar é utilizada somente para a criação desta localização para um tipo a qualquer. A função forkio é utilizada na criação de novos processos que são gerenciados pelo sistema de execução Haskell. Esses processos não correspondem a processos do sistema operacional [Peyton Jones et al. (1996)]. Na chamada do programa que utiliza a extensão CH, é passado um parâmetro referente ao número de threads do sistema operacional que serão criadas:./programa +RTS N2 RTS Os argumentos entre os argumentos +RTS e -RTS não serão lidos pelo programa do usuário, mas sim pela extensão CH, uma vez que o código gerador do programa foi compilado utilizando-se a opção -threaded. No exemplo acima, é especificado que a execução ocorrerá utilizando duas threads Código 4.2: Trecho do código que introduz paralelismo e sincroniza as execuções mapm_p :: Monad m=> (a > m b) > [a] > m () mapm_p f xs = do mvars < myreplicate (length xs) newemptymvar mapm_ (forkio. fthread) $ zip mvars xs mapm_ takemvar mvars where fthread (mvar, l ) = f l >> putmvar mvar () myreplicate : : Int > IO a > IO [a] myreplicate n x = sequence $ replicate n x

28 4. Implementação paralela do cálculo da CCT em Haskell 16 Nessa abordagem utilizando CH a implementação do algoritmo de Matas et al. (2008) pouco difere da sua implementação em uma linguagem imperativa. No Código 4.2 apresentamos onde é realizado o paralelismo, ou seja, onde há introdução extra de código em comparação a uma implementação sequencial utilizando MVector. A função mapm_p tem o mesmo tipo que a função mapm_ já definida no prelude do Haskell. Sua tarefa é realizar paralelamente as computações obtidas pela aplicação da função dada (primeiro argumento) a cada um dos elementos da lista dada (segundo argumento), e esperar as computações terminarem para terminar. Esta função é utilizada em dois momentos no código para o cálculo da CCT. Abaixo é mostrado o exemplo de sua primeira utilização, onde a função matas1d constrói a CCT em uma dimensão na estrutura MVector e height se refere à altura da imagem, que por consequência é também a altura da matriz que representa a point-tree. No Apêndice (página 25) apresentamos a implementação utilizando CH. mapm_p matas1d [0.. height 1]

29 Capítulo 5 Experimentos e Resultados Como mencionado na Seção 4, o principal foco de análise deste projeto foi na utilização do Data Parallel Haskell (DPH) e do Concurrent Haskell (CH). A implementação com a extensão DPH não foi passível de ser obtida, como foi mostrado na Seção 4.1. Quanto à extensão CH, realizamos uma implementação utilizando-a e a comparamos com implementações na linguagem C++ e MATLAB. Construímos a Tabela 5.1, que apresenta os resultados de tempo de execução obtidos com as implementações em Haskell, C++ e MATLAB 1. Os valores são apresentados em segundos e representam a média do tempo gasto para execução em 7 imagens de tamanhos diferentes. Para cada imagem foram realizadas 10 execuções. Os testes foram realizados em um computador com processador Intel Pentium i3. A implementação em C++ foi realizada utilizando POSIX threads (PThreads) e a implementação em MATLAB utilizou a toolbox Parallel Computing Toolbox [MathWorks (2012)]. Tanto a compilação do código em Haskell quanto do código em C++ foram realizadas com o parâmetro de otimização -O2. Foram utilizados os compiladores GHC e G++ nas versões e 4.7.2, respectivamente. Na linguagem Haskell e MATLAB é possível especificar o número de threads do sistema operacional a serem utilizadas no momento da execução. Desse modo, na Tabela 5.1 apresentamos o tempo de execução com até 4 threads utilizadas. Como na implementação em C++ não é possível limitar o número de threads utilizadas, uma vez que utilizamos threads nativas, apresentamos somente dois resultados que se referem às execuções sequencial e paralela. De acordo com os resultados apresentados na Tabela 5.1 é possível verificar que as 7 imagens são suficientes para realizar a comparação, pois os valores de tempo de execução para cada implementação diferem significativamente entre si. No Apêndice deste trabalho são apresentados de uma maneira mais minuciosa os mesmos resultados obtidos, assim como as imagens utilizadas nos testes. Apesar de o algoritmo em Haskell realizar atualizações nos valores da matriz resultado (a Árvore de Componentes Conectados) e ter estruturação semelhante à estruturação de uma 1 As implementações estão disponíveis em 17

30 5. Experimentos e Resultados 18 Haskell MATLAB Seq. 7,72 ± 14, thread 7,71 ± 13, threads 5,14 ± 9, threads 5,12 ± 9, C++ Seq. 0,74 ± 1,16 Par. 0,25 ± 0,37 Tabela 5.1: Resultados de tempo de execução das implementações em Haskell, C++ e MATLAB, em segundos. O número máximo de threads utilizadas na execução da implementação paralela do código em C++ é o número de linhas da imagem. A implementação em MATLAB apresenta tempo mínimo de execução de duas horas para o algoritmo paralelo. implementação em uma linguagem com paradigma imperativo, a eficiência do código Haskell é bastante inferior à obtida com a implementação em linguagem C++. Como foi apresentado na Seção 4.2, os processos criados pela extensão CH são gerenciados pelo sistema de execução do Haskell, ou seja, são threads em nível de usuário. Uma questão que surge é se o fato de a implementação em C++ usar threads nativas influencia em seu resultado positivo com relação à implementação do CH. Em um experimento realizado em Java por Sung et al. (2002) comparando um mecanismo de threads em nível de usuário com threads nativas, observou-se que o mecanismo de threads em nível de usuário apresenta melhores resultados quanto ao controle e sincronização de threads. Com relação às operações de entrada e saída e trocas de contexto, as threads nativas apresentam melhores resultados. Com isso, é possível que o tipo de mecanismo de threads não tenha favorecido a eficiência do programa em C++, mas não realizamos testes quanto a isso. De qualquer maneira, podemos ver que na comparação das implementações sequenciais, a implementação em C++ já apresenta maior eficiência. Com os resultados apresentados, observamos que a implementação em Haskell além de ter uma eficiência inferior, o speedup S CH = 7,72 5,12 = 1, 51 obtido com a utilização do CH é também inferior ao speedup S C++ = 0,74 0,25 = 2, 96 obtido com a utilização de PThreads da linguagem C++. Isso evidencia que o mecanismo de paralelismo em C++ é mais efetivo que o mecanismo utilizando no CH. De qualquer maneira, neste ponto seria necessário analisar a interferência do uso da estrutura MVector no speedup obtido com CH, análise essa que não realizamos no presente trabalho. Os resultados referentes ao tempo de execução do programa em MATLAB foram aproximados em duas horas, dado que a execução paralela do algoritmo levou um pouco mais de duas horas para terminar. Por conta desta grande ineficiência e por ser inviável a utilização de tal implementação, decidimos por não executar os testes na base toda. É um fato bem conhecido que quando for possível utilizar as funções do próprio MATLAB para evitar o uso de estruturas de repetição como for e while, é preferível fazê-lo, pois desta maneira o desempenho será muito superior [MathWorks (2012)]. Em geral, um programa que usa praticamente só as estruturas de repetição e realiza muitas operações pode se tornar

31 5. Experimentos e Resultados 19 inviável para uso. Para deixá-lo passível de uso, normalmente é necessário trocar o uso de alguns laços de repetição por funções já definidas no MATLAB. A explicação para a baixa eficiência do código implementado em MATLAB é o fato de que o MATLAB não provê muitas funções que possam ser utilizadas neste algoritmo, havendo com isso a necessidade de criação do algoritmo baseando-se quase que totalmente em estruturas de repetição. A implementação em MATLAB é apresentada no Apêndice deste trabalho.

32 Capítulo 6 Conclusões Neste trabalho analisamos o uso da biblioteca Data Parallel Haskell (DPH) e Concurrent Haskell (CH) na implementação de algoritmos de Processamento Digital de Imagens (PDI); mais especificamente o algoritmo não convencional de Matas et al. (2008) para geração de Árvores de Componentes Conectados (CCT). Verificamos a impossibilidade de se utilizar a extensão DPH em seu atual estágio de desenvolvimento no algoritmo de Matas et al. (2008). A principal característica limitadora é a impossibilidade de mesclar código DPH com código não paralelo, ou seja, o compilador não aceita o módulo que contém a implementação paralela importar outros módulos que não podem ser vetorizados pelo compilador. A implementação utilizando CH obtida tem o código estruturado de maneira semelhante à estruturação de um código em uma linguagem de paradigma imperativo. Nesta implementação, foi necessário perder a pureza das funções, dado que o mais apropriado foi utilizar MVector para não haver cópias supérfluas de regiões de memória ocasionadas pelas estruturas persistentes de Haskell. Objetivamos realizar implementações em Haskell que mantivessem a mesma ordem de complexidade de uma implementação em linguagem imperativa, por isso algumas alternativas como a representação da point-tree por meio de uma estrutura de árvore (acesso O(log n)) ao invés da representação por matriz (acesso O(1)), não foram avaliadas neste trabalho. Para comparação de eficiência do código gerado, a implementação do algoritmo de Matas et al. (2008) também foi realizada nas linguagens C++ (utilizando PThreads) e MATLAB (utilizando MATLAB Parallel Computing Toolbox). A utilização do código implementado em MATLAB é, pode-se dizer, inviável, uma vez que o tempo de execução é muitas vezes superior ao tempo de execução dos códigos Haskell e C++. Entre as implementações em Haskell e C++, Haskell apresentou desempenhos cerca de 10 vezes e de 20 vezes inferiores aos desempenhos obtidos com as implementações sequenciais e paralelas, respectivamente, na linguagem C++. Como possível trabalho futuro apontamos o estudo da possibilidade de implementação de 20

33 6. Conclusões 21 funções na API do DPH que permitam a implementação de etapas não paralelizáveis sobre o array paralelo. Para isso será necessário o estudo da implementação da extensão DPH e verificar se isso é possível de ser feito sem impedir o paralelismo automático gerado na etapa de vetorização do compilador.

34 Referências Bibliográficas Abramov, A.; Kulvicius, T.; Wörgötter, F. e Dellen, B. (2010). Facing the multicore-challenge. chapter Real-time image segmentation on a GPU, pp Berger, C. e Géraud, T. (2007). Effective component tree computation with application to pattern recognition in astronomical imaging. In IEEE International Conference on Image Processing, volume 4, pp Berger, C. e Widynsky, N. (2005). Using connected operators to manipulate image components. Technical report, EPITA Research and Development Laboratory. Blelloch, G. E. (1996). Programming parallel algorithms. Communications of the ACM, 39(3): Bräunl, T. (2000). Parallaxis-iii: Architecture-independent data parallel processing. IEEE Transactions on Software Engineering, 26(3): Bräunl, T. (2001). Tutorial in data parallel image processing. Australian Journal of Intelligent Information Processing Systems, 6(3): Chakravarty, M. e Keller, G. (2001). Nepal - Nested Data Parallelism in Haskell. 7th International Euro-Par Conference Manchester on Parallel Processing, pp Chakravarty, M. M. T.; Keller, G.; Lee, S.; McDonell, T. L. e Grover, V. (2011). Accelerating haskell array codes with multicore gpus. In 6th Workshop on Declarative Aspects of Multicore Programming, DAMP 11, pp Chakravarty, M. M. T.; Leshchinskiy, R.; Peyton Jones, S.; Keller, G. e Marlow, S. (2007). Data parallel haskell: a status report. In Workshop on Declarative Aspects of Multicore Programming, DAMP 07, pp DPH (2012). Data Parallel Haskell. Parallel_Haskell. GHC (2012). GHC: The Glasgow Haskell Compiler. GHC. 22

35 Referências Bibliográficas 23 Grozea, C.; Bankovic, Z. e Laskov, P. (2010). Facing the multicore-challenge. chapter FPGA vs. multi-core CPUs vs. GPUs: hands-on experience with a sorting application, pp Jones, S. P., editor (2002). Haskell 98 Language and Libraries: The Revised Report. Jones, S. P.; Leshchinskiy, R.; Keller, G. e Chakravarty, M. M. T. (2008). Harnessing the multicores: Nested data parallelism in haskell. In IARCS Annual Conference on Foundations of Software Technology and Theoretical Computer Science (FSTTCS 2008), volume 2, pp Jones, S. P. e Singh, S. (2009). A tutorial on parallel and concurrent programming in haskell. In Advanced Functional Programming, volume 5832, pp Keller, G.; Chakravarty, M. M. T.; Leshchinskiy, R.; Jones, S. P. e Lippmeier, B. (2010). Regular, shape-polymorphic, parallel arrays in haskell. In ACM SIGPLAN International Conference on Functional Programming, ICFP 10, pp ACM. Keller, R.; Kramer, D. A. e Weiss, J.-P. (2012). Facing the Multicore-Challenge II: Aspects of New Paradigms and Technologies in Parallel Computing. O livro pode ser consultado entrando em contato com: PH/ADP: Langenberg, Robert Johannes. Lippmeier, B. e Keller, G. (2011). Efficient parallel stencil convolution in haskell. In ACM Symposium on Haskell, Haskell 11, pp Marlow, S. (2012). Parallel and concurrent programming in haskell. In Central European Functional Programming School, volume 7241, pp Marlow, S.; Newton, R. e Jones, S. P. (2011). A monad for deterministic parallelism. In 4th ACM Symposium on Haskell, Haskell 11, pp ACM. Matas, P.; Dokládalová, E.; Akil, M.; Grandpierre, T.; Najman, L.; Poupa, M. e Georgiev, V. (2008). Parallel algorithm for concurrent computation of connected component tree. In Advanced Concepts for Intelligent Vision Systems, volume 5259, pp MathWorks (2012). MATLAB: The language of technical computing. com/products/matlab/. Menotti, D.; Najman, L. e Araújo, A. D. A. (2007). 1D Component tree in linear time and space and its application to gray-level image multithresholding. In International Symposium on Mathematical Morphology, volume 1, pp INPE. Najman, L. e Couprie, M. (2006). Building the component tree in quasi-linear time. IEEE Transactions on Image Processing, 15(11):

36 Referências Bibliográficas 24 Pacheco, P. (2011). An Introduction to Parallel Programming. Morgan Kaufmann. Elsevier Science. Perret, B.; Lefevre, S.; Collet, C. e Slezak, E. (2010). Connected component trees for multivariate image processing and applications in astronomy. In 20th International Conference on Pattern Recognition, ICPR 10, pp Peyton Jones, S.; Gordon, A. e Finne, S. (1996). Concurrent haskell. In 23rd ACM SIGPLAN- SIGACT Symposium on Principles of Programming Languages, POPL 96, pp Repa (2012). Numeric Haskell: A Repa Tutorial. Numeric_Haskell:_A_Repa_Tutorial. Salembier, P.; Oliveras, A. e Garrido, L. (1998). Antiextensive connected operators for image and sequence processing. IEEE Transactions on Image Processing, 7(4): Seinstra, F. J. e Koelma, D. (2004). User transparency: a fully sequential programming model for efficient data parallel image processing: Research articles. Concurrency and Computation: Practice and Experience, 16(6): Sung, M.; Kim, S.; Park, S.; Chang, N. e Shin, H. (2002). Comparative performance evaluation of Java threads for embedded applications: Linux Thread vs. Green Thread. Information Processing Letters, 84(4): Wilkinson, M. H. F.; Gao, H.; Hesselink, W. H.; Jonker, J.-E. e Meijster, A. (2008). Concurrent computation of attribute filters on shared memory parallel machines. IEEE Transactions on Pattern Analysis and Machine Intelligence, 30(10):

37 Apêndice API do Data Parallel Haskell Este trabalho foi realizado utilizando a versão da extensão DPH. Atualmente o DPH encontra-se na versão Abaixo apresentamos a API da versão A API da versão sofreu algumas modificações e algumas funções apresentadas neste trabalho não se encontram mais na API. Operações no array paralelo: emptyp : : [ : a : ] singletonp : : a > [ : a : ] replicatep : : Int > a > [ : a : ] lengthp : : [ : a : ] > Int (!:) : : [ : a : ] > Int > a (+:+) : : [ : a : ] > [ : a : ] > [ : a : ] concatp : : [ : [ : a : ] : ] > [ : a : ] mapp : : (a > b) > [ : a : ] > [ :b: ] filterp : : (a > Bool) > [ : a : ] > [ : a : ] combinep : : [ : a : ] > [ : a : ] > [ : Int : ] > [ : a : ] zipp : : [ : a : ] > [ :b: ] > [ : ( a, b) : ] unzipp : : [ : ( a, b) : ] > ( [ : a:], [ :b: ] ) zipwithp : : (a > b > c) > [ : a : ] > [ :b: ] > [ : c : ] bpermutep : : [ : a : ] > [ : Int : ] > [ : a : ] updatep : : [ : a : ] > [ : (Int, a ) : ] > [ : a : ] indexedp : : [ : a : ] > [ : (Int, a ) : ] slicep : : Int > Int > [ : e : ] > [ : e : ] crossmapp : : [ : a : ] > (a > [ :b: ] ) > [ : ( a, b) : ] andp : : [ :Bool: ] > Bool orp : : [ :Bool: ] > Bool minimump, maximump : : Num a => [ : a : ] > a minindexp, maxindexp : : Num a => [ : a : ] > Int sump : : Num a => [ : a : ] > a productp : : Num a => [ : a : ] > a enumfromtop : : Int > Int > [ : Int : ] 25

38 Apêndice 26 Conversões: fromparrayp : : PArray a > [ : a : ] toparrayp : : [ : a : ] > PArray a fromnestedparrayp : : PArray (PArray a) > [ : [ : a : ] : ] Imagens utilizadas para testes Nesta Seção apresentamos uma Tabela com resultados mais específicos referentes aos mesmos testes cujos resultados são apresentados na Tabela 5.1. são mostradas na Figura 1. As imagens utilizadas para teste Na Tabela 1, apresentamos o tempo de execução para cada uma das imagens testadas (10 execuções em cada imagem) e para cada linguagem, também diferenciando as execuções paralelas de execuções sequenciais. Os resultados das implementações em MATLAB não foram apresentados aqui por conta de seu baixo desempenho e de sua inviabilidade de uso. Haskell seq. Haskell 1 Haskell 2 Haskell 4 C++ seq. C++ par. Img. 1 2,32±0,04 2,36±0,05 1,60±0,03 1,60±0,04 0,21±0,06 0,10±0,02 Img. 2 4,03±0,05 4,08±0,04 2,71±0,06 2,70±0,04 0,45±0,13 0,18±0,03 Img. 3 16,01±0,13 15,57±0,46 10,68±1,09 10,46±0,19 1,38±0,21 0,41±0,03 Img. 4 4,43±0,06 4,50±0,09 3,05±0,09 3,00±0,07 0,52±0,11 0,17±0,02 Img. 5 4,38±0,05 4,40±0,05 2,97±0,02 3,08±0,71 0,42±0,12 0,14±0,03 Img. 6 7,05±0,09 7,10±0,05 4,76±0,07 4,78±0,07 0,85±0,08 0,25±0,03 Img. 7 15,83±0,38 15,93±0,29 10,21±0,24 10,19±0,18 1,37±0,46 0,50±0,03 Tabela 1: Resultados mais minuciosos de tempo de execução das implementações em Haskell, C++ e MATLAB, em segundos. Haskell seq. se refere à execução da implementação sequencial em Haskell. Haskell 1, Haskell 2 e Haskell 4 se referem às execuções do algoritmo paralelo em Haskell com uma, duas e quatro threads, respectivamente. C++ seq. e C++ par. se referem ao tempo de execução das implementações sequenciais e paralelas, respectivamente, na linguagem C++.

39 27 Apêndice (Img. 1) Dimensão: (Img. 2) Dimensão: (Img. 3) Dimensão: (Img. 4) Dimensão: (Img. 5) Dimensão: (Img. 6) Dimensão: (Img. 7) Dimensão: Figura 1: Imagens utilizadas para testes e suas dimensões.