Google ชีตเป็นหนึ่งในผลิตภัณฑ์แรกๆ ที่ Google ใช้ WasmGC ใน Chrome เราได้ประกาศการเปลี่ยนแปลงนี้ในปี 2022 โดยทีมชีตและ Chrome ได้ร่วมมือกันสร้างมาตรฐาน วิศวกรรม และเครื่องมือเพื่อให้ความคิดเห็นเกี่ยวกับการเพิ่มประสิทธิภาพแบบเรียลไทม์ การเป็นพาร์ทเนอร์ทางธุรกิจครั้งนี้สร้างต้นแบบให้ทีมวิศวกรของ Google ทำงานร่วมกับ Chrome อย่างมีประสิทธิภาพเพื่อให้แอป Google จำนวนมากขึ้นทำงานบน WasmGC ได้
ความท้าทาย: JavaScript
เครื่องมือการคำนวณของ Google ชีตเดิมเขียนขึ้นใน Java และเปิดตัวในปี 2006 ในช่วงแรกของการใช้ผลิตภัณฑ์ การคำนวณทั้งหมดจะเกิดขึ้นบนเซิร์ฟเวอร์ อย่างไรก็ตาม ตั้งแต่ปี 2013 เป็นต้นมา เครื่องมือได้ทำงานในเบราว์เซอร์โดยใช้ JavaScript ซึ่งแต่เดิมสามารถทำได้ผ่าน Google Web Toolkit (GWT) และภายหลังผ่านการแปลง Java to Closure JavaScript (J2CL) เครื่องมือการคำนวณ JavaScript จะทำงานใน Web Worker และสื่อสารกับเทรดหลักโดยใช้ MessageChannel
การย้ายข้อมูลผู้ใช้จากเซิร์ฟเวอร์ไปยังเครื่องมือการคำนวณเวอร์ชัน JavaScript (และเปลี่ยนจาก GWT ไปเป็น J2CL) เป็นการดำเนินการสำคัญที่ต้องมีการตรวจสอบอย่างรอบคอบ ทีมชีตได้พัฒนากลไกการตรวจสอบภายในเพื่อให้มั่นใจว่าเครื่องมือการคำนวณ JavaScript นี้จะให้ผลลัพธ์ที่ตรงกับเวอร์ชัน Java ทุกประการ กลไกนี้สามารถประมวลผลคลังข้อมูลขนาดใหญ่ของชีตและตรวจสอบว่าผลลัพธ์เหมือนกันในกลไกการคำนวณหลายเวอร์ชัน ทีมชีตใช้เครื่องมือนี้เป็นประจำเพื่อตรวจสอบการเปลี่ยนแปลงในชีต แต่ทีมไม่เพียงแต่เปรียบเทียบผลการคำนวณเหล่านั้นเท่านั้น แต่ยังเปรียบเทียบประสิทธิภาพระหว่าง JavaScript ในไคลเอ็นต์กับ Java บนเซิร์ฟเวอร์อีกด้วย และพบว่าเครื่องมือคำนวณเวอร์ชัน JavaScript ช้ากว่าเวอร์ชัน Java มากกว่า 3 เท่า
ทำไม JavaScript จึงช้ากว่า Java
JavaScript ทำงานเร็วสำหรับภาษาแบบไดนามิกที่มีการพิมพ์แบบหลวมๆ การลงทุนอย่างมากกับคอมไพเลอร์แบบ Just-In-Time (JIT) (เช่น Maglev, Sparkบอกเล่า และ 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 ของ WaasmGC เผยแพร่ในปี 2019 ในช่วงปลายปี 2020 Google Workspace และ Chrome ได้ร่วมมือกันประเมิน WasmGC โดยใช้เครื่องมือการคํานวณของชีต ทีมหลายแพลตฟอร์มของ Workspace มีความเชี่ยวชาญอย่างมากในการสร้างและเพิ่มประสิทธิภาพให้กับคอมไพเลอร์และตัวเปลี่ยนรูปแบบ ชีตซึ่งเป็นส่วนหนึ่งของ Workspace ได้รับการระบุว่าเป็นตัวเลือกที่ยอดเยี่ยมสำหรับการประเมิน WasmGC เพราะมีความละเอียดอ่อนด้านประสิทธิภาพ รวมถึงมีกลไกการตรวจสอบความถูกต้องและประสิทธิภาพที่แข็งแกร่ง Chrome มีทีม V8 ที่จะสร้างและเพิ่มประสิทธิภาพรันไทม์ WasmGC รวมถึงเป็นผู้มีส่วนร่วมใน Branchen ในการสร้างการเพิ่มประสิทธิภาพล่วงหน้า (AOT) การใช้ Chrome และ Workspace ต้องอาศัยความเชี่ยวชาญทุกอย่างที่จำเป็นในการสร้างและเพิ่มประสิทธิภาพเครื่องมือ WasmGC และใช้ Google ชีตเป็นตัวอย่างการทดสอบที่ดีที่สุด
ต้นแบบแรก
ในช่วงกลางปี 2021 ทีมได้ใช้คอมไพเลอร์ Java ไปยัง WasmGC ที่ทํางานอยู่ ในช่วงปลายปีเดียวกัน บริษัทได้ใช้ Google ชีตเวอร์ชันต้นแบบที่ทำงานเป็น WasmGC และทำการคำนวณ ระหว่างทางมีภารกิจมากมายที่อยากจะผลัดกันทำ ไม่มีเครื่องมือสำหรับการทำโปรไฟล์และนำฮีปดัมป์มาใช้จริงและต้องสร้างขึ้นเอง การใช้งานที่มีอยู่อาศัยไลบรารี JavaScript จำนวนมากซึ่งจำเป็นต้องพบหรือเขียนการแทนที่สำหรับ WasmGC การตรวจสอบความถูกต้องของเครื่องมือการคำนวณ Wasm เป็นงานที่ต้องใช้เวลามาก เนื่องจากลักษณะการทดลองของข้อกำหนดเฉพาะ คอมไพเลอร์ และไลบรารีใหม่ แต่กลไกการตรวจสอบความถูกต้องของชีตก็มีประโยชน์อย่างมากเช่นกัน ท้ายที่สุด ทีมก็ใช้งานทุกอย่างได้เป็นอย่างดี และข้อมูลประสิทธิภาพก็เริ่มเปิดตัวในช่วงต้นปี 2022
การเพิ่มประสิทธิภาพเพิ่มเติม
ชีต Wasm เวอร์ชันแรกแสดงประสิทธิภาพการคำนวณช้ากว่า JavaScript ประมาณ 2 เท่า อย่างไรก็ตาม นี่ไม่ใช่ผลลัพธ์ที่ไม่ดีสำหรับข้อกำหนดใหม่ คอมไพเลอร์ใหม่ และไลบรารีใหม่อีกหลายรายการ จากจุดนี้ ทีมชีตจึงเริ่มเพิ่มประสิทธิภาพ พวกเขาพบว่าการเพิ่มประสิทธิภาพที่พบมี 2-3 หมวดหมู่ปรากฏขึ้น ดังนี้
- จำลองการเพิ่มประสิทธิภาพหลักที่มีอยู่แล้วใน Java Virtual Machine (JVM) และ V8
- ใช้ API เบราว์เซอร์ที่เพิ่มประสิทธิภาพอย่างมาก
- กำลังนำรูปแบบการเขียนโค้ดที่ใช้เฉพาะ JavaScript ออก
ก่อนอื่น ทีมชีตต้องจําลองการเพิ่มประสิทธิภาพที่มีอยู่แล้วใน Toolchain อื่นๆ ตัวอย่างที่ดีที่สุดของปัญหานี้คือการเพิ่มประสิทธิภาพการส่งเมธอดเสมือนจริง ซึ่งได้รับการเพิ่มประสิทธิภาพโดย JVM และ V8 มาอย่างยาวนาน แต่ WasmGC ยังไม่มีสิ่งใดเกิดขึ้น การใช้อินไลน์แบบคาดเดาและการพัฒนาระบบ ซึ่งเป็นการเพิ่มประสิทธิภาพ 2 แบบที่ใช้กันทั่วไป ทำให้ Chrome ใช้เวลาคำนวณได้เร็วขึ้นประมาณ 40%
ประการที่ 2 มีบางกรณีที่ API ของเบราว์เซอร์ได้รับการสนับสนุนโดยการใช้งานที่มาพร้อมเครื่องที่เพิ่มประสิทธิภาพแล้ว ซึ่งแข่งขันกับการใช้ Wasm ได้ยาก สตริงและนิพจน์ทั่วไปเป็นตัวอย่างที่ดี 2 ตัวอย่าง โดยเฉพาะอย่างยิ่ง เมื่อใช้นิพจน์ทั่วไป ทีมพบว่าการดำเนินการกับนิพจน์ทั่วไปจะเร็วขึ้นเกือบ 100 เท่าเมื่อเปลี่ยนจาก re2j (คอมไพล์เป็น WasmGC) เป็น API ของเบราว์เซอร์ RegExp ใน Chrome ซึ่งสามารถรวบรวมนิพจน์ทั่วไปแต่ละรายการเป็นรหัสเครื่องของตัวเอง
สุดท้าย พวกเขาพบว่าการเพิ่มประสิทธิภาพเป็นเวลาหลายปีทำให้โค้ดเบสรองรับ JavaScript มากเกินไป เช่น มีโครงสร้างข้อมูลหลักในชีตซึ่งเบลอเส้นระหว่างอาร์เรย์และแผนที่ วิธีนี้มีประสิทธิภาพใน JavaScript ซึ่งจะจำลองอาร์เรย์แบบกระจัดกระจายเป็นแผนที่โดยอัตโนมัติ แต่ทำงานช้าในแพลตฟอร์มอื่น ทีมจึงต้องเขียนโค้ดใหม่ให้ไม่ยึดติดกับแพลตฟอร์มมากขึ้น อีกสิ่งหนึ่งที่ทีมชอบเกี่ยวกับ WebAssembly คือช่วยให้แอปพลิเคชันหลายแพลตฟอร์มทำงานได้อย่างมีประสิทธิภาพในเว็บได้ง่ายขึ้น คุณไม่จำเป็นต้องทำให้ทั้งแอปพลิเคชันของคุณมีรูปแบบไม่ถูกต้องของ JavaScript
ผลขั้นสุดท้าย
หลังจากการเพิ่มประสิทธิภาพทั้งหมดนี้แล้ว ชีตเวอร์ชันสุดท้ายของ WasmGC มีประสิทธิภาพการคำนวณเพิ่มขึ้นประมาณเร็วขึ้น 2 เท่าจาก JavaScript ซึ่งแสดงถึงการปรับปรุงขึ้น 4 เท่าจากจุดเริ่มต้นของ WasmGC เวอร์ชันแรก
บทสรุป
WasmGC เป็นเทคโนโลยีทรงพลังที่มีศักยภาพในการพัฒนาวิธีที่นักพัฒนาซอฟต์แวร์สร้างเว็บแอปพลิเคชัน ในช่วง 2-3 ปีที่ผ่านมา ทาง Google เราหวังว่าจะได้เห็น WasmGC ก้าวหน้าเพื่อรองรับการใช้ชุดข้อความร่วมกันที่มีหน่วยความจำแบบแชร์ และปรับปรุงประสิทธิภาพเทรดเดี่ยวเพิ่มเติมอีกขั้น เราขอแนะนำให้นักพัฒนาเว็บทั้งหมดพิจารณาใช้ WasmGC สำหรับโครงการประสิทธิภาพสูงถัดไปของตน มาร่วมมือกับเราเพื่อทำให้เว็บเป็นที่ที่เร็วและราบรื่นยิ่งขึ้นไปด้วยกัน
กิตติกรรมประกาศ
ขอขอบคุณ ผู้ให้ความช่วยเหลือในการใช้งาน WasmGC และกรณีศึกษานี้ Diwas Adhikary, Matthew Albright, Ksenia Bukina, Julien Dramaix, Asim Fazal, Michael Frederick, Goktug Gokdogan, Janice Gu Adam Kleinas, Janice Gu