Werbung
Die Leistung für Single-Thread-Anwendungen zu erhöhen, ist eine der größten Herausforderungen aktueller CPU-Architekturen. Während Intel hier in den vergangenen Jahren nur noch kleine Schritte machen konnte, soll die Zen-Architektur für AMD einen größeren Sprung machen und mit Intel zumindest aufschließen. Die Single-Thread-Performance ist durch die immer größere Parallelität und immer größere Anzahl an Kernen in den Hintergrund gerückt, spielt bei vielen Anwendungen aber noch immer eine wichtige Rolle.
Soft Machines, ein Unternehmen aus den USA, hat sich seit einigen Jahren auf die Entwicklung einer neuer CPU-Architektur spezialisiert und hier seit Jahren viele theoretische Ansätze aufgezeigt. Nun wurde eine erste konkrete Umsetzung vorgestellt, die durch Lizenzpartner lizensiert werden kann und auf praktische Umsetzungen wartet. Wir wollen einen genauen Blick auf die Herausforderungen und Lösungen durch Soft Machines werfen.
Es gibt verschiedene Ansätze die Leistung eines Prozessors zu erhöhen. Die Steigerung des Takes ist sicherlich die naheliegendste. Bei 4 bis 5 GHz und einer Leistungsaufnahme von 125 W ist aktuell aber auch hier das Ende der Fahnenstange erreicht. Also gilt es sich auf architektonische Verfeinerungen zu konzentrieren. Immer mehr Kerne sorgen für eine höheres Thread Level Parallelism (TLP). Auf Instruktionsebene sorgt die Instruction Level Parallelism (ILP) für eine Beschleunigung von Rechenvorgängen und über eine bessere Vorhersage und Aufteilung von Rechenaufgaben per Branch Prediction können Wartezeiten verkürzt werden.
An vielen dieser Stellschrauben wurde bereits gedreht und auch in Zukunft wird dies eine große Rolle spielen, denn nahezu jeder Software-Code und jede Instruktion ist zunächst einmal eine nicht per se zu parallelisierende Aufgabe für die Hardware. Es geht also darum per Software aus Single-Thread-Prozessoren eine möglichst gute Parallelisierung zu extrahieren. Dies wird bereits seit Jahren bei den Grafikkarten genutzt, denn hier stehen inzwischen mehrere tausend einzelne Rechenkerne pro GPU zur Verfügung. In Großrechnern sind es dann schnell mehrere Millionen und je nach Anwendungsgebiet können diese auch sehr effektiv genutzt werden.
Um die Single-Thread-Performance zu erhöhen versuchen die Entwickler neuer Architekturen IPC-Leistung, als Instruction per Clock, zu erhöhen. Können beispielsweise in einer 3-Wide Out-of-Order-Architektur-Pipeline drei Instruktionen pro Takt verarbeitet werden, sind es bei einer 5-Wide Out-of-Order-Architektur-Pipeline eben fünf und das erhöht die Leistung um theoretisch 66 Prozent. Doch so einfach ist diese Rechnung nicht, da sich der Code bzw. die Operationen nicht an die Hardware derart anpassen können, dass eine Instruktion immer genau in diese Blöcke eingeteilt werden kann. Es kommt immer zu einem gewissen Overhead und Leerläufen - die Pipeline ist nie zu 100 Prozent gefüllt und kann daher auch nie perfekt effizient arbeiten.
Dennoch: Je "weiter" die Architektur wird, also desto mehr Instruktionen pro Takt bearbeitet werden können, desto besser - zumindest auf den ersten Blick. Denn, je weiter die Architektur in dieser Hinsicht wird, desto größer muss auch die Infrastruktur dafür auch sein. Dazu gehören Buffer, Cache-Speicher und vieles mehr. Dies erhöht natürlich die Komplexität des Designs und vergrößert den Chip auch in seiner Fläche. Es muss vom Hersteller also abgewogen, ob die gewünschte Weite zum jeweils geplanten Budget an Chipfläche und den dazu passenden Verbrauchswerten übereinstimmt. Intel hat sich bei der Skylake-Architektur für eine 6-Wide-Out-of-Order-Architektur entschieden. NVIDIA bei den eigenen Denver-ARM-Kernen sogar zu einer 7-Wide. Diese extrem tiefen Pipelines sind bei Anforderungen im Bereich von 2-Wide- oder 3-Wide-Architektur aber wieder nicht sehr effizient und wir landen wieder bei der Frage nach einem möglichst guten Kompromiss.
So haben sich zwei Designphilosophien entwickelt. Während Complex Instruction Set Computer (CISC) auf komplexe Instruktionen hin ausgelegt sind, folgen Reduced Instruction Set Computer (RISC) dem einfacheren Ansatz. Eigentlich zählen x86-Prozessoren zu den CISC, da Intel aber eine Art Zwischenlösung anstrebt und auch verwendet, nennt sich diese CRISC. Dazu gehört auch die Implementierung von Simultaneous Multithreading (SMT), durch das zwei Threads auf einen physischen Kern verarbeitet werden können.
[h3]Die VISC-Architektur[/h3]
Was Soft Machines nun mit der VISC-Architektur macht, ist ein Aufteilen von Single-Thread-Instruktionen auf mehrere physische Kerne. Das klingt auf den ersten Blick recht einfach, ist aber keine triviale Lösung des Problems.
Das Beispiel zeigt eine Umsetzung mit vier physischen Kernen. Das Design als solches kann darauf vier virtuelle Kerne oder Threads verarbeiten. Was die VISC-Architektur an dieser Stelle aber besonders macht ist die Tatsache, dass Threads auf einem virtuellen Kern auf allen physischen Kernen verarbeitet werden können. Sind die physischen Kerne zudem auch noch als 4-Wide-Out-of-Order-Architektur-Pipeline ausgelegt, ergibt sich ein theoretisch 16-Wide-Design (4 physische Kerne x 4-Wide).
Alle CPU-Architekturen, egal ob x86, ARMv8, Power oder SPARC, verwenden ihre eigenen Instruction Set Architectures (ISA). Sie können also nur mit diesen vordefinierten Instruktionen umgehen und dies gilt auch für die VISC-Architektur. Im Front End dieser werden Instruktionen also in Virtual Hardware Threads unterteilt, die den virtuellen Kernen zugewiesen werden. Diese kümmern sich in der Folge selbständig darum, freie Ressourcen in den physischen Kernen zu finden und belegen diese nach Bedarf. Mehrere virtuelle Kerne können so einen physischen Kern benutzen.
Die Herausforderung ist nun die Zuteilung der freien Ressourcen und hier soll die VISC-Architektur einen großen Unterschied zu etablierten Designs machen. Während diese nämlich mehr oder weniger aus Spekulationen ausgelegt sind, die zutreffen können oder nicht, soll die VISC-Architektur bessere Vorhersagen über die Nutzung der Ressourcen ermöglichen und zudem in der Lage sein, eine Neuzuordnung in nur wenigen Taktzyklen (Soft Machines spricht von 1-4 Zyklen) durchzuführen. Diese Zuteilung von Daten an verschiedene Kerne ist der Flaschenhals der meisten Architekturen. VISC wählt einen Ansatz, der explizit auf einen schnellen Wechsel ausgelegt ist und so können Register ihre Daten in einem Taktzyklus austauschen, während dies zwischen den L1-Caches deutlich länger dauert. Erkauft wird dies mit einer limitierten Größe der Daten, die aus einem Register in ein anderes übertragen werden können.
Nun kann man sich die Frage stellen, warum Intel, ARM und andere CPU-Hersteller dies nicht ähnlich lösen. Die Antwort darauf ist durch die Schwierigkeit begründet den Austausch der Daten zu koordinieren, ohne das diese verloren gehen können. Ein Austausch von Daten aus den Registern ist extrem kompliziert und auch riskant. Einen Großteil der Anstrengungen hat Soft Machines genau auf diesen Punkt verwendet und daraus erklärt sich auch der theoretische Vorteil der VISC-Architektur. Der zweite wichtige Punkt ist eine möglichst gute Vorhersagen des anfallendes Rechenaufwandes bzw. die Zuteilung der freien Ressourcen. Diese Branch Predicition hat Intel nahezu perfektioniert (auch wenn vermutlich noch immer viel Verbesserungspotenzial vorhanden ist) und Soft Machines liegt hier einige Jahre im Rückstand. Wird aber auch dieses Feld angegangen, kann die VISC-Architektur weiter profitieren.
[h3]Shasta - 2 Kerne, 2 virtuelle Kerne[/h3]
Eine erste Umsetzung der VISC-Architektur ist Shasta. Dabei handelt es sich um eine Intellectual Property (IP) von Soft Machines, die wie ARM-Cortex-Kerne lizensiert werden kann. Shasta besteht aus zwei physischen und zwei virtuellen Kernen.
Die ersten drei Stages der Pipeline sehen dabei nicht anders wie bei anderen Architekturen aus. Interessant wird es ab der Threadlet/Formation, für die weitere drei Stages vorgesehen sind. Die Zuteilung der virtuellen Kerne auf die physikalisch vorhandenen sowie der dazugehörige Datenaustausch benötigen zusätzliche 6+1 Stages. Die +1-Stage kommt zu Stande, wenn keine gleichwertigen Threads auf einen physischen Core zugreifen. Dem rechenintensiveren Thread werden die größten Ressourcen zugeteilt. Da auch diese eine extrem schwierige Abschätzung ist, steckt darin auch ein Großteil an Kompetenz in der VISC-Architektur.
Die Aufteilung von virtuellen Kernen auf physische Kerne kann per Software geschehen. So ist es der VISC-Architektur nicht komplett selbst überlassen, ob ein virtueller Kern alle physischen verwenden kann oder beispielsweise einem virtuellen Kern nur die Nutzung von zwei physischen Kernen erlaubt wird. Über diese Konfiguration und Festlegung kann eine Optimierung an das jeweils vorhandene Anwendungsprofil erfolgen. Diese Zuteilung kann auch zur Laufzeit erfolgen, kostet dann aber etwa 10-12 Taktzyklen und sollte nur bei Bedarf angewendet werden.
Soft Machines - VISC-Architektur
Soft Machines verwendet für die VISC-Architektur eigene ISA, will aber natürlich zu bestehenden Systemen kompatibel sein. Bisher einzig offizielle Unterstützung besteht zu ARMv8 - entsprechender Code kann also interpretiert und umgewandelt werden. Interessant wäre sicherlich die Nutzung von x86-ISA, dagegen wird Intel aber sicherlich etwas haben und so gibt es derzeit nur Ankündigungen zur Unterstützung weiterer ISA. Bisher waren solche Konvertierungen meist auch wenig erfolgreich. Intel versuchte dies für seine Itanium-Prozessoren, Transmeta zu x86 und NVIDIA verwendet für Denver eine Konvertierung der ARM-ISA zu einem eigenen System.
Soft Machines spricht bei der Translation-Layer zwischen VISC und anderen ISAs aber nicht von einer Übersetzung, sondern nur von der Sicherstellung der Kompatibilität. Es wird an dieser Stelle also noch nicht derart in den Code eingegriffen, dass eine Leistungsoptimierung notwendig wird oder stattfindet, sondern die Translation-Layer stellt nur sicher, dass die VISC-ISA die ISA des Drittherstellers versteht. Die bisherigen Ansätze von Intel, NVIDIA und Transmeta sagen immer gleich eine Art Übersetzung vor, die dann im Falle von NVIDIA auch auf eine 7-Wide-Out-of-Order-Pipeline-Architektur hin ausgelegt war. Diese Festlegung findet im Falle der VISC-Architektur an dieser Stelle noch nicht statt. Soft Machines spricht von einem Overhead von gerade einmal 5 Prozent bei der Nutzung einer anderen ISA auf der VISC-Architektur.
[h3]Erste VISC-Hardware[/h3]
Soft Machines hat also damit begonnen die ersten Designs am Markt anzubieten. Doch neben eigenen Produkten steckt hinter der Entwicklung der VISC-Architektur natürlich noch viel mehr, denn Investoren sind beispielsweise Samsung Ventures, GlobalFoundries, AMD und Mubadala, die Erkenntnisse aus der Entwicklung sicherlich auch für die eigenen Produkte verwenden wollen.
Der bereits beschriebene Shasta-Prozessor ist mit jeweils zwei virtuellen und physischen Kernen nur eine erste Auskopplung aus einer kompletten Serie. Soft Machines sieht zwei Produktgruppen vor. Prozessoren und SoCs. Shasta ist ein Design, das einen Prozessor mit 1 oder 2 virtuellen auf zwei physischen Kernen oder 2 bis 4 virtuellen auf vier physischen Kernen vorsieht. Das 64-Bit-Design erreicht dabei Taktraten von 2 GHz und wird in 16-nm-FinFET gefertigt. Bereits ab Mitte 2016 sollen diese verfügbare sein.
Per Symmetric Multiprocessing (SMP) lassen sich mehrere Chips zusammenfassen. Damit plant Soft Machines für das 3. Quartal auch den Mojave-SoC mit 2 bis 4 virtuellen Kernen. 2017 soll dann Shasta+ mit bis zu acht virtuellen auf vier physischen Kernen erscheinen. Der Prozessor soll dann bereits in 10 nm gefertigt werden. Im SoC-Bereich soll es ebenfalls ine Shasta+-Design alias Tabernas geben. Für darauf folgende Generationen plant Soft Machines Tahoe mit bis zu 16 virtuellen auf acht physischen Kernen sowie auch hier eine SoC-Variante (Ordos).
Soft Machines - VISC-Architektur
Für die jeweiligen SMP-Varianten verwendet Soft Machines einen eigenen Interconnect zur Verbindung der Prozessoren. Dieser soll in der Lage sein bis zu 200 GB/s zu übertragen. Bisher ist es offenbar nur möglich zwei Chips miteinander zu verbinden. Die SoCs verfügen offenbar über eine PowerVR-Grafikeinheit, einen DDR4-Controller, PCI-Express-Lanes, USB-Ports, Netzwerkschnittstellen und vieles mehr.
[h3]Keine echten Benchmarks[/h3]
Nach all der Theorie ist die Frage berechtigt, wie sich die VISC-Architektur denn nun gegen bestehende Prozessoren darstellt. Doch hierzu werden die Daten, die Soft Machines zur Verfügung stellt eher schwammig. Bisher hat man auf einer Konferenz im Jahre 2014 ein einziges mal funktionierende Hardware präsentiert. Diese wurde in 28 nm gefertigt und lief bei 500 MHz. Da Shasta aber in 16 nm gefertigt werden soll und mit 2 GHz arbeitet, sind diese Zahlen natürlich nicht mehr repräsentativ. Soft Machines kann aktuell aber nur Schätzungen und Hochrechnungen liefern, wie sich Shasta gegen ein Cortex-A72-Design, Apples A9X oder die Skylake-Prozessoren von Intel schlägt.
Soft Machines - VISC-Architektur
Zudem wird von Anandtech die Methodik der Datenerhebung kritisiert, da hier einige Annahmen vorgenommen werden, die sie in der Praxis nicht relevant sind, Insgesamt sind die Zahlen nur schwer zu vergleichen
[h3]16-nm-FinFET-Chips existieren bereits[/h3]
Allerdings müssen Simulationen vermutlich nicht lange eine Diskussionsgrundlade sein, denn Soft Machines hat bereits erste Samples der von 16 nm gefertigten Chips erhalten. Diesen werden nun auf Herz und Nieren geprüft und vermutlich können damit auch realistische Benchmarks erstellt werden. Bei den gelieferten Samples handelt es sich aber zunächst einmal nur um reine Kerne, deren Leistung nun mit den Simulationen abgestimmt werden müssen, um evaluieren zu können, ob Theorie und Wirklichkeit übereinstimmen.
Das letztendliche Ziel ist es, einen Shasta-Kern im 16-nm-FinFET-Prozess bei 2 GHz mit 2 W betreiben zu können. Um hinsichtlich der verschiedenen Produkte möglichst breit aufgestellt zu sein, plant Soft Machines einen Bereich von 0,5 bis 5 W pro Kern abdecken zu können. Damit ließe sich der High-End-Markt bei den Servern ebenso abdecken, wie sparsames SoCs fertigen. Derzeit gibt es aber noch keine Pläne einer Umsetzung durch Partner.
Auf eben diese Partner ist Soft Machines auch angewiesen, denn alleine wird man kaum marktreife Prozessoren fertigen können. Man benötigt die Partner aber nicht nur wegen der Investitionen, sondern auch um den Eintritt in bestimmte Ökosysteme zu erhalten. Netzwerk-Equipment ist ein vielzitiertes Anwendungsgebiet für spezielle Hardware und darauf zielen auch Produkte wie die Opteron-1100-Prozessoren mit ARM-Kernen von AMD oder die Initiative von Intel in China, wo man ebenfalls im Netzwerkbereich Ambitionen hat und dazu Xeon-Prozessoren mit Custom-Hardware koppeln möchte.
In den nächsten 1-2 Jahren wird es vermutlich weiter an nennenswerten Hardware-Umsetzungen fehlen. Für ambitioniertere Ziele ist die VISC-Architektur noch in einem zu frühen Stadium. Allerdings könnten hier gerade die Weichen für viele zukünftige CPU-Architekturen gestellt werden, denn im mobilen Bereich sehen wir die Auswirkungen von Kompromissen zwischen Leistung und Energieeffizienz bereits. Viele Quad- und Octa-Core-Prozessoren verwenden sparsame CPU-Kerne neben solchen die besonders schnell sein sollen. Je nach Anwendungsprofil werden die jeweiligen CPU-Kerne verwendet. NVIDIA hat die Denver-Kerne sicherlich auch zu einem speziellen Zweck entwickelt, der sich nun beispielsweise in Drive PX 2 erkennen lässt. Hier werden Denver-Kerne im SoC verwendet, vermutlich weil eine 7-Wide-Out-of-Order-Pipeline-Architektur hier besonders sinnvoll ist.
So lange wir aber keine ernsthaften Ambitionen eines oder mehrere Hersteller oder eines kompletten Ökosystems sehen, wird die VISC-Architektur ein theoretisches Gebilde bleiben, das allenfalls in zukünftigen CPU-Architekturen eine teilweise Umsetzung finden wird.
Datenschutzhinweis für Youtube
An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen Sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.
Ihr Hardwareluxx-Team
Youtube Videos ab jetzt direkt anzeigen