Question con: Pipeline et tout ca.

[Wanou]

Voilà, chacun à ses lacunes, et moi, yen a une qui m'embete:
Quelqu'un peut-il me dire (ou me filer un lien) qui explique le rapport entre des pipelines courts-longs et la montée en fréquence des processeurs ?

Merci d'avance.

[jihef]

Ben j'espere que t'aimes l'anglais !!

Part 1 : http://arstechnica.com/articles/paed...pelining-1.ars

Part 2 : http://arstechnica.com/articles/paed...pelining-2.ars

Sinon en gros plus le pipeline est court plus il faut faire de trucs par étage de pipeline et plus c'est complexe. Plus c'est complexe plus ca demande de temps et comme l'horloge doit permettre a chaque étage du pipe de faire son boulot correctement c'est l'étage le plus complexe qui "détermine" la fréquence d'horloge. Sinon si tu rajoutes des étages tu as moins de compléxité par étage donc peut s'éxécuter plus vite.

edit : surtout part two.

[Franck@x86]

Je vous propose un petit exemple théorique comparant le traitement d'une instruction avec et sans pipeline.

Supposons qu'une instruction ait besoin de T ns pour être effectuée (ce temps est dépendant des caractéristiques des unités de traitement du CPU, indépendamment du fait qu'un pipeline soit utilisé ou non).

La même instruction traitée par un pipeline aura toujours besoin de T ns, mais sera découpée en P étapes (P étant le nombre d'étages du pipeline, ou encore la profondeur du pipeline). Supposons que chaque étape nécessite TP ns pour être traitée.

La première instruction nécessitera P x TP ns pour être traitée, et après cela une instruction sort du pipeline toutes les TP ns.

Pour n instructions, le temps de traitement sans pipeline est : n x T.
Avec pipeline elle est :
P x TP + (n-1) x TP = (P+n-1) x TP.

Or, TP = T / P, d'où :

(P+n-1) x TP = T x (P+n-1) / P.

Regardons maintenant le rapport entre le temps mis pour le traitement sans pipeline et le temps mis avec pipeline :

R = (n x T ) / ( T x (P+n-1) / P )
R = (P x n x T) / ( T x (P+n-1) )
R = (P x n) / (P + n - 1)

Si n devient très grand, (P + n - 1) ~ n.
Donc R tend vers (P x n) / n soit P.

Ce qui veut dire que le rapport entre le temps sans pipeline et le temps avec pipeline (soit le gain de performances due à l'utilisation du pipeline) tend vers P, soit le nombre d'étages du pipeline.

Bon attention ceci est pure théorie, car cela repose sur plusieurs hypothèses non vérifiées en pratique.

Le rapport avec la fréquence maintenant.
Le signal d'horloge est utilisé pour commander les transferts entre chaque étage du pipeline. La période de ce signal doit donc être supérieure ou égale à TP : période >= TP
La fréquence (1/période) doit donc vérifier : F <= 1/TP.

Or, TP = T / P, soit F <= P/T = Fmax.
Donc, plus P est grand, plus TP peut être petit, et plus Fmax peut être grande.

Voili voilou

Edit : on voit ici une limitation théorique de l'overclock, càd qu'il existe une fréquence max au dessus de laquelle on a une période supérieure à TP, qui est une donnée immuable. En fait il existe une étape qui prend plus de temps que les autres, et dans ce cas c'est cette étape qui joue le rôle de fusible, càd qu'elle ne peut pas s'achever. D'où les comportements erratiques que l'on peut observer, sans pour autant que le CPU plante directement.

Edit 2:
Tiens prenons un exemple concret pour voir, mettons une archi avec un Tmax de 5ns.
Avec P = 12, Fmax = 12/5 = 2.4 GHz (P6, PM)
Avec P = 20, Fmax = 20/5 = 4 GHz (Northwood)
Avec P = 30, Fmax = 30/5 = 6 GHz (Prescott)

(je répète c'est MEGA simplifié hein ... )

[Lissyx]

Je vous propose un petit exemple théorique comparant le traitement d'une instruction avec et sans pipeline.

Supposons qu'une instruction ait besoin de T ns pour être effectuée (ce temps est dépendant des caractéristiques des unités de traitement du CPU, indépendamment du fait qu'un pipeline soit utilisé ou non).

La même instruction traitée par un pipeline aura toujours besoin de T ns, mais sera découpée en P étapes (P étant le nombre d'étages du pipeline, ou encore la profondeur du pipeline). Supposons que chaque étape nécessite TP ns pour être traitée.

La première instruction nécessitera P x TP ns pour être traitée, et après cela une instruction sort du pipeline toutes les TP ns.

Pour n instructions, le temps de traitement sans pipeline est : n x T.
Avec pipeline elle est :
P x TP + (n-1) x TP = (P+n-1) x TP.

Or, TP = T / P, d'où :

(P+n-1) x TP = T x (P+n-1) / P.

Regardons maintenant le rapport entre le temps mis pour le traitement sans pipeline et le temps mis avec pipeline :

R = (n x T ) / ( T x (P+n-1) / P )
R = (P x n x T) / ( T x (P+n-1) )
R = (P x n) / (P + n - 1)

Si n devient très grand, (P + n - 1) ~ n.
Donc R tend vers (P x n) / n soit P.

Ce qui veut dire que le rapport entre le temps sans pipeline et le temps avec pipeline (soit le gain de performances due à l'utilisation du pipeline) tend vers P, soit le nombre d'étages du pipeline.

Bon attention ceci est pure théorie, car cela repose sur plusieurs hypothèses non vérifiées en pratique.

Le rapport avec la fréquence maintenant.
Le signal d'horloge est utilisé pour commander les transferts entre chaque étage du pipeline. La période de ce signal doit donc être supérieure ou égale à TP : période >= TP
La fréquence (1/période) doit donc vérifier : F <= 1/TP.

Or, TP = T / P, soit F <= P/T = Fmax.
Donc, plus P est grand, plus TP peut être petit, et plus Fmax peut être grande.

Voili voilou

Edit : on voit ici une limitation théorique de l'overclock, càd qu'il existe une fréquence max au dessus de laquelle on a une période supérieure à TP, qui est une donnée immuable. En fait il existe une étape qui prend plus de temps que les autres, et dans ce cas c'est cette étape qui joue le rôle de fusible, càd qu'elle ne peut pas s'achever. D'où les comportements erratiques que l'on peut observer, sans pour autant que le CPU plante directement.

Edit 2:
Tiens prenons un exemple concret pour voir, mettons une archi avec un Tmax de 5ns.
Avec P = 12, Fmax = 12/5 = 2.4 GHz (P6, PM)
Avec P = 20, Fmax = 20/5 = 4 GHz (Northwood)
Avec P = 30, Fmax = 30/5 = 6 GHz (Prescott)

(je répète c'est MEGA simplifié hein ... )

ça a beau être simplifié, ça reste quand même assez proche de la réalité

[Ministry]

merci pour cette explication Franck

[Wanou]

Merci beaucoup à tous les deux.
Et aucun probleme pour l'anglais.... Au contraire ! je préfère un bon article original qu'une mauvaise traduction.

[Philll]

Très intéressant :jap:

[fefe]

Une chose a ajouter est que chaque etage de pipeline comprend un certain nombre de taches incompressibles (essentiellement latcher le signal a la fin du cycle), ce qui fait qu'un traitement qui ferait 10 etages a une frequence donnee, fera plus de 20 etages a 2x la frequence (2X plus d'etages plus 1 ou 2 pour rattraper ce que t'ont coute les latches).

Tu peux considerer que le temps de propagation a travers une porte est a peu pres constant.

Si a une frequence donnee tu peux faire 20 operations dans ton cycle, tu en auras 19 utiles et une latche, a 2x la frequence tu auras 9 utiles par cycle. Si ton pipeline faisait 100 operations a l'origine, en doublant la frequence il en fait maintenant 105.

Qui plus est plus tu monte en frequence plus il devient difficile/couteux de construire des operateurs avec si peu de portes (couteux car oblige d'utiliser des portes tres rapides et tres gourmandes).

[ludoschmitt]

Une chose a ajouter est que chaque etage de pipeline comprend un certain nombre de taches incompressibles (essentiellement latcher le signal a la fin du cycle), ce qui fait qu'un traitement qui ferait 10 etages a une frequence donnee, fera plus de 20 etages a 2x la frequence (2X plus d'etages plus 1 ou 2 pour rattraper ce que t'ont coute les latches).

Ce dont tu parles c'est bien le superpipeline comme on pouvais le voir dans le MIPS R3000 et les générations suivantes.

Qui plus est plus tu monte en frequence plus il devient difficile/couteux de construire des operateurs avec si peu de portes (couteux car oblige d'utiliser des portes tres rapides et tres gourmandes).

Pour avoir des portes plus rapides on fait comment ? Y-a-t'il des transitors plus rapides ?

[fefe]

Le nombre d'etages dont je parle est effectivement comparable a un MIPS R3000 mais cela s'applique a tous les processeurs utilisant du CMOS.

Oui tu peux faire des transistors qui sont plus rapides, en general la dissipation d'energie et la surface dudit transistor croissent de maniere exponentielle par rapport au delai gagne.

Typiquement tu veux utiliser des circuits statiques avec les portes les plus petites possibles, leakant le moins possible, mais si tu as besoin de caser plus de logique dans cet etage de pipeline tu seras contraint d'utiliser des circuits plus agressifs (par exemple comme c'est le cas dans les ALU "fireball" sur les willamette/northwood).

[Minuteman]

C'est intéressant, merci franck

[fofo]

Merci à Wanou d'avoir osez poser la question merci aux autres d'avoir répondu :wink:


euh sinon c'est : "Question conne: Pipeline et tout ça."

[fefe]

Sinon il y a le cours sur les predictions de branchements sur onversity qui en parle un peu aussi.

[apossium]

merci pour ces reponses !

[Childerik]

Déterrage oblige :

Sait-on aujourd'hui quel est le nombre exact des étages du pipeline du Pentium M (banias, dothan et yonah) ?

Quand Sam a fait son article sur le banias, on était incapable de le savoir. 10 comme les PII/PIII ? 12, ou 15 peut-être ???

:jap:

[Dandu]

il me semble que c'est 12 dans les Banias/Dothan

[Neo_13]

ya un article sur le pipeline qui est sorti dans la presse papier... un certain franck dans hardware mag

[Franxinator]

j'ai lu (sut TT-hardware je crois) que le conroe comporterait (le conditionnel est important) 14 étages.

je me demande pourquoi Intel tient secret ce nombre d'étages alors que pour le prescott tout le monde est au courant et qu'il y a vraiment pas de quoi s'en vanter...

[Franck@x86]

je me demande pourquoi Intel tient secret ce nombre d'étages alors que pour le prescott tout le monde est au courant et qu'il y a vraiment pas de quoi s'en vanter...

C'est pas que c'est secret, mais Intel a beaucoup communiqué sur sa technologie "hyperpipeline", donc il semble assez malvenu maintenant de crier partout un retour à pipeline court.

[Franck@x86]

ya un article sur le pipeline qui est sorti dans la presse papier... un certain franck dans hardware mag

Ouais ouais !!! c'est sorti samedi !! :D

[Neo_13]

je me demande pourquoi Intel tient secret ce nombre d'étages alors que pour le prescott tout le monde est au courant et qu'il y a vraiment pas de quoi s'en vanter...

C'est pas que c'est secret, mais Intel a beaucoup communiqué sur sa technologie "hyperpipeline", donc il semble assez malvenu maintenant de crier partout un retour à pipeline court.

et ça prépare le retour inexorable a des pipelines longs

[Franck@x86]

oui voilà, qqu'un a lu mon article ! :-)

[Franxinator]

j'ai une petite question qui va surement paraitre bête, mais bon...le topic porte bien son nom, non?

c'est a propos de la gestion des taches par windows et les cpu dual core.
Est ce que windows est capable de gérer dynamiquement la répartition des taches entre les cores suivant l'occupation des cores et la puissance nécessitée par les applications? le "changement de core" du thread peut il se faire de façon fluid eet transparente?

et est ce que windows (XP ou server, via le choix de priorité du thread) permet d'allouer de façon permanente un thread à un processeur (exemple : montage vidéo ou jeu) et de mettre tous les autres (antivirus, explorer, internet etc...) sur le 2e core? si windows ne le gère pas ou a du mal (comme avec les dual core HT) est ce que des solutions existent (logiciels tiers, vista...)?

voila je crois que c'est tout pour le moment :wink:
il me plait bien le Core Duo...y a plus qu'a économiser

[seb64]

j'ai une petite question qui va surement paraitre bête, mais bon...le topic porte bien son nom, non?

c'est a propos de la gestion des taches par windows et les cpu dual core.
Est ce que windows est capable de gérer dynamiquement la répartition des taches entre les cores suivant l'occupation des cores et la puissance nécessitée par les applications? le "changement de core" du thread peut il se faire de façon fluid eet transparente?

Oui, mais déplacer les thread d'un core à l'autre a un coût qui n'est pas négligeable, donc il le fait en priorité sur la création de nouveaux threads

et est ce que windows (XP ou server, via le choix de priorité du thread) permet d'allouer de façon permanente un thread à un processeur (exemple : montage vidéo ou jeu) et de mettre tous les autres (antivirus, explorer, internet etc...) sur le 2e core? si windows ne le gère pas ou a du mal (comme avec les dual core HT) est ce que des solutions existent (logiciels tiers, vista...)?

oui, dans le gestionnaire de tache on peut définir l'affinité d'une application (pas d'un thread individuel)

[Ministry]

smpseesaw sinon

[Childerik]

j'ai lu (sut TT-hardware je crois) que le conroe comporterait (le conditionnel est important) 14 étages.

je me demande pourquoi Intel tient secret ce nombre d'étages alors que pour le prescott tout le monde est au courant et qu'il y a vraiment pas de quoi s'en vanter...

Le Yonah, il me semble, en a déjà 14, non ?

[MiGiLL]

Non le Yonah descend du Pentium M qui, il me semble, n'en a que 12.

[fefe]

Le probleme est de definir ce que tu appelles profondeur du pipeline, apres avoir un chiffre n'est pas tres difficile. Sur Willamette la valeur generalement retenue est 21 mais a peu pres n'importe quel chiffre entre 21 et 30 peut etre justifiable.

Le marketing Intel communiquera probablement une valeur sur le pipeline de Conroe qui pourra au choix correspondre:
-au pipeline le plus court constate pour une operation entiere
-au pipeline le plus long constate pour une operation entiere
-au pipeline moyen pour une operation entiere
-a la penalite minimum d'un branchement
- .... maximum ...
- ... moyenne ...
Au final la valeur en soi n'apportera pas grand chose, vu que l'on sait deja qu'elle sera dans les memes eaux que Yonah &co, probablement un peu plus long vu les frequences de fonctionnement annoncées.

C'etait juste pour dire que les architectures modernes etaient suffisament complexes pour que la profondeur de pipeline ne soit plus un parametre simple et constant pour toutes les instructions.

Franck j'ai bien aimé ton article .

[Franxinator]

a propos de marketing intel, j'ai vu la pub VIIV deux fois en même pas 2 minutes, en l'occurence Wanadoo et HFR...(et j'avais déja entendu à la radio...c'est la que j'ai appris qu'il fallait dire Vaïve ).

on en revient à ce qui a souvent été dit ici, la différence entre amd et intel, elle est principalement là pour le grand public...

[Neo_13]

oui voilà, qqu'un a lu mon article ! :-)

j'en étais déjà convaincu avant... mais maintenant j'ai tes chiffres en plus