Experimentos com a memória cache do CPU

Transcrição

1 Experimentos com a memória cache do CPU Alberto Bueno Júnior & Andre Henrique Serafim Casimiro Setembro de

2 Contents 1 Introdução 3 2 Desvendando o cache Para que serve o cache? Funcionamento básico Cache misses Causando falhas de cache Teste 1: Percorrendo matrizes O código O programa Testes Conclusões Teste 2: Somando vetores O código O programa Testes Conclusões Teste 3: Memória compartilhada entre cores O código O programa Testes Conclusões Conclusões gerais 23 5 Bibliografia 24 2

3 1 Introdução Este é um trabalho feito para a disciplina MAC Organização de Computadores, ministrada, em 2010, pelo professor Alfredo Goldman ( Esta disciplina é oferecida aos alunos de graduação em Ciência da Computação do Instituto de Matemática e Estatística (IME - da Universidade de São Paulo (USP - O objetivo é mostrar algumas experiências que podem ser feitas com a memória cache do CPU. 2 Desvendando o cache 2.1 Para que serve o cache? A memória cache é uma forma utilizada pelo CPU para diminuir o tempo de acesso à memória. O cache é muito menor do que a memória principal, tanto em bytes quanto espaço físico, muitas vezes cabendo no próprio chip do processador. Além disso, o tempo de acesso ao cache é muito menor. 2.2 Funcionamento básico O cache é dividido nas chamadas linhas de cache, onde cada uma delas contém 3 campos: data: dados index: um índice que indica a posição daquela linha no cache tag: um índice que indica qual é a posição da memória principal que contém a outra cópia do dado Dessa forma, quando o processador recebe uma instrução que precisa fazer uma leitura ou escrita na posição de memória x, ele verifica se existe alguma linha de cache cujo campo tag contém o valor x. Se ele encontrar, dizemos que ocorreu um cache hit. Caso contrário, ocorreu um cache miss. Quando ocorre um cache miss, uma nova linha é criada no cache, colocando o valor x no campo tag. Depois disso o processador tem que copiar os dados da memória principal para essa nova linha (no caso em que a instrução foi de leitura) ou copiar para a memória (caso de escrita). Um detalhe importante 3

4 é que para criar uma nova linha no cache, o mesmo precisa abrir mão de outra linha. A heurística utilizada pelo processador para escolher tal linha é chamada de Política de substituição. 2.3 Cache misses Existem três tipos de cache miss: Leitura de instrução: É quando o processador não encontra um instrução no cache e então tem que buscá-la na memória principal, fazendo com que o processo tenha que esperar até que a instrução seja obtida. É o que causa mais delay. Leitura de dados: É quando o processador não encontra um determinado dado no cache. Enquanto o dado não é retornado da memória principal, as instruções que não dependem daquela leitura podem ser executadas. Assim que o dado vier da memória, as instruções dependendes daquela leitura podem voltar à execução. É o que causa delay mediano. Escrita de dados: Semelhante ao item acima, com a diferença de que a escrita na memória principal pode ser enfileirada (para ser escrita, de fato, mais tarde). Assim, o processador só escreve os dados na memória principal quando esta fila está cheia. É o que causa menos delay. 3 Causando falhas de cache Nesta seção estão alguns exemplos de como se pode causar falhas de cache. Algumas considerações preliminares acerca dos testes: Computador: A máquina utilizada tem o processador Intel Core 2 Duo 2.26 GHz com 3 MB de cache L2. Sistema operacional: Ubuntu Linux Linguagem de programação: A linguagem utilizada foi C. Compilação de código: O compilador utilizado foi o gcc, com as opções -O1, -O2, -O3, -O4, dependendo do teste. 4

5 Medida de consumo de tempo: A ferramenta utilizada para medir o tempo de execução dos programas foi /usr/bin/time, do Linux, com a opção %U, que mede a quantidade de tempo que o processador gastou processando as instruções do programa (não conta o tempo de criação do processo no sistema operacional nem o tempo em que o processo está esperando na fila do S.O., por exemplo). Medida do número de cache misses: Foi utilizada a ferramenta valgrind para medir o número de falhas de cache, com a opção tool=cachegrind. 5

6 3.1 Teste 1: Percorrendo matrizes O código teste1.c: 1 #include <s t d i o. h> 2 #include <s t d l i b. h> int main ( int argc, char argv [ ] ) { 6 int i, j, s i z e ; 7 int p ; 8 9 s i z e = a t o i ( argv [ 1 ] ) ; / matriz de s i z e l i n h a e s i z e colunas / p = ( int ) malloc ( s i z e sizeof ( int ) ) ; 12 for ( i = 0 ; i < s i z e ; i ++) 13 p [ i ] = ( int ) malloc ( s i z e sizeof ( int ) ) ; i f ( argc == 2) { / Se f o i passado apenas um argumento, p e r c o r r e por l i n h a s / 16 for ( i = 0 ; i < s i z e ; i++) { 17 for ( j = 0 ; j < s i z e ; j++) { 18 p [ i ] [ j ] = 0 ; 19 } 20 } 21 } else {/ Senao, p e r c o r r e por colunas / 24 for ( i = 0 ; i < s i z e ; i++) { 25 for ( j = 0 ; j < s i z e ; j++) { 26 p [ j ] [ i ] = 0 ; 27 } 28 } 29 } for ( i = 0 ; i < s i z e ; i ++) 32 f r e e ( p [ i ] ) ; 33 f r e e ( p ) ; 34 return 0 ; 35 } 6

7 3.1.2 O programa O programa teste1.c aloca na memória uma matriz de inteiros com size linhas e size colunas, onde size é um argumento passado para o programa pela linha de comando. Em seguida, a matriz é preenchida com zeros. A principal questão do problema é o modo como a matriz é percorrida. Se nenhum argumento, além de size, for passado, a matriz será percorrida por linhas (isto é, serão zerados os elementos p[0][0], p[0][1],...,p[0][size - 1], p[1][0],..., p[size - 1][size - 1], nesta ordem). Caso contrário, ela será percorrida por colunas (p[0][0], p[1][0],..., p[size - 1][0], p[0][1],..., p[size - 1][size - 1]). 7

8 3.1.3 Testes Consumo de tempo No gráfico acima, as linhas tracejadas representam os testes por linha, enquanto as linhas continuas representam os testes por coluna. As cores representam o nível de otimização usado pelo compilador gcc. O tamanho da matriz (a variável size) foi variado de 0 até 15000, de 1000 em

9 Falhas de cache O esquema de cores e linhas do gráfico acima é o mesmo do gráfico por tempo. A diferença agora é que o eixo vertical representa a porcentagem de misses do L2 que ocorreram durante a execução do programa (n o de misses por n o de acessos ao cache). 9

10 3.1.4 Conclusões Nesse teste estamos atacando uma característica da linguagem de programação C, que é a de armazenar as matrizes na memória alocadas em blocos de linhas. Assim, posições adjacentes em uma mesma linha estão também fisicamente adjacentes na memória. Independentemente da política de substituição dos dados do cache, a escrita que é feita no cache é feita por blocos de memória. Assim, ao acessarmos as posições de memória da matriz, percorrendo-a tanto por linha quanto por coluna, sempre teremos trechos inteiros das linhas da matriz copiadas da memória principal no cache. Isso explica o comportamento das curvas referentes a percorrer a matriz por linha nos gráficos. Vale notar, entretanto, alguns detalhes sobre as curvas referentes a percorrê-la por coluna. No 1 o gráfico, o formato exponencial da curva de gasto de tempo é decorrente do fato que o número de operações cresce conforme o tamanho da matriz, e este cresce exponencialmente conforme size varia linearmente. No 2 o gráfico, o salto que a curva dá ao variar size de 2000 para 3000 é devido o fato de que com size = 2000 a matriz cabe inteira no cache L2, e apartir de size = 3000 já não cabe mais. É isso que faz com que tantos cache misses aconteçam. 10

11 3.2 Teste 2: Somando vetores O código teste2.c: 1 #include <s t d i o. h> 2 #include <s t d l i b. h> 3 4 #define SIZE int main ( int argc, char argv [ ] ) { 7 int o f f s e t, array1, array2, ans, i, j ; 8 9 / Se nenhum argumento f o r passado, roda com o f f s e t 1 / 10 i f ( argc > 1) 11 o f f s e t = a t o i ( argv [ 1 ] ) ; 12 else 13 o f f s e t = 1 ; array1 = ( int ) malloc ( SIZE sizeof ( int ) ) ; 16 array2 = ( int ) malloc ( SIZE sizeof ( int ) ) ; 17 ans = ( int ) malloc ( SIZE sizeof ( int ) ) ; for ( i = 0 ; i < SIZE ; i ++) { 20 array1 [ i ] = rand ( ) %1000; 21 array2 [ i ] = rand ( ) %1000; 22 } for ( i = 1 ; i <= o f f s e t ; i++) { 25 for ( j = i 1; j < SIZE ; j += o f f s e t ) 26 ans [ j ] = array1 [ j ] + array2 [ j ] ; 27 } f r e e ( array1 ) ; 30 f r e e ( array2 ) ; 31 f r e e ( ans ) ; 32 return 0 ; 33 } 11

12 3.2.2 O programa O programa teste2.c aloca três vetores de 10 milhões de posições na memória, inicializa os dois primeiros e depois soma, de posição em posição, os dois e guarda no terceiro. Se um número offset for passado como argumento, o programa soma de offset em offset (isto é, soma a posição 0, depois a posição offset, depois a posição 2 * offset, até y = k * offset tal que y 10 milhões, depois soma 1, 1 + offset, etc). 12

13 3.2.3 Testes Consumo de tempo v1 Para melhorar a legibilidade do gráfico acima, omitimos as linhas referentes às otimizações -O2, -O3, -O4, pois elas apresentaram o mesmo comportamento que a otimizaçao -O1. O gráfico foi feito com o offset variando de 1 até 3001, de 10 em

14 Consumo de tempo v2 O gráfico acima é basicamente a mesma coisa do anterior, mas estendendo a variação até

15 Falhas de cache O gráfico acima mostra, no eixo vertical, a porcentagem de cache misses que ocorreram no cache L2 e, no eixo horizontal, o offset variando de 1 até 4501, de 10 em

16 3.2.4 Conclusões Este teste ilustra dois fatores muito importantes nas políticas de substituição de dados na memória cache: o tamanho dos blocos a serem copiados para a memória de cache e o tempo de permanência dos mesmos lá até que sejam substituídos. Como essas políticas não são muito fáceis de se definir para cada processador, nossa conclusão aqui não é totalmente certa. O 1 o (consumo de tempo) e o 3 o gráfico (cache miss) revelam um comportamento bastante semelhante entre consumo de tempo e cache misses. Dessa forma, vamos nos concentrar em analisar trechos importantes do 2 o gráfico (consumo de tempo - extendido): offset <1000 Aqui encontramos o pico do consumo de tempo. Os valores de offset aqui são bastante pequenos em relação ao tamanho do vetor, o que significa que são necessárias muitas iterações de tamanho offset para percorrê-lo completamente. Conforme o vetor é percorrido de offset em offset posições, blocos do vetor são copiados para o cache. O aumento da taxa de cache misses se deve ao fato de que, na próxima varredura do vetor, os blocos que haviam sido copiados já foram sobreescritos por outros dados. Assim, o mesmo bloco precisa ser recopiado para o cache <offset <3000 Conforme offset vai aumentando, as varreduras do vetor inteiro demoram menos e então blocos de memória passam a utilizados em mais de uma varredura. O fato de essa região também apresentar o vale de consumo de tempo (e o mesmo estar logo após o pico) tem a ver com o equilíbrio entre tempo de retorno ao mesmo bloco de dados e a quantidade de blocos distintos do vetor que estão distribuídos no cache (que neste ponto ainda são muitos, pois offset ainda não cresceu muito) <offset <15000 Conforme offset vai aumentando, o número de blocos distintos do vetor que estão distribuídos no cache também vai diminuindo. E isso faz com que aumente um pouco o número de cache misses. Este crescimento é linear pois a proporção do blocos é diminui lineramente com o crescimento linear de offset. 16

17 offset >15000 O processo tende a ficar constante. Provavelmente aqui já não há mais influências diretas das falhas de cache. Este tempo deve ser somente o tempo de processamento para um número mais ou menos fixo delas. 17

18 3.3 Teste 3: Memória compartilhada entre cores O código teste3.c: 1 #include <s t d l i b. h> 2 #include <sched. h> 3 #include <s t d i o. h> 4 #define SIZE struct s h a r e d d a t a s t r u c t { 7 unsigned int data1 ; 8 unsigned int data2 ; 9 } ; struct s h a r e d d a t a s t r u c t shared data ; static int i n c s e c o n d ( struct s h a r e d d a t a s t r u c t ) ; int main ( int argc, char argv [ ] ) { int i, j, pid, f l a g = 0 ; 18 void c h i l d s t a c k ; i f ( argc > 1) f l a g = 1 ; / Aloca a memoria da p i l h a do segundo processo / 23 i f ( ( c h i l d s t a c k = ( void ) malloc (4096) ) == NULL) { 24 p e r r o r ( Cannot a l l o c a t e stack f o r c h i l d ) ; 25 e x i t ( 1 ) ; 26 } / Cria um c l o n e que roda no mesmo espaco de memoria / 29 / Se por acaso e s t e programa der f a l h a de segmentacao ao rodar, t e n t e t i r a r o da chamada da funcao / 31 i f ( f l a g == 1) { 32 i f ( ( pid = c l o n e ( ( void )&inc second, c h i l d s t a c k +4096, 33 CLONE VM, &shared data ) ) < 0) { 34 p e r r o r ( c l o n e c a l l e d f a i l e d. ) ; 35 e x i t ( 1 ) ; 36 } 37 } / Modifica a primeira v a r i a v e l da s t r u c t compartilhada / 40 for ( j = 0 ; j < SIZE ; j++) { 41 for ( i = 0 ; i < ; i++) { 18

19 42 shared data. data1++; 43 } 44 } return 0 ; } / Funcao que r e p r e s e n t a a execucao do processo f i l h o / 51 int i n c s e c o n d ( struct s h a r e d d a t a s t r u c t sd ) 52 { 53 int i, j ; 54 / Modifica a segunda v a r i a v e l da s t r u c t compartilhada / 55 for ( j = 1 ; j < SIZE ; j++) { 56 for ( i = 1 ; i < ; i++) { 57 sd >data2++; 58 } 59 } 60 } O programa O programa teste3.c possui a estrutura shared data struct, que possui duas variáveis. Se nenhum argumento for passado, o programa teste3.c realiza SIZE 100, 000 incrementos na primeira variável. Caso contrário, ele cria um processo filho, que compartilha a estrutura shared data struct e realiza o mesmo número de incrementos na segunda variável, e depois realiza os incrementos na primeira variável. 19

20 3.3.3 Testes Consumo de tempo No gráfico acima, o tempo consumido pelo programa compilado com as otimazações -O1, -O2, -O3, -O4 é praticamente zero e por isso as barras não aparecem no gráfico. 20

21 3.3.4 Conclusões O Teste 3 mostra que compartilhar memória cache entre processos (ou entre cores, se o processador for multicore) pode causar falhas de cache. A estrutura criada no programa tem dois inteiros (4 bytes cada um), totalizando 8 bytes. Essa quantidade é pequena se comparada ao tamanho do cache line do cache L2, que é de 64 bytes. Isso quer dizer que toda a estrutura cabe em apenas uma cache line. Assim, quando o primeiro processo (processo pai) altera a primeira variável da estrutura, o cache marca aquela linha como suja. Assim, quando o segundo processo (processo filho) tenta alterar a segunda variável da estrutura (que está na mesma cache line) ele percebe que aquela linha está marcada como suja e daí é necessário fazer dois acessos à memória: um para escrever a linha suja na memória principal e outra para copiar para o cache a nova informação da memória principal. Por esse motivo, o caso em que o processo filho é criado (quando passamos um argumento para o programa) leva mais que o dobro do tempo do caso em que ele não é criado. Uma possível solução para esse problema é fazer com que as duas variáveis da estrutura estejam em cache lines diferentes. Um jeito de fazer isso é substituindo as linhas 1 struct s h a r e d d a t a s t r u c t { 2 unsigned int data1 ; 3 unsigned int data2 ; 4 } ; por 1 struct s h a r e d d a t a s t r u c t { 2 unsigned int data1 ; 3 int aux [ 2 0 ] ; 4 unsigned int data2 ; 5 } ; Dessa forma, o vetor aux ocupará 20 4 = 80 bytes na memória, fazendo com que as variáveis data1 e data2 estejam em cache lines diferentes. 21

22 O gráfico abaixo mostra o que acontece com o consumo de tempo fazendo essa modificação. Como a máquina utilizada no teste possui dois cores, os processos rodam em paralelo, consumindo praticamente o mesmo tempo que apenas um processo. 22

23 4 Conclusões gerais A melhor conclusão que pode ser feita a partir dos resultados apresentados é que o programador deve conhecer as formas como o cache é utilizado e, dependendo da aplicação, conhecer a máquina onde tal aplicação irá rodar. Ter esse conhecimento ajuda a diminuir os cache misses e, consequentemente, aumentar o desempenho (em relação ao tempo consumido) da aplicação. Essa não é uma tarefa fácil, pois o simples fato de percorrer uma matriz por colunas na linguagem C pode aumentar em muito o tempo de execução, como foi mostrado aqui. Contudo, qualquer conhecimento pode vir a ser útil. 23

24 5 Bibliografia