एक बेस नेटवर्क बनाने के लिए Google गो के गोरोटाइन्स का उपयोग करें

Question

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

मुझे संबंधित तर्कों का एक बेसियन नेटवर्क बनाने की आवश्यकता है, ताकि प्रत्येक नोड अपने संबंधित तर्कों के लिए काफी सटीक और सटीक प्रभाव डाल सके; मुझे कनेक्टेड नोड्स की श्रृंखलाओं की संभावनाओं की गणना करने में सक्षम होने की आवश्यकता है, प्रत्येक नोड को डेटास्टोर लुकअप की आवश्यकता होती है जो परिणाम प्राप्त करने के लिए अवरुद्ध होनी चाहिए; प्रक्रिया ज्यादातर I/O बाध्य है, और मेरा डेटास्टोर कनेक्शन जावा, गो और पायथन {google appengine} में असीमित रूप से चला सकता है। एक बार प्रत्येक लुकअप पूरा हो जाने पर, यह अन्य सभी जुड़े नोड्स के प्रभाव को तब तक फैलता है जब तक कि संभाव्यता डेल्टा अपरिवर्तनीयता की वर्तमान सीमा से नीचे गिर जाती है {वर्तमान में 0.1%}। प्रक्रिया के प्रत्येक नोड को कनेक्शन की श्रृंखला की गणना करनी चाहिए, फिर वैधता परिणामों को समायोजित करने के लिए सभी प्रश्नों के सभी परिणामों को जोड़ना चाहिए, परिणाम किसी भी जुड़े तर्क के लिए बाहरी रूप से जंजीर हैं।

अनगिनत आवर्ती से बचने के लिए, मैं तर्कसंगत प्रभावों के आधार पर एक ह्युरिस्टिक के साथ गोरोटाइन में ए * जैसी प्रक्रिया का उपयोग करने के बारे में सोच रहा था, जो प्रभावशाली डिप्स की संभावना के बाद नोड्स को अनदेखा करता है, कहें 0.1% मैं एसक्यूएल ट्रिगर्स के साथ गणना स्थापित करने की कोशिश करता था, लेकिन यह जटिल और गन्दा रास्ता बहुत तेज हो गया। फिर मैं एसिंक्रोनस नोस्कल का लाभ उठाने के लिए Google एपेंजिन पर गया, और यह बेहतर था, लेकिन अभी भी बहुत धीमी थी। मुझे एक स्नैपी UI प्राप्त करने के लिए पर्याप्त तेज़ अपडेट चलाने की आवश्यकता है, इसलिए जब कोई उपयोगकर्ता किसी सबूत या विवाद के लिए या उसके विरुद्ध वोट बनाता है या वोट देता है, तो वे तुरंत यूआई में दिखाई देने वाले परिणाम देख सकते हैं।

मुझे लगता है कि मुझे आवश्यक समेकन का समर्थन करने के लिए गो की पसंद की भाषा है, लेकिन मैं सुझावों के लिए खुला हूं। क्लाइंट एक मोनोलिथिक जावास्क्रिप्ट ऐप है जो वास्तविक समय में तर्क मानचित्र {और उनके अपडेट} को पुश करने और खींचने के लिए एक्सएचआर और websockets का उपयोग करता है। मेरे पास एक जावा प्रोटोटाइप है जो 10 ~ 15s में बड़ी श्रृंखलाओं की गणना कर सकता है, लेकिन प्रदर्शन की निगरानी से पता चलता है कि मेरा अधिकांश रनटाइम सिंक्रनाइज़ेशन और कंसूरेंट हैशैप से ओवरहेड में बर्बाद हो जाता है।

यदि अन्य अत्यधिक समवर्ती भाषाओं की कोशिश करने लायक हैं, तो कृपया मुझे बताएं। मैं जावा, पायथन, जाओ, रूबी और स्कैला जानता हूं, लेकिन अगर मेरी जरूरतों के अनुरूप है तो कोई भी भाषा सीख जाएगी।

इसी प्रकार, यदि विशाल बेयसियन नेटवर्क के खुले स्रोत कार्यान्वयन हैं, तो कृपया एक सुझाव छोड़ दें।

Answer 1

मुझे लगता है कि आप जो पूछ रहे हैं उसे बताने में थोड़ा मुश्किल है। शायद आप अपने प्रश्न पर विस्तार कर सकते हैं।

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

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

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