भविष्य की समानांतर प्रोग्रामिंग तकनीक क्या होनी चाहिए?

मैंने हेब्रेटोपिक को देखा "समानांतर प्रक्रियाओं को प्रोग्रामिंग करना - क्या यह बहुत जटिल है?" , और महसूस किया कि ऐसे लोग हैं जो इसमें रुचि रखते हैं। मैं इस मामले पर अपनी राय व्यक्त करने का विरोध नहीं कर सका।



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



इसलिए, इंटेल इस तथ्य में रुचि रखता है कि सॉफ़्टवेयर उत्पादों के निर्माता डेस्कटॉप के लिए मल्टीथ्रेडेड प्रोग्राम लिखेंगे।



हालांकि, सब कुछ इतना सरल नहीं है। खासकर सॉफ्टवेयर निर्माताओं के लिए।



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



एडवर्ड ए। ली ने लेख में लिखा है "स्ट्रीम के साथ समस्याएं" : "मैं पुष्टि करता हूं कि ज्यादातर मामलों में सिस्टम की विश्वसनीयता और पूर्वानुमानशीलता धाराओं का उपयोग करके हासिल नहीं की जा सकती है।"



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



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



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



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



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



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



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



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