🍂 🤵🏽 👉🏾 जेएस को एलब्रस में पोर्ट करना 💆🏾 🏇 👩🏾‍🤝‍👨🏼

यह जावास्क्रिप्ट को घरेलू एल्ब्रस प्लेटफॉर्म पर पोर्ट करने की कहानी है, जो यूआईप्रो के लोगों द्वारा बनाया गया है। लेख प्लेटफार्मों, प्रक्रिया विवरण और नुकसान की एक संक्षिप्त तुलनात्मक विश्लेषण प्रदान करता है।

लेख दिमित्री ( dbezheckov ) बेज़ेत्कोव और व्लादिमीर ( वलोडियाबो ) Anufrienko द्वारा पवित्र जेएस 2018 पाइटर की एक रिपोर्ट पर आधारित है। कट के तहत आपको रिपोर्ट का वीडियो और टेक्स्ट ट्रांसक्रिप्ट मिलेगा।

भाग 1. एल्ब्रस, मूल रूप से रूस से

सबसे पहले, हम समझेंगे कि एल्ब्रस क्या है। यहाँ x86 की तुलना में इस मंच की कुछ प्रमुख विशेषताएं हैं।

वीएलआईडब्ल्यू वास्तुकला

सुपरस्केलर आर्किटेक्चर की तुलना में एक पूरी तरह से अलग वास्तुशिल्प समाधान, जो अब बाजार पर अधिक सामान्य है। वीएलआईडब्ल्यू आपको सभी स्वतंत्र अंकगणितीय-तर्क उपकरणों (ALUs) के स्पष्ट नियंत्रण के कारण कोड में अधिक सूक्ष्म रूप से व्यक्त इरादे की अनुमति देता है, जो कि एल्ब्रस के पास है, 4. यह कुछ ALU के डाउनटाइम की संभावना को बाहर नहीं करता है, लेकिन फिर भी एक घड़ी चक्र द्वारा सैद्धांतिक प्रदर्शन को बढ़ाता है। प्रोसेसर।

टीम बंडलिंग

तैयार प्रोसेसर कमांड बंडल (बंडल) में संयुक्त होते हैं। एक बंडल एक बड़ा निर्देश है जो प्रति सशर्त घड़ी निष्पादित करता है। इसके कई परमाणु निर्देश हैं जिन्हें स्वतंत्र रूप से और तुरंत एलब्रस वास्तुकला में निष्पादित किया जाता है।

दाईं ओर की छवि में, ग्रे आयताकार बाईं ओर जेएस कोड को संसाधित करके प्राप्त बंडलों को इंगित करता है। यदि निर्देश ldd, fmuld, faddd, fsqrts के साथ सब कुछ लगभग स्पष्ट है, तो पहले बंडल की शुरुआत में रिटर्न स्टेटमेंट उन लोगों के लिए आश्चर्यचकित करता है जो एल्ब्रस असेंबलर से परिचित नहीं हैं। यह निर्देश वर्तमान फ्लोटमैथ फ़ंक्शन से रिटर्न एड्रेस को ctpr3 रजिस्टर में पहले से लोड करता है, ताकि प्रोसेसर आवश्यक निर्देशों को डाउनलोड करने का प्रबंधन कर सके। फिर, अंतिम बंडल में, हम पहले से ही ctpr3 में प्रीलोड किए गए पते पर संक्रमण करते हैं।

यह भी ध्यान देने योग्य है कि एल्ब्रस में x86 के लिए 192 + 32 + 32 बनाम 16 + 16 +8 के बहुत अधिक रजिस्टर हैं।

स्पष्ट सट्टा बनाम निहित

एल्ब्रस कमांड स्तर पर स्पष्ट विशिष्टता का समर्थन करता है। इसलिए, हम जाँच कर सकते हैं और a.bar को मेमोरी से लोड कर सकते हैं, यह जाँचने से पहले कि यह अशक्त नहीं है, जैसा कि दाईं ओर कोड में देखा गया है। यदि अंत में तार्किक रूप से पढ़ना अमान्य हो जाता है, तो b में मान केवल हार्डवेयर को गलत के रूप में चिह्नित किया जाएगा और इसे एक्सेस करना संभव नहीं होगा।

सशर्त निष्पादन सहायता

एल्ब्रस भी सशर्त निष्पादन का समर्थन करता है। निम्नलिखित उदाहरण में इस पर विचार करें।

जैसा कि हम देख सकते हैं, सशर्त अभिव्यक्ति के दृढ़ विश्वास के उपयोग पर निर्भरता के बारे में पिछले उदाहरण से कोड भी निर्भर करता है, नियंत्रण से नहीं, बल्कि डेटा से। एल्ब्रस हार्डवेयर विधेय रजिस्टरों का समर्थन करता है, जिसमें आप केवल दो सही या गलत मूल्यों को संग्रहीत कर सकते हैं। उनकी मुख्य विशेषता यह है कि आप ऐसे विधेय के साथ निर्देशों को चिह्नित कर सकते हैं और निष्पादन के समय इसके मूल्य के आधार पर, निर्देश निष्पादित किया जाएगा या नहीं। इस उदाहरण में, cmpeq निर्देश तुलना करता है और अपने तार्किक परिणाम को P1 में डालता है, जो तब परिणाम में b से मान को लोड करने के लिए एक मार्कर के रूप में उपयोग किया जाता है। तदनुसार, यदि विधेय सत्य के बराबर था, तो परिणाम में मान 0 बना रहा।

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

इंटेल में एक की तुलना में तीन हार्डवेयर स्टैक

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

कोई डायनेमिक ब्रांच प्रेडिक्टर नहीं

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

तो हमें एलब्रस पर जेएस की आवश्यकता क्यों है?

आयात प्रतिस्थापन।
एलब्रस का घरेलू कंप्यूटर बाजार में परिचय, जहां एक ही ब्राउज़र के लिए जावास्क्रिप्ट पहले से ही आवश्यक है।
Elbrus उद्योग में पहले से ही आवश्यक है, उदाहरण के लिए Node.js. इसलिए, आपको इस आर्किटेक्चर में नोड को पोर्ट करने की आवश्यकता है।
एल्ब्रस की वास्तुकला का विकास, साथ ही साथ इस क्षेत्र में विशेषज्ञ।

यदि कोई दुभाषिया नहीं है, तो दो संकलक आते हैं

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

FullCodegen कैसे काम करता है?

वाक्य रचना के पेड़ के नोड्स को बाइनरी कोड में अनुवादित किया जाता है, जिसके बाद सब कुछ एक साथ "सरेस से जोड़ा हुआ" होता है। एक नोड मैक्रो असेंबलर में कोड की लगभग 300 लाइनें हैं। यह, सबसे पहले, अनुकूलन का एक विस्तृत क्षितिज देता है, और दूसरी बात, दुभाषिया में कोई बायोटेक संक्रमण नहीं हैं। यह सरल है, लेकिन एक ही समय में एक समस्या है - पोर्टिंग के दौरान आपको मैक्रो असेंबलर में बहुत सारे कोड को फिर से लिखना होगा।

फिर भी, यह सब किया गया था, और परिणाम एल्ब्रस के लिए एक फुलकोडेन 1.0 संकलक संस्करण था। सब कुछ C ++ रनटाइम v8 के माध्यम से किया गया था, उन्होंने कुछ भी अनुकूलित नहीं किया था, कोडांतरक कोड केवल x86 से एल्ब्रस वास्तुकला में फिर से लिखा गया था।

कोडजेन १.१

परिणामस्वरूप, परिणाम अपेक्षा के अनुरूप नहीं था, और फुलकोडेन 1.1 जारी करने का निर्णय लिया गया था:

कम रनटाइम बनाया, एक मैक्रो असेंबलर पर लिखा;
जोड़ा गया मैनुअल अगर रूपांतरण (चित्र में, उदाहरण के लिए, जेएस चर को सही या गलत के लिए जांचा जाता है);

ध्यान दें कि NaN, अपरिभाषित, अशक्त के लिए जाँच एक समय में की जाती है, यदि इसका उपयोग किए बिना, जो कि Intel आर्किटेक्चर में आवश्यक होगा।

कोड को केवल इंटेल के साथ फिर से नहीं लिखा गया था, लेकिन स्टब्स में स्पेकुलैसिटी लागू की और MAsm (मैक्रो असेंबलर) के माध्यम से फास्ट-पाथ भी लागू किया।

Google ऑक्टेन में टेस्ट आयोजित किए गए थे। टेस्ट मशीन:

एल्ब्रस: ई 2 एस 750 मेगाहर्ट्ज, 24 जीबी
इंटेल: कोर i7 3.4 गीगाहर्ट्ज, 16 जीबी

आगे के परिणाम:

हिस्टोग्राम पर परिणामों का अनुपात है, अर्थात्। कितनी बार Elbrus इंटेल से भी बदतर है। दो परीक्षणों, क्रिप्टो और ज़्लिब पर, परिणाम इस तथ्य के कारण काफी खराब हैं कि एलब्रस के पास एन्क्रिप्शन के साथ काम करने के लिए अभी तक हार्डवेयर निर्देश नहीं हैं। सामान्य तौर पर, आवृत्तियों में अंतर को देखते हुए, यह बहुत अच्छी तरह से निकला।

निम्नलिखित फ़ायरफ़ॉक्स से जेएस दुभाषिया की तुलना में एक परीक्षण है, जो मानक एल्ब्रस वितरण का हिस्सा है। ज्यादा बेहतर है।

फैसला - कंपाइलर ने फिर से अच्छा काम किया।

विकास के परिणाम

नए JS इंजन ने test262 टेस्ट पास किए। यह इसे पूर्ण-क्रमिक रनटाइम वातावरण ECMAScript 262 कहलाने का अधिकार देता है।
पिछले इंजन की तुलना में उत्पादकता में औसतन पांच गुना वृद्धि हुई है - दुभाषिया।
Node.js 6.10 को V8 के उपयोग के उदाहरण के रूप में भी चित्रित किया गया था, क्योंकि यह मुश्किल नहीं था।
हालांकि, यह अभी भी सात बार द्वारा FullCodegen पर कोर i7 से भी बदतर है।

कुछ भी नहीं दिख रहा था

सबकुछ ठीक हो जाएगा, लेकिन यहां Google ने घोषणा की कि यह अब FullCodegen और Crankshaft का समर्थन नहीं करता है और उन्हें हटा दिया जाएगा। जिसके बाद टीम को फ़ायरफ़ॉक्स ब्राउज़र के लिए एक विकास आदेश मिला, और बाद में और भी बहुत कुछ।

भाग 2. फ़ायरफ़ॉक्स और इसके मकड़ी बंदर

यह फ़ायरफ़ॉक्स ब्राउज़र इंजन के बारे में है - स्पाइडरमॉन्की। आकृति में, इस इंजन और नए V8 के बीच अंतर।

यह देखा जा सकता है कि पहले चरण में सब कुछ ऐसा लगता है जैसे स्रोत कोड को सार सिंटैक्स ट्री में पार्स किया जाता है, फिर बाइट कोड में, और फिर मतभेद शुरू होते हैं।

स्पाइडरमोंकी में, बाईटेकोड की व्याख्या C ++ दुभाषिया द्वारा की जाती है, जो संक्षेप में एक बड़े स्विच से मिलता-जुलता है, जिसके अंदर बायटेकोड कूदता है। इसके अलावा, व्याख्या किए गए कोड को नियोटिमाइजिंग कंपाइलर बेसलाइन में मिलता है। फिर, अंतिम चरण में, अनुकूलन संकलक आयन मामले में शामिल है। वी 8 इंजन में, बाईटेकोड को इन्ग्निशन इंटरप्रेटर द्वारा संसाधित किया जाता है, और फिर टर्बोफैन कंपाइलर द्वारा।

आधारभूत, मैं आपको चुनता हूं!

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

एक फ्रेम क्या है?

ऊपर की छवियों में आप शब्द फ़्रेम देख सकते हैं। मोटे तौर पर, यह हार्डवेयर पर एक जावास्क्रिप्ट संदर्भ है, अर्थात, ढेर पर एक डेटासेट जो आपके किसी भी कार्य का वर्णन करता है। नीचे दी गई छवि में, फ़ंक्शन foo है, और इसके दाईं ओर वही है जो स्टैक पर दिखता है: तर्क, फ़ंक्शन का विवरण, रिटर्न पता, पिछले फ्रेम का संकेत, क्योंकि फ़ंक्शन को कहीं से बुलाया गया था और कॉल के स्थान पर सही ढंग से वापस आने के लिए इस जानकारी को संग्रहीत किया जाना चाहिए। स्टैक, और फिर स्थानीय चर गणना के लिए स्वयं कार्य और संचालन करते हैं।

इस प्रकार, बेसलाइन के लाभ :

फुलकोडेन जैसा दिखता है, इसलिए उसका पोर्टिंग अनुभव काम आया;
कोडांतरक पोर्ट, एक काम कर रहे संकलक मिल;
यह डिबग करने के लिए सुविधाजनक है;
किसी भी ठूंठ को फिर से लिखा जा सकता है।

लेकिन इसके नुकसान भी हैं:

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

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

परिणामस्वरूप, नए संकलक के साथ परीक्षणों में उत्पादकता तीन गुना हो गई है:

हालांकि, ओकटाइन अपवादों का समर्थन नहीं करते हैं। और उनका कार्यान्वयन बहुत महत्वपूर्ण है।

असाधारण काम

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

समस्या यह है कि एल्ब्रस वास्तुकला पर एक और स्टैक डिवाइस के कारण यह काम नहीं करेगा। सिस्टम कॉल द्वारा गणना करना आवश्यक होगा कि आपको चेन स्टैक में रिवाइंड करने की कितनी आवश्यकता है। अगला, हम कॉल स्टैक प्राप्त करने के लिए एक सिस्टम कॉल करते हैं। अगला, चेन स्टैक में पते में, हम रिटर्न बनाने वाले पते के लिए एक प्रतिस्थापन करते हैं।

नीचे इन चरणों के अनुक्रम का एक चित्रण है।

सबसे तेज़ तरीका नहीं है, हालांकि, अपवाद को नियंत्रित किया जाता है। लेकिन फिर भी, इंटेल पर यह थोड़ा सरल दिखता है:

एल्ब्रस के साथ, हैंडलर के लिए अधिक छलांग होगी:

इसलिए आपको अपवादों पर कार्यक्रम के तर्क को आधार नहीं बनाना चाहिए, खासकर एल्ब्रस पर।

इसे ऑप्टिमाइज़ करें!

तो, अपवाद हैंडलिंग लागू किया गया है। अब हम आपको बताएंगे कि कैसे हमने इसे थोड़ा तेज किया:

इनलाइन कैश को फिर से लिखना;

विलंब की एक मैनुअल (और फिर स्वचालित) व्यवस्था की गई;
उन्होंने संक्रमण के लिए तैयारी की (कोड में अधिक): पहले संक्रमण तैयार किया गया है, बेहतर;
बढ़े हुए कूड़ा बीनने वाले का समर्थन किया

दूसरा पैराग्राफ थोड़ा और विस्तार में स्थित होगा। हमने पहले से ही बंडलों के साथ काम करने के एक छोटे से उदाहरण की जांच की है, और हम इस पर आगे बढ़ेंगे।

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

बेसलाइन v1.0 बनाम बेसलाइन v1.1 अनुकूलन के परिणाम। यकीन है, इंजन तेज हो गया है।

प्रोग्रामर एक आयन बंदूक कैसे नहीं बना सकते हैं?

बेसलाइन v1.1 के कार्यान्वयन से सफलता की लहर पर, यह अनुकूलन संकलक आयन को पोर्ट करने का निर्णय लिया गया था।

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

एल्ब्रस पर अधिक रजिस्टर हैं और टीमें स्वयं बड़ी हैं, इसलिए हमें इसकी आवश्यकता है:

टीम प्लानर
स्वयं रजिस्टर आवंटनकर्ता;
खुद का एलआईआर (निम्न-स्तरीय मध्यवर्ती प्रतिनिधि);
खुद का कोड-जनरेटर।

टीम को पहले से ही जावा को एलब्रस में पोर्ट करने का अनुभव था, उन्होंने आयन को पोर्ट करने के लिए कोड पीढ़ी के लिए एक ही पुस्तकालय का उपयोग करने का फैसला किया। उसे टैंगो कहा जाता है। यह है:

टीम प्लानर
स्वयं रजिस्टर आवंटनकर्ता;
निम्न स्तर के अनुकूलन।

यह चयनकर्ता बनाने के लिए टैंगो में एक उच्च-स्तरीय प्रतिनिधित्व पेश करने के लिए बना हुआ है। समस्या यह है कि टैंगो में निम्न-स्तरीय दृश्य कोडांतरक की तरह है, जिसे बनाए रखना और डिबग करना मुश्किल है। संकलक को अंदर की तरह क्या देखना चाहिए? बेहतर समझ के लिए, मोज़िला ने अपना स्वयं का पवित्र संकलक बनाया, एक उच्च-स्तरीय और निम्न-स्तरीय प्रतिनिधित्व के बीच अनुवाद के लिए अपनी खुद की मिनी-भाषा लिखने का विकल्प भी है।

विकास अभी भी चल रहा है। अच्छी तरह से और आगे कैसे अनुकूलन के साथ इसे ज़्यादा नहीं करना है।

भाग 3. अच्छे का दुश्मन सबसे अच्छा होता है

जैसा है वैसा ही संकलन

आयन में अनुकूलन प्रक्रिया, जब कोड गर्म होता है और फिर संकलन और अनुकूलन होता है, लालची होता है, इसे निम्नलिखित उदाहरण में देखा जा सकता है।

function foo(a, b) {
  return a + b;
}

function doSomeStuff(obj) {
  for (let i = 0; i < 1100; ++i) {
    print(foo(obj,obj));
  }
}

doSomeStuff("HollyJS");
doSomeStuff({n:10});

JS Shell ( ), Mozilla, :

. , , - bailout (). , . foo object, , , . , :

function doSomeStuff(obj) {
  for (let i=0; i < 1100; ++i) {
    if (!(obj instanceof String))
      // bailout
    print(foo_only_str(obj, obj));
  }
}

, .

. , , DCE.

, , , .

, , , SpiderMonkey Resume Point. - , . , baseline . , runtime , . lowering, regAlloc, (snapshot), , . baseline .

:

runtime x86 : , . . , , , , , . , , Type . :

, , chain . , , .

: , chain-, N , , baseline, .

, .

:

Ion 4- baseline. :

, , SpiderMonkey, V8 Node. — . .

. , , chain-.

, : 24-25 HolyJS, . — , .

जेएस को एलब्रस में पोर्ट करना