"جداول بيانات Google" هي أحد أوائل منتجات Google التي تستخدم WasmGC على Chrome. تم الإعلان عن هذا التغيير في عام 2022، وتعاون فريقا "جداول بيانات Google" وChrome في ما يتعلق بالتوحيد القياسي والهندسة والأدوات لتقديم ملاحظات في الوقت الفعلي حول التحسينات. وقد وضعت هذه الشراكة سابقة لكيفية عمل فِرق الهندسة في Google بفعالية مع Chrome لتشغيل المزيد من تطبيقات Google على WasmGC.
التحدي: JavaScript
تمت كتابة محرك الحسابات في "جداول بيانات Google" في الأصل بلغة Java وتم إطلاقه في عام 2006. في المراحل الأولى من المنتج، كانت تتم جميع العمليات الحسابية على الخادم. ومع ذلك، منذ عام 2013، أصبح المحرّك يعمل في المتصفّح باستخدام JavaScript. تم تحقيق ذلك في الأصل من خلال Google Web Toolkit (GWT)، ثم من خلال محوّل Java إلى Closure JavaScript (J2CL). يعمل محرّك حسابات JavaScript في Web Worker ويتواصل مع السلسلة الرئيسية باستخدام MessageChannel.
كان نقل المستخدمين من الخادم إلى إصدار JavaScript من محرك الحساب (ومن GWT إلى J2CL لاحقًا) مهمة كبيرة تطلّبت التحقّق بعناية. لضمان أن ينتج محرّك حساب JavaScript النتائج نفسها تمامًا التي تنتجها إصدار Java، طوّر فريق "جداول بيانات Google" آلية تحقّق داخلية. يمكن لهذه الآلية معالجة مجموعة كبيرة من أوراق البيانات والتأكّد من تطابق النتائج بين إصدارات متعددة من محرك الحساب. يستخدم فريق "جداول بيانات Google" هذه الأداة بانتظام للتحقّق من صحة التغييرات التي يتم إجراؤها على "جداول بيانات Google". ولم يكتفِ الفريق بمقارنة نتائج هذه العمليات الحسابية، بل قارن أيضًا الأداء بين JavaScript على العميل وJava على الخادم. وقد تبيّن لهم أنّ إصدار JavaScript من محرّك العمليات الحسابية كان أبطأ بأكثر من ثلاث مرات من إصدار Java.
لماذا تكون لغة JavaScript أبطأ من Java؟
تتميّز JavaScript بالسرعة لأنّها لغة ديناميكية غير صارمة الكتابة. وقد أدّى الاستثمار الكبير في برامج الترجمة الفورية (JIT) (مثل Maglev وSparkplug وTurbofan) على مدار الـ 15 عامًا الماضية إلى تحسين أداء JavaScript. ومع ذلك، فإنّ الأنواع غير الصارمة والسلوك الديناميكي للغة JavaScript يجعل من الصعب على برامج التجميع أثناء التشغيل إنشاء رمز برمجي مثالي. وهذا يعني أنّ JavaScript لا يزال متأخرًا عن لغات مثل Java وC++ من حيث معدّل النقل الأولي. تضيف TypeScript أمان الأنواع إلى JavaScript، ولكن تم تصميم معلومات الأنواع هذه لتسهيل عملية التطوير، وليس لتقديم أنواع الضمانات التي تحتاجها المترجمات لإنشاء رمز برمجي مثالي. في حالات مثل "جداول بيانات Google"، حيث يمكن أن تستغرق جداول البيانات الكبيرة عشرات الثواني لاحتساب البيانات، تكون JavaScript سريعة، ولكن ليس بالقدر الكافي.
الحل: WasmGC
WasmGC هي إضافة إلى مواصفات WebAssembly الحالية، وتضيف العناصر الأساسية اللازمة لترجمة اللغات التي يتم جمع البيانات غير الضرورية فيها (مثل Java). على سبيل المثال، يضيف WasmGC تعليمات لتحديد الأنواع وتخصيص هياكل البيانات التي يتم جمعها. من المتوقّع أن تقدّم WasmGC للغات التي يتم جمع البيانات غير الضرورية فيها الميزات نفسها التي قدّمتها Wasm للغة C++ (على سبيل المثال، Photoshop أو Google Earth)، أي إتاحة استخدامها على الويب بسرعة قريبة من سرعة التطبيقات الأصلية. في Google، نعتقد أنّ WasmGC لديه القدرة على إحداث تأثير أكبر من Wasm بسبب رواج اللغات التي يتم فيها جمع البيانات غير الضرورية.
Google Workspace يتعاون مع Chrome
تم نشر مسودة مواصفات الحد الأدنى من الميزات القابلة للتطبيق في WasmGC في عام 2019. في أواخر عام 2020، تعاون كلّ من Google Workspace وChrome لتقييم WasmGC باستخدام محرّك حسابات "جداول بيانات Google". يتمتّع فريق المنصات المتعددة في Workspace بخبرة كبيرة في إنشاء المحوّلات البرمجية والمحوّلات البرمجية المترجمة وتحسينها. تم تحديد "جداول بيانات Google"، وهي جزء من Workspace، كخيار مثالي لتقييم WasmGC، فهي حساسة للأداء وتتضمّن آليات قوية للتحقّق من الأداء والصحة. يضم فريق V8 مطوّرين يعملون على إنشاء وقت تشغيل WasmGC وتحسينه، بالإضافة إلى مساهمين في Binaryen لإنشاء تحسينات على الترجمة المسبقة (AOT). تتوفّر بين Chrome وWorkspace كل الخبرة اللازمة لإنشاء سلسلة أدوات WasmGC وتحسينها، مع توفّر "جداول بيانات Google" كبيئة اختبار مثالية.
النموذج الأوّلي الأول
بحلول منتصف عام 2021، كان لدى الفِرق مترجم Java إلى WasmGC يعمل. وبحلول نهاية العام نفسه، تمكّنوا من تشغيل نسخة أولية من "جداول بيانات Google" باستخدام WasmGC وإجراء العمليات الحسابية. وواجهوا خلال رحلتهم العديد من التحديات. لم تكن هناك أدوات لإنشاء الملفات الشخصية وأخذ عمليات تفريغ الذاكرة المؤقتة، وكان يجب إنشاؤها. اعتمد التنفيذ الحالي على العديد من مكتبات JavaScript التي كان يجب العثور على بدائل لها أو كتابتها لـ WasmGC. كان التحقّق من صحة محرك حساب Wasm يستغرق وقتًا طويلاً بسبب الطبيعة التجريبية للمواصفات والمترجم والمكتبات الجديدة. ولكن كانت آليات التحقّق من الصحة في "جداول بيانات Google" مفيدة للغاية مرة أخرى. في النهاية، تمكّنت الفِرق من إنجاز كل ذلك، وبدأت بيانات الأداء في الوصول في أوائل عام 2022.
تحسينات إضافية
أظهرت النسخة الأولية من Sheets Wasm أداءً في العمليات الحسابية أبطأ بمرتين تقريبًا من JavaScript. ومع ذلك، هذه ليست نتيجة سيئة لمواصفات جديدة ومترجم جديد والعديد من المكتبات الجديدة. من هذه النقطة، بدأ فريق "جداول بيانات Google" في إجراء التحسينات. ومن بين التحسينات التي عثروا عليها، ظهرت بضع فئات:
- تكرار التحسينات الأساسية المتوفّرة في "آلة Java الافتراضية" (JVM) وفي V8
- استخدام واجهات برمجة تطبيقات المتصفّح المحسّنة بشكل كبير
- إزالة أنماط الترميز الخاصة بلغة JavaScript
أولاً، كان على فريق "جداول بيانات Google" تكرار عمليات التحسين المتوفّرة حاليًا في سلاسل الأدوات الأخرى. وأفضل مثال على ذلك هو تحسين إرسال الطُرق الافتراضية، الذي تم تحسينه منذ فترة طويلة من خلال JVM وV8، ولكن لم يكن هناك أي شيء متاح لـ WasmGC. أدّى تنفيذ التضمين التخميني وإزالة التجريد، وهما طريقتان شائعتان جدًا لتحسين الأداء، إلى تسريع وقت الحساب بنسبة% 40 تقريبًا في Chrome.
ثانيًا، هناك حالات تكون فيها واجهات برمجة التطبيقات للمتصفح مدعومة بتنفيذات أصلية محسّنة يصعب منافستها باستخدام WebAssembly. السلاسل النصية والتعبيرات العادية هما مثالان جيدان على ذلك. على وجه التحديد، لاحظ الفريق أنّ عمليات التعبيرات العادية أصبحت أسرع بمقدار 100 مرة تقريبًا عند التبديل من re2j (التي تم تجميعها إلى WasmGC) إلى واجهة برمجة التطبيقات RegExp في المتصفح Chrome، والتي يمكنها تجميع كل تعبير عادي إلى رمز الآلة الخاص به.
أخيرًا، تبيّن لهم أنّ سنوات التحسين أدّت إلى زيادة توافق قاعدة الرموز مع JavaScript. على سبيل المثال، كان لديهم بنية بيانات أساسية في "جداول بيانات Google" تؤدي إلى عدم وضوح الحدود بين المصفوفات والخرائط. ويكون هذا الإجراء فعّالاً في JavaScript، الذي يصمّم تلقائيًا المصفوفات المتفرقة كخرائط، ولكنه بطيء على المنصات الأخرى. لذلك، كان عليهم إعادة كتابة الرمز بطريقة أكثر استقلالية عن النظام الأساسي. هذا سبب آخر يعجب الفريق في WebAssembly، إذ يسهّل على التطبيقات المتوافقة مع أنظمة أساسية متعدّدة تحقيق أداء جيد على الويب. لست مضطرًا إلى تعديل تطبيقك بالكامل ليتوافق مع خصائص JavaScript.
النتيجة النهائية
بعد إجراء كل عمليات التحسين هذه، يحقّق إصدار WasmGC النهائي من "جداول بيانات Google" أداءً حسابيًا أسرع بمرتين تقريبًا من JavaScript، ما يمثّل تحسّنًا بمقدار أربعة أضعاف مقارنةً بنقطة البداية لإصدار WasmGC الأوّلي.
الخاتمة
WasmGC هي تكنولوجيا فعّالة لديها القدرة على تطوير الطريقة التي ينشئ بها المطوّرون تطبيقات الويب. خلال السنوات القادمة، نأمل في Google أن نرى WasmGC يتطوّر لدعم سلسلة المحادثات المتعددة للذاكرة المشتركة وتحسين الأداء بشكل أكبر في سلسلة المحادثات الفردية. ننصح جميع مطوّري الويب باستخدام WasmGC في مشاريعهم التالية التي تتطلّب أداءً عاليًا. انضمّ إلينا لنعمل معًا على جعل الويب أسرع وأكثر سلاسة.
الإقرارات
نشكر كل من ساهم في تنفيذ WasmGC وإعداد دراسة الحالة هذه: ديواس أديكاري، ماثيو أولبرايت، كسينيا بوكينا، جوليان دراميكس، عاصم فضل، مايكل فريدريك، غوكوتغ غوكدوغان، جانيس غو، آدم كلاين، مانوس كوكوتوس، جاكوب كوميرو، ماتياس ليدتك، توماس لايفلي، روبرتو لوبلينرمان، فيشرت ميهتا، توماس ناتستاد، جوش بيرلشتاين، جواكيم بيروتي، كريس روينز، ستيفن سافيانو، ديريك شوف، تيم سيرز، مايكل توماس، يوان تيان، فيليب فايس، ماسون وو، ألون زاكاي، إيمانويل زيغلر.