krabby: Hızlı bir Rust derleyicisi yapmak

 (bal-e.org)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Krabby, rustc'nin yavaş derleme hızını iyileştirmeyi amaçlayan, performans öncelikli bir sıfırdan Rust derleyicisi uygulamasıdır
  • rustc'de hissedilir performans iyileştirmeleri artık tek bir fonksiyondaki değişikliklerden çok API ve veri yapısı değişikliklerinden geliyor, ancak büyük kod tabanı ve kararlılık gereksinimleri nedeniyle kapsamlı değişiklikler yapmak zor durumda
  • Krabby, tek bir kişinin kontrol ettiği küçük bir kod tabanında kararlılığı önceliklendirmeden derleyici bileşenlerini birlikte yeniden tasarlayarak yeni optimizasyon fırsatları ve daha tutarlı bir mimari bulmayı hedefliyor
  • Amaç, derleyici performansını büyük ölçüde artırmak için tasarımın tamamen yeniden düşünülmesi gerektiği hipotezini Rust gibi karmaşık bir dilde de sınamak
  • Kod, Codeberg'deki krabby deposunda açık olarak yayımlanıyor ve ilerleme durumunu Fediverse üzerinde 1-2 haftada bir ya da daha sık paylaşmak hedefleniyor

Krabby'nin hedefleri ve arka planı

  • Rust, tercih edilen bir dil olsa da rustc derleyicisi belirgin biçimde yavaş
  • rustc performansını iyileştirmek için zaten birçok kişi çalışıyor ve tek bir fonksiyondaki değişiklikle hissedilir performans artışı sağlayabilecek iyileştirmeler neredeyse tükenmiş durumda
  • Anlamlı iyileştirmeler artık API ve veri yapısı değişikliklerinden geliyor, ancak rustc gibi büyük bir kod tabanında çok sayıda özellik geliştirme işi ve kararlılık gereksinimleri nedeniyle büyük ölçekli değişiklikler fiilen zor
  • Krabby, performansı önceliklendiren bir sıfırdan Rust derleyicisi uygulaması ve hedefleri rustc ile temelden farklı
  • Küçük bir kod tabanının tek bir kişi tarafından kontrol edilmesi ve kararlılığın öncelik olmaması sayesinde, tüm bileşenler birbirini gözeterek tasarlanıp yeni optimizasyon fırsatları aranırken daha tutarlı bir mimari kurmayı amaçlayan bir yaklaşım izliyor
  • Çıkış noktası, derleyici performansını ciddi biçimde iyileştirmek için derleyici tasarımının tamamen yeniden düşünülmesi gerektiği hipotezi
  • Büyük ölçekli mimari optimizasyonların, hedef dilden bağımsız olarak gizli durumda bulunabileceğini ve bunun yalnızca C gibi basit dillere değil Rust gibi karmaşık dillere de uygulanabileceğini göstermeyi amaçlıyor
  • Ortaya çıkan tasarım Rust'a özel olsa bile, süreçten öğrenileceklerin değerli olacağı düşünülüyor

Projenin durumu ve açık kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Lobste.rs görüşleri

  • Herkesin kendine ait bir gösteriş lisansı olsun istiyor gibi görünüyor https://codeberg.org/bal-e/krabby/…

    • Hobi projesiyse sorun olmayabilir, ama bu proje için daha ciddi bir işten ziyade gündelik bir proje olduğu sinyalini de veriyor
      Bu lisans, kişisel ve ticari olmayan amaçlarla kullanım ve paylaşımı ücretsiz olarak izinli kılıyor; ancak bunun üzerine yapılan yazılımların da aynı koşullarla paylaşılması gerekiyor ve ticari amaçlar için yalnızca 30 gün deneme kullanımına izin veriyor
      Codeberg'ün proje lisansları konusunda katı libre/açık kaynak şartları isteyip istemediğini merak ediyorum. Codeberg'ün yalnızca FOSS barındırdığını sanıyordum, bu yüzden ticari olmayan kullanım kısıtı şaşırtıcı geldi; ama güncel durumu takip edememiş olabilirim
    • Evet, ben de farkındayım... lisans meselesi üzerine epey zamandır düşünüyorum ve hâlâ tek başıma çalışıyorken AGPL'ye geçmeyi değerlendiriyorum

  • Rust büyük ölçekli. Bu proje “kendi web tarayıcını yapmak”tan biraz daha kolay görünüyor ama kesinlikle kolay değil. Yine de hedefin büyük olması takdire değer
    krabby: motivations sayfasına bakılırsa hız bu projenin ana gerekçesi gibi görünüyor
    Rust hakkındaki benim anlayışıma göre tür denetimi, borrow check vb. zaten çok hızlı; darboğaz kod üretimi ve bunun da önemli bir kısmı Rust'ın kendisinden çok LLVM ile ilgili
    Bugünlerde Cranelift tarafında neler olduğunu ve kod üretim hızını artırma fikirleriyle örtüşen bir yan olup olmadığını merak ediyorum

    • Bu varsayım, rustc+LLVM'nin genel mimarisinin doğru olduğu ve artık yalnızca sabit katsayıların önemli olduğu fikrine dayanıyor
      Bana göre derleme hattına bütün olarak bakınca bu pek mantıklı gelmiyor. Yalnızca MIR içeren rlib gerekiyor ve sınırsız RAM olmadan da tüm dünyayı kapsayan optimizasyon yapabilen bir backend gerekiyor (bu yorum'a bakın)
      “Codegen Unit” tamamen tesadüfi karmaşıklık
    • Ne yaptığınıza bağlı: Tam olarak ne yaptığınıza bağlı
      Özellikle libraries ve binaries için ayrıntılı dağılım ilginç olabilir
      LLVM çok hızlı sayılmaz, ama rustc'nin LLVM'ye bir miktar şişirilmiş IR verme eğiliminin de pek yardımcı olmadığını hatırlıyorum
    • Teşekkürler :) Rust derleme süreleri konusunda insanların bakışı epey farklı gibi. Kimisi tür denetimini suçluyor, kimisi LLVM'yi suçluyor
      Benim orta vadeli hedefim, yani önümüzdeki yaklaşık 5 yıl için hedefim, cargo check; bu yüzden kod üretimine dokunmuyorum
      Yine de daha iyi paralellik, tanılama kodunun sıcak yollarını ayırma, tür denetimi ile borrow check arasındaki yinelenen işi azaltma ve temel veri yapılarının bellek yerleşimini iyileştirme gibi alanlarda hâlâ çok fazla optimizasyon payı olduğunu düşünüyorum
      rustc geliştiricileriyle yakın olmam ve kod tabanındaki çeşitli sorunları sık sık duymam da yardımcı oluyor
    • rustc için bir Cranelift backend var
    • Yavaş olan kısmın gerçekten LLVM olduğu görünüyor. Zig derleme süreleri tartışmalarında da benzer bir tablo gördüm ve self-hosted karşılık implementasyonu LLVM'den oldukça daha hızlı1