Comment les «chiffres de latence que tout programmeur devrait connaître» de Jeff Dean peuvent-ils être précis dans le contexte des différentes implémentations matérielles?

Je fais référence à ce tableau des nombres de latence , attribué à Jeff Dean de Google.

Ce que je ne comprends pas, c'est que ces chiffres ne varient pas d'un ensemble de matériel à l'autre? Comment peuvent-ils être précis pour tous les différents types de RAM, CPU, carte mère, disque dur, etc.?

Ces chiffres (également listés sur la programmation de Norvig dans 10 ans ) sont approximatifs et ne sont utiles que comme ordre de grandeur.

En fait, le matériel d'aujourd'hui (au moins pour les ordinateurs de bureau ou les ordinateurs portables) ne varie pas beaucoup, même entre un ordinateur portable bon marché à 300 € et une station de travail haut de gamme à 10 000 €. La vitesse varie d'un facteur d'environ 2 ou 4 au maximum. Un tel poste de travail peut avoir un disque plus grand, plus de cœurs, de cache et de RAM. Cependant, cela n'a pas beaucoup d'impact sur les performances brutes d'un seul thread.

Regardez quelques chiffres sur http://openbenchmarking.org/ ou certains comparateurs CPU.

La soi-disant loi de Moore est en train de mourir . Mon ordinateur de bureau de 3 ans et plus à la maison (un i3770K) pourrait être remplacé (aujourd'hui, en mars 2016) par un i6700 qui n'est que 20% plus rapide.

Les chiffres ne sont pas censés être exacts. Ce sont les rapports entre les ordres de grandeur entre les niveaux qui importent.

Cependant, lorsqu'une technologie perturbatrice apparaît (par exemple, cloud computing, 10GB / 100GB ethernet, nouveau module de noyau de mise en réseau, réseaux de stockage SSD, virtualisation et conteneurisation), ces chiffres peuvent être invalidés en raison de l'apparition, de la disparition ou de la réorganisation de nouveaux niveaux.

Lors de la programmation à un niveau très élevé - où tous les calculs, la mise en réseau, l'analyse, etc., sont effectués à l'aide de bibliothèques non écrites par vous-même, sachant que les performances des opérations de bas niveau peuvent ne pas aider beaucoup, car vous avez la possibilité de les améliorer les performances de la bibliothèque sont plutôt limitées ou carrément impossibles.

Au lieu de cela, lisez attentivement la documentation relative aux performances de chaque bibliothèque. Si une bibliothèque ne vient pas avec ceux-ci, demandez-leur - en faire un problème. Ou apprenez à comparer les logiciels de la bonne manière.

Il est important d'avoir une compréhension de base des nombres de latence lorsque vous êtes embauché par une entreprise qui conçoit et fabrique des composants logiciels. Comparez cela à une entreprise qui conçoit et fabrique des voitures et tous les composants qu'ils contiennent - le proverbial «réinventer la roue» (caoutchouc, pression des pneus, bandes de roulement, etc.)

La plupart des éditeurs de logiciels ne travaillent pas au niveau des composants - des systèmes logiciels fonctionnels entiers peuvent être construits à partir de l'assemblage des composants. Ces éditeurs de logiciels n'ont pas besoin de se concentrer sur la façon de concevoir des composants en termes de latences; ils doivent plutôt évaluer la qualité des composants qu'ils choisissent.

Pour résumer, (1) il est très possible que vous n'ayez pas besoin de connaître les numéros de latence; (2) sauf si vous souhaitez être embauché par une entreprise qui fabrique des composants logiciels (bibliothèques), que ce soit pour la vente ou pour un usage interne (comme dans certaines des plus grandes sociétés de logiciels au monde), (3) si vous avez besoin de ces numéros, c'est votre travail de faire vous-même les repères, d'une manière scientifiquement correcte, sinon vous ne devriez pas travailler sur des composants logiciels.

Personne n'a prétendu que ces chiffres sont exacts pour tout matériel.

Cependant, ils sont beaucoup, beaucoup plus précis que les suppositions aveugles. C'est ce sur quoi de nombreuses personnes basent malheureusement leur code.

Ils ne sont pas parfaitement précis et ils ne sont pas vraiment destinés à l'être.

Ils sont cependant (en particulier sur les petits nombres) un peu meilleurs que le simple ordre de grandeur. Un autre point est que cela peut aider à comprendre quelles choses sont proches les unes des autres, que les gens interprètent parfois à tort comme étant beaucoup plus éloignés qu'ils ne le sont vraiment. Pour un exemple évident, un bon nombre de personnes supposent que la mauvaise prédiction de branche est souvent une grande chose. Cela peut être très important s'il se répète beaucoup, mais cela ne vaut pas nécessairement la peine de sacrifier une énorme quantité n'importe où et partout ailleurs juste pour obtenir une meilleure prédiction de branche (par exemple, si vous lisez à partir de la mémoire principale, ou même du cache L2 pour améliorer la prédiction de branche, c'est probablement une perte nette).

En même temps, oui, les ordres de grandeur peuvent être les parties les plus utiles. Par exemple, il faut environ 100 fois plus de temps pour accéder aux données de la mémoire principale qu'à partir d'un registre. Oui, sur une machine, elle peut être environ 97 fois plus longue et sur une autre, elle peut être plus proche de 127 fois plus. Il sera presque certainement plus proche de 100 que de 10 ou de 1000.

Personnellement, j'aurais tendance à penser que la plupart d'entre elles sont similaires aux îles de, disons, l'océan Pacifique. Les vitesses de disque dur (par exemple) pourraient être les îles hawaïennes. Les vitesses SSD sont les îles philippines. Cela montre la carte à une échelle suffisamment petite pour que chacun d'eux ressemble à un seul point. Si nous zoomons, ce n'est clairement pas vrai - mais la distance entre les deux chaînes est beaucoup plus grande que les distances entre les îles de l'une ou l'autre chaîne.

Bien sûr, les chiffres ne peuvent pas être précis pour chaque machine. Et je suppose qu'ils n'ont jamais été censés le faire. Ils montrent cependant des différences dans l'ordre de grandeur entre plusieurs types d'opérations.

Vous pouvez trouver des liens et des données plus utiles dans les commentaires de vos données liées.