This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: really slow ALLOCATE / MOVE_ALLOC


> I don't see how this is possible. Your benchmark below hits exactly the point I mentioned
> above, i.e. there is never another allocation in the way preventing realloc() from just enlarging the existing area.

Actually, if you run strace on the binary, you'll see that it does
call mremap; you get the same behavior for many simultaneous
allocations.

> In glibc malloc, the mmap threshold is nowadays dynamically between 128 kB and 64 MB,
> much larger than a single page.

Yes, but that's mostly due to the history of that code.  Even with
those historical limitations, Linux realloc is already orders of
magnitude faster than the fastest possible solution currently
available in gfortran, and the difference is only going to get larger
in the future.

> As a result googling around you'll find plenty of people complaining that realloc performance sucks on their system compared to Linux.

Yes; I think Linux is going to drive other vendors to implement better
reallocs in their malloc implementations as well.

> As a result googling around you'll find plenty of people complaining that realloc performance
> sucks on their system compared to Linux. This doesn't necessarily mean that all other
> mallocs are bad, but perhaps realloc performance is not that big deal for most workloads.

It's not a big deal for most other languages.  In C and C++,
developers get full control over memory management, and they can
implement allocation strategies that work well without relying on
realloc, but Fortran doesn't permit that. Other language runtimes
don't use malloc/free at all and manipulate the VM hardware directly,
but runtimes like gfortran don't do that.  Calling realloc in some
places in Fortran isn't as good as implementing a Fortran-specific
storage allocator would be, but it's better than the current

> Well, such a REALLOCATE statement would necessarily be more complicated than realloc
> due to the need to handle multidimensional arrays

Given Fortran's array facilities, a useful REALLOCATE statement would
limit how multidimensional arrays can be reallocated, but there's
nothing wrong with that.

So, taking that back to the beginning: I think supporting "a = [a,x]"
via realloc would be nice, and providing a simple REALLOCATE library
subroutine would also be good.  The latter I can do myself; for the
former, I hope that the compiler writers will consider implementing
it.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]