Intel et HP prennent résolument le parti de simplifier l'architecture de leurs futurs processeurs, Transmeta va encore plus loin en déchargeant une grosse partie de ce qui est actuellement fait par le matériel sur le logiciel, et l'approche VLIW attire de plus en plus de concepteurs. Au contraire, Alpha et beaucoup d'autres continuent à miser fortement sur les architectures classiques. Qui a raison ? Actuellement, personne... En effet, le processeur le plus attendu, l'Itanium, n'a pas encore vraiment montré son nez. On ne sait pas ce que valent ses performances, même si on sait que celles-ci seront fortement dépendantes du compilateur utilisé, plus fortement encore que pour les architectures classiques. Nous ne reviendrons pas non plus sur toutes les informations et pseudo-informations qui tournent autour du Crusoe, mais nous statuerons que ses performances sont du même ordre de grandeur que celles des x86 d'Intel. En fait, et pour le moment, nous ne pouvons pas dire quoi que ce soit de plus : faute de comparaisons valables, nombreuses et variées, l'architecture classique est celle qui offre le plus de performances (avec l'Athlon 1GHz, disponible sur toute la planète, en tête du classement pour les micro-ordinateurs). Mais certains seront probablement avantagés... Décharger une partie du fonctionnement matériel sur le logiciel est probablement une bonne idée. Actuellement ces techniques sont représentées par des optimiseurs à la volée, du genre des JIT Java. Ainsi l'optimiseur peut adapter le code assembleur aux données qui sont traitées, optimisant là où c'est vraiment nécessaire. Une partie du travail d'adaptation dynamique du code, d'ordinaire laissée au matériel, peut donc être faite purement par logiciel. C'est efficace, mais pas dans tous les cas : les programmes qui bouclent beaucoup en profitent énormément, mais ceux où la quasi-totalité du code est parcourue en permanence demandent beaucoup de travail de recompilation...    Mais remarquons que toutes ces techniques, étant logicielles, sont aussi applicables aux processeurs classiques. Ainsi la majeure partie des avancées qui ont été faites pour permettre à des processeurs simplifiés d'atteindre des niveaux de performance importants peuvent tout aussi bien profiter aux puces que nous avons aujourd'hui dans nos machines. Et sans ces techniques, nos machines délivrent quand même une puissance de calcul appréciable. En fait, et c'est une opinion toute personnelle, il semblerait même que les CPUs actuels puissent plus tirer avantage des améliorations faites dans le domaine de la génération de code que les CPUs simplifiés.    En effet, nos CPUs actuels sont basés sur un langage machine simplifié, alors que les machines simplifiées ont besoin que leur langage assembleur donne plus d'informations sur l'exécution, pour pallier les économies faites sur le matériel. Constatons de plus deux choses : - plusieurs morceaux de code source différents écrits en C ou dans un autre langage de haut niveau peuvent aboutir à l'emploi des mêmes instructions en langage machine. Par contre à partir de ces mêmes instructions en langage machine on est bien évidemment dans l'impossibilité de remonter assurément au code source. Donc au plus le programme assembleur est exprimé à un niveau haut, au plus on a de souplesse dans la compréhension de sa fonction intrinsèque et au plus on peut choisir en confiance une manière optimisée de l'exécuter, ce qui avantage l'assembleur simplifié des processeurs RISC vis-à-vis de l'assembleur beaucoup plus lourd des processeurs simplifiés ; - les JIT existent déjà depuis longtemps, ils ont été popularisés par Java (qui procure des performances en calcul pur équivalentes à des langages compilés tels que le C), mais l'émulateur x86 pour Alpha fonctionne depuis belle lurette de cette manière (et l'Alpha revendiquait même à une époque le titre de machine x86 la plus rapide de la planète). Transmeta a apparemment poussé encore plus loin leurs possibilités, légèrement au détriment de la performance mais largement au profit de la réduction de la consommation électrique), et il semblerait qu'un projet HP, nommé Dynamo, soit de la même veine. Ces techniques s'acclimatent bien de byte-codes simples (Java) ou de codes assembleur plus complexes (x86).    Ma conclusion est la suivante : partant d'un code assembleur simple, ou même d'un byte-code simplifié, les constructeurs de processeurs alliés aux fabricants de logiciels ont apparemment tout loisir de choisir entre deux voies. Soit fournir directement ce code à un processeur hautement dynamique, qui saura réordonner les instructions, faire des prédictions de branchement à la volée, etc., et c'est probablement la solution « haute performance » de prédilection si les architectes de microprocesseurs arrivent à la fois à tenir la cadence de montée en fréquence et à exécuter plus d'instructions en même temps. Soit faire passer ce code dans une sorte de JIT qui saura l'adapter à un processeur plus simple, processeur qui tiendra plus du VLIW que du RISC, et qui sera sensé pouvoir exécuter plus d'instructions à une fréquence plus élevée, si les problèmes mentionnés précédemment ne sont pas résolus de manière satisfaisante. Ainsi, avec un code assembleur plus simple, on se garde la possibilité d'utiliser à plein régime tous les raffinements que les micro-électroniciens peuvent mettre au point, tout en gardant un code de petite taille, et on se garde aussi la possibilité de passer un jour, au cas où, à des techniques différentes. C'est pourquoi les acteurs du monde Alpha, Sparc et PowerPC, pour ne citer qu'eux, semblent envisager l'avenir avec sérénité en ce qui concerne la performance de leurs puces pour les prochaines années.