Trends bei Multi-Core-Prozessoren:
Mehrkernprozessoren brauchen einen intelligenten Systembauplan

von Bernd Reder (bernd.reder@networkcomputing.de), Ingo Frobenius (Sun Microsystems)

Share
26.01.2009

Mehr Leistung durch immer höhere Taktfrequenzen – dieser Weg hat sich bei Prozessoren als nicht weiter gangbar erwiesen. Heute sind es Multi-Core-CPUs, welche die Leistung von Servern beschleunigen. Ihre Entwicklung stellt die Entwickler vor neue Herausforderungen: Ohne effiziente Kommunikation zwischen Chip und Schnittstellen bleibt der Mehrkernprozessor unter seinen Möglichkeiten.

Bei integrierten Schaltkreisen (ICs) wird bereits heute an physikalischen Grenzen »gekratzt«, und das stellt die Entwickler vor neue Herausforderungen. So wird eine weitere Erhöhung der Taktrate durch die Lichtgeschwindigkeit beschränkt. Bei einer 5-GHz-CPU von IBM [1] beispielsweise ist ein einzelner Taktzyklus nur noch 0,2 Nanosekunden lang. In dieser Zeit legt das Licht im Vakuum gerade einmal sechs Zentimeter zurück. Der Strom kommt noch auf drei Zentimeter.

Dabei ist zu berücksichtigen, dass ein halber Taktzyklus eine logische 1 darstellt, und die zweite Zyklushälfte eine logische 0. So bleiben nur 0,1 Nanosekunden, um den Wechsel von 0 auf 1 oder zurück von 1 auf 0 durch eine CPU hindurch zu propagieren. Das bedeutet: Eine synchron getaktete CPU darf eigentlich gerade noch eine Diagonale von 1,5 Zentimetern haben, soll der Chip nicht aus dem Tritt geraten.

Bei solch kurzen Zeitfenstern kommt selbst die Latenzzeit von Caches ins Spiel. So hat ein heutiger Level-1-Cache Latenzen zwischen 3 und 5 ns. Beim Level-2 Cache sind bis zu 15 ns Zugriffszeit keine Seltenheit. Muss eine CPU Daten aus dem Hauptspeicher anfordern, können Zugriffszeiten von bis zu 480 ns entstehen, abhängig von der Größe des Servers – für einen Prozessor eigentlich schon eine Ewigkeit.

Beim Ultra-Sparc T2 wird jedem der vier Registersätze ein Thread zugeordnet. Das reduziert die Zeit, in welche die CPU

Fast alle Hersteller von Server-Prozessoren haben erkannt, dass mit der Steigerung der Taktfrequenz nicht mehr Geschwindigkeit aus den Prozessoren herausgeholt werden kann. Daher setzen sie heute auf Multi-Core- und Multi-Thread-Architekturen. Das ist auch aufgrund des Mooreschen Gesetze sinnvoll. Es besagt, dass sich alle 18 Monate die Anzahl der Transistoren, die man auf einem Chip unterbringen kann, verdoppelt.

Dennoch werden selbst hier ersten Grenzen sichtbar, weil die Sperrschichten bei den Transistoren mittlerweile nur noch wenige Atome dick sind.

Hindernis Latenzzeit

Es stellt sich die Frage, welche Herausforderungen bei einem Mehrkern-Chip zu meistern sind, bei dem ein Core eventuell mehrere Threads ausführen kann.

Zunächst ist anzumerken, dass die Latenzzeiten der Cache-Speicher beziehungsweise des Hauptspeichers durch Multi-Core-Technologien nicht auf 0 gesetzt werden können. Außerdem ist zu beachten, dass bei mehreren Cores auf einem Chip die Anzahl der Daten, die zwischen den Cores und der Außenwelt ausgetauscht werden müssen, eher größer als kleiner wird. Wenn etwa ein einzelner Core immer 256 Bit in seinen Level-1 Cache lädt, so benötigen zwei Cores die doppelte Bandbreite zum Hauptspeicher.

Um die Latenzzeiten zwischen Prozessor-Core und den Speichern zu überlisten, setzt Sun [2] bei den Ultra-Sparc-T-Prozessoren einen Trick ein. Vereinfacht dargestellt, besitzen die Cores intern die Registersätze in vierfacher Ausfertigung. Jedem Registersatz wird vom Betriebssystem Solaris ein Thread zugeordnet.

Zwischen den Registersätzen wird mit jeder Taktrate umgeschaltet. Ist zum Zeitpunkt 0 der Thread 0 in einem Core aktiv, so ist beim nächsten Taktzyklus der Thread 1 aktiv, bei Takt 2 der Thread 2, bei Takt 3 der Thread 3. Beim vierten Taktzyklus ist wieder Thread 0 an der Reihe. Was hat das zur Folge?

  • Nehmen wir an, zum Zeitpunkt n ist der Thread 0 aktiv und fordert nun Daten aus dem Hauptspeicher an: Die Abfrage wird adressiert und geht zum Level-1-Cache.
  • Beim nächsten Takt n+1 wird umgeschaltet auf den Thread 1, und dieser Thread darf einen Takt lang rechnen.
  • Beim Takt n+2 wird auf Thread 2 umgeschaltet.
  • Beim Takt n+3 wird auf Thread 3 umgeschaltet.
  • Bei Taktzyklus n+4 ist dann wieder Thread 0 aktiv. Seit Taktzyklus n sind nun (ausgehend von einer Taktfrequenz von 1 GHz) ziemlich genau 4 ns vergangen. Dies ist die Zeit, die der Level-1-Cache benötigt, um einen Wert bereitzustellen. Der Thread 0 kann also weiterrechnen, wenn die Daten im Level-1-Cache lagen.
  • Falls die Daten nicht im Level-1-Cache vorhanden sind, so muss auf weitere Cache-Hierarchien zurückgegriffen werden: Als nächstes käme der Level-2-Cache an die Reihe, der 12 ns zur Bereitstellung benötigt. In diesem Fall müsste der Thread 0 weiter warten, aber es sind ja noch drei weitere Threads im Core vorhanden, die weiterrechnen können.

Angenommen, der Thread 0 fordert zum Takt n Daten an. In diesem Zeitraum werden die arithmetischen und logischen Einheiten der CPU eigentlich nicht genutzt, sondern die CPU adressiert den Hauptspeicher. In den Takten n+1, n+2 und n+3 wird die CPU dann aber durch die Threads 1, 2 und 3 genutzt.

Single-Core-Prozessor: Warten auf Daten-Input

Bei einer klassischen Single-Core-Single-Thread-CPU würde der Thread innerhalb des Cores den Speicher adressieren, die nächsten drei Taktimpulse würde ohne Folgen bleiben, weil die CPU auf die Daten warten muss. Die Auslastung der CPU zwischen den Takten n bis n+3 würde bei dem klassischen Prozessor bei 0 Prozent liegen, bei der CMT-CPU sind es dagegen 75 Prozent.

Bei Einkern-CPUs liegt die Auslastung wegen der Wartzeiten deutlich höher.

Dramatischer würde dies, wenn die Daten aus dem Hauptspeicher angefordert werden müssten. Bei der CMT-CPU wäre zwar ein Thread quasi stillgelegt, aber die Auslastung würde durch die Thread-Umschaltung erheblich gesteigert.

Selbstverständlich werden auch bei diesen CPUs nicht einzelne Bytes nachgeladen, sondern der Cache wird immer gleich mit 32 Byte befüllt. Dahinter verbirgt sich die Hoffnung, dass das nächste Byte, das die CPU anfordert, sich innerhalb dieses 32-Byte-Blocks befindet.

Den Flaschenhals erweitern: Der Faktor Bandbreite

Mit einer solchen Technik lässt sich also Latenz – zumindest teilweise – austricksen. Bei den Ultra-Sparc-CMT-Prozessoren hat Sun bei Umsetzung des Chip-Multi-Threadings (CMT) darauf Wert gelegt, dass die eigentliche Befehlspipeline möglichst einfach und kurz ist. So gibt es innerhalb der Cores keine Branch-Prediction oder Out-of-Order Execution. Dies hätte das Threading extrem verkompliziert.

Stattdessen haben sich die Entwickler dafür entschieden, nicht nur einen, sondern gleich mehrere Cores auf einem Chip zu implementieren. Bei solchen Mehr-Core-Prozessoren »lauern« allerdings andere Herausforderungen: Während man einen einzelnen Core relativ einfach mit Daten aus dem Hauptspeicher versorgen kann, wird dies bei mehreren Cores schwierig. Denn irgendwann schlägt nicht nur die Latenz zu, sondern auch der Faktor Bandbreite.

So ist zum Beispiel bei Intel-Prozessoren zu erkennen, dass eine Verdopplung der Cores nicht automatisch eine Verdopplung der Leistungsfähigkeit mit sich bringt. Hier entpuppt sich der Front-Side-Bus (FSB) als Flaschenhals. Alle Cores eines heutigen Multi-Core-Server-Prozessors von Intel teilen sich einen Bus zur Kommunikation mit dem Hauptspeicher und der Peripherie. Erst bei der neuen Core-i7-Architektur ist das anders.

Vier statt zwei Kerne bringen weniger als 100 Prozent Leistungszuwachs

Setzt man statt herkömmlicher Dual-Core-Prozessoren Quad-Core-Modelle ein, erhält man je nach Benchmark-Verfahren eine Leistungssteigerung zwischen 40 und 100 Prozent. Eine Leistungsverdoppelung An wird jedoch nur dann erzielt, wenn die Algorithmen und Daten hervorragend in die CPU-Caches passen und keine Daten aus dem Hauptspeicher angefordert werden müssen.

Im Idealfall erreicht eine Ultra-Sparc-T2-CPU eine Auslastung von fast 100 Prozent.

Bei speicherlastigen Algorithmen, beispielsweise Data-Warehouse-Applikationen, kann die Performance aber deutlich schwächer sein, weil sich alle Cores den Front-Side-Bus teilen müssen. Hier ist Bandbreite gefordert.

Um die Ultra-Sparc-T-Prozessoren entsprechend mit Daten versorgen zu können, wurden mehrere Design-Entscheidungen gefällt. So sind innerhalb der CPUs die Cores durch eine Low-Latency-Crossbar verbunden. Sie hilft dabei, die Kohärenz des Cache-Speichers sicherzustellen, wenn ein Thread eines Rechenkerns Daten anfordert. In diesem Fall muss immer geprüft werden, ob die Daten in einem Cache eines anderen Cores liegen, wenn er sie nicht in seinem eigenen Cache-Speicher findet.

Über die Crossbar haben die Cores zudem Zugriff auf die On-Chip-Level-2-Caches. Während sich beim Ultra-Sparc-T1 die acht Cores noch vier Level-2 Caches teilten, wurden beim Ultra-Sparc-T2 und Ultra-Sparc-T2-Plus-Prozessor insgesamt acht separate Level-2 Caches implementiert.

Die Verbindung zu den Speicherbausteinen wurde bei den Ultra-Sparc-T1-CPUs noch per DDR2 (zwei Kanäle) realisiert. Daraus resultierte aber eine extrem hohe Anzahl von Anschluss-Pins an der CPU, nämlich mehr als 1400, weil der T1-Prozessor insgesamt vier Speicherbänke separat ansprechen kann.

Für die Ultra-Sparc-T2- und Ultra-Sparc-T2-Plus-Prozessoren wurde daher auf FB-DIMMs (Fully-buffered) zurückgegriffen, die gegenüber DDR2 eine bis zu viermal höhere Bandbreite aufweisen. Durch das Protokoll ergibt sich zudem ein einfacheres Motherboard-Design und eine geringere Zahl von Anschlusspins bei den CPUs.

Protokollfragen: Wie die Bausteine kommunizieren

Außerdem stellt sich die Frage nach dem I/O-Bereich. Bei klassischen Server-Designs spricht die CPU selber über ein bestimmtes Protokoll mit der Außenwelt. So wurde bei den Ultra-Sparc-IIIi-Prozessoren der JBUS für die Kommunikation mit dem Hauptspeicher und den I/O-Bausteinen eingesetzt. Die höherwertigen Ultra-Sparc III, IV und IV+ nutzen das Sun-eigene »Safari«-Protokoll, das eine Skalierung über mehr als 100 Cores in High-End-Systemen ermöglicht.

Der Aufbau eines Ultra-Sparc-T2-Prozessors (

Die I/O-Komponenten mussten dann jedoch an dieses Protokoll angepasst werden, damit sie sich ebenfalls mit den CPUs und den Speicher-DIMMs unterhalten konnten. Bei den Ultra-Sparc-CMT-Prozessoren ging Sun einen neuen Weg: Hier wurden die I/O-Komponenten direkt auf den Prozessoren implementiert. Die Vorteile dabei liegen auf der Hand:

  • Die I/O-Komponenten sind direkt über die CPU-interne Crossbar mit den Cores verbunden. Ein zusätzlicher externer I/O-Baustein oder Bridges sind nicht notwendig.
  • Zusätzlich wurden bei den Ultra-Sparc-T2-CPUs noch zwei 10-Gigabit-Ethernet-Anschlüsse auf dem Chip realisiert. Auch diese können direkt mit den Cores »reden«, ohne Umweg über die Außenwelt.
  • Durch die Integration müssen keine zusätzlichen Bridges im Server von JBUS nach PCI oder Safari nach PCI im Server verbaut werden.

Direkter Zugriff auf Netzwerkschnittstellen verbessert Performance

Der direkte Zugriff auf Ethernet- und PCIe-Schnittstellen verringert wiederum die Latenzzeiten. Normalerweise werden beispielsweise 10-GBit/s-Schnittstellen in PCIe-Slots implementiert. Doch der Weg von der CPU zu dieser Schnittstelle weist dann viele Engstellen auf, die zu Performance-Einbußen führen.

Bei Messungen mit mehreren Threads zum Ansteuern eines 10-Gigabit-Ethernet-Interfaces des Ultra-Sparc-T2 wurden mehr 7 GBit/s Übertragungsrate bei Webservice-Applikationen gemessen. Ein Wert, den man mit einer externen Karte in einem PCIe-Steckplatz nur sehr schwer erreichen kann, weil hier die Latenzen der PCI-Peripherie die Performance beeinträchtigen.

Die Integration wurde von Sun noch weiter geführt. Auf dem Chip wurde jedem Core zusätzlich eine Kryptoeinheit spendiert. Mit ihr lassen sich Ethernet-Daten verschlüsseln, eine Arbeit, die mit Software nur schwer zu realisieren ist. Wer jemals 3DES–Algorithmen implementiert hat, wird das zu schätzen wissen.

Virtualisierungstechniken

Um eine solche Rechenkraft überhaupt ausnutzen zu können, wurden bei den Multi-Core-Prozessoren Mechanismen implementiert, die den Einsatz von Hypervisor-basierten Virtualisierungsschichten ermöglichen. Solche Techniken sind heute auch in Prozessoren von AMD und Intel enthalten.

Sun hat den T5440-Server mit dem Ultra-Sparc T2 bestückt.

Die bei Sun eingesetzten »ldoms« weisen eine Granularität von einem Thread auf, so dass bei einem Ultra-Sparc-T2-basierten System bis zu 64 logische Domains in einem Server möglich sind. Bei einem Ultra-Sparc-T2-Plus-Rechner, also der Multi-Prozessor-Version des Ultra-Sparc-T2, sind es bis zu 128 logische Domains.

Ausblick: Die Zukunft der CPU-Architektur

Bei künftigen Entwicklungen wird es sicher darum gehen, die Latenzzeiten zwischen CPU und Hauptspeicher weiter zu verringern. Weitere Fortschritte wird es bei Funktionen geben, die man direkt in das Silizium »gießt«.

Im Bereich der Multi-Core-Desktop-Prozessoren ist davon auszugehen, dass Modelle mit integrierten Grafikprozessoren auf dem Markt erscheinen. Die Grafikprozessoren können dann gleichzeitig zur Beschleunigung von Gleitkomma-Operationen genutzt werden.

Die Integration von I/O auf den Prozessoren wird die Virtualisierung vereinfachen. Denkbar ist hier ein Virtualisierungs-I/O-Core, der direkt auf dem Chip »vorvirtualisierte« Devices den anderen Cores über eine Crossbar zur Verfügung stellt.

Bei der Kommunikation mit der Außenwelt wird es darum gehen, die Bandbreiten mit den externen Speicherbausteinen zu vergrößern und Signallaufzeiten zu minimieren. Der Übergang von Kupferkabeln zu Lichtwellenleitern in Servern ist hier ein Mittel, um die Signallaufzeiten etwas zu verkürzen.

Auch die Proximity-Communication wird für Multi-Core-Prozessoren interessant, weil Signale nicht mehr durch großflächige Treibertransistoren nach außen gegeben werden müssen. An ihre Stelle tritt die Chip-to-Chip-Kommunikation durch direkte Verbindung zwischen den Bausteinen.

Letztlich bleibt aber eines festzuhalten: Mit den parallelen Multi-Core-Prozessoren wird es auch ein Umdenken bei der Programmentwicklung geben müssen. Nur mit Multi-Threaded-Programmen lässt sich die Leistung von Multi-Core-Prozessoren ausnutzen. Programme wie etwa »Parallel bzip« sind ein Beispiel für solche Anwendungen.

Und es sollte klar sein, dass eine Textverarbeitung durch eine parallele Architektur nicht schneller wird. Diese Applikationen werden immer »Single Threaded« sein und von einem ganz speziellen »Performance-Faktor« bestimmt: der Geschwindigkeit, mit der ein User Tastatur und Maus bedient.

Zum Autor: Ingo Frobenius ist Produktmanager Enterprise Server bei Sun Microsystems [2].

[1] http://www.ibm.de/
[2] http://www.sun.de/
[3] http://www.sun.de/

Verwandte Artikel