Der weltweit stromsparendste Prozessor, der die herkömmlichen allgemeinen CPU auf den Kopf stellt, wird offiziell vorgestellt.

Seit mehreren Jahrzehnten bauen wir allgemeine CPUs auf die falsche Weise – so lautet die kühne Aussage des Teams von Efficient Computer. Aus diesem Grund haben sie heute ihr erstes Produkt, den E1-Prozessor, offiziell vorgestellt und hoffen, eine neue Ära der Effizienz in der allgemeinen Rechnung einzuläuten.

Efficient Computer erklärt. Dies ist ein universeller Prozessor, der die seit langem bestehende Abhängigkeit der Branche von der von-Neumann-Architektur grundlegend umstößt. Abgesehen davon, dass es das erste eigenständige Hardwareprodukt von Efficient Computer ist, ist ein weiterer bemerkenswerter Aspekt dieses Chips, dass das Unternehmen ihn als „weltweit energieeffizientesten universellen Prozessor“ bezeichnet.

Dem Bericht zufolge verbraucht der Electron E1-Prozessor im Gegensatz zu herkömmlichen von-Neumann-Prozessoren, die beim Transfer von Daten zwischen Speicher und Rechenkern zu viel Energie verbrauchen, aufbauend auf Efficient's Fabric-Architektur – einer räumlichen Datenflussarchitektur zur Ausführung allgemeiner Code, die auf kostspielige schrittweise Berechnungen verzichtet. Im Vergleich zu herkömmlichen Niedrigleistungs-CPUs kann diese Methode die Energieeffizienz um bis zu 100 Mal steigern, sodass an der Edge eingesetzte intelligente Anwendungen auch in Umgebungen mit eingeschränkter Stromversorgung und Wartung eine Lebensdauer von mehreren Jahren haben können.

Das Anliegen des Unternehmens: Enttäuschung über herkömmliche CPUs

Efficient Computer gibt direkt an, dass das Team seiner Ingenieure und Entwickler von den Einschränkungen herkömmlicher von-Neumann-Prozessoren stark enttäuscht ist, da diese Prozessoren beim Transfer von Daten zwischen Speicher und Rechenkern zu viel Energie verbrauchen. Wir wissen, dass es zur Erreichung echter Effizienz notwendig ist, die Art und Weise, wie Prozessoren konzipiert werden, grundlegend neu zu überdenken.

Wie sie sagen, waren unsere Prozessoren seit langem an das Kontrollflussmodell gebunden und haben ständig Daten zwischen Cache, Speicher und Recheneinheiten hin- und hergeschoben – ich denke, alle stimmen darin überein, dass jeder Schritt dieses Prozesses eine Menge Energie verbraucht. Tatsächlich verbrauchen CPUs derzeit schon beim Verschieben von Daten zu viel Energie, manchmal sogar mehr als für die Verarbeitung der Daten erforderlich ist. Die herkömmliche Architektur legt den Schwerpunkt auf Leistung, Stromverbrauch oder Stromverbrauch pro Einzeloperation und vernachlässigt oft die Kosten für das Datenverschieben. Dies ist gerade der Engpass bei strombegrenzten eingebetteten Systemen oder Systemen, die mit kleinen benutzerdefinierten Batterien oder Batterien betrieben werden.

Dem Bericht zufolge steht dem modernen Computersystem eine grundlegende Abwägung gegenüber: Die Erreichung maximaler Energieeffizienz geht oft auf Kosten der universellen Programmierbarkeit. Der Grund dafür ist, dass in modernen Architekturen das Datenverschieben (und nicht die Berechnung) der Hauptengpass für Energie, Leistung und Skalierbarkeit ist. Daher bedeutet die Erreichung hoher Effizienz, dass möglichst viel Rechenarbeit in der Nähe des Speicherzugriffs durchgeführt wird.

Wie in der Abbildung gezeigt, gehen heutige Systeme, einschließlich CPU, GPU und anderer programmierbarer Beschleuniger, diesem Problem durch die Verwendung verteilter Datenspeicher zwischen den Verarbeitungseinheiten (PE) entgegen (siehe NUMA-Diagramm). Die Idee besteht darin, vorab zu bestimmen, welche Programmdaten auf welchen Speicher abgebildet werden sollen und wie die Aufgaben an die PE in der Nähe jedes entsprechenden Speichers verteilt werden sollen. Diese Methode wird allgemein als Nichtgleichförmiger Speicherzugriff (NUMA) bezeichnet, da verschiedene Speicher unterschiedliche (d. h. nicht gleichförmige) Zugriffszeiten auf verschiedene Prozessoren haben.

NUMA allein kann Effizienz und Universalität nicht ausbalancieren. Abgesehen von den einfachsten Programmen ist die Bestimmung, wie Daten und Aufgaben koordiniert geplant werden sollen, für Compiler und Systeme fast unlösbar. Workloads mit unregelmäßigen Rechenmustern (z. B. sparse maschinelle Lernmodelle) sind schwer zu analysieren, und selbst bei vollständigen Informationen kann möglicherweise nicht durch die Datenabbildung eine deutliche Reduzierung des Datenverschiebens erreicht werden. Eine andere gängige Methode besteht darin, die Last auf die Programmierer zu verlagern, indem domänenspezifische Sprachen oder Low-Level-APIs verwendet werden. Dies geht jedoch auf Kosten der Universalität und beschränkt die Anwendbarkeit.

Es ist bekannt, dass herkömmliche Prozessoren sequenzielle Operationen über Branch-Prediction ausführen und zwischen jeder Operation der Prozessor auf den dem Verarbeitungspipeline benachbarten Speicher verweisen und Konfigurationsänderungen vornehmen muss. Laut dem CEO und Mitbegründer von Efficient Computer: „In jedem Zyklus führst du Milliarden solcher Operationen pro Sekunde aus; das ist sehr verschwenderisch.“

Deshalb haben sie bei dem Electron E1-Prozessor einen anderen Ansatz gewählt. Basierend auf zehnjähriger Forschung an der Carnegie Mellon University haben wir die Fabric-Architektur von Grund auf neu entwickelt, um die Energieeffizienz bei allgemeinen Rechenanwendungen deutlich zu verbessern.

Der E1 basiert auf einer proprietären räumlichen Datenflussarchitektur namens Fabric, die die mit der Befehlsextraktion, -dekodierung und -verschiebung im Registerfile verbundenen Kosten beseitigt. Laut Efficient erreicht diese Konstruktion in einem Chip, der vollständige Software-Programmierbarkeit und universelle Anwendbarkeit behält, eine bisher nie erreichte Energieeffizienz und kann bis zu 1 Billion 8-Bit-Ganzzahloperationen pro Sekunde und Watt ausführen (1 TOPS/W).

„Wenn du dem Computer sagt, X plus Y zu berechnen, geht 95 % bis 99 % des Energieverbrauchs für die Befehlszuführung, -dekodierung, -pipelineumkonfiguration und -operandenzuführung verloren. Nur 1 % bis 5 % des Energieverbrauchs wird tatsächlich für die Ausführung der Addition verwendet.“ so der Gründer der Firma, Lucia.

Die Datenflussarchitektur: Das Wesen des Durchbruchs

Der Electron E1-Prozessor basiert auf dieser räumlichen Datenflussarchitektur und kann allgemeinen Code ausführen, ohne kostspielige schrittweise Berechnungen durchführen zu müssen. Efficient's Ziel ist es, dieses Problem durch statische Planung und Datenflusskontrolle zu lösen – nicht durch Puffern, sondern durch Ausführen. Er hat keinen Cache, keine Out-of-Order-Architektur, aber er ist auch keine VLIW- oder DSP-Architektur. Er ist ein universeller Prozessor.

Wenn die meisten Menschen von einem „Niedrigleistungs-Chip“ oder einem „eingebetteten CPU“ hören, denken sie an einen sequenziell arbeitenden ARM Cortex-M oder einen etwas leistungsstärkeren Prozessor mit einer Architektur, die Out-of-Order-Befehle ausführen kann und über genügend On-Chip-Speicher oder etwas Off-Chip-DRAM verfügt. Das Modell ist einfach: Ein kleiner Prozessor holt, dekodiert, sortiert, plant, führt nacheinander Befehle aus und lässt sie die Pipeline verlassen und verschiebt Daten nach Bedarf in den Speicher und aus ihm heraus.

Efficients Architektur, kurz „Fabric“ genannt, basiert auf einem räumlichen Datenflussmodell. Die Befehle des E1 werden nicht über eine zentrale Pipeline geleitet, sondern an bestimmte Rechenknoten, sogenannte „Tiles“, gebunden, und dann fließen die Daten zwischen ihnen. Erst wenn alle Operandenregister eines Knotens (z. B. eines Multiplizierers) gefüllt sind, verarbeitet der Knoten seine Operanden. Das Ergebnis wird dann an das nächste „Tile“ weitergeleitet, das es benötigt. Er hat keinen Programmzähler und keinen globalen Planer. Es wird behauptet, dass dieses native Datenflussausführungsmodell die Energieverschwendung, die herkömmliche CPUs beim Datenverschieben verursachen, erheblich reduzieren kann.

Der Electron E1 ist im Wesentlichen ein Netzwerk aus kleinen Rechenblöcken, von denen jeder grundlegende Operationen wie Mathematik, Logik und Speicherzugriff ausführen kann. Der Compiler plant statisch jedes Tile, sodass es seinen Anforderungen entspricht, und leitet die Daten. Der Efficient-Compiler wandelt C++- oder Rust-Code in einen Datenflussgraphen um – das ist der Kernpunkt hier. Da er normalen C++- oder Rust-Code ausführen kann, bezeichnet Efficient ihn als universellen CPU.

Natürlich bringt dies auch Herausforderungen mit sich. Was passiert, wenn dein Programmdiagramm für den Chip zu groß ist? Efficient hat dieses Problem durch die Pipelineumkonfiguration gelöst – der Compiler teilt das Programmdiagramm in mehrere Blöcke auf, und der Chip lädt während der Ausführung dynamisch neue Konfigurationen. Jeder Block enthält sogar einen kleinen Cache für die jüngsten Konfigurationen, sodass Schleifen und wiederholte Muster nicht jedes Mal vollständig neu geladen werden müssen.

Die Verbindung zwischen den Tiles ist ebenfalls statisch geroutet und pufferspeicherfrei und wird zur Kompilierzeit festgelegt. Da es keine Verkehrskontrolle oder Wiederholungslogik gibt, muss der Compiler zur Kompilierzeit Konflikte zwischen zwei Datenpfaden lösen. Dies ermöglicht es der Fabric, eine sehr hohe Energieeffizienz zu erreichen, verschiebt aber auch viele Verantwortlichkeiten an die Toolchain. Die Abhängigkeit von einem „perfekten“ Compiler war schon immer ein Problem in der herkömmlichen Computertechnik, daher wird es sehr interessant sein, zu sehen, wie dieses Konzept funktioniert.

Ein bedeutendes Meilenstein für den ersten Kandidaten-Chip des Electron E1 ist die Unterstützung von 32-Bit-Gleitkommaoperationen. Viele Niedrigleistungsarchitekturen unterstützen nur Ganzzahloperationen und arbeiten mit Festkommaarithmetik. Professor Brandon Lucia, der CEO, betont, dass 32-Bit für die Skalierbarkeit dieser Architektur von entscheidender Bedeutung sind.

Wichtig ist, dass dies kein softwareemulierter Datenfluss ist; die Hardware ist als Datenflussmotor konzipiert. Es bleibt abzuwarten, ob diese Architektur flexibel genug ist, um sich an reale eingebettete Software anzupassen, oder ob es zu vielen Randfällen kommt. Architektonisch gesehen weicht sie stark von der herkömmlichen CPU-Architektur ab, behauptet aber dennoch „universell“ zu sein. So sollen die Vorteile bei der Energieeffizienz liegen.

Physikalisch gesehen wird der Electron E1 in einer Standard-BGA-Verpackung geliefert und integriert On-Chip-Speicher und Peripherieschnittstellen, um die externe Abhängigkeit zu minimieren. Er enthält 4 MB MRAM (für nichtflüchtigen Code- und Datenspeicher), sowie 3 MB SRAM und 128 KB Cache. Der Chip unterstützt sechs Instanzen von QSPI-, UART-, SPI-Slave-Schnittstellen und I2C-Master-Schnittstellen sowie 72 GPIO-Leitungen und eine Echtzeituhr.

Was die Leistung betrifft, bietet der E1 zwei Arbeitsmodi: Im Niederspannungsmodus kann er bei einer Fabric-Taktfrequenz von 25 MHz 6 GOPS erreichen; im Hochspannungsmodus kann er bei einer Taktfrequenz von 100 MHz bis zu 24 GOPS erreichen. Ein programmierbarer Wake-Up-Controller sowie integrierte Step-Down-Regler und LDO-Regler unterstützen dynamische Energieverbrauchsmodelle, einschließlich des Schlaf- und Tiefschlafmodus.

Der aktive skalare RISC-V-Kern des Chips kann in den stromlosen Zustand versetzt werden, während die Fabric weiterhin arbeitet.

Der E1 wird mit einer Spannung von 1,8 V versorgt, die interne Logikspannung liegt zwischen 0,55 V und 0,8 V, und die Nennbetriebstemperatur liegt zwischen -40 °C und 125 °C.

Der Electron E1 unterstützt auch die volle Programmierbarkeit des gesamten Stacks, indem normaler Code in einen Datenflussgraphen kompiliert und auf der gesamten Fabric-Architektur verteilt wird. Dabei bleibt das System deterministisch und statisch geplant, und der kompilierte Code kann bis zu 100 Millionen Mal langfristig ausgeführt werden.

Die Software-Stack: Ein weiterer Kernpunkt dahinter

Neben dem E1 hat Efficient auch die erste öffentliche Version seiner Compiler-Toolchain effcc veröffentlicht, die die einzigartige Hardware abstrahiert und Standard-Entwicklungs-Schnittstellen nutzt. Dieser Compiler basiert auf LLVM und MLIR und kann Standard-C-Code verarbeiten und mit minimalen Änderungen in den bestehenden Entwicklungsworkflow integriert werden. Entwickler können einfach auf die neue Compiler-Datei verweisen und dann gängige Build-Tools wie Make und CMake sowie Editoren wie Visual Studio Code verwenden.

Dadurch bleibt die Kompatibilität mit den Debugging-Tools und Workflows, mit denen die Ingenieure bereits vertraut sind, gewährleistet. Wie Lucia sagt: „Du verwendest einfach effcc, und es funktioniert wie Clang an der Front-End-Ebene... Wenn du VS Code, Make oder CMake verwendest, musst du ihm nur sagen, wo unser Compiler liegt, und dann funktioniert alles einwandfrei.“

Der Compiler verwendet Clang an der Front-End-Ebene, und in der Mitte wandelt Efficient die Eingabe in eine für die Fabric angepasste Zwischenrepräsentation um. Hochwertige Optimierungsroutinen (einschließlich eines auf KI basierten Planungsframeworks, dem modularen Optimierungsframework (MOF)) analysieren die Code-Struktur und legen sie effizient auf das räumliche Netzwerk ab. Dies umfasst die automatische Weiterleitung der Befehlsausgabe an die nachgelagerten Blöcke sowie die Optimierung der Datenflusswege, um die Latenz und den Stromverbrauch zu minimieren.

Mit diesen Tools können Entwickler auf einer webbasierten Playground-Umgebung die Ausführung simulieren, die eine interaktive Visualisierung der Befehlsausbreitung in der Fabric enthält. Das Unternehmen betont die Entwicklungsumgebung mit einer „zweiminütigen Hello-World-Erfahrung“ und hat fast die Lernkurve für die neue Plattform beseitigt.

Daraus lässt sich erkennen, dass der Electron E1 Standard-Tools verwendet; der Compiler-Front-End basiert auf Clang und unterstützt die oben genannten C++- und Rust-Sprachen. Sie sagen auch, dass sie Machine-Learning-Frameworks wie PyTorch, TensorFlow und JAX unterstützen, obwohl der Grad der manuellen Intervention, der zur Aktivierung dieser Frameworks erforderlich ist, noch nicht klar ist.

Bisher war ihre