[gmx-users] Some Scaling of 5.0 Results

Dallas Warren Dallas.Warren at monash.edu
Tue Sep 23 01:33:36 CEST 2014


Mark,

> Thanks for sharing. Since the best way to write code that scales well is to
> write code that runs slowly, we generally prefer to look at raw ns/day.
> Choosing between perfect scaling of implementation A at 10 ns/day and
> imperfect scaling of implementation B starting at 50 ns/day is a
> no-brainer, but only if you know the throughput.

Though from an end user point of view, CPU hours are things not to be wasted, so efficiency tends to be more important.

> I'd also be very suspicious of your single-core result, based on your
> super-linear scaling. When using a number of cores smaller than a node, you
> need to take care to pin that thread (mdrun -pin on), and not having other
> processes also running on that core/node. If that result is noisy because
> it ran into different other stuff over time, then every "scaling" data
> point is affected.

Had been wondering about that for awhile and had not looked into it.  Did think that might be the reason for the super scaling, will get back to testing that (and all the other options) once this quarter is over.  As I am sure you are aware, end of quarter equals very heavy loads on clusters as people try to use up their quota.

> Also, to observe the scaling benefits of the Verlet scheme, you have to get
> involved with using OpenMP as the core count gets higher, since the whole
> point is that it permits more than one core to share the work of a domain,
> and the (short-ranged part of the) group scheme hasn't been implemented to
> do that. Since you don't mention OpenMP, you're probably not using it ;-)

Yep, that would be right.  Another option that I need to look into.

This was meant to be a starting point, basic system, simple settings, then work through the other various options that I knew someone would pipe up with :) and that I had ignored.  Also need to get a script written to automate this scaling testing, making it easier and faster to test all the various options that can be used.

> Similarly, the group scheme is unbuffered by default, so it's an
> apples-and-oranges comparison unless you state what buffer you used
> there.

Catch ya,

Dr. Dallas Warren
Drug Delivery, Disposition and Dynamics
Monash Institute of Pharmaceutical Sciences, Monash University
381 Royal Parade, Parkville VIC 3052
dallas.warren at monash.edu
+61 3 9903 9304
---------------------------------
When the only tool you own is a hammer, every problem begins to resemble a nail.


More information about the gromacs.org_gmx-users mailing list