Sign in to follow this  
Misery

How to control floating point unit on different compilers

Recommended Posts

Hello,

I have a C code, that requires explicit control of roundoff error. The author of the program has included proper definitions for Linux GCC and MSVCC on Windows with Intel CPU. This can be found [url="http://www.cs.cmu.edu/~quake/robust.pc.html"]here[/url].

My question is how to do define this on other compilers. I am interested in:

Intel or AMD CPU working with code copiled with:
Intel C++ Windows/Linux
MinGW GCC Windows
Borland (Embrocadero) C++ Windows
Open64 Linux

Where can I find proper information? Or anybody has a solution already?

Thanks in advance and regards,
Misery

Share this post


Link to post
Share on other sites
Intel info [url="http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/copts/common_options/option_fp_model.htm"]here[/url].

For the others all I can suggest is searching for "floating point model" or "floating point strict" along with the compiler.

Share this post


Link to post
Share on other sites
[quote name='Misery' timestamp='1339764272' post='4949517']
This can be found here.
[/quote]
First and most important issue:

[b]Your article is 15 years out of date[/b]. It is about the 486 family and the original Pentium family. That era ended back circa 1997. Nobody uses those any more.



Second, the article's requirements don't work like that in games. It is much more than just setting a few bits of floating point control.

There is a lot of nuance in floating point. Even copying a block of floating point code from one location in a program to another location in a program can generate different floating point results. The stuff going on under the hood by the optimizer can significantly alter the results.

For example in one place the compiler may leave a value in the an 80-bit register while in another case it may do the work then push it out to a 32-bit float, then reload the float.



What is the actual problem you are trying to solve? Why do you think this is the solution? Edited by frob

Share this post


Link to post
Share on other sites
[quote]
First and most important issue:

[b]Your article is 15 years out of date[/b]. It is about the 486 family and the original Pentium family. That era ended back circa 1997. Nobody uses those any more.
[/quote]

Thanks for pointing that out! That ia quite an important issue I didn't notice at all.
What I am trying to achieve is to let the code do it's exact arithmetic for mesh generation purposes. The detailed description of what this code is supposed to do is [url="http://www.cs.cmu.edu/~quake/robust.html"]here[/url].

So what would You have me do? Maybe I should change code so it uses for example long doubles? Something like that would be quite a good solution, but not every compiler it is supposed to wor on has long doubles.

Thanks Edited by Misery

Share this post


Link to post
Share on other sites
[quote name='Misery' timestamp='1339835194' post='4949732']
Thanks for pointing that out! That ia quite an important issue I didn't notice at all.
What I am trying to achieve is to let the code do it's exact arithmetic for mesh generation purposes. The detailed description of what this code is supposed to do is [url="http://www.cs.cmu.edu/~quake/robust.html"]here[/url].

So what would You have me do? Maybe I should change code so it uses for example long doubles? Something like that would be quite a good solution, but not every compiler it is supposed to wor on has long doubles.
[/quote]Again, that article is 15 years old as well and the footnote are comparing using hardware floating point (which was still a rare thing back then) vs using a library for software floating point and a library using software fixed point.


Floating point numbers are accurate to within about 6 decimal digits. Double precision floating point numbers are accurate to about 10 decimal digits. That is simply the nature of how floating point works.

The article's problem is that they want to use floating point numbers but then proceed to deny the very nature of floating point numbers. Their solution is to disallow the higher precision because their results rely on having reliably less-precise answers. It is not a very good solution in my view.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this