क्लाउड-आधारित कंपाइलर लिखने के लिए यह कोई व्यावहारिक लाभ होगा, जो क्लाउड में विभिन्न मशीनों पर कोड की संकलित इकाइयों को फैलाएगा? संकलन के ठीक बाद ऐप के भीतर एक सॉफ़्टवेयर-ए-ए-सर्विस आर्किटेक्चर प्राप्त करने से लाभ हो सकता है, या अंतर्निहित विलंबता इस तरह के दृष्टिकोण को अव्यवहारिक बनाती है?क्या क्लाउड-आधारित कंपाइलर व्यवहार्य होगा?
मुझे यकीन नहीं है कि मैंने आपके बिंदु को गलत समझा है या यदि अन्य उत्तरों हैं। क्या आप किसी प्रकार के स्वचालित समांतरता कार्य के बारे में बात कर रहे हैं?अब तक दिए गए उत्तरों वितरित संकलन के बारे में बात कर रहे हैं - यानी संकलन के समय को तेज करने के लिए क्लाउड का उपयोग करना। मुझे लगता है कि आप क्लाइंट कंप्यूटिंग संसाधनों को लक्षित करने वाले एक कंपाइलर के बारे में बात कर रहे थे।
यदि आप वास्तव में वितरित संकलन के बारे में बात कर रहे थे, तो जाहिर है कि distcc जैसी चीजें आपको जो चाहिए वह करेंगे।
आप, के बारे में है कि क्या एक संकलक कि वितरित आर्किटेक्चर को लक्षित करता है उपयोगी होगा और अधिक दिलचस्प (IMHO) सवाल पूछ रहे थे मेरा उत्तर है एक शानदार 'हां' है। हालांकि, समस्या के दिल में व्यवहार्यता है। लेटेंसी इस तरह की समस्या नहीं है, हालांकि सुसंगतता (यानी यह सुनिश्चित करना कि सभी इकाइयों के सही संस्करण मौजूद हैं) और सभ्य हेरिस्टिक एक मुद्दा होगा।
देखने के लिए सबसे अच्छी जगह शायद ओकम प्रोग्रामिंग भाषा होगी - यह ट्रांसप्यूटर को लक्षित करती है, जो इन दिनों में रुचि रखने वाले वितरित सिस्टम आर्किटेक्चर के प्रकार से पूरी तरह से भिन्न नहीं थी। मेरा मानना है कि ओकम से कुछ ऐसा काम है जो कला की स्थिति के बारे में उपयोगी संकेत प्रदान कर सकता है।
यह निर्भर करता है। हमारे पास पुराने सी ++ आधारित संकलन होते थे जो 3-4 घंटे लगते थे। इस तरह के कुछ के लिए, संकलन को ऑफ़लोड करना बहुत उपयोगी होगा। लेकिन सी ++ परियोजनाओं में, यह अक्सर भी कम संभव होता है।
सी # या जावा के साथ, संकलन समय काफी तेज हैं, इसलिए यह उतना महत्वपूर्ण नहीं हो सकता है।
मेरा मानना है कि यह अव्यवहारिक होगा। आज का हार्डवेयर उचित समय में छोटे और मध्यम आकार की परियोजनाओं का संकलन कर सकता है; बहु-कोर CPUs के साथ और अधिक।
एकमात्र अपवाद स्रोतों से एक संपूर्ण ऑपरेटिंग सिस्टम (जैसे डेबियन) का निर्माण कर रहा है; इस तरह के आवेदन के लिए, खेतों का निर्माण व्यापक रूप से किया जाता है। हालांकि, खेतों के निर्माण की जरूरत वाले उपयोगकर्ताओं को आम तौर पर उन्हें स्वयं बना सकते हैं, और क्लाउड पर जाने की आवश्यकता नहीं है।
मैंने इस तरह की एक प्रणाली का उपयोग किया है, लेकिन यह एक स्थानीय क्लस्टर पर काम करता है, बादल नहीं। लेकिन सिद्धांत बिल्कुल वही होगा। दुर्भाग्यवश मुझे याद नहीं आया कि इसे क्या कहा जाता था - लेकिन यह अच्छा था, आपकी स्रोत फ़ाइलों को आपके विभाग में अन्य पीसी के लिए खेती की जा रही है।
संपादित करें: इसे IncrediBuild कहा गया था।
मैंने IncrediBuild का उपयोग किया है और यह लैन पर काफी अच्छा काम करता है। सैद्धांतिक रूप से ऐसी बात बादल में किया जा सकता है, बस CPU संसाधनों के आसपास झूठ बोल रही है यह काम महंगा हो सकता है बनाने के लिए हो रही है। Incredibuild लैन पर अन्य मशीनों से अतिरिक्त सीपीयू का उपयोग करता है जो बहुत समझ में आता है और मुफ़्त है। – jkupferman
एक्सकोड में एक वितरित निर्माण सुविधा है जो आपको ऐसा करने देती है, लेकिन मुझे लगता है कि एक लैन के अलावा किसी अन्य चीज़ पर यह ज्यादातर समय धीमा होगा।
मुझे लगता है कि यह उपयोगी हो सकता है अगर यह किसी प्रकार का निरंतर एकीकरण उपकरण था। कुछ विकास वातावरण के लिए, उचित सेटअप प्राप्त करना मुश्किल है। उदाहरण के लिए, मैंने एक बार एक परियोजना पर काम किया जहां टीम ने FlashDevelop और Adobe's Flex SDK का उपयोग करके एसडब्ल्यूएफ फाइलों को संकलित किया। कभी-कभी किसी व्यक्ति के कंप्यूटर पर स्थापित होने का दर्द होता था। यदि कोई सेवा किसी प्रोजेक्ट निर्देशिका या गिट/एसवीएन/आदि की निगरानी कर सकती है। भंडार और नवीनतम एसडब्ल्यूएफ का निर्माण, हालांकि, मुझे लगता है कि यह उपयोगी होता।
मुझे लगता है कि इसका क्रॉस-प्लेटफार्म परियोजनाओं के लिए भी उपयोग होगा। या, यह सेवा Mozilla's Bespin जैसे ब्राउज़र में आईडीई का समर्थन कर सकती है।
आप सबसे विशिष्ट यूनिक्स कोड के वितरित संकलन के लिए distcc और make -j का उपयोग कर सकते हैं। यदि आप नियमित रूप से कोड के बड़े हिस्से को संकलित करते हैं, तो यह आपको बड़ी गति मिल सकता है ... afaik samba (मुफ्त smb कार्यान्वयन) डेवलपर्स इसका उपयोग करते हैं। distcc केवल एक वितरित चरण में संकलन चरण करता है, जो प्रीप्रोकैसिंग को छोड़कर और मास्टर मशीन से लिंक करता है।
"क्लाउड" के साथ बातचीत विलंबता को प्रेरित कर सकती है, लेकिन मुझे अभी भी अधिक जटिल सी ++ कोड के साथ लगता है कि यह बहुत उपयोगी हो सकता है। मुझे लगता है कि यदि आपके पास 100 से अधिक संकलन इकाइयां हैं (f.e. .cpp फ़ाइलें), तो आप ध्यान देने योग्य गति प्राप्त कर सकते हैं।
मैंने ग्रिडगेन के शीर्ष पर जुनीट परीक्षण चलाने का अच्छा डेमो देखा है, और क्लाइड में ग्रिडगेन चलाया जा सकता है।
मुझे क्लाउड में होने वाले कंपाइलर में बहुत अधिक मूल्य दिखाई नहीं देता है।
हां, पूछने के लिए धन्यवाद, मैं इस क्षेत्र में भी शोध कर रहा हूं। असल में यह बहुत समझ में आता है और यह मौजूद है, http://www.cloudcompiling.com/, लेकिन जो भी मैं देख सकता हूं, यह अभी भी शीर्ष 10 सेवा होने के लिए अभी तक है।
विलंबता केवल कोड के अपलोड में है, इसलिए यदि डेवलपर एक अच्छे कनेक्शन के साथ काम कर रहे हैं और बहुत दूर नहीं हैं (नेटवर्क होप्स के मामले में और "अच्छा" होप्स), यह कोई मुद्दा नहीं होगा। बादल पर
विलंबता बादल प्रदाता का एक मुद्दा है, अगर यह आप क्लाउड प्रदाता है, ठीक है, तो आप एक अच्छी संतुलन रणनीति की जरूरत है।
हाँ ... कि मैं, क्या पूछ रहा था, तो एक संकलक कि वितरित आर्किटेक्चर को लक्षित करता है संभव होगा ... एक ही स्थान पर कोड लिखने और यह बादल में चलाने के लिए है, दुर्बलता से लिंक्ड, पुन: प्रयोज्य सेवाओं की एक श्रृंखला के रूप में है। मुझे कल्पना है कि यह उपयोगी होगा, मैं पूछताछ कर रहा हूं कि क्या विलंबता जंगली में अक्षम हो जाएगी। – luvieere
"क्लाउड-आधारित संकलक" के रूप में शीर्षक में कहा गया है एक संकलक कि बादल, नहीं एक संकलक कि क्लाउड-आधारित कार्यक्रमों को बनाने वाला चलाता है निकलता है। मुझे लगता है कि मैंने गलत समझा। –