並列演算の効率がどのように変化するのかログをもとに読み取ってみます

altair_fukuoka · December 4

はじめに

皆さんは、なんとなく、並列数を２倍にしても、計算速度は 2倍にならないということを、肌で感じていると思います。

本記事では、私が書いている Radioss 入門演習書の、リモコン落下解析のモデルを用いて、様々な並列パターンで計算してみて、ログを見ながら、演算効率がどのように変化しているのか、というのを解説します。

https://learn.altair.com/course/view.php?id=699

なお、今回のログの読み方がうまく当てはまらないこともあるかと思います。あくまで、どのあたりを見たらよいのか、というヒントになればと思います。

SPMD の並列演算をしてみた結果

SPMD は要は実行オプションの -np です。領域分割による並列化手法です。4 ~ 108 まで計算してみました。今回、注目したのは _0001.out ファイルのこの CUMULATIVE CPU TIME SUMMARY です。これは、CPU が演算に費やした時刻ですので、実際に人間が待っている時間とは異なります。

それから ELAPSED TIME も集計しました。これは、実行が終わるまでの実時間です。

集計した結果です。np 以外の単位は秒です。

実時間は "-np 72" で頭打ちといったところです。

ではどのようにして頭打ちになっていったのか読み取っていきましょう。表のままだと、分かりにくいので横軸を "-np" の並列数、縦軸を各計算項目の CPU 時間としてグラフにしてみました。

並列数に関わらず、同じ計算をしているので、もし並列化で効率が落ちないのであれば、計算に必要な CPU 時間は、一定になります。逆に効率が落ちるものは、増加します。

今回は、OTHERS というのに着目しました。並列数しか変わっていないのに、増えているわけですから、ここに SPMD 並列処理計算コストが含まれることになります。並列数を人に例えると、人が増えるにつれ、コミュニケーションを増やして情報交換しなくてはならないため、計算コストが上がります。"-np 72" で最も計算時間が掛かるようになってしまいました。変なたとえですが、業務効率化のために eMail を導入したら、メールの数が多すぎて、実業務に入れない、そんな感じです。

"-np 108" に至っては、例えるなら、生産ラインに人が多すぎて身動きが取れずに効率が下がっているところに、さらに人員を投入しているようなものになります。

また、CONTACT FORCES も、並列効率が良くない項目ですが、"-np 108" で急激に悪化しています。接触は、領域分割をまたいで計算しなくてはならないので、もともと並列効率が良くないところに、領域が増えすぎて、あちこちと接触力を計算しなくてはならなくなり、跳ね上がったと言えると思います。

ELEMENT FORCES (要素力計算) はもともと一番コストがかかっていますが、並列化効率がとても高いです。

ですので、本モデルでの "-np" による高速化は、要素力計算の高速化から、SPMD と接触力の速度低下を差し引いた分、高速化できたと言えると思います。

SMP 並列演算の結果

SMP は "-nt" による並列演算です。スレッド化と言われる技術です。一つの仕事を複数人で行う並列化です。ここでは "-np 8" を固定して、"-nt" を 1, 2, 3, 4 とやってみました。

こちらが集計結果です。

実時間である ELAPSED TIME はじりじりと改善します。

先ほどと同じようにグラフ化してみると、スレッド演算処理 (OTHERS に入っている) と接触力は、SPMD と同じように並列化効率が高くなく、要素力は高い並列化効率を保ちます。

スレッド演算処理ですが、例えば、物を運ぶとき、一人(で持てる)なら、黙って持ちあげて、黙って所定の場所まで自分の速度で運べばよいですが、二人、三人と人数掛けて運ぶときは、「よいしょ」と掛け声掛けて、タイミングを合わせないといけないですし、「１，２，１，２」と歩調も合わせないといけませんから、そういったところでスレッド並列演算を管理しているコストと考えると感じをつかみやすいと思います。