प्रोग्राम जो दावा करते हैं कि वे "मल्टी-कोर" अनुकूल नहीं हैं


17

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

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

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


11
एक बड़ी संभावना यह है कि सिंक्रोनाइज़ेशन में शॉर्टकट लिए गए थे, जो सिंगल-प्रोसेसर / कोर सिस्टम के लिए काम करते हैं, लेकिन कई प्रोसेसर / कोर की सही संगति के साथ टूट जाते हैं।
बार्ट वैन इनगेन शेनौ

@BartvanIngenSchenau: यह सही है। आपको इसका विस्तार करना चाहिए और इसे उत्तर के रूप में पोस्ट करना चाहिए। मुझे लगता है कि अन्य सभी इस बिंदु से चूक गए।
केविन क्लाइन

1
मुझे लगता है कि @ बर्ट वास्तव में करीब है। हालांकि, s / काम / काम करने के लिए दिखाई देते हैं / और यह निशान के करीब होगा।
बेन वोइगट

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

जवाबों:


28

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

  • कोई साझा स्थिति नहीं, प्रत्येक फ़ंक्शन केवल पारित किए गए मापदंडों पर निर्भर करता है
  • भौतिक उपकरणों तक पहुँच नहीं (ग्राफिक कार्ड, हार्ड ड्राइव, आदि)

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

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

प्रभावी संगामिति से निपटने में बड़ी वास्तु चुनौतियां हैं

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

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

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

तल - रेखा:

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


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

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

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

35

बहुत सारे कार्यक्रम (विशेष रूप से खेल) स्वाभाविक रूप से संगामिति का उपयोग करते हैं,

नहीं, वास्तव में यह उल्टा है। अधिकांश एप्लिकेशन एक ही थ्रेडेड मानसिकता में लिखे गए हैं, और डेवलपर (एस) ने कभी भी संगामिति का समर्थन करने के लिए आवश्यक परिवर्तन नहीं किए हैं।

सी में, सी ++, और सी # आपको नए धागे और / या प्रक्रियाओं को शुरू करने के लिए स्पष्ट रूप से एप्लिकेशन को बताने की आवश्यकता है।

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

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

आमतौर पर, जब कोई एप्लिकेशन कहता है कि यह कई कोर का उपयोग नहीं कर सकता है, तो इसका मतलब है कि उनके पास डेटा हेरफेर की सुरक्षा के लिए सिंक्रनाइज़ेशन नहीं है।


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

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

और गेम इंजन (कोड कार्यान्वयन) को अपडेट किए बिना कुछ गेम नई सामग्री (ग्राफिक्स और गेमप्ले) पर भी पनपते हैं। इस प्रकार, खेल इंजन प्रौद्योगिकी में वर्षों पीछे रह सकता है।
rwong

6
@SnakeDoc: आपको हजारों ऑन-स्क्रीन मॉडल से निपटने के लिए संगामिति की आवश्यकता नहीं है। यह ऐसा नहीं है कि आपके खेल की हर वस्तु को इसे अनुकरण करने के लिए अपने स्वयं के धागे की आवश्यकता है; एक धागा हर टाइमस्टेप पर स्क्रीन पर हर चीज के अपडेट को संभाल सकता है।
user2357112

13

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

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


8

यह पूर्ण उत्तर नहीं है। यह एक सतर्क कहानी है।

एक दिन मैंने सोचा कि मैं अपने समवर्ती प्रोग्रामिंग पाठ्यक्रम में छात्रों को एक समानांतर क्विकर के रूप में दिखाऊंगा। Quicksort अच्छी तरह से समानांतर करना चाहिए, मैंने सोचा। मैंने दो धागों का इस्तेमाल किया। इसे मेरे सिंगल कोर कंप्यूटर पर चलाया। परिणाम थे:

  • एकल-थ्रेडेड संस्करण के लिए 14 सेकंड।
  • 2-थ्रेडेड संस्करण के लिए 15 सेकंड।

यह वही था जो मैं उम्मीद करता था।

फिर मैंने इसे एक नए, दोहरे कोर मशीन पर आज़माया।

  • एकल-थ्रेडेड संस्करण के लिए 11 सेकंड।
  • 2-थ्रेडेड संस्करण के लिए 20 सेकंड।

दो सूत्र ने शेष कार्यों की एक कतार साझा की। ऐसा लगता है कि कतार वस्तु के क्षेत्र एक कोर के कैश और दूसरे के बीच आगे-पीछे फेर दिए जा रहे थे।


2
आपने कितने सरणी तत्वों के साथ परीक्षण किया? शायद बहु-कोर प्रोग्रामिंग के बाद से मर्जसॉर्ट अधिक उपयुक्त होगा क्योंकि कैश-लाइन संघर्षों से बचने के लिए डेटा की नकल की आवश्यकता होगी?
6

2
@rwong 10,000,000 सरणी तत्व थे। निश्चित रूप से मर्जरोर्ट अच्छी तरह से समानांतर होगा। अगर मैंने मर्ज सॉर्ट का इस्तेमाल किया होता तो शायद मैं एक उपयोगी सबक नहीं सीखता।
थियोडोर नॉरवेल

1
@ArlaudPierre मैं किसी भी एल्गोरिथ्म को समानांतर बनाने पर विचार करूंगा। Quicksort दिलचस्प है क्योंकि आप इसके लिए बैग-ऑफ-टास्क दृष्टिकोण का उपयोग कर सकते हैं। जैसे-जैसे कार्य स्वतंत्र होते हैं, मेरा अंतर्ज्ञान यह था कि यह समानता को शर्मसार करने वाला उदाहरण होना चाहिए। मुझे इस बात का उल्लेख करना चाहिए कि थोड़ी सी ट्यूनिंग के बाद, वास्तव में इसे करीब 2 का स्पीडअप मिल गया
थिओडोर नॉरवेल

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

2
@MaciejPiechotka नैतिकता आपके द्वारा सुझाई गई सभी चीजें हैं। लेकिन ओपी में वापस आते हुए, मुझे लगता है कि सबसे प्रासंगिक नैतिक यह है कि एक मल्टीथ्रेड प्रोग्राम वास्तव में एक ही कोर प्रोसेसर की तुलना में मल्टी-कोर आर्किटेक्चर पर धीमा (बहुत) धीमी गति से चल सकता है, जब तक कि अन्यथा सुनिश्चित करने के लिए प्रयास नहीं किया गया हो।
थियोडोर नॉरवेल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.