Skip to content

Instantly share code, notes, and snippets.

@kaityo256
Last active November 18, 2020 09:34
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kaityo256/ee7c29859591823d025fce18ccf461ef to your computer and use it in GitHub Desktop.
Save kaityo256/ee7c29859591823d025fce18ccf461ef to your computer and use it in GitHub Desktop.
HPLについて

HPLについて

これは以前Twitterに連投したものと、Qiitaに書いたものをまとめて加筆修正したものです。

はじめに

だいぶ前に一世を風靡し、今はもはや風化し始めている「2位じゃダメなんでしょうか?」という言葉がありました。ここで1位とか2位とか言っているのは、狭義にはスパコンのランキングTOP500の順位のことを指します。TOP500は、HPLというベンチマークによりスパコンの性能を測定し、そのランキングを決めるもので、年に2回ランキングが更新されます。以前、初代地球シミュレータが5期連続でトップを守りましたが、これは5年ではなく、2年半トップであった、というものです。

HPLとは、一言でいえば馬鹿でかい連立一次方程式を解くベンチマークです。問題サイズは自由に決められます。問題サイズが大きいほど性能を出しやすいですが、その分計算時間がかかるようになるため、実際には数時間〜数十時間程度で実行できる範囲のサイズが選ばれることが多いようです。問題が連立一次方程式なので、解いたあとに実際に代入して答えが合っているかどうかを確認します。実際には計算誤差などがあるため、その誤差が規定範囲内に収まっていれば合格となり、その時の演算性能がTOP500への報告値となります。

広く使われているベンチマークには「性能の一部しか反映していない」といった批判がつきものですが、HPLにも昔からそのような批判が存在しますし、LINPACKの開発者であるDongarra氏もHPLだけでスパコンの性能は評価できないので多面的に云々といった趣旨の発言をしているようです。

このことから、「TOP500というランキングで一位ないし上位に入っても、単に一つのベンチマークで高得点をとっただけであり、実際のスパコンの実用性とは乖離した指標である」という論調が見受けられます。もちろん、スパコンの性能は多面的に測定されるべきであり、究極的にはそのスパコンで主に使われるアプリケーション性能で議論すべきものです。しかし、おそらくスパコンにあまり詳しくない方が思っているよりも、HPLは実際的、実用的なベンチマークです。以下、ハードウェア作成側というよりは、スパコンユーザ側から見たHPLの意義をつらつら書いてみたいと思います。言うまでもありませんが、私個人の意見であり、所属組織を代表するものではありません。

HPLで測るもの

スパコンユーザ、というかスパコンを導入する側が、そのベンチマーク性能としてHPLの数値を求めるのには、大きく分けて「ハードウェアテスト」「電力消費量テスト」「ソフトウェアテスト」の三つの意味を持っています。

ハードウェアテスト

「ハードウェアテスト」というのは、システムがまっとうに組めているかのテストです。全系HPLでそれなりの数字を出そうとすると、全システムが全力で数時間~数十時間の間、トラブルなく動き続けられる必要があります。これに耐えられるシステムを組むのは極めて非自明なことです。スパコンは、多くのノードから構成されています。ノードは、CPU、メモリ、インターコネクトなどから構成されており、ざっくり言えばPCと同じようなものです。

さて、すべての部品は壊れる可能性があります。特にハードディスクやファンといった「回るもの」は壊れやすい傾向にあります。マザーボードも通信ケーブルも壊れます。メモリも頻繁に壊れる部品の代表です。スパコンのノードは普通のPCよりも多い枚数のメモリを積んでいることが多いため、その分壊れる可能性も増えます。

ざっくりした話、だいたい一年に一度壊れるようなノードを1000ノード集めると、8〜9時間ごとにノードがどこか壊れることになります。従って、このシステムでは、1000ノードを24時間協調動作させることは絶望的です。HPLで性能出そうとすると数十時間とか計算する必要があったりするので、一年に一度壊れるようなノードを集めたシステムでは1000ノードでもまともなベンチマークすら取れないことになります。

計算機は負荷をかければかけるほど壊れやすくなります。また、発熱も大きな問題です。HPLは、数あるベンチマークの中でも特に「重い」ベンチマークの一つです。数万ノードから構成されるスパコンが、全ノードで全力を出して計算をする状態を数十時間維持する(その間ちゃんと冷却する)技術は、極めて非自明なものです。ただPCを多数つないだだけでは、大規模計算はできません。「HPLでXX以上の性能を出してください」という要請は、「それなりの時間、全システムが全力を出しても壊れない信頼性のあるシステムを納品してください」ということを含意します。

電力消費量テスト

最近のCPUは、負荷に応じてコアを休ませたり動作周波数を変えたりします。したがって、実行時の電力消費量はかなり上下することになります。最近の石のカタログのTDPは「参考価格」程度にしか参考になりません。メーカーにもよりますが、カタログのTDPの値を積み上げていくと、電力消費量を実際よりもかなり過大に見積もることになります。現在、スパコンの電力消費量の増大はかなり問題になっており、予算よりも電力消費量が上限を決める場合もあります。かといって、ここを甘く見積もって運用中に使用電力がトランスのキャパシティを超えてしまっては大変なことになります。前述の通り、HPLはかなり「重い」ベンチマークです。普段使いで全系HPLを越える電力は使わないであろうことから、全系HPLをこのシステムの電力消費量の上限の見積りに使うことができます。

ソフトウェアテスト

これは「テスト」と呼ぶべきか微妙なのですが、HPLがちゃんとできるということは、ハードウェアベンダーがちゃんとしたBLAS職人を抱えている証左になります。昔は知りませんが、現在の石で行列行列積を書くのは非自明な技術です。自分でDGEMMを書いてみれば、その性能の低さに驚くと思います。科学技術計算の多くはBLASに依存しており、その基本はDGEMMです。DGEMMはアーキやSIMD幅に応じて書き直す必要があります。HPLをちゃんとやるというのは「そのアーキでちゃんとしたBLASを用意します」という、ベンダーの意思表示になります(もちろんスパコンを導入する際は、BLASはBLASでテストしますが)。

まとめ

HPLについて、「スパコンを使う側(導入する側)」の観点から書いてみました。繰り返しになりますが、HPCに詳しくない方が思うよりも、HPLはスパコンの性能指標として実際的/実用的なベンチマークとなっています。この小文がHPL(LINPACK)の新たな側面を紹介できたのなら幸いです。

おまけ

たまに「HPL専用機」といった言葉を見かけます。「HPLでの性能は高いけれど、実用的なアプリケーションは遅いために使い物にならない」といった意味で使われていることが多いようです。おそらくハードウェアの意味で「HPL専用機」という指摘はほぼ意味を持たないと思います。HPLの基本は倍精度実数行列行列積(いわゆるDGEMM)であり、DGEMMは多くの科学技術計算の基礎ですから、「HPLは高速に動くけれど、他の科学技術計算には使い物にならない」というハードウェアは、よほど「そう狙って」作らない限り実現は難しいものと思います。もちろん、倍精度計算は早いけれど、整数演算が遅く、それを多用する計算には向かない、等はあると思いますが、そのあたりは程度問題でしょうし・・・。そう言えば過去に「コンテキストスイッチが遅い」という欠点を持っており、一般の用途にはそれが致命的な欠点となりましたが、科学技術計算はそれが問題とならないためにHPC用途ではそれなりに使われた、なんて石もありましたっけ・・・。

「HPL専用機」という言葉が意味を持つのは、ソフトウェアスタック周りを指す時だと思われます。一般に新しいアーキテクチャでは、ソフトウェアまわりの整備が遅れる(あるいは間に合わないままハードウェアの寿命が尽きる)、というのはよくある話です。コンパイラ、通信ライブラリといった基礎的なところから、BLAS、LAPACK、ScaLAPACK、FFTといったライブラリのチューニング、デバッガやプロファイラなどの用意などは、どうしてもハードウェアができてから遅れて成熟するものです。ただ、その指摘はどのアーキテクチャにも言えることです。新しいアーキテクチャが登場と同時にソフトウェア周りもそれなりに揃っている、というのは、結局そのアーキテクチャが古いアーキテクチャと互換性を持っているからで、互換性に引きずられ過ぎては本質的に新しいアーキテクチャは生まれません。互換性か、革新か、そのバランスは常に難しい問題で、ソフトウェア開発コストも含めてトータルに議論すべきものですが、個人的には、どこかで挑戦をし続けなければ業界全体がジリ貧に陥ってしまうのではないか、と危惧します。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment