ここ数年ほとんどウェブアセンブリのことを調べたことは無かったが、ウェブアセンブリが結局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)
コードをあんまり具象化すると、AMDの拡張命令が使えるかとかAppleのSoCのコプロセッサが使えるかどうかとか
判定をsoやdllの中で網羅していかないといかなくて不便な気がする。
(既存のコード資産は、判定をsoやdllまで持ってきてるのもあれば、#ifdefなんかで落ちるのもあるんじゃない)
コードの中で判定するのは人手がかかるし、ファットバイナリは簡単だが通信量が増える