View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sat Mar 04, 2017 12:02 am Post subject: |
|
|
Dan,
Thanks for the recommendation. I shall look at the 64-bit debugger.
I was reviewing your quoted run times. I don't get the performance you quoted; must be related to the processor. I assume you used /64 /opt.
It looks like /64 /opt is performing well on these loops.
Paul,
Any documentation of what /64 /opt can achieve?
Does it include SSE or AVX instructions in inner loops, which could support more complex calculations than supported by (the very useful) DOT_PRODUCT8@ or AXPY8@ ? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Mar 04, 2017 12:35 am Post subject: |
|
|
Do you have 8.10? Use /opt then |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1891
|
Posted: Sat Mar 04, 2017 2:04 am Post subject: |
|
|
Dan, here is a constructive comment. If you have code that you suspect will give you trouble when you switch to the FTN95-64 compiler, you can do a 32-bit run in which you partly simulate the 64-bit behavior of mixed-mode arithmetic expressions.
This is easy to do with, for example, Intel Fortran, which gives you the /Qpc32 option. This option forces the x87 FPU into dropping the bit size of the mantissae down from 64 to 24. Thus, if you make two 32-bit runs, one compiled with /Qpc32 and another without, if the results are the same, you have a high likelihood that moving to 64-bits will not cause loss of precision in mixed mode expressions. If the results differ, you can pinpoint and fix the problem in 32-bit mode, where the debugger may be more convenient to use.
Doing the equivalent of Intel's /Qpc32 with FTN95-32 is possible, but not so convenient. You have to manipulate the X87 control word, and get FTN95 to ignore precision loss at run time (i.e., mask the precision exception). |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sat Mar 04, 2017 8:15 am Post subject: |
|
|
Thanks Mecej4, I am sure that Silverfrost will offer similar option easily making a switch which will issue warning or even report error in such cases. Besides parallelization Intel has no appeal to me. I need compiler which has unbeatable bug sniffing capabilities because actually code development, debugging and validation is 99% of time, health and brain cell losses. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Sat Mar 04, 2017 9:57 am Post subject: |
|
|
Here is a program that illustrates the point made by Mecej4 that "32 bit" FTN95 gives greater precision than one might expect because it uses x87 floating point coprocessor instructions to add a REAL*4 to an INTEGER*4.
Code: | program test
i=16777200 ! A little under 16777216 which is 2 raised to the power 24
do
k=i+1.0
i=i+1
if(k /= i)then
print*,"Last good value:",i-1
exit
endif
if(i > 2147483646)then
print*, "Good for all integer*4"
exit
endif
enddo
end |
Dan:
At the moment I don't know if it would be feasible to get "64 bit" FTN95 to do "better" than it does at the moment. Maybe a warning could be provided.
John:
I don't have any details at the moment about what /opt does, other than that in part it aims to minimise the number of assembly instructions. The use of SSE2 and AVX for the dot product etc. has not changed since 8.05 except that (in some cases) you will now get SSE2 for a DOT_PRODUCT anyway (with or without /opt). I will ask for further details. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1891
|
Posted: Sat Mar 04, 2017 10:39 am Post subject: |
|
|
As the 64-bit compiler gradually supplants the old reliable FTN95-32, we may run into another curious and unexpected behaviour: with 8-byte integers, the 32-bit compiler can do a more efficient job of catching integer overflow than the 64-bit compiler.
That is because FTN95-32 uses the X87 section of the CPU to do 8-byte integer arithmetic. When an expression is evaluated and saved to memory, an FIST/FISTP instruction is used. If the number is too large an integer for 8 bytes in memory, a floating-point exception is raised, if exceptions are unmasked, and the exception can be processed.
In FTN95-64, in contrast, arithmetic with 8-byte integers is faster with the main (integer) part of the CPU, but a lot more code has to be emitted by the compiler if the user wants to catch integer overflow -- no hardware assist in the form of an exception is available. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sat Mar 04, 2017 12:38 pm Post subject: |
|
|
I consider real*4 overflow to be a user coding error, as typically the wrong precision has been selected. Not a bug in FTN95.
For integer overflow, this has typically been used for random number generators. I have always considered this to not be an error or an exception. This can often occur with integer*1, integer*2 and integer*4, although I'd expect that integer*8 would be less frequent. Not sure that it needs to be trapped.
John |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1891
|
Posted: Sat Mar 04, 2017 1:15 pm Post subject: |
|
|
Sure, integer overflow is routine and need not be trapped.
However, when the programmer has asked for checking with a compiler option or directive, it is helpful in fixing the code if integer overflow can be trapped and traced. With most compilers, such checking can make the program so slow that one tends to turn on checks less often. With the hardware assist available in the FPU for 8-byte integers, the overhead for checking is greatly reduced, and some checks can be left in place in production code.
Last edited by mecej4 on Sun Mar 05, 2017 2:50 pm; edited 2 times in total |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Mar 05, 2017 4:08 am Post subject: |
|
|
Since FTN95 is a champ in tricky error cases, it is like Sherlock Holmes among compilers, this option would be great to add. Or at least add kind of more verbose mode to compiler which will generate suggestions/warnings/comments to make sure that integer does not go over 3e7 in mixed Int+FP*4 programming and be below ~1e15 in int*8 + FP*8.
For example this compiler warns that comparing FP numbers may produce misleading results. I see people use thousands of such IFs in their codes. Why not add one more warning? I am sure people will use mixing Int+FP and be burned. Know cases when they wrote books and published many papers with the bugs in codes found decades later. |
|
Back to top |
|
|
|