asm.js को अलविदा कहना

 (spidermonkey.dev)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Firefox 148 से SpiderMonkey का asm.js optimization डिफ़ॉल्ट रूप से disable कर दिया गया है, और आगे की रिलीज़ में इससे जुड़ा कोड हटा दिया जाएगा
  • asm.js, JavaScript का एक subset है, इसलिए मौजूदा साइटें चलती रहेंगी, लेकिन वे सामान्य JIT path पर चलेंगी और optimization का लाभ खत्म हो जाएगा
  • asm.js content को WebAssembly में दोबारा compile करने पर तेज़ execution और छोटे binaries मिल सकते हैं
  • asm.js ने NaCl·PNaCl के मुकाबले बिना अलग sandbox या alternative API के web content के भीतर native-जैसा execution संभव बनाया
  • 2013 में Firefox 22 में शामिल OdinMonkey ने Unity·Unreal जैसे C/C++ web deployment को संभव बनाया और WebAssembly की नींव रखी

asm.js optimization disable

  • Firefox 148 से SpiderMonkey का asm.js optimization डिफ़ॉल्ट रूप से disable कर दिया गया है, और आने वाली रिलीज़ में इससे जुड़ा पूरा कोड हटा दिया जाएगा
  • asm.js इस्तेमाल करने वाली साइटें चलती रहेंगी
    • asm.js, सामान्य JavaScript का एक subset है, इसलिए मौजूदा कोड दूसरे scripts की तरह सामान्य JIT path पर execute होगा
    • लेकिन asm.js-विशेष optimization का फायदा अब नहीं मिलेगा
  • अगर आप अभी भी asm.js content deploy कर रहे हैं, तो उसे WebAssembly में दोबारा compile करने की सिफारिश की जाती है
    • WebAssembly में दोबारा compile करने पर तेज़ execution और छोटे binaries मिल सकते हैं
    • SpiderMonkey का WebAssembly pipeline, asm.js pipeline की तुलना में कहीं अधिक विकसित है
  • WebAssembly के सफल हो जाने और asm.js के ज़्यादातर उपयोग पहले ही migrate हो जाने से दोनों paths को साथ बनाए रखने की लागत बढ़ गई है
    • maintenance में लगातार समय लगता है
    • VM के भीतर अतिरिक्त attack surface बना रहता है

asm.js की भूमिका और OdinMonkey का अंत

  • asm.js NaCl और PNaCl के इस सवाल का Mozilla का जवाब था: “क्या web पर native speed से code चलाया जा सकता है?”
    • यह एक सख्त और statically typed JavaScript subset था, जिसे engine तुरंत पहचानकर native code में compile कर सकता था
    • इससे अलग sandbox, IPC, या alternative API के बिना web content के भीतर रहकर मौजूदा web APIs का इस्तेमाल किया जा सकता था
  • asm.js को 2013 में Firefox 22 में शामिल किया गया था, और इसने Unity और Unreal जैसे projects को केवल standard web technologies के ज़रिए अपने C/C++ codebase को web पर deploy करने में सक्षम बनाया
    • Epic Citadel demo को सिर्फ 4 दिनों में web पर port किया गया था
    • asm.js ने साबित किया कि केवल web technologies के ज़रिए लगभग native-जैसी speed पर code चलाया जा सकता है, और इसी ने आगे WebAssembly का रास्ता खोला
    • WebAssembly को कुछ साल बाद Firefox 52 में शामिल किया गया, और asm.js के बिना संभावना है कि WebAssembly भी नहीं होता
  • asm.js compiler का नाम OdinMonkey था, और इसे हटाने का काम Ragnarök bug में “Twilight of OdinMonkey” नाम से track किया जा रहा है
    • OdinMonkey से जन्मा BaldrMonkey, WebAssembly optimization compiler है
    • RabaldrMonkey WebAssembly baseline compiler है
    • OdinMonkey, 13 साल की अपनी भूमिका पूरी करके अब विदाई की प्रक्रिया में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News टिप्पणियाँ

  • asm.js, NaCl और PNaCl के उस सवाल पर Mozilla का जवाब था: “वेब पर कोड को native speed से कैसे चलाया जाए?”
    अगर यह आज होता, तो Chrome शायद NaCl और PNaCl को बस आगे बढ़ा देता, और फिर सब लोग शिकायत करते कि Safari और Firefox “वेब” standards के साथ क्यों नहीं चल रहे

    • मुझे अब भी लगता है कि हम गलत timeline में हैं। PNaCl मर चुका है, और समय पर आए किसी dostoin uttaradhikari की जगह हम Electron apps के सूप में जिंदा उबाले जा रहे हैं
      कुछ समय तक मैं सच में सोचता था कि हम सब कुछ browser में ही करेंगे। एक मायने में हम धीरे-धीरे वहीं जा भी रहे हैं, लेकिन कुल अनुभव पहले से भी बदतर लगता है। मुझे WASM पसंद है और पसंद करना भी चाहता हूँ, लेकिन ecosystem की maturity की रफ्तार यकीन से परे खराब रही है
      इससे भी बुरा यह है कि अविश्वसनीय AI tools और their output को ठीक ऐसे ही sandbox के अंदर चलाना चाहिए, लेकिन कंपनियाँ उल्टा hosted sandbox और hosted JS-based VM बेच रही हैं
      आखिरकार समस्या हमेशा वही लगती है। client-side sandbox में पैसा नहीं था
    • मेरी याद के मुताबिक ऐसा नहीं था। उस समय यह एक उपयोगी experiment था, लेकिन अंत में बात बनी नहीं
      अंदरूनी तौर पर यह Flash player को sandbox करने में काम आया, लेकिन LLVM-आधारित approach की सीमाएँ जल्द ही इसमें शामिल सभी लोगों के लिए साफ हो गईं
    • असल में उस समय भी मूल योजना यही थी। वे इसे web standards committees के रास्ते आगे बढ़ाना चाहते थे और प्रक्रिया से भी गुज़रे
      अगर मुझे सही याद है, तो असफलता की बड़ी वजह यह थी कि NaCl बहुत “बड़ी” technology थी और asm.js बहुत “छोटी”, इसलिए asm.js कुछ साल बाद शुरू होने के बावजूद पहले production-ready हो गया
    • शायद मतलब यह है कि Chrome इसे धक्का देता, Apple WebKit team में निवेश किए बिना चुप रहकर समय खींचता, और इंटरनेट पर आसानी से बहकने वाले लोग Apple के हिसाब से खुद को ढाल लेते
      हालांकि regulation का दबाव बढ़ने के बाद Apple ने इस दशक में WebKit investment बढ़ाया है, इसलिए आज नतीजा अलग हो सकता है
    • जब web platform के लिए उपयोगी किसी feature का high-compatibility alternative नहीं होता, तब शिकायतें होती हैं। asm.js और बाद में आया Wasm वही विकल्प थे
      इसलिए तब शिकायतें कम थीं, और अब शिकायतें उन चीज़ों पर होती हैं जो Safari App Store को नुकसान पहुँचाने के कारण नहीं करता। अच्छी बात है कि EU अब Apple को कुछ हद तक सही दिशा में धकेल रहा है

  • दुखद है, लेकिन समझ में आता है। एक दिलचस्प बात यह है कि Figma की शुरुआत पूरी C++ codebase के रूप में हुई थी, और asm.js यह साबित करने की कुंजी था कि browser में design tools चल सकते हैं
    WebAssembly पर स्विच paid customers आने के बाद हुआ, और load time में सुधार भी काफ़ी बड़ा था। asm.js आखिर JS ही है, इसलिए bundle size बड़ा रहता है और code को AST में parse करना पड़ता है, जबकि WASM में ऐसा नहीं है

    • मुझे समझ नहीं आता कि इसमें इतना दुख किस बात का है। यह बस एक compile target था जिसका कभी महत्व था
      जैसे i386-unknown-freebsd1 support हटने पर दुख मनाना
    • दुख की बात यह है कि शायद हमारे पास एक साफ-सुथरा native desktop Figma app हो सकता था

  • तो क्या अब asm.js की मौत आ गई? हम भविष्यवाणी वाली timeline से दूर जा रहे हैं
    https://www.destroyallsoftware.com/talks/the-birth-and-death...
    अगर आपने अभी तक इसे नहीं देखा है, तो ज़ोरदार सिफारिश है। “सर्वश्रेष्ठ” की आपकी परिभाषा पर निर्भर करते हुए, यह अब तक की सबसे बेहतरीन tech talks में से एक हो सकती है

    • this technology की मौत से भविष्यवाणी का धागा टूट गया है। अब या तो saved game लोड करके destiny की बुनावट फिर से बहाल करो, या अपने बनाए हुए बर्बाद संसार में ही टिके रहो
    • मैं उस talk को साल में दो-तीन बार फिर देखता हूँ। यह इस बात का शानदार उदाहरण है कि presentation कैसे देनी चाहिए, slide deck को talk के साथ कैसे sync करना चाहिए, और यह operating system के privilege ring structure पर भी हैरान करने वाला अच्छा educational overview देती है
      कभी न कभी, जब हम युद्ध के दौर से निकल जाएँगे और पुराने programming paradigms के प्रति मनोवैज्ञानिक लगाव ढीला पड़ेगा, तब हम और उन्नत तरीकों की तरफ़ बढ़ पाएँगे। बेशक इसका मतलब यह नहीं कि आपका bank अगले कम-से-कम 85 साल तक YavaScript चलाना बंद कर देगा
    • अगर asm.js को WASM से बदल दें, तो भी बात अब तक सही बैठती है
    • चिंता की कोई बात नहीं। YavaScript हमेशा जिंदा रहेगा
    • अगर युद्ध को COVID से बदल दें, तो दोनों 2020 में ही हुए थे, इसलिए यह बहुत दूर नहीं जाता। सच जानने के लिए हमें अभी भी 2035 तक इंतज़ार करना होगा

  • Gary Bernhardt की JavaScript talk मैंने जिस पल देखी थी, उसे मैं कभी नहीं भूलूँगा.[0] वहीं मुझे पहली बार asm.js के बारे में पता चला, और browser में चलने के लिए code compile करने वाली rabbit hole में भी मैं उतर गया
    12 साल बाद यह देखकर हैरानी होती है कि उसकी fiction का कितना हिस्सा सच बन चुका है
    [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

    • “thick apps” वाला हिस्सा मुझे हमेशा याद रहा। नाम भी मज़ेदार था, और मेरी स्थिति के भी काफ़ी करीब था
      जब मैंने वह talk पहली बार देखी, मैं intern था, और मेरी कंपनी छोटे industrial IO boxes के लिए compiler, IDE, debugger सब कुछ खुद बनाती थी। compiler C में लिखा था, उसे Emscripten से JS में बदला जाता था, फिर IDE और debugger वाले हिस्सों के साथ एक विशाल HTML file में “compile” किया जाता था, जो असल में जोड़ना भर था। code upload और debugging Ethernet से होती थी, और सब कुछ Ajax से भेजा जाता था
      यह सुनने में शापित architecture जैसा लगता है, लेकिन customers को यह पसंद था। क्योंकि यह EXE नहीं था, इसलिए उनकी कंपनियों के ज़रूरत से ज़्यादा सख्त corporate IT filters में नहीं फँसता था। इसी वजह से हमने Electron पर switch नहीं किया। एक अर्थ में उसमें thick apps के आदिम तत्व मौजूद थे
    • अगर AI का उभार न हुआ होता, तो शायद WASM सभी भाषाओं के लिए machine-level compile target बन जाता। Gary ने बहुत कुछ सही देखा था, लेकिन AI नहीं देख पाया

  • बहुत पहले मैंने एक WebGL किताब में asm.js पर एक छोटा chapter लिखा था
    https://webglinsights.github.io/
    WebAssembly के पूर्वज asm.js के उभार को देखना मज़ेदार था। शुरुआती demos में browser में Unreal Engine चलने जैसी वाकई शानदार चीज़ें थीं। इसका यहाँ सूर्यास्त देखना थोड़ा कड़वा-मीठा है, लेकिन इसने कहीं बेहतर चीज़ों का रास्ता खोला

  • शायद asm.js से WASM में जाने वाला कोई transpiler चाहिए
    legacy Emscripten versions से legacy code compile करना काफ़ी निराशाजनक है। कई बार यह accumulated Emscripten ABI changes के हिसाब से JS code अपडेट करने जितना ही दर्दनाक होता है

    • Binaryen में पहले asm2wasm tool हुआ करता था, लेकिन मेरी जानकारी में अब वह deprecated है। मुझे दूसरा समान tool नहीं मिला
      कम-से-कम asm.js optimizations बंद होने पर भी asm.js code चलता रहेगा, लेकिन converter होना अच्छा रहेगा
    • https://porffor.dev/

  • asm.js मर गया! WebAssembly अमर रहे!

    • निष्पक्ष रूप से कहूँ, तो wasm आने के साथ ही मुझे लगा था कि asm.js कुछ साल पहले ही deprecated हो चुका होगा

  • निजी तौर पर मुझे यह फ़ैसला गलती लगता है। हालांकि वास्तविक असर कितना बड़ा होगा, यह पता नहीं। जहाँ तक मुझे पता है, अभी भी asm.js इस्तेमाल करने वाले बहुत लोग नहीं हैं
    लेकिन wasm, JavaScript से बहुत ज़्यादा अलग-थलग है। इसे सीमित तौर पर इस्तेमाल करने के बाद मेरे मन में आया कि क्यों न asm.js में compile करके देखूँ
    मुझे यह भी पक्का नहीं था कि Emscripten अभी इसे पूरी तरह support करता है या नहीं
    wasm में ज़्यादातर web APIs को call नहीं किया जा सकता
    और जिस काम के लिए मैं इसे देख रहा था, उसमें उससे भी अहम बात यह थी कि JS से wasm को zero-copy buffers पास नहीं किए जा सकते
    हर चीज़ एक trade-off है। isolation एक फ़ायदा है, लेकिन नुकसान भी

    • JavaScript के साथ interact करने के मामले में asm.js शायद wasm से भी ज़्यादा सीमित है। मूल रूप से यह simple numeric values और array buffers तक सीमित है
      जबकि आजकल wasm में GC types हैं और externref के ज़रिए JS values को पकड़े रखा जा सकता है
      asm.js में भी शायद zero-copy buffers नहीं हो पाएँगे। wasm के लिए zero-copy buffer proposal मौजूद है: https://github.com/WebAssembly/memory-control/blob/main/prop...
    • अगर मुझे सही याद है, तो Emscripten ने करीब 2020 में asm.js support हटा दिया था, और शायद वही asm.js को support करने वाली सबसे अहम toolchain थी। उसके बाद शायद Rust हो, लेकिन वह अब भी support करता है या नहीं, पता नहीं
      strict asm.js में भी ज़्यादातर web APIs को सीधे call नहीं किया जा सकता। यह सिर्फ numbers support करता है, JS strings या objects नहीं, और C heap को WASM की तरह ArrayBuffer object के अंदर मैनेज करता है
      zero-copy buffers में भी वही समस्या है। asm.js से “असली” JavaScript में निकलकर call करना पड़ता है, और किसी दूसरे ArrayBuffer को सीधे asm.js heap पर map भी नहीं किया जा सकता, इसलिए copy करनी पड़ती है। “JavaScript FFI” asm.js और WASM के बीच वास्तव में बहुत अलग नहीं है
    • अगर मैं गलत नहीं समझ रहा, तो asm.js में भी यही सीमाएँ नहीं हैं क्या? यानी asm.js code से web APIs सीधे call नहीं किए जा सकते, और “external” functions के लिए अलग handling अब भी चाहिए

  • मुझे याद है जब Mozilla ने asm.js code के लिए बहुत ही खास तौर पर tuned OdinMonkey पेश किया था। Chrome/V8 team ने इसके बजाय general-purpose JIT optimizations पर ध्यान दिया, जो सामान्य JavaScript को भी तेज़ चलाएँ और asm.js को भी फ़ायदा दें
    speed difference में Firefox को 2 से 4 गुना बढ़त थी, और उन्होंने इसका काफ़ी ज़ोर से प्रचार भी किया था :D
    आजकल ज़्यादातर browser JavaScript VMs बहुत मिलते-जुलते design और optimizations पर converge कर चुके हैं, इसलिए Odin के बिना भी asm.js code वैसे भी काफ़ी तेज़ चलेगा

  • runtime पर JS code generate करके algorithms को तेज़ करने की मेरी योजना अब खत्म हो गई। इसे wasm में करना शायद कहीं ज़्यादा मुश्किल होगा

    • runtime पर wasm code generate करना काफ़ी आसान है। संभव है कि valid asm.js code generate करने से भी आसान हो
      testing के लिए इस तरह का काफ़ी काम संभालने वाली एक छोटी library है: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
    • library इस्तेमाल करो तो यह मुश्किल नहीं है। Rust में इसके लिए यह इस्तेमाल कर सकते हैं: https://crates.io/crates/wasm-encoder
      JS में शायद https://www.npmjs.com/package/binaryen इस्तेमाल करोगे
    • अभी भी AssemblyScript मौजूद है। अगर मैं गलत नहीं समझ रहा या इसकी capability को गलत नहीं जानता, तो यह आपकी ज़रूरत के मुताबिक हो सकता है
      https://www.assemblyscript.org/
    • बस asm.js subset आज़मा कर performance देख लो। मुझे याद है कि browser के खास asm.js support के बिना भी Emscripten output की performance हैरान करने वाली अच्छी थी
    • यह अब भी काम करेगा। asm.js आखिर सामान्य JavaScript code ही है
      बस यह asm.js-विशेष pipeline जितनी तेज़ी से parse या execute नहीं होगा। बहुत बड़े applications न हों, तो मुझे नहीं लगता कि फ़र्क़ बहुत महसूस होगा