multithreading - Node.js के लिए हास्केल प्रतिक्रिया क्या है?




haskell concurrency (5)

मेरा मानना ​​है कि एरलांग समुदाय नोड.जेएस से ईर्ष्या नहीं है क्योंकि यह गैर-अवरुद्ध I / O मूल रूप से करता है और इसमें एक से अधिक प्रोसेसर (कुछ नोड.जेएस में भी अंतर्निहित नहीं) में आसानी से तैनाती को स्केल करने के तरीके हैं। http://journal.dedasys.com/2010/04/29/erlang-vs-node-js और Node.js या Erlang पर अधिक जानकारी

हास्केल के बारे में क्या? क्या Haskell Node.js के कुछ लाभ प्रदान कर सकता है, अर्थात् बहु-थ्रेड प्रोग्रामिंग के बिना I / O को अवरुद्ध करने से बचने के लिए एक स्वच्छ समाधान?

Node.js के साथ आकर्षक कई चीजें हैं

  1. घटनाक्रम: कोई धागा हेरफेर नहीं, प्रोग्रामर केवल कॉलबैक प्रदान करता है (जैसे स्नैप ढांचे में)
  2. कॉलबैक को एक थ्रेड में चलाने की गारंटी है: कोई रेस शर्त संभव नहीं है।
  3. अच्छा और सरल यूनिक्स-अनुकूल एपीआई। बोनस: उत्कृष्ट HTTP समर्थन। DNS भी उपलब्ध है।
  4. प्रत्येक I / O डिफ़ॉल्ट असीमित रूप से होता है। यह ताले से बचना आसान बनाता है। हालांकि, कॉलबैक में बहुत अधिक CPU प्रोसेसिंग अन्य कनेक्शन को प्रभावित करेगी (इस मामले में, कार्य को छोटे उप-कार्यों में विभाजित किया जाना चाहिए और फिर से निर्धारित किया जाना चाहिए)।
  5. क्लाइंट-साइड और सर्वर-साइड के लिए एक ही भाषा। (हालांकि, मुझे इस में बहुत अधिक मूल्य नहीं दिख रहा है। JQuery और Node.js इवेंट प्रोग्रामिंग मॉडल साझा करते हैं लेकिन शेष बहुत अलग है। मैं नहीं देख सकता कि सर्वर-साइड और क्लाइंट-साइड के बीच साझाकरण कोड कैसे हो सकता है अभ्यास में उपयोगी हो।)
  6. यह सब एक ही उत्पाद में पैक किया गया।

क्या Haskell Node.js के कुछ लाभ प्रदान कर सकता है, अर्थात् बहु-थ्रेड प्रोग्रामिंग के बिना I / O को अवरुद्ध करने से बचने के लिए एक स्वच्छ समाधान?

हां, वास्तव में घटनाओं और धागे हास्केल में एकीकृत हैं।

  • आप स्पष्ट हल्के धागे (जैसे एक लैपटॉप पर लाखों धागे) में प्रोग्राम कर सकते हैं।
  • या; स्केलेबल इवेंट अधिसूचना के आधार पर आप एसिंक घटना-संचालित शैली में प्रोग्राम कर सकते हैं।

थ्रेड वास्तव में घटनाओं के संदर्भ में लागू होते हैं, और कई कोरों में चलते हैं, जिसमें निर्बाध थ्रेड माइग्रेशन, दस्तावेज प्रदर्शन और अनुप्रयोगों के साथ।

के लिए

32 कोर पर समवर्ती संग्रह कोई नहीं

हास्केल में आपके पास दोनों घटनाएं और धागे हैं, और चूंकि यह हुड के नीचे सभी घटनाएं हैं।

कार्यान्वयन का वर्णन करने वाले पेपर को पढ़ें


आईएमएचओ कार्यक्रम अच्छे हैं, लेकिन कॉलबैक के माध्यम से प्रोग्रामिंग नहीं है।

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

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

Ocsigen (ocaml) समुंदर का किनारा (छोटा सा) WASH (बंद, हस्सेल) और mflow (हास्केल) जैसे अनुक्रमिक आधारित ढांचे हैं जो नेविगेशन और रीस्ट-फुलनेस बनाए रखते हुए राज्य प्रबंधन की समस्या को हल करते हैं। इन ढांचे के भीतर, प्रोग्रामर नेविगेशन को एक अनिवार्य अनुक्रम के रूप में व्यक्त कर सकते हैं जहां प्रोग्राम पेज भेजता है और एक थ्रेड में प्रतिक्रियाओं की प्रतीक्षा करता है, चर के दायरे में होते हैं और बैक बटन स्वचालित रूप से काम करता है। यह स्वाभाविक रूप से छोटे, अधिक सुरक्षित, अधिक पठनीय कोड उत्पन्न करता है जहां नेविगेशन प्रोग्रामर को स्पष्ट रूप से दिखाई देता है। (उचित चेतावनी: मैं mflow के डेवलपर हूँ)


ठीक है, इसलिए youtube.com/watch?v=F6k8lTrAE2g का एक छोटा सा देखा गया है कि @ गॉवी ने मुझे इंगित किया है, मैं थोड़ा और कह सकता हूं कि हास्केल कैसे नोड.जे.एस. की तुलना करता है। प्रेजेंटेशन में, रयान ग्रीन थ्रेड के कुछ फायदों का वर्णन करता है, लेकिन फिर यह कहता है कि उसे एक नुकसान होने के कारण थ्रेड अबास्ट्रक्शन की कमी नहीं मिलती है। मैं विशेष रूप से हास्केल के संदर्भ में अपनी स्थिति से असहमत हूं: मुझे लगता है कि थ्रेड प्रदान करने वाले अवशेष सर्वर कोड को सही होने के लिए और अधिक मजबूत बनाने के लिए आवश्यक हैं। विशेष रूप से:

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

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

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


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

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

एमओओ के साथ, हास्केल स्केल में यथार्थवादी HTTP सर्वर 20 सीपीयू कोर तक, जीएचसी के पिछले संस्करणों का उपयोग करते हुए उसी सर्वर की तुलना में 6.5x के कारक तक चरम प्रदर्शन प्राप्त करते हैं। हास्केल सर्वर की विलंबता में भी सुधार हुआ है: [...] एक मध्यम भार के तहत, जीएचसी के पिछले संस्करणों की तुलना में अपेक्षित प्रतिक्रिया समय 5.7x तक कम कर देता है

तथा:

हम यह भी दिखाते हैं कि Mio के साथ, मैकनेट (हास्केल में लिखे गए एक एसडीएन नियंत्रक) प्रभावी ढंग से 40+ कोर तक स्केल कर सकते हैं, एक मशीन पर प्रति सेकंड 20 मिलियन से अधिक नए अनुरोधों का एक पूर्णता तक पहुंच सकते हैं, और इसलिए सभी मौजूदा एसडीएन नियंत्रकों में से सबसे तेज़ हो जाते हैं ।

एमओओ ने इसे जीएचसी 7.8.1 रिलीज में बनाया है। मैं इसे व्यक्तिगत रूप से हास्केल प्रदर्शन में एक प्रमुख कदम के रूप में देखता हूं। पिछले जीएचसी संस्करण और 7.8.1 द्वारा संकलित मौजूदा वेब अनुप्रयोग प्रदर्शन की तुलना करना बहुत दिलचस्प होगा।


सवाल बहुत हास्यास्पद है क्योंकि 1) हास्केल ने इस मुद्दे को पहले से ही बेहतर तरीके से हल कर लिया है और 2) लगभग उसी तरह से एर्लांग के पास है। नोड के खिलाफ बेंचमार्क यहां दिया गया है: yesodweb.com/blog/2011/03/…

हास्केल 4 कोर दें और यह एक ही एप्लिकेशन में प्रति सेकेंड 100k (सरल) अनुरोध कर सकता है। नोड कई लोगों को नहीं कर सकता है, और कोर में एक ही आवेदन को स्केल नहीं कर सकता है। और आपको इसे काटने के लिए कुछ भी करने की ज़रूरत नहीं है क्योंकि हास्केल रनटाइम गैर-अवरुद्ध है। एकमात्र अन्य (अपेक्षाकृत आम) भाषा जिसमें रनटाइम में निर्मित गैर-अवरुद्ध आईओ है, वह एरलांग है।





node.js