Toutes les réponses sont dans les docs d'Intel et d'AMD, néanmoins pour pas avoir l'air trop méchant (quoique ? :P) :
Soit une fonction quelconque appelée par un call [ptr], si toutes les données utilisées par cette fonction sont, en terme d'adresse mémoire physique, contigües, alors le prefetch cache hardware aura tendance à charger ces données, au moins dans le cache L2 (?)
Je vois pas le rapport avec un call [ptr]. Si les données utilisées par la fonction sont contigues et si la fonction les utilisent dans l'ordre ou du moins dans un ordre régit par quelques fonctions affines adresse = f(numéro de l'acces mémoire) potentiellement entrelacées (si il n'y en a pas trop), alors le proc detecte qu'il peut etre judicieux de prefetcher et ce met à le faire tout seul comme un grand.
La chargement dans le cache L2 ou L1 est indépendant de lorigine de la décision de mise en cache (conseil de prefetching ou pas, prefetching automatique, mise en cache classique, etc...).
Il y a principalement 2 systèmes : inclusif ou les données de L1 sont obligatoirement aussi dans L2 et exclusif, ou les données de L1 ne sont pas dans L2 (sur certains proc il y a moins de L2 que de L1 donc dans ce cas l'exclusivité est obligatoire).
Les niveaux de cache ont des temps d'accès et potentielement un tas d'auters paramètres qui diffèrent (associativité, taille de lignes, ...).
Le choix de l'emplacement dans le cache à utiliser pour stocker un truc dans le cache dépend de l'adresse mémoire du truc à stocker, de l'associativité, et généralement d'un algorithme de type pseudo-LRU.
La mémoire est une matrice, et le temps d'accès à tel ou tel endroit de la mémoire est le même, j'ai donc du mal à comprendre pourquoi les données doivent être absolument alignées pour être chargé dans le cache ?
Déjà le temps d'accès n'est pas le même pour des accès contigus ou aléatoire. En contigu ca va plus vite, parce que tu n'a pas à transmettre la nouvelle adresse que tu veux charger / stocker et que ya surrement du matos de prefetching aussi dans les controleurs de RAM.
Et alignées comment ? Alignées de sorte à bien tenir dans un registre 32/64 bit ou aligné à plus grosses granulités, par exemple deux grosses chaînes de caractères de 16 Ko ?
Et qu'est-ce que veut dire contigues ?
Les données doivent en général être alignées sur la taille du registre dans lesquels elles vont attérir pour que ca aille plus vite, sinon le proc doit utiliser une unitée de décalage binaire pour les remettre ou il faut. Certains jeu d'instruction (principalement sur RISC et le SIMD de nos braves x86) n'acceptent même pas les accès non alignés (sauf des fois avec des instructions spéciales qui rament encore plus).
Il y a aussi le problème de la disposition en mémoire (faut-il faire un tableau de structures ou une structure de tableaux ?) et de l'associativité du cache (n-voix, full associative ?) mais j'ai pas spécialement le temps de détailler tout ca.
Prenons un exemple :
Imaginons qu'à partir de deux images on veuille obtenir une seule qui soit la première plus l'autre en transparence (un calque sous gimp en qq sorte).
Pour stocker mon image de manière contigu, Je peux les stocker les unes à côté des autres. Mais si elles font plus de 512 Ko, c'est comme si elle n'étaient pas contigûes : elles ne tiennent pas dans le cache (moins d'un Mo à l'heure actuelle).
Le cache n'est pas obligé de sotcker des données contigues, y a toutes les notions de tailles de lignes et d'associativité qu'il faut connaitre. Pour une zone mémoire données de la taille d'une ligne, il y a plusieurs lignes de cache dans lesquelles tu peux la stocker (ou tu peux eventuellement la mettre n'importe ou si tu a un cache pleinement associatif).
Je peux aussi décider de les découper "ligne à ligne" et mettre les lignes des 2 images 2 à 2 contigües : 1024 octet de l'une et à côté je stocke 1024 octets de l'autre, "ligne par ligne". Là peut-être que ça passe ?
Je me met dans un cadre où je ne veux pas toucher aux instructions prefetch des processeurs récent.
Sur deux gros blocs comme ça soit contigus soit entrelacés je present que le stockage en ram ne va pas changer grand chose. Le prefteching automatique est capable de gerer plusieurs flux d'accès simultannément. Les problèmes d'associativité ne joueront pas si lalgo accède aux mémoires une seule fois puisque seul leffet de prefetching va apporter une acceleration. Si par contre une succession d'algo est appliqué sur plusieurs images, il peut être interressant de découper en morceau le traitement de l'image pour que les données sur lesquels vont s'appliquer tous les traitements successifs restent en cache. Selon les cas et selon l'associativité une reorganisation en mémoire peut parfois etre necessaire mais c'est rare (c'est surtout lorganisation en arborescences des données multidimensionneles qu'il faut optimiser, nottement en SIMD).
# Lire la doc d'Intel et d'AMD merci
Posté par Guillaume Knispel . En réponse au journal La mémoire, goulot d'étranglement : optimiser le cache processeur.. Évalué à 10.
Soit une fonction quelconque appelée par un call [ptr], si toutes les données utilisées par cette fonction sont, en terme d'adresse mémoire physique, contigües, alors le prefetch cache hardware aura tendance à charger ces données, au moins dans le cache L2 (?)
Je vois pas le rapport avec un call [ptr]. Si les données utilisées par la fonction sont contigues et si la fonction les utilisent dans l'ordre ou du moins dans un ordre régit par quelques fonctions affines adresse = f(numéro de l'acces mémoire) potentiellement entrelacées (si il n'y en a pas trop), alors le proc detecte qu'il peut etre judicieux de prefetcher et ce met à le faire tout seul comme un grand.
La chargement dans le cache L2 ou L1 est indépendant de lorigine de la décision de mise en cache (conseil de prefetching ou pas, prefetching automatique, mise en cache classique, etc...).
Il y a principalement 2 systèmes : inclusif ou les données de L1 sont obligatoirement aussi dans L2 et exclusif, ou les données de L1 ne sont pas dans L2 (sur certains proc il y a moins de L2 que de L1 donc dans ce cas l'exclusivité est obligatoire).
Les niveaux de cache ont des temps d'accès et potentielement un tas d'auters paramètres qui diffèrent (associativité, taille de lignes, ...).
Le choix de l'emplacement dans le cache à utiliser pour stocker un truc dans le cache dépend de l'adresse mémoire du truc à stocker, de l'associativité, et généralement d'un algorithme de type pseudo-LRU.
La mémoire est une matrice, et le temps d'accès à tel ou tel endroit de la mémoire est le même, j'ai donc du mal à comprendre pourquoi les données doivent être absolument alignées pour être chargé dans le cache ?
Déjà le temps d'accès n'est pas le même pour des accès contigus ou aléatoire. En contigu ca va plus vite, parce que tu n'a pas à transmettre la nouvelle adresse que tu veux charger / stocker et que ya surrement du matos de prefetching aussi dans les controleurs de RAM.
Et alignées comment ? Alignées de sorte à bien tenir dans un registre 32/64 bit ou aligné à plus grosses granulités, par exemple deux grosses chaînes de caractères de 16 Ko ?
Et qu'est-ce que veut dire contigues ?
Les données doivent en général être alignées sur la taille du registre dans lesquels elles vont attérir pour que ca aille plus vite, sinon le proc doit utiliser une unitée de décalage binaire pour les remettre ou il faut. Certains jeu d'instruction (principalement sur RISC et le SIMD de nos braves x86) n'acceptent même pas les accès non alignés (sauf des fois avec des instructions spéciales qui rament encore plus).
Il y a aussi le problème de la disposition en mémoire (faut-il faire un tableau de structures ou une structure de tableaux ?) et de l'associativité du cache (n-voix, full associative ?) mais j'ai pas spécialement le temps de détailler tout ca.
Prenons un exemple :
Imaginons qu'à partir de deux images on veuille obtenir une seule qui soit la première plus l'autre en transparence (un calque sous gimp en qq sorte).
Pour stocker mon image de manière contigu, Je peux les stocker les unes à côté des autres. Mais si elles font plus de 512 Ko, c'est comme si elle n'étaient pas contigûes : elles ne tiennent pas dans le cache (moins d'un Mo à l'heure actuelle).
Le cache n'est pas obligé de sotcker des données contigues, y a toutes les notions de tailles de lignes et d'associativité qu'il faut connaitre. Pour une zone mémoire données de la taille d'une ligne, il y a plusieurs lignes de cache dans lesquelles tu peux la stocker (ou tu peux eventuellement la mettre n'importe ou si tu a un cache pleinement associatif).
Je peux aussi décider de les découper "ligne à ligne" et mettre les lignes des 2 images 2 à 2 contigües : 1024 octet de l'une et à côté je stocke 1024 octets de l'autre, "ligne par ligne". Là peut-être que ça passe ?
Je me met dans un cadre où je ne veux pas toucher aux instructions prefetch des processeurs récent.
Sur deux gros blocs comme ça soit contigus soit entrelacés je present que le stockage en ram ne va pas changer grand chose. Le prefteching automatique est capable de gerer plusieurs flux d'accès simultannément. Les problèmes d'associativité ne joueront pas si lalgo accède aux mémoires une seule fois puisque seul leffet de prefetching va apporter une acceleration. Si par contre une succession d'algo est appliqué sur plusieurs images, il peut être interressant de découper en morceau le traitement de l'image pour que les données sur lesquels vont s'appliquer tous les traitements successifs restent en cache. Selon les cas et selon l'associativité une reorganisation en mémoire peut parfois etre necessaire mais c'est rare (c'est surtout lorganisation en arborescences des données multidimensionneles qu'il faut optimiser, nottement en SIMD).