Intel Core i7 (Nehalem) : une architecture signée AMD ?

25/09/2008 à 08:40 par Fedy Abi-Chahla

Introduction

Il y a deux ans Intel a réussi un coup de maitre en introduisant l’architecture Conroe (via les processeurs Core 2 Duo et Quad), lui permettant de regagner la couronne des performances après la débâcle du Pentium 4. A cette époque Intel a même annoncé un plan ambitieux visant à réintroduire un rythme d’évolution rapide de ses architectures qui était présent au milieu des années 90 mais avait ensuite petit à petit disparu. La première phase du plan consistait à introduire un « refresh » de l’architecture 12 mois après son introduction pour profiter des avancées des technologies de gravure, ce qui fut fait avec le Penryn. Puis une toute nouvelle architecture devait arriver 24 mois plus tard dont le nom de code était Nehalem : c’est de cette dernière que nous allons parler aujourd’hui.

L’architecture Conroe avait beau offrir des performances de tout premier plan et une consommation des plus raisonnables, elle n’en était pas parfaite pour autant. Il faut dire que les conditions de sa mise au point n’ont pas été idéales : lorsqu’Intel a constaté l’impasse dans laquelle le menait le Pentium 4 il a fallut réinventer à toute vitesse, ce qui pour des sociétés de la taille d’Intel est loin d’être aisé. L’équipe d’ingénieurs d’Haïfa (Israël) qui avait jusque là la responsabilité des architectures mobiles, se voyait ainsi promue à la conception de toute la nouvelle gamme du géant de Santa Clara. Sacré responsabilité pour cette équipe sur qui reposait désormais l’avenir de la société. Dans ces conditions, vu le planning serré qu’ils devaient respecter et la pression qui pesait sur leurs épaules, le résultat obtenu par les ingénieurs d’Intel est encore plus remarquable mais cela explique également qu’ils ont du faire des compromis. En particulier l’architecture Conroe, bien que sérieusement remaniée par rapport à celle du Pentium M, trahissait encore par endroits ses racines « mobiles ».

L’architecture n’était notamment pas vraiment modulaire : elle devait couvrir toute la gamme d’Intel, des portables aux serveurs, mais en pratique il s’agissait toujours pratiquement de la même puce, le seul point sur lequel il était possible de jouer était la mémoire cache de second niveau. L’architecture était aussi clairement conçue pour être dual core, le passage à une version quad core reposant sur le même type d’astuce qu’Intel avait utilisé pour ses premiers processeurs dual core : deux dies au sein d’un même package. La présence du FSB était également un frein à la mise au point de configurations utilisant un grand nombre de processeurs, celui-ci constituant un goulot d’étranglement au niveau des accès mémoire. Enfin petit détail qui ne trompe pas, une des nouveautés introduites par l’architecture Conroe (la macro-op fusion qui permettait de fusionner deux instructions x86 en une seule µop) ne fonctionnait pas en mode 64-bit, le mode de fonctionnement standard des serveurs.

Ces compromis étaient compréhensibles il y a deux ans mais aujourd’hui Intel ne peut plus les justifier, surtout face à son rival AMD dont le marché des serveurs reste le dernier point fort. Avec Nehalem Intel avait donc besoin de s’attaquer à ses dernières faiblesses en concevant une architecture modulaire permettant de s’adapter aux besoins différents des trois marchés (mobile, bureau, serveur).

Liens commerciaux
Commentaires
Aimame 25/09/2008 10:59
Masquer
-0+

Et la tu prend un dolipran.

Article très complet qui rejoins bien l'article d'Hardware.fr
Je suis pressé de le voir en fonctionnement ;)

Merci!

Pinkuik 25/09/2008 12:16
Masquer
-2+

Après plus de dix ans à vouloir faire mieux que les autres avec une architecture "innovante", Intel revient aux conclusions des ingénieurs de Digital Equipment Corporation : plutôt amusant...

solistice 25/09/2008 13:12
Masquer
-0+

Aimame :
Et la tu prend un dolipran. Article très complet qui rejoins bien l'article d'Hardware.frJe suis pressé de le voir en fonctionnement Merci!


C'est rare mais personnellement, je suis pressé d'acheter :)

Caabale 25/09/2008 13:15
Masquer
-0+

Citation :on retrouve donc l’instruction POCNT apparue avec le Barcelona qui permet de compter le nombre de bits différent de 0 présents dans un registre.


Grosso merdo, c'est le meme nombre que les bits egaux a 1, quoi :o

Basilic et Pistou 25/09/2008 13:23
Masquer
-0+

En binaire, oui !! :lol:

Foudge 25/09/2008 14:01
Masquer
-1+

"tout d’abord le buffer est désormais plus important puisqu’il peut stocker 28 instructions"

Ce ne sont pas des instructions mais des µops. De plus, est-ce vraiment sûr qu'un buffer de 28 *ops soit plus gros qu'un buffer de 18 instructions ?
Je me doute que ça doit dépendre des instructions, mais en moyenne ça donnerait quoi ?

Zeross 25/09/2008 14:44
Masquer
-0+

Caabale :
Grosso merdo, c'est le meme nombre que les bits egaux a 1, quoi :o



Oui dans le cas du binaire, mais disons que POPCNT est une version un peu spécifique du poids de Hamming qui recherche dans une chaîne, le nombre de symboles différents du 0 de l'alphabet utilisé. Donc j'ai gardé la définition générique ;)

Foudge :
"tout d’abord le buffer est désormais plus important puisqu’il peut stocker 28 instructions"Ce ne sont pas des instructions mais des µops. De plus, est-ce vraiment sûr qu'un buffer de 28 *ops soit plus gros qu'un buffer de 18 instructions ?Je me doute que ça doit dépendre des instructions, mais en moyenne ça donnerait quoi ?



Tout à fait c'est une bonne remarque, je le précise un peu plus loin ("Le Loop Stream Detector du Nehalem ne stocke donc plus des instructions x86, mais des µop.") et je voulais souligner qu'effectivement le gain pratique était plus faible que ce qu'il semblait au premier abord mais c'était difficile à évaluer.

La grosse majorité des instructions x86 ne génèrent qu'une seule µop c'est la raison pour laquelle il y a 3 décodeurs simples qui ne peuvent traiter que ces instructions contre un seul pour les instructions générant de 2 à 4µop. Comme tu le notes le rapport instruction x86 / µop dépend fortement de l'application, la moyenne qui circule est de 1.36 µop générées par instruction x86. Dans ce cas le buffer est en fait à peine plus grand que celui du Core 2 duo (~20.6 instructions). Cependant ces chiffres sont assez anciens et datent du Pentium III, depuis il y a eu pas mal de progrès en la matière que ça soit au niveau des instructions SSE qui génèrent moins de µops, ou de la fusion (micro et macro) donc le rapport a du baisser. Je pense qu'on peut considérer que ce buffer est l'équivalent d'un buffer x86 de 22 instructions à la louche mais c'est qu'une grossière estimation.

Foudge 25/09/2008 15:14
Masquer
-0+

Et vue qu'en plus on évite l'étape de décodage, c'est effectivement tout benef :)

Wiiip 25/09/2008 18:25
Masquer
-0+

Moi, ça me rappelle le P4 cette histoire ...
Plus de puissance, plus de puissance, plus de puissance ... Au détriment de la vitesse.
Désolé

Ce sujet ne peut plus être commenté.
Liens commerciaux
Publicité

Les offres du moment

Tout sur les Processeurs
 Derniers articles sur les Processeurs
Tous les articles Processeurs

Newsletters


  • Besoin d'aide ? Publiez votre question
  • Publier