कोई और अधिक मुक्त सूप नहीं होगा

प्रोग्रामिंग में संगामिति के लिए एक मौलिक बदलाव

पोस्ट करनेवाले: Coat of Arms Sutter
अनुवाद: अलेक्जेंडर काचानोव

नि: शुल्क दोपहर का भोजन खत्म हो गया है: सॉफ्टवेयर में एक मौलिक टेंपर्ड कंज्यूमर की ओर
(हर्ब सटर द्वारा)

मूल लेख का लिंक: www.gotw.ca/publications/concurrency-ddj.htm

अनुवादक का नोट : यह लेख प्रोसेसर के विकास में वर्तमान रुझानों का अवलोकन प्रदान करता है, साथ ही साथ ये रुझान हमारे प्रोग्रामर के लिए क्या मायने रखते हैं। लेखक का मानना ​​है कि ये रुझान मौलिक हैं, और जीवन को बनाए रखने के लिए हर आधुनिक प्रोग्रामर को किसी चीज को त्यागना होगा।

यह लेख काफी पुराना है। वह पहले से ही 7 साल का है, यदि आप 2005 की शुरुआत में उसके पहले प्रकाशन के क्षण से गिनती करते हैं। यह याद रखें जब आप अनुवाद पढ़ते हैं, तो 2005 में लेख के लेखक के लिए बहुत सी चीजें जो पहले से ही आपके परिचित हो चुकी हैं और बस दिखाई दे रही थीं।


ओओपी क्रांति के बाद से सबसे बड़ी सॉफ्टवेयर विकास क्रांति आपके दरवाजे पर दस्तक दे रही है, और इसका नाम समानांतरवाद है।


यह लेख पहली बार "डॉ।" पत्रिका में प्रकाशित हुआ था। डॉब के जर्नल, मार्च 2005। इस लेख का एक छोटा संस्करण C / C ++ Users Journal में फरवरी 2005 में "Concurrency क्रांति" शीर्षक के तहत प्रकाशित किया गया था।

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

मुफ्त सूप जल्द ही चला जाएगा। इस बारे में आप क्या करेंगे? अब आप इस बारे में क्या कर रहे हैं?

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

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

शायद मुफ्त सूप एक या दो साल पहले ही समाप्त हो गया। हमने अभी इसे नोटिस करना शुरू किया।

नि: शुल्क प्रदर्शन सूप

आपने शायद ऐसा दिलचस्प कहावत सुनी होगी: "कोई बात नहीं, एंडी कितना कुछ देता है, बिल सब ले जाएगा" ("एंडी गिव एंड बिल टेकथ दूर")? (टिप्पणी अनुवादक - यह एंडी ग्रोव को संदर्भित करता है - इंटेल के प्रमुख, और बिल गेट्स - माइक्रोसॉफ्ट के प्रमुख)। कोई फर्क नहीं पड़ता कि कितने प्रोसेसर अपनी गति बढ़ाते हैं, प्रोग्राम हमेशा यह पता लगाएंगे कि इस गति पर क्या खर्च करना है। प्रोसेसर को दस गुना तेज बनाओ, और कार्यक्रम इसके लिए दस गुना अधिक काम करेगा (या, कुछ मामलों में, एक ही काम को दस बार कम कुशलता से करने की अनुमति देता है)। अधिकांश अनुप्रयोग कई दशकों से तेज़ी से और तेज़ी से चल रहे हैं, इसके लिए बिल्कुल कुछ भी नहीं कर रहे हैं, यहां तक ​​कि नए संस्करण या कोड में मूलभूत परिवर्तन जारी किए बिना। यह सिर्फ इतना है कि प्रोसेसर के निर्माता (सबसे पहले) और मेमोरी के निर्माता और हार्ड ड्राइव (सभी का दूसरा) हर बार अधिक से अधिक नए, कभी तेज कंप्यूटर सिस्टम बनाए। प्रोसेसर घड़ी की गति इसके प्रदर्शन का मूल्यांकन करने के लिए एकमात्र मानदंड नहीं है, और सबसे सही भी नहीं है, लेकिन फिर भी यह बहुत कुछ कहता है: हमने देखा कि कैसे 1 गीगाहर्ट्ज की घड़ी आवृत्ति के साथ प्रोसेसर द्वारा 500 मेगाहर्ट्ज प्रोसेसर बदले गए थे, और उनके बाद - 2 हर्ट्ज - नए प्रोसेसर और इतने पर। इसलिए अब हम एक ऐसे दौर से गुजर रहे हैं जब 3 GHz की क्लॉक फ्रीक्वेंसी वाला प्रोसेसर काफी साधारण होता है।

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

यदि आप एक सॉफ़्टवेयर डेवलपर हैं, तो सबसे अधिक संभावना है कि आप लंबे समय से डेस्कटॉप प्रदर्शन को बढ़ाने के मद्देनजर आराम कर रहे हैं। क्या किसी तरह का ऑपरेशन करते समय आपका प्रोग्राम धीरे-धीरे चलता है? "आप चिंता क्यों करते हैं?", आप कहते हैं, "कल और भी तेज़ प्रोसेसर निकलेंगे, लेकिन सामान्य कार्यक्रमों में धीरे-धीरे काम करना, न केवल धीमे प्रोसेसर और धीमी मेमोरी के कारण (उदाहरण के लिए, धीमे I / O उपकरणों के कारण, कॉल के कारण डेटाबेस के लिए) " विचार की सही ट्रेन?

काफी सच है। कल के लिए। लेकिन भविष्य के भविष्य के लिए बिल्कुल गलत है।

अच्छी खबर यह है कि प्रोसेसर अधिक से अधिक शक्तिशाली हो जाएंगे। बुरी खबर यह है कि, कम से कम निकट भविष्य में, प्रोसेसर पावर की वृद्धि एक ऐसी दिशा में जाएगी जिससे अधिकांश मौजूदा कार्यक्रमों के काम का स्वत: त्वरण नहीं होगा।

पिछले 30 वर्षों में, प्रोसेसर डेवलपर्स तीन मुख्य क्षेत्रों में प्रदर्शन बढ़ाने में सक्षम रहे हैं। उनमें से पहले दो कार्यक्रम कोड के निष्पादन से संबंधित हैं:

• प्रोसेसर की गति
• कोड निष्पादन अनुकूलन
• कैश

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

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

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

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

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

सब ठीक है। मैं यह सब क्यों हूँ?

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

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

यह दुनिया कितनी खूबसूरत थी। दुर्भाग्य से, यह दुनिया अब मौजूद नहीं है।

बाधाएं, या हम 10 गीगाहर्ट्ज प्रोसेसर क्यों नहीं देखते हैं

दो साल पहले हमारे लिए प्रोसेसर के प्रदर्शन में सामान्य वृद्धि एक दीवार के पार हुई थी। हम में से अधिकांश ने पहले ही यह नोटिस करना शुरू कर दिया है।

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



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

एक संक्षिप्त विषयांतर: देखो, आपके कंप्यूटर पर प्रोसेसर की आवृत्ति क्या है? शायद 10 गीगा? इंटेल प्रोसेसर 2 गीगाहर्ट्ज के स्तर पर बहुत पहले (अगस्त 2001 में) पहुंच गए थे, और अगर घड़ी की आवृत्ति की वृद्धि की प्रवृत्ति, जो 2003 से पहले मौजूद थी, तब जारी रही, तो अब - 2005 की शुरुआत में - 10 हर्ट्ज की आवृत्ति वाला पहला पेंटियम प्रोसेसर दिखाई देगा। चारों ओर देखो, क्या आप उन्हें देखते हैं? इसके अलावा, किसी के पास भी ऐसी घड़ी की गति के साथ योजना नहीं है, और हम यह भी नहीं जानते हैं कि ऐसी योजनाएं कब दिखाई देंगी।

खैर, 4GHz प्रोसेसर के बारे में क्या? पहले से ही, 3.4 गीगाहर्ट्ज की आवृत्ति वाले प्रोसेसर हैं, इसलिए 4 गीगाहर्ट्ज कोने के आसपास है? काश, हम 4 GHz तक भी नहीं पहुँच पाते। 2004 के मध्य में, आपको शायद याद होगा कि कैसे इंटेल ने 4 जीएचजेड प्रोसेसर को 2005 में रिलीज़ करना स्थगित कर दिया था, और फिर 2004 के पतन में आधिकारिक तौर पर इन योजनाओं की पूरी अस्वीकृति की घोषणा की। इस लेख को लिखने के समय, इंटेल ने 2005 की शुरुआत में 3.73 गीगाहर्ट्ज़ की आवृत्ति के साथ एक प्रोसेसर लॉन्च करके थोड़ा आगे बढ़ने की योजना बनाई (चित्र 1 में यह आवृत्ति विकास ग्राफ में उच्चतम बिंदु है), लेकिन हम कह सकते हैं कि हर्त्ज़ की दौड़ कम से कम है। आज का क्षण। भविष्य में, इंटेल और अधिकांश प्रोसेसर निर्माता अन्य तरीकों से विकास का पीछा करेंगे: वे सभी सक्रिय रूप से मल्टीकोर समाधानों की ओर मुड़ रहे हैं।

हो सकता है किसी दिन हम अभी भी अपने डेस्कटॉप कंप्यूटर में 4GHz प्रोसेसर देखेंगे, लेकिन यह 2005 में नहीं होगा। बेशक, इंटेल प्रयोगशालाओं में प्रोटोटाइप हैं जो उच्च गति पर काम करते हैं, लेकिन ये गति वीर प्रयासों द्वारा प्राप्त की जाती है, उदाहरण के लिए, भारी शीतलन उपकरण की मदद से। कभी भी अपने कार्यालय में ऐसे शीतलन उपकरण की उम्मीद न करें, और निश्चित रूप से एक हवाई जहाज में नहीं जहां आप लैपटॉप पर काम करना चाहते हैं।

BSNB: मूर का नियम और प्रोसेसर की अगली पीढ़ी

"कोई मुफ्त सूप (BSNB) नहीं है" - R.A. हेनलीन, "चंद्रमा एक सख्त मालकिन है"

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

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

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

• हाइपरथ्रेडिंग (हाइपरथ्रेडिंग)
• कई कोर (मल्टीकोर)
• कैश (कैश)

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

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

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

(एक संक्षिप्त विषयांतर: यहां वह कहानी है जो हमारे संकलक के साथ हुई थी, कथन के प्रदर्शन के रूप में "आकार का अर्थ है गति।" हमारे संकलक के 32-बिट और 64-बिट संस्करण एक ही स्रोत कोड से बनाए जाते हैं, बस जब हम संकलित करते हैं जो प्रक्रिया होती है। आपको बनाने की आवश्यकता है: 32-बिट या 64-bit.It की उम्मीद थी कि 64-बिट कंपाइलर 64-बिट प्रोसेसर पर तेजी से चलना चाहिए, यदि केवल इसलिए कि 64-बिट प्रोसेसर में बहुत अधिक रजिस्टर थे, और तेजी से अनुकूलन कार्य भी थे कोड निष्पादन। सूर्य ई बस ठीक है। और डेटा के बारे में क्या? 64 बिट्स पर स्विच करने से, निश्चित रूप से, पॉइंटर्स को छोड़कर, मेमोरी में अधिकांश डेटा संरचनाओं का आकार नहीं बदला, जो दो बार बड़े हो गए। यह पता चला कि हमारे कंपाइलर कुछ के मुकाबले पॉइंटर्स का अधिक बार उपयोग करते हैं। या एक और आवेदन।चूंकि पॉइंटर्स का आकार अब 4 बाइट्स के बजाय 8 बाइट्स हो गया है, इसलिए कंपाइलर के साथ काम करने वाले कुल डेटा का आकार बढ़ गया है। तेजी से प्रोसेसर और अतिरिक्त रजिस्टरों की उपलब्धता के कारण डेटा वॉल्यूम में वृद्धि ने प्रदर्शन को कम कर दिया। इस लेखन के समय, हमारा 64-बिट संकलक अपने 32-बिट समकक्ष के समान गति से चल रहा है, इस तथ्य के बावजूद कि दोनों संकलक समान स्रोत कोड से इकट्ठे हैं, और 64-बिट प्रोसेसर 32-बिट से अधिक शक्तिशाली है। आकार का मतलब गति!)इस लेखन के समय, हमारा 64-बिट संकलक अपने 32-बिट समकक्ष के समान गति से चल रहा है, इस तथ्य के बावजूद कि दोनों संकलक एक ही स्रोत कोड से इकट्ठे हैं, और 64-बिट प्रोसेसर 32-बिट से अधिक शक्तिशाली है। आकार का मतलब गति!)इस लेखन के समय, हमारा 64-बिट संकलक अपने 32-बिट समकक्ष के समान गति से चल रहा है, इस तथ्य के बावजूद कि दोनों संकलक समान स्रोत कोड से इकट्ठे हैं, और 64-बिट प्रोसेसर 32-बिट से अधिक शक्तिशाली है। आकार का मतलब गति!)

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

तो हार्डवेयर में इन परिवर्तनों का हमारे लिए प्रोग्रामर से क्या मतलब है? आप शायद पहले ही समझ गए हैं कि उत्तर क्या होगा, इसलिए आइए इस पर चर्चा करें और निष्कर्ष निकालें।

मिथक और वास्तविकताएं: 2 x 3GHz <6GHz

यदि दोहरे कोर प्रोसेसर में दो 3GHz कोर होते हैं, तो हमें 6GHz प्रोसेसर का प्रदर्शन मिलता है। है न?

नहीं!यदि दो थ्रेड्स दो शारीरिक रूप से अलग-अलग प्रोसेसर पर निष्पादित होते हैं, तो इसका मतलब यह बिल्कुल नहीं है कि कार्यक्रम का समग्र प्रदर्शन दोगुना हो जाता है। इसी तरह, मल्टी-थ्रेडेड प्रोग्राम दोहरे कोर प्रोसेसर पर दो बार तेजी से काम नहीं करेगा। हां, यह सिंगल-कोर प्रोसेसर की तुलना में तेजी से काम करेगा, लेकिन गति रैखिक रूप से नहीं बढ़ेगी।

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

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

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

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

सॉफ्टवेयर के लिए महत्व: एक और क्रांति

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

आज तक।

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

मैं रोने की आवाज सुनता हूं: "चिंता? यह क्या खबर है ?! लोग लंबे समय से समानांतर कार्यक्रम लिख रहे हैं। ” ठीक है।लेकिन यह केवल प्रोग्रामर का एक तुच्छ हिस्सा है।

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

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

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

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

समवर्ती के लाभ और यह हमें कितना खर्च करेगा

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

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

शायद अनुप्रयोगों को समानांतर करने के मार्ग पर दूसरी मुख्य कठिनाई यह तथ्य है कि सभी कार्यक्रमों को समानांतर नहीं किया जा सकता है। मैं इसके बारे में और नीचे कहूंगा।

फिर भी, समानता की मुख्य कठिनाई अपने आप में निहित है। समानांतर प्रोग्रामिंग मॉडल, अर्थात। छवियों का मॉडल जो प्रोग्रामर के सिर में विकसित होता है, और जिसकी मदद से वह अपने कार्यक्रम के व्यवहार का न्याय करता है, अनुक्रमिक निष्पादन के मॉडल की तुलना में बहुत अधिक जटिल है।

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

, , , : , . , , : , , , . , , - , , . .

- ( ? ? ? «» «», – ?), – ( «»? « » (deadlock)? ? ? (message queue)? «» «», – ?)

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

( . (concurrent lock-free programming), Java 5 ++. , . , , , . , .)

?

ठीक है। आइए हम प्रोग्रामर के लिए इस सब का मतलब क्या है।

1. पहला मुख्य परिणाम, जिसे हम पहले ही कवर कर चुके हैं, वह यह है कि यदि आप 100% प्रोसेसर का उपयोग करना चाहते हैं, तो एप्लीकेशन समानांतर हो जाना चाहिए, जो पहले से ही बाजार पर दिखाई देने लगे हैं और अगले कुछ वर्षों में इस पर स्कोर को ठीक कर देंगे। उदाहरण के लिए, इंटेल का दावा है कि निकट भविष्य में यह 100 कोर का प्रोसेसर बनाएगा; एक सिंगल-थ्रेडेड एप्लिकेशन इस प्रोसेसर की शक्ति का केवल 1/100 उपयोग कर सकेगा।

हां, सभी एप्लिकेशन (या, अधिक सटीक रूप से, एप्लिकेशन द्वारा किए गए महत्वपूर्ण संचालन) को समानांतर नहीं किया जा सकता है। हां, कुछ कार्यों के लिए, जैसे कि संकलन, संगामिति लगभग सही है। लेकिन दूसरों के लिए, नहीं। आमतौर पर, एक काउंटर-उदाहरण के रूप में, एक सामान्य वाक्यांश को याद करता है कि अगर एक महिला को बच्चा होने में 9 महीने लगते हैं, तो इसका मतलब यह नहीं है कि 9 महिलाएं 1 महीने में बच्चे को जन्म देने में सक्षम होंगी। आप शायद इस सादृश्य से मिले। लेकिन क्या आपने इस उपमा की कपटपूर्णता पर ध्यान दिया है? जब आपको इसके बारे में फिर से उल्लेख किया जाता है, तो एक साधारण प्रश्न पूछें: "क्या इस सादृश्य से निष्कर्ष निकाला जा सकता है कि बच्चे को जन्म देने के कार्य को परिभाषा द्वारा समानांतर नहीं किया जा सकता है?" आमतौर पर लोग प्रतिक्रिया में सोचते हैं और फिर जल्दी से इस निष्कर्ष पर पहुंचते हैं कि "हाँ? , इस समस्या को समानांतर नहीं किया जा सकता है, लेकिन यह पूरी तरह सच नहीं है। यदि हमारा लक्ष्य एक ही बच्चे को जन्म देना है, तो निश्चित रूप से इसे समानांतर नहीं किया जा सकता है। लेकिन यह पूरी तरह से समानांतर है अगर हम खुद को यथासंभव अधिक बच्चे (प्रति माह एक बच्चा) को जन्म देने का लक्ष्य निर्धारित करें! इसलिए, वास्तविक लक्ष्य को जानने से सब कुछ उल्टा हो सकता है। उद्देश्य के इस सिद्धांत को याद रखें, जब यह तय करना कि आपका कार्यक्रम बदलना है और इसे कैसे करना है।

2. शायद कम स्पष्ट परिणाम यह है कि अधिकांश संभावित अनुप्रयोग प्रोसेसर (सीपीयू-बाउंड) के कारण अधिक से अधिक धीमा हो जाएंगे। बेशक, यह सभी अनुप्रयोगों के साथ नहीं होगा, और जिन लोगों के साथ ऐसा हो सकता है, वे सचमुच कल को धीमा नहीं करेंगे। फिर भी, हम संभवतः उस सीमा पर पहुंच गए जब I / O सिस्टम के कारण, या नेटवर्क या डेटाबेस तक पहुंच के कारण एप्लिकेशन धीमा हो गए थे। इन क्षेत्रों में, गति अधिक और अधिक हो रही है (क्या आपने गीगाबिट वाई-फाई के बारे में सुना है?)। और प्रोसेसर को तेज करने के सभी पारंपरिक तरीकों ने खुद को समाप्त कर दिया है। जरा सोचिए: हम अब 3 GHz पर मजबूती से अटक गए हैं। नतीजतन, सिंगल-थ्रेडेड प्रोग्राम तेजी से काम नहीं करेंगे, जब तक कि प्रोसेसर कैश का आकार बढ़ाकर (कम से कम कुछ अच्छी खबर)। इस दिशा में अन्य प्रगति उतनी बड़ी नहीं होगी जितनी हम करते थे। उदाहरण के लिए, यह संभावना नहीं है कि सर्किट इंजीनियर एक नया तरीका पाएंगे कि प्रोसेसर पाइपलाइन को काम से कैसे भरें और इसे निष्क्रिय होने से रोकें। यहां, सभी स्पष्ट समाधान लंबे समय तक पाए गए और कार्यान्वित किए गए हैं। बाजार लगातार कार्यक्रमों से अधिक कार्यक्षमता की मांग करेगा; इसके अलावा, नए एप्लिकेशन को अधिक से अधिक डेटा संसाधित करना होगा। जितनी अधिक कार्यक्षमता हम कार्यक्रमों में पेश करना शुरू करते हैं, उतनी ही जल्दी हम ध्यान देंगे कि कार्यक्रमों में प्रोसेसर शक्ति की कमी है क्योंकि वे समानांतर नहीं हैं।

और यहाँ आपके पास दो विकल्प होंगे। सबसे पहले, अपने आवेदन को समानांतर में रीमेक करें, जैसा कि ऊपर बताया गया है। या, लेज़िएस्ट के लिए, कोड को फिर से लिखें ताकि यह अधिक कुशल और कम बेकार हो जाए। जो हमें तीसरे निष्कर्ष पर ले जाता है:

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

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

निष्कर्ष में

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

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

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