क्या यह प्रोसेसर या कोड से संबंधित स्पीड-अप की कमी है?


0

मैंने एक प्रोग्राम लिखा है जो एमपीआई का उपयोग करता है, यह समीकरणों की एक बहुत बड़ी प्रणाली को हल करता है। मुझे बहुत बड़े सिस्टम के लिए बहुत अच्छे "स्पीड-अप" मिल रहे हैं। इससे मेरा तात्पर्य यह है कि यदि मैं प्रक्रियाओं की संख्या बढ़ाता हूं तो समय को आधा होने के साथ-साथ एक निरंतर समय भी पूरा हो जाता है जिसे मैं संचार मानता हूं। उदाहरण के लिए, एक प्रक्रिया में 60 के दशक लग सकते हैं, फिर दो पर 35 (60 + 5) लग सकते हैं, फिर 4 पर 20.5 (17.5 + 3) लग सकते हैं।

हालाँकि, जब सिस्टम में प्रवेश होता है जो लगभग 1 मिलियन से 1 मिलियन होता है तो मुझे अजीब परिणाम मिलने लगते हैं। जब 4 कोर से 8 कोर तक जा रहा हूं तो मुझे आधा समय प्लस 10 सेकंड "संचार" मिलता है। यानी, गणना पूरा करने में लगने वाला समय ~ 260 से ~ 140 हो जाता है।

यह ठीक है, लेकिन फिर जब 8 से 16 तक का समय ~ 140 से ~ 110 हो जाता है, तो 16 से 32 तक जाने पर मुझे भी ऐसा ही खराब परिणाम मिलता है। यह है, ~ 110 से ~ 85।

मुझे लगता है कि यह प्रोसेसर के साथ कुछ करने के लिए हो सकता है, क्योंकि यह व्यवहार अचानक प्रकट नहीं होगा (?)

सिस्टम में इनमें से 2 प्रोसेसर हैं

https://ark.intel.com/products/120485/Intel-Xeon-Gold-6140-Processor-24_75M-Cache-2_30-GHz

इसमें लगभग 8000GB RAM भी है।

मैं कुछ स्पष्टीकरण चाहूंगा कि ऐसा क्यों हो रहा है।

मुझे और जानकारी प्रदान करने में खुशी हो रही है। मुझे पता है कि यह एक जटिल मुद्दा है और मुझे यकीन नहीं है कि आपको कुल में क्या जानकारी चाहिए


आपने अपना कार्यक्रम कैसे लिखा है? क्या अलग-अलग प्रक्रिया के उदाहरणों को एक-दूसरे के साथ सिंक करना है या उनके बीच कोई डेटा भेजना है? क्या वे सीपीयू के अलावा किसी और चीज का इस्तेमाल करते हैं? क्या वे (सामान्य से अधिक) RAM का उपभोग करते हैं, क्या वे डिस्क (I / O) या इसी तरह लिखते हैं?
Fanatique

हां, ऐसे कई उदाहरण हैं जहां वे सिंक करते हैं और एक नोड (मास्टर नोड) अन्य सभी नोड्स में डेटा भेजता है। हालाँकि, मेरे अधिकांश अन्य प्रयोगों (आकार में उप 1 मिलि) के लिए फिर हम प्रोसेसर की संख्या को बढ़ाते हुए संचार समय लगभग स्थिर दिखाई देते हैं। शायद थोड़ा बढ़ जाए। लेकिन इस मामले में 10 से 30+ सेकंड तक कूदने जैसा कुछ भी नहीं है।
HMPARTICLE

वास्तविक डेटा मात्राओं को किसके चारों ओर धकेला जा रहा है? आप कहते हैं कि आपका "सिस्टम" "1 मिलियन बाय 1 मिलियन" है, लेकिन यह वास्तव में थोड़ा व्यर्थ है, कितना डेटा इन सभी प्रक्रियाओं के बीच तालमेल बिठाया जा रहा है कि प्रत्येक आकार आप परीक्षण कर रहे हैं? आप किस प्रोग्रामिंग भाषा का उपयोग कर रहे हैं? यहां तक ​​कि पायथन में एमपीआई भी है, लेकिन अजगर बड़े पैमाने पर गतिशील डेटासेट के साथ संघर्ष कर सकता है ... हालांकि किसी भी भाषा के लिए भी यही कहा जा सकता है।
Mokubai

मैं C ++ का उपयोग कर रहा हूं। मैं दो समान पूर्णांक के उत्पाद के रूप में आयाम देता हूं, इसलिए n = 256 और उदाहरण के लिए m = 512। मान लीजिए कि मेरे पास 4 प्रक्रियाएं हैं। फिर नोड 0 प्रत्येक प्रक्रिया को वितरित करता है (512/4) * 256 ^ 2 "डबल्स"। स्क्वैयर है क्योंकि आसपास मैट्रिसेस पास किए जा रहे हैं। कुछ गणना करता है और फिर गणना के अंत में MPI_allgather को कहा जाता है।
HMPARTICLE

यदि आपके पास दो प्रोसेसर हैं और आप MPI का उपयोग कर रहे हैं, तो क्या आप इस तथ्य का ध्यान रख रहे हैं कि प्रत्येक प्रोसेसर की अपनी "बैंक" रैम हो सकती है और डेटा या तो दोनों बैंकों में मौजूद होना चाहिए या दूसरे CPU पर प्रक्रियाओं को पढ़ना पड़ सकता है। यह के माध्यम से पहला सीपीयू। क्या आपका सिस्टम इस्तेमाल कर रहा है? NUMA या अन्यथा ऐसी सीमाओं को मार रहा है?
Mokubai

जवाबों:


0

इस तरह से निदान करना मुश्किल है, लेकिन यहां कुछ बिंदु दिए गए हैं:

  • प्रत्येक प्रक्रिया रैम का उपयोग करती है, इसलिए प्रक्रियाओं की संख्या दोगुनी हो जाती है आवश्यक रैम को दोगुना करना। यदि उपलब्ध भौतिक RAM समाप्त हो जाती है, तो डिस्क पर स्वैप करने से गति धीमी हो जाएगी प्रसंस्करण।

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

  • यदि प्रक्रियाएँ सिंक्रनाइज़ेशन विधियों जैसे कि सेमाफोर का उपयोग करती हैं, वेट पर कुछ समय बर्बाद होने की उम्मीद है, जो बढ़ेगा प्रक्रियाओं की संख्या के प्रत्यक्ष अनुपात में।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.