This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: PR20278 Performance regression in formatted output vs. g77
- From: Janne Blomqvist <jblomqvi at cc dot hut dot fi>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Fortran List <fortran at gcc dot gnu dot org>
- Date: Tue, 20 Sep 2005 10:04:09 +0300
- Subject: Re: PR20278 Performance regression in formatted output vs. g77
- References: <432FA127.80300@verizon.net>
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