2010-10-14 13 views
7

मैंने बनाया एक अजगर कार्यक्रम आईओ बाध्य है। अधिकांश समय (9 0% से अधिक) एक लूप में बिताया जाता है जो ~ 10,000 बार दोहराता है। इस लूप में, ~ 100 केबी डेटा उत्पन्न होता है और अस्थायी फ़ाइल में लिखा जाता है; फिर इसे एकत्र किए गए डेटा के बारे में किसी अन्य कार्यक्रम और आंकड़ों द्वारा वापस पढ़ा जाता है। दूसरे कार्यक्रम में डेटा पास करने का यही एकमात्र तरीका है।डिस्क से RAMdisk धीमी है?

यह मुख्य बाधा होने के कारण, मैंने सोचा कि अस्थायी फ़ाइल के स्थान को मेरे मुख्य एचडीडी से (~ 40 एमबी) रैमडिस्क (2 जीबी से अधिक रैम के अंदर) में स्थानांतरित करने के लिए आईओ गति में काफी वृद्धि होगी फ़ाइल और इसलिए रन-टाइम को कम करें।

  • टेस्ट डेटा: 1: - 72.7s, रैमडिस्क के साथ - रैमडिस्क बिना 78.6s
  • टेस्ट डेटा 2: लेकिन, मैं निम्नलिखित परिणाम प्राप्त (प्रत्येक 20 से अधिक रन औसत) रैमडिस्क बिना - 223.0s के साथ, रैमडिस्क - 235.1s

ऐसा लगता है कि रैमडिस्क धीमा है कि मेरा एचडीडी।

इसका कारण क्या हो सकता है?

क्या तेजी से फ़ाइल IO प्राप्त करने के लिए रैमडिस्क का उपयोग करने का कोई अन्य विकल्प है?

उत्तर

3

आपका ऑपरेटिंग सिस्टम लगभग निश्चित रूप से बफरिंग/कैशिंग डिस्क लिख रहा है। यह आश्चर्य की बात नहीं है कि रैम डिस्क प्रदर्शन में बहुत करीब है।

यह जानने के बिना कि आप वास्तव में क्या लिख ​​रहे हैं या कैसे, हम केवल सामान्य सुझाव दे सकते हैं। कुछ विचार:

  • आप 2 जीबी रैम है, तो आप शायद एक सभ्य प्रोसेसर, ताकि आप एक फाइल सिस्टम संपीड़न है कि इस डेटा लिख ​​सकते हैं। यह CPU समय के लिए I/O संचालन का व्यापार करेगा, मानते हुए कि आपका डेटा उसमें सक्षम है।

  • यदि आप कई छोटे लिखते हैं, तो उन्हें एक साथ बड़े टुकड़े लिखने के लिए संयोजित करें। (क्या हम स्रोत कोड देख सकते हैं?)

  • क्या आप उपयोग के बाद 100 KB फ़ाइल हटा रहे हैं? अगर आपको इसकी आवश्यकता नहीं है, तो इसे हटा दें। अन्यथा ओएस को डिस्क पर फ्लश करने के लिए मजबूर किया जा सकता है।

2

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

मैं पहले डिस्क लिखने को अनुकूलित करने पर विचार करता हूं, और फिर पूर्ण होने पर तेज़ डिस्क को देखता हूं।

+0

बिंदु यह है कि वह अब शुद्ध रैम का उपयोग कर रहा है - यहां तक ​​कि एक डिस्क भी नहीं। सभी उम्मीदों से, उन्हें बाजार पर सबसे तेज़ एसएसडी की तुलना में बेहतर प्रदर्शन करना चाहिए - फिर भी यह एक यांत्रिक ड्राइव से धीमा है। वह पूछ रहा है कि ऐसा क्यों हो सकता है। – Arafangion

+0

हां मैं इसकी सराहना करता हूं। मैं सुझाव दे रहा था कि शायद यह डिस्क नहीं है जिस तरह डिस्क का उपयोग किया जाता है, यह समस्या है। –

+1

अराफांगियन: यह विचार है कि "राम = इलेक्ट्रॉनिक, डिस्क = मैकेनिकल" वास्तव में और सच नहीं है। मेमोरी पेजों को डिस्क पर प्रतिलिपि बनाने के लिए आपका ओएस स्वागत है जब इसे (RAM -> मैकेनिकल) की आवश्यकता होती है, या स्मृति में कैश फाइलें (डिस्क -> इलेक्ट्रॉनिक) चाहती हैं। गंदे पृष्ठ (कोड, डेटा, या फाइलें) केवल एक यांत्रिक प्लेटर पर फंस जाते हैं जब इसे किसी चीज़ के लिए रैम की आवश्यकता होती है। – Ken

2

मुझे पता है कि विंडोज रैम में डिस्क डेटा कैशिंग के बारे में बहुत आक्रामक है, और 100K आसानी से फिट होगा। लिखने सीधे कैश करने जा रहे हैं और फिर शायद एक गैर-अवरुद्ध लेखन के माध्यम से डिस्क पर लिखा जा रहा है, जो प्रोग्राम को जारी रखने की अनुमति देता है। रैम डिस्क शायद गैर-अवरुद्ध संचालन का समर्थन नहीं करेगी क्योंकि यह अपेक्षा करता है कि उन परिचालनों को जल्दी और परेशान करने योग्य नहीं है।

प्रोग्राम और कैशिंग के लिए उपलब्ध स्मृति की मात्रा को कम करके, आप केवल कुछ ही होने पर भी पेजिंग के लिए डिस्क I/O की मात्रा बढ़ाने जा रहे हैं।

यह मेरे हिस्से पर सभी अटकलें हैं, क्योंकि मैं कर्नेल या ड्राइवर से परिचित नहीं हूं।मैं यह भी अनुमान लगाता हूं कि लिनक्स इसी तरह काम करेगा।

0

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

0

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

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