ข้อเสนอวิสัยทัศน์เพื่อรองรับ WebAssembly ใน Swift

 (forums.swift.org)
4 คะแนน โดย GN⁺ 2025-04-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชุมชน Swift ได้พัฒนาการรองรับ WebAssembly (Wasm) อย่างต่อเนื่อง และจากพื้นฐานนี้ได้เสนอวิสัยทัศน์ระยะยาว
  • WebAssembly คือ ชุดคำสั่งของเครื่องเสมือน ที่ให้ความสำคัญกับ การพกพา ความปลอดภัย และประสิทธิภาพ และสามารถรันได้บนหลากหลายแพลตฟอร์ม
  • หาก Swift รองรับ Wasm ก็จะสามารถใช้งาน Swift ได้ใน สภาพแวดล้อมใหม่รวมถึงเบราว์เซอร์ และขยายโอกาสการใช้งานได้ทั้งใน แอปพลิเคชันฝั่งไคลเอนต์/เซิร์ฟเวอร์

คุณลักษณะด้านความปลอดภัยและอินเทอร์เฟซระบบ

  • Wasm สามารถ รันได้เฉพาะฟังก์ชันที่ถูก import มาอย่างชัดเจนโดยไม่มีการเข้าถึงระบบโดยตรง จึงได้เปรียบด้านความปลอดภัย
  • WASI (WebAssembly System Interface) มอบ API มาตรฐานเพื่อให้ Wasm โต้ตอบกับโฮสต์ OS ได้
  • Swift ทำงานบน target wasm32-unknown-wasi โดยอาศัย WASI libc และสามารถใช้งานได้แล้วผ่าน C interop
  • W3C กำลังจัดการการบูรณาการระบบชนิดและการเชื่อมต่อโมดูลของ Wasm แบบรวมศูนย์ผ่าน Component Model
    • สามารถสร้าง .wit จากการประกาศของ Swift ผ่าน wit-tool ได้ และรองรับทิศทางกลับกันด้วย

กรณีการใช้งานหลัก

  • สามารถคอมไพล์ Swift macro เป็น Wasm และแจกจ่ายเป็นไบนารีที่รันได้ทุกที่
  • เสริมความปลอดภัยโดย ทำให้การรัน SwiftPM plugin, manifest, macro ฯลฯ อยู่ในสภาพแวดล้อมเสมือน
  • Wasm สามารถสร้างไบนารีที่ปรับแต่งประสิทธิภาพผ่านการคอมไพล์แบบ JIT หรือ AOT ได้ จึง ลดการสูญเสียประสิทธิภาพให้เหลือน้อยที่สุด
  • คอมโพเนนต์ Swift ที่ถูกทำให้เป็นเสมือนด้วย Wasm สามารถ รันได้โดยไม่ต้องมีโปรเซสแยก จึงตัด overhead ของ IPC ออกไป

เป้าหมายที่เสนอ

  1. ขยายขอบเขต API ที่รองรับ WASI ใน Swift Standard Library
    • จำเป็นต้องสร้างสภาพแวดล้อม CI สำหรับการทดสอบอัตโนมัติ
  2. ปรับปรุงเครื่องมือ cross-compilation
    • ทำให้การจัดการเวอร์ชันและการติดตั้ง Swift SDK ง่ายขึ้น
  3. บูรณาการ Component Model
    • รองรับให้สามารถใช้สเปก WASI ล่าสุดใน Swift ได้
  4. ปรับปรุง interop กับคอมโพเนนต์ Wasm อื่น ๆ
    • เป้าหมายคือทำให้ประสบการณ์การใช้งานคอมโพเนนต์ Wasm จาก Swift เทียบเท่ากับ C/C++
  5. ปรับปรุงสภาพแวดล้อมการดีบักของ Swift บน Wasm

ประเด็นเกี่ยวกับการดีบัก

  • การดีบักของ Wasm ยังมีข้อจำกัด และไม่มีความสามารถ introspection ในตัว
  • มีแนวทางหลักอยู่สองแบบ
    1. Wasm runtime ที่รองรับ LLDB และ GDB protocol
    2. debugger ที่ฝังมากับ Wasm engine
  • สภาพแวดล้อมแบบเบราว์เซอร์และไม่ใช่เบราว์เซอร์ต้องการแนวทางการดีบักที่แตกต่างกัน
  • เครื่องมืออย่าง Chrome DevTools สามารถใช้ข้อมูล DWARF ได้ แต่ยังต้องมีการบูรณาการเพิ่มเติมสำหรับ Swift metadata และความสามารถในการประเมิน JIT expression

มัลติเธรดและ concurrency

  • ขณะนี้ Wasm มีเพียง atomic operation ที่รองรับ sequential consistency
  • การสร้างเธรด ขึ้นอยู่กับสภาพแวดล้อมโฮสต์
  • มีข้อเสนอด้าน threading อยู่สองแบบ:
    • wasi-threads (แนวทางเดิม ซึ่งเครื่องมือและ runtime บางส่วนรองรับแล้ว)
    • shared-everything-threads (ข้อเสนอใหม่ ซึ่งอาจกลายเป็นมาตรฐานในอนาคต)
  • Swift รองรับ wasm32-unknown-wasi (single-thread) และ wasm32-unknown-wasip1-threads (multi-thread)
  • ปัจจุบัน libdispatch ยังไม่รองรับ wasi-threads จึงใช้งาน Swift Concurrency executor แบบ single-thread อยู่

พื้นที่แอดเดรส 64 บิต

  • โดยพื้นฐานแล้ว Wasm ใช้ พื้นที่แอดเดรส 32 บิต
  • ข้อเสนอหน่วยความจำ 64 บิต (memory64) อยู่ระหว่างการนำไปใช้งาน
  • หากต้องการรองรับใน Swift จำเป็นต้องอาศัย ความร่วมมือจาก WebAssembly toolchain หรือ การเปลี่ยนโครงสร้าง Swift metadata

Shared library

  • มีอยู่สองแนวทาง
    1. dynamic linking แบบ Emscripten: ไม่ใช่มาตรฐานและขึ้นอยู่กับความสามารถของ runtime
    2. static linking บนพื้นฐาน Component Model: ใช้งานได้โดยไม่ต้องพึ่งความสามารถพิเศษของ runtime แต่ไม่สามารถโหลดขณะรันไทม์ได้
  • หากต้องการใช้ shared library ใน Swift จำเป็นต้องคอมไพล์ในโหมด PIC (Position-Independent Code) และปฏิบัติตาม ข้อกำหนดการลิงก์ที่กำหนดไว้

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

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

 
kandk 2025-04-07

Swift ก็ดีนะ แต่ Swift ที่ถูกทอดทิ้งจะกลับมามีชีวิตอีกครั้งได้ไหม..