AMD Genoa DeepDive - Zen 4世代EPYCが志向する性能、Sapphire Rapidsとの違いが浮き彫りに
●CPU Core DeepDive
昨年11月、AMDのGenoaことEPYC 9004シリーズの発表にあわせて概要などをご紹介したが、もう少し深い分析をお届けしたいと思う。競合製品であるSapphire Rapidsシリーズも無事に発表され、やっとデータなども出揃ってきた。以前のレポートでは、AMDはGen 3 Xeonとの比較しか示していなかったし、IntelはIntelでMilan世代との比較がメインで、実際比較するとどうなのか？ が気になる方も多いかと思う。このあたりを可能な範囲でもう少し掘り下げてみたいと思う。
○CPU Core
GenoaそのものはRaphaelことRyzen 7000 Desktopと完全にコアが同一である。これは、同じGolden Coveベースのコアと言いつつAlder LakeとL2/L3のサイズが異なり、更にアクセラレータなどを大量に実装したSapphire Rapidsとは全く別であり、物理的にGenoaとRaphaelは同一のダイで構成される。異なるのはダイの数(Raphaelは1 or 2個、Genoaは4/8/12個)とIOD(I/O Die)で、このIODは全く別物である。そんなわけでGenoaのMicroarchitectureそのもの(Photo01)はRaphaelと当然同一である。
実はまだZen 4アーキテクチャの詳細そのものをこれまで説明してきていない。まもなく掲載予定のRaptor Lake Deep DiveのRMMAの部分でも要所部分の説明をご紹介しているが、良い機会なのでちょっとまとめて説明したいと思う。
まずDecoderそのもの大きな変更はない。4 x86命令/cycleでDecodeを行い、これを最大8 Micro-Op/cycleにしてMicro-op Queueに格納するだけだ。Zen 3からの最大の変更点は、AVX512命令をサポートすることである。ただしOp Cacheの方は異なり、まず従来の4KOpsから6.75KOpsに容量が拡大。更に最大9 Ops/cycleに帯域が増えている。
あとRaptor Lake Deep Dive(記事は近日掲載予定)の方で細かくグラフを示すが、以下に示すグラフ(参考グラフA)の様にNOP命令に関しては扱いが変わったようで、ピークで12 NOP Ops/cycleもの処理性能を叩き出すようになっている。これはOp CacheでのNOPの持ち方が変わったためと考えられる。
またBranch PredictionについてもL1 BTBが2×1K Entry→2×1.5K Entryに、L2 BTBが2×6.5K Entry→2×7K Entryにそれぞれ大型化された。"Predict 2 taken branches per cycle"そのものはZen 3世代で既に実現しているが、これの精度をさらに引き上げた格好だ。ちなみにBTBがL1/L2共に2setあるのはSMTに対応するためで、Thread毎に別々のBTBが用意されているわけだ。
Backendの方は、基本的には大きな構造の変化こそないものの
Register FileはINT:160→192、FP:256→320に増量
ROBのQueue Sizeは256→320に増量
AVX-512に対応
といった変更が行われている。
このROBに関してはRaptor Lake Deep Dive(記事は近日掲載予定)でも示す予定だが、以下に示すグラフ(参考グラフB/C/D/F)の様に、単に容量増加なだけでなく、On-the-Fly状態の命令数が増えても性能が悪化しにくい、まるでServer向けの様なチューニングとなっている。
他にL2キャッシュの容量が512KB/core→1MB/coreに増量されている(L3容量はZen 3と同じく32MB/CCX)。またLoad/Store improvementに出てくる"Fewer port conflicts"は詳細は明らかにされていないが、ポートの競合を防ぐような対策が施されたとの事だ。
FPU(Photo02)は上に挙げた様にAVX-512のサポートが新たに追加された。元々Zen系列はFPUが2組あり、ただしZen 1は128bit幅×2。2つを組み合わせてAVX2命令を1命令/cycleで実行可能だった。Zen 2はFPUの幅が256bit化された事で、2命令/cycleでの処理が可能になったが、完全な対称型FPUでないため、2つを組み合わせてAVX-512を実行する事は不可能であり、これはZen 3でも引き継がれた。これが完全対称型になったのがZen 4で、この結果一つのAVX-512命令を256bit幅×2のFPUで1命令/cycleで実行可能になった形だ。加えて、VNNIという名前で呼ばれるAI/ML向け命令もサポートしている。
キャッシュ周りも基本的にはZen 3と同じだが、細かく性能改良の手が入っている(Photo03)。こうした積み重ねによって、Zen 4はZen 3比でIPCが14%向上した、とされている(Photo04)。Zen 3からZen 4の主な違いをまとめたのがこちら(Photo05)。流石にL2/L3のLatencyは増えているが、L2が大容量化に伴って2cycleのLatency増加はやむを得ない(Hit率向上とのバーター)だし、L2が遅くなればこれとVictim構成になるL3が遅くなるのも仕方がないところだろう。なんにせよ、デコーダとか実行ユニットの数を増やさずに10%以上のIPC向上を実現したのは流石である。
このIPCの向上に関し、EPYCでは具体例が示されなかったが、Ryzen 7000に関しては同じ4GHz動作の場合にZen 3からの性能向上例として示されたのがこちら(Photo06)。勿論これはAVX-512を使わない場合の性能向上率である。ではAVX-512は？ というのがこちら(Photo07)である。実をいうと、この時点でGenoaはがサポートしているAVX-512命令は、かなりSapphire Rapidsに近い。Sapphire RapidsがサポートしてGenoaが未サポートのAVX-512命令は
AVX512_VP2INTERSECT
AVX512_FP16
の2つだけである。このうちAVX512_VP2INTERSECTは従来TigerLakeだけでサポートされており、一方AVX512_FP16はSapphire Rapidsで新規追加された命令である。要するに既存のAVX-512命令を利用したプログラムは原則全てGenoaで動作する筈である。この結果として、特にAI/ML関連のアプリケーションはVNNIを利用する事で大幅に高速化した、というのがPhoto07の右側である。ただVNNIでなくても、AVX512Fを利用するようなアプリケーション(HPC分野)では効果が期待できる事になる。
気になるのがSapphire Rapidsとの性能差である。Skylake-SP以来、Xeon Scalableは1cycleあたり2つのAVX-512命令を実行できる。Skylake-SPはこれを実現するため、Skylakeに無理やりAVX-512ユニットを追加している。これはIce Lake-SPやSapphire Rapidsも同じである。なので同じ動作周波数なら、Sapphire RapidsがGenoaの2倍高速という事になるのだが、実際はもう少し複雑である。というのは
コア数はGenoaの方が多い：Sapphire RapidsはハイエンドのXeon Platinum 8490Hでも60コア。一方EPYC 9654は96コアである。つまりEPYC 9654の方が60%多い。
動作周波数もGenoaの方が高め：Xeon Platinum 8490HはBase 1.9GHz/Boost 3.5GHzである。一方EPYC 9654はBase 2.4GHz/Boost 3.7GHz(All Core Boostでも3.55GHz)である。Boostで比較しても5.7%、Baseで比較すると26.3%ほどEPYC 9654の方が高い。
従来Xeon ScalableはAVX Offsetと呼ばれる機能が搭載されていた。これはAVXユニットをフル駆動すると消費電力が急速に上がってしまうため、これを防ぐためにAVXユニットの稼働率がある程度以上になる場合は動作周波数を下げて対応するという仕組みだ。Ice Lake世代ではPower Level 0〜2が設定されており、0は動作周波数が変化なし、1は若干下がる程度、2は大きく下がるという感じになっていた。Sapphire Rapidsに関しては、このAVX Offsetがどうなっているかまだ公開されていないが、無くなったという事は無いと考えられる。一方Zen 4の方はもう明示的にAVX Offsetが無いと明言されており、なのでここでも何%かのアドバンテージがEPYC 9654の方にある事になる。
実際のところ、AVX Offsetを考えにいれなくても、Base Frequencyで比較するとXeon Platinum 8490HとEPYC 9654のAVX-512命令の処理性能はほぼ同じ(1.6×1.263≒2.02で、1%ほどEPYC 9654の方が性能が高いという計算が成り立つ)である。実際にはどのSKU同士を組み合わせるのか(同じコア数で比較するのか、同じ価格帯で比較するのか、etc)で比較対象は難しいが、少なくともTop End SKU同士で言う限り最早AVX-512の性能に差はない、と考えられる。
ちなみに同じダイを利用しつつ異なるのがSecurity周り。これに関してはZen 4のコアに最初から搭載されており、ただしRyzen向けには無効化されているという形だが、Zen 4というかGenoaではMilan世代と比べて
Security Guestの数が倍増(509 Guest→1006 Guest)
AES128 Encryption/DecryptionがAES256 Encryption/Decryptionに変更
CXL MemoryもSecurity化の対象に加わった
の3点が相違点となる(Photo09)。
さて、ではこのCPU Coreの性能はどの程度であろうか？ これに関してはAMD、Intel共にそれぞれベンチマークの結果を示している。まずAMDの方だがSPECrate_2017_int_baseのスコアをモデルナンバー順に並べたのがこちら(Photo10)。同一(もしくは近似)コア数の、GenoaとIce Lake-SPの比較がこちら(Photo11,12)、ハイエンド製品同士の比較がこちら(Photo13)である。対するIntelは？ というと、もうSPECで比較する時代ではない(Photo14)として、今回Sapphire RapidsではSPECのベンチマーク結果を一切示していない。
ということで、実際に結果をSPECのデータベースから引っ張り出してくることにした。幸いFirst Quarter 2023 SPEC CPU2017 Resultには、既にSapphire RapidsやGenoaベースの結果が登録されている。ただこれだけだとIce Lake-SPやMilanのデータが足りない。そこで2023年Q3及びQ4のデータも引っ張り出して纏めたのがグラフ1と2である。
ここで
データは2 Socket構成のもののみとした(2 Socket構成のデータが一番多かったため)
SMT/Hyper Threadingは有効のもののみを抽出
動作周波数は考慮していない。というのは定格と最大動作周波数はCPUによって定められているが、実際に測定中の動作周波数は必ずしも一意に決まらない。なので動作周波数は排除して考えて居る
メモリ構成も完全に同一とは限らない
といった結果として、数字には結構バラつきがある。例えばXeon Platinum 8490Hの場合のSPEC CPU2017 FP Rate baseの数字を比較すると
といった具合に結構幅がある。なので実際グラフでは同一コア数でありながら結構数字に差が出ることになる。そうした傾向を踏まえた上で見て頂きたいが、Ice Lake-SPとSapphire Rapids、あるいはMilanとGenoa同士を比較すると、これはどちらも明確に性能の伸びがはっきり示されていると思う。破線で示した近似直線を見て頂ければこれは明白だ。そのうえでGenoa vs Sapphire Rapidsを比較すると、INT/FPのどちらの場合でも、明確にGenoa側に軍配が上がる事が見て取れると思う。単にコア数が多い分有利なだけでなく、同一コア数同士を比較してもこれである。ちなみにSPECのデータは各サーバーメーカーが自社のマシンで測定してそれを登録するものだから、条件としては公平と考えて良いと思う。なるほど、IntelがPhoto14の様な事を言い出す訳である。
ではアプリケーション性能は？ というと、こちらはメモリ回りも関係してくるので、先にメモリ回りの説明をしたいと思う。
●Memory Controller DeepDive
○Memory Controller
RaphaelとGenoaの違い、というかRyzenとEPYCの最大の違いがMemory Controllerである。勿論EPYC Gen 1/Gen 2はZen 1/Zen 2コアそのままだったからMemory ControllerもRyzenと差が無かったのだが、Zen 3以降でMemory ControllerがIODに移ったことで、ここの設計と実装は完全に異なるものになった。
さて、そのMemory Controllerであるが、Photo15の左下にあるように、12chのDDR Memoryを装着可能である。サポートされるのはRegistered DIMMと3DS Registered DIMMである。容量についてはちょっと次のスライドで説明したい。あとここで特徴であるが、GenoaではVirtual/Physical Addressが57bit/52bitの実装となっている。つまり仮想アドレスは128PB分、物理アドレスも4PB(4096TB)分ある事になる。実はこれ、CXL Memoryを考えた時に非常に重要なポイントである。Zen 3まではVirtual/Physical Addressが48bitで、これは最大256TBに相当する。DDR5をフル実装すると、現世代では6TB/Socket(256GB/DIMM)だが、次世代DDR5は12TB/Socket(512GB/DIMM)が視野には入っているが、それでも256TBあれば十分に見える。ただこれはCXLを考慮に入れなければ、の話である。詳しくはCXLの所で説明するが、GenoaではPCIe Gen5 x16接続のCXLデバイスを4つまで接続できる。ただGenoaはx16レーンを4つのx4レーンに分割可能で、なので最大構成だと16個のCXLデバイスが接続可能だ。ここに各々16TBのNAND Flash SSDを接続したら、もうこれだけで256TBであり、48bitアドレスだと飽和することになる。ところがGenoaでは52bitなので、この構成でもまだゆとりがある(計算上は256TBのNAND Flash SSDを繋がない限り大丈夫)訳で、このあたりはきちんとCXLを考慮した構成になっていると言える。
ちなみにReference Platformに関して言えば、1 Socketは2 DIMM/chを、2 Socketでは1 DIMM/chを推奨している(Photo16)。理由としては2 DIMM/chになるとメモリ速度をDDR5-4400まで落とす必要があるので、メモリ帯域そのものは減ること。それとmemcachedの様に搭載メモリ量がモノを言う(そしてプロセッサ性能はそこまで要らない)用途であれば1 Socket Serverで十分であり、そうした用途向けには2 DIMM/ch構成が適切であるが、通常のアプリケーションであればそもそも12TB/Socketものメモリ容量は不要で、6TB/Socket程度で十分である、という判断のためであろう。あともう一つ言えば、物理的に無理、という話もある。Photo17はAMDのGenoa向けの2 Socket Reference BoardであるTitaniteと言うボードの部品配置図である。実は良く見るとDIMM Slotが28本(DIMM AとGのみ2つ用意されている)あるが、この28本+CPU Socket×2でもうほぼ横幅一杯なのが判る。物理的にも1 DIMM/chにするのが現実的、という話である(19inchラックに収める必要が無ければ、また色々やりようはあるのだろうが)。余談だがDIMM A/Gのみ2 DIMM(実際にはパターンが来てるだけで、DIMMソケットそのものはA0/G0には装着されていない)なのはTitaniteが開発とか検証用のプラットフォームなので、2 DIMM/chでの動作を確認出来るように用意されているだけで、別にそう使う事を推奨している訳では無いとの事だった。
それとメモリ容量であるが、今回説明している最大12TB/Socketというのは、256GB 3DS Registered DIMMを前提にした話である。256GB×24＝12TBな訳だが、例えばSamsungは2021年3月に512GB DDR5 Moduleの量産を発表しており、おそらく現在IntelやAMDと評価を行っている最中とみられる。こちらを使った場合、メモリ容量は2倍になる計算である。もっともハイエンドのEPYC 9654(96core/192thread)の2 Socketシステムでも同時実行数は384thread。12TBという容量はthreadあたり32GBを占有できる計算になる訳で、これをさらに増やすニーズがどの程度あるか？ と言われると、相当巨大な科学技術計算など以外は想像が付かない。その意味でも割とWell balancedな容量と考えて良いかと思う。
話をMemory Controllerに戻す。Genoaでは72bitと80bitの2種類のRDIMMに対応している(Photo18)。元々DDR5の世代では、64bit幅のデータバスを2つの32bit幅に分けてそれぞれ独立に動作する様になっているが、このためECCはそれぞれ個別に必要になる。従来だと64bit幅のデータに対して8bitのECCが付加される格好だったが、DDR5世代のRDIMMでは32bit幅のデータに対して4bit ECC(ECC4)と8bit ECC(ECC8)の2種類のECCの付加の選択が可能になっている。ECC4を使う場合は36bit×2で72bit、ECC8なら40bit×2で80bitになるが、例えばx8構成のDRAMチップを使う場合、ECC4なら9チップで構成できるのに対してECC8では10チップ構成になり、コストが上がる。その一方でECC8の方が強力な保護が可能ということで、後はニーズとコストを勘案して選ぶ格好だ。先に書いたように、どちらでもGenoaでは利用可能である。
またサーバー向けということでAMD-C(Advanced Memory Device Correction)も搭載されている。AMD-Cは初代EPYCから実装されているアルゴリズムで、一つのDRAMチップ内のSingle Bit Errorだけでなく列/行/バンク/複数バンクに跨る障害に対応できるように設計されている。このあたりの実装はConsumer向けのRyzenと全く違う部分である。
Ryzenと異なる部分という意味ではMemory Populationの考え方も異なる。Photo15にもちょっと出ているが、Genoaではフル構成(12chに全てDIMMを実装)以外に2/4/6/8/10chでの構成もサポートしている。そもそもGenoaではNPS(Nodes Per Socket)という考え方がある。これは要するにNUMA分割に絡む話で、CPU全体を一つのNUMAノードとする場合、NPS1が利用される。一方で2 NUMAノードに分割するのであればNPS2、4 NUMAノードならNPS4が利用される格好だ(Photo19)。12chすべてにDIMMを実装している場合は、NPS1/2/4のどの構成も可能であるが、2〜10枚の場合はこの辺に多少制約が入る(Photo20〜22)。ちなみに1枚のみの構成も一応可能となっている(Photo23)。このあたりは構成の自由度を最大限に確保できるように工夫されている格好だ。実際のところ、例えば最大構成のEPYC 9654なら12CCDに対してDDR5が12chだから、CCDが1個あたりDDR5が1chというバランスになる。なので64core(8CCD)のEPYC 9554ならDDR5は8chでEPYC 8654と同じ帯域だし、32coreのEPYC 9354なら4chで同じ帯域になる訳で、あとは性能と価格のバランスで考えれば良いからだ。
ところで一つ気になるのはMemory Controllerそのものの性能である。と言うのは、Desktop向けのRyzenシリーズの場合、Memory Controllerの特性がDesktop向けに最適化され過ぎていたからだ。判りやすいのは、以前Ryzen 7000シリーズを試した際のRMMT Readの結果だろうか。これはWindows環境で、Threadあたり40MBのRead Requestを出し、その際のトータルのRead Bandwidthを計測するテストである。この際Ryzen 7000系のメモリ設定はDDR5-5200 CL44の2ch構成で、理論上のBandwidthは83.2GB/secになる。実際の性能はグラフからも示されるように、Ryzen 9 7950Xはピークで95.5GB/secを叩き出している。これは32MB×2のL3キャッシュにHitしている部分では当然帯域が増えるためでおかしくは無いのだが、おかしいのはこれが5 Thread動作時の性能であり、8 Threadでは67.7GB/secとかなり低めに推移していることだ。これはZen 3世代のRyzen 9 5950Xも同じである。DDR4-3200の2chなので理論帯域は51.2GB/secに対してピークは64.1GB/secと上回っているが、これは5 Threadの場合。8 Threadだと54.3GB/secと10GB/sec以上下回る値になっている。そもそもDesktopの場合、全てのThreadから同時にMemory Access Requestが出る事は非常に稀であり、むしろ全体のなかで少数のコア(というか、Thread)が集中してMemory Accessするようなパターンの方が多いだろう。恐らくRyzenのIODに搭載されたMemory Controllerはこうしたニーズに対応する様に設計されており、なので多数のCore/Threadから一斉にMemory Requestが殺到するような構成ではQueueが長くなるというか溢れる事になり、Core側のLoad Requestに対して迅速に反応ができなくなる(RequestへのAckを送らない事でFlow Controlを行っている)と思われる。実際Desktop向けに、膨大なI/O Request Queueを用意するのはリソースの観点から見ても無駄が多い。
ただこれはServer用途に向いた設計とは言えない。そこで、実際のところどうか？ というのをちょっと確認してみる事にした。実は今回AMDのLabに設置されたEPYC 9654の2 Socket Systemをリモートで利用する機会に恵まれた。生憎競合製品とかMilanベースのシステムとの比較を行う事は出来なかったし、リモート(設置場所は米テキサス州オースチンだったので、物理的に10000Km彼方である)ということでOSの入れ替えなどは不可能だったしアプリケーションのインストールも難しかったのだが、とりあえずメモリ帯域の測定の為にStreamを実施することが可能だったので、この結果をご紹介したい。
プラットフォームは先ほどPhoto17でご紹介したTitanite Boardで、ここにEPYC 9654×2と64GB DDR5-4800 RDIMM×24(合計容量1.5TB)が搭載されている。OSはLinux(Kernel 5.15.0-52-generic)がインストールされている状態だ。
ベンチマークだが、スタンダードなところでstreamを利用した。テスト方法だが、このstreamをOpenMP Enableな状態(gcc -O -fopenmpでコンパイル)にしたうえで、
同時実行スレッドを1〜384まで可変
streamのArray Size(テストに利用する配列数)を1億個〜13億個まで1億個ずつ増加(ArrayはDouble:8byteなので、アクセスするメモリ量としては76.3MB〜534.1MBになる(13億個までなのは、それ以上増やすとコンパイルエラーが起きるためである)。
という条件で実施し、その際のTriadのBandwidthをプロットしてみたのがグラフ3である。スレッド数が最大384といっても実際はメモリ共有をする関係で、最大構成(384 Thread/13億個)でも消費メモリ量は2.9GBに過ぎないので、1.5TBのシステムで確認するには十分である。
さて結果であるが、必要メモリ量が少ない範囲(1〜4億個)位までは結構L3キャッシュ(2 Socketで合計768MB)にHitする確率が高い(というか、3億個だと全体で686.6MBしか必要としないので、完全にL3でHitする)事もあってかなり広めの帯域になっているが、5億個以降ではL3が飽和する事もあり、実際にメモリアクセスが発生する事もあって、Thread数が増えるにつれて実効帯域が減ってゆく(それだけメモリアクセスの頻度が上がるため)。10〜13億個になると、もうL3の効果が殆ど無くなるので、ほぼ生のメモリアクセス性能が示されていると考えて良いかと思う。ちなみに1〜3億個で192 Threadの時に大きなギャップがあるのは、このタイミングで1 Socketの有効Thread数を使い切り、2 Socket目に移るためと考えられる。残念ながらStreamのOpenMPの実装は、2つのCPUを均等に使うのではなく、まず1つ目を使いつくしたら2つ目に移る感じになっているようだ。ただ同一CPUの中では、12個のコアを均等に使う様にスケジュールされている様に見える(96 Threadあたりから、24 Thread周期で三角波の様な傾向が示されているのがその傍証だ)。
まぁそうした特徴はともかくとして、384 Threadをフルに動かした際のBandwidthを見ると
といったところで、概ねこの640GB/secあたりがStreamを使った場合のピーク性能と考えて良さそうだ。理論帯域はDDR5-4800×12ch×2 Socketで921.6GB/secだから、効率は69.4%とかなり高い(通常streamだと60%程度になるのが普通)。また、RyzenのRMMTの時の様な、Thread数による変動もそれほど大きくない。なにより、3GBほどのアクセスを連続して行っても殆ど性能に変化が無い辺りは、Ryzenとは全く異なるメモリコントローラの実装になっていることの証明ともいえる。実は筆者、このメモリコントローラ周りの癖が一番気になっていただけに、ちょっと安心である。
ちなみに検証のために、Ryzen 7 7700XとRyzen 9 7950Xでも同じように実施してみた結果がグラフ4と5である。こちらはUbuntu Desktop 22.04(Kernel 5.15.0-58-generic)で実施している。メモリはDDR5-4800構成だ。Thread数はそれぞれの製品に合わせて最大16 Thread/32 Threadにしている。
こちらでも1億個だと76.3MBしか使わない関係でかなりL3が効果的に作用する関係でやや高い帯域を示すが、13億個あたりになると最早Ryzen 9 7950XでもL3が飽和するので、ほぼ地のメモリ帯域が示される格好だ。で、13億個の数字で言うと、
といったところで、どちらも理論帯域(DDR5-4800×2chで76.8GB/sec)の47〜48%程度の効率でしかない事を考えると、Genoaのメモリコントローラの効率が実に良い事が伺い知れる。ついでに言えば、グラフ4・5共に2 Threadの時にピークがあり、そこからじわじわと性能が下がってゆく、というあたりがRyzen 7000シリーズのIOD内蔵Memory Controllerの癖であり、これをRMMTだけでなくStreamでも確認できた格好だ。
●CXL DeepDive
○CXL
Memory Controllerのついでに、CXLについても触れておきたい。CXLはAccelerator及びAttached Memory向けのI/Fなので、別にAttached Memory専用という訳では無い。しかしながら、IntelがOptane Memoryのビジネスを収束させることを発表し、かつ3rd PartyのNVDIMMが不発というか全然盛り上がっていない現状で、大きく期待されているのがCXLを利用したAttached Memoryであるのは事実である。実際MicronはOptaneというか3D XPointのビジネスから撤退を発表した際のリリースの中で"Micron sees immense promise in new classes of memory-centric solutions that utilize CXL to scale the capacity, performance and content required by applications to run on infrastructure with greater architectural freedom."(Micronは、CXLを利用することで、アプリケーションに必要な容量、性能、コンテンツを拡張し、アーキテクチャの自由度が高いインフラストラクチャで実行する、新しいクラスのメモリ中心のソリューションに大きな可能性を見出している)と明言しており、非常に積極的である。
そもそもIn-Memory ComputingはこれまでIntelのOptane Persistent Memoryを中心にソフトウェアが開発されてきたこともあって、現状はXeonの独壇場である。ところがそのOptane Persistent Memoryそのものの先行きが無くなってしまった。とりあえずSapphire Rapids向けにはCrow Passとして開発されてきたOptane Persistent Memory 300シリーズがリリースされたが、こちらは容量512GB。Xeonの場合は8chのDIMMにこのOptane Persistent Memoryと通常のRDIMMを1枚づつ装着することで、chあたり768GB。8ch合計で6TBの容量が確保できるとしているが、Genoaはそもそも12chに2枚づつ256GB DIMMを装着すれば6TB容量になるわけで、もはやOptane Persistent Memoryのメリットは半減している(不揮発性、という部分に多少のメリットが残される程度)。しかもCXLで利用可能なSwitchを利用したMemory Poolみたいな事はOptane Persistent Memoryには不可能である。なのでこれまでOptane Persistent Memoryを前提に構築されていたIn-Memory Computing Applicationは、現在CXLベースへの移行作業を始めていると思われるが、これには相応の時間が掛かる。Optane Persistent Memory 300シリーズは、このアプリケーションの移行作業が完了するまでの間、既存のアプリケーションを使える様にするために提供されていると考えれば良いだろう。
さてそんなCXLであるが、AMDは割と意欲的であり、Genoaは、CXL 1.1+の機能が実装されている(Photo24)。"+"って何だ？ という話だが、GenoaはCXL 1.1に完全準拠した上で、CXL 2.0の一部の機能を先行して実装している。具体的にはCXL 2.0で追加されたRAS機能及びPersistent Memoryのサポートである。2.0で追加されたその他の機能、具体的にはCXL SwitchingとかMemory Pooling、Hot plug、QoS telemetry、eFLRなどの機能はまだ未実装である。もっともMemory PoolingとかSwitchはCPU側が対応しただけでは駄目で、SwitchやらPool用のApplianceの開発も必要になるから、現状はまだ時期尚早というのは判る。それよりもRAS機能とPersistent Memoryのサポートが早くも追加されたことで、DRAMだけでなくNAND FlashベースのSSDも接続が可能になったという事は大きい。先ほどPhysical Addressが52bitになった話の説明の中で、16TBのNAND SSDベースCXL Memoryを引き合いに出したが、実際にGenoaでは技術的にはこれが可能にである(Sapphire Rapidsは今のところDRAMベースのMemoryしかサポートしていない)。
もう一つ、Sapphire RapidsがサポートしておらずGenoaがサポートしている機能に、Lane Bifurcationがある。Photo16で、1つのGenoaのSocketからは4本のCXL Linkが出ているのが判るかと思うが、各々のLaneはx16になっている。Sapphire Rapidsも同じくx16構成のCXL Laneを4つ利用可能であり、対応するDeviceは4つである。例えばx4構成のCXL Memoryを装着した場合、残りのx12 Laneには何も装着できなくなる。これに対してGenoaの場合、x16 Laneをx8 Lane×2、あるいはx4 Lane×4に分割して、それぞれ別のCXL Memoryを接続する事が可能になっている。なので、x4 Lane Memoryなら最大16個装着できる格好だ。
ちなみにこの分割したLaneはInterleaveも可能になっている。x8 Lane×2の場合は64Bytes Boundaryで、x4 Lane×4の場合は256Bytes BoundaryでInterleaveが行われる格好だ。更に言えば、4つのCXL Link同士でも2-wayないし4-wayのInterleaveが可能であり、全体を一つのCXL Memoryブロックとして扱う事も出来るようになっている。
一方、これに装着できるCXL Deviceの方は？ というと、昨年5月にSamsungは512GB CXL DRAMのサンプル出荷を発表している(Photo25)し、Genoaの発表にあたっては多くのベンダーのプロトタイプが示された(Photo26)。
Astera Labs(Photo27,28)は実際にCXLの先にそれぞれ2chのDDR5 DIMMを装着して、ローカルのDDR5-4800と性能差が無い事をアピールした。実際PCIe Gen5 x16だからレーンの帯域は64GB/secになり、DDR5-4800の2ch(76.8GB/sec)にはやや届かない計算になるが、実際にはそこまでの帯域を使い切れないというのは先のStreamのベンチマークでも示された通り。Photo28の結果はnumactlを使ってベンチマークを行った場合のもので、別のNUMAノードとしてCXL経由でDDR5を利用できるとしている。
MicronはE3.sモジュールを通常のDIMMと混載する形で動作させ、帯域が1.43倍(PCIe Gen4)〜2倍(PCIe Gen5)に増えるというLive Demoを披露した(Photo29)。
もう少し凝ったLive Demoを披露したのはMicronである。先に書いたように現状のGenoaではまだMemory Poolingには未対応であるが、MarvellはこれをMemory Appliance側に実装する事で実質的にSwitchとMemory Poolを実現するという構成である(Photo30)。このMemory ApplianceはほぼEPYCの2Uサーバーと同じ程度のサイズである(Photo31)。これ一つで6つのMemory Deviceを構築できる予定らしいが、内部構造(Photo32)を見ていると2 Deviceにしか思えないあたりがちょっと謎である。Photo31は現在のテストシステムの構成、Photo32は将来の予定構成なのかもしれない。実際に、Marvellの提供するソフトウェアを利用してMemory Poolingが行える様子も示された(Photo33)。
CXLのエコシステムは、やっと商用プラットフォームが立ち上がったという段階なので、次にOSやミドルウェア、アプリケーションのベンダーがこれに対応するフェーズに入った訳で、CXLベースのIn-Memory Computingが本格的に立ち上がるのは2024〜2025年辺りになりそうではあるが、ただそうしたCXLの立ち上がりを牽引してゆくのはGenoaという事になるだろう。
勿論CXLのエコシステムはIntelを無視する訳では無いだろう。Sapphire Rapidsは、公式にはType 3(つまりCXL Memory Expansion)は未サポートであるが、プロトコルとしてはCXL.io/CXL.mem/CXL.cacheの3つを完全にサポートしており、Type 3に関しては「技術的には動作するが、検証プラットフォームが無い関係でValidationを行っていないので、サポートを表明していない」という扱いである。なので現実問題としては動作するだろうし、エコシステムでも対応や検証を行ってゆくだろうとは思うが、先に書いたようにRAS機能とかPersistent Memoryは今のところGenoaのみのサポートだし、Lane Bifurcationのサポートも無いので、ちょっと使い勝手は悪いだろう。なによりOptane Persistent Memory 300をサポートしている間は、公式にもCXL Memory Deviceをサポートするとは表明しにくいと考えられる。そうした意味でも、現状ではGenoaを利用してアプリケーションのCXL Memory対応を進めるのが賢明と考えられる。
●Application Performance DeepDive
○Application Performance
さて、Intelによれば(Photo14参照)、一番肝心のApplication Performanceである。これが意外に比較が難しい。例えばEnterprise&Cloudの分野でIntelが出しているPerformance Dataは例えばこんな具合(Photo34)で、2世代前(つまりCascade Lake-SP)世代のものとの比較である。あるいはMicroserverではDeath Star benchの結果が示されている(Photo35)が、こちらはGenoaでの実施例がまだ存在しないので比較できないといった具合。これはAI&MLの分野も同じで、こちらはAMDがまだGenoaでの具体的なTraining/Inference性能を公開していないからという理由もあるのだが、比較が出来ないでいる。
唯一比較が可能だったのがHPC向けのマーケット。こちらのスライド(Photo36)によれば、Ansys FluentでのSapphire Rapidsの性能は、Xeon Platinum 8380の1.6倍であるとされている。一方でGenoaは、やはりXeon Platinum 8380と比較して2.5倍程度の性能であるとしている(Photo37)。AMD/Intel共に絶対的なスコアは示していないので、これで検証というのも難しいが、AMDのPerformance Numberの公開サイトではスコアも示されており、(Ansys Fluent 2022R2ではあるが)
といった数字を拾う事が出来る。ちなみにAnsys自身での測定結果で、GenoaはMilan比で29%〜70%と結構高速化しているとされており(Photo38)、恐らく1〜2 Socket構成で考える限りにおいてはGenoaの方が高速と考えて良いだろう。
もう少し公開データで、しかも実アプリケーションに近いものは？ ということで、グラフ6はSPECjbb-2015の公開データから、Genoa及びSapphire Rapidsの結果を拾ったものである。Genoaは2022年Q4、Sapphire Rapidsは2023年Q1からPickupしている(どちらも2 Socketの構成のみ)。横軸はmax-jOPS、縦軸はcritical-jOPSで、どちらも数字が高いほど性能が高い。max-iOPSの方は文字通りピークのjava Operation性能、critical-jOPSの方はSLAが10000μs/25000μs/50000μs/750000μs/100000μsの場合の幾何平均で、まぁ実効性能に近い。で、当然システム構成によって多少のばらつきはある訳だが、全体的に言ってGenoaはSapphire Rapidsの2倍近いjOPSを叩き出している。maxの方は概ね2倍だが、criticalの方はそこまでいかず1.7倍程度であるが、どちらにしても圧倒的な性能差である。気になるのは、Xeon Platinum 8490Hがmax-jOPSが高い割にcritical-jOPSが低めな事である。むしろXeon Platinum 8480+の方がバランスが良い感じだが、いずれにしても性能に大差がついている事そのものに違いはない。
同様にSPEChpcの結果だが、こちらはまだ公開されている数が少ないので、表形式で。
どちらもOpenMPを使った結果での比較である。ちなみにSPEChpcはテストで利用するデータセットのサイズでTiny/Small/Medium/Largeの4つがあるが、Medium/Largeは今のところ公開データが0なので比較対象となっていない。ちなみに条件で言えば、xFusionの2288H V7は1TB Memory、Lenovo ThinkSystem SR665 V3は768GB Memoryなので、どちらかと言えばXeon Platinum 8490Hが有利な筈だが、Tiny/Small程度のデータセットではメモリをそこまで使わないから差が出ないものと思われる。
同様にベンチマーク結果が公開されているものとしてはTPCがあるが、こちらは現状Genoaについては幾つか公開されているものの、Sapphire Rapidsに関しては結果が全く登録されていない。TPCはいずれも実施に結構な時間とコストが掛かるだけに、登録されるまでにはもう少し時間を要するものと思われる。
これ以外にベンチマークは？ というと、phoronixが今年1月10日に、Intel Xeon Platinum 8490H "Sapphire Rapids" Performance Benchmarksを公開している。こちらは
AMD：EPYC 7713/EPYC 7763/EPYC 7773X/EPYC 9374F/EPYC 9554/EPYC 9654
Intel：Xeon Platinum 8362/Xeon Platinum 8380/Xeon Platinum 8490H
の合計9種類の構成で多数のテストを実施している(流石に結果をここで転載するのは問題があるので、興味ある方はphoronixの記事を参照してほしい)。こちらでも、Genoaのスコアがかなり良好であることが示されている。
●考察 - Genoaの真実、Sapphire Rapidsとは異なる方向性
○考察
ということで4パートに分けてGenoaの特徴をご紹介してきた。競合となるのはSapphire Rapidsこと第4世代Xeon Scalable(とXeon MAX)ということになるが、そもそも最大でも$11,000(EPYC 9654)であり、$17,000のSapphire Rapids(Xeon Platinum 8490H)とは比較にならない。消費電力は定格で360W(EPYC 9654)と350W(Xeon Platinum 8490H)だから同程度というかややGenoaが高い様に見えるが、EPYC 9654が96コアとXeon Platinum 8490Hより60%もコア数が多く、しかも動作周波数もやや高めという事を考えると、性能/消費電力比ではGenoaの方に軍配が上がる事になる。
Sapphire Rapidsのメリットは様々なアクセラレータを搭載している事と、4/8 Socketまでの拡張が可能な事で、Genoaを選ぶかSapphire Rapidsを選ぶか？ という選択の際の基準は、こうしたSapphire Rapidsのメリットが自身のニーズに合致しているか否か、というあたりになりそうだ。
EPYCも第4世代になり、熟成が進んだ感がある。Xeon Scalableも奇しくも第4世代な訳だが、基本性能を高めるか、重厚なアクセラレータを搭載するか、という方向性の違いが浮き彫りになった気もしなくはない。どちらが正解というものでもないのだろうが、さてユーザーニーズに応えやすいのはどちらであろうか？
昨年11月、AMDのGenoaことEPYC 9004シリーズの発表にあわせて概要などをご紹介したが、もう少し深い分析をお届けしたいと思う。競合製品であるSapphire Rapidsシリーズも無事に発表され、やっとデータなども出揃ってきた。以前のレポートでは、AMDはGen 3 Xeonとの比較しか示していなかったし、IntelはIntelでMilan世代との比較がメインで、実際比較するとどうなのか？ が気になる方も多いかと思う。このあたりを可能な範囲でもう少し掘り下げてみたいと思う。
GenoaそのものはRaphaelことRyzen 7000 Desktopと完全にコアが同一である。これは、同じGolden Coveベースのコアと言いつつAlder LakeとL2/L3のサイズが異なり、更にアクセラレータなどを大量に実装したSapphire Rapidsとは全く別であり、物理的にGenoaとRaphaelは同一のダイで構成される。異なるのはダイの数(Raphaelは1 or 2個、Genoaは4/8/12個)とIOD(I/O Die)で、このIODは全く別物である。そんなわけでGenoaのMicroarchitectureそのもの(Photo01)はRaphaelと当然同一である。
実はまだZen 4アーキテクチャの詳細そのものをこれまで説明してきていない。まもなく掲載予定のRaptor Lake Deep DiveのRMMAの部分でも要所部分の説明をご紹介しているが、良い機会なのでちょっとまとめて説明したいと思う。
まずDecoderそのもの大きな変更はない。4 x86命令/cycleでDecodeを行い、これを最大8 Micro-Op/cycleにしてMicro-op Queueに格納するだけだ。Zen 3からの最大の変更点は、AVX512命令をサポートすることである。ただしOp Cacheの方は異なり、まず従来の4KOpsから6.75KOpsに容量が拡大。更に最大9 Ops/cycleに帯域が増えている。
あとRaptor Lake Deep Dive(記事は近日掲載予定)の方で細かくグラフを示すが、以下に示すグラフ(参考グラフA)の様にNOP命令に関しては扱いが変わったようで、ピークで12 NOP Ops/cycleもの処理性能を叩き出すようになっている。これはOp CacheでのNOPの持ち方が変わったためと考えられる。
またBranch PredictionについてもL1 BTBが2×1K Entry→2×1.5K Entryに、L2 BTBが2×6.5K Entry→2×7K Entryにそれぞれ大型化された。"Predict 2 taken branches per cycle"そのものはZen 3世代で既に実現しているが、これの精度をさらに引き上げた格好だ。ちなみにBTBがL1/L2共に2setあるのはSMTに対応するためで、Thread毎に別々のBTBが用意されているわけだ。
Backendの方は、基本的には大きな構造の変化こそないものの
Register FileはINT:160→192、FP:256→320に増量
ROBのQueue Sizeは256→320に増量
AVX-512に対応
といった変更が行われている。
このROBに関してはRaptor Lake Deep Dive(記事は近日掲載予定)でも示す予定だが、以下に示すグラフ(参考グラフB/C/D/F)の様に、単に容量増加なだけでなく、On-the-Fly状態の命令数が増えても性能が悪化しにくい、まるでServer向けの様なチューニングとなっている。
他にL2キャッシュの容量が512KB/core→1MB/coreに増量されている(L3容量はZen 3と同じく32MB/CCX)。またLoad/Store improvementに出てくる"Fewer port conflicts"は詳細は明らかにされていないが、ポートの競合を防ぐような対策が施されたとの事だ。
FPU(Photo02)は上に挙げた様にAVX-512のサポートが新たに追加された。元々Zen系列はFPUが2組あり、ただしZen 1は128bit幅×2。2つを組み合わせてAVX2命令を1命令/cycleで実行可能だった。Zen 2はFPUの幅が256bit化された事で、2命令/cycleでの処理が可能になったが、完全な対称型FPUでないため、2つを組み合わせてAVX-512を実行する事は不可能であり、これはZen 3でも引き継がれた。これが完全対称型になったのがZen 4で、この結果一つのAVX-512命令を256bit幅×2のFPUで1命令/cycleで実行可能になった形だ。加えて、VNNIという名前で呼ばれるAI/ML向け命令もサポートしている。
キャッシュ周りも基本的にはZen 3と同じだが、細かく性能改良の手が入っている(Photo03)。こうした積み重ねによって、Zen 4はZen 3比でIPCが14%向上した、とされている(Photo04)。Zen 3からZen 4の主な違いをまとめたのがこちら(Photo05)。流石にL2/L3のLatencyは増えているが、L2が大容量化に伴って2cycleのLatency増加はやむを得ない(Hit率向上とのバーター)だし、L2が遅くなればこれとVictim構成になるL3が遅くなるのも仕方がないところだろう。なんにせよ、デコーダとか実行ユニットの数を増やさずに10%以上のIPC向上を実現したのは流石である。
このIPCの向上に関し、EPYCでは具体例が示されなかったが、Ryzen 7000に関しては同じ4GHz動作の場合にZen 3からの性能向上例として示されたのがこちら(Photo06)。勿論これはAVX-512を使わない場合の性能向上率である。ではAVX-512は？ というのがこちら(Photo07)である。実をいうと、この時点でGenoaはがサポートしているAVX-512命令は、かなりSapphire Rapidsに近い。Sapphire RapidsがサポートしてGenoaが未サポートのAVX-512命令は
AVX512_VP2INTERSECT
AVX512_FP16
の2つだけである。このうちAVX512_VP2INTERSECTは従来TigerLakeだけでサポートされており、一方AVX512_FP16はSapphire Rapidsで新規追加された命令である。要するに既存のAVX-512命令を利用したプログラムは原則全てGenoaで動作する筈である。この結果として、特にAI/ML関連のアプリケーションはVNNIを利用する事で大幅に高速化した、というのがPhoto07の右側である。ただVNNIでなくても、AVX512Fを利用するようなアプリケーション(HPC分野)では効果が期待できる事になる。
気になるのがSapphire Rapidsとの性能差である。Skylake-SP以来、Xeon Scalableは1cycleあたり2つのAVX-512命令を実行できる。Skylake-SPはこれを実現するため、Skylakeに無理やりAVX-512ユニットを追加している。これはIce Lake-SPやSapphire Rapidsも同じである。なので同じ動作周波数なら、Sapphire RapidsがGenoaの2倍高速という事になるのだが、実際はもう少し複雑である。というのは
コア数はGenoaの方が多い：Sapphire RapidsはハイエンドのXeon Platinum 8490Hでも60コア。一方EPYC 9654は96コアである。つまりEPYC 9654の方が60%多い。
動作周波数もGenoaの方が高め：Xeon Platinum 8490HはBase 1.9GHz/Boost 3.5GHzである。一方EPYC 9654はBase 2.4GHz/Boost 3.7GHz(All Core Boostでも3.55GHz)である。Boostで比較しても5.7%、Baseで比較すると26.3%ほどEPYC 9654の方が高い。
従来Xeon ScalableはAVX Offsetと呼ばれる機能が搭載されていた。これはAVXユニットをフル駆動すると消費電力が急速に上がってしまうため、これを防ぐためにAVXユニットの稼働率がある程度以上になる場合は動作周波数を下げて対応するという仕組みだ。Ice Lake世代ではPower Level 0〜2が設定されており、0は動作周波数が変化なし、1は若干下がる程度、2は大きく下がるという感じになっていた。Sapphire Rapidsに関しては、このAVX Offsetがどうなっているかまだ公開されていないが、無くなったという事は無いと考えられる。一方Zen 4の方はもう明示的にAVX Offsetが無いと明言されており、なのでここでも何%かのアドバンテージがEPYC 9654の方にある事になる。
実際のところ、AVX Offsetを考えにいれなくても、Base Frequencyで比較するとXeon Platinum 8490HとEPYC 9654のAVX-512命令の処理性能はほぼ同じ(1.6×1.263≒2.02で、1%ほどEPYC 9654の方が性能が高いという計算が成り立つ)である。実際にはどのSKU同士を組み合わせるのか(同じコア数で比較するのか、同じ価格帯で比較するのか、etc)で比較対象は難しいが、少なくともTop End SKU同士で言う限り最早AVX-512の性能に差はない、と考えられる。
ちなみに同じダイを利用しつつ異なるのがSecurity周り。これに関してはZen 4のコアに最初から搭載されており、ただしRyzen向けには無効化されているという形だが、Zen 4というかGenoaではMilan世代と比べて
Security Guestの数が倍増(509 Guest→1006 Guest)
AES128 Encryption/DecryptionがAES256 Encryption/Decryptionに変更
CXL MemoryもSecurity化の対象に加わった
の3点が相違点となる(Photo09)。
さて、ではこのCPU Coreの性能はどの程度であろうか？ これに関してはAMD、Intel共にそれぞれベンチマークの結果を示している。まずAMDの方だがSPECrate_2017_int_baseのスコアをモデルナンバー順に並べたのがこちら(Photo10)。同一(もしくは近似)コア数の、GenoaとIce Lake-SPの比較がこちら(Photo11,12)、ハイエンド製品同士の比較がこちら(Photo13)である。対するIntelは？ というと、もうSPECで比較する時代ではない(Photo14)として、今回Sapphire RapidsではSPECのベンチマーク結果を一切示していない。
ということで、実際に結果をSPECのデータベースから引っ張り出してくることにした。幸いFirst Quarter 2023 SPEC CPU2017 Resultには、既にSapphire RapidsやGenoaベースの結果が登録されている。ただこれだけだとIce Lake-SPやMilanのデータが足りない。そこで2023年Q3及びQ4のデータも引っ張り出して纏めたのがグラフ1と2である。
ここで
データは2 Socket構成のもののみとした(2 Socket構成のデータが一番多かったため)
SMT/Hyper Threadingは有効のもののみを抽出
動作周波数は考慮していない。というのは定格と最大動作周波数はCPUによって定められているが、実際に測定中の動作周波数は必ずしも一意に決まらない。なので動作周波数は排除して考えて居る
メモリ構成も完全に同一とは限らない
といった結果として、数字には結構バラつきがある。例えばXeon Platinum 8490Hの場合のSPEC CPU2017 FP Rate baseの数字を比較すると
といった具合に結構幅がある。なので実際グラフでは同一コア数でありながら結構数字に差が出ることになる。そうした傾向を踏まえた上で見て頂きたいが、Ice Lake-SPとSapphire Rapids、あるいはMilanとGenoa同士を比較すると、これはどちらも明確に性能の伸びがはっきり示されていると思う。破線で示した近似直線を見て頂ければこれは明白だ。そのうえでGenoa vs Sapphire Rapidsを比較すると、INT/FPのどちらの場合でも、明確にGenoa側に軍配が上がる事が見て取れると思う。単にコア数が多い分有利なだけでなく、同一コア数同士を比較してもこれである。ちなみにSPECのデータは各サーバーメーカーが自社のマシンで測定してそれを登録するものだから、条件としては公平と考えて良いと思う。なるほど、IntelがPhoto14の様な事を言い出す訳である。
ではアプリケーション性能は？ というと、こちらはメモリ回りも関係してくるので、先にメモリ回りの説明をしたいと思う。
●Memory Controller DeepDive
○Memory Controller
RaphaelとGenoaの違い、というかRyzenとEPYCの最大の違いがMemory Controllerである。勿論EPYC Gen 1/Gen 2はZen 1/Zen 2コアそのままだったからMemory ControllerもRyzenと差が無かったのだが、Zen 3以降でMemory ControllerがIODに移ったことで、ここの設計と実装は完全に異なるものになった。
さて、そのMemory Controllerであるが、Photo15の左下にあるように、12chのDDR Memoryを装着可能である。サポートされるのはRegistered DIMMと3DS Registered DIMMである。容量についてはちょっと次のスライドで説明したい。あとここで特徴であるが、GenoaではVirtual/Physical Addressが57bit/52bitの実装となっている。つまり仮想アドレスは128PB分、物理アドレスも4PB(4096TB)分ある事になる。実はこれ、CXL Memoryを考えた時に非常に重要なポイントである。Zen 3まではVirtual/Physical Addressが48bitで、これは最大256TBに相当する。DDR5をフル実装すると、現世代では6TB/Socket(256GB/DIMM)だが、次世代DDR5は12TB/Socket(512GB/DIMM)が視野には入っているが、それでも256TBあれば十分に見える。ただこれはCXLを考慮に入れなければ、の話である。詳しくはCXLの所で説明するが、GenoaではPCIe Gen5 x16接続のCXLデバイスを4つまで接続できる。ただGenoaはx16レーンを4つのx4レーンに分割可能で、なので最大構成だと16個のCXLデバイスが接続可能だ。ここに各々16TBのNAND Flash SSDを接続したら、もうこれだけで256TBであり、48bitアドレスだと飽和することになる。ところがGenoaでは52bitなので、この構成でもまだゆとりがある(計算上は256TBのNAND Flash SSDを繋がない限り大丈夫)訳で、このあたりはきちんとCXLを考慮した構成になっていると言える。
ちなみにReference Platformに関して言えば、1 Socketは2 DIMM/chを、2 Socketでは1 DIMM/chを推奨している(Photo16)。理由としては2 DIMM/chになるとメモリ速度をDDR5-4400まで落とす必要があるので、メモリ帯域そのものは減ること。それとmemcachedの様に搭載メモリ量がモノを言う(そしてプロセッサ性能はそこまで要らない)用途であれば1 Socket Serverで十分であり、そうした用途向けには2 DIMM/ch構成が適切であるが、通常のアプリケーションであればそもそも12TB/Socketものメモリ容量は不要で、6TB/Socket程度で十分である、という判断のためであろう。あともう一つ言えば、物理的に無理、という話もある。Photo17はAMDのGenoa向けの2 Socket Reference BoardであるTitaniteと言うボードの部品配置図である。実は良く見るとDIMM Slotが28本(DIMM AとGのみ2つ用意されている)あるが、この28本+CPU Socket×2でもうほぼ横幅一杯なのが判る。物理的にも1 DIMM/chにするのが現実的、という話である(19inchラックに収める必要が無ければ、また色々やりようはあるのだろうが)。余談だがDIMM A/Gのみ2 DIMM(実際にはパターンが来てるだけで、DIMMソケットそのものはA0/G0には装着されていない)なのはTitaniteが開発とか検証用のプラットフォームなので、2 DIMM/chでの動作を確認出来るように用意されているだけで、別にそう使う事を推奨している訳では無いとの事だった。
それとメモリ容量であるが、今回説明している最大12TB/Socketというのは、256GB 3DS Registered DIMMを前提にした話である。256GB×24＝12TBな訳だが、例えばSamsungは2021年3月に512GB DDR5 Moduleの量産を発表しており、おそらく現在IntelやAMDと評価を行っている最中とみられる。こちらを使った場合、メモリ容量は2倍になる計算である。もっともハイエンドのEPYC 9654(96core/192thread)の2 Socketシステムでも同時実行数は384thread。12TBという容量はthreadあたり32GBを占有できる計算になる訳で、これをさらに増やすニーズがどの程度あるか？ と言われると、相当巨大な科学技術計算など以外は想像が付かない。その意味でも割とWell balancedな容量と考えて良いかと思う。
話をMemory Controllerに戻す。Genoaでは72bitと80bitの2種類のRDIMMに対応している(Photo18)。元々DDR5の世代では、64bit幅のデータバスを2つの32bit幅に分けてそれぞれ独立に動作する様になっているが、このためECCはそれぞれ個別に必要になる。従来だと64bit幅のデータに対して8bitのECCが付加される格好だったが、DDR5世代のRDIMMでは32bit幅のデータに対して4bit ECC(ECC4)と8bit ECC(ECC8)の2種類のECCの付加の選択が可能になっている。ECC4を使う場合は36bit×2で72bit、ECC8なら40bit×2で80bitになるが、例えばx8構成のDRAMチップを使う場合、ECC4なら9チップで構成できるのに対してECC8では10チップ構成になり、コストが上がる。その一方でECC8の方が強力な保護が可能ということで、後はニーズとコストを勘案して選ぶ格好だ。先に書いたように、どちらでもGenoaでは利用可能である。
またサーバー向けということでAMD-C(Advanced Memory Device Correction)も搭載されている。AMD-Cは初代EPYCから実装されているアルゴリズムで、一つのDRAMチップ内のSingle Bit Errorだけでなく列/行/バンク/複数バンクに跨る障害に対応できるように設計されている。このあたりの実装はConsumer向けのRyzenと全く違う部分である。
Ryzenと異なる部分という意味ではMemory Populationの考え方も異なる。Photo15にもちょっと出ているが、Genoaではフル構成(12chに全てDIMMを実装)以外に2/4/6/8/10chでの構成もサポートしている。そもそもGenoaではNPS(Nodes Per Socket)という考え方がある。これは要するにNUMA分割に絡む話で、CPU全体を一つのNUMAノードとする場合、NPS1が利用される。一方で2 NUMAノードに分割するのであればNPS2、4 NUMAノードならNPS4が利用される格好だ(Photo19)。12chすべてにDIMMを実装している場合は、NPS1/2/4のどの構成も可能であるが、2〜10枚の場合はこの辺に多少制約が入る(Photo20〜22)。ちなみに1枚のみの構成も一応可能となっている(Photo23)。このあたりは構成の自由度を最大限に確保できるように工夫されている格好だ。実際のところ、例えば最大構成のEPYC 9654なら12CCDに対してDDR5が12chだから、CCDが1個あたりDDR5が1chというバランスになる。なので64core(8CCD)のEPYC 9554ならDDR5は8chでEPYC 8654と同じ帯域だし、32coreのEPYC 9354なら4chで同じ帯域になる訳で、あとは性能と価格のバランスで考えれば良いからだ。
ところで一つ気になるのはMemory Controllerそのものの性能である。と言うのは、Desktop向けのRyzenシリーズの場合、Memory Controllerの特性がDesktop向けに最適化され過ぎていたからだ。判りやすいのは、以前Ryzen 7000シリーズを試した際のRMMT Readの結果だろうか。これはWindows環境で、Threadあたり40MBのRead Requestを出し、その際のトータルのRead Bandwidthを計測するテストである。この際Ryzen 7000系のメモリ設定はDDR5-5200 CL44の2ch構成で、理論上のBandwidthは83.2GB/secになる。実際の性能はグラフからも示されるように、Ryzen 9 7950Xはピークで95.5GB/secを叩き出している。これは32MB×2のL3キャッシュにHitしている部分では当然帯域が増えるためでおかしくは無いのだが、おかしいのはこれが5 Thread動作時の性能であり、8 Threadでは67.7GB/secとかなり低めに推移していることだ。これはZen 3世代のRyzen 9 5950Xも同じである。DDR4-3200の2chなので理論帯域は51.2GB/secに対してピークは64.1GB/secと上回っているが、これは5 Threadの場合。8 Threadだと54.3GB/secと10GB/sec以上下回る値になっている。そもそもDesktopの場合、全てのThreadから同時にMemory Access Requestが出る事は非常に稀であり、むしろ全体のなかで少数のコア(というか、Thread)が集中してMemory Accessするようなパターンの方が多いだろう。恐らくRyzenのIODに搭載されたMemory Controllerはこうしたニーズに対応する様に設計されており、なので多数のCore/Threadから一斉にMemory Requestが殺到するような構成ではQueueが長くなるというか溢れる事になり、Core側のLoad Requestに対して迅速に反応ができなくなる(RequestへのAckを送らない事でFlow Controlを行っている)と思われる。実際Desktop向けに、膨大なI/O Request Queueを用意するのはリソースの観点から見ても無駄が多い。
ただこれはServer用途に向いた設計とは言えない。そこで、実際のところどうか？ というのをちょっと確認してみる事にした。実は今回AMDのLabに設置されたEPYC 9654の2 Socket Systemをリモートで利用する機会に恵まれた。生憎競合製品とかMilanベースのシステムとの比較を行う事は出来なかったし、リモート(設置場所は米テキサス州オースチンだったので、物理的に10000Km彼方である)ということでOSの入れ替えなどは不可能だったしアプリケーションのインストールも難しかったのだが、とりあえずメモリ帯域の測定の為にStreamを実施することが可能だったので、この結果をご紹介したい。
プラットフォームは先ほどPhoto17でご紹介したTitanite Boardで、ここにEPYC 9654×2と64GB DDR5-4800 RDIMM×24(合計容量1.5TB)が搭載されている。OSはLinux(Kernel 5.15.0-52-generic)がインストールされている状態だ。
ベンチマークだが、スタンダードなところでstreamを利用した。テスト方法だが、このstreamをOpenMP Enableな状態(gcc -O -fopenmpでコンパイル)にしたうえで、
同時実行スレッドを1〜384まで可変
streamのArray Size(テストに利用する配列数)を1億個〜13億個まで1億個ずつ増加(ArrayはDouble:8byteなので、アクセスするメモリ量としては76.3MB〜534.1MBになる(13億個までなのは、それ以上増やすとコンパイルエラーが起きるためである)。
という条件で実施し、その際のTriadのBandwidthをプロットしてみたのがグラフ3である。スレッド数が最大384といっても実際はメモリ共有をする関係で、最大構成(384 Thread/13億個)でも消費メモリ量は2.9GBに過ぎないので、1.5TBのシステムで確認するには十分である。
さて結果であるが、必要メモリ量が少ない範囲(1〜4億個)位までは結構L3キャッシュ(2 Socketで合計768MB)にHitする確率が高い(というか、3億個だと全体で686.6MBしか必要としないので、完全にL3でHitする)事もあってかなり広めの帯域になっているが、5億個以降ではL3が飽和する事もあり、実際にメモリアクセスが発生する事もあって、Thread数が増えるにつれて実効帯域が減ってゆく(それだけメモリアクセスの頻度が上がるため)。10〜13億個になると、もうL3の効果が殆ど無くなるので、ほぼ生のメモリアクセス性能が示されていると考えて良いかと思う。ちなみに1〜3億個で192 Threadの時に大きなギャップがあるのは、このタイミングで1 Socketの有効Thread数を使い切り、2 Socket目に移るためと考えられる。残念ながらStreamのOpenMPの実装は、2つのCPUを均等に使うのではなく、まず1つ目を使いつくしたら2つ目に移る感じになっているようだ。ただ同一CPUの中では、12個のコアを均等に使う様にスケジュールされている様に見える(96 Threadあたりから、24 Thread周期で三角波の様な傾向が示されているのがその傍証だ)。
まぁそうした特徴はともかくとして、384 Threadをフルに動かした際のBandwidthを見ると
といったところで、概ねこの640GB/secあたりがStreamを使った場合のピーク性能と考えて良さそうだ。理論帯域はDDR5-4800×12ch×2 Socketで921.6GB/secだから、効率は69.4%とかなり高い(通常streamだと60%程度になるのが普通)。また、RyzenのRMMTの時の様な、Thread数による変動もそれほど大きくない。なにより、3GBほどのアクセスを連続して行っても殆ど性能に変化が無い辺りは、Ryzenとは全く異なるメモリコントローラの実装になっていることの証明ともいえる。実は筆者、このメモリコントローラ周りの癖が一番気になっていただけに、ちょっと安心である。
ちなみに検証のために、Ryzen 7 7700XとRyzen 9 7950Xでも同じように実施してみた結果がグラフ4と5である。こちらはUbuntu Desktop 22.04(Kernel 5.15.0-58-generic)で実施している。メモリはDDR5-4800構成だ。Thread数はそれぞれの製品に合わせて最大16 Thread/32 Threadにしている。
こちらでも1億個だと76.3MBしか使わない関係でかなりL3が効果的に作用する関係でやや高い帯域を示すが、13億個あたりになると最早Ryzen 9 7950XでもL3が飽和するので、ほぼ地のメモリ帯域が示される格好だ。で、13億個の数字で言うと、
といったところで、どちらも理論帯域(DDR5-4800×2chで76.8GB/sec)の47〜48%程度の効率でしかない事を考えると、Genoaのメモリコントローラの効率が実に良い事が伺い知れる。ついでに言えば、グラフ4・5共に2 Threadの時にピークがあり、そこからじわじわと性能が下がってゆく、というあたりがRyzen 7000シリーズのIOD内蔵Memory Controllerの癖であり、これをRMMTだけでなくStreamでも確認できた格好だ。
●CXL DeepDive
○CXL
Memory Controllerのついでに、CXLについても触れておきたい。CXLはAccelerator及びAttached Memory向けのI/Fなので、別にAttached Memory専用という訳では無い。しかしながら、IntelがOptane Memoryのビジネスを収束させることを発表し、かつ3rd PartyのNVDIMMが不発というか全然盛り上がっていない現状で、大きく期待されているのがCXLを利用したAttached Memoryであるのは事実である。実際MicronはOptaneというか3D XPointのビジネスから撤退を発表した際のリリースの中で"Micron sees immense promise in new classes of memory-centric solutions that utilize CXL to scale the capacity, performance and content required by applications to run on infrastructure with greater architectural freedom."(Micronは、CXLを利用することで、アプリケーションに必要な容量、性能、コンテンツを拡張し、アーキテクチャの自由度が高いインフラストラクチャで実行する、新しいクラスのメモリ中心のソリューションに大きな可能性を見出している)と明言しており、非常に積極的である。
そもそもIn-Memory ComputingはこれまでIntelのOptane Persistent Memoryを中心にソフトウェアが開発されてきたこともあって、現状はXeonの独壇場である。ところがそのOptane Persistent Memoryそのものの先行きが無くなってしまった。とりあえずSapphire Rapids向けにはCrow Passとして開発されてきたOptane Persistent Memory 300シリーズがリリースされたが、こちらは容量512GB。Xeonの場合は8chのDIMMにこのOptane Persistent Memoryと通常のRDIMMを1枚づつ装着することで、chあたり768GB。8ch合計で6TBの容量が確保できるとしているが、Genoaはそもそも12chに2枚づつ256GB DIMMを装着すれば6TB容量になるわけで、もはやOptane Persistent Memoryのメリットは半減している(不揮発性、という部分に多少のメリットが残される程度)。しかもCXLで利用可能なSwitchを利用したMemory Poolみたいな事はOptane Persistent Memoryには不可能である。なのでこれまでOptane Persistent Memoryを前提に構築されていたIn-Memory Computing Applicationは、現在CXLベースへの移行作業を始めていると思われるが、これには相応の時間が掛かる。Optane Persistent Memory 300シリーズは、このアプリケーションの移行作業が完了するまでの間、既存のアプリケーションを使える様にするために提供されていると考えれば良いだろう。
さてそんなCXLであるが、AMDは割と意欲的であり、Genoaは、CXL 1.1+の機能が実装されている(Photo24)。"+"って何だ？ という話だが、GenoaはCXL 1.1に完全準拠した上で、CXL 2.0の一部の機能を先行して実装している。具体的にはCXL 2.0で追加されたRAS機能及びPersistent Memoryのサポートである。2.0で追加されたその他の機能、具体的にはCXL SwitchingとかMemory Pooling、Hot plug、QoS telemetry、eFLRなどの機能はまだ未実装である。もっともMemory PoolingとかSwitchはCPU側が対応しただけでは駄目で、SwitchやらPool用のApplianceの開発も必要になるから、現状はまだ時期尚早というのは判る。それよりもRAS機能とPersistent Memoryのサポートが早くも追加されたことで、DRAMだけでなくNAND FlashベースのSSDも接続が可能になったという事は大きい。先ほどPhysical Addressが52bitになった話の説明の中で、16TBのNAND SSDベースCXL Memoryを引き合いに出したが、実際にGenoaでは技術的にはこれが可能にである(Sapphire Rapidsは今のところDRAMベースのMemoryしかサポートしていない)。
もう一つ、Sapphire RapidsがサポートしておらずGenoaがサポートしている機能に、Lane Bifurcationがある。Photo16で、1つのGenoaのSocketからは4本のCXL Linkが出ているのが判るかと思うが、各々のLaneはx16になっている。Sapphire Rapidsも同じくx16構成のCXL Laneを4つ利用可能であり、対応するDeviceは4つである。例えばx4構成のCXL Memoryを装着した場合、残りのx12 Laneには何も装着できなくなる。これに対してGenoaの場合、x16 Laneをx8 Lane×2、あるいはx4 Lane×4に分割して、それぞれ別のCXL Memoryを接続する事が可能になっている。なので、x4 Lane Memoryなら最大16個装着できる格好だ。
ちなみにこの分割したLaneはInterleaveも可能になっている。x8 Lane×2の場合は64Bytes Boundaryで、x4 Lane×4の場合は256Bytes BoundaryでInterleaveが行われる格好だ。更に言えば、4つのCXL Link同士でも2-wayないし4-wayのInterleaveが可能であり、全体を一つのCXL Memoryブロックとして扱う事も出来るようになっている。
一方、これに装着できるCXL Deviceの方は？ というと、昨年5月にSamsungは512GB CXL DRAMのサンプル出荷を発表している(Photo25)し、Genoaの発表にあたっては多くのベンダーのプロトタイプが示された(Photo26)。
Astera Labs(Photo27,28)は実際にCXLの先にそれぞれ2chのDDR5 DIMMを装着して、ローカルのDDR5-4800と性能差が無い事をアピールした。実際PCIe Gen5 x16だからレーンの帯域は64GB/secになり、DDR5-4800の2ch(76.8GB/sec)にはやや届かない計算になるが、実際にはそこまでの帯域を使い切れないというのは先のStreamのベンチマークでも示された通り。Photo28の結果はnumactlを使ってベンチマークを行った場合のもので、別のNUMAノードとしてCXL経由でDDR5を利用できるとしている。
MicronはE3.sモジュールを通常のDIMMと混載する形で動作させ、帯域が1.43倍(PCIe Gen4)〜2倍(PCIe Gen5)に増えるというLive Demoを披露した(Photo29)。
もう少し凝ったLive Demoを披露したのはMicronである。先に書いたように現状のGenoaではまだMemory Poolingには未対応であるが、MarvellはこれをMemory Appliance側に実装する事で実質的にSwitchとMemory Poolを実現するという構成である(Photo30)。このMemory ApplianceはほぼEPYCの2Uサーバーと同じ程度のサイズである(Photo31)。これ一つで6つのMemory Deviceを構築できる予定らしいが、内部構造(Photo32)を見ていると2 Deviceにしか思えないあたりがちょっと謎である。Photo31は現在のテストシステムの構成、Photo32は将来の予定構成なのかもしれない。実際に、Marvellの提供するソフトウェアを利用してMemory Poolingが行える様子も示された(Photo33)。
CXLのエコシステムは、やっと商用プラットフォームが立ち上がったという段階なので、次にOSやミドルウェア、アプリケーションのベンダーがこれに対応するフェーズに入った訳で、CXLベースのIn-Memory Computingが本格的に立ち上がるのは2024〜2025年辺りになりそうではあるが、ただそうしたCXLの立ち上がりを牽引してゆくのはGenoaという事になるだろう。
勿論CXLのエコシステムはIntelを無視する訳では無いだろう。Sapphire Rapidsは、公式にはType 3(つまりCXL Memory Expansion)は未サポートであるが、プロトコルとしてはCXL.io/CXL.mem/CXL.cacheの3つを完全にサポートしており、Type 3に関しては「技術的には動作するが、検証プラットフォームが無い関係でValidationを行っていないので、サポートを表明していない」という扱いである。なので現実問題としては動作するだろうし、エコシステムでも対応や検証を行ってゆくだろうとは思うが、先に書いたようにRAS機能とかPersistent Memoryは今のところGenoaのみのサポートだし、Lane Bifurcationのサポートも無いので、ちょっと使い勝手は悪いだろう。なによりOptane Persistent Memory 300をサポートしている間は、公式にもCXL Memory Deviceをサポートするとは表明しにくいと考えられる。そうした意味でも、現状ではGenoaを利用してアプリケーションのCXL Memory対応を進めるのが賢明と考えられる。
●Application Performance DeepDive
○Application Performance
さて、Intelによれば(Photo14参照)、一番肝心のApplication Performanceである。これが意外に比較が難しい。例えばEnterprise&Cloudの分野でIntelが出しているPerformance Dataは例えばこんな具合(Photo34)で、2世代前(つまりCascade Lake-SP)世代のものとの比較である。あるいはMicroserverではDeath Star benchの結果が示されている(Photo35)が、こちらはGenoaでの実施例がまだ存在しないので比較できないといった具合。これはAI&MLの分野も同じで、こちらはAMDがまだGenoaでの具体的なTraining/Inference性能を公開していないからという理由もあるのだが、比較が出来ないでいる。
唯一比較が可能だったのがHPC向けのマーケット。こちらのスライド(Photo36)によれば、Ansys FluentでのSapphire Rapidsの性能は、Xeon Platinum 8380の1.6倍であるとされている。一方でGenoaは、やはりXeon Platinum 8380と比較して2.5倍程度の性能であるとしている(Photo37)。AMD/Intel共に絶対的なスコアは示していないので、これで検証というのも難しいが、AMDのPerformance Numberの公開サイトではスコアも示されており、(Ansys Fluent 2022R2ではあるが)
といった数字を拾う事が出来る。ちなみにAnsys自身での測定結果で、GenoaはMilan比で29%〜70%と結構高速化しているとされており(Photo38)、恐らく1〜2 Socket構成で考える限りにおいてはGenoaの方が高速と考えて良いだろう。
もう少し公開データで、しかも実アプリケーションに近いものは？ ということで、グラフ6はSPECjbb-2015の公開データから、Genoa及びSapphire Rapidsの結果を拾ったものである。Genoaは2022年Q4、Sapphire Rapidsは2023年Q1からPickupしている(どちらも2 Socketの構成のみ)。横軸はmax-jOPS、縦軸はcritical-jOPSで、どちらも数字が高いほど性能が高い。max-iOPSの方は文字通りピークのjava Operation性能、critical-jOPSの方はSLAが10000μs/25000μs/50000μs/750000μs/100000μsの場合の幾何平均で、まぁ実効性能に近い。で、当然システム構成によって多少のばらつきはある訳だが、全体的に言ってGenoaはSapphire Rapidsの2倍近いjOPSを叩き出している。maxの方は概ね2倍だが、criticalの方はそこまでいかず1.7倍程度であるが、どちらにしても圧倒的な性能差である。気になるのは、Xeon Platinum 8490Hがmax-jOPSが高い割にcritical-jOPSが低めな事である。むしろXeon Platinum 8480+の方がバランスが良い感じだが、いずれにしても性能に大差がついている事そのものに違いはない。
同様にSPEChpcの結果だが、こちらはまだ公開されている数が少ないので、表形式で。
どちらもOpenMPを使った結果での比較である。ちなみにSPEChpcはテストで利用するデータセットのサイズでTiny/Small/Medium/Largeの4つがあるが、Medium/Largeは今のところ公開データが0なので比較対象となっていない。ちなみに条件で言えば、xFusionの2288H V7は1TB Memory、Lenovo ThinkSystem SR665 V3は768GB Memoryなので、どちらかと言えばXeon Platinum 8490Hが有利な筈だが、Tiny/Small程度のデータセットではメモリをそこまで使わないから差が出ないものと思われる。
同様にベンチマーク結果が公開されているものとしてはTPCがあるが、こちらは現状Genoaについては幾つか公開されているものの、Sapphire Rapidsに関しては結果が全く登録されていない。TPCはいずれも実施に結構な時間とコストが掛かるだけに、登録されるまでにはもう少し時間を要するものと思われる。
これ以外にベンチマークは？ というと、phoronixが今年1月10日に、Intel Xeon Platinum 8490H "Sapphire Rapids" Performance Benchmarksを公開している。こちらは
AMD：EPYC 7713/EPYC 7763/EPYC 7773X/EPYC 9374F/EPYC 9554/EPYC 9654
Intel：Xeon Platinum 8362/Xeon Platinum 8380/Xeon Platinum 8490H
の合計9種類の構成で多数のテストを実施している(流石に結果をここで転載するのは問題があるので、興味ある方はphoronixの記事を参照してほしい)。こちらでも、Genoaのスコアがかなり良好であることが示されている。
●考察 - Genoaの真実、Sapphire Rapidsとは異なる方向性
○考察
ということで4パートに分けてGenoaの特徴をご紹介してきた。競合となるのはSapphire Rapidsこと第4世代Xeon Scalable(とXeon MAX)ということになるが、そもそも最大でも$11,000(EPYC 9654)であり、$17,000のSapphire Rapids(Xeon Platinum 8490H)とは比較にならない。消費電力は定格で360W(EPYC 9654)と350W(Xeon Platinum 8490H)だから同程度というかややGenoaが高い様に見えるが、EPYC 9654が96コアとXeon Platinum 8490Hより60%もコア数が多く、しかも動作周波数もやや高めという事を考えると、性能/消費電力比ではGenoaの方に軍配が上がる事になる。
Sapphire Rapidsのメリットは様々なアクセラレータを搭載している事と、4/8 Socketまでの拡張が可能な事で、Genoaを選ぶかSapphire Rapidsを選ぶか？ という選択の際の基準は、こうしたSapphire Rapidsのメリットが自身のニーズに合致しているか否か、というあたりになりそうだ。
EPYCも第4世代になり、熟成が進んだ感がある。Xeon Scalableも奇しくも第4世代な訳だが、基本性能を高めるか、重厚なアクセラレータを搭載するか、という方向性の違いが浮き彫りになった気もしなくはない。どちらが正解というものでもないのだろうが、さてユーザーニーズに応えやすいのはどちらであろうか？
