लो-लेवल ऑप्टिमाइज़ेशन और Zig

• लो-लेवल ऑप्टिमाइज़ेशन को Zig भाषा में आसानी से लागू किया जा सकता है
• compiler ज़्यादातर परिस्थितियों में ऑप्टिमाइज़ेशन अच्छी तरह करता है, लेकिन कभी-कभी बेहतर performance के लिए programmer की मंशा को स्पष्ट रूप से बताना पड़ता है
• Zig, compile-time execution (comptime) फीचर के जरिए high-performance code generation और शक्तिशाली metaprogramming को सपोर्ट करता है
• Rust की तुलना में, Zig annotations और स्पष्ट code structure के साथ अधिक सटीक ऑप्टिमाइज़ेशन की सुविधा देता है
• string comparison जैसी दोहराई जाने वाली operations में comptime का उपयोग करके सामान्य functions से बेहतर assembly code बनाया जा सकता है

---

ऑप्टिमाइज़ेशन और Zig

जैसा कि मशहूर चेतावनी कहती है, "सब कुछ संभव है, लेकिन दिलचस्प चीज़ें आसानी से नहीं मिलतीं।" program optimization हमेशा से developers की मुख्य चिंताओं में से एक रहा है। cloud infrastructure की लागत, latency में सुधार, और system को सरल बनाने जैसी ज़रूरतों के लिए code optimization अनिवार्य है। यह लेख Zig में low-level optimization की अवधारणा और Zig की खूबियों पर केंद्रित है।

क्या compiler पर भरोसा किया जा सकता है?

• आम तौर पर "compiler पर भरोसा करो" जैसी सलाह दी जाती है, लेकिन व्यवहार में compiler उम्मीद से अलग काम कर सकता है या language specification का उल्लंघन भी कर सकता है
• high-level languages में intent को स्पष्ट रूप से व्यक्त करना कठिन होता है, इसलिए performance से जुड़ी सीमाएँ रहती हैं
• low-level languages में code की स्पष्टता की वजह से compiler को ऑप्टिमाइज़ेशन के लिए ज़रूरी जानकारी मिल सकती है; उदाहरण के लिए JavaScript और Zig के maxArray function की तुलना करें तो Zig type, alignment, और alias है या नहीं जैसी बातें runtime नहीं बल्कि compile time पर बता देता है
• वही maxArray operation अगर Zig और Rust में लिखा जाए तो लगभग एक जैसा high-performance assembly code मिल सकता है, लेकिन मंशा को जितना बेहतर व्यक्त किया जाए, ऑप्टिमाइज़ेशन का परिणाम उतना बेहतर होता है
• लेकिन compiler की performance पर हमेशा भरोसा नहीं किया जा सकता, इसलिए bottleneck वाले हिस्सों में code और compilation output को सीधे जाँचना और ऑप्टिमाइज़ेशन के तरीके ढूँढना ज़रूरी है

Zig की भूमिका

• Zig में सटीक स्पष्टता, समृद्ध built-in functions, pointers और annotations, comptime, और अच्छी तरह परिभाषित Illegal Behavior जैसी विशेषताओं की वजह से अमूर्त जानकारी के बिना भी optimized code बनाया जा सकता है
• Rust में memory model की वजह से arguments के alias न होने की गारंटी डिफ़ॉल्ट रूप से मिलती है, लेकिन Zig में इसके लिए सीधे noalias जैसी annotations की ज़रूरत होती है
• अगर LLVM IR को ही आधार माना जाए, तो Zig का optimization level भी काफ़ी ऊँचा है
• सबसे बढ़कर, Zig का comptime (compile-time execution) एक शक्तिशाली optimization tool है

comptime क्या है?

• Zig का comptime code generation, constant value embedding, और type-based generic structs बनाने जैसी चीज़ों में इस्तेमाल होता है, और runtime performance बेहतर करने में महत्वपूर्ण भूमिका निभाता है
• comptime के जरिए metaprogramming लागू की जा सकती है
• C/C++ के macros या Rust के macro system से अलग, comptime कोई अलग syntax नहीं बल्कि सामान्य code है
• comptime code सीधे AST को बदले बिना, सभी types के लिए compile time पर जाँच, reflection, और generation कर सकता है
• comptime की लचीलापन ने Rust जैसी दूसरी languages के सुधारों को भी प्रभावित किया है, और यह स्वाभाविक रूप से Zig भाषा में एकीकृत है

comptime की सीमाएँ

• token-pasting जैसे कुछ macro features को Zig comptime से बदला नहीं जा सकता
• Zig code की readability को महत्व देता है, इसलिए scope के बाहर variables बनाना या macro definitions जैसी चीज़ें अनुमति नहीं हैं
• इसके बजाय Zig comptime के लिए type reflection, DSL implementation, और string parsing optimization जैसे व्यापक metaprogramming उपयोग मौजूद हैं

comptime का उपयोग करके string comparison optimization

• सामान्य string comparison function किसी भी भाषा में लागू किया जा सकता है, लेकिन Zig में जब दो strings में से एक comptime पर ज्ञात constant हो, तो अधिक कुशल assembly code बनाया जा सकता है
• उदाहरण के लिए, अगर एक string हमेशा "Hello!\n" है, तो इसे byte-by-byte की बजाय बड़े block units में compare करने जैसी optimization इस्तेमाल की जा सकती है
• इसके लिए comptime का उपयोग करने पर SIMD vectors, block processing, और remaining bytes optimization जैसे high-performance code को compile time पर generate किया जा सकता है
• इस तरीके से सिर्फ बार-बार होने वाले string comparison ही नहीं, बल्कि static data पर आधारित तरह-तरह की mappings, perfect hash tables, AST parsers जैसी कई performance-केंद्रित implementations भी बनाई जा सकती हैं

निष्कर्ष

• Zig low-level optimization के लिए बेहद उपयुक्त है, और इसकी स्पष्ट code structure तथा शक्तिशाली comptime क्षमता की वजह से सर्वोत्तम performance सीधे हासिल की जा सकती है
• Rust जैसी दूसरी languages की तुलना में भी, Zig की compile-time programming क्षमता और स्पष्टता high-performance software development में बड़ा लाभ देती है
• Zig की optimization क्षमता आगे भी एक महत्वपूर्ण प्रतिस्पर्धी ताकत बनी रहेगी

[GN⁺]

Hacker News टिप्पणियाँ

• Zig में मुझे सबसे दिलचस्प बात इसकी build system की सादगी, cross-compilation, और high iteration speed की चाह लगती है। मैं game developer हूँ, इसलिए performance महत्वपूर्ण है, लेकिन ज़्यादातर ज़रूरतों के लिए अधिकांश भाषाएँ पर्याप्त performance दे देती हैं। इसलिए यह भाषा चुनने का सबसे बड़ा मानदंड नहीं है। किसी भी भाषा में मज़बूत code लिखा जा सकता है, लेकिन लक्ष्य ऐसा future-proof framework बनाना है जिसे दशकों तक maintain किया जा सके। C/C++ हर जगह supported होने की वजह से default choice रहे हैं, लेकिन लगता है Zig भी उतना आगे आ सकता है
  • मज़े के लिए मैंने एक बहुत पुराने Kindle device (Linux 4.1.15) पर Zig चलाकर देखा, और Zig की maturity देखकर हैरान रह गया। ज़्यादातर चीज़ें तुरंत काम कर गईं, और पुराने GDB से भी अजीब bugs debug कर सका। मैं भी Zig से प्रभावित हूँ। मेरा विस्तृत अनुभव यहाँ देखा जा सकता है
  • मुझे लगता है कि ज़्यादातर भाषाओं में मज़बूत code लिखा जा सकता है, लेकिन मैं ऐसा modular code चाहता हूँ जो दशकों आगे तक टिक सके। मुझे Zig पसंद है, लेकिन long-term maintenance और modularity के मामले में इसकी कमियाँ हैं। Zig encapsulation के प्रति प्रतिकूल भाषा है। struct members को private नहीं किया जा सकता। इस issue comment में उसका उदाहरण है। Zig का रुख यह है कि internal representation जैसी कोई अलग चीज़ नहीं होनी चाहिए, और सभी users को internal implementation पता हो तथा वह documented/public हो। लेकिन API contract, जो modular software का मूल है, बचाए रखने के लिए internal implementation छिपा सकना चाहिए, और यह संभव नहीं है। उम्मीद है कि कभी Zig private fields को support करेगा
  • मैंने Rust को हल्के तौर पर इस्तेमाल किया है और वह पसंद आया। लेकिन उसके बारे में "बुरा" सुनकर कुछ समय के लिए रुक गया था, अब फिर से इस्तेमाल कर रहा हूँ। अब भी अच्छा लग रहा है। लोग उससे इतनी नफ़रत क्यों करते हैं, यह समझ नहीं आता। बदसूरत generics syntax की बात करें तो C# और Typescript भी ऐसे ही हैं। Borrow Checker भी low-level language का अनुभव हो तो समझना आसान है
  • Zig एक simpler Rust और बेहतर Go जैसा लगता है। दूसरी तरफ, Zig पर बने tools में से 'bun' मुझे सचमुच बेहद प्रभावशाली लगता है। bun की वजह से जीवन बहुत आसान हो गया है। Rust-आधारित 'uv' भी ऐसा ही अनुभव देता है
  • मैं इस बात से सहमत हूँ कि C/C++ default हैं। C से बेहतर कुछ बनाने की कोशिश अक्सर आखिर में C++ बनकर रह गई। फिर भी कोशिश रुकनी नहीं चाहिए। Rust और Zig इस बात का प्रमाण हैं कि अब भी बेहतर चीज़ की उम्मीद की जा सकती है। मैं अब C++ को और गहराई से सीखने वाला हूँ
• भले ही cutting-edge compilers कभी-कभी language spec तोड़ दें, Clang का infinite loop termination वाला assumption C11 के बाद के standard के अनुसार सही है। C11 में साफ लिखा है: "ऐसे loops जिनका controlling expression constant expression नहीं है, और जो input/output, volatile, sync, या atomic operations नहीं करते, उन्हें compiler terminated मान सकता है"
  • C++ में (आगामी C++26 तक) यह नियम सभी loops पर लागू होता है, लेकिन जैसा आपने कहा, C में यह सिर्फ "ऐसे loops जिनका controlling expression constant expression नहीं है" पर लागू होता है। यानी for(;;); जैसी स्पष्ट infinite loop सचमुच infinite loop ही रहनी चाहिए, और Rust की loop {} भी वैसी ही होनी चाहिए। लेकिन LLVM developers कभी-कभी मान लेते हैं कि वे सिर्फ C++ compiler बना रहे हैं, इसलिए Rust में जब आप कहते हैं "कृपया infinite loop दीजिए", LLVM सोचता है "C++ के हिसाब से ऐसा नहीं होगा, optimize करो!" और समस्या पैदा हो जाती है। यानी गलत optimization गलत भाषा पर लागू हो गई
• compile-time (comptime) feature के बिना भी string comparison को inline और unroll करना C में पूरी तरह संभव है। संबंधित उदाहरण
  • बात सही है! पहला उदाहरण बहुत सरल था। बेहतर उदाहरण compile-time suffix automaton है। और ऊपर लिंक किया गया godbolt code तो उल्टा उन दो चीज़ों में से एक दिखाता है जिन्हें नहीं करना चाहिए
• मुझे नहीं लगता कि उदाहरण के तौर पर दिया गया JavaScript code, जिसके बारे में कहा गया कि V8 में बना bytecode inefficient है, अच्छी तुलना है। Zig और Rust को तो बहुत modern environment target करके compile करने को कहा जाता है, जबकि V8 के लिए ऐसी optimization settings मजबूर नहीं की जातीं। वास्तव में modern JIT भी परिस्थिति अनुकूल होने पर vectorization कर सकते हैं। और अधिकांश modern languages भी string-related optimizations को मिलते-जुलते तरीके से handle करती हैं। संदर्भ के लिए C++ का उदाहरण भी है
  • असल में JS और Zig की तुलना करना सेब और fruit salad की तुलना जैसा है। Zig के उदाहरण में fixed type और fixed size वाले arrays इस्तेमाल हुए, जबकि JS runtime पर कई तरह के types लेने वाला 'generic' code है। इसी वजह से JS में अगर type information सही दे दी जाए तो JIT कहीं तेज़ loop बना सकता है, भले vectorization तक न पहुँचे। व्यवहार में TypedArray अक्सर इस्तेमाल नहीं होते, क्योंकि initialization cost ज़्यादा होती है, और वे तभी ठीक लगते हैं जब reuse अधिक हो। और लेख में कहा गया कि JS code फूला हुआ है, लेकिन इसकी बड़ी वजह यह है कि JIT array length checks पर भरोसा नहीं कर पाता और guards डालता है; असल में हर कोई i < x.length जैसी loop लिखता है जिससे JIT optimization हो पाती है। उस लिहाज़ से यह थोड़ी nitpicking है, हालांकि फ़र्क बहुत सूक्ष्म है
  • Rust और Zig के godbolt examples को पुराने CPU target पर भी बदला जा सकता है। JS side की target limitation का मैंने ध्यान नहीं रखा था। और C++ का उदाहरण यह दिखाता है कि clang कितना अच्छा code निकालता है। फिर भी इस समय assembly पूरी तरह संतोषजनक नहीं लगती (भले Zig किसी खास CPU target के लिए build हो रहा हो)। अगर compile-time Suffix Automaton का C++ port example भी हो तो वह सचमुच दिलचस्प होगा। यह C++ compiler के लिए अनुमान से बाहर comptime के वास्तविक उपयोग का मामला है
• "high-level languages में low-level languages वाली 'intent' की कमी होती है" — इस बात पर मुझे संदेह है। उल्टा, मेरा मानना है कि intent को अधिक विविध और विस्तार से व्यक्त करना high-level languages की ताकत है
  • मैं भी सहमत हूँ। मूल रूप से high-level और low-level languages का अंतर यह है कि high-level language में आप intent व्यक्त करते हैं, जबकि low-level में आपको implementation mechanism स्वयं उजागर करना पड़ता है
  • यहाँ 'intent' का मतलब "इस purchase का tax calculate करो" जैसी business intent नहीं, बल्कि "इन bytes को बाएँ तीन जगह shift करो" जैसी, यानी computer से क्या करवाना है, उसके क़रीब वाली बात है। उदाहरण के लिए purchase.calculate_tax().await.map_err(|e| TaxCalculationError { source: e })?; जैसे code में intent भरा पड़ा है, लेकिन उससे कौन-सा machine code निकलेगा, यह अनुमानित नहीं किया जा सकता
• मुझे Zig का allocator model सचमुच पसंद है। काश Go में GC के बजाय request-per allocator जैसी चीज़ें इस्तेमाल की जा सकतीं
  • Go में custom allocator और arena असंभव तो नहीं हैं, लेकिन usability बहुत खराब है और उनका सही इस्तेमाल कठिन है। language level पर ownership rules को व्यक्त या enforce करने का कोई तरीका भी नहीं है। अंत में आप बस थोड़ा अलग syntax वाली C लिख रहे होते हैं, और GC न हो तो वह C++ से भी ज़्यादा खतरनाक हो सकता है
• "मुझे Zig की verbosity पसंद है" — इस बात से सहमति तो है, लेकिन सच कहूँ तो यह थोड़ा अजीब भी लगता है। C कई जगह ढीली है, जबकि Zig उल्टा बहुत ज़्यादा 'annotation noise' माँगता है (खासतौर पर formulas में explicit integer casting के समय)। संबंधित लेख देखें। performance के मामले में Zig का C से तेज़ होना अक्सर इसलिए होता है कि Zig, LLVM के ज़्यादा aggressive optimization settings (-march=native, whole-program optimization आदि) इस्तेमाल करता है। वास्तव में C में भी unreachable जैसे optimization hints language extension के रूप में दिए जा सकते हैं, और Clang constant folding में भी बहुत आक्रामक है। यानी Zig के comptime और C के codegen का अंतर अक्सर compiler optimization settings से आता है। TL;DR: अगर C धीमा है, तो पहले compiler settings जाँचनी चाहिए। आख़िरकार optimization का केंद्र LLVM ही है
  • अगर बात casting वाले उदाहरण की है, तो उल्टा एक function बनाकर casting को wrap करना code reusability और intent दोनों बढ़ा सकता है

    fn signExtendCast(comptime T: type, x: anytype) T {
      const ST = std.meta.Int(.signed, @bitSizeOf(T));
      const SX = std.meta.Int(.signed, @bitSizeOf(@TypeOf(x)));
      return @bitCast(@as(ST, @as(SX, @bitCast(x))));
    }
    export fn addi8(addr: u16, offset: u8) u16 {
      return addr +% signExtendCast(u16, offset);
    }
    

    इस तरीके से भी बिल्कुल वही assembly निकलती है, और यह ज़्यादा उपयोगी व स्पष्ट है
  • Zig के ideas दिलचस्प हैं, और मूल लेख से जो उम्मीद थी, उसकी तुलना में इसमें compile-time (comptime) और whole-program compilation पर ज़्यादा ज़ोर था। इस पर सहमति है। जानकारी के लिए, Virgil 2006 से compile-time पर पूरी language का उपयोग और whole-program compilation support करता आया है। Virgil LLVM target नहीं करता, इसलिए speed comparison अंततः backend comparison बन जाता है। इस approach की वजह से Virgil method calls को पहले से statically bind (devirtualize) कर सकता है, unused fields/objects को अधिकतम हटा सकता है, field-heap objects तक constant propagation कर सकता है, और पूरी specialization कर सकता है — यानी बहुत शक्तिशाली optimization संभव हैं
  • आगे AI के उपयोग को देखते हुए लगता है कि अधिक explicit और verbose languages का चलन बढ़ेगा। लोग AI के साथ coding करें या नहीं, और वह सही है या नहीं, इससे अलग बात यह है कि बहुत से developers AI की मदद पसंद करने लगे हैं, और languages भी उसी हिसाब से बदलेंगी
  • अगर नया x86 backend आ जाता है, तो आगे C और Zig की performance difference के ऐसे मामले भी दिख सकते हैं जो Zig project की अपनी वजहों से हों
  • explicit integer casting के बारे में जल्द ही कुछ साफ-सुथरा सुधार आने वाला है। संबंधित चर्चा देखें
• "C, Python से तेज़ है" जैसी language-level benchmarking सही नहीं है, लेकिन भाषा की कुछ features optimization में बड़ी बाधा बन सकती हैं। सही language चुनने पर developer और compiler दोनों natural और तेज़ तरीके से intent व्यक्त कर सकते हैं
• Zig का for loop syntax मुझे बहुत अव्यवस्थित लगता है। दो lists को साथ-साथ रखकर positions मिलानी पड़ती हैं, इसे देखकर ही आँखों में दर्द होता है। मुझे लगता है कि हाल की languages बहुत ज़्यादा 'magic' syntax और special symbols डाल रही हैं। शायद मैं इसे घंटों तक देखकर काम न कर सकूँ
  • इस तरह दो arrays को traverse करने का pattern low-level code में बहुत आम है, और parallel traversal भी उतना ही आम है। इसलिए Zig का इसे साफ़ और स्वाभाविक तरीके से support करना उल्टा उचित लगता है। समझ नहीं आता कि इससे आँखों में दर्द क्यों होगा
• optimization बहुत महत्वपूर्ण है। समय के साथ उसका असर और भी बढ़ता जाता है
  • हालाँकि यह बात तभी सही है जब मान लिया जाए कि वह software वास्तव में इस्तेमाल भी होगा