Desde mayo Phoronix viene midiendo el SpacemiT K3 RISC-V SoC como uno de los primeros chips comerciales que soporta el perfil RVA23. El K3 ha mostrado cuánto avanzó RISC-V en la última media década, y uno de los puntos más prometedores del SoC —con sus núcleos X100/A100— es que trae la RISC-V Vector Extension "RVV" 1.0 activa. En este artículo vienen los primeros benchmarks midiendo el impacto de RVV 1.0 en distintos paquetes de software soportados.
¿Sobre qué hardware corren los benchmarks?
Las pruebas se ejecutaron sobre el sistema SpacemiT K3 Pico ITX que la propia SpacemiT le envió a Phoronix para review. La configuración:
- SoC SpacemiT K3, 16 núcleos RISC-V X100/A100
- 16 GB de RAM
- Bianbu 4.0
- Kernel Linux 6.18
- GCC 15.2
¿Por qué el toggle de RVV desde el kernel no funcionó?
Según la documentación oficial de kernel.org sobre RVV, la interfaz sysfs /proc/sys/abi/riscv_v_default_allow permite prender y apagar en runtime el soporte de la extensión vectorial. La idea original era usarla para comparar el impacto de RVV en el K3 apagando el flag y volviendo a correr los mismos tests, tal como Phoronix hace desde hace años con AVX-512 en x86 borrando el bit correspondiente del CPUID.
En la práctica no funcionó así. Al deshabilitar riscv_v_default_allow, la instalación Bianbu 4.0 quedó inoperable: instrucciones ilegales impidieron ejecutar cualquier binario en el sistema.
La hipótesis razonable de Phoronix es que Bianbu se apoya en instrucciones RVV incondicionales dentro del build de libc o de alguna librería central. Sin RVV activo, esos símbolos revientan y el sistema se queda sin poder ejecutar nada. Un dato revelador: hoy no hay forma sencilla de correr un sistema RISC-V RVA23 moderno "sin vector", aunque el kernel diga que se puede.
Tras un hard reset, la comparación con y sin RVV se armó a mano: recompilando los paquetes relevantes con las opciones de build correspondientes o ajustando sus patches de habilitación de RVV para que no compilaran las secciones vectoriales.
¿Qué mostró el benchmark de llama.cpp?
Uno de los tests clave, y el más citado para hardware moderno, es llama.cpp con y sin las rutas RVV activadas. Los números completos vienen en la SVG oficial de Phoronix:
Además del rendimiento, quedó pendiente medir el impacto de RVV en consumo. El SoC K3 no expone métricas de energía bajo Linux por ahora —nada vía sysfs, HWMON o PowerCap— y los medidores WattsUp Pro externos de Phoronix estaban ocupados en otras máquinas. La corrida se limitó, entonces, a comparar rendimiento puro.
¿Qué gana el ecosistema RISC-V con esto?
La lectura práctica para desarrolladores en LatAm que exploran RISC-V como plataforma alternativa a ARM y x86:
- RVV 1.0 ya es la norma esperada en cualquier SoC RISC-V RVA23 serio. Deshabilitarlo no es una vía razonable, ni siquiera para debugging.
- El toolchain llegó primero: GCC 15.2 con generación vectorial estable convierte a RISC-V en un blanco compilable "en serio" para software matemáticamente denso, no solo para toy demos.
- Bianbu como sistema de referencia: el que arme un producto en base al K3 con Ubuntu o Debian debe validar cuidadosamente si esas distros heredan la misma dependencia dura de RVV que Bianbu trae de fábrica.
