चरणबद्ध कार्य (वैचारिक रूप से) क्या हैं?


24

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

वे एक छोटी व्याख्या देते हैं (जोर मेरा और संदर्भ संख्या बदल गया है; यह मूल में 22 है)

कार्यक्रम पीढ़ी के संदर्भ में, ताहा और शीर्ड द्वारा स्थापित मल्टीस्टेज प्रोग्रामिंग (एमएसपी, शॉर्ट के लिए मंचन) [2] प्रोग्रामर को प्रोग्राम अभिव्यक्ति के मूल्यांकन के बाद के चरण (इस प्रकार, अभिव्यक्ति का मंचन) को स्पष्ट रूप से विलंबित करने की अनुमति देता है । वर्तमान चरण प्रभावी रूप से एक कोड जनरेटर के रूप में कार्य करता है जो अगले चरण के कार्यक्रम की रचना (और संभवतः निष्पादित करता है) करता है।

हालाँकि, ताहा और शीरड लिखते हैं (जोर मेरा):

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

वे पुराने काम के कई संदर्भों पर जाने से कथित तौर पर दिखाते हैं कि मंचन प्रभावी है, जो बताता है कि अवधारणा और भी पुरानी है। वे शब्द के लिए ही संदर्भ नहीं देते हैं।

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

तो, क्या कर रहा है के मंचन क्रमशः इस संदर्भ में मंचन की व्याख्या कर रहे हैं? शब्द कहाँ से आता है?


  1. लाइटवेट मॉड्यूलर स्टेजिंग: टी। रोमपफ और एम। ओडस्की (2012) द्वारा रनटाइम कोड जेनरेशन और कम्प्लाइस्ड डीएसएल के लिए एक व्यावहारिक दृष्टिकोण
  2. डब्ल्यू। ताहा और टी। शीर्ड (2000) द्वारा स्पष्ट एनोटेशन के साथ मेटाएमएल और मल्टी-स्टेजप्रोग्रामिंग

आप दो बयानों के बीच क्या विरोधाभास देखते हैं? मेरे लिए, वे देखते हैं कि वे एक ही चीज़ के बारे में बात कर रहे हैं, अलग जोर के साथ।
गिल्स एसओ- बुराई को रोकना '

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

आप जूलिया प्रोग्रामिंग लैंग्वेज इम्प्लीमेंटेशन और मेटाप्रोग्रामिंग डॉक्यूमेंटेशन की जाँच कर सकते हैं @generated function: julia.readthedocs.org/en/latest/manual/metaprogramming/…
साल्चीपापा

जवाबों:


21

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

आप एक समारोह है, तो दो तर्क की, लेकिन आप एक तर्क पता है, का कहना है कि मीटर है, तो आप समारोह तुरंत पहले तर्क के ज्ञान का उपयोग कर की गणना के कुछ प्रदर्शन कर सकते हैं। फिर आप जो बचे हैं वह एक फ़ंक्शन ϕ m ( n ) है जिसकी गणना केवल दूसरे, अज्ञात, तर्क पर निर्भर करती है।ϕ(m,n)mϕm(n)

ϕm(n) ϕmnϕmϕmn

ϕmϕmϕm

ϕϕ

  • मंचन कार्यों को कैसे परिभाषित किया जाए?
  • मंचन कार्यों को परिभाषित करने के लिए किस प्रोग्रामिंग लैंग्वेज और टाइप सिस्टम का उपयोग किया जाना चाहिए?
  • ऐसी भाषाओं का शब्दार्थ क्या है?
  • हम मंचन किए गए कार्यों की सुसंगतता और शुद्धता को कैसे सुनिश्चित करते हैं?
  • स्वचालित रूप से या अर्ध-स्वचालित रूप से चरणबद्ध कार्यों के निर्माण के लिए कौन सी तकनीक उपयोगी हैं?
  • हम इस तरह की तकनीकों की शुद्धता कैसे साबित करते हैं?

अभ्यास में मंचित संगणना बहुत महत्वपूर्ण हो सकती है। वास्तव में, हर संकलक एक संगणित संगणना प्रभाव में होता है। एक स्रोत कार्यक्रम को देखते हुए, यह एक अनुवादित और अनुकूलित लक्ष्य कार्यक्रम का निर्माण करता है, जो तब वास्तविक इनपुट ले सकता है और परिणाम की गणना कर सकता है। अभ्यास में मंचित संगणना कार्यक्रमों को लिखना कठिन होता है क्योंकि हमें कई चरणों को टटोलना पड़ता है और सुनिश्चित करना होता है कि सही चीजें सही समय पर की जाएं। कंपाइलर लिखने वाला हर व्यक्ति इस तरह के मुद्दों से जूझता रहा है। अन्य प्रोग्राम लिखने वाले प्रोग्रामों को लिखना भी कठिन है, वे मशीन भाषा के प्रोग्राम (कंपाइलर), SQL क्वेरी (डेटाबेस जोड़तोड़) या HTML / सर्वर पेज / जावास्क्रिप्ट कोड (वेब ​​एप्लिकेशन) और अन्य एप्लिकेशन के असंख्य हो सकते हैं।


ϕϕ

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

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

9

यद्यपि अन्य उत्तर तकनीकी रूप से सही हैं, मुझे नहीं लगता कि वे इस बात की सही समझ देते हैं कि कंप्यूटर वैज्ञानिक मंचन के कार्यों में क्यों रुचि रखते हैं।

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

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

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

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

Czarnecki और Eisenecker (ISBN-13: 978-0201309775) द्वारा "जनरेटिव प्रोग्रामिंग" देखें।


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

देखने का यह डीएसएल बिंदु एक स्तर (कार्यक्रम के अंदर एक डीएसएल संकलक) को सही करने के लिए मंचन लगता है?
राफेल

1
@ राफेल: यह वास्तव में आपके दृष्टिकोण पर निर्भर करता है। जाहिर है, इस अवधारणा को कोई कम्प्यूटेशनल शक्ति नहीं मिलती है, जब स्रोत -> निष्पादन योग्य अनुवाद के रूप में देखा जाता है। हम डीएस भाषा के लिए एक संकलक का निर्माण कर सकते हैं और किया जा सकता है। यह ताकत कहां से आई है, यह पुनरावृत्ति में है। भविष्य में परियोजनाओं द्वारा उपयोग और विस्तारित किए जाने वाले पुस्तकालयों का निर्माण करते समय, पुस्तकालय की सीमाओं के अंदर प्राकृतिक चरण दिखाई देंगे। आपके पास एक पुस्तकालय हो सकता है जो ऑब्जेक्ट विशेषताओं को पूर्ण क्रमांकन के लिए स्रोत में बदल देता है, और फिर एक अन्य पुस्तकालय जो कुछ प्रेषण युक्ति पर निर्मित परिवहन परत बनाता है ...
ex0du5

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

5

प्रश्न में लेख के लिए तकनीकी परिप्रेक्ष्य में उत्तर दिया गया है [1]। विचाराधीन समस्या सामान्य और विशिष्ट कोड के बीच तनाव का क्षेत्र है:

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

निश्चित रूप से हम इस तनाव को हल करना चाहते हैं, यह सामान्य कोड और विशिष्ट कार्यान्वयन है:

हम सवाल पूछ सकते हैं: क्या यह कोड लिखना संभव है ताकि यह सामान्य उद्देश्य हो लेकिन फिर क्या यह अपने आप ही निष्पादन के लिए स्थिति में खुद को माहिर कर लेता है?

इसने (सामान्य) कार्यक्रमों के विचार को जन्म दिया है (पुनः) एक विशेष स्थिति के लिए स्वयं को रनटाइम पर लिखने के लिए:

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

मुझे लगता है कि जावा का जेआईटी एक अच्छा उदाहरण है। एक विशेष विचार मल्टी-स्टेज प्रोग्रामिंग है, जो ली इस तरह से बताते हैं:

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

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

रोमपफ और ओडस्की ने एक उदाहरण के रूप में तेजी से फूरियर रूपांतरण का उल्लेख किया जो शिक्षाप्रद हो सकता है।


  1. लोमड़ी और हेजहोग: पीटर ली (2012) द्वारा तकनीकी परिप्रेक्ष्य
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.