SpacemiT K3 SoC를 이용한 RISC-V RVV 벡터 성능 벤치마크

지난 5월부터 당사는 RVA23 프로파일을 지원하는 시장 최초의 RISC-V 칩 중 하나인 SpacemiT K3 RISC-V SoC를 벤치마킹해 왔습니다. SpacemiT K3는 지난 반세기 동안 RISC-V 성능이 얼마나 발전했는지를 보여주었으며, X100/A100 코어를 탑재한 이 현대적인 RISC-V SoC의 유망한 요소 중 하나는 RISC-V 벡터 확장(Vector Extension)인 "RVV" 1.0을 지원한다는 점입니다. 본 기사에서는 다양한 지원 소프트웨어에서 RISC-V RVV 1.0의 성능 영향력을 구체적으로 살펴보는 초기 벤치마크 결과를 다룹니다.

오늘의 벤치마크는 SpacemiT K3 SoC에서 RISC-V 벡터 RVV 1.0의 성능 영향을 정량화하는 데 중점을 둡니다. K3에 대한 벤치마크는 Phoronix의 리뷰를 위해 SpacemiT에서 친절히 제공해 준 SpacemiT K3 Pico ITX 시스템에서 계속해서 수행되고 있습니다. 16GB RAM을 갖춘 이 16코어 시스템은 Linux 6.18 커널과 GCC 15.2 컴파일러가 포함된 Bianbu 4.0을 실행 중입니다.

RISC-V 벡터 지원에 관한 kernel.org 문서에 따르면, /proc/sys/abi/riscv_v_default_allow sysfs 인터페이스를 사용하여 RISC-V 벡터 지원을 런타임(runtime) 중에 토글(toggling)할 수 있습니다. 이것이 처음에 K3에서 RISC-V 벡터 성능 영향을 비교하기 위해 세웠던 계획이었습니다. 하지만 실제로 해보니 그리 잘 풀리지 않았습니다...

지난 수년간 Phoronix에서 진행한 수많은 AVX-512 벤치마크의 경우, 대부분의 소프트웨어 패키지에서 CPU ID 비트를 단순히 지우는 것만으로 비교하는 것이 상당히 간단했습니다. /proc/sys/abi/riscv_v_default_allow를 통해 벡터 지원을 단순히 끌 수 있음으로써 RVV 또한 직관적인 비교가 가능하기를 희망했습니다.

하지만 "riscv_v_default_allow"를 비활성화했을 때, Bianbu 4.0 시스템은 잘못된 명령어(illegal instructions)로 인해 단순히 작동 불능 상태가 되었습니다. 그 이후로는 시스템에서 어떤 바이너리도 실행할 수 없었습니다. 아마도 Bianbu는 libc 빌드나 기타 공통 라이브러리에서 일부 무조건적인 RVV 명령에 의존하고 있기 때문에, riscv_v_default_allow가 비활성화되면 시스템이 아무것도 실행할 수 없게 된 것으로 추정됩니다.

따라서 하드 리셋(hard reset)을 수행한 후, RISC-V 벡터(Vector) 성능을 비교하기 위해서는 각 프로그램의 빌드 옵션을 사용하거나, 필요한 비트 없이 컴파일되도록 RVV 활성화 패치(RVV-enablement patches)를 조정하는 방식으로 관련 지원 패키지에서 RVV 지원을 수동으로 비활성화해야 했습니다.

다음은 RVV를 사용하거나 사용하지 않는 다양한 소프트웨어 패키지에 대한 RVV 1.0의 영향력을 살펴본 결과입니다. RVV 사용에 따른 전력(power) 영향을 정량화하는 것도 흥미로웠겠지만, 불행히도 K3 SoC는 현재 Linux 환경에서 어떠한 전력 지표(power metrics)도 노출하지 않습니다. 즉, sysfs, /HWMON, PowerCap 또는 기타 인터페이스를 통해 노출되는 전력 지표가 없습니다. 제 WattsUp Pro 외부 전력 미터(external power meters)는 외부 AC 전력 모니터링을 위해 다른 시스템에서 사용 중이었으므로, 본 기사에서는 성능 영향(performance impact)만을 살펴봅니다.