- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick query.
I might be completely wrong with this but are dynamically allocated real*8 arrays stored at 80 bits while static arrays are stored at 64 bits?
If so, is there a way to disable this so the stack is at 64 bits?
Thanks in advance
TJ.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This can't be quick, as it's not clear what you have in mind.
ifort has no way to store real*8 in 80-bit format.
The /Qpc options are still described in the Windows .chm help file, but I suppose you would need to be using the 32-bit (ia32) compiler with architecture option set to ia32 (/arch:IA32 or -mia32, according to Windows or linux). This subject still isn't close to your wording.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The simple answer to what you seem to be getting at is "No, they aren't, so just use the default options and you won't get any 80-bit floats." Even if you used a 32-bit compiler and used the options Tim mentions, at best you'd get intermediate calculations in 80-bit registers but they'd never get stored to memory that way. The default is to use the precision you declare and the SSE instructions used for floating point don't have an 80-bit option.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Many thanks for the responses!
Sorry for not being clearer in my query. I am running ifort 11.1 on a 64 bit Linux machine. I am trying to determine why an modification to my code influences the value of a function.
I have a number of dynamically allocated arrays :
real*8,save,allocatable :: DENSITY (:)
real*8,save,allocatable :: MASS (:)
real*8,save,allocatable :: PRESSURE (:)
in my function I calculate the value of variable 'pressure_force_ij' from
real*8 pressure_force_ij
pressure_force_ij = ((pressure(i)+pressure(j))/2.0) * (mass(j)/density(j))
Now, if I change this to
real*8 pressure_force_ij
real*8 pressure_i, pressure_j, mass_j, density_j
pressure_i = pressure(i)
pressure_j = pressure(j)
mass_j = mass(j)
density_j = density(j)
pressure_force_ij = ((pressure_i+pressure_j)/2.0) * (mass_j/density_j)
I should get the same value but I find that I get a very slightly difference. This is evident as the pressure force value exhibits positive feedback behaviour. I thought that this could be explained by the dynamic and static variables being stored at differing precisions but it would appear that this is not the case.
I am compiling with flags -O2 -openmp -xAVX -traceback -check bounds
Any ideas on why the change would effect the result?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are looking for the parentheses to force the same order of evaluation in the two cases, you should add the option -assume protect_parens (or an option which includes that). As far as I know, the lack of default status for this option is a historical question (might even involve your suspicions about past extended precision options).
Depending on how this code is used, -prec-div may also have an effect; without it, the compiler will look for opportunities to replace /density_j by 1/density_j * (which has numerical implications), as well as replacing /2.0 by *0.5 (which is completely safe and seems unnecessary to be controlled by -prec-div).
I don't know at which version ifort began having problems with allocatable under the -openmp option; I think that would be subsequent to the final 11.1 version (and appears to be corrected in the latest 13.1 and 14.0 versions). In the 11.1 series also, it would be preferable to use the final update version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the response. Neither of the compiler options had any effect on the solution. I will play around with the code to see if I can determine the cause or, alternatively, just turn a blind eye to this...
With kind regards
TJ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim covered the effects and switches that seemed most likely to be responsible. However, if you build with -fp-model precise, that should suppress all the optimizations that might lead to small variations in results. See the article attached at http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/ for more detail than you proably want to know. If that doesn't help, check carefully that you don't have typos in any of your type declarations - use implicit none, and perhaps -real-size=64.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page