एक सीपीयू कैश लाइन लिखने के बाद स्मृति में फ़्लश कब होती है?

Question

मैं सी # में काम कर रहा हूं और यदि संभव हो तो unsafe कोड से बचना चाहता हूं। यदि मेरे पास एक ऑब्जेक्ट या सरणी है जिसे कैश लाइन भरने के लिए आकार दिया गया है और मैं ऑब्जेक्ट के ऑब्जेक्ट या इंडेक्स के प्रत्येक फ़ील्ड को लिखना चाहता हूं, तो क्या सीपीयू लिखित-टू-लाइन को फ्लश करने से पहले सभी लिखने के लिए प्रतीक्षा करेगा या क्या यह शुरुआती फ्लश करेगा जब केवल एक या कुछ लिखने आए हैं?

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

Answer 1

स्वाभाविक रूप से सीपीयू के रूप में कुछ स्मृति संभव के रूप में पहुँचता बनाने की कोशिश करेंगे, लेकिन जरूरी मतलब नहीं है कि कि "अपने" स्मृति के ब्लॉक के रूप में जब तक आप इसे करना चाहते हैं कैश में रखा जाएगा।

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

अपने लेखन समय के करीब होने के कारण निश्चित रूप से यह सुनिश्चित होगा कि उस ऑपरेशन की अवधि के लिए स्मृति को कैश में रखा जाएगा।

Answer 2

क्या सीपीयू लिखित-रेखा को फ्लश करने से पहले सभी लिखने के लिए प्रतीक्षा करेगा या क्या यह केवल एक या कुछ लिखने के बाद शुरू हो जाएगा?

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

क्या मुझे त्वरित उत्तराधिकार में दिनचर्या के अंत में सभी लिखना चाहिए?

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

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