Microsoft: Weil CPUs zu langsam sind, müssen FPGAs her

Seit 2011 arbeitet Microsoft daran, FPGAs (Field Programmable Gate Arrays) in Massen einzusetzen. Die Entscheidung fiel also noch unter der Leitung von Steve Ballmer. Mittlerweile sind alle Azure- und Bing-Server mit einem FPGA-Baustein ausgestattet, das hat Microsofts Technikchef für Azure, Mark Russinovich, gesagt. Russinovich, der vor allem durch seine Sysinternal Tools bekanntgeworden ist, sieht in diesen Bausteinen eine große Zukunft, denn sie können spezielle Aufgaben fast so schnell durchführen wie ASICs und sind damit drastisch schneller als CPUs.

• 

Mark Russinovich ... (Foto: Andreas Sebayang/Golem.de)

Mittlerweile sind die FPGAs, die als Dienst auf der Ignite 2016 gestartet wurden, auch für Kunden verfügbar. Derzeit allerdings nur für eine Funktion: die Beschleunigung des Netzwerks, denn ohne die FPGAs lassen sich die 40GbE-Adapter der Server im Azure-Umfeld kaum ausnutzen. Die CPU-Last ist zu hoch und die CPU-Leistung will Microsoft natürlich verkaufen und nicht fürs Netzwerk unnötig und sprichwörtlich verbraten. Die FPGA-Option soll das verbessern. Die Bausteine sind effizienter, beschleunigen und benötigen erheblich weniger Energie, was die CPU entlastet. Die FPGA-Beschleunigung ist allerdings immer noch optional. Sie ist zwar laut Russinovich stabil und Probleme gab es bisher nicht. Zudem empfiehlt er die Option den Kunden, aber es fehlt anscheinend an Erfahrung für eine standardmäßig aktivierte FPGA-Netzwerkbeschleunigung.

Deutliche Beschleunigung in Azure

In mehreren Benchmarks auf Azure-Systemen demonstrierte Russinovich den FPGA-Offload. Ohne FPGAs hat er nur Netzwerkgeschwindigkeiten von 4 GBit/s erreichen können. Das wohlgemerkt auf einem 40GbE-Adapter. Mit zugeschaltetem FPGA waren es rund 25 GBit/s, was laut Russinovich ein guter Wert ist. Die netzwerkbedingte CPU-Last sinkt dabei in dem SDN nahezu auf null. Solche Beschleunigungen haben Microsoft anfangs allerdings auch verschreckt. In ersten Experimenten mit Bing-Servern und der Document-Indexer-Funktion stieg plötzlich die CPU-Last bei FPGA-bestückten Systemen. Der Grund war allerdings ein übergeordnetes System, das freie CPU-Ressourcen entdeckte und dementsprechend einfach noch mehr Daten zur Bearbeitung schickte.

Ähnlich deutlich verbessert sich zudem die Latenz. Die FPGA-Bausteine sind auch hier erheblich schneller. Statt 145 Mikrosekunden sind es nur noch 31 Mikrosekunden Verzögerung durch den FPGA-Baustein. Allerdings war das ein theoretischer Test. Das setzt sich aber auch ähnlich in der Praxis um. Ein SQL-Query demonstrierte Russinovich mit 0,3 Millisekunden statt zuvor etwa 1,2 Millisekunden.

Die Ergebnisse sind jedenfalls so gut, dass Russinovich schon weitere Pläne hat. Die Architektur ist so ausgelegt, dass sich die Bausteine dank direkter CPU-Anbindung auch zum Übernehmen anderer Aufgaben nutzen lassen. Das geht so weit, dass er davon ausgeht, FPGA-Ressourcen in Zukunft über Azure zu verkaufen. Noch müssen die entsprechenden Funktionen aber für die FPGA-Bauteile programmiert werden. Russinovich sieht vor allem Potenzial in dem Bereich Deep Learning und neuronale Netze - das sollte erheblich schneller auf FPGA-Chips funktionieren. Das ist eine Aufgabe, die auch zusammen mit Microsoft Research angegangen wird. Am Ende soll Azure zu einer konfigurierbaren Cloud werden. Es wird aber auch daran gearbeitet, Crypto-Berechnungen oder Storage-Systeme per FPGA zu beschleunigen. Diese beiden Möglichkeiten dürften eher einer Option ähneln wie derzeit die Netzwerkbeschleunigung per FPGA.

Es muss aber nicht immer alles auf FPGA-Bausteinen funktionieren. Fürs Netzwerk wird zumindest darüber nachgedacht, dieses auf ASIC-Bausteine auszulagern. Die Funktionen sind dann fest im Chip, was die Latenzen und die Effizienz noch einmal verbessern dürfte. Der Nachteil: Bis ein entsprechender Chip produziert wird, können durchaus zwei Jahre vergehen. Wenn sich bis dahin im Software Defined Networking von Azure etwas ändert. SDN-Offload ist derzeit eine der Hauptaufgaben, dann war die Arbeit umsonst.