AMD FXシリーズに関するブロガー勉強会 2.22 YOU CAN (NOT) ADVANCE
お前Advanceって言いたかっただけだろ？(AMDなだけに)
と突っ込まれると何も言えない。GPGPU AdCの合間を縫いつつのFXシリーズの話です。
さて、今日はPiledriver……の話をする前にBulldozerの話を致しましょう。
なぜBulldozerの話？
Piledriverではアーキテクチャに改善が入りました。では、前世代と比べてどれぐらい向上したのでしょうか？
それも実アプリケーションで！
……ベンチマークのためのアプリケーションで性能向上とかはいいやすいんですよ(例:LAPACK, LINPACK)
Intelがﾏｼﾞｷﾞﾚした論文とかもありますし、実際に使用するようなものでどういった性能向上が得られるか、というのが非常に焦点になると思うのです
さて、今回ベンチマークに使用するのはNAS Parallel Benchmarkと、個人的に気にしている分岐予測機構についての結果をメモリたいと思います。
割と数値計算分野でよく扱われるものが含まれているNAS謹製のベンチマークツール。READMEを見るとSGIのスパコンで動かしたりしていた感じがしていて、MIPSか時代の流れを感じるなぁとか思ってみたりします。僕にとってはMIPSというのはPocketPostPetとかWindowsCE機のCPUなんですよね
つーか本当はPARSECかPhoronixを動かそうとしてたんだけどなんか動かなかったからブチ切れながらNAS Parallel benchmarkにしたんですよ。
PARSECはもっと親切になるべき。というかコードメンテするべき。PhoronixはDLに時間かかりすぎるので断念しました。いいツールだとは思います
分岐予測のはなし
たびたびこのブログでは登場するw_o大先生のところからコードを引っ張ってきます
http://int.main.jp/txt/k10/
で使用されたコードですね
(ちなみに、w_o先生がすでに一度Trinityについての記事を書かれていますが、本稿はBulldozer&Piledriverについての比較記事ですんであしからずご了承ください)
さて、Bulldozerでは以下の結果となりました
1,392,146 branch-misses # 4.05% of all branches [84.00%]
3,140,544 branch-misses # 5.59% of all branches [83.56%]
6,342,833 branch-misses # 5.37% of all branches [83.86%]
12,692,306 branch-misses # 5.31% of all branches [83.62%]
25,767,303 branch-misses # 5.24% of all branches [83.50%]
51,348,832 branch-misses # 5.19% of all branches [83.38%]
103,111,451 branch-misses # 5.19% of all branches [83.33%]大体4%から5%の分岐ミスが発生しています
この辺がPiledriverでは改善されているのでしょうか？ 話によると、分岐予測機構は改善されているっぽいとのことですが……
NAS Parallel Benchmarkの話
NAS Parallel Benchmarkとは、は以下のサイトが詳しいです
http://mikilab.doshisha.ac.jp/dia/smpp/01_bench/naspara.html
同志社大学さまありがとう！
先のサイトによれば、NAS Parallel benchmarkは以下のような問題に対するベンチマークが取れます
| EP | 乗算合同法による一様乱数、正規乱数の生成 |
| MG | 簡略化されたマルチグリッド法のカーネル |
| CG | 正値対称な大規模疎行列の最小固有値を求めるための共役勾配法 |
| FT | FFTを用いた３次元偏微分方程式の解法 |
| IS | 大規模整数ソート |
| LU | Synmetric SOR iterationによるCFDアプリケーション |
| SP | Scalar ADI iterationによるCFDアプリケーション |
| BT | 5x5 block size ADI iterationによるCFDアプリケーション |
この中で着目したいのはEPでしょうか。
EPは浮動小数点演算をメインに扱うもの。つまり、Bulldozerに対して天敵ともいえるアプリケーションであるといえます。
今回は、シングルスレッドでFPUを占有した場合、マルチスレッド(4スレッド2モジュール使用)でFPUを奪い合う場合についてみていきたいと思います
条件はclassAです
さて、Time in seconds とMop/s totalを見ていきましょう
Time in seconds
| thread | 1 | 4 |
|---|---|---|
| BT | 125.14 | 86.29 |
| CG | 1.63 | 1.04 |
| EP | 41.64 | 13.29 |
| FT | 6.66 | 3.25 |
| IS | 0.00 | 0.00 |
| LU | 63.81 | 25.60 |
| MG | 2.10 | 1.44 |
| SP | 92.91 | 66.29 |
Mop/s total
| thread | 1 | 4 |
|---|---|---|
| BT | 1344.80 | 1950.23 |
| CG | 919.80 | 1438.39 |
| EP | 12.89 | 40.41 |
| FT | 1071.38 | 2195.13 |
| IS | inf | inf |
| LU | 1869.64 | 4660.85 |
| MG | 1855.61 | 2711.80 |
| SP | 914.93 | 1282.41 |
…あれ、意外にスケールしてる…？
EPを見ると、時間にして41.64->13.29,Mop/sにして12.89->40.41と、割と順当に1/4,x4になっています
スケジューラーがいい感じになっているのかしら？
と疑問に思いながら1スレッドと4スレッドの場合のperf statを取ってみる
$ export OMP_NUM_THREADS=1
$ perf stat ./ep.A
(略)
Performance counter stats for './ep.A':
42024.027852 task-clock # 0.998 CPUs utilized
4,382 context-switches # 0.104 K/sec
0 CPU-migrations # 0.000 K/sec
481 page-faults # 0.011 K/sec
155,874,426,498 cycles # 3.709 GHz [83.30%]
5,562,831,923 stalled-cycles-frontend # 3.57% frontend cycles idle [83.35%]
115,610,579,562 stalled-cycles-backend # 74.17% backend cycles idle [33.35%]
56,479,019,482 instructions # 0.36 insns per cycle
# 2.05 stalled cycles per insn [50.01%]
6,411,166,114 branches # 152.560 M/sec [66.67%]
428,316,636 branch-misses # 6.68% of all branches [83.33%]
42.113603511 seconds time elapsed
$ export OMP_NUM_THREADS=4
$ perf stat ./ep.A
(略)
Performance counter stats for './ep.A':
46960.709766 task-clock # 3.957 CPUs utilized
4,960 context-switches # 0.106 K/sec
5 CPU-migrations # 0.000 K/sec
844 page-faults # 0.018 K/sec
169,874,912,351 cycles # 3.617 GHz [83.29%]
4,432,542,175 stalled-cycles-frontend # 2.61% frontend cycles idle [83.35%]
54,275,223,099 stalled-cycles-backend # 31.95% backend cycles idle [33.36%]
56,655,235,438 instructions # 0.33 insns per cycle
# 0.96 stalled cycles per insn [50.03%]
6,411,949,722 branches # 136.539 M/sec [66.67%]
431,403,520 branch-misses # 6.73% of all branches [83.33%]
11.866363016 seconds time elapsed順等か…？
EPが4倍になっているのに対して、4倍になっていないものがCGとかMGとかですね
（クロックがかわっているのはBIOSで止めろよとか思われそうですね）
だとすると、コレは完全にFPUがネックで詰まっているのだと考えられます
PiledriverではFPUのスケジューラが改善されているということですので、この辺りの変化があると考えられます
では、次はPiledriverを見ていくことにしましょう
くみ上げレポートとかも待っててNE!!
