> Oui, on perd 8-10 cycles (ou même un peu plus) dans ce cas... mais c'est à > mettre en perspective avec les 120-170 cycles qu'il faut à la dernière > génération de CPU-Server d'Intel pour aller récupérer une donnée dans la > cache L3 !
C'est la raison pour laquelle il y a une cache L1 et une cache L2. Ajoutez à cela du simultaneous multithreaded sur un serveur et le remplissage du pipeline permet encore mieux de masquer les temps de récupération en mémoire qui est effectivement très long. Et précisons encore que les 200 cycles pour accéder la mémoire centrale ne concernent que le premier mot puisqu'on a des double horloges déphasées pour récupérer des paquets de mots sur un seule cycle. Le principe de localité rend ensuite statistiquement très intéressant d'avoir intégré en cache ces blocs. > Ce qui fait que, sur un benchmark de web serveur, l'impact du "branch > prediction" fait sourire à côté du reste. Je suis preneur d'un article qui le montre. >> Avec des pipelines d'aujourd'hui de plus de 10 étages, > > Le processeur RISC de DEC avait déjà 10 étages à la fin des années 80... MIPS > et SPARC en avait sauf erreur 8, etc. Donc, rien de très nouveau... Si et c'est clossal: à la fin des années 80 on avait un pipeline qui traitait une seule instruction par étage. Vous aviez donc au maximum 10 instructions dans le pipeline. On a aujourd'hui du superscalaire à 3 voies ou plus, avec renommage des registres, exécution dans le désordre et simultaneous multithreading (intel appelle ça hyperthreading). On a un ordre de grandeur en plus d'instructions simultanément traitée. Si vous appelez pas ça du neuf... Dom _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
