From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Mon Oct 26 2009 - 08:16:55 CDT
On Mon, 2009-10-26 at 02:10 -0300, Bernardo Sosa Padilla Araujo wrote:
> I have a question regarding the benchmark.
> NAMD scalability might be significantly different for two different
the differences can be even more drastic when using different
features. for example, if you make excessive use of tcl_forces,
then your scaling might seriously affected.
> systems. Right? If it is so, why would be important to run the
> benchmark apoa1 if you are going to be working with a different
well, there are three main reasons to run benchmarks.
1) to document the performance and scalability of a software
2) to find the optimal performance for a given problem
3) to validate that a specific machine is performing as expected.
in this case, it is most likely that it is about 3).
i've seen emails from a person by the same name before...
> system? It is just to compare to the performance that other people
that is the main use. if you have a machine with similar processors
and similar network, it should run at a similar performance. if it
does not, there is something very, very wrong and you have to find
> get with NAMD? Then if that is the case, for any system I would have
> to run some kind of benchmark to see how scalable is NAMD in that
> particular case. Right?
well, the performance graph on the NAMD homepage shows the so-called
strong scaling behavior of NAMD, i.e. how much faster can you run a
given input on a system. if you'd combine this with a graph on weak
scaling, i.e. how fast does it run with n times the size input on
n times the number of processor cores, then you could pretty much
extrapolate a ballpark number for how different size systems should
perform on different machines.
in any case, if you want to run NAMD optimally for a given input,
there is no alternative to run a scaling test with exactly that
input and different performance related options. the latter can be
pretty tricky, because often options that make a code execute faster,
are connected with some additional approximations or larger errors,
so one has to find a compromise between performance and correctness.
as a reminder to everybody, some scaling tests with NAMD should
indeed _always_ be made, since there are many details that can
affect scaling and with NAMD the performance will drop significantly
if you overshoot, i.e. you use too many processors. as usual, more
does not always help more.
> I hope someone can answer my questions.
> Thanks in advance.
> 2009/10/25 Axel Kohlmeyer <akohlmey_at_gmail.com>
> On Sun, 2009-10-25 at 12:16 +0530, Sangamesh B wrote:
> > Dear Sir,
> > taking
> > > very little time 3-4 minutes to complete(with 4
> cores), but
> > on the
> > > website its shown its taking 4days to complete.
> > please explain where it says that it takes this
> > The graph shown on the following webpage
> > http://www.ks.uiuc.edu/Research/namd/performance.html
> please polish your reading glasses. this graph does not at all
> say so.
> please check out what which lines mean. the left y-axis shows
> strong scaling performance, by multiplying the time per time
> step with
> the number of cores, i.e. you get a horizontal line with ideal
> the diagonal lines are to show you the throughput by
> indicating how
> long it would take to generate one nanosecond of trajectory.
> > From this graph I understood - 1 week for 4 processor job, 4
> days for
> > 8 processor job etc
> to produce _1 nanosecond_ of data, not 500 femtoseconds.
> > the input does just a few hundred steps. any
> > that would need 4 days to complete is very
> > Also the graph says, namd scales upto 256 cores. But in may
> case, its
> > taking very less time and not scaling beyond 24 cores.
> if you cannot scale beyond 24 cores, then you either must be
> doing something wrong, or there is something not working well
> with your hardware.
> > > May I know what mistake am doing here?
> > you are must be misreading something.
> > > On the website, there is no info provided about
> how to do
> > the
> > > benchmark.
> > you just run it like any other namd input.
> > for a bigger problem size namd input, upto what number of
> cores will
> > NAMD scale?
> thousands. there are some tricks required. you may need a
> hardware with very low latency communication and little OS
> check out the namd wiki for details.
> > axel.
> > > Thanks
> > >
> > >
> > --
> > Dr. Axel Kohlmeyer akohlmey_at_gmail.com
> > Institute for Computational Molecular Science
> > College of Science and Technology
> > Temple University, Philadelphia PA, USA.
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com
> Institute for Computational Molecular Science
> College of Science and Technology
> Temple University, Philadelphia PA, USA.
-- Dr. Axel Kohlmeyer akohlmey_at_gmail.com Institute for Computational Molecular Science College of Science and Technology Temple University, Philadelphia PA, USA.
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 05:22:29 CST