ここ数年ほとんどウェブアセンブリのことを調べたことは無かったが、ウェブアセンブリが結局JIT使うなら、おれが望んでいたものとだいぶ違うな。Ahead of Time コンパイルで最初から直接動くコードを読み込んで最速を目指すのがそれの目的かと思ったら、JavaScriptの構文解析のコストを下げるだけで終わってしまうのか。ブラウザから直接マシンコード読み込んで動かすことのなにがいけないのだろうか。<script src=xxx.js> のかわりに <exec code=x86:xxx.dll,armv8:xxx.armv8.so> みたいな感じで。サーバーで長々と動かすソフトウェアならゆるゆる最適化、実行中にコードを並び替えるのもいいかもしれないが、端末でそれやると非効率だ。
WebAssemblyが普及したら (スコア:1)
Re: (スコア:0)
ここ数年ほとんどウェブアセンブリのことを調べたことは無かったが、ウェブアセンブリが結局JIT使うなら、おれが望んでいたものとだいぶ違うな。Ahead of Time コンパイルで最初から直接動くコードを読み込んで最速を目指すのがそれの目的かと思ったら、JavaScriptの構文解析のコストを下げるだけで終わってしまうのか。ブラウザから直接マシンコード読み込んで動かすことのなにがいけないのだろうか。<script src=xxx.js> のかわりに <exec code=x86:xxx.dll,armv8:xxx.armv8.so> みたいな感じで。サーバーで長々と動かすソフトウェアならゆるゆる最適化、実行中にコードを並び替えるのもいいかもしれないが、端末でそれやると非効率だ。
Re:WebAssemblyが普及したら (スコア:0)
ブラウザから直接マシンコード読み込んで動かすことのなにがいけないのだろうか。<script src=xxx.js> のかわりに <exec code=x86:xxx.dll,armv8:xxx.armv8.so> みたいな感じで。
Google NaClがそんな感じの仕組みだった。だから、NaCl→pNaCl→WebAssemblyの流れを調べれば、その疑問の答えが分かるのではないかと予想している。誰か調べて教えてほしい。
Re: (スコア:0)
アーキテクチャが増えるたびに誰がどうメンテするのって話になるのでしょう。
だから、pNaClの時点で中間コードになった。
今でもx86,x64,ARM,MIPSがあるし、RISC-Vとかも多分要考慮。
x86/64と一口に言ってもSSEやAVXとか環境によってサポート具合が異なる。
しかも、サイト側がユーザーのアーキテクチャ向けのバイナリを用意しなければ動かない。
バイナリなし環境でも動くように救おうとしたら、アーキテクチャ分ののバイナリ変換プログラムの保守が必要になって、テストは指数関数的に増える。
そんな面倒な事やってられねーので、今の形になったと思う。