Afaik: समानांतर प्रसंस्करण के लिए उपयुक्त डेटा के लिए थ्रेड्स की इष्टतम संख्या कोर की संख्या है - चूंकि प्रत्येक थ्रेड में (सैद्धांतिक रूप से) पर चलाने के लिए अपनी खुद की एक कोर। सीपीयू के लिए जो हाइपर-थ्रेडिंग करने में सक्षम है, यह कोर की संख्या से 2x है। यदि मैं गलत हूं तो मुझे बताएं।
मेरा सवाल है अगर अंतर्निहित ओएस (लिनक्स,Winodws OSX) को स्वचालित रूप से मेरे "इरादे" का एहसास होगा और उदा। प्रत्येक सूत्र को एक ही कोर प्रदान करता है, यह मानते हुए कि मेरे पास है 8 कोर और तदनुसार 8 धागे जहां उनमें से प्रत्येक एक पर काम करता है "बहुत समय लगेगा“कार्य?
या आसपास का दूसरा तरीका: क्या धागे को कोर (विशेष रूप से में) को सौंपना संभव है Java)?
उत्तर:
जवाब के लिए 2 № 1AFAIK: समानांतर प्रसंस्करण के लिए उपयुक्त डेटा के लिए थ्रेड्स की इष्टतम संख्या कोर की संख्या है - चूंकि प्रत्येक थ्रेड में (सैद्धांतिक रूप से) चलने के लिए स्वयं का एक कोर है। सीपीयू के लिए जो हाइपर-थ्रेडिंग करने में सक्षम है, यह कोर की संख्या से 2x है। यदि मैं गलत हूं तो मुझे बताएं।
यह उससे कहीं अधिक जटिल है।
यह निर्भर करता है कि आप किस चीज के लिए अनुकूलन कर रहे हैं। यदि आपका उपलब्ध हार्डवेयर के कुशल (यानी लागत प्रभावी) के लिए अनुकूलन कर रहा है, तो यह शायद ही इष्टतम है। यदि किसी भी सूत्र को एक महत्वपूर्ण अवधि के लिए प्रतीक्षा करने की आवश्यकता है किसी कारणवश, तब एक-से-एक धागे का आवंटनभौतिक कोर के परिणाम में कोर के निरूपण का परिणाम है। अगर उन कोर को किसी और चीज़ के लिए इस्तेमाल किया जा सकता है (जैसे कि किसी को elses प्रोग्राम चलाने के लिए!) तो आपका उपयोग उप-योग है।
यहां तक कि अगर आप पूरी तरह से आवेदन की गति के लिए अनुकूलन कर रहे हैं, तो एक-से-एक आवंटन आवश्यक रूप से सर्वोत्तम रणनीति नहीं है।
प्रत्येक एप्लिकेशन + कार्यभार में एक "मीठा स्थान" हैधागे की संख्या की शर्तें। यह किसी भी आंतरिक विवाद की मात्रा और प्रकृति पर निर्भर करता है, और बाहरी प्रणालियों (फाइल सिस्टम, नेटवर्किंग, आदि) के साथ संचार की मात्रा और प्रकृति।
यदि आपके पास एक कठोर-प्रति-प्रति-कोर नियम है, तो आप एक एन कोर सिस्टम पर अधिकांश एन थ्रेड्स में हो सकते हैं।
यदि वह एन थ्रेड्स की "स्वीट स्पॉट" संख्या से काफी कम है, तो आप पा सकते हैं कि कोर बहुत समय से बेकार हैं।
अब हाइपर-थ्रेडिंग के लिए।
हाइपरथ्रेड्स संभावित रूप से आपको अतिरिक्त सीपीयू देते हैंचक्र प्रति घड़ी चक्र। हालांकि, वे आपको स्मृति प्रणाली में अतिरिक्त चक्र नहीं देते हैं। हाइपरथ्रेड "वर्चुअल कोर" की प्रदर्शन विशेषताएं एक भौतिक कोर के लिए अलग होंगी ... और वास्तविक जीवन के अनुप्रयोगों के लिए अंतर महत्वपूर्ण होगा। इसलिए आपके 2 x धारणा बिना आधार के है।
मेरा सवाल है अगर अंतर्निहित ओएस (लिनक्स,Winodws OSX) को स्वचालित रूप से मेरे "इरादे" का एहसास होगा और उदा। प्रत्येक सूत्र को एक ही कोर प्रदान करता है, यह मानते हुए कि मेरे पास है 8 कोर और तदनुसार 8 धागे जहां उनमें से प्रत्येक "समय लेने वाला" कार्य पर काम करता है?
जरुरी नहीं।
ओएस को अन्य बातों का ध्यान रखना होगासिस्टम पर हो रहे हैं। अन्य एप्लिकेशन, डेमॉन आदि जो आपके डेस्कटॉप को संभालते हैं, सामान जो फाइल सिस्टम और नेटवर्किंग प्रोटोकॉल से निपटते हैं।
ओएस (और JVM) आम तौर पर केवल पर प्रतिक्रिया करेगाशेड्यूलिंग निर्णय लेने में पहले से ही क्या हुआ है। अतीत के व्यवहार (इस स्तर पर) के आधार पर भविष्य के व्यवहार की भविष्यवाणी करना प्रभावी नहीं है ... और आधुनिक OSes इसे बहुत क्रूड / हेयुरिस्टिक स्तर पर छोड़कर करने का प्रयास नहीं करते हैं। पूर्ण (इष्टतम) भविष्यवाणी असंभव है, और भले ही आप। सही ज्ञान है शेड्यूलिंग समस्या NP-hard है।
सिद्धांत रूप में, एक आवेदन प्रोग्रामर डिजाइन कर सकता हैएक इष्टतम कार्यक्रम। व्यवहार में, अधिकांश एप्लिकेशन इसके लिए बहुत जटिल हैं और सिस्टम पर होने वाली अन्य "यादृच्छिक" चीजों का ध्यान रखना मुश्किल है।
या आसपास का दूसरा तरीका: क्या कोर (विशेष रूप से जावा में) को धागे सौंपना संभव है?
ऐसा करने का कोई व्यावहारिक तरीका नहीं है। (@ Ksmonkey123 का उत्तर देखें) निश्चित रूप से, कुछ नहीं
और संभवतः जावा में काम करने की संभावना नहीं हैवैसे भी। जावा के पास अतिरिक्त समस्या है कि आवेदन के पीछे चीजें छिपी हुई हैं (जैसे कि कचरा संग्रहकर्ता और अंतिम सूत्र), और जावा मेमोरी प्रबंधन के लिए भविष्यवाणी करना कठिन है और इसके लिए धुन करना मुश्किल है।
जवाब के लिए 2 № 2
नहीं, आप किसी विशिष्ट कोर में थ्रेड असाइन नहीं कर सकते Java (जावा मल्टीथ्रेडिंग - प्रोसेसर कोर को थ्रेड असाइन करें)
आम तौर पर आप उम्मीद कर सकते हैं कि ऑपरेटिंग सिस्टम थ्रेड के रनटाइम को कम या ज्यादा बेहतर तरीके से प्रबंधित कर सकता है। इसमें उदा। भुखमरी की रोकथाम।