[Patch, Fortran] Another floating point speedup
Daniel Kraft
d@domob.eu
Sat Jan 3 16:27:00 GMT 2009
Ok, seems I've not yet fully arrived in 2009... Of course the
exponent-writing code screws it all up, but as it is of limited range
(say, 3 digits should be enough, shouldn't it?) there's of course an
easy replacement. So just look at the rest of it :)
BTW, is there an assertion-function to use in libgfortran? Or shouldn't
we use those there?
Daniel
Daniel Kraft wrote:
> Hi all,
>
> again a patch to rework libgfortran's read_f for formatted reading of
> floating point numbers. This one should be equivalent to the old code
> with respect to precision, as we're still using convert_real and
> utimatly strtod for the actual conversion.
>
> This just reworks the way that read_f reformats the string to handle the
> Fortran/format specific issues. It is not as "good" as the other patch
> posted here, but it still brings down execution times from 33.4s to 25s
> for the test attached on my system. Profiling shows that most of the
> time (5s) is spent in strtod, about 3s in read_f for the reformatting
> and some 1s and below in other helper routines; so I'd guess that
> there's not much further speed-up possible (at least no dramatic one,
> except we could somehow get rid of this preprocessing completely) with
> still using strtod; but that's just a wild guess.
>
> io/list_read.c contains two other similar routines (parse_float and
> read_float) that sound as if we could do some cleaning up and maybe
> speed-up for those three (like combining common code or at least
> parse_float and read_float for unformatted IO, as I see it), I can work
> on this as a new patch or extension to this one. What do you think?
>
> Regression-testing at the moment on GNU/Linux-x86-32. Maybe I've got
> introduced some bugs with BLANK_ZERO/BLANK_NULL again, but those should
> not interfer much with the timing figure. Ok for 4.5 (at least from the
> main implementation and rather than my other patch)? I can then work on
> the others, if it is (or we take this one on hold and I work for a
> seperate patch on the rest).
>
> Daniel
>
--
Done: Arc-Bar-Cav-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran
More information about the Gcc-patches
mailing list