▲

krabby: 빠른 Rust 컴파일러 만들기

 (bal-e.org)
1P by GN⁺ 1시간전 | ★ favorite | 댓글 1개
  • Krabby는 rustc의 느린 컴파일 속도를 개선하려는 성능 우선의 빈 슬레이트 Rust 컴파일러 구현임
  • rustc의 체감 성능 개선은 이제 단일 함수 변경보다 API와 자료구조 변경에서 나오지만, 큰 코드베이스와 안정성 요구 때문에 대규모 변경이 어려운 상태임
  • Krabby는 한 사람이 통제하는 작은 코드베이스에서 안정성을 우선하지 않고 컴파일러 구성요소를 함께 다시 설계해 새로운 최적화 기회와 응집력 있는 아키텍처를 찾으려 함
  • 목표는 컴파일러 성능을 크게 높이려면 설계를 완전히 다시 생각해야 한다는 가설을 Rust처럼 복잡한 언어에서도 시험하는 데 있음
  • 코드는 Codeberg의 krabby 저장소에 공개되어 있으며, 진행 상황은 Fediverse에 1~2주에 한 번 이상 올리는 것을 목표로 함

Krabby의 목표와 배경

  • Rust는 선호하는 언어이지만 rustc 컴파일러는 눈에 띄게 느림
  • rustc 성능 개선에는 이미 많은 사람이 노력 중이며, 단일 함수 변경으로 체감 성능을 올릴 수 있는 개선은 대부분 구현된 상태에 가까움
  • 의미 있는 개선은 이제 API와 자료구조 변경에서 나오지만, rustc처럼 큰 코드베이스에서는 여러 기능 개발과 안정성 요구 때문에 대규모 변경이 사실상 어려움
  • Krabby는 성능을 우선순위로 둔 빈 슬레이트 Rust 컴파일러 구현이며, rustc와 목표가 근본적으로 다름
  • 작은 코드베이스를 한 사람이 통제하고 안정성을 우선하지 않기 때문에, 모든 구성요소를 서로 고려해 설계하면서 새로운 최적화 기회를 찾고 더 응집력 있는 아키텍처를 만들려는 접근임
  • 컴파일러 성능을 크게 개선하려면 컴파일러 설계를 완전히 다시 생각해야 한다는 가설에서 출발함
  • 대규모 아키텍처 최적화는 대상 언어와 관계없이 숨어 있을 수 있으며, 단순한 C 같은 언어뿐 아니라 Rust처럼 복잡한 언어에도 적용 가능하다는 점을 보이려 함
  • 결과 설계가 Rust에 특화되더라도, 그 과정에서 배울 가치는 있다고 봄

프로젝트 상태와 공개 자료

함께 보면 좋은 글 β

▲
GN⁺ 1시간전  [-]
Lobste.rs 의견들

  • 다들 자기만의 허영 라이선스를 갖고 싶어 하는 듯함 https://codeberg.org/bal-e/krabby/…

    • 취미 프로젝트라면 괜찮겠지만, 이 프로젝트가 진지한 쪽보다는 캐주얼한 프로젝트라는 신호가 되긴 함
      이 라이선스는 개인·비상업 목적의 사용과 공유는 무료로 허용하지만, 그 위에 만든 소프트웨어도 같은 조건으로 공유해야 하고, 상업 목적은 30일 동안만 시험 사용 가능하다고 되어 있음
      Codeberg가 프로젝트 라이선스에 대해 엄격한 libre/오픈소스 조건을 요구하는지 궁금함. Codeberg는 FOSS만 호스팅한다고 알고 있어서 비상업 사용 제한이 의외였는데, 최신 상황을 잘 못 따라가고 있을 수도 있음
    • 맞음, 나도 알고 있음... 라이선스 문제로 꽤 오래 고민해 왔고, 아직 혼자 작업 중일 때 AGPL로 바꾸는 걸 고려하고 있음

  • Rust는 규모가 큼. 이 프로젝트는 “직접 웹 브라우저 만들기”보다는 약간 쉬워 보이지만, 그렇다고 쉬운 건 전혀 아님. 그래도 목표가 큰 점은 높이 삼
    krabby: motivations를 보면 속도가 이 프로젝트의 주된 이유처럼 보임
    Rust에 대한 내 이해로는 타입 검사, 빌림 검사 등은 이미 매우 빠르고, 병목은 코드 생성이며 그중 상당 부분은 Rust 자체보다 LLVM과 관련되어 있음
    요즘 Cranelift 쪽은 어떻게 돌아가는지, 코드 생성 속도를 높이는 아이디어와 겹치는 부분이 있는지 궁금함

    • 그 전제는 rustc+LLVM의 전체 구조가 맞고, 이제는 상수 계수만 중요하다고 보는 것임
      개인적으로는 컴파일 파이프라인을 전체로 보면 말이 잘 안 된다고 꽤 확신함. MIR 전용 rlib가 필요하고, 무한한 RAM 없이도 전체 세계 최적화를 할 수 있는 백엔드가 필요함(이 댓글 참고)
      “Codegen Unit”은 순전히 우발적 복잡성임
    • 무엇을 하느냐에 따라 다름: Depends on what exactly you're doing
      특히 libraries와 binaries의 구체적 분해가 흥미로울 수 있음
      LLVM이 빠른 편은 아니지만, rustc가 LLVM에 다소 부풀려진 IR을 넘기는 경향도 도움이 되지 않았던 것으로 기억함
    • 고마움 :) Rust 컴파일 시간에 대해 사람마다 관점이 꽤 다른 듯함. 어떤 사람은 타입 검사를 탓하고, 어떤 사람은 LLVM을 탓함
      내 중기 목표, 즉 앞으로 약 5년 동안의 목표는 cargo check라서 코드 생성은 건드리지 않음
      그래도 더 나은 병렬성, 진단 코드의 핫 경로 분리, 타입 검사와 빌림 검사 사이의 중복 작업 감소, 핵심 자료구조의 메모리 배치 개선 등에서 최적화 여지가 아직 많다고 봄
      rustc 개발자들과 친해서 코드베이스의 여러 문제를 자주 듣는 점도 도움이 됨
    • rustc에는 Cranelift backend가 있음
    • LLVM이 실제로 느린 부분처럼 보임. Zig 컴파일 시간 논의에서도 그런 양상을 봤고, 자체 호스팅 대응 구현은 LLVM보다 상당히 빠름1
답변달기