Hello,
I spent some time this weekend wondering about the performance of the
i/o library (more on that later), and I think I found a simple bug in
libgfortran/io/unix.c. Namely it seems to assume that all non-mmapped
files are not seekable. This might or might not be true. Anyway, we
have a convenient function for figuring this out, so why not use it?
ChangeLog:
* unix.c (stream_at_bof): Don't assume that all non-mmapped files
are non-seekable. (stream_at_eof): Likewise.
The patch itself is attached.
About the performance issues, in some cases gfortran (and g77 for that
matter) seem to be clobbered pretty badly (10X) by ifort (and
presumably some other commercial compilers as well). See e.g. PR
16339. I figured that it might be because gfortran uses mmap and ifort
doesn't, and also because ifort uses rather big writes in 256 kB
chunks whereas gfortran uses 8 kB. I tried changing libgfortran to not
use mmap, and the execution time of the test in PR 16339 dropped, but
not by much (from ~1.6 s to ~1.4 s). Also, increasing the buffer size
didn't change things much.
Looking at the execution profile using gprof it seems that the code
spends a large amount of time in the *_alloc_w_at functions, in total
about 45 %. In fact, alloc_w_at is called for every one of the 10e6
elements in the array. So, regardless of the relative merits of mmap
vs. (f)read/write, I guess the key to improving i/o performance would
be to make the library interface more coarse grained, e.g. enabling
transfer of contigous array sections in one go instead of looping over
all the individual elements?