Re: Where is this array stored in memory?
From: Richard Maine (nospam_at_see.signature)
Date: 08/20/04
- Next message: Jugoslav Dujic: "Re: module interface -basic problem"
- Previous message: James Van Buskirk: "Re: module interface -basic problem"
- In reply to: Dimitri: "Where is this array stored in memory?"
- Next in thread: Kevin G. Rhoads: "Re: Where is this array stored in memory?"
- Reply: Kevin G. Rhoads: "Re: Where is this array stored in memory?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 20 Aug 2004 08:12:56 -0700
antoniou@aecom.yu.edu (Dimitri) writes:
> In my program I have an array that is allocated dynamically
> and has dimensions (1000,40000)
My inclination on reading this far right at first was to ask exactly
how the array is declared and what statements do the allocation. If
this were actually a Fortran question, that probably would haave been
important. But further reading revealed that the main parts of this
question doen't really have much to do with Fortran, so this data
isn't needed.
> In two workstations, the program didn't compile at all,
> because there was no space to store the huge array.
I don't think I believe at least part of what you have said above.
Which part to disbelieve I'm not entirely sure. If the array was
actually dynamically allocated, then the compiler would not know
how big it was - that would not be known until run-time. I posit
that either the array wasn't actually dynamically allocated or
that the failure was not actually at compile time.
This might actually be relevant, but I can't tell without a lot more
data. The possible relevance is that sometimes dynamically allocating
arrays can help by using only as much memory as the particular
problem needs at the particular time it needs it. If you aren't
actualy dynamically allocating the memory, then doing so might
possibly help...or maybe not - insufficient data.
>
> it compiled but it ran extremely slowly.
> Judging from the noise of the hard disk spinning, the program temporarily
> wrote the array on disk after each iteration, or something like that.
This is almost surely virtual memory memory swapping to disk. Your
description of the symptome matches perfectly.
> My question:
> From the above behavior, it seems that the four 32 Mb arrays fit in some place
> in memory that eventually can't accomodate 4*40 Mb
> What is this place in memory?
> Can I increase its storage capacity from the command line?
James pointed out the factor of 10 error in the arithmetic. I'll
apply that corrected computation to your question and symptoms.
That place in memory is...the memory...basically all of it that
isn't used for something else. I don't see that you mentioned
how much memory your system has, but with the corrected arithmetic,
your array sizes are in the ballpark of typical system configurations.
Many systems over the last 2 decades or so (and some earlier) use
virtual memory architectures. WIth such architectures, when you try
to use more memory than you physically have, parts of the memory are
written out to disk at times, and then read back in when needed. The
algorithms for determining what parts are written out and when are
more than I want to discuss in this post. It won't specifically be
related to particular Fortran arrays. This all works very nicely when
big chunks of memory aren't being accessed for a long time; they
get shuffled off to disk out of the way, making more real memory available
where it is actually needed.
But if the memory access patterns are such that you don't have large
chunks of memory that sit unaccessed for a (relatively) long time,
then stuff gets rapidly swapped to disk and back a lot. Disks are
a *LOT* slower than memory - several orders of magnitude so. This
kind of behavior can slow programs down by orders of magnitude (and
put a lot of strain on the poor disk head also). It is called
thrashing.
Possible solutions include
1. Reorganizing memory access patterns to work well with the virtual
memory scheme. This can be a big win. On occasion, it can be
trivial and have big benefits. Other times it can be impractical.
Dynamic allocation can occasionally (not always, or even most of
the time, but occasionally) help with this.
2. Redoing the algorithm to use less memory. Wouldn't want to forget
that one. That's one of the most important principles in all of
optimization - to select a good algorithm before optimizing it.
Improvements of many orders of magnitude have been found in areas
of major importance. I don't know enough about your code to offer
anything specific here. And perhaps there is nothing much to be
done. But I just hate to list possibilities without mentioning
that one, as it is so fundamental.
3. Buy more memory. That may well be the easiest solution in your
case.
I don't think the compiler has a command-line switch to do
that. :-)
-- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain | experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
- Next message: Jugoslav Dujic: "Re: module interface -basic problem"
- Previous message: James Van Buskirk: "Re: module interface -basic problem"
- In reply to: Dimitri: "Where is this array stored in memory?"
- Next in thread: Kevin G. Rhoads: "Re: Where is this array stored in memory?"
- Reply: Kevin G. Rhoads: "Re: Where is this array stored in memory?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
