समानांतर या वितरित कंप्यूटिंग अपने आप में एक बहुत ही गैर-तुच्छ चीज है। और विकास के माहौल का समर्थन करना चाहिए, और डीएस विशेषज्ञ के पास समानांतर कंप्यूटिंग का संचालन करने के लिए कौशल होना चाहिए, और कार्य को एक ऐसे रूप में घटाया जाना चाहिए, जो कि एक में मौजूद हो। लेकिन एक सक्षम दृष्टिकोण के साथ, आप एकल-थ्रेडेड आर के साथ समस्या के समाधान में बहुत तेजी ला सकते हैं, यदि आपके पास कम से कम मल्टीकोर प्रोसेसर है (और लगभग सभी के पास अब है), तो अमाल्ड के नियम द्वारा निर्धारित सैद्धांतिक त्वरण सीमा के लिए समायोजित किया गया है। हालांकि, कुछ मामलों में, यहां तक ​​कि इसे दरकिनार भी किया जा सकता है।

यह पिछले प्रकाशनों का एक सिलसिला है।

विशिष्ट दृष्टिकोण

एक नियम के रूप में, जब एक विश्लेषक (डीएस विशेषज्ञ, डेवलपर, या अपने लिए कोई उपयुक्त नाम चुनते हैं) एक कंप्यूटर के भीतर कार्य को गति देने की कोशिश करता है और एकल-थ्रेडेड से बहु-थ्रेडेड मोड में स्थानांतरित करना शुरू कर देता है, वह इसे बॉयलरप्लेट तरीके से करता है। parApply , foreach\%dopar% , आदि। आप उदाहरण के लिए, कॉम्पैक्ट और समझदारी से देख सकते हैं: "R में समानांतरवाद" । 3 चरण:

1. core-1 धागा बनाओ
2. foreach का उपयोग करके चलाएं,
3. जवाब एकत्र करें और परिणाम प्राप्त करें।

विशिष्ट कंप्यूटिंग कार्यों के लिए जो 100% सीपीयू पर कब्जा करते हैं और बड़ी मात्रा में इनपुट जानकारी के हस्तांतरण की आवश्यकता नहीं होती है, यह सही दृष्टिकोण है। मुख्य बिंदु जिस पर ध्यान देने की आवश्यकता है, वह प्रक्रिया को नियंत्रित करने में सक्षम होने के लिए थ्रेड्स के भीतर लॉगिंग प्रदान करना है। बिना लॉग इन किए, उड़ान बिना साधनों के भी जाएगी।

"उद्यम" कार्यों के मामले में, जब वे समानांतर होते हैं, तो कई अतिरिक्त कार्यप्रणाली कठिनाइयाँ उत्पन्न होती हैं, जो उपरोक्त सीधे दृष्टिकोण के प्रभाव को काफी कम कर देती हैं:

• प्रवाह पर भार का संभावित मजबूत असंतुलन;
• एक ही काम के भीतर सीपीयू प्रदर्शन आवश्यकताओं को केवल कुछ तेज फटने के साथ फाड़ा जा सकता है;
• प्रत्येक व्यक्तिगत गणना में परिणाम के इनपुट और आउटपुट के लिए महत्वपूर्ण मात्रा में मेमोरी की आवश्यकता हो सकती है;
• एक अलग कार्य के हिस्से के रूप में, कंप्यूटिंग के बीच एक मिश्रण हो सकता है, डिस्क के साथ काम करना और बाहरी सिस्टम को क्वेरी करना।

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

उपयोगकर्ताओं, स्थानों, दस्तावेज़ों, आईपी-पतों, तिथियों, ... द्वारा Map-reduce ... (इसे स्वयं जोड़ें)। सबसे दुखद मामलों में, समानांतर निष्पादन एकल-थ्रेडेड से अधिक लंबा हो सकता है। याददाश्त की समस्या भी हो सकती है। क्या यह सब खत्म हो गया है? बिलकुल नहीं।

वैकल्पिक तरीका है

आइए हम इस स्थिति को मौलिक रूप से सुधारने के तरीके की थीसिस पर विचार करें। उसी समय, हम यह नहीं भूलते हैं कि हम एक पूर्ण चिड़ियाघर के ढांचे में रहते हैं। विन * nix \ MacOS पर *nix , डीएस लैपटॉप पर प्रोडक्टिव सर्किट, लेकिन यह आवश्यक है कि यह हर जगह समान रूप से काम करे।

1. Microtask: उपयोगकर्ता इनपुट प्राप्त किया, डेटाबेस का अनुरोध किया, REST के माध्यम से 2 बाहरी आईसी का अनुरोध किया, डाउनलोड किया और डिस्क से निर्देशिका को पार्स किया, गणना की, डिस्क \ डेटाबेस के लिए परिणाम डंप किया। उपयोगकर्ता, उदाहरण के लिए, 10^6 ।
2. हम future पैकेज और सार्वभौमिक doFuture एडाप्टर के उपयोग की ओर doFuture ।
3. यदि अलग-अलग कार्य ऐसे हैं कि अलग-अलग कार्यों के भीतर प्रोसेसर समय की थोड़ी मात्रा में आवश्यकता होती है (हम थर्ड-पार्टी सिस्टम के उत्तर की प्रतीक्षा कर रहे हैं), तो doFuture आपको doFuture स्प्लिटिंग से अलग -अलग प्रक्रियाओं में एक पंक्ति में विभाजित करने की अनुमति देता है (आप स्टार्टअप पैरामीटर *nix में htop देख सकते हैं) ।
4. इन प्रक्रियाओं को कोर से बहुत अधिक बनाया जा सकता है। ज्यादातर समय स्टैंडबाय मोड में रहने के कारण कोई भी प्रक्रिया नहीं होगी। लेकिन एक विशिष्ट प्रसंस्करण प्रक्रिया के साइक्लोग्राम के आधार पर प्रक्रियाओं की इष्टतम संख्या का चयन करना प्रयोगात्मक रूप से आवश्यक होगा।

परिणाम - मूल कार्य कई गुना तेज है। त्वरण उपलब्ध कोर की संख्या से भी अधिक हो सकता है।
जानबूझकर कोई कोड नहीं है, क्योंकि प्रकाशन का मुख्य कार्य future पैकेज के दृष्टिकोण और एक उत्कृष्ट परिवार को साझा करना है।

पुनश्च

कुछ छोटी बारीकियों का भी पता लगाना होगा:

• प्रत्येक प्रक्रिया मेमोरी का उपभोग करेगी, जिसमें प्राप्त डेटा और वापस लौटाया जाएगा। प्रक्रियाओं की संख्या में वृद्धि उपलब्ध रैम के लिए आवश्यकताओं को गुणा करेगी।
• doFuture प्रक्रिया में स्थानांतरित होने वाले चर और पैकेट की संरचना को स्वचालित रूप से निर्धारित करने के लिए "जादू" का उपयोग करता है, लेकिन आपको सब कुछ अपने आप से नहीं जाने देना चाहिए, यह जांचना बेहतर है।
• प्रक्रियाओं में, स्पष्ट gc नियंत्रण और rm का उपयोग करते हुए स्पष्ट चर हटाने से चोट नहीं पहुंचेगी। यह रामबाण नहीं है और काम नहीं कर सकता है, लेकिन स्पष्ट रूप से हटाए गए ऑब्जेक्ट को इंगित करने में मदद मिलेगी।
• गणना पूरी होने के बाद, कॉल plan(sequential) । यह सभी प्रक्रियाओं को बंद कर देगा और उन मेमोरी को मुक्त कर देगा जो वे कब्जा कर रहे हैं।
• यदि आपको प्रक्रिया में बड़ी मात्रा में डेटा स्थानांतरित करने की आवश्यकता है, तो बाहरी भंडारण (डिस्क, डेटाबेस) का उपयोग करने पर विचार करें। यह मत भूलो कि डिस्क्रिप्टर को स्थानांतरित नहीं किया जा सकता है, स्रोत को प्रक्रिया के अंदर ही खोला जाना चाहिए।

पिछला प्रकाशन - “उद्यम कंपनियों में व्यावसायिक प्रक्रियाएँ: अटकलें और वास्तविकता। हम आर के साथ प्रकाश बहाते हैं ” ।