From: Jim Phillips (jim_at_ks.uiuc.edu)
Date: Wed Jun 15 2011 - 11:25:34 CDT
Whatever is meant by "Wall Clock" here it's probably not what you want to
measure. The total runtime of a simulation includes startup time as well
as the initial measurement and load balancing cycles. These are amortized
over a longer run but not a short benchmark-style run. This is why NAMD
prints several "Initial time:" and "Benchmark time:" lines, the latter
providing the best estimate of performance for the remained of the run.
You can also set outputTiming 100 to measure performance improvement or
degradation during the run.
Reporting benchmarks in time/step is also useful since latency is only
going to matter when you're running below 10ms/step.
-Jim
> The computers are on their own network and are connected via gigabit
> ethernet.
>
> This is what the data look like:
>
> n(CPU) Wall Clock n(CPU)*Wall Clock
> 18 63.21 1137
> 16 86.72 1387
> 12 84.79 1017
> 8 115.51 924
> 4 214.89 859
> 4(local) 209.20 836
>
> With a low number of cores the network version scales quite well, but
> the more cores are used the greater the penalty gets, approaching 30 %
> on all 18 cores. I suppose the latency that comes with TCP/IP is
> visible here. The hope is what with the Open-MX stack the scaling is
> better. Axel mentioned Open-MX/Open-MPI a few months ago but he hadn't
> tried.
>
> Thomas
>
>
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2012 - 23:20:27 CST