2009-03-13 16 views
15

मैं भौतिकी सिमुलेशन सॉफ़्टवेयर लिखने के विचार से टकरा रहा हूं जिसमें प्रत्येक भौतिक तत्व को अपने धागे में अनुकरण किया जाएगा।मैं कैसे सुनिश्चित कर सकता हूं कि एन थ्रेड लगभग उसी गति से चलते हैं?

इस दृष्टिकोण के कई फायदे होंगे। असली दुनिया कैसे काम करती है यह अवधारणात्मक रूप से बहुत करीब होगी। सिस्टम को कई मशीनों में स्केल करना बहुत आसान होगा।

हालांकि, इसके लिए काम करने के लिए मुझे यह सुनिश्चित करने की ज़रूरत है कि सभी धागे एक ही गति से चलें, बल्कि 'समान' की उदार व्याख्या के साथ। एक दूसरे के 1% के भीतर कहो।

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

किसी भी सुझाव की अत्यधिक सराहना की जाएगी।

अद्यतन 2009-03-16

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

+0

भौतिकी सिमुलेशन के साथ मेरा अनुभव यह है कि यह सिमुलेशन में त्रुटियों को जमा करने की अनुमति देगा, वास्तव में आपको प्रदर्शन में कोई लाभ नहीं पहुंचाएगा। यदि आप मल्टीकोर प्रोसेसर का उपयोग करना चाहते हैं तो प्रत्येक 'टिक' प्रत्येक तत्व के लिए थ्रेड के साथ 1-चरणीय गणना शुरू करता है। – DJClayworth

उत्तर

12

आपको किसी प्रकार का सिंक्रनाइज़ेशन की आवश्यकता होगी।

एक तुल्यकालन सहायता है कि सभी के लिए धागे का एक सेट की अनुमति देता है प्रत्येक एक आम बाधा बिंदु तक पहुँचने के अन्य के लिए इंतजार: CyclicBarrier वर्ग आपको क्या चाहिए है। साइक्लिक बार्सियां ​​ में धागे की एक निश्चित आकार वाली पार्टी शामिल है जो कभी-कभी एक दूसरे के लिए प्रतीक्षा करनी चाहिए। बाधा को चक्रीय कहा जाता है क्योंकि इसे के बाद पुनः उपयोग किया जा सकता है प्रतीक्षा थ्रेड जारी किए जाते हैं।

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

1

मैं थ्रेडिंग विशेषज्ञ नहीं हूं, लेकिन धागे का पूरा बिंदु नहीं है कि वे एक दूसरे से स्वतंत्र हैं - और गैर-निर्धारक?

13

आप समन्वय के बिना वास्तव में ऐसा नहीं कर सकते हैं। क्या होगा यदि एक तत्व को दूसरे की तुलना में सस्ती गणना की आवश्यकता हो (संभावित रूप से गैर-स्पष्ट तरीके से)?

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

साझा डेटा विवाद के कारण बहुत अधिक ओवरहेड होने से बचने के लिए बस इतना ही ऐसा करें और मुझे लगता है कि यह उचित रूप से अच्छी तरह से काम कर सकता है।

0

इसे प्राप्त करने के लिए दो चीजें होनी चाहिए। आपको यह सुनिश्चित करना होगा कि आपके पास प्रति सीपीयू कोर के बराबर संख्या है, और आपको किसी प्रकार का सिंक्रनाइज़ेशन चाहिए।

यह सिंक तुलनात्मक प्रदर्शन करते समय प्रत्येक थ्रेड के लिए "चक्र-पूर्ण" चर की जांच करने की तरह सरल हो सकता है, लेकिन आप इससे बच नहीं सकते हैं।

6

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

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

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

1

मुझे लगता है कि आप अपने प्रश्न में एक मौलिक गलत धारणा है कि आप कहां कहना है:

यह धारणात्मक बहुत कैसे वास्तविक दुनिया काम करता है

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

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

+0

यदि जटिल प्रक्रियाओं को अधिक संसाधनों की आवश्यकता नहीं है, तो आप गर्मी/एन्ट्रॉपी समकक्ष की व्याख्या कैसे करते हैं? –

3

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

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

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

चेतावनी: मैं किसी भी बड़े पैमाने पर सिमुलेशन सॉफ्टवेयर के साथ काम नहीं किया, बस कुछ शौकिया कोड।

4

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

अपने मामले में आप कई धागे बना सकते हैं, और प्रत्येक थ्रेड में इवेंट लूप डाल सकते हैं। एक 'मास्टर' धागा निष्पादन को अनुक्रमित कर सकता है और प्रत्येक कार्यकर्ता धागे को 'प्रक्रिया' घटना को जागने के लिए पोस्ट कर सकता है और इसे कुछ काम कर सकता है। इस तरह धागे तब तक सोएंगे जब तक कि आप उन्हें काम करने के लिए न कहें।

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

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

+0

सच नहीं है, एरलांग एक मशीन पर वास्तव में बहुत सी प्रक्रियाएं चला सकता है। –

1

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

2

यहां तक ​​कि सही सॉफ्टवेयर के साथ, हार्डवेयर आपको ऐसा करने से रोक देगा। हार्डवेयर धागे आमतौर पर उचित प्रदर्शन नहीं है। एक छोटी अवधि में, यदि आप धागे + -10% प्रदर्शन के भीतर चलते हैं तो आप भाग्यशाली हैं।

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

0

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

2

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

0

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

मैं सिमुलेशन के अलग-अलग चरणों की गणना करने के लिए उपयोग किए गए कुछ कार्यकर्ता धागे के साथ जाऊंगा।

3

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

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

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

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

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

नोट: इनमें से कोई भी विचार वास्तविक भौतिकी गणनाओं को ध्यान में नहीं लेता है। यह एर्लांग मजबूत पक्ष नहीं है और संभवतया आप चाहते हैं कि विशेषताओं के प्रकार के आधार पर सी पुस्तकालय में या जो भी आपकी कल्पना पर हमला कर सकता है।

नोट: मुझे ऐसा कोई भी मामला नहीं पता है जहां यह किया गया है (विशेष रूप से मेरे द्वारा नहीं), इसलिए मैं गारंटी नहीं दे सकता कि यह अच्छी सलाह है।

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

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