2009-12-25 6 views
21

memcpy() का उपयोग करते समय स्रोत और गंतव्य ओवरलैप अपरिभाषित व्यवहार का कारण बन सकता है - उन मामलों में केवल memmove() का उपयोग किया जा सकता है।किस का उपयोग करना है - memmove() या memcpy() - जब बफर ओवरलैप नहीं होते हैं?

लेकिन अगर मुझे पता है कि बफर ओवरलैप नहीं हैं तो क्या होगा - क्या memcpy() या विशेष रूप से memmove() का उपयोग करने का कोई कारण है? मुझे किस का उपयोग करना चाहिए और क्यों?

+3

या 'std :: copy'? ;) – jalf

+0

यदि मेरा जीवन इस पर निर्भर करता है तो मैं 'std :: copy' का उपयोग नहीं करता। –

+0

@ मैट जॉइनर: क्या आप कृपया बता सकते हैं कि आप 'std :: copy() 'को इतना पसंद क्यों करते हैं? – sharptooth

उत्तर

32

एक सेन लाइब्रेरी कार्यान्वयन मानते हैं, memcpy कम से कम memmove जितना तेज़ होगा। हालांकि, अधिकांश प्लेटफॉर्म पर अंतर कम होगा, और कई प्लेटफॉर्म पर memcpy लीगसी कोड का समर्थन करने के लिए memmove के लिए केवल एक उपनाम है (गलत तरीके से) memcpy ओवरलैपिंग बफर पर कॉल करता है।

दोनों memcpy और memmove प्लेटफॉर्म पर उपलब्ध सबसे तेज़ लोड और स्टोर का लाभ उठाने के लिए लिखा जाना चाहिए।

अपने प्रश्न का उत्तर देने के लिए: आपको उस व्यक्ति का उपयोग करना चाहिए जो अर्थात् सही है। यदि आप गारंटी दे सकते हैं कि बफर ओवरलैप नहीं होते हैं, तो आपको memcpy का उपयोग करना चाहिए। यदि आप गारंटी नहीं दे सकते कि बफर ओवरलैप नहीं होते हैं, तो आपको memmove का उपयोग करना चाहिए।

+0

+1। मुझे विशेष रूप से अपने स्वयं के उत्तर के लिए "धारणात्मक साझेदार" काउंटरपॉइंट पसंद है :-) – paxdiablo

+0

नाइटपिक: प्लेटफार्म पर उपलब्ध सबसे तेज़ 'असाइन किए गए' लोड और स्टोर का लाभ उठाने के लिए 'memcpy' और' memmove' लिखा जाना चाहिए। यदि आप जानते हैं कि आपके बफर ठीक से गठबंधन हैं, तो आप अक्सर एमएमएक्स जैसी चीजों का उपयोग करके बेहतर प्रदर्शन कर सकते हैं, जो एक समय में बड़ी डेटा इकाइयों की प्रतिलिपि बनाते हैं। –

+0

@Adam: आम तौर पर बोलने वाला कोई भी उपयुक्त संरेखण प्राप्त करने के लिए कुछ छोटी इकाइयों की प्रतिलिपि बनाकर ज्ञात लोड और स्टोर को मेमकोपी में उपयोग करने की व्यवस्था कर सकता है। यदि बफर के पास समान संरेखण नहीं है, तो स्टोर करने से पहले कुछ बदलाव या परमिट लागू करना आवश्यक होगा, लेकिन यह कई आर्किटेक्चर पर अनलिखित मेमोरी एक्सेस का उपयोग करने से तेज़ है। –

29

memcpy() में ओवरलैपिंग बफर के लिए कोई विशेष हैंडलिंग नहीं है, इसलिए इसमें कुछ चेक की कमी है इसलिए यह memmove() से तेज है।

कुछ आर्किटेक्चर पर भी memcpy() स्मृति के ब्लॉक को स्थानांतरित करने के लिए CPU निर्देशों का उपयोग करने से लाभ हो सकता है - memmove() कुछ ऐसा नहीं कर सकता है।

+0

आपके संपादन ने जो कुछ कहना है, उसे +1 किया। CPU निर्देशों का उल्लेख करने के लिए – falstro

+0

+1। – MAK

+0

यहां तक ​​कि आरआईएससी आर्किटेक्चर पर, अक्सर ब्लॉक-मूव ऑपरेशंस होते हैं जिनसे memcpy() लाभ हो सकता है। उदाहरण के लिए, पावरपीसी में वीएमएक्स है। – Crashworks

5

यदि आप रुचि रखते हैं तो बेहतर प्रदर्शन करेंगे, तो आपको इसे पर लक्षित प्लेटफ़ॉर्म पर परीक्षण करने की आवश्यकता है। मानक जनादेशों में कुछ भी नहीं है कि कार्यों को कैसे कार्यान्वित किया जाता है और, जबकि यह तार्किक प्रतीत हो सकता है कि एक गैर-जांच memcpy तेज होगा, यह निश्चित रूप से निश्चित नहीं है।

यह संभव है, हालांकि संभावना नहीं है, कि जो व्यक्ति अपने विशेष संकलक के लिए memmove लिखा एक प्रमाणित प्रतिभाशाली था, जबकि गरीब आत्मा जो memcpy लिखने की नौकरी मिल गई गांव बेवकूफ :-)

था हालांकि में, हकीकत, मुझे यह कल्पना करना मुश्किल लगता है कि memmovememcpy से तेज़ हो सकता है, मैं संभावना को छूट नहीं देता हूं। उपाय, अनुमान मत लगाओ।

+1

'memcpy' के पास अपने तर्कों पर प्रतिबंध योग्यता है, न कि' memmove'। (यह वास्तव में इस तथ्य को संहिताबद्ध करता है कि बफर ओवरलैप नहीं होते हैं)। –

+0

डी ओह! आप सही हैं, ज़ाहिर है, @StephenC, मैं उन्हें चारों ओर गलत रास्ता मिला। मेरे उत्तर से उस twaddle को हटा दिया :-) – paxdiablo

2

कुछ एआरएम मंच पर काम कर रहा हूं, memmove लघु असाइन किए गए लोड के लिए memcpy से 3 गुना तेज था। चूंकि memcpy और memmove एकमात्र वास्तव में पोर्टेबल टाइप-पनिंग तंत्र हैं, तो आपने सोचा होगा कि ऐसा करने के लिए नीयन का उपयोग करने से पहले संकलक द्वारा कुछ जांच की जाएगी।

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