2

私は最近、JVM バイト コードに夢中になっており、2 つのオペランド Tload 命令ではなく、Tload_<n> 命令 (aload_0、aload_1、aload_2 など) を利用するようにパフォーマンス クリティカルなコードを再構築すると、かなりのパフォーマンス上の利点はありますか?

これはまさに「必要のないマイクロ最適化」のカテゴリに分類されますが、学術的な好奇心と考えてください。メソッドがそのローカル変数テーブルを 7 エントリ未満に保つことができる場合、どのようなパフォーマンス上の利点が (もしあれば) 明らかになるでしょうか? これにより、バイトコードがわずかに小さくなる可能性があると考えています。

バイトコード レベルの最適化に関する読み物への質の高いリンクに対するボーナス ポイント!

4

1 に答える 1

5

短いロードが存在するのは、主に Java バイトコードの本来の目的のためです。もともとこの言語はセットトップ ボックス用に設計され、可能な限りコンパクトに作成されていたため、RAM/ROM を節約するために、頻繁に使用される命令の特別な短いバージョンを用意する価値があると考えられていました。

また、インタープリターには、組み込みの必要なオフセットを使用してインタープリター ルーチンを個別にコーディングできるというわずかなパフォーマンス上の利点もあります。

ただし、JITCed コードでは違いはありません。すべての op が同じロジックに折りたたまれ、短いオフセットに対して短いマシン命令を利用する可能性がありますが、短いバイトコードと同じ境界ではありません。

于 2013-03-15T01:28:03.263 に答える