Die Welt der Programmiersprachen und Compilerentwicklung erlebt gegenwärtig spannende Fortschritte, insbesondere im Bereich der Array-orientierten Sprachen und deren Compiler. Zwei bemerkenswerte Projekte, Hsu's Co-Dfns, ein Compiler für eine Teilmenge von Dyalog APL, und die BQN-Implementierung, liefern sich hier einen fachlichen und technologischen Vergleich. Beide verfolgen das Ziel, effiziente Compiler für Array-Sprachen zu entwickeln, die vor allem durch ihre ganze-Array-Operationen eine neue Art der Parallelisierung und Leistung bieten. Doch trotz gemeinsamer Wurzeln unterscheiden sich diese beiden Projekte in ihrer Herangehensweise und ihrem praktischen Einsatz maßgeblich. Hsu's Co-Dfns wird als ein ambitioniertes akademisches Projekt verstanden, das von Aaron Hsu initiiert wurde und mit dem Ziel einen kompakten, parallelisierten Compiler für APL-Code zu realisieren.
Der Grundgedanke dahinter war, die Möglichkeit zu demonstrieren, einen Compiler vollständig im Stil des Array-Programmierparadigmas zu implementieren – mit einer theoretisch niedrigen parallelen Komplexität. Dabei entstand ein Quellcode, dessen Kernkomponente anhand einer berühmten Grafik aus Hus Ph. D. Arbeit mit nur 17 Zeilen Compilerlogik aufwartet und das gesamte Kompilieren und Scoping-Prozesse innerhalb dieses prägnanten Kerns bündeln konnte. Ein zentrales Element der Co-Dfns Architektur liegt in der Manipulation des abstrakten Syntaxbaums (AST), welcher nicht als klassische Objektstruktur, sondern über Vektoren von Eltern- und Geschwisterindizes repräsentiert wird. Dies zeigt den Versuch, traditionelle Compilerstrukturen in konsequent daten-parallele Strukturen zu überführen. Im Gegensatz dazu steht die BQN-Implementierung, die von denselben Grundgedanken inspiriert wurde, jedoch einen anderen Weg verfolgt.
BQN ist selbst eine komplette Programmiersprache, die unter anderem auch ihren Compiler in einem array-basierten Stil selbst-hosten kann. Anders als Co-Dfns strebt BQN eine praktische und leistungsfähige Anwendung an. Die BQN-Compilerarchitektur verzichtet auf die strikte Trennung von Parsing, Kernkompilierung und Codegenerierung, sondern vermischt diese Schritte unter der Verwendung von flachen, linearen Tokenlisten. Statt expliziter Baumstrukturen nutzt BQN eine Reihe von Reorderings und Scans, die Eigenschaften von Baum-Traversierungen nachbilden. Dieses Vorgehen begrenzt die eingesetzten Operationen auf wenige, sehr performante Array-Primitiven, was das Debuggen erleichtert und den Code übersichtlicher macht. Ein bedeutender Unterschied zeigt sich auch in der Ausrichtung bezüglich Hardware-Unterstützung und Backend-Lösungen. Co-Dfns wurde von Anfang an für die Erzeugung von GPU-Programmen entwickelt.
Die Ausgabe erfolgt in Form von ArrayFire-Code, einem C++ Framework zur GPU-Programmierung, das anschließend kompiliert wird. Aufgrund der Beschränkungen und Herausforderungen des GPU-Programmings sind viele komplexe APL-Funktionalitäten in frühen Versionen von Co-Dfns einschränkend ausgelegt worden und wurden im Laufe der Entwicklung teilweise zurückgeschraubt, insbesondere in Bezug auf Rang-Arbeiten und verschachtelte Arrays. BQN verfolgt vielmehr das Ziel, allgemein balancierte Leistung zu erreichen und unterstützt von Beginn an flexible Datenstrukturen wie Züge (Trains) und lexikalische Closures. Das Backend von BQN besteht aus einer virtuellen Maschine, die Bytecode interpretiert, im Gegensatz zu Co-Dfns, das einen nativen Code für GPUs generiert. Die Optimierungsstrategien beider Compiler unterscheiden sich ebenfalls deutlich.
Während Co-Dfns größtenteils die Optimierung der generierten Array-Funktionsaufrufe und GPU-Programme der zugrundeliegenden ArrayFire-Bibliothek überlässt, werden seit Version 5. 7. 0 klassische Compileroptimierungen wie Dead Code Elimination eingeführt. Co-Dfns setzt mittlerweile auch ein Register-Modell ein, um die Wiederverwendung von Speicherplätzen für kleine Arrays zu ermöglichen, auch wenn der Algorithmus komplizierte Laufzeiten aufweist. BQN hingegen verlässt sich weitgehend auf die Virtual Machine zur Optimierung, wobei variable Lebenszeitanalysen zur Reduktion von Speicherverbrauch implementiert sind, aber auf klassische Optimierungen verzichtet wird. Ein weiterer Punkt, der im Vergleich hervorsticht, ist das Error Reportingsystem. Co-Dfns hat erst im Nachgang seiner Entwicklung ein umfassendes Fehlerbehandlungssystem als Reaktion auf die BQN-Standards aufgebaut.
BQN bietet sehr gute Fehlernachrichten mit präzisem Quellcode-Positions-Tracking, was sich sowohl im Compiler als auch zur Laufzeit auszahlt. Diese Qualität kommt mit einem moderaten Mehraufwand in Codezeilen und Laufzeit, trägt aber wesentlich zur Usability und Wartbarkeit bei. Im Bereich der Dokumentation und Kommentare wird ebenfalls ein Gegensatz deutlich. Aaron Hsu favorisierte in seiner Doktorarbeit eine beinahe vollständige Separation von Code und Kommentaren. BQN-Entwickler hingegen bevorzugen für mehr Übersichtlichkeit und Zugänglichkeit eine Kombination aus kurzen Kommentaren (eine pro Zeile), die in einer kompakten und verständlichen Form die Funktionalität näherbringen. Co-Dfns hat hier auch verschiedene Phasen durchlaufen und sogar literate programming versucht, also umfangreich dokumentierte Codeabschnitte. Die Leistungsfähigkeit der beiden Compiler war lange Zeit ein entscheidender Diskussionspunkt.
Die Co-Dfns Arbeit konnte durch CPU- und GPU-Benchmarking eine bis zu zehnfache Geschwindigkeit gegenüber vergleichbaren nanopass-Systemen zeigen, vor allem bei sehr großen Quellcodes. Die BQN-Implementierung zeigt dagegen in realen Benchmarks sehr gute CPU-Performance, erreicht 15MB/s Quellcodeverarbeitung auf Standardlaptops und ist dabei vergleichbar oder etwas langsamer als manche Java-basierte BQN-Compiler, die speziell optimiert wurden. Wichtig hierbei ist, dass BQN-Komponenten weiterhin sehr gut skalieren und gerade bei kleinen bis mittleren Programmen ein hohes Tempo bieten. GPU-Vorteile wie in Co-Dfns treten in der Praxis kaum in Erscheinung, da die Kompilierrate von BQN schon so schnell ist, dass die Ausführung normalerweise der größere Zeitfaktor ist. Diese Geschwindigkeitsunterschiede spiegeln auch unterschiedliche Zielsetzungen wider. Co-Dfns dient einerseits als Forschungsprojekt zur Machbarkeit der Datenparallelen Compilerentwicklung mit stark vereinfachtem Fokus.
BQN verfolgt das Ziel einer echten, praxistauglichen Programmiersprache mit alltagstauglicher Performance und Flexibilität. Die Realisierbarkeit eines GPU-basierten Compilers für komplexe Sprachen bleibt bei beiden Projekten begrenzt durch technische und theoretische Barrieren. Im Gesamtbild lässt sich die Entwicklung von Hsu's Co-Dfns und BQN als Spiegel niederer und höherer Prioritäten sehen: Co-Dfns zeigt eindrucksvoll die theoretische Machbarkeit und experimentiert mit radikal arrayorientierten Prinzipien; BQN hingegen legt Wert auf einen pragmatischen Ansatz, der durch Designentscheidungen Komplexität eindämmt und dabei ein modernes Programmiersprachen-Ökosystem abbildet. Das bedeutet, dass BQN zwar seinen Ursprung in Co-Dfns hat, sich aber stark weiterentwickelt und spezifisch auf Praktikabilität ausgelegt ist. Ein oft diskutierter Aspekt im Kontext von APL-ähnlichen Compilern betrifft die Rolle von Typisierungssystemen.
Aaron Hsu betrachtet eine klassische, C-ähnliche Typisierung als ungeeignet für Array-Compiler, da nahezu alle Variablen Listen von Zahlen sind. Er favorisiert stattdessen ein System, das die Achseninformation der Arrays statisch überprüft, eine Art "Achsen-Typisierung", die statische Garantien für die Kompatibilität von Operationen liefern würde. Obwohl noch keine allgemeine Lösung etabliert ist, liegt hierin ein mögliches Forschungsfeld, um APL-ähnliche Sprachen und ihre Compiler robuster zu machen. Neben den bestehenden Systemen gibt es weitere Projekte im Feld, wie Pareas, das mit Futhark ausgestattete Compiler für spezielle imperative Sprachen auf GPUs entwickelt. Pareas unterscheidet sich durch den Verzicht auf APL-Syntax und konzentriert sich darauf, systematische generische Methoden anstelle von Speziallösungen zu nutzen.
Obwohl es die Kompilation auf GPUs vorantreibt, zeigt sich auch hier, dass solche Systeme begrenzt sind bei komplexen Sprachen mit anspruchsvoller Syntax und Optimierung. Zur Zukunft von Array-Compilern und solchen Projekten lässt sich sagen, dass sie spannende Einblicke in parallelisierte Compilerarchitektur geben. Dennoch bleibt die praktische Umsetzung extremer Datenparallelität bei allgemeiner Kompilierung komplex und vielfach ineffizient im Vergleich zu klassischen Kompilertypen. Die Hoffnung liegt auf weiteren Konzepten, die den Mittelweg zwischen Flexibilität, Geschwindigkeit und Parallelisierung besser ausbalancieren. Zusammenfassend lässt sich feststellen, dass Hsu's Co-Dfns und BQN zwei unterschiedliche, sich ergänzende Wege zeigen, wie moderne Array-orientierte Compilerentwicklung gestaltet werden kann.
Co-Dfns fungiert als experimentelles Vorbild und Beweis der Machbarkeit, während BQN als pragmatische, weiterentwickelte Implementierung mit Fokus auf Benutzerfreundlichkeit und Alltagstauglichkeit gilt. Entwickler und Forscher, die sich mit Compilerbau, Arraysprachen oder GPU-Programmierung beschäftigen, finden in beiden Projekten wertvolle Impulse und Perspektiven für zukünftige Entwicklungen.
