यदि पिछले लेख के बीज होने की संभावना अधिक थी, तो अब जूलिया की उसके मशीन पर समानांतर क्षमताओं का परीक्षण करने का समय है।

मल्टी-कोर या वितरित प्रसंस्करण

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

जूलिया का संदेश कार्यान्वयन अन्य वातावरणों से अलग है, जैसे कि MPI [1] । जूलिया में संचार आमतौर पर "वन-वे" होता है, जिसका अर्थ है कि प्रोग्रामर को दो-प्रक्रिया ऑपरेशन में केवल एक प्रक्रिया को स्पष्ट रूप से नियंत्रित करने की आवश्यकता है। इसके अलावा, ये ऑपरेशन आमतौर पर "एक संदेश भेजने" और "एक संदेश प्राप्त करने" की तरह नहीं लगते हैं, बल्कि उच्च स्तर के संचालन से मिलते-जुलते हैं, जैसे उपयोगकर्ता-परिभाषित कार्यों के लिए कॉल।

जूलिया में वितरित प्रोग्रामिंग दो प्राइमरी पर बनाई गई है: दूरस्थ लिंक और दूरस्थ कॉल । रिमोट लिंक एक ऐसी वस्तु है जिसका उपयोग किसी भी प्रक्रिया से किसी विशेष प्रक्रिया में संग्रहित वस्तु को संदर्भित करने के लिए किया जा सकता है। रिमोट कॉल एक प्रक्रिया का एक अनुरोध है जो किसी निश्चित फ़ंक्शन को दूसरे के कुछ तर्कों के अनुसार कॉल करने के लिए (संभवतः समान) प्रक्रिया है।

दूरस्थ लिंक दो रूपों में आते हैं: भविष्य और RemoteChannel ।

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

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

चलिए नीचे उतरते हैं। julia -pn पोस्टस्क्रिप्ट के साथ julia -pn किया गया स्थानीय कंप्यूटर पर एन वर्कफ़्लोज़ प्रदान करता है। यह आमतौर पर समझ में आता है कि n मशीन पर सीपीयू थ्रेड्स (तार्किक कोर) की संख्या के बराबर है। ध्यान दें कि -p तर्क अंतर्निहित वितरण मॉड्यूल को लोड करता है।

 julia> pwd() #     "C:\\Users\\User\\AppData\\Local\\Julia-1.1.0" julia> cd("C:/Users/User/Desktop") #   julia> run(`calc`) #     #     Windows. #      Process(`calc`, ProcessExited(0)) 

 using Distributed addprocs(2) 

 $ ./julia -p 2 julia> r = remotecall(rand, 2, 2, 2) Future(2, 1, 4, nothing) julia> s = @spawnat 2 1 .+ fetch(r) Future(2, 1, 5, nothing) julia> fetch(s) 2×2 Array{Float64,2}: 1.18526 1.50912 1.16296 1.60607 

रीमोटेकॉल का पहला तर्क कहा जाता है।
जूलिया के अधिकांश समवर्ती कार्यक्रम विशिष्ट प्रक्रियाओं या उपलब्ध प्रक्रियाओं की संख्या का उल्लेख नहीं करते हैं, लेकिन एक दूरस्थ कॉल को निम्न-स्तरीय इंटरफ़ेस माना जाता है जो अधिक सटीक नियंत्रण प्रदान करता है।

remotecall का दूसरा तर्क उस प्रक्रिया की पहचानकर्ता है जो काम करेगा, और शेष तर्कों को फ़ंक्शन को पारित किया जाएगा। जैसा कि आप देख सकते हैं, पहली पंक्ति में हमने प्रक्रिया 2 को यादृच्छिक 2 द्वारा 2 मैट्रिक्स बनाने के लिए कहा, और दूसरी पंक्ति में हमने इसमें 1 जोड़ने के लिए कहा। दोनों गणनाओं का परिणाम दो वायदा, आर और एस में उपलब्ध है। स्पॉनट मैक्रो पहले तर्क में निर्दिष्ट प्रक्रिया के दूसरे तर्क में अभिव्यक्ति का मूल्यांकन करता है। कभी-कभी आपको दूरस्थ रूप से गणना किए गए मान की आवश्यकता हो सकती है। यह आमतौर पर तब होता है जब आप अगले स्थानीय ऑपरेशन के लिए आवश्यक डेटा प्राप्त करने के लिए किसी दूरस्थ वस्तु से पढ़ते हैं। इसके लिए एक remotecall_fetch फ़ंक्शन है। यह fetch (remotecall (...)) लिए बराबर है fetch (remotecall (...)) , लेकिन अधिक कुशल।

याद रखें कि getindex(r, 1,1) r[1,1] बराबर है, इसलिए यह कॉल भविष्य के r के पहले तत्व को पुनः प्राप्त करता है।

रिमोट कॉल remotecall विशेष रूप से सुविधाजनक नहीं है। @spawn मैक्रो @spawn आसान बनाता है। यह एक अभिव्यक्ति के साथ काम करता है, एक फ़ंक्शन के साथ नहीं, और चुनता है कि आपके लिए ऑपरेशन कहां करना है:

 julia> r = @spawn rand(2,2) Future(2, 1, 4, nothing) julia> s = @spawn 1 .+ fetch(r) Future(3, 1, 5, nothing) julia> fetch(s) 2×2 Array{Float64,2}: 1.38854 1.9098 1.20939 1.57158 

ध्यान दें कि हमने 1 .+ Fetch(r) बजाय 1 .+ Fetch(r) उपयोग किया है 1 .+ r ऐसा इसलिए है क्योंकि हमें पता नहीं है कि कोड को कहाँ निष्पादित किया जाएगा, इसलिए सामान्य स्थिति में r जोड़ने के लिए अतिरिक्त प्रक्रिया में लाने के लिए आवश्यक हो सकता है। इस मामले में, @spawn प्रक्रिया के लिए गणना करने के लिए पर्याप्त स्मार्ट है, जो कि r का मालिक है, इसलिए गैर-परिचालन होगा (कोई काम नहीं किया जाता है)। (यह ध्यान देने योग्य है कि स्पॉन बिल्ट-इन नहीं है, लेकिन जूलिया में एक मैक्रो के रूप में परिभाषित किया गया है। आप इस तरह के निर्माण को परिभाषित कर सकते हैं।)

यह याद रखना महत्वपूर्ण है कि निष्कर्षण के बाद, Future स्थानीय रूप से इसके मूल्य को कैश करेगा। आगे कॉल करने पर नेटवर्क लीप नहीं होता है। सभी रेफरिंग फ्यूचर्स का चयन होने के बाद, हटाए गए संग्रहीत मूल्य को हटा दिया जाता है।

@async @spawn के समान है, लेकिन स्थानीय प्रक्रिया में ही कार्य चलाता है। हम प्रत्येक प्रक्रिया के लिए "फ़ीड" कार्य बनाने के लिए इसका उपयोग करते हैं। प्रत्येक कार्य अगले इंडेक्स का चयन करता है, जिसकी गणना की जानी चाहिए, फिर प्रक्रिया पूरी होने तक प्रतीक्षा करता है और तब तक दोहराता है जब तक हम इंडेक्स से बाहर नहीं निकल जाते।

कृपया ध्यान दें कि फीडर कार्यों को तब तक निष्पादित नहीं किया जाता है जब तक कि मुख्य कार्य @sync ब्लॉक के अंत तक नहीं पहुंच जाता है, जिसके बाद यह नियंत्रण से गुजरता है और फ़ंक्शन से लौटने से पहले सभी स्थानीय कार्यों के पूरा होने का इंतजार करता है।

V0.7 और उच्चतर के लिए, फीडर कार्यों को अगलाडैक्स के माध्यम से साझा कर सकते हैं, क्योंकि उन सभी को एक ही प्रक्रिया में निष्पादित किया जाता है। यहां तक ​​कि अगर कार्यों को एक साथ नियोजित किया जाता है, तो कुछ संदर्भों में अवरोध की आवश्यकता हो सकती है, जैसे कि एसिंक्रोनस I / O के साथ। इसका मतलब यह है कि संदर्भ स्विचिंग केवल अच्छी तरह से परिभाषित बिंदुओं पर होती है: इस मामले में, जब remotecall_fetch । यह कार्यान्वयन की वर्तमान स्थिति है, और यह जूलिया के भविष्य के संस्करणों में बदल सकता है, क्योंकि यह एम प्रक्रियाओं, या एम: एन थ्रेडिंग में एन कार्यों को पूरा करने में सक्षम होने के लिए डिज़ाइन किया गया है। तब हमें nextidx लिए ताले प्राप्त करने / जारी करने के लिए एक मॉडल की आवश्यकता nextidx , क्योंकि यह एक ही समय में संसाधनों को पढ़ने और लिखने के लिए कई प्रक्रियाओं की अनुमति देने के लिए असुरक्षित है।

आपका कोड किसी भी प्रक्रिया के लिए उपलब्ध होना चाहिए जो इसे चलाता है। उदाहरण के लिए, जूलिया प्रॉम्प्ट पर, निम्न टाइप करें:

 julia> function rand2(dims...) return 2*rand(dims...) end julia> rand2(2,2) 2×2 Array{Float64,2}: 0.153756 0.368514 1.15119 0.918912 julia> fetch(@spawn rand2(2,2)) ERROR: RemoteException(2, CapturedException(UndefVarError(Symbol("#rand2")) Stacktrace: [...] 

प्रक्रिया 1 फ़ंक्शन rand2 के बारे में जानती थी, लेकिन प्रक्रिया 2 नहीं थी। सबसे अधिक बार, आप फ़ाइलों या पैकेजों से कोड डाउनलोड करेंगे, और आपके पास कोड को लोड करने वाली प्रक्रियाओं को नियंत्रित करने में महत्वपूर्ण लचीलापन होगा। निम्न कोड वाले DummyModule.jl फ़ाइल पर विचार करें:

 module DummyModule export MyType, f mutable struct MyType a::Int end f(x) = x^2+1 println("loaded") end 

सभी प्रक्रियाओं में MyType को संदर्भित करने के लिए, DummyModule.jl को प्रत्येक प्रक्रिया में लोड किया जाना चाहिए। include ('DummyModule.jl') करने के लिए एक कॉल include ('DummyModule.jl') इसे केवल एक प्रक्रिया के लिए लोड करता है। इसे प्रत्येक प्रक्रिया में लोड करने के लिए, @everywhere मैक्रो (जूलिया -p 2 के साथ जूलिया चलाएँ) का उपयोग करें

 julia> @everywhere include("DummyModule.jl") loaded From worker 3: loaded From worker 2: loaded 

हमेशा की तरह, यह DummyModule को किसी भी प्रक्रिया के लिए सुलभ नहीं बनाता है जिसके लिए उपयोग या आयात की आवश्यकता होती है। इसके अलावा, जब एक प्रक्रिया में किसी डमीमॉड्यूल को शामिल किया जाता है, तो इसे किसी अन्य में शामिल नहीं किया जाता है:

 julia> using .DummyModule julia> MyType(7) MyType(7) julia> fetch(@spawnat 2 MyType(7)) ERROR: On worker 2: UndefVarError: MyType not defined ⋮ julia> fetch(@spawnat 2 DummyModule.MyType(7)) MyType(7) 

हालाँकि, यह अभी भी संभव है, उदाहरण के लिए, MyType को उस प्रक्रिया में भेजने के लिए जिसने DummyModule को लोड किया है, भले ही वह दायरे में न हो:

 julia> put!(RemoteChannel(2), MyType(7)) RemoteChannel{Channel{Any}}(2, 1, 13) 

फ़ाइल को -L ध्वज के साथ स्टार्टअप पर कई प्रक्रियाओं में पहले से लोड किया जा सकता है, और गणना को नियंत्रित करने के लिए ड्राइवर स्क्रिप्ट का उपयोग किया जा सकता है:

 julia -p <n> -L file1.jl -L file2.jl driver.jl 

उपरोक्त उदाहरण में ड्राइवर स्क्रिप्ट को चलाने वाली जूलिया प्रक्रिया में 1 की पहचानकर्ता है, ठीक उसी तरह जैसे कि यह प्रक्रिया इंटरएक्टिव प्रॉम्प्ट प्रदान करती है। अंत में, यदि DummyModule.jl एक अलग फ़ाइल नहीं है, लेकिन एक पैकेज है, तो DummyModule का उपयोग करके सभी प्रक्रियाओं में DummyModule.jl को लोड किया जाएगा, लेकिन इसे केवल उस प्रक्रिया के दायरे में स्थानांतरित करें जिसके लिए उपयोग कहा जाता था।

वर्कफ़्लो का शुभारंभ और प्रबंधन

मूल जूलिया इंस्टॉलेशन में दो प्रकार के क्लस्टर के लिए अंतर्निहित समर्थन है:

• स्थानीय क्लस्टर -p विकल्प के साथ निर्दिष्ट है, जैसा कि ऊपर दिखाया गया है।
• क्लस्टर मशीन - themachine-file विकल्प का उपयोग कर। यह निर्दिष्ट मशीनों पर जूलिया वर्कफ़्लोज़ (वर्तमान होस्ट के समान पथ के साथ) शुरू करने के लिए पासवर्ड के बिना ssh लॉगिन का उपयोग करता है।

किसी कार्य को किसी क्लस्टर में जोड़ने, हटाने और क्वेरी करने के लिए सॉफ़्टवेयर उपकरण के रूप में addprocs , rmprocs , कार्यकर्ता और अन्य उपलब्ध हैं।

 julia> using Distributed julia> addprocs(2) 2-element Array{Int64,1}: 2 3 

addprocs कॉल करने से पहले Distributed मॉड्यूल को मुख्य प्रक्रिया में स्पष्ट रूप से लोड किया जाना चाहिए। यह स्वचालित रूप से वर्कफ़्लो के लिए उपलब्ध हो जाता है। ध्यान दें कि कार्यकर्ता स्टार्टअप स्क्रिप्ट ~/.julia/config/startup.jl स्टार्टअप. ~/.julia/config/startup.jl नहीं चलाते हैं और न ही वे किसी भी अन्य चल रही प्रक्रियाओं के साथ अपने वैश्विक राज्य (जैसे वैश्विक चर, नई विधियों की परिभाषा, और लोड किए गए मॉड्यूल) को सिंक्रनाइज़ नहीं करते हैं। अन्य प्रकार के समूहों को अपने स्वयं के ClusterManager को लिखकर समर्थित किया जा सकता है, जैसा कि क्लस्टरस्टरमैन अनुभाग में नीचे वर्णित है।

डेटा क्रियाएँ

संदेश भेजने और डेटा को वितरित प्रोग्राम में ओवरहेड का अधिकांश हिस्सा बनाते हैं। संदेशों की संख्या और भेजे गए डेटा की मात्रा को कम करना प्रदर्शन और मापनीयता को प्राप्त करने के लिए महत्वपूर्ण है। इसके लिए, जूलिया के विभिन्न वितरित प्रोग्रामिंग निर्माणों द्वारा किए गए डेटा आंदोलन को समझना महत्वपूर्ण है।

fetch को एक स्पष्ट डेटा आंदोलन ऑपरेशन के रूप में माना जा सकता है, क्योंकि यह सीधे स्थानीय मशीन पर किसी वस्तु की आवाजाही का अनुरोध करता है। @spawn (और कई संबंधित निर्माण) भी डेटा को स्थानांतरित करता है, लेकिन यह इतना स्पष्ट नहीं है, इसलिए इसे एक अंतर्निहित डेटा आंदोलन ऑपरेशन कहा जा सकता है। यादृच्छिक मैट्रिक्स के निर्माण और स्क्वैरिंग करने के लिए इन दो दृष्टिकोणों पर विचार करें:

रास्ता समय:

 julia> A = rand(1000,1000); julia> Bref = @spawn A^2; [...] julia> fetch(Bref); 

विधि दो:

 julia> Bref = @spawn rand(1000,1000)^2; [...] julia> fetch(Bref); 

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

उदाहरण के लिए, यदि पहली प्रक्रिया को मैट्रिक्स ए की आवश्यकता है, तो पहली विधि बेहतर हो सकती है। या, यदि कंप्यूटिंग A महंगा है और केवल वर्तमान प्रक्रिया का उपयोग करता है, तो इसे दूसरी प्रक्रिया में ले जाना अपरिहार्य हो सकता है। या, यदि वर्तमान प्रक्रिया में spawn और fetch(Bref) बीच बहुत कम समानता है, तो fetch(Bref) से पूरी तरह से समाप्त करना बेहतर हो सकता है। या कल्पना करें कि rand(1000, 1000) एक अधिक महंगा ऑपरेशन द्वारा बदल दिया गया है। तो फिर इस कदम के लिए एक और spawn स्टेटमेंट जोड़ना समझदारी हो सकती है।

वैश्विक चर

remotecall माध्यम से दूरस्थ रूप से निष्पादित की गई अभिव्यक्तियाँ, या remotecall का उपयोग करके दूरस्थ निष्पादन के लिए निर्दिष्ट क्लोजर, वैश्विक चर का उल्लेख कर सकते हैं। Main मॉड्यूल में वैश्विक बाइंडिंग को अन्य मॉड्यूल में वैश्विक बाइंडिंग की तुलना में थोड़ा अलग तरीके से नियंत्रित किया जाता है। निम्नलिखित कोड स्निपेट पर विचार करें:

 A = rand(10,10) remotecall_fetch(()->sum(A), 2) 

इस स्थिति में, दूरस्थ प्रक्रिया में sum को परिभाषित किया जाना चाहिए। ध्यान दें कि A स्थानीय कार्यक्षेत्र में परिभाषित एक वैश्विक चर है। वर्कर 2 में Main खंड में A नाम का एक चर नहीं है। कार्यकर्ता 2 के लिए क्लोजर फ़ंक्शन () -> sum(A) को Main.A कारण बनता है। 2 Main.A परिभाषित किया जाता है। remotecall_fetch कॉल remotecall_fetch बाद भी remotecall_fetch 2 कार्यकर्ता 2 पर मौजूद रहता है।

एम्बेडेड वैश्विक संदर्भों के साथ रिमोट कॉल (केवल मुख्य मॉड्यूल में) वैश्विक चर का प्रबंधन निम्नानुसार करता है:

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

 A = rand(10,10) remotecall_fetch(()->sum(A), 2) # worker 2 A = rand(10,10) remotecall_fetch(()->sum(A), 3) # worker 3 A = nothing 

उपरोक्त खंड के निष्पादन से तथ्य यह होता है कि कर्मचारी 2 पर Main.A कर्मचारी 3 पर Main.A से भिन्न मूल्य है, जबकि नोड 1 पर Main.A का मूल्य शून्य है।

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

 julia> A = rand(10,10); julia> remotecall_fetch(()->A, 2); julia> B = rand(10,10); julia> let B = B remotecall_fetch(()->B, 2) end; julia> @fetchfrom 2 InteractiveUtils.varinfo() name size summary ––––––––– ––––––––– –––––––––––––––––––––– A 800 bytes 10×10 Array{Float64,2} Base Module Core Module Main Module 

यह देखना आसान है कि वैश्विक चर A कार्यकर्ता 2 पर परिभाषित किया गया है, लेकिन B स्थानीय चर के रूप B लिखा गया है, और इसलिए B लिए बंधन कार्यकर्ता 2 पर मौजूद नहीं है।

समानांतर छोरों

सौभाग्य से, कई उपयोगी संगामियों की गणना के लिए डेटा आंदोलन की आवश्यकता नहीं होती है। एक विशिष्ट उदाहरण एक मोंटे कार्लो सिमुलेशन है, जहां कई प्रक्रियाएं एक साथ स्वतंत्र सिमुलेशन परीक्षणों की प्रक्रिया कर सकती हैं। हम सिक्कों को दो प्रक्रियाओं में फ्लिप करने के लिए @spawn का उपयोग कर सकते हैं। पहले count_heads.jl में निम्न फ़ंक्शन count_heads.jl :

 function count_heads(n) c::Int = 0 for i = 1:n c += rand(Bool) end c end 

Count_heads फ़ंक्शन केवल n यादृच्छिक बिट्स को जोड़ता है। यहाँ हम दो मशीनों पर कुछ परीक्षण कर सकते हैं और परिणाम जोड़ सकते हैं:

 julia> @everywhere include_string(Main, $(read("count_heads.jl", String)), "count_heads.jl") julia> a = @spawn count_heads(100000000) Future(2, 1, 6, nothing) julia> b = @spawn count_heads(100000000) Future(3, 1, 7, nothing) julia> fetch(a)+fetch(b) 100001564 

यह उदाहरण एक शक्तिशाली और अक्सर उपयोग किए जाने वाले समानांतर प्रोग्रामिंग पैटर्न को प्रदर्शित करता है। कई पुनरावृत्तियों को कई प्रक्रियाओं में स्वतंत्र रूप से किया जाता है, और फिर उनके परिणामों को कुछ फ़ंक्शन का उपयोग करके संयुक्त किया जाता है। संघ की प्रक्रिया को कमी कहा जाता है, क्योंकि यह आमतौर पर टेंसर रैंक को कम करता है: संख्याओं का वेक्टर एक संख्या तक कम हो जाता है, या मैट्रिक्स एक पंक्ति या स्तंभ, आदि तक कम हो जाता है। कोड में, यह आमतौर पर इस तरह दिखता है: पैटर्न x = f(x, v [i]) , जहां x बैटरी है, f कमी कार्य है, और v[i] कम होने वाले तत्व हैं।

यह वांछनीय है कि f साहचर्य हो ताकि यह मायने नहीं रखता कि किस क्रम में संचालन किया जाता है। कृपया ध्यान दें कि count_heads साथ इस टेम्पलेट के हमारे उपयोग को सामान्यीकृत किया जा सकता है। हमने दो स्पष्ट spawn स्टेटमेंट्स का उपयोग किया, जो दो प्रक्रियाओं के लिए संगामिति को सीमित करता है। किसी भी संख्या में प्रक्रियाओं पर चलने के लिए, हम वितरित मेमोरी में लूप संचालन के for एक समानांतर का उपयोग कर सकते हैं, जिसे जूलिया को वितरित का उपयोग करके लिखा जा सकता है, उदाहरण के लिए:

 nheads = @distributed (+) for i = 1:200000000 Int(rand(Bool)) end 

( (+) ). . .

, for , . , , , . , , . , :

 a = zeros(100000) @distributed for i = 1:100000 a[i] = i end 

, . , . , Shared Arrays , , :

 using SharedArrays a = SharedArray{Float64}(10) @distributed for i = 1:10 a[i] = i end 

«» , :

 a = randn(1000) @distributed (+) for i = 1:100000 f(a[rand(1:end)]) end 

f , . , , . , Future , . Future , fetch , , @sync , @sync distributed for .

, (, , ). , , Julia pmap . , :

 julia> M = Matrix{Float64}[rand(1000,1000) for i = 1:10]; julia> pmap(svdvals, M); 

pmap , . , distributed for , , , . pmap , distributed . distributed for .

(Shared Arrays)

Shared Arrays . DArray , SharedArray . DArray , ; , SharedArray .

SharedArray — , , . Shared Array SharedArrays , . SharedArray ( ) , , . SharedArray , . , Array , SharedArray , sdata . AbstractArray sdata , sdata Array . :

 SharedArray{T,N}(dims::NTuple; init=false, pids=Int[]) 

N - T dims , pids . , , pids ( , ).

init initfn(S :: SharedArray) , . , init , .

:

 julia> using Distributed julia> addprocs(3) 3-element Array{Int64,1}: 2 3 4 julia> @everywhere using SharedArrays julia> S = SharedArray{Int,2}((3,4), init = S -> S[localindices(S)] = myid()) 3×4 SharedArray{Int64,2}: 2 2 3 4 2 3 3 4 2 3 4 4 julia> S[3,2] = 7 7 julia> S 3×4 SharedArray{Int64,2}: 2 2 3 4 2 3 3 4 2 7 4 4 

SharedArrays.localindices . , , :

 julia> S = SharedArray{Int,2}((3,4), init = S -> S[indexpids(S):length(procs(S)):length(S)] = myid()) 3×4 SharedArray{Int64,2}: 2 2 2 2 3 3 3 3 4 4 4 4 

, , . उदाहरण के लिए:

 @sync begin for p in procs(S) @async begin remotecall_wait(fill!, p, S, p) end end end 

. pid , , ( S ), pid .

«»:

 q[i,j,t+1] = q[i,j,t] + u[i,j,t] 

, , , , , : q [i,j,t] , q[i,j,t+1] , , , q[i,j,t] , q[i,j,t+1] . . . , (irange, jrange) , :

 julia> @everywhere function myrange(q::SharedArray) idx = indexpids(q) if idx == 0 # This worker is not assigned a piece return 1:0, 1:0 end nchunks = length(procs(q)) splits = [round(Int, s) for s in range(0, stop=size(q,2), length=nchunks+1)] 1:size(q,1), splits[idx]+1:splits[idx+1] end 

:

 julia> @everywhere function advection_chunk!(q, u, irange, jrange, trange) @show (irange, jrange, trange) # display so we can see what's happening for t in trange, j in jrange, i in irange q[i,j,t+1] = q[i,j,t] + u[i,j,t] end q end 

SharedArray

 julia> @everywhere advection_shared_chunk!(q, u) = advection_chunk!(q, u, myrange(q)..., 1:size(q,3)-1) 

, :

 julia> advection_serial!(q, u) = advection_chunk!(q, u, 1:size(q,1), 1:size(q,2), 1:size(q,3)-1); 

@distributed :

 julia> function advection_parallel!(q, u) for t = 1:size(q,3)-1 @sync @distributed for j = 1:size(q,2) for i = 1:size(q,1) q[i,j,t+1]= q[i,j,t] + u[i,j,t] end end end q end; 

, :

 julia> function advection_shared!(q, u) @sync begin for p in procs(q) @async remotecall_wait(advection_shared_chunk!, p, q, u) end end q end; 

SharedArray , ( julia -p 4 ):

 julia> q = SharedArray{Float64,3}((500,500,500)); julia> u = SharedArray{Float64,3}((500,500,500)); 

JIT- @time :

 julia> @time advection_serial!(q, u); (irange,jrange,trange) = (1:500,1:500,1:499) 830.220 milliseconds (216 allocations: 13820 bytes) julia> @time advection_parallel!(q, u); 2.495 seconds (3999 k allocations: 289 MB, 2.09% gc time) julia> @time advection_shared!(q,u); From worker 2: (irange,jrange,trange) = (1:500,1:125,1:499) From worker 4: (irange,jrange,trange) = (1:500,251:375,1:499) From worker 3: (irange,jrange,trange) = (1:500,126:250,1:499) From worker 5: (irange,jrange,trange) = (1:500,376:500,1:499) 238.119 milliseconds (2264 allocations: 169 KB) 

advection_shared! , , .

, . , , .
, , , .

- Julia

, , , .

$$$\pi = 3.14159265...$, , -. $$$\ pi$, $$$S = \pi r^2$जहाँ $$$r$— . - $$$\ pi$, .. $$$[−1,1]^2$$$$x-y$, .

( $$$S=\pi$, $$$r = 1$) ( $$$A = 4$) $$$\pi/4$, , , . , $$$\ pi$, . compute_pi (N) , $$$\ pi$, $$$N$.

 function compute_pi(N::Int) # counts number of points that have radial coordinate < 1, ie in circle n_landed_in_circle = 0 for i = 1:N x = rand() * 2 - 1 # uniformly distributed number on x-axis y = rand() * 2 - 1 # uniformly distributed number on y-axis r2 = x*x + y*y # radius squared, in radial coordinates if r2 < 1.0 n_landed_in_circle += 1 end end return n_landed_in_circle / N * 4.0 end 

, , $$$\ pi$। : , , 25 .

Julia Pi.jl ( Sublime Text , ):

 C:\Users\User\AppData\Local\Julia-1.1.0\bin\julia -p 4 julia> include("C:/Users/User/Desktop/Pi.jl") 

 using Distributed addprocs(4) 

Jupyter

 @everywhere function compute_pi(N::Int) n_landed_in_circle = 0 # counts number of points that have radial coordinate < 1, ie in circle for i = 1:N x = rand() * 2 - 1 # uniformly distributed number on x-axis y = rand() * 2 - 1 # uniformly distributed number on y-axis r2 = x*x + y*y # radius squared, in radial coordinates if r2 < 1.0 n_landed_in_circle += 1 end end return n_landed_in_circle / N * 4.0 end function parallel_pi_computation(N::Int; ncores::Int=4) #       sum_of_pis = @distributed (+) for i=1:ncores compute_pi(ceil(Int, N / ncores)) end return sum_of_pis / ncores # average value end # ceil (T, x)     #  T,     x. 

, :

 julia> @time parallel_pi_computation(1000000000, ncores = 1) 6.818123 seconds (1.96 M allocations: 99.838 MiB, 0.42% gc time) 3.141562892 julia> @time parallel_pi_computation(1000000000, ncores = 1) 5.081638 seconds (1.12 k allocations: 62.953 KiB) 3.141657252 julia> @time parallel_pi_computation(1000000000, ncores = 2) 3.504871 seconds (1.84 k allocations: 109.382 KiB) 3.1415942599999997 julia> @time parallel_pi_computation(1000000000, ncores = 4) 3.093918 seconds (1.12 k allocations: 71.938 KiB) 3.1416889400000003 julia> pi ? = 3.1415926535897... 

JIT - — . , Julia . , ( Multi-Threading, Atomic Operations, Channels Coroutines).

, , . MPI.jl MPI ,
DistributedArrays.jl .
GPU, :

1. ( C) OpenCL.jl CUDAdrv.jl OpenCL CUDA.
2. ( Julia) CUDAnative.jl CUDA .
3. , , CuArrays.jl CLArrays.jl
4. , ArrayFire.jl GPUArrays.jl
5. -
7. Kynseed

, , . !