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으로 예외적이지만, 오래된 아키텍처이고 가격이 높음
Hacker News 의견들
ISA 자체를 탓하기보다는 실리콘 구현과 아키텍처별 최적화가 없는 소프트웨어의 문제라고 생각함
RISC-V도 결국은 발전할 것임
ARM도 처음엔 속도 중심이었지만, 이후 전력 효율로 방향을 바꿔 임베디드 시장에서 성공했고, 지금은 다시 속도 중심으로 돌아온 흐름을 보임
예를 들어 LLVM 이슈 #150263, #141488 같은 사례가 있음
또 4KiB 페이지 크기가 고정되어 있어 ARM 대비 성능이 제한되는 점도 있음
ARM은 빠르다가 느려졌다가 다시 빨라졌지만, RISC-V는 아직 한 번도 고성능 영역에서 경쟁력을 보여준 적이 없음
소규모 팀이 만든 구현은 인상적이지만, 모바일·데스크탑·서버급에서는 여전히 부족함
실제로는 캐시 구조, DDR·PCI 인터페이스 같은 아날로그 VLSI 설계가 핵심인데, 이걸 제대로 하는 팀이 거의 없음
또 모든 기업이 ‘고성능 RISC-V 벤더’가 되길 원하지만, ‘임베디드 시장’을 맡으려는 곳은 없음
미국에서는 칩을 직접 생산하기보다 IP만 파는 구조라 실제 하드웨어를 구하려면 중국 벤더에 의존해야 하는 현실임
Pentium 4의 Netburst 아키텍처가 한계에 부딪히고, 저전력 코어에서 파생된 Core 아키텍처가 인텔의 주력이 된 사례가 대표적임
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”에서 수행되었는데, 이 보드는 안정적이지만 속도는 느린 편임
gcc 빌드 시 4개의 바이너리를 동시에 링크하려면 최소 16GB 이상 필요하고, 스왑을 켜야 안정적으로 동작함
VisionFive 2에서는
-j1또는-j2로 빌드해야 하므로 시간이 2~4배 늘어남더 나은 링커(ld 대체) 를 쓰거나 LLVM 빌드 시스템처럼 병렬 링크 수를 따로 지정하는 게 효율적임
ARM이 지금 위치에 오기까지 40년이 걸렸고, RISC-V는 아직 15년밖에 안 됐음
올해 Tenstorrent가 RVA23 기반 서버 플랫폼을 출시할 예정이라 하니 지켜볼 만함
결국 하드웨어 벤더들이 고성능 실리콘을 내놓는 게 관건임
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분이면 끝날 정도로 발전했음
언어별로 해결 가능하지만, C/C++ 생태계는 특히 복잡함
그래서 대부분은 VM이나 실제 타깃 하드웨어에서 빌드함
LLVM 이후로는 가능해졌지만, 테스트를 위해선 여전히 에뮬레이터가 필요함
“그냥 x86_64 서버에서 크로스 컴파일하면 되지 않나?”는 의견도 있음
1년 전 Mastodon에서 “가장 빠른 RISC-V 하드웨어가 QEMU보다 느리다”는 글을 봤음
RISC-V가 여러 분야로 확산 중이긴 하지만, 고성능 컴퓨팅에서는 여전히 약함
게다가 개발사는 미국 제재로 사라짐
크로스 컴파일이 불가능한 건 아니지만,
%install과%check단계에서 테스트 실행이 문제임예를 들어 rpy 패키지 PR에서는 RISC-V에서 벡터 테스트를 비활성화해야 했음
빌드와 테스트를 분리할 수는 있지만, 복잡도 대비 시간 절약이 크지 않음
2012년 LWN 스레드(링크)에서도 이미 크로스 컴파일 반대 논의가 있었음
i686이 x86_64보다 14% 빠르다는 결과는 의심스러움
보통은 x86_64가 더 빠른데, 이는 레지스터 수 증가와 벡터 명령어 덕분임
다만 컴파일러가 더 많은 최적화를 시도하기 때문에 빌드 시간이 길어질 수도 있음
RISC-V에서도 비슷한 현상이 있을 가능성이 있음
글에서 어떤 RISC-V CPU가 사용됐는지 명시되지 않아 비교가 모호함
Milk-V Pioneer는 64코어·128GB RAM으로 예외적이지만, 오래된 아키텍처이고 가격이 높음