विषम प्रोग्रामिंग और oneAPI टूलकिट। इंटेल विशेषज्ञ ने आपके व्याख्यान का उत्तर दिया

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

प्रश्न सोरेक्स 16

ओपनसीएल से वनएपीआई में कितना श्रमसाध्य होगा और इससे क्या लाभ हो सकते हैं?

जवाब है। DPC ++ पर स्विच करना मुश्किल हो सकता है, लेकिन मेरी राय में, यह इसके लायक है। दो मुख्य चरण हैं।

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

क्यों कोशिश करें?

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

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

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

auto kern = [A, B, C](cl::sycl::id<1> wiID) { C[wiID] = A[wiID] + B[wiID]; //   A, B  C?  ! }; 

OpenCL पर एक ही बात:

 _kernel void vector_add(__global int *A, __global int *B, __global int *C) { int i = get_global_id(0); C[i] = A[i] + B[i]; } 

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

और सभी लाभ इस तक सीमित नहीं हैं। मैं निम्नलिखित उत्तरों में कुछ और उल्लेख करूंगा।

इसलिए मैंने आपके स्थान पर कंपाइलर डाउनलोड किया होगा और इसे आज़माया होगा, क्योंकि OneAPI पैकेज के साथ ऐसा करना मुश्किल नहीं है।

प्रश्न जस्टर

क्या OpenVINO और OneAPI किसी तरह संबंधित होंगे?

जवाब है। OpenVINO वितरण अब OneAPI वितरण का हिस्सा है। तंत्रिका नेटवर्क को सीखना और उपयोग करना कम्प्यूटेशनल रूप से कठिन कार्य हैं जो विषम प्रोग्रामिंग से बहुत लाभान्वित होते हैं। मेरा मानना ​​है कि जितनी जल्दी या बाद में, सभी वनएपीआई घटक आपके लिए उपलब्ध सभी कंप्यूटिंग संसाधनों का उपयोग करना संभव बना देंगे: ग्राफिक्स त्वरक और नर्वाना और एफपीजीए जैसे विशेष त्वरक दोनों। और यह सब आपके सी ++ प्रोग्राम की भाषा प्रतिमान और प्रकार प्रणाली को छोड़े बिना।

मेल से सवाल

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

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

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

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

पाइथन और उसकी सुविधा के लिए ... मुझे तुरंत स्वीकार करना चाहिए कि मैं गतिशील रूप से टाइप की गई भाषाओं की तरह नहीं हूं: वे धीमी हैं और सामान्य संकलन त्रुटि के बजाय, आपको गलत प्रकार के कारण रनटाइम में गिरने से दो घंटे पहले इंतजार करना होगा। लेकिन मैं यह नहीं देखता कि पायथन के तहत एक ही तरह के अपराध करना कितना बुरा है। वैसे, OneAPI में पहले से ही Python के लिए Intel वितरण शामिल है, जो विभिन्न समीक्षाओं के लिए बेहद सुविधाजनक है।

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

मेल से सवाल

ओपनसीएल बनाम प्रदर्शन। लक्जरी पर कर होना चाहिए - अर्थात ओवरहेड लागत। क्या कोई माप हैं?

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

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

इसके अलावा, विकास के समय के संदर्भ में डीपीसी ++ की नकारात्मक लागत होगी। एक सरल उदाहरण SYCL एक्सेसर्स है, जो संकलक पहले से ही घटनाओं की व्यवस्था करने और अतुल्यकालिक कतारों का प्रबंधन करने के लिए उपयोग कर रहा है।

 deviceQueue.submit([&](cl::sycl::handler &cgh) { auto A = bufferA.template get_access<sycl_read>(cgh); auto B = bufferB.template get_access<sycl_read>(cgh); auto C = bufferC.template get_access<sycl_write>(cgh); .... deviceQueue.submit([&](cl::sycl::handler &cgh) { auto A = bufferA.template get_access<sycl_read>(cgh); auto B = bufferB.template get_access<sycl_read>(cgh); auto D = bufferD.template get_access<sycl_write>(cgh); 

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

बेशक, एक मौलिक रूप से लिखित ओपनसीएल कार्यक्रम इसे भी कर सकता है, लेकिन गैर-तुच्छ कर्नेल के साथ बिताए गए विकास का समय तुलनीय नहीं होगा।

मेल से सवाल

क्या DPC ++ के लिए OpenCL अनुप्रयोगों को अनुकूलित करने के सभी तरीके प्रासंगिक हैं? उनके लिए क्या नया जोड़ा जाना है?

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

अधिक विस्तृत जवाब के लिए, मैं यहाँ रसातल से डरता हूँ। उदाहरण के लिए, एक प्रसिद्ध इंटेल दस्तावेज़ है "इंटेल प्रोसेसर ग्राफिक्स के लिए ओपनसीएल डेवलपर गाइड"। और कोशिश करने के तरीके पर एक खंड है , ताकि अतिरिक्त सिंक्रोनाइज़ेशन न हो।

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

दूसरी ओर, डीपीसी ++ में, स्पष्ट अवरोधों के साथ कोड लिखने के बजाय, इस तरह:

  for (t = 0; t < numTiles; t++) { const int tiledRow = TS * t + row; const int tiledCol = TS * t + col; Asub[col][row] = A[globalRow * AY + tiledCol]; Bsub[col][row] = B[tiledRow * BY + globalCol]; // Synchronise to make sure the tile is loaded barrier(CLK_LOCAL_MEM_FENCE); // .... etc .... 

आप संभवतः समांतर_for_work_group का एक स्पष्ट पुनरावृत्ति लिखेंगे, जिसके भीतर group.parallel_for_work_item

 cgh.parallel_for_work_group<class mxm_kernel>( cl::sycl::range<2>{BIG_AX / TS, BIG_BY / TS}, cl::sycl::range<2>{TS, TS}, [=](cl::sycl::group<2> group) { // .... etc .... for (int t = 0; t < numTiles; t++) { group.parallel_for_work_item([&](cl::sycl::h_item<2> it) { // .... etc .... Asub[col][row] = A[globalRow][tiledCol]; Bsub[col][row] = B[tiledRow][globalCol]; }); //      ,    

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

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

मेल से सवाल

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

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

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

और इसलिए, यदि हम प्रत्यक्ष और प्रभावी समाधानों के बारे में बात करते हैं, तो, निश्चित रूप से, डीपीसी ++ में कोई जादू नहीं है। अंत में आपका कार्यक्रम अभी भी भागों में विभाजित है: होस्ट कोड और डिवाइस कोड, और सभी डिवाइस प्रतिबंध डिवाइस कोड को प्रभावित करते हैं। काम करने वाले समूह का अधिकतम आकार वास्तविक समानता है जो आपके हार्डवेयर में सक्षम है। नाटकीय रूप से नकारात्मक रूप से प्रदर्शन को प्रभावित करने के लिए, इसके शीर्ष पर सब कुछ है। यही कारण है कि DPC ++ ऐसा करने का अवसर प्रदान करता है: device.get_info <sycl :: info :: device :: max_work_group_size> () और फिर तय करें कि परिणामी संख्या के साथ कैसे जीना है।

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

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

मेल से सवाल

DPC ++ SYCL पर आधारित है। लेकिन क्या होगा यदि आप हुड के नीचे गहराई से जाते हैं, तो बैक एंड के कार्यान्वयन में ओपनसीएल से क्या अंतर हैं, यदि कोई हो। उदाहरण के लिए, विषम उपकरणों के बीच वितरण तंत्र OpenCL के समान है?

जवाब है। यदि आप हुड के नीचे आते हैं, तो यह ओपनसीएल है। एसवाईसीएल के सभी फायदे और ताकत भाषा के फायदे और ताकत हैं, यानी कि फ्रंटएंड। सामने के छोर से अच्छा पुराना SPIRV आता है जो बैकएंड पर जाता है और वहां इसे ऑप्टिमाइज़ किया जाता है (अक्सर पहले से ही रनटाइम पर, यानी, यह JIT है) पहले से ही एक विशिष्ट वीडियो कार्ड के लिए उसी तरह से है जैसे OpenCL इसके लिए अनुकूलित होगा।

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

मेल से सवाल

लाइब्रेरी। जी हां, हम CUDA की बात नहीं कर रहे हैं। लेकिन हम जानते हैं कि CUDA डेवलपर्स के लिए बहुत उपयोगी पुस्तकालय हैं जो GPU पर उच्च प्रदर्शन के साथ काम करते हैं। OneAPI में कुछ लाइब्रेरी भी हैं, लेकिन, उदाहरण के लिए, IPP - oneAPI / OpenCL में छवियों के साथ काम करने के लिए कोई भी अभिलेखीय उपयोगी चीज़ नहीं है। क्या कुछ होगा, और इस मामले में CUDA से वनएपीआई में कैसे स्विच किया जाएगा?

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

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

और निश्चित रूप से, आईपीपी को नई वास्तविकताओं के लिए फिर से लिखा जाएगा। मुझे IPP से कोई लेना-देना नहीं है, लेकिन DPC ++ का उपयोग करना सामान्य ज्ञान है, और समझदार लोग वहां बैठे हैं।

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

मेल से सवाल

यदि हम नेरवाना और FPGA पर प्रशिक्षण और अनुमान तंत्रिका नेटवर्क एल्गोरिदम के प्रक्षेपण की तुलना करते हैं - प्रोग्रामिंग और परिणामी दक्षता में क्या अंतर हैं?

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

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

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

उदाहरण के लिए: "प्रोग्रामिंग और दक्षता में आसानी के दृष्टिकोण से मेरे कार्य% के लिए बेहतर क्या है - इस भाग को FPGA पर रखें, इस एक को नर्वाना पर छोड़ दें या इस भाग को दो में विभाजित करें, और GPU के लिए इस भाग को फिर से लिखें?"

और OneAPI के साथ पूरी कहानी - यह सिर्फ आपके लिए कहने के लिए है, "लंबे समय तक इसके बारे में क्यों सोचते हैं, मैं इसे अब जल्दी से कोशिश करूँगा, यह बहुत अच्छा है"।

अभी तक नहीं, आसान नहीं है। लेकिन वहाँ होगा।

---

विशेषज्ञ से आफ्टरवर्ड

आप सभी के सवालों के लिए धन्यवाद। यह संभव है और यहां तक ​​कि संभावित है कि मैं गलत था, गलत था और गलतियाँ कीं। ऐसा होता है, इंटरनेट पर लगातार कोई न कोई गलत होता है।

मुझे आशा है कि मैं विषम प्रोग्रामिंग और डीपीसी ++ में किसी को रुचि देने में सक्षम था। मैं सभी साइट sycl.tech की अनुशंसा करना चाहता हूं , जहां विश्व-प्रसिद्ध विशेषज्ञों (अंग्रेजी की आवश्यकता है) सहित रिपोर्ट के टन झूठ बोलते हैं

सभी को अच्छा!

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