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

Re: PR20278 Performance regression in formatted output vs. g77


On Mon, Sep 19, 2005 at 10:41:59PM -0700, Jerry DeLisle wrote:
> Is anyone already working on this?

Not exactly, but I've been looking at coarsening the io library
interface. The current plan is to replace the loop over the scalar
transfer_* functions with passing an array descriptor to the
library. This could allow improving performance for unformatted io,
but I don't think it matters for formatted io as such.

I only ask that you don't make formatted io dependent on scalar
transfers to the library. I haven't really looked at formatted
transfers myself, so I don't know how it's done at the moment. Mainly
I wonder how reading the format string is done? Is that compatible
with array transfers?.

> The 'gcc timing' is for an equivalent c program using printf on a double 
> float. This gives some perspective on what we may be able to achieve.  
>  Gfortran is tied with ifort, more or less.

IMHO it doesn't look too bad. At least compared to unformatted, where
in some cases we lose to ifort or g77 by a factor of 30. :(

> One idea would be to get the code for sprintf, and modify it to do what we 
> want in fortran.

As I said, I haven't looked at formatted transfer, but off the top of
my head I'm not sure this is a good idea. (v)s(n)printf is well
implemented and documented (not only man pages but every C programming
book etc.), and every C programmer is familiar with it. Having a
slightly different sprintf version in libgfortran sounds like a
maintenance headache to me.


-- 
Janne Blomqvist


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