HT oder auch SMT - Bitte um Klarstellung

[GTrash81]

Hallo zusammen,

ich lese immer wieder "HT bringt nur 5%" mehr Leistung.
Mir ist klar das HT oder SMT keine Wunder vollbringt, da die "virtuellen Kerne" eigentlich nur eine Technologie zur effizienten Lastverteilung sind.
Ich habe dagegen erlebt, dass bei einer multicorefähigen Anwendung sich die Verarbeitungsgeschwindigkeit mit HT um 90% verbessert hat.
War das nur ein Traum oder missverstehe ich hier was? Bitte daher um Aufklärung/Klarstellung.

 

[Wadenbeisser]

Das kommt immer darauf an wie mies das Programm den Kern belasten kann.
Da HTT/SMT (HT ist AMDs HyperTransport Link) lediglich Auslastungslücken des Kerns auffüllen kann ist praktisch alles drin, selbst ein Leistungsverlußt.

 

[DunklerRabe]

Kein Traum, es kommt halt schwer auf den Workload an.

Wenn du vier physikalische Kerne + HT hast und die physikalischen Kerne mit je einem Thread schon komplett ausgelastet sind, dann bringt HT praktisch nichts. Wenn da hingegen nur Kleinkram unterwegs ist und dann weitere Threads dazu kommen, dann kann HT für eine optimalere Abarbeitung sorgen.

 

[HominiLupus]

HT funktioniert immer dann wenn die Pipeline im "stall" ist, typischerweise wenn man auf Daten aus dem RAM wartet.
Es kann vielleicht sein daß eine bestimmtes Programm so RAM limitiert ist daß 90% Mehrlesitung durch HT erreicht werden, aber das ist dann schon ein sehr schöngerechneter Wert. In der Praxis geht man von maximal 20% bei "embarrassingly parallel" Aufgaben aus. Z.B. Videoencoding skaliert völlig linear aber schafft mit HT nicht mehr als ~20%.

 

[Cat Toaster]

HT ist Hyperthreading und SMT Simultaneous Multithreading? Aber wenn jeder unter den Abkürzungen was anderes versteht sollten wir diese vielleicht nicht mehr verwenden oder erstmal klären.

Wenn eine Aufgabe 100% mit der Kernzahl skalierbar ist, also SMT perfekt unterstützt dann skaliert es mit der Zahl (echter!) Kerne auch nahe 100% mit. So hohe Werte sind mit Hyperthreading nicht machbar, weil eben keine vollwertigen Kerne.

Beispiel: Eine bestimme Szene auf einem nativen 12 Kerner in Blender zu rendern dauert 49 Sekunden, schalte ich Hyperthreading dazu dauert es nur noch 36 Sekunden. Bei echten 24 Kernen wären 25 Sekunden zu erwarten.

 

[Wadenbeisser]

Unterm Strich ist es ganz einfach.
Je ineffizienter der Code den Kern nutzt desto mehr bleibt für HTT übrig.

 

[Cat Toaster]

Komisch, gerade Rendern und Video-Encoding sind also besonders "ineffizient" weil so ideal parallelisierbar? Ergibt das irgendeinen Sinn?

Ineffiziente Software - wenn überhaupt - zeichnet sich vielmehr dadurch aus das sie NICHT mit der Kernzahl skaliert geschweige denn der völlig irrigen Performance von Hyperthreads klarkommt, deren Ergebnisse viel später kommen als von echten Kernen bzw. dann noch daran scheitert echte Kerne von Hyperthreads überhaupt zu unterscheiden und in der Folge ins Stocken gerät.

Viele Aufgaben mit Abhängigkeiten voneinander die sich nicht gleichmäßig aufteilen lassen oder Echtzeitrelevant sind (60fps-Gamer FTW!) lassen sich nur schwer effektiv parallelisieren.

 

[DunklerRabe]

Mit ineffizientem Code hat das nicht so wirklich viel zu tun. Oder überhaupt irgendwas. Ziel ist es nicht schlechten Code auszugleichen. Man versucht damit die Auslastung und damit die Effizienz der CPU zu erhöhen, was ja was völlig anderes ist.
Video Encoding ist daher auch ein schlechtes Beispiel. Das ist gut parallelisierbar und lastet einen Kern oft sowieso komplett aus, daher bringt HT da kaum mehr Leistung.
HT funktioniert am besten, wenn mehr Threads als physikalische Kerne vorhanden sind und jeder Thread nur kleinere Mengen Rechenarbeit produziert. Dann erreicht man eine Art pseudoparallelisierung und das kann dann schneller sein als eine serielle Bearbeitung, ist aber niemals so schnell wie eine echte parallele Bearbeitung mit ausreichend physikalischen Kernen.

 

[Cat Toaster]

Habe ich jetzt nen Schlaganfall oder Du gesoffen? Video-Encoding lässt sich nahezu perfekt parallelisieren. Hyperthreading skaliert da ähnlich ideal wie mit Blender. Zumindest wenn es h264 in UHD crunchen muss.

 

[Wadenbeisser]

Ich schreibe von einer ineffizienten Nutzung des Kerns durch den Code und nicht von einem ineffizienten Code. Beides sind 2 verschiedene Sachen, bewirken aber für HTT das gleiche. Die Lücken in der Pipeline sind so groß das der zweite virtuelle Kern noch bequem rein passt.

 

[Cat Toaster]

Ok, sorry. Doch das muss der Entwickler der Anwendung dann auch mitgegeben haben, also den SMT-Support der zur Not dann auch HT zur Hilfe wenn alle physischen Kerne beschäftigt sind. Wenn er das nicht tut verteilt natürlich auch das OS die Arbeitslast munter aber nicht unbedingt effektiv. So habe ich zumindest die ursprüngliche Frage verstanden. Die Anwendung muss SMT unterstützen und das kann im Idealfall mit der Anzahl der physischen Kerne durchaus perfekt skalieren und wenn die physischen Kerne ausgehen, DANN kann HT noch was bringen.

 

[DunklerRabe]

Na klar lässt sich Encoding gut parallisieren, hab ich ja auch gesagt. Aber das ist für HT ja egal, denn HT macht ja keine Parallelisierung wo andernfalls durch die eingesetze Software keine vorhanden wäre. HT jongliert nur mit Threads mit denen die CPU gefüttert wird und dann auch vorrangig dann, wenn die Software SMT-aware ist oder es mehr Threads als physikalische Kerne gibt. Wenn die physikalischen Kerne aber am Anschlag sind, dann spielt es keine Rolle was man versucht irgendwo zwischen zu schieben. Es gibt dann einfach keine großen Lücken mit freier Rechenzeit, sodass der Mehrwert da sehr überschaubar ist.

Es mag natürlich auch Encoding Jobs geben wo die Kerne nicht komplett am Anschlag sind, dann bringt HT wieder was. Würde ich aber normalerweise eher nicht erwarten. Ich hab noch nie gesehen, dass eine CPU beim Encoding nicht sowieso bei 100% unterwegs ist. Wobei das natürlich nicht bedeuten muss, dass es das nicht gibt, aber ich würde das nicht als normal ansehen und daher nicht als Beispiel nehmen um HT zu erklären.

 

[Wadenbeisser]

@Cat Toaster
Wenn die physischen Kerne ernsthaft beschäftigt sind bleibt für SMT nicht mehr viel übrig denn bei SMT laufen 2 virtuelle Kerne auf einem physischen Kern. Um deftige Leistungseinbrüche bei Teillast zu vermeiden muss das Betriebssystem ohnehin zwischen den virtuellen und den physischen Kernen unterscheiden können.

 

[vander]

Gut funktionierendes HT hat man, wenn zwei Routinen die vorhandenen Recheneinheiten unterschiedlich nutzen, somit kann jede Routine auf den gerade freien Einheiten laufen. Mit effizient vs. ineffizient hat das nicht unbedingt was zu tun.

Zum Beispiel, Routine 1 kopiert einen Speicherbereich, dazu werden kaum Rechenoperationen fällig und viel Zeit wartet die CPU nur, auf die Daten aus dem Speicher.
Routine 2, alle Daten passen in die Register bzw. den internen CPU Cache und es müssen umfangreiche Rechenoperationen angewendet werden.
Dieses Beispiel dürfte stark von HTT profitieren.

Wenn beide Routinen gleiche oder ähnliche Operationen ausführen, wird sich kaum ein positiver Effekt durch HTT einstellen, da die Routinen jeweills warten müssen, bis die andere die Recheneinheiten wieder frei gibt. Dabei kann jede Routine für sich trotzdem super effizient sein.

 

[Cat Toaster]

@Cat Toaster
Wenn die physischen Kerne ernsthaft beschäftigt sind bleibt für SMT nicht mehr viel übrig denn bei SMT laufen 2 virtuelle Kerne auf einem physischen Kern. Um deftige Leistungseinbrüche bei Teillast zu vermeiden muss das Betriebssystem ohnehin zwischen den virtuellen und den physischen Kernen unterscheiden können.

Gut, dann geht die Asche für die Begriffserklärung auf mein Haupt! Ich erkläre die ganze Zeit SMP (Symmetric Multiprocessing) während Hyperthreading die gängigste Ausführung von SMT ist die Du gerade korrekt beschreibst.

Dennoch mein Blenderbeispiel: Ohne HT 100% Last auf zwölf Kernen um eine Szene in 49 Sekunden zu rendern oder mit HT bei 100% Last auf 24 Threads in 36 Sekunden. Die rund 30% Leistungssteigerung sind sicherlich ein Idealfall was Hyperthreading bringen kann aber dennoch nicht zu verachten. Im rechnerischen Endergebnis entspricht das der Leistung von vier physischen Kernen, also ohne den Einsatz von SMT/HT müsste ich statt einem 12-Kerner einen 16-Kerner einsetzen um in derselben Zeit fertig zu werden.

Unabhängig davon wie es das macht (es gibt ja durchaus Beispiele für eine negative Skalierung durch SMT/HT gerade bei einigen Spielen), habe ich noch keine Praxiswerte gesehen die deutlich über das hier beschriebene hinaus gehen. Ich sage in der Regel immer derzeit bei Intel HT ~25% und bei AMDs alter Modulbauweise ~50% was es bringen kann.

Das bringt mich zu folgendem Zitat des Thread-Erstellers:

Ich habe dagegen erlebt, dass bei einer multicorefähigen Anwendung sich die Verarbeitungsgeschwindigkeit mit HT um 90% verbessert hat.

Gibt es zu dem Erlebnis auch Fakten oder war das mehr ein Traum? Oder eine Ausnahme die die Regel bestätigt?

 

[DarkInterceptor]

dann frag ich mich mal warum IBM mit dem Power 9 Prozessor ein 8-faches HTT eingebunden hat wenn doch HTT schlechter ist als echte kerne.
HTT braucht doch auch platz auf dem DIE. daher könnten die doch mehr kerne aber weniger HTT einheiten draufpacken und daher mehr leistung generieren opder bin ich in meiner überlegung falsch?

 

[DunklerRabe]

Weil SMT weniger Platz braucht natürlich und es günstiger ist. Ja, es braucht auch extra Die Fläche für die ganze Logik, aber nur ein paar Prozent von dem was ein komplette Kern brauchen würde. Deine Überlegung ist an und für sich richtig, aber die CPU würde größer und damit teurer werden, mehr Energie benötigen, mehr Abwärme erzeugen und so weiter. Zumindest solange man beim selben Fertigungsprozess bleibt. Daher bringt man mehr Kerne meistens mit Verbesserungen / Verkleinerungen beim Fertigungsprozess und macht dann trotzdem noch SMT.

Außerdem sind Power CPUs ja sowieso nicht mit x86 CPUs vergleichbar, die werden ja ganz anderes eingesetzt.

 

[Cat Toaster]

Genau. Wenn man mit 10% Die-Fläche 25% Mehrleistung durch bessere Auslastung aller Funktionseinheiten (und um nichts anderes geht es bei SMT ja) erreichen kann, dann ist der Weg wirtschaftlicher als die Die-Fläche um 20% zu vergrößern für dasselbe Ergebnis wobei sich dann Teile des Siliziums ungenutzt die Eier schaukeln.

Intel, AMD (noch, bei ZEN wird es HT von Intel geben) und IBM (davon ab das der Power kein x86er ist) legen das allerdings ganz unterschiedlich aus. Das IBM neben einem 12-Kerner mit 8xSMT auch einen 24-Kerner mit "nur" 4xSMT anbietet kann ja bedeuten das irgendwo sogar in deren Welt mehr Kerne wichtiger sind als nur mehr Threads. Und letztlich will IBM damit Intel im Datacenter-Business angreifen (Xeon E7 24C/48T)...in H2 2017...Wie AMD wünsche IBM da viel Erfolg.

 

[Wadenbeisser]

@DarkInterceptor
HTT an sich benötigt durch das fehlen zusätzlicher Recheneinheiten nur einen Bruchteil der Waferfläche eines zusätzlichen Kerns.
IBM mit ihrem 8 fach SMT ist in dem Zusammenhang das denkbar schlechteste Beispiel für Sinnfragen von HTT denn die Prozessoren sind speziallösungen und haben nichts mit den Anforderungen des Massenmarktes zu tuen.
Wie wir ja schon gelernt haben hängt der Nutzen von SMT/HTT extrem davon ab wie der Code die physischen Kerne nutzt.
Hast du beispielsweise einen Code der extrem vom Speicher und den IO Bereich gebrauch macht dann hast du entsprechend viel Leerlauf auf den Recheneinheiten weil sie ständig auf die Zugriffe warten müssen. Hier ist die Skalierung von SMT/HTT natürlich sehr gut, hat aber mit den Anforderungen des Desktop Marktes herzlich wenig zu tuen.

 

[vander]

Gute HTT Nutzung kann man über optimierende Kompiler oder teure Handarbeit erreichen. In jedem Fall würde sich adaptiver Code empfehlen, der je nach CPU Hardware oder sogar Auslastung eine andere Routine durchläuft.
Ansonsten ist das OS für die Threadverteilung zuständig, was in suboptimalen Ergebnissen resultieren dürfte.
In jedem Fall ist das debuggen und die QA von solchen Spezialkonstrukten eine Sisyphusarbeit.