[Patch, Fortran] Another floating point speedup

Daniel Kraft d@domob.eu
Sat Jan 3 20:05: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/gcc-patches/attachments/20090103/8ed5c22b/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/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/gcc-patches/attachments/20090103/8ed5c22b/attachment.f90>


More information about the Gcc-patches mailing list