lasher a écrit 2732 commentaires

J'ai pertinenté, mais il ne faut pas oublier que se sentir offensé n'en fait pas une vérité. Nombre d'américains conservateurs sont offensés de « the war on Christmas », truc complètement fantasmé — tout ça parce que beaucoup de magasins ou chaînes de télés disent « bonnes fêtes » plutôt que « joyeux Noël »; alors que dans le même temps, les villes exhibent des crèches grandeur nature sur leurs grand' places…

Idem pour les athées qui se permettent de tourner en ridicule les religions, et qui se font maltraiter parce qu'ils ont offensé une ou plusieurs communautés religieuses. Pour citer un acteur/entertainer que j'aime beaucoup, Stephen Fry:

It's very common to hear people say "I'm rather offended by that." As if that gives them certain rights; it's actually nothing more… It's simply a whine. It's no more than a whine. "I find that offensive." It has no meaning. It has no purpose. It has no reason to be respected as a phrase. "I am offended by that." Well so fucking what?

Traduction approximative :

Il est très fréquent d'entendre « Je suis plutôt offensé par ceci. » Comme si ça donnait certains droits; ce n'est en fait rien de plus… C'est simplement un geignement. Ce n'est rien de plus qu'un geignement. « Je trouve ça offensant. » Ça n'a aucun sens. Ça n'a aucun but. Ça n'a aucune raison d'être respecté en tant qu'expression. « Je suis offensé par ceci. » Putain, et après ?

Je me considère féministe:
"Le féminisme est un ensemble d'idées politiques, philosophiques et sociales cherchant à définir, promouvoir et établir les droits des femmes dans la société civile et dans la sphère privée. Il s'incarne dans des organisations dont les objectifs sont d'abolir les inégalités sociales, politiques, juridiques, économiques et culturelles dont les femmes sont victimes."

(L'emphase est de moi)

Hum, même s'il a fait une ellipse, c'est peu ou prou ce que disait jyes. Il n'a pas écrit le mot « droit », mais dans le contexte de son message c'était implicite. Je ne peux donc que tomber d'accord sur ce qu'il dit, et affirmer que tu lui attribue des intentions, et tu donnes à ses mots un sens qu'il n'a pas voulu donner.

Sauf qu'écrire une dépêche ou un journal intéressant, ça consomme un temps fou si on essaie d'y mettre les formes (tu en sais quelque chose je pense).

Je ne vois pas pourquoi on t'inutilise. Ton objection est parfaitement valable: tout un chacun peut effectivement vérifier le processus de dépouillement. La seule expertise requise est d'avoir des yeux et des oreilles en état correct de fonctionnement. Pour le côté dépouillement, c'est un peu technique, il faut savoir compter…

Tu peux même dire « trois ordres de grandeur » si les calculs sur chiffrés homomorphes sont jusqu'à 1000 fois plus lents … :-)

C'est complètement faux !

… Puis tu fais suivre avec des exemples en F77. Fortran 90 rajoute tout un tas de trucs très utiles (notamment « free form », etc.), mais n'est pas encore objet et … TADAAAAA ! est toujours compatible avec C (en tout cas ifort+gcc, ifort+icc, etc.).

Pour F95 et ses successeurs, je te fais confiance. Ensuite, même si la forme n'y est pas, nazcafan a raison sur un point : j'ai bossé avec des boites allemandes et françaises pour aider à l'optimisation de leurs codes, et tous étaient écrits en F77 ou F90. Je suis certain qu'il existe des codes conséquents écrits en F95 et plus, mais je n'en ai jamais rencontré.

L'ABI C++ n'est pas standardisee et notamment le name mangling.
Oui, c'est ce que je voulais dire, mais j'ai oublié de le mentionner. Merci ! :)

Oui enfin, l'ABI entre icpc (C++) et g++ est différente même sous Linux. Tu fais comment dans ce cas ? C et Fortran ont une ABI compatible (il suffit de mettre les underscores au bon moment, au bon endroit pour les noms de symboles). Quel genre d'interaction voudrais-tu voir ?

Théoriquement, Si tu utilises les bons front-ends (clang pour C, clang++ pour C++, le front-end de OCaml, etc.), ils devraient générer le pseudo-assembleur de LLVM, et donc tu devrais pouvoir tout faire interagir. Je ne sais pas si c'est vrai, et quelles sont les limitations qui l'empêchent si c'est faux.

Sur x86, les instructions qui ne mettent pas en cache (je suppose que tu parles des instructions de type mov[xxx]nta etc.) n'empêchent pas la mise en cache à ma connaissance, mais garantissent que les données seront placées en tant que « lignes les moins utilisées » (pour être les premières à être évincées).

Voilà, j'ai retrouvé le papier dont je parlais : A control-structure splitting optimization for GPGPU

Oui pour l'ECC, mais que veux-tu dire pour le cache ?

Oui pour les bus, mais tu parles de quelque chose de différent là. Ce qui différencie un Xeon (en règle générale) de son équivalent « de bureau », c'est la possibilité de le faire fonctionner en multi-processeur (SMP). Ça veut dire entre autres qu'Intel doit rajouter un peu de logique pour gérer le protocole de cohérence de cache inter-processeur (MESIF). Il faut aussi rajouter de la logique pour gérer QPI (quick path interconnect), la techno d'accès NUMA d'Intel (qui concurrence HyperTransport d'AMD).

Sinon je veux juste vérifier ce que tu veux dire par « plus de bus d'accès à la mémoire ». Est-ce qu'on parle du bus par processeur que je viens d'évoquer ? Ou bien parles-tu de plusieurs bus par processeur ? Je sais que sur certains processeurs d'AMD (Bulldozer etc.) il y a effectivement deux bancs mémoire par proc, mais je n'en avais pas entendu parler pour Intel…

Heu, la FPU pour les processeurs Intel hauts et bas de gamme en termes de micro-architecture, je pige pas trop bien.

Disons que j'ai un Core i5. Il y a une version haut de gamme, avec 8Mio de cache L3, 3.2GHz de vitesse d'horloge, etc. Il y a une version « bas de gamme », avec 3Mio de cache L3, et 1.8GHz. Il y a une différence de peut-être ~50$ entre la version haut de gamme et l'autre. Maintenant, si je considère un Core i7 : c'est exactement la même micro-architecture au niveau d'un cœur, ce qui inclue la FPU. Par contre, on passe de 2 à 6 cœurs, et de 8Mio à 12Mio de cache L3. Et le prix est multiplié par deux ou trois par rapport au haut de gamme du Core i5… Comme le nombre de cœurs en fait.

Bah le problème de la PS3 était que le SDK était tout pourri, de ce qu'on m'a expliqué (j'y ai jamais touché). Bon, il y avait un autre problème aussi. Un mec d'une agence US à trois lettres que je n'ai pas le droit de nommer l'avait relativement bien expliqué devant des mecs d'IBM, Intel, etc. : « Le prochain architecte qui me propose une architecture de processeur sans cache d'instruction et me force à gérer la copie des donnés et des instructions dans les scratchpads, je vais physiquement lui faire très mal. »

C'est marrant, tu as exactement le point de vue du côté hardware : croire que c'est en faisant des améliorations matérielles qu'on arrivera à avoir des performances.

Ce n'est absolument pas ce que je sous-entends. Et je ne dis absolument pas que les mecs du hardware sont les « gentils », et les mecs du soft les « méchants ». Je suis un mec du soft moi-même, et il se trouve que j'ai bossé (et je continue de bosser en fait) beaucoup avec les gens de la compilation, mais aussi avec des architectures pour les processeurs.

Dans le cas des architectes, je peux te dire qu'au moins sur le projet auquel je participe, à chaque fois qu'on demandait une instruction en matériel, la réponse qu'on obtenait était en gros « Why do you need it? Show me the data ». Pour être honnête, l'architecture est pensée pour être extrêmement efficace énergétiquement parlant, donc si tu demandes un mécanisme de prédicat pour les conditionnelles, forcément, le monsieur, il tique. En gros, l'idée de notre projet est de justement exposer le plus de trucs en hard au logiciel, pour le que le logiciel fasse ce qu'il veut/peut avec. Ensuite, les mecs des compilateurs/runtimes retournent parler avec les architectures/mecs du hard, et leur disent ce qui définitivement nécessite d'être mis en œuvre en matériel, et ce que le logiciel peut faire efficacement sans aide matérielle.

Le point de vue que j'expose est aussi celui de pas mal de chercheurs en compilation : en gros, on a des techniques, on démontre qu'elles fonctionnent soit expérimentalement, du genre « je te donne mon algo, mais pour mes expériences j'ai tout transformé à la main », soit tu fais quelque chose de relativement théorique du genre « tiens, voilà mon algo, qui est en complexité polynomiale, et je fais la preuve qu'il est correct ». De temps en temps, tu as des mecs qui l'implémentent pour de vrai dans leurs compilateurs (heureusement). Mais je dirais que c'est du ⅓/⅓/⅓ en termes de proportions quand tu lis les papiers de recherche. À ceci il faut rajouter que l'implémentation n'est pas nécessairement disponible (parce qu'elle est faite dans un compilateur proprio), ce qui force donc le mec qui veut mettre en œuvre la technique de découvrir par lui-même tout ce qui n'a pas été dit. Parfois, ce qui fait qu'une technique fonctionne bien tient autant à l'algorithme qu'aux subtilités d'implémentation.

C'est par exemple ce qui s'est passé pour le papier sur la forme SSA : le papier était le premier à proposer un algorithme utilisable (i.e. en temps polynomial) pour exploiter SSA. Le truc, c'est que même si tu as trouvé le bon algo, écrire un compilateur nécessite de choisir très soigneusement ses structures de données. Il existe des papiers qui tiennent plus de l'ingénierie que de la recherche, mais qui expliquent comment un algorithme (par ex, mise sous forme SSA, puis faire un « de-SSA ») est équivalent à l'original, mais plus simple, et donc plus facile à implémenter sans bug.

De plus, SSA en elle-même n'est pas une optimisation, mais elle permet d'obtenir une représentation du code qui permet les optimisations plus facilement.

Sinon, les chercheurs en compilation vont bien entendu aussi te dire que les mecs du hardware te sortent des features de leur chapeau, sans forcément penser à « l'interface », ce qui rend la tâche du dév. de compilateur pour le moins ardue (par exemple : toutes les options proposées par l'Itanium en font un processeur — au moins de recherche — génial, mais avec aucun moyen « facile » de les utiliser depuis des intrinsics).

Première raison, c'est que les principaux gains de performance qui ont lieu ne sont pas dû au matériel comme tu le sous-entends mais sont principalement le fait d'avancées algorithmiques (surtout dans le domaine du calcul scientifique auquel se destine le processeur dont nous parlons),

Pour le calcul scientifique, j'ai déjà dit ailleurs qu'entre deux générations de processeurs, il fallait souvent ré-adapter le code pour la nouvelle architecture (les timings étant différents pour certaines séquences d'instruction, la hiérarchie mémoire ayant changé, etc.), ce qui se fait évidemment de façon logicielle. Cependant, surtout dans le cas des x86, oui, la venue des moteurs out-of-order, couplée à la présence de préchargeurs mémoire en matériel fait que, très souvent, il n'est plus nécessaire d'insérer à la main les trucs du genre _mm_prefetch(address).

Enfin, il est évident que le choix de la bonne structure de donnée et du bon algorithme sont les sources fondamentales de performance. Ce qui est aussi évident cependant, c'est que si ton implémentation utilise le « bon » algorithme, mais que les constantes élidées de ton algo en O(N) ou O(N log N) sont trop grosses, au final pour beaucoup des programmes scientifiques en question et qui tournent sur des workstations ou des petits clusters, la différence avec des algos à la complexité moins bonne mais mieux optimisés sera minime. Même sur les gros calculateurs, si ton programme est visiblement mal optimisé, tu risques de te prendre un refus par ses admins, parce que le temps machine est précieux (et que ça bouffe en électricité).

La raison pour laquelle les architectes rajoutent des fonctionnalités en matériel est évidemment qu'elles sont considérées comme utiles par les mecs du soft. Les instructions AltiVec ou SSE sont limitées en termes d'utilité pour les programmes en général, mais pour écrire des BLAS efficaces, si tu n'utilises pas ces instructions sur PowerPC ou x86, tu perds potentiellement entre 20 et 50% de performance (je prends en compte le fait que ton code ne fera pas que des multiplications de matrices).

Deuxième raison, le compilateur ne fait pas tout. Oui, comme tu le dis, il faut avoir un modèle de programmation parallèle, et si le matériel pouvait éviter de figer le modèle, on s'en porterait mieux, ça permettrait de pouvoir tester plein de modèle et de choisir suivant les cas. C'est bien l'algorithmique parallèle qui va amener les principaux gains, et pour faciliter le travail algorithmique, une machine «simple» (au sens où on peut en avoir une abstraction simple, mais elle peut être très complexe en vrai) et prévisible, c'est mieux.

Ben je suis dans un groupe de recherche qui justement cherche à proposer un modèle d'exécution¹ adapté aux manycores. En gros notre but est de fournir une sorte de vision un peu abstraite d'un « assembleur parallèle ». Ensuite, si tu veux continuer à utiliser OpenMP¹, mais qu'il génère notre truc, on est très content aussi (il faut juste quelqu'un qui écrive le compilateur qui va bien …).

Le gros problème est effectivement (comme je le disais dans un commentaire plus haut) un manque de communication entre les fabricants de processeurs/machines parallèles, et les gens des logiciels systèmes (OS, Runtime, compilateurs). La communauté scientifique en prend lentement conscience, à mesure que 50 000 machines parallèles voient le jour, chacune avec leur modèle d'exécution, chacune avec leur modèle de programmation.

[1] Je dis bien exécution et pas programmation. Par exemple, le modèle de von Neumann est un modèle d'exécution séquentiel.
[2] Voilà, ça c'est un modèle de programmation. :-) … Bon, il a aussi un modèle d'exécution, mais c'est pas (trop) important pour le programmeur.

Il y a tout un champ de recherche sur des mémoires locales (caches ou scratchpads) ou même la DRAM qui soient désactivables par morceaux (clockgating ou même powergating) en fonction de ce dont les processeurs ont besoin, justement pour que tu puisses réduire la consommation statique. Intel a récemment publié un papier (il y a ~6 mois ?) qui montre comment utiliser une FPU avec une précision variable pour des FMA, histoire de pouvoir « couper » la partie du bus qui ne sert à rien. Les modes étaient quelque chose du genre 16bits, 32bits, et 64bits si je me souviens bien.

Mon exemple est tiré d'un papier de compilation pour GPU. Il est tout à fait possible que la façon dont j'ai simplifié/représenté le pseudo-code (de mémoire) ne déclenche pas ce comportement tel qu'écrit. Mais c'était réellement l'idée à 1000km d'altitude.

Je suis en train de chercher le papier en question, et dès que je le retrouve, je viendrai donner les références ici.

Je parle en termes de recherche bien sûr, et par exemple les projets auxquels je participe en ce moment ont tous le co-design à l'avant plan : des mecs de la compilation, des mecs des runtimes, des mecs de l'archi, etc., mais aussi des mecs des applications.

L'Itanium 1 (Merced) était compatible x86. Il y avait une couche d'émulation (très lente).

Personnellement, je me demande comment ça se fait que, de nos jours, on n'imagine pas le processeur en même temps que le logiciel qui va tourner dessus.

Oui enfin c'est un peu facile comme remarque. Pendant environ 20 ans, on a eu droit à la loi de Moore « facile », celle qui transformait « pour une surface donnée, on va doubler le nombre de transistors tous les 18 ou 24 mois » en « on va doubler la fréquence d'horloge des microprocesseurs tous les 18 à 24 mois ». Maintenant qu'on ne peut plus faire ça, on (re)passe au parallélisme (qu'on croyait être la panacée dans les années 70 et 80, et qui avait été déclaré mort et enterré pour l'usage générique dans les années 90 jusqu'en 2005). Donc pendant 20 ans, le hardware grand public accélérait plus ou moins automatiquement l'exécution d'applications, parfois sans même avoir besoin de recompiler. Bien sûr il y avait quelques trucs supplémentaires ici et là (AltiVec, 3dNow!, MMX, puis SSE, AVX) pour écrire des applications qui pouvaient spécifiquement viser certains types de codes (comme les instructions AES pour SSE4), mais globalement tout était pépère pour des applications « grand public ».

Pour les gens qui écrivent des applications dans un environnement où les ressources sont très limitées (en gros les applications de calcul scientifique/calcul intensif et les applications embarquées), chaque nouvelle version d'un processeur a tendance à rajouter son lot de comportements qui perturbent fortement les performances. Comme les compilateurs ont tendance à évoluer relativement lentement, on se retrouve à faire des optimisations à la main, et qui souvent devront être refaites/modifiées pour la prochaine génération de processeurs.

Et la raison pour tout ça, c'est qu'il y a deux facteurs de ralentissement pour l'optimisation automatique de code (en utilisant un compilateur) :

1. Entre le moment où une technique/un algorithme/etc. pour l'optimisation de code est publiée quelque part et le moment où elle est mise en œuvre dans des compilateurs en production, il se passe environ 10 ans. Le hardware n'y est pour rien. Par exemple, une version efficace de la représentation de programmes sous forme SSA (Static Single Assignment) a été proposée en 1989. Elle a été mise en œuvre dans des compilateurs de prod' vers 1997 si je ne me trompe pas (dans open64 de SGI), et dans GCC pas avant la v3.5, soit vers 2003-2004.
2. Entre le moment où le hardware expose de nouvelles fonctionnalités, que ce soit des instructions vectorielles (MMX/SSE/AVX), l'utilisation de prédicats pour exécuter du code spéculativement (sur processeurs Itanium ou ARM), les instructions de préchargement mémoire, ou même comme plus récemment, une version limitée de mécanismes de mémoire transactionnelle (sur certains modèles du Haswell d'Intel, ou bien pour les processeurs de Blue Gene Q), et le moment où elle peut être exploitée automatiquement, il se passe entre 5 et 10 ans. Par exemple, la génération automatique d'instructions vectorielles sur GCC a été considérée comme expérimentale jusque vers GCC v4.3 je crois bien (je peux me tromper). Pire, elle reste extrêmement restreinte comparée à l'implémentation d'Intel dans ICC.
3. Bref, le temps qu'un compilateur exploite correctement les features d'une archi, celle-ci a le temps de devenir dépassée (c'est quasiment le cas avec l'Itanium 2 par exemple).

Et oui, il y a un gros effort à faire pour faire communiquer les architectes et les développeurs de compilateurs et autres bibliothèques haute performance. D'ailleurs, un bon moyen d'obtenir des sous pour la recherche aux USA et en UE depuis environ 2009-2010, c'est de parler de co-design, en montrant qu'on associe des mecs du hardware et des mecs du software pour faire un système informatique avec un modèle d'exécution parallèle qui tient la route (càd : une vraie sémantique parallèle, un modèle mémoire qui permette les optimisations tout en assurant que les programmes s'exécutent correctement, et un modèle de synchronisation qui relie modèle de concurrence et modèle mémoire de façon cohérente).

Déjà, il est bon de noter que du à l’architecture, les OS conventionnels ne peuvent tourner sur les 256 cores (l’interconnect ne le supporterai pas).

C'est vrai. En même temps, je ne vois pas pourquoi je voudrais forcément que l'OS tourne sur l'intégralité des cœurs.

Linux tourne sur seulement 4 cœurs, et les autres sont accessibles via une interface particulière, un peu comme on enverrai des shaders sur un gp-gpu ou un firmware sur un microcontrolleur.

Oui, car les quatre cœurs en question sont les seuls à pouvoir gérer les I/O (entre autres).

Donc déjà ça veut dire que vos applications traditionnelles (erlang, go, openmp…) ne vont pas profiter du cluster sans effort.

Oui, il faut utiliser une sorte de dialecte de C/C++ fournit avec le processeur. De ce qu'on m'a dit, programmer efficacement avec n'est pas sans peine. Cependant pour être honnête, c'est aussi vrai pour Cuda/OpenCL/OpenACC/HMPP/ etc. C'est même vrai pour les processeurs Intel/AMD/etc., où sans qu'on sache vraiment quand ni comment, certains aspects micro-architecturaux font qu'une série d'instructions assembleur vont se révéler très efficaces, mais avec la nouvelle version du Core i7 (par exemple), on se retrouve avec une performance unicœur plus pourrie. Pourtant, sur le papier y'a les mêmes specs : 32Kio de L1D, 256Kio de L2, 8Mio de L3 partagé… Sauf que non, le L3 n'est plus un cache avec une file d'attente, il s'agit désormais d'un cache de type NUCA (Non-Uniform Cache Access), donc segmenté, et que désormais la file d'attente est elle aussi segmentée, et … Bref. CUDA est encore pire, car même si on a accès au jeu d'instruction assembleur (PTX), il s'agit d'un langage « virtuel », et d'une carte Nvidia à l'autre la performance d'une séquence d'instructions PTX « optimisante » peut se retrouver « pénalisante ».

Ben en l'occurrence, le Xeon Phi, c'est Larrabee qui arrête de se prendre pour un GPU. :-)

Il y a 50 cœurs sur une carte dédiée pour la première génération (Knight Corner si je me souviens bien), mais la prochaine génération (Knight Landing) devrait être intégrée à un processeur multicœur classique, ce qui réduira évidemment tous les problèmes de latences dus aux transferts sur port PCI. Après, reste à savoir si le premier essai d'Intel sera mieux fichu que celui d'AMD avec le fusion (apparemment ça va mieux avec l'archi utilisée pour la PS4 et la Xbox One).

Le prix est relativement élevé, mais c'est quelque chose d'attendu. Un autre processeur manycore, Tile64 (produit par Tilera, une boite fondée par un prof au MIT), coûte dans les ~12000$ (ça inclut la chaîne de compilation basée sur gcc, la carte d'extension, etc.). Le MPPA est plus ou moins dans le même ordre de prix si je me souviens bien. Il ne faut pas oublier que les processeurs type Alpha étaient aussi très très chers comparés aux x86 dans les années 90.

Le problème est évidemment lié au volume de production. Au début seuls les gens qui ont un réel besoin de ce genre de processeurs (effectivement, les organismes de type CEA/DAM, DCRI, l'armée en règle générale, etc.) peuvent se permettre d'acheter ces trucs. Mais si ces processeurs ont un succès « significatif » dans ces niches, on peut espérer voir des versions plus « grand public » et plus faciles à produire en masse.

Pour aller dans ton sens : je l'ai déjà dit ailleurs, mais les deux « gros » compilateurs pour Itanium 2 sont icc et gcc. Le premier a mis deux ou trois générations avant de générer du code ultra optimisé (à partir d'icc v9.1 en gros, le code devient vraiment bon, avec une bonne exploitation des techniques de pipeline logiciel, la if-conversion, etc.). Le deuxième (gcc donc) génère du code entre deux et dix fois plus lent qu'icc. Pourtant, le modèle machine est bien mieux décrit pour IA64 que pour x64 ou ia32 (c'est nécessaire, vu que le compilateur doit générer tout le code statiquement).

Et en fait, si on regarde les techniques proposées pour accélérer le code sur VLIW, on trouve tout un tas de « contournements » de l'aspect statique pour la génération de code. On peut citer par exemple les techniques de « trace scheduling » (trop complexe à implémenter la plupart du temps) et surtout de « superblocks » et « hyperblocks ». L'idée derrière tout ça est de faire de la compilation guidée par profilage (profile guided optimization) :

1. On compile une première version du binaire et on l'exécute sur un petit jeu d'entrées représentatives.
2. Après avoir instrumenté l'exécution de ce mini-run, on recompile le code en y ajoutant des annotations.
3. Durant la compilation, on va générer plusieurs versions du « chemin chaud » (hou, je préfère la V.O. : « hot path »), ou si on préfère un autre terme, du « chemin critique » en termes de temps passé à calculer. L'idée est de profiter des capacités de spéculation sur les données et sur le contrôle de l'Itanium pour statiquement prédire « prise » l'une ou l'autre branche d'un if/else. La plupart du temps, si le code n'est pas trop irrégulier niveau contrôle, la spéculation sera une chose positive. Pour les rares cas où ça ne l'est pas, on doit rebrancher sur le code original, et « rejouer » toute la partie de code qui avait été spéculée. Évidemment, si on ne se trompe que de temps en temps, le surcoût est négligeable. Si on a mal effectué le profilage, ou si le code est trop irrégulier (ce qui est le cas des codes type compression de donnée, dont le comportement dépend fortement des entrées par exemple), cette optimisation va ruiner les performances.
4. La techniques des hyperblocks est similaire à celle des superblocks, mais rajoute en plus la if-conversion (et là, je renvoie à un truc que j'avais écrit cet été en promettant une suite pour « bientôt » — haha, la bonne blague).

Bref, bien qu'il existe tout un tas de techniques de compilations pour statiquement utiliser au maximum les unités fonctionnelles d'un processeur (VLIW ou pas), ces dernières ont toutes des désavantages liés au fait qu'il faut faire du profilage de code sur tout un tas d'entrées différentes pour avoir une optimisation qui marche « au mieux » dans le cas moyen. Les gens de Firefox (ou Chrome, ou…) peuvent le faire en partie grâce aux informations remontées par les PC d'utilisateurs qui indiquent quel genre de pages ils visitent, etc., ce qui fait que les fermes de compilation peuvent prendre en compte ce genre de trucs, et effectuer de la PGO (profile-guided optimization). À moins de faire de même pour tous les softs utilisés (avec les risques liés à la vie privée que cela comporte, sans parler du flux constant d'information qui ira vers le net et qui accompagnera toute exécution de n'importe quel soft — y compris ls ? ;-) ), ça risque d'être un peu compliqué.

Hum, je suis d'accord avec tes réponses, mais je trouve le « problème » attribué aux VLIW un peu bizarre. Je veux dire, tant que le codage des instructions est le même (en gros, tant que ton VLIW prend le même nombre d'instructions dans une instruction longue), je ne vois pas en quoi il y a un problème de compatibilité binaire. Il y a eu au moins 3 versions de l'Itanium 2, et toutes ont été compatibles au niveau binaire.