निर्देश कैश सीमाओं के प्रभाव का प्रदर्शन कैसे करें

Question

मेरा ऑर्गेनिक विचार एक सुरुचिपूर्ण कोड उदाहरण देना था, जो निर्देश कैश सीमाओं के प्रभाव का प्रदर्शन करेगा। मैंने कोड का निम्नलिखित भाग लिखा है, जो टेम्पलेट मेटाप्रोग्रामिंग का उपयोग करके, समान कार्यों की एक बड़ी मात्रा बनाता है।

volatile int checksum; 
void (*funcs[MAX_FUNCS])(void); 

template <unsigned t> 
__attribute__ ((noinline)) static void work(void) { ++checksum; } 

template <unsigned t> 
static void create(void) { funcs[t - 1] = &work<t - 1>; create<t - 1>(); } 

template <> void create<0>(void) { } 

int main() 
{ 
    create<MAX_FUNCS>(); 

    for (unsigned range = 1; range <= MAX_FUNCS; range *= 2) 
    { 
     checksum = 0; 
     for (unsigned i = 0; i < WORKLOAD; ++i) 
     { 
      funcs[i % range](); 
     } 
    } 

    return 0; 
} 

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

piecewise निरंतर लाल वक्र का केवल छलांग वास्तव में होते हैं जहां सीमा के भीतर सभी कार्यों के लिए कुल स्मृति की खपत से अधिक लग रहे हैं परीक्षण मशीन पर एक कैश स्तर की क्षमता, जिसमें कोई समर्पित निर्देश कैश नहीं है। बहुत छोटी श्रेणियों के लिए (इस मामले में 4 से नीचे) हालांकि, रन टाइम अभी भी कार्यों की मात्रा के साथ बढ़ता है। यह शाखा भविष्यवाणी दक्षता से संबंधित हो सकता है, लेकिन चूंकि प्रत्येक फंक्शन कॉल इस मामले में बिना शर्त कूद को कम कर देता है, इसलिए मुझे यकीन नहीं है कि क्या कोई शाखा दंड होना चाहिए।

नीला वक्र काफी अलग व्यवहार करता है। रन रेंज छोटी श्रेणियों के लिए स्थिर है और उसके बाद लॉगरिदमिक बढ़ जाती है। फिर भी बड़ी श्रृंखलाओं के लिए, वक्र एक निरंतर एसिम्पटोट फिर से आ रहा है। दोनों घटता के गुणात्मक अंतर कैसे समझाया जा सकता है?

मैं वर्तमान में g++ -std=c++11 -ftemplate-depth=65536 के साथ जीसीसी मिनीजीडब्ल्यू Win32 x86 v.4.8.1 का उपयोग कर रहा हूं और कोई संकलक अनुकूलन नहीं कर रहा हूं।

किसी भी मदद की सराहना की जाएगी। मुझे प्रयोग में सुधार करने के तरीके के बारे में किसी भी विचार में दिलचस्पी है। अग्रिम में धन्यवाद!

Answer 1

सबसे पहले, मुझे यह कहना है कि मुझे वास्तव में यह पसंद है कि आपने इस समस्या से कैसे संपर्क किया है, यह जानबूझकर कोड सूजन के लिए वास्तव में साफ समाधान है। हालांकि, आपके परीक्षण के साथ अभी भी कई संभावित समस्याएं हो सकती हैं -

1. आप भी गर्म समय को मापते हैं। आपने यह नहीं दिखाया कि आपने अपना समय चेक कहाँ रखा है, लेकिन यदि यह आंतरिक लूप के आसपास है - तो पहली बार जब तक आप रेंज/2 तक नहीं पहुंच जाते, तब भी आप पिछले बाहरी पुनरावृत्ति के गर्मजोशी का आनंद लेंगे। इसके बजाए, केवल गर्म प्रदर्शन को मापें - कई आंतरिक पुनरावृत्ति को कई बार चलाएं (बीच में एक और लूप जोड़ें), और 1-2 राउंड के बाद ही टाइमस्टैम्प लें।

2. आप कई कैश स्तरों को मापने का दावा करते हैं, लेकिन आपका एल 1 कैश केवल 32k है, जहां आपका ग्राफ समाप्त होता है। यहां तक ​​कि "रेंज" के संदर्भ में यह गणना मानते हुए, प्रत्येक फ़ंक्शन ~ 21 बाइट्स (कम से कम मेरे जीसीसी 4.8.1 पर) है, इसलिए आप अधिकतर 256 केबी तक पहुंच जाएंगे, जो केवल आपके एल 2 के आकार को खरोंच कर देगा।

3. आपने अपने सीपीयू मॉडल को निर्दिष्ट नहीं किया है (i7 अब बाजार में कम से कम 4 पीढ़ी है, हैसवेल, आईवी ब्रिज, सैंडी ब्रिज और नेहलेम)। मतभेद काफी बड़े हैं, उदाहरण के लिए जटिल भंडारण नियमों और शर्तों के साथ सैंड्रिब्रिज के बाद एक अतिरिक्त यूओपी-कैश। आपकी बेसलाइन चीजों को जटिल भी कर रही है, अगर मुझे सही याद है कि पी 4 में ट्रेस कैश था जो प्रदर्शन के सभी प्रकार के प्रभाव भी पैदा कर सकता है। यदि संभव हो तो आपको उन्हें अक्षम करने के लिए एक विकल्प की जांच करनी चाहिए।

4. टीएलबी को मत भूलना - भले ही यह शायद इस तरह के कड़े संगठित कोड में कोई भूमिका निभाता न हो, फिर भी अद्वितीय 4k पृष्ठों की संख्या आईटीएलबी (128 प्रविष्टियों) से अधिक नहीं होनी चाहिए, और इससे पहले भी यदि आप ओएसएलबी टकराव से बचने के लिए अपने ओएस भौतिक कोड पृष्ठों को पर्याप्त रूप से पर्याप्त नहीं फैलाते हैं तो आप टकराव शुरू कर सकते हैं।