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

Apple Intel Coreから自社製"Apple Silicon"への移行を発表

AppleがArmベースのSoCをMacに採用する背景 - PCWatch

　このApple Siliconなる名前が気に入らないが…。IntelのCoreやIBM/Sony PlayStation 3 CPUのCELLなど一般名詞の固有名詞化は今回に始まったことでもないが、いくらなんでも語呂が悪すぎ・ダサ過ぎではないか。もっとも、AppleのiPhone/iPad用Aシリーズ・AppleWatch用Sシリーズ・MacのTouch ID用Tシリーズ・AirPods/AppleWatchのWi-Fi用WシリーズといったApple製カスタムSoC群を総称してApple Siliconと呼ぶようだから、実製品の発表時には別のブランド名になっているかもしれない。

　AppleのARMアーキテクチャライセンスに基づく自社開発CPUコアのIPC（動作周波数あたり/1コアあたりの実行性能）でIntel Core系プロセッサーに比肩することは2008年にA7に搭載されたCycloneコアの登場以降、新コアが発表されるたびに話題となった（参考1、参考2）。
　もっとも、A7の場合ではTDP 5W以下のはずでiPhoneで2コア1.2 GHz・iPadで2コア 1.4 GHzに過ぎないから、iMacやMac Proに搭載されるようなTDP 65W超で3.0 GHz 4コア以上のIntel Core/Xeonプロセッサーに絶対的なパフォーマンスで勝てるはずはなかったが、TDP 15W程度のMacBookにiPadが肉薄しており、さらに言えば、iPad Proにも搭載されているA12Zではハイパフォーマンスコアが4コアだから最新のハイエンドiPadとエントリーレベルMacBookとの差は2008年から年々縮まってきていたのが現状である。
　これらを踏まえればIntel x86-64からARM64への移行でパフォーマンス面への疑問は少なかったのではと思う。

　問題はアーキテクチャー移行による対応ソフトウェアの問題だろう。
　MacOS向けアプリケーションはPowerPCからIntel x86-64への移行時と同様にRosettaで変換するとして、BootcampでWindowsを動かすことはできなくなる。私は個人的にはMacのARMへの移行には懐疑的だったが、その主な理由はBootcampで、MicrosoftがWindows on ARMのマーケットを拡大してから移行するものと思っていた（※いや、もしかしたら待てど暮らせどWindows on ARMが普及しないので見切ったのかもしれないが…）

Rosetta 2での変換によるパフォーマンス低下

ArmベースMac移行用のDTK、ベンチマークスコアが流出 - Engadget

　Engadgetの記事が酷いことは置いておくとして、Intel x86-64ネイティブアプリケーションをRosetta 2で変換して実行した場合、概ね20～40％のパフォーマンス低下ということになるようだ。

　そもそもプロセッサーが異なるため何をもって「XX％パフォーマンス低下」とするか悩ましいところだが、仮にA12ZのLightningコアがIntel CoreのSkylakeのコアと同等と仮定し、かつIntelのTurboを無視した場合、シングルコアあたりでIPCが38％程度しか達成していない計算である。これはエミュレーションした場合のオーバーヘッドとしては経験則（パフォーマンスが約1/3）に近く妥当な数字である。恐らく実際にはCore i3のTurboが効いているはずなので実際は1/2～1/3ではないかと思うが。
　A12Zのマルチコアが一見すると健闘しているように見えるのは4コアが搭載されているからで、4コアと2400MHzという動作周波数を考えれば妥当そうに見える。

	A12Z	Core i3-1000NG4
Geekbench Single-core	around 750 - 850 (Avg. 825.91)	1005
Geekbench Multi-core	around 2550 - 2950 (Avg. 2851.23; 712.81 per core)	2014 (1007 per core)
Arch	Lightning	Comet Lake
Core	4C/4T	2C/4T
Freq	2400 MHz	1100 MHz (Turbo 3200 MHz)

　逆の言い方をすれば、Appleがオーバーヘッドでパフォーマンスが1/2～1/3になってもIntel x86-64からARM64へ移行できると判断したということは、同じ消費電力枠・同じコストでコア数や動作周波数の引き上げで2～3倍のパフォーマンスを達成（つまり合計でイーブン）できると判断したということなのだろう。
　例えば、上述の通りA8XはCPUコア単体ではIntel Coreと同等クラスのIPC（動作周波数あたり/1コアあたりの実行性能）を達成していたが、3コア・1500 MHzでしかなかった。これでは絶対的なパフォーマンスでA8Xが当時のCore i3と相当を達成できるとは考えられない。それが、A12Zでは上の表の通りCore i3と同等のパフォーマンスを達成しているように見えるのは、A8Xの2014年から6年間を経てIPC向上・コア数の増量・動作周波数向上を積み重ねた結果と言える。A12ZのTDPは公表されていないが他のタブレット用アプリケーションプロセッサーと同等とすれば5W以下のはずで、Core i3-1000NG4のTDP 8Wを下回っている。

Intel Lakefield

「Comet Lake」と「Lakefield」について新しく深くわかった事 - マイナビ
発表されたLakefieldはカスタマイズ版Windows10向け - ASCII
Intel Launches Lakefield: An Experiment With Multiple New Technologies - WikiChip

　Lakefieldの発表記事を読んで苦笑したりガッカリした人は筆者だけではないはずだ。

　LakefieldはIntel版big.LITTLEとも言える、省電力コアとハイパフォーマンスコアを組み合わせた構成となっている。ARMがbig.LITTLEを発表したのは2013年のことなので、見方を変えればIntelには7年間もの猶予があったとも言えるわけだが、そんな中登場したLakefieldは、とても歪に見える。

　前提としてARMが実装したbit.LITTLEについてはPC Watchにて後藤氏が詳しく解説されているので割愛する（2013/12/18の記事、12/20の記事）が、ARMは2013年から現在のDynamIQに至るまで4段階に分けて段階的に実装してきている。キモは (1) 同じ命令セットをサポートするbigコアとLITTLEコアが同時にリリースされていて（ARMv7-Aのbig.LITTLEでCortex-A7/A15・ARMv8-Aのbit.LITTLEでCortexA53/A57・ARMv8.2-AのDynamIQでCortex-A55/A75）(2) それらをサポートするためのバスなどのハードウェアやスケジューラーなどのソフトウェアが同時にリリースされている点であろう。

　IntelなりMicrosoftなりがARMの実践したものを踏襲したり、ARMが築いたインフラをそのまま利用しようとするならば、必然的にbig.LITTLE/DynamIQの制約を受け継ぐことになるわけだが、この制約のためにLakefieldでは各種機能が無効化されているようだ。

　現在のIntel CPUについて振り返ってみると、Core系コアとAtom系コアの2種類のコアが存在し前者がハイパフォーマンス・後者が電力効率に最適化されている。その意味ではbig=Core系コア・LITTLE=Atom系コアでbig.LITTLEを構成するというアイデアは解らなくもない。
　しかし、問題は命令セットで、Core系コアはCoreブランドではSSEだけでなくAVX/AVX-2/AVX-512をサポートするのに対しAtom系コアも含まれるPentium/CeleronブランドではSSE4.2までしかサポートしていない。そのため、LakefieldではSunny Coveコアが搭載されているにも拘らずAVX/AVX-2/AVX-512が無効化されSSE4.2までのサポートに留まっている。また、Sunny Coveコア・TremontコアはそれぞれSMTに対応するがこちらも無効化されている。

　つまり、bigコアとLITTLEコアとで命令セットを共通化したりスケジューラーを準備することでbig.LITTLEを整備してきたARMに対し、Intelの実装はbig.LITTLE相当の構成をとる準備が不足している感が否めない。例えばTremontコアにAVX-512は無理でもAVX/AVX-2の実装は難しくはなかっただろうし（※AVX-512は物理512-bitでの実装が必須だが、AVX/AVX-2では物理128-bitでもSSEを拡張することで実装可能である）、記事中で指摘されているようなコア数やSMTの制限についても改善できたのではと思う。

理研「富岳」

Top500の1位は理研の富岳スパコン、Green500はPFNのMN-3が獲得 - マイナビ

　理研と富士通が開発してきた「富岳」が1年前倒しで稼働開始となり、Top500の1位を獲得した。
　既報の通り「富岳」はHigh Perf LINPACK（HPL）に最適化されているわけではない上、来年以降で米国・中国の1 ExaFLOPSクラスHPC計画が続々と控えていることから来年のどこかで別のシステムにTop500トップの座を奪取されるものと思われる。

　ところで「1年前倒し」というのは驚異的なことのように思われるが、個人的には1年遅い計画の方がおかしかったと思う。
　例えば前回までTop500 1位だったORNL/IBM Summitは2018年6月から首位を保持しているが、搭載されているIBM POWER9は2017年8月・NVIDIA Volta V100も2017年12月に発表されている。プロセッサーの製品化からHPCシステムの稼働まで半年しかない。半年というと短いように思われるがエンジニアリングサンプルなどを合わせると恐らく+1年間程度（合計で1年半ほど）はあっただろうからIBMやNVIDIAがメインボードやOSやドライバーなどを整備することは並行して可能なので驚くことではない。
　これに対しA64FXの最初のシリコンが発表されたのは2018年6月のことである。恐らく富士通・理研内ではCPUの検証・デバッグと並行してOSやドライバーなどの整備も進んでいただろうが、それを踏まえて2019年12月に建造開始・2020年6月に稼働開始というスケジュールは妥当で、むしろ2021年6月に稼働開始したらその方が驚きだ。

「富岳」はお金が足りなくて0.5 ExaFLOPSなのか？

　マイナビの記事も執筆されているHisa Ando氏は「富岳は、ラックが432本並ぶ構成となっている。なお、京コンピュータは864本であったので、ラックの数では半分の規模となっている。技術的には864ラックのシステムとしてエクサスケールのスパコンとすることは可能であるが、お金が足りなかったという」と、予算不足を指摘されているが、これについてはどうかと思う。

　まず、私の理解では2018年頃（まだ「ポスト京」と呼ばれていた時期）の時点で既に1 ExaFLOPSにはならずHPLで500 PFLOPS程度にしかならないという話だったかと思う（その根拠の記事は調査中）。
　「富岳」が目指していたのは「アプリケーション性能で「京」の100倍」という話だったかと思うが、半導体業界で有名な「ムーアの法則」（半導体スケーリングの問題で鈍化・法則が崩れつつあるが）を参考にするなら「京」の登場した2012年から2021年では9年間＝108カ月で、つまり「富岳」は「京」の2^6倍＝64倍の性能が期待できる。「富岳」のプロセッサーA64FXは「京」のSPARC64VIIIfx比でトランジスター数が11倍・コア数が6.5倍・FP64性能が21倍・FP32性能が42倍に増加している（つまりノードあたり21～42倍の性能）。これは法則通りの64倍からは乖離しているが、一方でノード数は1.8倍に増えている（88,128ノード→158,976ノード）。そのため、結果としてアプリケーション性能が約40～100倍の間という数字は妥当そうに見える。

　次に、予算の総額の観点から見れば「京」は1120億円（2012年当時）で、一方の「富岳」は1300億円（2019年時点での計画）で、2012年から2019年の日本のインフレ率を当て嵌めて計算してみても2012年当時の1120億円は2019年での約1190億円相当と考えられ、1300億円というコストが不足しているとは考え難い。むしろ「京」ですら事業仕分けされそうな危機に陥っておきながら「X000億円あれば二倍にできたが予算が足らなかった」と言うのならX000億円の予算を確保できるという想定が間違っている。もちろん一般的なインフレ率とIT業界・半導体業界のインフレ率に乖離がある可能性はあるが、とりあえず「十分な予算はかけた（お金が無かったわけではない）」と思われる。

　要するに、私から見ると計画通りに開発・構築した結果、予想通りに「京」比で40～100倍の性能になったという話で、「アプリケーション性能で100倍」という点を誇張した当初の計画の方に問題があった気がしなくもない。

　ところで、864ラック入れられるところを432ラックになった件については、個人的にはむしろ今後はより軽い開発に移行して開発コストを6割程度に落として432ラック単位で設置とすべきだと思う。

　神戸市の理化学研究所計算科学研究機構には「京」1システム（＝864ラック分）しか設置スペースが無く、そのため「富岳」導入にあたり2019年8月で「京」を停止していた。言い換えれば10カ月の空白期間が空いていた。もっとも、「京」自体が約8年も前に導入した古いコンピューターで電力効率もコストあたりの性能も良くなかったから撤去することは間違ってはいない。
　私が提案したいのは、開発コストを圧縮して4～5年単位で新システムを半分（432ラック）ずつ導入する方式である。「京」を例に挙げると、「京」では富士通がSPARC64fx VIII（2009年）を開発したが、その後富士通はコア数を16コアに倍増したSPARC64 IXfx（2011年）・さらに32コアに4倍増したSPARC64 XIfx（2015年）を発表しているにも拘らず「京」（あるいは理研）はそれを導入していない。2015年時点で432ラックのシステムを組んでいれば「京」の8倍近い性能のシステムができていた可能性もあり、そして、既成のSPARC64 XIfxを使うのであれば1000億円を超えるような馬鹿げた予算は必要なかったはずである。
　この方式の場合、4～5年間単位で432ラックずつ入れ替えるため、「京」のようにシステムを停止して1年間近く空白期間が空くなどということはなくなる。

※米国のフラッグシップHPCはシステム単体では$500M（約600億円）程度である。この理由は多数あろうが、(1) 研究予算とシステムの予算が分割されており$500Mはシステムのコストである (2) 米国企業の既成のプロセッサーを流用している、の2点が大きいだろうと思う。

今週の気になった話題（2020年第24週）

Jim Keller氏がIntelを辞職

Intel CPUアーキテクトのジム・ケラー氏が辞職 - PC Watch

　多数の有名なプロセッサーを手掛けたCPUアーキテクトとして有名なJim Keller氏がIntelを辞職するそうだ。今回が前回（Tesla）や前々回（AMD）と少し異なるのは辞任後も6カ月間にわたってコンサルタントとして携わることが明言されている点だろう。

　聞いた話になるが、Jim Keller氏に限らずCPUアーキテクトが企業を渡ることは珍しくないようだが、実際の製品が市場に投入される何年も前に離職することが少なくないようだ。近年の高性能CPUは約4年間の開発期間を要するのに対し、アーキテクトが設計するのは最初の～2年間程度の上流工程だからだ。
　例えばZen開発に関してAMDに参加したのは2012年8月のことであるが2015年9月に辞職し2016年1月にTeslaに参加、同職を2018年4月に辞職してIntelに移籍している。AMDの場合はZenが発表されたのは2017年3月のことで、Teslaの場合もFSDが発表されたのは2019年9月のことだから、いずれも1年半ほど前に辞職していたことになる。

　もちろん、今回も辞職後半年ほど経ってから別の企業に移籍するということは十分に考えられそうだが今回はHotChipsでの基調講演が予定されている状況での辞職のため、あらかじめ計画されていなかった可能性が高そうだ。

AMD Ryzen 3000CシリーズSoC

AMD Ryzen 3700C and 3250C Benchmark Results Point to Google Zork - Tom's Hardware

　Google Zork向けというAMD Ryzen 3700C・3250CがGeekBenchの結果に登場したそうだ。
　記事中ではGoogle Zorkを「2-in-1のPixel Bookではないか」と言っているが、恐らくChromeOSベースのデバイスだろう（※注：Pixel BookはChromeOSデバイスである）。Androidベースのデバイスと異なりChromeOSベースのデバイスではIntelプロセッサーが標準でサポートされているし、ChromeOSデバイス用プロセッサーにサフィックス「C」が付く例はこれまでもあった（例：Rockchip RK3288C）。

　Ryzen 3000Cシリーズが興味深いのは、Tom's Hardwareの記事中にある通り、通常のRyzen 3000U/3000G APUとは異なりチップセット無しのSoCであることだ。実際には、Zen/Zen+世代Ryzen APU（Raven Ridge / Picasso）はRyzen Embedded V1000・R1000シリーズに見られるようにチップセット無しのSoCとして利用できるため不思議な事ではない。

　恐らくPC用のRyzenがチップセットを必要とする背景には様々な理由/目的があるのだろうが、ユーザー視点・技術的な理由としてI/O数を増やす目的がある。後述するがCPUから出せるI/Oには限りがあるからだ。
　現在のAMDチップセットはPCIe x4で接続され、例えばB550の場合はここからPCIe Gen 3 10レーン・SATA 6レーン・USB 3.1 Gen 2 2レーンなどを取り出すことができる、ハブの役割を果たしている（※注：PCIeとSATAの高速シリアルI/Oは合計10レーンの排他利用）。言い換えれば、Thin ClientやChromeBookのようなレガシーフリーでI/Oの少ないプラットフォームではチップセット無しでも問題とならない場合がある。

　AMD Zen/Zen+シリーズのAPUはSoCとして使用する場合には合計16レーンの高速シリアルインターフェース（PCIe・SATA）が使用できる。Google Zorkの仕様は不明だが、一般的なChromeBook/ラップトップPCとして考えるならM.2 NVMe SSD（PCIe x4）・M.2 Wi-Fi（PCIe x1）・1GbE（PCIe x1）・SD Card Reader/Writer（PCIe x1）といった具合で合計16レーンで十分に足りてしまう。

　Intel Coreシリーズプロセッサーの場合、CPUは単体でブート可能なようにはできておらず、PCIeやビデオ出力以外のI/Oも搭載されておらず、チップセットありきのデザインとなっている（Core-Uはチップセットをパッケージに統合しているため外付けチップセットは必要ないが）。

余談：Ryzen Embedded SoC

　Ryzen 3000Cシリーズ≒Ryzen Embedded V1000/R1000シリーズと仮定してRyzen Embedded V1000/R1000について。
　AMD ZenシリーズとIntel Coreシリーズは製品としては似ているが大きく異なるコンセプトを持っている。それはZenシリーズが組込界の設計思想を取り入れたSoCとしての利用を想定した製品である点だ。これはGPUが統合されたAPU製品（Ryzen Embedded）だけでなく単体CPU製品（Epyc Embedded）でも共通の特徴である。

　組込とPCでの半導体製品の大きな違いは、組込では一般にチップに搭載されている機能を全て同時に利用することができず選択的/排他的に取り出すことが多いことだろう。組込では組み込まれる対象のデバイスの用途によって必要な機能（≒必要なI/O）が異なるが、特定の用途に限定されているので同時に利用可能なI/Oの種類は多くなくていい。むしろ、チップの半導体面積（≒4辺がI/O用）やパッケージのフットプリントが小さい方が良いためI/Oは必要最小限の方が良い。
　より具体的には各種コントローラーは論理層と物理層が別々に実装されているが、取り出すことが可能な機能は実装されている物理層≒高速シリアルI/O（いわゆるSerDes）の数に制約を受ける。

　以下の表は第1/2世代ZenのAMD APUの仕様（※一部推定を含む）をまとめたものであるが、左端がチップそのものの仕様、中央3項目が同チップから派生させた製品、右端が同チップの採用例（≒ユーザーから見た仕様）である。

Product line	N/A	Ryzen-U / -G	Ryzen Embedded V1000	Ryzen Embedded R1000	Example: Sapphire BP-FP5 Ryzen V1000/R1000
Memory Std	DDR4 2400 - DDR4 3200
Channel	2
PCIe lanes	16 SerDes lanes upto 16 PCIe upto 8 SATA upto 2 10GbE	PCIe Gen 3 12 (4 for SCH)	16 SerDes lanes upto 16 PCIe upto 2 SATAIII upto 2 10GbE	8 SerDes lanes upto 8 PCIe upto 2 SATAIII upto 2 10GbE	1 M.2 PCIe x4 or SATA 1 M.2 PCIe x1 1 SATA
SATA		-
Ethernet		-			2 1GbE (PCIe x1)
USB	4 USB3.1

　チップ自体は16レーンの高速シリアルI/O（SerDes）を搭載している。これは搭載しているPCIe 16レーン + SATA 2レーン + 10Gb Ethernet 2レーンとコントローラーの総数よりも少なく、取り出せるI/Oは排他利用となる。

　PC用Ryzen 2000シリーズAPU（Raven Ridge / Picasso）では16レーンすべてをPCIeとして使い、うち4レーンをチップセットとの接続・残り12レーンのうち8レーンをGPUなどPCIe・4レーンをM.2として使用するケースが多い。
　組込ではやや状況は変わり、利用可能なコントローラーから組込ベンダーが組み合わせを選択できる。例えばSapphire NP-FP5・BP-FP5ボードの場合、V1000・R1000両対応から8レーン分のI/Oが使用されている。M.2 2280 B+M KeyでPCIe x4またはSATA 1レーン・M.2 2230 A+E KeyでPCIe x1またはUSB・2基の1GbEでPCIe x1を2レーン・SATA 1レーンで合計8レーンを使用している。

　ちなみに、ここでいう高速シリアルI/O≒物理層とは、チップ間接続などでいう物理層のことでEthernet/OSIモデルの物理層とは異なる。例えばAPUにはSynopsys製10GbEのMACが搭載されているが、ここでいう物理層とはこのMACとPHYの間を接続するXGMIIシリアルI/Oのことである。これを他ノードとケーブル接続に利用するには外付のPHY（Ethernet/OSIモデルでの物理層）が別途必要になる。

　ところで、Ryzen Embedded搭載製品について調べていると、10GbEが有効化されていないことへの疑問の声が聞かれるが、恐らくこの10GbEはそのような利用を想定していないのではないか（メーカーがサポートしていないのではないか）と思う。
　まず、上述の通りRyzen Embeddedに搭載されているのはバックプレーン用の10GBASE-KRのMAC層であり、I/Oとして取り出すにはバックプレーン（PCB基板上での通信）としての使用が想定されている。恐らくSFPなどを使えば10GBASE-LR/ER/SR（光ファイバーでの通信）で使用できると思われるが、果たして消費者向けに浸透しつつある10GBASE-Tとして使用できるかは疑わしい。
　ちなみに、このMACは1GbE x2レーンとしても使用可能なようだがPHYを外付けする必要があるためコストパフォーマンスは良くない。MarvellあたりのPHYよりもRealtekのPCIe x1接続1000BASE-Tコントローラーの方が安価だったりするからだ。

　ちなみにCOM Express（組込用のプロセッサーモジュール規格）を使用する場合、Ryzen Embeddedの仕様はCOM Expressの仕様と完全には合致していない。これはEpyc Embeddedの仕様がCOM Express Type-7と完全に合致する（≒そういう意図で設計されている）のとは対照的である。

	COM Express Types		AMd Embedded Processor family
Type	COM Express Type-6	COM Express Type-7	Ryzen Embedded V1000	Epyc Embedded 3000
PCIe lanes	24	32	upto 16 lanes	upto 32
SATA	4	2	upto 2	upto 8
10GbE	0	4	upto 2	upto 4
1GbE	1	1	upto 2(?)	upto 4(?)
USB3.0	4	4	4	4
USB2.0	8	4	1	0
Video	LVDS A&B	0	LVDS	0

 

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

AMDがARMベース・モバイル用のRyzen C7を開発か

AMD Ryzen C7, an Arm Cortex-X1/A78/A55 Processor with MediaTek 5G Modem? (Leak) - CNX Software

　真偽は定かではないが、個人的には眉唾かと思う。
　事実だと仮定して、疑問はどの市場をターゲットとしているか？である。Chromebookのような薄型Armベースのラップトップなのか？Androidタブレットなのか？あるいはAndroidスマートフォンなのか、これにより話は変わってくる。

　記事によると、ARM製CPUコアCortex-X1/A78/A55にAMD Radeon GPU・MediaTekからライセンスされる5Gモデムを組み合わせたものだという。
　AMD製GPUのモバイルプロセッサーへの組込については、SamsungがAMDからRadeon GPUのIPをライセンスを受けて同社のExynosプロセッサーに組み込む計画がある。恐らくExynos 1000シリーズはCortex-X1/A78/A55 CPUコアとRadeon GPUを組み合わせたプロセッサーになる可能性が高い。言い換えればRyzen C7が事実だと仮定するとRyzen C7とExynos 1000シリーズとはモデム以外の主要スペックが同一になる可能性がある。

　CNXの記事では競合としてQualcomm Snapdragon 8cxの名を挙げている。つまりWindows on Armプラットフォームであるが、Windows on Armは何時消滅しても不思議ではない不安定なマーケットなので参入する意義は薄いが、この電力枠であればGoogleのChromebookで採用される可能性はある。

　Radeon C7が現実だとすると、Qualcomm Snapdragon 8cxか800シリーズと競合することになるが、AMDが勝てるとは思えない。
　Qualcomm Snapdragonをはじめモバイルプロセッサーの性能はしばしばCPUやGPUの性能で語られるが、半導体ダイの面積（≒製造コスト）ベースで見てもそれらが占める割合は5割に満たない。世代によって多少前後するがCPUが~20％・GPUが~25％といったところで、モデムやDSPの方が大きいほどである。モバイルプロセッサーにはCPU・GPUのほか画像処理ISP・動画/音声デコーダー/エンコーダー・NPUと様々なDSPが搭載されており、それらをシームレスに使い分けている。
　GSMArenaの写真の場合、Snapdragon 845のKryo 385 Goldコア（Cortex-A75）とExynos 9810のExynos M3コアとでは後者の方が3倍近くも巨大（≒ロジックが複雑≒高性能？）であるが、各種ベンチマークを見るとExynos 9810が勝っているのはCPUシングルコア性能だけで（AnandTechの記事の前半）、アプリケーション性能（AnandTechの記事の「System Performance」）ではSnapdragon 845の方が優秀であることが分かる。言い換えれば、よく話題になるCPU性能よりもGPU・DSPなどアクセラレーターを統合した性能が重要になる。

　AMDはQualcommよりも高性能なGPUを持っているし、ARMからCXCライセンスを受けることでQualcommと同等のCPUを得ることは可能だろうが、上述の通りモバイルプロセッサーはCPU+GPUで決まる世界ではなく統合させる技術が必要になる。世界で最も出荷されているDSP＝Hexagonを統合的に組み合わせてきたQualcomm相手には分が悪いだろう。
　もっとも、このようなことはAMDも知っているだろうし、逆に火の無い所に煙は立たぬわけで、例えばAMDとMediaTekが共同開発したプロセッサーが出てくるなどの、何らかの新製品が企画されているのかもしれない。

FreeNASはTrueNASに統合・LinuxベースのTrueNAS SCALEが追加

Starting our next Open Source Project - TrueNAS SCALE - iX Systems

　PCベースの無償のNAS用OSでFreeNASというものがあるが、その開発元＝iX Systemsのアナウンスがあり、この無償版FreeNASと有償版TrueNASのコードベース/配布OSイメージが統合されるのだという。無償版と有償版のコードベースが同じで追加機能の有無やサポートの有無で差別化されるというのはよくある話であるが、これまで無償版と有償版とでリリースのプロセス（QAテストなど）に差分があったものを統合することでエンジニアリングリソースを効率化するということだそうで、納得できる話である。これが発表されたのが3月5日のことである。
　…と、ここまでであれば特に取り上げるべくもないのだが、そのiX SystemsがTrueNASファミリーにDebian GNU/LinuxベースのTrueNAS SCALEを追加するという。要するに、FreeNASとTrueNASの統合でエンジニアリングリソースに空きを作ることで新製品を追加するという。これもよくある話であるが、過去の経緯を知っていて、Linuxベースであること、SCALEという名前からすると色々と考えさせられるものがある。

　FreeNASはLinuxベースではなくFreeBSDベースである。巷に出回っているオープンソースのファイルシステムで最もハイエンド向け機能が充実しているのがZFS（CDDLライセンス）であるが、ライセンス非互換のLinuxとは違いFreeBSDでは以前からZFSが統合されている。つまりZFSを利用できることはFreeNAS（やNexentaStor）のアドバンテージでもあるわけだが、拡張性やスケーラビリティーなどを考えた場合にLinuxの方が優れているという議論もあるだろう。その議論は約10年前2009年にもあり、当時FreeNASの主要デベロッパーのひとりだった人物が作ったのがOpenMediaVaultである。
　ちなみにCanonicalなどが取り組んでいるLinux KernelモジュールでのZFS実装＝OpenZFSであるが、昨年11月にFreeBSDは現在のZFS実装からOpenZFSへの移行を発表している。つまりライセンス問題はともかく、コマンドや機能という点ではFreeBSDでもLinuxでもZFSを同様に扱える。

　ただ、2009年当時と2020年とでは「スケーラビリティー」の意味はやや違ってくる。それはクラウドの存在に起因している。
　2020年と2009年とで違うLinuxのFreeBSDに対するアドバンテージはDockerやKubernetesと使えること・クラウド（例AWS）で動くことだ。2009年に開発が始まったOpenMediaVaultはスタンドアローンのNAS・FreeNASのLinux版でしかなく、単にFreeNASよりもアプリケーションやファイルシステムや対応ハードウェアへの対応が充実している程度でしかないが、2020年現在ではDocker時代の使い方を組み込める。Debianベースという選択肢も、2009年当時であればAPTをバックエンドにできるためWeb UI経由でパッケージを追加・削除しやすいと考えられるが、2020年ではそれに加えてDockerfileの書き易さが加わる。

　もっとも、ストレージのほかデータベースでも言えることだが、格納されているデータが重要なサブシステムでホストシステムのスケーラビリティーが果たして重要か？という疑問はある。アプリケーションとは違いストレージやデータベースはコンテナー化ではスケールさせ難い。バックエンドがスケールしなければフロントエンドだけがスケールしても性能は上がらないからだ。
　ただ、例えば現在TrueNAS（やSambaベースのWindows Share）を使用している企業が、クラウドのフロントエンド＝SMBサーバにTrueNAS SCALE・バックエンドにAWS S3やAWS FSxを利用することで、ユーザーから見たフロントエンドを変えずにクラウドプロバイダーのPaaSをバックエンドに変更することは可能になる。また、フロントエンド側をコンテナー化することで容易に可用性を高める（落ちたら別のコンテナーを起動する）ようにはできるだろう。

 

GPD WIN Max (2) パーツ編

　GPDの公式Twitterによると初期ロットの製造が始まったらしい。

The first batch of unit are standing by, soon you will see true reviews - GPD Game Console on Twitter

基板の写真（写真1・写真2・写真3）が掲載されているため、検証してみたい。ただし、基板の写真は高解像度で鮮明ではあるものの、部品上のシルク印刷が不鮮明なこともあり電子部品の正確な確認はできないが、恐らく以下のような構成と思われる。また、今回は第1ロットということもあり、将来変更される可能性はある。

GPD WIN Max

　型番不明のRealtek製コントローラーやITE製コントローラーはモデルが不明で用途も不明だが、基板上の位置や搭載され方（例：Realtek製コントローラーは周囲がシールドされている）や欠損している構成部品から推測している。
　下記のほかにも、USB Type-C/Thunderbolt周辺にはパワー系ICやHDMI Transmitterがあるはずだが、冷却ファンに隠れて詳細は分からない。冷却ファンが思いのほか大きいためM.2 SSDを換装するには恐らく丸ごと外さなければならないだろう。

Make	SKU	Desc
米Intel	Core i5 1035G7	CPU + Integrated GPU
メーカー不明	型番不明	64 Gb (8 GB) LPDDR4X x2
米Intel	AX200D2WL	IEEE 802.11ac / Wi-Fi 6 無線LANコントローラー
台Realtek	RTL8111	PCIe x1 1Gb Ethernetコントローラー
台Realtek	型番不明	オーディオコーデック (?)
台ITE	型番不明（IT5571 ?）	Keyboard or Touch screenコントローラー (?)
台Genesys Logic	GL3232	USB3.1 Gen 1 SDカードコントローラー

BIWIN (?) NS200 512GB M.2 NVMe SSD

　「NS200 512 GB」という型番・容量は読めるのだがメーカーは読むことができない。型番と容量から検索すると中BIWINなどの名前が出てくるが特定できない。480 GBの容量違いで中Lexar NS200というSSDもあるようだが2.5インチSATA接続のため違う（NVMeとSATAではプロトコルが全く異なり共通のコントローラーが無いため同一型番というのは考え難い）。恐らく他社にOEMされている中国製の実質ノーブランドSSDだと思うが、構成部品は先進国の有名ブランド製なので問題は無かろう。
　GPDによるとM.2 SSDはNVMeまたはSATA接続の片面実装品に対応するようだが、厚みのせいもあろうが、M.2スロットの下にLPDDR4Xメモリーが設置されているため発熱の問題もあろうかと思われる。

Make	SKU	Desc
台Silicon Motion	SM2263EM	PCIe Gen 3 x4 NVMe SSDコントローラー
台Nanya	NT5CB(C)512M16ER-EK	256 MB DDR3 SDRAM（SSDキャッシュ）
メーカー不明	型番不明	1024 Gb (128 GB) NAND Flash x 4

GPD WIN Max (1) 動機編

　私事で恐縮だが、IndieGoGoクラウドファウンディングでキャンペーン中のGPD WIN Maxに出資したため、このデバイスについて、また私の考える運用思想について書き記しておこうと思う。

現在の環境

　まず私の現在の環境について述べておくと、私の現在の普段使いのメインPCは2012年製の"Sandy Bridge"世代Intel Core i5搭載ラップトップPCのLenovo ThinkPad X220をベースに、独自にメモリーを16GBに増量・SSDに換装・Wi-Fiを802.11nに対応させたりと近代化アップグレードして使用している。

　ThinkPad X220に搭載されているのは低消費電力Mプロセッサー（TDP 28W）で、超低消費電力のUプロセッサー（TDP 15W）と比較すると消費電力はともかく性能は高い。先日まで勤め先で使用していたラップトップに搭載されていたCore i5-6200U相手にも見劣りしないほどである。
　それでも、これまでもメインPCを買い替えることは考えたのだが先延ばしになっていた。重い処理は1Lサイズ小型デスクトップPC Lenovo ThinkCentre Tinyにリモートでログインして実行しているのでラップトップ機を高性能化する必要が薄かったし、さらに、これまで引越が多く荷物を増やしたくなかったせいだ。

GPD WIN Maxと新しい運用方法

　今回GPD WIN Maxの入手を決めたのは運用方法の見直しのためだ。
　私はエンジニアのためビジネス旅行する機会は少なく外出先でラップトップPCで仕事をしなければならない機会は稀で、プライベートの旅行ではAndroidタブレット端末で事足りてしまうので、ラップトップPCを持ち運ぶ必要すらない。
　上述の通り、私のメインPCは13インチラップトップThinkPad X220だが、実際の運用は自宅のテーブルの上に据え置きされており、自宅内で持ち運ぶことすら稀で、自宅外への持ち運びとなると2年に1度の一時帰国ぐらいのものだ。もちろん、ThinkPad X220を入手した2012年当時は重くてもPCを持ち運ぶ必要があったから入手したのであるが、約8年間もの歳月が経過しiPadのような高性能タブレットが普及し小型PCの性能が飽和している現在では状況は変わっている。

　こうなると13インチの小型だが狭いディスプレイの利点はあまり無い。
　ほとんど持ち運ばず据え置きで使うのであれば、17インチラップトップでも良いのではないか？とも考えられるが、よくよく考えてみると、自宅や一時帰国先の実家には24インチディスプレイやキーボードもあるので、USB Type-C HDMI/DP Alt Modeドックなどを介して大型ディスプレイやフルサイズキーボードに接続して簡易デスクトップPC化する方が快適だ。

小型ラップトップとしてのGPD WIN Max

　GPD WIN MaxはゲーミングPCとして宣伝されているが、2000年代前半に大学生だった私にはSony VAIO Type-UやFujitsu LOOXの再来に見える。

　特にVAIO Type-Uは外観からして酷似している。
　以下はGPD WIN Maxを2002年に登場したVAIO type-Uのスペックと比較したものだが、スペックが似通っており、一方でバッテリー寿命が延びるなど大幅に改善されていることが見て取れる。

model		GPD WIN Max Product page	Sony VAIO type U Product page
		2020	2002
display input / output	display	8-inch H-IPS 1280 x 800 Multi-touch LCD Corning Gorilla Glass 5	6.4-inch 1024 x 768 LCD
	i/o interface	HDMI 2.0 x1 Thunderbolt 3	IEEE1394 S400
storage	internal	M.2 2280 SSD 512 GB NVMe	UltraATA HDD 20 GB
	external	MicroSD	MemoryStick
battery	capacity	15,000 mAh	4,900 mAh
	battery life	6 - 14 hours	2 - 4 hours
	dimensions	207 x 145 x 26 mm	184.5 x 139 x 30.6 mm
	weight	790 g	820 g

　2002年当時はドックなどの接続も優れたものが無く、PCとしての性能も低かったため、VAIO type-UやLOOXは超小型・軽量な代わりに遅いPCとして妥協して使うほかなかったが、GPD WIN Maxであれば、上述のようなドックで接続することで高性能な超小型デスクトップPCとして使うことができる。
　私個人はLOOX Sユーザーだったが、大学ではLOOX S・自宅では自作デスクトップPCで、データの移動が億劫だったことを覚えている。もし、GPD WIN Maxを簡易デスクトップPCとして使うのであればそもそもデータを移動させる必要性が無くなる。

ゲーミングPCとしてのGPD WIN Max

　筆者はゲーマーではないが、スペックには目を見張るものがある。GPD WIN Maxは、いわばNintendo Switch2個分の筐体に4倍の性能あるいは初代XBox Oneに近い性能を詰め込んだものだ。

		Laptop PC	Gen 8 Game Console		Gen 9 Portable Console
model		GPD WIN Max	Sony PlayStation 4	Microsoft Xbox One	Nintendo Switch
		2020	2013	2013	2018
display input / output	display	8-inch H-IPS 1280 x 800 189 ppi	N/A	N/A	6.2-inch 1280 x 720p 237 ppi
graphic processor	internal	Intel Gen 11 Iris Plus 940 64 EU (512 MADs) 300 MHz (base) 1050 MHz (turbo) 1075 GFLOPS	AMD GCN2 18 CUs (1152 MADs) 800 MHz 1840 GFLOPS	AMD GCN2 12 CUs (768 MADs) 853 MHz 1320 GFLOPS	NVIDIA Maxwell GM20B 256 cores (256 MADs) 768 MHz (docked) 465 MHz (handheld) 393 GFLOPS (docked) 236 GFLOPS (handheld)
memory	system memory	LPDDR4-3733 16 GB 128-bit width 60.0 GB/sec	GDDR5, 8 GB 256 bit-width 176.0 GB/sec	DDR3-2133 8 GB 256 bit-width 68 GB/sec eSRAM 32 MB 1024-bit width 204 GB/s	LPDDR4 4 GB 64-bit width 25.6 GB/sec
battery	capacity	15,000 mAh	N/A	N/A	4310 mAh
	battery life	6 - 14 hours			Original model: 2.5 - 6.5 hours HAC-001(-01): 4.5 - 9 hours
	dimensions	207 x 145 x 26 mm	N/A	N/A	163 x 102 x 14 mm
	weight	790 g			398 g