Zig – std.Io-Implementierungen für io_uring und Grand Central Dispatch hinzugefügt

 (ziglang.org)
2 Punkte von GN⁺ 2026-02-15 | 1 Kommentare | Auf WhatsApp teilen
  • In das Modul std.Io.Evented der Zig-Standardbibliothek wurden neue Implementierungen auf Basis von io_uring und Grand Central Dispatch (GCD) integriert
  • Beide Implementierungen arbeiten mit Stack-Umschaltung im User-Space (Fibers, stackful coroutines, green threads)
  • Derzeit befinden sie sich noch im experimentellen Stadium; weitere Arbeiten wie bessere Fehlerbehandlung, Entfernen von Logging, Analyse der Ursachen für Performance-Einbußen und Ausbau der Tests sind noch nötig
  • Im selben Anwendungscode kann nur das I/O-Backend ausgetauscht werden, um einfach zwischen io_uring und GCD zu wechseln
  • Auch der Zig-Compiler funktioniert mit beiden Implementierungen; nach einer späteren Stabilisierung könnten sie sich zu einer plattformübergreifenden Grundlage für integriertes asynchrones I/O entwickeln

std.Io.Evented-Implementierungen auf Basis von io_uring und GCD

  • Gegen Ende des Release-Zyklus von Zig 0.16.0 wurde std.Io.Evented aktualisiert, um die jüngsten API-Änderungen zu berücksichtigen

    • Neu hinzugekommene Implementierungen sind io_uring (Linux) und Grand Central Dispatch (GCD) (macOS)
    • Beide Implementierungen verwenden die Technik der Stack-Umschaltung im User-Space (Fibers, stackful coroutines, green threads)

  • Beide Implementierungen befinden sich derzeit im experimentellen Zustand; für einen stabilen Einsatz sind noch mehrere Verbesserungen nötig

    • Verbesserung der Fehlerbehandlung erforderlich
    • Entfernung von Logging sowie Analyse der Ursachen für Performance-Einbußen nötig (bei Verwendung von IoMode.evented kommt es zu Performance-Verlusten im Compiler)
    • Einige Funktionen sind noch nicht implementiert und die Testabdeckung muss erweitert werden
    • Es wird ein Builtin zur Prüfung der maximalen Stack-Größe pro Funktion benötigt (um praktische Nutzbarkeit bei deaktiviertem overcommit sicherzustellen)

Beispiel für den Austausch der I/O-Implementierung

  • Im selben Anwendungscode lässt sich der Betrieb durch Austausch nur des I/O-Backends umstellen

    • Im Beispielcode läuft die Ausführung auf Basis von io_uring, wenn statt std.Io.Threaded std.Io.Evented verwendet wird
    • Die Funktion app bleibt identisch, ebenso das Ausgabeergebnis (Hello, World!)

  • Ein Vergleich der strace-Ergebnisse zeigt die Unterschiede zwischen den beiden Ausführungsarten

    • hello_threaded verwendet gewöhnliche threadbasierte I/O-Aufrufe
    • hello_evented nutzt io_uring-Systemaufrufe (io_uring_setup, io_uring_enter usw.)

Einsatz im Zig-Compiler und aktueller Stand

  • Auch der Zig-Compiler selbst funktioniert korrekt mit std.Io.Evented

    • Der Compiler kann sowohl mit io_uring als auch mit GCD ausgeführt werden
    • Allerdings ist die Ursache der Performance-Einbußen noch ungeklärt, sodass weitere Analyse nötig ist

  • Durch diese Änderung nähert sich Zig einer Struktur, in der sich I/O-Implementierungen leicht austauschen lassen

    • Damit wird eine Grundlage geschaffen, um plattformspezifische asynchrone I/O-Modelle einheitlich zu behandeln

Weitere Aufgaben

  • Für einen stabilen Einsatz sind Performance-Verbesserungen und stärkere Tests erforderlich
  • Wenn Funktionen zur Verwaltung der Stack-Größe ergänzt werden, könnte die praktische Nutzung auch in Umgebungen mit deaktiviertem Overcommit möglich werden
  • Nach Fertigstellung dürfte Zigs Abstraktionsschicht für asynchrones I/O deutlich gestärkt sein

Fazit

  • Dieses Update ist ein wichtiger Fortschritt beim Ausbau des Standard-I/O-Systems von Zig
  • Durch die Integration von io_uring und GCD entsteht eine Grundlage für konsistente asynchrone Verarbeitung über Plattformgrenzen hinweg
  • Nach Abschluss der weiteren Stabilisierung dürfte sich Zigs leistungsfähiges und flexibles I/O-Modell deutlich erweitern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-15
Hacker-News-Kommentare

  • Ich bin zwar kein Zig-Fan, aber es ist schön zu sehen, wie sich ein kleines Team stetig weiterentwickelt
    Besonders beeindruckend ist die Haltung, Experimente und schrittweise Verbesserungen höher zu gewichten als bloße Fertigstellung
    Ich denke, es ist wichtiger, auf langfristige Ziele hinzuarbeiten, statt 1.0 überhastet zu veröffentlichen
    Für ein so stark auf eine einzelne Person zentriertes Projekt ist das eine erstaunliche Leistung, und die Menschen dahinter verdienen angemessene Anerkennung

    • Jedes Mal, wenn ich eine neue Sprache lerne, baue ich probeweise eine Game-Engine mit TCP/UDP-Multiplayer-Server; zuletzt habe ich das mit Zig versucht
      Es war bisher die spaßigste und produktivste Erfahrung
      Zigs Einfachheit liegt mir deutlich mehr als Rusts strenges Memory-Management
      Das Leben ist kurz, und ich will einfach nur schnelle, sauber strukturierte Software bauen

  • Unter fast jedem Beitrag über Zig gibt es viel Kritik, aber ich verstehe nicht, warum das so viele beschäftigt
    Der Engineering-Geist, mit dem Andrew und das Team umsetzen wollen, woran sie glauben, wirkt auf mich eher inspirierend
    Man muss sich nicht darum sorgen, ob Zig Mainstream wird; wenn es beim Lösen von Problemen hilft, reicht das völlig
    Man muss Sprachen nicht wie eine Identität behandeln

    • Um dieses Phänomen loszuwerden, müsste man die wirtschaftlichen Anreize für Programmierer ändern
      Sprachen und Libraries sind letztlich „verkaufbare Skills“, deshalb achten Menschen auf die Marktfähigkeit der Tools, die sie verwenden
      Dazu kommt das Problem, dass Entscheidungsträger Engineers oft als austauschbare Ressourcen betrachten
    • Diese Sprachdebatten sind nichts Zig-spezifisches
      Sie haben sich schon bei Lisp, Ruby, Rust und anderen wiederholt, und diese Identitätskämpfe sind ein chronisches Problem der Branche
    • Ein neuer Sprach-Stack erhöht in Linux-Distributionen die Wartungslast
      Langfristige Pflege wie Security- und Architektur-Support ist nötig, aber Entwickler übersehen diese Kosten oft
      Zig ist noch nicht stabil, deshalb kompilieren Pakete oft nur mit bestimmten Versionen
      Ich frage mich, ob man Probleme, die sich auch durch Verbesserungen anderer Sprachen lösen lassen, wirklich mit einer neuen Sprache angehen muss
    • Um eine Mainstream-Sprache zu werden, braucht es ein vorhersehbares Library-Ökosystem, das die meisten Use Cases abdeckt

  • Ich habe das Gefühl, dass es wenig bringt, Zig vor 1.0 intensiv zu verfolgen
    Die aktuelle Struktur wird wahrscheinlich noch mehrfach umgebaut
    Ich war selbst einmal interessiert, weiß aber nicht, ob ich 1.0 noch zu meinen Lebzeiten sehen werde

    • Tatsächlich treten Zigs Breaking Changes meist in der Standardbibliothek (stdlib) auf
      Grundfunktionen wie Datei-I/O bleiben fast gleich, nur die Namespaces ändern sich
      Ich halte eine „lebendige Sprache“ für besser
      Es wäre gut, wenn es auch nach 1.x eine Strategie zur Verwaltung versionsabhängiger Interfaces gäbe, um die stdlib schlank zu halten
    • Die Zig-Sprache selbst gefällt mir, aber bei der Qualität der stdlib habe ich Zweifel
      Beim Bau eines eigenen I/O-Frameworks bin ich auf fehlende Tests und fehlerhaften Assembler-Code gestoßen
      Ich habe mehrfach darauf hingewiesen, aber es wurde nicht korrigiert, wodurch mein Vertrauen gesunken ist
    • Für große Projekte kann man zögern, aber Zig hat geschäftlich bereits Wert
      Gerade in Cloud-Umgebungen kann Performance-Optimierung die Serverkosten um mehr als 90 % senken
      Mit Python oder Node stößt man dabei an Grenzen, sodass man letztlich auf C, C++, Rust oder Zig heruntergehen muss
      Davon ist Zig leicht zu lernen sowie gut zu lesen und zu testen
    • Zur Einordnung: Auch Bun ist in Zig geschrieben
      Die Sprache wird bereits auf produktionsreifem Niveau eingesetzt
    • Unser Team (ZML) folgt seit der Einführung von std.Io fortlaufend dem Zig-master-Branch
      Die meisten Änderungen fühlen sich tatsächlich wie Verbesserungen der Sprache an

  • Es ist interessant, dass Zig die Implementierung zuerst versucht, während Rusts io_uring-Unterstützung noch nicht abgeschlossen ist
    In Rust ist es schwierig, sichere und Zero-Cost-Abstraktionen zu entwerfen

  • Diese Nachricht betrifft noch eine unfertige Implementierung
    Zum Beispiel hat die GCD-Version kein Networking
    Das Interface wird immer größer und wirkt eher wie ein aktueller Snapshot als wie etwas Fertiges

    • Im Einleitungsteil des Artikels wurde aber bereits klargestellt, dass sich alles noch in einer experimentellen Phase befindet,
      und die sechs wichtigsten Aufgaben für die Zukunft wurden konkret aufgelistet

  • Es gibt ein Issue zur Optimierung von Stack-Speicher
    Es wird eine Funktion benötigt, bei der [500]u8 in verschiedenen Blöcken trotzdem nur 500 Byte im Stack-Frame belegt
    Das ist besonders wichtig im Zusammenhang mit Green-Thread-Koroutinen-Stacks

  • Ich sehe Zigs kontinuierliche Verbesserungsbemühungen positiv
    Derzeit gibt es keine Sprache, die io_uring wirklich gut behandelt
    Wenn Zig dieses Problem gut löst, wäre das ein großer Vorteil
    Ich halte eine Haltung, die Lernen und Experimentieren höher bewertet als Stabilität, für wertvoller

    • Interessant, dass man selbst in einer Low-Level-Sprache async will
      Ich bevorzuge es, in Zig mit libxev io_uring direkt zu steuern
    • Ich sehe das auch positiv, frage mich aber, wann Zig wie C eine langfristig stabile Version (LTS) herausbringen wird
      Ein Erfolgsfaktor von C war seine Stabilität und konsistente Entwicklungskultur

  • Ich finde gut, dass Zig freestanding-Targets ernst nimmt
    Ich erwarte, dass mit Version 0.16 die Wiederverwendbarkeit von Code weiter steigt

  • Ich habe mir nach langer Zeit mal wieder das Innenleben von macOS angesehen und mich gefreut, dass GCD beibehalten wurde
    Ich halte das für einen ausgewogenen Ansatz bei der Parallelisierung

  • Während andere Sprachen nur diskutieren, probiert Zig Dinge direkt aus und macht sie bei Bedarf wieder rückgängig
    Ich glaube, eine in der Praxis erprobte API ist die beste Form von Design
    Man kann ältere Versionen weiterverwenden, oder auf die neueste wechseln und dafür sauberere und schnellere Tools bekommen

    • Jai ist stark auf Spieleentwicklung ausgerichtet und hat deshalb Defizite bei Allgemeinheit und Sicherheit
      Es ist komplex wie C++, während Zig die Einfachheit auf C-Niveau beibehält
      Carbon ist bisher noch kaum mehr als ein Konzept
    • Es ist seltsam, Zig dafür zu kritisieren, dass es noch nicht 1.0 ist
      Jai befindet sich seit 11 Jahren in einer Closed Beta, während Zig bereits in vielen realen Projekten eingesetzt wird
    • Ich denke, eine Sprache sollte lieber richtig fertig werden, selbst wenn es 20 Jahre dauert
      Die unüberlegten Veränderungen, die man etwa bei Python 2→3, Rust async, Go-Generics oder C++ gesehen hat, sind eher schädlich