¿Cuál es la diferencia entre asm.js y WebAssembly?


101

Recientemente he estado leyendo sobre asm.js y WebAssembly:

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

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

Todavía estoy confundido por algunas cosas:

  1. ¿El código asm.js se compila a tiempo y se ejecuta? ¿Compilado en qué?
  2. Aparte de que asm.js es texto y wasm (ensamblaje web) es binario, ¿cuáles son las diferencias entre los 2?
  3. ¿Qué significa esto para otros lenguajes de secuencias de comandos que se ejecutan en el navegador? Tome Python, por ejemplo, ¿será
    • código python compilado en wasm? o
    • intérprete de Python (Cpython) compilado en wasm e interpretar Python?

Respuestas:


47

¿El código asm.js se compila a tiempo y se ejecuta? ¿Compilado en qué?

asm.js es un código javascript normal y, como siempre, el intérprete JS lo compila en código de bytes. Sin embargo, se supone que un intérprete con soporte asm debe realizar una compilación anticipada y posiblemente generar una representación de código más eficiente debido a la escritura estática. Consulte http://asmjs.org/ para obtener más detalles.

¿Cuáles son las diferencias entre asm y wasm (que no sean texto vs binario)?

Ninguno, por ahora. Se supone que wasm es compatible con versiones anteriores, compilable en asm (que de nuevo es ejecutable como JS normal). Sin embargo, podría ampliarse con más funciones en el futuro a medida que aumente el soporte.

¿Qué significa esto para otros lenguajes de secuencias de comandos que se ejecutan en el navegador?

Este último, más bien, como Python, aún necesita ser interpretado. Los lenguajes de script que no necesitan un intérprete pueden, por supuesto, compilarse directamente en (w) asm, dado que hay un compilador (cadena) que lo admite como destino.


Notas de pareja. La primera parte de su respuesta parece un poco ambigua; parece que estás diciendo que asm.js compilaría AOT en un "bytecode más eficiente". En realidad, las implementaciones no tienen que apuntar a un código de bytes y, de hecho, muchas apuntan a la ISA nativa directamente y a AOT (que es el punto, en realidad). También dice "compilable en asm y js". Es posible que desee aclarar que quería decir "ensamblado nativo" o algo así. O quizás quisiste decir "asm.js y js", pero eso no es muy útil ya que uno es un subconjunto del otro.
TNE

1
@tne: Gracias por los comentarios, espero poder resolver los problemas. Siéntase libre de (sugerir) editar usted mismo, se lo agradecería. Bien, fui un poco relajado con el "código de bytes más eficiente" ya que no estaba familiarizado con la arquitectura de compilación exacta, después de todo, ISA es simplemente otro "código de bytes" que es interpretado por el procesador. Perdone la terminología inexacta :-)
Bergi

53

asm.js es un subconjunto de JS con instrucciones "altamente optimizables". Básicamente, puede declarar el tipo (int, float) y el motor js (en los navegadores pero también en el de node.js) ejecutará las instrucciones más rápido. Tiene beneficios si su aplicación hace muchos cálculos o gráficos si se usa junto con WebGL.

El ensamblaje web es un formato binario para JS, todo JS, no solo asm.js. No es un código de bytes, es una codificación binaria del AST que calcula el analizador. Tiene 2 grandes beneficios:

  • el motor JS puede omitir el paso de análisis
  • es mucho más compacto que la fuente original de JS

Ya podemos escribir código para navegadores que no sea JS: EMSCripten puede compilar código C ++ en código JS. Ya hay otros transcompiladores disponibles para compilar su código en JS. Usando asm.js ese código puede ejecutarse más rápido cuando hace matemáticas. Al usar el ensamblaje web, ese código será más compacto y el navegador podrá procesarlo más rápido (porque podrá omitir el análisis). No tendrá un nuevo complemento para cargar como DirectX, JavaApplets, Flash o Silverlight porque todo se ejecutará en el sandbox de JS.


5
¿Saltar el análisis? Más despacio, ahí. El soporte de hardware está fuera del mapa en el futuro previsible. Lo que quiere decir es que el análisis se convirtió en el cuello de botella con asm.js, y wasm lo corrige con un formato binario eficiente. Su fundamento para asm.js / wasm parece un poco minimalista, pero está bien. Apoyos para señalar bytecode! = AST.
TNE

4
@Cristian, WASM no es un formato binario para JS. Utilizará las mismas API web que JS, pero es mucho más portátil y generalizado que JS. Los únicos formatos binarios para JS, o códigos de bytes, son los implementados en navegadores, como el de Firefox aquí: developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/…
LearningFast

20

¿El código asm.js se compila a tiempo y se ejecuta? ¿Compilado en qué?

Los diferentes navegadores compilan el código asm.js de diferentes maneras. A agosto de 2015:

  • Firefox compila asm.js en código de máquina (y almacena en caché el código de máquina para cargas futuras del mismo asm.js) [ 1 ].
  • En Windows 10 como una bandera experimental, Edge también realizará una validación y compilación anticipada de asm.js [ 2 ].
  • Chrome reconoce especialmente la directiva "use asm" al principio de asm.js para analizarlo y analizar el código con más entusiasmo y ajustar la heurística de compilación.
  • Safari no realiza ningún procesamiento especial de asm.js.

Aparte de que asm.js es texto y wasm (ensamblaje web) es binario, ¿cuáles son las diferencias entre los 2?

asm.js es solo JavaScript y, por lo tanto, debe comportarse exactamente de acuerdo con la especificación de JavaScript. Como nuevo estándar, WebAssembly puede solucionar algunos casos extremos en los que el comportamiento de JavaScript no es el ideal (desde una perspectiva de rendimiento o compilación) [ 3 ]. En el futuro [ 4 ], WebAssembly podrá agregar características que de otro modo serían difíciles de expresar en JavaScript.

¿Qué significa esto para otros lenguajes de secuencias de comandos que se ejecutan en el navegador? Tome Python, por ejemplo, ¿será

  • código python compilado en wasm? o
  • intérprete de Python (Cpython) compilado en wasm e interpretar Python?

En la v.1, la forma más sencilla de ejecutar Python en un navegador será compilar un intérprete de Python en wasm, como dijiste. Esto significa, por ejemplo, que Python GC se está ejecutando en código wasm y administra manualmente la memoria lineal de wasm. Ya ha habido proyectos experimentales para agregar un backend asm.js a PyPy [ 5 ] (que podría funcionar igual de bien para wasm). Actualmente se encuentra con limitaciones de asm.js que podrían resolverse mediante la función futura de vinculación dinámica de wasm. Yendo más allá, wasm busca proporcionar integración de GC y soporte de compilación JIT, lo que permitiría una integración más eficiente y natural con la plataforma web.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.