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

[Janne Blomqvist]

[Dropped gcc-patches]

On Sun, Jun 05, 2005 at 08:50:33PM -0500, bud davis wrote:
> Thomas Koenig wrote:
> 
> >Janne Blomqvist wrote:
> >
> > 
> >
> >>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?
> >>   
> >>
> >
> >Definitely.  For arrays, it would be straightforward to pass an
> >array descriptor to the i/o library, and have it handled there.
> >Lots of m4 to be written :-)  Implied do loops will be harder,
> >but not as important.  If these can be converted to an
> >array descriptor (sort of, using temporaries), that would be ideal.
> >
> > 
> >
> if someone grabs this idea and implement it, please also keep in mind 
> the need to know how many bytes will go into an unformatted sequential 
> record before it is written....
> 
> the seeking back into the file to write the start marker will always be 
> a big performance loss (esp for NFS mounted files).

Ah yes, that's a big one. Even without implementing any of the
"transfer arrays in one go" stuff I think this could help a lot even
in the case of one huge record as in PR 16339 since if the length of
the transfer would be known before any actual transfer takes place,
one could presumably do one big alloc_* via st_read/write for the
entire record instead of allocating separately for each element. Would
just have to make sure that big allocs and buffering play well
together, as currently an alloc bigger than the buffer size never
really occurs.

And additionally, once Buds "pluggable record markers" patch is
included, knowing the record size beforehand would allow an efficient
implementation of hp record markers.

Yet additionally, the IOLENGTH form of the INQUIRE statement could be
simplified quite a bit (perhaps it wouldn't even need to enter the
library at all if the record size computation would be done at the
compiler side).


-- 
Janne Blomqvist