Rounding error problems

Accelerated Computing CUDA CUDA Programming and Performance
#21

You cannot, in general, make the error of a floating-point computation zero when it should be zero mathematically. However, the use of IEEE-754 arithmetic in round-to-nearest-or-even mode should make the error statistically unbiased, and this should help with avoiding long-term temperature drift in your simulation.

As for the floating-point literals, a good strategy to maximize the accuracy of a computation is to use x-precision floating-point literals when using x-precision floating-point operations. Why throw away useful bits needlessly?

#22

Thanks for the suggestions. I can only hope now that the error will not affect the results. There are other terms in the model which might help damp the errors… i will keep in mind the suggestions. I should never throw away bits needlessly . This kind puts a pin on my plans to make the final code to make it faster by using single precision for the positions ans for some operations.

#23

I do not know what kind of molecular dynamics you are doing, but the experience of the AMBER teams seems to be that you cannot just drop down to single precision for everything. Some key pieces of data need to be presented with higher precision. That does not need to be double precision: it could be a double-float representation, or 64-bit fixed point (which is what AMBER uses at present, best I know).

The difficulty with mixed-precision approaches is finding out where exactly precision can be sacrificed in the name of performance, and where that is not possible. The AMBER team is full of people with extensive domain and software optimization experience, and it took them a considerable amount of time to figure the correct mix of low-precision and higher-precision computation.

I think GROMACS is also almost entirely single-precision computation, so converting the vast majority of computations into single precision, while maintaining reliable results, is definitely possible. It just takes work.