この記事は、The Parallel Universe Magazine 55 号に掲載されている「Distribute Intel-Optimized HPC Binaries Using Spack」の日本語参考訳です。原文は更新される可能性があります。原文と翻訳文の内容が異なる場合は原文を優先してください。
ハイパフォーマンス・コンピューティング (HPC) ユーザーは、パフォーマンス、互換性、精度をテストするため、異なるソフトウェアやパッケージのバージョン、依存関係、設定に対処する必要があります。この作業には時間がかかるため、ローレンス・リバモア国立研究所が主体となり、スーパーコンピューター・パッケージ・マネージャー (Spack) (英語) と呼ばれる効率的なパッケージ・マネージャーが開発されました。Spack は、その多くの利点 (オープンソースで、シンプルな仕様ベースの構文を提供し、パッケージの作者/メンテナーに同じパッケージの異なるビルドを処理する Python* インターフェイスを提供している、など) により、HPC コミュニティーの注目を集めています。Spack が2023年の HPCwire Editors’ Choice Award の「ベスト HPC プログラミング・ツール/テクノロジー」 (英語) を受賞したことは注目に値します。
この記事では、インテルのツール、ライブラリー、設定を使用してインテル® ハードウェアのパフォーマンスを最大限に引き出すことが難しい 3 つの重要な HPC アプリケーションで、最適な実行ファイルを構築する Spack レシピとガイドラインを示します。現在の作業における「最適な実行ファイル」という用語は、Spack を利用してそれらのツールを適切に使用し、インテル® HPC の顧客とパートナーに、インテル® Xeon® スケーラブル・プロセッサーで最適なパフォーマンスを達成しつつターゲットのオープンソース・アプリケーションを簡単に構築する一般的な方法を提供することを指します。これらのレシピは、Amazon Web Services* (AWS*) および Google Cloud Platform* (GCP*) 上の第 4 世代インテル® Xeon® スケーラブル・プロセッサーでテストされ、インテルにより最適化され、手動でビルドされたバイナリー (以下、「リファレンス・ビルド」と呼びます) と同等のパフォーマンスが得られています。
ターゲット・アプリケーション
HPC アプリケーションは、科学、エンジニアリング、ビジネスにおける複雑な問題を解決します。Spack を利用可能なパッケージのリスト (英語) は増え続けています。産業、研究、学術分野で広く使用されているため、さまざまな HPC 業界にわたる、次のアプリケーションが現在の作業に選択されています。
Weather Research and Forecasting Model (WRF) (英語) は、大気のモデリングと運用予測のために設計された数値気象予測モデルです。WRF のビルドプロセスは、一連の依存関係が含まれているため、「かなり」複雑なものと考えられています。そのため、ビルドを簡素化する Spack の能力を評価するのに役立ちます。
Large-scale Atomic/Molecular Massively Parallel Simulator (LAMMPS) (英語) は、材料のモデリングに重点を置いた古典的な分子動力学シミュレーターですが、異なるスケールの汎用粒子シミュレーターとして機能します。LAMMPS のビルドプロセスは簡単ですが、そのパフォーマンスはコンパイラー、命令セット、パフォーマンス・ライブラリーなどの選択に左右されます。そのため、ビルドプロセス中に発生する潜在的なパフォーマンスの低下を追跡するのに役立ちます。
Open Source Field Operation and Manipulation (OpenFOAM) (英語) は、数値のモデリング、および主に数値流体力学向けの連続体力学の前処理と後処理のためのオープンソースのツールボックス・スイートです。コンパイラー間の依存関係があるため、コンパイルプロセスに比較的時間がかかります。そのため、コンパイラー間の依存関係や長いコンパイルを処理する Spack の能力を評価するのに役立ちます。
システム構成
クラウド・サービス・プロバイダー (CSP) (AWS* や GCP* など) は、オンプレミスのシステムで発生する初期コストや導入の困難さを回避しながら、アプリケーションとデータを処理するオンデマンドで、オープンアクセスの、スケーラブルなコンピューティング・リソースをユーザーに提供します。この記事では、公開されている CSP のインスタンスを使用して Spack レシピのパフォーマンスを評価し、読者がレシピを再現できるようにしています。表 1 と表 2 はそれぞれ、AWS* と GCP* のインスタンスの概要です。提供された Spack ガイドラインが包括的で有用であり、異なるインテル® アーキテクチャーでテストされていることを保証するため、2 つの CSP で提供されている 4 つの異なる世代のインテル® Xeon® プロセッサーを含むインスタンスでテストを行いました。
パフォーマンス解析
前述の 3 つのアプリケーションの 13 のワークロードのパフォーマンスを、次の点を考慮して評価しました。
- Spack バイナリーを対応するリファレンス・ビルドと比較する際、同様の (または同じ) コンパイラーやアプリケーションのバージョンを利用して、ソフトウェア・スタックの変更を最小限に抑える。
- 同じベンチマーク・ツール、環境変数/設定、ワークロード・タイプ/バージョン、入力データセット、その他を使用して、各ビルドのパフォーマンスを測定する。
図 1 は、AWS* インスタンス上の対応するリファレンス・ビルドと比較した Spack ビルドのパフォーマンスを示しています。実行ごとの変動に伴う 10% の許容誤差を考慮すると、リファレンス・ビルドの予想パフォーマンスが、調査したすべてのワークロード間で Spack ビルドを使用して (ほぼ) 再現されています。同じテストと実行プロセスを GCP* のインスタンスで実行したときの、対応するパフォーマンス結果を図 2 に示します。繰り返しますが、リファレンス・ビルドと Spack バイナリーのパフォーマンスはほぼ同等です。
