Dizendo adeus ao asm.js

• A partir do Firefox 148, a otimização de asm.js do SpiderMonkey foi desativada por padrão, e o código relacionado será removido em versões futuras
• Como asm.js é um subconjunto de JavaScript, os sites existentes continuarão funcionando, mas serão executados pelo caminho normal de JIT, perdendo os benefícios de otimização
• Recompilar conteúdo asm.js para WebAssembly pode trazer execução mais rápida e binários menores
• O asm.js permitiu execução próxima da nativa dentro de conteúdo web, sem sandbox separado nem APIs alternativas, em resposta a NaCl·PNaCl
• O OdinMonkey, incluído no Firefox 22 em 2013, viabilizou a distribuição na web de projetos C/C++ como Unity e Unreal e serviu de base para o WebAssembly

---

Desativação da otimização de asm.js

• A partir do Firefox 148, a otimização de asm.js do SpiderMonkey foi desativada por padrão, e todo o código relacionado deverá ser removido em versões futuras
• Os sites que usam asm.js continuarão funcionando
  • Como asm.js é um subconjunto do JavaScript comum, o código existente será executado pelo caminho normal de JIT, como qualquer outro script
  • No entanto, os benefícios das otimizações específicas de asm.js desaparecem
• Se você ainda distribui conteúdo em asm.js, a recomendação é recompilar para WebAssembly
  • Recompilar para WebAssembly pode trazer execução mais rápida e binários menores
  • O pipeline de WebAssembly do SpiderMonkey está muito mais avançado do que o pipeline de asm.js
• Com o sucesso do WebAssembly e a migração da maior parte do uso de asm.js, o custo de manter os dois caminhos aumentou
  • Continua exigindo tempo de manutenção
  • E mantém uma superfície de ataque adicional dentro da VM

O papel do asm.js e o fim do OdinMonkey

• O asm.js foi a resposta da Mozilla à pergunta levantada por NaCl e PNaCl: “é possível executar código em velocidade nativa na web?”
  • A ideia era escolher um subconjunto estrito e estaticamente tipado de JavaScript que o mecanismo pudesse reconhecer instantaneamente e compilar para código nativo
  • Isso permitia permanecer dentro do conteúdo web e usar as APIs web existentes, sem sandbox separado, IPC ou APIs alternativas
• O asm.js foi incluído no Firefox 22 em 2013 e permitiu que projetos como Unity e Unreal publicassem bases de código C/C++ na web usando apenas tecnologias web padrão
  • A demo Epic Citadel foi portada para a web em apenas 4 dias
  • O asm.js provou que era possível executar código com desempenho quase nativo usando apenas tecnologias web, abrindo depois o caminho para o WebAssembly
  • O WebAssembly foi incluído alguns anos depois no Firefox 52, e é bem possível que ele não existisse sem o asm.js
• O compilador de asm.js se chamava OdinMonkey, e o trabalho de remoção está sendo acompanhado no bug Ragnarök como “Twilight of OdinMonkey”
  • O BaldrMonkey, nascido do OdinMonkey, é o compilador otimizador de WebAssembly
  • O RabaldrMonkey é o compilador baseline de WebAssembly
  • O OdinMonkey entra em processo de aposentadoria após cumprir seu papel por 13 anos

[GN⁺]

Comentários do Hacker News

• asm.js foi a resposta da Mozilla à pergunta levantada por NaCl e PNaCl: “como executar código em velocidade nativa na web?”
  Se fosse hoje, o Chrome provavelmente teria simplesmente empurrado NaCl e PNaCl goela abaixo, e então todo mundo estaria reclamando de por que Safari e Firefox não conseguiam acompanhar o padrão da “web”

  • Ainda acho que estamos na linha do tempo errada. PNaCl morreu e, em vez de um sucessor digno aparecendo na hora certa, acabamos sendo cozidos vivos numa sopa de apps Electron
    Por um tempo, eu realmente achei que faríamos tudo no navegador. Em certo sentido, estamos indo cada vez mais nessa direção, mas a experiência geral parece pior do que nunca. Gosto de WASM e quero gostar mais ainda, mas o ritmo de maturação do ecossistema é inacreditavelmente ruim
    Pior ainda é que temos ferramentas de IA não confiáveis, e a saída delas precisa ser executada justamente nesse tipo de sandbox, enquanto as empresas estão vendendo exatamente o oposto: sandbox hospedado e VM hospedada baseada em JS
    No fim das contas, parece que o problema sempre foi o mesmo. Nunca houve dinheiro em sandbox do lado do cliente
  • Pelo que eu me lembro, não foi bem assim. Na época foi um experimento útil, mas no fim não deu muito certo
    Internamente, foi útil para colocar o Flash player em sandbox, mas as limitações da abordagem baseada em LLVM logo ficaram claras para todos os envolvidos
  • Na verdade, foi basicamente isso que tentaram fazer na época. Tentaram fazer passar pelos comitês de padrões da web e seguiram o processo
    Se bem me lembro, um grande motivo do fracasso foi que NaCl era uma tecnologia “grande” demais e asm.js uma tecnologia “pequena” demais, então asm.js chegou ao estado pronto para produção antes, apesar de ter começado alguns anos depois
  • Acho que a ideia é que o Chrome teria forçado a barra, a Apple teria ganhado tempo sem dizer nada enquanto continuava sem investir na equipe do WebKit, e as pessoas ingênuas da internet teriam se alinhado ao lado da Apple
    Dito isso, a Apple parece ter aumentado o investimento no WebKit nesta década, depois que as questões regulatórias ficaram sérias, então talvez hoje o resultado fosse diferente
  • As reclamações surgem quando há algum recurso que seria útil na plataforma web e não existe uma alternativa altamente compatível. asm.js e depois Wasm eram exatamente essa alternativa
    Por isso havia menos reclamações na época, e hoje há reclamações sobre coisas que o Safari não faz porque seriam ruins para a App Store. Felizmente, a UE agora está tentando colocar a Apple um pouco nos trilhos

• É triste, mas faz sentido. Um fato interessante é que o Figma começou originalmente com uma base de código totalmente em C++, e asm.js foi essencial para provar que uma ferramenta de design podia rodar no navegador
  A migração para WebAssembly só veio depois que eles já tinham clientes pagantes, e a melhora no tempo de carregamento também foi bem grande. asm.js ainda é JS, então o bundle fica maior e o código precisa ser analisado como AST, enquanto no WASM isso não acontece

  • Não sei o que há de tão triste nisso. É só um alvo de compilação que já teve sua importância
    É parecido com ficar triste porque removeram suporte a i386-unknown-freebsd1
  • O triste é que poderíamos ter tido um app nativo de desktop do Figma bem limpo

• Então agora chegou a morte do asm.js? Estamos nos afastando da linha do tempo da profecia
  https://www.destroyallsoftware.com/talks/the-birth-and-death...
  Recomendo fortemente se você ainda não viu. Dependendo de como se define “melhor”, pode ser a melhor apresentação técnica de todos os tempos

  • Com a morte dessa tecnologia, o fio da profecia foi rompido. Você pode carregar um save e restaurar a trama do destino, ou continuar resistindo no mundo arruinado que você mesmo criou
  • Eu reassisto essa palestra duas ou três vezes por ano. É um excelente exemplo de como fazer uma apresentação, de como alinhar um deck de slides com a fala, e ainda faz uma passada surpreendentemente didática pela estrutura de anéis de privilégios dos sistemas operacionais
    Um dia, depois de atravessarmos o tempo de guerra e perdermos esse apego psicológico a paradigmas antigos de programação, talvez possamos migrar para algo mais avançado. Claro que isso não significa que o seu banco vai deixar de rodar YavaScript pelos próximos 85 anos, no mínimo
  • Se você trocar asm.js por WASM, ainda estamos no caminho certo
  • Não se preocupe. YavaScript vai sobreviver para sempre
  • Se trocar guerra por COVID, como ambos aconteceram em 2020, ainda não foge tanto assim. Para saber se é real mesmo, ainda precisamos esperar até 2035

• Nunca vou esquecer o momento em que vi a palestra do Gary Bernhardt sobre JavaScript.[0] Foi ali que conheci asm.js pela primeira vez e entrei na toca do coelho de compilar código para rodar no navegador
  Agora, 12 anos depois, impressiona quanto da ficção dele virou realidade
  [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

  • A parte dos “thick apps” sempre ficou na minha cabeça. O nome era engraçado e também era bem próximo da minha realidade
    Quando vi aquela palestra pela primeira vez, eu era estagiário, e a empresa fazia internamente o compilador, a IDE e o depurador para umas caixinhas industriais de IO. O compilador era escrito em C, convertido para JS com Emscripten e depois “compilado” junto com a IDE e o depurador em um arquivo HTML gigante, na prática só concatenando tudo. Upload de código e depuração eram feitos por Ethernet, e tudo era empurrado via Ajax
    Parece uma arquitetura amaldiçoada, mas os clientes adoravam. Como não era um EXE, não era barrado pelos filtros corporativos exagerados da TI das empresas deles. Por isso nunca migramos para Electron. Em certo sentido, já tinha elementos primitivos de um thick app
  • Se a ascensão da IA não tivesse acontecido, talvez o WASM tivesse se tornado o alvo de compilação em nível de máquina para todas as linguagens. Gary previu muita coisa, mas não viu a IA chegando

• Há muito tempo eu escrevi um pequeno capítulo sobre asm.js em um livro de WebGL
  https://webglinsights.github.io/
  Foi divertido ver a ascensão do asm.js, que era o precursor do WebAssembly. Havia demos iniciais realmente incríveis, como Unreal Engine rodando no navegador. É agridoce vê-lo se pôr aqui, mas ele levou a coisas muito melhores

• Talvez precisemos de um transpilador de asm.js para WASM
  Compilar código legado com versões legadas do Emscripten é bastante frustrante. Às vezes é quase tão doloroso quanto atualizar o código JS para acompanhar as mudanças acumuladas de ABI do Emscripten

  • O Binaryen costumava ter a ferramenta asm2wasm, mas pelo que sei ela foi descontinuada. Não consegui encontrar outra equivalente
    Pelo menos o código asm.js vai continuar funcionando mesmo que a otimização de asm.js seja desligada, mas seria bom ter um conversor
  • https://porffor.dev/

• asm.js morreu! Vida longa ao WebAssembly!

  • Sendo justo, achei que asm.js já tinha entrado em descontinuação há alguns anos, quando o wasm apareceu

• Pessoalmente, acho que essa decisão é um erro. Só não sei qual será o impacto real. Pelo que sei, ainda não há tanta gente usando asm.js
  Mas o wasm é isolado demais do JavaScript. Depois de usar um pouco de forma limitada, cheguei a pensar em talvez compilar para asm.js em vez disso
  Nem tinha certeza se o Emscripten ainda dava suporte completo
  No wasm, você não consegue chamar a maioria das APIs web
  E, no que eu queria fazer, mais importante ainda, não dá para passar buffers zero-copy do JS para o wasm
  Tudo é compromisso. O isolamento é uma vantagem, mas também é uma desvantagem

  • O asm.js provavelmente seria ainda mais limitado do que wasm na forma de interagir com JS. Basicamente fica restrito a valores numéricos simples e array buffers
    Já no wasm atual existem tipos GC, e dá até para manter valores JS com externref
    Provavelmente também não dá para fazer buffer zero-copy em asm.js. Há uma proposta para buffer zero-copy do lado do wasm: https://github.com/WebAssembly/memory-control/blob/main/prop...
  • Se me lembro direito, o Emscripten removeu o suporte a asm.js por volta de 2020, e provavelmente era a toolchain mais importante que suportava asm.js. Talvez a próxima fosse Rust, mas não sei se ainda suporta
    Mesmo no asm.js estrito, você não consegue chamar a maioria das APIs web diretamente. Só há suporte a números; não a strings ou objetos JS, e o heap em C é gerenciado dentro de um objeto ArrayBuffer, como no WASM
    O problema do buffer zero-copy é o mesmo. Você precisa sair do asm.js para chamar JavaScript “de verdade”, e também não dá para mapear outro ArrayBuffer diretamente no heap do asm.js, então é preciso copiar. A “FFI de JavaScript” não é tão diferente assim entre asm.js e WASM
  • Se eu não estiver entendendo errado, asm.js também não tem a mesma limitação? Ou seja, o código asm.js não consegue chamar APIs web diretamente, e ainda precisa de tratamento separado para funções “externas”?

• Lembro de quando a Mozilla lançou o OdinMonkey, extremamente especializado em código asm.js. Já a equipe do Chrome/V8 preferiu focar em otimizações JIT genéricas que aceleravam JavaScript em geral e também ajudavam asm.js
  A diferença de desempenho deixava o Firefox de 2 a 4 vezes na frente, e eles divulgaram isso com bastante força :D
  Hoje em dia, a maioria das VMs de JavaScript dos navegadores convergiu para projetos e otimizações muito parecidos, então mesmo sem Odin o código asm.js provavelmente ainda rodaria bem rápido

• Meu plano de gerar código JS em tempo de execução para acelerar algoritmos foi por água abaixo. Parece bem mais difícil fazer isso com wasm

  • Gerar código wasm em tempo de execução é bem fácil. Pode até ser mais fácil do que gerar código asm.js válido
    Há uma pequena biblioteca que lida com boa parte disso para testes: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
  • Com uma biblioteca não fica mais difícil. Em Rust, você pode usar isto: https://crates.io/crates/wasm-encoder
    Em JS, provavelmente usaria https://www.npmjs.com/package/binaryen
  • Ainda existe o AssemblyScript. Se eu não entendi errado ou não conheço mal a ferramenta, talvez sirva para o que você precisa
    https://www.assemblyscript.org/
  • Você pode simplesmente tentar usar o subconjunto asm.js e ver como fica o desempenho. Pelo que lembro, mesmo sem o suporte especial a asm.js do navegador, o desempenho da saída do Emscripten era surpreendentemente bom
  • Vai continuar funcionando. Afinal, asm.js ainda é só código JavaScript comum
    Só não vai ser analisado nem executado tão rápido quanto com um pipeline dedicado a asm.js. A menos que seja um aplicativo enorme, acho que você dificilmente notará tanta diferença