क्या ऐसे सीपीयू हैं जो इस संभव L1 कैश प्रदर्शन अनुकूलन का प्रदर्शन करते हैं?


9

जब L1 कैश के साथ CPU एक लेखन करता है, तो सामान्य रूप से क्या होता है (यह मानते हुए कि कैश लाइन जो इसे लिख रहा है वह पहले से ही L1 कैश में है) कैश (डेटा को अपडेट करने के अलावा) उस कैश लाइन को गंदा के रूप में चिह्नित करता है , और कुछ समय बाद अपडेट किए गए डेटा के साथ लाइन को लिख देगा।

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

मेरा प्रश्न: क्या सीपीयू हैं जो इस अनुकूलन को करते हैं?

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

तो, क्या एक सीपीयू है जो इस तरह से लिखने का अनुकूलन करने की कोशिश करता है?


11
यह कहा जाता है कि कंप्यूटर विज्ञान में वास्तव में दो मुश्किल समस्याएं हैं: कैश अमान्य होना, चीजों को अच्छी तरह से नाम देना और ऑफ-बाय-वन त्रुटियां। यह इस बात का उदाहरण है कि इनमें से पहला क्यों मुश्किल है।
मेसन व्हीलर

@poncho आप कहते हैं कि "कोई व्यक्ति जो कैश के व्यवहार को सुनने में सक्षम है, जो मैं कर रहा हूं वह कटौती करने में सक्षम नहीं होना चाहिए।" अब अगर कुछ सीपीयू ने इस "स्मार्ट राइट-बैक" सुविधा को लागू किया है जो कैश को अमान्य नहीं करता है जब तक कि डेटा को वास्तव में अपडेट नहीं किया जाता है, तो मेमोरी पदानुक्रम में सीपीयू से एक स्तर आगे जाकर, कोई ट्रैफ़िक / समय का पालन करने में सक्षम होगा वास्तविक लेखन और डमी के बीच अंतर लिखते हैं। क्या यह आप के बारे में चिंतित हैं?
कोडआर्टिस्ट

@poncho इसके अलावा, आपका वास्तविक प्रश्न एक बेहतर विशेषाधिकार प्राप्त / सुरक्षित मोड को लागू करने के बारे में लगता है जो उपयोग की जानकारी को लीक नहीं करता है। शायद आपको यह पूछना चाहिए? ...
TheCodeArtist

1
@TheCodeArtist: ठीक है, वहाँ क्रिप्टोग्राफ़िक साइडस्क्रीन हमलों को प्रकाशित किया गया है जहां एक एन्क्रिप्शन प्रोग्राम पर एक ही सीपीयू के एक अलग कोर पर चल रहे प्रोग्राम द्वारा हमला किया जा सकता है, हमले के कार्यक्रम को साझा कैश की निगरानी करके। मेरा मानना ​​है कि ऐसा प्रोग्राम संभावित रूप से यह पता लगा सकता है कि क्या L1 कैश लाइनों को फ्लश किया गया था, और इसलिए सीपीयू चर्चा के तहत अनुकूलन करता है, तो मैं उस कार्यक्रम के बारे में जानकारी घटा सकता हूं, जिसमें मैं दिलचस्पी रखता हूं। मैं 'सुरक्षित मोड' के बारे में बात नहीं कर रहा हूं, क्योंकि मैं सीपीयू या ओएस को संशोधित करने की क्षमता नहीं मानता हूं।
पोंचो

4
भले ही आज यह सच हो, पर कल सच होने की गारंटी नहीं है।
pjc50

जवाबों:


4

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

(पेज 7 और) https://cseweb.ucsd.edu/classes/fa14/cse240A-a/pdf/08/CSE240A-MBT-L15-Cache.ppt.pdf

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

रजिस्टर के कैश में वर्तमान मूल्य प्राप्त करना

इसके अलावा, सभी सैद्धांतिक समाधानों में किसी न किसी रूप में सॉफ़्टवेयर कार्यान्वयन (कोडांतरक) की आवश्यकता होती है। निकटतम मैंने एआरएम वास्तुकला से संबंधित पाया है, जो कैश हेरफेर के लिए अनुमति देता है। इसके अतिरिक्त, आपको अपने वांछित CPU के लिए कैश लाइन का आकार भी जानना होगा। आप कैश सामग्री को ध्यान से मेमोरी में द्वितीयक स्थान पर, लाइन-आकार के वेतन वृद्धि में पढ़ सकते हैं, और इसकी तुलना डेटा से कर सकते हैं जो रजिस्टरों (या एल 1 कैश लाइनों, इस मामले में) के बारे में लिखा जा सकता है।

सीपीयू कैश सामग्री पढ़ें

वहां से, आप एक सॉफ्टवेयर-आधारित प्रणाली तैयार कर सकते हैं जो समान पुनर्लेखन को रोकती है। जबकि यह थोड़ा सरल है, ऐसा इसलिए है क्योंकि समाधान किसी भी सीपीयू के लिए लागू होना चाहिए जो मौजूद है।

एक और संभावना है कि मैं कैशे के संबंध से संबंधित पाया गया:

एफ़पी सहवास के बारे में एक विकिपीडिया लेख से प्रासंगिक मार्ग

मुख्य मुद्दा जिसने मेरा ध्यान आकर्षित किया, इस मुद्दे के संबंध में, स्नार्फिंग विवरण था:

यह एक ऐसा तंत्र है जहां एक कैश नियंत्रक एक मेमोरी मास्टर की अपनी कॉपी को अपडेट करने के प्रयास में पता और डेटा दोनों को देखता है जब दूसरा मास्टर मुख्य मेमोरी में एक स्थान को संशोधित करता है। जब कोई लेखन कार्रवाई किसी स्थान पर देखी जाती है जिसमें कैश की एक प्रतिलिपि होती है, तो कैश कंट्रोलर नए डेटा के साथ स्नार्फ़्ड मेमोरी लोकेशन की अपनी प्रति को अपडेट करता है।

दूसरे शब्दों में, संभवतः पहले से ही तंत्र हैं। यह सिर्फ इतना है कि आपके द्वारा सुझाए गए अनुकूलन के लिए उनका उपयोग नहीं किया जा सकता है। आपको ऐसे सॉफ़्टवेयर को लागू करना होगा जो पढ़ने / लिखने की तुलना करते हैं।


कैश रजिस्टरों में वर्तमान मूल्यों तक पहुंचना भी संभव है - लेकिन ऐसा करना कुछ खतरनाक है। हुह, इसका कोई मतलब नहीं है। क्या आपका मतलब सीपीयू रजिस्टर है? कंपाइलर जेनरेट या हाथ से लिखे हुए asm कोड उन रजिस्टरों को रखने के लिए रजिस्टरों का उपयोग करता है, जिन पर वह काम कर रहा है ...
पीटर कोर्ड्स

यदि आप इसे सॉफ़्टवेयर में लागू करने का प्रयास कर रहे हैं, तो आपके पास केवल कंपाइलर जनरेट कोड होगा जो if (mem != x) { mem = x; }इसके बजाय करता है mem = x;। यह केवल कभी-कभी एक बहु-थ्रेडेड प्रोग्राम में साझा कैश लाइनों के लिए एक अनुकूलन है, क्योंकि लेखन अन्य थ्रेड्स पढ़ने के साथ हस्तक्षेप करता है।
पीटर कॉर्ड्स

1
"स्नार्फ़िंग" का इससे कोई लेना-देना नहीं है। यह सिर्फ पैसिव स्नूपिंग है। सीपीयू कैश एमईएसआई का उपयोग करता है ताकि उनके पास सुसंगत राइट-बैक कैश हो।
पीटर कॉर्डेस

@PeterCordes यदि आपको मेरा उत्तर अप्रिय लगता है, तो मैं क्षमा चाहता हूँ। हालाँकि, ऐसा प्रतीत होता है कि आपके पास मामले पर मुझसे अधिक अंतर्दृष्टि है। तो, सवाल का जवाब खुद क्यों नहीं दिया? मेरी प्रतिक्रिया स्पष्ट रूप से आपके मानकों से अपर्याप्त थी ...


3

L1 कैश पर लिखना एक बहुत ही महत्वपूर्ण समय है।

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

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

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

एक उदाहरण के रूप में, यदि आपके पास सी कोड है [i] = x / y; विभाजन x / y को अधिकांश CPU पर प्रदर्शन करने के लिए एक असाधारण लंबा समय लगता है। हालाँकि, [i] परिणाम को संचय करने से पहले काम करने के लिए आवश्यक अधिकांश कार्य विभाजन खत्म होने से बहुत पहले हुए हैं; केवल एक चीज गायब है आठ परिणाम बाइट्स की चाल कैश लाइन पर है। संचय समाप्त होने तक कैश लाइन को फ्लश करने वाला एक ऑपरेशन स्वचालित रूप से प्रतीक्षा करेगा। [I] पढ़ने वाला एक ऑपरेशन संभवतः परिणाम को सीधे विभक्त से प्राप्त करने के लिए पुनर्निर्देशित करेगा।


सुसंगतता के लिए MESI का उपयोग करने वाला एक कैश अभी भी RFO कर सकता है, लेकिन यदि डेटा एक ही बार तैयार होने के बाद तुलना करता है, तो संशोधित के बजाय अनन्य अवस्था में लाइन छोड़ दें। हार्डवेयर में ऐसा नहीं होने का असली कारण यह है कि यह अतिरिक्त कैश की लागत को पढ़ता है क्योंकि डेटा कैशे में आता है, और इसके लिए एक तरह के परमाणु रीड / तुलना / राइट साइकल (गंदे बिट की वैकल्पिक सेटिंग के साथ) की आवश्यकता होती है जो इसे बेकार करता है पाइपलाइन से क्रियान्वयन।
पीटर कॉर्डेस

1

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

क्या इस तरह के अनुकूलन से सीपीयू को कैश में कुछ लिखने की जरूरत नहीं होगी? क्योंकि प्रत्येक कैश लाइन लेखन अब एक तुलना ऑपरेशन के साथ होगा, जो मुफ्त नहीं है।

तो, वास्तव में अब अनुकूलन बहुत अस्पष्ट कारक पर निर्भर करेगा: एक औसत सॉफ्टवेयर कितनी बार एक ही डेटा के साथ अपनी कैशेबल मेमोरी को फिर से लिखता है।


यह तुलना सीपीयू तर्क के भीतर लागू की जाएगी। इसके लिए अतिरिक्त सीपीयू ऑपरेशन की आवश्यकता नहीं होगी, लेकिन सिग्नल का समय बढ़ सकता है, जो एक समस्या हो सकती है या नहीं।
जिग्गीस्टार

@ जिग्गीस्टार खैर, मैं एक हार्डवेयर मास्टर नहीं हूं, लेकिन मुझे इस विचार की आदत हो गई है कि सब कुछ एक लागत के साथ आता है। तो कैश लाइन के खिलाफ ऑपरेशन की तुलना करता है। यह तेज हो सकता है। लेकिन यह अभी भी लागत है। और मुझे लगता है कि कार्यान्वयनकर्ताओं ने इसे भुगतान नहीं करने का फैसला किया। कुछ सोच और मापने के बाद भी हो सकता है।
व्लादिस्लाव रास्ट्रुसनी

1
लेकिन आप समय के बारे में बात कर रहे हैं, जहां लागत केवल फाटकों की संख्या में वृद्धि हो सकती है।
जिगिसिस्टार

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

1
और इनमें से प्रत्येक लिखता है कि कैश लाइन को संशोधित किया गया है या नहीं। इसलिए जब दूसरा लेखन होता है, तो कैश लाइन यह नहीं जानती है कि यह संशोधित है या नहीं (अभी तक)। यह मज़ेदार होने वाला है।
gnasher729
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.