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.
