Design: Haverá um compilador JS -> WASM?

Os navegadores ainda terão uma VM JavaScript nativa ao lado do wasm. Não há razão para compilar JS para wasm porque você também teria que incluir um javascript vm inteiro. O código resultante seria enorme e mais lento do que o JS VM fornecido nativamente.

Há uma tarefa pós MVP para adicionar coisas como adicionar acesso ao GC a partir do código wasm para que as linguagens de script possam ser implementadas para o wasm.

JS → wasm só fará sentido quando o wasm suportar GC e, provavelmente, compilação JIT também, que ainda está um pouco distante. Isso seria basicamente equivalente a implementar o mecanismo JS no wasm! Mencionei isso recentemente e @BrendanEich me acusou de ter sido assumido por horse_js.

Para ser claro, o objetivo do wasm não é _substituir_ o JavaScript, mas complementá-lo. Portanto, não é realmente uma meta no momento oferecer suporte a JS → wasm, mas os recursos que queremos implementar tornarão isso possível. Não tenho certeza se será útil do ponto de vista de um desenvolvedor, no entanto. Você pode obter alguma redução de tamanho, mas isso é tudo. Do ponto de vista do navegador, pode ser interessante ter o mecanismo JS implementado no wasm de uma perspectiva de segurança pura.

@jfbastien venci você por 2 segundos;)

Mas sua resposta é melhor. Estou animado para GC e JIT no wasm. Adoro criar minhas próprias linguagens e executá-las na web.

E quanto ao suporte de variantes como asm.js ou TypeScript / ES7? Esses
sabores de Javascript prometem algum nível de garantias de tipo.

Eu imagino que a necessidade de JIT seja menor, mas GC ainda é muito
necessário para esses idiomas. Teria um {sabor digitado JS} -> WASM faria
isso é mais viável?

W: http://bguiz.com

Em 24 de junho de 2015 às 09:44, Tim Caswell [email protected] escreveu:

@jfbastien https://github.com/jfbastien você me venceu por 2 segundos: P

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

Sim, um tradutor asm.js -> wasm é de alta prioridade, e Luke já o fez
trabalhar em um compressor que possa servir como um bom ponto de partida.

Na quarta-feira, 24 de junho de 2015 às 01h59, Brendan Graetz [email protected]
escreveu:

E quanto ao suporte de variantes como asm.js ou TypeScript / ES7? Esses
sabores de Javascript prometem algum nível de garantias de tipo.

Eu imagino que a necessidade de JIT seja menor, mas GC ainda é muito
necessário para esses idiomas. Teria um {sabor digitado JS} -> WASM faria
isso é mais viável?

W: http://bguiz.com

Em 24 de junho de 2015 às 09:44, Tim Caswell [email protected] escreveu:

@jfbastien https://github.com/jfbastien você me venceu por 2 segundos: P

-
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

Falamos com a equipe do TypeScript sobre essa possibilidade e eles mostraram interesse, mas parece que há progresso atualmente bloqueado na adição de objetos digitados em JS.

@bguiz : O mecanismo JS é o mecanismo wasm e continuará a oferecer suporte à linguagem padrão JS em evolução. Não se preocupe (eu não tinha certeza se você achava que isso poderia ir embora. Não em um futuro que eu possa prever). OTOH, como outros observaram, o wasm precisa de tempo para desenvolver GC, suporte JIT e outros recursos de linguagem dinâmica, para ser um alvo de primeira classe para JS. Mesmo quando ele evolui essas coisas, tenho dúvidas de que os mecanismos JS / wasm abandonarão sua sintaxe JS e integradas em favor de VMs JS-in-wasm baixadas. Veremos!

/ser

Um tradutor asm.js-para-WebAssembly também será algo que estamos planejando adicionar ao Emscripten .

Quanto ao JS normal, acho que outros responderam à pergunta acima.

Todo o sentido do JS é fácil de codificar e pode fazer coisas incríveis: dhteumeuleu ou codepen.io/ge1doot, mas você pode ver o código-fonte e é fácil de hackear.

"wasm" é apenas uma maneira de vender mais jogos e outros aplicativos para google, apple e co. A única "evolução" é que poderemos controlá-lo melhor com "no install", diretamente do servidor big brother ... Só estou surpreso que eles não tenham medo de comer um ao outro ainda ...

É possível com análise de código ou anotações de código compilar ECMAScript para WebAssembly. Isso não parece uma prioridade para a equipe WebAssembly, mas parece uma ótima ideia para um esforço independente.

Acabei de começar a experimentar uma linguagem de programação de brinquedo que pode ser relevante: https://github.com/evanw/thinscript. Ele usa a sintaxe do estilo TypeScript e compila para WebAssembly. Achei que deveria mencioná-lo porque pode ser um estudo de caso interessante. Também fiquei agradavelmente surpreso com a facilidade de geração do WebAssembly. Bom trabalho a todos!

Eu alertaria as pessoas sobre o uso de embalagens muito finas em cima do wasm, no entanto, em geral. Como um exemplo, folheando o código thinscript, vejo que há uma instrução while que é reduzida para loop { if (!condition) break; } , que será menos eficiente do que if (condition) loop { ...; br_if condition } em vários motores wasm.

Para mim, o que torna o wasm mais do que apenas um JS reaquecido é a possibilidade de uma filosofia diferente: como o wasm é um alvo do compilador, os compiladores podem realizar otimizações antes de enviar o código aos clientes, para que possamos manter as VMs do lado do cliente mais simples e mais rápido. No entanto, se os thin wrappers em torno do wasm se tornarem populares, haverá o risco de que as implementações do lado do cliente eventualmente tenham que ficar mais volumosas e complexas para fazer as otimizações que não estão sendo feitas.

Sim eu concordo. Uma das coisas que mais gosto no WebAssembly é sua simplicidade. Estou planejando adicionar otimizações de compilador e fazer benchmarks quando a linguagem estiver mais completa. Espero que o inlining seja uma das maiores vitórias, por exemplo, e não esperaria que o WebAssembly fizesse isso por mim. Também estou planejando fazer experiências com um destino de código de máquina e usarei as mesmas otimizações para ambos os destinos.

Parece muito legal! Estarei interessado em ver aonde isso leva.

Estou imaginando JS-> WASM sendo mais atraente para servidores do que clientes. Como uma visão geral de alto nível da arquitetura que tenho em mente ...

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

Nesta concepção, um mapeamento claro de WASM para LLVM IR para coleta de lixo seria muito desejável. A promoção de duplas IEEE para inteiros pode ser feita como uma passagem LLVM. A noção de JITs separados para código quente e quente pode ser implementada em termos de gerenciadores de passagem LLVM.

Apenas algumas ideias, sinta-se à vontade para deletar se for falso!

A compatibilidade entre ambientes é um problema sério no ecossistema JS. Babel tenta resolver esse problema transpilando para uma versão mais adotada do ES e acho que todos podemos dizer que é muito bem-sucedido.

Ainda há um problema aqui. Por exemplo, se você estiver transpilando seu código ES 2016 para ES5 para compatibilidade e seu código rodar em um ambiente com suporte ES 2016 (parcial ou completo), você perderá os benefícios de ter suporte ES 2016 em seu ambiente .

Se todos estão transpilando seus códigos para o ES5, então qual é a vantagem de ter o suporte do ES 2016 em um ambiente em primeiro lugar?

Um novo projeto chamado "babel-preset-env" tenta combater esse problema focando nos ambientes por suas versões. A ideia por trás disso é que (1) você pede para direcionar versões específicas ou "últimas versões X" de navegadores, (2) determina o menor denominador comum de recursos e (3) permite apenas as transpilações necessárias. Isso ajuda, mas infelizmente não pode resolver o problema.

Ainda corremos o risco de um grande fornecedor não se comportar e causar os mesmos problemas que a Microsoft estava causando com o Internet Explorer por anos. Todo o ecossistema está nas mãos de alguns fornecedores, que decidem o que implementar e quando implementar. Isso não é gratuito nem aberto.

A única solução é um novo alvo de compilação para JavaScript que tem desempenho e precisa de muito menos manutenção (espero que nenhuma) do que um mecanismo JS. Quando os ambientes (navegadores, Node.js, etc.) começam a oferecer suporte a esse destino, a implementação de novos recursos ES deve se tornar responsabilidade dos compiladores e não dos fornecedores de mecanismo.

JS -> WASM seria interessante para proteger a propriedade intelectual por ofuscação de código quando se trata de instalações no local de, digamos, aplicativos Electron em servidores de clientes. É difícil de acreditar, mas é verdade, existem muitas pequenas instituições na Alemanha com muito pouca ou nenhuma conexão com a Internet, o que requer instalações locais, mas fornecer todo o seu código em texto simples pode ser assustador para empresas de software.

@ Simran-B Wasm tem como princípio de design suportar um formato de texto familiar. Notavelmente, tem um design de fluxo de controle estruturado para análise rápida e é otimizado para definições de uso único usadas na ordem da pilha, otimizado para expressões legíveis. Portanto, não é um alvo de 'ofuscação de código', mas os desenvolvedores podem emitir sua própria 'ofuscação de código' além disso, mas devem entender que isso deve ter um custo em termos de eficiência de codificação reduzida e desempenho reduzido.

Olá a todos, acabei de descobrir o WebAssembly, mas pensando no compilador JS -> wasm, imaginei algo como a compilação Ahead-of-Time do Angular2, mas muito mais otimizada (estou pensando em machinecode em vez de javascript) ... Será que isso nunca será possível? Vale a pena?

EDITAR
Também estou pensando se algum dia haverá a possibilidade de o navegador enviar um sinalizador para o cliente que oferece suporte a wasm, e então podemos servir um aplicativo pré-compilado em vez de um arquivo javascript?

Richard

@ Richard87 você pode pensar em webassembly como um conjunto de instruções independente de plataforma com sua própria codificação especializada e convenções de chamada. Não há nada que diga que você não pode descrever um subconjunto de javascript que seria muito fácil de transpilar para o trabalho no mundo de webassembly dessas coisas, mas impor isso provavelmente seria difícil. O conjunto de recursos e a área de superfície de implementação estão sempre crescendo em javascript, e adaptar bibliotecas e estruturas existentes para trabalhar nesse subconjunto provavelmente seria difícil, especialmente devido à atual falta de coleta de lixo em webassembly, e você essencialmente perderia os benefícios do javascript existente código.

Com a adição de primitivas de coleta de lixo na webassembly, o subconjunto de javascript que seria viável para transpilar sem escrever uma grande e velha máquina virtual seria alargado, mas ainda na minha opinião não seria ideal em comparação com apenas transpilar de um mais adequado linguagem, uma vez que seus overheads em javascript seriam apenas marginalmente menores, os overheads importantes em aplicativos da web (a rede!) aumentariam e os benefícios que você gostaria de obter com o uso de javascript em primeiro lugar ainda estariam fora de alcance, além de chegar a dizer que usa algo que lembra "javascript" (este é na verdade um barco semelhante que o Unity está com o UnityScript, exceto que eles o adaptaram um pouco para se integrar melhor com seus subsistemas e convenções de chamada em geral, além de outros caprichos).

Acho que é extremamente importante para alguns de nós, que buscam o navegador e o Webgl, sermos mais rápidos para jogar. Pretendo trazer um jogo de qualidade comercial em webgl, mas a tecnologia atual produz tanto lixo que os frames pulam.
Os jogos de navegador usando mecanismos de jogo JS quase falharam e o Unity decolou. Eu acho que C ++ => Wasm é uma vantagem indevida para esses grandes criadores de framework como o Unity, que poderiam compilar seu código para WASM.
Mas e as pessoas que escrevem JS à mão usando Three JS ou Babylon ... Não ter um conjunto de ferramentas JS / Asm.js => Wasm significaria que um grande aplicativo em Js estaria morto e as pessoas usariam C ++ e backends de geração de código para produzir Wasm. Mais especificamente em jogos e tal.
Não ter um back-end JS => Wasm é injusto para os desenvolvedores JS. Além disso, o EMCC aloca um Big heap quando é executado e as velocidades são evidentes devido a isso, mas os desenvolvedores Js que escrevem um bom código js ainda não conseguiram obter tanto desempenho devido à complexidade de escrever tal código. Deve haver algum mecanismo para reutilizar a maioria das coisas e capacidade de chamar gc mais cedo ou à vontade. O salto de quadros quando o GC é executado faz com que o Webgl pule quadros é um grande problema e precisa ser resolvido. Deve haver algum mecanismo para ajustar manualmente o código JS melhor do que os geradores de código. como o Assembly escrito à mão, ainda produz um código muito menor e altamente alinhado. Isso deve ser possível na web-assembly.

@metacritical C ++ pode compilar para WASM porque muitas pessoas colocam muito trabalho no processo. O mesmo pode acontecer com o JavaScript, mas, pelo que sei, ninguém está tentando fazer isso no momento. Há poucos motivos para isso: o desempenho não será alterado.

O problema do seu motor é a coleta de lixo. Esse problema não desaparece se você construir um algoritmo de coleta de lixo que use memória linear e código WASM ... eventualmente, você terá que parar o programa para ver quais objetos ainda estão vivos e excluir os que não estão. A solução é não criar objetos de lixo, evitando a necessidade de o GC funcionar. Você não precisa do WASM para conseguir isso, você precisa retrabalhar seu motor.

Javascript ultra puro que reutiliza Arrays e produz pouco lixo é extremamente difícil de escrever. Também acho que Plain Js não pode ser compilado para WASM. Asm.js ou Typescript seria mais fácil de compilar para WASM devido à disponibilidade de anotações de tipo ou tipos neles, respectivamente.

@metacritical Difícil, mas não impossível. Mesmo nos mecanismos C ++, grande parte do código gira em torno do gerenciamento do tempo de vida do objeto. Embora não seja convencional, não há razão para que você não possa fazer o mesmo em JavaScript.

JS simples _pode_ ser compilado para WASM, mas o compilador teria que adicionar muitos códigos auxiliares para habilitar os recursos de nível superior do JavaScript, como coleta de lixo, reflexão, propriedades e assim por diante. Basicamente, tudo o que você obtém de graça com o mecanismo JS integrado do navegador. TypeScript não ajuda muito.

Em comparação, o ASM.JS seria fácil de converter para WASM. O subconjunto estrito de recursos JS permitidos pelo ASM.JS também é 100% coberto pelo WASM. Se houvesse um grande volume de código escrito em ASM.JS, isso valeria a pena, mas, pelo que eu sei, todos os principais arquivos ASM.JS são produzidos a partir do código-fonte C ++, que já pode ter como alvo direto o WASM.

Em comparação, o ASM.JS seria fácil de converter para WASM.

Correto, e na verdade a principal maneira de compilar C ++ para wasm hoje é compilá-lo para asm.js primeiro e, em seguida, compilar esse asm.js para wasm usando o asm2wasm de Binaryen .

@kripken Olhando para as especificações do asm.js, parece fácil escrever asm.js manuscrito, o que significa que nem tudo está perdido para os programadores js, ainda podemos obter binários WASM usando o acima.

A evolução do JS, ou seja, linguagem estritamente tipada, não poderia torná-lo um bom candidato para JS -> WASM?
Acho que TC39 tem proposta de objeto digitado. Pode ser que mais outros recursos tornem isso possível.

@ aruns07 Quanto menos recursos JavaScript você permitir que as pessoas usem, mais fácil será compilar para o WASM e é mais provável que as pessoas não queiram viver com suas restrições devido à incompatibilidade com suas bibliotecas favoritas.

@Kardax @ aruns07 As pessoas adoram a conveniência de uma linguagem dinâmica. Precisamos de tipos fortes ocasionalmente, não o tempo todo.

jfbastien comentou em 24 de junho de 2015
JS → wasm só fará sentido quando o wasm suportar GC e, provavelmente, compilação JIT também, que ainda está um pouco distante. Isso seria basicamente equivalente a implementar o mecanismo JS no wasm!

De acordo com o seguinte link:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
Consenso da WebAssembly e fim da visualização do navegador

Agora, 2 anos após sua primeira resposta, o WebAssembly agora é compatível com os principais navegadores da web.
Portanto, não é equivalente a implementar o mecanismo JS no wasm.
As vantagens de js -> wasm não é apenas o suporte a GC, mas também o menor tamanho de código e execução mais rápida, especialmente no campo de desenvolvimento de aplicativos híbridos como o Ionic2 que geralmente produz um arquivo JS em torno de 10 MB que faz com que o tempo de carregamento do aplicativo exceda 5 segundos (cada análise de 2 MB de JS = 1 segundo)

@jfbastien Por favor, poste sua resposta atualizada sobre JS -> wasm transpiler?

Como parte da minha tese de mestrado, estou tentando escrever um Transpiler de um subconjunto de JavaScript para WebAssembly. No início, ele será limitado ao TypeScript, mas outras variantes digitadas como Flow podem ser suportadas no futuro.

No entanto, o objetivo não é implementar a linguagem JavaScript completa, pois, neste caso, eu enfrentaria os mesmos problemas que as implementações JIT enfrentam hoje e, portanto, nenhuma aceleração pode ser esperada (mais certamente, minha implementação seria 100 vezes mais lenta! ) Vai ser um subconjunto como definido pelo SoundScript

Meu objetivo é mais permitir que partes específicas de um aplicativo sejam compiladas para WebAssembly sem a necessidade de o desenvolvedor deixar seu ambiente de desenvolvimento familiar ou usar outra linguagem de programação. Portanto, ele será mais destinado a acelerar o desempenho de partes cruciais de um aplicativo e não como um transpiler de propósito geral que aceita qualquer aplicativo JavaScript existente.

Estou bastante curioso para saber quais serão minhas descobertas, visto que vejo os prós e os contras dessa abordagem. Deixe-me saber se você tem alguma contribuição.

@ Mohsen7s, minha resposta continua correta: a versão MVP do WebAssembly não oferece suporte a recursos de GC e JIT, o que torna possível implementar uma máquina virtual JavaScript rápida. Um intérprete é totalmente possível, com truques inteligentes pode ser muito bom, mas não tanto quanto as implementações nativas fazem.

Isso é inerente à nossa abordagem de "Produto Mínimo Viável": envie algo que funcione para alguns casos de uso primeiro e, em seguida, adicione um recurso para atender a outros casos de uso. Consulte o seguinte tópico para uma discussão semelhante sobre MVP e falta de "recursos futuros": https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

Deixando de lado as discussões técnicas sobre o que pode e não pode ser implementado atualmente, estou surpreso que JS -> WASM não é o objetivo número 1 filosófico e de uma perspectiva de marketing - não consigo ver como você conseguirá adesão do desenvolvedor até que seja o caso. Se todos os desenvolvedores front / back-end / full-stack com habilidades em JS capazes de trabalhar em qualquer vertical do mercado quisessem, em vez disso, gastar seu tempo aprendendo C ++, que é usado em um subconjunto substancialmente menor de setores, então eles já teriam feito então - eu sei, falo como um só. Não posso deixar de sentir que toda essa discussão é um pouco como uma câmara de eco e que aqueles que defendem a falta de um compilador descobririam que seu tempo seria mais bem gasto falando com as pessoas na cara do carvão perguntando o que elas realmente querem.

@BossLevel

Deixando de lado as discussões técnicas sobre o que pode e não pode ser implementado atualmente, estou surpreso que JS -> WASM não é o objetivo número 1 filosófico e de uma perspectiva de marketing - não consigo ver como você conseguirá adesão do desenvolvedor até que seja o caso. Se todos os desenvolvedores front / back-end / full-stack com habilidades em JS capazes de trabalhar em qualquer vertical do mercado quisessem, em vez disso, gastar seu tempo aprendendo C ++, que é usado em um subconjunto substancialmente menor de setores, então eles já teriam feito então - eu sei, falo como um só.

Os navegadores já podem executar JavaScript de forma eficiente. Os navegadores não podem executar os casos de uso pretendidos com a mesma eficiência. Para piorar, o WebAssembly tem aspirações não relacionadas à web.

Esta discussão, bem como https://github.com/WebAssembly/design/issues/992#issuecomment -281735235, ilustra a variedade de objetivos que diferentes pessoas têm. Nenhum está errado! O MVP simplesmente precisa priorizar quem é atendido primeiro.

Não posso deixar de sentir que toda essa discussão é um pouco como uma câmara de eco e que aqueles que defendem a falta de um compilador descobririam que seu tempo seria mais bem gasto falando com as pessoas na cara do carvão perguntando o que elas realmente querem.

Esse foi o objetivo principal de formar um Grupo da Comunidade W3C. Achamos que foi bem-sucedido, como ouvimos de muitos desenvolvedores interessados. Alguns não estão interessados ​​em MVP, mas estão interessados ​​em recursos futuros .

@jfbastien

Os navegadores já podem executar JavaScript de forma eficiente.

Ha, venho tentando escrever um jogo multiplayer em HTML5 massivo capaz de rodar a um FPS decente em um telefone móvel médio desde 2008 e ainda não estou lá! E visto que quando vou contratando para pagar as contas sou extremamente bem recompensado, tenho quase certeza de que minha falta de progresso não se deve à qualidade do meu código.

Esse foi o ponto principal de formar um Grupo da Comunidade W3C

Ha de novo - quantos desenvolvedores do mundo real você conhece que participam de um grupo da comunidade? Os desenvolvedores que o fazem são tipicamente evangelistas etc. que têm conhecimento, sim, mas sentiram menos a dor dos desenvolvedores da vida real.

E me desculpe, eu realmente não quero menosprezar ninguém nesta página / envolvido / no W3C. Como você disse, esta é uma discussão, e este é o meu ponto de vista da linha de frente.

Peço desculpas por ter voltado a isso como um cachorro preocupando-se com um osso, mas enquanto estava fora, pensei em uma maneira melhor de apresentar meu ponto de vista. Em seu próximo boletim informativo / evento comunitário ou qualquer outro meio que você tenha para obter feedback, faça esta pergunta aos desenvolvedores da web (seus clientes):

Para levar o desempenho baseado em navegador para o próximo nível, você precisará aprender outro idioma; isso seria aceitável?

Porque essa é basicamente a pergunta que já foi (na minha opinião, deletéria) respondida por alguns nesta página.

E finalmente (eu prometo ;-)) @jfbastien , se:

Para piorar, o WebAssembly tem aspirações não relacionadas à web.

por que é chamado de "WebAssembly"?

@BossLevel Acho que sei de onde você está vindo. Não posso falar pelas pessoas que fazem a evangelização, mas meu entendimento é que diferentes evangelistas estiveram em contato com desenvolvedores "nativos" tradicionais que estão interessados ​​no WebAssembly. Do seu ponto de vista, isso pode não ser aparente, mas, no mínimo, posso apontar o interesse do Unity como um sinal de desenvolvedores "sérios". Essas pessoas também postam no github com seus próprios nomes, mas as afiliações nem sempre são aparentes. Não é minha função falar por eles.

Ha, venho tentando escrever um jogo multiplayer em HTML5 massivo capaz de rodar a um FPS decente em um telefone móvel médio desde 2008 e ainda não estou lá! E visto que quando vou contratando para pagar as contas sou extremamente bem recompensado, tenho quase certeza de que minha falta de progresso não se deve à qualidade do meu código.

Não quis dizer que escrever JavaScript rápido é fácil. O que eu queria dizer é: WebAssembly não torna a otimização do JavaScript mais fácil. Em vez disso, permite que os navegadores consumam um formato mais adequado para gerar um desempenho confiável. Também permite que o TC39 se concentre em melhorar o próprio JavaScript, não apenas o JavaScript como um alvo de compilação.

Ha de novo - quantos desenvolvedores do mundo real você conhece que participam de um grupo da comunidade? Os desenvolvedores que o fazem são tipicamente evangelistas etc. que têm conhecimento, sim, mas sentiram menos a dor dos desenvolvedores da vida real.

E me desculpe, eu realmente não quero menosprezar ninguém nesta página / envolvido / no W3C. Como você disse, esta é uma discussão, e este é o meu ponto de vista da linha de frente.

Seu ponto de vista é realmente válido, e acho que está claro que, de onde você está, estou dizendo algo difícil de acreditar. Devemos comunicar isso melhor (ou ei, talvez eu esteja errado: piscadela :).

Para levar o desempenho baseado em navegador para o próximo nível, você precisará aprender outro idioma; isso seria aceitável?

Porque essa é basicamente a pergunta que já foi (na minha opinião, deletéria) respondida por alguns nesta página.

Vejo sua preocupação, mas espero que não seja verdade. Novamente, posso estar errado. A meu ver, o WebAssembly traz novos desenvolvedores para esta plataforma, desenvolvedores que tiveram experiências ruins com a Web no passado ou ouviram histórias de terror. Por sua vez, ajuda os desenvolvedores de JavaScript que desejam usar código "tradicional" (o que alguns chamam de "legado") a usar esse código: queremos que o WebAssembly seja facilmente utilizável em JavaScript. Para conseguir isso, ele precisa ser tão fácil quanto usar npm (o que ... nem sempre é fácil!).

Estou um tanto confiante de que isso vai acabar por causa do feedback que temos visto no Twitter, Hacker News, Reddit e várias conferências. Novamente, talvez eu esteja errado e estou ouvindo câmaras de eco. No mínimo, tive discussões muito promissoras em conferências com pessoas com experiência em C ++ e JavaScript.

Ao mesmo tempo, TC39 está realmente tentando melhorar o JavaScript. Acredito que sim nos últimos anos, principalmente com o ES6.

Mas seu ponto permanece: talvez os desenvolvedores queiram ser bem versados ​​em JavaScript , bem como em linguagens mais "amigáveis ​​para WebAssembly", como C ++ ou Rust. Não sei para que lado as coisas vão.

por que é chamado de "WebAssembly"?

Ha! Essa é uma pergunta maravilhosa. Tenho uma palestra intitulada "WebAssembly: nem Web nem Assembly". Terei que dar isso publicamente para que possa expressar como me sinto sobre o nome: sorriso:

Então vou mantê-lo esperando por isso.

Estou lendo dois desejos aqui:

1. Uma representação binária do JavaScript padrão para tempos de carregamento rápidos.
2. Algo para preencher a lacuna de desempenho entre C ++ compilado nativamente e JavaScript padrão.

O item 2 é objeto de pesquisas contínuas e de investimentos massivos por parte de muitas empresas. Se você observar as medições de desempenho dos mecanismos JavaScript nos últimos 15 anos, também está funcionando ... a diferença está ficando menor.

O item 1 não está sendo trabalhado por ninguém, pelo que eu sei. É extremamente complicado e fica cada vez mais difícil à medida que o JavaScript continua a evoluir em um ritmo rápido. WebAssembly é muito rígido e relativamente simples, e ainda levou anos para ser desenvolvido.

@jfbastien - muito obrigado por sua resposta considerada e atenciosa :)

Portanto, alguns pontos ilustrativos, sem uma ordem específica:

1) Um bom exemplo que vejo de toda essa discussão e minha visão sobre a direção que você deve seguir é o NodeJS - uma API JS / front-end para um back-end C ++ - você obtém facilidade de uso / familiaridade, etc. por um lado e a velocidade por outro.
2) Sticking with Node, em 2008, quando embarquei em minha própria odisséia pessoal ;-) Originalmente, olhei para PHP e Java como back-end (eu estava voltando ao desenvolvimento após uma década no lado negro do gerenciamento de TI e vendas ;-)!), mas rapidamente os descontou pela simples razão de que eu só queria ter que aprender um idioma, e aprender bem esse! Conheço uma história pessoal, mas duvido que seja o único desenvolvedor que se sente assim, principalmente aqueles que trabalham por conta própria, e não por um centavo da empresa enquanto aprendem o idioma.
3) Deliberadamente, não pesquisei os números antes de fazer meu próximo argumento (na verdade, não tenho certeza se conseguiria), mas estou disposto a apostar que a aceitação do ASM foi baixa. Eu sei que fiquei muito animado quando vi a demonstração inicial, mas ao saber que não havia nenhum compilador, imediatamente o descartei. Pedir a um desenvolvedor da web que faz parte da maior comunidade de desenvolvimento do planeta (JS), com uma vasta gama de APIs, bibliotecas, recursos, tutoriais, estruturas etc. disponíveis online para se afastar disso, é pedir demais, e por não fornecer a eles um meio de potencialmente dar o primeiro passo (ou seja, um compilador) está faltando um truque óbvio de sua parte. Eu até chegaria ao ponto de apostar que o desenvolvimento em Shading langage (GLSL) teve mais crescimento do que ASM agora que você pode a) escrevê-lo diretamente em excelentes estruturas como Pixi.js e Three.js eb) brincar com ele diretamente em sites como o ShaderToy .
4) A indústria de jogos / jogos em geral. Posso falar por experiência própria aqui como a) Tenho escrito jogos (ainda não lançados!) Nos últimos 9 anos eb) Servi no conselho da TIGA (a associação comercial para os desenvolvedores de jogos do Reino Unido) por 2 anos. Acredite em mim, acho que o número de desenvolvedores de jogos que queriam migrar para a web provavelmente poderia ser contado em uma mão - os desenvolvedores de jogos já estão na indústria que amam e até mesmo tendo um pagamento / trabalhando muitas horas apesar disso, então estes não deve ser o público-alvo da WA. Sim, seus empregadores estão sempre procurando por novos meios para portar seus jogos, mas não vamos nos enganar, excluindo o celular (onde o código nativo infelizmente vence e que é o que eu quero que o WASM conserte), a web ainda é muito relação ruim com o PC / console em termos de desempenho e monetização.
5) Por outro lado, embora a cena do programador / indie não esteja no auge como estava há alguns anos, há um grande número de desenvolvedores da web que desejam fazer um jogo da web em seu tempo livre. E embora eu não queira entrar abertamente na política e não estou de forma alguma criticando os caras da Unity (já negociei com vários deles e é um ótimo produto), pessoalmente acho que você deveria cuidar dos interesses dos vários pequenos rapazes, não o único grandão (faz sentido filosófico e comercial).

Estou muito ansioso para ver sua palestra @jfbastien :)

@RyanLamansky - Acho que você faz uma distinção razoável. Em relação a:

O item 1 não está sendo trabalhado por ninguém, pelo que eu sei. É extremamente complicado e fica cada vez mais difícil à medida que o JavaScript continua a evoluir em um ritmo rápido.

Em um nível totalmente pessoal, como alguém que escreve JS 8 horas por dia desde 2008, gostaria muito de ver a evolução do JS apenas parar um pouco e deixar que todos os outros me atualizassem! Sempre trabalhei com o princípio de desenvolver para o menor denominador comum, ou seja, se não tiver 100% de suporte, não está acontecendo (IE6 / 7/8/9 à parte ;-)). E assim nos encontramos na posição ridícula de nos concentrarmos nos padrões ES6 da moda e supostos casos de uso quando ainda não temos 100% de suporte do navegador para ES5 em desktops e dispositivos móveis. A linguagem funciona claramente como está (apesar de suas fraquezas admitidas), conforme demonstrado por sua participação no mercado, então que tal nós, como uma comunidade de desenvolvedores, passarmos os próximos anos aprendendo a escrever um código eficiente e ideal com o que temos, em vez de mais uma vez reinventando a roda com um novo código hipster (desculpe, estou entrando em um território de discurso retórico ;-))?

Acho que provavelmente é hora de pegar meu casaco ;-)

@RyanLamansky Eu tive a impressão de que o WebAssembly será apenas um novo alvo para o seu processo de construção de bundle e, de repente, tudo ficará mais rápido. Claramente, não é o caso. O WebAssembly tem um caso de uso de destino muito específico e provavelmente não terá muito a oferecer ao desenvolvedor da Web típico com uma grande base de código JS cheia de lógica de negócios.

Mas, como você notou, existem algumas lacunas no ciclo de vida de desenvolvimento baseado em JS para aplicativos da web orientados para negócios mais típicos:
1) Grandes pacotes JS têm uma sobrecarga de análise significativa e geralmente fornecem ofuscação insuficiente.
2) O código JS padrão não possui as anotações de tipo (e talvez outras dicas) necessárias para fazer otimizações de código JIT / nativo.

Isso sugere que uma possível solução é uma versão devidamente digitada e anotada de JS que fornece ao desenvolvedor caminhos de otimização mais determinísticos e transparentes e uma versão binária pré-analisada dessa versão da linguagem.

Os comentários e os documentos dizem que o WASM é executado além do JS e usa o mesmo mecanismo JS dos navegadores (otimizado). https://developer.mozilla.org/en-US/docs/WebAssembly

Eu realmente não entendo essa pergunta.

Desculpe por fazer uma pergunta idiota e um comentário idiota: a pergunta e o comentário da equipe de montagem da Web significam que Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? vejo apenas pensamentos subjetivos. Alguém pode explicar isso? Se o Webasembly é mais rápido que o Javascript, por que não fornecer um transpiler? Se o Javascript não é possível, por que não o código ES7 / TS? Por que existe tanto sigilo em torno disso?

@ganeshkbhat O lançamento inicial do WASM é pouco mais do que uma codificação binária compacta de asm.js, que é um subconjunto muito restrito de JavaScript. Ele não é executado mais rápido do que o asm.js, a menos que inteiros de 64 bits sejam usados, pois eles devem ser emulados no asm.js.

Existem propostas para adicionar recursos ao WASM que o aproximariam do JavaScript em termos de capacidade (coleta de lixo, integração DOM, encadeamentos), mas não há planos para adicionar o conjunto completo de recursos JavaScript. Portanto, é provável que um transpiler JS-> WASM nunca exista. Em vez disso, novos aplicativos e bibliotecas serão criados para funcionar dentro das limitações do WASM. Hoje, isso é C e C ++, onde as restrições de linguagem se alinham bem com WASM e asm.js.

Não há segredo nem magia. Wasm é "mais rápido que o JavaScript" porque é uma linguagem muito mais simples e muito mais próxima do hardware. JavaScript é uma linguagem complicada que tem que fazer muitas coisas caras durante a execução. Ele não ficaria mais rápido magicamente compilando-o em código nativo por meio do Wasm em vez de diretamente.

@ganeshkbhat atualmente, não é possível alocar objetos dentro de asm.js / webassembly. Em asm.js e webassembly, todas as operações JavaScript usarão um grande typedarray para armazenar e carregar seus valores. A criação de objetos JavaScript (por exemplo, var obj = {a: 1, b: 'test'} ) e matrizes (por exemplo, var a = []; ) não é possível dentro do webassembly, pois ainda não há suporte a objetos. Esta é uma decisão de design do Produto Mínimo Viável, feita para obter suporte de montagem na web em todos os principais navegadores o mais rápido possível.

Em uma versão futura, o suporte de GC está planejado para montagem na web. Nós (desenvolvedores do LeaningTech.com ) estamos trabalhando em uma proposta de suporte a objetos em webassembly, mas isso levará algum tempo para chegar como uma especificação e uma implementação em todos os principais navegadores. Até então, não é possível transpilar JavaScript (e CoffeeScript, TypeScript, etc.) para webassembly. Quando a proposta for aceita, deve ser possível transpilar um subconjunto maior de JavaScript , mas não oferecerá suporte a todos os recursos disponíveis atualmente.

Certo. Aguarde um melhor suporte para JS aqui. Eu definitivamente sinto que pode ser suportado. Escrever um transpiler é o que pode ser necessário para as linguagens de suporte de tipo.

Pelo que li sobre webassembly, ele visa principalmente navegadores da web e, nessa área, não parece muito atraente ter o compilador js -> webassembly. Mas posso imaginar a execução de webassembly em ambientes sem navegador. Isso não é totalmente verdade, pois também pode ser executado em nodejs, mas vejo seu verdadeiro potencial em ambientes nodejs em algo como vertx - polyglot permitindo a execução de módulos escritos em qualquer linguagem, que podem ser compilados para webassembly. Posso imaginar que será extremamente difícil fazer algo assim. Exigirá muitos recursos como GC, talvez até algum tipo de VM para ser implementado, mas nada é impossível. Lembre-se de que muitas pessoas também eram céticas em relação ao asm.js e olhe para ele hoje.

Para todos aqueles que estão entusiasmados (como eu) com a compilação de js -> webassembly, pode haver um caminho indireto e muito acidentado por meio de js -> c -> webassembly usando o transpiler do projeto

@ mauron85 Ambientes de tempo de execução sem navegador e sem JavaScript são definitivamente uma consideração do design, mas apenas a API JS existe hoje.

De minha parte, tenho experimentado um sistema .NET JIT e não vejo nenhuma barreira real além do tempo, e tenho certeza de que há outros procurando integrar o WASM em suas plataformas favoritas também. Tenho certeza de que daqui a alguns anos haverá tempos de execução não JavaScript de alta qualidade para WebAssembly. A única questão em aberto é até que ponto eles serão formalmente endossados ​​pela equipe WebAssembly.

IMO, um benefício da capacidade de compilação JavaScript -> WebAssembly é que os desenvolvedores / mantenedores das bibliotecas e ferramentas Javascript provavelmente seriam capazes de lançar suas APIs em dois formatos:

1. em JS (como está agora) que os usuários podem usar para navegadores e nó
2. WASM como a biblioteca compilada que pode ser mais eficiente.

E isso sem a necessidade de reescrever o código JS existente em C / C ++, se quiserem liberar os benefícios de desempenho do WASM em suas bibliotecas JS.
Portanto, os desenvolvedores da biblioteca ainda seriam capazes de desenvolver e manter em Javascript e produzir duas saídas para dois destinos diferentes, ambos em JS e WASM.

E usar a biblioteca de versão WASM compilada seria definitivamente mais eficiente para os usuários, pois tudo o que eles precisam fazer é usar a API exposta da biblioteca e eles obviamente não se importarão se ela está escrita em WASM ou não. Mas o desempenho certamente seria melhorado.

WASM como a biblioteca compilada que pode ser mais eficiente

Porque? Por que um blob de javascript transpilou web assembly (pior cenário, incluindo muito do tempo de execução para um mecanismo javascript naquele binário; melhor cenário, incluindo uma camada construída sobre o futuro wasm GC integrado, que incorre em sua própria sobrecarga de qualquer maneira ) executar mais rápido do que o javascript lançado em um jit dedicado a ... executar o javascript?

Ok, você quer dizer que seria ainda mais lento com mais sobrecarga?

Talvez haja algo que não tenha entendido bem. Como C/C++/Rust -> WebAssembly coisas compiladas são realmente eficientes e mesmo se houver um suporte para JS -> WASM no futuro que causaria sobrecarga? Isso é apenas porque JS é uma linguagem dinâmica e C, C ++ e Rust não são? Ou é porque JS não é, por natureza, uma linguagem totalmente compilada, mas essas outras linguagens são?

Eu acho que é improvável que a compilação de JS para WASM aumente o desempenho sustentado; no entanto, pode melhorar o tamanho do código e o tempo de análise devido à codificação binária, que ainda é útil.

Acho que podemos apenas definir uma codificação binária para JS e ignorar a memória linear etc. por enquanto. Isso é simples e polyfillable.

@kabirbaidhya O principal problema com JS -> WASM agora é que você não pode construir um coletor de lixo eficiente dentro dele, pois não há como analisar a pilha para ver quais objetos estão vivos. Isso significa que você teria que colocar uma cópia de todas as referências de objeto na memória linear (o heap) e mantê-la sincronizada, degradando seriamente o desempenho. Ele também não possui multi-threading de memória compartilhada, portanto, a coleta de lixo em segundo plano é impossível. Versões futuras do WASM serão capazes de acessar o mecanismo de coleta de lixo do navegador host, eliminando esse problema.

A outra grande barreira para JS -> WASM é o fato de que quase todos os objetos são totalmente dinâmicos. O WASM espera intrinsecamente que tudo seja puramente estático, portanto, camadas de mapeamento complexas, emulação e geração de código dinâmico seriam necessárias para se aproximar do desempenho JS padrão. Felizmente, o TypeScript ajuda com isso, portanto, um subconjunto estrito do TypeScript pode ser capaz de direcionar o WASM até certo ponto. Eu sei que há pelo menos uma pessoa tentando construir isso.

C / C ++ funciona bem com o primeiro lançamento do WASM devido ao fato de que as limitações do WASM estão estreitamente alinhadas com as limitações do hardware nativo, que o C / C ++ foi projetado para atingir.

FWIW, há um ótimo controle deslizante sobre como o V8 lida com a aritmética do JavaScript: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr este é apenas _um_ exemplo onde a realidade é muito mais difícil do que pode parecer e na prática não é muito significativo, já que a VM nativa pode (e provavelmente fará) um trabalho melhor e mais rápido, pois é verdadeiramente nativa e tem acesso a recursos e APIs nunca serão - e (provavelmente) o mais importante, anos de iteração.

Isso não quer dizer que um _subconjunto_ de JS / TypeScript não pudesse proliferar com sucesso, como ThinScript , TurboScript , etc. Eles parecerão muito familiares para programadores de JS à primeira vista.

Ainda acho que essas são boas perguntas e continuo perguntando. É fundamental que todos entendamos os casos de uso e o futuro do WebAssembly - bem como os objetivos não definidos.

Em 6 de abril de 2017 às 00h36, Ryan Lamansky [email protected] escreveu:

A outra grande barreira para JS -> WASM é o fato de que quase todos os objetos
são totalmente dinâmicos. WASM intrinsecamente espera que tudo seja puramente
camadas de mapeamento estáticas, tão complexas, emulação e geração de código dinâmico
seria necessário para se aproximar do desempenho JS padrão. Felizmente,
TypeScript ajuda com isso, então um subconjunto estrito de TypeScript pode ser capaz de
almeje WASM em algum grau. Eu sei que há pelo menos uma pessoa tentando
construir isso.

Infelizmente, duvido que o TypeScript ajude nesse sentido. Para abranger
JS legado, seu sistema de tipos é tão profunda e fundamentalmente doentio que
não existe um subconjunto "estrito" interessante. Por exemplo, tal subconjunto seria
precisa excluir qualquer noção de subtipagem do TS, o que o tornaria bonito
muito inútil em seu domínio.

Tem havido bons trabalhos de pesquisa, como, por exemplo, em SafeTypeScript, mas não
só são mais restritos, eles também exigem quantidades substanciais de
contabilidade e verificações de tempo de execução adicionais dispendiosas, anulando o propósito de
a discussão (e efetivamente sendo uma linguagem diferente de JS / TS).

Talvez eu não esteja recebendo algo, mas uma das ideias do WebAssembly é carregar o AST diretamente para evitar o tempo de análise de js, certo?

Portanto, se tivermos uma ferramenta que compila js para esse formato ast e o transmita para o navegador, ela não se beneficiará em evitar o tempo de análise?

@agnivade , é um AST para uma linguagem completamente diferente, muito mais de baixo nível.

Se você fosse compilar JS para Wasm offline, então sim, você não precisaria analisar no lado do cliente (apenas decodificar). Ao mesmo tempo, como JS é tão complicado, o tamanho do código aumentaria drasticamente, provavelmente por um fator de 5 ou mais, o que é um custo muito mais alto. (E isso nem mesmo leva em consideração que você provavelmente também precisaria incluir uma implementação inteira de um sistema de tempo de execução JS VM no Wasm, que facilmente tem megabytes de código.)

Além disso, sem uma representação das fontes, você não pode implementar a maioria das otimizações dinâmicas que são cruciais para obter JS em qualquer lugar perto de rápido. Essas otimizações contam com a recompilação do código-fonte original e a especialização dele com base nas informações de perfil. Um Wasm AST já compilado não permite isso, você precisa de um AST do programa de origem original.

@rossberg-chromium - Muito obrigado. Isso esclarece muito! Uma dúvida, porém -

E isso nem mesmo leva em consideração que você provavelmente também precisaria incluir uma implementação inteira de um sistema de tempo de execução JS VM no Wasm, que facilmente é megabytes de código

Por que você precisa do sistema de tempo de execução VM? Não é o próprio navegador o tempo de execução da VM? Só quero que o código esteja no formato AST para que o navegador possa começar a executá-lo imediatamente. Eu entendo que o tamanho da rede aumentará porque a linguagem em si é complexa e não podemos implementar otimizações dinâmicas. Mas por que precisamos empacotar o próprio tempo de execução da VM, quando temos o navegador para isso?

@agnivade , sem otimizações dinâmicas JavaScript ficará lento, e quero dizer _realmente_ lento, como 100x mais lento, talvez pior.

Por "tempo de execução" não quero dizer coisas do navegador como o DOM, mas o suporte à linguagem JS, ou seja, coisas como coletor de lixo, representações de objeto, primitivas e bibliotecas de base, etc. Isso é muito grande para JavaScript, e você precisa de uma reimplementação de tudo isso dentro do Wasm.

E, claro, você também precisaria de uma camada de interface para o DOM.

Ok, acho que entendo um pouco melhor as coisas agora. Eu pensei que o

coletor de lixo, representações de objetos, primitivas e bibliotecas de base, etc.

pode ser usado no próprio navegador. E posso simplesmente deixar o navegador carregar o AST e fazer seu trabalho normal. Mas agora eu percebo que tudo precisa ser empacotado dentro do próprio WASM.

Um bytecode de linguagem de script universal seria interessante! Um alvo de compilação projetado para transportar e executar com eficiência programas escritos em linguagens com tipos dinâmicos e coleta de lixo, com todos os casos extremos bizarros dos populares (javascript, ruby, python, lua) cobertos em (alguns casos) códigos de operação e estruturas especiais, etc.

@distransient , então você deseja a insanidade combinatória de todas as linguagens de script? Estou otimista de que seria possível para a humanidade reunir os recursos de engenharia para especificar e implementar isso de forma eficiente até 2050. :)

Aqueles que estão interessados ​​em compilar TypeScript para WebAssembly usando LLVM. confira este projeto de alcance. https://github.com/MichaReiser/speedy.js
Parece que essa discussão não acaba nunca ...

@rossberg-chromium eu disse que seria "interessante", nem fácil nem bonito 😉

Um bytecode de linguagem de script universal seria interessante ...

Enquanto o WASM está evoluindo de forma incremental para eventualmente suportar coisas como Python, poderíamos ter suporte de primeira classe para o desenvolvimento de linguagens de script para a Web muito mais cedo do que o WASM pode fornecer, se abordássemos o problema da extremidade oposta ao mesmo tempo.

Deve ser relativamente simples para os mecanismos JavaScript expor sua capacidade de executar ASTs JavaScript, e os ASTs que eles aceitaram podem ser padronizados (mesmo se forem imediatamente convertidos para um formato intermediário não padrão internamente).

Poderíamos simplesmente combinar um formato AST (como estree ) e um formato de serialização (como JSON) para criar um novo formato de arquivo com uma nova extensão. Se os navegadores suportassem o formato em tags de script e assim por diante, linguagens como TypeScript e CoffeeScript seriam apenas compiladas para analisar árvores, e o navegador faria isso de lá. As linguagens transpiladas não precisariam gerar a geração de código e os mapas de origem também não seriam mais necessários, pois a informação lexical seria baseada na fonte real.

Uma vez que o suporte básico foi estabelecido, o padrão poderia evoluir incrementalmente para atender ao WASM no meio, basicamente apenas adicionando novos tipos de nós. Existem coisas simples para começar, como add e nós concat explícitos, ou talvez adicionar novos tipos de dados, como DEC64.

À medida que WASM se desenvolve para suportar linguagens de script, adicionando coisas como GC, a execução de AST se moveria para baixo, estendendo a semântica de JavaScript para incluir recursos de outras linguagens de alto nível, de forma que um conjunto mais amplo de linguagens de script pudesse ser compilado para um tipo de JavaScript abstrato .

Em 25 de maio de 2017 às 02:57, Carl Smith [email protected] escreveu:
>

Existem alguns problemas que precisam ser resolvidos, mas seria
relativamente simples para os motores de JavaScript exporem seu suporte interno
para executar ASTs JavaScript, e as ASTs que eles aceitam devem ser
padronizado (mesmo se o AST for imediatamente convertido em não padrão,
formatos intermediários internamente).

Apenas para uma definição muito mais ampla de "relativamente simples" do que você provavelmente
tem em mente... ;)

Em relação ao WASM, é simples.

@bguiz Por exemplo:

• Você não pode traduzir JS nativamente para ASM, porque ele tem uma arquitetura diferente.
• Você não pode manipular o DOM do ASM, porque você não tem acesso aos seus recursos no nível do solo da CPU.

O motor Google V8 já compila o JavaScript diretamente para o código de máquina nativo, compilando toda a tarefa de tempo de execução, antes de executá-la.

Portanto, seria totalmente desnecessário ter um pipeline WASM alternativo do lado do cliente.

Por outro lado, WASM foi apresentado com um demo de Mandelbrot, então ele apresenta o demo Unity "Tanks" em primeiro lugar, mas eu duvido muito que desenhar pixels com ASM-> CPU (mesmo com SSE dupla precisão) poderia ser mais rápido do que WebGL-> GPU, porque como diz essa comunidade a GPU não está no escopo. E daí?

@ivanherczeg Woah! Onde esta comunidade diz que a GPU não está nas especificações?

@SephReed

Já temos tensões devido a diferenças entre o braço e o x86. Acho que adicionar outro conjunto de destinos de hardware criaria mais tensão: mais operações teriam que ser lentas devido aos custos de emulação para obter semântica uniforme em todos os destinos, ou mais operações teriam que ter um comportamento indefinido para permitir que todos executassem rapidamente. Acho que isso torna não lucrativo considerar a GPU neste momento (ou nunca).

-Fil

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

O tempo de execução do C # foi portado para o wasm e era um protótipo totalmente funcional substituindo o JS completamente. Portanto, isso significa que, no futuro, você pode esperar tempos de execução emergentes para substituir JS em navegadores e escrever aplicativos da web do lado do cliente em Java, C # ou mesmo C ++ com uma declaração dizendo "O código será executado mais rápido perto do nativo" , "O código compilado é mais rápido que a VM" ou qualquer coisa sem a ajuda de JavaScript.

Por favor, assista a este vídeo do que estou tentando dizer.

O WebASM foi introduzido para complementar o JS para não assumir o controle completamente, substituindo a linguagem de primeira classe.

Em um futuro próximo, você pode esperar que as páginas da web sejam entregues a partir de um servidor compilado nativamente

https://github.com/ballercat/walt

@Steakeye Muito bom :) Vou fazer uma peça - muito obrigado por destacar :)

você pode compilar JS para WebAssembly usando NectarJS. Demonstração: http://nectar-lang.com/ escolha no menu suspenso WebAssembly

Interessante, a demonstração do NectarJS usa emscripten, você pode ver isso na saída do asm.js. Parece que compila JS estaticamente em algo - provavelmente C ou IR LLVM - e então executa isso por meio de emscripten.

A saída do wasm também usa emscripten (pode ser visto na inspeção do binário), mas parece usar uma versão antiga, pois emite binários 0xd wasm, que não são executados em VMs modernas. Ele também envia apenas o wasm, não o JS, portanto, não pode ser executado de qualquer maneira. Em qualquer caso, é muito possível que ele esteja apenas fazendo o mesmo que para asm.js, apenas executando emscripten com o sinalizador para saída de wasm ativado.

A demonstração tem um limite de 300 bytes na entrada, então é difícil alimentá-la com um programa do mundo real para ter uma ideia de quão poderosa é sua análise, que é a verdadeira questão com uma abordagem estática como essa. Em geral, a pesquisa acadêmica sobre este tópico sugere ceticismo.

Suas demos compiladas para Windows simplesmente travam para mim 🤕

Eu concordo com o ceticismo de @kripken aqui. Acredito que JS arbitrário não pode ser razoavelmente convertido em WebAssembly. Qualquer ferramenta que alega conseguir isso provavelmente está trabalhando em algum subconjunto tratável da linguagem JS ou desistindo do desempenho de execução.

JS é uma linguagem extremamente dinâmica. Operações imprevisíveis em tempo de execução podem alterar significativa e globalmente a semântica do código. Isso significa que um compilador Ahead-Of-Time (ou offline) só pode assumir o pior e gerar um código genérico muito ineficiente que pode lidar com todos os casos possíveis. Para obter um exemplo, pegue o seguinte código JS:

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

poderia ser convertido (em pseudo-wasm) para 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

Agora, isso está muito longe do que podemos razoavelmente considerar "compilar" e é mais semelhante a desenrolar um interpretador. Obviamente, também é possível executar um interpretador JS compilado para Wasm, mas isso dificilmente seria uma vitória de desempenho.

Os mecanismos JS, como V8 e Spidermonkey, podem executar o código JS tão rápido quanto, compilando-o Just-In-Time. Ao fazer a compilação JIT, eles podem observar qual é a semântica real pretendida para um determinado pedaço de JS e gerar código rápido para aquele caso específico, enquanto, é claro, têm o cuidado de detectar qualquer mudança no ambiente que possa invalidar as suposições atuais.

Concordou. Eu não me importaria em usar um subconjunto de JavaScript, no entanto. Ou talvez uma variante digitada, o que provavelmente reduziria o dinamismo e permitiria a geração de um código mais eficiente.

Há alguma notícia sobre o "modo forte", BTW?

@ Simran-B, há muito abandonamos o modo forte, pelas razões resumidas aqui . A conclusão é que é praticamente impossível restringir a semântica do JavaScript sem perder a interoperabilidade com o código existente.

Pelo mesmo motivo, também não tenho muita esperança de projetar um dialeto "estaticamente compilável" de JavaScript ou TypeScript - seria uma linguagem diferente que não pode executar o código existente, então não adianta muito.

@ Simran-B: "No entanto, não me importaria de usar um subconjunto de JavaScript. Ou talvez uma variante digitada"

Há alguns trabalhos muito interessantes nesse espaço, como o AssemblyScript, que é um subconjunto estrito do TypeScript que é compilado para WebAssembly, https://github.com/AssemblyScript/assemblyscript

@rossberg : "Eu também não tenho muita esperança para a ideia de projetar um dialeto" estaticamente compilável "de JavaScript ou TypeScript - seria uma linguagem diferente que não pode executar o código existente, então não adianta muito."

Acho que o grande potencial de coisas como o AssemblyScript não é executar o código existente (concordo com você, isso não será viável em geral), mas que ter uma linguagem amigável e familiar é um grande negócio.

No momento, se você for um desenvolvedor de TypeScript e quiser escrever WebAssembly, precisará usar C ++ ou Rust. Ambos são bons idiomas, mas também têm desvantagens. Para alguém com esse histórico, algo como o AssemblyScript pode ser o caminho mais rápido para a produtividade.

Se o AssemblyScript puder ser compilado tanto para JavaScript quanto para Assembly, isso seria bastante ideal. Ansioso por essas atualizações.

Além disso, no futuro, a menos que alguém faça isso primeiro, provavelmente tentarei escrever um conversor TypeScript -> Assembly Script que analise os arquivos, faça as perguntas que ele precisa fazer e, em seguida, faça a conversão. Espero que funcione!

@SephReed Sim, pode ser compilado para JavaScript, porque existe um compilador WebAssembly -> asm.js , que deve funcionar com todo o código WebAssembly.

Consulte também a seção "Pode WebAssembly ser polyfilled?"

Se, em vez disso, você quisesse dizer "é possível para o AssemblyScript compilar em código JavaScript idiomático ?", Então tenho que perguntar, por que você faria isso quando WebAssembly / asm.js são muito mais rápidos do que o código JavaScript idiomático?

Embora eu suponha que você deva ser capaz de executar o código AssemblyScript por meio do compilador TypeScript. No entanto, você precisará manter certas coisas em mente .

Consulte também esta seção da documentação do AssemblyScript.

Senhores, considerem WALT , a linguagem WebAssembly semelhante ao JavaScript.

UPD. Desculpe por necroposting

Vejo que muitas pessoas consideram este compilador "JS -> WASM" uma boa ideia.

Para quem não acha útil, como:

Não tenho certeza se será útil do ponto de vista de um desenvolvedor, no entanto. Você pode obter alguma redução de tamanho, mas isso é tudo. Do ponto de vista do navegador, pode ser interessante ter o mecanismo JS implementado no wasm de uma perspectiva de segurança pura.

Por favor, aqui está meu exemplo concreto de por que é importante e por que é útil, e não apenas você "consegue alguma redução de tamanho, mas é isso". Um dos recursos que acompanham o WebAssembly é:

<= XXX « EnViRoNmEnT SaNdBoXeD » XXX =>

WebAssembly não trata apenas de desempenho. Você pode ver um bom artigo sobre plug-ins da equipe Figma .

Fazer um sistema de plugins é bastante desafiador. Você precisa de uma boa maneira de executar o código personalizado. Você precisa de um ambiente separado, seguro.

O WebAssembly oferece isso - um ambiente puro sem bagunça como algumas variáveis ​​globais. O AssemblyScript o torna conveniente de certa forma - você tem quase o mesmo ambiente TypeScript que o ambiente do seu aplicativo principal, o que é muito legal.

Mas aqui está o problema, "quase o mesmo":

Posso usar pacotes JS do NPM em meu ambiente seguro?

Não.

Bem, este projeto WALT é algum tipo de alternativa ao AssemblyScript. É quase como o JS, - é digitado como js. É mais parecido com o TS. Você não pode compilar / transpilar bibliotecas js existentes com isso.

Posso usar pacotes TS do NPM em meu ambiente seguro?

Não.

AssemblyScript também é uma linguagem do tipo TS. Ele pode compilar algo escrito em TS se estiver totalmente coberto com tipos. Sem exceções. Nenhum any 's. Mas muitas vezes as pessoas têm suas configurações não estritas o suficiente ou têm alguns @ts-ignore , ou ainda mais frequentemente, - eles escrevem pacotes em js e fornecem tipos separados em arquivos .d.ts - em todos esses casos, você não será capaz de compilar tal pacote para WASM.

@JerryGreen pontos positivos, mas no lado do desempenho das coisas, eu realmente acredito que é um grande equívoco que não haja benefícios de desempenho significativos além de economizar alguns bytes. As pessoas, incluindo benchmarks, são tão obcecadas com o desempenho do tempo de execução. Veja como ele executa jogos 3D rápido?

No entanto, a oportunidade do mundo real está, na verdade, no desempenho de inicialização , o que beneficia praticamente todos os sites. Poucos parecem falar sobre como o WebAssembly é substancialmente mais rápido no tempo de inicialização (por byte), muito além de quaisquer benefícios de tempo de execução. É por isso que, por exemplo, gzip em conteúdo textual, como JavaScript, tem pouco impacto no mundo real sobre PLT - é o tamanho do código compilado que importa.

Ironicamente, a indústria é obcecada por PLT (Page Load Times) e vários marcadores visuais completos, mas ninguém vê a correlação entre WebAssembly e esses vetores. O JavaScript é responsável por mais de 30% do tempo gasto antes desses eventos críticos, na maioria dos sites. Na verdade, o tamanho das páginas e a largura de banda têm muito menos impacto sobre os PLTs em comparação com os fatores de desempenho linear, ou seja, tempos de inicialização e latência do JavaScript.

Dito isso, não está claro para mim a viabilidade do JS -> WebAssembly.

@JerryGreen A abordagem do Figma é um caso muito específico e eu acho que para a maioria dos projetos, iframes ou reinos são bonitos o suficiente para o isolamento de javascript de terceiros. Para casos especiais em que o isolamento deve ser mais controlado e o desempenho, o tamanho e o tempo de carregamento não são tão importantes, você sempre pode compilar QuickJS ou JavaScriptCore para WebAssembly.

Você também pode usar Web Workers e executar o código antes do código não confiável que exclui quaisquer APIs às quais você não deseja que o código não confiável tenha acesso. Não há necessidade de WASM neste caso @JerryGreen!

Framerate cai em três js em uma coisa real, eu não tenho certeza se wasm poderia ajudar, mas com certeza parece que sim, pelo menos na superfície.

Não há razão para compilar JS para wasm porque você também teria que incluir um javascript vm inteiro. O código resultante seria enorme e mais lento do que o JS VM fornecido nativamente.

Não poderíamos fazer toda a monomorfização etc. que é feita por JS VMs por meio da Otimização guiada por

Uma construção PGO consiste em duas etapas: uma primeira passagem para construir binários instrumentados, depois uma segunda passagem para reconstruir binários otimizados usando informações de perfil obtidas na execução de binários instrumentados.

A primeira execução nos forneceria todas as informações de tipo (quais funções são chamadas com quais argumentos digitados etc.), então construímos um binário otimizado com todas as variantes com as quais uma função é chamada (+ um genérico com argumentos dinâmicos para código sem perfil) . Não precisaríamos de todo o JS VM.

O PGO exigiu uma cobertura excelente do teste do seu programa. Nem sempre é possível. Mas você pode rastrear algumas informações de tipo durante a execução na v8. Veja este documento: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading = h.xgjl2srtytjt

Falamos com a equipe do TypeScript sobre essa possibilidade e eles mostraram interesse, mas parece que há progresso atualmente bloqueado na adição de objetos digitados em JS.

Não precisa de tipos

O QuickJS pode realmente ser compilado para WASM?

Sim, a Figma usa QuickJS para seu sistema de plugins, por exemplo

E também é usado em http://numcalc.com/ .