उदाहरण के रूप में LLVM टेस्ट-सूट का उपयोग करके प्रोग्राम मेट्रिक्स के परीक्षण और संग्रह के लिए लचीली प्रणाली

परिचय

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

एलएलवीएम टेस्ट-सूट

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

परीक्षण-सूट संकलक और बेंचमार्किंग के लिए स्वाभाविक रूप से उपयोगी है, लेकिन इसका उपयोग कुछ अन्य शोध कार्यों के लिए भी किया जा सकता है जहां कुछ C / C ++ कोड आधार की आवश्यकता होती है। जिन लोगों ने एक बार डेटा विश्लेषण के क्षेत्र में कुछ करने का प्रयास किया था, मुझे लगता है, स्रोत डेटा की कमी और विखंडन की समस्या का सामना करना पड़ा। एक परीक्षण-सूट, हालांकि इसमें बड़ी संख्या में एप्लिकेशन शामिल नहीं हैं, लेकिन इसमें एकीकृत डेटा संग्रह तंत्र है। संग्रह में अपने स्वयं के अनुप्रयोगों को जोड़ना, अपने विशेष कार्य के लिए आवश्यक मीट्रिक एकत्र करना बहुत सरल है। इसलिए, मेरी राय में, परीक्षण-सूट (परीक्षण और बेंचमार्किंग के मुख्य कार्यों के अलावा) एक मूल परियोजना के लिए एक अच्छा विकल्प है, जिसके आधार पर आप उन कार्यों के लिए अपने डेटा संग्रह का निर्माण कर सकते हैं जहां आपको प्रोग्राम कोड की कुछ विशेषताओं और कार्यक्रमों की कुछ विशेषताओं का विश्लेषण करने की आवश्यकता होती है।

एलएलवीएम परीक्षण-सूट संरचना

test-suite |----CMakeLists.txt //  CMake ,   ,  | //   .. | |---- cmake | |---- .modules //        , | //   API    | |---- litsupport //  Python,      test-suite, | //    lit (  LLVM) | |---- tools //   :    | //     (    | // ),    .. | | //     | |---- SingleSource //   ,       | // .        . | |---- MultiSource //   ,      | //  .        | //  . | |---- MicroBenchmarks // ,   google-benchmark.   | //  ,    ,  | //       | |---- External //    ,     test-suite,  | // ,     (  ) | // -    

संरचना सरल और सीधी है।

कार्य सिद्धांत

जैसा कि आप देख सकते हैं, सीएमके और एक विशेष लिट-टेस्ट प्रारूप सभी कार्यों के लिए जिम्मेदार हैं, जो मैट्रिक्स के असेंबली, लॉन्च और संग्रह का वर्णन करते हैं।

यदि हम इसे बहुत सार तरीके से समझते हैं, तो यह स्पष्ट है कि इस प्रणाली का उपयोग करने वाली बेंचमार्किंग प्रक्रिया सरल और बहुत अनुमानित है:


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

1. बिल्डिंग परीक्षण अनुप्रयोगों।

एक बिल्ड सिस्टम के रूप में, यह C / C ++ CMake कार्यक्रमों के लिए वास्तविक मानक बन गया है। CMake प्रोजेक्ट को कॉन्फ़िगर करता है और उपयोगकर्ता की प्राथमिकताओं के आधार पर फाइल, निंजा आदि फाइल बनाता है। प्रत्यक्ष निर्माण के लिए।
हालांकि, टेस्ट-सूट में सीएमके न केवल एप्लिकेशन बनाने के तरीके के बारे में नियम बनाता है, बल्कि स्वयं परीक्षणों को भी कॉन्फ़िगर करता है।

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

सबसे मानक .test फ़ाइल का उदाहरण

 RUN: cd <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football ; <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football/football VERIFY: cd <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football ; <some_path_to_build_directory>/tools/fpcmp %o football.reference_output 

एक्सटेंशन .test वाली फ़ाइल में निम्न अनुभाग हो सकते हैं:

• PREPARE - किसी भी क्रिया का वर्णन करता है जो अनुप्रयोग को लॉन्च करने से पहले किया जाना चाहिए, विभिन्न इकाई परीक्षण रूपरेखाओं में पहले से मौजूद विधि के समान;
• RUN - एप्लिकेशन को चलाने का तरीका बताता है;
• बहुत - आवेदन के सही संचालन की जांच करने का वर्णन करता है;
• METRIC - उन मैट्रिक्स का वर्णन करता है जिन्हें मानक में अतिरिक्त रूप से एकत्र करने की आवश्यकता होती है।

इनमें से कोई भी खंड छोड़ा जा सकता है।

लेकिन चूंकि यह फ़ाइल स्वचालित रूप से उत्पन्न होती है, यह बेंचमार्क के लिए सीएमके फ़ाइल में है जो वर्णन करता है: ऑब्जेक्ट फ़ाइलों को कैसे प्राप्त करें, उन्हें आवेदन में कैसे इकट्ठा किया जाए, और फिर इस आवेदन के साथ क्या किया जाना चाहिए।

डिफ़ॉल्ट व्यवहार की बेहतर समझ के लिए और यह कैसे वर्णित है, कुछ CMakeLists.txt के उदाहरण पर विचार करें

 list(APPEND CFLAGS -DBREAK_HANDLER -DUNICODE-pthread) #      (         ..     CMak,       ) list(APPEND LDFLAGS -lstdc++ -pthread) #       

फ़्लैग्स को प्लेटफ़ॉर्म के आधार पर सेट किया जा सकता है, DetectArchitecture फ़ाइल को टेस्ट-सूट cmake मॉड्यूल में शामिल किया गया है, जो लक्ष्य प्लेटफ़ॉर्म को निर्धारित करता है जिस पर बेंचमार्क चलाए जाते हैं, इसलिए आप बस पहले से ही एकत्रित डेटा का उपयोग कर सकते हैं। अन्य डेटा भी उपलब्ध है: ऑपरेटिंग सिस्टम, बाइट ऑर्डर, आदि।

 if(TARGET_OS STREQUAL "Linux") list(APPEND CPPFLAGS -DC_LINUX) endif() if(NOT ARCH STREQUAL "ARM") if(ENDIAN STREQUAL "little") list(APPEND CPPFLAGS -DFPU_WORDS_BIGENDIAN=0) endif() if(ENDIAN STREQUAL "big") list(APPEND CPPFLAGS -DFPU_WORDS_BIGENDIAN=1) endif() endif() 

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

और फिर आपको .test फ़ाइल की पीढ़ी सुनिश्चित करने की आवश्यकता है। इसके लिए टेट्स-सूट इंटरफ़ेस क्या उपकरण प्रदान करता है?

2 मूल मैक्रोज़ llvm_multisource और llvm_singlesource हैं , जो अधिकांश तुच्छ मामलों के लिए पर्याप्त हैं।

• llvm_multisource का उपयोग किया जाता है यदि एप्लिकेशन में कई फाइलें होती हैं। यदि आप अपने सीएमके में इस मैक्रो को कॉल करते समय स्रोत कोड फ़ाइलों को पैरामीटर के रूप में पास नहीं करते हैं, तो वर्तमान निर्देशिका में स्थित सभी स्रोत कोड फ़ाइलों को भवन के लिए आधार के रूप में उपयोग किया जाएगा। वास्तव में, परीक्षण-सूट में वर्तमान में इस मैक्रो के इंटरफ़ेस में परिवर्तन हो रहे हैं, और स्रोत फ़ाइलों को मैक्रो पैरामीटर के रूप में स्थानांतरित करने की वर्णित विधि मास्टर शाखा में स्थित वर्तमान संस्करण है। इससे पहले, एक और प्रणाली थी: स्रोत कोड वाली फाइलें स्रोत चर को लिखी जानी थीं (जैसा कि यह 7.0 में जारी था), और मैक्रो ने किसी भी पैरामीटर को स्वीकार नहीं किया। लेकिन कार्यान्वयन का मूल तर्क वही रहा है।
• llvm_singlesource का मानना ​​है कि प्रत्येक .c / .cpp फ़ाइल एक अलग बेंचमार्क है और प्रत्येक के लिए एक अलग निष्पादन फ़ाइल एकत्र करता है।

डिफ़ॉल्ट रूप से, दोनों मैक्रो एक निर्मित एप्लिकेशन को लॉन्च करने के लिए ऊपर वर्णित हैं जो एक कमांड उत्पन्न करता है जो बस इस एप्लिकेशन को कॉल करता है। और एक्सटेंशन .reference_output (संभावित प्रत्ययों के साथ .reference_output.little-endian, .reference_output.big-endian) के साथ फ़ाइल में स्थित अपेक्षित आउटपुट के साथ तुलना करने के कारण शुद्धता की जांच होती है।

यदि यह आपको सूट करता है, तो आवेदन शुरू करने और निम्नलिखित मेट्रिक्स: कोड आकार (अनुभागों में), संकलन समय, लिंक समय, निष्पादन समय प्राप्त करने के लिए यह एक अतिरिक्त लाइन (कॉल llvm_multisource या llvm_singlesource) पर्याप्त है।

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

प्रत्येक चरण में क्रियाओं का वर्णन करने के लिए एपीआई में मैक्रोज़ हैं।

प्रारंभिक चरण के लिए llvm_test_prepare मैक्रो के बारे में लिखने के लिए बहुत कुछ नहीं है, जिन आदेशों को आपको निष्पादित करने की आवश्यकता है, उन्हें बस एक पैरामीटर के रूप में वहां पारित किया जाता है।

लॉन्च अनुभाग में क्या आवश्यक हो सकता है? सबसे अनुमानित मामला यह है कि एप्लिकेशन कुछ तर्कों, इनपुट फ़ाइलों को स्वीकार करता है। इसके लिए, llvm_test_run मैक्रो है, जो मापदंडों के रूप में केवल एप्लिकेशन स्टार्टअप तर्कों (निष्पादन योग्य फ़ाइल के नाम के बिना) को स्वीकार करता है।

 llvm_test_run(--fixed 400 --cpu 1 --num 200000 --seed 1158818515 run.hmm) 

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

 llvm_test_verify("cat %o | grep -q 'exit 0'") # %o -   placeholder   ,   lit.          lit,    ,    .    lit (  ,   LLVM)      (   <a href="https://llvm.org/docs/CommandGuide/lit.html"> </a>) 

लेकिन क्या होगा अगर कुछ अतिरिक्त मीट्रिक एकत्र करने की आवश्यकता है? इसके लिए एक llvm_test_metric मैक्रो है।

 llvm_test_metric(METRIC < > <,   >) 

उदाहरण के लिए, डेस्टोन के लिए, इसके लिए विशिष्ट मीट्रिक प्राप्त किया जा सकता है।

 llvm_test_metric(METRIC dhry_score grep 'Dhrystones per Second' %o | awk '{print $4}') 

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

नतीजतन, हमें फॉर्म के कुछ CMakeLists.txt मिलते हैं

 #       llvm_test_run(--fixed 400 --cpu 1 --num 200000 --seed 1158818515 run.hmm) llvm_test_verify("cat %o | grep -q 'exit 0'") llvm_test_metric(METRIC score grep 'Score' %o | awk '{print $4}') llvm_multisource() # llvm_multisource(my_application)    

एकीकरण को अतिरिक्त प्रयासों की आवश्यकता नहीं होती है, यदि एप्लिकेशन पहले से ही CMake का उपयोग करके बनाया गया है, तो CMakeList.txt में परीक्षण-सूट में आप विधानसभा के लिए मौजूदा CMake को शामिल कर सकते हैं और कुछ सरल मैक्रो कॉल जोड़ सकते हैं।

2. परीक्षण चल रहा है

अपने काम के परिणामस्वरूप, CMake ने निर्दिष्ट विवरण के अनुसार एक विशेष परीक्षण फ़ाइल तैयार की। लेकिन इस फ़ाइल को कैसे निष्पादित किया जाता है?

lit हमेशा कुछ कॉन्फ़िगरेशन फ़ाइल lit.cfg का उपयोग करता है, जो तदनुसार, परीक्षण-सूट में मौजूद है। इस कॉन्फ़िगरेशन फ़ाइल में, रनिंग टेस्ट के लिए विभिन्न सेटिंग्स को इंगित किया जाता है, जिसमें निष्पादन योग्य परीक्षण का प्रारूप भी शामिल है। टेस्ट-सूट अपने स्वयं के प्रारूप का उपयोग करता है, जो कि litsupport फ़ोल्डर में स्थित है।

 config.test_format = litsupport.test.TestSuiteTest() 

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



टेस्ट-सूट परीक्षण ऑपरेशन का एक उदाहरण (टेस्टकोटेक्स्ट क्लास के रूप में विवरण के अपवाद के साथ, विभिन्न जलाया कॉन्फ़िगरेशन और स्वयं परीक्षण आदि) नीचे प्रस्तुत किया गया है।



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

3. रनिंग टेस्ट-सूट

टेस्ट-सूट चलाने के दो तरीके हैं:

• मैनुअल, अर्थात आदेशों का क्रमिक आह्वान।

   cmake -DCMAKE_CXX_COMPILER:FILEPATH=clang++ -DCMAKE_C_COMPILER:FILEPATH=clang test-suite #  make #   llvm-lit . -o <output> #   

• LNT का उपयोग करना (LLVM पारिस्थितिकी तंत्र की एक और प्रणाली जो आपको बेंचमार्क चलाने, डेटाबेस को परिणाम बचाने, वेब इंटरफ़ेस में परिणामों का विश्लेषण करने की अनुमति देती है)। LNT, अपने परीक्षण रन टीम के भीतर, पिछले पैराग्राफ में के रूप में एक ही कदम करता है।
  

   lnt runtest test-suite --sandbox SANDBOX --cc clang --cxx clang++ --test-suite test-suite 

प्रत्येक परीक्षण के लिए परिणाम के रूप में प्रदर्शित किया जाता है

 PASS: test-suite :: MultiSource/Benchmarks/Prolangs-C/football/football.test (m of n) ********** TEST 'test-suite :: MultiSource/Benchmarks/Prolangs-C/football/football.test' RESULTS ********** compile_time: 1.1120 exec_time: 0.0014 hash: "38254c7947642d1adb9d2f1200dbddf7" link_time: 0.0240 size: 59784 size..bss: 99800 … size..text: 37778 ********** 

अलग-अलग लॉन्च के परिणामों की तुलना एलएनटी के बिना की जा सकती है (हालांकि यह रूपरेखा विभिन्न उपकरणों का उपयोग करके जानकारी का विश्लेषण करने के लिए शानदार अवसर प्रदान करती है, लेकिन इसे एक अलग समीक्षा की आवश्यकता है), परीक्षण-सूट में शामिल स्क्रिप्ट का उपयोग करके

 test-suite/utils/compare.py results_a.json results_b.json 

एक के कोड आकार और दो लॉन्च से एक ही बेंचमार्क की तुलना करने का एक उदाहरण: -O3 और -O के झंडे के साथ

 test-suite/utils/compare.py -m size SANDBOX1/build/O3.json SANDBOX/build/Os.json Tests: 1 Metric: size Program O3 Os diff test-suite...langs-C/football/football.test 59784 47496 -20.6% 

निष्कर्ष

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