Technologie Pentium 4 : Questions & réponses
Tuan le 07 janvier 2002 (12 470 lectures)
Et le cache L2, qu'en est- il ?
Le cache L2 du P4 est bien supérieur (théoriquement) à celui du Tbird. Il est interfacé en 256 bits tandis que le Tbird a un cache interfacé en 64bits. Certes il est exclusif mais il n'en est pas moins performant en théorie.
Heu c'est quoi un cache L2 exclusif ?
C'est tout simplement un cache qui ne contient jamais ce qui est déjà dans le cache L1 ! En gros il fonctionne comme réservoir si le gros cache L1 du Tbird déborde. Mais nous aurons l'occasion d'y revenir.
Mais alors le Pentium 4 l'emporte sur le total des deux caches ?
C'est un peu plus compliqué… Il y a déjà le paramètre "taille". Le Tbird a un total de cache plus gros et cela a son importance dans certaines conditions, nous le verrons… Mais surtout c'est bien d'avoir des caches rapides mais encore faut il qu'ils sachent bosser ensemble. Et là ça pose problème avec le P4.
En effet bien que le bus du cache du Tbird soit 4 fois plus étroit que celui du P4 il ne rend à son adversaire que 30% de performances.
Dis-moi, pourquoi un si faible écart ?
Parce que le P4 a un tout petit cache L1 ce qui l'oblige à accéder plus souvent au cache L2 qui parfois contient déjà des info du L1 (perte de temps et/ou redondance d'informations). Le Tbird, lui, grâce à son gros L1 et à sa technologie dual ported peut rivaliser avec le P4 car il accède moins au L2 et en terme de performances tient la dragée haute au Pentium 4. Mais surtout ce dernier tire avantage de l'énorme bande passante du L2, or celle-ci n'est exploitée que si on utilise les instructions SSE2 pour faire les transferts !!! On comprend donc mieux pourquoi les instructions SSE2 transcendent le P4…
Mais il y a encore une histoire de latence. Le L2 ne répond pas immédiatement aux requêtes…
Au fait que se passe t'il si le programme utilisé a un "corps très gros" et qu'il ne tient ni dans le cache de l'un ni dans celui de l'autre ?
C'est simple, on accède alors à la ram… Et là la SDRram est normalement gagnante sur la Rambus en temps de réponse mais pas en taux de transfert. Cependant le i850 fait des miracles et les temps de réponses sont largement concurrentiels par rapport à ceux de la SDram.
N'y avait il pas aussi une histoire de latence dans le cache L2 ?
Si revenons y. Le transfert des données entre les caches nécessite aussi un temps de réponse.
Commençons par le Tbird. Il affiche lorsque des tests sont très exigeants une latence de 20 cycles. Mais cela arrive très peu souvent car AMD a recours à un "victim buffer" qui est une zone mémoire qui permet de faire des transferts bidirectionnels entre les 2 caches et ainsi faire gagner de précieux cycles. Pourquoi ? Car quand une information manque dans le cache L1 le Tbird enlève des infos dans le "victim buffer" et en prend dans le cache L2 qui est sûr de fournir des infos que le L1 n'a pas (architecture exclusive). Ensuite le "victim buffer" donne son contenu au L2, cela permet de faire tout ça en parallèle et de ne pas perdre de temps. Ce qui donne en moyenne 11 cycles de latence. Les 20 cycles n'interviennent uniquement quand il manque trop de données dans le L1 et que le "victim buffer" est plein. Alors là tout est plus lent, le "victim buffer" doit écrire dans le L2 pour se vider pendent ce temps le L2 ne donne rien au L1 qui attend et fait attendre le processeur. Par contre sur le P4 point de "victim buffer" et le temps de latence n'est pas moins de 18 cycles !!! Mais cela n'intervient que si les données transférées sont codées en 64 bits (pour des raisons techniques). Par contre si les données sont transférées en 128 bits la latence est de 9 cycles seulement. Remarquons que sur le PIII cette latence est de seulement 7 cycles. Intel a donc augmenté la latence pour pouvoir atteindre plus facilement les hautes fréquences. Il est cependant répandu que l'on dise que la latence du P4 est inférieure. C'est tout simplement car il tourne plus vite en fréquence. Il met donc moins de temps à faire un cycle. Mais à fréquence égale il ne surpasse la concurrence de beaucoup.
Alors c'est quoi la conclusion sur les caches ?
Sur les applications dont le corps tient dans le petit cache L1 du P4 on obtient des performances hallucinantes. Sur les autres on est déjà moins performant face à la concurrence et quand le programme ne tient pas dans les 264 Ko de cache du P4 (8Ko de cache L1 + 256Ko de cache L2) alors on accède à la Ram et le P4 devient aussi performant que le Tbird. Sauf si le programme ne tient pas non plus dans les 384 Ko auquel cas le Tbird doit aussi piocher dans sa Ram qui même si elle est DDR ne permet pas d'atteindre les mêmes performances que celle de la Rambus. Mais il se trouve que la plupart des applications actuelles tiennent dans cet espace…
Le futur changera peut être la donne.
N'y a t-il pas d'autres innovations au niveau des caches ?
Si justement, il y a le "trace cache". Mais avant d'en parler, je vais faire un petit rappel sur le pipeline et quelques petits autres détails, cela paraîtra évident pour ceux qui s'y connaissent déjà mais je suis sûr que ça intéressera les autres.
Le pipeline qu'est que c'est ? Il s'agit d'une structure interne. Le processeur fait des calculs mais il ne fait pas toutes les étapes d'un seul coup. Pour des raisons qui tiennent de la physique, on décompose les unités d'exécution d'un microprocesseur pour en obtenir des plus petites qui ainsi à la manière d'un transistor plus petit (finesse de gravure) pose moins de problèmes pour monter en fréquence. D'autres avantages sont une possibilité de traiter les instructions plus vite les unes après les autres, car à la manière d'une chaîne de production, quand une unité qui compose le pipeline a fini d'effectuer son travail, elle transfert son résultat à la suivante et peut s'occuper de l'instruction qui arrive. Tandis que dans le cas d'une unité seule elle ne peut passer à l'instruction suivante uniquement si elle a fini son travail qui est plus important (et donc plus long) et ainsi "perdre" du temps.
Ainsi un pipeline est l'ensemble des unités qui compose le chemin de traitement des calculs. Le Pentium 4 a une profondeur de pipeline de 20, ce qui signifie en clair qu'il y a 20 étapes de traitement différentes d'un calcul. Cela est l'arme d'Intel pour monter en fréquence et explique qu'à finesse de gravure identique le P4 monte plus facilement en fréquences.
Mais en quoi cela concerne la mémoire cache, me direz vous? C'est simple. Un processeur ne peut pas forcément calculer comme ça. Parfois un calcul dépend du résultat d'un autre calcul. Par exemple a+b=c puis c/2+3. Pour effectuer le deuxième calcul il faut déjà le résultat du premier. A savoir c. Or on ne l'obtiendra qu'à la fin du pipeline quand la dernière étape sera effectuée. Le calcul suivant ne pourra pas être entamé avant cela. Il en résulte que les unités du pipeline attendent sans rien faire. D'où une perte de temps. Pour remédier à cela on utilise la prédiction de branchement. C'est une technique qui permet au processeur de spéculer sur l'opération suivante à effectuer. Cela s'appelle : l'exécution "out of order". Qui permet de lancer un calcul dépendant d'un autre avant que ce dernier ne soit fini. Mais les prédictions statistiques ne sont pas toujours bonnes et il arrive que le processeur prédise un mauvais calcul. Le cas échéant, le pipeline doit être vidé entièrement afin de tout recommencer. C'est une énorme perte de temps. Pour palier à cela il faut améliorer l'algorithme de prédiction. Ou alors faire comme le Pentium 4 (méthode moins efficace que la prédiction juste de branchement mais qui a son intérêt car on ne peut pas prévoir 100% des branchements). Il utilise un "trace cache" qui est un mini cache intégré au pipeline et qui mémorise les instructions déjà décodées par le microprocesseur (instructions qui viennent du L1). En cas d'erreur de prédiction le pipeline se re-rempli plus vite car le Pentium 4 n'a pas besoin d'aller les chercher dans le L1 et de les re-décoder en langage processeur (celui parlé par les unités du pipeline). On gagne ainsi du temps lors d'erreurs de prédictions. Mais ce cache doit être petit car son temps d'accès doit être ultra rapide pour ne pas pénaliser le re-remplissage du pipeline. Et il n'a d'intérêt que si sans lui le remplissage du pipeline serait plus long, à savoir si le pipeline est suffisamment long pour mettre du temps à être rempli ou si le re-décodage constituait une étape ralentissante. Ça tombe bien car le P4 a un pipeline très long et donc le "trace cache" s'avère salvateur. Remarquons que sur des processeurs type Power PC G4 ou G5 le "trace cache" serait inutile car ils ont une profondeur de pipeline comprise entre 4 et 10. Le re-décodage et re-remplissage s'avèrerait plus rapide que l'accès au "trace cache".
Le cache L2 du P4 est bien supérieur (théoriquement) à celui du Tbird. Il est interfacé en 256 bits tandis que le Tbird a un cache interfacé en 64bits. Certes il est exclusif mais il n'en est pas moins performant en théorie.
Heu c'est quoi un cache L2 exclusif ?
C'est tout simplement un cache qui ne contient jamais ce qui est déjà dans le cache L1 ! En gros il fonctionne comme réservoir si le gros cache L1 du Tbird déborde. Mais nous aurons l'occasion d'y revenir.
Mais alors le Pentium 4 l'emporte sur le total des deux caches ?
C'est un peu plus compliqué… Il y a déjà le paramètre "taille". Le Tbird a un total de cache plus gros et cela a son importance dans certaines conditions, nous le verrons… Mais surtout c'est bien d'avoir des caches rapides mais encore faut il qu'ils sachent bosser ensemble. Et là ça pose problème avec le P4.
En effet bien que le bus du cache du Tbird soit 4 fois plus étroit que celui du P4 il ne rend à son adversaire que 30% de performances.
Dis-moi, pourquoi un si faible écart ?
Parce que le P4 a un tout petit cache L1 ce qui l'oblige à accéder plus souvent au cache L2 qui parfois contient déjà des info du L1 (perte de temps et/ou redondance d'informations). Le Tbird, lui, grâce à son gros L1 et à sa technologie dual ported peut rivaliser avec le P4 car il accède moins au L2 et en terme de performances tient la dragée haute au Pentium 4. Mais surtout ce dernier tire avantage de l'énorme bande passante du L2, or celle-ci n'est exploitée que si on utilise les instructions SSE2 pour faire les transferts !!! On comprend donc mieux pourquoi les instructions SSE2 transcendent le P4…
Mais il y a encore une histoire de latence. Le L2 ne répond pas immédiatement aux requêtes…
Au fait que se passe t'il si le programme utilisé a un "corps très gros" et qu'il ne tient ni dans le cache de l'un ni dans celui de l'autre ?
C'est simple, on accède alors à la ram… Et là la SDRram est normalement gagnante sur la Rambus en temps de réponse mais pas en taux de transfert. Cependant le i850 fait des miracles et les temps de réponses sont largement concurrentiels par rapport à ceux de la SDram.
N'y avait il pas aussi une histoire de latence dans le cache L2 ?
Si revenons y. Le transfert des données entre les caches nécessite aussi un temps de réponse.
Commençons par le Tbird. Il affiche lorsque des tests sont très exigeants une latence de 20 cycles. Mais cela arrive très peu souvent car AMD a recours à un "victim buffer" qui est une zone mémoire qui permet de faire des transferts bidirectionnels entre les 2 caches et ainsi faire gagner de précieux cycles. Pourquoi ? Car quand une information manque dans le cache L1 le Tbird enlève des infos dans le "victim buffer" et en prend dans le cache L2 qui est sûr de fournir des infos que le L1 n'a pas (architecture exclusive). Ensuite le "victim buffer" donne son contenu au L2, cela permet de faire tout ça en parallèle et de ne pas perdre de temps. Ce qui donne en moyenne 11 cycles de latence. Les 20 cycles n'interviennent uniquement quand il manque trop de données dans le L1 et que le "victim buffer" est plein. Alors là tout est plus lent, le "victim buffer" doit écrire dans le L2 pour se vider pendent ce temps le L2 ne donne rien au L1 qui attend et fait attendre le processeur. Par contre sur le P4 point de "victim buffer" et le temps de latence n'est pas moins de 18 cycles !!! Mais cela n'intervient que si les données transférées sont codées en 64 bits (pour des raisons techniques). Par contre si les données sont transférées en 128 bits la latence est de 9 cycles seulement. Remarquons que sur le PIII cette latence est de seulement 7 cycles. Intel a donc augmenté la latence pour pouvoir atteindre plus facilement les hautes fréquences. Il est cependant répandu que l'on dise que la latence du P4 est inférieure. C'est tout simplement car il tourne plus vite en fréquence. Il met donc moins de temps à faire un cycle. Mais à fréquence égale il ne surpasse la concurrence de beaucoup.
Alors c'est quoi la conclusion sur les caches ?
Sur les applications dont le corps tient dans le petit cache L1 du P4 on obtient des performances hallucinantes. Sur les autres on est déjà moins performant face à la concurrence et quand le programme ne tient pas dans les 264 Ko de cache du P4 (8Ko de cache L1 + 256Ko de cache L2) alors on accède à la Ram et le P4 devient aussi performant que le Tbird. Sauf si le programme ne tient pas non plus dans les 384 Ko auquel cas le Tbird doit aussi piocher dans sa Ram qui même si elle est DDR ne permet pas d'atteindre les mêmes performances que celle de la Rambus. Mais il se trouve que la plupart des applications actuelles tiennent dans cet espace…
Le futur changera peut être la donne.
N'y a t-il pas d'autres innovations au niveau des caches ?
Si justement, il y a le "trace cache". Mais avant d'en parler, je vais faire un petit rappel sur le pipeline et quelques petits autres détails, cela paraîtra évident pour ceux qui s'y connaissent déjà mais je suis sûr que ça intéressera les autres.
Le pipeline qu'est que c'est ? Il s'agit d'une structure interne. Le processeur fait des calculs mais il ne fait pas toutes les étapes d'un seul coup. Pour des raisons qui tiennent de la physique, on décompose les unités d'exécution d'un microprocesseur pour en obtenir des plus petites qui ainsi à la manière d'un transistor plus petit (finesse de gravure) pose moins de problèmes pour monter en fréquence. D'autres avantages sont une possibilité de traiter les instructions plus vite les unes après les autres, car à la manière d'une chaîne de production, quand une unité qui compose le pipeline a fini d'effectuer son travail, elle transfert son résultat à la suivante et peut s'occuper de l'instruction qui arrive. Tandis que dans le cas d'une unité seule elle ne peut passer à l'instruction suivante uniquement si elle a fini son travail qui est plus important (et donc plus long) et ainsi "perdre" du temps.
Ainsi un pipeline est l'ensemble des unités qui compose le chemin de traitement des calculs. Le Pentium 4 a une profondeur de pipeline de 20, ce qui signifie en clair qu'il y a 20 étapes de traitement différentes d'un calcul. Cela est l'arme d'Intel pour monter en fréquence et explique qu'à finesse de gravure identique le P4 monte plus facilement en fréquences.
Mais en quoi cela concerne la mémoire cache, me direz vous? C'est simple. Un processeur ne peut pas forcément calculer comme ça. Parfois un calcul dépend du résultat d'un autre calcul. Par exemple a+b=c puis c/2+3. Pour effectuer le deuxième calcul il faut déjà le résultat du premier. A savoir c. Or on ne l'obtiendra qu'à la fin du pipeline quand la dernière étape sera effectuée. Le calcul suivant ne pourra pas être entamé avant cela. Il en résulte que les unités du pipeline attendent sans rien faire. D'où une perte de temps. Pour remédier à cela on utilise la prédiction de branchement. C'est une technique qui permet au processeur de spéculer sur l'opération suivante à effectuer. Cela s'appelle : l'exécution "out of order". Qui permet de lancer un calcul dépendant d'un autre avant que ce dernier ne soit fini. Mais les prédictions statistiques ne sont pas toujours bonnes et il arrive que le processeur prédise un mauvais calcul. Le cas échéant, le pipeline doit être vidé entièrement afin de tout recommencer. C'est une énorme perte de temps. Pour palier à cela il faut améliorer l'algorithme de prédiction. Ou alors faire comme le Pentium 4 (méthode moins efficace que la prédiction juste de branchement mais qui a son intérêt car on ne peut pas prévoir 100% des branchements). Il utilise un "trace cache" qui est un mini cache intégré au pipeline et qui mémorise les instructions déjà décodées par le microprocesseur (instructions qui viennent du L1). En cas d'erreur de prédiction le pipeline se re-rempli plus vite car le Pentium 4 n'a pas besoin d'aller les chercher dans le L1 et de les re-décoder en langage processeur (celui parlé par les unités du pipeline). On gagne ainsi du temps lors d'erreurs de prédictions. Mais ce cache doit être petit car son temps d'accès doit être ultra rapide pour ne pas pénaliser le re-remplissage du pipeline. Et il n'a d'intérêt que si sans lui le remplissage du pipeline serait plus long, à savoir si le pipeline est suffisamment long pour mettre du temps à être rempli ou si le re-décodage constituait une étape ralentissante. Ça tombe bien car le P4 a un pipeline très long et donc le "trace cache" s'avère salvateur. Remarquons que sur des processeurs type Power PC G4 ou G5 le "trace cache" serait inutile car ils ont une profondeur de pipeline comprise entre 4 et 10. Le re-décodage et re-remplissage s'avèrerait plus rapide que l'accès au "trace cache".
