カットアンドドライ...パフォーマンスのボトルネックになるほどの論理演算はありませんが、同じ名前の論理演算子ではなく、ビット単位と(&)およびビット単位または(|)を使用する方がよいのではないかと思います。 (&&および||)可能であれば?おそらく、質問の前に、操作の数を確認するためにJavaをアセンブリに変換するライブラリがわからないという事実があります。
8 に答える
ビット単位の演算子は、Javaコードの実行であっても、命令の分岐を回避します。その結果、高価な分岐予測のミスやジャンプはまったくありません。
私の経験から、十分な頻度で実行されるコードで使用すると、かなり高速になる可能性があります。ただし、ビット演算子は短絡演算子ではないことに注意してください。これは、場合によっては実際にパフォーマンスに悪影響を与える可能性があります。
とは言うものの、そのようなマイクロ最適化は最後の手段としてのみ使用されるべきであり、プロファイラーがそうするように指示した後でのみ使用する必要があります-読みやすさと保守性が最初になります。
Parleys.comでJoshBlochの「PerformanceAnxiety」の講演をご覧になることをお勧めします。http://www.parleys.com/#st=5&id=2103&sl=1
そのほとんどは、とにかくコンパイラによって最適化されるだけです。クイックGoogleは、Javaをアセンブラとして表示するためのこの便利なガイドを示しています。私は常に、CPU時間の数ナノ秒よりも、読みやすく、人間が読めるコードの方が重要であると考えてきました。
Javaは、JVMの追加レイヤーのおかげで、極端な速度を引き出すのに最適な言語ではありません。このような正確な最適化に関心がある場合は、C /C++などの別の言語に移行することをお勧めします。 このリストは、調べたい言語を示しています。
可能であれば、論理演算子ではなく、ビット単位と(&)およびビット単位または(|)を使用する方がよいでしょうか。
奇妙なことに、あなたはパフォーマンスについての雑学クイズから、実際にコードでそれを行うべきかどうかを尋ねることになりました。さて、2つ目は簡単です。いいえ。読みにくいコードを作成する開発者としてのコストは、CPUコストのナノ秒の違いを圧倒します。とにかくこれだけ最適化する必要がある場合は、CまたはC++を使用してください。
Javaコンパイラは、実際のマシンコードからかなり離れたバイトコードにコンパイルするだけです。それを行うのはJVMの責任であり、HotSpotのような最新のJVMはそれを行うのに非常に優れています。したがって、必要なことを実行する最も単純で明確なコードを記述します。
つまり、ほとんどの場合、違いを測定することはできません。
生成された実際のマシンコードを確認するには、JVMに表示を依頼する必要があります。これはベンダーによって異なります。
いいえ。
まず、論理演算子とは対照的にビット演算子を使用すると、エラーが発生しやすくなります(たとえば、1を右シフトすることは、2を掛けることと同じではありません)。第二に、パフォーマンス上の利点はごくわずかです(存在する場合)。
最後になりましたが、論理演算子を使用すると、意味がはるかによく伝わります。
たとえば100000ビット単位の演算で小さなプログラムを書いてみてください。タイマー関数を使用して実行時間を決定します。次に、論理演算に対して同じことを行います。それらを数回実行し、結果を確認してください。
シュレディンガーの猫のように、はい、同時にいいえ。
それはあなたが本当にしていることに依存します!私はかつて、ビット演算の有無にかかわらず数独ソルバーを実行しました。ここに私のベンチマーク:
- で:0.9ミリ
- なし:50ミリ
私はバックトラッキングアルゴリズムを使用していたので、数独はNP完全(おそらくNP困難)の問題であるため、ビット単位の操作で非常に高速であった理由がよく説明されています。
しかし、他の人がすでに言ったように、読んで維持するのは本当に難しいです(私は変更を加えるために数独ソルバーに戻ることは決してありません、私が何をしたのかどこかで理解できません)。
一般に、ビット単位の操作は他のどのソフトウェアよりも常に高速ですが、重要なソフトウェアのボトルネックでない限り、それ以外の理由で使用することはお勧めしません。