▲

RISC-V는 느려도 너무 느려요

 (marcin.juszkiewicz.com.pl)
3P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 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는 계속 비활성화 상태 유지 예정
    • 속도 문제 해결을 위해 새롭고 빠른 빌더 도입을 계획 중이며, 무거운 패키지 일부를 해당 빌더에 할당할 예정
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • ISA 자체를 탓하기보다는 실리콘 구현과 아키텍처별 최적화가 없는 소프트웨어의 문제라고 생각함
    RISC-V도 결국은 발전할 것임
    ARM도 처음엔 속도 중심이었지만, 이후 전력 효율로 방향을 바꿔 임베디드 시장에서 성공했고, 지금은 다시 속도 중심으로 돌아온 흐름을 보임

    • 어떤 경우에는 RISC-V ISA 명세 자체가 문제라고 봄
      예를 들어 LLVM 이슈 #150263, #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”에서도 관련 벤치마크를 다룸
    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 저장소, 관련 기사 참고

    • 어떤 제재가 실제로 어떤 영향을 미쳤는지 구체적으로 설명해줄 수 있는지 궁금함

  • 왜 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에서는 RISC-V에서 벡터 테스트를 비활성화해야 했음
    빌드와 테스트를 분리할 수는 있지만, 복잡도 대비 시간 절약이 크지 않음

    • Fedora는 전통적으로 네이티브 빌드를 선호함
      2012년 LWN 스레드(링크)에서도 이미 크로스 컴파일 반대 논의가 있었음
    • 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으로 예외적이지만, 오래된 아키텍처이고 가격이 높음
답변달기