Google ชีตเป็นหนึ่งในผลิตภัณฑ์แรกๆ ของ Google ที่ใช้ WasmGC ใน Chrome เราได้ประกาศการดำเนินการนี้ไปเมื่อปี 2022 และทีมชีตและทีม 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 กลไกนี้สามารถประมวลผลชุดชีตขนาดใหญ่และตรวจสอบว่าผลลัพธ์เหมือนกันระหว่างเครื่องมือคำนวณหลายเวอร์ชัน ทีมชีตใช้เครื่องมือนี้เป็นประจำเพื่อตรวจสอบการเปลี่ยนแปลงในชีต แต่ทีมไม่ได้แค่เปรียบเทียบผลลัพธ์ของการคํานวณเหล่านั้นเท่านั้น แต่ยังเปรียบเทียบประสิทธิภาพระหว่าง 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 ที่มีอยู่ ซึ่งเพิ่มองค์ประกอบพื้นฐานที่จำเป็นในการคอมไพล์ภาษาที่มีการเก็บขยะ (เช่น Java) เช่น WasmGC จะเพิ่มคำสั่งสำหรับการกำหนดประเภทและการจัดสรรโครงสร้างข้อมูลที่เก็บขยะ WasmGC กำลังจะทําในภาษาที่มีการเก็บขยะสิ่งที่ Wasm ทํากับ C++ (เช่น Photoshop หรือ Google Earth) ซึ่งก็คือนําภาษาเหล่านั้นมายังเว็บด้วยความเร็วใกล้เคียงกับเนทีฟ Google เชื่อว่า WasmGC มีศักยภาพที่จะส่งผลกระทบได้มากกว่า Wasm เนื่องจากภาษาที่มีการรวบรวมขยะได้รับความนิยม
Google Workspace ร่วมมือกับ Chrome
ข้อกำหนดฉบับร่าง MVP ของ WasmGC เผยแพร่เมื่อปี 2019 เมื่อช่วงปลายปี 2020 Google Workspace และ Chrome ได้ร่วมมือกันประเมิน WasmGC โดยใช้เครื่องมือคำนวณของชีต ทีมข้ามแพลตฟอร์มของ Workspace มีความเชี่ยวชาญอย่างมากในการสร้างและเพิ่มประสิทธิภาพคอมไพเลอร์และทรานสไพเลอร์ ชีตซึ่งเป็นส่วนหนึ่งของ Workspace ได้รับการระบุว่าเป็นตัวเลือกที่เหมาะสมสําหรับการประเมิน WasmGC เนื่องจากชีตมีความไวต่อประสิทธิภาพ และมีกลไกการตรวจสอบประสิทธิภาพและความถูกต้องที่มีประสิทธิภาพ Chrome มีทีม V8 เพื่อสร้างและเพิ่มประสิทธิภาพรันไทม์ WasmGC รวมถึงผู้มีส่วนร่วมใน Binaryen เพื่อสร้างการเพิ่มประสิทธิภาพล่วงหน้า (AOT) Chrome และ Workspace มีองค์ความรู้ทั้งหมดที่จำเป็นต่อการสร้างและเพิ่มประสิทธิภาพเครื่องมือทางเทคนิค WasmGC โดยมี Google ชีตเป็นแพลตฟอร์มทดสอบที่เหมาะเจาะ
ต้นแบบแรก
ภายในช่วงกลางปี 2021 ทีมมีคอมไพเลอร์ Java เป็น WasmGC ที่ใช้งานได้ ช่วงปลายปีเดียวกันนั้น ทีมได้ Google ชีตเวอร์ชันต้นแบบซึ่งทำงานเป็น WasmGC และทำการคํานวณ ตลอดเส้นทางนี้ พวกเขาพบเจอกับความท้าทายมากมาย เครื่องมือสำหรับการจัดโปรไฟล์และการทำ Dump กองขยะยังไม่มีอยู่และต้องสร้างขึ้น การใช้งานที่มีอยู่อาศัยไลบรารี JavaScript จำนวนมาก ซึ่งต้องหาหรือเขียนรายการที่จะมาแทนสำหรับ WasmGC การตรวจสอบความถูกต้องของเครื่องมือคำนวณ Wasm นั้นใช้เวลานานเนื่องจากข้อกำหนด คอมไพเลอร์ และไลบรารีใหม่เป็นลักษณะการทดลอง แต่กลไกการตรวจสอบของชีตก็มีประโยชน์อย่างมากอีกครั้ง ในที่สุดทีมก็ทําให้ทุกอย่างทํางานได้ และข้อมูลประสิทธิภาพก็เริ่มเข้ามาในช่วงต้นปี 2022
การเพิ่มประสิทธิภาพเพิ่มเติม
ชีต Wasm เวอร์ชันแรกมีประสิทธิภาพการคํานวณที่ช้ากว่า JavaScript ประมาณ 2 เท่า อย่างไรก็ตาม ผลลัพธ์นี้ไม่ใช่ผลลัพธ์ที่ไม่ดีสำหรับข้อกำหนดใหม่ คอมไพเลอร์ใหม่ และไลบรารีใหม่หลายรายการ จากจุดนี้ ทีมชีตก็เริ่มเพิ่มประสิทธิภาพ การเพิ่มประสิทธิภาพที่พบมี 2-3 หมวดหมู่ ได้แก่
- การทำซ้ำการเพิ่มประสิทธิภาพหลักที่มีอยู่แล้วในเครื่องเสมือน Java (JVM) และใน V8
- การใช้ API เบราว์เซอร์ที่เพิ่มประสิทธิภาพสูง
- นำรูปแบบการเขียนโค้ดเฉพาะ JavaScript ออก
ประการแรก ทีมชีตต้องจำลองการเพิ่มประสิทธิภาพที่มีอยู่แล้วในเครื่องมือทางเทคนิคอื่นๆ ตัวอย่างที่ดีที่สุดของเรื่องนี้คือการเพิ่มประสิทธิภาพการส่งผ่านเมธอดเสมือน ซึ่ง JVM และ V8 เพิ่มประสิทธิภาพมาอย่างยาวนานแล้ว แต่ไม่มีการดำเนินการใดๆ สำหรับ WasmGC การใช้การฝังแบบคาดการณ์และการแปลงจากเวอร์ชวล ซึ่งเป็นการเพิ่มประสิทธิภาพที่พบได้ทั่วไป 2 ประการ ช่วยให้เวลาในการคํานวณเร็วขึ้นประมาณ 40% ใน Chrome
ประการที่ 2 มีบางกรณีที่ API ของเบราว์เซอร์ได้รับการสนับสนุนจากการใช้งานแบบเนทีฟที่ได้รับการเพิ่มประสิทธิภาพ ซึ่งยากที่จะแข่งขันได้โดยใช้ Wasm สตริงและนิพจน์ทั่วไปเป็นตัวอย่างที่ดี 2 ตัวอย่าง โดยเฉพาะอย่างยิ่งสำหรับนิพจน์ทั่วไป ทีมพบว่าการดำเนินการนิพจน์ทั่วไปเร็วขึ้นเกือบ 100 เท่าเมื่อเปลี่ยนจาก re2j (คอมไพล์เป็น WasmGC) เป็น RegExp browser API ใน 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