4-कोर सीपीयू पर समान गणना कैसे करें: 4 धागे या 50 धागे?

Question

आइए मान लें कि हमारे पास ब्लॉकिंग, नींद, आई/ओ-प्रतीक्षा किए बिना गणना कार्य की निश्चित राशि है। काम को समानांतर समांतर किया जा सकता है - इसमें 100 एम छोटे और स्वतंत्र गणना कार्य होते हैं।

4-कोर CPU के लिए तेज़ क्या है - 4 धागे चलाने के लिए या ... 50 कहें? क्यों दूसरा संस्करण धीमा होना चाहिए और कितना धीमा होना चाहिए?

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

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

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

Answer 1

जैसा कि @ बाइल टिप्पणियों में उल्लेख करता है, यह अत्यधिक एप्लिकेशन, सिस्टम, पर्यावरण-विशिष्ट है।

और इस तरह, मैं प्रत्येक कोर के लिए बिल्कुल 1 धागे का उल्लेख करने के हार्ड लाइन दृष्टिकोण नहीं ले रहा हूं। (या हाइपरथ्रेडिंग के मामले में 2 धागे/कोर)

एक अनुभवी साझा-मेमोरी प्रोग्रामर के रूप में, मैंने अपने अनुभव से देखा है कि थ्रेड (4 कोर मशीन के लिए) इष्टतम # 1 से 64 तक कहीं भी हो सकता है +।

अब मैं स्थितियों है कि इस रेंज का कारण बन सकती करके बताना होगा:

इष्टतम धागे < कोर की #

कुछ कार्यों कि अत्यंत सूक्ष्म कर रहे हैं (जैसे छोटे FFTs के रूप में) के समानांतर में, थ्रेडिंग का ओवरहेड प्रमुख प्रदर्शन कारक है। कुछ मामलों में, यह समानांतर करने में सहायक नहीं है। कुछ मामलों में, आप 2 थ्रेड के साथ स्पीडअप प्राप्त करते हैं, लेकिन पीछे 4 धागे पर स्केलिंग करते हैं।

एक और मुद्दा संसाधन विवाद है। यहां तक ​​कि यदि आपके पास अत्यधिक समानांतर कार्य है जो आसानी से 4 कोर/धागे में विभाजित हो सकता है, तो आप मेमोरी बैंडविड्थ और कैश प्रभावों से बाधित हो सकते हैं। अक्सर, आप पाते हैं कि 2 धागे 4 धागे जितना तेज़ होंगे।कोर

की

इष्टतम धागे = # यह इष्टतम मामला है (यदि अक्सर बहुत बड़ी FFTs के मामले में)। यहां व्याख्या करने की कोई आवश्यकता नहीं - प्रति कोर एक धागा। सबसे शर्मनाक समानांतर अनुप्रयोग जो मेमोरी या आई/ओ बाध्य नहीं हैं यहां ठीक हैं।

इष्टतम धागे> कोर

यह जहां यह दिलचस्प ... बहुत दिलचस्प हो जाता है है की #। क्या आपने लोड असंतुलन के बारे में सुना है? ओवर-अपघटन और काम-चोरी के बारे में कैसे?

कई समानांतर अनुप्रयोग अनियमित होते हैं - जिसका अर्थ है कि कार्य बराबर आकार के उप-कार्यों में विभाजित नहीं होते हैं। तो यदि आप एक बड़े कार्य को 4 असमान आकार में विभाजित कर सकते हैं, तो उन्हें 4 धागे तक असाइन करें और उन्हें 4 कोर पर चलाएं ... परिणाम? खराब समानांतर प्रदर्शन क्योंकि 1 धागा अन्य धागे की तुलना में 10x अधिक काम प्राप्त हुआ।

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

---

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

---

संपादित करें: का जवाब विस्तार और सीधे सवाल का जवाब ...

संदर्भ स्विचिंग की लागत क्या है? स्टोर के लिए समय और सीपीयू अलग-अलग संदर्भ के लिए पुनर्स्थापित करता है?

यह पर्यावरण पर बहुत निर्भर है - और सीधे मापने में कुछ मुश्किल है।
लघु जवाब: बहुत महंगाThis might be a good read.

क्या कैश, पाइपलाइनों और CPU के अंदर विभिन्न कोड-भविष्यवाणी चीजों के बारे में? क्या हम कह सकते हैं कि प्रत्येक बार जब हम संदर्भ बदलते हैं, तो हमने सीपीयू, पाइपलाइनों और सीपीयू में कुछ कोड-डिकोडिंग सुविधाओं को नुकसान पहुंचाया है?

लघु जवाब: हाँ जब आप संदर्भ बाहर स्विच, आप की संभावना अपने पाइपलाइन और गंदगी सब भविष्यवक्ताओं फ्लश। कैश के साथ ही। नया धागा नए डेटा के साथ कैश को प्रतिस्थापित करने की संभावना है।

हालांकि एक पकड़ है। कुछ अनुप्रयोगों में जहां धागे एक ही डेटा साझा करते हैं, यह संभव है कि एक थ्रेड एक ही आने वाले धागे या अन्य थ्रेड के लिए कैश को "गर्म" कर सकता है, जो एक ही कैश को साझा करने वाले एक अलग कोर पर हो सकता है।(हालांकि दुर्लभ, मैंने देखा है यह मेरा NUMA मशीनों में से एक पर पहले हो - superlinear speedup:?!?! 16 कोर के पार 17.6x)

तो अधिक एक सिंगल कोर पर क्रियान्वित करने सूत्र, कम काम वे अपने सीरियल निष्पादन की तुलना में एक साथ कर सकते हैं?

निर्भर करता है, निर्भर करता है ... एक तरफ हाइपरथ्रेडिंग, निश्चित रूप से ओवरहेड होगा। लेकिन मैंने एक पेपर पढ़ा है जहां किसी ने मुख्य थ्रेड के लिए प्रीफेच करने के लिए दूसरा थ्रेड इस्तेमाल किया है ... हाँ यह पागल है ...

Answer 2

यदि आप 4 धागे का उपयोग कर सकते हैं, तो उनका उपयोग करें। 4-कोर मशीन पर 50 से 4 की तेजी से कोई रास्ता नहीं होगा। आपको जो भी मिलता है वह अधिक ऊपरी होता है।

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

Answer 3

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

Answer 4

50 धागे बनाना वास्तव में प्रदर्शन को नुकसान पहुंचाएगा, इसे बेहतर नहीं करेगा। यह सिर्फ कोई समझ नहीं आता है।

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

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

लेकिन गंभीरता से ... कंपाइलर्स और, जावा, जेवीएम के मामले में, उन हिस्सों को इतनी अच्छी तरह अनुकूलित करेंगे कि यह इसके लायक नहीं है (जब तक कि आप वास्तव में ऐसा कुछ नहीं करना चाहते)। 100 सेकंड में आपकी गणनाओं की बजाय, वे 97 या 98 में खत्म हो जाएंगे। सवाल जो आपको खुद से पूछना चाहिए: क्या यह कोडिंग और डिबगिंग के उन सभी घंटों के लायक है?

आपने संदर्भ स्विचिंग की समय लागत के बारे में पूछा। इन दिनों, ये बहुत कम हैं। आधुनिक दिन दोहरे कोर CPUs देखें जो उदाहरण के लिए विंडोज 7 चलाते हैं। यदि आप उस मशीन और एक MySQL डेटाबेस सर्वर पर अपाचे वेब सर्वर प्रारंभ करते हैं, तो आप आसानी से 800 से अधिक धागे पर जायेंगे। मशीन बस इसे महसूस नहीं करती है। यह लागत देखने के लिए, यहां पढ़ें: How to estimate the thread context switching overhead?। आपको खोज/पढ़ने का हिस्सा छोड़ने के लिए: संदर्भ स्विचिंग प्रति सेकेंड हजारों बार प्रति सेकंड किया जा सकता है।

Answer 5

4 थ्रेड तेज़ होते हैं यदि आप अपने 40 कार्यों को ऑपरेटिंग सिस्टम से बेहतर स्विचिंग प्रोग्राम कर सकते हैं।