アカウント名:
パスワード:
ストールが問題になるにはデータ依存が存在していることが必要で、データ依存の有無はアルゴリズムによって決まります。インクリメントが後置か前置かとは別の話でしょう。前置インクリメントを使ったためにデータ依存が新たに生じることはありません。(生じるとすれば、アルゴリズムが変わっています。)
影響があるとすればコンパイラの最適化でしょうが、前置インクリメントの方が一般に処理が単純なので、これを使ったために、データ依存解析に失敗するケースというのはちょっと想像がつきませんね。
逆に、後置インクリメントを使うことによって生じるコピーコンストラクタの削除にコンパイラが失敗するケースなら十分あり得ます。一般論として、コピーコンストラクタを削除するには手続き間解析(少なくともインライン化)が必要ですが、手続き間解析はコストが大きいため、現行のコンパイラは、これを完全には行えていないからです。(そもそも、コピーコンストラクタのソースコードが提供されていない場合、リンク時最適化を利用しない限り、最適化はできません。)
うん。リンク先も、単純な場合はコンパイラが勝手に上手いことやってくれる、までは良いんだけど、そこから迷走しだしてるね。
前置/後置の差で不自然なストールを演出しようとしても、わざわざそこでソースを分割して最適化出来ないような工夫さえしてなければ、本質的にストールを考慮て最適化する必要があるかどうか、コンパイラには見抜かれる。
コンパイラの最適化の限界を知っておくのはなかなかおもしろい。ソースコードを愚直に実行するとものすごく無駄な手順を踏むことになるけど、構造化されてて書きやすく、従ってバグを入れにくいような書き方を気楽に使える。
例えば、2×2行列の掛け算みたいな、手で書くと最小限のコードに出来そうだけどどこか書き間違えてしまいそうな処理も、汎用的なn×n行列の掛け算インライン関数を呼んでおけば、何だかループがアンロールされて、必死こいて必要最小限だけ手で書いたやつと似たような結果になる。出来合いの関数が無い処理でも、こういうのは、添え字を丁寧に書き並べるより、ループを使ったほうが書き間違いをしづらいし。
このあたり理解してる人間がわざとそうやって書いててもコードレビューという名の理解してない人間への説明会で遅いから書き換えろと言われる率の高さがなぁ変わらないって説明しても聞きゃしねぇ…
もしも差があったらコンパイラっていうかプリプロセッサに問題があるって言うのが現代でしょう。コード化された時に大きな速度差が出るようなコードって、プロセッサ処理よりI/O周りの処理がボトルネックになる方が大きいと思う。実際にコード化されたイメージをしながらプログラムソースを書く時代はとっくに終わってる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
あきらかにおかしい (スコア:0)
ストールが問題になるにはデータ依存が存在していることが必要で、データ依存の有無はアルゴリズムによって決まります。
インクリメントが後置か前置かとは別の話でしょう。
前置インクリメントを使ったためにデータ依存が新たに生じることはありません。
(生じるとすれば、アルゴリズムが変わっています。)
影響があるとすればコンパイラの最適化でしょうが、前置インクリメントの方が一般に処理が単純なので、
これを使ったために、データ依存解析に失敗するケースというのはちょっと想像がつきませんね。
逆に、後置インクリメントを使うことによって生じるコピーコンストラクタの削除にコンパイラが失敗するケースなら十分あり得ます。
一般論として、コピーコンストラクタを削除するには手続き間解析(少なくともインライン化)が必要ですが、
手続き間解析はコストが大きいため、現行のコンパイラは、これを完全には行えていないからです。
(そもそも、コピーコンストラクタのソースコードが提供されていない場合、リンク時最適化を利用しない限り、最適化はできません。)
Re:あきらかにおかしい (スコア:1)
うん。リンク先も、単純な場合はコンパイラが勝手に上手いことやってくれる、までは良いんだけど、そこから迷走しだしてるね。
前置/後置の差で不自然なストールを演出しようとしても、
わざわざそこでソースを分割して最適化出来ないような工夫さえしてなければ、
本質的にストールを考慮て最適化する必要があるかどうか、コンパイラには見抜かれる。
コンパイラの最適化の限界を知っておくのはなかなかおもしろい。
ソースコードを愚直に実行するとものすごく無駄な手順を踏むことになるけど、
構造化されてて書きやすく、従ってバグを入れにくいような書き方を気楽に使える。
例えば、2×2行列の掛け算みたいな、手で書くと最小限のコードに出来そうだけどどこか書き間違えてしまいそうな処理も、
汎用的なn×n行列の掛け算インライン関数を呼んでおけば、
何だかループがアンロールされて、必死こいて必要最小限だけ手で書いたやつと似たような結果になる。
出来合いの関数が無い処理でも、こういうのは、添え字を丁寧に書き並べるより、ループを使ったほうが書き間違いをしづらいし。
Re: (スコア:0)
このあたり理解してる人間がわざとそうやって書いててもコードレビューという名の理解してない人間への説明会で
遅いから書き換えろと言われる率の高さがなぁ
変わらないって説明しても聞きゃしねぇ…
Re: (スコア:0)
もしも差があったらコンパイラっていうかプリプロセッサに問題があるって言うのが現代でしょう。
コード化された時に大きな速度差が出るようなコードって、プロセッサ処理よりI/O周りの処理がボトルネックになる方が大きいと思う。
実際にコード化されたイメージをしながらプログラムソースを書く時代はとっくに終わってる。