Re: [Patch, Fortran] Another floating point speedup

[Daniel Kraft <d at domob dot eu>]

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