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 

Stack Size
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
davidb



Joined: 17 Jul 2009
Posts: 557
Location: UK

PostPosted: Fri Apr 27, 2018 10:48 am    Post subject: Re: Reply with quote

mecej4 wrote:
See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686774(v=vs.85).aspx regarding threads and stacks. Note the comments in the second paragraph regarding keeping stacks modest in size.


Yes, thread-specific stacks are used to hold thread-private variables. Management of the stack size comes down to careful selection of algorithm and data structures. As a simple example, in quicksort you don't need to use recursion to sort both sub-lists. Recursion should only be used on the shortest sub-list; iteration should be used on the longest sub-list. This strategy keeps the stack size down.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2086
Location: Sydney

PostPosted: Fri May 25, 2018 11:38 pm    Post subject: Reply with quote

davidb & mecej4,

I have now reread your posts on this thread. To me, what you have written is just excuses for what is a very poor/lazy system design.
If the stack is to overflow, there should be the ability to provide a secondary stack. In 64-bit, this should be easy, as I think all (virtual) memory above 4gb is dynamically allocated at run time, so stack extensions should not be a problem.
The only problem with this approach is the claimed relative efficiency of using the local stack vs secondary stack above 4gb, although I expect this can be overcome with the mapping of virtual memory to physical memory pages.

Unfortunately, any change in this area is probably unlikely to happen as the stack management is an O/S and not a FTN95 domain ?

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


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

PostPosted: Thu Feb 14, 2019 11:40 am    Post subject: Reply with quote

Some development has been carried out with respect to the permitted size of the FTN95 stack.

SLINK64 allows you set the maximum stack size which has a certain default value. It has been suggested above that FTN95/SLINK64 should know how much stack is required but this is not the case. On the other hand, SLINK64 could use a very large default size but that would not be sensible. So we are left with the status quo except...

FTN95 and SLINK64 have been developed to allow the user to extend the stack size above the 4GB level. So if a user wants to have enormous local arrays then it will now be possible provided SLINK64 is instructed accordingly.

Regarding the irritation of having to provide a hex value for the stack size, the only way to fix this is for us to provide an alternative command (a hex value might not contain x or A to F characters in which case it could be hex or decimal). An alternative command could be added if there is a demand.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Thu Feb 14, 2019 1:54 pm    Post subject: Reply with quote

Paul,

Isn't it sensible to make numbers that humans have to communicate to a computer always decimal or at least base 10 (like thousands or millions)? Frankly, I'd suspect that some multiple of megabytes is best, as I defy anyone to accurately predict the needed stack extent down to individual bytes, or some small multiple thereof.

I can't quite see why FTN95 / SLINK can't work out the required stack size, but I will take it on trust. There is one simple rule. If you have numerous very large local arrays passed between subprograms you will need a big stack, and if you don't, you won't. Us COMMONers simply don't need the huge stack, which is probably why COMMON was invented in the first place.

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


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

PostPosted: Thu Feb 14, 2019 4:04 pm    Post subject: Reply with quote

I have added a new SLINK64 command "stack" that takes a value which is the number of (decimal) megabytes.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Thu Feb 14, 2019 4:12 pm    Post subject: Reply with quote

Paul,

It's always gratifying when one makes a sensible suggestion which is acted upon with such great alacrity!

I shan't be churlish and ask if your megabytes are 10^6 or 2^20 ...

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


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

PostPosted: Thu Feb 14, 2019 4:49 pm    Post subject: Reply with quote

Eddie

I assume decimal 10^6 but it could be changed.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Thu Feb 14, 2019 5:01 pm    Post subject: Reply with quote

Paul,

Remember it matters not to we Plebs, we COMMONers, we few, we happy few, we band of brothers*, but I suspect you ought to put it in the documentation just so that it is clear to the Stack-mongers and Allocateers to whom it does matter.

Just a suggestion.

Eddie

*I could wax right poetical on this subject, given half a chance.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2086
Location: Sydney

PostPosted: Wed Feb 20, 2019 8:01 am    Post subject: Reply with quote

Paul,

Thanks very much for the stack command in SLINK64.
Please ensure it is documented in FTN95.chm

My preference would have been for something like "stack_size 16MB", rather than "stack_size 0x1000000", although I suspect I am breaking the mould with this suggestion (compared to other linkers).
Examples of alternatives in the documentation would be welcome.

It is interesting that managing the stack is still a challenge for 64-bit computing.
Rereading my earlier posts, I should have made clear that my comment "what you have written is just excuses for what is a very poor/lazy system design" was directed at Microsoft and not davidb & mecej4.

The tone of my posts has reflected my desperation with the lack of documentation of stack information and stack adjustment with a number of linkers. I challenge others to identify the documentation of stack adjustment in gFortran ! (Hint: I have found "-fopenmp -fstack-arrays -Wl,-stack,16777216" to work after much effort, but am unsure where I found this documented)

Again Paul, thanks for reviewing and improving the stack adjustment options for SLINK64.

I hope this thread has provided some information for others.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Feb 20, 2019 8:40 am    Post subject: Reply with quote

John

Thanks for the clarification.

The alternative to "stack_size 0x1000000" will be approximately "stack 17" giving you a little more than 16777216.
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