Qual é a diferença entre asm.js e WebAssembly?

101

Tenho lido recentemente sobre asm.js e WebAssembly:

http://ejohn.org/blog/asmjs-javascript-compile-target/

https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

Ainda estou confuso sobre algumas coisas:

  1. O código asm.js é compilado a tempo e executado? Compilado em quê?
  2. Além de asm.js ser texto e wasm (web assembly) binário, quais são as diferenças entre os 2?
  3. O que isso significa para outras linguagens de script em execução no navegador? Pegue o python, por exemplo, vai ser
    • código python compilado para wasm? ou
    • interpretador python (Cpython) compilado em wasm e interpretar python?
javascript asm.js webassembly NeoWang
fonte

Respostas:

47

O código asm.js é compilado a tempo e executado? Compilado em quê?

asm.js é um código javascript regular e é compilado em bytecode pelo interpretador JS como sempre. No entanto, um intérprete com suporte asm deve fazer uma compilação antecipada e, possivelmente, gerar uma representação de código mais eficiente devido à tipagem estática. Consulte http://asmjs.org/ para obter detalhes.

quais são as diferenças entre asm e wasm (diferente de texto vs binário)?

Nenhum, por enquanto. wasm deve ser compatível com versões anteriores, compilável para asm (que novamente é executável como JS normal). No entanto, pode ser estendido com mais recursos no futuro, à medida que o suporte para ele aumenta.

O que isso significa para outras linguagens de script em execução no navegador?

Este último, em vez disso, como Python ainda precisa ser interpretado. Linguagens de script que não precisam de um intérprete podem, é claro, ser compiladas diretamente para (w) asm, visto que há um compilador (cadeia) que o suporta como destino.

Bergi
fonte
Algumas notas. A primeira parte de sua resposta parece um pouco ambígua; parece que você está dizendo que asm.js compilaria AOT em um "bytecode mais eficiente". Na verdade, as implementações não precisam ter como alvo um bytecode e, na verdade, muitas têm como alvo o ISA nativo diretamente e AOT (que é o ponto, na verdade). Você também diz "compilável para asm e js". Você pode querer esclarecer que quis dizer "montagem nativa" ou algo assim. Ou talvez você quisesse dizer "asm.js e js", mas isso não é muito útil, pois um é um subconjunto do outro.
tne
1
@tne: Obrigado pelo feedback, espero ter conseguido resolver os problemas - sinta-se à vontade para (sugerir) editar você mesmo, agradeço. Certo, fui um pouco negligente no "bytecode mais eficiente", pois não estava familiarizado com a arquitetura de compilação exata, afinal ISA é apenas mais um "código de byte" que é interpretado pelo processador. Por favor, perdoe a terminologia imprecisa :-)
Bergi
53

asm.js é um subconjunto de JS com instruções "altamente otimizáveis". Basicamente, você pode declarar o tipo (int, float) e o mecanismo js (nos navegadores, mas também no node.js) executará as instruções mais rapidamente. Ele tem benefícios se seu aplicativo faz muitos cálculos ou gráficos se usado junto com WebGL.

web assembly é um formato binário para JS, todo JS, não apenas asm.js. Não é um bytecode, é uma codificação binária do AST que o analisador calcula. Tem 2 grandes benefícios:

  • o mecanismo JS pode pular a etapa de análise
  • é muito mais compacto do que a fonte original JS

Já podemos escrever código para navegadores que não sejam JS: EMSCripten pode compilar código c ++ em código JS. Outros transcompiladores já estão disponíveis para compilar seu código em JS. Usando asm.js, esse código pode ser executado mais rapidamente quando faz matemática. Usando o Web assembly esse código será mais compacto e o navegador será capaz de processá-lo mais rápido (porque ele será capaz de pular a análise). Você não terá um novo plugin para carregar como DirectX, JavaApplets, Flash ou Silverlight porque tudo será executado no sandbox JS.

cristian v
fonte
5
Pular análise? Calma aí. O suporte de hardware está fora do mapa em um futuro próximo. O que você quer dizer é que a análise se tornou o gargalo com asm.js e o wasm corrige isso com um formato binário eficiente. Sua justificativa para asm.js / wasm parece um pouco minimalista, mas tudo bem. Suportes para apontar o bytecode! = AST.
tne
4
@Cristian, WASM não é um formato binário para JS. Ele usará as mesmas APIs da Web do JS, mas é muito mais portátil e generalizado do que o JS. Os únicos formatos binários para JS, ou bytecodes, são aqueles implementados em navegadores, como o do Firefox aqui: developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/…
LearningFast
20

O código asm.js é compilado a tempo e executado? Compilado em quê?

Navegadores diferentes compilam o código asm.js de maneiras diferentes. Em agosto de 2015:

  • O Firefox compila asm.js em código de máquina (e armazena em cache o código de máquina para carregamentos futuros do mesmo asm.js) [ 1 ].
  • No Windows 10 como um sinalizador experimental, o Edge também fará alguma validação Ahead-of-Time e compilação de asm.js [ 2 ].
  • O Chrome reconhece especialmente a diretiva "use asm" no início do asm.js para analisar e analisar o código com mais atenção e ajustar as heurísticas de compilação.
  • O Safari não faz nenhum processamento especial de asm.js.

Além de asm.js ser texto e wasm (web assembly) binário, quais são as diferenças entre os 2?

asm.js é apenas JavaScript e, portanto, deve se comportar exatamente de acordo com as especificações do JavaScript. Como um novo padrão, o WebAssembly é capaz de corrigir alguns casos em que o comportamento do JavaScript não é o ideal (de uma perspectiva de desempenho ou compilação) [ 3 ]. No futuro [ 4 ], WebAssembly será capaz de adicionar recursos que de outra forma seriam difíceis de expressar em JavaScript.

O que isso significa para outras linguagens de script em execução no navegador? Pegue o python, por exemplo, vai ser

  • código python compilado para wasm? ou
  • interpretador python (Cpython) compilado em wasm e interpretar python?

No v.1, a maneira mais simples de executar Python em um navegador será compilar um interpretador Python para o wasm, como você disse. Isso significa, por exemplo, que o Python GC está sendo executado no código wasm e gerenciando manualmente a memória linear do wasm. Já houve um projeto experimental para adicionar um backend asm.js ao PyPy [ 5 ] (que poderia funcionar tão bem para o wasm). Atualmente, ele apresenta limitações do asm.js que poderiam ser resolvidas pelo futuro recurso de vinculação dinâmica do wasm. Indo mais longe, o wasm busca fornecer integração GC e suporte de compilação JIT, ambos permitindo uma integração mais eficiente e natural com a plataforma da web.

Lucas
fonte