Google ชีตเป็นหนึ่งในผลิตภัณฑ์แรกๆ ของ Google ที่ใช้ WasmGC ใน Chrome การย้ายข้อมูลนี้ประกาศในปี 2022 และทีมชีตและ Chrome ได้ร่วมมือกันในด้านการกำหนดมาตรฐาน วิศวกรรม และเครื่องมือต่างๆ เพื่อให้ความคิดเห็นแบบเรียลไทม์เกี่ยวกับการเพิ่มประสิทธิภาพ การเป็นพาร์ทเนอร์ครั้งนี้เป็นตัวอย่างที่แสดงให้เห็นว่าทีมวิศวกรของ Google สามารถทำงานร่วมกับ Chrome ได้อย่างมีประสิทธิภาพเพื่อให้แอป Google จำนวนมากขึ้นทำงานบน WasmGC ได้
ความท้าทาย: JavaScript
เดิมทีเครื่องมือคำนวณของ Google ชีตเขียนด้วยภาษา Java และเปิดตัวในปี 2006 ในช่วงแรกๆ ของผลิตภัณฑ์ การคำนวณทั้งหมดจะเกิดขึ้นในเซิร์ฟเวอร์ อย่างไรก็ตาม ตั้งแต่ปี 2013 เครื่องมือนี้ทำงานในเบราว์เซอร์โดยใช้ JavaScript เดิมทีเราใช้ Google Web Toolkit (GWT) และต่อมาก็ใช้ Java to Closure JavaScript Transpiler (J2CL) เครื่องมือคำนวณ JavaScript ทำงานใน Web Worker และสื่อสารกับชุดข้อความหลักโดยใช้ MessageChannel
การย้ายข้อมูลผู้ใช้จากเซิร์ฟเวอร์ไปยังเครื่องมือคำนวณเวอร์ชัน JavaScript (และต่อมาคือจาก GWT ไปยัง J2CL) เป็นงานที่สำคัญซึ่งต้องมีการตรวจสอบอย่างรอบคอบ ทีมชีตได้พัฒนากลไกการตรวจสอบภายในเพื่อให้มั่นใจว่าเครื่องมือคำนวณ JavaScript จะให้ผลลัพธ์ที่เหมือนกับเวอร์ชัน Java ทุกประการ กลไกนี้สามารถประมวลผลคลังข้อมูลชีตขนาดใหญ่และตรวจสอบว่าผลลัพธ์เหมือนกันในเครื่องมือคำนวณหลายเวอร์ชัน ทีมชีตใช้เครื่องมือนี้เป็นประจำเพื่อตรวจสอบการเปลี่ยนแปลงในชีต แต่ทีมไม่ได้เปรียบเทียบเฉพาะผลลัพธ์ของการคำนวณเหล่านั้นเท่านั้น แต่ยังเปรียบเทียบประสิทธิภาพระหว่าง JavaScript ในไคลเอ็นต์และ Java ในเซิร์ฟเวอร์ด้วย โดยพบว่าเครื่องมือคำนวณเวอร์ชัน JavaScript ช้ากว่าเวอร์ชัน Java มากกว่า 3 เท่า
เหตุใด JavaScript จึงช้ากว่า Java
JavaScript เป็นภาษาแบบไดนามิกที่พิมพ์แบบหลวมๆ ซึ่งทำงานได้อย่างรวดเร็ว การลงทุนอย่างมากในคอมไพเลอร์แบบทันที (JIT) (เช่น Maglev, Sparkplug และ Turbofan) ในช่วง 15 ปีที่ผ่านมาได้ช่วยเพิ่มประสิทธิภาพของ JavaScript อย่างไรก็ตาม ประเภทที่ยืดหยุ่นและลักษณะการทำงานแบบไดนามิกของ JavaScript ทำให้คอมไพเลอร์ JIT สร้างโค้ดที่เหมาะสมที่สุดได้ยาก ซึ่งหมายความว่า JavaScript ยังคงมีอัตราการรับส่งข้อมูลดิบต่ำกว่าภาษาอย่าง Java และ C++ TypeScript เพิ่มความปลอดภัยของประเภทให้กับ JavaScript แต่ข้อมูลประเภทดังกล่าวออกแบบมาเพื่อให้การพัฒนาเป็นเรื่องง่ายขึ้น ไม่ใช่เพื่อให้การรับประกันประเภทต่างๆ ที่คอมไพเลอร์จำเป็นต้องใช้ในการสร้างโค้ดที่เหมาะสมที่สุด ในกรณีต่างๆ เช่น Google ชีต ซึ่งสเปรดชีตขนาดใหญ่อาจใช้เวลาหลายสิบวินาทีในการคำนวณ JavaScript นั้นรวดเร็ว แต่ก็ยังไม่เร็วพอ
โซลูชัน: WasmGC
WasmGC เป็นส่วนขยายของข้อกำหนด WebAssembly ที่มีอยู่ ซึ่งจะเพิ่ม Primitive ที่จำเป็นในการคอมไพล์ภาษาที่มีการเก็บขยะ (เช่น Java) เช่น WasmGC จะเพิ่มวิธีการกำหนดประเภทและจัดสรรโครงสร้างข้อมูลที่รวบรวมขยะ WasmGC พร้อมที่จะทำในภาษาที่มีการเก็บขยะเช่นเดียวกับที่ Wasm ทำกับ C++ (เช่น Photoshop หรือ Google Earth) นั่นคือการนำภาษาเหล่านั้นมาไว้บนเว็บด้วยความเร็วใกล้เคียงกับความเร็วของภาษาเครื่อง ที่ Google เราเชื่อว่า WasmGC มีศักยภาพที่จะส่งผลกระทบมากกว่า Wasm เนื่องจากความนิยมของภาษาที่มีการเก็บขยะ
Google Workspace ทำงานร่วมกับ Chrome
ร่างข้อกำหนด MVP ของ WasmGC เผยแพร่ในปี 2019 ในช่วงปลายปี 2020 Google Workspace และ Chrome ได้ร่วมมือกันประเมิน WasmGC โดยใช้เครื่องมือคำนวณของชีต ทีมแบบหลายแพลตฟอร์มของ Workspace มีความเชี่ยวชาญอย่างมากในการสร้างและเพิ่มประสิทธิภาพคอมไพเลอร์และทรานสไพเลอร์ Sheets ซึ่งเป็นส่วนหนึ่งของ Workspace ได้รับการระบุว่าเป็นตัวเลือกที่เหมาะสำหรับการประเมิน WasmGC เนื่องจากมีความไวต่อประสิทธิภาพและมีกลไกการตรวจสอบประสิทธิภาพและความถูกต้องที่แข็งแกร่ง Chrome มีทีม V8 ที่สร้างและเพิ่มประสิทธิภาพรันไทม์ WasmGC รวมถึงผู้มีส่วนร่วมใน Binaryen เพื่อสร้างการเพิ่มประสิทธิภาพแบบ AOT (Ahead-Of-Time) Chrome และ Workspace มีความเชี่ยวชาญทั้งหมดที่จำเป็นต่อการสร้างและเพิ่มประสิทธิภาพเครื่องมือ WasmGC โดยมี Google ชีตเป็นแพลตฟอร์มทดสอบที่เหมาะสม
ต้นแบบแรก
ภายในกลางปี 2021 ทีมก็มีคอมไพเลอร์ Java เป็น WasmGC ที่ใช้งานได้ ในช่วงปลายปีเดียวกันนั้น ทีมได้สร้าง Google ชีตเวอร์ชันต้นแบบที่ทำงานเป็น WasmGC และทำการคำนวณ แต่ระหว่างทางก็พบกับความท้าทายมากมาย ไม่มีเครื่องมือสำหรับการสร้างโปรไฟล์และการถ่ายฮีปดัมพ์ จึงต้องสร้างขึ้นมา การติดตั้งใช้งานที่มีอยู่ต้องอาศัยไลบรารี JavaScript จำนวนมาก ซึ่งต้องหาหรือเขียนไลบรารีทดแทนสำหรับ WasmGC การตรวจสอบความถูกต้องของเครื่องมือคำนวณ Wasm เป็นงานที่ต้องใช้เวลานานเนื่องจากลักษณะการทดลองของข้อกำหนด คอมไพเลอร์ และไลบรารีใหม่ แต่กลไกการตรวจสอบของชีตก็มีประโยชน์อย่างมากอีกครั้ง ในที่สุดทีมก็ทำให้ทุกอย่างทำงานได้ และข้อมูลประสิทธิภาพก็เริ่มเข้ามาในช่วงต้นปี 2022
การเพิ่มประสิทธิภาพเพิ่มเติม
ชีต Wasm เวอร์ชันแรกแสดงประสิทธิภาพการคำนวณที่ช้ากว่า JavaScript ประมาณ 2 เท่า อย่างไรก็ตาม นี่ไม่ใช่ผลลัพธ์ที่ไม่ดีสำหรับข้อกำหนดใหม่ คอมไพเลอร์ใหม่ และไลบรารีใหม่หลายรายการ จากจุดนี้ ทีมชีตจึงเริ่มเพิ่มประสิทธิภาพ การเพิ่มประสิทธิภาพที่พบมีอยู่ 2-3 หมวดหมู่ ดังนี้
- การจำลองการเพิ่มประสิทธิภาพหลักที่มีอยู่ในเครื่องเสมือน Java (JVM) และใน V8 อยู่แล้ว
- การใช้ API ของเบราว์เซอร์ที่ได้รับการเพิ่มประสิทธิภาพอย่างสูง
- การนำรูปแบบการเขียนโค้ดที่เฉพาะเจาะจงสำหรับ JavaScript ออก
ประการแรก ทีมชีตต้องจำลองการเพิ่มประสิทธิภาพที่มีอยู่ในเชนเครื่องมืออื่นๆ อยู่แล้ว ตัวอย่างที่ดีที่สุดของเรื่องนี้คือการเพิ่มประสิทธิภาพการส่งเมธอดเสมือน ซึ่ง JVM และ V8 ได้เพิ่มประสิทธิภาพมานานแล้ว แต่ไม่มีอะไรสำหรับ WasmGC การใช้การแทรกแบบคาดการณ์และการยกเลิกการจำลอง ซึ่งเป็นการเพิ่มประสิทธิภาพที่พบได้ทั่วไป 2 อย่าง ช่วยลดเวลาในการคำนวณใน Chrome ได้ประมาณ 40%
ประการที่ 2 มีกรณีที่ API ของเบราว์เซอร์ได้รับการสนับสนุนจากการติดตั้งใช้งานแบบเนทีฟที่ได้รับการเพิ่มประสิทธิภาพ ซึ่งยากที่จะแข่งขันด้วยการใช้ Wasm สตริงและนิพจน์ทั่วไปเป็นตัวอย่างที่ดี 2 อย่าง กล่าวคือ เมื่อใช้นิพจน์ทั่วไป ทีมพบว่าการดำเนินการนิพจน์ทั่วไปเร็วขึ้นเกือบ 100 เท่าเมื่อเปลี่ยนจาก re2j (คอมไพล์เป็น WasmGC) ไปใช้เบราว์เซอร์ API RegExp ใน Chrome ซึ่งสามารถคอมไพล์นิพจน์ทั่วไปแต่ละรายการเป็นโค้ดเครื่องของตัวเองได้
สุดท้ายนี้ ทีมยังพบว่าการเพิ่มประสิทธิภาพมาหลายปีทำให้โค้ดเบสปรับให้เหมาะกับ JavaScript มากเกินไป เช่น มีโครงสร้างข้อมูลหลักในชีตที่ทำให้เกิดความสับสนระหว่างอาร์เรย์และแผนที่ ซึ่งมีประสิทธิภาพใน JavaScript ซึ่งจะจำลองอาร์เรย์แบบกระจัดกระจายเป็นแผนที่โดยอัตโนมัติ แต่จะช้าในแพลตฟอร์มอื่นๆ จึงต้องเขียนโค้ดใหม่ในลักษณะที่ไม่ขึ้นอยู่กับแพลตฟอร์ม อีกสิ่งหนึ่งที่ทีมชอบเกี่ยวกับ WebAssembly คือการช่วยให้แอปพลิเคชันหลายแพลตฟอร์มมีประสิทธิภาพที่ดีบนเว็บได้ง่ายขึ้น คุณไม่จำเป็นต้องปรับทั้งแอปพลิเคชันให้เข้ากับลักษณะเฉพาะของ JavaScript
ผลลัพธ์สุดท้าย
หลังจากการเพิ่มประสิทธิภาพทั้งหมดนี้ ชีตเวอร์ชัน WasmGC สุดท้ายจะมีความเร็วในการคำนวณเร็วกว่า JavaScript ประมาณ 2 เท่า ซึ่งแสดงถึงการปรับปรุง 4 เท่าจากจุดเริ่มต้นของ 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 และ Emanuel Ziegler