アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
Native Code?Client? (スコア:0)
Re: (スコア:3, 参考になる)
実はこれってアリなんじゃないかなぁ、と思います。Javaと比べてみると、最大のデメリットは、サーバー側のバイナリの量が増えることですが、オーサリングソフトがしっかりしていれば、あまり負担にはなりませんよね。ソース1つで[プラットフォーム数]倍のバイナリを吐くだけですし。実質的
Re:Native Code?Client? (スコア:1)
>完全にプラットフォーム依存なバイナリを送る
という点ですが
「Windowsでも、scons-out/nacl以下は同じで、Macと同様にFirefoxで問題なく表示できてますので、同一html/nexeでポータビリティありそうなのが確認できました.」
http://b.hatena.ne.jp/takuma104/20081209#bookmark-11220424 [hatena.ne.jp]
「takuma104さんのブコメ(引用者注：上の文章)によると、同じバイナリ (ELF フォーマット) が Mac でも Windows でもそのまま動いたとのこと。3.2 で書かれている、セキュア ELF ローダ (sel_ldr) とその先にあるランタイムで、プラットフォーム間の差異を吸収しているのでしょう。」
http://blog.deadbeaf.org/2008/12/09/google-native-client/ [deadbeaf.org]
という指摘がありますので「完全にプラットフォーム依存」なバイナリを送るものの、それを実行できないはずの環境でも「中間生成コード」のようになんとかして実行しちゃう技術なんでしょうか…？
とりあえず、いいたかったのは、どうもバイナリも(主要部分は)共通らしいということなんですが。
(でもランタイムみたいなものはやっぱりOSの数だけバリエーションかできるのか…。)
たしかに、x86マシン同士ではOSなどが異なっていても、同じことをするプログラムなら、マシン語レベルでも変わらない部分があるはずなので、その差さえ上手く吸収すれば動いちゃうってことなんでしょうけど。本気で、それを考えることがすごい。(で、それが正直どうなってるのか、いまいち分からないんですが…。)
でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。
Re:Native Code?Client? (スコア:1, 参考になる)
そのミニOS上のx86バイナリが共通だということです。
アイデアとしてはJavaからはっきり後退しているんですけども。
> でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。
その通りですが、APIもリッチのようです。