एक प्रोग्राम को एक विशेष न्यूनतम संख्या में CPU कोर की आवश्यकता क्यों होगी?


55

क्या कोड (या पूर्ण सॉफ्टवेयर, कोड के एक टुकड़े के बजाय) लिखना संभव है जो सीपीयू पर चलने पर ठीक से काम नहीं करेगा जिसमें एन संख्या से कम कोर है? स्पष्ट रूप से जाँच के बिना और उद्देश्य पर विफल:

IF (noOfCores <4) उद्देश्य पर ठीक से नहीं चलते हैं

मैं एक गेम ( ड्रैगन एज: इनक्विजिशन ) न्यूनतम सिस्टम आवश्यकताओं को देख रहा हूं , और यह एक चार-कोर सीपीयू का एक न्यूनतम बताता है। कई खिलाड़ियों का कहना है कि यह दो कोर सीपीयू और ईवीएन पर इंटेल कोर i3s पर दो भौतिक और दो तार्किक कोर के साथ नहीं चलता है । और यह कंप्यूटिंग शक्ति की समस्या नहीं है।

मेरी समझ से, थ्रेड पूरी तरह से सीपीयू से ओएस द्वारा अलग-थलग हैं क्योंकि ऐसा नहीं किया जा सकता है।

बस चीजों को साफ करने के लिए:

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

संक्षेप में, क्या ऐसे सॉफ़्टवेयर हो सकते हैं जिनके लिए कई कोर की आवश्यकता होती है, बिना अतिरिक्त कंप्यूटिंग शक्ति की आवश्यकता के जो कई कोर से आता है? यह सिर्फ एन अलग शारीरिक कोर की आवश्यकता होगी।


11
यदि आप मेरे प्रश्न को ध्यान से पढ़ेंगे तो आप देखेंगे कि वे एक ही बात नहीं पूछ रहे हैं।
uylmz

21
चूंकि कोर की संख्या को पुनः प्राप्त किया जा सकता है, इसलिए इसकी तुलना N से की जा सकती है, और यदि यह तुलना सत्य का मूल्यांकन करती है, तो कोड जो चाहे कर सकता है, जिसमें विज्ञापन शामिल नहीं हैं, लेकिन व्यवहार में सीमित नहीं है। आपका सवाल क्या हैं?

3
क्या आप सुनिश्चित हैं कि समस्या वास्तव में और सीधे कोर की संख्या से संबंधित है? हो सकता है कि उल्लेखित खेल आंशिक रूप से केवल (सही ढंग से) सीपीयू द्वारा कम से कम 4 कोर के साथ प्रदान की गई विशेषता पर आधारित हो?
मुनीमिन

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

3
@ सिब: मुझे लगता है कि आप कुछ कर रहे हैं: यदि 4 भौतिक कोर अधिक कैश होने के साथ सहसंबंधित करते हैं, तो 2 भौतिक / 4 तार्किक, तो खेल स्वाभाविक रूप से 2x2 मशीनों पर अपनी प्रसंस्करण शक्ति की सीमा को मारने के बिना घुट सकता है क्योंकि यह कैश को गायब कर रहा है। समय। परीक्षण 2x2 कोर और कैश के लोड, या 4 कोर और थोड़ा कैश के साथ एक सीपीयू खोजने के लिए होगा, और देखें कि क्या होता है।
स्टीव जेसोप Steve

जवाबों:


45

कोर आत्मीयता के लापरवाह उपयोग के साथ यह "दुर्घटना से" करना संभव हो सकता है। निम्नलिखित छद्मकोश पर विचार करें:

  • एक धागा शुरू करो
  • उस धागे में, पता करें कि यह किस कोर पर चल रहा है
  • उस कोर के लिए अपने CPU संबंध स्थापित करें
  • कुछ कम्प्यूटेशनल रूप से गहन / पाश हमेशा के लिए करना शुरू करें

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

(यदि आपके पास लंबे समय तक चलने वाले धागे हैं, तो सीपीयू आत्मीयता स्थापित करने से आमतौर पर थ्रूपुट में सुधार होता है)

यह विचार है कि गेम कंपनियां बिना किसी अच्छे कारण के लोगों को अधिक महंगा हार्डवेयर खरीदने के लिए "मजबूर" कर रही हैं। यह केवल उन्हें ग्राहक खो सकता है।

संपादित करें: इस पोस्ट को अब 33 अपवोट मिल गए हैं, जो कि बहुत कुछ दिया गया है जो कि शिक्षित अनुमान पर आधारित है!

ऐसा लगता है कि लोगों को डीए मिला है: मुझे चलाने के लिए, बुरी तरह से, दोहरे-कोर सिस्टम पर: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ विश्लेषण उल्लेख है कि अगर हाइपरथ्रेडिंग चालू है तो स्थिति में बहुत सुधार होता है। यह देखते हुए कि HT किसी भी अधिक निर्देश समस्या इकाइयों या कैश को नहीं जोड़ता है, यह केवल एक धागे को चलाने की अनुमति देता है जबकि दूसरा कैश स्टॉल में है, जो दृढ़ता से सुझाव देता है कि यह पूरी तरह से थ्रेड की संख्या से जुड़ा हुआ है।

एक अन्य पोस्टर का दावा है कि ग्राफिक्स ड्राइवरों को बदलने का काम करता है: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td.p.p3/3994141 ; यह देखते हुए कि ग्राफिक्स ड्राइवर मैल और खलनायकी के एक कूबड़ वाले छत्ते हैं, यह आश्चर्य की बात नहीं है। ड्राइवरों के एक कुख्यात सेट में एक "सही और धीमा" बनाम "तेज और गलत" मोड था जिसे अगर QUAKE.EXE से बुलाया गया था। यह पूरी तरह से संभव है कि चालक स्पष्ट रूप से अलग-अलग सीपीयू के लिए अलग-अलग व्यवहार करें। शायद (वापस अटकलें) एक अलग तुल्यकालन तंत्र का उपयोग किया जाता है। का दुरुपयोग spinlocks ?

"लॉकिंग और सिंक्रोनाइज़ेशन प्राइमेटिव्स का दुरुपयोग" बहुत ही सामान्य, बग का सामान्य स्रोत है। (यह लिखते समय मैं जिस बग को देख रहा था वह काम है "अगर प्रिंटर काम खत्म होते ही प्रिंटर सेटिंग्स बदल जाए" तो यह दुर्घटना है)।

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

www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) ग्राफिक्स कार्ड के लिए बेहतर समय-निर्धारण पर एक स्नातक थीसिस है जिसमें स्पष्ट रूप से उल्लेख किया गया है कि वे आम तौर पर पहले-आओ-पहले-सेवा शेड्यूलिंग का उपयोग करते हैं, जिसे लागू करना आसान है गैर-प्रीमेप्टिव सिस्टम। क्या स्थिति में सुधार हुआ है? शायद ऩही।


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

3
यदि आप वर्तमान कोर को आत्मीयता निर्धारित करते हैं तो क्या गलत हो सकता है? प्रीमेप्टिव मल्टीटास्किंग के साथ वेटिंग थ्रेड को तब तक शेड्यूल किया जाएगा जब तक कि वर्तमान में अधिकतम संभव प्राथमिकता (विंडोज में "रियलटाइम") न हो। मुझे एक और परिदृश्य दिखाई देगा: 4 थ्रेड्स में से प्रत्येक को 1,2,4,8 की वैधानिक रूप से परिभाषित आत्मीयता सौंपी गई है, जिस स्थिति में बाद के दो सूत्र कभी निर्धारित नहीं होंगे (हालांकि मुझे यकीन नहीं है कि प्रभावी के लिए आत्मीयता स्थापित करना शून्य सफल हो रहा है)।
रुस्लान

@Ruslan शायद अवैध संबंध स्थापित करने की कोशिश करने से पहली बार में ही दुर्घटनाग्रस्त हो जाएगी?
लुआं

1
@ Luaan अच्छी तरह से दुर्घटना के लिए नेतृत्व करने के लिए जोखिम भरा ऑपरेशन नहीं है । अधिकतम जो मैं उम्मीद करता हूं वह ओएस द्वारा दी गई एक त्रुटि है। मैंने अभी-अभी जाँच की है, लिनक्स में मुझे "अमान्य तर्क" त्रुटि मिलती है। पता नहीं विंडोज क्या कहेगा।
रुस्लान

@Ruslan निश्चित रूप से एक दशक से अधिक के लिए हर प्रमुख ओएस में थ्रेड भुखमरी से बचने के लिए कोड शामिल किया गया है (आमतौर पर थ्रेड की प्राथमिकता को बढ़ाने के बाद यह लंबे समय तक नहीं चलता है)।
वू

34

4 कोर होना आवश्यक हो सकता है क्योंकि एप्लिकेशन समानांतर थ्रेड्स में चार कार्य करता है और उनसे लगभग एक साथ समाप्त होने की उम्मीद करता है।

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

अप्रत्याशित थ्रेड टाइमिंग के कारण होने वाले कीड़े को " दौड़ की स्थिति " के रूप में जाना जाता है ।

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

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


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

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

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

8
@ निश्चित रूप से लेकिन सवाल पूछता है "क्या यह संभव है?" नहीं "यह समझदार है?"
user253751

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

16

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

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

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

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

गेम डेवलपर्स के पास नया हार्डवेयर खरीदने में आपकी रुचि शून्य है। उनके पास सिस्टम आवश्यकताएं होने का कारण यह है कि कम अंत मशीनों का समर्थन करने की लागत इसके लायक नहीं है।


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

4
तुलना करने की बात 2 बनाम 4 कोर नहीं है। यह अनिवार्य रूप से 1 बनाम 3 कोर है, क्योंकि सीपीयू # 0 ग्राफिक्स ड्राइवर और डीपीसी द्वारा बहुत अधिक आंकी जाएगी। यदि आप किसी विशिष्ट आधुनिक गेम की नौकरी प्रणाली में कई प्रकार के कार्यों के साथ सीपीयू का निरीक्षण करते हैं, तो महत्वपूर्ण कैश और माइग्रेशन प्रभाव भी होते हैं। आवश्यकता वहां है क्योंकि फ्रॉस्टबाइट (DA: I का इंजन) को बहुत सावधानी से ट्यूनिंग के साथ जमीन से डिज़ाइन किया गया है जिसके लिए एक विशेष संख्या में कोर की आवश्यकता होती है।
लार्स विकलुंड

6
@LarsViklund ऐसा लगता है कि आप यहाँ किसी और से अधिक विवरण जानते हैं। क्या आपने एक उत्तर देने पर विचार किया है?
को रोबोट

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

2
@ मुझे संदेह है कि एक अंत उपयोगकर्ता आसानी से बता सकता है कि किसी विशेष गेम का संसाधन किसी अन्य की तुलना में कितना गहन है।
रोबोट

9

तीन रीयलटाइम थ्रेड्स जो कभी नहीं सोते हैं और एक अन्य थ्रेड। यदि चार से कम कोर हैं, तो चौथा धागा कभी नहीं चलता है। यदि चौथे थ्रेड को रीयलटाइम थ्रेड के लिए रीयलटाइम थ्रेड्स में से एक के साथ संवाद करने की आवश्यकता है, तो कोड चार कोर से कम के साथ समाप्त नहीं होगा।

जाहिर है कि अगर रियलटाइम थ्रेड्स किसी ऐसी चीज का इंतजार कर रहे हैं जो उन्हें सोने नहीं देती है (जैसे कि पालक) तो प्रोग्राम डिजाइनर खराब हो जाता है।


1
संभवतः, जब कोई उपयोगकर्ता पहले स्थान पर रियलटाइम थ्रेड्स का अनुरोध करता है, तो डिज़ाइनर खराब हो जाता है: D
Luaan

2
मेंने यह किया है। कोड की डेढ़ लाख लाइनें। लगभग 300 लाइनों का उपयोग कर एक मामला। रीयलटाइम थ्रेड अपना अधिकांश समय इनपुट के इंतजार में बिताता है ताकि यह इनपुट को टाइमस्टैम्प कर सके और इसे कम प्राथमिकता वाले थ्रेड पर सौंप सके।
जोशुआ

2
@ Luaan अधिकांश अनुप्रयोगों के लिए मैं आपसे सहमत हूँ, लेकिन एम्बेडेड अनुप्रयोगों के रूप में खेल एक अलग जानवर हैं। उन दोनों मामलों में, अन्य समवर्ती अनुप्रयोगों के साथ अच्छा खेलने की चिंता ज्यादातर प्रदर्शन के पक्ष में खिड़की से बाहर जाती है।
रीबराब

हालांकि यह विशेष रूप से कुशल नहीं होगा, यह परिदृश्य किसी भी गतिरोध को जन्म नहीं देगा - प्राथमिकता उलटा इसका ख्याल रखेगा (पिछले दशक के किसी भी प्रमुख ओएस में किसी भी आधे सभ्य शिष्टाचार को मानते हुए)
वू

2
@ जोशुआ > विंडोज को पता नहीं है कि प्राथमिकता का उलटा क्या है। क्या? support.microsoft.com/kb/96418 , msdn.microsoft.com/en-us/library/windows/desktop/ms684831.aspx । इसके अलावा, प्राथमिकता व्युत्क्रम वह शब्द है जो समस्या का वर्णन करता है , न कि समाधान (@Voo)।
बॉब

3

सबसे पहले सॉफ्टवेयर थ्रेड्स का हार्डवेयर थ्रेड्स से कोई लेना-देना नहीं है और अक्सर इसे मिलाया जाता है। सॉफ़्टवेयर थ्रेड्स कोड के टुकड़े हैं जिन्हें प्रेषण प्रक्रिया के भीतर भेजा जा सकता है। हार्डवेयर थ्रेड ज्यादातर ओएस द्वारा प्रबंधित किए जाते हैं और नियमित कार्यक्रमों के बारे में बात करते समय प्रोसेसर के कोर में भेज दिए जाते हैं। ये हार्डवेयर थ्रेड लोड के आधार पर भेजे जाते हैं; हार्डवेयर थ्रेड डिस्पैचर लोड बैलेंसर की तरह कम या ज्यादा काम करता है।

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


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

2
जब तक पीसी गेमिंग है तब तक ये समस्याएं मौजूद हैं। शुरुआत में हमारे पास 486dx और 486sx थे, बाद में MMX और नॉन-MMX पेंटियम, कोर और नॉन-कोर और आज हमारे पास n-core आवश्यकताएं हैं। यह उन कारणों में से एक है जो अभी भी मौजूद हैं।
डीजे बेजी वाजई

4
क्या आपके पास CPU शेड्यूल करने वाले गेम का संदर्भ स्वयं है? जहां तक ​​मुझे जानकारी थी, यह सीधे विंडोज के तहत संभव नहीं है, कम से कम एक तरह से नहीं जो आपके सुझाव के तरीके में विफल होगा।
जूल्स

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

1
@djbazziewazzie आप ग्रैंड सेंट्रल डिस्पैच की बात को गलत समझते हैं, जो डेवलपर्स को इस बात पर अधिक नियंत्रण नहीं देता है कि उनका कोड एक कोर पर कैसे नियत है; वास्तव में, इसका उद्देश्य सटीक विपरीत है: यह चुनने के लिए कि कितने धागे बनाने हैं और कौन से कोड को किस धागे पर चलना चाहिए, अनुप्रयोगों के हाथों से बाहर निकले ताकि इसे सिस्टम-वाइड स्तर पर उपलब्ध हार्डवेयर के लिए अनुकूलित किया जा सके। एक निश्चित संख्या में कोर होने पर निर्भरता ठीक उसी तरह की समस्या है जिसे रोकने के लिए जीसीडी को डिजाइन किया गया था।
जूल्स

1

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

कहने का तात्पर्य यह है कि ऐसा सॉफ्टवेयर लिखना संभव नहीं है जो हमेशा एन कोर से कम पर रुके।

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


1

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


1
ऐसे परिदृश्य में खेल भी बेतरतीब ढंग से विफल हो जाएगा जब पृष्ठभूमि सेवाओं को चलाने के लिए निर्धारित किया गया था, जो कि अधिकांश पीसी पर अक्सर होता है।
जूल्स

1

मुझे लगता है कि यहोशू सही रास्ते पर जा रहा है, बस यह निष्कर्ष नहीं है।

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

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


यह आमतौर पर एक धागा लिखना संभव नहीं है जो अन्य थ्रेड्स पर नियंत्रण को त्याग नहीं करेगा। सभी आधुनिक गैर-आरटीओएस ऑपरेटिंग सिस्टम प्रीमेप्टिव मल्टीटास्किंग का उपयोग करते हैं, जो जानबूझकर किसी दिए गए कोर के नियंत्रण को जारी नहीं करने के लिए (उपयोगकर्ता मोड) थ्रेड के लिए असंभव बनाता है। कर्नेल थ्रेड्स, निश्चित रूप से, एक अलग मामला है।
१rab:०५ पर रीहराब

@reirab बूस्ट यह प्राथमिकता है।
लोरेन Pechtel

@ लॉरेन ने इस तथ्य को नहीं बदला कि शेड्यूलर अभी भी अपना काम करता है जिसका अर्थ है कि आपको उसी प्राथमिकता के अन्य थ्रेड्स के साथ समय साझा करना होगा और शेड्यूलर भूखे धागे की प्राथमिकता को बढ़ाएगा। आप सामान्य OSes पर नहीं कर सकते हैं और यदि आप कर सकते हैं, तो भी गेम निश्चित रूप से ऐसा करने का स्वीकार्य आवेदन नहीं होगा।
वू

1

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

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

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


1

ताला विवाद के किसी भी ध्यान देने योग्य राशि के साथ स्पिनकॉक का उपयोग करने वाला कोई भी कोड बहुत हद तक (खेल की तरह एक आवेदन के लिए - जहां आप कह सकते हैं - "काम नहीं करता है" ) यदि धागे की संख्या कोर की संख्या से अधिक है।

उदाहरण के लिए कल्पना कीजिए कि एक निर्माता धागा एक कतार में कार्य प्रस्तुत करता है जो 4 उपभोक्ता धागे परोसता है। केवल दो कोर हैं:

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

ध्यान दें कि यह किसी भी तरह के लॉक के साथ सिद्धांत रूप में काम करता है, न केवल स्पिनलॉक - लेकिन विनाशकारी प्रभाव स्पिनलॉक के साथ अधिक प्रमुख है क्योंकि सीपीयू जलता रहता है जबकि यह कुछ भी प्राप्त नहीं करता है।

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


यही कारण है कि अच्छे स्पिनलॉक एक छोटे समय के बाद अन्य लॉक प्रकारों के लिए डाउनग्रेड करते हैं, और इससे भी बेहतर यह है कि बहुत जल्दी करें यदि उसी लॉक के पिछले usages को डाउनग्रेड करना पड़ा है।
इयान

-1

अगर मैं समझता हूं कि आप क्या पूछ रहे हैं, तो यह संभव है, लेकिन यह बहुत, बहुत बुरी बात है।

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

यह समय और शुद्धता के बीच निर्भरता है जिसे कंप्यूटर विज्ञान एक दौड़ की स्थिति कहता है ।

रेस स्थितियों को अक्सर सिंक्रनाइज़ेशन तंत्र का उपयोग करके टाला जाता है ताकि यह सुनिश्चित हो सके कि साझा डेटा के एक टुकड़े पर काम करने के लिए थ्रेड्स को एक्सेस के लिए लाइन में लगना पड़ता है। ऊपर वर्णित काउंटर इसके लिए रीड-राइट लॉक का उपयोग कर सकता है ।

ड्रैगन एज के आंतरिक डिजाइन तक पहुंच के बिना : सभी, जो कोई भी कर सकता है, वह इस बारे में अटकलें लगाता है कि यह इस तरह से व्यवहार क्यों करता है। लेकिन मेरे पास अपने अनुभव में की गई कुछ चीजों के आधार पर एक यात्रा होगी:

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

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

यदि ड्रैगन आयु: पूछताछ यह सुनिश्चित करने का सरल कदम नहीं उठाती है कि आगे बढ़ने से पहले पर्याप्त भौतिक कोर उपलब्ध हैं, तो यह ईए की गलती है। वे शायद बहुत कम हार्डवेयर पर गेम चलाने की कोशिश करने वाले लोगों से एक छोटे से भाग्य फ़ील्डिंग समर्थन कॉल और ईमेल खर्च कर रहे हैं।


1
कुछ खिलाड़ियों का कहना है कि इसकी वजह से डीआरएम 2 कोर पर चल रहा है और वास्तविक गेम 2 पर भी चलता है। जब डीआरएम और गेम थ्रेड एक ही कोर पर चलते हैं तो गड़बड़ हो जाती है। लेकिन यह मेरे लिए सही नहीं है, यह एक खिलाड़ी द्वारा बनाई गई एक छोटी सी कहानी हो सकती है जो कि sw या hw आर्किटेक्चर के बारे में ज्यादा नहीं जानती है।
uylmz

4
दौड़ की स्थिति वास्तव में कोर काउंट के साथ बहुत कुछ नहीं कर सकती है, -1 ... कई वर्चुअल थ्रेड वाली एक एकल कोर मशीन में दौड़ की स्थिति पूरी तरह से रनटाइम के समय के लिए स्लाइसिंग तकनीक पर निर्भर हो सकती है, या कई कोर प्रणाली सभी दौड़ स्थितियों पर निर्भर रहने से बच सकती है मेमोर ऑपरेशंस के साथ यह कितना सख्त है ...
जिमी हॉफ

1
@Reek: कार्यक्रम कैसे काम करता है, इसका गहन ज्ञान के बिना, कुछ भी एक अनुमान है। सिर्फ डीआरएम करने के लिए दो कोर मुझे बहुत ज्यादा लगते हैं।
ब्लरफ्ल

1
@ जिमीहॉफ: मैं असहमत हूं। एक दौड़ की स्थिति अभी भी एक दौड़ की स्थिति है, जब यह अवांछित व्यवहार का कारण नहीं है। कोर काउंट प्रभावित कर सकता है कि क्या व्यवहार होता है या नहीं, जो कि प्रश्नकर्ता ने पूछा है, लेकिन मैंने इसे एकमात्र चर के रूप में नहीं बताया है।
ब्लरफ्ल

-1

विंडोज में इसके लिए अंतर्निहित कार्यक्षमता है: फ़ंक्शन GetLogicalProcessorInformation विंडोज एपीआई में है । आप इसे अपने प्रोग्राम से कोर, वर्चुअल कोर और हाइपरथ्रेडिंग के बारे में जानकारी प्राप्त करने के लिए कह सकते हैं।

तो आपके प्रश्न का उत्तर होगा: हाँ।


3
मैं नहीं पूछ रहा हूं "क्या मुझे कोड से कोर का कोई पता नहीं चल सकता है?" ... ऐसा कोड अशुभ होगा (किसी प्रोग्राम को चलाने के लिए आपको अधिक महंगा सीपीयू खरीदने के लिए मजबूर करता है - कम्प्यूटेशनल पावर की आवश्यकता के बिना)।
uylmz

3
यह फ़ंक्शन बहुत अधिक जानकारी देता है फिर सिर्फ एक कच्चा "कोर की संख्या"। इस जानकारी के साथ आप भौतिक कोर, तार्किक कोर और बहुत कुछ घटा सकते हैं। यदि आप उस कटौती कर सकते हैं, तो आप इस जानकारी का उपयोग करने के लिए सॉफ़्टवेयर लिख सकते हैं। एक अच्छे या बुरे तरीके से (क्रैश प्रोग्राम जब आप 4 कोर देखते हैं लेकिन कम है तो 4 भौतिक कोर)।
पीटर बी

1
यह विंडोज में काम कर सकता है, लेकिन OSX / Linux / iOS / Android / etc के बारे में क्या? हालांकि यह एक गेम को एक उदाहरण के रूप में संदर्भित कर रहा है जहां यह व्यवहार देखा जाता है (और प्राकृतिक सहसंबंध विंडोज = गेमिंग होगा), यह एक गेम विशिष्ट अनुरोध नहीं लगता है।
रॉबर्ट

ड्रैगन एज जैसे गेम के लिए, विचाराधीन सिस्टम विंडोज / एक्सबॉक्स / पीएस 4 हैं।
को रोबोट

लिनक्स में /proc/cpuinfoऔर sysconf(_SC_NPROCESSORS_ONLN)(बाद में POSIX में उल्लेख किया जा रहा है)। यद्यपि न्यूनतम प्रदर्शन सीमा को लागू करने के लिए जानकारी का उपयोग करना अभी भी बहुत बुरा रूप है।
cHao
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.