"自動化された知性は速い。だが、構造を深く読むのは、依然として人間である。"
プログラミングにおける最適化は、かつて「書き手」の責任だった。
だが現代では、コンパイラの最適化機能が進化し、もはや人間が介入すべき領域はないとさえ言われる。
それは本当か？
この章では、「最適化とは何か」を問い直しながら、
コンパイラが行う機械的な変形と、人間が行う構造的な洞察の差異を、
アセンブリコードの観点から深く検証する。
コンパイラの最適化とは何か？
現代のコンパイラ（GCC、Clang、MSVC）は、複数の段階にわたる最適化を行う：
- 定数畳み込み（constant folding）
- デッドコード削除（dead code elimination）
- ループ展開・融合（loop unrolling/fusion）
- 関数インライン化（inlining）
- レジスタ割当と命令再配置（scheduling）
例：
int x = 3 * 4;
→ mov eax, 12 に変換される。
しかしこの最適化は、「知っていることだけ」に対してしか作用しない。
人間の最適化とは何か？
人間による最適化は、単に「書き換える」ことではない。
それは：
- 実行される構造の“意図”を解釈し直す
- 対象ハードウェアの“癖”を考慮に入れる
- 未来の拡張、可読性、動的性質を見据えて調整する
例：256回の加算処理を shl eax, 8 に変換する。
コンパイラが安全性のために避ける変換でも、
人間はその「意味」と「境界」を文脈で評価して切り替えられる。
アセンブリがその差異を可視化する
Cレベルでは等価に見える以下のコード：
int y = (a * 256);
最適化なし：
mov eax, a
imul eax, eax, 256
-O2以降：
mov eax, a
shl eax, 8
だが、aがsigned overflowする可能性や、CPUが特定の命令セットを持たない場合、
コンパイラはこの変換を見送る可能性がある。
→ 人間は、この“コンパイラが避ける設計の迷い”に対して意図的に介入できる。
コンパイラが不得意とする最適化
| パターン | 人間が優れる理由 |
|---|---|
| メモリアクセスの局所性最適化 | キャッシュラインを意識したデータ構造の再設計が可能 |
| ループの意味的再構成 | 繰返し条件そのものの見直しができる |
| アーキテクチャ依存の命令活用 | CPU固有命令（e.g. LZCNT, MULX）を明示的に挿入できる |
| 複数関数に跨る意味的統合 | コンパイラは「関数間」を越えられないことが多い |
→ 結局、コンパイラは**「局所的な効率化」に強く、**
人間は**「構造的な合理性」への再設計に強い。**
では、両者は競合するのか？
否。理想は協調である。
- 人間が意図的に最適化しやすい構造を記述し、
- コンパイラが低レイヤで最適命令列に再構成する
→ その境界は「高級言語としての記述最適化」と「機械としての実行最適化」に分かれる。
人間が手動最適化すべきタイミングとは？
以下のような条件が揃うと、手動最適化の正当性が増す：
- ボトルネックが明確かつ頻繁に再現可能（プロファイラで確認）
- 特定のCPU/アーキテクチャに特化した環境（embedded, game console）
- リソース制限が極端に厳しい場合（bootloader, firmware）
- サイズや速度が芸術的要素として求められる（デモシーン, 競技）
未来における最適化の役割
LLMやAIコンパイラが台頭しても、
「何が速いか」ではなく、「何が適切か」を決定する判断基準は依然として人間に依存する。
- AIは無限に近いバリエーションを出力できるが、
- その**“選択基準”を設計するのは依然として開発者の責任**
→ 人間の最適化は「命令列の書き換え」ではなく、
設計構造への倫理的介入へと進化する。
結語：最適化とは、構造への対話である
コンパイラは速い。だが、意味を解釈しない。
人間は遅い。だが、意味を読解し、意味で構造を変えることができる。
最適化は、数値で測るものではない。
それは構造をどこまで愛せるかという、設計者の態度と選択の集積である。
"最適とは、最小の実行ではなく、最大の意図が通る構造である。アセンブリはその意図を剥き出しにする最後の場である。"