[Patch, Fortran] Another floating point speedup
Daniel Kraft
d@domob.eu
Sat Jan 3 20:09:00 GMT 2009
Once again... This patch should finally be rid of the bugs (no
regressions) and handles exponents of size up to 4 digits (should be
enough).
In addition, I got rid of the memcpy in convert_real and use
pointer-casting instead, got another second of speed up.
Ok for 4.5? Or should I first look at the list_read.c floating parsing
routines (I guess those are for unformatted IO?)
Daniel
> 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.changelog
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20090103/8ed5c22b/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20090103/8ed5c22b/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.f90
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20090103/8ed5c22b/attachment.f90>
More information about the Fortran
mailing list