सी ++

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

संपादित करें: 1. बढ़ावा से :: इंटरप्रोसेस डॉक्स: "के रूप में ऑपरेटिंग सिस्टम स्मृति सामग्री के साथ फ़ाइल सामग्री सिंक्रनाइज़ करने के लिए है, स्मृति-मैप की गई फ़ाइलों के रूप में तेजी से साझा स्मृति के रूप में नहीं कर रहे हैं मैं कुछ आगे पढ़ने बनाया " 2. http://msdn.microsoft.com/en-us/library/ms810613.aspx से: " एक स्मृति-मैप की गई फ़ाइल को एक साथ एक से अधिक अनुप्रयोगों द्वारा मैप किया जा सकता है। यह विंडोज एनटी में सीधे डेटा साझा करने के लिए दो या दो से अधिक प्रक्रियाओं के लिए एकमात्र तंत्र का प्रतिनिधित्व करता है। "

स्रोत

2011-06-02 andriej

विंडोज़ में सभी मेमोरी किसी फ़ाइल द्वारा समर्थित है, जैसे वर्चुअल मेमोरी ऑपरेटिंग सिस्टम। और फ़ाइलों को स्मृति, फ़ाइल सिस्टम कैश द्वारा समर्थित किया जाता है। जिससे यह संभव हो जाता है कि आपको स्पीड-अप दिखाई नहीं देगा। यह रैम बस गति, ~ 5 जीबी/सेकंड डीडीआर 2 के लिए स्थानांतरित होना चाहिए। –

@ हंस: क्या आप कह रहे हैं कि साझा मेमोरी का उपयोग करके मुझे डेटा फ़ाइलों को सीधे डेटा फ़ाइलों की तुलना में कोई गति-अप नहीं मिलेगा? – andriej

शायद बूस्ट विंडोज साझा मेमोरी आपकी गली होगी। यह निरंतर है, अगर आप वास्तव में इसका मतलब है। http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/windows_shared_memory.html –

मुझे लगता है कि एक मौलिक गलतफहमी है कि यहाँ हैं: आपको लगता है कि, आप एक फ़ाइल मानचित्रण द्वारा समर्थित बनाते हैं पेजिंग फ़ाइल, यह वास्तव में डिस्क पर सामान लिखने के रूप में धीमी होगी।

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

इस दस्तावेज़ से वास्तव में स्पष्ट नहीं है, लेकिन MSDN पर File Mapping पेज की पुष्टि करता है:

[...] यह डिस्क पर फ़ाइल द्वारा समर्थित है। इसका अर्थ है कि जब सिस्टम फ़ाइल मैपिंग ऑब्जेक्ट के पृष्ठों को स्वैप करता है, तो फ़ाइल मैपिंग ऑब्जेक्ट में किए गए कोई भी परिवर्तन फ़ाइल में लिखे जाते हैं। जब फ़ाइल मैपिंग ऑब्जेक्ट के पृष्ठ वापस आ गए हैं, तो उन्हें फ़ाइल से पुनर्स्थापित किया जाता है।

सूचना है कि इस साझा स्मृति पेजिंग फ़ाइल का समर्थन प्राप्त करने के साथ ही स्मृति नियमित फ़ाइलों का समर्थन हासिल करने के लिए लागू होता है (VMM गारंटी देता है कि विभिन्न विचारों सुसंगत रखा जाता है)।

संयोग से, उपयोगकर्ता प्रक्रियाओं में "नियमित" (= वर्चुअल) मेमोरी कैसे काम करती है: आवंटित स्मृति की प्रत्येक बिट को पेजिंग फ़ाइल में बदल दिया जा सकता है यदि वर्तमान में इसका उपयोग नहीं किया जाता है और सिस्टम को अन्य के लिए भौतिक स्मृति का उपयोग करने की आवश्यकता है सामान (उदाहरण के लिए मेमोरी पेज बनाना जो आपके/दूसरे एप्लिकेशन पर उपलब्ध पल में उपयोग किया जाता है)।

स्रोत

2011-06-02 13:40:58

+1। – 0xC0000022L

वहाँ एक फ़ाइल से समर्थित होने के साथ कुछ भी गलत नहीं है - स्मृति दबाव में, डेटा कहीं जाने के लिए है, और अपने विकल्प हैं:

पवित्र डेटा के रूप में याद है कि पृष्ठांकित नहीं किया जा सकता का इलाज या

केवल बहुत खराब स्मृति दबाव समस्याओं को बनाने की संभावना है, लेकिन कुछ एम्बेडेड सिस्टम के लिए अच्छी पसंद है जहां सिस्टम के पूरे रनटाइम पर्यावरण को बहुत अच्छी तरह से नियंत्रित किया जा सकता है।

ड्रॉप स्मृति

जाहिर है सभी डेटा को उपयुक्त नहीं है। कैश सामग्री? शायद। मूल चित्र? शायद ऩही।

पेज डिस्क

अच्छा सामान्य चुनाव के लिए स्मृति!

क्या आप साझा-मेमोरी टूल का उपयोग करते समय मेमोरी प्रेशर देख रहे हैं? अधिक रैम जोड़ें या अपने सिस्टम को कम करने के तरीके को समझें। :)

स्रोत

2011-06-02 01:10:15 sarnold

@ कर्नाइड: आप बिंदु खो रहे हैं। मुझे बहुत परवाह नहीं है जब रैम के टुकड़े विंडोज़ द्वारा डिस्क पर लिखे जाते हैं जब बहुत अधिक मेमोरी दबाव होता है। मैं एक डिस्क फ़ाइल और रैम के बीच सिंक्रनाइज़ेशन से बचना चाहता हूं जो रैम दबाव के बावजूद होगा - और जैसा कि मैं समझता हूं कि विंडोज़ साझा की गई स्मृति को कैसे कार्यान्वित किया जाता है? – andriej

जहां तक मुझे पता है, साझा स्मृति वास्तव में केवल स्मृति दबाव के तहत पेजिंग फ़ाइल में ले जाया जाएगा, वैसे, उपयोगकर्ता प्रक्रियाओं की हर बिट स्मृति के लिए क्या होता है। –

@ user467799: हुह? फिर पृष्ठ फ़ाइल द्वारा समर्थित एमएमएफ का उपयोग करें। क्या बड़ी बात है? एनटी में पेज लेखक आलसी है। इसका अर्थ यह है कि जब यह बिल्कुल जरूरी हो तो यह केवल डिस्क पर पृष्ठों को लिख देगा (oversimplified, लेकिन करीब आता है)। तो बस इसे पसीना मत करो। पर्याप्त रैम के साथ आप कोई प्रदर्शन गिरावट नहीं देखेंगे। – 0xC0000022L

जहां तक मुझे पता है कि आपके पास अनिवार्य रूप से 2 विकल्प हैं।

1) आप एक डीएलएल बनाते हैं और data_seg pragma का उपयोग करते हैं और अपनी दोनों प्रक्रियाओं में डीएलएल लोड करते हैं। इस विशाल कमियां जो यहाँ विस्तार से वर्णन किया गया है: http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx

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

2) नियमित मेमोरी-मैप की गई फ़ाइलों का उपयोग करने में कुछ भी गलत नहीं है, हालांकि वे किसी भी तरह से कैश किए जाते हैं। http://msdn.microsoft.com/en-us/library/ms810613.aspx

मैं वास्तव में इस उदाहरण का परीक्षण [1] अंतर संचार प्रक्रिया एक 1 GiB स्मृति-मैप की गई फ़ाइल के साथ की और कहा कि कुछ भी नहीं है इस बात की पुष्टि कर सकते हैं: तुम भी इस आलेख में वर्णित के रूप में डाटा स्टोर करने सिस्टम पृष्ठ फ़ाइल उपयोग कर सकते हैं डेटा के साथ पूरे जीआईबी भरने के बाद भी डिस्क पर लिखा गया था।

[1] http://msdn.microsoft.com/en-us/library/aa366551(v=vs.85).aspx

स्रोत

2011-06-02 01:13:06 PeterT

"नियमित मेमोरी-मैप की गई फ़ाइलों का उपयोग करने में कुछ भी गलत नहीं है" - जो मैंने पढ़ा है, वे मेरी ज़रूरतों के लिए सबसे तेज़ समाधान नहीं हैं क्योंकि वे डिस्क I/O को इंगित करते हैं, जबकि पूरी तरह से रैम-आधारित साझा मेमोरी हमेशा डिस्क पर स्वैपिंग नहीं करती है । – andriej

@ user467799: असत्य। वास्तव में I/O हो सकता है, लेकिन यह पूरी तरह से कैश प्रबंधक तक है। यदि आप पेज फ़ाइल द्वारा समर्थित एमएमएफ का उपयोग करते हैं और पर्याप्त रैम है, तो मूल रूप से कोई ओवरहेड नहीं होगा। और बोनस के रूप में आपका प्रोग्राम अभी भी चल सकता है - हालांकि खराब प्रदर्शन पर - बाधित परिस्थितियों में। यदि आप ढेर मेमोरी का उपयोग करना चाहते थे, तो यह मामला नहीं होगा। – 0xC0000022L

मैं अभी भी सुझाव दिया जाएगा स्मृति मैप किए गए दृष्टिकोण मैं उल्लेख होगा बजाय फ़ाइलें।

यदि आप वास्तव में किसी अन्य प्रक्रिया मेमोरी से पढ़ना चाहते हैं, तो Win32 API ReadProcessMemory() का उपयोग करें।

आप रैम में डेटा रखने पर पागल हैं, तो यूनिक्स mlock() एमएस विंडोज में समकक्ष VirtualLock()

स्रोत

2011-06-02 13:27:07 hackworks

जैसा कि लेख में लिखा गया है "ReadProcessMemory डेटा की प्रतिलिपि बनाता है" और वास्तव में उसे साझा स्मृति नहीं देगी जो उसे वही करने की अनुमति देगी: "दूसरी प्रक्रिया उन्हें पढ़ और निकाल देगी"। उसे हटाने के लिए उसे पहली प्रक्रिया में कॉल करना होगा क्योंकि वह इसे लिख नहीं सकता है। ओपी के गलत धारणा को हल करने की कोशिश करने के लिए – PeterT

उत्तर

संबंधित मुद्दे