2013-02-20 15 views
11

विंडोज 8 में फैंसी नए टास्कमैनगर का उपयोग करके मैंने कुछ ऐसा देखा जो मेरे लिए एक आश्चर्य के रूप में आया था, वर्तमान में उपयोग/चलने वाले धागे जहां लगभग 1k।क्या हमें वास्तव में इन सभी 1000 धागे चलने की ज़रूरत है?

के बाद से Ive सिर्फ resonantly ट्यूटोरियल और बहु ​​सूत्रण सॉफ्टवेयर और खेल के पीछे सिद्धांत को छुआ। मुझे धारणा मिली कि यदि आप अपने सॉफ़्टवेयर से सर्वश्रेष्ठ प्रदर्शन प्राप्त करना चाहते हैं, तो काम करने के लिए आपके पास हमेशा लॉजिकल प्रोसेसर के कम से कम एक थ्रेड होना चाहिए। चूंकि वह प्रोसेसर अन्यथा "अप्रयुक्त" होगा।

लेकिन जैसा कि मैंने पहले से ही, 1000 धागे के आसपास चला रहा हूँ अभ्यस्त सभी प्रोसेसर पहले से ही कुछ पर काम किया जा रहा?

क्यों multithread अगर प्रसंस्करण शक्ति पहले से ही अन्य 50 या तो प्रक्रियाओं के द्वारा प्रयोग किया जा रहा है? इन सभी 1000 धागे का प्रबंधन करने के लिए पर्याप्त cpu लेना चाहते हैं? मुझे प्रोग्रामर के रूप में थ्रेड को संभालना क्यों चाहिए, न कि ऑपरेटिव सिस्टम? यदि यह प्रत्येक प्रक्रिया को एक थ्रेड देता है, तो क्या मेरा सॉफ़्टवेयर अभी भी "multhithreaded" नहीं होगा?

प्रक्रियाओं को प्राथमिकता देने के एक अधिक सजावटी तरह से अधिक धागे का उपयोग कर रहा है बस?

+2

क्या आप वाकई उन 1000 धागे वास्तव में चल रहे हैं (यानी सीपीयू चक्र का उपयोग कर रहे हैं) जैसा कि अभी मौजूद है? सोने के बहुत सारे धागे होने के लिए यह असामान्य नहीं है, और केवल तब उठना जब उनके लिए कुछ काम करना है। –

+1

सैकड़ों/हजारों धागे स्वचालित रूप से खराब = FUD। इस समय मेरे पास 67 प्रक्रियाएं और 1135 धागे हैं। सीपीयू उपयोग 1-2%। सब कुछ ठीक काम कर रहा है। –

उत्तर

23

मैं कहूंगा, शायद नहीं। यद्यपि यह प्रश्न थोड़ा विचित्र है, जेफरी रिचटर द्वारा Stop the madness (CLR via C# पुस्तक से) इस लेख/पुस्तक अंश पर एक नज़र डालें। यह उन चीजों पर चर्चा करता है जो आप पूछते हैं।

यदि सब के बारे में हम परवाह कच्चे प्रदर्शन था, तो धागे का इष्टतम संख्या में किसी भी मशीन पर के लिए उस मशीन पर CPU की संख्या के समान है। [...] सभी धागे में अभी भी एक कर्नेल ऑब्जेक्ट, कर्नेल-मोड स्टैक, और उनके लिए आवंटित अन्य संसाधन हैं। थ्रेड बनाने की यह प्रवृत्ति willy-nilly क्योंकि वे सस्ते हैं; धागे सस्ते नहीं हैं बल्कि, वे महंगी हैं, इसलिए बुद्धिमानी से उनका उपयोग करें।

मैं अत्यधिक है कि इस पुस्तक सलाह देते हैं। पीछे से पढ़ने के लायक है, हालांकि यह काफी बड़ा है, ~ 900 पेज।

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

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

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

संक्षेप में आप कह सकते हैं, "एकाधिक धागे का उपयोग न करें जब तक आपके पास कोई कारण न हो"।
फिर भी, टी (एच) हल्के से पढ़ते हैं।

+1

सूचनात्मक प्रतिक्रिया के लिए धन्यवाद। कुछ तर्क उठाने और काउंटर हासिल करने के लिए यह अशिष्ट होना था।आपके द्वारा लिंक किया गया लेख सही था और निश्चित रूप से किसी भी बहस में उपयोग करने के लिए एक रखरखाव है। और मुझे भी खुशी है कि मैं आपके जवाब से थोड़ी अधिक दूध निकाल सकता हूं! ;)। मैं आपका जवाब अभी भी नहीं चुनूंगा। चूंकि मुझे यह देखने में दिलचस्पी है कि काउंटर राय के साथ कोई भी होगा या नहीं। – David

+0

मदद की खुशी है! –

+1

धागे की संख्या से मेल खाने से सीपीयू की संख्या उन कार्यक्रमों में इष्टतम हो सकती है जिन्हें कभी भी I/O की प्रतीक्षा करने की आवश्यकता नहीं होती है [या तो I/O संचालन के लिए इंतजार कर रहा है, या बाहरी घटनाओं के लिए प्रतीक्षा कर रहा है, नोटिस के माध्यम से आई/ओ]। यह देखते हुए कि कोड के कई टुकड़ों को ऐसी चीजों के इंतजार की आवश्यकता होगी जब कभी-कभी उनकी आंतरिक स्थिति जटिल हो, ऐसी चीजों को प्रबंधित करने के लिए धागे का उपयोग करना सहायक होता है। – supercat

8

मैं Jokob जवाब पसंद है और मुझे लगता है कि महत्वपूर्ण बिंदुओं में से सबसे पहले से ही किया गया है:

  • 1k धागे (विश्व स्तर पर) मतलब यह नहीं है कि वे पूरी तरह से चल रहे हैं: वे सभी के चारों ओर बैठे
  • इंतजार कर रहे हो सकता है
  • सामान्य रूप से, वैश्विक सिस्टम में धागे की संख्या बहुत भ्रामक है (नीचे स्पष्टीकरण देखें)
  • थ्रेड (समान नहीं) समानांतर प्रोग्रामिंग के लिए उपयोग किए जाते हैं: वे उन स्थितियों में उपयोग किए जाते हैं जहां आपको एक से अधिक पंक्ति की आवश्यकता होती है निष्पादन (जब आप किसी नेटवर्क के लिए प्रतीक्षा करना बंद कर देते हैं उत्तर, उदाहरण के लिए, लेकिन आपको अभी भी यूआई को अपडेट करने और इसे उत्तरदायी रखने की आवश्यकता है, या जब आपके पास समान प्रक्रिया में कम प्राथमिकता कार्य (वर्तनी जांच, कोड निरीक्षण, ...) है ...)। आखिरकार, धागे मौजूद थे और मल्टीकोर सीपीयू से पहले काफी उपयोगी थे!
  • हालांकि अब हम अक्सर "पागलपन" देखते हैं: बहुत सारे धागे। यह नया नहीं है: पहले मामलों में से एक जहां प्रारंभिक नेटवर्क (वेब?) सर्वर: एक धागा प्रति कनेक्शन (!)। बेवकूफ, अपमानजनक। हम आगे बढ़े, और अब हम थ्रेडपूल (और अधिक परिष्कृत चीजें भी, जैसे I/O समापन बंदरगाहों) और (हाल ही में) एसिंक्रोनस प्रोग्रामिंग का उपयोग करते हैं।

हालांकि, थ्रेडपूल के मामले में भी, थ्रेड की संख्या प्रति-प्रक्रिया है (जब तक आप सिस्टम थ्रेडपूल का उपयोग नहीं करते हैं, जो Windows2000 से आगे उपलब्ध है); इसलिए यदि आपके पास 4 कोर सिस्टम से सबसे बड़ा लाभ लेने की इच्छा रखने वाली 50 प्रक्रियाएं हैं, तो आपके पास वैश्विक स्तर पर 200 धागे की उचित संख्या है (और, आमतौर पर, थ्रेडपूल के पास अधिकतम 2X संख्या कोर होते हैं, I/O ब्लॉक लेने के लिए और खाते में प्रतीक्षा करें)।

यह स्वाभाविक है, आपको प्रति प्रक्रिया को सोचना है, ओएस चौड़ा नहीं। अगर आप सभी प्रक्रियाओं के लिए एक हार्ड सीमा के साथ केंद्रीकृत थ्रेडपूल का उपयोग करते हैं तो क्या होगा, इसके बारे में सोचें। मान लें कि एक आवेदन उन सभी को लेता है: आपके पास क्या विकल्प है? नहीं, आपके पास कठोर, ओएस चौड़ी सीमा नहीं हो सकती है। प्रत्येक आवेदन मूल रूप से अपने आप पर है। यह मॉडल "आधुनिक" (1 99 0-युग) ओएस द्वारा अलग प्रक्रियाओं और वर्चुअल, निजी पता स्थान, जैसे एनटी और लिनक्स के आधार पर लागू होता है: आप ओएस में अकेले हैं, और दूसरों की परवाह नहीं करना चाहिए (कभी-कभी यह दृढ़ता से है प्रबलित, स्मृति के मामले में)

+1

+1 के साथ (वर्चुअल) मेमोरी से बाहर निकलते हैं, "आप अपने आप हैं, न दें दूसरों के बारे में कुछ भी "! –

0

सरल होने के लिए, ऑपरेटिंग सिस्टम सभी अनुप्रयोगों को लगता है कि वे स्वयं मशीन (कंप्यूटर) पर चल रहे हैं। उदाहरण के लिए 32 बिट एप्लिकेशन सैद्धांतिक रूप से 4 जीबी मेमोरी है जबकि भौतिक कंप्यूटर में 2 जीबी है। ओएस इसे प्रदान करने के लिए समय साझा करने वाले मल्टीप्लेक्सिंग जैसी तकनीकों का उपयोग कर रहा है। इस तंत्र के साथ आप इस 1 के थ्रेड देख सकते हैं। (मैंने टर्मिनल सर्वर पर 28K कनेक्ट किए गए टर्मिनल सर्वर पर 72K देखा था।) चूंकि थ्रेड बनाने के बाद महंगे प्रोग्रामर एक बार धागे बनाते हैं और जब वे म्यूटेक्स, सेमफोर जैसे तंत्र के माध्यम से कार्य किया जाता है तो वे उन्हें नींद बनाते हैं ...

ऐसा इसलिए है क्योंकि आप बहुत सारे धागे और 1% सीपीयू उपयोग देखते हैं। यदि आप देखना चाहते हैं कि थ्रेड का कितना सीपीयू संसाधन थ्रेड या एप्लिकेशन के लिए CPU समय की जांच करता है। यह क्या हो रहा है के बारे में अधिक संकेत देता है।