Design: JS-> WASMコンパイラはありますか？

ブラウザには、wasmと一緒にネイティブJavaScriptVMが引き続きあります。 javascript vm全体も含める必要があるため、JSをwasmにコンパイルする理由はありません。 結果として得られるコードは、JSVMがネイティブに提供するものよりも巨大で低速になります。

スクリプト言語をwasmに実装できるように、wasmコードからGCへのアクセスを追加するなどを追加するためのタスクポストMVPがあります。

JS→wasmは、wasmがGCをサポートし、おそらくJITコンパイルもサポートするようになった場合にのみ、実際に意味をなします。 これは基本的に、wasmでJSエンジンを実装することと同じです。 私は最近これについて言及し、 @ BrendanEichは私が

明確にするために、wasmの目標はJavaScriptを_置き換える_ことではなく、それを補足することです。 したがって、現時点ではJS→wasmをサポートすることは実際には目標ではありませんが、実装したい機能によってそれが可能になります。 ただし、開発者の観点からはそれほど役立つかどうかはわかりません。 サイズがいくらか縮小されるかもしれませんが、それだけです。 ブラウザの観点からは、純粋なセキュリティの観点からJSエンジンをwasmに実装することは興味深いかもしれません。

@jfbastien私は2秒であなたを打ち負かしました;）

しかし、あなたの答えはより良いです。 私はwasmのGCとJITに興奮しています。 私は自分の言語を作成し、それらをWeb上で実行するのが大好きです。

そして、asm.jsやTypeScript / ES7などのバリアントをサポートするのはどうですか？ これらは
Javascriptのフレーバーは、ある程度の型保証を約束します。

JITの必要性は少ないと思いますが、GCはまだ非常に多いです
これらの言語に必要です。 {タイプされたフレーバーJS}-> WASMが作る
これはもう実現可能ですか？

W： http ：

9時44分に2015年6月24日、ティム・キャスウェルの[email protected]は書きました：

@jfbastien https://github.com/jfbastienあなたは2秒で私を打ち負かしました：P

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/WebAssembly/design/issues/219#issuecomment-114675456 。

はい、asm.js-> wasmトランスレータは優先度が高く、Lukeはすでにそうしました
良い出発点として役立つかもしれないコンプレッサーで作業します。

1：59 AMで水曜日、2015年6月24日には、ブレンダン・グレーツ[email protected]
書きました：

そして、asm.jsやTypeScript / ES7などのバリアントをサポートするのはどうですか？ これらは
Javascriptのフレーバーは、ある程度の型保証を約束します。

JITの必要性は少ないと思いますが、GCはまだ非常に多いです
これらの言語に必要です。 {タイプされたフレーバーJS}-> WASMが作る
これはもう実現可能ですか？

W： http ：

9時44分に2015年6月24日、ティム・キャスウェルの[email protected]は書きました：

@jfbastien https://github.com/jfbastienあなたは2秒で私を打ち負かしました：P

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/WebAssembly/design/issues/219#issuecomment-114677789 。

TypeScriptチームとこの可能性について話し合い、彼らは関心を示しましたが、現在、型付きオブジェクトをJSに追加することについては進展が見られないようです。

@bguiz ：JSエンジンはwasmエンジンであり、進化するJS標準言語を引き続きサポートします。 そこには心配はありません（それがなくなるかもしれないとあなたが思ったかどうかはわかりませんでした。私が予測できる将来はありません）。 他の人が指摘しているように、OTOHは、GC、JITサポート、およびその他の動的言語機能をJSのファーストクラスのターゲットに進化させるには、時間が必要です。 これらを進化させたとしても、JS / wasmエンジンがJS構文と組み込みを削除して、ダウンロードされたJS-in-wasmVMを優先するのではないかと思います。 我々は見るであろう！

/なれ

asm.jsからWebAssemblyへのトランスレータも、Emscriptenに追加

通常のJSについては、他の人が上記の質問に答えていると思います。

JSの要点はコーディングが簡単で、驚くべきことを実行できます：dhteumeuleuまたはcodepen.io/ge1dootですが、ソースを確認でき、ハッキングも簡単です。

「wasm」は、グーグル、アップル、共同でより多くのゲームや他のアプリを販売する唯一の方法です。 唯一の「進化」は、兄貴のサーバーから直接、「インストールなし」であなたをよりよく制御できるようになることです...私は彼らがまだお互いを食べることを恐れていないことに驚いています...

コード分​​析またはコード注釈を使用して、ECMAScriptをWebAssemblyにコンパイルすることができます。 これはWebAssemblyチームの優先事項のようには聞こえませんが、独立した取り組みのための素晴らしいアイデアのように聞こえます。

関連する可能性のあるおもちゃのプログラミング言語の実験を始めたところです： https ：

ただし、一般的に、wasmの上に非常に薄いラッパーを使用することについて人々に警告します。 一例として、thinscriptコードをざっと見てみると、 whileステートメントがloop { if (!condition) break; }に下げられていることがわかります。これは、いくつかのwasmエンジンのif (condition) loop { ...; br_if condition }よりも効率が低くなります。

私にとって、wasmを単なる再加熱されたJS以上のものにするのは、異なる哲学の可能性です。wasmはコンパイラーのターゲットであるため、コンパイラーはコードをクライアントに出荷する前に最適化を実行できるため、クライアント側のVMをよりシンプルに保つことができます。もっと早く。 ただし、wasmの薄いラッパーが一般的になると、実行されていない最適化を実行するために、クライアント側の実装が最終的にはより大きく複雑になるリスクがあります。

はい私は同意する。 WebAssemblyで私が最も気に入っていることの1つは、そのシンプルさです。 言語がより完成したら、コンパイラの最適化を追加し、ベンチマークを実行することを計画しています。 たとえば、インライン化は大きな成果の1つになると思いますが、WebAssemblyがそうすることは期待していません。 また、マシンコードターゲットで実験することも計画しており、両方のターゲットに同じ最適化を使用します。

とてもかっこいいですね！ それがどこにつながるのか興味があります。

JS-> WASMがクライアントよりもサーバーにとって魅力的だと想像しています。 私が念頭に置いているアーキテクチャの非常に高レベルの概要として...

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

この概念では、ガベージコレクションのためにWASMからLLVMIRへの明確なマッピングが非常に望ましいでしょう。 IEEEの倍精度浮動小数点数から整数への昇格は、LLVMパスとして実行できます。 ウォームコードとホットコードの別々のJITの概念は、LLVMパスマネージャーの観点から実装できます。

ちょっと考えてみてください。偽物の場合は、これを削除してください。

相互環境の互換性は、JSエコシステムの深刻な問題です。 Babelは、ESのより採用されたバージョンにトランスパイルすることでこの問題を解決しようとしていますが、かなり成功していると言えます。

ただし、ここにはまだ問題があります。 たとえば、互換性のためにES 2016コードをES5にトランスパイルしていて、コードが（部分的または完全な）ES 2016をサポートする環境で実行された場合、ご使用の環境でES2016をサポートするメリットを逃してしまいます。 。

誰もが自分のコードをES5にトランスパイルしている場合、そもそも環境でES 2016をサポートすることの利点は何ですか？

「babel-preset-env」と呼ばれる新しいプロジェクトは、バージョンごとに環境をターゲットにすることで、この問題と戦おうとしています。 その背後にある考え方は、（1）ブラウザの特定のバージョンまたは「最新のXバージョン」をターゲットにするように要求し、（2）機能の最小公分母を決定し、（3）必要な変換のみを有効にするというものです。 これは役に立ちますが、残念ながら問題を解決することはできません。

大手ベンダーが動作せず、MicrosoftがInternetExplorerで何年も引き起こしていたのと同じ問題を引き起こすリスクがまだあります。 エコシステム全体は、何をいつ実装するかを決定するいくつかのベンダーの手に委ねられています。 これは無料でもオープンでもありません。

唯一の解決策は、JavaScriptの新しいコンパイルターゲットです。これは、パフォーマンスが高く、JSエンジンよりもメンテナンスがはるかに少なくて済みます（できれば何も必要

JS-> WASMは、顧客サーバーへのElectronアプリのオンプレミスインストールに関しては、コードの難読化によって知的財産を保護するのに興味深いでしょう。 信じがたいことですが、確かに、ドイツにはインターネット接続がほとんどまたはまったくない小さな機関がたくさんあり、オンプレミスのインストールが必要ですが、コード全体をプレーンテキストで提供することはソフトウェア会社にとって恐ろしいことです。

@ Simran-B Wasmは、使い慣れたテキスト形式をサポートするための設計原則を備えています。 特に、迅速な分析のための構造化された制御フロー設計があり、スタック順序で使用される使い捨て定義用に最適化されているため、読み取り可能な式用に最適化されています。 したがって、これは「コードの難読化」ターゲットではありませんが、開発者はこれに加えて独自の「コードの難読化」を発行できますが、エンコード効率の低下とパフォーマンスの低下という点でコストがかかることが予想されることを理解する必要があります。

こんにちは、私は憤慨してWebAssemblyを発見しましたが、JS-> wasmコンパイラについて考えると、Angular2のAhead-of-Timeコンパイルのようなものを想像しました。可能ですか？ その価値はありますか？

編集
また、ブラウザがwasmをサポートしていることを示すフラグをクライアントに送信し、JavaScriptファイルの代わりにプリコンパイルされたアプリを提供できる可能性はあるのでしょうか。

リチャード

@ Richard87 Webassemblyは、独自の特殊なエンコーディングと呼び出し規約を備えたプラットフォームに依存しない命令セットと考えることができます。 WebAssemblyの世界で動作するようにトランスパイルするのが非常に簡単なjavascriptのサブセットを説明できないと言っていることは何もありませんが、それを強制することはおそらく難しいでしょう。 フィーチャーセットと実装の表面積はjavascriptで永遠に拡大しており、既存のライブラリとフレームワークをそのサブセットで機能するように適応させることは、特にWebAssemblyでのガベージコレクションの現在の不足を考えると、おそらく困難であり、既存のjavascriptの利点を本質的に失うことになります。コード。

Webアセンブリにガベージコレクションプリミティブを追加すると、大きな古い仮想マシンを作成せずにトランスパイルできるjavascriptのサブセットが広がりますが、それでも、より適切なものから単にトランスパイルする場合と比較して、最適ではないと思います。言語、JavaScriptでのオーバーヘッドはわずかに小さいだけなので、Webアプリケーション（ネットワーク！）での重要なオーバーヘッドは広がり、そもそもJavaScriptを使用することで得たいメリットはまだ届きません。 「javascript」に似たものを使用していると言うことに加えて（これは、他の気まぐれに加えて、サブシステムや一般的な呼び出し規則とよりよく統合するように調整したことを除いて、実際にはUnityがUnityScriptに使用しているのと同様のボートです）。

ブラウザとWebglを検討している私たちの中には、ゲームを高速化することが非常に重要だと思います。 私はwebglで商用品質のゲームを導入するつもりですが、現在の技術では大量のゴミが発生するため、フレームがスキップされます。
JSゲームエンジンを使用したブラウザゲームはほとんど失敗し、Unityは離陸しました。 C ++ => Wasmは、コードをWASMにクロスコンパイルできるフレームワークメーカーのようなこれらの大きなUnityにとって不当な利点だと思います。
しかし、ThreeJSまたはBabylonを使用して手動でJSを作成する人はどうでしょうか。JS/ Asm.js => Wasmツールチェーンがないと、Jsの大規模なアプリケーションが停止し、C ++とコード生成バックエンドを使用してWasmを生成します。 より具体的には、ゲームなどで。
JS開発者にとって不公平なJS => Wasmバックエンドがない。 また、EMCCは実行時にビッグヒープを割り当て、そのため速度は明らかですが、優れたjsコードを作成するJs開発者は、そのようなコードの作成が複雑であるため、それでもそれほど多くのパフォーマンスを達成できませんでした。 ほとんどのものを再利用するための何らかのメカニズムと、gcを早期にまたは自由に呼び出す機能が必要です。 GCの実行時にフレームをスキップすると、Webglがフレームをスキップするのは大きな問題であり、解決する必要があります。 コードジェネレーターよりもJSコードを手動で調整するためのメカニズムが必要です。 手書きのアセンブリのように、それでもはるかに小さく、高度に整列されたコードを生成します。 それはWebアセンブリで可能になるはずです。

@metacritical C ++は、多くの人がプロセスに多くの作業を投入するため、WASMにコンパイルできます。 JavaScriptでも同じことが起こる可能性がありますが、私が知る限り、現在これを試みている人は誰もいません。 そうする理由はほとんどありません。パフォーマンスは変わりません。

エンジンの問題はガベージコレクションです。 線形メモリとWASMコードを使用するガベージコレクションアルゴリズムを構築しても、この問題は解消されません。最終的には、プログラムを停止して、まだ生きているオブジェクトを確認し、生きていないオブジェクトを削除する必要があります。 解決策は、ガベージオブジェクトを作成せず、GCを実行する必要がないようにすることです。 これを実現するためにWASMは必要ありません。エンジンを作り直す必要があります。

配列を再利用し、ガベージを少なくする超自然のままのJavascriptは、作成するのが非常に困難です。 また、PlainJsはWASMにコンパイルできないと思います。 Asm.jsまたはTypescriptは、それぞれ型注釈または型が利用できるため、WASMにコンパイルする方が簡単です。

@metacritical難しいですが、不可能ではありません。 C ++エンジンでも、コードの多くはオブジェクトの存続期間の管理に関するものです。 型にはまらないものの、JavaScriptで同じことができない理由はありません。

プレーンJSはWASMにコンパイルできますが、コンパイラは、ガベージコレクション、リフレクション、プロパティなどのJavaScriptの高レベル機能を有効にするために、多くのヘルパーコードを追加する必要があります。 基本的に、ブラウザに組み込まれているJSエンジンで無料で入手できるものはすべてあります。 TypeScriptはあまり役に立ちません。

比較すると、ASM.JSはWASMに簡単に変換できます。 ASM.JSで許可されているJS機能の厳密なサブセットも、WASMで100％カバーされています。 ASM.JSで大量のコードが記述されている場合、これは価値のある作業ですが、私が知る限り、すべての主要なASM.JSファイルはC ++ソースコードから生成されており、すでにWASMを直接ターゲットにできます。

比較すると、ASM.JSはWASMに簡単に変換できます。

正解です。実際、今日C ++をwasmにコンパイルする主な方法は、最初にasm.jsにコンパイルしてから、 Binaryenのasm2wasmを使用してそのasm.jsをwasmにコンパイルすること

@kripken asm.jsの仕様を見ると、手書きのasm.jsを書くのは簡単なようです。つまり、jsプログラマーにとってすべてが失われることはなく、上記を使用してWASMバイナリを取得できます。

JSの進化、つまり厳密に型指定された言語は、JS-> WASMの良い候補になるでしょうか？
TC39には型付きオブジェクトの提案があると思います。 他の機能がそれを可能にする可能性があります。

@ aruns07ユーザーが使用できるJavaScript機能が少ないほど、WASMへのコンパイルが容易になり、お気に入りのライブラリとの互換性がないために、制限に従おうとしない可能性が高くなります。

@Kardax @ aruns07人々は動的言語の便利さを気に入っています。 常にではない場合もありますが、強力なタイプが必要になることがあります。

jfbastienが2015年6月24日にコメントしました
JS→wasmは、wasmがGCをサポートし、おそらくJITコンパイルもサポートするようになった場合にのみ、実際に意味をなします。 これは基本的に、wasmでJSエンジンを実装することと同じです。

次のリンクによると：
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
WebAssemblyのコンセンサスとブラウザプレビューの終了

現在、最初の返信から2年後、WebAssemblyは現在主要なWebブラウザーでサポートされています。
したがって、wasmにJSエンジンを実装することと同じではありません。
js-> wasmの利点は、GCのサポートだけでなく、コードサイズが小さく、実行が高速であるということです。特に、Ionic2などのハイブリッドアプリケーション開発の分野では、通常、アプリケーションの読み込み時間が5を超える約10MBのJSファイルを生成します。秒（JSの各2MB解析= 1秒）

@jfbastienでは、

修士論文の一部として、JavaScriptのサブセットからWebAssemblyにトランスパイラーを書き込もうとしています。 最初はTypeScriptに限定されますが、将来的にはFlowのような他の型付きバリアントがサポートされる可能性があります。

ただし、目標は完全なJavaScript言語を実装することではありません。この場合、JIT実装が今日直面しているのと同じ問題に直面するため、高速化は期待できません（より確実に、私の実装は100倍遅くなります！ ）。 SoundScriptで定義されているようなサブセットになります

私の目標は、開発者が使い慣れた開発環境を離れたり、別のプログラミング言語を使用したりすることなく、アプリケーションの特定の部分をWebAssemblyにコンパイルできるようにすることです。 したがって、既存のJavaScriptアプリケーションを受け入れる汎用トランスパイラーとしてではなく、アプリケーションのパフォーマンスの重要な部分を高速化することを目的としています。

そのようなアプローチの賛否両論を見ると、私の発見がどうなるのか非常に興味があります。 ご意見がありましたらお知らせください。

@ Mohsen7s私の答えは正確なまま

これは、「Minimal ViableProduct」アプローチに固有のものです。最初に一部のユースケースで機能するものを出荷してから、他のユースケースに対応する機能を追加します。 MVPと欠落している「将来の機能」に関する同様の議論については、次のスレッドを参照してください： https ：

現在実装できるものとできないものに関する技術的な議論はさておき、JS-> WASMが哲学的にもマーケティングの観点からも一番の目標ではないことに驚いています-私はあなたがどのように得ることができるかわかりませんこれが当てはまるまで、開発者の賛同。 あらゆる市場で働くことができるJSスキルを持つフロント/バックエンド/フルスタック開発者全員が、代わりに、かなり小さな業界のサブセットで使用されるC ++の学習に時間を費やしたい場合、彼らはすでに行っているでしょう。だから-私は知っている、私は一つとして話します。 この議論全体がちょっとした反響室であり、コンパイラーの欠如を擁護する人々は、彼らが本当に欲しいものを彼らに尋ねる石炭の顔の人々と話すことに時間を費やすほうがよいと感じざるを得ません。

@BossLevel

現在実装できるものとできないものに関する技術的な議論はさておき、JS-> WASMが哲学的にもマーケティングの観点からも一番の目標ではないことに驚いています-私はあなたがどのように得ることができるかわかりませんこれが当てはまるまで、開発者の賛同。 あらゆる市場で働くことができるJSスキルを持つフロント/バックエンド/フルスタック開発者全員が、代わりに、かなり小さな業界のサブセットで使用されるC ++の学習に時間を費やしたい場合、彼らはすでに行っているでしょう。だから-私は知っている、私は一つとして話します。

ブラウザはすでにJavaScriptを効率的に実行できます。 ブラウザは、意図したユースケースを効率的に実行できません。 それに加えて、WebAssemblyにはWeb以外の願望があります。

このディスカッションとhttps://github.com/WebAssembly/design/issues/992#issuecomment-281735235は、さまざまな人々が持つさまざまな目標を示しています。 間違いはありません！ MVPは、誰が最初にサービスを受けるかを優先する必要があります。

この議論全体がちょっとした反響室であり、コンパイラーの欠如を擁護する人々は、彼らが本当に欲しいものを彼らに尋ねる石炭の顔の人々と話すことに時間を費やすほうがよいと感じざるを得ません。

それが、W3Cコミュニティグループを形成するための全体的なポイントでした。 多くの関心のある開発者から聞いたように、私たちはそれが成功したと思います。 MVPには興味がないものの、将来の機能には興味がある人もい

@jfbastien

ブラウザはすでにJavaScriptを効率的に実行できます。

ハ、私は2008年以来、平均的な携帯電話でまともなFPSで実行できる大規模なマルチプレイヤーHTML5ゲームを作成しようとしていますが、まだそこにいません。 そして、私が請求書を支払うために契約を結ぶとき、私は非常に十分に報われていることを考えると、私の進歩の欠如は私のコードの品質によるものではないと確信しています。

それがW3Cコミュニティグループを形成するための全体的なポイントでした

繰り返しになりますが、コミュニティグループに参加している実世界の開発者は何人いますか？ そうする開発者は、通常、知識のある伝道者などですが、実際の開発者の苦痛はあまり感じていません。

申し訳ありませんが、このページ/関係者/ W3Cの誰かを軽蔑したくありません。 あなたが言うように、これは議論であり、これは最前線からの私の見解です。

犬が骨を心配しているようにこれに戻ってきたことをお詫びしますが、離れている間、私は自分の主張をするためのより良い方法を考えました。 次のニュースレター/コミュニティイベント、またはフィードバックを収集するためのあらゆる手段で、この質問をWeb開発者（顧客）に送信します。

ブラウザベースのパフォーマンスを次のレベルに引き上げるには、別の言語を学ぶ必要があります。 これは受け入れられますか？

それは基本的に、このページの一部の人がすでに（私の考えでは、有害に）回答している質問だからです。

そして最後に（私は約束します; -））

それに加えて、WebAssemblyにはWeb以外の願望があります。

なぜ「WebAssembly」と呼ばれるのですか？

@BossLevel私はあなたがどこから来ているのか

ハ、私は2008年以来、平均的な携帯電話でまともなFPSで実行できる大規模なマルチプレイヤーHTML5ゲームを作成しようとしていますが、まだそこにいません。 そして、私が請求書を支払うために契約を結ぶとき、私は非常に十分に報われていることを考えると、私の進歩の欠如は私のコードの品質によるものではないと確信しています。

高速なJavaScriptを書くのが簡単だという意味ではありませんでした。 私が言いたかったのは、WebAssemblyはJavaScriptの最適化を容易にするものではないということです。 むしろ、それはブラウザが信頼できるパフォーマンスを生成するのにより適したフォーマットを消費することを可能にします。 また、TC39は、コンパイルターゲットとしてのJavaScriptだけでなく、JavaScript自体の改善に集中することができます。

繰り返しになりますが、コミュニティグループに参加している実世界の開発者は何人いますか？ そうする開発者は、通常、知識のある伝道者などですが、実際の開発者の苦痛はあまり感じていません。

申し訳ありませんが、このページ/関係者/ W3Cの誰かを軽蔑したくありません。 あなたが言うように、これは議論であり、これは最前線からの私の見解です。

あなたの見方は確かに正しいです、そしてあなたが立っているところから私が信じがたいことを言っていることは明らかだと思います。 私たちはこれをよりよく伝える必要があります（またはねえ、多分私は間違っています：wink :)。

ブラウザベースのパフォーマンスを次のレベルに引き上げるには、別の言語を学ぶ必要があります。 これは受け入れられますか？

それは基本的に、このページの一部の人がすでに（私の考えでは、有害に）回答している質問だからです。

あなたの懸念はわかりますが、それが真実であることが判明するものではないことを願っています。 繰り返しますが、私は間違っているかもしれません。 私の見方では、WebAssemblyは、このプラットフォームに新しい開発者、過去にWebで悪い経験をした、またはホラーストーリーを聞いた開発者をもたらします。 次に、「従来の」コード（「レガシー」と呼ばれるもの）を使用したいJavaScript開発者がそのコードを使用するのに役立ちます。WebAssemblyをJavaScriptから簡単に使用できるようにする必要があります。 これを実現するには、 npmを使用するのと同じくらい簡単である必要があります（これは...必ずしも簡単ではありません！）。

Twitter、Hacker News、Reddit、およびさまざまな会議で私たちが見ているフィードバックのおかげで、これが明らかになると私はある程度確信しています。 繰り返しますが、多分私は間違っていて、エコーチェンバーを聞いています。 少なくとも、C ++やJavaScriptのバックグラウンドを持つ人々との会議で非常に有望な議論をしました。

同時に、TC39は本当にJavaScriptを改善しようとしています。 近年、特にES6でそうなっていると思います。

ただし、要点は変わりません。開発者は、JavaScriptだけでなく、C ++やRustなどの「WebAssemblyに適した」言語に

なぜ「WebAssembly」と呼ばれるのですか？

ハ！ それは素晴らしい質問です。 「WebAssembly：WebでもAssembly

だから私はあなたがそれにぶら下がっているままにしておきます。

私はここで2つの欲望を読んでいます：

1. 読み込み時間を短縮するための標準JavaScriptのバイナリ表現。
2. ネイティブにコンパイルされたC ++と標準のJavaScriptの間のパフォーマンスのギャップを埋めるための何か。

項目2は、多くの企業による継続的な調査と大規模な投資の対象です。 過去15年間のJavaScriptエンジンのパフォーマンス測定値を見ると、それも機能しています...ギャップは小さくなっています。

私の知る限り、項目1は誰も取り組んでいません。 これは非常に複雑であり、JavaScriptが急速に進化し続けるにつれて難しくなります。 WebAssemblyは非常に厳密で比較的複雑ではなく、開発にはまだ何年もかかりました。

@ jfbastien-あなたの

したがって、いくつかの説明的なポイントは、順不同です。

1）このディスカッション全体とあなたが向かうべき方向についての私の見解の良い例は、NodeJS（JS API /フロントエンドからC ++バックエンドへ）にあります-使いやすさ/親しみやすさなどが得られます一方と速度。
2）ノードに固執し、2008年に私が自分の個人的なオデッセイに着手したとき;-)私はもともとバックエンドとしてPHPとJavaの両方を検討していました（IT管理の暗い側面で10年後に開発に戻っていましたと販売;-)！）しかし、私が1つの言語を学び、それを上手に学びたいという単純な理由で、すぐにそれらを割り引いた！ 私が知っている個人的な話ですが、このように感じている開発者は私だけではないかと思います。特に、言語を学びながら会社のダイムではなく、自分たちのために働いている開発者です。
3）次のポイントを決める前に、意図的に数字をグーグルで検索していませんが（実際、できるかどうかはわかりません）、ASMの使用率が低かったことは間違いありません。 最初のデモを見て非常に興奮したことは知っていますが、コンパイラがないことを知ったとき、すぐにそれを却下しました。 膨大な数のAPI、ライブラリ、リソース、チュートリアル、フレームワークなどをオンラインで利用できる、地球上で最大の開発コミュニティ（JS）の一部であるWeb開発者に、そこから離れるように頼むことは、私の考えではあまりにも多くのことを求めています。その最初のステップ（つまり、コンパイラー）を潜在的に作成する手段を提供しないことによって、あなたの側に明らかなトリックが欠けています。 シェーディング言語（GLSL）の開発は、a）Pixi.jsやThree.jsなどの優れたフレームワークに直接書き込むことができ、b）それで遊ぶことができるようになったため、ASMよりも成長が進んでいることを賭けてもいいでしょう。 ShaderToyなどのサイトで直接。
4）ゲーム業界/ゲーム全般。 ここでの経験から、a）過去9年間（まだリリースされていません！）ゲームを書いていること、b） TIGA （英国のゲーム開発者の業界団体）の役員を2年間務めたことがあると言えます。 私を信じてください、私はおそらく一方でウェブに移行したいと思ったゲーム開発者の数を数えることができると思います-ゲーム開発者はすでに彼らが愛する業界にいて、それにもかかわらずペイヒット/長時間働いています、それでこれらはWAのターゲットオーディエンスであってはなりません。 はい、彼らの雇用主は常にゲームを移植するための新しいメディアを探していますが、モバイル（ネイティブコードが悲しいことに手に負えないものであり、WASMに修正してほしいものです）を除いて、私たち自身をからかってはいけません。パフォーマンスと収益化の両方の点で、PC /コンソールとの関係が悪い。
5）逆に、寝室のコーダー/インディーシーンは数年前の頂点にはありませんが、暇なときにWebゲームを作りたいと思っているWeb開発者はたくさんいます。 そして、私はあからさまに政治に傾倒したくはなく、Unityの人たちをノックすることは決してありませんが（私は彼らの多くと取引をしていて、それは素晴らしい製品です）、個人的にはあなたが利益の世話をするべきだと思います1人の大物ではなく、複数の小人の（それは政治的および商業的意味の両方に意味があります）。

私はあなたの話を見るのをとても楽しみにしています@jfbastien :)

@ RyanLamansky-あなたは合理的な区別をしていると思います。 に関して：

私の知る限り、項目1は誰も取り組んでいません。 これは非常に複雑であり、JavaScriptが急速に進化し続けるにつれて難しくなります。

完全に個人的なレベルでは、2008年から1日8時間JSを書いている人として、JSの進化がしばらく止まって、他のみんなに追いつくことを望んでいます！ 私は常に最小公分母のために開発するという原則に取り組んできました。つまり、100％のサポートがない場合、それは起こりません（IE6 / 7/8/9は別として;-)）。 そのため、デスクトップとモバイルでES5のブラウザが100％サポートされていない場合でも、流行のES6パターンと想定されるユースケースに焦点を当てるというばかげた立場にいることに気づきます。 この言語は、市場シェアによって示されているように、明らかに現状のままで機能します（それは認められていますが）。開発者のコ​​ミュニティとして、今後数年間、私たちが持っているものではなく、効率的で最適なコードを書くことを学ぶのはどうですか？もう一度、新しいヒップスターコードで車輪の再発明をします（申し訳ありませんが、私は暴言の領域に入ります;-)）？

たぶんコートを着る時だと思います;-)

@RyanLamansky WebAssemblyがバンドルビルドプロセスの新しいターゲットになり、突然すべてが高速になるという印象を受けました。 明らかにそうではありません。 WebAssemblyには非常に具体的なターゲットのユースケースがあり、ビジネスロジックでいっぱいの大規模なJSコードベースを一般的なWeb開発者に提供することはおそらく多くありません。

しかし、ご存知のように、より一般的なビジネス指向のWebアプリケーションのJSベースの開発ライフサイクルにはいくつかのギャップがあります。
1）大規模なJSバンドルにはかなりの解析オーバーヘッドがあり、通常は不十分な難読化を提供します。
2）標準のJSコードには、JIT /ネイティブコードの最適化に必要な型注釈（およびおそらく他のヒント）がありません。

これは、考えられる解決策が、開発者により決定論的で透過的な最適化パスを提供するJSの適切に型指定され、注釈が付けられたバージョンと、そのバージョンの言語の事前解析されたバイナリバージョンであることを示唆しています。

コメントとドキュメントによると、WASMはJSのほかに実行され、同じJSエンジンのブラウザー（最適化）を使用します。 https://developer.mozilla.org/en-US/docs/WebAssembly

私はこの質問を本当に理解していません。

愚かな質問をして愚かなコメントをすることをお詫びします：質問とWebassemblyチームのコメントは、 Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code?私が主観的な考えしか見ないことを意味しますか？ 誰かがこれを説明できますか？ WebasemblyがJavascriptよりも高速な場合は、トランスパイラーを提供してみませんか？ Javascriptが不可能な場合は、ES7 / TSコードを使用しないのはなぜですか？ なぜこれほど多くの秘密があるのですか？

@ganeshkbhat WASMの最初のリリースは、JavaScriptの非常に厳密なサブセットであるasm.jsのコンパクトなバイナリエンコーディングにすぎません。 64ビット整数はasm.jsでエミュレートする必要があるため、64ビット整数を使用しない限り、asm.jsよりも高速に実行されません。

WASMに機能（ガベージコレクション、DOM統合、スレッド）をJavaScriptに近づける機能を追加する提案がありますが、完全なJavaScript機能セットを追加する予定はありません。 したがって、JS-> WASMトランスパイラーは存在しない可能性があります。 代わりに、WASMの制限内で動作するように設計された新しいアプリケーションとライブラリが作成されます。 今日、それはCとC ++であり、言語制限はWASMとasm.jsとうまく調和しています。

秘密も魔法もありません。 Wasmは、ハードウェアにはるかに近い、はるかに単純な言語であるため、「JavaScriptよりも高速」です。 JavaScriptは複雑な言語であり、実行中に多くの高価なことをしなければなりません。 直接ではなくWasmを介してネイティブコードにコンパイルしても、魔法のように速くなることはありません。

@ganeshkbhat現在、asm.js / webassembly内にオブジェクトを割り当てることはできません。 asm.jsとwebassemblyでは、すべてのJavaScript操作で1つの大きなtypedarrayを使用して、そこに値を格納およびロードします。 JavaScriptオブジェクト（例： var obj = {a: 1, b: 'test'} ）と配列（例： var a = []; ）は、オブジェクトのサポートがまだないため、WebAssembly内では作成できません。 これは、すべての主要なブラウザでWebAssemblyのサポートをできるだけ早く取得するために行われたMinimal ViableProductの設計上の決定です。

将来のバージョンでは、 GCサポートはWebAssemblyで計画されています。 私たち（ LeaningTech.com開発者）は、WebAssemblyでのオブジェクトサポートの提案に取り組んでいますが、すべての主要なブラウザーでの仕様および実装として着陸するには時間がかかります。 それまでは、JavaScript（およびCoffeeScript、TypeScriptなど）をWebAssemblyにトランスパイルすることはできません。 提案が受け入れられると、 JavaScriptのより大きなサブセットをトランスパイルできるはずですが、現在利用可能なサポートするません。

もちろん。 ここでJSのより良いサポートを楽しみにしています。 確かにサポートできると思います。 トランスパイラーを書くことは、型をサポートする言語に必要かもしれないものです。

私がwebassemblyについて読んだことから、それは主にWebブラウザーを対象としており、その領域ではjs-> webassemblyコンパイラーを持っていることはあまり魅力的ではないようです。 しかし、ブラウザ以外の環境でWebAssemblyを実行することは想像できます。 これはnodejsでも実行できるため、完全には当てはまりませんが、vertx（webassemblyにコンパイルできる任意の言語で記述されたモジュールを実行できるpolyglot）のようなnodejs環境では真の可能性があると思います。 このようなことを成し遂げるのは非常に難しいだろうと想像できます。 GCのような多くの機能が必要になり、おそらく何らかのVMを実装する必要がありますが、不可能なことは何もありません。 多くの人がasm.jsにも懐疑的だったことを思い出して、今日それを見てください。

js-> webassemblyのコンパイルに（私として）興奮しているすべての人にとって、将来、プロジェクトts2ctranspilerを使用してjs-> c-> webassemblyを介して間接的で非常にでこぼこした方法があるかもしれません。

@ mauron85非ブラウザーおよび非JavaScriptランタイム環境は、間違いなく設計の考慮事項です。現在、

私としては、.NET JITシステムを試してきましたが、時間以外に実際の障壁は見られません。WASMをお気に入りのプラットフォームに統合しようとしている人もいると思います。 数年後、WebAssembly用の高品質の非JavaScriptランタイムが登場すると確信しています。唯一の未解決の質問は、WebAssemblyチームによって正式に承認される程度です。

JavaScript -> WebAssemblyコンパイル機能のIMOの利点の1つは、Javascriptライブラリとツールの開発者/メンテナがAPIを2つの形式でリリースできる可能性があることです。

1. ユーザーがブラウザとノードに使用できるJSで（現在のように）
2. より効率的なコンパイル済みライブラリとしてのWASM。

また、JSライブラリでWASMのパフォーマンス上の利点を発揮したい場合は、既存のJSコードをC / C ++で書き直す必要はありません。
したがって、ライブラリ開発者はJavascriptで開発および保守し、JSとWASMの両方で2つの異なるターゲットに対して2つの出力を生成することができます。

また、コンパイルされたWASMバージョンライブラリを使用すると、ユーザーはライブラリから公開されたAPIを使用するだけで、WASMで記述されているかどうかを気にしないため、間違いなく効率的です。 しかし、パフォーマンスは確かに改善されます。

より効率的かもしれないコンパイルされたライブラリとしてのWASM

どうして？ なぜjavascriptトランスパイルWebアセンブリのブロブ（そのバイナリのjavascriptエンジンのランタイムの多くを含む最悪のシナリオ;とにかく独自のオーバーヘッドが発生する将来の組み込みwasmGCの上に構築されたレイヤーを含む最良のシナリオ） ）専用のjitでスローされたjavascriptよりも速く実行します... javascriptを実行しますか？

さて、あなたはそれがより多くのオーバーヘッドでさらに遅くなるということですか？

よくわからないことがあるかもしれません。 C/C++/Rust -> WebAssemblyコンパイルされたものはどのように本当に効率的であり、将来的にJS -> WASMサポートがあり、オーバーヘッドが発生する可能性がありますか？ それは、JSが動的言語であり、C、C ++、およびRustがそうではないという理由だけですか？ それとも、JSは本質的に完全にコンパイルされた言語ではなく、これらの他の言語がそうであるためですか？

JSからWASMへのコンパイルが持続的なパフォーマンスを向上させる可能性は低いと思います。 ただし、バイナリエンコーディングにより、コードサイズと解析時間が改善される可能性があります。これは依然として有用です。

JSのバイナリエンコーディングを定義するだけで、今のところ線形メモリなどは無視できると思います。 これはシンプルでポリフィル可能です。

@kabirbaidhya現在のJS->

JS-> WASMのもう1つの大きな障壁は、ほぼすべてのオブジェクトが完全に動的であるという事実です。 WASMは本質的にすべてが純粋に静的であることを期待しているため、標準のJSパフォーマンスに近づくには、複雑なマッピングレイヤー、エミュレーション、および動的コード生成が必要になります。 幸い、TypeScriptはこれに役立ちます。そのため、TypeScriptの厳密なサブセットは、ある程度WASMをターゲットにできる可能性があります。 私はこれを構築しようとしている人が少なくとも1人いることを知っています。

C / C ++は、WASMの制限が、C / C ++が対象とするように設計されているネイティブハードウェアの制限と密接に連携しているため、WASMの最初のリリースでうまく機能します。

FWIW V8がJavaScript演算を処理する方法については、すばらしいスライドデッキがあります： https ：//docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; drこれは単なる_one_の例であり、現実は見た目よりもはるかに難しく、実際には、ネイティブVMは真にネイティブであり、アクセスできるため、より優れた、より高速なジョブを実行できるため、実際にはあまり意味がありません。リソースとAPIは決してそうなることはなく、（おそらく）最も重要なのは、何年にもわたる反復です。

それは次のように、JS /活字体の_subset_が正常に増殖することができなかったと言うことはありませんThinScript 、 TurboScriptなど、彼らは一見JS-プログラマーにとって非常に身近な見てみましょう。

私はまだこれらが尋ねるべき良い質問だと思います、そして尋ね続けます。 WebAssemblyのユースケースと将来、そして目標以外のことを私たち全員が理解することが重要です。

午後12時36分に2017年4月6日、ライアンLamanskyの[email protected]は書きました：

JS-> WASMのもう1つの大きな障壁は、ほぼすべてのオブジェクトが
完全に動的です。 WASMは本質的にすべてが純粋であることを期待しています
静的で非常に複雑なマッピングレイヤー、エミュレーション、動的コード生成
標準のJSパフォーマンスに近づくには必要です。 幸運にも、
TypeScriptはこれを支援するため、TypeScriptの厳密なサブセットで次のことができる場合があります。
WASMをある程度ターゲットにします。 私は少なくとも一人がしようとしていることを知っています
これを構築します。

残念ながら、TypeScriptがこの点で役立つとは思えません。 包含します
JSレガシー、その型システムは非常に深く根本的に不健全であるため
興味深い「厳密な」サブセットはありません。 たとえば、そのようなサブセットは
TSのサブタイピングの概念を除外する必要があります。
そのドメインではあまり役に立たない。

SafeTypeScriptなどの優れた研究論文はありますが、そうではありません。
それらはより制限されているだけでなく、かなりの量を必要とします
コストのかかる追加のランタイム簿記とチェック、
ディスカッション（そして事実上JS / TSとは異なる言語である）。

何かが得られないかもしれませんが、WebAssemblyのアイデアの1つは、jsの解析時間を回避するためにASTを直接ロードすることです。

したがって、jsをこのast形式にコンパイルしてブラウザーに渡すツールがある場合、解析する時間を回避することでメリットが得られるのではないでしょうか。

@agnivade 、これは完全に異なる、はるかに低レベルの言語のASTです。

JSをWasmにオフラインでコンパイルする場合は、はい、クライアント側で解析する必要はありません（デコードするだけです）。 同時に、JSは非常に複雑であるため、コードサイズが大幅に増加し、おそらく5倍以上になります。これは、はるかに高いコストです。 （そして、それはおそらく、JS VMランタイムシステムの実装全体をWasmに含める必要があることも考慮に入れていません。これは簡単にメガバイトのコードです。）

さらに、ソースの表現がなければ、JSをどこでも高速に近づけるために重要な動的最適化のほとんどを実装することはできません。 これらの最適化は、元のソースコードを再コンパイルし、プロファイリング情報に基づいてそれを特殊化することに依存しています。 すでにコンパイルされたWasmASTはそれを有効にしません、あなたは元のソースプログラムのASTを必要とするでしょう。

@ rossberg-chromium-どうもありがとう。 それはたくさんクリアします！ しかし1つの疑問-

そして、それはおそらく、JSVMランタイムシステムの実装全体をWasmに含める必要があることも考慮に入れていません。これは簡単にメガバイトのコードです。

なぜVMランタイムシステムが必要なのですか？ ブラウザ自体はVMランタイムではありませんか？ ブラウザがすぐに実行を開始できるように、コードをAST形式にしたいだけです。 言語自体が複雑で、動的な最適化を実装できないため、ネットサイズが大きくなることがわかりました。 しかし、そのためのブラウザーがあるのに、なぜVMランタイム自体をバンドルする必要があるのでしょうか。

@agnivade 、動的最適化がないとJavaScriptは遅くなります。つまり、100倍遅くなるなど、_本当に_遅くなります。

「ランタイム」とは、DOMのようなブラウザのものを意味するのではなく、ガベージコレクタ、オブジェクト表現、プリミティブ、ベースライブラリなどの裸のJS言語サポートを意味します。これはJavaScriptにとって非常に大きなものです。 Wasm内ですべてを再実装する必要があります。

そしてもちろん、DOMへのインターフェイスレイヤーも必要です。

わかりました。もう少しよく理解できたと思います。 私は

ガベージコレクター、オブジェクト表現、プリミティブ、ベースライブラリなど。

ブラウザ自体から使用できます。 そして、ブラウザにASTをロードさせて、通常の仕事をさせることができます。 しかし今、私はすべてがWASM自体の中にパッケージ化される必要があることに気づきました。

しかし、普遍的なスクリプト言語のバイトコードは興味深いでしょう！ 動的に型付けされたガベージコレクション言語で記述されたプログラムを効率的に転送および実行するように設計されたコンパイルターゲット。人気のあるもの（javascript、ruby、python、lua）のすべての奇妙なエッジケースが（場合によっては）特別なopcodeや構造などでカバーされます

@distransientなので、すべてのスクリプト言語の組み合わせの狂気が必要ですか？ 私は、人類がエンジニアリングリソースを収集して、2050年までにそれを効率的に指定および実装することが可能になると楽観視しています。:)

LLVMを使用してTypeScriptをWebAssemblyにコンパイルすることに興味がある人。 このリーチプロジェクトをチェックしてください。 https://github.com/MichaReiser/speedy.js
この議論は決して終わらないようです...

@ rossberg-chromium私はそれが「面白い」だろうと言った、簡単でもきれいでもない😉

普遍的なスクリプト言語のバイトコードは興味深いでしょう...

WASMは、最終的にPythonのようなものをサポートするように段階的に進化していますが、反対側から同時に問題に取り組んだ場合、WASMが提供できるよりもはるかに早くWeb用のスクリプト言語を開発するためのファーストクラスのサポートを得ることができます。

JavaScriptエンジンがJavaScriptASTを実行する機能を公開するのは比較的簡単である必要があり、受け入れたASTは標準化できます（内部で非標準の中間形式にすぐに変換された場合でも）。

AST形式（ estree ）とシリアル化形式（JSONなど）を単純に組み合わせて、新しい拡張子を持つ新しいファイル形式を作成できます。 ブラウザがスクリプトタグなどの形式をサポートしている場合、TypeScriptやCoffeeScriptなどの言語は、ツリーを解析するためにコンパイルするだけで、ブラウザはそこからそれを取得します。 語彙情報は実際のソースに基づいているため、トランスパイルされた言語はコード生成を行う必要がなく、ソースマップも必要ありません。

基本的なサポートが確立されると、基本的に新しいノードタイプを追加するだけで、標準は段階的に進化して、途中でWASMを満たすことができます。 明示的なadd concatノードと

WASMがスクリプト言語のサポートを構築するにつれて、GCなどを追加することで、ASTの実行が下に移動し、JavaScriptセマンティクスを拡張して他の高級言語の機能を含めることができるため、より幅広いスクリプト言語のセットを一種の抽象的なJavaScriptにコンパイルでき

2時57分に2017年5月25日、カール・スミス[email protected]は書きました：
>>

対処する必要のある問題がいくつかありますが、
JavaScriptエンジンが内部サポートを公開するのは比較的簡単です
JavaScript ASTを実行するために、それらが受け入れるASTは
標準化（ASTがすぐに非標準に変換された場合でも、
内部的に中間フォーマット）。

おそらくあなたよりもはるかに広い「比較的単純な」定義のためだけに
思っている... ;）

WASMに比べて、それは簡単です。

@bguiz例：

• JSはアーキテクチャが異なるため、ネイティブにASMに変換することはできません。
• CPUグラウンドレベルでそのリソースにアクセスできないため、ASMからDOMを操作することはできません。

Google V8エンジンは、実行前にランタイムタスク全体をコンパイルすることにより、JavaScriptをネイティブマシンコードに直接コンパイルします。

したがって、クライアント側から代替のWASMパイプラインを用意する必要はまったくありません。

一方、WASMにはMandelbrotデモが提示され、そもそもUnityの「タンク」デモが特徴ですが、ASM-> CPU（SSEの倍精度でも）でピクセルを描画する方がこれまでになく高速であるとは思えません。このコミュニティが言うように、GPUはスコープ内にないため、WebGL-> GPUよりも。 だから何？

@ivanherczegうわー！ このコミュニティは、GPUが仕様に含まれていないとどこで言っていますか？

@SephReed

アームとx86のバイクシェッドの違いにより、すでに緊張が高まっています。 別のハードウェアターゲットのセットを追加すると、緊張が高まると思います。すべてのターゲットで均一なセマンティクスを取得するためにエミュレーションコストのために操作を遅くするか、全員が高速で実行できるように動作を定義しない必要があります。 そのため、現時点（またはこれまで）にGPUを検討することは不採算になると思います。

-フィル

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

C＃ランタイムはwasmに移植され、JSを完全に置き換える完全に機能するプロトタイプでした。 つまり、将来的には、ランタイムが出現して、ブラウザのJSに置き換わり、Java、C＃、さらにはC ++で、 「コードはネイティブに近いほど高速に実行される」 、 「コンパイルされたコードはVMよりも高速である」というステートメントでクライアント側のWebアプリを作成することが期待できます。またはJavaScriptの助けを借りずに何か。

私が言おうとしていることのこのビデオを

WebASMは、JSを補完して完全に引き継がないようにするために導入され、ファーストクラスの言語に取って代わりました。

近い将来、ネイティブにコンパイルされたサーバーから配信されるWebページを期待できます

https://github.com/ballercat/walt

@Steakeyeとても素敵です:)私は遊びをします-ハイライトしてくれてありがとう:)

NectarJSを使用してJSをWebAssemblyにコンパイルできます。 デモ： http ：

興味深いことに、NectarJSデモはemscriptenを使用しています。これは、asm.jsの出力で確認できます。 JSを静的にコンパイルして（おそらくCまたはLLVM IR）、それをemscriptenで実行しているようです。

wasm出力もemscriptenを使用します（バイナリを調べるとわかります）が、最新のVMでは実行されない0xd wasmバイナリを出力するため、古いバージョンを使用しているようです。 また、JSではなくwasmを送信するだけなので、とにかく実行できません。 いずれにせよ、asm.jsの場合と同じように、wasm出力のフラグをオンにしてemscriptenを実行するだけである可能性が非常に高くなります。

デモには入力に300バイトの制限があるため、実際のプログラムにフィードして、分析がどれほど強力であるかを実感するのは困難です。これは、このような静的なアプローチの本当の問題です。 一般に、このトピックに関する学術研究は懐疑論を示唆しています。

Windows用にコンパイルされたデモは私のために単にクラッシュします🤕

ここで@kripkenの懐疑論に同意します。 任意のJSをWebAssemblyに合理的に変換することはできないと思います。 これを達成すると主張するツールは、おそらくJS言語の扱いやすいサブセットで動作しているか、実行パフォーマンスを放棄しています。

JSは非常に動的な言語です。 予測できないランタイム操作は、コードのセマンティクスを大幅かつグローバルに変更する可能性があります。 つまり、Ahead-Of-Time（またはオフライン）コンパイラーは、より悪いものを想定し、考えられるすべてのケースを処理できる非常に非効率的なジェネリックコードを生成することしかできません。 例として、次のJSコードを取り上げます。

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

（疑似wasmで）これに変換できます

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

さて、これは私たちが合理的に「コンパイル」と見なすことができるものからは程遠いものであり、インタプリタを展開することに似ています。 もちろん、WasmにコンパイルされたJSインタープリターを実行することも可能ですが、それはパフォーマンスの向上にはなりません。

V8やSpidermonkeyなどのJSエンジンは、ジャストインタイムでコンパイルすることで、JSコードを実行するのと同じ速さで実行できます。 JITコンパイルを実行することで、特定のJSの実際に意図されたセマンティクスを観察し、その特定のケースの高速コードを生成できます。もちろん、現在の仮定を無効にする可能性のある環境の変化を注意深く検出します。

同意しました。 ただし、JavaScriptサブセットを使用してもかまいません。 あるいは、型付きのバリアントである可能性があります。これにより、ダイナミズムが低下し、より効率的なコードを生成できるようになります。

「ストロングモード」フロントBTWに関するニュースはありますか？

@ Simran-B、ここに要約されている理由により、私たちは長い間ストロングモードを放棄してき

同じ理由で、JavaScriptまたはTypeScriptの「静的にコンパイル可能な」方言を設計するというアイデアもあまり期待していません。既存のコードを実行できない別の言語になるため、あまり意味がありません。

@ Simran-B：「JavaScriptサブセットを使用してもかまいません。または、型付きのバリアントかもしれません」

WebAssemblyにコンパイルされるTypeScriptの厳密なサブセットであるAssemblyScriptのように、そのスペースには非常に興味深い作業がいくつかあります。https：//github.com/AssemblyScript/assemblyscript

@rossberg ：「JavaScriptまたはTypeScriptの「静的にコンパイル可能な」方言を設計するというアイデアにもあまり期待していません。既存のコードを実行できない別の言語になるので、あまり意味がありません。」

AssemblyScriptのようなものの大きな可能性は、既存のコードを実行することではないと思います（私はそこであなたに同意します、それは一般的に実行可能ではありません）が、親しみやすく親しみやすい言語を持つことは大きな問題です。

現在、TypeScript開発者であり、WebAssemblyを作成する場合は、C ++またはRustを使用する必要があります。 どちらも良い言語ですが、欠点もあります。 そのような経歴を持つ人にとって、AssemblyScriptのようなものが生産性への最速の道かもしれません。

AssemblyScriptがJavaScriptとAssemblyの両方にコンパイルできる場合、それは非常に理想的です。 これらの更新を楽しみにしています。

また、将来的には、誰かが最初にそれを行わない限り、ファイルを調べ、必要な質問をしてから変換を行うTypeScript-> AssemblyScriptコンバーターを作成してみます。 うまくいけばうまくいきます！

@SephReedはい。すべてのWebAssemblyコードで動作するWebAssembly-> asm.jsコンパイラがあるため、JavaScriptにコンパイルできます。

「WebAssemblyをポリフィルできますか？」も参照してくださいFAQのセクション。

代わりに「AssemblyScriptを慣用的なJavaScriptコードにコンパイルすることは可能ですか？」という意味の場合、WebAssembly / asm.jsが慣用的なJavaScriptコードよりもはるかに高速であるのに、なぜそれを実行したいのでしょうか。

TypeScriptコンパイラを介してAssemblyScriptコードを実行できるはずですが。 ただし、特定の点に注意するあります。

AssemblyScriptドキュメントのこのセクションも参照してください。

紳士の皆さん、JavaScriptのようなWebAssembly言語であるWALTを検討してください。

UPD。 ネクロポスティングでごめんなさい

多くの人がこの「JS-> WASM」コンパイラを良いアイデアだと考えているようです。

それが役に立たないと思う人のために、例えば：

ただし、開発者の観点からはそれほど役立つかどうかはわかりません。 サイズがいくらか縮小されるかもしれませんが、それだけです。 ブラウザの観点からは、純粋なセキュリティの観点からJSエンジンをwasmに実装することは興味深いかもしれません。

これが、なぜそれが重要で、なぜそれが有用であるかについての私の具体的な例です。あなただけでなく、「サイズを小さくするだけでなく、それだけです」。 WebAssemblyに付属する機能の1つは次のとおりです。

<= XXX« SaNdBoXeDENViRoNmEnT »XXX =>

WebAssemblyはパフォーマンスだけではありません。 Figmaチームからのプラグインに関する良い記事を見るかもしれません。

プラグインシステムを作成することは非常に困難です。 カスタムコードを実行するための良い方法が必要です。 安全な別の環境が必要です。

WebAssemblyはそれを提供します-いくつかのグローバル変数のような混乱のない純粋な環境。 AssemblyScriptを使用すると、ある意味で便利になります。メインアプリの環境とほぼ同じTypeScript環境があり、非常に便利です。

しかし、ここに「ほぼ同じ」問題があります。

安全な環境でNPMのJSパッケージを使用できますか？

いいえ。

このWALTプロジェクトは、ある種のAssemblyScriptの代替手段です。 それはかろうじてJSのようなものです-それはタイプされたjsです。 TSのようなものです。 それを使って既存のjsライブラリをコンパイル/トランスパイルすることはできません。

安全な環境でNPMのTSパッケージを使用できますか？

いいえ。

AssemblyScriptもTSに似た言語です。 型で完全にカバーされている場合、TSで記述されたものをコンパイルする可能性があります。 例外なく。 anyありません。 しかし、多くの場合、構成が十分に厳密でないか、いくつかの@ts-ignoreを持っているか、さらに多くの場合、jsでパッケージを記述し、 .d.tsファイルで個別の型を提供します-これらすべての場合、そのようなパッケージをWASMにコンパイルすることはできません。

@JerryGreenの良い点ですが、パフォーマンスの面では、実際には、数バイトを節約する以外にパフォーマンス上の大きなメリットがないというのは大きな誤解だと思います。 ベンチマークを含む人々は、実行時のパフォーマンスに夢中になっています。 3Dゲームの実行速度をご覧ください。

しかし、実際の機会は実際には起動時のパフォーマンスにあり、これは事実上すべてのWebサイトにメリットをもたらします。 WebAssemblyの起動時間（バイトあたり）が、実行時のメリットをはるかに超えて大幅に高速化されていることについて話している人はほとんどいないようです。 これが、たとえばJavaScriptなどのテキストコンテンツのgzipがPLTに実際の影響をほとんど与えない理由です。重要なのは、コンパイルされたコードのサイズです。

皮肉なことに、業界はPLT（Page Load Times）とさまざまな視覚的完全マーカーに夢中になっていますが、WebAssemblyとこれらのベクトルの相関関係は誰にもわかりません。 JavaScriptは、ほとんどのWebサイトで、これらの重要なイベントの前に費やされた時間の30％以上を占めています。 実際、ページのサイズと帯域幅は、線形のパフォーマンス要因、つまりJavaScriptの起動時間と待機時間と比較して、

そうは言っても、JS-> WebAssemblyの実現可能性は私にはわかりません。

@JerryGreen Figmaのアプローチは非常に特殊なケースであり、ほとんどのプロジェクトでは、サードパーティのJavaScriptを分離するにはiframeまたはレルムで十分だと思います。 分離をより制御する必要があり、パフォーマンス、サイズ、読み込み時間がそれほど重要ではない特殊なケースでは、QuickJSまたはJavaScriptCoreをいつでもWebAssemblyにコンパイルできます。

また、 Web Workersを使用して、信頼できないコードの前にコードを実行し、信頼できないコードにアクセスさせたくないAPIを削除することもできます。 この場合、WASMは必要ありません@JerryGreen！

実際には、3つのjsでフレームレートが低下します。wasmが役立つかどうかはわかりませんが、少なくとも表面的にはそう思われます。

javascript vm全体も含める必要があるため、JSをwasmにコンパイルする理由はありません。 結果として得られるコードは、JSVMがネイティブに提供するものよりも巨大で低速になります。

プロファイルガイド付き最適化を介してJSVMによって行われるすべての単形化などを行うことができませんでしたか？ JS VMが実行時に実行するのとほぼ同じことを実行しますが、事前に実行します。

PGOビルドは、2つのパスで構成されます。最初のパスはインストルメント化されたバイナリをビルドし、2番目のパスはインストルメント化されたバイナリの実行から収集したプロファイル情報を使用して最適化されたバイナリを再構築します。

最初の実行では、すべての型情報（どの関数がどの型付き引数で呼び出されるかなど）が提供され、次に、関数が呼び出されるすべてのバリアント（+プロファイルされていないコードの動的引数を持つ汎用バイナリ）を使用して最適化されたバイナリを構築します。 JSVM全体は必要ありません。

PGOはあなたのプログラムの素晴らしいテストの報道を必要としました。 それは常に可能であるとは限りません。 ただし、v8での実行中に一部のタイプ情報をトレースできます。 このドキュメントを参照してください： https ：//docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading = h.xgjl2srtytjt

TypeScriptチームとこの可能性について話し合い、彼らは関心を示しましたが、現在、型付きオブジェクトをJSに追加することについては進展が見られないようです。

タイプは必要ありません

QuickJSは本当にWASMにコンパイルできますか？

はい、FigmaはプラグインシステムにQuickJSを使用しています。

また、 http：//numcalc.com/でも使用されています。