Bei den Spitzenmodellen ihrer CPUs lassen sich die Prozessorhersteller jedes Megahertz kräftig bezahlen. Beim Pentium 4 kosten beispielsweise die 20 Prozent mehr an Taktfrequenz beim Sprung von derzeit 1,4 auf 1,7 GHz 80 Prozent Aufpreis (Stand Mai 2001). Der Xeon mit 2 MByte Cache kostet mit 30 Prozent höherem Takt fast 90 Prozent mehr.
Dieses ungünstige Preis/Leistungsverhältnis lässt sich scheinbar mit einem Mehrprozessor-System umgehen. Für suggerierte 100 Prozent Mehrleistung ist rund das Doppelte zu bezahlen. Doch diese Rechnung geht meist nicht auf. Die erforderlichen Chipsätze und Mainboards für Multiprocessing (MP) sind komplexer und werden nur in kleinen Stückzahlen gefertigt. Dadurch steigt der Systempreis deutlich.
Wer ein Mehrprozessor-System ins Auge fasst muss zudem wissen, dass viele Anwendungen unter einer solchen Umgebung gar nicht schneller laufen - ja teilweise sogar langsamer werden. Dieser Beitrag zeigt, wovon der Leistungsgewinn abhängt und für wen sich ein Multiprozessor-System lohnt. In einem weiteren Artikel mit zahlreichen Benchmark-Ergebnissen lesen Sie, wie stark welche Anwendung in praxi von einer Dualprozessor-Workstation profitiert.
SMP, Multitasking & Multithreading
SMP-Computer arbeiten mit mehreren gleichwertigen Prozessoren. Jede CPU besitzt den vollen Zugriff auf die Ressourcen des Systems wie Arbeitsspeicher, Grafikkarte, Controller und sonstige Peripherie. Zusätzlich verfügen SMP-Systeme über Mechanismen, um exklusive Ressourcen zu synchronisieren. Hierzu zählen beispielsweise die Inhalte der in den einzelnen Prozessoren integrierten Caches.
Das Betriebssystem muss die SMP-Unterstützung des Systems erkennen und entsprechend nutzen können. Unter anderem ist dafür Multitasking oder Multithreading erforderlich. Multitasking ist die Fähigkeit eines Betriebssystems, verschiedene unabhängige Applikationen parallel laufen zu lassen. Beim Multithreading ist eine Anwendung so ausgelegt, dass mehrere CPUs sie parallel abarbeiten können. Beispielsweise kann ein Thread Daten für den Ausdruck aufbereiten, während ein anderer den Benutzer im Vordergrund weiterarbeiten lässt.
Alle Tasks oder Threads teilen sich die Ressourcen des Rechners. Das Betriebssystem teilt ihnen dazu feste Rechenzeiten (Zeitscheiben) des Prozessors zu, die dieser fortlaufend abarbeitet. Dadurch entsteht auch bei Systemen mit nur einem Prozessor der Eindruck, dass verschiedene Anwendungen parallel laufen.
Bei Multiprozessor-Systemen kann das Betriebssystem die Tasks oder Threads auf die installierten CPUs aufteilen. Ist ein Programm multithreaded geschrieben, laufen Teile der Anwendung tatsächlich parallel ab, die Ausführungsgeschwindigkeit steigt.
Die Multithread-Programmierung gestaltet sich durch die zeitliche Ablaufsteuerung und Synchronisierung der Threads jedoch reichlich kompliziert. Auch lässt sich nicht jede Anwendung oder Teilaufgabe in mehrere parallel ausführbare Einheiten splitten. Zudem ist das Debugging problematisch, da die Laufzeiten der einzelnen Threads je nach System unterschiedlich sein können. Die meiste Software ist deshalb singlethreaded programmiert.
Performance-Fallen
Zwei Prozessoren bedeuten auch bei einer Mutithreaded-Applikation nicht, dass die Anwendung mit doppelter Geschwindigkeit läuft. Ein 1967 von Gene Amdahl aufgestelltes Gesetz beschreibt, wie der Performancegewinn einer Anwendung bei Verwendung mehrerer Prozessoren durch Threads eingeschränkt ist, die nicht parallelisiert werden können. Laut Amdahl skaliert eine Multithreaded-Anwendung nie linear mit der Anzahl der Prozessoren. Weitere Performance-Einbußen entstehen durch beschränkte Systemressourcen, wie der zur Verfügung stehenden Bandbreite des bei SMP-Systemen gemeinsam benutzen Arbeitsspeichers.
Programme, bei denen der Aufwand für die Synchronisierung von Threads und Daten höher ist als der Zeitgewinn durch parallele Abarbeitung, sind für Multithreading nicht geeignet. Sie würden in jedem Fall langsamer ablaufen als eine Singlethreaded-Variante - selbst bei mehreren CPUs. Besonders einfach und effektiv ist Multithreading hingegen, wenn sich große Datenmengen in unabhängige Segmente aufteilen lassen. Ein Beispiel ist die Bildbearbeitung mit aufwendigen Filtern: Das Bild wird in mehrere Regionen aufgeteilt, jeder Prozessor bearbeitet eine eigene Bildregion. Ähnlich verhält es sich bei zahlreichen wissenschaftlichen Anwendungen und Programmen für Ingenieure (Statik, Feldberechnungen, Strömungsmechanik etc.), die nach der Methode der finiten Elemente arbeiten. Dabei werden den Prozessoren jeweils bestimmte Bereiche eines zu berechnenden Netzes zugewiesen. Nach Abschluss der Einzelberechnungen werden die Teilergebnisse gemäß den festgelegten Randbedingen zusammengefasst.
In der Theorie müssten aber auch Singlethreaded-Anwendungen in einem Multiprozessorsystem schneller sein: Das Betriebssystem weist der Applikation eine CPU zu, während die zweite CPU den Betriebssystem-Overhead verarbeitet. Beobachtet man im Systemmonitor die Auslastung beider Prozessoren, so bestätigt sich diese Aufteilung.
Überprüft man aber die Performance einer Singlethreaded-Anwendung, so ist sie in einem Mulitprozessor-System meist niedriger als in einem Uniprozessor-PC. Gleiches gilt für Benchmark-Ergebnisse, wie sie beispielsweise die BAPCO-Suite mit ihren zahlreichen Singlethreaded-Anwendungen liefert. Die Erklärung: Beide Prozessoren stehen in ständiger Kommunikation und gleichen beispielsweise laufend ihre Cache-Inhalte ab. Dieser Overhead für die Synchronisierung bremst die jeweilige Anwendung.
Cache-Konsistenz durch MESI
Alle Prozessoren eines SMP-Systems besitzen Zugriff auf den gemeinsamen Arbeitsspeicher. Mit exklusiven Ressourcen wie den lokalen Prozessor-Caches kann es dabei zu Problemen kommen: Befinden sich die Daten eines bestimmten Speicherbereiches im Cache von Prozessor 0, greift dieser bei einem erneutem Zugriff auf diese Daten in seinen schnellen Cache zurück. Hier kann es aber zu Inkonsistenzen kommen, wenn Prozessor 1 zwischenzeitlich den entsprechenden Speicherbereich mit neuen Daten überschrieben hat.
SMP-Systeme verfügen deshalb über ein Cache-Kohärenz-Protokoll: Es gewährleistet, dass die Daten im Arbeitsspeicher und den Caches der Prozessoren immer konsistent sind. Ein für Multiprozessor-Systeme weit verbreitetes Protokoll ist MESI (Modified, Exclusive, Shared und Invalid). Jede Cache-Line befindet sich durch das MESI-Protokoll in einem der vier Zustände:
Modified: Die Cache-Line findet sich nur in einem Prozessor und enthält modifizierte Daten. Der Inhalt stimmt nicht mehr mit dem Arbeitsspeicher überein.
Exclusive: Die Cache-Line ist nur in einem Prozessor gespeichert. Die Daten sind aber nicht verändert und stimmen mit dem entsprechenden Bereich im Arbeitsspeicher überein.
Shared: Eine Cache-Line ist in mehreren Prozessoren vorhanden. Schreibbefehle erfolgen jetzt über ein write-through in den Arbeitsspeicher. Bei diesem Vorgang werden die Cache-Lines der übrigen Prozessoren ungültig.
Invalid: Der Inhalt der Cache-Line ist ungültig. Ein Lesezugriff auf eine Cache-Line mit Invalid-Status erzeugt einen Cache Miss. Der Prozessor holt darauf die Daten aus dem Arbeitsspeicher.
Schneller durch MOESI
Zu einer erweiterten Variante des Cache-Kohärenz-Protokolls MESI zählt das noch nicht weit verbreitete MOESI-Protokoll. Neben den vier Cache-Line-Zuständen Modified, Exclusive, Shared und Invalid wurde für MOESI der Owner-Status hinzugefügt.
Besitzt die Cache-Line eines Prozessors den Owner-Status, so können die anderen CPUs auf die Daten der Owner-CPU zugreifen und müssen sie nicht aus dem Arbeitsspeicher holen. Dieses Cache-Handling sorgt für weniger Speicherzugriffe und somit für eine Steigerung der Systemperformance. Zu MOESI-basierenden Multiprozessor-Chipsätzen zählt beispielsweise AMDs 760MP, der Mitte 2001 erscheinen soll.
Die Funktion des Cache-Sharings basiert auf folgendem Prinzip: Prozessor 0 ist Owner einer Cache-Line. Erfolgt ein Lesezugriff von Prozessor 1 auf diesen Speicherbereich, leitet beispielsweise der 760MP-Chipsatz die Anfrage direkt an den schnellen Cache von Prozessor 0 weiter. Ein Zugriff auf den langsamen Hauptspeicher bleibt aus. Damit sinkt nicht nur die Antwortzeit für den Lesezugriff, gleichzeitig ist der Speicherbus entlastet und für andere Zugriffe frei.
Interrupt-Steuerung via APIC
Die Steuerung von Interrupts in einem SMP-System geschieht über sogenannte APICs (Advanced Programmable Interrupt Controller). Sie gehören neben den CPUs zu den Hauptbestandteilen einer Multiprozessor-Plattform. APICs sorgen dabei für eine dynamische Verteilung von Interrupts auf die Einzelprozessoren. So wird eine ausgeglichene Interrupt-Verteilung im System erreicht.
In einem SMP-System gibt es zwei APIC-Typen. Zum einen die lokalen APICs, die in den jeweiligen CPUs integriert sind und zum anderen die so genannten I/O-APICs. Letztere kümmern sich um die externen Interrupts von Peripheriebausteinen. Sie befinden sich in der Regel in einem SMP-fähigen Chipsatz oder einem extra Baustein. Die lokalen APICs leiten unter anderem Interprozessor-Interrupts weiter, beispielsweise wenn ein Prozessor einen Interrupt an einen anderen sendet. Dies ist beispielsweise für Steuersignale von Vorteil.
Die APICs kommunizieren untereinander über den so genannten ICC-Bus (Interrupt Controller Communication) und teilen darüber die anstehende Controller-Funktionen auf. Da alle Interrupt-Botschaften über den ICC-Bus laufen wird der Speicherbus nicht zusätzlich belastet. Auch kann ein Prozessor über diese Verbindung seine Interrupt-Abarbeitung mit einer anderen CPU teilen, was zu einer gleichmäßigen Lastverteilung führt.
SMP-Betriebssysteme
Damit die Multiprozessor-Hardware zur Geltung kommen kann, muss das Betriebssystem entsprechend SMP unterstützen. Gleiches gilt für die Anwendungen: Programme, die singlethreaded programmiert sind, laufen unter einer Multiprozessorumgebung nicht schneller.
Ausnahmen sind Systeme, auf dem mehrere CPU-intensive Programme gleichzeitig laufen. Arbeiten auf einem Rechner Webserver, Datenbank, Remote-Access-Zugang und gleichzeitig noch File- und Printjobs profitieren auch Singlethreaded-Anwendungen von zusätzlichen CPUs. Denn ein MP-fähiges Betriebssystem verteilt die Anwendungen auf die verschiedenen CPUs. Ein Blick in die Statistik der CPU-Auslastung schafft hier Klarheit. Belegen mehrere Programme gleichzeitig den Prozessor mit nennenswerter Last lohnt sich ein MP-System auf jeden Fall.
Zu beachten ist, dass es für nahezu jedes Betriebssystem verschiedene SMP-Versionen beziehungsweise Kernels gibt, die sich nach der Anzahl der installierten CPUs richten. So unterstützt Windows 2000 Professional von Haus aus maximal 2 CPUs. Die Servervarianten können je nach Hardware mit bis zu 32 Prozessoren (Windows 2000 Server Datacenter) umgehen. QNX und BeOS bieten Support bis acht Prozessoren. Die folgende Tabelle zeigt einen Auszug x86-kompatibler Betriebssysteme mit SMP-Unterstützung.
Betriebssystem | Hersteller |
|---|---|
| |
BeOS | |
Darwin für Intel | |
Linux * | |
OS/2 Warp | |
QNX | |
Windows 2000 | |
Windows NT |
* Linux-Distributionen verfügen erst ab der Kernel-Version 2.4 über einen vollständigen SMP-Support. Eingeschränkt SMP-fähig ist der Linux-Kernel bereits ab der Version 2.0.x.
SMP-Anwendungen
Im Server- und Backoffice-Umfeld sind SMP-Anwendungen die Regel. Alle professionellen Web-, SQL- oder Groupware-Server sind multithreaded konzipiert und profitieren somit von SMP-Systemen.
Bei Workstation- und Desktop-Programmen zeigt sich ein anderes Bild. Die Programmierung von SMP-fähigen Anwendungen ist komplex, fehleranfällig und damit teurer. Programme, die Multiprocessing unterstützen, sind somit hauptsächlich im professionellen Umfeld zu finden. Gängige Software findet sich vor allem in den Bereichen Digital Content Creation, CAD und Simulationen, sowie unter wissenschaftlichen Anwendungen, die nach der Methode der finiten Elemente arbeiten.
In der Tabelle finden Sie einen Auszug professioneller MP-fähiger Desktop-Anwendungen:
Programm | Kategorie | Hersteller |
|---|---|---|
| ||
MoviePack | Videoschnitt / -bearbeitung | |
Maya | Videobearbeitung, Spieleentwicklung, 3D-Animation | |
Photoshop 6.0 | Bildbearbeitung | |
Premiere 6.0 | Videoschnitt / -bearbeitung | |
3D Studio MAX 4 | 3D-Konstruktion, Rendering, Animation | |
Parallel Performance for ANSYS | Addon für diverse ANSYS-Produkte | |
Windows Media Encoder 7 | Sound- und Videokonvertierung | |
LightWorks 5.6 | 3D-Rendering | |
Parasolid 12.1 | 3D-Modeling | |
Mental Ray 2.1 | Raytracing und Rendering | |
VMware 2.0.3 | Betriebssystem-Tool, das virtuelle PCs auf einem Host-System erzeugt |
Auch gibt es einige Spiele, die Multiprocessing unterstützen. Doch die Zahl der Titel ist sehr begrenzt:
Programm | Hersteller |
|---|---|
| |
Quake III Arena | |
Falcon 4.0 | |
Starsiege |
Zusätzlich unterstützen alle auf der Quake-III-Engine basierenden 3D-Spiele SMP.
Windows und SMP
Windows 95/98 sowie Windows ME bieten keinen Support für Multiprozessor-Lösungen. Windows NT 4 und Windows 2000 verwenden für Uni- und Multiprozessor-Umgebungen verschiedene Betriebssystem-Kernel. Bei Windows NT 4 zeichnen sich hierzu nur die im System32-Verzeichnis befindlichen Dateien hal.dll und ntoskrnl.exe verantwortlich. Bei der Installation kopiert Windows NT je nach erkanntem System die entsprechenden Varianten.
Bei Windows 2000 existieren zahlreiche Hal- und Ntoskrnl-Versionen. Beispielsweise sind von den Uni- und Multiprozessor-Varianten je eine ACPI-fähige und eine Standardversion vorhanden. Zudem tauscht die Installation noch weitere Systemdateien je nach CPU-Anzahl aus.
Die Installation des Multiprozessor-Kernels ist auch auf Uniprozessor-Systemen möglich. In diesem Fall sinkt die Performance um einige Prozent. Verantwortlich hierfür ist der aufwendige Kernel, der auch auf einem Uniprozessor-System mit einem beachtlichen Overhead beschäftigt ist.
Fazit
CPUs im Doppelpack sind bei passenden Anwendungen ein geeignetes Mittel zur Leistungssteigerung. Im Serverbereich sind mittlerweile zahlreiche MP-fähige Anwendungen erhältlich. Im professionellen Workstation-Umfeld sind bis auf Nischenlösungen jedoch deutlich weniger Anwendungen zu finden. Hier ist genau abzuwägen, ob der Gewinn an Rechenleistung mit einer MP-Anwendung und damit eine Zeitersparnis einen Mehrpreis für ein MP-System rechtfertigt.
Desktop-Anwendungen und Spiele gibt es kaum. Der Grund hierfür liegt in der aufwendigen Programmierung und der in den einzelnen Segmenten nur geringen installierten Basis.
Singlethreaded-Anwendungen und -Benchmarks laufen auf MP-Systemen meist langsamer als auf einem Uniprozessor-System. Ein Grund liegt in dem für die Synchronisation der Prozessoren notwendigen Overhead. Nur falls mehrere Programme gleichzeitig die CPU belasten tritt hier eine Leistungssteigerung bezogen auf die Gesamtleistung des Systems ein. cvi)