Como Volkov e Demmel determinam experimentalmente as latências, tamanhos de linha e tamanhos de página de uma GPU?

Em "LU, QR e fatorações de Cholesky usando recursos vetoriais de GPUs", de Vasily Volkov e James Demmel , há uma maneira interessante de interpretar as latências, tamanhos de linha e tamanhos de página de um cache de um gráfico como este:

Aparentemente, o tamanho da linha é onde o cache começa a atingir o platô (cerca de 32 bytes neste exemplo). De onde isso veio?

E como sabemos que o tamanho da página é onde começa o segundo platô para a memória global?

Além disso, por que as latências acabam diminuindo com um comprimento de passada suficientemente grande? Eles não deveriam continuar aumentando?

Se isso realmente funcionar, e parece, seria incrível, porque podemos obter muitos dados não documentados sobre o cache de uma GPU.

Se isso realmente funcionar, e parece, seria incrível, porque podemos obter muitos dados não documentados sobre o cache de uma GPU.

Um aspecto frustrante da pesquisa em computação de alto desempenho é vasculhar todos os conjuntos de instruções não documentados e recursos de arquitetura ao tentar ajustar o código. No HPC, a prova está no benchmark, seja o High Performance Linpack ou o STREAMS. Não tenho certeza se isso é "impressionante", mas é definitivamente como as unidades de processamento de alto desempenho são avaliadas e avaliadas.

Aparentemente, o tamanho da linha é onde o cache começa a atingir o platô (cerca de 32 bytes neste exemplo). De onde isso veio?

Você parece familiarizado com os conceitos de desempenho da hierarquia de cache, descritos como a "montanha da memória" nos Sistemas de Computador de Bryant e O'Hallaron : a perspectiva de um programador , mas sua pergunta indica uma falta de entendimento profundo de como cada nível de cache em si trabalho.

Lembre-se de que um cache contém "linhas" de dados, ou seja, faixas de memória contígua que são harmonizadas com um local de memória em algum lugar do armazenamento principal. Ao acessar a memória dentro de uma linha, temos um "acerto" de cache, e a latência associada à recuperação dessa memória é chamada de latência para esse cache específico. Por exemplo, uma latência de cache L1 de 10 ciclos indica que toda vez que o endereço de memória solicitado já estiver em uma das linhas de cache L1, esperamos recuperá-lo em 10 ciclos.

Como você pode ver na descrição do indicador de referência de busca de ponteiros, são necessários passos de comprimento fixo na memória. OBSERVAÇÃO: Esse benchmark NÃO funcionaria conforme o esperado em muitas CPUs modernas que apresentam unidades de pré-busca com "detecção de fluxo" que não se comportam como caches simples.

Faz sentido, então, que o primeiro platô de desempenho perceptível (a partir do passo 1) seja um passo que não seja reutilizado pelas falhas anteriores do cache. Quanto tempo um passo deve ter antes de passar completamente pela linha de cache recuperada anteriormente? O comprimento da linha de cache!

E como sabemos que o tamanho da página é onde começa o segundo platô para a memória global?

Da mesma forma, o próximo estágio de avançar além da reutilização será quando a página de memória gerenciada pelo sistema operacional precisar ser trocada a cada acesso à memória. O tamanho da página da memória, diferente do tamanho da linha de cache, normalmente é um parâmetro que pode ser definido ou gerenciado pelo programador.

Além disso, por que as latências acabam diminuindo com um comprimento de passada suficientemente grande? Eles não deveriam continuar aumentando

Essa é definitivamente a parte mais interessante da sua pergunta e explica como os autores postulam a estrutura do cache (associatividade e número de conjuntos) com base nas informações que eles coletaram anteriormente (tamanho das linhas de cache) e no tamanho do conjunto de trabalho de dados sobre os quais estão caminhando. Lembre-se da configuração experimental que os passos "envolvem" a matriz. Para um passo grande o suficiente, a quantidade total de dados da matriz que precisa ser mantida no cache (o chamado conjunto de trabalho) é menor porque mais dados na matriz estão sendo ignorados. Para ilustrar isso, você pode imaginar uma pessoa subindo e descendo continuamente um conjunto de escadas, apenas dando cada quarto passo. Essa pessoa está executando menos etapas totais do que alguém executando a cada 2 etapas. Essa ideia é declarada de maneira um tanto estranha no artigo:

Quando o ritmo é muito grande, o conjunto de trabalho diminui até que caiba novamente no cache, desta vez produzindo conflitos de conflito se o cache não for totalmente associativo.

Como Bill Barth menciona em sua resposta, os autores declaram como fazem esses cálculos no artigo:

Os dados da Fig. 1 sugerem um TLB de 16 entradas totalmente associativo (sem sobrecarga TLB para matriz de 128 MB, passo de 8 MB), um cache L1 associativo definido de 20 vias (um array de 20 KB a 1 KB de largura cabe em L1) e um de 24 vias defina o cache L2 associativo (de volta à latência de acerto L2 para a matriz de 768 KB, avanço de 32 KB). Esses são os números efetivos e a implementação real pode ser diferente. Seis caches L2 associativos ao conjunto de quatro vias também correspondem a esses dados.

Eu diria que o parágrafo na página 3 que começa "Uma latência maior indica mais erros de cache". explica muito do que você está pedindo muito bem.