Wild responde a los benchmarks de mold: la diferencia está en cómo se mide

David Lattimore, responsable del enlazador Wild, ha publicado un análisis de los benchmarks que mold actualizó el 28 de agosto y en los que Wild aparece por primera vez, bastante por detrás. Su conclusión es que buena parte de la diferencia está en cómo se monta la prueba, no en que Wild se haya vuelto lento de un mes para otro.

Los dos conjuntos de cifras no se midieron igual. mold corrió sus pruebas en dos máquinas: un Threadripper de 64 núcleos (128 hilos) con Ubuntu 24.04 y un Apple M1 Ultra con Asahi Linux. Wild publicó las suyas en un Ryzen 9955hx de 16 núcleos (32 hilos) con Ubuntu 26.04. Hasta ahí, hardware distinto y diferencias esperables. El problema son las tres decisiones de configuración que van por debajo.

Qué cambia en la medición

La primera es el fichero de salida. Los benchmarks de Wild dejan el binario de la ejecución anterior en su sitio; los de mold lo borran antes de cada invocación. La segunda es el sistema de ficheros: Wild venía midiendo sobre tmpfs, algo que Lattimore admite que fue un error, porque casi nadie compila ahí; mold usa ext4. La tercera es --no-fork: mold lo pasa siempre, y Wild solo cuando mide consumo de memoria, dejando el comportamiento por defecto (fork al arrancar) cuando mide tiempo.

Para comprobar cuánto pesa cada cosa, replicó las pruebas en un M1 de 16 núcleos con ext4, borrando el fichero y con --no-fork, es decir, la configuración de mold. Los ratios Wild/mold que salen son casi idénticos a los del otro equipo: 1,2x en blender-debug, 1,2x en godot-debug (mold daba 1,3x), 0,9x en blender-release y 1,0x en clang-release.

Después desglosó clang-release cambiando un ajuste cada vez. Con ext4, borrado y --no-fork, Wild tarda 0,21 s frente a 0,20 s de mold (1,0x). Sin borrar el fichero, 0,14 s (0,7x). Sobre tmpfs, sin borrar y con fork por defecto, 0,11 s frente a 0,19 s: 0,6x. Es decir, Wild gana justo en la configuración contraria a la que usa mold, y eso se debe a que le faltan los ajustes específicos del sistema operativo que hacen rápido crear y escribir un fichero nuevo fuera de tmpfs: usar fallocate para reservar espacio y hugepages para mapearlo. Lattimore los describe en el artículo sobre mold y dice que ya están implementados en Wild, pendientes de la próxima versión.

mold también se ha movido

Queda el otro factor. Lattimore comparó todas las versiones de ambos enlazadores del último año y comprobó que mold ha ganado bastante velocidad en las versiones 2.42.0 y 2.42.1. Los benchmarks que Wild publicó el 4 de agosto son anteriores a esas versiones, así que parte de la brecha es simple cronología.

Lo que no ha podido reproducir son los resultados del Threadripper. No tiene ese hardware, y sospecha que la diferencia extra viene de que Wild corre con 128 hilos mientras mold usa 32; en su máquina de 32 hilos, Wild solo mejora marginalmente al pasar de 24 a 32. Lo dice él mismo: es conjetura. Quien tenga un Threadripper a mano tiene trabajo.