2015-05-15 7 views
8

मैं समझता हूं कि here समझाया गया है और साथ ही इसमें स्थिर शाखा भविष्यवाणी के लिए सीपीयू को संकेत शामिल होंगे।क्या BOOST_LIKELY और __builtin_expect अभी भी प्रासंगिक हैं?

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

यह देखते हुए, क्या ऐसे परिदृश्य हैं जहां कोड में शाखा संकेत हाल ही में इंटेल प्रोसेसर को लक्षित करने वाले सॉफ़्टवेयर के लिए उपयोगी हैं, शायद सशर्त वापसी का उपयोग कर रहे हैं या नेस्टेड के मामले में महत्वपूर्ण पथ में शाखा निर्देशों की संख्या से बचने के लिए ?

इसके अलावा, यदि ये अभी भी प्रासंगिक हैं, तो जीसीसी और अन्य लोकप्रिय कंपाइलरों पर किसी भी विनिर्देश की सराहना की जाती है।

पीएस मैं समयपूर्व अनुकूलन या इन मैक्रोज़ के साथ कोड को मिर्च करने के लिए नहीं हूं, लेकिन मुझे इस विषय में रूचि है क्योंकि मैं कुछ समय के साथ महत्वपूर्ण कोड के साथ काम कर रहा हूं और अभी भी जहां संभव हो वहां कोड अव्यवस्था को कम करना चाहता हूं।

धन्यवाद

+2

कोड उत्पन्न करना ताकि अपेक्षित पथ स्मृति में एक साथ हो, फिर भी कोड इलाके में सुधार हो, और संकलक इसे नियंत्रित कर सकता है। – Jester

+0

@ जेस्टर धन्यवाद। सहमत हैं कि यह निर्देश कैश प्रदर्शन में सुधार कर सकता है। आश्चर्य है कि अगर यह एक विशिष्ट प्रोसेसर को लक्षित करते समय जीसीसी द्वारा किया जाता है। – Jeevaka

+0

इसके अलावा, AFAIK, संकलन/लिंकिंग के दौरान विधियों को विभाजित नहीं किया जाता है। तो अगर छोटे तरीकों/नियंत्रण ब्लॉक में/अन्य लोगों के लिए इलाके में सुधार से ज्यादा मदद नहीं मिल सकती है। – Jeevaka

उत्तर

1

अपने प्रश्न के लिए टिप्पणी अनुभाग में के रूप में आप सही ढंग से यह पता लगाने की है कि:

  1. कोई स्थिर शाखा भविष्यवाणी इंटेल x86 CPUs पर अब और opcode मानचित्र में संकेत कर रहे हैं;
  2. "ठंड" सशर्त कूद के लिए गतिशील शाखा भविष्यवाणी गिरने वाले पथ की भविष्यवाणी करती है;
  3. कंपाइलर __builtin_expect का उपयोग कर सकता है ताकि पुन: व्यवस्थित किया जा सके ताकि अन्यथा उत्पन्न किए गए असेंबली में गिरावट के मामले के रूप में निर्माण किया जा सके।

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

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

इसलिए, __builtin_expect अभी भी (दुर्लभ) मामलों के लिए प्रासंगिक है जब 1) सही शाखा पूर्वानुमान जानकारी एक कंपाइलर द्वारा स्वचालित रूप से कम करने के लिए बहुत कठिन थी, और 2) कम से कम एक लक्ष्य आर्किटेक्चर पर अंतर्निहित हार्डवेयर भी जाना जाता था विश्वसनीय रूप से उन्हें गतिशील रूप से भविष्यवाणी करने में असमर्थ। यह देखते हुए कि कुछ कम-शक्ति प्रोसेसर में आदिम शाखा भविष्यवाणियों शामिल हैं जो शाखा इतिहास को ट्रैक नहीं करते हैं लेकिन हमेशा संभावित मार्ग चुनते हैं, यह फायदेमंद दिखने लगते हैं। आधुनिक इंटेल x86 हार्डवेयर के लिए, इतना नहीं।

+2

नहीं लिया गया शाखाएं अभी भी सस्ता हैं, भले ही दोनों सही ढंग से भविष्यवाणी करें: सही ढंग से पूर्वानुमानित होने पर किसी भी फ्रंट-एंड बुलबुले का कोई मौका नहीं है, और वे अधिक निष्पादन बंदरगाहों (इंटेल हैसवेल) पर चल सकते हैं। और एल 1 आई/यूओपी-कैश इलाके/घनत्व के लिए सभी गर्म कोड को एक साथ रखना बेहतर है। कंपाइलर्स अन्य निर्णयों के आधार पर भी अन्य निर्णय ले सकता है (उदाहरण के लिए कोड को स्वचालित रूप से चलाने के लिए संभव नहीं है, जो एक लूप को स्वचालित रूप से चलाने के लिए नहीं है)। या यदि कोई शर्त असंभव नहीं है तो शायद 'cmov' की बजाय शाखा का उपयोग करना चुनें। –

संबंधित मुद्दे