पूरे कार्यक्रम अनुकूलन अब अधिक प्रचलित क्यों नहीं हैं?

Question

मुख्य प्रश्न: हमारे दैनिक जीवन का सामान्य या यहां तक ​​कि विशेष कार्यक्रम अनुकूलक हिस्सा क्यों नहीं हैं?

मैं SuperCompilers पढ़ने के बाद इस बारे में सोचना शुरू कर दिया, एलएलसी के White paper है, जो करने के लिए "supercompiling" या metacompiling एक कार्यक्रम के स्रोत के अपने विधि पर चर्चा करता है (आम तौर पर) है कि मूल कार्यक्रम के रूप में ही कार्यक्षमता करता है एक तेजी से संस्करण को प्राप्त। अनिवार्य रूप से वे एक कार्यक्रम के निष्पादन के माध्यम से कदम और एक ही लक्ष्य भाषा में recompile। ऐसा करके, प्राकृतिक अनुकूलन होते हैं; उदाहरण के लिए, यदि इनपुट प्रोग्राम 100 आइटमों के सरणी का उपयोग करता है, तो सामान्य बाइनरी खोज फ़ंक्शन बाइनरी 100 आइटमों की एक सरणी खोजने के लिए विशिष्ट हो सकता है।

Partial Evaluation शायद एक अधिक संकीर्ण प्रकार का संपूर्ण प्रोग्राम अनुकूलन है, जहां प्रोग्राम के स्रोत को इनपुट के कुछ निश्चित सेट के आधार पर कम/मूल्यांकन किया जाता है जबकि रनटाइम पर मूल्यांकन किए जाने वाले अज्ञात इनपुट को छोड़ दिया जाता है। उदाहरण के लिए, एक सामान्य फ़ंक्शन x^y, यदि दिया गया है y = 5, को x^5 या शायद कुछ (x * x) * (x * x) * x में घटाया जा सकता है।

ऐतिहासिक पूरे कार्यक्रम अनुकूलन (मैं इन दो तकनीकों के अपने कच्चे विवरण के लिए माफी माँगता हूँ) इस तरह के दो से ऊपर भी स्मृति गहन प्रदर्शन करने के लिए है, लेकिन हमारे मशीनों के साथ किया जाएगा के रूप में स्मृति के gigs (या की तरह कुछ का उपयोग कर क्लाउड), हमने ओपन सोर्स आंशिक मूल्यांकनकर्ताओं और वसंत की तरह क्यों नहीं देखा है? मैंने कुछ देखा है, लेकिन मैंने सोचा होगा कि यह हमारी टूल श्रृंखला का एक नियमित हिस्सा होगा।

• क्या यह डर है (प्रोग्रामर बग पेश करने वाले उनके कोड के परिवर्तन से डरते हैं)?
• क्या यह इसके लायक नहीं है (यानी वेब ऐप्स के लिए बाधा I/O है, और इस प्रकार का अनुकूलन CPU समय सहेज रहा है)?
• क्या यह सॉफ्टवेयर है जो लिखने के लिए मुश्किल है ?
• या, की मेरी धारणा यह गलत है?

Answer 1

मुझे लगता है कि यह अधिकतर आपकी धारणा गलत है। अधिकांश कंपाइलर्स वास्तविक उपयोग के आधार पर अनुकूलक को मार्गदर्शन करने के लिए "संपूर्ण कार्यक्रम" (इंटरप्रोसेडुरल) अनुकूलन, और प्रोफ़ाइल-निर्देशित अनुकूलन का समर्थन करते हैं।

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

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

Answer 2

मेरा अनुमान है कि यह एक चिकन अंडे की समस्या है, मुझे इसे समझाएं।

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

तो यदि वहां (आज) कोई एससी नहीं है, तो प्रोग्रामर "निम्न स्तर" कोड लिखते हैं, इसलिए कोई भी बेहतर कोड नहीं लिखता है और भारी उठाने के लिए एससी की जरूरत होती है।

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

एक अन्य कारण यह है कि एससी आज आम नहीं है, यह है कि यह सापेक्ष रूप से नया है (अधिक पुरानी संकलन तकनीक की तुलना में), एससी 70 के दशक में विकसित किया गया था और संकलन लागत स्केल नॉनलाइनर है, इसलिए इसका लक्ष्य नहीं है बड़े कंपाइलर विक्रेताओं।

अधिक सार कोड मेरा मतलब है

• डेटाप्रकार स्वतंत्र कोड लिखने की क्षमता के साथ

  , तो यह अंत में होगा (अधिकांश भाग के लिए) टेम्पलेट्स/जेनरिक अप्रचलित बनाने

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

Answer 3

पूछने के लिए धन्यवाद मैं एक गहरा सवाल मानता हूं, और कृपया मेरी लौ को माफ कर दें ...

आंशिक मूल्यांकन एक सुंदर अवधारणा है जिसकी सुंदरता पूरी तरह से चालाक लेकिन दिमागहीन उपकरण बनाने के लिए अंतहीन इच्छाओं में पूरी तरह से खो गई है ताकि चीजों को हाथों से बाहर निकाला जा सके/प्रोग्रामर के दिमाग यही कारण है कि उसने बहुत कुछ नहीं किया है।

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

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

वही सामान्य रूप से अनुकूलन के लिए जाता है। जब प्रोग्रामर अपने उपकरण को एक उपकरण पर आत्मसमर्पण करता है, बहुत कम परिणाम, क्योंकि कोई उपकरण नहीं है (फिर भी, कम से कम) जो प्रोग्रामर के तरीके को कोड को समझ सकता है।

यह निश्चित रूप से सार्थक को कोशिश उपकरण है कि कोड के रूप में अच्छी तरह से प्रोग्रामर के रूप में करता है समझते हैं, लेकिन यह मान लेना कि यह किया गया है मूर्ख है।