Evolution du K8

[Mei]

c'est pas un CPU a orientation calcul scientifique donc c'est hors contexte. Mais avec un Quad Core on peut faire ca Speculation Multi Threading + verif remarque

[fennec]

Il faudrait un troisième core pour savoir qui à raison :/ Peut être que la Xbox360 a un avenir dans la calcul scientifique ? ou pas

[deltaden]

Je ne sais pas comment ça marche pour les Itanium, mais les processeurs de mainframe d'IBM font ça aussi en interne (c'est pas deux core séparés) et à ce que je sache, quand les résultats sont différents, le processeur revient en arrière d'un certain nombre d'instructions et les réexécutent. Si c'est encore différent le processeur s'auto-déclare fautif, le signale à l'OS et est désactivé. A ce point là, l'OS active un processeur de secours qui reprend la main. Une fois le processeur fautif remplacé, le processeur de secours sera déconnecté de nouveau, en attente. Tout cela sans arrêt de l'OS et d'aucun programme bien entendu :jap:

Sinon, ce genre de technique n'est pas vraimet utilisé pour du calcul scientifique, ce serait du gaspillage inacceptable de ressources, c'est pour des applications où la fiabilité prime avant tout le reste (typiquement la gestion de systèmes banquaires...). L'architecture d'un mainframe ou d'un serveur non-stop d'HP est assez différente d'un supercalculateur ou autre cluster de calcul.

[Neo_13]

est-ce parce que c'est pas possible que ça n'est pas utilisé, ou parce que c'est pas utilisé qu'on ne l'a pas prévu?

[deltaden]

Une erreur de calcul dans le processeur est quand-même hautement improbable, s'il y en a une, ce serait plutôt dans la cache ou en transferant des donnés sur le bus; deux zones protégées par ECC. Se prémunir contre ce genre de problème est vraiment pour des applications critiques qui doivent être à toute épreuve.*

Si tu es responsable d'un centre de calcul intensif qui vient de faire l'acquisition d'un supercalculateur contenant 2000 CPU, va tu vraiment vouloir utiliser la moité de ceux-ci pour vérifier ce que fait l'autre moitié? En sachant que les calculs qui tournent dessus prennent sans doute des jours/semaines/mois pendant lesquels les utilisateurs attendent les resultats?

Si c'est une plus petite machine/des calculs plus cours, tu peux de toute façon relancer tes calculs une seconde fois pour vérifier ;-)

Donc en gros, que croit qu'il s'agit plutôt de "peu de systèmes sont capables de faire ça car c'est rarement nécessaire".

*Dans le genre "toute épreuve", cette vidéo d'HP est sympa, elle montre un serveur de stockage capable de résister à la destruction de la moitiée de ses cartes électroniques:
hp

PS: maintenant, je n'ai pas vraiment une grande expérience dans ces applications critiques où on utilise cela, donc pour plus de détails, faudra sans doute demander à qlq d'autre.

[jihef]

Je cois que je vais postuler chez HP. Ils ont l'air de bien s'amuser.

[The_ED]

Une erreur de calcul dans le processeur est quand-même hautement improbable, s'il y en a une, ce serait plutôt dans la cache ou en transferant des donnés sur le bus;

Je lisais dans la Recherche que justement un transistor pouvait changer spontannément d'etat. Ce qui reste très rare quand meme.

Je me posais la question de justement comment pouvais t'on gerer ce genre d'erreur, je crois que deltaden a apporté la reponse à ma question.

PS: Pour HP j'adore l'avertissement à la fin de la video :D

[fefe]

Il y a beaucoup d'etudes faites la dessus. En dehors de zones particulierement radio-active les chances qu'un transistor changent spontanement d'etat (parce qu'il s'est pris un neutron ou une aprticule alpha) sont extremement faible. Et meme si il y a un transistor 1 fois par an dans ta machine qui change d'etat il est encore moins probable que l'etat de ce transistor ait ete important pour ton programme (typiquement tout ligne de cache en I-state, dans un bloc fonctionnel inactif etc...). Et finalement aujourd'hui plus de la moitie des transistors critiques dans la machine sont proteges par une forme de CRC ou d'ECC.
Il existe des systemes ou 1 erreur en 10 ans de fonctionnement est une catastrophe, donc des systemes redondants (mixtes software-hardware) sont mis en place, mais dans la majorite des cas cela n'a pas d'importance.

En revanche la probabilite de ce type d'erreurs augmente avec la miniaturisation des procedes de fabrication et la reduction des tensions appliquees. Cela force en general les constructeurs a proteger toujours plus de structures par de l'ECC pour garantir un taux d'erreur acceptable par la majorite (les banques utiliseront toujours des systemes redondants au cas ou).

Link vers un papier sur le sujet: http://www.cse.psu.edu/~mdl/paper/vlsifinal.pdf

[^M^]

Un très bon papier sur l'avenir du K8 : http://www.pureoverclock.com/article37.html

Pas grand chose de nouveau, mais c'est bien documenté.

[jose99m]

Personne n'a jamais eu besoin d'un controleur memoire integre pour construire des systemes SMP, ni meme des systemes SMP qui scalent tres bien.

Les interconnections entres processeurs et de disposer de suffisament de controleurs pour avoir une bande passante importante sont ce qui compte et sont idependants de l'integration du controleur memoire.

C'est un amalgame qui a ete fait parce que les systemes a base de K8 scalent bien en SMP, mais tout le monde semble oublier qu'il y a beaucoup d'autres systemes qui scalent jusqu'a plusieurs 100aines de processeurs en SMP sans controleur memoire integre.

C'est tout de même un gros plus, il ne faut pas exagèrer !

[Neo_13]

C'est tout de même un gros plus, il ne faut pas exagèrer !

je suis pas d'accord... le controleur intégré sert à rien pour le smp... la communication intercpu ne passe pas par là...

Par contre, c'est un plus pour le cpu...

[EPIC]

Effectivement ça serait plutôt les liens hypertransport qui faut remercier dans une config SMP...

[fefe]

C'est tout de même un gros plus, il ne faut pas exagèrer !

Sur un systeme avec un nombre massif de cpus l'apport du controleur memoire integre est entre negligeable et nul. L'architecture des interconnexions lui a un impact majeur.

Pour m'expliquer un peu plus tu gagnes 20 a 30 ns sur un acces memoire qui te coute ~75ns sur un single socket presente une amelioration de perf significative de l'ordre de 5 a 10% en moyenne pour un gain de 30+% en latence memoire.

Sur un systeme massivement parallele (par exemple 32 sockets) avec la memoire distribuee, ta latence memoire moyenne sera dans les 180ns, avec certains acces pouvant depasser les 250ns. Enleve 20 ou 30ns sur ce total grace a un controleur memoire integre et cela devient evident que l'impact sur la performance est moins important que la qualite de l'interconnexion entre les sockets: le nombre de hops a traversers avant d'arriver a la memoire, et la bande passante disponible sur ce reseau d'inteconnection (et l'efficacite du routage).

Les systemes Intel actuel ont probablement le systeme d'interconnexion le pire qui existe: un bus ou ils tendent a partager un ou peu de controleurs memoires. Alors que les systemes AMD utilisent du routage point a point (avec une bande passante agregee tres superieure au bus d'Intel) et chaque ajout de core ajoute de la bande passante memoire (effet indirect de l integration du controleur memoire, mais on peut y arriver sans l'integrer).

Au final les systemes AMD scalant tres bien, la fausse impression que leur scaling etait du au controleur memoire integre s'est rependue. Le scaling est du essentiellemnt au choix d'Hypertransport.

[jose99m]

Le contoleur HT est intégré également
Et le contrôleur mémoire est bien pratique pour que chaque cpu accède en direct à sa mémoire sans partager un quelconque bus mémoire avec quelqu'un d'autre

Tout çà va de pair me semble t il.

[fefe]

Tout çà va de pair me semble t il.

Justement cela ne va pas necessairement de pair, c'est parfaitement logique de le faire (c'est ce qu'ont fait Dec sur l'ev7 et AMD sur les K8) mais rien n'empeche d'integrer le controleur HT et pas le controleur memoire. Bien entendu pour un systeme monosocket ce n'est pas une bonne option, pour un systeme multisocket cela peut fournir plus de flexibilite pour le choix des controleurs memoire pour un impact sur la performance negligeable (a condition que les liens HT qui vont au controleur memoire sont suffisants).

[Franck@x86]

Voilà aussi pkoi le K8 ne bénéficie que "peu" de la DDR2, enfin tant que celle-ci ne disposera pas de timings aggressifs. Quand le K8 accède à la mémoire, le temps cpu <-> contrôleur est très faible, donc si la cuisine interne des modules occupe disons 90% du temps total d'accès, les timings lents auront une influence plus important que si ce temps n'occupait que 70% (dans le cas d'un contrôleur externe)(je donne ces chiffres au pif, pour illustrer). Tout est histoire de proportion.

Intel semble davantage miser sur les caches pour masquer les latences d'accès à la mémoire, et force est de constater que c'est assez efficace également. Dans ce cadre, un contrôleur intégré n'aurait pas forcément un impact incroyable sur les performances. Enfin y'a pas longtemps j'ai lu une news qui parlait d'un éventuel contrôleur intégré sur un futur processeur Intel, à voir donc !

[Neo_13]

Le contoleur HT est intégré également
Et le contrôleur mémoire est bien pratique pour que chaque cpu accède en direct à sa mémoire sans partager un quelconque bus mémoire avec quelqu'un d'autre

Tout çà va de pair me semble t il.

oui, mais si le cpu n°1 veut une donnée qui est dans la ram du cpu n°5 ? un hop vers le 2, un hop du 2 au 3, un hop du 3 au 4, un hop du 4 au 5, un accès ram...

Enfin y'a pas longtemps j'ai lu une news qui parlait d'un éventuel contrôleur intégré sur un futur processeur Intel, à voir donc !

ça aura un impact, mais probablement pas transcendant... en un 1S..