Re: Speeding up floating point number reading

[Daniel Kraft <d at domob dot eu>]

Mikael,

thanks for looking at this one!

Mikael Morin wrote:
> Daniel Kraft wrote:
> > However, I then looked further, and discovered that read_f, the caller
> > of convert_real, is already doing most of the work!  And then, it prints
> > the number back to a string just to parse it again using convert_real...
> > With the simple (experimental and rough) patch attached, the final
> > floating point value can be calculated with little additional effort in
> > read_f, without ever calling convert_real.  This cuts the execution time
> > in half to 15.5s!
> Wow, that's impressive!

Unfortunatelly, at the moment with some fixes, I'm at 18.8s (don't 
really know why, maybe this is something stupid), but still worth it ;)

> > The only weak point is that I'm not sure if we may experience rounding
> > errors in parsing the float due to all the *10 and + operations, and
> > that could be something strtod takes care of.  On the other hand, I
> > think this is rather unlikely.  What do you think about this one?
> integers can be represented exactly, so there won't be any problem.
> But you could overflow, or at least have problem with very long
> numbers/digit-strings.
> Problems could raise with non-format-matching numbers too.
> The evil is in the details as usual.
> Note that I know nothing about libgfortran, io.c, and had a very
> superficial look at read_f, so that I'm not the one to give you tips
> there.

I thought about this, too.  But that would be a lot of complication, and 
so far I don't see any not-enough-precision errors.

We'll see, but so far I've got a patch, but it still has some 
regressions and I want to clean it up again, with all those funny things 
like BLANK_NULL/BLANK_ZERO I just learned about :D

If it works finally, I'll post a formal patch.

Cheers,
Daniel

--
Done:  Arc-Bar-Cav-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran