Solicitud de divorcio de LLVM

 (github.com/ziglang)
2 puntos por GN⁺ 2023-07-01 | 2 comentarios | Compartir por WhatsApp
  • El proyecto Zig busca eliminar por completo las dependencias de las bibliotecas LLVM, Clang y LLD del ejecutable principal de zig
  • El trabajo pendiente se divide en eliminar LLD, quitar las llamadas a la API de LLVM, avanzar los backends de C/x86/wasm/aarch64, eliminar subcomandos y usos del preprocesador que dependen de Clang, e implementar un reemplazo para zig ar
  • El backend de LLVM ya genera archivos .bc, pero el compilador de Zig dejará de tener la capacidad de compilar .bc a archivos objeto, por lo que en ese caso será necesaria una instalación separada de Clang
  • Entre los efectos esperados se mencionan la simplificación de la compilación desde código fuente y del bootstrap, evitar problemas relacionados con LLVM/Clang/LLD en distribuciones Linux y Homebrew, y una reducción del tamaño del binario de aproximadamente 150 MiB → 5 MiB
  • La propuesta apunta a que Zig implemente sus propios passes de optimización y pueda atraer contribuciones directas de proyectos de investigación como alive2 y de fabricantes de chips como Intel, ARM y RISC-V

Dependencias que se buscan eliminar del ejecutable de Zig

  • El objetivo de este issue es eliminar por completo las bibliotecas LLVM, Clang y LLD del proyecto Zig
  • Los puntos de integración que aún quedan se resumen en las áreas de LLD, LLVM, Clang y zig ar

Trabajo pendiente relacionado con LLD

Trabajo pendiente relacionado con LLVM

Trabajo pendiente relacionado con Clang

zig ar y limitaciones al procesar archivos .bc

  • zig ar: a drop-in llvm-ar replacement #9828: aún queda trabajo para convertir zig ar en un reemplazo directo de llvm-ar
  • El backend de LLVM ya genera archivos .bc, pero el compilador de Zig dejará de tener la capacidad de compilar archivos .bc a archivos objeto
  • Para manejar este caso de uso, habrá que instalar Clang por separado

Cambios esperados al eliminar dependencias

  • Todos los bugs del lado de Zig pasarán a estar dentro del ámbito de responsabilidad del propio proyecto Zig
  • El proceso de compilar el compilador desde código fuente y hacer bootstrap se simplificará, y en el sistema host solo hará falta un compilador de C
  • Las distribuciones Linux y gestores de paquetes como Homebrew dejarán de lidiar con los problemas que generaban LLVM, Clang y LLD
  • El tamaño del binario del compilador Zig se reducirá de aproximadamente 150 MiB a 5 MiB
  • La velocidad de compilación podría aumentar por varios órdenes de magnitud
  • Zig podrá implementar sus propios passes de optimización para empujar el estado del arte en computación
  • Podrá atraer proyectos de investigación como alive2
  • Podrá incentivar contribuciones directas de actores interesados, como fabricantes de chips Intel, ARM y RISC-V, que quieren mejor código máquina para sus propios CPU

Lecturas relacionadas

2 comentarios

 
alstjr7375 2023-07-02

¿Será posible lograr tanta optimización o soporte de plataformas como con LLVM..
 
GN⁺ 2023-07-01
Comentarios de Hacker News

  • Andrew es una persona muy aguda, así que una vez que algo se declara como objetivo, parece que el equipo al final sí lo logrará.
    Aun así, desde la perspectiva de alguien que no conoce bien las dificultades de Zig relacionadas con LLVM, esta decisión se ve como si estuvieran desviando la capacidad del equipo hacia herramientas periféricas como binutils en vez de hacia Zig mismo.
    Cuando vi solo el título, pensé que estaban abandonando el compilador, y en un proyecto como Zig parece que también hay mucho que ganar manteniendo LLVM.
    De todos modos, la idea de reescribir mucho del código dentro de LLVM en Zig en lugar de C++ es bastante genial y ambiciosa. Incluso podría verse como algo tan ambicioso como el intento de Lattner al crear LLVM.
    Aun así, el código que termina accidentalmente con complejidad temporal cuadrática será igual de difícil de evitar si Zig llega a ser tan popular y útil como LLVM.

    • Me recordó una frase que vi antes en lo que parecía ser un documento no oficial de gestión de proyectos de la NASA.
      La idea era: “Si una misión espacial no reutiliza un lanzador existente, entonces ese proyecto se convierte en un proyecto de desarrollo de lanzadores, y todo lo demás que se pensaba que era el núcleo de la misión pasa a ser secundario”.
      Otra parte que recuerdo añadía la premisa de que “en vez de hacer concesiones para ajustarse a un lanzador existente, uno podría pensar que hacer un lanzador adaptado a una misión específica sería más barato y eficiente”.
    • Me recordó una entrevista reciente a Chris Lattner sobre el éxito de Swift. Él veía como un factor de éxito importante el hecho de que se podía empezar a mezclar Swift en grandes proyectos de Objective-C sin reescribir nada.
      Parte del éxito de Rust también se apoya en una compatibilidad similar con C/C++.
      Me cuesta imaginar que Zig tenga éxito sin una capacidad parecida, así que espero que no sigan empujando este hito tal cual.
    • Hay una gran diferencia con LLVM. Al menos en el contexto en que Apple tomó el proyecto, no había muchas alternativas.
      GCC no estaba dispuesto a permitir ni a implementar lo que Apple quería o necesitaba.
    • No es que “ya se haya declarado como objetivo”. Sigue siendo una propuesta no aceptada.
    • binutils se parece más a un paquete multipropósito de código para manejar formatos de código binario de forma portable, y un compilador no necesita ni la mitad de eso, especialmente no lo legado.
      Si se enfocan más, como TCC, la mayor parte probablemente sería generación de código para múltiples arquitecturas.

  • Aquí hay dos problemas. Uno es la generación de código y el otro es el bootstrapping.
    Por experiencia, las pasadas de optimización de un compilador son fáciles de escribir y divertidas. Hay que leer papers para entender la asignación de registros y la forma SSA, pero el código que va pasando el IR por distintas optimizaciones y lo va puliendo poco a poco puede escribirse de forma bastante entretenida.
    Se pueden hacer pasadas de optimización de alta calidad incluso sin LLVM. Pero la etapa de linearizar el IR a código máquina es un trabajo aburrido y rutinario, a menos que te encanten todas las formas en que x86-32/64 codifica instrucciones como “mov [eax+8*ebx], 123”.
    Si quisieras optimizar el tamaño del binario, ¿de verdad querrías medir en qué plataformas “push eax; push eax; push eax” es más corto que “add rsp,12”? Y eso es solo x86; si lo multiplicas por las arquitecturas no x86, que para la mayoría de los desarrolladores no importan mucho, se vuelve mucho más grande.
    También es muy probable que errores graves en generadores de código para arquitecturas poco usadas pasen años sin descubrirse.
    Lo segundo es el bootstrapping. ¿Con qué compilas un compilador de Zig escrito en Zig? Por ejemplo, podrías compilar el compilador de Zig con un compilador mínimo de Zig sin optimizaciones escrito en C.
    Pero si no está optimizado, entonces habría que recompilar el compilador de Zig con un compilador de Zig optimizado. No es un problema insoluble, pero un proceso de build largo y complejo corre el riesgo de ahuyentar a posibles contribuidores.

  • Después de promocionar tanto que Zig puede compilar C, y quizá hasta C++, ahora decir que van a sacar completamente LLVM se ve bastante radical.
    A menos que mucha más gente empiece a colaborar con el soporte, también parece muy poco probable que se acerquen al nivel de soporte de plataformas de LLVM.
    Entiendo el plan de agregar su propio backend para quien lo quiera, pero simplemente eliminar LLVM se ve apresurado.

    • Si el trabajo ya hubiera comenzado, podría ser apresurado, pero igual que otras propuestas sin la etiqueta “accepted” en el issue tracker, por ahora esto es solo una etapa para pedir discusión y propuestas en contra.
      En este momento el equipo está recolectando feedback, aprendiendo sobre los casos de uso afectados y midiendo la viabilidad, así que yo lo veo más bien como lo opuesto a algo apresurado.
    • Si lees el cuerpo del issue enlazado, no se trata de eliminar por completo el backend de LLVM. Solo se separa del binario principal, y si tienes LLVM instalado en el sistema, todavía puede usarse fácilmente como backend.
      Tener que incluir una copia de LLVM de más de 100 MB cuando ni siquiera hace falta en el caso general sí suena algo raro, así que tiene sentido. Además, si eres desarrollador, probablemente ya lo tienes instalado de todos modos.
      Aunque podría ser difícil garantizar que la instalación de Zig funcione correctamente con la versión de LLVM del sistema. Habrá que verlo.
    • Se seguirá emitiendo bitcode de LLVM, pero ya no dependerá de las librerías de LLVM.
      https://github.com/ziglang/zig/issues/13265
    • Yo también lo entendí exactamente así.
      Últimamente había estado leyendo un poco más sobre Zig y hasta lo usé como una forma sencilla de compilar C++ con LLVM sin pelearme con paquetes del sistema. La posibilidad de pasar de C/C++ a Zig era un gran punto de venta.
      Se siente muy repentino e inesperado. No sé si sea correcto o no para el proyecto, pero desde mi punto de vista sí se siente realmente de la nada.
    • En un proyecto de Rust estamos usando Zig como compilador de C++. Era la forma menos dolorosa de hacer compilación cruzada en GitHub Actions.

  • Por un lado, respeto la intención meticulosa de reducir dependencias, pero el costo parece bastante serio.
    La pérdida de compatibilidad con C++ prácticamente elimina la ventaja que los fans de Zig a mi alrededor mencionaban más a menudo.
    La pérdida de rendimiento, aunque sea temporal, también toca otro punto clave que ellos solían destacar.

    • La mayoría de las respuestas parecen estar en contra de esta propuesta.
      Para quienes lo lean por encima: esto no es una decisión tomada, sino una propuesta.

  • Durante unos 4 años escribí todo un proyecto embebido y sus bibliotecas en Zig, ¿y ahora simplemente van a desaparecer varias arquitecturas con soporte tier 1?
    El lenguaje es suyo y pueden hacer con él lo que quieran, pero si es así, ojalá ajusten también el branding en consecuencia.

    • ¿De verdad van a desaparecer?
      Supongo que el soporte tier 1 se dividirá en dos categorías: soporte tier 1 integrado y soporte tier 1 mediante un backend de LLVM opcional.
      Si una arquitectura ya tiene soporte tier 1, no veo por qué tendría que perderlo solo porque el backend de LLVM pase a ser una dependencia opcional.
      Como escribió Andrew en la propuesta, este enfoque incluso podría ser una vía para dar mejor soporte a arquitecturas más raras. Yo con gusto trabajaría en un backend de Zig para una arquitectura de procesador interesante, pero jamás contribuiría a LLVM. Trabajar con C++ no es algo que haría por gusto.
    • ¿La idea es quitar LLVM reimplementando por cuenta propia todo lo que hace LLVM?
      ¿Cuál sería la ventaja? ¿No es eso un desperdicio de recursos?
    • No es ningún secreto que Zig sigue estando antes de la 1.0. No se les puede achacar toda la responsabilidad por esto, pero aun así parece una propuesta bastante radical.
    • Sigue siendo solo una propuesta. El issue de GitHub también existe principalmente para subir casos de uso a favor y en contra, entre otras cosas; no está Accepted.
    • Esto sigue en fase de propuesta, así que si suficientes personas dan su opinión, como ya lo están haciendo muchas, creo que el equipo central también ajustará su enfoque.

  • DLang tiene 3 compiladores.
    gdc está basado en el backend de GNU Compiler Collection, ldc en el backend de LLVM, y dmd en un generador de código x86 que escribí para Zortech/Symantec/Digital Mars.
    Cada uno tiene ventajas, desventajas y objetivos distintos, pero el lenguaje D que soportan es el mismo.
    En general, a los usuarios les gustan las opciones, y algunos incluso usan más de uno.

    • Hay una diferencia de enfoque interesante. D parece tener compiladores totalmente separados, mientras que Zig parece ir en la dirección de que el compilador principal de Zig dé soporte a LLVM como backend si está instalado.
      Si eso es correcto, me gusta el enfoque de Zig.
    • Otro lenguaje con múltiples compiladores es Common Lisp. Hay alrededor de una decena de compiladores listos para producción, algunos comerciales pero en su mayoría gratuitos.
      Eso es muy útil porque durante el desarrollo puedes usar el compilador más rápido y, para la versión final, el compilador con el runtime más veloz o el menor uso de memoria.
      Además, si existe una especificación del lenguaje que todos los compiladores siguen, eso da la garantía de que el lenguaje es estable y no se va a romper de pronto por abajo.
      Claro, también hay ventajas en un lenguaje como Zig, donde todavía puedes cambiar lo que quieras para hacerlo más consistente, más limpio y más potente. Pero últimamente valoro mucho más esa estabilidad, porque te permite concentrarte en crear valor real para los usuarios en vez de estar persiguiendo constantemente a las herramientas de desarrollo.
    • Que los usuarios avanzados tengan opciones es una ventaja, pero creo que el simple hecho de tener que elegir ya es una gran desventaja.
    • Entiendo que a los usuarios les gusten las opciones, pero si Zig apunta a una adopción amplia a largo plazo, no creo que DLang sea un buen precedente.

  • Una de las principales razones por las que Zig me parecía interesante era que se podía insertar directamente como alternativa a un compilador de C/C++.
    Amigos míos me dijeron que, en Windows, Zig es más fácil de instalar como compilador de C/C++ que cualquier otra alternativa.
    Si esta propuesta se acepta, personalmente creo que la popularidad de Zig caerá al nivel de Hare u otros lenguajes extremadamente de nicho.
    Para lograr que mis colegas siquiera probaran Zig una vez, tuve que mandarles hasta artículos sobre cómo Uber lo usa en producción. Si no hubiera tenido un valor inmediato para proyectos existentes, ni lo habrían considerado dos veces.
    Aun así, entiendo el trasfondo de la propuesta. Los tiempos de compilación de LLVM pueden sentirse terribles, y tener un bytecode propio permitiría implementar técnicas de optimización muy interesantes. Lidiar con bugs de LLVM es, en la práctica, algo bastante ingrato, y también he visto eso en el ecosistema de Julia.
    Si mi recomendación sirve de algo, creo que Zig debería 1) usar bytecode personalizado en builds de debug para compilaciones rápidas y depuración rápida, y 2) usar LLVM en builds de release para obtener un rendimiento de runtime alto.
    Si se pudiera lograr el punto 1) manteniendo el soporte de compilación cruzada para C/C++, por ejemplo delegando solo esa parte a LLVM, entonces, aunque implicaría el trade-off de mantener código adicional de backend, podría ser el mejor punto medio.

    • Como una de las personas que lidia con bugs de LLVM en el ecosistema de Julia, sí.
      Requiere un conjunto de habilidades aparte, distinto del trabajo de más alto nivel en el compilador de Julia, y a veces tarda bastante en que una corrección de bug se integre upstream.
      Pero en la práctica tenemos una relación bastante buena y productiva con upstream, y si hubiéramos decidido eliminar LLVM, el proyecto habría logrado mucho menos.
      En particular, el soporte de GPU y el soporte para HPC, por ejemplo en PPC, dependen de LLVM.
      Por eso mantenemos la postura de que Julia debe compilarse de acuerdo con nuestro patchset/fork, y no invertimos tiempo en bugs que ocurren en builds de Julia que no usan esos parches. Eso pasa especialmente seguido en builds de distribuciones.

  • Viendo el trabajo en backends no basados en LLVM de otros lenguajes, en la propuesta enlazada se siente demasiado fuerte la arrogancia.
    Si no la hubiera escrito esa persona, la habría tomado por un issue cualquiera de GitHub escrito al tanteo por algún principiante de Zig.
    Subestima la cantidad de trabajo necesaria, menosprecia de forma implícita todo el trabajo que ha entrado en LLVM, y en cada frase se siente esa confianza y esa actitud de macho de “obviamente nosotros podemos hacerlo más barato, más rápido y mejor”. Es decepcionante.
    Hasta ahora siempre he respetado mucho el trabajo de Andrew, así que quiero darle el beneficio de la duda y pensar que quizá lo escribió con prisa o por impulso, sin darse cuenta de que sonaba así.
    Pero este texto no inspira confianza ni hace que me resulte más fácil ver la propuesta con una mente abierta.

    • No conozco para nada el backend de LLVM, pero las bibliotecas que intentan resolver el 100% de los problemas de los usuarios suelen terminar siendo más difíciles de manejar y más lentas que alternativas más optimizadas.
      Webpack y esbuild son un ejemplo de eso.

  • El momento adecuado para construir algo sin LLVM fue hace años. Pero ahora, si se elimina la funcionalidad de C++, eso podría significar el fin de Zig.
    Me sorprende que, en lugar de retirarla gradualmente, no hayan anunciado un plan para escribir su propio compilador de C++ en Zig.

    • Solo escribir un parser de C++ ya sería un proyecto gigantesco.
      Ni siquiera estoy seguro de que una persona que lo empiece a los 18 años pueda llegar a escribir un compilador de C++. Puede que ni siquiera le alcance el resto de su vida para terminar uno que funcione.

  • Zig quiere convertirse en el nuevo C del mundo, no tanto en el nuevo C++ del mundo
    Incluso en esta propuesta se puede ver que se seguirá dando soporte a la compilación cruzada de C
    Esta decisión podría ser la correcta. C se usa mucho hoy en el mundo embebido, y en ese ámbito LLVM no es bueno
    Si yo fuera Zig, querría apuntar a todos los microcontroladores, y este es el único camino realista para lograrlo