आपको यह जानना होगा कि शून्य को कहां रखा जाए

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

मैंने व्यक्तिगत रूप से कई प्रदर्शन त्रुटियों को पूरा किया जो एक शून्य में प्रवेश करके तय की गई थीं, और इस लेख में मैं दो कहानियां साझा करना चाहता हूं।

माप का महत्व

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

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

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

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

लेकिन यह पता चला है कि 10% त्वरण बकवास है।

यह अधिक दिलचस्प है कि परीक्षण कोड के अंदर खेल की तुलना में लगभग 10 गुना तेजी से निष्पादित किया गया था। यह एक रोमांचक खोज थी।

परिणामों की जाँच करने के बाद, मैंने थोड़ी देर के लिए शून्य में देखा, लेकिन फिर यह मुझ पर छा गया।

कैशिंग भूमिका

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

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

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

लगभग 7% प्रोसेसर समय के बजाय, फ़ंक्शन ने लगभग 0.7% का उपभोग करना शुरू कर दिया और अब कोई समस्या नहीं थी।

सप्ताह के अंत में, मेरी रिपोर्ट कुछ इस तरह दिखी: "39,999 घंटे का शोध, 0.001 घंटे की प्रोग्रामिंग एक बड़ी सफलता है!"

डेवलपर्स को आमतौर पर गैर-कैश की गई मेमोरी को गलती से आवंटित करने के बारे में चिंता करने की आवश्यकता नहीं है: अधिकांश ऑपरेटिंग सिस्टम पर, यह विकल्प मानक विधियों का उपयोग करके उपयोगकर्ता स्थान में उपलब्ध नहीं है। लेकिन अगर आप इस बात में रुचि रखते हैं कि कितनी गैर-संग्रहणीय मेमोरी प्रोग्राम को धीमा कर सकती है, तो Virtual_Nlloc में PAGE_NOCACHE या PAGE_WRITECOMBINE झंडे आज़माएं ।

0 GiB 4 GiB से बेहतर है

मैं आपको एक और कहानी बताना चाहता हूं। यह एक बग के बारे में है जो मुझे मिला, और किसी और ने इसे तय किया। कुछ साल पहले, मैंने देखा कि मेरे लैपटॉप पर डिस्क कैश बहुत बार साफ हो गया है। मैंने पता लगाया कि ऐसा तब होता है जब 4 GiB लाइन पहुँच जाती है, और अंत में यह पता चला है कि मेरे नए बैकअप HDD के लिए ड्राइवर किसी अज्ञात सेक्टर के आकार की ओर इशारा करते हुए SectorSize को 0xFFFFFFFF (या −1) पर सेट करता है। Windows कर्नेल इस मान को 4 GiB के रूप में व्याख्या करता है और संबंधित मेमोरी ब्लॉक को आवंटित करता है, जिससे समस्या हुई।

मेरे पास पश्चिमी डिजिटल में संपर्क नहीं हैं, लेकिन मैं सुरक्षित रूप से मान सकता हूं कि उन्होंने यह त्रुटि 0xFFFFFFFF (या FF1) को शून्य से बदलकर तय की थी। एक चरित्र ने प्रवेश किया - और एक गंभीर प्रदर्शन समस्या को हल किया।

(इस अध्ययन के बारे में और अधिक पढ़ें "विंडोज को धीमा करना: तलाश और पहचानना" )

टिप्पणियों

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

मैं कोड को #define और अन्य तुच्छ परिवर्तनों के द्वारा अनुकूलित करने के लिए हुआ। कमेंट में हमें बताएं कि क्या आपके पास भी ऐसी कहानियां हैं।