डिबग मोड में self-hosted x86 backend अब डिफ़ॉल्ट है

 (ziglang.org)
1 पॉइंट द्वारा GN⁺ 2025-06-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Zig ने x86_64 targets पर वह डिफ़ॉल्ट path बदल दिया है जिसमें LLVM bitcode को object file में lower करता था, और अब self-hosted x86 backend का उपयोग होता है, जिससे debug builds की compile speed और memory usage में बड़ी कमी आई है
  • self-hosted x86 backend ने 1987 behavior tests पास किए हैं, जो LLVM backend के 1980 से अधिक हैं, और कुल 2084 में से कुछ अतिरिक्त tests केवल self-hosted x86 tests में ही चलाए जाते हैं
  • hello.zig benchmark में LLVM path का औसत 918ms घटकर डिफ़ॉल्ट self-hosted backend पर 275ms हो गया, जिससे wall time में 70.1% की कमी आई, और peak RSS भी 214MB से 137MB पर आ गया
  • Zig compiler जैसे बड़े projects में भी build time 75 सेकंड से 20 सेकंड तक घट गया, लेकिन Windows में COFF linker पर अभी और काम बाकी है, इसलिए वहाँ यह अभी डिफ़ॉल्ट नहीं बना है
  • आगे के काम में code generation का full parallelization, linker improvements, incremental compilation की stability, x86 code quality में सुधार, और aarch64 backend का विस्तार शामिल है

x86_64 डिफ़ॉल्ट backend switch

  • x86_64 target builds में Zig अब डिफ़ॉल्ट रूप से self-hosted x86 backend का उपयोग करता है
  • पहले डिफ़ॉल्ट path वह था जिसमें LLVM bitcode files को object files में lower करता था
  • Windows पर अभी डिफ़ॉल्ट नहीं बदला गया है
    • क्योंकि COFF linker पर अभी और काम की ज़रूरत है

behavior test pass status

  • self-hosted x86 backend ने 1987 behavior tests पास किए हैं
  • LLVM backend ने 1980 behavior tests पास किए हैं
  • कुल behavior tests 2084 हैं, लेकिन अतिरिक्त tests ज़्यादातर LLVM के अपने x86 backend tests के साथ duplicate होते हैं
    • ये अतिरिक्त tests केवल self-hosted x86 tests के दौरान ही चलाए जाते हैं
  • pass count के आधार पर Zig का x86 backend, Zig language implementation में LLVM backend से आगे है

LLVM path से प्रतिस्पर्धा क्यों

  • Zig के LLVM के साथ code generation में प्रतिस्पर्धा करने की सबसे बड़ी वजह यह है कि इससे compile speed का अंतर बहुत बड़ा बनाया जा सकता है
  • इससे जुड़ी पृष्ठभूमि Ziggit की व्याख्या में दी गई है

hello.zig benchmark

  • zig build-exe hello.zig -fllvm result:
    • average wall time: 918ms
    • peak RSS: 214MB
    • CPU cycles: 4.53G
    • instructions: 8.50G
  • zig build-exe hello.zig डिफ़ॉल्ट path result:
    • average wall time: 275ms
    • peak RSS: 137MB
    • CPU cycles: 1.57G
    • instructions: 3.21G
  • डिफ़ॉल्ट self-hosted backend ने LLVM path की तुलना में कई metrics कम किए
    • wall time 70.1% कम
    • peak RSS 36.2% कम
    • CPU cycles 65.2% कम
    • instructions 62.2% कम
    • cache misses 86.1% कम
    • branch misses 78.3% कम

बड़े projects में असर

  • Zig compiler जैसे बड़े projects में build time 75 सेकंड से 20 सेकंड तक घट गया
  • self-hosted x86 backend केवल छोटे examples में ही नहीं, बड़े codebases में भी compile time को काफ़ी कम कर सकता है

आगे का काम

  • Zig ने पहले ही code generation के full parallelization पर काम शुरू कर दिया है
  • linker improvements और bug fixes आगे बढ़ने पर, इस backend के साथ incremental compilation को stable और robust बनाया जा सकेगा
  • generated x86 code quality में अभी भी सुधार की गुंजाइश है
  • अगला target aarch64 है, और नए Legalize pass की वजह से काम तेज़ होने की उम्मीद है
  • latest master branch build को Zig download page से डाउनलोड करके सीधे आज़माया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2025-06-09
Hacker News टिप्पणियाँ

  • मेरी जानकारी में Zig बेहतर development experience के लिए कई चीज़ों पर काम कर रहा है। लगभग हर दिन कुछ न कुछ काम हो रहा है, और अभी-अभी https://github.com/ziglang/zig/pull/24124 जैसा कुछ आया है
    पहले, मेरे ख्याल से hot code replacement की भी योजना थी, और मौजूदा development speed देखें तो x86_64 पर यह एक साल के अंदर चलने लगे तो मुझे हैरानी नहीं होगी
    अभी व्यक्तिगत रूप से सबसे बड़ा दर्द comptime की speed है। compiler को यहाँ बहुत काम करना है, और compile time पर brainF** DSL चलाना काफ़ी धीमा है। मैंने खुद करके देखा, यह मज़ेदार experiment था
    Zig जिन नए backends को ला रहा है, उन्हें लेकर कुल मिलाकर बहुत उत्साह है। मैं Zig के लिए URCL(https://github.com/ModPunchtree/URCL) backend खुद बनाकर देखना चाहता हूँ

    • comptime performance सुधारने के लिए क्या करना है, यह पता है, और बहुत पहले एक branch पर काम भी शुरू किया था। लेकिन इसके लिए semantic analysis code को काफ़ी फिर से काम करना पड़ेगा, इसलिए यह निश्चित रूप से किया जा सकता है, किया जाना चाहिए और किया जाएगा, पर अभी दूसरी priorities से मुकाबला कर रहा है
    • Hot code replacement game development के लिए बहुत बड़ा होगा। यह विचार कि Zig मूल रूप से सिर्फ़ एक compiler flag से इसे support करने लगेगा, कमाल है। clang में एक बार करके दिखाइए
    • सोच रहा हूँ कि comptime का धीमा होना सच में समस्या है या नहीं। मैं JSON-RPC library बना रहा हूँ, और JSON requests को arbitrary functions पर dispatch करने के लिए comptime पर बहुत निर्भर हूँ
      कड़े static types के कारण runtime पर arbitrary parameters वाली function में dynamic dispatch करने का तरीका नहीं है, और मुझे मिला इकलौता तरीका compile time पर comptime से function type mapping निकालना था
      हर arbitrary function के लिए comptime किए गए code की copy बढ़ेगी, इसलिए code size बढ़ने की संभावना है
    • जानना चाहता हूँ कि custom backend बनाना आसान है या नहीं। अभी देखा नहीं है, लेकिन experiment करना चाहता हूँ
      खास तौर पर, AIR लेकर memory safety report बनाने वाला backend बनाया जा सकता है। जैसे undefined values का इस्तेमाल, stack pointer escape, use-after-free, double free, alias xor mut जैसी चीज़ों की पहचान करना
    • URCL की वजह से rabbit hole में उतर रहा हूँ। अभी गहराई से नहीं देखा है, लेकिन सबसे मज़ेदार timeline यह होगी कि Minecraft के लिए बनाया गया intermediate representation कई languages का व्यावहारिक compile target बन जाए

  • यह पहले ही बहुत बड़ी उपलब्धि है, लेकिन development log में लिखे मुताबिक आगे अभी बहुत कुछ बाकी है। compilation के दौरान binary में सिर्फ़ ज़रूरी हिस्सों को modify करने वाले compiler का idea नया भी है और पूरी तरह साहसिक भी, और अब लगता है कि यह Zig project की पहुँच में आ गया है
    आगे का इंतज़ार है

  • “Zig compiler जैसे बड़े project 75 seconds से 20 seconds पर आ जाते हैं। यह तो बस शुरुआत है” वाला हिस्सा exciting है। उत्सुक हूँ कि यह व्यक्ति इससे क्या कर पाएगा, और वह सच में काफ़ी smart लगता है
    Package management किस स्थिति में है, यह जानना चाहता हूँ। QuickJS + SDL3 app बनाने की कोशिश की थी, लेकिन C++ side की उलझन के कारण Rust पर चला गया, और वहाँ सब ठीक-ठाक हो गया। अच्छा होगा अगर Zig में भी try कर सकूँ

    • Zig का package management Rust से ज़्यादा manual है। CLI से package URL fetch करके build script में module import करने का तरीका है
      इसके फायदे भी हैं, क्योंकि आप arbitrary archive पर depend कर सकते हैं, और C libraries को wrap करने वाले कई Zig packages असल में ऐसे build scripts जैसे होते हैं जो unmodified tarball releases पर depend करते हैं। बेशक beginners के लिए यह थोड़ा ज़्यादा कठिन है
      SDL3 के लिए native Zig wrapper है: https://github.com/Gota7/zig-sdl3
      C library/API की ज़्यादा basic repackaging भी है: https://github.com/castholm/SDL
      QuickJS के लिए C API ही इकलौता विकल्प है: https://github.com/allyourcodebase/quickjs-ng
      Zig इस तरह C packages को सीधे इस्तेमाल करना बहुत आसान बना देता है, लेकिन Zig के types बहुत ज़्यादा strict हैं, इसलिए API से interact करते समय बहुत casting करनी पड़ती है
    • dmd D compiler खुद को debug build के रूप में compile कर सकता है
      real 0m18.444s, user 0m17.408s, sys 0m1.688s
      बहुत पुराने processor पर भी इतना है, इसलिए यह इतना fast चलता है कि मैंने upgrade करने की ज़रूरत ही नहीं समझी
      specs कुछ इस तरह हैं: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+, 2 cores, 2.3GHz, cache 512KB
    • जानना चाहता हूँ कि ऐसा करने की कोई guide है या नहीं। जब मैंने Zig compile किया था, तो कई stages से गुजरने में काफ़ी समय लगा था, और इसमें wasm से bootstrap करने की पूरी प्रक्रिया शामिल थी
    • यह हैरान करने वाला है कि Zig खुद को 75 seconds में compile कर सकता है। LLVM इस्तेमाल करने पर भी

  • D और Nature के समय भी कहा था, लेकिन जिन भी languages के पास अपना backend है, उन सभी के लिए हमें LLVM पर निर्भर न रहने की कोशिश करने वाले projects को support करने की ज़िम्मेदारी है
    LLVM के कारण compiler research और development ठहर गया है, बहुत ज़्यादा languages ने LLVM पर depend करने का फैसला किया, और लगता है कि बहुत से लोगों ने fast iteration time को valuable मानना छोड़ दिया या उससे बेहतर की उम्मीद करना छोड़ दिया
    incremental compilation और binary patching से तेज़ iteration, और अच्छी debugging—ये नई languages से उम्मीद होनी चाहिए, इन्हें niche feature या बहुत मुश्किल काम नहीं माना जाना चाहिए

    • दूसरी तरफ, LLVM ने individual लोगों द्वारा बनाई गई languages को भी तुरंत competitive performance और broad platform support देकर तेज़ी से बढ़ने में मदद की। Zig भी उनमें से एक है
      पूरी real-time rendering industry व्यावहारिक रूप से LLVM या LLVM forks पर बनी है, Microsoft ने भी shader compiler को LLVM पर बदला है और अब जाकर code upstream करना शुरू किया है
      ज़्यादातर game console compiler infrastructure भी Clang-based है। Xbox अब तक MSVC पर अड़ा है, लेकिन वह अपवाद जैसा है
      कुल मिलाकर LLVM खास तौर पर नई चीज़ों के bootstrap में बेहद सफल रहा है
    • सही है। Go में जिन कुछ चीज़ों को मैं सकारात्मक मानता हूँ, उनमें से एक यह है कि वह bootstrapped है और LLVM पर निर्भर नहीं है

  • ऐसा नहीं लगना चाहता कि मैं मांग कर रहा हूं या आभार नहीं मान रहा। Zig पर काम मुफ्त में हो रहा है। बस सबसे ज़्यादा जिज्ञासा एक यथार्थवादी 1.0 शेड्यूल को लेकर है
    Zig लो-लेवल भाषा में जो मैं चाहता था, उससे लगभग बिल्कुल मेल खाता है, और मैं इसके स्थिर होने का इंतज़ार कर रहा हूं
    बेशक Zig की minimal design philosophy के लिए मैं सच में आभारी हूं

    • TigerBeetle जैसे गंभीर प्रोजेक्ट version pin करते हैं, शायद latest release इस्तेमाल करते हैं। nightly को मैं ज़्यादा experimental मानता हूं

  • zig init से बना hello world प्रोग्राम compile करने पर 9.3MB का है। -Doptimize=ReleaseSmall के 7.6KB की तुलना में यह 1000 गुना से भी ज़्यादा बड़ा है, जो बहुत भारी है

    • सही observation है। एक और observation यह है कि उसमें से 82% debug information है
      -OReleaseSmall -fno-strip 580KB executable बनाता है, और -ODebug -fstrip 1.4MB executable बनाता है
      Zig का x86 backend, Zig को समझने वाले lldb fork के साथ, कहीं बेहतर debugging experience देता है: https://github.com/ziglang/zig/wiki/LLDB-for-Zig
      अभी comptime logic को step-execute किया जा सकता है या नहीं, याद नहीं। हाल में इसी पर चर्चा हुई थी

  • लगता है कि Julia को अच्छा performance gain पाना हो तो Zig पर switch करने पर विचार करना चाहिए। याद है कि Julia के authors हर LLVM release के साथ performance regressions को लेकर चिंतित रहते थे

    • Julia असल में LLVM से काफ़ी मजबूती से बंधी हुई है। ecosystem का बड़ा हिस्सा intrinsic, automatic differentiation (Enzyme), और GPU compilation की वजह से LLVM की मौजूदगी पर निर्भर है। Base और Core की तो बात ही अलग है
      compiler काफ़ी हद तक retarget किया जा सकता है, और यह भी सक्रिय रूप से चल रहा क्षेत्र है। इसलिए भविष्य में भाषा के कुछ हिस्सों के लिए alternative compiler के रूप में Zig की कल्पना शायद की जा सकती है
    • क्या LLVM को Julia की public API का हिस्सा नहीं माना जाता? असल में IR दिखाने वाला @code_llvm जैसा macro भी है
    • यह compile time घटाने का एक तरीका हो सकता है, लेकिन मुझे लगता है Julia की तरफ अभी बहुत काम बाकी है
      जैसे अधिक fine-grained compile cache, invalidation रोकने के लिए बेहतर tools, world splitting optimization हटाना, compiler में multithreading का ज़्यादा इस्तेमाल, concrete signatures की automatic precompilation, और code compiled होने पर उसे hot-swap करने वाली अधिक lazy code generation
    • हर नए compiler backend के आने पर ऐसी बातें होती हैं। मैं काफ़ी skeptical हूं, लेकिन अगर कोई इसे project के रूप में लेकर करे तो देखना दिलचस्प होगा कि क्या होता है

  • पूरी तरह beginner के नज़रिए से जानना चाहता हूं कि Zig दूसरी भाषाओं से बेहतर किस तरह है। मैं इसे ज़्यादा modern C समझता हूं, तो वह modern हिस्सा क्या है?

    • जो चीज़ें अभी दिमाग में आ रही हैं, उनमें एक integrated build system है, जिसमें कई अलग-अलग obscure tools और languages इस्तेमाल नहीं करने पड़ते
      C के arrays के उलट, Zig में length जानने वाली slices हैं, जो buffer overflow के मामले में बेहतर हैं; explicit optional types को check करना अनिवार्य है; और null pointers allowed नहीं हैं। C code के साथ integrate करते समय जहां अनुमति होती है, वहां भी type इस बात को साफ़ दिखाता है
      enum, tagged union, और switch expressions की enforced exhaustiveness checking भी है
      error handling explicit है, और function ऐसे errors (enum values) return करता है जिन्हें caller को किसी न किसी तरह handle करना पड़ता है। C में function error दिखाने वाला integer return करे, तब भी उसे पूरी तरह ignore किया जा सकता है
      हालांकि errors के साथ data return करने का standard तरीका भाषा में built-in नहीं है। parameter के रूप में error struct pass करने वाला pattern कुछ जोड़ा हुआ सा लगता है, और मुझे लगता है इसके लिए special syntax होना चाहिए
      function return या error आने के बाद cleanup के लिए defer, errdefer blocks हैं, और macros के बजाय comptime code generation और @typeInfo जैसी type reflection इस्तेमाल कर सकते हैं
      libraries को allocator pass किया जाता है ताकि caller आम तौर पर तय करे कि memory कहां और कैसे allocate होगी, और सिर्फ GeneralPurposeAllocator इस्तेमाल करने से भी memory leaks ढूंढना आसान हो जाता है
      programming शुरू करने के बाद से मैं लगातार high-level languages इस्तेमाल करता रहा हूं और C व उसके आसपास के ecosystem की obscure और counter-intuitive चीज़ें नापसंद करता था, लेकिन Zig ने पहली बार systems programming को मेरे लिए enjoyable बना दिया

  • क्या इसमें सिर्फ backend बदला गया है? जानना चाहता हूं कि सारी analysis और type passes अभी भी बाकी हैं, या validation भी कम किया गया है
    तेज़ compile cycle productivity में मदद करता है, लेकिन मेरी नज़र में तभी जब उसमें तेज़ tests भी शामिल हों
    तो debug के लिए Zig को बस interpreted execution में चलाना आसान नहीं होगा? इससे हर target के लिए काम दोहराने की समस्या भी सुलझ जाएगी

    • debug mode का मुख्य बिंदु debuggability है, और interpreted Zig को gdb या lldb जैसे standard debugger से जोड़ना मामूली काम नहीं होगा। क्योंकि ऐसे tools DWARF debug information वाले executable की उम्मीद करते हैं
      इसके अलावा, खासकर game development जैसे क्षेत्रों में debug mode performance भी वाकई बहुत महत्वपूर्ण है
    • बदला सिर्फ backend गया है। tests भी तेज़ होंगे
      interpreter जोड़ने की कोई वास्तविक ज़रूरत नहीं है। custom backend होने का मतलब है कि अभी यह debug में इस्तेमाल हो रहा है, लेकिन बहुत दूर भविष्य में speed के मामले में LLVM से compete भी कर सकता है
      interpreter जोड़ने पर भी आखिरकार custom backend लिखना ही पड़ेगा, इसलिए उसका फायदा कम है
      समस्या यह है कि LLVM debug और release दोनों में धीमा है

  • क्या यह Zig में async/await वापस लाने की prerequisites में से एक नहीं है?
    https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-o...

    • वह हिस्सा सब settle कर दिया गया है, और शायद अगले 2–3 महीनों में कोई दिलचस्प update share कर सकेंगे। I/O को ground up से फिर से बना रहे हैं, और इसका ज़्यादातर हिस्सा standard library का काम है
    • link पढ़ने पर लगता है कि async वापस नहीं आएगा, या कम-से-कम 2028 तक तो नहीं आएगा