Erlang और Haskell मिक्सिंग




functional-programming garbage-collection (4)

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

Erlang परिपक्व वितरण मॉडल के साथ एक व्यावसायिक रूप से साबित गलती सहनशील भाषा है। हॉट कोड लोडिंग के माध्यम से रनटाइम पर अपने संस्करण को अपग्रेड करने की इसकी क्षमता में इसकी एक अनूठी विशेषता है। (बहुत कूल!)

दूसरी ओर, हास्केल, किसी भी मुख्यधारा की भाषा का सबसे परिष्कृत प्रकार प्रणाली है। (जहां मैं 'मुख्यधारा' को किसी भी भाषा के रूप में परिभाषित करता हूं जिसमें प्रकाशित ओ'रेली पुस्तक है, इसलिए हास्केल की गणना होती है।) इसकी सीधी रेखा एकल प्रदर्शन एरलांग से बेहतर दिखता है और इसके हल्के धागे भी हल्के दिखते हैं।

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

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

कृपया किसी भी अनुभव (सकारात्मक या नकारात्मक), विचारों या सुझावों के साथ उत्तर दें। वास्तव में, कोई प्रतिक्रिया (सीधे दुरुपयोग से कम!) का स्वागत है।

अद्यतन करें

सभी 4 उत्तरों के लिए धन्यवाद - प्रत्येक ने मुझे कम से कम एक उपयोगी चीज़ सिखाई जो मुझे नहीं पता था।

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

प्लेटफ़ॉर्म में मैंने ऊपर प्रस्तावित किया है, मैं केवल हास्केल लिखूंगा, क्योंकि बॉयलरप्लेट एरलांग स्वचालित रूप से जेनरेट हो जाएगा। तो हास्केल कितने समय तक चलेगा? खैर लिस्प अभी भी हमारे साथ है और ऐसा नहीं लगता कि यह जल्द ही दूर जा रहा है। हास्केल बीएसडी 3 ओपन सोर्स है और उसने महत्वपूर्ण द्रव्यमान हासिल किया है। यदि प्रोग्रामिंग स्वयं 50 साल के आसपास भी है, तो मैं हास्केल, या हास्केल के कुछ निरंतर विकास की उम्मीद करता हूं, अभी भी यहां होगा।

Rvirding की पोस्ट के जवाब में 2 अपडेट करें

सहमत - एक पूर्ण "Erskell / Haslang" सार्वभौमिक वर्चुअल मशीन को लागू करना बिल्कुल असंभव नहीं हो सकता है, लेकिन यह वास्तव में वास्तव में बहुत मुश्किल होगा। वीएम की तरह कुछ कचरा कलेक्टर स्तर साझा करना, जबकि अभी भी मुश्किल है , हालांकि मेरे लिए परिमाण का एक आदेश कम मुश्किल लगता है। कचरा संग्रहण मॉडल में, कार्यात्मक भाषाओं में बहुत आम होना चाहिए - अपरिवर्तनीय डेटा (थंक्स समेत) की अनियमितता और बहुत तेज आवंटन की आवश्यकता। तो तथ्य यह है कि समानता को मोनोलिथिक वीएम के साथ कसकर बंडल किया जाता है, यह अजीब लगता है।

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

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

बिल्कुल, यह मेरे लिए सही समझ में आता है। जीएचसी विकास दल के बहुत ही स्मार्ट लोग समानांतर "दुनिया को रोकें" जीसी के साथ समस्या का हिस्सा हल करने की कोशिश कर रहे हैं।

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

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

जीएचसी रनटाइम को केवल एक कोर, या स्थानीय मशीन पर सभी कोर, या बीच के किसी भी संयोजन का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है।

इस तरह, किसी दिए गए उपयोग के मामले में, मैं बेंचमार्किंग के बाद, एर्लांग मार्ग पर जाने का चयन कर सकता हूं, और एक जीएचसी रनटाइम चला सकता हूं (एक सिंगलथ्रेड जीसी के साथ) और प्रति कोर एक एरलांग प्रक्रिया और एरलांग को अच्छी इलाके के लिए कोर के बीच स्मृति की प्रतिलिपि बनाने दें ।

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

दोनों मामलों में, अगर एरलांग और जीएचसी एक ढेर साझा कर सकते हैं, तो साझाकरण शायद एक ही कोर पर चलने वाले एकल ओएस थ्रेड से बंधेगा। (मैं यहां अपनी गहराई से बाहर निकल रहा हूं, यही कारण है कि मैंने सवाल पूछा।)

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

http://john.freml.in/garbage-collection-harmful

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


  1. आप ओएसटी gen_supervisor प्रक्रिया का उपयोग Haskell उदाहरणों की निगरानी के लिए कर सकते हैं जिन्हें आप open_port () के साथ उत्पन्न करते हैं। "पोर्ट" से बाहर निकलने के तरीके के आधार पर, आप फिर इसे पुनरारंभ करने में सक्षम होंगे या निर्णय लेंगे कि यह उद्देश्य पर बंद हो गया है और संबंधित एरलांग प्रक्रिया भी मरने देगी।

  2. Fugheddaboudit। यहां तक ​​कि इन भाषा-स्वतंत्र वीएम जिन्हें आप बोलते हैं, कभी-कभी भाषाओं के बीच पारित डेटा के साथ परेशानी होती है। आपको किसी भी तरह से डेटा को क्रमबद्ध करना चाहिए: डेटाबेस, एक्सएमएल-आरपीसी, ऐसा कुछ।

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


आप Haskell और Erlang के बीच जीसी मिश्रण एक दिलचस्प समय होने जा रहे हैं। एरलांग प्रति-प्रक्रिया ढेर का उपयोग करता है और प्रक्रियाओं के बीच डेटा कॉपी करता है - क्योंकि हास्केल में प्रक्रियाओं की अवधारणा भी नहीं है, मुझे यकीन नहीं है कि आप दोनों के बीच इस "सार्वभौमिक" जीसी को कैसे मैप करेंगे। इसके अलावा, सर्वोत्तम प्रदर्शन के लिए, एर्लांग विभिन्न आवंटकों का उपयोग करता है, जिनमें से प्रत्येक थोड़ा tweaked व्यवहार के साथ है कि मुझे यकीन है कि जीसी उप-प्रणाली को प्रभावित करेगा।

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

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


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

आने वाली distributed-process-platform लाइब्रेरी में ओटीपी-एस्क्यू संरचनाओं जैसे जेन_सेवर, पर्यवेक्षण पेड़ और कई अन्य "हैकेल स्वाद" अवशोषणों के लिए समर्थन शामिल है जो एरलांग / ओटीपी द्वारा उधार और प्रेरित हैं।


हास्केल और एरलांग लोगों के बहुत सारे मॉडल उस मॉडल में रूचि रखते हैं जहां एरलांग वितरण का पर्यवेक्षण करता है, जबकि हास्केल सभी संख्या क्रंचिंग / तर्क के समानांतर में साझा मेमोरी नोड चलाता है।

इसकी ओर एक शुरुआत हैकेल-एरलांग लाइब्रेरी है: http://hackage.haskell.org/package/erlang

और हमारे पास रुब्री भूमि में हबिस के माध्यम से समान प्रयास हैं: http://github.com/mwotton/Hubris/tree/master

सवाल यह है कि मुश्किल मुद्दों को जानने के लिए किसी को वास्तव में एरलांग / हास्केल इंटरऑप के माध्यम से धक्का देना है।





ghc