जब मैं अपना कोड लिखूं तो मुझे संकलित मशीन कोड के बारे में सोचना चाहिए?

Question

उदाहरण के लिए मुझे निम्नलिखित कोड मिला है:

auto z = [](int x) -> int {
    if (x > 0) {
        switch (x) {
            case 2: return 5;
            case 3: return 6;
            default: return 1;
            }
        }
    return 0;
    };

और बाद में मैंने इसे कई बार कॉल किया। Asm कोड में मैं लैंबडा के साथ बाहरी कॉल देखता हूं .... कुछ ... यह पढ़ना आसान नहीं है और मुझे लगता है कि यह प्रदर्शन का कारण भी बन सकता है। इसलिए हो सकता है कि मैं मेटा-प्रोग्रामिंग में जीत जाऊं, लेकिन क्या मैं एएसएम डिबगिंग और प्रदर्शन में हार गया हूं? प्रदर्शन और डीबगिंग सादगी में सुनिश्चित करने के लिए क्या मुझे आधुनिक भाषा सुविधाओं, मैक्रोज़ और अन्य मेटा प्रोग्रामिंग पहलुओं से बचना चाहिए?

Comments

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

— रौंग

आपको असेंबली कोड डिबग करने की आवश्यकता नहीं है, जब तक कि आप प्रदर्शन महत्वपूर्ण पथ में नहीं हैं। इसके अलावा, "क्लीन कोड"! = "अच्छा प्रदर्शन"।

— B41ови।

कृपया अपना इंडेंटेशन ठीक करें। मैंने इसे करने की कोशिश की, लेकिन ऐसा लगता है कि आप सिर्फ व्हाट्सएप को संपादित नहीं कर सकते।

— क्रिस्टोफर हम्मरस्ट्रॉम जूल

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

— क्रिस्टोफर हम्मरस्ट्रॉम जूल

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

— dmckee

Answer 1

जब मैं अपना कोड लिखूं तो मुझे संकलित मशीन कोड के बारे में सोचना चाहिए?

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

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

Comments

+1 संक्षिप्त, सटीक, और सामान्य डॉक के अनुसार पालन करना आसान है, ख़ुशी की बात यह है कि हमारे यहाँ आपके पास है।

— जिमी हॉफ

सहमत, बहुत स्पष्ट जवाब।

— CND

Answer 2

लैम्ब्डा और फन्क्टर-क्लास के बीच का विकल्प एक ट्रेडऑफ है।

लैम्ब्डा से लाभ ज्यादातर सिंटैक्टिक है, बॉयलरप्लेट की मात्रा को कम करके और फंक्शनल-संबंधित कोड को इनलाइन में लिखने की अनुमति देता है, फ़ंक्शन के अंदर जो इसे (तुरंत या बाद में) उपयोग करने जा रहा है।

प्रदर्शन-वार, यह किसी फ़नकार वर्ग से भी बदतर नहीं है , जो एक C ++ संरचना या वर्ग है जिसमें एकल "विधि" शामिल है। वास्तव में, संकलक लैम्ब्डा का इलाज करते हैं जो दृश्य के पीछे संकलक-जनित फनकार वर्ग से अलग नहीं है।

// define the functor method somewhere
struct some_computer_generated_gibberish_0123456789
{
    int operator() (int x) const
    {
        if (x == 2) return 5;
        if (x == 3) return 6;
        return 0;
    }
};

// make a call
some_computer_generated_gibberish_0123456789 an_instance_of_0123456789;
int outputValue = an_instance_of_0123456789(inputValue);

आपके कोड उदाहरण में, प्रदर्शन-वार यह एक फ़ंक्शन कॉल से अलग नहीं है, क्योंकि फ़नकार वर्ग का कोई राज्य नहीं है (क्योंकि इसमें एक खाली कैप्चर क्लॉज़ है), इस प्रकार किसी आवंटन, निर्माण या विनाश की आवश्यकता नहीं है।

int some_computer_generated_gibberish_0123456789_method_more_gibberish(int x)
{
    if (...) return ...;
    return ...;
}

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

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

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

Answer 3

@DocBrown द्वारा उत्तर में जोड़ने के लिए, याद रखें कि इन दिनों सीपीयू सस्ते हैं लेकिन श्रम महंगा है।

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

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

Comments

केवल आंशिक रूप से सच है। यदि आपका कोड O (n ^ 2) (द्विघात) चलता है और आप इसे O (लॉग (n)) (लघुगणक) कहते हैं तो बेहतर होगा कि हार्डवेयर में कोड को बदलने के रूप में कभी भी अधिक प्रदर्शन वृद्धि नहीं होगी। मूल पोस्टर द्वारा निर्दिष्ट मामले में यह बहुत संभावना नहीं है।

— gnash117

@ gnash117 - हाँ, आप सही हैं यदि कोड को कई बार चलाना है; इस बारे में बताने के लिए शुक्रिया। ऐसे मामलों में, कोड को स्पष्ट रूप से दस्तावेजित करना प्रदर्शन में सुधार की अनुमति देते समय इसे बनाए रखेगा।

— धान लैंडौ

"श्रम महंगा है" - सही। आपके ग्राहक का समय बहुत महत्वपूर्ण है और अक्सर महंगा होता है।

— सेराड