Nehalem et innovations

**fefe** · 23/10/2007, 13h12

C'est deja le cas d'une certaine maniere tu stock une addresse virtuelle dans le cache et tu fais la traduction d'adresse dans une TLB.

De maniere generale il n'y a plus aucun gain visible au dela d'une associativite de 16 et les gains sont mineurs au dela de 8 (en considerant 1 seul thread), obtenir une associativite "complete" apporterait qq chose de minime aux microprocesseurs modernes (quelques pourcents en moyenne si la latence et le debit restaient les memes).

Le probleme de la solution de virtualiser une fois de plus l'espace d'adressage et que tu es force d'avoir une TLB plus complexe, en effet chaque acces au cache doit etre verifie par les TLB comme accedant a une page dans laquelle il a les droits de lecture ou d'ecriture appropries. Le traffic de coherence arrive aux caches en adresses physiques et aurait besoin d'etre traduit aussi afin de pouvoir verifier sa presence dans le cache, ralentissant de facto tout les snoops et les autres processeurs.

Une TLB plus compliquee implique une augmentationde la latence d'acces a moins que le cache soit completement virtuel (ce qui n'est plus le cas a ma connaissance depuis que les CPUs supportent le SMP pour des problemes de coherence).

**Yasko** · 23/10/2007, 13h41

Je ne pensais pas à utiliser une table de correspondance mais de substituer directement au niveau de l'instruction l'adresse d'origine par l'adresse physique en cache.
Cette adresse serait allouée lors du prefetch instruction ou du decode par le controleur de cache en fonction des disponibilités et des instructions déja chargées dans le pipe.
Le chargement de la donnée en cache a l'adresse allouée aurait lieu alors que l'instruction descend le pipe de manière à être disponible lorsque la lecture doit être faite.
La donnée ne pourrait être évincée du cache tant qu'une instruction l'utilisant serait présente dans le pipe.

**fefe** · 23/10/2007, 13h59

Les adresses ne sont pas connues avant l'etage d'execution (sauf un cas eventuel ou tu aurais une bonne partie de l'addresse en immediat dans l'instruction) ou tu calcule l'adresse (en lisant un/des registres), c'est donc quasi impossible: tu peux bien entendu essayer de predire ce genre de choses tres en amont mais le taux de bonnes predictions est faible, tres faible.

Le plus tot pour faire la substitution c'est dans l'AGU et il faudrait que ta fonction de hashage ne prenne pas plus longtemps que l'add que tu dois deja faire pour calculer l'addresse.

Meme une analyse complexe du code a du mal a determiner si une instruction est utilisee pour produire une adresse ou une donnee etant donne qu'ils utilisent les memes instructions (certains utilisent meme lea pour des donnees). Et meme savoir si une instruction appartient au flot de calcul d'adresse ne permet pas de determiner l'adresse finale en avance.

Si on pouvait avoir une bonne idee de l'adresse aussi en avance que tu le dis l'ensemble des caches de donnees des CPU actuels auraient 0 cycles de latence, on prefetcherai directement les donnees dans les registres juste avant de les utiliser.

Il y a des techniques qui essayent de predire les adresses et de transferer les donnees par des registres plutot que par le cache entre des instructions dependantes, ca s'appelle "memory renaming" et c'est a peu pres la seule technique que je connaisse qui reussisse dans certains cas particuliers a deviner une adresse a l'avance. Ca ne peut pas s'appliquer a une traduction systematique des adresses.

**Yasko** · 23/10/2007, 14h46

OK, merci pour l'explication.

Pour tenter de résumer, c'est parce que les adresses des données sont le résultat de calculs et non pas écrites en dur dans le code x86 que le problème de prédiction se pose.
un mov eax, [eax] est problématique, pas un mov eax, 00FF00EEh.

Si on pouvait avoir une bonne idee de l'adresse aussi en avance que tu le dis l'ensemble des caches de donnees des CPU actuels auraient 0 cycles de latence, on prefetcherai directement les donnees dans les registres juste avant de les utiliser.

On ne peut pas dans ce cas générer un code x86 n'utilisant que des adresses (relatives ?) écrites en dur ? (je ne me rends pas bien compte de ce que ca implique, désolé si c'est une aberration...)

**fefe** · 23/10/2007, 14h48

Ca rendrait au moins le code enorme et diminurait les performances de maniere tres importante a moins de changer tout le cache d instruction et les decodeurs.
Je suppose que ca ne plairait pas non plus aux compilos.

**DaP** · 12/12/2007, 16h15

Il y en a qui s'occupent sainement en attendant : http://smallcode.weblogs.us/2007/11/...-instructions/
Quelqu'un a essayé de SDK avec l'émulateur SSE4 ? http://softwarecommunity.intel.com/a...s/eng/1193.htm

Edit : prudence sur le premier lien mais BifDefender ne me dit rien.

**Childerik** · 12/12/2007, 16h21

Ton premier lien fait baliser mon AVG

**fefe** · 12/12/2007, 16h38

A noter que l'emulateur est pour Penryn donc supporte SSE4.1 alors que les instructions discutees dans ton premier loin sont SSE4.2 (Nehalem only).

Donc meme sur l'emulateur Penryn le code en question ne tournera (malheureusement) pas.

En revanche quelqu'un qui voudrait absolument tester ce code aujourd'hui peut assez facilement developper des macros qui remplacent les 7 instructions SSE4.2 par une sequence d'instructions "equivalentes" (correspondant a la spec). Ca ne presente un interet que pour quelqu'un qui essayerait de tuner une appli existante sans support d'intel pour etre dispo a la release de Nehalem (l'emulateur ou un set de macro approprie etant probablement donne par Intel en NDA aux principales boites de sw).

**DJ_DaMS** · 13/12/2007, 10h22

Envoyé par Childerik

Ton premier lien fait baliser mon AVG

Idem avec trendmicro sur mon PC du boulot.

**Childerik** · 13/12/2007, 11h43

Je ne pense pas que ça soit un méchant script : juste un truc mal codé que certains AV croient être une petite saloperie.

**Eld** · 13/12/2007, 17h19

Envoyé par Franck@x86

Et pour finir, il faut un OS capable de distinguer une unit logique d'une physique, cf le problème soulevé y'a qques temps sur ici même :
http://www.x86-secret.com/index.php?...=newsd&nid=850

Plus on ira vers des processeurs multicores avec des hiérarchies de caches, plus l'OS devra être "renseigné" sur la structure du processeur. En dehors du cas du SMT, on retrouve aussi le problème de placer des threads qui travaillent sur les mêmes données. On a évidemment intérêt à les placer sur des cores, physiques ou logiques, qui ont un cache en commun le plus proche possible. Il y a donc clairement du travail à faire au niveau du placement/déplacement des threads sur le processeur.
En ce qui concerne l'intérêt du SMT, on peut aussi citer l'utilisation des "helper threads" qui, en tournant sur le même core, consomment peu de ressources mais permettent de déclencher les accès mémoires et donc la remontée des informations dans les caches plus tôt afin d'améliorer les performances du thread principale.

**fefe** · 15/12/2007, 21h31

Envoyé par Eld

Plus on ira vers des processeurs multicores avec des hiérarchies de caches, plus l'OS devra être "renseigné" sur la structure du processeur. En dehors du cas du SMT, on retrouve aussi le problème de placer des threads qui travaillent sur les mêmes données. On a évidemment intérêt à les placer sur des cores, physiques ou logiques, qui ont un cache en commun le plus proche possible. Il y a donc clairement du travail à faire au niveau du placement/déplacement des threads sur le processeur.
En ce qui concerne l'intérêt du SMT, on peut aussi citer l'utilisation des "helper threads" qui, en tournant sur le même core, consomment peu de ressources mais permettent de déclencher les accès mémoires et donc la remontée des informations dans les caches plus tôt afin d'améliorer les performances du thread principale.

Je ne suis pas sur en fait qu'il vaut mieux que l'OS ait absolument besoin d'etre renseigne sur tous les details, je pense que c'est plus au hard de gerer ou positionner les threads pour obtenir la meilleur perf. Idealement l'OS communiquerait des indices sur les propriete des processus / threads executes comme :
- le taux de communication attendu entre les threads
- la sensibilite de l'application aux latences
- la sensibilite de l'application a la bande passante

Si l'OS n'est pas capable de connaitre ces infos, il n'y a aucune raison de lui donner le controle sur le positionnement des threads. Si il a ces infos, l'algo de scheduling va devoir changer a chaque generation pour chaque constructeur, donc autant definir une API et laisser le hardware (qui evolue toujours bcp plus vite que les OS) le controler.

**Eld** · 16/12/2007, 00h50

il faut une API, on est bien d'accord, mais pour moi elle est pour explorer l'architecture du proc
le processeur n'a pas assez d'informations pour gérer un ordonnancement global, il ne connait pas tous les programmes qui tournent, et puis ça ferait encore des trucs crassoux à envoyer dans le processeur...
des travaux qui vont vont dans ce sens : http://hal.inria.fr/docs/00/15/45/06/PDF/main.pdf

**fefe** · 16/12/2007, 11h06

Le processeur a beaucoup d'informations deja aujourd'hui qui sont generalement employees pour le power management uniquement, mais rien n'empeche d'etendre les API en question pour inclure des notions plus fines de performance.

Et je ne crois pas en la capacite des OS de gerer la performance efficacement, et ce principalement parce qu'un OS est developpe sur les CPUs d'hier pour les CPUs de demain avec a peu pres aucune idee de ce que seront les CPUs de demain. Et dire que les constructeurs de CPUs n'ont qu'a plus communiquer avec ceux qui font les OS est :
1 - une utopie, le secret represente des milliards pour les fabriquants de CPU, et ils ne vont pas communiquer des infos detaillees suffisament en avance pour pouvoir developper un OS dessus.
2 - impossible, au moment ou le fabriquant d'OS aurait besoin de ces infos le fabriquant de CPU ne sait pas encore suffisament a quoi ressemblera son CPU de demain (dans certains cas pas du tout meme).
3 - le power management, le CPU prend les decisions aujourd'hui (suivant les recommandations de l'OS) de la frequence a laquelle va tourner un thread, et il y a de bonnes chances pour qu'un jour le CPU sur lequel ce thread devra tourner sera decide apr le power management, ce qui enleve essentiellement toute possibilite a l'OS pour gerer la performance de maniere fine.

Bien entendu l'OS a un grand role a jouer, le CPU ignorant beaucoup de choses sur les caracteristiques des applis. Le plus simple est pour l'OS de les communiquer plutot que d'essayer de s'adapter a des algorithmes qui changent une fois par an (et pour Microsoft, en plus ca leur coute moins cher).

**Eld** · 16/12/2007, 15h30

le processur "connaît" les processus qu'il exécute à un instant T, donc 2, 4, 8 threads
l'OS lui a une vision globale et a des informations sur la 100aine de processus lancés à un instant T
ça fait quand même une grosse différence au niveau des possibilités de réarangement de l'ordonnancement
je ne pense pas que l'OS ait besoin d'informations si précises que ça sur le processeur, il a juste besoin de connâitre les "sites" d'exécution et la "distance" entre ceux-ci
en plus, une solution niveau OS peut très bien gérer plusieurs processeurs physiquement séparés
il existe des solutions matérielles pour connecter de façon intelligente plusieurs processeurs entre eux, mais avec une solution OS on pourrait le faire avec un hardware hétérogène

**fefe** · 16/12/2007, 16h31

Oui justement le processeur ne connait que ce qu'il execute a un instant donne, mais a cet instant il est aussi le seul qui peut resoudre le probleme d'optimisation de la dissipation energetique. Si l'OS ne lui fournit pas les informations sur les dependances des threads entre eux, la situation aboutira a une solution sub optimale d'un point de vue performance et energie.

Aujourd'hui les decisions sur la dissipation d'energie commencent a supplanter les decisions de placement de threads en terme d'impact sur les performances. Demain ce sera encore plus important.

Je ne me fait pas l'avocat d'un OS ignorant et d'un CPU qui fait tout. Comme tu le dis, c'est a l'OS de decider quels threads lancer concurrament et ca seul lui peut le faire, pour ca il a donc besoin d'un modele theorique representant les caracteristiques du processeur. En revanche une fois que les threads devant etre executes concurament ont ete selectiones, c'est au CPU de les placer le mieux possible (rien n'empeche l'OS de donner ses preferences, mais la decision finale est au CPU si on veut aboutir a une solution efficace a mon avis).

Les processeurs physiquements separes, ne sont effectivement pas power manages ensemble aujourd'hui, mais cela ne va plus durer tres longtemps.

**Eld** · 16/12/2007, 20h16

au final c'est toujours le processeur qui aura la main, et c'est vrai qu'on ne va pas rendre la main à l'OS à chaque fois qu'il se passe quelque chose
donc effectivement, peut être que l'OS pourrait placer les threads sur une abstraction du processeur, et le processeur après exécute tout ça en respectant au mieux ces contraintes

**Gabriel** · 16/12/2007, 21h26

Dans le cas "simple" où on a un seul processeur physique, il est clair que le processeur est positionné de manière optimale pour prendre les décisions de placement des threads.

Mais dès que l'on a plus d'un processeur physique, on commence à multiplier fortement les cas possibles:

*2 p4 avec HT activé: problème de positionnement des threads vis-à-vis des ressources de calcul, mais aussi des accès au cache.

*2 quads de type "Core": problème d'optimisation des accès aux caches, et problème d'optimisation de l'énergie

*2 opterons avec un seul banc mémoire: problème d'optimisation de la latence mémoire

*2 opterons avec 2 bancs mémoire: problème d'optimisation de la latence mémoire, incluant un problème de répartition des données entre les bancs mémoire

Avec un tout petit peu d'imagination, on peu aussi envisager les cas hypothétiques suivants:

*Larabee pourrait être un GPU capable aussi d'exécuter du x86: Dans ce cas, problème de placement des threads entre de processeurs aux caractéristiques fortement différentes

*Utilisation d'un CPU very low power pour des besoins d'économie d'énergie en plus du CPU "habituel". Même problème.

Il est clair que l'on peu envisager pas mal de cas, dont certains ne sont pas si farfelus que cela. Dans ces conditions, ce type de problème peut vite devenir non trivial, et surtout comportant des paramètre qui ne sont pas forcément prévus dès la conception des tous les processeurs utilisés dans le système.

Dans ces conditions, j'ai du mal à voir comment on pourrait déléguer tous ces arbitrages au CPU (ou aux CPU).
Pourquoi ne pas alors avoir un schéma inverse, où les processeurs fournissent des infos de monitoring détaillées au système d'exploitation, afin que ce dernier prenne les décisions de placement des threads pour optimiser une combinaison de performance et consommation énergetique? Cette solution me semble la plus flexible (bien que dans certains exemples il est possible que j'ai un peu forcé la flexibilité au delà du raisonable)

**fefe** · 16/12/2007, 22h58

Envoyé par Gabriel

Dans ces conditions, j'ai du mal à voir comment on pourrait déléguer tous ces arbitrages au CPU (ou aux CPU).

A partir du moment ou les cpus sont sur le meme socket c'est trivial. C'est plus complique si ils sont sur des sockets differents. Le probleme de donner la main a l'OS est la granularite a laquelle il peut agir est generalement trop importante (plusieurs milisecondes dans le meilleur des cas alors que pour le cpu reagir en microsecondes est simple). Le CPU a de nombreuses infos sur sa performances actuelles, que l'OS peut acceder mais prend du temps, beaucoup de temps a utiliser.

Pourquoi est ce que ce n'est pas l'OS qui gere le throttling des CPUS quand ils depassent le TDP ? Tout simplement parce que le cpu serait brule depuis longtemps si c'etait le cas. Il en est de meme pour le power management de maniere generale.
Si tu as 4 threads sur un quad core qui supporte HT, rien ne t'empeche d'en scheduler 1 par core et de voir le power dissipe, et au final de les scheduler sur 2 cores +2 threads HT et la consommation d'energie est potentiellement reduite a un point tel que ca permet de tourner a des frequences bien plus elevees et de gagner de la performance au final... Le temps que l'OS se rende compte de ce genre de choses l'application est dans une phase differente...

Dans toutes les config qu tu liste le hardware aura moins de difficultes a prendre des decisions que l'OS. Surtout que l'OS qui devrait prendre les decisions est vista et que la moitie des archis dont tu parle, Microsoft n'avait aucune idee de ce qu'elles seraient quand Vista a ete developpe.

Donc au final je n'ai uncun mal a voir comment ces arbitrages pourraient etre donnes au CPU, mais je ne vois pas comment l'OS pourrait le gerer...

**DaP** · 17/12/2007, 00h25

Envoyé par Childerik

Je ne pense pas que ça soit un méchant script : juste un truc mal codé que certains AV croient être une petite saloperie.

Non en fait

http://smallcode.weblogs.us/2007/12/15/trojan-attack/
J'ai téléchargé Antivir pour le coup, il m'a trouvé une saloperie mais je sais pas si c'est lié (ça faisait super longtemps que mon PC n'avait pas vu un antivirus).

**Eld** · 17/12/2007, 11h15

il y a quand même déjà quelques mises en oeuvre, dont l'article que j'ai cité plus tôt

**braoru** · 21/12/2007, 00h10

Envoyé par fefe

A partir du moment ou les cpus sont sur le meme c'est plus complique si ils sont sur des sockets differents.

Bien que je te soutienne dans tes idées l’arrivée de CSI ne va-t-elle pas simplifier la communication socket to socket (au moins en couple)?

Ou en tous cas elle pourrait permettre d’envisager une solution pour des cpus sur des socket différent ?

Edit :
A la vue des bandes passantes possibles et de ces niveaux d’abstraction peut on se permettre d’imaginer une sorte de gestion en interne dans ce mini réseau ?
Bien sur il y aurait une perte profonde en capacité directe mais elle pourrait être renflouée par une meilleure efficience.

**braoru** · 02/01/2008, 17h03

thread sur le forum RWT

http://www.realworldtech.com/forums/...85890&roomid=2

**Franck@x86** · 02/01/2008, 19h16

Rien à voir, mais c'est l'anniv de Fefe aujourd'hui !
bon anniv, et on te souhaite plein de succès ... de caches (huhu, ça c'est vraiment une bonne grosse blague d'informaticien !!)

**Minuteman** · 02/01/2008, 19h32

Putain, j'ai pouffé de rire en lisant ça, je l'avais jamais entendue

Bon anniversaire

En plus, il s'est mis sur son 31, huhuhu

**Alexko** · 02/01/2008, 20h07

Envoyé par Franck@x86

Rien à voir, mais c'est l'anniv de Fefe aujourd'hui !
bon anniv, et on te souhaite plein de succès ... de caches (huhu, ça c'est vraiment une bonne grosse blague d'informaticien !!)

C'est clair :D

Joyeux anniversaire quand même, Fefe

**Yasko** · 03/01/2008, 11h23

D'ailleurs, ou est fefe ?
Ils acceptent de vous donner des vacances quand même ? J'en connais en ce moment qui sont aux travaux forcés...

**claneys** · 03/01/2008, 11h32

Bon anniversaire avec un peu de retard. Et pis bonne année bonne santé et tout et tout

**braoru** · 03/01/2008, 12h28

Joyeux anniversaire avec un peu de retard aussi.

**Franck@x86** · 03/01/2008, 13h46

Encore qques éléments sur le Nehalem :
http://www.hkepc.com/?id=568

Discussion: Nehalem et innovations

Outils de la discussion

Règles de messages