RE: amber-developers: amber performance

From: Ross Walker <ross.rosswalker.co.uk>
Date: Thu, 1 Mar 2007 07:52:10 -0800

> taking a very quick eyeball look at temperature drift
> "without constraints"
> (I presume this means nve effectively), they drift
> temperature a whopping
> 2.0 degrees K per nsec (namd drifts 2.8 K per nsec). I was
> surprised by
> this (I am looking at table 5), and maybe I don't understand
> something.
> However, in testing out my cutoff methods, I did a bunch of
> NVE energy drift
> checks. I did checks on a dna 12mer in a 70 angstrom box.
> For pme, I had a
> 0.21 degree drift in 5 nsec, or 0.04 degrees K per nsec.

Indeed, this same point was made by the IBM Blue Matter guy who gave the
talk after the DE Shaw guy at Supercomputing. He was royally pissed and
probably with good reason as the talk before just trounced all over his Blue
Matter code but with little hard evidence. Besides take a look at the
Benchmark plot again. The Blue Matter code matches the DE Shaw code for
total throughput. It just needs more cpus because Blue Gene is
slooowwwww.... But from the talk you'd have thought that the Desmond code
had solved it all and was faster than anything else. Something that just
isn't true and requires some creative benchmarking to show - I.e. compare
apples and oranges.

Anyway, the guy from IBM said they validate against amber and charmm and
that 0.05 K/nsec drift is the maximum they ever except. He showed a nice
plot of what happens to your temperature over 200ns run (just over a days
simulation if you are at 170ns/day) if you drift by 0.05K vs 2.0K.

I'm convinced the DE Shaw guys know this but didn't want to let on. The
paper is really an example of where you need to read between the lines. For
example note that they do a lot of benchmark comparissons with namd and Blue
Matter but then in table 5 which shows the energy drift they conveniently
only show namd numbers. I am actually shocked that namd is so bad more than
anything...

Also note that their communication pattern, described in Figure 4 is
completely non-standard. The mpi2 standard says nothing about the legality
of recieving a nonblocking send with a blocking receive. I am shocked that
it works at all. It may just be luck based on their mpi implementation and
switch but I would be amazed if it worked on any decent range of hardware.

Also note that they say Desmond uses distributed output files - something I
think we will be in need of in a year or so. Although such approaches will
make little difference on your average NFS mounted cluster disk... However,
also note that the benchmarks section makes no mention of writing to output
or trajectory files so I would suspect that there is no trajectory writing
going on here.

Just my 2c...

All the best
Ross

/\
\/
|\oss Walker

| HPC Consultant and Staff Scientist |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
| http://www.rosswalker.co.uk | PGP Key available on request |

Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
Received on Sun Mar 04 2007 - 06:07:39 PST
Custom Search