यादगार कार्यान्वयन और उनके प्रदर्शन के इतिहास के बारे में

void * memcpy (शून्य * गंतव्य, const शून्य * स्रोत, size_t संख्या);
ऐसा लगेगा कि जटिल है? और आप इस फ़ंक्शन के कार्यान्वयन के बारे में पूरी कहानी लिख सकते हैं।

जब मैं अपने पसंदीदा कार्य उपकरण - Vtune XE प्रोफाइलर की खिड़की को देखता हूं, तो मैं बहुत बार देखता हूं कि उसने एक बार फिर पाया कि स्मृति की नकल करने में काफी समय बिताया गया था। यह आमतौर पर लिखा जाता है: libgcc / [g] लिबक / कर्नेल मेम्कपी - XX% में खर्च की गई घड़ी की टिक।

शायद यही कारण है कि मेमसीपी अक्सर पत्राचार किया जाता है, उदाहरण के लिए, इसी तरह के धागे अक्सर एलकेएमएल में दिखाई देते हैं। (अधिक कार्यान्वयन, सबसे अधिक संभावना है, केवल सॉर्टिंग के लिए हैं)। ऐसा लगता है, छँटाई के विपरीत, जहाँ मेमोरी की नकल करने के साथ कई विकल्प और एल्गोरिदम हैं, सब कुछ सरल है। वास्तव में, भले ही हम शुद्धता के बारे में बात करते हैं और प्रदर्शन नहीं, विकल्प संभव हैं। (इसकी पुष्टि में - लिनुस टॉर्वाल्ड्स और उलरिच ड्रेपर की भागीदारी के साथ महाकाव्य बग की चर्चा )।

8086 के दिनों में, अर्थात्, चौंतीस साल पहले, मेम्पी के कार्यान्वयन के अंदर निम्नलिखित कोड था:
Mov [ई] एसआई, src
Mov [ई] डीआई, पीटीआर_डस्ट
Mov [ई] सीएक्स, लेन
रेम्स movsb
(सभी जांच, आदि इसके बाद सादगी के लिए छोड़ दिया गया)

तब से क्या बदल गया है? Kat असेंबली कोड के तहत और एक भी तस्वीर नहीं।

एग्नेर फॉग ऑप्टिमाइज़िंग असेंबली के क्लासिक काम में सबसे यादगार प्रदर्शन पहलुओं का एक अच्छा (लेकिन बहुत विस्तृत नहीं) स्पष्टीकरण है।

90 के दशक के मध्य में, प्रोग्रामर्स ने पाया कि, हालांकि नए निर्देश हमेशा इंटरनेट को गति नहीं देते हैं, आप REP MOVS की तुलना में मेमोरी को तेजी से कॉपी करने के लिए विस्तारित SIMD रजिस्टरों का उपयोग कर सकते हैं।

पहले, एमएमएक्स रजिस्टरों को मध्यवर्ती भंडारण के रूप में इस्तेमाल किया गया था, फिर एक्सएमएम। आगे देखते हुए, मैं कहूंगा कि YMM को यह नहीं मिला।
एक्सएमएम एक्सएमएम [0-4], [src] (x4, पूर्ण कैश लाइन)
Movups [dst], एक्सएमएम [0-4]

तब [un] संरेखित पढ़ना, [संरेखण], और [un] संरेखित लेखन को स्मृति के विभिन्न संयोजनों में जोड़ा गया, सबसे अच्छी स्थिति में (SSE4.1) कुछ इस तरह
mov [nt] dqa XMM2, [src + i * 2]
mov [nt] dqa XMM1, [src + i * 2 + 1]
Movdqa XMM1, XMM0
Movdqa XMM0, XMM3
palignr XMM3, XMM2, Shift
palignr XMM2, XMM1, पारी
mov [nt] dqa [dst + i * 2], XMM2
mov [nt] dqa [dst + i * 2 + 1], XMM3
थोड़ी मुश्किल यह है कि संरेखण निर्देश केवल तत्काल अंतिम ऑपरेंड (शिफ्ट) के साथ मौजूद है, इस वजह से, कोड अच्छी तरह से खिलता है (glibc देखें)। वैसे, नेह्मल वास्तुकला के साथ शुरू हुआ, असंतुलित स्मृति का उपयोग जो उपरोक्त कोड से लड़ता है, अब ब्रेक का सबसे महत्वपूर्ण कारण नहीं है, हालांकि यह मुफ़्त नहीं है।

इस प्रकार, मेमकोपी के कई कार्यान्वयन दिखाई दिए, जिनमें से प्रत्येक ने कुछ प्रोसेसर पर तेजी से काम किया, लेकिन बाकी पर धीमा। कुछ समय बाद, कई विकल्प, और कोड जो एक का चयन करता है जिसे कॉल करना है, ने अपने रास्ते को शानदार बना दिया । संभवतः CLR और JVM वातावरण भी मक्खी पर System.arraycopy के प्रभावी कार्यान्वयन को चुनने में सक्षम हैं। Glibc के विपरीत, इस तरह का SSE कोड केवल कर्नेल में फेक नहीं किया जा सकता है। यह अभी भी अधिक दिलचस्प है, आपको SIMD रजिस्टरों को सहेजने की आवश्यकता है, लेकिन यह इतना तेज़ नहीं है। लिनक्स पर क्या, विंडोज पर क्या।

और हाल ही में, अचानक, एक बार, और सब कुछ एक वर्ग में लौट आया। (हो सकता है, एवीएक्स को फिर से लिखने के लिए मजबूर करने के लिए नहीं?) नवीनतम प्रोसेसर के लिए, क्लासिक मेमसीपी कार्यान्वयन फिर से सबसे तेज है। इसलिए यदि कोई 34 साल तक देखरेख करता है, तो पुराने कोड को बाहर निकालने और सहकर्मियों पर विजयी रूप से देखने का समय है, जिन्होंने MMX, SSE2, SSE3, SSE4.1 को क्रमिक रूप से नकल की है।

वैसे, प्रतिलिपि प्रदर्शन (विशेष रूप से वास्तविक सॉफ़्टवेयर के संदर्भ में) का परीक्षण करने के लिए इसे और अधिक दिलचस्प बनाने के लिए, यह गैर-अस्थायी पढ़ने और लेखन, मेमोरी एक्सेस गति सीमा, पिछले स्तर के सामान्य कैश से संबंधित प्रभाव और DTBB को याद करने से प्रभावित हो सकता है।

निष्कर्ष।
1. एक और कार्यान्वयन लिखना अब बेकार है, एसटीडी :: मेमसीपी रेप मोल्स का उपयोग करके प्रभावी रहेगा।
2. पुराने प्लेटफार्मों पर ऐतिहासिक पृष्ठभूमि और प्रदर्शन अध्ययन के लिए, इस लेख और एग्नर फॉग को देखें।
3. एटम पर, अन्य X86 प्लेटफ़ॉर्म, और पुराने (Nezhemam से पहले) प्रोसेसर, प्रतिनिधि Mov अभी भी धीमा है।

युपीडी:
जैसा कि टिप्पणियों में बार-बार अनुरोध किया गया था, मैंने एक साधारण माइक्रोबेनमार्क को एक लूप में सभी संरेखण संयोजनों के साथ दो किलो किलोबाइट के साथ हटा दिया।
अंक - कितनी बार सबसे उन्नत SSE4.1 कोड std की तुलना में तेज है :: repc movs के माध्यम से लागू किया गया
बुलडोजर - 1.22x (डेटा के लिए stepmex के लिए धन्यवाद)
पेरीएन - 1.6x
नेहेलम - 1.5x
सैंडी ब्रिज - 1.008x
यह बेंचमार्क विशेष रूप से सटीक नहीं है, कई अन्य कारक वास्तविक सॉफ़्टवेयर में भूमिका निभाते हैं, जिन्हें मैंने ऊपर सूचीबद्ध किया है।