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

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

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

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

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

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

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

　ドキュメントによれば，今回のパッチは，「Windows 7とWindows Server 2008 R2がBulldozerアーキテクチャの『Bulldozer Module』に対して適切にスケジューリングを行えないため，いくつかのアプリケーションでシステム性能の低下を招く可能性がある」問題に対処するためのものだ。
　導入は基本，Windows Updateからになる。Windows Updateの「オプションの更新」にKB2645594の選択肢が現れたら，それを適用すればOKだ。

　さて，テストの前に簡単なおさらいから。
　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と同じようなもの」と判断したこと，それ自体は妥当だろう。ただ，「世界初のデスクトップ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の割り当て変更を行うといったようなことが行われている可能性もあるが，それを確認するのは至難の業なので今回は割愛したい。

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

影響は極めて小さい

　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スレッド以上を用いた場合，リソースの衝突なしにはスケジューリングできなくなるので，スケジューラをいくら調整してもベンチマークスコアの違いがほとんど生じないというのは容易に想像できる。


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



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

　ただ，「パッチを適用しないよりは適用したほうがいい」はずで，だからこそMicrosoftは公開したのだろう。AMD FXユーザーはひとまず自己責任で導入しておくことをお勧めしたい。
　見た目が4コア8スレッドCPUへどグレードダウンしてしまうのは気がかりかもしれないが，CPUそのものが変わってしまうわけではないのだし。

Microsoftのサポートページ，KB2645594