जब एक कंप्यूटर में कई प्रोसेसर होते हैं, या कम से कम एक मल्टी-कोर प्रोसेसर होता है, तो आपके अनुप्रयोगों के प्रदर्शन को बढ़ाने की काफी संभावना होती है, जिसे कई तरीकों से किया जा सकता है. पिछले लेखों में मैंने कई कोर का लाभ उठाने के लिए मल्टी-थ्रेडिंग एप्लिकेशन के बारे में लिखा है. इस लेख में मैं चर्चा करूंगा कि सिंगल थ्रेडेड अनुप्रयोगों का उपयोग करते समय आप एकाधिक कोर का लाभ उठाने के लिए क्या कर सकते हैं. प्रोसेसर एफ़िनिटी एक विशिष्ट कार्य, या प्रक्रिया को एक निर्दिष्ट कोर का उपयोग करने के लिए निर्देशित करने की क्षमता है. यह उपयोगी क्यों है? ठीक है, अगर कोई प्रक्रिया बार-बार चलती है तो उस प्रक्रिया के पिछले रनों के अवशेष किसी दिए गए प्रोसेसर के कैश में शेष हो सकते हैं. इसलिए, यदि प्रक्रिया को हमेशा एक ही कोर का उपयोग करने के लिए निर्देशित किया जाता है, तो संभव है कि कैश के पुन: उपयोग के कारण प्रक्रिया अधिक कुशलता से चलेगी. प्रोसेसर एफ़िनिटी का उपयोग करने का दूसरा तरीका केवल एक या दो प्रदर्शन महत्वपूर्ण प्रक्रियाओं को एक कोर पर निर्देशित करना होगा जबकि अन्य सभी प्रक्रियाओं को अन्य कोर पर निर्देशित किया जाएगा. यह सुनिश्चित करना चाहिए कि जब प्रदर्शन महत्वपूर्ण प्रक्रियाओं को एक कोर की आवश्यकता होती है तो एक उपलब्ध होगा.
प्रोसेसर एफ़िनिटी उस प्रक्रिया को संदर्भित करता है जिसमें प्रोसेसर के लिए एक आत्मीयता होती है जिस पर यह वर्तमान में चल रहा है. जब कोई प्रक्रिया किसी विशिष्ट CPU पर निष्पादित होती है, तो कैश मेमोरी प्रभावित होती है. प्रोसेसर का कैश प्रक्रिया के सबसे हाल ही में एक्सेस किए गए डेटा से भर जाता है, इसलिए क्रमिक मेमोरी एक्सेस आमतौर पर कैश मेमोरी में संतुष्ट होते हैं. मान लें कि प्रक्रिया को किसी भिन्न CPU में ले जाया गया है. उस स्थिति में, पहले प्रोसेसर की कैश मेमोरी की सामग्री को अमान्य किया जाना चाहिए, और दूसरे प्रोसेसर के कैशे को फिर से भरना चाहिए. अधिकांश सममित मल्टीप्रोसेसिंग (एसएमपी) सिस्टम एक ही प्रोसेसर पर एक ही प्रक्रिया को चालू रखते हुए प्रक्रिया प्रवासन से बचने की कोशिश करते हैं क्योंकि कैश को अमान्य और पुन: पॉप्युलेट करना महंगा है.
प्रोसेसर एफ़िनिटी को "कैश एफ़िनिटी" के रूप में भी जाना जाता है. यह एक सीपीयू या सीपीयू के समूह के लिए एक प्रक्रिया या धागे को बांध और अनबाइंड कर सकता है और यह सुनिश्चित करता है कि प्रक्रिया या धागा केवल निर्दिष्ट सीपीयू पर ही निष्पादित होता है न कि किसी अन्य सीपीयू पर. यह सममित मल्टीप्रोसेसिंग ओएस के मूल केंद्रीय कतार शेड्यूलिंग एल्गोरिदम का एक संशोधन है. कतार में प्रत्येक आइटम में एक टैग होता है जो उसके परिजन प्रोसेसर को निर्दिष्ट करता है. जब संसाधन आवंटन की बात आती है, तो प्रत्येक कार्य दूसरों से पहले उसके परिजन प्रोसेसर को सौंपा जाता है. प्रोसेसर एफ़िनिटी इस तथ्य का उपयोग करती है कि एक निश्चित प्रोसेसर पर चलने वाली प्रक्रिया का बचा हुआ हिस्सा उस प्रोसेसर की स्थिति में बना रह सकता है, जब उस पर दूसरी प्रक्रिया चलती है. एक ही प्रोसेसर पर चलने के लिए कुछ इंटरप्ट के साथ सीपीयू-गहन प्रक्रिया को शेड्यूल करना कैश मिस जैसी अपमानजनक घटनाओं को कम करके प्रदर्शन में सुधार कर सकता है. हालाँकि, यह अन्य कार्यक्रमों को धीमा कर सकता है क्योंकि उन्हें उस प्रोसेसर के फिर से उपलब्ध होने की प्रतीक्षा करनी होगी. ग्राफिक्स-रेंडरिंग सॉफ़्टवेयर जैसे गैर-थ्रेडेड एप्लिकेशन के कई उदाहरणों का उपयोग करना प्रोसेसर एफ़िनिटी का एक वास्तविक उदाहरण है.
शेड्यूलिंग एल्गोरिदम के कार्यान्वयन प्रोसेसर एफ़िनिटी के उनके पालन में भिन्न होते हैं. कुछ कार्यान्वयन कार्य को किसी अन्य प्रोसेसर पर स्विच करने में सक्षम करेंगे यदि यह कुछ शर्तों के तहत दक्षता में सुधार करता है. उदाहरण के लिए, यदि दो प्रोसेसर-गहन प्रक्रियाओं (ए और बी) में एक प्रोसेसर के लिए एक समानता है और दूसरा अप्रयुक्त रहता है, तो कई शेड्यूलर सीपीयू उपयोग को अधिकतम करने के लिए नौकरी बी को दूसरे प्रोसेसर में स्थानांतरित कर देंगे. टास्क बी दूसरे प्रोसेसर के लिए एक आत्मीयता विकसित करेगा, जबकि टास्क ए मूल प्रोसेसर के लिए आत्मीयता बनाए रखेगा.
प्रोसेसर एफ़िनिटी, या सीपीयू पिनिंग या "कैश एफ़िनिटी", एक केंद्रीय प्रसंस्करण इकाई (सीपीयू) या सीपीयू की एक श्रृंखला के लिए एक प्रक्रिया या धागे के बंधन और अनबाइंडिंग को सक्षम बनाता है, ताकि प्रक्रिया या धागा केवल निर्दिष्ट सीपीयू पर ही निष्पादित हो या सीपीयू के बजाय किसी भी सीपीयू. इसे एक सममित मल्टीप्रोसेसिंग ऑपरेटिंग सिस्टम में मूल केंद्रीय कतार शेड्यूलिंग एल्गोरिदम के संशोधन के रूप में देखा जा सकता है. कतार में प्रत्येक आइटम में एक टैग होता है जो उसके परिजन प्रोसेसर को दर्शाता है. संसाधन आवंटन के समय, प्रत्येक कार्य को उसके परिजन प्रोसेसर को वरीयता में आवंटित किया जाता है. प्रोसेसर एफ़िनिटी इस तथ्य का लाभ उठाती है कि किसी दिए गए प्रोसेसर पर चलने वाली प्रक्रिया के अवशेष उस प्रोसेसर की स्थिति में रह सकते हैं (उदाहरण के लिए, कैश मेमोरी में डेटा) उस प्रोसेसर पर दूसरी प्रक्रिया चलने के बाद. एक सीपीयू-गहन प्रक्रिया को शेड्यूल करना जिसमें एक ही प्रोसेसर पर निष्पादित करने के लिए कुछ इंटरप्ट होते हैं, कैश मिस जैसी अपमानजनक घटनाओं को कम करके इसके प्रदर्शन में सुधार कर सकते हैं, लेकिन सामान्य कार्यक्रमों को धीमा कर सकते हैं क्योंकि उन्हें उस सीपीयू के फिर से उपलब्ध होने की प्रतीक्षा करने की आवश्यकता होगी. प्रोसेसर एफ़िनिटी का एक व्यावहारिक उदाहरण गैर-थ्रेडेड एप्लिकेशन के कई उदाहरणों को निष्पादित कर रहा है, जैसे कि कुछ ग्राफिक्स-रेंडरिंग सॉफ़्टवेयर. शेड्यूलिंग-एल्गोरिदम कार्यान्वयन प्रोसेसर एफ़िनिटी के पालन में भिन्न होते हैं. कुछ परिस्थितियों में, कुछ कार्यान्वयन कार्य को किसी अन्य प्रोसेसर में बदलने की अनुमति देंगे यदि इसका परिणाम उच्च दक्षता में होता है. उदाहरण के लिए, जब दो प्रोसेसर-गहन कार्यों (ए और बी) में एक प्रोसेसर के लिए आत्मीयता होती है जबकि दूसरा प्रोसेसर अप्रयुक्त रहता है, तो कई शेड्यूलर प्रोसेसर के उपयोग को अधिकतम करने के लिए कार्य बी को दूसरे प्रोसेसर में स्थानांतरित कर देंगे. टास्क बी फिर दूसरे प्रोसेसर के साथ आत्मीयता हासिल कर लेगा, जबकि टास्क ए का मूल प्रोसेसर के साथ संबंध बना रहेगा.
प्रोसेसर एफ़िनिटी कैश की समस्याओं को प्रभावी ढंग से कम कर सकती है, लेकिन यह लगातार लोड-बैलेंसिंग समस्या का समाधान नहीं करती है. उदाहरण के लिए, दो डुअल-कोर हाइपर-थ्रेडेड सीपीयू वाला सिस्टम शेड्यूलिंग एल्गोरिथम के लिए एक कठिन कार्य प्रदान करता है. हाइपर-थ्रेडिंग एक ही कोर पर चलने वाले दो वर्चुअल सीपीयू के बीच एक आदर्श संबंध बनाता है. एक ही भौतिक प्रोसेसर पर दो कोर के बीच कुछ समानता है लेकिन विभिन्न भौतिक प्रोसेसर के बीच कोई समानता नहीं है. जैसा कि अन्य संसाधनों को साझा किया जाता है, सीपीयू को भेजने के लिए अकेले प्रोसेसर एफिनिटी का उपयोग नहीं किया जा सकता है. मान लीजिए कि किसी दिए गए कोर पर वर्चुअल हाइपर-थ्रेडेड सीपीयू पर एक प्रक्रिया निष्पादित की गई है, और वर्चुअल सीपीयू वर्तमान में व्यस्त है, और सीपीयू इसका भागीदार नहीं है. इस स्थिति में, कैश एफ़िनिटी सुझाव देती है कि प्रक्रिया निष्क्रिय साथी प्रोसेसर को भेजी जाए. हालाँकि, दो वर्चुअल प्रोसेसर लगभग सभी कंप्यूट, मेमोरी संसाधनों और कैशे मेमोरी के लिए प्रतिस्पर्धा करते हैं. यदि केवल एक प्रोसेसर उपलब्ध है, तो प्रक्रिया को एक अलग कोर या प्रोसेसर में रूट करना आमतौर पर अधिक प्रभावी होता है. जब प्रक्रिया कैश को फिर से खोलती है तो यह एक प्रदर्शन जुर्माना लगा सकता है लेकिन समग्र प्रदर्शन में सुधार कर सकता है क्योंकि इसे CPU संसाधनों के लिए प्रतिस्पर्धा नहीं करनी पड़ेगी.
प्रोसेसर एफिनिटी मुख्यतः दो प्रकार की होती है. ये इस प्रकार हैं:-
Soft Affinity
Hard Affinity
शब्द "सॉफ्ट एफ़िनिटी" एक ऑपरेटिंग सिस्टम की एक ही प्रोसेसर पर एक प्रक्रिया को चालू रखने की नीति को संदर्भित करता है, और यह सुनिश्चित नहीं करेगा कि यह ऐसा करेगा.
यह एक प्रक्रिया को प्रोसेसर के एक सबसेट को परिभाषित करने में सक्षम बनाता है जिस पर वह निष्पादित हो सकता है. लिनक्स जैसे कुछ ऑपरेटिंग सिस्टम सॉफ्ट एफ़िनिटी को लागू करते हैं और सिस्टम कॉल की पेशकश करते हैं, जैसे कि शेड्यूल सेटफिनिटी (), जो हार्ड एफ़िनिटी का समर्थन करते हैं.
प्रोसेसर एफ़िनिटी कैश की समस्याओं को प्रभावी ढंग से कम कर सकती है, लेकिन यह लगातार लोड-बैलेंसिंग समस्या को कम नहीं करती है. यह भी ध्यान दें कि गैर-समान आर्किटेक्चर वाले सिस्टम में प्रोसेसर एफ़िनिटी अधिक जटिल हो जाती है. उदाहरण के लिए, दो डुअल-कोर हाइपर-थ्रेडेड सीपीयू वाला सिस्टम शेड्यूलिंग एल्गोरिथम के लिए एक चुनौती प्रस्तुत करता है. हाइपर-थ्रेडिंग के माध्यम से एक ही कोर पर लागू दो वर्चुअल सीपीयू के बीच पूर्ण समानता है, एक ही भौतिक प्रोसेसर पर दो कोर के बीच आंशिक आत्मीयता (जैसा कि कोर कुछ साझा करते हैं, लेकिन सभी नहीं, कैश), और अलग भौतिक प्रोसेसर के बीच कोई संबंध नहीं है. जैसा कि अन्य संसाधनों को भी साझा किया जाता है, अकेले प्रोसेसर एफ़िनिटी का उपयोग सीपीयू प्रेषण के आधार के रूप में नहीं किया जा सकता है. यदि कोई प्रक्रिया हाल ही में किसी दिए गए कोर में एक वर्चुअल हाइपर-थ्रेडेड CPU पर चलती है, और वह वर्चुअल CPU वर्तमान में व्यस्त है, लेकिन उसका पार्टनर CPU नहीं है, तो कैश एफ़िनिटी यह सुझाव देगी कि प्रक्रिया को निष्क्रिय पार्टनर CPU को भेजा जाना चाहिए. हालांकि, दो वर्चुअल सीपीयू अनिवार्य रूप से सभी कंप्यूटिंग, कैशे और मेमोरी संसाधनों के लिए प्रतिस्पर्धा करते हैं. इस स्थिति में, यदि कोई उपलब्ध हो, तो प्रक्रिया को किसी भिन्न कोर या CPU में भेजना आम तौर पर अधिक कुशल होगा. जब प्रक्रिया कैशे को फिर से खोलती है तो उस पर जुर्माना लग सकता है, लेकिन समग्र प्रदर्शन अधिक हो सकता है क्योंकि प्रक्रिया को सीपीयू के भीतर संसाधनों के लिए प्रतिस्पर्धा नहीं करनी पड़ेगी.
ऊपर दिखाया गया मामला एक विशिष्ट मामला है और काफी सरल है. निकट भविष्य में, प्रोसेसर एफ़िनिटी सेट करना और अधिक जटिल हो जाएगा. क्यों? क्योंकि प्रसंस्करण कोर के समान होने का कोई कारण नहीं है. जब सिस्टम कई दर्जन कोर के साथ शिपिंग शुरू करते हैं तो संभावना है कि इनमें से कई कोर कुछ प्रकार के संचालन के लिए अनुकूलित किए जाएंगे. यह काफी हद तक उसी तरह से किया जाएगा जैसे ग्राफिकल प्रोसेसिंग यूनिट (जीपीयू) को ग्राफिक्स प्रोसेसिंग के लिए सामान्य संचालन करने के लिए अनुकूलित किया जाता है.
तो मुझे यकीन है कि आप कल्पना कर सकते हैं कि जब दर्जनों कोर होते हैं, जहां अधिकांश विशिष्ट संचालन के लिए अनुकूलित होते हैं, तो प्रोसेसर एफ़िनिटी को समझदारी से असाइन करना काफी जटिल कार्य होगा. मेरा मानना है कि ऑपरेटिंग सिस्टम के भविष्य के संस्करणों को उपयोगकर्ता संशोधनों की अनुमति देते हुए इसका ध्यान रखना चाहिए. यह वैसा ही हो सकता है जैसा मैं नीचे वर्णित करता हूं. सबसे पहले, जब ऑपरेटिंग सिस्टम स्थापित होता है, या जब नया हार्डवेयर जोड़ा जाता है, तो ऑपरेटिंग सिस्टम प्रत्येक उपलब्ध कोर की पहचान करेगा. यह वैसा ही होगा जैसा अब यह करता है सिवाय इसके कि यह प्रत्येक कोर की तुलना पहले से बनाई गई रजिस्ट्री से भी करेगा. यह रजिस्ट्री, जिसे मैं कोर ऑप्टिमाइजेशन रजिस्ट्री कहूंगा, ऑपरेटिंग सिस्टम कंपनी द्वारा रखी जाएगी और अपडेट के लिए उपलब्ध रहेगी. यह सूची प्रत्येक कोर से संचालन के लिए मेल खाती है जिसके लिए इसे अनुकूलित किया गया है. प्रोसेसर निर्माता इस सूची के साथ अपने कोर को पंजीकृत करेंगे या कोर को ठीक से रखने के लिए उपयुक्त स्तर के अनुकूलन (यह शायद पसंदीदा तरीका है) सुनिश्चित करने के लिए प्रोसेसर के अनुकूलन की किसी प्रकार की स्वतंत्र समीक्षा हो सकती है.
कोर ऑप्टिमाइजेशन रजिस्ट्री की अवधारणा ऑपरेटिंग सिस्टम के बीच प्रतिस्पर्धा के लिए एक और क्षेत्र भी प्रदान कर सकती है; जबकि अलग-अलग ऑपरेटिंग सिस्टम में अलग-अलग कोर ऑप्टिमाइजेशन रजिस्ट्रियां हो सकती हैं, यहां तक कि विस्तार की विभिन्न डिग्री पर भी. उदाहरण के लिए, एक ऑपरेटिंग सिस्टम ग्राफिक संचालन के लिए अनुकूलित होने पर किसी दिए गए कोर को रैंक कर सकता है, जबकि अधिक व्यापक कोर ऑप्टिमाइज़ेशन रजिस्ट्री वाला दूसरा ऑपरेटिंग सिस्टम 3 डी ग्राफिक ऑपरेशंस के लिए अनुकूलित होने पर उसी कोर पर रैंक कर सकता है. दूसरे, जब ऑपरेटिंग सिस्टम उपलब्ध सभी कोर के बारे में जानता है और कोर ऑप्टिमाइज़ेशन रजिस्ट्री के खिलाफ उनकी जाँच करता है, तो ऑपरेटिंग सिस्टम को प्रक्रिया के लिए आवश्यक संचालन के प्रकारों के आधार पर प्रत्येक प्रक्रिया को एक या अधिक कोर को असाइन करने की आवश्यकता होती है. ऑपरेटिंग सिस्टम की स्थापना के दौरान ऑपरेटिंग सिस्टम सभी पूर्व-स्थापित सॉफ़्टवेयर को एक या अधिक कोर से मिला सकता है और साथ ही सभी ऑपरेटिंग सिस्टम प्रक्रियाओं को एक या अधिक कोर से मेल कर सकता है. इन प्रक्रियाओं को उपलब्ध कोर से मिलाना एक मुश्किल काम होगा.
ऑपरेटिंग सिस्टम को कैसे पता चलेगा कि किसी दिए गए सॉफ़्टवेयर में प्रक्रियाओं के लिए किस प्रकार के संचालन की आवश्यकता है? प्रोसेसर एफ़िनिटी को समझदारी से असाइन करने में सक्षम होने के लिए यह एक आवश्यकता है. एक सॉफ्टवेयर संचालन रजिस्ट्री हो सकती है, जहां सॉफ्टवेयर के लिए आवश्यक संचालन के प्रकार के साथ सॉफ्टवेयर रजिस्ट्री में पंजीकृत है. लेकिन, मैं आश्वस्त नहीं हूं कि यह एक अच्छा विचार है. सॉफ्टवेयर में विकास की इतनी तेज गति है कि मुझे संदेह है कि इस तरह की रजिस्ट्री को व्यावहारिक बनाया जा सकता है. एक बेहतर विचार, मेरी राय में, कोर ऑप्टिमाइज़ेशन रजिस्ट्री को प्रोग्रामेटिक एक्सेस प्रदान करना है ताकि सॉफ़्टवेयर को अपनी आत्मीयता सेट करने के लिए लिखा जा सके. यह संभवतः सॉफ़्टवेयर इंस्टॉलरों द्वारा सबसे अच्छा उपयोग किया जाता है जो सॉफ़्टवेयर की स्थापना के दौरान एफ़िनिटी (उपयोगकर्ता की पुष्टि के बाद) सेट करेंगे.
तीसरा, उपयोगकर्ता के लिए प्रोसेसर एफ़िनिटी को बदलने के लिए अभी भी एक तरीका होना चाहिए. यह विंडोज विस्टा में प्रोसेसर एफिनिटी सेट करने की विधि के समान सीधे आगे किया जाना चाहिए जैसा कि मैंने ऊपर वर्णित किया है. जाहिर है अगर दर्जनों कोर उपलब्ध हैं तो इस जानकारी को प्रदर्शित करने का लेआउट अलग होना चाहिए, लेकिन इसके लिए जो भी तरीका तय किया गया है वह सरल और सीधे आगे होना चाहिए. यह उपयोगकर्ताओं के लिए अपने कंप्यूटर के संचालन को निजीकृत करने का एक तरीका हो सकता है. शायद कुछ चतुर उपयोगकर्ता ऑपरेटिंग सिस्टम द्वारा चुने गए एफ़िनिटी से असहमत होंगे, शायद एक खराब कोर ऑप्टिमाइज़ेशन रजिस्ट्री के कारण, और इन उपयोगकर्ताओं को अपनी इच्छाओं से मेल खाने के लिए आत्मीयता को बदलने में सक्षम होना चाहिए.
यह सब ठीक है और अच्छा है, लेकिन कई अनुप्रयोगों को उपयोगकर्ता या अन्य सॉफ़्टवेयर अनुप्रयोगों से इनपुट के आधार पर सॉफ़्टवेयर के चलने के दौरान अलग-अलग अनुकूलित कोर की आवश्यकता होगी. यह मुझे मेरे चौथे बिंदु पर लाता है. (ठीक है, वास्तव में यह वास्तव में कोई मुद्दा नहीं है; मैं केवल अपने विचारों का बचाव किसी भी पाठक के खिलाफ कर रहा हूं जो महसूस कर सकता है कि मैंने इस सामान्य मामले की उपेक्षा की है). सॉफ्टवेयर के एक टुकड़े की कोर ऑप्टिमाइज़ेशन रजिस्ट्री तक पहुंच होनी चाहिए, जैसा कि मैंने अपने दूसरे बिंदु में समझाया है, यह न केवल सॉफ़्टवेयर को स्टार्ट-अप के दौरान अपनी आत्मीयता स्थापित करने की अनुमति देता है, बल्कि सॉफ़्टवेयर को विभिन्न प्रक्रियाओं के लिए आत्मीयता स्थापित करने और बदलने की अनुमति देता है. किसी भी समय आत्मीयता. इसी तरह, यदि कोई इंस्टॉलर सॉफ़्टवेयर एप्लिकेशन के लिए एफ़िनिटी सेट करता है तो सॉफ़्टवेयर में संभावित विभिन्न प्रकार की प्रक्रियाओं के लिए इंस्टॉलर को कई समानता से कोई रोक नहीं सकता है.
कई कोर वाले सिस्टम में प्रोसेसर एफ़िनिटी सेट करने के लिए ऊपर वर्णित विधि, जिनमें से कुछ विभिन्न प्रक्रियाओं के लिए अनुकूलित हैं, इसे पूरा करने का केवल एक ही तरीका है. एक और तरीका जिसके बारे में मैंने पढ़ा है, और इससे असहमत हूं, वह है जहां ऑपरेटिंग सिस्टम एक सॉफ्टवेयर एप्लिकेशन की गतिविधियों की निगरानी करता है और यह कोर का उपयोग कैसे कर रहा है और फिर प्रक्रिया को उस प्रकार की प्रक्रिया के लिए उचित लगता है. मेरा मानना है कि लोड बैलेंसिंग को पूरा करने का यह सही तरीका है. हालाँकि अगर इस निगरानी को प्रक्रिया की गणितीय प्रकृति का निर्धारण करने का काम सौंपा जाता है, तो मेरा मानना है कि ऐसा करने के लिए आवश्यक समय और प्रसंस्करण शक्ति बर्बाद होगी. ऊपर वर्णित विधि एक सॉफ्टवेयर डेवलपर को इस निर्धारण को रन-टाइम के बजाय स्थापना प्रक्रिया में स्थानांतरित करने की अनुमति देती है. मेरा मानना है कि इससे बेहतर, अधिक उपयोगकर्ता के अनुकूल, अंतिम परिणाम प्राप्त होंगे.