Re: timeline?

["Thomas Breuel" <tmbdev at gmail dot com>]

>> Are you saying that a = [a,1] actually uses realloc internally?
>>
>> Even with MOVE_ALLOC, if you try to do the same thing, you end up
>> making one copy.
>
> IIRC both of these use realloc behind the covers.

In GFortran 4.3.2, a = [a,1] calls malloc, even with -O3.  It would be
nice if it did call realloc.

The standard way of using MOVE_ALLOC for resizing is (Metcalf, Reid, Cohen):

allocate(temp(n,m))
temp(1:size(a,1),1:size(a,2)) = a
call move_alloc(temp,a)

The copy happens during the assignment statement, before the
move_alloc.  At that point, both a and temp are in memory which, for
large arrays, can be far too large.

Replacing this with a realloc would require recognizing and optimizing
the entire pattern, and GFortran doesn't do that; it just calls
malloc.

(Tracing this, I just discovered that statements like temp(1:size(a))
= a make one shared library call to _gfortran_size* for each element
transferred, even on -O3, which would seem to be a potential
performance problem.)

> There is no guarantee of this. Yes, realloc() tries to avoid copying, but
> it's not always possible.

Of course, there is no guarantee.  If a C compiler doesn't implement
realloc efficiently, then some programs will simply not work on some
hardware because they run out of memory, and some other programs will
run slowly.  That's no different from any other intrinsic in C or
Fortran.  There is no guarantee, for example, that my Fortran compiler
lets me allocate large arrays or doesn't fragment memory
unnecessarily.

Tom

PS:

> As an aside, p = realloc(p, ...) is a bad idea

I suggest you think that through a little more carefully.