🧕🏽 💅 👨🏿‍🌾 थ्रेड्स गोटो पैरेलल प्रोग्रामिंग हैं ☘️ 🍏 💪🏼

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

^{फ़ोटो द्वारा: रेनर ज़ेनज़}

पहले, थोड़ा इतिहास और पहले से ही चर्चा के संदर्भ।

गोटो को हानिकारक माना

संभवतः उस समय के दुर्भाग्यपूर्ण ऑपरेटर के ताबूत में सबसे अधिक आधिकारिक नाखून, 1968 के अपने पांच-पृष्ठ लेख में "ए केस टू गो स्टेटमेंट" के रूप में भी जाना जाता था, जिसे "गो-टू स्टेटमेंट" हानिकारक माना जाता था।

होबे पर, उच्च-स्तरीय भाषाओं में कार्यक्रमों से गोटो का उपयोग / निष्कासन का विषय बार-बार उठाया गया है:
habrahabr.ru/post/114211
habrahabr.ru/post/114470
habrahabr.ru/post/114326
निस्संदेह, गोटो का अस्तित्व अंतहीन होलीवर का एक स्रोत है। हालांकि, आधुनिक "सामान्य उद्देश्य" भाषाएं, जावा से लगभग शुरू होती हैं, गोटो को उनके सिंटैक्स में शामिल नहीं करती हैं, कम से कम अपने मूल रूप में।

अभी भी गोटो कहां है

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

मैं गोटो के खिलाफ सभी ज्ञात तर्कों का वर्णन छोड़ दूंगा; कोई भी उन्हें ऊपर दिए गए लिंक में पा सकता है। मैं एक निष्कर्ष तुरंत लिखूंगा, जैसा कि मैं इसे समझता हूं: गोटो का उपयोग "उच्च स्तर" कोड को कम करता है, एल्गोरिदम को क्रमिक कार्यान्वयन के विवरण में छिपाता है । चलिए चलते हैं बहने।

थ्रेड समस्या क्या है?

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

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

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

खैर, अगर धागे नहीं?

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

ओपनएमपी अच्छा है, लेकिन ऐसा नहीं है

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

एक्सटेंशन और पुस्तकालय

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

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

C ++ 11

नवीनतम सी ++ मानकों में, आधुनिक कंप्यूटिंग की समानांतर प्रकृति ने आखिरकार स्वीकृति प्राप्त कर ली है; कई भाषा निर्माणों और मानक कक्षाओं का वर्णन करते समय कोड की क्षमता को कुछ और के साथ एक साथ निष्पादित किया जाता है। इसके अलावा, प्रोग्रामर अमूर्त के स्तरों की एक विस्तृत श्रृंखला से चुन सकता है: std::thread माध्यम से धागे के प्रत्यक्ष हेरफेर से std::thread एक अतुल्यकालिक कॉल के माध्यम से std::packaged_task लिए एक अतुल्यकालिक / आलसी कॉल करने के लिए std::packaged_task गया। इस सभी मशीनरी के उचित संचालन को सुनिश्चित करने के लिए बहुत सारे काम तीसरे पक्ष के पुस्तकालयों से मानक एक में स्थानांतरित हो रहे हैं, जो एक संकलक के साथ आता है जो नए मानक की क्षमताओं को लागू करता है। एक खुला (कम से कम मेरे लिए) सवाल है: क्या C ++ 11 कार्यान्वयन पहले से मौजूद हैं जो उच्च-स्तरीय समानता के सभी तीन गुण प्रदान करते हैं: संरचना, वैकल्पिकता और संतुलन, और इस तरह इन चिंताओं से एप्लिकेशन प्रोग्रामर को मुक्त करता है।

और क्या पढ़ना है

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

माइकल मैककूल, आर्क रॉबिसन, जेम्स रेंडर्स। संरचित समानांतर प्रोग्रामिंग - 2012 - समानांतरबुक.कॉम ।

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

आपका ध्यान के लिए धन्यवाद!

थ्रेड्स गोटो पैरेलल प्रोग्रामिंग हैं