महाकाव्य पर विकिपीडिया लेख पहले से ही VLIW और महाकाव्य के लिए आम कई खतरों को रेखांकित किया गया है।
यदि किसी को उस लेख से भाग्यवाद का भाव नहीं आता है, तो मुझे इस पर प्रकाश डालिए:
मेमोरी पदानुक्रम से लोड प्रतिक्रियाएं जिसमें CPU कैश और DRAM शामिल हैं, एक नियतकालिक देरी नहीं है।
दूसरे शब्दों में, कोई भी हार्डवेयर डिज़ाइन जो मेमोरी एक्सेस से गैर-नियतात्मक विलंबता के साथ (*) सामना करने में विफल रहता है, बस एक शानदार विफलता बन जाएगी।
(*) "सामना" के द्वारा, उचित निष्पादन निष्पादन (दूसरे शब्दों में, "लागत-प्रतिस्पर्धी") को प्राप्त करना आवश्यक है, जो आवश्यक है कि सीपीयू को दसियों से सैकड़ों चक्र तक कभी भी बेकार न होने दें।
ध्यान दें कि EPIC द्वारा नियोजित नकल की रणनीति (ऊपर लिंक विकिपीडिया लेख में उल्लिखित है) वास्तव में इस मुद्दे को हल नहीं करता है। यह केवल कहता है कि डेटा निर्भरता को इंगित करने का बोझ अब संकलक पर पड़ता है। कोई बात नहीं; संकलक के पास पहले से ही वह जानकारी है, इसलिए वह कंपाइलर के अनुपालन के लिए सीधा है। समस्या यह है कि सीपीयू अभी भी मेमोरी एक्सेस पर दसियों सैकड़ों चक्रों के लिए निष्क्रिय हो रहा है। दूसरे शब्दों में, यह एक माध्यमिक जिम्मेदारी को बाहरी करता है, जबकि अभी भी प्राथमिक जिम्मेदारी का सामना करने में विफल है।
इस प्रश्न को फिर से परिभाषित किया जा सकता है: "एक हार्डवेयर प्लेटफ़ॉर्म को देखते हुए, जो एक विफलता के रूप में पाया जाता है, क्यों (1) नहीं किया (2) संकलक लेखकों को इसे भुनाने के लिए एक वीरतापूर्ण प्रयास नहीं कर सकता है?"
मुझे आशा है कि मेरा रीफ़्रेशिंग उस प्रश्न का उत्तर स्पष्ट कर देगा।
असफलता का एक दूसरा पहलू है जो घातक भी है।
मैथुन की रणनीतियों (उसी लेख में उल्लिखित) मानती हैं कि सॉफ़्टवेयर-आधारित प्रीफ़ैचिंग का उपयोग मेमोरी एक्सेस से गैर-नियतात्मक विलंबता के कारण प्रदर्शन हानि के कम से कम भाग को पुनर्प्राप्त करने के लिए किया जा सकता है।
वास्तव में, प्रीफ़ेटिंग केवल तभी लाभदायक है जब आप स्ट्रीमिंग ऑपरेशन (क्रमिक, या अत्यधिक अनुमानित तरीके से मेमोरी पढ़ना) कर रहे हों।
(उस ने कहा, यदि आपका कोड कुछ स्थानीय मेमोरी क्षेत्रों में लगातार पहुंच बनाता है, तो कैशिंग मदद करेगा।)
हालाँकि, अधिकांश सामान्य-प्रयोजन सॉफ़्टवेयर को बहुत सारे रैंडम मेमोरी एक्सेस का उपयोग करना चाहिए। यदि हम निम्नलिखित चरणों पर विचार करते हैं:
- पते की गणना करें, और फिर
- मान पढ़ें, और फिर
- कुछ गणनाओं में इसका उपयोग करें
अधिकांश सामान्य-प्रयोजन सॉफ़्टवेयर के लिए, इन तीनों को त्वरित उत्तराधिकार में निष्पादित किया जाना चाहिए। दूसरे शब्दों में, यह हमेशा संभव नहीं है (सॉफ्टवेयर लॉजिक की सीमा के भीतर) पते की गणना करने के लिए, या इन तीन चरणों के बीच स्टालों को भरने के लिए पर्याप्त कार्य खोजने के लिए।
यह समझाने में मदद करने के लिए कि स्टालों को भरने के लिए हमेशा पर्याप्त काम ढूंढना क्यों संभव नहीं है, यहां बताया गया है कि कोई कैसे कल्पना कर सकता है।
- मान लीजिए, स्टालों को प्रभावी ढंग से छिपाने के लिए, हमें 100 निर्देशों को भरने की आवश्यकता है जो स्मृति पर निर्भर नहीं करते हैं (इसलिए अतिरिक्त विलंब से ग्रस्त नहीं होंगे)।
- अब, एक प्रोग्रामर के रूप में, कृपया अपनी पसंद के किसी भी सॉफ़्टवेयर को एक डिस्सेम्बलर में लोड करें। विश्लेषण के लिए एक यादृच्छिक फ़ंक्शन चुनें।
- क्या आप कहीं भी 100 निर्देशों (*) के अनुक्रम की पहचान कर सकते हैं जो विशेष रूप से मेमोरी एक्सेस से मुक्त हैं?
(*) यदि हम कभी NOPभी उपयोगी कार्य कर सके ...
आधुनिक सीपीयू गतिशील जानकारी का उपयोग करके उसी के साथ सामना करने की कोशिश करते हैं - प्रत्येक निर्देश की प्रगति को समवर्ती रूप से ट्रैक करते हुए, क्योंकि वे पाइपलाइनों के माध्यम से प्रसारित होते हैं। जैसा कि मैंने ऊपर उल्लेख किया है, उस गतिशील जानकारी का हिस्सा गैर-नियतात्मक मेमोरी विलंबता के कारण है, इसलिए इसे संकलक द्वारा सटीकता की किसी भी डिग्री के लिए भविष्यवाणी नहीं की जा सकती है। सामान्य तौर पर, निर्णय लेने के लिए संकलन-समय पर पर्याप्त जानकारी उपलब्ध नहीं होती है जो संभवतः उन स्टालों को भर सकती है।
AProgrammer द्वारा जवाब के जवाब में
ऐसा नहीं है कि "संकलक ... समानता को निकालना कठिन है"।
आधुनिक संकलक द्वारा स्मृति और अंकगणितीय निर्देशों का पुन: निर्धारण इस बात का प्रमाण है कि इसमें उन परिचालनों की पहचान करने में कोई समस्या नहीं है जो स्वतंत्र रूप से और इसलिए समवर्ती निष्पादन योग्य हैं।
मुख्य समस्या यह है कि गैर-नियतात्मक मेमोरी लेटेंसी का मतलब है कि जो भी "इंस्ट्रक्शन पेयरिंग" है वह वीएलआईडब्ल्यू / ईपीआईसी प्रोसेसर के लिए एन्कोड किया गया है जो मेमोरी एक्सेस द्वारा रुका हुआ होगा।
उन निर्देशों का अनुकूलन करना जो स्टाल नहीं करते हैं (रजिस्टर-ओनली, अंकगणित) उन निर्देशों के कारण होने वाले प्रदर्शन मुद्दों के साथ मदद नहीं करेगा जो स्टाल (मेमोरी एक्सेस) की बहुत संभावना है।
यह अनुकूलन के 80-20 नियम को लागू करने में विफलता का एक उदाहरण है: पहले से ही तेज होने वाली चीजों का अनुकूलन, समग्र प्रदर्शन में सार्थक रूप से सुधार नहीं करेगा, जब तक कि धीमी चीजों को भी अनुकूलित नहीं किया जा रहा है।
बेसिल स्टायरनेविच द्वारा जवाब देने के लिए
यह "... (जो भी) कठिन है)" नहीं है, यह है कि ईपीआईसी किसी भी मंच के लिए अनुपयुक्त है जिसे विलंबता में उच्च गतिशीलता के साथ सामना करना पड़ता है।
उदाहरण के लिए, यदि प्रोसेसर में निम्नलिखित में से सभी हैं:
- कोई प्रत्यक्ष मेमोरी एक्सेस नहीं;
- किसी भी मेमोरी एक्सेस (रीड या राइट) को डीएमए ट्रांसफर द्वारा निर्धारित किया जाना है;
- प्रत्येक निर्देश में एक ही निष्पादन विलंबता होती है;
- आदेश में निष्पादन;
- वाइड / वेक्टरकृत निष्पादन इकाइयाँ;
तब VLIW / EPIC एक अच्छा फिट होगा।
ऐसे प्रोसेसर कहाँ से मिलते हैं? डीएसपी। और यहीं पर VLIW का उत्कर्ष हुआ है।
दृष्टिहीनता में, इटेनियम की विफलता (और स्पष्ट सबूतों के बावजूद आर एंड डी के प्रयास को जारी रखना) संगठनात्मक विफलता का एक उदाहरण है, और गहराई से अध्ययन करने के योग्य है।
दी गई, विक्रेता के अन्य उद्यम, जैसे कि हाइपरथ्रेडिंग, SIMD, आदि, अत्यधिक सफल प्रतीत होते हैं। यह संभव है कि इटेनियम में निवेश का इसके इंजीनियरों के कौशल पर समृद्ध प्रभाव पड़ा हो, जिसने उन्हें अगली पीढ़ी की सफल तकनीक बनाने में सक्षम बनाया हो।