2009-02-21 9 views
22

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

गेम में कई धागे क्यों नहीं हैं? भौतिकी, ध्वनि, ग्राफिक्स, एआई आदि के लिए अलग धागे जैसे?

+2

समांतरता कठिन है। सिर्फ "वाह, यह मुश्किल है" -हार्ड लेकिन सैद्धांतिक रूप से, कई समस्याएं समानांतर नहीं हैं "-हार्ड। –

उत्तर

14

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

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

हालांकि यह, threadsafe कोड लिखने के रूप में अन्य उत्तर के कई संकेत मिलता है, मुझे लगता है कि चीजों को आप देख रहे हैं के लिए कुछ अन्य कारण हैं मुश्किल है:

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

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

23

मुझे आपके द्वारा खेले गए गेम के बारे में पता नहीं है, लेकिन अधिकांश गेम ध्वनि को अलग थ्रेड पर चलाते हैं। नेटवर्किंग कोड, कम से कम सॉकेट श्रोताओं को एक अलग धागे पर चलाते हैं।

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

0

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

1

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

x86 गेम प्रोग्रामर के लिए बहुत दयालु रहा है, क्योंकि हमें कम क्षमाशील हार्डवेयर प्लेटफार्मों की विधियों के बारे में सोचना नहीं है।

0

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

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

1

एकाधिक कोर के लिए प्रोग्रामिंग की तकनीकी चुनौतियों के अलावा, वाणिज्यिक गेम को पैसे कमाने के लिए कम अंत सिस्टम w/o एकाधिक कोरों पर अच्छी तरह से चलना पड़ता है।

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

यहां इंटेल से an interview with Orion Granatir का एक लिंक है जहां वह गेम डेवलपर्स को बहु-थ्रेडिंग का लाभ उठाने के बारे में बात कर रहा है।

1

तथ्य यह है कि यहां हर कोई सही ढंग से दावा कर रहा है कि बहुसंख्यक कठिन है बहुत दुखद है। हमें कंसूरेंसी सिस्टम को आसान बनाने की जरुरत है।

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

+1

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

+0

प्रतिमान शिफ्ट, फिर उपकरण;) – Pyrolistical

15

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

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

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

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

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

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

ठीक है, यह मेरी अपेक्षा से थोड़ा लंबा हो गया। मैं थ्रेडिंग या गेम्स विशेषज्ञ नहीं हूं, लेकिन मुझे आशा है कि मैंने कोई विशेष रूप से चमकदार त्रुटियां नहीं की हैं।अगर मैं मुझे यकीन है कि लोग मुझ को सही कर देंगे :)

+2

वास्तव में, यहां तक ​​कि एक कोर मशीन थ्रेड पर भी प्रदर्शन लाभ हो सकता है। कुछ मशीन स्विच मेमोरी स्टालों के कारण चल रहे थ्रेड को स्वैप कर देंगे। अगर मुझे सही याद है, तो इंटेल की हाइपर थ्रेडिंग कुछ समान होती है। विस्तृत उत्तर –

+0

+1 मैं यह भी निर्दिष्ट करता हूं कि थ्रेड का उपयोग करते समय आप वास्तव में अपने शेड्यूलिंग की निगरानी नहीं करते हैं। शेड्यूलिंग एल्गोरिदम ओएस द्वारा डिजाइन किए गए हैं, न कि गेम डेवलपर। इसलिए यदि आपको एक कठोर क्रम में कार्यों को संभालना है तो यह एक धागे में इसे कम से कम करना आसान है। –

+0

के लिए –

1

धागे मृत, बच्चे कर रहे हैं।

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

यह प्लेस्टेशन 3 और एक्सबॉक्स 360 परियोजनाओं पर कुछ हद तक दर्दनाक अहसास रहा है, और ऐसा लगता है कि अब भी ऐप्पल हिम तेंदुए में अपनी "क्रांतिकारी" Grand Central Dispatch प्रणाली के साथ बोर्ड पर कूद गया है।

धागे अपनी जगह है, लेकिन की भोली वादा "एक धागे में सब कुछ डाल दिया है और यह सभी रन तेजी से होगा" बस व्यवहार में काम नहीं करता।

+0

... थ्रेड्स आप जो बात कर रहे हैं उसका एक अभिन्न अंग हैं। यह सिर्फ अमूर्तता की एक अतिरिक्त परत के नीचे है। – colithium

संबंधित मुद्दे