デュアルコアから始まり、1CPUに4コア、8コア、12コアなど、現在では1CPUに22コアという製品も存在します。多数のコアが使用できる環境であれば、並列数を増やして計算の速度アップが期待出来ます。E5-2600 v4ファミリーなら、1ノード44コア、44並列で研究の速度アップだ!
・・・って、ちょっと待って下さい!
並列計算をしようとしている、そのアプリケーションは44並列の実行が可能なものですか?
並列計算の実装方法はアプリケーションによって様々ですが、一般的に使用される並列計算の方法として、計算が必要な区分を分割して計算するものがあります。10の領域を計算する場合、2並列なら5と5に分割して、それらを同時に計算すれば、速度は(理想的には)2倍を期待出来ます。
では、44並列を行なう場合、分割は、44を素因数分解して2×2×11。あれ?11?11で割ったら、丸め誤差が出てしまうんじゃない?
実は、並列計算アプリケーションでは、暗黙の了解として、2のべき乗で並列計算する前提で開発されているものが多いです。2のべき乗であれば、分割の際の割り算で必ず割り切れるのですから、計算誤差の処理が容易です。誤差を増やしたくない場合、有効桁数の処理で処理し易いからです。
こうした理由で、弊社では、なるべく、2のべき乗の並列数で並列計算を実行することを推奨いたします。
アプリケーション側が想定していない並列数での実行例として、VASPで11並列を実行した場合を見てみましょう。
VASPの計算精度を検証するツールとして、vasptest( https://www.nsc.liu.se/~pla/vasptest/ )があります。一部、開発元のリンショーピング大学計算センター独自の都合のインプットもありますが、概ね、VASPの計算精度をチェックするのに有効です。
VASP5.3.5を8並列で実行した場合、vasptestの結果の数値精度に問題はありません。ここで、極端な例として11並列で試験してみます。すると、11並列でも動作はするのですが、
Failing scenarios:
features/functional.feature:5 Si-GW
features/production.feature:4 MgMoS
features/production.feature:21 PbO2
features/production.feature:31 Li2FeSiO4
features/production.feature:40 CeO2
このように、5つものインプットで計算誤差が許容範囲外となりました。例えば、最初のSi-GWの場合では、
And the highest occupied quasi-particle energy should be 5.1537 +/- 0.001 eV
Assertion Failed: got 3.927600 instead
となっており、この差異では、実計算をしたくない感じです。
分割を考えてみると、こうなってしまうのはありえる事で、むしろたった5つしか問題にならなかったVASPの誤差修正の実装は凄いと言っても良いかもしれません。
並列数の問題に関して、アプリケーション側で、対応を行なっているものもあります。例えばGROMACSで22並列を実行してみると
The number of ranks you selected (22) contains a large prime factor 11. In most cases this will lead to bad performance. Choose a number with smaller prime factors or set the decomposition (option -dd) manually.
といったワーニングを出して、問題があるという表示でストップする親切な仕組みとなっています。ただし、こうした対応をしているといっても、全ての並列数に対して条件分けする事は大変ですし、アプリケーションの速度も低下しますから、対応してあるとしても、限定的である場合が多い印象があります。
平日9:30~17:30(土曜日、日曜日、祝祭日、年末年始、夏期休暇は、休日とさせていただきます。)