Hello,
the attached patch provides a partial fix for the performance issues
in PR 21820 and 23363. Partial, as in improving performance 20-fold
for some cases but still being far away from other compilers. The
patch also solves all mmap related correctness problems, by removing
mmap support from the runtime library.
I gave some reason why I think mmap is not needed here:
Some analysis on why gfortran I/ is slow at
Timing measurements on Linux-x86 for this patch:
PR 21820
No mmap:
/pr21820.gfortran_no_mmap 0,02s user 0,00s system 82% cpu 0,024 total
mmap (current HEAD):
/pr21820.gfortran 0,16s user 0,40s system 102% cpu 0,547 total
delete file before executing for HEAD:
/pr21820.gfortran 0,02s user 0,01s system 134% cpu 0,022 total
ifort 8.0:
/pr21820.ifort 0,01s user 0,00s system 324% cpu 0,003 total
PR 23363
no mmap:
/rdiska.gfortran_no_mmap 0,75s user 0,01s system 98% cpu 0,774 total
with mmap (HEAD):
/rdiska.gfortran 4,11s user 9,38s system 99% cpu 13,560 total
delete file before running HEAD:
/rdiska.gfortran 0,94s user 0,03s system 97% cpu 0,990 total
g77:
/rdiska.g77 0,00s user 0,02s system 74% cpu 0,027 total
ifort 8.0:
/rdiska.ifort 0,03s user 0,11s system 102% cpu 0,137 total
Changelog and patch attached.

Sat, Sep 03, 2005 at 09:23:52PM +0300, Janne Blomqvist wrote:
Timing measurements on Linux-x86 for this patch:

PR 21820

No mmap:

./pr21820.gfortran_no_mmap 0,02s user 0,00s system 82% cpu 0,024 total

mmap (current HEAD):

./pr21820.gfortran 0,16s user 0,40s system 102% cpu 0,547 total

delete file before executing for HEAD:

./pr21820.gfortran 0,02s user 0,01s system 134% cpu 0,022 total

PR 23363

no mmap:

./rdiska.gfortran_no_mmap 0,75s user 0,01s system 98% cpu 0,774 total

with mmap (HEAD):

./rdiska.gfortran 4,11s user 9,38s system 99% cpu 13,560 total

delete file before running HEAD:

./rdiska.gfortran 0,94s user 0,03s system 97% cpu 0,990 total

As to why HEAD is much faster when first deleting the file, it turns
out that when the file needs to be extended the library switches to
the fd method. Doh

Sorry for any potential confusion.

Sat, Sep 03, 2005 at 09:23:52PM +0300, Janne Blomqvist wrote:
Hello,

the attached patch provides a partial fix for the performance issues
in PR 21820 and 23363. Partial, as in improving performance 20-fold
for some cases but still being far away from other compilers. The
patch also solves all mmap related correctness problems, by removing
mmap support from the runtime library.

If we want to keep mmap (perhaps there are situations where it does
bring better performance, although my guess is not measurably so with
the current fine-grained io library), it would be relatively
straightforward to e.g. add a check for a GFRTRAN_USE_MMAP
environment variable when opening a file. That way we'd get the
performance advantages of fd while still enabling those who want mmap
to use it.

If there is some support for this alternative approach I'll retract my
patch removing mmap and implement this instead.

Sat, Sep 03, 2005 at 09:23:52PM +0300, Janne Blomqvist wrote:
Hello,

the attached patch provides a partial fix for the performance issues
in PR 21820 and 23363. Partial, as in improving performance 20-fold
for some cases but still being far away from other compilers. The
patch also solves all mmap related correctness problems, by removing
mmap support from the runtime library.

Tobi has committed the patch (thanks!):