Série – Inside The Machine – Introdução

Quando você pensa na memória do seu servidor, qual é a primeira coisa que te vem à cabeça? Gigabytes? Terabytes? Enfim, espaço? E quando você pensa em desempenho, a primeira coisa que você pensa são os Gigahertz da CPU?

Nessa série de artigos quero explorar o subsistema de memória de um ponto de vista um pouco diferente: o foco será a interação entre ele e a CPU. Falaremos do desempenho da memória e como ela pode afetar – e afeta! – o desempenho como um todo do seu servidor, e o que você pode – e não pode – fazer a respeito em relação ao seu banco de dados (ou qualquer outra aplicação).

Confesso que essa série estava parada no meu OneNote há algum tempo. Conversando com o meu amigo Luan Moreno recentemente cheguei a conclusão que era hora de tirar a poeira e postá-los. :)

Velocidade do processador é tudo?

Se você não conhece Martin Thompson, recomendo adicionar o blog ao seu leitor de RSS favorito e acompanhar o que ele escreve e palestra. Ele é definitivamente uma das grandes referências no assunto de HPC (High Performance Computing) e baixa latência e vamos utilizar alguns testes escritos por ele (e alguns meus) durante essa série, então nada mais justo do que começar fazendo referência a uma frase sua: “The real design action is nn the memory sub-systems.” [2]

Você já percebeu que ultimamente têm sido bastante falado sobre a velocidade dos processadores e como seu desempenho parou de evoluir nos últimos anos em favor do aumento da quantidade de cores? Quem desenvolve software com certeza já ouviu que deve aprender desenvolvimento de software com paralelismo para não arriscar ficar sem emprego no futuro. A famosa frase “the free lunch is over” tem sido repetida diversas vezes nas últimas conferências mundo à fora desde que o guru de C++ Herb Sutter escreveu o seu artigo homônimo em 2005 para o respeitado journal Dr. Bobb’s [1].

De fato a frequência dos processadores parou de subir, principalmente devido às questões de economia de energia e dissipação de calor, como é possível observar claramente no gráfico abaixo tirado do artigo de Sutter:

Intel CPU Trends Chart

Intel CPU Trends 1970-2010. Fonte: The Free Lunch Is Over, Herb Sutter

Mas olhar apenas para os GHz não conta toda a história.

Linha Modelo Ops/Sec Ano de Lançamento
Core 2 Duo  P8600 @ 2.40GHz 1434 2008
Xeon  E5620 @ 2.40GHz 1768 2010
Core i7  i7-2677M @ 1.80GHz 2202 2011
Core i7  i7-2720QM @ 2.20GHz 2674 2011

Podemos observar na tabela acima que o desempenho geral do CPU continua subindo, mesmo que a frequência esteja, de certa forma, estagnada. Medimos esse desempenho através de IPCs, ou Instructions per Cycle.

Ou seja, em um processador de 2 GHz capaz de fazer o retirement de até 4 instruções por ciclo (IPC), como é o caso da microarquitetura Nehalem, no caso ideal o seu desempenho pode chegar a 8 bilhões de instruções por segundo! Nada mal.

Single Threaded Performance Trends Chart

Single Threaded Performance Trends 1995-2011 [3]

Então se o desempenho das CPUs efetivamente continua subindo (apesar de claramente em um ritmo menor) mesmo que os clocks se mantenham estáveis, quem é o responsável por segurar o desempenho geral dos sistemas?

Refazendo a pergunta anterior de outra forma… Em um workload onde o gargalo não se encontra nem em I/O nem na CPU, o que impede o seu processador de realizar o trabalho mais rapidamente?

Você provavelmente já deve ter matado a charada: no acesso à memória, ou o que chamamos de latência. Mas esse fato não parece ser muito óbvio à primeira vista: memória não é só uma questão de quantidade.

Latência? E acesso à memória lá tem custo?!

Em relação ao custo de acesso ao disco, a latência do acesso à memória é irrisório.

A memória, porém, é o que previne que o seu sistema rode em seu desempenho máximo. Isso ocorre pois o acesso à memória é significativamente inferior à velocidade do processador, e essa diferença só cresceu ainda mais nas últimas décadas. Esse fenômeno é chamado de “Memory Wall“, termo cunhado no paper [4].

Se pudéssemos trabalhar com dados apenas nos registradores, a “memória” com a menor latência no CPU, o nosso processador poderia utilizar todo o seu potencial computacional. Infelizmente, principalmente em servidores de bancos de dados, isso está muito longe da realidade. É comum trabalharmos com working sets de dezenas ou centenas de GB. E por isso pagamos o custo de acesso à memória o tempo todo. Enquanto esse acesso ocorre, o processador precisa ficar esperando pelos dados até que ele possa voltar a trabalhar, efetivamente gastando ciclos de clock à toa. Um cache miss pode custar centenas de ciclos de clock do processador, tempo que ele poderia gastar realizando operações ao invés de esperar por dados para serem processados.

Com o fim da era de crescimento contínuo dos clocks dos processadores os engenheiros têm evoluído as microarquiteturas a fim de amenizar o impacto da latência do acesso à memória principal do sistema. Os processadores se utilizam de diversos artifícios para esconder essa latência, e assim diminuir a penalidade causada pela disparidade entre o desempenho entre eles. Já falei sobre um deles aqui, o Hyper-Threading (SMT). Ao longo da série, são esses mecanismos, artifícios e otimizações que vamos tratar, além de outros assuntos que estejam relacionados.

Seguem alguns dos tópicos que tenho planejado para essa série:

  • Microprocessadores
  • Latência
  • Caches e Hierarquia da memória
  • Intel SpeedStep e Turbo Boost
  • Hyper-Threading (SMT)
  • FSB e NUMA
  • Superscalar
  • Pipelining
  • Spinlocks & Latches
  • Algoritmos e Otimizações no SQL Server 2014

Tentarei seguir a lista acima, mas vou manter a possibilidade de inserir, mesclar ou remover tópicos conforme a série se desenvolve. Manterei a lista atualizada de acordo, incluindo atualizações (adição de tópicos, etc.) e links para os artigos conforme vão sendo lançados. Portanto se quiser acompanhar você pode marcar essa página nos seus favoritos, ou adicionar o feed do blog ao seu leitor RSS favorito, como preferir.

Referências:

[1] Sutter – The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
[2] Thompson – Mythbusting modern hardware to gain “Mechanical Sympathy”
[3] Moore – Data Processing in Exascale-class Computing Systems
[4] Wulf, McKee – Hitting the Memory Wall: Implications of the Obvious

Pin It

3 thoughts on “Série – Inside The Machine – Introdução

  1. Pingback: Inside the Machine Parte 2 – Processadores | ivanglima.com

  2. Pingback: Performance Counter: Processador

  3. Pingback: Palestra Windows Internals | ivanglima.com

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>