क्या वास्तव में प्रत्येक कोर का अपना पहला और दूसरा स्तर कैश है?

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

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

तीसरी पीढ़ी के कोर i7 आर्किटेक्चर प्रोसेसर में कैश के साथ आरेख पर विचार करें। हालाँकि, यह किस पीढ़ी के लिए भी महत्वपूर्ण नहीं है।

अमूर्तता के इस उच्च स्तर पर, नेहेल्म, वेस्टमेरे, सैंडी ब्रिज, आइवी ब्रिज और हैसवेल के बीच अंतर ध्यान देने योग्य नहीं है। वैसे, सैंडी ब्रिज के अंदर यह सब कैसे काम करता है, इसका सबसे विस्तृत विवरण हेन्नेसी (हाँ, यह एक) लेख में पाया जा सकता है।

हम देखते हैं कि तीसरे स्तर का कैश (एलएलसी), सबसे बड़ा, एक साथ सभी कोर का कार्य करता है - वे दोनों जो "टिन खींचते हैं" - कम-प्राथमिकता वाली प्रक्रियाएं, और जो बाहरी डिवाइस या स्थानीय एपीआईसी टाइमर से व्यवधान प्राप्त करते हैं, जो जितना संभव हो उतना उच्च होना चाहिए। प्रक्रिया और परिणाम तेजी से उत्पादन। पिछले स्तर के कैश की एविक्शन पॉलिसी LRU का एक प्रकार है। इसलिए, अधिक से अधिक बार एक निश्चित कोर कैश का उपयोग करता है, एलएलसी का अधिक हिस्सा इसे प्राप्त करेगा। प्राथमिकताएं? प्राथमिकताएं क्या हैं ?? वैसे, बहुत महत्वपूर्ण कार्यों को अक्सर उच्च प्राथमिकता वाले लोगों के रूप में बड़े करीने से प्रोग्राम नहीं किया जाता है, और इसलिए विशेष रूप से बहुत अधिक मेमोरी और कैश की आवश्यकता होती है। एक उच्च-प्राथमिकता वाला कार्य अक्सर एक बाहरी घटना की उम्मीद करता है, जबकि इसके डेटा और कोड को एलएलसी से बाहर किया जाता है। मैंने इसके बारे में पहले ही किसी तरह लिख दिया था , लेकिन उस पोस्ट की टिप्पणियों में मैंने L1 / 2 कैश की विशिष्टता के बारे में प्रश्न का गलत उत्तर दिया।

यदि आप ऊपर दिए गए आरेख को देखते हैं, तो ऐसा लगता है कि प्रत्येक कोर का अपना कैश है, कम से कम 256 किलोबाइट आकार में। .Text और .data के लिए पर्याप्त से अधिक कई रीयलटाइम कार्य। खैर, कम से कम 32kb का डेटा स्टोर करने के लिए + 32kb का कोड कैश में कई घड़ी चक्रों के प्रतिक्रिया समय के साथ हमेशा गणना की जा सकती है? यह सत्यापित करना आसान है।

उच्च रक्तचाप और बिजली प्रबंधन को अक्षम करें। मैं निम्नलिखित माइक्रोबेनमार्क को लॉन्च करता हूं:

हेल्पर कार्य करता है

#define POOL_SIZE_L1D_LINES 512 #define POOL_SIZE_L2_LINES 8192 // This can differ on your CPU. Check with CPUID or some system diagnostics tool #define POOL_SIZE_LLC_LINES 6*1024*1024/64 // Yes, I waste 3/4 of space for the sake of test simplicity // 1 cache line == 1 linked list item. // Pointer length is hard coded to 8 bytes (Intel 64) struct list_item { unsigned long long int tick; list_item *next; unsigned char padding[48]; }; // Build a linked list of size N with pseudo-random pattern void build_list(list_item *head, int N, int A, int B) { int C = B; list_item *current = head; for (int i = 0; i < N - 1; i++) { current->tick = 0; C = (A*C + B) % N; current->next = (list_item*)&(head[C]); current = current->next; } } // Touch first N elements in a linked list void warmup_list(list_item* current, int N) { bool write = (N > POOL_SIZE_L2_LINES) ? true : false; for(int i = 0; i < N - 1; i++) { current = current->next; //No write is needed to keep a line in L1,but looks like it is needed to keep it in L2! if (write) current->tick++; // FIXME AK: to check on HSW } } 

build_list सूची को आरंभ करता है ताकि प्रीफ़ेचर को एक नियमित एक्सेस पैटर्न न मिले। उसी समय, पूरी सूची कैश में है, उस स्तर पर जहां वह फिट बैठता है।

अब नंबर 2 कर्नेल पर, हम सूची ट्रैवर्सल शुरू करते हैं और मापते हैं कि प्रत्येक पुनरावृत्ति के लिए औसत समय कितना आवश्यक है।

लिंक्ड सूची ट्रैवर्सल गति माप

 void measure(list_item* head, int N) { unsigned __int64 i1, i2, avg = 0; for (int j = 0; j < 50; j++) { list_item* current = head; #if WARMUP_ON while(in_copy) warmup_list(head, N); #else while(in_copy) spin_sleep(1); #endif i1 = __rdtsc(); for(int i = 0; i < N; i++) { current->tick++; current = current->next; } i2 = __rdtsc(); avg += (i2-i1)/50; in_copy = true; } printf("%i\n", avg/N); } 

विभिन्न आकारों की सूचियों के माध्यम से पारित होने के समय को मापने वाली धारा का कोड इस प्रकार होगा:

विभिन्न लिंक किए गए सूची आकारों के लिए माप

 // We initialize the linked list only once, and make it big enough to make sure // we do not observe effects of spatial locality but only effects of temporal locality // Magic numbers 509, 509 <= Hull-Dobell Theorem criteria build_list(head, POOL_SIZE_LLC_LINES*2, 509, 509); for (int i = 10; i < POOL_SIZE_L1D_LINES; i+=5) { warmup(head, i); measure(head, i); }; for (int i = POOL_SIZE_L1D_LINES; i < POOL_SIZE_L2_LINES; i+=50) { warmup(head, i); measure(head, i); }; for (int i = POOL_SIZE_L2_LINES; i < POOL_SIZE_LLC_LINES*2; i+=1000) { warmup(head, i); measure(head, i); }; 

तीसरे स्तर में कैश को रोकते हुए एक दूसरी स्ट्रीम जोड़ें: इसे कोर नंबर 3 पर स्पिन करने दें, और आगे और पीछे 18 एमबी डेटा कॉपी करें। 18MB - LLC स्कोर करने के लिए सुनिश्चित करें। इसे पहले धागे के साथ सिंक्रनाइज़ करें, ताकि लगभग किसी भी समय केवल उनमें से एक सक्रिय रूप से कैश के साथ काम करेगा। (मुझे पता है कि स्पिनलॉक कार्यान्वयन गलत और अक्षम है, और सब कुछ केवल उचित समय के लिए धन्यवाद काम करता है।)

एक धागा जो दूसरे कोर पर चलता है और एलएलसी का उपभोग करता है

 list_item *area1 = (list_item *)malloc(POOL_SIZE_LLC_LINES*64*2); list_item *area2 = (list_item *)malloc(POOL_SIZE_LLC_LINES*64*2); while (true) { while(!in_copy) spin_sleep(1); #if DISRUPT_ON memcpy(area1, area2, POOL_SIZE_LLC_LINES*64*3); memcpy(area2, area1, POOL_SIZE_LLC_LINES*64*3); #else spin_sleep(10); #endif in_copy = false; }; 

हम तीन प्रकार के मापन करेंगे:

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

नियंत्रण के लिए, मैंने एक परीक्षण भी चलाया, जिसमें कीट प्रवाह का डेटा अपने "एल" एल 2 में फिट होता है। जैसा कि अपेक्षित था, इस मामले में पहले थ्रेड द्वारा सूची की क्रॉल गति पर कोई प्रभाव नहीं था। (सैद्धांतिक रूप से, संघर्ष की यादों को देखा जा सकता है, लेकिन मैंने उन्हें नहीं देखा)

यहाँ माप परिणाम हैं:

क्षैतिज - सूची में आइटम की संख्या। कार्यक्षेत्र - सीपीयू चक्र एक तत्व से गुजरने पर खर्च किया जाता है। दिलचस्प है, "चरण" प्राप्त करने के लिए (एक ग्राफ जिस पर कैश की सीमाएं दिखाई देती हैं) आपको बस बेंचमार्क को थोड़ा बदलने, स्थानिक इलाके को जोड़ने की आवश्यकता है।

तुलना के लिए, जिस कंप्यूटर पर मैंने यह परीक्षण चलाया, उस समय मेमोरी पदानुक्रम के तत्वों तक पहुंच निम्नानुसार है:

• L1D हिट = 4 चक्र,
• L2 हिट = 11 चक्र,
• एलएलसी हिट = 31 चक्र,
• DRAM हिट = ~ 100 चक्र,

सूची के माध्यम से एक क्लिक पर खर्च होने वाला समय आनुपातिक है
L1D_hit * P (L1D_hit) + L2_hit * P (L2_hit) + LLC_hit * P (LLC_hit) + DRAM_hit * P (DRAM_it) जहां P इस कैश स्तर में अगली सूची आइटम को खोजने की संभावना है। यानी
P (L1D_hit) + P (L2_hit) + P (LLC_hit) + P (DRAM_hit) = 1
विशिष्ट संभाव्यता वितरण कैश के सापेक्ष सूची के आकार पर निर्भर करता है, और इसे Vtune, oprofile या Linux perf के उपयोग से मापा जा सकता है। उदाहरण के लिए, 16,384 वस्तुओं (512 किलोबाइट) की एक निश्चित सूची लंबाई के लिए यहाँ एक Vtune संभावना माप है।

	अबाधित	व्याकुल	वार्मअप
L1 हिट%	0.08	0	63
L2 हिट%	72	0.07	0.1
LLC हिट%	25	2.6	22
DRAM ने% मारा	3	97	15
DTLB मिस%	21	66	37

Vtune पुष्टि करता है कि "ब्लू" और "ग्रीन" विकल्पों के बीच के प्रदर्शन में अंतर सूची में अगले आइटम के लिए संक्रमण के कारण विभिन्न स्तरों के कैश में मिसाइलों के अनुपात में निहित है। यह देखा जा सकता है कि यदि उच्च-प्राथमिकता वाली धारा के डेटा को तीसरे स्तर के कैश से बाहर धकेल दिया गया, तो वे संबंधित कोर के पहले और दूसरे स्तर के कैश में स्वचालित रूप से अक्षम हो जाते हैं । हालांकि, स्वयं मापा संभावनाओं की संख्या मेरे लिए अप्रत्याशित थी। "ब्लू" कॉलम में कोई आश्चर्य नहीं है, लेकिन लाल में मुझे L1 में अधिक हिट की उम्मीद है, और "हरे" कॉलम में L2 में बहुत अधिक हिट हैं। हालांकि, बाद वाला आंशिक रूप से 16k सूची आइटम के क्षेत्र में हरे रंग के ग्राफ पर समझ से बाहर है।

यदि पहला धागा व्यवधान पर जागता है, तो "ब्लू" संस्करण में भी आईडीटी और इसके लिए आईएसआर कोड को मेमोरी से खींचना होगा, क्योंकि यह पहले से ही एल 1 आई, एल 2 और एलएलसी से बाहर निचोड़ा हुआ होगा। मेरे महान अफसोस के लिए, कोर i7 आर्किटेक्चर के आधुनिक प्रोसेसर में एक निश्चित कोर द्वारा अनन्य उपयोग के लिए एलएलसी के "लॉक अप" भाग की क्षमता नहीं है। इसलिए, एलएलसी और एल 1 से महत्वपूर्ण डेटा को हटाने से बचने का एकमात्र तरीका है, और एल 2 और एल 1 से, उन्हें समय-समय पर अद्यतन करना है, भले ही वे इस समय की आवश्यकता न हों।

इस पोस्ट में मैं यह बिल्कुल नहीं कहना चाहता कि मुझे कोर i7 की वास्तुकला में किसी प्रकार की समस्या मिली। कैश का यह संगठन (अधिक संसाधन उन लोगों को मिलता है जिन्हें सामान्य मामले में अधिक आवश्यकता होती है) (डेस्कटॉप, अधिकांश सर्वर लोड) प्रदर्शन में सुधार करता है। ऊपर वर्णित प्राथमिकता उलटा का मामला कार्यों के एक संकीर्ण वर्ग में उत्पन्न हो सकता है, आमतौर पर वास्तविक समय प्रणालियों से संबंधित होता है। इसके अलावा, प्रीफैचर्स को आमतौर पर मदद करनी चाहिए। वे इस परीक्षा में केवल इसलिए असफल हो जाते हैं क्योंकि मैंने छद्म यादृच्छिक पते पर संकेत दिए हैं।

वाह! ऐसा लगता है कि मैंने सिर्फ एक बड़ा पाठ लिखा है, जिसका सार एक ट्वीट पर डाला जा सकता है: “जब एक कैश लाइन को एलएलसी द्वारा एक कोर से निकाला जाता है, तो उसी कैश लाइन को एल 1 और / या एल 2 से निकाला जाता है जो इसके मालिक हैं। तो कैश को गर्म करना उपयोगी हो सकता है। "