[Patch, Fortran] Rework of floating point number reading
Tue Dec 30 17:59:00 GMT 2008
On Tue, Dec 30, 2008 at 18:58, Daniel Kraft <firstname.lastname@example.org> wrote:
> Mikael Morin wrote:
>> Daniel Kraft wrote:
>>> Thomas Koenig wrote:
>>>> On Tue, 2008-12-30 at 09:37 +0100, Daniel Kraft wrote:
>>>>> 3.) Keep using strtod; I'm quite sure we can speed up the existing
>>>>> code still significantly by optimizing how the string passed to
>>>>> strtod is constructed.
>>>> What about using the glibc strtod as a base, and adjust it to Fortran?
>>>> The glibc copyright is already with the FSF, so I wouldn't expect legal
>>>> problems, but, of course, IANAL.
>>> Actually, I don't think this is a good idea, as (at least if strtod does
>>> really do some "magic" to get around the rounding problem as much as
>>> possible) this sounds like including possibly a lot of system-dependent,
>>> complicated code into libgfortran that does not really belong there.
>>> Just my opinion, though.
>> I think it is a good idea. If we keep the code as is, with a call to
>> strtod, we parse the string twice, the first time in libgfortran, and
>> the second time in strtod. Adding 'e' for example (for exponent) to a
>> strtod base won't add any complexity to the strtod code, so the speed
>> will be the same. However, supporting it without touching strtod adds a
>> lot of unnecessary code.
>> Just my opinion too ;-)
> That's true, but without having looked at glibc's strtod code, I fear it
> won't really be something clear and easy-to-read. If we want a simple,
> clean and fast parsing routine, we could take my patch, including the
> possible rounding errors. If we don't want to have them, I guess the way
> strtod does it must be something ugly and system-dependent (at least if
> strtod really does a lot better than my naive implementation).
> So I would not want to do our own parser (or copy the one from glibc for the
> matter) if we still wanted to care about precision more than my patch does.
> But of course it may be worth a look at the actual glibc code; I'll try to
> do this now.
The actual implementation is here:
Looks quite scary! Based on nothing but the amount of code, I imagine
walking over the string once to convert the Fortran-specific stuff to
a format acceptable by strtod() won't have a huge performance impact,
especially considering the string is so short that there are no cache
effects to worry about. But, measurement beats idle speculation any
More information about the Gcc-patches