« Fonctionnement d'un ordinateur/La performance d'un ordinateur » : différence entre les versions

Contenu supprimé Contenu ajouté
Ligne 175 :
 
: <math>\text{Taux de défauts par instruction} = \frac{\text{Nombre de défauts de cache}}{\text{Nombre d'instructions}} = \text{Taux de défauts de cache} \times \frac{\text{Nombre d’accès mémoires}}{\text{Nombre d'instructions}}</math>
 
Si certains défauts de cache sont inévitables quel que soit le cache, comme les défauts à froid mentionnés plus haut, d'autres défauts peuvent être évités en augmentant la capacité du cache. En effet, quandC'est le processeurcas veutdes chargerdéfauts unede donnéecapacité dans un cache plein, des donnéesqui sont rapatriéescausés enpar RAMun pour laisser place aux donnéesaccès à charger.une Etdonnée siqui lesa donnéesété rapatriéeséliminée sontdu accédéescache ultérieurement, un défautfaute de cache s'ensuitplace. Plus le cache est gros, moins il a de chances d'être rempli, moins il doit rapatrier de données, plus son taux de succès augmente. Mais nous reviendrons sur le lien entre taille du cache et taux de défaut plus bas.
 
Le taux de succès ne dépend pas que du cache, mais aussi de la conception des programmes exécutés. Une bonne utilisation du cache (ainsi que de la mémoire virtuelle) repose sur le programmeur qui doit prendre en compte les principes de localités dès la conception de ses programmes. Par exemple, un programmeur peut parfaitement tenir compte du cache au niveau de son algorithme : on peut citer l'existence des algorithmes ''cache oblivious'', qui sont conçus pour être optimaux quelle que soit la taille du cache. Ces algorithmes permettent le plus souvent de gros gains en performances dans la plupart des situations sur les architectures modernes. Le programmeur peut aussi choisir ses structures de données de manière à améliorer la localité. Par exemple, un tableau est une structure de donnée respectant le principe de localité spatiale, tandis qu'une liste chainée ou un arbre n'en sont pas (bien qu'on puisse les implémenter de façon à limiter la casse). D'autres optimisations sont parfois possibles : par exemple, le sens de parcours d'un tableau multidimensionnel peut faire une grosse différence. Cela permet des gains très intéressants pouvant se mesurer avec des nombres à deux ou trois chiffres. Je vous recommande, si vous êtes programmeur, de vous renseigner le plus possible sur les optimisations de code ou algorithmiques qui concernent le cache : il vous suffira de chercher sur Google. Il y a une citation qui résume bien cela, prononcée par un certain Terje Mathisen. Si vous ne le connaissez pas, cet homme est un vieux programmeur (du temps durant lequel on codait encore en assembleur), grand gourou de l’optimisation, qui a notamment travaillé sur le moteur de Quake 3 Arena.
 
{{BlocCitation|Almost all programming can be viewed as an exercise in caching.|auteur=Terje Mathisen}}
 
Si certains défauts de cache sont inévitables quel que soit le cache, d'autres défauts peuvent être évités en augmentant la capacité du cache. En effet, quand le processeur veut charger une donnée dans un cache plein, des données sont rapatriées en RAM pour laisser place aux données à charger. Et si les données rapatriées sont accédées ultérieurement, un défaut de cache s'ensuit. Plus le cache est gros, moins il a de chances d'être rempli, moins il doit rapatrier de données, plus son taux de succès augmente. Mais nous reviendrons sur le lien entre taille du cache et taux de défaut plus bas.
 
===La latence moyenne d'un cache===