जिस भाषा का कंपाइलर C में लिखा जाता है वह C की तुलना में अधिक तेज़ कैसे हो सकता है?

Question

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

चित्र: C के सापेक्ष बेंचमार्क समय (छोटा बेहतर है, C प्रदर्शन = 1.0)।

Comments

बारीकी से संबंधित प्रश्न ।

— राफेल

एक कार, जो एक मानव निर्मित वस्तु है, कैसे एक आदमी की तुलना में तेजी से आगे बढ़ सकती है?

— बबौ

तालिका के अनुसार, पायथन सी की तुलना में धीमा है। क्या आपको लगता है कि पायथन में सी कंपाइलर लिखना असंभव है जो आपके पसंदीदा सी कंपाइलर के समान कोड उत्पन्न करता है? और वैसे भी कौन सी भाषा है?

— कार्स्टन एस

बाबू की टिप्पणी हाजिर थी, लेकिन मुझे नहीं लगता कि हमें इसके कई संस्करणों की आवश्यकता है।

— राफेल

एक संबंधित विचार। कई संकलक स्वयं की मेजबानी कर रहे हैं, जिसका अर्थ है कि वे अपनी भाषा (अक्सर प्लस असेंबली) में लिखे गए हैं और स्वयं के पिछले संस्करण के साथ संकलित हैं। फिर भी संकलक बेहतर और तेज हो जाते हैं। मन का झटका ।

— श्वार्न

Answer 1

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

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

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

मान लीजिए कि हमने फोर्टन के लिए पायथन भाषा में एक कंपाइलर लिखा। हमारे संकलक GFortran के समान मशीन कोड का उत्पादन करते हैं। अब हम एक फोरट्रान कार्यक्रम संकलित करते हैं। हम अपने कंपाइलर को CPython के ऊपर चला सकते हैं, या हम इसे PyPy पर चला सकते हैं, क्योंकि यह Python में लिखा गया है और ये दोनों कार्यान्वयन समान Python भाषा को चलाते हैं। हम यह जानेंगे कि यदि हम अपने संकलक को CPython पर चलाते हैं, तो उसे PyPy पर चलाते हैं, फिर उसी फ़ोर्ट्रन स्रोत को GFortran के साथ संकलित करते हैं, हम तीनों बार बिल्कुल एक ही मशीन कोड प्राप्त करेंगे, इसलिए संकलित प्रोग्राम हमेशा चलेगा लगभग उसी गति से। हालांकि, उस संकलित कार्यक्रम का उत्पादन करने में लगने वाला समय अलग होगा। CPython को संभवतः PyPy की तुलना में अधिक समय लगेगा, और PyPy को संभवतः GFortran की तुलना में अधिक समय लगेगा, भले ही वे सभी अंत में एक ही मशीन कोड का उत्पादन करेंगे।

जूलिया वेबसाइट की बेंचमार्क टेबल को स्कैन करने से, ऐसा लगता है कि दुभाषियों (पायथन, आर, मैटलैब / ऑक्टेव, जावास्क्रिप्ट) पर चलने वाली भाषाओं में से कोई भी ऐसा नहीं है, जहां वे सी को हराते हों। यह आम तौर पर संगत होती है जो मैं देखने की उम्मीद करता हूं। यद्यपि मैं पायथन के अत्यधिक अनुकूलित Numpy लाइब्रेरी (C और फोरट्रान में लिखित) के साथ लिखे गए कोड की कल्पना कर सकता हूं, समान कोड के कुछ संभावित सी कार्यान्वयन को हरा सकता है। वे भाषाएँ जो C के बराबर या उससे बेहतर हैं उन्हें संकलित किया जा रहा है (फोरट्रान, जूलिया ) या आंशिक संकलन (जावा, और शायद LuaJIT) के साथ एक हाइब्रिड मॉडल का उपयोग कर रहा है। PyPy एक हाइब्रिड मॉडल का भी उपयोग करता है, इसलिए यह पूरी तरह से संभव है कि अगर हम CPython के बजाय PyPy पर समान Python कोड चलाएं, तो हम वास्तव में इसे कुछ बेंचमार्क पर C को हराते हुए देखेंगे।

Comments

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

— एलेक्स ए।

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

— प्रोग्राममेउड

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

— गेलक्विस्ट

@ghellquist ज़रूर, अगर बेंचमार्क पर्याप्त कृत्रिम है और कंपाइलर पर्याप्त स्मार्ट है। यह सीधे या सीधे संकलक की कार्यान्वयन भाषा से संबंधित नहीं है, हालांकि, इसलिए मैंने इसका उल्लेख यहां नहीं किया है।

— tsleyson

Answer 2

आदमी द्वारा बनाई गई मशीन आदमी से ज्यादा मजबूत कैसे हो सकती है? यह बिल्कुल वही सवाल है।

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

Comments

एक शतरंज कार्यक्रम कैसे मानव को हरा सकता है जिसने इसे लिखा है?

— थोरबजोरन रावन एंडरसन

बेहतर चाल बनाकर! <rimshot>

— टोनी

पेन गिलिएट के जवाब को समझने के लिए कि यह क्यों नहीं मायने रखता है कि एक कंप्यूटर शतरंज में एक आदमी को हरा सकता है: "क्या आप जीई द्वारा डिज़ाइन किए गए रोबोट से बॉक्सिंग मैच में किसी व्यक्ति से हारने की उम्मीद करेंगे?"

— डेव कंटर

Answer 3

मैं एक आम धारणा के खिलाफ एक बिंदु बनाना चाहता हूं, जो मेरी राय में, नौकरी के लिए उपकरण चुनते समय हानिकारक होने के बिंदु तक पहुंचता है।

धीमी या तेज भाषा जैसी कोई चीज नहीं है। ¹

सीपीयू के हमारे रास्ते पर वास्तव में कुछ कर रहे हैं, कई चरण हैं।

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

हर एक आइटम वास्तविक रनटाइम में योगदान देता है जिसे आप कभी-कभी भारी मात्रा में माप सकते हैं। विभिन्न "भाषाएं" अलग-अलग चीजों पर ध्यान केंद्रित करती हैं।

बस कुछ उदाहरण देने के लिए।

• 1 बनाम 2-4 : एक औसत सी प्रोग्रामर एक औसत जावा प्रोग्रामर की तुलना में कहीं अधिक खराब कोड का उत्पादन करने की संभावना है, दोनों शुद्धता और दक्षता के मामले में। ऐसा इसलिए है क्योंकि प्रोग्रामर की सी में अधिक जिम्मेदारियां हैं।

• 1/4 बनाम 7 : सी जैसी निम्न-स्तरीय भाषा में, आप प्रोग्रामर के रूप में कुछ सीपीयू सुविधाओं का दोहन करने में सक्षम हो सकते हैं । उच्च-स्तरीय भाषाओं में, केवल कंपाइलर / दुभाषिया ऐसा कर सकते हैं, और केवल तब जब वे लक्ष्य सीपीयू को जानते हैं ।

• 1/4 बनाम 5 : क्या आप चाहते हैं या हाथ में मेमोरी आर्किटेक्चर का सबसे अच्छा उपयोग करने के लिए मेमोरी लेआउट को नियंत्रित करना है? कुछ भाषाएँ आपको उस पर नियंत्रण देती हैं, कुछ नहीं।

• 2/4 बनाम 3 : व्याख्या की गई अजगर अपने आप में बहुत धीमी है, लेकिन वैज्ञानिक कंप्यूटिंग के लिए अत्यधिक अनुकूलित, मूल रूप से संकलित पुस्तकालयों के लिए लोकप्रिय बाइंडिंग हैं । इसलिए पायथन में कुछ चीजें करना अंत में तेज़ है, अगर ज्यादातर काम इन पुस्तकालयों द्वारा किया जाता है।

• 2 बनाम 4 : मानक रूबी दुभाषिया काफी धीमा है। दूसरी ओर, Jububy बहुत तेज हो सकता है। यह वही भाषा है जो किसी अन्य संकलक / दुभाषिया का उपयोग करके तेजी से होती है।

• 1/2 बनाम 4 : संकलक अनुकूलन का उपयोग करते हुए, सरल कोड को बहुत कुशल मशीन कोड में अनुवादित किया जा सकता है।

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

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

---

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

3. मैं जानबूझकर अलग-अलग सफलता के मैट्रिक्स में यहाँ नहीं जाता हूँ: समय दक्षता, मेमोरी दक्षता, डेवलपर समय, सुरक्षा, सुरक्षा, (साबित?) शुद्धता, उपकरण समर्थन, प्लेटफ़ॉर्म इंडिपेंडेंसी, ...

   भले ही वे पूरी तरह से अलग-अलग लक्ष्यों के लिए डिज़ाइन किए गए हों, किसी भी मीट्रिक की तुलना में एक बड़ी गिरावट है।

Comments

@ बबौ सहमत, बहुत अच्छी व्याख्या। तो क्या एक बेहतर मीट्रिक, या शायद मैट्रिक्स का सेट होगा , जिसका उपयोग भाषाओं को अपने संबंधित संकलक / दुभाषियों के साथ तुलना करने के लिए किया जा सकता है? इसके अलावा, एक छोटी सी नाइट्रिक: आप कहते हैं "धीमी या तेज भाषा जैसी कोई चीज नहीं है" और फिर "पायथन खुद बहुत ही धीमी है", लेकिन मुझे लगता है कि आप पायथन दुभाषिया का मतलब है।

— स्ट्रगलिंगप्रोग्रामर

@benalbrecht मेरा कहना है कि ऐसे मेट्रिक्स का एक भी अच्छा सेट नहीं है। यह हमेशा से एक व्यापार है। यदि आप डिवाइस ड्राइवर बनाते हैं, तो आप सभी चीजों के ऊपर सही होना चाहते हैं। यदि आप ट्विटर की रीढ़ बनाते हैं, तो आप सभी से ऊपर कुशल होना चाहते हैं। दोनों ही मामलों में, आप टूल का उपयोग करते हैं और इसके लिए अनुमति देने वाले लोगों को किराए पर लेते हैं। यदि आप एक एंड्रॉइड-ऐप-टिंकरिंग स्टार्टअप हैं, तो आप उन लोगों का उपयोग करते हैं जो आपके लोगों को जानते हैं और / या आपके समय-समय पर बाजार को कम करते हैं। यदि आप एल्गोरिदम सिखाते हैं, तो आप संक्षिप्त, स्पष्ट वाक्यविन्यास और थोड़ा बॉयलरप्लेट के साथ एक भाषा चाहते हैं। और इसी तरह। प्राथमिकताएं अलग-अलग हैं, और इसलिए हमारे पास अलग-अलग भाषाएं हैं।

— राफेल

इससे संबंधित संबंधित प्रश्न भी देखें ।

— राफेल

Answer 4

यहां अनुकूलन के बारे में एक भूल गई बात है।

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

इसलिए कोड समान नहीं थे, सी परीक्षण की गई फ़ाइलों में कोई __restrict नहीं था, जिसने मतभेदों को फिर से लिखने के बाद संकलक को बताया कि यह पॉइंटर्स को अनुकूलित कर सकता है, रनटाइम समान हो जाते हैं।

यहाँ मुद्दा यह है, कि कुछ अनुकूलन तकनीकें नव निर्मित भाषा में आसान (या कानूनी होने लगती हैं) हैं।

$X$

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

इस परीक्षण में जेएस भी है, अच्छी तरह से वी 8 की तुलना में तेजी से वीएम हैं, और यह कुछ परीक्षणों में सी की तुलना में तेजी से प्रदर्शन भी करता है।

मैंने इसे जाँच लिया है, और सी संकलक में अभी तक अद्वितीय अनुकूलन तकनीक उपलब्ध नहीं थे।

सी कंपाइलर को एक बार में पूरे कोड का स्थैतिक विश्लेषण करना होगा, दिए गए प्लेटफॉर्म पर मार्च करना होगा और मेमोरी संरेखण समस्याओं के आसपास जाना होगा।

VM ने कोड को अनुकूलित असेंबली और इसे चलाने के लिए कोड का केवल अनुवाद किया।

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

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

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

Answer 5

पिछले जवाब बहुत ज्यादा स्पष्टीकरण देते हैं, हालांकि ज्यादातर एक व्यावहारिक कोण से, जितना कि प्रश्न समझ में आता है , जैसा कि राफेल के उत्तर द्वारा उत्कृष्ट रूप से समझाया गया है ।

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

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

संकलक क्या है?

$C_{S\to T}$$C$$\mathcal C_{S\to T}$$P_{:S}$$\mathcal P$ $S$$P_{:T}$ $T$$\mathcal P$

$\mathcal C_{S\to T}$$C_{S\to T}$$\{(P_{:S},P_{:T})\mid P_S\in S \wedge P_T\in T\}$

$\mathcal C_{S\to T}$$P_S$$P_T$$\mathcal P$

$P_{:T}$$P_{:S}$$\mathcal C_{S\to T}$

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

बूटस्ट्रैपिंग के बारे में

यह भेद को चित्रित करेगा, और एक व्यावहारिक अनुप्रयोग दिखाएगा।

अब एक भाषा लागू करना आम बात हो गई है$S$$I_S$$C_{S\to T\,:S}$$S$$C_{S\to T\,:S}$$I_S$$P_{:S}$$P_{:T}$$S$$T$

लेकिन आप कंपाइलर को संकलित करने के लिए इस संकलन सुविधा का उपयोग कर सकते हैं $C_{S\to T\,:S}$$S$$C_{S\to T\,:T}$$T$$T$$T$

Comments

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

— राफेल

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

— बबौ

@ राफेल चूंकि आपने अपनी टिप्पणी नहीं हटाई है, तो क्या इसका मतलब यह है कि मैंने इसे गलत समझा, या इसका सही जवाब नहीं दिया? यह कैसे होता है कि एक फ़ंक्शन के रूप में संकलक (संकलित कार्यक्रम का नहीं) का दृश्य बहुत सीमित है, एक अर्थ बिंदु से। बेशक, एक समारोह के रूप में, यह केवल संकलित कार्यक्रम, जैसे कि अनुकूलन निर्देश) के अलावा अन्य तर्क ले सकता है लेकिन यह एक ऐसा विवरण है जो चर्चा को नहीं बदलेगा।

— babou

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

— राफेल

$\mathcal C$$\mathcal P$

Answer 6

द्वारा ब्लम के speedup प्रमेय प्रोग्राम जो लिखा है और बहुत सबसे तेजी से कंप्यूटर / संकलक संयोजन पर चलने अपना पहला पीसी चल रहा है बुनियादी व्याख्या पर एक ही के लिए एक कार्यक्रम की तुलना में धीमी चलेंगे देखते हैं। वहाँ सिर्फ एक "सबसे तेज भाषा" नहीं है। आप सभी कह सकते हैं कि यदि आप एक ही एल्गोरिदम को कई भाषा में लिखते हैं (कार्यान्वयन के रूप में, जैसा कि उल्लेख किया गया है, चारों ओर विभिन्न सी कंपाइलर हैं, और मैं भी एक सक्षम सी दुभाषिया भर में आया हूं), यह प्रत्येक में तेजी से या धीमी गति से चलेगा। ।

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

Comments

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

— क्यूबिक

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

— Jörg W Mittag

... ऊ और अभिनेता मॉडल की नींव। APL को गणित पढ़ाने के लिए एक नोटेशन के रूप में डिजाइन किया गया था। जूलिया को वैज्ञानिक प्रोग्रामिंग के लिए डिज़ाइन किया गया था। वे सभी भाषाएँ अब अपने मूल समस्या डोमेन के बाहर उपयोग की जाती हैं, लेकिन अभी भी उन भाषाओं में कुछ गुण हैं जो उन्हें कुछ विशेष प्रकार के अनुप्रयोगों के लिए बेहतर या बदतर बनाते हैं, भले ही वे सभी प्रकार के पाठ बनाने के लिए उपयोग किए जा सकते हैं बातें।

— जोर्ज डब्ल्यू मित्तग

Answer 7

आइए मूल पंक्ति पर वापस जाएं: "कोई भाषा जिसका कंपाइलर C में लिखा गया है वह C से अधिक तेज़ कैसे हो सकता है?" मुझे लगता है कि यह वास्तव में कहने का मतलब है: जूलिया में लिखा गया एक कार्यक्रम, जिसका मूल सी में लिखा गया है, कभी भी सी में लिखे गए प्रोग्राम से तेज हो सकता है? विशेष रूप से, जूलिया में लिखे गए "मैंडेल" कार्यक्रम को सी में लिखे गए "मंडेल" कार्यक्रम के निष्पादन समय के 87% में कैसे चलाया जा सकता है?

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

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

एक ऐसी प्रोग्रामिंग भाषा की कल्पना कर सकता है जिसमें "प्लस" और "मल्टीप्लेयर" ऑपरेटर हो और दूसरी भाषा जिसमें केवल "प्लस" हो। यदि आपकी गणना के लिए गुणन की आवश्यकता है, तो एक भाषा "धीमी" होगी क्योंकि बेशक सीपीयू दोनों सीधे कर सकते हैं, लेकिन यदि आपके पास 5 * 5 को गुणा करने की आवश्यकता को व्यक्त करने का कोई तरीका नहीं है, तो आपको "5" लिखना होगा। + ५ + ५ + ५ + ५ ”। उत्तरार्द्ध को एक ही उत्तर पर पहुंचने में अधिक समय लगेगा। संभवतः, इसमें से कुछ जूलिया के साथ चल रहा है; शायद भाषा प्रोग्रामर को सी में सीधे व्यक्त करने के लिए संभव नहीं है, इस तरह से सेट एक मेन्डेलब्रोट की गणना के वांछित लक्ष्य को बताने की अनुमति देता है।

बेंचमार्क के लिए उपयोग किए जाने वाले प्रोसेसर को Xeon E7-8850 2.00GHz CPU के रूप में सूचीबद्ध किया गया था। सी बेंचमार्क ने gc 4.8.2 कंपाइलर का उपयोग उस सीपीयू के लिए निर्देश बनाने के लिए किया, जबकि जूलिया LLVM कंपाइलर फ्रेमवर्क का उपयोग करता है। यह संभव है कि gcc का बैकएंड (वह भाग जो किसी विशेष CPU आर्किटेक्चर के लिए मशीन कोड का उत्पादन करता है) LLVM बैकएंड के रूप में किसी तरह उन्नत नहीं है। जिससे प्रदर्शन में फर्क आ सके। कई अन्य चीजें भी चल रही हैं - संकलक प्रोग्रामर द्वारा निर्दिष्ट की तुलना में एक अलग क्रम में शायद निर्देश जारी करके "अनुकूलन" कर सकता है, या यहां तक ​​कि कुछ चीजें बिल्कुल भी नहीं कर सकता है यदि यह कोड का विश्लेषण कर सकता है और निर्धारित कर सकता है कि वे नहीं हैं। सही उत्तर पाने के लिए आवश्यक है। और प्रोग्रामर ने C प्रोग्राम का एक हिस्सा इस तरह से लिखा हो सकता है कि इसे धीमा करें, लेकिन didn '

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

Answer 8

संकलित कार्यक्रम की गति दो बातों पर निर्भर करती है:

1. इसे निष्पादित करने वाली मशीन की प्रदर्शन विशेषताएं
2. निष्पादन योग्य फ़ाइल की सामग्री

एक संकलक जिस भाषा में लिखा गया है वह (1) के लिए अप्रासंगिक है। उदाहरण के लिए, एक जावा कंपाइलर को C या Java या पायथन में लिखा जा सकता है, लेकिन सभी मामलों में प्रोग्राम को निष्पादित करने वाली "मशीन" JVM है।

एक संकलक जिस भाषा में लिखा जाता है वह (2) के लिए अप्रासंगिक है। उदाहरण के लिए, कोई कारण नहीं है कि पायथन में लिखा गया सी कंपाइलर सी या जावा में लिखे गए सी कंपाइलर के समान बिल्कुल निष्पादन योग्य फ़ाइल का उत्पादन नहीं कर सकता है।

Answer 9

मैं एक छोटे से उत्तर देने की कोशिश करूँगा।

प्रश्न का मूल भाषा की "गति" की परिभाषा में निहित है ।

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

* मान्यताएँ कभी-कभी गलत होती हैं।

Answer 10

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

लेकिन अगर भाषा X एक व्याख्या की गई भाषा है, और दुभाषिया C में लिखा गया है, और अगर हम मानते हैं कि भाषा X और C में लिखित कोड की व्याख्या एक ही C संकलक द्वारा की गई है, तो किसी भी तरह से X में लिखे गए कोड को आउटफ़ॉर्म कोड में नहीं जाना चाहिए। सी में लिखा गया है, बशर्ते दोनों कार्यान्वयन समान एल्गोरिथ्म का पालन करते हैं और समान डेटा संरचनाओं का उपयोग करते हैं।

Comments

यह पिछले उत्तरों के साथ क्या जोड़ता है? इसके अलावा, मुझे नहीं लगता कि अन्य उत्तरों में दिए गए कारणों से आपका दूसरा पैराग्राफ सही है।

— राफेल