क्या वास्तव में बिग ओ मायने रखता है?

Question

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

विशेष रूप से गेम प्रोग्रामिंग और उद्योग के लिए, वास्तव में सबसे ज्यादा और क्यों मायने रखता है?

सन्दर्भ बहुत मददगार होगा।

Comments

बिग-ओ = अनुकूलन। मुझे यह जानने के लिए थोड़ा बड़ा किया कि 0 क्या था।

— अटैकिंगहोबो

बिग-ओ "अनुकूलन" नहीं है। बिग-ओ विश्लेषण का एक रूप है जो आपको बताता है कि दक्षता के मामले में विभिन्न एल्गोरिदम कैसे व्यवहार करेंगे, क्योंकि तत्वों की संख्या बढ़ जाती है। अधिक विवरण के लिए en.wikipedia.org/wiki/Big_O_notation देखें ।

— ज़ोरबहुत

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

— drxzcl

ऑप्टिमाइज़ करने का नियम याद रखें: 1) ऐसा न करें। 2) (केवल विशेषज्ञ) इसे अभी तक न करें।

— 17

अच्छी तरह से सबसे पहले बिग ओ का उपयोग अंतरिक्ष या कम्प्यूटेशनल जटिलता के लिए किया जा सकता है, इसलिए "बाकी सब कुछ" बिल्कुल सच नहीं है। दूसरा, बिग ओ आमतौर पर सामान्य केस विश्लेषण की तुलना में किसी चीज़ की गणना करने के लिए बहुत सरल है, और इसका उपयोग त्वरित मानसिक जांच के रूप में किया जाएगा कि क्या आप कुछ गलत कर रहे हैं। यदि स्प्राइट को खींचने में O (2 ^ n) समय लगता है, तो आपको संभवतः एक अलग एल्गोरिथम चुनना चाहिए। यदि आप सॉफ़्टवेयर डिज़ाइन के लिए अधिक व्यावहारिक दृष्टिकोण चाहते हैं, तो CS के बजाय SE प्रथाओं पर ध्यान दें। सीएस प्रकृति में सैद्धांतिक है, जबकि एसई उद्योग पर अधिक आधारित है।

— डेलेटर

Answer 1

"व्हाट वन ट्रू पाथ" के बारे में हर दूसरे सवाल के साथ , ये सभी आपके टूलबॉक्स में उपकरण हैं और ऐसे मामले हैं जहां बड़े-ओ सब कुछ ट्रम्प करते हैं, और ऐसे स्थान जहां यह कोई फर्क नहीं पड़ता (टीएम)।

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

आप बड़े-हे के बारे में चिंतित नहीं हो सकते हैं जब, ठीक है, मैं वास्तव में एक समय के बारे में सोच नहीं सकता, लेकिन मुझे यकीन है कि कुछ हैं। :) शुक्र है, जो चीजें हम गेम स्केल में करते हैं उनमें से अधिकांश रैखिक रूप से होती हैं; आप डिस्क से एक फ़ाइल को पढ़ना चाहते हैं? यह फ़ाइल के आकार के लिए रैखिक रूप से आनुपातिक समय लेगा (क्षेत्र के आकार के संभावित और संभावित सुधारों को छोड़कर)।

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

मुझे लगता है कि यह रकम है, हालांकि; किसी भी समय प्रोसेसर कुछ ऐसा कर रहा है जो सीधे खिलाड़ी के लिए प्रतिनिधित्व करने योग्य नहीं है, यह समय बर्बाद कर रहा है। उस समय की मात्रा को अधिकतम करना जो प्रोसेसर डेटा की गणना कर रहा है जो कि खिलाड़ी को दिखाया जाएगा, वाह को अधिकतम कर रहा है ! आप खिलाड़ी दे रहे हैं।

Comments

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

— जेसन

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

— रुशियो

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

जो, निश्चित, हालांकि यह एक अलग तरह की चिंता है। क्या आप O (1) चाहते हैं जहां स्थिर कारक उच्च है, या O (n) एक छोटे 'n' और कम स्थिर कारक के साथ है? इस मामले में बिग-ओ को जानना कोई समस्या नहीं है, लेकिन आपको इस बात का पता लगाने में मदद कर सकता है कि समाधान उन परिस्थितियों के लिए समझ में आता है या नहीं, जिनमें इसका उपयोग किया जाता है।

— डैश-टॉम-बैंग

Answer 2

मेरे अंगूठे का नियम यह है कि जब तक आप O (डरावने) नहीं होते, आपके अन्य मुद्दे अधिक प्रासंगिक हैं।

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

संपादित करें: थोड़ा और विस्तार में जाने के लिए, आपका बड़ा O उतना महत्वपूर्ण नहीं है क्योंकि (कम से कम मेरे अनुभव में) आपके अधिकांश डेटा सेट अपेक्षाकृत छोटे हैं। जब आप कुछ सौ से कम तत्वों के साथ डेटा संरचना के साथ काम कर रहे होते हैं, तो आप अपने ऊपरी प्रदर्शन के बारे में परवाह नहीं करते हैं। और यदि आपकी सूचियों में 100k + तत्व हैं तो आपको वास्तव में अपने एल्गोरिदम के सभी पहलुओं पर विचार करने की आवश्यकता है। कि, और मेरे अनुभव से स्मृति सीपीयू की गति की तुलना में सीमित कारक है। एक तेज़ मेमोरी हॉगिंग एल्गोरिथ्म एक झुकाव के रूप में अच्छा नहीं हो सकता है लेकिन आपके उपयोग के मामलों पर निर्भर करता है।

Answer 3

बिग ओ ज्यादातर समय मायने रखता है, लेकिन कभी-कभी सिद्धांत रूप में एक "खराब" एल्गोरिथ्म व्यवहार में बहुत तेज हो जाता है।

टोनी अल्ब्रेक्ट से एक महान उदाहरण देखें : http://seven-degrees-of-freedom.blogspot.com/2010/07/question-of-sorts.html

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

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

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

Comments

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

— डैश-टॉम-बैंग

Answer 4

जब मैं इंजन कोडिंग कर रहा हूँ, मैं अक्सर केवल एक निश्चित के साथ संबंध रहा हूँ n: मैं पहले से ही एक spacial विभाजन प्राप्त वस्तुओं की संख्या को सीमित मिल गया है update(), physics()और render()स्क्रीन और आसपास के क्षेत्रों पर लगभग उन लोगों के लिए। अधिकतम बैच आकार आमतौर पर प्रति गेम बहुत अच्छी तरह से परिभाषित होता है, हालाँकि यह आपके द्वारा योजनाबद्ध रूप से थोड़ा बड़ा होता है।

इस मामले में मैं बड़े-ओ के साथ उतना चिंतित नहीं हूं जितना कि मैं निरंतर कारक गुणक और निचले क्रम की शर्तों से संबंधित हूं। रनटाइम जैसे फंक्शन के लिए a*n^2 + b*n + c(जो है O(n^2)), मैं अक्सर कम करने aऔर संभवतः खत्म करने से बहुत अधिक चिंतित हूं c। एक सेटअप या फाड़ की लागत cआनुपातिक रूप से बड़ी बनाम छोटी हो सकती है n।

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

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

एक विशिष्ट उदाहरण देने के लिए: यह वास्तव में एक पृष्ठभूमि टाइल-स्ट्रीमिंग एल्गोरिथ्म के साथ हाथ से निकल गया जो 8x8 256-रंग की टाइलें प्रवाहित करता है। बैकग्राउंड "लेयर्स" के बीच स्ट्रीमिंग बफ़र्स को साझा करना उपयोगी है, और एक ही बफ़र को साझा करने में हम उनमें से 6 तक हो सकते हैं। समस्या यह है कि आवश्यक बफर के आकार का आकलन सभी 6 परतों की संभावित स्थितियों पर आधारित है - और यदि वे एक प्राइम-नंबर चौड़ाई / ऊंचाई / स्क्रॉल दर हैं, तो आप जल्दी से एक संपूर्ण खोज में शामिल होने लगते हैं - समीप आने लगता हैO(6^numTiles)- जो कई मामलों में "ब्रह्मांड की तुलना में अधिक लंबा होगा" श्रेणी में है। सौभाग्य से ज्यादातर मामले सिर्फ 2-3 परतें हैं, लेकिन फिर भी, हम आधे घंटे के रनटाइम से ऊपर हैं। फिलहाल, हम इन संभावनाओं के एक बहुत छोटे उपसमुच्चय का नमूना लेते हैं, जब तक कि निर्धारित समय बीतने तक (या हमने कार्य पूरा कर लिया है, जो कि छोटे डबल-लेयर कॉन्फ़िगरेशन के लिए हो सकता है) तक ग्रैन्युलैरिटी बढ़ाना। हम इस अनुमान को थोड़ा बढ़ा देते हैं कि पूर्व के आंकड़ों के आधार पर हम कितनी बार गलत साबित हुए हैं, और फिर अच्छे उपाय के लिए थोड़ा अतिरिक्त पैडिंग जोड़ते हैं।

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

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

Answer 5

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

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

लेकिन मैं आलसी महसूस कर रहा था इसलिए मैंने हर राक्षस के खिलाफ हर गोली की तुलना की। यहां तक ​​कि सबसे विषम परिस्थितियों में, टक्कर कोड 60fps पर सीपीयू के 10% से कम का उपयोग कर रहा था। बिग-ओ: महत्वहीन।

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

बिग-ओ सिर्फ खेलों में उतना ही महत्वपूर्ण है जितना कि बाकी सब चीजों में: यानी बिल्कुल महत्वहीन, जब तक यह महत्वपूर्ण नहीं हो जाता।

कुछ कोड लिखें। यदि यह बहुत धीमा है, तो इसे प्रोफाइल करें।

Answer 6

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

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

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

1. सुनिश्चित करें कि आप प्रत्येक फ्रेम में नया या मालॉक नहीं कह रहे हैं (यह हमेशा # 1 समस्या है)
2. काम कम करें: कम रे कास्ट, कम लोग, आदि।
3. बिग-ओ एल्गोरिदम प्रकार की समस्याएं
4. कैश सुसंगतता: बिखरी हुई मेमोरी के बजाय एरे में सामान रखें
5. डिबग मोड में STL का उपयोग न करें। (और आप हमेशा काम करने के लिए डिबग मोड चाहते हैं)

Answer 7

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

जाहिर है, हमेशा पहले प्रोफ़ाइल करें, और अंतिम को अनुकूलित करें (जब तक कि आप एक सुविधा व्यवहार्यता अध्ययन नहीं कर रहे हैं)।

Answer 8

आपके सॉफ़्टवेयर में बिग-ओ का महत्व ओ (एन ² ) है। जैसे-जैसे एन बढ़ता है, सही एल्गोरिथ्म होने का महत्व और भी अधिक बढ़ता है। :)

Comments

क्या यह निर्भर नहीं करता है कि एल्गोरिथ्म को कितनी बार कहा जाता है ..?

— 18

कुछ हद तक। लेकिन अगर इसे चलाने में 3 दिन लगते हैं, तो शायद यह मायने नहीं रखता है अगर आप इसे केवल एक बार कहते हैं। :)

— काइलोटन

Answer 9

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

1) यदि आपके पास दो एल्गोरिदम हैं जो ज्यादातर एक ही काम करते हैं लेकिन एक बेहतर ओ है, तो आपको संभवतः उस एक के लिए जाना चाहिए (स्पष्ट रूप से)

2) बिग ओ का संबंध स्पर्शोन्मुख विश्लेषण से है । बिग-ओ केवल वास्तव में खेलने में आता है जब एन बड़ा होता है । उदाहरण के लिए, एक O (n) 2 के प्रदर्शन में एक O (n) एल्गोरिदम बहुत समान हो सकता है .. छोटे n के लिए । यदि आप एक एल्गोरिथ्म के बारे में बात कर रहे हैं जिसके लिए प्रति शीर्ष पर n ^ 2 संचालन की आवश्यकता है, लेकिन n = 2 या n = 3, तो एक O (n ^ 2) एल्गोरिथ्म (4 और 9 ऑप्स सम्मान लेने) और के बीच बहुत अंतर नहीं है और एक ओ (एन) एक (2 और 3 ऑप्स सम्मान।)। हालाँकि, यदि n = 9, तो आप अचानक O (n ^ 2) एल्गोरिदम के लिए 81 ऑपरेशन की बात कर रहे हैं और O (n) वन के लिए केवल 9 - एक बड़ा अंतर - और यदि n = 100 है, तो आप हैं 100 ऑप्स बनाम 10000 के बारे में बात करना - एक बहुत बड़ा अंतर।

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

Answer 10

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

Answer 11

जब आप एक खेल समारोह या एक खेल का एक पहलू प्रोटोटाइप, आप इसे बेहतर बनाने के बारे में चिंता नहीं करनी चाहिए सब पर ।

इसे प्रोटोटाइप करने और उस कार्यक्षमता की अज्ञातताओं के बारे में जानने के दौरान, आवश्यक अनुकूलन स्पष्ट हो जाएंगे और 2 डी प्रकृति की तरह अंतिम डिजाइन का कारक बन जाएगा ... अधिकांश समय।

यह पसीना मत करो।

Comments

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

खेल विकास का कितना प्रतिशत प्रोटोटाइप है? आखिरकार आप कुछ जहाज करना चाहते हैं , है ना?

— डैश-टॉम-बैंग

Answer 12

यह सब-का-सब नहीं होना चाहिए। लेकिन यह स्पष्ट मुद्दों को सुलझाने में मदद करता है जिससे प्रदर्शन हिट हो सकते हैं; O (n ^ 2) समय में कुछ का उपयोग क्यों करें, जब आप O (लॉग एन) समय में एक ही काम कर सकते हैं?

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

Answer 13

खेल में (और सबसे अधिक) विकास, हम लूप में किए गए एक अतिरिक्त ऑपरेशन के बारे में सोच रहे हैं:

for (int i = 0; i < array.length; i ++) { /* ... */ }

बनाम

for (int i = 0, l = array.length; i < l; i ++) { /* ... */ }

अधिकांश आधुनिक खेलों में भौतिकी है, और आपको एन-बॉडी सिमुलेशन समस्या मिलेगी । एक भोली एल्गोरिथ्म में, यह O (n ^ 2) है, लेकिन एक अनुकूलन है जो इसे O बनाता है (n log n) (लेकिन कुछ सटीकता का बलिदान करता है)।

आप कह सकते हैं, आप गुरुत्वाकर्षण और कण बातचीत नहीं कर रहे हैं, लेकिन एक सेना की टीम व्यवहार (लाश के बारे में) के बारे में क्या वे दूसरों के स्थानों पर निर्भर करते हैं (अधिक विशिष्ट शब्द में: झुंड)?

पारंपरिक टकराव का पता लगाने वाले एल्गोरिथ्म में, समय जटिलता ओ-एन (एन ^ 2) है, एन-बॉडी की तरह। हालांकि, एक बेहतर तरीका है: दुनिया को कई छोटे हिस्सों से अलग करें ताकि केवल उसी हिस्से के अंदर की वस्तुओं का टकराव हो। Http://www.videotutorialsrock.com/opengl_tutorial/collision_detection/text.php देखें ।

यदि आप गेम स्क्रिप्ट करने योग्य हैं, तो स्क्रिप्ट में O, (n ^ 2) (और अप) नंबर-क्रंचिंग एल्गोरिदम लिखें, जैसे कि उपयोगकर्ता के बैग की खोज न करें। इसके बजाय कोड में एक अंतर्निहित कार्य करें।

Comments

आपके दोनों कोड उदाहरण O (n) हैं। बिग-ओ चर्चाओं का "प्रति पाश एक अतिरिक्त ऑपरेशन" से कोई लेना-देना नहीं है, बल्कि "सब कुछ पर पाश की पुनरावृत्ति के माध्यम से एक अतिरिक्त खोज" है।

— डैश-टॉम-बैंग

Answer 14

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

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

Comments

यह गलत है, बिग ओ नोटेशन का उपयोग समानांतर एल्गोरिदम के ऊपरी सीमा को रैखिक एल्गोरिदम के समान दिखाने के लिए किया जाता है। Big O का उपयोग समवर्ती पढ़ने / समवर्ती लिखने वाले आर्किटेक्चर आदि के लिए किया जा सकता है। आप O (1) में n ^ 2 प्रोसेसर के साथ छँटाई जैसी पागल चीजें भी कर सकते हैं

— डेविड यंग

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

— जैस्पर बेकर्स

"O (1) में n ^ 2 प्रोसेसर के साथ छँटाई" मुझे आमतौर पर लगता है कि O का यह उपयोग भ्रामक है क्योंकि संसाधन का उपयोग अभी भी O (n ^ 2) है, इससे कोई फर्क नहीं पड़ता कि आप किस तरह से समस्या का समाधान करते हैं। बड़ी संख्या में थ्रेड्स का मतलब प्रति सेकंड बड़ी संख्या में सीपीयू चक्र नहीं होता है।

— रिचर्ड फैबियन

O ^ (1) में n ^ 2 प्रोसेसर के साथ छंटनी सबसे अच्छा उदाहरण नहीं है, इस प्रकार का बिग-ओ नोटेशन शायद सबसे अधिक बार अकादमिया में देखा जाता है। कुछ इस तरह के cs.bu.edu/~best/crs/cs551/homeworks/hw1/pram.html अधिक यथार्थवादी समानांतर एल्गोरिदम लॉग (n) प्रोसेसर का उपयोग कर सकते हैं। इस प्रकार का सामान GPU प्रसंस्करण या सुपर कंप्यूटिंग पर ओवरलोडिंग के लिए बेहतर है जहां सैकड़ों कोर उपलब्ध हैं।

— डेविड यंग

जब तक मेरा मतलब था ओवरलोडिंग, ओवरलोडिंग नहीं। मेरी मूल टिप्पणी को अब संपादित नहीं कर सकते।

— डेविड यंग