We're getting a little OT here, so I branched the thread
On Mon, May 26, 2014 at 5:09 PM, Robert McGibbon <rmcgibbo.gmail.com> wrote:
>
> > OpenMM-Python suffers from frequent I/O
>
> > OpenMM incurs a lot of overhead from the builtin dimensional analysis and
>
> the time spent in the Python interpreter.
>
>
>
> I don't think these statements are accurate. You can easily check by not
>
> attaching any reporters to a simulation, or running context.step() directly
>
> without a simulation object. But I'm a little biased. Perhaps another forum
>
> would be more appropriate to discuss it in though.
>
The first statement (OpenMM-Python suffers from frequent I/O) is definitely
accurate. The overhead of manipulating data in Python and the overhead of
OpenMM-Python's dimensional analysis is expensive. The slowdown relative
to "peak performance" (i.e., no printouts) of OpenMM-Python when writing a
trajectory snapshot every step is much more pronounced than the slowdown of
any compiled program (sander, pmemd, OpenMM-accelerated sander, etc.).
I've verified this directly with my own benchmarks and tests. [1]
The only trick you mentioned that gets rid of additional OpenMM-Python
overhead entirely in the simulation is calling step on the context (really
the context.integrator) directly, but for an OpenMM beginner (especially
coming only from experience with Amber), this is non-obvious. Even a
Simulation object with no reporters has _some_ additional Python overhead
introduced by taking only 10 steps at a time. [2]
All the best,
Jason
[1] This is hardly a strike against OpenMM -- in fact quite the opposite.
OpenMM will always be (possibly negligibly) faster than the Python
application layer reports due to this overhead. A more fair performance
comparison, strictly speaking, would be between pmemd.cuda and an
OpenMM-accelerated version of sander or pmemd (although you can get to a
fair comparison in the Python layer if you were careful).
[2] I have never measured this cost. It could easily be completely
negligible for any system of any size. I just don't know
(order-of-magnitude estimates here are complicated by jumping between
Python and C/C++)...
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon May 26 2014 - 16:00:02 PDT
