Por que a velocidade de gravação para RAM é menor que a velocidade de leitura? E como os caches entram em cena?

Question

Em primeiro lugar, isso é verdade, certo? Eu sinto que as leituras sempre serão mais rápidas do que as escritas, e também esse cara aqui faz algumas experiências para" provar ". Ele não explica porque, apenas menciona "problemas de cache". (e seus experimentos não parecem se preocupar com pré-busca)

Mas eu não entendo o porquê. Se for importante, vamos supor que estamos falando sobre a arquitetura Nehalem (como o i7), que tem L1, cache L2 para cada núcleo e, em seguida, um cache L3 inclusivo compartilhado.

Provavelmente isso acontece porque eu não entendo corretamente como as leituras e as gravações funcionam, então escrevo meu entendimento. Por favor, me diga se algo está errado.

If I read some memory, following steps should happen: (assume all cache misses)

    1. Check if already in L1 cache, miss
    2. Check if in L2 cache, miss
    3. Check if in L3 cache, miss
    4. Fetch from memory into (L1?) cache

Não tenho certeza sobre a última etapa. Os dados infiltram-se em caches, o que significa que, em caso de falha no cache, a memória é lida primeiro em L3 / L2 / L1 e depois lida a partir daí? Ou pode "ignorar" todos os caches e, em seguida, o cache acontece em paralelo para mais tarde. (leitura = acessar todos os caches + buscar da RAM para o cache + ler do cache?)

Then write:

    1. All caches have to be checked (read) in this case too
    2. If there's a hit, write there and since Nehalem has write through caches, 
write to memory immediately and in parallel
    3. If all caches miss, write to memory directly?

Novamente, não tenho certeza sobre a última etapa. Pode escrever ser feito "ignorando" todos os caches ou escrita envolve sempre lendo para o cache primeiro, modificando a cópia em cache e deixando o hardware write-through realmente gravar no local da memória na RAM? (escrever = ler todos os caches + buscar da RAM para o cache + escrever para o cache, escrito para a RAM em paralelo == > escrever é quase um superconjunto de leitura?)

    

Answer 1

Memory must store its bits in two states which have a large energy barrier between them, or else the smallest influence would change the bit. But when writing to that memory, we must actively overcome that energy barrier.

Superar a barreira de energia na RAM requer espera enquanto a energia é movimentada. Basta olhar para ver o que o bit está definido para leva menos tempo.

Para mais detalhes, consulte MSalters excelente resposta para uma pergunta um pouco semelhante .

Não estou certo o suficiente dos detalhes de como o cache interage com a RAM para responder a essa parte da questão com qualquer autoridade, por isso deixarei para outra pessoa.

    

Answer 2

Write Case: Se você tiver algo para gravar na memória e tiver um bom controlador de memória, ignorando todo o cache, tudo o que você precisa fazer é enviar uma transação para o controlador de memória com os dados quer escrito. Por causa das regras de ordenação de memória, assim que a transação deixa o núcleo, você pode passar para a próxima instrução porque pode assumir que o hardware está cuidando da gravação na memória. Isso significa que uma gravação praticamente não leva tempo.

Caso de leitura: Por outro lado, uma leitura é uma operação totalmente diferente e é muito assistida pelo armazenamento em cache. Se você precisar ler os dados, não poderá continuar com o próximo passo do programa até ter os dados em mãos. Isso significa que você precisa verificar os caches primeiro e depois a memória para ver onde estão os dados. Dependendo de onde os dados estão, sua latência sofrerá de acordo. Em um sistema sem pré-busca, sem pipelining, você está apenas gravando ciclos centrais esperando que os dados voltem para que você possa passar para a próxima etapa. O cache e a memória são ordens de magnitude mais lentas que a velocidade do núcleo / espaço de registro. É por isso que a leitura é muito mais lenta do que uma gravação.

Voltando à transação de gravação, o único problema com que você pode se deparar com velocidade é se você estiver fazendo leituras depois de uma transação de gravação para o mesmo endereço. Nesse caso, sua arquitetura precisa garantir que a sua leitura não atrapalhe sua gravação. Se isso acontecer, você receberá os dados errados de volta. Se você tiver uma arquitetura realmente inteligente, como essa gravação está se propagando em direção à memória, se uma leitura para o mesmo endereço aparecer, o hardware pode retornar o caminho de dados antes que ele saia da memória. Mesmo nesse caso de leitura após gravação, não é a gravação que leva um tempo da perspectiva do núcleo, é a leitura.

De uma perspectiva de RAM: Mesmo se não estamos falando de um núcleo e estamos falando apenas de RAM / controlador de memória, fazer uma gravação no MC resultará no armazenamento do MC em um buffer e enviando uma resposta dizendo que a transação está completa (mesmo que não seja). Usando buffers, não precisamos nos preocupar com as velocidades reais de gravação de DIMM / RAM, porque o MC cuidará disso. A única exceção a esse caso é quando você está fazendo grandes blocos de gravações e vai além dos recursos do buffer do MC. Nesse caso, você precisa começar a se preocupar com a velocidade de gravação da RAM. E é isso que o artigo vinculado está se referindo. Então você tem que começar a se preocupar com as limitações físicas de ler vs escrever velocidades que a resposta de David toca. Geralmente isso é uma coisa estúpida para um núcleo fazer de qualquer maneira; é por isso que o DMA foi inventado. Mas isso é outro assunto.