[ Lundi 3 novembre 2008 ] par Guillaume Louel
Intel Core i7 : (R)évolution ?
   
|
 Prix en boutique (hors frais de port)
Pratique de l'exposition en photographie 3e éd. Amazon.fr 20.90 €


L'HyperThreading en pratique



Le retour de l'HyperThreading n'est pas un clin d'œil aux Pentium 4. Dans la pratique, s'il revient, c'est pour une raison à la fois similaire et différente. Dans le Pentium 4, il fallait compenser la longueur extrême du pipeline qui, lors d'un branchement raté, devait se vider complètement avant de se remplir d'instructions de nouveau. Le problème posé était donc que les unités de calculs du processeur (la partie Execution) se tournaient les pouces en attendant.

Il n'y a pas de problème de longueur de pipeline avec les Core 2 ou les Core i7, mais malgré tout les unités de calculs ne sont pas stressées en permanence. Rajouter l'HyperThreading (deux pipelines avant les unités d'exécution) permet donc, en théorie, de maximiser l'utilisation de ces unités et donc de tirer le maximum de performances de son processeur. Sandra illustre assez bien cela :



Nous comparons ici les performances du Core i7 en ayant désactivé puis activé l'option HT. Comme vous pouvez le voir, les apports théoriques de l'HyperThreading sont réels, montant a plus de 55% pour les opérations à virgule flottante.

Quid de la pratique ?




De gros gains dans les applications multithreadés. x264, Pov et WinRar se régalent. Pour les autres on trouve des gains plus modestes, et même des baisses de performances sous 3D Mark 2005. L'HT est il l'ennemi des joueurs, comme il l'avait été a une certaine époque sur les Pentium 4 ? Nous avons voulu le vérifier dans les jeux que nous utilisons d'habitude pour tester les cartes graphiques :



L'Hyper Threading ralentit légèrement les jeux, oui. Cela reste infime cependant puisque les pertes oscillent entre 0.5 et 3%.

D'ou viennent ces pertes quand nous voyions plus haut des gains massifs ? Comme toujours quand on ne sait pas trop dans l'informatique, il faut tout mettre sur le dos de Microsoft.

Dans la pratique il y a deux phénomènes qui s'additionnent. Le premier est qu'en 2008, les jeux ne savent pas utiliser a bon escient plusieurs cores. Même si ces jeux utilisent parfois plusieurs threads, leurs performances (le nombre d'images affichées par secondes) sont liées aux performances du thread principal qui communique avec DirectX. L'espoir pour les jeux, c'est DirectX 11 qui sera enfin capable de supporter plusieurs threads graphiques dans un jeu, et qui devrait donc améliorer fortement les performances des solutions multicoeurs.

Si DirectX (et donc Microsoft) est en cause pour le premier problème, c'est la gestion des threads de Windows qui est notre deuxième coupable. Pour rappel, chaque programme sous Windows est un processus. Un processus peut décider d'utiliser plusieurs threads, des morceaux de sous programmes, afin d'utiliser au mieux plusieurs cores. Le programmeur ne décide cependant pas de la répartition de ses threads sur les cœurs. C'est la tache d'un morceau du noyau de Windows, que l'on appelle le scheduler.

Son rôle est assez simple, il prend les threads et les assigne à un cœur. Il va surveiller leur exécution, et peut décider à tout moment de les assigner à un autre cœur si il le désire. Car le scheduler doit gérer tous les threads de tous les programmes qui tournent sur votre système (ce qui inclut tout les services Windows, au minimum). Lorsque l'un se bloque pour une fraction de seconde, le scheduler va déplacer la thread vers un autre core pour qu'elle continue tranquillement son exécution dans les meilleures conditions possibles. Quel est le rapport avec l'Hyper Threading ? Il y a deux cas. Le premier est celui ou Windows décide de déplacer un thread d'un cœur virtuel d'un même core à l'autre. C'est la solution idéale puisqu'il n'y a pas besoin alors de recopier les données du cache dans celui d'un autre cœur. Le mauvais cas, c'est celui ou pour une raison ou une autre, le scheduler de Windows place deux threads gourmands sur les deux cœurs virtuels d'un core physique. La situation ne dure généralement pas très longtemps, mais cela peut provoquer un étouffement, le temps que le scheduler s'aperçoive de sa bêtise et réassigne l'une des deux threads ailleurs.

Les dégâts collatéraux de l'HT sont cependant très limités sur le Core i7 par rapport à ce qui se passait sur Pentium 4. En grande partie parce qu'avec un plus grand nombre de cœurs, on réduit les chances de collisions. Et que pour se retrouver dans un cas très défavorable, il faudrait avoir une application qui ne sache utiliser pleinement que quatre threads en simultanée. Un cas qui n'existe quasiment pas, les logiciels étant capables de tourner sur 4 threads pouvant facilement tourner sur 8, et se ranger dans la catégorie des applications qui profitent de l'Hyper Threading. On se doit également de rappeler que si Microsoft avait indiqué que le scheduler de Vista serait plus intelligent et s'assurerait d'utiliser à bon escient les cœurs virtuels, dans la pratique il n'en est rien. Le scheduler de Windows Vista propose le même comportement que celui de Windows XP.

Pour résumer, l'HyperThreading propose de gros gains et de petits dommages dans les cas critiques."


< Les canaux mémoires en pratique3D Mark 2005 et 2006 >

Les Processeurs déjà testés
 COMPARATEUR DE PRIX 
Trouvez le meilleur prix
OK