12

研究プロジェクトの準備として、機能の調査を行っています。

最適化するのが難しい主流の言語または言語機能に名前を付け、その機能が支払った価格に見合う価値がある、または価値がない理由を挙げてください。あるいは、事例証拠を使って以下の私の理論を暴くだけです。誰かがこれを主観的なものとしてフラグを立てる前に、言語や機能の具体例、これらの機能の最適化のアイデア、または私が考慮していない重要な機能を求めています。また、私の理論が正しいか間違っているかを証明する実装への参照。

最適化が難しい機能と理論のリストのトップ(私の理論のいくつかはテストされておらず、思考実験に基づいています):

1)ランタイムメソッドのオーバーロード(別名マルチメソッドディスパッチまたは署名ベースのディスパッチ)。ランタイムの再コンパイルやメソッドの追加を可能にする機能と組み合わせると、最適化するのは難しいですか。それとも、とにかく難しいですか?コールサイトのキャッシュは、多くのランタイムシステムで一般的な最適化ですが、マルチメソッドを使用すると複雑さが増すだけでなく、インラインメソッドの実用性が低下します。

2)タイプモーフィング/バリアント(変数ベースではなく値ベースのタイピング)基本ブロックで何かのタイプが変更できるかどうかわからない場合、従来の最適化は単純に適用できません。マルチメソッドと組み合わせると、インライン化は慎重に行う必要があります。おそらく、呼び出し先のサイズの特定のしきい値に対してのみ行う必要があります。すなわち。単純なプロパティフェッチ(ゲッター/セッター)のインライン化を検討するのは簡単ですが、複雑なメソッドのインライン化はコードの膨張を引き起こす可能性があります。もう1つの問題は、型情報を持ち歩く必要があるため、またはすべての変数に1ではなく2つのレジスタが必要なため、レジスタにバリアントを割り当ててネイティブ命令にJITすることができないことです。IA-32では、これは不便です。 x64の追加レジスタで改善されました。これは、プログラマーの観点から非常に多くのことを単純化するので、おそらく動的言語の私のお気に入りの機能です。

3)ファーストクラスの継続-それらを実装する方法は複数ありますが、私は最も一般的なアプローチの両方でこれを行いました。1つはスタックコピーであり、もう1つは継続渡しスタイル、サボテンスタック、コピーオンライトスタックフレームを使用するランタイムを実装する方法です。とガベージコレクション。ファーストクラスの継続には、リソース管理の問題があります。継続が再開された場合に備えて、すべてを保存する必要があります。「意図」を持って継続を残すことをサポートしている言語があるかどうかはわかりません(つまり、「私はここに戻ってこないので、この世界のコピーを破棄してもかまいません」 )。スレッドモデルと継続モデルでプログラムしたので、どちらも同じことを達成できることはわかっていますが、継続は エレガンスはランタイムにかなりの複雑さを課し、キャッシュの効率にも影響を与える可能性があります(継続とコルーチンを使用すると、スタックの局所性がさらに変化します)。もう1つの問題は、ハードウェアにマップされないことです。継続を最適化することは、あまり一般的でないケースを最適化することであり、私たちが知っているように、一般的なケースは高速であり、あまり一般的でないケースは正しいはずです。

4)ポインタ演算とポインタをマスクする機能(整数での格納など)これを投入する必要がありましたが、実際にはこれがなくても簡単に生活できました。

私の気持ちは、特に動的言語の高レベルの機能の多くは、ハードウェアにマッピングされていないということです。。マイクロプロセッサの実装には、チップ上の最適化の背後にある数十億ドルの研究がありますが、言語機能の選択により、これらの機能の多くが無視される可能性があります(キャッシング、レジスタへのスタックのトップのエイリアシング、命令並列処理、リターンアドレスバッファ、ループなどの機能)バッファと分岐予測)。マイクロ機能のマクロアプリケーションは、一部の開発者が考えるように必ずしもパンアウトするわけではなく、VMに多くの言語を実装すると、ネイティブopsが関数呼び出しにマッピングされることになります(つまり、言語が動的であるほど、ルックアップする必要があります/実行時にキャッシュするため、何も想定できないため、命令の組み合わせは、従来よりも高い割合の非ローカル分岐で構成されています。静的にコンパイルされたコード)そして私たちが本当にうまくJITできる唯一のことは、非動的型の式評価と定数型または即時型の操作です。このため、バイトコード仮想マシンとJITコアが特定の言語に対して常に正当化されるとは限らないというのが私の直感です。

私はあなたの答えを歓迎します。

4

2 に答える 2

5

いくつかのコメント:

  • 単一のオブジェクトに基づいていても、動的ディスパッチを使用するすべての言語は、効率的に実装するのがかなり難しいようです。Self (または最近では、SpiderMonkey を使用した JavaScript) の実行時の最適化に費やされたすべての努力を見てください。

  • 区切られた継続を見逃さないでください。判断はまだ下されていませんが、古典的な区切りのない継続よりも最適化がはるかに簡単です。Gasbichler と Sperber による論文を読んでください。

于 2010-03-24T23:26:49.780 に答える
1

このため、特定の言語ではバイトコード仮想マシンと JIT コアが常に正当化されるとは限らないというのが私の直感です。

IronPython は、仮想マシンが言語 (Python) のネイティブ実装と同様に機能しないことを証明するために作成されたものではありません。そして、IronPython の作成者は、IronPython がバイトコード VM 上の動的言語に対して非常に優れたパフォーマンスを発揮することを発見したとき、かなりショックを受けましたか?

Microsoft 自身の .Net 内部グループは、最終的には JITter が「通常の」コンパイラ/リンカー (C/C++ など) よりも優れていると考えていると述べていることを記録に残しています。

陪審員はまだこれについて出ていないと思います。どちらとも言い難い。仕事に最適な言語を選択してください...

于 2010-03-24T23:40:55.963 に答える