Intel Core 2 Duo

Les unités de calcul

Voici une rapide comparaison des unités de calcul des architectures actuelles :


... et les bandes passantes théoriques en instructions qui en découlent :


Core possède trois unités de calcul sur les entiers, soit une de plus que Mobile, le plaçant ainsi au niveau du K8 avec une capacité de trois instructions x86 par cycle. A noter que Netburst conserve sa suprématie en capacité de traitement des entiers avec ses unités double vitesse qui lui permettent de traiter jusqu’à 4 instructions entières par cycle (et non pas 5 comme le laisserait supposer la présence d’une ALU supplémentaire en simple vitesse, car celle-ci partage son port avec une des deux ALUs double vitesse). Hélas, cette capacité de traitement n’est pas exploitable en pratique car les unités de décodage de Netburst ne permettent pas de fournir un tel débit, limitant ainsi l’IPC à 3.

Il nous a semblé intéressant d’étudier le comportement de Core sur des instructions courantes x86 telles qu’opérations arithmétiques, décalages, rotations... Nous avons pour cela utilisé un outil intégré à Everest  qui fournit latence et débit de quelques instructions choisies parmi x86/x87, MMX, SSE 1, 2 et 3. Ce petit outil est présent dans la version d’évaluation : il suffit de cliquer droit dans la barre d’état d’Everest, et sélectionner « CPU Debug » puis « Instructions latency dump » dans le menu qui apparaît.

A titre de rappel, la latence d’une instruction représente, en nombre de cycles processeur, le temps qu’elle passe dans le pipeline de traitement. En pratique, le moteur OOO s’efforce de traiter le flux d’instructions de telle façon que ces latences soient masquées, mais les dépendances entre instructions tendent à générer des attentes, d’autant plus importantes que les latences de ces instructions le sont. Le débit d’une instruction correspond au temps minimal, en cycles processeur, séparant la prise en charge de deux instructions similaires. Ainsi, par exemple, la division entière possède un débit de 40 cycles sur K8, ce qui signifie que le processeur ne pourra traiter, et donc fournir le résultat d’un telle division entière qu’à raison d’une tous les 40 cycles.


Sur certaines instructions, dont l’addition, Core affiche un débit correspondant à son IPC maximal théorique (0,33 cycle par instruction, soit 3 instructions par cycle). La multiplication affiche une latence légèrement inférieure à celle obtenue sur le Yonah, et se place ainsi au niveau du K8. La division entière a subi en revanche une légère baisse de performance, quoiqu’elle reste beaucoup plus rapide que sur K8 et Netburst. En ce qui concerne les manipulations de registres, Core reste en dessous de K8, bien que le décalage (shl) ait été amélioré en comparaison au Yonah.

Ce qu’il faut retenir de ce tableau est que les efforts sur les unités de Core semblent avoir été portés sur les instructions pour lesquelles le K8 possédait jusque là une certaine avance sur Mobile et Netburst (addition et multiplication entières par exemple), alors qu’un peu de lest a été lâché sur les instructions pour lesquelles K8 ne brille pas (la division entière).

Performances SSE théoriques

Une des améliorations les plus notables des unités de calcul de Core consiste en la présence de trois unités SSE dédiées aux opérations SIMD entières et flottantes. Alliée aux unités arithmétiques concernées, chacune d’elles est capable d’effectuer en un seul cycle des opérations paquées 128 bits (c’est-à-dire agissant simultanément sur quatre données 32 bits ou deux données 64 bits), là où Netburst, Mobile et K8 nécessitent deux cycles. Sont concernées notamment les opérations arithmétiques courantes telles que la multiplication et l’addition.


Chacune des trois ALUs est associée à une unité SSE, permettant ainsi de traiter jusqu’à trois opérations SSE entières 128 bits par cycle (soit 12 instructions sur des entiers 32 bits, ou encore 24 sur des entiers 16 bits). En comparaison, Mobile et K8 ne possèdent que deux unités SSE, et celles-ci ne peuvent traiter que 64 bits par cycle d’horloge. La capacité de Mobile et de K8 en SSE entier n’est donc que de 2 x 64 bits, soit 4 instructions sur des entiers 32 bits (ou encore 8 instructions sur des entiers 16 bits).

Core possède deux unités de calcul flottant, une dédié aux additions et l’autre aux multiplications et aux divisions. La capacité de calcul théorique atteint donc deux instructions x87 par cycle, et deux instructions flottantes SSE 128 bits par cycle (soit 8 opérations sur des flottants simple précision 32 bits, ou 4 opérations sur flottants double précision 64 bits). Core se montre ainsi en théorie deux fois plus rapide sur ce type d’instructions que Mobile, Netburst et K8. Voyons cela sur quelques instructions SSE2.


Le packed mov se montre particulièrement véloce sur Core, qui atteint là son pic de débit de 3 opérations 128 bits par cycle. Les débits affichés sur les opérations arithmétiques isolées s’expliquent par la prise en charge de ces opérations par une seule des unités FP, qui utilisée seule offre son débit maximal d’une opération 128 bits par cycle. L’opération combinée mul + add exploite en revanche les deux unités conjointement, et s’exécute alors avec un débit de 1 cycle pour les deux opérations, soit deux opérations 128 bits par cycle.

Intel communique beaucoup sur cette nouvelle capacité de calcul introduite par Core, et la désigne sous le terme de Digital Media Boost. On notera au passage que Core introduit une nouvelle extension du jeu d’instructions SSE. Initialement prévue pour sortir sur le Tejas, SSE4 consiste en 16 nouvelles instructions SIMD, la plupart opérant sur des données entières. Elles sont essentiellement destinées à accélérer le traitement dans les algorithmes de compression et de décompression vidéo. A titre d’exemple, l’instruction palignr permet d’effectuer un décalage à cheval sur deux registres, opération qui est souvent utilisée dans l’algorithme de prédiction de mouvement dans le décodage MPEG.

Les capacités des unités d’exécution de Core sont pour le moins impressionnantes. Intel a doté sa nouvelle architecture d’un potentiel de calcul entre deux et trois fois supérieur à celle de ses prédécesseurs et de la concurrence. Mais posséder un IPC élevé sur le papier est une chose, et l’exploiter en pratique en est une autre. Comme nous l’avons vu un peu plus haut, un code x86 tend à faire chuter l’IPC par les branches et des accès mémoire. Intel a ainsi logiquement apporté quelques améliorations destinées à réduire les effets néfastes de ces deux types de dépendances.