सीखना कैसे सही तरीके से बेंचमार्क करना 2: कंपाइलर कैसे पीछे हटता है

उपयुक्त बेंचमार्क संख्या प्राप्त करना आधी लड़ाई है, लेकिन दूसरी छमाही की सही व्याख्या की जा सकती है, कुछ नया सीखना, और लागू करने में सक्षम होना। सामान्य और सामान्य बिल्ड के बीच 100x के अंतर ने आश्चर्यचकित किया, मैंने गहराई से खुदाई करने का फैसला किया। परिणामस्वरूप, मैंने बेहतर सीखा कि डिबग में क्या हो रहा है; स्टूडियो और (नहीं मिला) द्वारा 2005 और 2008 के बीच अंतर के लिए देखा; यह पता लगाना कि बिल्ड बिल्ड को कुछ मिनटों में 3 गुना कैसे तेज किया जाए (हमने ब्लॉक को बैक में हिट के खिलाफ रखा); "टेक एंड रन" विधि का उपयोग करते हुए, मुझे ऐसे परिणाम मिले जो कॉपीराइट वालों से 3.5 गुना अलग हैं (कार्रवाई में नारकीय बल x64!)। और हँसी के लिए, मैंने एक बुरा, बेकार अंडर-वेक्टर बनाम अच्छा (बुरा 100 गुना तेजी से निकला) मापा। कट के तहत विवरण।

मैं संदर्भों के साथ शुरुआत करना चाहता हूं, अन्यथा बाद में खोजना मुश्किल है। पोस्ट शुरू , उनका टेस्ट कोड , मेरा टेस्ट कोड ।

कंपकंपी को खत्म करते हुए, मैं मूल प्रश्न पर लौट आया: 100 से अधिक बार ब्रेक, यह बहुत धीमा है जहां वे आते हैं। किसी और का परीक्षण अच्छा है, लेकिन उसका अधिक परिचित, लिखित, लॉन्च किया गया। यह एक परियोजना बनाने के लिए आलसी था, कॉम्स्ट्रिंग से संकलन बहुत तेज है।

cl2005 /O2 /EHsc 1.cpp
std it++ res=49995000, 28.5 msec
std ++it res=49995000, 28.6 msec
my res=49995000, 19.0 msec

cl2005 /EHsc 1.cpp
std it++ res=49995000, 534.2 msec
std ++it res=49995000, 437.6 msec
my res=49995000, 69.9 msec


उफ़। परिणाम, हालांकि, अलग-अलग हैं: वे लोग 30 गुना धीमे हैं, मेरे पास केवल 10 हैं। उन लोगों के लिए, वेतन वृद्धि 3 गुना कम है, मेरे पास लगभग 20% है। मैं क्या गलत कर रहा हूँ? संकलक और प्रतिबंधित पुस्तकालय क्या वास्तव में इतने भयंकर हैं? ठीक है, हम इसे अभी डाल देंगे, हम इसकी जाँच करेंगे।

cl2008 /O2 /EHsc 1.cpp
std it++ res=49995000, 64.3 msec
std ++it res=49995000, 63.4 msec
my res=49995000, 19.0 msec

cl2008 /EHsc 1.cpp
std it++ res=49995000, 732.1 msec
std ++it res=49995000, 678.8 msec
my res=49995000, 70.0 msec


Mdja। वास्तव में मतभेद हैं, केवल विपरीत दिशा में: वीएस 2005 रिलीज बिल्ड हालांकि तीन गुना तेज था। सुधार स्पष्ट हैं; जाहिर है, स्टूडियो नंबर 2008 में एससीएल तीन गुना अधिक सुरक्षा बन गया है, जैसा कि। _SECURE_SCL 0 पर गति समान है। (आगे देखते हुए, अधिकांश अन्य परीक्षण बहुत अधिक समान हैं।) मैं और क्या गलत कर रहा हूं? कंपाइलर अब समान है, std :: वेक्टर समान प्रतीत होता है, आउटपुट असमान है: मैं गलत तरीके से संकलन कर रहा हूं। मेरा मतलब है, संकलक कुंजियों का विचलन। हम समाधान में देखते हैं, वहाँ एक बल्कि फैलने वाला कॉम्स्ट्रोक है।

/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TP /errorReport:prompt


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

cl2008 /Od /EHsc /MDd 1.cpp
std it++ res=49995000, 6026.1 msec
std ++it res=49995000, 1953.9 msec
my res=49995000, 66.5 msec

cl2008 /Od /EHsc /MDd /RTC1 1.cpp
std it++ res=49995000, 7572.0 msec
std ++it res=49995000, 2385.3 msec
my res=49995000, 101.8 msec

cl2008 /Od /EHsc /MDd /RTC1 /ZI 1.cpp
std it++ res=49995000, 18722.0 msec
std ++it res=49995000, 7131.8 msec
my res=49995000, 511.9 msec


अब, अब सब कुछ मनुष्यों की तरह है: और वेक्टर ट्रैवर्सल एक कमीने की तरह धीमा हो जाता है, और पोस्ट-इंक्रीमेंट धीमा होने लगा। Nishtyak! आप यह पता लगा सकते हैं कि मामला क्या है। पढ़ने के कुछ मिनटों में cl /? तीन सरल समझने योग्य बातें पता चली हैं (एक प्रति कुंजी), जो अभी भी नई हैं (अच्छी तरह से भूल गए पुराने लोगों को देखें) और इसलिए आश्चर्य की बात है।

/ MDd ने डिबग लाइब्रेरी (जो महत्वपूर्ण नहीं है) और स्वचालित रूप से सक्षम / D _DEBUG (जो महत्वपूर्ण है) प्रमाणित किया। इसमें से, SCL ने _SECURE_SCL द्वारा शामिल किए गए लोगों के अलावा, इसके अंदर चेक का एक अतिरिक्त पैकेट शामिल किया, जिसने सफलतापूर्वक पोस्ट-इन्क्रीमेंट को 8 गुना धीमा कर दिया, और 3 बार मिसकैरेज द्वारा पूर्व-इंक्रीमेंट।

/ RTC1 में स्टैक विफलता चेक और अनइंस्टॉल किए गए चर शामिल हैं। यदि आप डिस्मैस डिबगर के माध्यम से चलते हैं, तो आप देख सकते हैं कि विभिन्न कार्यों के लिए कॉल की आंतरिक लूप ऊँची एड़ी के जूते में दिखाई दिया (++; = =, * और दो विध्वंसक)। प्रत्येक कॉल की जाँच की जानी चाहिए: क्या होगा यदि वह इसे उठाता है और यह स्टैक कैसे तोड़ता है! ऐसा करने के लिए, मार्कर के 256 बाइट्स से थोड़ा कम एसटीएल में अधिभारित एक या किसी अन्य ऑपरेटर के प्रत्येक (प्रत्येक) कॉल के लिए स्टैक पर धकेल दिया जाता है। बाय-बाय, एक और 20% और इसलिए सबसे टॉप-एंड परफॉर्मेंस नहीं है।

/ ZI, हालांकि, सभी को रौंदता है और बैंक को घर ले जाता है। यह एडिट एंड कंटिन्यू है। संभवतः मक्खी पर कार्यक्रम को ठीक करना और फिर से शुरू करना सुविधाजनक है (मैं खुद नहीं जानता, मैं इसका उपयोग नहीं करता हूं)। सुविधा के लिए आपको भुगतान करना होगा और कीमत ब्रेक से 3 गुना अधिक है।

रिलीज के मुकाबले डीबग में कुल पोस्ट-इंक्रीमेंट 291 गुना धीमा हो जाता है (!!!)। जो तुरंत सवाल उठाता है: मेरे पास 291 बार क्यों हैं, और उन लोगों के पास केवल 95 हैं? मैं मूल परीक्षा एकत्र कर रहा हूं, अंत की प्रतीक्षा पर्याप्त धैर्य नहीं है, गणना को 10 गुना कम करके, मेरे सिर में समय को 10 से गुणा करना। यह पता चला है कि

it++, x86, release: 1.00
++it, x86, release: 1.00
it++, x86, debug: 275.7
++it, x86, debug: 101.9

it++, x64, release: 0.87779
++it, x64, release: 0.87753
it++, x64, debug: 83.2849
++it, x64, debug: 27.1557


संख्याओं को देखते हुए, मेरे x86 से रिहाई में उन्होंने 13% का आयकर लिया, और डिबग में उन्हें लूट लिया, केवल जांघिया, मोज़े और चप्पल छोड़कर। निराशाजनक रूप से निराशाजनक, लेकिन कुछ भी नहीं। वैसे भी, मैं XP को नहीं दूंगा, मेरे लिए सात मुश्किल है, यह बहुत ही पारदर्शी है, साथ ही हम सर्विस पैक के लिए इंतजार कर रहे हैं।

परिणामों के अनुसार, यह स्पष्ट है कि डिबग बिल्ड के नारकीय ब्रेक के लिए किसे दोषी ठहराया जाए। 2 बार इसे खाता है _SECURE_SCL, 5 बार अनुकूलन अक्षम करता है, 3 गुना (++ यह) से 8 गुना (यह ++) गडल्स को _DEBUG, 1.2 बार / RTC के तहत चेक करता है, और 3 बार / ZI के साथ समाप्त होता है, 2 और * ५ * a * १.२ * ३ = २ 1.2,, अनाज से एक चिकन, पूरे कोड में है ... चेक, ब्रेक ३०० (तीन सौ) बार हैं। हाथ चिकन खाते हैं, बेशक। शाश्वत तीन में से, अब केवल एक ही सवाल शेष है: क्या करना है?

सामान्य तौर पर, आप बहुत सारी चीजें कर सकते हैं, लेकिन लंबे समय तक। हालाँकि, 2 मिनट में आप 2 उपयोगी चीजें कर सकते हैं। सबसे पहले, यदि आप एडिट एंड कंटिन्यू (यदि यह आपके प्रोजेक्ट पर काम करता है) और नियमित सोवियत PDBs उत्पन्न करने के लिए उपयोग नहीं करने के लिए एक दृढ़ इच्छाशक्ति वाला निर्णय लेते हैं, तो यह 5 गुना नहीं, तो 3 गुना तेजी से काम करना शुरू कर देता है। 2, / RTC चेक डिसेबल, बेशक, कूल। हालांकि! MSDN को पढ़ने से दिलचस्प व्यावहारिक क्रम_चेक का पता चलता है। उन। आप इन चेक पॉइंट को प्रोजेक्ट में विशेष रूप से लगातार कार्यों के लिए, या पूरे STL के लिए अक्षम कर सकते हैं। हम बाहरी को दो पंक्तियों के साथ अनुभाग में शामिल करते हैं, आनंद लेते हैं।

#pragma runtime_checks("",off)
...
#pragma runtime_checks("",restore)


जब हम ++ का उपयोग करते समय इसे 7 सेकंड के बजाय 2 सेकंड का उपयोग करते हैं, तो हम 18 सेकंड के बजाय अपने ईमानदार 6 सेकंड वापस प्राप्त करते हैं। ++ का उपयोग करने की आवश्यकता के बारे में निष्कर्ष यह आश्वस्त है। बिक्री का निर्माण लगभग 3 गुना तेज है। लाभ! हम कोशिश करते हैं कि जो मूल परीक्षा में जाना जाता है, उसे लागू करें, यह इसी तरह से निकलता है। कम से कम अच्छे पुराने x86 पर।

vanilla
it++, x86, debug: 275.7
++it, x86, debug: 101.9

#pragma runtime_checks, /Zi instead of /ZI
it++, x86, debug: 102.2
++it, x86, debug: 30.0


एक बुरा, कुटिल, बेकार और आदिम अंडर-वेक्टर, जो बिल्कुल भी कुछ नहीं कर सकता है, डिबग में अपनी ईमानदार 0.066 सेकंड दिखाता है, उन। यह ++ संस्करण की तुलना में 90 गुना तेज है, या ++ संस्करण का 30 गुना है। पोस्ट की शुरुआत में लगभग 100 बार मैंने झूठ बोला । उसके पास केवल एक चेक है: पहुंच पर सूचकांक की शुद्धता (जो, हालांकि, वेक्टर से आवश्यक चेक के लगभग 99% को कवर करता है); पूर्व और बाद की वेतन वृद्धि के साथ ध्यान अनुपस्थित हैं, पुनरावृत्तियों के साथ। इसका कोई मतलब नहीं है। लेखक कुछ भी संकेत नहीं करता है। बेंचमार्क स्पष्ट रूप से सिंथेटिक है। वेक्टर को शाब्दिक रूप से 3 मिनट और संबंधित कार्यक्षमता, उन में लिखा गया है। एसटीएल की तुलना में मौजूद नहीं है। डिबग बिल्ड गति आवश्यक रूप से महत्वपूर्ण नहीं है; अनावश्यक सत्यापन महत्वपूर्ण हो सकता है; विकास की गति सभी के लिए महत्वपूर्ण है और हमेशा; सत्य हमेशा प्रोफाइलर को बताएगा।

_SECURE_SCL के बारे में याद रखें, _DEBUG के बारे में, कंपाइलर कुंजियों के बारे में, #pragma runtime_checks के बारे में। प्रभाव, mneee, तेजस्वी है। (अंतर ने मुझे व्यक्तिगत रूप से अंत में 300 बार मार दिया। और 3 से 5 बार के अंतर के कारण / ZI के बजाय / Zi के बाद भी लाश को खाया। "मुझे इसके बारे में पता था, लेकिन मुझे कोई पता नहीं था।")

आपके लिए सही बेंचमार्क। और त्वरित डिबगिंग।