Scheidungsantrag von LLVM

 (github.com/ziglang)
2 Punkte von GN⁺ 2023-07-01 | 2 Kommentare | Auf WhatsApp teilen
  • Das Zig-Projekt verfolgt das Ziel, die Abhängigkeiten von den Bibliotheken LLVM, Clang und LLD vollständig aus der zentralen zig-Executable zu entfernen.
  • Die verbleibenden Arbeiten gliedern sich in die Entfernung von LLD, die Beseitigung von LLVM-API-Aufrufen, Fortschritte bei den Backends für C/x86/wasm/aarch64, das Entfernen von Clang-abhängigen Unterbefehlen und Präprozessor-Nutzung sowie die Implementierung eines Ersatzes für zig ar.
  • Das LLVM-Backend kann bereits .bc-Dateien ausgeben, aber der Zig-Compiler wird keine Funktion mehr besitzen, .bc in Objektdateien zu kompilieren; dafür ist dann eine separate Clang-Installation erforderlich.
  • Als erwartete Effekte werden eine Vereinfachung von Source-Builds und Bootstrap, das Umgehen von LLVM-/Clang-/LLD-bezogenen Problemen in Linux-Distributionen und Homebrew sowie eine Verringerung der Binärgröße von etwa 150 MiB auf 5 MiB genannt.
  • Als Richtung wird ausgegeben, dass Zig eigene Optimierungspässe implementieren und direkte Beiträge von Forschungsprojekten wie alive2 sowie von Chipherstellern wie Intel, ARM und RISC-V anziehen könnte.

Abhängigkeiten, die aus der Zig-Executable entfernt werden sollen

  • Das Ziel dieses Issues ist es, die Bibliotheken LLVM, Clang und LLD vollständig aus dem Zig-Projekt zu entfernen.
  • Die verbleibenden Berührungspunkte lassen sich in die Bereiche LLD, LLVM, Clang und zig ar einteilen.

Verbleibende Arbeiten rund um LLD

Verbleibende Arbeiten rund um LLVM

Verbleibende Arbeiten rund um Clang

Einschränkungen bei zig ar und der Verarbeitung von .bc-Dateien

  • zig ar: a drop-in llvm-ar replacement #9828: Die Arbeit, zig ar zu einem Ersatz für llvm-ar zu machen, steht noch aus.
  • Das LLVM-Backend gibt bereits .bc-Dateien aus, aber der Zig-Compiler wird keine Funktion mehr besitzen, .bc-Dateien in Objektdateien zu kompilieren.
  • Um diesen Anwendungsfall abzudecken, muss Clang separat installiert werden.

Erwartete Veränderungen durch das Entfernen der Abhängigkeiten

  • Alle Zig-seitigen Bugs fallen vollständig in den Verantwortungsbereich des Zig-Projekts.
  • Der Prozess, den Compiler aus dem Source zu bauen und zu bootstrappen, wird einfacher; auf dem Host-System wird nur noch ein C-Compiler benötigt.
  • Linux-Distributionen und Paketmanager wie Homebrew müssen sich nicht mehr mit den Problemen beschäftigen, die sie rund um LLVM, Clang und LLD verursacht haben.
  • Die Größe des Zig-Compiler-Binaries sinkt von etwa 150 MiB auf 5 MiB.
  • Die Kompiliergeschwindigkeit könnte sich um mehrere Größenordnungen verbessern.
  • Zig könnte eigene Optimierungspässe implementieren und damit den aktuellen Stand des Computings vorantreiben.
  • Forschungsprojekte wie alive2 könnten eingebunden werden.
  • Direkte Beiträge von Interessengruppen wie Intel, ARM und RISC-V-Chipherstellern, die besseren Maschinencode für ihre CPUs wollen, könnten gefördert werden.

Verwandte Beiträge

2 Kommentare

 
alstjr7375 2023-07-02

Wird damit eine Optimierung und Plattformunterstützung wie bei LLVM überhaupt möglich sein..
 
GN⁺ 2023-07-01
Hacker-News-Kommentare

  • Andrew ist so scharfsinnig, dass das Team es am Ende wohl schaffen wird, wenn es erst einmal als Ziel ausgerufen wurde.
    Aus der Sicht von jemandem, der Zigs Schwierigkeiten mit LLVM nicht gut kennt, wirkt diese Entscheidung aber so, als würde die Teamkapazität von Zig selbst auf Werkzeuge im Umfeld wie binutils umgelenkt.
    Als ich nur die Überschrift gesehen habe, dachte ich erst, sie würden den Compiler aufgeben, und bei einem Projekt wie Zig scheint es auch viel zu geben, was man durch das Beibehalten von LLVM gewinnt.
    Trotzdem ist die Vorstellung, große Teile des Codes in LLVM nicht in C++, sondern in Zig neu zu schreiben, ziemlich cool und ehrgeizig. Man könnte sogar sagen, so ehrgeizig wie Lattners Versuch, LLVM überhaupt erst zu schaffen.
    Code, der versehentlich quadratische Zeitkomplexität hat, wird Zig aber wohl genauso schwer vermeiden können, sobald es ähnlich populär und nützlich wie LLVM wird.

    • Das erinnert mich an einen Satz aus einem Text, der wie ein inoffizielles NASA-Dokument zum Projektmanagement wirkte.
      Sinngemäß hieß es dort: „Wenn eine Weltraummission keinen bestehenden Träger wiederverwendet, dann wird das Projekt zu einem Trägerentwicklungsprojekt, und alles andere, was man für den Kern der Mission hielt, wird zur Nebensache.“
      Zusätzlich meine ich mich zu erinnern, dass es mit der Annahme eingeleitet wurde: „Statt sich an einen bestehenden Träger anzupassen, könnte man meinen, es sei billiger und effizienter, einen speziell für die Mission passenden Träger zu bauen.“
    • Das erinnert mich an ein jüngeres Interview mit Chris Lattner über den Erfolg von Swift. Er sah einen Erfolgsfaktor darin, dass man Swift nach und nach in große Objective-C-Projekte einmischen konnte, ohne irgendetwas neu schreiben zu müssen.
      Ein Teil des Erfolgs von Rust beruht ebenfalls auf ähnlicher Kompatibilität mit C/C++.
      Ich kann mir schwer vorstellen, dass Zig ohne eine ähnliche Fähigkeit erfolgreich wird, und hoffe deshalb, dass sie diesen Meilenstein nicht einfach so durchdrücken.
    • Das unterscheidet sich stark von LLVM. Zumindest in dem Kontext, in dem Apple das Projekt übernahm, gab es kaum Alternativen.
      GCC war nicht bereit, das zu erlauben oder umzusetzen, was Apple wollte oder brauchte.
    • Es wurde nicht als „Ziel“ festgelegt. Es ist bislang nur ein nicht angenommener Vorschlag.
    • binutils ist eher ein allgemeines Paket zur portablen Behandlung binärer Codeformate, und ein Compiler braucht davon nicht die Hälfte, insbesondere nicht den Legacy-Teil.
      Mit einem fokussierteren Ansatz wie bei TCC würde der Großteil wohl in die Codegenerierung für verschiedene Architekturen fließen.

  • Hier gibt es zwei Probleme. Das eine ist Codegenerierung, das andere Bootstrapping.
    Meiner Erfahrung nach sind Optimierungspässe in Compilern leicht zu schreiben und machen Spaß. Man muss zwar Paper lesen, um Registerallokation und SSA-Form zu verstehen, aber Code, der IR durch mehrere Optimierungspässe schickt und dabei Schritt für Schritt verbessert, lässt sich unterhaltsam schreiben.
    Hochwertige Optimierungspässe kann man auch ohne LLVM bauen. Aber der Schritt, in dem IR in Maschinencode linearisiert wird, ist langweilige Routinearbeit, sofern man nicht alle möglichen Arten liebt, wie x86-32/64 einen Befehl wie „mov [eax+8*ebx], 123“ encodieren kann.
    Wenn man die Binärgröße optimieren will, möchte man dann wirklich für jede Plattform messen, ob „push eax; push eax; push eax“ kürzer ist als „add rsp,12“? Das ist nur x86, und multipliziert man das mit den Nicht-x86-Architekturen, die für die meisten Entwickler noch weniger wichtig sind, wird es deutlich größer.
    Es ist außerdem sehr wahrscheinlich, dass schwere Bugs in Codegeneratoren für selten genutzte Architekturen jahrelang unentdeckt bleiben.
    Das zweite ist Bootstrapping. Womit kompiliert man einen in Zig geschriebenen Zig-Compiler? Man könnte zum Beispiel einen nicht optimierenden minimalen Zig-Compiler in C schreiben und damit den Zig-Compiler kompilieren.
    Wenn dieser aber nicht optimiert, muss man den Zig-Compiler anschließend noch einmal mit einem optimierenden Zig-Compiler neu kompilieren. Das ist kein unlösbares Problem, aber lange und komplexe Build-Prozesse können potenzielle Mitwirkende abschrecken.

    • Dieser Artikel scheint das Bootstrapping-Problem zu behandeln: https://ziglang.org/news/goodbye-cpp/
    • Zig bootstrapped bereits über ein C-Backend, daher ist das zweite Problem kein Problem.

  • Nachdem Zig so stark damit beworben wurde, dass es C und vielleicht sogar C++ kompilieren kann, wirkt es ziemlich radikal, jetzt LLVM komplett herauszunehmen.
    Es erscheint auch sehr unwahrscheinlich, dass man auch nur annähernd an LLVMs Plattformunterstützung herankommt, sofern nicht sehr viel mehr Leute an der Unterstützung mitarbeiten.
    Ich kann verstehen, dass man für Interessierte ein eigenes Backend hinzufügen will, aber LLVM einfach zu entfernen, wirkt überstürzt.

    • Wenn die Arbeit bereits begonnen hätte, könnte es überstürzt sein, aber wie bei anderen Vorschlägen ohne das Label „accepted“ im Issue-Tracker geht es derzeit nur darum, Diskussionen und Gegenvorschläge einzuholen.
      Im Moment sammelt das Team Feedback, lernt betroffene Use Cases kennen und schätzt die Machbarkeit ab; das ist eher das Gegenteil von Überstürzung.
    • Wenn man den Haupttext des verlinkten Issues liest, geht es nicht darum, das LLVM-Backend vollständig zu entfernen. Es wird nur vom Haupt-Binary getrennt; wenn LLVM auf dem System installiert ist, kann es weiterhin leicht als Backend verwendet werden.
      Es ist ohnehin etwas seltsam, in der Standardkonfiguration eine 100+ MB große LLVM-Kopie mitzubündeln, obwohl sie im allgemeinen Fall gar nicht nötig ist. Wer entwickelt, hat LLVM oft sowieso installiert.
      Allerdings könnte es schwierig sein zu garantieren, dass die installierte Zig-Version mit der LLVM-Version des Systems sauber funktioniert. Das muss man beobachten.
    • Es erzeugt weiterhin LLVM-Bitcode, hängt aber nicht länger von den LLVM-Bibliotheken ab.
      https://github.com/ziglang/zig/issues/13265
    • Ich habe es auch genau so verstanden.
      Ich habe mich vor Kurzem etwas mehr mit Zig beschäftigt und es auch als einfache Methode benutzt, C++ mit LLVM zu kompilieren, ohne mich mit Systempaketen herumzuschlagen. Dass man von C/C++ zu Zig wechseln kann, war ein starkes Verkaufsargument.
      Es wirkt sehr plötzlich und unerwartet. Ich weiß nicht, ob es für das Projekt richtig oder falsch ist, aber aus meiner Sicht fühlt es sich wirklich aus heiterem Himmel an.
    • Ich nutze Zig in einem Rust-Projekt als C++-Compiler. Für Cross-Compilation in GitHub Actions war das der am wenigsten schmerzhafte Weg.

  • Einerseits respektiere ich den sorgfältigen Willen, Abhängigkeiten zu reduzieren, aber der Preis dafür wirkt ziemlich hoch.
    Der Verlust der C++-Kompatibilität würde einen der Vorteile faktisch beseitigen, den Zig-Fans in meinem Umfeld am häufigsten erwähnt haben.
    Ein Performance-Verlust, selbst wenn er nur vorübergehend wäre, ist ebenfalls ein weiterer zentraler Punkt, den sie immer wieder genannt haben.

    • Die meisten Reaktionen scheinen gegen diesen Vorschlag zu sein.
      Für Leute, die nur querlesen: Das ist keine beschlossene Sache, sondern ein Vorschlag.

  • Ich habe rund vier Jahre lang sämtliche Embedded-Projekte und Bibliotheken komplett in Zig geschrieben, und jetzt fallen mehrere Tier-1-unterstützte Architekturen einfach weg?
    Es ist zwar ihre Sprache und sie können damit machen, was sie wollen, aber dann sollten sie das Branding bitte auch entsprechend anpassen.

    • Fallen die wirklich weg?
      Vermutlich wird sich Tier-1-Support in zwei Kategorien aufteilen: eingebauter Tier-1-Support und Tier-1-Support über ein optionales LLVM-Backend.
      Wenn eine Architektur bereits Tier-1-Support hat, sehe ich keinen Grund, warum dieser verloren gehen sollte, nur weil das LLVM-Backend zu einer optionalen Abhängigkeit wird.
      Wie Andrew im Vorschlag schrieb, könnte das sogar ein Weg sein, seltenere Architekturen besser zu unterstützen. An einem Zig-Backend für interessante Prozessorarchitekturen würde ich gern mitarbeiten, aber zu LLVM würde ich niemals beitragen. Mit C++ zu arbeiten ist nichts, was ich als Hobby machen würde.
    • Soll LLVM rausgeworfen werden, während man alles, was LLVM macht, auf eigene Weise neu implementiert?
      Was wäre denn der Vorteil davon? Ist das nicht Verschwendung von Ressourcen?
    • Dass Zig noch vor 1.0 ist, ist kein Geheimnis. Man kann ihnen dafür nicht die ganze Verantwortung aufladen, aber es wirkt trotzdem wie ein ziemlich radikaler Vorschlag.
    • Es ist bislang nur ein Vorschlag. Das GitHub-Issue dient vor allem dazu, Anwendungsfälle für und gegen den Vorschlag zu sammeln, und ist nicht angenommen.
    • Da es noch ein Vorschlag ist, denke ich, dass das Core-Team den Ansatz anpassen wird, wenn genug Leute Rückmeldung geben, so wie es ja bereits viele tun.

  • DLang hat drei Compiler.
    gdc basiert auf dem Backend der GNU Compiler Collection, ldc auf dem LLVM-Backend und dmd auf dem x86-Codegenerator, den ich für Zortech/Symantec/Digital Mars geschrieben habe.
    Jeder hat andere Vor- und Nachteile und andere Zielsetzungen, aber sie unterstützen dieselbe D-Sprache.
    Insgesamt mögen Nutzer Auswahlmöglichkeiten, und manche verwenden sogar mehr als einen davon.

    • Da gibt es einen interessanten Unterschied im Ansatz. Bei D scheint es wirklich getrennte Compiler zu geben, während Zig offenbar in die Richtung geht, dass der Hauptcompiler von Zig LLVM als Backend unterstützt, wenn es installiert ist.
      Falls das so stimmt, gefällt mir der Ansatz von Zig.
    • Eine weitere Sprache mit mehreren Compilern ist Common Lisp. Es gibt ungefähr zehn produktionsreife Compiler, einige kommerziell, die meisten aber kostenlos.
      Das ist sehr nützlich, weil man während der Entwicklung den schnellsten Compiler verwenden kann und für den finalen Release den mit der schnellsten Laufzeit oder dem geringsten Speicherverbrauch.
      Wenn es außerdem eine Sprachspezifikation gibt, der alle Compiler folgen, hat man die Sicherheit, dass die Sprache stabil ist und einem nicht plötzlich unter den Füßen wegbricht.
      Natürlich hat auch eine Sprache wie Zig Vorteile, bei der man Dinge noch ändern kann, um sie konsistenter, sauberer und mächtiger zu machen. Inzwischen schätze ich diese Art von Stabilität aber deutlich mehr, weil man sich dann darauf konzentrieren kann, echten Mehrwert für Nutzer zu schaffen, statt ständig den Entwicklungswerkzeugen hinterherzulaufen.
    • Für fortgeschrittene Nutzer ist Auswahl ein Vorteil, aber wählen zu müssen ist an sich ein großer Nachteil.
    • Ich verstehe, dass Nutzer Auswahl mögen, aber wenn Zig langfristig auf breite Akzeptanz abzielt, dann ist DLang meiner Meinung nach kein gutes Vorbild.

  • Einer der Hauptgründe, warum Zig interessant war, war die Möglichkeit, es direkt als Ersatz für einen C/C++-Compiler einzusetzen.
    Freunde haben mir gesagt, dass Zig sich unter Windows leichter als C/C++-Compiler installieren lässt als jede andere Alternative.
    Wenn dieser Vorschlag angenommen wird, glaube ich persönlich, dass Zigs Popularität auf das Niveau von Hare oder anderen extremen Nischensprachen sinken wird.
    Um Kollegen überhaupt dazu zu bringen, Zig einmal auszuprobieren, musste ich ihnen sogar Artikel schicken, dass Uber es in der Produktion einsetzt. Ohne unmittelbaren Nutzen für bestehende Projekte hätten sie nicht einmal zweimal darüber nachgedacht.
    Trotzdem verstehe ich den Hintergrund des Vorschlags. LLVM-Kompilierzeiten können furchtbar sein, und mit einem eigenen Bytecode könnte man auch coole Optimierungstechniken umsetzen. Sich mit LLVM-Bugs herumzuschlagen ist praktisch eine Aufgabe, die man kaum anfassen möchte, und ich habe so etwas auch im Julia-Ökosystem gesehen.
    Falls meine Empfehlung irgendetwas wert ist, dann sollte Zig meiner Meinung nach 1) für Debug-Builds benutzerdefinierten Bytecode für schnelles Bauen und schnelles Debugging verwenden und 2) für Release-Builds LLVM für schnelle Laufzeitleistung nutzen.
    Wenn sich 1) umsetzen ließe und zugleich die C/C++-Cross-Compile-Unterstützung erhalten bliebe, etwa indem nur dieser Teil an LLVM übergeben wird, dann wäre das trotz des Trade-offs, zusätzlich Backend-Code pflegen zu müssen, vielleicht der beste Kompromiss.

    • Als jemand, der im Julia-Ökosystem zu den Leuten gehört, die sich mit LLVM-Bugs befassen: ja.
      Dafür braucht man ein eigenes Kompetenzprofil, das sich von der Arbeit am High-Level-Julia-Compiler unterscheidet, und manchmal dauert es lange, bis Bugfixes upstream übernommen werden.
      In der Praxis haben wir aber ein ziemlich gutes und produktives Verhältnis zum Upstream, und wenn wir beschlossen hätten, LLVM loszuwerden, hätte das Projekt viel weniger erreicht.
      Vor allem GPU-Unterstützung und HPC-Unterstützung, etwa für PPC, hängen von LLVM ab.
      Deshalb bleiben wir bei der Position, Julia gegen unseren Patchsatz/Fork zu bauen, und investieren keine Zeit in Bugs, die in Julia-Builds ohne diese Patches auftreten. Das passiert besonders oft bei Distributions-Builds.

  • Wenn man sich die Arbeit anderer Sprachen an Nicht-LLVM-Backends anschaut, wirkt der verlinkte Vorschlag viel zu arrogant.
    Wenn der Autor nicht diese Person wäre, hätte ich es für ein hastig hingeworfenes GitHub-Issue eines Zig-Anfängers gehalten.
    Der nötige Arbeitsaufwand wird unterschätzt, die gesamte Arbeit, die in LLVM steckt, wird unterschwellig abgewertet, und aus jeder Zeile spricht dieses selbstbewusste, machoartige „natürlich können wir das billiger, schneller und besser machen“. Das ist enttäuschend.
    Bisher habe ich Andrews Arbeit wirklich respektiert, daher möchte ich wohlwollend annehmen, dass der Text hastig oder impulsiv geschrieben wurde und deshalb so rüberkommt.
    Aber dieser Text schafft kein Vertrauen und bringt mich auch nicht dazu, dem Vorschlag selbst offener gegenüberzustehen.

    • Ich kenne mich mit dem LLVM-Backend überhaupt nicht aus, aber Bibliotheken, die versuchen, 100 % aller Nutzerprobleme zu lösen, werden am Ende oft schwerfälliger und langsamer als stärker optimierte Alternativen.
      Webpack und esbuild sind ein Beispiel dafür.

  • Der richtige Zeitpunkt, etwas ohne LLVM zu bauen, war vor ein paar Jahren. Aber wenn jetzt die C++-Funktionen herausgenommen werden, könnte das das Ende von Zig sein.
    Ich bin überrascht, dass man nicht angekündigt hat, schrittweise ein eigenes C++-Compilerprojekt in Zig zu schreiben, statt es stückweise zu entfernen.

    • Schon allein einen C++-Parser zu schreiben ist ein gewaltiges Projekt.
      Ich bin mir nicht einmal sicher, ob eine Person, die an ihrem 18. Geburtstag damit anfängt, in ihrem verbleibenden Leben genug Zeit hätte, einen funktionierenden C++-Compiler zu schreiben.

  • Zig möchte eher das neue C der Welt werden als das neue C++ der Welt
    Auch in diesem Vorschlag ist zu sehen, dass C-Cross-Compilation weiterhin unterstützt wird
    Diese Entscheidung könnte richtig sein. C wird in der Embedded-Welt derzeit viel genutzt, und LLVM ist in diesem Bereich nicht gut
    Wenn ich Zig wäre, würde ich alle Mikrocontroller ins Visier nehmen wollen, und das ist der einzige realistische Weg, das zu erreichen