👩🏼‍🤝‍👩🏻 🕎 👊🏼 क्लैंग-प्रारूप कार्यक्रम को धीमा कर देता है 🚝 🐼 🧝🏼

आज हम टॉपर फ़ंक्शन के विभिन्न कार्यान्वयन के प्रदर्शन को मापेंगे, क्योंकि यह वे मंगलवार को करते हैं।

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

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

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

पहले कार्यान्वयन में, हम बस सी मानक पुस्तकालय के टॉपर [1] कार्य को कहते हैं और सी-स्टाइल लूप निष्पादित करते हैं:

void toupper_rawloop(char* buf, size_t size) { for (size_t i = 0; i < size; i++) { buf[i] = toupper(buf[i]); } }

दूसरे कार्यान्वयन में, हम कच्चे चक्र को एसटीडी के साथ बदलने के साथ एक अधिक आधुनिक दृष्टिकोण का उपयोग करते हैं :: रूपांतर :

 void toupper_transform(char* buf, size_t size) { std::transform(buf, buf + size, buf, ::toupper); }

अंत में, तीसरे कार्यान्वयन में, हम एक विशेष एल्गोरिथ्म का उपयोग करते हैं जो ASCII वर्णों के साथ काम करता है। यह जाँचता है कि चरित्र a - z में है या नहीं , और यदि सफल है, तो ऊपरी अक्षर में समान अक्षर को प्रतिस्थापित करता है, वर्ण कोड से संख्या 32 को घटाते हुए [2]:

 void toupper_branch(char* buf, size_t size) { for (size_t i = 0; i < size; i++) { char c = buf[i]; if (c >= 'a' && c <= 'z') { buf[i] = c - 32; } } }

आसान लगता है, है ना?

अब हम अपने लैपटॉप पर इन कार्यान्वयन की गति को Skylake i7-6700HQ प्रोसेसर के साथ डिफ़ॉल्ट सेटिंग्स के साथ gcc 5.5 संकलक पर मापेंगे। परिणाम तितर बितर चार्ट के रूप में दिए गए हैं [3]:

तुरंत हम तीन सवालों से निपटेंगे जो हमारे कार्य के लिए अप्रासंगिक हैं।

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

दूसरे, ऊपरी बाईं ओर हरे धब्बों के समूह पर ध्यान दें, जो टौपर_ब्रांच ब्रांचिंग के साथ संस्करण की बहुत कम गति के अनुरूप है:

यह एक अलग विरूपण साक्ष्य नहीं है: इस तरह के स्पॉट कई लॉन्च के दौरान दिखाई दिए। उसी समय, उन्हें पुन: प्रस्तुत नहीं किया जा सकता है यदि आप एल्गोरिदम का परीक्षण केवल विशेष रूप से इन डेटा आकारों पर करते हैं - वे केवल तभी पॉप अप करते हैं जब परीक्षण सभी आकारों में चलाया जाता है। लेकिन इस मामले में, वे हमेशा दिखाई नहीं देते हैं। मैंने विशेष रूप से इसमें तल्लीन नहीं किया है, लेकिन मैं यह मान सकता हूं कि यह शाखा भविष्यवाणी एल्गोरिथ्म में नाम या उपनाम के कुछ संघर्षों के कारण है या वर्चुअल करने के लिए 4 केबी के भौतिक पृष्ठों की मैपिंग करते समय (हालांकि वर्चुअल एड्रेस स्पेस का यादृच्छिककरण बंद कर दिया गया था)।

तीसरा, ग्राफ पर toupper_rawloop (नीले रंग में दिखाया गया है) का कार्यान्वयन दो अलग-अलग रेखाओं की तरह दिखता है: एक प्रति वर्ण के 2 उपायों के निशान से थोड़ा ऊपर, और दूसरा प्रति चरित्र 1.5 उपायों के स्तर पर। सभी परीक्षकों में ये दो पंक्तियाँ दिखाई दीं। प्रति चक्र 1.57 वर्णों की गति के साथ तेज विकल्प, वास्तव में डाउनलोड पोर्ट पर धीमा हो जाता है: पोर्ट 2 और 3 पर डेटा पढ़ने से प्रति चक्र 1.54 माइक्रोऑपरेशन की गति होती है, इसलिए वे 98% व्यस्त होंगे। मैं धीमी "शासन" के लिए कारण स्थापित नहीं कर सका।

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

फिर इस उदाहरण में हमें क्या दिलचस्पी है?

लेकिन हमें क्या दिलचस्पी है कि कच्चे चक्र के साथ संस्करण एसटीडी के साथ संस्करण की तुलना में 3-4 गुना तेज है :: रूपांतरण : 1.5-2 चक्र प्रति चरित्र बनाम 7 प्रति चक्र कुछ चक्रों के साथ।

यहाँ क्या मामला है? क्या मानक एल्गोरिदम ने मुझे विफल कर दिया है? एसटीडी :: परिवर्तन का कोई दोष है?

वास्तव में नहीं। अधिक सटीक, बिल्कुल नहीं।

यह पता चलता है कि ऐसे परिणाम दिखाई देते हैं जब फ़ंक्शन विभिन्न फ़ाइलों में संकलित किए जाते हैं। यदि आप उन्हें एक ही फ़ाइल में रखते हैं, तो उनका प्रदर्शन समान रूप से कम हो जाता है।

और नहीं, संरेखण का इससे कोई लेना-देना नहीं है।

लेकिन यह सब नहीं है: एक कच्चे चक्र के साथ तेजी से संस्करण, जब एक अलग फ़ाइल में संकलित किया जाता है, तो धीमा हो जाता है यदि आप बस इसे <एल्गोरिथम> हेडर फ़ाइल में संलग्न करते हैं। हां, यह सही है: बस इस फ़ाइल को कनेक्ट करें, जिसका उपयोग कभी नहीं किया जाता है और अंतिम ऑब्जेक्ट फ़ाइल में कोई कोड उत्पन्न नहीं करता है, और "कच्चे" चक्र की गति 3-4 गुना कम हो जाएगी। इसके विपरीत, एसटीडी के साथ संस्करण :: ट्रांसफ़ॉर्म को सीमा तक त्वरित किया जाता है यदि आप एसटी के कार्यान्वयन को कॉपी और पेस्ट करते हैं :: ट्रांसफॉर्मेशन <एल्गोरिथम फ़ाइल से, लेकिन इस फ़ाइल को शामिल न करें।

वेर्डनेस वहाँ समाप्त नहीं होती है (कोई और नहीं होगा, मैं वादा करता हूं): <एल्गोरिथम> फ़ाइल सहित हमेशा वर्णित प्रभाव नहीं होता है। स्पीड ड्रॉप तब होता है यदि <एल्गोरिथम> <ctype.h> की तुलना में पहले से जुड़ा हुआ है, लेकिन यदि आप उन्हें स्वैप करते हैं, तो नहीं:

धीमा कोड:

 #include <algorithm> #include <ctype.h>

त्वरित कोड:

 #include <ctype.h> #include <algorithm>

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

स्वाभाविक रूप से, हमें जल्दी या बाद में कोडांतरक की सूची में उतरना पड़ा। हम इस अप्रिय क्षण में देरी नहीं करेंगे।

कार्यों के तेज़ और धीमे संस्करण [5] नीचे दिखाए गए हैं, छोटे लूप एनोटेशन के साथ दिए गए हैं:

<एल्गोरिथम> पहले जोड़ता है:

 toupper_rawloop(char*, unsigned long): push rbp push rbx lea rbp, [rdi+rsi] sub rsp, 8 test rsi, rsi je .L1 mov rbx, rdi .L5: movsx edi, BYTE PTR [rbx] ;  char-  *buf add rbx, 1 ; buf++ call toupper ;  toupper(c) mov BYTE PTR [rbx-1], al ;    buf[-1] cmp rbp, rbx ;  buf == buf_end jne .L5 ; .L1: add rsp, 8 pop rbx pop rbp ret

<एल्गोरिथम> दूसरे से जुड़ा है:

 toupper_rawloop(char*, unsigned long): test rsi, rsi je .L7 push rbp push rbx mov rbp, rsi mov rbx, rdi sub rsp, 8 call __ctype_toupper_loc lea rsi, [rbx+rbp] mov rdi, rbx .L4: ;  char-  buf movsx rcx, BYTE PTR [rdi] ;      toupper ; (   __ctype_toupper_loc) mov rdx, QWORD PTR [rax] ; buf++ add rdi, 1 ;   toupper  , ;       mov edx, DWORD PTR [rdx+rcx*4] mov BYTE PTR [rdi-1], dl ;   cmp rsi, rdi ;  buf == end_buf jne .L4 ; add rsp, 8 pop rbx pop rbp .L7: rep ret

मुख्य अंतर यह है कि धीमे संस्करण में टॉपर फ़ंक्शन को बस एक लूप में कहा जाता है, जबकि फास्ट संस्करण में फ़ंक्शन कॉल पूरी तरह से अनुपस्थित हैं, और पत्राचार तालिका [6] में केवल एक खोज है, अर्थात एसटीडी का शरीर :: टॉपर फ़ंक्शन को कॉल के स्थान पर प्रतिस्थापित किया जाता है

यदि आप glibc लाइब्रेरी के स्रोत कोड को देखते हैं, तो हम वहां टॉपर फ़ंक्शन के कार्यान्वयन का पता लगाते हैं:

 __extern_inline int // __NTH –  , ,      __NTH (toupper (int __c)) { return __c >= -128 && __c < 256 ? (*__ctype_toupper_loc ())[__c] : __c; }

जैसा कि हम देख सकते हैं, टॉपर को एक बाहरी इनलाइन फ़ंक्शन के रूप में परिभाषित किया गया है जो पहले जांचता है कि चार-वर्ण का आकार एक बाइट [7] में फिट बैठता है, और फिर __ctype_ououou_loc () फ़ंक्शन द्वारा लौटाए गए पत्राचार तालिका में चरित्र की खोज करता है। यह फ़ंक्शन एक स्थानीय स्ट्रीम पॉइंटर (प्रकार का कॉन्स्टेंस इंट ** ) देता है, जो बदले में, एक पत्राचार तालिका की ओर इशारा करता है, जिसमें से, हमारे प्रतीक के लिए एक अनुरोध के जवाब में, इसका ऊपरी केस संस्करण वापस आ गया है [8]।

अब यह स्पष्ट है कि सूची में क्या हो रहा है। एल्गोरिथ्म के तेज संस्करण में, कंपाइलर टॉपर फ़ंक्शन के शरीर को प्रतिस्थापित करता है, लेकिन कॉल को __ctype_toupper_loc () फ़ंक्शन [9] में स्थानापन्न नहीं कर सकता है। हालाँकि, इस कॉल को __attribute __ ((const)) के रूप में घोषित किया गया है, जिसका अर्थ है कि वापसी मूल्य केवल तर्कों (जो यहाँ नहीं हैं) पर निर्भर करता है। कंपाइलर जानता है कि यह फ़ंक्शन हर बार एक ही मान लौटाता है, और इसलिए लूप के बाहर इसकी कॉल लेता है, और लूप में ही पत्राचार तालिका तक पहुंचने, बफर को एक नया मान लिखने और लूप नियंत्रण से जुड़े कुछ ही पढ़ने के संचालन होते हैं।

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

  lea edx,[rdi+0x80] ; edx = rdi + 0x80 movsxd rax,edi ;    c cmp edx,0x17f ; ,  c     -128  255 ja 2a ;  ,   mov rdx,QWORD PTR [rip+0x395f30] ;    ;   mov rdx,QWORD PTR fs:[rdx] ;     ;     mov rdx,QWORD PTR [rdx] ;    ;    mov rdx,QWORD PTR [rdx+0x48] ;     toupper mov eax,DWORD PTR [rdx+rax*4+0x200] ;  c   2a: ret

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

ऐसा क्यों है?

शामिल फ़ाइलों की एक लंबी श्रृंखला में, C ++ हैडर फ़ाइलें, जैसे कि <एल्गोरिथ्म> , बदले में, शामिल हैं, <बिट्स / os_defines.h> फ़ाइल, जिसमें निम्न पंक्ति शामिल है:

 //      isanum  .  //   . #define __NO_CTYPE 1

जब फ़ाइल <ctype.h> अंत में जुड़ा हुआ है, तो इस निर्देश के कारण, कोड जिसमें टौपर को बाहरी इनलाइन के रूप में परिभाषित किया गया है शामिल नहीं किया जा सकता है:

 #if !defined __NO_CTYPE # ifdef __isctype_f __isctype_f (alnum) //  ..  .. __isctype_f (xdigit) # elif defined __isctype # define isalnum(c) __isctype((c), _ISalnum) # define isalpha(c) __isctype((c), _ISalpha) //  ..  .. # endif //      # ifdef __USE_EXTERN_INLINES __extern_inline int __NTH (tolower (int __c)) { return __c >= -128 && __c < 256 ? (*__ctype_tolower_loc ())[__c] : __c; } __extern_inline int __NTH (toupper (int __c)) { return __c >= -128 && __c < 256 ? (*__ctype_toupper_loc ())[__c] : __c; } # endif //   tolower     # if __GNUC__ >= 2 && defined __OPTIMIZE__ && !defined __cplusplus # define tolower(c) __tobody (c, tolower, *__ctype_tolower_loc (), (c)) # define toupper(c) __tobody (c, toupper, *__ctype_toupper_loc (), (c)) # endif /* Optimizing gcc */ #endif /* Not __NO_CTYPE. */

कृपया ध्यान दें कि जब <ctype.h> को जोड़ने पर टॉपर के C ++ संस्करण को कभी भी मैक्रो के रूप में परिभाषित नहीं किया जाता है - अधिकतम एक बाहरी इनलाइन के रूप में - चूंकि मैक्रोज़ की परिभाषाओं को संरक्षित किया जाता है ! परिभाषित __cplusplus check और इसलिए कभी भी प्रभावी नहीं होगा।

सामान्य तौर पर, मुझे यह सुनिश्चित करने के लिए पता नहीं है कि इस मामले में __NO_CTYPE को बाहरी इनलाइन के रूप में घोषित टोलर और टौपर फ़ंक्शन के निकायों को बाहर करना चाहिए, लेकिन यह ठीक ऐसा ही होता है - और इसलिए हमारे चक्र की गति में एक महत्वपूर्ण गिरावट है। अंत में, मैं यह कह सकता हूं कि यदि आप <ctype.h> (यानी, C ++ के बजाय <cctype> को शामिल करते हैं, तो C हैडर फ़ाइल का संस्करण है, जो std :: namespace में फ़ंक्शन डालता है), तो इस स्थिति में कोड धीरे-धीरे काम करेगा। क्योंकि <cctype> में अंततः <बिट्स / os_defines.h> शामिल है ।

क्या यह सब महत्वपूर्ण है? नहीं, नहीं।

टॉपर फ़ंक्शन विभिन्न भाषाओं के पात्रों के साथ गंभीर काम के लिए उपयुक्त नहीं है, इसलिए यदि आपको केवल ASCII वर्णों को संसाधित करने की आवश्यकता है, तो आप अपने स्वयं के तेज़ कार्यान्वयन को लिख सकते हैं। यदि आपको पाठ के साथ गंभीर काम करने की आवश्यकता है, तो सबसे अधिक संभावना है कि आप यूटीएफ -8 का उपयोग करेंगे और क्षेत्रीय सेटिंग्स का समर्थन करने के लिए किसी तरह के आईसीयू का उपयोग करना होगा, या जब तक यूनिकोड का समर्थन C ++ में दिखाई नहीं देता है (यह इंतजार करने में लंबा समय लग सकता है) । तो "क्लैंग-फॉर्मेट 4x प्रदर्शन ड्रॉप का कारण बन सकता है" केवल एक क्लिकबैट हैडर के रूप में उपयुक्त है।

क्या यह प्रभाव libc के सभी संस्करणों में देखा गया है? हां, लगभग सभी में, लेकिन यहां तक कि यह इतना सरल नहीं है।

ऊपर दिखाए गए परिणाम gcc 5.5 और glibc 2.23 के लिए सही हैं, क्योंकि मैंने इन संस्करणों का उपयोग किया है, लेकिन नए संस्करणों में कुछ नया हो रहा है (glibc 2.27 से शुरू)। वहां, <ctype.h > से पहले <एल्गोरिथम> को चालू करना अभी भी समान प्रभाव देता है, लेकिन अब <stdlib.h> [10] भी समस्याएं पैदा करता है: यदि आप इसे <ctype.h> से पहले चालू करते हैं, तो प्रदर्शन भी बंद हो जाएगा, जो नहीं है पहले के संस्करणों में देखे गए। जाहिर है, नए संस्करणों में, <stdlib.h> फ़ाइल में __NO_CTYPE परिभाषा भी शामिल है। कम से कम, अब छँटाई के लिए क्लैंग-प्रारूप को दोष देना संभव नहीं होगा - यहाँ यह समस्या को हल करने में मदद कर सकता है (यदि कनेक्टेड फ़ाइलों की सूची में कोई अन्य समस्या फ़ाइलें नहीं हैं)।

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

मेरे पास अपनी साइट पर एक टिप्पणी प्रणाली नहीं है, लेकिन मैं इस पर काम कर रहा हूं (यानी, समय-समय पर रोना, जो एक स्थिर साइट पर टिप्पणी करना मुश्किल है)।

इस बीच, आप हैकर न्यूज वेबसाइट या lobste.rs पर इस लेख पर चर्चा कर सकते हैं।

धन्यवाद

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

हां, <ctype.h> हेडर फ़ाइल से टौपर (3) फ़ंक्शन अधिकांश गैर-ASCII वर्णों के साथ काम करने के लिए अनुपयुक्त है, जैसा कि पात्रों को एक बाइट से बड़ा नहीं कर सकते, लेकिन यह हमारे कार्य के लिए उपयुक्त है, क्योंकि हम केवल ASCII वर्णों के तार पास करेंगे।
ASCII तालिका में, निचले और ऊपरी मामले के अक्षर बहुत सुविधाजनक रूप से स्थित हैं - एक दूसरे से 32 पदों की दूरी पर, जिसका अर्थ है कि आप वर्णों को एक मामले से दूसरे में आसानी से घटा या जोड़कर 32 स्थानांतरित कर सकते हैं। सामान्य तौर पर, अगर हम यह सुनिश्चित कर लें कि सभी इनपुट डेटा ASCII अक्षर है, हम किसी भी अपरकेस अक्षर को लोअरकेस में बदलने के लिए बिना किसी चेक (उदाहरण के लिए, c & 0b11011111 ) के बिना 5 बिट को रीसेट कर सकते हैं, जबकि यह लोअरकेस अक्षरों में परिलक्षित नहीं होगा। लेकिन हम शायद यह नहीं जानते हैं, इसलिए हमें यह जांचना होगा कि क्या चरित्र एक अक्षर है, इसलिए गलती से भी गैर-अक्षर वाले चरित्र को तोड़ना नहीं है।
इसे बिंदुओं के स्थान पर "शोर" के अलावा एक स्कैटर प्लॉट कहा जाना चाहिए। वास्तव में, यह एक सामान्य तितर बितर चित्र है जिसमें हमारे लिए ब्याज का पैरामीटर (इनपुट डेटा का आकार) एक्स-अक्ष पर प्लॉट किया गया है, और काम की गति y- अक्ष पर है (प्रति प्रतीक के उपाय - मूल्य कम, उच्च गति )। इस आरेख की मुख्य विशेषता यह है कि एक्स अक्ष पर प्रत्येक पैरामीटर मान के लिए, नमूना कई बार किया जाता है: इस मामले में, प्रत्येक सरणी आकार के लिए परीक्षण 10 बार दोहराया जाता है।
अर्थात्, वर्णों को यादृच्छिक रूप से और समान रूप से सीमा [32, 127] से चुना जाता है, इसलिए फ़ंक्शन में स्थिति लगभग 27% मामलों में सही होगी।
दोनों लिस्टिंग एक कच्चे चक्र के कार्यान्वयन को संदर्भित करती हैं और केवल उस क्रम में भिन्न होती हैं जिसमें <एल्गोरिथ्म> और <ctype.h> फाइलें शामिल हैं । उत्पन्न स्रोत कोड सभी कार्यान्वयनों के लिए समान है - दोनों तेज और धीमी संस्करणों में। उदाहरण के लिए, std :: ट्रांस्फ़ॉर्म के साथ एक कार्यान्वयन समान धीमी कोडांतरक कोड उत्पन्न करेगा यदि आप <एल्गोरिथम> फ़ाइल, और समान तेज़ कोड शामिल करते हैं यदि आप केवल फ़ंक्शन परिभाषा की प्रतिलिपि बनाते हैं और फ़ाइल शामिल नहीं करते हैं।
हालाँकि, यह तेज़ लूप की तुलना में धीमा है क्योंकि पत्राचार तालिका के लिए सूचक लूप के अंदर कई बार ( mov rdx, QWORD PTR [rax] ) पढ़ा जाता है। यह पॉइंटर क्षेत्रीय सेटिंग्स के आधार पर भिन्न हो सकता है, लेकिन यह चक्र के निष्पादन के दौरान अपडेट नहीं किया जाता है और इसलिए इसे चक्र के बाहर ले जाया जा सकता है। यह होना चाहिए कि संकलक का मानना है कि इसके लिए पर्याप्त कारण नहीं हैं, क्योंकि हम टाइप चार के तत्वों की एक सरणी के लिए लिख रहे हैं, और वे सिद्धांत रूप में उपनाम के रूप में उपयोग किए जा सकते हैं [rax] अर्थात तालिका के लिए सूचक। वैसे भी, यहां तक कि __restrict__ यहां मदद नहीं करेगा। लेकिन लूप के एक अन्य संस्करण में, जहां टौपर वैल्यूज़ को बस जोड़ा जाता है और सरणी में कुछ भी नहीं लिखा जाता है, यह अनुकूलन लागू होता है - पॉइंटर को लूप के बाहर पढ़ा जाता है।
यह जाँच सबस्टेशन योग्य कोडांतरक कोड में परिलक्षित नहीं होती है, क्योंकि कंपाइलर को पहले से ही पता है कि चार वैल्यू हमेशा रेंज [-128, 255] में होती है । चेक केवल आवश्यक है क्योंकि टॉपर का एपीआई © फ़ंक्शन चार के बजाय टाइप इंट का एक मूल्य स्वीकार करता है, ताकि उपयोगकर्ता इसके लिए किसी भी प्रकार के इंट को पास कर सके , जबकि पत्राचार टेबल केवल टाइप चार के मूल्यों के लिए डिज़ाइन किए गए हैं, इसलिए चेक बफर के बाहर पढ़ने से बचने में मदद करता है। ।
वैसे, यह बताता है कि std :: toupper प्रक्रियाएं इनपुट डेटा के आकार से स्वतंत्र क्यों हैं: वे शाखाओं का उपयोग नहीं करते हैं (रेंज चेक को छोड़कर, जो उल्लेखनीय रूप से भविष्यवाणी की गई हैं), लेकिन एक शाखा-स्वतंत्र पत्राचार तालिका का उपयोग करें। ↵
इस कॉल को प्रतिस्थापित करने से बहुत मजबूत इच्छा के साथ भी काम नहीं किया जाएगा: फ़ंक्शन का मुख्य भाग हेडर फ़ाइल में उपलब्ध नहीं है।
मैं किसी भी तरह से stdlib.h (या <एल्गोरिथम> , उस मामले के लिए) के साथ गलती नहीं खोजता - यह काफी संभव है कि कई अन्य सी हेडर फाइलें और सभी सी ++ हेडर फाइलें भी इस व्यवहार का कारण बनती हैं, मैंने अभी उनका परीक्षण नहीं किया है। मैंने stdlib.h को सिर्फ size_t के निर्धारण के लिए जोड़ा था।

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

क्लैंग-प्रारूप कार्यक्रम को धीमा कर देता है

टिप्पणियाँ

धन्यवाद

More articles: