मुझे स्मृति प्रबंधन के प्रकार में दिलचस्पी है, जीटीए IV जैसे गेम का उपयोग यह हो सकता है कि इसे बहुत सारी वस्तुओं को बहुत जल्दी बनाने और हटाने की आवश्यकता है। ढेर और अन्य चीजों को खंडित करने से कैसे बचें। अगर कोई मुझे सही दिशा में इंगित कर सकता है तो मैं वास्तव में इसकी सराहना करता हूं।जीटीए IV जैसे गेम ढेर को कैसे विभाजित नहीं करते हैं?
वे memory pooling, विशेष आवंटकों और विशेष कंटेनर कक्षाओं जैसी चीजों का उपयोग करते हैं।
मेमोरी पूलिंग! हां, उस शब्द को भूल गए :) – Daniel
मुझे लगता है क्योंकि उनकी वस्तुएं अधिकतर आकार के हैं, वे कुछ आंतरिक मेमोरी मैनेजर का उपयोग कर सकते हैं जो वास्तव में मुक्त स्मृति नहीं है, लेकिन इसे उपलब्ध के रूप में चिह्नित करता है और अगली बार ~ आकार का हिस्सा आवंटित किया जाता है।
वैसे भी 'मुक्त()' के सरल कार्यान्वयन क्या हैं। पहली वाक्य के लिए – Artelius
बहुत सारी वस्तुओं को बनाना और नष्ट करना वास्तव में तेज़ी से ढेर विखंडन का मतलब नहीं है। अक्सर, यदि वस्तुएं एक ही आकार के हैं, तो एक के द्वारा मुक्त स्थान अगली के लिए आवंटित किया जा सकता है।
अक्सर, एक अनुकूलन के रूप में भी, एक प्रोग्राम ऑब्जेक्ट्स के लिए स्मृति मुक्त नहीं कर सकता है और हटा सकता है, लेकिन पुराने लोगों को पूल में रखता है और केवल एक को पकड़ लेता है और 'नया' ऑब्जेक्ट बनाने के लिए सामग्री को ओवरराइट करता है।
+1। इतने सारे लोग विखंडन के बारे में बात करते हैं और इसका कोई मतलब नहीं है कि इसका क्या अर्थ है। –
जबकि यह पेपर विशेष रूप से गेम का संदर्भ नहीं देता है, यह कस्टम मेमोरी आवंटकों के एक अच्छे दौर को प्रदान करता है जो लोग अक्सर प्रदर्शन सुधारने के प्रयास में सी और सी ++ अनुप्रयोगों में नियोजित होते हैं (और एक चेतावनी कहानी है)।
Reconsidering custom memory allocation, बर्गर, Zorn & मैककिनले, OOPSLA प्राप्त करने के लिए प्रदर्शन में सुधार अक्सर कस्टम स्मृति allocators का उपयोग उम्मीद कर 2002
प्रोग्रामर्स। यह गहराई से अध्ययन आठ अनुप्रयोगों की जांच करता है जो कस्टम आवंटकों का उपयोग करते हैं। हैरानी की बात है कि, इनमें से छह अनुप्रयोगों के लिए, एक अत्याधुनिक सामान्य उद्देश्य आवंटक (ली आवंटक) कस्टम आवंटकों की तुलना में या बेहतर प्रदर्शन करता है। दो अपवाद क्षेत्रों का उपयोग करते हैं, जो उच्च प्रदर्शन (44% तक के सुधार) प्रदान करते हैं। क्षेत्र प्रोग्रामर बोझ को भी कम करते हैं और मेमोरी लीक के स्रोत को खत्म करते हैं। हालांकि, हम दिखाते हैं कि प्रोग्रामर की क्षेत्रों में अलग-अलग वस्तुओं को मुक्त करने में असमर्थता से स्मृति खपत में काफी वृद्धि हो सकती है। इससे भी बदतर, यह सीमा सामान्य प्रोग्रामिंग मुहावरे के क्षेत्रों के उपयोग को रोकती है, जिससे उनकी उपयोगिता कम हो जाती है। हम सामान्य उद्देश्य और क्षेत्र-आधारित आवंटकों का एक सामान्यीकरण प्रस्तुत करते हैं जिन्हें हम रीप कहते हैं। रीप्स क्षेत्र और ढेर का संयोजन है, जो व्यक्तिगत ऑब्जेक्ट हटाने के अतिरिक्त क्षेत्र अर्थशास्त्र की पूरी श्रृंखला प्रदान करता है। हम दिखाते हैं कि हमारे पुनर्मूल्यांकन के कार्यान्वयन से उच्च प्रदर्शन प्रदान करता है, जो क्षेत्र-जैसे अर्थशास्त्र के साथ अन्य आवंटकों को बेहतर प्रदर्शन करता है। हम अभ्यास में रीपस के अंतरिक्ष फायदे और सॉफ्टवेयर इंजीनियरिंग लाभ का प्रदर्शन करने के लिए केस स्टडी का उपयोग करते हैं। हमारे नतीजे बताते हैं कि तेजी से क्षेत्रों की आवश्यकता वाले प्रोग्रामर को रीप का उपयोग करना चाहिए, और कस्टम आवंटकों पर विचार करने वाले अधिकांश प्रोग्रामर को इसके बजाय ली आवंटक का उपयोग करना चाहिए।
मनोरंजक कि पहला जवाब आपके ब्लॉग से लिंक होगा :) –
वहाँ मल्टी-थ्रेडेड कार्यान्वयन के लिए दो बहुत अच्छा malloc कार्यान्वयन हैं:
tcmalloc: गूगलjemalloc: अपाचे (उदाहरण के लिए) द्वारा इस्तेमाल कियायहाँ फेसबुक के लेख है लगभग improving jemalloc। वर्तमान शीर्ष उत्तर में होर्ड की स्मृति आवंटक यह लगभग 5 गुना तेज है :)
यह परिणाम काफी असंगत है - मैं जेसन इवांस के साथ काम करने की उम्मीद कर रहा हूं यह देखने के लिए कि वास्तव में समस्या क्या है। – EmeryBerger
@EmeryBerger: यह मुझे भी हैरान करता है, मुझे उम्मीद है कि आप इसे खोज लेंगे, अच्छी याददाश्त आवंटक तेजी से सॉफ्टवेयर बनाने के लिए पहली ईंट हैं :) –
बहुत सारे गेम यहां वर्णित कुछ स्मृति आवंटकों का उपयोग करते हैं। dlmalloc वह है जिसे हमने बड़ी सफलता के साथ उपयोग किया है (हमने इसे लुआ में बांध लिया है)। आप dlmalloc here पर जानकारी प्राप्त कर सकते हैं।
हालांकि एक और चीज जिसे मैं उल्लेख करता हूं, यह है कि सभी खेलों को गतिशील स्मृति आवंटन का उपयोग नहीं करना है। हमने अपने अधिकांश गेमप्ले डेटा के लिए मेमपूल और स्थिर मेमोरी क्षेत्रों का उपयोग किया है। केवल उन्हीं प्रणालियों जिन्हें गतिशील आवंटन की आवश्यकता होती है, ऐसा करते हैं (लुआ और कुछ तृतीय पक्ष पुस्तकालय)। बाकी सब कुछ जो हम करते हैं वह स्थिर बफर से बाहर आता है। हम गेमकोड में कोई एसटीएल का उपयोग नहीं करते हैं, जो स्मृति विखंडन के "क्षति" को सीमित करने में मदद करता है।
ध्यान दें कि कोई वास्तविक ओएस (यानी विंडोज़ को छोड़कर डेस्कटॉप/सर्वर/वर्कस्टेशन ओएस) एक का उपयोग करता है आवंटक जो एल्गोरिदमिक रूप से 'dlmalloc' के बहुत करीब है, विभिन्न * सुधार * के साथ पहले से ही है। 'Mlocococ' में छोड़कर एकमात्र सिस्टम 'मॉलोक' प्रतिस्थापन के रूप में छोड़ने से किसी भी उद्देश्य से विंडोज और शायद गेम कंसोल (कोई विचार नहीं है कि उनके पुस्तकालय कैसा दिखते हैं)। –
यह बिल्कुल सही नहीं है। लिनक्स-आधारित सिस्टम आमतौर पर ग्लिबक आवंटक का उपयोग करते हैं, जो वास्तव में dlmalloc पर आधारित है। हालांकि, विंडोज़, फ्रीबीएसडी, सोलारिस, एईक्स, और मैक ओएस एक्स सभी अलग-अलग मेमोरी आवंटकों का उपयोग करते हैं, जिनमें से कोई भी dlmalloc पर आधारित नहीं है। – EmeryBerger
मुझे लगता है कि मुझे यह स्पष्ट करना चाहिए था कि मैं गैर-वास्तविक ओएस के बारे में बात कर रहा था। व्यक्तिगत पूर्वाग्रह एक तरफ, मेरा जवाब वास्तव में खिड़कियों और कंसोल बिंदु से आ रहा था। – Mark
http://stackoverflow.com/questions/4687310/memory-allocation-patterns-in-c/4687324#4687324 –
आधुनिक सी ++ डिज़ाइन की एक प्रति प्राप्त करें। एक तेज आवंटक बनाने के लिए आपको चरणों के माध्यम से लिया जाएगा। –