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

Intel GPU話題2トピック

Intel Xe-HPC "Ponte Vecchio"

Here Is Intel’s First 7nm GPU Xe HPC Diagram With Correct Annotations - WCCFTech

　Raja Koduri氏がXe-HPC "Ponte Vecchio"の写真を公開しメディア各社が報じているがが（ServeTheHomeの記事）、WCCFTechがアノテーションを付けたものを報じている。

　写真では点対称で左右にチップレット群が配置されており各25タイル（左右で計50タイル）がIntel EMIBおよびFoverosで接続されている。計8個のコンピュートタイルがFoverosで計4個のRambo Cacheタイルと接続されたクラスターがEMIBで4個のHBM2・1個のXe Link I/Oタイル・対象側のクラスターと接続されている。
　これらのチップレットの製造技術については以前のKoduri氏のプレゼンテーションでも説明されており、ベースタイルがIntel 10nm SuperFin・コンピュートタイルがIntel Next GenまたはExternal（おそらくTSMC）・Rambo CacheタイルがIntel 10nm Enhanced SuperFin・Xe Link I/OタイルがTSMCとされていたが、WCCFTechはそれらを写真に書き込んだ格好だ。ここで疑問なのはコンピュートタイルがIntel 7nmなのか？TSMC N5ではないのか？？という点である。10nm++ = 10nm SuperFinや10nm+++ = 10nm Enhanced SuperFinがわざわざ明記されている以上「Intel Next Gen」が示すのは7nmなのだろうが、「Intel Next GenまたはExternal」ならTSMC N5の方が現実的と思える（TSMC N5はApple A14・M1およびHuawei/HiSilicon Kirin 9000で実用化済である）。

　"Ponte Vecchio"の最初の搭載システムは米エネルギー省Argonne国立研究所Auroraの予定で、Intelのプロセス開発の遅延により昨年7月の発表では2021年後半～2022年前半に延期されている。このスケジュールでは"Ponte Vecchio"がテープアウト済で検証中である必要があるため検証中のエンジニアリングサンプル品がKoduri氏のTwitterに掲載されること自体は何の不思議も無いが、やはりIntel 7nmというのは個人的には疑問である。もしIntel 7nmが事実なら量産用のファブではなく試験用のファブではないかと勘繰ってしまう。

Intel Xe DG1

i740以来のIntelビデオカードがついに登場 - PC Watch

　IntelからdGPU製品DG1がリリースされたそうだ。
　DG1については性能面で不満があるため筆者はスルーする予定だが、今後出るGaming/Enthusiast向け＝Xe-HPGには期待している。

　筆者は仮想化好きな人間で自宅でも複数の仮想サーバーが稼働しているが、GPU仮想化（SR-IOVなど）を手軽に行えるGPUを入手できずに困っている。AMDやNVIDIAのGPUでは一部モデルでGPU仮想化が可能だが対応GPUやライセンスがコスト的な理由で個人で導入できそうにない。その点でIntel iGPUはSR-IOVできるという話を聞いたことがあるし、実際昨年11月に登場したデータセンター用Xe-LPでは仮想化できることが示されている。

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

QualcommがステルスモードのスタートアップNuviaを14億ドルで買収

Qualcomm to Buy Nuvia for $1.4 Billion - EETimes
Qualcomm to Acquire NUVIA - AnandTech

　Nuviaについては2019年にIntel Xeonを超えるサーバー向けCPUの開発を計画していると報じられたものの、そこから実製品が発表される間もなくQualcommに買収された。同社のblogによるとArmベースのCPUコア"Phoenix"を搭載する"Orion" SoCを開発中とされる。

　筆者はこのニュースを見て正直に言って驚いた。Qualcommはかつてスマートフォン向けにScorpion/Krait/Kryoと呼ばれるArm CPUコアを開発しており、その後サーバー向けにFolker CPUコアを搭載するCentriqを開発したが（2017年）、2018年にデータセンター部門を廃止し250人以上を解雇している。

　今回のNuvia買収の発表は、これまでのQualcommの方針とは異なっているように見える。また、データセンター向けArmプロセッサー市場は既存のプレイヤー＝Ampere・Marvellの動向を見ても将来有望な市場か怪しいところで、もしかするとNuviaのプロセッサーを車載など他の市場に転用することも考えられる。

Intelの最新プロセスとCEO人事

ゲルシンガー氏がIntel新CEOに指名 - PC Watch

　Intelについて複数のニュースが発表された。まずIntel公式が発表したCEO人事で現CEO Bob Swan氏が退任し、元Intel CTO/SVPで現VMware CEO Pat Gelsinger氏がIntel新CEOに就任するというもの、そしてTrendForceが伝えた2021年下半期より台TSMCがIntel Core i3などの製造を開始するというものである。

　この2件のニュースは当然ながら深く関連しているのだろう。
　Intelの10nm/7nm製造プロセスの遅延が何時から遅れたのか？部外者が正確に把握することは困難だが、昨年7月26日の投稿でも書いたが、公式の情報を参考にすると2016年に出荷が開始され・14nm++プロセスを置き換える予定だったのが、実際には2019年後半に出荷が開始され・一部製品でしか14nm++を置き換えられない（第10-11世代のモバイル用CPU 35W以下と、もうすぐ1-2 Socket向けXeonが登場予定）という状態に見える。
　2016年から引き摺っている問題の責任を2018年6月に就任したCEOに求めるのは酷だが、問題はもう一つのTSMCのニュースを考慮すると2020年まで方針転換を行わなかった点にあるのではないだろうか。2021年下半期から製造開始というスケジュールから逆算すると、物理設計と検証に各1年間を要するとしても～2020年下半期に物理設計・2021年上半期中にはテープアウト→検証（validation）ということになるが、それではCEOに就任した2018年6月から2019年下半期まで何をしていたのか？という話になってしまう。Swan氏は2016年からIntel CFOを務めた人物で、2016～19年の10nm製造プロセスの問題（歩留まりや10nm/7nm製造プロセスが発生させている損失の具体的な数字など）を幹部として見てきたはずにも関わらず、である。

　Swan氏以前のIntelのCEO人事を見るとIntel生え抜きの技術畑出身者で占められている。もし2016～19年の10nm製造プロセスの躓きを技術畑出身CEOの誤判断と仮定するなら、財務畑出身のCEOに求められることは、その変革だったことは想像に難くない。
　もちろん、最先端技術なので予定通りに技術が確立されるかなど分からないが、設計と製造・製品の製造と自社工場の製造技術とをそれぞれ切り離すことができれば、自社工場での製造技術の導入に失敗しても、最新の設計を製品の製造に適用することは可能だろう。より具体的には今回発表されたようなTSMCでの製造を1年前に行うことも可能だったはずである。

　個人的に気になるのは次世代7nm製造プロセスとそれ以降である。
　既報の通り、7nm製造プロセスは2022年まで遅延することは発表されているが、業界をウォッチしている人々の間ではIntelが10nm以降の製造プロセスでレースからの脱落したものと見做されているように思う。その理由は簡単で、7nm製造プロセスでは10nm製造プロセスで導入したCo配線に加えEUV露光を導入予定とされるが、蘭ASMLの発表などどの資料を読んでもIntelがEUV露光装置を大量発注したという資料が出てこない点にある。
　現在、ASMLのEUV露光装置は争奪戦状態でTSMCに優先導入・Samsungが数台導入という状態で、1年ほど先までのバックオーダーが積み上がっているとされているが（参考1・参考2）、どの資料を読んでもIntelが争奪戦に参加しているという話は無い。もちろん、Intelも恐らく製造プロセスの研究開発用にEUV露光装置を数台は導入しているのだろうが、とりあえず2022年中に大量生産を行うことはできない、あるいは、そもそも大量生産を行う気が無いということになる。

　ここからは筆者個人の予測であるが、2023年以降のIntelはTSMCかSamsung（以下まとめて「ファウンダリー企業」と記す）から製造技術をライセンス供与を受けて導入する形になるのではと思う。この方法であればEUV露光装置の導入に積極的でないことも説明が付く。まずファウンダリー企業が製造技術を確立してから同じ機器を導入することになるからである。
　もし今から2023年の製造に向けて準備する場合、TSMCでいえば現在量産中のN5ではなく次世代＝N3がターゲットとなる。TSMCは2020年末にN3向け装置搬入・2021年に試験生産開始・2022年に量産開始というスケジュールなので（参考）、もし仮にIntelがTSMCからN3のライセンスを受けて自社工場に導入する場合、Intelが製造装置を導入するのはN3の製造プロセスが確立される2021～22年・量産開始は2022年以降になる。もしライセンス元がSamsungの場合だとしても同様のスケジュールになるだろう。
　このことはファウンダリー企業・Intelの両方にメリットがある。まず、ファウンダリー企業がIntelとクロスライセンス契約を締結してライセンス供与することで自社の製造技術の改良やライセンス収入が期待できる。また、膨大な製造キャパシティーを必要とするIntelがファウンダリー企業の工場ではなくIntelの自社工場を使うことでIntelが必要とするウェハー処理キャパシティーを確保しつつ、逼迫気味なファウンダリー企業の製造キャパシティーを緩和できる。問題は、Intelが仮に逼迫気味なファウンダリー企業の製造キャパシティーの技術を導入するとしても、やはりASMLのEUV露光装置は必要ということで2022年までは機材が揃わないことになる。

NVIDIA Orin

NVIDIA Orin

NIO ET7 sedan will use four NVIDIA Drive Orin SoCs for automated driving and AI - NoteBookCheck
NIO Selects NVIDIA for Intelligent, Electric Vehicles - NVIDIA

　先日、中国の電気自動車メーカーNIOがを100kWhの全固体電池のバッテリーパック搭載モデルが航続距離1,000km以上を達成できるというET7を発表し一部で話題となった。というのも、これまで全固体電池の実用化が小容量のものしか行われていないからであるが、それとは別にET7の車載コンピューターについても報じられている。
　NoteBookCheckによるとNVIDIAの次世代車載SoC＝Orinを4基搭載し、合計でCortex-A78 48コア・256 3rd gen Tensorコア・8096 CUDAコアとなり1000TOPS以上を達成するのだという。

　NVIDIAは自動運転向けにTegra/Xavier SoCをもっており、次世代SoC=Orinは2019年に概要のみ発表済で2021年（サンプル出荷）～2022年（通常版の量産品）頃に登場するとされている。
　これまでNVIDIA Orinの詳細は未発表だったが、今回の発表からOrin 1基あたりCortex-A78 12コア・64 Tensorコア・2048 CUDAコアであることが分かる。これは2018年登場のXavierの後継としては無難なスペックに思える。

	NVIDIA Xavier T194	NVIDIA "Orin"	（参）Tesla FSD
CPU	NVIDIA Carmel x8	Arm Cortex-A78 x12	Arm Cortex-A76 x12
GPU	NVIDIA Volta GV10B 512 CUDA 7.2 cores 64 Gen 1 Tensor cores	NVIDIA Ampere 2048 CUDA cores 64 Gen 3 Tensor cores	Arm Mali-G71MP12
Accelerator	Deep Learning Accelerator Video Decoder Video Encoder	Deep Learning Accelerator (?) Video Decoder Video Encoder	NPU Video Encoder
Total DL Performance	30 TOPS (INT8)	200 TOPS (INT8)	73.73 TOPS (INT8)

　CPUはNVIDIA独自のCarmelからArm純正コアに置き換わっている。NVIDIAが現在もCPUコアの自社開発を継続しているのか不明だが、ラフに言ってCortex-A75以降のArm純正コアはNVIDIA製コアの半分以下のトランジスターコストで同等の性能を達成してしまっているし、元からNVIDIAはArm純正コアの採用に積極的なので不思議な事ではない（参考：Carmel x 8でダイサイズ350 mm^2のXavier・Cortex-A76 x 12でダイサイズ260 mm^2のTesla FSD。WikiChipの試算ではCarmelはTSMC 14nmプロセスで1コアあたり5.75 mm^2・Cortex-A76はSamsung 12nmプロセスで1コアあたり1.19 mm^2）。言い換えると、Carmel x8コアからCortex-A78 x12コアへの変更は、たとえ同じ製造プロセスでもコストを削減しつつ同等以上のパフォーマンスを実現できる。
　ところで、ASIL Dレベルの安全基準を満たすにはLock-step（2基のコアで同じ計算を行い突合してエラーを検出する）を実装する必要があると考えられているが、Arm純正のソリューションであればCortex-76AE/Cortex-A78AEが標準で対応しているが、今回の発表では「AE」は明記されておらず通常のCortex-A78なのか車載向けのCortex-A78AEなのかまでは分からない。

　個人的に気になるのはOrinに搭載されるGPUである（過去の例に倣うとGA10Bと呼ばれるであろう）。実はNoteBookCheckとNVIDIA公式BlogポストにはGPUについての記述に若干の違いがあり、前者ではGPUを「GA102のカットダウン版」と表現しているのだが、個人的にはこれは眉唾だと思う。
　自動運転向けSoCのGPUの用途はGPGPU/ディープラーニングである。一応カーナビゲーションシステムのディスプレイ表示もあるが、それだけなら1/2以下の性能（OrinのGPU性能がXavierの4倍とすると1.4 TFLOPS。1/2だと700 GFLOPS ＠FP32）で問題なくOrinを複数モジュールを使う必要は無い。実際、2019年にTeslaが発表したFSDの場合はArm Mali-G71MP12（600 GFLOPS @FP32）である。
　言い換えるとGA102の用途＝GeForce/グラフィックタスクよりもGA100の用途＝Tesla/科学演算に近いワークロードが想定されており、実際、前世代＝Xavierの場合もGPUはTesla V100と同じVolta GPUのカットダウン版である。GA100とGA102のアーキテクチャー上の違いについてはPC Watch後藤氏の記事に詳しいが、GA102よりはGA100のカットダウン版という可能性が高そうに思う。さらに言えば、Car Watchの記事で掲載されているプレゼンテーションでもOrin 2基と組み合わせて搭載されるディスクリートGPU 2基もGA100と思しきGPUが映っている。dGPUにGA100を選択してiGPUにGA100系ではなくGA102系のGPUを選択する理由は無かろう。

AMD + Xilinxは自動運転の夢を見るのか

　ところで、AMDは同社のローエンド～ミッドレンジ向けにCPUとiGPUを搭載したAPUを供給しているが、iGPUがVegaであることがたびたび話題となっている。
　この理由についてはスケジュールの都合でVegaになったという見方が主流で（参考）、ほかにメモリー規格による性能の問題（参考）が囁かれているが、筆者の推測ではROCmへの対応のためではないかと思う。

　AMDはコンシューマー向けAPUと同じダイをRyzen Embeddedとして組込向けに供給しているが、RDNA=NaviはROCmに対応しておらずGCN/CDNAが必要になる。もしRyzen Embeddedを上述のNVIDIA Xavier/Orinように組込でGPGPUを実現するユースケースを想定するのであればAPUにRDNAを持って来ることができない。つまり、筆者の推測ではAMDはRyzen EmbeddedでROCmが必要なので消費者向けローエンド～ミッドレンジ向けAPUにもVegaが搭載されている。

　もちろん、せいぜい$100程度のローエンド向けAMD APUと$400前後もするNVIDIA SoCとを同列に並べることはできないが、もしAMDがXilinx買収でNVIDIA SoC対抗製品を企画するとすれば、AMDの自社製APUとXilinxが展開しているZynq UltraScale MPSoC・Versal SoCとを統合しGCN/CDNAをAPU/組込SoCにもたらす可能性がある。ちなみに、Xilinx SoCが対応しているXRT（Xilinx Runtime）は将来の拡張版ROCmに統合される予定とされている。もちろん、さすがにZynq UltraScaleもVersalもそのままではNVIDIA SoCには対抗できないが、Vega/CDNAを組み合わせれば要素技術は一通り揃っているように思われる。

	Zynq UltraScale+ MPSoC	Versal
CPU	Cortex-A53 x4 Cortex-R5 x2	Cortex-A72 x2 Cortex-R5 x2
GPU	Mali-400MP2	-
Accelerator	FPGA DSP48E2 H.264/H.265	FPGA DSP58 AI Engine

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

USB3接続5GBASE-Tネットワークアダプター

USB 3.1 Gen1 to 5GbE Network Adapter Guide - ServeTheHome

　ServeTheHomeがUSB3接続5GBASE-Tネットワークアダプターについてレビューを掲載している。この記事では「USB 3.1 Gen1」となっているが、消費者から見ると実質的にはSuperSpeed USB = USB 3.0 = USB 3.1 Gen 1 = USB 3.2 Gen 1x1であり、USB 3.1 Gen 1はUSB 3.0を置き換える規格である。本稿では元記事に倣い「USB3.1 Gen 1」で統一する。

　NBASE-T策定の経緯についてはInternet Watchなどに詳しいが、恐らく業界としては1000BASE-Tの次は10GBASE-Tと想定していたのだろうが、1000BASE-Tが1999年に規格化され2005年頃には広く普及していたのに対し、10GBASE-Tは2006年に規格化された後もPHYが厄介で未だに普及していない。その一方でWi-Fiのbackhaulなどの用途で1 Gbpsでは帯域が不足してきており、そこで2016年に10GBASE-Tをベースに信号速度を落としPHYを簡略化して策定されたのがNBASE-T（2.5GBASE-T・5GBASE-T）である。10GBASE-Tは14年を経た今でも巨大なヒートシンクが必要でポート単価$100ほどするが、2.5GBASE-T・5GBASE-Tは登場から間もない段階でポート単価がそれぞれ$20～30・$40～60程度となっている。

　従って、ServeTheHomeのレビューではUSB3.1 Gen1接続の5GBASE-T対応製品のみを扱っているが、類似の製品としては2.5GBASE-T対応製品もある。
　USB 3.0/3.1 Gen 1の信号レベルでの理論上の転送速度が最大5 Gbpsのため5GBASE-Tネットワークアダプターは、PCIeポートやThunderbolt/USB 4ポートを持たないラップトップPCや小型PCなどでは実質的に最高速のネットワークアダプターということになる。

　同種の製品は各社から発売されておりServeTheHomeの記事に掲載された製品以外に日本でもPlanexの5GBASE-T対応製品やBuffaloやPlanexの2.5GBASE-T対応製品が存在しているが、実は中のネットワークコントローラーは5GBASE-T対応製品はMarvell/旧Aquantia AQC111U・2.5GBASE-T対応製品はRealtek RTL8156で共通している。他に旧AquantiaでAQC112Uという2.5GBASE-T対応コントローラーも存在するのだが…恐らく価格のせいで搭載製品を見たことが無い。

　実は、USB3.1 Gen 1接続のネットワークアダプターでは理論上でも5 Gbpsに達しないため、5GBASE-T規格のアダプターだからといってベンチマーク結果を見るまでもなく5 Gbpsは達成できない点には注意が必要である。
　まず、USBという観点で見ると3.1 Gen 1のエンコーディングが8b/10bのため5 Gbps PHYでもデータ帯域は500 MB/s（4 Gbps）である。また、USBはホスト-デバイス間でパケット通信が行われるためデータパケットのヘッダやCRC-32などの20 Bytesのオーバーヘッドがあり最大1024 Bytesのパケットの場合でペイロードは最大1004 Bytesとなり最大490 MB/s（3.92 Gbps）である。さらに、ネットワークという観点で見ればホストコンピューター-USBネットワークコントローラーでやり取りされるIPデータグラムはTCP Header 20 Bytes + IP Header 20 Bytesの計40 Bytesのオーバーヘッドが含まれるから、これらオーバーヘッドを全て除外すると9000 Bytes Jumbo Frameの場合で最大488 MB/s（3.90 Gbps）の帯域が得られる計算になる。記事中ではiperf3（TCP）で測定しているため、測定結果は理論値の最大でも3.90 Gbpsを超えることは無く、実際にはこれより劣化することになる。
　そう考えると、ServeTheHomeのiperf3測定で3.45 Gbpsという実測結果は、5GBASE-TのTCPレベルでの転送速度（最大4.97 Gbps）に対し理論値の約69.30％でしかないが、USB 3.1 Gen 1接続であることも考慮すると理論値の約88.46％を達成していることになり悪くない数字のように思う。

　こうなってくると気になるのは2.5GBASE-Tとの性能差である。なにせ上記の通り5GBASE-Tの場合はUSBがボトルネックとなって理論上でも最大3.90 Gbpsに制限されているが2.5GBASE-TではUSBはボトルネックとならないからである。
　同じServeTheHomeの記事でSabrent NT-S25Gのレビューが掲載されているが、これによると約1.9 Gbps程度のようだ（ただし測定方法も正確な測定値も不明瞭）。つまりUSBという接続形式による制約を考えず規格上の転送速度で比較すると、5GBASE-TのアダプターではTCPレベルで最大4.97 Gbpsで3.45 Gbps（実効約69.30％）に対し2.5GBASE-TのアダプターではTCPレベルで最大2.49 Gbpsで1.9 Gbps（実効約76.33％）を達成していることになる。
　個人的にはUSB3.1 Gen 1の性能を活かす意味で5GBASE-Tのアダプターを推したいところであるが、現状では2.5GBASE-T対応アダプターと5GBASE-T対応アダプターの価格差は無視し難いものがある。そもそも、ネットワーク機器の常として1台分だけ買い換えても意味が無くハブや対向の装置のアダプターも替える必要が出てくるため、アダプター単品で見れば$20～30程度の価格差でもネットワーク全体で見れば差額は巨大になる。恐らく用途によって使い分けることになるだろう。

「ほんとにあった半導体業界のハナシ」について

ほんとにあった半導体業界のハナシ - マイナビ

　元AMDで営業を担当されていた方のコラムであるが、一部、私の理解とは違う印象である。

　Appleの自社製CPU製造・Macへの搭載の経緯についてであるが、当初Samsungを採用した経緯についてはITMediaに大原氏の記事があるが、そちらの方が正確に思える。
　まず、AppleはiPhone以前からNewton（1993年）やiPod（2001年～）でArmプロセッサーの採用実績があり（AppleはArm前身のAcornの初期の出資元の1社である）、iPhoneの開発にあたってSamsungが既に持っていたArmベースの携帯電話用SoCをAppleがカスタマイズして採用した。iPhone以前からSamsungは自社製品＝テレビ・セットトップボックス向けSoCだけでなく携帯電話向けにもSoCを開発しており、WikipediaにAシリーズのリストを見てもA4以前は完全にSamsung S3C/S5L/S5P SoCの系譜である。また、A4～A5/A5XまではAppleも独自IPは持っておらず搭載するArm製CPUコアやImagination製GPUコアの既成のIPを変更していたにすぎない。例えば2011年のSamsung Exynos 4/Apple A5ではCPUは共通で、Samsungは自社向けExynos 4でGPUに9.6 GFLOPSのMali-400を採用しているがAppleはA5で12.8 GFLOPSのPowerVR SGX543MP2を採用といった具合である。だから、「Samsungが当時ケーブルTVのセットトップボックス用に使用していた統合型CPUをベースに設計した」という表現は適切でない。
　また、AppleはA6/A6Xで初めて採用した自社製CPUの開発にあたり、P.A.Semi（2008年）とIntrinsity（2010年）とを買収したが、CPUアーキテクチャーに強いP.A.Semiに対しIntrinsityの強みは物理設計にある。Intrinsityは高速駆動の物理設計のスペシャリストで例えばIBMが～500 MHzで動作させていたPowerPC 400シリーズをAMCCと共同で2 GHz動作させたりしている。Samsung/Apple共同開発のApple A4には1.0 GHz駆動のArm Cortex-A8が搭載されているが、これはAppleに買収される前のIntrinsityとSamsungが共同開発した高速駆動版Cortex-A8 "Hummingbird"である。つまり、2011年頃の時点でスマートフォン向けSoCでノウハウを持っていたのはAppleではなくSamsungである。だから「Samsungはスマートフォン用のSoC設計のノウハウを生かして独自のCPUを開発しAppleが激怒した」というのは言い掛かりに近い。

　また、Intelがx86アーキテクチャーベースのスマートフォン用プロセッサーの開発に失敗したのは事実ではあるが、記事中にある「Appleをはじめとする他のスマートフォンメーカーが相次いで採用したのでArmはこの市場での標準アーキテクチャーとなった」というのは順序が逆である。
　スマートフォンやその前身の高性能PDAでArmが支配的となったのは2000年頃のMicrosoft PocketPCの時代である。ほかにPDA用プロセッサーとしては旧Motorola MC68KやMIPSもあったが、2002年頃にはIntel XScale・Arm Arm11といったArmアーキテクチャー以外は淘汰されており、例えばSharpが2005～08年頃に発売していたW-Zero3なども例外なく全てArmである。iPhoneが登場した2007年・Androidが登場した2008年時点ではArm以外の選択肢は無かったと言っていい。

　XBoxのCPUが発表直前にAMD K7からIntel Pentium III（スペックはCeleronであるが、Intel/MicrosoftはPentium IIIと呼んでいる）へと変更となったことについてはPC Watch後藤氏の2002年の記事でも既報であるが、内容が若干異なっている。明日論氏は「IntelがMicrosoftに強力な圧力をかけ最後の土壇場でメインCPUをAMDからIntelに変更させたらしい。どうやらIntelがとんでもなく低い値段を提示した」とするが、後藤氏は「AMDの方がオファー価格は安かったが、AMDがMicrosoftにFabへの投資とギャランティを求めたため」としている。どちらも正しいとすると、CPU単体ではAMDの方が安かったが、AMDは製造設備に不安がありMicrosoftにFabへの投資を求めたため、総合的にIntelの方が安かったということではないかと思う。

最近の気になった話題（2020年第51週）

GoogleがChromium OSベースCloudReadyの開発元を買収

Google、古いPCでChrome OSを動かせるCloudReadyのNeverwareを買収 - Engadget 日本版

　GoogleはChrome OSと、Chrome OSを搭載したChromebookを推進しているが、オープンソース化したChromium OSも提供している。
　Chrome OS/Chromium OSでは処理の多くをサーバー側で行うコンセプトのため軽量で、低性能なシンクライアントや古いPCの再利用への流用も可能と考えられる。そのためCloudReadyをはじめサードパーティーから幾つかのChromium OSベースのディストリビューションが登場している。もっとも、これらのディストリビューションではGoogleの認証を受けていないためAndroid用アプリケーションやPlay StoreをはじめとするプロプライエタリーなGoogle Appsを利用できないという難点がある。

　そんなサードパーティーChromium OSの雄CloudReadyの開発元であるNeverwareがGoogleに買収されたらしい。NeverwareおよびCloudReadyはChrome OSチームの一部となるが、CloudReadyについては当面の間は現行の製品はそのまま利用できるのだという。

　個人的にはGoogleの意図がよく分からない。もしCloudReady無償版が今後も提供され、GoogleによってGoogle Appsやサポートが提供されるのであれば個人的には好ましいことに思えるが、AndroidベースのサードパーティーOS（例：CyanogenMod/Lineage OS）を含め、Googleがアフターマーケット向けにOSを提供したりGoogle Appsの提供を行ったことは無い。

　Androidの場合、WikipediaのCyanogenModの記事には以下のようにある。Androidでの経緯を踏まえるとGoogleがサポートの付いたChromeOSやプロプライエタリーなGoogle Appsをアフターマーケット向けに提供するとは考え難い。

（前略）GoogleがCyanogenに対し、前述のアプリケーションをディストリビューションに含めないように警告したあと、数日間開発が停止した。（中略）Googleの立場を明確にした前述の声明と、その後のGoogleとCyanogenとの交渉により、プロプライエタリな“Google Experience”コンポーネントをバンドルしない形で、CyanogenModプロジェクトが継続できるという決着を見た。（中略）これは、プロプライエタリなGoogle製アプリケーションがGoogle提供のファームウェアからバックアップされ、権利を侵害していないCyanogenModに再インストールされてもよい、ということを示した。（後略）

個人のアフターマーケット向け以外とすると、教育機関向け・大企業のシンクライアント向けの展開を加速するためではないかと想像する。インフラのクラウドへの移行や内部統制などの兼ね合いもあり学生や労働者の使用する端末はシンクライアント化が今後も進むはずで、Chrome OS/Chromium OSは都合が良い。
　従来のGoogleのChrome OS事業はIntel・AMD・RockChipなどの半導体ベンダーやSamsung・Acerなど端末ベンダーと協力して端末にプリインストールして販売することだったが、Neverware/CloudReadyの取得はChrome OS/Chromium OSサービス事業の取得と見做すことができるわけで、Lenovo/Dell/HPEなどのインテグレーターが企業・学校に販売する場合にChrome OS/Chromium OSを通常のPCベースのマシンにインストールしたり、Neverwareを通して管理ソフトウェアを展開することが可能になるのではと思う。

GPD WIN MAX・WIN 3

スライダー式になった5.5型Windowsゲーミング機「GPD WIN 3」の全貌 - PC Watch
GPD WIN MAXはSteam専用スイッチ！積みゲー消化が捗る - Engadget 日本版

　先週の話であるが、PC WatchによるとGPD WIN 3が発表されたそうだ。
　WIN MAXとWIN 3とでは形状もスペックも異なる（ディスプレイサイズもWIN MAX 8-inchに対しWIN 3 5.5-inchと大きく違う）から単純比較はできないがWIN MAX（Core i5）がIndieGoGoキャンペーン価格$780・正規価格$900に対しWIN 3はIndieGoGoキャンペーン価格$829（Core i3）/$969（Core i7）というのは興味深いところだ。

　GPD製品を見ていると興味深いのは外観が昔のSony VAIO type Uに似ている点と、VAIO type Uに似ているにも関わらずゲーミングPCを謳っている点だろう（当然ながらVAIO type UはゲーミングPCではなかった）。
　WIN MAXは2002年に登場したVAIO U「PCG-U3」に似たスティックとボタンをキーボード奥に備えているが、今回のWIN 3は2006年に登場したVAIO type U「VGN-UX1」によく似たスライド機構をもっている。ちなみにWIN 2についてはそのものズバリという機種は見当たらないが、筆者は個人的に配色やキートップ中央が膨らんだ樹脂製のキーボードなどLogitech diNovo Miniに似ていると思っている。diNovo MiniはHTPC用（リビングルームPC用）のリモコンサイズの無線キーボードで、一部でDell StreakとペアリングしてUMPCのような使い方をした例が存在するので、そこからヒントを得たのでは？と邪推している。

　GPDが、VAIO UMPCに外観が似たPCをゲーミングPCとして位置付ける意図は不明だが、性能的な都合でSonyがVAIO type UをゲーミングPCに位置付けられなかったことは間違いない。
　VAIO type Uが高価で低性能だったことは当時の技術的な水準からすれば仕方のないところである。当時のPCではCPU・VGAアダプター・North BridgeとSouth Bridgeの2つのチップセットで構成される4チップソリューションが一般的で、PCG-U1/U3で採用されたTransmeta CrusoeはCPUとNorth Bridgeとが統合され当時としては画期的な低消費電力と省フットプリントを実現したが、それでもCPU・VGAアダプター・South Bridgeの3チップ構成だったし、VGN-UX1の頃にはVGAアダプターがNorth Bridgeに統合されたが依然としてCPU・North BridgeとSouth Bridgeの3チップ構成だった。消費電力が大きい複数個のチップが高速バスで接続されるだけあり多数の電子部品が複雑かつ高密度に集積されている（参考：VAIO PCG-U1・VGN-UX50）。
　それに比べれば、昨今は各種コントローラーの集積度の向上と統廃合が進み、昨今のIntel H/U/Yモバイルプロセッサーであれば1パッケージでCPU・GPU・チップセットがすべて集積されているので基板は実に簡素である（2002～06年当時と比較すれば）。

　筆者の推測では、GPDがゲーミングを謳うのは (1) 売るため (2) UMPCはサイズが携帯ゲーム機に近いためだろう（中国の御国柄や中国人の趣向という話もあろうが）。
　UMPCはその使い勝手の悪さからもともとセカンドPCという位置付けが強かったが、PCが3万円～・PC1人1台以上という現代ではより顕著で初めてのメインPCにGPD機を選ぶ例は稀だろう。そのような環境下で消費者に約$900/約10万円ものコストを支払ってまで買わせようと思った場合、小さい・軽い以外で差別化要因が欲しいところで、昨今のゲーミングPC市場の動向や、UMPCと携帯ゲーム機の類似性も併せて鑑みれば、UMPCをゲーミングPCとして売り出すことは妥当そうに思える。
※とはいえ、今更SonyなりVAIOなりがVAIO type Uを復活させてもビジネスにはならず、中国の中小企業ならではと思うが。ちなみにオリジナルのVAIO type Uは概ね20万円前後だった。

　ところで、WIN 3の特徴の一つとしてVGN-UX1と同様にドックが標準添付であることが挙げられる（VGN-UX1の場合はポートリプリケーターと呼んだようだが。参考1・参考2）。
　筆者の場合、在宅時はWIN MAXをUSB-C / HDMI Alt Mode対応ドックに接続してデスクトップPCのように使用しており、そのような運用であればドックの標準添付は好ましいことではないかと思われるが、個人的にはWIN MAXにも専用の小型ドックを用意してもらいたかったところである。筆者は (1) 安価（$30前後）(2) HDMI 2ポートという要件から別途AliExpressで購入し満足しているが、GPDならWIN MAXに合った専用モデルを作れたのではと思う。

ARMの話題 二題

Apple M1搭載Macで動作するParallels上のWindows on ArmはQualcomm搭載のSurface実機より速い

M1 MacBook is capable of running Windows on ARM faster than a Surface Pro X - NotebookCheck

　これはApple M1対応Parallelsの登場によって可能になったテストだと思うが、Windows on Armは一般販売はされていないのでWindows Insider Programの開発チャンネルあたりのもの（つまり最終版ではなさそう）を流用したと思われ、妥当性については検証の余地がありそうだ。
　もっとも、ロジックの規模から推定するにSurface Pro Xに搭載されているCortex-A76の性能は概ねIntel Atom系コアと同クラスで、Intel Core系コアやApple AシリーズのBigコアのクラスと比べると大雑把に言って半分程度のIPCと考えられるから、この結果は概ね妥当だろう。Parallelsの仮想化方法はよくわからないがホストとゲストとでCPUの命令セットが同じで変換の必要は無いからオーバーヘッドも大きくは無いだろう。

　もっとも、AndroidやiOSのスマートフォン/タブレットではCPU性能よりもアクセラレーターに処理をオフロードすることが重要で、Snapdragon搭載端末がExynos搭載GalaxyやiPhoneを上回っているベンチマークは概ねアクセラレーターも含めた総合的な速度で上回っている（※注：典型的なPCでの処理はほぼCPUのみで、グラフィックタスクをGPUにオフロードしている程度である。つまりプロセッサーの使い方が違う）から、スマートフォン由来のプロセッサーを流用したPCでCPUのシングルコア性能・マルチコア性能にどの程度の意味があるのか、ユースケースも含めて検証する必要はありそうだ。

　ArmプロセッサーベースのMacの搭乗前、筆者は個人的にWindows on ArmをMacにBootcampで起動可能になってから移行するのではないかと思っていたが、御存知の通り結果的にはAppleはWindows on Armを実行可能とせずにArmプロセッサーベースに移行している。Appleのソフトウェアエンジニアリング担当上級副社長Craig Federighi氏はMac以外のOSでブート可能とすることを否定しているそうで、MicrosoftがParallelsで実行可能なWindows on Arm版Windows 10を単体でリリースするか興味のあるところである。

Ampere Altra

The Ampere Altra Review: 2x 80 Cores Arm Server Performance Monster - AnandTech

　AnandTechがAmpereの80コアAltraの性能について報じている。
　Altraはそれ以前のAppliedMicro・Ampereの方針とは異なりArm純正のNeoverse N1プラットフォームに基づく。既存のNeoverse N1プラットフォームベースのプロセッサーとしては最大64コアのAWS Graviton 2が存在する。

　AnandTechでのAltraの写真を見ると、外観から恐らくSamsung 8nmプロセスで製造されていることが伺える（TSMC 7nmとする資料もあるが…製造国KoreaとあるからSamsungだろう）。いくらArmコアが比較的小さいとはいえ80コアともなると巨大なダイになるからMCM構成にする方が歩留まりの観点から良さそうに思えるがメモリーサブシステムと遅延の記事を読む限りモノリシックダイのようだ。
　圧巻は各8チャンネルのメモリーとソケットあたり128 laneのPCIeだろう（いずれもAMD Epycとほぼ同等である）。まだまだSerialATA/SASは現役で使用されているがNVMe SSDの普及でPCIeは多過ぎることが無くなりつつある。AnandTechの記事ではAmpereのリファレンスデザインのサーバーを用いているが2.5インチドライブベイ24ベイが装備されている。もし仮にNVMe x4 U.2 2.5インチSSDで埋めるとすれば計96 laneが必要になる（Altra 2ソケット＝192 laneであれば一応実現できそうだ）。

　Arm Neoverse N1のIntel/AMDプロセッサーに対する利点は、消費電力の低さと集積できるコアの密度の大きさだろう。Neoverse N1/Cortex-A76（論理的にほぼ同じコアである）はIntel Core系コアと比べ概ね半分程度のサイズで半分程度のIPCである。言い換えればNeoverse N1 80コア構成（80C/80T）はIntel Xeon/Core 40コア構成（40C/80T）とほぼ拮抗するが、シングルスレッド性能ではIntel Xeon/Coreが有利な反面、マルチスレッド性能ではNeoverse/Cortex-A76が有利になる可能性がある。
　もともと、Intel Xeon・AMD Epycでは、メモリー遅延ではモノリシックダイのXeonが有利・マルチスレッド性能では多コアのEpycが有利という関係であったが、Altraは多コアのモノリシックダイということでちょうどXeonとEpycの間に入りそうなスペックで、ベンチマーク結果もそのような特性が見て取れる。
　確かにスペックからもベンチマークからも見て取れるように、AltraはXeonやEpycに匹敵する性能を持っているが、個人的な疑問は既存の資産を活かせるx86-64=Xeon/Epycを捨ててまでArm64=Altraを採用するメリットが解かり難い。AWSが同じNeoverseベースのGraviton 1/Graviton 2を採用したりOracleがOracle CloudでAltraを採用しているように、低消費電力（→低TCO）が重視される環境やCPUアーキテクチャーが重視されない環境（例：AWS Lambda）ではArm64も採用は進むだろうが、ある程度限定的ではないかと思う。

　個人的に疑問なのはAltraのコア間インターコネクトである。
　Neoverse N1でCPUコア間を接続するCMN-600メッシュネットワークで32個のタイルを相互接続できる。最大64コアのGraviton 2の場合は2コア/タイルであるが、最大80コアのAltraの場合は4コア/タイルとなるのでオンチップネットワークがボトルネックとなる可能性がある。また、AltraはAnandTech記事中のような2ソケット構成ではPCIe Gen 4の物理層を使った32 laneのCCIX互換接続を行っているが、これはAMD EpycのIFIS（Infinity Fabric Inter Socket）の64 laneの半分の帯域である。

　個人的な想像だが、Ampereは突貫工事でAltraを作ったのではないか、そのせいで仕様が洗練されていないのではないかと推測している。
　理由はAnandTech記事中にもあるコード名＝QuickSilverは元は恐らく別の仕様だったからだ。AmpereはAppliedMicro（を買収したMacom）が独自に開発していたX-Geneを2017年末に買収して設立されたが、2019年半ばまでの発表資料を見てもArm純正プラットフォームを採用するという資料は存在しない（というか、～2019年までにその計画があったのであれば、そもそも大金を投じてX-Geneを買収する必要が無かったはずである）。そこから2019年12月にQuickSilverが最大80コアであることが示され、2020年2月にNeoverse N1を採用したAltraが発表されたから、2019年半ばまでに方針転換されたのだろうと推測できる。この推測が正しいとすると、方針転換から18～24カ月程度でサーバー向けチップをリリースしていることになり、かなり短期間で完成させた可能性がある。

最近の気になった話題（2020年第49-50週）

RISC-V関連 話題二選

SeagateがRISC-V CPUコアを発表

Seagate Designs RISC-V Cores to Power Data Mobility and Trustworthiness - Seagate

　Seagateが開発したCPUコアには「area-optimized core」と「high-performance core」があるようだ。
　HDDコントローラーに搭載されているCPUコアについては情報が出回っておらず、恐らくSSDコントローラーで主流なのはArm Cortex-Rだが、Western Digital（WD）とSeagateのHDD大手二社はRISC-Vを選択したようだ。WDについてはSiFiveとEsperanto Technologiesへの投資や独自CPUコアSweRV（GitHub）で既知だったが、SeagateもRISC-Vに移行し、しかもCPUコアから開発していたというのは驚きである。

　WDはSSDコントローラーを自社開発しているほか、Seagateも旧SandForceをAvago（現Broadcom。SandForceを買収したLSI Corpを買収した）から取得しているため、WD・SeagateともSSDコントローラーは内製品を使っている。大手SSDベンダーはコントローラーの内製化に取り組んでおり、SK Hynixは2012年にLink_A_Media Devices（LAMD）を買収したほか今年11月にIntelからSSD資産を買収（SK Hynixと親会社SK TelecomはSiFiveにも投資している）・Micronも2019年に発表したMicron 2200 SSDで内製のコントローラーを発表している。

　個人的に疑問なのは、コントローラーやコントローラーに搭載されるCPUコアまで内製する必要があるのか？という点である。
　Hisa Ando氏の記事によるとWDは年間1B個のCPUコアを使っているそうでロイヤリティーが馬鹿にならないのは理解できるのだが、ロイヤリティーフリーが良いのであればUC Berkley BOOMもあるしサポートが必要であればSiFiveやAndesという選択肢もある中で、給料の高いCPU開発者を雇ってまで内製する必要があるのか？と疑問である。
　ちなみに、日本では10月にRenesasがAndesからRISC-V CPUコアのライセンスを受けることを発表している（率直に言うとRenesasこそ独自RXを止めてRISC-Vを内製した方が良いと思うのだが…Armの採用も2019年だったし、どうもズレている感じがしてならない）。

Esperanto TechnologiesがET-SoC-1を発表

Esperanto Unveils ML Chip with Nearly 1,100 RISC-V Cores - HPC Wire

　Esperantoというと、元Sun/TransmetaのDavid Ditzel氏が率いるRISC-Vベンチャー企業で、3年前の2017年11月には4000コア超のプロセッサーの開発を発表するなどして目立っていたが、これまで実チップが出てこなかった。

　今回の発表では同社の高性能ET-Maxion 4コア・高効率ET-Minion 1088コアという2種類のコアを搭載・238億トランジスターを集積したSoCテストチップをダイ写真付きで発表した。ET-SoC-1はPCIe 4.0接続の機械学習アクセラレーターとして使用でき、記事中ではM.2接続のGlacier Pointでの接続例が掲載されているが、製品レベルでのチップは完成していないようで性能は示されていない。RISC-VにはVector拡張はあるが機械学習で多用されるMatrix演算は無いので、多数登場している専用アクセラレーターASICと比べて汎用ET-Minion 1088コアが高速なのか疑問である。

　2017年の記事ではET-Maxion 16コア・ET-Minion 4096コアをTSMC 7nmプロセスで集積する計画を示していたが、1チップでの実現は恐らく無理そうに思われる。
　今回のET-SoC-1は、上述の通りET-Maxion 4コア・ET-Minion 1088コアという2017年の計画の約1/4の構成であるが、TSMC 7nmプロセスで238億トランジスターという巨大なプロセッサーになっている。現在のTSMC 7nmで最大級のNVIDIA A100ですら542億トランジスターで826 mm2なので、4000コア超（約900億トランジスター？）を1チップに集積するのは恐らく不可能で、ET-SoC-1を4チップMCM構成にするか、TSMC 5nmを待つ必要があるのではと思われる。

TechSpotのNVIDIA GPU vs AMD GPUまとめ

Nvidia Ampere vs. AMD RDNA 2: Battle of the Architectures - TechSpot

　技術的な内容やニュースとしての目新しさは無いが、現行製品の比較としては面白い。
　Navi 21は通称「Big Navi」と呼ばれ、確かにNavi 10やVega 20と比較すれば圧倒的に巨大であるが、NVIDIA GA102より20％・GT102より45％ほども小型で、いかにNavi 21/Radeon RX 6800が省コスト・高性能であるかよく分かる。これらは数値的なデータとしては知っていたが写真付の図解はなかなか興味深い。

AWS Macインスタンス

Amazon EC2「Mac インスタンス」ラックのMac mini公開 - AWS re:Invent 2020 - マイナビ

　AWSがMac（Intel）インスタンスを発表したそうだ。
　Mac Miniをそのまま使用しているということで様々なメディアで取り上げられたが…恐らくはMac Mini以外でもあまり意味が無いという判断ではないかと思う。
　ラックマウントのサーバーが並ぶ中でMac Miniをそのままというのは確かに斬新ではあるが、恐らくは現時点ではテスト用を想定しており、他のEC2インスタンスのようなサーバーやVDIとしての用途は想定していないのではと思う。リモートでクラウド上の実端末を使ってテストするサービスはスマートフォンで存在するので新しい話ではないし、MacOSでテストできれば良いのであればMac Miniでいいだろう。逆にMac MiniだろうがMac Proだろうが電源やストレージが多重化されていなかったり、他のAWSインスタンスほどの可用性は実現できないからMac Miniなのだろう（Mac ProだとECCメモリーを使える利点はあるが）。

　MacインスタンスではNitro Systemを使っていることも説明されたようだが、AWSならそれは当たり前だろう。
　通常AWSで「Nitro」という単語はKVMベースのVMM「Nitro Hypervisor」・セキュリティーチップ「Nitro Security Chip」・NIC「Nitro Cards」の総称だが、この場合は主にNitro Cards≒Elastic Netrwork Adaptor（ENA）とリモートの各種コントローラーのことだろう。
　通常のAWS EC2インスタンスでは追加・削除されたElastic Block StorageはローカルストレージではなくAnnapurna Labs製NIC経由でNVMe-oFを使っているはずで、これは恐らくMac Miniインスタンスでも同様であろう（恐らくrootfsがNVMe-oF上のSSDに置かれていることだろう）。通常はNICはPCI Expressで接続されるがMac Miniの場合はThunderbolt 3（PCI Express 3.0）で接続されているわけである（Mac MiniはわからないがMac Proはネットワークドライブによるブートをサポートしないようである。しかし、NVMe-oFはOSから見ればNVMeローカルストレージだからブート可能だろう）。
　その意味では、メディアの言う「市販のMac Miniがそのまま使用されている」は嘘ではないが正しくも無いように思う。

ホビー用Single-Board Computer話題二選

FriendlyELECがNanoPi R4Sを発表

NanoPi R4S SBC launched with optional metal case for $45 and up - CNX Software
NanoPi R4S - FriendlyELEc

　中国のSingle-Board Computer（SBC）ベンダーのひとつであるFriendlyELECが中国RockChip製RK3399を搭載したNanoPi R4S（以下R4S）を発表した。NanoPi Rxシリーズの特徴としてEthernetポートを2ポート搭載しておりルーターの自作などに使える点が挙げられる。

　とはいえ、以前のNanoPi R2S（以下R2S）の記事でも説明したが、RK3328やRK3399をはじめ過去に発売された他のSoCもルーターなどで使用されるNetwork Processorとして作られたわけではないから、実験用としてはともかく高性能なWi-Fiルーター/Wi-Fi APとして実用的ではない。Android TV Box/タブレット用SoCであるRK3328やRK3399は、専用のNetwork Processorとは違いL2スイッチやパケットエンジンなどが搭載されておらずすべてのL3フォワーディングをCPUで処理することになるし、組み合わせて設計されたWi-FiコントローラーやファームウェアもないのでBeamformingのような芸当もできない。

　そこで、（先のNanoPi R2Sの記事でも挙げたが）例えばVPNサイト間接続用ゲートウェイのような、最初からL4以上のCPUでフォワーディングが必須の装置では強力なCPUの恩恵を受けることができる。
　ほかに考えられる用途としては、例えばEmby/Jellyfinを用いてビデオストリーミングサーバーが考えられる。これらのAndroid対応SoCでは動画のエンコード/デコードエンジンが充実しているためリアルタイムでトランスコードしながら配信することができる。

　上述の通りR4SにはR2Sという類似製品があるわけだが、CPUはR4Sが優れている代わりに高価（メタルケース付属の場合、R4S: $69・R2S: $30）なほかはよく似ている。

	NanoPi R4S	NanoPi R2S
SoC	Rockchip RK3399	Rockchip RK3328
CPU	Cortex-A72 2.0 GHz x 2 Cortex-A53 1.5 GHz x 4	Cortex-A53 1.3 GHz x 4
GPU	Mali-T864	Mali-450MP4
Memory	DDR3 1GB or LPDDR4 4GB	DDR4 1GB
VPU	(Decoder) MPEG-1/2/4, VC-1, VP8 4K VP9 4K 10-bits H265 4K 10-bits H264 (Encoder) VP8 1080p H.264	(Decoder) MPEG-1/2/4, VC-1, VP8 4K VP9 4K 10-bits H265 4K 10-bits H264 (Encoder) VP8 1080p H.264
Networking	Native 1000BASE-T RTL8211H (PCIe) 1000BASE-T	Native 1000BASE-T RTL8253B (USB3.0) 1000BASE-T

Hackboard 2

Hackboard 2 Intel Celeron N4020 SBC - CNX Software
Hackboard 2 - Crowd Supply

　クラウドファンディングのCrowd SupplyでHackboard 2が投資を募るキャンペーンを開始している。

　個人的には、このボードを見て複雑な心境になった。他社製の類似品であるLattePanda Deltaと見た目から酷似しているからだ。
　LattePandaの場合はIntel Core Mプロセッサーを搭載した上位LattePanda AlphaとAtom系Celeron/Pentiumプロセッサーを搭載したLattePanda Deltaから選択でき、多彩なGeneral Purpose I/O（GPIO）を備えていたが、Hackboard 2はGPIOが半分ほど省略されCPUがダウングレードした、まるで劣化コピー品のような存在（※LattePandaとHackboardの繋がりはよく分からなかった）で、代わりに$40ほど安い（LattePanda DeltaのKickStarterキャンペーン時の価格が$139。Hackboard 2が$99）。ちなみにLattePandaのKickStarterでのキャンペーンは既に終了しているが、ちょうど3年ほど前の同時期に開催されていた。

最近の気になった話題（2020年第48週）

AMD CDNAアーキテクチャー

Radeon Instinct MI100が採用するCDNAアーキテクチャーの内部構造 - ASCII

　ASCII大原氏の記事を含め、幾つかアーキテクチャーに関する記事が掲載されているが、詳細が一部明確ではない。
　大原氏の記事にも掲載されているCDNAのダイアグラムは「AMD CDNA Architecture White Paper」に掲載されているものを使用しているようだ。これらの図では随分と簡略化されているがCDNAはRDNAベースではなくGCNベースであるらしい。このことは昨年5月のRDNA発表時にAMD CEO=Lisa Sue氏が「今後もGCNは、高い(負荷の)ワークロードのアプリケーションの多くのために継続される」と言っていた通りなので驚くべきことではないが、詳細な情報が出ておらず不明な部分もある。もしInstinct MI100（Arcturus）の発表だけを見るとすれば、GCNをベースにアーキテクチャーの小改良とMatrix Unitを追加しただけのようにも見えるのだが、GCNからRDNAへの変更についてはグラフィックタスクへの最適化（汎用コンピューティング用の機能削減）に限らず汎用コンピューティングにも役立つ拡張もあり、それらRDNAで取り込まれた拡張がCDNAでも取り込まれたのかどうか、その辺りがよく分からない。

　まず、GCNとRDNAの違いを復習する。
　GPUはCU（Compute Unit）と呼ばれる単位のコアをクラスタリングしており、処理単位であるWavefrontを管理する部分（Program Counter・Instruction Bufferなどを持ちディスパッチする）と実行するSIMDエンジンで構成される（もちろんキャッシュやテクスチャーユニットなどもあるが割愛）。
　GCN（参考1、参考2）では1 CUあたり16 lane SIMD x 4基で4サイクルかけて64 work itemのWavefront（Wave64）を実行する。1 laneが32-bitだから2048-bitのSIMD幅である。10 Waveまで管理できる管理ユニットが1 CUあたり4基搭載されており、合計で最大40 Waveをインフライトで実行でき、160 サイクル分の遅延を許容する。
　RDNAでは1 CUあたり32 lane SIMD x 1基で1サイクルで32 work itemのWavefront（Wave32）を実行する。1 laneが32-bitだから1024-bitのSIMD幅である。20 Waveまで管理できる管理ユニットが1 CUあたり1基搭載されているため最大20 Waveをインフライトで実行でき、20 サイクル分の遅延を許容する。

　ここで疑問なのは「General Purpose GPUで最適なSIMD幅」である。
　SIMD演算ユニットのようなベクトル演算ユニットはスカラー演算ユニットに比して制御のコストに対する演算パフォーマンスが高くなるが、アプリケーションに対してSIMD幅が広過ぎても逆に効率が落ちるトレードオフがあるため、最適なSIMD幅が議論されていたことがある（※約10年ほど前。現在はよく分からない）。SIMD演算は制御ユニットに対する演算ユニットの多さ＝演算密度の高さが利点だから、制御ユニットの占める割合が高いCPUでは比較的短いSIMD幅（64-bit～）に留まりGPUでは比較的長いSIMD幅（～4096-bit）になるが、どこが境界になるか？という問題である。具体的な製品の例を挙げる：

• GPUの本来の用途であるグラフィックタスクでは4096-bitが最適とされていたが、用途が変わると最適な幅が変わってくる
• NVIDIAはWarpを処理単位とするがWarpは1024-bitである
• AMDはPhil Hester氏がCTOの時代（ATI Technologiesを買収した頃）に512-bit以上はGPUで実行すべきと主張していた
• 以前、IntelはGPGPUではなくMany Coreで処理する構想を持っていたが、Knights Landingで512-bit幅のAVX-512を導入した
• Intelは512-bit幅のAVX-512をIce Lake/Tiger Lake/Rocket Lakeといったコンシューマー製品にも導入している
• Armと富士通が共同開発したSVEでは128-bit～2048-bitまでスケールするようにした

	AMD (CDNA)	AMD (GCN)	AMD (RDNA)	NVIDIA (Pascal-Ampere)
Workgroup Logical SIMD width	Wave64 2048-bit	Wave64 2048-bit	Wave32 or Wave64 1024-bit or 2048-bit	Warp 1024-bit
Physical SIMD width	512-bit	512-bit	1024-bit	1024-bit
Latency	4 cycle	4 cycle	1 cycle or 2 cycle	1 cycle

　これを踏まえて登場したCDNA1.0アーキテクチャーであるが、GCNアーキテクチャーを踏襲している。
　AMDがFusionで512-bit以上のSIMDをGPUにマップして実行するアイデアを説明していたのは10年以上も前の話なので現在でも有効なのか分からないが、IntelやNVIDIAの動向も併せて考えると、CPUでは～512-bit幅・GPGPUでは512-bit/1024-bit～という棲み分けができると考えられる。GCNのアーキテクチャーでは物理実装されたSIMDエンジンは512-bit幅で4サイクルで実行しているので、512-bit幅や1024-bit幅のサポートを追加することも不可能ではなかったのではと想像する（ましてやRDNAで1024-bit幅のWave32を導入したのだから尚更である）が、それでも2048-bit幅を保っているのはAMDが2048-bitが最適と判断したためなのだろう。

　AMDがこのタイミングでCDNA 1.0/Instinct MI100を投入したのは、大原氏も指摘している通り米エネルギー省のHPC Frontier（2022年運用開始）とEl Capitan（2023年運用開始）を見据えたものだろう。言い換えると、Frontier・El Capitanで採用される将来のInstinct GPUはCDNA 1.0向けに開発したアプリケーションがほぼそのまま動くはずで、大幅な変更が行われないと推測できる。もしかすると将来バージョンのCDNAでもWave32への対応は追加されるかもしれないが、当面はWave64に最適化されるのだろう。

　CDNA 1.0で最大の謎はMatrix Unitであろう。上述の通りCDNA 1.0のCUは16 lane / 512-bit幅のSIMDユニット4基で構成されるが、ダイアグラムではSIMDユニット中に「DPx8」「SPx16」「HPx32」「SFUx4」と並んで「Matrix Unit」と記載されている。これを信じるならばMatrix UnitはCU中にFP32（SP）などを流用するのではなく別の演算ユニットとして存在するようだ（理屈の上ではSIMD演算ユニットも流用できるが…例えば16x16のマトリックス演算だと16-way SIMD 16サイクルで演算することになるので現実的ではない）。ただ、FP16:bFP16:FP32のサイクルあたりの演算性能が1024:512:256＝4:2:1という割合になっているのが不思議だ（よくあるのはINT8:bFP16/FP16:FP32の演算性能が4:2:1の割合）。この辺りの構成については続報を待ちたいところである。

　一方、アーキテクチャーではなく実装レベルの話として、Navi 2.0では搭載されたがArcturusでは搭載されていないものとしてInfinity Cacheがある。Navi 2.0では128 MBものキャッシュが搭載されており、恐らくInfinity Cacheはグラフィックタスクだけでなく汎用コンピューティングでも有効と推測するが、Arcturusでは採用されていないようだ。CDNA 1.0のダイでもCUアレイの外周とHBM2Eメモリーインターフェースの間には配線のみと思われる空間があるので、Infinity Cacheを搭載する余地はありそうに思えるのだが。次世代モデル（CDNA 2.0？）以降での採用に期待したいところである。

将来的にApple ISAが登場する？

Apple Siliconがやってきた　そのさらに先、「Apple ISA」への遠い道のり - ITMedia

　私の予想では将来的に「Apple ISA」が登場する確率は5割以下だと思う。より詳細に言えば、「Armv8-A ISA」「RISC-V ISA」のようなレベルでApple独自の命令セットが登場する確率は低いだろうが、IntelがXScaleでARMv5-TEを独自拡張したWireless MMXのような拡張ISAであればあり得そうに思える。

　AppleはAシリーズ/MシリーズでArmプロセッサーを性能でリードしているが、それでも知られている限りではArm標準以外の拡張は行っていない（恐らくライセンスで禁止されているせいもあるが…Appleが本当に独自拡張をしたければArmに認めさせるだろう）。Armv8-A ISAは一応Armv8.7-Aまで発表されているが、Arm純正コアはArmv8.2-Aまでの対応で、Armv8.4-Aに対応しているのはAppleのみである（参考1・参考2）。このことからも、Appleが市場の標準仕様に沿って製品開発を行っていることが分かるし、もし、AppleがXScaleのWireless MMXのようなArm標準への拡張を実装したければArmに働きかけそうに思う（富士通がSVEの開発でArmと協業したように）。
　Appleは確かに独自のMacOS/iOSやAプロセッサーを開発したりLightningケーブルのような独自規格を作るベンダーである一方で、MacOS/iOSのコア＝Darwinや標準ブラウザーSafariのエンジン＝WebKitをオープンソースにしたり、独自Aプロセッサーの命令セットに業界でデファクトスタンダードなArm ISAを採用したり、USBのような標準規格をいち早く取り入れたりと標準技術からの距離に敏感なベンダーでもあるように思う。
　もしAppleがISAレベルで所有することを望んでいるとすれば、SoftBankがArmを売り出した際に買っているはずで、やはり、いきなり独自「Apple ISA」というのは過去のAppleの行動からすると矛盾しているように思える。

　ただ、記事中でも指摘されているようにNVIDIAによるArm買収は懸念事項のはずである。Armコミュニティーへの貢献がイコールでNVIDIAへの貢献になってしまうからだ。
　例えば富士通はArmと協業してSVEを開発したわけだが、富士通のHPC用SIMD技術やノウハウがArmの標準としてコンパイラーやツールレベルで標準的にサポートされることになり富士通にとってもArmにとってもWin-Winの関係となったはずだが、富士通とNVIDIAはHPC市場では競合関係にある（と言えなくもない）わけで、今後は富士通がArmと協業する場合は注意が必要になることだろう。同じことはAppleにも言える。
　筆者が想像するに、過去のAppleのように標準技術・オープンソースを尊重しつつ、Arm/NVIDIAの影響を取り除きたいとすれば、Apple独自ISAよりもRISC-V ISAをベースにApple独自拡張をする方が理に適っていると思う。ただし、RISC-V市場は立ち上がり始めたばかりでコンパイラー等の整備・最適化も途上だから、もしAppleが再度ISAを乗り換えるとすれば10～20年後にRISC-Vが成熟した頃になるのではと思う。

最近の気になった話題（2020年第47週）

Elbrus-8CB搭載ボードがクラウドファンディングを準備中

VLIW CPU in a Desktop: Enthusiasts Crowdfund Elbrus-Based Mini-ITX Motherboard - Tom's Hardware
IcepeakITX ELBRUS-8CB Security-oriented mini-ITX motherboard with MCST Elbrus8CB VLIW as CPU - Cloud Supply

　露MCSTのElbrus-8CB 8コアCPUを搭載したMini-ITXタイプの基板がクラウドファウンディングCrowd Supplyでキャンペーンを開始するようだ（11/21現在は準備中）。

　Elbrusと聞いて、興味深々なような遠くから静観していたいような、不思議な気分になったのは筆者だけではあるまい。
　MCST（Moscow Center of SPARC Technologies）はロシア独自CPUの開発企業で、SPARCアーキテクチャーのほか独自のVLIW型Elbrusアーキテクチャーを推進している。MCST ElbrusについてはPCWatch後藤氏も何度か取り上げておられるが（参考1・参考2）、2000年頃に話題となったTransmeta CrusoeやIntel Itaniumのように、VLIW型のアーキテクチャーハードウェアでx86をソフトウェアでエミュレーション実行する。
　さすがに2000年頃から20年も経っているのでマイクロアーキテクチャーは進歩しているだろうが、英語版Wikipediaに「Elbrus 2000 based microprocessor」と記載がある通り基本的なアーキテクチャーは1999/2000年頃に登場したE2Kから踏襲していると考えられる。

　今回のクラウドファンディングに登場するボードに搭載されているのはElbrus v.5アーキテクチャーのElbrus-8CB 1500 MHzとのことだがMCSTの公式Webサイトはロシア語なので注意が必要である。上記の英語版WikipediaやMCSTのWebサイト（Google翻訳）やカタログを見てもElbrus-8CBは見当たらないが、実はキリル文字表記の「Elbrus-8SV」はラテン語アルファベット表記の「Elbrus-8CB」だと記載がある。クラウドファンディングに登場するのは「Elbrus-8CB」に「KPI-2」チップセットや各種コントローラーを組み合わせた基板である。

　基板とスペック表を注意深く観察するとPC用Mini-ITX基板では見慣れない構成になっていることが分かる。

• メモリーはDDR4-2400 ECCが4chである。基板には表と裏で計20個のチップ（1chあたり 16-bit config x 4チップ + ECC用 1チップ = 74-bit）を搭載
• KPI-2はPCIeを合計20レーンしかサポートせず、PLX Technology（現Broadcom）製PCIe Switchで不足分を補っている
• リアI/OのUSB 2.0 x6・USB 3.0 x2のうちUSB2.0はKPI-2に搭載のコントローラーを使用、USB3.0は恐らくPCIe x1接続（コントローラー不明）
• リアI/OのEthernetのRJ45 x3・SFP x1のうち1000BASE-T（RJ45）はKPI-2内蔵のMACにMarvell 88E1111 PHYを組み合わせている
KPI-2にはGbE MACが3基しか載っていないのでSFP用のGbEはコントローラーがPCIe接続と思われる（コントローラー不明）
• M.2が2スロットあるがSATAのみ対応。PCIe AHCI/NVMeに非対応のほかUSBも配線されていないのでSATA SSD以外には使用不可
KPI-2には8ポート分のSATAコントローラーを搭載しており、M.2接続x2のほか通常のSATAポート接続x6を備える
• HDMIはSilicon Motion製のSM768/256ディスプレイアダプターで2D描画のみ対応
• GPSおよび各種センサー（落下検出・ジャイロ・湿度）を搭載している

上記の構成を眺めると、例えばPCやPCサーバーとしての用途には適さない感じがする。CPU性能については後述するとしてI/O周りが古すぎたり遅すぎたり少なすぎたりするためである。GPSと各種センサーが搭載されており2Dのみのディスプレイアダプターが搭載されていることから車載エンターテインメント端末用かIoTエッジサーバー用が妥当ではないかと思う。旧共産主義陣営のロシアの立ち位置（旧資本主義陣営の技術からの独立）は理解できるし、Elbrus自身はサーバー用を謳うもののIntelやAMD製のCPUが入手可能ならばサーバー用に使いたいとは思えないだろう。CPUもそうだがKPI-2の仕様の古さが際立っている。

　Elbrusアーキテクチャーの詳細は不明であるが、Elbrus-8CBの前世代で2016年に登場したElbrus-8Cについては幾つか資料を見つけることができる。IEEE会員であれば「The 5th Generation 28nm 8-Core VLIW Elbrus-8C Processor Architecture」という論文が読めるが会員でなくても、Semantic Scholarで論文中のダイアグラムなどを見ることができる。

　Elbrus-8CではCPUコア2個とL3キャッシュ2バンクで1個のQARTクラスターを構成し、4個のQARTクラスターが双方向リングで接続されている。L3キャッシュは2 MB 16-wayのバンクが8個で合計16 MBである。各CPUコアはそれぞれ内部でCluster-AとCluster-Bの2セットのVLIWクラスターで構成されており各3基のALC（Arithmetic Logic Channel）を持つ。Elbrus-8Cのスペックを見るとL1命令キャッシュ64 KBに対しL1データキャッシュが128 KBであるが、どうやらL1命令キャッシュはCluster-A・Bで共有されるのに対しL1データキャッシュは別になっているようだ。ダイ中央にはSICと呼ばれるオンチップネットワークとメモリーコントローラーを統合したマネジメントユニットが搭載されている。SICから4chのメモリーコントローラーとCPUソケット間接続（最大4ソケット）とI/Oコントローラーに接続される。
　I/Oコントローラー＝KPI-2のスペック表にはCPUとの接続が「16 GB/s」としか表記が無いのであるが、どうもPCIe Gen 2 x2 8 Gbpsの双方向（計16 Gbps。レーン数が記載されていないがPCIe Gen 2で8 Gbpsだと2レーン）という意味のように読める。SICにはI/Oコントローラー用以外にPCIe Gen 2 x2 3リンクがあるようだがCPUのスペック表にも記載が無く使用可能なのかよく分からない。IntelやAMDのCPUのようにGPU接続用のPCIe x16が搭載されているわけではないように思うが、KPI-2経由だとCPU - GPU間の接続が上述の通りCPU - KPI-2（PCIe Gen 2 x2 8 Gbps）でボトルネックになりそうな気がする。

　CPUコアに搭載されている演算ユニットがALCであるが、Alt Linuxのドキュメント（Google翻訳）ではより詳細な説明があり、ALUで「integer (Int)」「real (FP)」「comparisons (Cmp)」「memory read (LD)」「memory write (ST)」「over packed vectors (Vect)」「division and square root (Div / Sqrt)」と一通りの命令が実行可能であることが分かる。6基のALU0-5が搭載され3ユニットごとのペアになっており、筆者の理解では演算ユニットは以下のようになっている。VLIW構成であるためElbrus-8CでもElbrus-8CBでも基本は変わらないはずである。

ALU0/ALU3	ALU1/ALU4	ALU2/ALU5
Int / Shift	Int / Shift	Int / Shift
Compare	Compare	-
Int SIMD (packed)	Int SIMD (packed)	Int Div (ALU5 only)
FP	FP	-
FP SIMD (packed)	FP SIMD (packed)	-
Load	-	Load/Store

　上記は前世代Elbrus-8Cの仕様についてであるが、Alt Linuxドキュメント中にはElbrus-8C 1300 MHzでFP64で125GFLOPSという記載がある。前世代Elbrus-8Cでは8コア1300 MHz動作だからFPUあたり1 FLOPS/Cycleとして各コア12基のFPUが必要なため上記（2 FLOP/Cycle）が6セット必要な計算になるが、FPUの仕様もよく分からないので論文中のALCとAlt Linuxドキュメント中のALUの関係がよく分からない。

　ここまではElbrus-8CBの前世代Elbrus-8Cの話であるが、Alt Linuxのドキュメントによると、どうやらElbrus-8CBではElbrus-8CからIPCが2倍に伸びたようだ（例：FP64でElbrus-8C 1300 MHzが125GFLOPSに対しElbrus-8CB 1500 MHzが288 GFLOPS）。これはVLIW構成であることを考えると驚異的に思える。VLIWではソフトウェアのコンパイル時にスケジューリングされるためハードウェア側はVLIWのフォーマットに簡単に変更を加えることができない（例：FPUを1ポート追加、というようなことができない）。そのためコア当たりのALCの数が倍増したと考えられる。

　Russian SuperComputer Dayプレゼンテーション資料を見ると、Elbrus-8CはIntel Xeon E2660 v3（Haswell 10C/20T 2.60 GHz）と同等という主張が見れるが、例示されているFFT（高速フーリエ変換）などはVLIW型アーキテクチャーが多いDSPが得意とする演算で、DSPが得意な演算はElbrusも得意ということではないかと思う。
　もっとも、クラウドファンディングのElbrus-8CB搭載Mini-ITX基板に話を戻せば、GPSおよび各種センサー（落下検出・ジャイロ・湿度）を搭載しており、センサー周りの演算（FTTなど）はDSPが得意とするところだからElbrusで最適なアプリケーションなのかもしれない。

Ice Lake世代Intel Xeon Scalable 32コアはZen 2世代AMD Epyc 64コアより高性能？

Intel、「Ice Lake世代の32コアXeonは64コアEPYCを上回る性能」 - PC Watch

　どういうことかと言うと (1) High Performance Computing（HPC＝いわゆるスパコン）のワークロードで (2) AVX-512が有効なアプリケーションではIntel Xeon Scalable 32コアはZen 2世代AMD Epyc 64コアより上という意味である。

　記事中ではLAMMPS・NAMD STMV・Monte Carloの性能差が示されているが、これらのアプリケーション名をネットを検索するとAVX-512が有効であるという結果が見つかるため（参考）、Intelのスライドには特に記載が無いがAVX-512のことを言っていることは推測できる。

　一応HPCのカンファレンスでの発表で参加者は研究者あるいはエンジニアが多いはずで、このワークロードがアンフェアとも言えないのだが、ここだけ切り取ると違和感を感じなくもない。
　例えば、256-bit SIMDのAVX-2より512-bit AVX-512が有効なアプリケーションではより幅の広いSIMDだとより高性能なはずで、例えばNVIDIA CUDAやAMD ROCmだとより高性能な可能性もあるし、そもそも最近はやや論調も変わってきたとはいえAMDは元から512-bit以上の幅のSIMDはGPUで実行すべきというスタンスでATI Technologiesを買ったわけだから、Intel vs AMDという視点で比較するならXeon vs EpycではなくXeon vs Radeon Instinctの方が妥当かもしれない。

　また、32コア対64コアの比較だと衝撃的に思えるかもしれないがEpycはコアの価格が安価なので例えば現行Cascade Lake Xeon Gold 6258R 28コアとZen 2 Epyc 7552 48コアは共に約$ 4,000なのでコア数の差を強調する意味はあまり無いかもしれない。

最近の気になった話題（2020年第46週）

MIPSがRISC-Vをサポート

MIPS、RISC-Vのサポートを表明 - マイナビ

　MIPSが8000シリーズコアでMIPSとRISC-Vの両命令セットをサポートするという。面白そうだとは思うが3年ほど遅かったのではと思う。また、群雄割拠状態に突入しつつあるRISC-VアーキテクチャーでMIPS製コアに需要があるのかと疑問にも思う。

　最近のマイクロプロセッサーはCISCに限らずRISCでも内部で内部命令に変換して実行しているものが多い。そのため、デコーダーを載せ替えて同じマイクロアーキテクチャーで異なる命令セットアーキテクチャーをサポートすることは理論上では可能だろうし（参考）、近い命令セットアーキテクチャーであればデコーダーで複数の命令セットをサポートすることは原理的に不可能ではない。x86マイクロプロセッサーのようなCISCからRISC（-like）への変換というのは極端な例としても、昨今のArm64プロセッサーはArm32をエミュレーションで実行しているし非現実的でもない。
　MIPSとRISC-Vの場合、記事中のスライドによると90％以上のMIPS命令とRISC-V命令が1対1で対応するのだそうで（MIPSもRISC-Vも元を辿ればジョン ヘネシー博士に行き着くため驚くことでもないが）、内部のアーキテクチャーに大きな変更を加えることなくデコーダーで変換できそうに思える。

　RISC-VはPCやスマートフォンのような消費者の目に見えるレベルではないものの、浸透の兆しを見せている。Westerd DigitalはHDD/SSDのコントローラーにRISC-Vの採用を表明し、同時に同社製ロイヤリティーフリーのCPUコアSweRVを発表しているし、NVIDIAはGPU内蔵のコントローラーにFalconに替えてRISC-VベースのNV RISC-Vを採用している。アプリケーションの互換性が重視される分野はともかく、採用ベンダーがソースコードをコンパイルできる組込では浸透できる余地がある。
　サポーターが減りつつあるMIPSが、同社のIPやエンジニアリングリソースを活かしてRISC-Vに参入することは不思議でも何でもない。

　ただ、RISC-Vが盛り上がってきた2017年頃ではなく今年に発表というのは動きが遅い気がする。
　Armに対してMIPSが劣勢に立たされているのは10年ほど前から明らかで、2012～17年頃にはBroadcomやMediaTekといったMIPSの最大級の顧客のArmへの移行が顕著になり始めた。Broadcomがブロードバンドルーター用SoC=BCM4708でMIPS系BMIPS（元はSiByte製）からArmへの移行を発表し（2012年）、Caviumが"Project Thunder"・Broadcomが "Vulcan"を発表し（共に2014年）、いわゆる「ヘネパタ本」がMIPSからRISC-Vに変更になった（2017年）のも、ちょうどこの頃である。日本でも理研と富士通が当時ポスト「京」と呼ばれていたHPCのCPUにSPARC64に替えてArmを採用すると発表したのが2016年のことである。
　もちろん、Broadcomや富士通とビジネスモデルが違いMIPSにはArmという選択肢は無かったし、ハイエンドCPUコアの開発には4～5年間ほど要するため意思決定から製品が投入されるまでのラグもあるのだろうが、それでも2021年に製品登場と言うのは遅いのではなかろうか（実際、似た状況だった富士通がA64FXのサンプルを出荷したのは2019年4月のことである）。

　今回発表されたのはI8100・I8500・I8800の、MIPS64 Release 8およびRISC-V ISAに基づき、2021年に登場予定である。
　ちなみに、記事中で記事の著者＝大原氏が「現行製品であるMIPS I-Classの7000シリーズの延長というよりは、その一つ前の6000シリーズの延長にある」とされているのは、そもそもMIPS Release 7（？）とI-7000が従来のMIPS32/MIPS64とは非互換のnanoMIPSに基づくコアI7200のみ（果たして採用企業はあるのだろうか？？）なので仕方が無いところではあると思う。
　また、I-ClassなのかP-Classなのかという点については、そもそもMIPS64 Release 6のI6400・P6600の時点でブロックダイアグラムのレベルではほぼ同等・違いはI6400がSMT4マルチスレッドのIn-order実行コア、P6600がSMT無しのOut-of-Order実行コアという違いでしかないため、あまり意味のない議論のように思われる。

　個人的にはMIPSのRISC-V対応というのは妥当な動きだと思うし、今後に期待したいところだが、上述の通り3年ほど遅い気がしてならない。
　富士通A64FXにも言えることだが、ニッチな命令セットをサポートするCPUでビジネスすることは困難だが、一方でArmやRISC-Vのようなメジャーな命令セットをサポートすると競合他社との競争に晒される。富士通A64FXの場合、汎用的なサーバー用途だとArm Neoverse・Marvell/Cavium ThunderX・Ampere Altraと競合することになるが、HPC（スパコン）用途でSVEに最適化していることで他社との差別化に成功しているように思われる。MIPSの場合はプロセッサーではなくCPUコアIPのライセンスが中心になるため差別化は難しそうに思える。RISC-Vの場合11月14日現在で86種類ものコアが登録されており道は険しそうだ。

Apple M1

Apple M1
Mac用新CPU「M1」は、5nmプロセスで”世界最速CPUコア”搭載 - PC Watch
「Apple M1」でMacの性能が大きく伸びたワケ　Intel脱却計画に課される制約とは？ - ITMedia

　恐らくiPad Proに搭載されるA14X（仮称）と同等だろう。A14Xは未登場のため詳細は不明ながら、iPad Proに搭載されているA12Zは4 big + 4 littleの計8 CPUコア・8 GPUコアで、これはM1と共通している。A12X/A12ZではCPUコア・GPUコアはiPhone用A12と共通でコア数のみ増強されていたが、A14X/M1も同様にiPhone用A14とCPUコア・GPUコアは共通でコア数を増強したものになることだろう。

　Apple製品に対するメディアの報道はポジティブなものばかりだが、恐らくIntelプロセッサー搭載MacとApple Armプロセッサー搭載Macの本当の意味での比較が可能になるのは来年以降のMac Proが出た段階でのことになると筆者は考える。
　上述の通り、M1はiPad Pro用プロセッサーを搭載したもので悪く言えば「間に合わせ」の感が強い。例えばMacBook 13で比較するとIntelプロセッサー搭載Macでは標準16 GBメモリー搭載・オーダー時に32 GBに変更可能だが、Apple Armプロセッサー搭載Macでは標準8 GB搭載・オーダー時に16 GBにしか変更できない。これは搭載メモリーがiPad Proで使われる仕様（LPDDR4X 128-bit幅。逆算するとLPDDR4 4チップ構成）を引き摺っているためと思われ、Mac Bookでは問題なくともMac Book Pro・Mac Proで許容されるとは思えない。LPDDRメモリーの選択には利点も欠点もあり、例えば高い転送帯域（LPDDR4X-4277で動作。チップあたり32-bitインターフェース）を低消費電力・省フットプリントで実現可能な反面、メモリーコントローラーと同一基板へのはんだ付けが必須で容量を増やし難いなどの制約もある。
　M1の登場にあたりMac BookとMac MiniというローエンドからApple Armプロセッサーの採用が始まったわけだが、PC用でなくタブレット＝iPad用のプロセッサーを流用しているのだからタブレットのような仕様になるのは当然である（ITMediaの記事ではAppleが「コンパクトに作った」と表現するが、iPadベースなので「コンパクトになった」が正解だろう）。恐らく大容量メモリーやディスクリートGPUが要求され、8コア以上のbigコアの搭載も求められるMac Book ProやMac ProではiPad用プロセッサーの流用とはいかないから、そこで初めてIntelプロセッサー搭載MacとApple Armプロセッサー搭載Macの本当の意味での比較が可能になる。

　現時点で出ているIntelプロセッサー搭載MacとApple Armプロセッサー搭載Macの性能比較も、どの程度が実態に即しているのか判断が難しい。モバイル用省電力プロセッサーと高性能プロセッサーとでは製造プロセスの最適化が違うため、タブレット用プロセッサー（TDP <10W）がPC用プロセッサー（TDP >65W）と同一の消費電力枠で比較することは現実的ではない。
　例えばAppleのスライド中のパフォーマンスを比較する部分だと、消費電力10W時の性能比較は、そもそもIntel Core-UプロセッサーがTDP 15W（メモリーなど周辺ロジックも含めると20W超）なので比較する方が無理があるし、音楽やビデオをXX時間再生できるというワークロードはスマートフォンやタブレット用プロセッサーが最適化されているワークロードで（DSPやビデオデコーダーASICを搭載している）、PCの性能を測る物差しとして適切なワークロードか怪しい。

　個人的に関心があったのが、LinuxやWindows on Armへの対応だが、現時点ではMacOS以外をブートすることは不可能で仮想マシンを使う必要があるようだ（Linux Kernelの開発者/モデレーターのLinus TorvaldsはMacBook Airユーザーである）。

Intel Server GPU

Intel Server GPU Shown for Video Transcoding Applications - ServeTheHome
Intel、Xe-LP採用のデータセンター向けGPU - PC Watch

　IntelはCPU・GPUなどを同一APIからアクセスできるOneAPIも発表しており、筆者個人はどういう使い方がされるのか興味深いところである。

　本製品を分析する上で適切なのかどうかは分からないが、ServeTheHomeを含む複数の記事が動画のエンコーディング/トランスコーディングに焦点を当てて報じている。
　御存知の通りIntel GraphicsにはQuickSync Videoハードウェアビデオデコーダー/エンコーダーが搭載されており、Ice LakeではNVIDIA NVDEC/NVENCを上回る画質・Tiger LakeではAV-1デコードを実現して非常に優秀な性能を見せており、もしクラウドから使用可能であれば動画のトランスコード等に使用されることは想像に難くない。
　実は、ハードウェア単体で見ればPC搭載GPU以外の選択肢も存在し、例えばスマートフォン用SoCは非常に高い動画のエンコード/デコード性能を発揮するが、コマンドラインから処理することを想定しておらず使い勝手は良くない（Qualcomm SnapdragonであればAndroidのMediaCodecからのアクセスを想定している）。より具体的にはOpenMAXからのアクセスに対応しており、LinuxではGStreamerからアクセス可能だがFFmpegではアクセスできない。スマートフォン用SoC以外のハードウェアエンコーダー/デコーダーも似たような問題を抱えており、Windows・Linuxで標準のFFmpegでハードウェアエンコーダー/デコーダーが利用できるのはNVIDIA/AMD/IntelのGPUだけと言っていい。

　PCWatch記事中にはさらりと「一般的なAndroidクラウドゲームであれば、2枚組構成で同時に100ユーザー以上を処理できる」と書いてあるが、これはNVIDIA・AMDのGPUでは難しい処理である。NVIDIA・AMDもGPU仮想化に取り組んでおり、製品としてはNVIDIA GRIDやAMD MxGPUが存在するが、GPUはコンテキストスイッチが大変（1スレッドの使うレジスタファイルの容量が膨大で、コンテキストスイッチで退避するオーバーヘッドが大きい）ため向いておらず（参考1、参考2）、NVIDIA GRID・AMD MxGPUではハイエンドGPUを1 GPUあたり8～16ユーザーで共有可能だった。「2枚組構成で同時に100ユーザー以上を処理できる」ということは1ボードあたり50ユーザー（ただし1ボードで4GPUなので実質12.5人か？）という高密度で共有可能ということになる。

　ところで、XG310ボードの写真についてPC Watchの記事では「X3C」とあるが、これはH3C（元Huawei 3Com）のことで、Hewlett Packered（現HP Enterprise）による3Com買収後にHuawei等からの出資で独立した中国のネットワーク機器・PC/サーバーベンダーである。筆者の知る限りH3Cがクラウド事業を展開しているという話は知らないが、恐らくAlibabaやTensentのクラウドで使用可能なものと思われる。

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

AMD Zen 3の内部構造

AMD Zen 3 Ryzen Deep Dive Review - AnandTech

　恐らく近日中に他誌でも分析記事が出ることだろうが、AnandTechにZen 3の内部構造に関する記事が掲載されている。
　記事はAMDのプレゼンテーションを基にしているようで、何処かで発表済なのかは不明ながら公式の情報に基づいた解説記事となっているようで読み応えがある。先日、Zen 2からZen 3への内部構造の変更点について予想を書いたが、すべてとは言わないまでも大きく異なる驚くべき内容となった。

　まず製造プロセス技術についてはZen 2と同じTSMC N7ということだ。
　筆者はN7+と予想したが、その根拠は (1) N7+は既に大量生産に使われている (2) N7+/N7P/N6はN7より高性能 (3) N7+はN7比で20％トランジスター密度が高いというもので、それらを使ってZen 2比+19％もの性能向上を実現したのだろうと予想したわけだが、そうではなかったことになる。AMDに新設されたZen 3を担当したCPU設計チームは、各ユニットを再設計することでZen 2とほぼ同じトランジスターバジェットで（！）+19％もの性能向上を達成したことになる。個人的にはZen 2と同じ同等のトランジスターバジェットで+19％もの性能向上を達成したことに賛辞を贈りたい一方で、Zen 4ではTSMC N5プロセスが見えている状況（既にAppleがA14 Bionicの製造で使用中なので来年以降であれば使えない理由は無い。つまり、仮にZen 4の設計に失敗した場合でもZen 3をN5に移すだけでお茶を濁せる状況）であるにも関わらずN7+/N7P/N6のいずれも採用しなかった理由に興味があるところである。

　ちなみに、こういうメーカーの主張する「+XX％改善」という数字はある側面から見れば実証できても全方位から見れば妥当とは言えないマーケティングトークであることが多いが、Zen 3に関しては+19％の性能向上が実現できている稀有な例に見える（参考1・参考2）。
　余談だが、各社のベンチマークテストではAMDがZen 3/Ryzen 5000シリーズの定格DDR4-3200で行っている場合が多く、これはIntel Core 10000シリーズの定格DDR4-2933に対して高速だが、それが公平か？というのは疑問の残るところである。一般的にCPU単体で最も重要なのはメモリーの帯域よりも遅延なので3200や2933という数字だけでは一概には判断できないが、とはいえSPECintならともかくCineBenchのようなワークロードではメモリーの帯域も重要になってくるだろう。
　恐らくAMD側の構成をDDR4-2933ではなく-3200に設定しているのはRyzenの仕様上、Infinity Fabricの動作速度がメモリーの動作速度に同期するから、メーカーの主張する性能を検証するにはメーカーの推奨する定格で動作させるというのは適切な方法だと思う。ただ、それとは別に、RyzenとCoreとでメモリーの遅延や帯域を揃えて個別に検証して頂きたかったところである。メモリーのスペックを完全に揃えても良いし、あるいは、例えばPC WatchのベンチマークでもAMDはDDR4-3200 CL=22に対しIntelはDDR4-2933 CL=21とCAS Latencyを抑えた構成になっているが、DDR4-3200 CL=22（13.75 nsec）に対しDDR4-2933 CL=21（14.32 nsec）では公平とは言えないためDDR4-2933 CL=20（13.63 nsec）にしてもらいたかったところである。

　さて、AnandTechに掲載されているZen 3の拡張に話を戻す。
　フロントエンドの拡張は、「分岐予測の高速化」など数字で表現されないものが多くZen 3がZen 2比でどの程度拡張されたか分かる部分が少ない。
　数字で示されているのは、例えばL1 BTB（Branch Target Buffer）が512KBから1024KBに倍増されたことぐらいで、命令デコード数・uOPキャッシュの容量・uOP命令ディスパッチ数にも変更が無い。ROB（Re-Order-Buffer）がZen 2→Zen 3で224→256（+14％）エントリーと増量こそしているものの、Intel Skylake 224エントリーを追い越した程度でIce Lake 352エントリーには及ばない。

　実行エンジンは実に興味深い。というのも、スペックシート上の数字（例：ALUユニット数）を見ればZen 2とZen 3では大きな違いは無いにも関わらず構造上の大幅な変更が入っているからである。地味だが最も大きな変更点は、遅延の低下（演算に要するサイクル数の低減）だろう。多くの命令で遅延が半分以下になったり帯域が2倍以上になっていることが解かる。

　まず整数演算エンジンだが、ダイアグラムの図の書き方はベンダーによって異なるためAMDの図では解かり難いがLoad/StoreユニットはStore-AddressとStore-Dataに分割されたように見える。Zen/Zen+/Zen 2までのコアではAGU（Address Generation Unit）の数と実行可能なLoad/Store数が一致していた。Zen/Zen+では2 AGUがあり最大2 Load/Storeが実行可能だったし、Zen 2では1基Store用ユニットが追加され3 AGUとなり最大 2 Load + 1 Storeを実行可能だった。AMDのダイアグラムでは引き続き3 AGUで変更が無いが3 Load + 2 Storeが実行可能となり一見すると図の実行ユニット数とLoad/Store数が合わないように見える。これは3 AGU（Load/Store-address）に加え2 Store-dataユニットが追加されているようだ。加えて独立したブランチユニットが追加されたためZen 2の7 issue/cycleから3増えて10 issue/cycleとなった。ただし、これにより同時発行可能なLoad/Store命令数は増えたものの実際にLoad/Store可能なデータ量は最大でLoad 32 B/cycle x2 + Store 32 B/cycleで違いは無いようだ（AVXを実行して256-bitで操作する場合は2 Load + 1 Storeに制限される）。

　次に浮動小数点演算エンジンの方は一見大きな変更が加えられたかのように見える。命令の同時発行数がZen 2では4 issue/cycleだったがZen 3では6 issue/cycleに拡張されているからだ。しかし、詳細を確認するとこの拡張は理論上の演算性能そのものの高速化にはあまり寄与しない。Zen/Zen+/Zen 2ではこれまでもFPU/SIMD演算ユニットは対称構成ではなく2 ADD + 2 MAD/MULと加算ユニットと積和算/除算ユニットに分割されていたが、追加された2ユニットは浮動小数点-整数変換（F2I）専用のユニットでADDやMAD/MULは相変わらず各2ユニットずつしかない。実行ポートが増えて演算性能が1.5倍に強化したというよりは実行効率の悪い小規模な専用演算ユニットを独立させて別ユニットで実行することで既存のユニットの実行効率を高めているように見える。
　ここで筆者の妄想に近い推測だが、Zen 3ではMAD/MULユニットとADDユニットそのものに変更が加えられていなくてもMAD/MULとADDを並列実行時のスループットが増加している可能性がある。そもそも、Zen/Zen+/Zen 2では3オペランドのFMA（積和算）の実行時はMAD/MULユニットがADDユニット側のレジスタファイルのリードポートを1本借用して3本のレジスタポートを使って実行しており、FMA実行時はADDユニットはブロックされてきた（参考）。これはMAD/MULユニット・ADDユニットともレジスタファイルのリードポートが各2本ずつしかないためだが、これによりリードポートへの配線の複雑化を抑えるのに役立つ一方でADDユニットが使えない分スループットは下がるトレードオフだった。しかし、F2Iユニットが追加されるのであればMAD/MULユニットがADDユニット側からではなくF2Iユニット側からリードポートを借用する方が理に適っている。F2Iユニットは元からレジスタポートが1本しかない上にADDユニットに比べれば使用頻度が低いだろうからだ。もしこの変更が行われた場合、FMA実行時でもADDユニットを同時に使用可能になり、スループットが向上する可能性がある。

　個人的に気になるのは実行ユニット直前のスケジューラーの構成の変更である。これまで、4 ALUと3 AGUに対しそれぞれ個別に計7個のスケジューラーが存在したが、Zen 3ではALU + AGUまたはALU + BRのペアでスケジューラーが各1個・計4スケジューラーとなった。
　ここで筆者の妄想に近い推測だが、Fused-uOPsに手が加えられた結果ではないかと想像する。というのも、もし複数の実行ユニットでスケジューラーを共用したいなら4 ALU/3 AGUでそれぞれ共用する方がロードバランシングの観点からも妥当そうに思える。しかし、ALU + AGUまたはALU + BRのペアでスケジューリングとなると異なるアイデアに基づくはずだ。例えばLoad→演算実行という一連の処理を、それぞれLoad + 整数演算という1個のFused-uOPとしてデコード・スケジューリングし、実行の直前でuOPに分割・実行するなら、ALU + AGUのペアでスケジューリングするというのは理に適っている。これは筆者のアイデアではなく、Intel（Israel Haifa）がCore Microarchitecture開発時に持ち込んだアイデアだ（参考）。このFused-uOPの利点は、命令デコーダーでデコードする命令数やスケジューリングの複雑さを増やさずに済む点にある。もちろん、類似のアイデア自体は既にZen/Zen+/Zen 2でも実装されているが（参考1・参考2）、仮にデコーダーステージでALU + AGUのペアをFused-uOPとして持っていたとしても、Zen 2までは実行ユニット前段のスケジューラーはALUとAGUでは分割されていたから、その前段のInteger Renameの時点で既に分割されていたことになる。Zen 3ではALU + AGUまたはALU + BRのペアでスケジューリングしているとすると、Zen 2→Zen 3ではFused-uOPの扱い方にも手が入っていることになる。

　AnandTechに記載されている内容の詳細を分析してみると、大規模な変更が加えられたというよりも既存ユニットの効率化に注力されているように見える。Zen+→Zen 2の時のような華は無いが、詳細を見てみると確かに効果のありそうな変更点が多く感じられる。
　整数演算エンジンでのブランチユニットの追加や浮動小数点演算エンジンへのF2I演算ユニットの追加もそうだが、追加されたリソースの規模はいずれも小規模にすぎず、既存ユニットの効率化に注力しているように見える。例えば浮動小数点演算エンジンを4基から6基に拡張するとしてもFADD + FMAD/FMULのペアを2組から3組に増量していれば理論上の演算性能は1.5倍になるが、それだと演算ユニットそのものの実装コストが高い上に、実際に効率良く動作させるにはレジスターファイルの増量やアクセスポートの追加・さらに恐らくはLoad/Storeの増強も必要になり影響が大きい。その点でF2Iならばオペランドは1個でレジスターファイルへのアクセスポートも1ポートで済むし実装コストも影響が小さくて済む。
　Zen 3では、トランジスターバジェットが増えていないせいか、逆に強化されていない部分も目立つ。例えばロードバッファー/ストアバッファーが72エントリー/64エントリーで、ストアバッファーは48エントリーから増強されたがロードバッファーは据え置きになっている。これはIntel Ice Lakeの128エントリー/72エントリーはもちろんスマートフォン用Cortex-A77の85エントリー/90エントリーよりも小さい容量である。

最近の気になった話題（2020年第42週）

AMDはXilinxを買収するのか？

AMD ザイリンクス買収で交渉が進んだ段階に－Bloomberg
AMDがXilinx買収か、複数メディアが報じる - EETimes

　AMDによるXilinxの買収交渉が進んでいることを複数のメディアが報じている。
　この取引自体は興味深くシナジーも見つけやすい。双方のポートフォリオを眺め、補完関係を考えるとすればAMD+Xilinxという組み合わせは、これがなかなか妙手に思える。AMDとXilinxの統合からIntelとAlteraの統合を連想することは容易だが、筆者にはNVIDIAとMellanoxの統合にも近いものも感じる。言い方を変えると、AMDが今後Intel（Altera・Habana Labsを買収）・NVIDIA（Mellanox・Armを買収）と競合し続けるためにはXilinxはベストな相手と言える。しかし、その実現性には首を傾げたくなる。

　同じx86 CPUベンダーとしてAMDとIntelとは比較されるが、詳しく見てみると実態は随分と違うように見える。
　Intelは安定して80％以上のシェアを誇り軍需にも食い込んでいる。さらに自社CPU向けチップセットに加え100/200GbEネットワークコントローラーやWi-Fiコントローラーのトップベンダーの一社でもあり、さらに近年はAltera・Barefoot Networks・Habanaを買収するなど、その保有するIPの品揃えは多岐に渡る。AMDとIntelとを比較することは、ヨドバシカメラのような一品種の小売り大手とAmazonのような何でも揃う総合スーパーマーケットとを比較するようなものである。
　例えば、今年3月に発表されたAtom P5900 seriesなどはそのハイライトのひとつではないか。小型のCPUコア・100 Gbit Ethernetとそれを支える440 Gbpsのネットワークアクセラレーター・16レーンの高速シリアルI/Oとそれを実現するSerDesをすべて自前のIPで実現している。さらにマクロセルを作る場合にはAtom P5900にIntel製モデムを接続する構成も考えられる（と言っても、Intel 5Gモデムはスマートフォン用をAppleに売却しPC用・車載用・IoT用は残っているはずなのだが続報が無い）。AMDが同種のネットワークプロセッサーを作ろうとすると他社製IPを寄せ集めた不完全なものしかできないだろう（例えばEpyc Embeddedに統合されているEthernetコントローラーはSynopsys製10 GbEである）。
　例えばMicrosoft AzureはProject CatapultでIntel Xeon CPUにIntel/Altera Stratix FPGAを組み合わせて使用しているが、AMDはそういう要望にも応えられるようにならなくてはならないだろう。AMDはZenシリーズCPUで成果を上げているが、ハイパースケールクラウド事業者に採用され続け・ビジネスを続けるためには、現在のような景気の良い時に弱点を補う努力をする必要がある。そんなAMDにとってはXilinxは好ましいパートナーと言えるだろう。FPGAの最王手としてIntel + Alteraに対抗可能というだけでなく、SmartNICベンダーSolarFlareを吸収しDeep Learningにも力を入れているからNVIDIA + Mellanoxにも対抗できる。

　対するXilinxにとってもAMDは好ましいパートナーと言えるだろう。
　矛盾するようだが、最近のFPGAベンダーは自社のプログラマブルロジックを売るために固定機能のFPGAとの統合に積極的に見える。10年以上前であればXilinxでいうPowerPCコアが統合されていたVirtexを除くFPGA製品は素のFPGAだったが、昨今ではよく使う機能はあらかじめASIC/固定ロジックが組み込まれる傾向がある。Xilinxでいうと例えばZynq Ultrascale+ではCortex-A53 4コア・Mali-400 GPU・リアルタイム処理用Cortex-R5・Arm TrustZone・LPDDR4メモリーコントローラーがあらかじめ組み込まれており、ほとんどフルセットのSoCとFPGAが同居するような格好になっている。もちろん、フルプログラマブルなFPGA（Virtex Ultrascale・Kintex Ultrascale）も需要はあるが、アプリケーション用CPUや高速なEthernetのような多数のユーザー使う機能はFPGAで合成するよりも、あらかじめ組み込んでしまった方が効率が良い（というか、Cortex-A53クラスのCPUでもVirtex Ultrascale+に収まらないだろう）。実際、XilinxはSmartNICのクラウドでの展開を見越してSolarFlareを買収している。しかし、高性能CPUや高性能GPUを持っていないため2018年にIntelが投入したXeonとArria FPGAを1パッケージに統合したXeon with FPGAやAgilex製品や、先日NVIDIAが発表したBlueFieldには対抗できない。AMDはIntel/NVIDIAに匹敵する高性能CPU/GPUを持つ理想的な相手といえる。
　このSolarFlareの資産はAMDにとっても貴重ではないかと思う。恐らくAMDはEpycやRadeon Instinctに高速Ethernetを組み込みたいだろうが、MellanoxはNVIDIAに・SolarFlareはXilinxに・CaviumはMarvellにそれぞれ買収されてしまっているし、NVIDIA（時価総額約$ 350 billion）もBroadcom（時価総額約$ 150 billion）も規模的に買収できないからXilinxを買えばSolarFlareまで付いてくるというのは魅力的なはずだ。

　しかし、問題は経営者や社員や製品ポートフォリオではなく第三者ではないかと思う。
　Xilinxの株主はより有利な条件での取引を望むだろうから提案を安易には承認しない可能性がある。もし仮に株主が承認しても中国当局・米国当局などが承認しない可能性もある。

　2015年にIntelがAlteraを買収した時は話は簡単だったと思う。誰から見てもWin-Winの関係だったはずだからだ。
　Intelは世界最大の半導体ベンダーでAlteraより時価総額も17倍（Intelの2014年の時価総額$ 172.30 billion。Alteraの同年の時価総額$ 10.4 billion）、さらに言えばAlteraはXilinxに次ぐ2位で当時製造能力で他社を圧倒していたIntelに統合されることは逆転する大きなチャンスだったはずである。しかもAlteraはIntelのファウンダリ事業の最初の顧客の一社でAlteraのハイエンドFPGAは既にIntelで製造されていたから即座にシナジーが生まれるしIntel製品との統合も容易だ。
　しかし一方のAMDの株価が高騰しており株式交換や第三者割当増資を使った買収が容易になっているとはいえ、IntelによるAltera買収ほど簡単ではなさそうに思える。例えばXilinxの時価総額約$ 29 billion・総資産額$ 5.151 billion（時価総額はリンク先の数字を参考。総資産額は2019年の実績）に対しAMDの時価総額約$ 100 billion・総資産額$ 6.028 billion（同左）であるが、AMDのこの時価総額はIntelの時価総額 $ 226.98 billionの約45％に相当しバブル気味に思える。AMDは最近4年間こそ業績が絶好調だがその前の6年間は成績が芳しくなく、例えば2014年の実績を見るとXilinxの時価総額$11.30 billionに対しAMDの時価総額$2.07 billionでしかない。最近できたベンチャー企業ならばともかく1969年創業の企業でこの乱高下は正直どうかと思う。要するに短期はともかく長期的な投資先としてのAMDには疑問がある。また、AMD自身が3月のFinancial Dayでも説明したように利益率の低さも問題だ。もしAMDがXilinxを買収するのであれば、投資会社と組んで第三者割当増資して現金を調達して行うのではないかと思うが、もしNVIDIAがArm買収で提案したような株式交換だとXilinx株主は容易には納得しないかもしれない。

　仮に株主が了承したとしても政府当局が了承しない可能性もある。
　中国はFPGA確保のため在米の政府関連投資ファンド＝Canyon Bridge Capital PartnersによるLattice Semiconductorの買収を試みたが2017年9月に米国のトランプ大統領が買収阻止の命令を出して阻止されている。米国政府と米国企業の影響拡大を警戒して承認しない可能性もある（とはいえ、米NVIDIAによる英Armの買収や米Qualcommによる蘭NXPの買収と違い、米国企業同士だから比較的スムーズに行く可能性もある）。
　また、Xilinxは軍需でも強いため、米国政府当局から何らかの条件が付く可能性もある。例えば戦闘機のアビオニクスだと20年ほど昔までは旧Mtorola（現NXP）のPowerPCにTexas InstrumentsのDSPというような組み合わせが多かったように思うが、自衛隊も導入したLochkeed Martin F-35などもIntel CPUにXilinx FPGAという組み合わせである。

AMD Zen 3での改善点

AMD Ryzenの「Zen 3」と「Zen 4」アーキテクチャ - PC Watch
性能/消費電力比がCore i9の2.8倍というRyzen 5000シリーズの詳細 - ASCII

　AMDは10月8日にZen 3ファミリーのデスクトップ向け単体CPU製品（コードネーム "Vermeer"）ことRyzen 5000シリーズを発表したが、説明は性能向上の割合などに留まり詳細な改善点は語られなかったためメディアでも推測しか報じられていない。国内メディアでは例えばPC Watch後藤氏やASCII大原氏が推測されている。

　そもそも改善点以前にTSMCのどのプロセス（N7P/N7+/N6）が採用されたかすら明らかでないのであるが、その何が問題かと言えばトランジスター密度に影響するからである。大雑把だが以下に纏めてみた：

• N7P ー N7と同じくDUVプロセスでN7より高効率だがデザインルールが同じためトランジスター密度は上がらない
• N6 ー EUVを使ったプロセスだがN7と同じデザインルールを使用できトランジスター密度は上がらない
• N7+ ー N7から電力効率も上がるが+20％ほどトランジスター密度も改善される

これを踏まえ筆者はN7+だと推測する。AMDが発表で使用したRyzen 5000シリーズの写真（※実物かどうか不明であるが）はRyzen 3000シリーズと瓜二つでCCDの大きさはほぼ同程度と推測できるが、ダイサイズの変更無しAMDが主張するIPC 19％の向上を達成するにはトランジスター密度の向上は必須ではないかと推測するからである。
　ちなみにIPC 19％向上というのは大幅な改善である。Zen+→Zen 2の変更ではGlobal Foundries 12LPプロセスからTSMC N7プロセスへの移行で大幅にトランジスターバジェットが増え（Zen+ 48億トランジスター→Zen2 CCD 38億トランジスター + cIOD 21億トランジスター）AVX/SSEユニットが128-bit→256-bitへの変更などの拡張が行われたが、それでもAMDの公称ではZen+→Zen2ではIPC 15％増加に留まる。Zen2→Zen3で行われた改良点のひとつ2クラスターのCCXを1クラスターに纏めるようなトランジスターバジェットへの影響が小さい改良もあるとはいえ、トランジスターバジェットの追加無しにIPC 19％向上というのは考え難いように思われる。

　Zen 2→Zen 3で公式に確定している改善項目は以下の通りである

• Cache Prefetchingの改良が2.7%程度、Execution Engineの改良が3.3%程度、Branch Predictorの改良が1.3%、Micro-op Cacheの改良が2.7%、Front Endの改良が4.5%強、Load/Storeの改良が4.5%弱で計19％のIPC向上
• Hash Perceptron分岐予測側に"ゼロバブル"と呼ばれる改良を行い分岐予測帯域を引き上げディレイを引き下げた
• CCXが8コアに変更になった

これらを踏まえて後藤氏と大原氏の推測を纏めると以下のようになる

後藤氏：

• 実行ユニットを増やしたというより、実行ユニットが分離されて命令発行ポートが分離された

大原氏

• ALU(整数演算器)が8wayないし9wayになった
• FPU(浮動小数点演算器)は4wayの対称型、もしくは6wayの非対称型になった
• Micro-opキャッシュの帯域が6 Micro-ops/サイクルから7ないし8 Micro-op/サイクルに強化された
• FPUの数を6つ(ただし依然として非対称のまま)にしたか、それともFPUの数は4つのままながら完全対称型にした
• LSU(Load/Store Unit)の帯域（64Bytes/サイクルと書き込み32Bytes/サイクルを同時に実行可能）を倍増した

　筆者の予測では、ALUの実行ポート追加という説は正しそうに思える。
　例えばArmコアでもCortex-A78にはZen/Zen+/Zen 2と同じく4ユニットのALUが実装されているが、うち2ポートは単純な整数演算（加算/論理演算など）のみ・1ポートは整数演算に加えて乗算に対応・1ポートは整数算に加えて積和演算と除算に対応している。これは積算・積和演算・除算の実装コストが大きいからだ。これに対しZen/Zen 2のALU 4ポートはすべてフル機能のALUとなっている（GCCの設定を見る限り4基のALUは対称である）ようで実装コストが大きい。そこで、例えば単純な整数演算のみの実行ポートを増やしたり、あるいは例えばフル機能のALU 4基に替えて整数演算・積算のみのALU 3基と整数演算・積和演算・除算に対応したALU 3基の組み合わせでALU 6基にするなどすれば実装コストを抑えつつポート競合を軽減できる。そもそもZen 2でさえ最大10 uopsまでイシューできるはずなので、ALUが4 ユニット以上あっても不思議はない。

　SIMD/FPUについては大原氏の推測のうち4基のバランスを変更した説が正しいのではと思う。
　後藤氏は実行ユニットを増やしたというより、実行ユニットが分離されてイシューが増えたとされているが、これは単にPapermaster氏の言葉の解釈だけでなく、上述の通りN7→N7+への移行でトランジスターバジェットが劇的に増やせないことによる。もしSIMD/FPUを6基に増やしたりすると大幅にトランジスターを食うはずで、実行ユニットを増やしたというよりも実行ポートのポート競合を減らしイシュー可能な組み合わせを増やしたと考える方が理解しやすい。
　SIMD/FPUの制約/非対称性については後藤氏の解説や大原氏の解説に詳しい。Zen/Zen+/Zen 2には4基のSIMD/FPUが実装されており基本的にはMUL/MADが2基・ADDが2基という組み合わせとなっているが、ここに2つの問題がある。まず、大原氏の記事の表にある通り各2セットあるMUL/MADとADDはそれぞれ対象ではなく一部の命令については4基中の1基でしか実行できずポート競合が発生する原因になる。また、積和算の場合は3オペランドとなりMADユニットで実行されるが、その際ADDユニットがブロックされる。これらは命令を並列実行する妨げになる。
　実装コストが大きいSIMD/FPUのバランスを変更してポート競合を軽減し並列実行性能を引き上げる試みはAMD以外でも行われている。例えばWikiChipにはSamsungのMongoose M3～M5コアでの拡張が解説されているが、M3→M4・M4→M5でそれぞれバランスが変更され実行可能な命令の組み合わせが変更された様子が示されている。AMDがZen 3でSIMD/FPUにどのような拡張を行ったか詳細は不明だが、トランジスターを大幅に増やせない以上はバランスを変更してイシュー可能な組み合わせを増やした可能性は高そうに思える。

　Load/Storeについては単にバッファーを増やしインフライトで発行可能な命令数を増やしたのではないかと思う。
　Zen/Zen+では2基のLoad/Storeユニットがあり最大128-bit x 2のLoad/Storeが同時実行可能だったが、Zen 2ではLoad 2基・Load/Store 1基に拡張された上で帯域も2倍となり最大256-bit x 2のLoadと最大256-bit x 1のStoreが同時実行可能となった。この128-bitとか256-bitという数字はSIMD演算ユニットの物理幅に合わせてある。
　これを踏まえると大原氏の推測が正しいと仮定するのは無理があるように思う。なぜならZen 3はAVX-512に対応しておらず512-bit x 2のLoadと512-bit x 1のStoreを同時実行できても意味が無いからである。Zen 2でも256-bitのAVXユニットが4基あるため、極論を言えば256-bit x 8のLoadと256-bit x 4のStoreでも性能向上に寄与する可能性はある。しかし、そこで必要なのはLoad/Storeユニットの増量による帯域向上であって、Load/Storeユニット数を同じまま単純にLoad幅やStore幅を増やしても性能を上げることができない。では、Zen 3でLoad/Storeユニットを追加したかというと筆者には否定的に思える。もしあるとすれば1基あるLoad/Storeユニットを1 Load + 1 Storeユニットに分割したり、StoreユニットをStore-Addressユニット+Store-Dataユニットに分割している可能性はありそうだ。
　筆者が推測するには、LoadバッファーとStoreバッファーを増量しインフライトで発行可能な命令数を増やすことが現実的に思える。メモリーアクセスは遅延が大きいためLoad/Store命令を発行しても完了するまでの遅延が大きい。そのためZen 2ではLoad 74エントリー/Store 48エントリーまでインフライトで実行できるが、Intel Sunny CoveではLoad 128エントリー/Store 72エントリー、モバイル向けArm Cortex-A77ですらLoad 85エントリー/Store 90エントリーでCortex-X1ではLoad/Storeバッファーを33％増量したとされる。それらに比べるとZen 2のLoad/Storeバッファーは小さすぎ、Sunny Coveと同程度までバッファーを増量している可能性は高そうに思える。

　フロントエンドの拡張としては、Reorder BufferやALUスケジューラー/FPUスケジューラーの拡張は確実だろう。
　Load/Storeの項でもIntel Sunny CoveやArm Cortex-A77/A78/X1に対するバッファーの小ささを指摘したが、これはReorder Bufferにも言える。Zen 2では224エントリーのReorder Bufferを備えるが、Intel Sunny Coveは352エントリー、モバイル向けArm Cortex-X1も224エントリーとなっている。こちらもSunny Coveと同程度までは拡張されていることだろう。

最近の気になった話題（2020年第40-41週）

NVIDIA/旧Mellanox BlueField

NVIDIA Shows DPU Roadmap Combining Arm Cores GPU and Networking - ServeTheHome

　NVIDIAが昨年買収したMellanoxのBlueFieldはSmartNICにカテゴライズされるものだ。つまりNVMe-oFなどでSSDアクセスのIOPを稼ぐことができる。Mellanox時代のBlueFieldはIPU（I/O Processing Unit）を名乗っていたことからも明白に思える。
　SmartNICやNVMe-oFと聞いて馴染みが無いかもしれないが、例えばAWS EC2のインスタンスにNVMe SSDのEBSを追加するような場合、NVMe-oFでストレージサーバーのNVMe SSDが追加されているはずで、知らず知らずのうちに使っている可能性が高い。AWSのGravitonプロセッサーはもともとはそういう用途で作られたSoCのはずである。ちなみに、AWSのRe:InventやHotChipsでのNitroの説明では、Gravitonだとは説明が無いが、NVMe-oFでインスタンスからネットワーク経由でAnnapurna製プロセッサーに接続されたNVMe SSDに接続する様子が図示されている。また、Gravitonの構成は他社製SmartNICに使用されているSoCに瓜二つである。

　そういう用途を踏まえてNVIDIAの資料を見るとBlueFieldのパフォーマンスを図る物差しとしてbpsやIOPSやSPECINTは分からなくも無いが、TOPSというのは違和感がある。言い換えればNVIDIAは新しいBlueFieldのロードマップで一般的なSmartNICとは違う立ち位置を目指しているように見える。
　そもそも、個人的にはSmartNICがどの程度売れているのか疑問である。悪く言えばSmartNICは高価（$500～）な割に中途半端な感がある。高速なEthernet NICということでは既に400GbEが市場に投入されているが、SmartNICはNVIDIA/Mellanox BlueField-2（2 x 100GbE）・Broadcom Stingrey （100GbE）・Marvell LiquidIO-III（5 x 100GbE）といった具合で内蔵NIC本体よりも性能は控え目に設定されている。さらにMellanox製品でいえばSmartNICで謳われる機能のうちVIF・SR-IOV・NVMe-oF・RDMA・DPDKなどはBlueField（マルチコアCPU + Connect-X）でなくともConnect-X単体でも対応しているので、SmartNICとしてBlueFieldの立ち位置は微妙に思える。真相はNVIDIA/Mellanox関係者にしか分からないがSmartNICとしてのBlueFieldはビジネス的に失敗だったのかもしれない。

　BlueField + NVIDIA GPU = DPUをDeep Learningアクセラレーターの一種として理解すると、GPUにRDMA対応のEthernetコントローラーが搭載されることは驚きではない。例えば学習または推論で複数のGPU/DPUが必要な場合にGPU/DPU同士でデータを直接やり取りできることでスケーラビリティーが向上する。Intelが買収したHabana LabsのGaudiにも100GbEが10ポートも搭載されている。
　プレゼンテーションではBlueField（+GPU）だけが載っているので解かり難いが、他のGPU・SoC製品と並べると役割分担とファミリー展開に納得がいくように思う（※Ampere世代よりTeslaブランドおよびQuadroブランドは廃止になったようだが、分かりやすさのために仮で載せている）。つまりARM CPU + GPUという組み合わせを派生させるだけで自動運転用SoCからHPCまで多様なマーケットに対応できる。
　筆者の個人的な意見だが、自動運転とDPU用SoCはよりDeep Learning重視で問題ないだろうが、現在のTeslaはGPGPU=General Purpose GPUというよりDeep Learningへの偏重が強すぎるように思うため、そういうマーケットはDPUに任せてよりGeneral Purposeに戻すべきではないかと思う。

	Embedded SoC	DPU SoC	GPGPU	GPU	GPU
Product Family	Tegra/Xavier	BlueField	Tesla	Quadro/GRID	GeForce
Market	Autonomous Car	Deep Learning	Scientific Computing HPC	CAD Pro Graphics	Consumer Graphics Gaming
Architecture	ARM CPU GPGPU	Ethernet ARM CPU GPGPU	GPGPU	GPGPU / GPU	GPU

SEIがPlayStation 5の分解動画を公開

PlayStation 5本体の分解映像を公開 - PlayStation.Blog
見所の多いPS5の公式分解動画が公開 - PC Watch

　冷却ユニットなど興味深くはあるが、意外性のない順当な内容である。
　メインボード上にはAMD製のメインSoCとGDDR6メモリー 8個・SSDコントローラーとNANDフラッシュ 6個が搭載されていることが確認できる。

　AMD製のSoCは詳細は未発表ながら概要は説明済のため順当な内容である。新しい情報というとXbox Series X用SoCと同じくモノリシック構成でチップレット構成でないことが確認されたぐらいであろうか。

　SSDは興味深い。
　SSDコントローラーはカスタム設計とされているが、筆者が想像するにはMarvelか何処かのカスタム品だろうと思う。12チャンネルというスペックはM.2タイプのSSDでは見ないがU.2タイプやHHHLタイプのSSDでは存在するだろうし、ファームウェアの成熟などを考えてもフルカスタムとは考え難い。続報を期待したいところである。
　PlayStation 5のSSDは12チャンネルと説明されているがNANDフラッシュは6個しかない。Dual-channel NANDというものは存在しないので2チップを1パッケージにまとめていると思われる。NANDフラッシュはTH***の型番が読めることから少なくともKioxia（旧Toshiba Memory）から供給を受けていることが解かるが、Kioxiaと工場を共同運営しているWestern Digital（旧SanDisk）製NANDフラッシュを搭載する個体も存在するかもしれない。とあるサイトによると動画中のものはTH58LJT0T24BA4Cだそうで2ダイ搭載の128GiB TLC NANDだそうだから計算は合う（128 GiB x 6 = 768 GiB = 825 GB）。

　PlayStation 5に限った話ではないがゲームコンソールへのSSD搭載で個人的に興味があるのはキャッシュの設計である。
　想像するに、ゲームコンソールのようなワークロードでは (1) システムソフトウェア (2) ユーザーが最近プレイ中のゲームにワークロードが偏ると思われ、100 GB程度のキャッシュがあればヒット率は高そうに思われる。特にPlayStation 5は5.5 GB/sもの性能を謳っているわけだからキャッシュを使っている可能性はありそうだ。
　一部報道によると、PlayStation 5では825 GBのSSDのうちユーザーが使用可能な領域は664 GBということで、約160 GBがシステムに占有されている可能性がある。とはいえ、いくらフィーチャーリッチなゲームコンソール用システムとはいえOSが160 GBもの領域を占有しているとは考え難く、恐らくOSがA面・B面で二重化されているのだろうが、それでも大容量すぎるためSLCキャッシュなどの何らかの仕掛けがあると想像する。

　オプションのM.2スロットが設けられていることはユーザーには僥倖だろう。対するXbox Series XではSeagate製のSSDがオプションで用意されているが1TBで$219と高価で恐らく性能も高くない。これに対し、PlayStation 5ではSamsung 980 Proのような高性能M.2 SSDを比較的安価に導入することができる。

　PlayStation 4のときはバックグラウンドプロセスを処理するサブシステムチップが搭載されていたが今回は搭載されていないようだ（参考）。
　PCWatch後藤氏の記事にもある通り、PlayStation 4ではダウンロードやゲームプレイ動画のエンコードタスクをサブシステムチップで行う予定だったようだが実現しなかった（PlayStation 4登場時。その後どうなったのか不明）。待ち時間の長いI/Oタスクを高性能プロセッサーから切り離すことは悪いアイデアではないが、PlayStation 5では実装されていないようだ。

脱押印

「個人の認証にもならない」三文判に河野太郎行革相 - FNNプライムオンライン on YouTube

　実に皮肉な結果だが官邸はCOVID-19に感謝すべきだろう。
　かねてより官邸主導で「働き方改革」なるものが叫ばれていたが、日本国外から見ている限りではスローガンばかりで内容が伴っていたようには見えなかった（参考：総務省のテレワーク導入率の資料）。官邸が「働き方改革」キャンペーンを始めたのは2016年頃、実に4年も前のことである。それがCOVID-19の影響で一気にテレワークが普及し、紙ベースから電子ベースへと移行が促され、押印が必要でなくなった。テレワークも電子ベースの決裁も欧米では既に多くで普及していた（後述）が、日本では遅々として進んでいなかった。

　印鑑自体は古代ローマ帝国でも使われていた実績あるものだ。
　ローマ人は印鑑を指輪にしており有力者が決裁するときもこの押印が使われたし（第二次ポエニ戦役の際、ハンニバルが倒したローマの将軍から奪って文書を偽造している）、それ以降でも印鑑とは違うが欧州では秘密文書の耐タンパー性確保のためシールが用いられた。その意味では日本固有の文化とは言えない。
　しかし、これは印鑑を含めすべて手作りかつ役割分担があったからこそ実現できたことだ。今日でも実印や銀行印が存在しメインバンクの登録や土地の売買などに使用されるが、例えば実印や銀行印の場合は複製が困難な印鑑であれば有効な可能性はある。

　ハンコ廃止議論で、実印の伴う取引への言及があるが、認印の廃止の問題と実印/銀行印の廃止の問題を同等に語るのは無理があるように思う。
　印鑑は認証におけるSomething You Haveだが、認印の場合は河野大臣も言う通り誰にでも安価で入手できる三文判は本人を認証する手段としては信頼性が低過ぎる。しかし、例えば私も実印を保有しているが、これをスキャンして3Dプリンターで偽造することは理論上は可能かもしれないが、そもそもほぼ使わないのでスキャンする機会が無く偽造は難しい。さらに言えば、もし今日における実印相当の決裁手段を印鑑か電子的な手段か選択可能になれば、攻撃側にとっては推定が困難になる。印鑑文化や業者を擁護するわけではないが、短絡的な発想はせず分けて考えるべきだろう。

　その意味でも認印の廃止には議論の余地が無い。
　例えば、社内での業務プロセスでの決裁に必要なサインを電子化することには意味がある。印刷が不要になりメールやWebベースで処理できることになりリモートワークで関係各所に会う必要がなくなる。そもそも上述の通り認印が本人確認の信頼性が低過ぎるのだから、電子的な決裁で信頼性を向上できるはずである。さらに、捺印する必要が無いということは印刷する必要が無くなりプロセスをすべて電子化することが可能になる。プロセスの本質とは必要十分な手続きを効率的に透明性・信頼性を担保して進めることにあるから、全プロセスを電子化できれば追跡が容易になりコンプライアンスの観点でも圧倒的に優れている。つまり良いことしかない。

　欧米でテレワークや電子決裁が進んでいる理由は、恐らく地理的な距離の問題でCOVID-19とは無関係にテレワークが必要だったからだ。
　欧米では日本に比して交通網は発達しておらず、最強のロジスティックを持つAmazonで商品を発注しても届くまでに一週間かかることはザラである（お急ぎ便で同日中に到着するロンドンなどの大都市の方が例外的である）。そういう距離感だから、社員がオフィスから自動車で2時間超の場所に住んでいることも珍しくなく、テレワーク≒対面することなくビジネスを進める方法が発達している。
　日本でもCOVID-19の影響でテレワークが進んだ結果「オフィスに出勤する必要なんてあったんだっけ？」という疑問を聞くことがあるが、それは欧米が既に通った道で、日本が先人から学ぶべき部分である。近視眼的には東京の会社に勤めるのに東京に住む必要があるのか考え直すべきであるが、より長期的・広範囲で考えれば、もし東京の会社に勤めるのに北海道や沖縄からでもテレワーク可能なら、中央集中と中央と地方との給与格差を是正でき、地方の経済発展に寄与する可能性がある。COVID-19自体は厄災には違いないが、国や社会を発展させる機会でもある。

　余談だが、河野太郎氏の行政改革・国家公務員制度担当大臣への就任を無任所大臣ということで降格人事とする批判もあったようだが、それは既成概念に囚われ過ぎだった感が否めない。
　古代ローマといえばユリウス カエサルは皇帝の概念を「発明」した人物として知られるが、彼は既に存在していた複数のポストを兼任することで絶大な権力を得られること（＝既成概念の抜け穴）に気付いた人物であった。そのポストのことを今日では「皇帝」と呼んでいる。河野氏とカエサルとを同列に並べる気は無いが、既成概念を合理的に理解した上で疑問を抱くことは大切だと思う。

GPT-3がRedditで1週間人間と会話していた

文章生成AI「GPT-3」がRedditで1週間誰にも気付かれず人間と会話していたことが判明 - Gigazine

　昨今のGPT-2/-3の成果や他の研究の成果を踏まえれば驚くことではないように思う。
　AIのテストとして著名なのがチューリングテストであるが、第2回AIブーム（1980～87年頃）から言われていたのがAIはナンセンスな質問に回答（誤答）してしまうという問題である。しかし、Redditのような掲示板で他者をAIだと疑っていない状況ではナンセンスな質問が行われるとは考え難く、合理的（メイク センス）で文章量や内容の多い作文はGPTのようなAIの得意分野といってよく、今回の事例はあらためて確認されたに過ぎないようにも思う。

　ところで、筆者は日本企業では見たことが無いのだが、欧米ではカスタマーサポートで製品やサービスの回答をボットに行わせる例が増えている。しかし、現行のボットはAIとは言い難くFAQ（よくある質問と回答）を返信するだけのものも多く、結局は人間のオペレーターに対応頂く場合が多い（一番厄介なのは、既にボットには解決不能/オペレーターによる解決が必要と判明済の問題でも、まずはボットが粘り強く対応してきて足止めを食らうことである）。
　Redditでのやり取りには経済的な価値は考え難いが、そのようなカスタマーサポート用ボットの性能・品質向上に期待したいところである。

　ちなみに、同AIの投稿の一覧はRedditで読むことができる。

最近の気になった話題（2020年第39週）

Arm Neoverseロードマップ

Arm Updates Its Neoverse Roadmap: New BFloat16, SVE Support - WikiChip Fuse
Arm Targets HPC with New Neoverse Platforms - HPC Wire

　Armがサーバー向けNeoverseプラットフォームのロードマップを更新したらしい。今年末に発表されると噂されるモバイル向けハイエンドコア"Matterhorn"の詳細が分からないため何とも言えないが、Neoverse N1まではモバイルと共通のコア、Neoverse N2はモバイル向けコア + SVE、Neoverse V1は専用コアになるのではと思う。

　まずこれまでの経緯を確認すると、Armはモバイル向けアプリケーションプロセッサー=Cortex-Aファミリーを主軸に製品展開を行ってきたため、サーバー向けはCortex-Aファミリーを流用したものだった。これはビジネス上は仕方のないことかもしれないが、第三者から見ると境界が曖昧だった。例えばAmazon AWSは2018年にCortex-A72コアを16コア集積したGraviton A1プロセッサーを発表しているがArmはこれをNeoverse "Cosmos"プラットフォームだと言っている。実際には既存のモバイル向けアプリケーションプロセッサーと周辺ロジックを流用したものなので、Neoverseプラットフォームの定義は非常に曖昧だった（もしGraviton A1がNeoverseなら、そもそもNeoverseって何だ？という話になる。恐らくはマーケティング/PR上の都合だろう）。
　2019年に発表されたNeoverse N1はCortex-A76コアをベースに最大128コアまでスケール可能なCMN-600メッシュネットワークなどの周辺ロジックを組み合わせたプラットフォームである。代表的な製品としてはAWS Graviton2（最大64コア）とAmpere Computing Altra（最大80コア）が挙げられる。

　今回発表されたロードマップだが、これまで名前だけ明らかにされていた次世代プラットフォーム「Zeus」＝Neoverse V1の内容とNeoverse Nシリーズの次期プラットフォームNeoverse N2の内容が説明された。
　Neoverse NシリーズはScale-out用のパフォーマンスと効率のバランスを狙ったプラットフォームで、来年登場予定のNeoverse N2では128-bit幅のSVEがサポートされる。Neoverse Vシリーズは最大パフォーマンス（Scale-up用？）のプラットフォームで、今年中に登場予定のNeoverse V1では256-bit幅のSVEがサポートされる。

　SVEはArmと富士通が共同開発した、128-bit単位で物理実装をスケール可能な128～2048-bit幅のSIMD演算命令である。
　現時点で実装済なのは富士通A64FXのみだが、Marvellが独自プロセッサーコアThunderX4でのサポートを表明している。128-bit以上のSIMDというとIntel AVXが有名だが、AVXでも実行時に動作周波数を落とす措置が取られたように、Load/Store・メモリー周りの負荷が高くなることが問題となる。物理128-bitであればLoad 16-byte x 2 + Store 16-byte x 1あれば十分だが、物理SIMD幅が広がるにつれてLoad/Store帯域を増やす必要があるためで、これは、もちろんCPU レジスターファイル-L1キャッシュ間のアクセスでも問題だがL1-L2キャッシュ間アクセスやCPUコア-メモリー間でも問題となる（A64FXの場合はその編も踏まえて設計されている）。それを踏まえると、HPCに特化した富士通A64FXの場合ではSVE 512-bit x 2という実装（Load/Store帯域 Load 64-byte x 2 + Store 64-byte x 1）だが、クライアント用・サーバー用であれば初期のAVXのように論理256-bit超でも物理128-bitで実装なんてこともあるのは当然で、Arm純正のサーバー用コアNeoverse V1/N2で各256-bit/128-bit幅というのは妥当そうに見える（恐らくはThunderX4も同等になるだろう）。

　そう考えると、Neoverse N2のCPUコアは恐らくCortex-A78か"Matterhorn"であろうと推測できる一方で、Neoverse V1のCPUコアはサーバー専用になる可能性が高いように思われる。

Samsung 980 Pro

The Samsung 980 PRO PCIe 4.0 SSD Review - Tom's Hardware
7GB/s級の転送速度を実現したSamsung初のPCIe 4.0 SSD「980 PRO」を試す - PC Watch

　SamsungがM.2 NVMe接続のSSDの新モデルを発表したそうだ。
　前世代970 Proとの主な違いとしてはPCIe Gen 4への対応（データ転送の帯域が約2倍）とNANDメモリータイプのMLCからTLCへの変更（書き込みに対する耐久性が約1/10）の2点が挙げられる。速度を取るか耐久性を取るか悩ましいところである。個人的には耐久性を取りたいので今のうちに970 Proを確保するかもしれない。Micron/Crucialは先に全面的にTLC NANDに移行済だから同価格帯で入手可能なMLC NAND採用SSDは全滅したと考えてよさそうだ。

　記事中で興味深いのは新開発のElpis Controllerのキュー数への言及だろう。旧来のSerial ATA・PCIe AHCIではキュー数は32コマンド x 1個で固定だったがNVMeでは最大64Kコマンド x 64K個に拡大されている。Phoenix（32キュー）からElpis（128キュー）で処理可能なキュー数が4倍に増えたという（各キューの深さは変更なし）。PhoenixはCortex-R5 5コアで構成されていたが恐らくコア数も増量されているはずだ。Phoenixの5コアの分担の割り当てが不明（例えばSATA時代のMCXコントローラーの場合、3コアがホストインターフェース・ランダムアクセス専用・シーケンシャルアクセス専用に分担されていた）のため何とも言えないが、Elpisではコア数の増量と動作周波数の向上とで前世代Phoenix Controllerの4倍程度のパフォーマンスになっている可能性もある。

　SLCキャッシュの項目は性能向上という観点では面白いが、個人的には怖い仕様である。
　「Intelligent TurboWrite」で一部の領域をSLCキャッシュとして使えるという機能だが、固定的に確保されているSLCキャッシュ（IntelligentでないSLCキャッシュ）6 GBはともかく動的に確保されるということはTLC NANDの一部を一時的にSLCキャッシュとして使うということで、例えば1TBモデルで最大108GBとされているがSLCはTLCの1/3の容量なのでTLC換算で324GB分のセルがキャッシュとして使われるということのように読める。
　ただでさえTLC化で耐久性が下がっているところで知らない間にSLCキャッシュとして寿命を擦り減らすというのは製品寿命が見積れなくなる不安がある。よく耐久性を測る指標としてDWPDなどが使われ「仮に1日にXX GB書き込むとしたらXX年もつ」という表現が見られるが、知らない間にキャッシュとして使われてしまうとその計算は成り立たなくなる。

Nintendo Switchのプラットフォームは長期化するのか

任天堂2020年3月期経営方針説明会 - 任天堂

　任天堂に限らないが、ゲームコンソールのプラットフォームの長期化が進んでいるのでSwitchプラットフォームの長期化自体は驚くことではない。個人的な疑問はプロセッサーを誰が供給するのか？という点である。

　プラットフォームの長期化の原因はハードウェアアーキテクチャーの寡占化によるものだろう。
　PlayStationを例に取るとPS1 (MIPS III)→PS2 (MIPS IV)→PS3 (PowerPC+Cell)→PS4 (AMD64)→PS5 (AMD64)といった具合で、以前は様々なアーキテクチャーが採用されてきたが昨今はPCアーキテクチャー（AMD64/Intel64）に統一されている。もしかするとベンダー間の移動（AMD→Intel、AMD→NVIDIA）はあるかもしれないが、同時代のハイエンドゲーミングPCクラスの高いパフォーマンスを得るなら必然的にPCアーキテクチャー（AMD64/Intel64）になるし、携帯ゲーム機ならスマートフォンに近いアーキテクチャー（Arm）になる。これはIT業界全体のトレンドなので任天堂/ソニー/Microsoftというゲームコンソールベンダーを問わず共通している。

　気になるのはNintendo Switchの後継に搭載されるプロセッサーだ。スマートフォンをはじめ携帯端末ではArmが寡占化しているので、次世代プラットフォームでもSwitchと同様にArmを採用することは可能だろう。しかし、問題はSwitchにプロセッサーを供給しているNVIDIAがモバイル向けプロセッサーを手掛けていない点にある。
　2017年3月に発売されたNintendo SwitchにはNVIDIAのSoC Tegra X1が採用されている。NVIDIAはこのSoCについて「500人年もの労力を、新しいゲームプラットフォームを作りあげるために、あらゆる面に注ぎ込んだ」とするものの、Tegra X1自体は2015年に発表されたAndroidタブレット用のモバイル向けSoCである。2019年にはSwitch Liteのリリースに合わせ改良版Tegra X1+に更新されたが、これはTSMCの製造プロセスを20nmから16nm FinFETに移行したものであるが、TSMCの20nmと16FFの違いは後藤氏の記事の通りフロントエンド＝トランジスター層のみの変更で、電力効率は向上したが設計レベルでの変更は行われていない。

　このTegra X1（デフォルトの消費電力10w）は現時点でNVIDIAの最後のモバイル向けSoCである。NVIDIAは2016年にTegra X2（7.5w）・2018年にXavier（10～30w）が発表したが、車載向けに軸足を移しており、これらのSoCにはCANなど車載で必要な（モバイルSoCでは不要な）インターフェースが多数あったり、価格が高かったり、消費電力が高めに設定されているなど、Switchのようなモバイル機器に適しているとは言えない。また、Tegra X1後継のモバイル用プロセッサーのロードマップも知られている限りでは存在しない。
　任天堂は2021年にSwitch Proをリリースすると言われているが、果たしてNVIDIAが任天堂向けにカスタムチップを作るのだろうか？疑問である。既に世界で6,000万台を販売しているNintendo Switch向けならば専用プロセッサーを用意しても投資は十分に回収できると思うのだが、NVIDIAから何も情報が聞こえてこないのが不思議である。もし仮に任天堂がSwitchの次世代機のプロセッサーをNVIDIA以外から調達するとなると、Snapdragonを要するQualcomm・AMDからGPU IPのライセンスを受けるSamsung・RDNA2 GPU IPにCortex-X1 + Cortex-A78を組み合わせたRyzen C7がウワサされるAMDが候補となると思うが、ゲーム機ビジネスはスマートフォンとは違うのでGameCube/Wii/WiiUで繋がりがあったAMDかもしれない。

藤井二冠がRyzen Threadripper 3990Xを使用

藤井聡太二冠「自作PC」の値段にパソコンマニアもびっくり - NEWS ポストセブン

　「藤井二冠がRyzen Threadripper 3990Xを使用している」という話題は様々な記事で見かけた（＆スルーしていた）のだが、CPUが50万円することなどばかりが話題となっており、意外なことに多くのオンライン記事ではその用途について詳しい言及が無かった（中日新聞紙面では一面割いてインタビュー記事が掲載されているらしい）。

※当初「藤井二冠が50万円のRyzen Threadripper 3990Xを使用している」と聞いてビデオゲームでもするのかと想像してしまったが、まったく違う非常に建設的な使用方法で、いわば「ピアノコンクール優勝者がSteinway & Sonsのピアノを購入した」というような話だった。価格を強調した見出しは誤った印象を与えるので止めた方が良いと思う。

どうやら将棋ソフトの読みの速さにはマルチコアCPUが効くのだという。

CPUの性能で読みの速さが変わります。家庭用パソコンのCPUが1秒間に約200万手読むのに対し、藤井二冠が使っているCPUでは30倍の6000万手読めます。短時間でより多くの局面を検討できるので、効率よく研究できます

この30倍の数字がどう計算されたか示されていないが、例えばThreadripper 3990Xは64コアのため家庭用パソコン＝2コアの32倍あると考えれば辻褄が合うのでおかしな数字ではない。

　加えて、恐らく多数の組み合わせパターンを評価して最適なパターンを導き出すことになるから、パターンを計算するための学習データ・膨大なパターンとその評価を格納するメモリーが必要になるはずである。記事中にも「藤井二冠の妙手「3一銀」が、将棋ソフトが4億手読んだ段階では悪手なのに、6億手読むと最善手になることが話題となった」とある通り、読む手数が少ない場合と多い場合とで最善手が変わってくることも考えればメモリーに格納するパターン数や評価値も膨大な量になることが想像できる。確かにThreadripperに256GBのメモリーというのは非常に妥当な構成に思える。

海洋研究開発機構（JAMSTEC）が4代目「地球シミュレーター」にNEC SX-Auroraを採用

次期“地球シミュレータ”にNECのスパコン「SX-Aurora TSUBASA」が採用 - PC Watch

　NECは2017年にSX-Auroraの発表したが何度かリフレッシュを行っており、NECによると地球シミュレーターに採用されるのはB401-8のようである。これはIntelアーキテクチャーベースのサーバーにSX-Aurora PCIeモジュールを8基搭載したものである。

　以下は過去の地球シミュレーターの変遷を表にしたものであるが（※注：SX-AuroraのスペックはホストのIntelアーキテクチャーのノードは含まれていない）、概ね7年毎に更新されているようだがパフォーマンスの向上は3.1～15倍とばらつきがある。初代地球シミュレーターがいかにオバケだったか分かる気がする。
　気になるのはHPCで重視されるFLOPS性能に対するメモリーバンド幅（B/F）が下がっていることである。SX-ACEなどは16 chメモリー（計1024-bit幅）を使ってでも帯域を確保しており当時のGPGPUなどと比較しても圧倒的であったが、SX-AuroraではNVIDIAやAMDのハイエンドGPUと同じHBM2で差は無くなっている。

　SX-Aurora登場当初のラインナップではIntel Xeon "Skylake-SP"をホストに使い、2ソケット構成にPCIe Switchを組み合わせて8台分（PCIe x16 x 8 = 128 lane）のレーン数を稼いでいたが、B401-8ではホストがAMD Epycとなり1ソケットでPCIe 128レーンを実現している。
　WikiChipなどでは2019年のSC19で発表されたType 10からType 10Eへのリフレッシュに関する記事が見つかるが、NECのスペックシートによるとType 20のようでType 10E比でベクトル演算性能が約50％・メモリー帯域が約20％程度向上している。

		Gen 1	Gen 2	Gen 3	Gen 4
Year		2002 - 2009	2009 - 2015	2015 - 2021	2021 -
Base		NEC SX-5	NEC SX-9	NEC SX-ACE	NEC SX-Aurora
Node	CPU	64 GFLOPS	102.4 GFLOPS	256 GFLOPS	24.57 TFLOPS (3.07 TFLOPS x 8)
	RAM	16 GB 463 GB/s	128 GB 256 GB/s	256 GB 256 GB/s	384 GB (48 GB x 8) 12.24 TB/s (1.53 TB/s x8)
	B/F	7.2 B/FLOP	2.5 B/FLOP	1.0 B/FLOP	0.49 B/FLOP
System	# of Nodes	640 Nodes	160 Nodes	5,120 Nodes	684 Nodes
	CPU	40.96 TFLOPS	131 TFLOPS	1.3 PFLOPS	19.5 PFLOPS
	RAM	10 TB	20 TB	320 TB	262.66 TB

IBMがOpenPOWER FoundationでA2Oを公開

IBM Contributing A2O Processor Core To OpenPOWER Community - Phoronix

　以前の記事でも触れたが、7月にIBMはBlueGene/Qで採用されたA2IコアをOpenPOWER Foundatioに寄贈し無償公開した。今回はOut-of-Order実行に対応したA2Oコアを寄贈・公開したらしい。

　BlueGene/Qの発表時はA2コアとされていたのが7月にはA2Iとなっていたため何のことかと思ったら、A2IはIn-Order実行コア・A2OはOut-of-Order実行コアということらしい（一部でA20（a-two-zero）と記載の記事もあるがA2O（a-two-o）である）。
　A2I・A2O共にGitHubでマニュアルが公開されているが（A2I・A2O）、構成は似て非なるものである。以下は概要を表にまとめたものだが、FXUは整数演算ユニットでA2Iについては固定小数点演算も可能なようだがA2Oにはその記載が無い。AXUは倍精度浮動小数点演算も可能なISAで定義された命令すべてを実行可能なユニットとのことである。表にまとめてみるとよく似通っているようにも思えるが、各マニュアルのp45～50あたりの記載やブロック図を見てもあまり類似しているようには見えない。

	A2I	A2O
ISA	Power ISA 2.06	Power ISA 2.07
L1$I	16 KB	32 KB
Decode/Issue	2 inst/cycle	2 inst/cycle
SMT	SMT4	SMT2
Execution	In-Order	Out-of-Order
Simple FXU	-	1
Complex FXU	1	1
AXU	1	1
Branch	1	1
LSU	1 64-bit width	1 64-bit width
L1$D	16 KB	32 KB

最近の気になった話題（2020年第38週）

TSMCによるHuawei/HiSiliconへの出荷停止

「米国に売られたケンカ」は買うしかない？ 絶体絶命のHuaweiに残された手段とは - EE Times

　個人的にはSMICのエンティティリスト入りは時間の問題と思う。
　そもそもSMICは米国政府からすれば潰したい企業の上位にいるはずで、同業の台湾TSMCが標的となっていることはすでに知られている（引き抜き自体は合法と想像するが、米国・欧州などが警戒を強めている）。

　米国による規制は5G通信機器やAndroid OSという最終製品に近い製品から始まり、徐々に基礎技術・材料へと遡ってきているように見える。仮にZTE・Huaweiの通信機器に規制を掛けても、Huawei/HiSilicon製の半導体が出回れば意味が無いし、Huawei/HiSikiconの半導体製造をTSMCで止めても、SMICが蘭ASML・米Applied Materials・米Lam Research・日TEL・日Nikonなどから最先端の製造装置を仕入れて最先端に近い水準の半導体を製造できてしまうと意味が無いし、ASMLなどの企業からSMICなどの半導体製造企業への製造装置の輸出を停止できても、SMEEやNAURAなどの中国の半導体製造装置企業が自前で作ってしまっては意味が無いからである。

　今回の輸出規制でHuawei/HiSiliconに対する規制がある程度固まったとするならば、次はSMICとなるのは当然のように思える。英BBCなどでも既にSMICの名がニュースに登場するようになり、EU製のASMLの装置の禁輸措置も進んでいる。

NVIDIAによるArm買収

　様々なメディアが触れている通り、Armの理想的な立ち位置は半導体企業から中立な立場であることで、NVIDIAによる所有に批判的な意見もあるようだが、売却されてしまったのは仕方がない。以前も述べたが、2016年以前とは異なりArmはもはや独立企業ではなく、その親会社＝ソフトバンクは3兆円を支払える売却先を探していたからだ。

政府からの承認

　筆者は法律は門外漢なので難しい問題であるが、とりあえず1国を除き承認されるものと想像する。そもそもArmは2016年に日本（EU圏外）のソフトバンクに買収されていたわけで英国/欧州企業以外が買収できない理由はない。ましてや、Armは本社を英国Cambridgeに置きつつも目玉のハイエンドCPUコアCortex-A7xファミリーは米Texas（と仏Sophia-Antipolis）のチームが開発している。そのことを考えるとArmが米国資本になることは、ある意味で「ねじれ」を解消するとも言える。

　最大の問題は中国であろう。
　米中間の貿易摩擦でHuaweiのエンティティリスト入りは有名なとことであるが、Huaweiの一件でもArmは英国企業であることを理由に米大統領令の対象外と主張し、傍から見ていて説明が二転・三転しているように見えた。2019年5月に方針転換してライセンス供与しない方針を打ち出したかと思えば、11月には英国の知的財産であるという理由でライセンス供与の続行を表明している。米国政府の中国に対する姿勢には賛否両論あろうが、この一貫しない姿勢は異質に見える。親会社がNVIDIAになることで姿勢が一貫したものになることだろう。

　Armが米国企業傘下に収まり米国政府の影響が強くなることは、米国政府および企業の立場からすれば歓迎すべきことだが、中国政府および企業の立場からすれば好ましいとはいえない。
　先に述べた通り、Armは既に日本企業の傘下となっているため米国企業が買収できないと理論的・法的に横槍を入れることは困難と思うのだが、しかし、中国の場合は「承認いない/回答の先延ばしする」という驚くべき手法が採れる。例えば2017/18年の米Qualcommによる蘭NXP買収（未成立）の場合、Qualcommは買収計画の発表後20ヶ月を費やしたにも関わらず中国当局が承認を先延ばしにし続け期限内に完了しなかったため破談となった。今回も18ヶ月以内に承認されなければ破談となる可能性がある。

得をしたのはソフトバンク？

　筆者は経済・経営も門外漢なので、専門家は異なる見方をするかもしれないが、個人的にはソフトバンクは今回の取引で大きな得をしたと思う。
　そもそもソフトバンクがArmを買収した2016年当時でも、その企業価値は認めつつ「3.3兆円もの価値はあるのか？」と言われてきた。具体的にはEV/EBITDA倍率（税引前利益に対する時価総額の倍率）が一般的には8倍程度が大きい中で3.3兆円という買収額（≒企業価値）は34倍を超える（つまり利益率低すぎ）という状態だった。
　さらに言えば、今回は売り時に売るというよりもソフトバンク・SoftBank Vision Fundの1.9兆円の赤字補填のためという意味合いが強い＝売り手側の弱みが見えている状況だったので、4.2兆円を取得し、しかも半分以上がNVIDIA株での支払いというのは、個人的には意外にソフトバンク有利な条件に思う。ソフトバンクはたびたびNVIDIA株を取得しているが、NVIDIAが時価総額でIntelを抜いたように株価が上昇する≒SoftBank Vision Fundで利益が出せる可能性がある。

ArmによるNVIDIA GPU IPの提供

　現時点でNVIDIAとArmで重複するのがGPU（NVIDIA GeForceファミリーとArm Maliファミリー）だろう。現在のNVIDIAはモバイル用プロセッサーを手掛けていないが、以前はAndroidタブレット用にTegraファミリー・現在も車載向けSoC Tegra/Xavierファミリーに搭載しているように派生品を用意することは可能だろう。

　個人的な推測だが、NVIDIAはArmを通じてライセンスビジネスを復活させるのではないか。
　NVIDIAは2013年にGeForce"Kepler" IPがライセンス供与可能であると発表したことがある。筆者の知る限りライセンスを受けてNVIDIA GPUを採用した企業は存在しないが、再度参入する可能性はありそうだ。モバイル向けに浸透しているArm Maliに対しNVIDIA GPUは高性能ながら消費電力/発熱に対する評価は芳しくないから、NVIDIA GPUでMaliを置き換えるのではなくMaliの上位のゲーミングモデルにNVIDIA GPUを据えるという形になるのではと思う。

　こういうビジネス（アイデア）はあると思う。
　例えばSamsungはAMDからGPUのIPのライセンスを受けているが（参考1、参考2）、Arm/Imagination製GPUを採用する他社との差別化のためハイパフォーマンスGPUのライセンスを以外から受けることは合理的だ。もしNVIDIAがGeForce GPUをMaliの上位としてライセンス提供するのであれば採用する半導体メーカーがいても不思議ではない。

　ただ、コモディティのアプリケーションプロセッサー＝Qualcomm SnapdragonやMediaTek Helioを採用した端末との差別化のため半導体事業に手を出す半導体企業が多数あるわけでもない。そういった差別化が有名なのはApple A・Samsung Exynos・Huawei/HiSilicon Kirinぐらいだが、AppleはCPU・GPUとも内製しているため必要ないし、Huawei/HiSiliconは米国の対中政策の影響でそれどころではない。Appleについては今後のArm Macの方向性でどうなるか分からないが、あまり市場規模は大きくなさそうだ。

Armの顧客

　ArmにあってNVIDIAに無い最大のものはIoT関連の資産と顧客だろう（もっとも、今回の取引ではTreasureDataなどArmのIoT関連資産が含まれていないようだが）。
　NVIDIAはPCにGPUを供給しているし自動運転用のコンピューターのリーダーでもある。それらもEdge IoTには違いないが、一般にIoTで想定される各種センサー類とコントローラーの消費電力（数mW～1W程度）と比較すると消費電力が10〜100倍程度大きい（10W～。車載向けのXavierで10～30Wである）。その結果、NVIDIAはDeep Learningのリーディングカンパニーであるにも拘らず、いわゆるEdge AIには浸透していない。

　IoTは市場でのDeep Learningはまだ方向性が定まっていないように思うが、Armはビッグプレイヤーの1社であることは間違いない（センサー周りのDSPが必要な分野ではCadence Tensilica Xtensaが便利なはずで、実際Xtensaを採用した中国Espressif ESPシリーズが躍進している）。NVIDIAは同社がXavier向けに開発したDeep Learning用アクセラレーターNVDLAでArmとパートナーシップを組んだことがあるが、今後はそのようなArmを通じたNVIDIA製IP製品が増えるかもしれない。

NVIDIAはArmを吸収するのか？

　世の中の企業には他社を買収した後、買収された側のブランドを残す企業と残さない企業と、その両方を使い分ける企業とがある。日本企業はほとんどの場合で買収された側のブランドを廃止するように思うが、ブランドは資産/知的財産なので安直に廃止するのは財務的に損失となるので一概に買収された側を廃止する方が良いとも限らない。
　NVIDIAは伝統的に買収された側のブランドを残さない企業で、最近買収したMellanox（mellanox.com）もCumulas Networks（cumulasnetworks.com）もWebサイトにアクセスるとNVIDIAのロゴに挿し代わっている。

　しかし、Armは本社を英国に残すと明言しているため、しばらくは半独立状態を保つのではないか。多くの企業・メディア・アナリストが指摘する通りArmのIPビジネスでは中立が重要なので、実態はともかく社名や本社を維持することで建前上は独立を保つことになると思われる。

最近の気になった話題（2020年第37週）

MicrosoftがXbox Series Sを発表

299ドルで“一番小さい”「Xbox Series S」海外発表 - AV Watch
Microsoft to charge $200 for 32 GPU cores, sliver of CPU clockspeed, 6GB RAM, 512GB SSD... and a Blu-Ray player - TheRegister

　Xbox Series Xの廉価版の登場は以前よりウワサされていたが、発表されたXbox Series SのスペックについてはThe Registerの記事に詳しいが予想を大幅に下回る内容だった（後述）。

　そもそも、Xbox SeriesXのスペックはコンシューマー向けとは思えない歩留まりを無視したスペックで、グレードを落とした製品が存在しなければ説明がつかない内容だった。
　GPUはシリコンレベルでは56 CUが搭載されており、うち52 CU（92％）が有効化されている。この数字はCUの欠陥をほとんど許容しないスペックで歩留まりが悪くなるのは当然といえる。例えば同じAMD RDNA系GPUを搭載するAMD "Navi 10" RX5000シリーズの場合、シリコンレベルでは40 CUが搭載されているが、実際に40 CU（100％）が有効なのはRadeon RX 5700 XT（$399）のみで、Radeon RX 5700（$349）およびRadeon RX 5600 XT（$279）では36 CU（90％）、Radeon RX 5600（$200）では32 CU（80％）のみが有効となっている。
　一般に半導体製品はダイサイズが大きくなると不良率が上がるが、251 mm2のNavi 10でもこういう調子だから、$499のXbox Series Xで360mm2のXbox Series X用プロセッサーのCUが92％有効というのは驚異的な数字で、RX 5700 XTに対するRX 5600のようにグレードを落とした廉価版≒Xbox Series Sが存在するのは当然と言える。

　以上のような理由から、Xbox Series Sの登場は予想できたとはいえ、そのスペックは予想を大幅に下回るものだった。
　ここで、私が予想していたのは以下のようなスペックである。表のうち左から参考としてXbox Series X・前世代Xbox One Xのスペック、右側にXbox Series Sの筆者予想と実際に発表されたスペックを示している。

09/19 - 記事の投稿後に出てきた詳細なスペックで更新しました。本旨には大きな影響はありません

	Xbox Series X	Xbox One X	Xbox Series S （筆者予想）	Xbox Series S （実際）
CPU Core	AMD Zen 2 8C/16T	AMD Jaguar 8C/8T	AMD Zen 2 8C/16T	AMD Zen 2 8C/16T
CPU speed	3.6 GHz (w SMT) 3.8 GHz (w/o SMT)	2.3 GHz	around 2.0 GHz	3.4 GHz (w SMT) 3.6 GHz (w/o SMT)
GPU # of CU	52 CU	40 CU	36 CU or 30 CU	20 CU
GPU performance	1825 MHz 12.15 TFLOPS	1173 MHz 6.0 TFLOPS	1300 or 1564 MHz 6.0 TFLOPS	1565 MHz 4.0 TFLOPS
RAM capaicty	16 GB	12 GB	12 GB	10 GB
RAM bandwidth	560 GB/s (10 GB) 336 GB/s (6 GB)	326 GB/sec	336 GB/s (6 GB)	224GB/s (8 GB) 56GB/s (2 GB)

筆者予想のスペックではXbox Series Xと互換性を維持しつつXbox One Xをエミュレーション可能そうなスペックを予想している。しかし、実際に発表されたXbox Series SスペックはGPUとメモリーのスペックが大幅に劣るものでXbox One Xのエミュレーションには性能が圧倒的に不足している。実際EuroGamerは「Microsoft confirms Xbox Series S won't support Xbox One X backward-compatibility enhancements（MicrosoftはXbox Series SがXbox One Xの後方互換をサポートしない）」と報じている。

　恐らく多くのデベロッパーはXbox Series X・PlayStation 5両対応のゲームを開発するだろうが、Xbox Series Sにも対応するかどうかは要求されるスペック次第で対応タイトルが増えない可能性もある。それでも、もしXbox One X対応ゲームタイトルに対応していれば（仮定）それなりにヒットしそうな気がしていたのだが…個人的には、Xbox One X非互換なXbox Series Sが売れそうな気がしない。