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] |
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] |