Article Prescott

[Alexko]

Avec des tableaux de 40 Mo on avait quasiment les mêmes résultats que avec les tables de 4 Mo ce qui est normale parceque au totale il s'agit de 3 * 4 mo. le cache L2 n'a quasiment plus d'effet surtout qu'il s'agit d''accès séquentielle.

Justement, l'accès séquentiel se prête bien aux algos de prefetching.

le cache L3 est "prefetchable" ?

[steph_d]

Un pipeline, c'est tout un processus. Dans le pipeline du P4, l'unité d'execution en elle-meme, c'est un seul étage (le 16 ou 17e si je me souvient bien).

Faut peut etre faire quelque part un lexique sur le site pour pas avoir de question de ce genre ....

[NaBoZo]

Le dictionnaire d'Onversity est excellent pour ça...

[steph_d]

Le dictionnaire d'Onversity est excellent pour ça...

:jap:

[Doc TB]

Le dictionnaire d'Onversity est excellent pour ça...

On va peut-etre utiliser un truc comme ca, mais pas celui d'onversity probablement, la license ne nous convient pas et on va utiliser un truc maison

[eponge]

Je pense qu'il y a là une certaine incompréhension du fonctionnement d'un
pipeline.
De façon théorique, la vitesse de traitement dans un pipeline augmente
avec sa profondeur, comme je l'ai expliqué dans un post précédent.
Mais à vitesse d'horloge donnée, une pipeline à 30 niveaux ne sera pas plus rapide qu'un pipeline à 20, 10 ou même 2 niveaux, car le débit maximal d'un pipeline est d'une instruction par cycle, et ce quelle que soit sa profondeur.

Dire que la vitesse de traitement du pipeline augmente avec la profondeur ne signifie qu'une chose : le pipeline peut être cadencé plus rapidement.

Et donc le pipeline du Prescott ne peut, en aucun cas, être plus rapide que celui du Northwood cadencé à la même vitesse. En pratique c'est même l'inverse, à cause des pénalités dues à la plus grande profondeur.

Les résultats révélés par les petits programmes sont à mon avis interprétable de façon complètement différente.

Les tests avec les tables de 4Mo révèlent le Prescott plus rapide, cela est juste du à la taille du L2. Avec un L2 de 1Mo, le Prescott fait moins d'accès à la mémoire (d'autant plus vrai avec le prefetch amélioré) et reste donc plus souvent dans son cache L2 que le Northwood. C'est aussi simple que ça.

Dans les test de 40Ko les deux processeurs travaillent dans leurs caches (L1+L2). Dans ce cas, le pipeline plus court et les latences inférieures des caches du Northwood lui donnent l'avantage.

En ce qui concerne les latences des caches, celle du L1 est certainement imputable au pipeline plus long. Rappelons que la latence mesurée du L1 correspond n'est pas la latence réelle, mais bien celle issue du mécanisme de spéculation.
Quant à celle du L2, elle augmente de 50% par rapport au Northwood (16 x 1.5 = 25), et il s'agit là de la latence réelle contrairement à ce que l'on mesure sur le L1. Il y a fort à parier que la latence du L2 a été augmentée de façon à pouvoir supporter les plus hautes fréquences.
Et d'ailleurs quand on regarde de plus près :
- le pipeline est 50% plus long
- Intel espère un gain de fréquence de l'ordre de 50% par rapport au plus
rapide des Northwood (3.4 x 1.5 = 5GHz)
- la latence du L2 a donc été en conséquence augmentée de 50% également.
Tout ceci se recoupe.

Ok Ok, j avais pas du tout saisi le fonctionnement du pipeline.

Je cherche a comprendre.. j aime bien avoir un avis oppose pour pouvoir compare, et comme le dit triad, ce n'est pas sur clubic ou pc inpact qu on trouvera l'info. j ai fait d autres recherches a cote, mais sans commentaires ou possibilite d'explications c est mal barre.


Maintenant autre question rapport au prescott :

Pourquoi faire toutes ses ameliorations (trace cache, pipeline rallonge, passage en 0.09µ) si c est pour derriere coller un 2nd pipeline, d autres ALU pour qu au final ca chauffe et empecher une montee plus importante ?

Si intel avait ameliore le trace cache, rallonge le pipeline, ameliore la prediction, passage en 0.09µ, on aurait bcp moins de transistor, ca chaufferai moins (a moins que l'on puisse desactiver les transistor "electriquement") et ca permettrait de monter plus rapidement ? C est peut etre pas dans leur interet ? ils veulent tester le double pipeline ?

[fennec]

Maintenant autre question rapport au prescott :

Pourquoi faire toutes ses ameliorations (trace cache, pipeline rallonge, passage en 0.09µ) si c est pour derriere coller un 2nd pipeline, d autres ALU pour qu au final ca chauffe et empecher une montee plus importante ?

En imposant un changement en termes de voltage et de dissipation thermique, Intel prépare le Tejas, qui selon beaucoup sera au northwood ce qu'a été le northwood au williamette. Comme ça toutes les cartes mères et les dissipateurs sur socket LGA seront "compatibles" Tejas. (ça n'est qu'un suposition)

Si intel avait ameliore le trace cache, rallonge le pipeline, ameliore la prediction, passage en 0.09µ, on aurait bcp moins de transistor, ca chaufferai moins (a moins que l'on puisse desactiver les transistor "electriquement") et ca permettrait de monter plus rapidement ? C est peut etre pas dans leur interet ? ils veulent tester le double pipeline ?

il est rare qu'un constructeur comme Intel fasse des erreurs, et l'épisode Williamette nous a bien montré qu'il faut souvent reculer pour mieux sauter. A la lecture de l'article on sent bien qu'il y a un potentiel très fort dans le Prescot mais personne se sait dans quelle mesure...

[Bibiche]

Bon : déjà j'ai mal au crane car je viens de me taper toutes les pages du post et une relecture de l'article de x86 et de onversity

Sinon : quelle différence entre dual-core et dual pipeline ? il manque les instructions annexes ? les pipes devront se partager certaines ressources car toutes ne semblent pas doublées (voir exemple des 2 cerveaux pour deux oreilles mais une seule bouche).

si le prescott a 2 pipelines : comment l'OS le gère ? il ne voit qu'un CPU (physique donc tjrs 2 cpu logiques) le proc envoyant un des deux résultats ? ce qui revient +/- a amélioré la prédiction de branchement ? ou bien alors on a bien affaire à 2 core physique (donc 4 logiques avec l'HT) même si les 2 cores doivent se partager certaines ressources ?

[Doc TB]

'tain, vous confondez vraiment tout. :heink:

Un core, c'est *PHYSIQUE*, ce sont des transistors qui font une action.

Un pipeline, c'est pas physique, c'est une méthode de traitement des informations, un protocole si vous preferez

[Bibiche]

OK OK calme calme pas taper...
je me suis mal exprimer : sur la photo du prescott on peut voir 2 cores d'exécutions avec L1 (physiques) maintenant comment seront "vus" ces 2 cores quand il seront activés ? comme 2 CPU ou alors comme un seul CPU et en interne il travaillerait en "parallèle" ce qui boosterait les appli multi-treads.
Ce qui me fait penser a ça c'est l'appelation Hypertreading2 dont Intel semble avoir reportée l'annonce ; peut-être jusqu'à l'activation du 2ième CPU (et passage au prochain socket?).
ou alors l'HT2 n'était que l'amélioration de la prédiction de branchement et les instructions SSE3 qui améliorent l'HT et Intel a jugé que l'appélation HT2 n'était pas justifié pour un gain de 20% de perf.

[Doc TB]

HT, c'est Hyper-Threading, ca n'a strictement rien a voir avec la prédiction de branchement ou le SSE3.

Qd tu fabrique une caisse, tu va marquer ABS dessus parcequ'il a un autoradio lecteur CD ?

[Bibiche]

pas la prédiction de branchement mais le prefetcher : sorry j'ai inversé... la fatigue
par contre dans le SSE3 il y a bien deux instructions qui optimise l'HT, là je te cite :
Instruction MONITOR / MWAIT
Il s'agit cette fois d'instruction uniquement destinée à gerer au mieux l'Hyper-Threading.

OK elles sont encore inutilisées mais bon ça aurait pu justifié une petite partie de l'appelation HT2.

[Oxygen3]

les 2 nvelles instructions servent à gérer les threads utilisés par l'HT mais pas vraiment l'HT directement
elles remplacent le boulot fait par l'OS normalement en fait

[Alexko]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

[fennec]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

[Bibiche]

et pour le bi-core : sera-t-il vu par l'OS comme 2 CPU distincts comme un système bi-CPU actuel ou alors vu comme un seul CPU par l'OS et c'est ensuite en interne que le CPU partage les taches, si c'est le cas ça va devenir comique niveau baratin chez carouf :
"Alors ma brave dame le processeur en contient deux vu comme un processeur mais géré comme deux par windows"
traduction :
Le CPU contient deux core d'exécution (physiques) vu comme un seul par win qui gère 2 processeurs logiques.
si l'OS voit bien les 2 cores et donc 4 CPU logiques c'est déjà pas mal :
"Alors ma brave dame c'est très bien, il faut acheter du Intel : 4 processeurs pour le prix d'un !"
Il y aurait de quoi s'arracher les cheveux.

[Filou]

Selon les echos que j'ai pu avoir, c'est loin d'etre le cas et il y aurait meme des étages actuellement "inutilisés" (des drives entre les deux cores ?)...

Même dans le Willamette/Northwood, depuis la sortie du P4 en fait il y a des rumeurs selon lesquelles certaines étapes du pipeline sont là comme étape supplémentaire inutile juste pour gagner en fréquence, plutôt que d'avoir un goulot.

il est rare qu'un constructeur comme Intel fasse des erreurs, et l'épisode Williamette nous a bien montré qu'il faut souvent reculer pour mieux sauter. A la lecture de l'article on sent bien qu'il y a un potentiel très fort dans le Prescot mais personne se sait dans quelle mesure...

Je pense que le Willamette était clairement une erreur, mais une erreur qu'ils ont été forcés à faire: le P3 était à bout de souffle face à l'Athlon et ils ont du castrer le P4 de 256 Ko de cache et le sortir en 0.18µ pour contrer AMD.

[fennec]

il est rare qu'un constructeur comme Intel fasse des erreurs, et l'épisode Williamette nous a bien montré qu'il faut souvent reculer pour mieux sauter. A la lecture de l'article on sent bien qu'il y a un potentiel très fort dans le Prescot mais personne se sait dans quelle mesure...

Je pense que le Willamette était clairement une erreur, mais une erreur qu'ils ont été forcés à faire: le P3 était à bout de souffle face à l'Athlon et ils ont du castrer le P4 de 256 Ko de cache et le sortir en 0.18µ pour contrer AMD.

c'est clair, quand on voit ce qui avait été annoncé par rapport à ce qui est sortis ... je me souviens pas bien mais il me semble qu'il avait été sérieusement castré le Williamette .... Mais ça a quand même été un gros changement et ça a introduit l'architechture NetBurst. Ce qui a le plus nuis au Williamette c'est le fait que RamBus n'ai pas ouvert sa technologie ... si ils l'avaient fait je ne sais pas si on aurait eu de la DDR sur les P4 ...

[Alexko]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

justement, y'a des chances pour que ca permette d'exécuter une opération sur 64 bits, mais en deux parties, c'est du moins l'hypothèse avancée par www.chip-architect.com

[fennec]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

justement, y'a des chances pour que ca permette d'exécuter une opération sur 64 bits, mais en deux parties, c'est du moins l'hypothèse avancée par www.chip-architect.com

tu veux dire que chaque corps d'execution traiterais une partie du calcul ? c'est assez étrange comme idée ... je vois pas comment réaliser ça avec les divisions et les multiplications ... enfin, qui vivra verra

edit: sachant qu'en plus les cpu actuels peuvent faire des calculs en 128bits, ce qui manque c'est les registres de 64bits pour faire le calcul en 1 seul cycle (en théorie) et je vois pas trop ce qu'un double corps ferais ldans cette histoire ...

[Alexko]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

justement, y'a des chances pour que ca permette d'exécuter une opération sur 64 bits, mais en deux parties, c'est du moins l'hypothèse avancée par www.chip-architect.com

tu veux dire que chaque corps d'execution traiterais une partie du calcul ? c'est assez étrange comme idée ... je vois pas comment réaliser ça avec les divisions et les multiplications ... enfin, qui vivra verra

edit: sachant qu'en plus les cpu actuels peuvent faire des calculs en 128bits, ce qui manque c'est les registres de 64bits pour faire le calcul en 1 seul cycle (en théorie) et je vois pas trop ce qu'un double corps ferais ldans cette histoire ...

Des calculs 128 bits ? par l'ALU ? hum ca me semble bizarre.
C'est vrai que l'idée de partager le calcul comme ca semble étrange, voire meme foireuse, je pense qu'Intel n'a pas eu le temps de faire mieux

[Lissyx]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

justement, y'a des chances pour que ca permette d'exécuter une opération sur 64 bits, mais en deux parties, c'est du moins l'hypothèse avancée par www.chip-architect.com

tu veux dire que chaque corps d'execution traiterais une partie du calcul ? c'est assez étrange comme idée ... je vois pas comment réaliser ça avec les divisions et les multiplications ... enfin, qui vivra verra

edit: sachant qu'en plus les cpu actuels peuvent faire des calculs en 128bits, ce qui manque c'est les registres de 64bits pour faire le calcul en 1 seul cycle (en théorie) et je vois pas trop ce qu'un double corps ferais ldans cette histoire ...

Des calculs 128 bits ? par l'ALU ? hum ca me semble bizarre.
C'est vrai que l'idée de partager le calcul comme ca semble étrange, voire meme foireuse, je pense qu'Intel n'a pas eu le temps de faire mieux

il doit parler des unités multimédias non ?

[Alexko]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

justement, y'a des chances pour que ca permette d'exécuter une opération sur 64 bits, mais en deux parties, c'est du moins l'hypothèse avancée par www.chip-architect.com

tu veux dire que chaque corps d'execution traiterais une partie du calcul ? c'est assez étrange comme idée ... je vois pas comment réaliser ça avec les divisions et les multiplications ... enfin, qui vivra verra

edit: sachant qu'en plus les cpu actuels peuvent faire des calculs en 128bits, ce qui manque c'est les registres de 64bits pour faire le calcul en 1 seul cycle (en théorie) et je vois pas trop ce qu'un double corps ferais ldans cette histoire ...

Des calculs 128 bits ? par l'ALU ? hum ca me semble bizarre.
C'est vrai que l'idée de partager le calcul comme ca semble étrange, voire meme foireuse, je pense qu'Intel n'a pas eu le temps de faire mieux

il doit parler des unités multimédias non ?

je pense qu'il parle justement des ALUs, à moins qu'il y ait confusion avec les FPUs

[steph_d]

:heink:
je suis pas expert mais j'ai l'impression que ce topic (tres interessant par ailleurs)part en vrille.... (je fais quasiment que des lectures car mon niveau n'étant pas suffisant, je prefere m'abstenir plutot que de raconter des conneries).

[fennec]

de toute facon il y a peu de chances pour que les deux cores servent à améliorer la parallélisation, mais c'est plutot ce qu'on connaissait sous le nom de code Yamhill

le yamhil n'a rien a voir avec le double corps d'execution du prescot, le yamill c'est le 64bits du prescot ...

justement, y'a des chances pour que ca permette d'exécuter une opération sur 64 bits, mais en deux parties, c'est du moins l'hypothèse avancée par www.chip-architect.com

tu veux dire que chaque corps d'execution traiterais une partie du calcul ? c'est assez étrange comme idée ... je vois pas comment réaliser ça avec les divisions et les multiplications ... enfin, qui vivra verra

edit: sachant qu'en plus les cpu actuels peuvent faire des calculs en 128bits, ce qui manque c'est les registres de 64bits pour faire le calcul en 1 seul cycle (en théorie) et je vois pas trop ce qu'un double corps ferais ldans cette histoire ...

Des calculs 128 bits ? par l'ALU ? hum ca me semble bizarre.
C'est vrai que l'idée de partager le calcul comme ca semble étrange, voire meme foireuse, je pense qu'Intel n'a pas eu le temps de faire mieux

il doit parler des unités multimédias non ?

oui, je voulais pas dire qu'il pouvait faire tous les calculs en 128bits, juste certains ...

ce que je voulais dire c'est que la pluspart des calculs ne peuvent pas être découpés en deux parties sur 32bits, mais nos idées se rejoignent sur le qualifiquaitf "foireux" :D

[cpulloverclock]

sinon jai vu un 4336MHz en air cooling avec un 3.2E
1.535v sur une IC7, je sais que j'av reussi a foutre du 0.925v sur la IC7 en faisant bugger les pins du proc, la mobo lisait ts les vcores avec -0.6v

[Alexko]

je vois pas trop ce qu'un double corps ferais ldans cette histoire ...

Des calculs 128 bits ? par l'ALU ? hum ca me semble bizarre.
C'est vrai que l'idée de partager le calcul comme ca semble étrange, voire meme foireuse, je pense qu'Intel n'a pas eu le temps de faire mieux[/quote]

il doit parler des unités multimédias non ?[/quote]
oui, je voulais pas dire qu'il pouvait faire tous les calculs en 128bits, juste certains ...

ce que je voulais dire c'est que la pluspart des calculs ne peuvent pas être découpés en deux parties sur 32bits, mais nos idées se rejoignent sur le qualifiquaitf "foireux" :D[/quote]

ah ok :D
je pense qu'Intel au départ n'avait pas prévu d'intégrer le yamhill au Prescott, donc ils s'y sont pris un peu tard, et ils ont fait ce qu'ils ont pu

[fennec]

je pense qu'Intel au départ n'avait pas prévu d'intégrer le yamhill au Prescott, donc ils s'y sont pris un peu tard, et ils ont fait ce qu'ils ont pu

Je pense pas, ça fait un bout de temps qu'on parle du Yamill, et pour ce qui est du 64bits c'est pas nouveau pour Intel. J'ai plustot l'impression qu'Intel n'a pas eu peur d'AMD avec son A64, et qu'ils ont retardé la sortie du Prescot pour écouler les northwood tranquillement. Par contre vu comment c'est parti j'ai vraiment l'impression que le yamill sera compatible avec l'x86-64 ...

[Neo_13]

je pense qu'Intel au départ n'avait pas prévu d'intégrer le yamhill au Prescott, donc ils s'y sont pris un peu tard, et ils ont fait ce qu'ils ont pu

Je pense pas, ça fait un bout de temps qu'on parle du Yamill, et pour ce qui est du 64bits c'est pas nouveau pour Intel. J'ai plustot l'impression qu'Intel n'a pas eu peur d'AMD avec son A64, et qu'ils ont retardé la sortie du Prescot pour écouler les northwood tranquillement. Par contre vu comment c'est parti j'ai vraiment l'impression que le yamill sera compatible avec l'x86-64 ...

j'ai un doute

quand aux FPU, yen a qu'une dans les P4

et les registres mmx font 64bits
et les SSE et SSE2 font 128bits

[Alexko]

je pense qu'Intel au départ n'avait pas prévu d'intégrer le yamhill au Prescott, donc ils s'y sont pris un peu tard, et ils ont fait ce qu'ils ont pu

Je pense pas, ça fait un bout de temps qu'on parle du Yamill, et pour ce qui est du 64bits c'est pas nouveau pour Intel. J'ai plustot l'impression qu'Intel n'a pas eu peur d'AMD avec son A64, et qu'ils ont retardé la sortie du Prescot pour écouler les northwood tranquillement. Par contre vu comment c'est parti j'ai vraiment l'impression que le yamill sera compatible avec l'x86-64 ...

je pense qu'il était au départ prévu pour le Tejas, voire même plus tard, et finalement avancé en catastrophe apres les annonces concernant Win XP-64, les partenariats d'AMD avec Sun et compagnie.