Re: -frecord-marker

[Janne Blomqvist <Janne dot Blomqvist at tkk dot fi>]

On Fri, Jul 21, 2006 at 04:45:07AM -0700, Bud Davis wrote:
> on some file systems those seeks will be slow. very
> slow.  and of course they will be worse the bigger the
>  records :)

In an absolute sense you're correct since longer seeks take a longer
time, but in practice it's not a problem since the seeks will be
amortized over a lot of "real" IO.  With the Intel scheme we'd be
limiting ourselves to 2 GB subrecords, meaning that every 2 GB we
would need to seek back and fix the marker. That's not a problem,
unless we're talking about tape io.

The worst case scenario really is tiny random io. Read/write a single
scalar variable, seek, and repeat. Like, say, direct_io_5.f90 in the
testsuite.

In case the random io is somewhat localized more clever buffering
could help. Instead of a single dirty region in the buffer we could
have a rbtree (or some other appropriate data structure) with

struct dirty_extent {
  gfc_offset offset;
  uint len;
}

indexed by offset.  Then, when flushing the buffer we walk the rbtree
depth-first, and if two adjacent extents overlap, or the non-dirty
space between them is active, they can be coalesced. 

That being said, back on planet Earth I think the IO library is
convoluted enough as it is, and AFAIK most Fortran programs don't do
much random IO. ;-|

> but, everything is a tradeoff...the world would be
> grand if we knew how big the record was going to be on
> the first library call.

Yup.

-- 
Janne Blomqvist

Attachment: pgp00000.pgp
Description: PGP signature