アカウント名:
パスワード:
b = a[i++] みたいな場合、 まず a[i] の中身を取りに行く もう i は参照しちゃったので、i は変更可 a[i] の中身を取りに行きながら、並行して i もインクリメント => 速い
だけど、b = a[++] だと まず i をインクリメント インクリメントが終わらなきゃ、どこにアクセスしていいか分からない 並行不可 => 遅い
for( ほげ; ふが; i++) とか for( ほげ; ふが; ++i) の場合 コンパイラが最適化しちゃうので、どっちも同じ
結論: 習慣化する (≒考えずにやる) なら、後置で。
だけど、b = a[++] だと
これでは、意味不明ではないか orz 正しくは当然 b = a[++i] です。
提唱者が言いたいのはそういうことだと思うし、この場合C++のクラスのインクリメントにかぎらず発生する話だよね。そもそも「ゲームプログラミングにおいて速度を要求される部分で発生する、インクリメント可能なインスタンスの前置/後置インクリメントの戻り値を使う場合」って要するにインデックスとかイテレータで単なる整数かポインタ一個だろう。コピーコストなんてそうそうかからない、というかCPUのレジスタ・リネーミングの狭間に消え去るレベル。
条件にマッチしたオブジェクトIDを別の配列に放り込む、とかいうありがちな処理での配列インデックス変数とか。インクリメント演算子の戻り値を参照する処理の前後がストール気味な処理だと特にきつそう。
ループとかだと初期値を増減するだけで本質的に同じ動作にできますよ。
それは本質的に同じ事をやることになるからです。
「並列不可」が、ループしている部分の冒頭で起こるか、末尾で起こるかの差しか生じません
b = a[i++]→iのインクリメントとa[i]を取ってくるのが並列可能b = a[++i]→a[i]を取ってくるのと、次回のiのインクリメントが並列可能
ですから、差が出るとしても、ループの1回目冒頭と最終回の直後のみで微々たる差にしかならない上、その差も、多くはコンパイラが最適化して消し去ってくれるはずです。
ですので、「早い方の書き方になるようにループの始め方を工夫してiを-1からスタートして...」といった努力は無駄に終わるでしょう。変則的な事はせず、スッキリ分かりやすい方のコードで書いた方が良いです。
インデックスインクリメント付き配列アクセスに進入する直前にその処理を実行するか否かのストールが発生したりすると直撃しますよ。ゲームでボトルネックになるくらい回る場所では意外とありがちな処理なので、ぶち当たる人はぶち当たるTipsだと思う。CPUにもよるし、ホントいろいろな意味で状況次第だけど。
そのパターンに思い至っておらず、別のツリーで似たような指摘を受けて試してみた [srad.jp]んですが、確かに影響しますね。
周りを含めて同じ動作にできるのと、そのものの動作が違うってのは別だと思うんですけど
本体部分の小さいループ最適化などではどちらのタイプを使用する変形を行うかによって1～2割変わることもありますループ終了が回数指定などによって容易に推定可能であれば、ループをオーバーラップさせることでロードのレイテンシによるストールを回避できたりするんです。これは私がよく使う最適化の手です。
インクリメント/デクリメント演算子については、言語によってセマンティクスが若干違います（Java と C でも違います。）ので、習慣化するなら前置の方ですね。前置であれば、セマンティクスの違いは無いはずです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
こういうこと? (スコア:2)
b = a[i++] みたいな場合、
まず a[i] の中身を取りに行く
もう i は参照しちゃったので、i は変更可
a[i] の中身を取りに行きながら、並行して i もインクリメント => 速い
だけど、b = a[++] だと
まず i をインクリメント
インクリメントが終わらなきゃ、どこにアクセスしていいか分からない
並行不可 => 遅い
for( ほげ; ふが; i++) とか for( ほげ; ふが; ++i) の場合
コンパイラが最適化しちゃうので、どっちも同じ
結論: 習慣化する (≒考えずにやる) なら、後置で。
Re:こういうこと? (スコア:2)
だけど、b = a[++] だと
これでは、意味不明ではないか orz
正しくは当然
b = a[++i]
です。
Re: (スコア:0)
提唱者が言いたいのはそういうことだと思うし、この場合C++のクラスのインクリメントにかぎらず発生する話だよね。
そもそも「ゲームプログラミングにおいて速度を要求される部分で発生する、
インクリメント可能なインスタンスの前置/後置インクリメントの戻り値を使う場合」
って要するにインデックスとかイテレータで単なる整数かポインタ一個だろう。
コピーコストなんてそうそうかからない、というかCPUのレジスタ・リネーミングの狭間に消え去るレベル。
条件にマッチしたオブジェクトIDを別の配列に放り込む、とかいうありがちな処理での配列インデックス変数とか。
インクリメント演算子の戻り値を参照する処理の前後がストール気味な処理だと特にきつそう。
Re:こういうこと? (スコア:1)
Re:こういうこと? (スコア:2)
ループとかだと初期値を増減するだけで本質的に同じ動作にできますよ。
Re: (スコア:0)
それは本質的に同じ事をやることになるからです。
「並列不可」が、ループしている部分の冒頭で起こるか、末尾で起こるかの差しか生じません
b = a[i++]→iのインクリメントとa[i]を取ってくるのが並列可能
b = a[++i]→a[i]を取ってくるのと、次回のiのインクリメントが並列可能
ですから、差が出るとしても、ループの1回目冒頭と最終回の直後のみで微々たる差にしかならない上、
その差も、多くはコンパイラが最適化して消し去ってくれるはずです。
ですので、「早い方の書き方になるようにループの始め方を工夫してiを-1からスタートして...」といった努力は無駄に終わるでしょう。
変則的な事はせず、スッキリ分かりやすい方のコードで書いた方が良いです。
Re: (スコア:0)
インデックスインクリメント付き配列アクセスに進入する直前にその処理を実行するか否かのストールが発生したりすると直撃しますよ。
ゲームでボトルネックになるくらい回る場所では意外とありがちな処理なので、ぶち当たる人はぶち当たるTipsだと思う。
CPUにもよるし、ホントいろいろな意味で状況次第だけど。
Re: (スコア:0)
そのパターンに思い至っておらず、別のツリーで似たような指摘を受けて試してみた [srad.jp]んですが、確かに影響しますね。
Re: (スコア:0)
周りを含めて同じ動作にできるのと、そのものの動作が違うってのは別だと思うんですけど
Re: (スコア:0)
本体部分の小さいループ最適化などではどちらのタイプを使用する変形を行うかによって1～2割変わることもあります
ループ終了が回数指定などによって容易に推定可能であれば、ループをオーバーラップさせることでロードのレイテンシによるストールを回避できたりするんです。
これは私がよく使う最適化の手です。
最適化も考えればいろいろ… (スコア:0)
インクリメント/デクリメント演算子については、言語によってセマンティクスが若干違います（Java と C でも違います。）ので、習慣化するなら前置の方ですね。前置であれば、セマンティクスの違いは無いはずです。