krabby: तेज़ Rust compiler बनाना

 (bal-e.org)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Krabby rustc की धीमी compile speed को बेहतर बनाने की कोशिश करने वाला performance-first blank-slate Rust compiler implementation है
  • rustc में महसूस होने वाले performance improvements अब single function changes से कम और API तथा data structure changes से ज़्यादा आते हैं, लेकिन बड़े codebase और stability requirements की वजह से बड़े पैमाने के बदलाव कठिन हैं
  • Krabby एक ऐसे छोटे codebase में, जिसे एक व्यक्ति नियंत्रित करता है, stability को प्राथमिकता दिए बिना compiler components को साथ में फिर से design करके नई optimization opportunities और अधिक cohesive architecture खोजने की कोशिश करता है
  • लक्ष्य यह परखना है कि compiler performance को बहुत बढ़ाने के लिए design को पूरी तरह फिर से सोचना पड़ता है या नहीं, और यह परिकल्पना Rust जैसी जटिल भाषा में भी लागू होती है या नहीं
  • कोड Codeberg के krabby repository में सार्वजनिक है, और प्रगति को Fediverse पर हर 1–2 हफ्ते में कम से कम एक बार पोस्ट करने का लक्ष्य है

Krabby के लक्ष्य और पृष्ठभूमि

  • Rust पसंदीदा भाषा है, लेकिन rustc compiler साफ़ तौर पर धीमा है
  • rustc performance सुधारने पर पहले से बहुत लोग काम कर रहे हैं, और single function change से महसूस होने वाले performance gains देने वाले ज़्यादातर improvements लगभग लागू हो चुके हैं
  • अब meaningful improvements मुख्यतः API और data structure changes से आते हैं, लेकिन rustc जैसे बड़े codebase में कई features के विकास और stability requirements के कारण बड़े architectural changes करना व्यावहारिक रूप से कठिन है
  • Krabby performance को प्राथमिकता देने वाला blank-slate Rust compiler implementation है, और इसका लक्ष्य rustc से मूल रूप से अलग है
  • क्योंकि छोटा codebase एक व्यक्ति के नियंत्रण में है और stability को प्राथमिकता नहीं दी जाती, इसलिए यह ऐसा approach अपनाता है जिसमें सभी components को एक-दूसरे के संदर्भ में design करके नई optimization opportunities खोजी जाएँ और अधिक cohesive architecture बनाया जाए
  • इसकी शुरुआत इस परिकल्पना से होती है कि compiler performance में बड़ा सुधार लाने के लिए compiler design को पूरी तरह फिर से सोचना होगा
  • इसका उद्देश्य यह दिखाना है कि बड़े architectural optimizations, target language चाहे जो भी हो, छिपे हो सकते हैं, और वे सिर्फ़ C जैसी सरल भाषाओं पर ही नहीं बल्कि Rust जैसी जटिल भाषाओं पर भी लागू हो सकते हैं
  • भले ही अंतिम design Rust के लिए विशेषीकृत हो, फिर भी इस प्रक्रिया से सीखने लायक बहुत कुछ है

प्रोजेक्ट की स्थिति और सार्वजनिक सामग्री

  • Krabby बहुत बड़ा प्रोजेक्ट है, और इसे पूरा कर पाना या स्वयं इसका सही व्यक्ति होना—इनमें से किसी पर भी पूरा भरोसा नहीं है
  • फिर भी code को optimize करने और उसे अधिक पूर्ण बनाने की प्रक्रिया स्वयं पसंद है, और जिस उद्देश्य को मूल्यवान माना जाता है उसके लिए अच्छा code लिखने का आनंद अब तक इसकी प्रेरक शक्ति रहा है
  • कोड Codeberg के krabby repository में सार्वजनिक है
  • प्रगति को Fediverse पर हर 1–2 हफ्ते में कम से कम एक बार पोस्ट करने का लक्ष्य है, और अधिक गहरे, लंबे updates उसी साइट पर पोस्ट किए जाएँगे
  • रुचि रखने वाले लोग ईमेल से संपर्क कर सकते हैं

  • संबंधित प्रगति लेख

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Lobste.rs की राय

  • लगता है हर कोई अपना vanity license रखना चाहता है https://codeberg.org/bal-e/krabby/…

    • hobby project के लिए यह ठीक हो सकता है, लेकिन यह इस बात का संकेत भी देता है कि यह प्रोजेक्ट किसी गंभीर दिशा से ज़्यादा एक casual project है
      इस लाइसेंस में व्यक्तिगत और गैर-व्यावसायिक उपयोग व शेयरिंग मुफ्त है, लेकिन उसके ऊपर बने सॉफ़्टवेयर को भी उन्हीं शर्तों पर शेयर करना होगा, और व्यावसायिक उद्देश्य के लिए सिर्फ 30 दिनों का ट्रायल उपयोग संभव है
      मुझे जिज्ञासा है कि क्या Codeberg प्रोजेक्ट लाइसेंस के लिए libre/open source को लेकर सख्त शर्तें मांगता है। मुझे पता था कि Codeberg सिर्फ FOSS होस्ट करता है, इसलिए non-commercial use restriction थोड़ा अप्रत्याशित लगा, हालांकि हो सकता है मैं हाल की स्थिति से पूरी तरह अपडेट न हूँ
    • हाँ, मुझे पता है... मैं भी लाइसेंस को लेकर काफ़ी समय से सोच रहा हूँ, और अभी जब मैं इस पर अकेले काम कर रहा हूँ, तो इसे AGPL में बदलने पर विचार कर रहा हूँ

  • Rust बहुत बड़ा है। यह प्रोजेक्ट “खुद से web browser बनाना” जितना कठिन नहीं लगता, लेकिन इसका मतलब यह बिल्कुल नहीं कि यह आसान है। फिर भी इतने बड़े लक्ष्य की मैं सराहना करता हूँ
    krabby: motivations को देखने पर लगता है कि speed इस प्रोजेक्ट का मुख्य कारण है
    Rust के बारे में मेरी समझ के अनुसार type checking, borrow checking वगैरह पहले से ही काफ़ी तेज़ हैं, और bottleneck code generation है, जिसका बड़ा हिस्सा Rust से ज़्यादा LLVM से जुड़ा हुआ है
    मुझे जिज्ञासा है कि आजकल Cranelift की दिशा क्या है, और क्या इसमें code generation की speed बढ़ाने वाले विचारों से कोई overlap है

    • उस धारणा का मतलब है कि rustc+LLVM की पूरी संरचना सही है, और अब सिर्फ constant factors ही मायने रखते हैं
      निजी तौर पर मुझे काफ़ी भरोसा है कि पूरी compile pipeline को देखें तो यह बात सही नहीं बैठती। हमें MIR-only rlib चाहिए, और ऐसा backend भी चाहिए जो अनंत RAM के बिना whole-world optimization कर सके (यह टिप्पणी देखें)
      “Codegen Unit” पूरी तरह accidental complexity है
    • यह इस पर निर्भर करता है कि आप ठीक-ठीक क्या कर रहे हैं: Depends on what exactly you're doing
      खासकर libraries और binaries का विस्तृत breakdown दिलचस्प हो सकता है
      LLVM बहुत तेज़ नहीं है, लेकिन मुझे याद है कि rustc का LLVM को कुछ हद तक bloated IR देना भी मददगार नहीं रहा
    • धन्यवाद :) लगता है Rust compile time को लेकर लोगों के नज़रिए काफ़ी अलग-अलग हैं। कोई type checking को दोष देता है, तो कोई LLVM को
      मेरा मध्यम-अवधि लक्ष्य, यानी अगले लगभग 5 वर्षों का लक्ष्य, cargo check है, इसलिए मैं code generation को छू नहीं रहा
      फिर भी मुझे लगता है कि बेहतर parallelism, diagnostic code के hot path को अलग करना, type checking और borrow checking के बीच दोहराए जाने वाले काम को कम करना, और core data structures की memory layout सुधारना जैसी चीज़ों में optimization की अब भी काफी गुंजाइश है
      यह भी मदद करता है कि मेरी rustc developers से काफ़ी पहचान है, इसलिए codebase की कई समस्याओं के बारे में अक्सर सुनता रहता हूँ
    • rustc में Cranelift backend है
    • LLVM सच में धीमा हिस्सा लगता है। Zig compile time की चर्चाओं में भी ऐसा ही पैटर्न दिखा था, और self-hosted समकक्ष implementation LLVM की तुलना में काफ़ी तेज़ है1