Problemer med hyper-threading

Bundkort / CPU d.  24. november. 2005, skrevet af espeholt_jr
Vist: 480 gange.

espeholt_jr
 
Elitebruger
Tilføjet:
24-11-2005 23:37:38
Svar/Indlæg:
2175/186
Godtnok en 2 dage gammel nyhed, men tror ikke den har været her...

http://www.computerworld.dk/ar...

Dermed ikke sagt den ikke giver lidt i andre ting....

Lars
 
Superbruger
Tilføjet:
24-11-2005 23:40:23
Svar/Indlæg:
1633/76
Okay, så det er skidt i server sammenhænge, men for resten af os er det vil fint nok?



espeholt_jr
 
Elitebruger
Tilføjet:
24-11-2005 23:46:23
Svar/Indlæg:
2175/186
er jo så det... men i flere spil test viser det lige at give et par frames eller 2 ekstra... men sikkert nogle steder hvor det ikke er godt så..



Salkcin
 
Elitebruger
Tilføjet:
25-11-2005 00:17:45
Svar/Indlæg:
1713/31
Jeg er overbevist om det giver bedre ydelse.

Disabler de hyper-threading vil hver CPU kun håndtere én forespørgsel ad gangen (måske lidt hurtigere end med enabled), men enabler de Hyper-threading vil hver CPU håndtere 2 forespørgsler ad gangen - det kan godt være at forespørgslen der bliver udført af den logiske CPU (den som Hyper-threading giver) har længere svartid end normalt, men antal forespørgsler der bliver behandlet per minut vil være flere med Hyper-threading pga. det ikke tager dobbelt så lang tid at processere en forespørgsel med hyper-threading enabled som med det disabled.
Om det så er brugbart nogen får længere svartider under nogen omstændinger kan man diskutere.

Det største problem ved Hyper-threading er nok når flere brugere får behandlet deres applikationer i den samme CPU/kerne som f.eks. ved terminal servere. Hvis 2 personer får afviklet deres applikationer i samme kerne (fordi der er en logisk CPU) bliver dataerne processeret parellelt og man kan derfor <B>potentielt</B> se hvad den anden bruger får processeret. Det kunne f.eks. være en nøgle til netbank. Det kan dog kun aflæses i de mikrosekund nøglen bliver processeret.
Dette sikkerhedshul er dog kun <B>TEOREKTISK</B> og man skal også være lidt sej for at lave en applikation der kan aflæse de ting på så lavt et hardware niveau.



Myth
 
Elitebruger
Tilføjet:
25-11-2005 10:55:00
Svar/Indlæg:
675/55
#3

Du glemmer at i dit første eksempel vil de to cpuer som ht giver jo så skulle slås om cache, bandwith m.v. og det er der problemet menes at opstå hvis der er MEGET træk på begge logiske kerner med forskellige forespørgsler eller givet vis også med 2 forskellige programmer der trækker 100%..



Sajmon
 
Elitebruger
Tilføjet:
25-11-2005 11:08:35
Svar/Indlæg:
6624/113
Et godt eksempel vil være at starte Folding@Home 2 gange på en HT maskine og en X2'er f.eks.

HT maskinen vil stadig være responsiv med 100% load på begge tråde.
X2 lægger man fuldstændig ned på den måde - og Folding er ikke engang hårdt at køre for en AMD.
Det giver faktisk højere temperaturer ved load på en Intel, end f.eks toast gør - som mange jo sværger til.

Starter man 2 x toast, er X2'eren stadig lige så presset - hvor HT maskinen vil være mindre ramt af det.

Det skal så siges at de to programmer kun er samme systemkald hele tiden, så komplexiteten i det er ikke så høj - men derfor skulle det netop være nemmere at se forskellen på en HT og Dual Core.

Snakker man server opgaver, er historien jo en HELT anden - og som jeg også har skrevet her, er der jo en logisk grund til det : http://www.hardware-test.dk/oc...