O que o seu computador faz enquanto você espera

Este artigo examina a velocidade – latência e performance – de vários subsistemas em um PC Intel Core 2 Duo de 3.0GHz moderno. Espero fornecer impressões quanto a velocidade relativa de cada componente e uma cheatsheet para os cálculos de performance. Tentarei mostrar o mundo real dos processos, ao invés de máximas teóricas. As unidades de tempo são nanosegundos (ns, 10^-9 segundos), milisegundos (ms, 10^-3 segundos) e segundos (s). As unidades de processamento são em megabytes e gigabytes por segundo. Vamos começar com CPU e memória:

A primeira coisa que se sobressai é como nossos processadores são absurdamente rápidos. A maior parte das instruções simples no Core 2 gastam um ciclo de clock para serem executadas, ou seja, um terço de nanosegundo a 3 Ghz. Como referência, a luz viaja mais ou menos 4 polegadas (10cm) no tempo de um ciclo do relógio. Vale a pena manter isso em mente ao pensar em otimização – instruções são muito baratas de se executar hoje em dia.

A medida que a CPU trabalha, ela precisa ler e escrever na memória do sistema, que é acessada via caches L1 e L2. Os caches usam static RAM, um tipo muito mais rápido e caro de memória do que a memória DRAM, usada como a principal do sistema.

Os caches são partes inerentes ao processador, e com memórias mais caras conseguimos uma latência muito baixa. Um aspecto em que a otimização, em nível de instrução, ainda é muito relevante é o tamanho da codificação. Devido ao caching, pode haver grandes diferenças de performance entre codificações que se encaixam perfeitamente nos caches L1 e L2 e a codificação que precisa ser empacotada para dentro e para fora dos caches, a medida que é executada.

Normalmente quando a CPU precisa acessar conteúdos em uma região da memória, eles precisam já estar nos caches L1/L2, ou então serem trazidos da memória principal do sistema. Aqui vemos nosso primeiro impacto, um massivo ciclo de latência de ~250 ciclos, que frequentemente leva a um stall, quando a CPU fica sem trabalho enquanto espera. Colocando em perspectiva, a leitura no L1 é como estar pegando um papel em cima da mesa (três segundos), no L2  pegando um livro  numa estante próxima (14 segundos) e na memória principal do sistema, caminhando quatro minutos para ir à lanchonete comprar uma barra de chocolate.

A latência exata da memória principal é variável e depende do aplicativo, assim como de muitos outros fatores. Por exemplo, depende da latência CAS e das especificações do real RAM stick que está no computador. Depende também quão bem sucedido é o processador em preftching – avaliando quais partes da memória serão necessárias com base na codificação que está sendo executada, trazida para os caches antecipadamente.

Examinando a performance do cache L1/ L2 em comparação com a da memória principal, fica claro quanto há a ganhar com caches L2 maiores e com aplicativos desenhados para usá-los bem. Para uma discussão abrangente sobre memória, veja o arquivo em PDF What Every Programmer Should Know About Memory (“O que todo programado deveria saber sobre memória” em português), de Ulrich Drepper. Esse é um bom trabalho sobre o assunto.

As pessoas se referem ao gargalo entre memória e CPU, como o gargalo de von Neumann. Agora, o tráfego de dados de 10GB/s parece decente. Nesse ritmo, você pode ler todos os 8 GB do sistema de memória em menos de um segundo, ou ler 100 bytes em 10ns. Infelizmente, esse rendimento é um máximo teórico (ao contrário da maioria dos outros no diagrama), e não pode ser alcançado devido a atrasos no circuito principal da RAM. Muitos períodos pequenos de espera são necessários ao acessar a memória.

O protocolo elétrico de acessos chama por atrasos depois que a linha de memória e a coluna são selecionadas, e antes que os dados possam ser lidos com segurança, e assim por diante. O uso de chamadas por capacitores para atualizações periódicas dos dados armazenados na memória para que não haja corrupção de bits adiciona sobrecargas. Certos acessos consecutivos de memória podem acontecer mais rapidamente, mas ainda assim há atrasos, que aumentam com acessos randômicos. A latência está sempre presente.

Indo para a southbridge temos uma série de outros barramentos (por exemplo PCIe, USB), e periféricos conectados:  

Infelizmente, a southbridge abriga alguns processos lentos, mesmo que a memória principal esteja trabalhando rápido, se comparada aos discos rígidos. Esta é a razão pela qual muitos carregamentos de trabalho são dominados pelo I/O do disco, e porque a performance do database pode desabar como num penhasco, uma vez que os buffers de memória são estourados. Esse é, também, o porquê da plenitude de RAM (para buffering) e discos rígidos rápidos serem tão importantes no desempenho global do sistema.

Embora a performance “sustentada” do disco seja real – quando se trata do que é realmente entregue pelo disco em situações do mundo real – ele não conta toda história. A perdição da performance de disco são as buscas, o que envolve a movimentação das cabeças de escrita/ leitura através da superfície do disco até a trilha certa e, então, esperar o giro até a posição correta do setor que deve ser lido.

A RPM do disco diz respeito a sua velocidade de rotação: quanto mais RPM, menos tempo médio de espera até chegar ao setor desejado – assim, mais rotação significa um HD mais rápido. Um lugar bacana para ler sobre o impacto das buscas é o trabalho de uma dupla de graduandos de Stanford: Anatomy of a Large-Scale Hypertextual Web Search Engine (em PDF).

Quando o disco está lendo um arquivo grande e contínuo, ele obtém maiores velocidades sustentadas de leitura, por não haver buscas. A desfragmentação de arquivos do sistema visa manter os arquivos em porções contínuas no disco, para minimizar buscas e incrementar os outputs. Quanto à rapidez de um computador, a performance sustentada é menos importante do que o tempo de busca e o número de operações I/ O randômicas (leituras/ escritas) que um disco pode fazer por unidade de tempo. Discos solid state podem ser uma grande opção aqui.

O cache dos discos rígidos também ajudam na performance. Seu tamanho pequeno – um cache de 16 MB em um drive de 750MB ocupa somente 0,002% do disco – sugerem que são inúteis, mas na realidade sua contribuição é alinhar dados e depois processá-los em grupos, permitindo dessa forma que o disco “planeje” a ordem dos dados para minimizar buscas. As leituras também podem ser agrupadas desta forma buscando performance, e tanto o OS e o disco firmware se empenham nessas otimizações.

Finalmente, o diagrama tem várias performances do mundo real para redes e barramentos. O Firewire é mostrado como referência, mas não está disponível nativamente no chipset x86 da Intel. É engraçado pensar na internet como um barramento de computador.

A latência de um website rápido (o google.com, por exemplo) é de aproximadamente 45 ms, comparável com a latência de busca de um HD. Na verdade, os HDs obtêm dados da memória central em uma proporção cinco vezes maior que a Internet no mesmo tempo. A Internet residencial ainda permanece atrás em velocidade, quando comparada com as leituras de dados dos HDs, mas “a rede é o computador”, de uma maneira bastante literal hoje em dia. O que acontecerá quando a Internet for mais rápida que os HDs?

Espero que este diagrama seja útil. É fascinante para mim olhar todos esses números juntos e ver como chegamos longe. Aqui tem um diagrama completo mostrando tanto as south, quanto as northbridges.

***

Texto original disponível em: http://duartes.org/gustavo/blog/post/what-your-computer-does-while-you-wait