WebAssembly 3.0 ได้เปิดตัวอย่างเป็นทางการในฐานะมาตรฐานใหม่ โดยนำมาซึ่งคุณสมบัติสำคัญต่างๆ เช่น การรองรับหน่วยความจำ 64-bit และการจัดการขยะ อย่างไรก็ตาม การเปิดตัวครั้งนี้ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนนักพัฒนาเกี่ยวกับการลดลงของประสิทธิภาพและการขาดหายไปอย่างต่อเนื่องของการเข้าถึง DOM โดยตรง
คุณสมบัติหลักของ WebAssembly 3.0:
- พื้นที่แอดเดรส 64 บิต: ขยายจาก 4GB เป็น 16 exabytes (เว็บจำกัดที่ 16GB)
- หน่วยความจำหลายตัว: โมดูลเดียวสามารถประกาศและเข้าถึงออบเจ็กต์หน่วยความจำหลายตัวได้
- การจัดการขยะ: ระบบจัดการหน่วยความจำในตัวสำหรับภาษาระดับสูง
- การอ้างอิงแบบมีประเภท: ระบบประเภทที่ปรับปรุงแล้วพร้อมการแบ่งประเภทย่อยและการเรียกซ้ำ
- การเรียกใช้ฟังก์ชันแบบ Tail calls: การเรียกใช้ฟังก์ชันที่ประหยัดพื้นที่ stack
- การจัดการข้อยกเว้น: การสนับสนุนข้อยกเว้นแบบดั้งเดิมภายใน WebAssembly
- คำสั่งเวกเตอร์แบบผ่อนคลาย: การดำเนินการ SIMD ที่ปรับปรุงประสิทธิภาพ
- โปรไฟล์แบบกำหนดได้: การประมวลผลที่สามารถทำซ้ำได้สำหรับระบบ blockchain/replay
 |
|---|
| การประกาศ WebAssembly 30 พร้อมเน้นฟีเจอร์ใหม่อย่างหน่วยความจำ 64 บิตและ garbage collection |
หน่วยความจำ 64-bit มาพร้อมกับต้นทุนด้านประสิทธิภาพ
คุณสมบัติที่ถูกคาดหวังมากที่สุด - พื้นที่แอดเดรส 64-bit - ช่วยให้แอปพลิเคชันสามารถเข้าถึงหน่วยความจำได้ถึง 16 exabyte ในทางทฤษฎี โดยขยายจากขีดจำกัดเดิมที่ 4 gigabyte ความก้าวหน้านี้มีประโยชน์อย่างยิ่งต่อแอปพลิเคชันแก้ไขวิดีโอและเว็บแอปที่ซับซ้อนอย่าง Figma ซึ่งจัดการไฟล์ที่มีเลเยอร์มากกว่าหนึ่งล้านชั้น อย่างไรก็ตาม นักพัฒนากำลังค้นพบข้อเสียด้านประสิทธิภาพที่สำคัญ การทดสอบประสิทธิภาพเบื้องต้นแสดงให้เห็นว่า WebAssembly 64-bit สามารถทำงานได้ช้ากว่าเวอร์ชัน 32-bit ตั้งแต่ 10% ถึง 100% โดยแอปพลิเคชันบางตัวประสบกับการชะลอตัวถึง 2 เท่า การลดลงของประสิทธิภาพเกิดจากข้อกำหนดการตรวจสอบขอบเขตเพิ่มเติมที่ไม่จำเป็นในการใช้งาน 32-bit ซึ่งรันไทม์สามารถจัดสรรพื้นที่แอดเดรส 4GB เต็มได้
การตรวจสอบขอบเขต: คุณสมบัติด้านความปลอดภัยที่ตรวจสอบการเข้าถึงหน่วยความจำอยู่ในขีดจำกัดที่อนุญาตเพื่อป้องกันการขัดข้องและช่องโหว่ด้านความปลอดภัย
การเปรียบเทียบผลกระทบต่อประสิทธิภาพ:
| คุณสมบัติ | ผลกระทบต่อประสิทธิภาพ | เหตุผล |
|---|---|---|
| หน่วยความจำ 64-bit | ช้าลง 10-100% | ต้องการการตรวจสอบขอบเขตเพิ่มเติม |
| หน่วยความจำ 32-bit | เป็นมาตรฐานอ้างอิง | สามารถละเว้นการตรวจสอบขอบเขตบนโฮสต์ 64-bit ได้ |
| WebAssembly GC | อาจเร็วขึ้น | ไม่จำเป็นต้องมี GC runtime ที่ส่งมาด้วย |
| หน่วยความจำหลายตัว | แปรผันได้ | ขึ้นอยู่กับรูปแบบการเข้าถึงหน่วยความจำ |
การจัดการขยะเปิดประตูสู่ภาษาระดับสูง
WebAssembly 3.0 แนะนำการรองรับการจัดการขยะแบบบิวท์อิน ทำให้ภาษาต่างๆ เช่น Java, Kotlin, Scala และ Dart สามารถทำงานได้อย่างมีประสิทธิภาพมากขึ้นโดยไม่ต้องส่งระบบจัดการหน่วยความจำของตัวเอง ชุมชนมองว่านี่เป็นตัวเปลี่ยนเกมสำหรับการลดขนาดบันเดิลและปรับปรุงประสิทธิภาพสำหรับภาษาที่มีการจัดการขยะ อย่างไรก็ตาม นักพัฒนาบางคนกังวลเกี่ยวกับความเข้าใจผิด โดยสังเกตว่านี่ไม่ใช่วิธีแก้ปัญหาที่สมบูรณ์แบบสำหรับการพอร์ตภาษาระดับสูงใดๆ WebAssembly GC ได้รับการออกแบบให้อยู่ในระดับต่ำโดยเจตนา ต้องการการออกแบบคอมไพเลอร์อย่างระมัดระวังเพื่อใช้ประโยชน์จากประเภท struct และ array
สถานะการรองรับภาษา:
- ขณะนี้รองรับด้วย GC: Java, OCaml, Scala, Kotlin, Scheme, Dart
- ยังคงมีความท้าทาย: C (ขาดการรองรับ ref/interior pointer), Go (ไม่เข้ากันกับ runtime)
- ไม่ได้รับผลกระทบ: C, C++, Rust, Zig (ไม่ใช้คุณสมบัติ GC)
การเข้าถึง DOM ยังคงเป็นชิ้นส่วนที่หายไป
บางทีการถกเถียงที่ถกเถียงกันมากที่สุดคือการขาดการเข้าถึง DOM โดยตรงของ WebAssembly ที่ยังคงดำเนินต่อไป นักพัฒนาจำนวนมากแสดงความไม่พอใจที่พวกเขายังคงต้องใช้ JavaScript เป็นตัวกลางในการจัดการองค์ประกอบของหน้าเว็บ แม้ว่าจะมีวิธีแก้ไขผ่าน JavaScript bindings แต่นักพัฒนาโต้แย้งว่าสิ่งนี้ขัดกับจุดประสงค์ของการใช้ภาษาทางเลือกสำหรับการพัฒนาเว็บ ผู้จำหน่ายเบราว์เซอร์ยืนยันว่าการเข้าถึง DOM โดยตรงจะสร้างความเสี่ยงด้านความปลอดภัยและความซับซ้อนในการใช้งาน โดยชอบแนวทางปัจจุบันที่ WebAssembly เรียกใช้ JavaScript APIs
การเข้าถึง DOM โดยตรงไม่มีเหตุผลใดๆ ในฐานะคุณสมบัติของ WASM มันจะเป็นคุณสมบัติของเว็บเบราว์เซอร์ในกรณีที่ดีที่สุด ซึ่งผู้จำหน่ายเบราว์เซอร์ต้องใช้งานนอก WASM
ความท้าทายด้านประสบการณ์นักพัฒนายังคงดำเนินต่อไป
ความคิดเห็นจากชุมชนเผยให้เห็นความไม่พอใจที่ยังคงดำเนินต่อไปเกี่ยวกับเครื่องมือพัฒนาและเอกสารของ WebAssembly นักพัฒนารายงานความยุ่งยากกับข้อผิดพลาดในการตรวจสอบ เอกสาร API ที่ไม่ดี และความซับซ้อนของ toolchain ที่มีอยู่อย่าง Binaryen บางคนประสบความสำเร็จจากการเปลี่ยนไปใช้เครื่องมือที่ใช้ Rust อย่าง wasm-tools ในขณะที่คนอื่นๆ สนับสนุนการเขียน WebAssembly ด้วยมือมากกว่าการใช้การแยกระดับสูง
การเปิดตัวครั้งนี้แสดงถึงก้าวสำคัญไปข้างหน้าสำหรับความสามารถของ WebAssembly โดยเฉพาะอย่างยิ่งสำหรับสภาพแวดล้อมที่ไม่ใช่เว็บ ซึ่งคุณสมบัติใหม่สามารถเปล่งประกายได้โดยไม่มีข้อจำกัดของเบราว์เซอร์ อย่างไรก็ตาม การแลกเปลี่ยนประสิทธิภาพและคุณสมบัติเฉพาะเว็บที่หายไปชี้ให้เห็นว่าการเดินทางของ WebAssembly เพื่อกลายเป็นเป้าหมายการคอมไพล์สากลที่นักพัฒนาจินตนาการไว้ยังมีอุปสรรคที่ต้องเอาชนะ
อ้างอิง: Wasm 3.0 Completed