Chrome V8 कैसे काम करता है? और जावास्क्रिप्ट पहले स्थान पर जेआईटी-संकलित क्यों नहीं था?

Question

मैं इंटरप्रिटर्स / कंपाइलर्स पर शोध कर रहा हूं, फिर मैंने JIT-Compilation - विशेष रूप से Google Chrome के V8 जावास्क्रिप्ट इंजन में ठोकर खाई।

मेरे प्रश्न हैं -

1. यह मानक व्याख्या से अधिक तेज़ कैसे हो सकता है ?
2. पहले स्थान पर जेआईटी-संकलन का उपयोग क्यों नहीं किया गया?
   
   

---

मेरी करंट अंडरस्टैंडिंग

1. प्रत्येक जावास्क्रिप्ट प्रोग्राम स्रोत कोड के रूप में शुरू होता है , फिर, निष्पादन की विधि की परवाह किए बिना, अंततः मशीन कोड में अनुवाद किया जाता है । JIT-Compilation और Interpretation
   दोनों को इस रास्ते पर चलना चाहिए, इसलिए JIT-Compilation कैसे तेज़ हो सकता है (AOT-Compilation के विपरीत JIT समय-विवश होने के कारण)?

2. ऐसा लगता है कि जेआईटी-संकलन अपेक्षाकृत पुराना नवाचार है , जो विकिपीडिया के जेआईटी-संकलन लेख से हटकर है ।

"जल्द से जल्द प्रकाशित जेआईटी कंपाइलर को आमतौर पर मैकार्थी द्वारा 1960 में एलआईएसपी पर काम करने के लिए जिम्मेदार ठहराया गया है ।"

"स्मॉलटाक (सी। 1983 ) ने जेआईटी संकलन के नए पहलुओं का बीड़ा उठाया। उदाहरण के लिए, मांग पर मशीन कोड में अनुवाद किया गया था, और बाद में उपयोग के लिए परिणाम को कैश कर दिया गया था। जब स्मृति दुर्लभ हो गई, तो सिस्टम इस कोड को हटा देगा और पुन: उत्पन्न करेगा। जब इसकी दोबारा जरूरत थी। "

तो क्यों जावास्क्रिप्ट के साथ शुरू करने के लिए व्याख्या की गई थी ?

---

मैं बहुत उलझन में हूं, और मैंने इस पर बहुत शोध किया है, लेकिन मुझे संतोषजनक जवाब नहीं मिला है।

इतना स्पष्ट, संक्षिप्त जवाब की सराहना की जाएगी। और अगर इंटरप्रिटेटर, जेआईटी-कंपाइलर आदि के बारे में अतिरिक्त स्पष्टीकरण लाना है, तो इसकी सराहना की जाती है।

Comments

# 2 और # 3 जवाबदेह हैं, लेकिन "Chrome V8 इंजन कैसे काम करता है?" बिना किसी योग्यता के बहुत व्यापक है; एकमात्र सही उत्तर V8 स्रोत कोड का एक लिंक है। क्या आपके पास V8 के बारे में कुछ और विशिष्ट पूछने का मतलब है? (यदि प्रश्न का वह भाग निकालना सबसे अच्छा नहीं होगा)

— Ixrec

दूसरी नज़र में, मुझे # 1 पूछने का एकमात्र बिंदु # 2 को समझना था, इसलिए मैं इसे हटा दूंगा। इनपुट के लिए धन्यवाद।

— एंटोन पारस

अन्य उत्तरों में इसका उल्लेख नहीं है लेकिन JIT संकलन कठिन है। यह एक साधारण बात नहीं है क्योंकि त्रुटियों के बजाय JIT संकलन के परिणामस्वरूप त्रुटियों का परिणाम होता है - कंसोल में एक त्रुटि को फेंकने के बजाय प्रोग्राम क्रैश हो जाता है। हाँ, एक सक्षम सी प्रोग्रामर के लिए gdb के साथ आरामदायक यह कोई समस्या नहीं है। लेकिन लगभग सभी सक्षम सी प्रोग्रामर जीडीबी के साथ सहज होकर अन्य परियोजनाओं पर काम करने के लिए भुगतान करते हैं। पर्ल और रूबी जैसी कुछ अन्य भाषाओं में अभी भी मुख्यधारा के जेआईटी दुभाषिए नहीं हैं।

— स्लीवतमैन

मामले में आप सोच रहे हैं। मैं एक प्रोग्रामिंग भाषा के लिए एक कोर डेवलपर / अनुचर के दृष्टिकोण से इस बारे में बात कर रहा हूं। एक दो साल के लिए मुझे फेराइट प्रोग्रामिंग भाषा को बनाए रखने के लिए काम पर रखा गया था। हमारी इच्छा सूची में से एक JIT को लागू करना था। यह कभी नहीं हुआ - हम इसके बजाय जाने के लिए चले गए। PHP को हाल ही में एक JIT कंपाइलर (HVVM) मिला है, जिसकी बदौलत फेसबुक ने इसे करने के लिए पर्याप्त पैसा डाला है।

— स्लीवतमैन

Answer 1

संक्षिप्त उत्तर यह है कि जेआईटी में अब प्रारंभिक बार है, लेकिन लंबे समय में बहुत तेज है, और जावास्क्रिप्ट मूल रूप से लंबे समय तक चलने का इरादा नहीं था।

90 के दशक में, एक वेब साइट पर विशिष्ट जावास्क्रिप्ट हेडर में एक या दो कार्यों के लिए होता है, और एक मुट्ठी भर कोड सीधे onclickगुणों और इस तरह से एम्बेडेड होता है । यह आम तौर पर तब सही तरीके से चलता है जब उपयोगकर्ता को किसी भी तरह से पेज लोड में देरी की उम्मीद थी। बंधक ब्याज कैलकुलेटर की तरह अत्यंत मूल रूप सत्यापन या छोटे गणित उपयोगिताओं के बारे में सोचें।

आवश्यकतानुसार व्याख्या करना बहुत सरल था और दिन के उपयोग के मामलों के लिए पूरी तरह से पर्याप्त प्रदर्शन प्रदान करता था। यदि आप लंबे समय तक चलने वाले प्रदर्शन के साथ कुछ चाहते थे, तो आप फ्लैश या जावा एपलेट का उपयोग करते थे।

2004 में गूगल मैप्स भारी जावास्क्रिप्ट उपयोग के लिए पहले हत्यारे ऐप्स में से एक था। यह जावास्क्रिप्ट की संभावनाओं के लिए आंखें खोल रहा था, लेकिन इसके प्रदर्शन की समस्याओं पर भी प्रकाश डाला गया। Google ने कुछ समय अपने जावास्क्रिप्ट प्रदर्शन को बेहतर बनाने के लिए ब्राउज़रों को प्रोत्साहित करने में बिताया, फिर अंततः निर्णय लिया कि प्रतियोगिता सबसे अच्छा प्रेरक होगी, और उन्हें ब्राउज़र-मानक तालिका में सर्वश्रेष्ठ सीट भी देगी। परिणामस्वरूप 2008 में क्रोम और V8 जारी किए गए थे। Google मानचित्र पर आने के 11 साल बाद, हमारे पास ऐसे नए डेवलपर हैं जिन्हें याद नहीं है कि जावास्क्रिप्ट को कभी इस तरह के कार्य के लिए अपर्याप्त माना जाता है।

कहते हैं कि आपका कोई फंक्शन है animateDraggedMap। इसकी व्याख्या करने में 500 ms लग सकते हैं, और 700 ms JIT तक इसे संकलित कर सकते हैं। हालाँकि, JIT संकलन के बाद, इसे वास्तव में चलाने के लिए केवल 100 ms लग सकते हैं। यदि यह 90 का दशक है और आप केवल एक बार फिर से पेज लोड कर रहे हैं, तो JIT इसके लायक नहीं है। यदि यह आज है और आप animateDraggedMapसैकड़ों या हजारों बार कॉल कर रहे हैं , तो प्रारंभ में अतिरिक्त 200 एमएस कुछ भी नहीं है, और यह उन दृश्यों के पीछे किया जा सकता है जब उपयोगकर्ता मानचित्र खींचने की कोशिश करता है।

Answer 2

रनटाइम पर क्या हो रहा है, इसकी समझ के साथ, कोड में बदलाव करना संभव है या कोड की व्याख्या जो इसे तेजी से निष्पादित करने की अनुमति देती है या जो समय संकलन समय से पहले जाना जाता है, उससे बेहतर है।

इस पर काफी कुछ कहा जा सकता है - यह महत्वपूर्ण मात्रा में शोध का विषय है। यहाँ मेरा अपना स्पष्टीकरण है कि मैंने अंतर को समझने के लिए दिए गए उत्तर की तुलना में पाल लिखना शुरू किया : पारंपरिक दुभाषिया, जेआईटी संकलक, जेआईटी दुभाषिया और एओटी संकलक

---

काफी बस, जावास्क्रिप्ट को शुरू में संकलित नहीं किया गया था या जेआईटी के लिए देखा गया था क्योंकि यह कभी भी ऐसा कुछ नहीं था जो जटिल या महत्वपूर्ण हो।

जावा स्क्रिप्ट का मूल इरादा एक वेब पेज पर जावा एप्लेट से लिंक करना था। कुछ बटन पर क्लिक करने या किसी फॉर्म फ़ील्ड में एक मान दर्ज करने की क्षमता और फिर जावा एपलेट पद्धति में काम करना जावास्क्रिप्ट कोड से अपॉलेटिंग एपलेट्स विधियों में देखा जा सकता है । यह भी संभव था, जावास्क्रिप्ट के माध्यम से एक एप्लेट से जावास्क्रिप्ट कोड को लागू करने का दूसरा तरीका ।

जावास्क्रिप्ट का मूल उद्देश्य एप्लेट्स और HTML पृष्ठों को जोड़ना था जो उन्हें सम्‍मिलित करते थे। इस तरह के एक छोटे से काम के लिए, किसी को महान प्रदर्शन की आवश्यकता नहीं है (यदि आप प्रदर्शन चाहते थे, तो एपलेट विधि को लागू करें जो कि JIT'ed है)।

नेटस्केप ने अपनी भाषा के रूप में जावास्क्रिप्ट के साथ महत्वपूर्ण काम करना शुरू किया और विकास के लिए इसे बढ़ावा देने के बाद ही ( नेटस्केप एंटरप्राइज सर्वर में सर्वर साइड जावास्क्रिप्ट सहित - जो संयोगवश समय संकलन से आगे हो गया) कि जावास्क्रिप्ट एक गंभीर लक्ष्य के रूप में प्रकाश में आया। । इसके बाद कई साल लग गए ताकि आवश्यक उपकरण के लिए इसे उपयोगी बनाया जा सके।

Comments

नहीं, जावास्क्रिप्ट जावा से संबंधित नहीं है। और जावा एप्लेट JVM बायटेकोड हैं।

— बेसाइल स्टायरनविच

@BasileStarynkevitch जावास्क्रिप्ट को हैमलेट पृष्ठों में जावा एप्लेट के साथ काम करने के लिए डिज़ाइन किया गया था - html डोम और जावा ऑब्जेक्ट में निहित विधियों के बीच गोंद के रूप में कार्य करता है। यह नहीं है और जावा होने का कभी इरादा नहीं था।

जावास्क्रिप्ट को मूल रूप से ECMAScript (या ऐसा कुछ) कहा जाता था और इसका जावा से कोई लेना-देना नहीं था। इसे जावास्क्रिप्ट कैसे कहा जाता है यह दिलचस्पी रखने वालों के लिए अलग शोध का विषय है। इससे आगे से भ्रम की स्थिति पैदा हो गई है।

— जल्‍दी से जल्‍दी से

@quickly_now और अभी भी tc39.github.io/ecma262 है

— caul

हाँ। और किसी अजीब कारण से जब मैंने इशारा किया कि ऊपर से मैंने इसके लिए अपमानित किया है!

— जल्दी_नहीं

Answer 3

JIT जावास्क्रिप्ट के लिए तेज़ हैं, क्योंकि जब आप अपने चर के प्रकार को नहीं जानते हैं तो तेज़ मशीन कोड उत्पन्न करना असंभव है।

जब आपके पास प्रकार की जानकारी नहीं होती है, तो गणनाएं महंगी होती हैं। उदाहरण के लिए,

x + y

यदि आप x और y के बारे में कुछ नहीं जानते हैं तो यह काफी जटिल है। वे पूर्णांक, युगल, स्ट्रिंग्स या यहां तक ​​कि ऐसी वस्तुएं हो सकते हैं जहां इस गणना के दुष्प्रभाव हैं। चूंकि हमारे पास स्थैतिक टाइपिंग नहीं है, इसलिए यह एक महंगी गणना है।

सिर्फ-इन-टाइम संकलन के साथ, हम रनटाइम जानकारी का उपयोग कर सकते हैं और इसे तेजी से कम्प्यूटेशन में बदल सकते हैं। रनटाइम के दौरान, V8 चर के प्रकार का ट्रैक रखता है। यदि उपरोक्त कोड, तार, के साथ कई बार निष्पादित किया जाता है, तो संकलक स्ट्रिंग समंजन के लिए बहुत सरल निर्देशों को निष्पादित कर सकता है। इसलिए जब कंपाइलर पहुंचता है x + y, तो कोड के बहुत सारे भाग चलाने के बजाय, जो कि कई अलग-अलग प्रकार के x और y के लिए शाखाएं हैं, कंपाइलर जल्दी से जांचता है कि क्या हमारे पास फिर से तार हैं, और फिर मशीन कोड की कुछ पंक्तियों को निष्पादित करता है जो विशेष रूप से स्ट्रेटनेट करता है।

उदाहरण के लिए, C ++ कंपाइलर समय से पहले x और y के प्रकारों को जानता है, क्योंकि हमें चर घोषित करना था। तो यह कोड को चलाने से पहले स्ट्रिंग को सुगम बनाने के लिए अनुकूलित मशीन कोड उत्पन्न कर सकता है।

Answer 4

1) यह मानक व्याख्या से अधिक तेज़ कैसे हो सकता है? खैर, एक विचार उदाहरण इस प्रकार होगा; मान लें कि हमारे पास 2 एप्लिकेशन ApplicationCompiled और ApplicationInterpreted हैं। ये दोनों कार्यक्रम बिलकुल एक जैसे काम करते हैं, और समान स्रोत कोड साझा करते हैं। ApplicationCompiled को संकलन में 6 सेकंड लगते हैं।

मान लीजिए कि परिदृश्य A का समय है:

• ApplicationCompiled के लिए: 4 सेकंड
• ApplicationInterpreted के लिए: 12 सेकंड

तो कुल मिलाकर ApplicationCompiled को परिदृश्य A (6 सेकंड संकलन, 4 सेकंड चलने) को चलाने के लिए 10 सेकंड लगते हैं और ApplicationInterpreted को चलाने में कुल 12 सेकंड लगते हैं। मेरे पास आपको दिखाने के लिए कोई विशिष्ट उदाहरण नहीं है, और मुझे यकीन नहीं है कि किन मामलों में उपरोक्त सत्य होगा - यह भी बहुत हद तक निर्भर करता है कि व्याख्या और संकलक कितने बुद्धिमान हैं।

जाहिर है कि यह बहुत सरल है, लेकिन एक ही विचार को जेआईटी संकलन / व्याख्या करने के लिए लागू किया जा सकता है। अगला प्रश्न तब होगा "हम कैसे निर्धारित करते हैं - कम लागत के साथ - यदि यह शाखा जेआईटी संकलित या व्याख्या की जानी चाहिए"? मैं यहाँ अपनी लीग से बाहर हूँ :)

2) जेआईटी-संकलन का उपयोग पहले स्थान पर क्यों नहीं किया गया? पता नहीं है, लेकिन मैं इसे पुन: व्यवस्थित करता हूं, यह संसाधनों की बात है और जावास्क्रिप्ट जैसे हार्ड-टू-ऑप्टिमाइज़ भाषा बनाने में उपलब्ध प्रगति की परिपक्वता इन जैसी अग्रिम तकनीकों को लागू करती है। उस समय शायद बहुत कम लटके हुए फल थे।