MAC0412 – EP1 1 Introduç˜ao 2 Primeiro programa

1 Introdução
MAC0412 – EP1
Experimentos com o cache
Pedro Matiello
Neste exercício, analisamos o comportamento de três pequenos programas
fornecidos pelo professor. O objetivo, em particular, é identificar possíveis
problemas de desempenho decorrentes do uso inadequado do cache do processador.
Sabemos, o cache é uma memória de tamanho reduzido, mas de acesso
mais rápido do que a memória principal. O uso apropriado deste recurso pode
oferecer ganhos significativos de desempenho a alguns programas, reduzindo
o tempo em que o processador fica ocioso para leitura ou escrita da memória.
2 Primeiro programa
O primeiro programa fornecido aloca uma grande região de memória como
uma matriz e preenche com zeros. Este preenchimento pode ser realizado de
duas maneiras, de acordo com argumentos passados na linha de comando:
• Percorrendo a matriz por linhas;
• Percorrendo a matriz por colunas.
Apesar de executarem o mesmo número de operações, a primeira maneira
se mostra mais rápida do que a segunda em testes realizados com o programa
time.
Modo de Execução Tempo Total
Por Linha 0.874s
Por Coluna 3.748s
1

Este comportamento, presenciado anteriormente na disciplina de MAC0300
na implementação de algoritmos para fatoração de matrizes, pode ser explicado
pela disposição dos elementos da matriz na memória. Este primeiro
programa está escrito em C, e esta linguagem armazena matrizes concatenando
suas linhas, uma após a outra. Quando um elemento da matriz é lido
da memória, todos os elementos armazenados na mesma página são armazenados
no cache; o acesso posterior a estes elementos, então, é feito com
menor latência.
Ora, devido à disposição por linhas da matriz, os elementos próximos a
um elemento específico tendem a ser aqueles que estão na mesma linha, e
o acesso por colunas não irá obter as vantagens oferecidas pelo cache. Isto
pode ser verificado pela contagem das falhas de cache, realizada através do
programa valgrind:
Modo de Execução Falhas de Cache
Por Linha 6,281,171
Por Coluna 98,170,003
Este problema das falhas de cache no acesso por colunas é, contudo,
bastante reduzido ou mesmo eliminado em matrizes menores, que podem
ser totalmente ou em grande parte armazenadas no cache. Em matrizes
maiores, porém, páginas de acesso mais recente tomam o lugar de páginas
de acesso mais antigo no cache, e acessos posteriores a estas devem fazer uso
da memória principal.
3 Segundo Programa
O segundo programa realiza a soma de dois vetores, armazenando o resultado
no terceiro. Um número pode ser passado como argumento pela linha
de comando, e o programa então realizará a soma pulando este número de
posições a cada iteração (mas, ainda assim, realizando o mesmo número de
somas no final).
Também aqui, a ordem em que as operações são realizadas afeta o desempenho
do programa. O gráfico abaixo apresenta a média do tempo total
de três execuções do programa para cada valor de salto entre 0 e 100. Novamente,
os dados foram obtidos através do programa time.
Pode-se observar que, para saltos de tamanho entre 0 e 30, o tempo to-
2

1.4
1.2
1
0.8
0.6
0.4
0.2
0
0 20 40 60 80 100
Figura 1: Tempo de execução (s) × Tamanho do salto
tal de execução aumenta a medida que o tamanho do salto aumenta. A
partir deste valor, o tempo total de execução não sofre variações significativas.
Podemos atribuir este comportamento, novamente, às falhas de cache:
no intervalo 0 – 30 estas aumentam com o aumento do tamanho do salto
mas, a partir deste valor limite, as posições acessadas nos vetores já estão
suficientemente distantes para provocar falhas de cache após um número de
iterações muito similar. A tabela abaixo apresenta os valores determinados
pelo valgrind para o número de falhas de cache para alguns valores de salto:
Tamanho do Salto Falhas de Cache
1 3,127,502
10 20,002,511
30 31,252,499
90 31,252,499
4 Terceiro Programa
O terceiro programa instancia uma estrutura contendo duas variáveis de
tipo inteiro. A seguir, dois processos distintos compartilham o acesso a esta
estrutura, de modo que o primeiro processo acesse exclusivamente a primeira
variável e o segundo processo acesse exclusivamente a segunda variável.
Apesar de não ocorrer acesso compartilhado a nenhuma variável, as duas
variáveis da estrutura são alocadas na mesma página de memória. Se cada
3

processo é executado em um core diferente do processador, a escrita em uma
destas variáveis por um dos processos irá acarretar na invalidação do cache
para esta página no core que executa o outro processo, forçando um acesso
desnecessário à memória principal.
O acesso à memória principal, por sua vez, é mais custoso, produzindo
um desempenho inferior ao possível. Podemos eliminar o problema, contudo,
alterando o código do segundo processo para realizar todas as suas operações
em uma variável temporária local, atualizando a variável compartilhada apenas
no fim de sua computação.
A tabela abaixo exibe o tempo consumido pela versão original (que altera
frequentemente a variável compartilhada) e pela versão modificada (que
altera a variável compartilhada apenas no final da computação).
Versão Tempo de Execução
Original 1.561s
Modificada 0.656s
5 Outra Forma de Atrapalhar o Cache
Outras maneiras de minimizar o efeito da ação do cache são possíveis. Uma
delas é sobrecarregá-lo com dados que são desnecessários na computação
sendo realizada. Considere, por exemplo, a estrutura abaixo:
struct Registro {
int campo0;
int campo1[1024];
int campo2[1024];
int campo3[1024];
int campo4[1024];
int campo5[1024];
int campo6[1024];
};
O código abaixo percorre 2000000 um vetor de 500 registros do tipo especificado
acima, realizando operações exclusivamente sobre o campo zero:
struct Registro registros[500];
4

for (i = 0; i < 2000000; i++) {
for (j =0; j < 500; j++) {
registros[j].campo0 = i+j;
}
}
O tamanho expressivo do struct Registro faz com apenas uma pequena
parte do vetor possa ser armazenada no cache em um dado momento. Contudo,
como os campos de 1 a 6 são irrelevantes no laço acima, podemos
removê-los para uma estrutura auxiliar:
struct Registro {
int campo0;
};
struct Registro_aux {
int campo1[1024];
int campo2[1024];
int campo3[1024];
int campo4[1024];
int campo5[1024];
int campo6[1024];
};
O código antes do laço deve ser alterado para declarar também as estruturas
auxiliares, para uma justa comparação:
struct Registro registros[500];
struct Registro_aux registros_aux[500];
for (i = 0; i < 2000000; i++) {
for (j =0; j < 500; j++) {
registros[j].campo0 = i+j;
}
}
E, novamente através de testes com o comando time, podemos verificar
que o tamanho das estruturas de dados utilizadas pode afetar negativamente
o desempenho:
5

Versão Tempo de Execução
Original 11.505s
Modificada 4.222s
6