अस्वीकरण: मैं इस प्रश्न की वर्बसिटी के लिए क्षमा चाहता हूं (मुझे लगता है कि यह एक दिलचस्प समस्या है, हालांकि!), फिर भी मैं यह नहीं समझ सकता अधिक संक्षेप में यह शब्द।64 बिट (या 32 बिट) पर 32 बिट प्रक्रिया में 2,3,4 जीबी फ़ाइलें एक्सेस करना
मैं अनुसंधान के घंटे किया है के रूप में जाहिरा तौर पर जिन तरीकों से विंडोज 7 64 बिट पर एक 32 बिट प्रक्रिया में बहु जीबी फ़ाइलों तक पहुँचने, /LARGEADDRESSAWARE से VirtualAllocEx एडब्ल्यूई को लेकर की समस्या को हल करने के लिए के असंख्य। मैं विंडोज़ (CreateFileMapping, MapViewOfFile, आदि) में एक बहु-दृश्य मेमोरी-मैप किए गए सिस्टम को लिखने में कुछ हद तक सहज हूं, फिर भी इस समस्या के लिए एक और अधिक सुरुचिपूर्ण समाधान है कि इस भावना से काफी बच नहीं सकता है। इसके अलावा, मुझे बूस्ट के इंटरप्रोसेस और आईस्ट्रीम टेम्पलेट्स के बारे में काफी जानकारी है, हालांकि वे हल्के वजन के रूप में दिखाई देते हैं, केवल विंडोज एपीआई कॉल का उपयोग करने वाली प्रणाली लिखने के लिए समान प्रयास की आवश्यकता होती है (इस तथ्य का जिक्र नहीं है कि मेरे पास पहले से ही एक स्मृति- विंडोज एपीआई कॉल का उपयोग कर मैप किए गए आर्किटेक्चर अर्ध-कार्यान्वित)।
मैं बड़े डेटासेट को संसाधित करने का प्रयास कर रहा हूं। कार्यक्रम पूर्व-संकलित 32 बिट पुस्तकालयों पर निर्भर करता है, यही कारण है कि, इस पल के लिए, प्रोग्राम 64 बिट की प्रक्रिया में भी चल रहा है, भले ही सिस्टम 64 बिट ओएस के साथ 64 बिट है। मुझे पता है कि ऐसे तरीके हैं जिनमें मैं इसके चारों ओर रैपर पुस्तकालय जोड़ सकता हूं, फिर भी, क्योंकि यह एक बड़े कोडेबेस का हिस्सा है, यह वास्तव में एक उपक्रम होगा। मैंने बाइनरी हेडर को /LARGEADDRESSAWARE (मेरे कर्नेल स्पेस को कम करने की कीमत पर) की अनुमति देने के लिए सेट किया है, जैसे कि मैं प्रति प्रक्रिया लगभग 2-3 जीबी एड्रेस करने योग्य मेमोरी तक पहुंचता हूं, देता हूं या लेता हूं (ढेर विखंडन आदि के आधार पर) ।
यहां समस्या है: डेटासेट 4 + जीबी हैं, और उनके पास डीएसपी एल्गोरिदम चलते हैं जिन्हें फ़ाइल में अनिवार्य रूप से यादृच्छिक पहुंच की आवश्यकता होती है। फ़ाइल से उत्पन्न ऑब्जेक्ट के लिए पॉइंटर को सी # में संभाला जाता है, फिर भी फ़ाइल को सी ++ (यह पी/इनवॉक्ड) में स्मृति (इस आंशिक मेमोरी-मैप किए गए सिस्टम के साथ) में लोड किया जाता है। इस प्रकार, मेरा मानना है कि समाधान दुर्भाग्य से फ़ाइल के उस हिस्से तक पहुंचने के लिए खिड़की को समायोजित करने के रूप में सरल नहीं है जिसे मुझे एक्सेस करने की आवश्यकता है, क्योंकि अनिवार्य रूप से मैं अभी भी पूरी फाइल को एक सूचक में सारणीबद्ध करना चाहता हूं, जिससे मैं विधियों को कॉल कर सकता हूं फ़ाइल में लगभग कहीं भी डेटा तक पहुंचने के लिए।
जाहिर है, अधिकांश मेमोरी मैप किए गए आर्किटेक्चर एकवचन प्रक्रिया को कई प्रक्रियाओं में विभाजित करने पर भरोसा करते हैं .. इसलिए, उदाहरण के लिए, मैं 3 जी प्रक्रियाओं के साथ 6 जीबी फ़ाइल तक पहुंचूंगा, प्रत्येक में फ़ाइल में 2 जीबी विंडो होगी। इसके बाद मुझे इन विभिन्न विंडोज़/प्रक्रियाओं से डेटा खींचने और पुनः संयोजित करने के लिए तर्क की एक महत्वपूर्ण मात्रा जोड़ने की आवश्यकता होगी। VirtualAllocEx स्पष्ट रूप से आभासी पता स्थान को बढ़ाने की एक विधि प्रदान करता है, लेकिन मुझे अभी भी पूरी तरह से यकीन नहीं है कि यह इसके बारे में जाने का सबसे अच्छा तरीका है।
लेकिन, मान लीजिए कि मैं चाहता हूं कि यह प्रोग्राम 64 बिट सिस्टम पर एकवचन 64 बिट प्रोसेस के रूप में "आसानी से" के रूप में कार्य करे। मान लीजिए कि मुझे थ्रैशिंग की परवाह नहीं है, मैं सिर्फ सिस्टम पर एक बड़ी फाइल में हेरफेर करने में सक्षम होना चाहता हूं, भले ही, केवल 500 एमबी भौतिक रैम में किसी भी समय लोड हो। हाथ से कुछ हद तक हास्यास्पद, मैनुअल मेमोरी सिस्टम लिखने के बिना इस कार्यक्षमता को प्राप्त करने का कोई तरीका है? या, एसओ और इंटरनेट को जोड़कर इस प्रकार के माध्यम से जो कुछ मिला है उससे कहीं बेहतर तरीका है?
यह खुद को एक माध्यमिक प्रश्न के लिए उधार देता है: क्या इस प्रक्रिया से कितनी भौतिक रैम का उपयोग किया जाएगा सीमित करने का एक तरीका है? उदाहरण के लिए, क्या होगा यदि मैं किसी भी समय भौतिक RAM में 500 एमबी लोड होने की प्रक्रिया को सीमित करना चाहता था (जबकि डिस्क पर बहु-जीबी फ़ाइल को व्यवस्थित रखते हुए)?
मुझे लंबे प्रश्न के लिए खेद है, लेकिन मुझे लगता है कि यह बहुत अच्छा प्रश्न है (केवल आंशिक उत्तरों के साथ) जो कि मैंने एसओ और नेट पर पाया है, का एक अच्छा सारांश है। मुझे आशा है कि यह एक ऐसा क्षेत्र हो सकता है जहां एक निश्चित उत्तर (या कम से कम कुछ पेशेवर/विपक्ष) को बाहर निकाला जा सके, और हम सभी प्रक्रिया में कुछ मूल्यवान सीख सकते हैं!
tl; डॉ, लेकिन यदि आप बाहरी पुस्तकालय का उपयोग करना चाहते हैं: क्यूटी "बड़ी फाइलें" क्रॉस प्लेटफ़ॉर्म को संभाल सकता है, हालांकि मेमोरी मैप नहीं किया गया है (32 बिट प्लेटफ़ॉर्म पर)। लेकिन यह एक आंतरिक आईओ कैश का उपयोग करता है जो * तुलनात्मक प्रदर्शन तक पहुंच सकता है? – leemes
टिप्पणी के लिए धन्यवाद, लीम (भले ही टीएल; डॉ कहने के लिए एक कठोर बात है> _> ;;)! मैंने एक आंतरिक आईओ कैश का उपयोग करने में देखा है, लेकिन ऐसा लगता है कि जटिलता की उचित मात्रा शुरू करने की तरह लगता है, जो मैं बचने की कोशिश कर रहा हूं। साथ ही, मैं अतिरिक्त पुस्तकालयों जैसे कि क्यूटी टू मिक्स (बूस्ट पहले से ही एकीकृत है) जोड़ने से बचना चाहता हूं, –
रैम सीमित करना, आप विंडोज़ जॉब ऑब्जेक्ट का उपयोग कर सकते हैं और वर्किंग सेट को सीमित कर सकते हैं, जो भौतिक रैम को सीमित कर रहा है। दुर्भाग्य से मुझे लगता है कि यह केवल स्वैपिंग को अधिकतम करेगा, इसलिए यह संभवतः आप नहीं चाहते हैं। मैं आपको स्मृति मैप की गई फ़ाइलों के बारे में भी जानता हूं और वे आपकी आवश्यकताओं के अनुरूप नहीं हैं। –