Micro-Architecture

[Tramb]

Les predicteurs fonctionnent en faisant des statistiques, si tu réordonnance ton code pour "coller" aux statistiques tu triches, en fait tu as fait à la main ce que le predicteur aurait du calculer.

C'est pas de la triche, c'est exactement ce que tu fais quand tu améliores les patterns d'accès mémoire alors que tu pourrais faire confiance aux caches : t'es quand même bien content de les aider, les caches.
Les streams non temporels, les instructions de contrôle de cache et les instructions de prefetch soft prouvent bien que les concepteurs de CPU reconnaissent que de l'information externe à leur système peut améliorer la performance de code s'exécutant sur leur archi.

[DaP]

En l'absence d'entrée dans l'historique le CPU a bien une heuristique statique pour se décider (les branches ne sont pas prises, j'imagine).

Ca dépend du processeur, certains ont aussi des préfixes pour indiquer si le branchement doit être pris la première fois ou pas mais j'ai jamais entendu dire que c'est utile.

Edit : je parlais des x86.

[Tramb]

Ca dépend du processeur, certains ont aussi des préfixes pour indiquer si le branchement doit être pris la première fois ou pas mais j'ai jamais entendu dire que c'est utile.

Tout à fait on en revient à mes hints PowerPC

[fennec]

C'est pas de la triche, c'est exactement ce que tu fais quand tu améliores les patterns d'accès mémoire alors que tu pourrais faire confiance aux caches : t'es quand même bien content de les aider, les caches.
Les streams non temporels, les instructions de contrôle de cache et les instructions de prefetch soft prouvent bien que les concepteurs de CPU reconnaissent que de l'information externe à leur système peut améliorer la performance de code s'exécutant sur leur archi.

Je disais que c'était de la triche dans le sens ou il est probable que tu n'obtiennes pas du tout les mêmes perf sur une achi différente. Fefe l'a bien mieux expliqué que moi, mais tout dépends évidement de ton application. Tu parles de datacrunching, c'est clairement le cas ou le réordonnancement est le bienvenue.

[fefe]

fefe, que penses-tu de mon exemple pour du code spaghetti où tous les asserts sont hintés comme non pris?
A raison de 1/2 asserts par fonction, y'a de quoi améliorer la vitesse des debug builds quand même.

En fait tu négliges le chauffage du BHT et les évictions, ce qui me parait tout à fait valide pour du data crunching, mais pour un programme plus versatile... en fait j'en sais rien
En l'absence d'entrée dans l'historique le CPU a bien une heuristique statique pour se décider (les branches ne sont pas prises, j'imagine).

Effectivement lors de la premiere passe tu peux considerer qu un branchement arriere sera pris et un branchement avant ne sera pas pris, mais de toutes facons il faudra trouver la target qui n'est pas encore dans la BTB, donc il y aurait deja eu une penalite pour le branchement arriere.

Un peu de lecture sur la prédiction de branchement:
A. Farcy, "Exécution anticipée des flots de condition : une alternative aux prédictions de branchement"
http://rangiroa.essi.fr/rapports/200...hese-farcy.pdf

Tiens une these pas inconnue (mais pas lue en entier). Remarque que l'alternative proposee est dynamique et a l'execution. Sinon l'idee de decoupler differents flots d'execution pour essayer de precharger les donnees et aussi preparer les predicteurs (ou obtenir une prediction proche d'un oracle) a fait pas mal de chemin et reste une des rares bonnes idees qui n'a pas encore ete implementee (le speculative multithreading part des memes constatations et propose une solution similaire meme si differente, il y a aussi eu une architecture nomme "replay" qui n'a rien a voir avec le rep[lay du P4).

C'est pas de la triche, c'est exactement ce que tu fais quand tu améliores les patterns d'accès mémoire alors que tu pourrais faire confiance aux caches : t'es quand même bien content de les aider, les caches.
Les streams non temporels, les instructions de contrôle de cache et les instructions de prefetch soft prouvent bien que les concepteurs de CPU reconnaissent que de l'information externe à leur système peut améliorer la performance de code s'exécutant sur leur archi.

Oui et les architectures modernes ignorent superbement la majorite des software prefetch parce qu'ils sont generalement inefficaces apres la premiere generation de microprocesseur pour laquelle l'analyse qui a conduit a les ecrire a ete faite. La latence et la bande passante memoire sont des parametres qui fluctuent tres rapidement entre generations et qui sont fondamentaux pour le tuning d'instructions de prechargement.

Bien entendu un programme qui prechargerait des donnees stockees dans des listes ou un arbre tirerait parti de ces instructions, mais malheureusement dans la plupart des cas les programmeurs les utilisent sur des acces sequentiels. Le seul acces pour lequel il y a un avantage certain a utiliser un prechargement logiciel est pour le premier acces d'une page ou des stride superieurs a la taille d'une page, les prefetcheurs etant limites a l'interieur d'une page. Dans ces cas la les prefetcheurs hard laisseraient la main aux prefetchers software.

[Gabriel]

Oui et les architectures modernes ignorent superbement la majorite des software prefetch parce qu'ils sont generalement inefficaces apres la premiere generation de microprocesseur pour laquelle l'analyse qui a conduit a les ecrire a ete faite. La latence et la bande passante memoire sont des parametres qui fluctuent tres rapidement entre generations et qui sont fondamentaux pour le tuning d'instructions de prechargement.

A priori j'ai l'impression c'est le cas de la plupart des optims non-algorithmiques: dans une optique x86 (ie on ajoute du hard pour faciliter la vie des programmeurs et des compilos), la plupart ne fonctionnent que temporairement, et ne font plus rien sur le microprocesseur suivant.

Par exemple:
*le mot clef "register" du C (ok, aussi obsolète du fait des compilos)
*les instructions de prefetch pour les accès séquentiels
*les périphériques de Duff (sur du Core, c'est encore utile)
*l'imbrication des types d'instructions (panache de mul et add)

Mais bon, en pratique on fait quand même assez souvent ce genre de trucs, et même de nos jours ça augmente les perfs.

[Tramb]

Bien entendu un programme qui prechargerait des donnees stockees dans des listes ou un arbre tirerait parti de ces instructions, mais malheureusement dans la plupart des cas les programmeurs les utilisent sur des acces sequentiels. Le seul acces pour lequel il y a un avantage certain a utiliser un prechargement logiciel est pour le premier acces d'une page ou des stride superieurs a la taille d'une page, les prefetcheurs etant limites a l'interieur d'une page. Dans ces cas la les prefetcheurs hard laisseraient la main aux prefetchers software.

Oui c'est sûr que les prefetcheurs hard font leur boulot sur les accès linéaires, même stridés, mais comme tu le dis toi même pour le pointer walking ça peut encore être intéressant et masquer des latences.

En fait tu me confortes dans mon idée (purement algorithmique, pas basé sur une connaissance professionnelle de la micro architecture et donc peut-être pûrement réthorique, je te le concède en parlant du premier prefetch :
un système dynamique genre branch predictor ou hardware prefetch a besoin d'historique, donc de temps, pour converger. Pourquoi dans ce cas-là ne pas pouvoir lui hinter ses conditions initiales pour accélerer la convergence?


Sinon, histoire de lancer un autre sujet, pourquoi les x86 n'ont pas le dcbz du PowerPC?
Pour ceux qui ne connaissent pas ça permet de mettre à zero une ligne de cache sans la charger.

Les write combiners sauraient-ils (les bougres) détecter qu'on écrit une ligne entière et éviter tout loading?
Corollaire : quel est le meilleur pattern pour initialiser de la mémoire sur un x86 moderneuh?

A priori j'ai l'impression c'est le cas de la plupart des optims non-algorithmiques: dans une optique x86 (ie on ajoute du hard pour faciliter la vie des programmeurs et des compilos), la plupart ne fonctionnent que temporairement, et ne font plus rien sur le microprocesseur suivant.

Bien d'accord mais au moins elles ne pénalisent pas grand chose sur les générations suivantes...

[Gabriel]

Sinon, histoire de lancer un autre sujet, pourquoi les x86 n'ont pas le dcbz du PowerPC?
Pour ceux qui ne connaissent pas ça permet de mettre à zero une ligne de cache sans la charger.

Naïvement, j'ai l'impression que le seul gain est au niveau de la bande passante mémoire consommée. Si il y a globalement un étranglement, pourquoi pas.
Par contre, si il reste de la bande passante mémoire, je dirais que ça ne doit pas changer grand chose, vu que la zone sera préchargée.

[Tramb]

Naïvement, j'ai l'impression que le seul gain est au niveau de la bande passante mémoire consommée. Si il y a globalement un étranglement, pourquoi pas.
Par contre, si il reste de la bande passante mémoire, je dirais que ça ne doit pas changer grand chose, vu que la zone sera préchargée.

Tu as raison c'est surtout une question de bande passante, mais la vraie raison d'être, c'est dans un environnement multithreadé où le L2 est partagé, il est recommandé d'être gentil et de ne pas trasher les caches des autres qui en ont peut-être plus besoin!

[Franck@x86]

Bon alors HT...
Si on regarde du cote des ressources partagees comme les caches: les C2D les ont systematiquement en plus grande quantite (...). Le cache de donnee de premier niveau est 2x plus gros par exemple. Donc si il n'y avait pas de problemes de partage il n'y en aura pas plus sur C2D.

Ca reste à démontrer, sur P4 (même Prescott) il est relativement facile de trouver un cas où l'HT fait globalement baisser les performances globales en raison d'un conflit de ressource. On peut de toute façon difficilement concevoir que le partage du cache (et de toute autre ressource d'ailleurs)entre deux threads soit sans effet sur la performance, en comparaison à l'accès exclusif par un seul thread, et ce qquesoit la taille du cache.

Le gain de perfs de l'HT n'est dans tous les cas que la résultante d'une accélération due au traitement simulatané de deux threads et d'un ralentissement lié au partage de ressources. Selon les applis la balance est positive ou négative, et le gain de perfs global reste statistique.

Au sujet du partage des L1, les caches sont splittés (un morceau par thread) ou partagés entre les deux threads ?

[fefe]

Ca reste à démontrer, sur P4 (même Prescott) il est relativement facile de trouver un cas où l'HT fait globalement baisser les performances globales en raison d'un conflit de ressource. On peut de toute façon difficilement concevoir que le partage du cache (et de toute autre ressource d'ailleurs)entre deux threads soit sans effet sur la performance, en comparaison à l'accès exclusif par un seul thread, et ce qquesoit la taille du cache.

Le gain de perfs de l'HT n'est dans tous les cas que la résultante d'une accélération due au traitement simulatané de deux threads et d'un ralentissement lié au partage de ressources. Selon les applis la balance est positive ou négative, et le gain de perfs global reste statistique.

Au sujet du partage des L1, les caches sont splittés (un morceau par thread) ou partagés entre les deux threads ?

J'argumentais sur le fait qu'il n y avait aucune raison que ce soit pire que P4, mais pas sur le fait que le second thread affecterait ou non les perfs du premier. De maniere generale a partir du moment ou tu commences a partager une ressource entre 2 threads il y a une perte de performance possible. C'est par exemple le cas sur les dual core, en particulier sur les threads ayant des acces intensifs au sous-systeme memoire (l2-memoire). Apres il suffit de definir ce que l'on trouve acceptable comme influence pour definir a quel point une solution multithreadee nous convient.

De ce que je comprends la solution dual core te convient mais pas la solution HT-P4. Il y a tout un spectre de possibilites entre les 2, et c'est un espace ou il y a eu pas mal de publications, en particulier sur comment preserver les performances d'un thread dans une architecture a multiflot simultane (bien entendu le debit combine des threads en souffre).

[fefe]

Oui c'est sûr que les prefetcheurs hard font leur boulot sur les accès linéaires, même stridés, mais comme tu le dis toi même pour le pointer walking ça peut encore être intéressant et masquer des latences.

Un hint qui specifierait que tu es en train de suivre une chaine de pointeurs, et specifiant ou est le pointeur dans ta structure pourrait definitivement aider. En revanche il ne faut pas essayer de hinter plus parce qu'il faut se limiter a des proprietes que le hardware a du mal a detecter mais qui seront constantes entre generations.

En fait tu me confortes dans mon idée (purement algorithmique, pas basé sur une connaissance professionnelle de la micro architecture et donc peut-être pûrement réthorique, je te le concède en parlant du premier prefetch :
un système dynamique genre branch predictor ou hardware prefetch a besoin d'historique, donc de temps, pour converger. Pourquoi dans ce cas-là ne pas pouvoir lui hinter ses conditions initiales pour accélerer la convergence?

Oui les premiers acces sont les plus durs a predire, en pratique on ne peux pas faire grand chose pour le premier acces car on ne connait pas encore la destination du branchement, donc un hint n'aide pas pour le premier. En revanche les quelques acces suivants (le temps de construire un historique fiable) la prediction est de moins bonne qualite et il existe des cas ou donner des hints pourraient aider. Cela permettrait potentiellement de reduire les mauvaises predicitons encore un peu plus, mais il n'y a effectivement pas de revolution a y voir, le gain serait faible en dehors de codes qui ont tres peu de localite temporelle.

Sinon, histoire de lancer un autre sujet, pourquoi les x86 n'ont pas le dcbz du PowerPC?
Pour ceux qui ne connaissent pas ça permet de mettre à zero une ligne de cache sans la charger.

Les write combiners sauraient-ils (les bougres) détecter qu'on écrit une ligne entière et éviter tout loading?

Les bougres , bien entendu la detection est limitee a ce qu'un petit buffer peut detecter, donc si effectivement les acces qui couvrent ta ligne sont proches dans le temps, mais c'est typiquement ce que tu fais quand tu initialises une ligne. c'est moins efficace que si le programmeur le specifiait a chaque fois, mais la perte n'est pas majeure non plus.

[Franck@x86]

De ce que je comprends la solution dual core te convient mais pas la solution HT-P4.

Non, en réalité je me pose la question de la pertinence du HT sur une archi multicore. Le HT sur P4 monocore je trouve ça intelligent : la techno tient en peu de place (intel a d'aileurs pas mal communiqué là dessus) et est débrayable, et apporte un sacré confort, jusque là connu que des seuls utilisateurs de machines multi sockets (donc principalement professionnels).

En comparaison, le dual-core sur P4 tient davantage de la solution disons ... peu élégante (mais cela ne veut pas dire qu'elle ne soit pas efficace pour autant).

Maintenant, la présence du SMT sur une archi quad cores n'apoorte plus cette "magie" du P4 HT en son temps. Mais elle conserve ses défauts, le pincipal restant à mon avis la nécessité pour les applis MT de devenir "logical unit aware", sous peine de laisser qques cores physiques inactifs. A mon sens, le SMT devrait rester cantonné aux CPUs servers, mais l'argument marketing "8 threads" devrait pousser Intel à le proposer sur les CPUs desktops également.

[fefe]

A mon sens, le SMT devrait rester cantonné aux CPUs servers, mais l'argument marketing "8 threads" devrait pousser Intel à le proposer sur les CPUs desktops également.

On est plutot d'accord sur le sujet. J'ai mes doutes sur la reintroduction de HT sur les desktop (hors XE) et son introduction sur les platformes mobiles pour les memes raisons que toi, mais seul l'avenir le dira.

[Dandu]

Question, en mobile : si on désactive un core et qu'on utilise une technologie HT pour garder le confort d'utilisation de l'OS quand même, on gagnerait en autonomie ?

j'avais lu qu'au départ, les Core Duo auraient la possibilité de désactiver un core sur batterie, mais j'ai jamais vu de cas concret de ce type d'utilisation (tout comme le IDA? d'ailleurs).

[Gabriel]

j'avais lu qu'au départ, les Core Duo auraient la possibilité de désactiver un core sur batterie, mais j'ai jamais vu de cas concret de ce type d'utilisation (tout comme le IDA? d'ailleurs).

Je crois que c'est un peu la faute aux OS. Par exemple, NT5 et NT6 ne sont pas vraiment capable de gérer ce genre de subtilités (tout comme les problematiques de distance entre le processeur et la mémoire), et donc l'OS déplace régulièrement les threads entre les différents coeurs. Ce n'est pas très optimal, mais l'avantage c'est que ce n'est pas non plus risqué au niveau perfs. Mais du coup, il n'est pas là de se mettre en veille le second coeur.

[Lissyx]

Peut être qu'avec Solaris ça serait géré. Il me semble que Solaris est capable de tourner sur du matos où on change les processeurs à chaud

[Doc TB]

Peut être qu'avec Solaris ça serait géré. Il me semble que Solaris est capable de tourner sur du matos où on change les processeurs à chaud

"tourner", c'est un bien grand mot. Il faut tout freezer, halter tous les CPUs, flusher tout ce qui est flushable et puis changer le CPU. A ce stade, Windows le fait aussi : Tu met en veille prolongée, tu change ton CPU et tu relance...

[Neo_13]

un os est capable de le faire 100% à chaud ?

[Lissyx]

"tourner", c'est un bien grand mot. Il faut tout freezer, halter tous les CPUs, flusher tout ce qui est flushable et puis changer le CPU. A ce stade, Windows le fait aussi : Tu met en veille prolongée, tu change ton CPU et tu relance...

ha, en me renseignant j'avais pas compris ça comme ça. Mais c'était au sujet de gros systèmes, où apparement t'avais juste à désactiver depuis l'OS le dit CPU, puis l'enlever. Mais pour ça, faudrait que je retrouve où j'ai vu ça ...

[EPIC]

Un petit article issue de l'ISSCC qui se déroule actuellement à San Francisco et concernant le nouveau processeur "Rock" 16 cores de Sun Microsystem prévu pour fin 2008 début 2009 (avec un peu de chance)

16 Cores, 65 nm, 2.3 Ghz, 396 mm², 250W - SMT 2Way/core + 2 Hardware Scout Thread

Au menu une nouvelle OOO et du Sharing dans tous les sens (Cache, FPU, etc...)

http://arstechnica.com/news.ars/post...is-cookin.html

Nouveau coup de force de SUN ou nouvelle désillusion ?

[Childerik]

Mmmmhhh, pas mal du tout, mais le L2 est petit quand même. Est-ce important dans cette architecture sparc, vu qu'il semble avoir des caches dédiés à chaque paire de coeurs ?

[EPIC]

Mmmmhhh, pas mal du tout, mais le L2 est petit quand même. Est-ce important dans cette architecture sparc, vu qu'il semble avoir des caches dédiés à chaque paire de coeurs ?

Ben je pense que justement les "Hardware Scout Thread" seront là pour compenser ou ré-équilibrer la faible capacité des caches en exécutant à l'avance le code durant le stalling du processeur si le problème de mémoire ne peut être résolu plus rapidement le scout thread met a profit le temps d'inactivité pour anticiper sur les opérations suivantes (notamment les branchements)... enfin bref c'est pas super clair dans mon esprit ni dans l'article... j'attend un petit décryptage de fefe pour ça...

Autre chose (entre autre) on remarque que le partage des caches de données ne se fait que pour deux cores une décision certainement guidée par un impact plus important sur les performances mais aussi par une compléxité accrue des structures de caches (dans le cas d'un partage pour 4 cores) et donc un coût en transistors et en consommation non négligeable...

[Childerik]

C'est marrant ces 16 cores : ca fait penser vaguement à Larabee : un nouveau dans le club "Qui va ray-tracer le plus efficacement ?"

[EPIC]

C'est marrant ces 16 cores : ca fait penser vaguement à Larabee : un nouveau dans le club "Qui va ray-tracer le plus efficacement ?"

j'ai quelques doutes quant aux capacités FPU de Rock vu que les unités FPU sont partagés entre plusieurs cores, sinon je pense que Rock est là pour couvrir un segment de la gamme serveur de SUN Microsystem qui jusque là était assuré par le poussif UltraSparc IV/IV+, Niagara (UltraSparc T1/T2) couvrant "l'entry Level".

Autant que je m'en souvienne les cores prévus pour Larabee seront beaucoup plus simple (rustique ? Archi P5 ?) ceux de Rock dispose de core Out of Order semblable à ce qu'était l'UltraSPARC III & IV...

[fefe]

J'aime beaucoup le concept de retirement speculatif qu'ils emploient, ca rappellent certains papiers dont l'un appele "replay" (ce n'est pas le replay de P4) publie il y a pas mal de temps maintenant. Quand je parlais de multiscalar/speculative multithreading dans le premier post, c'etait effectivememnt de ce type de mecanismes que je voulais discutter.
Je pense que c'est un tres bon concept qui se doit d'etre pousse et evalue. En revanche, malheureusement le succes des cores sun est relativement independant de leurs qualites, comme la plupart des chips non x86... Ils ont la grande qualite de persister et j'espere pour Sun que un bon chip se transformera en succes commercial aussi...

Les threads scout partent du principe qu'une bonne partie du flot d'instruction execute est independant des donnees chargees et qu'il n'y a pas besoin d'attendre la memoire pour avoir tous les resultats.
Donc une premiere passe, tu calcules les branchements, tu remplis tes tables de prediction, tu determines des dependances, tu envoies un load. Dans la seconde passe, tu execute le tout super vite et consomme la donnee de ton load qui est revenu.

En gros tu peux voir ca comme un super prefetcher qui serait capable de detecter la majorite des patterns d'instruction, et de transformer ton predicteur de branchement en un "presque" oracle.

C'est marrant ces 16 cores : ca fait penser vaguement à Larabee : un nouveau dans le club "Qui va ray-tracer le plus efficacement ?"

Sauf que ce n'est pas en partageant les FPU entre 2 cores que tu vas avoir les capacites necessaire a rentrer dans la course. Rock est tout sauf un CPU dedie au calcul flottant...

[EPIC]

Les threads scout partent du principe qu'une bonne partie du flot d'instruction execute est independant des donnees chargees et qu'il n'y a pas besoin d'attendre la memoire pour avoir tous les resultats.
Donc une premiere passe, tu calcules les branchements, tu remplis tes tables de prediction, tu determines des dependances, tu envoies un load. Dans la seconde passe, tu execute le tout super vite et consomme la donnee de ton load qui est revenu.

En gros tu peux voir ca comme un super prefetcher qui serait capable de detecter la majorite des patterns d'instruction, et de transformer ton predicteur de branchement en un "presque" oracle.

Merci pour ces éclaircissements fefe, est-ce que les Threads Scout fonctionnent uniquement quand un core subit un stall ou un évènement chronophage ou alors cette technique peut fonctionner dans n'importe conditions ? Quel gain peut ont espérer en moyenne ? Sans vouloir le comparer avec le SMT est-ce qu'il peut y avoir néanmoins des désagréments comme ceux rencontrés parfois avec l'HyperThreading ?

[fefe]

Il y a les memes risques qu'avec tout algorithme speculatif, tu specules trop et tu gaspilles des ressources a executer quelque chose qui ne te servira pas. Dans ce sens c'est different de SMT, ou tu utilises des ressources au detriment d'un autre thread mais tu en faits effectivement quelque chose (en partant du principe qu'il n'y a pas de speculation trop agressive quand tu tournes en SMT).

Un exemple d'autre algo speculatif qui peut etre detrimental si tu specules trop est le prefetch, si tu prefetch trop tu gaspilles de la bande passante memoire et remplis le cache de donnees inutiles qui vont remplacer des donnees potentiellement utiles.

Il y a donc forcement des cas ou tu perds de la performance parce que le thread scout n'a servi a rien et a soit rien reussi a calculer soit calcule des resultats faux (il est parti d'une mauvaise prediction de valeur/branchement etc...). Je suppose qu'ils ont des mecanismes avances pour eviter d'avoir trop souvent ce genre de cas et les detecter le plus tot possible, mais il est quasiment impossible d'eviter systematiquement ce genre de problemes. En revanche dans la majorite des cas tu gagnes (en partant du principe que c'est bien tune, mais je n'en doute pas).

Cote perf, les analyses que j'avais vues ajoutaient ~20% de perf sur des machines qui avait deja de bons prefetchers/predicteurs, sur une machine plus faible cela ajoute probablement plus, surtout quand tu as des applications serveurs qui generalement ne sont pas capturees par des prefetchers traditionnels.

En revanche toutes les ressources utilisees par les threads scouts ne sont pas disponibles pour executer d'autres threads SMT donc si tu combines les 2 il faut reussir a creer des arbitres qui gerent les priorites de maniere efficace.

[EPIC]

Il y a donc forcement des cas ou tu perds de la performance parce que le thread scout n'a servi a rien et a soit rien reussi a calculer soit calcule des resultats faux (il est parti d'une mauvaise prediction de valeur/branchement etc...). Je suppose qu'ils ont des mecanismes avances pour eviter d'avoir trop souvent ce genre de cas et les detecter le plus tot possible, mais il est quasiment impossible d'eviter systematiquement ce genre de problemes. En revanche dans la majorite des cas tu gagnes (en partant du principe que c'est bien tune, mais je n'en doute pas).

En revanche toutes les ressources utilisees par les threads scouts ne sont pas disponibles pour executer d'autres threads SMT donc si tu combines les 2 il faut reussir a creer des arbitres qui gerent les priorites de maniere efficace.

Dans le cas d'une prédication de branchement le Thread Scout pourrait alors servir à calculer les deux branchements avec évidement une comsomation accrue de ressources mais un résultat bon quoi qu'il arrive...

Si j'ai bien compris le fait de tunner son appli voir même d'utiliser un compilateur dédié pourrait être bien plus profitable que d'utiliser un compilo "générique", On retrouverait alors le même genre de phylosophie utilisée pour l'Itanium ou le rôle décisionel du compilateur est bien plus important.

[Møgluglu]

Le Silverthorne/Diamondville s'appelle maintenant officiellement Atom.
Alors que VIA se met à l'OoO "lourd", Intel fabrique donc des procos nains...

Le coeur in-order semble assez conventionnel, avec une ALU et une FPU à 2 voies chacune, et du SMT.
Des datapaths SIMD en 128-bits pour les entiers et 64-bits pour les flottants.

Pour l'économie d'énergie, on a :
- Cache L2 partiellement flushable
- FSB basculable en mode CMOS
- Pour le sommeil profond, possibilité de n'alimenter qu'une petite zone de SRAM basse conso contenant l'état du processeur (comme sur le Penryn?).

J'oublie certainement tout plein de choses...

sources en vrac :
http://arstechnica.com/news.ars/post...obile-cpu.html
http://www.anandtech.com/cpuchipsets...spx?i=3230&p=1
http://pc.watch.impress.co.jp/docs/2.../kaigai421.htm

Le 45nm devrait faire en sorte qu'on atteigne des fréquences raisonnables en restant dans l'enveloppe des 2W... Il semble qu'il se place plutôt en face des processeurs ARM, avec la compatibilité x86 en plus.

Pour le flush partiel, j'imagine que c'est par voies de cache. Donc la moitié du cache qui est flushée contenait à la fois des données utiles et moins utiles? (c'est-à-dire : on ne peut pas choisir la moitié qui nous arrange?)