Comment le cache peut-il être aussi rapide?

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

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?

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.

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

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 :

• L'article de David Kanter sur la microarchie SnB (avec d'excellents diagrammes et davantage axé sur la conception de l'ararch que sur la façon de l'optimiser).
• Manuel d'optimisation d'Intel
• Microarch pdf d'Agner Fog (et tableaux d'instructions et guide d'optimisation).
• Le wiki des balises x86 de SO pour les liens vers ceux-ci et plus encore.

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.

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.

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).