Compilar el paquete binutils en RISC-V tarda 143 minutos. En x86_64 tarda 29. En ARM64 tarda 36. Esos números — publicados hoy por Marcin Juszkiewicz, el ingeniero de Red Hat que lleva meses manteniendo el port de Fedora Linux para RISC-V — resumen mejor que cualquier benchmark el estado real del ecosistema RISC-V en 2026: prometedor en papel, todavía lento en la práctica.
Y eso con LTO desactivado. Con optimizaciones de tiempo de enlace habilitadas, los tiempos serían aún peores.
¿Qué es RISC-V y por qué le importa a alguien que no diseña chips?
RISC-V es una arquitectura de procesadores de código abierto — sin royalties, sin dueño corporativo, sin licencias que pagar. Mientras x86 (Intel/AMD) y ARM dominan el mercado, RISC-V es la apuesta de la industria por tener una tercera vía independiente. Qualcomm, Google, Meta, Intel y Alibaba han invertido en ella. Android 15 incluye soporte oficial. En 2026 ya alcanzó aproximadamente el 25% de penetración global en el mercado de chips.
La idea es simple: un ISA abierto significa que cualquiera puede diseñar chips sin pedir permiso, sin pagar por cada unidad fabricada. Para países que buscan soberanía tecnológica o startups que quieren chips personalizados para IA en el borde, es una propuesta estructuralmente atractiva.
El problema es que el hardware disponible hoy para desarrolladores sigue siendo básico.
Los números que preocupan: ~5x más lento que x86_64
Juszkiewicz lleva tres meses trabajando en el port de Fedora para RISC-V, ha enviado 86 pull requests y triado la mayoría de los problemas en el tracker oficial. Su diagnóstico es directo:
“El hardware RISC-V actual es lento. Lo que resulta en tiempos de compilación terribles.”
Los datos concretos de binutils 2.45.1 en diferentes arquitecturas:
- riscv64: 143 minutos (8 cores, 16 GB RAM, sin LTO)
- ppc64le: 46 minutos (10 cores, 37 GB RAM)
- aarch64: 36 minutos (12 cores, 46 GB RAM)
- x86_64: 29 minutos (8 cores, 29 GB RAM, con LTO)
- i686: 25 minutos (8 cores, 29 GB RAM)
El detalle importante: RISC-V es el único que corre sin LTO. Con optimizaciones habilitadas, la brecha sería mayor. Phoronix calcula la diferencia real en aproximadamente 5x más lento que x86_64.
Por qué el hardware es el cuello de botella, no la arquitectura
RISC-V como especificación de instrucciones no es inherentemente lento. El problema es que los chips RISC-V disponibles para desarrolladores hoy son SBCs (Single Board Computers) de baja gama — el equivalente a comparar una Raspberry Pi con un servidor moderno. Los cores actuales son comparables en rendimiento a un ARM Cortex-A55, que es el tipo de procesador que encuentras en teléfonos de gama baja.
Juszkiewicz usa QEMU para compensar: con 80 cores emulados puede compilar LLVM en ~4 horas. El mismo trabajo tarda 10,5 horas en una Banana Pi BPI-F3 real. Cuando la emulación es más rápida que el hardware nativo, hay un problema de ecosistema.
Hay esperanza en el horizonte: el UltraRISC UR-DP1000 (presente en el Milk-V Titan, soporta 64 GB RAM) y los sistemas basados en SpacemiT K3 (hasta 32 GB RAM) prometen mejoras, aunque el ingeniero es claro: “Ambos serán una mejora, pero no la solución final.”
Para que RISC-V se convierta en arquitectura primaria oficial de Fedora Linux, necesita hardware capaz de compilar binutils en menos de una hora, con LTO habilitado, en formato de servidor estándar gestionable. Aún no están ahí.
Lo que está en juego más allá de Fedora
El port de Fedora importa porque una distribución principal con soporte nativo es un paso esencial para que el ecosistema de software libre funcione bien en RISC-V. Sin eso, desarrollar para la arquitectura es doblemente difícil: código más lento y herramientas menos maduras.
La brecha de rendimiento actual en compilación no solo afecta a mantenedores como Juszkiewicz — impacta directamente a cualquier empresa que esté evaluando RISC-V para hardware propio, especialmente en el contexto de la carrera global por la independencia en semiconductores. China, la UE y varios países están apostando a RISC-V precisamente para reducir su dependencia de ARM e Intel. Si el ecosistema de software no madura, esa apuesta tiene pies de barro.
También hay lecciones aquí similares a las de los benchmarks engañosos de hardware: los números de marketing de RISC-V son sólidos, pero los números de producción cuentan una historia diferente. Para chips de IA en el borde y dispositivos embebidos donde la eficiencia energética es crítica, RISC-V ya compite hoy. Para compilación intensiva y cargas de servidor, todavía no.
Por qué importa
RISC-V va a ser relevante. La pregunta es cuándo y para qué. El trabajo de Marcin Juszkiewicz es exactamente el tipo de documentación honesta que los ecosistemas emergentes necesitan para no construir sobre expectativas infladas. Si estás evaluando RISC-V para tu stack — hardware propio, dispositivos IoT, chips de inferencia — el estado actual es “promisorio con asteriscos grandes”. Planifica tiempos de build conservadores, invierte en relaciones con la comunidad open source, y pon en agenda revisitar la decisión cuando aparezca hardware server-grade de verdad.
