Se introduce la generación de código de Cranelift en Rust

• Cranelift es un backend de generación de código con licencia Apache-2.0, desarrollado como parte del runtime Wasmtime para WebAssembly
• En octubre de 2023, el proyecto Rust comenzó a ofrecer Cranelift como un componente opcional del toolchain nightly
• Ahora los usuarios pueden usar Cranelift como backend de generación de código para builds de depuración de proyectos escritos en Rust
• Cranelift compite con los compiladores existentes y genera código más rápido gracias a un diseño simplificado que prioriza solo las optimizaciones importantes

La importancia del tiempo de compilación

• Los usuarios de lenguajes de programación quieren tiempos de compilación rápidos
• Rust, al igual que otros lenguajes que usan LLVM, ha tenido quejas sobre sus tiempos de compilación
• Un compilador que genera código lo suficientemente rápido puede tener ventajas frente al uso de un intérprete
• Un compilador enfocado en la velocidad de compilación puede ser valioso

Las optimizaciones de Cranelift

• Cranelift realiza optimizaciones de varias maneras durante la generación de código
• Su pipeline de optimización se basa en E-graphs, una estructura de datos que representa de forma eficiente conjuntos de representaciones intermedias
• En los compiladores tradicionales, el orden de las optimizaciones influye mucho en la calidad del código generado
• Cranelift usa E-graphs para que el orden de las optimizaciones no afecte el resultado
• Extraer la representación final de un E-graph es un problema NP-completo, pero Cranelift usa heurísticas para extraer rápidamente una representación suficientemente buena

Cranelift para Rust

• El esfuerzo para usar Cranelift como backend de Rust fue considerable
• El compilador de Rust usa un IR de nivel medio para representar programas con verificación de tipos
• Para usar Cranelift, se necesitaba una biblioteca que convirtiera el IR de nivel medio a CLIF
• Esta biblioteca fue escrita principalmente por "bjorn3", integrante del equipo del compilador de Rust
• Los usuarios pueden probar el backend de Cranelift usando rustup y cargo.

La opinión de GN⁺

• La introducción de Cranelift puede verse como una respuesta a la demanda constante dentro de la comunidad de Rust por reducir los tiempos de compilación. Esto puede contribuir a mejorar la productividad de los desarrolladores.
• El enfoque de Cranelift para resolver el problema del orden de optimización mediante E-graphs plantea un nuevo paradigma en el diseño de compiladores. Esto podría abrir nuevas direcciones para la investigación y el desarrollo de compiladores.
• Desde una perspectiva crítica, todavía hace falta validar con más casos de uso reales qué tan estable y eficiente es Cranelift frente a LLVM.
• Entre otros backends de compilador con funciones similares a Cranelift está libgccjit de GCC, y compararlo con estas alternativas puede ayudar a entender con mayor claridad sus ventajas y desventajas.
• Los desarrolladores que adopten Cranelift deben considerar la compatibilidad con la infraestructura existente basada en LLVM y el costo de migración, además de evaluar cuidadosamente su rendimiento y estabilidad.

[GN⁺]

Opiniones en Hacker News

• El backend y la optimización pueden usarse de forma distinta para diferentes crates. Para las dependencias, a menudo tiene sentido usar una build optimizada con LLVM, y para tu propio código usar LLVM en modo debug o Cranelift.
• Un artículo que ofrece un excelente panorama sobre la velocidad de optimización frente a la calidad de la optimización. En particular, la compilación copy-and-patch que usa código precompilado sigue siendo la más rápida, pero deja menos margen para optimizar. Cranelift permite más optimizaciones que el enfoque copy-and-patch al usar e-graphs para representar equivalencias en el IR. La salida más optimizada probablemente seguirá viniendo de toolchains de compiladores tradicionales como LLVM o GCC, pero para quienes quieren obtener resultados "lo suficientemente rápidos" lo antes posible, estas nuevas técnicas de compilación ofrecen una alternativa prometedora.
• Hay muchos comentarios sobre las builds debug completas, pero creo que la diferencia más importante está en el tiempo de build incremental para cambios pequeños. Eso es lo que acelera la iteración de desarrollo. Al comparar los tiempos de build tras hacer pequeños cambios en rust-analyzer y el proyecto gleam, agregar Cranelift y mold mostró mejoras mucho más rápidas. Incluso comparado con Terraform, construido con Go, se ve una gran mejora para Rust.
• Actualmente no hay soporte para Mac M1-M3 y tampoco parece haber soporte para Windows. La actualización más reciente del colaborador más activo deja una conclusión ambigua. El soporte para Windows está omitido por ahora, y en macOS solo se soporta x86_64 por el momento. Si usas un procesador M1, puedes intentar instalar la versión x86_64 de rustc y usar Rosetta 2, pero como Rosetta 2 puede afectar el rendimiento, habría que compararlo con el backend LLVM.
• En el proyecto Bevy probaron las instrucciones del artículo y lo compararon con una build "normal". La build release parecía más rápida que la build Cranelift+debug, pero eso era porque usaban sccache y cacheaban en un NAS local. Cuando volvieron a probar solo la build debug sin caché, el tiempo de compilación se redujo casi a la mitad.
• A través del enlace sobre Equality Graphs descubrí ESC/Java. Me pregunto si alguien realmente lo ha probado o ha tenido éxito con él. Sería interesante compararlo con Spot bugs (antes conocido como Findbugs).
• Me entusiasma mucho que las builds debug con Cranelift puedan acelerar la velocidad de iteración en el desarrollo. Esto es especialmente importante en Rust para WASM/frontend, donde la velocidad de iteración importa mucho, y la nueva era de herramientas de Rust a veces ofrece builds de menos de un segundo. Como todavía no hay soporte para ARM macOS, los usuarios de M1-M3 tendrán que esperar un poco.
• Me pregunto si existe algún benchmark del runtime al usar Cranelift, no del tiempo de compilación. El artículo menciona que es "dos veces más lento", pero esos datos son de 2020. Me da curiosidad saber si ha mejorado bastante desde entonces.
• Me pregunto si alguien puede explicar por qué se esperaría que Cranelift sea más rápido que LLVM y por qué esas mejoras no podrían aplicarse también a LLVM.