Pourquoi le processeur Itanium a-t-il été difficile d'écrire un compilateur?
Il est communément dit que l'architecture du processeur Itanium 64 bits d'Intel a échoué parce que le révolutionnaire jeu d'instructions EPIC était très difficile à écrire pour un bon compilateur, ce qui signifiait un manque de bons outils de développement pour IA64, ce qui signifiait un manque de développeurs créant des programmes pour l'architecture, et donc personne ne voulait utiliser du matériel sans trop de logiciels pour cela, et donc la plate-forme a échoué, et tout cela à cause de un clou en fer à cheval bons compilateurs.
Mais pourquoi le compilateur était-il un problème technique si difficile? Il me semble que si le parallélisme explicite dans EPIC était difficile à implémenter pour les éditeurs de compilateurs ... pourquoi leur imposer ce fardeau en premier lieu? Ce n'est pas comme si une bonne solution bien comprise à ce problème n'existait pas déjà: placez ce fardeau sur Intel à la place et donnez aux rédacteurs du compilateur une cible plus simple.
Itanium est sorti en 1997. À ce stade, le système de bytecode CSD P-Code avait près de 20 ans, la machine Z juste un peu plus jeune, et la JVM était la nouvelle étoile montante chaude dans le monde des langages de programmation. Y a-t-il une raison pour laquelle Intel n'a pas spécifié de langage de "simple bytecode Itanium" et a fourni un outil qui convertit ce bytecode en code EPIC optimisé, tirant parti de leur expertise en tant que personnes qui ont conçu le système en premier lieu?
Si je me souviens bien à l'époque, le problème n'était pas seulement les détails de IA64, c'était la concurrence avec le jeu d'instructions x86-64 d'AMD. En rendant leur architecture rétrocompatible avec le jeu d'instructions x86, AMD a pu tirer parti des outils existants et des compétences des développeurs. Le déménagement d'AMD a été un tel succès qu'Intel (et Via) ont été essentiellement contraints d'adopter l'architecture x86-64.
La grande barrière à l'époque était de 4 Go RAM sur les ordinateurs de bureau (plus réaliste ~ 3,4 Go utilisables sous Windows). X86-64 a brisé cette barrière et ouvert l'informatique plus puissante à tout le monde. Avait AMD jamais proposé x86-64, je suis sûr qu'Intel aurait été heureux d'avoir tous ceux qui voulaient passer à 4 Go + RAM payer une lourde prime pendant des années pour ce privilège. Démontrer la lenteur des marchés déplacer, il a fallu des années pour que les applications rattrapent jusqu'à 64 bits, la programmation multi-thread, et même maintenant 4 Go RAM est standard sur les PC bas de gamme.
En bref, Intel a tenté de faire un saut révolutionnaire avec l'architecture IA64, et AMD a fait un pas évolutif avec x86-64. Dans un marché établi, les étapes évolutives qui permettent aux travailleurs du savoir de tirer parti des compétences existantes l'emporteront sur les étapes révolutionnaires qui exigent que chacun acquière de nouvelles compétences. Quelles que soient les différences qualitatives entre les architectures, IA64 n'a pas pu surmonter l'élan de sa propre plate-forme x86 une fois qu'AMD a ajouté les extensions x86-64.
Je n'achète pas l'explication selon laquelle IA64 était trop difficile à programmer. Cela n'a été difficile que par rapport aux alternatives. Le point de @ delnan sur l'IR de bas niveau est clair, je ne pense pas que cela aurait fait une différence.
Quant à savoir pourquoi Intel n'a pas essayé d'assumer ce fardeau lui-même, qui sait? Ils étaient le pouvoir du marché à l'époque. AMD était une menace, mais Intel était le roi de la colline. Peut-être pensaient-ils que l'IA64 serait tellement mieux qu'autre chose qu'ils pourraient déplacer l'ensemble du marché. Peut-être qu'ils essayaient de créer un niveau premium et de laisser AMD, VIA, etc. dans le deuxième niveau se battre contre le matériel de base à faible marge - une stratégie qu'Intel et Apple ont utilisé avec succès).
Itanium était-il une tentative délibérée de créer une plate-forme premium et de retirer le tapis de sous AMD, VIA, etc.? Bien sûr, c'est ainsi que les affaires fonctionnent.
Le article Wikipedia sur EPIC a déjà décrit les nombreux dangers communs à VLIW et EPIC.
Si quelqu'un n'attrape pas le sens du fatalisme de cet article, permettez-moi de souligner ceci:
Les réponses de charge d'une hiérarchie de mémoire qui inclut des caches CPU et DRAM n'ont pas de délai déterministe.
En d'autres termes, toute conception matérielle qui ne parvient pas à faire face (*) à la latence non déterministe de l'accès à la mémoire deviendra un échec spectaculaire.
(*) Par "faire face à", il est nécessaire d'atteindre des performances d'exécution raisonnablement bonnes (en d'autres termes, "compétitives en termes de coûts"), ce qui nécessite de ne pas laisser le CPU tomber inactif pendant des dizaines à des centaines de cycles très souvent.
Notez que la stratégie d'adaptation employée par EPIC (mentionnée dans l'article Wikipedia lié ci-dessus) ne résout pas réellement le problème. Il indique simplement que la charge d'indiquer la dépendance des données incombe désormais au compilateur. C'est très bien; le compilateur possède déjà ces informations, il est donc simple pour le compilateur de se conformer. Le problème est que le CPU va toujours rester inactif pendant des dizaines à des centaines de cycles sur un accès mémoire. En d'autres termes, il externalise une responsabilité secondaire, sans pour autant faire face à la responsabilité principale.
La question peut être reformulée comme suit: "Étant donné une plate-forme matérielle destinée à être un échec, pourquoi (1) n'a pas (2) les rédacteurs du compilateur ne pouvaient-ils pas faire un effort héroïque pour la racheter?"
J'espère que ma reformulation rendra la réponse à cette question évidente.
Il y a un deuxième aspect de l'échec qui est également fatal.
Les stratégies d'adaptation (mentionnées dans le même article) supposent que la prélecture basée sur logiciel peut être utilisée pour récupérer au moins une partie de la perte de performances due à une latence non déterministe de l'accès à la mémoire.
En réalité, la prélecture n'est rentable que si vous effectuez des opérations de streaming (lecture de la mémoire de manière séquentielle ou hautement prévisible).
(Cela dit, si votre code permet un accès fréquent à certaines zones de mémoire localisées, la mise en cache vous aidera.)
Cependant, la plupart des logiciels à usage général doivent effectuer de nombreux accès aléatoires à la mémoire. Si nous considérons les étapes suivantes:
- Calculez l'adresse, puis
- Lisez la valeur, puis
- Utilisez-le dans certains calculs
Pour la plupart des logiciels à usage général, ces trois doivent être exécutés en succession rapide. En d'autres termes, il n'est pas toujours possible (dans les limites de la logique logicielle) de calculer l'adresse à l'avance, ou de trouver suffisamment de travail à faire pour combler les blocages entre ces trois étapes.
Pour expliquer pourquoi il n'est pas toujours possible de trouver suffisamment de travail pour remplir les stalles, voici comment on pourrait le visualiser.
- Disons que pour masquer efficacement les décrochages, nous devons remplir 100 instructions qui ne dépendent pas de la mémoire (donc ne souffriront pas de latence supplémentaire).
- Maintenant, en tant que programmeur, veuillez charger tout logiciel de votre choix dans un désassembleur. Choisissez une fonction aléatoire pour l'analyse.
- Pouvez-vous identifier n'importe où une séquence de 100 instructions (*) qui sont exclusivement libres d'accès à la mémoire?
(*) Si nous pouvions faire en sorte que NOP fasse un travail utile ...
Les processeurs modernes essaient de faire face à la même chose en utilisant des informations dynamiques - en suivant simultanément la progression de chaque instruction lors de leur circulation dans les pipelines. Comme je l'ai mentionné ci-dessus, une partie de ces informations dynamiques est due à une latence de mémoire non déterministe, par conséquent, elles ne peuvent être prédites à aucun degré de précision par les compilateurs. En général, il n'y a tout simplement pas assez d'informations disponibles au moment de la compilation pour prendre des décisions qui pourraient éventuellement combler ces blocages.
En réponse à la réponse d'AProgrammer
Ce n'est pas que "le compilateur ... extraire le parallélisme est difficile".
La réorganisation de la mémoire et des instructions arithmétiques par les compilateurs modernes prouve qu'il n'a aucun problème à identifier les opérations qui sont indépendamment et donc exécutables simultanément.
Le problème principal est que la latence de la mémoire non déterministe signifie que tout "appariement d'instructions" codé pour le processeur VLIW/EPIC finira par être bloqué par l'accès à la mémoire.
L'optimisation des instructions qui ne bloquent pas (registre uniquement, arithmétique) ne résoudra pas les problèmes de performances causés par les instructions qui risquent de se bloquer (accès à la mémoire).
C'est un exemple d'échec de l'application de la règle d'optimisation 80-20: l'optimisation de choses qui sont déjà rapides n'améliorera pas significativement les performances globales, à moins que les choses plus lentes soient également optimisées.
En réponse à la réponse de Basile Starynkevitch
Ce n'est pas "... (quoi que) soit difficile", c'est que l'EPIC ne convient pas à toute plate-forme qui doit faire face à un fort dynamisme en latence.
Par exemple, si un processeur possède tous les éléments suivants:
- Pas d'accès direct à la mémoire;
- Tout accès à la mémoire (lecture ou écriture) doit être planifié par DMA transfer;
- Chaque instruction a la même latence d'exécution;
- Exécution dans l'ordre;
- Unités d'exécution larges/vectorisées;
Alors VLIW/EPIC sera un bon ajustement.
Où trouve-t-on de tels processeurs? DSP. Et c'est là que VLIW a prospéré.
Rétrospectivement, l'échec d'Itanium (et la poursuite de l'effort de R&D dans un échec, malgré des preuves évidentes) est un exemple d'échec organisationnel et mérite d'être étudié en profondeur.
Certes, les autres projets du fournisseur, tels que l'hyperthreading, le SIMD, etc., semblent remporter un grand succès. Il est possible que l'investissement dans Itanium ait eu un effet enrichissant sur les compétences de ses ingénieurs, ce qui peut leur avoir permis de créer la prochaine génération de technologie à succès.
TL; DR: 1/il y a d'autres aspects de l'échec d'Itanium que les problèmes du compilateur et ils peuvent très bien suffire à l'expliquer; 2/un code d'octet n'aurait pas résolu les problèmes du compilateur.
Il est communément dit que l'architecture du processeur Itanium 64 bits d'Intel a échoué car le jeu d'instructions EPIC révolutionnaire était très difficile à écrire un bon compilateur pour
Eh bien, ils étaient également en retard (prévu pour 98, première expédition en 2001) et quand ils ont finalement livré le matériel, je ne suis même pas sûr qu'il a livré ce qui avait été promis pour la date antérieure (IIRC, ils ont au moins abandonné une partie de la émulation x86 qui était initialement prévue), donc je ne suis pas sûr que même si les problèmes de compilation ont été résolus (et AFAIK, il ne l'a pas encore fait), ils auraient réussi. L'aspect compilateur n'était pas le seul aspect trop ambitieux.
Y a-t-il une raison pour laquelle Intel n'a pas spécifié de langage de "simple bytecode Itanium" et a fourni un outil qui convertit ce bytecode en code EPIC optimisé, tirant parti de leur expertise en tant que personnes qui ont conçu le système en premier lieu?
Je ne sais pas où vous placez l'outil.
S'il est dans le processeur, vous avez juste une autre micro-architecture et il n'y a aucune raison de ne pas utiliser x86 comme public ISA (au moins pour Intel, l'incompatibilité a un coût plus élevé que tout ce qui pourrait apporter un ISA public plus propre).
S'il est externe, partir d'un code d'octet le rend encore plus difficile que de partir d'un langage de niveau supérieur. Le problème avec EPIC est qu'il ne peut utiliser que le parallélisme qu'un compilateur peut trouver, et l'extraction de ce parallélisme est difficile. Connaître les règles de langue vous offre plus de possibilités que si vous êtes contraint par quelque chose de déjà planifié. Mon souvenir (admis peu fiable et de quelqu'un qui l'a suivi de loin) est que ce que HP (*) et Intel n'ont pas réussi à obtenir sur le front du compilateur est l'extraction du parallélisme au niveau du langage, pas le bas niveau qui aurait été présent dans un octet. code.
Vous sous-estimez peut-être le coût auquel le processeur actuel atteint ses performances. OOO est plus efficace que les autres possibilités, mais il n'est sûrement pas efficace. L'EPIC voulait utiliser le budget de zone utilisé par la mise en œuvre de OOO pour fournir plus de calcul brut, en espérant que les compilateurs seraient en mesure de l'utiliser. Comme écrit ci-dessus, non seulement nous ne sommes toujours pas en mesure - comme AFAIK, même en théorie - d'écrire des compilateurs qui ont cette capacité, mais l'Itanium a suffisamment d'autres fonctionnalités difficiles à mettre en œuvre qu'il était tard et que sa puissance brute n'était pas même compétitif (sauf peut-être sur certains marchés de niche avec beaucoup de FP calcul) avec l'autre processeur haut de gamme quand il est sorti de fab.
(*) Vous semblez également sous-estimer le rôle de HP dans EPIC.
Quelques choses.
IPF était en règle, par exemple. Cela signifiait que vous ne pouviez pas compter sur la réorganisation pour vous sauver en cas de cache manquant ou d'un autre événement de longue durée. En conséquence, vous avez fini par devoir vous appuyer sur des fonctionnalités spéculatives - à savoir, les charges spéculatives (charges autorisées à échouer - utiles si vous ne saviez pas si vous auriez besoin d'un résultat de charge) et les charges avancées (charges qui pourraient être réexécutez, en utilisant le code de récupération, si un danger survient.) Obtenir ces bons résultats était difficile, des charges avancées en particulier! Il y avait également des conseils de prélecture de branche et de cache qui ne pouvaient vraiment être utilisés intelligemment que par un programmeur d'assemblage ou utilisant une optimisation guidée par profil, pas généralement avec un compilateur traditionnel.
D'autres machines à l'époque - à savoir UltraSPARC - étaient en ordre, mais IPF avait également d'autres considérations. L'une était l'encodage de l'espace. Les instructions Itanium n'étaient, par nature, pas particulièrement denses - un ensemble de 128 bits contenait trois opérations et un champ de modèle de 5 bits, qui décrivaient les opérations dans l'ensemble, et si elles pouvaient toutes être émises ensemble. Cela a donné une taille d'opération de 42,6 bits efficace - comparé à 32 bits pour la plupart des opérations commerciales des RISC à l'époque. (C'était avant Thumb2, et al - RISC signifiait toujours une rigidité de longueur fixe.) Pire encore, vous n'aviez pas toujours assez d'ILP pour s'adapter au modèle que vous utilisiez - il vous fallait donc un NOP-pad pour remplir le modèle ou le bundle. Ceci, combiné à la densité relativement faible existante, signifiait que l'obtention d'un taux de réussite i-cache décent était a) vraiment important, et b) difficile - d'autant plus que I2 n'avait qu'un L1I de 16 Ko (bien qu'il soit assez rapide.)
Bien que j'ai toujours senti que l'argument du "compilateur était le seul et unique problème" était exagéré - il y avait des problèmes microarchitecturaux légitimes qui n'aimaient vraiment pas I2 pour le code à usage général - ce n'était pas particulièrement amusant de générer du code pour comparer aux machines OoO plus étroites et à cadence plus élevée de la journée. Quand vous pouviez vraiment le remplir correctement, ce qui impliquait souvent PGO ou un codage manuel, c'était génial - mais la plupart du temps, les performances des compilateurs étaient vraiment peu inspirantes. IPF ne facilitait pas la génération de code génial, et c'était impitoyable quand le code n'était pas génial.
Mais pourquoi le compilateur était-il un problème technique si difficile? Il me semble que si le parallélisme explicite dans EPIC était difficile à implémenter pour les éditeurs de compilateurs ... pourquoi leur imposer ce fardeau en premier lieu? Ce n'est pas comme si une bonne solution bien comprise à ce problème n'existait pas déjà: placez ce fardeau sur Intel à la place et donnez aux rédacteurs du compilateur une cible plus simple.
Ce que vous décrivez est un peu ce que Transmeta a essayé de faire avec son logiciel de morphing de code (qui traduisait dynamiquement le "bytecode" x86 en code machine interne de Transmeta).
Quant à savoir pourquoi Intel n'a pas réussi à faire un compilateur assez bon pour IA64 ... Je suppose que c'est qu'ils n'avaient pas assez expertise en compilateur en interne (même si bien sûr ils avaient certains très bons experts en compilation à l'intérieur, mais probablement pas assez pour faire une masse critique). Je suppose que leur gestion a sous-estimé les efforts nécessaires pour faire un compilateur.
AFAIK, Intel EPIC a échoué parce que la compilation pour EPIC est vraiment difficile, et aussi parce que lorsque la technologie du compilateur s'est lentement et progressivement améliorée, d'autres concurrents ont également pu améliorer leur compilateur (par exemple pour AMD64), partageant un certain savoir-faire du compilateur.
BTW, je souhaitais que AMD64 aurait été un jeu d'instructions RISCy plus. Cela aurait pu être un peu POWERPC64 (mais ce n'était probablement pas à cause de problèmes de brevets, à cause des demandes de Microsoft à l'époque, etc ...). L'architecture du jeu d'instructions x86-64 n'est vraiment pas une architecture "très bonne" pour le rédacteur de compilateur (mais elle est en quelque sorte "assez bonne").
L'architecture IA64 a également intégré de fortes limitations, par exemple les 3 instructions/Word ont été bonnes tant que le processeur avait 3 unités fonctionnelles pour les traiter, mais une fois qu'Intel est allé sur des puces IA64 plus récentes, ils ont ajouté plus d'unités fonctionnelles et le parallélisme au niveau de l'instruction était à nouveau difficile à réaliser.
Peut-être RISC-V (qui est un ISA open source) réussira progressivement assez pour le rendre compétitif par rapport aux autres processeurs.
Comme l'a souligné Robert Munn - c'est le manque de compatibilité descendante qui a tué Itanium (et de nombreuses autres "nouvelles" technologies).
Bien que l'écriture d'un nouveau compilateur ait été difficile, vous n'en avez besoin que de quelques-uns. Un compilateur C qui produit du code optimisé est un must - sinon vous n'aurez pas de système d'exploitation utilisable. Vous avez besoin d'un compilateur C++, Java et étant donné que la base d'utilisateurs principale serait Windows une sorte de Visual Basic. Ce n'était donc pas vraiment un problème. Il y avait un système d'exploitation décent (NT) et un bon compilateur C disponible.
Ce qui semblerait être un effort insignifiant pour une entreprise offrant un produit logiciel - recompiler et retester votre base de code C (et à l'époque, la plupart auraient été écrits en C pur!) N'était pas aussi simple que cela; la conversion d'un large ensemble de programmes C qui supposait un entier 32 bits et supposait un adressage 32 bits en une architecture native 64 bits était pleine d'embûches. Si IA64 était devenu une puce dominante (ou même populaire!), La plupart des éditeurs de logiciels auraient mordu la balle et fait l'effort.
Puce si rapide avec un système d'exploitation raisonnable mais un ensemble très limité de logiciels disponibles, donc peu de gens l'ont acheté, donc peu de sociétés de logiciels ont fourni des produits pour cela.
Ce qui a tué Itanium, ce sont les retards de livraison qui ont permis à AMD64 d'intervenir avant que les éditeurs de logiciels ne s'engagent à migrer vers IA64 pour les applications 64 bits.
Laisser l'optimisation au compilateur était une bonne idée. Beaucoup de choses peuvent être faites de manière statique, ce qui est autrement inefficace en matériel. Les compilateurs sont devenus assez bons dans ce domaine, en particulier lors de l'utilisation du profilage PGO (j'ai travaillé chez HP et le compilateur HP avait tendance à surpasser Intel). PGO était une vente difficile cependant, c'est un processus difficile pour le code de production.
IPF était censé être rétrocompatible, mais une fois AMD64 lancé, il est devenu théorique, la bataille a été perdue et je crois que le matériel X86 dans le CPU a été simplement supprimé pour recibler en tant que CPU serveur. Itanium en tant qu'architecture n'était pas mauvais, les 3 instructions par mot n'étaient pas un problème. Ce qui était un problème est l'implémentation de l'hyper-threading en échangeant des piles pendant la mémoire IO était trop lent (pour vider et recharger le pipeline) jusqu'à Montecito etc., ce qui l'empêchait de concurrencer vs hors-de- ordonner les processeurs PowerPC. Les compilateurs ont dû corriger tardivement des défauts de mise en œuvre des processeurs, et certaines des performances d'Edge ont été perdues pour des erreurs difficiles à prévoir.
L'architecture a permis à Itanium d'être relativement simple tout en fournissant des outils pour que le compilateur en optimise les performances. Si la plate-forme avait survécu, les CPU seraient devenus plus complexes, et finiraient par devenir enfilés, hors service, etc. comme x86. Cependant, le premier transistor focalisé sur les gens compte sur d'autres schémas de performances puisque le compilateur a géré beaucoup de choses difficiles.
La plate-forme IPF a misé sur le compilateur et les outils, et ce fut la première architecture à exposer une conception extrêmement complète et puissante de Performance Monitoring Unit (PMU), qui a ensuite été redirigée vers Intel x86. Les développeurs d'outils si puissants ne l'utilisent toujours pas à sa pleine capacité pour profiler le code.
Si vous regardez les succès de ISA, ce n'est souvent pas le côté technique qui lance les dés. C'est sa place dans le temps et les forces du marché. Regardez SGI Mips, DEC Alpha ... Itanium vient d'être pris en charge par les perdants, les serveurs SGI et HP, les entreprises dont les directions ont accumulé des erreurs commerciales stratégiques. Microsoft n'a jamais été à fond et a adopté AMD64 pour ne pas être intégré avec uniquement Intel en tant que joueur, et Intel n'a pas bien joué avec AMD pour leur donner un moyen de vivre dans l'écosystème, car ils avaient l'intention d'étouffer la DMLA.
Si vous regardez où nous en sommes aujourd'hui, le matériel complexe de X86 l'a conduit jusqu'à présent à une impasse d'évolution. Nous sommes bloqués à 3 + GHz et vidons les cœurs avec une utilisation insuffisante. La conception plus simple d'Itanium aurait poussé plus de choses sur le compilateur (place pour la croissance), permettant de construire des pipelines plus minces et plus rapides. À la même génération et à la même technologie, il aurait fonctionné plus rapidement et plafonné tout de même mais un peu plus haut, avec peut-être d'autres portes à ouvrir à la loi de Push Moore.
Eh bien au moins ce qui précède est mes croyances :)
La mémoire devient vague ... Itanium avait de bonnes idées qui auraient besoin d'un excellent support du compilateur. Le problème était que ce n'était pas une caractéristique, c'était beaucoup. Chacun n'était pas un gros problème, tous ensemble.
Par exemple, il y avait une fonction de bouclage où une itération de la boucle fonctionnerait sur des registres de différentes itérations. x86 gère le même problème grâce à une énorme capacité hors service.
A cette époque Java et les machines virtuelles Java étaient à la mode. Ce qu'IBM a dit, c'est qu'avec PowerPC, vous pouviez compiler le bytecode rapidement et le CPU le rendrait rapide. Pas sur Itanium.