私は、次の仕様でのLinuxマシン上でシミュレーションを実行しています。
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 80
On-line CPU(s) list: 0-79
Thread(s) per core: 2
Core(s) per socket: 20
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Stepping: 4
CPU MHz: 3099.902
CPU max MHz: 3700.0000
CPU min MHz: 1000.0000
BogoMIPS: 4800.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 28160K
これは私のソルバーの実行コマンドラインスクリプトです。
/path/to/meshfree/installation/folder/meshfree_run.sh # on 1 (serial) worker
/path/to/meshfree/installation/folder/meshfree_run.sh N # on N parallel MPI processes
私は私の他の同僚とシステムを共有しています。彼は解決のための10個のコアを使用しています。この場合、私のための最速のオプションは何でしょうか？30 MPIプロセスを使用していますか？
私は、並列コンピューティングにはほとんど知識を持つメカニカルエンジニアです。質問はあまりにも愚かであれば、私を許してください。
Q：「何だろう最速のオプションこの場合、私のために？時間に不足して...私はシミュレーションの途中ですでにです。。」
アーヘンへの敬礼。それは事後発言がなかった場合は、最速のオプションは、コンピューティングのエコシステムよう-のconfigureを事前に次のようになります。
- お使いのNUMAデバイスの完全な詳細を確認-使用して
lstopo、またはlstopo-no-graphics -.asciiありませんlscpu
- 持つあなたのジョブが開始するなど、物理的にマッピングされ、可能な限り多くのMPI-ワーカープロセス（と最高の独占的にその上にマッピングされた各1 プライベート）（これらは本に値するとして、彼らは、コアがFEM /噛み合いワークロード処理を運ぶよう）CPUコア
- if your FH policy does not forbid one doing so, you may ask system administrator to introduce CPU-affinity mapping ( that will protect your in-cache data from eviction and expensive re-fetches, that would make 10-CPUs mapped exclusively for use by your colleague and the said 30-CPUs mapped exclusively for your application runs and the rest of the listed resources ~ the 40-CPUs ~ being "shared"-for-use by both, by your respective CPU-affinity masks.
Q : "Using 30 MPI processes?"
No, this is not a reasonable assumption for ASAP processing - use as many CPUs for workers, as possible for an already MPI-parallelised FEM-simulations ( they have high degree of parallelism and most often a by-nature "narrow"-locality ( be it represented as a sparse-matrix / N-band-matrix ) solvers, so the parallel-portion is often very high, compared to other numerical problems ) - the Amdahl's Law explains why.
Sure, there might be some academic-objections about some slight difference possible, for cases, where the communication overheads might got slightly reduced on one-less worker(s), yet the need for a brute-force processing rules in FEM/meshed-solvers ( communication costs are typically way less expensive, than the large-scale, FEM-segmented numerical computing part, sending but a small amount of neighbouring blocks' "boundary"-node's state data )
The htop will show you the actual state ( may note process:CPU-core wandering around, due to HT / CPU-core Thermal-balancing tricks, that decrease the resulting performance )
And do consult the meshfree Support for their Knowledge Base sources on Best Practices.
次回は - 最良の選択肢は、（あなたのビジネス継続性に影響を与える場合より、ビジネス・クリティカルな状況与えられたが、これはスムーズBAUのリスクであると考えて）クリティカルなワークロードを処理するために制限の少ないコンピューティングインフラストラクチャを取得することです。