El equipo de compiladores de AMD está proponiendo una nueva opción para el compilador LLVM Clang, -fenable-readonly-thp, destinada a implementar páginas gigantes transparentes de instrucciones, o iTHP, en tiempo de compilación y de enlazado. Con esta bandera, la compañía está encontrando más rendimiento en SPEC CPU, Geekbench y otras cargas de trabajo, a partir de alinear los segmentos a 2 MiB durante el enlazado y permitir que el rango de texto ejecutable se promueva a páginas gigantes.
¿Qué problema resuelve exactamente?
Bhuvanendra Kumar N, del equipo de tecnologías de compiladores de AMD, anunció la propuesta como el paso más reciente para exprimir rendimiento de la cadena de herramientas de LLVM. Así lo explicó en su publicación de solicitud de comentarios (RFC):
"Proponemos una funcionalidad opcional de Clang, -fenable-readonly-thp, que implementa iTHP (páginas gigantes transparentes de instrucciones) en tiempo de compilación y enlazado. El controlador organiza la alineación de segmentos a 2 MiB o más durante el enlazado, enlaza un pequeño objeto de arranque y, al iniciar el proceso, llama a madvise(MADV_COLLAPSE) sobre el rango de texto ejecutable para que el kernel pueda promover los mapeos de páginas de 4 KiB por defecto a páginas gigantes".
El razonamiento técnico apunta a un cuello de botella concreto: "Los binarios grandes con huellas de instrucciones extensas pueden quedar limitados por el frontend debido a la presión sobre el iTLB que generan los mapeos de texto de 4 KiB. Linux puede promover regiones .text ejecutables elegibles a páginas de 2 MiB cuando se cumplen los requisitos de alineación y el proceso lo solicita mediante madvise(). Hoy esto requiere scripts de enlazador manuales y código de arranque personalizado. Una vía opcional gestionada por el compilador vuelve práctica la optimización para builds de producción".
¿Cuánto rinde y a qué costo?
Ya existe un prototipo del parche, creado y probado. No se compartieron cifras firmes de rendimiento como parte del anuncio del RFC, pero sí se describieron las ganancias en términos generales:
"Medimos mejoras de rendimiento con SPEC CPU 2026, Geekbench y otros benchmarks (CPython, cargas de base de datos y servidor, pruebas microarquitectónicas). Las ganancias dependen de la carga de trabajo, y son más fuertes en cargas con .text grande, como intérpretes, simuladores y binarios de tipo compilador; algunas cargas quedan sin cambios. No vimos regresiones amplias en nuestras pruebas".
Esto viene, eso sí, con el costo potencial de binarios más grandes y una pequeña sobrecarga al momento del arranque. Con esta opción para el uso de iTHP, el funcionamiento pleno requiere Linux 7.2 o posterior, porque las versiones anteriores del kernel solo trabajan con iTHP desde almacenamiento basado en TMPFS.
La diferencia con BOLT
Aunque el optimizador de disposición de binarios BOLT puede entregar algunas optimizaciones que mejoran el rendimiento del iTLB, a diferencia de BOLT la opción -fenable-readonly-thp no requiere ningún perfilado de la carga de trabajo ni nada similar. Esa es la ventaja práctica de la propuesta: BOLT exige ejecutar el binario con una carga representativa, recolectar el perfil y reoptimizar, un ciclo que muchos equipos no incorporan a su proceso de construcción.
| Método | Requiere perfilado | Cambia el binario | Dependencia de kernel |
|---|---|---|---|
| BOLT | Sí, con carga representativa | Reordena el código | No |
| -fenable-readonly-thp | No | Solo alineación y objeto de arranque | Linux 7.2 o posterior |
Un ingeniero de compiladores de Google respondió que ellos desarrollaron una biblioteca que ejecuta un enfoque similar al que busca AMD. La apuesta de AMD es incorporar esto a las cadenas de herramientas de LLVM aguas arriba, y potencialmente también a las de GNU, en lugar de requerir otra biblioteca externa instalada en el sistema.
Por qué le importa a quien compila en la región
La lectura práctica es que se trata de una optimización gratuita en esfuerzo de ingeniería, pero condicionada por la versión del kernel. Un servidor de producción corriendo una distribución estable de soporte extendido, que es el escenario habitual en infraestructura local, difícilmente esté en Linux 7.2, así que el beneficio quedará por un buen tiempo restringido a quienes siguen kernels recientes.
El perfil de carga que más gana también es específico: intérpretes y binarios grandes. Eso significa que un servidor de aplicaciones Python o un motor de base de datos son candidatos naturales, mientras que un microservicio compilado y pequeño, cuyo .text cabe holgado en el iTLB, probablemente no note diferencia alguna.
Habrá que ver hacia dónde lleva la discusión y si logra integrarse aguas arriba. Quienes tengan interés en la propuesta inicial pueden encontrarla en LLVM Discourse.
