This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: timeline?
Thomas Breuel wrote:
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.
Oh, sorry about that then. Yes, I suppose this would be a possible
optimization target. Though it would require the same kind of analysis
as is already done for array expressions, to prove that a temporary
array is not needed.
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.
Yes, sorry for leading you on another wild goose chase. The point of
MOVE_ALLOC is of course to avoid the second copy as you would have to do
in F95 to resize an array. Instead MOVE_ALLOC modifies the descriptor of
a to point to temp's data, and frees the original a data, and sets temp
to deallocated.
Replacing this with a realloc would require recognizing and optimizing
the entire pattern, and GFortran doesn't do that; it just calls
malloc.
Right. I find it unlikely that such an optimization will be done by
gfortran or any other compiler.
(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.)
Huh? Yeah, that sounds bad.
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,
The C compiler itself as nothing to do with realloc. It sees it as just
another function.
Anyway, my point is that if some other allocation has used the space
behind the object you want to resize, then realloc() has to do a new
allocation and copy the data over. Unless, as I mentioned previously,
the allocation is big enough that malloc has switched from (s)brk to mmap.
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.
Yes, that's right. Personally I suspect that liberal use of all the
fancy F2003 features will lead to the same kind of heap fragmentation
issues that frequently plague C++.
As an aside, p = realloc(p, ...) is a bad idea
I suggest you think that through a little more carefully.
I've thought about it "a little more carefully", and I still maintain
that you'll leak memory if realloc() fails. Unless you previously stored
a copy of p of course, but that goes without saying.
--
Janne Blomqvist