[gull] Linux sur processeur Core Duo?

[Daniel Cordey]

On Friday 04 August 2006 13:44, Marc Mongenet wrote:

> Notons toutefois que l'architecture x86-64 a 2 fois plus de registres
> que l'architecture x86. Cela donne un gain de vitesse de quelques
> pourcents, voire quelques dizaines de pourcents.

Ce serait merveilleux si la simle adjonction de registres pouvait donner des 
gains de plusieurs dizaines de pourcents... Plutot que de doubler la vitesse 
d'une generation de processeur, il suffirait de mettre assez de registres a 
disposition pour doubler sa vitessee... Helas, tois fois helas, il n'en est 
rien. A moins d'avoir une application tres specifique qui beneficierait d'une 
augmentation du nombre de registre, au point de faire un bon en performance, 
le gain est malheureusement tres limite. Les applications dont je parle sont 
surtout des applications de caculs dont 99% du temps se passes dans quelques 
fonctions... Alors, oui, dans ce cas, il est possible d'obtenir des gains 
importants.

Depuis pret de 20 ans, on n'a cesse d'augmenter le nomber de registres et d'en 
augmenter la taille. Les exemples ou, en doublant le nombre de registres, en 
augmentant la cache, changeant le mode d'acces de celle-ci (ex: un cycle de 
moins pour acceder a une cache niveau 2), tunant le compilateur, augmentant 
la vitesse du bus memoire et celle du CPU... on a finalement obtenu un gain 
de moins de 50% sont nombreux. Dans le tuning des processeurs, cela fait 
longtemps que l'on sait que le meilleur booster de performance est 
l'augmentation de la taille de la cache principale, pas l'augmentation du 
nombre de registre. L'augmentation simple du nombre de registres offre des 
gains de 2-3 % en general. Ceci est une valeur statistique basee sur les 
processeurs RISCS des 20 dernieres annees.

Aussi, le passage de 32 a 64 bits a ete l'occasion de leurer les utilisateurs 
avec le nombre de registres. C'est tres simple... si vous disposez de 32 
registres memoires en 32 bits, et que vous desiriez offrir un processeur 
compatible en 64 bits, il vous faudra disposer aussi de 32 registres en 64 
bits. Or, pour assurer la compatibilte en 32 bits (et pour des raisons de 
techniques internes), on doit pouvoir conserver l'acces a ces registres 32 
bits. Pour eviter d'avoir 32 registres 32 bits + 32 registres 64 bits, chaque 
registre 64 bits est en fait constitues de 2 registres 32 bits... accessibles 
separement. On a donc bien doubler le nombre de registres 32 bits, mais pas 
celui des registres 64 bits. Si l'on tient compte qu'en mode 64 bits, on 
download dans la cache des paquets deux fois plus gros, on s'apercoit que la 
charge sur le bus memoire et la cache est deux fois plus important !!! Les 
explications concernant l'impact sur les performances ont ete clairement 
expliques sur les processeurs RISCS depuis 20 ans par HP, IBM, SGI, etc. 
Toutefois, le public cible des processeurs *86 etant moins pointu, jen n'ai 
jamais vu d'explication claire et non ambigue de la part d'Intel et AMD 
lorsqu'il sortaient un nouveau modele... au contraire, c'est l'ecran de 
fumee... et la desilusion systemaqtique. COntrairement a HP, IBM, SUN, etc. 
Intel ne sort pas forcement un processeur pour offrir clairement 30% de 
performances suplementaires, mais pour des raisons qui sont propres au 
marketing d'Intel et AMD... parfois, il s'agit simplement de consommer moins, 
parfois on essaie de reduier les cout de productions, etc. Il est rare que 
l'un des deux sorte un CPU pour aller vraiment plus vite est explique 
clairement comment il a atteind cet objectif. Sans doute ont-ils peur que 
l'on realise que les autres modeles encore en vente sont a jeter... Intel et 
AMD sont parfaitement au courant des faiblesses et des atouts du concurent. 
Chacun se garde bien de deterrer la hache de guerre...

dc