2024 में 10 लाख concurrent tasks चलाने के लिए कितनी memory चाहिए?
(hez2010.github.io)Rust, C#, Python, Go, Java, NodeJS आदि के नवीनतम versions में 10 लाख concurrent tasks को प्रोसेस करने वाले प्रोग्राम चलाकर memory efficiency की तुलना की गई।
C# (NativeAOT) और Rust ने सबसे बेहतरीन memory efficiency दिखाई, जबकि Go को अपेक्षा से अधिक memory consumption के कारण कम आंका गया। कुल मिलाकर .NET और Rust का प्रदर्शन खास रहा, और Java (GraalVM) ने चौंकाने वाला सुधार दिखाया।
विशेष रूप से Rust ने लगभग 29MB के साथ सबसे कम memory इस्तेमाल की, और उसके बाद C# NativeAOT लगभग 71MB पर रहा। NodeJS ने 232MB, Python ने 339MB दर्ज किए। Go ने 753MB के साथ तुलनात्मक रूप से काफी अधिक memory usage दिखाया, जिससे निराशाजनक नतीजे सामने आए। Java (GraalVM) ने 92MB के साथ बड़ा सुधार दिखाया।
10 टिप्पणियां
बेंचमार्क कोड को देखें तो Rust और Python के मामले में वास्तव में concurrent task बनाए नहीं जा रहे हैं, बल्कि ऐसे future object बनाए जा रहे हैं जो asynchronous तो हैं, लेकिन दूसरे task के साथ parallel रूप से चल नहीं सकते। शायद C# भी कुछ ऐसा ही मामला होगा। दूसरी ओर, Go कोड में goroutine बनाए जाते हैं, जो अपने call stack आदि रखने वाले task होते हैं, और मुझे लगता है कि 10 लाख मामलों में Go की memory usage खास तौर पर उछली हुई दिखने की वजह यही हो सकती है।
Go के पक्ष में बात करें तो, Go में 10 लाख चलने वाले फ़ंक्शनों के अंदर कोई भी लाइब्रेरी हो, वह काम कर जाती है। बस
goलगा देना होता है। दूसरे asynchronous-आधारित भाषाओं में अगर बीच में synchronous तरीके से थोड़ा भी समय खाने वाली कोई लाइब्रेरी हो, तो ऐसी पागल कर देने वाली स्थिति आ जाती है जहाँ वह asynchronous के सारे फ़ायदे ही खत्म कर देती है.asynchronous के फ़ायदे 100% लेने हों, तो थोड़ा भी समय खाने वाले सभी फ़ंक्शनों को asynchronous में बदलना पड़ता है.
Java VirtualThread तो, hmm... इस बार हमारी कंपनी में Java VirtualThread पर भरोसा करके आगे बढ़े, लेकिन आखिर में लाइब्रेरी compatibility की वजह से फिर सामान्य thread पर वापस जाना पड़ा, और कई दर्जन instances चलाने वाली ending पर बात खत्म हुई.
क्या आप compatibility वाले हिस्से के बारे में थोड़ा और बता सकते हैं? :eyes:
लगता है यह कहना ठीक नहीं होगा कि Spring में अक्सर कही जाने वाली बात — "WebFlux को सही तरीके से इस्तेमाल करना हो तो JPA की बजाय R2DBC के साथ इस्तेमाल करना चाहिए, तभी इसकी असली ताकत सामने आती है" — हमेशा सही है।
सुना है कि ms की msal लाइब्रेरी virtual thread पर काम नहीं करती।
उदाहरण के तौर पर आपने जो msal लाइब्रेरी दी है, मेरे हिसाब से Go के मामले में भी अगर वह ऐसी लाइब्रेरी है जो thread-safe नहीं होने वाले data types या structures का इस्तेमाल करती है, तो मामला वही होगा।
thread safety से इसका क्या संबंध है? goroutine तो मूल रूप से thread safety की गारंटी देने वाला सिस्टम नहीं है, है न?
जानकारी के लिए धन्यवाद
मैं एक सवाल पूछना चाहता हूँ।
तो फिर, क्या Go को छोड़कर बाकी भाषाओं में, जैसा आपने बताया, अगर synchronous तरीके की लाइब्रेरी हो तो सब टूट जाता है?
या फिर क्या दूसरी भाषाओं में भी Go की तरह पूरी तरह asynchronous को सपोर्ट करने वाली भाषाएँ हैं, यह जानने की जिज्ञासा है।
colorlessजैसा एक अभिव्यक्ति है। ऐसी भाषाओं में जहाँ asynchronous और synchronous को अलग-अलग करने की ज़रूरत नहीं होती, Go ही एकमात्र है। उपयोगकर्ता के नज़रिए से जब concurrency की ज़रूरत वाले प्रोग्रामिंग की बात आती है, तो कठिनाई और usability के मामले में Go की बढ़त बेहद प्रभावशाली है.बेशक, optimized asynchronous programming की तुलना में performance थोड़ी कम हो सकती है।
टोकने के लिए माफ़ कीजिए, लेकिन मैं सिर्फ़ उन हिस्सों की बात करूँगा जहाँ
깨진다जैसी अभिव्यक्ति औरपूर्ण asynchronousजैसी अभिव्यक्ति गलत हैं। asynchronous में synchronous लाइब्रेरी का इस्तेमाल करना भी ठीक है, बशर्ते यह गारंटी हो कि वह बहुत कम समय में पूरा हो जाएगा। समस्या तब होती है जब synchronous तरीके से चलने वाला कोई लंबा call हो, क्योंकि तब दूसरी asynchronous प्रोसेसिंग देर से होती है। Go में goroutine के ज़रिए अरबों स्तर के काम assign किए जा सकते हैं, इसलिए भाषा में अपने आप में asynchronous जैसा कोई अलग कॉन्सेप्ट नहीं है। इस्तेमाल करने वाले की नज़र से देखें तो किसी भी function को बसgoलगाकर call कर दें, वह parallel में चलने लगता है, इसलिए यह बहुत सुविधाजनक है। व्यक्तिगत रूप से मुझे लगता है कि सच मेंपूर्ण asynchronousअगर कोई भाषा है, तो वह JavaScript है, क्योंकि उसकी बुनियाद ही asynchronous पर टिकी है।