CLR and floating point: Some answers to common questions

re: CLR and floating point: Some answers to common questions

Chris Nahr — Tue, 09 Aug 2005 11:34:03 GMT

Why not educate the programmers about FP calculations instead? It's a well-known fact that FP variables must never be compared for equality, unless they result from a constant assignment. Otherwise, you must compare their absolute difference against an epsilon that represents the desired precision.

If you write FP code using crutches such as fp:precise or fp:strict you get poorly performing code that will break as soon as someone uses a different compiler or different compiler switches. I don't quite see the point, frankly -- other than perhaps reducing Microsoft's support incidents.

re: CLR and floating point: Some answers to common questions

Dmitriy — Tue, 09 Aug 2005 17:07:10 GMT

fp:precise or fp:strict is not crutches but makes wrighting "correct" code much easier.
Chris it just shows you never.

BTW 2 days before your blog I blogged on the same issue :)

David, could you explain some of the optimization desicisions and specifically why is it hard to inline value type members.

re: CLR and floating point: Some answers to common questions

davidnotario — Tue, 09 Aug 2005 18:52:52 GMT

Chris, the C++ story is better now than before. Pre Whidbey they wouldn't respect casts. At least now they don't do things like that.

Every time this issue comes up, we have to camps:

a) People that want the same floating point IL to give exactly the same results on all platforms and JITs.

b) People that want compilers to be able to take full advantage of the HW.

Both of these options are pretty extreme. a) is ideal, but not practical due to performance issues. Make b) too 'hard' for the developer and you are not offering a compelling platform. A similar decision has happened regarding the memory model of the CLR: a) would mean bad performance, b) as proposed by HW vendors (free write and read reordering) makes writing code for the platform very hard. What you really want is something that is easy to get right (so the platform is productive), but that doesn't leave performance on the table for advanced developers. I think C++ is closer to that model today for floating point with their /fp options: By default, the behavior is more coherent than in their previous versions, but it still has the /fp:fast option when you care more about speed.

re: CLR and floating point: Some answers to common questions

davidnotario — Tue, 09 Aug 2005 18:56:09 GMT

Dmitry:

It's not a design decision, it's a limitation in how the x86 JIT compiler was built which is expensive to fix now (ie, some major rehaul). It's on our radar, we hate that we have these limitations, but in a limited time budget, we have preferred to fix 20 other issues than concentrate a lot of effort in this particular one.

re: CLR and floating point: Some answers to common questions

Chris Nahr — Fri, 12 Aug 2005 09:35:06 GMT

Hmm, I guess I'm extreme then. :) What I'd really like to see:

1. A warning when the C# compiler encounters any direct comparisons between floating-point types. Better yet, different warnings depending on whether one operand is 0.0 or 1.0.

2. A standard method to perform FP comparisons with a given epsilon, or with a default epsilon based on the operand type. Let's call it Math.CompareTo(a, b, epsilon) which results in 0 if abs(a-b) <= epsilon, etc.

That solution would be fast, reliable, portable... you name it. No fundamental changes to the CLR or C# compiler would be required. And when people asked about weird FP results you could just tell them to use Math.CompareTo.

Maybe this would be a nice idea in addition to whatever FPU-specific options you think of adding?

Tim Van Wassenhove » Archive » About additional precision and unpredicted behaviour...

Tue, 26 Jun 2007 20:27:33 GMT

PingBack from http://www.timvw.be/about-additional-precision-and-unpredicted-behaviour/

David Notario s WebLog CLR and floating point Some answers to common | storage bench

Fri, 19 Jun 2009 10:51:09 GMT

PingBack from http://thestoragebench.info/story.php?id=7532