I'm going to be doing some weak scaling of an $N$-body integrator on AWS. In the past when I've done weak scaling for this integrator I've fixed the number of particles per core ($N/n = {\rm const}$).

However, when I do this I get a weak scaling that is proportional to $n^\alpha$ where $n$ is the number of cores, which is tied to $N$, and $\alpha \geq 1$. This is because the number of calculations involved in the $N$-body simulations is $N^2$. Thus, when I double the number of cores, I also double the number of particles, which actually quadruples the work. Therefore, I get an a scaling that is at least linear in $n$.

My understanding of weak scaling is that you're supposed to fix the problem size per core. In this case, is it more correct for me to fix the work per core than the number of particles per core?


One can define weak scaling in many different ways:

  • Amount of work per processor stays the same
  • Amount of communication per processor stays the same
  • Amount of memory usage per processor stays the same.
  • Number of objects per processor stays the same.

In many cases, all of these will amount to the same, notably if the amount of work, memory, and communication is proportional to the number of objects. But in some cases it is not. In those cases, choose one of these definitions and be clear in your description what you are doing.

(As a complete aside, for $N$-body simulations, you should really be using something like the multipole expansion to avoid the $N^2$ bottleneck...)

  • $\begingroup$ Thanks for the reply. I think that fixing work per processor is the best choice here. Unfortunately, I study large N near-Keplerian systems where multipole expansions are both too inaccurate and too slow to be used. Multipole methods scale better but only in the limit of $N \rightarrow \infty$. For the order 1000 particles I'm simulating, the direct method is faster. $\endgroup$ – Alex Apr 17 at 22:18
  • $\begingroup$ Hi. you might also gain some insight by benchmarking your codebase with respect to what your bottleneck is. Is the communication taking longer than the calculations per node? is your code memory-bound? etc. That might give you a better feel for the parallelization strategy. That sweetspot is highly machine/cluster dependent. If the AWS machines have fast comm but slow cpu's you should choose a smaller number of particles per cpu and vice versa. $\endgroup$ – MPIchael Apr 24 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.