Google Sheets, Chrome पर WasmGC का इस्तेमाल करने वाले Google के शुरुआती प्रॉडक्ट में से एक है. इस बदलाव का एलान 2022 में किया गया था. Sheets और Chrome की टीमों ने ऑप्टिमाइज़ेशन पर रीयल-टाइम में सुझाव देने के लिए, स्टैंडर्डाइज़ेशन, इंजीनियरिंग, और टूल के साथ साझेदारी की. इस साझेदारी ने एक मिसाल पेश की कि Google की इंजीनियरिंग टीमें, WasmGC पर Google के ज़्यादा से ज़्यादा ऐप्लिकेशन चलाने के लिए, Chrome के साथ असरदार तरीके से कैसे काम कर सकती हैं.
चुनौती: JavaScript
Google Sheets कैलकुलेशन इंजन को मूल रूप से Java में लिखा गया था और इसे 2006 में लॉन्च किया गया था. प्रॉडक्ट के शुरुआती दिनों में, सारा कैलकुलेशन सर्वर पर होता था. हालांकि, 2013 से, इंजन ब्राउज़र में JavaScript का इस्तेमाल करके चलता रहा है. यह काम मूल तौर पर Google Web Toolkit (GWT) की मदद से और बाद में Java से Close JavaScript ट्रांसपिलर (J2CL) की मदद से किया गया. JavaScript कैलकुलेशन इंजन, वेब वर्कर में चलता है और MessageChannel का इस्तेमाल करके, मुख्य थ्रेड से संपर्क करता है.
उपयोगकर्ताओं को सर्वर से कैलकुलेशन इंजन के JavaScript वर्शन पर माइग्रेट करना एक बड़ा काम था. इसके लिए, सावधानी से पुष्टि करने की ज़रूरत थी. इसके बाद, GWT से J2CL पर भी माइग्रेट किया जा सका. यह पक्का करने के लिए कि JavaScript कैलकुलेशन इंजन और Java वर्शन वाले नतीजे सटीक तौर पर दें, Sheets की टीम ने अंदरूनी तौर पर पुष्टि करने का एक तरीका तैयार किया है. यह तरीका, शीट के एक बड़े संग्रह को प्रोसेस कर सकता है. साथ ही, यह पुष्टि कर सकता है कि कैलकुलेशन इंजन के कई वर्शन के नतीजे एक जैसे हैं. Sheets की टीम, Sheets में किए गए बदलावों की पुष्टि करने के लिए, नियमित तौर पर इस टूल का इस्तेमाल करती है. हालांकि, टीम ने न सिर्फ़ उन कैलकुलेशन के नतीजों की तुलना की, बल्कि क्लाइंट के JavaScript और सर्वर पर Java की परफ़ॉर्मेंस की तुलना भी की. उन्होंने पाया कि कैलकुलेशन इंजन का JavaScript वर्शन, Java वर्शन के मुकाबले तीन गुना से ज़्यादा धीमा था.
JavaScript, Java से धीमी क्यों है?
JavaScript, आसानी से टाइप की जाने वाली डाइनैमिक भाषा के लिए तेज़ काम करती है. पिछले 15 सालों में, जेआईटी कंपाइलर, जैसे कि मैगलेव, स्पार्कप्लग, और टर्बोफ़ैन में भारी निवेश से JavaScript की परफ़ॉर्मेंस बेहतर हुई है. हालांकि, JavaScript के ढीले टाइप और डाइनैमिक व्यवहार की वजह से, JIT कंपाइलर के लिए सही कोड जनरेट करना मुश्किल होता है. इसका मतलब है कि रॉ थ्रूपुट के मामले में JavaScript अब भी Java और C++ जैसी भाषाओं से पीछे है. TypeScript में, JavaScript में टाइप सेफ़्टी को जोड़ा जाता है. हालांकि, इस तरह की जानकारी को डेवलपमेंट को आसान बनाने के लिए डिज़ाइन किया गया है. इससे, कंपाइलर को अलग-अलग तरह की गारंटी नहीं मिलती हैं, ताकि वे सबसे अच्छा कोड जनरेट कर सकें. Google Sheets जैसे मामलों में, जहां बड़ी स्प्रेडशीट को कैलकुलेट करने में कई सेकंड लग सकते हैं वहां JavaScript तेज़ है, लेकिन ज़रूरत के मुताबिक तेज़ नहीं है.
समाधान: WasmGC
WasmGC, मौजूदा WebAssembly स्पेसिफ़िकेशन का एक एक्सटेंशन है. यह ग़ैर-ज़रूरी चीज़ें इकट्ठा करने के लिए इस्तेमाल होने वाली भाषाओं (जैसे, Java) को कंपाइल करने के लिए ज़रूरी प्रिमिटिव जोड़ता है. उदाहरण के लिए, WasmGC ने कचरा इकट्ठा करने के लिए, डेटा के टाइप तय करने और उसे अलग-अलग कैटगरी में बांटने के निर्देश जोड़े. WasmGC ऐसा कॉन्टेंट तैयार करने के लिए तैयार है जो कचरा इकट्ठा करने के लिए इस्तेमाल की जाने वाली भाषाओं के लिए है. Wasm ने C++ के लिए जो किया, वह Wasm ने किया (उदाहरण के लिए, Photoshop या Google Earth), जिसके लिए उन्हें करीब-करीब स्थानीय स्पीड पर वेब पर लाया गया. Google का मानना है कि कचरा इकट्ठा करने वाली भाषाओं की लोकप्रियता की वजह से WasmGC के पास होने की संभावना ज़्यादा है.
Google Workspace ने Chrome के साथ साझेदारी की है
WasmGC MVP ड्राफ़्ट की खास बातें 2019 में पब्लिश की गई थीं. साल 2020 के आखिर में, Google Workspace और Chrome ने साथ मिलकर, Sheets कैलकुलेशन इंजन का इस्तेमाल करके, WasmGC का आकलन किया. Workspace की मल्टीप्लैटफ़ॉर्म टीम के पास, कंपाइलर और ट्रांसपिलर बनाने और उन्हें ऑप्टिमाइज़ करने में काफ़ी विशेषज्ञता है. Sheets, Workspace का हिस्सा है. इसे WasmGC का आकलन करने के लिए सबसे सही विकल्प माना गया है: यह परफ़ॉर्मेंस के हिसाब से संवेदनशील है. इसकी परफ़ॉर्मेंस और इसके सही होने की पुष्टि करने के तरीके बहुत अच्छे हैं. Chrome के पास V8 टीम है, जो WasmGC रनटाइम को बनाने और ऑप्टिमाइज़ करने के साथ-साथ Binaryen में योगदान देने वालों के साथ-साथ, समय से पहले (एओटी) ऑप्टिमाइज़ेशन बनाने के लिए करता है. Chrome और Workspace के बीच, WasmGC टूलचेन को बनाने और उसे ऑप्टिमाइज़ करने के लिए सभी तरह की विशेषज्ञता उपलब्ध है. इसमें Google Sheets एक बेहतरीन टेस्ट बेड है.
पहला प्रोटोटाइप
साल 2021 के मध्य तक, टीमों के पास Java to WasmGC कंपाइलर का काम करने वाला टूल था. उसी साल के आखिर में, उनके पास Google Sheets का एक प्रोटोटाइप वर्शन था, जो WasmGC के तौर पर चल रहा था और कैलकुलेशन कर रहा था. अपने इस सफ़र में उन्होंने कई चुनौतियां पूरी कीं. हीप डंप की प्रोफ़ाइल बनाने और उन्हें हटाने के लिए टूल मौजूद नहीं था. इसलिए, इसे बनाया जाना ही था. इसे लागू करने का मौजूदा तरीका कई JavaScript लाइब्रेरी पर निर्भर था, जिनके लिए WasmGC की जगह ढूंढनी या लिखी गई थी. Wasm के कैलकुलेशन इंजन के सही होने की पुष्टि करने में काफ़ी समय लगता था. ऐसा, स्पेसिफ़िकेशन, कंपाइलर, और नई लाइब्रेरी की एक्सपेरिमेंटल गतिविधि की वजह से होता था. हालांकि, Sheets की पुष्टि करने के तरीके ने फिर से बहुत मददगार साबित कर दिया. आखिरकार, सभी टीमों ने काम करना शुरू कर दिया और परफ़ॉर्मेंस का डेटा 2022 की शुरुआत में मिलने लगा.
अतिरिक्त ऑप्टिमाइज़ेशन
Sheets Wasm के शुरुआती वर्शन में, JavaScript के मुकाबले कैलकुलेशन की परफ़ॉर्मेंस करीब दो गुना धीमी थी. हालांकि, यह नए वर्शन, नए कंपाइलर, और कई नई लाइब्रेरी के लिए अच्छा नतीजा नहीं है. इसके बाद, Sheets की टीम ने ऑप्टिमाइज़ करना शुरू किया. उन्हें जो ऑप्टिमाइज़ेशन मिले, उनमें से कुछ कैटगरी सामने आईं:
- Java वर्चुअल मशीन (JVM) और V8 में पहले से मौजूद कोर ऑप्टिमाइज़ेशन की कॉपी बनाना.
- बेहतर तरीके से ऑप्टिमाइज़ किए गए ब्राउज़र एपीआई का इस्तेमाल करना.
- JavaScript से जुड़े कोडिंग पैटर्न हटाए जा रहे हैं.
सबसे पहले, Sheets की टीम को उन ऑप्टिमाइज़ेशन को दोहराने की ज़रूरत थी जो पहले से ही अन्य टूलचेन में मौजूद हैं. इसका सबसे अच्छा उदाहरण, वर्चुअल तरीके से मैसेज भेजने की सुविधा को ऑप्टिमाइज़ करना है. इस तरीके को JVM और V8 लंबे समय तक ऑप्टिमाइज़ करते रहे हैं, लेकिन WasmGC के लिए कुछ भी मौजूद नहीं था. अनुमान लगाने के लिए इनलाइनिंग और डीवर्चुअलाइज़ेशन को लागू करने से, Chrome में कैलकुलेशन का समय करीब 40% तक बढ़ गया. ये दो तरीके आम तौर पर इस्तेमाल किए जाते हैं.
दूसरा विकल्प यह है कि ब्राउज़र एपीआई के लिए, ऑप्टिमाइज़ किए गए नेटिव विज्ञापनों का इस्तेमाल किया जाता है. हालांकि, Wasm के साथ काम करना मुश्किल होता है. स्ट्रिंग और रेगुलर एक्सप्रेशन दो अच्छे उदाहरण हैं. खास तौर पर, रेगुलर एक्सप्रेशन का इस्तेमाल करने पर टीम को पता चला कि Chrome के re2j (इसे कंपाइल किया गया है) से RegExp ब्राउज़र एपीआई पर स्विच करने पर, रेगुलर एक्सप्रेशन की कार्रवाइयों की स्पीड करीब 100 गुना बढ़ी है. यह एपीआई हर रेगुलर एक्सप्रेशन को अपने मशीन कोड में इकट्ठा कर सकता है.
आखिर में, उन्होंने पाया कि सालों तक ऑप्टिमाइज़ करने की वजह से कोडबेस JavaScript के लिए ज़रूरत से ज़्यादा फ़िट हो गया है. उदाहरण के लिए, Sheets में उनका मुख्य डेटा स्ट्रक्चर था, जो अरे और मैप के बीच की लाइनों को धुंधला कर रहा था. यह JavaScript में कारगर है. यह स्पार्स अरे को अपने-आप मैप के तौर पर मॉडल करता है, लेकिन अन्य प्लैटफ़ॉर्म पर यह धीमी रफ़्तार से चलता है. इसलिए, उन्हें प्लैटफ़ॉर्म-एग्नॉस्टिक तरीके से कोड को दोबारा लिखना पड़ा. WebAssembly के बारे में टीम को यह भी पसंद है: इससे, मल्टीप्लैटफ़ॉर्म ऐप्लिकेशन के लिए वेब पर अच्छी परफ़ॉर्मेंस पाना आसान हो जाता है. आपको अपने पूरे ऐप्लिकेशन को JavaScript की विशिष्टता के साथ जोड़ने की ज़रूरत नहीं है.
आखिरी नतीजा
इन सभी ऑप्टिमाइज़ेशन के बाद, Sheets के आखिरी WasmGC वर्शन को कैलकुलेट करने की परफ़ॉर्मेंस, JavaScript की तुलना में दो गुना तेज़ी से मिलती है. इसमें WasmGC के शुरुआती वर्शन के शुरुआती पॉइंट से चार गुना सुधार होता है.
नतीजा
WasmGC एक बेहतरीन टेक्नोलॉजी है. इसमें, डेवलपर के वेब ऐप्लिकेशन बनाने के तरीके को बेहतर बनाने की क्षमता है. आने वाले सालों में Google, हमें उम्मीद है कि Google में WasmGC बेहतर होगा और वह शेयर की गई मेमोरी की मल्टीथ्रेडिंग के साथ काम करेगा और सिंगल थ्रेड की परफ़ॉर्मेंस को बेहतर करेगा. हम सभी वेब डेवलपर को सलाह देते हैं कि वे अपने अगले और बेहतरीन परफ़ॉर्मेंस वाले प्रोजेक्ट के लिए, WasmGC का इस्तेमाल करें. हमसे जुड़ें और वेब को सबके साथ मिलकर ज़्यादा तेज़ी से काम करने में मदद करें!
स्वीकार की गई
शुक्रिया