COMPTOIR
register

×

milan vs milan-x : latence cache et mémoire

3D V-Cache et latence avec un EPYC, y'a bon ?
milan vs milan-x : latence cache et mémoire
milan vs milan-x : latence cache et mémoire

Lorsqu'AMD avait présenté son fameux 3D V-Cache — en principe, basé sur des technologies de packaging 3D de chez TSMC — en juin dernier, outre s'interroger de son impact sur les performances, les spéculations allaient aussi de bon train quant aux conséquences pour la latence du cache et de la mémoire. En effet, avec le processeur ainsi surplombé d'un gros cache additionnel fusé sur le dessus de chaque CCD, il est tout à fait cohérent de penser que cela puisse affecter les latences en question et c'est précisément ce qu'a voulu démontrer Chips and Cheese, en opposant le nouveau EPYC Milan-X 7V73X avec un « ancien » EPYC Milan 7763. Le premier possède 768 Mo de cache L3 grâce aux 512 Mo du 3D V-Cache venus compléter les 256 Mo d'origine, soit 8 chiplets de cache SRAM en 7 nm de 64 Mo chaque, et donc trois fois plus qu'un EPYC 7763.

 

milan vs milan-x : latence cache et mémoire [cliquer pour agrandir]

 

milan vs milan-x : latence cache et mémoire [cliquer pour agrandir]

 

Résultat des courses, la comparaison présentée est plutôt impressionnante et l'augmentation mesurée de la latence n'a ici été que de 3 à 4 cycles supplémentaires. Le testeur fait aussi remarquer — sans trop donner de détails — que Milan-X se comporte aussi bien mieux en boost, en dépit de ses fréquences plus basses par rapport à Milan, ce qui a eu pour effet de nullifier l'impact de l'augmentation de la latence.

 

De toute évidence, AMD a donc effectué un très bon travail - que nous vous avions déjà exploré et raconté en détail plusieurs fois, ici et . C'est indéniablement une bonne nouvelle et encourageant pour l'avenir du 3D V-Cache, une technologie à laquelle le mainstream pourra prochainement goûter avec le Ryzen 7 5800X3D - et son cache L3 triplé par rapport au 5800X, mais également en contrepartie de fréquences inférieures. Par conséquent, les résultats et le comportement observés avec cet EPYC 7V73X devraient logiquement se retrouver avec le futur 5800X3D - et accessoirement tout éventuel Ryzen subséquent intégrant un 3D V-Cache ! Il reste à voir si cela se traduira effectivement avec les gains annoncés par AMD lors du CES 2022, mais pour l'instant, cela semble bien parti.

Un poil avant ?

Gamotron • Un anneau pour les gouverner tous ou presque

Un peu plus tard ...

Les EPYC bientôt plus chers et Sapphire Rapids (encore) retardé ?

Les 10 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 25 Janvier 2022 à 15h31  
par _m_ le Mardi 25 Janvier 2022 à 11h38
Par contre ça montre aussi qu'ils sont incapables d'aller piocher dans le cache du voisin (même pour de la lecture seule, pour des lignes qu'un autre CCD aurait déjà quémandé?)
Oui exactement. Un coeur d'un CCD ne peux pas utiliser le cache d'un autre CCD.
Donc il ne voit que 96MB de cache L3 (avec le V-cache) en mono-coeur.

Par contre les CCD ne forment pas des CPU totalement isolés. Il y a de la cohérence de cache entre eux via l'Infinity Fabric.

C'est à dire que si un code multi-threadé est exécuté sur 2 CCD différents et que 2 threads localisés dans 2 CCD différents utilisent la même ligne de cache, les CCD vont se transmettre la ligne de cache via l'IF directement sans passer par la DDR. Mais cela reste cher en latence.
par _m_ le Mardi 25 Janvier 2022 à 12h19
Mais tout de même, on ne peut pas accéder à 100 663 296 octets en seulement ~48 cycles. C'est uniquement une petite poignée d'entre eux qui seront relus (8 / 64 bits?).
Le CPU demande le contenue d'une adresse en RAM, et si par chance elle se trouve dupliqué dans le cache, il sera servi plus rapidement
Donc c'est bien la latence pour accéder à un élément précis du cache, bien qu'il n'ait pas d'adresse proprement dit.
Oui exactement, la latence ce n'est pas le débit. Par contre la taille maximum des accès mémoires est plutôt de l'ordre de 256bits (32B) ou 512bits (64B pout match la taille des lignes de cache)
par _m_, le Mardi 25 Janvier 2022 à 12h19  
Mais tout de même, on ne peut pas accéder à 100 663 296 octets en seulement ~48 cycles. C'est uniquement une petite poignée d'entre eux qui seront relus (8 / 64 bits?).
Le CPU demande le contenue d'une adresse en RAM, et si par chance elle se trouve dupliqué dans le cache, il sera servi plus rapidement
Donc c'est bien la latence pour accéder à un élément précis du cache, bien qu'il n'ait pas d'adresse proprement dit.
par _m_, le Mardi 25 Janvier 2022 à 11h38  
Merci pour cet éclairage.
(j'suis idiot, il m'est déjà arrivé de bosser avec du cache, j'aurai dû le savoir. mais mes neurone n'ont pas fait la connexion ce coup ci... )

Par contre ça montre aussi qu'ils sont incapables d'aller piocher dans le cache du voisin (même pour de la lecture seule, pour des lignes qu'un autre CCD aurait déjà quémandé?)
A moins que ce se soit ça qui joue après les ~100Mo?

Me demande comment ça va se passer avec les petits Epyc. Toute la gamme est annoncé avec 768Mo de L3. Ça voudrait dire qu'on va se retrouver avec 8 CCD ne comportant que 2 cœurs actifs par chiplets, mais pouvant se partager 96Mo à eux tout seuls?
Mais quel gâchis de silicium.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 25 Janvier 2022 à 09h07  
par Krenian le Lundi 17 Janvier 2022 à 16h13
Et les 4 cycles de différences que l'article nous mentionne c'est le 51-47
Exactement. Cependant je serais méfiant sur cette mesure de 3~4 cycles, c'est une moyenne, et c'est très bruité.
 
Et donc les valeurs les plus à droites (taille la plus grande) c'est le temps d'accès à la RAM ?
Oui, exactement cela s'en rapproche.
Cependant on voit que la courbe n'est pas plate autour de 1GB même si on a déjà bien dépassé la taille des 2 caches L3. Donc les caches L3 semblent toujours avoir un effet positif (ont toujours en cache des données) pour les régions qui dépassent leur taille. Pourquoi ?
Cela vient de la "politique de remplacement" du cache L3. C'est à dire l'algorithme qui choisi quelle ligne de cache doit être évincé (retiré du cache) lorsqu'il n'y a plus de place dans le cache mais qu'une nouvelle donnée doit y être stocké (et donc qu'il faut faire de la place).

Pour les caches L3 on utilise généralement des "politiques de remplacement" pseudo-aléatoires, c'est à dire que la ligne de cache à évincer est sélectionnée aléatoirement. Et donc, par chance, quand on a déjà bien dépassé la taille du cache L3 dans ces benchs il reste toujours quelques données toujours en cache qui donnent un petit gain. Un gain qui s'estompe de plus en plus quand la Region Size augmente.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 25 Janvier 2022 à 08h53  
par _m_ le Lundi 17 Janvier 2022 à 16h03
Moi ce que j'ai compris, c'est qu'il ne s'agit pas d'une taille, mais de l'adresse du cache que l'on cherche à accéder. Ici le L1 se termine à 32ko, le L2 à 256ko et le L3, à 32Mo ou 96Mo, suivant le proc. Et après on pioche dans la RAM.
Ce n'est pas comme ça que marche un cache. Les ligne d'un cache n'ont pas une adresse qui permet de choisir quelle lignes on cible.
par Krenian le Lundi 17 Janvier 2022 à 15h46
quand on parle de la taille du cache (et dans les graphes de la "Region SIze" ), c'est la taille matérielle du cache ou la taille de la donnée qu'on cherche/charge ?
La taille du cache c'est le nombre de bytes qui peuvent être "caché" par un niveau de cache, c'est à dire que que le cache peut contenir 32ko, ou 256ko, etc.

Pour comprendre les graphs il faut savoir comment on mesure la latence des caches:
Pour mesurer la latence des caches on alloue une zone de mémoire qu'on accède une première fois pour la charger en cache, puis un ré-accède à cette zone et à ce moment là on mesure la latence.
La taille de cette zone mémoire alloué c'est la "Region Size". Et on reproduit la mesure pour différente RegionSize jusqu'à faire ces graphiques.

Ce qu'on voit c'est ce lorsque la RegionSize dépasse 32kB il y a un changement de la latence, on en déduit donc que la zone mémoire alloué ne tiens plus entièrement dans le L1, et donc que le L1 fait 32kB. De même avec le L2 autour de 256kB.
Pour la suite de la courbe on voit que c'est très bruité, il peut y avoir plein de raison à ça. Mais on voit que le 7V73X tiens le régime ~48cycle plus longtemps, car son cache L3 est plus grand on peut donc stocker une "Region" plus grande.
par Krenian, le Lundi 17 Janvier 2022 à 16h13  
par _m_ le Lundi 17 Janvier 2022 à 16h03
Moi ce que j'ai compris, c'est qu'il ne s'agit pas d'une taille, mais de l'adresse du cache que l'on cherche à accéder.
Ici le L1 se termine à 32ko, le L2 à 256ko et le L3, à 32Mo ou 96Mo, suivant le proc. Et après on pioche dans la RAM.
ça expliquerait les 3 niveaux différents de latence (ici 4, 12, 47 cycles) et les montées de latences à la fin de chaque niveau ça serait les tailles où on atteint la saturation mais pas assez pour monter au supérieur ?
Et les 4 cycles de différences que l'article nous mentionne c'est le 51-47.

Et donc les valeurs les plus à droites (taille la plus grande) c'est le temps d'accès à la RAM ?

Je demande confirmation au cas où mais c'est vrai que ça me semble logique
par _m_, le Lundi 17 Janvier 2022 à 16h03  
par Krenian le Lundi 17 Janvier 2022 à 15h46
Une simple question : quand on parle de la taille du cache (et dans les graphes de la "Region SIze" ), c'est la taille matérielle du cache ou la taille de la donnée qu'on cherche/charge ?
Moi ce que j'ai compris, c'est qu'il ne s'agit pas d'une taille, mais de l'adresse du cache que l'on cherche à accéder.
Ici le L1 se termine à 32ko, le L2 à 256ko et le L3, à 32Mo ou 96Mo, suivant le proc. Et après on pioche dans la RAM.
par Krenian, le Lundi 17 Janvier 2022 à 15h46  
Une simple question : quand on parle de la taille du cache (et dans les graphes de la "Region SIze" ), c'est la taille matérielle du cache ou la taille de la donnée qu'on cherche/charge ?
par Superubu, le Lundi 17 Janvier 2022 à 14h07  
Bien hâte de voir les résultats en pratique, si la disponibilité et le tarif sont correct ça annonce du bon
par _m_, le Lundi 17 Janvier 2022 à 11h27  
Ils ont donc dégrader le L3 de base, pour l'aligner sur celui du dessus, et garder ainsi un comportement homogène.
(je me serais attendu à une 4ème marche d'escalier)