en effet pour avoir un P4 3.06 HT depuis sa sortie , j'ai pu triturer dans tous les sens ses caractéristiques.
 
Bilan , je fonctionne en permanence avec l'HT désactivé car :
 
* Avec HT , impossibilité oubien très fort ralentissement pour l'insttallation de certain jeux récent  ( ex : Unreal 2003 entre autre )
 
* Avec HT , ralentissement important lors des téléchargements Net.
 
* Avec HT , Echange de gros fichiers ralentis entre 2 partitions oubien entre 2 PC d'un même réseau local
 
* Avec HT ,Encodage Div X plante assez souvent.
 
Par contre , j'ai pu mesurer l'avantage de l'HT dans certain Bench , mais pas de manière sensible dans mes appli habituelles
 
 
Hyper Treading = bof bof        
 
 
Votre expérience m'intéresse  

sous quel OS ?

P4 3.06 HT @ 3795 Mhz max (3520 en vitesse de croisière à 1.55 Volt)  
 
Asus P4PE Rev 1.03 bios 1003.010  
1024 Mo DDR 3500 Geil Ultra  
Heat Pipe IHC-L71 + ventil 6000rpm  
Hercules ATI 9700 Pro  
DD IBM 180 GXP 80 Go  
TFT 17" Prophetview 920 DVI  
 
 
P4 2.8 @ +++ Mhz à 1.52 Volt  
Shuttel SB51  
512 DDR 3200 Winbond  
Ti 4200 Suma  
 
P4 2.53 "confidential"  
3 Ghz , (15 X 200)  
Asus P4PE  
512 DDR 3200 Corsair  
Ti 4200 Leadteck  
 
XP2200  
Asus A7V333  
256 DDR 2700  
Ti 4200 Leadteck  
 
Modem Routeur DG 814
 
Bin vu le matos de monsieur sûrement pas sous winME   .

Win XP Pro  

thx,  
C'était un peu évident vu que c'est le seul OS Qui peut en tirer partie, mais des fois on tombe sur des raleurs sans cervelles.
 
Et sinon, j'imagine que les pb que tu cites disparaissent une fois que tu désactive l'HT, non ?

Exacte , la différence est flagrante .
 
Copier un fichier de 1 Go d'une partition à l'autre est 3 fois plus rapide avec HT désactivé....
 
SVP , y a t il des expériences de recoupement ?

je te l'echange contre un non HT 2.4B C1 + SOUS alors ?

l'hyperthreading ça ne peut être rentable que s'il y a au moins 2 tâches ou 2 threads qui ont vraiment besoin du cpu.
s'il n'y a qu'un thread qui a besoin de cpu, les unités de calcul se partagent entre ce thread et un qui ne fait rien-->ça ralentit pour rien.

primo: il y a toujours une dizaine de services qui tournent en permanence sous Windows XP
secundo: tu décris le fonctionnement d'un bi-proc, pas de l'hyperthreading qui est beaucoup plus souple (mais beaucoup moins performant en multi threading) pourvu qu'on ait un OS adapté (WinXP par ex.).

et souvent y'en a un qui bosse (voire zero mais dans ce cas on s'en fout:D) et les autres qui font presque rien et n'occupent pas le cpu.
Là le problème c'est qu'un de ceux qui n'ont pas besoin d'occuper le cpu, va utiliser une des 2 unités d'exécutions du P4HT (pour exécuter une boucle d'attente inutile), en ralentissant l'autre.

non je ne décris pas le fonctionnement d'un bi-proc, mais celui d'un système où un pseudo bi-proc ralentit l'autre.
dans un vrai système bi-proc, quand l'un d'eux exécute une boucle d'attente, ça ne ralentit pas l'autre.
 
En fait le problème de l'HT c'est que, comme avec un bi-proc, on n'a la pleine puissance qu'en utilisant au moins 2 threads de calcul. Mais là, la pleine puissance n'est pas celle d'un bi-proc, ce qui veut dire qu'avec un seul thread on n'a pas la pleine puissance d'un cpu mono-thread.

en tout cas, tu décris pas le comportement de l'hyperthreading vu que les perfs restent les mêmes dans les applis mono thread

http://www.hardware.fr/articles/445/page8.html
 
EDIT: dans un vrai systeme bi proc, quand tu fais du mono thread, le second CPU ne fout rien (ou presque) donc tu gaspille la moitié de ta puissance, donc ça revient au même.

dans tes exemples l'HT ne  fait jamais rien gagner par contre il fait parfois perdre des perfs.
Encore heureux que le ralentissement ne soit pas + important que ça!
 

oui mais au moins il reste la puissance d'un cpu.
Là on arrive à descendre en-dessous.

HT = marketing = le coup du MMX et du SSE...???

Merci mandrak pour tes enrichissantes infos. On peut en déduire que ce proco est clairement destiné aux stations de travail plutôt qu'à des pc de particuliers. A moins que le support sous XP soit amélioré via un SP2 peut être?
 
Moi qui hésitait entre attendre que ce proc baisse sensiblement pour faire un renouvellement et changer tt de suite pour 2.4B (en priant que l'o/c se passe bein)...
 
Chacun tirera les leçons de l'utilité des benchs par rapport à la réalité des tâches courantes que nous demandons à nos machines.
 
Merci encore  

SSE c'est très utile.
MMX un peu moins mais utile quand-même.
HT, c'est différent. C'est très bien dans certains cas, mais pas forcément pour l'utilisateur moyen.
De toutes façons quand on voit que pour le prix on peut prendre un bi-proc AMD...:lol:

 
Une appli qui a rien à faire (en attente d'un évènement), ne risque pas de monopoliser le CPU, puisque l'OS ne la fait pas tourner.

l'OS fonctionne comme avec 2 cpu, c'est à dire qu'il fera toujours tourner 2 threads en même temps. Si l'un est une boucle d'attente, il ralentira moins qu'un thread de calcul (il ne monopolisera pas trop les unités de calcul en virgule flottante par exemple:D) mais il ralentira quand-même le cpu pour RIEN.
S'il n'y a qu'un seul thread qui bosse, y'en aura forcément un autre qui tourne inutilement.

vi m'enfin c'est pas logique ces chutes de perfs.
 
quand tu fais une copie de fichier c'est du transfert DMA entre la RAM et le contrôlleur IDE..
 
quand tu installes un soft, la dépendance CPU est quasiment nulle...
 
quand aux téléchargements sur le net....
 
---
 
c'est pas que je dises que Mandrak dises des bêtises, loin de là, il a certainement bien fait attention à la chose.
 
mais il est probable qu'il y ait un problème -ailleurs- non ?
 
un truc dans sa config qui chie tellement avec l'HT que le système s'écroule en perfs ?
 
sachant qu'à cause (dumoins grâce) de l'HT, les pipelines du P4 sont plus remplis, est-ce que le P4 ne chaufferai pas trop et se metterait en rapport cyclique 1/2 pour se protéger ?
 

Ouaip ! Si je me trompe pas, un CPU ne fout jamais rien ! Au pire, un thread se contente de consommer des ressources avec une boucle, jusqu'à ce qu'un trhead disposant d'une priorité plus élevée vienne consommer à sa place les ressources !

Mandrak => ton Xp pro est-il "patché" ?
 
SP1 min ?
 
étant que des "drivers" pour cpu (sûrement addon au kernel pour tirer parti des extensions propriétaires des cpu) sont sortis pour le P3 et l'athlon depuis le SP1, as-tu été faire un tour sur windows update pour voir si y'a pas des mises à jour de driver cpu pour le P4 ?
 
je pense qu'il faudrait aussi essayer une réinstall avec un CD d'Xp prépatché en SP1.

 
ouep, bon y'a quand même la possibilité de mettre le CPU en économie d'energie lors des timeslices en IDLE (des unités ont leur alimentation de coupée, mais le contexte est quand-même maintenu pour le réveil).

vi passke le noyau d'Xp peut autoriser ou pas l'HT à la volée.
 
d'ailleurs il serait interresant de connaitre le critère de mise en parallèle de deux threads dans les cores logiques du noyau d'Xp car c'est toute la clé du rendement.
 

drapeau

ça je savais pas. Effectivement c'est la solution la + intelligente qu'on puisse imaginer pour gommer les défauts de l'HT. En espérant que c'est mieux fait que beaucoup d'autres 'optimisations' sous windows

enfait l'HT n'est pas désactivé à la volée, mais soit le cpu prends ses instructions du thread du core 0 et du core 1 de manière entrelacée, soit on donne le contrôle complet au core 0 ou au core 1...
 
ce que ne fait pas le noyau Windows 2000 justement..... (et d'oû la perte de perfs avec win2k...)
 

oui donc ça revient à peu près au même que de désactiver l'HT.
comme tu dis, reste à voir comment est fait ce choix.

Salut, g aussi un p4 3.06 Ghz ht, mais dans ce que tu dis, seul un me concerne : unreal 2003 rame au démarage.
Donc je c pas, j'essaierai de désactiver l'ht pour voir si ca marche mieux.

 
démarrage ou chargement ?
 
de toutes façon le démarrage c'est normal, l'os swapes un peu ce qui est inutile (genre les DLLs de Word si tu as laissé le démarrage d'Office dans le menu démarrer...   )

si 2 threads utilisent trop les mêmes unités de calcul, le gain est faible. Si en + les 2 ont besoin de beaucoup de cache, ça peut devenir un handicap de les exécuter en même temps. Les 512Ko de cache ne sont pas toujours de trop pour un P4 sans HT, il suffit de voir la différence de vitesse avec les 0.18µ.

et a fréquence d'oirigine t'as les memes soucis, des fois que ton o/c soit pas super stable et provoque ces plantages

wave >> même unités au même famille d'instruction ? (entier/fpu/mmx/sse)
 
car dans un certains sens si tes deux threads te donnent deux lots d'instructions de la même famille, tu auras beaucoup d'occasions d'avoir du recouvrement de temps et du parallélisme (d'un point de vue OOO).
 

je sais pas exactement. faudrait voir sur aceshardware il me semble qu'ils avaient fait un bon article là-dessus.
Je sais juste que dans certains cas le gain est moins important, et que, combiné avec le fait de devoir partager le cache entre 2 threads, on peut arriver à des cas où la perte de temps devient supérieure au gain.

pour le cache wé, je pense que c'est clair....
 
en fait soit faudrait mettre des infos étendues dans les EXE (HT recommandé pour ce processus ou pas, code compilé pour tel CPU, comme ça si pas P4=>mise du process en core logique), soit que le noyau utilises des heuristiques pour savoir quoi et quand mettre en HT...  
 
enfin c'est bien compliqué tout ça ma bonne dame...

 
c'est à chier
 
2000 ne supporte pas correctement l'hyperthreading  
est-ce qu'il y aura un patch pour corriger ça?
 
que foutent les serveurs xeon HT alors? avec un os micro$oft ils sont censés tourner sous win2k (advanced) server non?

Je crois que le SP3 le fait

 
eh ben, je pensais l'inverse (comme bcp de gens a priori)
 
le HT permet en fait d'exploiter efficacement la nature superscalaire des processeurs

Bonjour,
 
Config = 3.06 + P4pe + Win xp pro
 
Perso, étant un fana de logiciels d'échecs j'ai trouvé un avantage à l'hypertreading car avec des softs supportant le smp (Deep fritz7, Shredder7 etc...) j'ai un gain de 16 % environ. Pour les autres je n'ai pas chercher à quantifier donc je ne peux donner de chiffre.
 
Cordialement.

l'avenir appartient à la programmation multithreadé on dirait, on se dirige vers les CPU à deux cores, gérant chacun l'HT, et vers le Cell de la PS3...
 
 
euh, OOO... au pif (une chance sur 2^24): object-oriented organisation?