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

NVIDIAがShield Android TVの新モデルを計画中か？

NVIDIA is working on a new SHIELD Controller and SHIELD Remote - XDA Developer

　Androidコミュニティーサイト、XDAがNVIDIAがShield Android TV用の二種類のコントローラーを開発中と報じており、そこから「Shield Android TVの新モデルが出るのでは」と飛ばし記事が出回っている。
　そもそも現行のShield Android TV (2017)はNintendo Switchと同じプロセッサーを採用しており、2019年後半にNintendo Switchの次世代モデルが登場するというウワサがあったことから、コントローラーの登場＝新モデルが出るのでは？というウワサに飛躍している。

　実際のところ、2015年以降のNVIDIAはAndroidタブレットやセットトップボックスでの使用を想定したプロセッサーを発表しておらず、Tegra X2 (Parker。2017)やXavier (Xavier。2018)は車載を想定していて設定価格や消費電力が高すぎる。そのため、Nintendo Switch用にプロセッサーを準備する場合はTegra X2かXavierをそのままではなくカットダウンした縮小版が準備されると想像できる。

　NVIDIAはよくプロセッサーや設計を流用する会社である。例えば2015年にTegra X1で採用したCortex-A57を2017年のTegra X2で流用している。ArmのCPUコアIPとしては新しいCortex-A72/A73が選択可能であったが、NVIDIAからすればハイパフォーマンスCPUは自社設計のDenver 2を使っているからCortex-A57だろうがCortex-A72/A73だろうが大きな違いは無かったのだろう。また、そのTegra X1自体も当初はGoogle Pixel C・Shield TV (2015)で採用されていたがShield Android TV (2017)・Nintendo Switchさらに先日発売されたJetson Nanoで流用している。
　そしてNVIDIAがNintendo Switch用にXavierのカットダウンモデルを作成すると想定すれば、それを流用したShield Android TVの新モデルも想像できる（想像の域を出ないが）。設計や製品を流用することは、エンジニアリングコストの削減や量産効果による製造コスト削減に繋がるので理にかなっている。

仮にXavierを1/2規模に縮小すると仮定する（右端）

		Tegra X1 (Nintendo Switch)	Xavier	1/2 Xavier (estimate)
CPU	Core	Arm Cortex-A57	NVIDIA Carmel	NVIDIA Carmel
	Spec	1.02 GHz x 4 cores	2.26 GHz x 8 cores	? GHz x 4 cores
GPU	Core	NVIDIA Maxwell	NVIDIA Volta	NVIDIA Volta
	Spec	307.2-768 MHz x 256 cores	1377 MHz x 512 cores	- ? MHz x 256 cores
	Perf	157 - 393 GFLOPS	1410 GFLOPS	- 512 GFLOPS (@ 1000 MHz)
RAM	Type	LPDDR4 x64	LPDDR4 x256	LPDDR4 x128
	Perf	4 GB 25.6 GB/sec	16 GB 137 GB/s	8 GB 68.5 GB/sec

これらの数字はXavierのスペックを単純に1/2にしたもので想像の域を出ないが、消費電力10-30WのXavierを半分にしても十分にTegra X1からアップグレードできることになるので（実現するかどうかはともかく）現実的に見える。

Windows 10 version 1903の後

8億台稼働を達成したWindows 10の“次”は何が変わる？  - ITMedia

　今週の記事ではなく先週の記事であるが、今週読んだので本稿に含めておこうと思う。
　寡聞にして知らなかったのだが、Windows Insider PreviewのSkip Aheadが19H2ではなく20H1であるのはWindowsのコア部分が19H2では更新されないということが原因なのだそうだ。確かに記事中（というか記事中で参照されているZDNet記事）の説明なら納得はいく。

　とはいえ、これで納得がいくのは19H1の次が20H1ということだけである。現在のWindows 10のLifecycleは複雑怪奇すぎる。

　恐らく、世のWindowsアプリケーション開発者たちは「Windows-as-a-Service」のコンセプトを知った時には狂喜したはずである。なにせWindows 10には1バージョンしか存在しないのだから、いわゆるDLL Hellのような微妙なバージョン不一致によるフラグメンテーションが解消される…はずであった。
　実際はそうでもなく、19H1=1903がリリースされる時点ではWindows 10だけでも1507 (LTSB)、1609 (LTSB、SAC)、1703 (SAC)、1709 (SAC)、1803 (SAC)、1809 (LTSC、SAC)、1903 (SAC)の合計7バージョンがサポートされていることになる（！）。さらにWindows 7・Windows 8.1もあるから系9バージョンである。Windows 10リリースされる以前の2015年7月時点ではWindows Vista Service Pack 2、Windows 7、Windows 8、Windows 8.1の計4バージョンしかサポートされていなかったことを考えれば、フラグメンテーションはむしろ酷くなった気すらする。恐らく状況をより一層と混沌とさせているのはYY09（例：1709・1809）の30ヶ月サポートではないか。基本の18ヶ月サポートと大企業向け（E3・E5サブスクリプション）のLTSB/LTSCは仕方がないとして、一般向けの30ヶ月というのは理解不能である。
　Ubuntuも似たような半期リリース+LTSのモデルを採用しているが、半期リリースはサポート期間18ヶ月固定なので、4月時点でサポート対象となるのは14.04または19.04に加え16.04、18.04、18.10の4バージョンのみである（Ubuntuは18.04まではLTSでも5年間サポートだった、というのも理由だが…仮に昔から10年間だったとしても6バージョンのみである）。

　ところで、記事中では「Vanadium」や「Vibranium」というコードネームがでてきているが、なかなかややこしい。ZDNetでは正確に記載されていると仮定するとVibranium等はWindows Kernelのコードネームと思われるが、検索してみると"Redstoneの次はVanadium/Vibraniumだ"というようなニュース記事が散見される。私の理解ではThresholdやRedstone（あるいはその先の19H1・20H1など）はWindows OS全体のコードネームなので別だと思うのだが判然としない。また、逆算してみるとWindows 10 version 1507のコアは元素記号=15のPhosphorus（燐）ということになり、こちらも何やら中途半端である。

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

NVIDIA Jetson Nano

NVIDIA、99ドルで手のひらサイズのAIボード「Jetson Nano」 - PC Watch
NVIDIAが99ドルでNintendo Switch同等の開発キットを発売 - PC Watch

　個人的には驚いたが、その理由としては主に2点が興味深いと思う。
　まず、Jetson Nanoは$500するJetson TX1と共通のハードウェア（Tegra X1や周辺チップ）をベースとしているが、そのTX1は昨年10月に2021年1月のEnd-of-Lifeがアナウンスされている。
　次に、そもそもTX1がEOLとなる理由は2015年に発表された旧世代製品だからで、既に2017年に後継のTX2・2018年にその後継のXavierがアナウンスされているからである。これは単にTX1・Tegra X1が古いというだけでなく2015年水準で優秀「だった」性能/機能しか無いという意味でもある。

　まず、EOLについてであるが、産業向け製品と消費者向け製品とのEOLの日程が一致しないことはよくあるので不思議ではない。
　産業向けとなると5～10年単位でのサポート提供・供給保証が必要となるが消費者向けではそうでないからで、Jetson TX1の場合は2015年から5年間以上の供給保証は必須だったと考えられる。一方、消費者向けでもTegra X1はNintendo Switchにも採用されているから、しばらくは製造・供給されるだろうが、2021年頃を目途にNintendo Switchの後継製品が出てJetson TX1・Jetson Nano・Nintendo Switchが終息ということは考えられる。
　ところで、上述の通りTegra X1はNintendo Switchにも採用されているが、PC Watchで後藤氏の言う「Nintendo Switch同等」という言い分は個人的には違和感がある。BSP/SDKを使うとLinux（標準ではUbuntu 18.04）が使用可能で、スキルがあればDebianやCentOSや、さらにはAndroidを動かすことも可能であるが、Nintendo Switchはソフトウェアが公開されていないので移植はほぼ不可能である。これはゲーム機のキモがソフトウェア資産ということを考えれば当然であろう。

　次に性能面についてであるが、これは2015年と2019年のスマートフォン（例：iPhone 6対iPhone XR）を比較してみても明らかであろう。興味深いのが公式のアナウンスで、CUDAコア 128コアで472 GFLOPSを実現するとある。実はTegra X1/Jetson TX1の公式のスペックではCUDAコア 256コアで512 GFLOPSだから数字が一致しない。考えられる可能性は幾つかあるが、恐らくはJetson TX1では256 CUDAコアが有効でFP32で500 GFLOPSに対し、Jetson Nanoでは128 CUDAコアが有効でFP16で472 GFLOPSということであろう。
　このようにして数字を並べてみて気づくのは、たった500 GFLOPS程度の性能しかないということだろう。例えばIntel Nural Computing StickのMyriad Xは4 TOPS（Int8）である。Jetson NanoのアドバンテージはFP16・FP32に対応しトレーニングにも使用可能なことであるがインファレンスの性能はMyriad Xの1/8しかないことになる。これはTegra X1が2015年の製品で性能が低いということでもあるし、また2015年時点ではEdge Machine Learningが普及していなかったからTegra X1はInt8の高速演算に対応しておらずFP16として演算するからでもある。実際、2017年のTX2や2018年のXavierではInt8にも対応している。

　ところで、今回のニュースはJetson TX1ユーザーには「棚から牡丹餅」的な朗報である。
　私自身もJetson TX1ユーザーだが、現在のJetPack 3.xのLinux 4.4+Ubuntu16.04ベースの開発環境からJetPack 4.xのLinux 4.9+Ubuntu 18.04ベースの開発環境への移行パスが見えてきたことだろう。

Note: JetPack 3.3 and Jetson TX1
A future version of JetPack 4 will be validated for use with Jetson TX1. For now, JetPack 3.3 remains the current production release for Jetson TX1.

TX1でどこまでサポートされるか不明であるが、Jetson NanoはCUDAも9.0から10.0・TensorRTも4.0から5.0へ更新され、TensorFlowにも公式に対応している。

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

NVIDIAがMellanoxを買収

NVIDIA to acquire Mellanox - NVIDIA
NVIDIA、HPC向けインターコネクト大手のMellanoxを約7,700億円で買収 - PCwatch

　ネットを見ていると、概ね驚きと好意的な意見が目立つが、個人的には1ピース足りないと思う。
　NVIDIAのGPUやInfiniBandはスーパーコンピューターで最もポピュラーな技術で、例えばTop500で現在1位のORNL SummitもIBM POWER9 22コア CPU 2基に608GBのメモリー・NVIDIA Volta GPU 6基をNVLinkで接続したものを1ノードとし、4608ノードをMellanox EDR Infinibandで接続している。そのNVIDIAがMellanoxを買収することになる。
　NVIDIAのGPU製品もMellanoxのInfiniBand製品も主要なスーパーコンピューターではシェア50％を超えるが、Intel Omni-pathなど競合がいないわけではない。穿った見方をすれば既にQLogicやEmullexを淘汰してInfiniBand圧倒的なシェア1位となったMellanoxを当局の規制対象になる前にNVIDIAが買収したということなのかもしれない。

　コンピューターには主に三種類のインターコネクト技術が存在する。まずチップ内でブロック間を接続するオンチップインターコネクト、近距離でチップ間を接続するチップ間インターコネクト、さらにノード間を接続するインターコネクトで、NVIDIAはチップ内とチップ間のインターコネクト（例：NVLink）は持っているが、InfiniBandのようなノード間接続は持っていないのでMellanoxの技術が嵌る形になる。

　しかし、これまでNVIDIAがノード間接続に手を出さなかったのは必要が無かったからではないか。
　そもそもGPUがノードを跨いで相互接続されるという話は聞いたことが無い。GPUの立ち位置はホストCPUに付随するアクセラレーターで、ノードの管理や他ノードとの接続はホストCPUの領分である。言い換えれば GPU⇔CPU⇔NIC⇔他ノード という構成になり、たとえNVIDIAとMellanoxが一体となっても間にIntelかIBMのCPUが入る構成は変わらないだろう。NVIDIAは組込用CPUこそ持ってはいるが、Intel XeonやIBM POWERに太刀打ちできるCPUは持っていないし、市場性の面からも微妙である（IntelもIBMも膨大なソフト資産と顧客企業がいる。NVIDIAがCPUを作っても誰も買わない）。

　あと、個人的に気になるのは、Network ProcessorベンダーとしてのMellanoxの立ち位置である。
　なるほどInfiniBand / 100Gb/40Gb EthernetベンダーとしてのMellanoxはNVIDIAと補完関係にあるのかもしれないが、MellanoxはEZchipやTileraを買収したNetwork Processorベンダーでもある。Mellanoxの製品ファミリーに残るNP-5は旧EZchipの製品ファミリー、BlueFieldは旧Tileraの資産にMellanoxの製品を組み合わせたものであるが、NVIDIAの戦略にフィットしそうな気がしない。

Mellanox SNAP

Mellanox、NVMe-oFでストレージを仮想化する「SNAP」を発表 - @IT

　NVMe SSDストレージは現時点では筐体に内蔵されたDASの形で使用されている。これをSANやiSCSIのようにネットワーク経由で利用可能とするのがNVMe-oF（NVMe over Fabrics）である。ネットワーク経由とすることでストレージプールを集中管理できるようになるが、高IOPSがウリのNVMeと高遅延のネットワーク経由というのが私には自己矛盾のように思えてならなかったのだが、ここでMellanoxが持ち出したのがBlueField SmartNICである。

　BlueFieldはMellanox Connect-Xネットワークアダプターに旧TileraのマルチコアCPU技術を組み合わせた製品である。
　Mellanoxは2016年にEZchipを買収したが、そのEZchipが2014年に買収していたのがTileraである。TileraはMIT「RAWプロセッサー」研究者グループが設立した企業で、超多コアをオンチップのメッシュで接続する技術を持っており、2014年時点でMIPSベースの9～72コア（3x3メッシュ～8x9メッシュ。遅延の最小化の都合上N^2に近い構成となる）の組込プロセッサーを製造していた。2014年に72コアということからも分かる通り、各コアは小型・低性能のコアである。
　Mellanox買収後は低性能のコア（独自MIPSコアおよびArm Cortex-A53コア）から高性能コア（Arm Cortex-A72）へと変更し、BlueFieldではCortex-A72 16コアを搭載している。性能の目安としては、ちょうどAWS A1インスタンスで使われるAWS GravitonがCortex-A72 16コアで、恐らくAWS NitroインスタンスのElastic Network Adapterも同様である（※Mellanox製ではなくAnnapurnaLabs製なのでモノとしては別物であるが）。

　MellanoxはBlueFieldを「プログラマブルなNIC」として売り出したわけであるが、個人的にはサッパリ理解できなかった。SDNはルーターやスイッチで行うものだし、仮想マシンでVIFを使うにしてもCPU 16コアは必要ない。しかし、BlueFieldをドライバーでNVMeアダプターに見せかけ（つまり仮想化に必要となるNVMe-oF管理ソフトをBlueField上で動作させ）、かつNVMeストレージに匹敵するIOPSを稼ぎ出すとすれば話は別である（ちなみに、消費者向けで最も高性能なSamsung 970 Pro NVMeはCortex-R4 5コアである）。

先週の興味深かった記事（2019年 第10週）

Google Edge TPU

Google、“ローカルAI”構築用ワンボードコンピュータやカメラを「Coral」ブランドで発売 - ITMedia
グーグルが外販するAI向け半導体｢Edge TPU｣の全貌  - BUSINESS INSIDER JAPAN
Google Coral

　Google TPU（Tensor Processing Unit）に限らずディープラーニング/人工知能用プロセッサー（NPU）には二種類があり、一方はクラウドで動作するトレーニングと推論を行うクラウド側と、もう一方は携帯電話などに搭載される推論専用のエッジ側とがある。今回のデバイスはUSB/PCIe接続のエッジ側である。競合としてはIntel/Movidius Myriadなどがあるし、過去にはGoogle Pixel 2/Pixel 3スマートフォンにGoogle Visual Coreという名前で同種のプロセッサーが既に搭載されている。

　Edge TPUはRaspberry Piのような開発ボード（NXP i.MX 8M）に搭載したものとUSB接続のものが発売され、やや遅れてmPCIeおよびM.2接続のボードとSOM（System on Module）が出るらしい。AIYで以前あったRaspberry PiのGPIOへのアドオンではなくホスト開発ボード/SOMから製品化するあたりは意気込みを感じさせる。同じスペックとコストパフォーマンス重視であれば中華ブランドのプロセッサーの採用も考えられるが、ドキュメントの充実・供給保証などを考慮した場合に大手機器メーカーが中華ブランドを採用することはまず無いためNXP・Marvell・MediaTekの採用が妥当である。

　もっとも、個人的にはGoogleが何をしたいのか解らないところである。
　そもそもの話として、AppleやHuawei/HiSiliconのスマートフォンに搭載されているようなNPUはコスト面・性能面からCPUなどと同一SoCに集積されているから、Googleからチップを買ってUSB/PCIe接続で利用するとは考え難い。消費電力枠の厳しいIoT分野であれば尚更である。しかし、かと言って半導体ベンダーが自社SoCに組み込むIPを探しているならArm MLかNVIDIA DLAあたりがデファクトスタンダードになるのは確実だから、ここでもGoogle Edge TPUが普及するとは考え難い。

　Androidの普及のためにNexusスマートフォンをリリースしたように、TensorFlow（Lite）の普及促進のために出す、ということも考えられるが、AndroidやWear OSを持っている現在のGoogleにとって組込ボードという方法が正解のようには感じられない。そのAndroidにはAndroid NNというAPIが既に実装されており、ハードウェアやドライバーなどHAL（ハードウェア抽象化レイヤー）以下を準備すればアプリケーションから利用可能となっている。

　ところでこのEdge TPUであるが…恐らく現時点ではブロック ダイアグラム等の詳細は説明されていないと思うが、アーキテクチャが気になるところである。
　Pixelに搭載されたPixel Visual CoreはIntelの協力で開発されたとされるが、この「協力」の真意は謎である。Intelは子会社MovidiusでMyriadシリーズVision Processorを展開しているが、構造は全く別物である。Pixel Vision Coreはフラットな8コア構成に対し、Myriad 2は制御用CPU + OpenCV画像処理プロセッサー+12コアのDSP+メモリーアレイ、Myriad Xは制御用CPU + 画像処理プロセッサー+Neural Compute Engine (1TOPS) + 16コアのDSP + メモリーアレイという構成で、いずれのアーキテクチャーもメリット・デメリット両方あるので優劣についての議論は割愛するが、いずれにせよPixel Vision CoreとIntel/Movidius Myriadが同じ/派生アーキテクチャとは考え難い。もっとも、MicrosoftのKinectのような単体カメラならばともかく、画像処理プロセッサーを標準搭載しているスマートフォン向けアプリケーションプロセッサーでは重複する機能を省いただけかもしれないし、メモリーアレイを除けばMyriad 1とPixel Vision Coreの構成はよく似ているのであるのだが。

　個人的にはM.2/mPCIe接続版がどうなるのか気になるところである。
　実はIntel/Movidius Myriadは既に類似製品が台湾ASUS傘下AAEONよりUp-Boardブランドで販売されているものの、個人的には画像認識の方面には興味が無い＝仮にMyriad Xを使っても活かしきれないので見送ったが、もしEdge TPUが純粋なTensorFlow/Caffeアクセラレーターとして使えるならば興味深いところである。気になるのはmPCIe版はともかくM.2版のイメージ図がA-E key（USB2.0 or PCIe x2）でB-M key（PCIe x4 or USB3.0 or SATA）ではなさそうに見える点であろうか。NVMe SSDなどに利用されるB-M keyならばともかく、Wi-Fiや4G LTEなどに使用されるA-E keyの場合、ホストコンピューターにコネクターがあってもUSBしか配線されていないケースを見かけるため動作するのか不安である。

日本の外側より（2019-03-03）

再犯率、世界最低。ノルウェーの刑務所で何が起こっているのか？ - まぐまぐニュース！

　ノルウェーをはじめ北欧の刑務所ではホテル並みに設備が整っており「自分の部屋よりも豪華」などと評論されることは有名だが、あまり「なぜこうする必要があったか？」については説明されない。

　こういう記事で見かける厳罰か温情かという論理は実態とは言えない。もし殺人を犯した凶悪犯罪者が悠々自適な刑務所で税金を使って快適に生活しているというのはキリスト教や文化の違いとか慈悲の精神とかいうだけでは説明がつかないだろう。

　BBCで、過去に冤罪で投獄されたFo Ghlasが世界各国の刑務所を体験するドキュメンタリーが放送され、その中でノルウェーについても扱っていた。そこでの刑務官の説明は個人的には目から鱗の内容だった。
　ノルウェーには死刑がないため、前科者はいずれ社会に出てくることになる。元犯罪者に再犯させないためには普通の人の普通の生活を覚えてもらう必要がある、というのである。囚人は家の掃除や隣人との過ごし方を実践したり職業訓練として刑務作業だけでなく自動車の修理などの訓練を受ける。確かに釈放された後で就労できなければ自活できずに再犯する可能性がでてくるから必要なのかもしれない。

　記事は刑務所というか薬物犯罪についてだが、難しい問題だと思う。
　違法という意味では犯罪に違いないが、医薬品などとの境界も曖昧だったり、ある国で違法な薬品が別の国で合法ということも少なくない。私自身もアイルランドに就職が決まった際に風邪を引いており、薬物検査をギリギリまで延期してもらったことがある。日本の風邪薬に含まれる痛み止めの一部が欧州では麻薬として禁止されていたからである。

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

Linus Torvalds氏がArmサーバーはx86に勝てないと主張

ARM announces Ares - RealWorldTech Forum

　Linuxの開発者として知られ、過激な発言でも知られるLinus氏がArmサーバーは成功しないと主張したらしい。
　個人的に同意できる部分は数多くあるのだが、同氏はArm "Ares"（Neoverse N1/E1）のターゲットとするサーバーCPUについて言及しているのみで、スマートフォンや車載のような組込には言及していないように、それらは分けて考えられるべきだと思う。

　x86とArmに限らず開発環境・試験環境と商用環境が違う場合を考えてみるべきだと思う。
　例えば、仮に同じRed Hat Enterprise Linux 7上で開発されたとしてもEC2 t3.micro（x86）上で動作したコードがEC2 A1.micro（Arm）上で100％動作すると誰が言えるだろうか？それがたとえPythonのようなプラットフォームを問わないインタープリタ言語であったとしても、である。あなた自身の書いたコードは動作するかもしれないがimportした誰かが書いたモジュールが動作するとは誰も保証できない（あるいは保証するのに余計な工数を要する）し、そもそもそのモジュールはx86向けにしか抵抗されていない場合だってある。
　また、これは理論上動作するかどうかという問題に留まらず、動作しないリスクと責任の問題もある。動作するならばそれは問題ないが、動作しなかった場合は顧客にどう説明するのだろうか？調査や問題解決に要した時間・コスト増を誰が支払うのか？そういったリスクを背負う合理的な理由は無いし、上司や顧客を説得することはできないだろう。

　これらの問題を解決する最も簡単な方法は、最も普及しているプラットフォームで開発環境と商用環境の構成を揃えればいい。それがx86である。

　ここでGoogleやAmazonでの採用例を引き合いに出すのはナンセンスである。彼等には、それを可能にする技術者陣・コスト高を帳消しにできる数のインスタンスを動作させ電気代を支払っている。

　あるいは、こういう考え方もできるかもしれない「実はLinusはPCまでArmにしろと言っているんだよ！」と。そういうスレッドがRedditでも作成されている。