वर्तमान में, विंडोज़ पर, जीएचसी 32-बिट जीएचसी है - मुझे लगता है कि 7.6 के आने पर विंडोज़ के लिए 64-बिट जीएचसी उपलब्ध होना चाहिए।
कि का एक परिणाम यह है कि विंडोज पर, आप, स्मृति से अधिक 4G - 1BLOCK
उपयोग नहीं कर सकते क्योंकि अधिकतम एक आकार पैरामीटर के रूप में अनुमति HS_WORD_MAX
है:
decodeSize(rts_argv[arg], 2, BLOCK_SIZE, HS_WORD_MAX)/BLOCK_SIZE;
के साथ 32-बिट शब्द
, HS_WORD_MAX = 2^32-1
।
बताते हैं कि ./mem चल रहा है।exe 42000000 + आरटीएस -M4G साथ -M4G त्रुटियों -s: आकार के बाहर अनुमत श्रेणी
decodeSize()
के बाद से 4G
2^32
के रूप में डीकोड।
यह सीमा आपके जीएचसी को अपग्रेड करने के बाद भी रहेगी, अंततः विंडोज़ के लिए 64-बिट जीएचसी जारी होने तक।
32-बिट प्रक्रिया के रूप में, उपयोगकर्ता-मोड वर्चुअल एड्रेस स्पेस 2 या 4 जीबी तक सीमित है (IMAGE_FILE_LARGE_ADDRESS_AWARE
ध्वज की स्थिति के आधार पर), सीएफ Memory limits for Windows Releases।
अब, आप Set
बनाने की कोशिश कर रहे हैं जिसमें 42 मिलियन 4-बाइट Int
एस है। Data.Set.Set
में प्रति तत्व ओवरहेड (कन्स्ट्रक्टर, आकार, बाएं और दाएं उपट्री पॉइंटर, तत्व के सूचक) के पांच शब्द हैं, इसलिए Set
लगभग 0.94 जीबीबी मेमोरी (1.008 'मीट्रिक' जीबी) लेगा। लेकिन प्रक्रिया दो या उससे अधिक के बारे में उपयोग करती है (इसे कचरा संग्रह के लिए जगह की आवश्यकता होती है, कम से कम लाइव ढेर का आकार)।
मेरी 64-बिट लिनक्स पर कार्यक्रम चल रहा है, इनपुट 21,000,000 के साथ, मैं
$ ./mem +RTS -s -RTS 21000000
min: 0
max: 21000000
31,330,814,200 bytes allocated in the heap
4,708,535,032 bytes copied during GC
1,157,426,280 bytes maximum residency (12 sample(s))
13,669,312 bytes maximum slop
2261 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 59971 colls, 0 par 2.73s 2.73s 0.0000s 0.0003s
Gen 1 12 colls, 0 par 3.31s 10.38s 0.8654s 8.8131s
INIT time 0.00s ( 0.00s elapsed)
MUT time 12.12s (13.33s elapsed)
GC time 6.03s (13.12s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 18.15s (26.45s elapsed)
%GC time 33.2% (49.6% elapsed)
Alloc rate 2,584,429,494 bytes per MUT second
Productivity 66.8% of total user, 45.8% of total elapsed
लेकिन top
रिपोर्ट प्राप्त स्मृति के केवल 1.1g
(दो बार के रूप में बड़े Int
और संकेत के लिए साइन अप करने के लिए) उपयोग करें - top
, और संभावित रूप से टास्क मैनेजर, केवल लाइव हीप की रिपोर्ट करता है।
तो यह IMAGE_FILE_LARGE_ADDRESS_AWARE
सेट नहीं है लगता है अपनी प्रक्रिया 2GB का एक पता स्थान तक ही सीमित है, और 42 लाख Set
कि अधिक से अधिक की जरूरत है - जब तक आप एक अधिकतम या सुझाव ढेर आकार कि है छोटे निर्दिष्ट करें:
$ ./mem +RTS -s -M1800M -RTS 21000000
min: 0
max: 21000000
31,330,814,200 bytes allocated in the heap
3,551,201,872 bytes copied during GC
1,157,426,280 bytes maximum residency (12 sample(s))
13,669,312 bytes maximum slop
1154 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 59971 colls, 0 par 2.70s 2.70s 0.0000s 0.0002s
Gen 1 12 colls, 0 par 4.23s 4.85s 0.4043s 3.3144s
INIT time 0.00s ( 0.00s elapsed)
MUT time 11.99s (12.00s elapsed)
GC time 6.93s ( 7.55s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 18.93s (19.56s elapsed)
%GC time 36.6% (38.6% elapsed)
Alloc rate 2,611,793,025 bytes per MUT second
Productivity 63.4% of total user, 61.3% of total elapsed
क्या यह स्वाभाविक रूप से प्रयोग करेंगे नीचे अधिक से अधिक ढेर आकार की स्थापना, वास्तव में यह Set
के लिए आवश्यक स्थान की तुलना में शायद ही अधिक में फिट की सुविधा देता है, एक थोड़ा लंबा जीसी समय की कीमत पर, और -H1800M
के एक ढेर आकार का सुझाव दे इसे पूरा करने देता है केवल
1831 MB total memory in use (0 MB lost due to fragmentation)
का उपयोग करना
तो यदि आप 2 जीबी से नीचे अधिकतम ढेर आकार निर्दिष्ट करते हैं (लेकिन Set
फिट करने के लिए काफी बड़ा है), तो यह काम करना चाहिए।
कृपया जीएचसी के एक नवीनतम संस्करण में अपग्रेड करें। क्या आपके पास अपनी विंडोज मशीन पर अधिकतम प्रक्रिया सीमा सेट है? जीएचसी की कोई ढेर सीमा नहीं है, इसलिए ओएस आपकी प्रक्रिया पता स्थान को सीमित कर सकता है। –
यदि आप हास्केल प्लेटफ़ॉर्म का उपयोग करने के आराम क्षेत्र को छोड़ना नहीं चाहते हैं, तो ध्यान दें कि अगला संस्करण इस महीने रिलीज़ होने के कारण है; पिछली बार मैंने जांच की थी कि इसमें जीएचसी 7.4.1 शामिल होगा। – dave4420