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 

FTN95 64-bit beta test
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2026
Location: Yateley, Hants, UK

PostPosted: Sat Sep 26, 2015 2:39 pm    Post subject: Reply with quote

John C's observation that one has to beware of running out of physical memory probably means using the GlobalMemoryStatusEx function. I think that life would be made easier if Paul could provide a standard Fortran function to do this (or someone else might).

John: is there a performance hit using the 64-bit backend when the program is runnable using 32-bit FTN95?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2116
Location: Sydney

PostPosted: Sun Sep 27, 2015 1:07 am    Post subject: Reply with quote

Dan, The stack is just as big a problem in 64 bit, actually probably more, as it does not take too long to overflow if you are not aware of the causes. That is why I recommend using ALLOCATE for all (large) local arrays. Everything is still finite, just bigger. Actually the first time you run a program that requires more memory than installed, you will be surprised, then very annoyed you did. You will have quite some time to think about this as you will wait a while till the PC returns to normal operation. Eddie's recommendation of Installed_Memory function would be a big help.

Eddie, At present /opt is not supported so there are some performance issues with this beta /64. There is a more general performance issue with /64 as with larger arrays ( lazyness ? ) the run times become more obvious. In general there negligible run time difference between running the same program as /32 or /64, although both have some areas where they perform better (different instruction set). If available I will use 64 bit.

This beta version does not yet have /check or /opt but I am sure it will soon.

I anticipate the big plus with this /64 version is that existing Clearwin programs can be compiled with /64 and get more memory with larger arrays. The main change will be to recognise which (API) handles must be integer*8. Testing clearwin is my next test so I will keep a log of changes required.

John
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Sep 27, 2015 4:51 am    Post subject: Reply with quote

Things are that some parts of the large codes are written in old style with common blocks and are very reliable, changing them to allicatables may cause hidden roaches to be introduced and cleaned for years. So this transition will take time.

Damn rudiment stack is still there. And is still probably set in bytes so now the compilation will look full line of zeroes...go count them right

SLINK AAA.obj /stack:32000000000

Heck also knows does this mean per array or per total...Smile. Kill the stack, Silverfrost!
Back to top
View user's profile Send private message
jalih



Joined: 30 Jul 2012
Posts: 190

PostPosted: Sun Sep 27, 2015 10:40 am    Post subject: Re: Reply with quote

JohnCampbell wrote:
Dan, The stack is just as big a problem in 64 bit, actually probably more, as it does not take too long to overflow if you are not aware of the causes. That is why I recommend using ALLOCATE for all (large) local arrays. Everything is still finite, just bigger.

I think going from 32-bits to 64-bits don't change the maximum stack size? If I recall correctly the maximum limit for stack size in executable is set by the linker and is the same for 32-bit program and 64-bit program, as it is defined inside the PE format as dword sized 32-bit field.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Sep 27, 2015 12:16 pm    Post subject: Reply with quote

Over the years the existence of stack caused nothing but the troubles and crashes. Probably it is just poorly implemented or buggy. Plus there is no facilities that tell what is going on with the allocation and how stack is full. OK, how about making at least the option /stack:-1 which will disable all the traces of involvement of stack facilities completely
Back to top
View user's profile Send private message
jalih



Joined: 30 Jul 2012
Posts: 190

PostPosted: Sun Sep 27, 2015 7:02 pm    Post subject: Re: Reply with quote

DanRRight wrote:
Over the years the existence of stack caused nothing but the troubles and crashes. Probably it is just poorly implemented or buggy. Plus there is no facilities that tell what is going on with the allocation and how stack is full. OK, how about making at least the option /stack:-1 which will disable all the traces of involvement of stack facilities completely

Stack is originally designed to store temporary and local variables (automatic storage). Unfortunately, it's not so easy to keep track of stack usage as program may have recursive procedures or Fortran compiler may even create array temporaries. Anyway using stack is fast and convenient way to reserve space for local variables and access them. I personally would use heap allocation to store huge amounts of data and prefer to keep stack size small. Also you should remember that every thread uses it's own stack, so you are probably not going to see stack disappear any time soon.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Sep 28, 2015 11:28 am    Post subject: Reply with quote

Here is some code for GlobalMemoryStatusEx.

Code:
program gmem
integer, parameter:: knd = 4

type MEMORYSTATUSEX
sequence
  integer dwLength;
  integer dwMemoryLoad;
  integer(knd) ullTotalPhys;
  integer(knd) ullAvailPhys;
  integer(knd) ullTotalPageFile;
  integer(knd) ullAvailPageFile;
  integer(knd) ullTotalVirtual;
  integer(knd) ullAvailVirtual;
  integer(knd) ullAvailExtendedVirtual;
end type 

stdcall GlobalMemoryStatusEx 'GlobalMemoryStatusEx'(REF):logical
type(MEMORYSTATUSEX)::mdata

mdata%dwLength = 64
if(GlobalMemoryStatusEx(mdata))then
  print *,  "Percentage of physical memory in use        ", mdata%dwMemoryLoad           
  print 10, "Amount of actual physical memory            ", mdata%ullTotalPhys           
  print 10, "Amount of physical memory available         ", mdata%ullAvailPhys         
  print 10, "Committed memory limit                      ", mdata%ullTotalPageFile       
  print 10, "Amount of memory current process can commit ", mdata%ullAvailPageFile       
  print 10, "Size of virtual address space               ", mdata%ullTotalVirtual         
  print 10, "Amount of unreserved/uncommitted memory     ", mdata%ullAvailVirtual         
else
  print*,"Failed" 
endif

10 format(1x,a,i12)
end program




What would an FTN95 library routine look like (preferably without optional arguments)?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2116
Location: Sydney

PostPosted: Mon Sep 28, 2015 1:56 pm    Post subject: Reply with quote

Could it look something like this:
Code:
module Global_Memory_Status_a
 integer, parameter:: knd = 4

 type MEMORYSTATUSEX
 sequence
   integer dwLength;
   integer dwMemoryLoad;
   integer(knd) ullTotalPhys;
   integer(knd) ullAvailPhys;
   integer(knd) ullTotalPageFile;
   integer(knd) ullAvailPageFile;
   integer(knd) ullTotalVirtual;
   integer(knd) ullAvailVirtual;
   integer(knd) ullAvailExtendedVirtual;
 end type 

 stdcall GlobalMemoryStatusEx 'GlobalMemoryStatusEx'(REF):logical
 type(MEMORYSTATUSEX)::mdata
!
end module Global_Memory_Status_a

program gmem
 call paul_example
 call lib_example
end program gmem

subroutine paul_example
 use Global_Memory_Status_a

 real*4    gb
 external  gb

 write (*,*) ' '
 mdata%dwLength = 64
 if (GlobalMemoryStatusEx(mdata)) then
   print *,  "Percentage of physical memory in use        ", mdata%dwMemoryLoad           
   print 10, "Amount of actual physical memory            ", gb(mdata%ullTotalPhys)
   print 10, "Amount of physical memory available         ", gb(mdata%ullAvailPhys)
   print 10, "Committed memory limit                      ", gb(mdata%ullTotalPageFile)
   print 10, "Amount of memory current process can commit ", gb(mdata%ullAvailPageFile)
   print 10, "Size of virtual address space               ", gb(mdata%ullTotalVirtual)
   print 10, "Amount of unreserved/uncommitted memory     ", gb(mdata%ullAvailVirtual)
 else
   print*,"Failed" 
 end if

 10 format(1x,a,f0.3)
 
end subroutine paul_example

subroutine lib_example

 real*4    gb
 integer*8 get_physical_memory_a, get_available_memory_a, get_memory_limit_a, get_virtual_memory_limit_a, jj
 external  get_physical_memory_a, get_available_memory_a, get_memory_limit_a, get_virtual_memory_limit_a, gb

 write (*,*) ' '
 jj = get_physical_memory_a ()
 write (*,11) "Amount of actual physical memory            ", gb(jj), jj
 jj = get_available_memory_a ()
 write (*,11) "Amount of physical memory available         ", gb(jj), jj
 jj = get_memory_limit_a ()
 write (*,11) "Committed memory limit                      ", gb(jj), jj
 jj = get_virtual_memory_limit_a ()
 write (*,11) "Size of virtual address space               ", gb(jj), jj

 11 format(1x,a,f10.3, i14)
 
 end subroutine lib_example

 integer*8 function get_physical_memory_a ()
 use Global_Memory_Status_a
 
   mdata%dwLength = 64
   if (GlobalMemoryStatusEx(mdata)) then
     get_physical_memory_a = mdata%ullTotalPhys
   else           
     get_physical_memory_a = -1
   end if
 end function get_physical_memory_a

 integer*8 function get_available_memory_a ()
 use Global_Memory_Status_a
 
   mdata%dwLength = 64
   if (GlobalMemoryStatusEx(mdata)) then
     get_available_memory_a = mdata%ullAvailPhys
   else           
     get_available_memory_a = -1
   end if
 end function get_available_memory_a

 integer*8 function get_memory_limit_a ()
 use Global_Memory_Status_a
 
   mdata%dwLength = 64
   if (GlobalMemoryStatusEx(mdata)) then
     get_memory_limit_a = mdata%ullTotalPageFile
   else           
     get_memory_limit_a = -1
   end if
 end function get_memory_limit_a

 integer*8 function get_virtual_memory_limit_a ()
 use Global_Memory_Status_a
 
   mdata%dwLength = 64
   if (GlobalMemoryStatusEx(mdata)) then
     get_virtual_memory_limit_a = mdata%ullTotalVirtual
   else           
     get_virtual_memory_limit_a = -1
   end if
 end function get_virtual_memory_limit_a
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2116
Location: Sydney

PostPosted: Mon Sep 28, 2015 2:02 pm    Post subject: Reply with quote

Code:
 real*4 function gb (leng)
   integer*8 leng
   gb = real(leng)/(1024.**3)
 end function gb


Paul,

Thanks very much for the examples.
_a could be replaced by @ and functions placed into salflibc.dll
I've also recommended some other additions which would be useful as documented extension utility functions.

John
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2026
Location: Yateley, Hants, UK

PostPosted: Mon Sep 28, 2015 11:24 pm    Post subject: Reply with quote

Several things occur to me about this.
Going to 64-bit is going to create a mix of INTEGER*4 and INTEGER*8 that will irritate Dan (sorry Dan) just as the last few INTEGER*2 variables do now.
If you hit the limits of available memory frequently, the problem is in the forefront of the programmerís mind. The less frequently you hit it, then the more shocking it will be when it happens, hence my suggestion that we need a Fortran routine for checking available space. I think it is more likely that one hits this limit with ALLOCATE than with statically allocated memory, and it seems to me essential to check that there is space before trying to allocate it (especially if you donít want users to see a system message). I wasn't expecting to see it so soon!
With statically allocated memory we are likely to know what the minimum computer configuration is needed to run the program in the first place, and if it wonít run that other applications need to be closed. With dynamically allocated memory this simple test/solution isnít available.
Ask yourself where is the memory allocated for local, unSAVEd variables. The answer is probably on the stack. The stack used to be tiny (tinier even than tiny total memory), and its use had to be restricted to such things as passing the addresses of subprogram parameters and return addresses, so there were severe limitations on the call tree depth (or whatever computer scientists call it now). When you contaminate it by filling it up with large volumes of local array storage then you are asking for the trouble you most certainly get, no matter how big the stack is.
Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 29, 2015 7:25 am    Post subject: Reply with quote

John

Thanks. I get the idea about creating simple Fortran functions.

It made me realise two things...
a) clearwin_info@ ought to return integer(7) in the new header files and
b) we can use clearwin_info@ in this context.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2116
Location: Sydney

PostPosted: Tue Sep 29, 2015 9:22 am    Post subject: Reply with quote

Paul,

I'd prefer to have the simple functions, like listed, as they are useful for programs not using clearwin.

I've sent a list of some useful routines, which I think would be better in salflibc.dll. I expect they are all easy to implement and would help with program testing, such as processor name, compiler version, dll version and compiler options. Note compiler_option is part of F08 ISO_FORTRAN_ENV, returning a string of variable length. I am not sure if that is easily supported, but adopting some of this would certainly provide some upward conformity and standardised KIND names. It would help with the KIND portability problem.

Also the two SSE functions, as they give easy access to vector instructions for the most common array calculations, if vector instructions are not going to be provided generally in the short term.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 29, 2015 10:55 am    Post subject: Reply with quote

John

"ClearWin+" functions are always available with "FTN95" functions. They reside in the same library(s). To save a lot of work at this end I will implement them via clearwin_info@, at least for the time being. In fact I have already done this. Just need to test that they work.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Sep 30, 2015 10:06 pm    Post subject: Reply with quote

As we discuss 64bit compiler here and in the other places i suspect i was not clear what i wanted to see in the next beta. I asked for simpler thing (though i might be wrong that it is simple) then to implement the debugger at this stage. If compiler just reported the error line where error occurs (and all other standard diagnostics) then it would be great milestone. For example in this text

Code:

a=1
b=0
c=a/b
print*, c
end


compiler has to tell not just "floating point divide by zero in #MAIN at address x000001001000101011000101010101000010101100000" but the

"floating point divide by zero in #MAIN at the line 3".

Is this doable without any major rebuilds?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2116
Location: Sydney

PostPosted: Thu Oct 01, 2015 12:52 am    Post subject: Reply with quote

If the line address is not available, what would it require to provide a trace back of the routines called? This is the main reason I use /debug with /32.
A combination of both /OPT and /Trace_Back would be good for both /32 and /64.
With my present program builds with many .f90 files, I am choosing different compile options for each file, when the line number is all I am requiring from the /DEBUG option. If /Trace_Back could provide some optimisation, that would be a good change.
I tend to mix:
/CHECK for data reading routines
/DEBUG for program management routines
/OPT for compute intensive routines
All in the one program.
There are many cases where /Trace_Back would be preferred to what I assume /DEBUG provides.

John
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 -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 2 of 9

 
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