アカウント名:
パスワード:
ストールが問題になるにはデータ依存が存在していることが必要で、データ依存の有無はアルゴリズムによって決まります。インクリメントが後置か前置かとは別の話でしょう。前置インクリメントを使ったためにデータ依存が新たに生じることはありません。(生じるとすれば、アルゴリズムが変わっています。)
影響があるとすればコンパイラの最適化でしょうが、前置インクリメントの方が一般に処理が単純なので、これを使ったために、データ依存解析に失敗するケースというのはちょっと想像がつきませんね。
逆に、後置インクリメントを使うことによって生じるコピーコンストラクタの削除にコンパイラが失敗するケースなら十分あり得ます。一般論として、コピーコンストラクタを削除するには手続き間解析(少なくともインライン化)が必要ですが、手続き間解析はコストが大きいため、現行のコンパイラは、これを完全には行えていないからです。(そもそも、コピーコンストラクタのソースコードが提供されていない場合、リンク時最適化を利用しない限り、最適化はできません。)
配列に頭から詰めてく・読んでくためのインデックスとかの場合、初期値と終了値がずれるため明らかにアルゴリズムが違います。ストール直後にインクリメント演算子の戻り値を使う場合、配列へのアクセスがインクリメント結果待ちになるか、配列アクセスと並行してパイプラインに詰め込めるかは明らかに違います。
そしてその程度の用途では演算子オーバライドだのでかいクラスのコピーだのとは次元の違う、単なる1レジスタの複製であり、その程度はレジスタリネームで隠蔽されかねないコストな訳です。
複雑なイテレータオブジェクトだと前置の方が高速になりがちで、単純なイテレータオブジェクトだと後置の方がパイプライン的には好都合、と言うだけです。リンク先の引用元はおそらく後者で、リンク元は前者よりに迷走してるから話が変なだけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
あきらかにおかしい (スコア:0)
ストールが問題になるにはデータ依存が存在していることが必要で、データ依存の有無はアルゴリズムによって決まります。
インクリメントが後置か前置かとは別の話でしょう。
前置インクリメントを使ったためにデータ依存が新たに生じることはありません。
(生じるとすれば、アルゴリズムが変わっています。)
影響があるとすればコンパイラの最適化でしょうが、前置インクリメントの方が一般に処理が単純なので、
これを使ったために、データ依存解析に失敗するケースというのはちょっと想像がつきませんね。
逆に、後置インクリメントを使うことによって生じるコピーコンストラクタの削除にコンパイラが失敗するケースなら十分あり得ます。
一般論として、コピーコンストラクタを削除するには手続き間解析(少なくともインライン化)が必要ですが、
手続き間解析はコストが大きいため、現行のコンパイラは、これを完全には行えていないからです。
(そもそも、コピーコンストラクタのソースコードが提供されていない場合、リンク時最適化を利用しない限り、最適化はできません。)
Re:あきらかにおかしい (スコア:0)
配列に頭から詰めてく・読んでくためのインデックスとかの場合、初期値と終了値がずれるため明らかにアルゴリズムが違います。
ストール直後にインクリメント演算子の戻り値を使う場合、配列へのアクセスがインクリメント結果待ちになるか、配列アクセスと並行してパイプラインに詰め込めるかは明らかに違います。
そしてその程度の用途では演算子オーバライドだのでかいクラスのコピーだのとは次元の違う、単なる1レジスタの複製であり、その程度はレジスタリネームで隠蔽されかねないコストな訳です。
複雑なイテレータオブジェクトだと前置の方が高速になりがちで、単純なイテレータオブジェクトだと後置の方がパイプライン的には好都合、と言うだけです。
リンク先の引用元はおそらく後者で、リンク元は前者よりに迷走してるから話が変なだけです。