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

From Vigyanwiki
No edit summary
No edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 125: 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".


बाहरी संबंध