एल्गोरिथम की सेवा में आयरन (जारी)

बोरिस बाबयान कंप्यूटिंग के भूत, वर्तमान और भविष्य पर

इस कार्य के पहले भाग के प्रकाशन के लगभग तीन महीने बीत चुके हैं। इस समय, दूसरा भाग पक रहा था और ... आखिरकार पक गया!

जैसा कि पिछले भाग में, बाबायन की ओर से कथा का निर्माण किया गया है। मैंने अपनी अधिकांश टिप्पणियों को साइडबार या वेब पृष्ठों के लिंक के रूप में डिज़ाइन किया है।


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

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

यह पता चला है कि दुनिया में कोई भी नहीं है, हमारे एल्ब्रस बच्चों को छोड़कर, उच्च-स्तरीय भाषाओं के वास्तविक फायदे जानते हैं। और यह सिर्फ भयानक है!

अब, इन लाभों को प्राप्त करने में क्या लगता है? बहुत कम। यह करना आसान है।

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

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

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

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

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

यही है, प्रत्येक प्रक्रिया का एक संदर्भ है। हमने इसे "प्रासंगिक रक्षा" भी कहा।

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

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

अंतरिक्ष से लौटने के बाद, उस प्रक्रिया का संदर्भ जिसने इसे विस्तार दिया। और इसके लिए किसी विशेषाधिकार प्राप्त कार्रवाई की आवश्यकता नहीं थी।

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

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

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

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

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

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

इस तथ्य के कारण कि सब कुछ स्मृति में टाइप किया गया है, डिबगिंग बस मेमोरी डंप की जांच करके किया जा सकता है। जब हमने एल्ब्रस कार दो को सौंप दिया, तो इसने SRCET में परियोजना प्रबंधक लेन्या रायकोव ने भाग लिया। और NICEVT एक ऐसी संस्था है जिसने IBM मशीनों की नकल की है। हमने तब सिर्फ एक ऑपरेटिंग सिस्टम बनाया था; अक्सर सौ टर्मिनल काम करते हैं; अक्सर कुछ प्रकार की त्रुटियां होती हैं। हमारे लोगों ने एक मेमोरी डंप लिया। यह संरचित है, इसके प्रकार हैं। प्रोग्रामर दो घंटे बैठे, ऑपरेटिंग सिस्टम को ठीक करने के लिए गए। लेन्या रायकोव निरुत्तर थे! क्योंकि वे, जब आईबीएम ऑपरेटिंग सिस्टम में एक त्रुटि का पता चलता है, तो उन्हें कई महीनों के लिए इस त्रुटि को प्राप्त करने की आवश्यकता होती है।

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

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

इस सब के बाद, यह स्मृति सफाई को जोड़ने के लिए बनी हुई है। मैं अब समझाता हूं कि यह क्या है।

मान लीजिए एक प्रोग्रामर ने किसी तरह की मेमोरी का इस्तेमाल किया और उसे मुक्त कर दिया। मुक्त स्मृति को साफ करने की आवश्यकता है क्योंकि इसमें पुराने विवरण शामिल हो सकते हैं। यदि मेमोरी को मिटाया नहीं गया है, तो ये विवरण नए हाथों में हो सकते हैं।और यह सुरक्षा का उल्लंघन होगा। इसलिए, स्मृति को साफ किया जाना चाहिए। लेकिन यह सरल है, यह एक ऑपरेटिंग सिस्टम है और अब यह कर सकता है।

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

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

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

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

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

वह सब है! मैंने जिन कठिनाइयों का वर्णन किया है, उसके अलावा कोई कठिनाई नहीं है। यही है, सहायक वस्तुओं का कुछ भी खर्च नहीं होता है! लेकिन यह अभी भी किसी भी कार में नहीं है!बस एक आपदा, समझे? उच्च-स्तरीय प्रोग्रामिंग के रूप में ऐसी संपत्ति अभी भी मौजूद नहीं है।

मैंने ऊपर जो कुछ भी बात की थी, वह लगभग पूरी तरह से स्थानिक घटक से संबंधित थी।

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

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

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

अब तक जिन दो एल्गोरिदम के बारे में मैंने बात की, वे मशीन अंकगणित का आधार हैं। समानतावाद के लिए संघर्ष उनके साथ शुरू हुआ।

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

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

वर्ष 78 तक, हमने दुनिया का पहला आउट-ऑफ-ऑर्डर सुपर-स्केलर बनाया था।सच है, उसके पास केवल 2 कन्वेयर थे। अब सुपरस्क्लेयर 6 कन्वेयर तक बढ़ गया है। पावर 8 में दस हैं। लेकिन यह आरआईएससी है। वहां बड़ी संख्या में कन्वेयर बनाना आसान है।

इंटेल ने 95 वें वर्ष में एक आउट-ऑफ-ऑर्डर मशीन बनाई। एक बहुत बड़ी दूरी प्राप्त की जाती है। 78 वां वर्ष और 95 वां। 17 साल की उम्र! आतंक!

यह समानता के लिए संघर्ष था।

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

अब वर्तमान सुपरसर्लर माइक्रोप्रोसेसर को देखें। यह कुछ अविश्वसनीय है। भद्दी बात। सबसे पहले, संकलक शुरू में समानांतर एल्गोरिदम को एक शासक में बदल देता है। फिर सुपरसेलकर मशीन फिर से इस शासक से समानता लाती है। और फिर, इस तथ्य के कारण कि भाषाएं लगातार हैं, सेवानिवृत्ति इकाई एक पंक्ति में फिर से समानांतर में निष्पादित निर्देशों को पूरा करती है।यहाँ इस तरह के एक वक्र है! भला, क्या यह बर्दाश्त किया जा सकता है? यह सिर्फ भयानक है। लेकिन लोग पीड़ित हैं।

मेरी अवधारणाओं के अनुसार, सुपरस्क्लर मशीनें बहुत अपूर्ण हैं (हालांकि एक समय में वे बहुत उपयोगी थीं)। मेरे सहयोगियों और मैंने लंबे समय से महसूस किया है कि सुपरस्क्लेयर की एक सीमा है ... इसकी सीमा क्यों है? क्योंकि धारावाहिक से समानांतर तक के इस रूपांतरण की एक सीमा है। आधुनिक इंटेल सुपरकोलर में डिकोडर को हर घड़ी चक्र में चार या छह डिक्रिप्टेड कमांड जारी करना चाहिए। और पढ़ना सुसंगत है। इसलिए, प्रत्येक चक्र को छह ऑपरेशन डिकोड करना इतना आसान नहीं है। X86 डिकोडर बहुत जटिल है।

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

इस प्रकार, सुपरस्लेकर की एक सीमा, एक प्रदर्शन सीमा होती है। हमें एल्बरस दो के बाद दूसरी पीढ़ी के सुपरसेलरों के बाद इसका एहसास हुआ। हालांकि दूसरे एल्ब्रस सुपरसर्कर के समय एक अच्छा विचार था। हमने इस पर आईबीएम को हराया, इस अर्थ में कि हमने एनआईसीवीटी से अपने प्रतिद्वंद्वियों को हराया जिन्होंने ईसी -1060 बनाया - आईबीएम सिस्टम / 360 की एक पूरी प्रतिलिपि (3033 प्रोसेसर के साथ, जो कि सुपरसेलकर नहीं था)।

हमने उन्हें दो बार हराया। लेकिन यह NICEVT के साथ प्रतिस्पर्धा नहीं थी, लेकिन IBM के साथ, क्योंकि NICEVT ने अमेरिकी मशीन की घड़ी-सटीक प्रतिलिपि बनाई, अर्थात, उन्होंने इसे हराकर दोहराया। और उनके सॉफ्टवेयर सभी आईबीएम जा रहे थे। और हमारे पास अपना सब कुछ है।

हालांकि, सुपरसैलर का विचार कितना भी सुंदर क्यों न हो, हमें एहसास हुआ कि इसकी एक सीमा है। बदले में कुछ के साथ आना आवश्यक है। इसके बाद हमने वोलोडा वोल्कॉन्स्की के साथ इस विषय के बारे में बहुत सोचा और "ट्रेन्स" के साथ आए - एक ही कोर के भीतर निष्पादन के समानांतर धागे।हमने सोचा: ठीक है, 32 ट्रेनों को बनाने के लिए - और हमारे पास वास्तविक समानता होगी! लेकिन फिर मैंने एक गलती की। मुझे लगा कि यह बहुत कठिन है, लेकिन एक सरल दृष्टिकोण है - एक व्यापक टीम का दृष्टिकोण। खैर, हमने इसे आजमाने का फैसला किया। आखिरकार, हम इस व्यापक टीम के minuses को नहीं जानते थे ...

परिणामस्वरूप, हमने एक विस्तृत टीम बनाई। लेकिन इटेनियम में ऐसा नहीं है। इटेनियम भी पूरी तरह से गलतफहमी है, इसलिए बोलने के लिए। क्योंकि चौड़ाई में यह सुपरसेलकर: 6 टीमों के समान है। और एक ही समय में स्थिर योजना का उपयोग करता है। इसे सुपरसेलकर से तेज क्यों होना चाहिए? मुझे नहीं मिला

हम Elbrus तीन में क्लस्टर दृष्टिकोण लागू किया है।इस तथ्य के कारण कि विस्तृत टीम में धारावाहिक से समानांतर में एक गतिशील रूपांतरण नहीं है, एकल निर्देश सूचक का रखरखाव अब बेकार नहीं है।

हमारे साथ प्रत्येक टीम 22 ऑपरेशन तक शामिल हो सकती है। अर्थात्, 22 कार्यकारी उपकरण थे।

हमने इसके साथ काम किया और महसूस किया कि यह शानदार नहीं है, क्योंकि स्थैतिक योजना का उपयोग किया जाता है।

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

उसके बाद, पहले से ही इंटेल में, हमने एक प्रोजेक्ट बनाना शुरू किया जो हमें दोनों दृष्टिकोणों की सीमाओं से दूर होने की अनुमति देगा।

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

क्या बदलने की जरूरत है? सब कुछ खराब क्यों है? ठीक है, सबसे पहले, मैंने पहले ही कहा था कि सुपरस्लेकर बहुत जटिल है। लेकिन सबसे बुरी बात यह है कि इसकी एक प्रदर्शन सीमा है। इसकी सीमा - 6 कन्वेयर - अब संभव नहीं है। पावर 8 में उनमें से 10 हैं, लेकिन यह आरआईएससी है। वहां यह आसान है, x86 में - अधिक जटिल। लेकिन यह "अधिक जटिल" अब इंटेल टीम की उच्च योग्यता से ऑफसेट से अधिक है। इस मामले में योग्यता का बहुत महत्व है।

अब देखें कि इस सीमा के कारण क्या हुआ है। वे सोचने लगते हैं कि मशीन का विस्तार कैसे किया जाए, तार्किक गति कैसे बढ़ाई जाए। भला यह कैसे हो सकता है? आवृत्ति में वृद्धि अब सीमित है। इसलिए, वेक्टर अंकगणित पेश किया गया है।

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

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

इस स्थिति में Iterative समानता स्वाभाविक होगी। और वैक्टर के साथ इसका उपयोग नहीं किया जा सकता है।

वैक्टर उपकरणों की एक जटिलता है, और यह जटिलता कई मामलों में बस उपयोग नहीं की जाती है। यह बहुत लोकप्रिय नहीं है।

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

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

इस तरह के एक एल्गोरिथ्म को समानांतर करने के लिए, सिंक्रनाइज़ेशन की आवश्यकता है। क्योंकि कई ऑब्जेक्ट एक विशिष्ट पिक्सेल पर समानांतर में प्रोजेक्ट करने का प्रयास करेंगे। लेकिन कई ऑब्जेक्ट हो सकते हैं, और सिंक्रनाइज़ेशन को अस्वीकार्य रूप से लंबा समय लगता है। क्योंकि स्मृति के माध्यम से सिंक्रनाइज़ेशन चला जाता है। एक नियम के रूप में, सेमाफोरस को साझा मेमोरी से लिया जाता है।

यह एक कारण था जिसके कारण लारबी परियोजना विफल हो गई।

और ग्राफिक्स के लिए आदर्श रूप से क्या आवश्यक है? हमें स्पष्ट समानता को लागू करने के लिए पर्याप्त उपकरणों की आवश्यकता है।

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

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

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

यही है, वास्तव में, क्या आवश्यक था? स्पष्ट समानता की आवश्यकता थी। स्मृति और समय दोनों में कार्यक्रम की यह लगातार प्रस्तुति एक बोझ बन गई है। रैखिक स्थान के कारण, हमारे पास प्रकार-सुरक्षा नहीं है, क्योंकि वस्तुओं के लिए कोई समर्थन नहीं है। सब कुछ अंतरिक्ष में आदेश दिया है।

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

तो, फिर से, तर्क का पता लगाने के लिए: आधुनिक सुपरस्क्लेर बहुत जटिल है और इसकी गति सीमा भी है। इस सीमा को पार करने के लिए, वेक्टरकरण और मल्टी-थ्रेडिंग की शुरुआत की जाती है। और जो वास्तव में आवश्यक है वह स्पष्ट समानता है।

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

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

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

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

लेकिन देखो, उदाहरण के लिए, कि यह दृष्टिकोण के साथ असंभव है। आप कोड स्वैपिंग के रूप में ऐसी सरल अनुकूलन नहीं कर सकते। यह वोलोडा पेंटकोवस्की ने मुझे समझाया। उन्होंने प्री-पेजिंग लागू करने वाली टीमों में काम किया।

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

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

अच्छी तरह से अनुकूलन करने के लिए, आपको एल्गोरिथ्म को जानने की आवश्यकता है। जो, ज़ाहिर है, उपकरण के लिए उपलब्ध नहीं है।

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

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

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

यहां एक सरल तरीका कैश के बजाय स्थानीय मेमोरी में प्रवेश करना है। फिर कैश में लगभग कोई चूक नहीं होगी। स्थानीय मेमोरी केवल एक विशिष्ट कोर की सेवा करनी चाहिए।

लेकिन अब यह कैसे किया जाता है? एक कार्यक्रम है, किसी तरह का कर्नेल काम कर रहा है। यह किसी प्रकार की मेमोरी के साथ काम करता है। और यह ज्ञात नहीं है: क्या एक ही मेमोरी के साथ दूसरे कोर पर एक समानांतर ऑपरेशन है या नहीं। बस मामले में, किसी को यह मान लेना होगा कि ऐसा काम चल रहा है। हमें मेमोरी-मॉडल को झेलना होगा। इससे कार काफी धीमी हो गई। यह बेवकूफी है!

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

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

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

अब ... जब मुझे आधुनिक कारों की कमियों का एहसास हुआ, तो मैं घबरा गया! लंबे समय से पहले से ही उपकरण पूरी तरह से अलग है। और एक ही समय में बहुत पहले कारों मॉडलिंग की जाती हैं। और कोई यह भी नहीं सोचता कि यह बेवकूफी है। हर कोई डरता है।

मैं पहले ही बहुत कुछ कह चुका हूं। लेकिन क्या, अंत में, भविष्य की सबसे प्रगतिशील मशीन का मेरा चेहरा है?

यहाँ देखो। एल्गोरिदम हैं। यह सुनिश्चित करना आवश्यक है कि कार्यक्रमों में स्थानिक और लौकिक दोनों घटक पूरी तरह से एल्गोरिथ्म के बराबर हैं। इसके लिए, स्पष्ट समानता की भाषा पेश की जाती है। हमें इस पर काम करने की जरूरत है। इस भाषा में, प्रकार की सुरक्षा आवश्यक रूप से मौजूद है। यह पहला है।

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

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

अगला, आपको कैश समस्या को हल करने की आवश्यकता है।

यह सबसे कठिन जगह है। कम से कम पता लगाया। कुछ सावधानी के साथ, कुछ पूर्वानुमान के साथ, मैं दावा करता हूं कि कैश को बस बाहर फेंकने की आवश्यकता है। केशी पुराने जमाने की देन है। आपको एक सीधे पता योग्य मेमोरी दर्ज करनी होगी।

फिर सेवानिवृत्ति को भी फेंकने की आवश्यकता है।

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

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

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

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

हालाँकि, यदि ऐसा है, तो स्मार्टफोन डेवलपर्स का जीवन बहुत आसान हो जाएगा।

अब वे बड़ी संख्या में जटिल उपकरणों के साथ अपने दम पर काम करने के लिए मजबूर हैं। उनकी प्रतिस्पर्धा बहुत उग्र होती जा रही है।

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

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

मैं फिर से जोर देता हूं कि अब क्या हो रहा है। कंप्यूटर तकनीक की वर्तमान स्थिति मूल से बहुत दूर नहीं है, जब सब कुछ रैखिक था।

संगतता सब कुछ पर हावी है: अनुक्रमिक समय, अनुक्रमिक स्थान। और टायर अभी भी मॉडलिंग की जा रही है। अब, यदि यह सब हटा दिया जाता है और किया जाता है, जैसा कि मैं अभी कहता हूं, तो सुपरस्केलर सीमा हटा दी जाती है, और हम एल्गोरिदम की प्राकृतिक सीमा से संपर्क कर रहे हैं।

और यह सीमा कुछ मायनों में अकल्पनीय है। यहाँ वे मुझे बता सकते हैं: शायद, आपके सिर में कुछ गड़बड़ है। अकल्पनीय का क्या अर्थ है? प्रगति रुक ​​गई, या क्या?

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

खैर, शायद, वह सब जो मैं कहना चाहता था। मैं आपके बारे में नहीं जानता, लेकिन यह मुझ पर बहुत बड़ा प्रभाव डालता है।

लेखक ने सामग्री तैयार करने में उनकी मदद के लिए अलेक्जेंडर ओस्टेनिविच और सर्गेई शिश्लोव को धन्यवाद दिया।

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

धन्यवाद!