krabby: crear un compilador de Rust rápido

 (bal-e.org)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Krabby es una implementación de un compilador de Rust desde cero y orientado al rendimiento, que busca mejorar la lenta velocidad de compilación de rustc
  • Las mejoras perceptibles de rendimiento en rustc ahora provienen más de cambios en APIs y estructuras de datos que de modificar una sola función, pero los cambios a gran escala son difíciles por el tamaño del código base y los requisitos de estabilidad
  • Krabby busca rediseñar juntos los componentes del compilador en un código base pequeño controlado por una sola persona, sin priorizar la estabilidad, para encontrar nuevas oportunidades de optimización y una arquitectura más cohesionada
  • El objetivo es poner a prueba, incluso en un lenguaje tan complejo como Rust, la hipótesis de que para mejorar de forma importante el rendimiento de un compilador hay que replantear por completo su diseño
  • El código está publicado en el repositorio de krabby en Codeberg, y el objetivo es publicar avances en Fediverse al menos una vez cada 1 o 2 semanas

Objetivos y contexto de Krabby

  • Rust es el lenguaje preferido del autor, pero el compilador rustc es notablemente lento
  • Ya hay muchas personas trabajando en mejorar el rendimiento de rustc, y las mejoras que pueden elevar de forma perceptible el rendimiento cambiando una sola función están casi todas implementadas
  • Las mejoras significativas ahora vienen de cambios en APIs y estructuras de datos, pero en un código base grande como rustc, los cambios amplios son en la práctica difíciles por el desarrollo simultáneo de múltiples funciones y por los requisitos de estabilidad
  • Krabby es una implementación de compilador de Rust desde cero con prioridad en el rendimiento, y sus objetivos son fundamentalmente distintos de los de rustc
  • Como se trata de un código base pequeño controlado por una sola persona y que no prioriza la estabilidad, el enfoque es diseñar todos los componentes teniendo en cuenta su relación mutua para encontrar nuevas oportunidades de optimización y construir una arquitectura más cohesionada
  • Parte de la hipótesis de que, para mejorar de forma importante el rendimiento de un compilador, es necesario replantear por completo su diseño
  • También busca mostrar que las optimizaciones arquitectónicas a gran escala pueden estar ocultas sin importar el lenguaje objetivo, y que esto puede aplicarse no solo a lenguajes simples como C, sino también a uno tan complejo como Rust
  • Incluso si el diseño resultante termina estando especializado para Rust, considera que lo aprendido en el proceso tendrá valor

Estado del proyecto y materiales públicos

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Opiniones en Lobste.rs

  • Parece que todos quieren tener su propia licencia de vanidad https://codeberg.org/bal-e/krabby/…

    • Para un proyecto de hobby puede estar bien, pero sí da la señal de que este proyecto va más por el lado de un proyecto casual que de algo serio
      Esta licencia permite gratis el uso y la distribución con fines personales y no comerciales, pero también exige que el software construido sobre ella se comparta bajo las mismas condiciones, y para fines comerciales solo permite una prueba de 30 días
      Me pregunto si Codeberg exige condiciones estrictas de libre/open source para las licencias de los proyectos. Tenía entendido que Codeberg solo hospeda FOSS, así que la restricción de uso no comercial me sorprendió, aunque puede que no esté al día con la situación actual
    • Sí, lo sé... llevo bastante tiempo dándole vueltas al tema de la licencia y estoy considerando cambiarla a AGPL mientras todavía sigo trabajando solo en esto

  • Rust es grande. Este proyecto parece un poco más fácil que “hacer tu propio navegador web”, pero de ninguna manera es algo fácil. Aun así, valoro que apunte alto
    Al ver krabby: motivations, parece que la velocidad es la razón principal de este proyecto
    Según mi entendimiento de Rust, la verificación de tipos, la verificación de préstamos y demás ya son muy rápidas, y el cuello de botella está en la generación de código; una parte importante de eso está relacionada con LLVM más que con Rust en sí
    Me da curiosidad cómo va hoy en día lo de Cranelift y si se cruza con ideas para acelerar la generación de código

    • Esa premisa asume que la estructura completa de rustc+LLVM es correcta y que ahora solo importan los factores constantes
      Personalmente, estoy bastante convencido de que eso no tiene mucho sentido si miras todo el pipeline de compilación. Hace falta un rlib solo para MIR y un backend que pueda hacer optimización de mundo completo sin necesitar RAM infinita (ver este comentario)
      “Codegen Unit” es complejidad puramente accidental
    • Depende de qué exactamente estés haciendo: Depends on what exactly you're doing
      En particular, puede ser interesante el desglose concreto de libraries y binaries
      LLVM no es precisamente rápido, pero si mal no recuerdo, tampoco ayudaba que rustc tiende a pasarle a LLVM un IR algo inflado
    • Gracias :) Parece que hay bastantes diferencias de perspectiva sobre los tiempos de compilación de Rust. Algunas personas culpan a la verificación de tipos, otras a LLVM
      Mi objetivo a mediano plazo, o sea durante unos 5 años, es cargo check, así que no voy a tocar la generación de código
      Aun así, creo que todavía hay mucho margen de optimización en mejor paralelismo, separar las rutas calientes del código de diagnósticos, reducir el trabajo duplicado entre la verificación de tipos y la verificación de préstamos, mejorar la disposición en memoria de las estructuras de datos clave, etc.
      También ayuda que tengo cercanía con desarrolladores de rustc y suelo escuchar seguido sobre varios problemas del codebase
    • rustc tiene un backend de Cranelift
    • LLVM sí parece ser la parte realmente lenta. Vi ese mismo patrón en discusiones sobre tiempos de compilación de Zig, y una implementación equivalente self-hosted es bastante más rápida que LLVM 1