एक सूचक में 'कॉन्स्ट' जोड़ना अनुकूलन में मदद कर सकता है?

Question

मेरे पास एक सूचक int* p है, और एक लूप में कुछ ऑपरेशन करें। मैं स्मृति को संशोधित नहीं करता, बस पढ़ो। यदि मैं पॉइंटर (const int* p, और int* const p) पर const जोड़ता हूं, तो क्या यह कोड को अनुकूलित करने के लिए एक कंपाइलर की सहायता कर सकता है?

मुझे सुरक्षा या स्वयं-दस्तावेज जैसे const की अन्य योग्यताएं पता हैं, मैं इस विशेष मामले के बारे में पूछता हूं। प्रश्न को दोहराएं: const संकलक को किसी भी उपयोगी (अनुकूलन के लिए) जानकारी दे सकता है?

Answer 1

हालांकि यह कार्यान्वयन के लिए स्पष्ट रूप से विशिष्ट है, यह देखना मुश्किल है कि int* से int const* से पॉइंटर बदलने से यह कभी भी अतिरिक्त जानकारी प्रदान कर सकता है कि संकलक अन्यथा ज्ञात नहीं होता है।

दोनों मामलों में, लूप के निष्पादन के दौरान इंगित मूल्य बदल सकता है।

इसलिए यह शायद संकलक को कोड अनुकूलित करने में मदद नहीं करेगा।

Answer 2

इससे मदद मिल सकती है या इससे कोई फर्क नहीं पड़ता है या इससे इसे और भी खराब हो सकता है। जानने का एकमात्र तरीका उत्सर्जित मशीन कोड दोनों का निरीक्षण करना और निरीक्षण करना है।

आधुनिक कंपाइलर बहुत स्मार्ट हैं, इसलिए वे अक्सर यह समझ सकते हैं कि स्मृति किसी भी क्वालीफायर के बिना अपरिवर्तित है (पीआर वे विश्लेषण के लिए आसान तरीके से लिखे गए कोड के बिना कई अन्य अनुकूलन संभव कर सकते हैं) फिर भी वे जटिल हैं और इसलिए बहुत कम कमीएं और अक्सर हर मौके पर हर संभव चीज़ को अनुकूलित नहीं कर सकती हैं।

Answer 3

नहीं। इस तरह की कॉन्स का उपयोग करने से संकलक को किसी भी जानकारी के साथ प्रदान नहीं किया जाएगा जिसका उपयोग ऑप्टिमाइज़ेशन के लिए किया जा सकता है।

सैद्धांतिक रूप से, यह आपके कंपाइलर की मदद के लिए है, ऑप्टिमाइज़र यह साबित करने में सक्षम होना चाहिए कि कोई भी आपके कॉन्स पॉइंटर पर const_cast का उपयोग नहीं करेगा, फिर भी यह साबित करने में असमर्थ है कि चर कभी नहीं लिखा गया है। ऐसी स्थिति बेहद असंभव है।

हर्ब सटर में यह Guru of the Week कॉलम में से एक में अधिक गहराई है।

Answer 4

मुझे लगता है कि संकलक आपके परिदृश्य में बहुत कुछ नहीं कर सकता है। तथ्य यह है कि आपका पॉइंटर const int * const p के रूप में घोषित किया गया है यह गारंटी नहीं देता है कि स्मृति को बाहरी रूप से बदला नहीं जा सकता है, उदा। एक और धागे से। इसलिए संकलक कोड उत्पन्न करना होगा जो आपके लूप के प्रत्येक पुनरावृत्ति पर स्मृति मान को पढ़ता है।

लेकिन अगर आप स्मृति स्थान के लिए लिख सकते हैं और को आप जानते हैं कि कोड का कोई अन्य टुकड़ा, तो आप एक स्थानीय चर बना सकते हैं और यह इस के समान उपयोग कर सकते हैं नहीं जा रहे हैं:

const int * p = ... 
... 
int val = *p; 
/* use the value in a loop */ 
for (i = 0; i < BAZILLION; i++) 
{ 
    use_value(val); 
} 

न केवल आप अपने कोड के संभावित पाठकों को यह देखने के लिए मदद करते हैं कि val लूप में नहीं बदला गया है, लेकिन आप संकलक को ऑप्टिमाइज़ करने की संभावना भी देते हैं (उदाहरण के लिए val लोड करें)।

Answer 5

const का उपयोग करना, जैसा कि हर किसी ने कहा है, संकलक को आपके लूप को अनुकूलित करने में मदद करने की संभावना नहीं है।

हालांकि, यह को लूप के बाहर या किसी कॉन्स्ट-क्वालिटी विधि के कॉल के साइट पर, या कॉन्स्ट तर्क लेने वाले फ़ंक्शन के लिए अनुकूलित करने में सहायता कर सकता है।

यह इस बात पर निर्भर करता है कि संकलक इसे अनावश्यक भार को खत्म करने, उन्हें चारों ओर स्थानांतरित करने, या गणना करने के बजाय गणना मूल्यों को कैश करने की अनुमति दे सकता है या नहीं।

यह साबित करने का एकमात्र तरीका अभी भी प्रोफ़ाइल और/या असेंबली की जांच करना है, लेकिन यही वह जगह है जहां आपको शायद दिखना चाहिए।

Answer 6

आप यह नहीं कहते कि आप किस कंपाइलर का उपयोग कर रहे हैं। लेकिन यदि आप स्मृति को पढ़ने और लिखने दोनों हैं, तो आप "प्रतिबंधित" या इसी तरह के उपयोग से लाभ उठा सकते हैं। कंपाइलर यह नहीं जानता कि क्या आपके पॉइंटर्स एक ही मेमोरी को अलियासिंग कर रहे हैं, इसलिए कोई भी स्टोर अक्सर अन्य मानों को लोड करने में मजबूर करता है। "प्रतिबंधित" संकलक को बताता है कि सूचक का कोई अलियासिंग नहीं हो रहा है और बाद के लेखन से पहले लोड किए गए मानों का उपयोग कर रख सकता है। एलियासिंग मुद्दे से बचने का एक और तरीका है स्थानीय मूल्यों में अपने मूल्यों को लोड करना, फिर संकलक को लिखने के बाद पुनः लोड करने के लिए मजबूर नहीं किया जाता है।