最近の気になった話題（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をバックエンドに変更することは可能になる。また、フロントエンド側をコンテナー化することで容易に可用性を高める（落ちたら別のコンテナーを起動する）ようにはできるだろう。