krabby: Membuat kompiler Rust yang cepat

 (bal-e.org)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Krabby adalah implementasi kompiler Rust dari nol yang berfokus pada performa untuk memperbaiki lambatnya kecepatan kompilasi rustc
  • Peningkatan performa rustc yang benar-benar terasa kini lebih banyak datang dari perubahan API dan struktur data daripada perubahan pada satu fungsi, tetapi perubahan besar sulit dilakukan karena basis kode yang besar dan tuntutan stabilitas
  • Krabby berupaya merancang ulang komponen-komponen kompiler bersama-sama dalam basis kode kecil yang dikendalikan oleh satu orang tanpa memprioritaskan stabilitas, demi menemukan peluang optimasi baru dan arsitektur yang lebih kohesif
  • Tujuannya adalah menguji hipotesis bahwa untuk meningkatkan performa kompiler secara signifikan, desainnya harus dipikirkan ulang sepenuhnya, bahkan untuk bahasa yang kompleks seperti Rust
  • Kodenya dibuka di repositori krabby di Codeberg, dan perkembangan proyek ditargetkan dipublikasikan di Fediverse setidaknya sekali tiap 1–2 minggu

Tujuan dan latar belakang Krabby

  • Rust adalah bahasa favorit sang pembuat, tetapi kompiler rustc terasa jelas lambat
  • Sudah banyak orang yang berupaya meningkatkan performa rustc, dan perbaikan yang bisa memberi peningkatan performa nyata hanya dengan mengubah satu fungsi pada dasarnya hampir semuanya sudah diterapkan
  • Peningkatan yang bermakna sekarang lebih banyak datang dari perubahan API dan struktur data, tetapi pada basis kode besar seperti rustc, perubahan skala besar pada praktiknya sulit dilakukan karena pengembangan banyak fitur dan tuntutan stabilitas
  • Krabby adalah implementasi kompiler Rust dari nol yang menempatkan performa sebagai prioritas, dan tujuannya secara mendasar berbeda dari rustc
  • Karena basis kodenya kecil, dikendalikan oleh satu orang, dan tidak memprioritaskan stabilitas, pendekatannya adalah merancang semua komponen dengan mempertimbangkan satu sama lain untuk menemukan peluang optimasi baru dan membangun arsitektur yang lebih kohesif
  • Proyek ini berangkat dari hipotesis bahwa untuk meningkatkan performa kompiler secara besar-besaran, desain kompiler perlu dipikirkan ulang sepenuhnya
  • Proyek ini juga ingin menunjukkan bahwa optimasi arsitektur skala besar bisa tersembunyi terlepas dari bahasanya, dan dapat diterapkan bukan hanya pada bahasa sederhana seperti C, tetapi juga pada bahasa kompleks seperti Rust
  • Meski desain akhirnya mungkin sangat khusus untuk Rust, proses pembelajarannya tetap dianggap bernilai

Status proyek dan materi publik

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Pendapat di Lobste.rs

  • Sepertinya semua orang ingin punya lisensi vanity versinya sendiri https://codeberg.org/bal-e/krabby/…

    • Kalau ini proyek hobi mungkin tidak masalah, tapi ini juga memberi sinyal bahwa proyek ini lebih merupakan proyek kasual daripada sesuatu yang benar-benar serius
      Lisensi ini menyatakan penggunaan dan pembagian ulang untuk tujuan pribadi/nonkomersial diperbolehkan gratis, tetapi perangkat lunak yang dibuat di atasnya juga harus dibagikan dengan syarat yang sama, dan untuk tujuan komersial hanya boleh dipakai uji coba selama 30 hari
      Saya jadi penasaran apakah Codeberg mewajibkan syarat libre/open-source yang ketat untuk lisensi proyek. Setahu saya Codeberg hanya meng-host FOSS, jadi adanya pembatasan penggunaan nonkomersial terasa agak mengejutkan, meski mungkin saya ketinggalan perkembangan terbaru
    • Benar, saya juga tahu... saya sudah cukup lama memikirkan masalah lisensi ini, dan sedang mempertimbangkan untuk menggantinya ke AGPL selagi saya masih mengerjakannya sendirian

  • Rust itu besar. Proyek ini tampak sedikit lebih mudah daripada “membuat web browser sendiri dari nol”, tapi tetap sama sekali tidak mudah. Meski begitu, saya menghargai besarnya ambisi tersebut
    Kalau melihat krabby: motivations, kecepatan tampaknya menjadi alasan utama proyek ini
    Dari pemahaman saya tentang Rust, type checking, borrow checking, dan semacamnya sebenarnya sudah sangat cepat; bottleneck-nya adalah code generation, dan sebagian besar dari itu lebih berkaitan dengan LLVM daripada Rust itu sendiri
    Saya penasaran bagaimana keadaan di kubu Cranelift belakangan ini, dan apakah ada irisan dengan ide-ide untuk meningkatkan kecepatan code generation

    • Premis itu mengasumsikan keseluruhan struktur rustc+LLVM sudah benar, dan sekarang yang penting hanya konstanta faktor
      Secara pribadi saya cukup yakin itu tidak masuk akal jika melihat pipeline kompilasi secara keseluruhan. Kita butuh rlib khusus MIR, dan backend yang bisa melakukan whole-world optimization tanpa membutuhkan RAM tak terbatas (lihat komentar ini)
      “Codegen Unit” murni adalah kompleksitas yang tidak esensial
    • Itu tergantung apa tepatnya yang sedang dilakukan: Depends on what exactly you're doing
      Secara khusus, rincian untuk libraries dan binaries mungkin menarik
      LLVM memang bukan yang tercepat, tetapi kalau saya tidak salah ingat, rustc juga cenderung mengirim IR yang membengkak ke LLVM, yang tentu tidak membantu
    • Terima kasih :) Sepertinya orang-orang punya sudut pandang yang cukup berbeda soal waktu kompilasi Rust. Ada yang menyalahkan type checking, ada juga yang menyalahkan LLVM
      Tujuan jangka menengah saya, yaitu untuk sekitar 5 tahun ke depan, adalah cargo check, jadi saya tidak akan menyentuh code generation
      Meski begitu, saya rasa masih banyak ruang untuk optimasi dalam paralelisme yang lebih baik, memisahkan hot path dari kode diagnostik, mengurangi pekerjaan yang duplikatif antara type checking dan borrow checking, memperbaiki tata letak memori dari struktur data inti, dan sebagainya
      Saya juga cukup dekat dengan para pengembang rustc, jadi saya sering mendengar berbagai masalah dalam codebase-nya, dan itu membantu
    • rustc punya backend Cranelift
    • LLVM memang tampak seperti bagian yang benar-benar lambat. Saya juga melihat pola itu dalam diskusi tentang waktu kompilasi Zig, dan implementasi padanan self-hosted-nya jauh lebih cepat daripada LLVM 1