Lab. de Programação Concorrente em Física Primeira Prática

Transcrição

1 Lab. de Programação Concorrente em Física Primeira Prática Paulo Matias de agosto de Introdução Nesta prática, avaliaremos a importância de se utilizar bons algoritmos e de otimizar o código antes de começar a paralelizá-lo. 2 Programas Bubble e Quick Compararemos o tempo de execução dos programas que implementam os algoritmos bubble sort e quick sort, com e sem otimizações habilitadas no compilador. Cada medida de tempo é computada como a média dos tempos de execução para pelo menos dez vetores aleatórios diferentes com o mesmo número de elementos. 2.1 Resultados Bubble sort sem otimização Tamanho do vetor Tempo (s)

2 2.1.2 Bubble sort com otimização Tamanho do vetor Tempo (s) Quick sort sem otimização Tamanho do vetor Tempo (s) Quick sort com otimização Tamanho do vetor Tempo (s)

3 2.2 Grácos Quick vs Bubble Sort (sem otimizacao) 35 Quick Bubble Tempo (s) Tamanho do vetor 3

4 Quick vs Bubble Sort (com otimizacao) 7 Quick Bubble 6 5 Tempo (s) Tamanho do vetor 4

5 Efeito da otimizacao no Bubble Sort Tempo (s) Bubble-O Bubble Tamanho do vetor 5

6 Efeito da otimizacao no Bubble Sort 10 1 Tempo (s) Bubble-O Bubble Tamanho do vetor 5 Efeito da otimizacao no Quick Sort 4 3 Tempo (s) Quick-O Quick Tamanho do vetor 1e7 6

7 2.3 Discussão O uso de algoritmos rápidos, de baixa complexidade, é essencial para o desenvolvimento de um programa de alto desempenho. O uso de otimizações oferecidas pelo compilador também é importante, pois permite obter um ganho de performance adicional signicativo. Para a maior entrada fornecida, o quick sort otimizado executou em cerca de 49% do tempo do quick sort não otimizado, ao passo que o bubble sort otimizado executou em apenas 25% do tempo do bubble sort não otimizado. Percebese que os códigos não são afetados da mesma forma pelas otimizações. Uma análise detalhada das otimizações realizadas pelo compilador gcc é apresentada no Apêndice A. O impacto causado pelo uso de um algoritmo de menor complexidade é bem maior que o impacto das otimizações. Para elementos, o quick sort otimizado é cerca de 1524 vezes mais rápido que o bubble sort otimizado. 3 Programa Cavalo Nesta seção, utilizaremos o gprof para identicar as partes do código que tomam mais tempo na execução de um programa. Esse tipo de informação é útil para identicar quais partes do código seriam mais beneciadas por uma otimização, auxiliando o desenvolvedor a melhorar a performance do programa. 7

8 3.1 As três funções/métodos que tomam mais tempo na execução De acordo com a saída do gprof, as três funções/métodos que tomam mais tempo na execução são Tabuleiro::vizinhos, posicionacavalo e Tabuleiro::valida. A porcentagem de tempo gasto em cada uma delas é, respectivamente, de 29.49%, 26.09% e 14.31%. Elas são chamadas , 25 e vezes, respectivamente. 3.2 As três linhas que mais tomam tempo As linhas que mais tomam tempo são a linha 120, que se encontra dentro do método Tabuleiro::vizinhos, a linha 59, que se encontra dentro do método Tabuleiro::valida e a linha 118, novamente no método Tabuleiro::vizinhos. A porcentagem de tempo gasto em cada uma delas é, respectivamente, de 13.00%, 11.62% e 9.59%. 8

9 A Análise das otimizações A.1 Bubble sort sem otimização 9

10 A.2 Bubble sort com otimização 10

11 A.3 Quick sort sem otimização 11

12 A.4 Quick sort com otimização A.5 Discussão O código compilado sem otimização é gerado pelo compilador o mais diretamente possível a partir do código fonte C++, empregando pouco ou nenhum esforço para reduzir o número de instruções utilizadas. Por exemplo, o seguinte trecho do código do bubble sort sem otimização: 12

13 mov eax, [ ebp + var_c ] add eax, 1 shl eax, 2 add eax, [ ebp + arg_0 ] mov edx, [ eax ] Corresponde a apenas uma instrução do código com otimização: mov ebx, [ edx + eax *4+4] sort, onde o seguinte tre- Otimizações similares ocorrem no código do quick cho do código sem otimização: mov eax, [ ebp + var_c ] shl eax, 2 add eax, [ ebp + arg_0 ] Corresponde à seguinte instrução do código com otimização: lea eax, [ esi + edx *4] Outra otimização que ocorre em ambos os códigos é o uso de registradores para algumas das variáveis locais. Por exemplo, no código não otimizado do bubble sort, a variável n é armazenada no local de memória ebp+var_10: mov eax, [ ebp + arg_4 ] ; N sub eax, 1 mov [ ebp + var_10 ], eax Já no código otimizado, a mesma varíavel é armazenada no registrador edi: mov edi, [ ebp + arg_4 ] ; N sub edi, 1 No código não otimizado do quick sort, a variável current é armazenada no local de memória ebp+var_c: add [ ebp + var_c ], 1 mov eax, [ ebp + var_c ] cmp eax, [ ebp + arg_8 ] ; current, fin setl al test al, al jnz short loc_ 80491C9 Enquanto no código otimizado, a mesma variável é armazenada no registrador edx: add edx, 1 add eax, 4 cmp [ ebp + arg_8 ], edx ; fin, current jg short loc_ B0493CF 13

14 Por m, comentamos a respeito de otimizações que foram realizadas sobre o código do bubble sort, mas que não possuem equivalentes no quick sort. O bubble sort utiliza uma função inline denominada swap. Porém, o gcc respeita a diretiva inline apenas se o programa for compilado com a opção -O. Assim, a função swap não é colocada como inline no código do bubble sort sem otimização, apesar de estar especicada como inline no código fonte: mov [ esp +4], edx ; segundo argumento mov [ esp ], eax ; primeiro argumento call _ Z4swapRiS_ ; swap ( int &, int &) Outra otimização que ocorre no mesmo trecho do código do bubble sort é o reaproveitamento dos valores e endereços para a realização da troca swap(v[i],v[i+1]) depois da comparação v[i+1]<v[i]. Enquanto no código sem otimização temos o seguinte trecho: mov eax, [ ebp + var_c ] add eax, 1 shl eax, 2 add eax, [ ebp + arg_0 ] mov edx, [ eax ] mov eax, [ ebp + var_c ] shl eax, 2 add eax, [ ebp + arg_0 ] mov eax, [ eax ] cmp edx, eax jge short loc_80491ef ;!( v[i +1] < v[i ]) mov eax, [ ebp + var_c ] add eax, 1 shl eax, 2 mov edx, eax add edx, [ ebp + arg_0 ] mov eax, [ ebp + var_c ] shl eax, 2 add eax, [ ebp + arg_0 ] mov [ esp +4], edx ; primeiro argumento mov [ esp ], eax ; segundo argumento call _ Z4swapRiS_ ; swap ( int &, int &) O código com otimização corresponde apenas ao seguinte trecho, onde os valores ebx e ecx e os endereços edx+eax*4 e edx+eax*4+4 são reaproveitados: mov ebx, [ edx + eax *4+4] mov ecx, [ edx + eax *4] cmp ebx, ecx jge short loc_80493df ;!( v[i +1] < v[i ]) mov [ edx + eax *4], ebx mov [ edx + eax *4+4], ecx 14

15 Essas duas últimas otimizações são em grande parte responsáveis pelo fato de o bubble sort ter sofrido um impacto maior da otimização do compilador que o quick sort. A.6 Curiosidades O compilador não é perfeito e, às vezes, gera códigos estranhos mesmo com a otimização habilitada. No código do bubble sort com otimização, a variável swapped é armazenada no local de memória ebp+var_d. A linha de código fonte swapped=true; é compilada da seguinte forma: movzx ecx, [ ebp + var_e ] mov [ ebp + var_d ], cl O local de memória ebp+var_e só é usado uma única outra vez no código, logo no início da função: mov [ ebp + var_e ], 1 Ou seja, as três instruções acima estão servindo apenas ao próposito de mover o byte 1 para a posição de memória ebp+var_d. Em vez de utilizar essas três instruções, uma única instrução bastaria: mov [ ebp + var_d ], 1 O código Assembly foi modicado desta forma e testado, e continuou funcionando corretamente. 15