Pas un qui fonctionne "pour tout, partout". La plupart des processeurs ont des instructions spéciales pour vider le cache, mais ce sont souvent des instructions privilégiées, donc cela doit être fait depuis le noyau du système d'exploitation, pas avec le code en mode utilisateur. Et bien sûr, il s'agit d'instructions complètement différentes pour chaque architecture de processeur.
Tous les processeurs x86 actuels ont une instruction clflush, qui vide une ligne de cache, mais pour ce faire, vous devez avoir l'adresse de la donnée (ou du code) que vous voulez vider. Ce qui est bien pour les structures de données petites et simples, pas si bon si vous avez un arbre binaire qui est partout. Et bien sûr, pas du tout portable.
Dans la plupart des environnements, lire et écrire un grand bloc de données alternatives, par ex. quelque chose comme:
// Global variables.
const size_t bigger_than_cachesize = 10 * 1024 * 1024;
long *p = new long[bigger_than_cachesize];
...
// When you want to "flush" cache.
for(int i = 0; i < bigger_than_cachesize; i++)
{
p[i] = rand();
}
L'utilisation rand sera beaucoup plus lent que le remplissage avec quelque chose de constant/connu. Mais le compilateur ne peut pas optimiser l'appel, ce qui signifie (presque) que le code restera. Ce qui précède ne videra pas les caches d'instructions, ce qui est beaucoup plus difficile à faire. En gros, vous devez exécuter une partie (assez grande) d'un autre morceau de code pour le faire de manière fiable. Cependant, les caches d'instructions tendent à avoir moins d'effet sur la performance globale du benchmark (le cache d'instructions est EXTRÊMEMENT important pour la perforamnce du processeur moderne, ce n'est pas ce que je dis, mais dans le sens où le code est généralement assez petit dans le cache, et l'indice de référence passe plusieurs fois sur le même code, il est donc plus lent de la première itération)
Autres idées
une autre façon de simuler le comportement « non-cache » est allouer une nouvelle zone pour chaque étape de l'analyse comparative - en d'autres termes, ne pas libérer la mémoire jusqu'à la fin du test ou utiliser un tableau contenant les données, et produire des résultats, de sorte que chaque exécution dispose de son propre ensemble de données. De plus, il est courant de mesurer réellement les performances des "hot-runs" d'un benchmark, pas la première "cold run" où les caches sont vides. Cela ne dépend évidemment de ce que vous en train d'essayer d'atteindre ...
Parlez-vous du cache CPU ou du cache disque du système d'exploitation? Un délai supplémentaire de 18 secondes semble beaucoup trop long pour remplir la mémoire cache du processeur à partir de la RAM, des fautes de page + et des échecs TLB. Même les lectures aléatoires dispersées devraient pouvoir remplir toutes les lignes de cache du cache L3 d'un grand Xeon en * bien * moins d'une seconde. –
@PeterCordes D'après mes calculs, si vous faisiez des lectures dispersées dépendantes en série et prenait 100 ns chacune, même en ignorant TLB et d'autres coûts, vous ne regarderiez que 2,8 Mo de lignes de cache en 18 secondes. le domaine de la faisabilité. – BeeOnRope