Re: [patch, fortran, RFC] Separate READ from WRITE

[Jerry DeLisle <jvdelisle at frontier dot com>]

On 10/12/2010 03:18 PM, Janne Blomqvist wrote:
> On Mon, Oct 11, 2010 at 01:07, Jerry DeLisle<jvdelisle@frontier.com>  wrote:
> > On 10/10/2010 01:44 PM, Tobias Burnus wrote:
> > > Thomas Koenig wrote:
> > > > this RFC patch separates reads from writes in Fortran, by establishing
> > > > separate transfer functions for writing, with a different spec. For
> > > > now, the write functions just call the original transfer functions, with
> > > > the spec making all the difference.
> > >
> > > I think you are currently trading non-clobber for having a function call
> > > overhead: The newly generated functions in libgfortran will probably not
> > > be
> > > inlined as the called procedure is also publicly visible. Though, they
> > > might be
> > > cloned and inlined - as least in the cases when the transfer function is
> > > small.
> > >
> > > The question is whether one can do without duplication of code, e.g., by
> > > having
> > > two different decls but with the same assembler name - though, I am not
> > > sure
> > > whether this will work - including with LTO.
> > >
> > > What do our middle end experts think?
> > > a) Status quo: Read and write I/O call the same libgfortran function, i.e.
> > > the
> > > non-clobbering is not taken into account.
> > > b) Thomas' patch: Adding a wrapper function for write, i.e. a function
> > > call
> > > overhead but allows to use fn-spec to mark the arguments as noclobber.
> >
> > I don't think this function call overhead is that significant, however it
> > would be nice to run some tests and measure it.  Also, It would make sense
> > to me to separate the READ and WRITE in the library.  I will be looking into
> > doing this soon.  This would clear the over head issue, if any, and we woud
> > also be able to get rid of runtime tests for whether we are doing READ or
> > WRITE which is additional overhead we have now. So over all, it looks like a
> > step in the right direction.
>
> I agree with Jerry here; one function call more or less is
> insignificant compared to all the other work the IO library does.
> Indeed, all this work is AFAICS the reason why gfortran IO performance
> suffers for simple IO statements. Thanks to transfer_array() we do
> quite well when reading/writing large array (sections), but something
> very simple like
>
> WRITE (10) i
>
> end up doing quite a lot of work. To some extent this is inevitable
> due to the "impedance mismatch" between Fortran and POSIX IO models,
> but still. Say, take a look at the horror that is
> data_transfer_init(), finalize_transfer(), next_record_*() and so
> forth that is executed for every single READ/WRITE statement.
>
> Not that I have any good idea on how to tackle this.
I have thought for a long time to refactor all of this.  Perhaps now is the time 
to start witth an eye toward 4.7.  I will open a PR and assign to myself.  One 
obvious benefit will be getting rid of a lot of conditionals at run-time that 
are known at compile time and don't change.  I will plan on doing this as soon 
as I finish with the format checking revamp I am doing.

Regards,

Jerry