Godot: लगभग हर बार सबसे धीमी डेटा संरचना का उपयोग करना।

प्रदर्शन की जरूरत किसे है? :ट्रॉल फ़ेस:

यह देखने के लिए उत्सुक है कि आप क्या मापते हैं।

तो यह समझा सकता है कि गोडोट में एक साधारण लाइट2डी नोड आपके कंप्यूटर को क्यों जला सकता है?

@ रानोलर मुझे ऐसा नहीं लगता। खराब रोशनी का प्रदर्शन इस समय सबसे अधिक संभावना से संबंधित है कि गोडोट इस समय 2डी प्रकाश व्यवस्था कैसे करता है: प्रत्येक स्प्राइट को एन-बार प्रस्तुत करना (एन के साथ रोशनी की संख्या जो इसे प्रभावित कर रही है)।

संपादित करें: देखें #23593

स्पष्ट करने के लिए, यह पूरे कोड में CPU पक्ष की अक्षमताओं के बारे में है। इसका गोडोट फीचर्स या गोडोट जीपीयू रेंडरिंग से कोई लेना-देना नहीं है।

@ vblanco20-1 एक साइड-टेंजेंट पर, आपने और मैंने नोड्स के बजाय ECS संस्थाओं के रूप में मॉडलिंग किए जाने के बारे में बात की थी। मुझे आश्चर्य है कि क्या चाल एक नए ईएनटी मॉड्यूल के साथ गोडोट की फीचर शाखा करना है जो धीरे-धीरे पेड़ के साथ-साथ काम करेगी। get_tree() और get_registry() की तरह। ईएनटी मॉड्यूल शायद पेड़/दृश्य की कार्यक्षमता के 80% की तरह याद करेगा, लेकिन यह टेस्टबेड के रूप में उपयोगी हो सकता है, खासतौर पर सामानों के लिए बड़े स्थिर स्तरों को लिखने के लिए बहुत सारी वस्तुओं (कुलिंग, स्ट्रीमिंग, बैच प्रतिपादन) के साथ। कम कार्यक्षमता और लचीलापन लेकिन अधिक से अधिक प्रदर्शन।

पूर्ण ईसीएस (जो मैं कर सकता हूं) जाने से पहले मैं प्रयोग के रूप में कुछ कम लटकने वाले फलों पर काम करना चाहता हूं। मैं बाद में लाइन के नीचे पूर्ण डेटा-उन्मुख जाने की कोशिश कर सकता हूं।

तो, पहले अपडेट:

update_dirty_instances : 0.2-0.25 मिलीसेकंड से 0.1 मिलीसेकंड तक
octree_cull (मुख्य दृश्य): 0.35 मिलीसेकंड से 0.1 मिलीसेकंड तक

मजेदार हिस्सा? ऑक्ट्री कल के लिए प्रतिस्थापन किसी भी त्वरण संरचना का उपयोग नहीं कर रहा है, यह सभी एएबीबी के साथ एक गूंगा सरणी पर फिर से चलता है।

और भी मजेदार हिस्सा? नई कलिंग कोड की 10 पंक्तियाँ हैं। अगर मैं इसे समानांतर रखना चाहता हूं, तो यह लाइन में एक ही बदलाव होगा।

मैं रोशनी के साथ अपनी नई कलिंग को लागू करना जारी रखता हूं, यह देखने के लिए कि स्पीडअप कितना जमा होता है।

हमें शायद मास्टर शाखा पर भी एक Google बेंचमार्क निर्देशिका मिलनी चाहिए। यह मान्य करने में मदद कर सकता है ताकि लोगों को इसके बारे में बहस न करनी पड़े।

Godotengine/godot-tests रिपॉजिटरी है, लेकिन अभी तक बहुत से लोग इसका उपयोग नहीं कर रहे हैं।

नई अपडेट:

Ive ने 2 स्तरों के साथ काफी गूंगा स्थानिक त्वरण संरचना लागू की। मैं बस इसे हर फ्रेम उत्पन्न कर रहा हूं और सुधार इसे बेहतर बना सकता है और इसे रीमेक करने के बजाय इसे गतिशील रूप से अपडेट कर सकता है।

छवि में, अलग-अलग पंक्तियाँ अलग-अलग स्कोप हैं, और प्रत्येक रंगीन ब्लॉक कोड का एक कार्य/हिस्सा है। उस कैप्चर में, मैं एक सीधी तुलना करने के लिए ऑक्ट्री कल्ल और माई कल्ट दोनों को साथ-साथ कर रहा हूं

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

मुझे एक भी ऐसा मामला नहीं मिला, जहां मेरी गूंगा संरचना वर्तमान ऑक्ट्री की तुलना में धीमी हो, अन्य यह कि प्रारंभिक निर्माण की लागत।

एक और बोनस यह है कि यह बहुत ही मल्टीथ्रेड फ्रेंडली है, और जो भी कोर काउंट आप चाहते हैं, उसके लिए समानांतर के साथ बढ़ाया जा सकता है।

यह मेमोरी को पूरी तरह से जांचता है, इसलिए इसे बिना किसी परेशानी के SIMD करना संभव होना चाहिए।

एक और महत्वपूर्ण विवरण यह है कि कोड की कम पंक्तियों के साथ, वर्तमान ऑक्ट्री की तुलना में यह काफी सरल है।

आप और अधिक प्रचार कर रहे हैं कि सिंहासन के खेल का अंत ....

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

मेरा कूलर अब मुख्य दृश्य के लिए गोडोट ऑक्ट्री से 10 गुना तेज है।

यदि आप परिवर्तनों को देखना चाहते हैं, तो मुख्य महत्वपूर्ण बात यहाँ है:
https://github.com/vblanco20-1/godot/blob/4ab733200faa20e0dadc9306e7cc93230ebc120a/servers/visual/visual_server_scene.cpp#L387
यह नया कलिंग फंक्शन है। एक्सेलेरेशन स्ट्रक्चर इसके ठीक ऊपर फंक्शन पर है।

इसे वीएस2015 के साथ संकलित करना चाहिए? कंसोल entt\ के अंदर फ़ाइलों के बारे में त्रुटियों का एक गुच्छा फेंकता है

@Ranoller यह c ++ 17 है इसलिए सुनिश्चित करें कि आप नए कंपाइलर का उपयोग कर रहे हैं

उह, मुझे लगता है कि गोडोट ने अभी तक c++17 में कदम नहीं रखा है? कम से कम मुझे इस विषय पर कुछ चर्चाएँ याद हैं?

गोडोट सी++ 03 है। यह कदम विवादास्पद होगा। मैं जुआन के साथ बात करने के लिए @ vblanco20-1 की सिफारिश करता हूं जब वह हॉलीडे खत्म करता है ... यह अनुकूलन बहुत अच्छा होगा और हम तुरंत नहीं चाहते हैं "यह कभी नहीं होगा टीएम

@vblanco20-1

octree_cull (मुख्य दृश्य): 0.35 मिलीसेकंड से 0.1 मिलीसेकंड तक

कितनी वस्तुएं?

@ nem0

@vblanco20-1

octree_cull (मुख्य दृश्य): 0.35 मिलीसेकंड से 0.1 मिलीसेकंड तक

कितनी वस्तुएं?

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

मेरा सिस्टम एएबीबी के 2 स्तरों के साथ काम करता है, यह ब्लॉकों की एक सरणी है, जहां हर ब्लॉक में 128 इंस्टेंस हो सकते हैं।

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

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

Ive ने अलग-अलग नंबरों की जाँच की, और 128 प्रति ब्लॉक अभी भी किसी तरह मिठाई की जगह लगता है।

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

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

मुझे लगता है कि एक सुधार शायद वर्तमान ऑक्ट्री का पुन: उपयोग करना होगा लेकिन इसे "समतल" करना होगा।

अब ऐसा एक भी मामला नहीं है जहां मेरा एल्गोरिथ्म समानांतर निष्पादन के बिना भी वर्तमान ऑक्ट्री के बराबर या बदतर हो।

@ vblanco20-1 मुझे लगता है कि आप release मोड में संकलित गोडोट के साथ अपनी तुलना कर रहे हैं (जो -O3 का उपयोग करता है) और डीबग में नियमित संपादक बिल्ड नहीं (जिसमें कोई अनुकूलन नहीं है और डिफ़ॉल्ट है) सही है ?
क्षमा करें यदि यह एक मूर्खतापूर्ण प्रश्न है, लेकिन मुझे इसका कोई उल्लेख नहीं है।
वैसे भी अच्छा काम :)

@Faless इसकी

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

यह इस बात से प्रेरित है कि मेरे एक प्रयोग ने कैसे काम किया, जहां मैं 400,000 भौतिकी वस्तुओं को एक दूसरे से उछल रहा हूं।

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

मुझे उत्सुकता है कि यदि आप वर्तमान मास्टर शाखा के निर्माण पर उस बेंचमार्क टूल (आपके स्क्रीनशॉट में से एक) को चला सकते हैं, तो हमें एक संदर्भ बिंदु देने के लिए कि आपका कार्यान्वयन वर्तमान कार्यान्वयन पर कितना प्रदर्शन दे रहा है। मैं एक डमी हूँ, वूप्स।

@ LikeLakers2 आप स्क्रीनशॉट में वर्तमान कार्यान्वयन और उसके कार्यान्वयन दोनों को देख सकते हैं।

उसने इसे मास्टर फोर्क पर चलाया

बुधवार, दिसंबर 12, 2018 पर, MichiRecRoom [email protected]
लिखा था:

@neikeq https://github.com/neikeq समझाएं? मैंने सोचा कि स्क्रीनशॉट
जो पोस्ट किए गए हैं, वे केवल उनके कार्यान्वयन के थे, यह देखते हुए कि पोस्ट कैसे हैं
स्क्रीनशॉट के साथ अब तक शब्दबद्ध किया गया है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/23998#issuecomment-446831151 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ADLZ9pRh9Lksse9KBfWV0z5GmHRXf5P2ks5u4crCgaJpZM4YziJp
.

क्या इस विषय पर कोई खबर है?

क्या इस विषय पर कोई खबर है?

मैंने रेडज़ के साथ बात की। कभी मर्जर नहीं मिलने वाला है क्योंकि यह प्रोजेक्ट के लायक नहीं है। मैं इसके बजाय अन्य प्रयोग करने गया। हो सकता है कि मैं बाद में 4.0 . के लिए कूलिंग को अपग्रेड कर दूं

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

शायद इसे 4.0 मील का पत्थर दिया जाना चाहिए? चूंकि Reduz 4.0 के लिए वल्कन पर काम करने की योजना बना रहा है, और यह विषय, प्रदर्शन के बारे में, प्रतिपादन पर केंद्रित है, या कम से कम ओपी है।

@ vblanco20-1 क्या उन्होंने कहा कि यह कैसे फिट नहीं है? मैं सी ++ 17 की ओर बढ़ने के कारण मान रहा हूं?

हालांकि मील के पत्थर पर एक और संबंधित समस्या है: #25013

आपकी रुचि हो सकती है। मैं काफी समय से फैंसी फोर्क पर काम कर रहा हूं। वर्तमान परिणाम इस प्रकार हैं:
4 कोर इंटेल सीपीयू और जीटीएक्स 1070 . के साथ एक बड़े गेमिंग लैपटॉप पर कैप्चर किया गया
सामान्य गोडोट

मेरा कांटा https://github.com/vblanco20-1/godot/tree/ECS_Refactor . पर

दोनों प्रोफाइल में, रेड अनिवार्य रूप से "जीपीयू की प्रतीक्षा करें" है। वर्तमान में opengl पर बहुत अधिक ड्रॉ होने के कारण अड़चन है। वास्तव में वल्कन या संपूर्ण रेंडरर को फिर से लिखने के बिना हल नहीं किया जा सकता है।

सीपीयू की तरफ, हम 13 एमएस फ्रेम से 5 एमएस फ्रेम तक जाते हैं। "तेज़" फ़्रेम 5.5 ms से 2.5ms . तक जाते हैं
"कुल फ्रेम" पक्ष पर, हम 13 एमएस से 8-9 एमएस . तक जाते हैं
~75 एफपीएस से ~115 एफपीएस

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

इनमें से बहुत से सुधार गोडोट में विलय योग्य हैं, अगर गोडोट ने आधुनिक सी ++ का समर्थन किया और एक मल्टीथ्रेडिंग सिस्टम था जो बहुत सस्ते "छोटे" कार्यों की अनुमति देता है।
डायनेमिक ऑब्जेक्ट्स #25013 पर मल्टीथ्रेडेड शैडो और मल्टीथ्रेडेड लाइटमैप रीड करके सबसे बड़ा लाभ प्राप्त होता है। ये दोनों एक ही तरह से काम करते हैं। रेंडरर के कई अन्य हिस्से भी मल्टीथ्रेडेड हैं।
अन्य लाभ एक ऑक्ट्री हैं जो गोडोट एक की तुलना में 10 से 20 गुना तेज है, और प्रतिपादन के कुछ प्रवाह में सुधार, जैसे कि गहराई-प्रीपास और सामान्य-पास रेंडर सूची दोनों को एक साथ रिकॉर्ड करना, बजाय सूची 2 को पुनरावृत्त करना समय, और एक महत्वपूर्ण परिवर्तन कैसे प्रकाश-> जाल कनेक्शन काम करता है (कोई लिंक्ड सूची नहीं!)

मैं वर्तमान में टीपीएस डेमो के अलावा और अधिक परीक्षण मानचित्र ढूंढ रहा हूं ताकि मेरे पास अन्य प्रकार के मानचित्रों में अधिक मीट्रिक हो सकें। मैं लेखों की एक श्रृंखला भी लिखने जा रहा हूं जिसमें बताया गया है कि यह सब विस्तार से कैसे काम करता है।

@ vblanco20-1 यह पूरी तरह से कमाल है। साझा करने के लिए धन्यवाद!

मैं इस बात से भी सहमत हूं कि भले ही वल्कन शांत है, फिर भी एक अच्छा GLES3 प्रदर्शन होना गोडोट के लिए एक पूर्ण जीत होगी। पूर्ण वल्कन समर्थन संभवतः जल्द ही कभी भी नहीं आएगा, जबकि GLES3 को पैच करना कुछ ऐसा है जो यहाँ के लोग अभी पूरी तरह से करने योग्य साबित हुए हैं।

इस पर अधिक से अधिक ध्यान देने के लिए मेरा विशाल +1। अगर Reduz समुदाय को GLES3 में सुधार करने की अनुमति देने के लिए सहमत होता तो मैं पृथ्वी पर सबसे खुश व्यक्ति होता। हम अब 1.5 वर्षों से गोडोट में एक बहुत ही गंभीर 3डी परियोजना कर रहे हैं, और हम गोडोट (दान सहित) के प्रति बहुत सहायक हैं, लेकिन ठोस 60 एफपीएस की कमी वास्तव में हमें हतोत्साहित करती है और हमारे सभी प्रयासों को एक बड़े जोखिम में डाल देती है।

यह वास्तव में शर्म की बात है कि इसे पर्याप्त क्रेडिट नहीं मिल रहा है। यदि हमारे पास आने वाले महीनों में हमारे वर्तमान (3D के संदर्भ में बहुत सरल) प्रोजेक्ट के साथ 60 FPS नहीं होंगे, तो हम एक खेलने योग्य गेम देने में विफल रहेंगे और इस प्रकार सभी प्रयास व्यर्थ हो जाएंगे। :/

@ vblanco20-1 ईमानदारी से, मैं उत्पादन में हमारे खेल के आधार के रूप में आपके कांटे का उपयोग करने पर भी विचार कर रहा हूं।

PS कुछ विचार: अंतिम उपाय के रूप में, मुझे लगता है कि 2 GLES3 रैस्टराइज़र - GLES3 और GLES3-समुदाय का कहना पूरी तरह से संभव होगा।

PS कुछ विचार: अंतिम उपाय के रूप में, मुझे लगता है कि 2 GLES3 रैस्टराइज़र - GLES3 और GLES3-समुदाय का कहना पूरी तरह से संभव होगा।

यह मेरे लिए कोई मतलब नहीं है; GLES3 और GLES2 रेंडरर्स में सीधे सुधार और प्रदर्शन सुधार प्राप्त करना शायद एक बेहतर विचार है (जब तक कि वे मौजूदा परियोजनाओं में प्रमुख तरीकों से प्रतिपादन को नहीं तोड़ते)।

अन्य लाभ एक ऑक्ट्री हैं जो गोडोट एक की तुलना में 10 से 20 गुना तेज है, और प्रतिपादन के कुछ प्रवाह में सुधार, जैसे कि गहराई-प्रीपास और सामान्य-पास रेंडर सूची दोनों को एक साथ रिकॉर्ड करना, बजाय सूची 2 को पुनरावृत्त करना समय, और एक महत्वपूर्ण परिवर्तन कैसे प्रकाश-> जाल कनेक्शन काम करता है (कोई लिंक्ड सूची नहीं!)

@ vblanco20-1 क्या सी ++ 03 पर रहते हुए गहराई प्रीपास को अनुकूलित करना संभव होगा?

@Calinou गहराई से

@ vblanco20-1 ईमानदारी से, मैं उत्पादन में हमारे खेल के आधार के रूप में आपके कांटे का उपयोग करने पर भी विचार कर रहा हूं।

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

गोडोट को प्रोफाइल करने के लिए आप किन टूल्स का उपयोग कर रहे हैं? क्या आपको इन नमूनों को उत्पन्न करने के लिए Profiler.Begin और Profiler.End झंडे को गोडोट स्रोत में जोड़ने की आवश्यकता है?

गोडोट को प्रोफाइल करने के लिए आप किन टूल्स का उपयोग कर रहे हैं? क्या आपको इन नमूनों को उत्पन्न करने के लिए Profiler.Begin और Profiler.End झंडे को गोडोट स्रोत में जोड़ने की आवश्यकता है?

ट्रेसी प्रोफाइलर का उपयोग करते हुए, इसमें विभिन्न प्रकार के स्कोप प्रोफाइल मार्क हैं, जिनका मैं यहां उपयोग करता हूं। उदाहरण के लिए ZoneScopedNC("Fill List", 0x123abc) उस नाम के साथ एक प्रोफ़ाइल चिह्न और आपके इच्छित हेक्स रंग जोड़ता है।

@ vblanco20-1 - क्या हम इनमें से कुछ प्रदर्शन सुधारों को गोडोट मुख्य शाखा में लाते हुए देखेंगे?

@ vblanco20-1 - क्या हम इनमें से कुछ प्रदर्शन सुधारों को गोडोट मुख्य शाखा में लाते हुए देखेंगे?

हो सकता है कि जब C++ 11 समर्थित हो। लेकिन वल्कन होने से पहले रेड्यूज वास्तव में रेंडरर पर अधिक काम नहीं करना चाहता है, इसलिए ऐसा कभी नहीं हो सकता है। अनुकूलन कार्य के कुछ निष्कर्ष 4.0 रेंडरर के लिए उपयोगी हो सकते हैं।

@ vblanco20-1 शाखा के लिए संकलक और पर्यावरण विवरण साझा करने का मन, मुझे लगता है कि मैं इसका अधिकांश पता लगा सकता हूं, लेकिन अगर मुझे नहीं करना है तो मुद्दों को समझने में समय बर्बाद न करें।

क्या हम एएबीबी परिवर्तन को गोडोट मुख्य में बिना अधिक लागत के नहीं जोड़ सकते हैं?

@ vblanco20-1 शाखा के लिए संकलक और पर्यावरण विवरण साझा करने का मन, मुझे लगता है कि मैं इसका अधिकांश पता लगा सकता हूं, लेकिन अगर मुझे नहीं करना है तो मुद्दों को समझने में समय बर्बाद न करें।

क्या हम एएबीबी परिवर्तन को गोडोट मुख्य में बिना अधिक लागत के नहीं जोड़ सकते हैं?

@swarnimarun विजुअल स्टूडियो 17 या 19, बाद के अपडेट में से एक, ठीक काम करता है। (खिड़कियाँ)
cpp17 ध्वज जोड़ने के लिए स्कैन स्क्रिप्ट को संशोधित किया गया। साथ ही, लॉन्चिंग एडिटर अभी टूटा हुआ है। मैं यह देखने पर काम कर रहा हूं कि क्या मैं इसे पुनर्स्थापित कर सकता हूं।

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

@ vblanco20-1 क्या आपके पास पैट्रियन है? मैं प्रदर्शन पर केंद्रित एक कांटा की ओर कुछ पैसे डालूंगा और यह खुद को प्राचीन सी ++ तक सीमित नहीं रखता है और शायद मैं अकेला नहीं हूं। मैं 3डी परियोजनाओं के लिए गोडोट के साथ खेलना चाहता हूं, लेकिन मैं उम्मीद खो रहा हूं कि यह एक विशाल सबूत के बिना व्यवहार्य हो जाएगा जो एक अवधारणा है जो कोर टीम के प्रदर्शन और उपयोगिता के लिए आपके दृष्टिकोण को साबित करती है।

@mixedCase मुझे गोडोट के किसी भी प्रकार के कांटे का समर्थन करने में बेहद संकोच होगा। फोर्किंग और विखंडन अक्सर ओपन सोर्स प्रोजेक्ट्स की मौत है।

बेहतर परिदृश्य, और अधिक संभावना है कि अब यह प्रदर्शित किया गया है कि नया सी ++ महत्वपूर्ण अनुकूलन के लिए अनुमति देता है, गोडोट के लिए आधिकारिक तौर पर सी ++ के नए संस्करण में अपग्रेड करना है। मैं उम्मीद करता हूं कि यह गोडोट 4.0 में होगा, 3.2 में टूटने के जोखिम को कम करने के लिए, और समय में नई सी ++ सुविधाओं का उपयोग करने के लिए वल्कन को गोडोट 4.0 में जोड़ा जा रहा है। मुझे यह भी उम्मीद नहीं है कि GLES 3 रेंडरर में कोई महत्वपूर्ण बदलाव किया जाएगा, क्योंकि reduz इसे हटाना चाहता है।

(लेकिन मैं गोडोट देवों के लिए नहीं बोलता, यह सिर्फ मेरी अटकलें हैं)

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

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

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

यह अनुकूलन के बारे में काम कर रहे लेखों की एक श्रृंखला से एक टुकड़ा है, ठीक डेटा संरचना उपयोग के बारे में।

गोडोट एसटीएल कंटेनरों और उसके सी++03 पर प्रतिबंध लगाता है। इसका मतलब है कि इसके कंटेनरों में मूव ऑपरेटर नहीं होते हैं, और इसके कंटेनर स्वयं एसटीएल कंटेनरों से भी बदतर होते हैं। यहां मेरे पास गोडोट डेटा संरचनाओं और उनके साथ समस्याओं का एक सिंहावलोकन है।

प्रीलोकेटेड सी ++ सरणी। पूरे इंजन के आसपास बहुत आम है। इसका आकार कुछ कॉन्फ़िगरेशन विकल्प द्वारा निर्धारित किया जाता है। यह रेंडरर में बहुत आम है, और एक उचित गतिशील सरणी वर्ग यहां बहुत अच्छा काम करेगा।
दुरुपयोग का उदाहरण: https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L442
यह सरणियाँ बिना किसी अच्छे कारण के स्मृति को बर्बाद कर रही हैं, एक गतिशील सरणी का उपयोग करना यहाँ एक बेहतर विकल्प होगा क्योंकि यह उन्हें केवल उसी आकार का बना देगा जिसकी उन्हें आवश्यकता है, बजाय एक संकलन स्थिरांक द्वारा अधिकतम आकार के। MAX_INSTANCE_CULL का उपयोग करने वाले प्रत्येक इंस्टेंस* सरणियाँ आधा मेगाबाइट मेमोरी का उपयोग कर रही हैं

वेक्टर (वेक्टर। एच) एक एसटीडी :: वेक्टर गतिशील सरणी समकक्ष, लेकिन एक गहरी दोष के साथ।
वेक्टर को कॉपी-ऑन-राइट कार्यान्वयन के साथ परमाणु रूप से पुनर्गणना किया जाता है। कब आप करेंगे

वेक्टर ए = बिल्ड_वेक्टर ();
वेक्टर बी = ए;

रेफ़काउंट 2 पर जाएगा। बी और ए अब स्मृति में एक ही स्थान पर इंगित करते हैं, और एक बार संपादन किए जाने के बाद सरणी की प्रतिलिपि बनायेगा। यदि आप अब वेक्टर A या B को संशोधित करते हैं, तो यह एक वेक्टर कॉपी को ट्रिगर करेगा।

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

पूलवेक्टर (पूल_वेक्टर.एच)। कमोबेश एक वेक्टर के समान, लेकिन इसके बजाय एक पूल के रूप में। इसमें वेक्टर के समान ही नुकसान हैं, बिना किसी कारण के कॉपी ऑन राइट और स्वचालित डाउनसाइज़िंग।

सूची ( list.h ) एक एसटीडी :: सूची समकक्ष। सूची में 2 पॉइंटर्स (पहला और आखिरी) + एक एलिमेंट काउंट वेरिएबल है। सूची में प्रत्येक नोड डबल लिंक्ड है, साथ ही सूची कंटेनर के लिए एक अतिरिक्त पॉइंटर भी है। सूची के प्रत्येक नोड के लिए मेमोरी ओवरहेड 24 बाइट्स है। वेक्टर सामान्य रूप से बहुत अच्छा नहीं होने के कारण गोडोट में इसका अत्यधिक उपयोग किया जाता है। पूरे इंजन पर अत्यधिक दुरुपयोग किया गया।

बड़े दुरुपयोग के उदाहरण:
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L129
इसकी सूची होने का कोई कारण नहीं, एक वेक्टर होना चाहिए
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L242
इनमें से हर एक मामला गलत है। फिर से, यह वेक्टर या समान होना चाहिए। यह वास्तव में प्रदर्शन के मुद्दों का कारण बन सकता है।
कुलिंग के लिए उपयोग किए जाने वाले ऑक्ट्री में सूची का उपयोग करना सबसे बड़ी गलती है। मैं इस सूत्र में गोडोट ऑक्ट्री के बारे में पहले ही विस्तार से बता चुका हूँ।

SelfList(self_list.h) एक घुसपैठ सूची, boost::intrusive_list के समान। यह हमेशा 32 बाइट्स ओवरहेड प्रति नोड स्टोर करता है क्योंकि यह स्वयं को भी इंगित करता है। पूरे इंजन पर अत्यधिक दुरुपयोग किया गया।
उदाहरण:
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L159
यह विशेष रूप से खराब है। पूरे इंजन में सबसे खराब में से एक। यह बिना किसी कारण के इंजन में हर एक रेंडर करने योग्य वस्तु में मोटापा के 8 संकेत जोड़ रहा है। इसके लिए सूची बनाने की कोई आवश्यकता नहीं है। यह, फिर से, एक स्लॉटमैप या एक वेक्टर हो सकता है, और यही मैंने इसे बदल दिया है।

नक्शा(map.h) एक लाल-काले पेड़। इसके सभी उपयोगों में हैशमैप के रूप में दुरुपयोग किया गया। उपयोग के आधार पर इंजन से OAHashmap या Hashmap के पक्ष में हटा दिया जाना चाहिए।
मैंने देखा कि मानचित्र का हर उपयोग गलत था। मुझे मानचित्र का एक उदाहरण नहीं मिल रहा है जिसका उपयोग किया जा रहा है जहां यह समझ में आता है।

हैशमैप (hash_map.h) मोटे तौर पर std::unordered_map के बराबर, लिंक्ड लिस्ट बकेट पर आधारित एक बंद

OAHashMap (oa_hash_map.h) नया लिखा हुआ तेज़ ओपन-

CommandQueueMT(command_queue_mt.h) कमांड कतार का उपयोग विभिन्न सर्वरों से संचार करने के लिए किया जाता है, जैसे कि विज़ुअल सर्वर। यह आवंटक पूल के रूप में कार्य करने के लिए हार्डकोडेड 250 kb सरणी के द्वारा काम करता है, और वर्चुअल कॉल () और पोस्ट () फ़ंक्शन के साथ प्रत्येक कमांड को ऑब्जेक्ट के रूप में आवंटित करता है। यह पुश/पॉप संचालन की सुरक्षा के लिए म्यूटेक्स का उपयोग करता है। म्यूटेक्स को लॉक करना बहुत महंगा है, मैं इसके बजाय मूडीकैमल कतार का उपयोग करने की सलाह देता हूं, जो तेजी से परिमाण का क्रम होना चाहिए। यह उन खेलों के लिए एक अड़चन बनने की संभावना है जो दृश्य सर्वर के साथ बहुत सारे संचालन करते हैं, जैसे बहुत सारी चलती वस्तुएं।

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

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

4.0 में वल्कन कार्यान्वयन पर पाई गई समस्याएं। मुझे पता है कि इसका काम प्रगति पर है, इसलिए इसे ठीक करने के लिए अभी भी समय है।

रेंडर एपीआई में मानचित्र का उपयोग। https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L350
जैसा कि मैंने टिप्पणी की, मानचित्र का कोई अच्छा उपयोग नहीं है और इसके अस्तित्व का कोई कारण नहीं है। उन मामलों में सिर्फ हैशपैप होना चाहिए।
लिंक्ड सूची केवल सरणियों या समान के बजाय अति प्रयोग।
https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L680
सौभाग्य से यह संभवतः तेज़ लूप पर नहीं है, लेकिन यह अभी भी सूची का उपयोग करने का एक उदाहरण है जहां इसका उपयोग नहीं किया जाना चाहिए

रेंडर एपीआई में पूलवेक्टर और वेक्टर का उपयोग करना। https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L747
रेंडर एपीआई एब्स्ट्रैक्शन के हिस्से के रूप में उन 2 त्रुटिपूर्ण संरचनाओं का उपयोग करने का कोई वास्तविक अच्छा कारण नहीं है। उनका उपयोग करके, उपयोगकर्ताओं को किसी अन्य डेटा संरचना का उपयोग करने में सक्षम होने के बजाय, उन 2 को उनकी कमियों के साथ उपयोग करने के लिए मजबूर किया जाता है। एक सिफारिश उन मामलों पर सूचक + आकार का उपयोग करना है, और अभी भी फ़ंक्शन का एक संस्करण है जो वेक्टर लेता है यदि आवश्यक हो।

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

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

यदि आप इस विषय के बारे में अधिक जानने में रुचि रखते हैं, तो मुझे पता है कि सबसे अच्छी बात सीपीपीकॉन से है। https://www.youtube.com/watch?v=fHNmRkzxHWs
अन्य महान वार्ता यह है: https://www.youtube.com/watch?v=-8UZhDjgeZU , जहां यह कुछ डेटा संरचनाओं की व्याख्या करता है जैसे कि स्लॉटमैप जो गोडोट की जरूरतों के लिए सुपर उपयोगी होगा।

गोडोट के पास प्रदर्शन की एक बड़ी समस्या है... आप गोडोट टीम के लिए एक अच्छे अतिरिक्त होंगे, कृपया इस पर विचार करें!

मैं इस धागे को बंद कर रहा हूं, क्योंकि मुझे नहीं लगता कि यह योगदान करने या मदद करने का सही तरीका है।

@ vblanco20-1 फिर, मैं वास्तव में सराहना करता हूं कि आपके अच्छे इरादे हैं, लेकिन आप इंजन के किसी भी आंतरिक कामकाज या इसके पीछे के दर्शन को नहीं समझते हैं। आपकी अधिकांश टिप्पणियां उन चीजों के प्रति हैं जिन्हें आप वास्तव में नहीं समझते हैं कि उनका उपयोग कैसे किया जाता है, वे प्रदर्शन के लिए कितने महत्वपूर्ण हैं, या उनकी प्राथमिकताएं सामान्य रूप से क्या हैं।

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

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

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

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

चूंकि कई तकनीकी विवरण के बारे में उत्सुक हो सकते हैं:

• सभी स्थानिक अनुक्रमण कोड (जिसे vblanco फिर से लिखा गया है) को कई थ्रेड्स के साथ एक रेखीय एल्गोरिथ्म द्वारा प्रतिस्थापित किया जाएगा, जो कि पदानुक्रमित रोड़ा कलिंग के लिए एक ऑक्ट्री और ओवरलैपिंग चेक के लिए एक SAP के साथ संयुक्त है, जो कि सबसे अच्छा ऑल राउंडर एल्गोरिदम है जो अच्छा वारंट करता है किसी भी तरह के खेल पर प्रदर्शन। इन संरचनाओं के लिए आवंटन नए RID_Allocator के समान ही होगा, जो कि O(1) है। मैंने पहले @ vblanco20-1 के साथ इस पर चर्चा की और समझाया कि उनका दृष्टिकोण सभी प्रकार के खेलों के लिए अच्छा नहीं है, क्योंकि इसके लिए उपयोगकर्ता को एक निश्चित डिग्री की विशेषज्ञता की आवश्यकता होती है, जो आमतौर पर विशिष्ट गोडोट उपयोगकर्ता के पास होने की उम्मीद नहीं है। यह रोड़ा कलिंग जोड़ने के लिए भी एक अच्छा तरीका नहीं था।
• जब सूचियों का उपयोग किया जा सकता है तो मैं सरणियों का उपयोग नहीं करूँगा क्योंकि सूचियाँ छोटे अस्थायी आवंटन करती हैं जिनमें फ़्रैजेंटेशन का शून्य जोखिम होता है। कुछ मामलों में, मैं एक खंडित सरणी आवंटित करना पसंद करता हूं (पृष्ठों के साथ संरेखित, इसलिए वे 0 विखंडन का कारण बनते हैं) जो हमेशा बढ़ते हैं और कभी सिकुड़ते नहीं हैं (जैसे RID_Allocator या 2D इंजन Vulkan शाखा में नया CanvasItem, जो अब आपको आइटम को फिर से निकालने की अनुमति देता है बहुत सारे आदेशों के साथ बहुत कुशलता से), लेकिन इसके लिए एक प्रदर्शन कारण होना चाहिए। जब गोडोट में सूचियों का उपयोग किया जाता है तो ऐसा इसलिए होता है क्योंकि प्रदर्शन पर छोटे आवंटन को प्राथमिकता दी जाती है (और वास्तव में वे दूसरों के पढ़ने के लिए कोड के इरादे को और अधिक स्पष्ट करते हैं)।
• पूलवेक्टर लगातार मेमोरी पेजों के साथ बहुत बड़े आवंटन के लिए अभिप्रेत है। गोडोट 2.1 तक यह एक प्रीआलोकेटेड मेमोरी पूल का उपयोग करता था, लेकिन इसे 3.x में हटा दिया गया था और अभी वर्तमान व्यवहार गलत है। 4.0 के लिए इसे वर्चुअल मेमोरी से बदल दिया जाएगा, यह करने के लिए चीजों की सूची में है।
• गोडोट के वेक्टर<> की तुलना std::vector से करना व्यर्थ है क्योंकि उनके पास अलग-अलग उपयोग के मामले हैं। हम इसका उपयोग ज्यादातर डेटा पास करने के लिए करते हैं और हम इसे तेजी से एक्सेस के लिए लॉक करते हैं (ptr() या ptrw() विधियों के माध्यम से)। यदि हम std::vector का उपयोग करते हैं, तो अनावश्यक नकल के कारण गोडोट बहुत धीमा होगा। हम कई अलग-अलग उपयोगों के लिए कॉपी ऑन राइट मैकेनिक का भी भरपूर लाभ उठाते हैं।
• मानचित्र<> बड़ी मात्रा में तत्वों के लिए बस सरल और मित्रवत है और विखंडन पैदा करने वाले जल्दबाजी में बढ़ने/गिरने के बारे में चिंता करने की आवश्यकता नहीं है। जब प्रदर्शन की आवश्यकता होती है, तो इसके बजाय हैश मैप का उपयोग किया जाता है (हालांकि यह सच है, शायद OAHashMap का अधिक उपयोग करना चाहिए, लेकिन यह बहुत नया है और ऐसा करने का समय कभी नहीं था)। एक सामान्य दर्शन के रूप में, जब प्रदर्शन प्राथमिकता नहीं होता है, तो छोटे आवंटन हमेशा बड़े लोगों पर पसंद किए जाते हैं क्योंकि आपके ऑपरेटिंग सिस्टम से मेमोरी एलोकेटर के लिए उन्हें रखने के लिए छोटे छेद ढूंढना आसान होता है (जो कि इसे करने के लिए डिज़ाइन किया गया है) , प्रभावी ढंग से कम ढेर खपत।

फिर से, आप दुष्ट होने और शिकायत करने के बजाय जब चाहें योजनाओं और डिजाइन के बारे में पूछ सकते हैं, यह परियोजना की मदद करने का सबसे अच्छा तरीका नहीं है।

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

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

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

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

हाय रेडुज,
जबकि मैं ज्यादातर देखता हूं कि आपके अंक मान्य हैं, मैं उन दो पर टिप्पणी करना चाहता हूं जिन पर मैं असहमत हूं:

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

मुझे अत्यधिक संदेह है कि एक लिंक्ड सूची में घातीय वृद्धि के साथ गतिशील सरणी की तुलना में बेहतर समग्र प्रदर्शन होगा, इसे गति या स्मृति दक्षता दें। उत्तरार्द्ध को वास्तव में उपयोग किए जाने वाले स्थान से दोगुने से अधिक स्थान पर कब्जा करने की गारंटी है, जबकि List<some pointer> तीन गुना अधिक भंडारण (वास्तविक सामग्री, अगला और पिछला सूचक) का उपयोग करता है। एक खंडित सरणी के लिए, चीजें और भी बेहतर दिखती हैं।

जब ठीक से लपेटा जाता है (और जितना मैंने पहले से ही गोडोट कोड के बारे में देखा है, वे हैं), वे प्रोग्रामर के लिए काफी समान दिखते हैं, इसलिए मुझे समझ में नहीं आता कि "वे [सूचियां" के साथ आपका क्या मतलब है ] कोड के इरादे को और स्पष्ट करें"।

IMHO, सूचियाँ बिल्कुल दो स्थितियों में मान्य हैं:

• आपको कंटेनर के बीच में तत्वों को बार-बार मिटाना/सम्मिलित करना होगा
• या आपको तत्वों के सम्मिलन/हटाने के लिए निरंतर-समय (और न केवल निरंतर-समय परिशोधित) की आवश्यकता है। यानी, वास्तविक समय के संदर्भों में जहां स्मृति का समय लेने वाला आवंटन संभव नहीं है, वे ठीक हैं।

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

libc-आवंटक आमतौर पर काफी स्मार्ट होते हैं, और चूंकि OAHashMap (या एक std::unordered_map) समय-समय पर अपने भंडारण को पुन: आवंटित करता है (परिशोधन निरंतर-समय), आवंटनकर्ता आमतौर पर अपने मेमोरी ब्लॉक को कॉम्पैक्ट रखने का प्रबंधन करता है। मेरा दृढ़ विश्वास है कि OAHashMap मैप जैसे सादे बाइनरी ट्री मैप की तुलना में प्रभावी रूप से अधिक ढेर का उपभोग नहीं करता है। इसके बजाय, मुझे पूरा यकीन है कि मानचित्र के प्रत्येक तत्व में विशाल पॉइंटर ओवरहेड वास्तव में OAHashmap (या std :: unordered_map) के किसी भी ढेर विखंडन की तुलना में अधिक मेमोरी का उपभोग करता है।

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

लेकिन @reduz , आप इन सभी परिवर्तनों को बेंचमार्क करने के बारे में क्या सोचते हैं जो @ vblanco20-1 ने सुझाया था (शायद अब भी, 3.1 में)। यदि @ vblanco20-1 (या कोई और) इस तरह के बेंचमार्किंग सूट को लिखने के लिए और गोडोट 3.1 के प्रदर्शन का मूल्यांकन करने के लिए तैयार है (दोनों गति के संदर्भ में और "विखंडन पर विचार करके ढेर खपत") vblanco के परिवर्तनों के खिलाफ? यह वास्तविक 4.0 परिवर्तनों के लिए मूल्यवान संकेत दे सकता है।

मुझे लगता है कि इस तरह की कार्यप्रणाली आपके "[चीजों] को जल्दी करने के बजाय ठीक से किया जाता है" अच्छी तरह से फिट बैठता है।

@ vblanco20-1: वास्तव में, मैं आपके काम की सराहना करता हूं। क्या आप ऐसे बेंचमार्क बनाने के लिए प्रेरित होंगे, ताकि हम वास्तव में माप सकें कि क्या आपके परिवर्तन वास्तविक प्रदर्शन सुधार हैं? मुझे बहुत दिलचस्पी होगी।

@Windfisch मेरा सुझाव है कि आप उपरोक्त मेरी पोस्ट को दोबारा पढ़ें, क्योंकि आपने कुछ चीजों को गलत तरीके से पढ़ा है या गलत समझा है। मैं उन्हें आपके लिए स्पष्ट कर दूंगा।

• सूचियों का उपयोग आपके द्वारा वर्णित उपयोग के मामले के लिए बिल्कुल किया जाता
• मैंने कभी भी @vblanco20-1 के काम के प्रदर्शन के बारे में तर्क नहीं दिया और मैं स्पष्ट रूप से इसकी परवाह नहीं करता (इसलिए आपको बेंचमार्क करने में उसे समय बर्बाद करने की आवश्यकता नहीं है)। उनके काम का विलय न करने का कारण यह है कि 1) उनके द्वारा उपयोग किए जाने वाले एल्गोरिदम को खेल में वस्तुओं के औसत आकार के आधार पर मैनुअल ट्विकिंग की आवश्यकता होती है, कुछ ऐसा जो अधिकांश गोडोट उपयोगकर्ताओं को करने की आवश्यकता होगी। मैं एल्गोरिदम का पक्ष लेता हूं जो थोड़ा धीमा हो सकता है लेकिन सुधार की आवश्यकता के बिना बेहतर पैमाने पर हो सकता है। 2) वह जिस एल्गोरिथम का उपयोग करता है वह रोड़ा मारने के लिए अच्छा नहीं है (सरल ऑक्ट्री श्रेणीबद्ध प्रकृति के कारण बेहतर है)। 3) वह जिस एल्गोरिथम का उपयोग करता है वह युग्मन के लिए अच्छा नहीं है (एसएपी अक्सर बेहतर होता है)। 4) वह सी ++ 17 और पुस्तकालयों का उपयोग करता है जिनकी मुझे समर्थन करने में कोई दिलचस्पी नहीं है, या लैम्ब्डा जो मुझे लगता है कि अनावश्यक हैं 5) मैं पहले से ही 4.0 के लिए इसे अनुकूलित करने पर काम कर रहा हूं, और 3.x शाखा में प्राथमिकता के रूप में स्थिरता है और हम 3.2 को जल्द से जल्द रिलीज करने का इरादा है, इसलिए इसे संशोधित नहीं किया जाएगा या वहां काम नहीं किया जाएगा। मौजूदा कोड धीमा हो सकता है, लेकिन यह बहुत स्थिर और परीक्षण किया गया है। अगर यह मर्ज हो जाता है तो बग रिपोर्ट, रिग्रेशन आदि होते हैं। किसी के पास इस पर काम करने या विक्टर की मदद करने का समय नहीं होगा क्योंकि हम पहले से ही 4.0 शाखा में व्यस्त हैं। यह सब ऊपर समझाया गया है, इसलिए मेरा सुझाव है कि आप पोस्ट को दोबारा पढ़ें।

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

गोडोट खुला स्रोत है और उसका कांटा भी। हम सभी खुले हैं और यहां साझा कर रहे हैं, अगर आपको इसकी आवश्यकता है तो आपको उनके काम का उपयोग करने से कोई नहीं रोक सकता है।

चूंकि वह अनुकूलन जीडीस्क्रिप्ट, रेंडर या "हकलाना" समस्याओं को प्रभावित नहीं करता है, और ऐसी चीजें हैं जो लोग शिकायत करते हैं (मुझे शामिल हैं), शायद इस बात को पूरा करने के साथ कि अनुकूलन लोग खुश होंगे (मुझे शामिल हैं) ... की जरूरत नहीं है लुआ जित वेग ...
"कॉपी ऑन राइट" में काम करता है मेरा एक प्लगइन में एक बहुत बड़ा प्रदर्शन अनुकूलन था (एक स्क्रिप्ट पार्स में 25 सेकंड से 7000 लाइनों की एक स्क्रिप्ट में केवल 1 सेकंड तक) ... मुझे लगता है कि इस तरह के अनुकूलन हैं कि हम जरूरत है, gdscript में, हकलाने की समस्या को प्रस्तुत करने और पूरा करने में... बस इतना ही।

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

यह अच्छा है कि स्थानिक अनुक्रमण कोड प्लग करने योग्य होगा, क्योंकि वास्तव में वह बहुत अलग-अलग पैमानों पर बहुत सारी वस्तुओं को संभालने से पहले मेरे पैरों पर गिर गया था। 4.0 के लिए तत्पर हैं।

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

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

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

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

मुख्य विचार यह है कि केवल ऑक्ट्री पर लीफ ऑब्जेक्ट्स को पकड़ते हैं, और उन ऑब्जेक्ट्स को आकार 64 (संकलन समय आकार, अलग हो सकता है) की एक सरणी पर रखा जाता है। एक ऑक्ट्री पत्ता केवल तभी विभाजित होगा जब यह 65 तत्वों में "ओवरफ्लो" हो जाएगा। जब आप ऑब्जेक्ट्स को हटाते हैं, यदि पैरेंट नोड का प्रत्येक लीफ 64 आकार के ऐरे में फिट होता है, तो हम लीफ्स को वापस उनके पैरेंट नोड में मर्ज कर देते हैं, जो लीफ बन जाता है।

ऐसा करने से, हम नोड्स पर समय परीक्षण को कम कर सकते हैं, क्योंकि ऑक्ट्री अंत में बहुत गहरा नहीं होगा।

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

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

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

रेंडर एपीआई पर वेक्टर और अन्य लोगों के लिए मेरी चिंताओं पर, यह समस्या बताती है कि मैं किस बारे में चिंता कर रहा था। https://github.com/godotengine/godot/issues/24731

पुस्तकालय और सी ++ 17 कांटे के सामान पर .. यह अनावश्यक है। कांटा बहुत सारे पुस्तकालयों का उपयोग करता है क्योंकि मुझे उनमें से कुछ हिस्सों की आवश्यकता थी। केवल एक चीज जिसकी वास्तव में जरूरत है, और मुझे लगता है कि गोडोट की जरूरत है, एक उद्योग-शक्ति समानांतर कतार है, मैंने इसके लिए मूडीकैमल कतार का उपयोग किया।

लैम्ब्डा पर, उनका उपयोग मुख्य रूप से कुलिंग के लिए होता है, और इसका उपयोग महत्वपूर्ण मात्रा में मेमोरी को बचाने के लिए किया जाता है, क्योंकि आपको केवल उन वस्तुओं को सहेजने की आवश्यकता होती है जो आपके चेक को आउटपुट सरणी में पास करते हैं। विकल्प इटरेटर ऑब्जेक्ट्स करना है (जो कि अवास्तविक इंजन उनके ऑक्ट्री के साथ करता है), लेकिन यह खराब कोड और लिखने में बहुत कठिन होता है।

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

@ vblanco20-1 यह बहुत अच्छा लगता है, और जिस तरह से आप ऑक्ट्री कार्यों का उल्लेख करते हैं, वह बहुत मायने रखता है। मैं ईमानदारी से समानांतर कतार को लागू करने में कोई फर्क नहीं पड़ता (बाहरी निर्भरता की आवश्यकता के लिए काफी आसान लगता है, और इसे ठीक से करने के लिए सी ++ 11 की आवश्यकता है, इसलिए अनुमान लगाएं कि यह केवल वल्कन शाखा पर होगा)। यदि आपने यह किया है, तो मैं निश्चित रूप से इसे देखना चाहता हूं, इसलिए मैं इसे वल्कन शाखा में इंडेक्सर पुनर्लेखन के आधार के रूप में उपयोग कर सकता हूं (मैं वहां अधिकतर सामान फिर से लिख रहा हूं, इसलिए इसे फिर से लिखना होगा वैसे भी ) बेशक यदि आप कार्यान्वयन में सहायता करना चाहते हैं (शायद जब नए एपीआई के साथ और चीजें हों), तो यह बहुत स्वागत है।

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

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

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

प्रदर्शन की जरूरत किसे है? :ट्रॉल फ़ेस:

परफॉर्मेंस और सोर्स मॉडल ही मुझे गोडोट से जोड़े रखता है।

संपादित करें: क्षमा करें, शायद मैं कुछ ऑफटॉपिक हूं लेकिन मैं ओपन सोर्स के लाभों को स्पष्ट करना चाहता था।

@mixedCase मुझे गोडोट के किसी भी प्रकार के कांटे का समर्थन करने में बेहद संकोच होगा। फोर्किंग और विखंडन अक्सर ओपन सोर्स प्रोजेक्ट्स की मौत है।

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

वैसे भी मूल डेवलपर्स सिर्फ कांटा से सुधार मर्ज कर सकते हैं। वे इसे हमेशा करने के लिए स्वतंत्र हैं। यह ओपन सोर्स वर्ल्ड की एक और प्रकृति है।

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