ओपनसीएल का भविष्य?

22

OpenCL प्रोग्रामिंग प्रतिमान एक रॉयल्टी मुक्त होने का वादा करता है जो विषम कंप्यूटिंग के लिए मानक खोलता है। क्या हमें OpenCL के आधार पर सॉफ्टवेयर विकसित करने में अपना समय लगाना चाहिए? फायदे नुकसान?

hpc programming-paradigms

— एलन पी। इंग्सिग-करुप
स्रोत

CUDA में आप कठिन कोड कर सकते हैं। आपके पास C ++ कक्षाएं हैं, जहां OpenCL केवल संरचनाओं का समर्थन करता है। इसलिए CUDA थोड़ा और परिपक्व है। यदि आपको उन्नत सामान की आवश्यकता नहीं है, तो मैं OpenCL पर स्विच करूंगा।

— vanCompute

19

सवाल बहुत व्यापक है और वास्तव में इसका जवाब देने के लिए अस्पष्ट है। हालांकि, मैं वैज्ञानिक कंप्यूटिंग के दृष्टिकोण से ओपेनसीएल के खिलाफ एक उल्लेखनीय बिंदु देखता हूं, जिस पर शायद ही जोर दिया जाता है। अब तक, ओपनसीएल के लिए ओपन सोर्स, इन्फ्रास्ट्रक्चर लाइब्रेरी बनाने का कोई प्रयास नहीं किया गया है, जबकि CUDA में कई उत्कृष्ट विकल्प हैं:

मुझे विश्वास है कि यह OpenCL को वास्तव में नुकसान पहुंचाएगा क्योंकि गोद लेने के एक प्रमुख सूत्रधार उच्च गुणवत्ता, खुले पुस्तकालय हैं।

— मैट नेप्ले
स्रोत

3

दिलचस्प बिंदु; विशेष रूप से चूंकि CUDA संकलक को लाइसेंस अपने आप में बहुत खुला नहीं है (जो मैं इन लोगों को शीर्ष पर बनाता हूं), जबकि (जहां तक मैं लाइसेंस से बाहर कर सकता हूं) कुछ भी महत्वाकांक्षी प्रोग्रामर के रास्ते में खड़ा नहीं होगा जो पूरी तरह से खुला स्रोत OpenCL समाधान विकसित करना चाहता है ...

— Erik P.

2

@JackPoulson मैं भी OpenCL पुस्तकालयों की कमी से चकित है, लेकिन CUDA कारण स्पष्ट है। उन्होंने वास्तव में महान लोगों को काम पर रखने और उपयोगी पुस्तकालयों के विकास के पीछे संसाधन लगाए हैं।

— मैट नेप्ले

6

पुस्तकालय जन्म लेते हैं और तेजी से मरते हैं; मानकों लंबे और दर्दनाक रहते हैं।

— mbq

6

नहीं है ViennaCL , जो अनदेखी की जा करने के लिए नहीं है।

— एरन अहमदिया

4

@ कब्र वैज्ञानिक पुस्तकालयों में लंबे जीवनकाल और सोच के साथ-साथ अभ्यास पर एक बड़ा प्रभाव है। गवाह CHARMM, BLAS, RELAP, GEANT, इत्यादि

— मैट नॅप्ले

16

OpenCL बनाम क्या?

यदि प्रश्न OpenCL बनाम CUDA है, तो मुझे इस प्रश्न पर बहुत अधिक हाथ-लेखन दिखाई देता है, और यह मुझे पागल लगता है। इससे कोई फर्क नहीं पड़ता। ईमानदार। गुठली - जहां सभी कठिन सोच को जाना है - दो भाषाओं के बीच व्यावहारिक रूप से समान हैं; आप OpenCL और CUDA के बीच उछाल के लिए 99% काम करने के लिए अपने पसंदीदा संपादक के लिए मैक्रोज़ लिख सकते हैं। यह उस तरह से होना है; वे हार्डवेयर के अंततः समान प्रकार के निम्न-स्तरीय नियंत्रण हैं। एक बार जब आपको पता चला कि {OpenCL, CUDA} में अपनी महत्वपूर्ण गुठली कैसे लिखनी है, तो उन्हें {CUDA, OpenCL} में पोर्ट करना तुच्छ है।

बॉयलरप्लेट होस्ट कोड जिसे आपको लिखना है, समान है, लेकिन CUDA सरल मामलों को सरल रखता है। इसलिए हम CUDA को अपने केंद्र में पढ़ाते हैं; आप कर्नेल कोड लिखने में सीधे छलांग लगा सकते हैं, जबकि हमें अपने दिन भर के पाठ्यक्रम के 1-2 घंटे सिर्फ कर्नल लॉन्चिंग सामान को खोलने के लिए समझाने में बिताने होंगे।

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

यदि यह OpenCL बनाम निर्देश-आधारित दृष्टिकोण - OpenACC या HMPP या कुछ और है - जो संभवतः (उम्मीद है?) भविष्य में इस प्रकार के आर्किटेक्चर के प्रोग्रामिंग के अच्छे तरीके होने जा रहे हैं, जहां आप 90% प्रदर्शन प्राप्त कर सकते हैं। 10% काम। लेकिन कौन सी पसंद "जीत" दिखाई देगी और मैं अभी तक उन लोगों के साथ काम करने में बहुत समय बिताने की सलाह नहीं दूंगा।

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

यदि आप NVIDIA हार्डवेयर का उपयोग कर रहे हैं - और आप शायद कर रहे हैं - तो मैं आमतौर पर CUDA की सिफारिश करता हूं - पुस्तकालयों के बारे में मैट नेप्ले की बात मर चुकी है। यदि आप नहीं हैं, तो OpenCL।

1

आप कहते हैं कि एकमात्र अंतर गुठली है, और यह है कि गुठली समान हैं, लेकिन फिर कहते हैं कि आप CUDA का उपयोग करते हैं क्योंकि बॉयलरप्लेट सरल है। मैं मानता हूँ करने के लिए कि CUDA में बॉयलरप्लेट सरल है हो, लेकिन वहाँ पुस्तकालयों कि OpenCL बॉयलरप्लेट, जैसे के साथ मदद कर सकते हैं code.google.com/p/clutil और github.com/hughperkins/OpenCLHelper (अस्वीकरण: OpenCLHelper अपने ही है)

— ह्यूग पर्किन्स

7

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

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

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

इतना ही नहीं, लेकिन यदि आप इसे अपने दृष्टिकोण से बेहतर बनाते हैं, तो यह दूसरों के लिए बेहतर बना सकता है, उन्हें अपनी खुद की वृद्धि प्रस्तुत करने के लिए प्रोत्साहित करता है और अंततः सभी के लिए सॉफ्टवेयर को बेहतर बनाता है।

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

— मार्क बूथ
स्रोत

6

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

भले ही CUDA और OpenCL की सुविधाओं का मुख्य सेट लगभग समान हो (जैसा कि @JonathanDursi अच्छी तरह से बताया गया है), यदि मूल डेवलपर कोड को परिवर्तित करने के कार्य के साथ असाइन नहीं किया गया है, तो संपूर्ण पोर्टिंग प्रोजेक्ट को काफी समय लग सकता है।

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

इस समय (2012 की शुरुआत में), भयानक पुस्तकालय जो @MattKnepley लिंक बंद स्रोत या उपयोग टेम्पलेट हैं, इसलिए वे कम से कम औसत समय में, NVIDIA के अलावा अन्य हार्डवेयर के लिए उपलब्ध नहीं होंगे।

किसी के लिए जो जीपीयू-कंप्यूटिंग सीख रहा है, मैं कहूंगा कि ओपनसीएल सी काफी मुश्किल हो सकता है, क्योंकि बहुत सारे विवरण हैं जो सीखने वाले को मूल विचारों से विचलित करते हैं, जबकि सीयूडीए सरल और सीधे आगे है। हालाँकि, ऐसे उपकरण हैं जो OpenCL को सीखने के लिए और अधिक सरल बनाते हैं और PyOpenCL (opencl के लिए अजगर आवरण) की तरह उपयोग करते हैं जो कि सभी अजगर को OpenCL (ध्यान दें कि PyCUDA भी है) लाता है। उदाहरण के लिए, दो सरणियों को जोड़ने के लिए PyOpenCL डेमो सिर्फ 25 लाइनों के अंतर्गत है और इसमें शामिल हैं: होस्ट और डिवाइस पर सरणियों का निर्माण, डेटा स्थानान्तरण, संदर्भ और कतार का निर्माण, कर्नेल, कर्नेल का निर्माण और निष्पादन कैसे करें। GPU से परिणाम प्राप्त करना और उनकी तुलना खस्ता के खिलाफ करना (नीचे लिंक देखें)।

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

अनुभवी gpu- प्रोग्रामर्स के लिए, यहां मैं @JonathanDursi से सहमत हूं, CUDA और OpenCL मौलिक रूप से समान हैं और वास्तव में कोई मेयर मतभेद नहीं हैं। इसके अलावा, GPUs के लिए एक कुशल एल्गोरिथ्म विकसित करने की कड़ी मेहनत बहुत अधिक भाषा स्वतंत्र है, और विक्रेताओं से OpenCL समर्थन और दस्तावेज़ीकरण अब 2 साल पहले की तुलना में बहुत अधिक परिपक्व है। एकमात्र बिंदु जो अभी भी एक अंतर बनाता है, वह यह है कि NVIDIA वास्तव में CUDA समुदाय को अपने समर्थन के साथ कुछ महान काम कर रहा है।

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

— fcruz
स्रोत

5

मुझे लगता है कि ओपनसीएल वर्तमान में एक "चैंपियन" की कमी से पीड़ित है। उदाहरण के लिए, यदि आप अभी (12/16/2011) एनवीआईडीआईए साइट पर जाते हैं, तो आपको जीपीयू कंप्यूटिंग के वैज्ञानिक / औद्योगिक पक्ष, और ~ 1 / पर ध्यान केंद्रित करते हुए स्प्लैश पेज पर कई "केन बर्न्स इफ़ेक्ट" स्टाइल शॉट्स मिले हैं। आपके नेविगेशन विकल्पों में से 4 आपको उन चीजों की ओर इंगित करते हैं जो संभवतः CUDA पर समाप्त हो जाएंगे। "GPU कंप्यूटिंग" सर्वर और वर्कस्टेशन बेचने वाले निर्माता NVIDIA समाधान बेच रहे हैं।

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

— Fomite
स्रोत

4

सबसे महत्वपूर्ण कारक यह है कि CUDA केवल NVIDIA हार्डवेयर द्वारा समर्थित रहेगा।

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

— MBq
स्रोत

बिल्कुल साफ नहीं। निश्चित रूप से मालिकाना मानक हैं जो कई लोगों द्वारा उन्हें अपनाने के बाद खुले थे।

— मैट नेप्ले

@MattKnepley कृपया, यहां तक कि NVIDA भी CUDA को एक मानक के रूप में बाध्य करने की कोशिश नहीं कर रहा है; यह उल्लेख करने के लिए कि यदि वे चाहेंगे भी, तो वे मूल रूप से ओपनसीएल के समान कुछ के साथ समाप्त हो जाएंगे।

— mbq

1

वास्तव में, यह विपरीत होने की संभावना होगी। ओपनसीएल CUDA से सभी अच्छी चीजों को अपनाना समाप्त कर देगा (जिनमें से अधिकांश पहले से ही वहां हैं, आपको क्या लगता है कि यह कहां से आया है?) और अभी वहां अधिक आपत्तिजनक सामान से छुटकारा पा रहा है।

— मैट नेप्ले