extended precision (64-bit precision)

[Axel_Ohrt_J_]

Dear DZ

I have just updatet my fortran compiler under WS(Professional 2013 - update 4) with Intel® Parallel Studio XE Composer Edition for Fortran Windows*.

Unfortunately, my code is no longer able to maintain the same calculation accuracy (machine eps = 1.2D-19) using the ifport modules (GETCONTROLFPQQ and SETCONTROLFPQQ), se the below code, which now creates the standard machine eps = 2.2D-16.

Are there any compiler settings to fix that problem, any guidance???

Thanks in advance!

Regards

Axel Ohrt Johansen

subroutine fpprecis()

use ifport

use dflib

integer(2) control, holdcontrol, newcontrol

real(8) A,EPSMAC

CALL GETCONTROLFPQQ(control)

! Clear any existing precision flags.

holdcontrol = IAND(control, NOT(FPCW$MCW_PC))

newcontrol = IOR(holdcontrol, FPCW$64)

! Set precision to 64 bits.

CALL SETCONTROLFPQQ(newcontrol)

! Test - machine eps:

EPSMAC=1.0D0

100 EPSMAC=EPSMAC/2.0D0

A=EPSMAC+1.0D0

IF(A.NE.1.0D0) GO TO 100

EPSMAC=2.0D0*EPSMAC

Write(6,*) EPSMAC

end subroutine fpprecis

[TimP]

I assume you are relying on /arch:IA32 for this purpose.  It appears to work as you expect here with current psxe on win8.1 X64.  So you are successful in over-riding the 53-bit precision mode set by Windows X64.

There may have been ways to make this work with past versions of ifort Intel64, but I don't think this remains possible with current versions.

I used to set /Op to achieve the effect of /arch:IA32 with ifort Intel64, but this has broken.  There has been some interaction with debug options.  I haven't dug into the reasons, but with current ifort Intel64 I require -debug:inline-debug-info rather than -Zi to avoid bad rounding effects.

I assume you have read the warnings from Intel about how the Microsoft run-time libraries aren't consistent with 64-bit precision mode (nor, apparently, with SSE2 gradual underflow).

[Axel_Ohrt_J_]

Hi Tim

I am working on /arch:IA32 Windows 7. Until my last update one month ago, the over-riding of the 53-bit precision seems to Work!

Regards

Axel

[mecej4]

I find that if I don't specify /arch:ia32 when I use the 32-bit IFort 15.0.3 the code contains SSE2 instructions. I tried /Fa without /arch:ia32, and found that the assembler file contained SSE2 instructions even though the file started out with ".686P" and ".387" directives.

Check if you have config files in more than one place contributing compiler options, one or of which may have overridden /arch:ia32.

[jimdempseyatthecove]

If it does not impact performance too much, in your precision critical routines, have you considered using REAL(16)?

Using this will future-proof your code. As you can garner from Tim's and mecej4's comments, relying on FPU instructions (as opposed to SSE, AVX, AVX2, AVX512, later) may be spotty and problematic. As you update compiler versions, (as you have experienced) code that used to work, no longer works as expected. Use of REAL(16) will fix this now and later.

I would venture to guess that some future version of a successor to Knights Landing (Xeon Phi series used in HPC) will eventually have hardware support for REAL(16). Though I do not expect this to occur in the notebook/desktop/workstation/small server processors.

Jim Dempsey

[Axel_Ohrt_J_]

Thanks to the entire Intel community!

I would consider converting my code to real(16) with x64. The great question is what it will cost in performance relative to the real(16) with 32-bit technology. Is there anyone who has experience in this area - I think of benchmarks.

Thanks in advance to all.

Axel Ohrt Johansen

[Steven_L_Intel1]

There is a significant performance penalty to converting the entire application to REAL(16). Ideally you would identify key computations that need to be done in a higher precision.

[LRaim]

Just for curiosity.

Which is the physical, chemical, engineering  field where calculations are needed with real*16 floating point operations ?

[Axel_Ohrt_J_]

Optimisation of large matrix systems with thousand of DOFs. It is therefore I ask for extended pression (53 bit to 64 bit) in Win32. I look for X64 as an alternative with real(16), which gives an mashine eps of app. 1.0E-34.

Regards

Axel

[jimdempseyatthecove]

Axel,

I did not suggest converting your entire application over to REAL(16). Rather I stated "in your precision critical routines".

This said, it may be more appropriate to see why your "precision critical routines" appear to require higher precision. In most cases, real(8) should be more than sufficient, but may require you correcting (adjusting) the algorithm such that the error component of the results is reduced. Steve (under "Dr. Fortran") has several good articles relating on how to control (reduce) error significance.

Jim Dempsey

[Axel_Ohrt_J_]

Hi Jim

You have right in your point real(8) is more than enough to solve my problems, and have already algoritme for scaling my equations. It annoyed me that I no longer can run the application with a machine eps on 1.2E-19. (53bit-> 64 bit).
Best regards

Axel