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 

Access violation error in 64-bit; works in 32-bit
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
DanRRight



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

PostPosted: Fri Aug 02, 2019 9:09 am    Post subject: Re: Reply with quote

JohnCampbell wrote:
Dan, what is a terabyte of random numbers ?

John, Who knows what for this code was written. May be this is just a demo. Or author is writing safe media eraser permanently generating random numbers for multiple times erase of existing data on harddrives and SSD? Or initializing PIC code from some random state. PIC codes may easily deal with terabytes, we generated 40TB just this month. Plus, there are infinite amount of reasons to do things wrong way, anyone has rights to do so.


Last edited by DanRRight on Fri Aug 02, 2019 9:24 am; edited 1 time in total
Back to top
View user's profile Send private message
ahalls_dsc



Joined: 12 Nov 2018
Posts: 16

PostPosted: Fri Aug 02, 2019 9:15 am    Post subject: Re: Reply with quote

mecej4 wrote:
To answer the last question, one needs to know the purpose of the program.

The short test program fills a huge 4-D array with random numbers and does a little bit of averaging on a boundary. The result is neither output nor used in a subsequent calculation. The effect of running the program is nil.

Do you see why a clear and complete problem definition is needed?


The labelled errant code is one line of many hundreds in one module, of many hundreds more of the entire program.

JohnCampbell wrote:
Apart from the other programming errors, it is foolish to put such large arrays on the stack. Their size should be confirmed and if required they should be placed on the heap via ALLOCATE.

There are also other coding errors, such as the use of uninitialized variables and arrays. These errors should be corrected, before claiming there is a compiler error.

Why present this in two forums ?


I don't think I suggested it was a compiler error - though maybe the fact it's in this forum makes that implicit.

The full program aims to relocate a country's worth of employment and population using a distance deterrence function. If I'm understanding this point in the program correctly, the array is necessary to be able to optimise the entire modelled area at once. The modelled area we are working with is many times larger than any previously, hence the overflow and the need for optimisation.

Thanks for confirming that we need to use ALLOCATE - I'm not a programmer (had you guessed?) I'm just debugging to aid the development process, and learning.

PaulLaidler wrote:
The SAVE attribute makes this array storage permanent. It does not go on the stack. When the subroutine is re-entered, data from the previous call is preserved.

It is quite possible that the author does not need/intend to use SAVE in this context.

There should be no problem if SAVE is not used even with very large arrays.

SAVE in one sense is equivalent to using a COMMON block or MODULE for the array but there is currently a limitation of 1GB on SAVEd data which does not apply to COMMON/MODULE data.

SAVEd data is always initialised and packed into the executable so it makes sense to limit the amount you can have.


The issue with SAVE was a new one introduced through my implementation, without proper forethought as to how moving it from a COMMON block would affect the program. As we can see from the final example I shared, it wasn't needed to demonstrate what turned out to be a rookie error regarding stack size.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Aug 02, 2019 9:37 am    Post subject: Reply with quote

One positive moment i found playing with this demo and my own programs which were causing stack overflow in 64bits. Though /stack:2048 had not solve the problem of this original poster, it positively influenced my OpenGL parts of programs which before were getting stack overflow at minuscule array dimensions. I use slink64 with INI file
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Aug 02, 2019 12:46 pm    Post subject: Reply with quote

mecej4

I was mistaken. A simple change to FTN95 provides for an improved error message with the name of the offending array together with the line number where the array is declared.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1200

PostPosted: Fri Aug 02, 2019 1:03 pm    Post subject: Reply with quote

Paul, that is a very welcome piece of news, and is certain to cause many users to look forward to the next version of the compiler.

As we have seen recently from this thread and others, users are applying the Silverfrost compiler to larger and more ambitious projects. As a result, we are seeing more instances of pushing against the boundaries of what the compiler can handle. It is gratifying that in almost every case the design of the new 64-bit FTN95 appears to be such that a fix for a reported problem is being made in time for the next release.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1200

PostPosted: Fri Aug 02, 2019 3:46 pm    Post subject: Re: Reply with quote

ahalls_dsc wrote:

The full program aims to relocate a country's worth of employment and population using a distance deterrence function. If I'm understanding this point in the program correctly, the array is necessary to be able to optimise the entire modelled area at once. The modelled area we are working with is many times larger than any previously, hence the overflow and the need for optimisation.


Quite often, the complexity of the algorithm used for a class of problems is such that when the problem size is increased drastically the previously well-performing algorithm becomes unsuitable. For example, in FEA models, a banded matrix solver is used instead of a dense matrix solver.

Another issue, which has already been discussed somewhat, is that when the problem becomes huge it is no longer feasible to load all the data, process everything in memory, and then write out the results.

Do you have a mathematical description of the problem, and some references to previous work?
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Aug 03, 2019 7:39 pm    Post subject: Reply with quote

Paul,
By the way the demo example above with SAVE did not increase EXE size. But major question is why /stack:3000 or larger does not make this demo to work as it should be?
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Aug 03, 2019 8:07 pm    Post subject: Reply with quote

Paul,
By the way the demo example above with SAVE did not increase EXE size. But major question is why /stack:3000 or larger does not make this demo to work as it should be?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Aug 04, 2019 8:01 am    Post subject: Reply with quote

A local array with the SAVE attribute does not go on the stack.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Aug 04, 2019 9:58 am    Post subject: Reply with quote

But does it help? When i add SAVE to the code above i get this.

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


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

PostPosted: Sun Aug 04, 2019 11:30 pm    Post subject: Reply with quote

This access violation occurs because of a bug in FTN95 which has already been fixed. When corrected FTN95 provides an error report something like....

Quote:
error 1207 - AMD backend failure:Insufficient static store for DDFUNCVAL at line 5


This is because there is currently a 1GB limit on the amount of SAVEd data that is allowed.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2144
Location: Sydney

PostPosted: Tue Aug 06, 2019 5:59 am    Post subject: Reply with quote

Regarding the use of large arrays in COMMON with FTN95 /64, Silverfrost FTN95 appears to be unique in it's implementation of large COMMON arrays, while most other compilers (including iFort and gFortran) do not allow large COMMON.
It is a shame that other compilers do not learn from FTN95's approach. (probably because they want to remove COMMON from the language!!)

If you want to use large arrays, the most portable way is to place them in a MODULE and use ALLOCATE when the required size is known.

This should be preceded by a check of their memory requirement, as the more common problem to occur is that the memory required exceeds either the amount of physical memory installed or the amount of virtual memory enabled in c:\pagefile.sys. Either of these mistakes can freeze the pc and be a difficult crash to recover from.
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