forums.silverfrost.com

PaulLaidler · Posted: Sat Jul 27, 2019 7:16 am Post subject:

John

When you write that "the design of the stack" is lazy, is that directed at Microsoft? In what way might it have been designed differently? I wonder how you have formed this opinion.

Paul

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

PaulLaidler · Posted: Sat Jul 27, 2019 12:31 pm Post subject:

John

The announcement for v8.50 http://forums.silverfrost.com/viewtopic.php?t=3994 includes

DanRRight · Posted: Sat Jul 27, 2019 12:36 pm Post subject:

Paul,

Are the size in 32bit and 64bit when you do /stack=size measured differently?
For sure the size in 32bits is in KBs but you are saying in 64bits it is in MBs?

Do i correctly understand that ini file addition to SLINK was done for convenience? Say if you do something like quick compilation FTN95 prog.f95 /link you will be able to compile it if large stack is needed? (compilation will not go if do that this way FTN95 prog.f95 /link /stack=1024 ). Otherwise there is no problem to add to BAT file /stack=value and forget about it

John,
Doing things by declaring fixed arrays and avoiding allocation/deallocation is just from laziness. Formally with 64bits we have what looks like an infinite ocean of RAM space. And expecting that almost infinity trying to run the code you're abruptly stepping on a rack at the 1/100 of what you have, and even below 32bit limit. Brain just refuses to accept existence of such small stack limit with 64bits and you always waiting that this year or maximum next one the stack concept will be called obsolete. If somebody likes the cars with the manual shift - fine, take and drive them, but most just do not like to deal with something no one knows what it is made for.

PaulLaidler · Posted: Sat Jul 27, 2019 1:49 pm Post subject:

Dan

"stack_size" takes a hex value for the number of bytes.

"stack" takes a decimal value which SLINK64 multiplies by one million to get the number of bytes.

The default value is 32MB but this can be set to some other value using Slink64.ini. This is for users who don't want to use "stack_size" or "size" but would prefer a larger default for the stack size reserve.

I tested it and ran our test suite using a default reserve of 16GB (which is the size of my RAM) and it did not complain but very large local arrays are currently not included in our tests.

It means that having a very large reserve does not appear to cause problems. The operating system will commit memory from this reserve on demand but otherwise the memory is still available for other purposes.

I don't know what will happen when it comes to creating very large local arrays but I recommend having a fire extinguisher to hand.

DanRRight · Posted: Thu Jan 16, 2020 7:38 am Post subject:

I think the error I started this posting was due to either bug in previous build of Windows, or specifically its incorrect handling of resources. Also possible conflict with NVIDIA driver of course.

Since then I updated only Windows twice first to 1903 and then to current build and have not seen stack problems. But sometimes computer graphics froze if demand for memory was to high while plotting in OpenGL. The screen got black for a minute but mostly recovered losing resolution but without putting the Windows do the knees.

After I manually set Windows from automatic handling pagefile to manual size as high as 200 GB (devoting to it fast SSD) there is no problem to plot in OpenGL even 600 million rectangles and simultaneously 3-5 high RAM demand programs can be resident without the need to shutting them off to free the memory. Before I thought that the reason of crashes also could be relatively small RAM addressable limit of processor itself but no, all works OK with such high RAM demands like if only the sky is the limit

And there is no more problems to allocate any size array because there is not enough memory Smile

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney