El desarrollador de ARM Lorenzo Stoakes ha acelerado de forma notable la compilación del kernel de Linux tras recurrir a un modelo de lenguaje para localizar varios cuellos de botella que lastraban el proceso de construcción del sistema. El propio ingeniero admite, sin embargo, que el código que la herramienta generó para solucionar esos problemas resultó, en sus propias palabras, «hideous» (horrible), y tuvo que reescribirlo casi por completo antes de enviarlo a revisión.
Stoakes explicó el trabajo en un correo enviado a la lista de desarrollo del kernel. Si alguna vez habéis intentado compilar vuestro propio núcleo, sabréis que el proceso exige un rigor extremo, porque cualquier atajo mal resuelto puede introducir fallos silenciosos. Por eso el ingeniero empleó primero un modelo de lenguaje para identificar dónde se producían los atascos y, después, para plantear cómo corregirlos. «Se usó un LLM para determinar primero dónde estaban los cuellos de botella y luego para averiguar cómo mejorarlos. Generó mucho código, gran parte de él horrible. Lo audité y reescribí extensamente y edité en profundidad los mensajes de commit, la carta de presentación y los comentarios», escribió el ingeniero.
Buen diagnóstico pero se falló al programar la solución
Vamos a ver en qué consistía exactamente el problema. El origen estaba en el propio sistema de construcción del kernel, conocido como Kbuild: los archivos Makefile de la arquitectura Arm64 ejecutaban un número excesivo de llamadas a la función shell de GNU Make, y cada una de esas llamadas lanzaba un proceso externo que ralentizaba la compilación de forma acumulativa. El modelo de lenguaje ayudó a rastrear con precisión dónde se concentraban esas llamadas redundantes, un trabajo de perfilado que de otro modo habría llevado semanas.
La herramienta demostró ser mucho más fiable a la hora de localizar el origen del problema que a la hora de resolverlo. Buena parte del código que propuso no cumplía los estándares habituales del kernel, lo que obligó a una revisión exhaustiva antes de considerar el trabajo apto para su integración en el árbol principal de Linux. El modelo se encargó de ejecutar las compilaciones y depurar los primeros errores, pero todas las comprobaciones finales corrieron a cargo de Stoakes.
Los tiempos de compilación mejoran hasta un 90%
Los resultados, según relata el propio Stoakes, son contundentes. Las compilaciones allmodconfig, que comprueban la compatibilidad del núcleo con todos los módulos disponibles, se aceleraron hasta un 36 %. Las compilaciones incrementales, esas que hacemos cada vez que tocamos una línea de código y volvemos a compilar sin partir de cero, mejoraron alrededor de un 70 %.
El salto más llamativo se produjo en las compilaciones noop, que miden el tiempo que tarda el sistema en comprobar que no hay ningún cambio pendiente por aplicar: llegaron a ser hasta un 90 % más rápidas, una diferencia que cualquiera que compile el kernel a diario notaría de inmediato.
Stoakes señala que la mejora se percibe independientemente del equipo utilizado, lo que podría apuntar a que el cuello de botella residía en un mecanismo interno del proceso de construcción y no en una configuración de hardware concreta.
Debian exige responsabilidad a quien envíe código de IA
El caso de Stoakes llega en un momento en que el uso de inteligencia artificial en el desarrollo del kernel de Linux genera cada vez más debate dentro de la comunidad. Linus Torvalds recurrió recientemente a estas herramientas para corregir un error en el núcleo. En Debian, la discusión sobre el código generado por modelos de lenguaje no se ha resuelto con una votación formal que autorice su uso de forma explícita: la postura del proyecto sigue siendo que el desarrollador que firma y envía el código es el único responsable de su calidad y su correcto funcionamiento, sin importar cómo se haya generado.
Torvalds ha señalado en varias ocasiones que los modelos de lenguaje están mejorando notablemente a la hora de detectar fallos, hasta el punto de que los mantenedores del kernel reciben cada vez más informes sobre problemas menores que probablemente habrían pasado desapercibidos en una revisión manual. Como demuestra el trabajo de Stoakes, el diagnóstico automatizado funciona con solvencia, pero la generación de código limpio y listo para producción sigue dependiendo del criterio de un desarrollador humano.