Ca fait quelques temps que je me demande:
le PIV monte plus en fréquence que le PIII ou l'athlon en partie parce qu'il a un pipe plus long (plus de stages)
Mais il me semble que dans le PIV il y a même des stages qui servent à rien que à le rallonger...
 
Pourquoi un processeur peut il monter plus en fréquence si le pipe est plus long? la chaleur est mieux répartie????
 
Pourquoi faire des stages inutiles? il vaut pas mieux tourner un peu moins vite avec plus d'instructions par cycle? (question un peu con, j'entends d'ici les *ntel rulez, AMD wins), En fait je me demande ce qui peut pousser à choisir de mettre des stages inutiles dans un proco.
 
Il y a plus de stage dans l'opteron que dans l'athlon, l'objectif est (je pense) de mieux monter en fréquence. il y a aussi plus de cache. il me semble que le cache ne chauffe pas (trop), mais est ce qu'il empêche aussi de monter en fréquence, et pourquoi?
 
Bref, plein de chtites questions que je me pose

Ce n'est pas plutot le contraire ??? a savoir, on augmente le nombre d'etage du pipe afin de profiter au maximum de la vitesse du CPU ?

 
En fait c'est pas ce que j'avais compris, mais il me semble bien que le PIV a plus d'étages que l'athlon, et il est moins on à isofréquence

 
tiens ça devrait répondre a ta question du moins en partie  
 
http://www.onversity.com/cgi-bin/p [...] =a1101#081

 
oui, c'est indeniable, le P4 possede 20 niveau de pipeline contre.. je ne sait plus combien pour l'athlon (de l'ordre de la dizaine...). Mais justement, le choix du nombre elevé d'etage de pipe pour le P4 est justifié afin de profiter au maximum des hautes cadences

En fait tu me dis que c'est pas le pipe plus long qui fait aller plus vite, mais qu'on profite mieux de la vitesse avec un pipe plus long?

 
Tres bon lien en effet, l'idée est donc de réduire la taille des unités de traitement pour pouvoir à continuer à traiter en un cycle par unité, en réduisant le nombre de transistors qui diminue la vitesse de propagation.
 
Ce qui me surprends toujours, c'est qu'il me semble que sur le PIV, il y a des étages qui ne traitent rien du tout...
 
je vais essayer de vérifier

 
oui, augmenter le nombre d'etage d'un pipe n'a jamais permis de monter plus en frequence un cpu, hors, justement, un CPU rapide profite du nombre de pipe elevé (dans le cas ou le code ne scratch pas le pipe avec un bon gros jump des familles par exemple ). le parcours du pipe se fait a chaque top d'horloge du CPU, le fait d'avoir un CPU veloce permet d'utiliser plus rapidement le pipe (de le remplir si tu preferes) et donc d'anticiper les operations qui suivent celle qui vient d'etre executée

J'avais compris le contraire    
 
Plus tu montes en frequence et plus le cycle d'horloge est court. Et plus le temps d'execution d'un etage d'un pipeline est court egalement. Et c'est ca qui peut limiter la montee en frequence : les temps d'execution deviennent trop court, ca passe plus.
 
En augmentant le nombre d'etage, on diminue le temps d'execution d'un etage et donc son temps d'execution. Ce qui permet d'augmenter la frequence du CPU.
 
En contrepartie, avoir trop d'etages ca pose des problemes au niveau des optimisations et des predictions de branchement : tu perds plus de temps (car plus d'etage et donc plus d'instructions executees en simultane) a annuler une operation et celles qui peuvent en dependre et etant en cours d'execution.
 
Voila ce que j'avais compris de maniere intuitive en tout cas

Apres lecture chez aces (tres bon article sur le PIV)http://www.aceshardware.com/Spades [...] d=15000190 Je me rends compte que si, ajouter des stages permet d'aller plus vite, car chaque étape étant plus petite, on met moins de temps à la traverser, et comme de toute façon il faut la traverser en un cycle, le temps de parcours d'une instruction impacte directement la fréquence du proc!
exemple: 1 stage on met 1 sec à le traverser, on a une frequence possible de 1Hz. Si on fait 2 stages à la place et qu'on ne met que 0.5 sec à les traverser, le proco peut tourner à 2Hz.
 
Ce que je me demandais, c'était pourquoi des stages inutiles dans le PIV, et en fait c'est parce que le pipe est tellement long qu'il est situé physiquement à des endroits différents sur le core, et que pour passer l'info d'un endroit à un autre, comme ça prend un cycle il faut bien mettre un stage.
 
That's not all, however. As we have pointed out, if the CPU keeps more instructions flight, more scheduling stages are necessary. The Pentium 4's pipeline is not only long because Intel's engineers wanted to reach very high clockspeeds, but many additional stages (compared to P6) are simply necessary! The P6 didn't need so many stages because the buffers and thus the number of instructions in flight were much lower (40 vs 126).  
 
 
 
Ace's:
 
On the Pentium 4's presentation slides, Intel says that the P6 had only 10 stages, while the Pentium 4 has no less than 20 stages.  
 
 
 
The unsuspecting reader might think that the Pentium 4 will be able to reach twice the clockrate, but that is of course not true. Not every stage is a "split up P6 stage", the Pentium 4 simply needs more stages to make sure that the huge amount of instructions in flight arrive where they should.  
 
More Pipeline Stages, The Other Side of the Coin  
 
The trace cache, the huge instruction buffers, and many other considerations have resulted in a Pentium 4 architecture with 20 stages after the trace cache and no less than 28 total. Notice that the branch check is at the 19th cycle, and therefore the branch misprediction penalty is no less than 19 cycles! If an instruction is not the in the Trace cache, the penalty could be even worse (context switches). Luckily, Intel has implemented an excellent branch predictor, which should be better than any existent branch predictor today to minimize the impact of branch misprediction. There is also a bypass between the decoder and the rename/allocate unit, which should lower the performance decrease caused by trace cache (L1- Instruction cache) misses.  
 
Nevertheless, it is clear that such a hyperpipelined architecture has a lot of disadvantages too. One very obvious disadvantage is die size. The Pentium 4 is almost twice as big as the Coppermine and the Thunderbird, a logical result of the 28 stage pipeline. Notice stages 5 and 20, labeled "drive." Intel told us at IDF that these stages are implemented for future "frequency headroom," but it is very likely that these stages are literally used just to push the data from one side of the chip to another. With such a huge hyperpipelined design, there are units that are on opposite ends of the chip and they need to spend a whole clock just to get from one side to another.  
 

 
Bravo Ernestor,   tout d'accord avec toi

Eh eh      
 
Par contre, ni dans l'article que tu cites, ni dans celui de Barbarella, on ne parle des problemes de predicitions de branchement et autres optimisations. Je me suis peut-etre trompe la  

 
Si si, suis le lien de ace's, je ne vous ai pas mis toute la page.
 
En effet, la vérification de branche sur le PIV se fait au 19e étage, ce qui fait que quand il se plante, il a vraiment l'air bête. C'est aussi pour ça que Intel a développé un branch predictor qui tue tout, pour que son bébé aie pas l'air trop ridicule (plutot réussi d'ailleurs)

Ok    
 
Y a ces techniques d'optimisation sur tous les CPUs de nos jours, c'est devenu indispensable.
 
Ca me rappele mes cours d'archi des CPU (y a longtemps ) ou on expliquait qu'un Dec Alpha y allait en bourrinant avec une grosse frequence mais peu d'optimisation et qu'un HP PA je-sais-plus-combien faisait bcp d'optimisations mais allait bien moins vite. Au final, les deux CPUS avaient les memes perfs

Ce n'est pas la longueur du pipeline qui compte, c'est la complexité de chaque étage.  
 
Les CPUs sont aujourd'hui de plus en plus complexe, et le travail eccompli tout eu long du pipe est donc de plus en plus grand, on est passé de simple processeurs qui n'exécutaient qu'une seule instruction par cycle et dans l'ordre à des monstres qui exécutent plusieurs instructions en parallèle et dans le désordre tout en spéculant sur les prochaines instructions...
 
Donc pour pouvoir maintenir la part de travail effectuée à chaque étage, il faut rajouter des nouveaux étages. Ca se voit très nettement dans les familles de CPU RISC qui sont passés successivement par 4,5,6... étages. Dans cette optique, le travail par étage (que l'on peut aussi voir comme étant le nombre de portes logiques à traverser) reste +/- constant.
 
Maintenant, on peut aussi vouloir monter en fréquence. En effet si on diminue le nombre de portes à traverser par étage (et on augmente le nombre d'étages pour compenser), on peut augmenter la fréquence. Il y a alors deux problème
1) une partie du budget 'timing' dépend de facteurs autres que le nombre de portes à traverser (logique liées à la synchronization au début.fin de l'étage, distance à parcourir sur le chip, incertitude sur le signal d'horloge...)
2) l'énergie dissipée augmente plus vite que le nombre d'étages. En effet, si je double le nombre d'étage, je vais peut-être gagner 70% en fréquence mais je vais également augmenter de façon significative le nombre de transistors (ben oui, faut bien des latch au début et à la fin de chaque étage, va falloir ajouter de nouveaux chemins, maintenir plus d'instructions en vol...). Au total, je gagne 70% en fréquence mais je paye surtout +70% (fréquence) +50% (logique en plus) = +120% en puissance... tout en ne gagnant que 50% en performance. Aïe.
 

Il n'y a pas d'étages inutiles (ça n'a pas de sens). Par contre, il devient difficile d'équilibrer les taches entre tous les étages -> certains vont se retrouver moins chargé que d'autres tout en dissipant un paquet de watts. Dans le P4, il y a deux étages dont le rôle officiel est simplement de faire transiter les données entre deux points distants du processeur.
 

Il vaut mieux avoir un design tel que F (fréquence) * IPC (instruction par cycle = max
 
Mais personne n'a la recette magique pour trouver le meilleur couple (F,IPC). Surtout que ça évolue avec les technologies de fabrication et de packaging (qui aurait pensé que l'on verrait des CPU craschant plus de 100W de chaleur - P4 3.0GHz - dans un PC de bureau? Je trouvais que le P5 à 66MHz chauffait déjà trop, une de mes connaissances en fit d'ailleurs les frais lorque son ventilateur s'arrêta).
 

Pas forcément, ce qui a été ajouté est dans la partie liée au décodage des instructions, décodage qui est plus complexe sur le K8 vu l'arrivée du mode 64 bits et des nouveux codes d'instruction. D'autre part, il est également possible que cette étape était le maillon faible du pipeline du K7 et ces étapes supplémentaires permettent d'augmenter la fréquence.
 

Non, le cache ne gêne pas la montée en fréquence pour une raison simple: si il est trop lent, on peut toujours ajouter un cycle d'attente supplémentaire au prix d'une légère perte de performance.
 

La prédiction de branchement sur le P4 n'a rien d'exceptionnel en ce qui concerne son taux de réussite qui est du même ordre que celui du K6 (>95%), l'exploit vient plutôt du fait qu'il tourne à des fréquences aussi élevée. AMD avait dû réduire nettement la complexité et le taux de réussite (tombant au niveux du P6, soit ~92%) pour le K7, le K8 quant à lui voit son historique revenir au niveau du K6 et devrait donc avoir un taux de réussite similaire à celui du P4.

Merci Blue Apple, c'est clair et précis!