|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Sep 26, 2015 2:39 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Sep 27, 2015 1:07 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Sun Sep 27, 2015 4:51 am Post subject: |
|
|
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.... Kill the stack, Silverfrost! |
|
Back to top |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Sun Sep 27, 2015 10:40 am Post subject: Re: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Sun Sep 27, 2015 12:16 pm Post subject: |
|
|
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 |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Sun Sep 27, 2015 7:02 pm Post subject: Re: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Sep 28, 2015 11:28 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Sep 28, 2015 1:56 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Sep 28, 2015 2:02 pm Post subject: |
|
|
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 |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Sep 28, 2015 11:24 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Sep 29, 2015 7:25 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Sep 29, 2015 9:22 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Sep 29, 2015 10:55 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Wed Sep 30, 2015 10:06 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Oct 01, 2015 12:52 am Post subject: |
|
|
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 |
|
|
|
|
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
|