K10 et innovations

[fefe]

Source : Madcho :whistle:

CPU Core IPC Enhancements:
Advanced branch prediction
- Dedicated 512-entry Indirect Predictor
- Double return stacksize
- More branch history bits and improved branch hashing
History-based pattern predictor

Un predicteur indirect et qq tweak ici la (equivalent a wmt->psc ou cd->c2d)

32B instruction fetch
- Benefits integer code too
- Reduced split-fetch instruction cases

Celui la est interressant, as supposer qu'ils passent a 4 fetch/decode/allocate en parallele, quel est le pourcentage de quadruplet d'instructions x86 qui depasse les 16 octets et justifie un passage a 32 ? Sur du code SSE4 et 64 bits ca doit arriver de temps en temps mais sur du code 32 bits je ne vois pas ca se produire tres souvent.

Core prefetchers
- DC Prefetcher fills directly to L1 Cache
- IC Prefetcher more flexible
* 2 outstanding requests to any address

Mouais, ca ne veut pas dire grand chose, mais bon vu qu'ils ont pas mal de marge d'amelioreation de ce cote c'est probablement un placeholder qui en cache plus.

Sideband Stack Optimizer
- Perform stack adjustments for PUSH/POP operations "on the side"
- Stack adjustments don't occupy functional unit bandwidth
- Breaks serial dependence chains for consecutive PUSH/POPs

Il etait temps , meme commentaire que les branch

Out-of-order load execution
- New technology allows load instructions to bypass:
* Other loads
* Other stores which are known not to alias with the load
- Significantly mitigates L2 cache latency

<=> (CD=>C2D)

TLB Optimisations
- Support for 1G pages
- 48bit physical address (256T
- Larger TLBs key for:
* Virtualized workloads
* Large-footprint databases and
* transaction processing

AMD only.

Additional fastpath instructions
– CALL and RET-Imm instructions
– Data movement between FP & INT

Les comm FP<=>int sont tres lentes sur K8 et etaient clairement une faiblesse versus l architecture core (en fait tellement lent que c'etait une faiblesse meme vs P4). En general ce n'est pas fondamental pour la perf, mais les applis qui en faisaient trop (povray dans mes souvenirs par ex) exposaient une faiblesse du K8.

Bit Manipulation extensions
- LZCNT/POPCNT

Enfin !

SSE extensions
- EXTRQ/INSERTQ (SSE4A)
- MOVNTSD/MOVNTSS (SSE4A)
- MWAIT/MONITOR (SSE3)

rattrapage standrad de version de SSE.

Comprehensive Upgrades for SSE
- Dual 128-bit SSE dataflow
- Up to 4 dual precision FP OPS/cycle
- Dual 128-bit loads per cycle
- New vector code, SSE128
- Can perform SSE MOVs in the FP "store" pipe
- Execute two generic SSE ops + SSE MOV each cycle (+ two 128-bit SSE loads)
- FP Scheduler can hold 36 Dedicated x 128-bit ops
- SSE Unaligned Load-Execute mode:
* Remove alignment requirements for SSE ld-op instructions
* Eliminate awkward pairs of separate load and compute instructions
* To improve instruction packing and decoding efficiency

Plus ou moins equivalent a CD=> C2D. Ils ont toujours leur scheduler FP separe (ce qui est une des sources de penalite quand on communique avec int). Ils ont 3 ports 128 bits qui peuvent faire du FP, 1 mul, 1 add, 1 mov/store alros que C2D a 1Mul, 1 add , 1 store, 1 mov+shuffle. Au final c'est kif-kif. A propos de l'alignement il semble que ce soient juste des fix mineurs ameliorant les conditions de fusion, mais ne permettant pas au load non alignes de s'executer de la meme maniere qu'un load aligne. De toutes facons en dehors de l'estimation de mouvement en video et des codes compiles avec les pieds ca n'a pas d'impact (et en video il y a le lddqu de SSE3 qui fix le pb).

Quad-core
- Native quad-core design
- Redesigned and improved crossbar(northbridge)
- Improved power management
- New level of cache added, L3 VICTIM

Je crois que je vais partir en croisade contre la notion de "native" quad core design. Tu mets 4 core sur un meme package c'est un quad core point (meme si ils communiquent entre eux par pigeons voyageurs). Apres si tu design un cache partage ou a des liens point a point entre les core ou meme un bus on package c'est une archi differente mais ca ne le rend pas plus "native" qu'un autre. En gros ils essayent de dire que leur version du quad core est meilleure que celle du concurent intrinsequement alors que c'est loin d'etre evident. Il y a des applis qui preferent avoir des caches split, d'autres qui preferent le cache shared, des applis pour lesquelles un bus entre les n-cores sera plus efficace pour acceder a la memoire qu'un hop a travers un autre core, etc... Bref le native a autant de sens que le "hyper" de la version d'Intel du simultaneous multithreading.

Quand au L3 etant un victim cache, quand tu as deja les protocoles tout faits pour des victim cache plutot que des caches inclusifs, pourquoi s'ennuyer a faire autrement. Secondo quand ton cache est assez petit par rapport a la somme des niveux inferieurs cela peut presenter un interet.

Redesigned northbridge for higher bandwidth
- Increase buffer sizes
- Optimize schedulers
- Ready to support future DRAM technologies

Standard, la frequence et le nombre de core augmente relativement a celle du controleur, donc il faut avoir plus de buffering, ca ouvre plus d'opportunites de scheduling (plus de stream en //) et la DDR3 arrive.

Power management - DICE(Dynamic Independent Core Engagement)
- Supports separate CPU core and memory controller power planes to allow CPU to lower its power state while the memory controller is running full bore
- Enhanced AMD's PowerNow allows individual core frequencies to lower while other cores may be running full bore

Normal sachant que l'on est dans des plateformes dont la perf est limitee par le power, donc reduire le power de tout ce qui n'est pas on est forcement une bonne idee. Je suppose que la granularite de ce type de management ne va pas cesser de se reduire a l'avenir, aussi bien chez Intel que AMD. A priori la dessus ils sont un peu en avance sur Intel.

Dedicated L1 cache
- 256bit 64kB instruction, 64kB data
- 2 x 128bit loads/cycle
- reduced latency

Elargi le datapath pour le FP128, je serais curieux de voir si ils ont descendu la latence de 1 cycle ou si il supporte juste une plus haute frequence et que la reduction de latence est donc en ps plutot qu'en cycles.

Dedicated L2 cache
- 128bit 512kB
- 128bit bus to northbridge
- reduced latency

J'espere bien que la latence est reduite, parce que vu d'ou ils partent sur leur version 65nm du K8 c'est pas difficile (ils ont bcp ajoute en passant de 90 a 65).

Shared L3 cache
- Victim-cache architecture maximizes efficiency of cache hierarchy
- Fills from L3 leave likely shared lines in the L3
- Sharing-aware replacement policy
- Exapndable

La partie interressante est le "sharing aware" LRU, je me demande ce qui peut se cacher derriere ca ? A priori ils empechent peut etre 1 core de monopoliser toutes les way du LLC. Le victime cache, quand tu as 4x 512k de L2 et 2M de L3 un L3 inclusif est strictemen inutile donc ils n'avaient pas le choix.

Independent DRAM controllers
- Concurrency
- More DRAM banks reduces page conflicts
- Longer burst length improves command efficiency
- Dual channel unbuffered 1066 support(applies to socket AM2+ and s1207+ QFX only)
- Channel Interleaving
Optimized DRAM paging
- Increase page hits
- Decrease page conflicts
Write bursting
- Minimize Rd/Wr Turnaround
DRAM prefetcher
- Track positive and negative, unit and non-unit strides
- Dedicated buffer for prefetched data
- Aggressively fill idle DRAM cycles
HyperTransport 3
- 4 16bit cHT links
- up to 5200MT/s per link
- un-ganging mode: each 16bit HT link can be divided in two 8bit virutal Links

Plus de core sur un meme die => besoin de plus de bande passante memoire et surtout besoin de track plus de pages en // parce que le nombre de streams parallele augmente. Tout cela est parfaitement raisonable.

Virtualization improvements
- Nested Paging(NP):
* Guest and Host page tables both exist in memory.(The CPU walks both page tables)
* Nested walk can have up to 24 memory acesses! (Hardware caching accelerates the walk)
* "Wire-to-wire" translations are cached in TLBs
* NP eliminates Hypervisor cycles spent managing shadow pages(As much as 75% Hypervisor time)
- Reduced world-switch time by 25%:
* World-switch time: round-trup to Hypervisor and back

Je n'ai pas encore trop regarde les benchmarks de virtualization, mais c'est plutot une preparation pour un avenir semi lointain que quelque chose d'interressant aujourd'hui. Les performances actuelels des implementations hard de machine virtuelles etant plutot mauvaise d'apres ce que j'en ai entendu (un peu comme toute premiere implementation d'une technologie pas encore eprouvee).

[fefe]

Merci Foudge.

On croirait vraiment lire les specs du Core 2 Duo.

Le L3 est nommé victim-cache (= exclusif) mais pas le L2, alors qu'il l'est également (du moins sur K8).
Je me pose quelques questions sur l'efficacité de deux étages de victim-caches (??).

(fefe required)

Comme dit plus haut, ils n'avaient pas le choix pour le L3 vu que la somme des L2 fait la taille du L3, un cache inclusif n'aurait d'interet que quand il y a du sharing entre les cores a une granularite assez faible, ce qui dans les applis actuelles est rare.
La difficulte d'un L3 exclusif partage est que quand un core veut l'ownership d'une ligne il ne suffit pas de le demander au L3 (qui dans le cas d'inclusivite sait si un autre core a la donnee et qui est owner) il faut effectivement aller la demander aux autres niveaux de caches prives, et si le L1 et le L2 sont exclusifs il faut aller le demander aux 2. Il y a des astuces pour eviter ca comme d'avoir une copie des tags des caches prives de niveaux inferieur a cote du L3 mais ca prend de la place.

Je suppose que la raison pour laquelle le L1/L2 sont exclusifs est historique plus qu'autre chose, c'est plus facile d'updater un design que d'en refaire un et de revalider tous les protocoles. On y gagne un peu de taille (128k) mais je doute que cela se sente vraiment quand on a un gros L3 derriere.

[Franck@x86]

Laisse nous qques jours pour digérer tout ça et faire des commentaires plus fouillés qu'un simple "merci fefe pour ces explications" :D

Ah si j'ai une question tiens : pourquoi le passage en 65nm du K8 s'est accompagné d'une augmentation de latence L2 ? c'est volontaire juste en prévision des fréquences plus importantes, ou effet indésirable du à ... à quoi en fait ?

Autre question / interrogation : je ne suis pas convaincu qu'AMD ne repasse pas en inclusif (L1/L2 s'entend) pour des raisons de facilité, enfin j'ai du mal à croire que ce soit juste de la flemme. Je pense que le rapport (L2/L1) est encore trop faible pour que l'inclusif soit vraiment intéressant (il vaut 4 sur un K8/512 et 64 sur un C2D/4M). Pour le L3 en effet, la question ne se pose même pas.

merci fefe pour ces explications

[Lissyx]

Je pense qu'ils ont dû faire ça pour améliorer les rendements, et supporter la baisse de prix et la hausse de demande avec tous les contrats OEM ?

[Franck@x86]

En fait je me demande si une latence élevée n'est pas qu'un demi défaut sur un cache exclusif, ceci expliquant cela. Et augmenter la latence permet une plus grande plage de fréquence, ce qui au final à un impact positif sur les perfs.

[Lissyx]

Aussi, j'avais oublié ça, dans la course face à Intel, ils doivent de toute façon essayer de grapiller partout.

[Yasko]

Je crois que je vais partir en croisade contre la notion de "native" quad core design. Tu mets 4 core sur un meme package c'est un quad core point (meme si ils communiquent entre eux par pigeons voyageurs).

C'est pas en rapport avec le nombre contrôleurs HT par core ? (3 au lieu de 2, comme sur les Opteron 8xx).

Edit :
Euh, je crois que je viens de dire une grosse connerie, non ?
Les cores ne sont pas reliés par liens HT (tous connectés au SRQ)

[Foudge]

fefe> AMD ne dit pas (ni ne sous-entend) qu'un Core 2 Quad n'est pas un quadcore. Dans "native quadcore design", il y a "native" et "design" et ça change tout (d'un point de vue sens). Ils insistent donc sur le fait que le K8L est monodie et qu'il a été pensé et optimisé dès sa conception pour un tel fonctionnement.
Ensuite faut voir si ça apporte réellement quelque chose, mais c'est un autre débat...

[Marc]

En fait je me demande si une latence élevée n'est pas qu'un demi défaut sur un cache exclusif, ceci expliquant cela. Et augmenter la latence permet une plus grande plage de fréquence, ce qui au final à un impact positif sur les perfs.

Ah, parce qu'en fait les A64 65nm vont plus haut en fréquence que les A64 90nm ?

[fefe]

Ce qui me surprend le plus c est que ca n'a pas ete corrige dans un stepping. Parce qu'un tel changement je ne vois personne de sense le faire sans de vraies bonnes raisons vu a quel point ca fait mal.
Donc les 3 options a mon avis:
-une merde, un bug, qui a ete patche de maniere un peu brutale et qui necessite des changements trop serieux pour un simple stepping.
-passer le lookup des tags de parallele a sequentiel avec la lecture des donnees. Ca permet des economies serieuses de power au prix de latence augmentee. En gros cela correspond a ne pas lire toutes les way en parallele de la comparaison des tags mais d'attendre de savoir dans quelle way la donnee est (donc sequentiel avec la comparaison des tags). En combinaison avec ca on peut aussi attendre de savoir si c'est un hit pour scheduler les operations dependantes, ca coute quelques cycles de plus mais on ne perd pas le power de mauvaise speculation lorsqu'on a des miss. Bref il y a bcp de choses que l'on peut faire pour economiser du power au prix de latence dans un cache.
-un truc qui ne m'est pas venu a l'esprit qui pourrait etre une preparation pour les futures generations.

Au final si ils l'avaient fait pour la frequence ca aurait change d'1 cycle ou 2 pas d'autant.

[Franck@x86]

Qques infos trouvées sur xtremesys (rien de bien nouveau par rapport à ce qu'on a déjà dit)
( source : http://www.xtremesystems.org/forums/...=133275&page=1 )

Edit : bon voilà le pdf directos :
http://public.cranfield.ac.uk/SOE_te...don_071206.pdf

(ça commence page 46)

[Foudge]

Ha tient, c'est le K10 maintenant :whistle:

[EPIC]

Ha tient, c'est le K10 maintenant :whistle:

bah... tant qu'on arrive pas au K19 y'a pas grand chose à criandre !

[Franck@x86]

Le K9 c'est l'Athlon X2.
Enfin bon, c pas très logique tout ça.

[fefe]

KK :grin:

[Franck@x86]

La partie interressante est le "sharing aware" LRU, je me demande ce qui peut se cacher derriere ca ? A priori ils empechent peut etre 1 core de monopoliser toutes les way du LLC

Peut-être un tag identifiant à quel core appartient la ligne de cache ?

Dans la doc pdf, AMD se targue de posséder des tagged TLB mais le tag concerne l'appartenance d'une ligne à une machine virtuelle, et non à un core précis, donc peut-être le terme "sharing aware" réfère aux machines virtuelles et non à l'id du core ?

[fefe]

Ca peut etre tagge par un ID de machine virtuelle ou un ID de thread, a mon avis pour la perf il y a plus de chances que ce soit avec un thread ID.

Un L3 non thread aware peut voire un core flusher completement le cache avec un memcopy (a supposer que le LRU des autres threads etait assez ancien du a un hit rate dans les 2 premiers niveaux de cache raisonable)creant une serieuse penalite pour les autres cores qui doivent recharger toutes les donnees flushees.
Les solutions faciles consistent soit a reserver certaines ways pour certains threads, et eventuellement partager un pool de way entre tout le monde. Ou alors dans le cas ideal juste donner des priorites a certains threads dans certaines voies, mais ca complexifie serieusement l'algo de remplacement a cote d'un bit qui dit juste si tel thread peut y ecrire ou non.

Apres si tu as un mecanisme pour reserver des ways en fonction de qui accede, rien ne t'empeche de jouer avec l'allocation des ID de ceux qui accedent: a differents threads en cas d'envirronnement fortement multithreade, a des machines virtuelles en environement virtualise. Pour se faire il te fautun mecanisme qui alloue ces ID pour chaque ligne de cache evict du L2. C'est bien entendu plus facile de le faire par core parce que pour le faire par machine virtuelle il faut que le L2 sache a quelle machine virtuelle chaque ligne de cache appartient (ou alors refaire un lookup des TLB qui le savent ce qui fait un peu trop a mon avis).

[Dandu]

j'ai lu 5 ou fois avant d'un peu comprendre uch:

Comment tu sais tout ça ?

[Franck@x86]

Et sur le c2d le L2 a des tags de threads ?

[fefe]

Sinon j'ai pense a une autre possibilite bcp plus simple en fait, mais beaucoup moins interressant. Quand tu remplaces une donnee dans le L3 tu choisis ta way de maniere a ne pas evict une donnee marquee shared.

C'est aussi une sharing aware replacement policy, ca ameliore la perf des apply qui partagent des donnees en ameliorant le temps de communication moyen entre les threads, et c'est plutot pas complique.

Et sur le c2d le L2 a des tags de threads ?

A ma connaissance aucune archi existante (en silicone) avec un cache partage ne tag ses ways avec un thread/core ID mais je peux me tromper.

Comment tu sais tout ça ?

Joker.

PS: desole je n'ai pas trop pris le temps de rendre ca tres "lisible"

[Lissyx]

PS: desole je n'ai pas trop pris le temps de rendre ca tres "lisible"

Clairement, si je savais pas que t'es crédible, j'aurais tamponné "bullshit marketing"

[Franck@x86]

merci pour toutes ces explications en tout cas

Je reviens un coup sur le pdf, il est vraiment intéressant et il explique plein de choses (il faut bien entendu faire abstraction du discours très orienté "les meilleurs choix sont forcément chez AMD").

(soit ils nomment Intel explicitement, soit ils parlent de "some x86 vendors" ... )

[fefe]

merci pour toutes ces explications en tout cas

Je reviens un coup sur le pdf, il est vraiment intéressant et il explique plein de choses (il faut bien entendu faire abstraction du discours très orienté "les meilleurs choix sont forcément chez AMD").

(soit ils nomment Intel explicitement, soit ils parlent de "some x86 vendors" ... )

De toutes facons:
1. ils ne vont pas dire qu'ils font de la merde par rapport aux autres
2. C'est leur tour de sortir quelque chose de nouveau, donc a priori si ils ne ratent rien leur produit devrait etre le plus attractif jusqu'au prochain nouveau produit du concurrent. Prescott nous avait fait perdre l'habitude, mais il n'y a pas de raison qu on retombe dans une sorte d'alternance Intel/AMD.

Clairement, si je savais pas que t'es crédible, j'aurais tamponné "bullshit marketing"

Je n'ai pas bcp de temps en ce moment donc comme je ne me relis pas tout est en jargon technique (sans la legende). Mais pour l'instant les details du L3 partage sont ce qui me semble le plus interressant sur le K10 (je suis un peu blase de base je sais).

[Lissyx]

je dis pas que c'est inintéressant, mais assez inaccessible, c'est pas un reproche, mais un constat.

[Yasko]

Ouais, moi aussi je suis d'accord, ce forum est de plus en plus incomprehensible, c'est une honte.
M'en vais faire un tour sur Clubic tiens.

Edit :
Bon je le mets quand même, au cas ou : :whistle:

[fetide]

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.

[Stéphane.P]

Il y un article chez Anandtech qui traite de l'architecture du Barcelona :

http://www.anandtech.com/cpuchipsets...oc.aspx?i=2939

[Foudge]

Interview de Phil Eisler et Giuseppe Amato :
Fr : http://www.syndrome-oc.net/articles.php?article=94
En : http://www.syndrome-oc.net/articles....cle=94&lang=en

edit: mwai, un peu déçu par l'interview, ça commençait bien pourtant

[Franck@x86]

La difficulte d'un L3 exclusif partage est que quand un core veut l'ownership d'une ligne il ne suffit pas de le demander au L3 (qui dans le cas d'inclusivite sait si un autre core a la donnee et qui est owner) il faut effectivement aller la demander aux autres niveaux de caches prives, et si le L1 et le L2 sont exclusifs il faut aller le demander aux 2. Il y a des astuces pour eviter ca comme d'avoir une copie des tags des caches prives de niveaux inferieur a cote du L3 mais ca prend de la place.

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 ?

[Franck@x86]

Sinon j'ai pense a une autre possibilite bcp plus simple en fait, mais beaucoup moins interressant. Quand tu remplaces une donnee dans le L3 tu choisis ta way de maniere a ne pas evict une donnee marquee shared.
C'est aussi une sharing aware replacement policy, ca ameliore la perf des apply qui partagent des donnees en ameliorant le temps de communication moyen entre les threads, et c'est plutot pas complique.

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 ?