Speeding up floating point number reading

[Daniel Kraft]

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