Prev: Functions with side effects
Next: creating shared library from Fortran
From: Gordon Sande on 15 Jul 2010 09:31
On 2010-07-15 10:18:41 -0300, Arjen Markus <arjen.markus895(a)gmail.com> said:

> On 15 jul, 14:12, "Philipp E. Weidmann" <philipp.weidm...(a)gmx.de>
> wrote:
>> A Watcher wrote:
>>> I'm supporting a giant legacy app that allocates memory in lots of
>>> places. �It sure would be handy to have a "deallocate all" function.
>>> Does any version of fortran have such a thing?
>>
>> I'd imagine that, if the app is indeed big enough and the project budget
>> permits it, it would be possible to write a script that generates such a
>> deallocation routine.
>>
>> That script would only need to parse the entire code, collect all
>> pointer-based variables and allocatable arrays, put them in a COMMON
>> block or MODULE if neccessary (so they are globally accessible) and then
>> generate a large DEALLOCATE statement.
>>
>> If you're savvy enough, such a script could probably be written in
>> Python or the likes in a single day.
>>
>> However, as others have pointed out, everything gets deallocated on exit
>> anyway, so you should seriously think about whether that is really
>> neccessary.
>>
>> --
>> -- Philipp Emanuel Weidmann
>
> If the allocation is done for ALLOCATABLE items and not for POINTER
> items,
> then garbage collection is automatic too.
>
> Perhaps "A Watcher" should explain what the symptoms are of the
> program
> that prompted this question, because such gross memory management as
> asked about seems unlikely to be useful, except, indeed at the end
> of the program, but then the OS should take care of it.
>
> Regards,
>
> Arjen

A common problem is turning a main program which executed once into a
subroutine that can be executed several times. The ALLOCATE of an
ALLOCATABLE will fail on the second execution. The memory leak for
pointers may cause other failures after repeated executions of the
new subroutine.

An intermediate solution is to repeatedly execute the main from a script
but that may not make sense for all sorts of good reasons.

A function that gives the total memory allocated would be very useful.
(Hint for compiler vendors!!) It would allow one to monitor the success
of the deallocations as wellas the presence of memory leaks. Garbage
collection is nice but not always present and it has its own drawbacks.




From: Ron Shepard on 17 Jul 2010 17:20
In article <2010071510314516807-GordonSande(a)gmailcom>,
Gordon Sande <Gordon.Sande(a)gmail.com> wrote:

> A function that gives the total memory allocated would be very useful.
> (Hint for compiler vendors!!)

Yes, this cannot be overstated. I know many legacy codes that avoid
fortran allocate/deallocate and automatic arrays for this very reason,
preferring instead to use their legacy approach. Particularly on
parallel computers which have (relatively) limited memory, it is
critical to monitor the memory usage. Sometimes, programs even choose
which branches to take (and which algorithms to use) based on runtime
memory usage. Sometimes you must submit your job to a different queue
depending on its memory usage, and if it overruns (say, because of some
automatic array somewhere) your job will abort.

$.02 -Ron Shepard
From: glen herrmannsfeldt on 17 Jul 2010 20:06
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
> In article <2010071510314516807-GordonSande(a)gmailcom>,
> Gordon Sande <Gordon.Sande(a)gmail.com> wrote:

>> A function that gives the total memory allocated would be very useful.
>> (Hint for compiler vendors!!)

> Yes, this cannot be overstated. I know many legacy codes that avoid
> fortran allocate/deallocate and automatic arrays for this very reason,
> preferring instead to use their legacy approach.

There are other Fortran features that you also can't use. Array
operations can require temporary arrays. A PL/I compiler I used
many years ago gave a warning when a temporary array was to be used,
such that one might modify the code. I don't know if any Fortran
compilers do that. (That was when memories were smaller, though.

> Particularly on
> parallel computers which have (relatively) limited memory, it is
> critical to monitor the memory usage. Sometimes, programs even choose
> which branches to take (and which algorithms to use) based on runtime
> memory usage. Sometimes you must submit your job to a different queue
> depending on its memory usage, and if it overruns (say, because of some
> automatic array somewhere) your job will abort.

It would also be nice to know how much memory is available, but
many systems don't have a good way to tell you that. On many, it
can change as other programs allocate and free memory, making it
even harder. (As soon as you find out how much is available,
some other task might use some of it.) In most cases, the ability
to detect allocation failure and retry with a different size is
about as good as you can do.

-- glen
From: fj on 19 Jul 2010 05:00
On 18 juil, 02:06, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> Ron Shepard <ron-shep...(a)nospam.comcast.net> wrote:
> > In article <2010071510314516807-GordonSande(a)gmailcom>,
> > Gordon Sande <Gordon.Sa...(a)gmail.com> wrote:
> >> A function that gives the total memory allocated would be very useful.
> >> (Hint for compiler vendors!!)
> > Yes, this cannot be overstated.  I know many legacy codes that avoid
> > fortran allocate/deallocate and automatic arrays for this very reason,
> > preferring instead to use their legacy approach.  
>
> There are other Fortran features that you also can't use.  Array
> operations can require temporary arrays.  A PL/I compiler I used
> many years ago gave a warning when a temporary array was to be used,
> such that one might modify the code.  I don't know if any Fortran
> compilers do that.  (That was when memories were smaller, though.

The intel compiler, with the right compiling option, issues such
warning when allocating a temporary array to pass it by argument to a
subroutine or function.

But the warning is there to indicate a possible performance loss.
>
> > Particularly on
> > parallel computers which have (relatively) limited memory, it is
> > critical to monitor the memory usage.  Sometimes, programs even choose
> > which branches to take (and which algorithms to use) based on runtime
> > memory usage.  Sometimes you must submit your job to a different queue
> > depending on its memory usage, and if it overruns (say, because of some
> > automatic array somewhere) your job will abort.
>
> It would also be nice to know how much memory is available, but
> many systems don't have a good way to tell you that.  On many, it
> can change as other programs allocate and free memory, making it
> even harder.  (As soon as you find out how much is available,
> some other task might use some of it.)  In most cases, the ability
> to detect allocation failure and retry with a different size is
> about as good as you can do.
>
> -- glen

First  |  Prev  | 
Pages: 1 2
Prev: Functions with side effects
Next: creating shared library from Fortran