Safari、新JavaScriptエンジンSquirrelFishによりJavaScript高速化 24
ストーリー by Acanthopanax
栗鼠魚 部門より
栗鼠魚 部門より
あるAnonymous Coward 曰く、
Safariの基礎をなしているWebKitに新JavaScriptエンジンのSquirrelFishが組みこまれることにより、JavaScriptのパフォーマンスが飛躍的に向上、Safari3との比較では平均して４倍高速との結果がでているとのこと(マイコミジャーナルより)。SquirrelFishはJavaScriptを中間形式に変換し、実行時に高速実行可能なコードに変換して走らせることにより高速化を実現する。Firefox4でも同様のTamarinが組み込まれる予定で、JavaScriptはウェブアプリケーションの大黒柱として新たな段階に突入するとみられる。
実行速度は速くなるだろうが、結果として長いスクリプトが書かれ、ロード時間が延びたりしないか気になるところだ。
Surfin' Safariブログ記事“Announcing SquirrelFish”もご参考に。
しかし、こう立て続けに高速化技術が出てくるってのは (スコア:2, すばらしい洞察)
そうじゃなくて「JavaScriptがウェブアプリケーションの大黒柱として新たな段階に既に突入している」からこそ、こぞって開発を競ってるんだろうね。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:しかし、こう立て続けに高速化技術が出てくるってのは (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
ブラウザもJavaScriptも同じJVMで実行することができて、効率的！大発明！
あれ？既視感が…
http://ja.wikipedia.org/wiki/HotJava [wikipedia.org]
Re:しかし、こう立て続けに高速化技術が出てくるってのは (スコア:2, 参考になる)
作ろうというプロジェクトでJavaScriptエンジン作られたものだったはずです。
プロジェクト本体はぽしゃってRhinoだけが生き残ってますが…
Re: (スコア:0)
Re:しかし、こう立て続けに高速化技術が出てくるってのは (スコア:1, オフトピック)
いっそのことJIT載せちゃおうよ (スコア:2, 参考になる)
Googleとかのアプリも快適になるだろうなあ。
しかしいままで中間形式に変換してなかったのが逆に驚きだったりして。
FlashとかのActionScript(ECMA-262拡張)はなにかやってるのかな。
個人的には最近Processing [processing.org]というJavaベースの「電子アートとビジュアルデザインのためのプログラミング言語 [wikipedia.org]」で書いたコードをJavaScript上で動かすProcessing.js [ejohn.org]というライブラリで遊んでいるので、そういう意味でも高速化は大歓迎です。
（解説はこちらがわかりやすいです→ ブラウザでお絵描きプログラミング！ Processing.js 登場！ [hatena.ne.jp])
Re: (スコア:0)
今度は動的言語としての旨みが薄れませんかね？
「ここはいつ動的に差し替えられるか判らん」と備えるのを「諦める」のがJITですから。
単に高速にするだけならコンパイル言語で。
＃という目的でJavaAppletは出現したはずだったのだが…一体何処でどう間違えたのやら…
Re:いっそのことJIT載せちゃおうよ (スコア:2, 参考になる)
ほんとはおっしゃるとおり、JavaAppletを使うのが正しいとは思うのですが、
・プラグインを入れないと使えない(IEではプラグインをいれないと古い仕様のVMしか入っていない）
・起動に時間がかかる
といったことから避けられている節がありますね。
そんなことから、本来実体はJavaAppletであるprocessingをわざわざJavaScript上で動かしてみたりするわけで・・・
次のJava1.7ではJavaAppletの復権を狙っているようで、起動を高速化するなどいろいろ改良していくようです（起動高速化手法は、常に常駐しておくということなのですが・・・むー）。
でも、なんだかんだいって不特定多数向けのサービスを作るには、いまはJavaScriptかFlashですよねえ。
JavaAppletがんばれ！超がんばれ！
Re: (スコア:0)
>（起動高速化手法は、常に常駐しておくということなのですが・・・むー）。
一番大きいのは、Appletのプロセスがブラウザから分離されることかと、
ただ、それは、Java1.6のアップデートで狙っていますよ。6u10ビルドのベータが
公開されていてそれでは、新しいプラグインの利用が可能いなっています。
起動高速化は、prefetchが使われていて
あとは、肥大化したライブラリのモジュール化を行い
スリムにするという動きもあります。
言語間の戦いというより、言語のラインタイム環境の争いになってきた昨今、
なかなか面白い動きです。
Re:いっそのことJIT載せちゃおうよ (スコア:2, 参考になる)
私は JIT のプロじゃないんですが、以前 Tcl が ver. 7.x から 8.x にメジャーアップデートして、バイトコードコンパイラが採用された時に、自分のコードの実行速度をかなり詳細に追いかけたことがあります。この場合、コードの動的な部分が実行される際には、その部分だけ自動的に再コンパイルされることが分かりました。だから動的なコードは、静的なものに比べて速度的なメリットは少々失われますが、LL言語の「旨味」をすっかり諦めることにはならないと思います。速度が必要な時には静的なコードに書き直してチューンアップする余地は十分にあるのですから、JITによるデメリットはとても小さいと思いますよ。
Re: (スコア:0)
それこそ今回と同じように、演算パフォーマンスが10倍アップとか宣伝してます。
http://journal.mycom.co.jp/articles/2006/06/20/flash/001.html [mycom.co.jp]
ActionScriptも、タイムラインの制御とかスプライトの移動程度やってる分には困らないのですが、FlexのようにモダンなUIスイートを全部実装してActionScriptで動かすような世界でも使われるようになってるので、この辺は一応頑張ってるようです。
Tamarin は JIT 付き (スコア:0)
スクリプトから生成されたバイトコードをインタプリタで実行しつつ
プロファイルを取って、それを元に JIT でネイティブなコードに変換します。
（実際には中間処理が続々と入っていて、multi-pass 状態みたいですが）
すらどでもJavaScriptで遊んでいる (スコア:1)
例えばespyさん [srad.jp]の質点の運動で遊ぼうシミュレータ [espilab.ddo.jp]とか。
# それだけだけどid
/.configure;oddmake;oddmake install
高速化も良いけど (スコア:1, 参考になる)
喰っており、マシンが火を吹くように熱くなってた。
まぁ適材適所、つまりはprocessing.js全般を動かすにはまだまだ
改善が必要ってことなんでしょうけど。
Re:高速化も良いけど (スコア:1)
これで (スコア:0)