कैसे हमने PHP 7 को PHP 5 से दोगुना तेज़ बना दिया। भाग 2: PHP 7.1 में बाइटकोड का अनुकूलन

कहानी के पहले भाग में , हाइलॉडड ++ पर ज़ेंड टेक्नोलॉजीज से दिमित्री स्टोगोव की एक प्रस्तुति पर आधारित, हमने PHP की आंतरिक संरचना को समझा। हमने विस्तार से सीखा और पहले हाथ से बुनियादी डेटा संरचनाओं में क्या बदलाव हुए, PHP 7 ने दो बार से अधिक तेजी लाने की अनुमति दी। इसे रोका जा सकता था, लेकिन पहले से ही संस्करण 7.1 में, डेवलपर्स बहुत आगे बढ़ गए, क्योंकि उनके पास अभी भी अनुकूलन के लिए कई विचार थे।

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



कटौती के तहत, दिमित्री स्टोगोव दिखाएगा कि यह कैसे काम करता है, एक सरल उदाहरण का उपयोग करके।

बायोटेक अनुकूलन

नीचे बाइटकोड है जिसमें मानक PHP संकलक फ़ंक्शन को संकलित करता है। यह एकल-पास - तेज़ और गूंगा है, लेकिन फिर से हर HTTP अनुरोध पर अपना काम करने में सक्षम है (यदि ओपचे जुड़ा नहीं है)।

OPcache ऑप्टिमाइज़ेशन

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


उन्हें एक यौगिक असाइनमेंट ऑपरेशन में जोड़ा जा सकता है, जो सीधे परिणाम पर ASSIGN_ADD $sum, $i : ASSIGN_ADD $sum, $i । एक अन्य उदाहरण पोस्ट-इन्क्रीमेंट वेरिएबल है जो सैद्धांतिक रूप से किसी प्रकार का परिणाम दे सकता है।


यह एक अदिश मान नहीं हो सकता है और इसे हटा दिया जाना चाहिए। ऐसा करने के लिए, निम्नलिखित अनुदेश का उपयोग करें। लेकिन अगर आप इसे प्री-इन्क्रीमेंट में बदलते हैं, तो FREE इंस्ट्रक्शन की आवश्यकता नहीं है।


अंत में दो RETURN स्टेटमेंट्स हैं: पहला सोर्स टेक्स्ट में RETURN स्टेटमेंट का सीधा रिफ्लेक्शन है, और दूसरा क्लोजिंग ब्रैकेट के साथ डंब कंपाइलर द्वारा जोड़ा गया है। यह कोड कभी नहीं पहुंचेगा और इसे हटाया जा सकता है।
लूप में केवल चार निर्देश शेष हैं। ऐसा लगता है कि अनुकूलन के लिए आगे कुछ भी नहीं है, लेकिन हमारे लिए नहीं।
$i++ और इसके अनुरूप निर्देश को देखें - PRE_INC पूर्व-वृद्धि। हर बार इसे निष्पादित किया जाता है:

• यह जाँचने की आवश्यकता है कि किस प्रकार का चर आया;
• चाहे वह is_long ;
• वेतन वृद्धि;
• अतिप्रवाह के लिए जांच;
• अगले पर जाएं;
• शायद अपवाद की जाँच करें।

लेकिन एक व्यक्ति, बस PHP कोड को देख रहा है, चर $i , 0 से 100 तक की सीमा में है, और कोई अतिप्रवाह नहीं हो सकता है, प्रकार की जांच आवश्यक नहीं है, और कोई अपवाद भी नहीं हो सकता है। PHP 7.1 में, हमने इसे समझने के लिए कंपाइलर को सिखाने की कोशिश की ।

नियंत्रण प्रवाह ग्राफ का अनुकूलन

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


इसलिए हमने सी.एफ.जी.

स्टेटिक सिंगल असाइनमेंट फॉर्म का अनुकूलन

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


प्रत्येक चर के लिए, हम एक सूचकांक, या पुनर्जन्म संख्या जोड़ते हैं। प्रत्येक स्थान पर जहां असाइनमेंट होता है, हम एक नया इंडेक्स डालते हैं, और जहां हम उनका उपयोग करते हैं - जब तक प्रश्न चिह्न नहीं लगता, क्योंकि यह हमेशा हर जगह नहीं जाना जाता है। उदाहरण के लिए, निर्देश में IS_SMALLER $ i दोनों ब्लॉक L0 से नंबर 4 के साथ और नंबर 2 के साथ पहले ब्लॉक से आ सकता है।

इस समस्या को हल करने के लिए, SSA Phi pseudo-function को प्रस्तुत करता है , जो यदि आवश्यक हो, तो मूल-> ब्लॉक की शुरुआत में डाला जाता है, जो एक चर के सभी प्रकार के सूचकांकों को लेता है, जो अलग-अलग स्थानों से बुनियादी-ब्लॉक पर आए, और चर का एक नया पुनर्जन्म बनाते हैं। यह ऐसे चर हैं जो बाद में अस्पष्टता को खत्म करने के लिए उपयोग किए जाते हैं।


इस तरह से सभी प्रश्न चिह्नों को प्रतिस्थापित करते हुए, हम SSA का निर्माण करेंगे।

ऑप्टिमाइज़ेशन टाइप करें

अब हम प्रकार घटाते हैं - जैसे कि प्रबंधन पर सीधे इस कोड को निष्पादित करने का प्रयास करना।


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


हम मानते हैं कि आउटपुट फी () हमारे पास लंबा होगा।


हम आगे वितरित करते हैं। हम विशिष्ट कार्यों के लिए आते हैं, उदाहरण के लिए, ASSIGN_ADD और PRE_INC । दो लंबे समय तक जोड़ें। ओवरफ्लो होने पर परिणाम या तो लंबा या दोहरा हो सकता है।


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


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

रेंज प्रचार अनुकूलन

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

पर्वतमाला का यह आउटपुट एक समान, लेकिन थोड़ा अधिक जटिल तरीके से बनाया गया है। नतीजतन, हमें सूचक 2, 4, 6 7 के साथ चर $i की एक निश्चित श्रृंखला मिलती है, और अब हम आत्मविश्वास से कह सकते हैं कि वेतन वृद्धि $i से अतिप्रवाह नहीं होगा।


इन दो परिणामों को मिलाकर, हम यह सुनिश्चित कर सकते हैं कि डबल चर $i कभी नहीं बन सकता।


हम सभी को अभी तक अनुकूलन नहीं मिला है, यह अनुकूलन के लिए जानकारी है! ASSIGN_ADD पर विचार करें। सामान्य शब्दों में, इस निर्देश के लिए आए योग का पुराना मूल्य, उदाहरण के लिए, एक वस्तु हो सकता है। फिर, इसके बाद, पुराने मूल्य को हटा दिया जाना चाहिए था। लेकिन हमारे मामले में, हम यह सुनिश्चित करने के लिए जानते हैं कि लंबा या दोहरा है, जो एक स्केलर मूल्य है। कोई विनाश की आवश्यकता नहीं है, हम ASSIGN_ADD को ADD बदल सकते हैं - एक आसान निर्देश। ADD sum चर का उपयोग तर्क और मान दोनों के रूप में करता है।


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


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


मूल की तुलना में बाइटकोड परिणाम।


चक्र में केवल 3 निर्देश बचे हैं, और उनमें से दो अत्यधिक विशिष्ट हैं। नतीजतन, दाईं ओर कोड मूल की तुलना में 3 गुना तेज है ।

अति विशिष्ट हस्त

किसी भी PHP क्रॉल हैंडलर सिर्फ एक सी फ़ंक्शन है । बाईं ओर एक मानक हैंडलर है, और ऊपर दाईं ओर एक अति विशिष्ट है। बायाँ एक जाँच करता है: यदि कोई अपवाद हुआ है, तो ऑपरेंड का प्रकार, यदि अतिप्रवाह हुआ है। सही एक बस एक जोड़ता है और वह यह है। यह 4 मशीन निर्देशों में अनुवाद करता है। अगर हम आगे बढ़े और जेआईटी किया, तो हमें केवल एक बार अनुदेश अनुदेश की आवश्यकता होगी।

आगे क्या है?

हम JIT के बिना PHP शाखा 7 की गति को जारी रखना चाहते हैं। PHP 7.1 फिर से विशिष्ट सिंथेटिक परीक्षणों पर 60% तेजी से होगा , लेकिन वास्तविक अनुप्रयोगों पर यह लगभग एक जीत नहीं देता है - वर्डप्रेस पर केवल 1-2%। यह विशेष रूप से दिलचस्प नहीं है। अगस्त 2016 से, जब बड़े बदलावों के लिए 7.1 शाखा जमी थी, हमने फिर से PHP 7.2 या PHP 8 के लिए JIT पर काम करना शुरू किया।

एक नए प्रयास में, हम कोड बनाने के लिए डायनाम का उपयोग करते हैं, जिसे LuaJIT-2 के लिए माइक पॉल द्वारा विकसित किया गया था। यह अच्छा है क्योंकि यह बहुत जल्दी कोड उत्पन्न करता है : तथ्य यह है कि मिनट एलएलवीएम पर जेआईटी संस्करण में संकलित किए गए थे अब 0.1-0.2 एस में होता है। पहले से ही आज, जेआईटी पर बेंच.एफपी पर त्वरण PHP 5 की तुलना में 75 गुना तेज है।

वास्तविक अनुप्रयोगों में कोई तेजी नहीं है, और यह हमारे लिए अगली चुनौती है। भाग में, हमें इष्टतम कोड मिला, लेकिन कई PHP स्क्रिप्ट्स को संकलित करने के बाद, हमने प्रोसेसर कैश को रोक दिया, इसलिए यह तेजी से काम नहीं करता था। और नहीं कोड गति वास्तविक अनुप्रयोगों में एक अड़चन थी ...

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

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


मैंडेलब्रोट टेस्ट में समान भाषाओं की तुलना में शीर्षक चित्र, PHP पर लौटना, बहुत अच्छे परिणाम दिखाता है (हालांकि डेटा 2016 के अंत में प्रासंगिक है)।

आरेख सेकंड में निष्पादन का समय दिखाता है, कम बेहतर है।

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

हम 17 मई को PHP रूस में मिलेंगे, हम पारिस्थितिकी तंत्र की संभावनाओं और विकास और वास्तव में जटिल और शांत परियोजनाओं के लिए PHP का उपयोग करने के अनुभव पर चर्चा करेंगे। पहले से ही हमारे साथ:

• PHP कर्नेल के सबसे प्रमुख डेवलपर्स में से एक निकिता पोपोव बताएंगे कि PHP 7.4 के आगामी रिलीज में हमें क्या इंतजार है।
• दिमित्री स्टोगोव PHP 8 में भव्य योजनाओं के बारे में बात करेंगे।
• रोडरनर एप्लिकेशन सर्वर के लेखक एंटोन टिटोव , " रोडरनर का उपयोग करके हाइब्रिड PHP / गो एप्लीकेशन विकसित करना " विषय पेश करेंगे।

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