CAD Trabalho III. PThreads e OpenMP. Pedro Carvalho de Oliveira Rui André Ponte Costa

Transcrição

1 Universidade de Coimbra Faculdade de Ciências e Tecnologia Departamento de Engenharia Informática CAD Trabalho III PThreads e OpenMP Pedro Carvalho de Oliveira Rui André Ponte Costa Maio 2008

2 Resumo Neste trabalho, à semelhança do anterior, foram desenvolvidas várias soluções para a implementação de um servidor multi-tarefa. Esse servidor contem uma base de dados que é consultada/alterada por uma aplicação cliente, sendo os pedidos de consulta e alteração ordenados. O servidor tem assim de garantir a máxima eficiência no processamento dos pedidos, ao mesmo tempo garantindo a correcta ordem de execução dos mesmos. A grande diferença em relação ao trabalho anterior consiste na introdução de um novo comando, ordenamento, e na mudança de linguagem e paradigmas de programação. Neste trabalho é proposto desenvolver as nossas soluções em C/C++, utilizando as livrarias PThreads e OpenMP. Na secção 1 é feito um estudo da aplicação com vista a identificar pontos de melhoramento, sendo a secção 2 reservada á explicação das várias soluções implementadas. A secção 3 contém os testes efectuados, concluindo a secção 4 com algumas considerações finais. I

3 Conteúdos 1. Estudo da Aplicação Implementações Unithread PThreads OpenMP PThreads+OpenMP Testes Descrição dos testes Resultados Conclusões Conclusão... 6 Referências... 6 II

4 1. Estudo da Aplicação Numa primeira fase decidimos estudar o desempenho do servidor base fornecido pelo professor. Após vários testes detecta-mos valores de desempenho estranhos que variavam independentemente das execuções. Com os inputs mais exigentes fornecidos (Input 2 e 4) o tempo de execução variava drasticamente entre execuções, tendo por vezes valores muito baixos (cerca 1/2 segundos) para depois atingir valores muito elevados (na ordem das centenas de segundos). Após algum debug, chegamos à conclusão que esse facto era dependente do valor inserido como número máximo de ligações pendentes no socket do servidor. Ao alterar esse valor para um número igual ou superior ao número de pedidos pelo cliente o problema ficou resolvido. De seguida, efectua-mos um profiling do servidor para verificar quais as zonas do processamento onde deveríamos de apostar (Imagem 1). Imagem 1. Profiling, utilizando o gprof, do servidor fornecido pelo professor com o input 4. Como se pode concluir, uma grande parte do tempo é gasta nas instruções de ordenamento (função compare). Para nossa surpresa, a escrita da base de dados no disco (função save_array) parece não possuir tanta complexidade quanto a existente na versão em Java. No entanto, à semelhança do trabalho anterior, decidimos criar uma thread específica para esta função. 2. Implementações De seguida são apresentadas as 4 soluções encontradas para este problema. Procuramos encontrar soluções conceptualmente diferentes do trabalho anterior, devido à mudança de paradigma e aos resultados pouco motivadores atingidos anteriormente. 1

5 2.1. Unithread Esta versão é idêntica à versão Unithread implementada no trabalho anterior. Como o próprio nome indica, utiliza apenas uma thread para efectuar todo o trabalho no servidor, garantindo a ordem de execução através de uma PriorityQueue que vai sendo ocupada com os pedidos enviados pelos clientes. Existe uma variável que define o número do próximo pedido a ser executado, sendo esse pedido executado quando estiver na cabeça da PriorityQueue PThreads Baseado na versão Unithread, foi criada esta versão multithread utilizando PThreads. Utilizando o mesmo mecanismo de prioritização dos pedidos, é lançada uma thread para cada pedido que esteja em condições de ser processado (ou seja, que esteja em ordem). Para bloqueio da base de dados foi implementado um sistema de bloqueios parciais. Para cada pedido é detectado as gamas de execução, sendo criado uma lista em memória com as gamas actualmente a serem ocupadas por outros pedidos que estejam a executar. Quando uma thread deseja processar, primeiro verifica essa lista para verificar se existe outro pedido que esteja actualmente a trabalhar na mesma zona de memória que a sua. Devido à diferença entre tipos de pedidos, a permissão para processar baseia-se em regras distintas (Tabela 1). Tipo de Pedido Leitura (Max, Min, Avg) Sort Change sem realocação Change com realocação Pode efectuar se: A sua gama está livre A sua gama está ocupada, mas por outras leituras Não existe nenhum change a realocar memória A sua gama está livre Não existe nenhum change a realocar memória A sua gama está livre Não existe nenhum change a realocar memória Nenhum pedido está a ser executado Tabela 2. Regras de permissão do servidor. A identificação de change com/sem realocação é feita tendo em conta a gama de alteração do change e o tamanho actual da tabela (se gama ultrapassa, vai ser necessário fazer realocação) OpenMP Nesta versão utilizámos as funcionalidades disponibilizadas pelo OpenMP, de modo a paralelizar-mos os cálculos efectuados pelo servidor. Os cálculos que paralelizados foram os seguintes: mínimo, máximo, média e ordenamento. Para os três primeiros foram feitos testes nos quais o OpenMP se demonstrava ligeiramente mais eficaz, no entanto isto só se verificou para grandes dimensões (> ). Assim, forçamos com que a parelização recorrendo ao OMP só acontece-se acima de um certo valor, sendo esse valor 2

6 definido como para as funções max, min e avg, e para a função de ordenamento. Foi utilizada uma implementação paralelizada do quick sort que se encontra livremente disponível [1]. À implementação existente foi ainda adicionado o insertion sort para ser usado quando o quick sort atinge dimensões reduzidas (<= 30). Após vários testes concluímos como sendo o valor de intervalo 30 o ideal para a utilização do insertion sort dentro do quick sort. Foi possível obter uma melhoria no desempenho de cerca de 3 segundos no ordenamento de um array aleatório de elementos. É ainda de salientar que pesquisámos por vários algoritmos de ordenamento especialmente criados para uma abordagem paralela. Um deles encontra-se descrito em [2], onde obtiveram os melhores resultados até hoje para benchmarks vulgarmente usados na área, com dois cores e uma arquitectura de memória partilhada. Foi usado o algoritmo Odd-Even Mergesort que é uma variação do Merge sort e foi usado OpenMP. Enviamos um a pedir a implementação, mas não obtivemos resposta em tempo útil. Outro algoritmo muito usado na área é o Parallel Sorting by Regular Sampling [3], que é o algoritmo que até hoje obtém melhores resultados para mais do que dois cores. Em [4] encontram-se alguns testes efectuados com o código disponibilizado no repositório de código OpenMP, bem como a identificação das principais deficiências do OpenMP no que toca a paralelização de algoritmos de ordenamento. Apesar disto, como comprovam os nossos testes, o OMP torna-se vantajoso, mesmo usando o quicksort PThreads+OpenMP Esta versão reúne a versão PThreads e a OpenMP numa só. Tal como nas implementações base, o processamento de pedidos é efectuado utilizando Pthreads, sendo o processamento dos cálculos efectuado utilizando OpenMP. Após alguns testes, deparamo-nos com problemas que nos foram impossíveis de resolver. Esses problemas ocorriam da utilização simultânea dos dois paradigmas. Após mais alguns testes, concluímos que para casos onde a utilização simultânea fosse simples (ou seja, não existisse grande sincronização de threads) os dois paradigmas funcionavam bem em conjunto. Quando se aumentava a complexidade de sincronização, como é o caso do servidor PThreads, ocorriam erros de corrupção de memória provenientes da livraria de Pthreads. Visto que o próprio OpenMP utiliza Pthreads internamente, estamos em crer que existe algum bug de sincronização na estrutura do mesmo, que corrompe a memória das threads. Sendo assim, este servidor não foi utilizado nos testes a seguir descritos. 3. Testes De seguida são apresentados os testes efectuados às implementações anteriormente descritas, juntamente com as respectivas conclusões. Todos os testes foram executados numa máquina com processador Intel Core Duo T5500 de 1.66GHz, com 2GB de memória disponível. A máquina virtual JAVA da 3

7 aplicação cliente foi lançada com 512MB de memória, devido á dureza em termos de input de alguns testes Descrição dos testes Para testar as nossas soluções cria-mos vários inputs de teste com vista a testar as várias situações que podem acontecer num servidor deste tipo. De seguida é apresentada uma descrição sumária de cada um. 1. Input nº1 fornecido pelo professor. 2. Input nº2 fornecido pelo professor. Bastantes leituras e algumas escritas. 3. Input nº3 fornecido pelo professor. Várias escritas. 4. Input nº4 fornecido pelo professor. Várias escritas, leituras e ordenamentos. 5. Três escritas ao inicio, seguido de 250 leituras aleatórias. 6. Cerca de 100 escritas e 100 ordenamentos, intercalados irregularmente com 20 leituras. 7. Igual ao teste nº4, mas com o cliente alterado de maneira a que os pedidos sejam lançados por ordem inversa (ou seja, o cliente primeiro lança o pedido com o número de ordem 39) 3.2. Resultados De seguida são apresentados os resultados temporais da execução das várias implementações para os vários testes. Os valores apresentados são a média de 30 execuções, em milésimos de segundo (ms). Input\Imp. Unithread Pthreads OpenMP Input 1 1,8 13,2 1,6 Input ,1 1351, Input 3 216,8 244,2 225,6 Input ,3 3252,4 1879,3 Input ,9 2814,8 Input , , ,7 Input ,2 5363,8 5267,8 Tabela 2. Resultados temporais (ms). 4

8 Imagem 2. Gráfico de resultados temporais (ms) Conclusões A primeira conclusão a retirar destes testes, em relação ao trabalho anterior, é os tempos de execução serem bastante inferiores. Com a versão Unithread, utilizando o Input 3, os tempos de execução foram de 216ms, tendo a versão em Java cerca de 1612ms. Esta diferença não se deve a optimizações do servidor, mas sim em relação à linguagem C que demonstra ser muito mais rápida no processamento. As versões multithread obtiveram resultados mais satisfatórios do que no trabalho anterior. Essa melhoria é mais evidente quando a carga do servidor com sorts e changes é elevada (Input 6). Curiosamente, os resultados das Pthreads e do OpenMP foram muito idênticos neste teste, mesmo sendo o seu funcionamento interno totalmente diferente. Por essa razão, estamos em crer que caso o servidor Pthreads+OpenMP funcionasse, teríamos obtido resultados ainda melhores, aproveitando a complementaridade das duas soluções. O Input 4 e 6 obtiveram algumas melhorias utilizando a versão OpenMP. Visto que essa melhoria não ocorreu no Input 2, que é muito idêntica a ambos mas sem os sorts, podemos concluir que essa melhoria advém da paralelização do ordenamento. Com o input 5, ao contrário do trabalho anterior, não houve melhoramentos de execução. Esse facto deve-se a solução do trabalho anterior estar muito optimizada para o processamento de leituras, aproveitando o excelente mecanismo de ReadWriteLocks do Java. Apesar dos resultados de paralelização deste trabalho serem melhores que no anterior, esses melhoramentos ocorreram principalmente nos inputs que utilizam uma função não utilizada anteriormente (sort). Nos inputs utilizados em ambos os trabalhos (Input 1, 2 e 3) os resultados em relação à versão Unithread foram idênticos. Com tudo isto podemos concluir, novamente, que este problema é de difícil paralelização. Com a adição do comando sort os resultados já melhoram em relação à versão Unithread, principalmente se a quantidade de sorts for elevada. A necessidade de 5

9 garantir uma ordem que não a de chegada demonstrou novamente ser muito difícil de paralelizar processamento. Tendo em conta os testes efectuados, podemos concluir que a melhor solução foi a versão com OpenMP. Tal como provado em [5], o OpenMP além de garantir resultados bastantes bons, está muito optimizado para as funcionalidades para as quais foi desenhado, sendo muito mais fácil de programar e depurar. No código anexo a este relatório seguem as 4 versões implementadas, incluindo a versão PThreads+OpenMP. 4. Conclusão Este trabalho permitiu-nos utilizar as principais capacidades das PThreads e do OpenMP. Durante a sua execução, tivemos de testar várias abordagens utilizando esses paradigmas, tendo feito uma pesquisa intensiva sobre a sua utilização neste problema concreto. Tal como no trabalho anterior, este problema permitiu-nos explorar um problema de difícil paralelização. Consciencializou-nos para o facto de nem todos os problemas serem de trivial paralelização, tendo sempre de se estudar bem os prós e contras de uma solução paralela antes de partir para a sua aplicação no mundo real. Referências [1] compunity, The Community of OpenMP users, researchers, tool developers and providers, [2] E. Herruzo et al., A New Parallel Sorting Algorithm based on Odd-Even Mergesort, Proceedings of the 15th Euromicro International Conference on Parallel, Distributed and Network-Based Processing, 2007, pp [3] H. Shi and J. Schaeffer, Parallel sorting by regular sampling, Journal of Parallel and Distributed Computing, vol. 14, 1992, pp [4] M. Suß and C. Leopold, A User s Experience with Parallel Sorting and OpenMP, Proceedings of the Sixth Workshop on OpenMP (EWOMP 04), October, [5] B. Kuhn, P. Petersen, and E. O Toole, OpenMP versus Threading in C/C+, Concurrency: Pract. Exper, vol. 12, 2000, pp