パスワードを忘れた? アカウント作成
203558 story
テクノロジー

Google、x64やARM向けの「Native Client」を開発 35

ストーリー by hylom
「マルチプラットフォームなActiveX」が現実に近づく 部門より

Googeは以前から「Native Client」と呼ばれる、ブラウザ上でx86のネイティブコードを実行できる技術を開発していたが、そのx86-64/ARM版も開発していることが発表された(The Chromium Blogの記事)。

ネイティブコードは速度の面で優れているが、自由度が高いため悪意のあるプログラムを作成できるという危険性もある。そのためNative Clientでは、Software Fault Isolation(SFI)と呼ばれる機構を用い、サンドボックス化された環境内でバイナリを実行することでセキュリティを高めている。これによりパフォーマンス低下が発生するものの、Googleはこれに対し独自の技術を開発、パフォーマンス低下を最小限(ARMで3%、x86-64で10%程度)に抑えることに成功したという(論文PDF)。

また、いまのところx86版のNative Client向けに作成されたコードをx86-64やARM版のNative Clientで動作させることはできないが、これを改善するため「Portable Native Client Executables(PNaCl)」という技術の開発も進めているという。PNaClではLow-Level Virtual Machine(LLVM)で用いられる中間コードを使用した「ポータブル」なバイナリでプログラムを配布し、実行時に各CPUのネイティブコードに変換するというもの。これにより、Native Clientの高速性とセキュリティを保ちつつ、単一のバイナリで複数のプラットフォームに対応できるという(GoogleによるPNaClのドキュメント[PDF])。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2010年03月20日 16時50分 (#1736162)

    「ブラウザ上で」の部分に何か意味はあるのか?

    • by Anonymous Coward
      ここで考えないといけないのは、Googleにとって意味があるかどうか、じゃないかな。
  • by Anonymous Coward on 2010年03月20日 17時02分 (#1736171)
    Silverlight 等とどう棲み分けるんでしょうか。
  • by Anonymous Coward on 2010年03月20日 17時08分 (#1736174)

    >いまのところx86版のNative Client向けに作成されたコードをx86-64やARM版のNative Clientで動作させることはできないが、
    >これを改善するため「Portable Native Client Executables(PNaCl)」という技術の開発も進めているという。

    Javaにしとけ

  • by Anonymous Coward on 2010年03月20日 18時14分 (#1736223)
    他の方も言われているように、Javaで十分な気がするのですが
    これの利点って何なのでしょうね。
    Nativeで動くといっても、デバイス直接触ったり出来るわけではないでしょうし。

    日本なら、「車輪の再開発」といわれるのがオチでしょうが
    選択の幅が広がるのは良いことですね。

    けど、クライアントのブラウザ上で速度が必要な処理…。
    FPSとか音声・動画像処理?

    思いついたのは、分散コンピューティングをブラウザ上でやる。
    空いてるクライアントで、webページにアクセスするだけで、参加できるとか。
    あっでもJavaでもできなくないな。
    • 他の方も言われているように、Javaで十分な気がするのですが
      これの利点って何なのでしょうね。
      Nativeで動くといっても、デバイス直接触ったり出来るわけではないでしょうし。

      動画CodecとかDRMにつきものの暗号化・復号化って年々重くなっていますよ。
      この手のものは、x86_64で高速な機械ならまだしも普通のパソコンや組み込み用途でJavaなどで実装するのは些か無謀だと思います。ARMやia32を入れてるのは明らかにゲーム機や携帯電話などの組み込み市場を意識してる訳で。

      それだったらプラグインにすればいーやん…となりがちですが、プラグインにするとクライアントの機械にコードを残すハメになる。
      システム構成によっては再起動すら必要になる。
      プラグインをワンタイムで失効させる事も不可能ではないですが、上記のビジネスリスクを考えるとワンタイムのコード実行のフレームワークを新たに作る方がベターと考えたのでしょう。
      プラグインの形でフレームワークを配布しておけば、アプリ自体をネットから読み込んで実行して完全に捨ててしまうワンタイム実行が可能になる。

      # 当然、Javaや.NETの市場を食い荒らそうという意図もあるでしょうが。
      ネットから読み込んだネィティブコードをワンタイム実行させて、処理が終わったら自動的に破棄する。
      ある意味理想的なDRMになるように思いますが。
      但し、個人的にはそういう個人がプログラムコードやコンテンツを所持して保管も二次利用もできない環境などクソ喰らえ。と思いますが

      親コメント
    • by Anonymous Coward
      > 他の方も言われているように、Javaで十分な気がするのですが

      Java等の安全なVMでは、Cのようななんでもありの言語を実行することができませんから新規に作るしかないわけです。
  • by Anonymous Coward on 2010年03月20日 18時32分 (#1736231)

    > ポータブルなコードを実行時にJITでネイティブコード

    なんでこんな何番煎じか判らんようなことを今更するのか誰か教えて。
    素直にJavaか.NETではなぜいけないのか?

    GoogleはNIH症候群にかかってる。自社で使えばシェアが一定まで
    取れてしまうことから誰も止められないという状態にしか見えない。

    • Re:わからん (スコア:4, 興味深い)

      by leiqunni (8779) on 2010年03月20日 19時29分 (#1736251) ホームページ 日記

      多くの同一意見が書かれてますがここに。

      対抗馬はJavaではなくてActiveXなのでは。
      そして何故開発するのかと言えば技術のコントロールを自分のものにするためであり、
      Googleは別に自社で使うために開発してるだけで、
      気前がいいからオープンソースにしてるだけで、
      なんか外野が「車輪の再発明」とか「シェアがどうこう」言ってるのは見当違いのような。

      それにその名の通り「ネイティブ」なのが速さが重要であって、
      参考文献Android NDKを使用してJava言語とC言語で速度比較をする [techfirm.co.jp]

      親コメント
      • by WindKnight (1253) on 2010年03月21日 7時15分 (#1736400) 日記
        Android の JVM って、JIT コンパイラを持っているんだろうか?
        まあ、ChromeOS の JVM が JIT コンパイラを持っていないという話かもしれませんが。
        親コメント
      • by Anonymous Coward
        Chrome OSで使うんでしょうね
      • by Anonymous Coward

        このNative Client使えばWindows APIとかハードウェアを
        直接叩けるってことか。プロセッサだけじゃなくて対象OS毎に
        準備するなんてGoogleもマゾいねw

        • by Anonymous Coward
          極論にマジレスするのもなんですが、(グーグルにとって)必要十分にメガリッチなAPIが定義されているでしょう。
      • by Anonymous Coward
        >そして何故開発するのかと言えば技術のコントロールを自分のものにするためであり、
        >なんか外野が「車輪の再発明」とか「シェアがどうこう」言ってるのは見当違いのような。

        Googleの検索以外の大半の労力はMS, 最近ではApple, Firefox, Linuxから客を引っぺがす為に割かれてるのは明らかだよ。
        良いとか悪いとかはさておき。

        個人的にはブラウザなんて狭苦しい窓枠に拘泥するアプリ、サービスは嫌いだな。使いにくいにもほどがある。
        こういう頑張り方はあまり歓迎しない。
        • by Anonymous Coward
          > Googleの検索以外の大半の労力はMS, 最近ではApple, Firefox, Linuxから客を引っぺがす為に割かれてるのは明らかだよ。

          グーグルはOSのシェアなんて気にしてないと思う。
          ブラウザのシェアもいらないんじゃない?
          クロームは、競争と進化を止めていたブラウザとJavascriptの速度を
          活性化させるのが第一目的っぽいし。

          OSは、グーグルが提供するサービスを必要十分に満たして、隅々まで
          インフラとして機能すれば、どこの会社のでも良いけど、グーグルの
          サービスに支配的な圧力をかける可能性がある場合は、「客に具体的な
          例を示すた
    • by Anonymous Coward

      >> ポータブルなコードを実行時にJITでネイティブコード

      どちらかというと、C/C++のコードをブラウザ上で、という側面のほうが重要ではないでしょうか。
      ffmpegとか、音声認識とか。

  • by Anonymous Coward on 2010年03月20日 19時48分 (#1736260)

    みんなJavaと比較してるの?これの対向ってActiveXじゃないの?

    触りもしないであーだこーだ言うのはまあ許せるとしても、最近のアンチgoogleの
    脊髄反射っぷりは某信者真っ青の思考停止っぷりですなぁw

    無理やりjavaを絡めるならjava appletだと思うが今のappletが使い物に
    ならない理由を考えればnative clientが「無意味」であるという結論にはならんと思うが

    • by Anonymous Coward
      信者が街にやってきたよ

          NaCl   Java  ActiveX
      速度   ○    ×    ○
      安全性  ◎    ○    ×
      移植性  ○    ○    ×
      豊富API ◎    ×    ◎
      • by Anonymous Coward

        NaClってネイティブ動作だけどサンドボックス内部で動くから、システム内部にアクセスできるわけじゃないですよね。
        多分、GUIも実現できないんじゃないのかな?
        API豊富の◎はせいぜい○では、とマジレス。

    • by Anonymous Coward
      目指してるのは JavaScript/Flashの置き換えじゃないですかねぇ。
      表示方面はWebGLとかで高速化してるんだから、制御側もそれに追いつこうとするのは必然でしょう。
  • by Anonymous Coward on 2010年03月20日 21時48分 (#1736309)

     トランスメタが作っていたクルーソーが発展していれば、
    ・並列動作対応
    ・セキュアな環境
    ・実行速度
     の全てが解決できたかもしれないのにな……。

  • by Anonymous Coward on 2010年03月21日 3時53分 (#1736387)
    LLVM(でなくてもいいのだろうけど)の中間コードの難読化ツールってあるのかな?
    • by Anonymous Coward
      Java1.1ぐらいの頃にはすでにありましたよ。オブファスケーターといいます。難読化ついでに最適化もしてくれる便利ツールで、携帯アプリプログラマ必携でした。
  • by Anonymous Coward on 2010年03月22日 13時32分 (#1736766)
    Nativeのコードを速く手軽に安全にブラウザ上で動かそうぜって根本が揺るいでる気が…

    ぐぐるって社内の技術者が作ったおもしろそうなものとりあえず出す習慣があって
    本気なのかどうなのか分かりかねる
typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...