今週の興味深かった記事（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年 第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でも作成されている。

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

AppleはArmベースのMacを準備中？

Intel Confirms Apple Macs Will Switch to Arm CPUs by 2020, Says Report - Tom's Hardware
Apple's move to ARM-based Macs creates uncertainty - Axions

　iOSデバイス用CPUを自前で開発するようになって以降、AppleがMac用CPUをIntelから内製Armプロセッサーに乗り換えるという噂は何度も報じられたが、ここまで近い時期と具体的なプロジェクト名と共に報じられたのは初めてではないだろうか。

　A7以降で搭載されているApple設計によるArmプロセッサーは単位動作周波数あたりの性能が概ねIntel Coreシリーズプロセッサーと同等のため、性能面に関しては置き換えることに支障はなさそうだし、Appleは過去に2度もCPUアーキテクチャの乗り換えをスムーズに成功させた実績があるので（Motorola MC68K→IBM/Motorola PowerPC→Intel x86）、もしArmに移行となっても切り替えに問題は起こらないかもしれない。

　もし問題があるとすればBootcamp部分かもしれない。私の知る限りでも少なくない人々がMacでWindowsをブート可能にしているが、Windows on Armはリテールで販売されていないし、仮にArm用Windowsを入手できたとしてもApple製GPUのドライバーを組込む必要があるため、Microsoftの協力無しには実現できないだろう。

Arm Neoverse N1 / E1

Arm Launches New Neoverse N1 and E1 Server Cores - WikiChip

　ArmがAresプラットフォームというコードネームで発表していたプラットフォームの中核をなすCPUコアNeoverse N1/E1を発表した模様。

　先代Cosmosプラットフォームはモバイルで使用されるCortex-A57/A72/A75をそのまま流用したもので、例えばNeoverseを名乗っていたAWS Gravitonも実態はCortex-A72ベースだったが、今回はCortex-A76/A65の派生らしい。WikiChipの説明（N1, E1）を信じるならば、N1はA76のLoad/Storeユニットを倍増して強化したもので、E1とA65はほぼ同等に見える。

　個人的に気になるのはCortex-A65/Neoverse E1である。
　例えばIntelがCoreシリーズでHyperThreadingを有効にしつつAtomシリーズで有効にしなかったように、演算リソースが豊富でパイプラインストールのペナルティが大きいCPUの方がSMTは有効に動作するはずである。ところがArmはハイパフォーマンスのCortex-A76/Neoverse N1ではなくミッドレンジのA65/E1の方にSMTを実装した。これはMIPSを彷彿とさせる。これは私の妄想だがMIPSからArmにエンジニアの移籍でもあったのかもしれない。

3Dプリンター

金属3Dプリンターがステルス戦闘機のメンテナンス事情を劇的に改善している - GIGAZINE

　3Dプリンターは話題にこそなっているが私達の生活に入り込んでいるとは言えない。CADで3D図面を引く必要があるし、サプライチェーンが整備された大量生産品の方が効率が良い。3Dプリンターで製造した生産品は大量生産品に比べれば品質でもコストでも劣る。だから3Dプリンターの最適な応用先は大量生産が効かないかサプライチェーンの構築が困難でコスト高を許容できる市場のはずで、登場当初より最適な使い道と言われてきたのが軍隊である。

　軍は自己完結しているのが理想で、最強の米軍に至っては自前で前線までのサプライチェーンを構築するほどである。だから多少のコスト高も許容できる。問題は、やはりクリティカルな部品には使い難い点ではなかろうか。仮に形が同じものを製造できても不良品かテストできなければ判別はできないし、不良品でも致命的にならないもの、あるいはテストが簡単なもの（例えば銃のマガジンのような？）になるのではないかと思う。

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

Amazonによるeero買収

AmazonのメッシュWi-Fiルーター「eero」買収が意味すること - ITMedia
消費行動が筒抜けに？ アマゾンがWi-Fiルーター企業の買収で手に入れる「データ」の価値 - Wired

　eeroはメッシュルーターのベンダーである。米国では売られているが他では見たことが無い。
　メッシュルーターはIEEE 802.11sプロトコルで実現されており、Linksys・Netgear・TP-Link・Asus・Huaweiといった旧来からあるメジャーブランドに加えメジャーではないUbuquitiやeero・EnGenius・Tendaといったベンチャーも参入している。

　メッシュルーターを単なる「複数のAPを相互接続させて、接続性が高いWi-Fi」として理解するなら面白くもなんともないが、「スマートホーム/IoT機器のハブとしてのWi-Fi」として見ればAmazonの意図も解りそうな気がする。AmazonでIoTと言えば例えばDashボタンがあるが、Wi-Fiに接続できなければ無駄な装置である。Echo/Alexa・Fireタブレット・Kindle・Ring・Blinkなどの利用促進のためにはWi-Fiルーターの接続性向上とアプリによる一括管理は確かに必須に思える（だからこそGoogleも2016年にGoogle Wifiをリリースしている）。

　個人的に期待したいのは価格破壊である。メッシュルーターの弱点は複数台を揃える必要がある点である。3台揃えるなら当然ながら導入コストは約3倍になる。
　実はTendaを除くと802.11sメッシュルーターはQualcomm IPQ4018/4019を採用している。搭載メモリー容量やWi-Fiのチャンネル構成に若干の違いはあるものの、ほとんど同じ構成で3台セットで$250～$650程度・平均$450前後である。ちなみに同じプロセッサー類を使った802.11s非対応ルーターだと$100前後とはいえ、メッシュ対応ルーターはスマートフォンアプリで管理可能だったりマルウェア検出機能があったりと付加価値も高いので割高になるのは仕方ないところである。とはいえ、～$650というの驚くべき高価格だと思う。今回Amazonが買収したeero製ルーターも1台$199と高価である。
　では、価格分のメリットがあるかというと…実はメッシュルーターの通信速度は速くない。「同じプロセッサーを使った802.11s非対応ルーターが$100前後」と上述した通り、価格はハイエンドゲーミングルーター並でもスループットは普及価格帯ルーター並みである。あくまで接続性を向上させるための製品と言える。よほど家が大きい人でなければメリットを享受できないはずで、これではイマイチ普及しないのも当然である。

# 記事ではプライバシー問題に触れているが、そこまでプライバシーを気にする人は、そもそもスマートホーム製品など
# 使うべきではないと思う…。

Windows 10 20H1 Insider Preview

Windows 10プレビュー版に早くも来年公開向けビルドが登場 - PC Watch

　御存知の通り、Windows 10はSemi-Annual Channelという一般消費者向けビルドでは4月と10月の年2回で正式版のリリースを行っている。これまでThresholdとかRedstoneとかいうコード名がついてきたが、2019年からは{2桁年}H{1か2}というフォーマットに変更になった。H1なら前半・H2なら後半という意味なので、19H1だと文字通り2019年前半ビルドである。そんなWindowsの開発版ビルドに20H1が登場した。

　これは個人的にはさっぱり理解できないのである。
　Windows 10 version 1703からはUbuntuに近いポイントリリースモデルを採用している。これはメジャーバージョン・マイナーバージョンによる更新ではなく、リリース期限を定めて変更が大きかろうが小さかろうが期限までにリリースするモデルである。だからUbuntuを見ると最新版は18.10・開発版は19.04だが、フリーズまでは19.10の開発版が出ることはない。これは当たり前で、それまでTrunkで開発していたものから次期バージョンのブランチが切られた時点で自然にTrunkは次々期バージョンの開発版になる。

　MicrosoftはWindows 10でポイントリリースに切り替えたものの、どうもポリシーや品質管理が安定していない気がする。例えばversion 1803は3月にRTM・4月にリリースとなるはずが5月までずれ込んだし、version 1809に至ってはリリース後に比較的大きな欠陥が見つかって引っ込めている。特にversion 1809は2016年10月以来のLTSC（Long-Term Support Channel。大企業などで使われる）かつWindows Server 2019リリースと同期した極めて大事なリリースであったにも関わらずこの失態である。
　Ubuntuの場合、大きめの変更であったUpstartからSystemdへの移行は16.04 LTSを見越して1年前の15.04で実施することで16.04は無難に乗り切っている。Microsoftが次期LTSC=20H2を見越しているというなら分からなくもないが20H1というのが実に中途半端である。

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

「ちゃお」付録のセキュリティ

「セキュリティ意識が高すぎ」とネットで話題――ちゃお編集部に聞く - ITmedia

　ユーザーは煩わしい認証が嫌いだし、指紋認証など専用の設備が必要となるなど物理的・設備的な制約もある。仮に莫大な予算を費やしても完璧な対策は難しいのに、コスト的な制約があって実現が難しいのがセキュリティー対策の現実だと思う。

　そんな中…少女漫画雑誌「ちゃお」の付録のセキュリティが凄いらしい。金庫のようだが三要素認証を採っていて、三要素は(1)カード(2)PINコード(3)指紋のようである。セキュリティ分野では認証要素は以下の三種類に分類される。

• Something you have（有効なユーザーのみが所持しているもの。例：IDカード）
• Something you are（有効なユーザー自身。例：指紋、網膜）
• Something you know（有効なユーザーのみ知っていること。例：パスワード）

多要素認証の場合、異なるカテゴリーから認証要素を組み合わせるのが理想的だが、現実的には同じカテゴリーが重複することはよくある（例：フリーメールアカウントなどでのパスワードを忘れた場合の秘密の質問）。
　もちろん、付録を企画した大人は実在のATMやメールアカウントなどの認証を知っているから、大人が知っている認証方式を組み合わせた結果と見れなくもないが、上述の通り三種類の組み合わせとなっている点は驚きに値すると思う。

高速なDev.ioサイト

「爆速すぎて笑う」　表示速度が“異常な”Webサイト「dev.to」　その仕組みは - ITMedia

　「読み込み速度が3秒以上かかると40％のユーザーが離脱する」というGoogleの研究が知られる通り、一部のサイトでは表示速度は非常に重要だ。Dev.io自体はeコマースサイトではないので影響（例：売上換算でXX億円）の判断は難しいように思うが、理論実証（POC=Proof of Concept）の場としては興味深いと思う。

　個人的に気に喰わないのはJavaScriptを多用してモダンになった代わりに速度が大幅に低下したWebサイトだ。国・地域・ネットワークやアクセス方法（PCからWebブラウザー・携帯端末からWebブラウザー・携帯端末からアプリ）にもよるのだろうが、私の環境・利用方法ではロゴを変更後のAirbnbが極端に遅くなったほか、Facebookもどんどん遅くなっている。Airbnbは休暇前にしかアクセスしないので問題ないが、Facebookはセキュリティー問題なども含めて利用をやめてしまった。

静止画ダウンロード違法化

静止画ダウンロード違法化案「目的を見失っている」 - ITMedia
「意味のない法改正」「イラスト界が壊滅する」　違法ダウンロード対象拡大で漫画家らが“反対集会” - ITMedia

　米国が策定したDigital Millennium Copyrights Act（DMCA）などと比較すると発想の違いが物凄いと思う。
　どちらが良い/悪いとは一概に言える話ではないが、DMCAは著作権の保護とGoogleやFacebookなどのWeb企業のビジネスへの悪影響との妥協案のように思える。
　もし、例えばYouTubeに著作権を侵害する動画が投稿されたとする。著作権を保持している企業がGoogle/YouTubeに報告することで該当の動画を削除することができるが、言い換えれば「YouTubeはけしからん。著作権侵害を助長する可能性があるので、法規制すべきだ」などとは言っていないのである。だからこそGoogle/YouTubeはビジネスを継続・発展できるし、著作権を保持している側の権利も保護される。

　日本政府は悪い意味で過保護だと思う。管理主義社会と言い換えてもいい。「リスクがある」「けしからん」がそのまま法規制になってしまう。ネットスラングで表現するなら「セルフ経済制裁」というやつである。

　そもそも、海賊版の根絶やしは本当に有効なのだろうか？
　とある経済学者がTEDで語っていたスピーチが面白かった。長いので要約すると「有名スニーカーブランドの人によると、コピー商品が作られていないということは、自社ブランドの何かがおかしいからだ」と。該当のスニーカーブランドの名前は伏せられていたが言われていることは理解できる。Nikeのコピーが発展途上国で出回っていないということは、Nikeがコピーでも履きたいようなクールなブランドでなくなったことを意味してしまう。
　また、リンク先の記事にある海外でのジャンプの無料配信について触れられているが、そもそも海外ではジャンプ収録作品は手に入り難い状態にある。町の本屋に置いてあるわけではないし、もちろん言語の問題もある。翻訳された正規版コミックスの入手は可能だが町の本屋に置いていない知らないコミックスなど入手のしようがない。だからと言って海賊版が許されるわけではないにせよ、海賊版が販売促進の一端を担っていたといえなくもない実態がある。だから海賊版を正規版で置き換えようとするなら無料配信するしかない（最新話などに限定するにせよ）。これは現実に即した販促活動だと思う。

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

Intel 新CEOに暫定CEOが就任

Intel新CEOは暫定CEOを務めたCFOのRobert Swan氏 - PC Watch

　前CEOのKrzanich氏が部下との不適切な関係を理由に辞任した2018年6月から空席となっていたCEOポジションにCFOのRobert Swan氏が就任したらしい。優れた手腕が選出の理由とあるが外野から見る限りではよく分からない。2016～18年のIntelは10nm製造プロセスに泣かされたものの、2018年末以降は2019年中に10nmを製品化でき業績が改善する兆しが見えてきている。とはいえ、これは期間が短すぎるのでSwan氏の功績とは呼べないだろう。

　同氏についてはよく知らないのだが、Intelというバリバリの先端技術企業のトップが財務責任者＝CFO出身というのは違和感というか不安を抱かずにはいられない。
　半導体ビジネスというのは乱暴に言えば博打のような要素が少なくない。例えば1990年代以降の複雑なCPUを開発するには、100人規模の特殊技能を持つ≒高給取りのエンジニアが4年間ほどかけて開発するもので、さらに開発に失敗することも少なくない。想定した性能が出なかったり遅延するぐらいは当たり前で（例：AMD Bulldozer）、致命的な欠陥が見つかってキャンセルされることもある（例：Sun Microsystem Rock）。さらに製造関連も博打に近い投資が必要となるため、2014-15年の22nmプロセスや今回の10nmプロセスのようなトラブルでは普通の会社なら潰れていそうな損失がでる。もし財務畑出身のCEOが、「よし半導体製造ビジネスを独立させよう！」とか言い出しても私は驚かない。

Intel Xeon W-3175X

The Intel Xeon W-3175X Review: 28 Unlocked Cores, $2999 - AnandTech

　マルチコアが一般的でなかった2000年頃はコア数を倍にしても性能は1.2倍程度にしかならなかった。これはコア数4倍（2^2倍）では性能は1.44倍、コア数28倍で性能は2.69倍にしかならないということである。
　もちろん、20年前と比べればプログラマーの技術・各種ライブラリー・コンパイラーなどもマルチプロセッシングに最適化されてきているとはいえ、シングルスレッドでなければ処理できないものが無くなることはないわけで、28コアあっても1コアの28倍とはいかない。マルチプロセッシングに適したアプリケーションでもなければ、せいぜい3～4倍（コアを倍にすると1.5倍程度）が関の山であろう。

　Xeon Wシリーズはサーバー用ではなくワークステーション用のCPUである。サーバーであれば多数のユーザーが同時に並列でアクセスする≒必然的にマルチプロセッシングになるのであるが、ワークステーションのユーザーは通常1名なので相対的に並列化が難しい、かといってPhotoshop/Illustratorや各種CADアプリケーションなどで並列演算が効くものはGPUで並列化するようになってきているのでCPUで並列化が効くのか怪しい。

次世代XBOX "Scarlett"

Xbox Scarlett might be the first console with discrete graphics like a gaming PC - TechRadar

　XBOX Scarlettは「ゲーミングPCのようにディスクリートGPUを初めて搭載する」らしい。
　もっとも、この「ディスクリート」の意味は謎だ。そもそも、規模が相対的に大きいためCPUとGPUが別チップになっていることは多く、コストを抑える必要もあって各種ペリフェラルコントローラーがCPUかGPU側に統合されていることが多かった。例えばPlayStation2のGPU=Graphic SynthesizerやPlayStation3のGPU＝RSX Reality SynthesizerはディスクリートGPUと言って差し支えないと思うが、初代XBOXや二代目XBOX 360の場合はメモリーコントローラーを搭載しているのでPC用チップセットでいうところのNorth Bridgeに近い構成となっている。

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

Docker互換のPodmanが公開

Docker互換のオープンソースコンテナエンジン「Podman 1.0.0」が公開 - ＠IT

　未使用なのでPodmanについてのコメントはしないが、メリットがよく解らないところ。
　DockerはDocker社が開発しているが一応はオープンソースだし、Docker互換のコンテナエンジンは既にいろいろとある。いわゆるDockerイメージ（※通称）はOpen Container Initiativeにて公開されているので旧CoreOS（Red Hatが買収）のrktやGoogleが主導で開発しているKubernetesに含まれるCRI-Oなどはオープンソースの互換エンジンである。

　記事を読む限りでは、デーモンを必要としないというのがPodmanの特徴とも思われるが、個人的には「デーモンを使わないことによるメリット」はあまり思いつかない。
　そもそもコンテナ技術はchrootの隔離を高めたものなのでデーモンが必ずしも必要とは限らないが、各種の管理機構を実現するためにデーモンが動作することが多い。例えばDockerをデプロイするとdocker0という名称のLinux Bridgeが作られてコンテナはブリッジ経由でネットワークに接続されるが、IPアドレスをDHCPで割り当てたりホスト名で名前解決しているのはDockerデーモンである。これらを、別の技術で代替することは可能で、例えばホストeth0とdocker0とをフォワーディングしDHCP・DNSサービスを提供するソフトルーターをデプロイしてもいいだろうし、ホストeth0をdocker0に接続して外部のDNS・DHCPサーバーを利用する方法も考えられるが、前者は面倒だし後者ではコンテナのスケーラビリティーを活かせない。だからDockerデーモンに任せるのは手軽で理にかなっている。

AlexaやSiriにプライベートな会話を聞かれないようにする技術

Project Alias makes sure Alexa and Google Assistant won't hear a damn thing - TheRegister

　正直に言うと、私にはこの手の技術の需要が理解できない。

　スマートスピーカーは、「Hey Siri」「Alexa」や「Okay Google」といった特定の呼び掛けでコマンドを実行するために常に音声を拾い続けて待機している。しかし、もしユーザーが「待機している」と思っているだけで音声をGoogleやAmazonに送り続けていたとしても不思議ではないし、あるいは「聞き間違い」に近い誤認識によってユーザーが意図しないコマンドを実行してしまい、それらの結果としてプライベートな会話がAppleやAmazonやGoogleに送信されてしまうプライバシー問題は否定できない。

　…というのが、これらの研究のモチベーションなのであろうが…
　しかし、もしApple・Amazon・Googleがプライバシーを侵害していると思うならスマートスピーカーを使わなければいいし、特定の場合以外で動作してほしくないなら普段は電源を切っておけばいい。
　この記事の装置はRaspberry Piを使ってスマートスピーカーにホワイトノイズ（あらゆる周波数の音を含むノイズ）を聞かせることで実現しているようだが、その装置のオン/オフはできるのにスマートスピーカーのオン/オフができない理由がわからない。

　私が思いつくのは、例えばパブリックなスペースにスマートスピーカーが設置されており、その横に商談など秘密/機密情報を取り扱う部屋（会議室/応接室など）があるような場合に、部屋から漏れ出た音声をスマートスピーカーから遮断するような場合だが…その場合でも、その部屋の防音を高めるべきであってスマートスピーカーにホワイトノイズを聞かせるというのはズレている気がする。

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

カエルの合唱を通信の効率化に応用

「すごすぎる」「発想の勝利」　カエルの合唱の“法則性”、通信の効率化に応用　研究者に聞く - ITMedia

　この発想は私も素晴らしく見習いたいと思う。
　無線LANを含めた無線通信というのは厄介だと思う。ケーブルを介してやり取りする場合でも輻輳したり衝突が発生する場合はあるが、そのような場合でも検出は比較的容易だし回避する方法をプロトコルに織り込むことすら可能である。何より、異なるネットワークは物理的あるいは論理的に切り離される（あるいは、それが可能）なので衝突を起こしにくい。ところが、無線通信ではそうはいかない。

　それでも、PCやスマートフォンの無線LANの場合は比較的大きなアンテナ・アンプと大容量バッテリーを備えており、たとえ通信が途切れても再接続・再送すれば済む。
　それがIoTではうまくいかない。まず、数百・数千というデバイスが無線でネットワークに接続され通信が干渉しあうことが想像できる。さらに、小型・省電力のIoTでは通信障害が発生しやすく再接続や再送はしたくない。ならばIoT機器では最初から通信障害の発生し難いプロトコルが使用されるべきだというのが想像できる。

MongoDBがライセンスを変更

MongoDBとLLVM、ライセンス変更の動き - マイナビニュース

　新ライセンスは名前が実に厄介だと思う。新しいライセンス名は「Server Side Public License (SSPL)」という。
　例えばApache FoundationのソフトウェアはApache Public Licenseとソフトウェアの名前とライセンス名が一致しているので判りやすいが、MongoDBのAGPL改変版は「Server Side Public License (SSPL)」と実に汎用的な名前である。

　邪推するにMongoDB社はオープンソースコミュニティーは賛同こそすれ批判を受けると予想していなかったのではないか――つまり「Server Side Public License」というのはApache Public Licenseのような団体と強く結びついたライセンスではなくAGPLに代わる業界標準にしよう――としていたのではないかと思う。実際はというと、この改定を受けてDebianやFedoraはMongoDBをリポジトリ―から削除したそうであるが。

USB Power Delivery

これで失敗しない、USB PD充電器選び(解説編) - PC Watch

　充電器の話題ではあるのだが、充電器としての使い方に拘るのはテクノロジー系ニュースサイトとしては感心しない。
　USB Power DeliveryはAmpare/Volt/Watt数が問題となるため、まずは単純化して従来のUSBでとUSB給電＝5V/0.5-1Aで考えたい。Ankerなどが製品化している充電器では5ポート程度のUSB機器に同時に給電することができる。スマートフォンやタブレットの充電は当然として、小型Wi-FiルーターやRaspberry Piも5V/1Aで動作するし、空気清浄機や加湿器や電気スタンドへの給電も可能だ。さらに変換ケーブルを使うと様々な機器に給電できる。例えば私の手元にある装置ではAndroid TVボックスや7インチのモバイルディスプレイが5V/1Aだった。
　つまり充電器としてではなく新種の電源タップとして書斎や居間のデスクやベッドサイドに設置しておくと重宝する。
※注：後半はUSBの規格としてはかなりグレーで、変換ケーブルを使う方法はUSB Power Deliveryでは使えないので注意が必要

　より大容量の給電能力を安全に扱えるUSB PDではさらに用途が広がる。最近のラップトップPCではUSB PDで給電しつつDP Alternate Modeでディスプレイ出力・USB3.0をケーブル1本で接続できる。「スマートフォンの充電」という観点で選ぶのもいいが、ラップトップPCへの給電を視野に入れると容量が65-90w程度必要になることから選択肢はガラリと変わる。

　例えば、出張にUSB PD対応のMac Bookを持って行くと仮定する。このとき、Macへの給電用に純正のアダプターを持って行くという選択肢もあるが、どうぜスマートフォンやタブレットの充電もしたいだろうし、人によってはモバイルWi-Fiルーターや加湿器なども持参するかもしれない。そういった機器に同時に給電できれば便利だ。
　例えば1つめの選択肢としては、Apple純正アダプターの代わりにAnkerなどが製品化しているマルチポートのPD対応の充電器を使うことが考えられるが、上のAnker製品の場合は最大30wまでだったりと容量に注意が必要だ。
　そこで2つめの選択肢としては、デスクにPD対応USBハブを設置して、純正のUSB PD対応アダプターとPCとの間に挟みこむことで卓上機器に給電することができる。

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

産総研ABCIスーパーコンピューター

SC18 - 日本のAI普及の加速を後押しする産総研のABCIスパコン - マイナビ

　AI普及促進のため、というコンセプトは高く評価したいが…このSkylake世代Xeonに1CPUあたり複数個のNVIDIA Volta世代Teslaで構成された計算ノードにDDN製ストレージという組み合わせは2018年のスーパーコンピューターとしては一般的なものの気がしてならない。このスーパーコンピューターの見どころは温水冷却だと思うがAIとは関係がない。

Huawei Kunpeng

HUAWEI、64コア・2.6GHzのサーバー向けARMプロセッサ「Kunpeng 920」を発表 - PCwatch

　先進国ではネットワーク機器ベンダーとして知られるHuaweiは中国ではサーバーベンダーとしても知られている。Kunpengは、そんなHuaweiが同社製サーバー向けに開発・採用したプロセッサーであるが、Armv8-Aコアを64個集積されているということしか情報が無くCaviumやAmpareのように独自設計コアなのかすら不透明なところ。

　私が勝手に想像するに、Huawei/HiSiliconが独自設計するとしたら利益の大きい同社製スマートフォン向けプロセッサーKirinに搭載するものが先になると想像できる。一方で同社はKirinのAIアクセラレーターとして中国CambriconのIPを採用したように同じ中国内半導体企業のIP採用に積極的である。そのため、恐らくはArm純正のコアあるいは中国Phytium Technologyが2015年のHotChips 27で発表したMarsコアではないかと想像する。

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

AMD ZEN2世代 Ryzen "Matisse"のSKUのウワサ

AMD Ryzen 9 3800X "Matisse" listed with 16 cores and 125W TDP - VideoCardz

　ロシアのメディア経由でVideoCardzがZEN2世代のRyzen "Matisse"のSKUのウワサについて報じている。

　コア数の構成はそれらしく見えるが、個人的には動作周波数が高過ぎる気がしてならない。
　個人的な推測だが、AMDはZEN2世代で動作周波数をあまり上げてこない。なぜならZEN2世代ではコアの消費電力が増える可能性が高いからである：(1) ZEN/ZEN+世代に比べコア数が増える (2) Load/Storeが256-bit帯域になる。
　加えて、ZEN2登場以前の時点でIntel 第8/9世代 Core（Kaby Lake Refresh/Coffee Lake/Whiskey Lake/Amber Lake/Coffee Lake Refresh）に対する優位を考慮すると、仮に動作周波数を上げられるとしても第10世代に備えて温存する可能性が高い。

Sony a7000のスペックのウワサ

Sony A7000 specs leaked and it's set to be a jaw dropper of a camera - Digital Camera World

　Digital Camera WorldがSony a7000、いわゆるミラーレスカメラのスペックのウワサについて報じている。

　個人的には滅茶苦茶という気がしてならない。

• New Ultra Fast LSI・New BIONZ X
"Ultra Fast LSI"と"BIONZ X"の何が違うのだろうか？デジタルカメラは主に3種類の半導体で構成される。(1) Image Sensor (2) Analog Front-end (3) Digital Front-endだが(1)と(2)は通常は纏めて扱われる。Exmor RS CMOSセンサーが(1)で(2)も内蔵・BIONZ Xは(3)にあたる。
• 10fps/16Bit Mechanical Shutter

いわゆるミラーレスカメラは構造上メカニカルシャッターを持てない。オートフォーカスカメラでは像をセンサーで解析して測距・測光する必要があるが、一眼レフカメラの場合はミラーで反射した先にセンサーを置くためメカニカルシャッターを使用できる。これに対し、ミラーレスカメラはミラーが無いのでCMOSセンサーの裏側にセンサーを配置する必要があり、メカニカルシャッターを置けない

「空母」いずも

従来の延長線上に留まった新防衛大綱 - アゴラ

　日本国政府の国防に関する戦略などわからないが、私の意見を述べておきたい。

　まず、日本の国防は意図的に「言葉遊び」だらけである。そもそも憲法第九条のような無理難題を前提に世界3位の経済大国を防衛する軍隊を維持しているのだから致し方ない。
　諸外国から見れば世界有数の軍隊は「自衛隊」だし、他国では駆逐艦は「護衛艦」・ドック型揚陸艦は「輸送艦」・ヘリコプター空母は「ヘリコプター搭載護衛艦」である。13500トンDDH ひゅうが の場合はこれが顕著で、建造前のイメージ図では航空母艦を連想させないように前後の甲板が艦橋構造物で分断されていた。それが実際の建造時にはひっそりと加筆され艦橋構造物を右舷側に寄せ全通飛行甲板をもつ姿に変更された。そういうフィクションと既成事実化によって成り立っているのが我が国の防衛政策である。「言葉遊び」という指摘は「何をいまさら」と思う。

　さて「空母」だか「多用途運用護衛艦」だかの いずも 改修計画であるが、運用可能な航空機の数がイマイチ判然としない。記事中には「甲板上に8機、艦内の格納庫に2機、合計10機」とあるが、現在のヘリコプターの搭載定数や満載排水量を見ても少なすぎるとように見える。ここで米軍の強襲揚陸艦では比較にならないので排水量が比較的近いイタリア軍カヴールを比較してみたい。

	いずも級	Cavour	Wasp級
全長	248.0 m	244.0 m	257.3 m
全幅	38.0 m	39.0 m	42.7 m
排水量 基準/満載	19,500 / 26,000 トン	27,100 / 30,000 トン	28,233 / 41,335 トン
艦載機	F-35B 10機程度	F-35B 8機 ヘリ 12機	F-35B 20機 MH-60R 6機

貨物船のように全幅が広く基準排水量が大きい（ただし速度が遅い）米海軍ワスプ級はともかく、イタリア海軍カヴールは自衛隊 いずも 級と同等だが、F35B 8機にヘリ 12機を搭載できる。漫画『空母いぶき』ではF35Bを15機搭載可能という設定だそうだが、こうして並べてみれば突飛な数字でないのが分かる。

　記事中では時々の任務に応じてF-35Bを搭載するという政府の主張について「早くも2023年には「空母いずも」を運用するらしいが、一体いつ、どこで発着艦訓練を積むのか。「時々」訓練する程度では搭乗員らの安全をとうてい確保できない」と指摘しておられるが、ワスプ級強襲揚陸艦のWikipedia記事を見ても分かる通り、任務（例：制海任務・空中強襲）に応じて艦載機の構成が変更されるのは、この規模の航空母艦では割と普通である。

　ちなみに、JSF=Joint Strike Fighterについての記事中の主張は揚げ足取りレベルの言い分である。
　昨今はコストの都合で専用設計の多品種の機体を作れないためマルチロール機になる傾向がある。F-35は戦闘機を示すF=Fighterを名乗るが攻撃機A=Attackerや電子戦機Eの任務もこなすことが可能となっている。F-35B/F-35CがA-10やF/A-18Cの置き換えを計画されているのだから、これは当然である。
　この「戦闘機」と「攻撃機」の違いであるが、他国を攻撃するかなどではなく、空戦に特化しているか地上攻撃が可能かどうかによる違いである。実は航空自衛隊は「支援戦闘機」という名称で戦闘/攻撃機を保有してきた経緯を持つが、離島防衛などを念頭に置くとしても地上攻撃能力が無い航空機など役に立たない。

　以上、いろいろとコメントしてきたが、恐らく私のようなド素人が上述のようなコメントをしなくとも、記事の著者のような専門家は全て御存知のはずである。知った上で野暮な指摘をするのは非生産的なことこの上ない。
　聞くところによれば、かつて地中海世界を支配したローマ帝国は、元老院で戦争をするかどうか議論している所を異民族に進入されて全員殺されて滅亡したのだという。議論することは悪い事ではないがイデオロギーと心中するほど馬鹿馬鹿しいことはないと主張しておきたい。

イエスやマリアは誰だったのか？

　アゴラで「「マグダラのマリア」と「聖母マリア」」を読んだ。マグダラのマリアと聖母マリアの違いについてはキリスト教に馴染みのある人であれば今更という感じもあろうが、記事自体は様々な聖典・外典への言及が多く、興味深く読んだ。

　本題に入る前に「史的イエス」という概念に言及しておきたい。つまりキリスト教の教義から切り離されて史実を基に検証されたイエス像は聖書中の人物とは大きく異なり、史実を基にしたものが「史的イエス」である。
　以下、キリスト教的イエス（Jesusイエズスの音写）と区別する意図でヨシュア（‎Yĕhôshúʿa=Joshua）と記載することにする。

　記事中では、例えば外典『フィリポによる福音書』『マリアによる福音書』について言及があるが、外典とある通り新約聖書には収録されておらずローマ・カソリックでは正典とは認められておらず異端とされている。これはヴァチカン非公認ということであるが、とはいえヴァチカン公認の正典が正しく外典が誤っているという意味ではない。宗教的な見方でいえば正典が正しいのであろうが、ローマ・カソリックで正典と外典が定義が確認されたのはトリエント公会議のことで1546年のことで、歴史学的な視点とは必ずしも同じでない。とはいえ2世紀に書かれた外典『フィリポによる福音書』の歴史的な正当性は怪しいところであろう（この辺はWikipediaに詳しく記載がある）。

　ちなみに、正典は12人の使徒か使徒と直接関係のあった者の著作が中心となっているが、使徒の著書とされる『マタイによる福音書』『ヨハネによる福音書』はともかく、『マルコによる福音書』『ルカによる福音書』は使徒の弟子の著書とされるし、『ヨハネの黙示録』に至っては作者は諸説ある。そもそもこの12名のヨシュアの弟子は4つの共感福音書でも共通しておらず、実在したか疑う声もある。（※縁起が良い数字＝12から12使徒となったという説もある）

　ヨシュアの父が祭司長ザカリアという説も面白い。通常、ヨシュアの父＝ナザレのヨセフは大工とされることが多いが、そもそも聖書によると、（受胎告知の絵画などで知られる通り）ヨシュアはマリアの処女懐妊によって生まれたのだからヨセフは「養父」扱いである。もちろん処女懐妊など生物学的に不可能だからここでいう「父」はヨセフとは別の生物学的な父親を指すが、かと言って祭司長の子というのは論理が飛躍している気がしてならない。ヨシュアの血統に箔をつけたい中世以降のキリスト教徒による希望的観測だとしても私は驚かない。例えば記事中で根拠とされている「正式に妻帯できない」のくだりもヨシュアが祭司の私生児であれば成立する話で、祭司長ザカリアの子という根拠にならない。

　また、マグダラのマリアがイスラエルの女王というのは説としては面白いが同様に眉唾ものだと思う。ヨシュアは（聖書でも茨の冠を乗せられた通り）旧約聖書に登場するメシアとして「ユダヤの王」を称した、あるいはそういう冒涜的行為を行ったとされるが、この「王」は実在する国家の国家元首というよりは神の子という意味である。中世までは多くの国において形式上は王＝神から統治を託されたということになっていたし、ましてやユダヤは政教一体の国だったから、政治神の子が政治的な意味でも王となるのは自然な論理ではあるのだが…。ヨシュアがユダヤの王というのはあくまで信者の視点（願望）である。
　実際にユダヤを統治していたのは聖書にもある通りヘロデ王であったし、そのヘロデ王さえもローマ帝国の傀儡であった。だから記事中の「イエスとマグダラのマリアは夫婦となって『イスラエル王と女王』となるはずだった」という説は強引すぎる。また、一般的に信じられるマグダラのマリアは娼婦だったという説とも大きく矛盾する。娼婦というのは説に過ぎないので誤りかもしれないが、しかし女王なら記録が残っているはずで娼婦などという学説がでてくるはずがない。

　ちなみに、BBCで放送されたWaldemar Januszczak博士の解説（「The Dark Ages - A Age of Light」）によると、聖母マリアはヨシュアをギリシア神アポロ（エジプト神話ではホルス）に見立てた場合のエジプト神話のイシスで、布教の為に神格化されたのだそうだ。確かに人口や信者の半分は女性であることを鑑みれば神や聖人が男性ばかりでは都合が悪い。
　このような経緯を考えると、マグダラのマリアが実在したか否か、ヨシュアの教えを深く理解していたか否かに関わらず、彼女が使徒に担ぎ上げられるのも政治的・宗教的理由で理解できる気がするが、歴史学的にはやはり謎の多い人物である。

今週の興味深かった記事（2018年 第52週）

MicrosoftはMellanoxを買収するのか？

Microsoft to Buy Mellanox? - HPCwire

　イスラエルのニュースメディアの報道をHPCwireが引用したゴシップ記事ですが、個人的には訳が分からないところ。
　Mellanoxは10Gb以上のEthernetやInfiniBandの大手ベンダーで、Microsoftの事業でMellanoxに直接的に関わる部分は少なく、AzureやOffice365などのクラウド事業のインフラ廻りで採用している可能性が高いと思いますが、買収するほどのことかと個人的には疑問です。

　Amazon Web ServicesがAnnapurna Labsを取得して同社のAlpineプロセッサーを使ってElastic Network Adapter（ENA）やGravitonプロセッサーをAWSで提供しているように、MellanoxのネットワークアダプターやBlueFieldプロセッサーをAzureやOffice365で提供することは可能するシナジーは生まれるとは思いますが、Annapurna LabsぐらいのベンチャーならともかくInfiniBand最王手ベンダーMellanoxを買収してまですることなのか個人的には疑問です。
　尚、AWSはAnnapurna LabsをUS$ 350-370Mで買収したと報じられていますが、12月29日現在でMellanoxの時価総額はUS$ 4.9Bで、文字通り桁違いです。

Socionextの24コア Armプロセッサー

Banana Pi Teases 24-Core ARM Server Board - Toms Hardware

　Banana Piで知られるSinoVoIPが開発・製造・販売するホビー用シングルボードコンピューター/開発ボードにSocionext製SC2A11を採用したBanana Piが登場するようです。

　Socionext SC2A11自体は新しいものではなく、2017年3月に発表済・Arm/Linaroの主催する96Boardsで開発ボードが既に出ていますが、この開発ボード自体は$1200もします。Banana Piが幾らで販売するかは不明ですがそれよりは安価であろうと想像します。
　Socionextというと一般に馴染みが無いように思われますが、富士通のLSI部門とPanasonicのLSI部門が独立・合併して設立された日本の会社で、NikonのExpeed・SigmaのTrue・GoProのGP1などの映像エンジンは同社（旧 富士通）のMilbeautをベースとしており、パナソニックのデジタル家電で採用されているUniPhier（LumixのVenus EngineやVieraのPeakを含む）も同社製となっています。

　SC2A11に話を戻すと、個人的には中途半端なプロセッサーと思います。一般には24コアは多いと思いますが（現在はMellanoxに買収された）EZChipに買収されたTileraは2015年2月に同じCortex-A53を100個メッシュネットワークで接続して集積したTile-MX100を発表しており目新しくもありません。24コアとはいえ採用されているCPUコアはRaspberry Piなどと同じCortex-A53で高性能なCortex-A57/A72ではなく非力です。先のTile-MX100の場合も発表はされたものの製品化されず、Mellanoxが買収後にBlueFieldでCortex-A53からCortex-A72 16コアに入れ替えたぐらいです（ちなみにAWS GravitonもCortex-A72 16コア）。ましてやSC2A11の場合はTile-MX100とは違い10/40/100GbEやInterakenなどの強力なネットワーク機能があるわけでも、暗号化などのアクセラレーターを搭載しているわけでもありません。SC2A11の発表時に動画トランスコーダーでの使用例が紹介されていますが実際のトランスコードは同社製MB86M30で行うこととなっておりSC2A11自体にはビデオ処理機能は搭載されていません（…もし動画トランスコード機能内蔵なら、いわゆるエンコ厨を中心に需要があった気もしますが…）。

　24コアもあるのでRaspberry Pi 3（4コア）などと比較すると高速なのは間違いありませんし、マルチスレッドのプログラミングなどの練習台として使えるのは理解できますが、仮に$1200もするなら8コア/16スレッドのRyzen 7の方がシングルスレッド・マルチスレッド共に少なくとも2倍～4倍は速いはずで、「スーパーコンピューター」などと形容するのは買いかぶり過ぎなように思います。

GMOが仮想通貨マイニング事業の損失計上でマイニングマシンの開発・製造・販売を終了

GMOの特別損失の計上が話題に 仮想通貨マイニング事業で総額355億円 - Livedoor News

　マイニング特需が終了してメインボードやGPUの値下がりと在庫処分が話題となっている昨今ですが、GMOがマイニングマシンの開発・製造・販売を止めるそうです。
　本件はHisa Ando氏の投稿を見て知ったのですが、マイニングマシンは今年6月に発表済・10月末から出荷の予定が遅延していたために初期の顧客には返金を行っていたそうで、結局1台も販売していないと見られているそうです。マイニング特需終了に併せてNVIDIAが在庫のGP104を流用してGDDR5X対応版GeForce GTX 1060を発売したのが10月末～11月初頭なので、完全に時期を読み間違えたように見えます。

　ところで、このマイニングマシンに採用されているプロセッサーは、GMOが開発を第三者（社）に委託して行ったという話で、恐らくはPezy ComputingグループのZettaHashが担当していたものと推測されます。Pezy Computingグループといえば助成金詐欺疑惑による齊藤元章社長の逮捕や海洋研究開発機構（JAMSTEC）との契約違反によるスーパーコンピューター「暁光」の撤去・開発費の返還要求など（自業自得ではあるが）逆風が吹いていますが、大丈夫なのでしょうか…