GPUとしてのTrinityを検証する。(Trinity Review No.4)

 さて、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では何とかギリギリ踏みとどまれた、という感じだが、次はどうするのかしらん。

Share

PiledriverコアとしてのTrinityを見てみる。(Trinity Review No.3)

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

 その1◆処理速度はどうよ?

 ということで、実際にベンチを回してみることに。
 以下は全て、メモリは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のマイナーバージョンアップである、ということを再認識しましたとさ。

 その2◆消費電力はどうよ?

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

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

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

 その3◆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の低さが露呈してしまうワケで。
 一言で言うなら「やりくり上手の大喰らい」というところか。

Share

Windows 7 x64 常用開始。

 ということで、未だServicePack2どころか一般発売前だというのに、常用環境をWindows 7 x64 Ultimateに切り替えてしまいました。
 とりあえず今日までに未だ一つも64bitアプリをインストールした覚えは無いけれども(除:開発関連)、システムが32bitの壁を意識しないで済むというのは精神衛生上非常に宜しいですな。

 ちなみに、常用アプリで「動かない」というのは結局見あたらず。まあ常用機なので特別ヘンなアプリも入れてないのだけど。
 というか、多分一番問題になるのは開発環境とゲームなのだろうが、前者は大分昔にVS2008にしてるし、後者はそもそも入って無いし。

 #但し明示的に権限やらを設定してあげないといけないモノは多かったけど。

 あと、巷ではやたら完成度が高いことになっているが、んじゃ全くヘンな挙動が無いのかというと決してそんなことはなく。
 特に、Vistaになってから挙動の不安定&不思議さが収まらないネットワーク周りのヘンテコ挙動は今回も健在。アヤシイ時はシステム再起動が効きます、希にこれが最後のトドメになって崩壊するけど。

 #殆ど同じコア使っている2008 R2ではここまでヘンじゃないんだが。
  ネットワークのゾーニング機能周り(「ホーム」「パブリック」ってアレ)がボロボロなんだろうな、きっと。2008R2に無くてWin7にだけあるモノといったらこれぐらいしか思いつかないし。

 まぁそういうワケなので、普通の人は右見て左見て、ServicePackの様子見て。本人がその気になったら、ということで良いのでは。当方の場合、64bitの誘惑に耐えられなかったということで。

 但し乗り換える気になってしまった場合、どうせならx64版を激しくお勧め。
 既に時代は64bit。メモリは4G超積んでもシステム全体から見たら大した金額にならないし、64bit OS上でも32bitアプリは普通に動くし、どうしても駄目ならVMware playerもVirtual PCもありますがな。
 そして何より、広大なメモリ空間がもたらす次世代computing環境をご堪能あれ。

 ◇

 おまけ、常用機のWindows Experience Indexの画像貼っておきますね。環境は以下の通り。

 CPU:Athlon II X4 605e (Propus 45W 2.3GHz)
 MEM:DDR3-1066 ECC 2GB(2Bank) x4 Total 8GB Unganged Mode
 VGA:AMD 785G/Radeon IGP 4200 500MHz(Default) UMA 512MB+SidePort 128MB/DDR3-1333
 HDD:WD15EADS AHCI(SB710)

 当方は信仰とハコの都合上、785GでATXにECCメモリというややアレな組み合わせだが。
 折角省電力でパワフルなCPUとIGPの組み合わせなのだから、よっぽどイロイロ載せる予定でも無ければ、MicroATXでコンパクトに組むのがイイ感じだと思う、うん。

785G AthlonIIX4-605e Windows7 x64

Share

e1000とe1000eはそんなに違うか?~計測編~

 GbEをベンチしてみたシリーズ数字編。
 取り敢えず、画像をぺたっと。

Benchmark Result

 ・・・いやね、Excelで表を作ったら、それをExportするのが面倒で。
 これでも読めるからイイでしょ、ということで。

 netperfのコマンドラインは以下の通り。

 puddy_netperf -H 相手IP -l 30 — -s 65535 -S 65535

 CPU負荷率は目測。目安程度でしかないので念のため。

 CIFS計測のコマンドラインは以下の通り。

 copy ¥¥相手IP¥共有名¥ファイル名 ローカルドライブ:¥作業ディレクトリ

 更に、CIFS転送効率も目測。
 とはいえGB単位のファイルを複数回転送していて、且つ1回目は捨てているので、そこそこの数字ではあると思う。

 #1回目を捨てるのはDisk I/Oの影響が大きいため。
  2回目以降は転送元側のCacheにFileが乗るので多少影響が減る。

 ・・・で、数字並べて疲れたのでここから先は考察編へ。

Share

e1000とe1000eはそんなに違うか?~準備編~

 ・・・という話が。

当方:「カタログスペックから見るだけでもBuffer削られたりしてるし、やっぱり廉価版なんでない。好きな方買えば?」
A:「お前ベンチマークしたってことは両方触れるんだろ、どうなのよ」
当方:「ESX 3.5のupd3突っ込んだらNICが消えて大慌てした記憶が蘇るからe1000eキライ」
A:「それはお前がアホなだけだろが」
当方:「ホントのこと言うなコラ。冗談は兎も角、自分用にわざわざIntel買うならPTだと思うがなあ。繋がりゃいいってレベルで良ければもっと安いのいくらでもあるし」
A:「そんなもんかね。大差ないって話もあるし」
当方:「環境とかドライバにもよるんでない。前回ベンチしたのはWindsor 2.6GHzにAMD780GとXP SP3っていうAMD Orientedな環境だったけど、Intel Orientedな環境だと違うかも知れんし。あとドライバもUpdateされてるし」
A:「ま、NIC本体以外の要素も大きいからなあ」
当方:「そいやIntel Orientedな環境が丁度空いてるから、そっちでもやってみるか。ちょっと古いし2003鯖だけど」

 ということで、もう一回ベンチマークしてみた。
 比較対象として用意出来たのはBCM5721(オンボード)とYukon (88E8053) 1枚だけだけど。

♯Yukonが2枚手配出来なかったのでYukon対向が確認出来ないのと、蟹が居ないのがちょい残念。

 何か極一部には重要らしいので、環境一通り書き出してみた。

  • HP ML110 G4 + Core2Quad Q6600 + DDR2-667 8GB mem
  • HDD : HD103UJ with Onboad ICH7
  • SLOT : MCH側PCIe 8x Slot (いちいち挿し替えた)
  • Hub : Corega CG-SW24GTX
  • Windows2003Server SP2 with 09/04迄のWindowsUpdate適用済
  • レジストリ設定によるRWIN等は全て標準のまま
  • PROSet : 14.0 (PT/CT共通)
  • Broadcom : 11.7.2 + BACS 11.7.5
  • Yukon : 10.69.2.3 + Util 10.10.7.3
  • NetPref : 2.1pl1/Win

 今回はSEPは無し、2003突っ込んだままの素のパフォーマンス計測。
 PROSetは前回は13.2使って、その頃はe1000とe1000eは別ドライバになっていたのだが、14.0になって全部込になりましたな。BACSとMarvell Utilityは突っ込んだけど設定は一切無し。

 あと、PT Serverは高いからって買って貰えなかったんだいっ。
 そこ、余計なツッコミしないっ。

 ◇

 ドライバセットアップメモ。
 全部いわゆる「ベンチマーク設定」だが、今時これを常用してるトコも多いんでないだろか。

 PRO/1000 プロパティはデフォルトから以下のように変更。
 どうでもいいが英語のままの方が意味分かり易い気がするのは自分だけかね。

パフォーマンスのオプション>割り込み加減率 オフ
パフォーマンスのオプション>受信記述子 2048 (最大値)
パフォーマンスのオプション>送信記述子 2048 (最大値)

 Gigabit CT プロパティはデフォルトから以下のように変更。

パフォーマンスのオプション>割り込み加減率 オフ
パフォーマンスのオプション>受信バッファ 2048 (最大値)
パフォーマンスのオプション>送信バッファ 2048 (最大値)
受信側スケーリング キュー 2 (最大値)

 Broadcom NeXtreme プロパティはデフォルトから以下のように変更。

Number of Receive Descripers 512 (最大値)
Number of Transmit Descripers 600 (最大値)

 Yukon プロパティはデフォルトから以下のように変更。

割り込み節度 オフ
受信バッファ 512 (最大値)
送信バッファ 512 (最大値)
毎秒最大IRQ 30000 (最大値)

 ・・・長くなったので一旦切り。
 ベンチマーク数字は次へ。

NIC

Share