RightMark Memory Analyzer 3.8(グラフ26～82)

cpu.rightmark.org
http://cpu.rightmark.org/products/rmma.shtml

　ではいよいよRMMAを。まずグラフ26～30がDecode Bandwidthである。Photo19で基本的にDecode部そのものの機構には変化が無いという話だったので(もちろん新命令への対応などはあるが)、全命令をやる必要はないだろうということで

  • グラフ26：nop (1)
  • グラフ27：test (2)
  • グラフ28：cmp ax, 0x00 (4)
  • グラフ29：cmp eax, 0x00007fff (6)
  • グラフ30： cmp eax, 0x0000007f (8)

の5つの結果を示したものだ(()内は命令のサイズ)。

5つともL1の領域に関しては綺麗に重なっており、ここからDecodeそのものの機構に変化は無いことが分かる。ただしL2の帯域は

  • Zacate:2.40Bytes/cycle
  • Kabini:3.45Bytes/cycle

とほぼKabiniが1Bytes/cycleほど帯域を広げているようで、これがそのまま反映される形になっているようだ。

ところで本当にDecodeに差が無いのか? と思ったらそうでもなかった。グラフ31はPrefixed NOP Efficiencyであるが、これはMicrocodeを使った処理の速度を示すもの。

Zacateの場合はNOP Pointが14(NOP命令の前に、14個無駄にPrefixがついて、合計で15Bytesの命令になっている)のケースで2.5Bytes/cycleでの処理が可能だからMicroCodeの処理に6cycle程度要している。ところがKabiniだとNOP Pointが14における処理速度はたったの0.33Bytes/cycle。つまりMicroCodeを通る場合、45cycleほど必要になることを示している。

何でここまで差がつくのか? といえば、おそらくは動作周波数向上のためにパイプライン分割を行った関係だと思われる。通常のPipeline StageいわゆるHyperPipelineのように機能分割をしてStageを増やせばいいのだが、Microcode読み出しは機能分割というわけにもいかないからだ。

とはいえ、ここまで急激に増えたあたりは、MicroCodeの持ち方を変えたとか、何かしらのドラスティックな変更が行われたのかもしれない。

Decode周りということで、次にROB周りについても見てみた(グラフ32～35)。Photo20で"Larger ROB"と明示されているから降下はあるか？という事を比較したかったのだが、グラフ32を見る限り、ROBのサイズは同等というか、Kabiniは60Entry程度であり、一方Zacateは64Entryでむしろ減っているように見える。おまけにLatencyは倍増だ。

この傾向はBackward(グラフ33)でも通じる。

ところがRandom(グラフ34)とかPseudo-Random(グラフ35)を見るとちゃんと平坦部がある分(そうした平坦部の無い)Zacateより改善されている気もする。とはいえ絶対的なLatencyが増えている分、果たしてこれが本当に改善なのか？はやや不思議なところではある。

ついでなのでTLB周辺の確認もしてみた。まずはI-TLB SizeのNear Jump(グラフ36～38)とFar Jump(グラフ39～41)の結果を見てみる。Entry数そのもの、で言うとZacateはI-TLBそのものは１つのみで512 Entry、一方KabiniはL1 I-TLBが32 Entry、L2 I-TLBが512 Entryとなっている。

で、L1 I-TLBに関してはKabiniとZacateで「それほど」変わらない(それでも平均0.5cycleほどKabiniが遅い)が、L1 Miss/L2 Hitでは明らかにKabiniの方が悪化しており、平均9cycleほどである。このあたりは、TLBを分割した事に起因するものと思われる。

またグラフ39～41では、L2 TLBが全部ミスというか、そもそも動いていないような振る舞いを見せるが、これは仕様であろう。

Photo55を見ると、L1 I-TLBはLP(Large Page)が4Page分あるが、L2 I-TLBではLPの対応が無い。64bit環境でFar JumpをやったらそりゃLarge Pageになるわけで、TLBがミスするのも仕方ないところだろう。大体64bit環境でFar Jumpの必要があるのか? といわれると普通はあまり必要性が感じられない状況で、このあたりは割り切ったものと思われる。

I-TLBではもう一つ、Associativityについても確認した(グラフ42～65)。Near Jump(グラフ42～53)とFar Jump(グラフ54～65)、それぞれ16/32/64/128EntryでのForward/Backward/Randomのアクセスを行った時のLatencyの出方を確認するもの。本来の目的はSet Associativityを確認するためのものだが、同時にTLBのアクセス特性を確認することにも使える。

まずNear Jumpのほうを見てみると、16 Entriesの場合はグラフの立ち上がりのSegment Countが若干異なるものの、傾向としては相似形で、ただしKabiniの方が全般的にLatencyが大きい。

これはFar Jumpの方も同じで、特に128 Entries, Random(グラフ65)など、かなりKabiniの数字が荒れているのは気になるところだ。

I-TLBの次はD-TLBについて。まずSize(グラフ66～68)だが、Entry数そのものはKabini/ZacateともにL1が40、L2が512でここに差はない。またL1はFully Associative、L2は4-way Set Associativeで、これもKabini/Zacateともに同じである。

しいて違いを挙げれば、ZacateはL1のみLarge Page対応(4 Entry/Fully Associative)、対してKabiniはL1は同じでL2が128 Entry/2-way Set Associativeということで、このあたりは64bit環境に本格対応すべくTLBの強化をしたことが分かる。

結果を見ると、L1は同一、L2はZacateがややなだらかながら次第にLatencyが増加しているのに対し、Kabiniは綺麗にフラットになっており、このあたりは明確に改善されたと言ってよさそうだ。L2 TLBがMissした先はなだらかにLatencyが増加しているが、これはL2 Cacheにアクセスしている状況になるので、共有L2になった分若干Latencyが増えていることを考えれば妥当な範囲といえる。

次にD-TLB Associativityであるが、16/32 Entriesに関してはZacate/Kabiniともに完全に3cycleでフラットになっているので割愛して、64 Entries以降(グラフ69～74)のみを示す。

結果はまぁご覧の通りで、傾向そのものは全く一緒。Kabiniの方がLatencyが大きいのは、L2 D-TLBもMissしてL2 Cacheにアクセスしている部分だからで、逆にTLBにHitしているところではほぼ同じLatencyとなっているのが分かる。

しいていえば、最初のLatencyが急増した立ち上がりのSegment数が、Kabiniでは4なのにZacateは5になっているあたりが少々違っているが、このあたりはインプリメントの都合であろう。

最後にCache/Memory周りについて。まずグラフ75～77がBandwidthである。

ここでハッキレしているのは、Load/Store Unitが明らかに128bit/cycle(16Bytes/cycle)まで高められていること。理由は簡単でAVX命令に対応するためだろう。

FPU部はAVXに対応すべく、128bit化されているから、最低でも128bit化は必須である。本当を言えば、AVX演算は原則「C = A op B」(AとBの2つを読み込み、演算opを行ったあとCに書き込む)だから、Load : Storeが2:1で発生するわけで、帯域的にはWriteが16Bytes/cycleならばReadは32Bytes/cycleにしないと効率が良いとはいえない。

だが、そこまですると消費電力の増加がばかにならないと判断されたのだろう。もともとJaguarコアはAVX対応といっても、これは命令セットの互換性を保つのがメインであって、AVXを使ってバリバリ処理を行いますという訳ではないから、手ごろなところで妥協したのだと思われる。

ただ結果としてRead/WriteはL1に対して16Bytes/cycle、L2に対しても7Bytes/cycleを維持しており、この手のコアとしては非常に高いスループットといえる。さすがにCopy(グラフ77)では、L1こそ14Bytes/cycleを維持しているが、L2では3.7Bytes/cycle弱まで落ちるのは、いかに共有L2用のBIUがWrite Combine Bufferを4つ搭載している(Photo23)とはいえ、同時処理には限界があるという話ではある。

このあたりの性能を高めると回路規模や消費電力が増えるから、このあたりが手ごろなバランスだったのだろう。実際KabiniのL2とZacateのL1がほぼ同じ帯域、というあたりは十分性能改善が行われていると考えられる。

さて、このグラフ75～77のうち、Memory Accessになる部分を拡大してまとめたのがグラフ78になる。

平均値で言うと、

Zacate Kabini
Read 2557.0 5254.8
Write 2172.4 3316.5
Copy 1490.4 2259.2
(単位はMB/sec)

といったところで、Readで2倍、Write/Copyで1.5倍に性能が高められている。ここは素直にMemory Controllerや内部のInterconnectの改善によるものと考えられる。

帯域は改善したがLatencyは? というのがこちら(グラフ79～82)。

L1に関してはKabini/Zacateは同等だが、L2に関しては明確にKabiniが良好。Memory Accessも、Random AccessはともかくSequential AccessだとKabiniが良い。帯域が大きく、Latencyも少なければそりゃ性能は改善するだろう、という訳だ。

ということで、ここまでの結果での中間考察を。

パイプラインそのものの改善がどの程度か、というのはここでははっきり見えてこない。動作周波数を引き上げるためにパイプライン分割を行ったり、あるいはより大量のデータを扱うためのバッファ容量増加などを行ったため、例えばROBとかTLBでは性能が悪化しているし、MicroCodeを使うシーンでは目に見えて性能が落ちている。その一方で、キャッシュやメモリアクセスは明確に性能が改善されており、広帯域・低レイテンシ化が進んでいる。

これは、Jaguarでコアの最適化の方向が若干変わったのだと思う。Bobcatは、いってみれば「比較的こじんまりしたデータを扱うプログラムを、そこそこの性能で処理する」方向に最適化が進んでいた観がある。だから最適化が進んでいないプログラムでもそこそこの性能が出る(代わりに、そこそこ以上の性能を引き出すのが難しい)という感じだった。

ところがJaguarは「やや大量のデータを扱うプログラムをそれなりの速度で処理する」方向に舵を切ったようだ。そのために不規則なアクセスとか分岐の多いプログラムなどでは、むしろBobcatより効率が悪いかもしれない反面、ある程度最適化が進んだ規則的なデータを扱うようなシーンでは、Bobcatに比べて倍近いスループットを引き出すことが可能な構成になっている。

Photo25で、"Bobcat" VirusはBobcat/Jaguarでほとんど性能が変わらないが、"Jaguar" Virusは倍以上のスループットが引き出せる、というのも、CPU内部のこうした最適化を反映しているように思う。

この方向性が正しいかどうか、というのは次以降の結果を見ながら判断したいと思う。

次のページ：ベンチマーク結果「PCMark Vantage v1.2.0」