qrios

IT ist kurios!

Kernschmelze im Rechenzentrum

5 Kommentare

Ein mit einem Neural Net "programmierter" Zynq-FPGA von Xilinx.

Ein mit einem Neural Net “programmierter” Zynq-FPGA von Xilinx.

Ende September schrieb die Wired über Microsofts Wette auf FPGAs in ihren Cloud-Rechenzentren. Es hat dann “nur” drei Wochen gedauert bis auch die großen Medien (Fortune, The Register, Forbes, …) auf das Thema aufmerksam wurden. Verstärkt wurde die Aufmerksamkeitswelle noch durch die Berichte, dass im neuesten Apple iPhone auch ein FPGA sitzt (fälschlicherweise vermutet der Autor, dass dieser für AI zuständig ist). Dass es so lange gedauert hat  ist insofern erstaunlich, da Wired von Diane Bryant erfahren haben will, dass  Intel die 16 Mrd. Dollar für Altera ausgegeben hat, eben weil Microsoft zukünftig FPGAs in ihren Servern haben will. Und Diane Bryant ist immerhin Intels Vizepräsidentin für die Data Center Group.

Die Übernahme des zweitgrößten FPGA-Herstellers Altera durch den größten CISC-Prozessor-Anbieter für eine Rekordsumme in diesem Markt wurde von Intel begründet mit dem großen Potential der frei programmierbaren Chips im Bereich des machine und deep learnings. Und diese Form der Computation geschieht – zumindest heute noch – in Rechenzentren.

FPGAs für Deep Learning?

Microsoft selbst untersuchte schon länger die Möglichkeiten von FPGAs als Beschleuniger für den Betrieb von AI-Tasks. Sie sind dabei nicht die ersten. Schon 2010 hatte Yann LeCun (heute Leiter des AI-Labors bei Facebook) ein Paper über die Hardware-beschleunigte Umsetzung von Convolutional Neural Networks mitverfasst.

Facebook selbst hatte im Frühjahr verlauten lassen, dass es seine Zusammenarbeit mit Intel bei der Definition neuer Serverprozessoren unterstützt. Dabei sollen zukünftig SoC rauskommen, die neben dem Xeon auch einen FPGA enthalten können.

Zusammen mit Google arbeitet Facebook darüber hinaus an einem Standard für eine schnellere Anbindung unter anderem von “Co-Prozessoren” an den Hauptprozessor. Diese Initiative namens OpenCAPI soll die Bremse PCI Express ablösen. Weder PCIe 3.0 mit 32 Lanes noch PCIe 4.0 sind derzeit in Sicht und damit ist die maximale Transferrate seit Jahren bei 16GByte/s eingefroren. OpenCAPI (Open Coherent Accelerator Processor Interface) soll pro “Link” 25Gbit/s ermöglichen mit initial 8 Links. Damit wäre man bei maximal 25GByte pro Sekunde. (Leider kennt Heise den Unterschied zwischen GBit und GByte nicht.)

Flaschenhals Speicherbandbreite


25 Gigabyte pro Sekunde sind jedoch für machine learning ein Witz. Aktuelle CUDA- und OpenCL-Karten von NVIDIA oder AMD erreichen Transferraten von mehreren hundert GByte. Eigentlich wollte NVIDIA mit Volta in diesem Jahr schon bei einem Tera-Byte pro Sekunde liegen, aktuell erreicht das beste System 720GByte/s. AMD möchte 2019 die Rate von 1TByte/s erreichen.

Diese hohen Raten betreffen die Kommunikation zwischen den GPU-Cores und deren dediziertem Speicher. PCI oder OpenCAPI spielen dann eine Rolle, wenn ein Netz trainiert oder ein neu trainiertes Netz geladen werden soll. Für den Betrieb eines Netzes im Rechenzentrum spielt dieser Fall eher eine untergeordnete Rolle. Im Normalfall wird das trainierte Netz einmal in den Speicher der CUDA-Karte geladen und bleibt dort währen der gesamten Laufzeit bestehen. Da sich das Netz selbst nicht ändert, muss nicht einmal der Zustand gesichert werden.

FPGAs mit einer soliden Transferrate zu einem lokalen Speicher gibt es bisher nicht. Eine aktuelle PCIe-Karte mit dem besten FPGA (Virtex-7) von Xilinx hat zwar 8GByte on Board und kann somit mit den besten NVIDIA oder AMD-Karten mithalten. Aber es handelt sich dabei um DDR3-Ram. Die maximale Transferrate die man in einem solchen System erreichen kann sind 14GByte/s. D.h. der schnellste verfügbare FPGA kann im Vergleich zu einer/mehrerer GPUs nur 1/20 der Daten in der gleichen Zeit scheffeln und den Highend-GPUs stehen meistens 12 oder 16GByte zur Seite.

Stratix 10: Fuß in der Tür zum Rechenzentrum

Vor dem Hintergrund all dieser Bestrebungen war die Meldung über den neuen Stratix 10 von Altera und damit des ersten FPGA aus dem Hause Intel nicht überraschend. Der aus Intel wichtigste Aspekt dieses Chips ist die versprochene Transferrate von 1 TByte/s zwischen Programming Logic (FPGA) und dem im SoC eingebauten Speicher. Dabei handelt es sich um vier HBM2-Speicherstapel jeweils mit 1024 an den FPGA angebunden. Diese 4096 Leitungen entsprechen dem, was auch eine Nvidia P100 Richtung HBM2 bieten soll.

Mit dem Stratix 10 gibt es somit erstmals eine FPGA-Konfiguration, die sich tatsächlich mit den aktuellen GPUs messen kann. Wer jedoch jemals mit FPGAs gearbeitet hat, weiss dass schon 1024 Datenleitungen zu einem erheblichen Verbrauch der LUTs, Gatter und Slices führen. Mit externem Speicher (also nicht dem internen Blockram) kommuniziert man mittels des AXI-Protokolls. Dabei greift man nicht einfach auf eine Speicheradresse zu sondern implementiert einen sehr umfangreichen Stack. Speicheradressen werden dabei in ein Register geschrieben und diese werden dann an die MMU gegeben. Der Ressourcenverbrauch verdoppelt sich noch, wenn man nicht nur lesen sondern auch schreiben will.

Von den verschiedenen AXI-Versionen ist nur Scatter/Gather und hier insbesondere der Modus “Cyclic Buffer Descriptor” relevant wenn es um wirklich hohe Transferraten geht. Dabei werden die Inhalte des Speichers Schritt für Schritt dem FPGA zur Verfügung gestellt. Abhängig davon, welche Bandbreite zur Verfügung steht, ergibt sich auch, wie viele Bytes man pro Cycle zur Verfügung hat. By 4 x 1024 sind dies im Prinzip 4096 bit.

Es ist jedoch möglich, mehrere Channels parallel zu betreiben. Bei Xilinx (Artix/Kintex) sind dies vier Channels. D.h. es stehen maximal 2KByte Speicher zur gleichen Zeit zur Verfügung. Puffert man diese noch im Embedded Memory Block (Altera) oder Blockram (Xilinx), kann man – je nach Chip – auf bis zu 2 Mbit gleichzeitig zugreifen. Ein solcher Puffer verbraucht aber weitere Ressourcen insbesondere, wenn er von zwei Teilnehmern gleichzeitig gelesen und geschrieben werden soll (Double Buffer).

 

Im Gegensatz dazu können die Cores einer GPU gleichzeitig auf unterschiedliche Bereiche des (Device-)Speichers zugreifen ohne sich in die Quere zu kommen. D.h. im Prinzip hat jeder Core sowohl lesend als auch schreibend Zugriff auf den gesamten Speicher. Bei der Entwicklung mit CUDA oder OpenCL muss nur darauf geachtet werden, dass im gleichen Takt oder Zyklus (respektive Thread) auf jede Zelle nur lesend oder schreibend zugegriffen wird. Wie im FPGA gibt es darüber hinaus auch bei GPUs Burstmodes, die das blockweise laden oder schreiben von Speicheradressen ermöglicht.

Die Wette von Intel und Microsoft auf FPGAs kann nur bei spezifischen und eng abgegrenzten Situationen funktionieren. Alle Topologien, die eine massive Verknüpfung mehrerer Layer verlangen – zB. DCNNs – scheiden offensichtlich aus (siehe Convolutional Neural Networks). Es müsste für jedes Neuron ein temporärer Speicher im lokalen Blockram implementiert werden, um einen Layer zu rechnen. Dabei ist noch nicht berücksichtigt, dass FPGAs nach wie vor Probleme mit Floatingpoint-Operationen haben. Der sehr limitierte lokale Speicher bei heutigen FPGAs verlagert den Flaschenhals also nur.

FPGAs sind bei vielen Aufgaben schneller als normale CPUs. In vielen Fällen sind sie auch schneller als GPUs. Ihr wesentlicher Vorteil ist der direkte Zugriff auf IOs. Deswegen werden sie beispielsweise als essentieller Bestandteil von Firewalls. Hier fliessen Ethernetpakete direkt in die Programming Logic. Nach wenigen Takten kann ein FPGA viele Pakete gleichzeitig filtern und blocken, eine unlösbare Aufgabe für einen Xeon oder ARM. Auch FFTs oder De-/Encoding von Audio oder Video lassen sich in Programming Logic wesentlich performanter und energiesparender implementieren. Auch, wenn hierfür häufig ASICs und DSPs eingesetzt würden.

Stolperstein FPGA-Toolchain

So überragend FPGAs aber auch für viele Aufgaben geeignet sind, sie haben nach wie vor ein großes Problem. Ein Problem, das wie ein weisser Elefant im Raum steht über den weder Microsoft, noch Intel noch Facebook spricht: die Entwicklungswerkzeuge. Unisono werden sowohl Altera Quartus als auch Xilinx Vivado als “crappy” bezeichnet. Die Tools sind echte Monster (Xilinx: ~20GByte Download jedes Quartal), sind unfassbar langsam, laufen nur auf wirklich sehr ausgewählten Betriebssystemkonfigurationen verwenden exotische Technik und die Fehlermeldungen geben selbst Experten oft Rätsel auf.

Solange die Toolsituation so ist, werden nicht genug Entwickler da sein, die die Möglichkeiten der Chips ausnutzen können. So ist es nicht verwunderlich, dass selbst Intel intensiv nach Entwicklern für zum Beispiel das AXI-Protokoll sucht. Inzwischen gibt es ein vielversprechendes Open-Source-Projekt: Yosys. Momentan kann man damit allerdings nur einen FPGA von dem kleinen aber feinen Hersteller Lattice programmieren (nein, es heisst synthetisieren). Das nächste Ziel auf der Roadmap der Entwickler ist der Zynq von Xilinx. Ein Chipfamilie, die schon eher das Potential für Größeres hat.

Fazit

GPUs sind im Rechenzentrum eine echte Bedrohung für Intels Marktführung. Und für die größten Einkäufer von Servern (Google, Microsoft und Facebook) zeichnete sin in letzter Zeit immer mehr ab, dass NVIDIA – inzwischen auch mit eigenen Komplettservern – der einzige Treiber und damit früher oder später Monopolist wird. Mit all der Definitions- und Preismacht, die damit einhergeht. Stratix 10, der erste FPGA unter dem Intel-Dach hat das Potential, die Vormacht von GPUs im Bereich Deep Learning zu brechen. Für einen wirklichen Erfolg müsste Intel jedoch die Software-Leute von Altera auf eine neue – möglichst freie – Codebasis ansetzen.

Denn die nächste Architektur für Machine Learning steht schon bereit: Wave.


Written by qrios

October 24th, 2016 at 2:49 pm

Posted in gadgets

5 Responses to 'Kernschmelze im Rechenzentrum'

Subscribe to comments with RSS or TrackBack to 'Kernschmelze im Rechenzentrum'.

  1. Dear Qrios,

    I’ve read your post using Google translator. I was looking for informations about memory access with the Stratix10. Am I right there is currently no public informations about this topic? At the Jain institute we’d like to evaluate these kind of processors as the main driver in cloud and security technology.

    Could you send me your code you describe in the article? It would be very helpful. We would even name you in our papers about this topic.

    Thank you very much.

    Bhattanagar Maitreya

    27 Oct 16 at 1:19 pm

  2. Hi,

    you’ll find my code at https://github.com/OpenDGPS/zynq-axi-dma-sg. As you can see it is the code for a Zynq/PL and not for Stratix 10. But it should be easily adaptable. The underlying protocol is in both cases AXI4 with scatter/gather.

    qrios

    27 Oct 16 at 1:40 pm

  3. Heise mag zwar falsch liegen mit den Bits und Bytes, aber offensichtlich verwechselst auch Du die Einheiten. Laut Spezifikation von OpenCAPI geht es um 25GHz und nicht 25Gbps.

    Ansonsten interessanter post. Mal sehen, was da demnächst passiert.

    N.N.

    27 Oct 16 at 1:45 pm

  4. Hi,

    laut “OpenCAPI 3.0 – Data Link Layer Specification” entsprechen die 25Ghz (oder genauer 25,78125 GHz) genau 25Gbps pro Lane. D.h. mit beispielsweise 8 Lanes kommt man mit OpenCAPI auch nur auf 25GByte/s. Zum Hostmemory (z.B. auch HBMs) wäre das im Vergleich zu Device-Memory auf GPU-Karten noch immer um mindestens eine Größenordnung zu wenig. Man bräuchte also 80+ Lanes um “transparent” zwischen CPU und GPU kommunizieren zu können. Ausserdem glaube ich, dass wir OpenCAPI lange nicht in erschwinglichen Rechnern sehen werden. Derzeit ist die Spezifikation nur auf Power-CPUs ausgelegt und trotz “Training” die Anforderungen an die Hardware bezüglich der Frequenzen extrem aufwändig und damit teuer ist.

    qrios

    27 Oct 16 at 2:02 pm

  5. […] intelligenter auf den Speicher zugreifen. Mit einem Bus von 288 bit Breite stellt sich das neulich beschriebene Problem Resourcen-hungrigen AXI-Implementation als nicht mehr so dramatisch […]

Leave a Reply