Doping für CPUs — Möglichkeiten der Leistungssteigerung

Ansätze der Optimierung per Hardware (Multi-Threading)

Time-sli­ce Multi-Threading
Das Prin­zip des Time-sli­ce Mul­ti-Thre­a­ding (kurz TSMT) basiert auf der Tat­sa­che, dass Pro­zes­so­ren trotz der zu Beginn genann­ten Fähig­kei­ten recht viel der zur Ver­fü­gung ste­hen­den Rechen­zeit mit Nichts­tun oder War­ten auf Daten ver­brin­gen. TSMT unter­teilt die ver­füg­ba­re Rechen­zeit in fixe Ein­hei­ten auf der Zeit­schei­be und wech­selt nach Ablauf die­ser ein­ge­teil­ten Rechen­zeit von einem Thread zum nächs­ten. Obwohl auch hier­bei vie­le Rechen­ein­hei­ten des Mikro­pro­zes­sors, die theo­re­tisch par­al­lel arbei­ten könn­ten brach lie­gen, wird den­noch der Zeit­ver­lust bei lan­gen War­te­zei­ten, bei­spiels­wei­se einem Cache-Miss inkl. fol­gen­dem Fetch der Daten aus dem Spei­cher, reduziert.

Switch-on-event Mul­ti-Thre­a­ding
Das Switch-on-event Mul­ti-Thre­a­ding (kurz SoEMT) gleicht größ­ten­teils dem TSMT, jedoch mit der klei­nen aber ent­schei­den­den Aus­nah­me, dass die Rechen­zeit nicht fix ein­ge­teilt wird, son­dern ledig­lich bei Auf­tre­ten von län­ge­ren War­te­zei­ten von einem Thread zum nächs­ten gewech­selt wird. Hier­bei muss jedoch der “Haupt­th­read” die höchs­te Prio­ri­tät haben, bei Auf­tre­ten einer län­ge­ren War­te­zeit wird zu Threads mit nied­ri­ge­rer Prio­ri­tät gewech­selt, bis die War­te­zeit für den Pro­zes­sor vor­über ist (als gutes Bei­spiel dient auch hier wie­der ein Cache-Miss mit anschlie­ßen­dem Fetch der Daten aus dem Arbeitsspeicher).
Der Vor­teil gegen­über TSMT ist, dass ein­zel­ne Threads höhe­re Prio­ri­tä­ten haben kön­nen als ande­re und somit der Pro­gramm­fluss gezielt gesteu­ert und opti­miert wer­den kann, wohin­ge­gen beim TSMT immer fes­te Rechen­zei­ten zuge­wie­sen wer­den, nach denen der Pro­zes­sor, unge­ach­tet der Tat­sa­che ob bereits eine Ter­mi­nie­rung des aktu­el­len Threads vor­liegt oder nicht, zum nächs­ten Thread schaltet.

Bei­de Ver­fah­ren haben jedoch den Nach­teil, dass auch hier­für eine im ers­ten Fall dezen­te, im zwei­ten Fall deut­li­che Ände­rung des Pro­gramm­codes not­wen­dig ist. Des­wei­te­ren sind bei­de Ver­fah­ren weit von der opti­ma­len Aus­nut­zung der Res­sour­cen entfernt.