Yong -
Don't fret about the ntwx 250; it is a matter of history, and as we move
forward we can change it to look more competitive. I have kept the values
so far in the factor ix benchmark for backward compatibility with older
results. Also, by cranking the write frequency up, I actually am actively
looking to push the disk i/o a bit harder to see where it will be a
bottleneck (so if I can get away with ntwx 250 at 300 processors, then I
should be able to get away with ntwx 1000 on 1200 processors). I do feel
that it is really only a fair benchmark if you DO write a trajectory though,
as most folks want at least a trajectory. If we handle our file i/o
efficiently, then we can end up having a competitive advantage here (so the
guys competing against us need to write trajectories too).
Regards - Bob
----- Original Message -----
From: "Yong Duan" <duan.ucdavis.edu>
To: <amber-developers.scripps.edu>
Sent: Wednesday, February 28, 2007 6:13 PM
Subject: RE: amber-developers: amber performance
>
> On the issue of comparison to other packages/programs, I think it makes
> sense to publish a set of comparison using throughput (rather than the
> dubious feeling-good scaling).
>
> Although I am pretty sure Bob and everybody else has considered this,
> please
> use a more realistic ntwx. 250-step/frame is just not the thing we do any
> more (was probably common 20 years ago). This has absolutely nothing to do
> with the notion of being "honest" or not. Ntwx=250 is just not realistic.
> In
> fact, if my students save the frames that often he/she likely receives a
> long and torturous lecture from me demanding an explanation.
>
>
> yong
>
> -----Original Message-----
> From: owner-amber-developers.scripps.edu
> [mailto:owner-amber-developers.scripps.edu] On Behalf Of Robert Duke
> Sent: Wednesday, February 28, 2007 2:59 PM
> To: amber-developers.scripps.edu
> Subject: Re: amber-developers: amber performance
>
>
> Scott -
> Great! I will be working for a little bit to get tip4p (actually I will
> probably just go ahead and do full extra pnts support), remd, ti into a
> checked in version of pmemd so the various amber developers can start
> reaping the benefits; then I will go back to pushing performance and can
> have pieces of that available for "pmemd 10 beta" performance comparison.
> Right now, the code base I have is not significantly faster than 9; I have
> been spending time on design issues, ff validity, electrostatic methods
> validity, etc. But I'll have some of this stuff working hopefully before
> too long.
> Best Regards - Bob
>
> ----- Original Message -----
> From: "Scott Brozell" <sbrozell.scripps.edu>
> To: <amber-developers.scripps.edu>
> Sent: Wednesday, February 28, 2007 5:24 PM
> Subject: amber-developers: amber performance
>
>
>> Hi,
>>
>> Today Kent Milfeld from TACC asked me about amber performance because
>> he saw that there is work underway for charmm's performance.
>> I told him about pmemd (which he had never heard of), namd, gromacs, etc.
>> He was very receptive to the idea that namd has great advertising
>> and might not be targeting the best science.
>>
>> This follows on the discussion we had at the amber meeting regarding
>> a publication on good vs dubious science, pmemd, single vs double
>> precision,
>> scaling vs throughput, etc. I hope that the ball will be rolling soon.
>> And I'm happy to help out.
>>
>> Scott
>>
>>
>>
>
>
>
Received on Sun Mar 04 2007 - 06:07:26 PST
