Rodrigo Strauss :: Blog
As implicações do HyperThreading
Slava Oks, da equipe do SQL Server, escreveu em um post recente que os clientes têm reportado problemas de queda de performance em servidores com processadores HT (como o Pentium 4 HT). Nesse post ele explica o problema e prova que ele realmente acontece usando um programa de exemplo. Veja o post dele para mais detalhes. E eu vou aproveitar esse assunto para divagar...
O que acontece é o seguinte: apesar de ter dois núcleos lógicos separados, em um processador HT eles compartilham os caches L1 e L2 entre si. Isso quer dizer que, se uma thread que acessa uma grande quantidade de memória de uma vez (como o lazy writer do SQL ou uma thread que lida com streaming de outra aplicação qualquer) estiver rodando no mesmo processador físico, ele vai acabar por sujar o cache toda vez. Esse efeito de cache trash também acontece com um processador single core, mas o que piora a situação nesse caso é que, além do cache miss, a worker thread do SQL vai ter que esperar a lazy writer thread liberar um spinlock. Em um processador single core, um spinlock não trava coisa nenhuma, já que não há possibilidade do scheduler do Windows colocar duas threads para rodar ao mesmo tempo. O máximo que acontece (em kernel mode) é subir a IRQL para que nenhuma INT interrompa a thread enquanto ela está sincronizada.
O problema de cache trash não ocorre quando dois processadores físicos são usados porque, como os caches são separados, assim que o segundo processador liberar o spinlock as estruturas usadas pela worker thread estaram no cache (muito provavelmente). Assim, a thread voltará rodando em velocidade muito maior do que uma thread no segundo core de um processador HT, já que ela teria vários roundtrips até a RAM graças aos cache miss.
Expandindo o problema além do SQL Server, já é sabido que aplicações multimídia são os maiores "destruidores de cache", já que elas lêem grande quantidade de dados na memória de forma sequencial, sem reaproveitar. Os aplicativos comuns (digamos, não-multimídia) costumam acessar quase sempre as mesmas posições na memória, o que faz com que os caches do processador aumentem bastante o desempenho. Os caches L1 e L2 estão "mais perto" do processador, e seu tempo de acesso é bem menor do que o da memória RAM. Como as aplicações multimídia lêem muitos dados e de forma sequencial, não há como fazer cache disso, e o processador quase sempre terá um "cache miss" tanto em L1 quanto em L2 na hora de fazer uma leitura na memória.
O efeito de cache trash também acontece quando você usa uma aplicação multimidia no seu computador com um processador, já que todas as threads de todos os programas usam o mesmo L1 e L2. Sendo assim, ouvir mp3 ou rodar qualquer tipo de software que de streaming reduz o desempenho de computadores com o cache menor (como Celeron), já que o player vai sujar o cache durante o tempo todo e as outras thread vão sofrer com o cache miss toda hora. Por isso que os processadores para servidor (como o Xeon) têm um cache maior, porque a probabilidade de uma thread encontrar os dados nos cache é maior, o que faz com que a thread rode mais rapidamente. Só que a memória cache é cara, o que explica a maior disponibilidade em servidores...
Para mais informações, leia:
- Artigo sobre cache no Ars Technica
- CPU caches, HyperThreading, Xeon, Pentium 4 e Celeron na Wikipedia.
Em 14/11/2005 16:14, por Rodrigo Strauss





Cara, a tua página inicial tá com problema na parte dos blogs, se é q vc já não viu... (Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in XXX). Se quiser apagar este post, sinta-se em casa... hehe