Difference between revisions of "Colliders performace"

From Yade

Line 42: Line 42:
   
 
[[File:ColliderTimesOptimal.png]]
 
[[File:ColliderTimesOptimal.png]]
  +
  +
=== Comparison on scripts/test/performance/checkPerf.py ===
  +
  +
* bzr2915
  +
5037 spheres, velocity= 110.359344232 +- 0.16947155531 %<br>
  +
25103 spheres, velocity= 27.4394736967 +- 1.47630822246 %<br>
  +
50250 spheres, velocity= 19.0980032815 +- 0.126775658881 %<br>
  +
100467 spheres, velocity= 9.22476120323 +- 0.174335620671 %<br>
  +
200813 spheres, velocity= 2.15555271381 +- 1.26679585962 %
  +
  +
* candidate code
  +
5037 spheres, velocity= 139.354078689 +- 0.22421460436 %<br>
  +
25103 spheres, velocity= 34.2937046476 +- 1.06545521486 %<br>
  +
50250 spheres, velocity= 19.6416457779 +- 1.8690151127 %<br>
  +
100467 spheres, velocity= 9.66142407162 +- 1.00938117431 %<br>
  +
200813 spheres, velocity= 4.02108768995 +- 0.960493684787 %

Revision as of 08:27, 21 September 2011

Results

This graph shows

  • "init": time for the first step
  • "step": average time for next 100 steps (normalized per step)
  • I had to put time for first step of PersistentSAPCollider to log scale.
  • Machine: Intel i7 2.7GHz, DDR3 RAM

Colliders-perf.svg

  • SpatialQuickSortCollider scaled with N^2 and is (significantly) slower, especially for big packings; the initial step is not significantly longer that regular step.
  • PersistentSAPCollider scales with something over N×log N. The first step is significantly slower than the next ones.
  • InsertionSortCollider scales the same as PersistentSAPCollider, but in absolute numbers is about 50% faster in regular steps and over 10x (!!) faster on the initial step.

Running

$ cd examples/collider-perf
$ export OMP_NUM_THREADS=1 # to make sure, for openMP-enabled builds
$ yade-trunk-opt-multi perf.table perf.py
$ python mkGraph.py *.log

Other machines

  • Machine: AMD Athlon(tm) XP 2100+, 1.7GHz

Colliders-gl.svg

  • Machine: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz

Xeon233 collider-perf.png

TODO (post your graphs here, with machine description)


Improved InsertionSort

Results obtained with a modified version of the insertion sort collider are given below (5000 iterations in the initial phase of an isotropic confinement, single thread, Intel(R) Xeon(R) CPU W3530 @ 2.80GHz). The code is candidate for release (https://code.launchpad.net/~bruno-chareyre/yade/collide2).

As opposed to the results above, the times are given per simulation step, not per execution of the collider::action(). The speedup approaches x10 for 96k spheres. The speedup in terms of total time for one step is slightly higher than x2. It's observed that very large Verlet distance can be used, while the optimum is always near 0.07 for r2915).

The improvement is more sensible in multithread runs, since the modified version keeps the ratio of costs collider/interaction loop small. With 96k particles and the larger Verlet distance, the collider gives 16% of the total cpu time (initial step excluded).


ColliderTimes.png

ColliderTimesOptimal.png

Comparison on scripts/test/performance/checkPerf.py

  • bzr2915

5037 spheres, velocity= 110.359344232 +- 0.16947155531 %
25103 spheres, velocity= 27.4394736967 +- 1.47630822246 %
50250 spheres, velocity= 19.0980032815 +- 0.126775658881 %
100467 spheres, velocity= 9.22476120323 +- 0.174335620671 %
200813 spheres, velocity= 2.15555271381 +- 1.26679585962 %

  • candidate code

5037 spheres, velocity= 139.354078689 +- 0.22421460436 %
25103 spheres, velocity= 34.2937046476 +- 1.06545521486 %
50250 spheres, velocity= 19.6416457779 +- 1.8690151127 %
100467 spheres, velocity= 9.66142407162 +- 1.00938117431 %
200813 spheres, velocity= 4.02108768995 +- 0.960493684787 %