Re: really slow ALLOCATE / MOVE_ALLOC

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

Tom,

> What can't be addressed with a library routine is optimizing
> temporaries, either removing them completely, or reallocating them
> using realloc.   That's where gfortran developers need to pay
> attention.  There are many situations that can be optimized; the
> section of the Fortran standard you cite no more prohibits optimizing
> temporary storage than other parts prohibit CSE.

I agree with you entirely about temporaries.  gfortran's performance
will almost certainly improve markedly if temporaries are not freed
but are kept for reuse via realloc..  One of the reasons why gfortran
does as well as it does, in comparison with commercial products, is
that we have paid a lot of attention to reducing temporary usage, via
fairly rigorous dependency analysis.  We could go further by deploying
loop reversal (patch available), loop order rearrangement(present in
gfortran but commented out because it doesn't work correctly yet) and
breaking up long loops but I rather think that memory management is
the next most effective step.

>
>> Ultimately, of course, the programmer is obliged, if all else fails,
>> to use the same strategy as realloc; allocate oversize and only
>> de-allocate/allocate when needed.
>
> Good implementations of malloc use VM hardware and page remapping,
> rather than reserve extra space.  Look at the mremap system call on
> Linux.

I understand this but reducing the number of system calls by
allocating oversize will certainly result in a performance
improvement.

>
>> This will become and issue when we implement automatic allocation for
>> allocatable arrays, a la f2003.
>
> Well, I think it's important that whoever works on that have a good
> understanding of dynamic memory management strategies, in addition to
> what actual malloc implementations do.  There seem to be a lot of
> prejudices and misconceptions people have about memory management.

True but a naive application with realloc would be a good start:-)

>
> Efficient memory management is at least as hard as good numerics, and
> just as important for high performance computing.  The good news is
> that the Fortran compiler can potentially do a lot more for the
> programmer automatically than C compilers can.
>

Agreed - Paul

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy