I think this debate would become a whole lot more controversial if SP were 48 bits, but while I suspect SP is perfectly adequate for unit cells <100 A per side, strange things start happening shortly thereafter without careful numerical analysis.
That and SHAKE just *wants* to be done in DP. I mean you can do it in SP, just like just about anything else, but it's a whole lot more work than the tiny O(n) amount of time you'll save doing so IMO.
It all comes down to dynamic range. Whenever you end up subtracting a relatively large number from a relatively small number, you run head-on into precision issues. SP only has ~7 sig figs. So, just by subtracting 0.xxxxx from yyy.yyyyy the result loses 2 of them. And 10^-5 is the approximate limit for accuracy in MD. Go any further down this path and you're begging for trouble IMO.
Of course, if you understand this, you can write complex newfangled code to work around this. But just try to explain this to someone without a good background in numerical analysis.
-----Original Message-----
From: amber-bounces.ambermd.org [mailto:amber-bounces.ambermd.org] On Behalf Of Robert Duke
Sent: Saturday, May 01, 2010 20:17
To: AMBER Mailing List
Subject: Re: [AMBER] size of real
The gain in performance, at least when I looked at it several years ago,
seemed relatively small for moving to 32 bit floats for pmemd (ca. pmemd 8).
In theory, you COULD cut the communications load in half by going to 4 bytes
on all transmitted data, but I got very little gain when I tried it. There
are several other MD codes that DO use a lower precision datatype, and I am
guessing that there are enough differences in the s/w architecture of the
codes that they can benefit from it enough to make it worthwhile (so I
believe that Shaw et al. use some sort of shorter fixed format - I have not
seen the code, and gromacs can be used with a 4 byte float). The Shaw code
may retain enough precision, but I have seen other code produce varying
results over several step timespans (basically, the rounding error can
become significant very quickly in making a trajectory nonreproducible). I
have always been of two opinions on this, both leading to retaining double
precision: 1) you should not drop precision unless you are certain it does
not have a detrimental effect on accuracy of your results, and 2) if
rounding error sends you on different trajectories in a matter of a few
steps, then it becomes a lot harder to validate the correctness of the
software. A final point: while I am somewhat obsessed with performance in
this code, if you sacrifice precision then you may be losing the ability to
discern problems in the forcefields and improve on them. For me, the real
significance in the enhanced performance is it allows adequate sampling to
get good statistics, but you need both good stats and sufficient accuracy; I
consider it an open research problem and I have advocated erring on the side
of caution. This is all in the realm of personal opinion, and I believe it
is more-or-less shared by a number of the amber developers (guys, feel free
to correct me if I am wrong...).
Regards - Bob Duke
----- Original Message -----
From: "Tom Joseph" <ttjoseph.gmail.com>
To: "AMBER Mailing List" <amber.ambermd.org>
Sent: Saturday, May 01, 2010 7:11 PM
Subject: Re: [AMBER] size of real
On a somewhat related topic: What would the performance/accuracy
tradeoff be like if sander/pmemd used 32-bit floats instead of 64-bit
doubles? How was the decision made to use 64 instead of 32 bits? Are
floats considered "safe" for MD codes? I ask purely out of
curiosity...
Thanks,
--Tom
2010/5/1 Robert Duke <rduke.email.unc.edu>:
> Should be ieee 754, 64 bits, ie. 8 bytes. I think maybe some of the crays
> in the past had a slightly different meaning; these days practically
> everything is intel ia32-or a derivative thereof-based, or itanium
> (disappearing), or ibm power chips. You specify intel below I believe.
> Intel does have an internal 80 bit format when you are in the registers; I
> expect that compiler options determine when this is used, but it can cut
> rounding error further. The thing is, once you store in memory or send dp
> over the net, you are back to 8 bytes. I have not recently done a lot of
> research on this, but that was the state of the world last time I
> looked...
> It was also true for the various now-essentially-defunct risc chips like
> MIPS and Alpha.
> Regards - Bob Duke
> ----- Original Message ----- From: "sop dadoun" <dadoun.sop.gmail.com>
> To: "AMBER Mailing List" <amber.ambermd.org>
> Sent: Saturday, May 01, 2010 6:14 PM
> Subject: Re: [AMBER] size of real
>
>
>> Hi,
>>
>> Thank you for your answers.
>> In fact, my question is about the width of "double precision" (64, 128 or
>> more bits ?)
>> Note : amber 8 , sander , ramd
>> Station : Intel(R) Pentium(R) 4 CPU 3.20GHz
>>
>> Best regards,
>> Sophie
>>
>>
>> 2010/5/1 Robert Duke <rduke.email.unc.edu>
>>
>>> All of pmemd just uses "double precision" instead of "real". The use of
>>> "double precision" is I think deprecated in the latest fortran
>>> standards,
>>> but it is really clear what you are doing, and they may deprecate the
>>> usage,
>>> but it is unlikely to go away, given the wide use. The whole "kind"
>>> system
>>> focuses on the range of values you can represent, which certainly is
>>> mathematically useful. But for a lot of computer-related issues, it is
>>> actually (at least to me) also useful to know how much storage is
>>> required.
>>> The two are related, but not precisely - depends on the exact nature of
>>> the
>>> number representation, especially for floating point, and also I think
>>> that
>>> there is an "at least" sense to "kind", so the compiler maker can just
>>> use
>>> more storage than required to represent a specified range.
>>> Regards - Bob Duke
>>> ----- Original Message ----- From: "Jason Swails"
>>> <jason.swails.gmail.com>
>>> To: "AMBER Mailing List" <amber.ambermd.org>
>>> Sent: Saturday, May 01, 2010 10:25 AM
>>> Subject: Re: [AMBER] size of real
>>>
>>>
>>>
>>> Hello,
>>>>
>>>> On Sat, May 1, 2010 at 9:03 AM, sop dadoun <dadoun.sop.gmail.com>
>>>> wrote:
>>>>
>>>> Dear amber users,
>>>>>
>>>>> I would like to know the size of real for a fortran program used in
>>>>> amber
>>>>> with Pentium 4 CPU.
>>>>>
>>>>>
>>>> Most amber programs include the file $AMBERHOME/include/dprec.h or .fh,
>>>> depending on what version of amber you're talking about. The precision
>>>> of
>>>> _REAL_ depends on the preprocessor flags that are given to (u)cpp.
>>>> Typically, though, they're double unless you modify something.
>>>>
>>>> All the best,
>>>> Jason
>>>>
>>>> Thanks you for rplying
>>>>
>>>>> Best regards,
>>>>> Sophie
>>>>> _______________________________________________
>>>>> AMBER mailing list
>>>>> AMBER.ambermd.org
>>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jason M. Swails
>>>> Quantum Theory Project,
>>>> University of Florida
>>>> Ph.D. Graduate Student
>>>> 352-392-4032
>>>> _______________________________________________
>>>> AMBER mailing list
>>>> AMBER.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun May 02 2010 - 11:30:03 PDT
