|
|
The following plots are an attempt to understand why we scale less well now we have multi-dt.
|
|
|
|
|
|
The test was a run of the master branch (at a4cb085a878f, 6/10/2016) on the `EAGLE_25`
|
|
|
volume (50 million particles) for 2000 steps using the default `run.sh` script, producing the usual `timesteps_12.txt` file.
|
|
|
|
|
|
First we show a plot of the number of particles updated per time step against
|
|
|
the time taken per time step (both axes are log'd).
|
|
|
|
|
|
![eagle_25-12cores-fig1](/uploads/853bd315db46189dcdfdc85c49540a72/eagle_25-12cores-fig1.png)
|
|
|
|
|
|
The interesting thing is that we are linear down to ~1000 particles, at which
|
|
|
point we don't get much faster for fewer particles.
|
|
|
|
|
|
This matters because:
|
|
|
|
|
|
![eagle_25-12cores-fig2](/uploads/ceb90848f131bbce715e16e7af85ba97/eagle_25-12cores-fig2.png)
|
|
|
|
|
|
which is a cumulative histogram of updated particles, so we see that ~1000 particle updates
|
|
|
and less account for half the time steps.
|
|
|
|
|
|
Richard and I have concluded that this is best explained by the fact that the number
|
|
|
of tasks (need a plot to prove this), a proxy for cells, is roughly the same for
|
|
|
these steps. So we are processing the same number of cells... |
|
|
\ No newline at end of file |