さて、Trinityシリーズの4回目。GPUについて見てみましょう。
　とはいえ、そこらのベンチマークアプリの値なんていくらでも見られるので、その辺りは割愛して。

　その1◆「メモリクロックがGPUパフォーマンスを直撃する」は健在か？

　兎に角GPUにはメモリ帯域が苦しいのがAPUの特質。なのでメモリのクロックアップは速度向上に直結する。
　Llanoは実際そうだった。では、Trinityはどうだ？

　論より証拠。3DMark 11で試してみた。

　DDR3-2133　→　P1603
　DDR3-1866　→　P1540
　DDR3-1600　→　P1466
　DDR3-1333　→　P1360

　・・・相変わらずですなこりゃ。

　定格であるDDR3-1866からOCである2133に引っ張り上げるだけで、これだけパフォーマンスが改善される。
　1600→1866と比べると伸び率は落ちてはいるが、それでもDDR3-2400の値を期待出来る程度ではある。

　＃DDR3-2400は設定を詰め切れずベンチ取れず・・・何しろここの管理人はOC慣れしていないもので。

　つかこの数字を見ると、AMDが当初DDR3-2133を定格にしたかったというのも納得というかなんというか。

　逆に、低価格故に選択する人が多いと思われるDDR3-1600では、APUの定格であるDDR3-1866と比べても相当パフォーマンスが落ちていることにも注目すべき。
　これじゃ折角のGPUが活かせてない。

　その2◆メモリクロック向上でパフォーマンスバランスはどうなる？

　取り敢えず、メモリクロック向上でグラフィック性能が上がるのは明確になった。
　ここで、先程の数字をもちっと詳しく。

　DDR3-2133　→　P1603 ／ 1471 ・ 3560 ・ 1393
　DDR3-1866　→　P1540 ／ 1414 ・ 3554 ・ 1307
　DDR3-1600　→　P1466 ／ 1345 ・ 3466 ・ 1234
　DDR3-1333　→　P1360 ／ 1250 ・ 3382 ・ 1102

　それぞれ Graphics・Physics・Combine。

　ここで注目すべきは、DDR3-1866とDDR3-2133でGraphicsの値は＋57と伸びているのに、Physicsの値が殆ど誤差程度しか変わっていないこと。
　これは即ち、DDR3-1866より上にはCPU側が追いついてこないということに他ならない。

　＃但しDDR3-1600・DDR3-1333時のPhysicsの値の落ち込みにも注目すべきね。

　対するGPU側は明らかに伸びしろがあり、DDR3-2400ではP1650、Graphics 1515ぐらいは望めそうではある。
　メモリの設定を詰めればもう少し伸びるかも、とも思わせる数字ですな。

　結局、パフォーマンスバランスという意味では最初っからGPU偏重なのがAPUなのだが、そのバランスは定格使用時にギリギリ保たれていると言って良いのかも知れない。

　その3◆GPUまとめ。

　・A10-5800Kの内蔵GPU速度は、定格のDDR3-1866メモリを使っていても単体VGAであるRadeon 6570とほぼ同等。
　・GPUに限ってみるとメモリ速度は相変わらず重要、DDR3-2133を使えばP1600は出せる。これは単体VGAであるRadeon 6570以上の速度ということ。
　・逆に低速メモリは命取り。

　こんな感じかな。
　いやはや優秀ですよ。マザーさえ選べば3画面出力も出るし、GPUに関しては死角無し、と言っていいかもしれない。

　とはいえ、APUのメモリ帯域はもう限界に来ているのも確か。
　Trinityでは何とかギリギリ踏みとどまれた、という感じだが、次はどうするのかしらん。

　さて、Trinityのシリーズ3回目。いよいよベンチとかが来ます。
　今回はテーマ毎に一段落ということで。
　まずは、Piledriver Coreの出来をチェックしてみましょ。

　その１◆処理速度はどうよ？

　ということで、実際にベンチを回してみることに。
　以下は全て、メモリはDDR3-1866相当で駆動。要するに完全定格ですよ。

　CrystalMark 2004R3（4.0GHz@TC作動 2Unit4Thread）
　→　ALU 52707、FPU 43442、Memory 31944。
　→　GDI 10487、Direct2D 2728、OpenGL 3760。

　非常にLegacyなベンチマークだが、現在でもゲームとコンテンツクリエイション系以外の殆どのアプリはこの頃から構造的に進歩していないので、実際問題としては比較基準として使い物になると思われる。
　といっても比較対象が無いと比べようがないので、参考値を。

　参考値＞Intel Core i3-2100（3.1GHz 2Core4Thread）
　→　ALU 45000、FPU 45000、Memory 35000。
　→　GDI 16000、Direct2D 2700、OpenGL 3800。

　参考値＞AMD PhenomIIX4 910e（2.6GHz 4Core4Thread）
　→　ALU 40000、FPU 39000、Memory 31000。

　整数演算のIPC（クロックあたりの命令実行効率）はDenebと比べて2割減といったところの模様。
　Deneb 2.6GHzとタメになるのはPiledriver 3.1GHz程度と想定される。
　なのでクロックダウンを行い、実際に検証してみた。ついでにCore i3とクロックも揃うし。

　CrystalMark 2004R3（3.1GHz固定 2Unit4Thread）

　→　ALU 40953、FPU 33109、Memory 29243。
　→　GDI 8739、Direct2D 2515、OpenGL 3726。

　うん、こんなもんだ。
　一方、泣きたくなるのが対SandyBridge。
　ぱっと見るPiledriverの方がおおよそ10％減、まぁこの程度なら・・・とも思いきや、コア数が倍違うんですよコレ。

　更にオマケ。2.6GHzまで落としてみた。

　CrystalMark 2004R3（2.6GHz固定 2Unit4Thread）

　→　ALU 34011、FPU 27391、Memory 27306。
　→　GDI 7877、Direct2D 2390、OpenGL 3676。

　う～む。正直コメントしづらい。なので、話を進めて。

　浮動小数点演算のIPCを見てみると、対Denebだと約3割減、対SandyBridgeで4割減といったところか。
　構造的に浮動小数点演算を「見捨てて」いる形にも関わらずこの数字というのは、個人的には善戦していると言っていいと思う。

　＃というか、ここまで割り切った構成で且つこれだけの成績を出せるってのは、ある意味整数演算よりPiledriverの思想を体現している気がする。

　とまぁ、こんなところで。
　Piledriverは良くも悪くもBulldozerのマイナーバージョンアップである、ということを再認識しましたとさ。

　その２◆消費電力はどうよ？

　取り敢えず他に思いつかないのでOCCTを使って試してみる。　

　4.2GHz　→ 128W
　4.0GHz　→　122W　（3.8GHz定格設定だがTurboCoreが効いて全コア4GHzで動作状態）
　3.0GHz　→　108W

　3.8GHz　→　 40W　（アイドル）

　当方の環境ではTurboCore ONにすると全コア4.0GHzで駆動する模様。最初のベンチでもTCで4GHzになっていたので。
　そういう意味では、TurboCoreって結構効き易い模様。

　但し全コア4.2GHzでVcore定格のままではかなりフラフラで、OCCT放置も1時間は大丈夫だったが2時間は超えられず。
　TC4.2GHzってコア性能をかなりギリギリまで攻めている模様。
　まあCPUの個体差もあるし、電源がヘボい（＆くたびれてる）ということもあると思うので、もっとまともな電源使えば余裕なのかも知れないが。
　とはいえこの価格帯のシステム組む人が￥20Kを超えるような「しっかりした」電源を選ぶとも思えないので、一つの目安程度にはなるかと。

　＃ちなみに、電圧盛ったら全コア4.2GHzでもさくっと安定したが、消費電力も盛り分にふさわしく増加。
　　VCore盛りは2乗で消費電力に効いてくる、その分発熱にもダイレクトに反映される、のでね。

　一方で、クロックを3.0GHzまで落としても消費電力は意外と減らない。つかたった14W差？
　なんというか、この辺りがPiledriverのアキレス腱なのね、と納得してしまった。

　そもそも、CMOS回路の消費電力は大雑把に言うとクロックに比例し、電圧の２乗に比例する。
　ところが最近のCMOSでは微細化の影響で、この比例分に加えて「漏れ電流」という、常時流れっぱなしの電流による「使用電力の底上げ」があり、こいつがヘタすると比例分よりも大きかったりするというとっても辛い状態になっている。
　今回、CPUクロックという「比例分」を下げても消費電力があまり下がらないということは、要するに「漏れ電流」が多いということ。逆に言うと、消費電力全体のうちCPUが実際に使える分が少ないということでもあり、端から見ると「電力効率がよろしくないCPU」ということになってしまう。

　勿論、このままではモバイル等では使い物にならないので、実際には色々と工夫をして消費電力を押さえ込んでいるワケであり。

　その辺りの状況が垣間見えるのがアイドル時の消費電力の低さで、フルパワー稼働時との差分（と電源の変換効率）を考えると、これはかなり優秀な値と言っていい。
　実際に消費電力やクロック変動を監視しながらベンチ等を回してみると、「すぐに跳ね上がるがすぐに落ちる」という挙動を繰り返している様子が見て取れるし。

　その３◆Piledriverコアのまとめ。

　・CPU性能では同クロック・同スレッド数のSandyBrigeと比較して、整数演算で1割減、浮動小数点で4割減。
　・現在のソフトウェア状況を鑑みればコア構成も特に問題無いと思われる。
　・TurboCoreって意外と効き易い。
　・相も変わらず得手不得手が強烈。
　・省エネ制御は優秀、けど本気出すとやっぱ熱い。やりくり上手の大喰らい。

　取り敢えずまとめるとこの辺りかな。

　まず、性能面。
　IPCとかコア絶対性能は確かにボロ負けだが、パッケージとしてのコストパフォーマンスという見方をすれば悪くない。
　この辺りはもうAMDは「織り込み済み」でしょう、この値段だし。
　これはコレでありだと思いますよ。

　＃勿論もっと高性能なCPUコアが載っていれば嬉しいに超したことは無いのだけど。

　CPUコア・スレッド構成についても然り。
　WindowsXPが出回った頃と違って、Windows 7や8、そして最近のアプリなら4コア程度ならそこそこ効率的に回せるようになっている。
　なので、実際にシステムを使う状況では、Intel CPUとのコア特性の違いもあまり問題にならないかと。

　＃逆にこの時代だからこそPiledriverコアでも許されるというか。
　　これが8コアとか言い始めるとまたおかしなことになるのだが・・・FXシリーズはここがネックだよなぁ。

　あと、TurboCoreは意外と回る模様。
　当方はSAMURAI MASTERという時代物を取り出したが、世間を見ればこれより冷えて静かなCPUクーラーなんかいくらでもある。
　かなり多くの環境でTCの恩恵にあずかれるのでは。

　更に、相も変わらず得手不得手は強烈。
　消費電力を監視していると面白いのだが、ベンチ全力で回している筈なのに電気全然喰ってないよ何コレ、という状況が結構見られる。
　要するに命令デコーダが追いついていなくて実行ユニットがサボっている、或いはその逆になっている状態になっているということで、そんな状況では勿論ベンチの値も低い。

　＃これでもBulldozerより改善されたらしいので、そうなるとBulldozerって…（以下略。

　最後に、省エネ制御については優秀だという感想。
　かなり細やかに制御していて、何としても最低限の電力で動かそうと涙ぐましい努力をしている様子が伺える。
　が、フルパワーを出すとIPCの低さが露呈してしまうワケで。
　一言で言うなら「やりくり上手の大喰らい」というところか。