時代はマルチコアへ

Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster

Brief aside on instruction reordering and memory models: Note that some of what I just called “optimizations” are actually far more than optimizations, in that they can change the meaning of programs and cause visible effects that can break reasonable programmer expectations. This is significant. CPU designers are generally sane and well-adjusted folks who normally wouldn’t hurt a fly, and wouldn’t think of hurting your code… normally. But in recent years they have been willing to pursue aggressive optimizations just to wring yet more speed out of each cycle, even knowing full well that these aggressive rearrangements could endanger the semantics of your code. Is this Mr. Hyde making an appearance? Not at all. That willingness is simply a clear indicator of the extreme pressure the chip designers face to deliver ever-faster CPUs; they’re under so much pressure that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster. Two noteworthy examples in this respect are write reordering and read reordering: Allowing a processor to reorder write operations has consequences that are so surprising, and break so many programmer expectations, that the feature generally has to be turned off because it’s too difficult for programmers to reason correctly about the meaning of their programs in the presence of arbitrary write reordering. Reordering read operations can also yield surprising visible effects, but that is more commonly left enabled anyway because it isn’t quite as hard on programmers, and the demands for performance cause designers of operating systems and operating environments to compromise and choose models that place a greater burden on programmers because that is viewed as a lesser evil than giving up the optimization opportunities.

CPU設計者たちは強いプレッシャーを受けながら、高速CPUを設計している。高速化を何よりも優先するため、プログラムの実行フローが変更されたり、最悪の場合、動作しなくなることもありえる。

プログラム内に記述した命令の順序が勝手に変更され、メモリアクセスの動作検証が難しくなる。この点に触れておきたい。私は"最適化"という表現を使用したが、実際に行われている"最適化"は私たちの予想をはるかに超えたものである。現実の最適化では、私たちのソースコードの意味が変更されてしまい、開発者である私たち自身が自分のプログラムの動作を評価できない事態を招いている。この点はきちんと認識しておくべきである。CPUの設計者たちは、健全な精神の持ち主でり、通常なら、一匹の虫も殺さない。私たちのコードを傷つけることなど想像すらできない。しかし、近年、彼らはスピードを上げるために、積極的に最適化を行うようになった。彼らはその危険性を熟知しているにもかかわらずである。危険性とは何か。それは、最適化設計がソースコードの意味を勝手に変えてしまうことである。彼らはジキルではなく、ハイドを目指しているのか。いや、それは違う！彼らは焦っているのである。彼らは、より高速なCPUを求める市場要求を満たそうとしているのである。それはすごいプレッシャーのはずだ！高速化を優先すると、プログラマの汗の結晶であるたコードの意味を変更したり、一部のプログラムが動作不能になる事態を招く危険がある。特に、読み書き処理の再構成はそのような危険性をはらんでいる。プロセッサが書き込み動作を勝手に再構成できるようになっていると、プログラマの意図とプロセッサの意図が一致しなくなる可能性が出てくる。これは深刻な問題であるため、通常は無効になっている。読み出し動作も基本的には同様の問題を抱えているが、プログラマへの負担が比較的軽いため、通常は、デフォルトで有効になっていることが多い。OSや動作基盤の設計者たちは、プログラマへの配慮を示しながらも、場面場面で妥協し、最適化モデルを選択している。その種のモデルでは、プログラマの負担を抑えながらも、実質的には、パフォーマンスの向上が優先されている。