Hyper-Threading in Systemen mit hoher Auslastung

B

bananenBrot

Well-Known Member
Hey
Grundlegend soll Hyper-Threading ja dadurch einen gewissen Performance-Boost versprechen, dass ein CPU Kern mit "mehr Aufgaben" befeuert wird und somit eine höhere Auslastung hat.
Was passiert nun, wenn ich ein System mit 16 Kernen (32 virtuelle) habe und jetzt 32 Threads dauerhaft zu 100% auslaste. Müsste sich da das HT nicht eher negativ auswirken?

Bisher dachte ich, dass ein CPU Kern, der von einem Thread nur zu 50% ausgelastet wird über HT halt in Wirklichkeit 100% Auslastung hat und dadurch der Performancegewinn kommt.

Oder stimmt hier mein Denkansatz nicht?

VG
 
Die Idee hiner Hyper-Threading (oder generischer SMT) ist, dass in modernen superskalaren CPUs kaum jemals alle Einheiten ausgelastet sind. Code ist meist entweder ALU- oder FPU-lastig, aber nicht beides zur gleichen Zeit. Er ist nicht parallelisierbar genug, um alle ALUs auszulasten. Aus verschiedenen Gründen kommt es immer wieder zu Pipeline-Stalls. Und so weiter. Durch recht geringen Aufwand - ein zweites Register File, ein paar Buffer und etwas Magie im Front- und Backend - kann man zwei CPU-States sozusagen griffbereit halten. Wenn ein Thread eine Einheit nicht auslastet, schiebt man dessen State sozusagen raus und den anderen State rein. Dadurch steigt die Auslastung der CPU an und insgesamt wird mehr Arbeit erledigt.

Wie viel das bringt, hängt von der Implementierung und vom Workload ab. Bei der Implementierung bringt Hyper-Threading auf AMDs Zen-Kernen schon recht deutlich mehr, als auf Intels inzwischen bestimmt zehnmal wieder aufgekochten Skylake-Kernen. Beim Workload bringt es umso mehr, je asymetrischer die Threads sind. Hauen beide Threads auf die ALU, ist der Effekt deutlich geringer, als wenn ein Thread ALU-lastig ist und der andere Thread FPU-lastig. Als Beispiel.
 
Außerdem gibt es der CPU Zeit Daten ausm Speicher ran zu schaffen d.h. während ein Hyperthread auf Speicherzugriffe wartet kann der andere weiterlaufen und ggf. Speicherzugriffe anwerfen d.h. es hilft die Speicherlatenz besser zu verstecken. Es kann auch mal Nachteile haben und zwar dann wenn das Working Set eines Threads gut gepasst hätte, aber das von beiden Threads zusammen nicht oder wenn einer der Thread sehr viel wichtiger ist als der andere. Passiert auf neuen Cores selten, aber kann halt noch immer vorkommen. Dafür lässt es sich als Tunable abschalten. Für den Userspace reicht sogar ein cpuset.
 
Kurze Zwischenfrage zum Verständnis;

In der Arbeit nutzen wir die Data Pump von Oracle. Auf einem mäßig dimensionierten System kann so ein impdp eine gute Stunde dauern, währenddessen sehe ich aber nur einen der (vier, meistens acht) Kerne auf 100% arbeiten, der Rest idlet irgendwo bei 2-4% herum.

Warum? Ist Oracle zu faul, impdp SMP-fähig zu machen?
 
guru schrieb:
Kurze Zwischenfrage zum Verständnis;

In der Arbeit nutzen wir die Data Pump von Oracle. Auf einem mäßig dimensionierten System kann so ein impdp eine gute Stunde dauern, währenddessen sehe ich aber nur einen der (vier, meistens acht) Kerne auf 100% arbeiten, der Rest idlet irgendwo bei 2-4% herum.

Warum? Ist Oracle zu faul, impdp SMP-fähig zu machen?
Zum Vergrößern anklicken....
Man kann, abhängig von der installierten Edition, Data Pump auch mit der Option parallel laufen lassen. Der Erfolg hängt aber stark von der Art der Daten ab. Bei einer großen und mehreren kleinen Tabellen macht es sich weniger bemerkbar, hat man dagegen mehrere große Tabellen spart es schon ne Menge Zeit, allein der Aufbau der Indices verkürzt sich damit merklich...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben