今週の興味深かった記事（2019年 第39週）

Hot Chipsで発表されたNPU（続）

Hot Chips 31はマシンラーニングが花盛り - マイナビ

　二週間前から継続して、Hot Chips 31で発表されたNPU（Neural Processing Unit）に関するHisa Ando氏による解説がマイナビに掲載されている。今週はTesla MotorsのFSDとNVIDIAのRC18に関してのものだった。

　記事の内容の前提であるが、Tesla Motorsの運転補助にはHW1.0～HW3.0までの三世代が存在しており、第一世代HW1.0ではIntel傘下MobilEye EyeQ3ベース、第二世代HW2.0/2.5ではNVIDIA Drive PX2（NVIDIA Tegra TX2 + NVIDIA Pascal GPU）ベース、そして第三世代ではTesla内製によるFSDベースとなっている。

　2019年現在でのNVIDIAのハードウェアを使ったDeep Learningとは、つまりNVIDIA GPUによる汎用的なコンピューティング機能＝General Purpose GPU＝CUDAを使っているので、よりASICに近いニューラルネットワーク専用ロジックを使えば電力効率や性能が向上できる。また、チップやチップを利用可能にするソフトウェア（いわゆるBSPやSDK）に要する開発コストを除外すれば、チップの単価が下がるのも理解できる。
　ただし、大手自動車会社・関連会社を何社も相手に何百万個ものプロセッサーを出荷するNVIDIAに対し、自社でしか使用しないプロセッサーを内製するというのは採算がとれるか難しい（例えばプロセッサーのリソグラフィーに必要なマスクを作るだけで数百万ドルのコストがかかる）。記事中ではテープアウトまで14カ月で開発したとあるが、逆に言えばEDA会社（Synopsys・MentorGraphics・Cadence・Arm・CEVAなど）がライセンスする既存のIPを組み合わせ、独自開発を極小化にしないと採算が取れないということではないかと思う。

　個人的に気になるのは開発時期である。TeslaはFSDを今年4月に発表しているが、出荷までにはテープアウト後6～12カ月程度かけて検証することになる（実際には、検証で不具合が出るとさらに遅延が発生する）。4月の発表時点でどの程度まで検証が進んでいたか不明であるが、仮に発表時点で開発に14カ月・検証に12カ月を費やしていたと仮定すると2017年2月頃に開発を開始したという計算になる。
　Teslaの自動運転ハードウェアエンジニアリングといえば、AMDでRyzenの開発を主導したJim Keller氏が担当副社長として在籍したことで知られ、Keller氏がFSDの開発に関与したという報道は無いが、時期的には奇妙に一致する（2017年2月～2018年4月）。

　一方のNVIDIAであるが、以前はGPGPUのリーダーとしてマシンラーニング環境の代名詞的な存在であったものの、近頃はGoogleはGoogle TPU・AWSは傘下Annapurna Infarentia・FacebookはIntel Nervana NPP-I/NPP-Tを利用しており、専用ハードウェアの登場で劣勢になりつつある印象が強い。
　そのNVIDIAはHot Chipsなどで2018年度の研究チップ（Research Chip 2018=RC18）を発表しているが、あくまで研究開発用なので製品化されるものではない。おそらくNVIDIAはGPU機能を持たない専用NPUを開発中と見られるが、その登場が待たれる。

Ryzen 4000シリーズはSMT4に対応か？

Rumor : AMD Zen 3 Architecture to Support up to 4 Threads Per Core With SMT4 Feature - WCCF Tech

　WCCF Techが報じた「ウワサ」であるが、ZEN 3ベースのAMD Ryzen 4000シリーズはSMT4に対応する可能性があるのだという。

　そもそものSMTであるが、一般向けとしてはIntelがPentium 4（Northwood）で採用したHyperThreadingが最初であるが、2セットのレジスタファイルやプログラムカウンターを用いることで2つのスレッドが1コアのCPU内で完全に並列で実行される技術で、当時はOut-of-Order実行と並んでパイプラインを埋める技術という認識が強かった。ところが、近年はCPUとメモリーの速度のギャップが年々開いており、CPUがメモリーを読み書きする遅延を隠ぺいする技術として認識されてきている。
　ちなみに、Pentium 4と同時期にマルチスレッド技術をCPUに持ち込んだSun Microsystems "Niagara"ファミリーは、専ら後者に注目しており、同時に実行できるスレッドはCPU1コアあたり1スレッドのみで、メモリーアクセスのイベントが発生する毎にスレッドが切り替わる仕様であった（参考）。このような方式はSMTに対してVMTと呼ばれている。

　SMTは上手く動作させれば10～20％程度の半導体リソース追加で20～最大40％程度のパフォーマンス向上を狙えるということで効率は良いが、シングルスレッド性能が向上するわけでもなく、むしろ並走するスレッド数が増えるとポート競合が発生しやすくなるため（この場合はシングルスレッド性能が低下する）、演算ユニットなどSMTを実装する1コアにリソースが潤沢にあることが前提となる。逆に、仮にSMT4やSMT8でポート競合が完全に無くなるほどのリソースを追加すると、1スレッド用小型CPU4コアや8コア分のリソースが必要になってしまいSMTである意味が無くなってしまう。バランスが重要となる。
　ちなみに、4並列以上のSMTは初めてではなく、IBM POWERファミリーでは前世代POWER 8・最新POWER 9でSMT8を実現しているが、POWER 9の場合は "64b slice" を8 sliceを束ねたような格好をしているが、"64b slice"はまるで小型CPUのような格好をしており1スレッドで専有される。共有されているのはキャッシュ・デコーダーなどのフロントエンドと除算ユニット・暗号エンジン・10進数アクセラレーターなど使用頻度が低い演算ユニットだけである。

　以下に、IBM POWER 9・AMD Zen 2・Intel Sunny Coveの各コアのスペックとスレッドあたりのリソースの量を示す。

　キャッシュの容量や各実行ユニットの数だけを見れば、Zen 2コアやSunny Coveコアの方が1スレッドあたりのリソースが潤沢そうに見えるかもしれないが、これはZen2やSunny Coveでは実行ポート1ポートに複数の演算機能をもたせているからである（ALU・FPU・SIMD・Load/Storeの数を足すと実行ポート数よりも多くなるのはこのため）。実際にはスレッドあたりの実行ポートの数についてはPOWER 9・Zen 2・Sunny Cove共に5～5.5とほぼ互角である。恐らく、1スレッドをOut-of-Orderで競合を避けつつ効率よく動作させるためにはこの程度のポート数が必要なのだろう。

	IBM POWER 9 (SMT8)		AMD Zen 2		Intel Sunny Cove
SMT	SMT8	(per thread)	SMT2	(per thread)	SMT2	(per thread)
L1$I (KB)	64 KB	8 KB	32 KB	16 KB	32 KB	16 KB
Exec Ports	42	5.25	11	5.5	10	5
ALU	8	1	4	2	4	2
FPU	8	1	4	2	3	1.5
SIMD	8	1	4	2	3	1.5
Load	8	1	3	1.5	2	1
Store	8	1	2	1	2	1
L1$D (KB)	64 KB	8 KB	32 KB	16 KB	32 KB	16 KB

1ポートに複数の機能をもたせることはSMT2程度であればポート競合の回避には役立つだろうが、SMT4まで増やしてしまうとポート競合は回避できないだろう。

　AMDがZen 3でSMT4を実装するかどうか公式発表は無く不明だが、Zen 3は既に開発が完了しており来年に製品が投入されることから、Zen 2を拡張したものであることは確実と思われる。この場合Zen 3がPOWER 9のような構成に化けるとは考え難く、もしSMT4を実装するならばポート競合の多発とシングルスレッド性能の低下は避けられないだろう。
　HPCや軽量な処理が多スレッド発生するWebサーバーなどのワークロードではメモリーの遅延がボトルネックになることが多いため、SMT4にすることで多少はシングルスレッド性能を犠牲にしても全体的な性能を向上できる可能性がある（Sun Microsystemsが提唱したThroughput Computingのアイデアと同じである）が、ユーザー1人がリソースを占有するデスクトップ用途ではSMT4はパフォーマンス向上に繋がらない可能性が高い。

　もしAMDがZen 3でSMT4を実装する場合、IntelがHyperThreadingの有効/無効をXeon / Core i7/i5/i3 / Pentiumの製品毎に使い分けているように、製品毎でSMTなし/SMT2/SMT4を使い分けるのではと予想する。

# ただ、AMDはRyzenでもEpycでも半導体ダイを使いまわしているので、
# 果たしてRyzenで有効に使えないSMT4を実装してくるのかという点には疑問が残る。

CentOS 8がリリース

CentOS 8.0がリリース，ローリングリリース「CentOS Stream」もアナウンス - Gihyo.jp

　Red Hat Enterprise Linux 8（RHEL）のGAから4カ月を経てCentOS 8およびCentOS Streamがリリースされた。

　御存知の通りRHELはオープンソースで、ソースコードはほぼSRPM形式で公開されている。そのため原理的にはSRPMからRHELクローンをビルド可能であり、実際にCentOSはそうして作られているし、Oracle LinuxやAmazon Linuxも同様である。

　前置きが長くなってしまったが、ここで疑問なのがローリングリリースモデルを採用するというCentOS Streamである。
　ローリングリリースモデルのような高速なリリースサイクルの採用自体は理解できる。なにせ5月にRHEL 8が出るまで最新だったRHEL 7など2013年6月にリリースされたLinux Kernel 3.10を使い続けている。これはRed Hatが5年に1回程度の頻度でしか新バージョンを出さないためで、2年に1回の頻度でLTSが出るUbuntuとは対象的である。
　とはいえ、Ubuntuのようなポイントリリースならともかくローリングリリースというのは理解できない。Red Hatのローリングリリースには既にFedoraがあって差別化が難しく、その一方で従来のRHELとの互換性も低くなることが予想されるが、さらにそれをCentOSブランドで出すとなると、もはや位置づけがよく解らない。

　そもそも、Red Hatのリリースサイクル高速化は近年のDocker/Containerサポートに起因しているはずである。Dockerの機能拡張にLinux 3.10のまま対応することが難しく、同社はそれを解決するためにCoreOSを買収した。
　Fedoraと統合後のCoreOSがどのように運用されるのかまだ分からないが、Fedoraや旧CoreOSのようなローリングリリース版とRedHatブランドの企業向け有償版とが出ることだろう。この場合、恐らくRed Hat版は1年に複数回の高速なリリースサイクルを採用するだろうと予想する。これはDockerの更新頻度に追従は必要だが、Red Hatの顧客の大企業はローリングリリースに適応できないためである（ちなみにDocker Enterprise Editionのリリース頻度は3カ月に1度である）。
　それならば、CentOS Streamはそれに準じたものであるのがユーザーとしては理解しやすい。例えばRed HatブランドとCentOSブランドでそれぞれStream版とCoreOS版が3カ月に1回の頻度でリリースされる、といったような。

　以上は筆者の予想・希望なので、Red Hatが実際にどうするのか不明だが、解りやすい≒予測しやすく計画を立てやすいリリースモデルの採用を期待したいところである。

Wave ComputingのCEOが交代していた

CEO Leaves Wave, Putting MIPS' Future in Doubt - EE Times

　Hisa Ando氏の個人ページの記事で知ったのだが、Wave ComputingのCEOが9月2日に交代していたらしい。

　個人的な疑問はWaveの製品・顧客で、WaveはNPUのIP（TritonAI 64）を開発している企業だが、同社のニュースサイトを見てもTritonAI 64の発表以外はMIPS TechnologiesのCPUコアライセンスの話題しか掲載されていない。また、EE TimesにもMIPSの主要顧客としてMediaTek（同社が買収した旧Ralink系の家庭用ルーター製品用SoCにMIPS24KcやMIPS1004Kcなどが採用されている。MediaTek SoCは日本ではBuffalo WSRシリーズルーターに採用されている）やIntel傘下のMobilEye（EyeQ2から最新EyeQ5まででMIPS34KfやMIPS I6500-Fなどが採用されている）の名が挙げられているが、Waveの顧客の名は挙げられていない。

　背後にベンチャーキャピタルTallwood Venturesがついており、自身が儲けていなくても企業運営や企業買収などが可能とはいえ、あまり明るい未来は感じられない。