オプティマイザーは、空間的局所性の悪用を取り除くことができますか？私は他の誰かによって書かれたコードを維持しています、そしてそれらの配列の多くは無計画な順序で宣言され、それらが呼び出されるたびに異なって繰り返されます。
コードが複雑なため、アレイが循環するたびに再管理を試みるのはかなりの時間のブロックになります。私はアセンブリ言語を読むのに十分なスキルがなく、さまざまなレベルの最適化で何が違うのかを正確に伝えることができませんが、私の質問は、
プログラムを書くときに局所性は重要ですか、それともそれが最適化されて心配できないのですか？
ローカリティを正しく取得することは重要です。これは、実行時に2桁の違い（ページフォールトがある場合は5〜6桁）の違いを生む可能性があるためです。
（Joel Falcouが言ったように）実際のコンパイラーは通常これを自動的に処理しないという事実は別として、架空のコンパイラーでさえそのようなことをするのに非常に苦労するでしょう。多くの場合、コンパイラがそのようなことを行うことは有効でさえないかもしれません、そしてそれがいつであるか、そうでないかを予測することは非常に困難です。
たとえば、CPUで計算し、OpenGLやDirectXなどのグラフィックAPIにアップロードする頂点データがあるとします。そのAPIに特定の頂点データレイアウトに同意しました。これで、コンパイラーは、何らかの方法でレイアウトを再配置する方が効率的であると判断しました。バン、あなたは死んでいる。
コンパイラはどのように知っているはずでしたか？
いくつかの配列といくつかのポインターがあり、いくつかのポインターが他のポインターをエイリアスしている、またはいくつかのポインターが何らかの理由で配列の中央を指している、他のポインターが最初を指しているとします。コンパイラーは、特定の操作を異なる順序で実行し、ある結果を別の結果で上書きする方が効率的であると考えています。
データ破損の問題はさておき、これらの配列が「やや大きい」としましょう。そのため、スタック上にあるのではなく、動的に割り当てられることが最も確実です。つまり、それらの開始アドレスは、コンパイラーの観点からは「非決定論的」または「ランダム」ですらあります。コンパイラは、コンパイル時に、詳細の半分を知らずに、どのように決定を下すのでしょうか。
局所性のためにデータレイアウトを処理するコンパイラはほとんどありません。それはまだ活発な研究領域です。