गो में मल्टीथ्रेडेड प्रोग्रामिंग

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

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

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

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

वैकल्पिक रूप से, आप मेकफाइल बना सकते हैं और इसे GNU मेक में -j स्विच के साथ चला सकते हैं। लेकिन अगर आप एक विशेष मल्टीथ्रेडेड प्रोग्राम लिखते हैं, तो आप बेहतर प्रदर्शन प्राप्त कर सकते हैं।


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

इस प्रकार, हम एन थ्रेड को व्यस्त रखेंगे, इष्टतम प्रोसेसर उपयोग सुनिश्चित करेंगे, अनावश्यक संदर्भ स्विचिंग पर समय बर्बाद किए बिना और थ्रेड के निरंतर निर्माण और विनाश।

सबसे पहले मैंने C ++ और pthreads में सब कुछ लिखने का फैसला किया। फंक्शनलर्स, म्यूटेक्स, सेमाफोर और सशर्त चर के आसपास नृत्य के कई घंटों के बाद, वास्तव में मेरे लिए कुछ भी काम नहीं किया। और फिर मुझे गो के बारे में याद आया। इस पर विश्वास न करें - एक घंटे के काम के बाद, मेरे पास पहला संस्करण तैयार था, जिसमें टीएआर के साथ काम करने, कमांड लाइन और बाहरी प्रक्रिया शुरू करने जैसी छोटी चीजें शामिल थीं।

तो: यह प्रोग्राम TAR को सूत्रों के साथ ले जाता है, उसे अनपैक करता है, और प्रत्येक फ़ाइल संकलक के माध्यम से चलती है।

मुझे तुरंत यह कहना चाहिए कि मैं यहां जो कुछ भी लिख रहा हूं उसका लक्ष्य (और अधिक कुछ नहीं) प्रदर्शित करना है कि गो पर बहु-पिरोया अनिवार्य कार्यक्रम लिखना कितना सरल और सुविधाजनक है।

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

इसके अलावा, आप सिर्फ स्रोत को देख सकते हैं। सबसे दिलचस्प जगह वह है जहां आप देख सकते हैं कि फ़ंक्शन "संकलन ()" को बिना किसी बदलाव के कई थ्रेड्स से कैसे कहा जा सकता है।

package main import ( "archive/tar" "container/vector" "exec" "flag" "fmt" "io" "os" "strings" ) //  :     . var jobs *int = flag.Int("jobs", 0, "number of concurrent jobs") var compiler *string = flag.String("cc", "bcom", "compiler name") func main() { flag.Parse() os.Args = flag.Args() args := os.Args ar := args[0] r, err := os.Open(ar, os.O_RDONLY, 0666); if err != nil { fmt.Printf("unable to open TAR %s\n", ar) os.Exit(1) } // defer -   "finally {}",   //     . defer r.Close() //   TAR. fmt.Printf("- extracting %s\n", ar) //    . tr := tar.NewReader( r ) tests := new(vector.StringVector) //    ,     //   . for { //      . hdr, _ := tr.Next() if hdr == nil { break } name := &hdr.Name //     ,  . if !strings.HasPrefix(*name, "HDR_") { tests.Push(*name) } //   . w, err := os.Open("data/" + *name, os.O_CREAT | os.O_RDWR, 0666) if err != nil { fmt.Printf("unable to create %s\n", *name) os.Exit(1) } //     . io.Copy(w, tr) w.Close() } fmt.Printf("- compiling...\n") *compiler , _ = exec.LookPath(*compiler) fmt.Printf("- compiler %s\n", *compiler) if *jobs == 0 { //  "compile()" ,   . fmt.Printf("- running sequentially\n") for i := 0; i < tests.Len(); i++ { compile(tests.At(i)) } } else { //  "compile()"   . fmt.Printf("- running %d concurrent job(s)\n", *jobs) //  :        , //   . -runner'   //    .     // .   ,    // ,   runner' . tasks := make(chan string, *jobs) //     -runner'. //    ,   runner'  //   .     . done := make(chan bool) //  runner'. for i := 0; i < *jobs; i++ { go runner(tasks, done) } //       .  //    ,   //  . for i := 0; i < tests.Len(); i++ { tasks <- tests.At(i) } //        //       . for i := 0; i < *jobs; i++ { tasks <- "" <- done } } } // -runner. func runner(tasks chan string, done chan bool) { //  . for { //    . ,   //   . name := <- tasks //   ,   . if len(name) == 0 { break } //  . compile(name) } //  ,   . done <- true } func compile(name string) { //  . c, err := exec.Run(*compiler, []string{*compiler, name}, os.Environ(), "./data", exec.DevNull, exec.PassThrough, exec.PassThrough) if err != nil { fmt.Printf("unable to compile %s (%s)\n", name, err.String()) os.Exit(1) } c.Wait(0) } 

makefile:

 target = tar_extractor all: 6g $(target).go 6l -o $(target) $(target).6 

मैंने आठ प्रोसेसर ब्लेड पर लिनक्स 64-बिट के तहत इस सामान को निकाल दिया। परीक्षण के दौरान, मैं मशीन पर अकेला था, इसलिए विभिन्न रनों के परिणामों की तुलना की जा सकती है। "विशाल.tar" फ़ाइल में ~ 15 हजार स्रोत हैं और इसमें एक गीगाबाइट का आकार है।

जब मशीन कुछ भी नहीं करता है तो प्रोसेसर लोडिंग कैसा दिखता है (सभी प्रोसेसर लगभग 100% निष्क्रिय हैं):

  Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.3%sy, 0.0%ni, 99.3%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 

अनुक्रमिक मोड में चलाएं (-ओज़र 0):

  make && time -p ./tar_extractor -jobs 0 huge.tar 

काम का समय:

  real 213.81 user 187.32 sys 61.33 

सभी प्रोसेसर का लगभग 70-80% कुछ भी नहीं करते हैं (मैंने संकलन चरण के दौरान सभी तस्वीरें लीं):

  Cpu0 : 11.9%us, 4.3%sy, 0.0%ni, 82.5%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 9.6%us, 2.7%sy, 0.0%ni, 87.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 4.3%us, 1.3%sy, 0.0%ni, 92.7%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 16.0%us, 6.0%sy, 0.0%ni, 78.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 12.6%us, 4.3%sy, 0.0%ni, 82.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 11.6%us, 3.3%sy, 0.0%ni, 85.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 4.7%us, 1.3%sy, 0.0%ni, 94.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 16.6%us, 6.3%sy, 0.0%ni, 77.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 

कुल प्रोसेसर लोड 2.7% है:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15054 tester 18 0 41420 4980 1068 S 2.7 0.1 0:02.96 tar_extractor 

अब थ्रेड पूल से शुरू करें, लेकिन केवल एक चैनल (-मुखमैथुन 1) के साथ।

समय:

  real 217.87 user 191.42 sys 62.53 

प्रोसेसर:

  Cpu0 : 5.7%us, 1.7%sy, 0.0%ni, 92.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 13.3%us, 5.3%sy, 0.0%ni, 81.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 7.0%us, 2.7%sy, 0.0%ni, 89.3%id, 0.7%wa, 0.0%hi, 0.3%si, 0.0%st Cpu3 : 15.3%us, 5.7%sy, 0.0%ni, 77.7%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 6.0%us, 2.0%sy, 0.0%ni, 92.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 14.3%us, 7.3%sy, 0.0%ni, 78.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 7.0%us, 2.3%sy, 0.0%ni, 90.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 15.3%us, 6.6%sy, 0.0%ni, 78.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 

यह स्पष्ट है कि तस्वीर वही है, क्योंकि वास्तव में हम एक धारा भी चलाते हैं।

अब थ्रेड पूल चालू करें (-जॉब 32):

  make && time -p ./tar_extractor -jobs 32 huge.tar 

ऑपरेटिंग समय लगभग सात गुना गिर गया है:

  real 38.38 user 195.55 sys 69.92 

कुल प्रोसेसर लोड (संकलन चरण के दौरान) बढ़कर 23% हो गया:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17488 tester 16 0 45900 9732 1076 S 23.6 0.1 0:06.40 tar_extractor 

यह देखा जा सकता है कि सभी प्रोसेसर वास्तव में व्यस्त हैं:

  Cpu0 : 56.3%us, 26.3%sy, 0.0%ni, 17.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 55.5%us, 27.9%sy, 0.0%ni, 15.6%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 56.1%us, 25.9%sy, 0.0%ni, 15.0%id, 0.7%wa, 0.3%hi, 2.0%si, 0.0%st Cpu3 : 58.1%us, 26.2%sy, 0.0%ni, 15.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 57.2%us, 25.8%sy, 0.0%ni, 17.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 56.8%us, 26.2%sy, 0.0%ni, 16.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 59.0%us, 26.3%sy, 0.0%ni, 13.0%id, 1.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 56.5%us, 27.2%sy, 0.0%ni, 16.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 

यह परीक्षण पूरी तरह से यह समझने के लिए है कि सबसे सरल समानांतर कोड सब कुछ कैसे गति देता है। और यह भी प्रदर्शित करने के लिए कि आप गो में समानांतर कंप्यूटिंग को कैसे सरल और अपेक्षाकृत सुरक्षित बना सकते हैं।

आगे बढ़ो। आइए देशी धागे की तुलना में गो-दिनचर्या की दक्षता की तुलना करें, उदाहरण के लिए, सी ++ में।

मैं मानता हूं, मैं बूस्ट और नए सी ++ में लड़ाकू नहीं हूं, लेकिन सी ++ में समाधान बहुत ही सुरुचिपूर्ण है।

निर्माण से गति और उन्हें काम के असाइनमेंट के संदर्भ में दोनों भाषाओं में प्रवाह की उत्पादकता की तुलना करना दिलचस्प था। जैसा कि मैं इसे समझता हूं, यह pthreads और गो-रुटीन सिस्टम के बीच एक लड़ाई है, जो ऑपरेटिंग सिस्टम थ्रेड नहीं हैं। जैसा कि प्रलेखन कहता है :

गोरूटाइन को कई ओएस थ्रेड्स पर मल्टीप्लेक्स किया जाता है, अगर किसी को ब्लॉक करना चाहिए, जैसे कि I / O की प्रतीक्षा करते समय, अन्य लोग चलते रहते हैं। उनका डिज़ाइन धागा निर्माण और प्रबंधन की कई जटिलताओं को छुपाता है।

मैंने अंतिम बढ़ावा लिया, और उसी आठ प्रोसेसर मशीन पर प्रयोग किया।

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

तो, जाओ पर कार्यक्रम:

 package main import ( "flag" "fmt" ) var jobs *int = flag.Int("jobs", 8, "number of concurrent jobs") var n *int = flag.Int("tasks", 1000000, "number of tasks") func main() { flag.Parse() fmt.Printf("- running %d concurrent job(s)\n", *jobs) fmt.Printf("- running %d tasks\n", *n) tasks := make(chan int, *jobs) done := make(chan bool) for i := 0; i < *jobs; i++ { go runner(tasks, done) } for i := 1; i <= *n; i++ { tasks <- i } for i := 0; i < *jobs; i++ { tasks <- 0 <- done } } func runner(tasks chan int, done chan bool) { for { if arg := <- tasks; arg == 0 { break } worker() } done <- true } func worker() int { return 0 } 

Makefile मापदंडों की एक श्रृंखला के माध्यम से चलाने के लिए:

 target = go_threading all: build build: 6g $(target).go 6l -o $(target) $(target).6 run: (time -p ./$(target) -tasks=$(args) \ 1>/dev/null) 2>&1 | head -1 | awk '{ print $$2 }' n = \ 10000 \ 100000 \ 1000000 \ 10000000 \ 100000000 test: @for i in $(n); do \ echo "`printf '% 10d' $$i`" `$(MAKE) args=$$i run`; \ done 

C ++ प्रोग्राम:

 #include <iostream> #include <boost/thread.hpp> #include <boost/bind.hpp> #include <queue> #include <string> #include <sstream> class thread_pool { typedef boost::function0<void> worker; boost::thread_group threads_; std::queue<worker> queue_; boost::mutex mutex_; boost::condition_variable cv_; bool done_; public: thread_pool() : done_(false) { for(int i = 0; i < boost::thread::hardware_concurrency(); ++i) threads_.create_thread(boost::bind(&thread_pool::run, this)); } void join() { threads_.join_all(); } void run() { while (true) { worker job; { boost::mutex::scoped_lock lock(mutex_); while (queue_.empty() && !done_) cv_.wait(lock); if (queue_.empty() && done_) return; job = queue_.front(); queue_.pop(); } execute(job); } } void execute(const worker& job) { job(); } void add(const worker& job) { boost::mutex::scoped_lock lock(mutex_); queue_.push(job); cv_.notify_one(); } void finish() { boost::mutex::scoped_lock lock(mutex_); done_ = true; cv_.notify_all(); } }; void task() { volatile int r = 0; } int main(int argc, char* argv[]) { thread_pool pool; int n = argc > 1 ? std::atoi(argv[1]) : 10000; int threads = boost::thread::hardware_concurrency(); std::cout << "- executing " << threads << " concurrent job(s)" << std::endl; std::cout << "- running " << n << " tasks" << std::endl; for (int i = 0; i < n; ++i) { pool.add(task); } pool.finish(); pool.join(); return 0; } 

makefile:

 BOOST = ~/opt/boost-1.46.1 target = boost_threading build: g++ -O2 -I $(BOOST) -o $(target) \ -lpthread \ -lboost_thread \ -L $(BOOST)/stage/lib \ $(target).cpp run: (time -p LD_LIBRARY_PATH=$(BOOST)/stage/lib ./$(target) $(args) \ 1>/dev/null) 2>&1 | head -1 | awk '{ print $$2 }' n = \ 10000 \ 100000 \ 1000000 \ 10000000 \ 100000000 test: @for i in $(n); do \ echo "`printf '% 10d' $$i`" `$(MAKE) args=$$i run`; \ done 

दोनों भाषाओं में, थ्रेड्स की संख्या प्रोसेसर की संख्या के बराबर होगी - 8. इन आठ थ्रेड्स के माध्यम से चलने वाले कार्यों की संख्या अलग-अलग होगी।

C ++ में प्रोग्राम चलाएँ:

 make && make -s test g++ -O2 -I ~/opt/boost-1.46.1 -o boost_threading \ -lpthread \ -lboost_thread \ -L ~/opt/boost-1.46.1/stage/lib \ boost_threading.cpp (time -p LD_LIBRARY_PATH=~/opt/boost-1.46.1/stage/lib ./boost_threading \ 1>/dev/null) 2>&1 | head -1 | awk '{ print $2 }' 10000 0.03 100000 0.35 1000000 3.43 10000000 29.57 100000000 327.37 

अब जाओ:

 make && make -s test 6g go_threading.go 6l -o go_threading go_threading.6 10000 0.00 100000 0.03 1000000 0.35 10000000 3.72 100000000 38.27 

अंतर स्पष्ट है।

वैसे, यदि आप सभी 8 प्रोसेसर का उपयोग करने के लिए गो रनटाइम को चर GOMAXPROCS = 8 से सेट करते हैं, (डिफ़ॉल्ट रूप से, केवल एक का उपयोग किया जाता है, तो कई भौतिक प्रोसेसर हैं), तो गो पर प्रोग्राम की गति बेतहाशा गिर जाती है और C ++ में प्रोग्राम के समय के लगभग बराबर हो जाती है। यह पता चलता है कि हल्के थ्रेड्स, मूल थ्रेड्स से गुणा किए जा रहे हैं, तेजी से काम करते हैं।

शायद मैं लाल रंग के साथ नमकीन की तुलना करता हूं, और परिणाम केवल अपर्याप्त हैं। मैं वास्तव में एक संकेत की सराहना करता हूं जिसमें सही ढंग से मापने के लिए तोते हैं।

जाने पर पोस्ट:

• कार्रवाई में भाषा जाओ - एक घंटे से भी कम समय में मल्टिस्वरुर url reducers
• एराटोस्थनीज छलनी - कौन तेज है: गो, सी या सी ++?