डॉट्स स्टैक: C ++ और C #

यह हमारी नई डेटा ओरिएंटेड टेक्नोलॉजी स्टैक ( डॉट्स ) का एक संक्षिप्त परिचय है। हम आपको यह समझने में मदद करने के लिए कुछ अंतर्दृष्टि साझा करेंगे कि एकता आज कैसे और क्यों बन गई है, और यह भी बताएं कि हम किस दिशा में विकसित होने की योजना बना रहे हैं। भविष्य में, हम एकता ब्लॉग पर नए डॉट्स लेख प्रकाशित करने की योजना बनाते हैं।

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

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

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

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

हम किन कारकों को प्राथमिकता देते हैं?

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

इसलिए, यह पता लगाना कि हमारे लिए क्या महत्वपूर्ण है, आइए अगले प्रश्न पर जाएं: किस भाषा में उन कार्यक्रमों को लिखना बेहतर है जिनसे इस तरह के मशीन कोड तब उत्पन्न होंगे? मान लें कि हमारे पास निम्नलिखित विकल्प हैं:

• अपनी भाषा
• C या C ++ का कुछ अनुकूलन / सबसेट
• सी # का सबसेट

क्या, सी #? हमारे आंतरिक छोरों के लिए जिनका प्रदर्शन विशेष रूप से महत्वपूर्ण है? हां। C # एक पूरी तरह से प्राकृतिक विकल्प है, जिसके साथ एकता के संदर्भ में बहुत अच्छी चीजें हैं:

• यह वह भाषा है जो हमारे उपयोगकर्ता पहले से ही आज के साथ काम कर रहे हैं।
• इसमें एक उत्कृष्ट IDE है, जो संपादन / रीफैक्टरिंग, और डीबगिंग दोनों के लिए है।
• पहले से ही एक संकलक है जो C # को एक मध्यवर्ती IL में परिवर्तित करता है (हम Microsoft से C # के लिए Roslyn संकलक के बारे में बात कर रहे हैं), और आप इसे बस अपना लिखने के बजाय इसका उपयोग कर सकते हैं। हमारे पास एक मध्यवर्ती भाषा को आईएल में परिवर्तित करने का समृद्ध अनुभव है, इसलिए हमें बस एक विशिष्ट प्रोग्राम कोड पीढ़ी और पोस्टप्रोसेसिंग करने की आवश्यकता है।
• C # कई C ++ समस्याओं से रहित है (हेडर के समावेश के साथ नरक, PIMPL पैटर्न, लंबे संकलन समय)

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

इसके अलावा, इस भाषा की मानक लाइब्रेरी "ढेर पर ऑब्जेक्ट" और "ऑब्जेक्ट्स जिनमें अन्य ऑब्जेक्ट्स के लिए पॉइंटर्स हैं" के आसपास आयोजित किया जाता है।

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

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

फट संकलनकर्ता: आज क्या है?

हमने एक कोड जनरेटर / संकलक लिखा है जिसे बर्स्ट कहा जाता है। यह एकता संस्करण 2018.1 में उपलब्ध है और "पूर्वावलोकन" मोड में एक पैकेज के रूप में अधिक है। उसके साथ बहुत काम किया जाना बाकी है, लेकिन हम आज उससे प्रसन्न हैं।

कभी-कभी हम C ++ की तुलना में तेजी से काम करने का प्रबंधन करते हैं, अक्सर - C ++ की तुलना में अभी भी अधिक धीरे-धीरे। दूसरी श्रेणी में प्रदर्शन कीड़े शामिल हैं, जो हम आश्वस्त हैं, सामना करने में सक्षम होंगे।

हालांकि, केवल प्रदर्शन की तुलना करना पर्याप्त नहीं है। कोई कम महत्वपूर्ण नहीं है कि इस तरह के प्रदर्शन को प्राप्त करने के लिए क्या किया जाना चाहिए। उदाहरण: हमने अपने वर्तमान C ++ रेंडरर से कलिंग कोड लिया और इसे बर्स्ट में पोर्ट किया। प्रदर्शन नहीं बदला है, लेकिन C ++ संस्करण में हमें अपने C ++ कंपाइलरों को वैश्वीकरण करने के लिए राजी करने के लिए अविश्वसनीय संतुलन कार्य करना था। बर्स्ट वाला संस्करण लगभग चार गुना अधिक कॉम्पैक्ट था।

ईमानदारी से, "आपको सी # में प्रदर्शन के लिए महत्वपूर्ण अपने कोड को फिर से लिखना चाहिए" के साथ पहली नज़र में आंतरिक एकता टीम में किसी से भी अपील नहीं की। हम में से अधिकांश के लिए, यह "हार्डवेयर के करीब!" की तरह लग रहा था जब सी ++ के साथ काम कर रहा था। लेकिन अब स्थिति बदल गई है। C # का उपयोग करते हुए, हम पूरी प्रक्रिया को स्रोत कोड को संकलित करने से लेकर मशीन कोड बनाने तक पूरी तरह से नियंत्रित करते हैं, और अगर हमें कोई विवरण पसंद नहीं है, तो हम इसे लेते हैं और इसे ठीक करते हैं।

हम C ++ से HPC # तक सभी प्रदर्शन-महत्वपूर्ण कोड को धीरे-धीरे लेकिन निश्चित रूप से पोर्ट करने जा रहे हैं। इस भाषा में, हमें जिस प्रदर्शन की आवश्यकता है उसे प्राप्त करना आसान है, बग को लिखना अधिक कठिन है, और इसके साथ काम करना आसान है।

यहाँ बर्स्ट इंस्पेक्टर का स्क्रीनशॉट है, जहाँ आप आसानी से देख सकते हैं कि आपके विभिन्न हॉट लूप्स के लिए कौन से असेंबली निर्देश तैयार किए गए थे:



एकता के कई अलग-अलग उपयोगकर्ता हैं। उनमें से कुछ मेमोरी से arm64 निर्देशों के पूरे सेट को याद कर सकते हैं, जबकि अन्य बस उत्साह के साथ बनाते हैं, यहां तक ​​कि कंप्यूटर विज्ञान में पीएचडी के बिना भी।
सभी उपयोगकर्ता तब जीतते हैं जब यह इंजन कोड निष्पादित करने पर खर्च होने वाले फ्रेम समय के अंश को तेज करता है (आमतौर पर 90% +)। एसेट स्टोर पैकेज के निष्पादन योग्य कोड के साथ काम करने की हिस्सेदारी वास्तव में तेज है, क्योंकि एसेट स्टोर पैकेज के लेखक एचपीसी # को अपना रहे हैं।

उन्नत उपयोगकर्ताओं को इस तथ्य से भी लाभ होगा कि वे एचपीसी # पर अपना स्वयं का उच्च-प्रदर्शन कोड लिख सकते हैं।

बिंदु अनुकूलन

C ++ में, अपनी परियोजना के विभिन्न हिस्सों में कोड के अनुकूलन पर विभिन्न समझौता निर्णय लेने के लिए कंपाइलर को प्राप्त करना बहुत मुश्किल है। सबसे विस्तृत अनुकूलन जिस पर आप भरोसा कर सकते हैं वह अनुकूलन के स्तर का एक फ़ाइल-दर-फ़ाइल संकेत है।

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

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

यह आम थ्रेडिंग समस्याओं को हल करने में कैसे मदद करता है?

सी ++ (साथ ही सी #) विशेष रूप से डेवलपर्स को थ्रेड-सुरक्षित कोड लिखने में मदद नहीं करते हैं।

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

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

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

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

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

पूरे ढेर को मास्टर करें

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

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

गेम इंजन कोड और गेम कोड के बीच अंतर धुंधला है

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