AVX-512

आर्किटेक्चर संदर्भFeex

AVX-512 opmask रजिस्टरों और 512-बिट संचालन के समर्थन के साथ x86 वेक्टर एक्सटेंशन का एक परिवार है। इसके फाउंडेशन और अलग-अलग सबसेट की अलग से जांच की जानी चाहिए; एक एकल AVX-512 लेबल एक पूर्ण अनुकूलता विनिर्देश नहीं है।

आपको क्या जानना चाहिए

यह कैसे काम करता है

यह आर्किटेक्चर ZMM वेक्टर स्टेट और k opmask रजिस्टर्स जोड़ता है। मास्क्ड ऑपरेशन्स अलग-अलग लेन्स चुन सकते हैं, जिसमें निर्देश-विशिष्ट मर्जिंग या ज़ीरोइंग व्यवहार शामिल होता है। AVX512F इसका आधार है; AVX512BW, DQ, CD और VL विभिन्न अतिरिक्त क्षमताओं को कवर करते हैं। AVX512VL संकरे वेक्टर्स पर प्रासंगिक ऑपरेशन्स की अनुमति देता है, इसलिए AVX-512 कोड हर निर्देश पर अनिवार्य रूप से 512 बिट्स प्रोसेस नहीं करता है।

यह कहाँ उपयोगी है

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

सपोर्ट और सक्षमता की जांच कैसे करें

AVX जाँचों के बाद, प्रोग्राम द्वारा आवश्यक विशिष्ट CPUID leaf 7 फ़ीचर बिट्स को सत्यापित करें। AVX-512 स्टेट के लिए, XCR0 को XMM, YMM, opmask, अपर ZMM और हाई ZMM स्टेट सक्षम करने चाहिए: बिट्स 1, 2, 5, 6 और 7। आमतौर पर उपयोग किया जाने वाला मास्क E6H है। XGETBV से पहले OSXSAVE की जाँच करें और एक ऐसे डिस्पैचर का उपयोग करें जो प्रत्येक आवश्यक सबसेट की जाँच करता हो।

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

यह सुविधा क्या स्थापित नहीं करती है

AVX512F, CPU जेनरेशन नाम या x86-64-v4 से प्रत्येक AVX-512 सबसेट का अनुमान न लगाएँ। फ़्रीक्वेंसी, पावर और निष्पादन थ्रूपुट कार्यान्वयन और वर्कलोड के अनुसार भिन्न होते हैं। केवल एक डेटाबेस लेबल यह स्थापित नहीं कर सकता कि फ़र्मवेयर, हाइब्रिड-कोर नीति या हाइपरवाइज़र वर्तमान प्रोसेस के लिए कोई उपयोगी फ़ीचर उपलब्ध कराता है या नहीं।

व्यवहार में अनुकूलता और प्रदर्शन

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

एक व्यावहारिक सत्यापन चेकलिस्ट

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

यदि सुविधा सूचीबद्ध है लेकिन सॉफ़्टवेयर इसका उपयोग नहीं कर सकता है

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

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

इस व्याख्या के स्रोत और दायरा

Intel 64 and IA-32 Architectures Software Developer's Manual · Linux कर्नेल: यूजर स्पेस में XSTATE सुविधाओं का उपयोग करना · x86-64 psABI: प्रोसेसर आर्किटेक्चर और माइक्रोआर्किटेक्चर स्तर

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

स्रोत और सत्यापन

संपादकीय स्वामित्व: Feex। कोई स्वतंत्र समीक्षा तिथि दर्ज नहीं है। हम कैसे शोध करते हैं.

Intel 64 and IA-32 Architectures Software Developer's Manual · खंड 1 और 2 नामित निर्देश परिवारों और CPUID का वर्णन करते हैं; खंड 3 स्टेट, पेजिंग, VMX और सुरक्षा नियंत्रणों का वर्णन करता है। आर्किटेक्चर दस्तावेज़ किसी विशेष मॉडल के लिए समर्थन स्थापित नहीं करता है।
Linux कर्नेल: यूजर स्पेस में XSTATE सुविधाओं का उपयोग करना · OS-सक्षम वेक्टर स्थिति, गतिशील रूप से सक्षम टाइल स्थिति, सिग्नल-स्टैक आवश्यकताएं और AMX अनुमति प्रवाह। लिनक्स-विशिष्ट व्यवहार किसी अन्य OS के बारे में वादा नहीं है।
x86-64 psABI: प्रोसेसर आर्किटेक्चर और माइक्रोआर्किटेक्चर स्तर · मशीन इंटरफ़ेस, प्रोसेसर आर्किटेक्चर: बेसलाइन और संचयी v2/v3/v4 फ़ीचर टेबल, OS-स्टेट जाँचें और डिप्लॉयमेंट सिफ़ारिशें।

क्या यह लेख उपयोगी था?

हाँ या ना ही काफी है। यदि आप चाहें तो कोई कारण चुनें, या एक संक्षिप्त नोट जोड़ें।