Et voilà, le Prescott est officiellement sorti et on a le droit de dire à présent tous les petits secrets d'Intel ;). Je vais donc reprendre l'analyse du microprocesseur Prescott et vous allez voir que ça va un peu plus loin que ce que vous avez pu lire dans certains articles sur le Prescott.

Bonne lecture

En théorie l'augmentation de la taille du pipeline ralentit l'exécution des programmes. Pas toutes les parties d'un programme mais celles qui comportent des tests ou conditions de branchement. Dans la pratique aussi, mais d'autres facteurs influent et peuvent compenser en partie les pertes dues à l'allongement du pipeline. C'est le cas de la prédiction de branchement. Et il faut dire qu'Intel a soigné la prédiction de branchement du Prescott.

Bon tout ça ne vous dit pas grand chose, alors voici un peu d'histoire et quelques explications. La prédiction de branchement est une optimisation interne des microprocesseurs. Avant cette optimisation, quand un microprocesseur rencontrait une instruction de test, il attendait le résultat du test. Une fois le test connu il exécutait telle ou telle partie du programme. La prédiction de branchement a pour but de permettre au microprocesseur de prédire quel sera le résultat du test et d'exécuter sans attendre son résultat la partie de programme correspondant à sa prédiction. Ca n'a l'air de rien expliqué comme ça, mais ça permet de produire une belle accélération. Ce qu'il y a de comique dans cette optimisation c'est que si la prédiction est mauvaise, le microprocesseur doit revenir en arrière. Dans la pratique cela signifie retirer toutes les instructions en cours de traitement dans le pipeline. La taille du pipeline est le talon d'achille de la prédiction de branchement.

En fait il faut savoir que les microprocesseurs de nouvelle génération comme l'Athlon-64 ou le Prescott ont une très bonne prédiction de branchement et la taille du pipeline n'influe que peu sur les performances dans bon nombre de programmes. Alors d'où viennent les mauvaises performances du Prescott ? Des mémoires caches ! C'est ce que nous allons voir dans le prochain chapitre.

A propos certains ont pu s'étonner que j'ai classé le Prescott comme microprocesseur de nouvelle génération. Comme je tenterais de l'expliquer tout au long de cet article le Prescott intègre de nouvelles technologies et/ou optimisations technologiques qui sont la signature de la nouvelle génération de microprocesseur d'Intel. Certaines comme la prédiction de branchement sont déjà activées, d'autres pas encore, mais pour la majorité elles sont déjà bien présentes dans ce microprocesseur.

En fait la plupart des problèmes de performances du Prescott, comme vous avez pu le lire dans de nombreux benchmark parus récemment, proviennent de la lenteur de ses mémoires caches. Nous avons d'ailleurs travaillé avec le site X86-secret sur ce problème en utilisant des programmes de test de performances de fonctions d'une future bibliothèque mathématique de grands nombres, bibliothèque qui fera l'objet de plusieurs articles durant l'année 2004. Revenons à nos moutons. Nous avons beaucoup de questions à nous poser sur les mémoires caches du Prescott et les raisons de leur lenteur.

Pourquoi les mémoires caches du Prescott sont-elles si lentes ?
En premier on constate que les latences des mémoires caches sont bien plus importantes pour un Prescott que pour un Northwood. Pour le cache L1 : 2 cycles contre 4 pour le Prescott et pour le cache L2 : 18 cycles contre 29 (note : dans cet article à chaque fois que je mentionnerais le cache L1 il s'agira du cache L1 des données). Deux raisons peuvent imposer une augmentation de la latence d'une mémoire cache. La première concerne la taille du cache. Effectivement, il faut un certain nombre de cycles pour que le signal se propage dans une mémoire cache. Plus elle est grande (= plus il y a de transistors) plus ce signal mettra un certain temps à la parcourir. Le cache L1 du Prescott a doublé, mais de là à faire doubler sa latence il y a quelque chose qui ne colle pas. Si on regarde du côté de l'Athlon, celui-ci a un cache L1 de 64 Ko soit 4 fois plus gros que celui du Prescott mais seulement une latence de 3 cycles ! La seconde raison concerne l'intégrité du signal. En gros si ça va trop vite il y a des risques d'erreur du cache et cette intégrité est d'autant plus mise à mal que la fréquence est élevée. Donc augmenter la fréquence d'une architecture implique souvent de revoir à la baisse les latences des caches. Mais à nouveau quelque chose cloche. Les fréquences du Prescott sont très proches de celles du Northwood. Même à 4 GHz le Prescott n'aura pas une fréquence de plus de 20% plus élevé qu'un Northwood 3,4 GHz.

Si on assemble les deux explications (taille et fréquence) pour voir si l'augmentation de latence est dans des proportions cohérentes, on peut se dire que pour le cache L2 à la limite cela peut aller. Mais pour le cache L1 une latence de 3 aurait suffi apparemment pour le Prescott. Alors pourquoi des latences si élevées ? En fait tant les latences du cache L1 que L2 sont surdimensionnées. Il y a des raisons à cela. Tant pour le cache L1 et que pour le L2, ceux-ci ont leur latence dimensionnée aux futures fréquences du Tejas, le successeur du Prescott, à savoir 4,8 / 5 GHz. De plus le cache L1 du Tejas sera de 24 Ko contre 16 Ko pour le Prescott (8 Ko pour le Northwood).

Apparemment nous avons là toutes les explications nécessaires et elles se résument par le fait que les latences des caches du Prescott sont alignées sur le futur Tejas. Quoique nous verrons dans le chapitre sur le SSE que ce n'est pas aussi simple. A la question pourquoi avoir adopté des latences aussi élevées dès le Prescott alors que celui-ci pourrait fonctionner avec des latences plus faibles, la réponse se trouve dans la méthodologie de travail des fabricants de processeurs. En gros ils conçoivent une architecture pour leur haut de gamme, puis désactivent des parties pour leur moyen et bas de gamme. Le Prescott est d'une certaine manière le bas de gamme du Tejas, ou plus exactement un Tejas embryonnaire.

Le Prescott actuel n'est pas des plus séduisants, pourtant les marchés ont une telle confiance en Intel qu'il n'y a pas de doute, ce microprocesseur se vendra sans difficulté. En même temps je ne peux m'empêcher de penser que les faibles performances du Prescott dues en grande partie à ses mémoires caches, n'est pas pour déplaire dans l'immédiat à Intel. Effectivement, l'avenir du Prescott puis du Tejas ne passe pas par des cartes graphiques AGP, ni des bus PCI, ni de la mémoire DDR-SDRAM, mais par le PCI-express, la DDR2-SDRAM, et même un nouveau format de boitier et de carte-mère, sans compter le socle de fixation du microprocesseur sur la carte-mère. Pour imposer ces choix un Prescott plus séduisant pourrait pousser plus de gens et plus rapidement à changer quasiment tout leur matériel. Matériel dans lequel Intel a beaucoup investi directement comme le PCI-express (même s'il s'agit d'un consortium, Intel en est le fer de lance) ou indirectement comme les mémoires DDR2 (pour un fabricant de mémoire savoir qu'Intel fera la promotion d'une nouvelle génération de mémoire ça aide à s'investir dans la recherche et la production de masse).

Il faut bien comprendre qu'en 2004 il y aura deux Prescott. L'actuel, compatible avec les cartes-mères les plus récentes et le futur compatible uniquement avec des cartes-mères non encore commercialisées mais qui disposeront de nouvelles technologies. Il serait bon pour Intel que ce futur Prescott soit un peu plus véloce à fréquence égale. Bien sûr, cela n'est qu'une hypothèse, mais même si elle s'avère fausse il faudra regarder de très près les futures versions du Prescott pour savoir si Intel ne nous aurait pas joué un tour à sa façon ;).

Le prefetching c'est l'art et la manière de précharger les données dont aura besoin un programme avant qu'il en ait réellement besoin. L'intérêt est que cela assure au microprocesseur de pouvoir toujours compter sur des données situées en cache et non en mémoire au moment où il en a besoin. Il existe deux types de prefetching. Le prefetching hardware, dans ce cas c'est le microprocesseur, qui à l'aide d'algorithmes internes, détermine les données à prefetcher. Le prefetching logiciel dans ce cas ce sont des instructions du programme qui indiquent au microprocesseur quand et quelles données prefetcher.

Force est de constater que le prefetching hardware a fait un bond dans sa capacité à déterminer ce qui doit être prefetcher de même que la manière de le faire. Cette dernière n'étant pas étrangère à l'augmentation du nombre de buffers permettant de faire des lectures / écritures en rafale.

Pour le prefetching logiciel, je vous renvoie au chapitre SSE.

D'un point de vue pratique dès que le microprocesseur recontrera des lectures ou écritures séquentielles, le Prescott récupère une bonne partie des pertes de performances et peut même mettre la pâté au Northwood s'il n'y a que de la lecture séquentielle. Toutefois en moyenne ce gain reste modeste car peu de programmes ou parties de programme font des accès séquentiels permanents et / ou importants.

C'est une optimisation qui n'était pas attendue, mais qui dans tout les cas montre que certaines optimisations qu'intègre le Prescott sont très bonnes.

SSE3 n'est pas une nouvelle unité de calcul comme le sont le SSE pour les entiers vectoriels, et SSE2 pour les flottants vectoriels. Sous le terme de SSE3, Intel regroupe des instructions qui complètent SSE et SSE2 de même que les fonctions multitâches pour l'hyper-threading. Le but de ces instructions est de permettre aux programmes de faire la même chose mais plus vite. Ce sont d'une certaine manière des optimisations.

En ce qui concerne l'hyper-threading, le SSE3, par le biais des instructions Monitor et Mwait, permet de diminuer la perte de temps générée lors de synchronisation de thread. Evidemment il faudra attendre que les programmes les utilisent pour pouvoir en bénéficier, mais comme la gestion des threads est confiée au système d'exploitation, il suffira d'attendre une mise à jour de Linux ou de Windows XP pour en bénéficier. L'hyper-threading du Prescott étant déjà plus rapide que celui du Northwood, on assistera donc à un gain supplémentaire de quelques pourcents dans son efficacité.

Pour les instructions vectorielles, certaines améliorations permettront d'accélérer les programmes surtout ceux destinés à faire de l'encodage vidéo, et du traitement d'image et de son. Mais ce n'est pas tout. J'ai réalisé un programme qui simule l'addition, mais qui est entièrement vectorisé par le compilateur Intel. J'ai produit une version optimisée SSE2 pour le Northwood et SSE3 pour le Prescott et j'ai eu deux surprises :

Temps en milliseconde

La première est qu'un programme vectorisé est nettement moins sujet au problème de cache du Prescott. 10% de perte contre 20% si on n'utilise que des instructions de l'ALU. La seconde c'est qu'en optimisant pour le Prescott le compilateur a fourni un code plus rapide. Il y a donc bien un gain à attendre pour le Prescott de l'utilisation du SSE3.

Mais tout n'est pas rose avec les instructions multimédias. Ainsi si les instructions sur les entiers sont aussi rapides sur le Prescott que sur le Northwood, il n'en va pas de même pour les instructions SSE2 qui pour la grande majorité voient leur temps d'exécution augmenter de 10% à 20%.

Le Prescott n'est pas une bête de compétition comme vous avez pu vous en rendre compte. Ses performances brutes laissent à désirer avec une perte moyenne de 5% comparé à un Northwood à fréquence égale. Maintenant ce que ne testent pas les sites internet c'est l'agrément d'utilisation. Or dans cette situation le Prescott devrait s'avérer supérieur. Je dis devrait car à Onversity on n'a aucun contact pour nous fournir du matériel je n'ai pu faire des tests que par l'intermédiaire du webmaster de X86. Toutefois quand je l'ai interrogé sur la réactivité de Windows sur une machine équipée d'un Prescott, il a estimé qu'elle était supérieure à celle du Northwood.

En fait je m'en doutais à cause de l'aspect théorique et cela a deux origines. La première concerne le surplus de cache. Le fait d'avoir plus de cache surtout pour le cache L2 permet au système d'exploitation de disposer plus rapidement de données nécessaires à sa gestion : gestion NTFS, base de registre, ... La deuxième est en rapport direct avec les améliorations internes de l'hyper-threading. Il faut bien se rendre compte qu'aujourd'hui quand vous allumez votre PC de nombreuses tâches se chargent en mémoire, certaines restant inactives tant qu'on n'a pas besoin d'elles (impression par exemple), d'autres par contre fonctionnent quasi en permanence et cela est d'autant plus vrai pour les gens qui naviguent sur internet et qui ont un firewall et un antivirus permament. Il y a un dernier aspect, mais cela nécessitera une confirmation. Le temps de chargement des logiciels devrait être légèrement plus court à cause des améliorations de prefetching hardware surtout si ceux-ci se trouvent déjà en mémoire cache du système d'exploitation.

En résumé d'un point de vue utilisation courante et surtout si votre manière d'utiliser le PC implique que plusieurs programmes importants travaillent de concert, le Prescott risque d'en surprendre plus d'un. Evidemment à 2,8 GHz, le Prescott n'est pas le nec plus ultra, mais à partir de 3,6 GHz il commencera à livrer la puissance qu'il recèle. En fait plus il montera en fréquence et mieux ça sera. C'est ce que nous allons voir dans le prochain chapitre.

Bon, il est clair que plus un microprocesseur a une fréquence élevée plus il est rapide, pour une même famille de microprocesseur s'entend. Par contre vous avez pu lire ici ou là des comparatifs de performances entre le Northwood et le Prescott à différentes fréquences. Et ces comparatifs mettent tous en avant que le Prescott voit mieux ses performances croître avec une augmentation de fréquence qu'un Northwood. Autrement dit, si le Prescott est plus lent de 5% que le Northwood pour une application donnée à 2,8 GHz, à 4 GHz (en supposant qu'on dipose d'un Northwood à 4 GHz) la différence serait plutôt de l'ordre de 1 à 2%. Pourquoi ?

C'est essentiellement la taille du cache L2 qui est responsable de cela. Comment ? Il faut bien comprendre qu'en général un programme ne peut compter en permanence sur le fait que ces données seront dans le cache L2. En augmentant la taille du cache la probabilité qu'elles y soient augmente. En même temps, augmenter la fréquence du microprocesseur fait que la différence de vitesse de traitemeent entre les données situées en mémoire cache et en mémoire RAM augmente. De fait plus un microprocesseur dispose d'un gros cache L2 et moins sa montée en fréquence influera sur la différence de performances entre la mémoire cache et la mémoire RAM. Il est bien entendu que l'on considère que la mémoire RAM n'augmente pas aussi en performances. Si c'est le cas alors le problème est tout autre.

Optimisations

• Augmentation de la taille des caches
• Performances de l'hyper-threading
• Amélioration du prefetching
• Prédiction de branchement améliorée
• Ajout de nouvelles instructions pour l'hyper-threading et les applications multimédias

Pourquoi parler déjà du Tejas ? Parcecque le Prescott préfigure ce que sera le Tejas. Mais ce dernier aura au moins deux avantages. Son cache L1 sera plus gros, passant de 16 Ko à 24 Ko, et sa fréquence de fonctionnement sera plus élevée.

La grosse interrogation concerne la présence ou non d'instructions 64 bits. Comme je l'ai dit dans plusieurs mini-articles, Intel ne peut plus se permettre de laisser AMD faire cavalier seul sur le 64 bits grand public, d'autant plus que la sortie de Windows XP 64 bits approche à grand pas. En fait la situation est pire que ça pour Intel. Windows XP 64 bits sera très souple d'adaptation quant aux applications c'est-à-dire qu'elles pourront être 64 bits évidemment mais aussi 32 bits (sûr). On peut même dans ce cas envisager que s'il accepte de fonctionner avec des applications 32 bits, qu'il puisse aussi fonctionner avec des microprocesseurs 32 bits (à vérifier). Intel est aussi dans une très mauvaise situation à cause de l'Itanium : processeur 64 bits haut de gamme. Si Intel sort un Tejas 64 bits ils devront aussi sortir un Xeon 64 bits et là ils se trouveront en situation de se concurrencer eux-mêmes ! Honêtement qui s'imagine que durant 2004 et 2005 Intel laisse AMD proposer le seul microprocesseur 64 bits pour Windows XP 64 bits ? Personne. Intel se doit de proposer une solution dès 2005 et cette solution passera par le Tejas.

Une autre question reste en suspend. Le 64 bits d'Intel sera-t-il compatible avec celui d'AMD ? Plusieurs cas se présentent. S'ils sont incompatibles, est-ce que Windows 64 bits pourrait servir d'interface pour que les programmes développés pour AMD et Intel puissent fonctionner de manière transparente à ces incompatibilités ? Pas sûr, mais faisable, puisque le morphing de code à la reconnaissance du microprocesseur existe déjà, c'est-à-dire que Windows 64 bits adapte son code en fonction du microprocesseur utilisé au moment de l'installation. Etre compatible instruction par instruction est une chose, mais AMD a introduit une amélioration et celle-ci concerne l'augmentation du nombre de registres programmables. Il serait souhaitable qu'Intel dispose de la même amélioration.

Concernant le pipeline du Tejas et des latences de ses mémoires caches je pense que dans sa version 0,09 micron de fabrication le Tejas aura les mêmes caractéristiques que le Prescott ou en sera très proche.

Comme l'a été le pentium 4 Willamette en son temps, le Prescott est un drôle de microprocesseur. Il intègre des optimisations d'architecture que beaucoup de constructeurs envient à mon avis, mais en même temps Intel est rongé par son obsession des hautes fréquences. Obsession qui coûte cher car en moyenne le Prescott est plus lent à fréquence égale qu'un Northwood et acheter un Prescott en-dessous de 3.4 GHz est une erreur. En fait hormis les fréquences et malgré des idées de conception intéressantes, l'architecture Netburst est un échec. Comme risque de l'être d'ailleurs l'architecture Epic des Itanium si comme tout le monde s'y attend un Tejas 64 bits grand public voit le jour en 2005. Pour couronner le tout on a appris qu'Intel a demandé à IBM une licence d'utilisation de sa technologie de fabrication SOI. Mais IBM est parti en guerre contre Intel et leur a proposé de telles conditions qu'Intel devrait être vraiment au pied du mur pour accepter. Mais ne le sont-ils pas déjà quand on voit les températures de fonctionnement d'un Prescott à 3,2 GHz ?

Mais que reste-t-il à Intel ? Le Pentium-M bien sûr. Ne trouvez-vous pas bizarre qu'Intel propose deux microprocesseurs totalement différents pour les portables ? Le premier cap que devra passer Intel est le 64 bits grand public, et cela se fera avec le Tejas, mais juste après il y a le cap des microprocesseurs multicore. L'architecture Netburst n'est pas adaptée à cela, trop grosse, trop gourmande en courant. Par contre le core du Pentium-M serait parfaitement adapté à cet exercice. En fait l'architecture multicore est une aubaine pour Intel car elle lui offre une porte de sortie honorable à son obsession des hautes fréquences.

Ainsi s'achève mes quelques réflexions sur le Prescott et l'architecture Netburst. Certaines de ces réflexions s'avèreront justes d'autres non, mais que rien ne vous empêche d'en discuter :).