Lorsque tu transfères une ligne d'un niveau à un autre, cette dernière ne peut être utilisée que si l'intégralité de la ligne a été transférée. Une ligne de cache sur x86 fait 64 bytes. Le bus a une largeur de 8 bytes. Donc pour transférer 64 bytes, il faut 8 transferts au total. Si Nicolas a raison et qu'il existe plusieurs ports d'écriture et plusieurs ports de lecture (en tout cas sur les Nehalem ça ne semblait pas vrai du tout quand j'avais fait mes benchs), alors la latence et la bande-passante peuvent avoir sérieusement augmenté1. Donc pour résumer : au moins pour les micro-archis Nehalem et SandyBridge, à ma connaissance il n'y a qu'un seul port de lecture et un seul d'écriture utilisables pour les L1 et L2 (qui sont privés). Le L3, ça dépend du modèle. Par exemple sur les Nehalem EP, c'est pareil que pour les L1/L2, mais pour les Nehalem EX, ils utilisent un cache de type NUCA, avec un bus segmenté qui peut allonger la latence jusqu'à 8 cycles, mais augmente la bande passante de façon significative par rapport aux EP.
Au passage, les 32 bytes/cycle annoncés sont expliqués dans le papier que je référence plus bas : sur les archis Intel, il y a 5 ou 6 ports : 1 port pour l'ALU, 1 port pour le ×ばつ flottant, un pour le + flottant, un pour les loads, et un pour les stores (parfois certaines archis on 2 ALU, mais pour l'architecture Nehalem je crois pas). Si tu émets un store et un load « en même temps » en utilisant les SSE, alors tu as effectivement bougé 32 bytes depuis les registres vers le L1. Par contre, je renvoie à la figure 4 du papier mis en note : s'il faut aller chercher la ligne de cache jusqu'en L3, alors ça peut prendre jusqu'à 14 ou 20 cycles (latence).
Si la "bande passante" est de 64Bytes/cycle, j'imagine que le bus fait 64Bytes, non ?
Non. Si tu charges une ligne depuis la RAM jusqu'au L1, puis jusque dans un registre, alors tu vas payer la latence au prix fort. Par contre, si tu effectues des opérations arithmétiques avec les données accédées, tu vas bénéficier des effets de cache (temporalité : tu réutilises les mêmes adresses mémoire; et localité : tu n'as pas besoin d'aller chercher les mots « voisins » du mot que tu avais initialement chargé). Comme en plus il existe des prefetchers extrêmement efficaces sur archi x86 (si tu as un cache miss, alors la ligne de cache suivant celle que tu veux est automatiquement préchargée; sur Intel, il y a un pattern matcher d'adresses, et tant que ça reste dans une page physique, le prefetcher va reconnaître le pas de déplacement et précharger automatiquement les lignes qui correspondent), tu n'as généralement pas trop à t'inquiéter de payer la latence à chaque fois : tu vas juste payer le prix fort de temps en temps.
Je renvoie à cet article qui décortique pas mal la micro-architecture du Nehalem EP. J'ai bossé avec l'un des auteurs : ils sont très sérieux et rigoureux. ↩
[^] # Re: Concentration?
Posté par lasher . En réponse au journal Le Power8 d'IBM pourra t-il s'imposer dans le monde des entreprises ?. Évalué à 4.
Lorsque tu transfères une ligne d'un niveau à un autre, cette dernière ne peut être utilisée que si l'intégralité de la ligne a été transférée. Une ligne de cache sur x86 fait 64 bytes. Le bus a une largeur de 8 bytes. Donc pour transférer 64 bytes, il faut 8 transferts au total. Si Nicolas a raison et qu'il existe plusieurs ports d'écriture et plusieurs ports de lecture (en tout cas sur les Nehalem ça ne semblait pas vrai du tout quand j'avais fait mes benchs), alors la latence et la bande-passante peuvent avoir sérieusement augmenté1 . Donc pour résumer : au moins pour les micro-archis Nehalem et SandyBridge, à ma connaissance il n'y a qu'un seul port de lecture et un seul d'écriture utilisables pour les L1 et L2 (qui sont privés). Le L3, ça dépend du modèle. Par exemple sur les Nehalem EP, c'est pareil que pour les L1/L2, mais pour les Nehalem EX, ils utilisent un cache de type NUCA, avec un bus segmenté qui peut allonger la latence jusqu'à 8 cycles, mais augmente la bande passante de façon significative par rapport aux EP.
Au passage, les 32 bytes/cycle annoncés sont expliqués dans le papier que je référence plus bas : sur les archis Intel, il y a 5 ou 6 ports : 1 port pour l'ALU, 1 port pour le ×ばつ flottant, un pour le + flottant, un pour les loads, et un pour les stores (parfois certaines archis on 2 ALU, mais pour l'architecture Nehalem je crois pas). Si tu émets un store et un load « en même temps » en utilisant les SSE, alors tu as effectivement bougé 32 bytes depuis les registres vers le L1. Par contre, je renvoie à la figure 4 du papier mis en note : s'il faut aller chercher la ligne de cache jusqu'en L3, alors ça peut prendre jusqu'à 14 ou 20 cycles (latence).
Non. Si tu charges une ligne depuis la RAM jusqu'au L1, puis jusque dans un registre, alors tu vas payer la latence au prix fort. Par contre, si tu effectues des opérations arithmétiques avec les données accédées, tu vas bénéficier des effets de cache (temporalité : tu réutilises les mêmes adresses mémoire; et localité : tu n'as pas besoin d'aller chercher les mots « voisins » du mot que tu avais initialement chargé). Comme en plus il existe des prefetchers extrêmement efficaces sur archi x86 (si tu as un cache miss, alors la ligne de cache suivant celle que tu veux est automatiquement préchargée; sur Intel, il y a un pattern matcher d'adresses, et tant que ça reste dans une page physique, le prefetcher va reconnaître le pas de déplacement et précharger automatiquement les lignes qui correspondent), tu n'as généralement pas trop à t'inquiéter de payer la latence à chaque fois : tu vas juste payer le prix fort de temps en temps.
Je renvoie à cet article qui décortique pas mal la micro-architecture du Nehalem EP. J'ai bossé avec l'un des auteurs : ils sont très sérieux et rigoureux. ↩