This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fortran/PR19303 PATCH: Runtime selection of record markers for unformatted sequential io


On Sat, Mar 05, 2005 at 07:36:25PM -0600, Bud Davis wrote:
> On Wed, 2005-03-02 at 14:19, Janne Blomqvist wrote:
>  
> > 
> > Yes, it sounds like a pretty weird design decision.  But anyway,
> > wouldn't it in principle be possible to to implement without
> > buffering?  E.g. have the compiler generate code to examine the
> > io-list and send the size to the library before any actual data
> > transfer happens? Although functions returning variable size arrays
> > (aren't these allowed?) would require a temporary under this scheme.
> 
> 
> this is the solution we need.  fortran records can be huge, they need to
> be transferred directly from the user program to the 'C' library with no
> intermediate buffering.  every system that i am aware of takes a
> significant amount of time to copy 2GB of memory between memory buffers.
> 
> this requires knowing how many bytes will be sent before the header is
> written.

Not necessarily. I don't think the current implementation is that bad,
i.e. first write a bogus record marker, and after the record is
finished we backspace and update the record marker to the correct
value. Depending on how buffering on the OS level works, I suspect
that for reasonably small records the bogus value will never make it
to disk and thus there is no noticeable performance penalty either. Of
course, the problem is that it is near impossible to implement
variable sized record markers (such as the HP record markers under
discussion) efficiently.

But anyway, I personally regard HP record markers more as a
icing-on-the-cake feature and thus I'm not very comfortable with the
idea of making a grand redesign of the io library just so we can
implement them more efficiently. Also, even if such a decision would
be made, I think it would be a big mistake to start implementing it
before GCC 4.0.

-- 
Janne Blomqvist


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]