富士通、富岳の技術が活きる“19.4PFLOPS”のスパコンをJAXAに納入（中村 真司2020年4月23日）
https://pc.watch.impress.co.jp/docs/news/1249039.html

『　富士通株式会社は22日、を国立研究開発法人宇宙航空研究開発機構(JAXA)より、スーパーコンピュータ「FUJITSU Supercomputer PRIMEHPC FX1000」を受注したことを発表した。稼働は10月を予定。

　JAXAでは、航空機やロケットなどの研究における流体力学や構造力学などの数値シミュレーション、衛星が収集した地球観測データを研究者や一般利用者向けに加工したり、ディープラーニングの計算に活用したりするなどの目的で、スーパーコンピュータを利用しており、3,240ノードで構成される富士通のPRIMEHPC FX100などを使用している。

　今回JAXAは、理化学研究所が共同開発しているスーパーコンピュータ「富岳」の技術を活用したPRIMEHPC FX1000を5,760ノード導入し、倍精度(64bit)での理論演算性能で現行システムの約5.5倍となる19.4PFLOPSを実現する見込み。

FX1000は、Armアーキテクチャを採用するA64FXプロセッサを搭載。導入されるシステムのノートあたりの性能は3.3792TFLOPS、メモリは32GB。システムはTofuインターコネクトDで接続される。』
『また、大容量メモリやGPUを搭載し、さまざまな計算に対応可能な汎用システムとして、FUJITSU Server PRIMERGYシリーズを465ノード導入するほか、約10PB(ペタバイト)の高速アクセス記憶装置を含んだ、50PBの大容量ファイルシステムが構築される。』

富士通、Armを採用した“ポスト京”スパコンの製造開始（佐藤 岳大2019年4月15日）
https://pc.watch.impress.co.jp/docs/news/1180127.html

『富士通開発のCPU「A64FX」を搭載し、Armアーキテクチャにより、幅広いソフトウェアに対応する汎用性を持ち、超並列、超低消費電力、メインフレームクラスの高い信頼性などを実現するとしている。

　A64FXは、Armv8.2-A SVE命令セットアーキテクチャに基づいたCPUで、計算ノードは48コア+2アシスタントコア、IO兼計算ノードは48コア+4アシスタントコアという構成。2.7TFLOPS以上の倍精度演算性能を謳う。メモリ容量はHBM2 32GB(4スタック)、バンド幅は1,024GB/sで、インターコネクトには「TofuインターコネクトD」を採用する。』
『富士通では、ポスト京のハードウェア開発/製造、ソフトウェア開発において、オープンソースコミュニティと連携し、Armエコシステムの推進、オープンソースソフトウェアの活用、ポスト京で創出された成果の展開などを進めるとしているほか、ポスト京の開発を通じて培った技術を活かし、商用スーパーコンピュータの製品化を行ない、「FUJITSU Supercomputer PRIMEHPC FX100」の後継機として、2019年度下期にグローバルで販売開始を予定しており、導入しやすいエントリーモデルの開発、他ベンダーへの供給なども検討するとしている。』
『PRIMEHPC FX100の後継機では、1ラックあたり384ノードを収容し、ノードあたりA64FXを1基搭載。OSはLinuxで、HPCミドルウェアは「FUJITSU Software Technical Computing Suite」の後継ソフトが採用される見込み。』

よくある質問 – 筑波大学 計算科学研究センター　Center for Computational Sciences
https://www.ccs.tsukuba.ac.jp/pr/ques/
『Q　ノードとはなんですか。
A　「ノード」は「台」とほぼ同じ意味です。2560ノードは、コンピュータが2560台あると考えてください。』

用語集
http://www.nsc.riken.jp/project/yougoshu.html

　※　「５７６０ノードの納入」ってことは、コア数にすると、「４８×５７６０＝２７６４８０」コア…、ということだぞ…。これを全部稼働させて、「並列計算」していくわけだ…。凄まじい話しだ…。 これが、「スパコンの世界」だ…。ちなみに、オレのシステムは「４コア＋４HT（仮想コア含めて、８コア）」だから、単純にコア数の計算だけでも２７６４８０÷８＝３４５６０倍だ…。目が眩んでくるな…。
　しかも、「能力が足りなければ」、さらに「発注して」「ノードを増大」すればいい…（収めるスペースの問題は、あるが…）。リース料金も、「何億／月」「何十億／月」という世界なんだろう…。
　ただ、こういう「電子計算機」は、どこまで行っても「発熱」と「電力供給」の問題がつきまとう…。とくに、「電力供給が途絶えた場合」には、どんな巨大なシステムであっても「巨大なガラクタの固まり」と化す…。阪神淡路や３１１、熊本大地震、千曲川の氾濫による水害、台風襲来による送電鉄塔の倒壊による停電…の例が、そういうことをまざまざと示している…。
　それと、ＡＲＭのアーキテクチャへの乗り換えからは、そういう「消費電力」と「パフォーマンス」のバランスの問題とか、商用展開にあたっての「縛り」の問題なんかが透けて見えるな…。「オープンソース」への舵切りとかからも、そういう方向性が見てとれる…。