मैं एक ब्लॉग पोस्ट थोड़ी देर पहले यह दावा करते हुए एक जावा आवेदन बेहतर भाग गया जब यह एक मल्टीकोर मशीन में एक CPU का उपयोग करने की अनुमति दी गई थी पढ़ा है: http://mailinator.blogspot.com/2010/02/how-i-sped-up-my-server-by-factor-of-6.htmlJVM
किन वजहों से वहाँ एक जावा अनुप्रयोग के लिए किया जा सकता है , एक कोर मशीन की तुलना में बहुत धीमी गति से चलाने के लिए मल्टीकोर मशीनों पर चल रहा है?
यदि वहाँ अलग धागे में साझा संसाधन के बीच महत्वपूर्ण विवाद है, यह हो सकता है कि ताला और वस्तुओं को अनलॉक IPI (अंतर-प्रोसेसर बीच में आता है) की एक बड़ी राशि की आवश्यकता है और प्रोसेसर उनके L1 और L2 कैश निकाल लिए और अधिक समय खर्च कर सकते हैं और अन्य CPUs से डेटा फिर से लाने से वास्तव में समस्या को हल करने पर प्रगति करने में खर्च करते हैं। यदि आवेदन रास्ता too-fine-grained locking है
यह एक समस्या हो सकती है। (मैंने एक बार यह सुना है कि "प्रति सीपीयू कैश लाइन प्रति एक से अधिक लॉक होने का कोई मतलब नहीं है", जो निश्चित रूप से सच है, और शायद अभी भी बहुत अच्छा है।)
जावा का "हर ऑब्जेक्ट एक म्यूटेक्स" हो सकता है चलने वाले सिस्टम में बहुत सारे ताले होने का कारण बनता है यदि बहुत से लोग रहते हैं और दलील देते हैं।
मुझे कोई संदेह नहीं है कि कोई जानबूझकर ऐसा एप्लिकेशन लिख सकता है, लेकिन शायद यह बहुत आम नहीं है। अधिकतर डेवलपर संसाधन अनुप्रयोगों को कम करने के लिए अपने अनुप्रयोग लिखेंगे जहां वे कर सकते हैं।
यह [अमाहल के कानून] (http://en.wikipedia.org/wiki/Amdahl%27s_law) और [लिटिल लॉ] (http://en.wikipedia.org/wiki/Little%27s_law) को अनदेखा कर रहा है जो मूल रूप से फोड़ा जाता है नीचे: भाषा/पर्यावरण के बावजूद, कुछ चीजें समानांतर कार्यों में बहुत अच्छी तरह से विभाजित नहीं होती हैं। –
मुझे "बहुत" हिस्सा संदेह है।
मेरा अनुमान होगा कि एक से दूसरे सीपीयू से राज्य चलती की कीमत काफी अधिक ध्यान देने योग्य हो रहा है। आम तौर पर आप एक ही सीपीयू पर रहने के लिए नौकरियां चाहते हैं, इसलिए इसका डेटा स्थानीय रूप से जितना संभव हो सके कैश किया जाता है।
यह पूरी तरह से लेख/डेटा के बिना अटकलों का अनुमान है, लेकिन कुछ प्रकार के कार्यक्रम हैं जो समांतरता के लिए उपयुक्त नहीं हैं - शायद एप्लिकेशन कभी भी सीपीयू-बाध्य नहीं है (जिसका अर्थ है कि सीपीयू बाधा नहीं है, शायद कुछ प्रकार I/O है)।
हालांकि यह प्रश्न/वार्तालाप अधिक जानकारी के बिना सुंदर आधारहीन है।
इसके लिए जावा-विशिष्ट कारण नहीं है, लेकिन कोर से कोर या यहां तक कि सीपीयू से सीपीयू तक चलने वाला राज्य समय लगता है। यदि प्रक्रिया एक कोर पर रहती है तो इस बार बेहतर इस्तेमाल किया जा सकता है। इसके अलावा, ऐसे मामलों में कैशिंग में सुधार किया जा सकता है।
यह केवल प्रासंगिक हालांकि अगर कार्यक्रम एक से अधिक थ्रेड उपयोग नहीं किया जाता है और इस प्रकार प्रभावी रूप से कई कोर/सीपीयू के लिए पर अपना काम वितरित कर सकते हैं।
हाल इंटेल सीपीयू टर्बो बूस्ट की है। यदि आप चार कार्यकर्ता-धागे भारी संख्या में क्रंचिंग करते हैं, तो ऐप क्वाड-कोर मशीन पर लगभग चार गुना तेज होगा, इस पर निर्भर करता है कि आपको कितना बुक-रखरखाव और विलय करना चाहिए।
, सबसे बुरी बात यह है कि वास्तव में बेतुका (यदि दुर्भावनापूर्ण नहीं है) कार्य शेड्यूलर चीजों की व्यवस्था करने का प्रयास कर सकता है ताकि टर्बो बूस्ट इसमें लात न सके - और मुझे यह भी यकीन नहीं है कि यह वास्तव में उस तरीके से छेड़छाड़ की जा सकती है। किसी भी मामले में यह कभी भी 6x प्रदर्शन अंतर की राशि नहीं होगी। –
मैं सहमत हूं। टर्बो बूस्ट भी 6x के करीब नहीं आता है। – Puppy
इस धागे आवेदन spawns की संख्या पर निर्भर हो जाएगा:
एप्लिकेशन इंटर-थ्रेड संचार को अवरुद्ध करने का बहुत खराब उपयोग कर सकता है। हालांकि, यह पूरी तरह से इस तथ्य के लिए नीचे होगा कि आवेदन असाधारण रूप से खराब प्रोग्राम किया गया है।
कोई कारण नहीं है सब पर क्यों किसी भी भी औसत दर्जे-ly एक मामूली parallelisable कार्यभार के साथ मल्टी कोर आवेदन क्रमादेशित कई कोर पर धीमी चलाना चाहिए नहीं है।
शुद्ध प्रदर्शन परिप्रेक्ष्य से, चुनौती अक्सर स्मृति उपप्रणाली के आसपास होती है। इसलिए जब अधिक सीपीयू अक्सर अच्छे होते हैं, तो सीपीयू जो जावा ऑब्जेक्ट्स में बैठे स्मृति के पास नहीं हैं, बहुत महंगा है। यह बहुत मशीन विशिष्ट है, और प्रत्येक सीपीयू और मेमोरी के बीच सटीक पथ पर निर्भर करता है। इंटेल और एएमडी दोनों में विभिन्न आकार/गतिएं हैं, और परिणाम काफी भिन्न होते हैं।
देखें क्योंकि मल्टी-कोर क्यों बाधा डाल सकता है।
हमने प्रोसेसर को JVMs पिन करने के तरीके के आधार पर 30% रेंज या उससे अधिक में प्रदर्शन डेल्टा देखा है। SPECjbb2005 अब ज्यादातर "बहु-जेवीएम" मोड में चलाया जाता है जिसमें इस कारण से दिए गए CPU/स्मृति से जुड़े प्रत्येक JVM के साथ होता है।
सीपीयू की अक्सर सीमा होती है कि वे कितनी गर्मी पैदा कर सकते हैं। इसका मतलब है कि कम कोर वाला एक चिप उच्च आवृत्ति पर चलाया जा सकता है जिसके परिणामस्वरूप एक प्रोग्राम तेजी से चल रहा है यदि यह अतिरिक्त कोर का प्रभावी ढंग से उपयोग नहीं करता है। आज अंतर 4, 6 और 8 कोर के बीच है, जहां अधिक कोर व्यक्तिगत रूप से धीमे होते हैं। मुझे किसी एकल कोर सिस्टम के बारे में पता नहीं है जो सबसे तेज़ 4 कोर सिस्टम से तेज़ है।
लेख में लेखक ने 6 – IttayD
की बजाय केवल एक ही सीपीयू को आवंटित करके अपने सर्वर को तेज़ी से बनाया है, आप सही हैं कि वह अपनी सभी प्रक्रियाओं को एक कोर में आवंटित कर रहा है। यदि यह काम करता है, तो वह लगभग निश्चित रूप से एक ट्यूनिंग समस्या है, हालांकि यह क्या अस्पष्ट है। –
जेआईटी में स्मृति बाधाओं को शामिल नहीं किया जाएगा यदि यह एक कोर में चल रहा है। मुझे संदेह है कि संदर्भित आलेख में क्या हो रहा है।
यहाँ स्मृति बाधाओं का एक बहुत ही संक्षिप्त विवरण है, यह भी JIT'd कोड को देखने का एक स्वच्छ तकनीक प्रदान करता है: http://www.infoq.com/articles/memory_barriers_jvm_concurrency
यह सभी अनुप्रयोगों से लाभ होगा कहने के लिए नहीं है एक भी पर रखा जा रहा कोर।
[जावा, प्रदर्शन और बहु कोर] (http://www.google.com/search?q=java+performance+multi+core) के लिए बहुत सारे आशाजनक लिंक हैं। यदि आप एक ब्लॉग पोस्ट सूची में हैं तो क्या आप एक नोट छोड़ सकते हैं? –