Conroe et innovations

**bjone** · 06/05/2006, 16h02

Envoyé par Sam D.

Non, tu ne comprends pas. Tu as une vision à 6 mois / 1 an la. Alors c'est sur que dans ce cas, Conroe, c'est trés bien.

Maintenant, regarde un peu plus loin. Tu sais comme moi que l'architecture P6, c'est bien beau, mais qu'on ne va pas monter à 10 GHz avec ça. Donc on fait comment pour augmenter les perfs, m'sieur ? Bah y a pas 16 solutions : Soit on augmente le pipe et on fait de la vectorisation à la chaine, soit on augmente le nombre de core et on fait du parallelisme à la chaine.

Dans tout les cas, ce sont ces technologies (parallelisme et vectorisation) ou plutot la facon de les exploiter qui vont faire le futur du CPU. Et Conroe, c'est donc un formidable retour en arriere. A cause de raison marketing.

c'est pas faux :D

mais disons que la problème c'est d'arriver a l'archi la plus perf.

tu dis que le netburst a échoué a cause de la prod.
bin ouais mais les archi ppro-like ont remontés le netburst grâce à 2/3 retouches et a la prod.

alors je vois par pourquoi la prod aurait pu faire suffisamment progresser les archi ppro non orientés montée en fréquence, et échouer sur le netburst "optimisé" a plusieures reprises pour la montée en fréquence.

au bout d'un moment, il faut se remettre en question.

alors qu'il y ait des trucs bien dans le netburst, je veux bien, mais que ce soit parfait bah l'expérience a montré que...

après je pense que c'est des compromis dont les extrêmes sont assez incompatibles, et ça en devient des écoles de pensées.

**Franck@x86** · 06/05/2006, 18h17

Pour faire bref, la performance peut s'évaluer par le rapport fréquence / CPI.
Le CPI augmente avec le nombre d'étages du pipeline, mais la fréquence aussi. Une rapide simu montre que le rapport entre les deux augmente avec le nbre d'étapes du pipeline, càd que l'augmentation du CPI induite par le découpage est compensée par l'augmentation de fréquence induite par ce même découpage. Et ce jusqu'à environ 56 étapes (soit une fois et demie la profondeur du Prescott). Bien sûr la courbe d'applatit, mais la progression continue.
La philosophie Netburst c'est ça, c'est la promesse d'une évolutivité, à mesure que les technologies de fabrication s'améliorent.
Il n'est pas question d'archi parfaite, il est question de "promesse de performance". L'archi après est adaptée pour répondre aux contraintes de cette évolution (dans le cas du Netburst elle consistait à augmenter le CPI le moins possible).

Core par contre va vite se trouver bloqué sur la fréquence. Reste donc à diminuer le CPI pour obtenir les perfs. Mais diminuer le CPI c'est compliqué, ça se conçoit en terme de largeur de traitement (+ de décodeurs, + d'unités de calcul), de sous-système de cache, et bien sûr de parallélisation. Donc oui Core c'est performant, mais ça plafonnera rapidement.

Y'a un truc quand même qui est bizarre et qui devrait mettre la puce à l'oreille. A chaque changement de process, les CPUs ont gagné qques MHz. Sauf le Cedar Mill, il plafonne toujours à 3,8GHz., comme le Prescott. Alors évidemment on peut expliquer ça par la volonté de laisser au Conroe un avantage conséquent en terme de performances. Mais si on y regarde de près, on remarque que dans le passé un tel chevauchement n'a jamais vraiment dérangé Intel, car la nouvelle archi était de toute façon amenée à évoluer de telle façon qu'un jour ou l'autre elle prendrait le pas sur la précédente. Preuve donc que Conroe n'a pas de potentiel d'évolutivité important.

**Dandu** · 08/05/2006, 23h24

Pour ce qui est du nombre de transistor et de la taille, je me suis déja posé la question avec le Yonah.

Un Dothan avec 2x32Ko de L1 et 2Mo de L2 fait 140.000.000 de transistor.
Le Yonah, avec 2 core d'exécutions et 2Mo de L2 fait seulement 151.000.000 de transistors.

Ca fait peu 11.000.000 de transistors pour un core (amélioré).

D'ailleurs, le L2 est partagé, mais le L1 ?

**EPIC** · 08/05/2006, 23h32

Envoyé par Franck@x86

Pour faire bref, la performance peut s'évaluer par le rapport fréquence / CPI.
Le CPI augmente avec le nombre d'étages du pipeline, mais la fréquence aussi. Une rapide simu montre que le rapport entre les deux augmente avec le nbre d'étapes du pipeline, càd que l'augmentation du CPI induite par le découpage est compensée par l'augmentation de fréquence induite par ce même découpage. Et ce jusqu'à environ 56 étapes (soit une fois et demie la profondeur du Prescott). Bien sûr la courbe d'applatit, mais la progression continue.
La philosophie Netburst c'est ça, c'est la promesse d'une évolutivité, à mesure que les technologies de fabrication s'améliorent.
Il n'est pas question d'archi parfaite, il est question de "promesse de performance". L'archi après est adaptée pour répondre aux contraintes de cette évolution (dans le cas du Netburst elle consistait à augmenter le CPI le moins possible).

Core par contre va vite se trouver bloqué sur la fréquence. Reste donc à diminuer le CPI pour obtenir les perfs. Mais diminuer le CPI c'est compliqué, ça se conçoit en terme de largeur de traitement (+ de décodeurs, + d'unités de calcul), de sous-système de cache, et bien sûr de parallélisation. Donc oui Core c'est performant, mais ça plafonnera rapidement.

Y'a un truc quand même qui est bizarre et qui devrait mettre la puce à l'oreille. A chaque changement de process, les CPUs ont gagné qques MHz. Sauf le Cedar Mill, il plafonne toujours à 3,8GHz., comme le Prescott. Alors évidemment on peut expliquer ça par la volonté de laisser au Conroe un avantage conséquent en terme de performances. Mais si on y regarde de près, on remarque que dans le passé un tel chevauchement n'a jamais vraiment dérangé Intel, car la nouvelle archi était de toute façon amenée à évoluer de telle façon qu'un jour ou l'autre elle prendrait le pas sur la précédente. Preuve donc que Conroe n'a pas de potentiel d'évolutivité important.

Pourtant Intel y vas dare dare en annonçant des Conroe Extrême Edition à plus de 3 Ghz... Preuve qu'Intel à effectivement à quelquechose derrière la tête ils ont avancés le planning de sortie de Conroe pour certainement mettre un coup de mattraque à AMD avant de sortir dans trois ans leur nouvelle (réellement inovante) architecture (Netburst 2, Nehalem, autre ??? ) Intel semble en veine avec ses process de lithographie en ce moment, la Roadmap du 65 nm c'est déroulé dans les temps (déja 3 architectures dessus dont deux commercialisées) et celle du 45 nm est en bonne voie, j'ai comme l'impression que l'on vas assiter d'ici 3 ans à un vrai bon technogique...

**Neo_13** · 09/05/2006, 07h48

Envoyé par dandu

Pour ce qui est du nombre de transistor et de la taille, je me suis déja posé la question avec le Yonah.

Un Dothan avec 2x32Ko de L1 et 2Mo de L2 fait 140.000.000 de transistor.
Le Yonah, avec 2 core d'exécutions et 2Mo de L2 fait seulement 151.000.000 de transistors.

Ca fait peu 11.000.000 de transistors pour un core (amélioré).

D'ailleurs, le L2 est partagé, mais le L1 ?

partager le L1 me parait suicidaire au niveau des accès L1...

**Dandu** · 09/05/2006, 10h15

Moi aussi, mais bon.

Bania : 77.000.000 au total. On enlève le Mo de cache : reste 20,3 millions
Dothan : 140.000.000 nau total. On enlève le L2 : rest 26,7 millions
Yonah : 151 millions au total. On enlève le L2 : reste 37,7 millions pour 2 cores. Et c'est censé être un peu amélioré.

Passage Bania -> Dothan : +7 millions, en amélioration.
Passage Dothan -> Yonah : +10 millions, en doublant un core de 26millions

Y a un truc que je capte pas dans l'histoire. Et même en supprimant le L1 du comptage de la taille du core, on est encore trop haut.

Le seul moyen que j'ai trouvé pour un comptage de données plus ou moins identique, c'est en mettant un cache ECC sur le Dothan et un pas ECC sur le Yonah. Et sur les captures CPUZ que j'ai vue, le L2 est en cache disabled sur les Yonah, et enabled sur mon Dothan... Et accesoirement, la différence de vitesse de cache peut venir de la aussi (en RAM, les ECC sont moins rapides, non ?)

**voxel** · 09/05/2006, 10h46

Je veux pas paraitre hors sujet et je vais peut etre dire une connerie mais la RAM n'est pas aussi un facteur limitant qq part a l'evolution des cpus? On tourne encore avec de la DDR premiere génération devant une DDR2 qui peine a montrer de réelles avancées de peformance par rappart a la premiere. Ou alors ce sont les cpus qui ne sont pas suffisement bien concues pour tirer partie de la DDR2 (cf: pas grand chose de plus sur un K8 ddr2 et sur socket AM2)?

**Dandu** · 09/05/2006, 11h00

Oui et non, la DDR2 a des avantages en débit et en consommation (pratique pour les portables).

Pour les K8, c'est simples : le contrôleur mémoire intégré est beaucoup plus sensibles à la latence de la mémoire qu'a sa vitesse. Et comme le problème de la DDR2 c'est la latence.

**EPIC** · 09/05/2006, 11h06

Envoyé par dandu

Moi aussi, mais bon.

Bania : 77.000.000 au total. On enlève le Mo de cache : reste 20,3 millions
Dothan : 140.000.000 nau total. On enlève le L2 : rest 26,7 millions
Yonah : 151 millions au total. On enlève le L2 : reste 37,7 millions pour 2 cores. Et c'est censé être un peu amélioré.

Passage Bania -> Dothan : +7 millions, en amélioration.
Passage Dothan -> Yonah : +10 millions, en doublant un core de 26millions

Y a un truc que je capte pas dans l'histoire. Et même en supprimant le L1 du comptage de la taille du core, on est encore trop haut.

Le seul moyen que j'ai trouvé pour un comptage de données plus ou moins identique, c'est en mettant un cache ECC sur le Dothan et un pas ECC sur le Yonah. Et sur les captures CPUZ que j'ai vue, le L2 est en cache disabled sur les Yonah, et enabled sur mon Dothan... Et accesoirement, la différence de vitesse de cache peut venir de la aussi (en RAM, les ECC sont moins rapides, non ?)

Ouais ou alors il y a des redondance de cache en moins... c'est combien la norme 10 % de cache en plus ? ou alors Intel à omis volontairement certain transistors dans son comptage...

**Franck@x86** · 09/05/2006, 11h43

Je pense que les archis faites pour durer 6 ans c'est terminé. L'investissement est trop important, et le risque est trop gros de tomber sur un os en milieu de parcours, comme il s'est passé pour Netburst.
Les nouvelles archis seront définies pour avoir une durée de vie de 2 ans, 3 max en tirant sur la corde.

Le fond du problème c'est qu'il est de plus en plus risqué d'essayer de deviner comment évolueront les technologies sur une durée de 5 ou 6 ans. De plus la pression du marché est telle que les fondeurs ne peuvent pas se permettre de rester 6 mois sans sortir qquechose (ce qui n'était pas le cas y'a 8-10 ans).
Bref, nous voilà dans l'ère des archis jetables

Bizarre le coup des transistors en effet :???:

**Dandu** · 09/05/2006, 14h45

Pour le cache L2 qui ne soit pas ECC sur les Yonah , c'est possible Franck ?

Parce que les captures Cpu-Z que j'ai vue sur le net indique tout "no" ou disabled". Et sur le Dothan c'est "enabled".

Et la ca tombe juste :

Dothan : 140.000.000 de transistors, dont 113 millions pour le L2 (ECC)(2048*1024*9*6) : core d'environ 26 millions de transistor.
Yonah : 151.000.000 de transistors, dont 100 millions pour L2 (pas en ECC)(2048*1024*8*6) : core d'environs 50 millions de transistor, soit à peu près 2X un core Dothan.

**Franck@x86** · 09/05/2006, 15h15

L'info ECC est retournée par un MSR (BBL_CR_CTL3), le même pour P6, PM et Yonah. La doc indique que :
- sur P6 le bit est R/W.
- sur P-M il est RO, mais il est indiqué que l'ECC est toujours activé.
- sur Core Solo/Duo il est RO mais rien n'est précisé.

J'aurais dit à première vue que tous les L2 intégrés ont l'ECC, mais finalement ça a peut-être changé pour le Yonah, je sais pas trop (sur Core 2 aussi c'est disabled tiens).

**Dandu** · 09/05/2006, 15h54

Sam pense la même chose, mais il parle pas de cache ECC dans les datasheets Intel des core duo.

js · 09/05/2006, 19h22

Salut à tous

Je me pose une petite question en relisant des vieilles news et des vieux articles : le 64 bit a déjà disparu du discours marketing pour le conroe ?

**Franxinator** · 10/05/2006, 00h45

je pense pas que ça soit l'argument à mettre en valeur, surtout depuis que le 64bit est sur toute la gamme intel -sauf yonah- du celeron au P4.
D'ailleurs je trouve qu'AMD s'est un peu lassé de cet argument...enfin à mes yeux. c'est plutot "on l'a et puis voila" que "le 64 bits va rendre votre PC super rapide avec un A64"

**Neo_13** · 10/05/2006, 08h08

et puis je me demande si ça marche toujours aussi bien comme argument *.

Et ils n'ont aucun intérêt à le faire, à part rappeler qu'amd était premier

**Childerik** · 10/05/2006, 10h52

Envoyé par Neo_13

et puis je me demande si ça marche toujours aussi bien comme argument *.

Et ils n'ont aucun intérêt à le faire, à part rappeler qu'amd était premier

D'autant que le premier 64 bits prototypaire date de 1992 :whistle: (qui a dit MIPS ?)

**Neo_13** · 10/05/2006, 14h37

Envoyé par childerik

D'autant que le premier 64 bits prototypaire date de 1992 :whistle: (qui a dit MIPS ?)

pas moi... moi je dis alpha... pour tout un tas de raison, et pis je fais ce que je veux aussi.

**KRUMLI** · 10/05/2006, 17h08

Je suis pas vraiment d'accord avec le "lynchage" de l'archi Core:

1. Je ne pense pas que Core soit une reponse principalement marketing. C'est une reponse technique a un probleme technique du Netburst face au K8.

2. L'argument du retour en arriere ne me choque pas: et si l'archi P6/K7 (donc assez efficiente ) etait juste le bon (ou moins pire) type d'archi pour le x86 ?

3. Il est clair que le temps des archi qui dure 6 ans est revolu. D'un point de vue beaute theorique, une archi faite pour evoluer sur le long terme est plus enthousiasmant, c'est vrai.

Sinon, plus globalement, je pense qu'on regarde trop ce genre d'evolution par la petite lorgnette du power user.

Desole pour le clavier qwerty

**Neo_13** · 10/05/2006, 18h23

Envoyé par KRUMLI

Sinon, plus globalement, je pense qu'on regarde trop ce genre d'evolution par la petite lorgnette du power user.

Pas vraiment...

Core va être utilisé 2ans pour combler un retard technologique de gravure, et ensuite, retour archi longue... netburst et consort...

**KRUMLI** · 10/05/2006, 19h37

Envoyé par Neo_13

Pas vraiment...

Core va être utilisé 2ans pour combler un retard technologique de gravure, et ensuite, retour archi longue... netburst et consort...

Tu as des sources pour affirmer ca ?

Je veux bien y croire mais ca me parait bizarre :???:

**Neo_13** · 10/05/2006, 20h06

Envoyé par KRUMLI

Tu as des sources pour affirmer ca ?

Je veux bien y croire mais ca me parait bizarre :???:

un peu de raisonnement permet de déduire ce genre de chose (avec un peu de recul)

**KRUMLI** · 10/05/2006, 20h07

Envoyé par Neo_13

un peu de raisonnement permet de déduire ce genre de chose (avec un peu de recul)

RdV dans 2-3 ans alors :D

**Neo_13** · 10/05/2006, 20h18

le nombre d'étage est déjà reparti à la hausse... conroe a plus d'étage que yonah...

**Franck@x86** · 10/05/2006, 20h32

Il n'est pas ici question de lyncher l'architecture Core, c'est même plutôt l'inverse : Core est une EXCELLENTE architecture, y'a qu'à voir les performances pour s'en convaincre.

Ce qu'on critique ici est la démarche de Intel. Une archi telle que Core ne laissera pas de traces, elle le fera pas avancer son successeur, bref elle repose sur des épaules de génie et à ce titre ne court aucun risque.

Maintenant une fois de plus, Core c'est du tout bon, encore heureux car c'est une compile de ce qui se fait de mieux ajourd'hui.

**Doc TB** · 10/05/2006, 21h33

Reste que c'est la premiere fois qu'Intel lance une nouvelle "architecture" qui n'en est pas une et qui est a fond dés le lancement.

**Neo_13** · 10/05/2006, 23h36

la question, c'est "est-elle à fond ?" ou est-ce qu'ils ont des subtilités comme le threading hardware ou autre "bidule" inconnu actuellement ?

S'il est clair qu'il n'y a pas de grandes nouveautés, on pourrait cependant se demander s'il ne vont pas se servir de conroe et consorts pour développer une techno autre (comme ils s'étaient servi de willamette et northwood pour développer l'hyperthreading, par exemple)...

Peut être envisage-t-il aussi un retour d'expérience de l'itanium 2 aussi, qui me semble dans une position délicate, avoir le leadership des perf, mais ne pas être utilisé. Pipeline court, cache énorme, unités nombreuses etc... fusion d'op (meme si sur ce point c'est très flou, pour moi)...

Bref juste un point d'arrêt temporaire, ou aussi un labo d'essai (le point d'arrêt est indiscutable) ?

**Franck@x86** · 11/05/2006, 11h29

Il planne une espèce de mystère autour du SSE4.
Avec Jihef on a trouvé les instructions, donc c'est du concret, mais Intel n'en parle pas du tout sur son site.

Je me demande si ça deviendra pas une sorte d'extension du SSE3, peut-être qu'Intel n'a pas jugé utile d'allonger la liste des SSE une fois de plus ...

Carrément mystérieux.

**Neo_13** · 11/05/2006, 12h53

le sse4 d'une part mais peut etre quelque chose d'autre dont ils ne parlent pas encore... quoiqu'au nombre de transistors, ça parait dificile.

**boblemagnifique** · 11/05/2006, 18h27

Pour ce qui est du cache L2 des yonahs , il se compose bien de 2mo a partager pour les 2 cores , merom 4mo l2 a partager pour les 2 cores également nan ? (on m a dit vu que j etais parti sur du 2x2mo et 2x4mo :whistle: )

Ca change des AMD DC avec chacun 1mo L2 par core ou mm des Pentium D (2x1mo and 2x2mo) il me semble :jap:

Discussion: Conroe et innovations

Outils de la discussion

Règles de messages