कांस्ट सी / सी ++ कोड को गति क्यों नहीं देता है?

कुछ महीने पहले, मैंने एक पोस्ट में उल्लेख किया था कि यह एक मिथक है, जैसे कि कास्ट सी और सी ++ में कंपाइलर अनुकूलन को सक्षम करने में मदद करता है । मैंने फैसला किया कि इस कथन को समझाया जाना चाहिए, खासकर क्योंकि मैं खुद इस मिथक पर पहले विश्वास करता था। मैं सिद्धांत और कृत्रिम उदाहरणों के साथ शुरू करूँगा, और फिर वास्तविक कोड बेस - SQLite पर आधारित प्रयोगों और बेंचमार्क पर आगे बढ़ूँगा।

सरल परीक्षण

चलो शुरू करते हैं, जैसा कि यह मुझे लगता था, सी कोड को गति के साथ बढ़ाने का सबसे सरल और सबसे स्पष्ट उदाहरण। मान लें कि हमारे पास दो फ़ंक्शन घोषणाएँ हैं:

 void func(int *x); void constFunc(const int *x); 

और मान लीजिए कि कोड के दो संस्करण हैं:

 void byArg(int *x) { printf("%d\n", *x); func(x); printf("%d\n", *x); } void constByArg(const int *x) { printf("%d\n", *x); constFunc(x); printf("%d\n", *x); } 

printf() को निष्पादित करने के लिए, प्रोसेसर को एक पॉइंटर के माध्यम से मेमोरी से *x प्राप्त करना होगा। जाहिर है, constByArg() का निष्पादन थोड़ा तेज हो सकता है, क्योंकि कंपाइलर जानता है कि *x एक स्थिरांक है, इसलिए constFunc() बाद इसके मूल्य को फिर से लोड करने की आवश्यकता नहीं है। है न? आइए देखें कि GCC द्वारा निर्मित कोडांतरक कोड को अनुकूलन के साथ सक्षम किया गया है:

 $ gcc -S -Wall -O3 test.c $ view test.s 

और यहाँ byArg() लिए पूरा कोडांतरक परिणाम है:

 byArg: .LFB23: .cfi_startproc pushq %rbx .cfi_def_cfa_offset 16 .cfi_offset 3, -16 movl (%rdi), %edx movq %rdi, %rbx leaq .LC0(%rip), %rsi movl $1, %edi xorl %eax, %eax call __printf_chk@PLT movq %rbx, %rdi call func@PLT # The only instruction that's different in constFoo movl (%rbx), %edx leaq .LC0(%rip), %rsi xorl %eax, %eax movl $1, %edi popq %rbx .cfi_def_cfa_offset 8 jmp __printf_chk@PLT .cfi_endproc 

byArg() और constByArg() लिए उत्पन्न कोडांतरक कोड के बीच एकमात्र अंतर यह है कि constByArg() पास call constFunc@PLT , जैसा कि स्रोत कोड में है। const खुद ही कोई फर्क नहीं पड़ता।

ठीक है, वह जीसीसी था। शायद हमें एक चालाक संकलक की आवश्यकता है। कहो क्लेंग।

 $ clang -S -Wall -O3 -emit-llvm test.c $ view test.ll 

यहाँ मध्यवर्ती कोड है। यह कोडांतरक की तुलना में अधिक कॉम्पैक्ट है, और मैं दोनों कार्यों को छोड़ दूंगा, ताकि आप समझ सकें कि मुझे "अंतर से कोई मतलब नहीं है, कॉल को छोड़कर:"

 ; Function Attrs: nounwind uwtable define dso_local void @byArg(i32*) local_unnamed_addr #0 { %2 = load i32, i32* %0, align 4, !tbaa !2 %3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %2) tail call void @func(i32* %0) #4 %4 = load i32, i32* %0, align 4, !tbaa !2 %5 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %4) ret void } ; Function Attrs: nounwind uwtable define dso_local void @constByArg(i32*) local_unnamed_addr #0 { %2 = load i32, i32* %0, align 4, !tbaa !2 %3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %2) tail call void @constFunc(i32* %0) #4 %4 = load i32, i32* %0, align 4, !tbaa !2 %5 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %4) ret void } 

विकल्प (प्रकार) काम करता है

और यहाँ वह कोड है जिसमें const की उपस्थिति वास्तव में मायने रखती है:

 void localVar() { int x = 42; printf("%d\n", x); constFunc(&x); printf("%d\n", x); } void constLocalVar() { const int x = 42; // const on the local variable printf("%d\n", x); constFunc(&x); printf("%d\n", x); } 

localVar() के लिए कोडांतरक कोड, जिसमें दो निर्देश हैं जो constLocalVar() बाहर अनुकूलित हैं constLocalVar() :

 localVar: .LFB25: .cfi_startproc subq $24, %rsp .cfi_def_cfa_offset 32 movl $42, %edx movl $1, %edi movq %fs:40, %rax movq %rax, 8(%rsp) xorl %eax, %eax leaq .LC0(%rip), %rsi movl $42, 4(%rsp) call __printf_chk@PLT leaq 4(%rsp), %rdi call constFunc@PLT movl 4(%rsp), %edx # not in constLocalVar() xorl %eax, %eax movl $1, %edi leaq .LC0(%rip), %rsi # not in constLocalVar() call __printf_chk@PLT movq 8(%rsp), %rax xorq %fs:40, %rax jne .L9 addq $24, %rsp .cfi_remember_state .cfi_def_cfa_offset 8 ret .L9: .cfi_restore_state call __stack_chk_fail@PLT .cfi_endproc 

LLVM मिडलवेयर थोड़ा क्लीनर है। constLocalVar() करने के लिए दूसरी कॉल से पहले load printf() constLocalVar() बाहर अनुकूलित किया गया था constLocalVar() :

 ; Function Attrs: nounwind uwtable define dso_local void @localVar() local_unnamed_addr #0 { %1 = alloca i32, align 4 %2 = bitcast i32* %1 to i8* call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %2) #4 store i32 42, i32* %1, align 4, !tbaa !2 %3 = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 42) call void @constFunc(i32* nonnull %1) #4 %4 = load i32, i32* %1, align 4, !tbaa !2 %5 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), i32 %4) call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %2) #4 ret void } 

तो, constLocalVar() ने रिबूट *x को सफलतापूर्वक नजरअंदाज कर दिया, लेकिन आपको कुछ अजीब लग सकता है: निकायों में localVar() और constLocalVar() एक ही कॉल constFunc() । यदि कंपाइलर यह पता लगा सकता है कि constFunc() ने constFunc() *x को संशोधित नहीं किया है, तो यह क्यों नहीं समझ सकता कि उसी फ़ंक्शन कॉल ने localVar() में *x को संशोधित नहीं किया है?

स्पष्टीकरण यह है कि C में कॉन्टेस्ट ऑप्टिमाइज़ेशन के रूप में उपयोग करने के लिए अव्यावहारिक है। सी में, const के अनिवार्य रूप से दो संभावित अर्थ हैं:

• इसका मतलब यह हो सकता है कि एक चर कुछ डेटा के लिए केवल-पढ़ने का छद्म नाम है, जो स्थिर हो सकता है या नहीं भी हो सकता है।
  
• या इसका मतलब यह हो सकता है कि चर वास्तव में एक स्थिर है। यदि आप एक पॉइंटर से स्थिर मान तक कांस्ट करते हैं, और फिर इसे लिखते हैं, तो आपको अपरिभाषित व्यवहार मिलेगा। दूसरी ओर, कोई समस्या नहीं होगी यदि const एक मूल्य के लिए एक संकेतक है जो एक स्थिर नहीं है।
  

यहाँ constFunc() का एक व्याख्यात्मक उदाहरण कार्यान्वयन है:

 // x is just a read-only pointer to something that may or may not be a constant void constFunc(const int *x) { // local_var is a true constant const int local_var = 42; // Definitely undefined behaviour by C rules doubleIt((int*)&local_var); // Who knows if this is UB? doubleIt((int*)x); } void doubleIt(int *x) { *x *= 2; } 

localVar() ने localVar() को constFunc() पॉइंटर को constFunc() वैरिएबल दिया। चूंकि चर शुरुआत में constFunc() नहीं था, constFunc() एक झूठा हो सकता है और UB को आरंभ किए बिना चर को बलपूर्वक संशोधित कर सकता है। इसलिए, संकलक यह नहीं मान सकता है कि constFunc() को वापस करने के बाद constFunc() चर का एक ही मूल्य होगा। constLocalVar() में वैरिएबल वास्तव में const , इसलिए कंपाइलर यह मान नहीं सकता है कि इसे बदला नहीं जाएगा, क्योंकि इस बार यह constFunc() लिए UB होगा , ताकि कंपाइलर constFunc() को अनबाइंड कर सके और वेरिएबल को लिख सके।

पहले उदाहरण से byArg() और constByArg() फ़ंक्शन निराशाजनक हैं, क्योंकि कंपाइलर यह constByArg() नहीं लगा सकता है कि *x const ।

लेकिन असंगति कहां से आई? यदि कंपाइलर यह मान सकता है कि constFunc() से कॉल करने पर constLocalVar() अपना तर्क नहीं बदलता है, तो यह constFunc() कॉल के लिए एक ही अनुकूलन लागू कर सकता है, है ना? नहीं। कंपाइलर यह नहीं मान सकता है कि constLocalVar() कभी भी बुलाया जाएगा। और अगर यह (उदाहरण के लिए, क्योंकि यह कोड जनरेटर या मैक्रो ऑपरेशन का सिर्फ कुछ अतिरिक्त परिणाम है) नहीं है, तो constFunc() चुपचाप यूबी आरंभ किए बिना डेटा को बदल सकता है।

आपको कई बार उपरोक्त उदाहरण और स्पष्टीकरण पढ़ने की आवश्यकता हो सकती है। चिंता न करें कि यह बेतुका लगता है - यह है। दुर्भाग्य से, const वेरिएबल्स को लिखना UB का सबसे खराब प्रकार है: सबसे अधिक बार, कंपाइलर को यह भी पता नहीं होता है कि यह यूबी होगा। इसलिए, जब कंपाइलर const देखता है, तो इस तथ्य से आगे बढ़ना चाहिए कि कोई इसे कहीं बदल सकता है, जिसका अर्थ है कि कंपाइलर अनुकूलन के लिए const उपयोग नहीं कर सकता है। व्यवहार में, यह सच है, क्योंकि बहुत सारे वास्तविक सी कोड में "मुझे पता है कि मैं क्या कर रहा हूं" की शैली में const अस्वीकृति शामिल है।

संक्षेप में, ऐसी कई स्थितियाँ होती हैं जहाँ कंपाइलर को ऑप्टिमाइज़ेशन के लिए const का उपयोग करने की अनुमति नहीं होती है, जिसमें एक पॉइंटर का उपयोग करके दूसरे स्कोप से डेटा प्राप्त करना या ढेर पर डेटा रखना शामिल है। या इससे भी बदतर, आमतौर पर उन परिस्थितियों में जहां कंपाइलर const उपयोग नहीं कर सकता है, यह आवश्यक नहीं है। उदाहरण के लिए, कोई भी स्वाभिमानी संकलक बिना समझे समझ सकता है कि इस कोड में x एक स्थिरांक है:

 int x = 42, y = 0; printf("%d %d\n", x, y); y += x; printf("%d %d\n", x, y); 

इसलिए const ऑप्टिमाइज़ेशन के लिए लगभग बेकार है, क्योंकि:

1. कुछ अपवादों के साथ, कंपाइलर को इसे अनदेखा करने के लिए मजबूर किया जाता है, क्योंकि कुछ कोड कानूनी रूप से अयोग्य हो सकते हैं।
   
2. उपरोक्त अधिकांश अपवादों में, कंपाइलर अभी भी समझ सकता है कि चर एक स्थिर है।
   

सी ++

यदि आप C ++ में लिखते हैं, तो फंक्शन ओवरलोडिंग के माध्यम से कोड को प्रभावित कर सकता है। आपके पास एक ही फ़ंक्शन के const और नॉन- const ओवरलोड हो सकते हैं, और नॉन- const को अनुकूलित किया जा सकता है (प्रोग्रामर द्वारा, संकलक नहीं), उदाहरण के लिए, कम कॉपी करने के लिए।

 void foo(int *p) { // Needs to do more copying of data } void foo(const int *p) { // Doesn't need defensive copies } int main() { const int x = 42; // const-ness affects which overload gets called foo(&x); return 0; } 

एक ओर, मुझे नहीं लगता कि व्यवहार में यह अक्सर C ++ कोड में लागू होता है। दूसरी ओर, इसके लिए वास्तव में एक अंतर बनाने के लिए, एक प्रोग्रामर को यह अनुमान लगाना चाहिए कि वे संकलक के लिए उपलब्ध नहीं हैं, क्योंकि वे भाषा की गारंटी नहीं हैं।

SQLite3 के साथ प्रयोग

पर्याप्त सिद्धांत और दूरगामी उदाहरण। वास्तविक कोडबेस पर const क्या प्रभाव पड़ता है? मैंने SQLite DB (संस्करण 3.30.0) के साथ प्रयोग करने का निर्णय लिया, क्योंकि:

• यह const. का उपयोग करता है const.
• यह एक nontrivial code base (200 KLOC से अधिक) है।
  
• डेटाबेस के रूप में, इसमें कई तंत्र शामिल हैं, जो स्ट्रिंग मानों को संसाधित करने और संख्याओं के रूपांतरण के साथ समाप्त होते हैं।
  
• इसे प्रोसेसर सीमित लोड के साथ परीक्षण किया जा सकता है।
  

इसके अतिरिक्त, लेखक और विकास में शामिल प्रोग्रामर उत्पादकता में सुधार करते हुए पहले ही वर्षों बिता चुके हैं, इसलिए हम यह मान सकते हैं कि उन्होंने कुछ भी याद नहीं किया।

ट्रेनिंग

मैंने सोर्स कोड की दो प्रतियां बनाईं। एक सामान्य मोड में संकलित है, और दूसरा एक निष्क्रिय कमांड में const को चालू करने के लिए हैक का उपयोग करके पूर्व-संसाधित किया गया है:

 #define const 

(GNU) sed प्रत्येक फाइल के ऊपर कमांड sed -i '1i#define const' *.c *.h साथ जोड़ सकता है।

बिल्ड के दौरान कोड उत्पन्न करने के लिए स्क्रिप्ट का उपयोग करते हुए SQLite चीजों को थोड़ा जटिल करता है। सौभाग्य से, कंपाइलर const और const के साथ कोड मिक्स करते समय बहुत शोर const , इसलिए आप तुरंत मेरे एंटी- const कोड को जोड़ने के लिए स्क्रिप्ट को नोट कर सकते हैं और कॉन्फ़िगर कर सकते हैं।

संकलित कोड की प्रत्यक्ष तुलना का कोई मतलब नहीं है, क्योंकि एक छोटा परिवर्तन संपूर्ण मेमोरी योजना को प्रभावित कर सकता है, जिससे पूरे कोड में संकेत और फ़ंक्शन कॉल में बदलाव होगा। इसलिए, मैंने द्विआधारी के आकार और प्रत्येक निर्देश के mnemonic नाम के रूप में एक objdump -d libSQLite3.so.0.8.6 कास्ट ( objdump -d libSQLite3.so.0.8.6 ) लिया। उदाहरण के लिए, यह फ़ंक्शन:

 000000000005d570 <SQLite3_blob_read>: 5d570: 4c 8d 05 59 a2 ff ff lea -0x5da7(%rip),%r8 # 577d0 <SQLite3BtreePayloadChecked> 5d577: e9 04 fe ff ff jmpq 5d380 <blobReadWrite> 5d57c: 0f 1f 40 00 nopl 0x0(%rax) 

में बदल जाता है:

 SQLite3_blob_read 7lea 5jmpq 4nopl 

संकलन करते समय, मैंने SQLite असेंबली सेटिंग्स को नहीं बदला।

संकलित कोड विश्लेषण

LibSQLite3.so के लिए, कांस्टेबल के साथ संस्करण 4,740,704 बाइट्स पर कब्जा कर लिया है, 4,736,712 बाइट्स वाले कांस्टेबल संस्करण की तुलना में लगभग 0.1% अधिक है। दोनों ही मामलों में, 1374 कार्यों का निर्यात किया गया था (PLT में निम्न-स्तरीय सहायक कार्यों की गिनती नहीं), और 13 कास्ट में कोई अंतर था।

कुछ बदलाव प्रीप्रोसेसिंग हैक से संबंधित थे। उदाहरण के लिए, यहां बदले गए कार्यों में से एक है (मैंने SQLite के लिए विशिष्ट कुछ परिभाषाओं को हटा दिया है):

 #define LARGEST_INT64 (0xffffffff|(((int64_t)0x7fffffff)<<32)) #define SMALLEST_INT64 (((int64_t)-1) - LARGEST_INT64) static int64_t doubleToInt64(double r){ /* ** Many compilers we encounter do not define constants for the ** minimum and maximum 64-bit integers, or they define them ** inconsistently. And many do not understand the "LL" notation. ** So we define our own static constants here using nothing ** larger than a 32-bit integer constant. */ static const int64_t maxInt = LARGEST_INT64; static const int64_t minInt = SMALLEST_INT64; if( r<=(double)minInt ){ return minInt; }else if( r>=(double)maxInt ){ return maxInt; }else{ return (int64_t)r; } } 

यदि हम const हटा देते हैं, तो ये स्थिरांक static चर में बदल जाते हैं। मुझे समझ में नहीं आता कि जो कोई भी const परवाह नहीं करता है, उसे इन चरों को static const । यदि हम static और const दोनों को हटा देते हैं, तो जीसीसी फिर से उन्हें स्थिरांक मान लेगा, और हमें एक ही परिणाम मिलेगा। इस तरह के static const वेरिएबल के कारण, तेरह में से तीन फंक्शन्स में बदलाव झूठा निकला, लेकिन मैंने उन्हें ठीक नहीं किया।

SQLite कई वैश्विक चर का उपयोग करता है, और अधिकांश वास्तविक const ऑप्टिमाइज़ेशन इसके साथ जुड़े होते हैं: जैसे कि एक चर के साथ एक तुलना की तुलना में एक स्थिर के साथ तुलना करना, या आंशिक रूप से एक कदम से लूप को रोल करना (यह समझने के लिए कि किस तरह के अनुकूलन किए गए थे, मुझे राडार पसंद था )। कुछ बदलाव ध्यान देने योग्य नहीं हैं। SQLite3ParseUri() में 487 निर्देश हैं, लेकिन const ने केवल एक बदलाव किया: इन दो तुलनाओं को लिया:

 test %al, %al je <SQLite3ParseUri+0x717> cmp $0x23, %al je <SQLite3ParseUri+0x717> 

और अदला बदली:

 cmp $0x23, %al je <SQLite3ParseUri+0x717> test %al, %al je <SQLite3ParseUri+0x717> 

मानक

प्रदर्शन को मापने के लिए SQLite एक प्रतिगमन परीक्षण के साथ आता है, और मैंने इसे मानक SQLite बिल्ड सेटिंग्स का उपयोग करके कोड के प्रत्येक संस्करण के लिए सैकड़ों बार चलाया। सेकंड में निष्पादन का समय:


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

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


टेस्ट यू ने प्रदर्शन में एक महत्वपूर्ण अंतर पाया। लेकिन - एक आश्चर्य! - बिना const संस्करण तेजी से निकला, लगभग 60 एमएस, यानी 0.5%। ऐसा लगता है कि किए गए "अनुकूलन" की छोटी संख्या कोड की मात्रा में वृद्धि के लायक नहीं थी। यह संभावना नहीं है कि const किसी भी प्रमुख अनुकूलन const सक्रिय const , जैसे कि ऑटो-वेक्टरकरण। बेशक, आपका माइलेज कंपाइलर, या उसके संस्करण, या कोड बेस, या कुछ और पर विभिन्न झंडे पर निर्भर हो सकता है। लेकिन मुझे यह कहना ईमानदार लगता है कि भले ही const ने सी के प्रदर्शन में सुधार किया हो, लेकिन मैंने इस पर ध्यान नहीं दिया।

तो कब्ज किस चीज के लिए जरूरी है?

इसके सभी दोषों के लिए, C / C ++ में const टाइप सुरक्षा प्रदान करने के लिए उपयोगी है। विशेष रूप से, यदि आप चाल शब्दार्थ और std::unique_pointer संयोजन में std::unique_pointer उपयोग करते हैं, तो आप स्पष्ट सूचक स्वामित्व को लागू कर सकते हैं। 100 केएलओसी से अधिक पुराने सी ++ कोडबेस में सूचक स्वामित्व की अनिश्चितता एक बहुत बड़ी समस्या थी, इसलिए मैं इसे हल करने के लिए विवश हूं।

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