Er hat aber Recht. Er vergleicht 6600K mit 6700. Der eine hat K und kein SMT, der andere hat kein K aber SMT...
DragonTear hat bestimmt gedacht es geht um 6700 vs. 6700K
Okey, war von den ganzen "non-k" anmerkungen überwältigt!
Erstaunt mich aber grad dass die Preisdifferenz trotz der insgesamt deutlich höheren Preise bei Intel im vergleich zu früher, so niedrig ist.
Wenn das im Geldbeutel nicht weh tut, würde ich deshalb ebenfalls nicht auf HT verzichten.
Es tauchen in der Tat ab und an Meldungen von kleinen Nachteilen durch HT in games - da geht es aber maximal um eine handvoll FPS und in Game Benchmarks stellt sich eigentlich auch nie ein Nachteil heraus wie ja schon oben verlinkt wurde.
Weillst du aber nur ein einziges mal in der Lebenszeit des Rechners, mal ein Video rendern, wird sich HT auszahlen
In games "könnte" es sich in zukunft auch zunehmend auszahlen. DX12 hat ja bereits demonstriert dass es die CPUlast deutlich besser auf die Threads verteilen kann (ob die Studios diese Features richtig nutzen bleibt abzuwarten).
@angelsdecay
Soweit ich das eisnchätzen kann, ist deine technsiche Ausführung richtig.
Aber wieso unterschlägst du schlichtweg dass manche Games durchaus jetzt schon von HT profitieren?
Irgendwie sinnlos ist HT nicht. Es bildet einen Mittelweg zwischen einem normalen 4kerner (i5) und einem echten Sechskerner wie die erwähnten CPUs für den Enthusiasten sockel (angenommen man schaltet HT dort ab).
So wie die i3 (zweikerner + HT) den Mittelweg zwischen nem Pentium und nem i5 bilden.
EDIT: Moment -Quatsch!
das heißt das 4 Kern optimierte spiele eine höhere IPC je Kern bekommen
Meinst du damit dass durch HT, die 4kern optimeirten Spiele mehr IPC bekommen? Dann ist das Unsinn.
Dachte du meinst, durch abschalten des HT bekommen 4kern optimierte Spiele etwas mehr IPC, eben weil die CPU nicht diese Zusatz-Kerne mitsimulieren muss.
In vier Sätzen zusammen zu fassen tut HT folgendes:
Zusätzliche Kerne werden simuliert, um die bestehenden, vier echten Kerne besser auszulasten.
Der Grund sind Teile eines Kerns die bei nur einem Thread darauf, zeitweise brach liegen würden, Stichwort: Piepeline-Flush (so hats mein Prof genannt) oder laut Wikipedia:
Pipeline-Hazard
Das OS hat somit 8 physikalische Threads zu verfügung welche alle von den 4 echten Kernen ausgeführt werden.
Die jeweils simulierten Threads sind im Schnit 1/4 eines normalen Kerns wert weswegen das OS darauf achten muss, welcher Software-Thread eines programms grad die meiste Leistung braucht - das tut das OS aber mindestens seit Win 7 inzwischen sehr gut.
Einen einzelnen Softwarethread deines Programms oder Games kann das OS allerdings nicht auf 2 CPU-Threads legen (auch wenn die zum einen echten Kern gehören). Deswegen kommt es in Randsituationen eben zu kleinen Nachteilen.
EDIT 2: Der Compiler hat sicher auch was damit zutun, wobei das meinem groben verständnis nach, ein Compiler eher nicht selbst, gegenseitiges Ausbremsen verhindern kann... das obliegt allein der Logik des Programmierers und stellt auch eine der größten herausforderungen dar (außer natürlich er benutzt eine Art API oder zwischenschicht welche sich halbwegs selbstständig um multithreading kümmert wie Java's Monitor System welches entsprechend auf die CPU angepasst werden kann. Da sind wir aber nicht mehr bei vollkompilierten Sprachen).
