From: Jérôme Hénin (jerome.henin_at_ibpc.fr)
Date: Tue Jul 22 2014 - 11:20:56 CDT
Indeed. In some cases when colvars contain many atoms, the slowdown factor
could be latency due to increased communication, rather than colvar
computation on the master node. Possibly a combination of both.
On 22 July 2014 18:02, Axel Kohlmeyer <akohlmey_at_gmail.com> wrote:
> On Tue, Jul 22, 2014 at 11:56 AM, Aron Broom <broomsday_at_gmail.com> wrote:
> > This isn't surprising, there are two factors leading to your poorer than
> > average results:
> >
> > 1) The RMSD colvar is a particularly computationally intensive one,
> since it
> > not only requires the calculation of the RMSD, but also the alignment to
> the
> > reference at every step. If you redo this test with a simpler colvar
> like
> > distance, or something intermediate like radius of gyration, you'll get
> much
> > less slow-down.
> >
> > 2) You are using a lot of cores. The colvar calculation occurs (at least
> > the last time I looked into these things) on a single core, so its speed
> is
> > more or less set and is a kind of upper limit on what you can expect. So
> > when you add cores to the rest of the calculation, you eventually hit the
> > wall at how long the colvar calculation takes.
>
> yup. one cannot repeat the lessons of amdahl's law often enough. it is
> not the parallel part of a program that decides its maximal speed when
> run in parallel, but the serial parts.
>
> http://en.wikipedia.org/wiki/Amdahl%27s_law
>
>
> >
> > If you want to improve things, don't use so many atoms in the colvar.
> For
> > instance, you could use just the C-alphas, or even every other or every
> > third C-alpha. This will likely give you a dramatic improvement.
> >
> >
> >
> >
> > On Tue, Jul 22, 2014 at 9:41 AM, Ivan Gregoretti <ivangreg_at_gmail.com>
> wrote:
> >>
> >> Thank you Jérôme.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Jul 22, 2014 at 8:44 AM, Branko <bdrakuli_at_chem.bg.ac.rs> wrote:
> >> > George.
> >> >
> >> > I never observed such drastic difference when I have used colvars
> (most
> >> > often distance and rgyr in NAMD 2.8 and 2.9). It is advisable to check
> >> > your
> >> > input and the scalability of system with and without colvars So do not
> >> > check
> >> > just benchmark time, but also wallclock and CPU time after some short
> >> > simulation. Generally 256 processors with 258000 atoms could be too
> >> > much...
> >> >
> >> > Branko
> >> >
> >> >
> >> >
> >> > On 7/22/2014 2:33 PM, Ivan Gregoretti wrote:
> >> >>
> >> >> Hi Jérôme,
> >> >>
> >> >> Could you expand your answer a little bit?
> >> >>
> >> >> Thank you,
> >> >>
> >> >> Ivan
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Jul 22, 2014 at 7:56 AM, Jérôme Hénin <jerome.henin_at_ibpc.fr>
> >> >> wrote:
> >> >>>
> >> >>> That is completely dependent on what variables you define, how many
> >> >>> atoms
> >> >>> are involved, and the biases.
> >> >>>
> >> >>> Jerome
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On 22 July 2014 13:27, George Patargias <gpat_at_bioacademy.gr> wrote:
> >> >>>>
> >> >>>> Hello,
> >> >>>>
> >> >>>> I am comparing the Benchmark times for a given system (~258,000
> >> >>>> atoms)
> >> >>>> using
> >> >>>> NAMD_CVS-2014-06-02_Source version with and without the colvar
> module
> >> >>>> on.
> >> >>>>
> >> >>>> When the colvar module is *off* (equilibrium MD), I get something
> >> >>>> like
> >> >>>>
> >> >>>> Benchmark time: 256 CPUs 0.0268481 s/step 0.155371 days/ns 540.59
> MB
> >> >>>> memory
> >> >>>>
> >> >>>> When the colvar module is *on* (moving harmonic restraint on an
> RMSD
> >> >>>> colvar calculated from 1981 C-alpha atoms), I get
> >> >>>>
> >> >>>> Benchmark time: 256 CPUs 0.320515 s/step 1.85483 days/ns 569.555 MB
> >> >>>> memory
> >> >>>>
> >> >>>> which is 11-12 times slower.
> >> >>>>
> >> >>>> Is this the actual computational cost of a colvar calculation?
> >> >>>>
> >> >>>> Also the scaling of this particular colvar calculation is not good:
> >> >>>>
> >> >>>> Benchmark time: 48 CPUs 0.331787 s/step 1.92006 days/ns
> >> >>>> Benchmark time: 128 CPUs 0.322472 s/step 1.86616 days/ns
> >> >>>> Benchmark time: 256 CPUs 0.320515 s/step 1.85483 days/ns
> >> >>>>
> >> >>>> Thanks in advance!
> >> >>>>
> >> >>>> George
> >> >>>>
> >> >>>> Dr. George Patargias
> >> >>>> Postdoctoral Research Fellow
> >> >>>> Biomedical Research Foundation
> >> >>>> Academy of Athens
> >> >>>> 4, Soranou Ephessiou
> >> >>>> 115 27
> >> >>>> Athens
> >> >>>> Greece
> >> >>>>
> >> >>>> Office: +302106597568
> >> >>>>
> >> >
> >>
> >
> >
> >
> > --
> > Aron Broom M.Sc
> > PhD Student
> > Department of Chemistry
> > University of Waterloo
>
>
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0
> College of Science & Technology, Temple University, Philadelphia PA, USA
> International Centre for Theoretical Physics, Trieste. Italy.
>
>
This archive was generated by hypermail 2.1.6 : Thu Dec 31 2015 - 23:21:01 CST