L'un des plus intéressants est d'éviter les collisions dans le cache. Si vous connaissez un modèle d'accès à la mémoire, vous pouvez disposer les éléments auxquels vous accédez en minimisant les collisions de lignes de cache entre les données auxquelles vous avez accédé. Vous pouvez le faire pour les données et le code.
Il est relativement difficile de déterminer les schémas d'accès aux données, mais vous pouvez facilement déterminer les schémas d'accès au code. Étant donné un graphe d'appel, les ensembles de blocs qui composent les corps de fonctions, et quelques estimations des fréquences de transition entre les blocs, vous pouvez assigner des blocs de code au cache d'une manière qui maximise la probabilité que le prochain bloc être dans une autre ligne de cache qui ne soit pas en conflit avec celle en cours. Une idée intéressante était que vous deviez seulement assigner des blocs de code qui étaient "chauds" (haute probabilité d'exécution); peu importe où vous mettez les froids. IIRC, cela signifie que vous pouvez trier les blocs par fréquence d'exécution probable, puis les affecter dans cet ordre. Vous avez simplement besoin d'une analyse globale: -} Le premier endroit que j'ai lu à ce sujet, l'optimizatoin a été réellement implémenté dans le cadre d'un éditeur de liens, ce qui est une façon de mettre la main sur tout le programme. Je ne me souviens pas d'une vue d'ensemble ou d'un ensemble de techniques collectées sympas. Les conférences PLDI ont tendance à avoir des documents de recherche sur ce sujet, cependant.
L'alignement des boucles par rapport aux lignes de cache peut aider, dépend des collisions et des expulsions. les éléments non utilisés mais réutilisés, qui prennent deux lignes de cache, mais qui pourraient vous convenir, vous coûtent deux fois plus de temps, récupérant 8 mots à chaque exécution au lieu de dire 2 ou 3. Pour voir ceci en action, ajoutez ou Enlevez un puis deux puis trois nops tôt dans le .text pour forcer un changement dans l'alignement de l'ensemble du programme, puis observez votre changement de performance. –