12
$\begingroup$

Why is that increasing the number of cores (openMP) in a computation does not decrease the duration of the process? Is it due to consecutive approximation?

I took a very simple system of Cu in FCC lattice and did the self consistent field (SCF) calculations with increasing number of cores. If you see the plot, the duration of task (Wall Clock) is nearly same or increases slightly. I am using an ordinary laptop with Intel Core i5 8th Generation, which has 4 cores (8 logical). Compiler: gfortran with openMP.

enter image description here

No of Cores CPU Clock (s) Wall Clock (s)
1 010.17 10.34
2 019.01 09.80
3 028.17 09.72
4 035.59 09.20
5 047.85 09.97
6 055.19 09.51
7 085.91 12.65
8 109.32 14.34
$\endgroup$
4
  • 4
    $\begingroup$ More cores doesn't mean faster. More cores can mean slower if the overhead caused by using parallelism is more significant than the work for the calculation. Are you using just a single unit cell? If so it's likely there's just not enough work to justify using more than one core. Please provide more details of the test case you are running. $\endgroup$
    – Ian Bush
    Oct 2, 2021 at 14:58
  • $\begingroup$ @IanBush Yeah am using a single unit cell because of my laptop. I'll redo my calculation with little complex unit cell and update the question. If anyone wants to try on their PC/Workstation, I can provide the script. $\endgroup$
    – 147875
    Oct 3, 2021 at 16:19
  • $\begingroup$ Keep in mind that some codes (e.g. OpenMolcas) provide OpenMP but it doesn't give much parallelization in the absence of MPI. Also, you can run MPI parallel software on one CPU, each MPI process would run on one core, which is fine. Try compiling with MPI and then see if that changes things. $\endgroup$
    – S R Maiti
    Oct 3, 2021 at 21:33
  • $\begingroup$ Another possibility just to check is that you have linked against threaded libraries, if your time is dominated by e.g. matrix multiplies and those aren't threaded, you won't get much performance improvement $\endgroup$
    – Ian Bush
    Oct 4, 2021 at 7:39

2 Answers 2

10
$\begingroup$

You don't give any real details on the system, but I can make a guess from your scaling that either the code doesn't properly support openmp (which is unlikely) or your system is way too small to see a benefit. I suspect if you use a bigger system (that can't finish in about 10 seconds on a single core) you will see an improvement.

Also keep in mind a practical consideration for using a laptop, you likely have other programs running in the background. This means using 100% of cores will always force some cores to be inactive for the calculation doing other things, slowing things down. An intel i5 8th gen will also probably have hyperthreading, so make sure you are using all of the cores not all of the threads. Hyperthreading tends to be bad for these sorts of workloads and its normally disabled or not available on high end software.

$\endgroup$
0
8
$\begingroup$

I think that there should be three considerations (and of course I could be wrong).

  1. If you have not compiled the software to work in parallel, specifying multiple (N number of) threads sometimes is said to cause the same job to run in serial mode but N times.
  2. Even though you have a multi-core calculation, the actual work being done may not really need more than a single core. To check this, you can monitor the utilization of individual cores to ensure that they are being fully utilize during each calculation.
  3. No matter how fast your processor completes a calculation, if your memory is slow, that could be the bottleneck (although this is highly unlikely for a small number of atoms judging by the wall time for each calculation).
$\endgroup$
2
  • $\begingroup$ the software is not compiled with mpi (message passing interface), since I have only one processor. But enabled openmp (multiprocessing) while compiling which is responsible for multithreading. Since I am doing for very simple lattices memory speed won't affect much. So first and third can be ruled out. I monitors the cores, they were all busy with 100% throughout calculation. $\endgroup$
    – 147875
    Oct 2, 2021 at 13:39
  • 2
    $\begingroup$ Try increasing the number of atoms and check how the wall clock time scales with the number of cores. $\endgroup$
    – PBH
    Oct 2, 2021 at 13:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .