कंप्यूटर सिस्टम के सिमुलेटर: एक परिचित पूर्ण-प्लेटफ़ॉर्म सिम्युलेटर और अज्ञात दक्षिणावर्त और निशान

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

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

पूर्ण प्लेटफ़ॉर्म सिम्युलेटर, या "अकेले मैदान में योद्धा नहीं है"

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

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

नीचे Intel के x58 चिपसेट का ब्लॉक आरेख है। इस चिपसेट पर एक पूर्ण-प्लेटफ़ॉर्म कंप्यूटर सिम्युलेटर के लिए अधिकांश सूचीबद्ध उपकरणों के कार्यान्वयन की आवश्यकता होती है, जिनमें IOH (इनपुट/आउटपुट हब) और ICH (इनपुट/आउटपुट कंट्रोलर हब) के अंदर के उपकरण शामिल हैं, जिन्हें ब्लॉक आरेख पर विस्तार से नहीं दर्शाया गया है। . हालाँकि, जैसा कि अभ्यास से पता चलता है, ऐसे कई उपकरण नहीं हैं जिनका उपयोग उस सॉफ़्टवेयर द्वारा नहीं किया जाता है जिसे हम चलाने जा रहे हैं। ऐसे उपकरणों के मॉडल बनाने की आवश्यकता नहीं है।

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

सिम्युलेटर प्रदर्शन

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

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

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

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

नीचे दिया गया ग्राफ़ मॉडल विवरण पर सिमुलेशन गति की अनुमानित निर्भरता दिखाता है।

बीट-दर-बीट सिमुलेशन

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

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

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

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

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

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

ट्रेस-आधारित सिमुलेशन

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

अगला कदम ट्रेस को "प्ले" करना है, जब घड़ी-दर-घड़ी सिम्युलेटर ट्रेस को पढ़ता है और उसमें लिखे सभी निर्देशों को निष्पादित करता है। अंत में, हमें प्रोग्राम के इस हिस्से का निष्पादन समय, साथ ही इस प्रक्रिया की विभिन्न विशेषताएं मिलती हैं, उदाहरण के लिए, कैश में हिट का प्रतिशत।

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

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

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

स्रोत: www.habr.com