Mengucapkan selamat tinggal kepada asm.js

 (spidermonkey.dev)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Mulai Firefox 148, optimisasi asm.js di SpiderMonkey dinonaktifkan secara default, dan kode terkait akan dihapus pada rilis mendatang
  • asm.js adalah subset JavaScript, jadi situs yang ada akan tetap berfungsi, tetapi dijalankan melalui jalur JIT umum sehingga keunggulan optimisasinya hilang
  • Konten asm.js bisa dikompilasi ulang ke WebAssembly untuk mendapatkan eksekusi yang lebih cepat dan biner yang lebih kecil
  • asm.js memungkinkan eksekusi yang mendekati native di dalam konten web tanpa sandbox terpisah atau API pengganti, sebagai tandingan terhadap NaCl·PNaCl
  • OdinMonkey yang masuk di Firefox 22 pada 2013 memungkinkan distribusi web C/C++ seperti Unity dan Unreal, dan menjadi fondasi menuju WebAssembly

Menonaktifkan optimisasi asm.js

  • Mulai Firefox 148, optimisasi asm.js di SpiderMonkey dinonaktifkan secara default, dan seluruh kode terkait dijadwalkan akan dihapus pada rilis mendatang
  • Situs yang menggunakan asm.js akan tetap berjalan
    • asm.js adalah subset dari JavaScript biasa, sehingga kode yang ada akan dijalankan melalui jalur JIT umum seperti skrip lainnya
    • Namun, keuntungan optimisasi khusus asm.js tidak lagi tersedia
  • Jika Anda masih mendistribusikan konten asm.js, disarankan untuk mengompilasinya ulang ke WebAssembly
    • Dengan mengompilasi ulang ke WebAssembly, Anda bisa mendapatkan eksekusi yang lebih cepat dan biner yang lebih kecil
    • Pipeline WebAssembly di SpiderMonkey sudah jauh lebih maju dibanding pipeline asm.js
  • Karena WebAssembly telah sukses dan sebagian besar penggunaan asm.js sudah bermigrasi, biaya mempertahankan kedua jalur sekaligus menjadi besar
    • Tetap membutuhkan waktu pemeliharaan
    • Menyisakan permukaan serangan tambahan di dalam VM

Peran asm.js dan berakhirnya OdinMonkey

  • asm.js adalah jawaban Mozilla atas pertanyaan yang diajukan oleh NaCl dan PNaCl: “bisakah kode dijalankan di web dengan kecepatan native?”
    • Pendekatannya adalah memilih subset JavaScript yang ketat dan bertipe statis, yang bisa dikenali mesin saat itu juga lalu dikompilasi menjadi kode native
    • Ini memungkinkan tetap berada di dalam konten web dan menggunakan Web API yang ada tanpa sandbox terpisah, IPC, atau API pengganti
  • asm.js dimasukkan ke Firefox 22 pada 2013, dan memungkinkan proyek seperti Unity dan Unreal mendistribusikan codebase C/C++ mereka ke web hanya dengan teknologi web standar
  • Nama compiler asm.js adalah OdinMonkey, dan proses penghapusannya dilacak di bug Ragnarök sebagai “Twilight of OdinMonkey”
    • BaldrMonkey yang lahir dari OdinMonkey adalah compiler optimisasi WebAssembly
    • RabaldrMonkey adalah compiler baseline WebAssembly
    • OdinMonkey kini memasuki tahap akhir setelah menyelesaikan perannya selama 13 tahun

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • asm.js adalah jawaban Mozilla atas pertanyaan yang diajukan NaCl dan PNaCl: “bagaimana menjalankan kode dengan kecepatan native di web?”
    Kalau ini terjadi sekarang, Chrome mungkin akan langsung memaksakan NaCl dan PNaCl, lalu semua orang akan mengeluh kenapa Safari dan Firefox tidak bisa mengikuti standar “web”

    • Saya masih merasa kita berada di garis waktu yang salah. PNaCl sudah mati, dan alih-alih mendapat penerus yang layak tepat waktu, kita malah direbus hidup-hidup dalam sup aplikasi Electron
      Dulu saya sempat serius berpikir bahwa untuk sementara waktu kita akan melakukan segalanya di browser. Dalam arti tertentu memang makin ke sana, tapi secara keseluruhan rasanya lebih buruk daripada sebelumnya. Saya suka WASM dan ingin terus menyukainya, tetapi kecepatan pematangan ekosistemnya benar-benar sulit dipercaya buruknya
      Yang lebih parah, kita harus menjalankan alat AI yang tidak dapat diandalkan beserta hasil keluarannya di dalam sandbox semacam itu, tetapi perusahaan malah menjual sandbox terhosting dan VM berbasis JS terhosting, yaitu kebalikan total dari itu
      Pada akhirnya, sepertinya masalahnya selalu sama. Tidak ada uang di sandbox sisi klien
    • Seingat saya tidak begitu. Itu eksperimen yang berguna pada masanya, tetapi pada akhirnya tidak berjalan baik
      Secara internal itu berguna untuk menyandbox Flash player, tetapi batasan dari pendekatan berbasis LLVM segera menjadi jelas bagi semua pihak yang terlibat
    • Sebenarnya, saat itu mereka pada dasarnya memang mencoba melakukan itu. Mereka berusaha meloloskannya melalui komite standar web dan mengikuti prosesnya
      Kalau ingatan saya benar, alasan besar kenapa gagal adalah karena NaCl adalah teknologi yang terlalu “besar” dan asm.js terlalu “kecil”, sehingga meskipun asm.js mulai beberapa tahun lebih lambat, ia mencapai kesiapan produksi lebih dulu
    • Maksudnya mungkin Chrome akan memaksakannya, Apple akan mengulur waktu dengan tidak banyak bicara sambil tidak berinvestasi pada tim WebKit, dan orang-orang internet yang mudah dibujuk akan menyesuaikan diri dengan posisi Apple
      Namun, Apple tampaknya sudah meningkatkan investasi WebKit pada dekade ini setelah tekanan regulasi mulai nyata, jadi hasilnya bisa saja berbeda kalau terjadi hari ini
    • Keluhan muncul ketika ada fitur yang berguna di platform web tetapi tidak ada alternatif berkompatibilitas tinggi. asm.js dan kemudian Wasm adalah alternatif seperti itu
      Karena itu dulu keluhannya lebih sedikit, sedangkan sekarang orang mengeluhkan hal-hal yang Safari tidak lakukan karena dianggap merugikan App Store. Untungnya, UE sekarang sedang mencoba sedikit meluruskan Apple

  • Sedih, tapi bisa dimengerti. Fakta menariknya, Figma awalnya dimulai sebagai codebase C++ penuh, dan asm.js adalah kunci untuk membuktikan bahwa alat desain bisa dijalankan di browser
    Mereka baru beralih ke WebAssembly setelah mulai punya pelanggan berbayar, dan peningkatan waktu muatnya juga cukup besar. asm.js tetaplah JS, jadi ukuran bundelnya lebih besar dan kodenya harus diparse menjadi AST, sedangkan WASM tidak begitu

    • Saya tidak paham apa yang begitu menyedihkan. Itu hanya target kompilasi yang dulu pernah relevan
      Mirip seperti bersedih karena dukungan i386-unknown-freebsd1 dihapus
    • Yang sedih adalah kita sebenarnya bisa saja punya aplikasi desktop Figma native yang rapi

  • Jadi sekarang kematian asm.js sudah tiba? Kita makin menjauh dari garis waktu nubuat
    https://www.destroyallsoftware.com/talks/the-birth-and-death...
    Sangat direkomendasikan kalau belum pernah menontonnya. Bergantung pada definisi “terbaik”, ini mungkin salah satu presentasi teknologi terbaik sepanjang masa

    • Dengan matinya teknologi ini, benang nubuat pun terputus. Tinggal memuat save game lama untuk memulihkan tenunan takdir, atau bertahan hidup di dunia rusak buatan sendiri
    • Saya menonton ulang presentasi itu dua atau tiga kali setahun. Itu contoh hebat tentang bagaimana cara memberi presentasi, bagaimana menyelaraskan slide deck dengan pembicaraan, dan secara mengejutkan juga memberi tinjauan yang cukup mendidik tentang struktur ring hak akses dalam sistem operasi
      Suatu hari nanti, setelah melewati masa perang dan keterikatan psikologis pada paradigma pemrograman lama memudar, kita mungkin akan beralih ke cara yang lebih maju. Tentu saja, itu tidak berarti bank Anda akan berhenti menjalankan YavaScript setidaknya selama 85 tahun ke depan
    • Jika Anda mengganti asm.js dengan WASM, Anda masih berada di jalur yang benar
    • Tidak perlu khawatir. YavaScript akan hidup selamanya
    • Jika perang diganti dengan COVID, keduanya sama-sama terjadi pada 2020, jadi tidak terlalu meleset. Kita masih harus menunggu sampai 2035 untuk tahu apakah itu benar

  • Saya tidak akan pernah lupa saat pertama kali menonton presentasi JavaScript dari Gary Bernhardt.[0] Di situlah saya pertama kali mengenal asm.js, dan lalu terjun ke lubang kelinci kompilasi kode agar bisa berjalan di browser
    Sekarang, 12 tahun kemudian, menakjubkan melihat berapa banyak fiksinya yang ternyata menjadi kenyataan
    [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

    • Bagian “thick apps” selalu melekat di ingatan saya. Namanya lucu, dan juga cukup dekat dengan situasi saya sendiri
      Saat pertama kali menonton presentasi itu, saya masih magang, dan perusahaan membuat sendiri seluruh compiler, IDE, dan debugger untuk kotak IO industri kecil. Compilernya ditulis dalam C, diubah menjadi JS dengan Emscripten, lalu “dikompilasi” bersama bagian IDE dan debugger menjadi satu file HTML raksasa, yang pada praktiknya lebih seperti disambung jadi satu. Upload kode dan debugging dilakukan lewat Ethernet, semuanya didorong lewat Ajax
      Kedengarannya seperti arsitektur terkutuk, tapi pelanggan menyukainya. Karena itu bukan EXE, jadi tidak tersangkut filter TI perusahaan pelanggan yang berlebihan. Karena itulah kami tidak beralih ke Electron. Dalam arti tertentu, itu memang punya elemen purba dari thick app
    • Andai kebangkitan AI tidak terjadi, WASM mungkin bisa menjadi target kompilasi tingkat mesin untuk semua bahasa. Gary memprediksi banyak hal, tetapi dia tidak melihat AI datang

  • Dulu sekali saya pernah menulis bab kecil tentang asm.js dalam buku WebGL
    https://webglinsights.github.io/
    Menyaksikan kebangkitan asm.js, pendahulu WebAssembly, itu menyenangkan. Beberapa demo awalnya benar-benar keren, seperti Unreal Engine yang berjalan di browser. Agak pahit melihat matahari terbenam di sini, tetapi itu membuka jalan ke hal-hal yang jauh lebih baik

  • Mungkin kita butuh transpiler dari asm.js ke WASM
    Mengompilasi kode lama dengan Emscripten versi lawas cukup menjengkelkan. Kadang rasanya sama menyakitkannya dengan memperbarui kode JS agar sesuai dengan akumulasi perubahan ABI Emscripten

    • Binaryen dulu punya alat asm2wasm, tetapi setahu saya sekarang sudah ditinggalkan. Saya belum menemukan alat lain yang setara
      Setidaknya kode asm.js akan tetap berjalan meski optimisasi asm.js dimatikan, tetapi akan bagus jika ada konverternya
    • https://porffor.dev/

  • asm.js sudah mati! Hidup WebAssembly!

    • Kalau mau adil, saya kira asm.js sudah dinyatakan akan dihentikan beberapa tahun lalu ketika wasm muncul

  • Secara pribadi saya menganggap keputusan ini sebagai kesalahan. Meski begitu, saya tidak tahu seberapa besar dampak nyatanya. Setahu saya, masih belum banyak orang yang memakai asm.js
    Tapi wasm terlalu terisolasi dari JavaScript. Setelah memakainya secara terbatas, saya sempat berpikir lebih baik kompilasi ke asm.js saja
    Saya juga tidak yakin apakah Emscripten masih mendukungnya sepenuhnya
    Di wasm, sebagian besar web API tidak bisa dipanggil
    Untuk pekerjaan yang ingin saya lakukan, yang lebih penting lagi, Anda tidak bisa mengirim buffer zero-copy dari JS ke wasm
    Semua hal adalah kompromi. Isolasi itu kelebihan, tetapi juga kekurangan

    • Dalam hal interaksi dengan JS, asm.js pasti justru lebih terbatas daripada wasm. Pada dasarnya hanya terbatas pada nilai numerik sederhana dan array buffer
      Sementara wasm modern punya GC types, dan dengan externref juga bisa menahan nilai JS
      asm.js kemungkinan juga tidak bisa melakukan buffer zero-copy. Di sisi wasm ada proposal buffer zero-copy: https://github.com/WebAssembly/memory-control/blob/main/prop...
    • Kalau ingatan saya benar, Emscripten menghapus dukungan asm.js sekitar 2020, dan itu mungkin toolchain paling penting yang mendukung asm.js. Setelah itu mungkin Rust, tetapi saya tidak tahu apakah masih mendukungnya
      Bahkan pada asm.js yang ketat pun, sebagian besar web API tidak bisa dipanggil langsung. Ia hanya mendukung angka, bukan string atau objek JS, karena heap C dikelola di dalam objek ArrayBuffer seperti pada WASM
      Buffer zero-copy juga bermasalah sama. Anda harus keluar dari asm.js ke JavaScript “asli” untuk memanggilnya, dan Anda juga tidak bisa memetakan ArrayBuffer lain langsung ke heap asm.js, jadi perlu penyalinan. “JavaScript FFI” pada praktiknya tidak banyak berbeda antara asm.js dan WASM
    • Kalau saya tidak salah paham, bukankah asm.js juga punya keterbatasan yang sama? Maksudnya, kode asm.js juga tidak bisa langsung memanggil web API, dan tetap memerlukan penanganan terpisah untuk fungsi “eksternal”

  • Saya ingat saat Mozilla merilis OdinMonkey yang sangat terspesialisasi untuk kode asm.js. Tim Chrome/V8 justru memilih fokus pada optimisasi JIT umum yang mempercepat JavaScript biasa sambil tetap membantu asm.js juga
    Perbedaan kecepatannya membuat Firefox unggul 2–4x, dan itu dipromosikan cukup gencar :D
    Sekarang kebanyakan VM JavaScript browser sudah berkumpul pada desain dan optimisasi yang sangat mirip, jadi bahkan tanpa Odin, kode asm.js tetap akan berjalan cukup cepat

  • Rencana saya untuk menghasilkan kode JS saat runtime demi mempercepat algoritme sekarang pupus. Rasanya ini akan jauh lebih sulit dilakukan dengan wasm

    • Menghasilkan kode wasm saat runtime sebenarnya cukup mudah. Bahkan mungkin lebih mudah daripada menghasilkan kode asm.js yang valid
      Ada pustaka kecil untuk pengujian yang menangani cukup banyak pekerjaan seperti itu: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
    • Kalau memakai pustaka, itu tidak lebih sulit. Di Rust Anda bisa pakai ini: https://crates.io/crates/wasm-encoder
      Di JS, kemungkinan Anda akan memakai https://www.npmjs.com/package/binaryen
    • Masih ada AssemblyScript. Kalau saya tidak salah paham atau salah mengerti kemampuannya, ini mungkin cocok dengan kebutuhan Anda
      https://www.assemblyscript.org/
    • Tinggal pakai subset asm.js saja dan lihat bagaimana performanya. Saya ingat performa output Emscripten sangat mengejutkan bagus bahkan tanpa dukungan asm.js khusus dari browser
    • Itu masih akan tetap berjalan. asm.js pada akhirnya hanyalah kode JavaScript biasa
      Hanya saja, ia tidak akan diparse atau dijalankan secepat pipeline khusus asm.js. Kecuali aplikasinya benar-benar sangat besar, saya rasa perbedaannya tidak akan terlalu terasa