X86 पर सबसे खराब मामला निष्पादन का समय

पिछली पोस्ट में, मैंने वर्णन किया था कि एटम प्लेटफ़ॉर्म पर अंतराल अव्यवस्था को कैसे और क्यों मापा जाता है।



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



केवल इस मामले में, मैं कहूंगा कि इस घटना के सार को समझे बिना, मैंने जो शीर्षक लागू किया है, उसमें " सबसे खराब मामले का निष्पादन समय " है। यह x86 से जुड़ा नहीं है।



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



इस मामले में, यह पता चला है कि प्रत्येक रुकावट निर्देशों के बिल्कुल उसी क्रम को निष्पादित करता है। हर बार, इसे उसी समय निष्पादित किया जाना चाहिए। तो? ऐसे नहीं!



दो मुख्य जाल हैं।

1. कैश। फ़िल्टर के लिए गुणांक मेमोरी से लिया जाता है। वे एल 1 डी कैश, एल 2 कैश, एल 3 कैश (यदि कोई हो), या स्मृति में हो सकते हैं। आप पहले से नहीं कह सकते। यदि उदाहरण में वर्चुअल मेमोरी का उपयोग किया गया था, तो DTLB मिस अभी भी हो सकती है (या नहीं)। और अंत में, ISR कोड स्वयं L1I कैश, L2 आदि में हो सकता है। यहां अप्रत्याशितता का मुख्य स्रोत तथ्य यह है कि पहले निष्पादित कोड कैश को अपने डेटा के साथ रोक सकता है। और कैश को वास्तविक या HT कोर के बीच साझा किया जा सकता है।

2. हाइपरट्रेडिंग। दूसरे धागे में क्या निर्देश निष्पादित किए गए हैं, इसके आधार पर, पहला धागा अलग-अलग तरीकों से धीमा हो जाता है। (1-3 बार, एटम पर औसतन डेढ़ गुना) एक एलएलसी पाइपलाइन के साथ कोर में और एक इन-ऑर्डर पाइपलाइन के साथ डेसेलेरेशन तंत्र कोर में थोड़ा अलग है। औसत पर एटम के हाइपरट्रेड्स एक-दूसरे के प्रदर्शन को अधिक प्रभावित कर सकते हैं, क्योंकि उन्हें अधिक सीमित संसाधनों को साझा करना होगा, जैसे कि कैश एक्सेस।



क्या किया जा सकता है?

1. कैश। सबसे पहले, s / w prefetch का उपयोग करें। आईएसआर कोड की शुरुआत में, सबसे पहले कैश में फ़िल्टर गुणांक का आदेश दें।

अगर हम नए कोर में सामान्य L3 कैश के बारे में बात कर रहे हैं, तो एक और तरीका है। कैश में मेमोरी के एक क्षेत्र को आवंटित करने के लिए आप कैश कलरिंग का उपयोग कर सकते हैं, जो अन्य कोर पर चलने वाली प्रक्रियाओं को भीड़ देना अधिक कठिन होगा। यदि आप ओएस में वर्चुअल मेमोरी के साथ काम को पैच करते हैं, तो आप वर्चुअल मेमोरी के एप्लिकेशन टुकड़े दे सकते हैं जो केवल सामान्य स्तर के कैश के कुछ क्षेत्रों में गिर सकते हैं। आप कोर पर L3 कैश को 32 क्षेत्रों में विभाजित कर सकते हैं, और विभिन्न कोर पर मेमोरी आवंटित करते समय, गैर-अतिव्यापी क्षेत्रों का चयन करें। मैंने देखा कि कैसे यह तकनीक एक निश्चित कोड के निष्पादन समय को 400-900us से 500-600us तक बदलने में मदद करती है।

दुर्भाग्य से, इस तरह का जादू भौतिक स्मृति के काफी लंबे क्षेत्रों पर लागू नहीं है।



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



ऊपर वर्णित दोनों घटनाओं का अस्तित्व, वास्तव में, समग्र उत्पादकता को बढ़ाने में मदद करता है। बस कुछ रीयलटाइम अनुप्रयोगों के लिए, संभव छोटे वाले (100-500us), लेकिन अप्रत्याशित देरी बहुत अवांछनीय है। इसलिए, नए आर्किटेक्चर में विशेषताएं अधिक अनुमानित प्रदर्शन प्राप्त करने में मदद करने के लिए दिखाई देंगी। उदाहरण के लिए, महीन कैश प्रबंधन सॉफ़्टवेयर के लिए समर्थन दिखाई दे सकता है।