Alors voilà, je viens de découvrir que l'HyperThreading n'a pas que du bon...
 
Petit rappel pour les 2 du fond :l'HyperThreading permet d'émuler deux processeurs (logiques) via un seul processeur physique, afin d´optimiser au mieux l´utilisation de ce dernier.
 
Je viens de faire des tests sur un XEON 3.06 HT avec 3Go de RAM et du SCSI de partout... Et les résultats m'ont surpris.  
La personne qui utilise cet ordi a besoin d'un très grosse puissance de calculs pour ses softs ( 1 de ses soft utilise 2Go de RAM tout de meme...). Pendant que son soft tournait, on a regardé l'utilisation CPU: IMPOSSIBLE de dépasser 50%. On a bien mis une heure pour s'appercevoir qu'en désactivant l'HT dans le bios, l'utilisation se mettais a plafoner alors a 100%(et le temps de calcul était divisé par 2 tout de meme...).
Donc pour les soft qui gèrent l'HT, je dis super cool! Mais pour les autres...attention !  
 
Voila un topic qu'il est interessant !  

Si tu balance une appli monothread sur une configuration HT, l'utilisation des CPU logique sera toujours indiquée comme à 50%, même si l'unique processeur logique utilisé utilise en fait 99% du processeur PHYSIQUE.

Oui mais pourquoi le temps de calcul a diminué de moitiée alors ?
 
[EDIT]: Mon dieu...j'avais pas vu que c'était le maître en personne qui me répond !

Amen

L'hyperthreading a ces avantages mais il a aussi des défauts, en effet les deux threads du P4 HT entre en concurence ce qui a un effet négatifs sur la gestions des buffers du P4 (notament les mémoires caches) cela provoque de nombreuses erreurs en lecture du cache d'où la baisse de performance  
 
cependant 50% de perfs en moins sans l'Ht, je trouve ça énorme
surtout que l'HT a un effet positif sur le  rendement des unités de calculs et autres.

Non, pour détailler le post de marc, imagine que windows gère l'HT comme deux processeurs différents.
 
Imagine que le 1 est le gros du travail et le 2 le petit plus apporté par l'HT.
 
Windows, dans le calcul du load CPU, va pas se faire chier : on prends le load CPU1, sur 100%, on le ramene a 50%, pareil pour le load CPU2, et on additionne le tout.
 
Maintenant, il faut comprendre que le HT, le CPU2 si tu préfères, est la que pour grapiller des sardines si y a multithread.
 
Donc si ton CPU1 est utilisé a 100%, ca veut dire que le processeur physique est utilisé a 100% et que l'HT sert a rien à ce moment précis, car tout le proco physique est pris par la tache.
 
Seulement windows traite ca comme un Bi-CPU lors de l'affichage, alors forcément... il divise le load par deux.
 
Pour etre plus "exact", en fait, il faudrait que le CPU1 représente 100% des capacités du systeme, et le CPU2 un bonus de 10% par exemple.
 
Ainsi si monothread en full load tu es a 100% ( au lieu de 50 actuellement), et 110 si l'HT te fait gagner un truc ( contre 100% maintenant).
 
Plus parlant et plus "proche" de la réalité.
 
Il est vrai cependant que le HT peut entrainer plus de Cache Miss. Mais il faut voir que bon, l'HT sert pas si un gros calcul prends tout le CPU ( rien a "grapiller" pour etre vulgaire), donc dans le cas du gros programme monothread ultra-gourmand, P4 HT == P4 non HT...

ya pas a dire ce genial l' HT,pouvoir encoder et faire autre chose a coté ce le pied

Il tourne sous quel OS ? si il est sous Windows 2000 et que l'appli est mono threadée, les résultats ne sont pas étonnants, Windows 2000 gérant assez mal l'hyperthreading pour les applis mono threadées.

"avec un OS qui comprend la gestion de l'HT" et un encodeur qui sature pas à 100% le proc physique

Je confirme ce que dit têtedechien.
En fait windows considère qu'il a à faire à 2 CPU ce qui est totalement faux. Il faut considérer la barre "utilisation de l'UC" comme l'addition des 2 Cpu à 50/50.
Quand un programme n'utilise pas le HT windows l'interprète comme si un seul CPU était en fonction. Du coup çà fait 50% d'utilisation de l'UC.
Si un programme utilise le HT windows considère que 2 CPU fonctionnent soit 100% de l'UC.
 
Tout simplement!
 
 
 

ça y est g retrouvé l'article qui parlait de l'Ht en détail
C par ici http://www.x86-secret.com/articles/cpu/3066/3066-4.htm
 
J'ai fait quelques erreurs dans mon expliquations mais mon raisonement se tiens quand même  

 
Exact.
Paradoxalement j'active pas toujours l'hypertreading sur les progr.
Je m'explique. Quand j'utilise TMPGnec pour coder une vidéo parfois je coche l'HT parfois pas. Si je coche l'HT çà accélère quelque peu le processus de codage mais du coup çà monopolise les 2 "UC virtuels". Si je le décoche, TMPGnec est plus lent mais je garde suffisament de ressources processeurs pour lancer d'autres tâches en parallèle et çà c'est cool.

Faudra qu'on ertrouve un terrain de désaccord un jour yoyo

 
Ne t'inquiète pas çà va revenir un jour
Ce n'est qu'une mauvais passe. Tous les couples ont malheureusement des phases de bonne entente mais nous finirons bien par nous détester à nouveau comme au 1er jour  

J'espère de tout mon ptit coeur

 
bien sur,je tourne sous Xp donc no soucils,et pour l'instant j'ai pas trouvé un encodeur qui me sature le proc a 100%

 
TPMPGenc. Il gère l'HT et une fois activé c'est du 100%  

Je vais peut être dire une connerie mais plus haut il me semble qu'il y avait :
 
Tanshiro a écrit :
--------------------------------------------------------------------------------
Oui mais pourquoi le temps de calcul a diminué de moitiée alors ?  
 
[EDIT]: Mon dieu...j'avais pas vu que c'était le maître en personne qui me répond !  
 
--------------------------------------------------------------------------------
 
 
Si le temps de calcul diminue de moitié ça veux dire que ce n'est pas qu'une question d'interprétation des 50% et 100% en parlant de 50% x2 µP ou 100% x1 µP...
 
...

 
Ah oui effectivement c'est pas normal çà que le temps de calcul soit divisé par 2

 
ah,me semble qu'il ne fait pas le divx non?je m'en suis servi pour du vcd et svcd.

 
Nan il convertit le divx, en vcd, svcd ou format DVD.

 
ah ben ca m'interresse pas alors je vait continuer a encoder tout en fesant autre chose a coté