Como os "números de latência que todo programador deve conhecer" de Jeff Dean podem ser precisos no contexto de diversas implementações de hardware?

Refiro-me a este gráfico de números de latência , atribuído a Jeff Dean no Google.

O que eu não entendo é: esses números não variam de um conjunto de hardware para o outro? Como eles podem ser precisos para todos os diferentes tipos de RAM, CPU, placa mãe, disco rígido, etc?

Esses números (também listados na programação Teach-in da Norvig em 10 anos ) são aproximados, úteis apenas como (ordem de) magnitude.

Na verdade, o hardware de hoje (pelo menos para desktops ou laptops) não varia muito, mesmo entre um laptop barato de 300 € e uma estação de trabalho de 10k € de alta qualidade. A velocidade varia em um fator de aproximadamente 2 ou 4, no máximo. Essa estação de trabalho pode ter um disco maior, mais núcleos, cache e RAM. No entanto, isso não tem muito impacto no desempenho bruto de thread único.

Veja algumas figuras em http://openbenchmarking.org/ ou alguns comparadores de CPU.

A chamada lei de Moore está morrendo . Minha área de trabalho com mais de 3 anos em casa (um i3770K) pode ser substituída (hoje, em março de 2016) por um i6700, que é apenas 20% mais rápido.

Os números não foram feitos para serem precisos. São as relações entre as ordens de magnitude entre as camadas que importam.

No entanto, quando uma tecnologia disruptiva aparece (por exemplo, computação em nuvem, ethernet de 10 GB / 100 GB, novo módulo do kernel de rede, redes de armazenamento SSD, virtualização e containerização), esses números podem ser invalidados devido a novos níveis que aparecem, desaparecem ou são embaralhados.

Ao programar em um nível muito alto - onde toda a computação, rede, análise etc. são executadas usando bibliotecas não escritas por você, saber os números de desempenho das operações de baixo nível pode não ajudar muito, pois sua oportunidade de melhorar cada o desempenho da biblioteca é bastante limitado ou totalmente impossível.

Em vez disso, leia atentamente a documentação relacionada ao desempenho de cada biblioteca. Se uma biblioteca não vier com eles, pergunte a eles - faça disso um problema. Ou aprenda como comparar o software da maneira correta.

Ter um entendimento básico dos números de latência é importante quando você é contratado por uma empresa que projeta e fabrica componentes de software. Compare isso com uma empresa que projeta e fabrica carros e todos os componentes contidos nele - o proverbial "reinventar a roda" (borracha, pressão dos pneus, pisos, etc.)

A maioria das empresas de software não trabalha no nível de componente - sistemas de software funcionais inteiros podem ser construídos a partir da montagem de componentes. Essas empresas de software não precisam se concentrar em como projetar componentes em termos de latências; em vez disso, eles precisam avaliar a qualidade dos componentes que escolherem.

Para resumir, (1) é muito possível que você não precise saber os números de latência; (2) a menos que você queira ser contratado por uma empresa que fabrica componentes de software (bibliotecas), seja para venda ou para uso interno (como em algumas das maiores empresas de software do mundo), (3) se você precisar desses números, é seu trabalho fazer os benchmarks você mesmo, de uma maneira cientificamente correta, ou você não deve estar trabalhando em componentes de software.

Ninguém afirmou que esses números são precisos para qualquer hardware.

No entanto, eles são muito, muito mais precisos do que suposições cegas. É nisso que muitas pessoas infelizmente baseiam seu código.

Eles não são perfeitamente precisos e não pretendem realmente ser.

Eles são (especialmente em números menores) um pouco melhor do que apenas uma ordem de magnitude. Outro ponto é que pode ajudar a entender quais são as coisas próximas, que as pessoas às vezes interpretam mal como estando muito mais afastadas do que realmente são. Por um exemplo óbvio, muitas pessoas assumem que a predição incorreta de ramificações é frequentemente uma grande coisa. Ele pode ser um grande negócio se for repetido muito, mas não é necessariamente pena sacrificar uma enorme quantidade em qualquer lugar e em qualquer outro lugar apenas para obter uma melhor previsão de desvios (por exemplo, se você ler a partir da memória principal, ou mesmo L2 cache para melhorar a previsão de desvios, provavelmente é uma perda líquida).

Ao mesmo tempo, sim, ordens de magnitude podem ser as partes mais úteis. Por exemplo, leva cerca de 100 vezes mais tempo para acessar dados da memória principal do que de um registro. Sim, em uma máquina pode ser cerca de 97 vezes maior e em outra pode estar mais próximo de 127 vezes. É quase certo que estará mais perto de 100 do que 10 ou 1000.

Pessoalmente, eu tenderia a pensar na maioria delas como sendo semelhante a ilhas, digamos, no Oceano Pacífico. As velocidades do disco rígido (por exemplo) podem ser as ilhas havaianas. As velocidades SSD são as ilhas das Filipinas. Isso mostra o mapa em uma escala pequena o suficiente para fazer com que cada um pareça um único ponto. Se aumentarmos o zoom, isso claramente não é verdade - mas a distância entre as duas cadeias é muitas vezes maior que as distâncias entre as ilhas nas duas cadeias.

Obviamente, os números não podem ser precisos para todas as máquinas. E eu acho que eles nunca deveriam. Eles mostram diferenças na ordem de magnitude entre vários tipos de operações, no entanto.

Você pode encontrar alguns links e dados mais úteis nos comentários dos seus dados vinculados.