[gull] Linux sur processeur Core Duo?

[Daniel Cordey]

On Friday 04 August 2006 14:43, vkeller at bluewin.ch wrote:

> j'avoue apprécier cette discussion HW orientée CPU. Mais ce n'est
> malheureusement qu'une - petite - partie du problème.

Oui, et la notion d'architecture ne se limite pas seulement a celle du chip 
CPU ! Il faut aussi compter avec le chipset et celle du MMU (souvent integre 
au chipset). Les chipset evolues pour des systemes multi-cpus sont tres 
chers... Dans le cas de l'acces a la memoire, le MMU doit etre tres evolue 
lorsque l'on veut acceder a de grands espaces memoires (>4 GB). Dans ce cas, 
il se peut que les performance sur un seul petit programme ne soit pas bon 
vis-a-vis d'un simple Pentium avec un bon FSB. Par contre, en environement 
massivement multi-tache et grosse memoire, l'architecture Pentium se 
fera "scocthe"... 

> Le choix de 
> telle ou telle architecture doit forcément être orienté par le type
> d'application que l'on désire exécuter. Et dans ce domaine, cela va
> du tout au rien.

On parle alors d'architecture du systeme dans son ensemble, pas seulement du 
processeurs.

> Si l'on a la chance de pouvoir maîtriser les 
> sources, alors on pourra tester différents compilateurs, différentes
> bibliothèques et évidemment différentes architectures (et je vous
> assure que les résultats sur des applis réelles ont parfois peu de
> choses en commun avec les benchs "intellisés" à la SPECINT2K), 

Les benchmarks SPECs ont ete developpes a la fin des annees 80 (les premieres 
versions) pour differencier les differents processeurs RISCs de l'epoque. Ils 
font partie de ce que l'on appelle les "toy benchmarks". Cela veut tout dire.

Depuis, des SPECs behcmarks ont aussi des tets plus significatifs comme les 
SPECweb et des benchmarks base de donnees (TPC*). Ceux-ci sont nettement plus 
representatifs mais peuvent difficilement etre reproduits par le commun des 
mortels, vu la complexite et le prix de l'infrastructure de ce qui est teste.

> dans 
> le cas contraire, le choix architectural doit être dirigé par le type
> d'application considérée (eg le type de problème résolu,
> l'algorithmique, etc...).

Surtout, le type de contexte. Serveur de calcul, de DB, de fichiers/baqckup, 
web, etc.

> Finalement concernant la fréquence des processeurs, trivialement
> seules les appli qui utilisent intensivement le cache ont une chance
> d'utiliser ces PE clockés - stupidement - à plus de 3.5 GHz (peut-
> être que les Microsofteries sont de ce type-là), mais dans
> l'écrasante majorité du calcul scientifique, le bottleneck se situe
> au niveau du FSB.

Dans le domaine du calcul scientifique, les architectures ayant plusieurs 
unites logiques (travaillant en //) sont privilegiees. Ce qui permet a des 
processeurs fonctionnat a 1 GHz d'etre plus rapide dans certains domaines que 
d'autres a 3 GHz. Ceci est visible dans le domaine HPC (High Performance 
COmputing).

Le FSB est important mais d'autres facteurs entrent en ligne de compte. Le 
domaine du calcul par elements finis requiert l'acces a de tres grosse masses 
de donnees que les architecture Intel/FSB gerent tres mal. 

> J'ai fait il y a quelques mois des tests sur mon laptop, passer la
> fréquence du CPU de 2GHz (f_max) à 800 MHz (grâce à la SpeedStep
> Technology) fait perdre de l'ordre de 10 % les performances des
> apps.

Oui, c'est assez significatif et demonstratif de la stupidite des messages 
markting dont on nous bombarde.

> Et lorsque l'on sait que l'énergie consommée par un processeur va
> avec sa fréquence au carré (à quoi il faut ajouter le cooling), soit
> un gain d'un facteur 6 (rien que pour le processeur), on comprend
> mieux pourquoi Intel a changé sa stratégie de développement. En ce
> sens, le Woodcrest avec son FSB à 1333 MHz pour deux PE bi-Core est
> très prometteur (les premiers tests le prouve d'ailleurs).

N'oublions pas que dual-core represente deux CPUs... si chacun d'eux a un gros 
apetit pour les donnees, on se retrouve tres vite avec un bus memoire 
completement sature. Il faut donner a "manger" les "instructions" + 
les "data" a deux CPUs... et non un seul.  Un FSB a 1333 MHz peut paraitre 
impresionnant... mais ce n'est, au mieux, que l'equivalent d'un seul bus a 
666 MHz pour un CPU... Tout compte fait, rien d'extraordinaire. Il faut 
savour que si Intel n'avait pas augmenter la vitesse du FSB et l'avait laisse 
a 800 MHz, nous aurions alors l'equivalent d'un FSB a 400 MHz par CPU. Intel 
n'avait donc pas le choix sinon les performances auraient ete ridicules et 
personne n'uarait compris tout ce bruit... AMD avec son quad core est encore 
plus ennuye... il faudrait l'equivalent d'un FSB a 2.6 GHz pour que chaque 
processeur puisse fonctionner au mieux (idealment il faudrait 3.2 GHz). Or, 
un bus memoire a 2.6 GHz... doit faire ricanner les ingenieurs d'Intel. Il va 
donc falloir developper des Core avec des caches de plusieurs dizaines de 
MB... dure, dure... Pour cela, il faudra attendre de pouvoir fabriquer des 
chips en technologies 45 nanos... On a le temps...

EN attendant Intel et AMD vont nous balancer des CPU N-cores qui ne 
fonctionneront pas du tout de maniere optimum et offriront des gains de 
performances largement inferieurs a ce que l'on pourait en attendre.

dc