View previous topic :: View next topic |
Author |
Message |
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Fri Apr 27, 2018 10:48 am Post subject: Re: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2578 Location: Sydney
|
Posted: Fri May 25, 2018 11:38 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8003 Location: Salford, UK
|
Posted: Thu Feb 14, 2019 11:40 am Post subject: |
|
|
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 |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2393 Location: Yateley, Hants, UK
|
Posted: Thu Feb 14, 2019 1:54 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8003 Location: Salford, UK
|
Posted: Thu Feb 14, 2019 4:04 pm Post subject: |
|
|
I have added a new SLINK64 command "stack" that takes a value which is the number of (decimal) megabytes. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2393 Location: Yateley, Hants, UK
|
Posted: Thu Feb 14, 2019 4:12 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8003 Location: Salford, UK
|
Posted: Thu Feb 14, 2019 4:49 pm Post subject: |
|
|
Eddie
I assume decimal 10^6 but it could be changed. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2393 Location: Yateley, Hants, UK
|
Posted: Thu Feb 14, 2019 5:01 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2578 Location: Sydney
|
Posted: Wed Feb 20, 2019 8:01 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8003 Location: Salford, UK
|
Posted: Wed Feb 20, 2019 8:40 am Post subject: |
|
|
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 |
|
|
|