Dissertacao Joao Albuquerque

Published on January 2017 | Categories: Documents | Downloads: 34 | Comments: 0 | Views: 290
of 117
Download PDF   Embed   Report

Comments

Content

˜ JOAO CLAUDIO MUSSI DE ALBUQUERQUE

´ ANALISE DO COMPORTAMENTO DA HIERARQUIA DE ´ MEMORIA COM OPROFILE ESTENDIDO

Disserta¸˜o apresentada como requisito parca cial ` obten¸˜o do grau de Mestre. Proa ca grama de P´s-Gradua¸˜o em Inform´tica, o ca a Setor de Ciˆncias Exatas, Universidade Fee deral do Paran´. a Orientador: Prof. Dr. Roberto Andr´ Hexsel e

CURITIBA 2009

˜ JOAO CLAUDIO MUSSI DE ALBUQUERQUE

´ ANALISE DO COMPORTAMENTO DA HIERARQUIA DE ´ MEMORIA COM OPROFILE ESTENDIDO

Disserta¸˜o apresentada como requisito parca cial ` obten¸˜o do grau de Mestre. Proa ca grama de P´s-Gradua¸˜o em Inform´tica, o ca a Setor de Ciˆncias Exatas, Universidade Fee deral do Paran´. a Orientador: Prof. Dr. Roberto Andr´ Hexsel e

CURITIBA 2009

i

´ DEDICATORIA
` ` A minha av´, Palmira. Aos meus pais, Jo˜o Liro e Maria Ana. A minha sobrinha e o a ` afilhada, Valentina. Aos meus irm˜os Humberto Luis e Paulo Henrique. A minha irm˜ a a Ana Maria. Aos demais familiares que tamb´m n˜o ler˜o esta disserta¸˜o. A qualquer e a a ca pessoa que justifique a existˆncia deste trabalho, lendo-o. e

ii

AGRADECIMENTOS
Aos meus familiares, pela paciˆncia e apoio incondicionais. Aos grandes amigos, amigas e e demais pessoas especiais, pela torcida e compreens˜o durante a minha ausˆncia: Aristeu, a e Daniel, Cassio, Bruno, Ike, Rapha, Betam, Enrico, Tati, Nissin, Carlos, Anna, Maur´ ıcio, Maria, Felipe, Kika, Jepi, Z´ e, especialmente ` Mell, a auxiliar de encaderna¸˜o. e a ca Ao meu orientador Roberto, principalmente pela paciˆncia e pela f´ no meu trabalho. e e ` A Juc´lia, secret´ria do DINF, pela prestatividade. Aos amigos e colegas do SIMEPAR e a pela compreens˜o e apoio, Sato em especial. Aos doutores Marcelo Oliveira, Erasto Cichon a e Julio Batista, pela minha segunda chance. A vocˆ, pelo seu interesse e aten¸˜o. e ca

iii

´ SUMARIO

LISTA DE FIGURAS LISTA DE TABELAS RESUMO ABSTRACT 1 INTRODUCAO ¸˜ ˜ ´ 2 REVISAO BIBLIOGRAFICA 2.1 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii viii ix x 1 5 5

2.2 OProfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 OPROFILE ESTENDIDO 15

3.1 Altera¸˜es na coleta dos dados . . . . . . . . . . . . . . . . . . . . . . . . . 15 co 3.2 P´s-processamento e an´lise das amostras . . . . . . . . . . . . . . . . . . 16 o a 4 METODOLOGIA 5 AMBIENTE DE TESTES ´ 6 ANALISE DAS FALTAS NAS TLBS 20 25 27

6.1 Descri¸˜o do programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ca 6.2 Prepara¸˜o do Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 27 ca 6.2.1 6.2.2 Parˆmetros dos Programas . . . . . . . . . . . . . . . . . . . . . . . 28 a Configura¸˜o do OProfile Estendido . . . . . . . . . . . . . . . . . . 29 ca

6.3 Resultados dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3.1 6.3.2 Buffer de 0 a 349 p´ginas . . . . . . . . . . . . . . . . . . . . . . . . 29 a Buffer de 22 a 42 P´ginas . . . . . . . . . . . . . . . . . . . . . . . 32 a

iv 6.3.3 Buffer de 250 a 280 P´ginas . . . . . . . . . . . . . . . . . . . . . . 34 a 38

´ 7 ANALISE DA MULTIPLICACAO DE MATRIZES ¸˜

7.1 Estudo das Otimiza¸˜es Testadas . . . . . . . . . . . . . . . . . . . . . . . 39 co 7.1.1 7.1.2 7.1.3 7.1.4 Multiplica¸˜o Convencional . . . . . . . . . . . . . . . . . . . . . . 39 ca Multiplica¸˜o com Padding . . . . . . . . . . . . . . . . . . . . . . 41 ca Multiplica¸˜o com Blocagem . . . . . . . . . . . . . . . . . . . . . . 42 ca Multiplica¸˜o com Padding e Blocagem . . . . . . . . . . . . . . . . 42 ca

7.2 Prepara¸˜o do Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 43 ca 7.2.1 7.2.2 Parˆmetros dos Programas . . . . . . . . . . . . . . . . . . . . . . . 43 a Configura¸˜es do OProfile Estendido . . . . . . . . . . . . . . . . . 46 co

7.3 Resultados dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.3.1 7.3.2 7.3.3 7.3.4 Comportamento dos Programas . . . . . . . . . . . . . . . . . . . . 47 Contagem dos Eventos . . . . . . . . . . . . . . . . . . . . . . . . . 48 Utiliza¸˜o da Hierarquia de Mem´ria . . . . . . . . . . . . . . . . . 50 ca o An´lise das Taxas dos Eventos Medidos . . . . . . . . . . . . . . . . 55 a 63

´ 8 ANALISE DO MERGESORT

8.1 Descri¸˜o dos Programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 ca 8.2 Prepara¸˜o do Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 64 ca 8.2.1 8.2.2 Parˆmetros dos Programas . . . . . . . . . . . . . . . . . . . . . . . 64 a Configura¸˜es do OProfile Estendido . . . . . . . . . . . . . . . . . 65 co

8.3 Resultados das Medidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 8.3.1 8.3.2 Comportamento dos Programas e Contagem dos Eventos . . . . . . 66 An´lise das Taxas das Medidas . . . . . . . . . . . . . . . . . . . . 75 a 83

ˆ 9 INTERFERENCIA NAS MEDIDAS

9.1 Faltas nas TLBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 9.2 Multiplica¸˜o de Matrizes . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 ca 9.3 Mergesort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

v ˆ 10 DIVERGENCIAS NAS MEDIDAS 88

10.1 Faltas nas TLBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.2 Multiplica¸˜o de Matrizes . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 ca 10.3 Mergesort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 ˜ 11 CONCLUSAO A EVENTOS SUPORTADOS PELO OPROFILE ESTENDIDO B MULTIPLICACAO DE MATRIZES BLOCADA ¸˜ C FUNCAO READTSC ¸˜ D EXEMPLO DE CONFIGURACAO DO OPROFILE ESTENDIDO ¸˜ BIBLIOGRAFIA 93 96 98 99 100 104

vi

LISTA DE FIGURAS
2.1 Esquema simplificado do OProfile. . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Altera¸˜es realizadas no OProfile. . . . . . . . . . . . . . . . . . . . . . . . 16 co 3.2 Ocorrˆncia de diferentes eventos medidos pelo OProfile Estendido. . . . . . 17 e 3.3 Eventos ajustados para compara¸˜o visual. . . . . . . . . . . . . . . . . . . 18 ca 3.4 Leitura do ciclo do processador durante a execu¸˜o do programa . . . . . . 19 ca 4.1 Contagem dos eventos do OProfile Estendido. . . . . . . . . . . . . . . . . 22 4.2 Taxas das contagens dos eventos do OProfile Estendido. . . . . . . . . . . . 23 4.3 Contagem discriminada dos eventos do OProfile Estendido. . . . . . . . . . 24 5.1 Diagrama do processador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1 C´digo ‘C’ do programa que causa faltas controladas nas TLBs. . . . . . . 28 o 6.2 Faltas na L1 e L2 DTLB percorrendo buffers entre 0 e 349 p´ginas. . . . . . . . 30 a 6.3 Faltas na L1 DTLB percorrendo buffers entre 22 e 41 p´ginas. . . . . . . . . . 32 a 6.4 Transi¸˜o entre o regime de funcionamento normal e o thrashing na L1 DTLB. 34 ca 6.5 Acima: faltas na L2 DTLB percorrendo buffers entre 250 e 279 p´ginas. Abaixo: a
amplia¸˜o do gr´fico demontrando a transi¸˜o entre buffers. . . . . . . . . . . . ca a ca

36

7.1 Endere¸os acessados na multiplica¸˜o de matrizes convencional. . . . . . . . . . 40 c ca 7.2 Endere¸os acessados na multiplica¸˜o de matrizes com padding. . . . . . . . . . 41 c ca 7.3 Endere¸os acessados na multiplica¸˜o de matrizes com blocagem. . . . . . . . . 43 c ca 7.4 Endere¸os acessados na multiplica¸˜o de matrizes com padding e blocagem. . . . 44 c ca 7.5 Monitoramento da cache de dados durante a multiplica¸ao convencional c˜ (acima) e a multiplica¸˜o com padding e blocagem. . . . . . . . . . . . . . 49 ca 7.6 Comportamento dos eventos durante a multiplica¸˜o convencional (acima) ca e a otimizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.7 Interferˆncia durante a multiplica¸˜o de matrizes convencional (topo) e a otimizada. 54 e ca

vii 7.8 Acessos ` cache por ciclos de rel´gio na multiplica¸˜o convencional (acima) a o ca e na com padding e blocagem. . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.9 Acertos na L2 por acessos ` cache na multiplica¸˜o convencional (acima) e a ca na multiplica¸˜o com padding e blocagem. . . . . . . . . . . . . . . . . . . 58 ca 7.10 Faltas na L2 por acessos ` cache na multiplica¸˜o convencional e na blocada. 61 a ca 8.1 Acima, execu¸˜o do Mergesort. Abaixo Tiled Mergesort no mesmo vetor. . 67 ca 8.2 Ciclos da ordena¸˜o; topo Mergesort e acima Tiled Mergesort. . . . . . . . 69 ca 8.3 Acessos ` cache do Mergesort e Tiled Mergesort, faixas do tamanho da L2. a 72

8.4 Faltas na L1 para o Mergesort no topo e para o Quicksort na base. . . . . . 74 8.5 Faltas na L2 para o Mergesort no topo e para o Quicksort na base. . . . . . 76 8.6 Taxas de acessos por ciclos para Mergesort (topo) e Quicksort. . . . . . . . 78 8.7 Taxas de faltas por acessos na L1 para o Mergesort (topo) e Quicksort. . . 80 8.8 Taxas de faltas na L2 por acessos, Mergesort (topo) e Quicksort. . . . . . . 82

viii

LISTA DE TABELAS
6.1 Trecho do log do OProfile no qual ocorre o degrau da Figura 6.2. . . . . . . 31 6.2 Faltas na L1d-TLB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 Tempo de execu¸˜o da multiplica¸˜o de matrizes variando bloco e padding. ca ca 46

7.2 Contagem dos eventos para os programas de multiplica¸ao de matrizes. . . 48 c˜ 8.1 Contagem de ciclos para os programas de ordena¸˜o. . . . . . . . . . . . . 65 ca 8.2 Contagem de eventos para o trecho da execu¸˜o dos programas. . . . . . . 70 ca 9.1 Overhead do OProfile e do OProfile Estendido para faltas nas TLBs. . . . . 84 9.2 Overhead do OProfile e do OProfile Estendido no produto de matrizes. . . 85 9.3 Overhead do OProfile e do OProfile Estendido na ordena¸˜o de vetores. . . 87 ca 10.1 Divergˆncia na contagem de faltas de p´ginas. . . . . . . . . . . . . . . . . 89 e a 10.2 Divergˆncia na contagem de eventos no produto de matrizes. . . . . . . . . 90 e 10.3 Divergˆncia na contagem de eventos na ordena¸˜o de vetores. . . . . . . . . 91 e ca

ix

RESUMO
O Oprofile ´ um programa de monitoramento de desempenho cujo funcionamento ´ basee e ado na amostragem de dados dos contadores de desempenho em hardware (CDHs). Esta disserta¸˜o descreve uma extens˜o ao Oprofile, o Oprofile Estendido, que adiciona uma ca a referˆncia de tempo absoluta e o estado de todos os contadores de desempenho `s amostras e a periodicamente coletadas. A referˆncia de tempo, obtida do Time Stamp Counter, pere mite observar o comportamento temporal dos eventos monitorados na resolu¸˜o definida ca pelo usu´rio, desde que suportada pelo projeto da CPU. a Com um conjunto de amostras, cada uma contendo o valor de todos os contadores de desempenho e a referˆncia de tempo, ´ poss´ estabelecer rela¸˜es entre as intera¸˜es de e e ıvel co co eventos que ocorrem em frequˆncias distintas. e Trˆs experimentos mostram a utiliza¸˜o do Oprofile Estendido: (i) um programa de e ca teste que provoca um n´ mero controlado de faltas nos dois n´ u ıveis da TLB do sistema; (ii) programas de multiplica¸˜o de matrizes com diferentes n´ ca ıveis de otimiza¸˜o; e (iii) a ca compara¸˜o de desempenho, com rela¸˜o ` hierarquia de mem´ria, da ordena¸˜o com duas ca ca a o ca vers˜es do algoritmo de ordena¸˜o Mergesort: uma implementa¸˜o simpl´ria, e outra que o ca ca o divide o vetor em faixas do tamanho das caches e emprega o Quick sort nestas faixas. Os resultados dos experimentos mostram que: (i) o Oprofile Estendido fornece dados importantes sobre o desempenho do sistema estudado; (ii) o Oprofile Estendido ajuda na compreens˜o do modo como os programas monitorados utilizam a hierarquia de mem´ria; a o (iii) o Oprofile Estendido apresenta uma interferˆncia pr´xima ` do Oprofile em alguns e o a experimentos, cuja intensidade se altera de acordo com a taxa de amostragem utilizada; e (iv) o Oprofile Estendido proporciona uma an´lise mais completa das sequˆncias dos a e eventos ao longo da execu¸˜o dos testes da que ´ poss´ de se obter com o Oprofile. ca e ıvel

x

ABSTRACT
Oprofile is a performance monitoring tool based on hardware performance counters (HPC) data sampling. This dissertation describes an extension to Oprofile, Oprofile Estendido, which adds an absolute time reference and the state of all performance counters to the periodically collected samples. The time reference allows observing the temporal behavior of the monitored events at a user defined resolution, provided that resolution is supported by the processor. The time reference is acquired from the Time Stamp Counter (TSC). With a set of samples, each containing the values of all performance counters and the time reference, it is possible to establish relations between the interactions of the different events that occur at distinct frequencies. Three experiments show Oprofile Estendido’s usage: (i) a simple test program that causes a controlled number of faults on both levels of the system’s TLB; (ii) matrix multiplication programs with different optimization levels; and (iii) a performance comparison, from the memory hierarchy point of view, between two Mergesort algorithms: a simple implementation and a complex one, which divides the vector in cache-sized tiles and applies Quick sort on these tiles. The experiments show that: (i) Oprofile Estendido provides invaluable data on the performance of the system under study; (ii) Oprofile Estendido helps to improve the understandig on the way that monitored programs use the memory hierarchy; (iii) Oprofile Estendido’s interference on the system under study is similar to that caused by Oprofile, and the level of interference is related to the sampling rates; and (iv) Oprofile Estendido allows a more thorough analysis of the sequences of events than is possible with Oprofile.

1

CAP´ ITULO 1 INTRODUCAO ¸˜
Contadores de Desempenho em Hardware (CDHs) s˜o dispositivos de monitoramento a dispon´ ıveis em CPUs de alto desempenho. Estes dispositivos possibilitam monitorar e contabilizar eventos ocorridos no processador durante a execu¸˜o de programas e s˜o ca a amplamente utilizados na otimiza¸˜o de aplica¸˜es. ca co As ferramentas de depura¸˜o de desempenho dispon´ ca ıveis at´ o advento dos CDHs eram e capazes de fornecer a ordem das chamadas das fun¸˜es e o tempo aproximado de execu¸˜o co ca de cada uma, bem como o n´ mero de vezes em que elas eram invocadas [15]. Com base u nesses dados, observava-se o comportamento do programa nos trechos cr´ ıticos de c´digo o e deduzia-se o que era poss´ otimizar no programa para melhorar o seu desempenho. ıvel Informa¸˜es mais detalhadas relacionadas ` execu¸˜o de um programa tamb´m poco a ca e dem ser adquiridas atrav´s de simuladores [3, 30], que s˜o dif´ e a ıceis de ajustar adequadamente [34], s˜o demorados para executar, al´m de gerarem um grande volume de dados a e e de n˜o serem capazes de reproduzir tudo o que ocorre num processsador real durante a a execu¸˜o do programa. ca A implementa¸˜o dos CDHs viabilizou o monitoramento de eventos ocorridos no proca cessador durante a execu¸˜o de programas, o que desencadeou o desenvolvimento de ca novas ferramentas de depura¸˜o de desempenho, que s˜o capazes de fornecer informa¸˜es ca a co complementares `s j´ existentes, com a finalidade de facilitar a identifica¸˜o de gargalos a a ca presentes nos sistemas. Dentre as ferramentas dispon´ ıveis para a utiliza¸˜o dos CDHs encontram-se: (i) drivers ca de acesso aos contadores [29]; (ii) bibliotecas para leitura e escrita dos CDHs [6, 16]; (iii) aplicativos de monitoramento [5, 2, 10, 7] – que funcionam sem nenhuma altera¸˜o ca no programa estudado; e (iv) ferramentas para a visualiza¸˜o dos dados coletados [11]. ca Cada processador que suporta CDHs provˆ um certo conjunto de eventos observ´veis, e a

2 que incluem acessos ` cache, desvios tomados, instru¸˜es completadas e faltas na cache a co da tabela de p´ginas (TLB) entre outros. A quantidade de eventos monitor´veis simula a taneamente, bem como as formas de acesso aos contadores s˜o tamb´m distintas para a e cada CPU. Apesar dessas restri¸˜es, os instrumentos dispon´ co ıveis possibilitaram a realiza¸˜o de ca pesquisas que resultaram em t´cnicas para otimiza¸˜o do desempenho de aplica¸˜es e e ca co compiladores baseadas no uso dos CDHs [8, 9], estudos relacionados ` acur´cia e confia a abilidade dos contadores [33, 26, 18, 35] e pesquisas referentes aos m´todos de coleta de e dados dos CDHs e dos programas monitorados [27, 4, 34, 28]. O Oprofile ´ um instrumento de depura¸˜o de desempenho baseado na utiliza¸˜o de e ca ca CDHs capaz de observar (ou monitorar) simultaneamente tantos eventos quanto permitidos pelo processador [24] sem causar perturba¸˜es significativas na execu¸˜o do programa co ca monitorado. As amostras coletadas pelo Oprofile n˜o cont´m informa¸˜o referente ao a e ca instante em que um evento ocorreu, nem informa¸˜es a respeito do estado dos demais co contadores naquele mesmo instante. Ap´s a execu¸˜o de um programa monitorado pelo Oprofile obt´m-se informa¸˜es eso ca e co tat´ ısticas, similares a um histograma, a respeito dos eventos ocorridos durante a medi¸˜o, ca tais como: (i) o n´ mero de eventos causados pelo programa observado; (ii) o n´ mero u u de eventos causados pelos demais bin´rios em execu¸˜o; (iii) estat´ a ca ısticas das medidas; (iv) estat´ ısticas de eventos sobre os s´ ımbolos de programas compilados com a op¸˜o de ca depura¸˜o ‘-g’ do gcc (GNU Compiler Collection). ca A primeira parte do trabalho aqui apresentado consistiu em expandir as funcionalidades do Oprofile, de forma que cada amostra coletada passasse a conter o ciclo de rel´gio o (clock) em que ocorreu a coleta do dado e o estado dos demais contadores naquele mesmo instante. Esta informa¸˜o complementar – do ciclo em que ocorre a coleta dos dados – ca permitiu observar a evolu¸˜o da contagem dos eventos ao longo do tempo. ca Outras extens˜es consistiram em disponibilizar, em arquivos diferentes dos utilizados o pelo Oprofile, os registros de todas as amostras coletadas durante uma sess˜o de monia toramento com o Oprofile Estendido, nomes dos bin´rios que causaram os eventos e seus a

3 respectivos PIDs (Process ID) e GIDs (Group ID). As novas informa¸˜es coletadas precisaram ser contextualizadas para viabilizar a sua co interpreta¸˜o correta. Para isso foi utilizada uma fun¸˜o independente do Oprofile que ca ca lˆ o ciclo de rel´gio do processador (readtsc()). Esta fun¸˜o foi inserida no c´digo dos e o ca o programas monitorados e foi utilizada para delimitar o momento em que se inicia um trecho da execu¸˜o do programa cujo comportamento se queria observar. ca A segunda parte do trabalho consistiu em utilizar essa vers˜o modificada do Oprofile a e a fun¸˜o readtsc() para: (i) estudar a distribui¸˜o temporal dos eventos monitoraca ca dos durante uma medi¸˜o; (ii) investigar o comportamento de programas com base na ca observa¸˜o das faltas na L1, L2 e TLB; e (iii) demonstrar as perturba¸˜es que tanto o ca co Sistema Operacional (SO) quanto o Oprofile podem causar em uma aplica¸˜o durante a ca sua execu¸˜o. ca Os programas que foram investigados com o aux´ da ferramenta, apresentados em ılio ordem crescente de complexidade, s˜o: (i) programas que acessam dados em mem´ria a o para estimar o tamanho das TLB’s; (ii) multiplica¸˜o de matrizes com diferentes n´ ca ıveis de otimiza¸˜o; e (iii) programas de ordena¸˜o. ca ca Os estudos descritos em (i) e (ii) destinam-se a refinar a aplica¸˜o da metodologia e ca eventualmente ajustar as ferramentas. Com (iii) pretende-se estudar o comportamento da hierarquia de mem´ria L1 e L2 cache durante a execu¸˜o de programas baseados em o ca recurs˜o trabalhando com conjuntos de dados de tamanhos distintos. a Parte dos resultados dos estudos contidos neste trabalho foi utilizada no artigo “OProfile Estendido para Depura¸˜o de Desempenho” [1], apresentado no VI Workshop de Sisca temas Operacionais (WSO’2009). O restante do trabalho est´ organizado como descrito a seguir: o Cap´ a ıtulo 2 apresenta uma discuss˜o sobre os trabalhos relacionados a esta disserta¸˜o e uma descri¸˜o mais a ca ca detalhada do Oprofile. As altera¸˜es feitas no Oprofile e os detalhes a respeito das inco forma¸˜es complementares coletadas est˜o descritas no Cap´ co a ıtulo 3. O Cap´ ıtulo 4 descreve a metodologia para a utiliza¸˜o do Oprofile Estendido enquanto o Cap´ ca ıtulo 5 apresenta o ambiente de testes utilizado. Os Cap´ ıtulos 6, 7 e 8 descrevem e discutem os experimentos

4 e resultados obtidos, enquanto o Cap´ ıtulo 9 discute a interferˆncia causadas pelo Oprofile e Estendido nas medidas. O Capitulo 10 apresenta uma discuss˜o a respeito da divergˆncia a e encontrada entre os valores obtidos com o Oprofile e com o Oprofile Estendido em cada experimento. Finalmente, o Cap´ ıtulo 11 apresenta as conclus˜es e estudos futuros eno quanto os Apˆndices A, B, C e D cont´m a listagem dos eventos suportados pelo Athlon, e e os c´digos de programas e fun¸˜es utilizadas no trabalho, e um exemplo de arquivo de o co configura¸˜o para o Oprofile Estendido. ca

5

CAP´ ITULO 2 ˜ ´ REVISAO BIBLIOGRAFICA 2.1 Trabalhos Relacionados

Existem duas modalidades de programa¸˜o e leitura dos CDHs durante o monitoramento ca da execu¸˜o de um programa, que s˜o: contagem (counting) e amostragem (sampling). ca a Contagem consiste na leitura dos CDHs antes e depois da execu¸˜o do programa. Nesta ca abordagem, a quantidade total de eventos ´ obtida atrav´s da subtra¸˜o dos valores e e ca registrados em cada uma das leituras. Amostragem ´ baseada na leitura de um CDH a cada overflow do mesmo. Neste modo, e quando o contador atinge o seu limite, uma interrup¸˜o de hardware permite a leitura do ca valor do contador e o disponibiliza para a aplica¸˜o de monitoramento, que por sua vez, ca contabiliza este evento nas estat´ ısticas das medidas. Em [27] ´ apresentado um estudo a respeito dessas duas modalidades de uso dos e contadores e das implica¸˜es de cada uma na eficiˆncia e acur´cia das medidas. O estudo co e a foi realizado com a ferramenta de medida PAPI, inicialmente descrita em [7]. O trabalho cita alguns processadores as modalidades de coleta por eles suportada. O trabalho conclui que ambos os modos s˜o importantes e devem ser suportados em todas as plataformas de a hardware poss´ ıveis. Conclui ainda, que ´ necess´rio mais trabalho para se determinar as e a caracter´ ısticas desej´veis em uma interface multi-plataforma de acesso a CDHs, al´m de a e sugerir estudos relacionados ` calibra¸˜o dos mesmos, a fim de melhorar a precis˜o das a ca a medidas. A acur´cia dos CDHs ´ estudada em [33]. Para estimar a precis˜o das medidas foa e a ram criados microbenchmarks capazes de causar uma quantidade previs´ ıvel de eventos monitor´veis por CDHs, como faltas na TLB (Translation Lookaside Buffer). Os microa benchmarks foram executados em um processador MIPS R12000 monitorado pelos CDHs e em um simulador deste processador.

6 No processador, os dados dos CDHs foram lidos por interm´dio das ferramentas de e acesso dispon´ ıveis para a plataforma SGI MIPS, perfex e libperfex. A quantidade de eventos registrada nos CDHs foi comparada com os valores das simula¸˜es e com os co valores estimados. Os resultados demonstram que, para cada tipo de microbenchmark e m´todo de acesso aos CDHs, distintos n´ e ıveis de acur´cia eram atingidos. Al´m disso, as a e leituras realizadas com perfex e libperfex divergiram nos mesmos testes. Dentre os eventos medidos est˜o: (i) instru¸˜es decodificadas; (ii) leituras em mem´ria; a co o (iii) escritas em mem´ria; e (iv) desvios condicionais resolvidos. Destes, apenas (iii) n˜o o a atingiu um ´ ındice de erro inferior a 10% depois dos microbenchmarks serem executados por tempo suficiente para que os valores lidos convirjam at´ os os valores estimados ou e obtidos nas simula¸˜es. N˜o s˜o analisadas as causas das diferen¸as entre as medidas co a a c obtidas com perfex e libperfex. Uma continua¸˜o do estudo de acur´cia descrito em [33] ´ apresentada em [26]. Neste ca a e trabalho foi utilizada uma metodologia semelhante ` apresentada em [33], al´m da fera e ramenta PAPI [7] para realizar medidas em diferentes processadores. Algumas das diferen¸as observadas entre a previs˜o de eventos e a leitura dos CDHs nos microbenchmarks c a foram atribu´ ıdas ` busca antecipada de dados em alguns dos processadores. Este proa blema foi contornado alterando-se nos microbenchmarks a sequˆncia de acesso aos dados e em mem´ria, de linear para aleat´ria. o o Os resultados obtidos permitiram tipificar as divergˆncias entre as estimativas e os e valores obtidos nas medi¸˜es da seguinte forma: (i) overhead – representa uma diferen¸a co c constante entre a medida prevista e a medida adquirida, possivelmente causada pela ferramenta de monitoramento, ou por uma perturba¸˜o, atribu´ pelos autores a algum ca ıda outro c´digo n˜o identificado; (ii) multiplicativa – o resultado obtido ´ o produto da o a e medida esperada por um fator; (iii) aleat´ria – diferen¸a que se apresenta apenas no o c in´ da medi¸˜o e que tende a desaparecer ` medida que o microbenchmark prossegue a ıcio ca a sua execu¸˜o; e (iv) desconhecida – n˜o se enquadra nas demais categorias. ca a Diante desses resultados os autores prop˜em a inclus˜o de fatores de corre¸˜o para os o a ca contadores nas ferramentas de an´lise dos dados para melhorar a precis˜o das medidas. a a

7 Tanto este estudo quanto o seu precedente n˜o detalham o m´todo de leitura dos registraa e dores nem qual o overhead que este processo causa de acordo com a sua implementa¸˜o ca nas diferentes plataformas analisadas, possivelmente pelo trabalho ter sido realizado em plataformas propriet´rias. a Estes trabalhos tamb´m n˜o consideram que algumas das perturba¸˜es observadas nas e a co medidas podem ser causadas pelo pr´prio Sistema Operacional, uma vez que as leituras o dos CDHs s˜o diretamente comparadas com os resultados das simula¸˜es e c´lculos de a co a previs˜o, os quais n˜o contemplam as interferˆncias causadas pelo SO. a a e Em [14], os autores demonstram como a ferramenta de monitoramento para clusters RVision [13] teve sua funcionalidade extendida para suportar a leitura dos CDHs. Para isso foi criada uma biblioteca de acesso aos contadores que utiliza o driver de acesso aos CDHs dispon´ ıvel em [29]. Esta extens˜o do aplicativo foi utilizada para monitorar a a execu¸˜o de uma vers˜o paralela do benchmark SPEC Swim [32]. ca a Ap´s a an´lise do resultado das medi¸˜es de taxas de faltas na cache durante execu¸˜o o a co ca do Swim, um problema de conflito de mapeamentos em cache foi detectado e resolvido atrav´s de uma pequena altera¸˜o no c´digo do programa. Ap´s essa altera¸˜o, o tempo e ca o o ca de execu¸˜o melhorou em 25%. ca Outras informa¸˜es relevantes s˜o apresentadas neste trabalho [14], como a an´lise da co a a intrus˜o das medidas no desempenho dos programas monitorados, al´m da listagem de a e algumas m´tricas derivadas dos eventos monitor´veis, tais como opera¸˜es completadas e a co por ciclo, taxa de escritas e leituras por ciclo entre outras. Duas t´cnicas para contornar algumas das limita¸˜es dos CDHs s˜o apresentadas e co a em [4]. A primeira consiste aumentar o n´ mero de contadores dispon´ u ıveis para uma medi¸˜o, multiplexando os eventos monitor´veis entre os contadores existentes no proca a cessador durante a execu¸˜o da medida. Para isso, ´ criado um contexto contendo os ca e dados dos contadores para cada processo em execu¸˜o na m´quina. Cada contexto acuca a mula as informa¸˜es obtidas dos contadores ` medida que os eventos monitor´veis s˜o co a a a multiplexados aleatoriamente ao longo da medi¸˜o. ca Os contextos de contadores s˜o trocados a cada troca de contexto do SO de forma a

8 que, para cada processo seja levantado o seu perfil de execu¸˜o, sem que este perfil sofra ca a interferˆncia dos demais processos existentes. Uma compara¸˜o entre os dados medidos e ca atrav´s dessa t´cnica e os dados medidos sem a multiplexa¸˜o dos eventos nos contadores e e ca indicou que a diferen¸a entre as medidas obtidas era de aproximadamente 15%. c A segunda metodologia proposta associa especulativamente as paradas (stalls) do processador a um componente que seja o potencial causador da parada. Essa metodologia foi implementada a partir da ferramenta de multiplexa¸˜o de CDHs e os resultados dos expeca rimentos demonstraram que as medidas obtidas atrav´s desse m´todo s˜o razoavelmente e e a precisas. Al´m das duas metodologias descritas, o trabalho [4] tamb´m apresenta algumas e e rela¸˜es entre a taxa de amostragem dos registradores e o overhead observado no sisco tema, assim como uma descri¸˜o detalhada das caracter´ ca ısticas de funcionamento dos processadores superescalares. A ferramenta para an´lise de desempenho PAPI ´ descrita em [7]. Essa ferramenta a e disponibiliza uma s´rie de m´tricas que podem ser utilizadas na depura¸˜o de desempenho e e ca de aplica¸˜es. Sua arquitetura ´ implementada em camadas, sendo que apenas a camada co e de aquisi¸˜o dos dados dos contadores ´ dependente da arquitetura do processador e do ca e SO, enquanto as demais s˜o facilmente port´veis entre Sistemas Operacionais distintos. a a A ferramenta PAPI cont´m conjuntos de contadores de eventos pr´-definidos, al´m e e e de suportar multiplexa¸˜o de contadores, fazer medi¸˜es estat´ ca co ısticas e medi¸˜es em thco reads. PAPI suporta as plataformas Intel Pentium Pro/II/III no Linux, SGI/MIPS

R10000/R12000 no IRIX 6.x, IBM Power 604/604e/630 no AIX 4.3, Compaq Alpha EV4/5/6 no Unix Tru64 e Cray T3e/Ev5 no Unicos/mk. O trabalho [7] tamb´m cita as v´rias ferramentas de visualiza¸˜o dos dados obtidos e a ca atrav´s da PAPI como o performeter e profometer, al´m de mencionar o fato desses dados e e serem compat´ ıveis com outras ferramentas de an´lise de desempenho como o vprof [20] e a o SvPablo [11]. Uma abordagem alternativa ` an´lise de desempenho baseada em eventos ocorridos nos a a CDHs ´ apresentada em [10]. Nesse trabalho ´ demonstrado como efetuar uma an´lise e e a

9 do desempenho de um programa a partir do perfil de execu¸˜o de pares de instru¸˜es ca co escolhidos aleatoriamente. Para isso, ´ necess´rio hardware adicional n˜o dispon´ em e a a ıvel todos os processadores. A fun¸˜o destes circuitos adicionais ´ registrar o que ocorre no processador durante ca e a execu¸˜o de uma determinada instru¸˜o. Os eventos observados incluem: (i) faltas ca ca nas caches de instru¸˜es e dados; (ii) faltas nas TLBs de instru¸˜es e dados; (iii) desvios co co previstos tomados; (iv) erro da previs˜o de desvios tomados; (v) instru¸˜es completadas; a co e (vi) latˆncia, em ciclos, de cada est´gio de execu¸˜o da instru¸˜o no pipeline. e a ca ca Com essas informa¸˜es e mais algumas m´tricas a elas associadas, ´ poss´ encontrar co e e ıvel gargalos nos sistemas examinados. Outras potenciais aplica¸˜es da ferramenta citadas co pelos autores s˜o: otimiza¸˜es de compiladores, melhorias no escalonamento das instru¸˜es a co co e aumento nas taxas de acertos das caches e TLBs. Outra t´cnica alternativa ` an´lise de desempenho baseada nos CDHs ´ a instrue a a e menta¸˜o no kernel estudada em [22, 23]. Neste trabalho ´ desenvolvida uma ferramenta ca e de depura¸˜o de desempenho, denominada PANALYSER, que adquire as amostras a partir ca das chamadas de sistema ptrace(), getrusage() e wait4(). O PANALYSER ´ compae rado `s demais ferramentas de monitoramento do sistema – que adquirem as informa¸˜es a co a partir do pseudo sistema de arquivos /proc – e concluiu-se que a instrumenta¸˜o do ca kernel demanda menos processamento e, consequentemente, apresenta um overhead inferior ao das ferramentas baseadas na leitura do /proc. Apesar da instrumenta¸˜o do ca kernel causar menos perturba¸˜o no sistema do que a leitura do /proc, ela ainda causa ca um overhead superior ao da leitura dos CDHs. Uma an´lise dos eventos contados em processadores x86 ´ apresentada em [35]. Neste a e trabalho, v´rios processadores dessa mesma arquitetura s˜o utilizados para medir insa a tru¸˜es completadas e ciclos em que o processador n˜o est´ parado. Uma vez que todos co a a os processadores s˜o da mesma arquitetura, o n´ mero de intru¸˜es necess´rias para exea u co a cutar o mesmo programa n˜o deve variar entre os processadores. a As medidas iniciais demonstraram, a priori, uma divergˆncia de aproximadamente 1% e entre os processadores testados. Foi ent˜o realizado um estudo que incluiu caracter´ a ısticas

10 de layout de mem´ria, an´lise de instru¸˜es dos benchmarks, an´lise do modo de execu¸˜o o a co a ca – entre 32 e 64 bits, gerenciamento de mem´ria e a pr´pria implementa¸˜o dos contadores. o o ca Com os resultados e padroniza¸˜es obtidas a partir dos dados deste estudo, os expeco rimentos foram realizados novamente e a margem de erro obtida entre os processadores baixou para menos de 0,002%. Apesar da alta precis˜o da medida, ela apenas se refere a ` quantidade de instru¸˜es executadas. Os demais eventos dispon´ a co ıveis nos processadores n˜o s˜o testados. a a Em [18] ´ feita uma compara¸˜o entre resultados de medidas obtidas com contadores e ca de desempenho de diferentes processadores para os mesmos benchmarks. Paralelamente, caracter´ ısticas dos benchmarks tais como previsibilidade de desvios, conjunto de trabalho (working set), quantidade de mem´ria utilizada foram analisados. o Comparando os resultados das medidas dos contadores com as caracter´ ısticas de cada programa examinado, foi constatado que benchmarks com caracter´ ısticas diferentes podem apresentar comportamentos similares em algumas arquiteturas, se analisados apenas pelo vi´s dos contadores de desempenho. Destas compara¸˜es, foi observado que as conclus˜es e co o referentes ao perfil de execu¸˜o de programas, quando obtidas a partir apenas dos dados ca dos CDHs em uma determinada arquitetura, n˜o devem ser generalizadas para as demais. a Dados coletados de contadores de desempenho s˜o utilizados para definir o melhor a conjunto de flags de compila¸˜o para programas de benchmark em [9]. O processo consiste ca na utiliza¸˜o de redes neurais para fazer o mapeamento entre o comportamento dos eventos ca e as flags que devem ser ligadas ou desligadas para a compila¸˜o. Ap´s a realiza¸˜o de ca o ca um treinamento exaustivo na rede neural com v´rios tipos de programas, o mapeamento a ´ obtido e utilizado como base para estabelecer o melhor conjunto de flags para um e programa qualquer. Normalmente o conjunto de flags ´ definido em aproximadamente e trˆs compila¸˜es e execu¸˜es monitoradas. e co co As medidas de desempenho realizadas nos programas compilados com o conjunto de flags estabelecido pela ferramenta demonstraram que houve um ganho de desempenho superior a 10% em rela¸˜o ao melhor conjunto de flags de otimiza¸˜o pr´-definidos em ca ca e um compilador comercial.

11 De acordo com [34], simuladores n˜o-comerciais s˜o dif´ a a ıceis de utilizar em pesquisas por serem mal documentados e implementados sobre bibliotecas velhas. Al´m disso, os e modelos de processadores suportados s˜o defasados e est˜o longe de simular a arquitetura a a dos processadores atuais. Partindo deste cen´rio, trˆs tipos de an´lises s˜o realizadas e comparadas para um a e a a conjunto de benchmarks: execu¸˜es com simuladores, execu¸˜es com ferramentas de Insco co trumenta¸˜o Dinˆmica Bin´ria (IDB) e execu¸˜es com contadores de desempenho. Os ca a a co testes foram realizados no simulador mais parecido com o processador utilizado nos experimentos e os valores obtidos com os contadores de desempenho foram a referˆncia de e medida confi´vel. a A conclus˜o indica que, apesar de trabalhosas e imprecisas na maioria das ocasi˜es, as a o simula¸˜es ainda s˜o necess´rias. Al´m disso, foi conclu´ tamb´m que de acordo com o co a a e ıdo e grau de detalhe necess´rio para a an´lise dos programas, as ferramentas de IDB podem a a oferecer vantagens por serem mais simples e mais r´pidas, apesar de fornecerem menos a detalhes sobre as execu¸˜es. co

2.2

OProfile

O Oprofile ´ uma ferramenta de monitoramento de desempenho baseada no uso dos CDHs e composta por: (i) componentes dependentes de arquitetura (DA) – c´digo respons´vel o a pelo gerenciamento, configura¸˜o e manipula¸˜o dos CDHs em cada arquitetura suporca ca tada; (ii) oprofilefs – pseudo filesystem que armazena os arquivos respons´veis por infora mar e receber configura¸˜es do espa¸o de usu´rio, al´m de outras informa¸˜es referentes co c a e co aos eventos monitor´veis; (iii) CPU Buffer e Event Buffer– ´reas de armazenamento que a a mant´m as amostras em espa¸o de SO at´ que elas sejam transferidas para a ´rea de e c e a usu´rio; (iv) driver gen´rico para o kernel – recebe as amostras enviadas pelo compoa e nente DA e armazena-as no buffer apropriado at´ transfer´ e ı-las para o daemon no espa¸o c de usu´rio; (v) OProfile daemon – respons´vel por receber as amostras do kernel e escrevˆa a e las em disco, sendo as amostras separadas e salvas em diferentes arquivos; (vi) ferramentas de p´s processamento – selecionam as amostras requeridas pelo usu´rio associando-as aos o a

12 bin´rios relevantes, apresentando a informa¸˜o num formato compreens´ a ca ıvel. Durante a execu¸˜o do Oprofile, cada CDH dispon´ no processador ´ inicializado ca ıvel e e configurado para monitorar um determinado evento que, quando ocorre, causa um incremento do contador apropriado. No momento em que o contador atinge o valor limite, uma interrup¸˜o causa a execu¸˜o do c´digo do driver (DA), que lˆ o valor do ca ca o e PC e o n´ mero do contador que entrou em overflow, reiniciando-o e inserindo os valores u do contador e do PC no CPU Buffer. O c´digo do driver DA tamb´m registra no CPU o e Buffer as trocas de processos em execu¸˜o, assim como as trocas de modo de execu¸˜o ca ca entre usu´rio e sistema. a Periodicamente, o CPU Buffer ´ sincronizado com o Event Buffer pelo driver gen´rico e e do OProfile, que al´m de converter o valor do PC em um offset relativo ao bin´rio causador e a do evento, insere os dados das amostras e do offset referente ao PC no Event Buffer, junto com um identificador do bin´rio em execu¸˜o no momento do registro da amostra. Os a ca dados s˜o ent˜o transferidos para o espa¸o de usu´rio pelo OProfile daemon, que trata os a a c a dados coletados criando e mantendo em disco arquivos de amostras para cada bin´rio em a execu¸˜o. ca Para cada bin´rio ´ mantido um conjunto de arquivos, um arquivo para cada evento a e monitorado. O arquivo cont´m uma s´rie de registros com o valor do PC no momento em e e que a interrup¸˜o do contador foi atendida, al´m do n´ mero de interrup¸˜es j´ atendidas ca e u co a para cada um dos valores de PC registrados. O n´ mero de registros, multiplicado pelo u n´ mero de ocorrˆncias, corresponde ao n´ mero de interrup¸˜es associadas ao contador e ´ u e u co e portanto proporcional ` contagem de eventos. No p´s-processamento ´ poss´ associar o a o e ıvel valor de cada PC a um s´ ımbolo do bin´rio, caso este tenha sido compilado com a op¸˜o -g a ca do gcc. A figura 2.1 descreve o trajeto percorrido por uma amostra durante uma medi¸˜o do ca Oprofile. Primeiramente, os contadores s˜o configurados e inicializados pelas chamadas a setup() e start(), contidas na por¸˜o dependente de arquitetura do driver do Oprofile. ca Ap´s algum tempo, o contador 0 entra em overflow. Neste momento, uma interrup¸˜o de o ca hardware executa o c´digo que descobre qual contador entrou em overflow, qual o valor o

13 do PC, qual a tarefa em execu¸˜o e envia essas informa¸˜es para o driver gen´rico atrav´s ca co e e da fun¸˜o oprofile_add_sample(). ca A amostra e demais informa¸˜es s˜o ent˜o armazenadas no CPU Buffer. No Oprofile co a a h´ um CPU Buffer para cada processador no sistema. O CPU Buffer tamb´m armazena a e informa¸˜es a respeito da troca de processos em execu¸˜o e da troca de modo de opera¸˜o co ca ca entre modo usu´rio e modo sistema ao longo de uma sess˜o de monitoramento. a a Periodicamente, os dados s˜o transferidos para o buffer principal, denominado Event a Buffer. O c´digo contido no arquivo buffer_sync.c ´ respons´vel pela sincroniza¸˜o dos o e a ca buffers, pela cria¸˜o de identificadores unicos (dcookie) para cada bin´rio executado no ca ´ a sistema e pelo armazenamento de informa¸˜es complementares. co As amostras s˜o ent˜o transferidas para o espa¸o de usu´rio atrav´s do OProfile daa a c a e emon, respons´vel por essa transferˆncia, pela cria¸˜o de novos arquivos ` medida que a e ca a amostras de novos bin´rios lhe s˜o entregues na sincroniza¸˜o peri´dica dos arquivos. a a ca o Para cada bin´rio executado, um arquivo por evento monitorado ´ criado e mapeado em a e mem´ria. Cada um desses arquivos de dados cont´m os totais de amostras para cada o e valor de PC que tenha causado um overflow. O daemon organiza os ponteiros para os arquivos numa lista encadeada tanto em LRU (Last Recently Used) quanto pelo ´ ındice gerado a partir do hash do nome do bin´rio a monitorado. A sincroniza¸˜o dos arquivos de amostras mapeados com o disco ocorre ca periodicamente at´ o t´rmino da execu¸˜o do Oprofile. Maiores informa¸˜es a respeito e e ca co desse processo e das ferramentas de p´s-processamento dispon´ o ıveis no Oprofile podem ser encontradas em [25].

14

PC 1:PC/Total,PC/Tot.. Processador
Dependente de Arquitetura

Disco

3:PC/Total 2:PC/Total,PC/Total n:PC/Total,...

4:PC/Total,PC/Tot.. CTR 2 CTR 3 n-1:PC/Total

CTR 0

CTR 1

setup() start() stop() oprofile_add_sample (PC,0)

Daemon OProfile

Lista encadeada e LRU
Driver Genérico

Hash 1 EVENT BUFFER DCOOKIE, OFFSET TASK SWITCH DCOOKIE, OFFSET daemon/ opd_trans.c Hash 3

CPU BUFFER PC, CTR TASK SWITCH PC, CTR buffer_sync.c KERNEL SWITCH PC, CTR PC, CTR

Hash 2

Hash 4

KERNEL SWITCH DCOOKIE, OFFSET DCOOKIE, OFFSET

Hash n-1

Hash n
Ponteiros para arquivos mapeados

Figura 2.1: Esquema simplificado do OProfile.

15

CAP´ ITULO 3 OPROFILE ESTENDIDO
O c´digo do Oprofile foi alterado pelo autor, de forma que cada amostra coletada cono tenha uma referˆncia de tempo, al´m do estado dos demais contadores no momento da e e interrup¸˜o. Este cap´ ca ıtulo descreve as altera¸˜es realizadas no c´digo do Oprofile que co o resultaram no Oprofile Estendido.

3.1

Altera¸˜es na coleta dos dados co

As primeiras altera¸˜es realizadas foram inseridas no c´digo do driver DA do Oprofile, co o e s˜o executadas no momento em que ocorre a interrup¸˜o que permite a leitura dos a ca contadores de desempenho e determina o contador em overflow. A referˆncia de tempo e foi obtida implementando neste trecho de c´digo uma fun¸ao que lˆ o Time Stamp Counter o c˜ e (TSC)1 no momento em que este c´digo ´ executado. A informa¸˜o referente ao estado o e ca dos demais contadores foi obtida alterando o c´digo que verifica os contadores, de forma o que os valores de todos fossem copiados para um array. O valor do TSC e o array contendo os valores de todos os contadores foram inclu´ ıdos nos parˆmetros da chamada da fun¸˜o oprofile_add_sample(), para que pudessem ser a ca inseridos no CPU Buffer junto aos demais dados. Os c´digos das estruturas CPU Buffer o e Event Buffer foram alterados para incluir os valores do TSC e dos demais contadores a cada nova amostra. Os arquivos buffer_sync.c e daemon/opd_trans.c tamb´m foram e alterados para incluir esses valores nas opera¸˜es de sincroniza¸˜o e transferˆncia entre co ca e os buffers. No c´digo do daemon, foram inseridos dois novos arquivos opd_logfile.c e opd_ o logtable.c. O c´digo contido em opd_logfile.c ´ respons´vel por mapear um arquivo o e a de registro contendo, para cada amostra, o valor do TSC, as informa¸˜es sobre o estado da co
TSC ´ um contador de 64 bits que conta o n´ mero de ciclos de rel´gio do processador a partir do e u o instante da inicializa¸ao do computador. c˜
1

16
TSC PC Disco

Processador
Dependente de Arquitetura

1:PC/Total,PC/Tot.. 2:PC/Total,PC/Total

n:PC/Total,... n-1:PC/Total HASH,BINÁRIO

CTR 0

CTR 1

CTR 2

CTR 3 TSC,CO,CTRS,HASH

setup() start() stop() oprofile_add_sample (PC,0,CTRS,TSC)

Driver Genérico

Daemon OProfile

opd_log{file,table}.c CPU BUFFER PC, CTR,CTRS,TSC TASK SWITCH PC, CTR,CTRS,TSC KERNEL SWITCH PC, CTR,CTRS,TSC PC, CTR,CTRS,TSC EVENT BUFFER DCOOKIE, OFFSET, CTRS, TSC TASK SWITCH daemon/ opd_trans.c Lista encadeada e LRU Hash 1

DCOOKIE, OFFSET, CTRS, TSC buffer_sync.c KERNEL SWITCH DCOOKIE, OFFSET, CTRS, TSC

Hash 2 Hash n-1

Hash n DCOOKIE, OFFSET,CTRS, TSC
Ponteiros para arquivos mapeados

Figura 3.1: Altera¸˜es realizadas no OProfile. co

contagem dos CDHs e o valor do hash do bin´rio que estava sendo executado, bem como a seus respectivos PIDs e GIDs. As amostras s˜o inseridas no arquivo de log mapeado a em mem´ria ` medida que s˜o processadas e o arquivo em disco ´ atualizado a cada o a a e sincroniza¸˜o do SO. ca O arquivo opd_logtable.c cont´m o c´digo para manter um arquivo de ´ e o ındice contendo o hash e o nome do bin´rio de cada programa em execu¸˜o que tenha gerado dados a ca de amostras durante a monitora¸˜o do Oprofile. O arquivo de ´ ca ındice ´ atualizado a cada e novo nome de bin´rio observado pelo Oprofile. A figura 3.1 cont´m o diagrama simplifia e cado do Oprofile original com as altera¸˜es realizadas no trabalho. co

3.2

P´s-processamento e an´lise das amostras o a

A an´lise dos resultados obtidos com o Oprofile Estendido ´ baseada no registro gerado a e a partir os dados coletados que, p´s-processados, podem fornecer gr´ficos, contagens dos o a eventos em trechos da execu¸˜o, etc. Todas as rotinas relacionadas ao p´s processamento ca o dos dados foram desenvolvidas ` parte do c´digo original do Oprofile e as principais a o

17
Contadores de Desempenho 500000 450000 400000 350000 Contagem de Eventos 300000 250000 200000 150000 100000 50000 0 0 1e+08 2e+08 Ciclos L1_DTLB_MISSES_L2_DTLD_HITS 450K L1_AND_L2_DTLB_MISSES 450K DATA_CACHE_REFFILLS_FROM_L2 450K 3e+08 4e+08 5e+08

Figura 3.2: Ocorrˆncia de diferentes eventos medidos pelo OProfile Estendido. e

caracter´ ısticas das ferramentas de p´s processamento dos dados est˜o descritas a seguir. o a A coleta de amostras do Oprofile Estendido ´ controlada somente pelo contador que e acumula os ciclos de rel´gio em que o processador est´ ativo (cpu_clk_unhalted). Deo a pendendo do grau de resolu¸˜o que se queira na medi¸˜o, o n´ mero de eventos registrado ca ca u por unidade de tempo pode ser muito elevado por conta da frequˆncia do rel´gio dos e o processadores atuais, o que torna mais lenta a gera¸˜o de gr´ficos de eventos × tempo. A ca a visualiza¸˜o do eixo do gr´fico que representa os ciclos de rel´gio ´ tamb´m prejudicada ca a o e e em fun¸˜o do tamanho dos valores inicial e final inseridos na escala. ca Para melhorar a visualiza¸˜o desses dados nos gr´ficos a escala de ciclos foi deslocada ca a para zero, subtraindo-se o valor do primeiro ciclo registrado pelo Oprofile Estendido dos demais ciclos. Dessa forma, al´m de melhorar a visualiza¸˜o do gr´fico, ´ poss´ estabee ca a e ıvel lecer um ponto inicial na execu¸˜o de um programa, o que torna poss´ a compara¸˜o ca ıvel ca entre gr´ficos de medidas de diferentes execu¸˜es do mesmo programa. a co O Oprofile ´ capaz de monitorar v´rios eventos. De acordo com a natureza do evento e a monitorado, ´ prov´vel que ele ocorra numa frequˆncia mais alta que a dos demais, fae a e

18
Contadores de Desempenho: Escala Ajustada 7e+06

6e+06

5e+06

Contagem

4e+06

3e+06

2e+06

1e+06

0 0 1e+08 2e+08 Ciclos L1_DTLB_MISSES_L2_DTLD_HITS: 0,96 L1_AND_L2_DTLB_MISSES: 0,06 DATA_CACHE_REFFILLS_FROM_L2 3e+08 4e+08 5e+08

Figura 3.3: Eventos ajustados para compara¸˜o visual. ca

zendo com que um contador atinja seu limite e seja reinicializado mais vezes do que os outros. Isso causa um efeito de serra no gr´fico da contagem dos eventos, como mostra a a Figura 3.2. Observa-se na figura que, enquanto Data_Cache_Refills_from_L2 ocorre aproximadamente na mesma frequˆncia que L1_DTLB_Misses_L2_DTLD_Hits – ambos e atingindo o pico do gr´fico aproximadamente quatorze vezes – L1_and_L2_DTLB_Misses a atinge o pico do gr´fico apenas uma vez, denotando uma frequˆncia de ocorrˆncia aproa e e ximadamente quatorze vezes inferior. Para corrigir esse problema, foi implementada uma rotina que soma, a cada valor lido, o valor total da contagem at´ a ultima re-inicializa¸˜o do contador. Deste modo, a linha e ´ ca em forma de serra ´ plotada como uma linha que cresce de forma monotˆnica. Para evitar e o que a inclina¸˜o da linha do evento que ocorre em maior quantidade torne invis´ ca ıveis as varia¸˜es na linha do evento que ocorre em menor quantidade, ao final da rotina de soma, co todos os pontos da linha s˜o ajustados em rela¸˜o ` escala do evento que ocorreu o maior a ca a n´ mero de vezes. Desta forma, as linhas do gr´fico s˜o plotadas em escalas diferentes mas u a a facilmente compar´veis, como mostrado na figura 3.3. O fator de ajuste de cada curva ´ a e

19
Contadores de Desempenho: Escala Ajustada 7e+06

6e+06

5e+06

Contagem

4e+06

3e+06

2e+06

1e+06

0 0 1e+08 2e+08 Ciclos L1_DTLB_MISSES_L2_DTLD_HITS: 0,96 L1_AND_L2_DTLB_MISSES: 0,06 DATA_CACHE_REFFILLS_FROM_L2 Passos do programa 3e+08 4e+08 5e+08

Figura 3.4: Leitura do ciclo do processador durante a execu¸˜o do programa ca

mostrado na legenda da figura. Para delimitar pontos interessantes da execu¸˜o do programa, assim como o in´ e ca ıcio o t´rmino da execu¸˜o do mesmo, foi escrita uma fun¸˜o – readtsc(), cujo c´digo est´ e ca ca o a listado no Apˆndice C – que lˆ o ciclo do processador registrado no Time Stamp Counter. e e O resultado da inser¸˜o da fun¸˜o readtsc() no c´digo do programa monitorado pode ca ca o ser visualizado na figura 3.4. As linhas verticais denotam os instantes em que a fun¸˜o ca readtsc() ´ invocada. e Estas s˜o as ferramentas utilizadas para facilitar a an´lise dos dados coletados pelo a a Oprofile Estendido. Na medida que mais testes foram concebidos e realizados, mais ferramentas se tornaram necess´rias e foram desenvolvidas. Neste mesmo processo, novas a potencialidades do Oprofile Estendido foram enxergadas e exploradas, o que ser´ demonsa trado no Cap´ ıtulo 4, nas formas de visualiza¸˜o apresentadas. ca

20

CAP´ ITULO 4 METODOLOGIA
Para analisar o comportamento de um determinado programa com o Oprofile Estendido a seguinte metodologia deve ser utilizada. Primeiramente, ´ necess´rio fazer uma an´lise da natureza da aplica¸˜o monitorada e e a a ca definir o tipo de evento que pode estar relacionado aos problemas de desempenho inerentes ` aplica¸˜o1 . Por exemplo, analisar as faltas nas caches e TLBs em um programa que exea ca cuta opera¸˜es matem´ticas em grandes quantidades de dados pode ser mais interessante co a a priori do que medir as falhas nas previs˜es de desvios do mesmo programa. o Monitorar diferentes eventos durante uma mesma execu¸˜o permite identificar as ca ´ rela¸˜es entre os eventos. E poss´ co ıvel, por exemplo, saber a propor¸˜o das faltas na cache ca L1 que causam faltas na L2, ou mesmo nas demais estruturas presentes nos outros n´ ıveis ´ da hierarquia de mem´ria. E poss´ tamb´m relacionar um per´ o ıvel e ıodo de muitas faltas nas TLBs a uma queda na taxa de instru¸˜es completadas e assim por diante. co Definidos os eventos a serem monitorados, ´ necess´rio verificar a taxa de amostragem e a ideal para coletar os dados. Durante uma medi¸˜o com o Oprofile Estendido, o prica meiro contador ´ configurado para contar os ciclos de rel´gio do processador (Cpu_Clk_ e o Unhalted). Cada vez que aquele entra em overflow, ´ coletada a amostra do programa e em execu¸˜o e o estado dos demais contadores. A frequˆncia com que o primeiro contador ca e entra em overflow ´ definida como taxa de amostragem e pode ser alterada pelo usu´rio. e a A taxa de amostragem utilizada depende da resolu¸˜o requerida pela aplica¸˜o em ca ca teste e do tempo de execu¸˜o da mesma. Por exemplo, eventos monitorados na cache ca L1 podem requerer uma taxa de amostragem mais alta do que eventos monitorados na TLB, uma vez que os eventos da TLB s˜o menos frequentes. Por outro lado, monitorar a eventos na TLB com a mesma frequˆncia que se monitora eventos na cache resulta em e
1

Os eventos suportados pelo Athlon est˜o listados no Apˆndice A a e

21 um overhead de processamento desnecess´rio. a Da mesma forma, monitorar os eventos – ainda que na frequˆncia recomendada – e durante muito tempo gera uma quantidade de dados enorme, dos quais – de acordo com o caso – grande parte podem ser seguramente descartada sem que a visualiza¸˜o do gr´fico ca a seja prejudicada. Este caso tamb´m ilustra uma situa¸˜o onde boa parte do overhead da e ca medida poderia ser evitado. Definido o valor ideal da taxa de amostragem, o c´digo do programa a ser medido o deve ser analisado e a fun¸˜o readtsc() inserida no c´digo para delimitar os pontos mais ca o interessantes a serem investigados. Tamb´m ´ interessante inserir uma chamada desta e e fun¸˜o no in´ e no final da execu¸˜o do programa, de forma que o overhead da carga e ca ıcio ca da destrui¸˜o do processo medido n˜o interfira nos dados analisados. ca a Com o Oprofile Estendido, ´ poss´ visualizar os dados para a an´lise de trˆs fore ıvel a e mas distintas: (i) a contagem dos eventos; (ii) a taxa dos eventos; e (iii) a contagem discriminada dos eventos. Cada um dos m´todos de visualiza¸˜o pode exigir op¸˜es de e ca co configura¸˜o diferentes no momento da coleta de dados. Al´m disso, o p´s-processamento ca e o dos dados das amostras tamb´m s˜o distintos para cada um dos casos. e a Na visualiza¸˜o da contagem dos eventos, o conjunto de dados ´ tratado com o ajuste ca e das curvas e a demarca¸˜o dos pontos interessantes do programa com o aux´ da fun¸˜o ca ılio ca readtsc(), como visto no Cap´ ıtulo 3. A Figura 4.1 mostra a evolu¸˜o da contagem ca dos eventos ICache_Fetches e ICache_Misses durante a carga de um programa. A linha vertical pontilhada, delimita o in´ da execu¸˜o do programa e foi obtida com a execu¸˜o ıcio ca ca da fun¸˜o readtsc(). ca A visualiza¸˜o da taxa ´ obtida dividindo-se as varia¸˜es (∆) de um evento entre duas ca e co amostras consecutivas pela varia¸˜o de outro evento nas mesmas duas amostras. Os evenca tos s˜o escolhidos de acordo com a informa¸˜o que se queira visualizar. Na Figura 4.2, a ca o mesmo trecho de carga de programa ´ apresentado, mas as linhas plotadas represene tam as taxas dos eventos ∆ICache_Accesses/∆Ciclos e ∆ICache_Misses/∆ICache_ Accesses. A taxa dos eventos apresenta oscila¸˜es em alguns trechos da execu¸˜o da medida. Isto co ca

22
OProfile Estendido: Contagem dos eventos 1,6e+06

1,4e+06

1,2e+06

1e+06 Contagem

800000

600000

400000

200000

0 0 5e+06 1e+07 1,5e+07 2e+07 Ciclos ICACHE_FETCHES ICACHE_MISSES Início do Programa 2,5e+07 3e+07 3,5e+07

Figura 4.1: Contagem dos eventos do OProfile Estendido.

acontece porque a execu¸˜o da interrup¸˜o que lˆ a amostra do Oprofile Estendido n˜o ca ca e a ocorre instantaneamente, uma vez que ela depende do atendimento pelo processador, que pode demorar de centenas a milhares de ciclos de rel´gio de acordo com a carga da CPU. o Devido a estas varia¸˜es no tempo de atendimento da coleta da amostra, a contagem co dos eventos monitorados pode sofrer alguma altera¸˜o entre momento em que ocorre o ca overflow e o momento da leitura do contador. Esta varia¸˜o ´ praticamente invis´ na ca e ıvel visualiza¸˜o da contagem mas torna-se bastante evidente na taxa. ca A visualiza¸˜o discriminada apresenta, al´m da contagem dos eventos, o bin´rio que ca e a estava sendo executado no momento em que foi realizada a leitura dos contadores e outras ´ informa¸˜es. E poss´ co ıvel gerar este tipo de visualiza¸˜o porque o Oprofile ´ capaz de ca e distinguir as amostras dos bin´rios monitorados entre: (i) lib – c´digo de bibliotecas a o compartilhadas, (ii) kernel – c´digo de kernel executado, (iii) cpu – em qual processador o o c´digo foi executado, (iv) thread – caso o mesmo programa seja executado em threads, o separa as amostras por thread e (v) all – todas as op¸˜es. co De acordo com as op¸˜es de configura¸˜o escolhidas na coleta das amostras, cada uma co ca

23
OProfile Estendido: Taxas dos eventos 0,4

0,35

0,3

0,25 Taxa

0,2

0,15

0,1

0,05

0 0 5e+06 1e+07 1,5e+07 2e+07 Ciclos ∆ ICACHE_FETCHES / ∆ Ciclos ∆ ICACHE_MISSES / ∆ ICACHE_FETCHES Início do Programa 2,5e+07 3e+07 3,5e+07

Figura 4.2: Taxas das contagens dos eventos do OProfile Estendido.

delas conter´ informa¸˜es complementares como nome do bin´rio, nome da biblioteca, a co a n´ mero do PID e n´ mero do GID. Considerando a quantidade de programas rodando em u u um sistema, as bibliotecas utilizadas na implementa¸˜o de cada um, al´m do respectivo ca e PID ou GID que diferentes instˆncias do mesmo programa podem possuir, nota-se que a ´ invi´vel plotar um gr´fico contendo todas estas informa¸˜es. Neste caso, as amostras e a a co coletadas tem de ser reagrupadas de forma que a visualiza¸ao dos dados se torne poss´ c˜ ıvel, al´m de manter-se apenas as informa¸˜es relevantes ao experimento em quest˜o. e co a Um exemplo desta visualiza¸˜o ´ demonstrada na Figura 4.3 – que mais uma vez ca e apresenta o mesmo trecho de carga do programa dinamico – no qual todas as amostras foram separadas e reagrupadas de acordo com a conveniˆncia de visualiza¸˜o. Cada padr˜o e ca a de ponto representa a sequˆncia da contagem de um evento. Cada cor atribu´ aos pontos e ıda equivale a um bin´rio detectado pelo Oprofile Estendido durante a monitora¸˜o. Os dados a ca coletados que n˜o fazem parte do conjunto que se quer observar (oprofile, ld, libc, libm e a dinamico) foram agrupados em um grupo e plotados como “resto”. Os trechos em que h´ a uma grande distˆncia entre os pontos representam stalls (paradas) do processador. a

24

OProfile Estendido: Contagem Discriminada 1200

1000

800 Contagem

600

400

200

0 0 5e+06 1e+07 1,5e+07 2e+07 Ciclos ICACHE_FETCHES oprofile ICACHE_FETCHES resto ICACHE_FETCHES ld ICACHE_FETCHES libc ICACHE_FETCHES vmlinux ICACHE_FETCHES libm ICACHE_FETCHES dinamico ICACHE_MISSES oprofile ICACHE_MISSES resto ICACHE_MISSES ld ICACHE_MISSES libc ICACHE_MISSES vmlinux ICACHE_MISSES libm ICACHE_MISSES dinamico Início 2,5e+07 3e+07 3,5e+07

Figura 4.3: Contagem discriminada dos eventos do OProfile Estendido.

25

CAP´ ITULO 5 AMBIENTE DE TESTES
Todos os testes apresentados neste trabalho foram realizados na mesma m´quina. Os a experimentos realizados com o Oprofile Estendido foram executados no GNU Linux-2.6.8 com as altera¸˜es nos drivers do Oprofile original. A vers˜o do Oprofile usada como base co a para o desenvolvimento do Oprofile Estendido foi a vers˜o 0.9.2. a O processador utilizado nos experimentos ´ o AMD AthlonTM XP 2400+, fam´ 6, e ılia modelo 8. A maioria das informa¸˜es aqui descritas foram obtidas no seu manual [19], co assim como a Figura 5.1, que cont´m um diagrama do processador com os elementos da e sua hierarquia de mem´ria destacados em vermelho. As informa¸˜es n˜o encontradas na o co a documenta¸˜o do Athlon foram complementadas com os dados fornecidos pelo programa ca x86info [21]. A hierarquia de mem´ria do Athlon tem dois n´ o ıveis de mem´ria cache. A cache o prim´ria ´ separada entre cache de dados e cache de instru¸˜es. A cache de dados tem a e co capacidade de 64 Kbytes com 512 conjuntos, cada conjunto contendo dois blocos (associatividade bin´ria), cada um com 64 bytes e a reposi¸˜o ocorre sobre o elemento menos a ca recentemente utilizado (Least Recently Used). A escrita de dados funciona com escrita pregui¸osa (write back) e aloca¸˜o em falta na escrita. c ca A cache de instru¸˜es tem capacidade para 64 Kbytes, associatividade de duas vias e co armazena 64 bytes por bloco. A reposi¸˜o dos blocos ´ Least Recently Used (LRU) e cada ca e busca de instru¸˜o recupera da L2, ou da mem´ria principal, os 64 bytes que preenchem ca o uma linha inteira, al´m dos 64 bytes da linha seguinte, tirando proveito da localidade e espacial. O segundo n´ da cache ´ unificado para dados e instru¸˜es, com associatividade de ıvel e co 16 vias, 64 bytes por bloco e capacidade de 256 Kbytes. A hierarquia de TLBs ´ organizada em dois n´ e ıveis, sendo o primeiro n´ separado para ıvel

26

Figura 5.1: Diagrama do processador.

instru¸˜es e dados. A TLB de dados do n´ 1 cont´m 32 mapeamentos para p´ginas co ıvel e a de 4 Kbytes e 8 mapeamentos para p´ginas de 2 ou 4 Mbytes, al´m de ser totalmente a e associativa e com reposi¸˜o LRU. Na TLB de instru¸˜es do primeiro n´ h´ 16 blocos ca co ıvel a para p´ginas de 4 Kbytes e 8 blocos para p´ginas de 2 ou 4 Mbytes, a reposi¸˜o ´ LRU e a a ca e a associatividade ´ total. e O segundo n´ da TLB deste processador tamb´m ´ separado para dados e instru¸˜es. ıvel e e co Tanto a TLB de instru¸˜es quanto a de dados do n´ 2 mant´m 256 mapeamentos com co ıvel e associatividade de 4 vias. As duas TLBs possuem apenas mapeamentos para p´ginas de a 4 Kbytes [19].

27

CAP´ ITULO 6 ´ ANALISE DAS FALTAS NAS TLBS
Este cap´ ıtulo descreve um experimento que visa a monitorar as faltas na TLB durante a execu¸˜o de um programa que causa um n´ mero definido de faltas nesta estrutura. ca u O objetivo dos experimentos ´ observar o comportamento das faltas na L1 e L2 TLB ` e a medida que o tamanho do buffer percorrido na execu¸˜o do programa supera a capacidade ca do n´ da TLB testado. ıvel

6.1

Descri¸˜o do programa ca

Para causar a quantidade de faltas esperadas durante a sua execu¸˜o, a cada ‘passo’ do ca teste, o programa aloca um conjunto de n p´ginas e as percorre 500 vezes, efetuando uma a leitura em cada p´gina. Dessa forma espera-se que a cada passo ocorra ao menos uma a falta a mais que no passo anterior. O algoritmo do programa ´ mostrado em linguagem e ‘C’ na Figura 6.1. Uma ´rea de tamanho n/5 a
1

´ alocada para separar a ´rea original de tamanho n e a

daquela que ser´ alocada com tamanho n + 1. As ´reas de tamanho n e n/5 s˜o liberadas a a a somente ap´s a aloca¸˜o da nova ´rea, que ´ ent˜o percorrida 500 vezes. O separador o ca a e a de tamanho n/5 diminui a probabilidade de que dois testes consecutivos usem o mesmo conjunto de p´ginas, o que reduziria a ocorrˆncia de faltas pelo reaproveitamento dos a e mapeamentos na TLB.

6.2

Prepara¸˜o do Experimento ca

Esta se¸˜o descreve os valores e padr˜es utilizados nos programas para cada teste, al´m ca o e dos parˆmetros de configura¸˜o utilizados no Oprofile Estendido. a ca
1

n/5 foi o valor escolhido. Entretanto, este poderia ser qualquer outro valor, tal como n/3, n/7, etc.

28
... /* aloca o tamanho inicial do buffer */ buffer1 = malloc (n); do { /* repete 500 itera¸~es */ co for (i = 0; i < 500; i ++) /* acessa todo o buffer, p´gina por p´gina */ a a for (size = 0; size < n; size + pagesize) tmp = buffer1[size]; /* incrementa o buffer em uma p´gina para a pr´xima sequ^ncia de 500 a o e acessos */ n+=pagesize; /* separa duas aloca¸~es consecutivas */ co buffer2 = malloc(n/5); /* aloca um buffer novo */ buffer3 = malloc(n); free(buffer2); free(buffer1); /* aponta buffer1 para o buffer rec´m alocado */ e buffer1 = buffer3; } while (n < max); ...

Figura 6.1: C´digo ‘C’ do programa que causa faltas controladas nas TLBs. o

6.2.1

Parˆmetros dos Programas a

Os tamanhos inicial e final do buffer s˜o definidos pelo usu´rio. O programa tamb´m a a e aceita o n´ mero de itera¸˜es que o loop deve executar e o incremento da quantidade de u co p´ginas a cada sequˆncia de itera¸˜es do loop. Em cada experimento, o programa executou a e co 500 itera¸˜es do loop acrescentando 1 p´gina ao buffer a cada sequˆncia de itera¸˜es. co a e co Trˆs medi¸˜es foram realizadas com este programa. A primeira ao percorrer um buffer e co variando entre 0 e 349 p´ginas, na qual foram medidas as faltas nas TLBs de primeiro e a segundo n´ ıveis. A segunda, percorrendo um buffer variando entre 22 e 41 p´ginas em que a foram medidas as faltas na L1 TLB e a terceira, percorrendo um buffer variando de 250 a 279 p´ginas, na qual foram medidas as faltas na L2 TLB. a

29

6.2.2

Configura¸˜o do OProfile Estendido ca

A configura¸˜o utilizada no Oprofile Estendido foi a mesma em todos os testes: (i) Cpu_ ca Clk_Unhalted, 150.000 eventos; (ii) Data_Cache_Accesses, 500.000 eventos; (iii) L1_ Dtlb_Misses_L2_Dtld_Hits, 500.000 eventos; e (iv) L1_And_L2_Dtlb_Misses, 500.000 eventos. A taxa de amostragem ´ definida pelo evento Cpu_Clk_Unhalted. Os demais evene tos est˜o configurados apenas para ajustarem os contadores aos eventos a se monitorar. a Apesar de todos estes eventos serem monitorados em todos os testes, apenas os eventos relevantes a cada teste s˜o apresentados nos resultados. a

6.3 6.3.1

Resultados dos Experimentos Buffer de 0 a 349 p´ginas a

O gr´fico da Figura 6.2 apresenta as faltas ocorridas durante a execu¸˜o do programa a ca percorrendo buffers com tamanho de 0 a 349 p´ginas. A primeira linha vertical s´lida a o demarca a capacidade do buffer em 32 p´ginas, a segunda linha vertical s´lida representa o a o ponto em que o buffer atinge 256 p´ginas e as duas faixas verticais pontilhadas demarcam a o in´ ıcio e o final da execu¸˜o do programa. A linha superior representa as faltas na ca L1d-TLB e a inferior as faltas na L2-TLB – com fator de escala de 0, 186. O degrau nas duas linhas que medem as faltas nas TLBs pr´ximo ao ciclo 2·109 decorre o da execu¸˜o de c´digo do kernel, libc e Oprofile Estendido. Este degrau nas contagens ca o dos eventos associado ` execu¸˜o de c´digo do OProfile indica o momento em que o SO a ca o p´ra a execu¸˜o do programa monitorado e passa a executar o c´digo do OProfile para a ca o sincronizar os buffers do OProfile bem como salvar dados das amostras coletadas. A Tabela 6.1 mostra o que ´ executado pelo processador no trecho do log de amostras e do Oprofile Estendido extra´ do intervalo em que ocorre o degrau. Na primeira coluna da ıdo Tabela 6.1 est˜o os valores referentes ao ciclo em que foi realizada a leitura dos contadores, a na segunda coluna est˜o os nomes dos bin´rios que estavam sendo executados no momento a a da leitura, na terceira, quarta e quinta coluna est˜o os valores ajustados dos contadores que a

30
Faltas na DTLB

2,5e+07

2e+07

Contagem

1,5e+07

1e+07

5e+06

0 0 5e+08 1e+09 1,5e+09 Ciclos L1_DTLB_MISSES_L2_DTLD_HITS L1_AND_L2_DTLB_MISSES: 0,186 Execução Buffer = 32 ou 256 2e+09 2,5e+09 3e+09

Figura 6.2: Faltas na L1 e L2 DTLB percorrendo buffers entre 0 e 349 p´ginas. a

registram os eventos Cpu_Clock_Unhalted, L1_Dtlb_Misses_L2_Dtld_Hits e L1_and_ L2_DTLB_Misses respectivamente. Os nomes dos bin´rios na segunda coluna mostram a que o programa tlb_teste parou de ser executado durante este intervalo da medida, enquanto o Oprofile Estendido realizou a sincroniza¸˜o dos seus registros. ca Sobre o comportamento das faltas na hierarquia de mem´ria apresentado na Figura 6.2, o durante a metade esquerda do gr´fico as faltas na L1 TLB aumentam a partir do ponto a em que o buffer atinge 32 p´ginas – a capacidade da L1 TLB – na primeira linha vertical a s´lida. A partir deste ponto, as faltas nesse n´ continuam ocorrendo na medida em que o ıvel mais e mais p´ginas s˜o alocadas. a a Quando o tamanho do buffer se aproxima da capacidade da L2 TLB, o n´ mero de u faltas naquela aumenta lentamente. Quando a capacidade da L2 ´ ultrapassada – centro e da figura – o n´ mero de faltas na L2 TLB aumenta gradativamente a medida em que u mais p´ginas s˜o alocadas para o buffer, enquanto a contagem de faltas na L1 TLB a a parece diminuir. A redu¸˜o na contagem das faltas na L1 TLB se deve ` pr´pria defini¸˜o do evento ca a o ca

31
Ciclo 2004291143 2004442118 2004455914 2004592743 2004743619 2004894172 2005044853 2005195523 2005346466 2005371143 2014107167 2014258021 2014408780 2014559754 2014645408 2014710594 2014861908 2015012886 2015163807 2015314592 Bin´rio a tlb teste oprofile oprofile oprofile oprofile oprofile vmlinux vmlinux vmlinux oprofile vmlinux libc-2.3.6.so vmlinux libc-2.3.6.so vmlinux oprofiled vmlinux vmlinux vmlinux vmlinux Clock Unhalted 235494181 235548720 235555491 235627403 235710063 235795961 235876816 235960173 236042444 236055612 ... 237882634 237931057 237976297 238020696 238056054 238071539 238133560 238179766 238229001 238274002 L1 M L2 H 20996488 20996736 20996736 20996736 20996736 20996736 20996737 20996738 20996739 20996739 20997489 20997527 20997547 20997582 20997605 20997610 20997652 20997664 20997702 20997721 L1 & L2 M 990284 990402 990404 990410 990416 990423 990430 990448 990457 990458 1016162 1016803 1017637 1018400 1018955 1019272 1020043 1021159 1021916 1023022

Tabela 6.1: Trecho do log do OProfile no qual ocorre o degrau da Figura 6.2.

monitorado, uma vez que ele conta faltas na L1 com acertos na L2 TLB. A partir do momento em que as faltas na L1 n˜o correspondem a acertos na L2, a contagem desses a eventos na L1 tende a diminuir uma vez que aumentam as faltas na L2 TLB. Outro fator que colabora para a redu¸˜o das faltas na L1 TLB na segunda metade do ca experimento ´ o custo mais elevado das faltas na L2: o n´ mero de ciclos decorridos entre e u duas faltas na L2 TLB ´ superior ao de duas faltas na L1 TLB com acertos na L2 TLB. e As faltas na L2 TLB causam uma redu¸˜o na taxa de faltas por ciclos, mas n˜o no total ca a de faltas. O resultado deste experimento coincide com o esperado: enquanto as p´ginas percora ridas s˜o todas mapeadas pela L2 TLB, a taxa de faltas na L1 TLB ´ aproximadamente a e constante. Quando o n´ mero de p´ginas percorridas excede a capacidade da L2 TLB, u a o n´ mero de faltas nesta aumenta gradativamente, assim como diminui a contagem de u faltas na L1 com acertos na L2 TLB. Outro efeito do aumento das faltas na L2 TLB ´ o e aumento do custo relativo de cada falta na L1 TLB.

32
Faltas na L1DTLB 200000

150000

Contagem

100000

50000

0 0 5e+06 1e+07 1,5e+07 2e+07 Ciclos L1_DTLB_MISSES_L2_DTLD_HITS Execução do programa Buffer = 32 2,5e+07 3e+07 3,5e+07

Figura 6.3: Faltas na L1 DTLB percorrendo buffers entre 22 e 41 p´ginas. a

6.3.2

Buffer de 22 a 42 P´ginas a

A Figura 6.3 mostra as faltas ocorridas na L1 DTLB enquanto o programa percorre buffers com tamanhos entre 22 e 41 p´ginas. As linhas verticais pontilhadas representam a o intervalo de tempo em que o programa foi executado e a linha vertical s´lida marca o o ponto em que o buffer atinge o tamanho de 32 p´ginas, que ´ a capacidade da L1 TLB. a e A linha plotada apresenta a contagem de faltas na L1 TLB ao longo da execu¸˜o do ca programa. Como visto no Cap´ ıtulo 5, a hierarquia de TLBs do Athlon possui dois n´ ıveis. A TLB de primeiro n´ ıvel, L1d-TLB cont´m 32 mapeamentos, ´ totalmente associativa com e e ´ reposi¸˜o least recently used (LRU) [19]. E esperado que, antes da utiliza¸˜o de 32 p´ginas, ca ca a cada ciclo de 500 acessos acumule apenas o n´ mero de faltas correspondente ao espa¸o u c alocado: um buffer de 27 p´ginas causa 27 faltas na primeira volta do loop, enquanto que a nas outras 499 voltas nenhuma falta ocorre porque os 27 mapeamentos j´ est˜o carregadas a a na TLB. Acima do limite de 32 p´ginas, espera-se que todos os acessos realizados em todas a

33 as itera¸˜es do loop causem faltas, o que caracteriza o estado de thrashing na L1d-TLB. co Isso ´ esperado porque, sendo a reposi¸˜o por LRU, cada nova p´gina mapeada al´m das e ca a e 32 expurga um mapeamento que ser´ reutilizado em breve. a Considerando que programa usa ao menos uma p´gina adicional para sua pilha, podea se considerar que o limite de thrashing na L1d-TLB ´ 31 p´ginas. Desta forma, o n´ mero e a u de faltas esperado quando o programa de testes percorre de 22 a 31 faltas ´ o somat´rio de e o todos estes valores: 265 faltas. Na segunda metade do experimento, quando s˜o percora ridas de 32 a 41 p´ginas, o valor estimado ´ a soma dos valores do intervalo multiplicado a e pelo n´ mero de itera¸˜es do loop: 182.500 faltas. O total de faltas esperado ´ 182.765 u co e faltas, que ´ a soma dos valores estimados nas duas etapas do teste. e A Figura 6.3 mostra a contagem de faltas na medida em que o tamanho do bloco percorrido aumenta de 22 a 41 p´ginas. Antes da medi¸˜o atingir o ponto de interesse, a ca ap´s a carga do programa, faltas decorrentes da aloca¸˜o da pilha e de dados do programa o ca s˜o registradas, totalizando 1.258 faltas. No momento em que o teste propriamente dito a se inicia, as faltas crescem linearmente com o tamanho da ´rea alocada pois ainda h´ a a registros livres na L1-TLB. Quando s˜o alocadas mais de 28–30 p´ginas, a L1d-TLB a a entra em thrashing, como esperado. Ao final do teste, desprezados os valores anteriores ` a execu¸˜o do programa, s˜o contabilizadas 188.953 faltas, 3% acima do esperado. ca a ´ E importante observar que a estimativa para o n´ mero de faltas n˜o modela fielmente u a o que ocorre no processador, enquanto este executa o programa sobre um SO multitarefa, concorrentemente `s demais aplica¸˜es. A deficiˆncia da estimativa torna-se evidente a co e quando se observa a amplia¸˜o do gr´fico na Figura 6.4: cada flecha indica o tamanho do ca a ´ buffer a ser percorrido (n´ mero de p´ginas). E poss´ observar que entre o regime normal u a ıvel e o de thrashing, h´ um regime intermedi´rio – entre 29 e 31 p´ginas – no qual a taxa a a a de faltas aumenta muito, possivelmente em virtude dos conflitos de mapeamento entre o programa de teste e os demais processos, mas ainda n˜o o suficiente para caracterizar o a thrashing, evidenciado a partir do ponto em que o buffer atinge o tamanho de 32 p´ginas, a quando a inclina¸˜o do gr´fico se aproxima da vertical. ca a ´ E poss´ ıvel observar degraus no gr´fico da Figura 6.4, o que nos permite contar o a

34
Faltas na L1DTLB: Transição até o estado de thrashing 3200

32 2800 31 Contagem 2400 30

2000 29 28

1600

1,2e+07

1,3e+07

1,4e+07

1,5e+07 Ciclos

1,6e+07

1,7e+07

1,8e+07

L1_DTLB_MISSES_L2_DTLD_HITS Execução do programa

Buffer=32

Figura 6.4: Transi¸˜o entre o regime de funcionamento normal e o thrashing na L1 DTLB. ca

n´ mero de faltas para cada tamanho de buffer percorrido. A Tabela 6.2 apresenta a u compara¸˜o entre valores contados nos degraus e os valores estimados para alguns trechos ca da execu¸˜o do programa, e o total de faltas medidas no experimento. ca
Intervalo [p´g] a 23 24 36 37 Total Medido 42 33 18.427 20.197 188.953 Estimado 23 24 18.000 18.500 182.765

Tabela 6.2: Faltas na L1d-TLB.

6.3.3

Buffer de 250 a 280 P´ginas a

O gr´fico na por¸˜o superior da Figura 6.5 mostra as faltas ocorridas na L2 DTLB ena ca quanto o programa percorre buffers com tamanho variando de 250 a 279 p´ginas. As a linhas verticais pontilhadas demarcam o intervalo em que o programa foi executado enquanto a linha vertical s´lida marca o ponto em que o buffer atinge o tamanho de 256 o

35 p´ginas. a No in´ ıcio da execu¸˜o do programa, quando s˜o alocadas 250 p´ginas, a contagem ca a a de faltas na L2 TLB aumenta de forma gradativa, antes mesmo do buffer atingir 256 p´ginas. Isso ocorre porque o programa come¸a a execu¸˜o utilizando um tamanho de a c ca buffer pr´ximo do limite da TLB, o que gera conflitos de mapeamento entre os endere¸os o c utilizados pelo buffer no programa e os endere¸os utilizados pelo SO ou pelos demais c programas em execu¸˜o na m´quina. ca a A partir do momento em que o buffer atinge o tamanho da L2 TLB, a inclina¸˜o da ca linha aumenta a cada incremento no tamanho do buffer. A por¸˜o inferior da Figura 6.5 ca apresenta a amplia¸˜o de um trecho da execu¸˜o no qual ´ poss´ identificar os pontos em ca ca e ıvel que ocorrem aumentos no tamanho do buffer. No gr´fico, cada degrau da linha equivale a a um novo buffer, de tamanho n + 1, percorrido pelo programa. Confirmando a rela¸˜o entre os degraus no gr´fico e o tamanho do buffer no programa, ca a nesta figura ´ poss´ e ıvel contar seis degraus na linha vermelha antes do ponto em que o n´ mero de p´ginas do buffer chega a 256, lembrando que o programa inicia a sua execu¸˜o u a ca com um buffer de 250 p´ginas. Existem 30 degraus ao longo de toda a extens˜o da mesma a a linha, na por¸˜o superior da Figura 6.5. ca Era esperado que a taxa de faltas na L2 TLB apresentasse um comportamento similar ao da L1 TLB na Figura 6.3. Entretanto, comparando as estruturas das duas TLBs, apresentadas no Cap´ ıtulo 5, e verificando o gr´fico de cada uma, conclui-se que a difea ren¸a entre o comportamento das duas TLBs ocorre porque, enquanto a L2 TLB possui c associatividade quatern´ria, a L1 TLB possui associatividade total e reposi¸˜o LRU. a ca Enquanto a L1 TLB se comporta como descrito na Se¸˜o anterior, a L2 TLB mapeia ca 256 p´ginas com associatividade 4, distribuindo-as em 64 linhas, cada uma com 4 possia bilidades de lugar para inserir um dado mapeamento. O local de inser¸˜o varia de acordo ca com o m´todo de reposi¸˜o utilizado. No in´ da execu¸˜o, por ainda haverem registros e ca ıcio ca ` livres na TLB, quase n˜o ocorrem faltas. A medida que o tamanho do buffer aumenta, a a quantidade de faltas cresce lentamente. Quando o tamanho do buffer supera o tamanho da L2 TLB, o reaproveitamento pro-

36
Faltas na L2DTLB 450000

375000

300000 Contagem

225000

150000

75000

0 0 5e+07 1e+08 1,5e+08 2e+08 Ciclos L1_AND_L2_DTLB_MISSES Execução do programa Faltas na L2 TLB 75000 Buffer = 256 2,5e+08 3e+08 3,5e+08

60000

Contagem

45000 5 4 30000 2 1 15000 3

6

0 0 2,5e+07 5e+07 7,5e+07 Ciclos 1e+08 1,25e+08 1,5e+08

L1_AND_L2_DTLB_MISSES Execução do programa

Tamanho do buffer = 256

Figura 6.5: Acima: faltas na L2 DTLB percorrendo buffers entre 250 e 279 p´ginas. Abaixo: a amplia¸˜o do gr´fico demontrando a transi¸˜o entre buffers. ca a ca

37 porcionado pela associatividade quatern´ria da L2 TLB piora e a quantidade de faltas a cresce gradativamente. Caso este experimento fosse executado para um intervalo maior de p´ginas, o ponto a partir do qual a linha plotada no gr´fico se tornasse uma linha reta, a a similar `quela da Figura 6.3, representaria o ponto da execu¸˜o em que a L2 TLB entrou a ca em thrashing. Assim como apresentado para a L1 TLB na Figura 6.3, o estado de thrashing na L2 TLB ´ caracterizado por um aumento no tamanho do buffer sem um aumento proe porcional na inclina¸˜o da reta que representa a contagem de faltas nesta estrutura. Isto ca ocorre quando o limite da TLB ´ excedido ao ponto de n˜o se conseguir mais reaproveie a tar nenhum endere¸o presente nesta estrutura. Deste instante em diante, cada acesso ` c a p´gina do buffer causa uma falta e a contagem de faltas ´ aproximadamente a mesma que a e a contagem de acessos at´ o t´rmino do teste. e e

38

CAP´ ITULO 7 ´ ANALISE DA MULTIPLICACAO DE MATRIZES ¸˜
Programas de multiplica¸˜o de matrizes s˜o simples e tˆm um padr˜o de acessos ` mem´ria ca a e a a o ruim. O acesso aos elementos dispostos em colunas causa faltas na cache a cada elemento acessado. No melhor caso, ao se multiplicar matrizes pequenas, o acesso aos elementos da primeira coluna de uma matriz faz com que os elementos seguintes sejam carregados automaticamente no bloco da cache, reduzindo as faltas compuls´rias nos acessos o subsequentes. ` A medida que o tamanho das matrizes aumenta, os elementos dispostos nas colunas que j´ est˜o carregados na cache conflitam com novos elementos da mesma coluna quando a a a capacidade da cache ´ atingida. Por este motivo, o desempenho do programa piora e drasticamente. Para evitar este comportamento indesejado, existem diferentes otimiza¸˜es co que reduzem conflitos de mapeamento e tiram proveito da hierarquia de mem´ria a fim o de melhorar o tempo de execu¸˜o desses programas. ca O experimento descrito nesta se¸˜o tem como objetivo demonstrar a medi¸˜o de falca ca tas nas caches L1 e L2 do sistema, durante a execu¸˜o de programas de multiplica¸˜o de ca ca matrizes com diferentes n´ ıveis de otimiza¸˜o. Este experimento tamb´m avalia a interca e ferˆncia nas medidas causada pelo Oprofile Estendido durante a execu¸˜o dos testes. A e ca interferˆncia ´ discutida em mais detalhe no Cap´ e e ıtulo 9. Apesar do experimento medir apenas eventos nas caches do sistema, a importˆncia a das TLBs no desempenho dos programas n˜o foi ignorada. Para que a eficiˆncia dos a e programas otimizados seja evidenciada ´ necess´ria a utiliza¸˜o de matrizes de tamanho e a ca superior ` capacidade da L2 TLB do sistema. Dessa forma, o programa que fizer o melhor a uso da hierarquia de mem´ria do processador obter´ desempenho superior. o a Neste experimento foram utilizadas matrizes de 1.024 linhas por 1.024 colunas com elementos do tipo double, ocupando cada matriz 8Mbytes. A L2 TLB do Athlon possui

39 256 elementos [19] para p´ginas de 4Kbytes, totalizando aproximadamente 1Mbyte de a capacidade de mapeamento. A L1 cache do processador possui 512 linhas com dois blocos de 64 bytes cada, totalizando 64Kbytes de capacidade. No caso, uma linha da matriz ocupa 128 blocos da cache em linhas distintas. Quatro programas para a multiplica¸˜o de matrizes foram selecionados para a reaca liza¸˜o deste teste, s˜o eles: (i) Multiplica¸˜o de matrizes convencional, n˜o otimizado; ca a ca a (ii) Multiplica¸˜o de matrizes com padding; (iii) Multiplica¸˜o de matrizes com blocagem; ca ca e (iv) Multiplica¸˜o de matrizes com padding e blocagem. ca

7.1

Estudo das Otimiza¸˜es Testadas co

Esta se¸˜o descreve o funcionamento dos programas de multiplica¸˜o de matrizes e suas ca ca otimiza¸˜es, sob o ponto de vista da hierarquia de mem´ria. co o

7.1.1

Multiplica¸˜o Convencional ca

Boa parte do mau desempenho da multiplica¸˜o de matrizes ´ decorrente de conflitos ca e de endere¸amento entre as matrizes: as posi¸˜es de uma matriz que est˜o sendo acessac co a das num determinado instante podem estar mapeadas na mesma regi˜o da cache que as a posi¸˜es equivalentes das duas outras matrizes envolvidas na multiplica¸˜o. Nesse caso, co ca cada acesso a um determinado elemento de cada matriz pode causar uma falta em qualquer das estruturas da hierarquia de mem´ria, o que anula os benef´ o ıcios de acesso r´pido a proporcionados por esta hierarquia. A Figura 7.1 apresenta o padr˜o de referˆncias acessados durante a multiplica¸˜o de a e ca matrizes quadradas de ordem 64 pelo programa normal em que A × B = C. Cada linha dessas matrizes ocupa 8 linhas da cache e os pontos em vermelho, verde e azul indicam endere¸os das matrizes ‘A’, ‘B’ e ‘C’ respectivamente. O eixo vertical indica a linha da c cache L1 acessada e o eixo horizontal representa o tempo: a cada elemento multiplicado, os endere¸os dos operandos s˜o impressos. Todas as demais figuras referentes a acessos c a de endere¸os seguirem este padr˜o e utilizaram as mesmas matrizes. c a

40

Figura 7.1: Endere¸os acessados na multiplica¸˜o de matrizes convencional. c ca

No programa, para obter o valor de um elemento da coluna ‘C’, ´ preciso que uma e linha inteira de ‘A’ multiplique uma coluna inteira de ‘B’. Na Figura 7.1 observa-se que enquanto as colunas de ‘B’ s˜o acessadas, os pontos do gr´fico que representam o endere¸o a a c de ‘B’ s˜o plotados na vertical pois cada coluna se encontra numa linha de cache diferente. a Enquanto isso, ` medida que a mesma linha de ‘A’ ´ acessada, a varia¸˜o vertical a e ca dos pontos de ‘A’ ´ de 8 linhas, ou a regi˜o ocupada por uma linha da matriz na cache. e a A cada ciclo de multiplica¸˜o de linha de ‘A’ por coluna de ‘B’, um endere¸o de ‘C’ ´ ca c e acessado. Finalmente, a cada 8 endere¸os sequenciais acessados para ‘C’, a linha de cache c do endere¸o de ‘C’ muda. c Este padr˜o de acessos se repete durante toda a execu¸˜o do programa e os pontos a ca do gr´fico nos quais os endere¸os das trˆs matrizes s˜o plotados no mesmo lugar indicam a c e a conflitos de endere¸amento. Neste gr´fico especificamente, nota-se as matrizes ‘A’ e ‘C’ c a est˜o mapeadas nas mesmas linhas da cache, o que causa um constante conflito de ena dere¸os entre as duas matrizes. Dependendo do ciclo da multiplica¸˜o tamb´m ocorrem c ca e conflitos de mapeamento entre as trˆs matrizes. e

41

Figura 7.2: Endere¸os acessados na multiplica¸˜o de matrizes com padding. c ca

7.1.2

Multiplica¸˜o com Padding ca

Para resolver o problema dos conflitos de mapeamento, utiliza-se a t´cnica de padding, e que consiste em separar as faixas de endere¸os das matrizes de forma que elas sejam mac peadas em diferentes linhas de cache. Para isso, entre cada declara¸˜o de matriz que ser´ ca a multiplicada ´ declarado um vetor do tamanho de uma ou mais linhas de cache que n˜o ´ e a e utilizado durante a execu¸˜o do programa. Os vetores vazios deslocam o mapeamento dos ca endere¸os das matrizes, alterando a linha de cache onde elas ser˜o mapeadas e reduzindo c a os conflitos de mem´ria e, consequentemente, o desempenho do programa melhora. A o Figura 7.2 apresenta o padr˜o de acesso de endere¸os do programa que realiza a multia c plica¸˜o de matrizes com padding. Nesta figura ´ poss´ observar que a matriz ‘C’ est´ ca e ıvel a mapeada em linhas de cache distintas das de ‘A’, devido ` separa¸˜o das diagonais que a ca representam os endere¸os dessas matrizes, diferentemente da Figura 7.1. c

42

7.1.3

Multiplica¸˜o com Blocagem ca

Outra forma de melhorar o desempenho da multiplica¸˜o de matrizes ´ aumentar o aproca e veitamento das caches do sistema. Para se obter um linha de ‘C’, uma mesma linha de ‘A’ multiplica cada coluna de ‘B’. Para a pr´xima linha de ‘C’, a mesma linha de ‘A’ o multiplica cada coluna de ‘B’ novamente. Considerando o caso em que as matrizes sejam grande demais para a L1, periodicamente os dados das matrizes s˜o expurgados da cache a e tˆm de ser recuperados na mem´ria principal a cada ciclo de acessos, o que piora o e o desempenho j´ que acessos ` mem´ria s˜o custosos. a a o a A blocagem tira proveito da hierarquia de mem´ria dividindo as matrizes em blocos o de tamanhos menores, compat´ ıveis com o da cache, otimizando a quantidade de opera¸˜es co realizadas entre cada busca de elementos das matrizes na mem´ria principal. O c´digo o o da multiplica¸˜o com blocagem utilizado ´ o mesmo apresentado em [17]. ca e O comportamento dos acessos aos endere¸os ´ similar ao da multiplica¸˜o de matrizes c e ca convencional mas o espa¸o de mem´ria percorrido ´ menor. Na Figura 7.3, ´ poss´ c o e e ıvel observar que o espa¸o vertical representado pelos acessos `s colunas de ‘B’ ocupa apenas c a 256 linhas a cada bloco utilizado ao inv´s de toda a cache. Isso ocorre porque apenas um e bloco da matriz ‘B’ est´ sendo acessado, coluna por coluna, para cada linha dos blocos a de ‘A’ e ‘C’ que s˜o percorridas. Nota-se tamb´m que o tamanho das marcas no gr´fico a e a que representam os acessos a ‘A’ e ‘C’ s˜o menores do que as marcas apresentadas na a Figura 7.1, tamb´m por causa da blocagem j´ que a linha do bloco ´ mais curta do que a e a e linha da matriz. Ainda ´ poss´ visualizar a troca de blocos em ‘C’ durante a execu¸˜o e ıvel ca do programa.

7.1.4

Multiplica¸˜o com Padding e Blocagem ca

´ E poss´ ıvel combinar as duas t´cnicas, separando a faixa de endere¸os das matrizes na e c declara¸˜o para evitar conflitos de mapeamento e utilizando a t´cnica de blocagem para ca e otimizar a utiliza¸˜o da hierarquia de mem´ria. O padr˜o de acessos ` mem´ria durante a ca o a a o multiplica¸˜o das matrizes com a combina¸˜o de padding e blocagem pode ser observado ca ca na Figura 7.4, na qual ´ poss´ verificar o mesmo comportamento da Figura 7.3 mas e ıvel

43

Figura 7.3: Endere¸os acessados na multiplica¸˜o de matrizes com blocagem. c ca

com os endere¸os das linhas de bloco da matriz ‘C’ separados dos da matriz ‘A’. O c´digo c o do programa de multiplica¸˜o com blocagem e padding est´ no Apˆndice B. ca a e

7.2

Prepara¸˜o do Experimento ca

Esta se¸˜o descreve os valores de bloco e padding utilizados nos experimentos de medida ca que definiram os casos a serem estudados, assim como as configura¸˜es utilizadas no co Oprofile Estendido para cada programa monitorado.

7.2.1

Parˆmetros dos Programas a

Trˆs fatores foram levados em conta para a prepara¸˜o dos testes: o tamanho de uma e ca linha da cache do sistema, o tamanho da cache do sistema e o n´ mero de linhas de cache u que uma linha de matriz ocupa. O tamanho da linha da cache do sistema foi utilizado para determinar o tamanho m´ ınimo do padding utilizado na separa¸˜o das matrizes: o tamanho do padding deve ser ca

44

Figura 7.4: Endere¸os acessados na multiplica¸˜o de matrizes com padding e blocagem. c ca

sempre um m´ ltiplo da linha de cache, que tem 64 bytes ou 8 doubles. Dessa forma, u cada in´ de linha da matriz coincide com um in´ de linha de cache, o que otimiza ıcio ıcio o acesso aos dados, uma vez que a carga do primeiro elemento de uma linha de cache resulta na carga antecipada de todos os elementos da mesma linha. Este valor tamb´m e foi utilizado para determinar o passo do aumento do bloco no teste de blocagem: blocos de tamanho m´ ltiplo da linha de cache tamb´m tiram proveito da busca antecipada e u e obt´m um desempenho superior. e O tamanho da cache do sistema foi utilizado para determinar o melhor tamanho de bloco para o programa. O ideal ´ que a cache do sistema comporte os trˆs blocos acessados e e durante cada etapa da multiplica¸˜o. Neste caso, o tamanho m´ximo que um bloco pode ca a ter ´ 48 elementos (48 linhas × 48 colunas × 3 blocos × 8 bytes por elemento = 55.296 e bytes). O pr´ximo valor de bloco a ser testado seria de 56 elementos, o que totaliza um o espa¸o de 75.264 bytes, maior que capacidade da L1 que ´ de 65.536 bytes. c e O n´ mero de linhas de cache ocupadas por uma linha da matriz pode ser utilizado para u definir um tamanho de padding que seja mais apropriado do que o de apenas uma linha

45 da cache. Se o padding n˜o for grande o suficiente para separar as linhas das matrizes ‘A’ a e ‘C’, haver´ na cache uma ´rea de sobreposi¸˜o entre as duas matrizes que ocasionar´ a a ca a faltas por conflito durante a multiplica¸˜o. Se cada linha da matriz ocupa 128 linhas ca de cache, este valor seria suficiente para evitar essa sobreposi¸˜o. Por´m, sendo 128 uma ca e potˆncia de 2, existe a possibilidade dos mapeamentos das matrizes coincidirem na mesma e regi˜o da cache. Por isso, foram utilizados os valores de padding de 133 linhas entre ‘A’ e a ‘B’ e 135 linhas entre ‘B’ e ’C’. Definidos os valores, blocos variando de 0 a 48 elementos e padding escolhido dentre 0, 1 e 133 e 135 linhas, o desempenho dos programas foi medido para cada combina¸˜o ca de parˆmetros. Medidas de tempo foram realizadas durante vinte execu¸˜es de cada um a co dos programas com o utilit´rio time. A m´dia dessas medidas serviu para a defini¸˜o a e ca do tamanho ideal de padding e de bloco utilizados nos programas, de forma que fossem obtidos os menores tempos de execu¸˜o. A partir desses resultados, os programas com ca melhor e pior desempenho foram selecionados para a an´lise com o Oprofile Estendido. a Os resultados das medidas de tempo podem ser vistos na Tabela 7.1, em que a primeira coluna apresenta o tamanho dos blocos utilizados, a segunda coluna apresenta os resultados de tempo para execu¸˜es sem padding, a terceira coluna apresenta os resultaco dos para padding de uma linha de cache entre cada matriz e a quarta coluna o resultado para padding de 133 linhas de cache entre a primeira e a segunda matriz e de 135 entre a segunda e a terceira matriz. A primeira linha da Tabela 7.1 apresenta os tempos em segundos para a multiplica¸˜o ca de matrizes convencional, sem blocagem, para os diferentes valores de padding utilizados. Dos demais valores da tabela ´ poss´ concluir que nem sempre h´ ganho de desempenho e ıvel a utilizando padding diferente de uma linha e que o tamanho ideal de bloco est´ entre 16 e a 32 elementos: valores de bloco maiores ou menores que estes degradam o desempenho do programa neste processador. Para a an´lise com o Oprofile Estendido, cada experimento foi realizado 20 vezes a e os resultados apresentados nos gr´ficos e tabelas das pr´ximas se¸˜es representam a a o co m´dia das 20 execu¸˜es, exceto quando explicitamente mencionado. Os casos selecionados e co

46
Bloco 0 8 16 24 32 40 48 0 214,7 30,6 26,6 25,5 25,7 69,6 107,3 Padding 1 133 e 135 99,8 98,9 30,1 30,3 24,1 24,2 22,7 22,8 22,8 22,3 51,8 25,4 97,7 101,3

Tabela 7.1: Tempo de execu¸˜o da multiplica¸˜o de matrizes variando bloco e padding. ca ca

para a an´lise com o Oprofile Estendido pelo crit´rio do melhor e pior tempo foram a a e multiplica¸˜o convencional, sem otimiza¸˜es e a multiplica¸˜o com padding de 133 e 135 ca co ca linhas e blocos de 32 elementos.

7.2.2

Configura¸˜es do OProfile Estendido co

Os eventos selecionados para a observa¸˜o nesses experimentos foram: (i) Data_Cache_ ca Accesses; (ii) Data_Cache_Refills_from_L2 e; (iii) Data_Cache_Refills_from_System. O contador de ciclos de rel´gio Cpu_Clock_Unhalted foi configurado de acordo com o o tempo de execu¸˜o de cada um dos experimentos de forma que a quantidade de informa¸˜o ca ca registrada pelo Oprofile Estendido seja equivalente. Sendo o tempo m´dio de execu¸˜o do programa de multiplica¸˜o de matrizes normal e ca ca aproximadamente 9 vezes maior do que o tempo m´dio de execu¸˜o da multiplica¸˜o de e ca ca matrizes otimizada, o contador de ciclos foi configurado para interromper o processador a cada 1.800.000 ciclos ativos durante a multiplica¸˜o normal. Na multiplica¸˜o com ca ca padding e blocagem, o valor de overflow do contador foi ajustado em 250.000 ciclos. A diferen¸a entre o valor de leitura da fun¸˜o readtsc() e os valores dos contadores c ca registrados no ciclo de rel´gio mais pr´ximo – do in´ ou do t´rmino da execu¸˜o – do o o ıcio e ca trecho do programa que se quer monitorar n˜o apresenta problemas para a visualiza¸˜o dos a ca dados nos gr´ficos. No entanto, dependendo da frequˆncia da amostragem dos contadores, a e pode-se perder precis˜o na medida da contagem total dos eventos. a Para contornar esse problema e obter as contagens dos eventos monitorados no ponto

47 em que ocorreu a chamada ` fun¸˜o readtsc(), ´ feita uma aproxima¸˜o calculando a a ca e ca varia¸˜o do n´ mero de eventos monitorados em rela¸˜o a varia¸˜o do n´ mero de ciclos ca u ca ` ca u registrados. A varia¸˜o do n´ mero de eventos ´ ent˜o multiplicada pela diferen¸a entre a ca u e a c ultima leitura do TSC ocorrida antes da chamada ` readtsc() e o valor retornado por ´ a esta fun¸˜o. Dessa forma, ´ esperado que se mantenha um grau razo´vel de confiabilidade ca e a na medida mesmo utilizando taxas de amostragem distintas.

7.3

Resultados dos Experimentos

Esta se¸˜o apresenta os resultados dos experimentos assim como algumas solu¸˜es adotaca co das na apresenta¸˜o dos mesmos. ca

7.3.1

Comportamento dos Programas

A multiplica¸˜o convencional apresentou um comportamento bastante est´vel em todas ca a as execu¸˜es. Aparentemente, o uso da hierarquia de mem´ria por esse programa ´ ruim a co o e ponto do seu desempenho n˜o ser prejudicado por interferˆncias do Sistema Operacional a e (SO). No caso da multiplica¸˜o com blocagem e padding, o tempo de execu¸˜o varia ca ca bastante entre as medidas, em raz˜o deste programa tirar um bom proveito da hierarquia a de mem´ria e consequentemente ser mais sens´ `s interferˆncias do SO. o ıvel a e Para contornar o problema da instabilidade nas medidas de tempo da multiplica¸˜o ca com padding e blocagem, foram realizadas, ao inv´s de 20, 60 medidas de execu¸˜o deste e ca programa com o Oprofile Estendido. A execu¸˜o com os valores de ciclos e contagem de ca faltas mais pr´ximas `s das m´dias das 60 medidas foi utilizada para plotar os gr´ficos o a e a apresentados nessa e nas se¸˜es que referenciem este experimento. Os demais dados co apresentados, contagens e taxas, s˜o referentes ` m´dia das contagens das 60 execu¸˜es. a a e co Nos gr´ficos que apresentam as medidas do Oprofile Estendido para cada programa a monitorado, a primeira linha da legenda representa os acessos ` cache L1, a segunda linha a representa as faltas ocorridas na L1 que corresponderam a acertos na L2, a terceira linha representa as faltas da L1 que ocasionaram faltas na L2, a quarta linha indica o in´ e ıcio

48 o final da execu¸˜o do programa e os eixos X e Y representam os ciclos de rel´gio e a ca o contagem de eventos respectivamente. Os valores apresentados ao lado de cada linha na legenda indicam os fatores de ajuste de cada uma, que ´ o valor pelo qual a linha deve ser multiplicada para que ela entre na e sua escala normal. A linha de evento sem fator de ajuste apresenta a contagem do evento obtida diretamente atrav´s do Oprofile Estendido. e

7.3.2

Contagem dos Eventos

Apesar do programa de multiplica¸˜o otimizado ser 8,5 vezes mais r´pido do que o proca a grama normal, os gr´ficos plotados a partir do registro do Oprofile Estendido para os dois a programas s˜o praticamente iguais, a menos dos valores das contagens de eventos e os a fatores de ajuste apresentados em cada legenda dos gr´ficos da Figura 7.5. Em princ´ a ıpio, n˜o h´ evidˆncia visual que justifique a diferen¸a de desempenho entre os programas al´m a a e c e da discreta separa¸˜o entre a linha que conta os acessos ` cache e as linhas que contam ca a as faltas nessa estrutura, que pode ser observada na por¸˜o inferior da Figura 7.5. ca Os valores aproximados das medidas obtidas no registro do Oprofile Estendido s˜o a mostrados na Tabela 7.2. Nessa tabela, a primeira coluna apresenta os tipos de programas estudados, a segunda coluna o total de ciclos, a terceira coluna os acessos ` cache a (Data_Cache_Accesses), a quarta e quinta colunas apresentam as recargas oriundas da L2 (Data_Cache_Refills_from_L2) e do sistema (Data_Cache_Refills_from_System) respectivamente. O total de faltas na L1 ´ calculado a partir da soma das recargas proe venientes da L2 e do sistema. Analisando as contagens dos eventos, a multiplica¸˜o normal realiza pouco mais do ca que a metade dos acessos ` cache efetuados pela multiplica¸˜o otimizada. Ainda assim, a a ca multiplica¸˜o normal precisa de uma quantidade de ciclos 8,5 vezes maior que a utilizada ca
Programa Convencional Otimizado Ciclos 4,32 · 1011 5,05 · 1010 Acessos ` L1 a 1,66 · 1010 2,96 · 1010 Faltas na L1 2,15 · 109 1,06 · 109 L1 ← L2 1,08 · 109 1,03 · 109 L1 ← sistema 1,07 · 109 3,4 · 107

Tabela 7.2: Contagem dos eventos para os programas de multiplica¸˜o de matrizes. ca

49
Mmatriz convencional 1,8e+10 1,6e+10 1,4e+10 1,2e+10 Contagem 1e+10 8e+09 6e+09 4e+09 2e+09 0 0 5e+10 1e+11 1,5e+11 2e+11 Ciclos DATA_CACHE_ACCESSES DATA_CACHE_REFILLS_FROM_L2: 0,064 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,064 Execução Mmatriz com padding e blocagem 3e+10 2,5e+11 3e+11 3,5e+11 4e+11

2,5e+10

2e+10 Contagem

1,5e+10

1e+10

5e+09

0 0 1e+10 2e+10 Ciclos DATA_CACHE_ACCESSES DATA_CACHE_REFILLS_FROM_L2: 0,034 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,0008 Execução 3e+10 4e+10 5e+10

Figura 7.5: Monitoramento da cache de dados durante a multiplica¸˜o convencional ca (acima) e a multiplica¸˜o com padding e blocagem. ca

50 pelo programa otimizado. No caso, a multiplica¸˜o normal realiza acessos ` cache a uma ca a taxa de 0,038 acessos para cada ciclo de rel´gio enquanto a multiplica¸˜o otimizada atinge o ca a taxa de 0,586 acessos por ciclo. Este aumento na taxa de acessos ocorre porque, na multiplica¸˜o otimizada, al´m dos dados serem acessados de maneira diferente, a maioria ca e das faltas na cache L1 resultam em acertos na cache L2. Sendo os acessos ` L2 mais a r´pidos do que os acessos ` mem´ria principal, o n´ mero de ciclos em que o processador a a o u fica parado aguardando os dados da mem´ria ´ menor no programa otimizado. o e Na multiplica¸˜o normal, 12,9% dos acessos ` cache L1 realizados resultam em faltas. ca a Deste percentual, 50,4% s˜o repostos pela L2 e 49,6% pelo sistema de mem´ria. No caso a o do programa otimizado, 3,5% dos acessos ` L1 resultam em faltas, das quais 97,1% s˜o a a repostos pela L2 e 2,9% pelo sistema, indicando uma melhora significativa na utiliza¸˜o ca da L2 e, consequentemente, no desempenho do programa. O ganho de desempenho ocorre porque o processador ´ capaz de continuar executando outras instru¸˜es, independentes e co dos dados faltantes, enquanto espera por uma recarga da L2 [17]. Os dados apresentados nesta se¸˜o foram obtidos a partir do registro do Oprofile Esca tendido. As mesmas informa¸˜es tamb´m podem ser obtidas com o Oprofile convencional. co e Entretanto, h´ uma varia¸˜o entre as medidas destas ferramentas – que ocorre em fun¸˜o a ca ca da natureza do m´todo de amostragem de cada uma – que pode alterar os resultados, e comprometendo a precis˜o da medida do Oprofile. As diferen¸as entre as medidas realia c zadas com o Oprofile Estendido e o Oprofile, bem como as suas causas s˜o discutidas no a Cap´ ıtulo 10.

7.3.3

Utiliza¸˜o da Hierarquia de Mem´ria ca o

Ampliando um pequeno trecho da execu¸˜o de cada um dos gr´ficos da Figura 7.5, ´ ca a e poss´ observar as diferen¸as entre o comportamento de cada programa durante a fase da ıvel c execu¸˜o mostrada no intervalo da amplia¸˜o. Na multiplica¸˜o convencional, mostrada ca ca ca na Figura 7.6 (topo) nota-se que enquanto os acessos ` cache s˜o relativamente constantes, a a os refills provenientes da L2 ocorrem numa taxa mais baixa do que os 6,4% indicados no fator de ajuste, salvo quando ocorrem pequenos degraus verticais na linha que representa

51 este evento. A linha que representa as recargas ` L1 provenientes do sistema apresenta uma eleva¸˜o a ca pouco superior aos 6,4% indicados na legenda, mas ela apresenta discretos degraus horizontais nos mesmos pontos em que a linha que representa as recargas da L2 apresenta os ` degraus verticais. A exce¸˜o dessa perturba¸˜o peri´dica, o comportamento dos eventos ca ca o n˜o apresenta qualquer varia¸˜o devido ao padr˜o de acessos ` mem´ria realizado pelo a ca a a o programa. A quantidade de conflitos de endere¸os ocorridos ao longo da execu¸˜o do c ca programa ´ constante. e Uma an´lise do registro do Oprofile Estendido nos trechos onde ocorrem as pera turba¸˜es indica que esta altera¸˜o no comportamento dos programas ´ decorrente de co ca e uma descarga (dump) dos buffers do Oprofile Estendido. Nesta se¸˜o, esta interferˆncia ca e ser´ utilizada como referˆncia na compara¸˜o entre a utiliza¸˜o da mem´ria dos dois a e ca ca o programas. No Cap´ ıtulo 9 ser´ apresentada uma an´lise mais detalhada da interferˆncia. a a e No caso da multiplica¸˜o otimizada, enquanto os acessos a cache ocorrem com taxa ca ` aparentemente constante, as recargas provenientes da L2 oscilam na faixa dos 3,4% ´ (por¸˜o inferior da Figura 7.6). E poss´ ca ıvel perceber um padr˜o na oscila¸˜o da linha, a ca ocasionado pelas fases da blocagem durante a execu¸˜o do programa. Um comportaca mento semelhante ´ apresentado pela linha que representa as recargas da L1 pelo sistema, e que oscila na faixa de 0,08% em rela¸˜o aos acessos ` cache. ca a Esta oscila¸˜o reflete o comportamento das faltas na cache ` medida que as colunas de ca a um mesmo bloco b1 s˜o multiplicadas pelas linhas de outro bloco b2. Enquanto a faixa de a endere¸os ocupada por b1, que est´ sendo acessada coluna a coluna permanece constante, c a o bloco b2, que ´ percorrido linha por linha, ocupa da primeira ` ultima linha da matriz. e a´ Dessa forma, o tempo gasto para cada linha de b2 que ´ carregada na cache ´ compensado e e multiplicando-se a linha pelas colunas de b1 que j´ est˜o carregadas na cache. a a Devido ao comportamento do programa e ao tamanho das matrizes, ocorrem conflitos de endere¸amento entre as pr´prias colunas de b1. Pode tamb´m ocorrer de a linha de b2 c o e estar no mesmo endere¸o de algum outro dado utilizado. Esses conflitos de endere¸amento c c refletem os trechos com maior inclina¸˜o nas linhas que indicam as recargas na L1. Por ca

52
Mmatriz convencional 9,4e+09 9,2e+09 9e+09 8,8e+09 Contagem 8,6e+09 8,4e+09 8,2e+09 8e+09 7,8e+09 2,05e+11 2,1e+11 2,15e+11 2,2e+11 Ciclos DATA_CACHE_ACCESSES DATA_CACHE_REFILLS_FROM_L2: 0,064 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,064 Execução Mmatriz com padding e blocagem 2,25e+11 2,3e+11 2,35e+11 2,4e+11

1e+10

9e+09 Contagem

8e+09

7e+09

6e+09

1e+10

1,1e+10

1,2e+10

1,3e+10

1,4e+10 Ciclos

1,5e+10

1,6e+10

1,7e+10

1,8e+10

DATA_CACHE_ACCESSES DATA_CACHE_REFILLS_FROM_L2: 0,034 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,0008 Execução

Figura 7.6: Comportamento dos eventos durante a multiplica¸˜o convencional (acima) e ca a otimizada.

53 serem usados conjuntos pequenos de dados na blocagem, a grande maioria das faltas na L1 s˜o preenchidas por dados da L2. a Al´m desses conflitos, ` medida que os blocos da matriz que est˜o sendo percorridos e a a linha a linha s˜o trocados por outros, podem ocorrer sobreposi¸˜es entre os endere¸os de a co c cache ocupados pelos os novos blocos da matriz e os endere¸os ocupados por b1. Ao longo c da execu¸˜o do programa, ` medida que os blocos das matrizes se movimentam pelas ca a linhas da cache, as faltas causadas pelos blocos sobrepostos causam a discreta ondula¸˜o ca nas linhas que medem as reposi¸˜es das faltas na L1, mostrada na por¸˜o inferior da co ca Figura 7.5. ´ E poss´ ainda observar que, al´m do padr˜o ondulado apresentado nas linhas que ıvel e a contam as recargas na L1, h´ tamb´m a interferˆncia peri´dica causada pelo Oprofile Esa e e o tendido – semelhante ` interferˆncia da multiplica¸˜o convencional – representada por um a e ca degrau horizontal na linha das recargas vindas do sistema e por uma inclina¸˜o cont´ ca ınua na linha das recargas pela L2 nos mesmos pontos. A por¸˜o superior da Figura 7.7 mostra ca a amplia¸˜o de um trecho da interferˆncia ocorrida no programa de multiplica¸˜o convenca e ca cional, onde ´ poss´ observar claramente que enquanto os acessos ` cache permanecem e ıvel a est´veis, o n´ mero de recargas provenientes da L2 aumenta rapidamente e as recargas do a u sistema permanecem est´veis durante o mesmo per´ a ıodo. Uma amplia¸˜o semelhante para a multiplica¸˜o otimizada ´ mostrada na parte inferior ca ca e da Figura 7.7. Os eventos nesse gr´fico aparentemente apresentam o mesmo comportaa mento: h´ um aumento, ainda que leve, na inclina¸˜o da linha que mede os acertos na L2 a ca e uma redu¸˜o na inclina¸˜o da linha que mede as faltas na L2. No trecho em que ocorre ca ca essa oscila¸˜o, a linha que mede os acessos ` cache permanece constante. ca a Analisando a Figura 7.7 ´ poss´ comparar visualmente a utiliza¸˜o da cache L2 pelos e ıvel ca dois programas, tomando como referˆncia a perturba¸˜o causada pelo Oprofile Estendido. e ca Observando-se o aumento da inclina¸˜o na linha que mede as recargas provenientes da L2 ca durante o dump do Oprofile Estendido, constata-se que utiliza¸˜o da L2 na multiplica¸˜o ca ca convencional ´ pior do que a utiliza¸˜o da L2 durante a execu¸˜o do Oprofile Estendido. e ca ca No caso da multiplica¸˜o otimizada, ocorre uma perturba¸˜o nas recargas da L2, mas a ca ca

54

Mmatriz convencional

9,3e+09

9,28e+09 Contagem

9,26e+09

9,24e+09

9,22e+09

2,404e+11

2,405e+11

2,406e+11 Ciclos

2,407e+11

2,408e+11

DATA_CACHE_ACCESSES DATA_CACHE_REFILLS_FROM_L2: 0,064 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,064 Execução Mmatriz com padding e blocagem 2,13e+10

2,12e+10

2,11e+10 Contagem

2,1e+10

2,09e+10

2,08e+10 3,49e+10 3,495e+10 3,5e+10 3,505e+10 Ciclos 3,51e+10 3,515e+10 3,52e+10

DATA_CACHE_ACCESSES DATA_CACHE_REFILLS_FROM_L2: 0,034 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,0008 Execução

Figura 7.7: Interferˆncia durante a multiplica¸˜o de matrizes convencional (topo) e a otimizada. e ca

55 inclina¸˜o da linha que mede estas recargas quase n˜o se altera. Disto constata-se que a ca a utiliza¸˜o da L2 ´ similar entre o programa otimizado e o Oprofile Estendido. Maiores ca e detalhes referentes aos valores das taxas dos eventos medidos em cada programa s˜o a apresentados na pr´xima se¸˜o. o ca Todos os dados e figuras apresentados nesta se¸˜o foram obtidos a partir do registro ca do Oprofile Estendido – n˜o sendo poss´ a ıvel obter estes mesmos dados com o Oprofile – e auxiliam a compreens˜o do funcionamento da hierarquia de mem´ria do processador a o durante a execu¸˜o de cada um dos programas de multiplica¸˜o de matrizes. Com a ca ca distribui¸˜o temporal da contagem de eventos, ´ poss´ observar e deduzir os est´gios ca e ıvel a da multiplica¸˜o das matrizes bem como o comportamento da hierarquia de mem´ria em ca o cada um destes est´gios. a

7.3.4

An´lise das Taxas dos Eventos Medidos a

Os resultados apresentados na Se¸˜o 7.3.2 mostram as contagens de acessos, de faltas e de ca algumas taxas obtidas durante a execu¸˜o dos dois experimentos sem apresentar a varia¸˜o ca ca delas ao longo do tempo. Os resultados da Se¸˜o 7.3.3 apresentam essa varia¸˜o nos ca ca eventos ao longo do tempo, mas devido ao fator de ajuste das linhas, ´ dif´ estabelecer e ıcil valores mais precisos nas varia¸˜es dos eventos ao longo da execu¸˜o dos programas. co ca Para complementar as informa¸˜es das se¸˜es anteriores, as taxas das medidas dos co co experimentos foram calculadas, dividindo as varia¸˜es (∆1 ) de um evento por outro, co seguindo as mesmas m´tricas dos resultados j´ apresentados: a taxa dos acessos ` cache ´ e a a e ∆Data_Cache_Accesses/∆Ciclos, a de acertos na L2 ´ ∆Data_Cache_Refills_from_ e L2/∆Data_Cache_Accesses, enquanto a taxa das faltas na L2 ´ ∆Data_Cache_Refills_ e from_System/∆Data_Cache_Accesses. Em todos os gr´ficos apresentados nesta se¸˜o, o eixo Y apresenta a varia¸˜o da taxa a ca ca da medida, o eixo X representa a contagem dos ciclos de rel´gio ao longo do tempo, o os pontos correspondem aos valores da m´trica para cada ∆ ciclo amostrado e as linhas e verticais pontilhadas indicam o in´ e o fim da execu¸˜o do programa. ıcio ca
1

∆x = ...x2 − x1 , x3 − x2 ..., ∆y = ...y2 − y1 , y3 − y2 ..., sendo x e y eventos plotados nos eixos x e y.

56

Figura 7.8: Acessos ` cache por ciclos de rel´gio na multiplica¸˜o convencional (acima) e a o ca na com padding e blocagem.

57 A an´lise da taxa dos acessos ` cache por intervalo pode ser observada no topo da a a Figura 7.8 para a multiplica¸˜o convencional. O gr´fico, mostra que na maior parte do ca a tempo de execu¸˜o do programa a taxa de acessos por ciclo ´ de 0,035. Numa frequˆncia ca e e bem mais baixa ocorre tamb´m uma convergˆncia do valor da taxa de acessos em 0,076. e e A taxa mais baixa representa os acessos `s colunas da matriz enquanto a taxa mais a alta representa os acessos `s linhas da matriz, situa¸˜o em que ´ poss´ a ca e ıvel obter algum reaproveitamento dos dados nas caches. Nos curtos intervalos em que a taxa oscila entre 0,6 e 0,75 ocorre a interferˆncia causada pelo dump do Oprofile Estendido. e Para o caso da multiplica¸˜o com padding e blocagem, apresentado na Figura 7.8, a ca maior parte dos acessos ` L1 ocorrem na faixa entre 0,68 e 0,7 acessos por ciclo. Logo a abaixo h´ um outro patamar menos denso entre 0,62 e 0,63. Possivelmente esses patamares a tamb´m indiquem os acessos da linha do bloco da matriz e da coluna do bloco da matriz e durante cada fase da multiplica¸˜o. As demais concentra¸˜es de pontos abaixo desses ca co valores indicam as interferˆncias entre os blocos que causam as oscila¸˜es das faltas na L1 e co e na L2. Os intervalos com pontos acima de 0,7 s˜o causados tamb´m pela interferˆncia a e e do daemon do Oprofile Estendido. A redu¸˜o da taxa de acertos na L2 por acessos ` cache pode significar duas coisas: ca a (i) que a taxa de acertos na L1 aumentou; (ii) que as faltas na L2 aumentaram. Por isso, para complementar o estudo do comportamento dos acertos na L2, os gr´ficos contidos a na Figura 7.9 apresentam as faltas por acesso na L1, plotadas em vermelho, e os acertos na L2, plotados em verde. Dessa forma, ´ poss´ e ıvel estabelecer a origem da causa da diminui¸˜o nas faltas na L2. ca Os acertos por acesso na L2 – plotados em verde – para a multiplica¸˜o convencional se ca mant´m na faixa dos 0,07 como mostrado no topo da Figura 7.9. Tamb´m ´ poss´ obe e e ıvel servar mais trˆs faixas de valores nas quais ocorrem convergˆncias dos pontos: a primeira e e em 0,033, a segunda em 0,072 e a terceira em 0,085. Em raz˜o da densidade das trˆs faixas de valores ser parecida, al´m de baixa, ´ dif´ esa e e e ıcil tabelecer uma correla¸˜o entre elas e as fases da multiplica¸˜o das matrizes. Comparandoca ca se a taxa de acertos na L2, que oscila em 0,033, com a taxa de faltas na L1 (em vermelho),

58

Figura 7.9: Acertos na L2 por acessos ` cache na multiplica¸˜o convencional (acima) e a ca na multiplica¸˜o com padding e blocagem. ca

59 em 0,064, ´ poss´ associar a redu¸˜o dos acertos na L2 com a redu¸˜o das faltas na L1. e ıvel ca ca Dessa associa¸˜o, ´ poss´ relacionar a faixa mais baixa de valores de recargas da L2 a ca e ıvel acessos `s linhas da matriz e a faixa superior aos acessos `s colunas da matriz. a a As faltas na L1 (em vermelho), que oscilam em torno de 0,154, causam a eleva¸˜o ca da taxa dos acertos na L2 (em verde) para 0,085. Considerando o tamanho da L2 e o tamanho do conjunto de trabalho utilizado para acessar as colunas da matriz, ´ muito e dif´ atribuir os acertos na L2 ao acesso de colunas e, portanto, essas taxas tamb´m ıcil e devem ser atribu´ ıdas aos acessos `s linhas da matriz. a Os demais acessos e faltas realizados pelo programa, faltas na L1 na faixa de 0,142 com acertos na L2 na faixa de 0,072 representam os acessos `s colunas da matriz. A a pequena separa¸˜o entre na faixa plotada em 0,072 pode representar alguma melhoria ca no reaproveitamento de dados das colunas, mas ainda nada que represente um ganho de desempenho significativo. O valor da taxa de acertos na L2 oscila entre 0,035 e 0,036 para a multiplica¸˜o ca otimizada, na por¸˜o inferior da Figura 7.9. Os picos pouco acima dessa faixa n˜o s˜o ca a a causados por interferˆncias, mas pelo pr´prio programa. Ocorre ainda uma pequena e o concentra¸˜o em 0,005, decorrente de um aumento nos acertos da L1, como pode ser ca verificado pela redu¸˜o da taxa de faltas. ca Ainda sobre a taxa de faltas, ´ poss´ perceber que apesar da sua varia¸˜o, os acertos e ıvel ca na L2 permanecem em um n´ constante. Os picos na taxa de faltas entre 0,04 e 0,05 ıvel causam uma redu¸˜o quase impercept´ ca ıvel na taxa de acertos da L2. As faltas na L1 causadas pelo Oprofile Estendido que elevam a taxa acima de 0,065 causam um aumento na taxa dos acertos na L2 para 0,062 enquanto as que reduzem a taxa de faltas para quase 0 tamb´m reduzem os acertos. e A an´lise da taxa das recargas provenientes do sistema por acesso ` cache pode ser a a observada no topo da Figura 7.10 para a multiplica¸˜o convencional. O gr´fico mostra ca a que, na maior parte do tempo, a taxa de faltas na L2 ´ de 0,07. H´ tamb´m um patamar e a e na taxa de acessos em 0,03. A taxa mais alta representa os acessos `s colunas da matriz a enquanto a taxa mais baixa representa os acessos `s linhas da matriz, nos quais ´ poss´ a e ıvel

60 obter algum reaproveitamento dos dados na L2. As falhas peri´dicas na faixa inferior o de pontos representam a interferˆncia do Oprofile Estendido, comprovada comparando o e n´ mero de falhas com a ocorrˆncia dos dumps indicada no registro do Oprofile Estendido. u e Para a multiplica¸˜o com padding e blocagem, na parte inferior da Figura 7.10, a ca maior parte das faltas na L2 ocorrem numa faixa muito pr´xima de 0. Pouco acima dessa o primeira faixa h´ outro patamar discreto. Estes patamares indicam os acessos da linha a do bloco da matriz e da coluna do bloco da matriz durante cada fase da multiplica¸˜o. ca As concentra¸˜es de pontos acima desses valores indicam as interferˆncias entre os blocos co e que causam as faltas na L2. Os dois gr´ficos da Figura 7.10 apresentam um comportamento inverso aos gr´ficos a a correspondentes, apresentados na Figura 7.8. As faltas na L2 interferem diretamente na taxa dos acessos ` cache, uma vez que a penalidade de uma falta nesse n´ da hierarquia a ıvel de mem´ria pode bloquear os acessos subsequentes at´ que o dado que ocasionou a falta o e seja recuperado da mem´ria principal. o Na por¸˜o inferior da Figura 7.10 ´ poss´ identificar trˆs fases distintas na concenca e ıvel e tra¸˜o de pontos entre 0,005 e 0,01. Estas mesmas fases podem ser observadas na por¸˜o ca ca inferior da Figura 7.5, em que a discreta varia¸˜o na inclina¸˜o das linhas que medem os ca ca eventos Data_Cache_Refills_from_L1 e Data_Cache_Refills_from_System representa a oscila¸˜o da taxa de faltas ao longo das trˆs fases. Esta varia¸˜o pode ocorrer devido a ca e ca um padr˜o de sobreposi¸˜o dos blocos das matrizes na hierarquia de mem´ria do sistema, a ca o ou por um padr˜o de interferˆncia causada pelo SO ao longo da execu¸˜o do programa. a e ca Um estudo dos padr˜es de acesso aos endere¸os em mem´ria, similar ao apresentado na o c o Figura 7.4 (p´gina 44), pode revelar o que ocorre na mem´ria durante as diferentes fases a o no comportamento das faltas. Entretanto, tal estudo em uma matriz de 1.024×1.024 elementos resulta em 1.0243 × 3 endere¸os para plotar no gr´fico – aproximadamente c a 24Gbytes – o que inviabiliza a gera¸˜o do gr´fico. ca a Os dados e figuras apresentados nesta se¸˜o complementam os dados apresentados nas ca se¸˜es anteriores e tamb´m foram obtidos a partir do registro do Oprofile Estendido. N˜o co e a conhecemos nenhuma outra ferramenta que disponibilize dados suficientes para plotar

61

Figura 7.10: Faltas na L2 por acessos ` cache na multiplica¸˜o convencional e na blocada. a ca

62 gr´ficos de eventosXciclo ou taxaXciclo. A distribui¸˜o temporal das taxas dos eventos a ca monitorados auxiliam na compreens˜o do comportamento da hierarquia de mem´ria dos a o dois programas de multiplica¸˜o de matrizes, al´m de fornecer informa¸˜es das taxas de ca e co faltas para cada etapa da execu¸˜o dos programas, ao inv´s de apenas um histograma ou ca e de uma m´dia das taxas de faltas das execu¸˜es dos programas. e co

63

CAP´ ITULO 8 ´ ANALISE DO MERGESORT
Este cap´ ıtulo descreve um conjunto de experimentos para determinar o comportamento da hierarquia de mem´ria durante a execu¸˜o de programas que implementam duas vers˜es o ca o do algoritmo de ordena¸˜o Mergesort. A primeira ´ uma implementa¸˜o simples do algoca e ca ritmo Mergesort e a segunda ´ uma vers˜o otimizada para tirar proveito da hierarquia de e a mem´ria, chamada de Tiled Mergesort. o

8.1

Descri¸˜o dos Programas ca

A primeira vers˜o do Mergesort ordena um vetor dividindo-o ao meio e fazendo uma a chamada recursiva da pr´pria fun¸˜o de ordena¸˜o para uma metade do vetor. Essas o ca ca chamadas se repetem at´ que o vetor tenha apenas um elemento. Neste ponto, a recurs˜o e a volta um est´gio e ´ realizada uma chamada para a outra metade do vetor. Na volta da a e segunda recurs˜o ´ chamada uma fun¸˜o que agrega as duas metades do vetor de forma a e ca ordenada, sobre o vetor original, com o aux´ de um segundo vetor denominado vetor ılio de resultado. O segundo algoritmo, Tiled Mergesort, ´ uma vers˜o do Mergesort convencional em e a que as chamadas recursivas sobre as metades do vetor param quando o vetor atinge o tamanho da cache da m´quina. Neste ponto (da recurs˜o) ´ utilizado outro algoritmo de a a e ordena¸˜o, para que se tire proveito da localidade espacial dos dados em cache. O outro ca algoritmo utilizado nesta implementa¸˜o do Tiled Mergesort ´ o Quicksort. ca e O Quicksort ´ um algoritmo que ordena um vetor selecionando um elemento, denoe minado pivˆ, e ordenando os demais componentes do vetor de forma que os elementos o menores do que o pivˆ sejam posicionados antes dele e os maiores sejam posicionados o ap´s ele. O processo se repete recursivamente para os subvetores ` esquerda do pivˆ, at´ o a o e que o subvetor possua apenas um elemento. Neste ponto, a recurs˜o retorna um n´ e a ıvel

64 a metade direita do subvetor ´ ordenada atrav´s do mesmo processo. Este procedimento e e se repete at´ o retorno de todos os n´ e ıveis da recurs˜o. a

8.2

Prepara¸˜o do Experimento ca

Esta se¸˜o descreve os valores utilizados nos programas para cada teste, al´m dos parˆmetros ca e a de configura¸˜o utilizados no Oprofile Estendido. ca

8.2.1

Parˆmetros dos Programas a

Os dois programas estudados ordenam o mesmo vetor, de 819.200 elementos do tipo double. Este vetor ocupa um espa¸o de 6 Mbytes na mem´ria e portanto, ´ maior do que c o e a capacidade da L1 (1.000 ×), da L2 (25 ×), da L1dTLB (50 ×) e da L2dTLB (6 ×). Este tamanho de vetor foi utilizado para que a cada execu¸˜o da medida, os dados presentes ca nas caches e TLBs do sistema n˜o fossem reaproveitados. Os resultados apresentados nos a gr´ficos e tabelas dessa se¸˜o correspondem ` m´dia de 20 execu¸˜es de cada teste. a ca a e co O vetor utilizado nos programas foi gerado com a fun¸˜o random() e salvo em um ca arquivo ‘.c’. Este vetor foi compilado ` parte e o seu arquivo objeto foi ligado aos proa gramas Mergesort e Tiled Mergesort. N˜o foi utilizado um arquivo separado contendo o a vetor porque a leitura desses dados causaria interferˆncias indesejadas dos acessos a disco. e Cada programa de ordena¸˜o estudado foi monitorado durante a execu¸˜o com o ca ca mesmo tamanho da faixa de trabalho na qual o Quicksort era utilizado. A faixa utilizada tem o tamanho da cache L2 do processador. A fun¸˜o readtsc() foi utilizada nesse teste ca para demarcar o in´ e o final da execu¸˜o de cada programa, assim como o ponto da ıcio ca ordena¸˜o em que o Tiled Mergesort inicia a execu¸˜o da fun¸˜o quicksort(). O ponto ca ca ca equivalente no Mergesort convencional tamb´m ´ demarcado pela fun¸˜o readtsc(), al´m e e ca e das chamadas ` fun¸˜o merge(), que agrega dois vetores rec´m ordenados. a ca e ´ E importante frisar que, devido ` forma com que os vetores s˜o manipulados pelo a a Mergesort, o trecho delimitado pelas linhas verticais que destaca o momento em que a fun¸˜o quicksort() ´ executada, demarca duas execu¸˜es da fun¸˜o – quicksort() ca e co ca

65 Programa Mergesort Tiled Mergesort Diferen¸a Percentual c N´ mero de ciclos u 1,252·109 1,111·109 12%

Tabela 8.1: Contagem de ciclos para os programas de ordena¸˜o. ca

ou mergesort() – uma para cada vetor do tamanho da cache L2. Esta abordagem, de delimitar duas execu¸˜es de cada fun¸˜o, foi utilizada por ser mais simples de se co ca implementar de forma correta do que a abordagem que delimita apenas uma execu¸˜o ca das fun¸˜es de ordena¸˜o. co ca

8.2.2

Configura¸˜es do OProfile Estendido co

Os eventos monitorados com o Oprofile Estendido durante a execu¸˜o dos programas ca de ordena¸˜o Mergesort e Tiled Mergesort foram: (i) Data_Cache_Accesses; (ii) Data_ ca Cache_Misses; e (iii) Data_Cache_Refills_From_System, ou faltas na L2. Em princ´ ıpio, o contador de ciclos (Cpu_Clock_Unhalted) seria ajustado de acordo com o tempo de execu¸˜o de cada um dos testes, de forma que a quantidade de informa¸˜o ca ca registrada pelo Oprofile Estendido fosse equivalente nos dois experimentos. Entretanto, uma vez que a diferen¸a no tempo de execu¸˜o dos programas ´ da ordem de 12%, como c ca e mostrado na Tabela 8.1, optou-se por utilizar a mesma configura¸˜o para todos os testes ca de ordena¸˜o. ca O contador de ciclos de rel´gio Cpu_Clock_Unhalted foi configurado para interromper o o processador a cada 75.000 ciclos e os demais contadores foram configurados para entrar em overflow a cada 231 − 1 eventos, o que equivale a n˜o entrarem em overflow. a A diferen¸a entre o valor de leitura da fun¸˜o readtsc() e os valores dos contadores c ca registrados no ciclo de rel´gio mais pr´ximo – do in´ ou do t´rmino da execu¸˜o – do o o ıcio e ca trecho do programa que se quer monitorar n˜o apresenta problemas para a visualiza¸˜o a ca dos dados nos gr´ficos. Dependendo da frequˆncia da amostragem dos contadores, pode-se a e perder precis˜o na medida da contagem total dos eventos. Quanto mais baixa a amosa tragem maior ser´ o tempo – e a quantidade de eventos ocorridos mas n˜o registrados – a a

66 decorrido entre a ultima amostra coletada e a chamada da fun¸˜o readtsc(). Quanto ´ ca mais curto o tempo de execu¸˜o do experimento, maior a sensibilidade dos dados ` baixa ca a taxa de amostragem. Para contornar este problema e obter as contagens dos eventos monitorados no ponto em que ocorreu a chamada ` fun¸˜o readtsc(), ´ feita uma aproxima¸˜o calculando-se a a ca e ca varia¸˜o da contagem dos eventos monitorados em rela¸˜o ` varia¸˜o no n´ mero de ciclos ca ca a ca u registrados. A taxa ´ ent˜o multiplicada pela diferen¸a entre a leitura do TSC obtida da e a c amostra do Oprofile Estendido imediatamente anterior ` chamada da fun¸˜o readtsc() a ca e o valor retornado pela fun¸˜o. Dessa forma, melhora-se precis˜o da medida, mesmo ca a utilizando taxas de amostragem mais baixas.

8.3

Resultados das Medidas

Esta se¸˜o apresenta os resultados das medidas dos experimentos para os programas ca enquanto ordenam os vetores do tamanho da cache L2.

8.3.1

Comportamento dos Programas e Contagem dos Eventos

A Figura 8.1 mostra os gr´ficos da execu¸˜o das duas vers˜es do Mergesort. A linha a ca o Merge indica as chamadas da fun¸˜o merge(), que agrega os dois vetores. A linha Quick ca indica o ponto no qual o vetor utilizado naquele n´ da recurs˜o tem o tamanho igual ıvel a ao dobro da capacidade da cache L2. No Tiled Mergesort, quando o vetor atinge o dobro do tamanho da L2, o programa executa o Quicksort para as duas metades do vetor, cada uma delas com o tamanho da cache L2. No Mergesort a linha de nome Quick serve apenas para comparar o comportamento dos dois programas durante a ordena¸˜o dos vetores num mesmo est´gio da ca a execu¸˜o. ca As demais linhas do gr´fico indicam a contagem dos eventos monitorados pelo Oprofile a Estendido. Data_Cache_Accesses mostra a contagem dos acessos ` cache na sua escala a normal. Data_Cache_Misses mostra as faltas na L1, que est˜o numa escala equivalente a

67
Mergesort L2 7e+08 6e+08 5e+08 Contagem 4e+08 3e+08 2e+08 1e+08 0 0 2e+08 4e+08 6e+08 8e+08 Ciclos DATA_CACHE_ACCESSES DATA_CACHE_MISSES: 0,009 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,001 Merge Quick Tiled Mergesort L2 1e+09 1,2e+09 1,4e+09

5e+08

4e+08

Contagem

3e+08

2e+08

1e+08

0 0 2e+08 4e+08 6e+08 Ciclos 8e+08 1e+09 1,2e+09

DATA_CACHE_ACCESSES DATA_CACHE_MISSES: 0,011 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,002 Merge Quick

Figura 8.1: Acima, execu¸˜o do Mergesort. Abaixo Tiled Mergesort no mesmo vetor. ca

68 a 0,009 dos valores obtidos do registro do Oprofile Estendido para o Mergesort e 0,011 para o Tiled Mergesort. Finalmente, a terceira linha mostra a contagem das faltas na L2, representadas pelo evento Data_Cache_Refills_From_System; Os valores reais destes eventos est˜o em 0,001 do valor do gr´fico para o Mergesort e em 0,002 para o Tiled a a Mergesort. Uma amplia¸˜o de trechos equivalentes da execu¸˜o dos dois programas que ilustra a ca ca sequˆncia das chamadas de fun¸˜o pode ser observada nos gr´ficos da Figura 8.2. A linha e ca a vertical s´lida indica o ponto em que a faixa de trabalho do vetor est´ com o dobro da o a capacidade da cache L2. Na ´rea demarcada entre as linhas verticais indicada por A1 , o a Mergesort (topo) continua a sua execu¸˜o normal enquanto o Tiled Mergesort executa o ca Quicksort para os dois vetores. A ´rea indicada por B1 demarca a execu¸˜o da fun¸˜o a ca ca merge(), juntando os dois vetores rec´m ordenados. Em seguida, a `rea indicada por A2 e a delimita outro par de vetores do tamanho da cache sendo ordenado. Ap´s essa ordena¸˜o, o ca a ´rea B2 indica os dois vetores rec´m ordenados sendo agrupados com o aux´ do vetor a e ılio de resultado. Na chamada seguinte ` fun¸˜o merge() (C1 ) os dois vetores (ordenados em A1 e A2 ) a ca s˜o agregados nas duas ultimas chamadas da merge() com o aux´ do vetor de resultados. a ´ ılio As ´reas seguintes do gr´fico – A3 , B3 , A4 , B4 e C2 – indicam este mesmo processo se a a repetindo e, em D1 ocorre o agrupamento de todos os vetores ordenados durante o trecho da execu¸˜o dos programas exibido nos gr´ficos da Figura 8.2. ca a Durante a execu¸˜o da fun¸˜o merge(), a taxa de faltas na L2 ´ elevada, uma vez ca ca e que o tamanho do conjunto de dados utilizado ´, no m´ e ınimo, quatro vezes maior do que a capacidade da L2: cada vetor rec´m ordenado tem o tamanho da L2 e o vetor de e resultados trabalha copiando todos esses dados, dobrando a ´rea de mem´ria acessada a o durante a ordena¸˜o. Enquanto a taxa de faltas na L2 aumenta, as faltas na L1 se ca mant´m constantes e os acessos ` cache diminuem porque a busca dos blocos faltantes e a produz bloqueios no processador. A an´lise mais detalhada deste trecho da execu¸˜o dos programas – utilizando dados a ca do registro do Oprofile Estendido – mostra que a quantidade de acessos ` L1 cache do a

69
Mergesort L2 3e+08

2,5e+08

Contagem

2e+08 A1 B1 A2 B2 C1 A3 B3 A4 B4 C2 D1

1,5e+08

1e+08 3e+08

3,5e+08

4e+08

4,5e+08 Ciclos

5e+08

5,5e+08

DATA_CACHE_ACCESSES DATA_CACHE_MISSES: 0,009 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,001 Merge Quick Tiled Mergesort L2

1,8e+08

Contagem

1,5e+08

A1

B1

A2

B2 C1

A3

B3

A4

B4 C2

D1

1,2e+08

9e+07

2,8e+08

3,2e+08

3,6e+08 Ciclos

4e+08

4,4e+08

4,8e+08

DATA_CACHE_ACCESSES DATA_CACHE_MISSES: 0,011 DATA_CACHE_REFILLS_FROM_SYSTEM: 0,002 Merge Quick

Figura 8.2: Ciclos da ordena¸˜o; topo Mergesort e acima Tiled Mergesort. ca

70 Evento Ciclos Cache Access Cache Misses Refills from System Programa Mergesort L2 Tiled Mergesort L2 Diferen¸a (%) c 2,72·108 2,21·108 22 1,53·108 9,4·108 63 854.347 601.180 42 168.521 165.887 1,5

Tabela 8.2: Contagem de eventos para o trecho da execu¸˜o dos programas. ca

Mergesort ´ 63% superior ` do Tiled Mergesort. Quanto aos demais eventos medidos, a e a propor¸˜o ´ de 42% a mais para as faltas na L1, 1,5% a mais para as faltas na L2 cache ca e e 22% a mais na quantidade de ciclos. Os valores utilizados de base para esses c´lculos a est˜o dispostos na Tabela 8.2. a Para comparar o comportamento do Mergesort e do Quicksort durante a ordena¸˜o ca da mesma faixa do vetor, um trecho menor da execu¸˜o dos dois programas foi ampliado. ca Para estes trechos apresentados, a m´dia das 20 execu¸˜es descaracterizou o comportae co mento dos programas e por isso, os gr´ficos apresentados at´ o final desta se¸˜o tamb´m a e ca e mostram os resultados da execu¸˜o “mais parecida” com m´dia das 20 execu¸˜es. Os ca e co valores apresentados no entanto, s˜o das m´dias de 20 testes. a e O comportamento dos acessos ` cache ´ mostrado na Figura 8.3. O gr´fico do Mergea e a sort (topo) mostra o momento que a fun¸˜o mergesort() ´ chamada para o vetor com o ca e dobro do tamanho da L2. O Tiled Mergesort, mostrado na por¸˜o inferior da Figura 8.3, ca indica o momento em que a fun¸˜o quicksort() ´ executada. A contagem dos acessos ´ ca e e de aproximadamente 3, 17 · 107 para o primeiro programa e de 1, 75 · 107 para o segundo. O total de ciclos utilizados ´ de 4, 92 · 107 para Mergesort enquanto para o Quicksort ´ de e e 3, 53 · 107 ciclos. O comportamento dos acessos do Mergesort come¸a constante e aproximadamente na c metade do gr´fico, ponto onde ocorre a ultima chamada ` merge(), h´ uma redu¸˜o a ´ a a ca gradativa na contagem de acessos at´ o ponto em que ela se mant´m constante, devido e e ao aumento das faltas e os consequentes stalls do processador. Quando o pr´ximo vetor o come¸a a ser ordenado, a contagem de acessos volta a subir na mesma taxa e s´ baixa no c o final da ´rea delimitada, quando mais uma vez, a fun¸˜o merge() ´ chamada e as duas a ca e

71 metades do vetor s˜o ordenadas com o aux´ do vetor de resultado. a ılio Os acessos ` cache executados pelo Quicksort apresentam uma redu¸˜o no n´ mero a ca u de acessos tanto no in´ ıcio quanto no meio da ´rea delimitada pelas linhas verticais do a gr´fico. Cada oscila¸˜o dessa representa o in´ da execu¸˜o do Quicksort, quando todos a ca ıcio ca os elementos do vetor s˜o lidos e movimentados de acordo com o seu valor em rela¸˜o a ca ao pivˆ. Nessa fase, muitas faltas ocorrem na L2, o que ocasiona bloqueios aos demais o acessos e consequentemente a redu¸˜o na contagem. ca O mesmo trecho delimitado pelas linhas verticais, ajustado para mostrar as faltas na L1 para os dois programas ´ exibido na Figura 8.4. A linha que representa as faltas e causadas pelo Mergesort (topo) apresenta o comportamento do programa ao longo da ´ ordena¸˜o de dois vetores do tamanho da L2. E poss´ observar nos degraus causados ca ıvel pela fun¸˜o merge() os oito est´gios da execu¸˜o da ordena¸˜o, marcados com flechas. ca a ca ca O primeiro est´gio (A1 ) representa o final da ordena¸˜o do primeiro quarto do vetor, a ca quando a contagem das faltas aumenta, formando um pequeno degrau na linha. Em B1 , o segundo quarto do vetor come¸a a ser ordenado at´ o pr´ximo degrau da linha, mais c e o alto, que representa a ordena¸˜o da primeira metade do vetor. O terceiro quarto do vetor ca come¸a a ser ordenado e termina no terceiro degrau (C1 ). O ultimo quarto do vetor ´ c ´ e ordenado e termina no degrau mais alto, indicado por D1 . Neste ponto, as duas metades de todo o vetor s˜o agregadas, o que causa o aumento nas faltas. Da metade do gr´fico a a adiante, o processo se repete para o segundo vetor, como demonstrado em A2 , B2 , C2 e D2 . Para o Quicksort, no in´ da ordena¸˜o (Figura 8.4, abaixo), ocorrem a maioria das ıcio ca faltas enquanto todos os elementos do vetor s˜o lidos e reposicionados. Depois dessa a primeira ordena¸˜o, apesar das faltas diminuirem elas continuam a ocorrer, uma vez ca que o tamanho do vetor ´ quatro vezes a capacidade da L1. Na ordena¸˜o do segundo e ca vetor, o comportamento ´ praticamente o mesmo. O momento em que as faltas ocorrem e depois que a contagem se estabiliza depende do reaproveitamento dos dados em cache. De acordo com a movimenta¸˜o dos valores no vetor em rela¸˜o ao pivˆ, o reaproveitamento ca ca o dos elementos pode ser maior ou menor, o que interfere no momento em que as faltas

72
Mergesort L2 1,44e+08

1,36e+08

Contagem

1,28e+08

1,2e+08

1,12e+08

2,2e+08

2,3e+08

2,4e+08 Ciclos Merge Tiled Mergesort L2

2,5e+08

2,6e+08

DATA_CACHE_ACCESSES

Quick

8,5e+07

8e+07

Contagem

7,5e+07

7e+07

1,8e+08

1,85e+08

1,9e+08

1,95e+08 Ciclos

2e+08

2,05e+08

2,1e+08

DATA_CACHE_ACCESSES

Merge

Quick

Figura 8.3: Acessos ` cache do Mergesort e Tiled Mergesort, faixas do tamanho da L2. a

73 ocorrem, mas n˜o na quantidade de faltas. a A contagem total de faltas para cada programa, na ´rea delimitada pelas linhas vera ticais, ´ de aproximadamente 134.371 para o Mergesort. O Quicksort causa 71.937 faltas e na L1 durante a ordena¸˜o do mesmo trecho do vetor. A diferen¸a entre as contagens, ca c de 86%, ´ devida ` baixa associatividade da L1 e tamb´m ao fato do Mergesort utilizar e a e o vetor de resultados para agregar os vetores. Os trechos da ordena¸˜o do Mergesort ca utilizam o dobro de espa¸o necess´ro ao Quicksort e por isso h´ uma quantidade maior c a a de faltas e, consequentemente, perda de desempenho. A contagem do evento Data_Cache_Refills_from_System, ou faltas na L2, apresenta um comportamento similar ao das faltas na L1 para os dois programas, como pode ser observado na Figura 8.5. Para o Mergesort, ` medida que a fun¸˜o merge() ´ executada, a ca e as faltas ocorrem e os dados s˜o armazenados em cache. As chamadas subsequentes da a fun¸˜o merge() sobre conjuntos maiores do vetor tiram proveito dos dados presentes em ca cache e n˜o causam faltas na L2 at´ o momento em que ocorre a ultima ordena¸˜o do a e ´ ca vetor, quando a quantidade de faltas ´ baixa e aumenta bruscamente, uma vez que a L2 e n˜o acomoda todo o conjunto de dados. a O comportamento da contagem de faltas na L2 apresenta trechos planos indicados por flechas onde a contagem de faltas na L1 apresenta degraus, ` exe¸˜o do final de cada a ca ordena¸˜o, quando a contagem de faltas na L2 aumenta. Para este programa, o total de ca faltas na L2 contabilizado na ´rea delimitada pelas linhas verticais ´ de 9.926. a e O Quicksort apresenta na L2 o mesmo comportamento em rela¸˜o `s faltas na L1. No ca a in´ da execu¸˜o, todo o vetor ´ percorrido e o n´ mero de faltas aumenta rapidamente. ıcio ca e u Em seguida, o vetor est´ carregado na cache e as movimenta¸˜es seguintes dos elementos a co causam faltas de acordo com o posicionamento do pivˆ. Aparentemente, a quantidade de o faltas que ocorre na ordena¸˜o do segundo vetor ´ maior do que a que ocorre no primeiro ca e vetor. Observando atentamente a linha do gr´fico, h´ uma pequena falha na ascen¸˜o das a a ca faltas que significa a troca de vetores. O primeiro vetor apresentou um aumento na taxa de faltas no final da ordena¸˜o, provavelmente devido a alguma interferˆncia do Sistema ca e Operacional. A contagem neste trecho da ordena¸˜o foi de 7.773 faltas. A diferen¸a de ca c

74
Mergesort L2 1,23e+06 D2

1,2e+06 B2 A2 1,17e+06 Contagem D1 1,14e+06 B1 1,11e+06 A1 C1

C2

1,08e+06 2,2e+08 2,3e+08 2,4e+08 Ciclos Merge Tiled Mergesort L2 990000 2,5e+08 2,6e+08

DATA_CACHE_MISSES

Quick

975000

Contagem

960000

945000

930000

915000 1,8e+08 1,85e+08 1,9e+08 1,95e+08 Ciclos 2e+08 2,05e+08 2,1e+08

DATA_CACHE_MISSES

Merge

Quick

Figura 8.4: Faltas na L1 para o Mergesort no topo e para o Quicksort na base.

75 27% entre a quantidade de faltas do Mergesort e do Quicksort no trecho demarcado ´ e devida ` associatividade 4 da L2, que obt´m um reaproveitamento de dados superior ao a e da L1, cuja associatividade ´ 2 [19]. e Com a distribui¸˜o temporal dos eventos, ´ poss´ observar o comportamento das ca e ıvel faltas e acessos ` cache de forma mais clara do que com as demais ferramentas baseadas a em CDHs dispon´ ıveis. Assim como na Se¸˜o 7.3.2, o Oprofile Estendido ajuda na comca preens˜o da forma com que cada programa utiliza a hierarquia de mem´ria, viabilizando a o a observa¸˜o e a contagem das faltas e acessos ao longo da execu¸˜o dos programas. Esta ca ca observa¸˜o permite a identifica¸˜o de cada etapa da execu¸˜o dos programas e, conseca ca ca quentemente, um estudo e uma compreens˜o mais aprofundados da intera¸˜o entre os a ca programas e a hierarquia de mem´ria do sistema. o

8.3.2

An´lise das Taxas das Medidas a

Da mesma forma que apresentado na Se¸˜o 7.3.4, os dados obtidos nas medidas dos expeca rimentos com os programas de ordena¸˜o foram utilizados para calcular taxas, dividindo ca as varia¸˜es (∆1 ) de um evento por outro, seguindo as mesmas m´tricas dos resultados j´ co e a apresentados: a taxa dos acessos ` cache ´ ∆Data_Cache_Accesses/∆Ciclos, a de faltas a e na L1 ´ ∆Data_Cache_Misses/∆Data_Cache_Accesses, enquanto a taxa das faltas na e L2 ´ ∆Data_Cache_Refills_from_System/∆Data_Cache_Accesses. e Em todos os gr´ficos apresentados nesta se¸˜o, o eixo Y apresenta a varia¸˜o da taxa a ca ca da medida, o eixo X representa a contagem dos ciclos de rel´gio ao longo do tempo, os o pontos correspondem aos valores da m´trica para cada intervalo amostrado e as linhas e verticais pontilhadas indicam o in´ e o fim da ordena¸˜o do vetor. ıcio ca Os dados da taxa dos acessos ` cache para os dois programas s˜o mostrados na Fia a gura 8.6. O Mergesort (topo), apresenta uma varia¸˜o entre 0,50 e 0,74 acessos por ciclo ca durante as ordena¸˜es de pequenos trechos do vetor. Quando ocorrem chamadas ` fun¸˜o co a ca merge() em por¸˜es maiores do vetor – j´ carregadas em cache – a taxa de acessos por co a ciclo se estabiliza em aproximadamente 0,7. Os pontos em que a taxa apresenta estabili1

∆x = ...x2 − x1 , x3 − x2 ..., ∆y = ...y2 − y1 , y3 − y2 ..., sendo x e y eventos plotados nos eixos x e y.

76
Mergesort L2

116000

114000 Contagem 112000 110000

2,2e+08

2,3e+08

2,4e+08 Ciclos

2,5e+08

2,6e+08

DATA_CACHE_REFILLS_FROM_SYSTEM Merge Tiled Mergesort L2 113750

Quick

112000

Troca Contagem 110250

108500

106750

1,8e+08

1,85e+08

1,9e+08

1,95e+08 Ciclos

2e+08

2,05e+08

2,1e+08

DATA_CACHE_REFILLS_FROM_SYSTEM Merge

Quick

Figura 8.5: Faltas na L2 para o Mergesort no topo e para o Quicksort na base.

77 dade est˜o indicados com flechas verticais e s˜o os mesmos em que o gr´fico do Mergesort a a a na Figura 8.4 apresenta degraus indicando a ocorrˆncia de faltas na L1, e o da a Figura 8.5 e apresenta redu¸˜o na contagem de faltas na L2. ca O motivo da estabilidade da taxa de acessos nestes pontos ´ a presen¸a dos dados na e c L2 e a ausˆncia dos mesmos na L1. Nos trechos em que a taxa de acessos ´ mais inst´vel e e a ocorre que, enquanto os dados s˜o carregados da mem´ria principal durante a ordena¸˜o a o ca dos trechos menores do vetor, a taxa de acessos diminui quando o dado n˜o est´ disponivel a a e aumenta quando eles est˜o carregados na L1. Como a quantidade de valores ordenados a nestes subvetores ainda ´ muito pequena, h´ um reaproveitamento desses dados ainda na e a L1, o que causa o aumento na taxa de acessos. ` A medida que a quantidade de dados aumenta, os valores s˜o expurgados da L1 mas a permanecem ainda na L2. Quando estes dados s˜o acessados novamente, a taxa de acessos a por ciclo passa a ser limitada pelo tempo de acesso ` L2 e por isso se mant´m constante a e nos trechos demarcados. No centro do gr´fico ocorre a ultima ordena¸˜o do vetor, que a ´ ca causa faltas na L2 al´m da L1, e causa uma redu¸˜o na taxa de acessos. e ca No caso do Quicksort, percebe-se que a taxa de acessos diminui durante a primeira fase da execu¸˜o do programa devido `s faltas que estes acessos causam na L1 e na L2. Logo ca a no in´ ıcio, a taxa de acessos cai, oscilando entre 0,27 e 0,17 acessos por ciclo, convergindo para 0,23. A seguir, ela se estabiliza em 0,55 acessos por ciclo. Em alguns pontos, a taxa apresenta uma ligeira baixa, atingindo valores pr´ximos a 0,4. Como os ind´ o ıcios de faltas na L2, que seriam as poss´ ıveis causadoras de tamanha redu¸˜o na taxa de acessos, s˜o ca a muito fracos, efetuou-se uma an´lise destes trechos diretamente no registro do Oprofile a Estendido. Em trˆs dos pontos de baixa, foram encontradas amostras de execu¸˜o de c´digo do e ca o ´ Sistema Operacional. E poss´ ıvel, portanto, que os demais pontos de baixa da taxa de acessos tamb´m representem a execu¸˜o de c´digo do SO, n˜o detectada devido ` baixa e ca o a a taxa de amostragem – para este tipo espec´ ıfico de monitoramento. No registro foram encontradas mais amostras de execu¸˜o de c´digo de SO na regi˜o ca o a entre 1,96·108 e 1,98·108, entre a troca dos vetores indicada pela flecha vertical, o que

78
Mergesort L2 0,8

0,7

0,6

0,5 Taxa 0,4 0,3 0,2 0,1 2,2e+08 2,3e+08 2,4e+08 Ciclos 2,5e+08 2,6e+08

∆ DATA_CACHE_ACCESSES / ∆ Ciclos Merge Tiled Mergesort L2

Quick

0,6

0,5

Taxa

0,4

0,3

0,2

0,1 1,8e+08 1,85e+08 1,9e+08 1,95e+08 Ciclos 2e+08 2,05e+08 2,1e+08

∆ DATA_CACHE_ACCESSES / ∆ Ciclos Merge

Quick

Figura 8.6: Taxas de acessos por ciclos para Mergesort (topo) e Quicksort.

79 confirma a hip´tese de que a alta contagem de faltas no trecho pr´ximo ao in´ o o ıcio da ordena¸˜o do segundo vetor com o Quicksort tenha sido causada por interferˆncia do ca e Sistema Operacional. Em rela¸˜o `s faltas na L1, mostradas na Figura 8.7 o Mergesort apresenta uma ca a oscila¸˜o entre 4 · 10−4 e 0,008 com alguns picos em 0,025. Essa varia¸˜o da taxa de ca ca faltas est´ relacionada ao comportamento do sistema de mem´ria virtual: os dados s˜o a o a acessados pela primeira vez, causam faltas e aumentam a taxa. Depois de carregados na cache L1, enquanto os vetores ordenados s˜o pequenos, ocorre o reaproveitamento dos a dados, o que reduz a taxa de faltas. Os trechos indicados com as flechas na Figura 8.7 s˜o os mesmos indicados nos gr´ficos a a anteriores. Devido ao comportamento das faltas na L1 e na L2 observado nos gr´ficos das a Figuras 8.4 e 8.5, a taxa de faltas por acesso apresenta uma pequena estabilidade nestes pontos, devido ` execu¸˜o da fun¸˜o merge(). O trecho no centro do gr´fico em que a a ca ca a taxa de faltas aumenta temporariamente para 0,025 indica o momento em que ocorre uma chamada para a fun¸˜o merge() com uma quantidade de dados superior ` capacidade da ca a L1. No in´ da uni˜o dos vetores os dados acessados ainda est˜o em cache e a taxa se ıcio a a mant´m em 0.008. A partir do ponto em que os dados ordenados n˜o est˜o mais presentes e a a em cache, a taxa de faltas sobe para 0,025. No caso do Quicksort, o comportamento da taxa de faltas ´ o esperado. Na fase inicial e da ordena¸˜o ocorre a maioria das faltas e a taxa oscila em aproximadamente 0,065 ca faltas por acesso, caindo para aproximadamente 1,4·10−4, mantendo-se neste patamar at´ ocorrer a interferˆncia do SO, pouco antes do t´rmino da ordena¸˜o do vetor. As e e e ca pequenas oscila¸˜es que ocorrem depois da fase inicial da ordena¸˜o s˜o decorrentes da co ca a pequena capacidade da L1 em rela¸˜o ao tamanho do conjunto de dados. Cada oscila¸˜o ca ca mostrada no gr´fico corresponde a um pequeno degrau do gr´fico da Figura 8.4. a a Analisando a rela¸˜o entre a taxa de acessos e faltas na cache para os dois programas, ca apesar das faltas do Mergesort ocorrerem em maior quantidade, a taxa de acessos ` cache a deste programa ´ maior do que a do Quicksort. Isso ocorre porque, enquanto o Quicksort e realiza todas as opera¸˜es de ordena¸˜o sobre o mesmo vetor, o Mergesort acessa os valores co ca

80
Mergesort L2

0,025

0,02

Taxa

0,015

0,01

0,005

0 2,2e+08 2,3e+08 2,4e+08 Ciclos 2,5e+08 2,6e+08

∆ DATA_CACHE_MISSES / ∆ DATA_CACHE_ACCESSES Merge Quick Tiled Mergesort L2 0,105

0,09

0,075

0,06 Taxa 0,045 0,03 0,015

0 1,8e+08 1,85e+08 1,9e+08 1,95e+08 Ciclos 2e+08 2,05e+08 2,1e+08

∆ DATA_CACHE_MISSES / ∆ DATA_CACHE_ACCESSES Merge Quick

Figura 8.7: Taxas de faltas por acessos na L1 para o Mergesort (topo) e Quicksort.

81 no vetor original e agrega os valores ordenados no vetor de resultado a cada execu¸˜o da ca fun¸˜o merge(). ca A taxa de faltas na L2 por acessos ` cache pode ser vista no topo da Figura 8.8 para a o Mergesort. Os trechos indicados com as flechas mostram a taxa de faltas pr´ximas a o zero durante as execu¸˜es da fun¸˜o merge() com dados j´ presentes na L2. Os trechos co ca a que apresentam oscila¸˜es entre 0 e 8·10−4 indicam as faltas que ocorrem na L2 e que co interferem na taxa de acessos ` cache, j´ mostrada na Figura 8.7. a a A taxa de faltas na L2 aumenta para 0,025 no Mergesort apenas no est´gio final da a ordena¸˜o, quando o tamanho da ´rea de dados acessada – vetor de entrada mais vetor ca a de resultado, cada um ocupando o tamanho da L2 – supera a capacidade deste n´ da ıvel hierarquia de mem´ria virtual, ao final da ordena¸˜o de cada vetor. o ca No caso do Quicksort (Figura 8.8), no in´ da ordena¸˜o do primeiro vetor, a taxa de ıcio ca faltas na L2 come¸a oscilando entre 0,003 e 0,0058 e estabilizando em aproximadamente c 0,0036. Depois que os elementos do vetor s˜o carregados em cache, a taxa de faltas reduz a para 6,5·10−5 e permanece nessa faixa at´ que ocorre a interferˆncia do SO e o in´ da e e ıcio ordena¸˜o do segundo vetor, indicado pela flecha. Neste ponto, a taxa de faltas oscila ca entre 0,007 e 0,009 e logo em seguida cai novamente para 6,5·10−5. A distribui¸˜o temporal das taxas dos eventos permitiu observar o comportamento das ca taxas de faltas e acessos ` cache de forma mais clara do que com outras ferramentas basea adas em CDHs dispon´ ıveis. Assim como na Se¸˜o 7.3.2, os dados obtidos com o Oprofile ca Estendido mostram a forma com que cada programa utiliza a hierarquia de mem´ria ao o longo da execu¸˜o, permitindo computar valores para a taxa de faltas ou acessos em cada ca trecho. Esta informa¸˜o permitiu a identifica¸˜o das etapas da execu¸˜o dos programas ca ca ca de ordena¸˜o e, consequentemente, uma compreens˜o maior sobre a intera¸˜o entre os ca a ca programas e a hierarquia de mem´ria do sistema. Este conhecimento adicional ´ util o e ´ para a depura¸˜o do desempenho destes programas, sugerindo, por exemplo, novos testes ca utilizando faixas de dados menores para o Tiled Mergesort, com o prop´sito de melhorar o a utiliza¸˜o cache L2. ca

82
Mergesort L2

0,025

0,02

Taxa

0,015

0,01

0,005

0 2,2e+08 2,3e+08 2,4e+08 Ciclos 2,5e+08 2,6e+08

∆ DATA_CACHE_REFILLS_FROM_SYSTEM / ∆ DATA_CACHE_ACCESSES Merge Quick Tiled Mergesort L2 0,025

0,02

0,015 Taxa 0,01 0,005

0 1,8e+08 1,85e+08 1,9e+08 1,95e+08 Ciclos 2e+08 2,05e+08 2,1e+08

∆ DATA_CACHE_REFILLS_FROM_SYSTEM / ∆ DATA_CACHE_ACCESSES Merge Quick

Figura 8.8: Taxas de faltas na L2 por acessos, Mergesort (topo) e Quicksort.

83

CAP´ ITULO 9 ˆ INTERFERENCIA NAS MEDIDAS
Qualquer ferramenta de monitoramento interfere na execu¸˜o do programa que esteja ca sendo monitorado. Por isso, o resultado de uma execu¸˜o normal de um programa tende ca a ser diferente do resultado apresentado pela ferramenta de medida. Quanto maior a interferˆncia da ferramenta, maior a distor¸˜o na medida. e ca No Oprofile original, a cada interrup¸˜o provocada por um contador de eventos, soca mente aquela ocorrˆncia ´ registrada. Normalmente, cada contador provoca v´rias intere e a rup¸˜es ao longo da execu¸˜o de um programa e tipicamente h´ mais de um contador co ca a gerando interrup¸˜es. Assim, o tratamento de uma interrup¸˜o ´ relativamente r´pido, co ca e a mas elas podem ocorrer com alguma frequˆncia. e Com o Oprofile Estendido, as interrup¸˜es ocorrem a uma taxa que depende da reco solu¸˜o desejada, mas o tratamento de cada interrup¸˜o n˜o ´ r´pido porque, al´m do ca ca a e a e TSC, todos os contadores s˜o lidos e seus valores registrados. Em rela¸˜o ao Oprofile oria ca ginal, esse aumento na quantidade de dados interfere tamb´m no overhead causado pela e sincroniza¸˜o do sistema de arquivos e pela c´pia do arquivo de registros da mem´ria para ca o o o disco. Para mensurar a interferˆncia do Oprofile Estendido nas medidas realizadas, em rela¸˜o e ca ` execu¸˜o normal dos testes, todos os programas apresentados neste trabalho foram moa ca nitorados de trˆs maneiras e com diferentes configura¸˜es em cada uma: (i) com o Oprofile e co Estendido; (ii) com o Oprofile original; e (iii) sem o Oprofile. A medida de tempo nos dois ultimos ´ obtida com duas invoca¸˜es da fun¸˜o readtsc(), no in´ e no final da ´ e co ca ıcio execu¸˜o. ca Cada experimento tamb´m foi monitorado com uma combina¸ao diferente de confie c˜ gura¸˜es entre o Oprofile e o Oprofile Estendido com a finalidade de mostrar as varia¸˜es co co da interferˆncia causada pelo Oprofile Estendido em cada uma das situa¸˜es. e co

84 Nas tabelas apresentadas neste cap´ ıtulo, a primeira coluna mostra o programa executado ou algum parˆmetro da execu¸˜o que ser´ citado, a segunda coluna mostra a a ca a contagem total dos ciclos da execu¸˜o do programa monitorado com o Oprofile Estenca dido, a terceira coluna mostra a contagem de ciclos obtidos com o Oprofile convencional e a terceira coluna apresenta a contagem obtida na execu¸˜o normal do programa. ca Al´m dos dados de contagens de ciclos, ao lado de cada medida est´ mostrada a e a interferˆncia da ferramenta na quantidade de ciclos medidos. A percentagem de ciclos e adicionais apresentada na tabela ´ contabilizada em rela¸˜o ` execu¸˜o do programa sem e ca a ca qualquer tipo de monitoramento e ´ denominada Overhead. e

9.1

Faltas nas TLBs

Com o intuito de mostrar a varia¸˜o da interferˆncia das medidas quando se altera o ca e comportamento do programa, a Tabela 9.1 mostra as contagens de ciclos registradas pelo Time Stamp Counter (TSC) durante as trˆs execu¸˜es do programa que causa faltas na e co TLB, apresentado no Cap´ ıtulo 6. P´ginas percorridas Oprofile Estendido a 0 a 350 2, 96 · 109 5,6% 22 a 42 2, 91 · 107 1,8% 250 a 280 3, 71 · 108 1% Oprofile 2, 83 · 109 0,9% 2, 89 · 107 1,5% 3, 70 · 108 0,8% – 2, 81 · 109 2, 85 · 107 3, 66 · 108

Tabela 9.1: Overhead do OProfile e do OProfile Estendido para faltas nas TLBs.

A configura¸˜o utilizada nestes testes foi: (i) Cpu_Clk_Unhalted, 150.000 eventos; ca (ii) Data_Cache_Accesses, 500.000 eventos; (iii) L1_Dtlb_Misses_L2_Dtld_Hits, 500.000 eventos; e (iv) L1_And_L2_Dtlb_Misses, 500.000 eventos. As varia¸˜es apresentadas na Tabela 9.1 mostram que para estes experimentos e esta co configura¸˜o, o overhead causado pelo Oprofile Estendido ´ de 0,2 a 0,3% em rela¸˜o ao ca e ca Oprofile original para os intervalos de p´ginas apresentados na segunda e terceira linhas a da tabela. Na primeira linha, a interferˆncia do Oprofile ´ de 0,9% enquanto a do Oprofile e e Estendido ´ de 5,6%, ou 5,2% a mais do que o Oprofile. e A poss´ causa da diferen¸a entre as duas medidas ´ o tempo de execu¸˜o de cada ıvel c e ca

85 ´ experimento. E prov´vel que a execu¸˜o com o Oprofile original tenha passado pelo trecho a ca de interesse da execu¸˜o antes do Oprofile realizar a descarga dos buffers, como ocorre ca nas Figuras 6.3 e 6.5 (p´ginas 32 e 36). No caso da execu¸˜o monitorada pelo o Oprofile a ca Estendido, a descarga dos buffers ocorre dentro da ´rea de interesse, como pode ser visto a na Figura 6.2, p´gina 30. Uma vez que os dumps do Oprofile Estendido ocorrem em a um intervalo fixo de tempo, a descarga ocorre em todas as 20 execu¸˜es do programa, co afetanto todas as medidas. Por este ser um programa de r´pida execu¸˜o, a interferˆncia a ca e da descarga pode alterar significativamente a medida.

9.2

Multiplica¸˜o de Matrizes ca

Os resultados para programas de multiplica¸˜o de matrizes apresentados no Cap´ ca ıtulo 6 est˜o na Tabela 9.2, que mostra as contagens de ciclos registradas pelo Time Stamp a Counter (TSC) durante a execu¸˜o de cada um dos programas monitorados pelo Oprofile ca Estendido, pelo Oprofile e sem nenhum monitoramento, na segunda, terceira e quarta colunas respectivamente. A primeira linha mostra os dados para a multiplica¸˜o de matrizes ca convencional e a segunda, para a multiplica¸˜o otimizada com padding e blocagem. ca Programa Normal Otimizado Oprofile Estendido 4, 32 · 1011 1,8% 5, 07 · 1010 11,9% Oprofile 4, 27 · 1011 0,7% 4, 79 · 1010 5,7% – 4, 24 · 1011 4, 53 · 1010

Tabela 9.2: Overhead do OProfile e do OProfile Estendido no produto de matrizes.

A configura¸˜o utilizada para o Oprofile ´ diferente daquela do Oprofile Estendido ca e para estes programas. Neste caso, o intuito das configura¸oes distintas ´ apresentar mais c˜ e uma difen¸˜o do comportamento da interferˆncia das duas ferramentas durante o monica e toramento. A configura¸˜o utilizada nos testes realizados com o Oprofile foi: (i) Cpu_Clk_Unhalted, ca 1.500.000 eventos para a multiplica¸˜o convencional e 250.000 para a otimizada; (ii) Data_ ca Cache_Accesses, 100.000 eventos; (iii) Data_Cache_Refills_From_L2, 50.000 eventos; e (iv) Data_Cache_Refills_From_System, 50.000 eventos.

86 Para o Oprofile Estendido a configura¸˜o utilizada foi: (i) Cpu_Clk_Unhalted, 1.500.000 ca eventos para a multiplica¸˜o convencional e 250.000 para a otimizada; (ii) Data_Cache_ ca Accesses, 231 −1 eventos; (iii) Data_Cache_Refills_From_L2, 231 −1 eventos; e (iv) Data_ Cache_Refills_From_System, 231 − 1 eventos. As varia¸˜es apresentadas na Tabela 9.2 mostram que para estes experimentos, nesta co configura¸˜o, o overhead causado pela interferˆncia do Oprofile ´ de 0,7% enquanto o ca e e do Oprofile Estendido ´ de 1,8% na multiplica¸˜o de matrizes convencional. No caso da e ca multiplica¸˜o de matrizes com padding e blocagem, a interferˆncia causada pelo Oprofile ca e Estendido ´ de 11,9%, enquanto a interferˆncia do Oprofile ´ de 5,7% em rela¸˜o ` execu¸˜o e e e ca a ca da multiplica¸˜o sem nenhum tipo de monitoramento. ca A diferen¸a nas taxas de amostragem dos ciclos de rel´gio Cpu_Clk_Unhalted ´ fator c o e determinante para o aumento do overhead do programa de multiplica¸˜o de matrizes ca normal para o otimizado. A taxa de amostragem deste evento para o programa otimizado ´ seis vezes superior ` taxa de amostragem para o programa convencional. e a No caso do Oprofile Estendido, a rela¸˜o entre a medida do overhead para os dois ca programas ´ de 6,4 vezes, pr´ximo da rela¸˜o entre as taxas de amostragem configuradas e o ca para cada um dos programas. Para o Oprofile original este racioc´ ınio n˜o se aplica, a uma vez que qualquer evento pode causar uma interrup¸˜o do processador e prejudicar ca a medi¸˜o. A diferen¸a de Overhead entre as medidas realizadas com o Oprofile ´ de ca c e aproximadamente 9 vezes, bastante superior ` diferen¸a da configura¸˜o. a c ca De acordo com os dados apresentados nesta se¸˜o, o Oprofile Estendido apresentou ca um overhead superior ao do Oprofile para as configura¸˜es utilizadas nestes testes. Apeco sar disso, o pior overhead causado pelo Oprofile Estendido ´ de apenas 11,9%, que ´ e e aceit´vel quando se considera o benef´ proporcionado pelas informa¸˜es adicionadas a a ıcio co cada amostra.

9.3

Mergesort

Os programas de ordena¸˜o apresentados na Cap´ ca ıtulo 8 foram novamente executados e a quantidade de ciclos foi medida de acordo com os trˆs crit´rios propostos no in´ e e ıcio

87 deste cap´ ıtulo. A Tabela 9.3 mostra as contagens de ciclos registradas pelo Time Stamp Counter (TSC) durante as trˆs execu¸˜es de cada um dos programas. e co A configura¸˜o utilizada para o Oprofile foi diferente da utilizada no Oprofile Estendido ca para estes programas. Neste experimento, a inten¸˜o ´ demonstrar duas configura¸˜es nas ca e co quais o comportamento da interferˆncia das duas ferramentas durante o monitoramento e ´ similar. e Programa Merge L2 T-Merge L2 Oprofile Estendido 1, 380 · 109 10% 1, 227 · 109 10% Oprofile – 9 1, 377 · 10 10% 1, 252 · 109 1, 228 · 109 10% 1, 111 · 109

Tabela 9.3: Overhead do OProfile e do OProfile Estendido na ordena¸˜o de vetores. ca

A configura¸˜o utilizada nos testes realizados com o Oprofile foi: (i) Cpu_Clk_Unhalted, ca 75.000 eventos; (ii) Data_Cache_Accesses, 10.000 eventos; (iii) Data_Cache_Refills_ From_L2, 10.000 eventos; e (iv) Data_Cache_Refills_From_System, 10.000 eventos. Para o Oprofile Estendido a configura¸˜o utilizada foi: (i) Cpu_Clk_Unhalted, 75.000 ca eventos; (ii) Data_Cache_Accesses, 231 − 1 eventos; (iii) Data_Cache_Refills_From_L2, 231 − 1 eventos; e (iv) Data_Cache_Refills_From_System, 231 − 1 eventos. As varia¸˜es apresentadas na tabela mostram que, para estes experimentos e esta co configura¸˜o, o overhead causado pelo Oprofile Estendido ´ o mesmo causado pelo Oprofile ca e convencional. Os valores de interferˆncia medidos para as duas ferramentas s˜o de 10%. e a Os valores de overhead causados pelo Oprofile Estendido e o Oprofile apresentados neste cap´ ıtulo mostram diferentes resultados para diferentes combina¸˜es de amostragem co em cada ferramenta. Estes resultados sugerem um estudo futuro que relacione a taxa de amostragem das duas ferramentas e o overhead causado por cada uma delas. A motiva¸˜o ca do estudo ´ encontrar o ponto em que o overhead do Oprofile Estendido seja t˜o baixo e a quanto o do Oprofile, sem comprometer a precis˜o das medidas obtidas. a

88

CAP´ ITULO 10 ˆ DIVERGENCIAS NAS MEDIDAS
O Oprofile Estendido utiliza um m´todo de coleta de dados diferente do Oprofile original. e Enquanto o Oprofile realiza uma amostragem de cada contador ao longo da execu¸ao c˜ de um programa, o Oprofile Estendido atualiza a contagem de todos os eventos a cada intervalo de tempo definido pelo usu´rio. a Dessa forma, o Oprofile original n˜o conta ‘eventos’ mas sim “o n´ mero de overflows a u ocorridos” no contador de eventos. Estes contadores s˜o configurados com valores adea quados para as m´tricas, inicializados em zero e incrementados a cada evento. Quando e a contagem chega ao limite, o processador ´ interrompido. Portanto, o n´ mero (aproxie u mado) de eventos ´ o produto entre o n´ mero de interrup¸˜es e o valor de configura¸˜o e u co ca do contador. No Oprofile Estendido, o processador ´ interrompido pelo contador de ciclos de execu¸˜o e ca (Clock_Unhalted) de acordo com o intervalo definido pelo usu´rio, e ent˜o os valores em a a todos os contadores s˜o registrados. Assim, as contagens dos eventos monitorados s˜o a a atualizadas a cada intervalo de medida, ao inv´s de acumuladas a cada overflow de cada e contador configurado. As diferen¸as entre a contagem baseada nas amostragens do Oprofile e as contagens c apresentadas pelo Oprofile Estendido variam bastante, principalmente em fun¸˜o da conca figura¸˜o do Oprofile e do tempo de execu¸˜o do experimento. Os dados apresentados ca ca neste Cap´ ıtulo s˜o baseados nas mesmas configura¸˜es utilizadas nos experimentos do a co Cap´ ıtulo 9. Os resultados obtidos com o Oprofile foram calculados a partir dos relat´rios gerados o pelo programa opreport, incluido na distribui¸˜o do Oprofile. Embora todos os 20 expeca rimentos de cada programa analisado tenham sido realizados com a mesma configura¸˜o, ca em alguns casos, o opreport n˜o gerou os relat´rios com a apresenta¸˜o dos dados no a o ca

89 padr˜o ideal para a composi¸˜o da m´dia1 , e por isso estes relat´rios n˜o foram incluidos a ca e o a no c´lculo. Os resultados do Oprofile Estendido correspondem ` m´dia de 20 execu¸˜es a a e co de cada experimento. Em todas as tabelas apresentadas nesta Cap´ ıtulo, a primeira coluna apresenta o evento monitorado, a segunda coluna a m´dia da contagem do evento obtida atrav´s do Oproe e file Estendido, a terceira coluna apresenta a m´dia da contagem calculada a partir dos e resultados do Oprofile.

10.1

Faltas nas TLBs

A Tabela 10.1 apresenta os resultados das contagens de faltas nas TLBs obtidas com o programa da Cap´ ıtulo 6. Dentre os resultados dos testes realizados para este programa, o que apresenta a maior divergˆncia entre as medidas ´ o teste que percorre de 22 a 42 e e p´ginas. Neste teste, que dura apenas 3·107 ciclos, o n´ mero de faltas na L1 n˜o atinge a u a o valor de overflow do contador e portanto nenhuma falta foi registrada pelo Oprofile. Oprofile Estendido P´ginas entre 0 e 350 a L1_Dtlb_Misses_L2_Dtld_Hits 2,66·107 L1_And_L2_Dtlb_Misses 4,88·106 P´ginas entre 22 e 42 a L1_Dtlb_Misses_L2_Dtld_Hits 1,88·105 P´ginas entre 250 e 280 a L1_And_L2_Dtlb_Misses 3,8·105 Evento Oprofile 2,65·107 4,64·106 0 3,5·106 Varia¸˜o ca 0,37% 5,17% – 8,57%

Tabela 10.1: Divergˆncia na contagem de faltas de p´ginas. e a

A segunda maior divergˆncia ocorre no teste que percorre o intervalo de 250 a 280 e p´ginas. Neste teste, a diferen¸a ´ de uma uma ordem de grandeza a mais para o Oprofile. a c e ´ E poss´ que, em virtude deste tamb´m ser um teste r´pido – da ordem de 108 ciclos, uma ıvel e a a duas ordens de grandeza a menos do que os demais testes – a interferˆncia da inicializa¸˜o e ca do programa seja a causadora da distor¸˜o apresentada na medida do Oprofile. Este tipo ca de interferˆncia n˜o altera o resultado do Oprofile Estendido uma vez que a contagem e a
1

Os dados n˜o estavam devidamente separados por bin´rio, o que inviabiliza o processamento. a a

90 de eventos ocorrida antes da primeira chamada ` fun¸˜o readtsc() ´ eliminada no p´s a ca e o processamento dos dados. As diferen¸as podem ser parcialmente corrigidas repetindo-se os experimentos com os c parˆmetros alterados. Uma das possibilidades de corre¸ao consiste em aumentar o tempo a c˜ de execu¸˜o do programa, aumentando-se o n´ mero de vezes que o buffer ´ percorrido ca u e at´ que se aloque mais uma p´gina. Outra possibilidade ´ reduzir o valor de overflow do e a e contador de faltas na L1 TLB do Oprofile.

10.2

Multiplica¸˜o de Matrizes ca

Os resultados obtidos nos programas de multiplica¸˜o de matrizes podem ser observados ca na Tabela 10.2. Quanto maior o tempo de execu¸˜o do programa, menor ´ a divergˆncia ca e e entre os valores medidos pelas duas ferramentas. Oprofile Estendido Multiplica¸˜o Convencional ca Data_Cache_Accesses 1,66·1010 Data_Cache_Refills_From_L2 1,08·109 Data_Cache_Refills_From_System 1,07·109 Multiplica¸˜o Otimizada ca Data_Cache_Accesses 2,97·1010 Data_Cache_Refills_From_L2 1,03·109 Data_Cache_Refills_From_System 3,4·107 Evento Oprofile 1,53·1010 1,08·109 1,07·109 3,06·1010 1,09·109 2,04·107 Varia¸˜o ca 8,49% 0% 0% 3,03% 5,82% 66,6%

Tabela 10.2: Divergˆncia na contagem de eventos no produto de matrizes. e

No caso da multiplica¸˜o de matrizes, o programa convencional, com maior tempo ca de execu¸˜o, apresenta uma pequena divergˆncia entre os acessos ` cache, e aproximadaca e a mente os mesmos valores para as demais medidas. No caso da multiplica¸˜o otimizada ca com padding e blocagem, que executa em aproximadamente um d´cimo do tempo da mule tiplica¸˜o convencional, as diferen¸as existem em todos os eventos. Estudos anteriores ca c relacionados ` acur´cia dos CDHs relacionam o tempo de execu¸˜o dos testes ` precis˜o a a ca a a dos valores obtidos dos contadores [33, 26].

91

10.3

Mergesort

O comportamento das medidas dos programas de ordena¸˜o de vetores pode ser visto ca na Tabela 10.3. Nesta tabela, a diferen¸a entre as medidas do OProfile e do Oprofile c Estendido ´ de, em m´dia, 54% com um desvio padr˜o de 13 pontos percentuais. Estes e e a experimentos utilizam uma taxa de amostragem 5 vezes maior do que a recomendada pelo fabricante do processador [12], mas n˜o se obt´m uma convergˆncia entre os valores a e e obtidos pelas ferramentas. Oprofile Estendido Mergesort L2 Data_Cache_Accesses 7,35·108 Data_Cache_Misses 4,35·106 Data_Cache_Refills_From_System 1,09·106 Tiled Mergesort L2 Data_Cache_Accesses 5,03·108 Data_Cache_Misses 3,41·106 Data_Cache_Refills_From_System 1,09·106 Evento Oprofile Original 4,26·108 2,5·106 6,91·105 3,47·108 2,31·106 8,39·105 Diferen¸a c 72,53% 74% 57,74% 44,95% 47,61% 29,91%

Tabela 10.3: Divergˆncia na contagem de eventos na ordena¸˜o de vetores. e ca

Analisando de uma forma geral a proximidade entre as medidas coletadas das ferramentas e o tempo de dura¸˜o dos experimentos, ´ poss´ ca e ıvel estabelecer uma rela¸˜o ca entre o tempo de execu¸˜o de um teste e a diferen¸a entre as medidas coletadas com ca c as duas ferramentas. Esta rela¸˜o sugere, como estudo futuro, um aprofundamento no ca estudo da rela¸˜o entre a precis˜o da amostragem e o tempo de execu¸˜o do experimento, ca a ca complementando estudos como [26]. Ainda em rela¸˜o ` amostragem, diferentemente do Oprofile, – em que cada evento ca a mensur´vel possui um intervalo de amostragem recomendado – a amostragem ideal para a o Oprofile Estendido pode variar de acordo com o n´ de detalhe requerido pelo tipo de ıvel an´lise desejada e pelo tempo de execu¸˜o do experimento. a ca Considerando que a contagem de eventos do Oprofile Estendido elimina as interferˆncias anteriores e posteriores ao intervalo de interesse, n˜o ´ necess´rio executar o e a e a teste por tempo longo o suficiente para que o comportamento do programa domine os valores dos contadores. Outro aspecto a ser considerado ´ que, como mostrado em [31], e

92 os programas podem apresentar um mesmo comportamento que se repete ao longo da execu¸˜o – como demonstrado aqui, na multiplica¸˜o de matrizes e na ordena¸˜o de veca ca ca tores. Nestes casos, a an´lise de um pequeno trecho do programa pode ser suficiente para a compreender toda a sua execu¸˜o, o que torna desnecess´rios testes de longa dura¸˜o para ca a ca programas que apresentem essas caracter´ ısticas.

93

CAP´ ITULO 11 ˜ CONCLUSAO
Apresentamos uma extens˜o do Oprofile que permite gerar perfis de execu¸˜o que coma ca binam v´rias m´tricas e a informa¸˜o de tempo absoluto. Com o Oprofile Estendido ´ a e ca e poss´ tomar amostras temporais de todos os contadores de eventos observados a uma ıvel taxa de amostragem t˜o alta quanto permitida pelo projeto da CPU, sem causar pera turba¸˜o significativa na execu¸˜o do programa monitorado. ca ca Relatamos trˆs experimentos que demonstram a utiliza¸˜o do Oprofile Estendido. O e ca primeiro utiliza um programa de teste que provoca faltas controladas nos dois n´ ıveis da TLB, de forma que seja poss´ observar a evolu¸˜o das faltas nessas estruturas na ıvel ca medida que o conjunto de trabalho aumenta. As faltas s˜o monitoradas at´ que seja a e atingido o estado de thrashing nas TLBs. Deste material resultou o artigo “OProfile Estendido para Depura¸˜o de Desempenho” [1], apresentado no VI Workshop de Sistemas ca Operacionais (WSO’2009). O segundo experimento estuda o comportamento da hierarquia de mem´ria durante a o execu¸˜o de dois programas de multiplica¸˜o de matrizes, um convencional e um otimica ca zado. Nos resultados ´ poss´ observar a evolu¸˜o das faltas nos dois n´ e ıvel ca ıveis da cache de dados, al´m de fazer correla¸˜es entre a perturba¸˜o que cada evento monitorado causa e co ca nos demais. O terceiro experimento compara o desempenho, com rela¸˜o ` hierarquia de caches, da ca a ordena¸˜o de um vetor de doubles com duas vers˜es do algoritmo de ordena¸˜o Mergesort. ca o ca Uma ´ a implementa¸˜o simples e a outra divide o vetor em faixas do tamanho das caches e ca e emprega o Quicksort nestas faixas. Nos resultados ´ poss´ observar a evolu¸˜o das e ıvel ca referˆncias e das faltas nas caches L1 e L2 ` medida que as chamadas recursivas ocorrem e a e que os vetores ordenados s˜o agregados. a Al´m da an´lise dos resultados obtidos com as contagens normais dos eventos, realie a

94 zamos, tanto para a multiplica¸˜o de matrizes quanto para a ordena¸˜o de vetores, uma ca ca an´lise das varia¸˜es nas taxas dos eventos monitorados, associando os eventos `s fases a co a da execu¸˜o dos programas. ca Analisamos a interferˆncia que o Oprofile Estendido causa na execu¸˜o de cada proe ca grama em rela¸˜o ` interferˆncia causada pelo Oprofile original em diferentes confica a e gura¸˜es, e em rela¸˜o ` execu¸˜o normal dos testes. Encontramos varia¸˜es de 0,6 a co ca a ca co 10% para o Oprofile, e de 1 a 10% para o Oprofile Estendido em rela¸˜o ` execu¸˜o norca a ca mal, de acordo com a configura¸˜o utilizada em cada uma das ferramentas, o que serve ca de base para definir, em experimentos futuros, qual deve ser a melhor rela¸˜o entre taxa ca de amostragem e interferˆncia. e Por fim, comparamos as medidas obtidas com o Oprofile e com o Oprofile Estendido em todos os programas de teste investigados e relacionamos fatores e caracter´ ısticas – como tempo de execu¸˜o e configura¸˜es das ferramentas – de cada um dos testes `s divergˆncias ca co a e observadas nas medidas. Os parˆmetros de configura¸˜o do Oprofile Estendido devem a ca variar de acordo com o experimento testado, ao contr´rio do Oprofile – e possivelmente a demais ferramentas baseadas em amostragem de contadores, que utilizam intervalos de valores pr´-definidos para cada evento monitorado. e O Oprofile Estendido ´ uma ferramenta capaz de agregar informa¸˜es uteis `s amostras e co ´ a do Oprofile com baixo overhead. As informa¸˜es complementares auxiliam ` compreens˜o co a a da intera¸˜o entre o programa examinado e a hierarquia de mem´ria, o que ´ fundamental ca o e para depura¸˜o de desempenho em sistemas computacionais. Outros eventos monitor´veis ca a podem enriquecer as informa¸˜es mostradas neste trabalho. Estudos visando ao monitoco ramento dos demais eventos ser˜o realizados em trabalhos futuros. a Os estudos futuros incluem: (i) relacionar as taxas de amostragem do Oprofile Estendido ao overhead causado; (ii) relacionar as taxas de amostragem e o tempo de convergˆncia entre as medidas do Oprofile e do Oprofile Estendido; e (iii) utilizar a visuae liza¸˜o da contagem discriminada dos dados do Oprofile Estendido (Figura 4.3, p´gina 24) ca a para estudar o desempenho da carga de bibliotecas dinˆmicas no sistema. a Estamos considerando a integra¸˜o do Oprofile Estendido ao Oprofile mediante conca

95 tato, e desenvolvimento conjunto com o autor do Oprofile, ampliando as funcionalidades da ferramenta, o hardware suportado e, consequentemente, as possibilidades de utiliza¸˜o. ca

96

ˆ APENDICE A EVENTOS SUPORTADOS PELO OPROFILE ESTENDIDO
Este apˆndice apresenta a sa´ do comando opcontrol --list-events, que lista os e ıda eventos monitor´veis no Athlon. a
info02:/var/lib/oprofile# opcontrol --list-events oprofile: available events for CPU type "Athlon" See AMD document x86 optimisation guide (22007.pdf), Appendix D CPU_CLK_UNHALTED: (counter: all) Cycles outside of halt state (min count: 3000) RETIRED_INSNS: (counter: all) Retired instructions (includes exceptions, interrupts, resyncs) (min count: 3000) RETIRED_OPS: (counter: all) Retired Ops (min count: 500) ICACHE_FETCHES: (counter: all) Instruction cache fetches (min count: 500) ICACHE_MISSES: (counter: all) Instruction cache misses (min count: 500) DATA_CACHE_ACCESSES: (counter: all) Data cache accesses (min count: 500) DATA_CACHE_MISSES: (counter: all) Data cache misses (min count: 500) DATA_CACHE_REFILLS_FROM_L2: (counter: all) Data cache refills from L2 (min count: 500) Unit masks (default 0x1f) ---------0x10: (M)odified cache state 0x08: (O)wner cache state 0x04: (E)xclusive cache state 0x02: (S)hared cache state 0x01: (I)nvalid cache state 0x1f: All cache states DATA_CACHE_REFILLS_FROM_SYSTEM: (counter: all) Data cache refills from system (min count: 500) Unit masks (default 0x1f) ---------0x10: (M)odified cache state 0x08: (O)wner cache state 0x04: (E)xclusive cache state 0x02: (S)hared cache state 0x01: (I)nvalid cache state 0x1f: All cache states DATA_CACHE_WRITEBACKS: (counter: all) Data cache write backs (min count: 500) Unit masks (default 0x1f) ---------0x10: (M)odified cache state 0x08: (O)wner cache state 0x04: (E)xclusive cache state 0x02: (S)hared cache state

97
0x01: (I)nvalid cache state 0x1f: All cache states RETIRED_BRANCHES: (counter: all) Retired branches (conditional, unconditional, exceptions, interrupts) (min count: 500) RETIRED_BRANCHES_MISPREDICTED: (counter: all) Retired branches mispredicted (min count: 500) RETIRED_TAKEN_BRANCHES: (counter: all) Retired taken branches (min count: 500) RETIRED_TAKEN_BRANCHES_MISPREDICTED: (counter: all) Retired taken branches mispredicted (min count: 500) L1_DTLB_MISSES_L2_DTLD_HITS: (counter: all) L1 DTLB misses and L2 DTLB hits (min count: 500) L1_AND_L2_DTLB_MISSES: (counter: all) L1 and L2 DTLB misses (min count: 500) MISALIGNED_DATA_REFS: (counter: all) Misaligned data references (min count: 500) L1_ITLB_MISSES_L2_ITLB_HITS: (counter: all) L1 ITLB misses (and L2 ITLB hits) (min count: 500) L1_AND_L2_ITLB_MISSES: (counter: all) L1 and L2 ITLB misses (min count: 500) RETIRED_FAR_CONTROL_TRANSFERS: (counter: all) Retired far control transfers (min count: 500) RETIRED_RESYNC_BRANCHES: (counter: all) Retired resync branches (only non-control transfer branches counted) (min count: 500) INTERRUPTS_MASKED: (counter: all) Interrupts masked cycles (IF=0) (min count: 500) INTERRUPTS_MASKED_PENDING: (counter: all) Interrupts masked while pending cycles (INTR while IF=0) (min count: 500) HARDWARE_INTERRUPTS: (counter: all) Number of taken hardware interrupts (min count: 10)

98

ˆ APENDICE B MULTIPLICACAO DE MATRIZES BLOCADA ¸˜
Este apˆndice apresenta o c´digo em linguagem ‘C’ do programa de multiplica¸˜o de e o ca matrizes blocado, implementado a partir do c´digo dispon´ em [17]. o ıvel
#include <stdio.h> #include <stdlib.h> #include <tsc.h> #define Mtype double #define MSIZE 1024 #define CLSIZE 16 // # de inteiros pra encher uma linha da cache int min (int v1, int v2) { if (v1 <= v2) return (v1); else return (v2); } Mtype a[MSIZE][MSIZE]; int pad1 [CLSIZE]; Mtype b[MSIZE][MSIZE]; int pad2 [CLSIZE]; Mtype c[MSIZE][MSIZE]; int main (int argc, char * argv[]) { Mtype sum; int B, i, j, jj, k, kk; if (argc !=2) { fprintf(stderr,"Modo de usar: %s <tam. bloco>", argv[0]); exit (1); } B = atoi(argv[1]); printf ("%llu 0\n",native_read_tsc()); for (i = 0; i < MSIZE; i++) for (j = 0; j < MSIZE; j++) a[i][j] = b[i][j] = c[i][j] = 0.1; printf ("%llu 1\n",native_read_tsc()); for (jj = 0; jj < MSIZE; jj = jj + B) for (kk = 0; kk < MSIZE; kk = kk + B) for (i = 0; i < MSIZE; i++) for (j = jj; j < min(jj + B, MSIZE); j++) for (sum = 0, k = kk; k < min(kk + B, MSIZE); k++) { sum += a[i][k] * b[k][j]; c[i][j] = sum; } printf ("%llu 1\n",native_read_tsc()); exit (0); }

99

ˆ APENDICE C FUNCAO READTSC ¸˜
Este apˆndice apresenta o c´digo em linguagem ‘C’ da fun¸˜o readtsc(), escrita com a e o ca ajuda de Aristeu S´rgio Rozanski Filho. e
#include <stdint.h> static inline unsigned long long native_read_tsc(void) { unsigned long long val; asm volatile("rdtsc" : "=A" (val)); return val; }

100

ˆ APENDICE D EXEMPLO DE CONFIGURACAO DO OPROFILE ¸˜ ESTENDIDO
Este apˆndice apresenta um exemplo do arquivo de configura¸˜o comentado do Oprofile e ca Estendido, normalmente encontrado no diret´rio /root/.oprofile/daemonrc. o
# Monitorar evento em modo SO -------------+ # Monitorar evento em modo usu´rio ------+ | a # M´scara (varia entre cada evento) ---+ | | a # Overflow do contador ------------+ | | | # Evento Monitorado --+ | | | | # Contador # -+ | | | | | # v v v v v v CHOSEN_EVENTS_0=CPU_CLK_UNHALTED:40000:0:1:1 CHOSEN_EVENTS_1=DATA_CACHE_MISSES:1573741824:0:1:1 CHOSEN_EVENTS_2=L1_DTLB_MISSES_L2_DTLD_HITS:1573741824:0:1:1 CHOSEN_EVENTS_3=L1_AND_L2_ITLB_MISSES:1573741824:0:1:1 # N´mero total de eventos selecionados u NR_CHOSEN=4 # Separar amostras dos programas por bibliotecas (0 = n~o, 1 = sim) a SEPARATE_LIB=0 # Separar amostras dos programas quando eles executam c´digo do kernel o SEPARATE_KERNEL=0 # Separar amostras dos programas por thread SEPARATE_THREAD=1 # Separar as amostras dos programas por CPU SEPARATE_CPU=0 # Localiza¸~o da imagem do kernel ca VMLINUX=/usr/src/_kernel-source-2.6.8/vmlinux # Filtrar apenas as amostras geradas por um bin´rio a IMAGE_FILTER= # Habilita callgraph CALLGRAPH=0 # Valores dos buffers utilizados. Podem (e devem) ser aumentados de # acordo com o aumento da taxa de amostragem. Caso n~o sejam definidos, a # o OProfile utiliza seus valores padr~o a CPU_BUF_SIZE=24576 BUF_SIZE=397200 BUF_WATERSHED=98304 # Faixa de mem´ria ocupada pelo kernel (gerado sozinho) o KERNEL_RANGE=c0100000,c0308ba9 # Caso se fa¸a o profile de uma m´quina virtual c a XENIMAGE=none # Fim do arquivo

101

BIBLIOGRAFIA
[1] J C Albuquerque e R A Hexsel. Oprofile estendido para depura¸˜o de desempenho. ca WSO’09 VI Workshop de Sistemas Operacionais, p´ginas 1–6, 2009. a [2] J M Anderson et al. Continuous profiling: where have all the cycles gone. ACM Trans on Computer Systems, 15(4):357–390, 1997. [3] T Austin, E Larson, e D Ernst. SimpleScalar: An infrastructure for computer system modeling. IEEE Computer, 35(2):59–67, Fevereiro de 2002. [4] R Azimi, M Stumm, e R W Wisniewski. Online performance analysis by statistical sampling of microprocessor performance counters. ICS’05: Proc 19th Intl Conf on Supercomputing, p´ginas 101–110, 2005. a [5] T Baer. lperfex: A hardware performance monitor for Linux/IA32 Systems. http: //www.osc.edu/~ troy/lperfex/, Janeiro de 2002. Acesso em 30 jul 2008. [6] R Berrendorf e H Zeigler. PCL, the Performance Counter Library, version 2.3. http: //www.fz-juelich.de/jsc/PCL/, Julho de 2003. Acesso em 28 jul 2008. [7] S Browne, J Dongarra, N Garner, G Ho, e P Mucci. A portable programming interface for performance evaluation on modern processors. The Intl Journal of High Performance Computing Applications, 14(3):189–204, 2000. [8] B R Buck e J K Hollingsworth. Using hardware performance monitors to isolate memory bottlenecks. SC Conference, 0:40, 2000. [9] J Cavazos, G Fursin, F Agakov, E Bonilla, M F.P. O’Boyle, e O Temam. Rapidly selecting good compiler optimizations using performance counters. IEEE/ACM International Symposium on Code Generation and Optimization, 0:185–197, 2007. [10] J Dean et al. ProfileMe: hardware support for instruction-level profiling on out-oforder processors. 30th IEEE/ACM Intl Symp on Microarchitecture, p´ginas 292–302, a 1997.

102 [11] L DeRose e D A Reed. SvPablo: A multi-language performance analisys system. ICPP’99: Proc 1999 Intl Conf on Parallel Processing, p´ginas 311–318, Setembro de a 1999. [12] P J Drongowski. Basic performance measurements for AMD AthlonT M 64 and AMD OpteronT M processors. http://developer.amd.com/Pages/1212200690.aspx, Dezembro de 2006. Acesso em 30 ago 2007. [13] T C Ferreto, C A F DeRose, e L DeRose. RVision: An Open and Highly Configurable Tool for Cluster Monitoring. Proc 2nd IEEE/ACM Intl Symp on Cluster Computing and the Grid, p´ginas 75–82, 2002. a [14] T C Ferreto, L DeRose, e C A F DeRose. A hardware counters based tool for system monitoring. Euro-Par Conf, p´ginas 7–16, 2003. a [15] S L Graham, P B Kessler, e M K McKusick. GProf: A Call Graph Execution Profiler. SIGPLAN Notices, 39(4):49–57, 2004. [16] D Heller. Rabbit: A performance counters library for Intel/AMD processors and Linux. http://www.scl.ameslab.gov/Projects/Rabbit, Outubro de 2001. Acesso em 30 jul 2008. [17] J L Hennessy e David A Patterson. Computer Architecture: A Quantitative Approach. Morgan Kaufmann, 4th edition, 2007. ISBN 0-12-370490-1. [18] K Hoste e L Eeckhout. The pitfall in comparing benchmarks using hardware performance counters. ACES Symposium, p´ginas 64–67, Outubro de 2006. a [19] Advanced Micro Devices Inc. AMD Athlon processor x86 code optimization guide, Fevereiro de 2004. [20] C L Janssen. The visual profiler version 0.4. http://aros.ca.sandia.gov/

~cljanss/perf/vprof/, Outubro de 1999. Acesso em 11 ago 2008. [21] D Jones. x86info, a CPU identification utility, v1.24. http://www.codemonkey.org. uk/projects/x86info/, 2001-2009. Acesso em 3 de mai 2009.

103 [22] Martin Alain Kretscheck. Panalyser, uma ferramenta de baixo impacto para medi¸˜o ca de utiliza¸˜o de recursos do sistema operacional Linux. Disserta¸˜o de mestrado, ca ca Departamento de Inform´tica, UFPR, Maio de 2002. http://www.inf.ufpr.br/ a roberto/dissMartin.pdf. [23] M A Kretschek, R A Hexsel, e A L dos Santos. Panalyser, uma ferramenta de baixo impacto para medi¸˜o de utiliza¸˜o de recursos do sistema operacional linux. XXX ca ca Semin Integrado de Software e Hardware, p´ginas 345–358, agosto de 2003. a [24] J Levon. OProfile - A System Profiler for Linux. http://oprofile.sourceforge. net/news/, 2003. Acesso em 11 ago 2008. [25] J Levon. OProfile Manual. http://oprofile.sourceforge.net/docs/index.

php3/, 2003. Acesso em 11 ago 2008. [26] P J Teller e L Salayandia M E Maxwell. Accuracy of performance monitoring hardware. Proc Los Alamos Computer Science Institute Symposium, Outubro de 2002. [27] S V Moore. A comparison of counting and sampling modes of using performance monitoring hardware. Intl Conf on Computational Science, p´ginas 904–912, 2002. a [28] T Mytkowicz, P F Sweeney, M Hauswirth, e A Diwan. Time interpolation: so many metrics, so few registers. 40th IEEE/ACM Intl Symp on Microarchitecture, p´ginas a 286–298, 2007. [29] M Petterson. Linux x86 performance-monitoring counter’s driver, version 2.6.39. http://user.it.uu.se/~ mikpe/linux/perfctr, Junho de 2008. Acesso em 30 jul 2008. [30] J Renau. SESC: cycle accurate architectural simulator. http://sesc.sourceforge. net/index.html, 2002. Acesso em 25 de mai 2009. [31] T Sherwood, E Perelman, G Hamerly, e B Calder. Automatically characterizing large scale program behavior. SIGOPS Operating System Review, 36(5):45–57, 2002.

104 [32] The Standard Performance Evaluation Corporation (SPEC). SPEC CPU2006. http: //www.spec.org/, 2006. Acesso em 11 ago 2008. [33] W Korn W, P J Teller, e G Castillo. Just how accurate are performance counters? IEEE Performance, Computing, and Communications, p´ginas 303–310, 2001. a [34] V M Weaver e S A McKee. Are cycle accurate simulations a waste of time? 7th Workshop on Duplicating, Deconstructing, and Debunking (WDDD), p´ginas 40–53, a Junho de 2008. [35] V M Weaver e S A McKee. Can hardware performance counters be trusted? IEEE International Symposium on Workload Characterization, p´ginas 141–150, Setembro a de 2008.

˜ JOAO CLAUDIO MUSSI DE ALBUQUERQUE

´ ANALISE DO COMPORTAMENTO DA HIERARQUIA DE ´ MEMORIA COM OPROFILE ESTENDIDO

Disserta¸˜o apresentada como requisito parca cial ` obten¸˜o do grau de Mestre. Proa ca grama de P´s-Gradua¸˜o em Inform´tica, o ca a Setor de Ciˆncias Exatas, Universidade Fee deral do Paran´. a Orientador: Prof. Dr. Roberto Andr´ Hexsel e

CURITIBA 2009

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close