This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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]

[patch, fortran] Large transfer support for IO library


Hello,

the recently committed patch that introduced array transfers to the IO
library (see thread starting at
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01519.html ) has brought
forward a few shortcomings in the IO library wrt large transfers:

1) The IO library interface with the salloc_r_at and salloc_w_at
functions require a buffer where the higher level library reads or
writes the data. For small transfers this doesn't matter since we use
the same buffer that we use for IO buffering (to avoid frequent
syscalls, similar to stdio). However, for large transfers this can in
the worst case (rank 1 array with stride 1) double the memory
requirements of the application.

2) Sloppines wrt types; A lot of the IO functions use int instead of
(s)size_t, essentially limiting the library to < 2 GB transfers even
on LP64.

The attached patch fixes the above two problems (or at least, tries
to). This is done by adding read and write function pointers to the
stream struct, and of course corresponding implementations in the
library (unix.c). These functions use (s)size_t etc., and should be
able to cope with up to SIZE_MAX transfers. In the mid-layer the
unformatted read and write functions are changed to use this new
interface. The formatted functions are left as is, since for large
transfers they are implemented as loops over scalar transfer functions
and thus points #1 and #2 above don't apply (well, > 2 GB characters
might be a problem but then we have lots of other problems too).

I would appreciate if someone with a LP64 system could test the
attached program which should write a 2.2 GB array in a single
transfer.

Due to avoiding the extra layer of buffering, this patch also improves
performance. PR 16339 (40 MB file in a single array transfer) time
drops from 0.20 s (current mainline) to 0.14 s, making it equivalent
with a C program with a single fwrite(). PR 23363 (rdiska) drops from
0.040 s to 0.027 s, making gfortran about as fast as g77, and 500
times faster than 4.0. ;-)

Regtested on i686-Linux. 

Patch, changelog and test program for big writes attached.


-- 
Janne Blomqvist

Attachment: ChangeLog
Description: Text document

Attachment: large_trans.diff
Description: Text document

Attachment: write-record.f
Description: Text document


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