👩🏽‍🤝‍👩🏻 🐖 🙏 जाओ: बहुआयामी 🤸 ♣️ 📯

मुझे गो में मल्टीथ्रेडिंग के विषय में दिलचस्पी थी: habrahabr.ru/post/195574 ।
मैंने लेखक और सामुदायिक टिप्पणियों को ध्यान से पढ़ा और फैसला किया कि विषय का अभी भी पूरी तरह से खुलासा नहीं किया गया है।
भविष्य में, इसलिए इसे गलत न समझा जाए, मैं आपसे यह स्वीकार करने के लिए कहता हूं कि इसके बाद "धागा" शब्द का उपयोग विशेष रूप से "धागा" के अर्थ में किया जाता है, न कि "धारा" के अर्थ में। आपका धन्यवाद

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

कार्यक्रम का पाठ

/* channel_test01.go * Tests how go-routines interact with channels * Call: channel_test01 --help * Pls, do not use name "channel_test", because this name always is used by go-pkg-system */ package main import ( "fmt" "time" "flag" "os" "runtime" ) // flag support for program var MAXPROCS int var LOAD_CYCLES int //internal burden cycle var Usage = func() { fmt.Fprintf(os.Stderr, "Usage channel_test01 [-maxprocs=NN] [-cycles=NN] \n", os.Args[0]) } func init() { flag.IntVar(&MAXPROCS, "maxprocs", 1, "maxprocs for testing. From 1 to 256 "); flag.IntVar(&LOAD_CYCLES, "cycles", 1000, "burden internal cycle for testing. From 1 to 1000000 and more "); } func main() { flag.Parse();//get MAXPROCS and LOAD_CYCLES from flags // runtime.GOMAXPROCS() returns previous max_procs max_procs := runtime.GOMAXPROCS(MAXPROCS) // second call to get real state max_procs = runtime.GOMAXPROCS(MAXPROCS) fmt.Println("MaxProcs = ", max_procs) ch1 := make(chan int) ch2 := make(chan float64) go chan_filler(ch1, ch2) go chan_extractor(ch1, ch2) fmt.Println("Total:", <-ch2, <-ch2) } func chan_filler(ch1 chan int, ch2 chan float64) { const CHANNEL_SIZE = 1000000 for i := 0; i < CHANNEL_SIZE; i++ { for j := 0; j < LOAD_CYCLES; j++ { i++ } //thus we avoid optimizer influence i = i - LOAD_CYCLES ch1 <- i } ch1 <- -1 ch2 <- 0.0 } func chan_extractor(ch1 chan int, ch2 chan float64) { const PORTION_SIZE = 100000 total := 0.0 for { t1 := time.Now().UnixNano() for i := 0; i < PORTION_SIZE; i++ { // burden cycle for j := 0; j < LOAD_CYCLES; j++ { i++ } i = i - LOAD_CYCLES m := <-ch1 if m == -1 { ch2 <- total } } t2 := time.Now().UnixNano() dt := float64(t2 - t1)/1e9 //nanoseconds ==> seconds total += dt fmt.Println(dt) } }

परिणाम

मशीन: इंटेल, 3 गीगाहर्ट्ज पर 4 कोर, 4 जीबी रैम, लिनक्स-x86-64, कर्नेल-3.11, गोलंग-1.1.2

मेरी मशीन पर अधिकतम प्राप्त करने योग्य रनटाइम। MAXPROCS मान 256 है। आप अधिक निर्दिष्ट कर सकते हैं, लेकिन यह अभी भी 256 पर सेट किया जाएगा। डिफ़ॉल्ट मान 1 है।

कार्यक्रम द्वारा उत्पन्न थ्रेड्स की संख्या (ps -C channel_test01 -L)
एटमैक्सप्रोक्स = 1: 3 धागे।
-मैक्सप्रोक्स के साथ = 2 या अधिक: हमेशा 4 धागे।

कभी-कभी, लंबे समय तक संचालन के दौरान, 2 और प्रवाह दिखाई दिए, जो प्रक्रिया के अंत तक बने रहे। यह कचरा संग्रह की तरह दिखता है।

(मैंने इसे एक वर्चुअल सर्वर पर आज़माया, जिसमें 24 कोर / proc / cpuinfo की उपस्थिति दिखाई देती है। इस पर थ्रेड्स की संख्या भी 4 थी। लेकिन अक्सर एक पाँचवाँ धागा होता था - ऐसा लगता है कि लालची vds को मेमोरी आवंटित करने की कोई जल्दी नहीं थी। , और कूड़ा उठाने वाले को देखने के लिए बाहर निकले)।

चक्र = 1000 पर प्रवाह की संख्या पर चैनल की भरने की दर की निर्भरता

अधिकतम प्रदर्शन MAXPROCS = 1 के साथ विकसित होता है

गिट्टी लोड में वृद्धि पर चैनल भरने की दर की निर्भरता

लोड के तहत, मल्टीथ्रेडिंग अभी भी अपना टोल लेता है।

चार्ट से निष्कर्ष

मैक्सप्रोक्स = 1 के साथ, सब कुछ 1 थ्रेड में काम करता है, छद्म-मल्टीथ्रेडिंग आंतरिक गोलंग अनुसूचक द्वारा प्रदान किया जाता है, जो बहुत कुशल है।
मैक्सप्रोक्स = 2 या अधिक के साथ, अधिक प्रवाह दिखाई देते हैं, प्रवाह के बीच बातचीत का तंत्र चालू होता है। रुकावटें आती हैं, और सब कुछ धीमा हो जाता है, सोने के धागे पर - लगभग 2 बार।
मैक्सप्रोक्स = 3..256 के साथ, सिस्टम में थ्रेड्स की वास्तविक संख्या नहीं बढ़ती है, लेकिन कुछ थ्रेड्स "छद्म-धागे" बन जाते हैं, जिसके बीच का अंतर आंतरिक गोलंग अनुसूचक के नियंत्रण में आने लगता है। यह "छद्म-सूत्र" की संख्या में प्रत्येक वृद्धि के साथ गति में एक छोटी वृद्धि देता है।
मैक्सप्रोक्स (256 के अधिकतम मूल्य तक) में और वृद्धि के साथ, अधिक से अधिक धागे छद्म धागे बन जाते हैं और आंतरिक अनुसूचक के नियंत्रण में आते हैं। लेकिन कुछ धागे अभी भी स्वतंत्र प्रणाली के धागे हैं। स्लीपिंग थ्रेड्स और फास्ट कंप्यूटिंग पर, इससे हमें प्रदर्शन का लगभग 10% खर्च होता है।

निष्कर्ष।

रनटाइम बदलना। MAXPROCS पैरामीटर प्रदर्शन में लाभ और हानि दोनों ला सकता है। यह एक बार फिर सामान्य सिद्धांत की पुष्टि करता है कि समानांतरकरण का प्रभाव एक विशिष्ट कार्य और विशिष्ट उपकरणों पर निर्भर करता है।

जाओ: बहुआयामी

परिणाम

चक्र = 1000 पर प्रवाह की संख्या पर चैनल की भरने की दर की निर्भरता

गिट्टी लोड में वृद्धि पर चैनल भरने की दर की निर्भरता

चार्ट से निष्कर्ष

निष्कर्ष।

More articles: