This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] Rework of floating point number reading


On Tue, Dec 30, 2008 at 18:58, Daniel Kraft <d@domob.eu> 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:

http://repo.or.cz/w/glibc.git?a=blob;f=stdlib/strtod_l.c

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
day..


-- 
Janne Blomqvist


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]