[gfortran] Patch for potential bug in i/o library

[bud davis]

Janne Blomqvist wrote:

>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?
>
>  
>
you are onto the big performance problem in the I/O library today.  
until we deal with arrays as contiguos blocks of memory the performance 
will be dismal. 

we get that fixed, then the buffer size and mmap yes / no will become 
significant......


--bud