वृद्धि वेक्टर तत्व

किस स्थिति में std :: वेक्टर तत्व तेजी से बढ़ेंगे - यदि वे प्रकार uint8_t या uint32tt हैं ?

अमूर्त रूप से तर्क न करने के लिए, हम दो विशिष्ट कार्यान्वयनों पर विचार करते हैं:

void vector8_inc(std::vector<uint8_t>& v) { for (size_t i = 0; i < v.size(); i++) { v[i]++; } } void vector32_inc(std::vector<uint32_t>& v) { for (size_t i = 0; i < v.size(); i++) { v[i]++; } } 

आइए अनुमान लगाने की कोशिश करते हैं

बेंचमार्क का उपयोग करके इस प्रश्न का उत्तर देना आसान है, और थोड़ी देर बाद हम ऐसा करेंगे, लेकिन पहले हम अनुमान लगाने की कोशिश करेंगे (इसे "मूल सिद्धांतों पर आधारित तर्क" कहा जाता है - यह अधिक वैज्ञानिक लगता है)।

सबसे पहले, यह एक सवाल पूछने के लायक है: इन वैक्टरों का आकार क्या है ?

अच्छा, चलो कुछ नंबर चुनें। प्रत्येक में 20,000 तत्व होने दें।

इसके अलावा, यह ज्ञात है कि हम इंटेल स्काईलेक प्रोसेसर पर परीक्षण करेंगे - हम सीधे पते के साथ 8-बिट और 32-बिट ऑपरेंड के लिए अतिरिक्त कमांड की विशेषताओं को देखेंगे। यह पता चला है कि उनके मुख्य संकेतक समान हैं: प्रति चक्र 1 ऑपरेशन और 4 साइकिल प्रति मेमोरी एक्सेस (1) की देरी। इस मामले में, देरी से कोई फर्क नहीं पड़ता है, क्योंकि प्रत्येक अतिरिक्त ऑपरेशन स्वतंत्र रूप से किया जाता है, ताकि गणना की गई गति 1 तत्व प्रति चक्र हो, बशर्ते कि लूप पर शेष सभी काम समानांतर में किए जाएंगे।

आप यह भी देख सकते हैं कि 20,000 आइटम uint8_t के साथ संस्करण के लिए 20 Kbyte डेटासेट के अनुरूप हैं और uint32_t के साथ संस्करण के लिए 80 Kbytes हैं। पहले मामले में, वे आदर्श रूप से आधुनिक x86- आधारित कंप्यूटरों के L1 स्तर कैश में फिट होते हैं, और दूसरे में - नहीं। यह पता चला है कि 8-बिट संस्करण कुशल कैशिंग के कारण हेड स्टार्ट मिलेगा?

अंत में, हम ध्यान दें कि हमारा कार्य स्वचालित वैश्वीकरण के क्लासिक मामले के समान है: लूप में पुनरावृत्तियों की एक ज्ञात संख्या के साथ, स्मृति में क्रमिक रूप से स्थित तत्वों पर एक अंकगणितीय ऑपरेशन किया जाता है। इस स्थिति में, 8-बिट संस्करण को 32-बिट संस्करण पर एक जबरदस्त लाभ होना चाहिए, क्योंकि एक वेक्टर ऑपरेशन चार बार कई तत्वों की प्रक्रिया करेगा और सामान्य रूप से इंटेल प्रोसेसर एकल-बाइट तत्वों पर वेक्टर ऑपरेशन को उसी गति से करते हैं जैसे कि 32- बिट तत्व।

ठीक है, रूकना बंद करो। यह परीक्षण की ओर मुड़ने का समय है।

बेंचमार्क

मुझे gcc 8 पर 20,000 तत्वों के वैक्टर और निम्नलिखित अनुकूलन स्तरों के साथ 8 संकलक के लिए निम्नलिखित समय मिला है:


यह पता चलता है कि, -O1 स्तर के अपवाद के साथ, uint32_t के साथ संस्करण uint8_t के साथ संस्करण की तुलना में तेज है, और कुछ मामलों में यह महत्वपूर्ण है: -O3 स्तर पर gcc पर 5.4 गुना और -O2 और -O2 और - दोनों स्तरों पर ठीक 8 गुना। O3 । हां, std :: वेक्टर में 32-बिट पूर्णांक की वृद्धि मानक अनुकूलन सेटिंग्स के साथ लोकप्रिय संकलक पर 8-बिट पूर्णांक की वृद्धि की तुलना में आठ गुना तेज है।

हमेशा की तरह, आइए हम इस आशा में कोडांतरण सूची की ओर मुड़ें कि यह क्या हो रहा है पर प्रकाश डालेगा।

यहाँ -O2 स्तर पर gcc 8 के लिए एक सूची दी गई है, जहाँ 8-बिट संस्करण 32-बिट संस्करण (2) की तुलना में "केवल" 1.5 गुना धीमा है:

8 बिट:

 .L3: inc BYTE PTR [rdx+rax] mov rdx, QWORD PTR [rdi] inc rax mov rcx, QWORD PTR [rdi+8] sub rcx, rdx cmp rax, rcx jb .L3 

32-बिट:

 .L9: inc DWORD PTR [rax] add rax, 4 cmp rax, rdx jne .L9 

32-बिट संस्करण बिल्कुल वैसा ही दिखता है जैसा कि हम एक अविकसित (3) लूप से उम्मीद करते हैं: एक वृद्धि (4) एक पते के साथ, फिर तीन लूप नियंत्रण आदेश: रक्स जोड़ें , 4 - आगमनात्मक चर (5) का एक वेतन वृद्धि और सीएमपी और जेन कमांड के एक जोड़े लूप से बाहर निकलने और उस पर सशर्त कूदने के लिए शर्तों की जांच करना। सब कुछ बहुत अच्छा लग रहा है - तैनाती काउंटर को बढ़ाने और स्थिति की जांच करने की लागत की भरपाई करेगा, और हमारा कोड लगभग 1 घड़ी प्रति चक्र (6) तत्व की अधिकतम संभव गति तक पहुंच जाएगा, लेकिन एक ओपन-सोर्स एप्लिकेशन के लिए यह करेगा। और 8-बिट संस्करण के बारे में क्या? पते के साथ इंक कमांड के अलावा, मेमोरी से पढ़ने के लिए दो अतिरिक्त कमांड निष्पादित किए जाते हैं, साथ ही सब कमांड, जो कहीं से लिया गया है।

यहाँ टिप्पणियों के साथ एक सूची दी गई है:

8 बिट:

 .L3: inc BYTE PTR [rdx+rax] ;    v[i] mov rdx, QWORD PTR [rdi] ;  v.begin inc rax ; i++ mov rcx, QWORD PTR [rdi+8] ;  v.end sub rcx, rdx ; end - start (.. vector.size()) cmp rax, rcx ; i < size() jb .L3 ; .   i < size() 

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

तो क्या बात है? संक्षिप्त उत्तर सूचक अलियासिंग है । मैं नीचे एक विस्तृत जवाब दूंगा।

विस्तृत जवाब

सदिश v को संदर्भ से फ़ंक्शन में पास किया जाता है, जो वास्तव में, एक नकाबपोश सूचक है। कंपाइलर को अपने आकार के आकार () की गणना करने के लिए वेक्टर के :: v: start और v :: end के सदस्यों पर जाना चाहिए, और हमारे उदाहरण में, आकार () प्रत्येक पुनरावृत्ति पर गणना की जाती है। लेकिन संकलक स्रोत कोड को नेत्रहीन रूप से पालन करने के लिए बाध्य नहीं है: यह लूप के बाहर आकार () फ़ंक्शन को कॉल करने का परिणाम अच्छी तरह से ले सकता है, लेकिन केवल अगर यह सुनिश्चित हो कि कार्यक्रम के शब्दार्थ में बदलाव नहीं होगा । इस दृष्टिकोण से, लूप में एकमात्र समस्याग्रस्त स्थान वृद्धि v [i] ++ है । रिकॉर्डिंग एक अज्ञात पते पर होती है। क्या इस तरह के ऑपरेशन से आकार () का मूल्य बदल सकता है?

यदि रिकॉर्ड std :: वेक्टर <uint32_t> (यानी uint32_t * पॉइंटर द्वारा) में होता है, तो नहीं, यह आकार () मान नहीं बदल सकता है। टाइप uint32_t की वस्तुओं को लिखना केवल टाइप uint32_t की वस्तुओं को संशोधित कर सकता है, और आकार की गणना में शामिल पॉइंटर्स () में एक अलग प्रकार (8) है।

हालाँकि, uint8_t के मामले में, कम से कम लोकप्रिय संकलक (9) पर, उत्तर यह होगा: हाँ, सैद्धांतिक रूप से, आकार का मान () बदल सकता है , क्योंकि uint8_t अहस्ताक्षरित चार के लिए एक उपनाम है, और अहस्ताक्षरित चार (और चार ) प्रकार के सरणियों के प्रकार कर सकते हैं। किसी अन्य प्रकार के साथ उपनाम । इसका मतलब है कि, संकलक के अनुसार, uint8_t पॉइंटर्स पर लिखना किसी भी पते (10) पर अज्ञात मूल की मेमोरी की सामग्री को संशोधित कर सकता है। इसलिए, यह मानता है कि प्रत्येक वृद्धि ऑपरेशन v [i] ++ आकार () मान को बदल सकता है, और इसलिए लूप के प्रत्येक पुनरावृत्ति पर इसे फिर से गणना करने के लिए मजबूर किया जाता है।

हम सभी जानते हैं कि स्टैड द्वारा बताई गई मेमोरी पर लिखना :: वेक्टर कभी भी अपना आकार () नहीं बदलेगा, क्योंकि इसका अर्थ यह होगा कि वेक्टर को किसी तरह अपने ही ढेर के अंदर आवंटित किया गया था, और वह व्यावहारिक रूप से चिकन और अंडे की समस्या के लिए असंभव और (11)। लेकिन दुर्भाग्य से यह संकलक को पता नहीं है!

बाकी परिणामों के बारे में क्या?

ठीक है, हमें पता चला है कि क्यों -O2 स्तर पर uint8_ के साथ संस्करण uint32_t के संस्करण की तुलना में थोड़ा धीमा है। लेकिन विशाल अंतर की व्याख्या क्यों - 8 गुना तक - क्लैंग पर या एक ही जीसी ऑन- ओ 3 ?

यहां सब कुछ सरल है: uint32_t के मामले में , क्लैंग लूप ऑटो-वेक्टराइजेशन कर सकता है:

 .LBB1_6: ; =>This Inner Loop Header: Depth=1 vmovdqu ymm1, ymmword ptr [rax + 4*rdi] vmovdqu ymm2, ymmword ptr [rax + 4*rdi + 32] vmovdqu ymm3, ymmword ptr [rax + 4*rdi + 64] vmovdqu ymm4, ymmword ptr [rax + 4*rdi + 96] vpsubd ymm1, ymm1, ymm0 vpsubd ymm2, ymm2, ymm0 vpsubd ymm3, ymm3, ymm0 vpsubd ymm4, ymm4, ymm0 vmovdqu ymmword ptr [rax + 4*rdi], ymm1 vmovdqu ymmword ptr [rax + 4*rdi + 32], ymm2 vmovdqu ymmword ptr [rax + 4*rdi + 64], ymm3 vmovdqu ymmword ptr [rax + 4*rdi + 96], ymm4 vmovdqu ymm1, ymmword ptr [rax + 4*rdi + 128] vmovdqu ymm2, ymmword ptr [rax + 4*rdi + 160] vmovdqu ymm3, ymmword ptr [rax + 4*rdi + 192] vmovdqu ymm4, ymmword ptr [rax + 4*rdi + 224] vpsubd ymm1, ymm1, ymm0 vpsubd ymm2, ymm2, ymm0 vpsubd ymm3, ymm3, ymm0 vpsubd ymm4, ymm4, ymm0 vmovdqu ymmword ptr [rax + 4*rdi + 128], ymm1 vmovdqu ymmword ptr [rax + 4*rdi + 160], ymm2 vmovdqu ymmword ptr [rax + 4*rdi + 192], ymm3 vmovdqu ymmword ptr [rax + 4*rdi + 224], ymm4 add rdi, 64 add rsi, 2 jne .LBB1_6 

चक्र 8 बार तैनात किया गया था, और यह सामान्य रूप से अधिकतम प्रदर्शन है जो आप प्राप्त कर सकते हैं: एल 1 कैश के लिए प्रति घड़ी चक्र में एक वेक्टर (8 तत्व) (यह अब घड़ी चक्र (12) प्रति एक लिखने के संचालन की सीमा के कारण काम नहीं करेगा)।

वैश्वीकरण uint8_t के लिए नहीं किया जाता है, क्योंकि यह प्रत्येक पुनरावृत्ति पर लूप की स्थिति की जांच करने के लिए आकार () की गणना करने की आवश्यकता से बाधित है। लैग का कारण अभी भी वही है, लेकिन लैग खुद बहुत बड़ा है।

सबसे कम समय को ऑटो-वेक्टराइजेशन द्वारा समझाया गया है: gcc इसे केवल -O3 स्तर पर लागू करता है, और क्लैग डिफ़ॉल्ट रूप से -O2 और -O3 दोनों स्तरों पर लागू होता है। -Cc स्तर gcc संकलक क्लैंग की तुलना में थोड़ा धीमा कोड उत्पन्न करता है क्योंकि यह ऑटोवैक्टराइज्ड लूप का विस्तार नहीं करता है।

स्थिति को ठीक करें

हमें पता चला कि समस्या क्या है - हम इसे कैसे ठीक कर सकते हैं?

पहले, आइए एक तरह से कोशिश करते हैं, हालांकि, काम नहीं करेगा, अर्थात्, हम एक इटालियन के आधार पर एक अधिक मुहावरेदार चक्र लिखेंगे:

 for (auto i = v.begin(); i != v.end(); ++i) { (*i)++; } 

-O2 स्तर पर gcc उत्पन्न करने वाला कोड आकार () के विकल्प से थोड़ा बेहतर होगा

 .L17: add BYTE PTR [rax], 1 add rax, 1 cmp QWORD PTR [rdi+8], rax jne .L17 

दो अतिरिक्त रीड ऑपरेशंस एक में बदल गए, क्योंकि अब हम वेक्टर के अंतिम पॉइंटर की तुलना करते हैं, साइकल को आकार देने () के बजाय, एंड पॉइंटर से वेक्टर स्टार्ट पॉइंटर को घटाते हैं। निर्देशों की संख्या से, यह कोड uint32_t के साथ पकड़ा गया, क्योंकि अतिरिक्त रीड ऑपरेशन की तुलना ऑपरेशन के साथ हो गई। हालाँकि, समस्या दूर नहीं हुई है और ऑटो-वैरिएशन अभी भी अनुपलब्ध है, इसलिए uint8_t अभी भी uint32_t से काफी पीछे है - दोनों gcc और clang पर 5 गुना से अधिक जहां ऑटो-वेक्टरकरण प्रदान किया गया है।

चलो कुछ और कोशिश करते हैं। हम फिर से सफल नहीं होंगे, या यों कहें कि हमें एक और निष्क्रिय विधि मिलेगी।

इस संस्करण में, हम लूप से पहले केवल एक बार आकार () की गणना करते हैं और परिणाम को एक स्थानीय चर में डालते हैं:

 for (size_t i = 0, s = v.size(); i < s; i++) { v[i]++; } 

यह काम करने लगता है? समस्या का आकार () था , और अब हमने कंपाइलर को लूप की शुरुआत में स्थानीय चर के आकार () के परिणाम के लिए प्रतिबद्ध करने का आदेश दिया, और स्थानीय चर, जैसा कि आप जानते हैं, अन्य डेटा के साथ प्रतिच्छेद नहीं करते हैं। हमने वास्तव में वह किया जो कंपाइलर नहीं कर सका। और जो कोड उत्पन्न करेगा वह वास्तव में बेहतर होगा (मूल की तुलना में):

 .L9: mov rdx, QWORD PTR [rdi] add BYTE PTR [rdx+rax], 1 add rax, 1 cmp rax, rcx jne .L9 

केवल एक अतिरिक्त रीड ऑपरेशन है और कोई उप कमांड नहीं है। लेकिन यह अतिरिक्त कमांड ( rdx, QWORD PTR [rdi] ) क्या करता है यदि यह आकार गणना में शामिल नहीं है? यह v से डेटा () पॉइंटर को पढ़ता है!

अभिव्यक्ति v [i] को * (v.data () + i) के रूप में कार्यान्वित किया जाता है, और सदस्य डेटा द्वारा लौटाया जाता है () (और, वास्तव में, एक नियमित शुरुआत सूचक) आकार () के रूप में एक ही समस्या उत्पन्न करता है। सच है, मैंने इस ऑपरेशन को मूल संस्करण में नहीं देखा था, क्योंकि यह "मुक्त" था, क्योंकि आकार की गणना करने के लिए इसे अभी भी प्रदर्शन करना था।

थोड़ा और अधिक के साथ सहन, हम लगभग एक समाधान मिला। आपको बस हमारे लूप से निकालने की आवश्यकता है std :: वेक्टर की सामग्री पर सभी निर्भरताएं। इसका सबसे आसान तरीका यह है कि हम अपने मुहावरे को एक आइटर के साथ थोड़ा संशोधित करें:

 for (auto i = v.begin(), e = v.end(); i != e; ++i) { (*i)++; } 

अब सब कुछ नाटकीय रूप से बदल गया है (यहां हम केवल संस्करणों की तुलना uint8_t से करते हैं - एक में हम लूप से पहले एक स्थानीय चर में पुनरावृत्त अंत को बचाते हैं, दूसरे में - नहीं):


इस छोटे से बदलाव ने हमें ऑटो-वेक्टराइजेशन के साथ स्तरों पर गति में 20 गुना वृद्धि दी। इसके अलावा, uint8_t के साथ कोड सिर्फ uint32_t के साथ कोड के साथ पकड़ नहीं था - यह gcc -O3 और clang -O2 और -O3 द्वारा लगभग इसे 4 बार से आगे निकल गया, जैसा कि हमने बहुत शुरुआत में उम्मीद की थी, वैश्वीकरण पर भरोसा करते हुए: अंत में, ठीक चार बार और तत्वों को एक वेक्टर ऑपरेशन द्वारा संसाधित किया जा सकता है और हमें चार बार कम बैंडविड्थ की आवश्यकता होती है - कैश स्तर (13) की परवाह किए बिना।

यदि आप इस जगह पर पढ़ते हैं, तो आपको इस समय अपने आप को उत्साहित करना होगा:

लेकिन C ++ 11 में पेश किए गए बैंड ट्रैवर्सल के लिए लूप के बारे में क्या?

मैं आपको खुश करने के लिए जल्दबाजी करता हूं: यह काम करता है! यह, वास्तव में, वाक्यगत चीनी है, जिसके पीछे एक पुनरावृत्ति वाला हमारा संस्करण लगभग उसी रूप में छिपा हुआ है, जहां हमने लूप की शुरुआत से पहले एक स्थानीय चर में अंत सूचक को निर्धारित किया था। तो उसकी गति समान है।

अगर हमने अचानक प्राचीन गुफा समय पर वापस जाने और सी-लाइक फ़ंक्शन लिखने का फैसला किया, तो ऐसा कोड भी काम करेगा:

 void array_inc(uint8_t* a, size_t size) { for (size_t i = 0; i < size; i++) { a[i]++; } } 

यहाँ, सरणी a और आकार चर का सूचक मान से फ़ंक्शन में जाता है, इसलिए उन्हें सूचक a (14) - स्थानीय चर की तरह लिखने के परिणामस्वरूप परिवर्तित नहीं किया जा सकता है। इस कोड का प्रदर्शन पिछले विकल्पों की तरह ही है।

अंत में, संकलक पर जहां यह विकल्प उपलब्ध है, आप __restrict (15) के साथ एक वेक्टर घोषित कर सकते हैं:

 void vector8_inc_restrict(std::vector<uint8_t>& __restrict v) { for (size_t i = 0; i < v.size(); i++) { v[i]++; } } 

__Restrict कीवर्ड C ++ मानक का हिस्सा नहीं है, लेकिन C99 ( प्रतिबंधित ) के बाद से C मानक का हिस्सा है। यदि इसे संकलक में C ++ एक्सटेंशन के रूप में लागू किया जाता है, तो सबसे अधिक संभावना है कि यह सी के शब्दार्थ का पालन करेगा, सी में कोई लिंक नहीं हैं, इसलिए आप मानसिक रूप से वेक्टर के लिए एक सूचक के साथ वेक्टर के लिंक को बदल सकते हैं।

ध्यान दें कि प्रतिबंधित के पास एक सकर्मक संपत्ति नहीं है: __restrict Specier की क्रिया, जिसके साथ std :: वेक्टर घोषित किया गया है, केवल वेक्टर के सदस्यों पर ही लागू होता है, और v.data () द्वारा संदर्भित हीप क्षेत्र पर नहीं। हमारे मामले में, अधिक की आवश्यकता नहीं है, क्योंकि (स्थानीय चर के मामले में) यह संकलक को यह समझाने के लिए पर्याप्त है कि शब्द स्वयं, वेक्टर की शुरुआत और अंत की ओर इशारा करते हैं, किसी भी चीज़ के साथ प्रतिच्छेद नहीं करते हैं। प्रतिबंधित के बारे में खंड, हालांकि, अभी भी प्रासंगिक है, क्योंकि v.data () के माध्यम से लिखने के बाद भी अलियासिंग के कारण आपके फ़ंक्शन में अन्य ऑब्जेक्ट बदल सकते हैं।

निराशा

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

अलियासिंग समस्या दूर नहीं हुई है, और राइट कमांड अभी भी "कहीं भी" जा सकते हैं - इस फ़ंक्शन में बस कोई अन्य डेटा नहीं है जो अभी तक प्रभावित हो सकता है ... अभी के लिए। जैसे ही एक नया कोड इसमें दिखाई देगा, सब कुछ दोहराया जाएगा। यहाँ एक उदाहरण ऑफहैंड है । यदि आप छोटे छोरों में uint8_t प्रकार के तत्वों के सरणियों को लिखते हैं, तो आपको अंत (16) तक कंपाइलर के साथ लड़ना होगा।

टिप्पणियाँ

मुझे किसी भी प्रतिक्रिया की खुशी होगी। मेरे पास अभी तक एक टिप्पणी प्रणाली (17) नहीं है, इसलिए, हमेशा की तरह, हम हैकरन्यूज पर इस थ्रेड में चर्चा करेंगे।

1. यहां मेमोरी को एक्सेस करने से, यह समझ में आता है कि निर्भरता की श्रृंखला मेमोरी से गुजरती है: उसी पते पर कमांड लिखें, जिसे वहां लिखा गया अंतिम मान पढ़ना चाहिए, इसलिए इस तरह के ऑपरेशन निर्भर हैं (अभ्यास में, लोडिंग के लिए पुनर्निर्देशन) (एसटीएलएफ) का उपयोग किया जाएगा यदि रिकॉर्डिंग पर्याप्त है अक्सर)। स्मृति तक पहुँचने पर ऐड कमांड की निर्भरता अन्य तरीकों से हो सकती है, उदाहरण के लिए, पते की गणना करके, लेकिन हमारे मामले के लिए यह अप्रासंगिक है।
2. केवल एक छोटा सा चक्र यहाँ दिखाया गया है; स्थापना कोड सरल है और यह तेजी से काम करता है। पूरी लिस्टिंग देखने के लिए, कोड को गॉडबॉल्ट पर अपलोड करें ।
3. शायद इसे केवल "छोटा" कहा जाना चाहिए? जैसा कि यह हो सकता है, gcc संकलक आमतौर पर -O2 और -O3 स्तरों पर भी लूप नहीं करता है, विशेष मामलों को छोड़कर जहां पुनरावृत्तियों की संख्या छोटी है और संकलन चरण में जाना जाता है । इस वजह से, gcc क्लैंग की तुलना में कम परीक्षा परिणाम दिखाता है, लेकिन यह कोड आकार पर बहुत बचत करता है। आप प्रोफ़ाइल अनुकूलन लागू करने या -funroll-loops ध्वज को चालू करके लूप को अनियंत्रित करने के लिए मजबूर कर सकते हैं।
4. दरअसल, gcc में DWORD PTR [rax] कमांड एक मिस्ड ऑप्टिमाइज़ेशन है: ऐड [rax], 1 कमांड का उपयोग करना लगभग हमेशा बेहतर होता है, क्योंकि इसमें inc के लिए केवल 2 संयुक्त microoperations बनाम 3 होते हैं। इस मामले में, अंतर केवल 6% है, लेकिन यदि चक्र को थोड़ा विस्तारित किया गया था ताकि केवल रिकॉर्डिंग ऑपरेशन दोहराया जाए, तो अंतर अधिक महत्वपूर्ण होगा (आगे विस्तार अब भूमिका नहीं निभाएगा, क्योंकि हम 1 की सीमा तक पहुंच जाएंगे। प्रति चक्र रिकॉर्डिंग ऑपरेशन, जो माइक्रो-ऑपरेशन की कुल संख्या पर निर्भर नहीं करता है)।
5. मैं इस चर को आगमनात्मक कहता हूं, और सिर्फ मैं ही नहीं, स्रोत कोड के रूप में, क्योंकि कंपाइलर ने वेतन वृद्धि की इकाई संचालन को rax रजिस्टर में संग्रहीत सूचक के 4-बाइट वेतन वृद्धि में बदल दिया, और तदनुसार लूप की स्थिति को ठीक किया। अपने मूल रूप में, हमारा लूप वेक्टर के तत्वों को संबोधित करता है, और इस रूपांतरण के बाद, यह सूचक / पुनरावृत्ति को बढ़ाता है, जो संचालन की लागत को कम करने का एक तरीका है।
6. वास्तव में, यदि आप -फ्रून-लूप को सक्षम करते हैं, तो जीसीसी पर गति 8x रोल- आउट के साथ प्रति तत्व 1.08 उपाय होगी। लेकिन इस ध्वज के साथ भी, वह 8-बिट तत्वों के साथ संस्करण के लिए लूप का विस्तार नहीं करेगा , इसलिए गति में अंतराल और भी अधिक ध्यान देने योग्य होगा!
7. इन सदस्यों के पास एक निजी संशोधक है, और उनके नाम कार्यान्वयन पर निर्भर हैं, लेकिन stdlibc ++ में उन्हें वास्तव में स्टार्ट और फिनिश नहीं कहा जाता है, जैसा कि जीसीसी में है। उन्हें _Vector_base :: _ वेक्टर_impl :: _ M_start और _Vector_base :: _ वेक्टर_impl :: _ M_finish क्रमशः कहा जाता है , अर्थात। _Vector_impl संरचना दर्ज करें, जो _M__pl (और केवल एक) _Vector_base वर्ग का सदस्य है , और जो बदले में, std :: वेक्टर के लिए आधार वर्ग है। अच्छा, अच्छा! सौभाग्य से, कंपाइलर आसानी से अमूर्त के इस ढेर के साथ मुकाबला करता है।
8. मानक यह निर्धारित नहीं करता है कि std के आंतरिक प्रकार क्या हैं : वेक्टर सदस्य होने चाहिए, लेकिन libstdc ++ लाइब्रेरी में उन्हें केवल Alloc :: पॉइंटर (जहां एलोक वेक्टर के लिए एलोकेटर है) के रूप में परिभाषित किया गया है, और डिफ़ॉल्ट स्टैड :: आवंटित ऑब्जेक्ट के लिए वे बस प्रकार टी * , के संकेत एक वस्तु को नियमित संकेत - इस मामले में uint32_t * ।
9. मैं एक कारण के लिए यह आरक्षण कर रहा हूं। एक संदेह है कि uint8_t को चार , हस्ताक्षरित चार और अहस्ताक्षरित चार के अलावा एक प्रकार माना जा सकता है। चूंकि अलियासिंग चरित्र प्रकारों के साथ काम करता है, यह सिद्धांत रूप में uint8_t पर लागू नहीं होता है और इसे किसी अन्य गैर-चरित्र प्रकार की तरह व्यवहार करना चाहिए। हालाँकि, कोई भी संकलक जो मुझे पता है कि मुझे ऐसा लगता है: उन सभी में टाइप किया गया uint8_t अहस्ताक्षरित चार का एक उपनाम है, ताकि संकलक उन दोनों के बीच अंतर न देखें, भले ही वे इसका उपयोग करना चाहें।
10. "अज्ञात मूल" से मेरा तात्पर्य यहाँ केवल यह है कि संकलक को यह पता नहीं है कि मेमोरी की सामग्री कहाँ इंगित कर रही है या यह कैसे प्रकट हुई। इसमें फ़ंक्शन के लिए पारित किए गए मनमाने ढंग से पॉइंटर्स, साथ ही वैश्विक और स्थिर चर शामिल हैं। , , , , , ( - ). , malloc new , , , , : , , . , malloc new .
11. , std::vector - ? , std::vector<uint8_t> a a.data() placement new b . std::swap(a, b) , – , b ? , b . : - (, ), , .
12. 8 , .. 32 . , std::vector .
13. - 4 : , , – . : 8- L1, 32- – L2 , .
14. , – : . , , «».
15. v[i] , .
16. . , «» , uint8_t . , , , uint8_t , . , clang, gcc , , uint8_t . - gcc , . , , - __restrict .
17. - , , ( Disqus), ( ), .

. : Travis Downs. Incrementing vectors .