le post d´un mec sur hfr, pasque toi, t´as pas trop l´air de savoir de quoi tu parle
quote: Le problème intrinsèque du pipeline à rallonge, c´est la prédiction, il est impossible de prédire avec certitude la prochaine instruction...
C´est loin d´être le seul problème.
Quand tu allonges le pipeline tu augmentes également le temps de rétention des bulles dans le pipeline. Comparons deux cpu de même perfs : un p4C 3.0 et un Athlon 2.0Ghz. p4C : pipeline de 20 étages, deux fois plus que l´aXP (10 étages), et fréquence supérieure d´un tiers. Les bulles de pipeline (il est impossible de les supprimer totalement car elles sont liées à l´ILP) avancent un tiers plus vite mais restent 20 cycles au lieu de 10 pour un K7. Pour compenser il te faut optimiser le front end, agrandir la fenêtre d´instruction, mais à un moment donné, tu te heurtes à l´ILP.
Tu augmentes égalemement le nombre d´instructions en cours d´exécution dans le pipeline à un instant t (2 fois plus dans un p4C que dans un aXP). Hors sur un cpu OOO, il faut impérativemement des transistors pour suivre les instructions et le stade d´exécution, pour pouvoir remettre le tout dans l´ordre à la fin. Le nombre de transistors de suivit augmente donc avec la profondeur du pipeline. L´astuce de fusion d´instructions permet de limiter le phénomène sur le PPC970, le p-M et le Core2Duo. Hors ton budget en transistors n´est pas illimité, surtout pour un cpu grand public, qui doit rester peu cher. Donc tu manges sur ton budget en unités d´exécutions (cas du p4 qui possède seulement 2 ALUs principales, et 2 FPUs, contre 3 ALUs et 3 FPUs pour un athlon, avec un nombre de transistors total comparable).
Le p4, même "Northwood", possède 2 autres problèmes spécifiques liés à son pipepline démesuré. D´une part les étages passifs, qui ne font que transmettre le signal, et d´autre part le système "replay", rendu nécessaire par l´éloignement des unités d´exécution et de la fenêtre d´instruction (voir ici :
http://www.xbitlabs.com/articles/c [...] eplay.html ).
Ces deux paramètres prouvent que le choix des hautes fréquences pour le p4 n´a pas été fait par les ingénieurs, mais par le service marketing, qui désirait se démarquer d´AMD. Quoi de plus facile que de vendre un truc plus haut fréquencé au novice ?
En conclusion, il faut se résoudre à l´idée que les fréquences stagnent depuis un moment, et que cela perdurera le temps de trouver des solutions innovantes aux problèmes liés à la miniaturisation et à l´approche des limites physiques.
quote: Avec de la DDR2 voire DDR3 qui se profile, il le trouvera, t´inquiète pas
Non, le problème n´est pas uniquement la BP mémoire. Il faut extraire du parallèlisme dans ton code. C´est très facile sur un code multimédia type SIMD (GPU, SSE), mais beaucoup plus complexe sur des instructions multiples peu prédictibles (code réseau, IA, bases de données).
En résumé, les limites de l´ILP sont ATTEINTES par les cpu actuels, surtout pour les entiers, et le nombre d´unités d´exécution restera à 3 - 4.
En revanche il reste du travail à faire sur le TLP, et donc l´augmentation cette fois ci du nombre de cpu, en l´occurence du nombre de cores.
Ce que certains appellent le threading hardware revient à appliquer les recettes de l´OOO, non plus aux instructions, mais à un niveau supérieur, celui des threads.