Comment le cache peut-il être aussi rapide?

37

Voici une capture d'écran d'un repère de cache:

Résultats du test de performance AIDA64 Cache et mémoire

Dans le test de référence, la vitesse de lecture du cache N1 est d’environ 186 Go / s, la latence étant d’environ 3 à 4 cycles d’horloge. Comment une telle vitesse est-elle atteinte?

Considérons la mémoire ici: la vitesse maximale théorique est de 665 MHz (fréquence de la mémoire) x 2 (double débit de données) x 64 bits (largeur du bus), soit environ 10,6 Go / s, ce qui est plus proche de la valeur de référence de 9,6 Go / s. .

Mais avec le cache L1, même si nous pouvions lire à chaque cycle avec le processeur à sa fréquence maximale (3 GHz), il nous faudrait environ 496 lignes de données pour atteindre un tel débit, ce qui semble irréaliste. Ceci s'applique également aux autres caches.

Qu'est-ce que je rate? Comment calcule-t-on le débit d'un cache à partir de ses paramètres?

Chevalier
la source
14
avez-vous pensé à la taille réduite de la mémoire cache L1,2,3 et à son emplacement physique? Astuce, vous n'avez pas besoin de vous préoccuper d'un standard de bus si vous possédez l'intégralité de la puce
JonRB
2
En outre: le référentiel en sait-il assez sur ce qu'il fait pour s'assurer que certaines données testées ne sont pas conservées directement dans un registre?
rackandboneman
7
@rackandboneman: AIDA64 est une référence bien respectée, ce n'est pas quelqu'un que quelqu'un vient de pirater en C et de laisser le compilateur optimiser certaines charges! Je suppose que les pièces de microbenchmark sont écrites en assemblage, avec les versions SSE ou AVX.
Peter Cordes
1
@ Peter Cordes réponse satisfaisante - à une question nécessaire.
rackandboneman
1
Juste pour mettre les pensées en perspective physique: en 1,4 nanosecondes, la lumière parcourt environ un pied et demi. Cela signifie que si le cache était situé de l'autre côté de la carte mère, une latence comme celle-ci pourrait briser la relativité. Ou être une erreur de mesure .
Arthur

Réponses:

35

Ce processeur a ...

2 cœurs Une instruction de 32 Ko et un cache de premier niveau (L1) de données de 32 Ko pour chaque cœur

Comme il y a deux cœurs, nous pouvons nous attendre à ce que le benchmark exécute deux threads en parallèle. Leur site Web fournit cependant très peu d'informations, mais si nous regardons ici , les CPU avec plus de cœurs semblent donner des débits L1 plus élevés. Je pense donc que ce qui est affiché est le débit total avec tous les cœurs travaillant en parallèle. Donc, pour votre CPU, nous devrions diviser par deux pour un noyau et un cache:

Read   93 GB/s
Write  47 GB/s
Copy   90 GB/s

Maintenant, le fait de "copier" est deux fois plus rapide que "d'écrire" est très suspect. Comment pourrait-il copier plus vite qu'il ne peut écrire? Je parie que ce que l’indice de référence affiche comme "copie" correspond à la somme du débit lecture / écriture. Dans ce cas, il lit et écrit à 45 Go / s, mais affiche 90, car c’est un essai, et qui diable fait confiance aux repères? Donc, ignorons "copie".

Read   93 GB/s => 30 bytes/clock
Write  47 GB/s => 15 bytes/clock

Maintenant, un registre de 128 bits a une taille de 16 octets, ce qui donne l'impression que ce cache peut effectuer deux lectures de 128 bits et une écriture par horloge.

C’est exactement ce que vous voudriez rationaliser vraiment ces instructions de calcul de SSE: deux lectures et une écriture par cycle.

Cela serait très probablement implémenté avec beaucoup de lignes de données parallèles, ce qui est le moyen habituel de transporter beaucoup de données très rapidement dans une puce.

peufeu
la source
4
La page 55 du document @ next-hack contient les liens suivants: "En interne, les accès peuvent aller jusqu'à 16 octets. [...] Deux opérations de chargement et une opération de stockage peuvent être traitées à chaque cycle". Cela explique pourquoi la lecture est deux fois plus rapide - il peut effectuer deux lectures dans la même opération tout en effectuant une écriture.
Tom Carpenter
2
Oui, il est clair que copie compte BW = lire et écrire. Cela semble tout aussi valable que l'alternative, car il est significatif que les lectures et les écritures puissent s'exécuter en parallèle. Notez que les numéros de l'OP pour L2 / L3 ont une copie pas beaucoup plus haute que l'écriture, et plus basse pour la mémoire. Le bus de mémoire DDR3 n'est pas en duplex intégral: les mêmes lignes de données sont nécessaires pour la lecture et l'écriture. (Pour plus d'informations sur la bande passante mem86 / memset x86 avec les magasins NT par rapport aux magasins normaux, voir stackoverflow.com/questions/43343231/… ).
Peter Cordes
6
Vous devinez qu'IvyBridge peut faire 2 lectures et 1 écriture dans le même cycle d'horloge. Vous avez raison, mais seulement dans des circonstances très limitées. IvB ne dispose que de 2 ports AGU, il est donc normalement limité à 2 opérations de mémoire par horloge, dont un peut être un magasin . Mais les chargements / magasins AVX 256b prennent 2 cycles à exécuter dans les ports de chargement / stockage, alors que l’AGU n’a besoin que du premier cycle. Ainsi, un uop d’adresse de magasin peut s’exécuter sur le port 2/3 au cours de ce deuxième cycle d’une charge de 256 bits sans que la bande passante de la charge ne soit coûtée. (Les données stockées sur les magasins fonctionnent sur le port 4.) Source: agner.org/optimize microarch pdf
Peter Cordes
2
Une CPU AMD Bulldozer ou Ryzen vous donnerait le même nombre de lectures = écriture, mais elles sont en réalité limitées à 2 opérations de mémoire par horloge (jusqu'à une peut être une écriture) sans aucune échappatoire. lecture / écriture / copie ne détecte pas la différence, mais Triad peut ( a[i] = b[i] + c[i]). BTW, Intel Haswell et les versions ultérieures disposent d’un magasin-AGU sur le port 7, capable de gérer des modes d’adressage simples (non indexés), leur permettant ainsi d’exécuter 2 charges + 1 magasin uops par horloge. (Et le chemin de données vers L1D est 256b, il double donc la bande passante de L1D.) Voir l'article de David Kanter: realworldtech.com/haswell-cpu/5
Peter Cordes
1
@AliChen: Le terminal opérateur a explicitement mentionné la latence d'utilisation de la charge en 4 cycles d'IvyBridge juste après la bande passante, avant de demander comment elle pouvait être aussi rapide.
Peter Cordes
27

La réponse de @ peufeu indique qu'il s'agit de largeurs de bande globales à l'échelle du système. Les caches L1 et L2 sont des caches privés par cœur dans la famille Intel Sandybridge, de sorte que les chiffres correspondent à deux fois plus qu'un simple cœur peut faire. Mais cela nous laisse toujours avec une largeur de bande impressionnante et une faible latence.

Le cache L1D est construit directement dans le cœur de la CPU et est très étroitement couplé aux unités d’exécution de la charge (et à la mémoire tampon de stockage) . De même, le cache L1I est juste à côté de la partie extraction / décodage d'instruction du noyau. (En fait, je n’ai pas examiné un plan d’étage en silicium Sandybridge, ce qui n’est peut-être pas tout à fait vrai. La partie émettrice / renommée de l’interface est probablement plus proche du cache uop décodé "L0", ce qui permet d’économiser de l’énergie et d’améliorer la bande passante. que les décodeurs.)

Mais avec le cache L1, même si nous pouvions lire à chaque cycle ...

Pourquoi s'arrêter là? Intel depuis Sandybridge et AMD depuis K8 peuvent exécuter 2 charges par cycle. Les caches multi-ports et les TLB sont une chose.

La microarchitecture Sandybridge de David Kanter contient un joli diagramme (qui s'applique également à votre processeur IvyBridge):

(Le "planificateur unifié" tient en mémoire l'ALU et la mémoire Uops attendant que leurs entrées soient prêtes et / ou leur port d'exécution. (Par exemple, vmovdqa ymm0, [rdi]décodage en charge d'un uop qui doit attendre rdisi une précédente add rdi,32n'a pas encore été exécutée, par par exemple). calendriers Intel UOP aux ports en cause / heure de changement de nom . Ce schéma est seulement montrant les ports d'exécution pour UOP de mémoire, mais non exécuté ALU UOP en compétition pour elle aussi. l'étape numéro / renommage ajoute UOP à l'ORB et programmateur Ils restent dans le ROB jusqu’à sa retraite, mais dans le planificateur uniquement jusqu’à ce qu’ils soient envoyés à un port d’exécution (il s’agit de la terminologie d’Intel; d’autres personnes utilisent différemment l’émission et la distribution)). AMD utilise des ordonnanceurs séparés pour les nombres entiers / FP, mais les modes d'adressage utilisent toujours des registres d'entiers

Diagramme de mémoire SnB de David Kanter

Comme cela est montré, il n’ya que 2 ports AGU (unités de génération d’adresses, qui prennent un mode d’adressage semblable à celui qui est [rdi + rdx*4 + 1024]utilisé et produisent une adresse linéaire). Il peut exécuter 2 opérations de mémoire par horloge (de 128b / 16 octets chacune), l’un d’eux pouvant être un magasin.

Mais il a un tour dans son sac: SnB / IvB exécuter 256b AVX charge / stocke sous la forme d’un uop unique qui prend 2 cycles dans un port de chargement / stockage, mais n’a besoin que de l’AGU au premier cycle. Cela permet à une adresse de magasin uop de s'exécuter sur l'AGU sur le port 2/3 au cours de ce deuxième cycle sans perdre aucun débit de charge. Ainsi, avec AVX (que les processeurs Intel Pentium / Celeron ne prennent pas en charge: /), SnB / IvB peut (en théorie) supporter 2 charges et 1 magasin par cycle.

Votre processeur IvyBridge est l’inférieur de Sandybridge (avec quelques améliorations microarchitecturales, telles que mov-élimination , ERMSB (memcpy / memset) et le préchargement du matériel de la page suivante). La génération suivante (Haswell) a doublé la bande passante L1D par horloge en élargissant les chemins de données des unités d'exécution à L1 de 128b à 256b afin que les charges AVX 256b puissent en supporter 2 par horloge. Il a également ajouté un port store-AGU supplémentaire pour les modes d'adressage simples.

Le débit maximal de Haswell / Skylake est de 96 octets chargés + stocké par horloge, mais le manuel d'optimisation d'Intel suggère que le débit moyen soutenu de Skylake (en supposant toujours qu'aucun manque de L1D ou de TLB) est d'environ 81 milliards de dollars. (Une boucle entière scalaire peut supporter 2 charges + 1 magasin par horloge selon mes tests sur SKL, exécutant 7 uops (domaine non fusionné) par horloge à partir de 4 uops de domaine fusionné. Mais elle ralentit quelque peu avec des opérandes 64 bits au lieu de 32 bits, donc, apparemment, il existe une limite de ressources microarchitecturales et il ne s’agit pas uniquement de planifier les uops des adresses de magasin sur le port 2/3 et les cycles de vol des charges.)

Comment calcule-t-on le débit d'un cache à partir de ses paramètres?

Vous ne pouvez pas, sauf si les paramètres incluent des nombres de débit pratiques. Comme indiqué ci-dessus, même la L1D de Skylake ne parvient pas à suivre le rythme de ses unités d'exécution charge / stockage pour les vecteurs 256b. Bien que ce soit proche, et il peut pour les entiers 32 bits. (Cela n'aurait aucun sens d'avoir plus d'unités de charge que le cache n'avait de ports de lecture, ou inversement. Vous laisseriez de côté un matériel qui ne pourrait jamais être pleinement utilisé. Notez que L1D peut avoir des ports supplémentaires pour envoyer / recevoir des lignes / depuis d’autres noyaux, ainsi que pour les lectures / écritures à partir du noyau.)

Le simple fait de regarder les largeurs et les horloges de bus de données ne vous donne pas toute l’histoire. La bande passante L2 et L3 (et la mémoire) peut être limitée par le nombre de défaillances en suspens que L1 ou L2 peuvent suivre . La bande passante ne peut pas dépasser la latence * max_concurrency, et les puces avec une latence supérieure L3 (comme un Xeon à plusieurs cœurs) ont beaucoup moins de bande passante L3 à un cœur que les processeurs à deux / quatre cœurs de la même microarchitecture. Voir la section "plates-formes liées à la latence" de cette réponse SO . Les processeurs de la famille Sandybridge disposent de 10 mémoires tampons de remplissage de ligne pour suivre les erreurs L1D (également utilisées par les magasins NT).

(La bande passante L3 / mémoire agrégée avec de nombreux cœurs actifs est énorme sur un gros Xeon, mais le code à thread unique voit une bande passante inférieure à celle d'un quad core à la même vitesse d'horloge car plus de cœurs signifie plus d'arrêts sur le bus en anneau, et donc plus élevé. latence L3.)


Latence du cache

Comment une telle vitesse est-elle atteinte?

La latence d'utilisation de la charge de 4 cycles du cache L1D est assez étonnante , d'autant plus qu'elle doit commencer par un mode d'adressage tel que [rsi + 32], de sorte qu'elle doit faire une addition avant même d'avoir une adresse virtuelle . Ensuite, il doit traduire cela en physique pour vérifier les balises de cache pour une correspondance.

(Les modes d'adressage autres qu'un [base + 0-2047]cycle supplémentaire sur la famille Intel Sandybridge, de sorte qu'il existe un raccourci dans les AGU pour les modes d'adressage simples (typique pour les cas de recherche de pointeur où une faible latence d'utilisation est probablement la plus importante, mais également commune en général) (Voir le manuel d’optimisation d’Intel , Sandybridge, section 2.3.5.2 L1 DCache.) Cela suppose également qu’aucun remplacement de segment et une adresse de base de segment de 0, ce qui est normal.).

Il doit également sonder le tampon de stockage pour voir s'il se superpose aux précédents. Et cela doit être compris même si une adresse de magasin uop antérieure (dans l'ordre du programme) n'a pas encore été exécutée, donc l'adresse de magasin n'est pas connue. Mais on peut supposer que cela peut se produire parallèlement à la recherche d’un succès de L1D. S'il s'avère que les données L1D n'étaient pas nécessaires, car le transfert de magasin peut fournir les données du tampon de magasin, ce n'est pas une perte.

Intel utilise les caches VIPT (index virtuellement indexés physiquement) comme presque tout le monde, utilisant l’astuce habituelle voulant que le cache soit suffisamment petit et associe suffisamment pour qu’il se comporte comme un cache PIPT (sans aliasing) avec la vitesse de VIPT (peut indexer parallèle avec la recherche virtuelle -> physique TLB).

Les caches L1 d’Intel sont 32koB, associatifs à 8 voies. La taille de la page est 4kiB. Cela signifie que les bits "index" (qui sélectionnent les 8 façons de mettre en cache une ligne donnée) sont tous situés en dessous du décalage de page; c'est-à-dire que ces bits d'adresse sont le décalage dans une page et sont toujours les mêmes dans les adresses virtuelle et physique.

Pour plus de détails à ce sujet et pour savoir pourquoi les caches petits / rapides sont utiles / possibles (et fonctionnent bien lorsqu'ils sont associés à des caches plus lents et plus grands), voir ma réponse sur la raison pour laquelle L1D est plus petit / plus rapide que L2 .

Les petits caches peuvent faire des choses trop coûteuses en énergie, comme aller chercher les tableaux de données d'un ensemble en même temps que chercher des balises. Ainsi, une fois qu'un comparateur a trouvé la balise correspondante, il n'a plus qu'à multiplexer l'une des huit lignes de cache de 64 octets déjà extraites de la mémoire SRAM.

(Ce n’est pas si simple: Sandybridge / Ivybridge utilise un cache L1D avec banque, avec huit banques de morceaux de 16 octets. Vous pouvez obtenir des conflits de banque de cache si deux accès à la même banque dans différentes lignes de cache tentent de s’exécuter dans le même cycle. (Il y a 8 banques, cela peut donc arriver avec des adresses multiples de 128, c.-à-d. 2 lignes de cache.)

IvyBridge n’a également aucune pénalité pour un accès non aligné tant qu’il ne franchit pas une limite de ligne de cache de 64B. J'imagine qu'il détermine la ou les banques à récupérer en fonction des bits d'adresse faible et définit le décalage nécessaire pour obtenir le nombre correct de 1 à 16 octets de données.

Sur les fractionnements de lignes de cache, il ne reste qu'un seul uop, mais il y a plusieurs accès au cache. La pénalité est encore faible, sauf sur 4 k-splits. Skylake effectue même des fractionnements 4 k relativement peu coûteux, avec une latence d'environ 11 cycles, identique à un fractionnement de ligne de cache normal avec un mode d'adressage complexe. Mais le débit divisé en 4K est nettement pire que le non divisé en cl-split.


Sources :

Peter Cordes
la source
1
C'est très clair, exhaustif et bien écrit! +1!
next-hack
8

Sur les CPU modernes, la mémoire cache se trouve juste à côté de la CPU sur la même puce (puce) , elle est réalisée à l’aide de SRAM, qui est beaucoup plus rapide que la DRAM utilisée pour les modules de mémoire vive dans un PC.

Par unité de mémoire (un bit ou un octet), la SRAM est beaucoup plus chère que la DRAM. C'est pourquoi la mémoire DRAM est également utilisée dans un PC.

Mais puisque la mémoire SRAM utilise la même technologie que le processeur, elle est aussi rapide que le processeur. En outre, seuls les bus internes (sur la CPU) sont concernés, donc s’il s’agit d’un bus large de 496 lignes, c’est probablement le cas.

Bimpelrekkie
la source
Merci de votre intérêt. J'ai lu dans quelques livres indiquant que les vitesses d'accès aux registres étaient supérieures à 300 Go / s, auquel cas, pour un processeur de 3 GHz, le débit des registres est de 100 B / cycle, ce qui n'est pas possible car les registres ont généralement une largeur de 64/128 bits, ils ne pouvaient pas sortir autant. C'est ce qui me concerne. GB / sa est-il un bon moyen d’exprimer le débit?
Knight
3
@Knight N'oubliez pas qu'IvB (comme tout processeur haute performance) exécute plusieurs instructions par cycle, telles que 3 opérations ALU, 2 charges et 1 magasin. La plupart d’entre elles peuvent prendre 2 entrées (même des charges, pour l’adressage indexé) et la charge, même 3. C’est 13 registres de 8 octets chacun, 104 octets (une combinaison aussi épique n’aurait pas pu être autorisée n’indique pas que c’est le cas pour IvB, bien que cela ne puisse être maintenu). Si vous considérez également les registres de vecteurs, ce nombre augmente encore.
harold
@harold: related: Haswell et Skylake semblent avoir des limites sur les lectures de registre par horloge, bien que cela puisse être dans le front-end et n'affecte pas une exécution en rafale après que certaines entrées soient prêtes. C’est peut-être une autre limite microarchitecturale, mais j’ai trouvé des goulots d’étranglement dans le code qui devraient pouvoir supporter plus d’opérations par horloge. agner.org/optimize/blog/read.php?i=415#852 . Sur Haswell, mon meilleur scénario lisait ~ 6,5 registres entiers par cycle d'horloge (maintenu). J'ai également réussi à obtenir 7 uops par horloge dispatche / execute sur Skylake (les magasins sont store-address + store-data).
Peter Cordes
@PeterCordes qui doit être le front-end, n'est-ce pas? IIRC a également été le problème par le passé (PPro to Core2) et je ne suis pas sûr de savoir comment les nombres fractionnaires ont un sens autrement. Quoiqu'il en soit, mes chiffres étaient un peu décalés
harold
@harold: ouais, je suis presque sûr que c'est un goulot d'étranglement en amont, probablement renommé. Le goulot d'étranglement de P6 lié à la lecture du registre se trouvait sur des registres "froids" qui devaient être lus à partir du fichier de registre permanent dans l'OBD en question. Les registres récemment modifiés se trouvaient toujours à l’Ordre, ce qui n’a pas entraîné de goulet d’étranglement. Je n'ai pas beaucoup enquêté sur les réglages froid / chaud sur HSW / SKL, car, pour une raison quelconque, je ne pensais pas faire ma boucle plus grande que 4 ups / idéalement 1c par itération. Oops. IDK Quelle différence y a-t-il entre le transfert et la lecture de PRF (ce qui doit se produire au moment de l’exécution, pas à émettre / renommer)
Peter Cordes
4

Les caches L1 sont des structures de mémoire assez larges. L'architecture des caches L1 dans les processeurs Intel se trouve dans ce manuel (fourni par next-hack). Cependant, l'interprétation de certains paramètres est incorrecte, la "taille de la ligne de cache" n'est pas la "largeur de données", c'est la taille du bloc série d'accès aux données atomiques.

Le tableau 2-17 (section 2.3.5.1) indique que lors des chargements (lectures), la bande passante du cache est 2x16 = 32 octets par cœur et par cycle . Cela seul donne une bande passante théorique de 96 Gb / s sur un cœur 3GHz. Le rapport de référence cité n’est pas clair. Il semble que deux cœurs fonctionnent en parallèle, ce qui donne 192 Gbps pour deux cœurs.

Ale..chenski
la source
2

Les délais de porte sont quoi? 10 picosecondes? Les temps de cycle de toutes les opérations en pipeline sont de 333 picosecondes, avec diverses activités de décodage et de bus et une capture de données par bascule avant le début du prochain cycle d'horloge.

Je m'attends à ce que l'activité la plus lente dans la lecture d'un cache attende que les lignes de données soient suffisamment éloignées (probablement différentielles: une référence et une charge réelle du bit de lecture) qu'un comparateur / verrou puisse être cadencé pour mettre en œuvre une analyse positive. action de réaction pour convertir une tension minuscule en un grand écart de tension de niveau logique de rail à rail (environ 1 volt).

analogsystemsrf
la source
1
Gardez à l’esprit que la latence L1D à 4 cycles inclut la génération d’adresses (pour les modes d’adressage simples [reg + 0-2047]), une recherche de TLB et une comparaison de balises (associative à 8 voies), ainsi que le placement des 16 octets non alignés résultants sur le port de sortie de l’unité de chargement, pour le transfert à d’autres unités d’exécution. C'est une latence de 4c pour une boucle de type pointeur mov rax, [rax].
Peter Cordes