On Mon, Jul 26, 2010, istvan.kolossvary.hu wrote:
> Depending on your file system,
> etc., Desmond performance can be severely affected by I/O and thus
> biasing benchmark results.
OK...I'll try your cfg file with less I/O.
> I also noticed that RESPA schedule was set
> to 1:1:1 and I didn't change that. I don't know if PMEMD does multiple
> time step integration, but it is the normal way of running Desmond and
> with a 2 fs inner time step, the Desmond schedule should be 1:1:3,
> which runs about 25% faster.
This was deliberate: the benchmark on the Amber web site does not use a
multiple time step algorithm, so that seemed to be a fair comparison. Both
pmemd and desmond can be sped up by using a multiple time-step algorithm, but
then we would be looking at a different benchmark.
>
> You can set the global cell partition in the .cfg file to [0 0 0] in
> which case Desmond will figure out the ideal spatial decomposition
> based on the number of CPUs requested.
Good to know...I had missed that option.
>
> When you say using 16 *threads*, did you mean 16 processes/cores? This
> is what you set with the -P option.
I'm not sure what the "this" refers to in your final sentence. The
machine I was using has 8 physical cores, but "cat /proc/cpuinfo" reports
16, since hyperthreading is turned on. Both pmemd and desmond perform
better if I ask for 16 processes (the same as threads, at least as I am
using the term) instead of 8; to be specific, I used "-P 16" for desmond,
and "mpirun -np 16" for pmemd. I will try "-P 8 -tpp 2" for desmond, but
hyperthreading makes the OS and programs act as though there were
really 16 cores. [Apologies for any loose language here: I really don't
know the correct words to use to give a good description of hyperthreaded
systems....]
Reminder: I don't want people to think these are serious benchmark
comparisons. My basic conclusion is what I have thought since the
original announcment of desmond results on commodity hardware: at low
amounts of parallelism, pmemd and desmond are not that different in
performance -- i.e. much less than a factor of 2. Of course, a 30-40%
speed difference can be important, and results at higher levels of
parallelism (probably) favor desmond by increasing amounts over pmemd.
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Jul 25 2010 - 20:00:03 PDT
