Universidade de São Paulo - USP. Instituto de Física de São Carlos - IFSC. Programação de Alto Desempenho. Prática 1. André de Freitas Smaira

Transcrição

1 Universidade de São Paulo - USP Instituto de Física de São Carlos - IFSC Programação de Alto Desempenho Prática 1 Aluno: André de Freitas Smaira

2 1 Otimização pelo Compilador Atualmente, os compiladores tem otimização própria, ajudando os programadores a melhorar consideravelmente o tempo de execução e o gasto de memória de seus programas sem se preocuparem, necessariamente, muito com isso. O compilador utilizado nesse curso (g++) tem várias opções de otimização [1], sendo que a mais simples delas é a opção -O, em que o compilador tenta reduzir o tamanho e o tempo de execução do programa sem utilizar nenhuma otimização que faça com que a compilação demore muito mais que o normal. Abaixo estão as linhas de comando que compilam o arquivo prog.cpp no programa prog sem e com otimização respectivamente: g++ prog.cpp -o prog g++ -O prog.cpp -o prog Os objetivos dessa primeira parte da prática são: Complexidade de Algoritmos: Mostrar a diferença de desempenho entre algoritmos de complexidades diferentes, exemplicados aqui pelos algoritmos de ordenação conhecidos como Bubble Sort, que está entre os algoritmos de mais fácil compreensão mas de maior tempo de execução, com complexidade O (n 2 ) no pior caso e no caso médio e O (n) no melhor caso, e Quicksort, que é mais difícil de se compreender, mas é o algoritmo de ordenação de menor tempo de execução possível para o caso médio e o melhor caso, com complexidade O (n log n), apesar de o pior caso ter complexidade O (n 2 ). Existem algoritmos de ordenação em que a complexidade de todos os casos são Θ (n log n), mas esse não é o objetivo desse trabalho. Otimização de Algoritmos: Mostrar a diferença de desempenho entre dois executáveis provenientes de um mesmo algoritmo diferenciados pela presença ou ausência da otimização explicada acima. Aqui serão comparados em relação ao tempo de execução cada um dos algoritmos com e sem a otimização. Apesar do gasto de memória também ser otimizado por essa opção, esse não é o objetivo desse trabalho. 1

3 Antes de começarmos, vale explicitar que a sessão 3 exibe as congurações do computador utilizado na execução desse trabalho, em que durante a execução dos programas nada mais era executado pelo usuário do computador e que cada programa foi executado para 15 vetores, ou, em termos das variáveis do programa, M = 15. Vamos iniciar nosso estudo comparando os tempos de execução dos dois algoritmos tratados sem a utilização da otimização descrita (gura 1). No primeiro gráco, percebemos claramente a melhor eciência do Quicksort em relação ao Bubble sort, sendo que a razão entre os tempos de execução do primeiro e do segundo, ou seja, a razão entre as velocidades de execução dos dois algoritmos para o maior valor de N é r = T BS T QS = v QS v BS = 2509,6623. Podemos agora fazer algumas contas para comprovar a complexidade teórica desses algoritmos: T BS = α BS n 2 e T QS = α QS n log n. Se igualarmos a razão entre essas duas expressões à razão obtida no gráco, obtemos n = , que é aproximadamente igual aos elementos reais no programa, o que mostra claramente que a complexidade de um programa para altos valores de N indica muito bem como esse programa se comporta em relação a outros. Essa diferença de 1% é referente a aproximações nas contas e à inclusão dos pontos de menores valores de N na determinação dos parâmetros do ajuste dos grácos. Figura 1: Comparação entre os tempos de execução dos algoritmos de ordenação Bubble sort e Quicksort sem otimização. Sendo T BS = (8, ) n 2 e T QS = (3, ) n log n. O primeiro gráco é exibido na escala linear e segundo na escala logarítmica 2

4 Analisando agora o gráco em escala logarítmica e deixando claro que o ajuste foi feito para todos os dados obtidos pelo programa (o que justica 3 dos 5 pontos do gráco estarem acima da curva), podemos adicionar que esses pontos fora da curva mostram que para pequenos valores de N (até 10000), o Quicksort, apesar de ainda ser cerca de 15 vezes mais rápido que o Bubble sort, tem eciência menor que o ajuste dos pontos para N bem maiores. Isso vai car claro, quando o gráco que exibe todos os pontos for utilizado para a demonstração da otimização. Esse é o comportamento normal da Quicksort para poucos elementos e, por isso, as implementações utilizadas para o Quicksort costumam utilizar outros métodos de ordenação, como o Insertion sort, que para pequenos vetores passa a ser mais eciente que o Quicksort. Mesmo o Bubble sort se torna mais eciente que o Quicksort para pequenos valores de N. Executando novamente os algoritmos para valores de N menores que 20, podemos encontrar o limite para o qual isso passa a ocorrer: N lim 8 (gura 2). Figura 2: Demonstração de que para certos valores de N, a eciência do Quicksort é menor até que o Bubble sort. Para essa experiência foram utilizados 1 N 19 e M = Podemos agora estudar como a otimização inuencia cada um dos métodos separadamente. Primeiro vamos ver na gura 3 essa inuência em relação ao algoritmo Bubble sort. Pelo resultado do programa e pelo gráco, podemos obter uma melhora média de desempenho do Bubble sort de 4,7 vezes. Além disso, percebemos no segundo gráco que a otimização desse algoritmo faz com que ele se torne mais eciente que a curva de ajuste do restante dos pontos para pequenos valores de N, em que a otimização o torna 5,8 vezes mais rápido. Podemos agora fazer o mesmo para o algoritmo de Quicksort, cuja comparação é indicada 3

5 Figura 3: Comparação entre o algoritmo Bubble sort otimizado e não otimizado. Sendo T n opt = (8, ) n 2 e T opt = (1, ) n 2. O primeiro gráco é exibido na escala linear e segundo na escala logarítmica na gura 4. Pelo resultado do programa e pelo gráco, podemos obter uma melhora média de desempenho do Quicksort de 3,7 vezes. Além disso, percebemos no segundo gráco que a otimização desse algoritmo faz com que ele se torne menos eciente que a curva de ajuste do restante dos pontos para pequenos valores de N, em que a otimização o torna 2,9 vezes mais rápido. Para essas duas últimas comparações, percebemos que o Bubble sort é melhor otimizado que o Quicksort. Isso ocorre pois o Quicksort está mais próximo do limite de desempenho para um algoritmo de ordenação, O (n log n), fazendo com que que mais difícil a melhora de desempenho através de qualquer tipo de otimização. Mesmo no Quicksort há uma melhora signicativa (de meia ordem de grandeza), mostrando a importância da otimização, mesmo que simples, como a otimização padrão do compilador, para um programa que se deseja rodar mais ecientemente. Passemos agora para a mesma comparação inicial (entre os dois algoritmos), mas para as versões otimizadas (gura 5). No primeiro gráco, novamente, percebemos a melhor eciência do Quicksort em relação ao Bubble sort, sendo que a razão entre os tempos de execução do primeiro e do segundo para o maior valor de N é r = T BS T QS 4 = v QS v BS = 1985,2863. Essa diminuição

6 Figura 4: Comparação entre o algoritmo Quicksort otimizado e não otimizado. Sendo T n opt = (3, ) n log n e T opt = (8, ) log n. O primeiro gráco é exibido na escala linear e segundo na escala logarítmica de eciência relativa se deve ao que já foi discutido sobre ser mais complicado otimizar um algoritmo que já esteja próximo do limiar de eciência, como é o caso do Quicksort. Figura 5: Comparação entre os tempos de execução dos algoritmos de ordenação Bubble sort e Quicksort com otimização. Sendo T BS = (1, ) n 2 e T QS = (8, ) n log n. O primeiro gráco é exibido na escala linear e segundo na escala logarítmica 5

7 Como na primeira vez, vamos analisar o gráco em escala logarítmica. Como já explicado, o Bubble sort se torna mais eciente que o Quicksort para pequenos valores de N. Podemos ver melhor essa tendência nesse gráo, já que a otimização aproxima essas duas curvas mais do que o normal nessa região. Executando novamente os algoritmos para valores de N menores que 20, podemos encontrar o limite para o qual isso passa a ocorrer: N lim 10,5 (gura 6). Podemos perceber que para o algoritmo otimizado, esse cruzamento ocorre para N lim um pouco maior, já que a otimização aproxima a eciência dos dois algoritmos para pequenos valores de N. Figura 6: Demonstração de que para certos valores de N, a eciência do Quicksort é menor até que o Bubble sort e que no caso otimizado esse valor de N é maior que no caso normal. Para essa experiência foram utilizados 1 N 19 e M = Finalmente podemos chegar à conclusão de que para altos valores de N, a complexidade de um algoritmo inuencia muito mais na eciência de um programa que uma possível otimização. Portanto, quanto quisermos um programa eciente, antes de tudo devemos pensar muito bem em como vamos tratar o problema para que a complexidade seja a menor possível e só depois procurar possíveis otimizações (caso seja necessário). Para pequenos valores de N (ordem de unidades), no entanto, podemos nos preocupar mais com otimizações, pois as complexidades não inuenciarão mais que um fator de algumas unidades. 2 Proles O termo inglês proling se refere a uma forma de análise de software dinâmica capaz de determinar o quanto de recurso computacional é consumido por cada parte do código [2], com 6

8 o objetivo de facilitar a otimização do programa por parte do programador. O objetivo dessa segunda parte da prática é justamente esse: analisar o consumo de recursos de um determinado programa. Para isso usaremos o aplicativo gprof da GNU. O programa que utilizaremos tem por objetivo calcular as trajetórias de um cavalo de jogo de xadrez em um tabuleiro quadrado, o que é uma tarefa bem custosa. Primeiro temos que compilar o programa com informações de depuração: g++ -g -pg cavalo1.cpp -o cavalo Em seguida, executamos o programa com seus três argumentos:./cavalo sendo estes, respectivamente, o tamanho do tabuleiro, a autorização de exibição das soluções possíveis e a profundidade do cálculo executado e das mensagens mostradas. Depois, basta-nos utilizar o gprof. Vamos fazer essa análise separando o programa de duas formas diferentes: por função e por linha. Para cada um deles, serão estudados os três maiores gastos de recursos. As duas linhas abaixo mostram as chamadas do gprof para os dois objetivos anteriores na ordem em que foram citados: gprof cavalo gprof -l cavalo Por função A tabela abaixo mostra quais as funções que mais tomam tempo, qual é esse tempo, qual a porcentagem desse tempo em relação ao total do programa e qual o número de vezes que cada uma delas é chamada. 7

9 Função Tempo (s) Porcentagem Número de Chamadas vizinhos(casa, Casa*, int&) const 4,32 32, Casa(int, int) 3,28 24, posicionacavalo(tabuleiro&, Casa, int) 1,65 12,56 25 Para resumir a tabela, em seguida é dito a que classe pertence cada função. Em negrito estão indicadas as classes e em seguida estão listados os componentes da mesma. Tabuleiro: vizinhos() Tabuleiro::Casa: Casa() Observamos na tabela que a terceira função, apesar de ter um percentual de consumo de tempo da mesma ordem de grandeza das outras, é chamada um número de vezes 7 ( sete) ordens de grandeza menor que a segunda. Isso indica que para ter um ganho de desempenho deste programa em relação a essas 3 funções deve-se diminuir o número de chamadas das duas primeiras ou diminuir a complexidade da terceira, já que dessas três a que gasta mais tempo por chamada à função é a terceira com 66,02ms/chamada contra um tempo desprezível por chamada das outras duas. Essa complexidade é relativamente tão alta pois essa é a função principal do programa, executando todos os possíveis movimentos dos cavalos, além de ser recursiva, o que acarreta em um aumento considerável de tempo de execução. As outras são apenas função auxiliar (vizinhos) e função construtora de uma classe auxiliar (Casa), que são inclusive chamadas inúmeras vezes dentro da própria posicionacavalo. Uma possibilidade de diminuição de tempo de execução para essa função é torná-la iterativa, já que toda função recursiva pode ser transformada em uma função iterativa. O problema dessa implementação é a diculdade. Geralmente a implementação recursiva de uma função é muito mais fácil de se entender e de se implementar que uma equivalente no formato iterativo. Por linha Analogamente à analise por funções, abaixo é mostrada a tabela indicando a linha, o tempo total de execução e a porcentagem em relação ao tempo total de execução do programa. Em 8

10 seguida vamos analisar cada uma delas. Linha Tempo (s) Porcentagem 24 2,76 21, ,55 19, ,23 9,33 Agora vamos analisar cada uma dessas linhas: 24: // Abaixo: classe auxiliar para representar os indicies de uma casa. class Casa { public: Casa(int const a=0, int const b=0) : i(a), j(b) {} int i, j; }; A linha 24 é a : i(a), j(b) {} Ela tem tanto gasto de tempo pois está dentro da função construtora da classe Casa, que como já visto na análise por função é a função que segundo gasta mais tempo e a função que é chamada mais vezes no programa. A função que gasta mais tempo tem muito mais linhas que esta. Por isto é que, apesar de a função ser a segunda função que mais gasta, tem a linha que mais gasta em seu interior. 119 e 121: // Metodo para calcular as vizinhas de uma casa dada no tabuleiro // Devolve apenas as vizinhas validas. 9

11 // Vizinhas sao as casas que podem ser alcancadas por um pulo de // cavalo da casa de partida. void Tabuleiro::vizinhos(Casa const c, Casa v[], int &M) const { // Array padrao guarda as posicoes relativas de todos os vizinhos static int padrao[maxviz][2] = { { -1, -2}, { -1, 2}, { 1, -2}, { 1, 2}, { -2, -1}, { -2, 1}, { 2, -1}, { 2, 1} }; Casa vizinha; M = 0; for (int i = 0; i < MAXVIZ; i++) { // Calcula vizinho de acordo com padrao vizinha = Casa(c.i + padrao[i][0], c.j + padrao[i][1]); // Se casa valida, aceita. Senao o proximo escreve sobre este. if (valida(vizinha)) { v[m] = vizinha; M++; } } } As linhas abaixo indicam as linhas descritas na tabela: vizinha = Casa(c.i + padrao[i][0], c.j + padrao[i][1]); if (valida(vizinha)) { v[m] = vizinha; M++; } Além de essas duas linhas estarem dentro da função que mais gasta tempo, elas estão dentro de um for de 8 elementos, o que faz elas serem acessadas 8 vezes dentro de cada chamada à função. A linha 119 gasta mais tempo pois a chamada à função Casa() gasta mais tempo que a chamada à função valida(), além de a primeira ter que fazer várias 10

12 contas para obter os parâmetros que serão enviados à função Casa(). 3 Especicações do Computador Para essa prática, foi utilizado um notebook da marca Toshiba com o sistema operacional Ubuntu 12.04, com as seguintes congurações: Processador Memória RAM Intel R Core TM i5-2410m CPU 2,30Ghz 2,30Ghz 6,00 GB 11

13 Referências [1] Optimize Options - Using the GNU Compiler Collection (GCC) Disponível em: Acessado em: 02/08/2012 [2] Gprof - Wikipedia Disponível em: Acessado em: 03/08/2012 [3] Proling (computer programming) - Wikipedia Disponível em: Acessado em: 03/08/