- The Art of HPCは、TACCのVictor Eijkhoutが作成した高性能コンピューティングの教材シリーズで、科学コンピューティングの基礎から並列プログラミング、開発ツールまでを一つの流れとしてまとめている
- 第1巻は、コンピューターアーキテクチャ、算術、線形代数、ODE/PDEが大規模計算でどのように噛み合うかを扱う科学コンピューティングの背景書
- 第2巻はMPIとOpenMPを中心に並列プログラミングを説明し、PETSc、Kokkos、Sycl、Co-array Fortranも短く含む
- 第3巻は科学・工学プログラミングで使われるC++17とFortran2008を扱い、入門者とCプログラマーのどちらも対象として読める
- 第4巻はコンパイラ、ビルドシステム、ソースコード管理など、実際のHPC作業に必要な開発ワークフローのツールを紹介する
The Art of HPC 教材構成
- The Art of HPCは、TACCのVictor Eijkhoutが作成した高性能コンピューティングの教材シリーズ
- シリーズは、科学コンピューティングの背景、並列プログラミング、科学プログラミング言語、HPC開発エコシステムを巻ごとに分けて扱う
巻ごとの範囲
-
Volume 1: The Science of Computing
- 科学コンピューティングを理解するために必要な一般的な背景知識を扱う
- コンピューターアーキテクチャ、並列コンピューターアーキテクチャ、コンピューター算術、線形代数、ODE/PDEを含む
- 各要素が大規模計算でどのように組み合わさるかを説明し、Volume 2とともにHPCの「何を／なぜ」と「どのように」を成す構成
-
Volume 2: Parallel Programming for Science and Engineering
- 科学コンピューティングで重要な並列プログラミングを扱う巻
- 現代版のMPIとOpenMPを中心に紹介する
- PETSc、Kokkos、Sycl、Co-array Fortranに関する短いセクションも含む
- MPIとOpenMPはC、Fortran、C++で扱い、MPIはPythonも含む
-
Volume 3: Introduction to Scientific Programming
- 科学・工学プログラミングでよく使われるC/C++とFortranを背景に、現代的なC++17とFortran2008を教える
- CよりもC++17を好むアプローチを取る
- ゼロから学ぶ科学プログラミング入門書としても、Cプログラマー向けのC++学習書としても読める
- 複数の長いプログラミングプロジェクトを含む
-
Volume 4: HPC Carpentry
- 科学コンピューティングのエコシステムが、プログラミング言語と並列プログラミングシステムだけで構成されるわけではない点に焦点を当てる
- コンパイラ、ビルドシステム、ソースコード管理など、科学ワークフローに必要な要素を紹介する
- すべてを網羅する参考書というより、科学ワークフローに合わせた入門集に近い
1件のコメント
Hacker Newsのコメント
この話題のハードウェア／データセンター面も同じくらい興味深い
以前AWSでソフトウェア／サービス側の仕事をしていたが、ときどきデータセンターチームの発表をこっそり聞きに行っていた
いちばん大きな気づきは、データセンターで計算能力を高めることは、実際のコンピューティングよりも熱力学の問題に近いという点だった。ノード密度が高くなりすぎて、電力を入れて熱を取り出し、さらに各種の冗長化まで加えることが極めて難しい。非効率を見つけても、ソフトウェア更新のように直せるわけでもない
これは10年ほど前の話なので、今は変わっている部分もあるだろうが、オンライン書店として始まったAmazonが熱力学問題の解決の最前線にいるという点は驚きだ
Cray-2ではさらに極端な方式を採り、高密度に積み重ねた回路基板をFluorinert™という特殊な非導電性液体に浸す冷却構造を使っていた: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
水は熱容量が非常に大きく、最適温度まで大量に素早く冷却できる。液体冷却できない部品の熱を逃がすためにファンや空調は依然として必要だろうが、CPUやGPU／演算エンジンのような大電力消費部品では、膨大な熱を素早く直接取り除ける
漏水の複雑さとリスクが問題ではあるだろうが、Amazon規模のデータセンターなら、それほど大きな懸念ではないように思える
最先端の冷却技術がどのようなものなのか気になる
HPC がハードウェアからかなり抽象化されて見えることがあるのは興味深い
本では SPMD プログラミング、アルゴリズムとデータ構造、タスク並列性、同期などが多く扱われているようだが、スーパーコンピュータのメモリサブシステム、CXL のような高帯域幅インターコネクト、GPU アーキテクチャといったコンピュータアーキテクチャの詳細は少ないように見える
抽象化とツールがすでに十分に優れていて、こうした詳細を気にしなくてよいのか、それとも HPC の実務者は性能を引き出すためにブラックボックスのノブをたくさんいじっているのかも気になる
一般原則として、最適なスケーラビリティのためには、ソフトウェアのトポロジーをハードウェアのトポロジーにできるだけ合わせる必要がある。効率的な HPC ソフトウェアはハードウェア特性の影響を強く受ける
新しい HPC ハードウェア向けのコードを書くときに、プログラミング文書ではなくシステムのハードウェアとアーキテクチャの文書を求めると、人々はいつも驚いていた。ハードウェア設計を理解すると、その上でソフトウェアをどう設計すべきかが第一原理から明確になった。プログラミング文書には、開発者に実際より簡単に見せるための半分だけの真実がかなり多かった
一部の HPC プラットフォームは「書きやすい」と見せるために、最大性能を出すには開発者が何をすべきかを継続的に誤って伝えており、マーケティングが示唆した方法でソフトウェアを書くとシリコンが出せる性能を引き出せず、大きく失敗することもあった
抽象化の上で HPC コードを書くことはできるし、実際に多くの人がそうしているが、性能とスケーラビリティの損失は避けられない整数倍レベルであることが多い。他のソフトウェアと同じく、経験の浅い開発者でもコードを設計できるようになるなら、こうした損失が受け入れられることも多かった
HPC も他のソフトウェアと同じく、名目上はプロの開発者であっても、継続して良い結果を出すのが難しい人は多い。HPC に使われる高価なハードウェアの相当部分は、悪いソフトウェア設計によって生じる性能損失を緩和するために存在している
最大性能を望むなら、ハードウェアが実際にどう動作するかを理解する以外に近道はない。一般的なソフトウェアと変わらず、HPC ではハードウェアシステムがより大きく複雑なだけだ
ただし予想とは違っていた。性能指向の作業をもっと多く行い、数値を分析し、クラスタから最後の性能まで絞り出す仕事をすると思っていた。正直に言うと、最初は監視すらなかった。自分で構築したが、ほとんど使われていない。たまに経営陣が予算の正当化などの理由で「クラスタはどれくらい忙しいのか」と聞く程度だ
ほとんどの「最適化」は、スクリプトが CPU を16個しか使わないのに384個の CPU を要求しないよう確認したり、あるソフトウェアが性能低下なしに何個の CPU まで動くかをテストしたりすることだ。Intel プロファイラはたった2回だけ開いた
仕事の大半は、研究者たちの作業を手助けすることに近い。たいていは商用またはオープンソースのプログラムを実行して問題を解決したり、別チームが別のクラスタで書いたコードを持ってきて、こちらのクラスタでビルドして実行できるようにしたりする。ひどい Python コードを掘り返し、より新しいクラスタから CentOS 7 環境へ C++ プロジェクトをビルドしようと苦労する
それなりに面白い。いくつもの言語を扱ってきたので、何かを動くようにし、クラッシュやスタックトレースを掘り下げるのは好きだ。大きな機材を扱っていると、RAM が「たった」128GB だったりディスクが20TBだったりするサーバを見るときの普通の基準が歪んでくる
怖いのは、こうした結果が実世界で使われるのに、シミュレーションを回す人たちがきちんとやっていない場合があることだ。間違ったコード、混ざり合ったソースコード、自分たちが使っていると思っていたデータとは別のデータの使用、3年間存在していた巨大なバグを見つけたこともある。そうなると、このテーマで行ってきた作業が全部無効になるのではないかと思ってしまう
欠点は、HPC の求人のかなり多くが、クラスタ運用だけなのに修士号を要求することだ。よく理解できない。自分が実行するソフトウェアを書いているわけでも、最新の TOP500 クラスタを運用しているわけでもない。ただ複数のマシンをネットワークでつないでコードを走らせているだけだ
CUDA 開発者たちと働いた経験では、性能を引き出すためにノブをかなりいじる。Shmoo Plot（https://en.wikipedia.org/wiki/Shmoo_plot、一部の業界では「wedge」とも呼ばれる）は、日常的な最適化の重要な道具の一つだ
ただし、これをブラックボックスと呼ぶかは分からない。結果的には似ているかもしれない。ノブが何をして、どう動作するかを知り、根拠のある推測をしても、測定してみると大きな驚きが出ることはよくある。最適化の第一規則は測定だ
Michael Abrash の “Black Book” の第1章 “The Best Optimizer is Between Your Ears” http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf をいつも思い出す。現代の HPC ではなく PC ゲーム中心ではあるが、高性能の哲学をよく示す優れた文章だ
抽象化に関連して、最も重いノブ調整は最適化プロセスの最後に行うのがよい。リファクタリングしたり何かを変えたりすると、ノブ調整をやり直す必要があるからだ。レジスタスピルやキャッシュアクセスパターンの小さな変化だけでも、スレッド構成、キャッシュ、共有メモリサイズといった細かなチューニングが完全にリセットされ得る
それでも途中途中で適度な量のノブ調整は必要だ。確認とバランスを取り、コード周辺の性能空間について直感を得るためだ
今日の x86_64 ハードウェアには、スーパーコンピュータのメモリサブシステムのようなものはない。ただの豪華な NUMA システムであり、最大の問題はメモリをコアの近くに置くこと、つまりレイテンシを下げるためにデータをその NUMA ノード内でローカルに保つことだ
リソースのマッピングはスケジューラが処理する。スケジューラはハードウェアを知っているので、要件を満たし、できるだけ最適化された cgroup を作り、アプリケーションをその cgroup に入れて実行する
現在、高性能インターコネクトの王者は InfiniBand で、ファブリックレベルで MPI を高速化します。メッセージ転送、ブロードキャスト、結果のリダクションを非常に高速に行えます。メッセージは到着した時点ですでにリダクションされており、ブロードキャスト時には単一のメッセージを送るだけでファブリック層でブロードキャストされます。マルチコンテキストの IB カードはキューが多く、1つのノード／カード上で複数の MPI ジョブをキュー／コンテキスト分離によって実行できます
GPU の処理にフレームワークを使う場合、構造や最適化は通常そのレベルで自動的に処理されます。大変な作業の多くはフレームワーク開発者が担っています。NVIDIA ドライバも純粋な黒魔術のようなもので、最適化の一部を処理します。GPU 間接続は物理ファブリックが担い、ドライバと専用デーモンが管理します
CPU がボトルネックであれば、ライブラリは通常ベンダーが手作業でチューニング済みです。Intel MKL、BLAS、Eigen などがそうで、個人的に使ったことのある Eigen にはプロセッサごとのヒントや最適化が含まれていました
気にすべきなのは、コードを正しいアーキテクチャ向けにコンパイルし、実行するハードウェアが要件を満たせるか確認することです。たとえばランダムメモリアクセスを増やしすぎない、ノード上で「できるだけ速く」動かしたいならプリフェッチャと分岐予測器にうまく合わせる、ディスクアクセスを乱用しない、といったことです
数値計算では、命令レベル並列性／ベクトル化が可能になるよう処理を独立に保ち、不要な計算をせず、MPI を乱用しないこと、つまりノード間の会話を本当に必要な範囲に抑えることが要点です
言うのは簡単ですが、慣れてくるとこうしたことを考えるのは第二の本能のようになります。もっとも、こういう種類の仕事が性に合っていれば、という話です
正しくもあり、そうでない面もあります
MPI と OpenMP は、HPC においてハードウェアを抽象化する主な手段です。MPI は分散メモリ並列計算の抽象化であり、OpenMP は共有メモリ並列計算の抽象化です。多くの研究者はこの2つだけでコードを書き、同じコード内で両方を使うこともよくあります。これらを使う場合、たいていはアーキテクチャの細部を気にする必要はありません
それでも、さらに最適化するのが好きな研究者は、性能を引き出すために細かな構造上の詳細をいろいろ触ります。たとえば ループ展開 はかなり一般的で、個人的にはかなり混乱を招き得るものだと思います。特定の CPU アーキテクチャのために、乗算より加算を好んで演算をベクトル化しようとする、という話をぼんやり覚えていますが、実際に見たことはありません
キャッシュミス を防ぐことも大きなテーマです。コードによっては、最も必要な情報をメモリではなく CPU キャッシュに置くように書かれます。ほとんどのコードでは、Fortran なら配列演算で列優先の走査、C なら行優先の走査を保証する程度にとどまりますが、この概念はさらに拡張できます。プロセッサのキャッシュサイズが分かっていれば、必要な情報をすべてキャッシュ内に保つように特定の演算を最適化し、キャッシュミスを最小化することもできます。実際に見たことはありませんが、2013年に受けた科学計算の授業では盛んに扱われていました
特定の GPU を使うかどうかは、解こうとしている問題に大きく左右されます。GPU で非常にうまくいく問題もあれば、難しすぎる問題もあります。そのあたりは残念ながら詳しくありません
Victor がこれほど素晴らしい資料を集めたことに感嘆している。
個人的な知り合いではないが、1990年代に UT Austin で博士課程に在籍していたとき、TACC が管理していたリソース（Cray Y-MP、IBM SP/2 Winterhawk、そして当時 Cray T3E を指していたホスト名 Lonestar）を使って研究を終えた。博士審査委員の一人は今もそこにいる。記憶が正しければ、当時 TACC は HPCC か CHPC と呼ばれていた。
当時はプログラマーが自分でコードを並列化する必要があり、私の場合は UNICOS 環境の Cray T3E で MPI を使っていた。分野がまだ初期段階だったため、ハードウェアについてもある程度理解する必要があった。問題は、灰色の Cray リングバインダーと手元にあった Gropp らの本を読みながら解決したし、もちろん先に述べた知識豊富な連絡先も大いに助けになった。
時代は決して止まらない。
自分の分野からは少し外れるが、非常に興味深かった。残りも見てみるつもりで、興味のある人には確認してみることを勧める。
HPC の ハードウェア管理 側に関心がある。
問題がどのように検知・診断され、再起動／再インストール／修理といった措置にどうマッピングされるのか、こうした作業がどのようにスケジューリングされ、最善のサービスレベルを提供するよう最適化されるのかが気になる。
ノードの可用性と全体スループットのように同時に最適化すべき目標が複数ある場合はどうするのか、複数のトポロジーが上記にどのような影響を与えるのか、他の制約がどのような影響を与えるのか、全般的にこうした問題をシステムダイナミクスの観点から扱う方法にも関心がある。
こうした情報をうまく扱った資料はあまり見つけられなかった。知っている資料があれば教えてほしい。
待ち行列理論は最初に学ぶと些細で簡単に見えるが、未解決問題が多い。
たとえば、ランダムな到着時刻、独立したサービス時間、k 個のサーバーを持つシステム（M/G/k）の性能指標も、まだ未解決問題である。
https://www.sciencedirect.com/science/article/pii/S0895717704905341
予想に反して、待ち行列理論には本当に多くの未解決問題がある。
Meta には、この規模の GPU を扱う問題を説明した良い YouTube 動画がいくつかあった。
Meta もエンジニアリングサイトで論文、ブログ、オープンソースプロジェクトを多数公開している [2]。
AWS の James Hamilton もほぼ毎年インフラについて発表している。複数年分の発表を見る価値がある [3]。
[1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
[2] https://engineering.fb.com/category/data-center-engineering/
[3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
基本的にはワークロード、ここでは ディープラーニングジョブ のレベルで最適化し、ジョブサイズの調整とプリエンプションを可能にしている。
[1] https://arxiv.org/pdf/2202.07848.pdf
2013年に 科学計算 の授業を受けた。
コンピューターサイエンスと応用数学の両方にまたがって開講されていた科目だった。問題は、この分野全般があまりにも広く、HPC と並列プログラミングを含む多くのトピックを非常に表面的に扱っていたことだ。受講したことを後悔してはいないが、自分が目指していた応用には広すぎた。
ここ数年どの科目が開講されているかは見ていないが、大学院生だった当時、並列計算を丸々1学期扱う専用科目があれば本当に役に立ったと思う。特に、並列・分散計算における特定の アルゴリズムとデータ構造 を深く掘り下げる授業が必要だった。
私が受けた科学計算の授業では、こうした内容はあまりにも大ざっぱに扱われ、まるで初めて試しても正確に並列化する方法が分かるかのようだった。その後、多くの HPC 関係者と同じく、何年もかけて独学や同僚から多くを学んだが、こうした本が1学期の専用授業の一部だったなら非常に貴重だったはずだ。
著者が C++ と Unix ツールの教育まで含む、これほど包括的な本を作り、無料で共有していることに驚かされる。
HPC 専用でなくても、すべてのプログラマーに学ぶことがある。
関連資料として、Jorg Arndt の “Matters Computational” という本と FXT ライブラリもある: https://www.jjj.de/fxt/
ここで使われている C++ の教育方式をどう見るか気になります。特に欠点はあるでしょうか？
Python はかなり長く使っており、C、C++、CUDA も少し扱い、HPC 環境でアプリケーションレベルの研究（ML/DL）をしています。C++ の実力を上げたいのですが、3冊をざっと見たところ、自分のレベルにちょうど合っているように見えます。進行が遅すぎるわけではなく、網羅性を目指すというより、著者が言うベストプラクティスを教える方式です
範囲ベース for ループ、std::array、std::span を探したところ、すべて載っていて良かったです
この本は HPC に関係しているので、いくつか追加したい点があります。戻り値最適化、ムーブセマンティクス、そして再帰関数の節には末尾呼び出し最適化の説明があるとよいでしょう
初心者向け教材としては強くおすすめできます
参考までに、MPI は Python で HPC を行う一つの方法にすぎません
記憶が正しければ、ipyparallel は自前のトンネル上で MPI ジョブを実行できます
dask-scheduler、CuDF、CuGraph（NetworkX）、DaskML、CuPy、dask-labextension についての章があれば、より現代的になるでしょう
Dask はデータ保存を肩代わりしてくれないため、各バリアの前にあるデータストアが性能ボトルネックにならないよう保証するのは利用者の責任です
Dask ドキュメントの High Performance Computers: https://docs.dask.org/en/stable/deploying-hpc.html
乱数ソースがボトルネックになることもあります。クラスタ全体でジョブをプロファイルするまでは分かりません
eBPF ベースのトレーシングツール関連: https://news.ycombinator.com/item?id=31688180
その次には、GitOps と ChatOps、コードレビューとリビジョン、プロジェクトのリソース割り当て量といった内容もあるとよいでしょう
10年前、HPC の大学院科目の TA 役を分担してほしいという提案を受けましたが、断りました
ざっと見た限りでは、当時この本があったなら、その機会をつかんでいたと正直に言えます
Knuth 風に見える 芸術としてのフレーミング、木工になぞらえた視点、そして自分の DevOps 担当者よりも優れた DevOps 担当者にならなければならないという必要性が組み合わさって、説得力があります
著者の成果に拍手を送ります。UT Austin はコンピューターサイエンスにおいて、North Texas State が音楽で成し遂げたことに似たことをやってのけたように思えます
UT Austin は HPC と計算手法において本当に優れた機関です
大手自動車メーカーの HPC エンジニアを支援する小さな会社に加わったとき、スケジューラーである LSF の周辺に社内開発のスクリプトがあまりに多くて驚きました
ずっと後になって個人用のミニクラスタで SLURM を触ってみて、スケジューラーソフトウェアのバージョン同士は概して互換性がないことを知りました。つまり、クラスタ内部ではあるバージョンを使い、外部クライアントマシンでは別のバージョンを使う、ということができませんでした
そのため、外部からスケジューラーにジョブを投入し、あとで結果を取得するための接着ソフトウェアが必要でした。個人的には、これはスケジューラーの価値を下げていると思います
高性能分散計算を30年ほどやってきたなら、要件はよく知られており、少なくともコマンドとデータ交換プロトコルは固定されているものだと思っていました。ところが、そうではないようです
過去にも基本的なジョブ管理 API を標準化しようとする試みはあり、DRMAA は注目すべき例です。ただし DRMAA v2 は Grid Engine だけが実装し、実質的には内部 API を少し抽象化した版だったため、Slurm/PBS/LSF では第一級のサポートを得られませんでした
Slurm では REST API が今後の方向性と見なされています。認証の問題は、Apache/NGINX プロキシを通じて、管理者が接続したい任意の方式へ丸投げします。基本的なジョブ投入と状態 API は、今後ほぼどのバージョンのクライアントアプリケーションでも利用できる程度には安定してきています