http://blog.deadbeaf.org/2008/12/09/google-native-client/
http://d.hatena.ne.jp/ranha/20081210
http://q.hatena.ne.jp/1228948862#comment[話題]
Native Clientは現在のところx86のバイナリをブラウザベースで実行できる。
「C/C++で書いたコードに対してどうやればsandbox環境を提供できるのか?」
について興味のある人も多いと思う。そもそもそんなことが技術的に可能なら、docomoはFOMAシリーズにCPUリソースを
食いまくるJavaなんて搭載しなかっただろうし、auだってBREWなんて採用しなかったかも知れないし、
Android携帯にしてもJavaなんかではなくC/C++で書かせてくれたほうが
よっぽど処理速度面においてiPhoneに対抗出来たはずだ。
Native Clientの仕組みはすこぶる単純だった。
見た通り、仮想化に取り組んでいる人には当たり前のテクニックだろう。
ええと、つまり?
……ということなのかな?
(仮想マシン) (一部仮想命令) (全部実命令)
安全性:Java, dotNet >= NativeClient > NativeCode
速度 :Java, dotNet < NativeClient <= NativeCode
仮想化に取り組んでいる人には当たり前のテクニックだということなら、なぜ今までわざわざ仮想マシンを間に挟んでいる実装しか無かったのかというのが疑問だ。
(確かに、1種類のCPUに依存する仮想環境とか泥臭い気はするけど)
あと、NativeClientはあくまでもx86のネイディブコードを動かすためのものなので、
「どんな機械の上でも動くコード」ってのが不可能だという点がデメリットか。携帯電話/端末は
ともかくとして、組み込み系とかは技術思想的に最初から対象外。
でもやっぱり
http://blog.deadbeaf.org/2008/12/09/google-native-client/
Native Client が流行るかといわれるとそうでもないかなーと思うんですが、
やはり Google のインフラ技術はおもしろいですね。
とか言われてる。
私も微妙とか言ってたけど、NativeClientからグラフィックボードの機能を使えるなら、マルチプラットフォームの3Dゲーム動作環境として幅を利かせることが出来るかも。
練習問題: Gears との関係は?Gearsは黒歴史ということで、忘れよう。