goo blog サービス終了のお知らせ 

ALH84001

私的コラム&雑記(&メモ)

今週の興味深かった話題(2020年第11週)

2020-03-15 | 興味深かった話題

HPEによる買収後のCray

Steve Scott Lays Out HPE-Cray Blended Product Roadmap - HPCwire

 元CrayのCTOのSteve Scott氏がプレゼンテーションを行ったそうだ。
 前提となるCray・HP Enterprise各社の現在の製品シリーズを説明すると、まずCrayはHPC製品のファミリーを主に2種類持っている。ひとつが独自規格ラックや独自インターコネクトを使用したもので、現行世代ではSlingshotインターコネクトを使用したShastaシリーズや前世代のAriesインターコネクトを使用したXCシリーズがこれにあたる。もうひとつがApproの買収により追加された標準19インチラックやInfiniBandといった標準的な部品で構成されたクラスターサーバーのCSシリーズである。
 実は、Shastaに関して言えば、ソフトウェアから見たハードウェア構成は同一ながらも独自規格のラック・液冷・メザニンカード・スイッチを使用したMountain構成と、標準19インチラックに空冷ユニットや標準規格のPCIeカードを使用したRiver構成とがある。
 次に、買収した側のHPEであるが、Cray以前にもコンピューター企業を多数買収したものの、製品シリーズの統廃合を行った結果、現行のHPC製品としてはApolloシリーズのみがある。

 今回の発表で明らかになったのはCrayのShasta MountainとRiverのリネームで、前者がOlympus・後者がApolloとなり、後者がそのままHPE Apolloシリーズと統合され、今後はHPEのデザインを使うというものである。また、将来的にはCSシリーズはApolloに統合されるのだという。つまりCray 3シリーズとHPE 1シリーズの統廃合で2シリーズに集約される。
 そのほか高可用性サーバーのSuperdome FlexやマイクロサーバーのMoonshotも同じSVP(元Cray CEO)傘下となるようだが、さすがにこれらは用途が異なるので統合はされないだろう。

 個人的には歴史的に見てHPEは統廃合の上手な企業だとは思わないが、これは悪手に思える。
 実際、HPEは過去にApollo ComputerSGIのほかCompaqを通してDEC AlphaServerとHPC・PCクラスターを手掛ける企業を多数手中に収めてきたが、いずれも現存しておらず、現在はPCサーバー=ProLiantシリーズの上位に設定される高性能サーバーApolloシリーズしかない(ただし旧Apollo Computerとは縁も所縁もなく、ブランド名を再利用しただけである)。SGIを買収した時はSGIからNUMAlinkインターコネクトなどを導入したが、標準製品で置き換えられ、現在でも残っているのはHPE MPIにリネームされた旧SGI MPIぐらいのものである。
 同業種の企業が売買収された場合に重複する製品が統廃合されることは驚くことではないが、どちらかと言えばHPE ApolloシリーズはCray CSシリーズに近く、Cray Shasta River(新Apollo)と統廃合されるというのは理解に苦しむ。

 ところで、個人的に興味深いのが記事中3枚目の写真である。
 Crayは米エネルギー省(DOE=Department of Energy)の次世代HPC 4システムで全勝しており、1システム(Perlmutter)がAMD CPUノード+AMD CPU + NVIDIA GPU ノードのハイブリッド・2システム(Frontier・El Capitan)がAMD CPU + AMD GPU・1システム(Aurora)がIntel CPU + Intel GPUという構成になっているが、この3枚目の写真中の構成の組み合わせで実現される。

 興味深いのはIntel CPU + Intel GPU構成では2 CPU + 6 GPUの組み合わせで恐らくCPU側からSlingshotに接続されるのに対し、AMD CPU + AMD GPU構成では1 CPU + 4 GPUの組み合わせでGPU側からSlingshotに接続している点だろう。

 まずCPU+GPUの構成についてであるが、Intelの2 CPU + 6 GPUという構成は、例えば現在Top500首位のORNL/IBM Summitがそうである(IBM POWER9 x 2 + NVIDIA V100 x 6)ように現在の典型的な構成である。しかし、SummitのTop500ベンチマーク計測がそうであったように、現在のHPCではGPUだけで演算してしまうことが多く、乱暴に言えればCPUに対するGPUの比率が大きいほどノードあたりの性能を上げやすい。AMD CPU + AMD GPU構成(CPU:GPU = 1:4)はIntel CPU + Intel GPU構成(CPU:GPU = 2:6)よりもGPUの比率が大きく性能を上げやすい可能性がある。

 次にインターコネクトの接続形態であるが、最近のGPUはネットワーク経由で直接GPU-GPU間コミュニケーションができ(Mellanox GPUDirect RDMA)、NVIDIAがMellanoxを買収したのもこれが理由のひとつと考えられる。機械学習などで多数のGPUでひとつの演算を分散して行う場合にCPUを介してアクセスするよりもCPU負荷を低減でき遅延も小さくなる。これまでもPCIeスイッチなどを介した実装は行われてきたが、CPU-GPU間接続とは独立してGPUに直接ネットワークインターコネクトを接続した例はなく、こちらも性能向上を期待できる。

富士通の気象庁気象研究所の新HPC

富士通の新スパコン、世界最高レベルの気象予測精度達成に向けて稼動開始 - 日刊工業新聞

 富士通のHPCとはいってもA64FX系でもSPARC64系でもなくIntel Xeonで、GPUは使用していないようだ。

 一見すると何の変哲もない構成に見えるが、興味深いのはIntel Omni-Pathを採用している点である。
 Omni-PathはQLogicのInfiniBand部門を買収したIntelが開発したInfiniBand競合のインターコネクト技術であるが、昨年8月に開発中止を発表しており、普通に考えればそのような製品は採用しないであろうから実に不思議である。

 ここからは筆者の推測であるが、Intelの在庫一掃で安価に入手したのではないかと邪推する。
 実際、2019年3月にオーストラリアの石油探査企業DUGがHPCを導入する際にも8カ月ほど前に開発中止を発表していたXeon Phi(Knights Landing)のウェハ38000枚分を採用している

 ところで、CPUのみの構成を採用しディープラーニングに触れない点も興味深い。
 筆者は気象予想には全く詳しくないが、気象予想は二種類の科学で構成されていると理解している。ひとつが流体力学であり、もうひとつが過去の気象データに基づく予測である。
 流体力学は物理シミュレーションのため、数値の型でいえばFP64、精度を落として加速したければFP32の使用が考えられる。そのため、これまでの気象予測用HPCではFP64性能重視だったことは理解できる。
 もう一方は過去の気象データで類似している現象に基づいて予測するもので、これはそのままディープラーニングの得意分野である。そして、ディープラーニングではほとんどFP64は使用されずFP32かbFP16で学習・bFP16かINT8で推論して結果を導き出す。

 その考え方でいえば、FP64に強い高性能CPUの採用は理解できる一方で、FP32/FP16/INT8に強いGPUの採用がある方が自然に思えるが、あえてGPUが採用されていない点は興味深い。

4G ルーター

 私事だが、同僚に4Gルーター(4G CPE)の貸し出しをしたので紹介したい。

 新型肺炎=COVID-19に関連して勤務先社で2週間~1カ月の在宅勤務を言い渡された。
 …と言っても、私や同僚が中国やイタリアに滞在したというわけではなく、欧州では身近にイタリアに渡航した人がいてもおかしくないはずで、在宅勤務で様子見というのは企業が事業を続けていく上で悪い選択肢ではない。そもそも欧州・米国では日本よりもテレワーク環境が普及している(というか法律で企業に義務付けている場合が多い)ので、突然、明日から在宅勤務となっても困ることは無い。
 ところが、同僚の1人がスマートフォンしか自宅にインターネット接続が無いという話だったため、私が個人で所有している4G ルーターを貸し出した。

 4Gルーターには、PCと共にホテルやカフェなどに持ち込んで使用する小型・バッテリー搭載のモバイルWi-Fiルーター(欧州ではMiFiとも呼ばれる)や宅内設置型でバッテリー非搭載だが通信性能が高いCPE(Customer Premises Equipment)などが考えられる。
 前者は移動先でPCなどでインターネット接続するのに使用するわけだが、後者は自宅や事務所などに設置して使用する。4G/5Gになってブロードバンド並の速度も確保されてきているから、何らかの理由でADSLや光ファイバーによるインターネット回線を引くことができない場合、携帯電話回線を使ったブロードバンドルーターを利用したインターネット接続は選択肢のひとつである。

 ところで、モデムは非常に門戸の狭い市場である。現在市場にいるプレイヤーだと端末側は米Qualcomm・韓Samsung・台MediaTek・中HiSilicon(Huaweiの半導体子会社)などである。最近はコモディティ化が進んでいるとはいえ、元を辿ればキャリアとの接続が保証できなければモデムを製品化することができず、言い換えればキャリアはQualcomm製チップセットでしかテストしないので端末メーカーもQualcomm製チップセットを採用するのが安心・安全である。
 このため、モデムビジネスに参入しても撤退する企業は多い。2010年に芬Nokiaから事業を買収して参入したルネサスも2013年に撤退しているし(米Broadcomが買収)、2019年に米Appleが買収して話題となった米Intelのモデム事業も元は2010年に独Infineonから買収したものだし、2011年にモデムベンチャー米Iceraを買収して参入した米NVIDIAも2016年に撤退している。

 ただし、誰もが持っている携帯電話と違い、4G MiFiやCPEはマーケットもプレイヤーも限定的である。
 Huawei・Alcatel(ブランドのみ。中身は中国TLC)・中国ZTEなどが端末を出しているが、Huawei端末のモデムチップセットはHiSilicon製・AlcatelやZTEのモデムチップセットはQualcomm製である。3GまではHuaweiもQualcommチップセットを使っていたのだが、4Gになって自社製品に切り替えた。

 私が所有している4GルーターはHuawei B528s-23aでHiSilicon製Balong 722モデムを使用している。
 Huawei製というと昨今は情報漏洩リスクを指摘されそうだが、私のインターネットアクセスのほとんどはHTTPS(アプリケーション層)で暗号化されておりルーター(ネットワーク層)で情報を抜くことは困難である(言い換えると、Huawei製スマートフォンを購入する予定はない)。その一方で、Huawei製端末はQualcommチップセット搭載端末よりも対応するバンドが幅広く・高速な製品が相対的に安価で入手できる。


今週の興味深かった話題(2020年第10週)

2020-03-07 | 興味深かった話題

MarvellのOcteon TX2とOcteon Fusion

New Marvell OCTEON TX2 and Fusion CNF95xx 5G SoCs - ServeTheHome

 CaviumのOcteonからMarvellのOnteonへ。それを印象付けられた発表だった。

 OcteonとはMarvellが2018年に買収した旧Caviumを代表するネットワークプロセッサーのブランド名である。
 Cavium Octeonといえば、元はCavium独自設計のMIPS64プロセッサー=cnMIPSコアを多数集積したネットワークプロセッサーで、ルーターやファイヤーウォールなどのプロセッサーに採用された。Octeon FusionはそのOcteonにベースバンド処理用にDSPを統合したものである。
 サーバー向け製品ブランドThunderXを期にCaviumはMIPSからArmに乗り換えており、Marvellによる買収前の2016年に発表されたOcteon TXではThunderXのArm CPUコアが流用されている。

 今回、Marvell傘下になって初めてOcteonブランド製品を発表したわけであるが、なかなか興味深い。

 まず、象徴的なのがOcteon TXのCN9130のCPUコアが自社開発ではなくArm製のCortex-A72という点だろう。注目すべきは、Octeon CN9130はArmada 7040とほぼ同スペックである点で、恐らくはリブランディングだろう。MarvellはCavium買収前からArmadaブランドの組込プロセッサーを持っておりローエンドのネットワークプロセッサーとしても利用されていたが、OcteonファミリーとArmadaファミリーとを統合しつつあるようだ。

  CN9130 Armada 88F7040
CPU Arm Cortex-A72 x4 Arm Cortex-A72 x4
Memory DDR4 DDR4
PCIe Gen3 6 lanes
PCIe x4 x1 lane
PCIe x1 x2 lanes
Gen3 6 lanes
PCIe x4 x1 lane
PCIe x1 x2 lanes
I/O SerDes x6 lanes
SATA 3.0 x2
USB 3.0 x2
SerDes x6 lanes
SATA 3.0 x2
USB 3.0 x2
Ethernet 10GbE x1
5/2.5GbE x1
2.5/1GbE x1
with Packet Processor
(Parser/Classifier/Buffer/PTP)
10GbE x1
2.5/1GbE x2

with Packet Processor
(Parser/Classifier/Buffer/PTP)

 次に気になるのはOcteon TX2上位モデルのCPUコアである。なにせ「ARMv8.2」という記述で具体的な名称が伏せられている。CN9130と違いArmのコア名でもなく、先代Octeon TXのようにThunder X系コア名が記載されているわけでもない。
 公開されている情報が僅かにも拘らず、このコアには謎が多い。まず、もしThunderXとOcteon TXの関係のようにThunderX2コアが用いられているのであればARMv8.1であるはずだが、このコアはARMv8.2を名乗っている。さらに奇妙なのが66KB I-cache 41KB d-cacheという2^Nにならない中途半端なスペックである。数字の珍妙さはそれぞれ64KB・40KBの誤植として目を瞑るとしても、現行CaviumのThunderX2の場合L1命令キャッシュ/L1データキャッシュがそれぞれ32KB/32KB、Arm純正のCortex-A72が48KB/32KB、Cortex-A77が64KB/64KBのいずれとも合致せず、別物と考えるのが自然だ。

 ではこの「ARMv8.2」コアは何者だろうか?
 ところで、現行のThunderX2は旧Caviumが当時Broadcomが開発中だったVulcanコアを買収し、自社製SoCに組み込んだもので、Caviumが開発していた旧ThunderX2とは同名ながら別物である。
 もともと前世代ThunderXはcnMIPSの流れを汲む低性能なコアで、別のThunderX2開発が進行中だったが、2017年11月頃にCaviumがBroadcomからVulcanコアを買収してこれを置き換えた。恐らくCaviumが開発中だったcnMIPS系コアではThunderX製品ファミリーがターゲットとするサーバーCPUとしては性能不足だったため高性能なVulcanに置き換えたと考えられる。
 AnandTechの記事が解り易いが、ThunderXとVulcanでは設計思想とターゲットとするパフォーマンスが全く異なる。ThunderXコアのダイアグラムは公開されていないが、ほぼcnMIPS(HotChipsのプレゼンテーションPDF)の命令セットをMIPS64からAArch64へ置き換えた物と推測されており、2イシュー/2実行ユニット/インオーダーのシンプルな設計である。これに対し、Broadcomの主張によればVulcanのシングルスレッド性能はIntel Haswellの9割程度に達する。

 ThunderXファミリーはサーバー向けプロセッサーだったから、この判断は正しかったのだろう。ただ、cnMIPSはネットワークプロセッサーに最適化されたコアだったのでOcteon TX2にVulcanが合うかというのは別の話であろう。

 ここからは筆者の推測になるが、今回のOcteon TX2の「ARMv8.2」コアはVulcan買収前に設計していた旧ThunderX2である可能性がある。実際、Vulcan買収前の旧ThunderX 2の製品ページ(InternetArchiveの2016年6月のアーカイブ)を見ると命令キャッシュ/データキャッシュ64KB/40KBのコアの情報が見られる。

Ampereが80コアAltraを発表

Ampere Aims For The Clouds With Altra Arm Server Chip - TheNextPlatform

 前世代eMAG(Skylark)の最大32コアからAltraで最大80コアとなったが、独自設計コアからArm純正のNeoverse N1(Cortex-A76相当)のセミカスタムコアへと変更になった。

 類似品としてはAWS Graviton 2があるが、同じNeoverse N1を採用しつつもGravion 2の64コアに対しAltraは80コアと16コア多い。
 Graviton 2はArm社のリファレンス通り6x6のメッシュの64コア構成で、Armのリファレンスを使うというのはCPU開発能力を持たないAWS/Annapuruna Labsが安価で高性能を得るという意味では納得できるし、性能面ではMarvell/CaviumのThunderX 2と比べて見劣りするものの、AWSがGraviton 2を例えばS3などで使用するとすれば妥当そうに見える。
 一方のAmpere Altraは立ち位置が微妙に思える。Marvell/Cavium ThunderX 2ほどの高性能でもなく、クラウドベンダー内製のGravitonほどのコスト削減の効果も無いとすれば、ThunderX 2の方が魅力的に見える。

 ちなみに、Altraは「80 Cores + Coherent Mesh Network」と記載があるものの、Armのリファレンスデザインを使っているのかはよく分からない。
 ArmのHyperscaleデザインは「64 - 128コア」を謳うがCoreLink CMN-600 Coherent Mesh Networkは1 - 32タイルに対応しているため、2コア/タイルで最大64コア・4コア/タイルで最大128コアとなる。AltraがCoreLink CMN-600を使っているとすれば4コア/タイルで5x4か6x4(4個のI/O用タイル)のメッシュということになるだろうが、2コア/タイルでも4コア/タイルでもネットワーク帯域は変わらないため、2コア/タイル構成の方がジッターの影響を受け難くなる(ちなみに動作周波数によるだろうが、ドキュメントによると2 - 10 GB/sec/タイルのようだ)。
 もちろん、AmpereがCMN-600ではなく自社設計のインターコネクトを採用している可能性もあるが、もしCMN-600を使っているのであればGraviton 2 64コアとAltra 80コアを比較した場合にコア数分(+25%)も性能差がでない可能性がある。

 上述の通り、AmpereはAltraでArm純正コアを採用し、Macom/AppliedMicroから買収したX-Gene系のコアを放棄したようだが、その判断は妥当そうに思える。
 先代までのX-Gene系コアは4イシュー/4実行ユニットのアウトオブオーダー設計で(HotChipsでのプレゼンテーション)、概ねIntel Atom程度のパフォーマンスであった。それに対しArm純正コアはCortex-A76/A77・Neoverse N1で高パフォーマンス設計に方針転換しており、旧AppliedMicro系コアとArm純正コアとの間に性能差は失われつつある。言い換えれば巨額の投資と高リスクを背負ってまで自社設計するメリットが無くなったのだろう。
 もっとも、パフォーマンスや投資の観点から独自設計を止めArm純正コアを採用するという判断は理解できるのだが、既存顧客から見てAmpere製品を選ぶ差別化ポイントも同時に失われたように思える。唯一の救いはAmpereと同様にNeoverse N1を採用してサーバー用SoCを開発しているAWSやHuawei/HiSiliconがプロセッサーの外販をしておらず、顧客には他の選択肢があまり無いことぐらいだろう。


今週の興味深かった話題(2020年第09週)

2020-03-01 | 興味深かった話題

IntelがAtom P5900シリーズを発表

Intel、10nmで製造される最大24コアの「Atom P5900」- PC Watch

 「5G基地局向け」ネットワークプロセッサーということで、Intelは2014年にAvago(現Broadcom)から旧LSI CorpのAxxiaビジネスを買収しているので資産はあるはずだが、事実上は再参入ではないかと思われる。
 基地局といっても宅内に設置できるFemtocellからMacrocellまでアクセスネットワークも様々であるし、その後方にはコアネットワークがあったり、それぞれに使われる機材も様々であるが、P5900と同じマーケットということだと、Marvell(旧Cavium)・NXP・Texas Instruments・Broadcomがプロセッサーを作っているし、Huawei/HiSiliconなど自社製ネットワーク機器向けにプロセッサーを作っているベンダーもある(以前はEricssonやNokiaも作っていたはずだが…現在はよく分からない)。

 Atom系プロセッサーにQuickAssist Technology(QAT)の組み合わせでは、以前はAtom Cシリーズ(現行はGoldmontコアベースのDenverton)が知られており、構成は似通って見えるが、Atom Cシリーズが小型サーバー・L3スイッチなどの制御用・NASのようなネットワーク機器で使用されていたのに対し、Atom P5900が「5G基地局向け」と銘打っているあたりが目新しい。

AMD Zen 2の回路設計

AMD Zen 2 CPUコアの物理的な姿が明らかに - PC Watch

 2月16~21日に渡ってISSCCが開催されていたこともあり、先週末から今週にかけてメディア各社が関連ニュースを報じているのが目立った。

 本記事は後藤氏によるISSCCでのAMDの公式発表の解説が中心で、しかも以前に発表されていたZen 2の仕様を裏付ける内容のため、概ね納得できる内容ではないかと思う。

 個人的に気になったのは、2コア版CCXについての後藤氏の洞察の部分で、2コア版CCXが単体では不経済なので4コア版CCXと組み合わせて6コア構成というアイデアは理解できるものの、次世代ゲームコンソールでは使用されないのではないか。理由は2つあり (1) 次世代ゲームコンソールでは40コア前後のGPUと組み合わせるのでZen 2 2コア分の違い(2コア版CCX + 4コア版CCXか、4コア版CCX x 2か)はコスト的に微々たるものになる可能性がある (2) 現行世代ゲームコンソールPS4・XBox Oneは物理8コア搭載しているため互換性維持のためには物理8コアが好ましい。

 AMDが実際に2コア版CCXをどう使うのかについてはAMD関係者のみ知るところだろう
 私ならばマイクロコントローラー的な使い方を想定する。例えばIntelはIce Lakeにも使用されているSunny Coveコアを"Spring Hill"ことNervana NNP-I1000プロセッサーでも使用しており、ランタイムの実行や12コアのICE(Inference Compute Engines)の制御に使用している。このような用途であれば2コア版CCXは使いやすいと思われる。
 (ここまでくると予想というよりも妄想だが)もしゲームコンソールで使うのであれば、2コア版CCX + 10コア GPU + 128-bit GDDR6メモリーコントローラーでチップレットを作り、4チップレットでAPUを構成する方が説得力があるのではないか。


今週の興味深かった話題(2020年第08週)

2020-02-22 | 興味深かった話題

英気象庁が新HPC導入を発表

UK Announces £1.2 Billion Weather and Climate Supercomputer - HPCwire

 2022年に退役するCray XC40 3台を置き換えるHPCを導入する計画だそうで、現行の6倍の性能を見込んでいる。
 …と、ここまでは特筆すべき内容ではないが、記事後半にはCray製のMarvell ThunderX2ベースのHPC「Isambard 2」にCray製の富士通A64FXベースのノードを追加するという英政府の発表について記載されている。
 ちなみに同一の記事に記載されているため関連記事と誤解しそうだが、英気象庁の案件は現在RFP(Request for Proposal)段階でベンダーやシステムは選定されておらず、さらに少なくとも開発の50%は英国で行うことが要求されていることからHPE/Crayや富士通が対象になるとは考え難い(とはいえ、英国にHPCベンダーなど無く、欧州では仏Atos/Bullがほぼ唯一のベンダーのはずであるが…)。

 これまで、Cray製A64FXベースCS500システムは富士通製FX700ベース(1Uラック)ではと推測さてきたが、記事中にはSC19で展示されていたというA64FXベースのCS500ブレードが掲載されており、1Uラックではなくブレードであることが見て取れる。
 ブレード後方(写真左側)の巨大な2個の銅製ヒートシンクがA64FXでブレード前方(写真右側)にPCIe x16が2スロットとM.2 SSD二基が見える(少なくとも計PCIe 40レーン。Ethernetと思しきコネクターも2個見えるため管理用BMCもあるのかもしれない)が、A64FXは各PCIe 16レーン(2ソケットで計32レーン)しかないため中間に見える黒いヒートシンクに覆われたチップはPCIe Switchと推測できる。以前から指摘してきたがA64FXは現行のサーバー用CPUとしてはPCIeのレーンが圧倒的に不足している一方で、この構成ではSoCに内蔵されている理研Tofu-Dインターコネクトのロジックは無駄になっており、率直に言って設計ミスと言わざるをえない(本来であればPCI-Express 32-48レーンをSoCに組み込んで、理研にしか需要の無いToFu-DはPCI-Express接続で外付けすべきである)。

独シュトゥットガルト大学Hawk HPC

University of Stuttgart Inaugurates ‘Hawk’ Supercomputer - HPCwire

 独シュトゥットガルト大学が「Hawk」HPCを導入した模様。ベンダーは米HP Enterpriseであるが傘下のCrayではなくHPEのApollo 9000がベースとなっている。Apolloはかつて存在したHPCベンダーであるが現在はSGIなどと共にHPEの1ブランドとなっている。

 記事からのリンクでシュトゥットガルト大High Performance Computing Center(HLRS)の発表記事およびスペックシートが見られるが、44ラック/5,632ノード/720,896コアという構成でGPUのようなアクセラレーターは搭載していないようである。EpycはDDR4 SDRAM 8チャンネルだから90,112 DIMM/1.44 PBということで1チャンネルあたり16 GB DIMMモジュール1個という構成と推測できる(つまりソケットあたり64C/128T+128GB)。

 興味深いのはインターコネクトがMellanox HDR200 InfiniBandで9D-Hypercubeという点だろう。
 最近のHPCではFat-treeやDragonflyが大勢で一部でTorusも見られるが、Hypercubeは久しぶりという感じがする。9D Hypercubeということで、どのように構成しているのか興味深いところである。古典的な方法では各ノードに9基のNICを搭載してノード間を直接相互接続するところであろうが、スイッチがスペックシートに記載されていないため一切使用していないのか興味深いところである。Mellanox ConnectX-6では1コントローラーあたり2ポート/PCIe x32(HDR200 x 2ポートで計400 Gbps必要で、PCIe x32で504 Gbps。x16では帯域が不足する)を占有するため9Dで計144レーンが必要となるが、AMD Epyc 2基/ノードではPCIe 168レーンがサポートされるから一応可能である(というか、PCIe Switchを使う方法を除きAMD Epyc以外では実現できない)が、当然ながらNICの方がSwitchよりもポート単価が高額な上にネットワークトポロジーも複雑になることから、本当に各ノードにNICを9基搭載しているのか興味深いところである。

ネットワーク半導体ビジネス

Ubiquiti UniFi USW-Leaf Overview - ServeTheHome

 元ネットワーク系の組込エンジニアだった筆者は、転職して約8年を経た今でもネットワーク系半導体に興味があるのだが、そのマーケットというのは非常に独特に思える。

 ServeTheHomeに米Ubiquiti製UniFi USW-Leafのレビュー記事が掲載されたのだが、その製品に搭載されていたスイッチASICというのがNephos製「Taurus 1.8T」という珍しいものである。ServeTheHomeも「We have heard of a few other vendors building around this chip such as Lite-On but this is the first time we have seen one in the wild.(我々はLite-Onといった他の幾つかのベンダーがこのチップで開発しているというのは聞いたことがあるが、実際の製品で見たのは今回が初めてである)」と書いている。

 このNephosであるが、謎が多い。ServeTheHomeによると台湾MediaTek子会社の低価格スイッチチップベンダーとあるが、About Usには投資を受けて2016年にMediaTekから独立した旨が記載されているほか、Conract Usを見ると米Californiaや台湾Hsinchu(新竹)より上に中国Hefei(合肥)が記載されており、中文ページでも台湾で見られる繁体字ではなく中国で見られる簡体字で記載されていることから、実質的には中国の会社と見られる。

 中国企業の場合、政府の投資や独自の経済圏もあるため分からないが、一般的にはネットワーク系半導体ビジネスというのはシビアで生き残るベンダーは片手で数えられる程度でしかない。
 インターネットとクラウド全盛の現在においてネットワーク用半導体は必須のように思われ、実際、これまでも常に新規参入のベンチャーが登場してきたのだが、Wikipediaに「List of defunct Network Processor Companies(倒産したネットワークプロセッサーベンダーのリスト)」なんてものが存在するぐらいに倒産・買収による退場の多いマーケットである。

 データセンタークラスのスイッチであればBroadcom・Mellanox(NVIDIA)で、Intelに買収されたBarefoot Networksもどうなるか分からない。その少し下のクラスにMarvell Technologyがくるが、MarvellはCaviumの買収を通じてXpliantを取得しており同社のPrestera CXシリーズがここに食い込んでくる可能性はある(ただしXpliant製品ラインは終息するらしい)。これら計4社にCiscoやJuniperといったネットワーク機器ベンダーが独自開発したASICや、Intel CPUを使ったソフトウェアベースのスイッチを加えたスイッチ群でデータセンターのネットワークは構成されている。
 データセンターほどのパフォーマンス(40GbE~400GbE)が必要とされないマーケット、例えば消費者向け(~10GbE)ではBroadcomやMarvellに加えRealtekあるいはVitesseを買収したMicrosemi/MicroChip製スイッチも見られることだろうが、そもそも一般家庭ではWi-Fiが中心なうえブロードバンドルーターのSoC(Broadcom・Qualcomm・MediaTek製)にはスイッチが内蔵されていることも多く、独立したスイッチASICを見かける機会は少ない。

 逆に言えば、データセンターを構築するには米国企業からAISCやプロセッサーを購入する必要があり、そのため中国ではHuawei/HiSiliconなどがサーバー用CPUを開発したりしている。Nephosは一応は独立企業ということだが、恐らく間接的には中国政府が関係しているのではと想像する。


今週の興味深かった話題(2020年第07週)

2020-02-16 | 興味深かった話題

BackBlazeの統計2019年度版

Backblaze Hard Drive Stats for 2019 - BackBlaze

 データセンターでのHDD故障状況を公表しているBackBlazeの統計資料の最新版が公開された。

 BackBlazeはDropBoxのようなオンラインストレージ/バックアップを生業としている企業でストレージの区分でいうコールドストレージが多く、オンラインやニアラインのホット/ウォームストレージの比率は大きくないと思われ、そのような偏ったワークロードのため参考程度に留めるべきである。例えば、もし、いわゆる「倉庫」用途でNASなどを運用するのであればHDDを購入する際の参考になるかもしれないが、メインPCを組む際や個人事業主が自社サーバーを構築する際の参考になるかどうかは疑わしい。

 BackBlazeの特徴としてエンタープライス/データセンター向けに交じってデスクトップ向けなど様々な別様とのHDDが含まれている点で、(特にHDDベンダーなど)一部では不評である。
 今回の場合、マイナビが指摘する通り東芝が比較的、良好な成績を収めたようであるがエンタープライズ向け(旧 富士通系)MG07シリーズはともかく(旧HGST系)MD04ABA400Vはコンシューマー向け監視カメラ用のため用途として妥当でない可能性がある。同じことはSeagateでも同様で、「DM」のつく型番はデスクトップ用モデルである。
 もっとも、幸か不幸か用途の違いと統計データの結果には大きな乖離が見られず、HGST・東芝は全モデルで良好・Seagateは全モデルで1.0~1.5%以上の故障率である。ちなみに、批判を受けたBackBlazeは過去にコンシューマー向けとエンタープライズ向けで統計的に差異があるか検証している

 個人的に気になるのはWestern Digitalの8TB以上のモデルがリストに無い点である。
 Western Digitalの8TB以上のモデルは旧HGST(Thailand工場)製であるが、HGSTブランドは廃止されている。エンタープライズモデルでは例えばWD Ultrastarなど旧HGST製品ブランドが継承されているが、コンシューマーモデルではWD RedやWD Purpleなどにも旧HGST製HDDが採用されており見分けが難しくなってきている。
 個人的には旧HGST製でWD RedブランドのWD80EFAX等の統計データが見たいのであるが、残念ながら見当たらない。それらが今後BackBlaze統計でどのように掲載されるのか興味があるところである(まさかHGSTの10-12TBモデルに実はWD製品が含まれている…ということは無いと思うが…)。

Cray Slingshot

Inside Rosetta: The Engine Behind Cray’s Slingshot Exascale-Era Interconnect - WikiChip Fuse

 本Blogでも以前取り上げたCray Slingshotだが、WikiChipがHot InterconnectでのCrayの発表内容を報じている(もっとも、Hot Interconnect 26は昨年8月のイベントだったので2月になって記事になった理由はよく分からないのであるが…)。

 記事中ではEthernetの問題点が挙げられているが、記事中の「Ethernet」はLayer 1~2の本来の意味でのEthernetと、一般的にEthernetと一緒に使われるTCP/IPを含んだプロトコルスタックとが、混在して同列に扱われているのではと思われ注意が必要である。これは技術的には誤りだが一般的にEthernetの上位層でTCP/IPが使われる以上は致し方ないと言える。
 というのも、EthernetというかTCP/IPの利点は多様な用途に対応した高い柔軟性であるが、欠点として分厚いソフトウェア(≒CPUで実行される)で実装されており、遅延が非常に大きくかつヘッダーが長大になっている点が挙げられる。~Layer 4のTCP/IPまで含めたEthernetが速い/遅いという議論とハードウェア実装のLayer 1~2が速い/遅いという議論は別に議論されるべきだと思われる。
 実際、Cray HPC EthernetはCrayプロプライエタリーで詳細不明であるものの、Layer 1~2ではEthernetとの互換性を残したままInfiniBand相当の性能を達成しており、さらにコモディティの規格でもEthernetの上位層をInfiniBandに置き換えたRCoEのような規格が存在しているわけでLayer 1~2に限定してEthernetが遅いかどうかは別の話であろう。

 記事中で最も興味深いのはEthernetにおけるショートフレームの制限撤廃の部分、特にLayer 2ヘッダー除去の部分だろう。「Ethernetと互換性がある」と聞いて、個人的にはLayer 1~2はEthernet互換だと思い込んでいたため驚きであった。
 Ethernetでは同一ブロードキャストドメイン内であればMACアドレスでデータを転送・そうでなければIP+ルーターでデータを転送するが、DragonflyのSlingshotの場合は最大でルーターが三段構成(最大5ホップ)・最大36,864ノードだから、TCP/IPでのMACアドレス+IPアドレスの組み合わせによる解決は非効率だし、独自にフラットなアドレスを採用したのではと推測する。もし、MAC層を無視していいのであればEthernetヘッダー18 Byteは除去できるが、最小フレームサイズが48 Byte(Ethernetの最小ペイロード)ではなく40 Byteというのはよく分からない(ちなみにプリアンブルの除去については、そもそも100BASE-TX以降では互換性目的以外で使われていないから妥当と言える)。
 それでは、なぜ個人的に驚きだったかと言えば、Ethernetヘッダー無し・最小フレーム40 ByteとなるとコモディティのEthernetデバイス(例:Switch ASIC)では非互換となる可能性が高いためである。Cray RosettaはBroadcomとの共同開発とされており、時期・スペックからしてBroadcom Tomahawk IIIと酷似しているが、Tomahawk IIIがそのまま40 Byteフレームを扱えるかは疑わしい。恐らくはファームウェアレベルでかなりカスタマイズされているのではと推測する。

WindowsはCloud HPCに適しているか?

 これはニュースではなく身近で議論にあった話題である。
 とある人々がWindows HPCの月例アップデートに問題を抱えているという話題があり、その件に関して知人と議論したのだが、元も子もない結論になった、という話。

 私はインフラストラクチャーのセットアップあるいはハードウェアやサポートのコストを考慮した場合に、HPCをクラウドに持って行くのはアリだと思っているが、Windowsだけはナシだと考えている。以下に理由を述べる:

1. ライセンスの結びつき
 OSにライセンスが必要になる場合があることは理解できるが、Windowsのライセンスはハードウェアとの結び付きが強いため、クラウドでの利用にはイマイチ適さないと考える。
 クラウドの魅力のひとつはマシンの破棄・再構築が容易な点である。既存の仮想マシンに不都合がでたら破棄して容易に新規で仮想マシンを立ち上げることができる。これはアップデート/パッチにもいえ、長期間に渡って放置してアップデートの適用に不都合を感じたら既存の仮想マシンイメージを破棄して、ベンダーが提供する最新版のイメージを使って新規に仮想マシンを立ち上げればいい。
 それがWindows HPCで可能か?というと恐らくライセンス違反を避けるためには仮想マシンイメージを保持し続ける必要があり、これではクラウドの魅力が半減である。

2. OSのフットプリント
 Windowsを利用していると月例パッチのサイズが500 MB~1 GBになることがある。その理由は様々で、Microsoftが月例パッチをかつてのService Packのような累積的更新として提供していることも理由のひとつであろう。
 しかし、そもそもの問題はOSのフットプリントが大き過ぎる点にある。例えばLinuxならディス取っビューしょんにもよるが比較的フットプリントが巨大なCentOSやUbuntuでも初期インストールなら8 GB、Debianでパッケージを取捨選択してインストールすれば4 GB以下に収めることも難しくない。これに対しWindowsは初期インストールで20 GB程度も消費する。もしOSのフットプリントが5倍だとしたらパッチのサイズが5倍になっても何の不思議もない。

3. コンテナー
 Crayなどの最新のドキュメントを見ると解るが、Docker/Kubernetesを使ったコンテナー化はHPCにも押し寄せている。実はこれは理解し易い。
 HPCの場合、小規模構成のHPCでアプリケーションの開発を行い、それを大規模構成のHPCで実行するケースが少なくない。また、HPCはシステム全体を1アプリケーションで利用することは少なく、複数の利用者で分割して使用する。言い方を換えると今週は1000ノード・来週は2000ノードなどというケースもあり得る。コンテナー化によって開発環境・本番環境など環境の違いを抽象化できるし、DockerfileやKubernetes YAMLで作成されるのでイメージを最新に更新することも容易である。

 つまり、クラウドでHPCを利用する場合、(1) 最新のイメージを使ってコンテナーホストを必要なノード数だけ起動する (2) DockerfileやKubernetes YAMLを使いコンテナーをデプロイしてアプリケーションを実行する。(1)(2) の通り最新のイメージを使うためパッチを適用する必要はなく、アプリケーションの実行が終了次第、ホストとコンテナーは破棄していい。
 もっとも、このワークフローを実装するためにはLinuxの使用/Windowsの不使用が前提となるので、元も子もない話である。

 ちなみに、本業=セキュリティエンジニアの立場から言わせてもらえば、最新イメージを使っていてもセキュリティースキャンは企業のコンプライアンス/ポリシー上必要であろう。
 ただし、Infrastracture as Code的に、最新イメージをコードでデプロイし(≒最新イメージなので修正必要な個所はあっても少ないはず)、コードでAPIをCallしてセキュリティースキャンを実行すれば良いので、一度コードを書けば後は手間も時間も少なくて済むはずである。


今週の興味深かった話題(2020年第06週)

2020-02-08 | 興味深かった話題

VMwareのライセンス形態が変更に

Licenseageddon Rages as VMware Overhauls Per-Socket Licensing - ServeTheHome

 日本のニュースではほとんど話題とならなかったが、英語圏のニュースでは一時期どこもこのニュースで持ち切りだった。

 CPUの多コア化に合わせてVMwareがライセンス形態を変更するというもので、ソケットあたり32コア以上であれば2 CPUとしてカウントするというもの。つまりこれまで64コア1CPUと32コア1CPUのライセンス料は同じだったが、これからは64コア1CPUのライセンス料は32コア2CPUと同額になるということで「AMD Epycに打撃」という趣旨の記事が多く見られた。

 AMD Epycが不利なのは、例えば64コアサーバーでVMwareを使う場合、これまでのライセンス形態ではAMD "Rome"世代Epycでは64コアCPU1ソケットに対しIntel "Cascade Lake"世代Xeonでは32コアCPU2ソケットが必要となりライセンス料削減でアドバンテージがあったところ、新しいライセンス形態では、いずれの構成でも2CPU分のライセンスが必要となりAMDのアドバンテージが無くなる。

 もっとも、個人的には現行世代ではAMD EpycについてもIntel Xeonについても影響は限定的と見る。
 まず、そもそもAMD Zen 2アーキテクチャーは高性能であることが挙げられる。AMD EpycとIntel Xeonとで同等のパフォーマンスを得るには同等のコア数になりライセンス料も同額になる。Oracle SPARCのように性能が貧弱なコアを超多コア/超多スレッドで高性能を達成しているような場合では問題となるが、AMD Epycの場合はこれまで幾つかあったアドバンテージのうちのひとつが失われるだけでディスアドバンテージとなるわけではない。
 次に、AMD EpycとIntel Xeonのフットプリントの違いは依然として大きいことが挙げられる。AMD Epyc "Rome"の場合は64コアまで1ソケットで実現できるが、Intel Xeon "Cascade Lake"の場合は比較的安価なXeon Silverは16コアまでしかなく、24コアまでなら高価なXeon Gold・56コアまでならさらに高価なXeon Platinumが必要となる。つまりIntelで16コア以上で構成する時点で必然的に2ソケット以上になる可能性が高い(例:24コアの場合Xeon Silver 4214 $ 704.00 x 2CPU = $ 1408.00に対しXeon Gold 6252 $ 3,662.00。ちなみにEpycは$ 1,350.00~1,783.00)。データセンターの単位面積あたりのコストは高価であることが知られているが、2ソケットや4ソケットになるとサーバーの体積も増える。
 VMwareのライセンス料だけで見るとAMDのアドバンテージは弱くなったように見えるが、全体で見ればやはりAMDの方が圧倒的に安い。

 もっとも、Zen 4以降のプロセッサーについては話は変わってくる可能性がある。
 現在のZen 2/Rome世代Epycでは8コアまたは16コア単位でコア数が調整されており、最大64コアである。そのためVMwareの1CPU/2CPU/4CPUの境界である32コア/64コアにピッタリと収まっており、これは恐らく次世代Zen 3/"Milan"世代でも同様である。
 しかし、TSMC N5プロセスを使うZen 4/"Genoa"世代ではコア数が増えるはずで、例えば最大コア数が96コアとか128コアに達する可能性があり、

IntelがNervana NPPを終了しHabana LabsのNPUに一本化

Intel Axes Nervana just two months after the launch - WikiChip Fuse

 IntelがHabana Labsを買収して動向が心配されていたIntel Nervanaシリーズだが、開発が中止されることが決定したらしい。既に出荷中のNNP-I1000については既存顧客への出荷は継続されるとのことだが、恐らく最大の顧客はFacebookなのでそれも当然だろう。

 Hisa Ando氏のサイトによると「Nervanaの従業員はIntelに吸収され,IntelのAIチップの開発を強化する」「と言っていますが,多くのNervana側のエンジニアの履歴書が出回っている」のだそう。

 実態は不明ながら「さもありなん」という印象である。
 Habanaに限らずMovidius・MobilEyeもIntelのDeep Learning用プロセッサーはイスラエルに集中しているのに対しNervanaだけはカリフォルニアにある。もしかするとIntelイスラエル内で統廃合やエンジニアの移動は可能かもしれないが、カリフォルニアのチームには開発すべき製品が無い。

名古屋大がA64FX搭載の富士通PRIMEHPC FX1000を導入

名古屋大学、“富岳型”スパコン「不老」を導入 - PCWatch
Fujitsu A64FX Supercomputer to Be Deployed at Nagoya University This Summer - HPC Wire

 富士通が理研の富岳のために開発したA64FXを搭載するHPC製品はPRMIEHPC FX1000とFX700とがあり、FX1000は富岳と同じTofu-Dインターコネクトを採用するため、恐らく富岳で動作させるアプリケーションの開発も想定しているのではと想像します。

 名古屋大はFX1000 6ラック/2304ノードの「Type I」サブシステムのほか、Intel Xeon + NVIDIA V100 GPUの富士通PRIMERGY CX2570 M5「Type II」サブシステム、48TBの大規模メモリを搭載したHPE SuperdomeFlex「Type III」サブシステム、プライベートクラウド用HPE ProLiant DL560クラスターも導入されるそう。

 運用方法が分からないので何とも言いかねるが、第一印象としては効率が良いのか疑問に感じられる。「Type I」と「Type II」または「Type II」と「Type III」は統合できたのでは。


今週の興味深かった話題(2020年第05週)

2020-02-02 | 興味深かった話題

Intelの10nmプロセスと7nmプロセスの状況

Intel 10nm yield is ahead of expectation 7nm Ponte Vecchio GPU on track - WCCF Tech

 Intelの10nm歩留まりは予想より良好で、7nm世代のPonte Vecchio GPUはスケジュール通りという報道だが、もはや何が何やらというのが率直な感想である。

 これに先立つ別の報道によると、14nm世代のXeonプロセッサーの供給が不足しており、且つそれをクラウドベンダーが確保しているため、DellやHPEの顧客への供給が十分ではないらしく、昨年11月中旬にはIntelが公式に謝罪文までリリースしている。
 14nm製品の供給不足は、10nmプロセスが予定通りに立ち上がらず未だに大半の製品を14nmに留めているためで、2018-19年に14nm製造能力を増強したにも拘わらず供給不足が続いている。このあたりの状況は一部推定も含めてASCII大原氏が説明されているので参照されたい(例えば、これこれこれ)が、本当に10nmが言葉通りの意味で良好ならモバイル向けCore U/Yシリーズ全モデルさらにデスクトップ向けCore Sシリーズの一部を10nmに移行させればよく、「予想より良好」とはどういった「予想」を指すのか理解に苦しむ。

 Ponte Vecchioも何やらおかしい。
 Ponte Vecchioは次世代Xeon "Saphire Rapids"・インターコネクト技術CXL・GPGPU技術OneAPIなどと共にArgonne国立研究所のA21/Aurora HPCへの採用が決まり話題となったが、そのAuroraの稼働予定が2021年なのに、その構成部品のPonte Vecchioが2021年第4四半期登場予定というのは、どういうことなのだろうか?
 例えば、現在HPC Top500で首位となっているOak Ridg国立研究所のSummitの場合2018年6月に稼働を開始しているが、構成部品であるNVIDIA Volta GPUは2017年12月・IBM POWER9 CPUも2017年半ばのリリースで、学会発表されたエンジニアリングサンプルも含めればさらに半年~1年前には出揃っていた。また、日本の富士通/理研の富岳はAuroraと同じ2021年頃稼働の予定でA64FX CPUは2019年5月にリリース・11月には試作機が稼働している。こちらは1年~1.5年も前に出揃っている。そこから周辺ハードウェアやソフトウェア環境などを整備・チューニングするとすれば1年間以上という期間は妥当に思える。
 これらを鑑みると、新アーキテクチャーづくしのAuroraが間に合うようには思えない。Intelは先日、Xeアーキテクチャーで初のdGPU DG1を「ソフトウェア開発者向け」として発表したが、Ponte Vecchioが間に合わないことを前提としての対応ではないかと邪推してしまう。
 ウワサの域を出ない話題としてPonte VecchioはIntel自社FabではなくTSMCでの製造という報道もあるが、現状を鑑みれば「さもありなん」といったところに思える。

Linux Kernel 5.6 にWireGuardがマージされるか?

Linux 5.6 Is Looking Like It Will Be Spectacular With A Long List Of Features - Phoronix

 先週末にLinux Kernel 5.5がリリースされたため、5.6のマージウィンドウが開いている状況であるが、既にPhoronixがリストに纏めてくれている。

 この中で個人的に気になるのがWireGuardのマージである(「必要あるのかコレ?」的な意味で)。

 そもそも、Linuxに限らず多くのOSではLayer1からLayer2のリンク層までがネットワークアダプター・Layer2のMAC層からLayer4までをカーネルが処理し、Layer4とLayer5のインターフェースであるTCPポート/UDPポートでinetd/Systemd(Linux)なりsvchost(Windows)なりスーパーデーモンが動作している。言い換えればLayer2~4まではカーネルの範疇でありLayer5以上はユーザースペースの範疇である。
 その上でVPNであるが、VPNは単一のプロトコルではなく多用なプロトコルを組み合わせてトンネルを構成する。例えばIPSecはLayer3プロトコルだがL2TPなどLayer2トンネルで通信を行うのでカーネルの範疇であるが、これに対しSSL VPNの場合はLayer2のtun/tapからLayer5のSSLトンネルで通信を行う。ここで例えばOpenVPNの場合などはOpenSSLでSSLトンネルを接続するのでカーネルの範疇ではない。一言で「VPN」と言っても様々である。

 そこでWireGuardであるが…実のところ、仕組みを説明しているドキュメントを見あたらなかったのでまだ勉強中であるが、Linux Kernelにマージできる・軽量であることを考えるとLayer2/3あたりの暗号化技術ではと推測する。

 気になるのはArs TechnicaのレビューにWireGuardが使用する暗号スィートのリストがあるが、AESなどSSL/TLSで一般的な暗号化方式には対応していない点である。(ChaCha20 - Poly 1305自体はHTTP/2とTLS1.3では標準のひとつである)
 これは問題である可能性がある。Android端末などのASICを作る側が一般的なSSL/TLS CipherSuiteに対応した暗号化方式をOpenSSLのインターフェース(例えばCryptodev)経由で利用可能にしているからである。例えばここのQualcomm Snapdragon Crypto Engine CoreのドキュメントにはOpenSSLでサポートされる暗号化方式の多くが掲載されているが(page 5~などを参照)Ars Technicaに掲載されているリストには合致しない。
 また、一部の暗号化アルゴリズムはCPUで標準的にサポートされているが、例えばLinux KernelでのArm ISAのサポートを確認してもChaCha20とPoly1305ぐらいしか見当たらない。

 記事中では「In theory, WireGuard could greatly accelerate throughput from wimpy ARM-powered devices(理論上では、WireGuardは貧弱なARMベースのデバイスでスループットを加速できるはずである)」というが、どう加速するのか説明されていない。
 カーネルで処理されるVPN技術がユーザースペースのOpenSSLに依存しないのは至極当然であるが、ハードウェアサポートのあるOpenVPN/OpenSSLとソフトウェア処理のWireGuardでどちらが速いかなど簡単な問題ではない。


今週の興味深かった話題(2020年第03週)

2020-01-18 | 興味深かった話題

LinuxとZFS

Don’t Use ZFS on Linux: Linus Torvalds - It's FOSS

 最初に報じられたのが先週のことなので厳密には今週の話題ではないが、どういうわけかニュースサイトでは今週に入ってから話題となったので取り上げたい。

 率直に私見を言えば、なぜこの発言が取り上げられるのか理解に苦しむ。
 LinusはZFSの機能や性能については一切コメントしておらず、コメントはライセンスに関するものである。ZFSのCDDSライセンスでLinux KernelのGPLv2非互換であるためコードを取り込めない。このコメントはLinux Kernel開発をコーディネートする人物の発言としては妥当なものだ。
 そもそも、ZFSのLinuxでの利用におけるライセンス問題についてはたびたび議論となっており、UbuntuがZFS on Linuxを含めた際もバイナリーパッケージではなくソースコードで配布すべきといった意見も散見された。OracleのOpen Sourceに対する姿勢への批判も含め目新しい話題ではない。

 むしろ個人的に気になるのは、誰も「ZFSではなく、このファイルシステムを使うべき」とは言っていない点である。
 これはそもそもZFSに対抗しうるFile SystemがLinuxで存在していないのが問題であるが、ZFSは(HDFSのような分散ファイルシステムではなく)1台のスタンドアローンのコンピューター向けに設計されたファイルシステムとしては理想に近い機能的に最も優れている。
 英語版Wikipediaにファイルシステムの機能比較が掲載されているが、内容を知らなくとも緑色/赤色の数を数えれば、いかにZFSのサポートする機能の多彩かが解ることだろう。Copy-on-Write・重複排除・ボリュームのオンライン拡張/縮小・Scrubなどのエンタープライズストレージでの使用に適した機能が充実していている。SDxの時代にスケーラビリティーという点では最も適したファイルシステムではなかろうか。ちなみにZFSは高速なファイルシステムではなくチューニングが必要なので、個人で使用すべきかどうかは疑わしい。

 Linuxの世界で比較的ZFSに近い機能をもつのが、ZFSにインスパイヤされて開発されたBtrfsである。上述の英語版Wikipediaでの機能比較でもZFSに匹敵する機能を誇るが、評判は芳しくない。カタログスペックはともかくBtrfsを採用している企業や製品は少なく、Red HatはRHEL 7でサポートを打ち切っているほどで、サポーターが減っていることも問題である。ちなみにRed HatはXFSベースのStratisの開発へ方針を転換している。
 Btrfsについては遅い・安定していないという批判と共に「ZFSもどきを使うぐらいなら本家ZFSを使うべき」という意見も散見される。もしライセンスに気を遣う必要が無い立場で、かつZFS/Btrfsの提供する機能が必要なのであれば、確かにZFSを使ってしまった方が良いかもしれない。

 Linuxで利用可能なZFSの実装としてはFUSEで動作するOpenZFSとカーネル空間で動作するZFS on Linuxが知られているが、Linusがライセンスについて言っているので後者が該当する。
 このZFS on Linuxは米エネルギー省のローレンスリバモア国立研究所(LLNL)が開発を主催しているもので、一概に否定もできないものである。ちなみにZFSはHPCの世界で標準的なLustre分散ファイルシステムのバックエンドにも使用できる(ZFSのほかにext4も選択できる)。LLNLなど米国はLustreの主要ユーザーだから、LLNLがZFS on Linuxを支援するのは当然にも思える。

Google、User-Agentを廃止予定

Google Chrome、ユーザーエージェントを廃止する計画を発表 - マイナビ

 これはセキュリティー的に良いか悪いかは判断が難しい。
 個人のセキュリティー/プライバシーと企業の内部統制・エンタープライズセキュリティーとは、しばしば競合・矛盾を引き起こす。

 端的な言い方をすれば、悪意あるハッカーの挙動をモニターすることは、そのハッカーのプライバシーを侵害していると言えなくもない。もし、自社Webサイトにアクセスするユーザーや自社ネットワークで活動する社員の悪意ある行動を検出・モニターしたければ、日常的にそういった情報を集める必要がある。企業側としては社員のプライバシーを侵害する意図は無いかもしれないが、内部統制では必要な情報である。

 User-AgentはDNSやWebサイトなどにアクセスするユーザーの痕跡を取得する上では貴重な情報だ。
 例えばMan-in-the-Middle(中間者)攻撃などをする場合や、自作の攻撃ツールを使う場合には正常なWebブラウザーであることを偽装する必要があるが、しばしばスペルミスや情報の誤りを含むため、DNSやWebサイトへのアクセスでそのような情報が見つかれば要注意である(参考:SANS, SANS)。

 そんなUser-Agentの削除は、個人ユーザーであればプライバシー問題の解決に役立つが、企業のセキュリティー担当者の情報源を奪うことになり、悪意あるハッカーのプライバシー保護にも役立つことになる。

NanoPi R2S

NanoPi R2S Dual Gigabit Ethernet SBC & Router is Powered by Rockchip RK3328 SoC - CNX Software

 中華Raspberry Piモドキ(〇〇 PiブランドのSBC=Single Board Computer)の一種、FriendlyELEC製Nano Piシリーズで2月末にNano Pi R2Sが出るらしい。
 中国RockChip製RK3328をベースにGigabit Ethernetポートが2基付いた、ルーターなどでの利用を想定したもので、同様の製品としては同じNanoPi系R1・R1SのほかOrange Pi R1Banana Pi R2Banana Pi W2などもある。

 もっとも、私はこの種の装置を改造して自宅ルーターを置き換えることはオススメしない。
 ネットワーク用のチップセットというのは一般人が想像するよりも複雑で、このような汎用のプロセッサーに汎用のLinuxやルーター用OSを組み合わせても速度が期待できないためで、素直にBuffalo WSR-2533DHP2かWSR-2533DHPLあたりを使った方が手間もコストも速度も有利である。
 特に本製品に至ってはそもそもWireless LANのインターフェースがなくUSB経由になるから性能は期待できない。

 それでも本製品が使えそうな分野となるとVPNゲートウェイなどネットワークアプライアンスではないかと思う。Next Gen FirewallやVPMゲートウェイが一般的なところだが、Next Gen FirewallだとpfSenseなどはArm SBC未対応のため選択肢は多くない。

 VPNゲートウェイとして見たとき、R2Sは既存のR1・R1Sよりも優れている。
 中国Allwinner製H3/H5プロセッサーを搭載するNano Pi R1/R1Sの場合、半導体レベルでは非常に強力な暗号エンジンを搭載しているにもかかわらず、ドライバーが存在せずOpenSSLでの暗号化・複合化に使えない(例:OpenSSLで -engine cryptodevオプション)。ドライバーは有志のボランティアによって開発されており、Linux Kernelの次期リリースLinux 5.5でようやく一部ブロック暗号が有効になる。
 その点、RockChip製RK3328の暗号エンジンは、使用できる暗号化スィートこそ限定的ながらRK3288の頃から既にドライバーがLinux Kernelに取り込まれており標準で使用できる。

DRAM価格が上昇中

DRAM価格、2020年第2四半期までに価格上昇の見込み - PC Watch
Market Activity - DRAM eXchange

 私事で恐縮だが、以前から購入を検討していたDDR4 ECC Non-Reg 32 GB 2-Rank DIMMモジュール2個を発注した。今年後半に12C/24TのRyzen 7ベースで小型PC(恐らくMiniITXでDIMM x2スロット)を構築予定で、仮想マシンの運用に用いる予定(構成例:vCPU 2C/4T + 8 GBの仮想マシン6台で48GBが必要)。

 DRAM eXchangeのインデックスを参照頂きたいが、DRAMベンダー各社が生産数を絞った関係で11~12月頃を境に急激にDRAMチップの取引価格が上昇している。価格が下降中だった2019年7月頃の時点でも、日本の対韓国の輸出管理強化の関係で価格が上下していたこともあり、スポット価格と消費者向けのモジュール価格が完全に連動するわけではないが、それでも今年は半ばまで価格上昇が続いたのち高止まりする
 私個人の予想では、今年後半~来年に登場予定のIntel "Saphire Rappids" XeonがDDR5に対応予定のため、大手クラウドベンダーもDRAMベンダー各社もDDR5待ちで、恐らくDDR4メモリーの価格が最安値を記録することはもうなく、そのDDR5のモジュール価格が底値になるまでには時間を要すると予測する。ちなみに、2007年に登場したDDR3メモリーが2011年頃に最安値・2014年に登場したDDR4メモリーが2019年初頭に最安値を記録し、同様ならDDR5も最安値になるには約4~5年を要することになる。

 ちなみにRyzenはECCには対応しているがRegistered DIMMには未対応(ThreadRipperおよびEpycは対応)である。ところがECC対応モジュールはRegisteredが主流のうえ、32GBクラスではメモリーチップが18個(2 Rank)以上となるためRegisteredメモリーモジュールばかりでUnregisteredは選択肢が少ない。
 ついでに、RyzenではRank数で1chあたりに接続できるメモリーモジュール数に制限があるため、2 Rankでは2モジュール接続できない可能性があり、1 Rank 16GBモジュール2個を接続するよりは2 Rank 32GBモジュール1個を接続した方がコスト的にもパフォーマンス的にも優れている(2個接続可能な32GB モジュールが存在するかは不明)


今週の興味深かった話題(2020年第02週)

2020-01-12 | 興味深かった話題

AMD Ryzen 4000 APU

AMD、Zen 2 CPUと改良版Vega GPU採用のモバイル向けRyzen 4000 - PC Watch

 Ryzenは単体CPUとAPUとでCPUコアの世代が1世代開いており、Ryzen 3000シリーズAPUが搭載していたCPUコアはRyzen 2000シリーズ単体CPUと同等のZen+コアである。今回のRyzen 4000シリーズAPUが搭載するのはRyzen 3000シリーズ単体CPUと同等のZen 2コアとなる。

 Ryzen 3000単体CPUではCPUチップレット=CCDとI/Oチップレット=cIODに分割されMix&MatchのMCM構成で製品化されたため、APUでもGPUがチップレット化される可能性もあったはずだが、APUでは引き続きモノリシックな構成が採用されている。

 私が想像するに、現在のAMDのAPU製品はRyzen 3~Athlonの低価格プロセッサーおよびRyzen Embedded組込プロセッサーをカバーすることからコストやフットプリントの小ささを考慮するとMCMにできなかったのではないか。
 半導体はサイズが増えると不良率が増え指数関数的にコストが上昇するため、巨大な半導体を1個作るよりも小さな半導体を複数個MCMで組み合わせた方がコストが安い場合がある。そのため初代Zen世代のEpycでは巨大なダイ1個ではなく小さなダイ4個を組み合わせることでコストを59%に抑えたという。4個に分割することで10%のオーバーヘッドとMCMの工賃を要したにも関わらずである。言い換えれば、オーバーヘッドとMCMの工賃の元が取れない小さな半導体ではモノリシックに作る方が経済的ということになる。
 また、Athlonなどローエンド製品でCPUコア数を4コア以下に派生したいのであれば、CPUコアが8コアも載ったRyzen 3000シリーズ単体CPUのチップレットは不経済だ。

Intel DG1

Intel Xe DG1 ‘Software Development Vehicle’ - VideoCardz
Intel、同社初の単体GPU「DG1」搭載ビデオカードを初披露 - PC Watch

 Intelが久々に投入する単体GPUの最初の製品であるDG1 = Discrete Graphics 1はソフトウェア開発用(Software Development Vehicle)になるのだという。ゲームなどは基本的にDirectXなどからアクセスするからソフトウェア開発用のGPUというのは珍しい。実に不思議な話だ。

 私が想像するに、2021年に稼働予定の米エネルギー省Argonne国立研究所(ANL)のHPC Auroraが控えていることからAPIレベルで互換のあるハードウェアを投入する必要があったのだろう。
 なにせAuroraではXeon "Saphire Rapids" CPUとXe "Ponte Vecchio" GPUをOneAPIから操作するようなので、2007年登場のNVIDIA CUDAや2008年登場のOpenCLとは違い誰も使い方に馴染みが無く、かと言って"Ponte Vecchio"は2021年に登場するIntel 7nmプロセス(WikiChipの記事を参考)で製造されるためHPC本体に先行して開発用に提供するというのも不可能である。
 IntelはXe GPUは単一のアーキテクチャーでモバイルXe-LPからスーパーコンピューターXe-HPCまでカバーすると言っているため、仮にDG1がXe-LP相当だとしてもXe-HPC用の開発が行えるはずである。ちなみにOneAPIの開発環境はBeta版ながら既にダウンロード可能である。

Vyatta改めDANOS

AT&T Finally Opens Up dNOS "DANOS" Network Operating System Code - Phoronix

 今週の話題ではなく昨年10月末の話題であるが、今週になって気が付いたので掲載しておきたい。

 10~15年ほど前の話になるが、VyattaというLinuxベースのソフトウェアルーターが話題になった時期がある。
 2012年にBrocadeが買収して以来、ソースコードがクローズドになったり様々な企業の傘下を転々としてきて、(Brocade→Broadcom→)現在はAT&Tの製品となっているが、DANOSという名称で再度オープンソース化されているらしい。それが昨年10月のことである。

 Linksys製ファームウェア由来のDD-WRTやOpenWrt(いずれも2004年頃~)なども含めれば、Linuxベースの汎用のルーター用OSというのは新しいアイデアではないが、注目を集めるようになったのはAWSなどクラウド環境の普及でネットワークアプライアンスを仮想マシンで利用する機会が増えてからだろう。ちょうど2010~15年頃からOpenFlowやSDN=Software Defined NetworkやNFV=Network Functionality Virtualizationといったソフトウェアで柔軟に管理する仮想化されたネットワーク機器の普及が始まっており、私はVyattaもその流れで注目を集めBrocadeに買収されたものと認識している。

 そのVyattaはBrocadeによる買収に伴いオープンソースからクローズドソースに転換しており、最後のオープンソース版=Vyatta Core Editionからフォークする形でオープンソースのVyOSやクローズドソースだがUbiquiti NetworksのEdgeOSなどが派生しており、もちろんBrocade/AT&Tも開発を継続している。

 個人的に興味深いのはDANOSのオープンソース化が、2013年のVyattaのクローズドソース化ほど話題とならなかったことだろう。
 実際、過去5年間のVyatta/VyOSの注目度の低さはWikipediaの記事の内容の乏しさからも察することができるだろう。派生したVyOSなども開発者不足で開発が滞っており、2013年のフォークから18年までDebian GNU/LinuxベースのOSのコア部分もDebian 6 Stretchが使い回されていたほどである。Debian 6はVyattaのクローズドソース化前の2011年リリースで14年に既にEnd-of-Lifeになっていた(ちなみに現在のLTS 1.2系はDebian 8 JessieベースRolling-releaseの1.3系はDebian 9 Stretchベースで、いずれもサポート継続中である)。
 ソフトウェアルーターとしては、恐らくVyatta/VyOSよりもセキュリティーアプライアンスを兼ねたFreeBSDベースのpfSenseやOPNSenseの方が普及していると思うし、ソフトウェアベースの宿命であるパフォーマンス問題(ハードウェア=ASICベースのルーターと比べパフォーマンスが劣る)を考えれば利用が進まないのも当然かもしれない。

 ちなみに、汎用OSであるLinux Kernelではスケジューラーなどの仕様の問題で20 Gbps以上の達成が難しく遅延が大きいという問題があるが、SDN/NFV風の方法でASICベースのネットワークアプライアンス並の速度を達成する方法は幾つか存在する。

 その方法のひとつがEthernet Frameの転送時にLinux KernelあるいはLinux Kernelのネットワークスタックをバイパスする方法でDPDKやXDPが代表的である。VyattaはBrocade時代のVyatta vRouter 5600(2013年~)でDPDKを実装している。
 また、その他の方法としてはL2/L3スイッチといったデータプレーンをASICに任せ管理部分のみオープンソースソフトウェアを利用する方法がありONIEが代表的である。正確にはONIEはネットワークアプライアンスに搭載されるファームウェア(BIOSのようなもの)のことで、ユーザーが上位の管理OSのインストールすることを可能にしている(言い換えればエンタープライズクラスのASICを搭載したONIE対応ハードウェア以外では使用できない)。こちらの代表例としては先駆者のCumulus LinuxのほかMicrosoftがAzureのために開発したSONiCがあるが、どうやらDANOSにもONIE版があるようである。

「パナソニックの半導体売却のリスク」!?

パナソニックの半導体売却のリスク - Business Journal

 この記事では悪い意味で絶句させられたので掲載しておきたい。
 記事中で最重要なポイントは「工場は設計側から渡された設計情報を蓄積しているので設計が途切れても生産はできる」とした上で、あたかも台湾TSMCや、パナソニックとイスラエルTowerJazzの合弁製造子会社TPSCOが、設計元に無断で製品を勝手に製造できるような論調で書いてある点にある。

 要するに、記事は「台TSMCなどのファウンドリーは、米Appleや米Qualcommや米Broadcomや米AMDや米NVIDIAや米Xilinxや東芝や富士通やソニーの半導体を無断でコピーできる」と言っているように読める。ちなみに一般消費者には馴染みは無いかもしれないがTSMCは世界3位の半導体製造企業で、ファウンドリーとしてはシェア5割を超えている信頼と実績ある大企業である。

 私はTSMCと関わったことはないが、私の知る限りでも半導体の製造の大部分はシステム化されており、マスクの使用や製造数も自動的に管理されている。そうでなければ何百万個という半導体チップの管理は不可能だし、英Arm・米Synopsysといった設計のライセンスを行う企業のビジネスが成り立たない。
 逆にTSMCなどのファウンドリーが他社の設計を無断使用するとバレるし、もし機密保持契約を破って裁判になれば確実に敗訴する。また、そのような企業にファブレス半導体企業(自社工場を持たない半導体企業)が製造を委託するはずもない。
# TSMCの情報漏洩のニュースは同社の製造技術の漏洩ばかりで顧客の設計情報の漏洩などは見当たらない

 また、どうも記事のライターはPSCS製品とTowerJazz製品とを意図的に混同しているように見える。
 パナソニック半導体部門=パナソニックセミコンダクターソリューションズ(PSCS)の台湾Nuvotonへの売却で問題なのはPSCSの保有する知的財産だけで製品はパナソニックのサイトに掲載されているが、兵器という観点でクリティカルな製品があるようには見えない。
 PSCS製品としてはGaN半導体についてもパワー半導体のみであるし、記事中にあるAESAなどは完全にTowerJazz製品の話である。子会社から親会社の機密情報が漏洩するリスクはあるとしても、製造子会社を合弁しているというだけで互いの企業秘密が筒抜けになるとは考えられない。


今週の興味深かった記事(2020年 第01週)

2020-01-05 | 興味深かった話題

 今週は多くの企業がまだ休暇中ということもあり目ぼしいニュースはなかったのだが、2020年に予定されているイベントについて書いてみたい。

AMD Zen 3 / 第4世代 Ryzen/Epyc

 Zen 3については憶測/非公式のレベルで様々なウワサが報じられている。

  • CCXあたりのコア数が4から8になる(公式)
  • SMT2は維持される。SMT4は公式に否定(公式)
  • IPCが平均17%向上(非公式:TechPowerUp

 CCXの8コア化は第1世代Zenの頃から知られていた要改善項目であるが、一方でSMT4は以前も説明した通りシングルスレッド性能を下げるので公式に否定されるのはもっともである。IPCの向上は具体的でないので分からない。

 CCXの8コア化では、メリットとしてキャッシュアクセスの効率化およびInfinity Fabricの負荷低減があるが、デメリットとして最小構成製品の難しさが挙げられる。
 現在の4コア/CCXの構成では同チップレット内・別CCXでのキャッシュアクセス時にInfinity Fabricを経由することになり遅延が問題となる。Infinity Fabricはメモリーの動作速度に同期するためDDR4 3200搭載時で1600 MHzで動作し、これはI/Oを基準とすると高速だがCPUを基準とすると速くない。仮にCPUコアが3200 MHz動作だとすると同CCX内のL3キャッシュアクセスは等速だが、別CCXだと1/2倍速でアクセスすることになる。加えて、Epycのように多コアになるとメモリーアクセスや他CCXへのキャッシュアクセスが頻発しInfinity Fabricが混雑してさらに遅延が悪化する可能性がある。8コア/CCXとすることで同チップレット内でのキャッシュアクセス時にInfinity Fabricを経由する必要がなくなり、キャッシュへのアクセス効率の向上が狙えるほか、CCX間の通信が減りInfinity Fabricへの負荷低減が見込める。
 デメリットとしては最小コアの構成(現在は2コア)でもチップレットのレベルでは8コア載る(もし最小コア構成だと6コア無効化する必要がある)ことだが、これは現在のRyzen 3000シリーズ単体CPU・次世代のRyzen 4000シリーズAPUでも同様の問題があり、恐らくRyzen 4000シリーズの最小構成は4コアとなることだろう。

 17%の性能向上というのは、恐らくIPCの改善ではなくIPCは若干改善 x 動作周波数の向上での総合的な数字だと推測する。
 Zen 3ではTSMC N7+を使用し、EUVを使用することでマルチパターニングの工数が減らせることから不良率の改善が見込まれている。トランジスタ性能の向上に加え、良品が多く採れることから動作周波数の高いプロセッサーも多く採れると考えられる。コンシューマー用で100~200 MHz向上するという予測は妥当に思える。
 IPCの向上については具体性がなく判断が難しい。ただ、TechPowerUp記事中ではFPUの性能が+50%向上とあるのでFPUが強化された結果IPCが増加すると推測する。例えばZen/Zen+/Zen 2にはMUL+ADDの場合は4基のFPUを全て使用できるがFMAの場合は2基しか使用できないという弱点があるが、それが改善されている可能性はある。

 ただ、個人的にはIPC 17%向上というのは否定的に思う。Overclock3DによるとZen 2で導入されたTAGEベースの分岐予測は元はZen 3で導入予定だったものを持った来たのだという。言い換えれば、もしZen 4で導入予定のものをZen 3に持って来られれば性能向上は高くなりそうだが、そうでない場合はZen 2→Zen 3でのジャンプはZen+→Zen 2よりも見劣りするものになるだろう。Zen 4では5 nmプロセスを使うため半導体予算が増えるが、Zen 2→Zen 3ではN7からN7+プロセスへの移行で半導体予算が増えないためZen 4の機能を持って来れるか疑わしい。

LBNL Cray/AMD/NVIDIA Perlmutter・ANL/Intel/Cray Aurora

 Perlmutterは2020年稼働予定・Auroraは2021年稼働予定の米エネルギー省のHPC(スーパーコンピューター)である。

 米エネルギー省Lawrence Berkeley国立研究所/NERSCのPerlmutterはCray ShastaをベースにAMDの特別仕様のEpyc CPUとNVIDIAの次世代Volta("Volta-Next"と表現) GPUで構成されたHPCで、具体的な詳細は発表されていないものの、いずれも現行製品の改良版と想像でき詳細の発表が楽しみである。

 一方、米エネルギー省Argonne国立研究所が導入するA21はCray ShastaをベースにIntel CPU・GPUで構成されたHPCで、現時点では、1ノードあたり2 Sapphire Rapids CPU + 6 Ponte Vecchio GPUで構成であることとCPU・GPUはCXLで接続されOneAPIでコードが書けるということが知られるのみである。
 Hisa Ando氏も指摘しておられるが、初物ばかりなのでリスクは高いと想像できる。稼働予定は来年(2021年)だから今年から構成部品の情報が出てくると思われるが、逆に出てこない場合は遅延するのではと思う。

Sony PlayStation 5・Microsoft Xbox X series

 今年末を目処に登場すると思われ、両者共にAMDのZen 2 CPUとNavi GPUを組み合わせたAPUを採用すると思われるが、MCM構成がどうなるのか興味深いところである。

 私の想像では、AMD Ryzen/Athlon APUではCPUチップレット(CCD)・I/Oチップレット(cIOD)に加えGPUチップレットを組み合わせた3チップのMCM構成になると思うが、ゲームコンソールではメモリー帯域不足のためI/OチップレットをcIODとは共通化できない上、GPUのダイサイズも増やす必要があることから、GPUとI/OのチップレットはNavi 10規模の1チップレットに纏められ、2チップレット構成になるのではと予想している(そもそも、Navi GPUはGPU・メモリーコントローラー・Infinity Fabricを搭載しているのでCCDと組み合わせればAPU化そのものは簡単なはずである)。


今週の興味深かった記事(2019年 第50週)

2019-12-21 | 興味深かった話題

NVIDIA Orin

NVIDIA Details DRIVE AGX Orin: A Herculean Arm Automotive SoC For 2022 - AnandTech

 NVIDIAの自動運転向け車載SoCのロードマップが更新され現行のXavierの後継としてOrinが発表された。いろいろと興味深い点はあるが、まずCPUコアがNVIDIA独自のCarmelからArm純正のHeruclesに変更になるほか、ディープラーニングでINT8の演算性能が30 TOPSから200 TOPSに跳ね上がることに注目したい。

 CPUコアの切り替えについては、過去にもTegra K1で独自コアDenverを採用後にTegra X1でArm純正コアCortex-A57に切り替え、さらにTegra X2で独自コアに戻した経緯があるため、NVIDIAが独自コアを放棄したのかは判らない。ただ、XavierのCarmelコアはCortex-A76コアに比してコアのサイズ(≒半導体コスト)は倍程度ながら性能は同等ということがあったし、またArmはCortex-A76でパフォーマンスを向上させる路線に変更しており、パフォーマンスという点から高いコストをかけて独自コアを作り込む必要性は薄れている。実際、独自CPUコアを開発していたSamsungは今年末で開発を終了するとされている。さらに、ArmはCortex-A76AEやCortex-A65AEで車載向けセーフティ機能(例えばLock Stepは複数コアで同一処理を実行して結果を突合することでソフトエラーを回避する仕組み)を盛り込んでいたりするから、Arm純正コアに切り替えるメリットは少なくない。
# もしArm純正コアが半分の半導体コストだとすると、同じ半導体バジェットで倍のコアを搭載できる
# Xavierで8コア・Orinで12コアだと、仮に同じ製造プロセスでも後者の方が低コストで、さらに
# 余った4コア分の半導体バジェットで他の機能を搭載できる。

 ディープラーニングでのINT8演算性能については、恐らく推論専用の演算ユニットが追加されている。
 Xavierは2018年の発表でOrinは来年以降(※「2022年の自動車に搭載される」とのことなので遅くとも2021年中)の製品だからPC用のGPUでいうと数世代飛ばしていることになるので大きな性能向上には驚かないが、とはいえ66倍という性能向上はGPU以外の仕掛が必要になる。
 過去にもNVIDIAはGPU内蔵のTensorCoreや、独立したアクセラレータDLAなどをXavierに搭載してディープラーニング性能を向上させてきたが、それでも汎用的なGPU+CUDAで処理する方針だったように見える。その結果、Tesla MotorsのFSDようなディープラーニング専用プロセッサー(73.73 TOPS)と比較すると性能で見劣りする結果となってしまった。
 そもそも車載・自動運転では純粋なグラフィックプロセッサーとしてのGPUへの要求性能は低いため、無理に汎用的なGPUで処理する必要性は薄く、むしろ処理内容や要求性能がある程度決まっているなら(例:画像処理・画像認識・センサーフュージョン・進路制御・速度制御など)固定機能のアクセラレーター(例:イメージプロセッサーなど)を充実させた方が効果的だ。Xavierでもディープラーニング専用のDLA(Deep Learning Accelerator)や画像処理用のPVA(Programmable Vision Accelerator)を搭載してきたが、恐らくそちらの比重がOrinではXavierよりも増えることになるだろう。

IntelがHabana Labsを買収

Intel Acquires Habana Labs For $2 Billion - Forbes

 IntelによるHabana買収はEETimesが12月7日に「?」付きで報じていたが、Intelは既にNervanaを持っていることを考えると先が気になるところ。Nervanaの買収は$408Mで、Habanaの買収における$2Bはまさに桁違いである。

 Nervanaの場合、学習用NNP-T1000と推論用NNP-I1000はアーキテクチャが別物で、前者はNervanaの設計ながら後者はIntelの色が濃かった。学習用と推論用のアーキテクチャが同じ必要はないかもしれないが、外から見ていて健全そうには見えない。
 学習と推論とでは、一般に学習の方がデータ精度が高く(FP64 vs INT8)、従って学習データや学習済データのサイズも変わってくる(同じデータ量だと単純に8倍)ため、一般的には推論専用ハードウェアは学習・推論用ハードウェアの機能削減版のような格好をしていることが多い。代わりに、推論は学習と違いリアルタイム性が求められることが多いため多数のプロセッサーを並列に並べたりすることがある。
 Habanaは学習用Goyaと推論用Gaudiとではアーキテクチャは似通っている

 Intelのディープラーニング事業は、データセンター用Nervanaの他に自動運転用MobilEyeとエッジでのビジョンコンピューティング用Movidiusを買収で取得しているが、Habanaも含めNervana(米カリフォルニア)以外はいずれもイスラエルの会社である。こうなるとIntelはニューラルネットワーク処理用のプロセッサーを作る部隊をイスラエルに集中しようとしているようにも思える。データセンターでもエッジでも車載でも推論は必要で、Habana・MobilEye・Movidiusでのアーキテクチャーの統一もありえるのかもしれない。


先週の興味深かった記事(2019年 第49週)

2019-12-21 | 興味深かった話題

理研/富士通「富岳」の性能

Fugaku Remakes Exascale Computing In Its Own Image - Next Platform

 日本の次期フラッグシップHPC「富岳」の性能についてNext Platformが報じている。
 Next Platformは富岳がExa Flopsに達しないと報じているように読めるが、そもそも米エネルギー省のAuroraも含め最初の自称「Exascale」コンピューターはそのパフォーマンスを出す演算精度が曖昧になってきている。
 Peta Flops時代は科学演算で重要とされる倍精度(FP64)演算性能が基準だったが、現在は半導体スケーリングの鈍化に加えFP16やINT8が主流のニューラルプロセッシングの興隆もあって基準が曖昧になってきており、日米とも「Exascale」の定義は「処理性能がFP64で1 Exa Flops以上」というよりは「処理性能が前世代スーパーコンピューターのN倍以上」だったり「FP16性能が1 Exa Flops以上」といったような定義になっている。

 例えばFP64が基準だった「京」などニューラルプロセッシング流行以前のコンピューターではFP64が高速(FP64とFP32の演算性能が等速か1/2倍速程度)に演算できることが求められた。実際、記事中にある通り「京」ではFP64・FP32とも11.3 Peta Flopsだった。それが「富岳」ではFP32はFP64の2倍速・FP16はFP64の4倍速で演算可能となりFP64では400 Peta Flops(「京」の約34倍)ながらFP16で1.6 Exa Flopsを達成している。

 加えて、この「Exa Flops」の基準として用いられるHigh Performance Linpack(HPL)と実アプリケーションの乖離が指摘されており、「富岳」もHPL基準でのExa Flopsを狙っていないとされる。この辺はHisa Ando氏のマイナビの記事「Top500 1位を目指さない「富岳」」が詳しい。

Centaur「CNS」

Centaur Unveils Its New Server-Class x86 Core: CNS - WikiChip Fuse

 先日の記事で背景を説明したが、新しいCNSコアはコード名から2008年に発表されたIsaiah(CNA)の発展型であることが分かる。ただし、途中世代のCNB~CNRと約10年間も内部構成が説明されてこなかったこともありCNSコアの拡張は非常に大きく見える。

  Isaiah / CNA CNS Zen Zen 2
Decode (OPs/cycle) 3 4 4 4
Issue (OPs/cycle) 3 4 6 6
Reorder Buffer 76 ? 192 192 224
ALU (Simple) 2 2 4 4
ALU (Complex) 1 2
FPU / SIMD 2 3 4 4
Branch 1 (shared) 1 (shared) 2 (shared) 2 (shared)
Load 2 2 2 2
Store Address 1 1
Store Data 1 1 1
Load Buffer 16 ? 72 72 72
Store Buffer 16 ? 44 44 48

ちなみにFPUであるが、CNS・Zen 2はAVX-2で256-bitを1 cycle(DP精度で16 FLOPS/cycle)で実行するのに対しZenでは2 cycle(DP精度で8 FLOPS/cycle)であるから、CNSとZenでは演算ユニットの数の違いと実パフォーマンスは逆転することになる。
 まだ詳細が不明な部分はあるとはいえブロック図で見る限りではCNSでは大幅に拡張されRyzen 1000(Zen)シリーズに近いクラスの構成となっているといえ、「Server Class」が謳われることも頷ける。

 ただ、やはり先日も述べた通りCPUコア数(8コア)もNPU性能(20 TOPS)も単体でサーバー用としてはイマイチなのでMCM構成かマルチプロセッサー構成に期待したいところである。もし第一世代ZenのEpycのように4チップのMCMが実現できれば(※仮定)32 コア・80 TOPとなり実用的と思えるのだが。


先々週の興味深かった記事(2019年 第48週)

2019-12-21 | 興味深かった話題

AWSの第二世代「Graviton」

AWS gives Servers a Real Shot in the Arm - Next Platform
AWS EC2 6th Gen Arm Instances are 7x Faster thanks to Graviton 2 - CNX-Software

 初代Gravitonを使ったインスタンスはA1という特殊なインスタンス名だったが、第二世代Gravitonでは-g suffixがついたM6g、R6g、C6gといった普通のインスタンス名になるようだ。これは冒頭のM- R-といったprefixが用途を表し、プロセッサーの違いはsuffixで表していたことを考えれば妥当であろう(例:AMD Epyc搭載インスタンスのsuffixは「-a」である)。

 想像するに、当初AWSはA1で使われた初代Gravitonをインスタンスとして展開する予定が無かったのではないか。最大16コアという規模を鑑みれば、AWSが内部で使うネットワークアプライアンスやストレージアプライアンスあるいはスマートNICとして使うには適当な規模で、例えばENAに競合するMellnox BluefieldやBroadcom Stinglyの構成はGravitonと酷似しているが、サーバーのCPUとして使うには最大16コアでは中途半端過ぎる。

 もっとも、これはAWS/Annapurna Labsの問題というよりはArm純正IPのスケーラビリティーの問題でもある。初代Gravitonで採用されたCortex-A72の時点ではサーバーレベルでのスケーラビリティが考慮されていなかった。これに対しNeoverse N1/Cortex-A76世代ではArmの発表時の資料でも2 core/cluster x 32 clusterをメッシュで接続した64コア構成が具体例に挙がっている通り、インターコネクトも含めてスケーラブルになっており多コアで展開しやすくなった。

 気になるのは記事中にある「Custom Neroverse N1」という表現である。Neoverse N1はArmのサーバープラットフォームのブランドで、CPUコア単体で見ればCortex-A76とほぼ同じ(リビジョン違い)である。Gravitonについては「AWSがCPUを作った!」などと言われることがあるが、実際にはAWS傘下のAnnapurna LabsはCPU等のIPをSoCに構成するベンダーであってCPU開発能力はない。ただし、QualcommがSnapdragonで行っているようにArm設計のコアに若干のカスタマイズを加えている可能性はある。

NEC SX-Auroraロードマップ

NEC Refreshes SX-AURORA Vector Engine, Outlines Roadmap - WikiChip Fuse

 NECがベクトルプロセッサーのロードマップを更新したそうだ。
 別のニュースではドイツ気象庁から受注したという話もあるが、正直なところこのビジネスは上手く行っているのだろうか?

 ロードマップによると2年毎にVE10・VE20・VE30と更新していくようであるが、メモリー帯域の向上・プロセッサーコアの追加・高い動作周波数と書いてあるだけで情報量はほぼ皆無である。GPUもそうだが、メモリー帯域やクロスバーなどの帯域は調整する必要があるとはいえ、乱暴に言えば同一設計のベクトルプロセッサーを並列動作させるのでスケールさせやすい。そのため前述のメモリー帯域の向上・プロセッサーコアの追加・高い動作周波数というのはある意味で当たり前である。

 気になるのはSKUの多さだろう。ある程度は受注生産と思われ、どの程度在庫を抱えているのか分からないためSKU=Stock Keeping Unitという表現が妥当か怪しいがPCIe x16接続のベクトル演算ユニットで6品種・サーバーの構成で5品種が存在するというのは多過ぎないか。例えばベクトル演算ユニット1機のみの1Uサーバーは存在意義が不明だし、ベクトル演算ユニットも液冷・アクティブ空冷・パッシブ空冷の3品種は知っていたが、いつの間にかメモリー帯域が微増したType 10Eなるモデルが追加され6品種に増えたようだ。

Intelが6年前の「Haswell」を復活させる?

Intel Resuscitates 22nm Haswell Pentium Processor - Tom's Hardware

 個人的には非常に疑問だ。
 まず、そもそもの話として7年前のCPUは生産数は減らされ消費者市場に出回っていないが製造は継続されている。組込オプションがあるSKUでは10年間程度の供給保証があるし、また中国などの新興国では低価格製品向けに旧製品が出荷されて続けているためだ。だから仮に7年越しでSKUが復活したとしても、それは製造ラインを再構築したわけではなく既存製品の出荷先の変更やリブランディングでしかない。

 つまり、7年前の製品を復活させることは難しくはない。しかし、現実的かといわれれば疑問だ。
 例えば、2018年初頭に問題となったSpectre/Meltdown脆弱性の影響を受けるプロセッサーを復活させるか?という点である。組込では7年前の製品であることは問題とならないが、消費者向けでは問題となるからである。
 組込は考え方が特殊で、現行モデルで脆弱性が見つかった場合でも多くの場合で将来製造されるロットでも完全に同じ仕様(脆弱性も含めて挙動が同じ)であることが求められる。組込では脆弱性対策も組込製品固有の仕様(ハードウェア・ソフトウェア・使い方・エンドユーザー)に特化して対策され、内部の動作はエンドユーザーから見てブラックボックスなので、製品のロットの違いで仕様/挙動が違う方が問題だ。Meltdown/Spectreを例に取ると、システム内からWebブラウザーでも使わない限りは遠隔でexploitできないから、組込機器ではそもそも対策不要という場合も考えられる。もちろん組込でも長年に渡って製造・出荷される中で構成部材が変更となることはあるが、初期に出荷された製品と後期に出荷された製品とで変更点が制御されている必要がある。
 これ対し、消費者向けの市場では汎用OSなどだからメーカー側が影響を制御できず、Windowsの月例パッチのようにメーカーが対策を施す必要がある。

 もっとも、Comet Lakeなど現行製品を製造している14nm工場を空けるという意味では効果的だ。Intelは11月20日にも14nmプロセス製品の供給不足を謝罪したところで、Intelは10nmプロセスの躓きで14nmプロセス工場を大増設したと言われているが、2年ほど前から14nm製品の供給不足が続いてきた。7年前・22nmプロセスのHaswellであれば製造余力があるはずで復活させることには意義があるかもしれない。


今週の興味深かった記事(2019年 第47週)

2019-11-24 | 興味深かった話題

Centaurが新CPUを発表

Centaur、世界初となるAIコプロセッサ内蔵のハイエンドx86 SoC - PC Watch

 1999年より台湾VIA Technologies傘下となっているCentaur Technologiesからは随分と長い間ロードマップが示されていなかったが、2015年以来4年ぶりに新製品がリリースされるようだ。その内容は既存の「Isaiah II」の改良版にNPU「NCORE」を統合したサーバー用SoCであるらしい。

 これまでCentaurは親会社VIAを通じて「Eden」「Nano」「QuadCore」などの名称で製品をリリースしてきた。Centaur設計のCPUにはCentaurのコード名とVIAのコード名があたりとややこしいが、2008~15年にかけて「Isaiah(Centaur名:CNA/CNB/CNC/CNQ)」「Isaiah II(Centaur名:CNR)」が開発されてきた。
 それが2014年以降はVIAと中国上海市政府とのジョイントヴェンチャーである兆芯 /Zhaoxin/ ブランドでCentaur設計のCPUコアをベースとしたSoCが製品化される一方、Centaurの新設計の話題はまったく聞こえなくなって久しい。そのZhaoxin製品としてはコード名「ZhangJiang」「WuDaoKou」「LuJiaZui」が知られているが、CPUの改良の話はほとんど聞こえないことから、恐らくCPUコアは引き続きIsaiah・Isaiah IIでSoCのコード名と推測できる。

Product familyVIA
Code name
Centaur
Code name
Zhaoxin
Code name
ISATechnologyYear
VIA Nano 1000
VIA Nano 2000
Isaiah CNA N/A x86-64, MMX, SSE, SSE2, SSE3, SSSE3 Fujitsu 65nm 2008
VIA Nano 3000 CNB x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 Fujitsu 65nm 2009
VIA Nano DualCore family
VIA Nano X2
CNC x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 TSMC 40nm 2011
VIA QuadCore family
VIA Nano QuadCore
VIA Eden X2
Zhaoxin ZX-A
Zhaoxin ZX-B
CNQ x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2 TSMC 40nm 2011
VIA QuadCore-E
VIA Eden X4
Isaiah II CNR N/A x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX-2 TSMC 28nm 2015
Zhaoxin ZX-C
KaiXian KX-4000
Kaisheng KH-4000
ZhangJiang TSMC 28nm 2015
Zhaoxin ZX-D
KaiXian KX-5000
Kaisheng KH-20000
WuDaoKou HLMC 28nm,
SMIC 28nm
2017
Zhaoxin ZX-E
KaiXian KX-6000
Kaisheng KH-30000
LuJiaZui TSMC 16nm 2019
? ? CNS   x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX-2, AVX-512 TSMC 16nm  

 今回発表されたCentaur設計のSoCであるが、CPUのコード名が「CNS」SoCのコード名が「CHA」となっている。
 CPUコード名「CNx(xはA〜のアルファベット)」はIsaiah系ファミリーのプレフィックスで(その前世代のSamuel系ファミリーはC5xであった)、Isaiah IIが「CNR」であることから「CNS」はIsaiah IIの改良版であることが分かる。
 CNAはMMX/SSE/SSE2/SSE3/SSSE3に対応、それに加えてCNB/CNCではSSE4.1、CNQではSSE4.2、CNRではさらにAVX/AVX-2が追加されていたが、CNSは遂にAVX-512に対応というのは驚きである。とはいえ、512-bit幅のSIMD演算を効率よく実行するには128-byte幅のLoad・64-byte幅のStoreが必要となる(そして、そんなものを実装しているのはIntelでもSkylake SPおよびIce Lakeぐらいである)ため、Centaurの実装がどのようになっているのかは分らない。詳細が判明するまで待ちたいところである。

 CNSの詳細は不明であるが、CNAのアーキテクチャーの規模は概ねIntel Atom(Goldmont)相当で、ArmでいうとCortex-A72あたりに相当する。これが8コアにNPUということでサーバー用とはいいつつもハイエンドCPU相当とは言い難い。例えばIntelはGoldmontコアを用いたサーバー用SoC Denvertonを開発しているが最大16コアにIntel QuickAssist Technologyアクセラレーターを統合した製品となっている。参考までに、AMDの第一世代Ryzenが8コアでGlobalFoundries 14nmプロセスで212mm^2に対し、CHAはTSMC 16nmプロセスで8コアで195mm2というから、やはりかなり小型≒低コストである。

 IsaiahGoldmontCortex-A72
ALU (Simple) 2 3 2
ALU (Complex) 1 (shared)
2
1
FPU / SIMD 2 2
Branch - - 1
Load 2 2 2
Store Address 1
Store Data 1

 NCOREの詳細も12月に発表されるようで詳細は不明であるが、推論専用で20 TOPSという数字がでてきている。FLOPSではなくOPSであることからINT8での数字と思われるが、この数字はIntel Nervana NPP-I(Spring Hill)の最大96TOPS・AWS Inferentiaの100 TOPSより低く、むしろHuaweiのスマートフォン用Kirin 990の8 TOPSに近いことを考えると、やはりデータセンターでの利用よりエッジでの利用を想定しているように思われる。

 このように考えると、ややターゲットの市場が解り難い製品である。
 ブロック図を見る限りGPUは搭載しておらず、タブレットやタッチパネル付スマートスピーカーとしての用途は想定していないようだし、4chのDDR4 SDRAMを要求するように(つまり、SDRAMチップが最低でも16個程度必要)、コストにシビアな一般家庭は想定していないのではないかと思う(PlayStationのようなゲーム機であればそれ以上のスペックを達成しているが…エッジサーバーに$300も出せるか?という話である)から、家庭用・SOHO用とも考えられず、上述のようにデータセンター向けとしても考え難い。
 第一世代Ryzenが212mm^2の「Zeppelin」ダイ4個のMCMでEpycを構成したように、CHAを4個MCMで集積すると32 CPUコア・80 TOPSとなりデータセンタークラスの性能となるが、この場合もメモリーチャンネル数が総計16chとなるので(性能が落ちることを承知で使わないという選択肢はあるが)、やはり使い難そうに思う。


最近の興味深かった記事(2019年 第44-46週)

2019-11-17 | 興味深かった話題

※筆者体調不良・出張の影響で、2019年44-46週合併号とさせて頂きます。御容赦ください。

Samsungが独自CPUコア開発を終了へ

Samsung is shutting down its custom CPU core department, will use standard ARM cores - GSMArena

 元AMDで所謂「猫系ファミリー」省電力CPUコアの開発に携わっていたチームを取得し、MongooseファミリーArm CPUコアを開発・同社製Exynos SoCに搭載してきたSamsungであるが、独自CPU開発を終了し、QualcommのようなArm純正コアを流用する形に移行するらしい。

 Armは、純正コアはCortex-A75あたりまでは相対的に省電力・低コストの路線を維持し、超高性能コアはAppleやSamsungの独自開発するCPUコアが担ってきた。そのため、Samsung Exynosの場合、Galaxy S10などに搭載されるExynos 9820では"Mongoose 4"ことExynos M4 2コア(Super)・Cortex-A75 2コア(Big)・Cortex-A55 2コア(Little)で構成されている。
 ところが、ここへきてArmが方針を転換し、Cortex-A76以降は拡張する路線に転換してきている。このあたりはPC Watch後藤氏の解説に詳しい。ここで最初に煽りを受けたのは米テキサス州オースティンのSamsungのチームで、年内に独自CPUコア開発を終了するらしい。恐らくMongoose 5・Cortex-A76あたりまでは差別化ができるが、Armの次々世代"Matterhorn"までに差別化が困難になる。
 現在、Armからアーキテクチャライセンスを取得して独自コアを開発しているのはMarvell(旧Cavium)・Apple・Ampare・Huawei・富士通などだが、国策が関わるHuawei・独自の垂直統合路線が目立つAppleはともかく、性能による差別化が困難なAmpareも撤退する可能性があると想像する。

 そもそも、実際にQualcommが行っている通り、Arm純正CPUを使ってもチューニングや周辺ロジックの作り込み(Qualcommの場合はAdreno GPU・Hexagon DSP・Spectre ISPなど)でSoCとしての高性能・差別化は可能なので、コストに見合うかは怪しい。

MarvellのArm CPUコアロードマップ

Marvell Lays Out ARM Server Roadmap - WikiChip Fuse

 意外と言っては失礼かもしれないが、Marvelが旧Caviumから取得したサーバー用Arm CPU開発へのコミットを発表したらしい。

 調べてみて頂けると解るが、Marvellの本業はEthernetアダプターやEthernetスイッチチップといったネットワーク周辺の半導体製品群で、あまりCPUに熱心だったわけではない。ネットワーク関連組込チップとしてCPUを手掛けるのは初めてではなくAndroid以前のWindows Pocketの時代にはArmv5EJ互換(というかIntel XScale互換)のFeroceonやArmv7-A互換のSheevaを手掛けている(IntelからXScale部門を買収したのも同社である)が、差別化が困難になった途端に止めてしまった。また、現世代Cavium Thunder X2ファミリーは前世代Thuder Xとは直接関係がなく、Broadcomが開発中だった"Vulcan"を買収したもので、開発を引き継げているか不安がある。

 しかし、今回の発表によるとThunder X3 "Triton"でNEONユニットを2倍(2 x 128-bit→4 x 128-bit)に・Thunder X3またはThunder X4でSVEを導入し、各世代毎に約2倍の性能向上を達成するらしい。

 個人的にはこの説明には懐疑的である。同一アーキテクチャーに基づくコアの性能を2倍にするのは容易ではなく、新アーキテクチャーの開発には経験的に4年ほどの期間が必要となる。恐らくは世代毎にコアの性能を+10~20%ほど向上させつつ1.6~1.8倍ほどコア数を増やしたりしてお茶を濁すのではと想像している。
 そうすると、記事にもあるが現行のThuder X2では16C/64Tから32C/128TでAMD Epycの最大64C/128Tに対して分が悪く、またArm純正コアでもいいのではという議論になりかねない。

 ところで、クラウド全盛の時代ではSoftware Defined X(SDx)と呼ばれるコードで再定義可能なインフラストラクチャーが重視されている。すると、ASICだけでなくASIC並の速度を実現しつつコードが走るCPUを統合したSoCが必要になってくる。恐らくMarvellもそのことは認識しており、Cavium買収で取得したThunder Xファミリーの必要性は認識していることだろう。ただ、その実現に独自開発Arm CPUコアが必須かは根拠が怪しく、むしろ、コストにシビアなMarvellの経営陣であればArm純正コアで置き換えてしまう可能性が高そうに思える。

Crayが富士通と提携、A64FXベースHPCシステムを販売へ

Cray, Fujitsu Both Bringing Fujitsu A64FX-based Supercomputers to Market in 2020 - HPCWire

 A64FXは富士通が理研と共同開発中のフラッグシップスーパーコンピューター「富岳」のために開発したArmv8-A互換CPUであるが、このA64FXをベースとしたHPCシステムをCrayが販売するようだ。

 CrayはMarvell Thunder X2ベースのHPCも販売しているが、A64FXとの大きな違いは、Thunder X2は汎用的なCPUでベクトル演算をPCIe接続のGPUにオフロードする設計に対し、A64FXは512-bit~2048-bit(論理ベクター長。物理実装は512-bit)のベクトル演算拡張SVEをCPUに実装している点にある。この特徴はIntelがXeon Phiを止めた現在では貴重に思える。
 その他のA64FXの特徴として、HBM2メモリーやTofu-Dインターコネクトなども挙げられるが、これらは長所(256GB/sの広帯域・低遅延)だけでなく短所(容量が僅か8GB・独自仕様でほかに選択肢が無い)でもあるので差別化要因と呼べるかは怪しい。むしろ、それらにロジックを割かれているせいかPCIeインターフェースは僅か16レーンに留まり拡張の幅が限定されている(Thunder X2は56レーン)。

 個人的には、Cray・富士通が狙っているのはA64FXの次世代で、より汎用的な(例:PCIe接続でCray Slingshotインターコネクトを使用)構成を採用する布石ではないかと想像する。