PHP 8 में सबसे दिलचस्प बात

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

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


संदर्भ के लिए: दिमित्री स्टोगोव 1984 में प्रोग्रामिंग से परिचित हो गए, जब सभी पाठकों का जन्म नहीं हुआ था, और विकास उपकरण के विकास में एक महत्वपूर्ण योगदान देने में कामयाब रहे, और विशेष रूप से पीएचपी (हालांकि दिमित्री रूसी डेवलपर्स के लिए विशेष रूप से नहीं PHP के प्रदर्शन में सुधार करते हैं, उन्होंने व्यक्त किया हाईलाड ++ पुरस्कार के रूप में मेरा धन्यवाद)। दिमित्री PHP (eAccelerator) के लिए Turck MMCache के लेखक, Zend OPcache अनुरक्षक, PHPNG परियोजना के नेता हैं, जिसने PHP 7 का आधार बनाया और PHP के लिए JIT के विकास में अग्रणी है।

PHP प्रदर्शन विकास

मैंने 15 साल पहले PHP परफॉर्मेंस पर काम करना शुरू किया था जब मैंने Zend ज्वाइन किया था। फिर हमने संस्करण 5.0 जारी किया - पहला जिसमें भाषा वास्तव में ऑब्जेक्ट-ओरिएंटेड हो गई। तब से, हम सिंथेटिक परीक्षणों पर प्रदर्शन को 40 गुना और वास्तविक अनुप्रयोगों पर 6 गुना बढ़ा सकते हैं।



इस समय के दौरान, दो सफलता के क्षण थे:

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

अन्य सभी संस्करणों ने धीरे-धीरे कई कम प्रभावी विचारों को लागू करके उत्पादकता में वृद्धि की। उदाहरण के लिए, 7.1 संस्करण में, बायटेकोड (इन समाधानों पर एक लेख ) के अनुकूलन पर बहुत ध्यान दिया गया था।

आरेख से पता चलता है कि दोनों 5 वें संस्करण के विकास के अंत में और 7 वें संस्करण के विकास चक्र के अंत में, हम एक पठार पर जाते हैं और धीमा हो जाते हैं। इसलिए v7.4 पर काम के अंतिम वर्ष में, उत्पादकता में केवल 2% की वृद्धि हुई है। और यह बुरा नहीं है, क्योंकि टाइप किए गए गुणों और सहसंयोजक प्रकारों की नई विशेषताएं दिखाई दी हैं जो PHP को धीमा कर देती हैं (निकिता पोपोव ने इन नए उत्पादों के बारे में PHP रूस में बात की है)।

और अब हर कोई सोच रहा है कि 8 वें संस्करण से क्या उम्मीद की जाए, क्या यह v7 की सफलता को दोहरा सकता है?

JIT को या JIT को नहीं

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

लेकिन एक नई सफलता प्रौद्योगिकी के लिए आशा बनी हुई है - बेशक, मुझे JIT और जावास्क्रिप्ट इंजन की सफलता की कहानी याद है।

वास्तव में, PHP के लिए JIT पर काम 2012 से चल रहा है। 3 या 4 कार्यान्वयन थे, हमने इंटेल सहयोगियों, जावास्क्रिप्ट हैकर्स के साथ काम किया, लेकिन किसी तरह जेआईटी को मुख्य शाखा में शामिल करना संभव नहीं था। अंत में, PHP 8 में, हमने JIT को संकलक में शामिल किया और दोहरे त्वरण को देखा, लेकिन केवल सिंथेटिक परीक्षणों पर, लेकिन वास्तविक अनुप्रयोगों पर, इसके विपरीत, मंदी।



बेशक, यह वह नहीं है जिसके लिए हम प्रयास कर रहे हैं।

मामला क्या है? शायद हम कुछ गलत कर रहे हैं, शायद वर्डप्रेस इतना बुरा है, और कोई भी जेआईटी उसकी मदद नहीं करेगा (हाँ, वास्तव में यह है)। हो सकता है कि हमने पहले से ही दुभाषिया को बहुत अच्छा बना दिया हो, लेकिन जावास्क्रिप्ट में यह और भी बुरा है। कम्प्यूटेशनल परीक्षणों में, यह सच है: PHP दुभाषिया सबसे अच्छे में से एक है ।



मैंडेलब्रोट टेस्ट में, उन्होंने LuaJIT जैसे रत्न से भी आगे निकल गए, जो एक असेंबली भाषा में लिखा गया था। इस परीक्षण में, हम जीसीसी-5.3 संकलक के अनुकूलन से केवल 4 गुना पीछे हैं। जेआईटी के साथ, हम मैंडलब्रॉट टेस्ट में बेहतर परिणाम प्राप्त कर सकते हैं। वास्तव में, हम पहले से ही ऐसा करते हैं, अर्थात्, हम सी कंपाइलर के साथ प्रतिस्पर्धा करने वाले कोड उत्पन्न करने में सक्षम हैं।

फिर हम वास्तविक अनुप्रयोगों में तेजी क्यों नहीं ला सकते हैं? समझने के लिए, मैं आपको बताता हूं कि हम JIT कैसे करते हैं। आइए बुनियादी बातों से शुरू करें।

PHP कैसे काम करती है

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

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

लेकिन सबसे अधिक संभावना है कि कोई भी अपने नंगे रूप में PHP का उपयोग नहीं करता है, हर कोई इसे ओपचे के साथ उपयोग करता है।

PHP + OPcache

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

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

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



एक दुभाषिया सबसे पहले एक लूप है जो प्रत्येक निर्देश के लिए अपने स्वयं के हैंडलर को बुलाता है।

हम दो रजिस्टर का उपयोग करते हैं:

• execute_data - वर्तमान सक्रियण फ़्रेम का सूचक;
• opline - वर्तमान निष्पादन योग्य आभासी निर्देश के लिए सूचक।

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

लूप में, हम बस प्रत्येक निर्देश के लिए हैंडलर को कॉल करते हैं, जिसके बाद प्रत्येक हैंडलर के अंत में हम पॉइंटर को अगले निर्देश पर ले जाते हैं।

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

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

इस विवरण से विशिष्ट कार्य उत्पन्न होते हैं। चूंकि तीन संभावित पहले ऑपरेंड थे, तीन संभव दूसरे, हमें 9 अलग-अलग कार्य मिलते हैं।



इन कार्यों में, ऑपरेंड प्राप्त करने के लिए सार्वभौमिक तरीकों के बजाय, विशिष्ट लोगों का उपयोग किया जाता है जो किसी भी चेक को नहीं करते हैं।

हाइब्रिड वर्चुअल मशीन

एक और जटिलता जो हमने 7.2 संस्करण में बनाई है, तथाकथित हाइब्रिड वर्चुअल मशीन है।

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



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

हाइब्रिड वर्चुअल मशीन ने उत्पादकता को 5-10% तक बढ़ाने की अनुमति दी।

PHP + OPcache + JIT

जेआईटी को ओपेक के हिस्से के रूप में लागू किया गया है।



बाइटकोड को संकलित और अनुकूलित करने के बाद, इसके लिए एक जेआईटी संकलक लॉन्च किया गया है, जो अब स्रोत कोड के साथ काम नहीं करता है। PHP bytecode से, JIT संकलक मूल कोड उत्पन्न करता है, जिसके बाद पहले निर्देश (वास्तव में फ़ंक्शन) का पता bytecode में बदल जाता है।

उसके बाद, मूल, पहले से ही उत्पन्न कोड को किसी भी बदलाव के बिना मौजूदा दुभाषिया से बुलाया जाना शुरू होता है। मैं आपको एक सरल उदाहरण दिखाऊंगा।



बाईं ओर, PHP में एक निश्चित फ़ंक्शन लिखा जाता है जो 0 से 100 तक संख्याओं का योग गिनाता है। दाईं ओर, उत्पन्न बायटेकोड। पहला निर्देश 0 को योग प्रदान करता है, दूसरा मैं के लिए एक ही करता है, फिर लेबल के लिए बिना शर्त कूद। लेबल L1 पर, चक्र से बाहर निकलने की स्थिति की जाँच की जाती है: यदि यह पूरी हो गई है, तो बाहर निकलें, यदि नहीं, तो चक्र पर जाएँ। इसके बाद, मुझे राशि में जोड़ें, परिणाम को राशि में लिखें, 1 से बढ़ाएं।

यहाँ से सीधे हम कोडांतरक कोड उत्पन्न करते हैं, जो बहुत अच्छा निकलता है।



पहला QM_ASSIGN निर्देश सिर्फ दो मशीन निर्देशों (2-3 लाइनों) में संकलित किया गया है। %esi रजिस्टर में वर्तमान सक्रियण फ्रेम के लिए एक सूचक होता है। 30 ऑफसेट पर एक चर राशि निहित है। पहला निर्देश मान 0 लिखता है, दूसरा 4 लिखता है - यह पूर्णांक प्रकार ( IS_LONG ) का एक पहचानकर्ता है। चर i संकलक ने महसूस किया कि यह हमेशा लंबा होता है, और इसके लिए प्रकार को संग्रहीत करने की कोई आवश्यकता नहीं है। इसके अलावा, यह एक मशीन रजिस्टर में संग्रहीत किया जा सकता है। इसलिए, यहाँ केवल अपने साथ रजिस्टर का XOR रीसेट करने के लिए सबसे सरल और सस्ता निर्देश है।

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

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

जीट में क्या गलत है

ऐसे अच्छे कोडर कोड के साथ, हम वास्तविक अनुप्रयोगों को गति क्यों नहीं दे सकते हैं?

वास्तव में, वे चाहिए?

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

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

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

PHP 8 के लिए मामूली योजनाएं

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

• सभी कार्यों के लिए;
• केवल कार्यों के लिए जब उन्हें पहली बार बुलाया जाता है;
• आप प्रत्येक फ़ंक्शन पर एक काउंटर लटका सकते हैं और केवल उन कार्यों को संकलित कर सकते हैं जो वास्तव में गर्म हैं।

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

इन स्थितियों में, हम ईमानदार संकलन से दूर होने जा रहे हैं और इसे सट्टा करना शुरू कर रहे हैं।



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

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

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

प्रीलोड करने के लिए। वर्ग बंधन की समस्या

वास्तव में, PHP संवर्द्धन के लिए कई विचार जो लंबे समय से PHP 7 में सम्‍मिलित हैं और यहां तक ​​कि PHP 5 JIT से संबंधित कार्य से आते हैं। आज मैं एक और ऐसी तकनीक के बारे में बात करूंगा - यह प्रीलोडिंग है। यह तकनीक पहले से ही PHP 7.4 में शामिल है और फ़ाइलों का एक सेट निर्दिष्ट करना, उन्हें सर्वर स्टार्टअप पर लोड करना और इन फ़ाइलों के सभी कार्यों को स्थायी बनाना संभव बनाता है।

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

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

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

प्रीलोडिंग का उपयोग करना सभी PHP लिपियों के वैश्विक अनुकूलन के साथ भी मदद करता है, पूरी तरह से ओपेक ओवरहेड को हटा देता है और आपको अधिक कुशल आईआईटी कोड उत्पन्न करने की अनुमति देता है।

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

तकनीक की कल्पना पारदर्शी के रूप में की गई थी, अर्थात इसने बिना किसी परिवर्तन के मौजूदा अनुप्रयोगों (या भागों) को लोड करने की अनुमति दी। लेकिन लागू होने के बाद, यह पता चला कि यह पूरी तरह से सच नहीं है। सभी अनुप्रयोग काम नहीं करते हैं जैसे कि वे प्रीलोड का उपयोग करके लोड किए गए थे । उदाहरण के लिए, यदि function_exists या class_exists की जाँच करने के परिणामों के आधार पर एप्लिकेशन में एक कोड कहा जाता है, और फ़ंक्शन निरंतर हो जाता है, क्रमशः, function_exists हमेशा true हो जाता true , और जो कोड पहले कहा जाता था, उसे नहीं कहा जाता था।

तकनीकी रूप से, प्रीलोडिंग को केवल एक कॉन्फ़िगरेशन निर्देश opcache.preload की मदद से सक्षम किया जाता है, जिसके इनपुट के लिए आप एक स्क्रिप्ट फ़ाइल देते हैं - एक नियमित PHP फ़ाइल जिसे एप्लिकेशन स्टार्टअप चरण में लॉन्च किया जाएगा (न केवल लोड किया गया, बल्कि निष्पादित किया गया)।

 <?php function _preload(string $preload, string $pattern = "/\.php$/") { if (is_file($path) && preg_match($pattern, $path)) { opcache_compile_file($path) or die("Preloading failed"); } else if (is_dir($path)) { if ($dh = opendir($path)) { while (($file = readdir($dh)) !== false) { if ($file !== "." && $file !== "..") { _preload($path . "/" . $file, $pattern); } } closedir($dh); } } } _preload("/usr/local/lib/ZendFramework"); 

यह उन संभावित परिदृश्यों में से एक है, जो किसी न किसी निर्देशिका में (इस मामले में, ZendFramework) सभी फ़ाइलों को पुन: पढ़ने देता है। आप PHP में पूरी तरह से किसी भी स्क्रिप्ट को लागू कर सकते हैं: एक सूची के साथ पढ़ें, अपवाद जोड़ें, या यहां तक ​​कि संगीतकार के साथ पार करें ताकि यह पॉडोवाल फाइलें हो जो प्रीलोडिंग के लिए आवश्यक हैं। यह सब प्रौद्योगिकी का मामला है, और अधिक दिलचस्प यह नहीं है कि कैसे जहाज करना है, लेकिन क्या जहाज करना है।

प्रीलोडिंग में क्या लोड करना है

मैंने इस तकनीक को वर्डप्रेस पर आजमाया। यदि आप सभी * .php फ़ाइलों को बस अपलोड करते हैं, तो वर्डप्रेस पहले बताई गई विशेषता के कारण काम करना बंद कर देगा: इसमें एक फ़ंक्शन_एक्सिस्ट चेक है, जो हमेशा सच हो जाता है। इसलिए, मुझे स्क्रिप्ट को पिछले उदाहरण (अपवादों को जोड़ें) से थोड़ा संशोधित करना पड़ा, और फिर, वर्डप्रेस में किसी भी बदलाव के बिना, यह काम किया।


नतीजतन, प्रीलोडिंग के कारण हमें ~ 5% त्वरण मिला , जो पहले से ही खराब नहीं है।

मैंने लगभग सभी फ़ाइलों को डाउनलोड किया, लेकिन उनमें से आधे का उपयोग नहीं किया गया था। आप और भी बेहतर कर सकते हैं - एप्लिकेशन को चलाएं, देखें कि कौन सी फाइलें डाउनलोड की गई हैं। आप opcache_get_status() फ़ंक्शन का उपयोग करके ऐसा कर सकते हैं, जो सभी OPcache कैश्ड फ़ाइलों को वापस कर देगा और प्रीलोडिंग के लिए उनके लिए एक सूची बनाएगा। इस प्रकार, आप 3 एमबी बचा सकते हैं और थोड़ा अधिक त्वरण प्राप्त कर सकते हैं। तथ्य यह है कि अधिक मेमोरी की आवश्यकता होती है, जितना अधिक प्रोसेसर कैश गंदा हो जाता है, और उतना ही कम कुशल होता है। कम मेमोरी का उपयोग किया जाता है, उच्च गति।

एफएफआई - विदेशी फ़ंक्शन इंटरफ़ेस

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

PHP में FFI के लिए एक विस्तार बनाने के लिए पहले से ही कई प्रयास किए गए हैं, लेकिन वे सभी इंटरफेस का वर्णन करने के लिए अपनी भाषा या एपीआई का उपयोग करते हैं। मैंने LuaJIT में विचार की जासूसी की, जहां सी भाषा (एक उपसमुच्चय) का उपयोग इंटरफेस का वर्णन करने के लिए किया जाता है, और परिणाम एक बहुत अच्छा खिलौना है। अब, जब मुझे यह जांचने की आवश्यकता है कि सी में कुछ कैसे काम करता है, तो मैं इसे PHP में लिखता हूं - यह होता है, ठीक कमांड लाइन पर।

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

लेकिन:

• अपने आप को पैर में गोली मारने के ये 1000 नए तरीके हैं।
• C ज्ञान और कभी-कभी मैन्युअल मेमोरी प्रबंधन की आवश्यकता होती है।
• C- प्रीप्रोसेसर (#include, #define, ...) और C ++ का समर्थन नहीं करता है।
• JIT के बिना प्रदर्शन काफी कम है।

हालांकि, शायद कुछ के लिए यह सुविधाजनक होगा, क्योंकि संकलक की आवश्यकता नहीं है। यहां तक ​​कि विंडोज के तहत, यह PHP से किसी भी विज़ुअल-सी के बिना काम करेगा।

मैं आपको दिखाता हूँ कि लिनक्स के लिए एक वास्तविक GUI एप्लिकेशन को लागू करने के लिए FFI का उपयोग कैसे करें।

सी कोड से चिंतित न हों, मैंने खुद लगभग 20 साल पहले सी में एक जीयूआई लिखा था, लेकिन मुझे यह उदाहरण इंटरनेट पर मिला।

 #include <gtk/gtk.h> static void activate(GtkApplication* app, gpointer user_data) { GtkWidget *window = gtk_application_window_new(app); gtk_window_set_title(GTK_WINDOW(window), "Hello from C"); gtk_window_set_default_size(GTK_WINDOW(window), 200, 200); gtk_widget_show_all(window); } int main() { int status; GtkApplication *app; app = gtk_application_new("org.gtk.example", G_APPLICATION_FLAGS_NONE); g_signal_connect(app, "activate", G_CALLBACK(activate), NULL); status = g_application_run(G_APPLICATION(app), 0, NULL); g_object_unref(app); return status; } 

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

और अब, वही चीज़ PHP में फिर से लिखी गई है:

 <?php $ffi = FFI::cdef(" … // #include <gtk/gtk.h> ", "libgtk-3.so.0"); function activate($app, $user_data) { global $ffi; $window = $ffi->gtk_application_window_new($app); $ffi->gtk_window_set_title($window, "Hello from PHP"); $ffi->gtk_window_set_default_size($window, 200, 200); $ffi->gtk_widget_show_all($window); } $app = $ffi->gtk_application_new("org.gtk.example", 0); $ffi->g_signal_connect_data($app, "activate", "activate", NULL, NULL, 0); $ffi->g_application_run($app, 0, NULL); $ffi->g_object_unref($app); 

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

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

अब देखते हैं कि इंटरफ़ेस कैसा दिखता है। पहले भाग में, हम C में प्रकारों और कार्यों को निर्धारित करते हैं, और अंतिम पंक्ति में हम साझा पुस्तकालय को लोड करते हैं:

 <?php $ffi = FFI::cdef(" typedef struct _GtkApplication GtkApplication; typedef struct _GtkWidget GtkWidget; typedef void (*GCallback)(void*,void*); int g_application_run (GtkApplication *app, int argc, char **argv); unsigned long * g_signal_connect_data (void *ptr, const char *signal, GCallback handler, void *data, GCallback *destroy, int flags); void g_object_unref (void *ptr); GtkApplication * gtk_application_new (const char *app_id, int flags); GtkWidget * gtk_application_window_new (GtkApplication *app); void gtk_window_set_title (GtkWidget *win, const char *title); void gtk_window_set_default_size (GtkWidget *win, int width, int height); void gtk_widget_show_all (GtkWidget *win); ", "libgtk-3.so.0"); ... 

इस मामले में, इन सी-परिभाषाओं को जीटीके लाइब्रेरी की एच-फाइलों से कॉपी किया जाता है, लगभग अपरिवर्तित।

सी और पीएचपी के साथ एक ही फाइल में हस्तक्षेप न करने के लिए, आप पूरे सी-कोड को एक अलग फाइल में डाल सकते हैं, उदाहरण के लिए, gtk-ffi.h नाम के साथ और शुरुआत में जोड़े एक विशेष डिफाइन'ओव का एक जोड़ा जो लोडिंग के लिए इंटरफ़ेस का नाम और लाइब्रेरी निर्दिष्ट करता है:

 #define FFI_SCOPE "GTK" #define FFI_LIB "libgtk-3.so.0" 

इस प्रकार, हमने सी इंटरफ़ेस के पूरे विवरण को एक फ़ाइल में चुना। यह gtk-ffi.h लगभग वास्तविक है, लेकिन दुर्भाग्य से, हमने अभी तक सी प्रीप्रोसेसर को लागू नहीं किया है, जिसका अर्थ है कि मैक्रोज़ और शामिल काम नहीं करेंगे।

अब इस इंटरफ़ेस को PHP में लोड करते हैं:

 <?php final class GTK { static private $ffi = null; public static function create_window($title) { if (is_null(self::$ffi)) self::$ffi = FFI::load(__DIR__ . "/gtk_ffi.h"); $app = self::$ffi->gtk_application_new("org.gtk.example", 0); self::$ffi->g_signal_connect_data($app, "activate", function($app, $data) use ($title) { $window = self::$ffi->gtk_application_window_new($app); self::$ffi->gtk_window_set_title($window, $title); self::$ffi->gtk_window_set_default_size($window, 200, 200); self::$ffi->gtk_widget_show_all($window); }, NULL, NULL, 0); self::$ffi->g_application_run($app, 0, NULL); self::$ffi->g_object_unref($app); } } 

चूंकि एफएफआई एक खतरनाक तकनीक है, इसलिए हम इसे किसी के हाथ में नहीं देना चाहते हैं। आइए कम से कम एफएफआई ऑब्जेक्ट को छिपाएं, अर्थात, इसे कक्षा के अंदर निजी बनाएं। और हम FFI::cdef का उपयोग नहीं करते हुए एक FFI ऑब्जेक्ट FFI::cdef , लेकिन FFI::load का उपयोग करते हुए, जो पिछले उदाहरण से सिर्फ हमारी एच-फाइल को पढ़ता है।

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

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

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

एफएफआई + प्रीलोडिंग

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

 <?php FFI::load(__DIR__ . "/gtk_ffi.h"); final class GTK { static private $ffi = null; public static function create_window($title) { if (is_null(self::$ffi)) self::$ffi = FFI::scope("GTK"); $app = self::$ffi->gtk_application_new("org.gtk.example", 0); self::$ffi->g_signal_connect_data($app, "activate", function($app, $data) use ($title) { $window = self::$ffi->gtk_application_window_new($app); self::$ffi->gtk_window_set_title($window, $title); self::$ffi->gtk_window_set_default_size($window, 200, 200); self::$ffi->gtk_widget_show_all($window); }, NULL, NULL, 0); self::$ffi->g_application_run($app, 0, NULL); self::$ffi->g_object_unref($app); } } 

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

इस तरह से बनाए गए एक्सटेंशन का उपयोग सीधे कमांड लाइन से किया जा सकता है:

 $ php -d opcache.preload=gtk.php -r 'GTK::create_window(" !");' 

FFI क्रॉसब्रीडिंग और प्रीलोडिंग का एक और प्लस सभी उपयोगकर्ता स्तर स्क्रिप्ट के लिए FFI के उपयोग को प्रतिबंधित करने की क्षमता है। आप ffi.enable = preload निर्दिष्ट कर सकते हैं, जिसका अर्थ होगा कि हम प्रीलोडेड फ़ाइलों पर भरोसा करते हैं, लेकिन नियमित PHP स्क्रिप्ट से FFI को कॉल करना प्रतिबंधित है।

डेटा संरचनाओं के साथ काम करना सी

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

 <?php $points = FFI::new("struct {int x,y;} [100]"); for ($x = 0; $x < count($points); $x++) { $points[$x]->x = $x; $points[$x]->y = $x * $x; } var_dump($points[25]->y); // 625 var_dump(FFI::sizeof($points)); // 800  foreach ($points as &$p) { $p->x += 10; } var_dump($points[25]->x); // 35 

100 ( FFI::new != new FFI), integer. , C. PHP, . count, / foreach . 800 , PHP PHP' , 10 .

FFI:

• PHP.
• PHP.

Python/CFFI : (Cario, JpegTran), (ffmpeg), (LibreOfficeKit), (SDL) (TensorFlow).

, FFI .

- PHP. , , callback' , . FFI. , . FFI c JIT, , LuaJIT, . , , .

 for ($k=0; $k<1000; $k++) { for ($i=$n-1; $i>=0; $i--) { $Y[$i] += $X[$i]; } } 

FFI .

: Zeev Surasky (Zend), Andi Gutmans (ex-Zend, Amazon), Xinchen Hui (ex-Weibo, ex-Zend, Lianjia), Nikita Popov (JetBrains), Anatol Belsky (Microsoft), Anthony Ferrara (ex-Google, Lingo Live), Joe Watkins, Mohammad Reza Haghighat (Intel) Intel, Andy Wingo (JS hacker, Igalia), Mike Pall ( LuaJIT).

, , .

PHP Russia 2020 ! telegram- , 2019 youtube- , , — .