logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

follow us in feedly

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:


Em 14/11/2005 16:14, por Rodrigo Strauss


  
 
 
Comentários
Charles Schneider Pereira | e-mail | em 14/11/2005 | #
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
Rodrigo Strauss | website | em 14/11/2005 | #
Valeu, vou arrumar. Eu fiz uma faxina nas tabelas do mysql (os nomes estavam horríveis e inconsistentes) e coloquei alguns recursos novos no site (como o # do lado dos comentários para ter um link para ele). Mas pelo jeito eu esqueci de arrumar algumas coisas... :-)
Alfred Gary Myers Jr. | website | em 15/11/2005 | #
Não seria o caso dos programas que lidam com streams evitarem o uso do L1 e L2 já que além de não ganharem nada com o seu uso ainda atrapalham os programas que poderiam tirar proveito da cache?
Existem alguma instrução assembly ou de alguma linguagem de alto nível que nos permita lidar com isto?
Rodrigo Strauss | website | em 15/11/2005 | #
Dei uma procurada na USENET e só achei como desabilitar para o cache para o processador inteiro, e quando você desabilita é obrigado a chamar a instrução WBINVD para invalidar o cache:

http://groups.google.com/group/comp.sys.intel/browse_thread/...
http://groups.google.com/group/comp.lang.asm.x86/browse_thre...

Invalidando o cache ele não poderia mais ser usado por outra thread. O cache trash torna o cache inútil, desligar o cache no processador inteiro teria o mesmo efeito.

Já li em algum lugar sobre suporte a isso em novos processadores. Se eles não fizeram ainda é pq não deve ser tão fácil ou lucrativo.
Algo a dizer?
Nome:


Site:


E-mail:


Escreva o número vinte e seis:


 Não mostre meu e-mail no site, não serve pra nada mesmo...

Comentário





Os comentários devem ser sobre assuntos relativos ao post, eu provavelmente apagarei comentários totalmente offtopic. Se quiser me enviar uma mensagem, use o formulário de contato. E não esqueça: isso é um site pessoal e eu me reservo o direito de apagar qualquer comentário ofensivo ou inapropriado.
rebarba rebarba
  ::::