Temps des différents accès
L'année dernière, en "Compilation Avancée", on a vu différentes méthodes permettant de réduire les défauts de cache, ce qui permet de gagner un bon gros facteur en terme de performances.
Alors certes, pourquoi pas, mais on se rend compte qu'en règle général on a du mal à imaginer les écarts de temps... Un accès à une valeur du cache L2, est-ce vraiment beaucoup plus lent que pour le cache L1 ? Et que pour un accès en RAM ? Il existe donc un petit tableau "comparatif", histoire que tout programmeur puisse se faire une idée de l'importance de ce genre d'optimisations...
Je ne l'ai pas traduit car de toute façon c'est relativement simple à comprendre, je vous laisse donc vous instruire 
| 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 w/ cheap algorithm | 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 |
Un petit commentaire ? A la louche, un facteur 14 entre les accès au cache L1 et les accès au cache L2, et à nouveau un facteur de cet ordre pour un accès en mémoire principale. Comme quoi ça coûte vraiment cher !
Source : The Axis of Eval
4 janvier 2011
Tu fais que ralonger un peu la chaine de l’info… Le site Axis of Eval a tiré ce tableau d’un article sur Google qui l’avait lui-même tiré du blog de Peter Norvig qui lui l’a tiré d’on ne sait où…
4 janvier 2011
Tout a fait