On Friday 04 August 2006 14:43, [EMAIL PROTECTED] 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 _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
