Les chiffres essentiels que tout programmeur devrait connaître

Représentation visuelle des chiffres de latence que les programmeurs devraient connaître

• Référence au cache L1 : 1 nanoseconde
• Échec de prédiction de branchement : 3 nanosecondes
• Référence au cache L2 : 4 nanosecondes
• Verrouillage/déverrouillage de mutex : 17 nanosecondes
• Transmission de 1 Ko de données sur un réseau à 1 Gbit/s : 44 nanosecondes
• Référence à la mémoire principale : 100 nanosecondes
• Compression de 1 Ko de données avec Zippy : 2 microsecondes
• Lecture séquentielle de 1 Mo en mémoire : 3 microsecondes
• Lecture aléatoire 4K sur SSD : 16 microsecondes
• Lecture séquentielle de 1 Mo sur SSD : 49 microsecondes
• Temps d’aller-retour au sein du même datacenter : 500 microsecondes
• Lecture séquentielle de 1 Mo sur disque : 825 microsecondes
• Recherche sur disque : 2 millisecondes
• Aller-retour d’un paquet entre la Californie et les Pays-Bas : 150 millisecondes

L’avis de GN⁺

• Ces données peuvent servir de référence importante aux programmeurs lors de la conception d’un système ou de l’optimisation des performances. Savoir combien de temps prend chaque opération ou tâche permet d’identifier les goulets d’étranglement et de les améliorer.
• Par exemple, en comparant le temps d’accès mémoire et la latence réseau, on comprend qu’il est bien plus rapide de minimiser les appels réseau et de traiter les données en mémoire. Cela peut constituer un point crucial dans la conception de systèmes distribués.
• Ces latences peuvent évoluer avec les progrès du matériel et des technologies, il est donc important de disposer d’informations à jour. Par exemple, les progrès des SSD ont considérablement réduit les temps de lecture sur disque.
• Lors de l’adoption de nouvelles technologies ou de logiciels open source, il faut tenir compte de ces latences pour prévoir les performances du système et déterminer quelle technologie sera la plus efficace en conditions réelles. Par exemple, l’utilisation d’une solution de cache en mémoire peut réduire la latence réseau, mais elle nécessite aussi une réflexion supplémentaire sur la cohérence du cache et la synchronisation des données.

[kleinstein]

https://colin-scott.github.io/personal_website/research/…
Ici, la présentation est plus agréable.

[cosine20]

Oh là là, l’UI/UX ne me plaît vraiment pas...

[yangeok]

C'est vraiment ça, pff...

[GN⁺]

Commentaires Hacker News

• Résumé du premier commentaire :

  • L’utilisateur partage du code JavaScript qui parcourt les éléments enfants d’un élément HTML avec la classe latency-container et affiche la latence de chacun.
  • Les latences affichées couvrent différentes opérations informatiques, allant d’une référence au cache L1 jusqu’à un aller-retour au sein d’un data center.

• Résumé du deuxième commentaire :

  • Il estime que l’utilisabilité de l’interface utilisateur (UI) est mauvaise, et la présente comme un cas intéressant en matière d’expérience utilisateur (UX).
  • Il critique le fait que l’UI ne réponde pas aux attentes des utilisateurs pour accomplir sa fonction principale et qu’elle soit difficile à comprendre.
  • L’utilisateur note qu’il faut lire l’aide, mais que la plupart des gens n’aiment pas le faire.
  • Il souligne que la discussion autour de ces problèmes permet de tirer des enseignements sur l’UX.

• Résumé du troisième commentaire :

  • Il fait remarquer que le mot « Latency » manque dans le titre, ce qui rend la recherche d’autres résultats plus difficile.
  • En se référant à d’autres sources, il dit préférer des ressources textuelles qui fournissent davantage d’informations sur la latence.

• Résumé du quatrième commentaire :

  • Il critique le fait qu’une partie de l’UI affichée à l’écran soit difficile à lire.
  • Il juge inconfortable que le texte soit tourné à 90 degrés et estime que, si l’UI est amusante, elle privilégie davantage la forme que la fonction pour obtenir réellement de l’information.

• Résumé du cinquième commentaire :

  • Il énumère des ressources liées à l’origine des informations sur la latence, fournissant ainsi un contexte historique.

• Résumé du sixième commentaire :

  • Il mentionne que les latences liées au réseau ne sont pas intuitives.
  • Il partage une expérience personnelle sur la manière dont des services comme Google Stadia peuvent être plus rapides qu’attendu.

• Résumé du septième commentaire :

  • En tant qu’utilisateur de Firefox Mobile, il dit ne pas comprendre ce que l’UI essaie de montrer.

• Résumé du huitième commentaire :

  • Il dit ne pas comprendre la signification des chiffres affichés dans l’UI et exprime sa confusion, car ils ressemblent à des années futures.

• Résumé du neuvième commentaire :

  • Il trouve le titre quelque peu mystérieux et dit s’être attendu à un contenu sur des nombres comme 16, 256, 65536, etc.
  • Il exprime son scepticisme face à l’affirmation selon laquelle, en 2030, envoyer 1K octets sur un réseau gigabit sera plus rapide qu’un échec de prédiction de branchement à l’intérieur du CPU.