Black Friday 2021 (2) Samsung 970 EVO Plus

　今年は珍しくBlack Fridayにいろいろと買い物をしたので、買った物についてメモがてら書いてみる。

[12/04 加筆修正] SLCキャッシュ周りの挙動に関する部分を加筆修正

Samsung 970 EVO Plus 1 TB

　言わずと知れたSamsung製M.2 NVMe接続SSDの旧世代品。安価（約€90≒¥11500）だったのと、とある記事（後述）で興味を持ったため購入。
　実は、来年初頭にも引越して新しくサーバーの構築を計画しており引越の邪魔にならない程度で部品調達を進めている。高信頼性のSSDとして既にSamsung 970 PROを確保済なのだが、それと組み合わせる比較的安価で高速なSSDとして970 EVO Plusを入手した。

　SamsungはSSD製品を主にPRO/EVOの2クラスで展開してきているが、960 PRO・970 PROまではMLC 3D NANDを採用していたところ、980 PROではTLC 3D NANDを採用しており、フラッシュメモリーの信頼性は低下している（1TB版で1200 TBW→600 TBW）。このことに関するSamsungによる説明をGuru 3Dが紹介しているのだが、これが実に興味深い。
　詳細はリンク先の記事を参照いただくとして、要は「5年間で600 TBW以上を書き込むユーザーは全体の0.3％以下・99％のユーザーは5年間で156 TBWかそれ以下しか書き込まない」ということで、言い換えれば99％の人が600 TBWを使い切るには19年間を要するため、970 PROの1200 TBWはおろか980 PROの600 TBWですら明らかなオーバースペックということである。
　代わりに、970 EVO/970 EVO Plusで先行して導入されたSLCキャッシュ技術＝Intelligent TurboWriteが導入され、970 PRO以上のRead/Write性能を達成している。

　筆者個人としては、信頼性を重視して確保した970 PROに満足しているが、上述のSamsungの説明を信じるなら980 PROと同等の信頼性を安価な970 EVO Plusでも実現できる可能性がある（実際、970 EVO Plus旧モデルでは耐久性は非常に高かったらしい）。加えて上述の通り高速/高信頼性という棲み分けが必要と判断したのが970 EVO Plusを入手した動機である。
　もっとも、970 EVO Plusの信頼性を判断するにはNANDフラッシュやSLCキャッシュ技術以外も検証する必要はあるのだが。

　…ここまでであれば、よくある「そういう話」なのだが…実は最新970 EVO Plus（v.3）は980 PROに近い仕様に変更されていたことを購入後に知ったので御紹介したい。

• 970 PROと同じPhoenixから980 PROと同じElpisに変更
  • Tom's Hardwareによると、これはSSDコントローラー不足による措置
  • ランダムR/W性能だけを見れば改良といえる。「選別落ち品ではないか？」という批判があるようだが型番が同じため根拠が無い
• 対応インターフェースはPCIe 3.0のまま
• NANDフラッシュは96層から128層に変更
  • Samsung 3D NAND Version 5=96層から3D NAND Version 6=128層への変更で、一概に改良とも改悪とも言えない
  • 型番をある読む限りでは品質に関わる部分は旧モデル・新モデルで共通
• SLCキャッシュ枯渇後の速度低下が著しい
  • SLCキャッシュ枯渇による性能劣化の自体は980 PROや980でも存在する問題である。もっとも、980 PROについてはPCIe Gen 4.0対応なせいか970 EVO Plus v.3よりは高速であるが
• 同じ製品名・JANコードのまま仕様が変更された

　コントローラーとIntelligent TurboWrite=SLCキャッシュの仕様の変更によりSLCキャッシュ枯渇までは新モデルが高速、SLCキャッシュ枯渇は旧モデルが早く（旧モデル：42 GB、新モデル：114 GB）、SLCキャッシュ枯渇後は旧モデルの方が高速ということになるそうだ（下表参照。数値はTom's Hardwareから引用）。TurboWriteが有効な場合は下記よりも高速な可能性があり、公式のスペック表では3300 MB/sとなっている。

	with TurboWrite	> 42 GB	> 114 GB
970 EVO Plus (v.2)	1750 MB/s	1500 MB/s (without TW)
970 EVO Plus (v.3)	2500 MB/s		800 MB/s (without TW)
980 PRO	5000 MB/s		2000 MB/s (without TW)

[12/04 加筆修正部分 ここから]

　某巨大掲示板などでは、このSLCキャッシュ枯渇後の「1500 MB/s」と「800 MB/s」という数字にのみ着目して改悪だと大騒ぎする人が多いのであるが…実際はそれほど単純な話では無く、筆者の個人的な見解としてはSLCキャッシュ枯渇前の高速化はメリットがあるしSLCキャッシュ枯渇についても運用対処でどうにかなる範疇だと思っている。

　この問題をややこしくしているのはSLCキャッシュの挙動が単純ではないからだ。例えばSLCキャッシュの容量「114 GB」という部分を考えてみると、日常的に114 GBもの巨大なサイズを読み書きする人は限定的で、多くの人々にとってはSLCキャッシュの枯渇は心配する必要の無いもののように思える。
　その一方で、SLCキャッシュを114 GB（動的確保部分108 GB）も確保できる条件は限定されるため本当に気にする必要が無いとは言い切れない場合がある。SLC 108 GB=TLC換算 324 GBなので、そもそも空き容量が十分でないと確保できないことになる。 使用容量が多い場合はSLCキャッシュ容量も減るから実際にはSLCキャッシュが114 GBに達する前に枯渇してしまう。

　実は、こういった内容を詳細に検証したサイト（参考1: 970 EVO Plus・参考2: 980）が存在し、それを纏めると以下の表のようになる。

SLC Cache	Utilized capacity	970 EVO Plus (v.2) 1000 GB			970 EVO Plus (v.3) 1000 GB
		Default	Intelligent	Total	Default	Intelligent	Total
Capacity	0 - 50%	6 GB	36 GB	42 GB	6 GB	108 GB	114 GB
	50 - 80 %		36 GB	42 GB		61 GB	67 GB
	>80 %		0 GB	6 GB		0 GB	6 GB

　そもそものSLCキャッシュ枯渇後に970 EVO Plus v.3で遅くなる理由であるが、どうやら970 EVO Plus v.2のIntelligent TurboWrite 1.0と970 EVO Plus v.3のIntelligent TurboWrite 2.0とで挙動が変わったためということのようだ。
　そもそものTurboWrite・Intelligent TurboWrite 1.0ではSLCキャッシュ枯渇後はTLC NANDに直接書き込まれ、SLCキャッシュの内容は書き込み完了後のアイドル時にTLC NANDに展開されるが、Intelligent TurboWrite 2.0ではSLCキャッシュ枯渇後はTLC NANDへの直接書き込みとSLCキャッシュ内容のTLC NANDへの展開が並行して発生するらしい。そのためSLCキャッシュ枯渇直後は速度が大幅に低下するが（2500 MB/s→800 MB/s）、SLCキャッシュのフラッシュ後は速度が一部回復する（800 MB/s→1000 MB/s）らしい。ホストからの書込とSLCキャッシュのTLC NANDへの書込が並列して動作するわけだから書き込み速度が大幅に低下するのも納得できる。

　このアルゴリズムの変更については変更内容も変更理由もSamsungは公式に発表していないため不明だが、ある程度の推測は可能だろう。というのも、SLCキャッシュが枯渇した場合書込とキャッシュのフラッシュとを並行して行わなければエラーとなる可能性が高いからである。例えば1 TB（1000 GB）のSSDのうち500 GBを消費していて180 GB（※新モデルでの最大SLCキャッシュ容量を上回る容量）の書き込みをする場合を考えてみる。
　この場合、旧バージョンののSLCキャッシュ容量と旧バージョンのキャッシュ制御方式の組み合わせであれば、36 GB（TLC換算 108 GB）のSLCキャッシュが確保され500 GB + 108 GB + 180 GB = 788 GBとなり、速度は落ちるかもしれないが問題無く書き込むことができる。
　ところが、新バージョンのSLCキャッシュ容量と旧バージョンのキャッシュ制御方式の組み合わせであれば108 GB（TLC換算324 GB）がSLCキャッシュが確保され500 GB + 324 GB + 180 GB = 1004 GBとなり4 GB溢れてしまう（→書き込みエラー）。
　このため、新バージョンのように大容量のSLCキャッシュを確保する場合は書き込みエラーを避けるためにもTLC NANDへの直接書込とSLCキャッシュの展開を並列して行う必要がある。また、SLCキャッシュのTLC NAND領域への展開もそれなりに遅延が発生することも考慮する必要がある。

[12/04 加筆修正部分 ここまで]

　某巨大掲示板等ではコスト削減のための改悪だという批判があるのだが、今回はコントローラーを新しい物への変更とそれに伴う挙動の変更で、個人的にはコスト削減で改悪されたとは言えないように思う。
　JANコードが同じだったことは混乱を招いたと思われるが、ただし「114 GB以上の書き込み」等の変更内容はワークステーション/エンタープライズならばともかく970 EVO Plusの想定ユーザー＝一般消費者からすれば非日常的な条件のため実用上の問題がないという判断だったのかもしれない。

Black Friday 2021 (1) - Gemini Lake Mini PC

　今年は珍しくBlack Fridayにいろいろと買い物をしたので、買った物についてメモがてら書いてみる。

MeLE Quieter2

　中国MeLE製ファンレスMini PC Quieter2が安価（€199）だったので衝動買いした。2017/18年登場のIntel "Gemini Lake"搭載PCだから2021年末にレビューするような代物ではないけれども。

Pros	Cons
Windows 10 Proプリインストール Windows 11アップグレード可能 安価	電力供給だけのUSB C（PD非対応/USBとして使えない） USB C HDMI/DP Alt Mode非サポート

　Intel E-Core系コア（旧Atom系コア）ベースの中華Mini PC製品としては、以前Celeron J1900 "Bay Trail"ベースのTronsmart Ara BJ19を所有していたのだが、良くも悪くも廉価版/省電力/省スペースPCという印象が強い製品だった。WebブラウジングやOffice程度の日常使いには足りる性能ではあったが…全方位で同世代のP-Core系コア（旧Core系コア）ベースのPCに劣った劣化版、悪い言い方をすれば「安かろう悪かろう」という印象が強かった。

　例えばスマートフォン/タブレットを想像してみると、絶対性能という点ではPCに劣るにしても、必ずしもPCの劣化版という扱いではない。
　それは例えばYouTubeなどの動画を再生する場合にはむしろ最新のスマートフォンは旧世代のPCよりスムーズにHD動画を再生できたりすることからも解る。これは、アプリケーションプロセッサーに搭載される動画や画像のエンコーダー/デコーダーが高性能だからである。だからFireTVなどのAndroid TVボックスのようなPCより都合が良いアプリケーションが存在する。
　逆に言えば、FireTVなどの安価なストリーミング動画プレイヤーでよく採用されているAmlogic S905シリーズの場合CPU・GPUは低性能（例えばハイエンドS922Xの場合：CPU Cortex-A73 x 4 + A53 x 2・GPU Mali-G52 MP2）で動画デコード/エンコード機能に特化している。

	Amlogic S922X	Intel "Gemini Lake"
CPU	Arm Cortex-A73 x4 Arm Cortex-A53 x2	Intel "Goldmont Plus" x4
GPU	Arm Mali-G31 MP2 54.4 GFLOPS	Intel HD Graphics GT1 (12 CU) 144.0 GFLOPS
Video Decode	4Kp60 H.265 10-bit, 4Kp60 VP9 Profile2, 4Kp30 H.264	H.265 10-bit, VP9 Profile2, H.264
Video Encode	1080p60 H.265, 1080p60 H.264	H.265, H.264

　筆者が思うに、Pentium/Celeron "Gemini Lake"搭載Mini PCは、ようやくそういう使い方ができる最低限の水準に達した製品だったと思う。言い換えればIntelがx86 CPUのスマートフォンやタブレットへの搭載を計画していた時点では、GPUもマルチメディア性能も電力効率も色々と足りていなかった。
　"Gemini Lake"に統合されている"Goldmont Plus" CPUコアも興味深いが、それ以上に興味深いのがIntelの動画エンコーダー/デコーダーSIPであるQuickSync Videoだろう。なにせ第6世代Core "Skylake"を上回り、第7～10世代（※"Ice Lake"を除く）Coreと同等でHEVC 10-bitデコード/エンコード（※4:2:0のみ）やVP-9 10-bitデコード/8-bitエンコードに対応している。

Platform

8-bit

10-bit

MPEG-2

MPEG-4 / H.263

H.264 / AVC

H.265 / HEVC Main 4:2:0

WMV3 / VC-1

MJPEG

VP8

VP9

AV1 4:2:0

H.265 / HEVC Main10 4:2:0

H.265 / HEVC Main10 4:2:2

H.265 / HEVC Main10 4:4:4

VP9

AV1 Main 4:2:0

AV1 Main 4:4:4

Intel

Version 5 (Skylake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

-

-

-

Version 5 (Apollo Lake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

Decode

Decode

-

Version 6 (Kaby Lake, Coffee Lake, Whiskey Lake, Comet Lake, Gemini Lake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode

Version 7 (Ice Lake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

　エンコーダーなどのツールを作成されているrigaya氏が2020年にSSIMで画質比較をされた記事があるのだが（参考：個人サイトのためGoogle検索結果）、ここにあるIntel "Kaby Lake"に搭載のQuickSync Video（Version 6）が"Gemini Lake"に搭載のものと同等で、さすがにx246/x265ソフトウェアエンコードと比較すれば画質は劣り永久保存版には向かないものの、リアルタイムのエンコード/デコードであれば十分実用になるレベルといえる。
　AV-1やHEVC 10-bit 4:2:2/4:4:4や12-bitのデコード/エンコードは対応していないが、そもそもNetflixやAmazon Primeなどのビデオフォーマットを見ても、UHDやHDRを謳うタイトル以外であれば問題無く再生可能なはずである。

　MeLE Quieter2が搭載しているプロセッサーはCeleron J4215 "Gemini Lake"でCPUコアは"Goldmont Plus"である。Intel E-Coreは最近になって急激に拡張されてきているが、恐らくその転機となったのが"Goldmont"→"Goldmont Plus"ではないかと思う。そこから最新の"Gracemont"まで大幅な強化が進んでいる。
　ワークロードにもよるが"Tremont"が概ね"Goldmont Plus"の+20％前後・"Gracemont"がさらに+20％前後ほど性能が向上している。"Gracemont" 4コアが"Skylake" 2コアと同等とされているから、"Goldmont Plus" 4コアは"Haswell" 2コアと同等ぐらいの性能である（凄いのか凄くないのか、よく分からない比較）。

	Silvermont	Goldmont Plus	Tremont	Gracemont
Year	2013	2017	2019	2021
L1$I	32 KB	32 KB	32 KB	64 KB
Decode	2	3	3 x2	3 x2
ROB	32		208	256
# Exec Ports	5	9	10	17
INT ALU	2	3	3	4
Branch	(1)	1	1	2
FPU/SIMD	2	2	2	3
Load	1	2	2	2
Store Address				2
INT Store Data		1	1	2
FP Store Data			1	2
L1$D	24 KB	24 KB	24 KB	32 KB

その意味では"Tremont" CPUコアを搭載した"Jasper Lake"搭載PCの方が良かったのだろうが…"Jasper Lake"搭載PCは比較的新しいせいか€300ほどしてしまい、個人的には価値を見出せなかった。

　やや話が脱線するが、MeLE Quieter2は自宅サーバー用途としてもある程度使えそうだ。ファンレスで消費電力は非常に低いし、中華Mini PCではWindows 10 Homeを搭載しているものが多い中でMeLE Quieter2はWindows 10 Proを搭載するためRemote Desktopできるからである。

　MeLE Quieter2で1点だけ非常に残念なのは、USB Type-Cに見えるコネクターがただの電源コネクターという点だろう。個人的にはHDMI Alt Mode対応USB Type-Cはドックと接続して電源供給とHDMI出力とキーボード等の接続を纏めて行えるので便利だと思うが、本製品ではそういった接続をすることはできない。

最近の気になった話題（2021年第44-45週）

AMDに関する話題

AMD、スケーラビリティ重視の「Zen 4c」を発表 - マイナビ
AMD Bergamo to hit 128 Cores and Genoa at 96 Cores - ServeTheHome

　AMDの発表でのテーマは3D V-Cache搭載のZen 3世代Epyc = "Milan-X"だったのだろうが、個人的に興味深かったのはZen 4搭載Epyc = "Genoa" / Zen 4c搭載Epyc = "Bergamo"の話題の方だった。

"Genoa", "Bergamo"

　Zen 4世代Epyc = "Genoa"が96コアというウワサは既報の通りだが、Zen 4c搭載の"Bergamo"も併せて考えると非常に興味深い。なぜならメモリートポロジーの変更もありえるからだ。
　記事中にある通り、"Genoa"・"Bergamo"はソケットおよび命令セットを共有する。普通に考えれば、これは対応メモリーのスペック・チャンネル数とPCIeのスペック・レーン数が共通ということを示唆している。

　ところが、このうち対応メモリーのスペック（DDR5）はともかくチャンネル数については現行Zen 2/Zen 3世代からのメモリートポロジーの変更を示唆しているようにも見える。

　まず、現行Zen 2/Zen 3世代Epycのメモリートポロジーを振り返ってみる。以前も本ブログでも取り上げたことがあるが、Zen 2世代Epycについて、ServeTheHomeが「Quadrant」という構成単位を解説したことがある。このQuadrantという単位について筆者はAMD公式の資料で見たことが無いので名称の正当性は不明であるが、概念そのものはAMDのISSCC 2020の発表資料での解説とも合致する妥当なものだ。Anandtechのような海外メディアでも用いられることがある。

　1つのQuadrantは1～2 CCD x DDR4 2ch・PCIe 32レーンで構成され、Zen 2/Zen 3世代ではRyzenからEpycまで、このQuadrant単位でスケールする。Epycでは4つのQuadrantにより8 CCD・DDR4 8ch・PCIe 128レーンという構成・Ryzenでは1つのQuadrantにより1～2 CCD・DDR4 2ch・PCIe 32レーンという構成となっている。
　実際、AMDのISSCC 2020でのsIODの説明資料（Anandtechの記事中の画像）を参照しても、内部で4分割されリングバスで相互接続されていることが解る。そして、NUMAモードで運用するような場合にはNode per Socket（NPS）でQuadrant単位で分割されることになる（NPS=1の場合1 Node = 4 Quadrant・NPS=4の場合1 Node = 1 Quadrant）。
　つまり、Zen 2/Zen 3世代Epycは4 Quadrant構成のため、必ずCCD数・メモリーチャンネル数も4の倍数となりバランスされている。

　もし仮に最大8コア/CCDでZen 2/Zen 3のトポロジーのまま96コアを実現するとすれば普通に考えれば6 Quadrant構成で12 CCD・メモリー 12chとなるはずである。
　実際、Zen 4世代Epyc "Genoa"は最大96コア・12 CCDという構成（これは以前もウワサされていたが今回の発表でも明らかになっている）で、メモリーチャンネル数は公式には発表されていないがDDR5 12chとウワサされており、もしZen 2/Zen 3のメモリートポロジーが維持されていても構造的に問題はない。
　ところが、Zen 4c搭載Epyc "Bergamo"ではこの計算が合わないように見える。"Bergamo"はクラウドハイパースケーラー向けの高密度サーバー用で、上述の通り"Genoa"とソケットが共通とされている。
　しかし、CPUコア数は128で6の倍数ではなく6 Quadrantとは考え難い。マイナビ記事中で大原氏が「CCXそのものは8コアのままで16ダイを搭載か、それともCCXそのものを16コアに拡張して8ダイ構成なのかは現状不明」とされているが、いずれにせよ6 Quadrantにはならない。128コアという数字から逆算すると4 Quadrantまたは8 Quadrantが妥当で、この場合のメモリーチャンネル数は8 chまたは16 chということになる。

　"Genoa"についても"Bergamo"についてもスペックの詳細が明かされたわけでもモノが出たわけでもないので、どのようになっているのか詳細は不明である。(1) メモリートポロジーが変更されておりQuadrant単位ではなくなっている場合 (2) "Genoa"と"Bergamo"で物理的・電気的に「ソケットは共通」だが最大メモリーチャンネル数は異なる場合の2通りが考えられる。
　通常、(2)のようなことはありえないが、"Bergamo"が特定ユーザー＝クラウドハイパースケーラー限定の一般に出回らないSKUなのだとすれば特に問題にならない可能性もある。
　ちなみに、ウワサではZen 5世代でも192コア構成の通常用と256コア構成の高密度サーバー用の2種類が用意されるとされている。

※ 8 Quadrant構成で"Genoa"の96コアが12コア x 8 CCDや6コア x 16 CCDというのも計算上は成り立つが、AMDの発表資料では12 CCDのため、やはり辻褄が合わない。

Zen 4, Zen 4c

　Zen 4cという派生コアの登場は興味深い。というのも、Zen 5世代ではZen 5/Zen 5L（いずれも正式名称ではなくウワサされている名称）という2種類のコアによるAMD版big.LITTLEの導入がウワサされているからだ。

　もし"Genoa" 最大96コアと"Bergamo" 最大128コアのCCDの占める面積（≒トランジスター数）がほぼ同等とするならZen 4cはZen 4比で概ね75％という計算になる。AMDは世代毎に約+20％程度CPUコアのトランジスターバジェットを増やしているため、Zen 3→Zen 4でも同等と仮定するとZen 4とZen 4cとのトランジスター数の比率は概ね120:90となることが想定される（Zen 3を基準＝100とする場合）。
　つまり上述の仮定が正しい場合ではZen 4cコアのトランジスター数はZen 4比で約75％でしかなく、big.LITTLE構成の省電力コアとしてはかなり大型となってしまい中途半端になってしまう。ちなみにIntel P-Core/E-CoreでもArm Cortex-A70系/A50系でも省電力コアは高性能コアの1/4以下でしかない。

　しかし、さらに世代を進めZen 5世代以降では話は変わってくるかもしれない。Zen 3→Zen 4→Zen 5でこれまで通り世代毎に約+20％程度CPUコアのトランジスターバジェットが増え、さらにZen 4c→Zen 5Lのトランジスターバジェットが同等と仮定すると、Zen 5とZen 5Lとのトランジスター数の比率は144:90となり相対的に約60％まで縮小することになる。
　もちろん、上述の仮定（「"Genoa" 最大96コアと"Bergamo" 最大128コアのCCDの占める面積（≒トランジスター数）がほぼ同等」「Zen 4c→Zen 5Lのトランジスターバジェットが同等」）は筆者の推定に基づく根拠の無い数字ではあるが、技術的には実現可能そうに思える。

CDNA2

AMDのエクサスパコン用CPU「Milan-X」とGPU「Instinct MI200」を読み解く - マイナビ
AMD、Frontierに採用のカスタム版EPYCとRadeon Instinct MI200の詳細を公開 - マイナビ
The AMD “Aldebaran” GPU that won Exascale - The Next Platform

　AMDはCDNA2のWhitepaperを既に公開しており、なかなか興味深い。

　CDNA2のアーキテクチャーはCDNAによく似ている。
　個人的に気になるのは一般的な市場で売る気があるのかどうかである。FP64 Vector演算とFP64 Matrix演算の性能が大幅に強化されており、Frontierを強く意識しているように見える。その一方でFP32/FP16/bFP16についてはCDNAからほとんど変化が無く、HPC以外の用途をどの程度想定しているのか疑問である。

　MI250Xは2ダイのオンパッケージのMCMで構成されているが、各ダイのスペックはCDNA世代のMI100と酷似している。
　下の表はMI100・MI250XそしてMI250Xのダイあたりのスペックを示したものであるが、MI100とMI250X 1ダイのスペックはよく似ており、FP64 Vector・FP64 Matrixが重点的に強化されたことが解る。

	MI100 "Arcturus"	MI250X "Aldebaran"	MI250X (1 die only)
Technology	TSMC N7	TSMC N6
Die	25.6 billion 750 mm2	58.2 billion	29.1 billion
Compute Units	120	220	110
Engine Clock	1520 MHz	1700 MHz
Memory	HBM2 32GB 4 stack	HBM2E 128GB 8 stack	HBM2E 64GB 4 stack
Memory Bandwidth	1.23 TB/s	3.2 TB/s	1.6 TB/s
FP64 Vector	11.5 TFLOPS	47.9 TFLOPS	23.9 TFLOPS
FP64 Matrix	11.5 TFLOPS	95.7 TFLOPS	47.9 TFLOPS
FP32 Vector	23.1 TFLOPS	47.9 TFLOPS	23.9 TFLOPS
FP32 Matrix	46.1 TFLOPS	95.7 TFLOPS	47.9 TFLOPS
FP16 Matrix	184.6 TFLOPS	383.0 TFLOPS	191.5 TFLOPS

　そもそも、CDNAはTSMC N7で製造されたのに対し、CDNA2はTSMC N6で製造されている。N6はN7のハーフノード世代＝改良版でトランジスター密度は微増で、マクロの種類によっても異なるが、N7の96.5 MTr/mm2に対しN6は114.2 MTr/mm2で+18％に留まる。そのためMI100からMI250Xで同等のトランジスター数を維持するのであれば+13％のトランジスター数増加というのは妥当そうに思える。

　言い方を変えれば、AMDは+18％程度のトランジスターの追加でFrontierに搭載するGPUを考えたはずで、しかもEpycとの接続のためにInifnity Fabricリンクを完全結合できるように追加する必要があるから、2 ダイMCM化とFP64に絞った性能強化となったのだろう。

　AMD CDNAのMatrix UnitはNVIDIAのTensorCoreとは異なり、独立した演算ユニットではなく、既存のシェーダーの512-bit幅SIMDエンジン（shSIMD）を拡張し、Matrix演算用に512-bit幅レジスタファイルと512-bit SIMDエンジン（miSIMD）を追加したものだ。そのためMatrix演算時にはshSIMDとmiSIMDの両方が動作しVector演算の2倍のスループットを実現している。shSIMDはFP64に対応していたわけで、今回miSIMDがFP64に対応してMatrix演算でFP64演算が可能となったようだ。

Frontier

　御存知の通り、CDNA2アーキテクチャーのMI250Xは米エネルギー省フラッグシップHPC「Frontier」に搭載予定だが、CDNA2のブロック図のほか、Frontierのノード内のトポロジーについても言及がある。 以下の図はCDNA2のWhitepaperからの抜粋である。
　MI250Xでは2つのダイをパッケージ内で相互接続するMulti-Chip Moduleとなっているが、ダイにはInfinity Fabricリンクのインターフェースが8基搭載され、うち4基を使って恐らく16レーン x 2リンクづつの双方向接続を行うようだ。

　Frontierでは「最適化した」EpycにMI250Xを4基接続される。
　上述の通りダイ＝GCD間は2リンクで接続されるが、下の図のように全体で3種類のリング接続を行うようだ。これによりすべてのGCDが必ず1～2ホップで相互接続されることになる。

　ところで、Epycの「最適化」の内容が不明なのだが、1つはPCIe/Infinity Fabricレーンの使い方なのかもしれない。現行Zen 3世代EpycのsIODにはPCIe/Infinity Fabric共用のSerDesを128レーン搭載しているのだが、一部はSATAとも共有しているため、図のように16レーン x 8リンク＝128レーンをすべてInfinity Fabricで使ってしまうとNVMe SSDはおろかSATA SSD/HDDすら接続できなくなってしまう。恐らく何らかの起動用ストレージは接続されると思うが、USB 3.1で接続されるのかもしれない。
　ちなみにInfinity Fabricの帯域については「800 GB/sec」という表記がある。16レーン x 8リンクの合計とすると1リンクあたり100 GB/secで、これはPCI Express 5.0 x16（63 GB/sec）よりも高速なものである。実は、Zen 3世代EpycのPCIeはPCIe Gen 4（16.0 GT/s/Lane）であるが、Infinity Fabricと共用していることもありPHYは高速なものが使用されているようで、Zen 2世代Epyc登場時に2ソケット時のIFIS（Infinity Fabric Inter-Socket）双方向48 Laneで307.2 GB/sec（16 Laneあたり102.4 GB/sec）というのが話題になったことがある。