- C++相談室 part144
570 ：デフォルトの名無しさん[sage]：2019/08/20(火) 14:48:01.70 ID:lOKfo+mN - 最近の環境では「実測」の信頼性確保も、また難しいです。
なぜかある時には何度測定しても遅いのに、あらためて別の時に
測ると速く出る事があったりします。
|
- C++相談室 part144
576 ：デフォルトの名無しさん[sage]：2019/08/20(火) 15:29:52.16 ID:lOKfo+mN - >>575
最適化はどちらも同じオプションでしてますし、出力されたアセンブリ・コード
も見て、テーブルを使った方が命令数の少ないコードになっていることも
確認してます。条件jmp命令も少なくなっています。
|
- C++相談室 part144
579 ：デフォルトの名無しさん[sage]：2019/08/20(火) 15:51:20.21 ID:lOKfo+mN - 最近のCPUは温度によってクロック数が変動する可能性もあるそうですね。
|
- C++相談室 part144
582 ：デフォルトの名無しさん[sage]：2019/08/20(火) 16:23:55.23 ID:lOKfo+mN - マクロスイッチ切り替え方式にして、ほぼ同時に両方を測定してみたら、
テーブル方式の方が速くなっていました。
|
- C++相談室 part144
584 ：デフォルトの名無しさん[sage]：2019/08/20(火) 17:25:38.94 ID:lOKfo+mN - >>580
アセンブリコードを見る限り、特に問題なく、人間が単純に書いた場合
と似たようなコードになっています。
ただし、一点、テーブルの c 番目の要素を参照する際、バイト整数の c
をゼロ拡張して32BIT 整数にする必要があるのですが、自分の使ってるVC++
だと、movzx 命令を使わずに、xor eax,eax; mov al,cl のように2命令
を使ってしまっている点が、人間が最適化するより遅いコードになってしまって
います。
|
- 将来性ないプログラミング言語。Delphi含まれず安心
130 ：デフォルトの名無しさん[sage]：2019/08/20(火) 21:45:07.95 ID:lOKfo+mN - >>128
それに、ブロックの終了の記号が何にも無いのは明確さがなく、
ケアレスミスの元となる。レイアウト的なものは、空行を入れたり
少し違う業や関数からコピーして来たりするときにずれ易い。
ずれたときにブロックの終了記号があると助かる。
>>127
逆に助長性は安全性に繋がりやすい。例えば、C/C++の最後のセミコロン";"
は無くてもコンパイラがその都度推定できる可能性はあるが、
有った方が確実だから有る。Rubyなんかは無くても分かるときはなくて良い
仕様ではあるが、大規模プログラムではそれが見つけにくいバグの原因に
なる可能性がある。
|
- 将来性ないプログラミング言語。Delphi含まれず安心
137 ：デフォルトの名無しさん[sage]：2019/08/20(火) 22:25:28.11 ID:lOKfo+mN - そういえば、プログラミングにおいても>>134の場合のように、関数の
引数を折り返して書く場合、どの程度引数の前に空白やタブを入れるべきかは
人間が見たときの「見易さ」で決まる。それは関数名 func 部分の長さに
よっても変化し得る。そして、何が美しいかは「美学」「美術」の領域に
入ってきてしまう可能性がある。だからプログラミングは芸術とも言われる。
その意味で、インデントに論理的な意味を与えすぎると、芸術的な
美しさが得られなくなってしまう可能性は高い。
|