K10 et innovations

[Franck@x86]

Voilà chaque proc aura son topic "innovations" :D

Y'a pas mal de fakes de K8L qui ont circulé ces derniers jours, on a entendu tout et n'importe quoi. Je propose donc de regrouper ici ce qui semble le plus fiable sur ce proc (et j'éviterai soigneusement les évaluations de perfs du genre +40% de fruits en plus et autres salades).

J'ai trouvé ça sur xtremesys. Ca sent quand même vachement une "conroeisation" de K8.

AMD K8L Agena & Kuma Details

Core Enchancements:
128 Bit floating point (Applies only to Agena & Kuma)

New SSE4A instructions:
Advanced Bit manipulation
MWAIT & MONITOR instructions
Misaligned SSE Mode

Additional Features:
Power management state invariant time stamp counter (TSC)
increased number of TLB Page entries
1GB large paging support
Physical address space increased to 48 bits

IMC Enhancements
DDR2 Dimms in products variations:
Socket AM2+: Dual Channel unbuffered 1066 support
Socket 1207+ Dual Channel unbuffered 1066 support

Memory Controller enhancements
Write Burst & DRAM prefetching performance improovements
DRAM writes can be buffered in the memory controller before being opportunistically bursted into DRAM controler to improve DRAM interface efficiency
Read prefetcher detects stride paterns and issues prefetch requests based on confidence level
Channel Interleaving

Roadmap:
Agena FX:
Q3 2007:
2.7-2.9GHz
2MB L2 total L2 cache for the CPU (quad core so 512KB each core)
2MB shared L3
Socket 1207+
4000MHz hypertransport Bus
TDP not determined yet
65nm SOI

Agena:
Q3 2007:
2.4-2.6GHz
2MB L2 total L2 cache for the CPU (quad core so 512KB each core)
2MB shared L3
Socket AM2+
4000MHz hypertransport Bus
TDP 125W
65nm SOI

Kuma:
Q3 2007:
2.0-2.9GHz
1MB L2 total L2 cache for the CPU (dual core so 512KB each core)
2MB shared L3
Socket AM2+
4000MHz hypertransport Bus
TDP 89w - 65w
65nm SOI

Ah oui, un truc rigolo : le "L" de K8L ferait référence au chiffre romain 50. Le nom signifierait donc "K8.50", entre K8 et K9 donc.

[Lissyx]

Autant une Conroeisation du K8L que le Conroe a été une K8isation des cores Intel, non ?

Un partout, en gros.

[Franck@x86]

Pas tout à fait quand même, le Conroe s'est aligné sur le K8 en terme de perfs mais avec des améliorations propres à Intel qu'on ne retrouve pas forcément sur le K8.
Là c'est vraiment :

K8L = K8 + (Conroe - Pentium M)

oui j'aime bien les formules.

[fefe]

Parler de conroeisation suppose qu'ils copient, en pratique le 128 bit SSE, le 4 wide fetch &decode& retire les acces memoire OOO, sont juste des techniques connues et efficaces pour augmenter l'IPC. Le fait que l'1 le fasse apres l'autre ne veut pas dire qu'il y a copie.

Par contre la K8isation des core Intel je ne vois vraiment pas ... Si le fait de selectionner ton core mobile pour aller partout parce que les autres cores sont mauvais c'est de la copie je veux bien me faire pendre . Je veux bien la liste de features qui a ete empruntee a K8 dans conroe .

[Franck@x86]

Les deux archis restent quand même assez différentes pour ne pas se comporter de la même façon dans toutes les applis.
Vivement les benchs tiens

[Lissyx]

Bah le Conroe a quand même été conçu pour être au même niveau que les K8 là où il ne l'était pas, c'est en ce sens qu'il faut comprendre "K8isation".

[fefe]

pour être au même niveau que les K8 là où il ne l'était pas

desole c est pas clair. J'ai besoin d un peu d eclairage pour comprendre.

[krumtrash]

Bah le Conroe a quand même été conçu pour être au même niveau que les K8 là où il ne l'était pas, c'est en ce sens qu'il faut comprendre "K8isation".

Ou tout simplement, une meilleur IPC.
On pourrait aussi dire une P3isation dans cas

[Lissyx]

Ou tout simplement, une meilleur IPC.
On pourrait aussi dire une P3isation dans cas

Nan, mais j'avais été interloqué par l'augmentation de perfs, qui amenait le Conroe au même niveau voire plus rapide que le K8.

Pas la peine de me tourner en ridicule ...

[fefe]

Nan, mais j'avais été interloqué par l'augmentation de perfs, qui amenait le Conroe au même niveau voire plus rapide que le K8.

Pourtant Sam avait montre ici meme que Dothan etait deja au niveau de perf du k8 a frequence egale quelques annees plus tot. Supposant que Yonah et Conroe apportaient des ameliorations incrementales a Dothan, cela n'aurait pas du etre si surprenant que ca.

PS: je n'avais aucune intention de te tourner au ridicule j'esperais juste que tu formulerais des arguments techniques histoire de me motiver pour faire un long post .

[Fanche]

Y a un truc que je trouve "rigolo" avec ce k8l, c'est que le bus HT tourne plus vite que le proc (4GHz pour au max 3GHz pour le proc). Bon je pense qu'il doit être en ddr, et il faut voir aussi qu'il doit "alimenter" jusqu'à 4 coeurs (dans ce cas ça fait du 1GHz par coeur), mais il ne risque pas de "gaver" les coeurs comme des oies?
D'un autre côté le bus HT doit être développer pour permettre de "voir l'avenir" avec des coeurs qui demandent plus de bande passante.
Une autre question: est-ce qu'il y a un lien direct entre le bus HT et le contrôleur mémoire? parce que dans ce cas le bus HT est peut-être surdimensionné pour les CM avec chip graphic intégrés et autres CG hypermemory...

[Lissyx]

Pourtant Sam avait montre ici meme que Dothan etait deja au niveau de perf du k8 a frequence egale quelques annees plus tot. Supposant que Yonah et Conroe apportaient des ameliorations incrementales a Dothan, cela n'aurait pas du etre si surprenant que ca.

PS: je n'avais aucune intention de te tourner au ridicule j'esperais juste que tu formulerais des arguments techniques histoire de me motiver pour faire un long post .

j'arrive plus à me souvenir exactement, mais ça m'avait frappé :/

[fefe]

Y a un truc que je trouve "rigolo" avec ce k8l, c'est que le bus HT tourne plus vite que le proc (4GHz pour au max 3GHz pour le proc). Bon je pense qu'il doit être en ddr, et il faut voir aussi qu'il doit "alimenter" jusqu'à 4 coeurs (dans ce cas ça fait du 1GHz par coeur), mais il ne risque pas de "gaver" les coeurs comme des oies?
D'un autre côté le bus HT doit être développer pour permettre de "voir l'avenir" avec des coeurs qui demandent plus de bande passante.
Une autre question: est-ce qu'il y a un lien direct entre le bus HT et le contrôleur mémoire? parce que dans ce cas le bus HT est peut-être surdimensionné pour les CM avec chip graphic intégrés et autres CG hypermemory...

Le bus HT n'est pas large ce qui pousse a monter sa frequence. Le fait qu'elle soit plus haute que celle du core ne veut pas dire que ce soit surdimensionne. Quand tu as 2 processeurs et que tu n'utilises pas un OS optimise NUMA il te faut en theorie autant de bande passante (agregee) sur ton lien HT que sur tes controleurs memoire car la moitie des acces memoire (de chaque cote) passe par ton lien HT. Ensuite il te faut encore un peu plus de bande passante pour les snoop.
Au final le dernier niveau de cache du K8L est probablement capable de demander 1 ligne de cache (64B ?) tous les 2 coups d'horloge a 3GHz, donc un lien 16? (la flemme de verifier) bits a 4GHz n'a vraiment rien de surdimensionne...

[Fanche]

désolé, dans ma candeur je croyais que le lien était en 64 bits, j'avais pas pensé à ça.
Si je te suis bien, le controleur mémoire est relié au bus HT? (si pour les accés mémoires les coeurs l'utilisent) Dans ce cas est-ce que par exemple un proc graphique peut accéder directement au controleur mémoire? Parce que depuis l'intégration du controleur mémoire dans le proc, je me pose la question de la cohérence des chips graphiques intégrés (savoit s'ils entrainent une "suractivité" du proc comparé à une carte graphique identique).

[fefe]

le cas dont je parlais est le suivant :

socket0--iMC0===Mem(x2 channels)
   |
   | <-(HT link)
   |
socket1--iMC1===Mem(x2 channels)

Dans cette configuration la moitie des acces memoire de chaque socket transite par un lien HT si l'OS n'est pas NUMA. Si l'OS est NUMA au lieu de faire un modulo sur les adresses pour les repartire equitablement entre les 4 channels de memoire, il va essayer d'allouer des pages entieres sur un controleur memoire ou l'autre pour eviter le trafic par le lien HT.

Quand a la connection d'un chip graphique sur un lien HT, je vois a priori 2 methodes:

socket0--iMC0===Mem(x2 channels)
   |
   | <-(HT link)
   |
  GPU--GMC=== GDDR

Dans ce cas seulement les acces qui passaient avant sur le PCIe passent par le lien HT

ou alors la version a memoire partagee:

socket0--iMC0===Mem(x2 channels)
   |
   | <-(HT link)
   |
  GPU

Dans ce cas tous les acces memoire de ton GPU passent par ton lien HT

Dans les 2 cas pour l'instant le fait que HT permette de maintenir la coherence entre 2 agents est relativement peu important pour le graphique etant donne que les espaces memoire sont separes et geres manuellement par le driver. Je suppose que l'integration d'un GPU dans l'1 des 2 options cis-dessus encouragera a remettre ca en cause et a utiliser HT pour la coherence aussi.

[arthur]

...finalement ca ne serait pas le K8L, mais le K10:
http://www.theinquirer.net/default.aspx?article=37444

[glord]

Depuis le temps que The Inquirer fait danser la valse des noms de code des archi AMD, on est plus à un twist près maintenant...

Si ils veulent, je peux leur donner une autre interprétation : le L du K8L ca fait 50 en chiffres romains. Donc, K8.50 ! Mais c'est bien sûr !

Ca sent un peu la news n'importe nawak quand même...

[Oxygen3]

le K8.50 ca fait presque 1 an qu'on en a eu vent, et bien souvent, les plus anciennes rumeurs qui persistent sont les plus proches de la réalité :D

[fefe]

s/k8l/whatever/g
On s'en fout un peu du nom qui est choisi en interne la seule chose interressante est de pouvoir parler des technologies associees .

[glord]

Exactement, j'ai l'impression de voir un manège qui tourne en rond dans les news sur le sujet. A défaut de matière, il resucent sans cesse les mêmes histoires de nom...qui en a quelque chose à foutre franchement !

Sincèrement, je préfère m'exciter quand les filières russes commencent à laisser filtrer des infos que de la resucée de power points bidons. Je suis partisan de se taire quand on a rien de concrêt à proposer.

[Fanche]

Moi perso le k10 j'y crois pas, aux amériques du chnord c'est les réformés militaires équivalant à nos p4 français les k10. Alors pour un nom de proc "super intelligeant", ben ça le fait pas trop (quoi que les bonshommes bleus d'intel ça faisait pas mal p4 tout de même...)

[Yasko]

Si je te suis bien, le controleur mémoire est relié au bus HT? (si pour les accés mémoires les coeurs l'utilisent) Dans ce cas est-ce que par exemple un proc graphique peut accéder directement au controleur mémoire? Parce que depuis l'intégration du controleur mémoire dans le proc, je me pose la question de la cohérence des chips graphiques intégrés (savoit s'ils entrainent une "suractivité" du proc comparé à une carte graphique identique).

Le controleur mémoire est relié au controleur HT par ce qu'AMD appelle XBar (l'unité de dispatch HT - CPU - MCT)
http://www.amd.com/us-en/assets/cont...cture_WP_2.pdf
Pages 7 et 8

DRAM writes can be buffered in the memory controller before being opportunistically bursted into DRAM

Du cache dans le contrôleur mémoire ? C'est nouveau ? C'est pour les jeunes ?

[Dandu]

C'est la FB-DIMM, non, ça ? c'est efficace pour la sécurité (et ça permet de passer facilement d'une sorte de mémoire à une autre) mais normalement ça augmente un peu la latence (et surtout le prix).

[fefe]

Du cache dans le contrôleur mémoire ? C'est nouveau ? C'est pour les jeunes ?

Non a peu pres tous les controleurs memoires modernes (chipset ou integres) ont des buffers qui servent entre autre pour reordonnancer les acces afin de maximiser le nombre de dram page hit (ils essayent de scheduler un acces pour lequel la page memoire est deja ouverte par exemple).

Ces buffers ne contiennent generalement que quelques entrees mais c'est quand meme du buffering. Bien sur si les acces sont peu frequents ces buffers seront essentiellement vides.

Ces buffers n'ont rien a voir avec la fbdram, et existent au moins depuis certains controleurs sdram.

[Foudge]

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
32B instruction fetch
- Benefits integer code too
- Reduced split-fetch instruction cases
Core prefetchers
- DC Prefetcher fills directly to L1 Cache
- IC Prefetcher more flexible
* 2 outstanding requests to any address
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
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
TLB Optimisations
- Support for 1G pages
- 48bit physical address (256T
- Larger TLBs key for:
* Virtualized workloads
* Large-footprint databases and
* transaction processing
- DTLB:
* Fully-associative 48-way TLB (4K, 2M, 1G)
* Backed by L2 TLBs: 512 x 4K, 128 x 2M
- ITLB:
* 16 x 2M entries
Data-dependent divide latency
Additional fastpath instructions
– CALL and RET-Imm instructions
– Data movement between FP & INT
Bit Manipulation extensions
- LZCNT/POPCNT
SSE extensions
- EXTRQ/INSERTQ (SSE4A)
- MOVNTSD/MOVNTSS (SSE4A)
- MWAIT/MONITOR (SSE3)
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
Quad-core
- Native quad-core design
- Redesigned and improved crossbar(northbridge)
- Improved power management
- New level of cache added, L3 VICTIM
Redesigned northbridge for higher bandwidth
- Increase buffer sizes
- Optimize schedulers
- Ready to support future DRAM technologies
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
Dedicated L1 cache
- 256bit 64kB instruction, 64kB data
- 2 x 128bit loads/cycle
- reduced latency
Dedicated L2 cache
- 128bit 512kB
- 128bit bus to northbridge
- reduced latency
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
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
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

[Franck@x86]

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)

[Neo_13]

en même temps, madcho ne comprend même pas ce qu'il écrit lui même...

Je m'interroge sur l'utilité d'un L3, qui devrait en plus être en DRAM... Masquer un prefetch moisi ?

[Oxygen3]

Accélérer l'accès, le bw du L3 doit etre largement supérieure à la DRAM je pense.

Par contre, tu es sur Franck que la L2 du K8 est déjà en exclusif ? Il me sembvle que ca conservait le design du K7 avec le L1 & L2 en inclusif ...

[Franck@x86]

oui, tous les K8 ont un L2 exclusif.
Sur les premiers K7 à cache L2 discret le L2 était inclusif, mais dès que le L2 a été intégré au die il est devenu exclusif, pour le rester par la suite.

Ca se vérifie bien par un test de latence et/ou débit, les valeurs changent à taille(L2+L1D), alors que sur un Intel c'est dès taille(L2).

On avait écrit un truc là dessus :
http://www.x86-secret.com/articles/cpu/k8-3/amd64-5.htm

[Foudge]

Oxygen3> Sur les K7, les L1&L2 étaient exclusif. Sinon imagine ce que ça donnerait un Duron avec 64Ko de L2 si c'était du inclusif :D