La conférence ISSCC qui a débuté le 3 février est l'occasion d'avoir enfin des détails sur tous les futurs processeurs qui vont sortir prochainement.
Le site ArsTechnica propose une première analyse du nouveau processeur Sparc de SUN : le Rock.
On sait que Sun a choisi une voie originale avec ses processeurs Niagara 1 et 2. Plutôt que de lutter sur la puissance brute d'un seul coeur d'exécution, les Niagara privilégient la puissance cumulée de plusieurs coeurs (8) et ils masquent la latence mémoire en ayant plusieurs threads par coeur (8). Au final, pour le Niagara 2,on obtient un CPU de 8 coeurs ayant chacun 8 threads ce qui donne 64 threads pour un processeur dissipant à peine 72 watts à 1.4 GHz.
Cette architecture audacieuse a été bien accueillie et Sun se félicite de son choix technique original.
L'ennui c'est que si Niagara est très efficace sur des programmes spécifiques (comme les serveurs web) sa puissance reste faible pour des programmes classiques nécessitant une puissance par coeur plus importante.
La solution de Sun se nomme Rock et il n'est pas moins original que son petit frère Niagara.
Le Rock possède 16 coeurs ayant chacun 2 threads et il tourne à 2.3 GHz. Pour augmenter la puissance par coeur la technique habituelle est d'opter pour l'exécution des instructions dans le désordre (Out-of-order) et Sun aurait pu se contenter de ça : prendre un Niagara (in order) et lui ajouter le out-of-order. L'ennui c'est que le OOO est très compliqué : il faut consacrer beaucoup de transistors au suivi des instructions puisqu'elle peuvent se balader dans tous les sens. En plus comme la fréquence des CPU est très supérieure à celle de la RAM il faut consacrer aussi beaucoup de transistors au masquage des latences. Sun a donc décidé d'utiliser une nouvelle technique : le scout thread.
Ce thread "de reconnaissance" est l'un des deux threads qui s'exécutent dans chaque coeur et, quand le premier thread est bloqué par un accès mémoire lent, il continue a exécuter les flot d'instruction du programme !
Le premier thread est sauvegardé dans un checkpoint (un registre fantôme) et le thread de reconnaissance (totalement transparent pour le programme ou pour l'OS) continue son travail et sauve les résultats dans une mémoire très rapide (SRAM).
Quand le premier thread a enfin reçu les informations venant de la RAM lente il peut rattraper son retard en se servant directement des résultats sauvés dans la SRAM au lieu de devoir exécuter les instructions du programme.
Si le scout thread est bloqué lui aussi par un accès mémoire alors le thread principal lui "saute par dessus" et devient le scout thread a sa place !
L'article d'ArsTechnica explique très bien toute cette machinerie.
Cette architecture originale à l'avantage de ne nécessiter aucun travail d'adaptation des programmes et devrait permettre à Sun d'augmenter considérablement la puissance par coeur de ses CPU.
Le désavantage c'est que tous les registres fantômes utilisés dans les checkpoints et tous ces scouts threads qui s'exécutent en permanence grèvent le budget énergétique. Un Rock cadencé à 2.3 GHz et gravé en 65 nm dissipe 250 Watts !!!
Il est à noter également que Sun n'a évidemment pas tout dévoilé de son nouveau bébé. On parle beaucoup d'un support hardware de la notion de mémoire transactionnelle. C'est un nouveau modèle qui permettrait d'exécuter des tâches en parallèle sans avoir à gérer toutes la complexité des verrous et les risques de bugs d'interblocage.
Comme l'affirme David Yen, le boss des CPU chez Sun, il n'est pas possible de lutter contre Intel sur le plan de la finesse de gravure car ils sont les plus fort. il faut donc innover coté architecture. Rock va donc avoir des "fonctionnalités qui jusqu'à présent n'existaient que dans des publications académiques" et on peut s'attendre a d'autres révélations très bientôt.
Journal Sun Rock : Les détails arrivent
5
fév.
2008
# #
Posté par Bruce Le Nain (site web personnel) . Évalué à 10.
Merci pour toutes ces infos
[^] # Re: #
Posté par patrick_g (site web personnel) . Évalué à 10.
On y trouve notamment cette phrase a propos du support hardware de la mémoire transactionnelle : "Sun is working to create a consortium that would define an application programming interface for its implementation of atomic transactions and make the API available as open-source software. Sun is also developing a simulator for its approach that will be released as open-source software".
[^] # Re: #
Posté par Val1472 . Évalué à 3.
Merci.
[^] # Re: #
Posté par Marc Quinton . Évalué à 4.
[^] # Re: #
Posté par patrick_g (site web personnel) . Évalué à 10.
L'ironie se voit trop maintenant. J'avais pourtant bien dit que vous ne seriez payés que si c'était subtil.
[^] # Re: #
Posté par Putifuto . Évalué à 6.
C'est avec un plaisir non dissimulé que j'ai lu avec attention ton journal.
Ton sens du phrasé et de la synthèse font de toi un contributeur hors pair que nous envie des sites prestigieux comme http://windowsfr.org ou http://www.trollfr.org
Je sais même de source proche du ministère de l'éducation que tes textes sont étudiés en classe Techno du lycée du Mesnil Esnard.
Peut-être pourrais-tu nous rédiger une news cinéma sur le nouveau Asterix ?
[^] # Re: #
Posté par patrick_g (site web personnel) . Évalué à 3.
Tant que j'ai pas la légion d'honneur et le prix Nobel pour l'ensemble de mon oeuvre je ne fais plus rien. Na !
[^] # Re: #
Posté par nonas . Évalué à 5.
Circular dependencies :-(
[^] # Re: #
Posté par windu.2b . Évalué à 5.
[^] # Re: #
Posté par Dup (site web personnel) . Évalué à 7.
# prévoir climatiseur...
Posté par aedrin . Évalué à 3.
à quoi rime cette course à l'armement sur la fréquence CPU ?
après c'est pas étonnant de se retrouver avec des alims de 1000w et 6 ventilateurs par tours...
moi qui pensait (ou espérait ;-( ) que le ratio fréquence/tdp allait devenir à la mode ces temps-ci...
le jour où ça commencera à rentrer dans les moeurs, les architectures prendront compte de la consommation au moment de leur conception
[^] # Re: prévoir climatiseur...
Posté par patrick_g (site web personnel) . Évalué à 4.
"We decided what mattered was power efficiency more than overall power"
[^] # Re: prévoir climatiseur...
Posté par CrEv (site web personnel) . Évalué à 4.
La course à la fréquence ok, mais ça n'explique pas uniquement la puissance dissipée je pense...
[^] # Re: prévoir climatiseur...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: prévoir climatiseur...
Posté par Troy McClure (site web personnel) . Évalué à 4.
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=31(...)
Si le prix est honnete y'aura surement moyen d'en faire des choses assez sympa !
[^] # Re: prévoir climatiseur...
Posté par Maclag . Évalué à 3.
S'il abat plus de boulot que 10 procs à 32W, alors on en sort gagnant tout de même!
[^] # Re: prévoir climatiseur...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# "scout" thread ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour faire plusieurs threads sur un meme core, il y a plusieurs techniques. La plus simple (genre PS3 et XBOX360), c'est que chaque threads envoie executre une instruction sur 2 par cycle.
Une version plus complete n'est pas de remplir le fectcher une fois sur 2, mais d'utiliser toutes les unites, c'est le SMT d'intel.
Je ne vois pas vraiment de difference entre la solution d'intel et celle de sun.
"La première sécurité est la liberté"
[^] # Re: "scout" thread ?
Posté par castorpilot . Évalué à 3.
Apparement, les threads du Rock sont completement transparents pour le programmeur. Ils sont crées par le processeur directement. Donc un programme "classique" devrait pouvoir en beneficier.
Pour le SMT, si je me souviens bien, il faut quand meme explicitement avoir 2 threads au départ.
[^] # Re: "scout" thread ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ou alors, il s'agit de technique ou un thread d'assistance est cree a cote du thread principal en ayant pour but de faire du prefetch de cache intelligent.
"La première sécurité est la liberté"
[^] # Re: "scout" thread ?
Posté par khivapia . Évalué à 4.
Alors, le premier se met en sommeil et le deuxième thread continue ce qu'il est possible de faire du premier sans utiliser ces données (par exemple, quelques unes instructions suivantes ne font pas tout de suite appel aux données manquantes et peuvent être calculées pendant ce temps ; mais il s'agit également de calculer des adresses de sauts (prédiction de chanchement), du chargement des instructions suivantes, du prefetch de cache). Elles n'ont pas besoin d'être recalculées ensuite par le thread initial, qui dès qu'il aura récupéré la donnée de la mémoire, pourra utiliser immédiatement les précalculs effectués par le thread de surveillance et continuer sa tâche.
Toutes les instructions qui n'ont pas pu être exécutées car dépendantes de la donnée manquante sont chargées dans une file qui sera parcourue par le thread principal quand il aura obtenu ses données. Les autres peuvent être exécutées tout de suite.
C'est une sorte d'out-of order simplifié : l'out-of-order traditionnel cherche à effectuer tout de suites les instructions dont les opérandes sont immédiatement disponibles, et à conserver les résultats. Cela revient à se dire : "j'ai telle et telle donnée en registre, qu'est-ce que je pourrais faire avec avant de les envoyer dans le cache ou ailleurs pour faire autre chose ? Y a-t-il une instruction qui les utilise quelque part dans la suite, et que je pourrais faire tout de suite pour gagner du temps après ?"
Alors qu'ici, l'approche serait plutôt : "Il me manque une donnée. Dans le flot d'instructions, quelles sont les instructions suivantes qui n'en dépendent pas et que je peux effectuer en attendant ?"
(et mon avis personnel serait qu'idéalement le travail d'ordonnancement des instructions soit fait par le compilateur. En effet, il devrait pouvori déterminer lui-même quelles sont les instructions qui ne dépendent pas d'une autre, et prévoir quand les fautes de cache arrivent.)
[^] # Re: "scout" thread ?
Posté par Ontologia (site web personnel) . Évalué à 5.
Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.
Alors après, comment gérer le multitâche, la gestion d'état de celui-ci ? Je ne sais pas jusqu'où le compilateur peut aller, mais surement beaucoup plus loin qu'actuellement.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: "scout" thread ?
Posté par M . Évalué à 4.
Parce qu'il faut regarder les choses en face : plus ça va, plus de transistors sont utilisés pour "réécrire" du code mal écrit par le compilateur. Tous ces transistors consomment, et n'exécute pas du code, et mis ensemble permettrait surement de faire un coeur de plus, un dsp, du cache supplémentaire, que sais-je....
Regardes le succès des RISC par rapport au x86 (qui est compatible avec une archi de plusieurs dizaine d'année).
Un bon compilateur, du moment qu'il sache avec exactitude quel processeur cible il doit attaquer, est capable de préparer le out-of-order lui même.
Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...
[^] # Re: "scout" thread ?
Posté par Sachiel . Évalué à 1.
J'ai plutôt tendance à avoir une vision visant à donner plus de boulot au processeur justement. J'ai l'impression qu'il est plus à même de déterminer ce qui est le plus rapide pour lui au moment de l'exécution. Tout décharger sur le compilateur me parait assez utopique.
Après je ne suis pas un spécialiste non plus, ça vaut ce que ça vaut hein..
[^] # Re: "scout" thread ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
L'IA64 ne fait en effet rien et se repose sur le compilo. Les resultats ne sont pas genial certe.
Concernant le succes du RISC, j'ai des doutes. x86 archi domine.
Sinon le probleme d'un compilateur c'est tout ce qui est data dependant. Il faudrait creer plusieurs chemin de code selon les donnees. C'est ce qui donne l'avantage au compilo just in time dans certain cas.
"La première sécurité est la liberté"
[^] # Re: "scout" thread ?
Posté par Ontologia (site web personnel) . Évalué à 4.
Certes, mais reconait que les compilo sont assez nuls pour le moment... Ca fait combien de temps que GCC sait faire une analyse de flot du pauvre ?
C'est sure que faire de l'analyse de flot avec un langage comme C, c'est assez utopique
Oui peux être dans un contexte monotache genre dsp, mais dans un contexte multitâche le compilo ne maîtrise pas du tout ce qui est en cache, quand le flow va être interrompu par un context switch, ...
Bah justement, c'est là qu'on pourrait utiliser les archi multi-coeur, pour éviter au maximum de faire des contexts switch... Quand on a 8 coeurs, et bientôt le double, voire le quadruple, on a quand même la possibilité d'y penser. Surtout que c'est une tendance qui va s'installer dans les années à venir.
Et de toutes façon, je peux t'assurer que de manière général, et sans se spécialiser sur un processeur, il y a beaucoup de choses à faire niveau compilation.
Je me suis amusé, sur du code C à jouer à intervertir certaines instructions commutatives dans des boucles critiques (merci gcov) pour mutualiser les read/write. Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable : La plupart des processeurs du marché vont 10 fois plus vite que la mémoire, et gérer ça, ça peut énormément aider..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: "scout" thread ?
Posté par M . Évalué à 2.
Si tu as utiliser gcov, tu as donc fait des optimisation au runtime, chose que le compilo ne sait pas faire.
Par contre ça pourrait être fait par le processeur ou une machine virtuelle.
De plus le C est très complexe à optimiser (les informations de ce que faire le programmeur sont très pauvre). Du coût la plupart du temps l'optimisation d'un code C reflète son codage
Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable
d'ailleurs un code C "optimiser" pour X86 peut être une grosse bousse sur une autre archi.
[^] # Re: "scout" thread ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu as un exemple ?
"La première sécurité est la liberté"
[^] # Re: "scout" thread ?
Posté par benoar . Évalué à 3.
Par contre, je n'aurai pas parlé de "thread" parce qu'a part le mode de fonctionnement, ca n'a rien a voir avec un thread classique d'un OS (puisqu'il est invisible a l'OS...).
Bizarrement, Intel va sortir un processeur in-order prochainement, le silverthorne : http://www.hardware.fr/news/9385/silverthorne-retour-hyperth(...)
Et leur solution pour améliorer les problemes dus a cette approche (on avait pas vu un x86 in-order chez intel depuis le pentium MMX !) ils ont choisi l'approche hyper-threading : ca sera un peu le meme principe que pour le Rock (OOO simplifié), sauf que la partie scheduler sera gérée par l'OS (puisqu'il voit 2 core virtuels) et que c'est limité a 2 "threads" au lieu de 8 ici. Je pense que c'est vraiment l'intéret ici, plutot qu'éviter les problemes de vidage du pipeline dus aux mauvaises prédiction de branchement, comme c'était le cas pour le P4, car ici ce processeur a un pipeline plutot court (16 étages) comparé au P4 (l'HT a été créé pour le P4 rappelons-le, et n'a jamais été utilisé sur l'archi Core, il me semble).
[^] # Re: "scout" thread ?
Posté par castorpilot . Évalué à 2.
"This scout thread (ST) is a hardware entity that's totally invisible to the operating system, hypervisor, or whatever else has control of the processor, and in the course of execution it predicts and resolves branches, prefetches code and data, and saves its speculative state in a shadow register file."
@khivapia: ton avis personnel ressemblerait plus à du VLIW non ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.