क्या लंबे संकलन अतीत की बात हैं?

38

कितने युद्ध कितने समय तक चल सकते हैं, इसके बारे में अनगिनत युद्ध कथाएँ हैं। यहां तक कि xkcd ने भी इसका उल्लेख किया।

अब, मैं लंबे समय से प्रोग्रामिंग नहीं कर रहा था और ज्यादातर सिर्फ जावा और पायथन के संपर्क में था (और पायथन एक व्याख्या की गई भाषा है, संकलित नहीं है)। मुझे लगता है कि यह संभव है कि मैं अभी उन परियोजनाओं में नहीं आया हूं जो संकलन के लिए बहुत लंबा समय लेते हैं, लेकिन यहां तक कि सभ्य आकार के ऐप्स के लिए, यह या तो मेरे लिए तात्कालिक है (आमतौर पर आईडीई द्वारा पृष्ठभूमि में संभाला जाता है) या 30 से अधिक नहीं ले रहा है सेकंड या तो एक बहुत बड़ी परियोजना के लिए। यहां तक कि एक कारोबारी माहौल (जहां कॉमिक जगह लेता है) में, मैंने कभी भी कोड को संकलन के लिए लंबा नहीं लिया है।

क्या मैं अभी लंबे संकलन समय वाली परियोजनाओं के संपर्क में नहीं आया हूँ? क्या यह अतीत का अवशेष है जो अब ऐसा नहीं है जो आधुनिक दिन में होता है? एक संकलन को इतना लंबा समय क्यों लगेगा?

compilation

— Thunderforge
स्रोत

31

क्रोमियम का संकलन करने का प्रयास करें।

— UldisK

2

लिनक्स कर्नेल की एक प्रति पकड़ो। एक पूर्ण निर्माण करें। अपने आप को देखो। या यदि आप एक जावा कोडर हैं तो स्रोत से स्प्रिंग। जैसा कि यह है, इस प्रश्न के कई उत्तर हैं जो इस प्रश्न का उत्तर दे रहे हैं जैसे कि यह एक सर्वेक्षण था ("मैंने 30 मिनट का संकलन किया है ..." उत्तर टाइप करें) जो एक संकेत है कि प्रश्न स्वयं एक अच्छा फिट नहीं है ।

हाल ही में एक बड़ी परियोजना को संकलित करने में मुझे 40 मिनट लगे (40 000 स्रोत कोड फाइलें मावेन के साथ संकलन)। कई सीपीयू कोर पर संकलन को व्यवस्थित करना है।

— निकलस Rosencrantz

2

एक स्रोत लिनक्स वितरण (gentoo, LFS, ...) उठाएं और फिर हर उस सॉफ़्टवेयर को संकलित करने में दिन बिताएं जिसे आप स्थापित कर रहे हैं।

— बेसिल स्टारीनेवविच

6

लंबे समय तक परिभाषित करें ... स्कूल के बाहर कुछ बच्चों के लिए 1 मिनट लंबा लग सकता है, एक बूढ़े व्यक्ति को, जो कुछ घंटों से खाइयों में है, भौंहें नहीं उठाते हैं।

— जॉइंटिंग

48

संकलन में कुछ समय लग सकता है, विशेष रूप से C, C ++ या Scala जैसी भाषाओं में लिखी गई बड़ी परियोजनाओं के लिए। पृष्ठभूमि में भागों को संकलित करने से संकलन समय कम हो सकता है, लेकिन कभी-कभी आपको एक नया संकलन करना होगा। वे कारक जिनमें लंबे संकलन समय शामिल हो सकते हैं:

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

संकलन केवल एक चीज नहीं है जो समय लेता है। प्रोजेक्ट संकलित होने के बाद, एक परीक्षण सूट चलाया जाना चाहिए। इस पर बिताया गया समय कुछ सेकंड से लेकर कुछ घंटों तक हो सकता है (यदि परीक्षण बुरी तरह लिखे गए हैं)।

— आमोन
स्रोत

14

दरअसल, स्काला का टाइप सिस्टम ट्यूरिंग-पूर्ण है, इसलिए टाइप-चेकिंग में अनंत समय लग सकता है, और कंपाइलर के लिए यह निर्धारित करना असंभव है।

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

7

अनुकूलन मत भूलना। बहुत सारे अनुकूलन जो कि (जैसे) C / C ++ कंपाइलर करेंगे बहुत महंगे हैं (जैसे इतना महंगा कि JIT उन्हें बिल्कुल भी बर्दाश्त नहीं कर सकता)। सबसे खराब स्थिति के लिए, अधिकांश टूल-चेन पूरे प्रोग्राम ऑप्टिमाइज़ेशन का समर्थन करते हैं, जो कि बिल्ड समय को बढ़ाने के लिए जाना जाता है।

— ब्रेंडन

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

— थंडरफोर्स

1

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

— corsiKa

1

महान जवाब, मैं सिर्फ यह ध्यान देना चाहूंगा कि संभव संकलन समय का प्रसार बहुत बड़ा हो सकता है। मैंने उन परियोजनाओं पर काम किया है जहाँ एक पूर्ण संकलन में दो से तीन दिन लग सकते हैं (हाँ जो भयावह था!) और मुझे लगता है कि वहाँ से भी बदतर अपराधी हैं।

— रॉय टी।

17

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

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

— चार्ल्स ई। ग्रांट
स्रोत

1

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

— पीटर टेलर

10

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

हालांकि, अन्य संकलन जैसी प्रक्रियाएं हैं जो लंबे समय तक ले सकती हैं। डिजिटल सर्किट डिजाइन (ASIC या FPGAs के लिए) को एक स्थान और मार्ग चरण की आवश्यकता होती है। वह स्थान और मार्ग चरण वह जगह है जहां इंटरकनेक्ट वायरिंग के लिए रूटिंग के साथ-साथ व्यक्तिगत लॉजिक गेट्स, फ्लिप-फ्लॉप, रजिस्टर, रैम और अन्य घटकों का स्थान निर्धारित किया जाता है। सॉफ्टवेयर संभावित स्थानों के लिए फाटक और मार्ग देरी को निर्धारित करने के लिए समय के मॉडल का उपयोग करता है, समय की कमी के आधार पर प्रदान की गई सीमाओं की तुलना करता है, और फिर समय की आवश्यकताओं को पूरा करने के लिए प्लेसमेंट स्थानों और तार रास्तों को समायोजित करता है। कभी-कभी सॉफ्टवेयर को फाटकों का आकार बदलना होगा और समय पूरा करने के लिए बफ़र्स जोड़ना होगा। यह कदम अत्यंत कम्प्यूटेशनल रूप से गहन है और इसे पूरा करने में कई घंटे या दिन भी लग सकते हैं। यह भी वास्तव में बहुत अच्छी तरह से समानांतर नहीं है। एक FPGA डिजाइन था जिसे मैं एक साल या उससे पहले काम कर रहा था, जिसने लगभग आधे से एक Virtex 6 HXT 565 FPGA (~ 565k LUTs में से 300k) का उपभोग किया और पूरी जगह और मार्ग को पूरा करने में लगभग 7 घंटे का समय लिया। मैं कल्पना नहीं कर सकता कि कोर i7 सीपीयू डिज़ाइन जैसी चीज़ पर जगह और मार्ग चलाने में कितना समय लगेगा - शायद कम से कम कई सप्ताह।

— alex.forencich
स्रोत

4

अन्य उत्तरों ने पहले ही उल्लेख किया है कि हां, बड़ी परियोजनाओं पर कोड, जहां बड़ी का मतलब 500k लाइनें और ऊपर है, महत्वपूर्ण समय ले सकता है, खासकर जब खरोंच से निर्माण होता है।

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

मुझे लगता है कि आप समय बर्बाद करने के लिए इस तरह के किसी भी बहाने के साथ नहीं मिलेगा। एक पेशेवर व्यक्ति अपने कार्य की योजना बना दिया जाना चाहिए ताकि वे करते हैं इस तरह के समय में करने के लिए कुछ उपयोगी है।

— andy256
स्रोत

3

थोड़ा दोनों। C ++ (और कुछ हद तक C) उनके धीमे संकलन समय के लिए कुख्यात थे, खासकर पीरियड हार्डवेयर पर। सहस्राब्दी के मोड़ के आसपास, मैंने एक परियोजना पर काम किया जिसमें मैक्रो शीनिगन्स के कारण निर्माण में लगभग 4 घंटे लगे।

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

— Telastyn
स्रोत

2

यह परियोजना और पर्यावरण पर निर्भर करता है जिसमें इसे संकलित किया जाता है। मैंने C ++ प्रोजेक्ट्स पर काम किया है जिसमें संकलन करने के लिए कई मिनट लगे (MSVS में कई प्रोजेक्ट्स के रूप में स्थापित), जो कि संभवत: एक तलवारबाजी के लिए पर्याप्त समय है।

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

— ट्रिक्सी वुल्फ
स्रोत