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