JIT कंपाइलर डायनामिक भाषाओं को तेज़ कैसे बनाते हैं

Ruby की छवि धीमी भाषा की है। Python की भी है। JavaScript की भी थी — कम से कम तब तक, जब तक V8 ने उसे सर्वर-साइड वर्कलोड चलाने लायक तेज़ नहीं बना दिया। डायनामिक भाषाएँ तेज़ कैसे होती हैं, यह कहानी असल में JIT (Just-In-Time) कंपाइलेशन की कहानी है, और यह व्यावहारिक कंप्यूटर साइंस के सबसे दिलचस्प क्षेत्रों में से एक है। ताज़ा अध्याय: Ruby का ZJIT इंटरमीडिएट रिप्रेज़ेंटेशन स्तर पर बेवजह के ऑब्जेक्ट लोड और स्टोर हटा रहा है — उसी किस्म का ऑप्टिमाइज़ेशन जिसने V8 के TurboFan को इतना असरदार बनाया था।

अगर आपने कभी सोचा है कि आपका Ruby कोड C की रफ़्तार का एक हिस्सा ही क्यों चलता है, या JavaScript इतना तेज़ कैसे हो गया कि VS Code जैसा ऐप चला सके, तो जवाब इसमें छिपा है कि JIT कंपाइलर असल में करते क्या हैं — और डायनामिक भाषाओं को ऑप्टिमाइज़ करना स्टैटिक भाषाओं से मूल रूप से कठिन क्यों है।

डायनामिक भाषाओं की मूल समस्या

जब C कंपाइलर a + b देखता है, तो उसे compile time पर पता होता है कि a और b के टाइप क्या हैं। अगर दोनों integers हैं, तो वह एक ही ADD इंस्ट्रक्शन निकालता है। अगर floats हैं, तो floating-point add। CPU उस इंस्ट्रक्शन को एक cycle में चला देता है। कोई अस्पष्टता नहीं, रनटाइम पर कोई फैसला लेने की ज़रूरत नहीं।

जब Ruby इंटरप्रेटर a + b देखता है, तो उसे लगभग कुछ नहीं पता होता। a integer, float, string, array, या कोई भी ऑब्जेक्ट हो सकता है जो + मेथड परिभाषित करता हो। इंटरप्रेटर को यह करना पड़ता है: a का टाइप जाँचना, उस टाइप के लिए + मेथड ढूँढना, b का टाइप जाँचना, ज़रूरत हो तो टाइप कन्वर्ज़न करना, एज केस संभालना (overflow, frozen ऑब्जेक्ट), और आखिर में ऑपरेशन करना। उस एक + में दर्जनों इंस्ट्रक्शन, मेमोरी लुकअप और branch फैसले शामिल हो सकते हैं।

# What the programmer writes:
def sum(a, b)
a + b
end
# What the interpreter actually has to do (pseudocode):
def sum(a, b)
method = lookup_method(a.class, :+)      # Hash lookup
raise NoMethodError unless method         # Branch
if a.is_a?(Integer) && b.is_a?(Integer)   # Type checks
result = integer_add(a.value, b.value)  # Actual math
if overflow?(result)                     # Overflow check
result = promote_to_bignum(result)    # Bignum promotion
end
elsif a.is_a?(Float) || b.is_a?(Float)
result = float_add(to_float(a), to_float(b))
elsif a.is_a?(String)
result = string_concat(a, b.to_s)
else
result = call_method(method, a, [b])    # Generic dispatch
end
result
end

यह ओवरहेड — टाइप चेकिंग, मेथड लुकअप, डिस्पैच — डायनामिज़्म की कीमत है। a + b लिखकर उसे integers, floats, strings और कस्टम ऑब्जेक्ट्स के लिए काम करवाने की लचीलापन रनटाइम पर महँगा पड़ता है।

JIT कंपाइलेशन कैसे पलटवार करता है

JIT कंपाइलर का काम यह है कि वह देखे प्रोग्राम रनटाइम पर असल में क्या करता है, और उन्हीं observations के आधार पर optimized machine code बनाए। मुख्य बात यह है: Ruby कोड किसी भी टाइप पर काम कर सकता है, लेकिन व्यवहार में किसी भी call site पर लगभग हमेशा एक ही टाइप आते हैं।

अगर sum(a, b) को 10,000 बार बुलाया गया है और a तथा b हमेशा integers रहे हैं, तो JIT ऐसा specialized machine code बना सकता है जो मान लेता है कि वे आगे भी integers ही रहेंगे। वह एक 'guard' के साथ single integer add इंस्ट्रक्शन निकालता है — एक तेज़ टाइप चेक जो अगर यह धारणा कभी टूटे तो slow path पर लौट जाता है।

Interpreter execution of sum(a, b) where a and b are Integers:
1. Load a from stack
2. Check if a is an object reference
3. Load a's class pointer
4. Look up :+ in method table (hash lookup)
5. Check method visibility
6. Load b from stack
7. Check if b is an object reference
8. Check if b is compatible type
9. Unbox a's integer value
10. Unbox b's integer value
11. Perform addition
12. Check for overflow
13. Box result as new Integer object
14. Return result
JIT-compiled version (after profiling shows a,b are always Integers):
1. Guard: check a is Integer (bail if not)
2. Guard: check b is Integer (bail if not)
3. ADD instruction
4. Guard: check no overflow (bail if overflow)
5. Return result

यह 14 स्टेप की प्रक्रिया को 5 स्टेप में बदलना है, जहाँ स्टेप 1-2 और 4 एक-एक comparison इंस्ट्रक्शन हैं। असली गणना — ADD — CPU का एक cycle है। JavaScript इसी तरह 'किसी गंभीर काम के लिए भी बहुत धीमा' से 'पूरा IDE चलाने लायक तेज़' तक पहुँचा।

Ruby की JIT यात्रा: MJIT से YJIT और ZJIT तक

Ruby का JIT कंपाइलेशन का इतिहास बताता है कि यह समस्या कितनी कठिन है। Ruby ने कई JIT इम्प्लीमेंटेशन देखे हैं, और हर एक ने अलग तरीका अपनाया।

MJIT (Ruby 2.6, 2018) ने Ruby bytecode को C कोड में बदलकर GCC या Clang से compile करवाने का तरीका अपनाया। इससे अच्छी तरह ऑप्टिमाइज़ किया हुआ कोड मिला, लेकिन warm-up टाइम बहुत खराब था — C compile करने में सेकंड लगते हैं, मिलीसेकंड नहीं। जब तक JIT-compiled कोड तैयार होता, प्रोग्राम शायद पहले ही खत्म हो चुका होता।

YJIT (Ruby 3.1, 2022) Shopify का योगदान था, जो पहले C में लिखा गया और बाद में Rust में दोबारा लिखा गया। YJIT 'lazy basic block versioning' नाम की तकनीक इस्तेमाल करता है — यह कोड को एक-एक basic block करके compile करता है, और केवल तब जब वह कोड सच में चलता है, और देखे गए टाइप के आधार पर specialized versions बनाता है। इससे तेज़ warm-up (मिलीसेकंड, सेकंड नहीं) और अच्छी peak performance मिलती है। YJIT आम तौर पर Rails जैसे असली workloads पर Ruby की performance को 15-30% बेहतर करता है।

ZJIT अगला विकास है, और यहीं चीज़ें सच में दिलचस्प होती हैं। ZJIT एक इंटरमीडिएट रिप्रेज़ेंटेशन (IR) पेश करता है — bytecode और machine code के बीच प्रोग्राम का एक संरचित रूप। यह IR उन classical compiler optimizations को संभव बनाता है जिन्हें YJIT का सीधा bytecode-से-machine-code तरीका आसानी से नहीं कर पाता था।

बेवजह के loads और stores हटाना

ZJIT ने हाल ही में जो खास ऑप्टिमाइज़ेशन लागू किया — बेवजह के ऑब्जेक्ट loads और stores हटाना — सुनने में जटिल लगता है, लेकिन इसका असर बहुत बड़ा है। ऐसा क्यों, वह यहाँ है।

Ruby ऑब्जेक्ट्स अपने instance variables एक property table में रखते हैं। जब भी आप @name पढ़ते हैं, इंटरप्रेटर ऑब्जेक्ट की property table से मेमोरी में से value लोड करता है। जब भी आप @name = value लिखते हैं, वह उसी table में store करता है। किसी मेथड में अगर एक ही instance variable कई बार एक्सेस होता है, तो इंटरप्रेटर हर बार उसे मेमोरी से लोड करता है — क्योंकि सामान्य स्थिति में हो सकता है कि दो reads के बीच कुछ और उसकी value बदल चुका हो।

class Rectangle
def area
@width * @height
end
def perimeter
# @width and @height are each loaded TWICE from memory
2 * (@width + @height)
end
def scale(factor)
@width = @width * factor    # Load @width, multiply, store @width
@height = @height * factor  # Load @height, multiply, store @height
self
end
end
# In a tight loop, these redundant loads add up:
rects.each { |r| r.scale(2).perimeter }

IR की मदद से ZJIT load elimination कर सकता है: अगर @width पहले ही लोड हो चुका है और उसके बाद उसे किसी ने नहीं बदला, तो मेमोरी से दोबारा लोड करने के बजाय रजिस्टर की value दोबारा इस्तेमाल हो सकती है। यह store elimination भी कर सकता है: अगर आप @width में दो बार लगातार लिखते हैं और बीच में कोई उसे पढ़ता नहीं, तो पहला store हटाया जा सकता है।

ये ऑप्टिमाइज़ेशन स्टैटिक भाषाओं के कंपाइलर में बुनियादी माने जाते हैं — GCC और LLVM इन्हें दशकों से करते आ रहे हैं। लेकिन डायनामिक भाषा के लिए यह कहीं ज़्यादा कठिन है, aliasing की वजह से। Ruby में कोई भी मेथड कॉल किसी भी ऑब्जेक्ट के instance variables बदल सकता है (instance_variable_set, method_missing, या trace hooks के ज़रिए)। JIT को यह साबित करना होता है कि @width के दो reads के बीच उसे कुछ नहीं बदल सकता — और इसके लिए हर बीच के ऑपरेशन का असर जाँचना पड़ता है।

IR का फायदा

ZJIT ने IR क्यों अपनाया (और V8 का TurboFan, JavaScriptCore के DFG/FTL, और HotSpot का C2 भी IR क्यों इस्तेमाल करते हैं), इसका कारण यह है कि इससे ये ऑप्टिमाइज़ेशन composable बन जाते हैं। IR असल में ऑपरेशनों का एक graph है, जिस पर optimizations graph transformations की तरह लागू हो सकते हैं।

• Constant folding: अगर किसी जोड़ के दोनों operands ज्ञात constants हैं, तो ऑपरेशन को उसके नतीजे से बदल दो। 2 + 3 compile time पर 5 बन जाता है।
• Dead code elimination: अगर किसी ऑपरेशन का नतीजा कभी इस्तेमाल नहीं होता, तो उसे पूरी तरह हटा दो।
• Common subexpression elimination: अगर वही गणना दो बार आती है, तो उसे एक बार करो और नतीजा दोबारा इस्तेमाल करो।
• Load/store elimination: ऊपर बताए अनुसार बेवजह की memory operations हटा दो।
• Escape analysis: अगर कोई ऑब्जेक्ट बनता है और मौजूदा मेथड से बाहर नहीं जाता, तो उसे heap के बजाय stack पर allocate करो (या allocation ही पूरी तरह हटा दो)।
• Inlining: किसी मेथड कॉल को उसके body से बदल दो, ताकि बाकी optimizations के लिए और मौके मिलें।

ये optimizations एक-दूसरे को बढ़ाते हैं। किसी मेथड को inline करने से उसके ऑपरेशन caller के संदर्भ में दिखने लगते हैं, जिससे constant values पता चल सकती हैं, जिससे constant folding संभव होता है, जिससे कुछ कोड dead हो जाता है और हट जाता है। एक inlining फैसला दर्जनों ऑपरेशन हटाने तक की श्रृंखला शुरू कर सकता है।

Deoptimization का सुरक्षा जाल

JIT कंपाइलर जो कुछ भी करता है, वह speculative होता है। वह मान लेता है कि टाइप नहीं बदलेंगे, मेथड दोबारा परिभाषित नहीं होंगे, और monkey-patching उसके optimized कोड को अमान्य नहीं करेगी। जब ये धारणाएँ टूटती हैं, तो JIT को 'deoptimize' करना पड़ता है — optimized कोड हटाकर इंटरप्रेटर पर वापस लौटना।

Deoptimization JIT डिज़ाइन का सबसे कठिन हिस्सा है। Optimized कोड ने local variables हटा दिए हों, ऑपरेशनों का क्रम बदल दिया हो, या गहराई से नेस्टेड कॉल inline कर दिए हों। इंटरप्रेटर पर वापस लौटने के लिए JIT को इंटरप्रेटर की स्थिति — सारे local variables, call stack, program counter — उस जानकारी से दोबारा बनानी होती है जो optimized कोड के पास उपलब्ध है। इसके लिए ऐसा metadata रखना पड़ता है ('on-stack replacement' या OSR maps कहलाता है) जो optimized कोड की स्थितियों को इंटरप्रेटर की स्थितियों से जोड़ता है।

जब deoptimization बार-बार होता है — जिसे 'deopt thrashing' कहते हैं — तो performance शुद्ध interpretation से भी खराब हो सकती है। JIT optimized कोड compile करने में समय लगाता है, उसे थोड़ी देर चलाता है, deoptimize करता है, और फिर दोहराता है। V8 deoptimization की गिनती रखकर किसी फंक्शन को optimize करने का प्रयास आखिर में छोड़ देता है। YJIT एक सरल तरीका अपनाता है: वह अलग-अलग टाइप संयोजनों के लिए हर code path के कई versions बनाता है, जिससे deoptimization की ज़रूरत घटती है, पर बदले में ज़्यादा कोड बनता है।

Ruby से आगे इसका महत्व

Ruby की JIT यात्रा वही दिखाती है जो पूरी डायनामिक भाषाओं की दुनिया में हो रहा है। CPython 3.13 में आया Python का copy-and-patch JIT Python के लिए सही JIT कंपाइलेशन की ओर पहला कदम है। LuaJIT कई सालों से आक्रामक tracing JIT के ज़रिए बेहद तेज़ रहा है। PHP 8.0+ का JIT अपने IR-आधारित optimizations के लिए LLVM इस्तेमाल करता है।

पैटर्न एक जैसा है: interpreter से शुरू करो, रनटाइम व्यवहार समझने के लिए profiling जोड़ो, hot paths को type specialization के साथ compile करो, classical optimizations के लिए IR लाओ, और फिर सुधारते रहो। हर भाषा एक ही चुनौतियों का सामना करती है — dynamic dispatch, mutable objects, eval, monkey-patching — और लगभग एक जैसे समाधान पर पहुँचती है।

इन भाषाओं का उपयोग करने वाले डेवलपर्स के लिए व्यावहारिक निष्कर्ष यह है कि डायनामिक और स्टैटिक भाषाओं के बीच performance का फासला सिकुड़ रहा है। यह पूरी तरह कभी खत्म नहीं होगा — type checks और guards की कीमत लगती है, और deoptimization एक अंतर्निहित ओवरहेड है। लेकिन अच्छी तरह ऑप्टिमाइज़ किया हुआ JIT computational workloads पर समकक्ष C कोड के 2-5 गुना के भीतर पहुँच सकता है, जो ज़्यादातर अनुप्रयोगों के लिए 'काफी तेज़' है।

एक सूक्ष्म निष्कर्ष: सीधा-सादा कोड लिखें। JIT कंपाइलर अनुमानित पैटर्न को अच्छी तरह ऑप्टिमाइज़ करते हैं। Monomorphic call sites (जहाँ मेथड को हमेशा एक ही टाइप मिलता है) अच्छी तरह ऑप्टिमाइज़ होते हैं। Polymorphic call sites (जहाँ टाइप बदलते हैं) कठिन होते हैं। Megamorphic call sites (दर्जनों टाइप) शायद कभी ऑप्टिमाइज़ ही न हों। जो कोड इंसान के लिए समझने में सरल है, वह आम तौर पर JIT के लिए भी ऑप्टिमाइज़ करने में सरल होता है — यह प्रोत्साहनों का एक अच्छा मेल है।