- Le projet Zig vise à supprimer complètement les dépendances aux bibliothèques LLVM, Clang et LLD du principal exécutable zig
- Les travaux restants se répartissent entre la suppression de LLD, la suppression des appels à l’API LLVM, les progrès des backends C/x86/wasm/aarch64, la suppression des sous-commandes dépendantes de Clang et de l’usage du préprocesseur, ainsi qu’une implémentation de remplacement de
zig ar, entre autres - Le backend LLVM produit déjà des fichiers
.bc, mais le compilateur Zig ne disposera plus de la capacité de compiler des.bcen fichiers objet ; dans ce cas, une installation séparée de Clang sera nécessaire - Parmi les effets attendus figurent la simplification de la compilation depuis les sources et du bootstrap, l’évitement des problèmes liés à LLVM/Clang/LLD dans les distributions Linux et Homebrew, ainsi qu’une réduction de la taille du binaire d’environ 150 Mio à 5 Mio
- Zig met en avant l’idée de pouvoir implémenter ses propres passes d’optimisation et d’attirer les contributions directes de projets de recherche comme alive2, ainsi que de fabricants de puces Intel, ARM et RISC-V
Dépendances que Zig veut retirer de l’exécutable
- L’objectif de cette issue est de supprimer complètement les bibliothèques LLVM, Clang et LLD du projet Zig
- Les points de connexion restants sont regroupés autour de LLD, LLVM, Clang et
zig ar
Travaux restants liés à LLD
- completely eliminate dependency on LLD #8726 : il reste à supprimer complètement la dépendance à LLD
Travaux restants liés à LLVM
- La partie LLVM comprend la sortie de bitcode LLVM, le taux de réussite des tests des backends et la suppression de l’API LLVM
- directly output LLVM bitcode rather than using LLVM's IRBuilder API #13265 : produire directement du bitcode LLVM au lieu d’utiliser l’API IRBuilder de LLVM
- Le backend C réussit 1742 tests sur 1792, soit un taux de réussite de 97 %
- enable the x86 backend by default for debug builds on x86_64-linux #22257 : activer par défaut le backend x86 pour les builds de debug sur x86_64-linux
- Le backend wasm réussit 1611 tests sur 1765, soit un taux de réussite de 91 %
- 100% behavior tests passing for the aarch64 backend #21172 : faire passer 100 % des behavior tests pour le backend aarch64
- ability to create import libs from def files without LLVM #17807 : permettre de créer des import libs à partir de fichiers def sans LLVM
- Avoid LLVM API for setting a module's code model and PIC/PIE levels #21238 : éviter l’usage de l’API LLVM pour définir le code model et les niveaux PIC/PIE d’un module
- completely eliminate dependency on LLVM library API calls #25492 : supprimer complètement la dépendance aux appels à l’API de la bibliothèque LLVM
Travaux restants liés à Clang
- Les fichiers source C++ du dépôt Zig sont compilés avec clang lors du bootstrap
- src/windows_sdk.cpp: port to Zig #15657 : porter
src/windows_sdk.cppvers Zig
- src/windows_sdk.cpp: port to Zig #15657 : porter
zig cc,zig c++,zig translate-cand other subcommands without a clang/llvm dependency in the compiler binary #20875 : fournirzig cc,zig c++,zig translate-cet d’autres sous-commandes sans dépendance à clang/llvm dans le binaire du compilateur- make resinator use aro's preprocessor instead of clang #17752 : faire en sorte que resinator utilise le préprocesseur d’aro au lieu de clang
- make mingw .def.in file parsing use aro's preprocessor instead of clang #17753 : faire en sorte que l’analyse des fichiers mingw
.def.inutilise le préprocesseur d’aro au lieu de clang - move
@cImportto the build system #20630 : déplacer@cImportvers le système de build
Contraintes liées à zig ar et au traitement des fichiers .bc
- zig ar: a drop-in llvm-ar replacement #9828 : il reste à faire de
zig arun remplaçant direct de llvm-ar - Le backend LLVM produit déjà des fichiers
.bc, mais le compilateur Zig ne disposera plus de la capacité de compiler des fichiers.bcen fichiers objet - Pour couvrir ce cas d’usage, il faudra installer Clang séparément
Changements attendus de la suppression des dépendances
- Tous les bugs côté Zig entreront dans le périmètre de responsabilité du projet Zig
- Le processus de compilation du compilateur depuis les sources et de bootstrap sera simplifié ; le système hôte n’aura besoin que d’un compilateur C
- Les distributions Linux et les gestionnaires de paquets comme Homebrew n’auront plus à gérer les problèmes liés à LLVM, Clang et LLD
- La taille du binaire du compilateur Zig passera d’environ 150 Mio à 5 Mio
- La vitesse de compilation pourrait être améliorée de plusieurs ordres de grandeur
- Zig pourrait implémenter ses propres passes d’optimisation et repousser l’état de l’art en matière de calcul
- Il pourrait attirer des projets de recherche comme alive2
- Il pourrait encourager les contributions directes de parties prenantes souhaitant un meilleur code machine pour leurs propres CPU, comme les fabricants de puces Intel, ARM et RISC-V
2 commentaires
Peut-on vraiment atteindre le même niveau d’optimisation et de prise en charge des plateformes qu’avec LLVM…
Commentaires sur Hacker News
Andrew a un esprit tellement affûté que, dès lors qu’il l’a annoncé comme objectif, on a l’impression que l’équipe finira par y arriver
Cela dit, vu de l’extérieur et sans bien connaître les difficultés de Zig avec LLVM, cette décision donne l’impression de détourner les capacités de l’équipe vers des outils périphériques comme binutils plutôt que vers Zig lui-même
En ne lisant que le titre, j’ai d’abord cru qu’ils abandonnaient le compilateur, et pour un projet comme Zig, il semble aussi y avoir beaucoup à gagner à conserver LLVM
Cela dit, l’idée de réécrire une grande partie du code à l’intérieur de LLVM en Zig plutôt qu’en C++ est assez cool et ambitieuse. On peut même dire que c’est aussi ambitieux que la tentative de Lattner qui a créé LLVM
Cela dit, le code qui devient accidentellement en complexité temporelle quadratique sera probablement tout aussi difficile à éviter pour Zig si le projet devient aussi populaire et utile que LLVM
En substance : « si une mission spatiale ne réutilise pas un lanceur existant, alors le projet devient un projet de développement de lanceur, et tout le reste, que l’on pensait être le cœur de la mission, devient secondaire »
Je me souviens aussi d’un passage ajoutant l’hypothèse suivante : « au lieu d’accepter les compromis imposés par un lanceur existant, on peut penser qu’il serait moins cher et plus efficace d’en construire un adapté à une mission donnée »
Une partie du succès de Rust repose aussi sur une compatibilité similaire avec C/C++
J’ai du mal à imaginer Zig réussir sans une capacité comparable, et j’espère donc qu’ils n’iront pas jusqu’au bout de ce jalon tel quel
GCC ne voulait pas autoriser ni implémenter ce qu’Apple voulait ou avait besoin de faire
Avec une approche plus ciblée, comme TCC, l’essentiel concernerait la génération de code pour plusieurs architectures
Il y a ici deux problèmes. L’un est la génération de code, l’autre le bootstrap
D’expérience, les passes d’optimisation d’un compilateur sont faciles à écrire et amusantes. Il faut lire des articles pour comprendre l’allocation de registres et la forme SSA, mais on peut prendre plaisir à écrire du code qui fait passer un IR dans diverses passes d’optimisation pour l’affiner progressivement
On peut créer des passes d’optimisation de haute qualité sans LLVM. Mais l’étape qui consiste à linéariser l’IR en code machine est un travail ennuyeux et banal, sauf si l’on adore toutes les façons dont x86-32/64 peut encoder une instruction comme “mov [eax+8*ebx], 123”
Si l’on optimise la taille du binaire, qui a envie de mesurer sur quelle plateforme “push eax; push eax; push eax” est plus court que “add rsp,12” ? Et ça, ce n’est que pour x86 ; si on multiplie cela par les architectures non x86, qui importent peu à la plupart des développeurs, c’est encore bien pire
Il est aussi très probable que de gros bugs dans les générateurs de code pour des architectures peu utilisées passent inaperçus pendant des années
Le second problème est le bootstrap. Avec quoi compiler un compilateur Zig écrit en Zig ? On peut par exemple compiler le compilateur Zig avec un compilateur Zig minimal non optimisé écrit en C
Mais s’il n’est pas optimisé, il faut ensuite recompiler le compilateur Zig avec un compilateur Zig optimisé. Ce n’est pas un problème insoluble, mais un processus de build long et complexe risque de faire fuir des contributeurs potentiels
Vu la communication faite jusque-là sur le fait que Zig pouvait compiler du C, et peut-être même du C++, annoncer maintenant qu’ils vont retirer complètement LLVM paraît assez radical
À moins qu’un bien plus grand nombre de personnes ne participe au support, il semble aussi très improbable qu’ils s’approchent du niveau de prise en charge des plateformes offert par LLVM
Je peux comprendre l’idée d’ajouter un backend maison pour ceux qui le souhaitent, mais supprimer purement et simplement LLVM paraît précipité
En ce moment, l’équipe recueille des retours, apprend quels cas d’usage seraient affectés et évalue la faisabilité, donc on est presque à l’opposé de la précipitation
Devoir embarquer une copie de LLVM de plus de 100 Mo, dont on n’a pas forcément besoin dans le cas général, est effectivement un peu étrange, donc cela se tient. Beaucoup de développeurs l’ont probablement déjà installé de toute façon
En revanche, il pourrait être difficile de garantir qu’une installation donnée de Zig fonctionne correctement avec la version système de LLVM. À voir
https://github.com/ziglang/zig/issues/13265
J’ai récemment davantage lu sur Zig et je m’en suis aussi servi comme moyen simple de compiler du C++ avec LLVM sans me battre avec les paquets système. Le fait de pouvoir passer de C/C++ à Zig était un gros argument de vente
Cela paraît extrêmement soudain et inattendu. Je ne sais pas si c’est la bonne ou la mauvaise direction pour le projet, mais de mon point de vue, ça tombe vraiment de nulle part
D’un côté, je respecte cette volonté méticuleuse de réduire les dépendances, mais le prix à payer semble assez lourd
La perte de compatibilité C++ éliminerait de fait l’avantage que les fans de Zig autour de moi citaient le plus souvent
La perte de performances, même si elle est temporaire, est aussi un autre point clé qu’ils mettaient souvent en avant
Pour ceux qui lisent en diagonale : ce n’est pas acté, c’est une proposition
J’ai passé environ quatre ans à écrire tous mes projets embarqués et bibliothèques en Zig, et maintenant plusieurs architectures supportées tier 1 vont simplement disparaître ?
C’est leur langage, donc ils peuvent en faire ce qu’ils veulent, mais dans ce cas j’aimerais qu’ils ajustent aussi le branding en conséquence
J’imagine plutôt que le support tier 1 va se diviser en deux catégories : le support tier 1 intégré, et le support tier 1 via un backend LLVM optionnel
Si une architecture a déjà un support tier 1, je ne vois pas pourquoi elle le perdrait simplement parce que le backend LLVM devient une dépendance optionnelle
Comme Andrew l’a écrit dans sa proposition, cette approche pourrait même permettre de mieux prendre en charge des architectures plus rares. Je serais volontiers prêt à travailler sur un backend Zig pour une architecture de processeur intéressante, mais je ne contribuerai jamais à LLVM. Travailler en C++ n’est pas quelque chose que je fais pour le plaisir
Quel serait l’intérêt ? Ce n’est pas du gaspillage de ressources ?
DLang a trois compilateurs
gdc repose sur le backend de la GNU Compiler Collection, ldc repose sur un backend LLVM, et dmd repose sur le générateur de code x86 que j’ai écrit pour Zortech/Symantec/Digital Mars
Chacun a ses avantages, ses inconvénients et sa cible, mais tous prennent en charge le même langage D
Globalement, les utilisateurs aiment avoir le choix, et certains en utilisent même plusieurs à la fois
Si c’est bien ça, j’aime l’approche de Zig
C’est très utile, parce qu’on peut utiliser le compilateur le plus rapide pendant le développement, puis pour la release finale celui qui offre le runtime le plus rapide ou la plus faible consommation mémoire
Et lorsqu’il existe une spécification du langage que tous les compilateurs suivent, cela donne l’assurance que le langage est stable et ne se casse pas soudainement en dessous
Bien sûr, il y a aussi des avantages à un langage comme Zig, où l’on peut encore changer ce qu’on veut pour le rendre plus cohérent, plus propre et plus puissant. Mais aujourd’hui, j’accorde beaucoup plus de valeur à ce genre de stabilité, parce qu’elle permet de se concentrer sur la création de vraie valeur pour les utilisateurs au lieu de courir sans cesse après les outils de développement
L’une des principales raisons pour lesquelles Zig m’intéressait, c’est qu’il pouvait s’insérer directement comme alternative à un compilateur C/C++
Sur Windows, des amis m’ont dit que Zig était plus facile à installer comme compilateur C/C++ que n’importe quelle autre alternative
Si cette proposition est acceptée, j’ai personnellement l’impression que la popularité de Zig retombera au niveau de Hare ou d’autres langages extrêmement de niche
Pour convaincre mes collègues d’essayer Zig ne serait-ce qu’une fois, j’ai dû leur envoyer des billets disant qu’Uber l’utilisait en production. Sans valeur immédiate pour les projets existants, ils n’y auraient même pas réfléchi à deux fois
Cela dit, je comprends le contexte de la proposition. Les temps de compilation de LLVM peuvent sembler terribles, et avoir son propre bytecode permettrait aussi d’implémenter des techniques d’optimisation intéressantes. Gérer des bugs LLVM est en pratique une tâche très difficile, et j’ai vu ça aussi dans l’écosystème Julia
Si ma recommandation a la moindre valeur, je pense que Zig devrait 1) utiliser un bytecode custom pour les builds de debug afin d’avoir des builds rapides et un débogage rapide, et 2) utiliser LLVM pour les builds de release afin d’obtenir de bonnes performances à l’exécution
S’ils peuvent faire le point 1) tout en conservant le support de compilation croisée C/C++, par exemple en ne déléguant à LLVM que cette partie, ce serait peut-être le meilleur compromis, même avec le coût de maintenance supplémentaire lié à un autre backend
Cela demande des compétences séparées de celles du travail sur le compilateur Julia de haut niveau, et il arrive que l’intégration upstream des correctifs prenne du temps
Mais en pratique nous avons une relation assez bonne et productive avec l’upstream, et si nous avions décidé de supprimer LLVM, le projet aurait accompli bien moins de choses
En particulier, le support GPU et le support HPC, par exemple pour PPC, dépendent de LLVM
C’est pourquoi nous maintenons la position selon laquelle Julia doit être compilé avec notre jeu de patchs / notre fork, et nous n’investissons pas de temps dans les bugs produits par des builds Julia qui n’utilisent pas ces patchs. Cela arrive surtout souvent avec les builds de distributions
Ayant observé le travail sur des backends non LLVM dans d’autres langages, je trouve que la proposition liée dégage beaucoup trop d’arrogance
Si elle n’avait pas été écrite par cette personne, je l’aurais prise pour une issue GitHub vaguement rédigée par un débutant de Zig
Elle sous-estime la quantité de travail nécessaire, rabaisse implicitement tout le travail investi dans LLVM, et dégage à chaque phrase une forme de confiance bravache disant « bien sûr qu’on peut faire moins cher, plus vite et mieux ». C’est décevant
J’ai jusque-là beaucoup respecté le travail d’Andrew, donc j’essaie de lui accorder le bénéfice du doute en me disant qu’il l’a peut-être écrit dans la précipitation ou à chaud sans réaliser que cela se lirait ainsi
Mais ce texte n’inspire pas confiance et ne me rend pas plus enclin à regarder la proposition elle-même avec ouverture d’esprit
Webpack et esbuild en sont un exemple
Le bon moment pour construire quelque chose sans LLVM, c’était il y a quelques années. Mais aujourd’hui, retirer les fonctionnalités C++ risque de signer la fin de Zig
Je suis surpris qu’au lieu d’une suppression progressive ils n’aient pas annoncé un plan pour écrire leur propre compilateur C++ en Zig
Je ne suis même pas sûr qu’une personne qui commence à son 18e anniversaire puisse écrire un compilateur C++. Il ne lui resterait peut-être même pas assez de temps dans sa vie pour en faire un qui fonctionne
Zig ne cherche pas à devenir le nouveau C++ du monde, mais plutôt le nouveau C du monde
On peut aussi voir dans cette proposition que la compilation croisée en C continuerait d’être prise en charge
Ce choix est peut-être le bon. Le C est encore très utilisé aujourd’hui dans le monde de l’embarqué, et LLVM n’est pas bon dans ce domaine
Si j’étais Zig, je voudrais viser tous les microcontrôleurs, et c’est la seule voie réaliste pour y parvenir