[patch, fortran, RFC] Separate READ from WRITE

[Jerry DeLisle]

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