LLVM से तलाक़ की अर्जी

 (github.com/ziglang)
2 पॉइंट द्वारा GN⁺ 2023-07-01 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Zig प्रोजेक्ट का लक्ष्य मुख्य zig executable file से LLVM, Clang, LLD library dependencies को पूरी तरह हटाना है
  • बचा हुआ काम LLD हटाने, LLVM API calls हटाने, C/x86/wasm/aarch64 backend की प्रगति, Clang पर निर्भर subcommands और preprocessing का उपयोग हटाने, zig ar का replacement implementation आदि में बंटा है
  • LLVM backend पहले से .bc files output करता है, लेकिन Zig compiler के पास .bc को object file में compile करने की क्षमता नहीं रहेगी; इस स्थिति में Clang को अलग से install करना होगा
  • अपेक्षित फायदों में source build और bootstrap को सरल बनाना, Linux distributions और Homebrew में LLVM/Clang/LLD से जुड़ी समस्याओं से बचना, और binary size को लगभग 150 MiB → 5 MiB तक घटाना बताया गया है
  • Zig अपनी optimization passes implement कर सकता है और alive2 जैसे research projects के साथ Intel, ARM, RISC-V chip manufacturers से direct contributions आकर्षित कर सकता है—यह दिशा सामने रखी गई है

Zig executable file से हटाई जाने वाली dependencies

  • इस issue का लक्ष्य Zig प्रोजेक्ट से LLVM, Clang, LLD libraries को पूरी तरह हटाना है
  • बचे हुए connection points को LLD, LLVM, Clang, zig ar क्षेत्रों में व्यवस्थित किया गया है

LLD से जुड़े बचे हुए काम

LLVM से जुड़े बचे हुए काम

Clang से जुड़े बचे हुए काम

zig ar और .bc file handling constraints

  • zig ar: a drop-in llvm-ar replacement #9828: zig ar को llvm-ar replacement बनाने का काम बाकी है
  • LLVM backend पहले से .bc files output करता है, लेकिन Zig compiler के पास .bc files को object files में compile करने की क्षमता नहीं रहेगी
  • इस use case को संभालने के लिए Clang को अलग से install करना होगा

Dependency removal से अपेक्षित बदलाव

  • Zig-side bugs सभी Zig project की जिम्मेदारी के दायरे में आ जाएंगे
  • compiler को source से build और bootstrap करने की प्रक्रिया सरल होगी, और host system पर केवल C compiler होना पर्याप्त होगा
  • Linux distributions और Homebrew जैसे package managers को LLVM, Clang, LLD से जुड़ी वे समस्याएं अब handle नहीं करनी पड़ेंगी जो वे बनाते थे
  • Zig compiler binary size लगभग 150 MiB से 5 MiB तक घट जाएगा
  • compile speed कई orders of magnitude तक तेज हो सकती है
  • Zig अपनी optimization passes implement करके computing की state of the art को आगे बढ़ा सकता है
  • alive2 जैसे research projects को आकर्षित कर सकता है
  • Intel, ARM, RISC-V chip manufacturers जैसे stakeholders से direct contributions प्रेरित कर सकता है, जो अपने CPUs पर बेहतर machine code चाहते होंगे

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

2 टिप्पणियां

 
alstjr7375 2023-07-02

क्या LLVM जितनी optimization या platform support संभव होगी..
 
GN⁺ 2023-07-01
Hacker News की राय

  • Andrew वैसे भी बहुत तेज़-तर्रार इंसान हैं, इसलिए अगर इसे लक्ष्य के रूप में घोषित किया गया है तो लगता है टीम आखिरकार इसे कर ही लेगी
    लेकिन Zig की LLVM-संबंधित मुश्किलों को अच्छी तरह न जानने वाले नज़रिए से देखें तो यह फ़ैसला टीम की क्षमता को Zig ख़ुद से हटाकर binutils जैसे आसपास के टूल्स की तरफ़ मोड़ने जैसा लगता है
    सिर्फ़ शीर्षक देखकर तो मुझे लगा था कि वे compiler को छोड़ रहे हैं, और Zig जैसे प्रोजेक्ट के लिए LLVM को बनाए रखने से भी काफ़ी फ़ायदा दिखता है
    फिर भी LLVM के भीतर के बहुत से code को C++ की जगह Zig में दोबारा लिखने की योजना काफ़ी शानदार और महत्वाकांक्षी है। इसे LLVM बनाने वाले Lattner की कोशिश जितना महत्वाकांक्षी भी कहा जा सकता है
    लेकिन अगर Zig भी LLVM जितना लोकप्रिय और उपयोगी हो गया, तो गलती से quadratic time complexity वाला code बन जाना उससे बच पाना मुश्किल होगा

    • इससे मुझे NASA के किसी अनौपचारिक project management दस्तावेज़ में पढ़ी एक पंक्ति याद आती है
      उसका आशय था: “अगर कोई space mission मौजूदा launch vehicle का पुन: उपयोग नहीं करता, तो वह project launch vehicle development project बन जाता है, और बाकी सब कुछ, जिसे पहले mission का मूल समझा जाता था, गौण हो जाता है”
      और जो हिस्सा मुझे और याद है, उसमें यह पूर्वधारणा भी जुड़ी थी: “मौजूदा launch vehicle के हिसाब से समझौता करने के बजाय अगर किसी खास mission के लिए अलग launch vehicle बनाया जाए, तो वह ज़्यादा सस्ता और कुशल लग सकता है”
    • Swift की सफलता पर Chris Lattner का हाल का interview याद आता है। उनके हिसाब से सफलता का एक कारण यह था कि बड़े Objective-C project में कुछ भी फिर से लिखे बिना Swift को मिलाकर इस्तेमाल करना शुरू किया जा सकता था
      Rust की सफलता का एक हिस्सा भी C/C++ जैसी compatibility पर टिका है
      Zig के लिए ऐसी क्षमता के बिना सफल होना कल्पना करना मुश्किल है, इसलिए उम्मीद है कि वे इस milestone को ज्यों का त्यों आगे नहीं बढ़ाएँगे
    • LLVM से इसका बड़ा फ़र्क है। कम से कम उस संदर्भ में जब Apple ने project अपने हाथ में लिया था, विकल्प बहुत कम थे
      क्योंकि GCC, Apple जो चाहता था या जिसे ज़रूरी मानता था, उसे अनुमति देने या लागू करने को तैयार नहीं था
    • इसे “लक्ष्य के रूप में घोषित” नहीं किया गया है। यह अभी स्वीकृत न हुआ प्रस्ताव है
    • binutils, portable तरीके से binary code formats संभालने वाले general-purpose code bundle के ज़्यादा क़रीब है, और compiler को उसका आधा हिस्सा, ख़ासकर legacy तक, ज़रूरी नहीं होता
      अगर TCC की तरह ज़्यादा focused रहा जाए, तो ज़्यादातर काम कई architectures के लिए code generation की तरफ़ होगा

  • यहाँ दो समस्याएँ हैं। एक है code generation, और दूसरी bootstrapping
    अनुभव से कहूँ तो compiler के optimization passes लिखना आसान और मज़ेदार होता है। Register allocation और SSA form समझने के लिए papers पढ़ने पड़ते हैं, लेकिन IR को अलग-अलग optimization passes से गुज़ारते हुए उसे धीरे-धीरे निखारने वाला code मज़े से लिखा जा सकता है
    LLVM के बिना भी high-quality optimization passes बनाए जा सकते हैं। लेकिन IR को machine code में linearize करने वाला चरण, जब तक आपको “mov [eax+8*ebx], 123” instruction को x86-32/64 पर encode करने के हर तरीके से प्यार न हो, उबाऊ और साधारण काम है
    अगर आप binary size optimize कर रहे हों, तो क्या आप मापना चाहेंगे कि किस platform पर “push eax; push eax; push eax” की लंबाई “add rsp,12” से कम है? यह तो सिर्फ़ x86 की बात है, और जब इसे उन non-x86 architectures तक बढ़ाएँ जो ज़्यादातर developers के लिए महत्वपूर्ण भी नहीं हैं, तो काम बहुत बढ़ जाता है
    कम इस्तेमाल होने वाले architectures के code generator में बड़े bugs कई साल तक पकड़े ही न जाएँ, इसकी संभावना भी बहुत ज़्यादा है
    दूसरी समस्या bootstrapping है। Zig में लिखा गया Zig compiler आख़िर किससे compile होगा? उदाहरण के लिए, C में लिखा कोई unoptimized minimal Zig compiler इस्तेमाल करके Zig compiler को compile किया जा सकता है
    लेकिन अगर वह unoptimized है, तो फिर optimized Zig compiler से Zig compiler को दोबारा recompile करना पड़ेगा। यह कोई असंभव समस्या नहीं है, लेकिन लंबी और जटिल build process संभावित contributors को दूर भगा सकती है

    • लगता है यह लेख bootstrapping समस्या को कवर करता है: https://ziglang.org/news/goodbye-cpp/
    • Zig पहले से ही C backend के ज़रिए bootstrap करता है, इसलिए दूसरी समस्या वास्तव में समस्या नहीं है

  • Zig ने C, और शायद C++ तक compile कर सकने की बात का इतना प्रचार किया, और अब LLVM को पूरी तरह हटाने की बात करना काफ़ी कट्टर लगता है
    जब तक बहुत ज़्यादा लोग support में योगदान न दें, LLVM-स्तर के platform support के क़रीब पहुँचना भी बहुत असंभव लगता है
    जो लोग चाहें उनके लिए अपना backend जोड़ने की योजना समझ में आती है, लेकिन LLVM को बस हटा देना जल्दबाज़ी लगता है

    • अगर काम पहले ही शुरू हो चुका है तो इसे जल्दबाज़ी कहा जा सकता है, लेकिन issue tracker में “accepted” label न रखने वाले दूसरे प्रस्तावों की तरह अभी यह सिर्फ़ चर्चा और counter-proposals आमंत्रित करने का चरण है
      अभी टीम feedback इकट्ठा कर रही है, प्रभावित use cases समझ रही है, और feasibility का अंदाज़ा लगा रही है, इसलिए इसे जल्दबाज़ी कहना उल्टा होगा
    • linked issue के मुख्य भाग को पढ़ें तो LLVM backend को पूरी तरह हटाया नहीं जा रहा। बस इसे main binary से अलग किया जा रहा है, और अगर system में LLVM installed है तो इसे अब भी आसानी से backend की तरह इस्तेमाल किया जा सकता है
      आम उपयोग में ज़रूरत भी न पड़ने वाली 100MB+ LLVM copy को bundle करना कुछ अजीब है, इसलिए बात समझ में आती है। Developers के पास वैसे भी वह installed होने की संभावना रहती है
      हालाँकि यह सुनिश्चित करना मुश्किल हो सकता है कि installed Zig, system के LLVM version के साथ सही तरह काम करे। देखना होगा
    • यह अब भी LLVM bitcode output करता है, लेकिन अब LLVM libraries पर निर्भर नहीं रहेगा
      https://github.com/ziglang/zig/issues/13265
    • मैंने भी इसे ठीक ऐसे ही समझा
      हाल में मैंने Zig के बारे में थोड़ा और पढ़ा, और इसे system packages से जूझे बिना LLVM के साथ C++ को आसानी से compile करने के तरीके के रूप में भी इस्तेमाल किया। C/C++ से Zig की तरफ़ बढ़ पाने की बात एक बड़ा selling point थी
      यह बहुत अचानक और अप्रत्याशित लगता है। project के लिए सही है या ग़लत, यह नहीं जानता, लेकिन मेरी नज़र में यह वाक़ई बहुत बेतुका और अचानक लगा
    • मैं Rust project में Zig को C++ compiler की तरह इस्तेमाल कर रहा हूँ। क्योंकि GitHub Actions में cross-compilation करने का यह सबसे कम दर्दनाक तरीका था

  • एक ओर dependencies कम करने की इस सावधानीपूर्ण इच्छा का सम्मान है, लेकिन इसकी क़ीमत काफ़ी भारी लगती है
    C++ compatibility का खोना मेरे आसपास के Zig प्रशंसकों द्वारा सबसे ज़्यादा बताए जाने वाले फ़ायदों में से एक को लगभग ख़त्म कर देता है
    performance loss भी, भले अस्थायी हो, उनके द्वारा साथ में बताए जाने वाले दूसरे बड़े बिंदु में आता है

    • ज़्यादातर प्रतिक्रियाएँ इस प्रस्ताव के ख़िलाफ़ लगती हैं
      जो लोग बस सरसरी तौर पर पढ़ रहे हों, उनके लिए: यह तय हो चुकी बात नहीं, बल्कि एक प्रस्ताव है

  • मैंने लगभग 4 साल तक embedded projects और libraries पूरी तरह Zig में लिखीं, तो क्या अब कई tier 1 supported architectures बस हट जाएँगी?
    भाषा उनकी है, वे जैसा चाहें वैसा कर सकते हैं, लेकिन अगर ऐसा है तो branding भी उसी हिसाब से बदलनी चाहिए

    • क्या वे सचमुच हट रही हैं?
      शायद tier 1 support दो श्रेणियों में बँट जाएगा: built-in tier 1 support, और optional LLVM backend के ज़रिए tier 1 support।
      अगर किसी architecture को पहले से tier 1 support मिला हुआ है, तो LLVM backend को optional dependency बनाने से वह support खोने की कोई वजह नहीं दिखती।
      जैसा Andrew ने proposal में लिखा, यह तरीका शायद अपेक्षाकृत कम प्रचलित architectures को बेहतर support देने का रास्ता भी बन सकता है। किसी दिलचस्प processor architecture के लिए Zig backend पर मैं खुशी से काम करूँगा, लेकिन LLVM में कभी योगदान नहीं दूँगा। C++ में काम करना कोई शौकिया काम नहीं है
    • क्या मतलब LLVM जो कुछ करता है, उसे अपनी तरह से फिर से implement करके LLVM को हटा देंगे?
      उसका फायदा क्या होगा? क्या यह resources की बर्बादी नहीं है?
    • यह कोई छिपी बात नहीं कि Zig अभी 1.0 से पहले है। इसके लिए पूरी ज़िम्मेदारी उन्हीं पर डालना मुश्किल है, लेकिन फिर भी यह काफ़ी उग्र proposal लगता है
    • यह अभी सिर्फ proposal stage में है। GitHub issue भी मुख्यतः पक्ष-विपक्ष और use cases पोस्ट करने की जगह है, यह Accepted नहीं है
    • चूँकि यह अभी proposal है, अगर काफ़ी लोग अपनी राय देंगे — और कई लोग दे भी रहे हैं — तो मुझे लगता है core team भी अपना approach adjust करेगी

  • DLang में 3 compilers हैं
    gdc, GNU compiler collection backend पर आधारित है, ldc, LLVM backend पर आधारित है, और dmd उस x86 code generator पर आधारित है जिसे मैंने Zortech/Symantec/Digital Mars के लिए लिखा था
    तीनों के अपने फायदे-नुकसान और अलग target हैं, लेकिन वे जिस D language को support करते हैं, वह एक ही है
    कुल मिलाकर users को choices पसंद आती हैं, और कुछ लोग एक से ज़्यादा का साथ में इस्तेमाल भी करते हैं

    • यहाँ approach का एक दिलचस्प अंतर है। D में पूरी तरह अलग-अलग compilers दिखते हैं, लेकिन Zig शायद इस दिशा में जा रहा है कि अगर LLVM installed हो, तो main Zig compiler उसे backend support के रूप में इस्तेमाल करे
      अगर यही सही समझ है, तो मुझे Zig का approach पसंद है
    • कई compilers वाली एक और language Common Lisp है। इसमें लगभग दस production-ready compilers हैं, कुछ commercial हैं लेकिन ज़्यादातर free हैं
      इसकी वजह से development के दौरान सबसे तेज compiler इस्तेमाल किया जा सकता है, और final release के लिए सबसे तेज runtime performance या सबसे कम memory usage वाला compiler चुना जा सकता है, जो काफ़ी उपयोगी है
      और अगर कोई language specification हो जिसे सभी compilers follow करें, तो language के stable रहने और नीचे की परत में अचानक न टूटने की गारंटी भी मिलती है
      बेशक Zig जैसी भाषा में, जहाँ अभी भी मनचाही चीज़ें बदलकर भाषा को अधिक consistent, साफ़ और powerful बनाया जा सकता है, उसके भी अपने फायदे हैं। लेकिन आजकल मैं इस तरह की stability को कहीं ज़्यादा महत्व देता हूँ, क्योंकि इससे development tools के पीछे भागते रहने के बजाय users के लिए असली value बनाने पर ध्यान दिया जा सकता है
    • power users के लिए choices होना एक फायदा है, लेकिन चुनना पड़ना अपने आप में एक बड़ा नुकसान भी है
    • मैं समझता हूँ कि users को choices पसंद होती हैं, लेकिन अगर Zig का long-term लक्ष्य व्यापक adoption है, तो DLang अच्छा precedent नहीं है

  • Zig के दिलचस्प लगने की एक मुख्य वजह यह थी कि उसे सीधे C/C++ compiler के विकल्प के रूप में plug in किया जा सकता था
    मेरे दोस्तों ने कहा था कि Windows पर Zig को C/C++ compiler की तरह install करना किसी भी दूसरे alternative से आसान है
    अगर यह proposal स्वीकार हो गया, तो मुझे व्यक्तिगत रूप से लगता है कि Zig की लोकप्रियता Hare या अन्य बेहद niche languages के स्तर तक गिर जाएगी
    अपने सहकर्मियों को Zig एक बार आज़माने के लिए मनाने हेतु मुझे Uber के production use पर लिखे लेख तक भेजने पड़े थे। अगर मौजूदा projects में उसका तुरंत practical value न होता, तो वे दूसरी बार सोचते भी नहीं
    फिर भी मैं proposal की पृष्ठभूमि समझता हूँ। LLVM compile times बेहद खराब महसूस हो सकते हैं, और अपना bytecode होने से कुछ बढ़िया optimization techniques भी लागू की जा सकती हैं। LLVM bugs से निपटना लगभग हाथ न लगाने लायक काम है, और Julia ecosystem में भी मैंने ऐसा होते देखा है
    अगर मेरी recommendation की कोई कीमत है, तो Zig को 1) debug builds के लिए तेज build और तेज debugging हेतु custom bytecode इस्तेमाल करना चाहिए, और 2) release builds में तेज runtime performance के लिए LLVM इस्तेमाल करना चाहिए
    अगर C/C++ cross-compilation support बनाए रखते हुए 1) हासिल किया जा सके — जैसे उस हिस्से को ही LLVM को सौंप दिया जाए — तो अतिरिक्त backend code maintain करने का trade-off होने के बावजूद यह सबसे अच्छा समझौता हो सकता है

    • Julia ecosystem में LLVM bugs से जूझने वालों में से एक होने के नाते, हाँ, बिल्कुल
      इसके लिए high-level Julia compiler work से अलग एक अलग skill set चाहिए, और bug fixes को upstream में merge होने में कभी-कभी लंबा समय लगता है
      लेकिन वास्तव में हमारा upstream के साथ काफ़ी अच्छा और productive संबंध है, और अगर हमने LLVM हटाने का फैसला किया होता तो project बहुत कम काम कर पाता
      खासकर GPU support और HPC support, जैसे PPC, LLVM पर निर्भर करते हैं
      इसी वजह से हम इस बात पर टिके रहते हैं कि Julia को हमारे patchset/fork के साथ build किया जाए, और उन Julia builds में आने वाले bugs पर समय नहीं लगाते जो उन patches का इस्तेमाल नहीं करते। यह खासकर distribution builds में अक्सर होता है

  • दूसरी languages के non-LLVM backend work को देखते हुए, linked proposal में घमंड बहुत ज़्यादा महसूस होता है
    अगर इसे वही व्यक्ति न लिख रहा होता, तो मैं इसे किसी Zig beginner द्वारा जल्दबाज़ी में लिखे GitHub issue की तरह टाल देता
    इसमें ज़रूरी काम की मात्रा को कम करके आँका गया है, LLVM में हुए सारे काम को परोक्ष रूप से छोटा दिखाया गया है, और “ज़ाहिर है कि हम इसे सस्ता, तेज़ और बेहतर कर सकते हैं” वाली आत्मविश्वासी, macho-सी भावना हर वाक्य में झलकती है। निराशाजनक है
    अब तक मैं Andrew के काम का सचमुच सम्मान करता आया हूँ, इसलिए मैं उसे good faith में यही मानना चाहूँगा कि शायद यह जल्दी या impulsively लिखा गया था और उन्हें अंदाज़ा नहीं हुआ कि यह ऐसा लगेगा
    लेकिन यह लेख भरोसा नहीं जगाता, न ही proposal को और खुले मन से देखने के लिए प्रेरित करता है

    • मुझे LLVM backend के बारे में कुछ नहीं पता, लेकिन जो library users की 100% समस्याएँ हल करने की कोशिश करती है, वह अक्सर ज़्यादा optimized alternatives की तुलना में संभालने में कठिन और धीमी हो जाती है
      Webpack और esbuild इसका उदाहरण हैं

  • LLVM के बिना कुछ बनाने का सही समय कुछ साल पहले था। लेकिन अब अगर C++ features हटा दिए गए, तो यह Zig के अंत की शुरुआत हो सकती है
    यह हैरानी की बात है कि चरणबद्ध हटाने के बजाय Zig में अपना C++ compiler लिखने की योजना घोषित नहीं की गई

    • सिर्फ C++ parser लिखना ही एक बहुत बड़ा project है
      मुझे यक़ीन नहीं कि 18वें जन्मदिन पर शुरू करने वाला कोई व्यक्ति C++ compiler लिख पाएगा। हो सकता है कि एक काम करने वाला compiler बनाने लायक ज़िंदगी का समय ही पर्याप्त न बचे

  • Zig दुनिया का नया C बनना चाहता है, दुनिया का नया C++ बनना नहीं
    इस प्रस्ताव में भी देखा जा सकता है कि C cross-compilation का समर्थन जारी रहेगा
    यह चुनाव सही हो सकता है। C अभी embedded दुनिया में बहुत इस्तेमाल होता है, और उस क्षेत्र में LLVM अच्छा नहीं है
    अगर मैं Zig होता, तो मैं सभी microcontroller को target करना चाहता, और इसे हासिल करने का यथार्थवादी रास्ता यही है