Bug 139065 - g77 generates inefficient code for unformatted writes
Summary: g77 generates inefficient code for unformatted writes
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc   
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL: http://gcc.gnu.org/bugzilla/show_bug....
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-12 19:37 UTC by Bogdan Costescu
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-15 17:43:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bogdan Costescu 2004-11-12 19:37:23 UTC
Description of problem:
g77 generates inefficient code for writting into unformatted files. 
The code that results does calls like (obtained with strace):

_llseek(3, 100, [100], SEEK_SET)        = 0
write(3, ";p\23?\4\0\0\0", 8)           = 8
_llseek(3, 96, [96], SEEK_SET)          = 0
write(3, "\4\0\0\0", 4)                 = 4
_llseek(3, 108, [108], SEEK_SET)        = 0
_llseek(3, 112, [112], SEEK_SET)        = 0
write(3, "\360\10\6?\4\0\0\0", 8)       = 8
_llseek(3, 108, [108], SEEK_SET)        = 0
write(3, "\4\0\0\0", 4)                 = 4
_llseek(3, 120, [120], SEEK_SET)        = 0

which kills performance when the file is written to a NFS mounted 
directory. Other compilers (like the Intel compiler) would do only 2 
writes for the above sequence, like:

write(3, "\4\0\0\0;p\23?\4\0\0\0", 12)  = 12
write(3, "\4\0\0\0\360\10\6?\4\0\0\0", 12) = 12

without any seeking in the file.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See the referenced gcc bug report.

Additional info:

Comment 1 Jakub Jelinek 2004-11-15 17:43:39 UTC
RHEL4 will include libgfortran (as preview).
For the old libg2c library, speeding this up would require rewriting quite big part of the library and all that work would be for GCC 3.2..3.4 only, as
GCC 4 has a completely rewritten fortran library (but incompatible).

If you have a support contract, you can escalate this through your support contact, if you can't easily work around this (by using a local filesystem
and only copy generated data when it is done) and request it that way.

Note You need to log in before you can comment on or make changes to this bug.