2010-05-22 13 views
5

मैंने सी में प्रदर्शन के बारे में कई बातें सुनी हैं; सामान्य असाइनमेंट की तुलना में कास्टिंग धीमा है, कार्यात्मक कॉल धीमा है, बाइनरी ऑपरेशन सामान्य संचालन से बहुत तेज है, और cetera ...सी: असाइनमेंट का प्रदर्शन, बाइनरी ऑपरेशंस, एट कैटर

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

+8

* "... कास्टिंग धीमा है ..." * कास्टिंग, सी में, रनटाइम पर शून्य-टाइम ऑपरेशन है। संकलन-समय पर यह * पूरी तरह से * होता है। इसी तरह, फ़ंक्शन कॉल उच्च स्तर की भाषा में सी से अधिक तेज़ नहीं होते हैं; * शाब्दिक * बस "स्टैक पर रिटर्न वैल्यू को दबाएं, स्टैक पर 0 दबाएं, एक कूद निष्पादित करें।" आप इन "सत्य" कहां से प्राप्त कर रहे हैं? 'क्योंकि मुझे एक और स्रोत मिलेगा। :-) –

+2

कास्टिंग धीमा है? सी में? यह रन-टाइम पर भी मौजूद नहीं है। –

+2

@ टीजे। कुछ जानवर मुक्त नहीं हैं। उदाहरण के लिए, 'char' को' डबल' पर कास्टिंग करें। अभी भी बहुत सस्ता है। –

उत्तर

10

असल में, नहीं। सिंटैक्स स्तर से ऐसी कोई "टिप्स और ट्रिक्स" पुस्तक नहीं है, क्योंकि इसमें कोई निश्चित अग्नि गारंटी नहीं है कि आपने जो भी कहा है वह सच है (वास्तव में, इसमें से अधिकांश गलत है)।

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

यदि आप इंटेल आर्किटेक्चर (और सभी इंटेल संगत CPUs) पर माइक्रो-ऑप्टिमाइज़ेशन में रूचि रखते हैं, तो यह is a must read (पीडीएफ) है। Agner's website.

+1

+1 - पहले एल्गोरिदम डालना। एक खराब एल्गोरिदम तेजी से नहीं मिलेगा भले ही यह प्रत्येक चरण में सूक्ष्मदर्शीकृत हो। –

+0

यह एक उत्कृष्ट साइट है। –

1

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

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

9

ऐसा लगता है कि आप इन सब से बहुत उलझन में हैं। आइए इन मिथकों में से कुछ को संबोधित करें जिन्हें आपने खींचा है।

सामान्य असाइनमेंट की तुलना में कास्टिंग धीमा है।

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

फ़ंक्शन कॉल धीमे हैं।

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

बाइनरी ऑपरेशंस सामान्य संचालन से तेज़ होते हैं।

"सामान्य ऑपरेशन" क्या है? एफडब्ल्यूआईडब्ल्यू, अतिरिक्त बाइनरी ऑपरेशन है। तो गुणा है। आधुनिक हार्डवेयर पर, वे दोनों बहुत तेज हैं।कंपाइलर को इसके बारे में चिंता करने दें। यह बहुत महत्वपूर्ण है कि आप वर्णन कर रहे हैं कि आप सही तरीके से क्या कर रहे हैं।

अब, चीजें हैं जो वास्तव में खर्च के लिए:

  • आई/ओ।
  • मेमोरी आवंटन।
  • मेमोरी प्रतियां।
  • गहरा घोंसला (या बहुत लंबा) लूप।

उन पर अपनी आंखें रखें; वे हैं जहां सॉफ्टवेयर आमतौर पर धीमा हो जाता है। और हमेशा अच्छे एल्गोरिदम और डेटा संरचनाएं चुनें।

+0

उत्कृष्ट जवाब। अति उत्कृष्ट। हालांकि, ढेर स्मृति आवंटन I/O के समान वर्ग में नहीं है, न कि करीब भी। हीप बहुत तेज है। एक कलाकार की तरह तेज़ नहीं, लेकिन तेज़ - जब तक आप कम नहीं चलते हैं। :-) –

+0

@ टीजे। I/O सबसे धीमा है, और आम तौर पर वास्तव में छुटकारा पाने के लिए सबसे मुश्किल है; आप आमतौर पर एक अच्छे कारण के लिए 'पढ़ा() 'कर रहे हैं। ढेर आवंटन बहुत तेज़ है, लेकिन आप अक्सर इसमें बहुत कुछ करते हैं; यह डरने वाला नहीं है, लेकिन यह निश्चित रूप से मुफ़्त नहीं है। –

+1

और एक ऐसा क्षेत्र जो अक्सर अनिवार्य रूप से महंगा है स्ट्रिंग हैंडलिंग है। गरीब कोडर अक्सर उस क्षेत्र में विनाशकारी रूप से खराब कोड लिखते हैं क्योंकि वे स्मृति प्रतियों और लूपों पर एक अच्छा संभाल नहीं रखते हैं। –

1

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

सी उतना करीब है जितना आप मशीन भाषा में जा सकते हैं और अभी भी एक मशीन-स्वतंत्र "उच्च स्तरीय" भाषा हो सकते हैं।

अन्य सभी उत्तरों सही हैं।

मैं केवल वास्तविक सॉफ्टवेयर (छोटे दो-पेज प्रोग्राम नहीं) अतिरिक्त सामान्यता, अति-अमूर्तता, बाजुका के साथ मक्खियों को मारने, खराब प्रदर्शन के भारी कारण हैं, भले ही हर अंतिम प्रोग्रामर अपने समाधान को मानता है "सरल"।

2

एक बार एक समय पर कुशल सी नाम की एक पुस्तक थी। कुछ हद तक, कुशल सी/सी ++ प्रोग्रामिंग नाम की एक पुस्तक थी: छोटे, तेज़, बेहतर। हाल ही में, अभी भी कुशल सी ++ नामित किया गया था।

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

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

1

मैं सी में प्रदर्शन के बारे में बहुत सी बातें सुना है ...

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

मैं एक सामान्य विचार प्राप्त करने के लिए एक चार्ट देखना चाहता हूं कि मुझे क्या करना चाहिए और मुझे उच्च प्रदर्शन कार्यक्रम लिखने से क्या बचना चाहिए।

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

Have you read Jon Bentley's book "Programming Pearls"? --no--> read it 
      | 
      | yes 
      V 
    Have you read Peter van der Linden's book 
    "Expert C Programming: Deep C Secrets"?     --no--> read it 
      | 
      | yes 
      V 
    Have you learned how to use valgrind --tool=callgrind 
    and the kcachegrind visualizer?       --no--> learn them 
      | 
      | yes 
      V 
    Congratulations! You are now equipped to write 
    reasonably efficient C programs. 

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

संबंधित मुद्दे