सॉफ्टवेयर प्रोग्रामिंग में, क्या CPU और GPU दोनों को 100% पर लोड करना संभव होगा?

Question

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

तो मैंने सोचा: सीपीयू 100% लोड पर है, जबकि सीपीयू 50% (उदाहरण के लिए) अपरिहार्य है?

या, अधिक सटीक रूप से: क्या कुछ गणनाएं जो सामान्य रूप से सीपीयू द्वारा की जाती हैं, यदि पहला 100% लोड पर होता है, तो सीपीयू द्वारा किया जाता है, ताकि दोनों 100% लोड तक पहुँच सकें?

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

Comments

सीपीयू और जीपीयू दोनों का एक NO-OPही समय में अनंत लूप चलाने के लिए यह संभव है , जिससे दोनों 100% लोड हो सकें।

— जोर्ग डब्ल्यू मित्तग

@ Jörg के बिंदु के बाद, CPU% द्वारा मापी जाने वाली एकमात्र चीज वह है जो समय का अंश अन्य प्रोसेसर के इंतजार में खर्च नहीं किया जाता है। यदि कार्यक्रम कुशल है या कार्यक्रम अक्षम है तो 100% अच्छी बात हो सकती है। बहुत अधिक समय, लोग सीपीयू% पर ध्यान केंद्रित करते हैं जैसे कि यह प्रदर्शन का एक उपाय है - यह नहीं है।

— माइक डनलैवी

मूल Crysis ने यह ठीक किया।

— क्यूबिकलसॉफ्ट

@ माइकडूलेवी आप एक अच्छा बिंदु लाते हैं। कारों के साथ हम RPM द्वारा उनके प्रदर्शन को नहीं मापते हैं, हम गति को मापते हैं।

— कप्तान मैन

@ JörgWMittag: सीपीयू, हो सकता है। लेकिन ओएस और जीपीयू में अनंत लूप से निपटने के लिए हल करने की समस्या है। अर्थात्, यदि कोई शेडर उचित समय में पूरा नहीं करता है, तो वह मर जाता है और GPU रीसेट कर देता है।

— निकोल बोलस

Answer 1

सैद्धांतिक रूप से हाँ, लेकिन व्यावहारिक रूप से यह शायद ही कभी इसके लायक है।

सीपीयू और जीपीयू दोनों ही ट्यूरिंग-पूर्ण हैं , इसलिए किसी भी एल्गोरिथ्म की गणना एक द्वारा की जा सकती है और दूसरे की गणना भी की जा सकती है। सवाल यह है कि कितना तेज और कितना सुविधाजनक है।

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

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

Comments

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

— मैडवर्ड

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

— एथन

@gardenhead ब्रह्माण्ड में कुछ भी अनबिके पुनर्संरचना का समर्थन नहीं करता है, क्योंकि ब्रह्माण्ड परिमित आकार है और इसमें सूचना का घनत्व कम है। एक प्रणाली की "ट्यूरिंग-पूर्णता" आम तौर पर इस बात की चर्चा है कि हटाए गए ऐसे अवरोधों के साथ क्या संभव होगा।

— 198 में रैंडम 832

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

— 21

@leftaroundabout आधुनिक जीपीयू किसी भी सीपीयू के रूप में तुच्छ रूप से पूरा कर रहे हैं । ट्यूरिंग पूर्णता के साथ कुछ नहीं करना है: 1) प्रदर्शन 2) स्रोत की पठनीयता। 80 का सीपीयू टीसी के करीब था, बाकी सब कुछ: या तो वे टीसी थे या वे नहीं थे (बाद वाला विकल्प बकवास था)।

— मार्गरेट ब्लूम

Answer 2

यह गेम प्रोग्रामिंग से संबंधित नहीं है। कुछ वैज्ञानिक कोड भी GPU और CPU दोनों का उपयोग कर सकते हैं।

सावधान-और पीड़ादायक प्रोग्रामिंग के साथ, जैसे कि OpenCL या CUDA का उपयोग करके , आप अपने GPU और CPU दोनों को 100% के पास लोड कर सकते हैं। बहुत शायद आपको GPU (तथाकथित "कर्नेल" कोड) और CPU के लिए कोड के कुछ टुकड़े लिखने की आवश्यकता होगी, और कुछ उबाऊ गोंद कोड (विशेष रूप से GPU में संकलित कर्नेल कोड भेजने के लिए)।

हालांकि, कोड जटिल होगा, और आपको संभवतः उस विशेष हार्डवेयर पर ट्यून करना होगा, जिस पर आप विशेष रूप से चल रहे हैं, क्योंकि GPU और CPU के बीच डेटा ट्रांसमिशन महंगा है।

विषम कंप्यूटिंग के बारे में और पढ़ें ।

OpenACC भी देखें , GCC के हाल के संस्करणों द्वारा समर्थित (उदाहरण के लिए जून 2016 में GCC 6 )

Comments

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

— मैडवर्ड

यह काफी हद तक दो एल्गोरिदम के साथ समाप्त होगा। मैंने इसे एक बार आज़माया: पूरी छवि एक बार जीपीयू के लिए, और एक बार सीपीयू (बड़े कैश का दुरुपयोग करने के लिए) कई छवियां। यह वास्तव में दर्दनाक है, खासकर बनाए रखने के लिए।

— पीटी राइटर

Answer 3

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

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

if (expr1)
    expr2;
else
    expr3;

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

फिर आपके पास सीपीयू में सिमड फीचर्स हैं जो वेक्टर ऑपरेशन हैं। यह इस अर्थ में GPGPU- प्रकाश की तरह है कि आप आमतौर पर एक ही समय में केवल चार या आठ ऑपरेशन करते हैं, GPU 32 या 64 की तरह करते हैं। फिर भी आपको FLOPS को क्रैंक करने के लिए उपयोग करना होगा।

झूठे बंटवारे की तरह सामान इतनी भारी सिंक्रनाइज़ेशन लागत का कारण बन सकता है जो आमतौर पर लिनक्स में कर्नेल लोड के रूप में दिखाई देता है। सीपीयू पूरी तरह से उपयोग किया जाता है, लेकिन आपके पास बहुत उपयोगी थ्रूपुट नहीं है।

मैंने आईबीएम ब्लू जीन / क्यू मशीन पर कुछ प्रोग्रामिंग की है। इसके कई पदानुक्रम स्तर हैं ( पुराने ब्लू जीन / एल के योजनाबद्ध ) और इसलिए इसे कुशलता से प्रोग्राम करना मुश्किल है। प्रदर्शन को पूरा करने के लिए आपको SIMD और SMT (Intel कॉल इस हाइपरथ्रेडिंग) को पूरा पदानुक्रम नीचे उपयोग करना होगा।

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

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

Answer 4

आपको मोज़िला रिसर्च में विकसित किए जा रहे सर्वो ब्राउजर इंजन की जाँच करने में रुचि हो सकती है , और विशेष रूप से इसके वेब रेंडर (वीडियो) को ।

सीपीयू से GPU में किसी कार्य को गतिशील रूप से करना अव्यावहारिक हो सकता है, जैसा कि अन्य उत्तरों में उल्लेखित है (विशेषकर @ फिलिप के), यह पहले से विशिष्ट कार्यभार पर सीपीयू / जीपीयू के भार का अध्ययन करने और कुछ कार्यों को आम तौर पर कम लोड करने के लिए व्यावहारिक हो सकता है। एक।

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

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

लक्ष्य, ज़ाहिर है, GPU के लिए रेंडरिंग प्रक्रिया के जितना संभव हो, ऑफ-लोड करना है, जावास्क्रिप्ट को निष्पादित करने के लिए सीपीयू को मुक्त करना, डोम, और अन्य सभी कार्यों को अपडेट करना है।

तो, जबकि आपके सुझाव के रूप में चरम नहीं है, यह सीपीयू और जीपीयू दोनों को ध्यान में रखते हुए गणना की रणनीति तैयार करने की दिशा में जाता है।

Answer 5

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

इस स्थिति में, आप इसे सीपीयू पर कर सकते हैं और रेंडर करने के लिए जीपीयू पर परिणाम अपलोड कर सकते हैं या जीपीयू पर गणना और रेंडरिंग कर सकते हैं। मेरा मानना ​​है कि आजकल यह GPU ("हार्डवेयर स्किनिंग" के रूप में जाना जाता है) पर किया जाता है: यह ऐसा करने के लिए समझ में आता है, क्योंकि आपके पास अपेक्षाकृत सरल गणनाएं होती हैं जिन्हें हजारों बार किया जाना होता है, और परिणाम के बाद प्रत्येक शीर्ष की गणना समवर्ती रूप से की जा सकती है। शीर्ष B के परिणाम पर A का कोई असर नहीं है।

सिद्धांत रूप में, आप सीपीयू और जीपीयू पर यह करने के बीच गतिशील रूप से स्विच कर सकते हैं कि जीपीयू और सीपीयू कैसे ओवरलोड हैं।

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

कुल मिलाकर, GPU प्रोग्रामिंग के साथ प्रमुख मुद्दा (कम से कम ओपनजीएल और डायरेक्टएक्स 11 और उसके तहत) यह है कि आपके पास इस बात पर थोड़ा नियंत्रण है कि GPU आपके shader कोड की कैसे व्याख्या करता है। किसी शेडर के भीतर शाखा लगाना जोखिम भरा होता है क्योंकि यदि आप गलती से गणनाओं के बीच एक निर्भरता बना लेते हैं, तो GPU आपके पिक्सेल को एक-एक करके रेंडर करने का निर्णय ले सकता है, वास्तविक डेटा समरूप होने के बावजूद एक पल में 60fps को 10fps करने के लिए।

Answer 6

एक वास्तविक विश्व उदाहरण ओपन सोर्स लक्सर रेंडरिंग इंजन है, जो एक ही समय में सीपीयू और जीपीयू को पूरी तरह से लोड करने में सक्षम है। इसके अलावा, यह एक ही समय में कई GPU लोड कर सकता है और कई कंप्यूटरों में वितरित भी कर सकता है।

LuxRender OpenCL को इस सुविधा के लिए उपयोग करता है , हालांकि OpenCL के बिना भी बनाता है।

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

Comments

इस छवि को दिखाने की बात क्या है, यह पूछे गए प्रश्न के लिए कैसे प्रासंगिक है?

— गन्नत

एह ठीक है। मैं इसे हटा दूंगा। मैं सोच रहा था कि यह आसानी से प्रदर्शित करेगा कि यह किस तरह का सॉफ्टवेयर है। लेकिन शायद यह वास्तव में विचलित करने वाला है। (कई अलग-अलग प्रकार के रेंडरिंग इंजन; यह एक फोटोरिअलिस्टिक स्टिल्स पर लक्षित है।)

— पाइथननॉट

Answer 7

हां, यह निश्चित रूप से संभव है।

कोई भी गणना जो सीपीयू कर सकता है, एक जीपीयू भी कर सकता है, और इसके विपरीत।

लेकिन यह असामान्य है क्योंकि:

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

• जीपीयू की तुलना में लागत दक्षता जीपीयू अधिक शक्तिशाली हैं। जीपीयू का पूरा विचार सस्ता, धीमी गति का उपयोग करना है, लेकिन सीपीयू की तुलना में कहीं अधिक तेजी से गणना करने के लिए कई और प्रोसेसर समान लागत के लिए कर सकते हैं। GPU परिमाण के एक या दो आदेशों द्वारा अधिक कुशल लागत-वार हैं।

यदि आप GPU पर चलने के लिए अपना एल्गोरिथ्म प्राप्त करते हैं, तो यह केवल उन लोगों के लिए अनुकूलन करने के लिए अधिक समझ में आता है, और जितनी आवश्यकता हो उतने जोड़ें।