Hyperthreading Leistung Intel CPU

[Piktogramm]

Turbo ist also auch ein Gedankenspiel ohne Basis , HSA ebenso ein Gedankenspiel ohne Basis ? Und deine Intension hatte auch keine Basis !?

Also mich interessiert das eben schon was aus den Ankündigungen geworden ist das die SMT (HT) Leistung von Haswell verbessert wurde .

Was fängst du mit Turbo an, HSA und Co an? Das sind je völlig andere Geschichten. Das ist in etwa als würdest du bei einer Person die kein Spinat mag schlussfolgern, dass diese Person auch keine Schokolade mag -.-

Ansonsten das Wort Intension bedeutet "Eifer, Anspannung" Quelle, keine Ahnung was du ausdrücken willst, versuch es doch mal mit einfacheren Wörtern


Ansonsten, die Funktion von SMT/HT bzw. wie diese Funktionen mit Software skalieren hängt vorrangig von der Software ab. Daher sind pauschale Aussagen schlicht Unsinn. Wie gesagt, man kann Programme soweit optimieren, dass SMT keinerlei Vorteil bringt und genauso kann es Software geben die maximal profitiert. Jedoch sind alle Aussagen zum Skalierungsverhalten immer nur spezifisch zu eben der betrachteten Software möglich. Alles was darüber hinausgeht ist Kaffeesatzleserei.

Was die Verbesserung von Haswell im Bereich von SMT angeht, lässt sich das in der Praxis auch nur schwerlich aufzeigen, da die CPU als solches auch noch weitere Optimierungen erfahren hat, die immer auch das Gesamtergebnis verzerren. Daher sind die Leistungsdifferenzen einzelnen Verbesserunigen kaum zuzuordnen. Unterm Strich bleibt, Haswell kann (fast) alles etwas besser/schneller/energieeffzienter.

 

[Herdware]

Ich denke, man kann generell sagen, dass je "breiter" eine CPU-Architektur ist, je mehr kann sie (entsprechende Software vorausgesetzt) davon profitieren. Bei einer "breiten" CPU liegen bei ungünstigen Lastfällen einfach mehr Einheiten brach.

Die Pentium4, bei denen HT damals erstmals eingeführt wurde, waren vergleichsweise eher "schmale" CPUs, die ihre Leistung nur über hohen Takt erreichten. Bei denen brachte HT noch ziemlich wenig. Der größte Vorteil lag darin, dass man bei Single-Cores überhaupt einen zusätzlichen Thread hatte und somit Multitasking etwas flüssiger funktionierte.

Mit Nehalem, Sandy Bridge und Haswell wurden die CPUs dann wieder immer breiter und mit jeder Generation wurde HT etwas effektiver.

Aber wie schon mehrfach gesagt, der Hauptfaktor ist und bleibt die Software.
Der Idealfall für HT ist Software, die nur Teile der Funktionseinheiten der CPU ausnutzt, aber von zusätzlichen Threads profitiert. Oder halt mehrere solcher Programme parallel.

 

[Piktogramm]

Gerade bei den Netburst CPUs mit ewig langer Pipeline war HT ein recht geschickter Kunstgriff um die ewig lange Pipeline besser auslasten zu können. Wenn ein Thread eine Operation beackern ließ und nicht weiterarbeiten konnte bis das Ergebnis vorlag hat es anno dazumal eben seine +20 Takte gedauert eh die Pipeline durchlaufen war und der Thread mit dem Ergebnis weiterarbeiten konnte. Die Pipleine konnte über HT mit anderen (ok einem anderem) Thread zwischengefüttert werden, was die Nachteile dieser riesen Pipelines schon etwas kompensieren konnte. Nachteil war eher, dass Multithreaded Software zu diesen Zeiten für Consumer noch in den Kinderschuhen steckte und so HT vor allem dazu diente die Hintergrundprozesse zu beackern und so mehr effektive Rechenzeit für den leistungshunrigsten Thread/Prozess übrig zu haben.

 

[Voyager10]

@Piktogramm

Jetzt mal ganz ernsthaft , ich lese gern etwas technisches und möchte das gern näher beleuchten inwieweit die Verbesserungen im Frontend beim Haswell Hyperthreading vorangeschritten sind um sagen zu können SMT schafft theoretisch bis zu 50% und praktisch bei 2 Anwendungen um die 35% , dein "SMT ist Kaffesatz" ist nicht hilfreich.
Entweder du kommst mit ein paar Mess-Werten oder du lässt es , ich habe mir schliesslich auch Mühe gegeben eine Hand voll Messwerte zusammen zu tragen.
Ich gehe auch nicht in deinen Ubuntu Thread und erzähl dort , Ubuntu ist Kaffeesatz , Ubuntu ist ein Gedankenspiel , Ubuntu ist Pfusch , ein Kernel ist nichts zu Essen... das würde dir ebenso wenig gefallen.

 

[Herdware]

Gerade bei den Netburst CPUs mit ewig langer Pipeline war HT ein recht geschickter Kunstgriff um die ewig lange Pipeline besser auslasten zu können. Wenn ein Thread eine Operation beackern ließ und nicht weiterarbeiten konnte bis das Ergebnis vorlag hat es anno dazumal eben seine +20 Takte gedauert eh die Pipeline durchlaufen war und der Thread mit dem Ergebnis weiterarbeiten konnte. Die Pipleine konnte über HT mit anderen (ok einem anderem) Thread zwischengefüttert werden, was die Nachteile dieser riesen Pipelines schon etwas kompensieren konnte.

Das verstehe ich anders. Es ist nicht so, dass da immer nur eine Berechnung zur selben Zeit durchläuft. Die Pipeline wird sowieso immer kontinuierlich mit neuen Aufgaben gefüttert, nicht erst, wenn das Ergebnis der letzten vorliegt.
Zum Problem wird die lange Pipeline des Netbrust-Pentium4 deshalb nur, wenn dieses Ergebnis (und schlimmstenfalls sogar noch ein paar weitere Ergebnisse von darauf basierenden Berechnungen, die noch in der Pipeline stecken) am Ende verworfen werden muss, weil sich die CPU "verspekuliert" hat. Dann muss die Pipeline "geleert" und alles nochmal neu berechnet werden. Das kostet dann gleich haufenweise "Straf-Takte".
HT kann daran wenig ändern.

Ein Beispiel für einen Fall, wo HT was bringt, sieht eher anders aus. Nehmen wir z.B. ein Program, das zwei Threads hat. Der eine Thread besteht fast nur aus Integer-Berechnungen, der andere fast nur aus Floatingpoint. Ohne HT würden die Threads immer abwechselnd nacheinander abgearbeitet, wobei jeweils ein großer Teil der CPU-Ressourcen brach liegt (um so mehr, je "breiter" die CPU aufgebaut ist).
Mit HT werden beide Threads parallel abgearbeitet und die CPU nahezu komplett ausgelastet. (Vorausgesetzt sie hat zufällig genau den Mix aus Integer- und FP-Einheiten, den diese 2-Thread-Anwendung braucht.)

Ich kann mit dieser Auffassung natürlich auch komplett daneben liegen. Ich bin letztlich nur ein Laie, in Sachen CPU-Architektur.

 

[Piktogramm]

@Voyager10: Ich habe nicht geschrieben, dass SMT Kaffeesatzleserei ist sondern deine "Messwerte" bzw. Betrachtungen. Dazu habe ich begründet geschrieben, dass jeder Messwert nur für diesen einen Fall Aussagekraft hat und keine allgemeingültige Aussagen zulässt + Begründung.
Nochmal die Begründung in Kurz: SMT ist eine CPU Funktion, deren Nutzen in erster Linie von der Software abhängt, daher sind Betrachtungen der Hardwareebene ohne fundiertes Wissen zur Software nicht zweckmäßig. Alles was man ohne diese Betrachtungen "misst" läuft unter dem Motto "wer viel misst, misst Mist"

Daher ich kann dir kaum irgendwelche Werte presentieren, da der Aufwand für eine belastbare Aussage einfach enorm ist. (Quelltext vom Programm analysieren, mit div. Compiler flags compilieren, testen, auswerten, Aufwand von Tagen bis Wochen nur für eine Aussage die nahezu ausschließlich auf dieses eine Programm zutrifft, ist also Unsinn).

@Herdware: DU verstehst es anders, es ist aber trotzdem nicht so wie du es verstehst
https://de.wikipedia.org/wiki/Hyper-Threading (in Englisch ist der Artikel besser)

Wenn Ein Prozess/Thread oder wie man es nennen will einer CPU zugewiesen wird, dann besetzt dieser Prozess die Pipeline für den zugeteilten Zeitraum*. Daher wenn Zwischenergebnisse oder Daten aus dem RAM fehlen läuft die Pipeline vollständig oder teilweise leer, arbeitet aber mit dem Arbeitstakt weiter. Verpulvert also sinnlos elektrische Leistung und die theoretische Leistung wird real nicht annähernd erreicht. Mit HT/SMT kann die Pipeline mit anderen Threads gefüttert werden.
Was den Flush der Pipeline angeht, da muss ich zugeben, dass mein Wissen etwas dünn wird. Jedoch könnte ich mir vorstellen, dass bei einer intelligenten Umsetzung SMT dafür sorgt, zwar die Ergebnisse von Thread1 verworfen werden, jedoch Ergebnisse von Thread2 weiterhin als valid behandelt werden können. Selbst wenn dem nicht so ist, und wirklich die gesamte Pipeline mit Operationen aus Thread1 und Thread2 plattgemacht werden würde, so wäre SMT/HT immer noch für eine gescheite Leistungssteigerung möglich, da ein Flush ja nur bei falscher Sprungvorhersage erfolgt.
Was nicht klappt (zumindest nicht bei mir bekannten Intel CPUs, bei AMD bin ich nicht firm), ist gleichzeitig 2 Operationen getrennter Threads auf einer Pipe laufen zu lassen. Das würde schlicht enorme Probleme beim Ansprechen/Trennen dieser Operationen führen. Daher baut SMT nachwievor auf eine zeitdiskrete Zuordnung auf.

*Je nach sheduling, NEIN ich mach nicht alle Beispiele, wird arg viel.

 

[jan4321]

@jan4321
Bei welchen Anwendungen ist eine CPU mit HT langsamer?
Wie kommst Du darauf, das HT nicht mehr als 10% bringt? Irgendwelche Links oder Bauchgefühl?

pauschal kann man das natürlich genau nie sagen, aber um mal bei Aktuellen CPUs zu bleiben, müssen die Programmierer bei einer 6 Core CPU mit HT der CPU auch genug zum tun geben für 12 Thrads, sonst bringt dir HT rein gar nichts.

Für näheres zur Technik kann ich dir http://de.wikipedia.org/wiki/Hyper-Threading#Software Empfehlen, hier ist auch die Problematik von HT genau beschrieben.