Le développeur ARM Lorenzo Stoakes a considérablement accéléré la compilation du noyau Linux après avoir utilisé un modèle de langage pour localiser plusieurs goulots d'étranglement qui entravaient le processus de construction du système. L'ingénieur lui-même admet cependant que le code généré par l'outil pour résoudre ces problèmes était, selon ses propres mots, « hideux », et il a dû le réécrire presque complètement avant de l'envoyer pour révision.
Stoakes a expliqué le travail dans un e-mail envoyé à la liste de développement du noyau. Si vous avez déjà essayé de compiler votre propre noyau, vous saurez que le processus demande une extrême rigueur, car tout raccourci mal résolu peut introduire des pannes silencieuses. C'est pourquoi l'ingénieur a d'abord utilisé un modèle de langage pour identifier où se produisaient les embouteillages puis proposer comment les corriger. « Un LLM a été utilisé pour déterminer d'abord où se trouvaient les goulots d'étranglement, puis pour trouver comment les améliorer. Il a généré beaucoup de code, pour la plupart horrible. « Je l'ai audité et réécrit en profondeur et j'ai fortement modifié les messages de validation, la lettre de motivation et les commentaires », a écrit l'ingénieur.
Bon diagnostic mais échec de programmation de la solution
Voyons quel était exactement le problème. L'origine était dans le système de construction du noyau lui-même, connu sous le nom de Kbuild– Les Makefiles sur l'architecture Arm64 exécutaient un nombre excessif d'appels à la fonction shell GNU Make, et chacun de ces appels lançait un processus externe qui ralentissait cumulativement la construction. Le modèle linguistique a permis de suivre précisément où étaient concentrés ces appels redondants, un travail de profilage qui aurait autrement pris des semaines.
L’outil s’est avéré beaucoup plus fiable pour localiser la source du problème que pour le résoudre. Une grande partie du code qu'il proposait ne répondait pas aux normes communes du noyau, ce qui nécessitait un examen approfondi avant que le travail ne soit considéré comme apte à être intégré dans l'arborescence principale de Linux. Le modèle était responsable de l'exécution des builds et du débogage des premières erreurs, mais toutes les vérifications finales ont été effectuées par Stoakes.
Les temps de compilation s'améliorent jusqu'à 90 %
Les résultats, selon Stoakes lui-même, sont écrasants. Les builds allmodconfig, qui vérifient la compatibilité du noyau avec tous les modules disponibles, sont accéléré jusqu'à 36%. Les builds incrémentielles, celles que nous faisons à chaque fois que nous touchons une ligne de code et compilons à nouveau sans repartir de zéro, améliorées d'environ 70 %.
Le saut le plus frappant s'est produit dans les compilations noop, qui mesurent le temps nécessaire au système pour vérifier qu'il n'y a pas de modifications en attente à appliquer : elles ont atteint jusqu'à un 90% plus rapideune différence que quiconque compile quotidiennement le noyau remarquerait immédiatement.
Stoakes souligne que l'amélioration est perçue quel que soit l'équipement utilisé, ce qui pourrait indiquer que le goulot d'étranglement résidait dans un mécanisme interne du processus de construction et non dans une configuration matérielle spécifique.
Debian exige la responsabilité de quiconque soumet du code AI
Le cas de Stoakes intervient à un moment où l'utilisation de l'intelligence artificielle dans le développement du noyau Linux suscite de plus en plus de débats au sein de la communauté. Linus Torvalds s'est récemment tourné vers ces outils pour corriger un bug dans le noyau. Chez Debian, le débat sur le code généré par les modèles de langage n'a pas été résolu par un vote formel autorisant explicitement leur utilisation : la position du projet reste que le développeur qui signe et soumet le code est seul responsable de sa qualité et de son bon fonctionnement, quelle que soit la manière dont il a été généré.
Torvalds a noté à plusieurs reprises que les modèles de langage s'améliorent sensiblement dans la détection des bogues, au point que les responsables du noyau reçoivent de plus en plus de rapports faisant état de problèmes mineurs qui seraient probablement passés inaperçus lors d'une révision manuelle. Comme le démontrent les travaux de Stoakes, le diagnostic automatisé fonctionne de manière fiable, mais la génération d'un code propre et prêt pour la production dépend toujours du jugement d'un développeur humain.
FAQ sur l'IA du noyau Linux Les builds Allmodconfig étaient jusqu'à 36 % plus rapides, les builds incrémentielles étaient jusqu'à 70 % plus rapides et les builds noop étaient jusqu'à 90 % plus rapides.
Car, bien que le modèle de langage ait correctement identifié les goulots d'étranglement dans Kbuild, une grande partie du code qu'il proposait pour les corriger ne répondait pas aux normes du noyau et a dû être presque entièrement réécrit.
Debian n'a pas passé de vote formel autorisant explicitement l'utilisation de l'IA ; La position du projet reste que le développeur qui signe et soumet le code est seul responsable de sa qualité, quelle que soit la manière dont il a été généré.
Quelles améliorations de performances Lorenzo Stoakes a-t-il obtenues dans le noyau Linux ?
Pourquoi Stoakes a-t-il qualifié le code généré par l'IA de « hideux » ?
Debian autorise-t-elle la soumission de code généré par des modèles de langage ?