mold 2.0.0 - enlazador de alta velocidad

• La licencia cambió de AGPL a MIT, convirtiéndose en el cambio principal de mold 2.0.0
• Se corrigió un bug que impedía crear archivos objeto con más de 65,520 secciones al usar --relocatable
• -undefined ahora se interpreta como sinónimo de --undefined en lugar de -u ndefined, alineándose con el comportamiento de GNU linkers y LLVM lld
• -nopie ahora se trata como sinónimo de --no-pie
• Soporte en RISC-V para los tipos de reubicación R_RISCV_SET_ULEB128 y R_RISCV_SUB_ULEB128
• Soporte en PPC64 para el tipo de reubicación R_PPC64_REL32

[GN⁺]

Opiniones en Hacker News

• mold es un trabajo realmente excelente para sistemas modernos.
  Hace poco, al intentar acelerar las compilaciones de un proyecto, me di cuenta de que la etapa de enlace era un cuello de botella enorme. Aunque uso 24 núcleos * 2 hilos, alrededor del 30% del rendimiento total queda ocioso por culpa del linker.
  Antes había intentado compilar con mold, pero en ese momento no funcionó bien; pienso volver a intentarlo.

  • Mold es impresionante. Hace unos meses estuve trabajando con O3DE y probé cambiar a Mold para ver si podía reducir el ciclo de compilar-ejecutar, y definitivamente se volvió más rápido.
    No recuerdo las cifras exactas, pero era una diferencia bastante grande: algo que con gold y lld tardaba varios segundos bajó a menos de 1 segundo con mold.
  • En la empresa también hicimos algunas pruebas de concepto, y en una máquina pequeña de builds de prueba, el tiempo de compilación completo de la capa de UI bajó de 44–45 minutos a 29 minutos al cambiar de lld a mold.
    Era código C++/Qt complejo.
  • mold -run ninja funciona muy bien en mi entorno.

• Me alegra mucho ver el cambio de licencia. Espero que el proyecto también pueda generar ingresos, pero con una licencia MIT aumenta mucho la posibilidad de integrarlo en proyectos de trabajo.
  Si realmente terminamos usándolo, pienso intentar convencer a la empresa de patrocinar este proyecto.

  • La licencia de un linker no debería importar demasiado. No inyecta código con copyright, y en el ecosistema GPL ya hay precedentes de considerar como excepción el boilerplate trivial, así que no hay razón para que el binario generado se vea afectado por la licencia copyleft de la herramienta.
    AGPL probablemente solo impondría restricciones al distribuir como servicio de red un linker modificado en privado, lo cual no es un escenario realista para una herramienta básica de desarrollo.

• Me da curiosidad el cambio de licencia. ¿Esto no es un ejecutable? Llamarlo como un proceso separado no obliga a que el software que lo invoca sea GPL, así que en los casos normales la transición a MIT no debería tener impacto.
  Si los autores realmente querían una licencia más permisiva, en vez de relicenciar de AGPL a MIT, deberían haber cambiado a AGPL con una excepción de enlace. Un ejemplo de proyecto GPL con excepción de enlace es libgit2: https://github.com/libgit2/libgit2#license
  Ese tipo de licencia es más permisiva y, al mismo tiempo, todavía permite vender licencias comerciales a quienes quieran hacer cambios de código cerrado.

  • Creo que el punto central es que los autores ya no quieren seguir vendiendo licencias. Parece que no valía la pena frente a las molestias.
    La versión para macOS, sold, parece ser la excepción.

• Este linker mejora notablemente la satisfacción de desarrollo en mi repositorio Rust de exploración, que está camino a convertirse en un gran monolito web usando SeaORM y axum/tokio.
  No querrías saber el tamaño de mi directorio target, pero las compilaciones incrementales se sienten mucho más ágiles.

  • Tendré que probar mold un poco.
    15:55 $ du -Hs --si target/
11G target/

• Mold es excelente, y tengo algunos usos favoritos.

  1. Acelera las compilaciones de Rust.
     [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=-fuse-ld=mold",
"-C", "target-cpu=native"
]
  2. En ArchLinux, agregar "-fuse-ld=mold" a CFLAGS también acelera makepkg.
  • ¿Hay alguna forma de sobrescribir esta configuración del linker solo para una instalación local? No quiero cambiar el código ni los binarios de producción, pero me gustaría que las compilaciones fueran más rápidas.
  • Me da curiosidad cuánto cambió el tiempo de enlace de Rust antes y después.
  • ¿Cómo se compara esta última versión con lld? ¿También puede ejecutarse en alpine/musl?

• Es una decisión muy sensata. A veces también hay momentos difíciles en los que tengo que admitir que algunas cosas de mi producto o código no encajan con la monetización.
  El mercado te lo dice, y aunque es una lástima, en vez de pelear contra eso es importante encontrar otra cosa que el mercado sí recompense.

• ¿Alguien sabe si este cambio de licencia/estrategia de negocio también se aplicará a sold? sold es mold para macOS.
  https://github.com/bluewhalesystems/sold

  • Apple tiene un nuevo linker paralelo, que quizá podría interesarles, o quizá no.
    https://twitter.com/davidecci/status/1665835119331135488
  • Si miras la parte superior del README de mold, mi impresión es que no será open source.
    “Este repositorio contiene la versión gratuita del linker mold. Si buscas una versión comercial con soporte para macOS, visita el repositorio del linker sold”.
  • No entiendo por qué Apple no patrocina este proyecto y lo convierte en el linker predeterminado de Xcode.
    Podrían pagarles bien por el trabajo y hacer del mundo un lugar mejor.
    Para Apple debería ser demasiado fácil.

• La licencia cambió de AGPL a MIT.
  Pero ¿cómo deberían recompensarse artesanos tan excelentes como este, y por qué todavía no ocurre? Creo que las empresas, sin importar su tamaño, deberían asignar cierto presupuesto a dependencias o herramientas clave y publicarlo en su sitio web oficial. Parece que hace falta más una especie de norma cultural.

• Había olvidado que este era un linker rápido.
  “Mold 2.0.0 es una nueva versión mayor de nuestro linker de alta velocidad. En esta versión, cambiamos la licencia de AGPL a MIT con el objetivo de ampliar nuestra base de usuarios. Como sabrán quienes han seguido el avance, no fue una decisión fácil, porque veníamos intentando monetizar el producto con un modelo de doble licencia AGPL/comercial. Lamentablemente, este enfoque no estuvo a la altura de las expectativas. El cambio de licencia es el resultado de aceptar esta realidad. No queremos seguir insistiendo en una estrategia que no funcionó bien.”

  • ¿Alguien recuerda los tiempos en que había que pagar el costo de cc en Solaris? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
    Era horrible, y también una forma pésima de tratar a los desarrolladores que escribían software para tu propio SO.
    Durante muchísimo tiempo nos acostumbramos a no pagar por herramientas de desarrollo de bajo nivel y, en cambio, a pagar por soporte. Me sorprende que siquiera hayan intentado una licencia de ese estilo.

• Durante mucho tiempo vi varias discusiones sobre linkers rápidos y relatos de que, al cambiar un linker por otro más rápido, el tiempo de compilación se reducía mucho, pero en general nunca entendí bien por qué un linker es lento.
  Me gustaría que alguien pudiera explicarlo.

  • No es una explicación completa, pero el linking es intensivo en CPU y los linkers antiguos suelen ser de un solo hilo.
    Una buena parte de la mejora de rendimiento viene de procesar el trabajo en paralelo, y en las CPU modernas y potentes de varios núcleos eso se traduce en una gran mejora.
    Si quieres saber más, hay una buena charla de Rui sobre Mold: https://www.youtube.com/watch?v=hAt3kCalE0Y
  • En el caso ideal, un linker debería ser tan rápido como cat. Al fin y al cabo, solo tendría que concatenar binarios y listo. En la época de los discos giratorios, la E/S de disco era el problema, pero hoy lo es menos.
    Lo que toma tiempo es reescribir contenido durante el proceso. Recorrer la tabla de relocaciones e insertar direcciones en el código es barato, y el dead stripping a nivel de sección también es bastante barato, pero para hacer dead stripping de bloques básicos individuales dentro de una función se necesita mucho más análisis, y eso toma tiempo.
    La deduplicación de cadenas constantes es una buena idea, pero hay que pasarlas todas por alguna forma de tabla hash. Si además quieres compartir sufijos comunes, el trabajo aumenta.
    La deduplicación, el dead stripping y la reescritura de información de depuración también toman tiempo. Una compilación de depuración puede contener varios GB de DWARF que hay que reescribir.
    Curiosamente, el hecho de que el linker sea programable y se le pueda pasar un programa para interpretar no parece ser un gran costo. Probablemente porque esos scripts son bastante cortos y sus funciones están algo limitadas.
    Históricamente, lld era muy rápido porque hacía poco procesamiento de información de depuración y poca otra deduplicación. lld corría rápido, pero los binarios de salida eran grandes.
    Hace años que dejé de trabajar en rendimiento de linking, así que no conozco bien el estado actual. En particular, no sé dónde se ubican mold o lld en el equilibrio entre calidad de salida y su propio rendimiento.
  • El mejor material que leí fue un blog de Ian Taylor sobre su trabajo en el linker gold.
    https://www.airs.com/blog/archives/38
    “Una vez más, el objetivo es la velocidad. En este caso, ser más rápido que mi segundo linker. Ese linker se volvió considerablemente más lento con los años a medida que se le agregaron ELF y soporte para bibliotecas compartidas. Ese soporte no fue diseñado desde el principio, sino añadido después. Los planes futuros para el nuevo linker también incluyen soporte para linking incremental, que es otra forma de aumentar la velocidad.”
    Basta con pensar en las apps de los primeros tiempos de Unix. Eran apps simples, de un solo propósito, probablemente un solo archivo fuente, un solo objeto, solo había que linkear libc, y no existían cosas como las bibliotecas compartidas.
    Después, a medida que se agregaron funciones “imprescindibles”, el código del linker creció de forma orgánica. Sobre todo en la época en que los discos giratorios eran el cuello de botella, la corrección de las funciones importaba más que la velocidad.