Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Avez-vous une bonne idée des temps de latence ?

Bien que cela regarde directement le hardware, les temps de latence des principales opérations d’un ordinateur impactent directement sur le logiciel. Comment prendre de bonnes décisions d’architecture, d’algorithme sans aucune connaissance même approximative de ces temps ?

Rien n’est gratuit !

Hélas rien n’est gratuit, même dans le monde virtuel des signaux qui transitent dans un PC. Toute opération réalisée par un ordinateur, aussi rapide soit-il, prend du temps, non pas pour sa simple exécution mais aussi pour sa préparation. Un circuit intégré ne bascule pas d’un mode à un autre immédiatement. Aussi court soit ce temps il a un impact. Un cout.

Optimiser ses applications prend son sens que si l’on a une bonne idée de tous ces temps de latence qui s’additionnent et qui, au final, représentent un “prix d’entrée” pour chaque opération.

Latence

On peut la définir comme le temps entre l’apparition d’une cause et l’observation de son effet.

Tout le monde sait sauf exception qu’une lecture dans le cache L1 d’un processeur est plus rapide que dans le cache L2 ou que lire en mémoire 1Ko de données est plus rapide que sur disque même SSD. Mais ce sont des généralités, sans ordre de grandeur, donc inexploitable. Cela devient des lapalissades sans aucun intérêt pratique.

Ordres de grandeur

Pour mieux comprendre, optimiser, architecturer un logiciel ce qu’il faut c’est connaitre les ordres de grandeur des principales opérations. Cela permet de prendre de la hauteur, de changer parfois la perspective pour des optimisations, de mieux choisir la mise en œuvre d’un algorithme, etc.

Pour un non physicien savoir que la période d’un élément comme l’Uranium est “très longue” est déjà faire montre d’une certaine culture générale. Mais pour un physicien cela ne veut rien dire. Entre la période (demi-vie) de l’Uranium 235 qui est de 700 millions d’années environ et celle de l’Uranium 238 qui de 4,5 milliards d’années, il y a comme une différence énorme qui oblige à traiter les problèmes différemment !

Pour un utilisateur, savoir que la mémoire se lit plus vite qu’un disque dur c’est bien et c’est faire montre d’une bonne culture générale, pour un informaticien il faut savoir quel est l’ordre de grandeur de ces deux évènements.

Tableau des latences

Jeff Dean de chez Google a étudié les principales latences et c’est ce tableau que je vais vous dévoiler. Non pas qu’il faille le connaitre par cœur, mais il est bon de retenir les différences entre les opérations et surtout leur ordre de grandeur.

Dans la première colonne se trouve l’opération, dans la deuxième quelques notes, dans la troisième la latence en nanosecondes et dans la quatrième le facteur entre l’opération sur le cache L1 que l’on considère comme la valeur “1”. Pour rendre plus tangible les écarts de temps, le facteur est exprimé en secondes en considérant que l’opération de référence prend 1 seconde. C’est toujours un facteur mais exprimé en Jours, heures, minutes et secondes. Ainsi 3 minutes veulent dire que l’opération considérée dure 3x60 = 180 secondes = 180 fois plus longtemps que l’opération de référence…

Les valeurs des latences peuvent en réalité varier beaucoup d’un hardware à l’autre c’est donc bien l’ordre de grandeur qui compte plus que la valeur précise.

 

Opération note Latence Facteur
Référence au cache L1 Ce cache est implémenté dans le processeur 0,5 ns 1s
Erreur de prédiction de branche Le processeur tente de prévoir les prochaines instructions à exécuter, parfois il se trompe et doit refaire son calcul 5 ns 10s
Référence au cache L2 Ce cache est parfois sur un composant externe 7 ns 14s
Mutex Lock/unlock C’est le mécanisme de synchronisation classique pour réserver une ressource en multitâche 25 ns 50s
Référence à la RAM principale La RAM se trouve dans des composants externes au processeur 100 ns 3m 20s
Compresser 1K avec “snappy” Snappy est un algorithme de compression en C++ développé et utilisé par Google, il est considéré comme très rapide. 3.000 ns 1h 40m
Envoyer 1K sur un réseau 1Gbps   10.000 ns 5h 33m 20s
Lire 1Mo séquentiellement dans la RAM   250.000 ns 5J 18h 53m 20s
Round trip dans un même datacenter En considérant que le DNS sera plus rapide que lors d’un accès à un site extérieur au datacenter 500.000 ns 11J 13h 46m 40s
Lire 1Mo séquentiellement sur un SSD   1.000.000 ns 23J 3h 33m 20s
Positionnement des têtes d’un HDD “disk seek” temps pris pour positionner les têtes sur la piste et le secteur des données avant d’y accéder 10 M ns 231J 11h 33m 20s
Lire 1Mo séquentiellement sur un HDD Un disque dur classique est bien moins rapide qu’un SSD mais de combien… 20 M ns 462J 23h 6m 40s
Round trip USA/Europe Aller retour d’un paquet de données entre les USA et l’Europe par Internet 150 M ns 3472J 5h 20m

 

S’il n’y a rien de vraiment fantastique dans ce tableau il a ainsi l’avantage de donner des valeurs même approximatives à ces fameuses latentes.

Ainsi, envoyer un paquet de données par internet aux USA et obtenir une réponse prend environ 150 millions de nanosecondes. Alors que lire séquentiellement 1Mo de données depuis un SSD ne prend que 1 million de nanosecondes. On peut lire ainsi 150 Mo séquentiellement sur un SSD le temps d’un aller retour de données Europe/USA. Peut-être est-il donc plus judicieux de copier les informations en local que de les réclamer à un Web service distant… C’est une évidence, mais ici on sait ce que l’on gagne. Car si la base est locale on ne lira pas 150 Mo pour accéder à la même quantité de données que le fameux aller retour. Au pire donc le gain sera de 150 fois, en réalité à quantité de données équivalente il sera de 150.000 fois (en lisant 1Ko) ! Une telle différence doit inciter à réfléchir…

Conclusion

Bref, rien d’extraordinaire ici, nous savons tous que lire de la RAM est plus rapide que de lire un SSD ou accéder à des données aux USA. Tout le problème pour prendre des décisions c’est de savoir de “combien” c’est plus lent ou plus rapide.

Ce petit tableau fixe les choses. C’est bon à savoir.

Stay Tuned !

blog comments powered by Disqus