RISC-V es demasiado, demasiado lento

 (marcin.juszkiewicz.com.pl)
3 puntos por GN⁺ 2026-03-24 | 1 comentarios | Compartir por WhatsApp
  • El trabajo de port de RISC-V para Fedora Linux lleva en marcha unos 3 meses, y la mayoría de los paquetes ya fueron compilados para Fedora 43
  • Actualmente, el hardware RISC-V muestra una velocidad de compilación extremadamente lenta; al compilar el mismo paquete puede tardar más de 5 veces que x86_64
  • Para ser adoptado como arquitectura oficial de Fedora, se necesita hardware de clase servidor capaz de compilar binutils en menos de 1 hora
  • Los retrasos en las compilaciones provocan quejas de los mantenedores de paquetes, e incluso se menciona la posibilidad de que RISC-V quede fuera
  • En el futuro, planean mejorar el problema de velocidad con la compilación de Fedora 44 y la incorporación de builders más rápidos, además de mantener la unificación del kernel y LTO desactivado

Estado del port de Fedora a RISC-V

  • El trabajo de port de RISC-V para Fedora Linux comenzó hace unos 3 meses y ha habido varios cambios
  • La mayoría de los elementos del tracker de Fedora RISC-V ya fueron resueltos y actualmente solo quedan 17 elementos en estado NEW
  • Se toma el código fuente de los paquetes de Fedora y se compila con el comando fedpkg mockbuild -r fedora-43-riscv64
  • Hasta ahora se han enviado 86 Pull Requests para paquetes, la mayoría ya fue fusionada, y la compilación para Fedora 43 está completa
  • Se pueden realizar compilaciones adicionales siguiendo la etiqueta ‘f43-updates’

  • Problema de velocidad de compilación en RISC-V

    • El hardware RISC-V actualmente muestra una velocidad de compilación extremadamente lenta
    • El tiempo de compilación de binutils 2.45.1-4.fc43 se midió en 143 minutos para riscv64, 36 minutos para aarch64 y 29 minutos para x86_64
    • La placa StarFive VisionFive 2 usada ofrece buen soporte de drivers, pero su velocidad es lenta
    • Al compilar el mismo paquete en la placa Milk-V Megrez, toma 58 minutos
    • Actualmente, las compilaciones de RISC-V tienen LTO (link-time optimization) desactivado, como medida para reducir el uso de memoria y el tiempo de compilación
    • Los builders cuentan con 4 a 8 núcleos y 8 a 32 GB de RAM, y su rendimiento se evalúa como de nivel Arm Cortex-A55
    • En el futuro, se espera mejora con el SoC UltraRISC UR-DP1000 (hasta 64 GB de RAM) y sistemas basados en SpacemiT K3 (hasta 32 GB de RAM)

  • Requisitos para entrar como arquitectura oficial de Fedora

    • Para ser incluida como arquitectura oficial de Fedora, se necesita hardware capaz de compilar el paquete binutils en menos de 1 hora
    • También se requiere alcanzar una velocidad comparable a otras arquitecturas incluso con LTO activado a nivel global del sistema
    • Como los resultados de compilación solo se reflejan en el repositorio cuando todas las arquitecturas terminan, los builders lentos provocan quejas de los mantenedores de paquetes
    • En el pasado hubo quejas por la velocidad de los builders AArch64, y algunos desarrolladores mencionaron la posibilidad de excluir a RISC-V
    • En el futuro, los builders deberán ser sistemas tipo servidor montables en rack y con administración remota; un entorno basado en SBC con reinicio manual no es adecuado
    • Si no se cumplen estas condiciones, será imposible que Fedora adopte oficialmente a RISC-V de 64 bits como arquitectura oficial

  • Pruebas locales usando QEMU

    • Debido a los largos tiempos de compilación, las pruebas locales mediante emulación con QEMU resultan útiles
    • En un desktop AArch64 de 80 núcleos, es posible compilar el paquete llvm15 en unas 4 horas usando emulación riscv64 en espacio de usuario con QEMU
    • Compilar el mismo paquete en el builder Banana Pi BPI-F3 toma 10.5 horas
    • Como el paquete LLVM aprovecha tanto los núcleos como la memoria, se espera una mejora de rendimiento en sistemas basados en Ampere One de 192/384 núcleos
    • QEMU se usa solo para compilación y pruebas locales, y Fedora solo realiza compilaciones nativas

  • Planes a futuro

    • Está previsto iniciar la compilación de Fedora Linux 44
    • El objetivo es que todos los builders usen la misma imagen de kernel; actualmente hay una mezcla de versiones de kernel
    • LTO seguirá desactivado
    • Para resolver el problema de velocidad, planean incorporar builders nuevos y más rápidos, y asignar algunos de los paquetes más pesados a esos builders

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-24
Comentarios en Hacker News

  • En vez de culpar a la ISA en sí, creen que el problema está en la implementación en silicio y en el software sin optimizaciones específicas por arquitectura
    RISC-V eventualmente también va a madurar
    ARM al principio estaba orientado a la velocidad, luego cambió hacia la eficiencia energética y triunfó en el mercado embebido, y ahora parece haber vuelto a priorizar la velocidad

    • En algunos casos consideran que el problema sí está en la propia especificación de la ISA de RISC-V
      Por ejemplo, hay casos como LLVM issue #150263, #141488
      También está el hecho de que el tamaño de página está fijado en 4KiB, lo que limita el rendimiento frente a ARM
    • Cuesta estar de acuerdo con la idea de que “RISC-V algún día se pondrá al día”
      ARM fue rápido, luego lento y después volvió a ser rápido, pero RISC-V todavía no ha demostrado competitividad en el segmento de alto rendimiento
      Las implementaciones hechas por equipos pequeños son impresionantes, pero para móviles, desktop y servidores sigue faltando mucho
    • Decir que “no es la ISA sino la implementación” es cierto, pero también es algo demasiado obvio
      En la práctica, lo clave es el diseño analógico VLSI de cosas como la estructura de caché y las interfaces DDR·PCI, y casi no hay equipos que hagan eso bien
      Además, todas las empresas quieren convertirse en un “vendor de RISC-V de alto rendimiento”, pero nadie quiere encargarse del “mercado embebido”
      En EE. UU., en vez de fabricar chips directamente, el modelo es vender IP, así que si quieres conseguir hardware real terminas dependiendo de vendors chinos
    • Si se mira el patrón de evolución del rendimiento de CPU, primero se optimiza la eficiencia energética y luego se vuelve a subir la velocidad, en un ciclo que se repite
      Un ejemplo representativo es cómo la arquitectura Netburst de Pentium 4 llegó a su límite, y la arquitectura Core, derivada de núcleos de bajo consumo, terminó convirtiéndose en la principal de Intel
      La historia de ARM muestra un recorrido parecido
    • En un video de LowSpecGamer cuentan que uno de los primeros chips ARM funcionó solo con diodos de protección
      Según Steve Furber, se habían olvidado de conectarle la alimentación y aun así el código llegaba a ejecutarse por lo eficiente que era

  • Comparten una corrección a un post de blog escrito por un colega
    En el sistema de builds de Fedora RISC-V, completaron una compilación de binutils en 67 minutos con una Milk-V “Megrez”, una mejora importante frente al registro anterior de 143 minutos
    Actualmente, las placas de desarrollo más rápidas no son Banana Pi sino la SiFive “HiFive P550” y la UltraRISC “DP1000”
    La presentación de FOSDEM “Fedora on RISC-V: state of the arch” también cubre benchmarks relacionados
    La prueba de Marcin se hizo en una StarFive “VisionFive 2”, una placa estable pero bastante lenta

    • La VisionFive 2 es confiable, pero como es una placa de más de 3 años, tiene limitaciones de memoria para builds actuales
      Para enlazar 4 binarios al mismo tiempo al compilar gcc, hacen falta al menos 16GB y además activar swap para que funcione de forma estable
      En la VisionFive 2 hay que compilar con -j1 o -j2, así que el tiempo termina aumentando entre 2 y 4 veces
      Es más eficiente usar un mejor linker (reemplazo de ld) o, como en el sistema de build de LLVM, configurar por separado cuántos enlaces paralelos se permiten

  • A ARM le tomó 40 años llegar a donde está hoy, y RISC-V apenas tiene 15 años
    Dicen que este año Tenstorrent planea lanzar una plataforma de servidor basada en RVA23, así que vale la pena seguirlo de cerca
    Al final, la clave es que los vendors de hardware saquen silicio de alto rendimiento

    • RISC-V recibió mucha influencia de MIPS, y MIPS también generó grandes expectativas a comienzos de los 90, pero terminó quedándose atrás en el mercado
    • AArch64 solo tiene 15 años, pero es una arquitectura casi completamente distinta de ARM de 32 bits

  • felix está compilando el repositorio de Arch Linux RISC-V con una Milk-V Pioneer
    Creen que las sanciones contra SOPHGO también influyeron en la desaceleración del desarrollo
    La Milk-V Oasis basada en el SG2380 de SOPHGO fue cancelada, pero parecía un SoC muy prometedor
    Los chips de esa empresa soportaban una arquitectura dual capaz de alternar entre ARM y RISC-V
    Ver repositorio Arch RISC-V, artículo relacionado

    • Les da curiosidad si alguien puede explicar con más detalle qué sanciones tuvieron qué efectos concretos

  • Se preguntan por qué el software para RISC-V necesariamente tiene que compilarse en un sistema RISC-V
    Como el compilador incluye en el código la información de la arquitectura de destino, en teoría debería poder hacerse también desde otro sistema

    • Para compilar cruzado una distribución completa, esa distribución tiene que soportarlo
      Fedora actualmente solo soporta builds nativos, y sus cross-compilers son únicamente versiones bare-metal para firmware
      Además, como automatizar las pruebas es difícil, los builds nativos con pruebas en hardware real son más realistas
      AArch64 también era lento al principio, pero ahora compilar Qt4 puede terminar en apenas 18 minutos
    • Hay muchos problemas de dependencias donde los scripts de build consultan bibliotecas o configuraciones del sistema host
      Según el lenguaje se puede resolver, pero el ecosistema de C/C++ es especialmente complejo
      Por eso la mayoría termina compilando en VM o en hardware objetivo real
    • Los compiladores antiguos elegían el backend en tiempo de compilación, así que soportar múltiples arquitecturas era difícil
      Desde LLVM eso se volvió posible, pero para probar sigue haciendo falta un emulador
    • El cross-build en sí es posible, pero probar después del build requiere más recursos
    • El cross-compiler en sí es fácil, pero modificar los scripts de build de decenas de miles de paquetes implica una carga de mantenimiento enorme

  • También aparece la opinión de que “¿por qué no simplemente hacer cross-compile desde un servidor x86_64?”

    • Pero adaptar todo el software para que soporte cross-compilation de forma completa es un trabajo gigantesco

  • Hace un año vieron en Mastodon un post que decía que “el hardware RISC-V más rápido es más lento que QEMU”
    RISC-V se está expandiendo a varios ámbitos, pero en cómputo de alto rendimiento sigue siendo débil

    • La Milk-V Pioneer superó ese límite, pero es cara y además usa una arquitectura antigua
      Encima, la empresa desarrolladora desapareció por las sanciones de EE. UU.

  • La compilación cruzada no es imposible, pero en las etapas %install y %check el problema es ejecutar las pruebas
    Por ejemplo, en el PR del paquete rpy hubo que desactivar las pruebas vectoriales en RISC-V
    Se puede separar build y testing, pero el ahorro de tiempo no compensa mucho la complejidad

    • Fedora tradicionalmente prefiere los builds nativos
      Ya en un hilo de LWN de 2012 (link) se discutía oponerse a la compilación cruzada
    • La alternativa más realista es compilar usando QEMU

  • El resultado de que i686 sea 14% más rápido que x86_64 parece dudoso
    Normalmente x86_64 es más rápido, gracias al mayor número de registros y a las instrucciones vectoriales
    Aun así, como el compilador intenta hacer más optimizaciones, el tiempo de build también podría alargarse
    Es posible que algo parecido ocurra en RISC-V

    • Si i686 resulta más rápido, podría ser por un cuello de botella en el ancho de banda de memoria
    • Los builds de x86_64 tienen 50% más pruebas del linker que los de i686

  • Como el texto no especifica qué CPU RISC-V se usó, la comparación queda ambigua

    • En la práctica, la mayoría de los builders tienen configuraciones de 4 a 8 núcleos y entre 8 y 32GB de RAM, y no hay muchas opciones
      La Milk-V Pioneer es una excepción con 64 núcleos y 128GB de RAM, pero usa una arquitectura vieja y además es cara