forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Does this code work under debugger and without ?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Mar 04, 2017 12:02 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Mar 04, 2017 12:35 am    Post subject: Reply with quote

Do you have 8.10? Use /opt then
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Mar 04, 2017 2:04 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Mar 04, 2017 8:15 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Mar 04, 2017 9:57 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Mar 04, 2017 10:39 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Mar 04, 2017 12:38 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Mar 04, 2017 1:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Mar 05, 2017 4:08 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group