hyper-threading / Sinnvoller Zusatz oder Blendwerk?

Das ist doch wieder ein Sturm im Wasserglas. Skylake startete Anfang August 2015, ich war damals mutig und einer der ersten Kunden. Seitdem hat Intel sicher Millionen CPUs auf Skylake- und auf Kaby Lake Basis ausgeliefert. Nun, nach fast 2 Jahren, dringt das Problem an die Öffentlichkeit. Es muss also sehr, sehr selten auftreten. Deshalb nun gleich loszurennen, Hyperthreading abzuschalten und das System damit zu verkrüppeln ist für 99,9% der Anwender weit über der Grenze des Sinnvollen. Gerade, da ein absoluter Großteil der Skylake-Systeme ohne ECC-RAM läuft und dort ein einziges, verirrtes Alpha- oder Beta-Teilchen ausreicht, um die Systemstabilität zu gefährden. Also: Einmal tief durchatmen, Microcode-Updates einrichten und sich zurücklehnen. Die Microcode-Updates sollte man sowieso konfiguriert haben, um nicht von der Gnade der meist unwilligen Mainboard-Hersteller abhängig zu sein.
 
Wie viel SMT (Hyperthreading) bringt hängt nicht vom Betriebssystem ab, stattdessen vom Workload. Alle gängigen Betriebssysteme versuchen erst einmal die physischen Kerne zu belegen. SMT kommt also erst ins Spiel wenn mehr Prozesse nenneswert CPU-Leistung einfordern, als die CPU physische Kerne hat. Dann verteilt sich die Leistung des Kerns auf beide Hardware-Threads. Angenommen ein Kern ist mit einem Prozess zu 100% ausgelastet und der Scheduler legt einen weiteren Prozess, der den Kern ebenfalls zu 100% auslastet, auf den zweiten Hardware-Thread. Nun teilen sich beide Prozesse die zur Verfügung stehende Leistung, bekommen als jeder 50%. In diesem Szenario ist also nichts gewonnen.

Der Trick liegt nun darin, dass ein CPU-Kern niemals zu 100% ausgelastet ist. Der meiste real existierende Code bewegt sich zu einem Zeitpunkt lediglich auf einer Funktionseinheit. Er nutzt z.B. hauptsächlich die ALU, die FPU wird aber kaum genutzt. Auch innerhalb einer Funktionseinheit kommt es immer wieder zu Leerläufen, beispielsweise da Daten aus dem Cache oder sogar RAM nachgeladen werden müssen oder durch Abhängigkeiten zwischen einzelnen Instruktionen. SMT erlaubt es diese sonst brach liegenden Ressourcen zu nutzen. Nutzen beide Prozesse die gleiche Funktionseinheit ist der Gewinn gering, beide Prozesse bringen zusammen vielleicht 10% oder wenn es hoch kommt 20% Mehrleistung gegenüber nur einem Prozess. Wenn sie aber unterschiedliche Funktionseinheiten nutzen, kann man Bereiche von 40% bis sogar 60% Mehrleistung bringen.

Ein weiterer Faktor ist die Mikroarchitektur. Meiner eigenen, vielleicht nicht unbedingt wissenschaftlichen Erfahrung nach bringt SMT bei Skylake unabhängig des Workload deutlich mehr als noch bei Sandy Bridge. AMDs Zen Architektur ist diversen Berichten zu folge noch etwas breiter angelegt, wodurch SMT überdurchschnittlich profitiert. Das kann zu bis zu 80% Mehrleistung führen.
 
Intel hat am 7.7.2017 ein neues Microcode-Paket veröffentlicht. Es aktualisiert den Microcode auf meinem Dell XPS 13 mit Kably Lake CPU auf Version 0x62. Anschließend kann ich den Bug nicht mehr reproduzieren. 100% sicher, dass er wirklich behoben ist, kann ich natürlich nicht sein, aber es sieht schon sehr danach aus. Außerdem würde ich davon ausgehen, dass das Paket auch neuen Microcode für die bisher noch nicht reparierten Skylakes enthält, aber auch das ist nur eine Vermutung. FreeBSDs sysutils/devcpu-data Port ist allerdings noch nicht aktualisiert.
 
Zurück
Oben