SIMD प्रोग्रामिंग कोड बेस की रखरखाव लागत

14

सवाल:

सॉफ्टवेयर उद्योग की सर्वसम्मति यह है कि स्वच्छ और सरल कोड कोड आधार की दीर्घकालिक व्यवहार्यता और इसके स्वामित्व वाले संगठन के लिए मौलिक है। इन गुणों के कारण रखरखाव लागत कम हो जाती है और कोड बेस के जारी रहने की संभावना बढ़ जाती है।

हालांकि, SIMD कोड सामान्य एप्लिकेशन कोड से अलग है, और मैं जानना चाहूंगा कि क्या विशेष रूप से SIMD कोड पर लागू होने वाले स्वच्छ और सरल कोड के बारे में समान सहमति है।

मेरे सवाल का बैकग्राउंड।

मैं विभिन्न छवि प्रसंस्करण और विश्लेषण कार्यों के लिए बहुत सारे SIMD (एकल-निर्देश, एकाधिक डेटा) कोड लिखता हूं। हाल ही में मुझे इन कार्यों की एक छोटी संख्या को एक वास्तुकला (SSE2) से दूसरे (ARM NEON) में पोर्ट करना था।

कोड सिकुड़ते लिपटे सॉफ़्टवेयर के लिए लिखा गया है, इसलिए यह अप्रतिबंधित पुनर्वितरण अधिकारों जैसे MATLAB के बिना मालिकाना भाषाओं पर निर्भर नहीं कर सकता है।

विशिष्ट कोड संरचना का एक उदाहरण:

सभी मेमोरी, बफर और आजीवन प्रबंधन के लिए OpenCV के मैट्रिक्स प्रकार ( Mat) का उपयोग करना ।
इनपुट तर्कों के आकार (आयामों) की जांच करने के बाद, पिक्सल की प्रत्येक पंक्ति के आरंभिक पते पर संकेत ले जाया जाता है।
पिक्सेल गणना, और प्रत्येक इनपुट मैट्रिक्स से पिक्सेल की प्रत्येक पंक्ति के शुरुआती पते कुछ निम्न-स्तरीय C ++ फ़ंक्शन में पारित किए जाते हैं।
ये निम्न स्तर के C ++ फ़ंक्शंस में SIMD इंट्रेंसिक्स ( इंटेल आर्किटेक्चर , और ARM नीयन के लिए ) का उपयोग किया जाता है, जो कच्चे सूचक पते से लोड होता है और बचत करता है।
इन निम्न-स्तरीय C ++ फ़ंक्शन के लक्षण:
- विशिष्ट रूप से एक-आयामी (लगातार स्मृति में)
- मेमोरी आवंटन से संबंधित नहीं है।
  (प्रत्येक आवंटन, जिसमें अस्थायी कर्मचारी भी शामिल हैं, को OpenCV सुविधाओं का उपयोग करके बाहरी कोड द्वारा नियंत्रित किया जाता है।)
- प्रतीकों की नाम लंबाई की सीमा (आंतरिक, चर नाम, आदि) लगभग 10 - 20 वर्ण हैं, जो काफी अधिक है।
  (टेक्नो-बेबीबल की तरह पढ़ता है।)
- SIMD चर का पुन: उपयोग हतोत्साहित किया जाता है क्योंकि कंपाइलर सही ढंग से पार्सिंग कोड में काफी छोटी हैं जो "एकल-असाइनमेंट" कोडिंग शैली में नहीं लिखा गया है।
  (मैंने कई संकलक बग रिपोर्ट दर्ज की हैं।)

SIMD प्रोग्रामिंग के किन पहलुओं के कारण चर्चा सामान्य मामले से भिन्न होगी? या, SIMD अलग क्यों है?

प्रारंभिक विकास लागत के संदर्भ में

यह सर्वविदित है कि अच्छे प्रदर्शन के साथ C ++ SIMD कोड की प्रारंभिक विकास लागत लापरवाही से लिखे C ++ कोड की तुलना में लगभग 10x - 100x (विस्तृत मार्जिन के साथ) है ।
जैसा कि प्रदर्शन बनाम पढ़ने योग्य / क्लीनर कोड के बीच चयन के जवाबों में उल्लेख किया गया है ? , अधिकांश कोड (लापरवाही से लिखे गए कोड और SIMD कोड सहित) शुरू में न तो साफ है और न ही तेज है ।
कोड प्रदर्शन (स्केलर और SIMD कोड दोनों) में विकासवादी सुधार को हतोत्साहित किया जाता है (क्योंकि इसे एक तरह के सॉफ्टवेयर rework के रूप में देखा जाता है ), और लागत और लाभ को ट्रैक नहीं किया जाता है।

प्रवृत्ति के संदर्भ में
(जैसे पेरेटो सिद्धांत, उर्फ 80-20 नियम )

भले ही छवि प्रसंस्करण में एक सॉफ्टवेयर सिस्टम (कोड आकार और कार्यक्षमता दोनों में) का 20% शामिल है, छवि प्रसंस्करण तुलनात्मक रूप से धीमा है (जब खर्च किए गए सीपीयू समय के प्रतिशत के रूप में देखा जाता है), 80% से अधिक समय ले रहा है।
- यह डेटा आकार प्रभाव के कारण है: मेगाबाइट में एक विशिष्ट छवि आकार मापा जाता है, जबकि गैर-छवि डेटा का विशिष्ट आकार किलोबाइट में मापा जाता है।
इमेज प्रोसेसिंग कोड के भीतर, एक SIMD प्रोग्रामर को C ++ कोड में लूप संरचना की पहचान करके हॉटस्पॉट्स को शामिल करने वाले 20% कोड को स्वचालित रूप से पहचानने के लिए प्रशिक्षित किया जाता है। इस प्रकार, एक SIMD प्रोग्रामर के दृष्टिकोण से, "कोड जो मायने रखता है" का 100% प्रदर्शन अड़चन है।
अक्सर एक छवि प्रसंस्करण प्रणाली में, कई हॉटस्पॉट मौजूद होते हैं और समय के तुलनीय अनुपात लेते हैं। उदाहरण के लिए, कुल समय के लिए प्रत्येक में 20 हॉटस्पॉट हो सकते हैं (20%, 18%, 16%, 14%, 12%)। उच्च प्रदर्शन लाभ प्राप्त करने के लिए, सभी हॉटस्पॉट को SIMD में फिर से लिखना होगा।
- इसे गुब्बारे-पॉपिंग नियम के रूप में संक्षेपित किया गया है : एक गुब्बारे को दो बार पॉप नहीं किया जा सकता है।
- मान लीजिए कि कुछ गुब्बारे हैं, उनमें से 5 को कहें। उन्हें अलग करने का एकमात्र तरीका उन्हें एक-एक करके पॉप करना है।
- एक बार पहला गुब्बारा पॉप होने के बाद, शेष 4 गुब्बारे अब कुल निष्पादन समय का उच्च प्रतिशत शामिल करते हैं।
- आगे लाभ कमाने के लिए, एक और गुब्बारा पॉप करना चाहिए।
  (यह अनुकूलन के 80-20 नियम की अवहेलना है : 20% सबसे कम-फांसी वाले फलों को चुनने के बाद एक अच्छा आर्थिक परिणाम प्राप्त किया जा सकता है।)

पठनीयता और रखरखाव के संदर्भ में

SIMD कोड को पढ़ना मुश्किल है।
- यह तब भी सच है, जब कोई हर सॉफ्टवेयर इंजीनियरिंग का सबसे अच्छा अभ्यास करता है, जैसे कि नामकरण, एनकैप्सुलेशन, कांस्टीट्यूशन (और साइड-इफेक्ट्स को स्पष्ट करना), फ़ंक्शन अपघटन आदि।
- अनुभवी SIMD प्रोग्रामर के लिए भी यह सही है।
Optimal SIMD कोड अपने समकक्ष C ++ प्रोटोटाइप कोड की तुलना में बहुत विपरीत है, (टिप्पणी देखें) ।
- SIMD कोड को गर्भपात करने के कई तरीके हैं, लेकिन 10 प्रयासों में से केवल 1 ही तेजी से परिणाम प्राप्त करेगा।
- (यह है कि उच्च विकास लागत का औचित्य साबित करने के लिए 4x-10x प्रदर्शन लाभ की धुनों में। व्यवहार में उच्चतर लाभ भी देखा गया है।)

(टिप्पणी)
यह एमआईटी हैलाइड परियोजना का मुख्य शोध है- कागज के शीर्षक शब्दशः उद्धृत करते हुए:

"इमेज प्रोसेसिंग पाइपलाइनों के आसान अनुकूलन के लिए शेड्यूल से एल्गोरिदम को डिकूप्ल करना"

आगे की प्रयोज्यता के संदर्भ में

SIMD कोड कड़ाई से एकल वास्तुकला से बंधा है। प्रत्येक नए आर्किटेक्चर (या SIMD रजिस्टरों में से प्रत्येक को चौड़ा करना) को फिर से लिखना पड़ता है।
सॉफ्टवेयर विकास के बहुमत के विपरीत, SIMD कोड के प्रत्येक टुकड़े को आमतौर पर एक ही उद्देश्य के लिए लिखा जाता है जो कभी नहीं बदलता है।
(अन्य आर्किटेक्चर के लिए पोर्टिंग के अपवाद के साथ।)
कुछ आर्किटेक्चर पूर्ण पिछड़ी संगतता (इंटेल) को बनाए रखते हैं; कुछ तुच्छ राशि से कम हो जाते हैं (ARM AArch64, के vtblसाथ प्रतिस्थापित vtblq) लेकिन जो कुछ कोड को संकलित करने में विफल होने के लिए पर्याप्त है।

कौशल और प्रशिक्षण के संदर्भ में

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

शुद्धता और दोष-संबंधी लागतों के संदर्भ में

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

विघटनकारी नवाचारों के संदर्भ में

शिक्षाविदों से कई समाधान प्रस्तावित किए गए हैं, लेकिन कुछ व्यापक व्यावसायिक उपयोग देख रहे हैं।
- MIT हैलाइड
- स्टैनफोर्ड डार्करूम
- NT2 (न्यूमेरिकल टेम्पलेट टूलबॉक्स) और संबंधित Boost.SIMD
व्यापक व्यावसायिक उपयोग वाले पुस्तकालय भारी सिमड-सक्षम नहीं लगते हैं।
- ओपन-सोर्स लाइब्रेरी सिमड के लिए गुनगुना लगती हैं।
  - संस्करण 2.4.9 के रूप में बड़ी संख्या में OpenCV API फ़ंक्शंस की रूपरेखा तैयार करने के बाद हाल ही में मेरा यह पहला अवलोकन है।
  - कई अन्य इमेज प्रोसेसिंग लाइब्रेरियों को मैंने प्रोफिल्ड किया है जो कि SIMD का भारी उपयोग नहीं करते हैं, या वे सच्चे हॉटस्पॉट्स को याद करते हैं।
- वाणिज्यिक पुस्तकालय पूरी तरह से SIMD से बचते हैं।
  - कुछ मामलों में, मैंने बाद के संस्करण में पहले के संस्करण में SIMD- अनुकूलित कोड को पुनः प्राप्त करने वाली छवि प्रसंस्करण पुस्तकालयों को बाद के संस्करण में गैर-SIMD कोड में देखा है, जिसके परिणामस्वरूप गंभीर प्रदर्शन प्रतिगमन हुए हैं।
    (विक्रेता की प्रतिक्रिया है कि संकलक कीड़ों से बचना आवश्यक था।)

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

हालांकि, यह जवाब "समय से पहले अनुकूलन" के दृष्टिकोण के लिए "तुष्टिकरण" के लिए बहुत अधिक है, यानी दृष्टिकोण के लिए:

सभी ऑप्टिमाइज़ेशन परिभाषा द्वारा समय से पहले (या प्रकृति द्वारा अल्पकालिक ), और हैं
दीर्घकालिक अनुकूलन का एकमात्र अनुकूलन सादगी की ओर है।

लेकिन इस तरह के दृष्टिकोण इस एसीएम लेख में लड़े जाते हैं ।

यह सब मुझे पूछने के लिए प्रेरित करता है:
SIMD कोड सामान्य एप्लिकेशन कोड से अलग है, और मैं जानना चाहूंगा कि क्या SIMD कोड के लिए स्वच्छ और सरल कोड के मूल्य के बारे में समान उद्योग सहमति है।

performance optimization estimation

— rwong
स्रोत

2

क्या प्रदर्शन की आवश्यकताएं हैं? क्या आप SIMD का उपयोग किए बिना अपनी प्रदर्शन आवश्यकताओं को पूरा कर सकते हैं? अगर नहीं तो सवाल मूट का है।

— चार्ल्स ई। ग्रांट

4

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

3

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

— ब्रेंडन

2

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

— gnat

2

मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह एक वैचारिक प्रोग्रामिंग समस्या नहीं है जैसा कि सहायता केंद्र में वर्णित है ।

— डुर्रोन 597

6

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

कोड "उच्च स्तरीय कोड" की तुलना में विकसित करने के लिए 10x से 100x लेता है
यह एक विशिष्ट वास्तुकला से बंधा है
कोड कभी भी "साफ" नहीं होता है और न ही रिफ्लेक्टर के लिए आसान होता है
आपको इसे लिखने और बनाए रखने के लिए विशेषज्ञों की आवश्यकता है
डिबगिंग और रखरखाव कठिन है, वास्तव में कठिन विकसित करना

किसी भी तरह से SIMD के लिए "विशेष" नहीं हैं - ये बिंदु किसी भी प्रकार की विधानसभा भाषा के लिए सही हैं, और वे सभी "उद्योग आम सहमति" हैं। सॉफ्टवेयर उद्योग में निष्कर्ष भी बहुत हद तक असेंबलर के लिए ही है:

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

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

जैसा कि आपने पहले ही अपने प्रश्न में वर्णित किया है, वर्तमान पुस्तकालयों के साथ एक गुणवत्ता की समस्या भी मौजूद है। इसलिए IMHO सबसे अच्छी उम्मीद कर सकता है कि अगले वर्षों में कंपाइलरों और पुस्तकालयों की गुणवत्ता बढ़ेगी, हो सकता है कि SIMD हार्डवेयर को और अधिक "कंपाइलर फ्रेंडली" बनने के लिए बदलना पड़े, हो सकता है कि विशेष प्रोग्रामिंग भाषाएं आसान वैश्वीकरण का समर्थन कर रही हों (जैसे हैलिड, जो आपने दो बार उल्लेख किया) अधिक लोकप्रिय हो जाएगा (यह पहले से ही फोरट्रान की ताकत नहीं है?)। इसके अनुसार,विकिपीडिया के , 15 से 20 साल पहले SIMD "एक बड़े पैमाने पर उत्पाद" बन गया (और जब मैं डॉक्स की सही व्याख्या करता हूं तो हैलीड 3 साल से कम है)। परिपक्व होने के लिए आवश्यक "क्लासिक" विधानसभा भाषा के लिए समय कंपाइलरों से इसकी तुलना करें। इस विकिपीडिया लेख के अनुसारजब तक कंपाइलर्स मानव विशेषज्ञों (गैर-समानांतर मशीन कोड बनाने में) के प्रदर्शन से अधिक नहीं हो गए, तब तक लगभग 30 साल (~ 1970 से 1990 के दशक तक) में लग गए। इसलिए हमें SIMD- सक्षम कंपाइलर के होने तक बस 10 से 15 साल और इंतजार करना पड़ सकता है।

— डॉक्टर ब्राउन
स्रोत

विकिपीडिया लेख के मेरे पढ़ने के अनुसार , एक सामान्य उद्योग सर्वसम्मति प्रतीत होती है कि निम्न स्तर पर अनुकूलित कोड को "कई तकनीकी विवरणों के कारण उपयोग करना मुश्किल माना जाता है, जिसे याद रखा जाना चाहिए"

— gnat

@gnat: हाँ, बिल्कुल, लेकिन मुझे लगता है कि अगर मैं इसे अपने जवाब में जोड़ दूं, तो मुझे ओपी द्वारा पहले ही उल्लेखित एक दर्जन अन्य चीजों को अपने बहुत लंबे सवाल में दूसरे शब्दों में कहना चाहिए।

— Doc Brown

सहमत हूँ, अपने जवाब में विश्लेषण काफी अच्छा लग रहा है के रूप में, कि संदर्भ जोड़ने यह "अधिक भार" का एक जोखिम ले जाएगा

— कुटकी

4

मेरे संगठन ने इस सटीक समस्या से निपटा है। हमारे उत्पाद वीडियो स्पेस में हैं, लेकिन हमारे द्वारा लिखे गए अधिकांश कोड इमेज प्रोसेसिंग हैं जो अभी भी छवियों के लिए काम करेंगे।

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

हम तब OpenGL छायांकन भाषा (glsl) में अपना कोड लिखते हैं। यह स्केलर कोड, SSE, SSE2, SSE3, AVX, नियॉन और निश्चित रूप से वास्तविक ग्लोसल के लिए संकलित हो जाता है। जब हमें एक नए प्लेटफ़ॉर्म का समर्थन करने की आवश्यकता होती है, तो हम कंपाइलर को उस प्लेटफ़ॉर्म के आउटपुट कोड में अपडेट करते हैं।

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

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

— user1118321
स्रोत

यह लगता है 🔥🔥! क्या यह उत्पाद आप बेचते हैं या स्टैंड-अलोन उपलब्ध करते हैं? (इसके अलावा, 'एवीसी' = एवीएक्स है?)

— अहमद फसीह

क्षमा करें, हाँ, मेरा मतलब था AVX (मैं इसे ठीक करूँगा।)। वर्तमान में हम संकलक को स्टैंड-अलोन उत्पाद के रूप में नहीं बेचते हैं, हालांकि यह भविष्य में हो सकता है।

— user1118321

कोई मजाक नहीं, यह वास्तव में साफ लगता है। निकटतम चीज जो मैंने इस तरह से देखी है कि कैसे CUDA संकलक "सीरियल" प्रोग्राम बनाने में सक्षम हुआ करता था जो CPU पर डिबगिंग के लिए चलते हैं - हमें उम्मीद थी कि बहु-थ्रेडेड और SIMD CPU कोड लिखने के लिए एक तरह से सामान्य हो जाएगा, लेकिन अफसोस। अगली निकटतम चीज़ जो मैं सोच सकता हूँ, वह है ओपनसीएल- क्या आप लोगों ने ओपनसीएल का मूल्यांकन किया था और इसे अपने जीएसएल-टू-ऑल कंपाइलर से नीचा पाया?

— अहमद फसीह

1

जब हमने शुरुआत की थी तब ओपनसीएल मौजूद नहीं था, मुझे नहीं लगता। (या अगर यह किया, यह काफी नया था।) तो यह वास्तव में समीकरण में नहीं आया था।

— user1118321

0

यदि आप उच्च-स्तरीय भाषा का उपयोग करने पर विचार करते हैं, तो यह बहुत अधिक रखरखाव ओवरहेड जोड़ने के लिए प्रतीत नहीं होता है:

Vector<float> values = GetValues();
Vector<float> increment = GetIncrement();

// Perform addition as a vector operation:
List<float> result = (values + increment).ToList();

बनाम

List<float> values = GetValues();
List<float> increment = GetIncrement();

// Perform addition as a monadic sequence operation:
List<float> result = values.Zip(increment, (v, i) => v + i).ToList();

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

http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-married.aspx

http://blogs.msdn.com/b/dotnet/archive/2014/05/13/update-to-simd-support.aspx

— मांद
स्रोत

मेरे पढ़ने के अनुसार, बाहरी पुस्तकालयों का उपयोग करने का विकल्प पहले से ही जांचकर्ता द्वारा पूछा और संबोधित किया गया है: "व्यापक व्यावसायिक उपयोग वाले पुस्तकालय भारी SIMD- सक्षम नहीं लगते हैं ..."

— gnat

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

— डेन

1

मेरी समझ में, ओपी पूछ रहा है कि क्या व्यापक व्यावसायिक उपयोग के साथ समाधान मौजूद हैं। हालांकि मैं आपके संकेत की सराहना करता हूं (हो सकता है कि मैं यहां एक परियोजना के लिए काम का उपयोग कर सकता हूं), मैं जो देखता हूं कि रियूजिट "व्यापक रूप से स्वीकृत उद्योग मानक" को दूर करने से दूर है।

— Doc Brown

@DocBrown हो सकता है, लेकिन उनका वास्तविक प्रश्न अधिक सामान्य होने के लिए तैयार है: "... SIMD कोड के लिए स्वच्छ और सरल कोड के मूल्य के बारे में उद्योग की सहमति ..."। मुझे संदेह है कि कोई भी (आधिकारिक) सर्वसम्मति है, लेकिन मैं प्रस्तुत करता हूं कि उच्च-स्तरीय भाषाएं "सामान्य" और SIMD कोड के बीच के अंतर को कम कर सकती हैं, ठीक वैसे ही जैसे C ++ आप असेंबली के बारे में भूल जाते हैं, इस प्रकार रखरखाव की लागत को कम करते हैं।

— Den

-1

मैंने पूर्व में असेंबली प्रोग्रामिंग की है, हाल ही में SIMD प्रोग्रामिंग नहीं।

क्या आपने इंटेल जैसे SIMD- अवगत संकलक का उपयोग करने पर विचार किया है? है vectorization के लिए एक गाइड इंटेल सी ++ संकलनकर्ता साथ दिलचस्प?

"गुब्बारे-पॉपिंग" जैसी आपकी कई टिप्पणियाँ एक संकलक का उपयोग करने का सुझाव देती हैं (यदि आपके पास एक भी हॉट-स्पॉट नहीं है तो लाभ प्राप्त करने के लिए)।

— ChrisW
स्रोत

मेरे पढ़ने के अनुसार, इस दृष्टिकोण को पूछने वाले द्वारा कोशिश की गई थी, प्रश्न में संकलक कीड़े / दोष का उल्लेख देखें

— gnat

ओपी ने यह नहीं कहा कि क्या वे इंटेल कंपाइलर की कोशिश करेंगे , जो इस प्रोग्रामर का विषय भी है । अधिकांश लोगों ने इसे आजमाया नहीं है। यह सभी के लिए नहीं है; लेकिन यह ओपी के व्यवसाय / प्रश्न (कम कोडिंग / डिजाइन / रखरखाव लागत के लिए बेहतर प्रदर्शन) के अनुरूप हो सकता है।

— क्रिस डब्ल्यूडब्ल्यू

प्रश्न में मैंने जो पढ़ा है वह अच्छी तरह से बताता है कि प्रश्नकर्ता इंटेल और अन्य आर्किटेक्चर के लिए कंपाइलर्स के बारे में जानते हैं: "कुछ आर्किटेक्चर सही पिछड़ेपन (इंटेल) को बनाए रखते हैं; कुछ कम हो जाते हैं ..."

— gnat

उस वाक्य में "इंटेल" का अर्थ इंटेल-द-चिप-डिजाइनर है, न कि इंटेल-द-कंपाइलर-लेखक।

— क्रिस डब्ल्यूडब्ल्यू