Il est communément admis que l'architecture de processeur Itanium 64 bits d'Intel a échoué parce que le jeu d'instructions EPIC révolutionnaire était très difficile à écrire pour un bon compilateur, ce qui signifiait un manque de bons outils de développement pour IA64, ainsi qu'un manque de développeurs créant des programmes pour l'architecture. et personne n’a voulu utiliser du matériel sans beaucoup de logiciels, et la plate-forme a donc échoué, et tout cela par manque deun clou de fer à cheval bons compilateurs.
Mais pourquoi le compilateur était-il un problème technique aussi difficile? Il me semble que si le parallélisme explicite dans EPIC était difficile à implémenter pour les éditeurs de compilateurs… pourquoi leur imposer cette charge en premier lieu? Ce n’est pas comme si une bonne solution bien comprise à ce problème n’existait pas déjà: imposer cette charge à Intel et donner aux auteurs du compilateur une cible plus simple.
Itanium est sorti en 1997. À ce stade, le système de bytecode UCSD P-Code avait presque 20 ans, la Z-machine à peine plus jeune et la JVM était la nouvelle étoile montante dans le monde des langages de programmation. Existe-t-il une raison quelconque pour laquelle Intel n’a pas spécifié de langage «simple bytecode Itanium» et fourni un outil qui convertisse ce bytecode en code EPIC optimisé, en tirant parti de leur expertise en tant que personnes qui ont conçu le système au départ?
Réponses:
Si je me souviens bien à l'époque, le problème ne concernait pas que les détails de l'IA64, c'était la concurrence du jeu d'instructions x86-64 d'AMD. En rendant leur architecture rétro-compatible avec le jeu d'instructions x86, AMD a pu exploiter les outils et les compétences existants des développeurs. Le mouvement d'AMD a été un tel succès que Intel (et Via) ont été essentiellement obligés d'adopter l'architecture x86-64.
La grande barrière à l'époque était de 4 Go de RAM sur les ordinateurs de bureau (plus réaliste: environ 3,4 Go utilisable sous Windows). Le x86-64 a brisé cette barrière et ouvert à tout le monde l'informatique plus puissante. Si AMD n’avait jamais proposé la technologie x86-64, je suis sûr que Intel aurait été ravi de laisser tous ceux qui souhaitaient passer à 4 Go + RAM payer une prime considérable pendant des années pour bénéficier de ce privilège. Démonstration de la lenteur des mouvements des marchés, il a fallu des années pour que les applications puissent prendre en charge une programmation multithread 64 bits, et même maintenant, 4 Go de RAM sont 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 les x86-64. Sur un marché établi, les étapes évolutives qui permettent aux travailleurs du savoir d’exploiter les compétences existantes l'emporteront sur des étapes révolutionnaires nécessitant que tout le monde 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 que AMD a ajouté les extensions x86-64.
Je n'achète pas l'explication selon laquelle IA64 était trop difficile à programmer. Ce n'était que difficile par rapport aux alternatives. L'argument de @ delnan à propos des faibles niveaux de RI est clair, je ne pense pas que cela aurait fait une différence.
Quant à savoir pourquoi Intel n'a pas essayé d'assumer lui-même ce fardeau, 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 que tout le reste pour pouvoir déplacer l'ensemble du marché. Ils essayaient peut-être de créer un niveau supérieur et de laisser AMD, VIA, etc. au deuxième niveau, en se battant pour du 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 haut de gamme et de sortir du tapis sous AMD, VIA, etc.? Bien sûr, c'est comme ça que les affaires fonctionnent.
la source
L' article de Wikipedia sur EPIC a déjà décrit les nombreux dangers communs à VLIW et EPIC.
Si quelqu'un ne comprend pas le sentiment de fatalisme de cet article, laissez-moi souligner ceci:
En d'autres termes, toute conception matérielle qui ne parvient pas à gérer (*) la latence non déterministe à partir de l'accès à la mémoire deviendra tout simplement un échec spectaculaire.
(*) Par "faire face", il est nécessaire d’obtenir des performances d’exécution raisonnablement bonnes (en d’autres termes, "coût compétitif"), ce qui nécessite de ne pas laisser le processeur tourner au ralenti pendant des dizaines à des centaines de cycles.
Notez que la stratégie d’adaptation utilisée par EPIC (mentionnée dans l’article de Wikipedia référencé ci-dessus) ne résout pas le problème. Cela indique simplement que le fardeau d'indiquer la dépendance des données incombe maintenant au compilateur. C'est très bien; le compilateur a déjà cette information, il est donc facile pour le compilateur de s'y conformer. Le problème est que le processeur va toujours rester inactif pendant des dizaines à des centaines de cycles sur un accès mémoire. En d’autres termes, il extériorise une responsabilité secondaire tout en ne s’acquittant pas de la responsabilité première.
La question peut être reformulée de la manière suivante: "Étant donné qu'une plate-forme matérielle est vouée à un échec, pourquoi (1) ne peut-il pas (2) les rédacteurs du compilateur ne pourraient-ils pas faire un effort héroïque pour le 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 performance due à une latence non déterministe à partir d'un accès à la mémoire.
En réalité, le préchargement 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 aidera.)
Cependant, la plupart des logiciels à usage général doivent créer de nombreux accès en mémoire aléatoire. Si nous considérons les étapes suivantes:
Pour la plupart des logiciels à usage général, ces trois opérations doivent être exécutées rapidement. 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 lacunes entre ces trois étapes.
Pour aider à expliquer pourquoi il n’est pas toujours possible de trouver assez de travail pour remplir les stands, voici comment le visualiser.
(*) Si nous pouvions faire
NOPun travail utile ...Les processeurs modernes essaient de gérer la même chose en utilisant des informations dynamiques - en suivant simultanément les progrès de chaque instruction lors de leur circulation dans les pipelines. Comme je l'ai mentionné plus haut, une partie de cette information dynamique est due à une latence non déterministe de la mémoire. Par conséquent, elle ne peut être prédite avec une extrême précision par les compilateurs. En général, il n’ya tout simplement pas assez d’informations disponibles au moment de la compilation pour prendre des décisions qui pourraient éventuellement combler ces lacunes.
En réponse à la réponse de 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 est la preuve évidente qu'il n'a pas de problème à identifier les opérations indépendantes et donc exécutables simultanément.
Le problème principal est que la latence non déterministe de la mémoire signifie que le "couplage d'instructions" que l'on a codé pour le processeur VLIW / EPIC finira par être bloqué par un accès mémoire.
L'optimisation des instructions qui ne se bloquent pas (arithmétique en registre uniquement) n'aidera pas les problèmes de performances causés par des instructions très susceptibles de se bloquer (accès à la mémoire).
C’est un exemple d’échec dans l’application de la règle d’optimisation 80-20: l’optimisation des choses déjà rapides n’améliorera pas sensiblement 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 "... (peu importe), c'est difficile", c’est que l’EPIC ne convient pas à une plate-forme qui doit faire face à un fort dynamisme en matière de latence.
Par exemple, si un processeur présente toutes les caractéristiques suivantes:
Ensuite, VLIW / EPIC conviendra parfaitement.
Où trouve-t-on de tels processeurs? DSP. Et c’est là que VLIW a prospéré.
En rétrospective, l’échec d’Itanium (et la poursuite des efforts de R & D, 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 avoir beaucoup de 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 leur a peut-être permis de créer la prochaine génération de technologies performantes.
la source
TL; DR: 1 / la défaillance d’Itanium comporte d’autres aspects que ceux du compilateur et ils pourraient très bien suffire à l'expliquer; 2 / un code d'octet n'aurait pas résolu les problèmes du compilateur.
Eh bien, ils étaient également en retard (prévu pour 98, première livraison en 2001) et quand ils ont finalement livré le matériel, je ne suis même pas sûr que celui-ci a livré ce qui avait été promis pour la date antérieure (IIRC, ils ont au moins laissé tomber une partie du logiciel). é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, ce n’est pas encore le cas), ils auraient réussi. L’aspect compilateur n’était pas le seul aspect trop ambitieux.
Je ne sais pas où vous placez l'outil.
Si c'est dans le processeur, vous avez juste une autre micro-architecture et il n'y a aucune raison de ne pas utiliser x86 en tant qu'ISA public (du moins pour Intel, l'incompatibilité a un coût plus élevé que tout ce qui pourrait apporter un ISA public plus propre).
Si c'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 extraire ce parallélisme est difficile. Connaître les règles linguistiques vous donne plus de possibilités que si vous êtes contraint par quelque chose de déjà planifié. Mon souvenir (admis peu fiable et de la part de quelqu'un qui a suivi cela de loin) est que ce que HP (*) et Intel n'ont pas réussi à réaliser sur le front du compilateur est l'extraction du parallélisme au niveau linguistique, et non le niveau bas 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 ce n'est sûrement pas efficace. EPIC souhaitait utiliser le budget de surface utilisé par la mise en œuvre de OOO pour fournir davantage d’informatique brute, dans l’espoir que les compilateurs puissent l’utiliser. Comme indiqué ci-dessus, non seulement nous ne sommes toujours pas en mesure - en tant que AFAIK, même en théorie - d'écrire des compilateurs dotés de cette capacité, mais l'Itanium disposait de suffisamment de fonctionnalités difficiles à mettre en œuvre pour qu'il soit en retard et sa puissance brute n'était pas suffisante. même compétitif (sauf peut-être sur certains marchés de niche avec beaucoup de calcul FP) avec l’autre processeur haut de gamme lorsqu’il est sorti de la fab.
(*) Vous semblez également sous-estimer le rôle de HP dans EPIC.
la source
Quelques choses.
IPF était en ordre, pour un. Cela signifiait que vous ne pouviez pas compter sur la réorganisation pour vous sauver en cas de perte de mémoire cache ou de tout autre événement de longue durée. Par conséquent, vous avez fini par avoir besoin de recourir à des fonctions spéculatives - à savoir, des charges spéculatives (charges qui ont été autorisées à échouer - utiles si vous ne savez pas si vous avez besoin d'un résultat de charge) et des charges avancées (charges Exécutez à nouveau, en utilisant le code de récupération, si un danger survient.) Obtenir ces correctes était difficile, charges avancées en particulier! Il existait également des astuces de prélecture de branche et de cache qui ne pouvaient en réalité être utilisées intelligemment que par un programmeur d'assemblage ou à l'aide d'une optimisation guidée par profil, généralement pas avec un compilateur traditionnel.
À l’époque, d’autres machines - notamment UltraSPARC - étaient en ordre, mais IPF avait aussi d’autres considérations. L'un était l'espace d'encodage. Les instructions Itanium n'étaient, par nature, pas particulièrement denses: un groupe de 128 bits contenait trois opérations et un champ de modèle de 5 bits, décrivant les opérations du groupe et indiquant si elles pouvaient toutes être émises ensemble. Cela a permis d'obtenir une taille d'opération efficace de 42,6 bits, à comparer à 32 bits pour la plupart des opérations des RISC du commerce à ce moment-là. (C'était avant Thumb2, et autres - 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 - vous auriez donc besoin de NOP-pad pour remplir le modèle ou le paquet. Ceci, combiné à la faible densité relative existante, signifiait qu'obtenir un taux de réussite décent i-cache était a) très important,
Bien que j'aie toujours pensé que l'argument du "compilateur était le seul et unique problème" était exagéré - il existait des problèmes microarchitecturaux légitimes qui rendaient vraiment I2 pas favorable au code à usage général - ce n'était pas particulièrement amusant de générer du code pour les comparés aux machines OoO plus étroites et plus cadencées du jour. Lorsque vous pouviez vraiment le remplir correctement, ce qui impliquait souvent le codage PGO ou manuel, le résultat était excellent - mais la plupart du temps, les performances des compilateurs étaient vraiment sans intérêt. IPF ne permettait pas de générer facilement du bon code, et c'était impitoyable quand le code n'était pas génial.
la source
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 ne Intel n'a pas réussi à faire un assez bon compilateur pour IA64 ... Je suppose qu'ils ne disposaient pas assez d' expertise du compilateur dans la maison (même si bien sûr , ils ne sont quelques experts du compilateur très bien à l' intérieur, mais probablement pas assez pour faire une masse critique). Je suppose que leur direction a sous-estimé les efforts nécessaires pour créer un compilateur.
AFAIK, Intel EPIC a échoué car la compilation pour EPIC est très difficile et parce que, lorsque la technologie du compilateur s’est lentement et progressivement améliorée, d’autres concurrents ont également été en mesure d’améliorer leur compilateur (par exemple pour AMD64), en partageant un certain savoir-faire du compilateur.
BTW, je souhaitais que AMD64 aurait été un peu plus jeu d'instructions RISCy. Cela aurait pu être un POWERPC64 (mais ce n’était probablement pas à cause de problèmes de brevets, à cause des demandes de Microsoft à cette époque, etc.). L'architecture du jeu d'instructions x86-64 n'est vraiment pas une "très bonne" architecture pour le compilateur (mais elle est en quelque sorte "assez bonne").
L’architecture IA64 comporte également de fortes limitations, par exemple les 3 instructions / mot ont été bonnes tant que le processeur avait 3 unités fonctionnelles pour les traiter, mais une fois que Intel est passé aux puces IA64 plus récentes, elles ont ajouté plus d’unités fonctionnelles, et l’instruction Le parallélisme des niveaux était encore une fois difficile à atteindre.
Peut - être que RISC-V (qui est un ISA open source) réussira progressivement à être suffisamment performant pour le rendre concurrentiel par rapport aux autres processeurs.
la source
Comme l'a souligné Robert Munn - c'est le manque de compatibilité en amont qui a tué l'Itanium (et de nombreuses autres "nouvelles" technologies).
Bien qu'écrire un nouveau compilateur ait peut-être été difficile, vous n'avez besoin que de quelques-uns d'entre eux. Un compilateur CA qui produit un code optimisé est un must - sinon vous n’auriez 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. Donc ce n'était 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 trivial pour une entreprise proposant un logiciel - recompiler et retester votre base de code C (et à cette époque, la plupart aurait été écrit en C pur!) N’était pas aussi simple; convertir un grand ensemble de programmes C qui supposaient un entier de 32 bits et supposaient que l'adressage de 32 bits à une architecture native de 64 bits était pleine de pièges. Si IA64 était devenu une puce dominante (ou même une puce populaire!), La plupart des éditeurs de logiciels auraient mordu la balle et fait l'effort.
Puce tellement rapide avec un système d’exploitation raisonnable mais un ensemble très limité de logiciels disponibles. Peu de gens l’ont donc achetée et peu de fabricants de logiciels ont donc fourni des produits.
la source
Ce qui a tué Itanium, ce sont les retards d'expédition qui ont permis à AMD64 d'intervenir avant que les fournisseurs 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 statiques qui autrement sont inefficaces en matériel. Les compilateurs sont devenus très compétents, en particulier lors de l’utilisation du profil PGO (j’ai travaillé chez HP et ce compilateur a tendance à surpasser celui d’Intel). PGO a été une vente difficile, cependant, c'est un processus difficile pour le code de production.
IPF était censé être rétro-compatible, mais une fois que AMD64 a été lancé, il est devenu sans objet, la bataille a été perdue et je crois que le matériel X86 dans le processeur venait tout juste d'être redirigé vers un processeur de serveur. Itanium en tant qu'architecture n'était pas mauvais, les 3 instructions par mot n'étaient pas un problème. Le problème, c’est que l’implémentation hyper-threading consistant à permuter les piles pendant la mémoire IO était trop lente (pour vider et recharger le pipeline) jusqu’à Montecito, etc., ce qui l’empêchait de concurrencer les CPU PowerPC hors d’ordre. Les compilateurs ont dû corriger les failles des implémentations de processeur tardives afin de détecter les failles des performances, et une partie de la performance a été perdue au point de laisser des erreurs difficiles à prévoir.
L'architecture a permis à Itanium d'être relativement simple tout en fournissant des outils au compilateur pour en améliorer les performances. Si la plate-forme avait vécu, les processeurs seraient devenus plus complexes et, éventuellement, deviendraient threadés, en panne, etc., comme x86. Cependant, les premiers transistors axés sur la génération reposent sur d’autres schémas de performances puisque le compilateur a géré une grande partie de la tâche la plus ardue.
La plate-forme IPF a misé sur le compilateur et les outils. Il s'agit de la première architecture à présenter une conception extrêmement complète et puissante de Performance Monitoring Unit (PMU), qui a par la suite été reportée sur Intel x86. Les développeurs d'outils si puissants ne l'utilisent toujours pas pleinement dans sa capacité à profiler le code.
Si vous regardez les succès d'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 soutenu par les perdants, les serveurs SGI & HP, des entreprises aux gestes empreints d’erreurs stratégiques. Microsoft n’a jamais été à fond et a adopté AMD64 pour ne pas jouer avec Intel, mais Intel n’a pas bien joué avec AMD pour leur donner le moyen de vivre dans l’écosystème, car ils avaient l’intention de prendre AMD.
Si vous regardez où nous en sommes aujourd'hui, le matériel complexe de X86 l'a conduit à une impasse de l'évolution jusqu'à présent. Nous sommes bloqués à 3 + GHz, et les décharges de cœurs ne sont pas assez utilisées. La conception plus simple d'Itanium aurait poussé plus de matériel sur le compilateur (espace de croissance), permettant de construire des pipelines plus minces et plus rapides. À la même génération et avec la même technologie, elle aurait fonctionné plus rapidement et aurait été plafonnée, mais un peu plus haut, avec peut-être d'autres portes à ouvrir pour faire avancer la loi de Moore.
Bien au moins ce qui précède est mes croyances :)
la source
La mémoire devient vague ... Itanium a eu quelques bonnes idées qui nécessiteraient un excellent support du compilateur. Le problème était que ce n'était pas une caractéristique, mais beaucoup. Chacun n'était pas un gros problème, tous ensemble.
Par exemple, il existait une fonction de mise en boucle dans laquelle une itération de la boucle opérait sur des registres d'itérations différentes. x86 résout le même problème grâce à une capacité de mise hors service massive.
A cette époque, Java et les JVM étaient à la mode. Ce que IBM a dit, c’est qu’avec PowerPC, vous pouvez compiler le bytecode rapidement et que le processeur le rendrait rapide. Pas sur Itanium.
la source