Intel Core i7 (Nehalem) : une architecture signée AMD ?
Sommaire
- 1 – Introduction
- 2 – Nehalem, une vue d’ensemble
- 3 – Lecture & décodage des instructions
- 4 – Prédicteurs de branchement
- 5 – Le retour de l’HyperThreading
- 6 – Implémentation du SMT (suite)
- 7 – SSE 4.2, consommation
- 8 – QuickPath Interconnect
- 9 – Sous système mémoire
- 10 – Une hiérarchie de cache à 3 niveaux
- 11 – TLB
- 12 – Accès mémoires, prefetchers
- 13 – Conclusion
- 14 – Plus de contenu sur ce sujet
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).
- Choix entre core i7 920 et core i7 860 [Matériel]
- Un Nehalem six cores cette année ? [Les news : vos réactions]
- Le prix des Core i5/i7 Lynnfield [Les news : vos réactions]
- [Mailing hebdo] 14 septembre 2009 - Le Core i va enfin avoir du succès [Le Bistrot]
- Grosse config en vue...besoin d'aide [Matériel]
Posez votre question sur ce sujet à la communauté !
Sujets relatifs sur le forum
Les offres du moment
- SIEMENS INDUSTRY - MOBILITY - INGÉNIEUR SYSTÈME POSTE DE COMMANDE CENTRALISÉE (H/F)
- SIEMENS INDUSTRY - MOBILITY - INGENIEUR INTEGRATION ET VALIDATION LOGICIEL POUR LES EQUIPEMENTS VIDEO PHONIE (H/F)
- SIEMENS INDUSTRY - MOBILITY - CHEF DE PROJET INFORMATIQUE (H/F)
- SIEMENS IT SOLUTIONS & SERVICES - CONTRÔLEUR DE GESTION / GESTIONNAIRE DE PROJET (H/F)
- SIEMENS HEALTHCARE - WORKFLOW & SOLUTIONS - INGENIEUR DEVELOPPEMENT FRAMEWORK MUMPS (H/F)
- playstation 4
- comment utiliser utorrent
- test ordinateur portable
- flyff serveur prive
- demonter pc portable
- wacom intuos 4
- windows 32 64 bits
- xp mode
- batterie portable
- intel atom z520
- serveur hotmail
- firefox 64 bits
- intel atom n270
- performance carte graphique
- augmenter vitesse vuze
- intel atom 230
- pinetrail
- nvidia gt 220 performance
- i5 i7
- taille tableau php

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!
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...
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
Grosso merdo, c'est le meme nombre que les bits egaux a 1, quoi
En binaire, oui !!
"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 ?
Grosso merdo, c'est le meme nombre que les bits egaux a 1, quoi
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
"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.
Et vue qu'en plus on évite l'étape de décodage, c'est effectivement tout benef
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é