एक प्रोग्रामर की सख्त नजर के तहत इंटेल वीट्यून एम्पलीफायर एक्सई 2011 बीटा

मैंने नए Intel VTune एम्पलीफायर XE 2011 बीटा को देखने और उपयोग के उदाहरण के बारे में एक लेख लिखने का फैसला किया। सच है, लेखन प्रक्रिया में, एम्पलीफायर का उपयोग करने से लेकर इसके परीक्षण तक का आंशिक रूप से जोर दिया गया है। लेकिन यह भी अच्छा है, मुझे उम्मीद है कि इंटेल के डेवलपर्स इच्छाओं को ध्यान में रखेंगे और उपकरण के अगले संस्करण में बदलाव करेंगे। और सामान्य तौर पर मैं अपनी और सभी की आलोचना करूंगा। :)







मैं थोड़ी दूर से शुरू करूंगा, अन्यथा सवाल उठेंगे, मुझे एक कोड की आवश्यकता क्यों थी जिसे मुझे अनुकूलित करना था। सी ++ के लिए एक स्थिर कोड विश्लेषक के विकास के दौरान, मुझे बहुत ही विदेशी कोड टुकड़ों से निपटना होगा। क्या केवल प्रोग्रामर के साथ नहीं आते हैं। और यहां तक ​​कि ऐसे कंपाइलर, जैसे विजुअल C ++ या Intel C ++, नहीं, नहीं, और वे अगले "स्क्वीगल" पर गिरेंगे।



हमारे PVS-Studio स्थैतिक विश्लेषक में वस्तुओं के प्रकार को निर्धारित करने से संबंधित एक नहीं-अच्छी जगह है। उदाहरण के लिए, एक निर्माण है:

  typedef int A;
 टाइम्डिफ एबी;
 बी मायवैल्यू; 

और टाइप बी की "गणना" करना आवश्यक है ताकि यह पता लगाया जा सके कि यह इंट के अलावा कुछ भी नहीं है। इस तरह के उदाहरणों के साथ, ज़ाहिर है, कोई मुश्किल नहीं है और सब कुछ काम करता है। हालांकि, बहुत जटिल परिस्थितियां हैं। मैं एक कोड का उदाहरण देता हूँ जिसमें प्रदर्शित किया जाता है कि विभिन्न कठिनाइयाँ सामने आने लगती हैं:



जब चर X के प्रकार का पता लगाने की कोशिश की जाती है, तो हम इसके प्रकार को नामस्थान B में देखेंगे और इसे वहां नहीं पाएंगे। फिर हम देखेंगे कि हमें नाम स्थान सी में क्या देखने की जरूरत है और हमने इसे नहीं पाया। अब हमें नाम स्थान B ... शाश्वत चक्र को देखने की आवश्यकता है। बेशक, यह एक साधारण मामला है और इसके साथ कोई समस्या नहीं है। लेकिन यहां टाइप्डिफ, टेम्प्लेट, विरासत में मिली कक्षाएं जोड़ें। कभी-कभी आश्चर्यजनक रूप से जटिल चीजें सामने आती हैं, और विशेष रूप से नहीं। यह खासतौर पर टेम्प्लेट के साथ कोड में स्पष्ट है।



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



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



एक सरल लेकिन प्रभावी रोक तंत्र बनाया गया है। यदि ऑब्जेक्ट के प्रकार को प्राप्त करने पर हमें एन्कोडेड प्रकार के लिए एक पॉइंटर मिलता है जिसे हमने पहले से काम कर चुके हैं, तो रोक दें। आरंभ करने के लिए, बस एक वर्ग बनाया गया था जिसमें std :: set <const void *> * m_pGuardPointers शामिल थे। यदि सेट में पहले से ही एक पॉइंटर है, तो यह रुकने का समय है।



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

  टाइपडिफ लंबे लंबे; लंबी x; 

तुरंत निम्नलिखित फॉर्म की एक क्लास लिखी गई (संक्षिप्त रूप में दी गई):

  क्लास CPointerDuplacateGuard
 {
   स्थिर कास्ट size_t QuickMaxSize = 10;
   const void * m_ptrs [QuickMaxSize];
   size_t m_index;
   std :: set <const void *> * m_pGuardPointers;
 सार्वजनिक:
   CPointerDuplacateGuard ();
   CPointerDuplacateGuard (कास्ट CPointerDuplacateGuard * जनक);
   ...
 }; 

शुरुआत में, हम 10 तत्वों के एक साधारण सरणी में पॉइंटर्स को सहेजते हैं और देखते हैं, और उसके बाद ही हम सेट का उपयोग करते हैं और शुरू करते हैं। यह बहुत बेहतर हो गया है, लेकिन इस तंत्र के बिना सब कुछ कई गुना धीमा है।



और यहाँ मैंने तय किया कि यह इंटेल वीट्यून एम्पलीफायर एक्सई 2011 बीटा को देखने का समय था। बहुत अच्छा कारण है। यहाँ, प्रोफाइलर का स्वागत है। यह प्रश्न का उत्तर देने में मदद करेगा, क्या प्रदर्शन केवल std :: set के उपयोग से जुड़ा हुआ है, या निरंतर पॉइंटर चेक के उपयोग से मंदी शुरू की गई है। यदि मुख्य प्रदर्शन ड्रॉप std :: set के कारण है, तो आपको QuickMaxSize का मान बढ़ाने की आवश्यकता है। यह std के उपयोग में देरी करेगा :: सबसे चरम मामले के लिए सेट। यदि एल्गोरिथ्म धीमा हो जाता है, तो आगे सोचें।



मुझे तुरंत कहना होगा कि मेरे पास Intel VTune एम्पलीफायर XE 2011 बीटा के साथ ठीक से काम करने का धैर्य नहीं था। वह काम में अकल्पनीय ब्रेकिंग का परिचय देता है। हालांकि मेरे पास एक काफी शक्तिशाली प्रणाली है (4 कोर, 8 जीबी मेमोरी), अगर इंटेल वीटीएन एम्पलीफायर एक्सई 2011 बीटा विंडो खुली है, तो कोड के माध्यम से एक सरल आंदोलन भी परिश्रम और झटके के साथ किया जाता है। इसके अलावा, Intel VTune एम्पलीफायर XE 2011 खुद कुछ नहीं करता है। बल्कि, यह प्रोसेसर को लोड करता है, लेकिन यह नहीं लिखता है कि यह क्या करता है। निराधार नहीं होने के लिए मैं डेमो स्क्रीनशॉट दे दूंगा।



स्पष्टता के लिए, मैंने devenv.exe को 4 कोर में संलग्न किया।



तो, अब मेरे पास एक परियोजना खुली है, कुछ भी नहीं होता है। आंकड़ा बताता है कि चौथे कोर का लोड शून्य के करीब है:



अब मैं सिर्फ Intel VTune एम्पलीफायर XE 2011 लॉन्च कर रहा हूं। मैं अभी इसे शुरू कर रहा हूं। मैं प्रोजेक्ट एनालिसिस नहीं करता और कुछ भी नहीं करता। लेकिन चौथा कोर पहले से ही पूरी तरह से व्याप्त है:



यह तुरंत किसी भी तरह काम करने के लिए असहज हो जाता है। जहाँ भी संभव हो वहाँ का वातावरण धीमा होने लगता है। यदि आप Intel VTune एम्पलीफायर XE 2011 विंडो को बंद करते हैं, तो ब्रेक लगाना तुरंत गायब हो जाता है और कर्नेल लोड फिर से शून्य के करीब हो जाता है। शायद लॉन्च किया गया Intel VTune एम्पलीफायर XE 2011 कुछ उपयोगी काम करता है। लेकिन जो स्पष्ट नहीं है। अगर वह करता है, तो आपको कम से कम यह दिखाना चाहिए। मुझे किसी तरह की गलती का अहसास हुआ।



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



विश्लेषण आश्चर्य के बिना किया गया था:



और मुझे एक उपयोगी परिणाम मिला:



अधिकांश समय std :: _ ट्री में, स्मृति को आवंटित करने और मुक्त करने के कार्यों में व्यतीत होता है। यह प्रोग्रामर को तुरंत स्पष्ट हो जाएगा कि मुख्य मंदी एसटीडी :: सेट के उपयोग से जुड़ी है।



यदि आप हॉटस्पॉट मोड में एम्पलीफायर चलाते हैं, तो समस्या क्षेत्र बहुत अधिक स्पष्ट हो जाएगा:



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



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



हालांकि, न केवल उपस्थिति को अभिव्यक्त किया। कभी-कभी किसी कारण से यह कोड के गलत खंड को फेंकता है जो आवश्यक है।



हालांकि, मैंने अभी भी वांछित परिणाम प्राप्त किया। यह पता चला कि यदि आप सरणी का मान 64 पर सेट करते हैं, तो प्रदर्शन लगभग उसी स्तर पर लौटता है। नया सबसिस्टम व्यावहारिक रूप से काम को धीमा नहीं करता है। सुधार:



स्थिर कास्ट size_t QuickMaxSize = 64;



इसकी पुष्टि एम्पलीफायर ने की है। अब पूरी तरह से अलग कार्य, जैसे कि strncmp, सामने आए हैं:

निष्कर्ष

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



Intel VTune एम्पलीफायर टूल के संबंध में पोस्ट कुछ हद तक महत्वपूर्ण है। जाहिर तौर पर यह एक डेवलपर के दर्द की तरह है। वे एक और कार्यक्रम की कोशिश कर रहे हैं जो दुनिया में सुधार करेगा, और जब आप इसके साथ काम करना शुरू करते हैं, तो आप समझते हैं कि आपने गुणवत्ता नियंत्रण पर विपणन या सुंदर चित्रों पर अधिक खर्च किया। खैर, यह किस तरह का प्रोफाइल है जो धीमा हो जाता है? जूते के बिना शोमेकर। :)



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