अलियासिंग (कंप्यूटिंग): Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Multiple names for the same data location}} {{about||the term used in signals processing and computer graphics|Aliasing|the command|Alias (command)}} ...")
 
No edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Short description|Multiple names for the same data location}}
{{Short description|Multiple names for the same data location}}
{{about||the term used in signals processing and computer graphics|Aliasing|the command|Alias (command)}}
[[ कम्प्यूटिंग | कम्प्यूटिंग]] में, '''अलियासिंग''' एक ऐसी स्थिति को डिस्क्राइब करता है जिसमें [[मेमोरी (कंप्यूटर)|मेमोरी]] में डेटा लोकेशन को प्रोग्राम में विभिन्न सिंबॉलिक नामों के माध्यम से एक्सेस किया जा सकता है। इस प्रकार, एक नाम के माध्यम से डेटा को मॉडिफाई करने से सभी अलियास नामों से एसोसिएटेड वैल्यूज को इम्प्लिसिटी से मॉडिफाई किया जाता है, जिसे प्रोग्रामर द्वारा एक्स्पेक्ट नहीं की जा सकता है। परिणामस्वरूप, अलियासिंग से प्रोग्राम को अंडरस्टैंड करना, एनालाइज करना और ऑप्टिमाइज़ करना विशेष रूप से डिफिकल्ट हो जाता है। अलियास एनालाइज का इंटेंड फंक्शन में अलियास को समझने के लिए उपयोगी जानकारी बनाना और कंप्यूट करना है।
[[ कम्प्यूटिंग ]] में, अलियासिंग एक ऐसी स्थिति का वर्णन करता है जिसमें [[मेमोरी (कंप्यूटर)]] में डेटा स्थान को प्रोग्राम में विभिन्न प्रतीकात्मक नामों के माध्यम से एक्सेस किया जा सकता है। इस प्रकार, एक नाम के माध्यम से डेटा को संशोधित करने से सभी उपनाम नामों से जुड़े मानों को अंतर्निहित रूप से संशोधित किया जाता है, जिसकी प्रोग्रामर द्वारा अपेक्षा नहीं की जा सकती है। परिणामस्वरूप, अलियासिंग से प्रोग्राम को समझना, विश्लेषण करना और अनुकूलित करना विशेष रूप से कठिन हो जाता है। उपनाम विश्लेषण का उद्देश्य कार्यक्रमों में उपनाम को समझने के लिए उपयोगी जानकारी बनाना और गणना करना है।


== उदाहरण ==
== उदाहरण ==


=== बफर अतिप्रवाह ===
=== बफर ओवरफ्लो ===
उदाहरण के लिए, [[सी (प्रोग्रामिंग भाषा)]] के अधिकांश कार्यान्वयन सरणी सीमाओं की जांच नहीं करते हैं। फिर कोई व्यक्ति कंपाइलर और कंप्यूटर आर्किटेक्चर की असेंबली भाषा सम्मेलनों द्वारा प्रोग्रामिंग भाषा के कार्यान्वयन का लाभ उठा सकता है, ताकि सरणी के बाहर (एक प्रकार का [[बफ़र अधिकता]]) लिखकर अलियासिंग प्रभाव प्राप्त किया जा सके। यह सी भाषा विनिर्देश के अनुसार [[अपरिभाषित व्यवहार]] का आह्वान करता है; हालाँकि C के कई कार्यान्वयन यहाँ वर्णित अलियासिंग प्रभाव दिखाएंगे।
उदाहरण के लिए, [[सी (प्रोग्रामिंग भाषा)|सी प्रोग्रामिंग लैंग्वेज]] के अधिकांश इंप्लीमेंटेशन ऐरे बाउंड की जांच नहीं करते हैं। फिर कोई व्यक्ति कंपाइलर और कंप्यूटर आर्किटेक्चर की असेंबली लैंग्वेज कन्वेंशन के द्वारा प्रोग्रामिंग लैंग्वेज के इंप्लीमेंटेशन का लाभ प्राप्त कर सकता है, जिससे ऐरे के बाहर (एक प्रकार का [[बफ़र अधिकता|बफ़र ओवरफ्लो]]) लिखकर अलियासिंग इफेक्ट्स प्राप्त किया जा सके। यह सी लैंग्वेज स्पेसिफिकेशन के अनुसार [[अपरिभाषित व्यवहार|अनडिफाइंड बिहेवियर]] का इन्वोक करता है; यघपि C के कई इंप्लीमेंटेशन यहाँ डिस्क्राइब अलियासिंग इफेक्ट्स दिखाएंगे।


यदि [[कॉल स्टैक]] पर एक ऐरे बनाया जाता है, तो उस ऐरे डेटा संरचना के ठीक बगल में मेमोरी में एक वेरिएबल रखा जाता है, कोई ऐरे के बाहर इंडेक्स कर सकता है और संबंधित ऐरे तत्व को बदलकर वेरिएबल को सीधे बदल सकता है। उदाहरण के लिए, यदि कोई है {{code|int}} आकार 2 की सरणी (इस उदाहरण के लिए, इसे कॉल करना {{code|arr}}), दूसरे के बगल में {{code|int}} वेरिएबल (इसे कॉल करें {{code|i}}), {{code|arr[2]}} (यानी, तीसरा तत्व) को उपनाम दिया जाएगा {{code|i}} यदि वे स्मृति में आसन्न हैं।
यदि [[कॉल स्टैक|स्टैक]] पर एक ऐरे बनाया जाता है, तो उस ऐरे के ठीक बगल में मेमोरी में एक वेरिएबल रखा जाता है, कोई ऐरे के बाहर इंडेक्स कर सकता है और संबंधित ऐरे एलिमेंट को बदलकर वेरिएबल को सीधे बदल सकता है। उदाहरण के लिए, यदि आकार 2 की कोई {{code|int}} ऐरे है (इस उदाहरण के लिए, इसे {{code|arr}} कहा जाता), दूसरे {{code|int}} वेरिएबल के बगल में (इसे {{code|i}} कहें), {{code|arr[2]}} (अर्थात्, तीसरा एलिमेंट) को {{code|i}}अलियास दिया जाएगा यदि वे मेमोरी में एडजासेंट होते हैं।
<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
# include <stdio.h>
# include <stdio.h>
Line 28: Line 27:
}
}
</syntaxhighlight>
</syntaxhighlight>
सी के कुछ कार्यान्वयन में यह संभव है क्योंकि एक सरणी सन्निहित मेमोरी का एक ब्लॉक है, और सरणी तत्वों को केवल एक तत्व के आकार से गुणा किए गए उस ब्लॉक की शुरुआत के पते से ऑफसेट द्वारा संदर्भित किया जाता है। चूँकि C की कोई सीमा नहीं है, इसलिए सरणी के बाहर अनुक्रमण और पता लगाना संभव है। ध्यान दें कि उपर्युक्त उपनाम व्यवहार [[अपरिभाषित व्यवहार]] है। कुछ कार्यान्वयन स्टैक पर सरणियों और वेरिएबल्स के बीच जगह छोड़ सकते हैं, उदाहरण के लिए, वेरिएबल्स को मेमोरी स्थानों पर संरेखित करने के लिए जो आर्किटेक्चर के मूल शब्द आकार के गुणक हैं। सी मानक आम तौर पर यह निर्दिष्ट नहीं करता है कि डेटा को मेमोरी में कैसे रखा जाए। (आईएसओ/आईईसी 9899:1999, अनुभाग 6.2.6.1)।
सी के कुछ इंप्लीमेंटेशन में यह पॉसिबल होता है क्योंकि एक ऐरे कांटीगुअस मेमोरी का एक ब्लॉक होता है, और ऐरे एलिमेंटों को मात्र एक एलिमेंट के आकार से गुणा किए गए उस ब्लॉक की बेगिननिंग के एड्रेस से ऑफसेट द्वारा रिफरेन्स किया जाता है। चूँकि C की कोई बाउंड नहीं होता है, इसलिए ऐरे के बाहर इंडेक्सिंग और एड्रेस करना पॉसिबल होता है। ध्यान दें कि उपर्युक्त अलियास बिहेवियर [[अपरिभाषित व्यवहार|अनडिफाइंड बिहेवियर]] होता है। कुछ इंप्लीमेंटेशन स्टैक पर ऐरे और वेरिएबल्स के मध्य स्पेस छोड़ सकते हैं, उदाहरण के लिए, वेरिएबल्स को मेमोरी लोकेशन पर अलाइन करने के लिए जो आर्किटेक्चर के नेटिव वर्ड साइज़ के मल्टीप्ल होते हैं। सी स्टैण्डर्ड सामान्यतः यह स्पेसिफाये नहीं करता है कि डेटा को मेमोरी में कैसे रखा जाए। (आईएसओ/आईईसी 9899:1999, सेक्शन 6.2.6.1)।


किसी कंपाइलर के लिए किसी ऐरे की सीमा से बाहर आने वाले एक्सेस के लिए अलियासिंग प्रभाव को छोड़ना गलत नहीं है।
किसी कंपाइलर के लिए किसी ऐरे की बाउंड से बाहर आने वाले एक्सेस के लिए अलियासिंग इफेक्ट्स को ऑमिट करना एरोनियस नहीं होता है।


=== उपनाम सूचक ===
=== अलियास पॉइंटर्स ===
किसी भी भाषा में अन्य प्रकार के उपनाम हो सकते हैं जो मेमोरी में एक स्थान को एक से अधिक नामों से संदर्भित कर सकते हैं (उदाहरण के लिए, [[ सूचक (कंप्यूटर प्रोग्रामिंग) ]] के साथ)। C Xor स्वैप एल्गोरिथम#XOR स्वैप एल्गोरिथम का कोड उदाहरण देखें जो एक फ़ंक्शन है; यह मानता है कि इसे दिए गए दो पॉइंटर्स अलग-अलग हैं, लेकिन यदि वे वास्तव में बराबर हैं (या एक दूसरे के उपनाम), तो फ़ंक्शन विफल हो जाता है। यह उन फ़ंक्शंस के साथ एक आम समस्या है जो सूचक तर्कों को स्वीकार करते हैं, और अलियासिंग के लिए उनकी सहनशीलता (या इसकी कमी) को सावधानीपूर्वक प्रलेखित किया जाना चाहिए, विशेष रूप से उन फ़ंक्शंस के लिए जो उन्हें दिए गए स्मृति क्षेत्रों पर जटिल हेरफेर करते हैं।
किसी भी लैंग्वेज में अन्य प्रकार के अलियास हो सकते हैं जो मेमोरी में एक स्थान को एक से अधिक नामों से रिफरेन्स कर सकते हैं (उदाहरण के लिए, [[ सूचक (कंप्यूटर प्रोग्रामिंग) |पॉइंटर्स]] के साथ)। XOR स्वैप एल्गोरिथम का C उदाहरण देखें जो एक फ़ंक्शन होता है; यह मानता है कि इसे दिए गए दो पॉइंटर्स भिन्न-भिन्न होते हैं, परन्तु यदि वे फैक्ट ईकुअल होते हैं (या एक दूसरे के अलियास), तो फ़ंक्शन विफल हो जाता है। यह उन फ़ंक्शंस के साथ एक कॉमन प्रॉब्लम होती है जो पॉइंटर्स आर्गुमेंट को स्वीकार करते हैं, और अलियासिंग के लिए उनकी टॉलरेंस (या इसकी कमी) को केयरफुल्ली डोकोमेंट किया जाना चाहिए, विशेष रूप से उन फ़ंक्शंस के लिए जो उन्हें दिए गए मेमोरी एरिया पर काम्प्लेक्स मैनिपुलेट करते हैं।


== निर्दिष्ट उपनाम ==
== स्पेसीफाई अलियास ==
नियंत्रित अलियासिंग व्यवहार कुछ मामलों में वांछनीय हो सकता है (अर्थात, निर्दिष्ट अलियासिंग व्यवहार, सी में मेमोरी लेआउट द्वारा सक्षम किए गए व्यवहार के विपरीत)। [[फोरट्रान]] में यह आम बात है। [[पर्ल]] [[प्रोग्रामिंग भाषा]], कुछ निर्माणों में, अलियासिंग व्यवहार को निर्दिष्ट करती है, जैसे कि {{code|foreach}} लूप्स. यह कुछ डेटा संरचनाओं को कम कोड के साथ सीधे संशोधित करने की अनुमति देता है। उदाहरण के लिए,
नियंत्रित अलियासिंग बिहेवियर कुछ केस में डिजायरेबल हो सकता है (अर्थात, स्पेसीफाई अलियासिंग बिहेवियर, सी में मेमोरी लेआउट द्वारा इनेबल्ड किए गए बिहेवियर के विपरीत)। [[फोरट्रान]] में यह कॉमन होता है। [[पर्ल]] [[प्रोग्रामिंग भाषा|प्रोग्रामिंग लैंग्वेज]], कुछ निर्माणों में, अलियासिंग बिहेवियर को स्पेसीफाई करती है, जैसे कि {{code|foreach}} लूप्स। यह कुछ डेटा स्ट्रक्चर को कम कोड के साथ सीधे मॉडिफाई करने की अनुमति देता है। उदाहरण के लिए,


<syntaxhighlight lang="perl">
<syntaxhighlight lang="perl">
Line 50: Line 49:
print "@array \n";
print "@array \n";
</syntaxhighlight>
</syntaxhighlight>
परिणामस्वरूप 2 3 4 प्रिंट आउट हो जाएगा। यदि कोई अलियासिंग प्रभावों को बायपास करना चाहता है, तो वह इंडेक्स वेरिएबल की सामग्री को दूसरे में कॉपी कर सकता है और कॉपी को बदल सकता है।
परिणामस्वरूप 2 3 4 प्रिंट आउट हो जाएगा। यदि कोई अलियासिंग इफेक्ट्स को बायपास करना चाहता है, तो वह इंडेक्स वेरिएबल की कंटेंट्स को दूसरे में कॉपी कर सकता है और कॉपी को बदल सकता है।


== अनुकूलन के साथ संघर्ष ==
== ऑप्टिमाइजेशन के साथ कॉन्फ्लिक्ट्स ==
जब अलियासिंग संभव हो तो [[कंपाइलर का अनुकूलन]] को अक्सर वेरिएबल्स के बारे में रूढ़िवादी धारणाएँ बनानी पड़ती हैं। उदाहरण के लिए, किसी वेरिएबल का मान जानना (जैसे <code>x</code> 5 है) आम तौर पर कुछ अनुकूलन की अनुमति देता है (जैसे कि निरंतर तह#निरंतर प्रसार)। हालाँकि, कंपाइलर किसी अन्य वेरिएबल को असाइनमेंट के बाद इस जानकारी का उपयोग नहीं कर सकता है (उदाहरण के लिए, सी में, <code>*y = 10</code>) क्योंकि ऐसा हो सकता है <code>*y</code> का उपनाम है <code>x</code>. जैसे असाइनमेंट के बाद ऐसा हो सकता है <code>y = &x</code>. इस असाइनमेंट के प्रभाव के रूप में <code>*y</code>, का मान है <code>x</code> भी बदल दिया जाएगा, इसलिए जानकारी का प्रचार-प्रसार कर रहे हैं <code>x</code> निम्नलिखित कथनों में 5 है <code>*y = 10</code> संभावित रूप से गलत होगा (यदि <code>*y</code> वास्तव में का एक उपनाम है <code>x</code>). हालाँकि, यदि पॉइंटर्स के बारे में जानकारी है, तो निरंतर प्रसार प्रक्रिया एक क्वेरी बना सकती है जैसे: कर सकते हैं <code>x</code> का उपनाम हो <code>*y</code>? फिर, यदि उत्तर नहीं है, <code>x = 5</code> सुरक्षित रूप से प्रचारित किया जा सकता है।
जब अलियासिंग पॉसिबल हो तो [[कंपाइलर का अनुकूलन|कंपाइलर का ऑप्टिमाइजेशन]] को अधिकांशतः वेरिएबल्स के बारे में कन्सेर्वटिवे असम्पशन बनानी पड़ती हैं। उदाहरण के लिए, किसी वेरिएबल का मान जानना (जैसे <code>x</code> 5 है) सामान्यतः कुछ ऑप्टिमाइजेशन की अनुमति देता है (जैसे कि कांस्टेंट प्रोपेगेशन)। यघपि, कंपाइलर किसी अन्य वेरिएबल को असाइनमेंट के पश्चात् इस जानकारी का उपयोग नहीं कर सकता है (उदाहरण के लिए, सी में, <code>*y = 10</code>) क्योंकि ऐसा हो सकता है <code>*y</code> <code>x</code>का अलियास हो। <code>y = &x</code> जैसे असाइनमेंट के पश्चात् ऐसा हो सकता है। इस असाइनमेंट के इफेक्केट्स रूप में <code>*y</code>, <code>x</code>का मान है भी बदल दिया जाएगा, इसलिए <code>*y = 10</code> के पश्चात् स्टेटमेंटमें या जानकारी प्रोपेगेट करना की <code>x</code> 5 पोटेंशियली गलत होगा (यदि <code>*y</code> इनडिड में <code>x</code> का एक अलियास है)। यघपि, यदि पॉइंटर्स के बारे में जानकारी है, तो कांस्टेंट प्रोपेगेशन प्रोसेस एक क्वेरी बना सकती है जैसे: क्या <code>x</code> <code>*y</code>का अलियास हो सकता है? फिर, यदि उत्तर नहीं है, तो <code>x = 5</code> सेफली प्रोपागेट किया जा सकता है।


अलियासिंग से प्रभावित एक अन्य अनुकूलन कोड पुनः व्यवस्थित करना है। यदि संकलक यह निर्णय लेता है <code>x</code> द्वारा उपनाम नहीं दिया गया है <code>*y</code>, फिर वह कोड जो के मान का उपयोग करता है या बदलता है <code>x</code> असाइनमेंट से पहले स्थानांतरित किया जा सकता है <code>*y = 10</code>, यदि इससे निर्देश शेड्यूलिंग में सुधार होगा या अधिक [[लूप अनुकूलन]] किए जाने में सक्षम होगा।
अलियासिंग से इम्पक्टेड एक अन्य ऑप्टिमाइजेशन कोड रीऑर्डरिंग करना है। यदि कम्पाइलर यह निर्णय लेता है की <code>x</code> को <code>*y</code>द्वारा अलियास नहीं दिया गया है, तो फिर <code>x</code> वैल्यू का उपयोग करने या बदलने वाले कोड को असाइनमेंट <code>*y = 10</code> से पहले ले जाया जा सकता है , यदि इससे शेड्यूलिंग में इम्रप्रूव होगा या अधिक [[लूप अनुकूलन|लूप ऑप्टिमाइजेशन]] किए जाने में इनेबल होगा।


ऐसे अनुकूलन को पूर्वानुमेय तरीके से सक्षम करने के लिए, C (प्रोग्रामिंग भाषा) #ANSI C और C (प्रोग्रामिंग भाषा) के लिए ISO C (इसके नए C (प्रोग्रामिंग भाषा) #C99 संस्करण सहित, अनुभाग 6.5, पैराग्राफ 7 देखें) निर्दिष्ट करता है कि विभिन्न प्रकार के पॉइंटर्स का उपयोग करके एक ही मेमोरी स्थान तक पहुंचना अवैध है (कुछ अपवादों के साथ)। इसलिए एक कंपाइलर यह मान सकता है कि ऐसे पॉइंटर्स उपनाम नहीं देते हैं। यह नियम, जिसे सख्त अलियासिंग नियम के रूप में जाना जाता है, कभी-कभी प्रदर्शन में प्रभावशाली वृद्धि की अनुमति देता है,<ref>{{cite web | url=http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html |author=Mike Acton |date=2006-06-01 |title=Understanding Strict Aliasing}}</ref> लेकिन कुछ अन्यथा वैध कोड को तोड़ने के लिए जाना जाता है। कई सॉफ़्टवेयर प्रोजेक्ट जानबूझकर C99 मानक के इस भाग का उल्लंघन करते हैं। उदाहरण के लिए, CPython|Python 2.x ने [[संदर्भ गिनती]] को लागू करने के लिए ऐसा किया,<ref>{{cite web | url=http://mail.python.org/pipermail/python-dev/2003-July/036898.html |author=Neil Schemenauer |date=2003-07-17 |title=ANSI strict aliasing and Python}}</ref> और इस अनुकूलन को सक्षम करने के लिए पायथन 3 में मूल ऑब्जेक्ट संरचनाओं में आवश्यक परिवर्तन। [[लिनक्स कर्नेल]] ऐसा इसलिए करता है क्योंकि सख्त एलियासिंग इनलाइन कोड के अनुकूलन में समस्याओं का कारण बनता है।<ref>{{cite web | url=https://lkml.org/lkml/2003/2/26/158 |author=Linus Torvalds |date=2003-02-26 |title=Re: Invalid compilation without -fno-strict-aliasing}}</ref> ऐसे मामलों में, जब [[जीएनयू कंपाइलर संग्रह]] के साथ संकलित किया जाता है, तो विकल्प <code>-fno-strict-aliasing</code> अवांछित अनुकूलन को रोकने के लिए लागू किया जाता है जो अप्रत्याशित कोड उत्पन्न कर सकता है।
ऐसे ऑप्टिमाइजेशन को प्रेडिक्टेबल मैनर से इनेबल करने के लिए, प्रोग्रामिंग लैंग्वेज के लिए आईएसओ स्टैण्डर्ड (इसके नए #C99 एडिशन सहित, सेक्शन  6.5, पैराग्राफ 7 देखें) स्पेसीफाई करता है कि विभिन्न प्रकार के पॉइंटर्स का उपयोग करके एक ही मेमोरी लोकेशन  तक पहुंचना इललीगल होता है (कुछ एक्सेप्शन के साथ)। इसलिए एक कंपाइलर यह मान सकता है कि ऐसे पॉइंटर्स अलियास नहीं देते हैं। यह नियम, जिसे स्ट्रिक्ट अलियासिंग रूल के रूप में जाना जाता है, कभी-कभी परफॉरमेंस में इम्प्रेसिव इनक्रीस की अनुमति देता है,<ref>{{cite web | url=http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html |author=Mike Acton |date=2006-06-01 |title=Understanding Strict Aliasing}}</ref> परन्तु कुछ को अन्यथा इललीग कोड को ब्रेक करने के लिए जाना जाता है। कई सॉफ़्टवेयर प्रोजेक्ट इंटेन्सिली C99 स्टैण्डर्ड के इस पार्ट को वॉयलेट करते हैं। उदाहरण के लिए, CPython|Python 2.x ने [[संदर्भ गिनती|रिफरेन्स काउंटिंग]] को इम्प्लेमेंट करने के लिए ऐसा किया,<ref>{{cite web | url=http://mail.python.org/pipermail/python-dev/2003-July/036898.html |author=Neil Schemenauer |date=2003-07-17 |title=ANSI strict aliasing and Python}}</ref> और इस ऑप्टिमाइजेशन को इनेबल करने के लिए पायथन 3 में मूल ऑब्जेक्ट स्ट्रक्चर में आवश्यक परिवर्तन किया। [[लिनक्स कर्नेल]] ऐसा इसलिए करता है क्योंकि स्ट्रिक्ट एलियासिंग इनलाइन कोड के ऑप्टिमाइजेशन में समस्याओं का कारण बनता है।<ref>{{cite web | url=https://lkml.org/lkml/2003/2/26/158 |author=Linus Torvalds |date=2003-02-26 |title=Re: Invalid compilation without -fno-strict-aliasing}}</ref> ऐसे केस में, जब [[जीएनयू कंपाइलर संग्रह|जीसीसी]] के साथ कंपाइल किया जाता है, तो विकल्प <code>-fno-strict-aliasing</code> अनवांटेड ऑप्टिमाइजेशन के प्रिवेंट के लिए इनवोक किया जाता है जो अनएक्स्पेक्ट कोड उत्पन्न कर सकता है।


== हार्डवेयर एलियासिंग ==
== हार्डवेयर एलियासिंग ==
अलियासिंग शब्द का उपयोग उस स्थिति का वर्णन करने के लिए भी किया जाता है, जहां हार्डवेयर डिज़ाइन विकल्प या हार्डवेयर विफलता के कारण, मेमोरी चयन प्रक्रिया में एक या अधिक उपलब्ध एड्रेस बिट्स का उपयोग नहीं किया जाता है।<ref>{{cite web | url=http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-memory-testing.html |author=Michael Barr |date=2012-07-27 |title=Software Based Memory Testing}}</ref> यह एक डिज़ाइन निर्णय हो सकता है यदि स्थापित मेमोरी डिवाइस(डिवाइसों) का समर्थन करने के लिए आवश्यक से अधिक एड्रेस [[ अंश ]]्स उपलब्ध हैं। विफलता में, एक या अधिक एड्रेस बिट्स को एक साथ छोटा किया जा सकता है, या [[ग्राउंड (बिजली)]] (तर्क 0) या आपूर्ति वोल्टेज (तर्क 1) के लिए मजबूर किया जा सकता है।
अलियासिंग शब्द का उपयोग उस सिचुएशन का वर्णन करने के लिए भी किया जाता है, जहां हार्डवेयर डिज़ाइन चॉइस या हार्डवेयर विफलता के कारण, मेमोरी सिलेक्शन प्रोसस में एक या अधिक उपलब्ध एड्रेस बिट्स का उपयोग नहीं किया जाता है।<ref>{{cite web | url=http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-memory-testing.html |author=Michael Barr |date=2012-07-27 |title=Software Based Memory Testing}}</ref> यह एक डिज़ाइन डिसिशन हो सकता है यदि इन्मेसटाल्मोड री डिवाइस(डिवाइसों) का सपोर्ट करने के लिए आवश्यक से अधिक एड्रेस [[ अंश |बिट्स]] उपलब्ध होता हैं। फेलीयर में, एक या अधिक एड्रेस बिट्स को एक साथ छोटा किया जा सकता है, या [[ग्राउंड (बिजली)|ग्राउंड]] (लॉजिक 0) या सप्लाई वोल्टेज (लॉजिक 1) के लिए फोर्स किया जा सकता है।


;उदाहरण
;उदाहरण
इस उदाहरण के लिए, 8 स्थानों के साथ एक मेमोरी डिज़ाइन मानते हुए, 2 के बाद से केवल 3 पता पंक्तियों (या बिट्स) की आवश्यकता होती है<sup>3</sup>=8). मानक [[काउंटर (डिजिटल)]] फैशन में, अद्वितीय मेमोरी स्थानों का चयन करने के लिए एड्रेस बिट्स (ए 2 से ए 0 नामित) को डीकोड किया जाता है:
इस उदाहरण के लिए, 8 स्थानों के साथ एक मेमोरी डिज़ाइन मानते हुए, 2<sup>3</sup> = 8 के पश्चात् से केवल 3 एड्रेस लाइन (या बिट्स) की आवश्यकता होती है।  स्टैण्डर्ड [[काउंटर (डिजिटल)|काउंटर]] फैशन में, यूनिक मेमोरी लोकेशन का चयन करने के लिए एड्रेस बिट्स (ए 2 से ए 0 नामित) को डीकोड किया जाता है:


{| class="wikitable" style="text-align:center"
{| class="wikitable" style="text-align:center"
Line 86: Line 85:
|-
|-
|}
|}
उपरोक्त तालिका में, पता बिट्स के 8 अद्वितीय संयोजनों में से प्रत्येक एक अलग मेमोरी स्थान का चयन करता है। हालाँकि, यदि एक एड्रेस बिट (मान लीजिए A2) को ग्राउंड पर छोटा किया जाना है, तो तालिका को निम्नानुसार संशोधित किया जाएगा:
उपरोक्त टेबल में, एड्रेस बिट्स के 8 यूनिक कॉम्बिनेशन में से प्रत्येक एक अलग मेमोरी लोकेशन को सलेक्ट करता है। यघपि, यदि एक एड्रेस बिट (मान लीजिए A2) को ग्राउंड पर छोटा किया जाना है, तो टेबल को निम्नानुसार मॉडिफाई किया जाएगा:


{| class="wikitable" style="text-align:center"
{| class="wikitable" style="text-align:center"
Line 109: Line 108:
|-
|-
|}
|}
इस मामले में, A2 हमेशा शून्य होने पर, पहले चार मेमोरी स्थान डुप्लिकेट हो जाते हैं और दूसरे चार के रूप में फिर से दिखाई देते हैं। स्मृति स्थान 4 से 7 अप्राप्य हो गए हैं।
इस केस में, A2 सदैव शून्य होने पर, पहले चार मेमोरी लोकेशन डुप्लिकेट हो जाते हैं और दूसरे चार के रूप में फिर से दिखाई देते हैं। मेमोरी लोकेशन 4 से 7 इनएक्सेसिबल हो गए हैं।


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


== यह भी देखें ==
== यह भी देखें ==
* [[उपघटन प्रतिरोधी]]
* [[उपघटन प्रतिरोधी|एंटीअलियासिंग]]
* कंप्यूटर ग्राफिक्स सहित सिग्नल प्रोसेसिंग पर लागू होने पर शब्द के उपयोग के लिए उपनाम
* कंप्यूटर ग्राफिक्स सहित सिग्नल प्रोसेसिंग पर एप्लाइड होने पर शब्द के उपयोग के लिए अलियास


== संदर्भ ==
== संदर्भ ==
Line 126: Line 125:
* [http://www.ddj.com/cpp/184404273;jsessionid=NV5BWY3EOHMFSQSNDLPCKH0CJUNN2JVN?_requestid=510121 Type-based alias analysis in C++] – Informational article on type-based alias analysis in C++
* [http://www.ddj.com/cpp/184404273;jsessionid=NV5BWY3EOHMFSQSNDLPCKH0CJUNN2JVN?_requestid=510121 Type-based alias analysis in C++] – Informational article on type-based alias analysis in C++
* [http://dbp-consulting.com/tutorials/StrictAliasing.html Understand C/C++ Strict Aliasing] – article on strict aliasing originally from the boost developer's wiki
* [http://dbp-consulting.com/tutorials/StrictAliasing.html Understand C/C++ Strict Aliasing] – article on strict aliasing originally from the boost developer's wiki
[[Category: संकलक निर्माण]] [[Category: कार्यक्रम विश्लेषण]] [[Category: उदाहरण पर्ल कोड वाले लेख]]


[[Category: Machine Translated Page]]
[[Category:Created On 24/07/2023]]
[[Category:Created On 24/07/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:उदाहरण पर्ल कोड वाले लेख]]
[[Category:कार्यक्रम विश्लेषण]]
[[Category:संकलक निर्माण]]

Latest revision as of 17:26, 21 August 2023

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

उदाहरण

बफर ओवरफ्लो

उदाहरण के लिए, सी प्रोग्रामिंग लैंग्वेज के अधिकांश इंप्लीमेंटेशन ऐरे बाउंड की जांच नहीं करते हैं। फिर कोई व्यक्ति कंपाइलर और कंप्यूटर आर्किटेक्चर की असेंबली लैंग्वेज कन्वेंशन के द्वारा प्रोग्रामिंग लैंग्वेज के इंप्लीमेंटेशन का लाभ प्राप्त कर सकता है, जिससे ऐरे के बाहर (एक प्रकार का बफ़र ओवरफ्लो) लिखकर अलियासिंग इफेक्ट्स प्राप्त किया जा सके। यह सी लैंग्वेज स्पेसिफिकेशन के अनुसार अनडिफाइंड बिहेवियर का इन्वोक करता है; यघपि C के कई इंप्लीमेंटेशन यहाँ डिस्क्राइब अलियासिंग इफेक्ट्स दिखाएंगे।

यदि स्टैक पर एक ऐरे बनाया जाता है, तो उस ऐरे के ठीक बगल में मेमोरी में एक वेरिएबल रखा जाता है, कोई ऐरे के बाहर इंडेक्स कर सकता है और संबंधित ऐरे एलिमेंट को बदलकर वेरिएबल को सीधे बदल सकता है। उदाहरण के लिए, यदि आकार 2 की कोई int ऐरे है (इस उदाहरण के लिए, इसे arr कहा जाता), दूसरे int वेरिएबल के बगल में (इसे i कहें), arr[2] (अर्थात्, तीसरा एलिमेंट) को iअलियास दिया जाएगा यदि वे मेमोरी में एडजासेंट होते हैं।

# include <stdio.h>

int main()
{
  int arr[2] = { 1, 2 };
  int i=10;

  /* Write beyond the end of arr. Undefined behaviour in standard C, will write to i in some implementations. */
  arr[2] = 20;

  printf("element 0: %d \t", arr[0]); // outputs 1
  printf("element 1: %d \t", arr[1]); // outputs 2
  printf("element 2: %d \t", arr[2]); // outputs 20, if aliasing occurred
  printf("i: %d \t\t", i); // might also output 20, not 10, because of aliasing, but the compiler might have i stored in a register and print 10
  /* arr size is still 2. */
  printf("arr size: %lu \n", (long) (sizeof(arr) / sizeof(int)));
}

सी के कुछ इंप्लीमेंटेशन में यह पॉसिबल होता है क्योंकि एक ऐरे कांटीगुअस मेमोरी का एक ब्लॉक होता है, और ऐरे एलिमेंटों को मात्र एक एलिमेंट के आकार से गुणा किए गए उस ब्लॉक की बेगिननिंग के एड्रेस से ऑफसेट द्वारा रिफरेन्स किया जाता है। चूँकि C की कोई बाउंड नहीं होता है, इसलिए ऐरे के बाहर इंडेक्सिंग और एड्रेस करना पॉसिबल होता है। ध्यान दें कि उपर्युक्त अलियास बिहेवियर अनडिफाइंड बिहेवियर होता है। कुछ इंप्लीमेंटेशन स्टैक पर ऐरे और वेरिएबल्स के मध्य स्पेस छोड़ सकते हैं, उदाहरण के लिए, वेरिएबल्स को मेमोरी लोकेशन पर अलाइन करने के लिए जो आर्किटेक्चर के नेटिव वर्ड साइज़ के मल्टीप्ल होते हैं। सी स्टैण्डर्ड सामान्यतः यह स्पेसिफाये नहीं करता है कि डेटा को मेमोरी में कैसे रखा जाए। (आईएसओ/आईईसी 9899:1999, सेक्शन 6.2.6.1)।

किसी कंपाइलर के लिए किसी ऐरे की बाउंड से बाहर आने वाले एक्सेस के लिए अलियासिंग इफेक्ट्स को ऑमिट करना एरोनियस नहीं होता है।

अलियास पॉइंटर्स

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

स्पेसीफाई अलियास

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

my @array = (1, 2, 3);

foreach my $element (@array) {
    # Increment $element, thus automatically
    # modifying @array, since $element is ''aliased''
    # to each of @array's elements in turn.
    $element++;
}

print "@array \n";

परिणामस्वरूप 2 3 4 प्रिंट आउट हो जाएगा। यदि कोई अलियासिंग इफेक्ट्स को बायपास करना चाहता है, तो वह इंडेक्स वेरिएबल की कंटेंट्स को दूसरे में कॉपी कर सकता है और कॉपी को बदल सकता है।

ऑप्टिमाइजेशन के साथ कॉन्फ्लिक्ट्स

जब अलियासिंग पॉसिबल हो तो कंपाइलर का ऑप्टिमाइजेशन को अधिकांशतः वेरिएबल्स के बारे में कन्सेर्वटिवे असम्पशन बनानी पड़ती हैं। उदाहरण के लिए, किसी वेरिएबल का मान जानना (जैसे x 5 है) सामान्यतः कुछ ऑप्टिमाइजेशन की अनुमति देता है (जैसे कि कांस्टेंट प्रोपेगेशन)। यघपि, कंपाइलर किसी अन्य वेरिएबल को असाइनमेंट के पश्चात् इस जानकारी का उपयोग नहीं कर सकता है (उदाहरण के लिए, सी में, *y = 10) क्योंकि ऐसा हो सकता है *y xका अलियास हो। y = &x जैसे असाइनमेंट के पश्चात् ऐसा हो सकता है। इस असाइनमेंट के इफेक्केट्स रूप में *y, xका मान है भी बदल दिया जाएगा, इसलिए *y = 10 के पश्चात् स्टेटमेंटमें या जानकारी प्रोपेगेट करना की x 5 पोटेंशियली गलत होगा (यदि *y इनडिड में x का एक अलियास है)। यघपि, यदि पॉइंटर्स के बारे में जानकारी है, तो कांस्टेंट प्रोपेगेशन प्रोसेस एक क्वेरी बना सकती है जैसे: क्या x *yका अलियास हो सकता है? फिर, यदि उत्तर नहीं है, तो x = 5 सेफली प्रोपागेट किया जा सकता है।

अलियासिंग से इम्पक्टेड एक अन्य ऑप्टिमाइजेशन कोड रीऑर्डरिंग करना है। यदि कम्पाइलर यह निर्णय लेता है की x को *yद्वारा अलियास नहीं दिया गया है, तो फिर x वैल्यू का उपयोग करने या बदलने वाले कोड को असाइनमेंट *y = 10 से पहले ले जाया जा सकता है , यदि इससे शेड्यूलिंग में इम्रप्रूव होगा या अधिक लूप ऑप्टिमाइजेशन किए जाने में इनेबल होगा।

ऐसे ऑप्टिमाइजेशन को प्रेडिक्टेबल मैनर से इनेबल करने के लिए, प्रोग्रामिंग लैंग्वेज के लिए आईएसओ स्टैण्डर्ड (इसके नए #C99 एडिशन सहित, सेक्शन 6.5, पैराग्राफ 7 देखें) स्पेसीफाई करता है कि विभिन्न प्रकार के पॉइंटर्स का उपयोग करके एक ही मेमोरी लोकेशन तक पहुंचना इललीगल होता है (कुछ एक्सेप्शन के साथ)। इसलिए एक कंपाइलर यह मान सकता है कि ऐसे पॉइंटर्स अलियास नहीं देते हैं। यह नियम, जिसे स्ट्रिक्ट अलियासिंग रूल के रूप में जाना जाता है, कभी-कभी परफॉरमेंस में इम्प्रेसिव इनक्रीस की अनुमति देता है,[1] परन्तु कुछ को अन्यथा इललीग कोड को ब्रेक करने के लिए जाना जाता है। कई सॉफ़्टवेयर प्रोजेक्ट इंटेन्सिली C99 स्टैण्डर्ड के इस पार्ट को वॉयलेट करते हैं। उदाहरण के लिए, CPython|Python 2.x ने रिफरेन्स काउंटिंग को इम्प्लेमेंट करने के लिए ऐसा किया,[2] और इस ऑप्टिमाइजेशन को इनेबल करने के लिए पायथन 3 में मूल ऑब्जेक्ट स्ट्रक्चर में आवश्यक परिवर्तन किया। लिनक्स कर्नेल ऐसा इसलिए करता है क्योंकि स्ट्रिक्ट एलियासिंग इनलाइन कोड के ऑप्टिमाइजेशन में समस्याओं का कारण बनता है।[3] ऐसे केस में, जब जीसीसी के साथ कंपाइल किया जाता है, तो विकल्प -fno-strict-aliasing अनवांटेड ऑप्टिमाइजेशन के प्रिवेंट के लिए इनवोक किया जाता है जो अनएक्स्पेक्ट कोड उत्पन्न कर सकता है।

हार्डवेयर एलियासिंग

अलियासिंग शब्द का उपयोग उस सिचुएशन का वर्णन करने के लिए भी किया जाता है, जहां हार्डवेयर डिज़ाइन चॉइस या हार्डवेयर विफलता के कारण, मेमोरी सिलेक्शन प्रोसस में एक या अधिक उपलब्ध एड्रेस बिट्स का उपयोग नहीं किया जाता है।[4] यह एक डिज़ाइन डिसिशन हो सकता है यदि इन्मेसटाल्मोड री डिवाइस(डिवाइसों) का सपोर्ट करने के लिए आवश्यक से अधिक एड्रेस बिट्स उपलब्ध होता हैं। फेलीयर में, एक या अधिक एड्रेस बिट्स को एक साथ छोटा किया जा सकता है, या ग्राउंड (लॉजिक 0) या सप्लाई वोल्टेज (लॉजिक 1) के लिए फोर्स किया जा सकता है।

उदाहरण

इस उदाहरण के लिए, 8 स्थानों के साथ एक मेमोरी डिज़ाइन मानते हुए, 23 = 8 के पश्चात् से केवल 3 एड्रेस लाइन (या बिट्स) की आवश्यकता होती है। स्टैण्डर्ड काउंटर फैशन में, यूनिक मेमोरी लोकेशन का चयन करने के लिए एड्रेस बिट्स (ए 2 से ए 0 नामित) को डीकोड किया जाता है:

A2 A1 A0 Memory location
0 0 0 0
0 0 1 1
0 1 0 2
0 1 1 3
1 0 0 4
1 0 1 5
1 1 0 6
1 1 1 7

उपरोक्त टेबल में, एड्रेस बिट्स के 8 यूनिक कॉम्बिनेशन में से प्रत्येक एक अलग मेमोरी लोकेशन को सलेक्ट करता है। यघपि, यदि एक एड्रेस बिट (मान लीजिए A2) को ग्राउंड पर छोटा किया जाना है, तो टेबल को निम्नानुसार मॉडिफाई किया जाएगा:

A2 A1 A0 Memory location
0 0 0 0
0 0 1 1
0 1 0 2
0 1 1 3
0 0 0 0
0 0 1 1
0 1 0 2
0 1 1 3

इस केस में, A2 सदैव शून्य होने पर, पहले चार मेमोरी लोकेशन डुप्लिकेट हो जाते हैं और दूसरे चार के रूप में फिर से दिखाई देते हैं। मेमोरी लोकेशन 4 से 7 इनएक्सेसिबल हो गए हैं।

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

यह भी देखें

  • एंटीअलियासिंग
  • कंप्यूटर ग्राफिक्स सहित सिग्नल प्रोसेसिंग पर एप्लाइड होने पर शब्द के उपयोग के लिए अलियास

संदर्भ

  1. Mike Acton (2006-06-01). "Understanding Strict Aliasing".
  2. Neil Schemenauer (2003-07-17). "ANSI strict aliasing and Python".
  3. Linus Torvalds (2003-02-26). "Re: Invalid compilation without -fno-strict-aliasing".
  4. Michael Barr (2012-07-27). "Software Based Memory Testing".


बाहरी संबंध