Changes between Version 1 and Version 2 of Introducing SquirrelFish Extreme.ja


Ignore:
Timestamp:
Sep 19, 2008 7:34:50 AM (14 years ago)
Author:
omo@dodgson.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Introducing SquirrelFish Extreme.ja

    v1 v2  
    1 This page is a Japanese translation of the post on Surfin' Safari blog
    2 "Introducing SquirrelFish Extreme".
    3 
    4 ----
     1[[PageOutline]]
    52
    63= この文書について =
     
    107 * 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか...
    118
    12 = SquirrelFish Extreme の紹介 =
     9= SquirrelFish Extreme を紹介します =
    1310
    1411ちょうど三ヶ月前、私達は SquirrelFish を発表しました。
     
    3633出て一年も経たない Safari 3.0 の 10 倍も高速です。
    3734私達はこうした改善を大変嬉しく思います。
    38 しかしこの先の更なる改善も確信しています。
     35しかしこの先の更なる改善を確信してもいます。
    3936
    4037かなりの数の人々がこの成果に貢献してくれました。
    4138以下では重要な仕事をした何人かに言及しますが、
    42 JavaScript や性能の面で協力してくれた WebKit のコントリビュータ皆に
     39JavaScript や性能の面で協力してくれた WebKit コントリビュータの皆に
    4340感謝したいと思います。
    4441
     
    5855
    5956私たちがやったことの一つは、オプコード内での最適化です。
    60 JavaScript の操作にその多くに高い多態性があります。
    61 様々な場合にによって様々に振舞いを変えるのです。
     57JavaScript の操作はその多くが高い多態性を持ちます。
     58様々な場合に応じ様々に振舞いを変えるのです。
    6259単に一番よくある、最速の場合を先にチェックするだけで、
    6360JavaScript のプログラムはかなり高速化できるのです。
     
    7471他の JavaScript エンジンで採用され良い効き目を出しています。
    7572
    76 基本的な考え型はこうです: 言語設計の上では、JavaScript は極めて動的あ言語です。
    77 しかし大半のプログラムでは、実際のところ多くのオブジェクトが
    78 オブジェクト指向のクラスのようにもう少し構造のある使われ型をしています。
    79 たとえば、多くの JavaScript ライブラリは 「x]と「y」というプロパティのある
    80 オブジェクトを使う作りになっています。このオブジェクト他のプロパティを持たず、
     73基本的な考え方はこうです: 言語設計の上では、JavaScript は極めて動的な言語です。
     74しかし大半のプログラムでは、実際のところ多くのオブジェクトが
     75オブジェクト指向のクラスのような、もう少し構造のある使われ方をしています。
     76たとえば、多くの JavaScript ライブラリは 「x]と「y」というプロパティをもつオブジェクトを
     77使う作りになっています。このオブジェクト他のプロパティを持たず、
    8178点を表現するのに使われます。多くのオブジェクトが同じ構造に基いているなら、
    8279こうした知識を最適化に使うことができます。
     
    8481
    8582では、どうやってインチキをすればいいのでしょうか?
    86 私達はオブジェクトが同じ構造を持つこと...順序の同じプロパティがあること...を検出します。
     83私達はオブジェクトが同じ構造を持つこと...同じ順序で同じ名前のプロパティがあること...を検出します。
    8784そしてオブジェクトに構造の識別子 StrucureID を割り付けます。
    8885プロパティアクセスがおこると、初回はまず普通に(超高速のハッシュテーブルを使い)ハッシュ検索をします。
    8986そしてプロパティをみつけた場所に StructureID とオフセット値を記録しておきます。
    9087それ以降のアクセスでは StructureID の一致をチェックします - 
    91 ふつう同じコード片は同じ構造を持つオブジェクト相手に使われるものなのです。
     88ふつう同じコード片は同じ構造を持つオブジェクト相手に使われるものです。
    9289チェックに成功したらキャッシュしておいたオフセットを使い、わずか数命令で検索を行うことができます。
    9390これはハッシュ検索よりずっと高速です。
     
    10097
    10198私達の施したインラインキャッシュは、まだはじめの一歩です。
    102 更なる高速のためにこのテクニックを改善するアイデアが沢山あります
     99更なる高速のためにこのテクニックを改善するアイデアが沢山あります
    103100とはいえ、プロパティアクセスがボトルネックであるような性能テストでは、
    104 現状で劇的な改善を見ることができるでしょう。
     101現状で劇的な改善を見ることができるでしょう。
    105102
    106103== 3. コンテクトスレッド JIT ==
     
    118115バイトコードを 1 オプコード毎にネイティブコードに変換するというものです。
    119116複雑なオプコードは言語のランタイムに対する関数呼びだしになります。
    120 単純なオプコードや、複雑なオプコードのうち高速に実行できるパスは
    121 ネイティブコード列へ直接差し込まれます。まず、オプコード間の制御フローは
    122 直線的なコードとなって CPU に差し出されます。したがってディスパッチのオーバーヘッドはなくなります。
     117単純なオプコードや、複雑なオプコードのうち高速に実行できるパスは、
     118ネイティブコード列へ直接差し込まれます。
     119まずオプコード間の制御フローは
     120直線的なコードとなって CPU に差し出されます。
     121したがってディスパッチのオーバーヘッドはなくなります。
    123122次にもともとオプコードの間にあった多くの分岐はインライン化されます。
    124123これは CPU の分岐予測器にとって大変予測しやすいコードになるのです。
     
    128127ここ数週間でそれをチューニングし性能を磨きあげるのには、何人もが手を貸しています。
    129128
    130 私達の量 JIT がもつ優れた点の一つは、ネイティブコードの生成に
     129私達の量 JIT がもつ優れた点の一つは、ネイティブコードの生成に
    131130わずか 4000 行のコードしか使っていないところです。
    132131コードの他の部分はクロスプラットフォームのままです。
     
    158157一年前、テストに占める正規表現の割合はとても小さなものでした。
    159158そして各 JS エンジンは正規表現以外の改善を大いに進めました。
    160 たとえば個々の SunSpider のテストひとつのの結果 JavaScriptCore より 5 から 10 倍高速で、
     159たとえば個々の SunSpider のテストひとつのの結果 JavaScriptCore より 5 から 10 倍高速で、
    161160Safari 3.0 版の WebKit より 70 倍速いなんてものもありました。
    162161しかし今日まで、正規表現の性能はほとんど改善されてこなかったのです。
     
    215214
    216215追記2:
    217 私達のちいさなマスコットに不満のは、下の SquirrelFish をクリックすると
     216私達のちいさなマスコットに不満のは、下の SquirrelFish をクリックすると
    218217WebKit ナイトリーの SVG アニメーションサポートを見ることができます。
    219218