先々の記事（v2406）は新サーバー（E.Mogura’s 2024 Server / Intel Core i9-14900K）での初のAllrunであった。新サーバーといっても、旧サーバー（E.Mogura’s ServerR / Dual Xeon Gold 6130）が昇天した為、著者の新しいデスクトップマシンとして用意してあったマシンを代替利用したものであった。しかし、先々の記事（v2406）、先の記事（v2412）でインテルCPUのEコアが全くもって役に立たないことがわかったので、計算サーバーとしての利用は諦め、改めて新々サーバー（E.Mogura’s 2025 Server / AMD Ryzen 9 9950X）を導入したので、早速やってみた。その結果をサーバー性能の比較という観点で取り纏めてみた。
基本的に、先の記事（v2306）に記した方法に加えて、並列数が8を超えるケースについては並列数を変更した上で、ほぼログ解析まで問題なく実行でき、残された手作業項目や、実行エラーしたケース等についても全く同一であった。
2025-02-19 18:39:51 +0900(Start) / 2025-03-11 03:18:18 +0900(Finish)
総計算時間 460Hr（旧計算環境では639Hr）
データベースのグラフ化による比較
念の為、ディスク使用量の変化についても調べたのと、カテゴリ別、チュートリアルケース毎で計算時間の比較を実施した。
カテゴリ別ディスク使用量の比較（新旧計算サーバー）
カテゴリ別計算時間の比較（新旧計算サーバー）
トータルの計算時間としては、100時間強短くなっていたが、incompressibleを除くほとんどのカテゴリで計算時間が1/2〜1/3になっているのに対して、incompressibleのカテゴリでは、計算時間が増えてしまっていた。
使用したSQL構文
並列数別計算時間の比較（新旧計算サーバー）
新サーバーで実質有効なコア数は8であり、新々サーバーでは16であるので、並列数が8以下の計算ケースとそうでないケースを区別して比較するのが妥当であろうと考え、以下のように取り纏めた。
並列数(Np)別ClockTime比較
| clockTime(Hr) | Np<=8 | Np>9 |
| 2025 Server | 188 | 274 |
| 2024 Server | 228 | 421 |
| 変化(%) | 82.6 | 65.1 |
やはり高並列数ケースでの計算時間短縮効果が大きいところを見てとれたが、そうでないケースでの短縮効果も予想以上に大きかった。
個別ケース毎計算時間比較（新旧計算サーバー）
並列数が8を超えるケースでの比較はあまり意味が無いので、8以下のケースについて、個別ケース毎に比較した。
使用したSQL構文
図中には、等速ライン（x1）も記してあるが、全平均として82.6%となっていた数字は凡そ納得できそうではある。しかし個別のケースで見ると、かなりばらつきが大きいこともわかった。
参考までに、図中の番号を付したケースの名前を、計算時間が短縮したケースと、増加したケースとを区分して記しておく。
計算時間短縮したケース（黄色番号）
- incompressible/pimpleFoam/LES/surfaceMountedCube(8)
- incompressible/adjointOptimisationFoam/shapeOptimisation/motorBike(20)
- multiphase/interFoam/laminar/vofToLagrangian(4)
- multiphase/cavitatingFoam/LES/throttle3D(4)
- incompressible/simpleFoam/turbulentFlatPlate(1)
- combustion/fireFoam/LES/smallPoolFire3D(4)
- compressible/rhoPimpleAdiabaticFoam/rutlandVortex2D(3)
- incompressible/pimpleFoam/LES/decayIsoTurb(8)
計算時間増加したケース
- lagrangian/DPMFoam/Goldschmidt(1)
- lagrangian/sprayFoam/aachenBomb(1)
- combustion/reactingFoam/laminar/counterFlowFlame2D_GRI(1)
- combustion/reactingFoam/RAS/SandiaD_LTS(1)
- lagrangian/icoUncoupledKinematicParcelFoam/hopper(4)
- multiphase/interFoam/RAS/DTCHullMoving(8)
- discreteMethods/dsmcFoam/supersonicCorner(4)
- incompressible/overPimpleDyMFoam/twoSimpleRotors(1)
- discreteMethods/molecularDynamics/mdEquilibrationFoam/periodicCubeWater(1)
- lagrangian/reactingParcelFoam/verticalChannel(1)
- verificationAndValidation/schemes/nonOrthogonalChannel(1)
- compressible/overRhoPimpleDyMFoam/twoSimpleRotors(1)
- lagrangian/MPPICFoam/Goldschmidt(1)
- discreteMethods dsmcFoam/freeSpaceStream(4)
- mesh/foamyHexMesh/flange(1)
追加計算
今回は並列数が16以上のケースに対して、余裕を見て少なめの並列数としたが、いくつか並列数を変更して計算をやり直してみた。14並列で実施した計算を、15並列や、16並列で計算するなど。
しかしその間、新々計算サーバーに対してメモリー増設も実施していた。後で判ったことであるが、メモリー増設が裏目に出て、計算速度が低下してしまっていた。増設したメモリーのメーカーが既設のそれとは異なっており、多分メモリーのクロック周波数が違うなどあった可能性がある。上記追加計算の結果もいくつか残っているが、数字をそのまま出しても計算条件等の説明も難しく、却って混乱を助長しかねないのでここでは公開しないでおくこととした。
ただ、メモリーを増設した新々計算サーバーで総じて遅くなっているだけで、14〜16並列での違いは大差ないと言ってよさそうではあった。
結論と今後
新々計算サーバー（Ryzen 9 9950X）において、新計算サーバー（Core i9-14900K）における有効コア数（Pコア数）の8を超える並列計算において、予想通りの計算速度向上が見られた。加えて8並列以下の計算についても平均して20％程度の速度向上が見られた。これは、一般的なCPUベンチマークの数字からは想像できない数字であった。但し、こちらはケースによるバラツキが大きく、速度低下となるものもあった点は留意する必要もあろう。
いずれにせよ、新々計算サーバーのメリットは明らかになったので、当分はこれでやっていく予定。
また今後のAllrunにおける多並列計算のケースでは、最大並列数を16として実施していく予定。
並列数が16 以上のケース（OpenFOAM-v2406）
新々サーバーではコア数が16あるので、16並列までは大丈夫かと思われたが、余裕を見て、以下のように変更した。
- incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses 60->12
- incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass 60->12
- incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass-uniformity 60->12
- incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox/losses-mass-uniformity-SQP 60->12
- incompressible/pimpleFoam/LES/planeChannel 36->14
- IO/cavity_parProfiling 20->14x
- incompressible/pimpleFoam/LES/periodicHill 16->12
- incompressible/pimpleFoam/LES/wallMountedHump 16->14
なお、以下のケースは仕掛かりの時点で、見落としていた。
SQL-1
select `ver_name` version,
category,
count(*) postcount,
sum(`diskUsage`)/1000,
sum(`clockTime`)/3600 ,
`name` exeSys,
`release_date`,
case when exe_system = 4 then 0.5* sum(`diskUsage`)/1000000
else sum(`diskUsage`)/1000000
end as du
from `wp_of_tutorials`
JOIN of_ver ON wp_of_tutorials.of_ver = of_ver.id
JOIN wp_of_exe_system ON wp_of_tutorials.exe_system=wp_of_exe_system.id
where of_ver.id in (32)
group by `exe_system`, `of_ver` ,`category`
order by `exe_system`
SQL-2
DROP TABLE IF EXISTS of_temp;
create table of_temp as
with old_data
as( select category as o_category, solver as o_solver, model as o_model, caseName as o_caseName,diskUsage as o_diskUsage ,exeTime as o_exeTime ,clockTime as o_clockTime from `wp_of_tutorials` where of_ver=32 and exe_system=7)
select new.category, new.solver, new.model, new.caseName, new.diskUsage, old.o_diskUsage, new.exeTime, old.o_exeTime , new.clockTime, old.o_clockTime
from
wp_of_tutorials as new
inner join old_data old
on new.category = old.o_category
and new.solver = old.o_solver
and new.model = old.o_model
and new.caseName = old.o_caseName
where new.of_ver=32 and exe_system=8
order by new.category, new.solver, new.model, new.caseName
;
select category, caseName, diskUsage/1000, o_diskUsage/1000, exeTime, o_exeTime , clockTime, o_clockTime from of_temp
where clockTime > 0