Il est tout à fait possible de comprendre et d'optimiser les caches. Cela commence par la compréhension du matériel et se poursuit par le contrôle du système. Moins vous aurez de contrôle sur le système, moins vous aurez de chances de réussir. Linux ou Windows exécutant un tas d'applications / threads qui ne sont pas inactifs.
La plupart des caches sont quelque peu similaires dans leurs propriétés, utilisent une partie du champ d'adresse pour rechercher des hits, ont une profondeur (voies) et une largeur (ligne de cache). Certains ont des tampons d'écriture, certains peuvent être configurés pour écrire ou contourner le cache lors des écritures, etc.
Vous devez être parfaitement conscient de toutes les transactions de mémoire en cours qui atteignent ce cache (certains systèmes disposent d'instructions indépendantes et de caches de données facilitant la tâche).
Vous pouvez facilement rendre un cache inutile en ne gérant pas soigneusement votre mémoire. Par exemple, si vous avez plusieurs blocs de données que vous traitez, en espérant les garder en cache, mais ils sont en mémoire à des adresses qui sont même multiples par rapport à la vérification des caches hit / miss, disons 0x10000 0x20000 0x30000, et vous avez plus de ces façons que dans le cache, vous pouvez très rapidement finir par faire quelque chose qui fonctionne assez lentement avec le cache activé, plus lent qu'avec le cache désactivé. Mais changez cela en peut-être 0x10000, 0x21000, 0x32000 et cela pourrait être suffisant pour profiter pleinement du cache, réduisant les expulsions.
En fin de compte, la clé de l'optimisation d'un cache (enfin, à part bien connaître le système) est de conserver toutes les choses dont vous avez besoin de performances dans le cache en même temps, en organisant ces données de sorte qu'il soit possible d'avoir tout cela dans le cache à la fois. Et empêcher des choses comme l'exécution de code, les interruptions et autres événements réguliers ou aléatoires d'expulser des parties importantes de ces données que vous utilisez.
Il en va de même pour le code. C'est un peu plus difficile, car vous devez contrôler les emplacements où se trouve le code pour éviter les collisions avec d'autres codes que vous souhaitez conserver dans le cache. Lors du test / profilage de tout code passant par un cache qui ajoute une seule ligne de code ici et là ou même un seul nop, tout ce qui décale ou modifie les adresses où le code vit d'une compilation à une autre pour le même code, change où les lignes de cache tombent dans ce code et modifient ce qui est expulsé et ce qui ne l'est pas pour les sections critiques.