Zig – ajout d’implémentations `std.Io` pour io_uring et Grand Central Dispatch

• De nouvelles implémentations basées sur io_uring et Grand Central Dispatch (GCD) ont été intégrées au module std.Io.Evented de la bibliothèque standard de Zig
• Les deux implémentations fonctionnent avec un changement de pile en espace utilisateur (fibers, coroutines à pile, green threads)
• Elles sont pour l’instant au stade expérimental et nécessitent encore des travaux de suivi, notamment l’amélioration de la gestion des erreurs, la suppression des logs, l’analyse des causes de la baisse de performances et le renforcement des tests
• Il est possible de remplacer uniquement le backend I/O dans un même code applicatif pour basculer facilement entre io_uring et GCD
• Les deux implémentations fonctionnent également dans le compilateur Zig et pourraient, une fois stabilisées, devenir une base unifiée d’I/O asynchrones selon les plateformes

---

Implémentations de std.Io.Evented basées sur io_uring et GCD

• À la fin du cycle de publication de Zig 0.16.0, std.Io.Evented a été mis à jour pour refléter les derniers changements d’API

  • Les nouvelles implémentations ajoutées sont io_uring (Linux) et Grand Central Dispatch (GCD) (macOS)
  • Les deux implémentations utilisent la technique du changement de pile en espace utilisateur (fibers, coroutines à pile, green threads)

• Les deux implémentations sont actuellement expérimentales et plusieurs chantiers restent ouverts pour un usage stable

  • Nécessité d’améliorer la gestion des erreurs
  • Nécessité de supprimer les logs et de diagnostiquer les causes de la baisse de performances (une dégradation des performances du compilateur se produit lors de l’utilisation de IoMode.evented)
  • Présence de fonctions non encore implémentées et besoin de renforcer la couverture de tests
  • Nécessité d’ajouter une fonction intégrée permettant de vérifier la taille maximale de pile par fonction (afin d’assurer un usage pratique quand overcommit est désactivé)

Exemple de remplacement d’implémentation I/O

• Le même code applicatif peut fonctionner en remplaçant uniquement le backend I/O

  • Dans l’exemple de code, utiliser std.Io.Evented à la place de std.Io.Threaded permet une exécution basée sur io_uring
  • La fonction app reste identique, et le résultat affiché (Hello, World!) est lui aussi identique

• La comparaison des résultats strace permet de voir la différence entre les deux modes d’exécution

  • hello_threaded utilise des appels I/O classiques basés sur les threads
  • hello_evented utilise des appels système io_uring (io_uring_setup, io_uring_enter, etc.)

Application au compilateur Zig et état actuel

• Le compilateur Zig lui-même fonctionne correctement en utilisant std.Io.Evented

  • Le compilateur peut s’exécuter aussi bien avec io_uring qu’avec GCD
  • Toutefois, les causes de la baisse de performances ne sont pas encore identifiées et demandent une analyse complémentaire

• Cette évolution rapproche Zig d’une architecture où le code peut facilement remplacer son implémentation I/O

  • Elle pose les bases d’une gestion unifiée des modèles d’I/O asynchrones selon les plateformes

Travaux à venir

• Des améliorations de performances et un renforcement des tests sont nécessaires pour un usage stable
• L’ajout d’une fonction de gestion de la taille de pile permettrait un usage pratique même dans des environnements où l’overcommit est désactivé
• Une fois aboutie, la couche d’abstraction des I/O asynchrones de Zig devrait s’en trouver nettement renforcée

Conclusion

• Cette mise à jour constitue une avancée importante dans l’extension du système d’I/O standard de Zig
• En intégrant io_uring et GCD, elle établit une base pour une cohérence du traitement asynchrone entre plateformes
• Une fois le travail de stabilisation achevé, elle élargira les possibilités d’un modèle I/O Zig à la fois performant et flexible

[GN⁺]

Commentaires sur Hacker News

• Je ne suis pas un fan de Zig, mais c’est agréable de voir une petite équipe progresser avec constance
  Son attitude, qui privilégie l’expérimentation et l’amélioration progressive plutôt qu’un produit « fini », est impressionnante
  Je pense qu’il est plus important d’avancer vers des objectifs de long terme que de se précipiter pour sortir une 1.0
  Pour un projet aussi centré sur une seule personne, c’est une réussite étonnante, et les gens qui s’y investissent méritent une reconnaissance légitime

  • Chaque fois que j’apprends un nouveau langage, j’essaie de créer un moteur de jeu avec un serveur multijoueur TCP/UDP, et récemment je l’ai tenté en Zig
    Ça a été l’expérience la plus amusante et productive que j’aie eue jusqu’ici
    La simplicité de Zig me convient bien mieux que la gestion mémoire stricte de Rust
    La vie est courte, et je veux simplement construire des logiciels rapides et bien organisés

• Il y a beaucoup de critiques sous chaque article sur Zig, mais je ne comprends pas pourquoi ça suscite autant d’attention
  L’esprit d’ingénierie d’Andrew et de son équipe, qui cherchent à concrétiser ce en quoi ils croient, est au contraire inspirant
  Inutile de se demander si Zig deviendra dominant : s’il aide à résoudre des problèmes, c’est déjà suffisant
  Il ne faut pas traiter un langage comme une identité

  • Pour faire disparaître ce phénomène, il faudrait changer les incitations économiques que reçoivent les programmeurs
    Les langages et les bibliothèques sont aussi des « compétences vendables », donc les gens restent attentifs à la valeur de marché des outils qu’ils utilisent
    Le fait que les décideurs voient souvent les ingénieurs comme des ressources interchangeables est aussi un problème
  • Ce type de débat autour des langages n’est pas propre à Zig
    On l’a déjà vu avec Lisp, Ruby, Rust et d’autres, et ces guerres d’identité sont un problème chronique du secteur
  • Une nouvelle pile de langage augmente la charge de maintenance dans les distributions Linux
    Il faut une gestion à long terme pour la sécurité, le support d’architecture, etc., mais les développeurs ont tendance à négliger ce coût
    Zig n’est pas encore stable, donc certains paquets ne compilent qu’avec des versions précises
    On peut se demander s’il est vraiment nécessaire de résoudre avec un nouveau langage des problèmes qu’on pourrait aussi traiter en améliorant d’autres langages
  • Pour devenir un langage grand public, il faut un écosystème de bibliothèques prévisible capable de couvrir la plupart des cas d’usage

• J’ai l’impression que ça ne sert pas à grand-chose de suivre Zig avant qu’il atteigne la 1.0
  La structure actuelle a de fortes chances d’être remaniée plusieurs fois
  Je m’y suis intéressé un temps, mais je ne sais même pas si je verrai une 1.0 de mon vivant

  • En pratique, les ruptures de compatibilité de Zig viennent surtout de la bibliothèque standard (stdlib)
    Les fonctions de base comme les entrées/sorties de fichiers restent presque identiques ; seuls les espaces de noms changent
    Je pense qu’un « langage vivant » est préférable
    Même après la 1.x, j’aimerais qu’il y ait une stratégie de gestion des interfaces par version pour garder une stdlib légère
  • J’aime le langage Zig lui-même, mais j’ai des doutes sur la qualité de la stdlib
    En construisant moi-même un framework I/O, j’ai trouvé des tests insuffisants et du code assembleur incorrect
    Je l’ai signalé plusieurs fois, mais rien n’a été corrigé, donc ma confiance a baissé
  • On peut hésiter pour de très gros projets, mais Zig a déjà une vraie valeur business
    Surtout dans le cloud, où l’optimisation des performances peut réduire les coûts serveur de plus de 90 %
    Avec Python ou Node, on atteint vite des limites, donc il faut au final descendre vers C, C++, Rust ou Zig
    Parmi eux, Zig est facile à apprendre, ainsi qu’à lire et à tester
  • À noter que Bun est aussi écrit en Zig
    C’est déjà un langage utilisé à un niveau professionnel
  • Notre équipe (ZML) continue de suivre la branche master de Zig depuis l’introduction de std.Io
    La plupart des changements donnent réellement l’impression d’améliorer le langage

• Il est intéressant de voir Zig tenter cette implémentation avant Rust, alors que le support de io_uring côté Rust n’est pas encore finalisé
  En Rust, il est difficile de concevoir des abstractions à la fois sûres et zero-cost

• Cette annonce concerne encore une implémentation inachevée
  Par exemple, la version GCD n’a pas de réseau
  L’interface continue de grossir, donc on est plus proche d’un snapshot actuel que d’un ensemble abouti

  • Mais l’introduction de l’article précise déjà qu’il s’agit d’une phase expérimentale,
    et liste concrètement six tâches majeures à accomplir par la suite

• Il existe une issue sur l’optimisation de la mémoire de pile
  Il faudrait une fonctionnalité permettant que l’usage de [500]u8 dans différents blocs n’occupe que 500 octets dans la stack frame
  C’est particulièrement important pour les stacks de coroutines à green threads

• Je vois d’un bon œil les efforts d’amélioration continue de Zig
  À l’heure actuelle, aucun langage ne gère vraiment bien io_uring
  Si Zig résout bien ce point, il prendra un avantage important
  Je trouve plus précieux de privilégier l’apprentissage et l’expérimentation que la stabilité

  • C’est intéressant de vouloir de l’async même dans un langage bas niveau
    Personnellement, je préfère contrôler io_uring directement dans Zig avec libxev
  • Moi aussi je suis positif, mais je me demande à quel moment Zig proposera une version LTS comme C
    Le succès de C reposait sur sa stabilité et une culture de développement cohérente

• J’aime le fait que Zig traite sérieusement les cibles freestanding
  J’espère que la version 0.16 améliorera encore la réutilisabilité du code

• J’ai jeté un œil aux entrailles de macOS pour la première fois depuis longtemps, et ça fait plaisir de voir GCD toujours maintenu
  Je trouve que c’est une approche équilibrée de la parallélisation

• Pendant que d’autres langages se contentent de débattre, Zig essaie concrètement, puis revient en arrière si nécessaire
  Je crois qu’une API éprouvée en pratique est la meilleure forme de conception
  On peut garder les anciennes versions, ou passer à la plus récente pour obtenir des outils plus propres et plus rapides

  • Jai est centré sur le développement de jeux, donc il manque d’universalité et de sécurité
    Il est complexe comme C++, alors que Zig conserve une simplicité de niveau C
    Carbon n’a toujours pas de réalité concrète
  • C’est étrange de critiquer Zig parce qu’il n’est pas en 1.0
    Jai est en bêta fermée depuis 11 ans, alors que Zig est déjà utilisé dans plusieurs projets réels
  • Même si cela prend 20 ans, je pense qu’il vaut mieux qu’un langage soit bien achevé
    Les changements désordonnés qu’on a vus avec Python 2→3, l’async de Rust, les génériques de Go ou encore C++ sont au contraire nuisibles