जो स्मृति, स्याही या वर्णों में तेज़ है? और फ़ाइल मैपिंग या खंड पढ़ने?

Question

ठीक है, इसलिए मैंने जेपीईजी को छवियों को एन्कोड करने से पहले एक (बल्कि अप्रचलित) प्रोग्राम लिखा है, हालांकि, अब मैं एमपीईजी -2 परिवहन धाराओं और उनके भीतर एच .264 एन्कोडेड वीडियो के साथ काम कर रहा हूं। इससे पहले कि मैं यह सब प्रोग्रामिंग में कूदूं, मैं उत्सुक हूं कि वास्तविक फ़ाइल से निपटने का सबसे तेज़ तरीका क्या है।

वर्तमान में मैं इस पर काम करने के लिए .mts फ़ाइल को मेमोरी में फ़ाइल मैपिंग कर रहा हूं, हालांकि मुझे यकीन नहीं है कि यह तेजी से होगा (उदाहरण के लिए) फ़ाइल में 100 एमबी फाइलों को स्मृति में याद रखें और इसके साथ सौदा करें उस तरफ।

इन फ़ाइलों को बहुत सी चीजें बदलने की आवश्यकता होती है और झंडे पढ़ने के लिए, इसलिए मुझे आश्चर्य है कि जब मैं कुछ स्मृति को संदर्भित करता हूं तो यह एक बार के रूप में एक पूर्णांक या 1 बाइट के रूप में 4 बाइट पढ़ने के लिए तेज़ होता है । मैंने सोचा कि मैंने कहीं पढ़ा है कि x86 प्रोसेसर को 4-बाइट ग्रैन्युलरिटी के लिए अनुकूलित किया गया है, लेकिन मुझे यकीन नहीं है कि यह सच है ...

धन्यवाद!

Answer 1

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

मैप किए गए फ़ाइलों के साथ आपको प्राप्त होने वाला मुख्य लाभ यह है कि आप फ़ाइल पर स्मृति में काम कर सकते हैं, जबकि यह अभी भी ओ/एस द्वारा डिस्क से पढ़ा जा रहा है, और आपको अपना लॉकिंग/थ्रेडेड फ़ाइल रीडिंग कोड प्रबंधित करने की आवश्यकता नहीं है।

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

यदि आप एच 2264 या एमपीईजी 2 एन्कोडिंग कर रहे हैं तो बाधाएं शायद किसी भी मामले में डिस्क I/o की बजाय CPU समय होने जा रही हैं।

Answer 2

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

हां, 4-बाइट (या यहां तक ​​कि 8-बाइट) ग्रैन्युलरिटी पर मेमोरी एक्सेस करना बाइट-वार तक पहुंचने से तेज़ है। फिर यह एक समझौता है - इसके बाद आपको डेटा के साथ क्या करना है, और एक int में बिट्स के साथ झुकाव करने के लिए आप कितने कुशल हैं, यह समग्र रूप से तेज़ नहीं हो सकता है।

सब कुछ के लिए के रूप में अनुकूलन के बारे में:

1. उपाय
2. अनुकूलन
3. उपाय

Answer 3

सबसे अच्छा आकार के बारे में स्मृति से पढ़ने के लिए, मुझे यकीन है कि आप this post पढ़ने का आनंद लें जाएगा मेमोरी एक्सेस प्रदर्शन और कैश प्रभाव के बारे में।

Answer 4

ये अनुक्रमिक बिट-स्ट्रीम हैं - आप मूल रूप से बिना किसी यादृच्छिक-पहुंच के उन्हें एक बिट का उपभोग करते हैं।

आपको स्पष्ट रूप से बफरिंग पढ़ने और इस परिदृश्य में बहुत प्रयास करने की आवश्यकता नहीं है: ऑपरेटिंग सिस्टम उन्हें आपके लिए भी बफर करेगा। मैंने पहले H.264 पार्सर्स लिखे हैं, और समय पूरी तरह से डीकोडिंग और हेरफेर का प्रभुत्व है, आईओ नहीं।

मेरी सिफारिश मानक पुस्तकालय का उपयोग करना और इन बिट-स्ट्रीम को पार्स करने के लिए है।

Flavor इस तरह के एक पार्सर है, और वेबसाइट भी एमपीईजी -2 (पी एस) और एम सांकेतिक शब्दों में बदलनेवाला जैसे विभिन्न 264 भागों के उदाहरण भी शामिल है। स्वाद एक सी ++ - भाषा की तरह देशी पार्सिंग कोड बनाता है; स्मृति-मानचित्रण फ़ाइलों के बारे में विचार करने के लिए

class TargetBackgroundGridDescriptor extends BaseProgramDescriptor : unsigned int(8) tag = 7 
{ 
    unsigned int(14) horizontal_size; 
    unsigned int(14) vertical_size; 
    unsigned int(4) aspect_ratio_information; 
} 

class VideoWindowDescriptor extends BaseProgramDescriptor : unsigned int(8) tag = 8 
{ 
    unsigned int(14) horizontal_offset; 
    unsigned int(14) vertical_offset; 
    unsigned int(4) window_priority; 
} 

Answer 5

एक चीज़ जो उपलब्ध पता श्रेणी से अधिक आकार के साथ एक फ़ाइल केवल के एक हिस्से के नक्शे होने के लिए सक्षम हो जाएगा है: यहाँ एमपीईजी -2 पी एस कल्पना से एक उद्धरण फ़ाइल। फ़ाइल के शेष भाग तक पहुंचने के लिए पहले भाग को अनैप किया जाना चाहिए और अगले भाग को इसके स्थान पर मैप करने की आवश्यकता है।

चूंकि आप एमपीईजी धाराओं को डीकोड कर रहे हैं, इसलिए आप एसिंक्रोनस फ़ाइल पढ़ने के साथ एक डबल buffered दृष्टिकोण का उपयोग करना चाह सकते हैं। यह इस तरह काम करता है:

blocksize = 65536 bytes (or whatever) 
currentblock = new byte [blocksize] 
nextblock = new byte [blocksize] 
read currentblock 
while processing 
    asynchronously read nextblock 
    parse currentblock 
    wait for asynchronous read to complete 
    swap nextblock and currentblock 
endwhile