गो: मल्टीथ्रेडिंग एंड पैरेलिज्म

आई लव गो, आई लव यू स्तुति इट (यह भी होता है, मैं एक गालिया बकता हूं), मुझे इसके बारे में लेख बहुत पसंद हैं। मैंने लेख " गो: प्रोडक्शन में दो साल " पढ़ा, फिर टिप्पणी की। यह हब पर स्पष्ट हो गया - आशावादी! वे सर्वश्रेष्ठ में विश्वास करना चाहते हैं।

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

channel01.go

package main import "fmt" import "time" import "runtime" func main() { numcpu := runtime.NumCPU() fmt.Println("NumCPU", numcpu) //runtime.GOMAXPROCS(numcpu) runtime.GOMAXPROCS(1) ch1 := make(chan int) ch2 := make(chan float64) go func() { for i := 0; i < 1000000; i++ { ch1 <- i } ch1 <- -1 ch2 <- 0.0 }() go func() { total := 0.0 for { t1 := time.Now().UnixNano() for i := 0; i < 100000; i++ { m := <-ch1 if m == -1 { ch2 <- total } } t2 := time.Now().UnixNano() dt := float64(t2 - t1) / 1000000.0 total += dt fmt.Println(dt) } }() fmt.Println("Total:", <-ch2, <-ch2) } 

 users-iMac:channel user$ go run channel01.go NumCPU 4 23.901 24.189 23.957 24.072 24.001 23.807 24.039 23.854 23.798 24.1 Total: 239.718 0 

अब लाइनों को टिप्पणी करके सभी गुठली को सक्रिय करते हैं।

  runtime.GOMAXPROCS(numcpu) //runtime.GOMAXPROCS(1) 

 users-iMac:channel user$ go run channel01.go NumCPU 4 543.092 534.985 535.799 533.039 538.806 533.315 536.501 533.261 537.73 532.585 Total: 5359.113 0 

20 गुना धीमी? कैच क्या है? डिफ़ॉल्ट चैनल का आकार 1 है।

  ch1 := make(chan int) 

100 रखो।

  ch1 := make(chan int, 100) 

परिणाम 1 स्ट्रीम

 users-iMac:channel user$ go run channel01.go NumCPU 4 9.704 9.618 9.178 9.84 9.869 9.461 9.802 9.743 9.877 9.756 Total: 0 96.848 

4 स्ट्रीम परिणाम

 users-iMac:channel user$ go run channel01.go NumCPU 4 17.046 17.046 16.71 16.315 16.542 16.643 17.69 16.387 17.162 15.232 Total: 0 166.77300000000002 

केवल दो बार धीमा, लेकिन इसका उपयोग करना हमेशा संभव नहीं होता है।

चैनल चैनल उदाहरण

 package main import "fmt" import "time" import "runtime" func main() { numcpu := runtime.NumCPU() fmt.Println("NumCPU", numcpu) //runtime.GOMAXPROCS(numcpu) runtime.GOMAXPROCS(1) ch1 := make(chan chan int, 100) ch2 := make(chan float64, 1) go func() { t1 := time.Now().UnixNano() for i := 0; i < 1000000; i++ { ch := make(chan int, 100) ch1 <- ch <- ch } t2 := time.Now().UnixNano() dt := float64(t2 - t1) / 1000000.0 fmt.Println(dt) ch2 <- 0.0 }() go func() { for i := 0; i < 1000000; i++ { ch := <-ch1 ch <- i } ch2 <- 0.0 }() <-ch2 <-ch2 } 

परिणाम 1 स्ट्रीम

 users-iMac:channel user$ go run channel03.go NumCPU 4 1041.489 

4 स्ट्रीम परिणाम

 users-iMac:channel user$ go run channel03.go NumCPU 4 11170.616 

इसलिए, यदि आपके पास 8 कोर हैं और आप गो पर सर्वर लिखते हैं, तो आपको केवल कार्यक्रम को समानांतर करने में गो पर निर्भर नहीं होना चाहिए, या शायद 8 एकल-थ्रेडेड प्रक्रियाएं शुरू करें, और उनसे पहले एक बैलेंसर है जिसे गो पर भी लिखा जा सकता है। हमारे पास उत्पादन में एक सर्वर था, जो एकल-कोर सर्वर से 4x पर स्विच करते समय, 10% कम अनुरोधों को संसाधित करने लगा।

इन नंबरों का क्या मतलब है? हमें एक संदर्भ में प्रति सेकंड 3000 अनुरोधों को संसाधित करने के कार्य के साथ सामना करना पड़ा (उदाहरण के लिए, प्रत्येक अनुरोध को क्रमिक रूप से संख्या देते हुए: 1, 2, 3, 4, 5 ... शायद थोड़ा अधिक जटिल) और प्रति सेकंड 3000 अनुरोधों का प्रदर्शन मुख्य रूप से चैनलों द्वारा सीमित है। धागे और कोर के अलावा के साथ, प्रदर्शन उत्साह के रूप में वांछित रूप से नहीं बढ़ता है। गो के लिए प्रति सेकंड 3000 अनुरोध आधुनिक उपकरणों पर एक निश्चित सीमा है।

रात का अपडेट: मैं कैसे ऑप्टिमाइज़ कर सकता हूं

लेख " गो: टू इयर्स इन प्रोडक्शन " की टिप्पणियों ने मुझे इस लेख को लिखने के लिए प्रेरित किया, लेकिन इस टिप्पणी ने पहले की टिप्पणियों को पार कर लिया।

साइबरग्रीग रक्षक ने निम्नलिखित अनुकूलन का प्रस्ताव रखा। पहले से ही 8 अन्य habrazhitelami द्वारा पसंद किया गया। मुझे नहीं पता कि वे कोड पढ़ते हैं या शायद वे गोताखोर हैं और वे सब कुछ सहज रूप से करते हैं, लेकिन मैं समझाऊंगा। तो लेख अधिक संपूर्ण और जानकारीपूर्ण हो जाएगा।
यहाँ कोड है:

 package main import "fmt" import "time" import "runtime" func main() { numcpu := runtime.NumCPU() fmt.Println("NumCPU", numcpu) //runtime.GOMAXPROCS(numcpu) runtime.GOMAXPROCS(1) ch3 := make(chan int) ch1 := make(chan int, 1000000) ch2 := make(chan float64) go func() { for i := 0; i < 1000000; i++ { ch1 <- i } ch3 <- 1 ch1 <- -1 ch2 <- 0.0 }() go func() { fmt.Println("TT", <-ch3) total := 0.0 for { t1 := time.Now().UnixNano() for i := 0; i < 100000; i++ { m := <-ch1 if m == -1 { ch2 <- total } } t2 := time.Now().UnixNano() dt := float64(t2 - t1) / 1000000.0 total += dt fmt.Println(dt) } }() fmt.Println("Total:", <-ch2, <-ch2) } 

इस अनुकूलन का सार क्या है?

1. चैनल ch3 जोड़ा गया। यह चैनल दूसरे गोरूटिन को ब्लॉक करता है, जब तक कि पहला गोरुटिन खत्म नहीं हो जाता।
2. चूँकि दूसरा gorutin चैनल ch1 से नहीं पढ़ता है, यह भरने के दौरान पहले gorutin को ब्लॉक करता है। इसलिए, ch1 को आवश्यक 1,000,000 तक बढ़ाया गया है

यही है, कोड अब समानांतर नहीं है, यह क्रमिक रूप से काम करता है, और चैनल एक सरणी के रूप में उपयोग किया जाता है। और निश्चित रूप से यह कोड दूसरे कोर का उपयोग करने में सक्षम नहीं है। इस कोड के संदर्भ में, कोई "एन के एक कारक द्वारा आदर्श त्वरण" के बारे में बात नहीं कर सकता है।

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

अपडेट 2: गो 1.1.2 पर टेस्ट

बफर 1 के साथ टेस्ट नंबर एक (channel01.go)

  ch1 := make(chan chan int, 1) 

1 धागा

 go runchannel01.go NumCPU 4 66.0038 66.0038 67.0038 66.0038 67.0038 66.0038 65.0037 67.0038 67.0039 76.0043 Total: 0 673.0385000000001 

4 धागे

 go run channel01.go NumCPU 4 116.0066 186.0106 112.0064 117.0067 175.01 115.0066 114.0065 148.0084 133.0076 153.0088 Total: 0 1369.0782 

निष्कर्ष: बहुत बेहतर। क्यों बफर 1 की कल्पना करना मुश्किल है, लेकिन शायद ऐसे बफर के लिए एक आवेदन है।

बफर 100 के साथ टेस्ट नंबर एक (channel01.go)

  ch1 := make(chan chan int, 100) 

1 धागा

 go run channel01.go NumCPU 4 16.0009 17.001 16.0009 16.0009 16.0009 16.0009 17.001 16.0009 17.001 16.0009 Total: 0 163.00930000000002 

4 धागे

 go runchannel01.go NumCPU 4 66.0038 66.0038 67.0038 66.0038 67.0038 66.0038 65.0037 67.0038 67.0039 76.0043 Total: 0 673.0385000000001 

निष्कर्ष: संस्करण 1.0.2 से दो गुना बदतर

परीक्षण संख्या दो (channel03.go)

1 धागा

 go run channel03.go NumCPU 4 1568.0897 

4 धागे

 go run channel03.go NumCPU 4 12119.6932 

संस्करण 1.0.2 के लगभग समान, लेकिन थोड़ा बेहतर। 1: 8 बनाम 1:10