Numerical Algorithms Group Ltd.
イントロダクション
InterlagosプロセッサーはAMD社の16コアOpteronプロセッサーであり、HECToRプロジェクトのフェーズ3で実装されています。このプロセッサーは32nmプロセスのBulldozer/AMDファミリーの15番目のアーキテクチャーであり、そのコアは以前の12コアMagnyCours(MC)プロセッサーのような45nmプロセスAMDファミリーの10番目の設計よりも、多くのリソースを搭載していますが、インテルの45nmプロセス12コアのWestmere(WM)のようなハイパースレッディング・プロセッサーほど多くのリソースを持つものではありません。本レポートは、Interlagosプロセッサー・アーキテクチャーを説明し、ベンチマーク性能の測定結果を示し、以前のAMD/Margny-Cours(MC)およびインテル/Westmere(WM)との比較をしながらアーキテクチャーの観点から結果を分析しています。
Interlagosプロセッサー・アーキテクチャー
MCと比較してILの設計で最大の明確な相違点は、コアのペアが、リソースにおいて大きな比率を占める"モジュール"に配置されたことです。図1にモジュールの2つのコア間でリソースが共有される様子を示します。
図1 ： Interlagosモジュール。モジュールは2つのコア(薄青色部分)から構成され、これらは独立したL1データキャッシュ、レジスターおよび整数演算ユニットを持つ。共有リソースとして、L2データキャッシュ、浮動小数点演算ユニットおよびフェッチとデコード命令のためのハードウェアが存在する。
これはMCプロセッサーの隣接コアがL2キャッシュからリソースを共有すること、およびハイパースレッディング時のWMプロセッサーの仮想コアが、制御部と通常目的かつ浮動小数点演算レジスター以外の図1に示す全てのリソースを共有することと対照的なものになっています。つまり、ILモジュールの設計は、MCプロセッサーでのリソースの全分割と、WMプロセッサーの全てを共有する場合との間の、中間的な方法をとっていると言えます。これはCPUの整数演算と浮動小数点演算を切り離すAMDの最初のステップとして、GPUほどにルーズな結合でないにせよ、CPUから切り離されたコプロセッサーにより浮動小数演算を行うという、将来的な融合的プロセッサーへのステップであると見ることもできます。
モジュールをより詳細に見ると、図2に示すように共有された浮動小数点演算ユニットは、単一の256ビットパイプラインとして結合可能な2つの128ビットのパイプラインから構成されています。つまりこの浮動小数点演算ユニットはクロックサイクル毎に、2つの128ビットSSEベクトル命令、または一つの256ビットAVXの加算あるいは乗算ベクトル命令を実行可能です。さらにSSE、AVX命令に加えて新たに、浮動小数点演算ユニットの理論性能を実行的に倍にする256ビット融合積和演算(fused multiply-add)命令が存在します。これは乗算が加算される前に丸められることがないため、乗算とその後の加算を分けて実行する場合に比べて精度的な改善も生じます。コンパイラーはループをベクトル化する際に、出来る限りこの命令を適用します。この新しいAVXと融合積和演算については以下の事に注意すべきです：
- 1つの256ビットAVX命令は2つの128ビットSSEの並列命令と同じスループットを持ちます：つまりクロックサイクル毎に4個の倍精度FLOPS、あるいは8個の単精度FLOPSであり、Margny-Coursプロセッサーと同じです。しかしながらAVX命令の利点の一つが、これらがnon-destructiveであることです。つまり、演算結果の入力レジスター内容への上書きは発生せず、演算結果用の3番目のレジスターが存在します。この事により、コンパイラーはSSE命令で必要なmove演算を省くことが可能になり性能向上が期待できます。
- 融合積和演算(クロックサイクル毎の8倍精度FLOPSあるいは16単精度FLOPS)による理論性能向上は、ILプロセッサーの8個の浮動小数点演算ユニットに対してMCプロセッサーは12個であるため、単純に性能が倍になるとは言えません。
図2 ： Interlagosモジュールの詳細。赤と緑の矢印はデータの移動の例を示す。赤矢印は、FMAC(浮動小数点積和演算器)へディスパッチされるまでの、L2キャッシュからレジスターへロードされるオペランドを示し、緑の矢印は、レジスターへ書き戻されて、L1(writeスルーキャッシュ)とL2キャッシュへと戻された結果データを示す。
InterlagosプロセッサーはHyperTransport interconnectionリンクにより結合された2つのダイから構成されます。各ダイはローカルメモリーおよび6MBのL3データキャッシュ(およびキャッシュコヒーレンシーのためにハードウェア的に予約された2MB)を共有する、4つのモジュールで構成されます。この状況を図3に示します。プロセッサー内の2つのダイはHyperTransportリンクで結合され、他のダイのメモリーにアクセスするよりも素早くローカルメモリーにアクセス可能なNon-Uniform Memory Architecture(NUMAアーキテクチャ)でメモリーアドレス空間を共有します。これを図4に示します。
図3 ： Interlagosダイ。青色の四角形は2コアから成るモジュールを示す。
図4 ： InterlagosプロセッサーはNUMAによるHyperTransportリンクで結合された2つのダイから構成される。
図5に示す通り、NUMAノードは2つ目のプロセッサーを外部HyperTransportリンクで結合して構成されます。これはHECToRのノード構成例です。
図5 ： NUMAノードは2つのInterlagosプロセッサーから構成され、ダイ間の結合の数で示されるように、ダイのバンド幅はデータがどこへ/から出入りするかに依存して3:2:1の比率になる。
テストシステム
Interlagos(IL)
InterlagosシステムとしてHECToR Cray XE6のテスト・開発システムTDSを用いました。これは図5で示された78個のNUMAノードで構成されます。プロセッサーのクロックは2.3GHzであり、ピーク性能は以下で与えられます：
以前に示したように、新しいFused Multiply-Add命令(FMA)性能は倍精度でクロックサイクル毎に8FLOPSです。ノード内の4つのダイ各々は、8GB DDR3@1333MHzのローカルメモリーを搭載するため、ノード内では32GBの共有メモリーを提供することになります。
Magny-Cours(MC)
Magny-Cours(MC)システムとして、図5で示したものと同じNUMAトポロジーを持ち、各ノードが2つの12コアプロセッサーを搭載する1856ノードで構成される、フェーズ2bのHECToR Cray XE6システムを用いました。プロセッサーのクロックは2.1GHzで、スーパースカラーモードで動作し、クロックサイクル毎に2つの倍精度の積和演算結果を返します。理論的なピーク性能は以下の通りです：
ノード内の4つのダイ各々は、8GB DDR3@1333MHzのローカルメモリーを搭載するため、ノード内では32GBの共有メモリーを提供することになります。Magny-Cours(MC)プロセッサー内の各コアは、ダイ内の隣接コアとL2キャッシュのみを共有します。
Westmere(WM)
Westmereシステムは、ハイパースレッディングをサポートする2個の2.93GHzの6コアXeonプロセッサーから成り、ノード内で24のバーチャルコアを起動することができます。各プロセッサーは12GB DDR3@1333MHzのローカルメモリーを持ち、ノード間でQuickPath interconnectリンク(HyperTransportと同仕様)を通して共有します。理論ピーク性能は以下の通りです：
Westmereプロセッサーの各コアは、レジスター以外の全てのリソースを共有し、2プロセッサー/スレッドをハードウェア的にサポート、つまり2個のバーチャルコアをサポートします。
ベンチマーク
上述したInterlagosプロセッサーのアーキテクチャーから生じる検証すべきポイントを以下に記します。
Q1 ： 新しいAVXとFMA(Fused Multiply-Add)命令を導入により、計算的に負荷の大きい計算部は如何にチューニングされるのか？シリアルプログラムはMCと比較して2倍になるのか？
Q2 ： モジュール内のリソース共有(浮動小数点演算ユニット、命令フロントエンド、L2キャッシュおよびTLB)により数値計算ルーチンへどのような影響があるのか？その結果を、より少ない共有リソースを持つ(MC)ものや、より多くのリソースを共有する(WM)似たシステムとどのように比較するのか？
Q3 ： MCと比較して、ダイに追加された2コアによるメモリーバンド幅上の競合増加の影響はどのようになるか？
これらの問題に対して、(a)高計算負荷の浮動小数点演算性能、(b)高メモリー負荷の整数演算性能、という点の影響を調べるために、2つのベンチマークテストを選択しました。(a)に対してはDGEMMを選びました。DGEMMは高計算負荷のBLAS level3ルーチンで、Interlagosプロセッサーの新しいFMA命令の利点を引き出すことが出来、かつベンダーライブラリーとして高度にチューニングされたOpenMP実装が施されています。(b)に対してはメルセンヌ・ツイスターを選びました。これはベクトル化不能な整数演算を実行するものであり、Interlagosモジュールの整数演算ユニットを並列に利用できるでしょう。また該当するNAGのSMPおよびマルチコアライブラリーはOpenMP実装されています。
DGEMM ベンチマーク
DGEMMのテストに以下の簡単なテストプログラムを用いました：
program matmul_test
use mpi
use timers
implicit none
integer :: n
double precision, allocatable, dimension(:,:) :: a,b,c
integer :: ierr,myrank
call mpi_init(ierr)
call mpi_comm_rank(mpi_comm_world,myrank,ierr)
if(myrank.eq.0) read(5,*) n
call mpi_bcast(n,1,mpi_integer,0,mpi_comm_world,ierr)
allocate(a(n,n),b(n,n),c(n,n))
a(:,:) = 0.d0
call random_number(b)
call random_number(c)
call start_timer(1)
call dgemm('n','n',n,n,n,1.d0,a,n,b,n,0.d0,c,n)
call end_timer(1)
call print_timers()
call mpi_finalize(ierr)
end program matmul_test
このプログラムは多数のDGEMMを並列に実行するものです。タイミングモジュールは、全プロセッサーに対して最大、最小および平均の経過時間を出力します。各テストマシン上においては、最も適したコンパイラーとベンダーライブラリーとして、ILとMC上ではCray 7.4.0とlibsci 11.0およびWM上ではifort 12.0, MKL 10.3によりコンパイルリンクされました。これらライブラリーは、OMP_NUM_THREADS環境変数で制御可能なDGEMMのマルチスレッド版です。
ここで各マシン上で3種の性能スケーリングを測定しました：
(a) ノードを完全に飽和させた時のマルチスレッディングのスケーラビリティ
(b) 単一プロセス時のマルチスレッディングのスケーラビリティ
(c) マルチプロセスのスケーラビリティ
(a)と(b)に対してOMP_NUM_THREADS値を、ILでは1,2,3,4,8,16、MCとWMでは1,2,3,4,6,12,24としました。テスト(a)では、MPIプロセス数NPROCSをNPROCS*OMP_NUM_THREADS=32(ILではOMP_NUM_PROC=3, NPROC=10とした)となるように指定し、また、NPROCに関する平均時間を計測しました。テスト(c)についても同様にNPROCに関する平均時間を計測しました。本レポートでは上述のQ1からQ3への回答に関連する結果を報告します。
ベースラインとなる結果を、非スレッドバージョンのライブラリを用いた単一プロセスにより測定しました。各プロセッサーでのベースラインを表1に示します。
| N | IL (Secs.,GFLOPS/s) | MC | WM |
| 1,000 | 0.156, 12.9 | 0.262, 7.7 | 0.181, 11.1 |
| 2,000 | 1.211, 13.3 | 2.043, 7.9 | 1.433, 11.2 |
| 3,000 | 4.093, 13.3 | 6.868, 7.9 | 4.816, 11.3 |
| 4,000 | 9.630, 13.4 | 16.227, 7.9 | 11.395, 11.3 |
表1がQ1への回答です。その性能はMCの値の1.7倍であり、2倍まではいきません。コンパイラーの最適なAVX命令を生成する機能が、SSE命令を生成する場合に比べてまだ未成熟であると考えられます。より最新のコンパイラーを用いれば2倍に近くなると考えてよいでしょう。MCに比べてWMが非常に速いのは、プロセッサーのクロックが速いことと、MC/ILでのCrayのlibsci実装よりもMK実装がWMに適したチューニングが施されているためであり、TPPに対する比率も高いものとなっています。いずれにせよILはWMより優っています。
図6から9は、表1に示したベースラインを基準とした、各テストマシン上で実施されたN=4,000での性能を示しています。
全てのグラフにおいて、y軸は以下の式で計算されています：
baseline_time/(OMP_NUM_THREADS*threaded_time)
よって値1は完全にスケーリングした状態を意味し、1以下であれば、並列アルゴリズム内のオーバーヘッド(DGEMMの2つの実装でほぼ同等とみなしています)、およびさらに重要なリソース競合の影響を示します。
図6と7はQ2への回答であり、モジュールレベルのリソースを共有するスレッドによる性能への重大な影響を示しています。DGEMMの場合は性能劣化に対する影響は約40%です。
Q2の二番目に関して、図8と9はそのアーキテクチャーから期待される様子が示されています：単一プロセスと比較してMCのスケーラビリティは、L2キャッシュを除きコアの完全な独立性が存在するため大きく損なわれることはありません。WMのスケーラビリティは大きく損なわれています(WMの結果は最大、最小および平均経過時間に大きなばらつきがある事を注記しておきます)。単一プロセスに比べて全バーチャルノードを用いた場合は性能の70%損失が生じており、これはハイパースレッディングの際にレジスターまで2プロセッサーあるいは各コアのスレッドが共有しているためです。ILのプロセッサーはこれらの結果の中間的なもので、リソースの部分的な共有のため性能は40%損失しています。
図6 ： 飽和ILノード(左図)と非飽和ILノード(右図)におけるDGEMMのマルチスレッド・スケーリングテスト。単一スレッドでの単一プロセス実行時と比較して、IL上のDGEMMの32並列実行は性能が40%損失している(32x1、左の青色バー)。これは8スレッドでさらに上昇する(ターコイズ色バー、4x8)が、ここではスレッドが同一ダイを占めており、これはリソース競合の増加よりも並列オーバーヘッドの寄与によるものである。16スレッド(オレンジ色バー、2x16)ではILプロセッサー内でHyperTransport(HT)リンクの通信が生じ、性能を50%以下に押し下げる。右図のチャートは、2スレッドのみを用いた場合でさえ左図のものから微妙な差がある。これはデフォルトではスレッドは順番に配置されるためであり、例えば2スレッドの場合(赤色バー、1x2)それらは同じモジュールを共有するためである。2つのチャートの類似性はモジュールレベルの共有が、それが2スレッドでさえ、性能を40%引き下げていることを示唆している。これは、以下の図7で示した結果が更なる証拠となっている。
図7 ： デフォルト配置(青色バー)では、隣接コアにスレッドは配置されるが、これは両方のスレッドが同じモジュールを共有することを意味する。同一ダイ(赤色バー) の異なるモジュールや、同一プロセッサー中の異なるダイ(緑)や、異なるプロセッサー(紫)(これらの配置はCray XE6ではaprunへの-ccフラグで制御可能であり、それぞれ、aprun -n 1 -d 2 -cc 0,2, aprun -n 1 -d 2 -cc 0,8, aprun -n 1 -d 2 -cc 0,16として使用する)へ2番目のスレッドを配置することにより性能は大きく上昇し、ほぼ完全なスケーリング性能を示す。これは図6で見られた性能の40%損失が、スレッドのリソース共有、この場合は浮動小数点演算ユニットの共有が最も寄与していることを示している。
図8 ： 飽和MCノード(左図)と非飽和MCノード(右図)におけるDGEMMのマルチスレッド・スケーリングテスト。L2キャッシュ以下のみを隣接コアが共有しているため、期待通りに良いスケーラビリティが示されている。図6のデータと対照的に、マルチスレッディングはベースラインからの影響は少ない。プロセス・スレッドがダイ境界を跨ぐ場合にのみ、図6でも見た通りのNUMAアーキテクチャーによる性能劣化が生じる。
図9 ： 飽和WMノード(左図)と非飽和WMノード(右図)におけるDGEMMのマルチスレッド・スケーリングテスト。共有リソースのレベルから期待される通りに、飽和WM上のDGEMMのスケーリング性能は非常に悪い。興味深いことに、単一プロセスが全ノードを専有した場合に性能は少し改善する。考えられる可能性として、MKLはハイパースレッディングが有効なときのみその利点を最適化しており、もしそうすることで利点があるならばより少ないスレッドを用い、DGEMMのような高計算負荷演算のリソース上の競合を減らしていることである。非飽和ケースのスケーラビリティは12スレッドまでMCとほぼ同等の性能を示している。これはデフォルトではスレッドが全てのコアに行き渡るまで別の物理コアへ配置するためで、その後にようやくコアはリソースを共有してハイパースレッディングが生じるためである。
メルセンヌ・ツイスター ベンチマーク
このベンチマーク用に、NAGルーチンG05SAF(均一疑似乱数発生器)を、NPROCS数の並列呼出しを実行するように修正しました。
Program g05safe ! G05SAF Example Program Text ! Mark 24 Release. NAG Copyright 2011. ! .. Use Statements .. Use nag_library, Only: g05kff, g05saf, nag_wp use timers use mpi ! .. Implicit None Statement .. Implicit None ! .. Parameters .. Integer, Parameter :: lseed = 1, nin = 5, nout = 6 ! .. Local Scalars .. Integer :: genid, ifail, lstate, n, subid ! .. Local Arrays .. Real (Kind=nag_wp), Allocatable :: x(:) Integer :: seed(lseed) Integer, Allocatable :: state(:) integer :: ierr, myrank ! .. Executable Statements .. call mpi_init(ierr) call mpi_comm_rank(mpi_comm_world,myrank,ierr) if(myrank.eq.0)then Write (nout,*) 'G05SAF Example Program Results' Write (nout,*) ! Skip heading in data file Read (nin,*) ! Read in the base generator information and seed Read (nin,*) genid, subid, seed(1) ! Read in sample size Read (nin,*) n end if call mpi_bcast(genid,1,mpi_integer,0,mpi_comm_world,ierr) call mpi_bcast(subid,1,mpi_integer,0,mpi_comm_world,ierr) call mpi_bcast(seed(1),1,mpi_integer,0,mpi_comm_world,ierr) call mpi_bcast(n,1,mpi_integer,0,mpi_comm_world,ierr) ! Initial call to initialiser to get size of STATE array lstate = 0 Allocate (state(lstate)) ifail = 0 Call g05kff(genid,subid,seed,lseed,state,lstate,ifail) ! Reallocate STATE Deallocate (state) Allocate (state(lstate)) ! Initialize the generator to a repeatable sequence ifail = 0 Call g05kff(genid,subid,seed,lseed,state,lstate,ifail) Allocate (x(n)) ! Generate the variates ifail = 0 call init_counters call start_timer(1) Call g05saf(n,state,x,ifail) call end_timer(1) ! Display the variates !Write (nout,99999) x(1:n) call print_timers() call mpi_finalize(ierr) 99999 Format (1X,F10.4) End Program g05safe
SMPおよびマルチコア対応のNAGライブラリーのG05SAFのOpenMPバージョンを用いて、DGEMMベンチマークで行ったマルチプロセスおよびマルチスレッディングの同様の設定を行いました。IL上ではPGIコンパイラバージョン11.9を使用し、MC上ではPGI 11.5、WM上ではifort 12.0を使用しました。全てにおいて"-fast"コンパイルフラグを用いました。以下の入力ファイルを全てのテストで使用し、各プロセスで125,000,000個の乱数を発生させました。
G05SAF Example Program Data 3 1 1762543 :: GENID,SUBID,SEED(1) 125000000 :: N
メルセンヌ・ツイスターのアルゴリズムにおける計算カーネルは整数演算が主で、最後に整数を浮動小数点にキャストするのみですが、DGEMMとは異なりその性能は計算よりもメモリーアクセスにより支配されます。よってコアレベルのリソースと同様にメモリーの競合が性能に寄与する重要な因子となります。さらにDGEMMと比較して異なる点は、小さなN(125,000,000は比較的小さな値です)に対しても生成シーケンス(シリアル実行時と同等のシーケンスが保証されます)の並列オーバーヘッドが無視できないことです。表2はノードを専有して実行した単一スレッドプロセスのベースライン結果です。
| IL (Secs.,GFLOPS/s) | MC | WM | |
| Time (secs) | 1.573 | 1.501 | 0.656 |
WMの性能は2つのAMDプロセッサー性能を凌駕しています。これはメモリーサブシステムの性能(ILに比べて2，3割以上のメモリー操作を実行することが出来ます。参考情報：http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=8)や高いクロック周波数およびコンパイラー性能がより優れていた結果と考えられます。
DGEMMテストと同様に、この節では、与えられたリソース内で表2のベースラインを基に、プロセッサー負荷やプロセス/スレッドの分配により性能がどのように変化するかに焦点を当てます。
DGEMMで行った3タイプのテストを、メルセンヌ・ツイスターに対しても同様に行いました：
(a) ノードを完全に飽和させた時のマルチスレッディングのスケーラビリティ
(b) 単一プロセス時のマルチスレッディングのスケーラビリティ
(c) マルチプロセスのスケーラビリティ
ここで大変興味深い結果を得ました。
図10において、32の独立したプロセスがデータを全く共有していない極端な例では、単一プロセス時と比べて単一スレッドの性能は50%減少しています。このオーバーヘッドにはアルゴリズム的な並列競合は含まれていませんが、図11で示した約10%の単一モジュール内の競合と、L3キャッシュでの競合、およびメインメモリーバンドでの競合が含まれています。各モジュールにおいて2つのスレッドを実行させた場合、より多くのデータがL2およびL3キャッシュで共有されることから、図同様のオーバーヘッドが30%の性能を減少させていることが図10から解ります。同様にMCの性能減少が、24個の独立したプロセスでは20%、2スレッドの12個の独立したプロセスでは10%生じています。これらの事がQ3の回答であり、単一ILモジュール内のリソース競合を差し引いた後でさえ、L3キャッシュとメモリーバンドの競合が重要であることを示しています。
WMと比較して、ノードが飽和している場合、モジュール内の10%の効率悪化は影響ありません。しかしながらWMでは、OSは最初にハイパースレッディングに頼らずに物理コアを満たしていくのに対して、ILではモジュールから配置していくために、スケーリングの様子から見ての通りに10%のペナルティーが生じます：つまり、図10の右図においては、2スレッドに対して25%の性能損失がありますが、図12や13では15%程度です。
このテストで見られたモジュール内の10%の性能損失は、DGEMMで見られた40%よりも小さなものですが(スカラー整数演算ユニットが共有されていないので当然ですが)、MCやWMと比較すると依然大きな値です。
図10 ： 飽和ILノード(左図)と非飽和ILノード(右図)におけるメルセンヌ・ツイスターのマルチスレッド・スケーリングテスト。単一スレッドでの単一プロセス実行時と比較して、各2スレッドの16個の独立したG05SAF呼出しでは、約55%の損失が生じている(左図の赤色バー)。2スレッドに対してノードが非飽和の場合は(右図の赤色バー)、効率は25%損失する。これはノードが飽和した際の効率損失55%の内、30%が他のモジュールとのL3キャッシュとメモリーバンドの競合によるものであることを示しており、右図の赤色バーでの並列オーバーヘッドとモジュールレベルの競合は同等である。左図の青色バーは並列オーバーヘッド以外の50%の効率損失を示している。しかしながらL2のモジュールレベルの競合とL3およびメインメモリーの競合は、データの共有がないために2スレッドの場合よりも大きくなると考えられる。
図11 ： 2番目のスレッド配置を変えるとモジュールレベルの競合が消える。同じモジュールへ2つのスレッドを配置した場合は、隣接モジュールや別のダイや別のプロセッサーの場合と比較して、10%の効率損失が生じる。これは、DGEMMでは40%だった(図7)モジュールレベルの競合と比較して小さい。残りの性能損失15%は、並列オーバーヘッドとL3/メインメモリーの競合である。
図12 ： 飽和MCノード(左図)と非飽和MCノード(右図)におけるメルセンヌ・ツイスターのマルチスレッド・スケーリングテスト。各2スレッドの12個の独立したG05SAF呼出しでは、L3キャッシュとメモリーバンド競合のため25%の損失が生じており(左図の赤色バー)、これは図10のILの非飽和の場合と同じである。非飽和の場合の2スレッドの結果は(右図の赤色バー)図11のスレッドが別のモジュールに配置された場合のILと同じで15%の性能損失である。右図と左図の赤色バーの違いは、L3とメモリーバンド競合であり、ILでは30%だったものがここでは約10%である。並列オーバーヘッドがない場合(左図の青色バー)、性能損失はILの50%に比べ20%以下である。これはILにおけるコア毎のメモリーバンド幅の減少によるものであることを示している。
図13 ： 飽和WMノード(左図)と非飽和WMノード(右図)におけるメルセンヌ・ツイスターのマルチスレッド・スケーリングテスト。左図はILの図10とほぼ同様な傾向を示している。しかしながら右図では、2スレッドでの性能損失は15%のみであり、これはMCやILでのスレッドがモジュールを別にしている場合と同じである。これはWMにおいては、12プロセッサー/スレッド以上が実行されるまでは、スレッドはコアレベルのリソースを共有しないためである。
ベンチマーク結論
結果として、ILで共有されるモジュールレベルのリソースは、高計算負荷演算DGEMMに対して大変大きなインパクトを与えます。非飽和な状態では、このインパクトはハイパースレッディング・プロセッサー(WM)よりも比較的小さいですが、通常のコンベンショナルなプロセッサー(MC)よりは大きいと言えます。その損失はMCでは数%、WMでは70%、ILではその中間的な40%程度です。メモリー負荷コードの場合は、性能はモジュール内競合により制限を受けますが、メモリーバンド幅がコアの増加と共に小さくなってしまうことの方が重要です。
プロセッサーが飽和していない場合は、OSによるスレッド配置ポリシーが性能にとって重要なポイントとなります。ILにおいてはOSはモジュール内のコアを別の物理コアとみなしてしまいますが、高計算負荷アプリケーションではモジュールを一つのコアとしてとらえるべきです。デフォルトのスレッド/プロセス配置はモジュール、ダイ、プロセッサーの順番に飽和させるものです。よって2スレッド又はプロセスのみを計算する場合には、これらのタスクはデフォルトでは同じモジュールを共有します。DGEMMの場合、これは飽和ケースと同等な40%の性能損失を生じており、モジュールレベルの共有による影響が支配的であることが解ります。
これはWMプロセッサーでの配置ポリシーと対照的です。WMではそれらを12個の物理コアとみなし、デフォルトではプロセッサー内の物理コアを飽和し、さらに2つのプロセッサーに渡って配置し、最終的にバーチャルコアあるいはハイパースレッディングを用います。つまりコアレベルのリソース共有はILより大きなインパクトを示しますが(70%)、12タスクを超えない限りこうしたインパクトは生じません。よって、高計算負荷演算コードに対しては、WMのOSポリシーのように、2プロセッサー/スレッドを同じモジュール配置にする必要がない限りは、モジュールを一つのコアを見なうべきです。メモリー負荷コード、特に整数データによるものに対しては、より少ない損失でデュアルコアとみなすことが可能でしょう。しかしながらその損失は、2スレッドのみの場合でさえすぐに顕著になります。
HECToRでの実験
ベンチマークにおいて示されたMCに対する性能の劣化傾向は、HECToR上での実際のアプリケーション実行において広く再確認されています。このセクションは、レベル3のBLASとLAPACKを頻繁に利用してHECToRでも二番目に負荷の高いアプリケーションである、量子化学コードCASTEPの性能を報告します。
図14 ： CASTEPベンチマーク1、同数のプロセッサーによるILとMCと比較。
図15 ： CASTEPベンチマーク2、同数のプロセッサーによるILとMCと比較。
図16 ： CASTEPベンチマーク3、同数のプロセッサーによるILとMCと比較。
図14-16のILのsmp=8およびMCのsmp=6は、System Vシェアードメモリーの最適化を示します。ノード内の各コアに対して個別のセグメントを用いていますが、比較には影響しません。
図17 ： 半飽和時(モジュールに1プロセス)の実行時間は揃っていない。最も適したSMPサイズ8に対して、同サイズジョブに倍のノードを用いるには約1.6倍コストが掛かっている。
図14-16で示した3ベンチマークの内2つは、ノードを飽和させた場合(ILノードに32MPIプロセス、MCノードに24MPIプロセス)、ILはMCより大きく劣ることを示しています。これは、AVX/FMA命令セットによる性能の利得が、ベンチマークのセクションで示したようにノードが飽和する際の損失に及ばないことを示しています。図17は、モジュール当り1プロセス(つまり倍のノード数)を用いて同じジョブを実行した場合の性能がコストパフォーマンスとして良く無いことを示します。
全体の結論
本レポートにおけるInterlagosプロセッサーに代表されるAMDのBulldozerアーキテクチャーは、Magny-Coursプロセッサーに代表される、L2あるいはL3キャッシュ以上のリソースのみを共有する伝統的なマルチコア設計である以前の世代のAMDプロセッサー、および、Westmereプロセッサーに代表される、状態を管理するレジスター以外の全てのリソースを共有するインテルのハイパースレッディング設計の、中間的な設計です。
これらのプロセッサーは実行時に飽和したときにその様相が展開されます：Magny-Coursは最も並列効率が良く、次にInterlagosそしてWestmereが続きます。しかしながら、プログラムがシリアルプログラムから如何にスケールするかを見ると、Interlagosプロセッサーは、そのプロセッサーを16物理コアとして扱うそのOSのポリシーによりすぐに悪化します。本レポートのベンチマークから明白なことは、特に高浮動小数点計算負荷のアプリケーションにとって、プロセッサーは8コアとしてみなされるべきであり、8プロセッサー/スレッドより多くが必要になったときのみ、モジュールを共有するようにタスクを配置するべきです。このポリシーは、Westmereの場合にその効果を見て取ることが出来ます。
HECToRフェーズ3の32コアInterlagosへの更新において、以前のフェーズの24コアMagny-Coursノードに比べてさらにメモリーバンド幅のペナルティーが発生します。これはメモリー負荷のRNGメルセンヌ・ツイスター・ベンチマークで見た通りです。
Interlagosの課題としてはジョブ配置がその一つです。HECToRではユーザーは、aprunランチャーを使って如何にプロセスやタスクを配置するかを学ばねばなりませんが、それは簡単でなく、彼らのコードに対して最適な戦略を選択するためのベンチマークが必要となります。より一般的に言えば、例えばNAG SMPライブラリーでは、最適な性能のためにOSの配置ポリシーに頼ることはもはやできません。システム負荷や、親和性や、用いるルーチンのタイプに関する計測時間ベースのスレッド配置の制御といったこの種のプロセッサーの利用方法を、ユーザーに明確にわかるようにすることが理想的です。幸運にもこの問題はすでにOpenMP4.0に備わっています：例えば、ネストしたループのリストとしてのOMP_NUM_THREADSの新しい指定形式や、OMP_PROC_BINDと親和的なプロセッサー制御、およびOMP_PROCSETによるコアのノミネートセットへの実行制限などです。