क्या आप मल्टीकोर के बारे में चिंतित हैं?

Question

यह निर्विवाद है: मल्टीकोर कंप्यूटर यहां रहने के लिए हैं।

तो यह है: कुशल मल्टीकोर प्रोग्रामिंग बहुत मुश्किल है। यह सिर्फ pthreads समझने का मामला नहीं है।

यह तर्कसंगत है: 'सड़क पर डेवलपर' को इन घटनाओं के साथ खुद को चिंता करने की आवश्यकता है।

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

Answer 1

प्रोग्राम आमतौर पर सीपीयू बाध्य हैं?

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

कूल, आह?

यदि आप सीपीयू बाध्य हैं, और आपकी समस्या समानांतर है, तो आप एकाधिक कोर का लाभ उठाने में सक्षम हो सकते हैं। यही समय है कि इसके बारे में चिंता करना शुरू करें।

---

टिप्पणियों से

: यदि आपके प्रोग्राम सीपीयू बाध्य है कैसे बताने के लिए किसी न किसी तरह की व्याख्या दे: जवाब में सुधार के लिए

सुझाव। - Earwicker

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

तो आपको यह जानने की आवश्यकता होगी कि आपका प्रोग्राम पल से पल (और मशीन कितनी व्यस्त है ...) पर एक यूनिक्स जैसी प्रणालियों को खोजने के लिए top चलाएं। विंडोज़ पर टास्कमैनगर (धन्यवाद रोबोप्रोग) का उपयोग करें।

1 कोर से कम लोड वाली मशीन पर (यानी आपकी डेस्कटॉप मशीन जब आप कुछ भी नहीं कर रहे हों) पर, एक सीपीयू बाध्य प्रक्रिया में लगातार 50% प्रोसेसर होता है (अक्सर 90 से अधिक %)। जब लोड औसत उस से अधिक होता है (यानी आपके पास तीन संकलन हैं, सेटी @ होम, और दो पीयर-टू-पीयर नेटवर्क पृष्ठभूमि में चल रहे हैं) एक सीपीयू बाध्य प्रक्रिया में (# of cores)/(load average) का एक बड़ा अंश होगा।

Answer 2

मैं 15 से अधिक वर्षों से धागे के साथ प्रोग्रामिंग कर रहा हूं। मैं थोड़ी सी

Answer 3

में चिंतित नहीं हूं, मुझे चिंता नहीं है। अवधारणाएं बहुत कठिन नहीं हैं और अधिक डेवलपर्स मल्टीथ्रेड किए गए ऐप्स लिखते हैं = विषय पर अधिक सामग्री = आपको यह जानने के लिए आसान है कि आपको क्या चाहिए।

Answer 4

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

Answer 5

मुझे लगता है कि इसे हल्के ढंग से रखने के लिए आम तौर पर इसमें रुचि लेने लायक है।

यह शायद ही कहने की जरूरत है कि पिछले कुछ दशकों में सीपीयू की गति में भारी वृद्धि बेहद मूल्यवान रही है, और आगे के लाभ उतना ही मूल्यवान होंगे।

लेकिन उन लाभों में अब से अधिकतर कोर की संख्या में नियमित दोगुना होना शामिल है। इसलिए इन लाभों से लाभ उठाने के लिए, सॉफ्टवेयर को समांतर करने की आवश्यकता है।

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

लेकिन हम में से ज्यादातर लोग सी # में लिख रहे हैं, भले ही हम जीयूआई लिख रहे हों, हमें इस सामान पर ध्यान देना होगा। एक जीयूआई को उपयोगकर्ता को जो भी मॉडल प्रस्तुत करता है, उस पर कुछ उपयोगी ऑपरेशन करना पड़ता है, और उपयोगकर्ता को बैठने के लिए परेशान हो जाता है और इसे पूरा करने की प्रतीक्षा होती है। वे कुछ वर्षों में और भी नाराज हो जाएंगे, जब वे टास्क मैनेजर को देखेंगे और देखेंगे कि उनकी फैंसी नई 32-कोर मशीन का लगभग 3% उपयोग किया जा रहा है।

Answer 6

बस एक तरफ ध्यान दें: यदि आपके ऐप में एक जीयूआई है और तीव्र गणना करता है, तो हमेशा एक अलग धागे पर अपनी गहन गणना करें। ऐसा करने के लिए भूलना यही कारण है कि जीयूआई जमा हो जाते हैं।

Answer 7

मुझे लगता है कि होने की संभावना क्या है कि एक बार बड़ी संख्या में कोर (8+ कहें) आम हो जाते हैं, तो हम उन अनुप्रयोगों के विकास को देखेंगे जो समांतरता का लाभ उठाते हैं जिन्हें एकल-थ्रेडेड दुनिया में व्यवहार्य नहीं माना जाता था ।

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

तो जब तक कि आपके वर्तमान ऐप्स अत्यधिक CPU-बाध्य न हों, मैं उन्हें समानांतर करने की चिंता नहीं करता। यदि आपको लगता है कि आपके पास एकाधिक कोर के माध्यम से सीपीयू पावर का ढेर है, तो नई परियोजनाओं में इसका फायदा उठाने के तरीकों को देखें।

1) क्लाइंट-साइड:

Answer 8

ठीक है, के बाद से मैं ASP.Net में वेब विकास करते हैं, वहाँ कुछ क्षेत्रों मैं मल्टीकोर एक भूमिका निभा रहा है देख सकते हैं कर रहे हैं। जावास्क्रिप्ट की तरह कुछ क्लाइंट के लिए ऑप्टिमाइज़ किया जा सकता है जिसमें क्वाड-कोर सीपीयू है यदि कोई ऐसा है जो डेटा की लंबी सूची को सॉर्ट करने जैसा कुछ चलाने में दोहन करना चाहता है। क्या वसा-ग्राहक आईई, फ़ायरफ़ॉक्स, सफारी और क्रोम के नए संस्करणों के साथ वापस आ रहे हैं?

2) वेब सर्वर पर सर्वर-साइड। आईआईएस और .NET ढांचे के भीतर जो इसका उपयोग करता है, PLINQ जैसी चीजें हैंडलिंग अनुरोधों को तेज़ करने में सहायता के लिए समांतर या समवर्ती प्रोग्रामिंग का उपयोग कैसे करती हैं? प्रदर्शन को बढ़ाने और हार्डवेयर को ट्यून करने के लिए आईआईएस सेटिंग्स किस प्रकार की जा सकती हैं?

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

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

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

ये सिर्फ मेरे वर्तमान विचार हैं और किसी भी समय परिवर्तन के अधीन हैं।

Answer 9

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

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

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

लेकिन मैं नहीं कर रहा हूँ कड़वा :-)

संशोधन/टिप्पणी:

बहुत बढ़िया दूरी करने वाली स्मृति के बारे में कहीं और टिप्पणी। मैं हाल ही में इस बारे में कुछ भी सोच रहा था। मार्क-एंड-स्वीप कचरा संग्रह वास्तव में चल रही प्रक्रियाओं के "इलाके" पहलू को नुकसान पहुंचाता है। एम/एस जीसी 0 पुरानी 80286 पर स्टेट रैम पर हानिकारक लग रहा था, लेकिन यह वास्तव में बहु-स्तर कैशिंग आर्किटेक्चर पर दर्द होता है। शायद गिनती का संदर्भ + फोर्क/निकास कुछ मामलों में जीसी कार्यान्वयन के रूप में इतना बुरा विचार नहीं है?

---

संपादित करें: मैं यहाँ मेरी बात का बैकअप लेने में कुछ प्रयास डाल (परिणाम भिन्न हो): http://roboprogs.com/devel/2009.04.html

Answer 10

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

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

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

Answer 11

नहीं, मुझे चिंता नहीं है।

मेरा काम औसत से थोड़ा अधिक असामान्य और संभवतः समांतरता समान है, लेकिन इस पर ध्यान दिए बिना कि मैं इसे किसी समस्या से अधिक अवसर के रूप में देखता हूं।

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

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

Answer 12

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

सीएस के काफी साफ क्षेत्र। :)

Answer 13

इंडी गेम डेवलपर के रूप में मैं वास्तव में इसके बारे में बहुत उत्साहित हूं। सक्रिय पलों के दौरान कई गेम सीपीयू बाध्य होते हैं। और लगभग सभी आधुनिक 3 डी गेम हार्डवेयर पर बहुत कर लगा रहे हैं। मल्टीकोर पिछले कई सालों से वीडियो के लिए जमीन का कानून रहा है। कुछ एनवीडिया कार्ड आजकल 200 कोर से अधिक हैं।

इन कार्डों के लिए लेखन शेडर्स एक खुशी है, और मैं यह देखने के लिए इंतजार नहीं कर सकता कि अधिक से अधिक मशीन बहु-प्रसंस्करण के बाहर क्या आती है।

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

पास अवधि: यह एक बड़ी बात है जब तक आप अपने प्रोसेसर दीर्घकालिक कुचल कर रहे हैं नहीं है: बेहतर ताले :)

Answer 14

Dataflow programming साथ आराम मिलता है मल्टीकोर समस्या के लिए एक अपेक्षाकृत आसान समाधान के लिए कुछ वादा दिखाता है।

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

Answer 15

मैं वर्तमान स्वीकृत उत्तर से सहमत नहीं हूं।

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

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

मल्टीकोर पर एक अच्छे अवलोकन के लिए http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html देखें और जिस तरह से चीजें चल रही हैं। वे जो प्रमुख बिंदु कहते हैं वे हैं:

• घड़ी की गति पहले की तरह नहीं बढ़ रही है। फास्ट प्रोसेसर की एक छोटी संख्या की तुलना में धीमी, सरल कोर की अधिक संख्या के निर्माण के लिए यह अधिक लागत प्रभावी है।
• स्मृति (तेजी) दूर सीपीयू
• कुछ ही वर्षों में से है, वहाँ वेब सर्वर में कोर, डेस्कटॉप पर 100s के 1000s किया जाएगा। इसलिए अपने आवेदन (शायद ऑटो-स्केल) को 100 या कोर के 1000s तक स्केल करने की योजना बनाएं। इसका मतलब है कि आपको कई स्वतंत्र कार्य बनाना चाहिए।
• धागे के साथ काम करना मुश्किल है, इसलिए "कार्यों" के साथ बेहतर काम है।

Answer 16

कोई रास्ता नहीं! मैं एक क्लोजर प्रोग्रामर हूँ! : डी

Answer 17

जिस चीज के बारे में मैं सोच रहा हूं, वह सबसे अधिक विभाजित नहीं है और एल्गोरिदम बड़े पैमाने पर समानांतर नहीं है? प्रत्येक विभाजन को दो अलग-अलग धागे में चलाने में सक्षम होना चाहिए ...

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

Answer 18

दिन-प्रति-दिन मैं बहु-कोर प्रोग्रामिंग के बारे में बहुत कुछ नहीं सोचता, लेकिन यह हमेशा मेरे रडार पर होता है।

समानांतर प्रसंस्करण के साथ हमेशा की सबसे बड़ी समस्या यह निर्धारित करती है कि समानांतरता क्या होनी चाहिए? एक फ़ाइल को पृष्ठभूमि प्रक्रिया में थ्रेड को स्पिन करना आसान है, लेकिन फ़ाइल प्रसंस्करण स्वयं समानांतर हो सकता है?

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

Answer 19

मुझे लगता है कि यह एक अच्छा सवाल है। इसलिए, मैंने here के बारे में ब्लॉग पोस्ट की एक श्रृंखला शुरू कर दी है।

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

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

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

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

मैं पूरी तरह से सहमत हूं कि एक सीपीयू बाध्य ऑपरेशन लेना और इसे लकड़हारा करना अक्सर जटिल कार्य हो सकता है - ठीक अनाज सिंक्रनाइज़ेशन, सीपीयू कैशिंग, सीपीयू निर्देश पाइपलाइन इत्यादि के ज्ञान की आवश्यकता होती है। दरअसल, यह क्लासिकल 'हार्ड' ।

लेकिन, मैं तर्क दूंगा कि उसे करने की आवश्यकता दुर्लभ है; ऐसे कई समस्याएं नहीं हैं जिनके लिए इस तरह के दानेदार समांतरता की आवश्यकता है। हाँ! वे मौजूद हैं और आप इसे हर दिन सौदा कर सकते हैं, लेकिन मैं तर्क दूंगा कि अधिकांश डेवलपर्स के दिन-प्रतिदिन, यह बहुत दुर्लभ है।

फिर भी, बहु-थ्रेडेड के मूलभूत सिद्धांतों और इस प्रकार बहु-कोर विकास सीखने के अच्छे कारण हैं।

1. यह संदेश लूप थ्रेड से लंबे संचालन को स्थानांतरित करके आपके प्रोग्राम को उपयोगकर्ता परिप्रेक्ष्य से अधिक उत्तरदायी बना सकता है।
2. उन चीजों के लिए भी जो सीपीयू बाध्य नहीं हैं, अक्सर उन्हें समानांतर में करने के लिए समझ में आता है।
3. यह जटिल एकल थ्रेडेड राज्य मशीनों को सरल, अधिक प्रक्रियात्मक कोड में तोड़ सकता है।

दरअसल, ओएस पहले से ही आपके लिए बहुत कुछ करता है, और आप पुस्तकालयों का उपयोग कर सकते हैं जो बहु-कोर सक्षम हैं (जैसे Intel's stuff)। लेकिन, ऑपरेटिंग सिस्टम और पुस्तकालय जादू नहीं हैं - मैं तर्क देता हूं कि बहु-थ्रेडेड प्रोग्रामिंग की मूल बातें सीखने के लिए अधिकांश मूल्यवान हैं। यह आपको बेहतर सॉफ़्टवेयर लिखने देगा जो आपके उपयोगकर्ता खुश हैं।

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

Answer 20

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