最近の気になった話題（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の記事は疑問が残る内容だった。

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

AMD Ryzen Embedded V3000はRembrandtがベース？

AMD Ryzen Embedded V3000 SoCs Based on 6nm Node, Zen 3 Microarchitecture -  techPowerUp!

　Zen3世代Ryzen Embeddedのウワサが報じられている。ウワサによると"Cezannne"系ではなく今年後半に登場予定の"Rembrandt"系になるのだという。

• 最大8 Cores / 16 Threads
• PCIe 4.0 20レーンレーン（dGPU用はx8）
• DDR5-4800 4ch（ECC対応）
• 10G Ethernet x2
• USB 4.0 x2
• TDP 15-30 Wと35-54 Wのモデルがある
• iGPUはRDNA2 12 CUs

　Zen3 CPUコアとRDNA2 GPUの組み合わせなどは"Rembrandt"のスペックとして以前から報じられていた通りであるが、一部で組込用に仕様が変更されている。
　具体的にはメモリーのECC対応・10GbE x2といったあたりで、Zenファミリー登場当初からRyzen Embedded・Epyc EmbeddedではCOM Express仕様を強く意識した仕様となっている。

　まず、DDR5メモリーのECC対応は以前のモデルからRyzen APUではECC非対応・Ryzen EmbeddedではECC対応で一貫している。ちなみに4chとされているのはDDR5では1DIMMモジュールでx32×2chとなるからで、特におかしな仕様ではない。

　10GbE対応という点は意外に思われるかもしれないず、ネット上でも混乱が見られるが、過去のRyzen Embedded・Epyc Embeddedでも10GBASE-KRに対応製品があり、COM Express対応のためにも重要な機能である。
　10GBASE-KRはPCB（基板）上でのバックプレーン接続を目的としたEthernet規格で、RJ-45などのコネクターで外部と接続することを目的としていない。組込では例えばCiscoなどのエンタープライズ/データセンター用Ethernet Switchなどでスイッチチップー管理用CPUとの接続に用いられる。

　個人的に気になるのは、Ryzen EmbeddedよりもむしろZen世代のように2 chiplet構成でEpyc Embeddedが展開されるか否かの方である。
　COM Express Type-7では10GBASE-KR x 4が含まれており、Zen/Zen+ではZeppelin chipletに10GBASE-KR MACが2基搭載され、Zeppelin x 2の構成で10GBASE-KR x 4を実現していた。しかし、Zen2世代ではRyzen APU "Renoir"がRyzen Embedded V2000として投入されたもののEpyc Embeddedは投入されなかった。"Renoir"ではCOM Express Type-7を満たすにはI/Oが明らかに不足しており、例えば10GBASE-KRに限って言えばPCIe接続でコントローラーを追加することも可能だが、それではPCIeレーン数の規定を満たせないため当然とも言える。
　その点、"Rembrandt"の仕様であれば2 chiplet構成にできればCOM Express Type-7の仕様を満たせそうに見える。ただし、過去のAMD APU製品は複数chiplet構成をサポートしてこなかったため、その辺りがポイントとなりそうだ。

	COM Express Types		AMD Embedded Processor family
			Zen/Zen+		Zen2	Zen3
Type	COM Express Type-6	COM Express Type-7	Ryzen Embedded V1000	Epyc Embedded 3000	Ryzen Embedded V2000	Ryzen Embedded V3000
DRAM	-		DDR4-3200 ECC	DDR4-3200 ECC	DDR4-3200 ECC	DDR5-4800 ECC
PCIe lanes	24	32	upto 16 lanes	upto 32	upto 20	upto 20
SATA	4	2	upto 2	upto 8	2	?
10GbE	0	4	upto 2	upto 4	-	upto 2
1GbE	1	1	upto 2	upto 4(?)	-	?
USB4.0	-	-	-	-	-	4
USB3.1 Gen2	-	-	-	-	4
USB3.0/3.1 Gen1	4	4	4	4
USB2.0	8	4	1(?)	0	4	4?
Video	LVDS A&B	0	LVDS	0	DP-Alt, LVDS	?

ところでウワサの出所によると「two 10G ethernet PHYs」という記載になっているようだが、厳密にどういう意味なのか判然としない。

　まず、昨今のEthernetでいう「PHY」とは昔からあるOSI参照モデルでの物理層＝PHYという意味と、MACコントローラーチップから物理層に接続するシリアルインターフェース（OSI参照モデルでいうとデータリンク層と物理層の間のインターフェース）のSerDes PHYの2種類がある。
　例えば上述の10GBASE-KRはOSI参照モデルでいう物理層は実装されないが、SerDesのPHYは搭載されシリアル信号でバックプレーン接続されるし、昨今のPCIeやAMD Infinity FabricなどはEthernet/InfiniBandで培われたSerDesを応用しているから（参考）、昨今のマイクロプロセッサーはEthernet MAC層の搭載数や搭載有無に関わらず膨大な量のEthernet PHY（SerDes）を搭載している。例えばZen/Zen+ Zeppelin chipletは上述の通り10GBASE-KR MAC層を2基搭載していたが、搭載されていたSynopsys Enterprise 12G Ethernet PHYは計32レーンである。

　筆者が想像するに「two 10G ethernet PHYs」のPHYとはシリアルインターフェースのSerDesのことと推測する。
　そもそも、組込SoCで管理用の低速Ethernet（例：1000BASE-T）を除きMAC層と物理層を統合することは好ましくない。上述の通り10GBASE-KRのように物理層を実装しない規格もあるし銅撚線ケーブルを使った10GBASE-Tや光ファイバーを使った10GBASE-ERなどで物理層が異なるため、組込SoCの用途を制限してしまうからである。

MicrosoftがWindows 11を発表

Windows 11発表。年内提供予定でWindows 10からは無償アップグレード - PC Watch

※本稿は6月24日に公開した記事に加筆・修正を行ったものです

概要

　MicrosoftがWindows 10 21H2あるいはコードネーム"Sun Valley"として開発してきたWindowsが、2015年に発表されていた「Windows 10が最後のメジャーバージョン」という前言を撤回して「Windows 11」となることが発表されたのは各メディアが報じた通り。

• 21H2 "Sun Valley"と呼ばれてきた新バージョンWindowsはWindows 11に
• Windows 10から無償アップグレード可能
• ハードウェア要件が変更
• 6カ月毎の機能アップデートは1年毎に変更（参考）

アップデート方式

　個人的に最も気に入らないのが年1回への機能アップデートの変更だ。
　MicrosoftはWindows 10のリリースでAgile型の開発とWindows-as-a-Serviceというコンセプトを導入したが、後退したように見える。

　ネットを見ていると6カ月毎から1年毎への変更は好意的な感想が多いが、それは、そもそも現行のMicrosoftのやり方が悪いからであって6カ月毎の変更が悪いわけではない。
　例えばGoogle Chromeは現在約6週間毎でアップデートされており、さらに約4週刊毎に加速する計画を発表しているし、Linux Kernelは2～3カ月（約10週間）で新バージョンをリリースし続けているし、Ubuntuは6カ月毎のリリースを2004年10月から続けているが、これらのプロジェクトが開発サイクルで批難の対象となったことは無い。Chrome・Linux Kernel・Ubuntu・Windowsはそれぞれ異なる背景や機能やプロジェクト規模を持つから、一概にN週間が適切と言うつもりは無いが、1年間という期間が妥当でない/後退であることは間違い無い。

　そもそもAgile型の開発は一言で言えば「カイゼン」である。
　例えば20世紀に主流だったWaterfall型に代表される古典的な開発方式での教訓（製品開発に長期間を要し、完成した製品がユーザーの希望から大きく乖離している）を踏まえ、実装→テスト→リリース→フィードバック（計画、要求分析）のサイクルを短く（例：1～4週間）とり、それを反復することで開発の失敗を防ぐことを目的としている。より厳密に言えば開発した一部の新機能が失敗することはあるのかもしれないが、数週間の短期間で失敗を検出して軌道修正することができ、プロジェクト全体としての失敗を防止できる。

　MicrosoftはAgile型開発に移行しInsider Previewをほぼ毎週リリースしている（ということになっている）が、どうもWaterfall型開発的な考え方から抜け出せていない感じがする。というのも、Microsoftは2019年末頃から極秘裏に内部でWindows 11を開発し続けており（※）、6月24日現在で最新のInsider PreviewはWindows 11のプレビュー版ではないことが明らかになったからだ。Windows Vista/8/8.1の時もそうだったが、Microsoftが「改良」と考え年単位を費やして開発し満を持してリリースした機能やUIがユーザーから批難の大合唱で迎えられたことは一度や二度ではない。

※2019年12月に、後に"Sun Valley"・Windows 11と呼ばれる開発ブランチ（build 19536～）がWindows 10（Windows 10 19H2 build 18363～20H1 build 19043）から分岐して独立して開発されてきたことが確認されている

ハードウェア要件

　各種記事を読んでみて思ったのは単にWindows 11の見た目の違いだけでなく、ハードウェア要件の変更によるものではないかと思う。
　64-bit CPU・メモリー4 GB以上・ストレージ64GB以上といった、5年前のPCでも満たしているような内容はともかく、DirectX 12対応GPUとTPM2.0という点が意外に大きい。

　まずDirectXだが、Windows 10をインストールするとDirectX 12がインストールされるが、Windows 10の要件そのものはDirectX 9.0で、この要件は2006年登場のWindows Vistaから変更されていなかった。

3.4.2 Graphics
Devices that run Windows 10 for desktop editions must include a GPU that supports DirectX 9 or later.

　Haswell/Apollo Lake以前の世代のiGPUはDirectX 10までの対応のためWindows 11非対応となる。Haswellは2013年の登場だから、現役のCore系CPU搭載PCの多くはそれ以降のものだろうが、Apollo Lakeは2016年の登場だからそれ以前（～2015年）のBay Trail Pentium J2xx0/Pentium N35xx/Celeron J1xx0/Celeron N28xxシリーズ搭載機もWindows 11非対応となる。

　これまでの半期毎のWindows 10のアップグレードでも対応機種は微妙に変化しており、非対応機種のサポートが順次打ち切られてはいたが、今回のアップグレードでは相当数がサポート対象外となるのではないかと思う。

　次にTPMだが、TPMの概要は他誌やWikipediaを御覧頂くとして、上述のCPU/iGPUの対応/非対応とは違いTPM2.0搭載/非搭載というのが明確でないのが悩ましい。TPMは外付の小型のチップとファームウェアで提供されBIOS/UEFIでON/OFFされるため、CPUなどを見ただけでは対応状況が判別できない。ただし、TPM2.0規格が発表されたのが2014年のことなので2015年頃のPCの対応状況は怪しいとして、2014年以前のPCは全て非対応と考えた方が良さそうだ。

　以上を纏めると、2015年以降のPCの多くはWindows 11対応と思われる（ただし確認は必要）が、2014年以前のPCは全て切り捨てられるということになりそうだ。

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

IBMが契約不履行でGlobalFoundries提訴を準備中

IBMがプロセス開発の“契約不履行”でGFに賠償請求か - EETimes
IBMが契約不履行でGF提訴の準備、先鋭化する先端プロセスでの各社の動向 - マイナビ

　先週の報道になるが、IBMがGlobalFoundriesを契約不履行で提訴を準備中なのだという。果たして司法がどう判断するのかはともかく、GlobalFoundriesの7nmプロセス開発の無期限凍結が発表されたのが2018年09月ということを考えると傍から見ればいささか遅いようにも思える。

　 両社の契約内容は詳細不明であるし実態との齟齬やIBMの狙いは今後の経過で明らかとなる可能性があるが、これまで公開されている情報を基に筆者が想像するにはIBMは2014年にIBM-GlobalFoundries間で締結された10年間有効な契約について、契約の無効化（契約不履行で提訴→調停→違約金無しで契約の無効化）と投資した資金の一部の回収を狙っているのではと思う。

まずは今後の予定を含む経緯を時系列で考えてみる（スペースの都合上この節のみGlobalFoundriesをGFと記載）。

2014年04月　GFが14nmプロセス開発をスキップし、Samsung 14nmプロセスの導入を発表（参考）

• 開発中の14XMを中止しSamsung 14nmプロセス技術14LPE/14LPPを導入

2014年10月 GF・IBMの半導体製造部門を吸収合併を発表（参考）

• IBMがGFに15億ドルの現金を支払う
• GFが以後10年間に渡りIBMのプロセッサを排他的に製造する権利を得る（※22nm/14nm/10nmプロセスのみ？）
• 米NYのIBM Fab（現GF Fab9・Fab10）を取得

2017年07月　GFが10nmプロセス開発をスキップし、直接7nmプロセスへの移行を発表（参考）

• 以後、7nm FinFETとFD-SOI（22nm～）に注力
• 2018年に第1世代7nm量産開始・2019年に第2世代7nm量産開始を予定（当時）

2018年04月　GFが14HPプロセスを発表（参考）

• 14LPE/14LPPと異なりIBM SOI技術をGFのプロセス技術に組み合わせたプロセス

2018年09月　GFが7nmプロセスの無期延期を発表（参考）

• 以後、14/12nm FinFETおよびFD-SOIに注力
• 翌日、GFの最大顧客のAMDが7nm世代でのTSMCへの移行を発表。2019年のZen2よりTSMCで製造

2018H2 TSMCが7nmノードを初めて実用化

• 最初の顧客＝AppleがiPhoneに搭載のA12でTSMC N7を最初に市場投入
• 試作・リスクプロダクションは2016年6月以降に順次開始していた
• Samsungも7nmプロセスを2018年中に量産開始

2019年04月 GFが蘭ON SemiconductorにFab 10を売却（参考）

• 旧IBM Fabを4.3億ドルで売却

2020年02月　IBMがz15を発表（参考）

• 前世代＝z14プロセッサと同じGF 14HPプロセス

2020年08月　IBMがPOWER10を発表（参考）

• 2021Q4より出荷開始
• Samsung 7nm FinFETプロセスノードを採用

2020H2 TSMCが5nmノードを初めて実用化

• 最初の顧客＝AppleがiPhoneに搭載のA14でTSMC N5を最初に市場投入

　EETimesの記事では「GLOBALFOUNDRIESはIBMから支払われた15億米ドルと、追加の数十億米ドルも投じてIBMから譲渡された製造設備の一部を改修し、14nmプロセスを開発し、（GLOBALFOUNDRIESによればIBMが満足するように）14nm製品を生産し、7nmプロセスの開発に着手した」とし、GlobalFoundriesの法務担当が「われわれは義務を果たした」という主張が掲載されているが、14nmプロセス（14HP）こそ開発されたものの続く10nm・7nmはキャンセルされた。

　14nmプロセスについては義務を果たし、7nmプロセスに関する言い分も分らなくも無いが、2014年にIBM-GlobalFoundries間で締結された契約に照らし合わせて10nm/7nmの計画を放棄したことが義務を果たしたことになるのか。

　IBMは2020年02月にz15を発表しているが、2014年の契約の都合で時代遅れの14nm FinFETしか使えていない。1年半も前にTSMCやSamsungは7nmノード世代採用製品の量産品を市場に投入しており、IBMと同じく製品の製造をGlobalFoundriesに委託していたAMDは2019年のZen 2プロセッサーからTSMC N7に切り替えているにも関わらずである。
　2014年の契約にある、GlobalFoundriesが以後10年間に渡りIBMのプロセッサを排他的に製造する権利の範囲が22nm/14nm/10nmプロセスのみなのか、2024年までの10年間ノードを問わず適用されるのかについてはメディアにより書き方が異なるため不明瞭だが、z15の経緯を考えると10nmより微細なプロセスでも影響があるようにも推定できる。そこから考えると2021Q4から出荷予定のPOWER10は上記の契約違反となる可能性がある。

　上記を踏まえると、IBM視点では(1)投資がIBMのために有効に使われず、さらに(2)2021Q4に投入される製品を守るためには2014年の契約の範囲を明確にする必要がありそうに思える。2021Q2現在の段階で提訴の話が出てきた動機の一つはPOWER 10で採用するSamsung 7nmが2014年の契約の対象外であることをGlobalFoundriesから言質を取ることなのかもしれない。
　また、GlobalFoundriesは7nmプロセス開発を放棄してから経済状況が好転していることもチャンスに見える。同社は黒字化しており2021H2～2022H1でのIPOを計画している。GlobalFoundriesとしてはIPOのためにも早急に問題を解決したいはずで、加えて仮にIBMの訴える25億ドルの損害が認められても支払う能力がある。

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

IntelはSiFiveを買収するのか？

Chipmaker SiFive Is Said to Draw Intel Takeover Interest - Bloomberg

　幾つかのメディアがBloombergの報道を引用して報じているが、IntelがSiFiveに対し20億ドルでの買収を提案中なのだという。CPU ISAの覇権争い（RISC vs CISCやx86 vs Arm）が連想され「ライバル潰し」のように受け取られそうだが、個人的には単純に企業のM&A案件としては悪くないアイデアのように思う。

　IntelはArmの最大級のライセンシーの1社であり（恐らくSSDやネットワークのコントローラーに用いられていると推測されている）同様にArmの大口ライセンシーのWestern DigitalやSeagateはRISC-Vへの移行によるライセンス費用の低減を模索しているし、Intelがファウンドリー構想"IDM 2.0"を真剣に考えているならばIntelファウンドリーに最適化されたIPの品数を揃えることは悪いアイデアではない。なにせIntelファウンドリーはユーザーがほぼ皆無でSynopsysやCadenceといったEDAベンダーもIntelファウンドリー用のIPの開発には消極的なのでIntelが代わりにある程度揃えることは理に適っている。
　また、IntelのCPU以外の製品群とのシナジーも考えられ、旧AlteraのFPGA製品だとSiFiveのCPUコアを統合したFPGA製品やAltera FPGAで使えるソフトIP、NPU製品ではMobilEye製品のSoCへの統合（現行EyeQ5ではMIPSを採用）やMovidius製品のVisionプロセッサーへの統合（現行Myriad XではSPARCv5系のLEONを採用）なども考えられる。

	Product	CPU Core	Architecture
Intel (Altera)	Agilex	Arm Cortex-A53	Armv8-A
MobilEye	EyeQ5	MIPS I6500-F	MIPS64 Release 6
	EyeQ6	Intel Atom ?	Intel x86-64 ?
Movidius	Myriad X	Cobham Gaisler LEON	SPARCv5

　実際のところ、SiFiveはRISC-VアーキテクチャーCPU IPをリードしている会社として知られるが、ArmでいうCortex-R系・Cortex-M系に競合しており、サーバーやスマートフォン用CPUというよりはSSD/ネットワーク用コントローラーや車載半導体での採用が多いように思われるから、Intelから見てもライバルとは言い難く、かつてIntelが擁していたXScale/StrongARMに相当する役割を担うのではと思う。

　疑問は買収費用で、報道では20億ドルとされているが企業価値5億ドルと見積もられているスタートアップに対する金額としては高過ぎるように思う。

AMDが3D V-Cacheを発表

COMPUTEXで発表した積層技術3D V-Cacheは性能向上と歩留まりを改善する新兵器　AMD CPUロードマップ - ASCII

　AMDは今年後半に採用製品を投入するようだが、筆者が思うに本命はEpyc・Threadripperだろうと思う。その理由はAMD ZenファミリーCPUのL3キャッシュの扱いにある。V-Cacheの技術的な概要は他誌に任せるとして（参考：ASCII大原氏の記事）、本稿では違った角度から見ていきたい。

　Zen2/Zen3のキャッシュ/メモリー周りの構造は意外に複雑である。
　Intel Core/Xeonであればコアに不随してL1～L3キャッシュが搭載されており各コアやメモリーコントローラーはCPU等速のリングバスでほぼフラットに接続され、他のコアに付随するL3キャッシュへのアクセスでもメモリーアクセスでもレイテンシーはほぼフラットである（※AMD Zenファミリーに比べればレイテンシーのばらつきは無視できるレベルである）。例えばXeon Scalable "Cascade Lake"は最大28コアでL2キャッシュ24 MB・L3キャッシュ33 MBだが、この計57 MBのキャッシュは全28コアからほぼ等速にアクセスできるL2・L3キャッシュ容量である。
　これに対しAMDはチップレット戦略を採っているためにフラットに接続されておらず、キャッシュやメモリーのレイテンシーはばらつきがある。CPUと同じCCXに付随するL2・L3キャッシュに対しては高速にアクセスできるが、他のCCXに付随するL2・L3キャッシュはメモリーとほぼ等速のInfinity Fabric経由でI/O Dieを経由してアクセスするためレイテンシーは非常に長い。そのため、Zen3世代Epyc "Milan"の場合では1 CPUで最大64コアで260 MBものL2/L3キャッシュをもっているが、高速にアクセスできるのはCCXに付随するL2キャッシュ512 KB×コア数・L3キャッシュ32 MBだけで残りの227.5 MB226 MBへのアクセスはメモリーへのアクセスとほぼ同等である。
　実際、AnandTechの分析記事を見ると、Intel Xeonでは同一ソケットのどのコアに対してであっても44～48 nsecほどでアクセスできているにも関わらず、AMD Epycでは付随するL2/L3キャッシュへのアクセスは高速（約～30 nsec）だが、他のCCXへのアクセスは約90～120 nsecほども要している。DRAMへのアクセスはDDR4-3200で110～130 nsec程度だから他のCCXのL3キャッシュにアクセスするのとDRAMにアクセスするのとでレイテンシーはほとんど変わらない。

　つまり、メーカーの謳い文句だけを見ればL2+L3キャッシュの総容量はIntel Xeon "Cascade Lake"では57 MBに対しAMD Epyc "Milan"では260 MBだが、CPUコアからのアクセス速度を加味し高速にアクセス可能なキャッシュという観点ではIntel Xeonでは57 MBに対しAMD Epycでは32.5 MBでしかない。3D V-Cacheはこの状況を逆転できる。

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

ArmがArmv9-AアーキテクチャーのCortex-X2・Cortex-A710・Cortex-A510を発表

Arm Launches Its New Flagship Performance Armv9 Core: Cortex-X2 - WikiChip
Arm Unveils Next-Gen Armv9 Big Core: Cortex-A710 - WikiChip
Arm Unveils Next-Gen Armv9 Little Core: Cortex-A510 - WikiChip

　今回の発表と前回のCortex-X1・Cortex-A78発表時との最大の違いはArmv9-A対応だろう。
 現在のbig.LITTLEでは負荷の大小でコアへのスケジューリングを調整するため命令セットは共通である必要があるためArmv9-A・big.LITTLE対応のクラスターを構成するためにCortex-X2・A710・A510を同時に発表したと考えられる。これはArmv8-A発表後のCortex-A57・A53が既存のArmv7-AのCortex-A15・A7を置き換えたのに似ている。

　そのためか、Cortex-X1→X2もCortex-A78→A710も性能向上幅は小さく抑えられ、ほぼ命令セットを置き換えただけで、次のパフォーマンス向上は次世代コアに持ち越されたように見える。
　Armには現存の開発チームが米国（2チーム）・英国・フランス・ノルウェー・台湾の6チームが存在するが、ノルウェーはGPU・台湾はCortex-M系となっており、Cortex-X2・A710は米国Austinのチーム・Cortex-A510は英国Cambridgeのチームによるものである。他に高性能コアを手掛けるのは仏Sophia-Antipolisのチームで、AnandTechによると次期高性能コアはSophia-Antipolisチームのものという。

　高性能コア＝Cortex-X系が定着したことでCortex-A7x/A7xx系は高性能コアというよりも効率重視に変化してきているように見える。
　big.LITTLEでbig=高性能コア・LITTLE=高効率コアということで見逃されがちだが、高性能コア＝Cortex-A70系でもCortex-A73までとCortex-A75/A76以降とでは方向性が違い、A710でも少し方向性が変わってCortex-A73までの方向性に近くなっている。
　もともと、Cortex-A70系は高性能コアとはいいつつも高性能スマートフォンで実装コストや電力効率が重視されておりIPCの向上には制限が付いていた。そのため、例えばSamsungのExynos MコアやNVIDIAのDenver/Carmelコアのような俗に"Super"と分類される実装が存在していた。大まかな実装コスト（トランジスターコストあるいはダイサイズ）でいうとSuper:big:LITTLE=8:4:1程度である。それがCortex-A75からは明確にIPC向上へ方向転換した。Armの説明ではCortex-A75→A76→A77でそれぞれ+35％・+20％のIPC向上となっている。これらのコアでは半導体プロセスの進化（微細化・トランジスターの高性能化）により動作周波数も向上するから実際の性能向上幅はより大きくなる（参考）。
　それがCortex-A78・A710では再び効率が重視され性能向上に制限がかかるようになった。恐らくCortex-X系のIPCをどんどん引き上げるシリーズが登場したためだろう。Cortex-A77→A78では動作周波数向上分も合わせて+20％、Cortex-A78→A710ではIPCが+10％と説明されており、Cortex-A710では、TLBの強化やSVE/SVE2対応など高性能化が進む一方で、MOP Cache帯域と命令発行帯域が減少（6 MOPs/cycle→5 MOPs/cycle）している。

　今回発表された中で個人的に興味深く感じたのはCortex-A510だ。基本的なスペックはCortex-A55に似ているがAdvanced SIMD/SVE/SVE2ユニットが2コアで共有される形へと変更になった。通常のスマートフォン/PC用途では整数のスカラー演算の出現頻度が高いから浮動小数点/SIMD演算ユニットが共有とされるケースはCortex-A510が初めてではなく、AMDのBulldozer～ExcavatorやSun MicrosystemsのNiagaraでも同様に2コアで共有される形だった。
　ただ、個人的に気になるのは64-bit x2または128-bit x2となっている点である。SVE/SVE2の場合は論理的には最大2048-bit幅のSIMDとなる。Cortex-X2ではSIMDユニット128-bit x4（2サイクル）・Cortex-A710ではSIMDユニットが128-bit x2（4サイクル）だが、Cortex-A510のSIMDユニットが64-bit x2の場合の遅延がどうなるのか気になるところである（というか、それ以前にSVEは128-bit～2048-bitでの実装だったはずで、SIMDユニットが64-bit x2の場合SVEには対応するのだろうか？）。

　Cortex-A510ではIn-order実行ながらCortex-A55の2-wideから3-wideへと変更になった。現時点でCortex-A510の内部構成は公開されていないが、想像するにIn-order実行コアとしてはかなり重厚な構成で次世代LITTLEコアはOut-of-Order実行コアになると予想する。
　Cortex-A55が2-wideとは言っても実行ポートが2ポートというような意味ではなく、Armの公開した図を信じるのであればALU・Integer・FPU/SIMDが各2ユニット、Load・Storeが各1ユニットで必ず2命令発行可能だったようだ。複数の演算ユニットが実行ポートを共用しているのか演算ユニットごとに実行ポートがあるのかArmの図からは読み取れないが、命令デコード数と演算ユニット数だけで見れば2015年のハイエンドコアCortex-A72（3命令デコード・3 Integer/ALU・1 Branch・2 SIMD/NEON・2 Load/Store）相当で、In-order構成の方が不思議なほど重厚な構成である。加えて、シングルスレッド・In-orderだと同時発行できる命令数にも限界があるから、Cortex-A510後継の次世代LITTLEコアはOut-of-Order実行コアになると予想する。

　ところで、2023年には32-bitのA32命令サポートが打ち切られるそうだ。もっとも、32-bitが必要と考えられる純粋な組込コアのCortex-R系/Cortex-M系は32-bitサポートが継続されるだろうから、問題無さそうに思える。

米エネルギー省バークレー国立研究所NERSC「Perlmutter」

Berkeley Lab Debuts Perlmutter, World’s Fastest AI Supercomputer - HPC Wire
4EFLOPSのAI性能を発揮するNVIDIA A100搭載スパコン「Perlmutter」- PC Watch

　米エネルギー省のHPCが2020～2023年に続々と登場するが、その第1弾が2020年末から構築の始まっていたPerlmutterである。～2023年に登場する米エネルギー省の4台のHPCとしては最後のPre-Exascale HPCとなる。以下は2023年までに導入される4台に、比較のため2018年に導入されたSummit/Sierraを加えた表である。
※もっとも、Summit/Sierraなどは途中で公開されたスペックがそのままだったり、導入後にアップグレードしたりで資料によって数字が違い計算が合わない。例えばORNL SummitなどはORNLサイトには「たった4,608ノード」と記載があるが、Top500の記載（SMT8の論理コアを含め2,414,592コア）という記載から逆算すると12,576ノードになる

Site	System		Year	Contractor	Base	Nodes	CPU	Cores	Accelerators	Memory	Interconnect	Bandwidth	Topology	HP LINPACK
DOE LLNL	ATS-4	El Capitan	2023	Cray	Cray Shasta		AMD Epyc		AMD Instinct		Cray Slingshot			> 1.5 Exa Flops
DOE ORNL	OLCF-5	Frontier	2022	Cray/AMD	Cray Shasta		AMD Epyc		AMD Instinct		Cray Slingshot			1.5 Exa Flops
DOE Argonne		Aurora (A21)	2021	Intel/Cray	Cray Shasta		Intel Xeon		Intel Xe		Cray Slingshot			1 Exa Flops
DOE LBNL	NERSC-9	Perlmutter	2021	Cray/NVIDIA/AMD	Cray Shasta		AMD Epyc		NVIDIA A100 CPU-GPU Nodes		Cray Slingshot	200 Gbps	Dragonfly	Pre-Exascale
DOE ORNL	OLCF-4	Summit	2018	IBM/NVIDIA	IBM PS AC922	12,576	IBM POWER 9 25,152 CPUs	301,824	NVIDIA Volta V100 75,456 GPUs	2,801,664 GB	Dual-rail EDR InfiniBand	100 Gbps	Fat-tree	148,600.0 TFLOPS
DOE LLNL	ATS-2	Sierra	2018	IBM/NVIDIA	IBM PS AC922	7,920	IBM POWER 9 15,840 CPUs	190,080	NVIDIA Volta V100	1,382,400 GB	Dual-rail EDR InfiniBand	100 Gbps	Fat-tree	94,640.0 TFLOPS

　PerlmutterはCPU-GPUノードとCPU Onlyノードの二種類のノードで構成される点がユニークで、今回稼働開始したのはCPU-GPUノード（1,536 Nodes = 128 Nodes/Cabinet x 12 Cabinets）のみ、残りのCPU Only Node 12 Cabinetsは今年半ばに搬入予定である。

　詳細はPerlmutterのスペックシートに詳しいが、1ノードあたりAMD "Zen 3" Epyc 7763 2基に256 GBのメモリーとNVIDIA "Ampere" A100 GPU 4基が接続される構成となっており、各ノードはCray Slingshotで接続される。1536ノードで計196,608CPUコア・393,216 GBのメモリー・6,159 GPUで構成される（※1,536 Nodesなら6,144 GPUのはずである）。
　CPU Onlyノードが導入されても約3,000ノードで規模的にはORNL「Summit」には及ばず、科学演算ではFP32/FP64演算性能も理研「富岳」やORNL「Summit」には及ばないが、A100を搭載していることもありMLワークロード/Tensor演算に強く、PC Watchにある「FP16/FP32混合精度演算によるAI処理において約4EFLOPS(エクサフロップス)を発揮でき、FP64でも約120PFLOPSの演算性能」とはいずれもA100に内蔵されているTensorCoreによる演算性能である。通常の科学演算ではFP32で約120 PFLOPS・FP64で約60 PFLOPSとなる。PC Watchの記事では「現時点でTOP500の5位に相当する」とあるが、TOP500の5位（63.46 PFLOPS）・6位（61.44 PFLOPS）が理論値ではなく実測値であることを考えると5位が妥当なのかよく分からない。

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

富岳HPCのコデザイン

富岳スパコンはどのように考えて開発されたのか？- マイナビ

　リンク先の連載記事は「富岳」開発に関する理研R-CCSのアーキテクチャ開発チームのチームリーダの佐藤三久氏のCOOL Chips 24での発表内容を基にHisa Ando氏が解説を付けたものであるが、全9回に渡る長期連載で読み応えがある。非常に興味深く読ませて頂いた。

　理研/富士通の開発した「富岳」は、「ポスト京」と呼ばれていた時代も含めれば随分と沢山の記事があり、マイナビに掲載されている名称決定以降の記事だけでも30件を超えるが、筆者が読んだ限りでは、今回の連載でのポイントはコデザインではないかと思う。実際、第3～4回はどのようにコデザインが行われたか概要、第5～6回はハードウェアについて、第7～8回は第3～6回の内容を踏まえてコデザインのポイントと得られた結果を解説しているように読める。
　富岳運用開始前はハードウェア特にマイクロプロセッサーに焦点をあてた記事、運用開始前後ではシステム全体のアーキテクチャー、運用開始後は性能や得られた成果に関する記事が多かったように思われるが、今回はコデザインを取り上げることで過去に発表された内容を踏まえつつ、ハードウェアからアプリケーションまでの統合するような内容となっている。第5～6回の内容自体は過去のハードウェアの記事と重複する部分があるが、今回はコデザインという観点から見ているので類似の内容でも見え方は異なるように思う。

　記事中で解説されている内容そのものに異論・反論を唱える気は無いが、この種の内容に馴染みのない読者は注意が必要だと思う。それはコデザインは乱暴に言ってしまえば、ワークロードに最適化するようにハードウェア・ソフトウェアを協調的に開発するという事になるのだろうが、例えば第7回で比較対象として挙げられているIntel "Skylake-SP" Xeon ScalableやMarvell "Vulcan" Thunder X2への適用は限定的に考える必要があるからだ。

　なぜなら、Intel Xeon ScalableシリーズもMarvell Thunder Xシリーズも汎用的なサーバー用プロセッサーであってHPC専用プロセッサーではないし、Intel "Skylake"コアに至ってはTDP 15wのモバイルからTDP 200w超のサーバーまでを単一のアーキテクチャーでカバーしているからである。
　HPCではユーザーがアプリケーションをHPCシステム毎に再構築する/できるケースが多いと考えられるが（※8年ほど前の古い記事だがNVIDIA CEOのJen-Hsun Huang氏もNVIDIAがx86ではなくARM CPUに取り組む理由について「HPCの世界ではアプリケーションは世代毎に再構築されるので、どのようなCPUだろうが、GPUだろうが大きな問題にはならない」と語っている）、PC/サーバー用プロセッサーでは、どのコンパイラーの、どのオプションでコンパイラーしたソフトウェアであっても高速に動作する必要がある。

　例えば第7回のL2キャッシュについての解説部分を考えると、解説にある通りコデザインが前提であれば大容量キャッシュの統合を諦め、そのハードウェア＝A64FXに最適化したソフトウェアを開発できるかもしれないが、そのような開発思想はIntel Xeonシリーズでは採用できないだろう。
　Intel "Skylake-SP" Xeonでは、各コア1MBのL2キャッシュとコアあたり1.375MB（最大28コアで38.5MB）もの共有のLLキャッシュを搭載しているほかSMTが実装されており、"Skylake"コアの実行パイプライン構成に最適化されていないコードでも実行ユニットを遊ばせることなく処理を続けることができるが、その代償としてL2・LLキャッシュにコアの約1/4・SMTの実装にコアの5％以上もの膨大なリソースを費やしている。

　乱暴に言えば、もしかすると富士通A64FXと同様のコデザインの結果、理論上ではIntel "Skylake-SP" XeonでもL2・LLキャッシュを廃止することで同じダイサイズで28コア→38コアにコアを増量でき特定用途での演算性能が大きく向上させることが可能かもしれないが、Intelは汎用的な処理性能を選択することにより"Skylake"コアを15Wのモバイルから200W超のサーバーまでを単一のアーキテクチャーでカバーできるというトレードオフが成立している。
　その結果として、HPCベンダーは大量生産されている汎用のIntel Xeonプロセッサーを採用してHPCを構築できる。コストの計算の仕方が米国と日本とで異なるため単純比較はできないとはいえ、米エネルギー省のフラッグシップHPCの場合2015年のOLCF-4/Summitが約350億円（$325 million）・今年末～来年初頭に登場予定のAuroraが約540億円（$500 million）に対し、理研の富岳のプログラムコストは約1,300億円となっている。　

　その結果得られた性能については第7～9回に数字が登場し、それら自体は確かに見事なものだが、そもそも米国などはCPU + GPGPU（アクセラレーター）による演算が主流なので、第7回に登場するような富士通A64FXとIntel "Skylake-SP" Xeon・Marvell Thunder X2との比較がフェアなのかよく判らない。一部のベンチマーク結果では特にThunder X2が大敗しているが、そもそもThunder X2は128-bit SIMDエンジンのARMv8-A Advanced SIMDしか搭載しておらずHPC用途で使うのであればNVIDIAかAMDのGPUと組み合こととなるだろうからCPU単体で比較対象として妥当なのか疑問である。
　もちろん、コデザイン手法を含む富岳の開発で得られた知見は日本のHPC業界・理研RCC・富士通にとって学術的にも産業的にも有益な経験だったろうし、そのための投資という側面もあろうから、そもそもIT最強国家＝米国と米国企業製品と比較することは野暮かもしれないが…。

　ところで、個人的に今回の連載で衝撃的だったのは、異なるCMG（Core-Memory Group）間ではメモリーが独立でデータのやり取りの必要がある場合は同じノード内でもMPIで通信する必要があるという点である。CMGには演算用の12コアとは別に1コアのアシスタントコアがあるが、その謎が解けた気がする。
　HPCに限らず、I/Oに代表されるようなCPU時間に比して非常に長い遅延が発生する処理では、演算を妨げないように専用にCPUコアを割り当てるケースがよくある。マルチコアのネットワークプロセッサーなどでは1コアを専用に割り当てたりする。これは富士通に限った話では無くIBM BlueGene/Qでも17コア中の1コアはI/O用である。
　しかし、もしA64FXの4個のクラスター（CMG）がAMD "Zen"世代 EpycのZeppelin（2 CCX + UMCを集積したダイ）のようにフラットにメモリーにアクセスできるのであればアシスタントコアは各CMGに1コアも必要なかったかもしれない。各CMGに1コア・A64FX 1ソケット＝1ノードで4コアも必要なのは、そもそもメモリーがCMG内でしか共有されておらず、他のCMGのメモリーに格納されているデータにアクセスするにはMPI（同一ノード内）なりOpenMP（他のノード）なりで当該のCMGで代わりにメモリーにアクセスしてくれるコアが必要だからだろう。

　富岳の設計思想として、1単位のジョブが原則として1コアまたは1 CMGで完結し、他のCMGとの通信が多発しない前提であればそれで問題ないのだろうが、比較対象として挙げられているIntel XeonやMarvell Thunder Xが一般的に使われるサーバー用途ではパフォーマンスが発揮されないことだろう。
　ところで、理研/富士通は先代「京」では富士通SPARC64VIIIfxを採用したが、これは富士通のUNIXサーバー用SPARC64シリーズの派生で、基本アーキテクチャーは共通で例えばSPARC64VIIはUNIXサーバー用・SPARC64IXfxはHPC用といったように作り分けられている。富士通がA64FXで同様の製品展開をするのか不明であるが、A64FXをサーバー用に転用するには大幅なアーキテクチャー変更が必要になりそうである。

　本稿はツッコミや批判のような内容となってしまったが、マイナビのHisa Ando氏の記事は読み応えがあるし、HPC用途に限定すれば納得のいくものである。
　ただ、やはりHPC用限定でマイクロプロセッサーからシステムまで作っているのは世界中で日本と中国ぐらいなので、非常に小さいHPCマーケットでしか使えない専用ハードウェアというのは先行きに不安を感じずにはいられない。

Google TPUv4

Google、1エクサフロップを超える性能を持つ「TPU v4」発表、Google史上最高性能のシステム - IT Media

　以前Google TPUを開発していたメンバーがGroqを設立したので、個人的にGoogleが自社開発TPUを続けるのか疑問に思っていたが、TPUv4が発表された。もっとも発表されただけで詳細は不明である。

　個人的に気になるのは「1エクサフロップを超えるGoogle史上最高性能」というくだりである。マーケティング用のあまり意味のない説明ではないかと思う。
　Google TPUv4の詳細は不明なのでこの指摘が妥当なのか不明だが、Google TPUを含むNeural Processing Unit＝NPUにはSIMD演算ユニットやMatrix演算ユニットのクラスターで構成されているが、基本的に積和算のようなNeural Network処理に必要なオペレーションにしか対応していないので汎用的でないことが多い。恐らくIntel CPUに搭載されるAVXユニットやNVIDIA GPUに搭載されるCUDAコアとは異なり、除算などは演算できないのではと思われる（※注：除算は実装が非常に重いことで有名。NPUを実装するならば除算を省く代わりに、より多くの演算ユニットを積む方が有益である）。
　恐らく「1エクサフロップを超える」と言っても「※ただしMLアプリケーションに限る」という注釈が付くはずで、例えば米エネルギー省が導入を計画している1エクサフロップ超のHPC（通称：エクサスケールHPC）とは意味が異なるのではと思う。

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

IBMが2nmプロセスを開発

IBM、世界初となる2nmプロセス。バッテリ寿命4倍に - PC Watch
IBMが開発した2ナノメートルの半導体技術が、米国にもたらす大きな価値 - WIRED.jp
IBM Unveils World’s First 2 nm Chip - EE Times

　先週の記事だが、Wiredの記事があまりにミスリードを誘う記事に読めたのでコメントしておこうと思う。

　IBMがリリース中で述べている、ナノシート技術を利用することで高度な半導体スケーリングを可能にしたという新技術は称賛されるべきだが、それ以上でも以下でも無い内容である。
　研究開発レベルでは実用レベルの製品をスペック的に遥かに上回る試作品を作れる場合がある。それ自体は研究開発・将来の実用化までの一歩ということで重要なステップだが、それが製品化されるとは限らない。製品化されるには歩留まり（良品率）や量産方式の確立やコストなど様々な要因が関わってくるため当然である。
　Wired誌の記事はあたかもIBMの技術で数年後には米国企業が2nmプロセスで製品を製造可能になると言わんばかりだが、そんな単純な話では無い（※注：1990年代のWired誌は他誌とは異なるテーマを扱った優良な記事が多数あったが…決して技術的に優れたライターが記事を書いている雑誌ではない）。実際、IBMは2017年に5nmプロセスのテストチップを開発しているが米国で5nmプロセスを製品を大量生産している企業は2021年5月現在で一社も存在しない。

　もっとも、個人的に興味深いのはこの試作品の製造が何処で行われたかである。
　EETimesの記事によるとIBMのNew York州AlbanyにあるR&Dセンターで製造されたそうだが、Hisa Ando氏は300mmウエファなのでPowerやZを作っているファブでの製造と推測されている。しかし、POWER 9やz15を14nmプロセスで製造を担当しているGlobalFoundriesは既に先端プロセスから撤退済のため筆者としては懐疑的である。

　筆者が今回関与している、あるいは今後関与すると考えているのはIntelである。Intelは3月にIntel Foundry Servicesを発表したが、その際にIBMとプロセスルールやパッケージ技術の開発で協力するとしていた。
　そもそも、2014-15年にIBMが自社ファブをGlobalFoundriesに売却した際には10年間のIBMサーバープロセッサーの排他的な製造権・IBMの持つ数千の特許や知的財産・将来のIBMの研究成果を利用できる権利が売却内容に含まれていた。言い換えればGlobalFoundriesが2014年から10年間のIBM POWER・Z CPUを製造するのでIBMが半導体技術開発を支援することになっていたわけだ。ところが、現実にはGlobalFoundriesは2018年に先端プロセス開発を無期限で凍結してしまった。製造ファブを持たないIBMが先端半導体技術の研究開発を続行しており、IntelとIBMとプロセスルールやパッケージ技術の開発で協力するということは、IBMが恐らくIntelに技術を提供しIntel工場で将来のPOWER・Z CPUを製造することを示唆していると思われる。

GPD WIN Max 2021

GPD 初のRyzen 7 4800U採用ゲーミングUMPC「WIN Max 2021」- PC Watch

　CPUをIntel "Tiger Lake" Core-i7 Core i7-1165G7/1185G7またはAMD "Renoir" Ryzen 7 4800Uに換装したGPD WIN Max 2021が登場するのだという。

　Intel CPUとしてはハズレ世代と言っても過言ではない"Ice Lake"搭載版WIN Max (2020)ユーザーとしては複雑な心境ではあるが、PC Watchの記事によると、既存のWIN Maxユーザーはクラウドファンディングを介しマザーボードだけを入手してアップグレードできるようにするのだそうだ。配慮は素晴らしいところだが、当然ながら自作PCと違い余剰部品を使ってもう一台組めるわけでもなければ、Ice Lake→Tiger LakeにしろIce Lake→Renoirにしろ性能向上幅は限定的なので悩ましいところではある。
　もし安価にアップグレード可能なら交換したいところだが、メインボードには$400前後するCPU（1165G7, 1185G7, 4700U）・LPDDR4Xメモリー・Ethernet（Wired・Wi-Fi）がハンダ付で搭載されていることを考えれば最低でも$500以上すると見るべきだろう。筆者はWIN Max (2020)をIndieGoGoクラウドファンディングで入手したが$779だった。仮にWIN Max 2021が同価格なら買い替えた方がコストパフォーマンスは良いかもしれない（が、CPUが+$100前後するため恐らく$900前後になると思う）。

　記事によるとGPDはゲーミング用にはIntel Core i7-1165G7/1185G7、クリエイティブ用にはAMD Ryzen 7 4800Uを推奨しているようだが、確かにベンチマークなどを見るとそういう傾向は掴むことができる。ちなみに、もし筆者がWIN Max 2021を入手するとしたらRyzen 7版と思う。

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

AMDに関するウワサ 2題

Zen3+ "Warhol"

AMD Ryzen 6000 'Warhol Zen 3+' CPUs Reportedly Cancelled - WCCF Tech

　一部で噂されていたZen3+ = Warholがキャンセルされたのだという。
　そもそも、AMD公式はZen3+について一切言及しておらず、そのような計画が存在したかすら疑わしいが、ウワサによるとZen3に改良が加えられた上でTSMC N6で製造されるとされていた。国内大手メディアでは例えばASCIIで大原氏が言及している。

　筆者は個人的にはWarholの存在自体がデマではないか、あるいは誇張・ミスリードが含まれていたのではと考えている。
　コードネームWarholの真偽はともかく、恐らく今年後半にZen3のリフレッシュ版は登場することだろう。ただし、それはWarholとしてウワサされたような小改良版ではなく、Zen2の「XT」サフィックス付モデルのようなリフレッシュ版かもしれない。そもそも、2021年は新CPUモデルの無い空白の期間となるのでビジネス的な理由で年末商戦を目処にZen3のリフレッシュ版を出す必要があるだろうと推測できる。さらに、（大原氏も指摘されている通り）TSMCの主張通りN7とN6に互換性がある（参考）ならTSMC N7で製造されているZen3世代単体CPU=VermeerをN6に移すなりした程度の変更が行われる可能性はあり、この場合は動作周波数が向上するか消費電力が下がる可能性がある（※ただしIPCは向上しない）。
　しかし、Warholでウワサされたのはその程度の改良ではなく、一説によると平均9％・最大～12％程度IPCが向上という話であった（IPCがそれだけ伸びるということは、論理設計レベルでの変更を示唆している）。昨今のAMDはモジュラー設計とアジャイル的でインクリメンタルな開発手法を導入しているようで、Zen3にZen4で導入予定の新機構の一部を設計レベルで導入したZen3+（仮称）を作り出すことは不可能では無かろう。実際、例えばZen2で導入されたTAGE分岐予測はZen3で導入予定だったものを前倒ししたりしている。ただし、それを物理実装し・マスクを作成し・検査するか？と言えば疑問に思う。もし今年後半に新CPUが出るなら、その昨年後半にはテープアウトして検査している必要がある。あるいは、本当にAMDがそのようなものを計画していたのだとすれば、（2018年のZen+と同様に）過去の発表でZen3+などが登場していたのではないか。

　ただ、このタイミングでキャンセルの話がでてきたのは興味深い。というのも、TSMCの7nm/5nmの予約が2022年末まで・3nmは2024年末まで予約が埋まっていることが報じられたからだ。
　言い換えると、AMD（やNVIDIAやAppleやQualcomm）が来年末までにTSMCで製造するウェハーの数は確定してしまっており、あとは各社の社内での調整が必要になる。例えば、Zen3リフレッシュ版としてVermeerをTSMC N7からN6に移すことを検討あるいは計画していたが、Zen3世代APU=Rembrandtや一部RadeonのモデルでN6が必要なのでTSMC N6版のZen3単体CPUは無くなった、ということかもしれない。

"Zen 5"世代のAPU"Strix Point"はbig.LITTLE構成を採用するのか

AMD Zen 5 "Strix Point" Processors Rumored To Feature big.LITTLE Core Design - TechPowerUp

　AMDがbig.LITTLE相当の実装することは案外難しく個人的に信憑性は薄いと考えるが…仮にAMD内で構想があるとしたら、既に設計が進んでいることだろう。

　信憑性を疑問視する理由はAVX-512である。
　ArmやIntelの実装でもそうだが、bigコアとLITTLEコアは命令セットを互換にする必要があるためだ。Armの場合はbig.LITTLE導入時にCortex-A7/A15とLITTLEコアとbigコアで新コアを出したし、Intel Lakefieldの場合はbigコア=Sunny Coveの機能（AVX/AVX-2/AVX-512）を無効化しLITTLEコア=Tremontに合わせることによって対応している（参考）。これは、現在のbig.LITTLEのソフトウェア側の実装がOSのタスクスケジューラーから見て、負荷に応じてbigコア・LITTLEコアを使い分けているのであって命令セットによって使い分けているわけではないからだ。
　例えばあるタスク（例：Google Chrome）をCore0で動作させていたところCore0-3は未対応でCore4-7で対応している命令セットが出てきたらどうするのか？という話で、不可能ではないがなかなか面倒なことになる。何より、高コストなコンテキストスイッチが発生するなら、省電力機能の実装で負荷が増えてしまうという本末転倒なことになりかねない。

　ウワサの信憑性を検証しても仕方がないので、仮にAMDがbig.LITTLE相当の実装を実現し、Zen系コアをbigコアとすると仮定した場合に疑問となるのは、LITTLEコアはどうなるのか？ということだろう。
　多くの人が真っ先に思いつきそうなのはBobcat/Jaguarなどのいわゆる猫系コアであるが、筆者は2点の理由で否定的である。まず、当時の猫系コアを開発していたチームは既にAMDにいない（Samsungに移籍後に解散した）こと、次に命令セットの問題である。上述の通り猫系コアの命令セットをZen5に合わせる必要がでてくるが、AMDはZen4でAVX-512の実装がウワサされているからLITTLEコアもAVX-512のサポートを追加する必要が出てくる。JaguarはAVXをサポートしていたが物理的には128-bit SIMDのままだった（参考）。この場合物理レジスターの拡張やロード/ストア帯域を具体的には4倍以上に引き上げる大改造が必要になる。これらを総合的に考えた場合、あまり現実的とは思えない。

　ここからは筆者の想像であるが、Zen系コアを派生させるのではないか。
　同一系統の昔のコアから派生させるのはAMDが最初ではない。大原氏のITMediaの記事によるとAppleのbig.LITTLE実装のLITTLEコアはA6で採用されたApple初ArmコアSwiftの派生なのだという（いろいろ調べてみたが、大原氏の記事以外でソースが見当たらないため真偽は不明）。
　正確な数字が公表されていないため概算となるが、トランジスター数はZen→Zen2でコア周りの概ね＋30％増加・Zen2→Zen3で＋10％ほど増加しているようで、TSMC N3で製造されるZen 5ではトランジスター数はZenの2.5倍ほどになっていても不思議ではないから（※製造プロセスが進む毎に+30％増える想定）、LITTLEコアを初代Zenと同等に抑えれば実現は可能そうに思える。

# もっとも、ArmもIntelもLITTLEコアの実装コストはbigコアの～1/4程度のようだからLITTLEコアとしてはやや大きめではある

MicrosoftはHyper-VにArm用の改良を加えている

Microsoft Prepping Linux For Running As 64-bit ARM Hyper-V Guest - Phoronix
Microsoft、Hyper-VとAzureでARM64版Linuxサポート改善の動き - マイナビ

　記事を読む前の事前知識として、MicrosoftはAzureにて市販されているものとは異なるバージョンのHyper-V=Azure Hypervisorを稼働させている。言い換えると、Azure Hypervisorで入った変更が市販されているWindows Server添付のHypre-Vに反映されるとは限らない。

　昨年12月頃、MicrosoftがArmベースのサーバープロセッサーを開発中と報じられているから、それが真実ならMicrosoftがAzure HypervisorでArmをサポートすることは想像に難くない。しかし、Arm版Windows Serverが市販されたりAzureのインスタンスで提供されるか否かは別問題だと想像する。
　そもそも、AWSの場合も2015年にAnnapurnaLabsを買収してから2018年にAWS Gravitonを発表するまでの間にElastic Network AdapterやNitro Security Chipなど多方面でAnnapurnaLabs製Arm SoCを開発し採用していた。恐らくS3やELBなどもAnnapurnaLabs製Arm SoCを採用していたことだろう。L2スイッチやストレージなど一部のネットワークアプライアンスはCPU使用率が高くなることは稀でArmに置き換えることで消費電力を削減できる可能性は高いからだ。
　AWS・Azure・GCPクラスのハイパースケーラーであれば低消費電力なカスタムプロセッサーを内部利用向けに内製することは何ら驚くことではない。ただ、インスタンスとして外部に提供するとなると各種サポートが関わってくるため簡単な道のりではないように思う（AWSがGravitonインスタンスを用意できたのはLinuxで使う前提で、Amazon LinuxもベースのRed Hat Enterprise LinuxがArm対応済だったからだろう）。

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

Cool Chips - Esperantoの低電力高性能・推論エンジン

Esperantoの低電力高性能・推論エンジン - マイナビ

　元Transmetaの創業者・CEOだった人物として著名なDavid Ditzel氏が率いるEsperantoがRISC-Vアーキテクチャーに基づくET-Maxion・ET-Minionを開発し、それらを統合したNeural Network処理用SoCていることは2017年から知られており（参考）、実際に「ET-SoC-1」を開発中であることも昨年発表されていた（参考）が、例えば2017年の記事ではET-Maxionが何個・ET-Minionが何個という程度しか説明が無かったし、2020年の記事でもSoCのフロアプランの説明があった程度で内部構造の詳細な説明は無かったが、今回はそのアップデートで、より詳細な構造が明らかとなっている。

　ET-Minionのクラスターは「Minion Shire」で分割されており、ET-Minion 8コアをクラスタリングしたブロックを4クラスター（計32コア）で構成されており、ET-SoC-1ではET-Maxion 4コア＋Minion Shire 34クラスター（計1088コア）に加えサービスプロセッサーET-Minion 1コアで構成されており、各ブロックがメッシュファブリックで相互接続されている。また、256-bit幅のLPDDR4メモリーコントローラに接続されている（より詳細は記事を参照）。

　OCP（Open Compute Project）のGlacier Point V2での接続例が紹介されているが、Facebookあたりに採用される話が進んでいるのかもしれない。
　Glacier Point V2はFacebookが主導的に開発しており（参考1、参考2）、同時期にIntelが旧Nervana "Spring Hill" NNP-I1000をGlacier Point V2対応として発表しており（参考）、FacebookがIntel Nervana NNP-I1000を採用しているものと推定されていた。そのNervanaは2020年にIntelが開発・製造中止を発表しているのでNPP-I1000の置き換える需要がある可能性はある。ET-SoC-1自体は推論にも学習にも対応しているが推論が強調されているのはNervana NNP-I1000（推論専用）の置き換えを狙っているのかもしれない（※もっとも、発表スライド中にある「OCPデータセンター例」の写真に写っているのはFacebookではなくVantageである）。
　そもそも、2017年時点ではEsperantoはET-Maxion 8コア＋ET-Minion 4096コア構成を目指していたのが、上述の通りET-SoC-1ではET-Maxion 4コア＋Minion 1088コアとなっていることから考えると、具体的な製品計画に合わせてダイ/パッケージサイズや消費電力の制約から仕様が調整された結果かもしれない（もちろん他の制約により変更を余儀なくされた可能性もあるが）。Glacier Point V2はM.2・Dual M.2に対応しているので、拡張カードサイズや消費電力は規格に沿ったものである必要がある。機械学習では学習アクセラレーターに用いられることが多いOAM（OCP Accelerator Module）の場合NVIDIA Tesla A100・Intel Nervana NPP-T100・Intel/HabanaLabs Gaudiの場合いずれも300-400 WクラスのTDPとなるが、Glacier Point V2の場合M.2 22110で最大12W・Dual M.2 22110で20W TDPとなるようだ。ちなみにGlacier Point V2ではDual M.2モジュールを6基搭載でき、1ラックあたり64 Glacier Point V2モジュールを搭載できるため、計384基のET-SoC-1を搭載できる。

　ET-SoC-1自体は推論にも学習にも対応していると述べたが、学習よりも推論に最適化されている。
　例えばET-Minionのベクトル拡張命令はFP16/FP32 256-bit SIMDに対しINT8 512-bit SIMDだからFP32で学習を行う約8倍の性能でINT8で推論を実行できる可能性がある。また、Minion ShireにはTCM/キャッシュが搭載されており、ET-SoC-1全体（Minion Shire x 34）では136MBにもなるが、Minion Shire 1個では4MBしかなくFP16よりもINT8の方が効率的に使えそうである。ちなみに、NNP-I1000でもプロセッサークラスター（ICE）毎に256 KBのTCM（Tightly Coupled Memory）と4MBのSRAMキャッシュが搭載されていたためNNP-I1000を置き換える用途では問題ないという判断なのかもしれない。

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

NVIDIA "Grace"

NVIDIA、GTC 21の基調講演でデータセンタCPU「Grace」を発表 - マイナビ
NVIDIA Graceとは　ArmベースAI専用CPUの実力 - ITmedia
NVIDIA Announces CPU for Giant AI and High Performance Computing Workloads - NVIDIA
Grace CPU - NVIDIA

　詳細が発表されていないため推測の粋を出ないが、個人的な感想としては各種メディアの記事中にある「AI専用CPU」という表現はミスリードではないかと思う。より正確に言えば「（NVIDIA GPUで）AI（処理を高効率で動作させる）専用のCPU」で、"Grace" CPU単体での演算性能は高くないのが実態ではないかと思う。

　例えばビデオゲームがそうだがCPUがGPUに処理の大部分をオフロードするワークロードは存在し、Neural Network処理もそのひとつである。実際、NVIDIAは"Grace"発表のプレゼンテーション中でGPU-CPU-メモリー間のデータ転送について言及したのみで、CPUコア単体の性能やFLOPS/TOPS性能には一切触れていない。恐らくCPU単体でのNeural Network処理性能はAVX-512搭載Intel Xeonの方が圧勝で、CPU + GPU構成で高性能を発揮するのだろうと推測する。

　そもそも、NVIDIAは同社のGPUを効率良く動作させるホストCPUを必要としており、例えばNVIDIAはIBMとORNL OLCF-4 Summit（2018年）を組んだ時でもIBMと協業してIBM POWER 9にNVLinkを統合した。今回のNVIDIAの発表スライドに登場したx86 CPUとGraceのメモリーバンド幅比較スライドのような違いはx86 CPUとIBM POWER 9にも存在した。GPUはホストCPUにある程度制約を受けるためNVIDIAがCPU側のコントロールを欲していることは公然の秘密で、x86アーキテクチャーライセンスの取得を狙っていると報じられたり（参考1、参考2）、当時独立企業だったArmにエンジニアを100人規模の送り込んでアーキテクチャー開発に携わったこともある（参考）。
　CPU・GPUを持つIntelがCXL・AMDがCCIXへと舵を切りつつある現状を鑑みても、NVIDIAがNVLinkを統合したCPUを持つ意思があることは想像に難くない。

システム構成

　NVIDIAの発表スライドの趣旨は理解できるのだが、こちらもミスリードがあるように思う。
　x86 CPU + 4x GPUと"Grace" CPU + 4x GPU構成でのメモリーバンド幅の比較の図が示されているが、x86の構成でGPU-Memory間の帯域が64 GB/sに制限されているのは～2019年頃のPCIe Gen 3 x16（16 GB/s）が4 リンクである。"Grace"が登場すると見られる2023年時点であればPCIe Gen 5 x16（63 GB/s。4リンクで252 GB/s）も使える。もちろん、PCIe Gen5でもNVLinkとの優劣が引っ繰り返るわけではないが、2019年頃の規格と2023年の新製品とを比較して「30倍」と主張することはフェアとは言えない。
　また、いずれの場合もCPU-GPU間接続がボトルネックとなるのであまり関係ないが、CPUソケット数を増やすとCPU-Memory間の帯域も増えるので1 socket構成と4 socket構成とを比較することもフェアなのか判断に迷うところである。

　下の表はNVIDIA発表資料に合わせて別の構成を比較したものである。2023年のx86構成はIntel Xeon "Sapphire Rapids"をモデルとしているが、恐らくAMD Zen4世代Epyc "Genoa"やZen5世代Epycでも可能と思われるが趣旨がズレるので割愛する。OLCF-4 SummitはノードあたりPOWER9 x 2ソケット・NVIDIA V100 x 6 GPUだったりと変則的だが、2018年のシステムとしては"Grace"に近い傾向を見せていることが解る。
　ちなみに、筆者の知る限りLPDDR5Xなどという規格は存在しないため、過去にLPDDR3/4→LPDDR3X/4Xで起こったことがLPDDR5で踏襲された場合を想定しておりバンド幅の概算と思われる（もしLPDDR5Xが4266 MHzならx512構成で546 GB/sである）。

	NVIDIA Presentation		Reference
CPU	x86	"Grace"	OLCF-4 Summit POWER 9	x86
Year	????	2023	2018	2023
# of CPU sockets	1	4	2	2
# of GPU modules	4	4	6	4
4x GPU-VRAM (GB/sec)	HBM2E 8000	HBM2E 8000	HBM2 900 x 6 GPUs 5400	HBM2E 8000
CPU-Memory (GB/sec) (per socket)	DDR4-3200 x 8ch 200	LPDDR5X 4266 x 512-bit 500	DDR4-2100 x 8ch 135	DDR5-4800 x 8ch 307
CPU-GPU (GB/sec)	PCIe Gen 3 x16 16	NVLink 4.0 500	NVLink 2.0 300	PCIe Gen5 x 16 63
GPU-Memory (GB/sec)	PCIe x16 x 4-links 64	NVLink x 4-links 2000	NVLink x 6-links 270	PCIe x16 x 4-links 252

"Grace" SoCの謎

　上述の通り、"Grace"とは「NVIDIA GPUでAI処理を高効率で動作させる専用のCPU」と推定され、その内部構成は説明されていないため幾つかの疑問点が存在する。

　まずCPUコアについてだが、処理をGPUにオフロードする前提と思われるためNeoverse N2（Cortex-A78）相当ではないかと想像する。
　NVIDIAの発表スライド中にある画像を参考にすると12x7のメッシュで接続された84コアのように見えるが、恐らく実態に即していないため、概ね80コア＋冗長用コアが搭載されるものと思われる。
　NVIDIAは過去にDenver/Denver2/Carmelという独自設計のArmv8コアを開発してきたが、NVIDIA自身が"Grace"のCPUについて「Next-Generation Arm Neoverse Cores」と表現しているため恐らくArm純正のNeoverse V1かNeoverse N2と思われるが判然としない。上述の通り"Grace"が「NVIDIA GPUでAI処理を高効率で動作させる専用のCPU」だとすればNeoverse N2ではないかと想像する。ちなみにNeoverse V1は最大96コア・Neoverse N2は最大128コアである。

　最も不思議なのがメモリー構成である。
　上述の通りNVIDIAの発表スライド中にある画像が恐らく実態に即していない理由がこれで、LPDDR5X with ECCだとしているにも関わらず、恐らく画像の構成ではECCが考慮されていない。
　LPDDRメモリーはスマートフォンなどモバイルを想定しているため筆者はECC構成の実例を見たことは無いが、ECCの仕組みは単純なのでコントローラー側さえ対応すれば実現は可能である。一般的なPCのECCの場合ではメモリーはx8 configのDRAMを8個並べた64-bitインターフェースに、ECC用にDRAMを1個追加した72-bitインターフェースで1チャンネルを構成している。仮に64-bit/8-bytesのデータを読み/書きする場合は8-bitずつ8チップに対し読み/書きされるわけだが、この各チップの0～7ピン・8チップ分をXORしたものがECCで1-bit誤りを検出できる（訂正：筆者の勘違いのため訂正いたします。ECCでのエラー検出はパリティーではなくハミング符号による1-bitエラー検出・修正でした）。つまり、ECCを実現するには対応コントローラーと必要なチャンネル数/メモリーチップのコンフィグ+1個のメモリーが必要となる。
　LPDDRメモリーでは1パッケージで2チップが搭載されインターフェースは64-bitが一般的である。例えばLPDDR1～LPDDR3の場合では1チップがx32コンフィグで1パッケージに2チップが搭載されて64-bitが構成されている。そこから計算するとNVIDIA発表スライド中の構成では64-bit x 8パッケージ = 512-bitであろうと想像できる。事実、上述のバンド幅の比較では1 CPUあたり500 GB/sのメモリーバンド幅を実現するとされているが、恐らく512-bit程度の幅がないと実現できない（もしLPDDR5Xが4266 MHzならx512構成で546 GB/sである）。NVIDIAが何bit単位でチャンネルやECCを構成するのか不明だが、恐らく少なくとも1パッケージのLPDDR5Xメモリーは追加されると思われる。

　最大の謎がネットワークインターフェースである。
　筆者の想像では旧MellanoxのConnectX-7ネットワークアダプターがSoCに統合されると思われるが、いかんせんNVIDIA発表スライドではまったく登場しなかったため、どのような構成になるのか不明である。
　NVIDIAが買収した旧Mellanoxのネットワークアダプターはネットワークを介したGPU-GPU間接続＝GPUDirectに対応しており、NVIDIA発表資料中の4 CPU + 4 GPU構成以上にスケールさせるためにも旧Mellanoxのネットワークアダプターの採用は必然と思われるが、"Grace"に統合されるのかGraceとPCIeで接続されるのかは分からない。もっとも、ConnectX-7系とArm CPUを統合した最新SoC＝BlueField-3の場合だと恐らくConnectX-7は巨大なせいでArm CPUコアは16コア止まりだから、"Grace"のCPUコアが64～128コアに達するようであればConnectX-7はPCIe外付される可能性が高そうに思われる。

NVIDIA "Atlan"

NVIDIA Unveils NVIDIA DRIVE Atlan, an AI Data Center on Wheels for Next-Gen Autonomous Vehicles - NVIDIA

　報道を見る限り、"Atlan"の注目度は"Grace"より低かったように見える。もっとも、2023年登場の"Grace"に対し2026年登場の次々世代の車載SoCということで雲を掴むような話なので仕方がないのかもしれない。

　しかし、筆者にはNVIDIA GPU/車載SoCに旧Mellanox ネットワークアダプター/DPUやArmサーバーCPU搭載SoCの追加によって、CPU/GPU/ネットワークの共通したIPを搭載し共通のソフトウェアスタックを利用可能な多様なプラットフォーム構成の実現が可能になるように思う。実際、"Atlan"の発表でNVIDIAが出したイメージ画像は「Ampere-Next GPU」「Grace-Next CPU」「BlueField DPU」と既存の他のプラットフォームのIPをSoCとして統合したものだ。
　下記の表はCPU/GPU/Networkingの各種IPの搭載比率を◎/○/△/N/A（非搭載）で表現したものである（※製品の世代毎に変化するので、あくまでもコンセプトである）。Server SoCは"Grace"に始まるファミリー、Automotive SoCはTegra/Xavierファミリー、DPUは旧MellanoxのBlueFieldファミリーのことで、同じIPを比率を変えて統合することで多様な製品を作り分けていることが解る。

	CPU	GPU (GeForce/Tesla)	Networking (ConnectX)	Domain Specific
Discrete GPU (GeForce/Tesla)	N/A	◎	N/A	High band-width memory
Server SoC	◎ (probably > 64-core CPU)	N/A	？	High band-width memory NVLink
Automotive SoC (Tegra/Xavier)	△ (8-12-core CPU)	〇 (192 - 2048 CUDA cores)	△	ASIL-D Safety, CAN Networking
DPU (BlueField)	〇 (8-16-core CPU)	△ (planned)	◎ (up-to 400GbE)

 

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

Intelのファウンドリービジネス

Intelがアリゾナに2棟の新ファブを建設へ、ファウンドリサービスに本格参入 - マイナビ
はたして敵か味方か？　IntelのIDM 2.0宣言に困惑する台韓半導体業界 - マイナビ
Intel、2023年に7nmのコンピュートタイルを持つ「Meteor Lake」を投入 - PC Watch

　Intelは3月23日に開催された記者会見で製造プロセスのロードマップを説明した。
　もし事前情報抜きに発表を見たなら印象は変わったものだったかもしれないが、過去の経緯から考えると期待外れだったと思う。

　まず前提として、Intelがファウンドリービジネスに参入するのは初めてのことではない、というか以前にファウンダリービジネスに参入しており、低調に推移した後、14nm製造キャパシティーの枯渇と10nmの頓挫で有耶無耶になった状態である。

　Intelがファウンドリービジネスへの参入を表明したのは2014～16年頃のことである。最先端プロセスが14nmの頃、まだIntelがTSMCなど競合他社の一世代先を行っていると言われた時代のことである（参考1・参考2）。
　恐らく動機は色々とあったのだろうが、最大の動機は製造キャパシティーの余剰であろう。Intelが天文学的なコストを支払って開発・設置した他社を凌駕した（※当時）製造プロセスのキャパシティーがIntel製品の製造だけでは余剰してしまう場合、コストの償却と次世代プロセスの開発・設置資金の調達のためにも他社製品を受託製造する必要があった。
　そもそも、当時のIntelはどうしても製造キャパシティーが余剰してしまう計画になっていた。Pentium II～Core 2の時代はCPUにNorth Bridge/MCH・South Bridge/ICHを加えた3チップソリューションだったのがNehalem以降でCPUにMCHが統合されPCHを加えた2チップソリューションとなった。3チップソリューションではCPUを最先端プロセス（例：14nmプロセス）・North Bridge/MCHを前世代プロセス（例：22nmプロセス）・South Bridge/ICHを前々世代プロセス（例：45nmプロセス）で製造していたが、2チップソリューションになると前世代または前々世代プロセスの製造キャパシティーが余剰となってしまう。加えて、Nehalem～Kaby Lakeまでの間でプロセス微細化が進む一方で、クライアントCPUは2～4コアに留まりCPUのダイサイズは縮小し続けたから、1ウェハから取れるCPUダイの数が増えてしまい、やはり製造キャパシティーが余剰してしまう。

　それでは、2014～16年当時の、TSMC・Samsung・GlobalFoundriesといった他社ファウンドリーを性能で一世代分も凌駕していたIntelのファウンドリービジネスは順調だったか？といえばそうではない。そんな高性能（※当時）ファウンドリーが低調だったのには理由がある。IPベンダー・EDAベンダーのサポートが限定的だったからだ。
　例えばIntelは2016年にArmと提携している。Androidスマートフォンのアプリケーションプロセッサーなどで用いられるArm CPUコアであるが、多くのプロセッサーベンダーはArmからPOP IP（Processor Optimized Package）と呼ばれる、半物理設計済・最適化済のIPを採用している。ところが、最適化/物理設計は製造プロセス毎に異なるから、2016年以前はArm POP IPをTSMCでは利用できるがIntelでは利用できないという状況だった。
　また、EDAベンダーのIP、特に物理層（PHY）IPがIntelファウンドリーサービスに対応していなかったのも大きいと思う。例えばAMDはZen/Zen+でPCIe Gen3のPHYをSynopsys 12G Multi-Protocol PHYのライセンスを受けて使用しているが、Productsのセクションを見ても台TSMCの多様なプロセスに対応する一方で、韓Samsung・米GlobalFoundriesですらSS 5LPE・GF 22FFDSOIにしか対応しておらず、Intelについては一切掲載されていない。Cadenceの場合も同様で台TSMC・台UMC・中SMIC・米GlobalFoundriesの名前は見つかるがIntelについては一切掲載されていない。
　他社製IP・物理層IPなどと言われてもピンとこないかもしれないが、Androidスマートフォン向けプロセッサーベンダーは毎年のようにリリースされる新CPU IPや新メモリー規格をSoCに組み込み毎年のように製品化している。これを可能としているのは他社製の各種IPをEDAツールでレゴブロックのように組み合わせることでSoCを構成可能だからだ。特に低電圧で動作する最先端プロセスで高電圧での動作が求められるI/Oは難しくSynopsysやCadenceのようなベンダーの提供するPHY IPはよく使用される。

　言い換えると、Intelのファウンドリーサービスで製造したければ、極めて限定的なEDAツールとIPとを使い、かなりの部分を自作したり自前でデバッグしたりする必要があり、その結果2014～16年当時のIntelのファウンドリービジネスの顧客は米Altera（2015年にIntelが買収）・中Spreadtrum（Intelと提携しスマートフォン向けにAtomベースのSoCを開発）・米Netronome（IntelからIXPプロセッサービジネスを買収した都合でIntelファウンドリーを利用）・米Achronix Semiconductorぐらいであった。

　もっとも、筆者の私見では2014～16年のIntelのファウンドリービジネスの低調ぶり自体は大きな問題ではない。なぜならIntelがファウンドリービジネスを本格的に行っていたのは2014～16年の僅か2年間だけで、もし今頃10nm・7nmが目論見通り展開できていたなら違う結果になった可能性は否定できないからだ。むしろ致命的な問題は2017～年頃の10nmプロセス・7nmプロセスでの躓きと14nmプロセスの製造キャパシティーの枯渇によりファウンドリービジネスが事実上破綻したことだ。
　IntelのCustom Foundryには一応22nmに加え14nmや10nmが掲載されているが、筆者の知る限りNetronome・Achronixは22nmのみ（AchnomixはTSMCに移行）・14nmはSpreadtrumをIntel Atomコア搭載製品のみ（それ以外はTSMC）といった具合で、Intel 10nmを採用したIntel以外の半導体企業を筆者は知らないし、それ以前にIntelファウンドリービジネスの話題を2016年以降に聞いた記憶が無い。

　そんなIntelがファウンドリービジネスに再参入（？）するとして、誰が採用するのだろうか？
　例えばファウンドリービジネスで先頭を走るTSMCとファブレスで半導体で業界を牽引しているAppleの組み合わせを考えると、しっかりとした製造プロセスのロードマップと製品計画が見える。2019年12月のIEDM2019・2020年3月のISSCC2020で詳細が発表されたTSMC N5は2020年10月に登場したApple A14で初めて採用され、ISSCC2020で概要が発表されたTSMC N3は2021年1月にリスクプロダクションを開始しており、2022年のApple製プロセッサー（A16？）に採用される見込みだ。スケジュールから逆算するとAppleは既に2021年のiPhoneに搭載されるプロセッサーは設計完了・テープアウト済、現在は2022年のiPhoneに搭載されるプロセッサーを設計中のはずで、両社のスケジュールは同期している。
　それに比べるとIntelのロードマップには疑問符が付くところではないかと思う。Intelもロードマップこそ披露しているが、10nmは2017年から3年間も遅れた上に現在でも性能不足（14nmよりも遅い）で、当初2021年に実用化予定だった次世代7nmは2022年末～2023年の予定となっている。
　筆者の私見だがIntelのファウンドリービジネスを利用する企業は、強い政治力を持ちIntelと喧嘩できる米国企業に限定されるのではないかと思う。大手以外の半導体企業では14nmの二の舞（Intelが失敗すると製品計画が破綻する）になりかねないし、米国政府はセキュリティーの観点から米国での半導体製造を重視しているからだ。

　Intelは賛同企業（採用企業とは言ってない…）としてGoogle・Amazon・Microsoft・IBM・Cisco・IMEC・Qualcommの名を挙げたが、筆者の予想では恐らく最初の大物顧客はIBMではないかと思う。理由は簡単で、Intel・IBMの利害が一致しているからだ。それに対しGoogle・Amazon（Annapurna Labs）・Cisco・QualcommはもともとファブレスなのでTSMCでもIntelでも何処でもいい。
　IBMは2014年10月まではUNIXサーバー用POWERプロセッサーとメインフレーム用zプロセッサーを自社ファブで製造していたが製造部門をGlobalFoundriesに売却しGlobalFoundriesでの製造に切り替えている。そのためPOWER9・z14はGlobalFoundries 14LPが採用されたが、2018年に当のGlobalFoundriesが10nm以降をキャンセルしたためz15でも14LPを採用する羽目になって現在に至る。そもそも、当初の計画ではGlobalFoundriesは10年間に渡りIBM製サーバープロセッサを排他的に製造できることになっていたので、IBMはGlobalFoundriesの代わりのPOWER10以降・z16以降の製造委託先を探す必要がある。
　もしIBMがIntelに生産委託する場合、早ければ2021年中に登場予定のPOWER10からIntel製造になる可能性がある。

03/28 追記

　Business Insiderの記事で「専門家の一部からは、コストフルな自社工場での製造をあきらめて他社に製造委託すべきとの声もあがっている」のだそうだ。有料記事を購読していないため、誰の意見なのか・どういう提案なのかといった詳細を読むことができないのだが…それは「すべき/すべきでない」という以前に極めて非現実的である。

　そもそも、Intelは世界最大級の半導体メーカーで、売上高は世界最大・生産能力は世界6位にも達する。
　生産能力で言うとTSMCは月産270万ウェハーに対しIntelは月産88万ウェハーで、仮にIntel製品を全てTSMCで製造するとすればTSMCの生産能力の1/3を埋めてしまうことになる。実際のTSMCはApple・AMD・NVIDIA・QualcommなどのIntelより小規模なファブレス半導体企業からの生産委託を受けている状況で既に最先端プロセスのキャパシティーが枯渇し増強を表明している状態で、Intelからの大規模な生産委託に耐えられる生産能力を持っていない。もちろんIntelの一部製品（例：Xe-HPGなど）をTSMCで製造するようなことは可能だが、最新の製品すべて（例：すべてのCoreプロセッサー）をTSMCで製造するようなことは不可能である。
　ちなみにSamsungの生産能力は月産300万ウェハーでTSMCを上回っている（ように見える）が、過半はNAND/DRAMプロセスでロジックプロセスではないため、SamsungがTSMCよりも大きなCPU/GPU製造能力を持っているという意味ではない。

　筆者は1月16日に投稿した記事でIntelがTSMCから製造プロセスのライセンスを受けるのではないかと冗談半分で独自の予想をしたが、これは仮にIntelが先端プロセス開発を放棄した場合でも、TSMCやSamsungへの委託はキャパシティー的に不可能のため、先端プロセスのライセンスを受けて自社工場で生産するしかないという意味である。

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

AMD Zen4に関するウワサ2題

Zen 4世代Epycは最大96コア・メモリーは12チャンネル

AMD EPYC Genoa CPU Platform Detailed – Up To 96 Zen 4 Cores, 192 Threads, 12-Channel DDR5-5200 - WCCF Tech

　Zen 4世代Epycは、最大96コア・12チャンネル DDR5メモリーをサポートするのだという。
　Zen 4世代でも1 CCD（Compte Complex Die）あたり8コアが維持されると仮定すれば96コアというのは12 CCD + 1 sIOD（Server I/O Die）の計13 ChipletによるMCMとなると予想される。

　そのため、多くのニュース記事では本件について13 ChipletのMCMをsIODを中心に左右に3 CCDが2 列ずつ（3 CCD x 4 列 = 12 CCD）配置した想像図が示されているのだが、このレイアウトについては実物が出るまではよく分からないのであくまで想像図である。
　CCDとIODはIFOP（Infinity Fabric On-Package）で接続されるが、配線長が短い方が電気的に有利である一方で、現在のRyzen/Epycでも既に配線が入り組んでいるためだ。配線長だけを考えれば3 CCD x 4 列よりも2 CCD x 6 列とかの方が良いかもしれないし、むしろIODを中心にCCDがIODを囲む形の方が良いかもしれない（ちょうどGPUとGDDRメモリーのようなレイアウト）。いずれにせよ実物が出てくるまでは何とも言えない。

　ところで、メモリーチャンネル数（≒メモリーバンド幅）については12チャンネルというのは妥当そうに見える。
　メモリーチャンネルについてはZen 2世代EpycについてServeTheHomeが興味深い考察をしているのだが、CCD 2個あたりメモリーチャンネルが2チャンネルとなっており、CPUコア数：メモリーバンド幅の釣り合いがRyzen 9 3950Xと同等になっている。これはCPUコア数とFLOPSが比例すると考えれば、例えばHPCで指標のひとつであるB/F（1 FLOP性能あたりのメモリー帯域幅）が16コアRyzenから64コアEpycまで共通ということで妥当と言える（演算性能：メモリーバンド幅という観点では最大コア数＝最低のB/F値である）。従ってZen 4世代でEpycが最大96コアとなるのであれば12チャンネルとなるのは妥当と考えられる。
　もっとも、このServeTheHomeの考察にある、CCD 2個とメモリーチャンネルが2チャンネルをまとめた「Quadrant」という考え方がどの程度妥当なのかは分からない。CCDとIODを結ぶIFOPの帯域はメモリー2チャンネル分のRead帯域と合致している（参考）のでミクロ的にはともかくマクロ的な視点では概ね正しそうに思えるが、全コアに均等にタスクが割り当てられるとも限らないし、各CCDが最寄りの2チャンネルしか使わないわけでもないので、瞬間的には1 CCDのみがビジーで1 CCDの8コアが全8チャンネルを使うことも理屈の上ではありえるだろう。

　個人的に気になるのはDDR5メモリーとPCIe Gen 5 128レーンのサポートに伴うInfinity Fabricの拡張である。
　前述でIFOPの帯域について触れた通り、ZenアーキテクチャーではInfinity Fabricの帯域が全面的にメモリーの帯域を強く意識したものになっている。メモリーがDDR4からDDR5に帯域が倍増するということはInfinity Fabricの帯域も倍増することを意味しているし、また、Epycでソケット間を結ぶIFIS（Infinity Fabric Inter-Socket）はPCIeとSerDes/PHY（Zen～Zen2ではSynopsysのPCIe用PHYだった）を共有しているため、PCIe Gen5の採用は同等のIFIS帯域の場合に必要となるレーン数が減ることを意味している。

　事実、Zen 2世代EpycではPCIe Gen4が採用されたためIFISの帯域は増えたが使用されるレーン数はZen世代Epycの64-laneから48-laneに削減された。Zen/Zen 2世代Epycではいずれも1ソケットあたりPCIe 128レーンだったから、Zen世代Epyc 2-way構成ではPCIe 128-lane（(128-lane - 64-lane) x 2 = 128-lane）、Zen 2世代Epyc 2-way構成ではPCIe 160レーン（(128-lane - 48-lane) x 2 = 160-lane）が使用可能だった。
　Zen 4ではどうなるのか興味深いところである。PCIe Gen5の採用により1レーンあたりの帯域は倍増するものの、同時にDDR5の採用によりメモリーの帯域も「ほぼ」倍増するので必要なレーン数は恐らく変わらないからである。もっとも、Zen 2世代EpycはDDR4-3200まで、Zen 4世代EpycがWCCF Techの言う通りDDR5-5200までだとメモリーの帯域は約1.6倍だからIFISに使用するレーン数を最大30~40％程度削減することはできるかもしれない。

　そして、もしIFISのレーン数を削減できるとすれば、いよいよEpyc 4-way構成が視野に入ってくる。現時点でZen 4で4-way対応はウワサもされていないが、Zen 4かZen 5（仮称）か近い将来の時点で実現されることだろう。
　利益率でIntelの後塵を拝し粗利率50％を目指すAMDにとって利益率の高い4-way対応製品は悲願と思われる。例えばIntel "Skylake-SP"世代 Xeon Scalableでいうと2-wayのみのXeon Silver 4114（10C/20T, 2.2 GHz / Turbo 3.0 GHz, LLC 13.75 MB）は$ 694.00だが、4-way対応のXeon Gold 5115（10C/20T, 2.4 GHz / Turbo 3.2 GHz, LLC 13.75 MB）は$ 1,221.00にも達する。AMD自身の利益率を上げる意味でもIntelの牙城を崩す意味でも4-way構成は必要なはずだ。
　AMDのISSCC 2019での発表によると、現行のEpycでも技術的には4-way構成は可能なようだ。しかし製品化していないのは恐らくメモリー帯域や使用可能なPCIeレーン数とのバランスのせいだろう。Zen～Zen 2世代Epycでは1ソケットあたりのPCIeレーン数は128-laneなのでZen世代Epyc 4-way構成（IFISが64-lane x 3-link＝192-lane必要）でもZen 2世代Epyc 4-way構成（IFISが48-lane x 3-link＝144-lane必要）でもレーン数は不足してしまう。しかし、もしZen 4世代EpycでIFISに必要なリンク数が30-lane（48-lane - 18-lane）まで削減できるとすれば4-way構成でも現実味がでてくる。IFISが32-lane x 3-link＝96-laneに加え4-way構成でもPCIe 32-lane/socket x 4-way=128-laneをPCIeとして使用可能になるからだ。
　上述の通り、Zen 4世代で4-way構成をサポートするという話は現時点でも聞こえていない（2-way構成までというウワサはある）が、理論的に現実味を帯びてきているのでZen 4かZen 5か近い将来の時点で実現されそうな気がする。

※このあたりの正確な試算を試みているが、ネット上のドキュメントによって情報が異なったり計算が合わなかったりするため、もう少し纏めてから記事にしようと思う。

Zen4はAVX-512とbFloat 16をサポートする

AMD EPYC Genoa Zen 4 CPUs Rumored To Feature AVX3-512 & BFLOAT16 Instruction Sets - WCCF Tech

　記事中にあるZen 4の特徴を訳すと以下のようになる

• 1 socketあたり64-coreを超えるコア数
• コアあたりのスレッド数は2-thread
• 2-socketまでの構成をサポート
• 57-bit仮想アドレス、52-bit物理アドレス
48-bit仮想/52-bit物理から変更。52-bit物理は既に最大らしい
• AVX3-512, BFloat 16、その他の命令セットの実装
• 設計と製造の改良による性能およびPerformance per wattの向上

　このうち、Zen 4でのAVX-512サポートは既定路線であるが、bFP16は新しい話題である。
　以前も記事にしたが、2020年夏にAMD・Intel・Red Hat・SUSEによってx86-64-v2/-v3/v4標準が策定されており、Skylake-SPと同水準のAVX-512サポートはx86-64-v4の要件だからZen 4でのサポートは予想されていた通りである。

　とはいえ、AVX-512は実装が重いせいだろうがIntelも含め全命令をサポートしたプロセッサーは存在しないから、疑問はどの程度の水準でサポートされるかであろう。
　上述の通りZen4は恐らくx86-64-v4対応となるので最低でもSkylake-SPと同水準がサポートされることは予想されていただろうが、bFP16サポートとなるとAVX512VNNI・AVX512BF16がサポートされCooper Lake相当となる可能性が高いのではないか。WCCF Techの記事にはAVX512VNNIに対する言及は無いが、AVX-512でbFP16を使うのはAVX512BF16でbFP16がディープラーニング用のデータ型であることを考えれば、同じくディープラーニング用のAVX-512拡張であるAVX512VNNIがサポートされるのが妥当そうに思われる。

　ここで疑問なのはAVX-512がハードウェア的にZen 4コアに搭載されサーバー用＝Epycで使用可能になるとして、デスクトップ用＝Ryzenでサポートされるか否かであろうが、筆者はデスクトップでもサポートされると予想する。理由はZen4でAM5プラットフォームに移行しDDR5メモリーがサポートされるからである。
　Intelの場合はデスクトップ用CPUとサーバー用CPUは別ダイを使用しており、SkylakeとSkylake-SP・Coffee LakeとCooper Lakeがシリコンレベルで別仕様でも不思議ではないが、AMDはデスクトップ用でもサーバー用でも同じCCDチップレットを使いまわしてSKUを作っているため、物理的にはRyzenでも実装される可能性が高いが製品レベルでは非サポートとなる可能性は考えられる。
　しかし、そもそもAVX-512のサポートがデスクトップで消極的な理由のひとつはメモリー帯域（普通の積算・和算で1コアあたり64 Byte x 2のLoadと64 Byte x 1のStoreが必要）のはずで、Zen 4ではDDR5がサポートされるからメモリー帯域の問題は緩和されるはずである。
　例えば、聞くところによるとH.265エンコーダーであるx265でAVX-512を使ってエンコードなどをする場合にはXeonでなければメモリー帯域が不足していたらしい（DDR4-2666 x 6ch = 128 GB/s）。この帯域をDDR4対応のデスクトップ用CPUで実現することは不可能だが、DDR5対応デスクトップCPUでは近いバンド幅を実現でき、例えばDDR5規格で最速のDDR5-6400 2chは102.40 GB/sである。さすがにDDR4-2666 6chには敵わず問題が解消されたとは言い難いがギャップが大幅に緩和されていることは分かるかと思う。

　ところで、Zen 3では登場前にSMT4対応が予測され、本ブログではシングルスレッド性能低下を理由に否定したが、将来のどこかでSMT4が現実的になる可能性は高い。理由は実行ポートが増えておりシングルスレッド性能を犠牲にすることなくポート競合を防ぎつつSMTが可能になりつつあるからである。

　Zen 3ではLoad/StoreがLoad/Store-address + Store-dataに分離されたほかFPUからFP Storeも分離され、Branchが追加されたため、実行ポート数はZen 2の11ポートからZen 3では16ポートに増えた。
　SMT2のAMD Zenファミリー・Intel CoreファミリーCPUからSMT8のPOWER8/POWER9まで、SMTによるポート競合を避けるためスレッドあたりの実行ポート数がある程度確保されており、下の表の例では経験則的に概ね5～5.5-port/thread確保されているように見えるが、Zen 3は8-port/threadと頭一つ抜けている。
　もちろん、Zen 3で拡張されたポートは多機能のポートではなくStoreやBranchのみの単機能なので同列に比較はできない（し、Zen 3でSMT2が維持されたのも理解できる）が、5-port/threadを目安とすればSMT4で必要と想定される20 exec portsも視野に入ってくる。今のところZen 4でのSMT4のウワサは聞こえないがZen 5 かZen 6（いずれも仮称）あたりでサポートされる可能性はありそうに思える。
※初出時Sunny Coveのパイプライン構成が誤っていたため修正しました（2021/03/10）

	IBM POWER 9 (SMT8)		AMD Zen 3		AMD Zen 2		Intel Sunny Cove
SMT	SMT8	(per thread)	SMT2	(per thread)	SMT2	(per thread)	SMT2	(per thread)
L1$I (KB)	64 KB	8 KB	32 KB	16 KB	32 KB	16 KB	32 KB	16 KB
Exec Ports	44	5.5	16	8	11	5.5	10	5
ALU	8	1	4	2	4	2	4 (shared)	2
Branch	2	0.25	1	0.5	1 (shared)	(0.5)	1 (shared)	(0.5)
FPU	8	1	6	3	4	2	3 (shared)	1.5
SIMD	8	1
Load	8	1	3	1.5	3	1.5	2	1
Store-address	8	1			2	1	2	1
Store-data			2	1			2	1
L1$D (KB)	64 KB	8 KB	32 KB	16 KB	32 KB	16 KB	32 KB	16 KB

NVIDIAが組込SoCモジュールJetson TX2 NXを発表

NVIDIA introduces lower cost Jetson TX2 NX SO-DIMM module - CNX Software

　NVIDIA SoCファミリーはある程度馴染みがないと名称からGeForceの世代が分かりにくいが、Jetson TX2シリーズに搭載されるTegra X2 "Parker"ベースでGPUはPascal世代であり、Nintendo Switchにも搭載されているTegra X1 "Erista"（GPUはMaxwell世代）の後継にあたる。
　今回登場したJetson TX2 NXはJetson Nano/NXシリーズとしては新製品であるが、NVIDIA製SoCとしては2017年に登場した旧世代製品で、前回登場したJetson Xavier NXに搭載されているXavier（2018年発表）の前世代にあたる。

　SoCという観点で言えば、Tegra X2 "Parker"はNVIDIA製SoCがAndroidタブレット用モバイルアプリケーションプロセッサーから車載に転換した世代と言っていい。
　スペック表を見るとTegra X1の改良版のように見え、車載用のXavier（～32TOPS、10～30W）と比べると性能（1.3 TFLOPS）・消費電力（7.5W）は控え目でモバイルアプリケーションプロセッサーらしさも残るが、一方でCANなど車載向けのインターフェースの追加やメモリーインターフェースも128-bit化（LPDDR4で2パッケージ・DDR4で4チップが必要となり、フットプリントが増えるためモバイル用途では不利）などモバイル用らしからぬ仕様もあり、過渡期の製品に見える。電気自動車メーカーTeslaのAutopilot 2.0 - 2.5ハードウェアに搭載されたのもこのSoCである。
　これが、完全に車載に転換したXavierでは性能が向上・メモリーインターフェースが256-bitに拡張され消費電力が増えたほか、価格も大幅に向上し、モバイル向けには適さない仕様となった（組込SoCーは購入数量で価格が大きく変動するしサポート契約も含まれるため見積もりが難しいが、Qualcomm Snapdragon 800シリーズが概ね$50～60に対しXavierは$200を超えるはずである）。

　Jetson Nano/NXという観点で見ると、興味深いのはメモリー以外のスペックの削減が行われておらずダウングレードの幅が小さい点であろう。
　下の表はJetsonフルスペック版とJetson Nano/NXでのスペックの比較（相違点のみの抜粋）で相違点を太文字で示しているが、Tegra X1搭載のJetson NanoやXavier搭載のJetson Xavier NXでは、一部ブロックが大きくダウングレードされており性能と消費電力が低減されているのに対し、Jetson TX2 NXでは搭載メモリー容量以外はほとんど無い。メモリーの速度も1ランク低速なものに置き換えられているが体感できない程度の僅かなダウングレードである。
※CPUの項目を初出時から追加。尚、Jetson TX2 NXのCPUスペックは未公表だが、消費電力がJetson TX2と変化無いことから同一と推定（2021/03/10）

SoC	Tegra X1		Tegra X2		Xavier
SoM	Jetson Nano	Jetson TX1	Jetson TX2 NX	Jetson TX2	Jetson Xavier NX	Jetson AGX Xavier
CPU	Arm Cortex-A57 x 4-core 1.43 GHz (-18%)	Arm Cortex-A57 x 4-core 1.73 GHz	NVIDIA Denver 2 x 2-core 2.0 GHz Arm Cortex-A57 x 4-core 2.0 GHz	NVIDIA Denver 2 x 2-core 2.0 GHz Arm Cortex-A57 x 4-core 2.0 GHz	NVIDIA Carmel 6-core (-25 %) 1.4 GHz (-39 %)	NVIDIA Carmel 8-core 2.26 GHz
GPU	Maxwell 128-core 921MHz 472 GFLOPS (-53%)	Maxwell 256-core 1000MHz 1.0 TFLOPS	Pascal 256-core 1300MHz 1.3 TFLOPS	Pascal 256-core 1300MHz 1.3 TFLOPS	Volta 384-core (-25 %) 1100MHz (-20 %) 1.65 TFLOPS (-40 %)	Volta 512-core 1377 MHz 2.75 TFLOPS
DRAM	4 GB 64-bit LPDDR4 1600 MHz 25.6 GB/s	4 GB 64-bit LPDDR4 1600 MHz 25.6 GB/s	4 GB (-50 %) 128-bitLPDDR4 1600 MHz 51.2 GB/s (-15 %)	8 GB 128-bit LPDDR4 1866 MHz 58.3 GB/s	8 GB (-75 %) 128-bit LPDDR4X (-50 %) 1600 MHz (-25 %) 51.2 GB/s (-63 %)	32 GB 256-bit LPDDR4X 2133 MHz 137 GB/s

　Jetson Nano・Jetson TX2 NXはフルスペック版Jetson TX1・Jetson TX2が「型落ち」した後でリリースされているためハードウェア的な新規性も魅力もあまりないが、Jetson Nano登場以降ソフトウェアが拡張されており素人視点で使い易さが向上している。
　NVIDIA製SoCにはGPUとしてローエンドGeForce相当が搭載されており、GPUとしてだけでなくCUDAやNVENC/NVDECなども利用できるが、Jetson TX1・TX2が現役だった2015～2018年当時では使い勝手が良かったとは言えなかった。

　例えばNVIDIAのディープラーニング用ライブラリー群cuDNNなどは以前から同梱されておりCUDAでプログラミングする必要があったが、Jetson Nanoと共にJupyter WebインターフェースからPythonで利用可能となっているし、ほかにも、NVENC/NVDECを使った動画エンコード/デコード機能も、もともとAndroid用で一般的なOpenMAXのみのサポートで、利用するにはGStreamerを使用する必要があったが、昨年あたりからV4L2（Video4Linux2）プラグインが同梱されFFMPEGから利用可能になっている。

　本ブログではたびたびRaspberry Piや中華SBCといった組込SBCを取り扱っているが、それらと比べてNVIDIA製SoC搭載SBCの魅力はサポートではないかと思う。もっとも組込SoCで「サポート」というとソフトウェアパッケージのサポートとカスタマーサポート対応のサポートといった複数の意味があるが、本件の場合は前者のことを指す（後者についてはNVIDIAとやり取りしたことがないので不明）。
　Jetson向けの開発ソフトウェアパッケージ群はJetPackと呼ばれているが頻繁に更新されており、毎月のように新パッケージやドキュメントがリリースされているほか、BSPに相当するL4T（Linux for Tegra）も3カ月に1度程度の頻度で更新されている。

　また、意外に古いプラットフォーム向けのサポートも継続されており、例えば上記の中で最も古いJetson TX1は2019年EOL（終息）で開発ソフトウェアパッケージ（JetPack）のサポートも打ち切られそうな雰囲気があったが、2021年2月の最新版でもサポートが継続している（2015年～）。ちなみに、現時点ではJetson TX2 NXのサポートは2026年2月までが予定されているようだ。

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

AMD APU "Cezanne" と "Lucienne"

CezanneはRenoirをZen 3に置き換えただけでなくあちこち再設計されている - ASCII.jp

　ASCII大原氏がAMDのRyzen 5000 APUシリーズ"Cezanne"と"Lucienne"について解説されている。興味深いのは"Lucienne"が"Renoir"のリネームではなくZen2版"Cezanne"ということで、CPUコア以外も再設計されているという点だろう。"Lucienne"は"Zen2" CPUコアと"Vega" 8CU GPUコアの組み合わせということで"Renoir"のリネームあるいは"Renoir Refresh"と考えられてきたが、そうでなかったことになる。

	Ryzen 5000 Cezanne	Ryzen 5000 Lucienne	Ryzen 4000 Renoir
CPU	Zen3 8-core (1 CCX) 16 MB L3$	Zen2 8-core (2 CCX) 4+4 MB L3$	Zen2 8-core (2 CCX) 4+4 MB L3$
GPU	Vega 8CU	Vega 8CU	Vega 8CU

　このことは普通に考えればエンジニアリングリソースの無駄遣いである。"Renoir"はRyzen APU＝デスクトップ版Gシリーズ・モバイル版U/H/HSシリーズだけでなくRyzen Embeddedでも投入されており10年間ほどの供給義務が発生するため、恐らくはRyzen 5000シリーズをリリース後も"Renoir"を製造中止にするわけにはいかないだろう。ならばRyzen 5000シリーズは"Cezanne"のみとし"Renoir"を継続するかリブランドした"Renoir Refresh"を投入する方が自然に思える。"Lucienne"では電源管理が"Renoir"から大きく改善されているそうでAnandTechが詳しく報じているが、それで改善できるのは消費電力≒バッテリー寿命とかCPUやGPUのピーク動作周波数とかで、"Renoir"から設計を大幅変更までするのは不可解としか言いようがない。
　同様に不可解なのがVega GPUである。2017年発表の"Raven Ridge" APU・2019年発表の"Picasso" APUで"Zen" CPU（2017年発表）や"Zen+" CPU（2018年発表）に"Vega" GPU（2017年発表）が採用され"Navi" GPU（2018年発表）が採用されないというのは理解できるし、2020年発表"Renoir"で"Zen2" CPU（2019年発表）と"Vega" GPUを採用というのも解らないではない。しかし、2021年発表の"Cezanne"/"Lucienne"で"Zen3" CPU（2020年発表）に組み合わせるのが"Navi2" GPU（2020年発表）でも"Navi" GPU（2018年発表）すでもなく"Vega" GPUというのは合理的でない。ましてや、同じ論理設計・物理設計を使い回したならばともかく"Picasso"→"Renoir"→"Cezzanne"/"Lucienne"と論理設計も物理設計も変更されているにも拘らずである。

　ところで、筆者は先日投稿した記事中でAMDがAPUでGCN系GPUを続ける理由としてAPU/SoCでのROCmのためではないかと推測したが、筆者の推測が合っているか否かはともかく、そういった本来のAPUの用途（デスクトップ/ラップトップ クライアントPC用）以外を想定した何らかの目的でRDNAではなくGCNが選択されたと考えなければ合理的でないように思う。

　例えば、以前"Raven Ridge"/"Picasso"→"Renoir"ではCPUコアが2倍に増えた代わりにGPUを"Vega" 10CU→"Vega" 8CUとGPU CU数が20％削減されており、動作周波数を25％向上させることで性能向上を果たした。これは"Renoir"が製造コスト/実装コストに制約のあるラップトップ/ローエンドデスクトップ向けAPUの立ち位置を考えれば合理的に思えた。しかし、"Renoir"→"Cezzanne"/"Lucienne"では同じVega 8CUながら35％も実装コストは増えており辻褄が合わない（大原氏の試算を引用すれば「Renoirがおよそ11.2mm2、対するCezanneは15.1mm2ほど」らしい）。それならば例えば"Cezanne"/"Lucienne"では"Vega" 8CU→"Vega" 10CUに戻すといった判断があってもよかったはずである。
　また、そもそも論理設計や物理設計に手を入れるのであれば"Vega"ではなく"Navi"でもよかったはずである。PCWatch後藤氏の記事に詳しいが、RDNAはGCNから制御回りや演算ユニットがグラフィックスに最適化しており、実装コストあたりの演算性能は向上している。GCNでは1CUあたり4基の制御ユニットが4基の512-bit幅SIMDエンジンを制御してWavefront=2048-bitを処理していたが、RDNAでは1基の制御ユニットが1基の1024-bit幅SIMDエンジンを制御してWave1024=1024-bitを処理する形に改められ、さらにSIMDエンジンもゲーミング/グラフィックスではほとんど使用されないFP64演算のリソースが削減されている。つまり同じ実装コストならば"Vega"より"Navi"の方が性能的に優位で、"Renoir"/"Cezanne"/"Lucienne"（ラップトップ/ローエンドデスクトップ向けAPU）への搭載を考えれば"Navi"の方が適しているように思える。

　言い換えれば"Raven Ridge"→"Renoir"→"Cezzanne"/"Lucienne"として見た場合にはGPUの選択は非合理的で辻褄が合わない。財政的に好調なAMDが将来製品のためにラップトップ/ローエンドデスクトップ向けAPU以外の用途を考えており、APU/SoCで今後もGCN/CDNA系GPUを使い続ける意思があるためと考えるのが自然なように思われる。

　そこで筆者が先日述べた予想に戻すと、AMDはXilinxとの統合でNVIDIA Tegra/Xavier/"Orin" SoCに対抗する車載SoCに参入すると見ている。いかんせん未発表のためAMD+Xilinxのアプローチは不明だが、もしNVIDIA Tegra/Xavier/"Orin"と同様の路線をAMD+Xilinxの保有するIPの組み合わせで実現するとすれば、Xilinx VersalにCDNA系GPUを統合して実現するというのが最も簡単で理に適っている。AMD+XilinxはAMDのROCmとXilinxのXRTを統合した拡張版ROCmを計画しているとされ、ROCmからXilinxのIPを利用できるようになる。自動車にはカメラや赤外線レーダーなど様々なセンサーがあるからXilinx DSPを活かさない手は無いし、加工済のデータを機械学習で処理するにはDSPよりもAMD CDNAやXilinx AI Engineを使うのが理に適っている。

3D XPoint

「Intelじゃない3D XPoint」がメモリ市場を席巻か？ - TechTarget Japan

　TechTarget記事中の説明は合理的にも見えるが、実際の市況を見ていると現実は異なるように思う。3D XPointを擁するIntel/Micronが既に製品を投入して市場を開拓していて、その競合他社が市場に参入することは考えられるが、その時期や普及する規格については疑問がある。
　IntelとMicronは3D XPointを2015年に発表・デモを行っており、Intelは2017年にSSD・2019年にNVDIMMを発表している。つまりPRを開始してから実際に本命の製品を出す準備に4年間もの歳月を費やしている。もちろんSamsung/SK HynixなどがIntelと同様の行動をするとは限らないとはいえ、もし例えば再来年に製品を出すならそろそろ概要だけでも発表していなければおかしいだろう。

　ここで興味深いのはIntelよりもMicronの動きである。
　MicronはIntelと共同で3D XPointを開発したので、理屈上はIntelと同様に2017/2019年から製品を投入可能だっただろうが実際は2020年まで製品を市場に投入しなかった。その理由を推測してみると、まず (1) プラットフォームのチップセットやメモリーコントローラがコントロール下にあったIntelに対し、Micronはチップセット等を持っていないためNVMeキャッシュやNVDIMMといったプラットフォームが普及するまで製品を投入できなかったと考えられるし、また、 (2) Intelが勝手に膨大なコストを費やして市場を開拓してくれ、3D XPointの研究開発コストはIM Flashを通じてはIntelの売上の一部から回収できるので、Micronがリスクを冒して製品の市場投入を急ぐ理由はなかったからだろう。

　ところで、アナリストがNVDIMMの方がSSDより市場が大きいと見ているのは、個人的にはあまり納得できない。理由は、現在のデータセンターで最大級のプレイヤーがAWSやAzureのようなクラウドハイパースケーラーで、筆者の知る限りではAWSのアーキテクチャーでNVDIMMがマッチするインスタンスタイプは多くないからだ。

　筆者の知る限り、AWSは新技術をゼロから開発することはないが、他社が開発した新技術の導入と展開は早い。SR-IOVしかり・DPDKしかり・NVMe-oFしかりである。
　そのAWSはインスタンスにストレージの柔軟性を確保するためにNVMe-oFを使用することでブロックストレージ（EBS）をソフトウェア的にアタッチ/デタッチを行っているためNVMe接続でSSDを使用している。AWSのNVMe-oFのバックエンドの詳細は公開されていないが、AWS Nitroのプレゼンテーションスライドを参考にするなら、Annapurna Labs製SmartNICに直接NVMeでSSDが接続されているようだ（元プレゼンテーションスライド）。
　思うに、NVDIMMは速度と遅延では優位だがインターフェースと容量に制限があり、現時点ではクラウドの柔軟性に合わない。例えばXeon Silver "Cooper Lake"を考えてみると1ソケットあたりDDR4 6ch（最大12モジュール）とPCIe 64 lane（PCIe x4接続の場合NVMe SSD 16基）を搭載している。もしすべてOptaneで埋めるとすればNVDIMMは512GB x 12=6TBに対しPCIe/NVMeは1.5TB x 16=24TBを搭載できる。実際にはDIMMもPCIeもすべてOptaneで埋めるというケースは無いだろうが、PCIe/NVMeはインターフェースの柔軟さ・搭載容量の自由度で利点がある。また、NVMe-oFで使うのであればファブリックがボトルネックになりNVDIMMのPCIe/NVMeに対する利点は発揮されないため、NVDIMMを使うのはローカルで搭載する場合に限られるだろう。
　これらを総合的に考えると、仮に現在のAWSインスタンスタイプに当て嵌めるならばMemory OptimizedやStorage Optimizedのような一部のインスタンスではNVDIMMが使われるかもしれないが、それ以外のCompute OptimizedやGeneral Purposeなどでは今後もNVMe-oF経由でNVMe SSDを使う方が理に適っているように思われるし、NVMe SSDの方が今後も主流に残るのではないかと思う。