適用で8コアのAMD FXが「4コア」に!? Microsoftの「Bulldozerアーキテクチャ最適化パッチ」を試す

AMDは，Windows 8でスケジューラがBulldozerアーキテクチャに最適化されると予告したときに，「Windows 7にもパッチが提供される」としていた

　2012年1月12日の記事でお伝えしたとおり，Microsoftから，Bulldozerアーキテクチャ向けの最適化パッチ（修正プログラム）が再公開された。Knowledge Base番号は「KB2645594」と「KB2646060」。AMDはかねてから，「Windows 8ではスケジューラがBulldozerアーキテクチャに最適化される。そして，Windows 7にも最適化パッチが提供される」と予告してきたので，このパッチに期待していた人も多いのではないかと思う。

　そこで4Gamerでは，実際にパッチを適用し，適用前と後で何が変わるのかをチェックしてみた。Bulldozerアーキテクチャの性能をブーストさせる魔法のアイテムとなるのかどうか，レポートをお届けしたい。

Windowsのスケジューラ最適化パッチで

OSから見たCPUはまさかのグレードダウン!?

2011年12月のパッチが非公開になり，あらためての公開となった今回のパッチだが，それに前後して，いくつかのSocket AM3＋対応マザーボードでBIOSアップデートが公開されている。BIOSアップデートの内容は新たなモデルナンバーへの対応だ。ひょっとすると，新たなモデルナンバーに対応させる必要があったために，パッチの公開がいったん延期になった可能性もあるかもしれない

　ドキュメントによれば，今回のパッチは，KB2645594が，「Windows 7とWindows Server 2008 R2がBulldozerアーキテクチャの『Bulldozer Module』に対して適切にスケジューリングを行えないため，いくつかのアプリケーションでシステム性能の低下を招く可能性がある」問題に対処するもの。「Bulldozer Moduleが頻繁にC6ステートに入ってしまい，結果，マルチスレッド化があまり進んでいない環境で性能が低下する」問題に対処するとされるKB2646060は，スケジューラにパッチを当てたときの「副作用」を抑えるものという位置づけだ。
　後者は前者の導入が前提となっており，実際，前者を導入していない状態では，インストールすることもできない。

　ちなみにKB2645594は，Windows Updateの「オプションの更新」に選択肢が現れたら，それを適用すれば導入可能。後者は，まだ最終的な検証が済んでいないとのことで，Knowledge Baseからのダウンロード提供という扱いになっている。

　さて，テストの前に簡単なおさらいから。
　Bulldozerアーキテクチャでは，2基の整数演算ユニット――AMDはこれを2基のx86 CPUコアと位置づけている――で命令デコーダや浮動小数点演算ユニット，L2キャッシュを共有するBulldozer Moduleが採用されている。「Intel Hyper-Threading Technology」（以下，HTT）のように2つのスレッドが1物理コア内におけるすべてのリソースを共有するわけではないものの，その仕様上，Bulldozer Moduleの2コアへ同時に負荷をかけると多少の性能低下が起こることは，すでに4Gamerで検証済みだ。

FX-8150のブロック図。整数演算ユニット（図中「Integer CORE」）がフロントエンドや浮動小数点演算ユニット（図中「FP Schedular」および「128-bit FMAC」），L2キャッシュを共有する形でBulldozer Moduleを構成する。Bulldozer Moduleを4基搭載するから，「8コア」プロセッサなのだ

　OSにおいて，プロセスやスレッドをCPUに割り当てる主体は，冒頭でその名を挙げたスケジューラで，スケジューラがCPUの仕様を「知っている」状態なら，ほかのコアが空いているのに，わざわざ性能が落ちるような割り当てを行ったりしない。たとえばWindowsのスケジューラはHTTを「知っている」ため，HTTに対応したCPUを搭載する環境だと，HTTの採用が性能上の不利にならないよう，プロセスやスレッドの割り当てを行える。

　一方，これまでのWindows 7（とWindows Server 2008 R2）では，Bulldozer Moduleを2基の物理CPUコアとして認識していた。つまり，「Bulldozer Moduleに含まれる2基のCPUコアが一部のリソースを共有している」ことを，Windowsは「知らなかった」わけだ。
　そのため，ほかのBulldozer Moduleが空いているにもかかわらず，同一Bulldozer Module内の2コアへプロセスやスレッドをWindowsが割り当ててしまうということが起こり得るが，今回のパッチは，Intel製CPUにおけるHTTと同じように，Bulldozer Moduleの仕様をWindowsが「知る」ためのものとなる。Bulldozer Moduleを「知っている」状態になれば，Bulldozer Moduleにとって不利になるようなスレッドやプロセスの割り当てを回避できるという理屈だ。

　「WindowsがCPUをどのように認識しているか」は，「GetLogicalProcessorInformation」というWindows APIを用いると得られる。
　今回は，MSDNに用意されたGetLogicalProcessorInformationのサンプルコードを基に，筆者が使っているコンパイラへ向けて手を加えたプログラムを実行してみた。下に示したのはその結果で，左が適用前，右が適用後だ。「Number of processor cores」が物理コア数，「Number of logical processors」が論理コア数を示している。

GetLogicalProcessorInformationベースのプログラムを実行した結果。左がパッチ適用前，右が適用後となる

　注目すべきは，パッチ適用前は「物理コア数8，論理コア数8」で，ネイティブの8コアCPUとして認識されているFX-8150が，パッチ適用後は「物理コア数4，論理コア数8」に変わっていることだ。これは，Windows 7が，AMD FXの「8コア」を4コア8スレッド仕様のCore iプロセッサと同じ扱いにしていることを示している。
　「一部のリソースを2基の物理コアで共有する」というBulldozer Moduleの実情を「HTTと同じようなもの」と判断したこと，それ自体は妥当だろう。ただ，Windowsからの見た目上は，「世界初のデスクトップPC向け8コアCPU」が，4コア8スレッド仕様のCPUへとグレードダウンしてしまうわけで，AMDのマーケティングチーム，そして，AMDファンからすると痛い変更といえそうだ。

　いずれにせよ，パッチを適用するとWindowsによって認識されるCPUの仕様が変わり，結果としてスケジューラの振る舞いも変わる。
　ではどう変わるのか。実のところ，スケジューラの動作はそう単純なものではないため，一般的なアプリケーションの挙動からそれを詳細に知るのは相当に難しい。

　OSは，時分割を使い，優先度に応じてプロセスやスレッドをCPUに割り当てている。同じプロセスやスレッドが同じCPUコアで動作し続けると保証されていたりはしない。ある「スライス」（時分割でCPUに割り当てられている時間のこと）において「Core 0」で動作していても，次のスライスでは「Core 3」で動作しているということが当然のように生じ得る。スケジューラは，「時分割やAPI呼び出しのタイミングでOS側に制御が移った後，次にプロセスやスレッドをCPUに割り当てるとき，空いているCPUコアを優先的に割り当てる」という動作を基本としているからである。

　「プロセス側から，“自分”がどのCPUに割り当てられているか」を知るのは，不可能ではないと思うものの，かなり難しそうだ。適当なタイミングでWindows APIを呼び出し，呼び出し後に“自分”が割り当てられているCPUコアを検出して，その統計を取ることは，時間をかければできるかもしれないが……。
　いずれにせよ，「パッチを適用すると，同一Bulldozer Module内における2コアでリソースの衝突が起きないようプロセスやスレッドがスケジュールされるだろう」とは言える。また，そのことは4つのスレッドを同時に動かすと，はっきりと分かる。

　下に示した画面は，MP3エンコードソフト「午後のこ〜だ」をベースとした古典的なCPUベンチマークテスト用アプリケーション「GogoWinBench」（Version 1.28）を用い，4スレッドでベンチマークを実行した時のCPU負荷の様子を見たものだ。GogoWinBenchは古いツールだが，任意のスレッド数を設定できるので，この種のテストには便利である。

　パッチ適用前だと，8コアが同列に扱われるため，8コアへ均等に負荷が分散される様子を確認できるが，パッチを適用すると，それが4つのコアにしか割り当てられなくなる。タスクマネージャのグラフはCPUコア番号ごとに並んでいるわけではないため，不規則で分かりづらいものの，残る4コアに負荷が生じていないことから，リソースの衝突を避けるようにスレッドがスケジュールされることは確認できよう。

GogoWinBenchを使い，4つのスレッドを動かしてタスクマネージャでCPUコアの負荷を見たもの。これはパッチ適用前だ。8つのコアへ均等に，時分割で4スレッドが割り当てられることが分かる

こちらがパッチ適用後。適用前と同じように4スレッドを動かすと，4つのコアにだけ4スレッドが割り当てられることを確認できる。同一Bulldozer Module内の2コアに同時に負荷をかけてしまわないよう，スケジューラが調整しているわけだ

　そのほかにも，たとえば4スレッドを使うアプリケーションの動作中に別の2スレッドを使うアプリケーションを起動したとき，リソースの衝突とキャッシュ構成を勘案したCPUの割り当て変更を行うといったようなことが行われている可能性もあるが，それを確認するのは至難の業なので今回は割愛したい。

もう1つのHotfixは

Core C6 Stateが原因で起こる副作用を修正

　KB2645594による副作用を抑えるというKB2646060だが，これは，AMD FXで「Core C6 State」と呼ばれる新しい省電力機構が採用されたことと密接に関わっている。

BIOSからCore C6 Stateを有効にすると，Windowsの電源管理の設定とはまったく無関係に，アイドル時，コアの動作クロックは1.4GHzにまで落ちる

　Core C6 Stateを有効化すると，Windowsの電力管理設定に関係なく，アイドル時にコアの動作クロックが1.4GHzにまで低下するというのは，AMD FXの基礎検証レポートでお伝えしたとおりだ。そしてこれは要するに，WindowsがCore C6 Stateに対応していないため，CPU側で負荷に応じて勝手に動作クロックを上げ下げしているということになる。

　なので，KB2645594の適用によってスケジューラの挙動が変わると，少数のスレッドを使うアプリケーションでは，Bulldozer Moduleの一方のコアにしか負荷がかからなくなり，いきおい，動作クロックが上がらず，1.4GHzでスレッドが処理されてしまう可能性がある。KB2646060は，この症状に対策を施すもので，適用すると，Bulldozer Module内で片方のコアにしか負荷がかからないようなケースでも，Core C6 Stateから復帰できるようだ。

　KB2645594だけ適用し，KB2646060を適用しない場合は，性能の低下する可能性があるものの，それは，Core C6 Stateから復帰できないほど軽い負荷のときに限定される。「KB2646060を当てないと性能低下が起きる」というのは，比較的まれなケースということになるだろう。
　なお，KB2646060を適用しても，Windowsの電源管理設定と無関係にクロックが1.4GHzに落ちるという現象に変化はなかった。電源管理の設定とCore C6 Stateの挙動が一致しないのは仕様ということになりそうである。

アプリケーションに対する

影響は極めて小さい

　4Gamer的に重要なのは，スケジューラの振る舞いが変わったことで，ゲームの性能に変化が生じるのかどうかだ。今回は表のテスト環境を用意して，「3DMark 11」（Version 1.0.3）と「Battlefield 3」（以下，BF3）の「THUNDER RUN」シークエンスでベンチマークテストを取ってみよう。
　3DMark 11のテスト方法は，テストを「Performance」プリセットに絞る以外，ベンチマークレギュレーション11.2準拠。BF3のテスト方法は2011年11月5日のテストレポートに準じる。


　3DMark 11では，CPU性能のみを比較すべく，「Physics」テストの結果も抜き出してみたが，グラフ1〜2を見る限り，スコアは誤差程度しか変わらない。ひいき目に見ても，スコアの向上率はごくわずかだ。
　Physicsテストはマルチスレッド処理に最適化されているのだが，現実的な話，4スレッド以上を用いた場合，リソースの衝突なしにはスケジューリングできなくなるので，スケジューラをいくら調整してもベンチマークスコアの違いがほとんど生じないというのは容易に想像できる。

　KB2646060も適用した場合と，KB2645594のみを適用した場合とで，違いはないに等しく，むしろグラフ2ではスコアの低下も見られるが，これは誤差と断じて問題ないと思う。先ほど述べたとおり，KB2646060は負荷が低い場合に性能低下をもたらすので，十分にCPU負荷の高い3DMark 11でスコアが変わらないのは，むしろ当然だろうと思う。


　BF3のテストにあたっては，GPU負荷をできる限り下げ，CPU性能差が分かりやすくなるよう，グラフィックス設定のプリセットを「低」，解像度を1280×720ドットにそれぞれ指定したが，やはり，ベンチマークテストの結果に違いはまったくといっていいほど生じていない（グラフ3）。



　……以上，パッチが，AMD FXの性能を劇的に向上させてくれる魔法のアイテムではないということを確認できた。そもそも論として，Bulldozer Moduleにおけるリソースの衝突はHTTほどペナルティが大きくない（関連記事）ので，スケジューラで衝突を避けるような最適化が行われても，目に見えるようなスコアの向上がないというのは納得できる話だ。

　ただ，KB2645594は「適用しないより適用したほうがいい」はずで，だからこそMicrosoftはWindows Updateで公開したのだろう。AMD FXユーザーはひとまず自己責任で導入しておくことをお勧めしたい。
　一方，KB2646060はまだテスト中というステータスで，また，筆者が確認した限り，一度導入するとアンインストールできなかった。「KB2645594の導入により，特定のゲームタイトルで大幅な性能低下があった」などといった問題がない限り，正式版の登場を待ったほうがいいかもしれない。

※2012年1月16日16：15頃追記
　初出時に欠けていた，KB2646060に関する言及を追加しました。追加にともない，一部で表記の変更を行っている部分がありますが，ご了承ください。

Microsoftのサポートページ，KB2645594

Microsoftのサポートページ，KB2646060

AMD公式blogの該当ポスト