# RISC-V는 느려도 너무 느려요 > Clean Markdown view of GeekNews topic #27797. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27797](https://news.hada.io/topic?id=27797) - GeekNews Markdown: [https://news.hada.io/topic/27797.md](https://news.hada.io/topic/27797.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-03-24T11:54:26+09:00 - Updated: 2026-03-24T11:54:26+09:00 - Original source: [marcin.juszkiewicz.com.pl](https://marcin.juszkiewicz.com.pl/2026/03/10/risc-v-is-sloooow/) - Points: 3 - Comments: 1 ## Topic Body - Fedora Linux의 **RISC-V 포트 작업**이 약 3개월째 진행 중이며, 대부분의 패키지가 Fedora 43용으로 빌드 완료됨 - 현재 RISC-V 하드웨어는 **매우 느린 빌드 속도**를 보이며, 동일 패키지 빌드 시 x86_64 대비 최대 5배 이상 시간 소요 - Fedora 공식 아키텍처로 채택되려면 **binutils를 1시간 이내 빌드 가능한 서버급 하드웨어**가 필요함 - 빌드 지연은 **패키지 유지관리자의 불만**을 초래하며, RISC-V가 제외될 가능성도 언급 - 향후 **Fedora 44 빌드와 빠른 빌더 도입**을 통해 속도 문제를 개선하고, 커널 통일 및 LTO 비활성화를 유지할 계획임 --- ### Fedora RISC-V 포팅 진행 상황 - 약 3개월 전부터 **Fedora Linux의 RISC-V 포트 작업**이 진행 중이며, 여러 변화가 있었음 - Fedora RISC-V 트래커의 대부분 항목이 정리되어 현재 **17개 항목만 NEW 상태**로 남아 있음 - Fedora 패키지 소스를 가져와 `fedpkg mockbuild -r fedora-43-riscv64` 명령으로 빌드 수행 - 지금까지 **86개의 패키지에 대한 Pull Request**가 제출되어 대부분 병합되었고, Fedora 43용 빌드 완료 - ‘f43-updates’ 태그를 따라 추가 빌드 진행 가능 - ## RISC-V 빌드 속도 문제 - RISC-V 하드웨어는 현재 **매우 느린 빌드 속도**를 보임 - `binutils 2.45.1-4.fc43` 빌드 시간은 riscv64 **143분**, aarch64 **36분**, x86_64 **29분**으로 측정됨 - 사용된 **StarFive VisionFive 2 보드**는 드라이버 지원은 양호하지만 속도는 느림 - 동일 패키지를 **Milk-V Megrez 보드**에서 빌드 시 58분 소요 - 현재 RISC-V 빌드는 **LTO(링크 타임 최적화)** 비활성화 상태로, 메모리 사용량과 빌드 시간 절감을 위한 조치 - 빌더는 **4~8코어, 8~32GB RAM**을 갖추며, 성능은 **Arm Cortex-A55 수준**으로 평가됨 - 향후 **UltraRISC UR-DP1000 SoC**(최대 64GB RAM)와 **SpacemiT K3 기반 시스템**(최대 32GB RAM)이 개선 기대 대상 - ## Fedora 공식 아키텍처 편입 요건 - Fedora 공식 아키텍처로 포함되려면 **binutils 패키지를 1시간 이내 빌드 가능한 하드웨어** 필요 - LTO를 시스템 전역에서 활성화한 상태에서도 다른 아키텍처와 동등한 속도 확보 필요 - 빌드 결과는 모든 아키텍처가 완료되어야 리포지토리에 반영되므로, 느린 빌더는 **패키지 유지관리자의 불만**을 초래 - 과거 AArch64 빌더의 속도 문제로 불만이 있었으며, 일부 개발자는 **RISC-V 제외 가능성**을 언급 - 향후 빌더는 **랙 장착 및 원격 관리 가능한 서버형 시스템**이어야 하며, SBC 기반 수동 리부팅 환경은 부적합 - 이러한 조건을 충족하지 못하면 **Fedora의 공식 64비트 RISC-V 아키텍처 채택은 불가능** - ## QEMU를 이용한 로컬 테스트 - 빌드 시간이 길어 **QEMU 에뮬레이션을 통한 로컬 테스트**가 유용함 - 80코어 **AArch64 데스크톱**에서 QEMU 사용자 공간 riscv64 에뮬레이션으로 `llvm15` 패키지를 약 **4시간**에 빌드 가능 - 같은 패키지를 **Banana Pi BPI-F3 빌더**에서 빌드 시 **10.5시간** 소요 - LLVM 패키지는 코어와 메모리를 모두 활용하므로, **Ampere One 기반 192/384코어 시스템**에서의 성능 향상이 기대됨 - QEMU는 로컬 빌드 및 테스트용으로만 사용되며, Fedora는 **네이티브 빌드만 수행** - ## 향후 계획 - **Fedora Linux 44 빌드 시작** 예정 - 모든 빌더에서 동일한 커널 이미지를 사용하는 것을 목표로 하며, 현재는 커널 버전이 혼재 - LTO는 계속 비활성화 상태 유지 예정 - 속도 문제 해결을 위해 **새롭고 빠른 빌더 도입**을 계획 중이며, **무거운 패키지 일부를 해당 빌더에 할당**할 예정 ## Comments ### Comment 53703 - Author: neo - Created: 2026-03-24T11:54:26+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47328214) - ISA 자체를 탓하기보다는 **실리콘 구현**과 아키텍처별 최적화가 없는 **소프트웨어**의 문제라고 생각함 RISC-V도 결국은 발전할 것임 ARM도 처음엔 속도 중심이었지만, 이후 전력 효율로 방향을 바꿔 임베디드 시장에서 성공했고, 지금은 다시 속도 중심으로 돌아온 흐름을 보임 - 어떤 경우에는 RISC-V **ISA 명세 자체**가 문제라고 봄 예를 들어 [LLVM 이슈 #150263](https://github.com/llvm/llvm-project/issues/150263), [#141488](https://github.com/llvm/llvm-project/issues/141488) 같은 사례가 있음 또 4KiB 페이지 크기가 고정되어 있어 ARM 대비 성능이 제한되는 점도 있음 - “RISC-V도 언젠가 따라잡을 것”이라는 말에 동의하기 어려움 ARM은 빠르다가 느려졌다가 다시 빨라졌지만, RISC-V는 아직 한 번도 **고성능 영역**에서 경쟁력을 보여준 적이 없음 소규모 팀이 만든 구현은 인상적이지만, 모바일·데스크탑·서버급에서는 여전히 부족함 - “ISA가 아니라 구현 문제”라는 말은 맞지만, 너무 **자명한 이야기**임 실제로는 캐시 구조, DDR·PCI 인터페이스 같은 **아날로그 VLSI 설계**가 핵심인데, 이걸 제대로 하는 팀이 거의 없음 또 모든 기업이 ‘고성능 RISC-V 벤더’가 되길 원하지만, ‘임베디드 시장’을 맡으려는 곳은 없음 미국에서는 칩을 직접 생산하기보다 **IP만 파는 구조**라 실제 하드웨어를 구하려면 중국 벤더에 의존해야 하는 현실임 - CPU 성능 발전의 패턴을 보면, 먼저 **전력 효율**을 최적화한 뒤 속도를 높이는 순환이 반복됨 Pentium 4의 Netburst 아키텍처가 한계에 부딪히고, 저전력 코어에서 파생된 Core 아키텍처가 인텔의 주력이 된 사례가 대표적임 ARM의 역사도 비슷한 흐름을 보임 - LowSpecGamer 영상에서 ARM 초창기 칩이 **보호 다이오드만으로도 동작**했다는 일화가 있음 Steve Furber에 따르면, 전원 연결을 잊었는데도 코드가 실행될 정도로 효율적이었다고 함 - 동료가 쓴 블로그 글에 대한 **정정**을 공유함 Fedora RISC-V 빌드 시스템에서 Milk-V “Megrez”로 67분 만에 binutils 빌드를 완료했으며, 이는 이전 143분 기록보다 큰 개선임 현재 가장 빠른 개발 보드는 Banana Pi가 아니라 SiFive “HiFive P550”과 UltraRISC “DP1000”임 FOSDEM 발표 [“Fedora on RISC-V: state of the arch”](https://fosdem.org/2026/events/attachments/SQGLW7-fedora-on-...)에서도 관련 벤치마크를 다룸 Marcin의 테스트는 StarFive “VisionFive 2”에서 수행되었는데, 이 보드는 안정적이지만 속도는 느린 편임 - VisionFive 2는 신뢰성은 좋지만 **3년 이상 된 보드**라 최신 빌드에는 메모리 한계가 있음 gcc 빌드 시 4개의 바이너리를 동시에 링크하려면 최소 16GB 이상 필요하고, 스왑을 켜야 안정적으로 동작함 VisionFive 2에서는 `-j1` 또는 `-j2`로 빌드해야 하므로 시간이 2~4배 늘어남 더 나은 **링커(ld 대체)** 를 쓰거나 LLVM 빌드 시스템처럼 병렬 링크 수를 따로 지정하는 게 효율적임 - ARM이 지금 위치에 오기까지 **40년**이 걸렸고, RISC-V는 아직 **15년**밖에 안 됐음 올해 Tenstorrent가 **RVA23 기반 서버 플랫폼**을 출시할 예정이라 하니 지켜볼 만함 결국 **하드웨어 벤더**들이 고성능 실리콘을 내놓는 게 관건임 - RISC-V는 MIPS에서 많은 영향을 받았는데, MIPS도 90년대 초반에 큰 기대를 받았지만 결국 시장에서 밀렸음 - AArch64는 15년밖에 안 됐지만, 32비트 ARM과는 거의 **완전히 다른 아키텍처**임 - felix가 Milk-V Pioneer로 **Arch Linux RISC-V 저장소**를 빌드 중임 SOPHGO 제재로 개발이 느려진 것도 원인이라 생각함 SOPHGO의 SG2380 기반 Milk-V Oasis는 출시 취소됐지만, 매우 유망한 SoC였음 이 회사의 칩은 ARM/RISC-V를 **전환할 수 있는 듀얼 아키텍처**를 지원했음 [Arch RISC-V 저장소](https://archriscv.felixc.at/), [관련 기사](https://www.tomshardware.com/tech-industry/artificial-intell...) 참고 - 어떤 제재가 실제로 어떤 영향을 미쳤는지 구체적으로 설명해줄 수 있는지 궁금함 - 왜 RISC-V 소프트웨어를 꼭 RISC-V 시스템에서 빌드해야 하는지 궁금함 컴파일러는 대상 아키텍처 정보를 코드에 포함하므로, 이론적으로는 다른 시스템에서도 가능하지 않나 하는 의문임 - 전체 배포판을 **크로스 컴파일**하려면 그 배포판이 이를 지원해야 함 Fedora는 현재 **네이티브 빌드만 지원**하며, 크로스 컴파일러는 펌웨어용 bare-metal 버전뿐임 또 테스트 자동화가 어렵기 때문에 실제 하드웨어에서 테스트하는 네이티브 빌드가 더 현실적임 AArch64도 초창기엔 느렸지만, 지금은 Qt4 빌드가 18분이면 끝날 정도로 발전했음 - 빌드 스크립트가 호스트 OS의 라이브러리나 설정을 참조하는 **의존성 문제**가 많음 언어별로 해결 가능하지만, C/C++ 생태계는 특히 복잡함 그래서 대부분은 VM이나 실제 타깃 하드웨어에서 빌드함 - 예전 컴파일러는 백엔드를 컴파일 시점에 선택했기 때문에, **다중 아키텍처 지원이 어려웠음** LLVM 이후로는 가능해졌지만, 테스트를 위해선 여전히 에뮬레이터가 필요함 - 크로스 빌드 자체는 가능하지만, 빌드 후 테스트가 더 많은 리소스를 요구함 - 크로스 컴파일러 자체는 쉽지만, 수만 개의 패키지 빌드 스크립트를 수정해야 하므로 **유지보수 부담**이 큼 - “그냥 x86_64 서버에서 크로스 컴파일하면 되지 않나?”는 의견도 있음 - 하지만 **크로스 컴파일을 완벽히 지원하도록 모든 소프트웨어를 수정**하는 건 매우 큰 작업임 - 1년 전 Mastodon에서 “가장 빠른 RISC-V 하드웨어가 QEMU보다 느리다”는 글을 봤음 RISC-V가 여러 분야로 확산 중이긴 하지만, **고성능 컴퓨팅**에서는 여전히 약함 - Milk-V Pioneer는 그 한계를 넘었지만, 비싸고 사용된 아키텍처도 오래됨 게다가 개발사는 **미국 제재로 사라짐** - 크로스 컴파일이 불가능한 건 아니지만, `%install`과 `%check` 단계에서 테스트 실행이 문제임 예를 들어 [rpy 패키지 PR](https://src.fedoraproject.org/rpms/rpy/pull-request/4#reques...)에서는 RISC-V에서 벡터 테스트를 비활성화해야 했음 빌드와 테스트를 분리할 수는 있지만, **복잡도 대비 시간 절약이 크지 않음** - Fedora는 전통적으로 **네이티브 빌드**를 선호함 2012년 LWN 스레드([링크](https://lwn.net/Articles/487622/))에서도 이미 크로스 컴파일 반대 논의가 있었음 - QEMU를 이용한 빌드가 가장 현실적인 대안임 - i686이 x86_64보다 14% 빠르다는 결과는 의심스러움 보통은 x86_64가 더 빠른데, 이는 **레지스터 수 증가**와 **벡터 명령어** 덕분임 다만 컴파일러가 더 많은 최적화를 시도하기 때문에 빌드 시간이 길어질 수도 있음 RISC-V에서도 비슷한 현상이 있을 가능성이 있음 - i686이 더 빠른 경우는 **메모리 대역폭 병목** 때문일 수 있음 - x86_64 빌드는 i686보다 **링커 테스트가 50% 더 많음** - 글에서 어떤 RISC-V CPU가 사용됐는지 명시되지 않아 비교가 모호함 - 실제로는 4~8코어, 8~32GB RAM 구성의 빌더들이 대부분이며, 선택지가 많지 않음 Milk-V Pioneer는 64코어·128GB RAM으로 예외적이지만, 오래된 아키텍처이고 가격이 높음