บอกลา asm.js

 (spidermonkey.dev)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่ Firefox 148 เป็นต้นไป การเพิ่มประสิทธิภาพ asm.js ของ SpiderMonkey ถูกปิดใช้งานเป็นค่าเริ่มต้น และมีแผนจะลบโค้ดที่เกี่ยวข้องออกในอนาคต
  • asm.js เป็นส่วนย่อยของ JavaScript ดังนั้นเว็บไซต์เดิมยังคงทำงานต่อได้ แต่จะรันผ่านเส้นทาง JIT ปกติ ทำให้ข้อได้เปรียบด้านการเพิ่มประสิทธิภาพหายไป
  • สามารถคอมไพล์คอนเทนต์ asm.js ใหม่เป็น WebAssembly เพื่อให้รันได้เร็วขึ้นและได้ไบนารีขนาดเล็กลง
  • asm.js ทำให้สามารถรันโค้ดได้ใกล้เคียงเนทีฟภายในคอนเทนต์เว็บ โดยไม่ต้องมีแซนด์บ็อกซ์แยกหรือ API ทางเลือก เพื่อต่อกรกับ NaCl·PNaCl
  • OdinMonkey ซึ่งเข้าสู่ Firefox 22 ในปี 2013 ทำให้การเผยแพร่ C/C++ บนเว็บสำหรับ Unity และ Unreal เป็นไปได้ และกลายเป็นรากฐานที่นำไปสู่ WebAssembly

ปิดใช้งานการเพิ่มประสิทธิภาพ asm.js

  • ตั้งแต่ Firefox 148 เป็นต้นไป การเพิ่มประสิทธิภาพ asm.js ของ SpiderMonkey ถูกปิดใช้งานเป็นค่าเริ่มต้น และมีแผนจะลบโค้ดที่เกี่ยวข้องทั้งหมดออกในรีลีสถัดไป
  • เว็บไซต์ที่ใช้ asm.js จะยังคงทำงานต่อได้
    • asm.js เป็นส่วนย่อยของ JavaScript ทั่วไป ดังนั้นโค้ดเดิมจะถูกรันผ่านเส้นทาง JIT ปกติเหมือนสคริปต์อื่น
    • แต่ข้อได้เปรียบจากการเพิ่มประสิทธิภาพเฉพาะ asm.js จะหายไป
  • หากยังคงเผยแพร่คอนเทนต์ asm.js อยู่ แนะนำให้คอมไพล์ใหม่เป็น WebAssembly
    • การคอมไพล์ใหม่เป็น WebAssembly จะทำให้รันได้เร็วขึ้นและได้ไบนารีขนาดเล็กลง
    • ไปป์ไลน์ WebAssembly ของ SpiderMonkey พัฒนาไปไกลกว่าของ asm.js มาก
  • เมื่อ WebAssembly ประสบความสำเร็จ และการใช้งาน asm.js ส่วนใหญ่ได้ย้ายไปแล้ว ต้นทุนในการดูแลทั้งสองเส้นทางพร้อมกันจึงสูงขึ้น
    • ยังคงต้องใช้เวลาบำรุงรักษาอย่างต่อเนื่อง
    • และยังคงมี พื้นผิวการโจมตี เพิ่มเติมอยู่ภายใน VM

บทบาทของ asm.js และการสิ้นสุดของ OdinMonkey

  • asm.js คือคำตอบของ Mozilla ต่อคำถามที่ NaCl และ PNaCl ตั้งไว้ว่า “สามารถรันโค้ดด้วยความเร็วระดับเนทีฟบนเว็บได้หรือไม่”
    • แนวทางคือเลือกใช้ส่วนย่อยของ JavaScript ที่เข้มงวดและกำหนดชนิดแบบสแตติก ซึ่งเอนจินสามารถจดจำได้ทันที แล้วคอมไพล์เป็นโค้ดเนทีฟ
    • โดยยังคงอยู่ภายในคอนเทนต์เว็บ ใช้ Web API เดิมได้ โดยไม่ต้องมีแซนด์บ็อกซ์แยก, IPC หรือ API ทางเลือก
  • asm.js ถูกรวมเข้ามาใน Firefox 22 เมื่อปี 2013 และทำให้โปรเจกต์อย่าง Unity และ Unreal สามารถนำโค้ดเบส C/C++ ไปเผยแพร่บนเว็บได้ด้วยเทคโนโลยีเว็บมาตรฐานล้วน ๆ
    • Epic Citadel demo ถูกพอร์ตมาสู่เว็บภายในเวลาเพียง 4 วัน
    • asm.js พิสูจน์ให้เห็นว่าเทคโนโลยีเว็บเพียงอย่างเดียวก็สามารถรันโค้ดด้วยความเร็วใกล้เคียงเนทีฟได้ และเปิดทางไปสู่ WebAssembly ในเวลาต่อมา
    • WebAssembly ถูกรวมเข้าใน Firefox 52 ไม่กี่ปีถัดมา และหากไม่มี asm.js ก็มีความเป็นไปได้สูงว่า WebAssembly อาจจะไม่เกิดขึ้น
  • ชื่อของคอมไพเลอร์ asm.js คือ OdinMonkey และการลบระบบนี้กำลังถูกติดตามในบั๊ก Ragnarök ภายใต้ชื่อ “Twilight of OdinMonkey”
    • BaldrMonkey ที่ถือกำเนิดจาก OdinMonkey คือคอมไพเลอร์เพิ่มประสิทธิภาพของ WebAssembly
    • RabaldrMonkey คือคอมไพเลอร์แบบเบสไลน์ของ WebAssembly
    • OdinMonkey กำลังเข้าสู่ขั้นตอนยุติบทบาท หลังทำหน้าที่มาเป็นเวลา 13 ปี

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • asm.js คือคำตอบของ Mozilla ต่อคำถามที่ว่า “จะรันโค้ดบนเว็บให้เร็วระดับเนทีฟได้อย่างไร?” ซึ่งเป็นคำถามที่ NaCl และ PNaCl โยนไว้
    ถ้าเป็นตอนนี้ Chrome คงดัน NaCl และ PNaCl แบบไม่สนใครไปแล้ว และจากนั้นทุกคนก็คงบ่นว่า Safari กับ Firefox ทำไมถึงตามมาตรฐาน “เว็บ” ไม่ทัน

    • ฉันยังคิดว่าเราอยู่ในไทม์ไลน์ที่ผิดอยู่ดี PNaCl ตายไปแล้ว และแทนที่จะมีผู้สืบทอดที่คู่ควรมาทันเวลา เรากลับถูกต้มทั้งเป็นอยู่ในซุปแอป Electron
      อยู่ช่วงหนึ่งฉันเคยคิดจริงจังว่าเราจะทำทุกอย่างในเบราว์เซอร์กันหมด ในบางแง่ก็กำลังเป็นแบบนั้นมากขึ้นเรื่อย ๆ แต่ภาพรวมที่รู้สึกได้กลับแย่ลงกว่าที่เคย WASM ฉันก็ชอบและอยากจะชอบต่อไป แต่ความเร็วในการเติบโตของ ecosystem นี่แย่จนน่าเหลือเชื่อ
      ที่แย่กว่านั้นคือเราต้องรันเครื่องมือ AI ที่ไว้ใจไม่ได้พร้อมเอาต์พุตของมันใน sandbox แบบนั้นพอดี แต่บริษัทต่าง ๆ กลับขาย hosted sandbox กับ hosted JS-based VM กันแทน
      สุดท้ายดูเหมือนปัญหาจะเหมือนเดิมเสมอ ฝั่ง client-side sandbox มันไม่มีเงินให้ทำ
    • เท่าที่จำได้ไม่ใช่แบบนั้น มันเป็นการทดลองที่มีประโยชน์ในเวลานั้น แต่สุดท้ายก็ไปไม่รอด
      ภายในองค์กร มันมีประโยชน์ในการ sandbox Flash player แต่ข้อจำกัดของแนวทางแบบ อิง LLVM ก็ชัดเจนกับทุกคนที่เกี่ยวข้องในไม่ช้า
    • จริง ๆ ตอนนั้นพวกเขาก็พยายามทำแบบนั้นเป็นหลักอยู่แล้ว พยายามผลักผ่านคณะกรรมการมาตรฐานเว็บและทำตามขั้นตอนครบ
      ถ้าจำไม่ผิด สาเหตุใหญ่ที่ล้มเหลวคือ NaCl เป็นเทคโนโลยีที่ “ใหญ่” เกินไป ส่วน asm.js “เล็ก” เกินไป ทำให้ asm.js ไปถึงระดับพร้อมใช้จริงก่อน ทั้งที่เริ่มช้ากว่าหลายปี
    • น่าจะหมายถึง Chrome จะเป็นฝ่ายดันต่อไป ส่วน Apple ก็จะถ่วงเวลาแบบไม่พูดอะไรพร้อมกับไม่ลงทุนในทีม WebKit และผู้คนบนอินเทอร์เน็ตที่เชื่ออะไรง่ายก็จะเข้าข้าง Apple
      อย่างไรก็ตาม ดูเหมือน Apple จะเพิ่ม การลงทุนใน WebKit ในช่วงทศวรรษนี้หลังแรงกดดันด้านกฎระเบียบเริ่มจริงจัง ดังนั้นถ้าเป็นวันนี้ผลลัพธ์อาจต่างออกไป
    • คนจะบ่นเมื่อฟีเจอร์ที่ควรมีบนแพลตฟอร์มเว็บไม่มี ทางเลือกที่เข้ากันได้สูง ให้ใช้ และ asm.js รวมถึง Wasm ที่ตามมานั่นแหละคือทางเลือกนั้น
      เพราะแบบนี้ตอนนั้นเลยมีคนบ่นน้อยกว่า และตอนนี้คนถึงบ่นเรื่องที่ Safari ไม่ทำเพราะมันกระทบ App Store โชคดีที่ตอนนี้ EU กำลังพยายามจัดการ Apple ให้เข้าที่เข้าทางมากขึ้น

  • น่าเสียดาย แต่ก็เข้าใจได้ เรื่องน่าสนใจคือ Figma เดิมเริ่มจาก codebase C++ ล้วน และ asm.js เป็นตัวสำคัญที่พิสูจน์ว่าเครื่องมือออกแบบสามารถรันในเบราว์เซอร์ได้
    พวกเขาเปลี่ยนไปใช้ WebAssembly หลังจากมีลูกค้าที่จ่ายเงินแล้ว และเวลาโหลดก็ดีขึ้นมากพอสมควร asm.js ยังเป็น JS อยู่ จึงมีขนาด bundle ใหญ่กว่าและต้อง parse โค้ดเป็น AST แต่ WASM ไม่ต้อง

    • ไม่เห็นเข้าใจว่ามันน่าเศร้าตรงไหน มันก็เป็นแค่ คอมไพล์เป้าหมาย ที่เคยมีความหมายในยุคหนึ่ง
      ก็คล้ายกับไปเศร้าที่การรองรับ i386-unknown-freebsd1 ถูกถอดออก
    • ที่น่าเศร้าคือเราน่าจะมี แอปเดสก์ท็อป Figma แบบเนทีฟที่สะอาดเรียบร้อยก็ได้

  • ตอนนี้ความตายของ asm.js มาถึงแล้วหรือ? เรากำลังห่างออกจากไทม์ไลน์แห่งคำพยากรณ์
    https://www.destroyallsoftware.com/talks/the-birth-and-death...
    ถ้ายังไม่เคยดู ขอแนะนำอย่างยิ่ง ตามนิยามของคำว่า “ดีที่สุด” บางแบบ มันอาจเป็นการพูดสายเทคที่ดีที่สุดตลอดกาลก็ได้

    • การตายของเทคโนโลยีนี้ทำให้ เส้นด้ายแห่งคำพยากรณ์ ขาดสะบั้น คุณจะโหลดเซฟเก่ามาฟื้นการทอทับของโชคชะตา หรือจะฝืนอยู่ต่อไปในโลกที่พังพินาศด้วยมือของตัวเองก็ได้
    • ฉันกลับไปดูงานพูดนั้นปีละสองสามครั้งเสมอ มันเป็นตัวอย่างที่ยอดเยี่ยมของการทำพรีเซนต์และการจัดให้สไลด์เข้ากับการบรรยาย อีกทั้งยังพาชมโครงสร้าง permission ring ของระบบปฏิบัติการอย่างน่าประหลาดใจและให้ความรู้มาก
      สักวันหนึ่ง เมื่อเราผ่านช่วงเวลาแห่งสงครามและหลุดพ้นจากการยึดติดทางจิตใจกับกระบวนทัศน์การเขียนโปรแกรมแบบเก่า เราอาจขยับไปสู่วิธีที่ก้าวหน้ากว่าได้ แน่นอนว่านั่นก็ไม่ได้แปลว่าธนาคารของคุณจะหยุดรัน YavaScript ไปอีกอย่างน้อย 85 ปีข้างหน้า
    • ถ้าแทนที่ asm.js ด้วย WASM ก็ยังถือว่าเราอยู่บนเส้นทางเดิม
    • ไม่ต้องห่วง YavaScript จะอยู่ตลอดกาล
    • ถ้าเปลี่ยนคำว่าสงครามเป็น COVID ก็ถือว่าไม่ได้คลาดเคลื่อนไปมาก เพราะทั้งคู่เกิดขึ้นในปี 2020 ถ้าอยากรู้ว่าจริงไหมคงต้องรอถึงปี 2035

  • ฉันไม่มีวันลืมช่วงเวลาที่ได้ดูงานพูด JavaScript ของ Gary Bernhardt เป็นครั้งแรก[0] ตอนนั้นเองที่ฉันรู้จัก asm.js เป็นครั้งแรก และยังหลุดเข้าไปในโพรงกระต่ายของการคอมไพล์โค้ดให้รันบนเบราว์เซอร์ด้วย
    ผ่านมา 12 ปีแล้ว ตอนนี้น่าทึ่งมากว่ามีเรื่องแต่งของเขากลายเป็นจริงไปมากแค่ไหน
    [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

    • ส่วน “แอปหนา” (thick apps) ติดอยู่ในหัวฉันเสมอ ทั้งเพราะชื่อมันตลกและเพราะมันใกล้เคียงกับสถานการณ์ของฉันมาก
      ตอนที่ดูงานพูดนั้นครั้งแรก ฉันยังเป็นเด็กฝึกงานอยู่ และบริษัททำทั้งคอมไพเลอร์ IDE และดีบักเกอร์เองทั้งหมดสำหรับกล่อง industrial IO ขนาดเล็ก คอมไพเลอร์เขียนด้วย C จากนั้นแปลงเป็น JS ด้วย Emscripten แล้ว “คอมไพล์” มันรวมกับส่วน IDE และดีบักเกอร์ให้กลายเป็นไฟล์ HTML ขนาดมหึมาไฟล์เดียว ซึ่งจริง ๆ คือการเอามาต่อกันเฉย ๆ การอัปโหลดโค้ดกับดีบักทำผ่านอีเธอร์เน็ต และทุกอย่างถูกส่งผ่าน Ajax
      ฟังดูเหมือนสถาปัตยกรรมต้องคำสาป แต่ลูกค้ากลับชอบ เพราะมันไม่ใช่ EXE จึงไม่ติดตัวกรอง IT องค์กรสุดเข้มงวดของลูกค้า เราเลยไม่เปลี่ยนไปใช้ Electron ในบางแง่มันก็มี องค์ประกอบดั้งเดิม ของแอปหนาอยู่เหมือนกัน
    • ถ้าไม่ได้มีการผงาดขึ้นมาของ AI เป็นไปได้ว่า WASM อาจกลายเป็นคอมไพล์เป้าหมายระดับ machine-level สำหรับทุกภาษา Gary ทำนายอะไรไว้หลายอย่าง แต่เขาไม่เห็น AI

  • เมื่อนานมาแล้วฉันเคยเขียนบทสั้น ๆ เกี่ยวกับ asm.js ในหนังสือ WebGL
    https://webglinsights.github.io/
    การได้เห็น การเติบโตของ asm.js ซึ่งเป็นบรรพบุรุษของ WebAssembly เป็นเรื่องสนุก เดโมยุคแรก ๆ มีของเจ๋งจริง เช่น Unreal Engine ที่รันในเบราว์เซอร์ ตอนนี้เห็นมันลับขอบฟ้าก็รู้สึกขมขื่นอยู่บ้าง แต่ท้ายที่สุดมันก็พาไปสู่สิ่งที่ดีกว่ามาก

  • เราอาจต้องมี ทรานส์ไพเลอร์ จาก asm.js ไป WASM
    การคอมไพล์โค้ดเก่าด้วย Emscripten เวอร์ชันเก่านั้นชวนหงุดหงิดไม่น้อย บางครั้งก็ทรมานพอ ๆ กับการไล่อัปเดตโค้ด JS ให้ทันกับการเปลี่ยนแปลง ABI ของ Emscripten ที่สะสมมาเรื่อย ๆ

    • เมื่อก่อน Binaryen เคยมีเครื่องมือ asm2wasm แต่เท่าที่รู้ตอนนี้เลิกใช้ไปแล้ว ยังหาเครื่องมืออื่นที่เทียบเท่ากันไม่เจอ
      อย่างน้อยต่อให้ปิด asm.js optimization ไป โค้ด asm.js ก็น่าจะยังทำงานได้ แต่ถ้ามีตัวแปลงก็คงดี
    • https://porffor.dev/

  • asm.js ตายแล้ว! WebAssembly จงเจริญ!

    • พูดอย่างเป็นธรรม พอ wasm มา asm.js ก็ดูเหมือนถูกประกาศ เตรียมเลิกใช้ ไปแล้วตั้งแต่หลายปีก่อน

  • โดยส่วนตัวฉันคิดว่าการตัดสินใจนี้เป็นความผิดพลาด แต่ก็ไม่แน่ใจว่าผลกระทบจริงจะมากแค่ไหน เท่าที่รู้ตอนนี้คงมีคนใช้ asm.js ไม่มากแล้ว
    แต่ wasm แยกตัวออกจาก JavaScript มากเกินไป หลังจากลองใช้แบบจำกัด ๆ แล้ว ฉันถึงขั้นคิดว่าเอางานนี้ คอมไพล์เป็น asm.js แทนดีไหม
    ฉันยังไม่แน่ใจเลยว่า Emscripten ยังรองรับแบบเต็มรูปแบบอยู่หรือเปล่า
    ใน wasm คุณเรียก web API ส่วนใหญ่ไม่ได้
    และสำหรับงานที่ฉันจะทำ สิ่งที่สำคัญกว่านั้นคือ คุณส่ง บัฟเฟอร์แบบ zero-copy จาก JS ไปยัง wasm ไม่ได้
    ทุกอย่างมีการแลกเปลี่ยน ข้อดีของการแยกตัวก็คือมันเป็นข้อเสียด้วย

    • asm.js น่าจะจำกัดกว่า wasm เสียอีกในเรื่องการทำงานร่วมกับ JS โดยพื้นฐานแล้วมันจำกัดอยู่แค่ค่าตัวเลขง่าย ๆ กับ array buffer เท่านั้น
      แต่ทุกวันนี้ wasm มี GC types แล้ว และยังใช้ externref เพื่ออ้างถึงค่า JS ได้ด้วย
      asm.js เองก็น่าจะทำ zero-copy buffer ไม่ได้เหมือนกัน ฝั่ง wasm มีข้อเสนอเรื่อง zero-copy buffer อยู่: https://github.com/WebAssembly/memory-control/blob/main/prop...
    • ถ้าจำไม่ผิด Emscripten ถอด การรองรับ asm.js ออกราวปี 2020 และมันน่าจะเป็น toolchain ที่สำคัญที่สุดที่เคยรองรับ asm.js ส่วนอีกตัวอาจเป็น Rust แต่ไม่แน่ใจว่ายังรองรับอยู่ไหม
      แม้แต่ asm.js แบบเข้มงวดก็เรียก web API ส่วนใหญ่โดยตรงไม่ได้ มันรองรับแค่ตัวเลข ไม่รองรับสตริง JS หรืออ็อบเจ็กต์ และจัดการ C heap ภายในอ็อบเจ็กต์ ArrayBuffer แบบเดียวกับ WASM
      zero-copy buffer ก็เจอปัญหาเดียวกัน ใน asm.js คุณต้องหลุดออกไปเรียก JavaScript “จริง” ก่อน และก็ไม่สามารถแมป ArrayBuffer ตัวอื่นเข้ากับ heap ของ asm.js ได้โดยตรง จึงต้องมีการคัดลอก “JavaScript FFI” แทบไม่ได้ต่างกันมากระหว่าง asm.js กับ WASM
    • ถ้าฉันไม่ได้เข้าใจผิด asm.js ก็มีข้อจำกัดแบบเดียวกันไม่ใช่หรือ? คือโค้ด asm.js เรียก web API โดยตรงไม่ได้ และก็ยังต้องมีการจัดการแยกต่างหากสำหรับฟังก์ชัน “ภายนอก” อยู่ดี

  • ฉันจำได้ตอนที่ Mozilla เปิดตัว OdinMonkey ซึ่งจูนมาเฉพาะอย่างหนักสำหรับโค้ด asm.js ส่วนทีม Chrome/V8 เลือกโฟกัสไปที่การปรับแต่ง JIT แบบทั่วไปที่ทำให้ JavaScript ทั่วไปเร็วขึ้นและช่วย asm.js ไปด้วย
    ความต่างด้านความเร็วตอนนั้น Firefox นำอยู่ 2 ถึง 4 เท่า และพวกเขาก็โปรโมตเรื่องนี้ค่อนข้างหนักเลย :D
    ทุกวันนี้ JavaScript VM ของเบราว์เซอร์ส่วนใหญ่มีแนวโน้มไปสู่สถาปัตยกรรมและการปรับแต่งที่คล้ายกันมาก ดังนั้นถึงไม่มี Odin โค้ด asm.js ก็น่าจะยังรันได้เร็วพอสมควรอยู่ดี

  • แผนของฉันที่จะสร้างโค้ด JS ตอนรันไทม์เพื่อทำให้อัลกอริทึมเร็วขึ้นคงจบแล้ว ทำแบบนี้กับ wasm น่าจะยากกว่ามาก

    • การสร้างโค้ด wasm ตอนรันไทม์นั้นค่อนข้างง่าย อาจง่ายกว่าการสร้างโค้ด asm.js ที่ถูกต้องด้วยซ้ำ
      มีไลบรารีเล็ก ๆ สำหรับการทดสอบที่จัดการงานแบบนั้นได้พอสมควร: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
    • ถ้าใช้ไลบรารีก็ไม่ได้ยากกว่าเลย ใน Rust ใช้อันนี้ได้: https://crates.io/crates/wasm-encoder
      ส่วนใน JS ก็น่าจะใช้ https://www.npmjs.com/package/binaryen
    • ยังมี AssemblyScript อยู่นะ ถ้าฉันไม่ได้เข้าใจผิดหรือจำฟีเจอร์มันผิด มันอาจตรงกับความต้องการของคุณ
      https://www.assemblyscript.org/
    • ก็ลองใช้ subset ของ asm.js ไปเลยแล้วดูว่า performance เป็นอย่างไร ฉันจำได้ว่าต่อให้ไม่มี การรองรับ asm.js แบบพิเศษในเบราว์เซอร์ ประสิทธิภาพของเอาต์พุตจาก Emscripten ก็ยังดีจนน่าประหลาดใจ
    • มันน่าจะยังทำงานได้อยู่ asm.js ก็เป็นโค้ด JavaScript ปกตินั่นเอง
      แค่จะไม่ parse หรือ execute ได้เร็วเหมือน pipeline เฉพาะสำหรับ asm.js เท่านั้น ถ้าไม่ใช่แอปขนาดมหึมาจริง ๆ ก็คงไม่รู้สึกถึงความต่างมากนัก