Windows: die Probleme mit Hyperthreading und Bulldozer

Wer eine Intel-CPU mit Hyperthreading einsetzt, sollte schleunigst auf Windows 7 upgraden, denn ältere Versionen des Microsoft-Betriebssystems bis einschließlich Vista können mit Hyperthreading gar nicht richtig umgehen. Wer eine brandneue Bulldozer-CPU von AMD hat, kann sich ganz sicher sein: Es gibt überhaupt keine Windows-Version, die diese CPUs richtig bedient.

Für Bulldozer-CPU gibt es jetzt immerhin einen Patch. Der ist aber so experimentell, dass man beim Support von Microsoft nachfragen muss, um ihn zu bekommen.

Das Problem ist, dass Windows bis einschließlich Vista alle logischen CPUs, die dem Betriebssystem vorgegaukelt werden, gleich behandelt, was nicht immer richtig ist. Angenommen eine Single-Threaded-App lastet eine logische CPU komplett aus. Startet man eine zweite Single-Threaded-App teilt Vista dieser eine zweite logische CPU zu.

Läuft die erste App auf CPU 0 und die zweite auf CPU 1, dann hat die Hyperthreading-Falle zugeschlagen. Bei einem Prozessor mit Hyperthreading sind die logischen CPU 0 und 1 nämlich auf demselben Core. Das Betriebssystem müsste die beiden Apps auf die logischen CPUs 0 und 2 legen, damit sie auf getrennten Cores und damit schneller laufen.

Das hat Microsoft mit Windows 7 dann auch verstanden und das Scheduling entsprechend angepasst. Bei Bulldozer-CPUs ist aber wieder alles anders: Laufen zwei Threads auf den CPUs 0 und 2, dann werden zwei Bulldozer-Module benutzt, die keinen gemeinsamen Level-2-Cache besitzen. Liefen sie auf den logischen CPUs 0 und 1, könnten sie schneller auf den gemeinsamen L2-Cache zugreifen. Außerdem kann im Turbo-Modus höher getaktet werden, da nur ein Bulldozer-Modul beansprucht wird.

Allerdings gilt das nur, wenn keine Floating-Point-Befehle im Code enthalten sind. Bei Bulldozer-CPUs teilen sich die beiden Integer-Cores eines Bulldozer-Moduls eine gemeinsame FPU. Bei Anwendungen mit vielen Floating-Point-Befehlen sollten lieber getrennte Bulldozer-Module genutzt werden, etwa die logischen CPUs 0 und 2.

Insofern dürfte der jetzt verfügbare Patch nur bedingt helfen, denn der Kernel weiß ja gar nicht, ob und wie viele Floating-Point-Befehle im Code enthalten sind. Dieses Problem kann Microsoft auf die Schnelle nicht lösen. Denkbar wäre, dass Entwickler Threads künftig kennzeichnen können, ob sie viele Floating-Point-Operationen ausführen oder nicht. Diese Information könnte der Scheduler nutzen.

Im Endeffekt kann man kann es aber drehen und wenden wie man will: Dass die Art der verwendeten Befehle einer Anwendung Einfluss darauf hat, wie man Prozesse und Threads am besten auf die logischen CPUs verteilt, ist keine wirklich gute Situation. Vielleicht hat ja AMD ein Einsehen und spendiert in Zukunft wieder jedem Kern eine FPU.