Design: ¿Habrá un compilador JS -> WASM?

Los navegadores seguirán teniendo una máquina virtual JavaScript nativa junto con wasm. No hay ninguna razón para compilar JS en wasm porque también tendría que incluir una máquina virtual javascript completa. El código resultante sería enorme y más lento que el JS VM proporcionado de forma nativa.

Hay un MVP de publicación de tareas para agregar cosas como agregar acceso al GC desde el código wasm para que los lenguajes de scripting se puedan implementar para wasm.

JS → wasm solo tendrá sentido una vez que wasm admita GC, y muy probablemente también la compilación JIT, que todavía falta bastante. ¡Esto sería básicamente equivalente a implementar el motor JS en wasm! Mencioné esto recientemente y @BrendanEich me acusó de haber sido tomado por horse_js.

Para ser claros, el objetivo de wasm no es _sustituir_ JavaScript, es complementarlo. Por lo tanto, no es realmente un objetivo en este momento admitir JS → wasm, pero las características que queremos implementar lo harán posible. Sin embargo, no estoy seguro de que sea tan útil desde la perspectiva de un desarrollador. Puede obtener una reducción de tamaño, pero eso es todo. Desde la perspectiva de un navegador, puede ser interesante tener el motor JS implementado en wasm desde una perspectiva de seguridad pura.

@jfbastien te

Pero tu respuesta es mejor. Estoy emocionado por GC y JIT en wasm. Me encanta crear mis propios lenguajes y ejecutarlos en la web.

¿Y qué hay de admitir variantes como asm.js o TypeScript / ES7? Estas
Los sabores de Javascript prometen cierto nivel de garantías de tipo.

Me imagino que la necesidad de JIT sería menor, pero GC todavía mucho
necesario para estos idiomas. Tendría un {tipo de sabor JS} -> WASM hacer
esto es más factible?

W: http://bguiz.com

El 24 de junio de 2015 a las 09:44, Tim Caswell [email protected] escribió:

@jfbastien https://github.com/jfbastien me ganaste por 2 segundos: P

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

Sí, un traductor asm.js -> wasm es de alta prioridad, y Luke ya lo hizo
trabajar en un compresor que pueda servir como un buen punto de partida.

El miércoles 24 de junio de 2015 a las 1:59 a. M., Brendan Graetz [email protected]
escribió:

¿Y qué hay de admitir variantes como asm.js o TypeScript / ES7? Estas
Los sabores de Javascript prometen cierto nivel de garantías de tipo.

Me imagino que la necesidad de JIT sería menor, pero GC todavía mucho
necesario para estos idiomas. Tendría un {tipo de sabor JS} -> WASM hacer
esto es más factible?

W: http://bguiz.com

El 24 de junio de 2015 a las 09:44, Tim Caswell [email protected] escribió:

@jfbastien https://github.com/jfbastien me ganaste por 2 segundos: P

-
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

Hemos hablado con el equipo de TypeScript sobre esta posibilidad y han mostrado interés, pero parece que actualmente se ha avanzado en la adición de objetos escritos en JS.

@bguiz : El motor JS es el motor wasm y seguirá siendo compatible con el lenguaje estándar JS en evolución. No se preocupe (no estaba seguro de si pensaba que eso podría desaparecer. No en ningún futuro que pueda prever). OTOH como otros señalan, wasm necesita tiempo para evolucionar GC, soporte JIT y otras características de lenguaje dinámico, para ser un objetivo de primera clase para JS. Incluso cuando evolucionan estas cosas, tengo dudas de que los motores JS / wasm abandonen su sintaxis JS y sus componentes integrados en favor de las VM JS-in-wasm descargadas. ¡Veremos!

/ser

Un traductor asm.js-to-WebAssembly también será algo que planeamos agregar

En cuanto a JS normal, creo que otros han respondido la pregunta anterior.

El objetivo de JS es fácil de codificar y puede hacer cosas increíbles: dhteumeuleu o codepen.io/ge1doot, pero puedes ver la fuente y es fácil de piratear.

"wasm" es solo una forma de vender más juegos y otras aplicaciones para google, apple an co. La única "evolución" es que podrá controlarte mejor sin "instalar", directamente desde el servidor del hermano mayor ... Me sorprende que todavía no tengan miedo de comerse unos a otros ...

Es posible con análisis de código o anotaciones de código compilar ECMAScript en WebAssembly. Esto no parece una prioridad para el equipo de WebAssembly, pero parece una gran idea para un esfuerzo independiente.

Acabo de comenzar a experimentar con un lenguaje de programación de juguetes que podría ser relevante: https://github.com/evanw/thinscript. Utiliza una sintaxis de estilo TypeScript y se compila en WebAssembly. Pensé que debería mencionarlo porque podría ser un caso de estudio interesante. También me sorprendió gratamente lo fácil que fue generar WebAssembly. ¡Buen trabajo a todos!

Sin embargo, advertiría a la gente sobre el uso de envoltorios muy finos sobre el wasm, en general. Como ejemplo, hojeando el código thinscript, veo que hay una instrucción while que se reduce a loop { if (!condition) break; } , que será menos eficiente que if (condition) loop { ...; br_if condition } en varios motores de wasm.

Para mí, lo que hace que wasm sea más que un JS recalentado es la posibilidad de una filosofía diferente: debido a que wasm es un objetivo del compilador, los compiladores pueden realizar optimizaciones antes de enviar el código a los clientes, por lo que podemos mantener las VM del lado del cliente más simples y más rápido. Sin embargo, si los envoltorios delgados alrededor de wasm se vuelven populares, existe el riesgo de que las implementaciones del lado del cliente eventualmente tengan que volverse más voluminosas y complejas para hacer las optimizaciones que no se están haciendo.

Sí estoy de acuerdo. Una de las cosas que más me gustan de WebAssembly es su simplicidad. Estoy planeando agregar optimizaciones del compilador y hacer evaluaciones comparativas una vez que el lenguaje esté más completo. Espero que inlining sea una de las mayores ganancias, por ejemplo, y no esperaría que WebAssembly hiciera eso por mí. También planeo experimentar con un objetivo de código de máquina y usaré las mismas optimizaciones para ambos objetivos.

¡Suena muy bien! Me interesará ver a dónde conduce.

Me imagino que JS-> WASM es más atractivo para los servidores que para los clientes. Como una descripción general de muy alto nivel de la arquitectura que tengo en mente ...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

En esta concepción, sería muy deseable un mapeo claro de WASM a LLVM IR para la recolección de basura . La promoción de dobles IEEE a números enteros podría realizarse como un pase LLVM. La noción de JIT separados para códigos calientes y calientes podría implementarse en términos de administradores de pases LLVM.

Solo algunas ideas, siéntase libre de eliminar esto si es falso.

La compatibilidad entre entornos es un problema grave en el ecosistema JS. Babel intenta resolver este problema trasladando a alguna versión más adoptada de ES y supongo que todos podemos decir que tiene bastante éxito.

Sin embargo, todavía hay un problema aquí. Por ejemplo, si está transfiriendo su código ES 2016 a ES5 para compatibilidad y su código se ejecuta en un entorno con soporte ES 2016 (parcial o completo), se perderá los beneficios de tener soporte ES 2016 en su entorno. .

Si todos están transfiriendo su código a ES5, entonces, ¿cuál es el beneficio de tener soporte ES 2016 en un entorno en primer lugar?

Un nuevo proyecto llamado "babel-preset-env" intenta combatir este problema dirigiéndose a los entornos por sus versiones. La idea detrás de esto es que (1) le pide que apunte a versiones específicas o "últimas versiones X" de los navegadores, (2) determina el mínimo común denominador de características y (3) habilita solo las transpilaciones necesarias. Esto ayuda, pero lamentablemente no puede resolver el problema.

Todavía corremos el riesgo de que un proveedor importante no se comporte y cause los mismos problemas que Microsoft estuvo causando con Internet Explorer durante años. Todo el ecosistema está en manos de unos pocos proveedores, quienes deciden qué implementar y cuándo implementar. Esto no es gratis ni abierto.

La única solución es un nuevo objetivo de compilación para JavaScript que es eficiente y necesita mucho menos mantenimiento (con suerte ninguno) que un motor JS. Cuando los entornos (navegadores, Node.js, etc.) comienzan a admitir dicho objetivo, la implementación de nuevas funciones de ES debería ser responsabilidad de los compiladores y no de los proveedores de motores.

JS -> WASM sería interesante para proteger la propiedad intelectual mediante la ofuscación del código cuando se trata de instalaciones locales de, digamos, aplicaciones Electron en los servidores de los clientes. Es difícil de creer, pero es cierto, hay muchas instituciones pequeñas en Alemania con muy poca o ninguna conexión a Internet, lo que requiere instalaciones en las instalaciones, pero darles todo su código en texto plano puede ser aterrador para las empresas de software.

@ Simran-B Wasm tiene como principio de diseño admitir un formato de texto familiar. En particular, tiene un diseño de flujo de control estructurado para un análisis rápido y está optimizado para definiciones de un solo uso utilizadas en orden de pila, por lo que está optimizado para expresiones legibles. Por lo tanto, no es un objetivo de 'ofuscación de código', pero los desarrolladores pueden emitir su propia 'ofuscación de código' además de esto, pero deben comprender que se espera que esto tenga un costo en términos de menor eficiencia de codificación y menor rendimiento.

Hola a todos, acabo de descubrir WebAssembly con resentimiento, pero pensando en el compilador JS -> wasm, imaginé algo como la compilación Ahead-of-Time de Angular2, pero mucho más optimizada (estoy pensando en código de máquina en lugar de javascript) ... alguna vez será posible? ¿Vale la pena?

EDITAR
También estoy pensando, ¿habrá alguna vez la posibilidad de que el navegador envíe una bandera al cliente que admita wasm, y luego podamos ofrecer una aplicación precompilada en lugar de un archivo javascript?

Ricardo

@ Richard87 podría pensar en webassembly como un conjunto de instrucciones independiente de la plataforma con sus propias convenciones especializadas de codificación y llamada. No hay nada que diga que no se puede describir un subconjunto de javascript que sería muy fácil de transpilar para trabajar en el mundo de webassembly de esas cosas, pero hacer cumplir eso probablemente sería difícil. El conjunto de características y el área de la superficie de implementación están creciendo constantemente en javascript, y adaptar las bibliotecas y marcos existentes para que funcionen en ese subconjunto probablemente sería difícil, especialmente dada la falta actual de recolección de basura en el ensamblaje web, y esencialmente perdería los beneficios del javascript existente. código.

Con la adición de primitivas de recolección de basura en el ensamblaje web, el subconjunto de javascript que sería factible de transpilar sin escribir una gran máquina virtual se ensancharía, pero aún en mi opinión no sería óptimo en comparación con simplemente transpilar de una máquina virtual más adecuada. lenguaje, dado que sus gastos generales en javascript serían solo un poco más pequeños, los gastos generales importantes en las aplicaciones web (¡la red!) Se ampliarían y los beneficios que le gustaría obtener al usar javascript en primer lugar aún estarían fuera de su alcance, además de llegar a decir que usa algo que se parece a "javascript" (este es en realidad un barco similar en el que se encuentra Unity con UnityScript, excepto que lo adaptaron un poco para integrarse mejor con sus subsistemas y convenciones de llamadas en general, además de otros caprichos).

Creo que es extremadamente importante para algunos de nosotros que buscamos en el navegador y Webgl ser más rápidos para los juegos. Intento traer un juego de calidad comercial en webgl, pero la tecnología actual produce tanta basura que los marcos se saltan.
Los juegos de navegador que utilizan motores de juegos JS casi han fallado y Unity despegó. Creo que C ++ => Wasm es una ventaja indebida para estos grandes creadores de frameworks similares a Unity que podrían compilar su código en WASM.
Pero ¿qué pasa con las personas que escriben JS a mano usando Three JS o Babylon? No tener una cadena de herramientas JS / Asm.js => Wasm significaría que una gran aplicación en Js estaría muerta y la gente usaría C ++ y backends de generación de código para producir Wasm. Más específicamente en juegos y tal.
No tener un backend JS => Wasm es injusto para los desarrolladores de JS. Además, EMCC asigna un montón grande cuando se ejecuta y las velocidades son evidentes debido a eso, pero los desarrolladores de Js que escriben un buen código js aún no pudieron lograr tanto rendimiento debido a la complejidad de escribir dicho código. Debería haber algún mecanismo para reutilizar la mayoría de las cosas y la capacidad de llamar a gc antes o a voluntad. La omisión de fotogramas cuando se ejecuta el GC hace que Webgl omita fotogramas es un gran problema y debe resolverse. Debería haber algún mecanismo para ajustar manualmente el código JS mejor que los generadores de código. como Assembly escrito a mano, todavía produce un código mucho más pequeño y altamente alineado. Eso debería ser posible en el montaje web.

@metacritical C ++ puede compilarse en WASM porque muchas personas ponen mucho trabajo en el proceso. Lo mismo podría suceder con JavaScript, pero hasta donde yo sé, nadie está intentando esto actualmente. Hay pocas razones para hacerlo: el rendimiento no cambiará.

El problema de su motor es la recolección de basura. Este problema no desaparece si crea un algoritmo de recolección de basura que usa memoria lineal y código WASM ... eventualmente tendrá que detener el programa para ver qué objetos aún están vivos y eliminar los que no lo están. La solución es no crear objetos basura, evitando la necesidad de que el GC se ejecute. No necesita WASM para lograr esto, necesita reelaborar su motor.

Javascript ultra prístino que reutiliza matrices y produce poca basura es extremadamente difícil de escribir. También creo que Plain Js no se puede compilar en WASM. Asm.js o Typescript serían más fáciles de compilar en WASM debido a la disponibilidad de anotaciones de tipo o tipos en ellos, respectivamente.

@metacritical Difícil, pero no imposible. Incluso en los motores C ++, gran parte del código gira en torno a la gestión de la vida útil de los objetos. Aunque no es convencional, no hay razón para que no pueda hacer lo mismo en JavaScript.

El JS simple _podría_ compilarse en WASM, pero el compilador tendría que agregar una gran cantidad de código auxiliar para habilitar las características de alto nivel de JavaScript, como la recolección de basura, la reflexión, las propiedades, etc. Básicamente, todo lo que obtienes de forma gratuita con el motor JS incorporado en el navegador. TypeScript no ayuda mucho.

En comparación, ASM.JS sería fácil de convertir a WASM. El subconjunto estricto de características JS permitidas por ASM.JS también está cubierto al 100% por WASM. Si hubiera un gran volumen de código escrito en ASM.JS, este sería un esfuerzo valioso, pero hasta donde yo sé, todos los archivos principales de ASM.JS se producen a partir del código fuente C ++, que ya puede apuntar directamente a WASM.

En comparación, ASM.JS sería fácil de convertir a WASM.

Correcto, y de hecho, la forma principal en la que compilamos C ++ en wasm hoy es compilarlo en asm.js primero, luego compilar ese asm.js en wasm usando asm2wasm de Binaryen .

@kripken Mirando las especificaciones de asm.js, parece fácil escribir asm.js escrito a mano, lo que significa que no todo está perdido para los programadores de js, aún podemos obtener binarios de WASM usando lo anterior.

¿La evolución de JS, es decir, un lenguaje estrictamente escrito, no podría convertirlo en un buen candidato para JS -> WASM?
Creo que TC39 tiene una propuesta para un objeto escrito. Puede haber más otras características que podrían hacerlo posible.

@ aruns07 Cuantas menos funciones de JavaScript permita que las personas usen, más fácil será compilar en WASM y es más probable que las personas no estén dispuestas a vivir con sus restricciones debido a la incompatibilidad con sus bibliotecas favoritas.

@Kardax @ aruns07 A la gente le encanta la comodidad de un lenguaje dinámico. Necesitamos tipos fuertes de vez en cuando, no todo el tiempo.

jfbastien comentó el 24 de junio de 2015
JS → wasm solo tendrá sentido una vez que wasm admita GC, y muy probablemente también la compilación JIT, que todavía falta bastante. ¡Esto sería básicamente equivalente a implementar el motor JS en wasm!

Según el siguiente enlace:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
Consenso de WebAssembly y fin de la vista previa del navegador

Ahora, 2 años después de su primera respuesta, WebAssembly ahora es compatible con los principales navegadores web de la actualidad.
Por lo tanto, no es equivalente a implementar el motor JS en wasm.
Las ventajas de js -> wasm no son solo la compatibilidad con GC, sino también un tamaño de código más pequeño y una ejecución más rápida, especialmente en el campo del desarrollo de aplicaciones híbridas como Ionic2, que generalmente produce un archivo JS de alrededor de 10 MB, lo que hace que el tiempo de carga de la aplicación supere los 5 segundos (cada análisis de 2 MB de JS = 1 segundo)

@jfbastien Entonces, por favor, publique su respuesta actualizada sobre JS -> wasm transpiler?

Como parte de mi tesis de maestría, estoy tratando de escribir un Transpiler desde un subconjunto de JavaScript a WebAssembly. Al principio, estará limitado a TypeScript, pero otras variantes escritas como Flow podrían ser compatibles en el futuro.

Sin embargo, el objetivo no es implementar el lenguaje JavaScript completo ya que, en este caso, enfrentaría los mismos problemas que enfrentan las implementaciones JIT hoy y, por lo tanto, no se puede esperar una aceleración (más ciertamente, ¡mi implementación sería 100 veces más lenta! ). Va a ser un subconjunto como el definido por SoundScript.

Mi objetivo es permitir que partes específicas de una aplicación se compilen en WebAssembly sin la necesidad de que el desarrollador abandone su entorno de desarrollo familiar o utilice otro lenguaje de programación. Por lo tanto, estará más destinado a acelerar el rendimiento de las partes cruciales de una aplicación y no como un transpilador de propósito general que acepta cualquier aplicación JavaScript existente.

Tengo bastante curiosidad por saber cuáles serán mis hallazgos, ya que veo los pros y los contras de tal enfoque. Avíseme si tiene alguna aportación.

@ Mohsen7s mi respuesta sigue siendo precisa: la versión MVP de WebAssembly no es compatible con las capacidades GC y JIT que hacen posible implementar una máquina virtual JavaScript rápida. Un intérprete es completamente posible, con trucos inteligentes puede ser bastante bueno, pero no tanto como lo que hacen las implementaciones nativas.

Esto es inherente a nuestro enfoque de "Producto mínimo viable": envíe primero algo que funcione para algunos casos de uso y luego agregue una función para satisfacer otros casos de uso. Consulte el siguiente hilo para ver una discusión similar sobre MVP y las "funciones futuras" que faltan: https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

Dejando de lado las discusiones técnicas sobre lo que se puede y no se puede implementar actualmente, me sorprende que JS -> WASM no sea el objetivo número 1, tanto desde el punto de vista filosófico como de marketing; no veo cómo llegará compra del desarrollador hasta que este sea el caso. Si todos esos desarrolladores front / back-end / full-stack con habilidades JS capaces de trabajar en cualquier mercado vertical quisieran, en cambio, dedicar su tiempo a aprender C ++, que se usa en un subconjunto de industrias sustancialmente más pequeño, entonces ya lo habrían hecho. así que ... lo sé, hablo como uno. No puedo evitar sentir que toda esta discusión es una especie de cámara de resonancia y que aquellos que defienden la falta de un compilador encontrarán que es mejor dedicar su tiempo a hablar con la gente en la cara del carbón preguntándoles qué es lo que realmente quieren.

@JefeLevel

Dejando de lado las discusiones técnicas sobre lo que se puede y no se puede implementar actualmente, me sorprende que JS -> WASM no sea el objetivo número 1, tanto desde el punto de vista filosófico como de marketing; no veo cómo llegará compra del desarrollador hasta que este sea el caso. Si todos esos desarrolladores front / back-end / full-stack con habilidades JS capaces de trabajar en cualquier mercado vertical quisieran, en cambio, dedicar su tiempo a aprender C ++, que se usa en un subconjunto de industrias sustancialmente más pequeño, entonces ya lo habrían hecho. así que ... lo sé, hablo como uno.

Los navegadores ya pueden ejecutar JavaScript de manera eficiente. Los navegadores no pueden ejecutar los casos de uso previstos de manera tan eficiente. Para colmo, WebAssembly tiene aspiraciones ajenas a la Web.

Esta discusión, así como https://github.com/WebAssembly/design/issues/992#issuecomment -281735235, ilustra la variedad de objetivos que tienen diferentes personas. ¡Ninguno está equivocado! MVP simplemente necesita priorizar a quién se atiende primero.

No puedo evitar sentir que toda esta discusión es una especie de cámara de resonancia y que aquellos que defienden la falta de un compilador encontrarán que es mejor dedicar su tiempo a hablar con la gente en la cara del carbón preguntándoles qué es lo que realmente quieren.

Ese fue el objetivo de formar un Grupo Comunitario W3C. Creemos que ha tenido éxito, como hemos escuchado de muchos desarrolladores interesados. Algunos no están interesados ​​en MVP, pero están interesados ​​en funciones futuras .

@jfbastien

Los navegadores ya pueden ejecutar JavaScript de manera eficiente.

¡Ja, he estado tratando de escribir un juego HTML5 multijugador masivo capaz de funcionar a un FPS decente en un teléfono móvil promedio desde 2008 y todavía no estoy allí! Y dado que cuando voy a contratar para pagar las facturas, estoy muy bien recompensado, estoy bastante seguro de que mi falta de progreso no se debe a la calidad de mi código.

Ese fue el objetivo de formar un Grupo Comunitario W3C

De nuevo, ¿cuántos desarrolladores del mundo real conoces que se unan a un grupo comunitario? Los desarrolladores que lo hacen suelen ser evangelistas, etc., que son conocedores, sí, pero han sentido menos el dolor de los desarrolladores de la vida real.

Y lo siento, realmente no quiero menospreciar a nadie en esta página / involucrado / en W3C. Como usted dice, esta es una discusión, y este es mi punto de vista desde el frente.

Disculpas por volver a esto como un perro preocupado por un hueso, pero mientras estaba fuera pensé en una mejor manera de expresar mi punto. En su próximo boletín / evento comunitario o cualquier medio que tenga para obtener comentarios, plantee esta pregunta a los desarrolladores web (sus clientes):

Para llevar el rendimiento basado en navegador al siguiente nivel, necesitará aprender otro idioma; ¿Sería esto aceptable?

Porque esa es básicamente la pregunta que ya (en mi opinión, de manera perjudicial) ha sido respondida por algunos en esta página.

Y finalmente (lo prometo ;-)) @jfbastien , si:

Para colmo, WebAssembly tiene aspiraciones ajenas a la Web.

¿Por qué se llama "WebAssembly"?

@BossLevel Creo que veo de dónde vienes. No puedo hablar por las personas que evangelizan, pero tengo entendido que diferentes evangelistas han estado en contacto con desarrolladores "nativos" tradicionales que están interesados ​​en WebAssembly. Desde su punto de vista, puede que no sea evidente, pero como mínimo puedo señalar el interés de Unity como una señal de desarrolladores "serios". Estas personas también publican en github, con sus propios nombres, pero las afiliaciones no siempre son evidentes. No me corresponde hablar por ellos.

¡Ja, he estado tratando de escribir un juego HTML5 multijugador masivo capaz de funcionar a un FPS decente en un teléfono móvil promedio desde 2008 y todavía no estoy allí! Y dado que cuando voy a contratar para pagar las facturas, estoy muy bien recompensado, estoy bastante seguro de que mi falta de progreso no se debe a la calidad de mi código.

No quise dar a entender que escribir JavaScript rápido sea fácil. Lo que quería decir es: WebAssembly no facilita la optimización de JavaScript. Más bien, permite que los navegadores consuman un formato más adecuado para generar un rendimiento confiable. También permite que TC39 se centre en mejorar JavaScript en sí mismo, no solo JavaScript como objetivo de compilación.

De nuevo, ¿cuántos desarrolladores del mundo real conoces que se unan a un grupo comunitario? Los desarrolladores que lo hacen suelen ser evangelistas, etc., que son conocedores, sí, pero han sentido menos el dolor de los desarrolladores de la vida real.

Y lo siento, realmente no quiero menospreciar a nadie en esta página / involucrado / en W3C. Como usted dice, esta es una discusión, y este es mi punto de vista desde el frente.

Su punto de vista es ciertamente válido y creo que está claro que, desde su punto de vista, estoy diciendo algo que es difícil de creer. Deberíamos comunicar esto mejor (o bueno, tal vez me equivoque: guiño :).

Para llevar el rendimiento basado en navegador al siguiente nivel, necesitará aprender otro idioma; ¿Sería esto aceptable?

Porque esa es básicamente la pregunta que ya (en mi opinión, de manera perjudicial) ha sido respondida por algunos en esta página.

Veo su preocupación, pero espero que no resulte cierta. Una vez más, puedo estar equivocado. A mi modo de ver, WebAssembly trae nuevos desarrolladores a esta plataforma, desarrolladores que tuvieron malas experiencias con la Web en el pasado o escucharon historias de terror. A su vez, ayuda a los desarrolladores de JavaScript que desean usar código "tradicional" (lo que algunos llaman "heredado") a usar ese código: queremos que WebAssembly sea fácilmente utilizable desde JavaScript. Para lograr esto, debe ser tan fácil como usar npm (que ... ¡no siempre es fácil!).

Estoy algo seguro de que esto resultará debido a los comentarios que hemos estado viendo en Twitter, Hacker News, Reddit y varias conferencias. De nuevo, tal vez me equivoque y estoy escuchando cámaras de eco. Como mínimo, he tenido discusiones muy prometedoras en conferencias con personas con experiencia en C ++ y JavaScript.

Al mismo tiempo, TC39 realmente está tratando de mejorar JavaScript. Creo que lo ha hecho en los últimos años, especialmente con ES6.

Pero su punto sigue siendo: tal vez los desarrolladores quieran estar bien versados ​​en JavaScript , así como en lenguajes más "compatibles con WebAssembly" como C ++ o Rust. No sé en qué dirección irán las cosas.

¿Por qué se llama "WebAssembly"?

¡Decir ah! Esa es una pregunta maravillosa. Tengo una charla titulada "WebAssembly: ni Web ni Assembly". Tendré que darlo públicamente para poder expresar lo que siento por el nombre: grin:

Así que te mantendré pendiente de eso.

Estoy leyendo dos deseos aquí:

1. Una representación binaria de JavaScript estándar para tiempos de carga rápidos.
2. Algo para cerrar la brecha de rendimiento entre C ++ compilado de forma nativa y JavaScript estándar.

El artículo 2 es objeto de investigaciones continuas e inversiones masivas de muchas empresas. Si observa las medidas de rendimiento de los motores JavaScript durante los últimos 15 años, también está funcionando ... la brecha es cada vez menor.

Hasta donde yo sé, nadie está trabajando en el punto 1. Es enormemente complicado y cada vez más difícil a medida que JavaScript continúa evolucionando a un ritmo rápido. WebAssembly es muy estricto y relativamente sencillo, y aún tardó años en desarrollarse.

@jfbastien - muchas gracias por su considerada y considerada respuesta :)

Entonces, un par de puntos ilustrativos, sin ningún orden en particular:

1) Un buen ejemplo que veo de toda esta discusión y mi punto de vista sobre la dirección en la que debería dirigirse, se encuentra en NodeJS, una API JS / front-end a un back-end de C ++, obtiene la facilidad de uso / familiaridad, etc.en por un lado y la velocidad por el otro.
2) Siguiendo con Node, en 2008, cuando me embarqué en mi propia odisea personal ;-) Originalmente, miré PHP y Java para el back-end (estaba volviendo al desarrollo después de una década en el lado oscuro de la administración de TI y ventas ;-)!) pero los descarté rápidamente por la sencilla razón de que solo quería tener que aprender un idioma, ¡y aprenderlo bien! Una historia personal que conozco, pero dudo que sea el único desarrollador que se siente así, especialmente aquellos que trabajan para ellos mismos, no con un centavo de la empresa mientras aprenden el idioma.
3) Deliberadamente no busqué en Google los números antes de hacer mi siguiente punto (de hecho, no estoy seguro de poder hacerlo), pero estaré dispuesto a apostar que la aceptación de ASM fue baja. Sé que me emocioné mucho cuando vi la demostración inicial, pero al enterarme de que no había un compilador, lo descarté de inmediato. Pedirle a un desarrollador web que forma parte de la comunidad de desarrolladores más grande del planeta (JS) con una amplia gama de API, bibliotecas, recursos, tutoriales, marcos, etc.disponibles en línea, que se aleje de eso, es en mi opinión pedir demasiado, y al no proporcionarles un medio para potencialmente dar ese primer paso (es decir, un compilador) falta un truco obvio de su parte. Incluso iría tan lejos como para apostar que el desarrollo en lenguaje de sombreado (GLSL) ha crecido más que ASM ahora que puede a) escribirlo directamente en marcos excelentes como Pixi.js y Three.js yb) jugar con él directamente en sitios como ShaderToy .
4) La industria de los juegos / juegos en general. Puedo hablar por experiencia aquí como a) he estado escribiendo (¡aún inéditos!) Juegos durante los últimos 9 años yb) he trabajado en la junta directiva de TIGA (la asociación comercial de desarrolladores de juegos del Reino Unido) durante 2 años. Créame, creo que la cantidad de desarrolladores de juegos que querían migrar a la web probablemente podría contarse con una mano: los desarrolladores de juegos ya están en la industria que aman e incluso reciben un pago / trabajan muchas horas a pesar de eso, así que estos no debería ser el público objetivo de WA. Sí, sus empleadores siempre están buscando nuevos medios para portar sus juegos, pero no nos engañemos, excluyendo el móvil (donde lamentablemente el código nativo gana indiscutiblemente y que es lo que quiero que arregle WASM), la web sigue siendo la mejor opción. mala relación con PC / consola tanto en términos de rendimiento como de monetización.
5) Por el contrario, si bien la escena indie / codificadora de dormitorio no está en el cenit de hace unos años, hay una gran cantidad de desarrolladores web a los que les apetece hacer un juego web en su tiempo libre. Y aunque no quiero desviarme abiertamente hacia la política y de ninguna manera estoy atacando a los chicos de Unity (he tenido tratos con varios de ellos y es un gran producto), personalmente creo que deberías estar cuidando los intereses. de los múltiples tipos pequeños, no del tipo grande (tiene sentido tanto filosófico como comercial).

Espero con ansias ver su charla @jfbastien :)

@RyanLamansky : creo que hace una distinción razonable. Con respecto a:

Hasta donde yo sé, nadie está trabajando en el punto 1. Es enormemente complicado y cada vez más difícil a medida que JavaScript continúa evolucionando a un ritmo rápido.

A un nivel completamente personal, como alguien que ha estado escribiendo JS 8 horas al día desde 2008, ¡me gustaría mucho ver la evolución de JS simplemente detenerse por un tiempo y dejar que todos los demás se pongan al día! Siempre he trabajado en un principio de desarrollo para el mínimo común denominador, es decir, si no tiene el 100% de soporte, no está sucediendo (aparte de IE6 / 7/8/9 ;-)). Y así nos encontramos en la ridícula posición de centrarnos en los patrones de moda ES6 y supuestos casos de uso cuando ni siquiera tenemos un 100% de compatibilidad con el navegador ES5 en computadoras de escritorio y dispositivos móviles. El lenguaje funciona claramente como está (a pesar de sus debilidades admitidas) como lo demuestra su participación en el mercado, entonces, ¿qué tal si nosotros, como comunidad de desarrolladores, pasamos los próximos años aprendiendo a escribir código eficiente y óptimo con lo que tenemos en lugar de una vez más reinventar la rueda con un nuevo código hipster (lo siento, estoy entrando en territorio de peroratas ;-))?

Creo que probablemente sea hora de que compre mi abrigo ;-)

@RyanLamansky He tenido la impresión de que WebAssembly será un nuevo objetivo para el proceso de creación de paquetes y, de repente, todo será más rápido. Claramente ese no es el caso. WebAssembly tiene un caso de uso de destino muy específico, y probablemente no tendrá mucho que ofrecer al desarrollador web típico con una gran base de código JS llena de lógica empresarial.

Pero como puede observar, existen algunas lagunas en el ciclo de vida del desarrollo basado en JS para aplicaciones web orientadas a negocios más típicas:
1) Los paquetes JS grandes tienen una sobrecarga de análisis significativa y, por lo general, proporcionan una ofuscación insuficiente.
2) El código JS estándar carece de las anotaciones de tipo (y quizás otras sugerencias) necesarias para realizar optimizaciones de código JIT / nativo.

Esto sugiere que una posible solución es una versión de JS debidamente escrita y anotada que le brinda al desarrollador rutas de optimización más deterministas y transparentes, y una versión binaria previamente analizada de esa versión del lenguaje.

Los comentarios y los documentos dicen que WASM se ejecuta además de JS y utiliza el mismo motor JS de los navegadores (optimizado). https://developer.mozilla.org/en-US/docs/WebAssembly

Realmente no entiendo esta pregunta.

Perdón por hacer una pregunta estúpida y hacer un comentario estúpido: ¿La pregunta y el comentario del equipo de Webassembly significan que Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? solo veo pensamientos subjetivos? ¿Alguien puede explicar esto? Si Webasembly es más rápido que Javascript, ¿por qué no proporcionar un transpilador? Si Javascript no es posible, ¿por qué no el código ES7 / TS? ¿Por qué hay tanto secreto en torno a esto?

@ganeshkbhat La versión inicial de WASM es poco más que una codificación binaria compacta de asm.js, que es un subconjunto muy estricto de JavaScript. No se ejecuta más rápido que asm.js a menos que se utilicen enteros de 64 bits, ya que deben emularse en asm.js.

Hay propuestas para agregar características a WASM que lo acercarían a JavaScript en capacidad (recolección de basura, integración DOM, subprocesos), pero no hay planes para agregar el conjunto completo de características de JavaScript. Por lo tanto, es probable que nunca exista un transpilador JS-> WASM. En su lugar, se crearán nuevas aplicaciones y bibliotecas diseñadas para funcionar dentro de las limitaciones de WASM. Hoy en día, eso es C y C ++, donde las restricciones de idioma se alinean bien con WASM y asm.js.

No hay ningún secreto ni magia. Wasm es "más rápido que JavaScript" porque es un lenguaje mucho más simple que está mucho más cerca del hardware. JavaScript es un lenguaje complicado que tiene que hacer muchas cosas caras durante la ejecución. No se volvería mágicamente más rápido compilándolo en código nativo a través de Wasm en lugar de hacerlo directamente.

@ganeshkbhat actualmente, no es posible asignar objetos dentro de asm.js / webassembly. En asm.js y webassembly, todas las operaciones de JavaScript usarán un gran typedarray para almacenar y cargar sus valores. La creación de objetos JavaScript (por ejemplo, var obj = {a: 1, b: 'test'} ) y matrices (por ejemplo, var a = []; ) no es posible dentro de webassembly ya que todavía no hay soporte para objetos. Esta es una decisión de diseño del Producto Mínimo Viable que se tomó para obtener soporte de ensamblaje web en los principales navegadores lo antes posible.

En una versión futura, se prevé la compatibilidad con GC para el montaje web. Nosotros (los desarrolladores de LeaningTech.com ) estamos trabajando en una propuesta para el soporte de objetos en el subconjunto más grande de JavaScript , pero no admitirá todas las funciones que están disponibles actualmente.

Seguro. Espere un mejor soporte para JS aquí. Definitivamente siento que se puede apoyar. Escribir un transpilador es lo que podría ser necesario para los lenguajes de soporte de tipos.

Por lo que leí sobre webassembly, se dirige principalmente a navegadores web y en esa área no suena muy atractivo tener js -> compilador webassembly. Pero puedo imaginarme ejecutando webassembly en entornos sin navegador. Esto no es del todo cierto, ya que también se puede ejecutar en nodejs, pero veo su verdadero potencial en entornos de nodejs en algo como vertx : políglota que permite ejecutar módulos escritos en cualquier idioma, que se pueden compilar en webassembly. Puedo imaginar que será extremadamente difícil hacer algo como esto. Requerirá muchas características como GC, tal vez incluso algún tipo de VM para ser implementado, pero nada es imposible. Recuerde que mucha gente también se mostró escéptica acerca de asm.js y mírelo hoy.

Para todos aquellos que están entusiasmados (como yo) con la compilación de js -> webassembly, puede haber una forma indirecta y muy accidentada a través de js -> c -> webassembly usando el

@ mauron85 Los entornos de tiempo de ejecución sin navegador y sin JavaScript son definitivamente una consideración del diseño, es solo que solo existe la API JS en la actualidad.

Por mi parte, he estado experimentando con un sistema .NET JIT y no veo ninguna barrera real aparte del tiempo, y estoy seguro de que hay otros que buscan integrar WASM en sus plataformas favoritas también. Estoy seguro de que dentro de unos años habrá tiempos de ejecución sin JavaScript de alta calidad para WebAssembly, la única pregunta abierta es hasta qué punto serán respaldados formalmente por el equipo de WebAssembly.

En mi opinión, uno de los beneficios de la capacidad de compilación JavaScript -> WebAssembly es que los desarrolladores / mantenedores de las bibliotecas y herramientas de Javascript probablemente podrían lanzar sus API en dos formatos:

1. en JS (como está ahora) que los usuarios pueden usar para navegadores y nodos
2. WASM como la biblioteca compilada que podría ser más eficiente.

Y esto sin tener que volver a escribir su código JS existente en C / C ++, si quieren aprovechar los beneficios de rendimiento de WASM en sus bibliotecas JS.
Por lo tanto, los desarrolladores de bibliotecas aún podrían desarrollar y mantener en Javascript y producir dos salidas para dos objetivos diferentes tanto en JS como en WASM.

Y el uso de la biblioteca de versiones WASM compilada definitivamente sería más eficiente para los usuarios, ya que todo lo que necesitan hacer es usar la API expuesta de la biblioteca y, obviamente, no les importará si está escrito en WASM o no. Pero el rendimiento sin duda mejoraría.

WASM como la biblioteca compilada que podría ser más eficiente

¿Por qué? ¿Por qué una gota de ensamblado web transpilado de javascript (en el peor de los casos, incluida gran parte del tiempo de ejecución de un motor javascript en ese binario; en el mejor de los casos, incluida una capa construida sobre el futuro GC integrado de wasm, que de todos modos incurre en su propia sobrecarga) ) se ejecuta más rápido que el javascript lanzado en un jit dedicado a ... ¿ejecutar javascript?

Bien, ¿quiere decir que sería aún más lento con más gastos generales?

Quizás hay algo que no he entendido bien. ¿Cómo son las cosas compiladas C/C++/Rust -> WebAssembly realmente eficientes e incluso si hay un soporte JS -> WASM en el futuro que causaría gastos generales? ¿Es eso solo porque JS es un lenguaje dinámico y C, C ++ y Rust no lo son? ¿O es porque JS, por naturaleza, no es un lenguaje completamente compilado, pero estos otros lenguajes sí lo son?

Supongo que es poco probable que la compilación de JS a WASM aumente el rendimiento sostenido; sin embargo, puede mejorar el tamaño del código y el tiempo de análisis debido a la codificación binaria, que sigue siendo útil.

Creo que podemos definir una codificación binaria para JS e ignorar la memoria lineal, etc. por ahora. Esto es simple y se puede rellenar.

@kabirbaidhya El principal problema con JS -> WASM en este momento es que no se puede construir un recolector de basura eficiente dentro de él, ya que no hay forma de analizar la pila para ver qué objetos están vivos. Esto significa que tendría que colocar una copia de todas las referencias de objetos en la memoria lineal (el montón) y mantenerla sincronizada, degradando seriamente el rendimiento. También carece de subprocesos múltiples de memoria compartida, por lo que la recolección de basura en segundo plano es imposible. Las versiones futuras de WASM podrán aprovechar el motor de recolección de basura del navegador host, eliminando este problema.

La otra barrera importante para JS -> WASM es el hecho de que casi todos los objetos son completamente dinámicos. WASM espera intrínsecamente que todo sea puramente estático, por lo que se necesitarían capas de mapeo complejas, emulación y generación de código dinámico para acercarse al rendimiento estándar de JS. Afortunadamente, TypeScript ayuda con esto, por lo que un subconjunto estricto de TypeScript puede apuntar a WASM hasta cierto punto. Sé que hay al menos una persona que intenta construir esto.

C / C ++ funciona bien con la primera versión de WASM debido al hecho de que las limitaciones de WASM están estrechamente alineadas con las limitaciones del hardware nativo, a las que C / C ++ están diseñadas para apuntar.

FWIW hay una gran presentación de diapositivas sobre cómo V8 maneja la aritmética de JavaScript: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr este es solo un ejemplo en el que la realidad es mucho más difícil de lo que parece y en la práctica no es muy significativa, ya que la VM nativa puede (y probablemente lo hará) hacer un trabajo mejor y más rápido, ya que es verdaderamente nativa y tiene acceso a recursos y API nunca lo hará, y (probablemente) lo más importante, años de iteración.

Eso no quiere decir que un _subconjunto_ de JS / TypeScript no pueda proliferar con éxito, como ThinScript , TurboScript , etc. A los programadores de JS les parecerán muy familiares a primera vista.

Sigo pensando que estas son buenas preguntas para hacer y sigo haciéndolo. Es fundamental que todos comprendamos los casos de uso y el futuro de WebAssembly, así como los no objetivos.

El 6 de abril de 2017 a las 00:36, Ryan Lamansky [email protected] escribió:

La otra gran barrera para JS -> WASM es el hecho de que casi todos los objetos
son completamente dinámicos. WASM espera intrínsecamente que todo sea puramente
capas de mapeo estáticas, tan complejas, emulación y generación de código dinámico
sería necesario para acercarse al rendimiento estándar de JS. Afortunadamente,
TypeScript ayuda con esto, por lo que un subconjunto estricto de TypeScript puede
apuntar a WASM hasta cierto punto. Sé que hay al menos una persona intentando
construye esto.

Desafortunadamente, dudo que TypeScript ayude en este sentido. Para abarcar
JS legacy, su sistema de tipos es tan profunda y fundamentalmente erróneo que
no hay un subconjunto "estricto" interesante. Por ejemplo, tal subconjunto
necesidad de excluir cualquiera de las nociones de subtipificación de TS, lo que lo haría bastante
mucho inútil en su dominio.

Ha habido buenos trabajos de investigación, como por ejemplo sobre SafeTypeScript, pero no
sólo que son más restringidos, también requieren cantidades sustanciales de
costosos controles y contabilidad en tiempo de ejecución adicionales, anulando el propósito de
la discusión (y efectivamente siendo un lenguaje diferente al de JS / TS).

Tal vez no obtengo algo, pero una de las ideas de WebAssembly es cargar directamente el AST para evitar el tiempo de análisis de js, ¿verdad?

Entonces, si tenemos una herramienta que compila js en este formato ast y lo pasa al navegador, ¿no se beneficiará de evitar el tiempo de análisis?

@agnivade , es un AST para un lenguaje completamente diferente, mucho más de bajo nivel.

Si tuviera que compilar JS en Wasm sin conexión, entonces sí, no necesitaría analizar en el lado del cliente (solo decodificar). Al mismo tiempo, debido a que JS es tan complicado, el tamaño del código aumentaría drásticamente, probablemente en un factor de 5 o más, lo que es un costo mucho mayor. (Y eso ni siquiera tiene en cuenta que probablemente también necesitaría incluir una implementación completa de un sistema de tiempo de ejecución JS VM en Wasm, que fácilmente son megabytes de código).

Además, sin una representación de las fuentes, no puede implementar la mayoría de las optimizaciones dinámicas que son cruciales para que JS sea casi rápido. Estas optimizaciones se basan en volver a compilar el código fuente original y especializarlo en función de la información de creación de perfiles. Un Wasm AST ya compilado no permite eso, necesitaría un AST del programa fuente original.

@ rossberg-chromium - Muchas gracias. ¡Eso se aclara mucho! Una duda, aunque -

Y eso ni siquiera tiene en cuenta que probablemente también necesitaría incluir una implementación completa de un sistema de tiempo de ejecución JS VM en Wasm, que fácilmente son megabytes de código

¿Por qué necesitaría el sistema de tiempo de ejecución de VM? ¿No es el navegador en sí el tiempo de ejecución de la máquina virtual? Solo quiero que el código esté en formato AST para que el navegador pueda comenzar a ejecutarlo fácilmente. Entiendo que el tamaño neto aumentará porque el lenguaje en sí es complejo y no podemos implementar optimizaciones dinámicas. Pero, ¿por qué necesitamos agrupar el tiempo de ejecución de la máquina virtual en sí, cuando tenemos el navegador para eso?

@agnivade , sin optimizaciones dinámicas JavaScript será lento, y me refiero a _realmente_ lento, como 100 veces más lento, tal vez peor.

Por "tiempo de ejecución" no me refiero a cosas del navegador como DOM, sino al soporte del lenguaje JS simple, es decir, cosas como recolector de basura, representaciones de objetos, primitivas y bibliotecas base, etc. Eso es bastante grande para JavaScript, y necesita una reimplementación de todo dentro de Wasm.

Y, por supuesto, también necesitaría una capa de interfaz para el DOM.

Ok, creo que ahora entiendo un poco mejor las cosas. Pensé que el

recolector de basura, representaciones de objetos, primitivas y bibliotecas base, etc.

se puede utilizar desde el propio navegador. Y puedo dejar que el navegador cargue el AST y haga su trabajo habitual. Pero ahora me doy cuenta de que todo debe estar empaquetado dentro de WASM.

¡Sin embargo, un código de bytes de lenguaje de scripting universal sería interesante! Un objetivo de compilación diseñado para transportar y ejecutar de manera eficiente programas escritos en lenguajes de recolección de basura con tipos dinámicos, con todos los casos extremos extraños de los populares (javascript, ruby, python, lua) cubiertos en (algunos casos) códigos de operación y estructuras especiales, etc.

@distransient , ¿quieres la locura combinatoria de todos los lenguajes de scripting? Soy optimista de que sería posible para la humanidad reunir los recursos de ingeniería para especificar e implementar eso de manera eficiente para 2050. :)

Aquellos que estén interesados ​​en compilar TypeScript en WebAssembly usando LLVM. Echa un vistazo a este proyecto de alcance. https://github.com/MichaReiser/speedy.js
Parece que esta discusión nunca termina ...

@ rossberg-chromium dije que sería "interesante", no fácil ni bonito 😉

Un código de bytes de lenguaje de scripting universal sería interesante ...

Si bien WASM está evolucionando gradualmente para eventualmente admitir cosas como Python, podríamos tener soporte de primera clase para desarrollar lenguajes de scripting para la Web mucho antes de lo que WASM puede proporcionar, si abordamos el problema desde el extremo opuesto al mismo tiempo.

Debería ser relativamente simple para los motores de JavaScript exponer su capacidad para ejecutar AST de JavaScript, y los AST que aceptaron podrían estandarizarse (incluso si se convierten inmediatamente a un formato intermedio no estándar internamente).

Simplemente podríamos combinar un formato AST (como estree ) y un formato de serialización (como JSON) para crear un nuevo formato de archivo con una nueva extensión. Si los navegadores admitieran el formato en etiquetas de script, etc., entonces lenguajes como TypeScript y CoffeeScript simplemente se compilarían para analizar árboles, y el navegador lo tomaría desde allí. Los lenguajes transpilados no necesitarían generar código, y los mapas fuente tampoco serían necesarios, ya que la información léxica se basaría en la fuente real.

Una vez que se estableció el soporte básico, el estándar podría evolucionar gradualmente para cumplir con WASM en el medio, básicamente simplemente agregando nuevos tipos de nodos. Hay cosas simples para comenzar, como los nodos explícitos add y concat , o tal vez agregar nuevos tipos de datos, como DEC64.

A medida que WASM se desarrolla para admitir lenguajes de scripting, al agregar cosas como GC, la ejecución de AST se movería hacia abajo, extendiendo la semántica de JavaScript para incluir características de otros lenguajes de alto nivel, por lo que un conjunto más amplio de lenguajes de scripting podría compilarse en una especie de JavaScript abstracto .

El 25 de mayo de 2017 a las 02:57, Carl Smith [email protected] escribió:
>

Hay algunos problemas que deberían abordarse, pero sería
relativamente simple para que los motores de JavaScript expongan su soporte interno
para ejecutar AST de JavaScript, y los AST que aceptan deben ser
estandarizado (incluso si el AST se convierte inmediatamente a no estándar,
formatos intermedios internamente).

Solo para una definición mucho más amplia de "relativamente simple" de lo que probablemente
tener en mente... ;)

En relación con WASM, es simple.

@bguiz Por ejemplo:

• No puede traducir JS de forma nativa a ASM, porque tiene una arquitectura diferente.
• No puede manipular DOM desde ASM, porque no tiene acceso a sus recursos al nivel del suelo de la CPU.

El motor Google V8 ya compila JavaScript directamente en el código de máquina nativo, compilando toda la tarea en tiempo de ejecución, antes de ejecutarla.

Por lo tanto, sería totalmente innecesario tener una tubería WASM alternativa desde el lado del cliente.

Por otro lado, WASM se presentó con una demostración de Mandelbrot, luego presenta la demostración de Unity "Tanks" en primer lugar, pero dudo mucho que dibujar píxeles con ASM-> CPU (incluso con SSE doble precisión) pueda ser más rápido. que WebGL-> GPU, porque como dice esta comunidad, la GPU no está en el alcance. ¿Y qué?

@ivanherczeg ¡

@SephReed

Ya tenemos tensiones debido a las diferencias entre bikeshed y x86. Creo que agregar otro conjunto de objetivos de hardware crearía más tensión: más operaciones tendrían que ser lentas debido a los costos de emulación para obtener una semántica uniforme en todos los objetivos, o más operaciones tendrían que tener un comportamiento indefinido para permitir que todos se ejecuten más rápido. Creo que eso hace que no sea rentable considerar la GPU en este momento (o nunca).

-Fil

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

El tiempo de ejecución de C # se transfirió a wasm y era un prototipo completamente funcional que reemplazaba a JS por completo. Entonces, esto significa que en el futuro puede esperar que surjan tiempos de ejecución para reemplazar JS en los navegadores y escribir aplicaciones web del lado del cliente en Java, C # o incluso C ++ con una declaración que diga "El código se ejecutará más rápido cerca del nativo" , "El código compilado es más rápido que la VM". o cualquier cosa sin la ayuda de JavaScript.

Mire este video de lo que estoy tratando de decir.

WebASM se introdujo para complementar JS y no asumir el control por completo, reemplazando el lenguaje de primera clase.

En un futuro cercano, puede esperar que las páginas web se entreguen desde un servidor compilado de forma nativa

https://github.com/ballercat/walt

@Steakeye Muy bonito :) Tendré una obra de teatro, muchas gracias por destacar :)

puede compilar JS en WebAssembly usando NectarJS. Demostración: http://nectar-lang.com/ elija del menú desplegable WebAssembly

Interesante, la demostración de NectarJS usa emscripten, puede ver eso en la salida de asm.js. Parece que compila estáticamente JS en algo, probablemente C o LLVM IR, y luego lo ejecuta a través de emscripten.

La salida de wasm también usa emscripten (se puede ver al inspeccionar el binario), pero parece usar una versión anterior, ya que emite binarios de wasm 0xd, que no se ejecutan en máquinas virtuales modernas. También solo le envía el wasm, no el JS, por lo que de todos modos no se puede ejecutar. En cualquier caso, es muy posible que esté haciendo lo mismo que para asm.js, simplemente ejecutando emscripten con la bandera para la salida wasm activada.

La demostración tiene un límite de 300 bytes en la entrada, por lo que es difícil alimentarlo con un programa del mundo real para tener una idea de cuán poderoso es su análisis, que es la verdadera pregunta con un enfoque estático como este. En general, la investigación académica sobre este tema sugiere escepticismo.

Sus demostraciones compiladas para Windows simplemente fallan para mí 🤕

Estoy de acuerdo con el escepticismo de @kripken aquí. Creo que JS arbitrario no se puede convertir razonablemente a WebAssembly. Cualquier herramienta que pretenda lograr esto probablemente esté trabajando en algún subconjunto manejable del lenguaje JS o renunciando al rendimiento de ejecución.

JS es un lenguaje extremadamente dinámico. Las operaciones en tiempo de ejecución impredecibles pueden cambiar de manera significativa y global la semántica del código. Esto significa que un compilador adelantado (o fuera de línea) solo puede asumir lo peor y generar un código genérico muy ineficiente que puede manejar todos los casos posibles. Para un ejemplo, tome el siguiente código JS:

var a = {prop1: 1};
func(a);

podría convertirse (en pseudo-wasm) a este

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

Ahora, esto está muy lejos de lo que razonablemente podemos considerar "compilar" y es más similar a desenrollar un intérprete. Por supuesto, también es posible ejecutar un intérprete JS compilado para Wasm, pero eso difícilmente sería una ganancia de rendimiento.

Los motores JS como V8 y Spidermonkey pueden ejecutar código JS tan rápido como lo hacen compilándolo Just-In-Time. Al hacer la compilación JIT, pueden observar cuál es la semántica real prevista para una pieza determinada de JS y generar código rápido para ese caso específico, mientras que, por supuesto, tienen cuidado de detectar cualquier cambio en el entorno que pueda invalidar las suposiciones actuales.

Acordado. Sin embargo, no me importaría usar un subconjunto de JavaScript. O tal vez una variante escrita, que probablemente reduciría el dinamismo y permitiría generar un código más eficiente.

¿Hay alguna novedad sobre el frente del "modo fuerte" por cierto?

@ Simran-B, hace tiempo que abandonamos el modo fuerte, por las razones que se resumen aquí . La conclusión es que es prácticamente imposible ajustar la semántica de JavaScript sin perder la interoperabilidad con el código existente.

Por la misma razón, tampoco tengo muchas esperanzas con la idea de diseñar un dialecto "compilable estáticamente" de JavaScript o TypeScript; sería un lenguaje diferente que no puede ejecutar código existente, así que no tiene mucho sentido.

@ Simran-B: "Sin embargo, no me importaría usar un subconjunto de JavaScript. O tal vez una variante escrita"

Hay un trabajo muy interesante en ese espacio, como AssemblyScript, que es un subconjunto estricto de TypeScript que se compila en WebAssembly, https://github.com/AssemblyScript/assemblyscript

@rossberg : "Tampoco tengo muchas esperanzas con la idea de diseñar un dialecto" compilable estáticamente "de JavaScript o TypeScript; sería un lenguaje diferente que no puede ejecutar código existente, así que no tiene mucho sentido".

Creo que el gran potencial de cosas como AssemblyScript no se trata de ejecutar código existente (estoy de acuerdo contigo, eso no será factible en general), sino que tener un lenguaje amigable y familiar es un gran problema.

En este momento, si es un desarrollador de TypeScript y desea escribir WebAssembly, debe usar C ++ o Rust. Ambos son buenos idiomas pero también tienen inconvenientes. Para alguien con esa experiencia, algo como AssemblyScript podría ser el camino más rápido hacia la productividad.

Si AssemblyScript puede compilar tanto en JavaScript como en Assembly, sería bastante ideal. Esperamos estas actualizaciones.

Además, en el futuro, a menos que alguien lo haga primero, probablemente intentaré escribir un convertidor de TypeScript -> Assembly Script que revise los archivos, haga las preguntas que deba hacer y luego realice la conversión. ¡Ojalá funcione!

@SephReed Sí, se puede compilar en JavaScript, porque hay un compilador WebAssembly -> asm.js , que debería funcionar con todo el código WebAssembly.

Consulte también la sección "¿Se puede polrellenar el WebAssembly?"

Si en cambio quiso decir "¿es posible que AssemblyScript compile en código JavaScript idiomático ?", Entonces tengo que preguntar, ¿por qué querría hacer eso cuando WebAssembly / asm.js son mucho más rápidos que el código JavaScript idiomático?

Aunque supongo que debería poder ejecutar el código AssemblyScript a través del compilador TypeScript. Sin embargo, deberá tener en cuenta ciertas cosas .

Consulte también esta sección de la documentación de AssemblyScript.

Caballeros, consideren WALT , el lenguaje WebAssembly similar a JavaScript.

UPD. Perdón por necropostar

Veo que mucha gente considera que este compilador "JS -> WASM" es una buena idea.

Para aquellos que no lo encuentran útil, como:

Sin embargo, no estoy seguro de que sea tan útil desde la perspectiva de un desarrollador. Puede obtener una reducción de tamaño, pero eso es todo. Desde la perspectiva de un navegador, puede ser interesante tener el motor JS implementado en wasm desde una perspectiva de seguridad pura.

Por favor, aquí está mi ejemplo concreto de por qué es importante y útil, y no solo "obtienes algo de reducción de tamaño, pero eso es todo". Una de las características que vienen con WebAssembly es:

<= XXX « MEDIO AMBIENTE SANDBOXED » XXX =>

WebAssembly no se trata solo de rendimiento. Es posible que vea un buen artículo sobre complementos del equipo de Figma .

Hacer un sistema de complementos es bastante desafiante. Necesita una buena forma de ejecutar código personalizado. Necesita un entorno separado, uno seguro.

WebAssembly le ofrece eso: un entorno puro sin desorden como algunas variables globales. AssemblyScript lo hace conveniente de alguna manera: tiene casi el mismo entorno de TypeScript, que el entorno de su aplicación principal, lo cual es bastante bueno.

Pero aquí está el problema, "casi el mismo":

¿Puedo usar paquetes JS de NPM dentro de mi entorno seguro?

No.

Bueno, este proyecto WALT es una especie de alternativa de AssemblyScript. Es apenas como JS, se escribe js. Es más parecido a TS. No puede compilar / transpilar bibliotecas js existentes con eso.

¿Puedo usar paquetes TS de NPM dentro de mi entorno seguro?

No.

AssemblyScript también es un lenguaje similar a TS. Puede compilar algo escrito en TS si está completamente cubierto de tipos. Sin excepciones. No hay any . Pero a menudo las personas tienen configuraciones que no son lo suficientemente estrictas o tienen algunos @ts-ignore , o incluso con más frecuencia, escriben paquetes en js y proporcionan tipos separados en archivos .d.ts , en todos estos casos no podrá compilar dicho paquete en WASM.

@JerryGreen tiene buenos puntos, pero en el lado del rendimiento, creo que es un gran error pensar que no hay beneficios de rendimiento significativos más allá de ahorrar unos pocos bytes. La gente, incluidos los puntos de referencia, está tan obsesionada con el rendimiento en tiempo de ejecución. ¿Ves lo rápido que se ejecutan los juegos en 3D?

Sin embargo, la oportunidad del mundo real está en el rendimiento de las startups , que beneficia prácticamente a todos los sitios web. Pocos parecen hablar de cómo WebAssembly es sustancialmente más rápido en el tiempo de inicio (por byte), mucho más allá de los beneficios del tiempo de ejecución. Esta es la razón por la que, por ejemplo, gzip en contenido textual, como JavaScript, tiene poco impacto en el mundo real en PLT: lo que importa es el tamaño del código compilado .

Irónicamente, la industria está obsesionada con PLT (Page Load Times) y varios marcadores visuales completos, pero ¿nadie ve la correlación entre WebAssembly y estos vectores? JavaScript es responsable de más del 30% del tiempo pasado antes de estos eventos críticos, en la mayoría de los sitios web. De hecho, el tamaño de las páginas y el ancho de banda tienen un impacto mucho menor en los PLT en comparación con los factores de rendimiento lineal, a saber, los tiempos de inicio y la latencia de JavaScript.

Dicho esto, no me queda claro la viabilidad de JS -> WebAssembly.

El enfoque de @JerryGreen Figma es un caso muy específico y supongo que para la mayoría de los proyectos los iframes o reinos son lo suficientemente bonitos para el aislamiento de javascript de terceros. Para casos especiales donde el aislamiento debe ser más controlado y el rendimiento, el tamaño y el tiempo de carga no son tan importantes, siempre puede compilar QuickJS o JavaScriptCore en WebAssembly.

También puede usar Web Workers y ejecutar código antes de su código que no es de confianza que elimina las API a las que no desea que tenga acceso el código que no es de confianza. ¡No hay necesidad de WASM en este caso @JerryGreen!

La velocidad de fotogramas cae en tres js en una cosa real, no estoy seguro de si wasm podría ayudar, pero al menos lo parece en la superficie.

No hay ninguna razón para compilar JS en wasm porque también tendría que incluir una máquina virtual javascript completa. El código resultante sería enorme y más lento que el JS VM proporcionado de forma nativa.

¿No podríamos hacer toda la monomorfización, etc. que realizan las máquinas virtuales JS a través de la optimización guiada por

Una compilación de PGO consta de dos pasos: un primer paso para compilar binarios instrumentados, luego un segundo paso para reconstruir binarios optimizados utilizando la información de perfil obtenida al ejecutar los binarios instrumentados.

La primera ejecución nos proporcionaría toda la información de tipo (qué funciones se llaman con qué argumentos escritos, etc.), luego construimos un binario optimizado con todas las variantes con las que se llama a una función (+ uno genérico con argumentos dinámicos para código no perfilado) . No necesitaríamos toda la máquina virtual JS.

PGO requirió una gran cobertura de prueba de su programa. No siempre es posible. Pero podría rastrear algún tipo de información durante la ejecución en v8. Consulte este documento: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading = h.xgjl2srtytjt

Hemos hablado con el equipo de TypeScript sobre esta posibilidad y han mostrado interés, pero parece que actualmente se ha avanzado en la adición de objetos escritos en JS.

No necesito tipos

¿Se puede realmente compilar QuickJS en WASM?

Sí, Figma usa QuickJS para su sistema de complementos, por ejemplo

Y también se usa en http://numcalc.com/ .