क्या मुझे सी/सी ++ में अपने डीएसपी दिनचर्या को फिर से लिखना चाहिए या मैं सी # असुरक्षित पॉइंटर्स के साथ अच्छा हूं?

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

क्या मुझे सी या सी ++ में इन दिनचर्या को फिर से लिखने से कोई प्रदर्शन लाभ मिलेगा या क्या मुझे असुरक्षित पॉइंटर्स से चिपकना चाहिए? मैं जानना चाहता हूं कि सी/सी ++ की तुलना में प्रदर्शन के संदर्भ में असुरक्षित पॉइंटर्स तालिका में क्या लाता है।

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

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

0
यदि आपने सामने कहा था, "असुरक्षित पॉइंटर्स का उपयोग करके मैंने सी # में दिनचर्या पहले ही लिखी है, तो सवाल बहुत स्पष्ट होगा।" शायद इससे आपको कुछ और सटीक उत्तर प्राप्त करने में मदद मिलेगी?
जोड़ा लेखक Orion Edwards, स्रोत
आपको निश्चित रूप से यह कहना चाहिए था कि आपने उन्हें सी # में लिखा था। हमें यह मानना ​​है कि यह मामला है।
जोड़ा लेखक Tim, स्रोत

13 उत्तर

आपका सवाल काफी हद तक दार्शनिक है। जवाब यह है: जब तक आप प्रोफ़ाइल तक ऑप्टिमाइज़ न करें।

आप पूछते हैं कि क्या आपको सुधार मिलेगा। ठीक है, आप एन प्रतिशत द्वारा सुधार हासिल करेंगे। यदि यह पर्याप्त है (जैसे आपको कुछ एम्बेडेड सिस्टम पर 20 मिलीसेकंड में 200 बार निष्पादित करने की आवश्यकता है) तो आप ठीक हैं। लेकिन क्या होगा यदि यह पर्याप्त नहीं है?

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

0
जोड़ा

क्या आप वास्तव में ऐप को यथासंभव तेज़ या बस तेज़ी से चाहते हैं? यह आपको बताता है कि आपको आगे क्या करना चाहिए।

0
जोड़ा

मोनो 2.2 में अब SIMD समर्थन है, इसके साथ आप दोनों दुनिया के सर्वश्रेष्ठ हो सकते हैं प्रबंधित कोड और कच्ची गति।

You might also want to have a look at Using SSE in C# is it possible?

0
जोड़ा

क्या मुझे कोई प्रदर्शन लाभ मिलेगा   सी/सी ++ में इन दिनचर्या को फिर से लिखने से   या मुझे असुरक्षित पॉइंटर्स से चिपकना चाहिए?

सिद्धांत रूप में इससे कोई फर्क नहीं पड़ता - एक आदर्श कंपाइलर कोड को अनुकूलित करेगा, चाहे सी या सी ++, सर्वोत्तम संभव असेंबलर में हो।

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

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

तो, नहीं, आपको सी ++ पर स्विच करके प्रदर्शन में वृद्धि दिखाई नहीं देगी।

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

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

-Adam

0
जोड़ा
मुझे लगता है कि मैं यह कहने में सही हूं कि सी से सी ++ में स्विच करने से आपको कोई प्रदर्शन नहीं मिलेगा, हालांकि लगभग किसी अन्य चीज़ से सी ++ में स्विच करना संभवतः (पिछले तीसरे पैराग्राफ में, जो स्पष्ट नहीं है) में स्विच करेगा।
जोड़ा लेखक Zooba, स्रोत

मुझे लगता है कि आपको अपने डीएसपी दिनचर्या को सी ++ (प्रबंधित या अप्रबंधित) या सी # में एक ठोस डिजाइन का उपयोग करके लिखना चाहिए, लेकिन शुरुआत से सबकुछ अनुकूलित करने की कोशिश किए बिना, और फिर आपको अपना कोड प्रोफाइल करना चाहिए और बाधाएं ढूंढनी चाहिए और उनको अनुकूलित करने का प्रयास करना चाहिए दूर।

शुरुआत से "इष्टतम" कोड तैयार करने का प्रयास करने से आपको पहले स्थान पर काम करने वाले कोड लिखने से विचलित किया जा रहा है। याद रखें कि आपके अनुकूलन का 80% केवल आपके कोड का 20% प्रभावित करेगा क्योंकि कई मामलों में आपके कोड का केवल 10% आपके CPU समय के 90% के लिए ज़िम्मेदार है। (वाईएमएमवी, क्योंकि यह आवेदन के प्रकार पर निर्भर करता है)

जब मैं अपने ग्राफिक्स टूलकिट में अल्फा ब्लेंडिंग के हमारे उपयोग को अनुकूलित करने का प्रयास कर रहा था, तो मैं पहली बार "बेयर मेटल" तरीके सिमड का उपयोग करने की कोशिश कर रहा था: इनलाइन असेंबलर। जल्द ही मुझे पता चला कि शुद्ध असेंबली पर सिमड इंट्रिनिक्स का उपयोग करना बेहतर है, क्योंकि संकलक अलग-अलग ऑपोड्स को पुनर्व्यवस्थित करके और सीपीयू में विभिन्न प्रोसेसिंग इकाइयों के उपयोग को अधिकतम करके इंट्रिनिक्स के साथ पठनीय सी ++ को अनुकूलित करने में सक्षम है।

अपने कंपाइलर की शक्ति को कम मत समझो!

0
जोड़ा

सबसे पहले मुझे "सुरक्षित" बनाम "असुरक्षित" के बारे में प्रश्न का उत्तर दें: आपने अपनी पोस्ट में कहा था "मैं चाहता हूं कि ऐप जितनी जल्दी हो सके" और इसका मतलब है कि आप "सुरक्षित" या "प्रबंधित" से गड़बड़ नहीं करना चाहते हैं पॉइंटर्स (कचरा संग्रह का भी उल्लेख नहीं है)।

भाषाओं की अपनी पसंद के संबंध में: सी/सी ++ आपको अंतर्निहित डेटा के साथ फैंसी कंटेनरों से जुड़े किसी भी ओवरहेड के बिना अधिक आसानी से काम करने देता है जो हर कोई इन दिनों उपयोग कर रहा है। हां यह कंटेनरों द्वारा cuddled करने के लिए अच्छा है जो आपको seg-faulting से रोकता है ... लेकिन कंटेनर RUINS आपके प्रदर्शन से जुड़े अमूर्तता का उच्च-स्तर।

At my job our code has to run fast. An example is our polyphase-resamplers at work that play with pointers and masking operations and fixed point DSP filtering ... none of these clever tricks are really possible without low level control of the memory and bit manipulations ==> so I say stick with C/C++.

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

(एफवाईआई, प्रशिक्षण पहियों को बंद करने के बारे में: आपको अपने सी डीएसपी कोड को अतिरिक्त ऑफ़लाइन जांचने की ज़रूरत है ताकि यह सुनिश्चित किया जा सके कि उनका सूचक उपयोग अच्छा है ... o/w यह गलती को रोक देगा।)

संपादित करें: पी। "seg faulting" आप सभी पीसी/x86 डेवलपर्स के लिए एक लक्जरी है। जब आप एम्बेडेड कोड लिख रहे हों ... एक सीईजी गलती का मतलब है कि आपका प्रोसेसर wuides में जाएगा और केवल पावर साइकलिंग द्वारा पुनर्प्राप्त किया जाएगा;)।

0
जोड़ा

यह जानने के लिए कि आपको प्रदर्शन लाभ कैसे मिलेगा, कोड के उन हिस्सों को जानना अच्छा होता है जो बाधा उत्पन्न कर सकते हैं।

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

सीपीयू और मेमोरी के बीच के रास्ते पर एक और बाधा होगी - आपके आवेदन में मेमोरी ट्रांसफर की बड़ी संख्या के कारण कैश याद आती है। तब सबसे बड़ा लाभ कैश मिस को कम करने में झूठ बोलता है, जो आपके द्वारा उपयोग किए जाने वाले प्लेटफॉर्म पर निर्भर करता है, और आपके डेटा के लेआउट पर (क्या यह स्थानीय है या स्मृति के माध्यम से फैल गया है?)।

लेकिन चूंकि आप पहले से ही असुरक्षित पॉइंटर्स का उपयोग कर रहे हैं, तो आपके पास अपने नियंत्रण में थोड़ा सा है, इसलिए मेरा अनुमान है: उस पहलू पर, आपको बंदरगाह से सी (या सी ++) से अधिक लाभ नहीं होगा।

निष्कर्ष निकालना: आप अपने आवेदन के छोटे हिस्सों को सी में बंद करना चाहते हैं।

0
जोड़ा

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

for each n do t´[n] = h(g(f(t[n])))

इस तरह आप कैश को बहुत कम कचरा करेंगे और अधिकतर एक अच्छी गति में वृद्धि होगी।

0
जोड़ा
यह वास्तव में एक अच्छा सुझाव है। वास्तव में, इसे "अच्छी इलाके" कहा जा सकता है, और न केवल डीएसपी कोड के लिए बल्कि कई अनुप्रयोगों के लिए काम करता है।
जोड़ा लेखक Dave Van den Eynde, स्रोत

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

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

क्या आपने सी ++/सीएलआई माना है? तब आप दोनों दुनिया के सर्वश्रेष्ठ हो सकते हैं। यदि आवश्यक हो तो यह आपको इनलाइन असेंबलर का उपयोग करने की अनुमति भी देगा।

0
जोड़ा
कभी-कभी एएसएम से शुरू होता है, वास्तविक निर्देशों के कारण नहीं, बल्कि इसलिए कि आप अपने डेटा के बारे में अलग-अलग सोचते हैं। यदि आपके पास एएसएम अनुभव है, हालांकि, क्रैशवर्क्स कहते हैं कि आप अक्सर कंपेलर को सही तरीके से करने के लिए मना सकते हैं। एएसएम का ज्ञान होने से आपको अतिरिक्त बढ़ावा मिलता है।
जोड़ा लेखक Nosredna, स्रोत
यह आवश्यक अनुकूलन के स्तर पर निर्भर करता है। मैं किसी ऐसे व्यक्ति को जानता था जो 56k/96k कोड को अनुकूलित करने में इतना धीमा था कि निर्माताओं (मोटोरोला) मदद के लिए उसे कॉल करने के लिए उपयोग किया जाता था। वह सभी असेंबलर था; एक कंपाइलर रास्ते में मिल जाएगा।
जोड़ा लेखक Peter K., स्रोत
मैंने एमएसवीसी को निर्देश शेड्यूलिंग पर इष्टतम पाया है और रंग पंजीकरण करने के लिए इसे सॉफ़्टवेयर पाइपलाइनिंग का उपयोग करना चाहते हैं, तो इसे संभालने के लिए थोड़ा सा जरूरत है, और मुझे इसे केवल हार्डवेयर ऑप का उपयोग करने के लिए कंपाइलर इंट्रिनिक्स का सहारा लेना पड़ता है दिमाग, लेकिन न ही एएसएम छोड़ने की आवश्यकता है।
जोड़ा लेखक Crashworks, स्रोत
सीधे विधानसभा में कूद क्यों? सी और सी ++ पोर्टेबल होने का लाभ है।
जोड़ा लेखक postfuturist, स्रोत
मैं कभी नहीं किसी भी चीज़ के लिए सीधे एएसएम पर कूद जाऊंगा। आपका सबसे अच्छा सी में लिखना है, सी में अनुकूलित करना, फिर कंपाइलर से एएसएम डंप लें और इसे प्रोफाइल करें। इसे ट्विक करें जहां आप कर सकते हैं। कोई भी आधुनिक आधुनिक सीपीयू में सभी प्रोसेसिंग इकाइयों और रजिस्टरों को निर्धारित नहीं कर सकता है।
जोड़ा लेखक Adam Hawes, स्रोत

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

जैसा हुआ था, वैसे ही हुआ जब मेरा एल्गोरिदम असुरक्षित पॉइंटर्स के साथ प्रति सेकंड 1.5-2 फ्रेम प्रति सेकंड से 40 सेकंड प्रति सेकेंड तक चला गया। सी # और सी ++/सीएलआई निश्चित रूप से सी ++ की तुलना में धीमे थे, यहां तक ​​कि पॉइंटर्स के साथ, मैं उन भाषाओं के साथ प्रति सेकंड 10 फ्रेम से ऊपर नहीं पहुंच पा रहा हूं। जैसे ही मैंने सी ++ पर स्विच किया, मुझे तुरंत प्रति सेकंड 15-20 फ्रेम की तरह कुछ मिला। कुछ और चालाक बदलाव और एसएसई ने मुझे प्रति सेकंड 40 फ्रेम तक पहुंचाया। तो हाँ, अगर आप मेरे अनुभव में गति चाहते हैं तो यह नीचे जा रहा है। एक स्पष्ट प्रदर्शन लाभ है।

0
जोड़ा
मैं खुशी से तीसरा होगा, खासकर यदि आप गणित का उपयोग कर रहे हैं। कार्य बिल्कुल। मुझे गणित :: लॉग() (सी ++/सीएलआई) से लॉग इन() में गणित में 10x गतिशीलता मिली है। अगर आप सी ++/सीएलआई में कोड मिश्रण करना चाहते हैं तो #pragma प्रबंधित (बंद) को याद रखें - यह ठीक काम करता है।
जोड़ा लेखक Zooba, स्रोत
मैं दूसरे रे का अनुभव कर सकता हूं। मैंने लगभग 2 से 1 गति सुधार के लिए सी ++/सीएलआई से शुद्ध सी ++ में कुछ छवि फ़िल्टरिंग कोड ले जाया।
जोड़ा लेखक Steve Fallows, स्रोत

यह देखते हुए कि आप पहले से ही असुरक्षित कोड में लिख रहे हैं, मुझे लगता है कि इसे सी डीएल में परिवर्तित करना अपेक्षाकृत आसान होगा और उन्हें सी # के भीतर से कॉल करना होगा। अपने प्रोग्राम के सबसे धीमे हिस्सों की पहचान करने के बाद ऐसा करें और फिर उन्हें सी के साथ बदलें।

0
जोड़ा

सी # के पास एसएसई के लिए कोई समर्थन नहीं है (फिर भी, एसएसई संचालन के लिए एक मोनो प्रोजेक्ट है)। एसएसई के साथ सी/सी ++ के लिए निश्चित रूप से तेज़ होगा।

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

0
जोड़ा

यदि आप अपने हैंड-रोल के साथ चिपकने के लिए आग्रह करते हैं, बिना असेंबलर या समान में हाथ-अनुकूलन के, सी # ठीक होना चाहिए। दुर्भाग्य से, यह एक तरह का सवाल है जिसे केवल प्रयोगात्मक रूप से उत्तर दिया जा सकता है। आप पहले से ही अप्रबंधित पॉइंटर स्पेस में हैं, इसलिए मेरा आंत महसूस होता है कि सी ++ के लिए सीधा पोर्ट गति में महत्वपूर्ण अंतर नहीं देखेगा।

मुझे कहना चाहिए कि, हालांकि, मुझे हाल ही में एक ही समस्या थी, और हम इंटेल इंटीग्रेटेड प्रदर्शन Primitives लाइब्रेरी। हमने देखा प्रदर्शन प्रदर्शन बहुत प्रभावशाली थे।

0
जोड़ा
एक बहुत ही रोचक जवाब, बहुत बहुत धन्यवाद।
जोड़ा लेखक Trap, स्रोत