This page summarises some results for the performance test of YADE (yade --performance) on multicore machines. It should give an idea on how good YADE scales.
Two versions of YADE are compared to each other and two different machines are used. The test was conducted on the computing grid of the University of Newcastle by Klaus.
- version1 (trunk): 2014-01-25.git-22c2441
- version2 (see https://lists.launchpad.net/yade-dev/msg10498.html): 2014-02-24.git-b60d388
- AMD: AMD Opteron(tm) Processor 6282 SE (64 cores)
- Intel: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (16 cores)
- Red Hat Enterprise Linux Server release 6.4 (Santiago)
- gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
- Number of tests per data point in plots: 10
Performance of Parallel Collider
Fig. 1.1 shows how version2 (parallel collider) scales in relation to version1 (NOTE: version1/version2 indicates how much faster the parallel collider is). It is interesting to note that for simulations with less than 100000 particles the scaling is almost not depending on the number of threads and scaling is slightly bigger than one only. For simulations with more than 100000 particles things are looking differently.
Using the total number of cores on the machine is not recommended, e.g. -j12 (and probably -j14) scales better than -j16 on the Intel and -j24 scales better than -j32 on the AMD.
Figs. 1.2-1.3 show the absolute speed in iterations per seconds for both versions on both machines. It can clearly be seen that the lines for the parallel collider on the right are almost shifted parallel whereas the lines for version1 converge at the 500000 particle point. This means that the parallel collider does not just allow for better scaling (i.e. faster calculation) but as well for more particle to be used in a simulation.
Sample output from Timing
Sample output for timing for -j12 on Intel:
Fig. 1.4 shows the difference between running version1 and version2 on an Intel or AMD machine. The AMD is generally slower (Intel/AMD>1).
The new parallel collider scales good for the --performance test with more than 100000 particles. The scaling for 500000 particles is really good, i.e. -j12 scales by a factor of 6 for both machines. Intel machines perform better (similar observations have been made here ). Finally, I would say that there is an optimum number of threads you should use per simulation. Many cores doesn't always mean much faster. So use your resources wisely.
Finally, it should be mentioned that the results for 500000 particles are extrapolated from 10 iterations since this is the value in the current script. This is far too optimistic. I will post more realistic results soon.
Same as Test 1 but with more iterations (1x, 3x and 12x the number of iterations specified in checkPerf.py) and more particles (up to 1 million). However, 3 simulations per data point only. A summary of the full series of results can be downloaded here . All relevant data files and timing stats can be downloaded here .
Performance of Parallel Collider
The following figures show the cundall number for both versions. It can be seen that the estimated scaling gets worst when increasing the number of iterations. Nevertheless, the graphs show a more stable Cundall number for the new implementation with the parllel collider.
Some output from Timing
Timing output for -j8 on Intel for various iterations (1x, 3x and 12x the number of iterations specified in checkPerf.py):
And here a summary of the scaling of the new parallel collider for 1 million particles for different threads. The scaling factor is calculated by dividing the absolute time of the InsertionSortCollider for j1 by the absolute time of the InsertionSortCollider for j>1. The timings are taken from the last simulation of base iterations x12 (iterx12). The collider is called 46 times. For full timing stats see files in .
Results indicate again that there is an optimum number of threads. It might be best to try a couple of configurations first since it will certainly be problem dependent.
The timing stats suggest that InteractionLoop and NewtonIntegrator are becoming the bottle neck now.
TODO some more real example, feel free to add something...