गो इतनी जल्दी कैसे संकलन करता है?

Question

मैंने Go वेबसाइट के चारों ओर Googled और poked किया है, लेकिन मुझे Go के असाधारण बिल्ड समय के लिए स्पष्टीकरण नहीं मिल रहा है। क्या वे भाषा सुविधाओं के उत्पाद (या इसके अभाव), एक अत्यधिक अनुकूलित संकलक, या कुछ और हैं? मैं गो को बढ़ावा देने की कोशिश नहीं कर रहा हूं; मैं सिर्फ उत्सुक हूँ।

Comments

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

— एडम क्रॉसलैंड

इस सवाल का निराशावादी संस्करण है "C ++ इतनी धीरे-धीरे क्यों संकलन करता है?" stackoverflow.com/questions/588884/…

— dan04

मैंने इस सवाल को फिर से खोलने के लिए मतदान किया क्योंकि यह राय आधारित नहीं है। एक भाषा और / या संकलक विकल्प का एक अच्छा तकनीकी (गैर-राय) अवलोकन दे सकता है जो संकलन की गति को सुविधाजनक बनाता है।

— मार्टिन टूरनोइज

छोटी परियोजनाओं के लिए, गो मुझे धीमा लगता है। ऐसा इसलिए है क्योंकि मुझे याद है कि टर्बो-पास्कल एक ऐसे कंप्यूटर पर कहीं अधिक तेज था जो शायद हजारों गुना धीमा था। prog21.dadgum.com/47.html?repost=true । हर बार जब मैं "गो बिल्ड" टाइप करता हूं और कई सेकंड के लिए कुछ भी नहीं होता है, तो मुझे लगता है कि वापस पुराने फोरट्रान संकलक और छिद्रित कार्ड। YMMV। TLDR: "धीमी" और "तेज" सापेक्ष शब्द हैं।

— RedGrittyBrick

निश्चित रूप से dave.cheney.net/2014/06/07/five-things-that-make-go-fast को और अधिक विस्तृत जानकारी के लिए पढ़ने की सलाह देते हैं

— कार्तिक

Answer 1

निर्भरता का विश्लेषण।

जाओ पूछे जाने वाले प्रश्न निम्नलिखित वाक्य को रोकने के लिए प्रयोग किया जाता है:

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

जबकि वाक्यांश अब एफएक्यू में नहीं है, यह विषय Google पर चर्चा गो में विस्तृत है , जो सी / सी ++ और गो के निर्भरता एनालिसिस दृष्टिकोण की तुलना करता है।

यही तेज संकलन का मुख्य कारण है। और यह डिजाइन द्वारा है।

Comments

यह वाक्यांश अब Go FAQ में नहीं है, लेकिन C / C ++ और पास्कल / मोडुला / गो दृष्टिकोण की तुलना करने वाले "निर्भरता विश्लेषण" विषय का अधिक विस्तृत विवरण Google पर

— rob74

Answer 2

मुझे लगता है कि यह नहीं है कि गो संकलक तेज हैं , यह है कि अन्य संकलक धीमी हैं ।

C और C ++ कंपाइलर्स को भारी मात्रा में हेडर्स को पार्स करना होता है - उदाहरण के लिए, C ++ "हेल्लो वर्ल्ड" को संकलित करने के लिए कोड की 18k लाइनों की आवश्यकता होती है, जो कि स्रोतों का लगभग आधा मेगाबाइट है!

$ cpp hello.cpp | wc
  18364   40513  433334

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

संकलन की गति कई कारकों पर निर्भर करती है।

कुछ भाषाओं को तेजी से संकलित करने के लिए डिज़ाइन किया गया है। उदाहरण के लिए, पास्कल को सिंगल-पास कंपाइलर का उपयोग करके संकलित करने के लिए डिज़ाइन किया गया था।

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

Comments

Microsoft का C # कंपाइलर VM में नहीं चलता है। यह अभी भी C ++ में लिखा गया है, मुख्य रूप से प्रदर्शन कारणों के लिए।

— ब्लीच

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

— TheBlastOne

कोड की 18k लाइनें (18364 सटीक होना) 433334 बाइट्स (~ 0,5MB)

— el.pescado

2011 के बाद से C # कंपाइलर C # के साथ संकलित किया गया है। यदि कोई इसे बाद में पढ़ता है तो बस एक अपडेट।

— कुर्ट कोल्लर

C # कंपाइलर और CLR जो उत्पन्न MSIL को चलाता है, हालांकि अलग-अलग चीजें हैं। मुझे पूरा यकीन है कि CLR C # में नहीं लिखा गया है।

— jocull

Answer 3

गो संकलक अधिकांश C / C ++ संकलक की तुलना में बहुत तेज़ होने के कई कारण हैं:

• शीर्ष कारण : अधिकांश C / C ++ कंपाइलर असाधारण खराब डिजाइन (संकलन गति के नजरिए से) का प्रदर्शन करते हैं। इसके अलावा, संकलन की गति के दृष्टिकोण से, C / C ++ पारिस्थितिकी तंत्र के कुछ हिस्से (जैसे कि प्रोग्रामर जिसमें अपने कोड लिख रहे हैं) को गति-संकलन के साथ दिमाग में नहीं बनाया गया है।

• शीर्ष कारण : तीव्र संकलन गति गो संकलक और गो भाषा में भी एक सचेत विकल्प था

• Go कंपाइलर में C / C ++ कंपाइलर की तुलना में अधिक सरल अनुकूलक है

• C ++ के विपरीत, Go में कोई टेम्पलेट और कोई इनलाइन फ़ंक्शन नहीं हैं। इसका मतलब है कि गो को किसी भी टेम्प्लेट या फंक्शन इंस्टेंटेशन को करने की आवश्यकता नहीं है।

• गो संकलक निम्न-स्तरीय असेंबली कोड को जल्द ही उत्पन्न करता है और ऑप्टिमाइज़र असेंबली कोड पर काम करता है, जबकि एक विशिष्ट C / C ++ कंपाइलर में ऑप्टिमाइज़ेशन पास मूल स्रोत कोड के आंतरिक प्रतिनिधित्व पर काम करता है। C / C ++ कंपाइलर में अतिरिक्त ओवरहेड इस तथ्य से आता है कि आंतरिक प्रतिनिधित्व को उत्पन्न करने की आवश्यकता है।

• किसी Go प्रोग्राम के अंतिम लिंकिंग (5l / 6l / 8l) को C / C ++ प्रोग्राम को लिंक करने की तुलना में धीमा किया जा सकता है, क्योंकि Go कंपाइलर सभी उपयोग किए गए असेंबली कोड से गुजर रहा है और शायद यह अन्य अतिरिक्त क्रियाएं भी कर रहा है जो C / C ++ है। लिंक नहीं कर रहे हैं

• कुछ C / C ++ कंपाइलर (GCC) टेक्स्ट फॉर्म (असेंबलर को पास करने के लिए) में निर्देश उत्पन्न करते हैं, जबकि Go कंपाइलर बाइनरी फॉर्म में निर्देश उत्पन्न करता है। पाठ को बाइनरी में बदलने के लिए अतिरिक्त कार्य (लेकिन बहुत अधिक नहीं) किए जाने की आवश्यकता है।

• गो संकलक केवल कम संख्या में सीपीयू आर्किटेक्चर को लक्षित करता है, जबकि जीसीसी संकलक बड़ी संख्या में सीपीयू को लक्षित करता है

• कंपाइलर जो उच्च संकलन गति के लक्ष्य के साथ डिज़ाइन किए गए थे, जैसे कि बाइक, तेज हैं। 2GHz CPU पर, Jikes प्रति सेकंड जावा कोड की 20000+ लाइनों को संकलित कर सकता है (और संकलन का वृद्धिशील मोड और भी अधिक कुशल है)।

Comments

गो संकलक छोटे कार्यों को रेखांकित करता है। मुझे यकीन नहीं है कि CPU की एक छोटी संख्या को लक्षित करने से आप कैसे तेजी से धीमे हो जाते हैं ... मुझे लगता है कि मैं gcp86 का संकलन करते समय PPC कोड नहीं बना रहा हूं।

— ब्रैड फिट्ज़पैट्रिक

@BradFitzpatrick एक पुरानी टिप्पणी को पुनर्जीवित करने से घृणा करता है, लेकिन कम संख्या में प्लेटफार्मों को लक्षित करके संकलक के डेवलपर्स हर एक के लिए इसे अनुकूलित करने में अधिक समय व्यतीत कर सकते हैं।

— परसिस्टेंस

एक मध्यवर्ती रूप का उपयोग करने से आपको बहुत अधिक आर्किटेक्चर का समर्थन करने की अनुमति मिलती है क्योंकि अब आपको केवल प्रत्येक नए आर्किटेक्चर के लिए एक नया बैकेंड लिखना होगा

— phvv

Answer 4

संकलन दक्षता एक प्रमुख डिजाइन लक्ष्य था:

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

पार्सिंग से संबंधित विशिष्ट भाषा सुविधाओं के संबंध में भाषा FAQ बहुत दिलचस्प है:

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

Comments

यह सच नहीं है। आप प्रतीक तालिका के बिना स्रोत कोड को पूरी तरह से पार्स नहीं कर सकते।

मैं यह भी नहीं देखता कि कचरा संग्रह संकलन समय को क्यों बढ़ाता है। यह सिर्फ नहीं है।

— TheBlastOne

ये अक्सर पूछे जाने वाले प्रश्न हैं: golang.org/doc/go_faq.html मैं यह नहीं कह सकता कि क्या वे अपने लक्ष्यों (प्रतीक तालिका) को पूरा करने में विफल रहे हैं या यदि उनका तर्क दोषपूर्ण (GC) है।

— लैरी ओब्रायन

करने के लिए @FUZxxl जाओ golang.org/ref/spec#Primary_expressions और दो दृश्यों [ओपेरैंड, कॉल] और [रूपांतरण] पर विचार करें। उदाहरण गो स्रोत कोड: पहचानकर्ता 1 (पहचानकर्ता 2)। प्रतीक तालिका के बिना यह तय करना असंभव है कि यह उदाहरण कॉल या रूपांतरण है। | कोई भी भाषा कुछ हद तक प्रतीक तालिका के बिना पार्स हो सकती है। यह सच है कि गो स्रोत कोड के अधिकांश हिस्सों को प्रतीक तालिका के बिना पार्स किया जा सकता है, लेकिन यह सच नहीं है कि गोलंग कल्पना में परिभाषित सभी व्याकरण तत्वों को पहचानना संभव है।

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

— सैम हरवेल

Answer 5

जबकि ऊपर का अधिकांश सत्य है, एक बहुत महत्वपूर्ण बिंदु है जो वास्तव में उल्लेखित नहीं था: निर्भरता प्रबंधन।

केवल उन पैकेजों को शामिल करने की आवश्यकता है जिन्हें आप आयात कर रहे हैं सीधे हैं (जैसा कि पहले से ही आयात किए गए हैं जो उन्हें चाहिए)। यह सी / सी ++ के विपरीत है, जहां हर एक फाइल में एक्स हेडर शामिल है, जिसमें वाई हेडर आदि शामिल हैं। नीचे की पंक्ति: गो के संकलन में आयातित पैकेजों की संख्या के लिए रैखिक समय की संख्या होती है, जहां C / C ++ घातीय समय लेती है।

Answer 6

एक संकलक की अनुवाद क्षमता के लिए एक अच्छा परीक्षण आत्म-संकलन है: किसी दिए गए संकलक को खुद को संकलित करने में कितना समय लगता है? C ++ के लिए यह बहुत लंबा समय (घंटे?) लेता है। तुलना करके, पास्कल / मोडुला -2 / ओबेरॉन संकलक एक से कम में खुद को संकलित करेगा एक आधुनिक मशीन [1] में सेकंड ।

गो इन भाषाओं से प्रेरित है, लेकिन इस दक्षता के कुछ मुख्य कारणों में शामिल हैं:

1. कुशल स्कैनिंग और पार्सिंग के लिए एक स्पष्ट रूप से परिभाषित वाक्यविन्यास है जो गणितीय रूप से ध्वनि है।

2. एक प्रकार-सुरक्षित और सांख्यिकीय रूप से संकलित भाषा जो मॉड्यूल सीमाओं के पार निर्भरता और प्रकार की जाँच के साथ अलग संकलन का उपयोग करती है, हेडर फ़ाइलों के अनावश्यक री-रीडिंग और अन्य मॉड्यूल के पुन: संकलन से बचने के लिए - जैसा कि सी / ++ + जैसे स्वतंत्र संकलन के विपरीत है। इस तरह के कोई भी क्रॉस-मॉड्यूल चेक कंपाइलर द्वारा नहीं किए जाते हैं (इसलिए उन सभी हेडर फ़ाइलों को बार-बार पढ़ने की आवश्यकता है, यहां तक ​​कि एक सरल एक-लाइन "हैलो वर्ल्ड" प्रोग्राम के लिए भी)।

3. एक कुशल संकलक कार्यान्वयन (उदाहरण के लिए एकल-पास, पुनरावर्ती-वंशीय टॉप-डाउन पार्सिंग) - जो निश्चित रूप से ऊपर 1 और 2 द्वारा मदद करता है।

ये सिद्धांत पहले से ही 1970 और 1980 के दशक में मेसा, एडा, मोडुला -2 / ओबेरॉन और कई अन्य भाषाओं में पहले से ही ज्ञात और पूरी तरह से लागू किए गए हैं, और केवल अब (2010 के दशक में) गो (Google) जैसी आधुनिक भाषाओं में अपना रास्ता खोज रहे हैं , स्विफ्ट (Apple), C # (Microsoft) और कई अन्य।

चलो आशा करते हैं कि यह जल्द ही आदर्श होगा और अपवाद नहीं। वहां जाने के लिए दो चीजों का होना जरूरी है:

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

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

किसी भी मामले में, यह वह प्लेटफ़ॉर्म है जो भाषा को अपनाने वाला है, न कि दूसरे तरीके से।

संदर्भ:

[१] http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf , पेज ६: "कंपाइलर लगभग ३ सेकंड में खुद को संकलित करता है"। यह भाव एक कम लागत वाले Xilinx संयमी -3 FPGA विकास बोर्ड के लिए 25 मेगाहर्ट्ज की घड़ी की आवृत्ति पर चल रहा है और मुख्य मेमोरी के 1 एमबीटी की विशेषता है। इससे एक कंपाइलर आसानी से 1 गीगाहर्ट्ज से ऊपर की घड़ी की आवृत्ति पर चलने वाले आधुनिक प्रोसेसर और मुख्य मेमोरी के कई GBytes (यानी Xilinx संयमी -3 GPGA बोर्ड की तुलना में अधिक शक्तिशाली के कई आदेश) के लिए "1 सेकंड से भी कम" को एक्सट्रपलेट किया , यहां तक ​​कि जब I / O गति को ध्यान में रखा जाता है। पहले से ही 1990 में जब ओबेरॉन 25MHz NS32X32 प्रोसेसर पर 2-4 एमबीटीएस मुख्य मेमोरी के साथ चलाया गया, तो कंपाइलर ने कुछ ही सेकंड में खुद को संकलित कर लिया। वास्तव में प्रतीक्षा की धारणा कंपलीशन चक्र को पूरा कर सकता है फिर भी ओबेरॉन प्रोग्रामर के लिए पूरी तरह से अज्ञात था। विशिष्ट कार्यक्रमों के लिए, यह हमेशामाउस बटन से उंगली को हटाने में अधिक समय लगा, जिससे कंपाइलर की तुलना में कंपाइलर के इंतजार की तुलना में कंपाइल कमांड पूरी हो गई। यह वास्तव में तत्काल संतुष्टि था, लगभग शून्य प्रतीक्षा समय के साथ। और उत्पादित कोड की गुणवत्ता, भले ही हमेशा पूरी तरह से सबसे अच्छा संकलक के साथ सममूल्य पर उपलब्ध नहीं है, फिर भी अधिकांश कार्यों के लिए उल्लेखनीय रूप से अच्छा था और सामान्य रूप से काफी स्वीकार्य था।

Comments

एक पास्कल / मोडुला -2 / ओबेरोन / ओबेरोन -2 संकलक एक आधुनिक मशीन [एक उद्धरण आवश्यक] पर कम से कम एक सेकंड में खुद को संकलित करेगा

— कॉफ़ेन्डकोड

उद्धरण जोड़ा गया, संदर्भ देखें [1]।

— एंड्रियास

"... सिद्धांत ... गो (Google), स्विफ्ट (Apple) जैसी आधुनिक भाषाओं में अपना रास्ता खोज रहे हैं" यकीन नहीं है कि स्विफ्ट उस सूची में कैसे बनी: स्विफ्ट कंपाइलर ग्लेशियल है । हाल ही में कोकोआइड्स बर्लिन मीटअप में, किसी ने मध्यम आकार के ढांचे के लिए कुछ नंबर प्रदान किए, वे प्रति सेकंड 16 एलओसी पर आए।

— एमपीडब्ल्यू

Answer 7

गो को तेजी से डिजाइन किया गया था, और यह दिखाता है।

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

ध्यान दें कि ऐसी विशेषताओं के साथ GO केवल एकमात्र भाषा नहीं है (आधुनिक भाषाओं में मॉड्यूल आदर्श हैं), लेकिन उन्होंने इसे अच्छी तरह से किया।

Comments

बिंदु (4) पूरी तरह से सच नहीं है। क्रॉस-मॉड्यूल इनलाइनिंग और सामान की अनुमति देने के लिए निर्भरता के क्रम में एक दूसरे पर निर्भर रहने वाले मॉड्यूल को संकलित किया जाना चाहिए।

— फ़ुज

@FUZxxl: यह केवल अनुकूलन चरण की चिंता करता है, आप बैकएंड आईआर पीढ़ी तक पूर्ण समानता रख सकते हैं; केवल क्रॉस-मॉड्यूल अनुकूलन इस प्रकार चिंतित है, जो लिंक चरण में किया जा सकता है, और लिंक वैसे भी समानांतर नहीं है। बेशक, अगर आप अपने काम की नकल नहीं करना चाहते हैं (रि-पार्सिंग), तो आप "जाली" तरीके से संकलन करना बेहतर समझते हैं: 1 / मॉड्यूल बिना किसी निर्भरता के, 2 / मॉड्यूल केवल (1), 3 / मॉड्यूल के आधार पर केवल (1) और (2) पर निर्भर करता है, ...

— Matthieu M.

जो कि Makefile जैसी मूलभूत उपयोगिताओं का उपयोग करना पूरी तरह से आसान है।

— fuz

Answer 8

एलन डोनोवन और ब्रायन कर्निघन की पुस्तक " द गो प्रोग्रामिंग लैंग्वेज " से उद्धृत :

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

Answer 9

संकलन का मूल विचार वास्तव में बहुत सरल है। एक पुनरावर्ती-वंशीय पार्सर, सिद्धांत रूप में, I / O बाध्य गति से चल सकता है। कोड पीढ़ी मूल रूप से एक बहुत ही सरल प्रक्रिया है। एक प्रतीक तालिका और बुनियादी प्रकार की प्रणाली ऐसी चीज नहीं है जिसके लिए बहुत अधिक गणना की आवश्यकता होती है।

हालांकि, एक संकलक को धीमा करना मुश्किल नहीं है।

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

उत्पन्न कोड के अनुकूलन के संदर्भ में, उस चरण में कितना प्रसंस्करण जोड़ा जा सकता है, इसकी कोई सीमा नहीं है।

Answer 10

बस (मेरे अपने शब्दों में), क्योंकि वाक्य रचना बहुत आसान है (विश्लेषण और पार्स करने के लिए)

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

उदाहरण के लिए इस कोड में उदाहरण: संकलक "इंटरफेस" नहीं जाता है और जांचता है कि क्या इच्छित प्रकारउस प्रकार का विश्लेषण करते समय दिए गए इंटरफ़ेस को लागू करता है। केवल जब तक इसका उपयोग नहीं किया जाता है (और यदि इसका उपयोग किया जाता है) तो चेक किया जाता है।

अन्य उदाहरण, संकलक आपको बताता है कि क्या आप एक चर घोषित कर रहे हैं और इसका उपयोग नहीं कर रहे हैं (या यदि आप रिटर्न मान रखने वाले हैं और आप हैं)

निम्नलिखित संकलन नहीं है:

package main
func main() {
    var a int 
    a = 0
}
notused.go:3: a declared and not used

इस प्रकार के प्रवर्तन और सिद्धांत परिणामी कोड को सुरक्षित बनाते हैं, और संकलक को अतिरिक्त सत्यापन नहीं करना पड़ता है जो प्रोग्रामर कर सकता है।

बड़े पैमाने पर इन सभी विवरणों से भाषा को पार्स करने में आसानी होती है जिसके परिणामस्वरूप तेजी से संकलन होते हैं।

फिर से, मेरे अपने शब्दों में।

Answer 11

मुझे लगता है कि गो को संकलक निर्माण के साथ समानांतर में डिज़ाइन किया गया था, इसलिए वे जन्म से सबसे अच्छे दोस्त थे। (IMO)

Answer 12

• आयात निर्भरता जाओसभी फ़ाइलों के लिए एक बार , इसलिए आयात समय परियोजना के आकार के साथ तेज़ी से नहीं बढ़ता है।
• सरल भाषाविज्ञान का अर्थ है कि उनकी व्याख्या करना कम कंप्यूटिंग लेता है।

और क्या?