[gull] x86_64

[Marc Mongenet]

Le 05/06/06, Marc SCHAEFER<schaefer at alphanet.ch> a écrit :
> On Mon, Jun 05, 2006 at 09:33:38AM +0200, Daniel Cordey wrote:
>
> Je ne connais pas les détails techniques, mais je me demande une chose:
>
>   si tout à coup *tous* les processeurs actuels Intel et AMD avaient
>   simplement un core justement *très* similaire (le truc qui exécute les
>   instructions ``RISC'' longue taille (VLIW)).
>
>   et par-dessus, il y aurait une unité de transcodage des instructions
>   du jeu 8088, x86 et x86_64.

C'est vrai que les noyaux de processeurs ne semblent plus
beaucoup évoluer. Ce n'est pas par manque de transistors
disponibles, mais plutôt parce qu'ajouter encore une ALU de plus
ou des étages de pipeline de plus, ne permet plus d'augmenter
sensiblement les performances (law of diminished returns).
En revanche, la consommation électrique augmente
sensiblement.

Enfin, pour l'instant, les noyaux des CPU sont encore assez
différents. Mais qui sait, avec la multiplication du nombre de
noyaux par processeur, les noyaux eux-mêmes seront
peut-être de plus en plus simples et finiront par se
ressembler beaucoup. Ça me paraît toutefois une éventualité
trop lointaine pour être prévisible.

Il y a malgré tout encore beaucoup d'innovations.
Par exemple il me semble que les processeurs de
Transmeta exécutaient leurs propres instructions et
faisaient en fait fonctionner un émulateur
(de x86 puisque c'était le plus grand marché).

Peut-être va-t-on aussi voir arriver des processeurs sans
horloge?

> Pour les fabricants, cela signifierait qu'une même `fonderie' pourrait
> produire les mêmes processeurs, et que seule la dernière couche tout en
> haut (qui, depuis le Pentium II est programmable après-coup: le microcode)
> devrait être changée.

Pour les années à venir, c'est la guerre au niveau des fondeurs
(Intel vs AMD-IBM) pour réduire la tailles du gravage (Intel a de l'avance).
Mais il me semble qu'il y a de moins en moins de fondeurs
indépendants, à cause du prix des usines ("only real men have fabs")

> Si cela est vrai (ou approchant, p.ex. par constructeur, voire par famille),
> cela signifierait qu'on aurait eu, nous le monde des logiciels libres, plus
> d'intérêt à avoir accès directement au VLIW, sans passer par cette
> couche de compatibilité x86 ou x86_64: modulo de bons compilateurs, le
> travail est forcément plus efficace qu'une couche matériel -- car il
> est fait à l'avance (pour les langages réellement compilés).

Logiquement (en fait j'en sais rien :-), les micro-instructions VLIW
internes sont adaptées à chaque noyau, donc incompatibles d'une
génération de processeur à l'autre.

C'est même peut-être un avantage des CISC :
un jeu d'instruction compacte qui n'encombre
pas les mémoires (disque, RAM, cache), et qui est transformé
en des instructions parfaitement adaptées au noyau de chaque
processeur. Bref, le code x86 n'est plus qu'un bytecode. D'ailleurs
le Pentium 4 a un cache L1 de micro-instructions, on peut donc
dire qu'il fait de la compilation JIT (just-in-time). :-)

Il faut encore noter à propos du JIT que le travail fait à l'avance
(par un compilateur) n'est pas forcément toujours plus efficace.
Les observations faites à l'exécution peuvent permettre des
optimisations dynamiques qui rendent une émulation plus
efficace qu'une exécution directe. Cela dit les compilateurs
permettent d'utiliser le résultat de code profilé pour recompiler
en tenant compte d'observation faites lors d'une précédente
exécution. Tiens, il faut que j'essaie ça avec GCC...

Marc Mongenet