प्रदर्शन के लिए सी में लेखन? [बन्द है]

Question

मुझे पता है कि मैंने अक्सर सुना है कि C का आमतौर पर C ++ पर प्रदर्शन लाभ है। मैं वास्तव में इसके बारे में कुछ और नहीं सोचता था जब तक मुझे एहसास हुआ कि MSVC सी के नवीनतम मानक का समर्थन करने के लिए भी प्रतीत नहीं होता है, लेकिन सबसे नया यह C99 का समर्थन करता है (जहां तक ​​मुझे पता है)।

मैं OpenGL में रेंडर करने के लिए कुछ कोड के साथ एक पुस्तकालय लिखने की योजना बना रहा था ताकि मैं इसका पुन: उपयोग कर सकूं। जब मैं ग्राफिक्स की बात करता हूं तो मैं सी में लाइब्रेरी लिखने की योजना बना रहा था।

लेकिन क्या यह वास्तव में इसके लायक होगा? लाइब्रेरी का उपयोग करने वाला कोड संभवतः C ++ में लिखा जाएगा और मैं C ++ में आमतौर पर कोड करना पसंद करता हूं।

हालांकि, अगर यह प्रदर्शन में थोड़ा अंतर पैदा करेगा, तो मैं संभवतः सी के साथ जाऊंगा।

यह भी ध्यान दिया जा सकता है कि यह पुस्तकालय कुछ ऐसा होगा जिसे मैं विंडोज / ओएस एक्स / लिनक्स पर काम करने के लिए बनाऊंगा, और मैं संभवतः सब कुछ मूल रूप से संकलित करूंगा (ओएस एक्स के लिए विंडोज, क्लैंग या जीसीसी और लिनक्स के लिए जीसीसी) ।। । संभवतः हर चीज के लिए इंटेल के संकलक)।

मैंने चारों ओर देखा है और मुझे कुछ बेंचमार्क और ऐसे मिले हैं, लेकिन मैंने जो कुछ भी देखा है वह एमएसवीसी और क्लैंग के बजाय जीसीसी से निपटा है। इसके अलावा, बेंचमार्क में प्रयुक्त भाषाओं के मानकों का उल्लेख नहीं है। क्या किसी के पास इस पर कोई विचार है?

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

Comments

MSVC का नवीनतम समर्थन वास्तव में C89 है।

— detly

@detly विज़ुअल स्टूडियो 2013 में, C99 सुविधाओं के विशाल बहुमत का समर्थन किया जाता है । यह पूर्ण समर्थन नहीं है, लेकिन मैं C99 लिखने के लिए इसका इस्तेमाल करना ठीक है।

— कॉंगसबोंगस

@ danielu13 - आपने कहां सुना है कि C का C ++ पर प्रदर्शन लाभ है?

— रामहाउंड

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

— user1942027

@RaphaelMiedl इसके अलावा मैंने उल्लेख किया था कि यह 2007 में लिखा गया था, जो काफी समय पहले, C ++ कंपाइलर और C ++ भाषा तब से विकसित हुई है। इसके बावजूद, यह प्रोग्रामर पर निर्भर है कि वह किस भाषा का उपयोग करे।

— सेबस्टियन-लॉरेनियू प्लेसीस्यूक

Answer 1

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

आइए निम्नलिखित कथन लें:

foo->doSomething(a + 5, *c);

चलिए आगे मान लेते हैं कि doSomethingनिम्नलिखित हस्ताक्षर हैं:

void doSomething(int a, long b);

अब, आइए इस विशेष विवरण के संभावित प्रदर्शन प्रभाव का विश्लेषण करने का प्रयास करें।

सी में, निहितार्थ काफी स्पष्ट हैं। fooकेवल एक संरचना के लिए एक संकेतक हो सकता है, और doSomethingएक फ़ंक्शन के लिए एक संकेतक होना चाहिए। *cdereferences एक लंबा, और a + 5पूर्णांक जोड़ है। केवल अनिश्चितता के प्रकार से आता है a: यदि यह एक इंट नहीं है, तो कुछ रूपांतरण होगा। लेकिन इसके अलावा, इस एकल कथन के प्रदर्शन प्रभाव को निर्धारित करना आसान है।

अब C ++ में स्विच करते हैं। एक ही कथन में अब बहुत अलग प्रदर्शन विशेषताएं हो सकती हैं:

1. doSomethingएक गैर-आभासी सदस्य फ़ंक्शन (सस्ता), आभासी सदस्य फ़ंक्शन (थोड़ा अधिक महंगा) std::function, लंबोदर ... आदि fooहो सकता है । क्या बुरा है, एक वर्ग प्रकार हो सकता है operator->जो अनकाउंटेड जटिलता के कुछ ऑपरेशन के साथ अतिभारित हो सकता है । तो आदेश बुला की लागत की गणना कर में doSomething, यह अब आवश्यक की वास्तविक प्रकृति को पता है है fooऔर doSomething।
2. aएक पूर्णांक, या एक पूर्णांक (अतिरिक्त अप्रत्यक्ष), या एक वर्ग प्रकार का संदर्भ हो सकता है जो लागू होता है operator+(int)। ऑपरेटर अन्य प्रकार के प्रकार को भी लौटा सकता है जो अनुमानित रूप से परिवर्तनीय है int। फिर, अकेले प्रदर्शन से लागत प्रदर्शन स्पष्ट नहीं है।
3. cएक वर्ग प्रकार कार्यान्वयन हो सकता है operator*()। यह भी एक के लिए एक संदर्भ हो सकता है long*आदि

आपको चित्र मिल जाएगा। सी ++ की भाषा सुविधाओं के कारण, सी में किसी भी स्टेटमेंट की प्रदर्शन लागतों को निर्धारित करना बहुत कठिन है। अब इसके अलावा, अमूर्त जैसे std::vector, std::stringआमतौर पर सी ++ में उपयोग किए जाते हैं, जिनकी प्रदर्शन विशेषताओं की विशेषता होती है, और गतिशील मेमोरी आवंटन को छिपाते हैं। यह भी देखें @ इयान का जवाब)।

तो, नीचे पंक्ति यह है: सामान्य तौर पर, सी या सी ++ का उपयोग करके प्राप्त होने वाले संभावित प्रदर्शन में कोई अंतर नहीं है। लेकिन वास्तव में प्रदर्शन-महत्वपूर्ण कोड के लिए, लोग अक्सर C का उपयोग करना पसंद करते हैं क्योंकि वहाँ रास्ता संभव हो सकता है छिपे हुए प्रदर्शन दंड।

Comments

शानदार जवाब। यह वही है जो मैं अपने जवाब में बता रहा था, लेकिन आपने इसे बहुत बेहतर बताया है।

— इयान गोल्डबी

यह वास्तव में स्वीकृत उत्तर होना चाहिए। यह बताता है कि "C ++ की तुलना में अधिक तेज़ क्यों" जैसे कथन मौजूद हैं। C ++ की तुलना में C तेज़ या धीमा हो सकता है, लेकिन आमतौर पर यह पता लगाना बहुत आसान है कि C कोड का एक विशिष्ट टुकड़ा तेज़ / धीमा क्यों है, जो आमतौर पर अनुकूलन करना भी आसान बनाता है।

— सिंह

इस उत्कृष्ट उत्तर (जिसके लिए मेरे से एक +1) से कुछ भी नहीं लेना है, लेकिन संकलक (ओं) को इस तुलना में सेब और संतरे हो सकते हैं। यह / वे C बनाम C ++ के समान कोड उत्पन्न कर सकते हैं, या नहीं। बेशक किसी भी दो संकलक या संकलक विकल्पों के लिए कहा जा सकता है, यहां तक ​​कि समान स्रोत-भाषा मान्यताओं के साथ शारीरिक रूप से एक ही कार्यक्रम को संकलित करने के लिए भी।

— JRobert

मैं जोड़ूंगा कि अधिकांश C ++ रनटाइम समान C रनटाइम के साथ तुलना में बड़े पैमाने पर हैं, जो कि अगर आप स्मृति में बाधा हैं तो बात होगी।

— जेम्स एंडरसन

@ जेम्सएंडरसन यदि आप वास्तव में उस स्मृति में बाधक हैं , तो आपको संभवतः किसी रनटाइम की आवश्यकता नहीं है :)

— नवीन

Answer 2

कुछ प्रकार के कार्यों के लिए C ++ में लिखा गया कोड C से तेज हो सकता है।

यदि आप C ++ पसंद करते हैं, तो C ++ का उपयोग करें। आपके सॉफ़्टवेयर के एल्गोरिथम निर्णयों की तुलना में कोई भी प्रदर्शन समस्याएँ नगण्य होने वाली हैं।

Comments

यह तेज हो सकता है लेकिन यह उसी कारण से तेज नहीं हो सकता है।

— रोब

क्या आप C ++ में लिखे गए अनुकूलित कोड के कुछ उदाहरण दे सकते हैं जो अनुकूलित C से तेज है?

@TomDworzanski: एक उदाहरण है कि टेम्प्लेट का उपयोग करके, कोड पथ के बारे में निर्णय संकलन समय पर निर्धारित किए जा सकते हैं और अंतिम बाइनरी में हार्डकोड को समाप्त कर सकते हैं, बजाय सशर्त और शाखाओं में बँधने की आवश्यकता होगी क्योंकि यह सी में लिखा गया था, साथ ही साथ क्षमता भी। inlining के माध्यम से फ़ंक्शन कॉल से बचने के लिए।

— whatsisname

Answer 3

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

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

Comments

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

— जॉन आर। स्ट्रॉहेम

संरचनाएं C ++ में कक्षाएं हैं।

— दायां

@ राइटफोल्ड: ज़रूर, लेकिन आप अभी भी C ++ कोड लिख सकते हैं जो thisपॉइंटर भाषा सुविधा का उपयोग किए बिना पॉइंटर्स के आसपास संरचनाओं में गुजरता है । बस इतना ही कह रहा था।

— ग्रेग हेविल

@ जॉन वास्तविक लागत अप्रत्यक्ष नहीं है (हालांकि मुझे पूरा यकीन है कि यह कुछ प्रोसेसर के साथ कुछ पेंच भी होगा), लेकिन यह तथ्य कि आप आभासी कार्यों को इनलाइन नहीं कर सकते हैं (C ++ में कम से कम) जो कई अन्यथा संभव नहीं है अनुकूलन। और हाँ जो प्रदर्शन पर एक विशाल प्रभाव डाल सकता है।

— Voo

@Voo निष्पक्ष होने के लिए, समान सी कोड (कोड जो मैन्युअल रूप से रनटाइम पॉलीमॉर्फिज़्म का अनुकरण करता है) के बारे में कहा जा सकता है। सबसे बड़ा अंतर यह है कि मेरा मानना ​​है कि एक संकलक के लिए यह निर्धारित करना आसान होगा कि क्या कहा फ़ंक्शन C ++ में इनबिल्ट किया जा सकता है।

— थॉमस एडिंग

Answer 4

उच्च स्तर की भाषाएं कभी-कभी धीमी होने का एक कारण यह है कि वे पर्दे के पीछे निचले स्तर की भाषाओं की तुलना में अधिक स्मृति प्रबंधन को छिपा सकती हैं।

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

यदि आपने C में इस तरह का कोड लिखा है तो यह स्पष्ट रूप से स्पष्ट होगा। C ++ में संभवत: ऐसा कम होता है, क्योंकि आवंटन और नकल कहीं दूर एक कक्षा में रखी जा सकती है। वे एक निर्दोष दिखने वाले ओवरलोड ऑपरेटर या कॉपी कंस्ट्रक्टर के पीछे छिपे हो सकते हैं।

यदि आप चाहते हैं तो C ++ का उपयोग करें। लेकिन अमूर्तता की प्रतीत होने वाली सुविधा से नहीं गुज़रना चाहिए जब आप नहीं जानते कि उनके नीचे क्या है।

बेशक, यह पता लगाने के लिए एक प्रोफाइलर का उपयोग करें कि क्या वास्तव में आपके कोड को धीमा कर रहा है।

Answer 5

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

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

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

---

अब अपनी प्राथमिक चिंता को दूर करने के लिए: प्रदर्शन।

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

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

---

अब कुछ मजेदार रीडिंग के बारे में कि कैसे भाषा की विशेषताएं और अनुकूलन वास्तव में आपके पक्ष में काम कर सकते हैं:

std :: unique_ptr में शून्य ओवरहेड है

कॉन्स्टैक्स संकलन-समय की गणना के लिए अनुमति देता है

चालित शब्दार्थ अनावश्यक अस्थायी वस्तुओं को रोकते हैं

Comments

std::unique_ptr has zero overheadयह संभवतः तकनीकी रूप से सही नहीं हो सकता है, क्योंकि यदि इसके अपवाद के कारण स्टैक को बंद कर दिया जाता है, तो उसे अपने निर्माता को कॉल करना होगा। एक कच्चे पॉइंटर में यह ओवरहेड नहीं होता है और फिर भी सही होगा यदि आपका कोड संभवत: नहीं फेंकेगा। एक कंपाइलर सामान्य मामले में यह साबित नहीं कर पाएगा।

— थॉमस एडिंग

@ThomasEding मैं अपवाद-मुक्त कोड के संबंध में आकार और रनटाइम ओवरहेड का उल्लेख कर रहा था। सही होने पर मुझे सही करें, लेकिन निष्पादन मॉडल हैं जो शून्य रनवे ओवरहेड को उकसाते हैं जब अपवाद नहीं फेंके जाते हैं जो अभी भी आवश्यक होने पर अपवादों को प्रचारित करने की अनुमति देते हैं। फिर भी, जब एक अपवाद को कभी भी निर्माणकर्ता में फेंका जा सकता है unique_ptr? यह घोषित किया गया है noexcept, और इसलिए बहुत कम से कम यह सभी अपवादों को संभालता है, लेकिन मैं कल्पना नहीं कर सकता कि किस प्रकार के अपवाद को पहली जगह में भी फेंक दिया जा सकता है।

— vmrob

vmrob: मुझे क्षमा करें ... मेरा मतलब "निर्माता" के बजाय "विध्वंसक" लिखना था। मेरा यह भी लिखने का मतलब था "बहुत फेंक देंगे"। Eeek!

— थॉमस ईडिंग

@ThomasEding तुम्हें पता है, मुझे नहीं लगता कि यह तब भी कोई फर्क नहीं पड़ता अगर विध्वंसक ने एक अपवाद फेंक दिया। जब तक विध्वंसक कोई नया अपवाद पेश नहीं करता है, तब तक यह शून्य ओवरहेड विनाश है। इसके अलावा, मेरा मानना ​​है कि पूरा विध्वंसक अनुकूलन के साथ एक सिंगल डिलीट / फ्री कॉल के लिए इनबिल्ट हो जाता है।

— vmrob

Answer 6

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

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

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

Answer 7

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

C ++ में अलग-अलग प्रदर्शन हो सकते हैं, या तो धीमे या तेज़, अगर (1) आप मानक C ++ लाइब्रेरी का उपयोग उन चीजों को करने के लिए करते हैं जो लाइब्रेरी का उपयोग किए बिना बहुत तेज़ और आसान किया जा सकता है, या (2) यदि आप मानक C ++ लाइब्रेरी का उपयोग करते हैं बुरी सी में लाइब्रेरी को फिर से लागू करने की तुलना में चीजों को बहुत आसान और तेज करना।

Comments

इस प्रस्ताव को कुछ भी क्या 6 पहले जवाब में स्पष्ट किया गया था पर पर्याप्त प्रतीत नहीं होता है

— कुटकी

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

— user27539