[Linux] latence / rapidité / temps d'accès

[zirst@::1]

Salut !

Intéressant en effet. Malgré ces chiffres étonnant, il faut quand même
garder en mémoire que tout ce qui est inférieur à 0.1s (la plupart des
trucs listés < aux communications tcp) nous semble instantané. Et ce n'est
qu'au delà de 10s que ça semble lent.

C'est aussi inquiétant en un sens. D'où va-t-on pouvoir augmenter la
rapidité d'exécution des programmes ? Sachant que ces latences ne bougent
plus et que la question de la recherche de perfs ne fait pas partie des
objectifs de formation des développeurs que ce soit pour la
parallélisation ou les optims (enfin de ce que j'ai vu, si quelqu'un a un
contre-exemple ça m'intéresse). Cela ne semble pas nécessaire pour
l'instant car la plupart des opérations peuvent se résoudre dans un délais
compris entre instantanément et rapidement (<1s). Du coup on se contente
de former des singes codeurs pour produire vite et mal en sous-effectif.


J'ajoute aux liens cette partie de Art of assembly de Randall Hyde parlant
d'optim :
https://courses.engr.illinois.edu/ece390/books/artofasm/CH25/CH25-1.html

> 'soir
>
> En 2010, j'avais envoyé sur la liste un lien parlant de la latence des
> système qui donne une bonne idée des échelles de grandeur énormes qui
> séparent un accès à un registre du CPU, aux cache L1/L2 ou L3, à la
> mémoire, au disque jusqu'à l'accès réseau à l'autre bout du monde :
> http://www.linux-mag.com/id/7589/
>
> voici le tableau retranscrit pour info :
> L1 cache reference                             0.5 ns
> Branch mispredict                              5 ns
> L2 cache reference                             7 ns
> Mutex lock/unlock                             25 ns
> Main memory reference                        100 ns
> Compress 1K bytes with Zippy               3,000 ns
> Send 2K bytes over 1 Gbps network         20,000 ns
> Read 1 MB sequentially from memory       250,000 ns
> Round trip within same datacenter        500,000 ns
> Disk seek                             10,000,000 ns
> Read 1 MB sequentially from disk      20,000,000 ns
> Send packet CA->Netherlands->CA      150,000,000 ns
>
>
> Ce tableau a été un peu amélioré par l'excellente page interactive qui
> permet de jouer avec un curseur temps pour voir l'évolution depuis 1990
> jusqu'à nos jour (en tentant même une extrapolation jusqu'en 2020)
> http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
>
> et c'est en effet assez étonnant de voir que l'on a probablement atteint
> un plafond et que tant sur la latence interne du processeur, le cache
> L1 ou L2 ou les accès mémoire, ça ne bouge plus depuis presque 10 ans
>
> Il n'y a guère que pour les gros transferts RAM (merci aux DDR2 DDR3 et
> autres technos permettant de paralléliser), et les accès disques ou SSD
> où l'on va encore voir des petites améliorations mais qui ne sont pas
> non plus transcendantes (à moins de trouver un nouveau type d'accès RAM
> ultra rapide)
>
> Néanmoins, ces nombres sont en effet assez peu parlant pour le néophyte
> ce qui est corrigé grâce à ce tableau qui met en perspective ces nombres
> de l'infiniment petit (0,3ns d'un cycle CPU) en le ramenant à 1 seconde
> et de montrer à quoi ça correspond pour tout les autres délais
> https://twitter.com/PieCalculus/status/459485747842523136/photo/1
> dont voici la retranscription en français
>
> Événement			Latence		mise à l'échelle
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 cycle CPU			 0,3 ns		 1 s
> accès cache L1		 0,9 ns		 3 s
> accès cache L2		 2,8 ns		 9 s
> accès cache L3		12,9 ns		43 s
> accès mém.			120 ns		 6 mn
> (DRAM depuis CPU)
> E/S SSD (flash)		50-150 µs	2-6 j
> E/S ddur			1-10 mn		1-12 mois
> Internet :
>  San Francisco -> NY 40 ms		 4 ans
>  SF -> Royaume-Uni	 81 ms		 8 ans
>  SF -> Australie	183 ms		19 ans
> restransmission TCP	1-3 s		105 à 317 ans
> reboot OS virtualisé  4 s		423 ans
> timeout cmd SCSI	 30 s		 3 millénaires
> reboot machine phys. 5 mn		32 millénaires
>
> oui : une fois le cycle processeur ramené à 1 seconde, ça serait 6
> minutes qu'il faudrait pour effectuer un accès à la mémoire, de 2 à 6
> jours pour un accès SSD et jusqu'à 1 an pour un accès disque dur (sans
> parlé des 32 milliers d'années pour un reboot machine... une éternité)
>
> Bref, des chiffres (pardon, nombres) que tout programmeurs devraient
> avoir en mémoire (RAM, CPU, ce que vous voulez)
>
> Bonus : voici l'article qui m'a permis de découvrir ce dernier lien
> http://javarevisited.blogspot.sg/2014/05/10-articles-every-programmer-must-read.html
> qui lui aussi est plein de ressources intéressantes
>
> --
> 	Cyril Chaboisseau
>
> Ce message est constitué d'électrons recyclés.
>