Neuro-Prozessoren

Den größten Bedarf an Rechenleistung haben derzeit Unternehmen, die auf Machine Learning setzen: Die dafür verwendeten neuronalen Netze erfordern sowohl beim Training als auch bei der Anwendung viel Performance. Häufig kommen dafür GPUs von Nvidia zum Einsatz, weil sie immerhin schneller als Standardprozessoren und in großen Stückzahlen verfügbar sind.

Geht es jedoch nach Firmen wie Thinci, werden GPUs bald durch Spezialprozessoren für neuronale Netze abgelöst – ähnlich wie GPUs den CPUs die Berechnung von 3D-Welten abgenommen haben. Thincis Graphenprozessor soll auf Task-, Thread-, Daten- und Instruktionsebene parallel arbeiten können. Dabei ist es Funktionseinheiten egal, ob sie mit 8-, 16- oder 32-bittigen Integer- beziehungsweise 32- oder 64-bittigen Fließkommawerten gefüttert werden.

Der Chip soll im 28-nm-Verfahren bei TSMC vom Band laufen und zwei Betriebsmodi unterstützen, nämlich entweder als PCIe-Zusatzkarte oder als SoC mit integrierten ARM-Kernen. Im SoC-Betrieb soll er Simulationen zufolge gerade einmal 2,5 Watt verbraten.

Einen Gegenentwurf stellte Wave Computing vor: Sein Datenflussprozessor alias DPU hat 2¹⁴ einzelne Rechenwerke, die asynchron mit über 6 GHz laufen. Laut Wave würde eine zentrale Taktverteilung bei so vielen Rechenwerken enorme Energiemengen verschlingen. Berechnungen sollen in Wellen durch den Chip laufen. Dadurch kann im Optimalfall auf das Zwischenspeichern in Registern verzichtet werden: Der Output eines Rechenwerks landet unmittelbar als Input im nächsten Rechenwerk.

Wave-CTO Chris Nicol verwies auf das Early-Access-Programm, über das Interessenten schon vor dem eigentlichen Marktstart DPU-Server beziehen können. In diesen sind dann immer vier DPUs über einen FPGA-Interconnect zu einem Einschub verbunden, dem 32 GByte HBM-Speicher und 512 GByte DDR4-RAM zur Seite stehen. Ein kompletter Server-Knoten nimmt 16 Einschübe auf, sodass 64 DPUs zusammenarbeiten. Das als KI-Benchmark benutzte AlexNet soll sich auf solch einem Knoten mit dem ImageNet-Bildersatz in nur 40 Minuten trainieren lassen.

Chips von gestern …

Spezialprozessoren, die gezielt zur Beschleunigung von neuronalen Netzen entwickelt wurden, sind an sich nichts Neues – allerdings geschah viel Prozessorentwicklung bisher im Geheimen. So hat Google bereits seit 2015 seine TPU (Tensor Processing Unit) im Einsatz. Googles Cliff Young erklärte die Hintergründe, warum Google überhaupt selbst Hardware entwickelt hat.

Anno 2013 sah man sich mit einem Skalierungsproblem konfrontiert: Selbst wenn alle Android-Nutzer nur drei Minuten pro Tag ihrem Smartphone Sprachbefehle gegeben hätten, hätte Google dafür seine weltweiten Serverbestände mindestens verdoppeln müssen. Trotz hoher Entwicklungskosten war die eigene Hardware also insgesamt immer noch günstiger, zudem sie nicht auf Spracherkennung beschränkt war: Neuronale Netze werden von Google etwa auch bei der Bilderkennung, bei Übersetzungen und beim Sortieren von Suchergebnissen benutzt.

Das TPU-Projekt wurde sehr schnell umgesetzt: Zwischen Projektbeginn und dem Einsatzstart in den Rechenzentren vergingen gerade einmal 15 Monate. Dabei half sicherlich, dass Google das Trainieren von neuronalen Netzen erst einmal ausgeblendet hatte und sich auf die Anwendung fokussierte – ergo konnte man sich auf Integer-Arithmetik beschränken (siehe auch S. 24). Und weil viel Speicher nötig war, nehmen die im Chip integrierten Puffer mehr Die-Fläche ein als die eigentliche Matrix-Multiply-Einheit (35 zu 24 Prozent).

Trotz der Puffer und zusätzlichen 8 GByte DDR3-Speicher hat sich herausgestellt, dass die TPU in den meisten Fällen ihre Rechenpower nicht voll ausfahren konnte, weil die Speicherbandbreite zum Flaschenhals wurde. Young verneinte allerdings die Nachfrage, ob Google daraufhin eine überarbeitete TPU-Variante in Angriff genommen hätte: Man habe zu dem Zeitpunkt bereits an der TPU2 gearbeitet, die auch das Training von neuronalen Netzen beherrsche. Fragen zur TPU2 blockte Young konsequent ab – vielleicht erfährt man ja in ein paar Jahren Details zu ihr, wenn in Googles Rechenzentren bereits eine TPU3 arbeitet …

… für heute …

Microsofts John Sell hatte zur Hot Chips „seinen“ Scorpio-Chip mitgebracht, das Herzstück der ab 7. November erhältlichen Spielekonsole Xbox One X. Zum großen Teil bestätigte sein Vortrag die Informationen, die bereits vor etlichen Monaten an die Öffentlichkeit geraten sind.

John Sell garnierte seinen Vortrag allerdings mit vielen kleinen Details. So hat der Chip, den TSMC mit 16 nm FinFET+ fertigt, vier Shader-Arrays mit jeweils 11 Compute Units. Genutzt werden pro Array aber nur jeweils 10 Units: Die elfte ist als Ersatz einkalkuliert. Solche „Opfer“-Einheiten sind bei großen Chips – der Scorpio-Chip misst 359 mm² und umfasst 7 Milliarden Transistoren – keine Seltenheit; sie dienen dazu, Fertigungsfehler auszugleichen und dadurch die Chipausbeute zu erhöhen.

Um Latenzen zu minimieren und Bandbreiten zu erhöhen, wurden an vielen Stellen größere Caches und TLBs eingebaut; der Speicher-Controller spricht nun GDDR5- statt DDR3-Speicher an. Die Xbox One X enthält 12 GByte Speicher; DevKits für Entwickler haben sogar 24 GByte. Das vormals in der One-Familie verwendete ESRAM wurde ersatzlos gestrichen: Es konnte sein angedachtes Potenzial nie voll entfalten. HBM2 hat sich Microsoft während der Entwicklung ebenfalls angesehen, aber verworfen: zu komplex, zu teuer.

Während andere Prozessoren je nach Umgebung oder Kühlsystem leicht unterschiedliche Performance liefern, war es Microsoft wichtig, dass alle Konsolen für Multiplayerspiele eine exakt gleiche Rechenleistung erzielen. Um dennoch je nach Einsatzzweck den Lüfterlärm gering zu halten, passt Scorpio die Taktfrequenzen der Shader-Einheiten laufend an den aktuellen Bedarf an. Power Gating, also das Abtrennen einzelner Funktionsblöcke, ist bei den Shader-Arrays hingegen nicht vorgesehen.

… und für morgen

Software Defined Networks, kurz SDN, sind bei Netzwerkausrüstern der letzte Schrei: Netzwerkkomponenten sollen sich je nach individueller Programmierung anders verhalten. Inzwischen haben mehrere Firmen begonnen, Netzwerk-Controller zu entwickeln, die sich mehr oder minder direkt mit Programmen der SDN-Programmiersprache P4 füttern lassen.

Barefoot Networks hat den 16-nm-Chip Tofino im Angebot, der bis zu 1,3 Millionen IPv4-Routen unterstützt. Er bedient wahlweise 65 100-GBit/s-, 130 50-GBit/s- oder 260 25-GBit/s-Ports. Ein Port kann dediziert zur Konfiguration abgestellt werden; alternativ lässt sich eine Kontroll-CPU auch per PCIe 3.0 x4 anbinden.

Xilinx propagiert wiederum seine grundsätzlich vielseitig einsetzbaren FPGA-Chips für P4-Lösungen. Für die UltraScale+-Familie gibt es einen Compiler, der P4 in das hauseigene SDNet-Format übersetzt, das ohne zusätzliche Verifizierungen auskommt.

Netronome lockt bei seinen Netzwerkchips der NFP-4000-Serie mit bis zu vier unabhängigen PCIe-3.0-x8-Links. In Servern mit mehreren CPU-Sockeln kann der Chip so an jede CPU einzeln angebunden werden und Daten direkt in ihren Arbeitsspeicher schreiben – ganz ohne NUMA-Komplikationen.

IoT-Controller

Das Start-up Eta Compute hatte einen besonderen Cortex-M3-Mikrocontroller im Gepäck: Der EtaCore M3 arbeitet bei Versorgungsspannungen von 0,25 V bis 1,2 V. Damit lässt er sich ohne zwischengeschaltete Pufferelektronik oder Akkus direkt von Solarzellen versorgen – sogar in Innenräumen.

Die Stromspar-Philosophie von Eta unterscheidet sich stark von der etablierter Chips: Statt anstehende Aufgaben so schnell wie möglich abzuarbeiten und danach wieder im Sparmodus zu schlummern, arbeitet der EtaCore M3 durchgängig. Der Clou: Je niedriger die Versorgungsspannung, desto niedriger taktet der Chip. Am Minimum von 0,25 Volt schafft der Chip nur noch 260 kHz, verbraucht aber dann auch weniger als 8 µW. Das ist laut Eta nur ein Fünftel dessen, was herkömmliche M3-Controller verbraten, die zudem vergleichsweise viel Energie beim Aufwachen und Einschlafen verlieren.

SiFive hat die Hot Chips dafür genutzt, sein Geschäftsmodell rund um die lizenzfreie Prozessorarchitektur Risc-V vorzustellen: Man arbeitet schlicht als Mittelsmann. SiFive hat IP-Blöcke rund um Risc-V im Angebot, aus denen man sich selbst einen individualisierten Mikrocontroller zusammenstellen und bei SiFive in Auftrag geben kann. Den weiteren Prozess, also die Zusammenarbeit mit einer Foundry zur eigentlichen Chipfertigung, übernimmt SiFive; als Auftraggeber bekommt man am Ende die gewünschte Stückzahl getesteter Chips zurück.

Einige Details rund um SiFive muten allerdings kurios an. So gibt es keine IP-Blöcke für Embedded Flash, obwohl dies kein ungewöhnlicher Wunsch bei einem Mikrocontroller wäre. Hinzu kommt, dass SiFive die IP von Sicherheits-Coprozessoren und zugehörige Dienstleistungen von Rambus durchreicht – einer Firma, die jetzt nicht gerade zum Open-Source-Ansatz von Risc-V passt. (mue@ct.de)