"कोई फर्क नहीं पड़ता कि आप कितनी कोशिश करते हैं, आप एक सुअर से बाहर दौड़ने का रास्ता नहीं बना सकते। आप हालांकि, एक तेज सुअर बना सकते हैं" (Emax के स्रोत कोड में टिप्पणी)

इस तथ्य को सभी जानते हैं कि सूअर उड़ते नहीं हैं। कोई भी कम लोकप्रिय राय यह नहीं है कि उच्च-स्तरीय भाषाओं को निष्पादित करने की तकनीक के रूप में बाईटेकोड व्याख्याकारों को समय-समय पर गतिशील संकलन के उपयोग के बिना त्वरित नहीं किया जा सकता है।

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

भाग एक, परिचयात्मक
भाग दो, अनुकूलन (वर्तमान)
भाग तीन, लागू

PorosenokVM

आइए परिचित हों।

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

पिगलेट वीएम मशीन में पूरे राज्य को एक संरचना में संग्रहीत किया जाता है:

static struct { /* Current instruction pointer */ uint8_t *ip; /* Fixed-size stack */ uint64_t stack[STACK_MAX]; uint64_t *stack_top; /* Operational memory */ uint64_t memory[MEMORY_SIZE]; /* A single register containing the result */ uint64_t result; } vm;

उपरोक्त हमें इस मशीन को निम्न-स्तरीय आभासी मशीनों की विशेषता प्रदान करने की अनुमति देता है, लगभग सभी ओवरहेड जिसमें मुख्य प्रोग्राम चक्र के रखरखाव पर पड़ता है:

 interpret_result vm_interpret(uint8_t *bytecode) { vm_reset(bytecode); for (;;) { uint8_t instruction = NEXT_OP(); switch (instruction) { case OP_PUSHI: { /* get the argument, push it onto stack */ uint16_t arg = NEXT_ARG(); PUSH(arg); break; } case OP_ADD: { /* Pop 2 values, add 'em, push the result back to the stack */ uint64_t arg_right = POP(); *TOS_PTR() += arg_right; break; } /* * ... * Lots of other instruction handlers here * ... */ case OP_DONE: { return SUCCESS; } default: return ERROR_UNKNOWN_OPCODE; } } return ERROR_END_OF_STREAM; }

कोड से पता चलता है कि प्रत्येक opcode के लिए, गुल्लक चाहिए:

निर्देश धारा से opcode प्राप्त करें।
सुनिश्चित करें कि opcode opcode मानों की मान्य श्रेणी में है (यह तर्क C कंपाइलर द्वारा स्विच कोड बनाते समय जोड़ा जाता है)।
शरीर के निर्देशों पर जाएं।
स्टैक से अनुदेश तर्क निकालें या सीधे बायोटेक में स्थित एक निर्देश तर्क को डीकोड करें।
एक ऑपरेशन करें।
यदि गणना का एक परिणाम है, तो इसे स्टैक पर रखें।
वर्तमान निर्देश से सूचक को अगले पर ले जाएं।

यहां पेलोड केवल पांचवें पैराग्राफ में है, बाकी ओवरहेड है: स्टैक (क्लॉज 4) से निर्देश तर्कों को डिकोड करना या पुनर्प्राप्त करना, ओपकोड मूल्य (क्लॉज 2) की जांच करना, बार-बार मुख्य लूप की शुरुआत में लौटना और बाद में मुश्किल से अनुमानित सशर्त संक्रमण (क्लाज 3) की भविष्यवाणी करना।

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

सुअर विधानसभा भाषा और एराटोस्थनीज की छलनी

पहले, चलो खेल के नियमों पर निर्णय लेते हैं।

सी में एक आभासी मशीन के लिए सीधे प्रोग्राम लिखना एक बुरा विचार है, लेकिन एक प्रोग्रामिंग भाषा बनाने के लिए एक लंबा समय है, इसलिए हमने खुद को गुल्लक विधानसभा भाषा में सीमित करने का फैसला किया।

एक प्रोग्राम जो इस असेंबलर में 1 से 65,536 तक की संख्या की गणना करता है, वह कुछ इस तरह दिखता है:

 # sum numbers from 1 to 65535 # init the current sum and the index PUSHI 1 PUSHI 1 # stack s=1, i=1 STOREI 0 # stack: s=1 # routine: increment the counter, add it to the current sum incrementandadd: # check if index is too big LOADI 0 # stack: s, i ADDI 1 # stack: s, i+1 DUP # stack: s, i+1, i+1 GREATER_OR_EQUALI 65535 # stack: s, i+1, 1 or 0 JUMP_IF_TRUE done # stack: s, i+1 DUP # stack: s, i+1, i+1 STOREI 0 # stack: s, i+1 ADD # stack: s+i+1 JUMP incrementandadd done: DISCARD PRINT DONE

अजगर नहीं, निश्चित रूप से, लेकिन सुअर की खुशी के लिए आपकी जरूरत की हर चीज है: टिप्पणी, टैग, सशर्त और बिना शर्त कूदना, उन्हें निर्देश के लिए मेनेमिक्स, और निर्देशों के लिए सीधे तर्क निर्दिष्ट करने की क्षमता।

मशीन "पिगलेट वीएम" के साथ पूरा करें कोडांतरक और डिस्सेम्बलर हैं, जो आत्मा में साहसी हैं और बहुत अधिक खाली समय है, पाठक स्वतंत्र रूप से लड़ाई में परीक्षण कर सकते हैं।

संख्या बहुत तेज़ी से बढ़ती है, इसलिए प्रदर्शन के परीक्षण के लिए मैंने एक और कार्यक्रम लिखा - एराटोस्थनीज़ की छलनी का एक भोली कार्यान्वयन।

वास्तव में, पिगलेट वैसे भी काफी तेज चलता है (इसके निर्देश मशीन वालों के करीब हैं), इसलिए, स्पष्ट परिणाम प्राप्त करने के लिए, मैं कार्यक्रम के सौ शुरुआत के लिए प्रत्येक माप करूंगा।

हमारे गैर-अनुकूलित सुअर का पहला संस्करण इस तरह चलता है:

 > ./pigletvm runtimes test/sieve-unoptimized.bin 100 > /dev/null PROFILE: switch code finished took 545ms

आधा सेकंड! तुलना निश्चित रूप से बेईमान है, लेकिन वही पायथन एल्गोरिथ्म सौ रन बनाता है थोड़ा धीमा:

 > python test/sieve.py > /dev/null 4.66692185402

4.5 सेकंड, या नौ बार धीमा। हमें घेंटा को श्रद्धांजलि देनी चाहिए - उसके पास क्षमता है! ठीक है, अब देखते हैं कि क्या हमारे सुअर प्रेस को पंप कर सकते हैं।

व्यायाम एक: स्टेटिक सुपरिनस्ट्रक्शन

फास्ट कोड का पहला नियम बहुत अधिक काम नहीं करना है। फास्ट कोड का दूसरा नियम यह है कि कभी भी बहुत अधिक काम न करें। तो पिगलेट वीएम किस तरह का अतिरिक्त काम करता है?

अवलोकन एक: हमारे कार्यक्रम की रूपरेखा से पता चलता है कि निर्देशों के अनुक्रम हैं जो दूसरों की तुलना में अधिक सामान्य हैं। हम अपने सुअर को अधिक पीड़ा नहीं देंगे और खुद को सिर्फ एक-दो निर्देशों तक सीमित रखेंगे:

LOADI 0, ADD - स्टैक को मेमोरी 0 से नंबर 0 पर रखें और इसे स्टैक के शीर्ष पर स्थित संख्या में जोड़ें।
PUSHI 65536, GREATER_OR_EQUAL - स्टैक पर एक संख्या डालें और उस संख्या के साथ तुलना करें जो पहले स्टैक के शीर्ष पर थी, तुलना (0 या 1) का परिणाम स्टैक पर वापस डाल दिया।
PUSHI 1, ADD - स्टैक पर एक संख्या डालें, इसे उस संख्या में जोड़ें जो पहले स्टैक के शीर्ष पर थी, और स्टैक पर जोड़ के परिणाम को वापस डाल दिया।

पिगलेट वीएम मशीन में 20 से अधिक निर्देश हैं, और एक पूरे बाइट का उपयोग एन्कोडिंग के लिए किया जाता है - 256 मान। नए निर्देशों का परिचय देना कोई समस्या नहीं है। हम क्या करेंगे:

 for (;;) { uint8_t instruction = NEXT_OP(); switch (instruction) { /* * Other instructions here * */ case OP_LOADADDI: { /* get immediate argument as an memory address , add it to value from the address to the top * of the stack */ uint16_t addr = NEXT_ARG(); uint64_t val = vm.memory[addr]; *TOS_PTR() += val; break; } case OP_GREATER_OR_EQUALI:{ /* get the immediate argument, compare it with the value from the address to the top of the stack */ uint64_t arg_right = NEXT_ARG(); *TOS_PTR() = PEEK() >= arg_right; break; } case OP_ADDI: { /* Add immediate value to the top of the stack */ uint16_t arg_right = NEXT_ARG(); *TOS_PTR() += arg_right; break; } /* * Other instructions here * */ }

कुछ भी जटिल नहीं है। आइये देखते हैं क्या आया:

 > ./pigletvm runtimes test/sieve.bin 100 > /dev/null PROFILE: switch code finished took 410ms

वाह! कोड केवल तीन नए निर्देशों के लिए है, और हमने डेढ़ सौ मिलीसेकंड जीते!

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

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

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

अगला कदम एक विशिष्ट कार्यक्रम के संदर्भ में सुपरइंस्ट्रक्शन का गतिशील संकलन हो सकता है, अर्थात, डायनामिक सुपरिनस्ट्रक्शन (90 और 2000 के दशक की शुरुआत में, इस तकनीक ने एक आदिम JIT संकलन की भूमिका निभाई थी)।

साधारण सी के ढांचे में मक्खी पर निर्देश बनाना असंभव है, और हमारे गुल्लक काफी हद तक इसे एक ईमानदार प्रतियोगिता नहीं मानते हैं। सौभाग्य से, मेरे पास उसके लिए कुछ बेहतर अभ्यास हैं।

व्यायाम दो: opcode मूल्यों की सीमा की जाँच

हमारे त्वरित कोड नियमों का पालन करते हुए, एक बार फिर हम अपने आप से शाश्वत प्रश्न पूछते हैं: आप क्या नहीं कर सकते?

जब हम पिगलेट वीएम मशीन के उपकरण से परिचित हो गए, तो मैंने उन सभी कार्यों को सूचीबद्ध किया जो वर्चुअल मशीन प्रत्येक ओपोड के लिए करती है। और बिंदु 2 (स्विच मानों की वैध सीमा में फिट होने के लिए ओपकोड के मूल्य की जांच करना) सबसे संदिग्ध है।

आइए एक नजर डालते हैं कि GCC स्विच निर्माण को कैसे संकलित करता है:

एक संक्रमण तालिका का निर्माण किया जाता है, अर्थात्, एक तालिका जो निर्देश के शरीर को निष्पादित करने वाले कोड के पते पर ओपकोड के मूल्य को प्रदर्शित करती है।
एक कोड डाला जाता है जो यह जांचता है कि प्राप्त ओपकोड सभी संभव स्विच मूल्यों की सीमा के भीतर है या नहीं और डिफ़ॉल्ट लेबल पर भेजता है यदि ओपकोड के लिए कोई हैंडलर नहीं है।
हैंडलर में जाने वाला कोड डाला जाता है।

लेकिन प्रत्येक निर्देश के लिए मूल्यों के अंतराल की जांच क्यों की जाती है? हम मानते हैं कि ओपेक या तो सही है - OP_DONE निर्देश द्वारा निष्पादन को समाप्त करना, या गलत - बायटेकोड से परे जाना। ओपकोड स्ट्रीम की पूंछ शून्य के साथ चिह्नित है, और शून्य OP_ABORT निर्देश का ऑपकोड है, जो एक त्रुटि के साथ बायटेकोड के निष्पादन को पूरा करता है।

यह पता चला है कि इस चेक की बिल्कुल ज़रूरत नहीं है! और पिगेट को इस विचार को संकलक तक पहुंचाने में सक्षम होना चाहिए। आइए मुख्य स्विच को थोड़ा ठीक करने का प्रयास करें:

 uint8_t instruction = NEXT_OP(); /* Let the compiler know that opcodes are always between 0 and 31 */ switch (instruction & 0x1f) { /* All the instructions here */ case 26 ... 0x1f: { /*Handle the remaining 5 non-existing opcodes*/ return ERROR_UNKNOWN_OPCODE; } }

यह जानते हुए कि हमारे पास केवल 26 निर्देश हैं, हम एक बिट मास्क लगाते हैं (ओपल मूल्य 0x1f एक द्विआधारी 0b11111 है जो ओपकोड पर मानों की सीमा को 0 से 31 तक कवर करता है) और 26 से 31 के बीच अप्रयुक्त मानों में हैंडलर जोड़ते हैं।

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

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

हम कोशिश करते हैं:

 > ./pigletvm runtimes test/sieve.bin 100 > /dev/null PROFILE: switch code finished took 437ms PROFILE: switch code (no range check) finished took 383ms

एक और 50 मिलीसेकंड! घेंटा, ऐसा लगता है जैसे आपने खुद को अपने कंधों में सुना है! "

व्यायाम तीन: ट्रेल्स

क्या अन्य अभ्यास हमारे पिगलेट की मदद कर सकते हैं? सुपर निर्देशों के लिए हमें सबसे बड़ी बचत मिली। और वे मुख्य चक्र से बाहर निकलने की संख्या को कम करते हैं और आपको इसी ओवरहेड लागत से छुटकारा पाने की अनुमति देते हैं।

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

एक और समस्या है बाइट-बाय-बायट रीडिंग ऑफ़िस ओपकोड्स और सीधे तर्कों को बायटेकोड से। भौतिक मशीनें 64-बिट मशीन शब्द के साथ काम करती हैं और वास्तव में इसे पसंद नहीं करती हैं जब कोड कम मूल्यों के साथ संचालित होता है।

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

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

हमारे मामले में, आप बेस यूनिट की परिभाषा को ट्रैक तक भी बढ़ा सकते हैं। पिगलेट वीएम मशीन के संदर्भ में ट्रैक में सभी क्रमिक रूप से जुड़े (यानी बिना शर्त कूद का उपयोग) बेस ब्लॉक शामिल होंगे।

निर्देशों के क्रमिक निष्पादन के अलावा, निर्देशों के प्रत्यक्ष तर्कों को अग्रिम रूप से डिकोड करना अच्छा होगा।

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

आइए पहले इस बारे में सोचें कि आप ट्रैक में शामिल निर्देश की कल्पना कैसे कर सकते हैं:

 struct scode { uint64_t arg; trace_op_handler *handler; };

यहाँ आर्ग निर्देश का पूर्व-डिकोडेड तर्क है, और हैंडलर एक फ़ंक्शन का सूचक है जो निर्देश के तर्क को निष्पादित करता है।

अब प्रत्येक ट्रेस का दृश्य इस तरह दिखता है:

 typedef scode trace[MAX_TRACE_LEN];

अर्थात्, एक ट्रेस सीमित लंबाई के एस-कोड का एक क्रम है। वर्चुअल मशीन के अंदर ट्रेस कैश ही इस तरह दिखता है:

 trace trace_cache[MAX_CODE_LEN];

यह संभव बायोटेक लंबाई से अधिक नहीं लंबाई के साथ निशान की एक सरणी है। समाधान आलसी है, स्मृति को बचाने के लिए यह एक हैश तालिका का उपयोग करने के लिए समझ में आता है।

दुभाषिया की शुरुआत में, प्रत्येक ट्रेस का पहला हैंडलर खुद को संकलित करेगा:

 for (size_t trace_i = 0; trace_i < MAX_CODE_LEN; trace_i++ ) vm_trace.trace_cache[trace_i][0].handler = trace_compile_handler;

मुख्य दुभाषिया लूप अब इस तरह दिखता है:

 while(vm_trace.is_running) { scode *code = &vm_trace.trace_cache[vm_trace.pc][0]; code->handler(code); }

एक ट्रेस कम्पाइलर थोड़ा अधिक जटिल है, और वर्तमान निर्देश से शुरू होने वाले ट्रेस के निर्माण के अलावा, यह निम्न कार्य करता है:

 static void trace_compile_handler(scode *trace_head) { scode *trace_tail = trace_head; /* * Trace building here */ /* now, run the chain that has a trace_compile_handler replaced with proper instruction handler * function pointer */ trace_head->handler(trace_head); }

सामान्य निर्देश हैंडलर:

 static void op_add_handler(scode *code) { uint64_t arg_right = POP(); *TOS_PTR() += arg_right; /* * Call the next trace handler * */ /* scodes are located in an array so we can use pointer arithmetic to get the next handler */ code++; code->handler(code); }

एक हैंडलर जो फ़ंक्शन की पूंछ पर कोई कॉल नहीं करता है, प्रत्येक ट्रेस को समाप्त करता है:

 static void op_done_handler(scode *code) { (void) code; vm_trace.is_running = false; vm_trace.error = SUCCESS; }

यह सब, ज़ाहिर है, सुपरइंस्ट्रक्शन जोड़ने की तुलना में अधिक जटिल है, लेकिन देखते हैं कि क्या यह हमें कुछ भी देता है:

 > ./pigletvm runtimes test/sieve.bin 100 > /dev/null PROFILE: switch code finished took 427ms PROFILE: switch code (no range check) finished took 395ms PROFILE: trace code finished took 367ms

हुर्रे, एक और 30 मिलीसेकंड!

ऐसा कैसे? केवल लेबल के माध्यम से नेविगेट करने के बजाय, हम निर्देश संचालकों की कॉल श्रृंखला बनाते हैं, कॉल और पासिंग तर्कों पर समय बिताते हैं, लेकिन हमारा पिगी अभी भी अपने लेबल के साथ एक साधारण स्विच की तुलना में तेजी से पटरियों के साथ चलता है।

ट्रैक प्रदर्शन में यह लाभ तीन कारकों के कारण प्राप्त हुआ है:

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

हमारे प्रशिक्षण के परिणामों को संक्षेप में प्रस्तुत करने से पहले, पिगलेट और मैंने कार्यक्रमों की व्याख्या करने के लिए एक और प्राचीन तकनीक की कोशिश करने का फैसला किया - सिलना कोड।

व्यायाम चार: "सिलना" कोड

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

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

सीवन कोड (अंग्रेजी टोकन थ्रेडेड कोड) के संस्करण में, जिसे मैंने अपने सुअर लक्ष्यों को प्राप्त करने के लिए चुना था, हम बायटेकोड को बचाते हैं, लेकिन व्याख्या शुरू करने से पहले, हम एक तालिका बनाते हैं जो निर्देश हैंडकोड लेबल के पते पर निर्देश ऑपकोड प्रदर्शित करता है:

 const void *labels[] = { [OP_PUSHI] = &&op_pushi, [OP_LOADI] = &&op_loadi, [OP_LOADADDI] = &&op_loadaddi, [OP_STORE] = &&op_store, [OP_STOREI] = &&op_storei, [OP_LOAD] = &&op_load, [OP_DUP] = &&op_dup, [OP_DISCARD] = &&op_discard, [OP_ADD] = &&op_add, [OP_ADDI] = &&op_addi, [OP_SUB] = &&op_sub, [OP_DIV] = &&op_div, [OP_MUL] = &&op_mul, [OP_JUMP] = &&op_jump, [OP_JUMP_IF_TRUE] = &&op_jump_if_true, [OP_JUMP_IF_FALSE] = &&op_jump_if_false, [OP_EQUAL] = &&op_equal, [OP_LESS] = &&op_less, [OP_LESS_OR_EQUAL] = &&op_less_or_equal, [OP_GREATER] = &&op_greater, [OP_GREATER_OR_EQUAL] = &&op_greater_or_equal, [OP_GREATER_OR_EQUALI] = &&op_greater_or_equali, [OP_POP_RES] = &&op_pop_res, [OP_DONE] = &&op_done, [OP_PRINT] = &&op_print, [OP_ABORT] = &&op_abort, };

प्रतीकों पर ध्यान दें && - ये निर्देश के निकायों के साथ लेबल करने के लिए संकेत हैं, जीसीसी का सबसे गैर-मानक विस्तार।

कोड निष्पादित करना शुरू करने के लिए, प्रोग्राम के पहले ओपकोड के लिए पॉइंटर पर क्लिक करें:

 goto *labels[NEXT_OP()];

यहाँ कोई चक्र नहीं है और वहाँ नहीं होगा, प्रत्येक निर्देश स्वयं ही निम्न हैंडलर के लिए एक कूद बनाता है:

 op_pushi: { /* get the argument, push it onto stack */ uint16_t arg = NEXT_ARG(); PUSH(arg); /* jump to the next instruction*/ goto *labels[NEXT_OP()]; }

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

वह पूरी तकनीक है। वह अपनी सादगी के लिए गुल्लक पसंद करती थी। आइए देखें कि व्यवहार में क्या होता है:

 > ./pigletvm runtimes test/sieve.bin 100 > /dev/null PROFILE: switch code finished took 443ms PROFILE: switch code (no range check) finished took 389ms PROFILE: threaded code finished took 477ms PROFILE: trace code finished took 364ms

ऊप्स! यह हमारी सभी तकनीकों में सबसे धीमा है! क्या हुआ था? चलो सभी GCC अनुकूलन को बंद करते हुए एक ही परीक्षण चलाते हैं:

 > ./pigletvm runtimes test/sieve.bin 100 > /dev/null PROFILE: switch code finished took 969ms PROFILE: switch code (no range check) finished took 940ms PROFILE: threaded code finished took 824ms PROFILE: trace code finished took 1169ms

यहां, सिलना कोड बेहतर प्रदर्शन करता है।

तीन कारक यहां भूमिका निभाते हैं:

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

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

आइए हम आखिरकार अपने सूअर द्वारा प्राप्त सफलताओं का सारांश और मूल्यांकन करें।

सुअर के उड़ान का विश्लेषण

मुझे यकीन नहीं है कि इसे एक उड़ान कहा जा सकता है, लेकिन चलो इसका सामना करते हैं, हमारी गुल्लक ने 550 मिलीसेकंड से लेकर "चलनी" पर अंतिम 370 मिलीसेकंड तक के लिए एक लंबा सफर तय किया है। हमने विभिन्न तकनीकों का उपयोग किया: सुपर-निर्देश, मूल्यों के अंतराल की जांच से छुटकारा, निशान के जटिल यांत्रिकी और अंत में, यहां तक कि सिलना कोड भी। एक ही समय में, हम, सामान्य तौर पर, सभी लोकप्रिय सी कंपाइलरों में लागू चीजों के ढांचे के भीतर काम करते हैं। 1.5 के एक कारक द्वारा त्वरण, जैसा कि मुझे लगता है, एक अच्छा परिणाम है, और घेंटा गर्त में चोकर के एक अतिरिक्त हिस्से के हकदार हैं।

सुअर के साथ हम खुद के लिए जो निहित शर्तें रखते हैं, उनमें से एक पिगलेट वीएम मशीन के स्टैक आर्किटेक्चर को संरक्षित करना है। वास्तुकला को पंजीकृत करने के लिए संक्रमण, एक नियम के रूप में, कार्यक्रमों के तर्क के लिए आवश्यक निर्देशों की संख्या को कम करता है और तदनुसार, अनुदेश प्रबंधक को अनावश्यक निकास से छुटकारा पाने में मदद कर सकता है। मुझे लगता है कि इस पर 10-20% समय कट सकता है।

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

बेशक, अन्य चालें हैं जिनके लिए हमारी छोटी सुअर खुर तक नहीं पहुंची है। , — - — - . , .

PS , , , , ( https://www.instagram.com/vovazomb/ ), .

PPS , . true-grue - — PigletC . !

PPPS iliazeus : . ; . .

सुअर उड़ान, या Bytecode दुभाषियों का अनुकूलन