गो पर एक कार्यक्रम को फिर से तैयार करना: 23 बार त्वरण

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

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

प्रोग्राम, मोटे तौर पर बोलता है, इनपुट फ़ाइल को पढ़ता है, इसे लाइन से लाइन करता है और ऑब्जेक्ट्स को मेमोरी में भरता है।



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

$ go test -bench=. 

μ प्रति कॉल (कम - बेहतर)

यह पता चला है कि मेरे कंप्यूटर पर "अच्छा कोड" 16% तेज है। क्या हम इसे गति दे सकते हैं?

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


हम सादगी के पहाड़ पर चढ़ते हैं, और फिर उससे नीचे जाते हैं

यह एक व्यापार है: आप कितनी दूर जाने के लिए तैयार हैं?

त्वरण पर काम को ठीक से प्राथमिकता देने के लिए, इष्टतम रणनीति बाधाओं को खोजने और उन पर ध्यान केंद्रित करना है। ऐसा करने के लिए, प्रोफाइलिंग टूल का उपयोग करें। आपके मित्र आपके मित्र हैं:

 $ go test -bench=. -cpuprofile cpu.prof $ go tool pprof -svg cpu.prof > cpu.svg 

CPU उपयोग का एक बड़ा ग्राफ (SVG के लिए क्लिक करें)

 $ go test -bench=. -trace trace.out $ go tool trace trace.out 

इंद्रधनुष अनुरेखण: बहुत से छोटे कार्य (केवल Google Chrome में काम करने के लिए क्लिक करें)

ट्रेसिंग पुष्टि करता है कि सभी प्रोसेसर कोर व्यस्त हैं (0, 1, आदि के नीचे की रेखाएं), और, पहली नज़र में, यह अच्छा है। लेकिन वह हजारों छोटे रंग "गणना" और कई खाली क्षेत्रों को भी दिखाती है जहां कोर निष्क्रिय थे। आइए ज़ूम करते हैं:


3 एमएस में "विंडो" (खोलने के लिए क्लिक करें, केवल Google Chrome में काम करता है)

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

आइए देखें कि फ्लाइट डिटेक्टर हमें क्या बताता है। क्या डेटा के समकालिक उपयोग में कोई समस्या है (यदि कोई हैं, तो हमारे पास प्रदर्शन की तुलना में बहुत बड़ी समस्याएं हैं)?

 $ go test -race PASS 

बहुत बढ़िया! सब कुछ सही है। कोई फ्लाइट नहीं मिली। टेस्ट फ़ंक्शंस और बेंचमार्क फ़ंक्शंस अलग-अलग फ़ंक्शंस हैं ( प्रलेखन देखें ), लेकिन यहां वे एक ही ParseAdexpMessage फ़ंक्शन को कॉल करते हैं, इसलिए हमने परीक्षण द्वारा डेटा फ़्लाइट के लिए जो जाँच की वह ठीक है।

"अच्छे" संस्करण में प्रतिस्पर्धी मॉडल में एक अलग गोरोइन (सभी कोर का उपयोग करने के लिए) इनपुट फ़ाइल से प्रत्येक पंक्ति को संसाधित करना शामिल है। यहाँ लेखक के अंतर्ज्ञान ने अच्छी तरह से काम किया, क्योंकि गोरोइनों में आसान और सस्ती सुविधाओं के लिए एक प्रतिष्ठा है। लेकिन हम समानांतर निष्पादन के माध्यम से कितना जीतते हैं? आइए एक ही कोड से तुलना करें लेकिन गोरोइन का उपयोग न करें (केवल फ़ंक्शन कॉल से पहले आने वाले शब्द को हटा दें):




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


μ प्रति कॉल (कम बेहतर है)

हमें "अच्छा" संस्करण की तुलना में लगभग 40% त्वरण मिला, कोड को सरल बनाने और प्रतिस्पर्धा ( अंतर ) को हटाने।


एक गोरोइन के साथ, एक समय में केवल एक कोर काम करता है

आइए अब पिफिट ग्राफ में हॉट फंक्शन्स को देखें:


अड़चनों की तलाश में

वर्तमान संस्करण (अनुक्रमिक ऑपरेशन, स्लाइस) का बेंचमार्क 86% समय संदेश भेजने में खर्च करता है, और यह सामान्य है। लेकिन हम जल्दी से ध्यान देंगे कि 43% समय नियमित अभिव्यक्ति और फ़ंक्शन (* Regexp) .FindAll का उपयोग करने पर खर्च किया जाता है।

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

हमारे कार्यक्रम में, एक टेम्पलेट

 patternSubfield = "-.[^-]*" 

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


μ प्रति कॉल (कम बेहतर है)

वाह! 40% अधिक उत्पादक कोड! सीपीयू खपत ग्राफ अब इस तरह दिखता है:



नियमित अभिव्यक्तियों पर अधिक समय बर्बाद नहीं हुआ। इसका एक महत्वपूर्ण हिस्सा (40%) पांच अलग-अलग कार्यों के मेमोरी आवंटन के लिए जाता है। दिलचस्प बात यह है कि अब 21% समय बाइट्स पर खर्च होता है। नि : शुल्क समारोह:


यह फीचर मुझे इंटिग्रेट करता है। हम यहां क्या कर सकते हैं?

बाइट्स। ट्रिम को एक तर्क के रूप में "कट ऑफ" वाले पात्रों के साथ एक स्ट्रिंग की उम्मीद है, लेकिन इस स्ट्रिंग के रूप में हम केवल एक चरित्र - एक स्थान के साथ एक स्ट्रिंग पास करते हैं। यह केवल एक उदाहरण है कि आप जटिलता के कारण त्वरण कैसे प्राप्त कर सकते हैं: चलो मानक एक के बजाय हमारे ट्रिम फ़ंक्शन बनाएं। हमारा कस्टम ट्रिम फ़ंक्शन एक पूरी पंक्ति के बजाय एक बाइट के साथ काम करेगा:



μ प्रति कॉल (कम बेहतर है)

हुर्रे, एक और 20% की कटौती! वर्तमान संस्करण मूल "खराब" की तुलना में चार गुना तेज है और एक ही समय में केवल एक कोर का उपयोग करता है। बुरा नहीं है!

---

इससे पहले, हमने लाइन प्रोसेसिंग स्तर पर प्रतिस्पर्धा को छोड़ दिया था, लेकिन मेरा तर्क है कि उच्च स्तर पर प्रतिस्पर्धा का उपयोग करके त्वरण प्राप्त किया जा सकता है। उदाहरण के लिए, 6,000 फाइलें (6,000 संदेश) संसाधित करना मेरे कंप्यूटर पर तेजी से होता है यदि प्रत्येक फ़ाइल को अपने गोरोइन में संसाधित किया जाता है:


μ प्रति कॉल (कम बेहतर है; बैंगनी एक प्रतिस्पर्धी समाधान है)

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

हम केवल कुछ श्रमिकों को बनाकर निष्पादन समय (12 गुना नहीं, लेकिन अभी भी) को कम कर सकते हैं। उदाहरण के लिए, 12 लंबे समय तक रहने वाले गोरोइन, जिनमें से प्रत्येक संदेशों के भाग को संसाधित करेगा:


μ प्रति कॉल (कम बेहतर है; बैंगनी एक प्रतिस्पर्धी समाधान है)

यह विकल्प एकल-थ्रेडेड संस्करण की तुलना में निष्पादन समय को 79% कम कर देता है। ध्यान दें कि यह रणनीति केवल तभी समझ में आती है जब आपके पास प्रक्रिया के लिए कई फाइलें हों।

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

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


μ प्रति कॉल (कम बेहतर है; बैंगनी एक प्रतिस्पर्धी समाधान है)

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

---

अन्य एल्गोरिदम का उपयोग करने से एक बड़ा प्रदर्शन लाभ भी हो सकता है।

यहाँ मैं रॉब पाइक से लेक्सिकल स्कैनिंग के एक व्याख्यान से प्रेरित था,


एक कस्टम लेक्सर ( स्रोत ) और एक कस्टम पार्सर ( स्रोत ) बनाने के लिए। यह कोड अभी तैयार नहीं है (मैं कोने के मामलों का एक गुच्छा संसाधित नहीं करता हूं), यह मूल एल्गोरिथ्म की तुलना में कम स्पष्ट है, और कभी-कभी सही त्रुटि हैंडलिंग लिखना मुश्किल है। लेकिन यह सबसे अनुकूलित संस्करण की तुलना में छोटा और 30% तेज है।


μ प्रति कॉल (कम बेहतर है; बैंगनी एक प्रतिस्पर्धी समाधान है)

हां। परिणामस्वरूप, हमें स्रोत कोड की तुलना में 23 गुना का त्वरण मिला।

---

आज के लिए बस इतना ही। मुझे उम्मीद है कि आपको यह रोमांच पसंद आया होगा। यहाँ कुछ नोट और निष्कर्ष दिए गए हैं:

• विभिन्न तकनीकों का उपयोग करके, अमूर्तता के विभिन्न स्तरों पर उत्पादकता में सुधार किया जा सकता है, और लाभ अक्सर बढ़ जाता है।
  
• ट्यूनिंग को उच्च-स्तरीय अमूर्त के साथ शुरू करने की आवश्यकता है: डेटा संरचनाएं, एल्गोरिदम, मॉड्यूल का सही डिकम्पलिंग। निम्न-स्तर के सार को बाद में लें: I / O, बैचिंग, प्रतिस्पर्धात्मकता, मानक पुस्तकालय का उपयोग करना, स्मृति के साथ काम करना, स्मृति आवंटित करना।
  
• बिग ओ विश्लेषण बहुत महत्वपूर्ण है, लेकिन आमतौर पर एक कार्यक्रम को गति देने के लिए सबसे उपयुक्त उपकरण नहीं है।
  
• बेंचमार्क लिखना कठिन काम है। बाधाओं को खोजने और कार्यक्रम में क्या हो रहा है इसकी व्यापक समझ हासिल करने के लिए प्रोफाइलिंग और बेंचमार्क का उपयोग करें। ध्यान रखें कि बेंचमार्क परिणाम वैसा नहीं है जैसा आपके उपयोगकर्ता वास्तविक जीवन के काम में अनुभव करेंगे।
  
• सौभाग्य से, उपकरण का एक सेट ( बेंच , पोट्रेट , ट्रेस , रेस डिटेक्टर , कवर ) कोड के प्रदर्शन पर शोध को सस्ती और दिलचस्प बनाता है।
  
• अच्छा, प्रासंगिक परीक्षण लिखना कोई तुच्छ कार्य नहीं है। लेकिन वे लानत है महत्वपूर्ण नहीं wilds में जाने के लिए। आप यह सुनिश्चित कर सकते हैं कि कोड सही रहे।
  
• खुद को रोकें और पूछें कि "उपवास पर्याप्त है।" किसी एक समय की स्क्रिप्ट के अनुकूलन में अपना समय बर्बाद न करें। यह मत भूलो कि अनुकूलन मुफ़्त नहीं है: इंजीनियर का समय, जटिलता, बग और तकनीकी ऋण।
  
• कोड को जटिल करने से पहले दो बार सोचें।
  
• जटिलता Ω (n²) और ऊपर के एल्गोरिथ्म आमतौर पर बहुत महंगे होते हैं।
  
• जटिलता ओ (एन) या ओ (एन लॉग एन) और नीचे के साथ एल्गोरिदम आमतौर पर ठीक हैं।
  
• विभिन्न छिपे हुए कारकों को नजरअंदाज नहीं किया जा सकता है। उदाहरण के लिए, लेख में सभी सुधार इन कारकों को कम करके किए गए थे, न कि एल्गोरिथ्म की जटिलता वर्ग को बदलकर।
  
• I / O अक्सर एक अड़चन है: नेटवर्क क्वेरी, डेटाबेस क्वेरी, फाइल सिस्टम।
  
• नियमित अभिव्यक्तियाँ अक्सर बहुत महंगी और अनावश्यक होती हैं।
  
• मेमोरी आवंटन गणना की तुलना में अधिक महंगे हैं।
  
• ढेर पर आवंटित वस्तु ढेर पर आवंटित वस्तु से सस्ती है।
  
• महंगी स्मृति चाल के विकल्प के रूप में स्लाइस उपयोगी हैं।
  
• स्ट्रिंग्स तभी प्रभावी होती हैं जब रीड-ओनली (रिस्सलिंग सहित)। अन्य सभी मामलों में, [] बाइट अधिक प्रभावी हैं।
  
• यह बहुत महत्वपूर्ण है कि आपके द्वारा संसाधित किया जाने वाला डेटा निकट है (प्रोसेसर कैश)।
  
• प्रतिस्पर्धा और समानता बहुत उपयोगी हैं, लेकिन तैयार करना मुश्किल है।
  
• जब आप गहरी और नीची खुदाई करते हैं, तो "कांच का फर्श" याद रखें जिसे आप गो में तोड़ना नहीं चाहते हैं। यदि आपके हाथ कोडांतरक निर्देशों, SIMD निर्देशों को आज़माने के लिए खुजली कर रहे हैं, तो आपको केवल प्रोटोटाइप के लिए गो का उपयोग करने की आवश्यकता हो सकती है, और फिर हार्डवेयर और प्रत्येक नैनोसेकंड का पूर्ण नियंत्रण पाने के लिए निचले स्तर की भाषा पर स्विच करें!