LLVM se fait de vieux os ? La recherche pour rester jeune

a marqué ce sujet comme résolu.
Auteur du sujet

Il y a une discussion intéressante sur la liste de développement de LLVM ce mois-ci, partie du constat que les temps de compilation de LLVM augmentent au fil du temps – avec l’évolution du code. En particulier j’ai trouvé ce message de Daniel Berlin très intéressant: il parle du rapport entre les compilateurs industriels et la recherche en compilation, et de l’effet que ça peut avoir sur la maintenabilité du code. Traduction à la rache (le début est la citation d’un autre message):

Sean Silva a écrit:

Un truc qui m’a frappé en me promenant dans les sources de GCC est qu’il semble utiliser des algorithmes bien plus sophistiqués (par exemple beaucoup de fichiers ont des commentaires au début citant des articles de recherche et tout; compter les citations ne veut pas dire grand chose, mais c’est une approximation du fait de se tenir au courant de littérature scientifique). Dans LLVM, j’ai l’impression que la plupart des choses sont faites maison, ou en tout cas pas reprises très souvent pour utiliser un algorithme plus récent. Et une fois qu’on a accumulé un tas de petits cas particuliers, ça devient de plus en plus difficile de remplacer le code par une meilleure approche, parce que personne ne voudra jeter les vieux trucs tant que la nouvelle approche ne couvre pas au moins tous ces cas.

C’est précisément ce qui s’est passé avec la passe de Global Value Numbering (et qui se passe avec d’autres choses comme InstrCombine, LVI, BasicAA…). Toutes ces passes ont commencé avec un rôle clairement défini et une certaine durée de vie prévue. Elles avaient du sens pour ces usages. Et puis les gens les ont poussés au-delà de leurs usages initiaux, mais sans les reconcevoir ou les repenser. Très vite on se retrouve avec du désordre qu’il est très difficile de nettoyer pour les raisons que tu dis – en pratique, il faut découper les analyses ou les passes en plusieurs morceaux, et accepter qu’on ne peut pas et ne doit pas essayer de tout gérer en une seule passe.

Heureusement, il y a des entreprises et des gens dans notre communauté qui peuvent trouver le temps de travailler sur la "dette technique" (technical debt) au lieu de juste améliorer les performances, mais à mon avis on est toujours trop en faveur de la performance quel que soit le coût. Ça arrive à tous les compilateurs, bien sûr, pas juste à LLVM.

Sur la question de pourquoi GCC utilise plus la littérature scientifique, voici encore mon avis. GCC a plus de parties du code avec des mainteneurs/propriétaires attitrés que LLVM, ce qui a l’avantage qu’il y a quelqu’un qui réfléchit vraiment à ces choses et a un avis sur là où cette partie du code devrait aller. Les maintenurs peuvent diriger le développement, s’assurer que ça va dans la bonne direction. L’inconvénient bien sûr c’est que ça ajoute de la bureaucracie (mais LLVM a aussi de la bureaucracie je trouve, elle est juste mieux cachée), et parfoit un peu moins d’innovation (ça varie). Ça veut dire aussi que les gens ne doivent pas le voire comme un simple titre, quand ils passent à autre chose où s’en déintéressent il faut réassigner le code à quelqu’un d’autre. L’autre inconvénient c’est que souvent ces personnes se retrouvent à dire "non, on ne va pas faire comme ça, il faut plutôt faire comme ça", et ça ne plaît à personne quand la personne en face essaie juste de faire intégrer un changement qu’on lui a demandé de faire.

La seule chose que ces approches changent, en fin de compte, c’est la durée de vie du résultat final. Ça ne veut pas dire qu’on obtient quelque chose de parfait, mais on peut avoir un truc qui va bien marcher pour 10 ans, au lieu de bien marcher pour 5 ans seulement. Ça peut être ou ne pas être le bon choix, ça dépend de ce qu’on fait (ça ne sert à rien de passer 6 mois à concevoir un truc qui ne va pas être utilisé plus de 6 mois).

Enfin je ne veux pas dire, bien sûr, que le fait-maison est forcément mauvais. Mais le faire bien demande au moins d’avoir assez bien lu et compris la théorie sur le sujet, pour comprendre comment bien faire son propre truc, ou alors faire un truc si petit que ça n’a pas d’importance.

Personellement j’ai appris les compilateurs et l’optimisation dans un environnement où j’étais entouré de gens qui avaient en gros déjà tout fait avant, et donc j’ai appris à aller chasser pour voir quel est l’état de l’art sur un sujet, et les aspects théoriques derrière, avant de faire du fait-maison. Ça ne veut pas dire que cet état de l’art était toujours bon, raisonnable, ou même implémentable, mais au moins on y pensait, et souvent, même quand les articles étaient complètement dans les nuages, ils avaient des idées et des approches qu’on a pu réutiliser.

Que retirer de ce message ? Pas mal de choses. Que LLVM commence à prendre de l’age et que les gens ont du mal à maintenir certaines parties du code. Que GCC a su bien faire des choses dans son développement que les développeurs LLVM savent admirer. Que les articles de recherche, c’est parfois utile. Que les mainteneurs grincheux peuvent améliorer le résultat final mais aussi introduire un peu de friction dans le développement. Que les mailing-list où on écrit des messages détaillés, c’est toujours intéressant.

Édité par gasche

+16 -0

Salut.

Les points que tu souligne sont très pertinents, même si je n’irais personnellement pas jusqu’à dire que LLVM se fait de vieux os (je parle ici en tant qu’utilisateur de LLVM pour un projet relativement conséquent, et en tant que lecteur « hobbyiste » du code de LLVM).

LLVM commence à prendre de l’age et […] les gens ont du mal à maintenir certaines parties du code.

Je pense que cette dette technique, inhérente à tout projet de grande taille, n’est pas si conséquente que ça pour LLVM. À part certains éléments évoqués sur la liste de diffusion, le code est assez clean, et des gros refactoring se produisent à chaque nouvelle version. Donc selon moi, ça reste largement maintenable.

GCC a su bien faire des choses dans son développement que les développeurs LLVM savent admirer.

Oui. Même si les deux projets ont des philosophies radicalement opposées (enfin, surtout du côté de Clang mais ça déteint forcément sur LLVM), les inspirations mutuelles se produisent forcément et sont une bonne chose.

les articles de recherche, c’est parfois utile.

Un gros +1. Surtout dans un domaine comme la compilation et l’optimisation où énormément de choses sont encore à améliorer et à raffiner.

les mainteneurs grincheux peuvent améliorer le résultat final mais aussi introduire un peu de friction dans le développement.

C’est un mal nécessaire et un équilibre fragile à atteindre, selon moi. Avoir une ligne directrice stricte est important, mais il faut aussi faire preuve de pédagogie pour éviter de dégoûter les contributeurs, en particulier les nouveaux. Le problème du bus factor faible peut également se poser. L’équipe du langage Rust a écrit quelques articles là dessus, c’est très instructif (ça doit être quelque part sur leur blog).

les mailing-list où on écrit des messages détaillés, c’est toujours intéressant.

+1 aussi. À la fois pour les développeurs du projet pour discuter de choses importantes, et pour les personnes extérieures pour comprendre un minimum ce qu’il se passe et peut-être donner envie de s’impliquer.

Mon Github | Pony : Un langage à acteurs sûr et performant

+2 -0
Auteur du sujet

Sympa, tu travailles sur Pony ? Qu’est-ce que tu fais sur le projet ?

(J’aime bien la sécurité par capabilities depuis longtemps, donc je trouve que Pony est un projet intéressant dans ce cadre.)

+0 -0

Je fais partie de l’équipe de développement, oui (pas en tant que salarié, l’effort de développement est assuré par la communauté). Je fais principalement des ajouts au langage (via des RFC à la Rust) et des améliorations du générateur de code et de la bibliothèque d’exécution.

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte