Tu código es rápido... si tienes suerte

Un hilo viral cuestiona la fiabilidad de los micro-benchmarks: el mismo código puede variar un 30% según el orden de los símbolos, la posición en memoria o el nombre de usuario. Lo que esto cambia para el *craft*.

En términos simples

Un desarrollador demostró que un mismo fragmento de código puede ser un 30 % más rápido o más lento según parámetros que no tienen nada que ver con el algoritmo: orden de los símbolos en el enlace, tamaño de las variables de entorno, alineación de memoria. En otras palabras, gran parte de lo que medimos en microsegundos depende de la suerte.

La historia

El autor, en tiki.li/blog/lucky_code, retoma un hilo ya conocido en el mundo de los compiladores (Emery Berger, Stabilizer, ASPLOS 2013) y lo actualiza: ejecuta un mismo binario, sin modificarlo, y varía parámetros periféricos (nombre del directorio de compilación, orden de enlace de los archivos objeto, tamaño de $PATH). Los tiempos de ejecución varían significativamente, hasta más de un 30 % en micro-benchmarks. La causa: la alineación de las instrucciones en las cachés L1i/uop, el decodificador x86 y la predicción de saltos, que son sensibles a la dirección virtual del código.

Lo que debería molestar a todo el mundo: en la vida real, comparamos un PR antes/después, anotamos una mejora del 8 %, y hacemos merge. ¿Cuántas de esas mejoras son señal real? ¿Cuántas son ruido de alineación?

Bajo el capó

• Stabilizer (Berger 2013) randomiza la asignación de stack, heap y código en cada ejecución: las mediciones se convierten en distribuciones, no en puntos.
• Hyperfine + -warmup + -runs 50 NO resuelve el problema: promedia, pero la alineación sigue siendo la misma en cada ejecución de un mismo binario.
• La buena práctica: recompilar con offsets aleatorios (Stabilizer, o padding manual) O ejecutar con -randomize-address y reportar un IC 95 %, no un promedio.

Entonces, ¿qué?

Tres consecuencias para el oficio. Uno: cualquier mejora de rendimiento inferior al 10 % en un micro-benchmark único probablemente es ruido. Rechazarla o repetirla con randomización. Dos: las regresiones de rendimiento en CI (como Codspeed) deben adoptar la randomización, o dejaremos pasar regresiones reales y entraremos en pánico por ruido. Tres: los benchmarks de marketing de compiladores y runtimes (Bun vs Node, Zig vs C…) deben leerse con este filtro. El rendimiento, a este nivel, depende tanto de la ingeniería de compilación como del algoritmo.