Mit äußerst breiten Einheiten zum Erfolg

Die Lösung war daher, eine VLIW-basierte ISA samt Mikroarchitektur und Compiler zu kreieren, bei der nachfolgende Instruktionen auf derselben Einheit ablaufen können, die schon für die vorherigen Resultate verantwortlich war. "Bei Workloads für Server-Applikationen oder Integer-Benchmarks wie SpecINT2017 gelingt uns das in 93 Prozent der Fälle, bei den restlichen 7 Prozent müssen wir die Daten weiterreichen", sagt Danilak.

Das klappt ihm zufolge, weil Instruktionen zu etwa 20 Prozent aus Branches und zu 10 Prozent aus Stalls bestehen, die ohnehin auf der jeweiligen Einheit stattfinden. Die restlichen 70 Prozent setzen sich laut Danilak zu zwei Dritteln aus Berechnungen in denselben Registern zusammen, bei denen nur eine dynamische Eingabe vorkommt - was ebenfalls in derselben Einheit durchführbar ist.

Solche Ansätze sind nicht neu, allerdings bei einem VLIW-Design wie dem Prodigy dennoch schwierig zu implementieren. Die von Tachyum entwickelte Befehlssatzarchitektur nutzt eine In-Order-Ausführung, erst der Compiler sorgt für eine Out-of-Order-Execution, wie sie nahezu alle heutigen CPU-Implementierungen verwenden.

Ein CPU-Replacement für Cloud/Hyperscaler-Kunden

Wie gut oder schlecht OoO per Compiler funktioniert, zeigte Intel mit dem in den späteren Jahren gerne als Itanic verspotteten Itanium, der nie wirklich erfolgreich war. Tachyum verweist in der initialen Präsentation von 2018 jedoch auf diese VLIW-Architektur und gibt an, ebenfalls unter der Verwendung sogenannter Poison Bits eine sehr hohe Instruktionen-Level-Parallelität (ILP) in den Recheneinheiten zu erreichen.

• 

Geplant sind 2U-Blades mit vier CPUs und DDR5. (Bild: Tachyum)

Ebenfalls eine Frage der Auslastung sind die Ressourcen, um Daten lokal pro Kern vorzuhalten: "Mit Blick auf Server-Workloads haben wir den L1-Daten- und den L1-Instruktionen-Cache von 32 KByte auf 64 KByte verdoppelt, beim L2-Puffer sind wir von 512 KByte auf 1 MByte hoch", erläutert Danilak. Beim L3-Victim-Cache hat sich Tachyum für eine dynamische Lösung entschieden, die ein wenig an die virtuelle dritte Pufferstufe von IBMs Telum (z16) erinnert: "Der L3 ist quasi der L2, inaktive Kerne geben ihre Ressourcen ab", legt der CEO offen.

Hinzu kommt, dass Tachyum äußerst breite Rechenwerke verwendet, auch weil sich der Zielmarkt für Prodigy im Laufe der Jahre etwas verschoben hat. "Wir sind ein CPU-Ersatz- und kein KI-Beschleuniger-Unternehmen, wir zielen auf Cloud/Hyperscaler sowie Telcos ab", sagt Danilak mit Blick auf das Marktumfeld, ergänzt aber später: "Über die Zeit konnten wir einige Supercomputer-Kunden gewinnen, daher haben wir die Breite der Vector/MAC-Einheiten von 512 Bit auf 1.024 Bit verdoppelt." Der eigentliche Grund aber waren die notwendigen Datenpfade für die 4.096-Bit-Matrix-Operationen für künstliche Intelligenz.

Eine weitere Änderung seit der Präsentation auf der Linley Conference 2018 (PDF) betrifft die Pipeline-Stufen für Integer und Vector, die erweitert sowie modifiziert wurden: "Zwischen Instruction-Fetch und Decode gibt es eine Stage mehr zugunsten höherer Taktraten, auch füttern Load/Store nicht mehr direkt die ALUs; das reduziert die Stages und die Leistungsaufnahme", sagt Danilak. Das ist wichtig für die Performance, die sehr hoch ausfällt.