veilletech.frCe qui se passe
L'argument circule largement : les modèles de langage produisent du code lent et boursouflé, et la « bloat » logicielle va s'aggraver. Dan Luu prend le problème par l'autre bout.
Ce qui a changé, écrit-il, n'est pas la qualité moyenne du code produit. C'est le coût du travail de performance, tombé de plusieurs ordres de grandeur. Un travail qui exigeait une personne — ou une équipe — aux compétences rares peut désormais être lancé par quiconque sait écrire quelques phrases.
Le mécanisme : la spécialisation redevient rentable
Historiquement, on optimise pour une classe de charges de travail. Écrire un compilateur à la volée, ou un moteur taillé pour un cas précis, coûtait trop cher pour tout sauf les projets les plus lucratifs ou les plus vastes.
Quand ce coût s'effondre, l'arbitrage change : on peut ajuster le logiciel à une charge précise plutôt qu'à une famille de charges. Marc Brooker, cité dans l'article, rapproche la perspective de FFTW et des techniques de la demoscene, qui visaient à être très rapides sur un problème très particulier.
Michael Malis fait l'observation complémentaire : la rareté des compilateurs JIT donne à penser qu'en écrire un était historiquement trop difficile pour en valoir la peine. Si la barrière tombe, ce qu'on ose construire change de nature.
L'expérience
Dan Luu applique l'idée à FRE, un moteur d'expressions régulières produit lors d'un billet précédent en laissant un agent boucler un mois sur l'amélioration des performances, avec accès à la suite de tests rebar. Le résultat était massivement surajusté à rebar, jusqu'à ce que l'agent soit averti de l'existence d'un jeu de test gardé de côté, ce qui l'a forcé à généraliser.
Le détail intéressant : la version compilée nativement en avance de phase tenait bien sur les recherches longues. D'où l'expérience : lancer le compilateur de code natif dans un autre fil pendant que ripgrep tourne avec son moteur habituel, puis basculer une fois la compilation terminée. On perd un fil sur les requêtes courtes — un arbitrage assumé, l'auteur se souciant davantage des recherches qui durent des minutes que de celles qui durent deux secondes.
L'opération, « une bonne dose de chirurgie » pour un humain, a été réalisée par un agent à partir de quelques phrases.
Le chiffre honnête
C'est ce qui fait la valeur du billet : l'auteur ne s'arrête pas au chiffre flatteur.
- Sur quelques requêtes simples et longues : 2× à 4× plus rapide.
- Sur un jeu de requêtes réelles gardé de côté, tirées de son propre historique, pour les cas où la compilation anticipée devrait s'activer : environ 7 % de gain.
Sept pour cent, ce n'est pas un résultat spectaculaire. Mais rapporté à quelques minutes de frappe, c'est un rapport que personne n'obtenait auparavant. Et l'auteur note que l'optimisation, superficielle parce qu'il a laissé l'agent faire à sa guise, donnerait davantage avec un plan plus détaillé.
La lucidité sur la méthode
L'article se saborde volontairement à plusieurs endroits, et c'est ce qui le rend utile.
Construire un index serait évidemment plus malin que d'écrire un compilateur de code natif pour de la recherche de texte répétée. L'auteur le dit lui-même : le propos n'est pas que cette optimisation soit la bonne, c'est que ce type de travail technique est devenu trivial à lancer.
Il ajoute une réserve de méthode qui vaut pour tout le monde : les compétences d'expérimentation et de mesure des meilleurs modèles ne suffisent pas, dans le cas général, à monter seuls un environnement de benchmark correct. Il faut un humain — ou un skill — pour le préparer. Sans cela, on obtient un surajustement au benchmark, exactement ce qui était arrivé à FRE.
Et il rappelle, en note, l'ordre de priorité raisonnable : les gains simples d'abord. Réduire une page d'inscription de 50 Mo à 5 Mo lui avait rapporté environ 0,5 % de revenu en test A/B — il y a probablement beaucoup de chantiers à meilleur retour que d'écrire des compilateurs sur mesure.