Prev: the meaning
Next: Intel Fortran compiler
From: Dan on 9 Jun 2010 16:15
I'm using Fortran 95 ( it may be a while before I'm up to a compiler
for 2003 or 2008 ).

Say that I do something like the following:

n = 10000
ALLOCATE( x(n) )

::::::::::: do stuff ::::::::::::

I now need x(:) to hold more data than I've allocated space for. I
could do something like this:

n = 15000
ALLOCATE( y(n) ) <--- assumes I'll now use Y() instead
of X().

DEALLOCATE( x )

Or, I could even create another temporary array to hold the x() data
in while I deallocate x and then reallocate it to the new size and
then move the old data into the new x()... and then deallocate the
temporary array. Of course, I could use pointers too. It all
seems like a bit of a pain though doesn't it????

So.... ( disregarding the fact that these types of ops are probably
better handled with some of the newer F2003+ capabilities which I've
not spent time with yet )....

Considering todays operating systems ( mainly Windows for me ), is
such a "Reallocation" scheme going to save memory or help it. I
assume fragmented memory is occurring with these types of
applications. Are todays operating systems better at managing memory
such that fragmentation problems aren't too bad??? Put another
way... should I worry about this much if I'm working with large
amounts of data?

Thanks, Dan :-)
From: Richard Maine on 9 Jun 2010 16:36
Dan <dantex1(a)aol.com> wrote:
....
> I now need x(:) to hold more data than I've allocated space for. I
> could do something like this:
>
> n = 15000
> ALLOCATE( y(n) ) <--- assumes I'll now use Y() instead
> of X().
>
> DEALLOCATE( x )
>
> Or, I could even create another temporary array to hold the x() data
> in while I deallocate x and then reallocate it to the new size and
> then move the old data into the new x()... and then deallocate the
> temporary array. Of course, I could use pointers too. It all
> seems like a bit of a pain though doesn't it????

Yes. That's why the move_alloc in f2003 (which ought to be implemented
in most f95 compilers by now, I'd think. It is trivial for the compiler
to do).
>
> So.... ( disregarding the fact that these types of ops are probably
> better handled with some of the newer F2003+ capabilities which I've
> not spent time with yet )....

Ok, though see above note about move_alloc. It basically saves you the
step of needing another allocation to move the data back to x, this
making it about the same steps to use allocatable as it is to use
pointers.

> Considering todays operating systems ( mainly Windows for me ), is
> such a "Reallocation" scheme going to save memory or help it.

Compared to what? I lost the question in here. You gave an example of
needing more memory than previously allocated. If you need more memory
then doing nothing is not an option, so that can't be what you are
comparing to.

You can save memory (and time, and complexity) by using the f2003
move_alloc instead of doing a second allocation and copy, but that
didn't sound to me like what you were comparing to.


--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: robin on 9 Jun 2010 20:05
"Dan" <dantex1(a)aol.com> wrote in message news:34fb8399-f405-4acf-807a-8b124d39d32f(a)j12g2000pri.googlegroups.com...
| I'm using Fortran 95 ( it may be a while before I'm up to a compiler
| for 2003 or 2008 ).
|
| Say that I do something like the following:
|
| n = 10000
| ALLOCATE( x(n) )
|
| ::::::::::: do stuff ::::::::::::
|
| I now need x(:) to hold more data than I've allocated space for. I
| could do something like this:
|
| n = 15000
| ALLOCATE( y(n) ) <--- assumes I'll now use Y() instead
| of X().
|
| DEALLOCATE( x )
|
| Or, I could even create another temporary array to hold the x() data
| in while I deallocate x and then reallocate it to the new size and
| then move the old data into the new x()... and then deallocate the
| temporary array. Of course, I could use pointers too. It all
| seems like a bit of a pain though doesn't it????
|
| So.... ( disregarding the fact that these types of ops are probably
| better handled with some of the newer F2003+ capabilities which I've
| not spent time with yet )....
|
| Considering todays operating systems ( mainly Windows for me ), is
| such a "Reallocation" scheme going to save memory or help it. I
| assume fragmented memory is occurring with these types of
| applications. Are todays operating systems better at managing memory
| such that fragmentation problems aren't too bad??? Put another
| way... should I worry about this much if I'm working with large
| amounts of data?

There are alternatives.
One is to use direct access I/O.

Simplest is to allocate a new, larger, array and then to copy the existing elements
into it, and then to de-allocate the old array.


From: Dan on 10 Jun 2010 16:52
What I was attempting to ask in the last part of my post was... if
you do a lot of allocating and reallocating of memory, will that
fragment the memory in such a way as to possibly cause problems. Sort
of like a hard disk gets fragmented and performance then degrades.
With memory, is the operating system generally smart enough to
"unfragment" the holes left in memory due to a deallocate.

Dan
From: glen herrmannsfeldt on 10 Jun 2010 20:49
Dan <dantex1(a)aol.com> wrote:

> What I was attempting to ask in the last part of my post was... if
> you do a lot of allocating and reallocating of memory, will that
> fragment the memory in such a way as to possibly cause problems. Sort
> of like a hard disk gets fragmented and performance then degrades.
> With memory, is the operating system generally smart enough to
> "unfragment" the holes left in memory due to a deallocate.

On most systems, it can't defragment. If there are pointers
(explicit or implicit) to the memory, the way addressing is done
on most systems, they can't be moved.

The Fortran 95 way to change the size of an allocatable variable
is something like: Allocate a temporary, copy the data to the
temporary, deallocate the original, allocate a new, larger version,
copy the data over, deallocate the temporary. Two copies are done.

With the Fortran 2003 move_alloc, you can do it with one copy and
one allocate, which is somewhat better. Allocate new space,
copy data over, move_alloc over the old one. Only one copy
is needed.

In both cases, it is possible to be unlucky, if doing this in
a loop, such that the deallocate blocks are always too small for
the next allocated block. That is especially easy if more than
on such array is being resized in the loop.

C has realloc() that, on most unix and unix-like systems, has
the possibility of increasing the size in place. If the array
is at the end of allocated memory it can usually be increased
in place. Using a single realloc() in a loop will eventually
end up and the end of memory and resize in place. Doing two
realloc()'s in a loop will have similar fragmentation problems
as the above Fortran cases. Zero or one copy is needed.

-- glen
 | 
Pages: 1
Prev: the meaning
Next: Intel Fortran compiler