Zig की build speed तेज़ हो रही है

• Zig 0.15.1 के रिलीज़ के साथ compile speed में पिछले version की तुलना में बड़ा सुधार हुआ है
• Ghostty project में वास्तविक build time मापने पर, कुल मिलाकर run/build turnaround time कम हुआ है
• अभी भी LLVM का कुछ हिस्सा इस्तेमाल हो रहा है, लेकिन अपने backend के लागू होने पर अतिरिक्त speed improvement की उम्मीद काफ़ी बढ़ी है
• incremental compilation अभी पूरी तरह लागू नहीं हुई है, फिर भी partial build में performance लाभ दिख रहा है
• आगे और तेज़ build environment तथा बेहतर developer experience के साकार होने की संभावना अधिक है

---

अवलोकन

Andrew Kelley के इस कथन, "compiler इतना धीमा है कि bugs पैदा हो जाते हैं," से शुरू होकर Zig ने कई वर्षों तक तेज़ compile time को लक्ष्य बनाकर विभिन्न संरचनात्मक सुधारों पर काम किया है

• Zig टीम LLVM को हटाने, अपना code generation backend विकसित करने, अपना linker बनाने, और अंततः incremental compilation को साकार करने के लिए काम करती रही है
• इस दीर्घकालिक विकास के नतीजे Zig 0.15.1 version में स्पष्ट रूप से दिखने लगे हैं, और एक वास्तविक project (Ghostty) में build time के बदलाव को मापकर साझा किया गया है

Build Script compile speed

• Zig 0.14: 7 सेकंड 167ms
• Zig 0.15: 1 सेकंड 702ms

यह build.zig script के स्वयं के build time का माप है, और यह समय नए source build environment में हर बार चुकाई जाने वाली शुरुआती लागत है

• build script के दोबारा compile होने की आवृत्ति कम रखी जाती है, लेकिन जब उपयोगकर्ता पहली बार project को सीधे build करता है, तब इस अनुभव पर इसका सीधा असर पड़ता है

पूरा non-cached binary build (Ghostty)

• Zig 0.14: 41 सेकंड
• Zig 0.15: 32 सेकंड

यह build script build time सहित पूरे binary build time का माप है

• Zig 0.15 में लगभग 2 सेकंड का अतिरिक्त speed improvement दिखता है, और वास्तविक wall-clock time के आधार पर भी शुरुआती अंतर साफ़ है
• अभी native x86_64 backend का पूरा उपयोग नहीं हो पा रहा है, और ज़्यादातर स्थिति में LLVM का उपयोग जारी है
• आगे जब Ghostty पूरी तरह native backend से build होगा, तब समय 25 सेकंड से नीचे आने का अनुमान है (पहले की तुलना में लगभग आधा)

incremental build (Ghostty executable)

• Zig 0.14: 19 सेकंड
• Zig 0.15: 16 सेकंड

यह किसी अर्थपूर्ण एक-पंक्ति बदलाव (terminal emulation code में log call जोड़ने) के बाद दोबारा build करने में लगा समय है

• build script और dependency graph पहले से cache में हैं, इसलिए यह partial build है
• incremental compilation अभी पूरी तरह लागू नहीं हुई है, फिर भी performance improvement पहले से स्पष्ट है
• उपयोग में मौजूद LLVM को छोड़ दें तो समय लगभग 12 सेकंड तक घटने की संभावना है
• आगे जब वास्तविक incremental build लागू होगा, तब millisecond स्तर के build time की उम्मीद भी की जा रही है

incremental build (libghostty-vt)

• Zig 0.14: 2 सेकंड 884ms
• Zig 0.15: 975ms

एक पंक्ति के बदलाव के बाद केवल libghostty-vt को आंशिक रूप से दोबारा build करने के समय का माप

• libghostty-vt को native x86_64 backend पर पूरी तरह build किया जा सकता है, इसलिए LLVM के प्रभाव के बिना Zig के सुधार सीधे दिखाई देते हैं
• incremental compilation न होने पर भी 1 सेकंड से कम build time हासिल होना एक बड़ा कदम है
• developer workflow में तुरंत feedback experience मिलने से efficiency बढ़ती है
• x86_64 और aarch64 backend लगातार स्थिर हो रहे हैं, और आने वाले कुछ महीनों में इनके Ghostty के पूरे build पर लागू होने की संभावना है

build speed improvement की वर्तमान स्थिति

• Ghostty build में Zig 0.15.1 का उपयोग सभी मापे गए हिस्सों में स्पष्ट रूप से तेज़ साबित हुआ है
• native backend और incremental compilation अभी अधूरे होने के बावजूद, मौजूदा परिणाम अपने आप में काफ़ी प्रभावशाली हैं
• आने वाले 1~2 वर्षों में और भी अधिक क्रांतिकारी speed improvement की उम्मीद की जा रही है
• build speed के नज़रिए से Zig को चुनना एक व्यावहारिक फैसला महसूस होने लगा है

[GN⁺]

Hacker News राय

• 1995 में हाई स्कूल से ग्रेजुएट होते समय Intel 486 पर "Borland Pascal version Turbo Vision for DOS" को फिर से compile करने जितनी तेज़ compile speed अब सच में देखने को मिल रही है
  Turbo Vision एक TUI window framework था, जिसका उपयोग Borland Pascal और C++ IDE development में होता था
  इसे JetBrains IDE का 1000MB की जगह 10MB वाला character mode संस्करण कहा जा सकता है
  Turbo Vision Wikipedia

• LLVM एक तरह का trap है
  bootstrap बहुत तेज़ हो जाता है और तरह-तरह के optimization pass तथा कई platforms का support मुफ़्त में मिल जाता है, लेकिन आख़िरी optimization stage या linking stage की performance को बारीकी से tune करने की क्षमता खो जाती है
  मुझे लगता है कि Cranelift जल्द ही Rust में enable होगा
  लेकिन Rust ने शुरुआत में LLVM चुना, इसलिए आज वह इस मुकाम पर है
  Go ने बहुत पहले ही code generation और linking को बाहर न सौंपकर खुद manage करने का फैसला किया था, और उस फैसले का उसे काफ़ी फ़ायदा मिला है

  • LLVM को trap कहना मानना मुश्किल है, और Rust तो उल्टा एक अच्छा उदाहरण है
    असल में LLVM के साथ code generation compiler का बहुत छोटा हिस्सा होता है, और चाहें तो इसे codegen_cranelift या codegen_gcc से बदला भी जा सकता है
    SIMD vendor intrinsics पर निर्भरता एक तरह की lock-in समस्या ज़रूर है, लेकिन यह language structure की समस्या है
    ज़्यादातर भाषाओं के लिए LLVM backend से शुरुआत करना समझदारी है
    C/C++ जैसी भाषाओं में LLVM default pipeline ही optimization के लिए काफ़ी अच्छी है, लेकिन जिन भाषाओं की विशेषताएँ अलग हैं, वे अपना optimization pipeline खुद लिखती हैं
    Go की तरह शुरुआत से अपना backend integrate करने के उदाहरण सफल दिखते हैं, लेकिन यह कोई खास differentiator नहीं है, और इसे खुद implement करने में काफ़ी opportunity cost लगती है

  • Go और Ocaml compiler वाकई बहुत तेज़ हैं
    उन्होंने शुरू से ही अपनी libraries ठीक से बना लीं, और अब speed के मामले में उन्हें नुकसान नहीं है
    भविष्य में मैं 1 मिनट से ज़्यादा compile time वाले environment में काम नहीं करना चाहूँगा
    अच्छा होता अगर हर project में एक अलग ‘dev’ compiler होता, और केवल final build के लिए llvm जैसी भारी चीज़ इस्तेमाल होती

  • अगर LLVM-आधारित languages का लक्ष्य C++ replacement बनना है, तो वे फिर भी C++ पर निर्भर रह जाती हैं
    language को खुद से bootstrap होना चाहिए
    शुरुआत में सुविधाजनक tools होते हैं, लेकिन वे सिर्फ़ time-saving साधन हैं, अनिवार्य नहीं
    Go team ने जो चुनाव किया, उससे मैं पूरी तरह सहमत हूँ

  • Cranelift लगातार आगे बढ़े, यही उम्मीद है
    आज का LLVM CPU vendor के हिसाब से कई forks में बँटता जा रहा है, और हर fork में CPU-specific improvements बंद packages में बँधी रहती हैं
    अगर कोई दूसरा language frontend इस्तेमाल किया जाए या compiler bug आ जाए, तो स्थिति बहुत कठिन हो जाती है

  • यह सवाल उठाया गया कि जब languages आसानी से दूसरे backends पर जा सकती हैं, तो इसे trap कैसे कहा जा सकता है

• अगर compile speed development में बाधा बनती है, तो interpreter क्यों न बनाया जाए
  execution speed और compile speed का रिश्ता मूलतः स्वतंत्र है
  interpreter इस्तेमाल करने पर code instrumentation या runtime control जैसे अतिरिक्त development tools बनाना भी आसान हो जाता है
  ऐसे बहुत कम cases होते हैं जहाँ optimized RELEASE binary को ही debug करना पड़ता है, ज़्यादातर मामलों में interpreter या DEBUG build काफ़ी होता है

  • मैंने सुना है कि Rust को safety, performance, usability के क्रम में और Zig को performance, usability, safety के क्रम में देखा जाता है
    इस नज़रिए से build speed improvements समझ में आती हैं, लेकिन interpreter usability को प्राथमिकता देने पर ज़्यादा उपयुक्त विकल्प है

  • Julia का approach मुझे पसंद है
    पूरे interactive environment में interpreter वास्तव में code को compile करके तुरंत चला देता है
    SBCL जैसे Common Lisp environments भी ऐसे ही काम करते हैं

  • execution speed और compile speed चरम स्थिति में देखें तो स्वतंत्र हैं
    इन दोनों के बीच एक "समझौते योग्य क्षेत्र" है, जहाँ executable performance घटाए बिना compiler को तेज़ बनाया जा सकता है

  • यह कहा गया कि game domain कोई विशेष मामला नहीं है

• अब तक की सबसे बेहतरीन compiler speed TCC (Fabrice Bellard का काम) की है
  multithreading या जटिल optimization के बिना भी यह बेहद तेज़ है
  release के लिए Clang इस्तेमाल करते हैं, लेकिन TCC की code generation performance भी खराब नहीं है

  • मुझे लगता है कि Delphi इससे कहीं ज़्यादा expressive और safe होते हुए भी बहुत तेज़ compile speed देता है

  • Go compiler भी काफ़ी तेज़ है

  • मैंने DMD को "gold standard" माना था, क्योंकि यह C और D दोनों compile कर सकता है

  • काश TCC C23 को support करे

  • कोई एक चीज़ "असल gold standard" नहीं है
    vlang में भी recompile कुछ ही seconds में हो जाता है, और Go का compiler भी बेहद तेज़ है
    build caching जैसी तकनीकें recompilation को ही टाल देती हैं, इसलिए यह किसी एक का विशेषाधिकार नहीं है

• zig से app build करते समय incremental build को लेकर काफ़ी संतुष्टि मिली
  SQLite, luau जैसी कई libraries इस्तेमाल करने वाली single static binary को Go जितनी तेज़ी से build किया जा सकता है
  हालाँकि self-hosted compiler में अभी भी काफ़ी bugs bचे हैं
  उदाहरण के लिए SQLite के लिए llvm इस्तेमाल करना पड़ता है, और संबंधित issue यहाँ देखा जा सकता है

• यह जानने की जिज्ञासा है कि Zig, Bazel और Buck2 जैसे build systems के साथ कितनी अच्छी तरह काम कर सकता है
  Zig में build scripts Turing-complete हैं, इसलिए चिंता है कि ऐसे systems में caching और build automation आसान न हों
  यह कुछ वैसा ही कारण है कि Rust में build.rs के बिना चलने वाली libraries ज़्यादा पसंद की जाती हैं
  जानना है कि Zig libraries में भी custom build बहुत आम हैं या नहीं

  • Zig की build scripts पूरी तरह optional हैं
    build.zig के बिना भी individual source files को सीधे build/run किया जा सकता है
    जहाँ कहीं भी GCC या Clang वाला workflow हो, वहाँ Zig को जोड़ा जा सकता है
    और जानकारी के लिए, Zig एक C compiler replacement की तरह भी काम कर सकता है
    संबंधित लेख

  • Bazel और Zig integration के उदाहरण के रूप में rules_zig का उल्लेख किया गया
    असल project ZML भी इसका उपयोग करता है
    ZML project

• यह जिज्ञासा है कि Zig का compilation और code generation TPDE के मुकाबले कैसा है
  कहा जाता है कि यह LLVM -O0 से 10~20 गुना तेज़ है, लेकिन इसकी भी कुछ सीमाएँ लगती हैं

• मुझे लगता है Zig की strategy काफ़ी साहसी है
  लेकिन अभी भी यह सवाल है कि LLVM backend का उपयोग जारी रखना सही है या नहीं
  LLVM compile speed और platform support के मामले में प्रतिस्पर्धी है, लेकिन बेहतरीन machine code बनाने में उसका अब भी कोई सानी नहीं है

  • केवल Release build के लिए LLVM backend इस्तेमाल होता है, और debug build में supported platforms पर self-hosted तरीका default है
    debug build को असली testing process में कई बार दोहराकर build किया जाता है, इसलिए यह तरीका ज़्यादा तर्कसंगत है

  • compiler performance को लेकर इस तरह का जुनून समझ नहीं आता
    आख़िरकार यह optimization passes (inlining, dead code elimination आदि) और compile time के बीच का trade-off है
    बिना optimization वाला compiler केवल रैखिक रूप से तेज़ हो सकता है, उससे आगे optimization बढ़ाने पर समय लागत हमेशा बढ़ती है

  • "बेहतरीन assembly output" वास्तव में इतना महत्वपूर्ण मुद्दा नहीं है
    Proebsting's Law के अनुसार compiler technology की प्रगति machine performance growth की तुलना में बहुत धीमी है
    निष्कर्ष यह है कि आसान और तेज़ optimization ही व्यावहारिक रूप से काफ़ी है
    LLVM भी कोई absolute optimization नहीं देता, और compile speed से तुलना करें तो जल्दी ही सीमाओं से टकरा जाता है

• JNI के साथ C libraries को wrap करने वाली Java library बनाते समय, platform-specific dynamic libraries को build करना बहुत झंझटभरा है, इसलिए zig के साथ multi-platform build पर विचार किया जा रहा है

  • अगर यह सिर्फ़ एक simple shim है, तो modern Java में Panama और jextract का उपयोग बेहतर हो सकता है

  • Zig headers, libc source और अपना LLVM सब कुछ साथ में लाता है, और cross-compilation वाकई बहुत आसान है
    सच में लगभग कुछ भी अलग से सोचने की ज़रूरत नहीं पड़ती

• यह जिज्ञासा है कि Ghostty अभी self-hosted x86_64 backend के साथ build क्यों नहीं हो पा रहा

  • Zig compiler bug की वजह से crash हो जाता है
    यह अभी नई technology है, इसलिए जटिलताएँ हैं, लेकिन जल्द ही ठीक हो जाना चाहिए

  • ज़्यादातर Ghostty users aarch64 platform पर हैं