WASM 3.0 เสร็จสมบูรณ์

 (webassembly.org)
17 คะแนน โดย GN⁺ 2025-09-18 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการประกาศมาตรฐาน Wasm 3.0 อย่างเป็นทางการ พร้อมฟีเจอร์ขนาดใหญ่ที่เตรียมกันมานาน 6–8 ปี
  • มี พื้นที่แอดเดรส 64 บิต, garbage collection, typed references, tail calls, การจัดการข้อยกเว้น ฯลฯ ช่วยให้คอมไพล์ภาษาแบบ high-level ไปยัง Wasm ได้ง่ายขึ้น
  • ฟีเจอร์หลักใหม่ ๆ ช่วยด้าน แอปพลิเคชันประสิทธิภาพสูง, รันไทม์ของหลายภาษา, ความปลอดภัย และการขยายระบบ
  • เหมาะกับกรณีใช้งานที่ต้องจัดการความจุและชุดข้อมูลขนาดใหญ่ใน ระบบนอกเหนือจากเว็บ ด้วย
  • ตอนนี้รองรับแล้วในเว็บเบราว์เซอร์หลัก และเอนจินอิสระอย่าง Wasmtime ก็ใกล้รองรับครบถ้วน ทำให้ Wasm ยิ่งชัดเจนขึ้นในฐานะ แพลตฟอร์มรันโปรแกรมอเนกประสงค์

ภาพรวมการเปิดตัว Wasm 3.0

  • มาตรฐาน WebAssembly เวอร์ชัน 3.0 เปิดตัวเมื่อวันที่ 17 กันยายน 2025
    • นับเป็นการอัปเดตใหญ่ในรอบ 3 ปี หลังจากเวอร์ชัน 2.0 (เสร็จสมบูรณ์ในปี 2022) ที่เพิ่ม vector instructions, bulk memory operations, multiple return values และ simple reference types
    • กลุ่ม W3C Community Group และ Working Group พัฒนาต่อเนื่องมาโดยตลอด และรีลีสครั้งนี้เป็นการเปลี่ยนแปลงขนาดใหญ่ที่รวม ฟีเจอร์สำคัญซึ่งเตรียมมานาน 6–8 ปี
    • Wasm ยังคงแนวคิดของการเป็นภาษา low-level แต่เสริมระบบหน่วยความจำและระบบชนิดข้อมูลให้แข็งแรงขึ้น เพื่อรองรับ การคอมไพล์ภาษา high-level ได้ดียิ่งขึ้น
  • ฟีเจอร์ที่พัฒนาหลังเวอร์ชัน 2.0 ได้เสร็จสมบูรณ์และกลายเป็น มาตรฐาน Live พร้อมการรองรับที่ขยายเพิ่มทั้งในเว็บเบราว์เซอร์และเอนจินอิสระ
    • สามารถติดตามสถานะการรองรับของแต่ละเอนจินได้ที่ หน้าสถานะฟีเจอร์ของ Wasm
    • ใช้ toolchain ใหม่ SpecTec ในการสร้างเวอร์ชันนี้เป็นครั้งแรก จึงช่วย เพิ่มความน่าเชื่อถือ

การเปลี่ยนแปลงสำคัญและฟีเจอร์ใหม่

  • พื้นที่แอดเดรส 64 บิต
    • สามารถประกาศหน่วยความจำและตารางด้วยชนิด i64 ได้
    • ขยายพื้นที่แอดเดรสของแอป Wasm จากราว 4GB ไปจนถึงขีดจำกัดทางกายภาพ (เชิงทฤษฎี 16 exabytes)
    • สำหรับเว็บจะยังจำกัดไว้ที่ 16GB แต่ใน ระบบนอกเว็บ มีประโยชน์สำหรับการรองรับแอปพลิเคชันและชุดข้อมูลขนาดใหญ่
  • หลายหน่วยความจำ
    • สามารถประกาศและเข้าถึง อ็อบเจ็กต์หน่วยความจำหลายตัว ได้โดยตรงภายในโมดูลเดียว
    • ใช้งานได้หลากหลาย เช่น การรวมโมดูล การแยกพื้นที่แอดเดรส การบัฟเฟอร์ และความปลอดภัย
    • ทำให้เครื่องมือ static linking อย่าง wasm-merge ใช้กับโมดูล Wasm ได้ทั้งหมด
  • Garbage Collection (GC)
    • นอกจาก linear memory แล้ว ยังรองรับ พื้นที่จัดเก็บที่รันไทม์ของ Wasm ดูแลให้อัตโนมัติ
    • คอมไพเลอร์สามารถประกาศ data layout ได้โดยตรง เช่น struct/array types และ unboxed integers
    • มีเพียงบิลดิ้งบล็อกพื้นฐานสำหรับการจัดการหน่วยความจำ ส่วน ระบบอ็อบเจ็กต์ระดับสูงหรือ closure สามารถออกแบบแยกกันตามภาษาที่นำไปใช้
  • Typed References
    • ระบบชนิดข้อมูลของ Wasm ถูกขยายให้ อธิบายรูปแบบของค่าในฮีปและฟังก์ชันรีเฟอเรนซ์ได้แม่นยำขึ้น
    • รองรับ subtyping และ type recursion พร้อมคำสั่งใหม่ call_ref ที่ช่วยให้ เรียกฟังก์ชันทางอ้อมอย่างปลอดภัยโดยไม่ต้องเช็กชนิดข้อมูลตอนรันไทม์
  • Tail Calls
    • รองรับโครงสร้าง tail call ที่คืนค่าทันทีโดยไม่ต้องใช้พื้นที่สแตกเพิ่มจากฟังก์ชันเดิม
    • นำไปใช้กับภาษาเชิงฟังก์ชันหรือการปรับแต่งภายในรันไทม์ได้
  • การจัดการข้อยกเว้น
    • เพิ่ม ระบบจัดการข้อยกเว้นแบบเนทีฟ ภายใน Wasm
    • รองรับการประกาศ exception tag และ payload, การ catch แบบเลือกได้ และตัวจัดการข้อยกเว้นระดับบล็อก
    • ช่วย เพิ่ม portability และประสิทธิภาพ โดยไม่ต้องใช้วิธีอ้อมผ่าน JS ที่ไม่มีประสิทธิภาพแบบเดิม
  • คำสั่งเวกเตอร์แบบ relaxed
    • เพื่อรองรับความแตกต่างของฮาร์ดแวร์สำหรับคำสั่ง SIMD จึงมี relaxed variant ที่เปิดให้รายละเอียดการทำงานบางส่วนขึ้นกับการอิมพลีเมนต์
    • ทำให้สามารถปรับแต่งประสิทธิภาพได้หลากหลายภายในขอบเขตพฤติกรรมที่ถูกต้อง
  • โปรไฟล์แบบกำหนดผลลัพธ์แน่นอน
    • แม้ในกรณีที่ผลลัพธ์ของคำสั่งเดียวกันอาจไม่เป็น deterministic เช่น การคำนวณ floating point หรือ relaxed SIMD ก็ยัง กำหนดการทำงานแบบ deterministic ข้ามแพลตฟอร์ม ได้
    • ช่วยรับประกัน ความสามารถในการทำซ้ำและการพกพา สำหรับบล็อกเชนหรือระบบที่ต้อง replay ได้
  • ไวยากรณ์ custom annotation
    • เพิ่ม ไวยากรณ์ annotation ที่มนุษย์อ่านและเขียนได้ในซอร์สโค้ด
    • แม้มาตรฐานจะไม่ตีความโดยตรง แต่สามารถนำไปใช้กับมาตรฐานหรือส่วนขยายในอนาคตได้

การเชื่อมต่อกับ JavaScript และความเข้ากันได้

  • JS string builtins
    • สามารถส่งและจัดการค่าสตริงของ JS ใน Wasm ได้ผ่าน externref
    • โดย import ฟังก์ชันพื้นฐานใหม่ ก็จะสามารถใช้สตริง JS ภายนอกได้โดยตรงภายใน Wasm

ประโยชน์และแนวโน้มของ Wasm 3.0

  • เป็นรากฐานสำคัญที่จำเป็นสำหรับ การคอมไพล์ภาษาโปรแกรมระดับสูงไปยัง Wasm
  • ภาษาอย่าง Java, OCaml, Scala, Kotlin, Scheme, Dart เป็นต้น ก็เริ่มใช้ฟีเจอร์ GC อย่างจริงจังมากขึ้น

สถานะการจัดทำสเปกและการเผยแพร่

  • Wasm 3.0 เป็นมาตรฐานแรกที่สร้างด้วย toolchain ใหม่ SpecTec
  • เว็บเบราว์เซอร์หลัก ส่วนใหญ่รองรับ Wasm 3.0 แล้ว และเอนจินแบบสแตนด์อโลนอย่าง Wasmtime ก็ใกล้เสร็จสมบูรณ์
  • ตรวจสอบสถานะการรองรับของแต่ละเอนจินได้ที่หน้า Wasm feature status

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
coremaker 2025-09-18

อาจจะเริ่มมีความพยายามสร้าง Memory DB ขึ้นมาด้วยหรือเปล่า?
 
GN⁺ 2025-09-18
ความคิดเห็นบน Hacker News

  • ส่วนที่น่าตื่นเต้นจริง ๆ คือการที่ 64 บิตจะกลายเป็นค่าเริ่มต้นของสเปก โดยเฉพาะเว็บแอปอย่างโปรแกรมตัดต่อวิดีโอออนไลน์ที่ตอนนี้ยังติดข้อจำกัด 32 บิตอยู่มาก Figma เองก็เจอข้อจำกัดนี้โดยตรงเหมือนกัน สิ่งหนึ่งที่สงสัยคือบนอุปกรณ์พกพา ข้อจำกัดหน่วยความจำแบบระบุตามแท็บจะยังคงเดิมหรือไม่ ปกติแล้วมันถูกกำหนดโดย OS จึงอาจไม่ได้ผูกกับพื้นที่ 32 บิตโดยตรง

    • ก็ยังสงสัยอยู่ว่าการที่แอประดับ Video editor มาอยู่ใน document browser นั้นเหมาะสมหรือไม่ น่าเสียดายที่มี native operating system ที่ออกแบบมาดีอยู่แล้วแต่ตอนนี้แทบไม่มีใครใช้ ถ้าต้องการ virtual machine ที่แข็งแรงกว่าการแยกส่วนแบบที่โปรเซสของระบบปฏิบัติการเดิมให้มา ผมคิดว่าการออกแบบ abstraction ที่ตรงกับจุดประสงค์ไปเลยจะซื่อตรงกว่า มันให้ความรู้สึกเหมือนจับ document reader ธรรมดามาดัดแปลงฝืน ๆ ให้เป็นโปรแกรมตัดต่อวิดีโอ

    • น่าเสียดายที่ฟีเจอร์ Memory64 มีภาระด้านประสิทธิภาพค่อนข้างมาก เดิมใน 32 บิต runtime จะจัดสรร 4GB ทั้งก้อนทุกครั้งอยู่แล้ว เลยแทบไม่ต้องเช็กขอบเขต แต่ใน 64 บิตต้องตรวจสอบขอบเขตเอง ถ้าจำเป็นต้องใช้หน่วยความจำเกิน 4GB จริง ๆ ก็ไม่มีทางเลือกนอกจากต้องใช้มัน

    • ก็ตื่นเต้นกับการมาของ GC, reference types และ JS string API เหมือนกัน ดีใจที่ได้เห็นตัว J อีกครั้ง ไม่รู้สบายดีไหม

    • มันก็ดูเป็นเรื่องปกติที่เว็บแอปจะชนเพดานหน่วยความจำ 4GiB ราวกับว่าสมัยนี้แค่อ่านอีเมลก็ต้องมีอย่างต่ำ 512GiB แล้ว

  • การเพิ่ม garbage collection เข้ามานี่น่าทึ่งมาก ก่อนหน้านี้ใน Wasm เข้าถึงสแตกโดยตรงไม่ได้ เลยใช้แนวทาง GC แบบดั้งเดิมอย่าง stack scanning ไม่ได้ ด้วยเหตุนี้จึงยังคงความเป็นภาษา low-level เอาไว้ ขณะเดียวกันก็ระบุ layout ของหน่วยความจำด้วย struct, array type, unboxed tagged int ฯลฯ แล้วให้ Wasm จัดการการจัดสรรและอายุการใช้งานให้ สุดยอดจริง ๆ

    • การที่มี GC เข้ามาแต่ยังรองรับสภาพแวดล้อมที่ไม่มี GC ด้วย ถือว่าแปลกใหม่น่าสนใจ จุดนี้คล้ายภาษา D มาก (D รองรับทั้งแบบไม่มี GC และแบบมี GC พร้อมการคอมไพล์และรันที่เร็ว) อนึ่ง ตอนนี้คอมไพเลอร์ Dlang อย่าง LDC ก็สร้าง Wasm ได้แล้ว Generating WebAssembly with LDC

    • อยากรู้ว่าการเปลี่ยนแปลงนี้จะทำให้ลดขนาดของอ็อบเจ็กต์ WebAssembly.Memory ได้หรือไม่ นี่เป็นประเด็นสำคัญมาก เพราะต่อให้คืนหน่วยความจำไปแล้ว มันก็ยังค้างอยู่ในเบราว์เซอร์ issue 1 issue 2

  • สงสัยว่าเมื่อไร WASM จะสามารถแตะ DOM ได้โดยตรง รู้สึกว่านี่เหมือนจะเป็นเป้าหมายหลักของ WASM ตั้งแต่แรก แต่ตอนนี้มันกลับดูเหมือนสัตว์ประหลาดอีกตัวที่แทบไม่เกี่ยวกับเว็บเลย ไม่รู้ว่าเมื่อไรถึงจะไม่ต้องใช้ JavaScript ได้เสียที

    • หวังว่าส่วนนี้รวมถึงการเข้าถึงแบบมัลติเธรดจะถูกสนับสนุนอย่างเหมาะสมด้วย อยากใช้แอป Rust คอมไพล์เป็น wasm แล้วเรียกใช้ตรง ๆ แบบนี้:

      ในเว็บแอปประสิทธิภาพสูงหรือส่วนขยายเบราว์เซอร์ ปัญหาเรื่องหน่วยความจำและประสิทธิภาพมีอยู่จริงมาก ๆ ดังนั้นสิ่งนี้จะช่วยได้มาก ถ้าเป็นแอปที่อิง wasm ก็สามารถข้าม v8 ไปใช้เอนจินอย่าง wasmer ได้โดยตรง ผมคิดว่าเหตุที่เทคโนโลยีเว็บถูกเอาไปใช้กับเดสก์ท็อปแอปอย่าง Electron ก็เพราะ desktop API ห่วยเกินไปและพกพาไม่ได้ ถ้าเสริมการรองรับ native ของ WASM ให้ดีขึ้น แอปอย่าง Slack, VSCode, Discord ก็น่าจะเบาลงได้

    • ตอนนี้โปรแกรม WASM ก็เข้าถึง DOM ได้อยู่แล้ว เพียงแต่ต้องผ่าน JS API เดิม ครั้งหนึ่งเคยมีการคุยเรื่อง API สำหรับ WASM โดยเฉพาะ แต่ข้อเสียเยอะเกินไปเลยถูกยกเลิกไปในที่สุด

    • ผมกำลังรอดูและหวังว่าจะมีภาษา frontend ที่ออกแบบมาดีจริง ๆ ขึ้นมา แต่ก็สงสัยว่าการต้องผ่าน JS wrapper ตอนเข้าถึง DOM มันไร้ประสิทธิภาพขนาดนั้นจริงหรือ ส่วนใหญ่โค้ดก็ไม่มีประสิทธิภาพอยู่แล้ว ผมเลยคิดว่า overhead จากตรงนี้ไม่ได้โดดเด่นมากนักในทางปฏิบัติ

    • ถ้าคุณคิดว่า JavaScript มีปัญหา ด้าน DOM จะยิ่งทำให้คุณรู้สึกแย่กว่าเดิมอีก

    • การถือ DOM reference หมายความว่าสามารถมองเข้าไปยังอ็อบเจ็กต์ที่มีการทำ garbage collection ได้โดยตรง ซึ่งเป็นเรื่องที่ tricky เพราะตามโมเดลความปลอดภัยของ JavaScript บนเว็บ เราไม่ควรมองเข้าไปในภายในของ GC ได้ ถ้า WASM ถือ pointer ไปยัง DOM ได้จริงจะจัดการอย่างไรจึงเป็นปัญหา หลังจากมี GC ที่สมบูรณ์แล้ว ประเด็นนี้อาจกลับมาถูกคุยกันใหม่ได้ แต่สำหรับ WASM ที่ไม่มี GC ดูเหมือนแทบไม่มีคำตอบเลย

  • ผมหยุดตาม WASM ไปประมาณปีหนึ่ง เพิ่งรู้เดี๋ยวนี้เองว่าเปลี่ยนมาใช้โมเดลรีลีสแบบมีเวอร์ชันแล้ว ตอนแรกนึกว่าหลายฟีเจอร์จะยังเป็นตัวเลือกอยู่ แต่ตอนนี้ดูเหมือนว่าจะต้องให้ทุก implementation รองรับทุกฟีเจอร์ ถึงจะบอกว่าเข้ากันได้กับเวอร์ชันนั้นได้จริง (เช่น WASM 3.0) อีกเรื่องที่สงสัยคือ non-browser runtime ตัวที่สองที่จะรองรับ 3.0 แบบครบถ้วนจะเป็นใคร ตัวแรกน่าจะเป็น wasmtime (ไม่นับ deno เพราะใช้ v8) โดยเฉพาะ GC ดูเป็นฟีเจอร์ที่ tricky มาก อยากรู้ว่าการออก 3.0 เชื่อมโยงกับโมเดล "evergreen" เดิมอย่างไรบ้าง evergreen คือโมเดลที่อัปเดตเฉพาะร่างมาตรฐานอย่างต่อเนื่อง โดยไม่แยกเวอร์ชัน final อย่างเป็นทางการ ตอนนี้ Candidate Recommendation Draft ล่าสุดถูกมองเป็นมาตรฐานโดยพฤตินัย สถานะฟีเจอร์ wasm ข่าว wasm 2.0 ร่างมาตรฐานล่าสุด

    • wasmtime รองรับฟีเจอร์หลักทั้งหมดของ wasm 3.0 อยู่แล้ว GC นั้นเพื่อนร่วมงาน Nick Fitzgerald เป็นคนทำไว้ตั้งแต่หลายปีก่อน ส่วน tail call เมื่อปีที่แล้ว Jamey Sharp กับ Trevor Elliott ก็ทำให้รองรับได้ครบถ้วนแล้ว (ไม่มีข้อจำกัดเรื่อง signature และไม่ต้องใช้ trampoline) ระบบจัดการข้อยกเว้นก็มีแล้วและใกล้ออกรีลีส正式เช่นกัน รีลีสชื่อว่า "3.0" ถ้ามองในมุมนี้ก็คือสัญญาณว่าแต่ละเอนจินเตรียมฟีเจอร์เหล่านี้ไว้พร้อมแล้ว ผมเป็นเมนเทนเนอร์ของ wasmtime และ Cranelift

    • Wizard เป็นเครื่องมือเพื่อการวิจัย แต่รองรับ Wasm 3.0 ครบทั้งหมด เพียงแต่มันมีแค่อินเทอร์พรีเตอร์กับ baseline compiler ไม่มี optimized compiler แบบ v8 หรือ wasmtime ดังนั้นความเร็วเลยช้า

    • คิดว่าการจัดการเวอร์ชันจะกลายเป็นแบบ feature set ของ JavaScript กล่าวคือจะอธิบายกันว่ารันไทม์ไหนรองรับชุดฟีเจอร์อะไรบ้าง อยากรู้ว่าการทำ feature discovery ใน wasm จะทำงานอย่างไร

  • ดีใจมากที่มีการเพิ่มการรองรับ GC เข้ามา แต่ก่อนใน WASM เข้าถึงสแตกโดยตรงไม่ได้ จึงแทบเป็นไปไม่ได้เลยที่จะทำ GC แบบ stack scanning ตามดั้งเดิม

  • รู้สึกว่า WebAssembly community ควรใส่ใจกับ developer experience (DX) มากกว่านี้ ผมลองเขียนคอมไพเลอร์ตัวหนึ่งโดยให้ Wasm เป็น target เองแล้วพบว่าค่อนข้างไม่สะดวก นึกว่าจะเป็นภาษาที่มีความหมายเชิงรูปแบบชัดเจน แต่พอสร้าง Wasm ด้วย Binaryen.js จริง ๆ กลับไม่ค่อยรู้สึกว่ากำลัง target ชุดคำสั่งที่ชัดเจนอยู่ น่าจะเป็นเพราะตัว Binaryen เองและเอกสารที่ยังขาดอยู่ อย่างน้อยก็ยังพอปลอบใจได้ว่าการเขียน Wasm text snippet นั้นสนุกดี jasmine wasm compiler

    • Binaryen มีภาระจากอดีตเยอะ เพราะ Wasm รุ่นแรก ๆ เป็น AST ฟีเจอร์ใหม่ ๆ เลยยัดให้เข้ากับโมเดลเดิมได้ยาก คอมไพเลอร์ของเราจึงนิยามโครงสร้างข้อมูลสำหรับ abstract Wasm representation แยกต่างหาก แล้วปกติจะปล่อยออกเป็น .wasm ส่วนตอนดีบักจะปล่อยเป็น .wat รู้สึกว่าค่อนข้างตรงไปตรงมา ชุดคำสั่งเองก็โอเคนะ Scala.js wasm backend

    • ผมเคยใช้ Binaryen จาก TypeScript แล้วรู้สึกอึดอัดคล้ายกัน สุดท้ายย้ายไปใช้ wasm-tools ที่เขียนด้วย Rust แล้วประสบการณ์ดีกว่ามาก

    • อยากรู้ว่าเฉพาะเจาะจงแล้วส่วนไหนที่ยาก เพราะบางที validation error น่ารำคาญมาก เราเลยใส่ตัวเลือก --trace-validation ไว้ใน Wizard เพื่อให้เห็นและไล่ดูขั้นตอนการตรวจสอบได้ง่ายขึ้น

    • เอกสารและ binding ของ binaryen.js ยังขาดอยู่มากจริง ๆ ตอนนี้พลังหลักถูกเทไปที่การปรับปรุง optimization ของ Binaryen core เลยทำให้ฝั่ง JS/TS พัฒนาช้า แต่ถ้ามีใครมาช่วยลงเวลากับการปรับปรุง JS/TS binding ก็น่าจะเป็นประโยชน์กับทุกคนมาก

    • ยังรู้สึกเลยว่าการเขียนโค้ดแอสเซมบลีล้วนตั้งแต่ต้นอาจจะง่ายกว่าเสียอีก แหล่งข้อมูลส่วนใหญ่ไปกองอยู่กับเครื่องมือ Rust แต่ประสบการณ์การเขียนด้วยมือก็สำคัญ compiler กับ assembly เป็นคนละเรื่องกัน เราควรมองด้วยว่าไม่ใช่มีแค่นักพัฒนาคอมไพเลอร์ที่สนใจ Wasm

  • ผมยังคงมีความหวังกับ WASM อยู่ รีลีสครั้งนี้ดูยอดเยี่ยมมาก เรากำลังรันปลั๊กอิน WASM ที่มีทราฟฟิกสูงใน envoy และยังใช้ WASM กับปลั๊กอินสำหรับแอปเทอร์มินัลอย่าง zellij ด้วย ส่วนโปรเจกต์เล็ก ๆ ส่วนตัวก็มีเว็บแอป wasm ที่ทำด้วย rust leptos อยู่เหมือนกัน พูดตามตรง 2 ใน 3 อย่างนี้อาจไม่ใช่ตัวเลือกที่ดีที่สุดในเชิงเทคนิค แต่ผมคิดว่าทิศทางนี้จะไปได้ดีต่อจากนี้ ขอบคุณทุกคนมาก

  • อะไรที่เรียบง่ายที่สุดมักดีที่สุด สิ่งที่ผมอยากได้คือวิธีส่งผ่าน Go struct ที่ง่ายและเร็วขึ้น เวลาใส่หรือดึง go struct เข้าออกจากรันไทม์จะได้ไม่ต้องพันกันยุ่ง และไม่ต้องไปพึ่งโซลูชันพอกเสริม ถ้ามีวิธีทั่วไปที่ใช้ได้กับหลายภาษาก็ดี แต่ถ้ามีข้อจำกัดเชิงปฏิบัติบ้างก็ไม่เป็นไร สำหรับผม go สำคัญที่สุด

    • เห็นด้วยมาก และในภาษาที่ไม่มี GC สถานการณ์จริงก็ไม่ได้ดีไปกว่ากันเท่าไร เอาเข้าจริง runtime แบบมี GC บน wasm กลับยิ่งเละกว่าเสียอีก ประสบการณ์แย่ที่สุดที่ผมเคยเจอกับ JavaScript คือการต้องมานั่งจัดการ pointer ด้วยมือ ใน C++ พอหลุด scope ไป destructor ก็จัดการให้ แต่ใน wasm กับ js ต้องมานั่งดูแลเองทั้งหมด จนถึงขั้นรู้สึกว่าไปทำ JNI ยังดีกว่าเสียอีก (รวมถึง go ด้วย) แล้วพอฝ่าด่านจนส่ง struct ได้หนึ่งตัว ก็ยังเจอ overhead ต่อการเรียกสูงมาก สุดท้ายก็ต้องเริ่มห่อข้อมูลให้ใหญ่ขึ้นก่อนส่งอยู่ดี ผมเองก็หวังแค่ว่าอย่างน้อย pipeline ของ wasm จะดีขึ้น เพราะที่ผ่านมาเหนื่อยมาก

    • ถ้าเป็น native code วิธีแก้ก็เหมือนเดิม คือไม่ก็ทำให้ตรงตามโครงสร้างมาตรฐานระหว่างภาษา (เช่น C struct) หรือไม่ก็ serialize/deserialize เวลาเอาหลาย runtime มาปนกัน ถ้าภาษาไม่ได้รองรับกันโดยตรงมันก็เป็นงานที่น่าปวดหัวจริง ๆ และก็เห็นชัดอยู่แล้วว่าทำไมถึงเป็นปัญหา

    • ไม่แน่ใจว่าคุณต้องการแบบไหนเป๊ะ ๆ แต่ component model ซึ่งเป็นพื้นฐานของ WASI น่าจะช่วยได้ โมเดลนี้เปิดให้แต่ละโมดูลกำหนดวิธีแมปข้อมูลลงหน่วยความจำของตัวเองได้ (ภายหลังกระทั่งรวมถึง GC heap ด้วย) และยังนิยามสิ่งอย่างประเภท struct เป็นอินเทอร์เฟซได้ ทำให้คอมไพเลอร์สร้าง glue code ให้โดยอัตโนมัติ

    • อันนี้ดูเหมือนจะเป็นเรื่องระดับไลบรารีมากกว่าสเปกของ WASM ผมเองก็เคยมีประสบการณ์ที่ดีจากการใช้ code generator ลักษณะนี้ภายในระบบ

  • กำลังรอการรองรับ OpenMP อยู่ ตอนนี้กำลังลองรัน Solvespace เว็บบิลด์แบบทดลองอยู่ ถ้ามี OpenMP ก็น่าจะดีขึ้นมาก online solvespace demo เป็น CAD โอเพนซอร์สที่รันในเบราว์เซอร์

    • ผมคิดว่า Solvespace เป็นเครื่องมือที่เจ๋งมาก เมื่อก่อนเคยตามวิดีโอสอนใน YouTube แล้วออกแบบเคสคีย์บอร์ดแบบแยกส่วนก่อนเอาไปทำ CNC ได้ผลลัพธ์เร็วมาก ขอบคุณที่ช่วยดูแลโปรเจกต์นี้

    • คิดว่านี่คือเว็บ UI บน WASM ที่ดีที่สุดเท่าที่เคยเห็นมา อยากรู้ว่าตอนพาเดสก์ท็อปบิลด์มารันผ่าน Emscripten อะไรคือส่วนที่ยากที่สุด

  • ขอเสริมในส่วนที่ยังไม่มีใครพูดถึง: สงสัยว่าฟีเจอร์ multiple-memories จะช่วยเลี่ยงการคัดลอกซ้ำตอนแมปทรัพยากร WebGPU ได้หรือไม่ ตอนนี้เพราะมีสิ่งที่แมปอยู่บน ArrayBuffer ทำให้ฝั่ง WASM ต้องคัดลอกผ่าน JS และเสียประสิทธิภาพ คิดว่าการมี WASM memory หลายก้อนร่วมกับฟีเจอร์ address space ของ Clang/LLVM อาจเป็นทางออกได้ แต่ก็ไม่แน่ใจว่าของจริงจะง่ายแบบนั้นไหม

    • มีการคุยเรื่อง การรองรับ multi-memory ใน toolchain อยู่จริง แต่ก็ไม่แน่ใจว่าใน LLVM มีการทำของจริงโดยใช้หลาย address space ไปแล้วหรือยัง

    • ทั้งหมดนี้ทำให้นึกถึง segmented memory กับ far-pointers สมัยก่อน ช่วงนี้ผมเพิ่งลองเขียนเกม Gameboy เลยพอเข้าใจว่าการแมปหน่วยความจำเป็นส่วนหนึ่งของ "ความสนุก" แต่ถ้าอยู่ในสภาพแวดล้อมที่ไม่จำกัดแล้วต้องกลับมาทำแบบนี้อีกก็คงไม่ไหว เหตุผลที่ยุค DOS/Win16 ฝัง far pointers ทิ้งไปก็มีเหตุผลของมันเอง