[अनुवाद] समानांतर धाराओं का उपयोग कब करें

स्रोत
लेखक: ब्रायन गोएटज़, पॉल सैंडोज़, अलेक्सी शिपिलेव, हेंज काबुत्ज़, जो बोएबीर, के साथ डग ली ...

java.util.streams फ्रेमवर्क में संग्रह और अन्य डेटा स्रोतों पर डेटा-चालित संचालन शामिल हैं। अधिकांश धारा विधियाँ प्रत्येक तत्व पर समान संचालन करती हैं। parallelStream() संग्रह विधि का उपयोग करते हुए, यदि आपके पास कई कोर हैं, तो आप डेटा-संचालित को डेटा-समानांतर में बदल सकते हैं। लेकिन यह कब करने लायक है?

S.parallelStream().operation(F) का उपयोग करने पर विचार करें S.parallelStream().operation(F) बजाय S.parallelStream().operation(F) S.stream().operation(F) , बशर्ते कि ऑपरेशन एक दूसरे से स्वतंत्र हैं और या तो कम्प्यूटेशनल रूप से महंगे हैं या बड़ी संख्या में ऐसे तत्वों पर लागू होते हैं जो प्रभावी रूप से विभाजित हैं। (अलग-अलग) डेटा संरचनाएं, या दोनों। अधिक सटीक:

• F : एक तत्व के साथ काम करने के लिए एक फ़ंक्शन, आमतौर पर एक लंबोदर, स्वतंत्र होता है, अर्थात्। किसी भी तत्व पर ऑपरेशन स्वतंत्र है और अन्य तत्वों पर संचालन को प्रभावित नहीं करता है (गैर-हस्तक्षेप करने वाले स्टेटलेस कार्यों के उपयोग के लिए सिफारिशें, स्ट्रीम पैकेज के लिए दस्तावेज देखें)।
• S : मूल संग्रह प्रभावी रूप से विभाजित है। संग्रह के अलावा, अन्य समानांतर हैं, डेटा स्रोतों को स्ट्रीमिंग करने के लिए उपयुक्त हैं, उदाहरण के लिए, java.util.SplittableRandom (समानांतरण जिसके लिए आप stream.parallel() विधि) का उपयोग कर सकते हैं। लेकिन कोर में I / O के साथ अधिकांश स्रोत मुख्य रूप से अनुक्रमिक संचालन के लिए डिज़ाइन किए गए हैं।
• अनुक्रमिक मोड में कुल रन समय न्यूनतम स्वीकार्य सीमा से अधिक है। आज, अधिकांश प्लेटफ़ॉर्म के लिए, सीमा लगभग १० माइक्रोसेकंड के बराबर (x10 के भीतर) है। इस मामले में, सटीक माप की आवश्यकता नहीं है। व्यावहारिक उद्देश्यों के लिए, यह केवल Q (एक F का ऑपरेटिंग समय) द्वारा N (तत्वों की संख्या) को गुणा करने के लिए पर्याप्त है, और Q को लगभग संचालन की संख्या या कोड की लाइनों की संख्या से अनुमान लगाया जा सकता है। उसके बाद, आपको यह जांचने की आवश्यकता है कि N * Q कम से कम 10000 से कम है (यदि आप शर्मीले हैं, तो एक या एक जोड़ी जोड़ें)। इसलिए, यदि F एक छोटा कार्य है जैसे x -> x + 1 , तो समानांतर निष्पादन का अर्थ होगा जब N >= 10000 । इसके विपरीत, यदि F एक वजनदार गणना है, तो शतरंज के खेल में अगली सबसे अच्छी चाल खोजने के समान है, तो Q मूल्य इतना बड़ा है कि N को उपेक्षित किया जा सकता है, लेकिन जब तक संग्रह पूरी तरह से विभाजित नहीं हो जाता।

स्ट्रीमिंग प्रसंस्करण ढांचा उपरोक्त में से किसी पर भी जोर नहीं देगा (और नहीं कर सकता)। यदि गणना अन्योन्याश्रित हैं, तो उनके समानांतर निष्पादन का कोई मतलब नहीं है, या बिल्कुल हानिकारक होगा और त्रुटियों को जन्म देगा। उपरोक्त इंजीनियरिंग मुद्दों और ट्रेडऑफ से प्राप्त अन्य मानदंडों में शामिल हैं:

• लॉन्च (स्टार्ट-अप)
  प्रोसेसर में अतिरिक्त कोर की उपस्थिति, ज्यादातर मामलों में, एक शक्ति प्रबंधन तंत्र के अतिरिक्त के साथ थी, जो कभी-कभी जेवीएम, ऑपरेटिंग सिस्टम और हाइपरवाइजर से अतिरिक्त ओवरले के साथ, कोर के प्रक्षेपण में मंदी का कारण बन सकती है। इस मामले में, जिस सीमा पर समानांतर मोड समझ में आता है वह पर्याप्त संख्या में कोर के साथ उपप्रकार प्रसंस्करण शुरू करने के लिए आवश्यक समय से मेल खाती है। उसके बाद, अनुक्रमिक की तुलना में समानांतर कंप्यूटिंग अधिक ऊर्जा कुशल हो सकती है (प्रोसेसर और सिस्टम के विवरण के आधार पर। उदाहरण के लिए, लेख देखें )।
• विवरण देना (ग्रैन्युलैरिटी)
  यह छोटी गणनाओं को विभाजित करने के लिए शायद ही कभी समझ में आता है। फ्रेमवर्क आमतौर पर कार्य को विभाजित करता है ताकि सभी उपलब्ध सिस्टम कोर पर व्यक्तिगत भाग काम कर सकें। यदि, शुरुआत के बाद, प्रत्येक कोर के लिए व्यावहारिक रूप से कोई काम नहीं है, तो (आमतौर पर अनुक्रमिक) समानांतर कंप्यूटिंग को व्यवस्थित करने के प्रयास बर्बाद हो जाएंगे। यह देखते हुए कि कोर की संख्या 2 से 256 थ्रेसहोल्ड तक होती है, यह कार्य के अत्यधिक विभाजन के अवांछनीय प्रभाव को भी रोकता है।
• पृथक करने की क्षमता (Splittability)
  सबसे कुशलता से विभाजित संग्रह में ArrayList और {Concurrent}HashMap , साथ ही नियमित सरणियाँ ( T[] , जो स्थिर java.util.Arrays विधियों का उपयोग करके भागों में विभाजित हैं। कम से कम कुशल स्प्लिटर LinkedList , BlockingQueue और आई / ओ आधारित अधिकांश स्रोत हैं। बाकी कहीं बीच में हैं (डेटा संरचनाएं जो यादृच्छिक अभिगम का समर्थन करती हैं और / या कुशल खोज आमतौर पर कुशलता से विभाजित होती हैं)। यदि बंटवारे का डेटा प्रसंस्करण से अधिक समय लेता है, तो प्रयास व्यर्थ है। यदि Q काफी बड़ा है, तो आप LinkedList लिए भी समानांतर होने के कारण वृद्धि प्राप्त कर सकते हैं, लेकिन यह एक दुर्लभ मामला है। इसके अलावा, कुछ स्रोतों को एक तत्व में विभाजित नहीं किया जा सकता है, और इस प्रकार, समस्या के अपघटन की डिग्री पर प्रतिबंध हो सकता है।

इन प्रभावों की सटीक विशेषताओं को प्राप्त करना मुश्किल हो सकता है (हालांकि, यदि आप कोशिश करते हैं, तो यह जेएमएच जैसे उपकरणों का उपयोग करके किया जा सकता है )। लेकिन संचयी प्रभाव नोटिस करना काफी आसान है। इसे स्वयं महसूस करने के लिए - एक प्रयोग करें। उदाहरण के लिए, 32-कोर टेस्ट मशीन पर, जब आप छोटे कार्य चलाते हैं, जैसे कि max() या sum() , ArrayList ऊपर ArrayList ब्रेक- ArrayList पॉइंट लगभग 10,000 होता है। अधिक तत्वों के लिए, 20 गुना तक त्वरण नोट किया जाता है। 10,000 से कम वस्तुओं वाले संग्रह के लिए खुलने का समय 10,000 से बहुत कम नहीं है, और इसलिए अनुक्रमिक प्रसंस्करण की तुलना में धीमा है। सबसे खराब परिणाम 100 से कम तत्वों के साथ होता है - इस मामले में, शामिल थ्रेड्स कुछ भी उपयोगी होने के बिना बंद हो जाते हैं, क्योंकि गणना शुरू होने से पहले पूरी हो जाती है। दूसरी ओर, जब तत्वों पर संचालन समय लेने वाला होता है, जब कुशल और पूरी तरह से संग्रहणीय संग्रह, जैसे कि ArrayList , तो लाभ तुरंत दिखाई देते हैं।

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

क्यू एंड ए

• समानांतर में परिचालन निष्पादित करने के लिए जेवीएम क्यों नहीं समझ सकता है?

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

• क्या होगा अगर एक अच्छा निर्णय लेने के लिए मुझे मापदंडों ( F , N , Q , S ) के बारे में पर्याप्त ज्ञान नहीं है?

यह भी, अनुक्रमिक प्रोग्रामिंग में आने वाली समस्याओं के समान है। उदाहरण के लिए, Collection वर्ग का S.contains(x) विधि आम तौर पर तेजी से चलती है यदि S एक HashSet , तो धीमी है यदि LinkedList और अन्य मामलों में औसत है। आमतौर पर, संग्रह का उपयोग करने वाले घटक के लेखक के लिए, इस स्थिति से बाहर का सबसे अच्छा तरीका यह है कि इसे एनकैप्सुलेट किया जाए और इसके लिए केवल एक विशिष्ट ऑपरेशन प्रकाशित किया जाए। फिर उपयोगकर्ताओं को चुनने की आवश्यकता से अलग किया जाएगा। समानान्तर परिचालनों पर भी यही लागू होता है। उदाहरण के लिए, आंतरिक मूल्य संग्रह के साथ एक घटक एक ऐसी विधि निर्धारित कर सकता है जो उसके आकार को सीमा तक जांचता है, जो समझ में आएगा जब तक कि बिटकॉइन कंप्यूटिंग बहुत महंगा नहीं है। एक उदाहरण:

 public long getMaxPrice() { return priceStream().max(); } private Stream priceStream() { return (prices.size() < MIN_PAR) ? prices.stream() : prices.parallelStream(); } 

यह विचार कब और कैसे संगामिति का उपयोग किया जाए, इसके बारे में अन्य विचारों तक बढ़ाया जा सकता है।

• यदि मेरा कार्य संभवतया I / O या सिंक्रनाइज़ ऑपरेशन करता है तो क्या होगा?

एक चरम पर ऐसे कार्य हैं जो स्वतंत्रता के मानदंडों को पूरा नहीं करते हैं, जिसमें अनुक्रमिक I / O संचालन शामिल हैं, ताला लगा हुआ सिंक्रनाइज़ संसाधनों तक पहुंच, और ऐसे मामले जिनमें I / O प्रदर्शन करने वाले एक समानांतर उप-कार्य में त्रुटि दूसरों को प्रभावित करती है। उनका समानांतर होना बहुत मायने नहीं रखता। दूसरी ओर, ऐसी गणनाएँ हैं जो कभी-कभी I / O या शायद ही कभी सिंक्रनाइज़ेशन को रोकती हैं (उदाहरण के लिए, लॉगिंग के अधिकांश मामले और ConcurrentHashMap रूप में इस तरह के प्रतिस्पर्धी संग्रह का उपयोग)। वे हानिरहित हैं। उनके बीच क्या है और अधिक शोध की आवश्यकता है। यदि प्रत्येक सबटास्क को I / O या एक्सेस की प्रतीक्षा में काफी समय तक अवरुद्ध किया जा सकता है, तो प्रोग्राम या JVM द्वारा उनके उपयोग की संभावना के बिना CPU संसाधन निष्क्रिय हो जाएंगे। इससे सभी का बुरा हाल है। इन मामलों में, समानांतर स्ट्रीमिंग प्रोसेसिंग हमेशा सही विकल्प नहीं होती है। लेकिन अच्छे विकल्प हैं - उदाहरण के लिए, अतुल्यकालिक I / O और CompletableFuture दृष्टिकोण।

• यदि मेरा स्रोत I / O पर आधारित हो तो क्या होगा?

फिलहाल, JDK Stream / I / O जनरेटर (उदाहरण के लिए, BufferedReader.lines() ) का उपयोग करते हुए, वे मुख्य रूप से अनुक्रमिक मोड में उपयोग के लिए अनुकूलित होते हैं, एक के बाद एक उपलब्ध तत्वों को संसाधित करते हैं। बफर आई / ओ के उच्च प्रदर्शन वाले थोक प्रसंस्करण के लिए समर्थन संभव है, लेकिन, फिलहाल, इसके लिए विशेष जनरेटर Stream एस, Spliterator एस और Collector एस के विकास की आवश्यकता है। JDK की भविष्य की रिलीज़ में कुछ सामान्य मामलों के लिए समर्थन जोड़ा जा सकता है।

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

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

• समानांतर मोड का उपयोग करते समय क्या सभी ऑपरेशन समानांतर होते हैं?

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

• मुझे संगामिति से क्या त्वरण मिलेगा?

यदि आप इन युक्तियों का पालन करते हैं, तो, आमतौर पर, समझ बनाने के लिए पर्याप्त है। प्रिडिक्टिबिलिटी आधुनिक हार्डवेयर और सिस्टम का एक मजबूत बिंदु नहीं है, और इसलिए कोई सार्वभौमिक उत्तर नहीं है। कैश इलाके, जीसी विशेषताओं, जेआईटी संकलन, मेमोरी एक्सेस टकराव, डेटा स्थान, ओएस समयबद्धन नीतियां और हाइपरविजर की उपस्थिति कुछ ऐसे कारक हैं जिनका महत्वपूर्ण प्रभाव पड़ता है। अनुक्रमिक मोड का प्रदर्शन भी उनके प्रभाव के अधीन है, जो, समानता का उपयोग करते समय, अक्सर प्रवर्धित किया जाता है: अनुक्रमिक निष्पादन के मामले में 10 प्रतिशत अंतर के कारण होने वाली समस्या समानांतर प्रसंस्करण में 10 गुना अंतर पैदा कर सकती है।

स्ट्रीम फ्रेमवर्क में कुछ विशेषताएं शामिल हैं जो त्वरण की संभावना को बढ़ाने में मदद करती हैं। उदाहरण के लिए, आदिम के लिए विशेषज्ञता का उपयोग करना, जैसे IntStream , आमतौर पर अनुक्रमिक मोड की तुलना में समानांतर मोड के लिए अधिक प्रभाव पड़ता है। कारण यह है कि इस मामले में, न केवल संसाधनों (और मेमोरी) की खपत कम हो जाती है, बल्कि कैश स्थानीयता में भी सुधार होता है। collect ऑपरेशन के समानांतर संचालन के मामले में, HashMap बजाय ConcurrentHashMap का उपयोग करना, आंतरिक लागत को कम करता है। अनुभव के साथ नए टिप्स और ट्रिक सामने आएंगे।

• यह सब बहुत डरावना है! क्या हम सिर्फ जेवीएम संपत्तियों का उपयोग करने के लिए नियमों के साथ नहीं आ सकते हैं?

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