क्या गैर-अवरुद्ध I / O वास्तव में मल्टी-थ्रेडेड अवरुद्ध I / O से अधिक तेज़ है? कैसे?

Question

मैंने I / O को अवरुद्ध करने और I / O को अवरुद्ध करने के बारे में कुछ तकनीकी विवरणों पर वेब खोजा और मैंने पाया कि कई लोग बताते हैं कि I / O को अवरुद्ध करने की तुलना में गैर-अवरुद्ध I / O अधिक तेज़ होंगे। उदाहरण के लिए इस दस्तावेज़ में ।

अगर मैं अवरुद्ध I / O का उपयोग करता हूं, तो निश्चित रूप से वर्तमान में अवरुद्ध किया गया धागा कुछ और नहीं कर सकता है ... क्योंकि यह अवरुद्ध है। लेकिन जैसे ही एक धागा अवरुद्ध होना शुरू होता है, ओएस दूसरे धागे पर स्विच कर सकता है और वापस स्विच नहीं कर सकता है जब तक कि अवरुद्ध धागे के लिए कुछ करना न हो। इसलिए जब तक कि सिस्टम पर एक और धागा है जो सीपीयू की आवश्यकता है और अवरुद्ध नहीं है, एक घटना आधारित गैर-अवरुद्ध दृष्टिकोण की तुलना में कोई और सीपीयू निष्क्रिय समय नहीं होना चाहिए, क्या वहाँ है?

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

1. किसी फ़ाइल की सामग्री को लोड करने के लिए, एक एप्लिकेशन इस कार्य को एक इवेंट-आधारित i / o फ्रेमवर्क में दर्शाता है, एक फाइलबैक के साथ एक कॉलबैक फ़ंक्शन को पारित करता है।
2. इवेंट फ्रेमवर्क ऑपरेटिंग सिस्टम को दर्शाता है, जो फ़ाइल को मेमोरी में सीधे लिखने के लिए हार्ड डिस्क का डीएमए कंट्रोलर प्रोग्राम करता है
3. इवेंट फ्रेमवर्क आगे कोड को चलाने की अनुमति देता है।
4. डिस्क-टू-मेमोरी प्रतिलिपि के पूरा होने पर, डीएमए नियंत्रक एक बाधा का कारण बनता है।
5. ऑपरेटिंग सिस्टम का इंटरप्ट हैंडलर फ़ाइल में पूरी तरह से मेमोरी में लोड होने के बारे में इवेंट-आधारित i / o फ्रेमवर्क को सूचित करता है। इससे ऐसा कैसे होता है? सिग्नल का उपयोग करना ??
6. कोड जो वर्तमान में इवेंट i / o फ्रेमवर्क खत्म होने के बाद चलाया जाता है।
7. इवेंट-आधारित i / o फ्रेमवर्क अपनी कतार की जाँच करता है और चरण 5 से ऑपरेटिंग सिस्टम के संदेश को देखता है और चरण 1 में प्राप्त कॉलबैक को निष्पादित करता है।

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

Comments

संक्षिप्त उत्तर: यह प्रति कनेक्शन एक धागा होने के उपरि के बारे में अधिक है। गैर-अवरोधक io एक कनेक्शन प्रति धागा होने से बचने देता है।

— डैन डी।

IO को ब्लॉक करना एक ऐसी प्रणाली पर महंगा है जहां आप कनेक्शन के रूप में कई थ्रेड नहीं बना सकते हैं। JVM पर आप कुछ हज़ार सूत्र बना सकते हैं, लेकिन क्या होगा यदि आपके पास 100.000 से अधिक कनेक्शन हैं? तो आपको एक अतुल्यकालिक समाधान से चिपकना होगा। हालाँकि, ऐसी भाषाएँ हैं जहाँ धागे महंगे नहीं होते हैं (जैसे हरे रंग के धागे) जैसे गो / एर्लांग / जंग जहाँ यह 100.000 धागे होने की समस्या नहीं है। जब थ्रेड्स की संख्या बड़ी हो सकती है, तो मेरा मानना ​​है कि अवरुद्ध आईओ पैदावार तेजी से प्रतिक्रिया समय देता है। लेकिन यह कुछ ऐसा है जो मुझे विशेषज्ञों से पूछना होगा कि क्या यह वास्तविकता में सच है।

— OlliP

@OliverPlow, मुझे भी ऐसा लगता है, क्योंकि IO को अवरुद्ध करने का मतलब आमतौर पर हम सिस्टम को "समानांतर प्रबंधन" को संभालने देते हैं , बजाय इसके कि यह स्वयं कार्य कतारों और इस तरह का उपयोग कर रहा है।

— पचेरियर

@ डीडी। और, यदि थ्रेड वाले ओवरहेड नॉन-ब्लॉकिंग आईओओ के ओवरहेड के बराबर है तो क्या होगा? (आमतौर पर हरे रंग के धागे के मामले में सच है)

— पेसियर

"स्टैक की प्रतिलिपि बनाना" नहीं होता है। विभिन्न थ्रेड्स में अलग-अलग पते पर उनके ढेर होते हैं। अन्य रजिस्टरों के साथ प्रत्येक थ्रेड का अपना स्टैक पॉइंटर होता है। एक संदर्भ स्विच सिर्फ वास्तुशिल्प स्थिति (सभी रजिस्टरों सहित) को बचाता है, लेकिन स्मृति नहीं। एक ही प्रक्रिया में थ्रेड्स के बीच, कर्नेल को पेज टेबल भी नहीं बदलना है।

— पीटर कॉर्डेस

Answer 1

नॉनब्लॉकिंग या एसिंक्रोनस I / O का सबसे बड़ा लाभ यह है कि आपका धागा समानांतर में अपना काम जारी रख सकता है। बेशक आप इसे एक अतिरिक्त धागे का उपयोग करके भी प्राप्त कर सकते हैं। जैसा कि आपने सर्वश्रेष्ठ समग्र (सिस्टम) प्रदर्शन के लिए कहा था कि मुझे लगता है कि अतुल्यकालिक I / O का उपयोग करना बेहतर होगा और कई थ्रेड्स (इसलिए थ्रेड स्विचिंग को कम करना)।

आइए एक नेटवर्क सर्वर प्रोग्राम के संभावित कार्यान्वयन को देखें जो समानांतर में जुड़े 1000 ग्राहकों को संभालेंगे:

1. प्रति कनेक्शन एक धागा (अवरुद्ध किया जा सकता है I / O, लेकिन गैर-अवरुद्ध I / O भी हो सकता है)।
   प्रत्येक थ्रेड को मेमोरी रिसोर्स की आवश्यकता होती है (कर्नेल मेमोरी भी!), यह एक नुकसान है। और प्रत्येक अतिरिक्त थ्रेड का मतलब शेड्यूलर के लिए अधिक काम है।
2. सभी कनेक्शनों के लिए एक धागा।
   यह सिस्टम से लोड लेता है क्योंकि हमारे पास थ्रेड कम हैं। लेकिन यह आपको अपनी मशीन के पूर्ण प्रदर्शन का उपयोग करने से भी रोकता है, क्योंकि आप एक प्रोसेसर को 100% तक चला सकते हैं और अन्य सभी प्रोसेसर को निष्क्रिय कर सकते हैं।
3. कुछ धागे जहां प्रत्येक धागा कुछ कनेक्शनों को संभालता है।
   यह सिस्टम से लोड लेता है क्योंकि थ्रेड कम हैं। और यह सभी उपलब्ध प्रोसेसर का उपयोग कर सकता है। विंडोज पर यह दृष्टिकोण थ्रेड पूल एपीआई द्वारा समर्थित है ।

बेशक अधिक धागे होना एक समस्या के अनुसार नहीं है। जैसा कि आपने पहचाना होगा कि मैंने काफी संख्या में कनेक्शन / थ्रेड चुने हैं। मुझे संदेह है कि आप तीन संभावित कार्यान्वयन के बीच कोई अंतर देखेंगे यदि हम केवल एक दर्जन थ्रेड्स के बारे में बात कर रहे हैं (यह भी रेमंड चेन एमएसडीएन ब्लॉग पोस्ट पर सुझाव देता है कि क्या विंडोज में प्रति प्रक्रिया 2000 थ्रेड्स की सीमा है? )।

विंडोज पर असंबद्ध फ़ाइल I / O का उपयोग करने का मतलब है कि लिखना एक आकार का होना चाहिए जो पृष्ठ आकार का एक से अधिक है। मैंने इसका परीक्षण नहीं किया है, लेकिन ऐसा लगता है कि यह बफ़र सिंक्रोनस और एसिंक्रोनस राइट्स के लिए लेखन प्रदर्शन को सकारात्मक रूप से प्रभावित कर सकता है।

आपके द्वारा वर्णित चरण 1 से 7 यह एक अच्छा विचार देता है कि यह कैसे काम करता है। विंडोज पर ऑपरेटिंग सिस्टम आपको एक घटना या एक कॉलबैक का उपयोग करके एक अतुल्यकालिक I / O ( संरचना के WriteFileसाथ OVERLAPPED) के पूरा होने के बारे में सूचित करेगा । कॉलबैक फ़ंक्शन को केवल उदाहरण के लिए बुलाया जाएगा जब आपका कोड सेट के WaitForMultipleObjectsExसाथ कॉल करता bAlertableहै true।

वेब पर कुछ और पढ़ना:

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

Comments

सामान्य ज्ञान के वेब बिंदु से (इंटरनेट, विशेषज्ञों से टिप्पणियां) सुझाव देते हैं कि अधिकतम वृद्धि। स्मृति वृद्धि और संदर्भ स्विचिंग समय के कारण अनुरोध थ्रेड्स की संख्या IO को अवरुद्ध करने (अनुरोधों के प्रसंस्करण को भी धीमा कर रही है) में एक बुरी बात है, लेकिन, क्या Async IO एक ही कार्य को दूसरे थ्रेड पर काम करते समय नहीं कर रहा है? हां, आप अभी और अनुरोध कर सकते हैं, लेकिन पृष्ठभूमि में समान संख्या में धागे हैं .. इसका वास्तविक लाभ क्या है?

— जेवियर जे

@JavierJ आपको लगता है कि यदि n थ्रेड async फ़ाइल IO करते हैं तो एक अवरुद्ध फ़ाइल IO करने के लिए अन्य n थ्रेड बनाए जाएंगे? यह सच नहीं है। OS में async फ़ाइल IO सपोर्ट है और IO के पूरा होने का इंतज़ार करते समय इसे ब्लॉक करने की आवश्यकता नहीं है। यह IO अनुरोधों को कतारबद्ध कर सकता है और यदि कोई हार्डवेयर (जैसे DMA) बाधित होता है, तो यह अनुरोध को चिह्नित कर सकता है और एक घटना को सेट कर सकता है जो कॉलर थ्रेड को इंगित करता है। यहां तक ​​कि अगर एक अतिरिक्त थ्रेड की आवश्यकता होती है, तो ओएस कई थ्रेड से कई IO अनुरोधों के लिए उस थ्रेड का उपयोग करने में सक्षम होगा।

— वर्नर हेन्ज

धन्यवाद, यह समझ में आता है कि OS async फ़ाइल IO समर्थन से युक्त है, लेकिन जब मैं इसे (वेब ​​के दृष्टिकोण से) वास्तविक कार्यान्वयन के लिए कोड लिखता हूं तो जावा सर्वलेट 3.0 के साथ कहते हैं NIO मैं अभी भी अनुरोध के लिए एक धागा और एक पृष्ठभूमि धागा देखता हूं ( async) फ़ाइल, डेटाबेस या जो कुछ भी पढ़ने के लिए लूपिंग।

— जेविआरजे

@ पीयूष गोयल ने मेरे जवाब को दोहराया। मुझे उम्मीद है कि अब यह स्पष्ट है।

— वर्नर हेन्ज

विंडोज पर एसिंक्रोनस फाइल I / O का उपयोग करने का मतलब है कि लिखना एक आकार का होना चाहिए जो पृष्ठ आकार का एक से अधिक है। - नहीं, यह नहीं है। आप अनबैलेंस्ड I / O के बारे में सोच रहे हैं। (वे अक्सर एक साथ उपयोग किए जाते हैं, लेकिन उनका होना आवश्यक नहीं है।)

— हैरी जॉनसन

Answer 2

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

आवेदन के स्तर पर, अतुल्यकालिक I / O थ्रेड को I / O संचालन के पूरा होने तक प्रतीक्षा करने से रोकता है। जैसे ही एक एसिंक्रोनस I / O ऑपरेशन शुरू होता है, यह उस थ्रेड को जारी करता है जिस पर इसे लॉन्च किया गया था और एक कॉलबैक पंजीकृत है। जब ऑपरेशन पूरा हो जाता है, तो कॉलबैक पहले उपलब्ध थ्रेड पर निष्पादन के लिए कतारबद्ध होता है।

यदि I / O ऑपरेशन को समान रूप से निष्पादित किया जाता है, तो यह ऑपरेशन पूरा होने तक अपने चल रहे धागे को कुछ नहीं करता है। रनटाइम को पता नहीं है कि I / O ऑपरेशन कब पूरा होता है, इसलिए यह समय-समय पर प्रतीक्षा के धागे को कुछ CPU समय प्रदान करेगा, CPU समय जो अन्यथा अन्य थ्रेड्स द्वारा उपयोग किया जा सकता है जिनके पास प्रदर्शन करने के लिए वास्तविक CPU बाध्य ऑपरेशन हैं।

तो, जैसा कि @ user1629468 ने उल्लेख किया है, अतुल्यकालिक I / O बेहतर प्रदर्शन प्रदान नहीं करता है, बल्कि बेहतर मापनीयता प्रदान करता है। यह स्पष्ट है जब ऐसे संदर्भों में चल रहे हैं जिनमें सीमित संख्या में धागे उपलब्ध हैं, जैसे कि वेब अनुप्रयोगों के साथ ऐसा ही है। वेब एप्लिकेशन आमतौर पर एक थ्रेड पूल का उपयोग करते हैं जिससे वे प्रत्येक अनुरोध पर थ्रेड असाइन करते हैं। यदि अनुरोधों को लंबे समय से चलने वाले I / O संचालन पर अवरुद्ध किया जाता है, तो वेब पूल को समाप्त करने और प्रतिक्रिया देने के लिए वेब एप्लिकेशन को फ्रीज या धीमा करने का जोखिम है।

एक बात जिस पर मैंने गौर किया है, वह यह है कि एसिंक्रोनस I / O बहुत तेज I / O संचालन के साथ काम करते समय सबसे अच्छा विकल्प नहीं है। उस स्थिति में जब मैं / O ऑपरेशन को पूरा करने के लिए प्रतीक्षा करने के दौरान किसी थ्रेड को व्यस्त न रखने का लाभ बहुत महत्वपूर्ण नहीं है और यह तथ्य कि ऑपरेशन एक धागे पर शुरू होता है और यह दूसरे पर पूरा होता है, समग्र निष्पादन के लिए एक ओवरहेड जोड़ता है।

आप एक अधिक विस्तृत शोध को पढ़ सकते हैं जो मैंने हाल ही में अतुल्यकालिक I / O बनाम के विषय में किया है ।

Comments

मुझे आश्चर्य है कि अगर यह I / O संचालन के बीच अंतर करने के लायक है जो पूरा होने की उम्मीद है, और ऐसी चीजें जो [जैसे "अगले चरित्र जो सीरियल पोर्ट पर आती हैं" नहीं मिल सकती हैं ", उन मामलों में जहां रिमोट डिवाइस हो सकता है या नहीं। कुछ भी भेज दो]। यदि I / O ऑपरेशन उचित समय के भीतर पूरा होने की उम्मीद है, तो ऑपरेशन पूरा होने तक संबंधित संसाधनों की सफाई में देरी हो सकती है। यदि ऑपरेशन कभी पूरा नहीं हो सकता है , हालांकि, इस तरह की देरी अनुचित होगी।

— सुपरकैट

@ आप जिस परिदृश्य का वर्णन कर रहे हैं, उसका उपयोग निचले स्तर के अनुप्रयोगों और पुस्तकालयों में किया जाता है। सर्वर इस पर भरोसा कर रहे हैं, क्योंकि वे लगातार आने वाले कनेक्शन की प्रतीक्षा करते हैं। ऊपर वर्णित I उस स्थिति में जब आप वर्णन कर रहे हैं कि आपको सिस्टम ईवेंट पर कॉलबैक रजिस्टर करने और प्रत्येक सूचना को संसाधित करने की आवश्यकता है। आप ऑपरेशन करने के बजाय लगातार प्रोसेसिंग कर रहे हैं। जैसा कि कहा गया है, यह आमतौर पर निम्न स्तर पर किया जाता है, लगभग कभी भी आपके ऐप में नहीं होता है।

— फ्लोरिन डुमिट्रेस्कु

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

— सुपरकैट

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

— लिफू हुआंग

Answer 3

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

Answer 4

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

पहले परिदृश्य को अक्सर "समानांतर" प्रोग्रामिंग के रूप में संदर्भित किया जाता है। दूसरे परिदृश्य को अक्सर "समवर्ती" या "अतुल्यकालिक" प्रोग्रामिंग के रूप में संदर्भित किया जाता है, हालांकि "समवर्ती" को कभी-कभी केवल ऑपरेटिंग सिस्टम को कई कार्यों के निष्पादन की अनुमति देने के मामले को संदर्भित करने के लिए भी उपयोग किया जाता है, भले ही इस तरह के निष्पादन को लेना चाहिए। क्रमिक निष्पादन प्राप्त करने के लिए धारावाहिक या यदि कई संसाधनों का उपयोग किया जा सकता है। इस बाद के मामले में, "समवर्ती" आम तौर पर उस तरीके को संदर्भित करता है जो कार्य निष्पादन के वास्तविक युगपतता के परिप्रेक्ष्य से नहीं बल्कि कार्यक्रम में लिखा गया है।

यह बहुत आसान है कि इस सब के बारे में मौन धारणाओं के साथ बोलना आसान है। उदाहरण के लिए, कुछ दावा करने के लिए जल्दी हैं जैसे "एसिंक्रोनस I / O मल्टी-थ्रेडेड I / O की तुलना में तेज़ होगा।" यह दावा कई कारणों से संदिग्ध है। सबसे पहले, यह मामला हो सकता है कि कुछ दिए गए अतुल्यकालिक I / O ढांचे को बहु-थ्रेडिंग के साथ सटीक रूप से लागू किया जाता है, जिस स्थिति में वे एक ही में होते हैं और यह एक अवधारणा को "दूसरे को" से तेज कहने का मतलब नहीं है ।

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

आपके द्वारा चलाए जा रहे असामान्य या बेवकूफ कोने के मामलों की बहुत कल्पना करना उपयोगी है।

"एसिंक्रोनस" को समवर्ती नहीं होना पड़ता है, उदाहरण के लिए ऊपर के रूप में: आप "एसिंक्रोनस रूप से" बिल्कुल एक प्रोसेसर कोर के साथ मशीन पर दो सीपीयू-बाउंड कार्यों को निष्पादित करते हैं।

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

इसलिए न तो एसिंक्रोनस I / O और न ही मल्टी-थ्रेडिंग को रन समय के संदर्भ में कोई प्रदर्शन लाभ प्रदान करना है। वे चीजों को धीमा भी कर सकते हैं।

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

प्रश्न पूछने के लिए: मुझे प्रदर्शन करने के लिए कितने कम्प्यूटेशनल चरणों की आवश्यकता है और उन्हें प्रदर्शन करने के लिए कितने स्वतंत्र सिस्टम हैं? क्या कम्प्यूटेशनल चरणों के सबसेट हैं जो स्वतंत्र सिस्टम सब-कम्यूटरों के उपयोग की आवश्यकता होती है और ऐसा समवर्ती करने से लाभ हो सकता है? मेरे पास कितने प्रोसेसर कोर हैं और अलग-अलग कोर पर कार्यों को पूरा करने के लिए कई प्रोसेसर या थ्रेड्स का उपयोग करने के लिए ओवरहेड क्या है?

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

जब भी कार्य एक ही संसाधन से बंधे होते हैं (जैसे एकाधिक को समान नेटवर्क या स्थानीय संसाधन तक पहुंचने की आवश्यकता होती है), तो बहु-थ्रेडिंग शायद असंतोषजनक ओवरहेड का परिचय देगा, और जबकि एकल-थ्रेडेड अतुल्यकालिक कम ओवरहेड का परिचय दे सकता है , ऐसे संसाधन में- सीमित स्थिति यह भी गति का उत्पादन नहीं कर सकती है। ऐसे मामले में, एकमात्र विकल्प (यदि आप स्पीड-अप चाहते हैं) उस संसाधन की कई प्रतियाँ उपलब्ध करना है (जैसे कई प्रोसेसर कोर अगर दुर्लभ संसाधन सीपीयू है, तो एक बेहतर डेटाबेस जो अधिक समवर्ती कनेक्शन का समर्थन करता है यदि दुर्लभ संसाधन; एक कनेक्शन-सीमित डेटाबेस, आदि) है।

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

Answer 5

गैर-अवरोधक I / O का एक संभावित कार्यान्वयन ठीक वही है जो आपने कहा था, पृष्ठभूमि थ्रेड्स के एक पूल के साथ जो I / O को अवरुद्ध करता है और कुछ कॉलबैक तंत्र के माध्यम से I / O के प्रवर्तक के धागे को सूचित करता है। वास्तव में, यह कैसे glibc में AIO मॉड्यूल काम करता है। कार्यान्वयन के बारे में कुछ अस्पष्ट विवरण यहां दिए गए हैं।

हालांकि यह एक अच्छा समाधान है जो काफी पोर्टेबल है (जब तक आपके पास धागे हैं), ओएस आमतौर पर गैर-अवरुद्ध I / O को अधिक कुशलता से सेवा देने में सक्षम है। यह विकिपीडिया लेख थ्रेड पूल के अलावा संभावित कार्यान्वयन को सूचीबद्ध करता है।

Answer 6

मैं वर्तमान में प्रोटोथ्रेड्स का उपयोग करके एक एम्बेडेड प्लेटफॉर्म पर एसिंक्रोन io लागू करने की प्रक्रिया में हूं। नॉन ब्लॉकिंग आईओ 16000fps और 160fps पर चलने के बीच अंतर करता है। गैर अवरुद्ध io का सबसे बड़ा लाभ यह है कि आप अपने कोड को अन्य चीजों को करने के लिए संरचना कर सकते हैं जबकि हार्डवेयर अपनी बात करता है। यहां तक ​​कि उपकरणों के प्रारंभिककरण को समानांतर में भी किया जा सकता है।

मार्टिन

Answer 7

नोड में, कई थ्रेड लॉन्च किए जा रहे हैं, लेकिन यह C ++ रन-टाइम में एक लेयर डाउन है।

"तो हाँ NodeJS सिंगल थ्रेडेड है, लेकिन यह एक आधा सच है, वास्तव में यह इवेंट-संचालित है और बैकग्राउंड वर्कर्स के साथ सिंगल-थ्रेडेड है। मेन इवेंट लूप सिंगल-थ्रेडेड है, लेकिन अधिकांश I / O वर्क अलग-अलग थ्रेड्स पर चलते हैं, क्योंकि Node.js में I / O API इवेंट लूप को समायोजित करने के लिए डिजाइन द्वारा अतुल्यकालिक / गैर-अवरोधक हैं। "

https://codeburst.io/how-node-js-single-thread-mechanism-work-understanding-event-loop-in-nodejs-230f7440b0ea

"Node.js गैर-अवरोधक है जिसका अर्थ है कि सभी फ़ंक्शन (कॉलबैक) इवेंट लूप में दिए गए हैं और वे अलग-अलग थ्रेड द्वारा निष्पादित (या हो सकते हैं) हैं। यह Node.js रन-टाइम द्वारा नियंत्रित किया जाता है।"

https://itnext.io/multi-threading-and-multi-process-in-node-js-ffa5bb5cde98 

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

Answer 8

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

Answer 9

मैं आपको एक प्रतिरूप देता हूं कि अतुल्यकालिक I / O काम नहीं करता है। मैं नीचे दिए गए बढ़ावा :: एसियो के समान एक प्रॉक्सी लिख रहा हूं। https://github.com/ArashPartow/proxy/blob/master/tcpproxy_server.cpp

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

इस प्रकार यह async I / O फ्रेमवर्क अब काम नहीं करता है। हमें प्रत्येक थ्रेड को एक सत्र निर्दिष्ट करके सर्वर को भेजने के लिए एक थ्रेड पूल की आवश्यकता है।