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

Zen 4世代EpycはHBMを搭載する？

AMD Reportedly Planning Zen 4 EPYC Genoa CPUs With HBM Memory - WCCF Tech

　Zen 4世代EpycはHBMを搭載するというウワサがあるらしい。
　もちろん製品が発表されるまで真偽は不明だが、もし現在の基本的なアーキテクチャーが維持されると仮定した場合、HBMが採用される可能性は非常に低いと推測する。理由はHBMの広大な帯域を活かすことが難しいからである。

　Intel Core/Xeonと違いAMD ZenファミリーのアーキテクチャーはHBMによる効率化が難しい。
　その理由はCPUコア⇔メモリー間のバスであるScalable Data Fabric（SDF）の帯域がDDR系メモリー動作周波数に同期しており帯域も2チャンネル分の帯域に合うように設定されているからである。DDR4-3200の場合では帯域は25.6 GB/s/chで2チャンネルで51.2 GB/sとなるがSDFの帯域も51.2 GB/sに設定されている。つまりメモリー間の通信は51.2 GB/sでバランスがとれるよう設定されている。
[CCX]←(SDF 51.2 GB/s)→[UMC]←(25.6 GB/s x 2 ch)→DDR4メモリー
　もし仮に、現在のEpycのDDR4メモリーをHBM2E（1スタックあたり307 GB/s。4スタックと仮定して1228 GB/s）に入れ替えた場合SDFがボトルネックとなり性能は向上しない。
[CCX]←(SDF 51.2 GB/s)→[UMC]←(307 GB/s)→HBM2Eメモリー
　従って、DDR4/DDR5系メモリーをHBM系メモリーに置き換えたければ、現行のInfinity Fabricの帯域やあるいはメモリートポロジーを大幅に変更する必要がある。

　なぜ、そのような大幅な変更が必要になるのか？端的に言えばInfinity Fabricの設計思想とHBM系メモリーの利用が相反するからではないかと思う。
　ZenアーキテクチャーではRyzenからEpycまで1 CCDまたは2 CCDで2 chメモリー帯域を共有して釣り合うようにメモリートポロジーが設計されている。Ryzenの下位モデルでは1 CCD + cIODの構成で2chメモリー・上位モデルでは2 CCD + cIODの構成で2chメモリーとなっているし、Epycでも下位モデルでは4 CCD + sIODの構成で8chメモリー・上位モデルでは8 CCD + sIODの構成で8chメモリーとなっている。
　例えば現行のEpycでもDDR4 8チャンネル、DDR4-3200と仮定し512-bit幅・204.8 GB/sもの帯域をもつことになる。ところが、Epycの特定のCPUコアに着目してみると204.8 GB/sは使えないことが解る。上述の通りCCD - sIODを接続するIFOPの帯域は51.2 GB/sに設定されているからである。もしかすると瞬間的に8チャンネルすべてを1コアのワークロードが占有することもあるかもしれないが、通常は最大2チャンネル分＝51.2 GB/sしか使用することはできない。
　Epycで現行のメモリートポロジーに大きな変更を加えることなく帯域を増やしたければ、まずEpycのSDFの帯域を2チャンネルではなく8チャンネルに合わせることが先だろう。

　ちなみに、Intel Core/Xeonの場合ではCPUコアはメモリーコントローラーと広帯域のオンチップファブリックで接続されるためHBM系メモリーの統合は難しくない。例えばSkylake-SP世代Xeon Scalableの場合オンチップネットワークの帯域は～768 GB/sで、メモリーコントローラーは2基（各3チャンネルで計6チャンネル）搭載されているから、HBM系メモリーに単純に置き換えるだけで最大1536 GB/sの帯域は確保できる。

　もしHBMを使う前提で、Zenファミリーのアーキテクチャーを変更するとすればSDFをバス幅を広げたり動作周波数を向上させて帯域を大幅に引き上げるか、メモリー周りのトポロジーを大幅に変更する必要があるが、現在のDDR4メモリーをHBM2Eメモリーに単純に置き換えsIODに接続することは考え難い。
　まず、CCDとcIOD/sIODを接続するオンチップのSDFやChiplet間を接続するInfinity Fabric on Package（IFOP）も帯域を引き上げる必要がある。SDFにはオンチップ/オンパッケージ/インターソケットの3種類の物理実装があるが帯域は揃えられている。DDR4→DDR5のような最大2倍程度の帯域向上は動作周波数の向上などで達成可能だろうがDDR4→HBM2Eで12～24倍もの帯域向上となると話は違ってくる。そして、動作周波数を大幅に引き上げると電力効率が悪化する可能性がある。現在のMulti-Chip Moduleでは1 pJ/bitが指標となっており、Zen/Zen+世代では2 pJ/bitだったことが発表されているが（参考）、これがさらに悪化する可能性がある。
　SDFに変更が入る場合、デスクトップ製品への影響も考慮する必要がある。Zenファミリーではデスクトップ用＝Ryzenとサーバー用＝Epycでチップレット＝CCDを共通化することで低コスト化とスケーラビリティーを確保しているわけで、HPCのような特定用途向けの変更をCCDに取り込むことは容易ではない可能性がある。

　比較的実現の可能性が高そうなのがCCDに直接接続してキャッシュとして利用する場合だが…これは先日発表された3D V-Cacheと真っ向から対立するため、筆者にはAMDの構想と矛盾しているように感じられる。

　3D V-Cacheを利用した場合とHBMをCCDに接続するキャッシュとした場合とでは相互に利点と欠点が考えられる。
　3D V-Cacheの欠点としてはAMD独自のダイとなるため生産数が少なければコストが高くなる可能性があり、またSRAMベースのため容量もHBM比では小さくなる。代わりに利点としてはSRAMベースのため遅延で有利だし、既存のL3キャッシュをスタッキングするだけだからバスを引き廻したりコントローラーを配置するなど現行のメモリートポロジーに一切の変更の必要も無くコアとの統合の面で有利である。
　HBM系メモリーはDDR系メモリーと比較すれば広帯域だがキャッシュとして見た場合に広帯域かといえば疑問が残る。HBM2Eはスタックあたり最大307 GB/sだが、Zen 2/Zen 3のL3キャッシュは32 B/cycle/coreで4 GHz時に128 GB/s/core、つまり8コア/CCDとすると1024 GB/s/CCDとなる。多少遅延が大きくても大容量・広帯域のキャッシュが必要な場合はHBM系メモリーも考えられるが3D V-Cacheと比較すると性能面での不利は否めないだろう。

　筆者にはそもそも3D V-Cacheの開発とHBM系メモリーへの対応は矛盾しているように感じられる。
　HBM系メモリーの最初の規格＝HBMの登場は2013年のことで、3D V-Cacheが発表された今年6月より遥か以前で、もしAMDがキャッシュとしてHBM系メモリーの搭載を計画しているのであれば3D V-Cacheの開発や製品化などそもそも必要が無いためである。

IntelがGlobalFoundriesを300億ドルで買収を計画中？

Intel in Talks To Buy GlobalFoundries for $30 Billion: Report - Tom's Hardware
Intelがファウンドリ事業拡大のためGFの買収を画策か？ - マイナビ

　最先端プロセスという観点ではGlobalFoundriesは見るべきものがない。しかし、そもそもPC/スマートフォン用以外では最先端プロセスは必要無く別の要件がある場面が多い。IntelがIDM2.0と呼ぶIntel Foundryビジネスで既存のIntel製品の需要とは異なる需要に対応するには、案外悪くない選択肢かもしれない。

　例えばルネサスは今年2月のISSCCでハイエンド車載SoC「R-Car V3U」を発表したが製造プロセスはTSMC 12nmで、これはルネサスに限った話では無い。
　組込半導体では製品寿命が長い（例：10年超の長期供給保証）からファウンドリーのLong Liveノードである必要があるし、長期供給なのだから最先端に拘ることは大きな意味も無い（どうせ4～5年後には最先端ではない）し、用途によっては高電圧のI/Oを扱う必要があるから先端の超微細プロセスは対応していない場合もある。あるいはコストに対するの要件が強くTSMC N7・N5など最先端で効果なプロセスは利用が困難な場合もある。
　こういった需要は現行のIntel製品ではあまり対応の必要が無かったように思われるが、IDM2.0で多種多様な半導体の製造を受注したければ、そういう需要に対応できるプロセスノードが必要になる。

　また、IntelとIBMが協業を考えているとすれば、IBMから工場・特許など知的財産・開発チームを引き継いだGlobalFoundriesは魅力かもしれない。また、IntelがGlobalFoundriesを買収した場合はIBMもGlobalFoundries相手の訴訟を取り下げるかもしれない。

　IntelがGlobalFoundries買収に提案中という300億ドルという投資額は一般人からすれば膨大な額には違いないが製造設備や製造技術の額としては高価ではない。
　例えばIntelは製造能力の増強に膨大な投資をしておりアリゾナ州に200億ドルでファブの建設を発表している。このアリゾナ州の新工場の性能は不明だが、TSMCが同じくアリゾナ州に120億ドルでファブを建設予定でこちらは20,000ウェハー/月とされているので、それをやや上回ることだろう。これに対しGlobalFoundriesの製造工場はニューヨーク州マルタのFab 8が60,000ウェハー/月、AMDから引き継いだドイツ ドレスデンのFab 1が66,000ウェハー/月である。
　もちろんIntelのアリゾナ新工場（3nm？）とGlobalFoundriesの旧式工場（Fab 8は～12/14nm、Fab 1は～22nm）とではプロセスが違うし、そもそも最先端プロセスではマルチパターニングなどによりスループットが低くなる傾向があるため単純比較することは無理があるが、それを差し引いても新たに工場を建設し、新規顧客を開拓することを考えれば安上がりと言えなくもないかもしれない。

GPD WIN Max (5) GPD WIN Max 2021, Steam Deck

GPD WIN Max 2021

Ryzen搭載8型「GPD WIN 2021」の価格が決定 - PC Watch

　WIN Max (2020)に後継機として今年5月にWIN Max 2021がリリースされることが発表されたが、同時にWIN Max (2020)購入者はメインボードを換装することでWIN Max 2021相当にアップグレード可能であることが発表されていた。今回、そのWIN Max 2021および換装用のメインボードのIndieGoGoでの価格が発表された。
　WIN Max 2021にはIntel Core i7 1165G7/1185G7・AMD Ryzen 7 4800Uの3種類が存在するが、Core i7-1165G7・Ryzen 7 4800UがUS$999、Core i7-1185G7がUS$1400、換装用基板（Core i7-1165G7・Ryzen 7 4800U）はUS$669とのことである。

　個人的な率直な意見としては微妙な価格設定だと思う。
　そもそもWIN Max (2020)はIntel "Ice Lake" Core i5搭載でIndieGoGoでの価格はUS$780だったので、WIN Max 2021のCore i7-1165G7/Ryzen 7 4800Uの換装用基板US$669・システム全体US$999というのは相対的に高めの価格設定である。
　新規ユーザーならばUS$999で用途に合わせてGPU性能重視＝Core i7-1165G7またはCPUマルチスレッド性能重視＝Ryzen 7 4800Uから選択することになると思うが、筆者のような既存WIN Max (2020)ユーザーの場合は換装用基板を買うぐらいなら+$230で本体を丸ごと買い替えた方が割安かもしれない。

Steam Deckという選択肢

　ここで個人的に気になるのは、奇しくも時期を同じくして発表されたValve Steam Deckである。Steam Deckには64GB/256GB/512GB版が存在し、それぞれ$399/$529/$649である。
　注目すべきは価格設定であろう。既存WIN Max (2020)ユーザーとしては基板を換装するよりも安価に買えてしまうわけで、用途によってはWIN Max 2021への乗り換えではなくSteam Deckを買うという選択肢も考えられる。

　もちろん、Steam DeckはWIN Max 2021に対してははCPUもGPUも見劣りしてしまうが、重量でも恐らくバッテリー持続時間でもSteam Deckの方が優れているし、特にWIN Max (2020)に対してはiGPUも上回っているので、既存WIN Maxユーザーとしては基板換装も1つの選択肢ではあるがSteam Deckに乗り換えというのも1つの選択肢であろう。

	GPD WIN Max (2020)	GPD WIN Max 2021		Valve Steam Deck
CPU	Intel Sunny Cove x4 1.2 GHz (Base) 3.7 GHz (Turbo)	Intel Willow Cove x4 3.0 GHz (Base) 4.8 GHz (Turbo)	AMD Zen 2 x8 1.8 GHz (Base) 4.2 GHz (Turbo)	AMD Zen 2 x4 2.4 GHz (Base) 3.5 GHz (Turbo)
GPU	Intel Gen11 1075 GFLOPS	Intel Xe LP 2073 GFLOPS	AMD Vega 8 1792 GFLOPS	AMD Navi2 1600 GFLOPS
Memory	LPDDR4-3200 51.2 GB/sec 16 GB	LPDDR4X-4266 68.2 GB/sec 16 GB		LPDDR5-5500 88.0 GB/sec (?) 16 GB
Display	8-inch 1280 x 800			7-inch 1280 x 800
Battery	57 Wh			40 Wh
Dimensions	207 x 145 x 26 mm			298 x 117 x 49 mm
Weight	790 g	790 g (?)		669 g

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

産総研のABCIアップグレード

Inside Look Inside Japan’s ABCI AI Supercomputer Upgrade - The Next Platform
産総研のABCIスパコンが大幅アップグレード - マイナビ

　この話題はマイナビなどでは5月に既報のもので概ね同様の内容がThe Next Platformでも報じられたので取り上げてみる。

　内容としてはNVIDIA V100ベースのCompute Node (V)で構成された既存のABCI 1.0にNVIDIA A100ベースのCompute Node (A)を追加するというものである。Compute Node (A)は単にV100からA100への換装という感じのものではなくNVSwitchを用いて1ノードあたりのGPU数を倍増（4 GPUs→8 GPUs）したもので、従って1ノードあたりの演算性能も4.6～5倍に向上している（※データ精度による）。
　ただし、ABCI 1.0はCompute Node (V) x 1088ノードで構成されたのに対しABCI 2.0で追加されるのはCompute Node (A) x 120ノード（つまり+10％）だから、1ノードあたりの演算性能が大幅に向上しているとはいえ全体で何倍にも高速化しているか？といえばそれほどでもない。むしろ、V100→A100ではTensorCoreの強化によるDeep Learningでの性能向上幅が大きい（参考1、参考2、参考3）からCUDA CoreによるFP64の性能向上よりもTensorCoreによるFP16/FP32やSparsityでの圧縮による性能向上幅が大きい。

	ABCI 1.0	ABCI 2.0		Improvements
		Expansion	Overall
# of nodes	1088	120	1208	x1.11
	Traditional HPC
FP64 (per node)	34 TF	156 TF	-	x4.6
FP64 (entire system)	37.2 PF	19.3 PF	56.5 PF	x1.52
	Deep Learning (AI)
FP32 (per node)	68 TF	1260 TF	-	x18
FP32 (entire system)	75 PF	150 PF	225 PF	x3
FP16 w Sparsity (per node)	500 TF	5000 TF	-	x10
FP16 w Sparsity (entire system)	550 PF	600 PF	1.15 PF	x2.09

　古典的なFP64主体のHPCとしては＋50％ほどしか性能向上していないが、Deep Learningの学習（FP32）で3倍・推論（FP16）で2倍もの性能向上を達成していることになる。ABCI = AI Bridging Cloud InfrastructureはAI研究開発のために設置されたHPCだから、そのコンセプトと今回の増強の方向性としては正しいのだろう。

Compute Node (A)はData Centric構成

　個人的に気になるのはCompute Node (A)の構成である。
　第3世代Xeon Scalable "Ice Lake-SP" 2ソケットにNVIDIA A100を接続し、A100同士をNVSwitchで相互接続した構成であるが、Xeon SPの標準のPCIeレーン数（2ソケットで計128レーン）では足らず旧PLX（現Broadcom）製PCIe Switchを4基搭載している。各ソケットあたりA100 x 4（PCIe x16 x4）・InfiniBand HDR x 2（PCIe x16 x2）・NVMe x 1（PCIe x4 x1）が接続され1ノード全体では計PCIe 200レーン（1ソケットあたり100レーン）が必要なためである。
　Compute Node (A)の構成はNVIDIA純正のDGX A100と酷似しているが、DGX A100で採用されているAMD Epycの場合でも2ソケットで計160レーンを確保できるがそれでも不足で、やはりPCIe Switch 4基を搭載している 。

　PCIe Switchを搭載するもう一つの理由はGPUからNICを直接制御するためだろう。
　InfiniBand＝Mellanox ConnectX-6をCPU側ではなくPCIe Switch側＝GPUクラスター側に、それも2 GPUあたり1 NICの割合で接続していることからしてもMellanox SHARP/GPU Direct（参考1、参考2）によるノードを跨いだ（CPUを介さない）GPU同士での直接的な通信を意図していることが解る構成となっている。

Data Centric構成の先に見えるNVIDIA "Grace", "Atlan"

　このような構成だとNVIDIAが"Grace"や"Atlan"を構想するのもよく解る。
　GPUとInfiniBandを中心として構成されたノードはGPUを使った演算は高速になるが、CPUがボトルネックとなってしまうし、NVIDIA視点ではPCIe Switchが無駄に見えるからである。
　一度GPUにコードやデータを取り込んでしまえばGPU間のみで演算も通信もできてしまうが、ファイルシステムにアクセスするにはOS・CPUを経由することになるし、CPU側メモリーのデータは細いPCIe（4 GPUあたり僅かPCIe x16）でのアクセスとなってしまう。

　ここで、例えばCPU側にGPUとNICを接続するのに十分なインターフェース（例：計200レーン分のPCI Switch）があればPCIe Switchを外付で載せる必要が無くなるし、そもそもPCIeではなくNVLinkで接続できるのであればCPU側メモリーへのアクセスも高速になると考えれば、それはNVIDIA "Grace"そのものだ。また、さらに踏み込んでCPU・GPU・NICをSoCに統合してしまうことを考えるならば、それはNVIDIA "Atlan"そのものである。
　サーバーやHPCの場合はCPU:GPUのバランスがワークロードによって異なるためCPU・GPU・NICをディスクリートでNVLinkで相互接続される方が選択肢を広げることになるだろうが、ある程度ワークロードがある程度決まっている（例：自動運転）場合はSoCにしてしまった方が効率が良い。

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

3期連続スパコン世界一「富岳」の成果

3期連続スパコン世界一「富岳」の成果 - PC Watch

　HPCのランキングであるTop500は毎年6月と11月に発表されているが、2021年6月のランキングで「富岳」が四冠を3期連続で達成したそうである。
　PC Watchの記事では話題となった新型コロナウィルスのシミュレーションをはじめとする「富岳」の成果について説明されており興味深い。

　ただ、これを見ていて思うのは、それならば、やはり2台構築して交互に更新するようにすべきなのではないか？という点である。
　語弊ある表現だが、「富岳」にとって新型コロナウィルスの流行はタイミングが良かった。先代「京」は2011年に運用が始まりTop500のトップに立ったが2019年6月には20位にまで後退、その後「富岳」への更新にあたり2019年8月に撤去されており、2020年6月頃に「富岳」の稼働が始まるまでの約1年間に渡り空白期間が開いている。言い換えると新型コロナウイルスの流行が1～2年間ほど前にズレていた場合、「京」や非国産のHPCでシミュレーションすることになったことだろう。

　米国の場合、Oak Ridge National Laboratories（ORNL）を例にとっても、「Titan」が2011年後半～2019年前半・「Summit」が2018年6月～・「Frontier」が2022年～と、2台が交代で更新されており、ORNLの研究者は常にTop500 5位以上のシステムを使い続けることができている。

Windows 11のCPU要件で対応/非対応の境界線を決めたものは？

Windows 11はなぜTPMが必要で、CPU制限が厳しいのか? その理由を詳しく説明 - PC Watch
Windows 11にアップグレード可能なCPUは基本はやっぱり第8世代／Zen+以降になりそう？ - ASCII

　PC Watchの記事はMicrosoftが公開したブログ記事を解説したもので基本的にMicrosoftの説明に準じているのだが、ASCIIの記事の信憑性はどうなのだろうか？

　PC Watchの記事の方は、さすがMicrosoftが説明した内容を基にしているだけあり興味深い。VBS/HVCIを利用するために必要という説明である。
　簡単に言えば、Hyper-VのRoot Partition（XenでいうDom0）でVSM（Virtual Secure Module）というセキュアな環境を動作させ・通常のWindowsはChild Partition（またはXenでいうDomU）で動かすことで分離し、マルウェアの攻撃を回避することができる（※Hyper-VとXenのアーキテクチャーは類似している）。
　このVBS/HVCIを実用的に利用するためにSLAT（Second Level Address Translation）拡張命令が必要で、SLATに対応しているのが第8世代Intel Core・第2世代AMD Zenだという説明である。

　もう一方のASCIIの説明であるが…
　記事で主張されている内容は理解できるものの、筆者は第8世代Intel Core = "Coffee Lake" "Kaby Lake Refresh"でRetpolineが不要になったという話を聞いたことが無いため記事の内容には疑問が残る。

　Meltdown/Spectreは2017年後半にGoogle Project ZeroによってIntelなどの関係者に通知され、2018年1月4日にニュースメディアによって報じられたCPU脆弱性であるが、理解を難しくしているのは、後に発見された類似の脆弱性がSpectreNGなどの類似の名称で発表されていることと、ハードウェア側の対策も段階的に取り込まれており3年経った今も対策が続いている点ではないかと思う。

　Meltdown/Spectre関連の脆弱性（Vulnerability）と緩和策（Mitigation）のCPUモデル毎の対応状況についてはIntelが表に纏めている。Rocket Lakeなど最近のモデルではハードウェア側に緩和策が盛り込まれていたり、そもそも脆弱性の対象で無かったりというIntel側の対応が確認できるが、実は第6世代Core=Skylakeと第8世代Core=Coffee Lake/Kaby Lake Refreshとを比較した場合、この表の大雑把な詳細度で言えば脆弱性の対応状況はまったく同じであることが解る。
　また、Intelは2018年6月にRetpolineに関する資料をリリースしているがMicrocodeの変更（緩和策のひとつ）で動作が変わるCPUモデル名が記載されているが、Family 06H Model 4EH～67Hに加え8EH（Kaby Lake Refresh・Amber Lake・Whisky Lake）・9EH（Coffee Lake）が記載されている。

　個人的にはPC Watchの記事は納得できる内容だったが、ASCIIの記事は疑問が残る内容だった。