回答編集履歴
1
update
answer
CHANGED
|
@@ -8,4 +8,23 @@
|
|
|
8
8
|
|
|
9
9
|
演算回数がひとつの目安であることは否定しませんが、モダンなCPU・OS・コンパイラによる実行環境下ではあまり大きな性能要因とはならないことが多いです。ループ展開の意義を議論するようなケースでは、C++ソースコードレベルの議論ではほとんど意味が無く、コンパイル後の生成アセンブリコードを確認する必要があるでしょう。
|
|
10
10
|
|
|
11
|
-
ループ展開に関連する性能要因は、CPU動作レベル（＝CPU命令＋実行時の様子）での分岐予測の状況、データキャッシュミス、命令キャッシュミス、命令レベル並列実行(IPC=Instruction Per Cycle)といった観点で議論されるものです。
|
|
11
|
+
ループ展開に関連する性能要因は、CPU動作レベル（＝CPU命令＋実行時の様子）での分岐予測の状況、データキャッシュミス、命令キャッシュミス、命令レベル並列実行(IPC=Instruction Per Cycle)といった観点で議論されるものです。
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
**追記**
|
|
15
|
+
|
|
16
|
+
> どんなコードでも同じ挙動を示すものなら最適化され、最も良いもので実行されるのであれば、こんな風にはならない気がします。
|
|
17
|
+
|
|
18
|
+
「コンパイラが全知全能であれば」あなたの理解通りのことが起こると思います。もちろん、現実的にはそんなことはありませんから、プログラマの記述したC++ソースコードによって実性能が左右されます。
|
|
19
|
+
|
|
20
|
+
> それは「windowsPCのコマンドプロンプトで cl ファイル名.cpp を実行」するものです。このコンパイルの方法が最適化されたものなのかどうかはわかっていません。
|
|
21
|
+
|
|
22
|
+
Microsoft Visual C++コンパイラ(`cl`)のデフォルト動作では、最適化は行われません。
|
|
23
|
+
|
|
24
|
+
> そして、その上で僕が知りたくて四苦八苦しているのは、以上のことが前提としてある上で、「なぜ64個の方が32個のものより時間がかかったのか」なのです。
|
|
25
|
+
|
|
26
|
+
繰り返しになりますが、提示されているC++ソースコードからだけでは、確かなことは何も言えません。
|
|
27
|
+
|
|
28
|
+
個人的な経験則に基づく推測にすぎませんが、rubato6809さん回答にある「生成される機械語命令列が肥大化したことにより、実行時の命令キャッシュミスが発生しているため」が最も有力だと思います。
|
|
29
|
+
|
|
30
|
+
（ループ展開を 2 → 4 →... と進めていくと最初は性能向上がみられるが、展開回数を大きくすると性能劣化が始まるという状況からの類推）
|