प्रदर्शन पर विचार करने का सबसे अच्छा समय कब है?

45

मैं सॉफ्टवेयर डेवलपमेंट बैकग्राउंड से आ रहा हूं। सॉफ्टवेयर विकास चक्र के दौरान, हम आम तौर पर कार्यात्मकताओं और काम करने वाले उत्पाद पर ध्यान केंद्रित करते हैं। विकास के अंत में, हम कोड को अनुकूलित करना और प्रदर्शन में सुधार करना शुरू करते हैं।

अब सवाल यह है कि क्या हमें खेल विकास में कोड की हर एक पंक्ति में प्रदर्शन के बारे में सोचने की जरूरत है?

ऐसा करने से मुझे लगता है कि हम डिजाइन पैटर्न और स्वच्छ कोड को याद करते हैं। मैं सोच रहा था कि क्या खेल विकास उद्योग में कोई सर्वोत्तम अभ्यास दृष्टिकोण है?

— Emad
स्रोत

8

समयपूर्व अनुकूलन के बारे में इस पिछले प्रश्न पर चर्चा आपको उपयोगी लग सकती है।

— DMGregory

10

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

— टॉम ज़ातो

10

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

— जॉन वाट

1

सब। । समय। अपने आप को कुछ समय और उबाऊ कार्य बचाएं, बस हर समय करें और आप खुद को पहले से ही कोड (यदि आवश्यक हो) की तुलना में आगे अनुकूलित करने की कोशिश करके खुद को बहुत ही शांत और geeky कार्य कर पाएंगे। बस यहीं से मस्ती शुरू हो जाती है।

— येट्स

6

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

— एरिक लिपर्ट

90

प्रदर्शन के लिए इंजीनियरिंग

विक्रेता की सिफारिशों का पालन करें।
सही डेटा संरचनाओं का उपयोग करें।
सही उपयोग पैटर्न लागू करें।
कुछ भी बेवकूफी मत करो।

अनुकूलन

जब पहले से लिखा कोड धीमा चल रहा है, तो इसे मापें, पता करें कि क्यों, इसे तेजी से बनाने के लिए क्या आवश्यक है।

समय से पहले अनुकूलन

माप के बिना क्या तेज या धीमा है, इसके बारे में धारणाएं बनाएं कि इन मान्यताओं को कैसे कोड और डिज़ाइन किया गया है।

ये तीनों चीजें एक जैसी नहीं हैं ।

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

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

उदाहरण के लिए: सभी GPU विक्रेता सलाह देते हैं कि GPU से रीडबैक हर फ्रेम धीमा है। रीडबैक न करने के लिए अपना कोड डिज़ाइन करना समय से पहले का अनुकूलन नहीं है ।

— मैक्सिमस मिनिमस
स्रोत

28

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

— एसी

2

@एसी मुझे यह भी लगता है कि अच्छा डिजाइन शुरू होने में समय लग सकता है, लेकिन अंत में इसका मतलब होगा कि आप तेजी से काम कर रहे हैं, जिसका मतलब है कि जरूरत पड़ने पर अनुकूलन के लिए अधिक समय। मेरा अनुभव (इसे वापस करने के लिए एक एकल, आधे-अधूरे सोलो हॉबी प्रोजेक्ट के साथ) यह है कि एक बार जब आपका प्रोजेक्ट काफी बड़ा हो जाता है, तो बड़े समय की खपत 1 होती है) "मैं यह सब कुछ जो पहले से ही है, उसमें बुनाई करने जा रहा हूं", और 2) "डेमनिट, जो कोड मैंने एक हफ्ते पहले लिखा था, जो पूरी तरह से फिट है, फिर मैं आगे क्या करना चाहता हूं, उसके साथ बिल्कुल काम नहीं करता है"। अच्छा डिज़ाइन (जो मैंने नहीं किया है) उन दोनों की मदद करता है।

— आर्थर

5

प्रदर्शन के लिए ठीक से इंजीनियर के लिए असफल होने को भी डिजाइन की नकल के रूप में सोचा जा सकता है। तो, अगर समय से पहले अनुकूलन सभी बुराई की जड़ है , तो यह समय से पहले निराशा का क्या कारण है ? ; पी

— निंजाल

1

@ आर्थर "अधिक समय [अनुकूलन के लिए छोड़ दिया"? अपने स्वयं के सीमित विकास संसाधनों (और वर्कफ़्लो) के अनुकूलन के साथ-साथ इसे देखने का यह एक अच्छा तरीका है ताकि आपको अपने अनुकूलन प्रयास से इष्टतम प्रभाव मिले! इसके अलावा, मुझे पता है कि हम स्टैक ओवरफ्लो पर उचित नहीं हैं, लेकिन यह मुझे आश्चर्यचकित करता है कि हम अनुकूलन की बात कर रहे हैं और पेरेटो सिद्धांत का अभी तक एक उत्तर में उल्लेख नहीं किया गया है ... मुझे "प्रतिशत" शब्द भी नहीं दिखता है!

— एसी

1

अच्छे प्रदर्शन के लिए अपनी डेटा संरचनाओं को डिज़ाइन करते समय, आपको यह जानना होगा कि कंप्यूटर कुशलतापूर्वक और वे क्या नहीं कर सकते हैं। उदाहरण के लिए, आधुनिक सीपीयू लूपिंग ओवर ब्रीज बल की एक बड़ी मात्रा को लागू कर सकते हैं, खासकर यदि आप चीजों को सेट करते हैं तो कंपाइलर एसएसई / एवीएक्स के साथ ऑटो-वेक्टर कर सकते हैं। (उदाहरण के लिए एक्स निर्देशांक और y निर्देशांक, xy जोड़ी structs या xyz ट्रिपल के एरे नहीं की एरे के प्रयोग सरणियों देखें। stackoverflow.com/tags/sse/info कुछ लिंक, विशेष रूप से के लिए इन्सोम्नियाक खेलों में SIMD (जीडीसी 2015)

— पीटर Cordes

22

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

धीमी मशीन का उपयोग करके आप जान पाएंगे कि आपको प्रदर्शन में सुधार करने की आवश्यकता है।

क्या हमें खेल विकास में कोड की हर एक पंक्ति में प्रदर्शन के बारे में सोचने की आवश्यकता है?

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

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

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

— पीटर
स्रोत

1

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

— हॉफमैले

डिबग बिल्ड के साथ बहुत विकास किया जाता है जो रिलीज़ बिल्ड की तुलना में बहुत धीमा है। इसका मतलब यह है कि विकास के लिए एक तेज मशीन की आवश्यकता होती है जो स्वीकार्य गति से खेल को चलाने के लिए आवश्यक है।

— जैक ऐडली

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

— पीटर कॉर्ड्स

9

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

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

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

— फिलिप
स्रोत

3

आपको कम से कम जाने के लिए पर्याप्त प्रयास करने की आवश्यकता है "क्या यह संभावित रूप से एक अड़चन है, और यदि हां, तो इसे ठीक करने के लिए एक बदलाव कैसे शामिल होगा?"।

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

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

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

क्या मैं ग्राफिकल फ्रैमरेट के लिए गेम अपडेट रेट बांध रहा हूं?
क्या मैं तुल्यकालिक बचत को मजबूर कर रहा हूं?
क्या मैं मजबूर कर रहा हूँ (गैर) -Determinism?

— TLW
स्रोत

1

एक गेम के लिए, आपका प्राथमिक लक्ष्य लक्ष्य न्यूनतम युक्ति (और संभवतः अधिकतम लोड समय, आदि) पर लक्ष्य फ्रैमरेट को पूरा करना है।

ऐसा करने के लिए, नहीं, आपको हर लाइन के बाद परेशान होने की जरूरत नहीं है।

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

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

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

— डैमन
स्रोत

0

असली लें। जवाब बस पूरी तरह से नहीं है। कोई चर्चा नहीं।

मुख्य समस्या आपके द्वारा पूछे जाने का तरीका है:

क्या हमें खेल विकास में कोड की हर एक पंक्ति में प्रदर्शन के बारे में सोचने की आवश्यकता है?

आपका मतलब है, कॉन्फिग स्क्रीन जैसी चीजों में भी? एक छोटे 1kb अधिकतम फ़ाइल के लिए एक बार पार्सर की तरह? गंभीरता से?

इससे कोई फर्क नहीं पड़ता कि आपका अधिकांश कोड कितना महत्वपूर्ण है। एक भी ऐसा सॉफ्टवेयर नहीं है जहाँ हर एक लाइन क्रिटिकल हो। कहीं भी नहीं।

— टॉम टॉम
स्रोत