Prev: problem in interface
Next: Fortran in Physics - meeting in London
From: Paul van Delst on 25 May 2010 16:06
Hello,

Can some kind, patient person explain exactly what the use of static memory entails? For
example, if one uses the "-fstatic" option for a compiler.

A colleague is having an issue with some code that runs fine on one machine (#1: redhat 4,
32 bit, g95 v4.0), but bombs on another (#2: redhat 3, 32 bit, g95 v4.1). And by bombs I
mean it runs to completion, but the results are full of NaN's.

One of the debug suggestions I made was to *remove* the "-fstatic" switch from the
compile. When she did that the runs bombed on both machines. She asked me why that would
happen and I have to admit I was at a bit of a loss to explain it. My own experience is
built around usage, not theory.

What I did bumble on about (gleaned from various google searches) was:

<quote>
Variables that are stored in static memory are allocated when a program is first run.
Thus, the variable remains in memory for the duration of the program and, typically, its
value is retained between calls to procedures.

Also, static variables tend to be initialized (i.e. set to zero) when the program is started.

Static variables behave similarly to SAVE'd variables (but I'm sure there are some
differences... not sure what they are)

Thus, if the code depends on variables being static, basically it is not very robust code
(as you are discovering) since the behaviour of assuming initialised variables is simply
dangerous.
</quote>

Can someone grade my response above with some additional information? I don't think static
and SAVE are the same, but an understanding of the differences elude me.

Any info appreciated.

cheers,

paulv
From: Gordon Sande on 25 May 2010 16:44
On 2010-05-25 17:06:23 -0300, Paul van Delst <paul.vandelst(a)noaa.gov> said:

> Hello,
>
> Can some kind, patient person explain exactly what the use of static
> memory entails? For
> example, if one uses the "-fstatic" option for a compiler.
>
> A colleague is having an issue with some code that runs fine on one
> machine (#1: redhat 4,
> 32 bit, g95 v4.0), but bombs on another (#2: redhat 3, 32 bit, g95
> v4.1). And by bombs I
> mean it runs to completion, but the results are full of NaN's.
>
> One of the debug suggestions I made was to *remove* the "-fstatic"
> switch from the
> compile. When she did that the runs bombed on both machines. She asked
> me why that would
> happen and I have to admit I was at a bit of a loss to explain it. My
> own experience is
> built around usage, not theory.
>
> What I did bumble on about (gleaned from various google searches) was:
>
> <quote>
> Variables that are stored in static memory are allocated when a program
> is first run.
> Thus, the variable remains in memory for the duration of the program
> and, typically, its
> value is retained between calls to procedures.
>
> Also, static variables tend to be initialized (i.e. set to zero) when
> the program is started.

Separate issue. More likely to get left over program or other garbage!
Some loaders
will give you zeroes, or other requested values. Some of the default requested
values are things like "DEADMEAT" as characters ,i.e. someones
editorial comment
on your using non-initialized values. Security and the contents of new
memory is
a separate topic.

> Static variables behave similarly to SAVE'd variables (but I'm sure
> there are some
> differences... not sure what they are)
>
> Thus, if the code depends on variables being static, basically it is
> not very robust code
> (as you are discovering) since the behaviour of assuming initialised
> variables is simply
> dangerous.
> </quote>
>
> Can someone grade my response above with some additional information? I
> don't think static
> and SAVE are the same, but an understanding of the differences elude me.

Static is a simple efective implementation of SAVE. Save is something that acts
"as if" it were static. The "as if" can take a bit of work to mix with other
storeage schemes but that is someone else's problem. Save with
recursion is an extra
level of complication so I will ignore it here.

> Any info appreciated.
>
> cheers,
>
> paulv

Does your system have a "save everything" flag as well as a static. Try
it it there is one.
But it sounds like a garden variety bug, probably an uninitilaized
variable. There are good
tools for dealing with those. They tend to be developed away from the
bazaar of open source.








From: glen herrmannsfeldt on 25 May 2010 17:49
Gordon Sande <Gordon.Sande(a)gmail.com> wrote:
> On 2010-05-25 17:06:23 -0300, Paul van Delst <paul.vandelst(a)noaa.gov> said:

>> Can some kind, patient person explain exactly what the use
>> of static memory entails? For example, if one uses the
>> "-fstatic" option for a compiler.

>> A colleague is having an issue with some code that runs fine
>> on one machine (#1: redhat 4, 32 bit, g95 v4.0), but bombs
>> on another (#2: redhat 3, 32 bit, g95 v4.1). And by bombs I
>> mean it runs to completion, but the results are full of NaN's.

There are a fair number of possible causes for that...

>> One of the debug suggestions I made was to *remove* the
>> "-fstatic" switch from the compile. When she did that the
>> runs bombed on both machines. She asked me why that would
>> happen and I have to admit I was at a bit of a loss to explain it.
>> My own experience is built around usage, not theory.

>> What I did bumble on about (gleaned from various google
>> searches) was:

>> <quote>
>> Variables that are stored in static memory are allocated
>> when a program is first run. Thus, the variable remains in
>> memory for the duration of the program and, typically, its
>> value is retained between calls to procedures.

It is fairly rare for programs to depend on that, and you
usually know when they do. One of the more common cases is
the internal state of a random number generator. Otherwise,
some routines count how many times they have been called for
a variety of reasons.

>> Also, static variables tend to be initialized
>> (i.e. set to zero) when the program is started.

That is required by C, and tends to happen in other compilers
that are based on the back end of a C compiler. It is
not required by Fortran.

> Separate issue. More likely to get left over program or other garbage!
> Some loaders will give you zeroes, or other requested values.
> Some of the default requested values are things like "DEADMEAT"
> as characters ,i.e. someones editorial comment on your using
> non-initialized values. Security and the contents of new
> memory is a separate topic.

Well, if one uses uninitialized variables it isn't hard to
get NaNs out. Also, the program can be very sensitive to other
changes, such as the order of declaration of variables.

>> Static variables behave similarly to SAVE'd variables
>> (but I'm sure there are some differences... not sure what they are)

Fortunately this was discussed her in the last few days.

>> Thus, if the code depends on variables being static, basically
>> it is not very robust code (as you are discovering) since the
>> behaviour of assuming initialised variables is simply dangerous.
>> </quote>

Well, you can initialize static variables. In Fortran, that is
done with the DATA statement, which also gives the SAVE attribute.
It is usually not a good idea to static initialize a large array
to zero (or other single value), and is rarely needed.

>> Can someone grade my response above with some additional
>> information? I don't think static and SAVE are the same,
>> but an understanding of the differences elude me.

Well, SAVE is pretty much the way you ask for static data
in Fortran, in addition to the DATA statement. Asking for automatic
(non-static) is a little harder in Fortran.

> Static is a simple efective implementation of SAVE. Save is
> something that acts "as if" it were static. The "as if" can
> take a bit of work to mix with other storeage schemes but
> that is someone else's problem. Save with recursion is an extra
> level of complication so I will ignore it here.

Well, recursion is where the distinction becomes important.
Non-SAVEd variables can pretty much be either static or automatic
when a routine does not have the RECURSIVE attribute. With
RECURSIVE, local variables pretty much have to be automatic,
unless the SAVE attribute is specified or implied.

> Does your system have a "save everything" flag as well as a
> static. Try it it there is one. But it sounds like a garden
> variety bug, probably an uninitilaized variable. There are good
> tools for dealing with those. They tend to be developed away from the
> bazaar of open source.

I agree, it is most likely an ordinary undefined variable problem,
such that the problem moves or changes as variables move around.

-- glen
From: mecej4 on 25 May 2010 18:28
Paul van Delst wrote:

> Hello,
>
> Can some kind, patient person explain exactly what the use of static
> memory entails? For example, if one uses the "-fstatic" option for a
> compiler.
>
<--CUT-->
>
> Can someone grade my response above with some additional information? I
> don't think static and SAVE are the same, but an understanding of the
> differences elude me.
>
> Any info appreciated.
>
> cheers,
>
> paulv
To add to what others have already written in response to your query:

1. Writing a DATA statement for a variable(s) changes the allocation type
from AUTOMATIC (if that is the default) to SAVE.

2. The word "static" is rarely used in Fortran standards and documentation,
which prefer the word SAVE. [It is possible that some
hardware-knowledgeable readers would be confused by reading "static
memory", because to them it means SRAM (as opposed to DRAM). Some early 386
PCs achieved spectacular performance ratings compared to their predecessors
by using rather expensive SRAM for the whole of their system memory.]

3. The SAVE attribute does not imply "initialize to zero" (or any
initialization); even though many compilers may be asked to do that with
options such as -zeroise, etc.

4. Early mainframes (IBM, CDC, UNIVAC, Honeywell, etc.) tended to give you
no opting out of using SAVE. In addition, they had loaders that zeroed out
memory before loading your program. They also had rather odd (from today's
perspective) restrictions on variables in COMMON, three types of COMMON,
BLOCKDATA, etc, all related to sharing and initializing variables and using
them as arguments.

Software developed on these machines was often considered "debugged" when,
with the default zero initialization, correct results were produced
consistently. These same routines (many are in Netlib), run on a Linux
system, may very well give erroneous results even with a -static compiler
switch used.

-- mecej4
From: John Paine on 25 May 2010 20:03

"Paul van Delst" <paul.vandelst(a)noaa.gov> wrote in message
news:hthajv$oqj$1(a)news.boulder.noaa.gov...
> Hello,
>
> Can some kind, patient person explain exactly what the use of static
> memory entails? For
> example, if one uses the "-fstatic" option for a compiler.
>
> A colleague is having an issue with some code that runs fine on one
> machine (#1: redhat 4,
> 32 bit, g95 v4.0), but bombs on another (#2: redhat 3, 32 bit, g95 v4.1).
> And by bombs I
> mean it runs to completion, but the results are full of NaN's.
>
> One of the debug suggestions I made was to *remove* the "-fstatic" switch
> from the
> compile. When she did that the runs bombed on both machines. She asked me
> why that would
> happen and I have to admit I was at a bit of a loss to explain it. My own
> experience is
> built around usage, not theory.
>
> What I did bumble on about (gleaned from various google searches) was:
>
> <quote>
> Variables that are stored in static memory are allocated when a program is
> first run.
> Thus, the variable remains in memory for the duration of the program and,
> typically, its
> value is retained between calls to procedures.
>
> Also, static variables tend to be initialized (i.e. set to zero) when the
> program is started.
>
> Static variables behave similarly to SAVE'd variables (but I'm sure there
> are some
> differences... not sure what they are)
>
> Thus, if the code depends on variables being static, basically it is not
> very robust code
> (as you are discovering) since the behaviour of assuming initialised
> variables is simply
> dangerous.
> </quote>
>
> Can someone grade my response above with some additional information? I
> don't think static
> and SAVE are the same, but an understanding of the differences elude me.
>
> Any info appreciated.
>
> cheers,
>
> paulv

It seems to me that what you are really looking for is a simple to way to
find where the program is going wrong. This is currently masked by the
floating-point exception handler generating a NaN and the program continuing
on to the bitter end without generating anything useful. I don't know what
the switch is for the g95 compiler, but for the Intel compiler you set the
exception handler to use Underflow gives 0.0; Abort on other IEEE exceptions
(/fpe:0). This means that the program crashes as soon as it encounters the
operation that causes the NaN result. That should then help you identify
where it happens and more importantly why it is happening.

On a more subjective note, I have experienced similar problems where the
same program behaves differently on different (but very similar) machines.
Quite intriguing, but horrible to debug. My all-time favourite was the
machine where the program ran fine, but only if the network driver was not
loaded. Another favourite was the one where two instances of the program had
to be started, the first one would not run correcly but could be left in the
background while the second one ran just fine. Couldn't solve either of
those, but both went away when the computers were retired and replaced with
new ones.


 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: problem in interface
Next: Fortran in Physics - meeting in London