क्या प्रोग्रामिंग में मेमोरी मैनेजमेंट एक अप्रासंगिक चिंता का विषय है?

Question

पृष्ठभूमि
मैंने एक पुरानी (लेकिन महान) साइट पर दोबारा गौर किया, जो मैं उम्र के लिए नहीं था - एलियथ लैंग्वेज शूटआउट ( http://benchmarkgame.alioth.debian.org/ )।

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

निष्पादन समय अभी भी अपेक्षाकृत अच्छा, जावा के साथ ज्यादा से ज्यादा C / C ++ की तुलना में धीमी 4x प्रदर्शन कर रहे थे, लेकिन औसत के आसपास पर (या नीचे) 2x। जावा के कार्यान्वयन की प्रकृति के कारण, यह कोई आश्चर्य की बात नहीं थी, और यह प्रदर्शन का समय वास्तव में मेरी अपेक्षा से कम था ।

असली ईंट मेमोरी आवंटन था - सबसे खराब, जावा आवंटित:

• सी की तुलना में एक 52x अधिक स्मृति
• और सी ++ से 25x अधिक।

52x मेमोरी ... बिल्कुल गंदा, है ना? ... या यह है? मेमोरी अब तुलनात्मक रूप से सस्ती है।

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

मैं भाग में पूछ रहा हूं क्योंकि मैं अपनी प्राथमिक भाषा के रूप में स्काला की ओर पलायन पर विचार कर रहा हूं। मैं इसके कार्यात्मक पहलुओं को बहुत पसंद करता हूं, लेकिन जो मैं इसे देख सकता हूं, वह जावा की तुलना में स्मृति के मामले में और भी अधिक महंगा है। हालाँकि, लगता है कि स्मृति वर्ष तक तेज, सस्ती और अधिक बहुतायत से मिल रही है (कम से कम 4GB DDR3 RAM के बिना उपभोक्ता लैपटॉप को खोजने के लिए यह तेजी से कठिन हो रहा है), क्या यह तर्क नहीं दिया जा सकता है कि संसाधन प्रबंधन लगातार बढ़ता जा रहा है (संभवतः कार्यान्वयन-वार महंगी) उच्च-स्तरीय भाषा सुविधाओं की तुलना में अप्रासंगिक जो पठनीय समाधानों के तेजी से निर्माण की अनुमति देती है?

Comments

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

— कार्सन 63000

यदि मोबाइल विकास अप्रासंगिक है, तो हाँ की तुलना में।

— जेफ़ो

सवाल यह है कि जावा बेंचमार्क बनाम C / C ++ कितना बुरा है और दो भाषाओं के बीच चयन के संदर्भ में इसका क्या मतलब है। मैं इसे ऑन-टॉपिक के रूप में देखता हूं, जो सभी प्रोग्रामर के लिए प्रासंगिक है, स्पष्ट, केंद्रित, और इसके वर्तमान रूप में यथोचित उत्तर देने में सक्षम है। मैंने फिर से खोलने के लिए मतदान किया है।

— ग्लेनपेटर्सन

अधिकांश प्रदर्शन समस्याओं का कारण और डिज़ाइन स्तर पर तय किया जाता है, न कि उपकरण स्तर पर। कुछ समस्याओं के लिए 1ms ग्रैन्युलैरिटी की आवश्यकता होती है और इस प्रकार C / C ++ की आवश्यकता होती है। यदि आपके पास 10 किलोमीटर की तरह, लेवे है, तो शायद स्काला या जावा एक अच्छा विकल्प है। गेम के लिए अधिकांश इनपुट नियंत्रक 50-100ms के स्तर पर काम करते हैं। बहुत से लोग आज एक भाषा में महत्वपूर्ण खंड लिखते हैं और बाकी का कार्यक्रम दूसरे में।

— ग्लेनपेटर्सन

जब इस परीक्षण पर "25x C ++ से अधिक" को देखते हैं, तो किसी को रनटाइम (लगभग 3 एमबी) के निरंतर जोड़ को ध्यान में रखना होगा। जैसे-जैसे समस्या बड़ी होती है, रनटाइम मेमोरी की आवश्यकता पूरे कार्यक्रम के प्रतिशत के रूप में कम हो जाती है। जहाँ C ++ मेमोरी का उपयोग 1 MB से कम है, यदि आप जावा मेमोरी उपयोग से C ++ मेमोरी उपयोग को घटाते हैं, तो आपको काफी स्थिर मूल्य मिलेगा।

Answer 1

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

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

क्या यह अधिक सिरदर्द है? यकीन है लेकिन अगर आपको सटीक नियंत्रण की आवश्यकता है, तो आप इसके साथ जुड़ते हैं।

Comments

-1 "... सचमुच एक खेल में घातक ..." - मेरा दिन नौकरी जीवन की सुरक्षा के रूप में एक सुरक्षा महत्वपूर्ण प्रणाली है। गेम सॉफ़्टवेयर में सबसे बुरा यह है कि लेखक बस्ट हो जाता है क्योंकि उसका भद्दा और कोई नहीं खरीदता है। यह एक अंतर है जिसे तुच्छ नहीं किया जाना चाहिए।

— मटनज़

मेरी ओर से @mattnz बेचारे की पसंद इसे ठीक कर लिया गया है। किसी भी चीज को तुच्छ बनाना मेरा उद्देश्य नहीं था।

— वर्ल्ड इंजीनियर

@ मैट्टनज़: यदि आप खेलों से परिचित हैं, तो उनका स्पष्ट रूप से मतलब है कि यह आपके चरित्र के लिए घातक हो सकता है , जो कि पूरी तरह से सही कथन है।

— मेसन व्हीलर

+1 क्योंकि उत्तर देने वाले के पास एक हीरा होता है इसलिए उत्तर सही होना चाहिए।

— Psr

रीयलटाइम कचरा संग्रहकर्ता उम्र के लिए मौजूद हैं।

— जोर्ग डब्ल्यू मित्तग

Answer 2

असली ईंट मेमोरी आवंटन था - सबसे खराब, जावा ने सी की तुलना में 52x अधिक मेमोरी आवंटित की, और सी ++ की तुलना में 25 गुना अधिक।

क्या आप उन नंबरों को समझते हैं जिन्हें आप अपने प्रश्न को आधार बनाते हैं?

• कितनी मेमोरी आवंटित की गई थी?
• क्या कार्यक्रम कर रहे थे?

जब उन जावा और सी कार्यक्रमों के बीच बड़ी असमानता होती है, तो यह ज्यादातर डिफ़ॉल्ट जेवीएम मेमोरी आवंटन बनाम जो कुछ भी आवश्यक है, वे हैं:

• n- बॉडी
  जावा प्रोग्राम 13,996KB :: C प्रोग्राम 320KB :: फ्री पास्कल 8KB

उन कार्यों को देखें जिन्हें मेमोरी को आवंटित करने की आवश्यकता होती है (या मल्टीकोर कार्यक्रमों से परिणाम जमा करने के लिए अतिरिक्त बफ़र्स का उपयोग करें):

• मैंडलब्रॉट
  जावा प्रोग्राम 67 , 880KB :: सी कार्यक्रम 30 , 444KB

• k- न्यूक्लियोटाइड
  जावा प्रोग्राम 494 , 040KB :: C प्रोग्राम 153 , 452KB

• रिवर्स- सप्लीमेंट
  जावा प्रोग्राम 511 , 484KB :: C प्रोग्राम 248 , 632KB

• regex-dna
  Java प्रोग्राम 557 , 080KB :: C प्रोग्राम 289 , 088KB

• बाइनरी-ट्री
  जावा प्रोग्राम 506 , 592KB :: C प्रोग्राम 99 , 448KB

... क्या आज सामान्य प्रयोजन की भाषा चुनने पर स्मृति उपयोग एक चिंता का विषय होना चाहिए?

यह निर्भर करता है कि क्या विशिष्ट उपयोग, आपके द्वारा हल की जाने वाली विशिष्ट समस्याओं को हल करने के लिए आपके विशिष्ट दृष्टिकोण के लिए , उपयोग किए जाने वाले विशिष्ट प्लेटफॉर्म पर उपलब्ध मेमोरी की विशिष्ट सीमाओं से विवश होगा।

Comments

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

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

— gnat

Answer 3

सभी चीजों के साथ, यह एक व्यापार बंद है।

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

Answer 4

यह कई कारकों पर निर्भर करता है, खासकर जिस पैमाने पर आप काम कर रहे हैं।

बस तर्क के लिए, चलो स्मृति में 30x अंतर और CPU उपयोग में 2x मान लें।

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

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

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

Comments

नोटिंग स्केल के लिए +1। बड़े पैमाने पर संसाधन प्रबंधन को वास्तव में संतुष्ट करने के लिए इस लेख पर एक नज़र डालें ।

— गाय कोडर

Answer 5

स्मृति प्रबंधन आज की दुनिया में बिल्कुल प्रासंगिक है। हालाँकि, उस तरीके से नहीं जिस तरह आप उम्मीद कर सकते हैं। यहां तक ​​कि कचरा एकत्र की गई भाषाओं में भी आपको यह सुनिश्चित करना होगा कि आपके पास संदर्भ रिसाव न हो

यदि आपका कोड है तो आप कुछ गलत कर रहे हैं:

static List<string> Cache;

...
Cache.Add(foo); //and then never remove anything from Cache

कचरा संग्रह जादुई रूप से नहीं जान सकता है कि आप कभी भी कुछ संदर्भ का उपयोग कभी भी नहीं करेंगे जब तक आप इसे नहीं बनाते हैं ताकि आप इसे फिर से उपयोग न कर सकें , अर्थात Cache=null, आप प्रभावी रूप से कचरा संग्रहकर्ता को सतर्क करते हैं कि "अरे मैं नहीं जा पा रहा हूँ अब इसे एक्सेस करें। आप इसके साथ क्या करेंगे "

यह उससे कहीं अधिक जटिल है, लेकिन संदर्भ लीक वैसे ही हैं, जैसे पारंपरिक मेमोरी लीक की तुलना में अधिक हानिकारक नहीं हैं।

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

जब आपको गारंटीकृत प्रतिक्रिया समय की आवश्यकता होती है, तो कचरा संग्रह का उपयोग करना काफी कठिन हो जाता है। जैसे, यदि आपके पास दिल की निगरानी या कुछ है और जब यह 1कुछ पोर्ट पर प्राप्त होता है , तो आपको यह गारंटी देने की आवश्यकता है कि आप इसे उचित संकेत या 10ms के भीतर कुछ के साथ प्रतिक्रिया दे सकते हैं। यदि आपकी प्रतिक्रिया दिनचर्या के बीच में कचरा कलेक्टर को पास बनाने की आवश्यकता होती है और यह प्रतिक्रिया देने के लिए 100 मील की दूरी पर होता है, तो हो सकता है कि कोई मृत हो। कचरा संग्रह बहुत मुश्किल है, यदि असंभव नहीं है, तो उपयोग करने के लिए जब समय की आवश्यकताओं की गारंटी देने की आवश्यकता होती है।

और निश्चित रूप से, यहां तक ​​कि आधुनिक हार्डवेयर पर, कुछ मामले हैं जहां आपको कचरे के कलेक्टर के ओवरहेड के बारे में चिंता न करके अतिरिक्त 2% प्रदर्शन की आवश्यकता होती है।

Answer 6

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

कहा कि, यदि अनुकूलन समय से पहले नहीं है, तो सभी तरीकों से करें। मैं व्यक्तिगत रूप से अभी एक परियोजना पर काम कर रहा हूं, जहां मैं अपने मेमोरी उपयोग को बहुत विस्तार से समझता हूं, मुझे वास्तव में सटीक नियंत्रण की आवश्यकता है, और एक कचरा स्वीप मुझे मार देगा। इसलिए मैं इस प्रोजेक्ट को C ++ में कर रहा हूं। लेकिन यह पसंद मेरे लिए हर कई वर्षों में एक बार होने वाली घटना लगती है। (उम्मीद है कि कुछ हफ्तों में मैं कुछ और वर्षों के लिए फिर से सी ++ को नहीं छू पाऊंगा।)

Comments

यह दृष्टिकोण यह है कि हम अविश्वसनीय रूप से धीमे कंप्यूटरों पर फूला हुआ उद्यम सॉफ्टवेयर के साथ कैसे समाप्त होते हैं जो पेजिंग करते रहते हैं। हर कोई कहता है कि 'निश्चित रूप से मेरा ऐप अधिक मेमोरी लेता है, लेकिन कौन परवाह करता है, यह व्यावहारिक रूप से मुफ़्त है!' और फिर आप मेमोरी-भूखे ऐप्स के एक पूर्ण ढेर के साथ समाप्त होते हैं जो 10 साल पहले किए गए 512 एमबी रैम मशीन की तुलना में 4 जीबी रैम मशीन को धीमा बनाते हैं।

— मिरोक्स

@MrFox वास्तव में एंटरप्राइज़ सॉफ़्टवेयर के साथ समस्या यह है कि जो लोग इसका उपयोग करने का निर्णय लेते हैं, वे ऐसे लोग नहीं हैं जो इससे पीड़ित हैं। यह क्यों टूटा है के एक उत्कृष्ट विवरण के लिए lists.canonical.org/pipermail/kragen-tol/2005-April/000772.html देखें । बाकियों के लिए, क्या आपने मेरा इशारा याद किया कि स्मृति के उपयोग की चिंता कभी-कभी आवश्यक होती है?

— 21

Answer 7

"बड़े डेटा" मेमोरी प्रबंधन से निपटने वाले लोगों के लिए अभी भी एक बहुत बड़ा मुद्दा है। खगोल विज्ञान, भौतिकी, जैव सूचना विज्ञान, मशीन सीखने, आदि में कार्यक्रम, सभी को बहु-गीगाबाइट डेटासेट से निपटना पड़ता है, और यदि प्रासंगिक भागों को स्मृति में रखा जा सकता है, तो कार्यक्रम बहुत तेजी से चलते हैं। यहां तक ​​कि 128GB RAM वाली मशीन पर चलने से समस्या हल नहीं होती है।

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

Answer 8

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

यह है, IMO पूरी तरह से सार्थक और उचित व्यापार पर विचार करने के लिए। हालांकि मुझे इस बात का अफ़सोस है कि आधुनिक पीसी इतने शक्तिशाली हैं और मेमोरी इतनी सस्ती है, हम इस तरह की चिंताओं और ब्लोट फीचर्स और ब्लोट कोड को पूरी तरह से नज़रअंदाज़ कर सकते हैं और विकल्पों के बारे में आलसी हो सकते हैं जहाँ यह बहुत सारा सामान लगता है मैं अब एक विंडोज़ पीसी पर करता हूं, जब तक विंडो '95 में किया था। गंभीरता से हालांकि, शब्द? कितना नया बकवास है कि उनके उपयोगकर्ता-आधार का 80% वास्तव में 18 वर्षों में संभव हो सकता है? बहुत यकीन है कि हम पूर्व विंडोज़ सही वर्तनी था? लेकिन हम स्मृति की बात कर रहे थे जो जरूरी नहीं कि गति हो अगर आपके पास इसमें बहुत कुछ है तो मैं पचाता हूं।

लेकिन निश्चित रूप से अगर आप 2 सप्ताह में किए गए ऐप को कुछ अतिरिक्त मेगाबाइट्स की कीमत पर 2 साल के बजाय ज़रूरत-से-कुछ-के-संस्करण प्राप्त कर सकते हैं, तो यह विचार करने योग्य है कि कुछ megs कैसे तुलना करते हैं ( मैं अनुमान लगा रहा हूं) इतनी मैला होने के विचार पर उपहास करने से पहले औसत उपयोगकर्ता मशीन पर 4-12 गीगा।

लेकिन इससे व्यापार के सवाल के परे स्काला का क्या करना है? सिर्फ इसलिए कि यह कचरा संग्रह है, इसका मतलब यह नहीं है कि आपको हमेशा डेटा के प्रवाह के बारे में सोचने की कोशिश नहीं करनी चाहिए कि स्कोप और क्लोजर में क्या है और क्या इसे आसपास बैठे या इस तरह से इस्तेमाल किया जाना चाहिए कि यह हो जाएगा जब यह अब जरूरत नहीं है, तो जीसी ने डील किया। यही कुछ हमारे यहां तक ​​कि जावास्क्रिप्ट यूआई वेब देवों के बारे में भी सोचना पड़ता है और उम्मीद है कि हम आगे भी बने रहेंगे जैसे कि हम अन्य समस्या डोमेन में फैलते हैं जैसे कि perf-savvy कैंसर (कि आप सभी को फ्लैश या Applets के साथ मारना चाहिए था या कुछ और जब आपके पास मौका था) जो की हम हैं।

Answer 9

क्या प्रोग्रामिंग में मेमोरी मैनेजमेंट एक अप्रासंगिक चिंता का विषय है?

स्मृति प्रबंधन (या नियंत्रण) वास्तव में C और C ++ का उपयोग करने का प्राथमिक कारण है।

मेमोरी अब तुलनात्मक रूप से सस्ती है।

तेज याददाश्त नहीं। हम अभी भी बहुत कम संख्या में रजिस्टरों को देख रहे हैं, जैसे I1 पर L1 के लिए 32KB डेटा कैश, L2 के लिए 256KB और L3 / कोर के लिए 2MB। ने कहा कि:

यदि हम कार्यशील मेमोरी (यानी एम्बेडेड सिस्टम और इसी तरह) पर सख्त सीमा वाले लक्ष्य प्लेटफार्मों के संदर्भ में नहीं बोलते हैं, तो क्या आज सामान्य प्रयोजन की भाषा चुनने पर मेमोरी का उपयोग एक चिंता का विषय होना चाहिए?

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

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

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

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

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

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

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

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

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

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