- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've compiled our large project with both switches. The some 400 test files are mostly nearly equal in both cases with a few having large diffs. In one particular case, I'm interested in tracking down what the possible differences could be (as it is only for a few variables), but I'm a bit stumped at what to look for.
So, any hints on what to look for in code would be helpful.
Also -- if I were to run both versions in debug -- /fp:fast and /fp:source -- would that show up those kinds of diffs?
Any hints appreciated.
Linda
So, any hints on what to look for in code would be helpful.
Also -- if I were to run both versions in debug -- /fp:fast and /fp:source -- would that show up those kinds of diffs?
Any hints appreciated.
Linda
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you were considering whether to use /fp:source vs. /fp:fast, you would probably add additional flags to narrow the differences, such as -Qftz -assume:protect_parens -Qprec-div -Qprec-sqrt. You should look up those individual options; /fp:source by itself turns off ftz and should set those other options.
If you allow your debug option to set /Od, it will eliminate most of the aggressive effects of /fp:fast. If you set the same /O level as your release mode, debug will not change the effect of these options.
The most visible effect of /fp:fast=2 is to set complex limited range, where the valid exponent range for complex is cut by half. This would permit vectorization of many complex operations, but isn't worth considering if you don't have vectorizable complex.
The most visible effect of /fp:fast -assume:protect_parens -Qprec-div -Qprec-sqrt is to permit vectorization of sum reductions which aren't permitted under /fp:source. Vectorization of reductions usually gives a slightly improved accuracy which may vary with data alignment.
If you allow your debug option to set /Od, it will eliminate most of the aggressive effects of /fp:fast. If you set the same /O level as your release mode, debug will not change the effect of these options.
The most visible effect of /fp:fast=2 is to set complex limited range, where the valid exponent range for complex is cut by half. This would permit vectorization of many complex operations, but isn't worth considering if you don't have vectorizable complex.
The most visible effect of /fp:fast -assume:protect_parens -Qprec-div -Qprec-sqrt is to permit vectorization of sum reductions which aren't permitted under /fp:source. Vectorization of reductions usually gives a slightly improved accuracy which may vary with data alignment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay -- should have said I already have the options you mention on in both: assume:protect_parens -Qprec-div -Qprec-sqrt
I also, at the same time had switched from fp:speculation=off to speculation=fast.
We have no complex numbers being used in the code.
Linda
I also, at the same time had switched from fp:speculation=off to speculation=fast.
We have no complex numbers being used in the code.
Linda
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're getting close to thinking this may be a compiler bug. (Similar to ones we saw with 11.0 but obviously not the same.
I may go back and load update 5 and see if it occurred there.
Linda
I may go back and load update 5 and see if it occurred there.
Linda
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page