Quote:
|
Originally Posted by childerik
Merci pour ton conseil, d'autant qu'après avoir relu plusieurs articles sur x86-secret, j'ai appris que les caches L1 et L2 du Prescott subissaient des latences nettement plus élevées que ceux du Northwood, ce qui explique les pertes de performances dans les applications sollicitant fortement ces caches (et non l'allongement du pipeline comme certains le pensaient).
|
>> Non non, les articles expliquant la baisse de performances par l'allongement du pipeline ne sont pas faux.
Les deux paramètres ont en effet une influence.
En effet, s'il est évident qu'une cache plus lente pénalisera les performances, il est aussi relativement aisé de se rendre compte que l'augmentation de la longueur du pipeline est aussi pénalisante.
Explication : un programme informatique est rarement linéaire, et comporte généralement de nombreux sauts conditionnels.
Les temps de détermination de la condition, et donc de la suite du code a exécuter étant parfois relativement long, le processeur anticipe en exécutant en avance le code d'un des deux cas. Ainsi, si le code exécuté est le bon, on peut gagner pas mal de temps.
Mais par contre, si le calcul de la condition indique que c'est l'autre partie du code qu'il fallait exécuter, il faut vider le pipeline, et attendre qu'il soit de nouveau remplis avec le bon code pour continuer l'exécution du programme, ce qui engendre un petit retard d'autant plus long que le pipeline est profond.
Il est d'ailleurs à noter que de même que pour la lenteur de la cache partiellement compensée par l'augmentation de taille, la perte due à l'allongement du pipeline est partiellement compensée par l'optimisation de l'algorithme de prédiction de branchement, qui fait désormais moins d'erreurs. Reste à voir si l'amélioration de l'algorithme est suffisante pour compenser la perte (voir même pour permettre une amélioration des performances), mais je n'ai aucun chiffre fiable pour répondre à cette question.