回答編集履歴
4
考察に誤りがあるので訂正
test
CHANGED
|
@@ -1,3 +1,37 @@
|
|
|
1
|
+
ベストアンサーを戴きましたが、不注意で誤った考察をしました。考察に使うべきコードと結果は、strike君が示したものではなく、asmさんの[「なおしてみました」](https://wandbox.org/permlink/sWnByHBlG99FV9Oj)のほうだと思います。その結果は、こうです。
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
8bit[1]整数の処理時間 = 0.587834秒
|
|
6
|
+
|
|
7
|
+
16bit[2]整数の処理時間 = 0.585182秒
|
|
8
|
+
|
|
9
|
+
32bit[4]整数の処理時間 = 0.580845秒
|
|
10
|
+
|
|
11
|
+
64bit[8]整数の処理時間 = 1.405345秒
|
|
12
|
+
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
8〜32bitが横並び、64bitは2.4倍の時間が掛かっている。私の手元でも同様の結果になりました（ただ古いパソコンのせいか、2.4倍ではなく3倍超orz）。不適切なコードの実験は無意味です。まず、strike君はobjdumpも含めて自分の手元でやり直して、結果を見直すべきです。
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
この結果から、CPUとキャッシュの間では32bit転送も64bit転送も一回で済んでいる、なんて言えません（とは言え、CPU・キャッシュ間の64bit転送を32bit転送２回に分けたりしないとは思うが）。
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
むしろ、8〜32bitの除算はCPU内部で同一ビット長の除算器を使うのだろうか？とも思いました。なぜならa_saitohさんが仰る通り「整数の割り算はビット長が長いほど手間がかかる」ものだから。しかし一方で、KSwordOfHasteさんが示唆されたように、CPUにとってキャッシュでさえも遅いかもしれず、8〜32bit除算ではCPU動作時間の違いがキャッシュアクセス時間の中に埋もれたのかもしれません。どうなのか、私にはわかりかねます。
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
結論的には、ビット数が多いほど時間のかかる割り算で「得意なビット数」を考えるってどうよ、そもそも実験の方針が不適当では？という事で、私的にベストアンサーはa_saitohさんです。
|
|
28
|
+
|
|
29
|
+
以上、お詫びを兼ねて訂正いたします。
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
1
35
|
> なぜ、8bitや16bitの方が32bitや64bitより早いのでしょうか？？
|
|
2
36
|
|
|
3
37
|
|
3
追記３への回答を追加
test
CHANGED
|
@@ -107,3 +107,25 @@
|
|
|
107
107
|
|
|
108
108
|
|
|
109
109
|
加えて、この狭い範囲のメモリしか使わないのだから、キャッシュの問題でもありません。メモリアクセスは、ほぼ全てがキャッシュアクセスで済んでいるはずです。念の為、追記：N回ループするコードも命令キャッシュにすっぽり入ってしまいます。
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
追記３へ
|
|
114
|
+
|
|
115
|
+
> CPUには得意なデータ型がある。変数のサイズがCPUのレジスタ長と一致していれば相性が良い?
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
一般的にそうでしょう。余計なビットを切り落とす命令が不要、足りないビットを補う命令も不要、なのだから。ただ、絶対のルールかどうかは知らないよ。
|
|
120
|
+
|
|
121
|
+
|
|
122
|
+
|
|
123
|
+
> 機械語だけだとすると「Nbitの精度を保証して、かつ処理効率が最速になる型」を定義する必要はありませんよね？？
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
機械語と言っても実際はアセンブリ言語でプログラムする場合だと思うが、機械語（とオペランドサイズ等）を選択するのはプログラマの責務ですからね。
|
|
128
|
+
|
|
129
|
+
何を元にして選択するかと言えば、一番重要なのはアーキテクチャの理解であることは論を待たないわけで、そこに、どの機械語が相応しいか、判断できるだけの情報を仕入れているか、ということになります。
|
|
130
|
+
|
|
131
|
+
コンパイラの作者はそうした情報に精通しているはずですが、実際は最初から100%良いコードを生成出きるとは限らなくて、コンパイラのバージョンアップで改良するわけです。
|
2
コードのコメント、誤りを修正
test
CHANGED
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
|
|
55
55
|
|
|
56
56
|
|
|
57
|
-
# long long ll3 = l1 / l2;
|
|
57
|
+
# long long ll3 = ll1 / ll2;
|
|
58
58
|
|
|
59
59
|
7f3: 48 8b 45 d0 mov -0x30(%rbp),%rax
|
|
60
60
|
|
1
若干の追記
test
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
|
|
15
15
|
```
|
|
16
16
|
|
|
17
|
-
# char
|
|
17
|
+
# char c3 = c1 / c2;
|
|
18
18
|
|
|
19
19
|
6ac: 0f be 45 f7 movsbl -0x9(%rbp),%eax
|
|
20
20
|
|
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
-
# short
|
|
31
|
+
# short s3 = s1 / s2;
|
|
32
32
|
|
|
33
33
|
716: 0f bf 45 ea movswl -0x16(%rbp),%eax
|
|
34
34
|
|
|
@@ -42,7 +42,7 @@
|
|
|
42
42
|
|
|
43
43
|
|
|
44
44
|
|
|
45
|
-
# long
|
|
45
|
+
# long l3 = l1 / l2;
|
|
46
46
|
|
|
47
47
|
785: 48 8b 45 e0 mov -0x20(%rbp),%rax
|
|
48
48
|
|
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
|
|
55
55
|
|
|
56
56
|
|
|
57
|
-
# long long
|
|
57
|
+
# long long ll3 = l1 / l2;
|
|
58
58
|
|
|
59
59
|
7f3: 48 8b 45 d0 mov -0x30(%rbp),%rax
|
|
60
60
|
|
|
@@ -88,6 +88,8 @@
|
|
|
88
88
|
|
|
89
89
|
一方、cateye さんのAMD機での実行時間は16, 32, 64bit が、ほぼ 0.33 秒で横並びだから、（8bit, 16bitのコードは示されたけど）32bit, 64bit でどんな命令か拝見したいですね。strike君の場合と違うはずです。
|
|
90
90
|
|
|
91
|
+
asmさんの結果は 64bit だけ余計に時間がかかっているから、64bitのところの機械語パターンが違うのではないかな。これもループの中身を比較してみると、何かわかるでしょう。もしかすると、同じ機械語を使うように修正できれば、strike君の手元でも結果が大きく違ってくるはず。
|
|
92
|
+
|
|
91
93
|
|
|
92
94
|
|
|
93
95
|
> アライメントに関わる問題
|
|
@@ -100,4 +102,8 @@
|
|
|
100
102
|
|
|
101
103
|
|
|
102
104
|
|
|
105
|
+
ただ、仮にCPUとメモリの間のバスが32bitだとすると、64bitの転送に２回の動作が必要になるから、64bit命令が大きく不利になるのは明らかです。しかし32bitと64bitの実行時間がほぼ同じ結果だから、CPUとメモリ（実際はCPUとキャッシュ）の間は64bit転送も１回の動作で済んでいるはずです（この段落、追記しました）。
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
|
|
103
|
-
加えて、この狭い範囲のメモリしか使わないのだから、キャッシュの問題でもありません。メモリアクセスは、ほぼ全てがキャッシュアクセスで済んでいるはずです。
|
|
109
|
+
加えて、この狭い範囲のメモリしか使わないのだから、キャッシュの問題でもありません。メモリアクセスは、ほぼ全てがキャッシュアクセスで済んでいるはずです。念の為、追記：N回ループするコードも命令キャッシュにすっぽり入ってしまいます。
|