Oh, and regarding Knuth, he is of course right. The problem with
optimization work is it always adds complexity and causes you to tromp all
over all sorts of solid software engineering principles. So you shouldn't
do it until you know you have to, because it can lead to all sorts of
grief - slipped schedules, bugs, outright project failures. But there are
some things where you know you need performance, and that is the domain I am
living in (heck, I have been working in this exact domain for years - I am
completely bored with just getting functionality, and very early on in
industry I specialized in handling the code where performance limitations
were an issue). So it is a really good idea for you guys to hack out some
reasonably clean software (please) that gets the science right, and for me
to come in and say, well, if I make this stuff impossible to understand,
then not only will nobody figure out how to copy it, but it will be 10x
faster ;-) (just a joke - that impossible to understand part).
Best - Bob
----- Original Message -----
From: "Scott Brozell" <sbrozell.scripps.edu>
To: <amber-developers.scripps.edu>
Sent: Thursday, March 01, 2007 4:17 PM
Subject: Re: amber-developers: amber performance
> Hi,
>
> If Dave's comments are only worth $0.02 then mine surely will be
> valueless, due to inflation, by the time you finish reading this :)
>
> I started the sunday night conversation between Ross, Tom C, and Mike
> because I am an Amber representative and I do not have enough expertise
> to explain in detail to people like Kent Milfeld and other higher ups
> why the well advertised NAMD and Gromacs are not the best performing MD
> codes. Of course, I can mention throughput vs scaling and everybody gets
> it, but the tradeoffs between single and double precision vis-a-vis
> energy conservation, and other good vs dubious science issues are
> more involved.
>
> Thus, I think that we do need publications, not just benchmarks,
> that underscore the tradeoffs. I see the pedagogical value of such
> work as much greater than its Amber advertising value.
>
> Scott
>
> ps and in the category of free advice,
>
> It reads like Bob has quite a bit of work that could be
> published - this could be a case of not following Knuth's quote:
> Premature optimization is the root of all evil.
> In other words, you may due more communal good by publishing than
> optimizing pmemd for feature x on platform y or beating namd
> performance yet again.
>
>
> On Thu, 1 Mar 2007, David A. Case wrote:
>
>> On Wed, Feb 28, 2007, Ross Walker wrote:
>> >
>> > Tom C and I spent some time talking about this on Sunday evening. We
>> > pretty
>> > much came to the conclusion that we want to do is design a series of
>> > calculations that attempt to address the various issues that people
>> > simply
>> > "believe" at present. I.e. find something that is sensitive to single
>> > vs
>> > double precision and see if we can address whether single precision is
>> > okay
>> > or not.
>>
>> In my view, this could very easily become a time sink where you don't get
>> any definitive results and just waste time and create controvesy. The
>> way in
>> which gromacs and desmond use single precision is quite different, and
>> both
>> would be different from trying to compile sander in single precision.
>>
>>
>> > In addition we thought about answering PME vs force switch
>> > simulations. Here a salt water solution simulation might be useful as
>> > this
>> > would be an extreme test of the electrostatics and we could address
>> > whether
>> > a force switch cutoff is actually okay or if you really need pme.
>>
>> Bob has already answered this, pointing out quite eloquently ways in
>> which
>> this could become another wild-goose chase. And, since he already has so
>> much
>> data in this area, starting some new effort here doesn't seem very
>> productive.
>>
>> >
>> > A straight benchmark paper is unlikely to get published so I think
>> > wrapping
>> > it up in a paper that attempts to address issues regarding PME, time
>> > step,
>> > single vs double precision etc is a good way to go.
>>
>> We don't necessarily need a paper on benchmarks: a good web site that
>> collects
>> numbers we already have lying around (plus some new calculations) would
>> go a
>> long way in my view. A key need: someone in the Amber community needs to
>> be
>> able to run gromacs and namd, so we can do our own side-by-side
>> comparisons.
>>
>> The usual $.02 disclaimers go here.
>
Received on Sun Mar 04 2007 - 06:07:46 PST
