このアーティクルでは前置と後置、２種類のインクリメントについて考察と現状をまとめるものです。
長年の常識
従来（～2015）は前置インクリメント(++value)と後置インクリメント(value++)の挙動の違いを正しく完全に理解した上で前置インクリメントを使うべきだ。というのがC++プログラマの基本姿勢でした。
各インクリメントの標準的な実装を以下に示します。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// 前置インクリメント T& T::operator++() { // ※ここでなんらかのインクリメント処理 return *this; // 自身の参照を返す } // 後置インクリメント T T::operator++(int) { T old(*this); // インクリメント前にコピーした後 ++*this; // 前置インクリメントを呼ぶ return old; // コピーしたものを返す } |
後置インクリメントにはひと目で遅くなりそうな処理が見て取れますね。
前置インクリメントがインクリメント処理後、単純に自身の参照を返すのに対し、後置インクリメントではインクリメント前に一時オブジェクトの生成、そしてインクリメント後にはその前に生成した一時オブジェクトを値で返しています。
前置と後置では、単純にオブジェクトをコピーして返す分、普通に考えたら後置の方が遅いよね。というのが従来の認識でした。
「C++ Coding Standards -101のルール、ガイドライン、ベストプラクティス」の中でも、特に後置インクリメントの必然性が無い時は迷わず前置インクリメントを使うことが推奨されてきました。
元の値を必要としないときは前置形式の演算子を使おう
＿＿C++ Coding Standards (p50)
新たな主張
「ゲームエンジン・アーキテクチャ第二版」の中の一節を紹介します。
しかし、値が使われる場合、CPUのパイプラインでストールを生じさせないので、ポストインクリメントの方が優秀である。したがって、プレインクリメントの動作が絶対に必要である場合を除いて、必ずポストインクリメントを使う習慣を身につけたほうがよい。
＿＿ゲームエンジンアーキテクチャ第二版 プレインクリメント vs ポストインクリメント
従来の主張と真逆の主張が展開されたのです。後置インクリメントの方が優秀なので出来る限りそちらを使うべきとされました。
ゲームエンジン・アーキテクチャの著者は、UnchartedやThe Last of Usの開発元であるノーティドッグ社のエンジニアです。その彼が後置インクリメントを使うべきと主張したことで大きな話題となりました。
後置インクリメントが優秀とされる理由は以下のとおりです。
- 前置インクリメントは値を書き換えて戻すのでインクリメント処理が終了するまで戻す値が決まらない
- それはデータ依存性を生み、深いパイプラインのCPUではストールを発生させる
- 後置インクリメントはインクリメント処理と戻す値は別インスタンスなので並列に処理が可能
- よってストールの発生が無い分、後置インクリメントが優秀
なるほど、といった感じです。
考察を深めよう
今後は後置インクリメントに統一だ！今まで書いた前置インクリメントを全部置換しなくちゃ！と、急ぐ前に、本当にゲームエンジン・アーキテクチャの主張が正しいかは一考の余地があります。
深いパイプラインにおけるストールの可能性はデータ依存性があるかぎり発生しうる問題です。
この部分の主張は正しいです。
しかし、ゲームエンジン・アーキテクチャでは後置インクリメントに発生していたコピーコストについて言及がありません。
文脈を読み解く限り、「コピーコスト＜ストールコスト」という前提があるようです。このインクリメントの項以外でもゲームエンジン・アーキテクチャではストールに対する嫌悪を書いてある箇所があり、著者はかなりストールコストに対してナイーブになっているように感じます。
実際にコンソールゲーム機のアーキテクチャにはストールのコストが引くほど高いものもあり、それこそPS2の時代はとにかくCPUの稼働効率を高めるようなコードを意識して書かないと描画ポリゴンが倍は違うというような状況でした。XBOX360の頃でさえ、シーングラフ（ゲームシーンの描画を効率的に管理したりする構造）を作っても、その走査や判定のコストの方が高い為、単純にシーンにある全オブジェクトを順番に描画するだけの方が速かったという経験があります。
一時オブジェクト生成のコスト考察
一時オブジェクトの生成に伴うコストについて、好意的に解釈してみましょう。
例で示した実装の場合、後置インクリメントで変更前の値を返す際にRVOの最適化が期待されるので、前置インクリメントも後置インクリメントも（このインクリメントの結果として使う時の）オブジェクトの生成は１度きりになる可能性があります。厳密には直前のテンポラリオブジェクトが(oldという)名前付きオブジェクトなので、この最適化を期待するためにはコンパイラがNRVO(Named Return Value Optimization)に対応している必要があります。それでもほとんどのコンパイラはNRVOが効くのでコピーコストは低くなる可能性があります。
ちゃんとNRVOが効くコンパイラ（今回はgcc）を使って実際のアセンブラコードを見てみましょう。
ユーザー定義の前置インクリメントと後置インクリメントを用意します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
class Hoge { public: Hoge(int c) : a_(c) , b_(c) {} Hoge& operator ++() { a_ += 1; b_ += 1; return *this; } Hoge operator++(int) { Hoge old(*this); ++*this; return old; } int a_; int b_; }; |
前置インクリメント、後置インクリメントそれぞれの処理を呼び出す処理を書きます。
pre.cpp
|
1 2 3 4 5 6 7 8 9 |
#include <cstdio> // 前置インクリメントを呼び出すバージョン int main(int argc, char *argv[]) { Hoge h(argc); ++h; // ここで呼ぶ std::printf("%d", h.a_); return 0; } |
post.cpp
|
1 2 3 4 5 6 7 8 9 |
#include <cstdio> // 後置インクリメントを呼び出すバージョン int main(int argc, char *argv[]) { Hoge h(argc); h++; // ここで呼ぶ std::printf("%d", h.a_); return 0; } |
これら２つの処理のアセンブラコードを出力します。
|
1 |
g++-4 *.cpp -S -O0 |
アセンブラコードを読むのが嫌いな人は行数だけ見ればいいです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 |
.file "pre.cpp" .section .text$_ZN4HogeC1Ei,"x" .linkonce discard .align 2 .globl __ZN4HogeC1Ei .def __ZN4HogeC1Ei; .scl 2; .type 32; .endef __ZN4HogeC1Ei: LFB9: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: movl 8(%ebp), %eax movl 12(%ebp), %edx movl %edx, (%eax) movl 8(%ebp), %eax movl 12(%ebp), %edx movl %edx, 4(%eax) popl %ebp LCFI2: ret LFE9: .section .text$_ZN4HogeppEv,"x" .linkonce discard .align 2 .globl __ZN4HogeppEv .def __ZN4HogeppEv; .scl 2; .type 32; .endef __ZN4HogeppEv: LFB10: pushl %ebp LCFI3: movl %esp, %ebp LCFI4: movl 8(%ebp), %eax movl (%eax), %eax leal 1(%eax), %edx movl 8(%ebp), %eax movl %edx, (%eax) movl 8(%ebp), %eax movl 4(%eax), %eax leal 1(%eax), %edx movl 8(%ebp), %eax movl %edx, 4(%eax) movl 8(%ebp), %eax popl %ebp LCFI5: ret LFE10: .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d\0" .text .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB12: pushl %ebp LCFI6: movl %esp, %ebp LCFI7: andl $-16, %esp LCFI8: subl $32, %esp LCFI9: call ___main movl 8(%ebp), %eax movl %eax, 4(%esp) leal 24(%esp), %eax movl %eax, (%esp) call __ZN4HogeC1Ei leal 24(%esp), %eax movl %eax, (%esp) call __ZN4HogeppEv movl 24(%esp), %eax movl %eax, 4(%esp) movl $LC0, (%esp) call _printf movl $0, %eax leave LCFI10: ret LFE12: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE1: .long LEFDE1-LASFDE1 LASFDE1: .long LASFDE1-Lframe1 .long LFB12 .long LFE12-LFB12 .byte 0x4 .long LCFI6-LFB12 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI7-LCFI6 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI10-LCFI7 .byte 0xc5 .byte 0xc .uleb128 0x4 .uleb128 0x4 .align 4 LEFDE1: .def _printf; .scl 2; .type 32; .endef |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 |
.file "post.cpp" .section .text$_ZN4HogeC1Ei,"x" .linkonce discard .align 2 .globl __ZN4HogeC1Ei .def __ZN4HogeC1Ei; .scl 2; .type 32; .endef __ZN4HogeC1Ei: LFB9: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: movl 8(%ebp), %eax movl 12(%ebp), %edx movl %edx, (%eax) movl 8(%ebp), %eax movl 12(%ebp), %edx movl %edx, 4(%eax) popl %ebp LCFI2: ret LFE9: .section .text$_ZN4HogeppEv,"x" .linkonce discard .align 2 .globl __ZN4HogeppEv .def __ZN4HogeppEv; .scl 2; .type 32; .endef __ZN4HogeppEv: LFB10: pushl %ebp LCFI3: movl %esp, %ebp LCFI4: movl 8(%ebp), %eax movl (%eax), %eax leal 1(%eax), %edx movl 8(%ebp), %eax movl %edx, (%eax) movl 8(%ebp), %eax movl 4(%eax), %eax leal 1(%eax), %edx movl 8(%ebp), %eax movl %edx, 4(%eax) movl 8(%ebp), %eax popl %ebp LCFI5: ret LFE10: .section .text$_ZN4HogeppEi,"x" .linkonce discard .align 2 .globl __ZN4HogeppEi .def __ZN4HogeppEi; .scl 2; .type 32; .endef __ZN4HogeppEi: LFB11: pushl %ebp LCFI6: movl %esp, %ebp LCFI7: subl $20, %esp LCFI8: movl 8(%ebp), %eax movl 4(%eax), %edx movl (%eax), %eax movl %eax, -8(%ebp) movl %edx, -4(%ebp) movl 8(%ebp), %eax movl %eax, (%esp) call __ZN4HogeppEv movl -8(%ebp), %eax movl -4(%ebp), %edx leave LCFI9: ret LFE11: .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d\0" .text .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB12: pushl %ebp LCFI10: movl %esp, %ebp LCFI11: andl $-16, %esp LCFI12: subl $32, %esp LCFI13: call ___main movl 8(%ebp), %eax movl %eax, 4(%esp) leal 24(%esp), %eax movl %eax, (%esp) call __ZN4HogeC1Ei movl $0, 4(%esp) leal 24(%esp), %eax movl %eax, (%esp) call __ZN4HogeppEi movl 24(%esp), %eax movl %eax, 4(%esp) movl $LC0, (%esp) call _printf movl $0, %eax leave LCFI14: ret LFE12: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE1: .long LEFDE1-LASFDE1 LASFDE1: .long LASFDE1-Lframe1 .long LFB12 .long LFE12-LFB12 .byte 0x4 .long LCFI10-LFB12 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI11-LCFI10 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI14-LCFI11 .byte 0xc5 .byte 0xc .uleb128 0x4 .uleb128 0x4 .align 4 LEFDE1: .def _printf; .scl 2; .type 32; .endef |
やっぱり後置インクリメントの方が遅いですね。
では次はコンパイラの最適化オプションをバッチリ有効にしたバージョンで見てみましょう。
|
1 |
g++ *.cpp -S -O3 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
.file "pre.cpp" .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d\0" .text .p2align 4,,15 .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB12: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: andl $-16, %esp LCFI2: subl $16, %esp LCFI3: call ___main movl 8(%ebp), %eax movl $LC0, (%esp) addl $1, %eax movl %eax, 4(%esp) call _printf xorl %eax, %eax leave LCFI4: ret LFE12: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE1: .long LEFDE1-LASFDE1 LASFDE1: .long LASFDE1-Lframe1 .long LFB12 .long LFE12-LFB12 .byte 0x4 .long LCFI0-LFB12 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI1-LCFI0 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI4-LCFI1 .byte 0xc5 .byte 0xc .uleb128 0x4 .uleb128 0x4 .align 4 LEFDE1: .def _printf; .scl 2; .type 32; .endef |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
.file "post.cpp" .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d\0" .text .p2align 4,,15 .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB12: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: andl $-16, %esp LCFI2: subl $16, %esp LCFI3: call ___main movl 8(%ebp), %eax movl $LC0, (%esp) addl $1, %eax movl %eax, 4(%esp) call _printf xorl %eax, %eax leave LCFI4: ret LFE12: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE1: .long LEFDE1-LASFDE1 LASFDE1: .long LASFDE1-Lframe1 .long LFB12 .long LFE12-LFB12 .byte 0x4 .long LCFI0-LFB12 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI1-LCFI0 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI4-LCFI1 .byte 0xc5 .byte 0xc .uleb128 0x4 .uleb128 0x4 .align 4 LEFDE1: .def _printf; .scl 2; .type 32; .endef |
なんということでしょう。
前置も後置もまったく同じ結果になりました。流石、昨今のコンパイラは優秀です。
これは例として示したコードのようにインクリメントの実装詳細まで一つのコンパイル単位に含まれている関係で、コンパイラが副作用がないことを把握しながらインライン展開まで行える為、とにかく結果だけ合うように最速のパフォーマンスを組み上げられる為です。
もう一歩進んで、Hoge::operator++()とHoge::operator++(int)を別のcppに移しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#include "hoge.hpp" Hoge& Hoge::operator ++() { a_ += 1; b_ += 1; return *this; } Hoge Hoge::operator++(int) { Hoge old(*this); ++*this; return old; } |
それではアセンブラコードを見てみましょう。
|
1 |
g++ pre.cpp hoge.cpp -S -O3 |
まずはhoge.cpp自体のアセンブラコード。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
.file "hoge.cpp" .text .align 2 .p2align 4,,15 .globl __ZN4HogeppEv .def __ZN4HogeppEv; .scl 2; .type 32; .endef __ZN4HogeppEv: LFB3: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: movl 8(%ebp), %eax addl $1, (%eax) addl $1, 4(%eax) popl %ebp LCFI2: ret LFE3: .align 2 .p2align 4,,15 .globl __ZN4HogeppEi .def __ZN4HogeppEi; .scl 2; .type 32; .endef __ZN4HogeppEi: LFB4: pushl %ebp LCFI3: movl %esp, %ebp LCFI4: movl 8(%ebp), %ecx pushl %ebx LCFI5: movl (%ecx), %eax movl 4(%ecx), %edx leal 1(%eax), %ebx movl %ebx, (%ecx) leal 1(%edx), %ebx movl %ebx, 4(%ecx) popl %ebx LCFI6: popl %ebp LCFI7: ret LFE4: |
pre.cpp
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 |
.file "pre.cpp" .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d\0" .text .p2align 4,,15 .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB10: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: andl $-16, %esp LCFI2: pushl %ebx LCFI3: subl $44, %esp LCFI4: movl 8(%ebp), %ebx call ___main leal 24(%esp), %eax movl %eax, (%esp) movl %ebx, 24(%esp) movl %ebx, 28(%esp) call __ZN4HogeppEv movl 24(%esp), %eax movl $LC0, (%esp) movl %eax, 4(%esp) call _printf addl $44, %esp xorl %eax, %eax popl %ebx LCFI5: movl %ebp, %esp LCFI6: popl %ebp LCFI7: ret LFE10: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE1: .long LEFDE1-LASFDE1 LASFDE1: .long LASFDE1-Lframe1 .long LFB10 .long LFE10-LFB10 .byte 0x4 .long LCFI0-LFB10 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI1-LCFI0 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI4-LCFI1 .byte 0x10 .byte 0x3 .uleb128 0x8 .byte 0x75 .sleb128 0 .byte 0x9 .byte 0xf0 .byte 0x1a .byte 0x9 .byte 0xfc .byte 0x22 .byte 0x4 .long LCFI5-LCFI4 .byte 0xc3 .byte 0x4 .long LCFI6-LCFI5 .byte 0xd .uleb128 0x4 .byte 0x4 .long LCFI7-LCFI6 .byte 0xc5 .byte 0xe .uleb128 0x4 .align 4 LEFDE1: .def __ZN4HogeppEv; .scl 2; .type 32; .endef .def _printf; .scl 2; .type 32; .endef |
post.cpp
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 |
.file "post.cpp" .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d\0" .text .p2align 4,,15 .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB10: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: andl $-16, %esp LCFI2: pushl %ebx LCFI3: subl $44, %esp LCFI4: movl 8(%ebp), %ebx call ___main leal 24(%esp), %eax movl $0, 4(%esp) movl %eax, (%esp) movl %ebx, 24(%esp) movl %ebx, 28(%esp) call __ZN4HogeppEi movl 24(%esp), %eax movl $LC0, (%esp) movl %eax, 4(%esp) call _printf addl $44, %esp xorl %eax, %eax popl %ebx LCFI5: movl %ebp, %esp LCFI6: popl %ebp LCFI7: ret LFE10: .section .eh_frame,"w" Lframe1: .long LECIE1-LSCIE1 LSCIE1: .long 0x0 .byte 0x1 .ascii "\0" .uleb128 0x1 .sleb128 -4 .byte 0x8 .byte 0xc .uleb128 0x4 .uleb128 0x4 .byte 0x88 .uleb128 0x1 .align 4 LECIE1: LSFDE1: .long LEFDE1-LASFDE1 LASFDE1: .long LASFDE1-Lframe1 .long LFB10 .long LFE10-LFB10 .byte 0x4 .long LCFI0-LFB10 .byte 0xe .uleb128 0x8 .byte 0x85 .uleb128 0x2 .byte 0x4 .long LCFI1-LCFI0 .byte 0xd .uleb128 0x5 .byte 0x4 .long LCFI4-LCFI1 .byte 0x10 .byte 0x3 .uleb128 0x8 .byte 0x75 .sleb128 0 .byte 0x9 .byte 0xf0 .byte 0x1a .byte 0x9 .byte 0xfc .byte 0x22 .byte 0x4 .long LCFI5-LCFI4 .byte 0xc3 .byte 0x4 .long LCFI6-LCFI5 .byte 0xd .uleb128 0x4 .byte 0x4 .long LCFI7-LCFI6 .byte 0xc5 .byte 0xe .uleb128 0x4 .align 4 LEFDE1: .def __ZN4HogeppEi; .scl 2; .type 32; .endef .def _printf; .scl 2; .type 32; .endef |
やはりコード次第では、最適化オプションを有効にしていても、前置インクリメントにアドバンテージがあるケースがありますね。
hoge.cppなんてコンパイラにとったら何のヒントも無いコンパイル単位なので、素直に処理するしかないので当たり前といえば当たり前です。
しかし、世の中には、リンク時最適化というものがあり、オブジェクトコード生成後に再度ファイルを走査し、リンクのタイミングでインライン展開されるような場合もあるので、この例で一概に前置が有利と結論付けることはできません。
ストールコストの考察
ストールが発生するシチュエーションを考えます。
ストールは本来、このインクリメントに限らず、データ依存性を持つあらゆるシチュエーションで発生する恐れがあります。条件分岐、値の更新など、結果を待たなければ先の処理が行えないケースが発生するたびストールは起こりえます。分岐予測など、ストールが実質的に無くなるような工夫ももちろん行われているのですが、予測が外れた場合には、事前準備の甲斐なく、やっぱりストールします。
まず、インクリメントの外、インクリメント結果を使う瞬間に発生するストールについてですが、ただ単に一行
|
1 |
++value; |
と書く場合、前置と後置で何も変わりません。
次の行以降で使う値はインクリメント後の値なので、前置後置関係無く、値の更新が完了しないと何も始まらないからです。
|
1 2 3 4 5 6 7 8 9 |
int main() { int i = 5; while (i--) { // 何かしらの処理 } return 0; } |
この例の場合、while文のtest exprに入った段階でiの内容が確定している為、インクリメントの結果を待たずに次の処理を進めることができます。こういうようなシチュエーションでは前置と後置でストールによるコストが変わってきます。
インクリメントの中で発生するストールもについても意識する必要がります。
前述のとおり、ストールはどこでも発生する可能性があります。
このストールがインクリメント演算の中で発生した場合、インクリメント演算の度にCPUはストールしてしまいます。しかし、後置インクリメントであれば、インクリメント演算の結果を待たず次の処理へ移れる為、有利と言えるでしょう。
最悪の場合、インクリメントの中でストールするわ、インクリメントの外でストールするわと、春先の有楽町と同じくらいストールで溢れかえってしまいます。実際にCPUがストールしまくる状態のことを「海外セレブ効果(Celebrity Fashion)」と呼びます。嘘です。
今回のゲームエンジン・アーキテクチャの主張もまさに、後置インクリメントはインクリメントの結果を待たなくても、戻り値のオブジェクトは決定しているのでそのオブジェクトに対する処理はインクリメントの動作と並行して行えるよね。ならストールしないよね。というものです。
逆に、コードの流れの中で、インクリメントした後の結果しか使わないのであれば、前置でも後置でもCPUのコストは変わりません。仮にインクリメント演算子の中で70,000サイクルの処理がかかるとしても、インクリメント後の値しか使わないのであれば、前置でも後置でも等しくその負荷が計上されることになります。
計測サンプル
ダラダラとアセンブラコード貼ってる暇があったら実測値をだしてみろよ！投資家は数字でしか動かねーんだよ！というYコンビネーターマインドの方もいるかもしれません。
以下のサイトではインクリメントのコストを複数のコンパイラで比較検証されていますので一例として参考にして頂ければと思います。
インクリメントの前後置速度比較(vc++/gcc/clang)|他人の空似
典型的なfor文を前置後置それぞれのインクリメントを使用する形で作成。
インクリメント対象をunsigned int/iterator/適当に重めのクラスの三種それぞれを対象。
また、最適化により返り値計算が消えることを考えforの真偽判定でインクリメントの返り値を使用するものも用意。
以上をそれぞれ100,000,000回実行をさらに10回繰り返しかかった時間の平均をとる。
(中略)
vc++ gcc clang int前置インクリメント 46ms 61ms 41ms int後置インクリメント 51ms 44ms 53ms クラス前置インクリメント 320ms 47ms 316ms クラス後置インクリメント 2206ms 388ms 446ms ＿＿インクリメントの前後置速度比較(vc++/gcc/clang)|他人の空似
全計測の結果は元サイトよりご確認下さい。
なお、余談ではございますが闇夜のC++のサイト運営に２億くらい出してもいいよというエンジェル投資家の方がいらっしゃいましたら、ご連絡下さい。
現実的な観点
我々は現実の世界で実際にコードを書くプログラマです。そこには机上の論理以外の様々な要素を考慮する必要があります。
結論を出す前に我々が向き合わなければいけない現実的な考慮事項は４つあります。
まず第１に、一時オブジェクトの検証結果ですが、インライン展開が効かない、前置インクリメントにアドバンテージのあるシチュエーションにするには、リンク時最適化の効かないコンパイラ上で、ユーザー定義のインクリメントオペレータ演算子をcpp側に書く必要があります。
インクリメント演算子もデクリメント演算子もクラス書くたびに必ず用意してます（しかもヘッダーファイルじゃなくcpp側に！）という人は別として、一般的に最も多く呼び出されるインクリメント演算子は組み込みのint、もしくはSTLのイテレータに対してではないでしょうか。
その場合、やはり先程の検証でもあったように、コンパイラの素晴らしい最適化により、前置と後置のコストの違いは限りなく少なくなります。
第２に、インクリメント演算によって発生するなんらかのストールを回避するにはインクリメント前の値を使うようなコードを心がける必要があります。
例えば、インクリメント演算子を式中で使ったり、インクリメント後もインクリメント前の値に対する処理を書くという感じです。
しかし可読性の観点からすると、あまり推奨されるようなコードではありません。
第３に、ストールのコストは肌で感じづらいという問題があります。
処理に直接関係するコストは、例えばアセンブラコードの出力を見れば把握できます。
余分なオブジェクトが生成されているな、とか、最適化されているな、とか。
しかし、あるコードを書いた時にその部分の処理によってCPUにストールが発生しているかというのは極めて把握が難しい問題です。
第４に、しかし、それでも、いかんともしがたく、アーキテクチャに引っ張られることがあるという点です。
中盤でも触れましたが、一部のアーキテクチャにおいてはストールの発生を抑えなければロクに処理が動かないというケースがあるのも事実です。そういうアーキテクチャと向き合わなければならない場合、全く一切選択の余地なく、可読性うんぬん以前に、方針を決めざるをえない場合もあります。
CPUのアーキテクチャへの理解と、コンパイラの挙動、そして現実にコードを書く我々、この３つを勘案した上で、実際に前置インクリメントを使うべきか、後置インクリメントを使うべきか、また今の時代そういうことは気にしないべきか、考える必要があります。
私は、後置インクリメントを使っている事を指摘した際に「だってゲームエンジン・アーキテクチャに書いてあったからなんとなく」という答えをするプログラマが増えない事だけを願っています。
まとめ
- 前置インクリメントを使うべきという主張の理由を理解しよう
- 後置インクリメントを使うべきという主張の意図を汲もう
- 時代の変化とともに柔軟に再考しよう
