| Re: Why gfortran`s stream access is so slow? |
|
 |
|
 |
|
 |
|
 |
Group: comp.lang.fortran · Group Profile
Author: Gordon SandeGordon Sande Date: Nov 2, 2007 06:26
> On Nov 1, 11:03 pm, glen herrmannsfeldt ugcs.caltech.edu> wrote:>>> On Oct 30, 10:25 pm, "CPLUSPLU...@ gmail.com" gmail.com>>
>> I agree with this, but it seems even slower than that.
>> It is a factor of 40 in user time, which is probably the
>> overhead that you mention. A factor of 2800 in system time
>> which I believe is because it is doing unbuffered I/O.
>
> You have a point there. The Fortran run-time overhead would
> show up as extra user time, not system time.
>
> I doubt that gfortran is doing unbuffered I/O. I suspect it
> is doing excessive flushing instead. The effect would be the
> same in this case. A test that might show the difference is
> to read the file one byte at a time into a character array and
> then write the file one byte at a time from the character array.
> If the system time is still excessive, then it is likely that I/O
> is unbuffered. If the system time drops to something reasonable,
> it is likely too much flushing is being done in the original
> example.
>
> Bob Corbett
The "problem" of slow I/O in Fortran has been a long standing
"complaint" raised against Fortran. When I have tried to ask
serious questions in the past the problems quickly turned into
urban legends.
If one asks about using moderate sized arrays of floating point
values stored in native formats the results are that all the various
contenders can spin tape at about the same speed. I have understood
this to mean that the underlying use of the system is equally good
(or bad). Many did not expect Fortran to be competitive in this
situation given the "general understanding". Whole arrays instead
of equivalent implied DO lists do not seem to slow things down much
but that may be system dependent and reflect how much data copying
is done at lower levels.
If one asks about full records that require format conversion from
internal native to external text form the results are that all
contenders bog down. I have understood this to mean that correctly
done format conversion takes a while because of the difficult corner
(or extreme) case. This comes as a surprise on some systems as this
is not a common usage style. Systems that have sterling reputations
for fast I/O are acting like dogs and everyone is "amazed".
Where one finds more complaints is if Fortran is using text through
the FORMAT machinery. The conversions are not that complicated
but the overhead is substantial. The contenders are often able to
treat this as native I/O. The difference can be quite real and is
really an apples and oranges situation. But the differing I/O models
of records or byte streams do seem to make the mismatch a plausible
implementation choice.
I am always amazed that there is enough I/O in the mismatch situation
to be observable. The few times I have learned more turned out to
border on the bizarre. (But maybe my normal is their bizarre.) I have
been fortunate in never have run into the "backspace by rewinding and
rereading" level of implementations as the systems I have asked about
were mature vendors supplied and in active use.
The subject line complaint seems to be about an new I/O variant on
a system that is still described as an alpha development. Be glad it
works and report a performance anomaly.
| 
