float vs double

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
-=Magic=-
Posts: 41
Joined: Thu Jun 30, 2011 11:32 am

float vs double

Post by -=Magic=- »

I saw that there's a fork with double type.

But what's the main difference? I mean, why the main release doesn't use double type? is there some potential-issue with it?

Also, is it possible to have the .fx of the instancedEffect ? (the one inside resources.resx into DebugDrawer project)
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: float vs double

Post by Norbo »

But what's the main difference? I mean, why the main release doesn't use double type? is there some potential-issue with it?
The reasons doubles have not been used/are not used in the main branch are:
1) Historically, XNA used single precision, and BEPUphysics started as an XNA-centric project. BEPUutilities started as a mostly in-place replacement for XNA types (though it has since diverged in some ways).
2) Single precision values are easier to feed to the GPU. GPUs do not tolerate double precision input data well; they suffer massive penalties. Compensating for this fact would introduce a lot of translation between CPU data and GPU data. While this translation can be computationally cheap since you only really need to do it on a per-object-transform basis, it still introduces software complexity that doesn't usually need to exist.
3) When it comes to numerical robustness, single precision is 'enough' for representing everything except planet sized positions. Double precision doesn't automatically increase the quality of numerically stable implementations of GJK or MPR, for example, without doing deeper iterations and spending more CPU time.
4) While the performance of individual non-SIMD floating point operations are similar with single or double precision, doubles are inherently larger and increase memory pressure. This doesn't really matter in terms of total memory capacity, but only half as many doubles can fit within a cache line. (This factor, while important at the limits of optimization, is not hugely significant in many of BEPUphysics's systems today due to stall-prone implementations. However, as I gradually pick all of the low hanging fruit, it will become more important.)
5) With RyuJIT and .NET native optimizing compilation around the corner, being able to fit as many values as possible into the SIMD instruction width is important for throughput. 128 bit instructions can handle 4 singles, but only 2 doubles.
Also, is it possible to have the .fx of the instancedEffect ? (the one inside resources.resx into DebugDrawer project)
Yup. The shader source is in the BEPUphysicsDemosContent project.
Post Reply