Design: なぜjavaや.netではないのですか？

私もWebAssemblyを初めて使用します。 しかし、私はこれがすでに何度か尋ねられていると思います。 多分それはFAQにあるべきです。

私の推測では、.netとjvmはバイトコードであるだけでなく、独自のガベージコレクションとクラスローダーおよびリフレクションを備えた仮想マシンであるためです。 WebAssemblyは、実際にはブラウザに依存しない低レベルの運用プラットフォームです。 WebAssemblyでJVMを実行できると思いますが、それでは希望する結果が得られません。 WebAssemblyの起動時間とJVMの起動時間を追加するだけです。 そして、2つの異なるガベージコレクションヒープがあります。 1つはJavaScriptからのもので、もう1つは新しいJVMからのものです。 現在、GWTの方が優れていると思います。

Web Assemblyを、完全に新しいテクノロジーではなく、asm.jsの進化形と考える方が正確です。 asm.jsに対して実際に備えている唯一の機能は、64ビット整数であり、ほとんどのプログラムでは必要ありません。 この限られた範囲により、既存のJavaScriptエンジンに比較的簡単に統合できます。

Web Assemblyプロジェクトのベテランの1人はおそらくもっと完全な答えを持っているでしょう、そしてこれは1.0が出荷されるときに頻繁に出てくる可能性があるので、これは良いFAQ項目になるだろうと私は同意します。

Jvmおよび.Netバイトコードは、関連する仮想マシンに特化しており、それぞれに、Webブラウザーで実行される仮想マシンとは別に解決しようとしている独自の懸念事項と問題領域があります。 2番目の仮想マシン全体をWebブラウザーで実行するように適合させることは、ユーザーにとって厄介であり、Jvmおよび.Net vm apiを既存の仮想マシン内で実行するように適合させることは、実装が煩雑であり、必然的にユーザーにとって厄介であり、エラーやバグが発生しやすくなります。複雑さが増します。 Web Assemblyは、トランスポート時間とロード時間の最適化に重点を置いて、すでにブラウザにある既存のJavascript仮想マシンで簡単に実行できるシンプルなISAとして設計されており、既存のバイトコードでは十分に満たされません。

FAQまたは理論的根拠のドキュメントでこれについて何かがあると確信していました。 私たちはしません。 それは素晴らしい追加になるでしょう。

@ kovalenko0意見を

@ kovalenko0ああ、そしてすべてのWebブラウザーベンダーにJVMと.netをバンドルすることに同意させることも、あまりにも大きな障壁だったかもしれません（攻撃対象領域や肥大化などの理由で予想していましたが、おそらくもっと小さな理由でも） 、したがって、asm.jsは共通の基盤であるもので動作しました。 Wasmは、Webブラウザベンダー間の合意がなくても、Web上でJVMまたは.Netを使用できるようにし、セキュリティと肥大化について独自の判断を下せるようにする可能性があります。

ここで回答を組み合わせてFAQに追加するつもりですが、このプロジェクトの貢献プロセスはどのようなものですか？

コミュニティグループに参加していることを確認してから、PRを
デザインリポジトリ。

19:56時金、2017年1月27日には、ライアンLamansky [email protected]
書きました：

回答を組み合わせて、FAQへの追加を書きたいと思います
ここにありますが、このプロジェクトの貢献プロセスは何ですか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/WebAssembly/design/issues/960#issuecomment-275744408 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ALnq1BziU5qIZOBNq5fBYLfOjoeOkMIzks5rWj3SgaJpZM4LmzIH
。

貢献する詳細。 それらは「新しいPR」ページからリンクされています😁

私は当初、LLVMの下にセクションを追加することを計画していましたが、そのセクションが2015年に作成されたため、一部が古くなっています。 例えば...

LLVMの経験を生かし、目標と要件に合わせてIRとバイナリエンコーディングを設計することで、他の目的に設計されたシステムを採用するよりもはるかに優れた成果が得られると確信しています。

...現在のWASMバイナリエンコーディングがブラウザのプレビューで問題なく機能していることを考えると、あまりにも慎重すぎるようです。

私は現在、LLVMセクションを既存のバイトコードに関するより一般的な議論（例としてLLVM、Java、および.NETに言及）に置き換えることを検討しています。これは、WebAssemblyチームが採用したアプローチにはるかに自信を持って表現されています。

異議はありますか？

@Kardax LLVMセクションをどうするかは、 @ dschuff / @ sunfishcodeまでです。

@kardaxさまざまなデザインには多くの長所と短所があり、それでもwasmに多くの改善を加えることができるため、何も追加しない方がよいでしょう。 Asm.jsは、あなたの観点からは「完璧に機能していた」可能性があり、ある意味ではwasmよりもパフォーマンスが優れていたため、さらに多くの機能があります。 解析/デコードとコンパイルの時間とパフォーマンスを調べたいと思うかもしれません。

@wllang ...何のことをいっているのですか？ ASM.JSのパフォーマンスがWASMより優れているとは決して言いませんでした。 あなたは私が書いたものを完全に誤解したと思います。 また、WASMの現在のMVP用バイナリエンコーディングに多くの改善を加えることに強く反対します。 そのままでいいのは約98％だと思いますが、最後の2％がなくても生きていけると思います。

@dschuff / @sunfishcode LLVMビットコードの長い議論はまだ関連していますか？ 特殊なバイナリエンコーディングの実行可能性は十分に証明されていると思います。そのため、LLVM、Java、および.NETの中間形式を単一のセクションで処理することで、1つの石で3羽の鳥を殺すことができました。

@Kardax申し訳ありませんが、「ASM.JSのパフォーマンスはWASMよりも優れている」と言ったのではありません。 しかし、たとえばAsm.jsには定数モジュール変数があり、これらをコンパイル済みコードにベイクすることができます。これは、wasmにはないものであり、非常に便利で、wasmで同様の機能を取得するには、モジュールを書き換えるユーザーコードが必要です。

グループは、wasmが「goodtogo」の2％以内であるという主張を客観的に評価するにはどうすればよいですか（それが意味するものは何でも）最高のパフォーマンス、最高のエンコードサイズ、最高のデコードおよびコンパイル速度など、最低のものを知っていますか？デコード-コンパイルリソースの使用量など？ 私たちはそれを個人的にしたくはありません。誰かが最もよく知っているわけではありません。そのような主張に対応することさえ非常に困難です。技術的なメリットで評価できる技術的なアイデアについて話す必要があります。

FAQ llvmの議論は私にとって価値があり、多くの良い点がありますが、それでも非常に関連性があり、個人的にはまだデザインスペースを調査しており、そのような理論的根拠が非常に役立つと感じています。

まだ実際に高性能なデコードとコンパイルの実装はありません。これらが設計の決定を最終決定するのに本当に役立つと思います。設計はさまざまな方向に進む可能性があると思います。 エンコーディングにはまだ非常に不完全な定義があります-レジスタ割り当てに必要な最終使用情報（スタックポップはこれらの一部を提供します）と私はライブセットがスピルアルゴリズムを実装するために必要であると期待しています、そしてそれらはで行うことができるより多くかもしれませんループなど。他にも多くの問題があります。デプロイメントパイプライン、および非常に重要な方法で設計を反転させる可能性のあるWebブラウザーオブジェクトとの統合です。

@Kardaxはい、少なくとも一部のオーディエンスにとって、

余談ですが、「実行可能性」と「完璧に機能する」とおっしゃっていますが、このレベルでは、これらは本質的に当然のことと見なされていることをお勧めします。 多くの種類のものが機能するように作られている可能性があります。 問題は、なぜ他の代わりに1つが選ばれたのかということです。

しばらくの間、これに関するPRはほとんどありません。 締めくくります。興味があれば修正するためにPRを提出してください。

私はまだこれがFAQに関連していると思います。

＃1061を開きました。

FWIW Microsoftの誰かが、実験としてWebAssemblyで実行されている.NETインタープリターを入手しました： https ：

https://github.com/appcypher/awesome-wasm-langs