क्या यह SIMD का उपयोग करके C ++ में इमेज प्रोसेसिंग को अनुकूलित करने के लायक है?

SIMD और इमेज प्रोसेसिंग

छवि प्रसंस्करण (यहां हम जानबूझकर खुद को केवल बिटमैप छवियों तक सीमित करते हैं और वेक्टर छवियों की एक विस्तृत श्रेणी को छोड़ देते हैं), एक नियम के रूप में, सरल ऑपरेशन का एक सेट है जो छवि में प्रत्येक बिंदु पर लागू होता है। यदि हम ध्यान में रखते हैं कि रंग चैनल जो छवि बिंदु (पिक्सेल) बनाते हैं, आमतौर पर छोटे आयाम के पूर्णांक के रूप में दर्शाए जाते हैं, तो छवि प्रसंस्करण 1-2 बाइट पूर्णांक पर एक ही प्रकार के संचालन की एक बड़ी संख्या में कम हो जाता है।


सामान्य-प्रयोजन प्रोसेसर निर्देशों का उपयोग करके ऐसे ऑपरेशन करना पूरी तरह से प्रभावी नहीं है, क्योंकि वे 4-8 बाइट संख्या के प्रसंस्करण के लिए अनुकूलित हैं। वास्तव में, जब 1 बाइट संख्या के साथ काम करते हैं, तो उनकी प्रभावशीलता 4-8 गुना कम हो जाएगी। प्रोसेसर निर्माताओं ने लंबे समय तक ऐसे डेटा के साथ काम करते समय उत्पादकता बढ़ाने के लिए एक काफी प्रभावी समाधान का प्रस्ताव दिया है - SIMD (एकल निर्देश, एकाधिक डेटा) - वेक्टर निर्देशों के सेट जो आपको एक ऑपरेशन में बड़ी मात्रा में डेटा संसाधित करने की अनुमति देते हैं। यदि हम x86 प्लेटफॉर्म पर विचार करते हैं, तो उस पर बड़ी संख्या में SIMD एक्सटेंशन हैं: MMX, 3DNow, SSE, SSE2, SSE3, SSEE3, SSE4.1, SSE4.2, AVX और AVX2। इनमें से अधिकांश एक्सटेंशन वास्तविक संख्याओं के वेक्टर प्रसंस्करण के लिए हैं। यदि हम वेक्टर पूर्णांक निर्देशों को स्पर्श करते हैं, तो हम MMX, SSE2 और AVX2 कमांड के सेट को अलग कर सकते हैं, जिसमें क्रमशः 8, 16 और 32-बाइट वैक्टर के साथ काम करने के लिए ऑपरेशन होते हैं। MMX एक्सटेंशन पहली बार 1997 में पेंटियम MMX प्रोसेसर में दिखाई दिया था और वर्तमान में ऐतिहासिक हित में है, क्योंकि सभी आधुनिक x86 प्रोसेसर अधिक उन्नत SSE2 निर्देश सेट का समर्थन करते हैं, जो पहली बार 2000 में जारी इंटेल पेंटियम 4 प्रोसेसर में पेश किया गया था। हालांकि, जीवन अभी भी खड़ा नहीं है, और 2013 में AVX2 निर्देशों के समर्थन के साथ प्रोसेसर की चौथी पीढ़ी के iCore परिवार को जारी किया गया था, जो जल्द ही व्यापक हो जाएगा।

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

आकर्षण आते हैं

1. SIMD निर्देशों के उपयोग से एक साथ स्रोत डेटा के कई सेटों की एक साथ प्रसंस्करण की अनुमति मिलती है, जिससे एल्गोरिदम के समग्र समय में काफी कमी आती है।
2. विस्तारित निर्देश सेट में विशेष कमांड होते हैं (उदाहरण के लिए, संख्याओं की एक जोड़ी के लिए औसत या अधिकतम संख्या, संतृप्ति के साथ जोड़ना या घटाना), जो कई सामान्य-उद्देश्य निर्देशों को प्रतिस्थापित करते हैं। इन आदेशों का उपयोग गति में एक बहुत ही महत्वपूर्ण लाभ दे सकता है।
3. SIMD प्रोसेसर एक्सटेंशन का उपयोग करने के लिए, एक आम गलत धारणा के विपरीत, कोडांतरक का उपयोग करना आवश्यक नहीं है। सभी आधुनिक सी ++ संकलक तथाकथित आंतरिक - कार्यों का समर्थन करते हैं जो संकलक सीपीयू के लिए सीधे कमांड में अनुवाद करता है। इसलिए, SIMD का उपयोग करते समय, आप पूरी तरह से परिचित IDE में C / C ++ सिंटैक्स के ढांचे के भीतर रह सकते हैं।

विपक्ष

1. प्रोसेसर एक्सटेंशन को शामिल करने वाले कोड की बहुमुखी प्रतिभा को खोना। दरअसल, प्रोसेसर आर्किटेक्चर की एक बड़ी संख्या है, जिनमें से प्रत्येक में वेक्टर निर्देशों का अपना सेट हो सकता है (या नहीं) हो सकता है। इसलिए, या तो हमें अपने कार्यक्रम की प्रयोज्यता को किसी विशेष वास्तुकला तक सीमित करना होगा, या हमारे द्वारा आवश्यक प्रत्येक आर्किटेक्चर के लिए एल्गोरिथम के कई कार्यान्वयन लिखना होगा।
2. इनपुट और आउटपुट डेटा को एक क्रमबद्ध तरीके से याद रखना चाहिए (अधिमानतः क्रमिक रूप से, हालांकि हर दूसरे या हर चौथे तत्व को काफी कुशलता से निकालना संभव है)। इनपुट और आउटपुट डेटा को सघन करता है, कम पुन: संचालन संचालन हमें करना होगा और हमारे एल्गोरिथ्म को जितना अधिक कुशल होगा। यह आवश्यकता हमें डेटा संग्रहीत करने के तरीकों पर पुनर्विचार करने के लिए मजबूर करती है, उदाहरण के लिए, अलग-अलग रंग के विमानों के एक सेट के रूप में एक रंगीन छवि को संग्रहीत करने के लिए, और प्रत्येक बिंदु के लिए वैकल्पिक चैनलों के साथ एक रंग विमान में नहीं (जैसा कि बीजीआर -24 में है)।
3. यह वांछनीय है कि इनपुट और आउटपुट डेटा को मेमोरी में संरेखित किया जाए (SSE2 के लिए 16 बाइट सीमा, AVX2 के लिए 32 बाइट सीमा), इसलिए संरेखित डेटा को पढ़ना और सहेजना बहुत तेज है। यदि हम इनपुट और आउटपुट डेटा के निर्माण को नियंत्रित करते हैं, तो उनका संरेखण विशेष मेमोरी आवंटनकर्ताओं का उपयोग करके प्राप्त किया जाता है। अन्यथा, हमें या तो एल्गोरिदम की गति के नुकसान को स्वीकार करना चाहिए, या संरेखित किए गए डेटा के संरेखित न होने के मामले में एल्गोरिथ्म के दो संस्करण लिखना चाहिए।
4. यदि, सामान्य-उद्देश्य वाले रजिस्टरों में छवियों को संसाधित करते समय, गणना प्रक्रिया में संख्याओं के अतिप्रवाह की समस्या लगभग कभी सामने नहीं आती है (हम केवल मानक इंट प्रकार का उपयोग करते हैं, जो 8 बिट डेटा के साथ काम करते समय अतिप्रवाह करने की संभावना नहीं है), तो जब वेक्टर निर्देशों का उपयोग करके प्रसंस्करण करते हैं, तो आपको लगातार इस समस्या को बनाए रखने की आवश्यकता है। नियंत्रण में है। यदि, उदाहरण के लिए, एल्गोरिथ्म में, गणना प्रक्रिया के दौरान 8-बिट डेटा का अतिप्रवाह संभव है, तो हमें उन्हें 16-बिट में बदलना होगा, गणना करना और उलटा रूपांतरण करना होगा। बेशक, इसके लिए वैक्टर पैकिंग और अनपैकिंग के लिए विशेष वेक्टर निर्देश हैं, लेकिन यह सब एल्गोरिथ्म को धीमा कर देता है, साथ ही तथ्य यह है कि वेक्टर एक बार में 16-बिट डेटा प्रक्रिया दो बार कम डेटा की तुलना में 8-बिट की तुलना में है।
5. वेक्टर निर्देशों को संसाधित करते समय, प्रत्येक तत्व के लिए कमांड के सशर्त निष्पादन की कोई संभावना नहीं है। कुछ मामलों में, सशर्त कूदता का अनुकरण किया जा सकता है, जिसके लिए कोड की दोनों शाखाओं को निष्पादित करना आवश्यक है, और फिर उनके काम के परिणामों को संयोजित करें। यह स्वाभाविक रूप से एल्गोरिथ्म के प्रदर्शन को प्रभावित करता है, और यदि कोड सशर्त संक्रमण से संतृप्त होता है, तो SIMD अनुकूलन में अर्थ खो जाता है।
6. छवियों को संसाधित करते समय, अंक जो सीमाओं पर स्थित होते हैं, आमतौर पर एक विशेष तरीके से संसाधित होते हैं। वेक्टर निर्देशों के लिए, यह मामला इस तथ्य से जटिल है कि बिंदुओं की सीमा ब्लॉक में, सामान्य एल्गोरिथ्म के अनुसार अंकों का हिस्सा संसाधित किया जाता है, और सीमा बिंदुओं के लिए एल्गोरिदम के अनुसार भाग, जो विकास को बहुत जटिल करता है।
7. छवि की चौड़ाई हमेशा वेक्टर के आकार की एक बहु नहीं होती है। इसलिए, एक मनमाना चौड़ाई के साथ छवियों को संसाधित करने के लिए, विशेष रूप से अंतिम ब्लॉक को एक पंक्ति में संसाधित करना आवश्यक है, जिसे केवल आंशिक रूप से भरा जा सकता है।
8. स्केलर रजिस्टरों के लिए उपलब्ध सभी गणितीय संचालन वेक्टर निर्देशों के लिए अपने स्वयं के एनालॉग नहीं हैं। उदाहरण के लिए, कोई पूर्णांक विभाजन नहीं है। इन मामलों में, आपको या तो सदिश करने से इंकार करना होगा, या उपलब्ध निर्देशों का उपयोग करके उनका अनुकरण करने का प्रयास करना होगा, जिससे कम दक्षता और अधिक जटिल कोड हो सकता है।
9. वेक्टर निर्देशों वाले कोड की पठनीयता आमतौर पर स्केलर कोड की तुलना में काफी कम है।
10. वेक्टर निर्देश वाले डिबगिंग कोड बहुत अधिक कठिन है, क्योंकि प्रोग्रामर को पूरे स्केलर मानों की नहीं, बल्कि पूरे वैक्टर की शुद्धता को ट्रैक करना होता है। और आधुनिक आईडीई, इस क्षेत्र में महत्वपूर्ण प्रगति के बावजूद, वेक्टर डेटा को स्केलर वाले की तुलना में बहुत खराब प्रदर्शित करते हैं।
11. अनुभव से पता चलता है कि वेक्टर निर्देशों का उपयोग करते हुए एक सही ढंग से काम करने वाले एल्गोरिदम को लिखना, यूनिट परीक्षणों की उपस्थिति के बिना व्यावहारिक रूप से असंभव है, जो सभी विशिष्ट मामलों को कवर करता है जिसमें इसका उपयोग किया जाएगा।

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

अंतभाषण

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