時折耳にする「年々CPUは高速になるのでコードの最適化は不要」と言うのは全くの見当違いです。
しかし、十分な速度で動いている部分を最適化する為に余分な労力を使うのは時間の無駄であり、単なる自己満足に過ぎません。
本書は小手先の技巧的なコーディングテクニックを紹介する本ではありません。
本書の第3章のコラムにもあるように、性能のボトルネックになっている1ヶ所を最適化する事で性能が7%向上した。
しかし、別の部分は最適化しても効果が無いので最適化を見送った。本書はそう言う見極めとメリハリが重要だと説いています。
もちろん、C++の言語的な、或いは付属のライブラリの特性を意識した最適化の為のテクニックの紹介は多々ありますが、それは本書の全てではありません。
むしろ本書は、適切なアルゴリズムやデータ構造を使う事の重要性を説いています。そして並行処理の最適化についても紹介されています。
例えば1989年に初版発行の「アルゴリズムとデータ構造」ですら、いわゆるビックオー表記の性能評価の目安であるO(n2)やO(log2 n)などが紹介されています。
そして当時でさえ、データ数が十分に少なければO(n2)の方がO(log2 n)よりも早くなる場合がある事も記されています。
これは一般的に繰り返しの回数を少なくするアルゴリズムは複雑になる傾向があるので、定数・係数であるビックオー部分が大きくなるからです。
例えて言えば、10m先に行くのに徒歩と自動車どちらが早いかと言う事です。
長距離であれば当然自動車の方が遙かに早いのですが、たったの10m程度の距離であれば車に乗り込んでシートベルトを着用してエンジン掛けて・・・とやってる暇があるなら歩いた方が早い。当たり前の話ですね。
本書では近年の研究の成果を踏まえて、理論的な計算量（時間コスト）とCPUのキャッシュ、データの特性を考慮したアルゴリズムの選択について紹介されています。
時折挟まれるコラムには最適化に関する著者の体験談なども載っており、「ああ、あるある」と楽しめます。
第3章の先述とは別のコラムで、線形探索と二分探索の性能測定でデータ数を増やしても常に線形探索の方が早いのでおかしいと思ってコードを調べたら、線形探索のバグで最初の1回目で常に「成功」を返していたと言うのがありますが、実は私も全く同じミスを犯した事があります。
まあ、筆者の場合と異なり、単体テストの段階でミスに気づきましたが。
本書の購入を考えている、或いは本書に興味を持つような方なら大丈夫だと思いますが、本書は内容の特性上、C++はもとよりCPUやメモリアクセス及びキャッシュの仕組みと特性、OSの構造や動作、CPUの進化の歴史などの知識がそれなりに必要です。
もちろんそれらの知識がなくても読めない訳ではありませんが、「なぜそうするのか？」と言う一番重要なポイントが腑に落ちないと思います。
コンパイラの最適化オプションによってソースコードがどう変化するかを、アセンブラのソースを出力させて確認する。そう言う経験をして来た人達だと著者が言いたい事が伝わりやすいと思います。
本書には（恐らく原文からしてそうなのでしょうが）比喩的な表現が多く見られます。特に第2章の「～の真実」関係の記述は、分かっている人でないと誤解を招く表現も多々見うけられます。
例えばP.14ではZ80などの昔のCPUと違い、最近のCPUではマルチコアだったり各種の高速化技法を使っているので一筋縄では行かないと言う事を読者に伝えたいようです。
が、それを表現するのに「C++プログラムは、先ほど述べたコンピュータの単純モデルを信じているように振るまう」と書かれています。
これは前後の文章の流れからするとCPUの投機実行（分岐した先の処理をあらかじめ実行しておくこと。分岐しなかった場合の結果は破棄される）やHTやアウトオブオーダー実行（命令の実行順をプログラムと矛盾しない範囲で入れ替えて実行する）、或いはMMUを使った仮想記憶などを意識した記述だと思われるのですが・・・
これはCPUの内部で行われている話であり、外部に対してはプログラムの記述通りの結果になる事が保障されています。
つまり、「振るまっている」のはCPUであって、C++ではありません。
とは言え、それらが全く無関係かと言うとそうでもなく、C++コンパイラ自身の最適化機能においてもソースコードのコンパイル時に結果に影響がない範囲で順番を変えてコードを生成する場合があります。
もっともその場合でも、「振るまっている」のはC++のコンパイラ（の最適化機能）であって、（ユーザーが作成した）プログラムではありませんが。
もしかすると「C++プログラム」とはC++コンパイラの事を言いたいのかとも思いましたが、その後に「C++ コンパイラ」と言う文言が出てくるので、恐らく「C++プログラム」はユーザーが作ったプログラムの事を示しているのだと思います。
他にも用語的には「C++」「コンパイラ」が使われていますが、「C++」はC++の言語仕様を示す時に使われているようです。
まあ勿論、CPUやコンパイラがどの様に振るまうかと言う事は（プログラマ自身が）コーディングの際に常に意識しておく必要はあります。
例えば副作用を伴う関数を引数に渡す場合がそれに該当します。
仮に次の様な（推奨されない）記述があったとします。
int a = 0;
func(a++, a++);
関数の引数の評価順序はC++の仕様で規定されてないので、コンパイラは「振るまう」必要がありません。
つまりこの場合、func(0, 1)で呼び出されるか、それともfunc(1, 0)で呼び出されるかはコンパイラに依存し、さらに同じコンパイラを使っても最適化機能のON/OFFで結果が異なる可能性があると言う事です。
つまり、コンパイラの振るまいを理解しておかないと、（最適化機能OFFの）Debug環境では正常に動くのに（最適化機能ONの）Release環境では間違った動作をするやっかいなプログラムを作ってしまう事になります。
そう言うプログラムは当然ですが、作った本人にはバグが見つけられず、無駄にデバッグに時間を費やす事になります。
「引数に渡す前に別のローカル変数に入れる」と言う、わずかな手間、わずかな行数、わずかな実行時間を惜しんだがために、分かりづらいバグを生み出す。
もちろん使っているC++によっては問題なく動く場合もありますが、潜在バグの一つなので他の処理系に移植された時に問題が出るパターンもあります。自己満足の最適化パターンが生み出すバグの一種なのですが、意外とありがちです。
話を戻すと、この様に（文章的に）やや気になる点は幾つかありますが、より高速なC++プログラムを作る必要がある場合、本書は座右の書となるでしょう。
尚、第1章の冒頭に明記されていますが、本書の最適化の技法はC++の特徴を意識した物なので、他の言語で同じ技法を使っても同様の効果が得られる保証はありません。
また、特定のCPUやハードウェア、OS固有のAPI等に依存した最適化の技法についても（軽く触れられる程度で）基本的には対象外です。
本書で紹介されるのはあくまでもC++一般で適用されるであろう最適化の技法であり、その為の知識です。
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
よく一緒に購入されている商品
+
+
総額:
当社の価格を見るには、これら商品をカートに追加してください。
ポイントの合計:
pt
一緒に購入する商品を選択してください。
この商品を見た後に買っているのは？
ページ 1 以下のうち 1 最初から観るページ 1 以下のうち 1
