Google Sheets הוא אחד מהמוצרים הראשונים ב-Google שמשתמשים ב-WasmGC ב-Chrome. המעבר הזה הוכרז בשנת 2022, והצוותים של Sheets ו-Chrome שיתפו פעולה בנושא סטנדרטיזציה, הנדסה וכלים כדי לספק משוב בזמן אמת על אופטימיזציות. השותפות הזו יצרה תקדים לגבי האופן שבו צוותי הנדסה ב-Google יכולים לעבוד ביעילות עם Chrome כדי להפעיל יותר אפליקציות של Google ב-WasmGC.
האתגר: JavaScript
מנוע החישוב של Google Sheets נכתב במקור ב-Java והושק בשנת 2006. בתחילת הדרך של המוצר, כל החישובים התבצעו בשרת. עם זאת, מאז 2013, המנוע פועל בדפדפן באמצעות JavaScript. ההמרה הזו בוצעה במקור באמצעות Google Web Toolkit (GWT), ומאוחר יותר באמצעות Java to Closure JavaScript transpiler (J2CL). מנוע החישוב של JavaScript פועל ב-Web Worker ומתקשר עם השרשור הראשי באמצעות MessageChannel.
העברת משתמשים מהשרת לגרסת JavaScript של מנוע החישוב (ומאוחר יותר מ-GWT ל-J2CL) הייתה משימה מורכבת שדרשה אימות קפדני. כדי לוודא שמנוע החישוב של JavaScript הפיק בדיוק את אותן תוצאות כמו גרסת Java, צוות Sheets פיתח מנגנון אימות פנימי. המנגנון הזה יכול לעבד קבוצה גדולה של גיליונות ולוודא שהתוצאות זהות בין כמה גרסאות של מנוע החישוב. צוות Sheets משתמש בכלי הזה באופן קבוע כדי לאמת שינויים ב-Sheets. אבל הצוות לא רק השווה בין התוצאות של החישובים האלה, אלא גם השווה בין הביצועים של JavaScript בצד הלקוח לבין Java בצד השרת. הם גילו שגרסת JavaScript של מנוע החישוב איטית פי שלושה יותר מגרסת Java.
למה JavaScript איטית יותר מ-Java?
JavaScript היא שפה דינמית עם הקלדה חלשה, אבל היא מהירה. השקעה גדולה בקומפיילרים של just-in-time (JIT) (לדוגמה, Maglev, Sparkplug ו-Turbofan) ב-15 השנים האחרונות שיפרה את הביצועים של JavaScript. עם זאת, בגלל הטיפוס החלש וההתנהגות הדינמית של JavaScript, קשה למהדרי JIT ליצור קוד אופטימלי. כלומר, קצב העברת הנתונים הגולמי של JavaScript עדיין נמוך יותר בהשוואה לשפות כמו Java ו-C++. TypeScript מוסיף בטיחות סוגים ל-JavaScript, אבל מידע הסוגים הזה נועד להקל על הפיתוח, ולא לספק את סוגי ההבטחות שנדרשות לקומפיילרים כדי ליצור קוד אופטימלי. במקרים כמו Google Sheets, שבהם חישוב של גיליונות אלקטרוניים גדולים יכול להימשך עשרות שניות, JavaScript מהיר אבל לא מספיק מהיר.
הפתרון: WasmGC
WasmGC הוא תוסף למפרט הקיים של WebAssembly, שמוסיף את הפרימיטיבים שנדרשים כדי לקמפל שפות עם איסוף אשפה (כמו Java). לדוגמה, WasmGC מוסיף הוראות להגדרת סוגים ולהקצאת מבני נתונים שנאספים כזבל. WasmGC עומד לעשות לשפות עם איסוף אשפה מה ש-Wasm עשה ל-C++ (לדוגמה, Photoshop או Google Earth), כלומר להביא אותן לאינטרנט במהירות שקרובה למהירות המקורית. ב-Google, אנחנו מאמינים של-WasmGC יש פוטנציאל להשפיע אפילו יותר מ-Wasm, בגלל הפופולריות של שפות עם איסוף אשפה.
שותפים של Google Workspace עם Chrome
טיוטת המפרט של WasmGC MVP פורסמה בשנת 2019. בסוף שנת 2020, צוותים מ-Google Workspace ומ-Chrome שיתפו פעולה כדי להעריך את WasmGC באמצעות מנוע החישוב של Sheets. לצוות של Workspace שפועל בכמה פלטפורמות יש מומחיות רבה בבנייה ובאופטימיזציה של קומפיילרים וטרנספיילרים. זוהה ש-Sheets, שהוא חלק מ-Workspace, הוא מועמד אידיאלי להערכת WasmGC: הוא רגיש לביצועים ויש לו מנגנונים חזקים לאימות הביצועים והנכונות. צוות V8 ב-Chrome בונה ומבצע אופטימיזציה של זמן הריצה של WasmGC, וגם תורמים ל-Binaryen כדי לבצע אופטימיזציות מראש (AOT). בין Chrome ל-Workspace, יש את כל המומחיות שנדרשת כדי לבנות ולבצע אופטימיזציה של כלי WasmGC, עם Google Sheets כסביבת בדיקה אידיאלית.
אב הטיפוס הראשון
באמצע 2021, לצוותים היה מהדר Java ל-WasmGC שעובד. לקראת סוף אותה שנה, הייתה להם גרסת אב-טיפוס של Google Sheets שפועלת כ-WasmGC ומבצעת חישובים. במהלך הדרך, הם נתקלו באתגרים רבים. לא היו כלים ליצירת פרופילים ולשמירת תמונות מצב של ה-heap, והיה צורך לבנות אותם. ההטמעה הקיימת הסתמכה על ספריות JavaScript רבות, ולכן היה צריך למצוא או לכתוב תחליפים ל-WasmGC. בגלל האופי הניסיוני של המפרט, של הקומפיילר ושל הספריות החדשות, נדרש זמן רב כדי לוודא שמנוע החישוב של Wasm פועל בצורה נכונה. אבל מנגנוני האימות של Sheets עזרו מאוד שוב. בסופו של דבר, הצוותים הצליחו לגרום לכל המערכות לפעול, ונתוני הביצועים התחילו להגיע בתחילת 2022.
אופטימיזציות נוספות
בגרסה הראשונית של Sheets Wasm, ביצועי החישוב היו בערך פי שניים איטיים יותר מאשר ב-JavaScript. עם זאת, זה לא תוצאה רעה למפרט חדש, לקומפיילר חדש ולכמה ספריות חדשות. מנקודה זו, צוות Sheets התחיל לבצע אופטימיזציה. מתוך האופטימיזציות שנמצאו, אפשר לזהות כמה קטגוריות:
- שכפול של אופטימיזציות ליבה שכבר קיימות במכונה הווירטואלית של Java (JVM) וב-V8.
- שימוש בממשקי API של דפדפן שעברו אופטימיזציה גבוהה.
- הסרה של דפוסי קידוד ספציפיים ל-JavaScript.
קודם כל, צוות Sheets היה צריך לשכפל אופטימיזציות שכבר קיימות בשרשראות כלים אחרות. הדוגמה הטובה ביותר לכך היא אופטימיזציה של שליחת שיטות וירטואליות, שעברה אופטימיזציה על ידי JVM ו-V8 במשך זמן רב, אבל לא הייתה קיימת עבור WasmGC. הטמעה של הוספה לשורה (inlining) ספקולטיבית והסרת וירטואליזציה (devirtualization) – שני סוגים נפוצים מאוד של אופטימיזציות – קיצרה את זמן החישוב בכ-40% ב-Chrome.
שנית, יש מקרים שבהם ממשקי API של דפדפנים מגובים בהטמעות מקומיות שעברו אופטימיזציה, וקשה להתחרות בהן באמצעות Wasm. מחרוזות וביטויים רגולריים הן שתי דוגמאות טובות. באופן ספציפי, באמצעות ביטויים רגולריים, הצוות ראה שיפור של כמעט פי 100 במהירות של פעולות ביטויים רגולריים כשעבר מ-re2j (שקומפל ל-WasmGC) ל-RegExp browser API ב-Chrome, שיכול לקמפל כל ביטוי רגולרי לקוד מכונה משלו.
לבסוף, הם גילו שבעקבות שנים של אופטימיזציה, בסיס הקוד התאים יותר מדי ל-JavaScript. לדוגמה, הייתה להם מבנה נתונים מרכזי ב-Sheets שגרם לטשטוש ההבדלים בין מערכים לבין מפות. השיטה הזו יעילה ב-JavaScript, שממפה באופן אוטומטי מערכים דלילים, אבל היא איטית בפלטפורמות אחרות. לכן הם נאלצו לכתוב מחדש את הקוד בצורה שמתאימה ליותר פלטפורמות. עוד דבר שהצוות אוהב ב-WebAssembly: היא מאפשרת ליישומים חוצי-פלטפורמות להשיג ביצועים טובים באינטרנט. אתם לא צריכים להתאים את כל האפליקציה שלכם למוזרויות של JavaScript.
התוצאה הסופית
אחרי כל האופטימיזציות האלה, הביצועים של הגרסה הסופית של Sheets ב-WasmGC מהירים בערך פי שניים מ-JavaScript, וזה שיפור של פי ארבעה לעומת נקודת ההתחלה של הגרסה הראשונית של WasmGC.
סיכום
WasmGC היא טכנולוגיה מתקדמת שיכולה לשפר את הדרך שבה מפתחים יוצרים אפליקציות אינטרנט. בשנים הקרובות, אנחנו ב-Google מקווים ש-WasmGC יתקדם ויתמוך בריבוי שרשורים של זיכרון משותף, ושהביצועים של שרשור יחיד ישתפרו עוד יותר. אנחנו ממליצים לכל מפתחי האינטרנט לשקול שימוש ב-WasmGC בפרויקט הבא שלהם שדורש ביצועים גבוהים. אנחנו מזמינים אתכם להצטרף אלינו ולעזור לנו להפוך את האינטרנט למקום מהיר וחלק יותר!
תודות
תודה לכל מי שעבד על הטמעת WasmGC ומחקר המקרה הזה: Diwas Adhikary, Matthew Albright, Ksenia Bukina, Julien Dramaix, Asim Fazal, Michael Frederick, Goktug Gokdogan, Janice Gu, Adam Klein, Manos Koukoutos, Jakob Kummerow, Matthias Liedtke, Thomas Lively, Roberto Lublinerman, Vishrut Mehta, Thomas Nattestad, Josh Pearlstein, Joaquim Perotti, Chris Ruenes, Steven Saviano, Derek Schuff, Tim Sears, Michael Thomas, Yuan Tian, Philipp Weis, Mason Wu, Alon Zakai, and Emanuel Ziegler.