मेमोरी बैरियर/बाड़ का ओवरहेड

Question

मैं वर्तमान में सी ++ कोड लिख रहा हूं और अपने कोड में बहुत सारी मेमोरी बाधाओं/बाड़ का उपयोग कर रहा हूं। मुझे पता है कि एक एमबी ने कंपाइलर और हार्डवेयर को इसके बारे में लिखने/पढ़ने के लिए पुन: व्यवस्थित नहीं करने के लिए कहा है। लेकिन मुझे नहीं पता कि यह ऑपरेशन रनटाइम पर प्रोसेसर के लिए कितना जटिल है।

मेरा प्रश्न है: इस तरह के बाधा का रनटाइम ओवरहेड क्या है? मुझे google के साथ कोई उपयोगी उत्तर नहीं मिला ... ओवरहेड नगण्य है? या गंभीर प्रदर्शन समस्याओं के लिए एमबी के भारी उपयोग की ओर जाता है?

सर्वश्रेष्ठ संबंध।

Answer 1

निर्देश के बारे में सोचने का प्रयास करें। यह सीपीयू तर्क के संदर्भ में कुछ भी जटिल नहीं करता है, लेकिन यह तब तक इंतजार करने के लिए मजबूर करता है जब तक कि सभी पाठ और लेखन मुख्य स्मृति के लिए प्रतिबद्ध नहीं होते हैं। तो लागत वास्तव में मुख्य स्मृति (और बकाया पढ़ने/लिखने की संख्या) तक पहुंचने की लागत पर निर्भर करती है।

मुख्य मेमोरी एक्सेस करना आमतौर पर काफी महंगा होता है (10-200 घड़ी चक्र), लेकिन एक अर्थ में, यह कार्य बाधा के बिना भी किया जाना चाहिए, यह केवल कुछ अन्य निर्देशों को निष्पादित करके छुपाया जा सकता है ताकि आप लागत बहुत ज्यादा महसूस नहीं किया।

यह सीपीयू (और कंपाइलर्स) को निर्देशों को फिर से निर्धारित करने की क्षमता को भी सीमित करता है, इसलिए अप्रत्यक्ष लागत भी हो सकती है, साथ ही पास के निर्देशों को भी अंतःस्थापित नहीं किया जा सकता है जो अन्यथा अधिक कुशल निष्पादन अनुसूची उत्पन्न कर सकता है।

Answer 2

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

सामान्य रूप से कुछ अलग-अलग प्रकार की बाधाएं होती हैं, इसलिए मतभेदों को समझना सहायक हो सकता है। जेल का उल्लेख करने वाले एक अवरोध की आवश्यकता है उदाहरण के लिए लॉक शब्द (पीपीसी पर lwsync, या st4.rel उदाहरण के लिए ia64) को साफ़ करने से पहले mutex कार्यान्वयन में। सभी पढ़ और लिखना पूर्ण होना चाहिए, और केवल बाद में पाइपलाइन में निर्देश जिनके पास कोई मेमोरी एक्सेस नहीं है और प्रगति मेमोरी ऑपरेशंस पर कोई निर्भरता निष्पादित नहीं की जा सकती है।

एक और प्रकार का बाधा वह प्रकार है जिसे आप लॉक प्राप्त करते समय mutex कार्यान्वयन में उपयोग करेंगे (उदाहरण, पीपीसी पर isync, या r64 पर instr.acq)। इसका भविष्य के निर्देशों पर असर पड़ता है, इसलिए यदि एक गैर-निर्भर भार का प्रीफेच किया गया है तो इसे त्याग दिया जाना चाहिए। उदाहरण:

 
if (pSharedMem->atomic.bit_is_set()) // use a bit to flag that somethingElse is "ready" 
{ 
    foo(pSharedMem->somethingElse) ; 
} 

एक अधिग्रहण बाधा (उधार ia64 शब्दावली) के बिना, अपने कार्यक्रम अप्रत्याशित परिणाम दे सकते अगर somethingElse फ़्लैग करने बिट की जांच की जांच से पहले एक रजिस्टर में इसे बनाया है पूरा हो गया है।

एक तीसरा प्रकार का बाधा है, आमतौर पर कम उपयोग किया जाता है, और स्टोर लोड ऑर्डरिंग को लागू करने के लिए आवश्यक है। इस तरह के आदेश लागू करने के निर्देशों के लिए निर्देशों के उदाहरण हैं, पीपीसी (हेवीवेट सिंक) पर सिंक, आईए 64 पर एमएफ, स्पैक्स पर मेम्बर # स्टोरलोड (टीएसओ के लिए भी आवश्यक)।

का उपयोग ia64 स्यूडोकोड वर्णन करने के लिए की तरह, मान लें कि एक के बीच एक कोई गारंटी है कि लोड की दुकान इस प्रकार है में एक म्यूचुअल फंड के बिना

 
st4.rel 
ld4.acq 

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

क्योंकि म्यूटेक्स कार्यान्वयन बहुत ही संभावित रूप से केवल कार्यान्वयन में बाधाओं को हासिल करने और रिलीज करने का उपयोग करते हैं, इसलिए मुझे उम्मीद है कि इसका एक अवलोकन प्रभाव यह है कि लॉक रिलीज के बाद मेमोरी एक्सेस वास्तव में कभी-कभी "महत्वपूर्ण खंड में" हो सकती है।