Component Model, SIMD & Threads

Component Model คือวิวัฒนาการถัดไปของ WebAssembly ที่อยู่เหนือ raw module โดย core Wasm module เปิดเผยเฉพาะ numeric function ส่วน component เปิดเผย typed interface ที่ครอบคลุม — string, record, list, variant — ที่นิยามใน WIT (Wasm Interface Type language) Component สามารถ compose เข้าด้วยกันที่ระดับ toolchain ก่อน deployment ทำให้เกิด plugin ecosystem ที่ไม่ขึ้นกับภาษาอย่างแท้จริง

WIT — Wasm Interface Types

ไฟล์ .wit คือ contract ระหว่าง component หน้าตาคล้าย typed IDL:

package example:greeter@0.1.0;

interface greeter {
  greet: func(name: string) -> string;
}

world greeter-world {
  export greeter;
}

world นิยามสิ่งที่ component export และ import wasm-tools (reference toolchain) สามารถ validate, compose และ inspect component จาก WIT definition

การสร้าง component จาก Rust

# Install cargo-component (Rust Component Model toolchain)
cargo install cargo-component

# Create a new component project
cargo component new greeter --lib

# Build to a component .wasm
cargo component build --release
# Output: target/wasm32-wasip2/release/greeter.wasm

# Inspect the component's interface
wasm-tools component wit greeter.wasm

wasm-tools suite จัดการกลไก low-level:

# Compose two components: a greeter and a logger
wasm-tools compose greeter.wasm -d logger.wasm -o composed.wasm

# Validate a component
wasm-tools validate --features component-model greeter.wasm

# Convert a core module to a component (adapter pattern)
wasm-tools component new core.wasm --adapt wasi_snapshot_preview1.wasm -o component.wasm

โมเดลการ compose component

flowchart LR
  subgraph "Component A (Rust)"
    A_wit["WIT: export greeter"]
    A_core["core wasm\n(compiled Rust)"]
  end
  subgraph "Component B (Go)"
    B_wit["WIT: import greeter\nexport http-handler"]
    B_core["core wasm\n(compiled Go)"]
  end
  T["wasm-tools compose"]
  OUT["composed.wasm\n(deployable component)"]
  A_wit --> T
  B_wit --> T
  T --> OUT

สอง component ที่ compose เป็น artifact ที่ deploy ได้หนึ่งชิ้น

SIMD — ประเภท v128

Fixed-Width SIMD proposal (มาตรฐานแล้ว) เพิ่ม value type ใหม่หนึ่งประเภท: v128 register v128 เก็บ 128 bits ที่สามารถตีความได้หลายรูปแบบ lane:

i8x16 — สิบหก 8-bit integer
i16x8 — แปด 16-bit integer
i32x4 — สี่ 32-bit integer
f32x4 — สี่ 32-bit float
f64x2 — สอง 64-bit float

ใน WAT มีลักษณะดังนี้:

(module
  (func (export "add4f") (param $a v128) (param $b v128) (result v128)
    local.get $a
    local.get $b
    f32x4.add)
)

Compiler (Rust, C/Clang) ใช้ SIMD อัตโนมัติผ่าน auto-vectorisation เมื่อเปิดใช้ คุณแทบไม่เขียน SIMD WAT ด้วยมือ เพราะ SIMD จะโผล่ใน compiler output สำหรับ kernel ที่ compute-heavy (image processing, audio codec, ML inference)

Threads proposal

Threads proposal (Phase 4 — ใช้ได้ใน browser และรันไทม์ส่วนใหญ่) เพิ่ม:

Shared memory — (memory (shared) N N) นิยาม memory ที่แชร์ข้าม thread ได้
Atomic instruction — i32.atomic.load, i32.atomic.store, i32.atomic.rmw.add เป็นต้น
wait และ notify — memory.atomic.wait32 / memory.atomic.notify (เทียบเท่า Wasm ของ futex)

ใน Rust การคอมไพล์ด้วย RUSTFLAGS="-C target-feature=+atomics,+bulk-memory" และ target wasm32-unknown-unknown (พร้อม custom allocator) เปิดใช้ multi-threaded Wasm ใน browser threads ต้องการ SharedArrayBuffer ซึ่งต้องการ response header COOP/COEP

# Compile Rust with atomics + bulk-memory for browser threads
RUSTFLAGS="-C target-feature=+atomics,+bulk-memory" \
  cargo build --target wasm32-unknown-unknown --release

🦾 Phase ของ standard เทียบกับความพร้อมของ tooling

ณ ปลายปี 2026 ตัว proposal ของ Component Model เองยังอยู่แค่ Phase 1 ในกระบวนการของ WebAssembly community group (WebAssembly/proposals) — ยังไม่ผ่านการรับรองอย่างเป็นทางการ แต่ในทางปฏิบัติ tooling รอบๆ มัน (wasm-tools, cargo-component, wit-bindgen, jco) และ interface ของ WASI 0.2 ที่สร้างอยู่บนมันนั้นเสถียรและถูกใช้งานจริงแล้ว ดังนั้น “ยังเป็น proposal phase ต้น” กับ “ใช้งานได้จริงวันนี้” เป็นจริงพร้อมกันได้ ส่วน Threads proposal ที่ใช้ในบทนี้ไปไกลกว่านั้น อยู่ที่ Phase 4

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
WASI capability-based security	ปลอดภัยกว่าโมเดลเดิมมาก — component ได้สิทธิ์เฉพาะ capability ที่ host grant อย่างชัดเจนเท่านั้น	ยังไม่ compatible กับ POSIX เต็มรูปแบบ โค้ด native บางตัวที่ assume ว่ามี ambient filesystem/network access จะ port เข้า component ไม่ราบรื่น
Server-side Wasm (edge/serverless)	Cold-start ระดับ microsecond เหมาะกับการ deploy component บน edge/serverless มาก	Ecosystem ยังไม่ mature เท่า container — tooling รอบ Component Model และ orchestration ยังไม่ผ่านสนามรบมาเท่า

ข้อผิดพลาดที่พบบ่อย

คิดว่า SIMD หรือ multi-threading proposal ใช้ได้ในทุก Wasm runtime — ทั้งคู่ยังเป็น opt-in feature ที่ต้อง compile ด้วย target/flag เฉพาะ ไม่ใช่ทุกรันไทม์รองรับเหมือนกัน
มองข้าม versioning churn ของ Component Model — ยังเป็น standard ที่พัฒนาอยู่ WIT interface ระหว่าง version อาจเปลี่ยนแบบ breaking ได้ ถ้าผูก production ไว้ตอนนี้ต้องเตรียมรับมือ
ลืมว่า component ที่ import WASI interface ก็ยังต้องได้รับ capability grant จาก host อย่างชัดเจนเหมือนเดิม — compose component สำเร็จไม่ได้แปลว่าจะเข้าถึง filesystem หรือ network ได้เอง

💡 ตัวอย่างจากของจริง

Fermyon Spin สร้างบน Component Model และ Wasmtime เพื่อ build และ deploy serverless Wasm microservice ส่วน Fastly Compute รัน untrusted customer code เป็น Wasm module ที่ sandbox ไว้ พร้อมการควบคุม capability สไตล์ WASI บนเครือข่าย edge ของตัวเอง