नहीं, लेकिन हां, लेकिन शायद, लेकिन शायद दूसरा तरीका, लेकिन नहीं।
जैसा कि लोगों ने पहले ही इंगित किया है, (एक भाषा को छोड़कर जहां जोड़-घटाव है, जैसे C, C ++, C # या Java) अभिव्यक्ति ((1 + 2) + 3)बिल्कुल इसके बराबर है 1 + 2 + 3। वे स्रोत कोड में कुछ लिखने के विभिन्न तरीके हैं, जिसके परिणामस्वरूप मशीन कोड या बाइट कोड पर शून्य प्रभाव होगा।
किसी भी तरह से परिणाम दो अनुदेशों को जोड़ने और फिर एक तिहाई जोड़ने के लिए एक निर्देश होने जा रहा है, या एक स्टैक से दो मान लें, इसे जोड़ें, इसे वापस धक्का दें, फिर इसे और दूसरा लें और उन्हें जोड़ें, या तीन रजिस्टर जोड़ें अगले स्तर (मशीन कोड या बाइट कोड) में जो सबसे अधिक समझदार है, उसके आधार पर तीन संख्याओं को योग करने के लिए एक एकल ऑपरेशन, या कुछ अन्य तरीके। बाइट कोड के मामले में, इसके बदले में एक समान री-स्ट्रक्चरिंग से गुजरना होगा, जैसे कि इस के IL समतुल्य (जो एक स्टैक पर लोड की एक श्रृंखला होगी, और जोड़े को जोड़ने और फिर परिणाम को वापस लाने के लिए पॉपिंग जोड़े) मशीन कोड स्तर पर उस तर्क की एक सीधी प्रतिलिपि में परिणाम नहीं होगा, लेकिन सवाल में मशीन के लिए कुछ और अधिक समझदार।
लेकिन आपके सवाल में कुछ और भी है।
किसी भी सेंस सी, सी ++, जावा, या सी # कंपाइलर के मामले में, मैं उम्मीद करूंगा कि आपके द्वारा दिए गए दोनों कथनों के परिणाम निम्नानुसार होंगे:
int a = 6;
परिणामी कोड को शाब्दिक गणित पर समय बर्बाद क्यों करना चाहिए? प्रोग्राम की स्थिति में कोई परिवर्तन का परिणाम बंद हो जाएगा 1 + 2 + 3जा रहा है 6, ताकि क्या कोड में जाना चाहिए निष्पादित किया जा रहा। वास्तव में, शायद यह भी नहीं है (आप उस 6 के साथ क्या करते हैं, इसके आधार पर, शायद हम पूरी चीज को फेंक सकते हैं, और यहां तक कि सी # के दर्शन के साथ "भारी रूप से अनुकूलन न करें, क्योंकि घबराना इस तरह से अनुकूलन करेगा" या तो उत्पादन करेगा के बराबर int a = 6या सिर्फ पूरी चीज को अनावश्यक के रूप में फेंक दें)।
हालांकि यह हमें आपके प्रश्न के संभावित विस्तार की ओर ले जाता है। निम्नलिखित को धयान मे रखते हुए:
int a = (b - 2) / 2;
/* or */
int a = (b / 2)--;
तथा
int c;
if(d < 100)
c = 0;
else
c = d * 31;
/* or */
int c = d < 100 ? 0 : d * 32 - d
/* or */
int c = d < 100 && d * 32 - d;
/* or */
int c = (d < 100) * (d * 32 - d);
(ध्यान दें, यह अंतिम दो उदाहरण C # मान्य नहीं हैं, जबकि यहाँ सब कुछ है, और वे C, C ++ और Java में मान्य हैं।)
यहाँ फिर से हम आउटपुट के मामले में बिलकुल समकक्ष कोड है। जैसा कि वे लगातार अभिव्यक्ति नहीं कर रहे हैं, वे संकलन समय पर गणना नहीं की जाएगी। यह संभव है कि एक रूप दूसरे की तुलना में तेज़ हो। कौन सा तेज है? यह प्रोसेसर पर निर्भर करेगा और शायद राज्य में कुछ मनमाने अंतर पर (विशेष रूप से अगर एक तेज है, तो यह बहुत तेज होने की संभावना नहीं है)।
और वे आपके प्रश्न से पूरी तरह से संबंधित नहीं हैं, क्योंकि वे ज्यादातर उस क्रम में अंतर के बारे में हैं जिसमें कुछ वैचारिक रूप से किया जाता है।
उनमें से प्रत्येक में, संदेह करने का एक कारण है कि एक दूसरे की तुलना में तेज़ हो सकता है। एकल वेतन वृद्धि में एक विशेष निर्देश हो (b / 2)--सकता है , इसलिए वास्तव में इससे भी तेज हो सकता है (b - 2) / 2। d * 32शायद तेजी से उत्पादन किया जा सकता है d << 5ताकि यह d * 32 - dतेजी से बना रहे हैं d * 31। पिछले दो के बीच के अंतर विशेष रूप से दिलचस्प हैं; एक कुछ मामलों में कुछ प्रसंस्करण को छोड़ देता है, लेकिन दूसरा शाखा गलत भविष्यवाणी की संभावना से बचता है।
इसलिए, यह हमें दो प्रश्नों के साथ छोड़ देता है: 1. क्या वास्तव में दूसरे की तुलना में तेज़ है? 2. क्या एक कंपाइलर धीमी गति को तेज में परिवर्तित करेगा?
और उत्तर 1. यह निर्भर करता है। 2. शायद।
या विस्तार करने के लिए, यह निर्भर करता है क्योंकि यह प्रश्न में प्रोसेसर पर निर्भर करता है। निश्चित रूप से ऐसे प्रोसेसर मौजूद हैं जहां भोले मशीन-कोड एक के बराबर होता है, दूसरे के बराबर भोले मशीन-कोड की तुलना में तेज़ होता है। इलेक्ट्रॉनिक कंप्यूटिंग के इतिहास के दौरान, ऐसा कोई भी नहीं था जो हमेशा तेज था, या तो (विशेष रूप से शाखा गलत भविष्यवाणी तत्व कई के लिए प्रासंगिक नहीं था, जब गैर-पाइपलाइड सीपीयू अधिक सामान्य थे)।
और हो सकता है, क्योंकि अलग-अलग ऑप्टिमाइज़ेशन का एक गुच्छा होता है जो कंपाइलर (और जिटर्स, और स्क्रिप्ट-इंजन) करते हैं, और जबकि कुछ को कुछ मामलों में अनिवार्य किया जा सकता है, हम आम तौर पर तार्किक समकक्ष कोड के कुछ टुकड़े ढूंढने में सक्षम होंगे यहां तक कि सबसे भोले संकलक के भी समान परिणाम होते हैं और तार्किक रूप से समतुल्य कोड के कुछ टुकड़े जहां सबसे परिष्कृत भी एक से दूसरे के लिए तेजी से कोड का उत्पादन करता है (भले ही हमें अपनी बात साबित करने के लिए कुछ पूरी तरह से विकृति लिखना हो)।
यह एक बहुत छोटे अनुकूलन चिंता की तरह लग सकता है,
नहीं, यहां तक कि मेरे द्वारा दिए गए लोगों की तुलना में अधिक जटिल मतभेदों के साथ, यह बिल्कुल मिनट की चिंता की तरह लगता है जिसका अनुकूलन के साथ कोई लेना-देना नहीं है। यदि कुछ भी हो, तो यह निराशा की बात है क्योंकि आपको संदेह है कि पढ़ने के लिए कठिन पढ़ने ((1 + 2) + 3में आसान से अधिक धीमा हो सकता है 1 + 2 + 3।
लेकिन C ++ / जावा / ... पर C ++ चुनना सभी अनुकूलन (IMHO) के बारे में है।
अगर यह वास्तव में C # या जावा पर C ++ का चयन करता है, तो "सभी के बारे में" मैं कहूंगा कि लोगों को स्ट्रॉस्ट्रुप और आईएसओ / आईईसी 14882 की अपनी प्रति जलानी चाहिए और कुछ और एमपी 3 या कुछ के लिए कमरे छोड़ने के लिए अपने सी ++ कंपाइलर के स्थान को खाली करना चाहिए।
इन भाषाओं के एक दूसरे पर अलग-अलग फायदे हैं।
उनमें से एक यह है कि सी ++ अभी भी आम तौर पर स्मृति उपयोग पर अधिक तेज़ और हल्का है। हाँ, ऐसे उदाहरण हैं जहां C # और / या जावा तेज़ हैं और / या बेहतर अनुप्रयोग-जीवनकाल मेमोरी का उपयोग करते हैं, और ये अधिक सामान्य होते जा रहे हैं क्योंकि तकनीक में सुधार हुआ है, लेकिन हम अभी भी C ++ में लिखे गए औसत प्रोग्राम की उम्मीद कर सकते हैं एक छोटा निष्पादन योग्य जो अपने काम को तेजी से करता है और उन दोनों भाषाओं में समकक्ष की तुलना में कम मेमोरी का उपयोग करता है।
यह अनुकूलन नहीं है।
ऑप्टिमाइज़ेशन का उपयोग कभी-कभी "चीजों को तेज़ी से बनाने" के लिए किया जाता है। यह समझने योग्य है, क्योंकि अक्सर जब हम "अनुकूलन" के बारे में बात कर रहे होते हैं तो हम वास्तव में चीजों को तेजी से आगे बढ़ाने के बारे में बात कर रहे हैं, और इसलिए एक दूसरे के लिए एक आशुलिपि बन गया है और मैं स्वीकार करता हूं कि मैं इस तरह से शब्द का दुरुपयोग करता हूं।
"चीजें तेजी से आगे बढ़ें" के लिए सही शब्द अनुकूलन नहीं है । यहाँ सही शब्द सुधार है । यदि आप एक कार्यक्रम में बदलाव करते हैं और एकमात्र सार्थक अंतर यह है कि यह अब तेज है, यह किसी भी तरह से अनुकूलित नहीं है, यह सिर्फ बेहतर है।
अनुकूलन तब होता है जब हम किसी विशेष पहलू और / या विशेष मामले के संबंध में सुधार करते हैं। आम उदाहरण हैं:
- यह अब एक उपयोग के मामले के लिए तेज़ है, लेकिन दूसरे के लिए धीमा है।
- यह अब तेज़ है, लेकिन अधिक मेमोरी का उपयोग करता है।
- यह अब स्मृति पर हल्का है, लेकिन धीमा है।
- अब यह तेज है, लेकिन इसे बनाए रखना कठिन है।
- अब इसे बनाए रखना आसान है, लेकिन धीमी गति से।
ऐसे मामलों को उचित ठहराया जाएगा यदि, उदाहरण के लिए:
- तेजी से उपयोग के मामले के साथ शुरू होने के लिए अधिक सामान्य या अधिक गंभीर रूप से बाधा है।
- कार्यक्रम अस्वीकार्य रूप से धीमा था, और हमने बहुत सारे रैम मुक्त हैं।
- कार्यक्रम रुक रहा था क्योंकि इसमें इतनी रैम का इस्तेमाल किया गया था कि इसकी सुपर-फास्ट प्रोसेसिंग को निष्पादित करने की तुलना में अधिक समय स्वैप किया गया था।
- कार्यक्रम अस्वीकार्य रूप से धीमा था, और कोड को समझने में मुश्किल अच्छी तरह से प्रलेखित और अपेक्षाकृत स्थिर है।
- कार्यक्रम अभी भी तेजी से स्वीकार्य है, और अधिक समझने योग्य कोड-बेस बनाए रखने के लिए सस्ता है और अन्य सुधारों को अधिक आसानी से करने की अनुमति देता है।
लेकिन, ऐसे मामलों को अन्य परिदृश्यों में भी उचित नहीं ठहराया जाएगा: गुणवत्ता के पूर्ण अचूक माप द्वारा कोड को बेहतर नहीं बनाया गया है, इसे किसी विशेष संबंध में बेहतर बनाया गया है जो इसे किसी विशेष उपयोग के लिए अधिक उपयुक्त बनाता है; अनुकूलित।
और भाषा की पसंद का यहाँ प्रभाव पड़ता है, क्योंकि गति, स्मृति का उपयोग, और पठनीयता सभी इससे प्रभावित हो सकते हैं, लेकिन इसलिए अन्य प्रणालियों के साथ संगतता, पुस्तकालयों की उपलब्धता, रनटाइम की उपलब्धता, किसी दिए गए ऑपरेटिंग सिस्टम पर उन रनटाइम की परिपक्वता हो सकती है। (अपने पापों के लिए मैंने किसी तरह लिनक्स और एंड्रॉइड को अपनी पसंदीदा OS के रूप में और C # को अपनी पसंदीदा भाषा के रूप में समाप्त किया, और जबकि मोनो महान है, लेकिन मैं अभी भी इस एक के खिलाफ आता हूं)।
यह कहना कि "C ++ / जावा / ... पर C ++ चुनना सभी के लिए अनुकूलन है" केवल तभी समझ में आता है जब आपको लगता है कि C ++ वास्तव में बेकार है, क्योंकि अनुकूलन "बेहतर होने के बावजूद ..." "बेहतर" नहीं है। अगर आपको लगता है कि C ++ अपने आप में बेहतर है, तो आपको जिस आखिरी चीज की आवश्यकता है, वह है ऐसे मिनटों के संभावित माइक्रो-ऑप्स के बारे में चिंता करना। वास्तव में, आप शायद इसे छोड़ना ही बेहतर समझते हैं; खुश हैकर्स भी एक गुणवत्ता के लिए अनुकूलित करने के लिए कर रहे हैं!
यदि फिर भी, आप "I C C से प्यार करते हैं, और जिन चीज़ों से मुझे प्यार है, उनमें से एक अतिरिक्त चक्र को निचोड़ रहा है", तो यह एक अलग बात है। यह अभी भी एक मामला है कि माइक्रो-ऑप्स केवल इसके लायक हैं अगर वे एक रिफ्लेक्सिव आदत हो सकते हैं (यानी, जिस तरह से आप स्वाभाविक रूप से कोड करते हैं, वह धीमी गति से अधिक बार होगा)। अन्यथा वे समय से पहले अनुकूलन नहीं कर रहे हैं, वे समय से पहले निराशा है कि बस चीजों को बदतर बनाते हैं।