K10 et innovations

[Franck@x86]

Effectivement la seul "nouveauté" semble bien être le L3 "sharing aware".
Pour ceux que ça intéresse il y a un bon article sur le partitionnement des caches partagés qui a été présenté à la dernière conférence MICRO.
Le lien de la conf : http://www.microarch.org/micro39/
Le lien de l'article : www.ece.northwestern.edu/~rjoseph/eecs453/papers/quereshi-micro2006.pdf

Bonne journée à tous.

Réveil#3 :
-----------

J'ai également trouvé un papier super intéressant écrit par des ingés chez Intel : http://www.cpuid.com/download/paper03.pdf

C'est de la simu, mais y'a des choses très très intéressantes, en particulier l'évolution du tx d'échec des caches en fonction du nombre de threads concurrents. Ainsi on apprend que si on multiplie le nombre de threads concurrents par quatre, le tx d'échec du cache partagé ne fait "que" doubler.
Puis d'autres résultats sur les caches discrets, les caches exclusifs ...

[fefe]

Réveil#1 :
----------

Tu vois qques semaines pour tout digérer
Bon j'ai pas compris ce point : "qui dans le cas d'inclusivite sait si un autre core a la donnee et qui est owner". Je ne vois pas en quoi la relation inclusive intervient ?

Dans le cas d'un cache inclusif, le dernier niveau de cache a forcement une copie des donnees si un autre core l'a, dans le cas d'un cache exclusif le fait de ne pas trouver une donnee dedans n'est nullement la preuve qu'aucun autre niveau de la hierarchie n'a une copie de cette donnee.

Cela ne dit pas qui est owner de cette ligne de cache (sauf si tu attaches a chaque ligne de cache en plus de son etat MESI un vecteur de bit disant quel core a l'ownership), mais cela te permet de savoir si tu dois snoop les autres caches quand un core essaye de devenir owner de cette ligne.

Dans le cas d'un cache exclusif tu dois snoop les autres cores a chaque acces meme quand la donnee n'est pas presente dans le dernier niveau de cache (ce qui explique pourquoi le K8 a une copie des tags du premier niveau de cache qui ne sert qu a faire des snoops, car sans ca une grande partie de la bande passante du cache L1 serait consommee par des snoops).

Dans le jargon, on dit que un cache partage inclusif agit comme un snoop filter.

PS: dans le cas d'un cache non exclusif mais a inclusion non garantie tu ne peux pas appliquer ce genre d'astuces. (Weak inclusivity = tu n'envoies pas de back invalidate aux caches prives quand tu evict une donnee du cache partage)
PPS: desole aucune idee sur comment traduire ca de franglais a francais

Bonne digestion.

[fefe]

Réveil#2 :
----------

Arrête moi si je me trompe, mais cette méthode améliore le partage entre les threads, mais ne lutte pas directement contre les risques de conflits de cache (éviction / mise en cache concurrentes) ?
En fait j'y réfléchis depuis qques temps là dessus, et y'a pas réellement de moyen de réduire les conflits autrement que par la taille. Si on réserve des ways, ça supprime tout l'intérêt d'une allocation dynamique, correct ?

Cette methode permet d'accelerer les echanges de donnees qui sont partagees par 2 threads mais effectivement n'aide pas a la repartition des ressources entre les threads.

Le partage completement dynamique (donc en utilisant un LRU traditionnel) favorise les applications qui accedent regulierement au niveau de cache partage, ce n'est pas necessairement la meilleure politique: typiquement un bzero execute par un core flushera tout le cache partage et c'est mauvais et frequent. Le partage completement statique (plus ou moins equivalent a des caches non partages) evite la pollution mutuelle des threads.
Donc rien n'empeche d'envisager une solution intermediaire ou si tu disposes d'un cache avec une associativite importante tu reserves certaines voies a chaque thread et partage un pool restant. Apres savoir comment faire ce partage (statiquement ou dynamiquement) est un sujet de recherche qui genere des publications scientifiques en ce moment.

[Franck@x86]

en épluchant le pdf je suis tombé sur un truc qui semble assez sympa :
"Separate CPU core and Northbridge power planes : allow processors to reduce voltage while NB continues to run (power savings)".
En dessous : "Also can apply additionalvotlage to NB to raide the NB frequency".

Je me demandais comment un seul contrôleur mémoire pourrait alimenter quatre cores, j'ai ma réponse

[fefe]

Si le Northbridge n'est pas sur un power-plane separe cela empeche d'eteindre les processeurs (ou de les mettre au voltage minimum ou a la frequence minimum) et de maintenir l'affichage video en meme temps. Une fois decouple tu peux avoir tes processeurs dans un mode d'economie d'energie avancee tout en continuant a acceder a ta memoire pour continuer a afficher.

Ca veut donc dire une consomation d'energie plus faible quand les processeurs sont idle, ou equivalent au K8 car 4 processeurs+ 2MB L3 il doit y avoir bcp de courants de fuite (euh leakage c'est bien courant de fuite ?).

Est ce que tu as vu si les processeurs etaient aussi sur des power-planes independants ? Ou juste un pour les processeurs un pour le northbridge? Gerer de multiples power-planes est particulierement complique et couteux (les multiplier augmente la consommation totale donc il faut le faire a bon escient) mais ca permet une gestion tres efficace de la consommation.

[edited] Tentative de francisation... J'ai un peu de mal avec le francais technique.

[Fanche]

heu fefe, je ne remets absolument pas en doute tes compétences et je te remercie de nous en faire part, mais j'ai une toute petite requête, peux tu essayer d'éviter quand c'est possible les termes anglais... du type power display core leak, d'un autre côté je me doute bien que tu dois pas avoir bcp de temps pour poster ici. C'est juste que ce que tu dis n'est pas simple et avec le décodage des termes en plus ben moi j'comprends pas tout tjs.
Maintenant c'est juste une demande qui ne doit refléter que moi, donc à ne pas donner trop d'importance.

[fefe]

J'ai edite le dernier post, des que je trouverai un peu de temps (il y a des periodes ou j'ai plus de temps, mais la ca tarde a venir) j'essayerai d'ecrire quelque chose sur les caches pour essayer d'eclaircir un peu mes reponses precedentes. Sinon je suis sur que Franck va s'en charger :D

Des fois je me demande si je ne devrais pas repondre directement en anglais ca serait peut etre plus clair .

[Fanche]

Des fois je me demande si je ne devrais pas repondre directement en anglais ca serait peut etre plus clair .

ben c'est vrai qu'à y réfléchir ça serait peut-être mieux. Moi perso j'ai du mal à gérer 2 langues à la fois, du coup je préfère la vosto à la vostf par exemple.
Enfin d'un côté je suis pas un pro des langues...

[fefe]

Cela fait plus de 5 ans que je ne parle plus francais du tout donc ca n'aide pas non plus.

[Fanche]

ha mince!


ça explique alors...

[Franck@x86]

Je vais prendre un petit exemple pour expliquer ce que j'ai compris.
Supposons donc un processeur composé de N cores chacun doté de son L1 et qui se partagent un L2.

Mettons que core#1 doit modifier une ligne de son cache L1 (suite par exemple à une écriture). Avant de modifier une ligne, il doit savoir à quel core appartient cette ligne, càd quel core est à l'origine de la création de cette ligne, c'est l' "owner".

Si le L2 est inclusif, il contient une copie de cette ligne. Dans ce cas, si un tag a été ajouté indiquant quel core est le propriétaire de la ligne, c'est facile : core#1 cherche la ligne dans le L2, en déduit le core propriétaire, et c'est une affaire réglée.

Si le cache est exclusif la donnée n'est a priori pas dans le L2. core#1 doit donc interroger chaque core jusqu'à trouver le bon (il "snoop"). Sachant qu'un core modifie souvent son L1, vous imaginez le trafic qui en résulte.

Comme le cache inclusif permet de se passer de la phase snoop, on dit qu'il jour le rôle de snoop filter.

Le back invalidate maintenant.
En config inclusive, core#1 modifie une ligne de son L1. La ligne similaire du L2 est donc aussi modifiée pour raison de cohérence. Or, un autre L1 peut contenir la même donnée, donc le L2 envoie une commande de maj vers les autres L1, le "back invalidate". Une fois de plus ce truc prend un temps fou, car il faut imaginer que ça n'arrive pas une fois de temps en temps.
Donc la soluce c'est de ne pas faire de maj dans tous les L1. On économise de la bande passante, au détriment de l'inclusion, car la stricte similarité L1/L2 n'est plus respectée. C'est la relation "weakly inclusive" qu'on retrouve dans le Core 2 Duo.

Alors évidemment un cache "weakly inclusive" perd son inclusion stricte, et par là-même son rôle de "snoop filter". Résultat : il doit "snooper" comme un cache exclusif.

Bon j'espère que ça vous éclaire un peu.

[Foudge]

Tes explications sont très claires :jap:

Je pensais pas qu'un cache L2 (ou L3) partagé entrainent de tels inconvéniants, que ce soit en fonctionnement inclusif ou exclusif. Du coup, j'ai du mal à imaginer comment ça peut malgré tout être plus efficace qu'un cache L2 (ou L3) privé. Si Intel et AMD ont fait de tel choix, c'est pas par effet de mode mais par efficacité de ce système :D

[fefe]

Le back invalidate maintenant.
En config inclusive, core#1 modifie une ligne de son L1. La ligne similaire du L2 est donc aussi modifiée pour raison de cohérence. Or, un autre L1 peut contenir la même donnée, donc le L2 envoie une commande de maj vers les autres L1, le "back invalidate". Une fois de plus ce truc prend un temps fou, car il faut imaginer que ça n'arrive pas une fois de temps en temps.
Donc la soluce c'est de ne pas faire de maj dans tous les L1. On économise de la bande passante, au détriment de l'inclusion, car la stricte similarité L1/L2 n'est plus respectée. C'est la relation "weakly inclusive" qu'on retrouve dans le Core 2 Duo.

Alors évidemment un cache "weakly inclusive" perd son inclusion stricte, et par là-même son rôle de "snoop filter". Résultat : il doit "snooper" comme un cache exclusif.

Bon j'espère que ça vous éclaire un peu.

Ce que tu decris est illegal, tu n'as pas le droit d'avoir une donnee qui est modifiee dans le L2 et pas modifiee dans un des L1 sans la marquer invalide. Si tu le fais cela resulte en une execution incorrecte potentielle du programme qui consommera la donnee pas a jour. Le seul cas ou tu as le droit de ne pas envoyer le back invalidate est si la donnee que tu evinces du L2 n'est pas dans l'etat modifie.

[fefe]

MESI protocol,
From Wikipedia, the free encyclopedia

The MESI protocol (known also as Illinois protocol) is a widely used cache coherency and memory coherence protocol, which was later introduced by Intel in the Pentium processor to "support the more efficient write-back cache in addition to the write-through cache previously used by the Intel 486 processor" [1].


Every cache line is marked with one of the four following states (coded in two additional bits):

M - Modified: The cache line is present only in the current cache, and is dirty; it has been modified from the value in main memory. The cache is required to write the data back to main memory at some time in the future, before permitting any other read of the (no longer valid) main memory state.
E - Exclusive: The cache line is present only in the current cache, but is clean; it matches main memory.
S - Shared: Indicates that this cache line may be stored in other caches of the machine.
I - Invalid: Indicates that this cache line is invalid.
A cache may satisfy a read from any state except Invalid. An Invalid line must be fetched (to the Shared or Exclusive states) to satisfy a read.

A write may only be performed if the cache line is in the Modified or Exclusive state. If it is in the Shared state, all other cached copies must be invalidated first. This is typically done by a broadcast operation known as Read For Ownership (RFO).

A cache may discard a non-Modified line at any time, changing to the Invalid state. A Modified line must be written back first.

C'est pour ca que tu es oblige de propager les back invalidate sur des donnees modifiees.

A cache that holds a line in the Modified state must snoop (intercept) all attempted reads (from all of the other CPUs in the system) of the corresponding main memory location and insert the data that it holds. This is typically done by forcing the read to back off (i.e. to abort the memory bus transaction), then writing the data to main memory and changing the cache line to the Shared state.

Tu n'es pas necessairement oblige de faire le write back en memoire dans le cas weakly inclusive/non inclusif a partir du moment ou tu as mis a jour les caches desqueles tu n'as aps evince la donnee.

A cache that holds a line in the Shared state must also snoop all invalidate broadcasts from other CPUs, and discard the line (by moving it into Invalid state) on a match.

Tu n'es pas oblige de faire cette derniere partie si tu ne desires pas maintenir l'inclusivite de ta hierarchie.

A cache that holds a line in the Exclusive state must also snoop all read transactions from all other CPUs, and move the line to Shared state on a match.

The Modified and Exclusive states are always precise: i.e. they match the true cacheline ownership situation in the system. The Shared state may be imprecise: if another CPU discards a Shared line, and this CPU becomes the sole owner of that cacheline, the line will not be promoted to Exclusive state (because broadcasting all cacheline replacements from all CPUs is not practical over a broadcast snoop bus).

In that sense the Exclusive state is an opportunistic optimization: If the CPU wants to modify a cache line that is in state S, a bus transaction is necessary to invalidate all other cached copies. State E enables modifying a cache line with no bus transaction.

[EPIC]

Guère aisé a appréhendé comme sujet, mais très instructif

Si j'ai bien compris l'un des gros point noirs des "systèmes" multi core, multi processeurs c'est entre autres la cohérence des caches et le trafic qu'elle génère pour maintenir la synchronisation de données entre eux, se qui consomment une bande passante relativement importante.

Cette consommation de bande passante est d'autant plus importante que les données changent régulièrement ce qui oblige les caches L1 à mettre à jour leurs données et donc à snooper à mort sur le ou les bus.

Existe-il des modèles théoriques et génériques ou des études qui permettent de deviner, quantifier (pas nécéssairement avec une grande précision) la consomation en bande passante que génèrent telles ou telles architectures multicore ?

Dans le même ordre d'idée et afin de réduire les snoops et la consommation en bande passante, la solution la plus simple ne serait elle pas de mutualiser le cache L1 pour un même ensemble de cores (2, 4 , 6 , etc...) visiblement cela semble être la logique suivit pas SUN Microsystem sur son futur processeur 16 cores "Rock" ou les caches L1 (I et D) se retrouvent partagé pour un même ensemble de 4 cores. Est-ce vraiment pour cette raison ou y a t'il un autre intéret à mutualiser les ressources mémoires (cache L1) pour plusieurs cores ?

[fefe]

La seule methode assez simple et suffisament precise que je connaisse est l'emploi de simulateurs de caches. Il suffit d'instrumenter une application existante pour que chaque acces a la memoire fasse aussi appel a un simulateur de caches (c'est un peu plus complexe en multithread mais reste relativement simple et il existe beaucoup de code libre pour le faire). Quand on dispose du code c'est tres simple a faire, mais il est aussi possible d'instrumenter des binaires.

La methode la plus precise que je connaisse est de simuler le fonctionnement complet du microprocesseur et d'executer le programme sur un simulateur precis (simplescalar est le seul que je connaisse qui soit publique et sa precision est tres discutee), en effet l'ordre et le timing de chacune des operations memoire a un impact sur le taux de succes/echec/snoop.

Si on ne veut pas faire appel a un simulateur mais que l'on connait assez bien son application (ou qu'elle est suffisament simple), cela peut se faire dans un modele analytique en utilisant des probabilites (definies a l'aide de ta "connaissance" de l'application). Ca peut se faire dans excel mais par experience des que l'on sort d'un programme calculatoire avec quelques boucles assez simple on a vite tout faux. Afiner une telle methode prend souvent plus de temps que d'utiliser un simulateur de cache.

Est-ce vraiment pour cette raison ou y a t'il un autre intéret à mutualiser les ressources mémoires (cache L1) pour plusieurs cores ?

Il y a generalement peu d'interet a partager un cache de premier niveau:
-La plupart des programmes parralleles accedent beaucoup plus souvent a des donnees privees que partagees (l'inverse les rendrait lents sur la plupart des machines paralleles)
-un cache sert a accelerer les acces les plus probables, cela a generalement peu de sens d'optimiser un cache pour des evenements supposes assez rares.
- plus un cache a de ports d'acces (permettant a plusieurs agents des acces simultanes) plus il est lent et plus il consomme
- afin de construire un cache a multiple ports d'acces assez rapide on a tendance a repliquer beaucoup de structures, un cache a 2 ports de lecture aussi rapide qu'1 cache a 1 port sera grosso modo 2 fois plus gros.
- les ports en ecriture multiple sont tres couteux car la replication ne permet pas de contourner les problemes de latence
- quand un cache devient trop lent on a tendance a intercaler un cache plus petit et plus rapide avant celui-ci (cela devient donc un cache de niveau 2)
- si un cache partage est trop petit le taux d'echec devient tres important et donc tous les acces memoires deviennent plus lents.

Dans des cas particuliers cela peut avoir un sens de partager un L1:
-chaque core effectue des acces memoires relativement infrequents ce qui permet de partager aussi le nombre de ports d'acces.
-l'application que l'on desire executer a ete parallelisee avec un grain tres fin et les acces a de la memoire partagee sont plus frequents que ceux a de la memoire privee (certaines applis dsp) .
-l'application ne tire presque aucun benefice de caches de petite taille et rapides, enquel cas cela revient a prendre un systeme a L2 partage et enlever les L1. On se retrouve avec un gros cache de premier niveaupartage, et lent. Des applications a grosse emprunte memoire et acces plutot aleatoires pourraient beneficier d'une telle topologie (certaines applis serveur).

[Franck@x86]

Juste une précision : le screenshot cpuz du K10 overclocké à 3GHz est un faux. L'info commence à être relayée, alors autant couper court tout de suite.

[braoru]

Qu’esse qui te fait dire ça ? (attention je ne remets pas en cause je suis juste curieux)

[fefe]

Si il le dit, il y aura des meilleurs fakes .

[braoru]

ok

[Dandu]

"Le doute plane sur l’authenticité de cet overclocking. Franck Delattre, le développeur de CPU-Z nous a en effet informé que le logiciel est pour l’heure incapable de détecter le cache de niveau 3 des K10. Ceci permet donc d’affirmer que les screenshots publiés par nos confrères de Fudzilla sont des faux."

Vu sur Presence-pc

[claneys]

http://en.wikipedia.org/wiki/AMD_K10

ça reprend la plupart des choses abordées ici mais si ça interresse certains

[fefe]

L'article le plus complet publie a ce jour sur le K10 est sur RWT:
http://www.realworldtech.com/page.cf...WT051607033728

[claneys]

Lirais ça à tête reposé ^^. Merci du lien.

[Franck@x86]

http://www.amd.com/us-en/assets/cont...docs/40546.pdf

Cf appendix A pour qques détails sur l'archi.

[Foudge]

Franck@x86> T'as des infos précises sur le SSE4 d'AMD, notamment sa détection ? Le PDF indique que ces instructions sont nommées SSE4a et seraient composées de (seulement !?!) 4 instructions. Mais rien sur la détection.

Une source officieuse indique ceci : CPUID Fn8000_0001_ECX [bit:6]

Tu confirmes ou toi aussi t'es dans le brouillard ? :D

[Franck@x86]

pas la moindre idée, désolé.

[Franck@x86]

Franck@x86> T'as des infos précises sur le SSE4 d'AMD, notamment sa détection ? Le PDF indique que ces instructions sont nommées SSE4a et seraient composées de (seulement !?!) 4 instructions. Mais rien sur la détection.

Une source officieuse indique ceci : CPUID Fn8000_0001_ECX [bit:6]

Tu confirmes ou toi aussi t'es dans le brouillard ? :D

C'est bien ça.

D'ailleurs :
http://www.fudzilla.com/index.php?op...=1342&Itemid=1

Ce coup-ci c'est pas un fake.
Tamas m'a confirmé que Everest est capable de lire le L3 sur AMD, ainsi que le SSE4A.

[lhuser]

L'Agena FX et l'Agena remplacent les Athlon 64 et Athlon 64 FX. Le Kuma est comme le Sempron, mais y'a plus d'allure!

4GHZ en Hypertransport et le CPU CLK est meme pas rendu la?! Hmm, je pense qu"AMD se plante trop.

[Fanche]

4GHZ en Hypertransport et le CPU CLK est meme pas rendu la?! Hmm, je pense qu"AMD se plante trop.

ben je vois pas trop là, ça veut rien dire, à part que les coeurs consomment de la bande passante ou sinon qu'ils veulent pas avoir à changer de bus tout de suite...
Et puis pour alimenter 4 coeurs il doit falloir un minimum de bande passante non?
(je m'abstiens des commentaires comme quoi la fréquence ne fait pas tout)