Une hiérarchie mémoire revue et corrigée (suite)
Avec une architecture à quatre processeurs la hiérarchie mémoire devient particulièrement importante. Il faut que les différents cœurs d’exécution puissent communiquer efficacement les données, mais en même temps éviter qu’ils polluent le cache des autres s’ils travaillent sur des tâches distinctes. L’architecture à 3 niveaux est donc la réponse à ce problème : les quatre cœurs disposent d’un espace privé de 512 Ko et d’un espace de 2 Mo unifié à travers lequel ils peuvent partager leurs informations.
Le fonctionnement de cette nouvelle hiérarchie ne change pas de ce que l’on connaît déjà sur les processeurs AMD depuis le Thunderbird. Le cache L2 est toujours exclusif c’est-à-dire que les données du cache L1 ne sont pas dupliquées, de même les données du cache L3 sont aussi exclusives. On parle de victim cache : lorsqu’une donnée est sur le point d’être évincée du cache de niveau 1 lors d’un conflit, au lieu d’être écrite en mémoire centrale elle est placée dans le cache de niveau 2 et de la même façon lorsqu’une donnée doit être supprimée du cache de niveau 2 elle se retrouvé écrite dans le cache de niveau 3. Le cache de niveau 3 incorpore aussi des algorithmes destinés à le rendre plus efficace dans les applications multithreadées. Ainsi lorsqu’une donnée est réclamée au cache de niveau 3, si cette donnée a des chances d’être accédée par d’autres cœurs (s’il s’agit de code ou si cette donnée a déjà été partagée auparavant ce que le processeur peut déterminer grâce à un historique) elle est placée dans le cache de niveau 1 de donnée mais reste aussi à ce niveau. A l’inverse si elle n’est nécessaire qu’à un coeur elle est placée directement dans le cache de niveau 1 de ce cœur et retirée du cache de niveau 3. On parle de non inclusive victim cache : le cache de niveau 3 contient les "victimes" évincées du cache de niveau 2 mais pas seulement, à l’inverse du cache de niveau 2 qui ne contient que des données qui autrefois étaient dans le cache de niveau 1.
Au niveau des caractéristiques de ces différents niveaux de cache il y a peu de changement : le cache de niveau 1 est toujours associatif par ensemble de 2 blocs et présente une latence de 3 cycles mais en revanche son interface a été élargie à 256 bits contre 128 sur le K8, le cache de niveau 2 est associatif par ensemble de 16 blocs et présente une latence de 9 cycles en plus des 3 cycles du cache de niveau 1, enfin le cache de niveau 3 est associatif par ensemble de 32 blocs. AMD ne donne pas sa latence vu qu’elle est visiblement variable en fonction de la bande passante réclamée par les différents cœurs.
- Processeur,
- architecture ,
- K10 ,
- AMD ,
- Phenom
tres bel article
On voit les efforts de l'equipe d'AMD et cela semble encourageant pour les futures perf' des Barcelona
Encore un très bon article, merci.
La question que je me pose est au niveau des jeux d'instructions. Outre les optimisations purement hardware qui sont transparentes du point de vue software, à quel moment le nouveau jeu d'instructions est pris en compte?
Est-ce lors de la compilation avec un linker dépendant de chaque architecture?
Est-ce lors de l'installation du programme sur la machine cible?
Ou est-ce totalement transparent du point de vue du programme tiers et c'est alors l'os qui s'occupe d'optimiser le code pour prendre en compte les nouvelles instructions disponible?
Peut-être est-ce le processeur lors du décodage des instructions x86 qui détecte qu'une émulation possible peut-être faite avec les nouvelles instructions?
Je dois avouer que je ne comprends pas vraiment comment cela ce passe, dans le monde des microcontrôleurs c'est beaucoup plus simple
Ca me rappelle mes cours ou notre prof nous disait, vous voyez vous avez tout en main pour faire un processeur (tout ca parcqu'on arrivait à faire des additionneurs 8bits en vhdl^^)
Ouais peut-être le retour de AMD!!!!!!!!!!!!!
"si le voltage est commun à tous les cœurs"
Alors que la gestion des horloges est indépendantes... maikilsoncon... Il perde une occasion de bien faire descendre la consomation. J'imagine que seul la version portable pourra le faire...
TapiTapo :
ca dépend des programmes.
Globalement, en général on propose les optimisations à part sur certains calculs, avec le choix dans le programme (soit à la main, rare, soit en détectant si le CPU le fait). C'est surtout sur des programmes qui n'utilisent pas intensivement les instructions en question. On a donc au moins deux versions différentes du code : une SSE (par exemple) et une autre.
L'autre possibilité, c'est de limiter le programme à un jeu d'instruction minimum. C'est rare, parce que du coup ça limite le nombre de CPU utilisables : faut un parc installé important. On a de plus en plus de programme qui nécessitent le SSE(2) actuellement parce que la majorité des CPU actuels le sont.
Sinon, y a les programmes qui proposent plusieurs exécutables : un par type d'instruction, mais c'est chiant pour l'utilisateur.
l'OS n'est pas capable de définir les instructions à utiliser (et n'est en général pas optimisé pour des jeux en particulier) et le processeur n'est normalement pas capable de détecter les instructions.
Au vu de cette article le K10 sera sans doute du meme ordre de performances que le C2D ... a frequence egale ... et c'est bien sa le probleme la frequence des C2D s'envole pendant qu'AMD peine a faire monter celle de ses processeurs ... il faut donc esperer que les Les K10 soient nettement plus performants que les C2 a frequence egale sinon c'est mal barré pour AMD ...
Merci pour ces informations Dandu
J'epère bien qu'AMD va réussir à équivaloir les C2D, voir les dépasser à fréquence égale (réponse dans un prochain test) car un avenir sans AMD avec un seul fondeur serait une catastrophe pour l'avancé technologique, allez AMD sort toi les doigts du ... En tout cas les ingénieurs n'ont pas l'air d'avoir chômer, espérons que cela en ressortira du bon.
Pour les jeux d'instruction, c'est me semble-t-il le compilateur qui les utilise ou non, de manière efficace ou non. C'est pourquoi Intel développe son (ses ?) propre compilateur C, qui génère du code rapide sur processeur intel.
Pour ce qui est du délai et du saut d'appellation, n'y a-t-il pas eu une architecture K9, abandonnée il y a environ 18 mois pour une cause inconnue ? (manque de performance, problèmes de fabrications, de brevet ?)
l'OS n'est pas capable de définir les instructions à utiliser (et n'est en général pas optimisé pour des jeux en particulier) et le processeur n'est normalement pas capable de détecter les instructions.
i386, i586, i686 ce n'est pas adapter le l'OS à un jeu en particulier ? (bien sur il y a plus de jeux d'instructionsque ca).
Les instructions à utiliser sont également choisit par le compilateur lors de la compilation non ? (bien sur il faut dire au compilateur qu'elles instructions notre proc supporte).
on voit qu'il y a un travail sérieux qui a été fait![[:fraye:3]](http://img.infos-du-net.com/forum/images/perso/3/fraye.gif)
même si je ne comprends pas tout
bravo a l'équipe de PPC.
Fraye > Quels passages ne comprends tu pas ?
Ca me rappelle mes cours ou notre prof nous disait, vous voyez vous avez tout en main pour faire un processeur (tout ca parcqu'on arrivait à faire des additionneurs 8bits en vhdl^^)
Ha ben on a eu le même.
Les instructions à utiliser sont également choisit par le compilateur lors de la compilation non ? (bien sur il faut dire au compilateur qu'elles instructions notre proc supporte).
oui, pour Linux, tu peux limiter au CPU minimum, mais c'est pas nécessairement le cas.
les instructions sont choisies par le compilateur en fonction de ce qu'on lui demande, mais tu peux lui mettre plusieurs versions dans le programme (avec un choix, manuel ou automatique)
en général, on a quand même tendance a faire du code le "moins" optimisé possible pour garder une compatibilité correcte : on se limite par exemple au i686 avec MMX (ce qui doit représenter une bonne partie des machines actuelles)
Maintenant, si t'as du code qui va tourner sur une machine que tu connais bien, tu peux optimiser avec ce que le CPU supporte (ex. Gentoo qui peut être compilé en fonction de la machine).
Fraye > Quels passages ne comprends tu pas ?
l'article est trés bien fait et tout et tout..
bonnes explications.. ça se voit
ca vient plus de moi qui même quand il y a toutes les explications possibles
n'arrive plus a suivre techniquement.
Fedy Abi-Chahla -> Mais comment tu sais tout ça ?