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

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

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.


-- 
Janne Blomqvist