Hyperthreading führt Prozessprioritäten ad absurdum
-
nachtfeuer schrieb:
HT ist doch vor allem dazu da, Prozesse besser verzahnt in die Pipline zu schieben und so Verzögerungen zu minimieren.
Der Verbesserungseffekt hängt von der Verzögerung im Betriebssystem ab.
Wenn schon einiges oder alles z.B. Cache optimiert ist, dann brauchts kein HT.
(Und für gute Asmprogramme auch nicht unbedingt)Ne.
Ohne HT bekommt man es auch mit "guten Asmprogrammen" nicht hin sämtliche Teile eines Cores auszulasten. In Spezielfällen mag es gehen, aber da man sich meist nicht aussuchen kann was man programmieren muss sonder nur wie, wird auch der begabteste Assembler Programmierer die allermeisten Programme nicht so hinbekommen dass sie die CPU ohne HT voll auslasten.Ich denke HT ist auch mehr für den Allgemeinbetrieb auf Hochsprachenebene gedacht, und nicht primär als Spezialrechnerei-Tuningtool.
Denk nicht so viel
-
hustbaer schrieb:
p.S.: was den Linux Scheduler oder andere angeht kann ich diesbezüglich nur hoffen dass die auch HT-aware sind, wissen tu ich es aber nicht.
Seit etwa einem Jahrzehnt sowas IIRC. Plus minus ein Jahr. (Erinnere mich dunkel an entsprechende 2.5er-Changelogs und Backports zu 2.4.x.)
Ich finde das Thema ehrlich gesagt nicht spannend genug, um selbst zu suchen, aber etwas ausführlichere Benchmarks als die bis dato geposteten fände ich trotzdem fein, wenn Ihr gerade zufällig was bei der Hand habt.
Ich selbst würde HT nicht abschalten, aber ein echtes CPU-Kaufargument ist es für mich auch nicht. (Da sind die größeren Caches der entsprechenden Intel-CPUs in meinen Augen schon viel interessanter.) Lass mich natürlich gerne eines besseren belehren, sofern irgendjemand gute Benchmarks oder sonstige Daten hat.
-
Shade Of Mine schrieb:
Hyperthreading ist nur für eins gut: die Kerne stärker auszulasten.
Allerdings wirkt sich dies als Steigerung der Prozessorleistung aus.
Shade Of Mine schrieb:
Wenn du den Kern aber schon selber auslasten kannst, dann schadet Hyperthreading nur.
Kannst du das? Nun ich bin wirklich kein Prozessor-Assembler-Kenner, allerdings kenn ich die Motivation, dass im Befehl/Datenstrom Abhängigkeiten existieren, dass den Prozessorscheduler verhindet, den Befehlsstrom durchgängig in die Pipeline zu schieben, aus diesen Grund wurde HT entwickelt.
-
hustbaer schrieb:
Ohne HT bekommt man es auch mit "guten Asmprogrammen" nicht hin sämtliche Teile eines Cores auszulasten. In Spezielfällen mag es gehen, aber da man sich meist nicht aussuchen kann was man programmieren muss sonder nur wie, wird auch der begabteste Assembler Programmierer die allermeisten Programme nicht so hinbekommen dass sie die CPU ohne HT voll auslasten.
Ht ist kein Auslastungsgarant, es bietet Verzögerungsminimierung und bessere Effizienz. Multiprozessing steckt noch nicht mal in den Kinderschuhen, krabbelt auch noch auf allen Vieren. Ich hab noch kein wirklich gutes Multiprozessorprogrammiertool gesehen. Und vor allem hängt die Auslastung der Kerne von der Parallelisierbarkeit des Programms selbst ab und dem Programmierer Know How, das ganze auch umzusetzen.
-
OK das war vielleicht ein wenig misverständlich formuliert.
Ich meinte damit: es ist beim grossteil der Programme noch Potential da, das man mit HT nutzen kann, um den gesamten Throughput zu steigern.
Parallelisierbarkeit vorausgesetzt.Multiprozessing steckt noch nicht mal in den Kinderschuhen, krabbelt auch noch auf allen Vieren. Ich hab noch kein wirklich gutes Multiprozessorprogrammiertool gesehen.
Ich würde mal sagen das ist Definitionssache. Kann man über viele Bereiche sagen. Bei IDEs ist mMn. z.B. auch noch gewaltig viel Raum für Verbesserungen. Trotzdem finde ich z.B. Visual Studio 2010 in Verbindung mit Visual Assist X sehr gut.
Genau so gibt es einige recht brauchbare Techniken/Libs für Parallelprogrammierung.
Und vor allem hängt die Auslastung der Kerne von der Parallelisierbarkeit des Programms selbst ab und dem Programmierer Know How, das ganze auch umzusetzen.
Ja. Aber wo ist das schon anders? Die Qualität von jedem Programm hängt von den Fähigkeiten des Entwicklers ab. Wie sollte es auch anders sein?
----
Mir ging es lediglich darum dass HT (im Allgemeinen) die Performance nicht verschlechtert, so wie Shade es dargestellt hat.
-
Ja, die Gesamtleistung steigt sicherlich, weil beide Prozesse den Prozessor optimal auslasten. Das Problem ist aber trotzdem da, dass Prozesspriorität dadurch nicht mehr richtig funktioniert. Gerade bei prozessorlastigen Programmen will man diese schließlich benutzen. Wenn die Programme ohnehin durch andere Ressourcen beschränkt sind, nützt Prozesspriorität herzlich wenig zur Steuerung.
Jedenfalls stehen so einem Prozess der sonst 99.999% der CPU-Zeit bekäme, nur 50% zur Verfügung. Auch wenn der Gesamtumsatz der CPU dafür um 10% steigt, gleicht sich das doch niemals aus. Die Möglichkeit, HT abzuschalten scheint wohl der einzig gangbare Weg zu sein, wenn man die Prioritäten benutzen möchte. Der Scheduler kann ja gerne wissen, dass einer der Kerne nur virtuell ist - mir fällt jedenfalls keine Möglichkeit ein wie er die Prozessorzeit trotzdem wie gewünscht aufteilen könnte, außer nur auf einem der Kerne zu rechnen.
-
SeppJ schrieb:
Der Scheduler kann ja gerne wissen, dass einer der Kerne nur virtuell ist - mir fällt jedenfalls keine Möglichkeit ein wie er die Prozessorzeit trotzdem wie gewünscht aufteilen könnte, außer nur auf einem der Kerne zu rechnen.
Was gefällt dir an der Lösung, dass in solchen extremsituationen der Scheduler den virtuellen core nichts tun lässt, nicht? Man könnte das auch noch weiter denken. Jedenfalls käme dann am Ende raus, dass das alles gar kein Problem ist, wenn der Scheduler schlaug genug ist.
-
Das Problem ist, wenn ein hoch priorisierter Prozess und ein niedrig priorisierter Prozess sich die CPU Pipeline teilen, bekommen Sie 50-50 Zeitanteile, d.h. im Endeffekt bekommen Sie gleiche Zeitanteile bereitgestellt. Ich habs mit C# auf Win7 getest.
-
Ich gebs auf.
Tut was ihr für richtig haltet, dreht es auf oder ab, ganz wie es euch gefällt.
Ich sehe zwar kein Problem, aber wenn ihr dann besser schlafen könnt ... geht ja um nix.
-
Wie kann hyperthreading Prioritaeten ad absurdum fuehren, wenn es keine Prioritaeten kenn. Diese werden erst durch das Betriebssystem hinzugefuegt.
-
knivil schrieb:
Wie kann hyperthreading Prioritaeten ad absurdum fuehren, wenn es keine Prioritaeten kenn. Diese werden erst durch das Betriebssystem hinzugefuegt.
Und die Betriebssysteme kommen damit nicht zurecht. Wem du jetzt die Schuld gibst, ist mir egal. Fakt ist, es funktioniert nicht wie es soll.
edit: Und eine mögliche Lösung wäre natürlich, wenn der Prozessor selbst Prioritäten kennen würde. Es ist aber einsichtig, dass dies ziemlich viel Entwicklungsarbeit bei den Prozessorentwicklern voraussetzen würde, die ich dann doch lieber bei schnelleren oder billigeren Chips sehen würde. Wie Shade of Mine schon sagte, kann man bei Bedarf die Kerne on the fly deaktivieren und hat dann das Problem für sich gelöst, auch wenn dies die Gesamtleistung um ein paar Prozent senken wird.
