This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Speeding up floating point number reading
- From: Mikael Morin <mikael dot morin at tele2 dot fr>
- To: Daniel Kraft <d at domob dot eu>
- Cc: Fortran List <fortran at gcc dot gnu dot org>
- Date: Mon, 29 Dec 2008 19:27:17 +0100
- Subject: Re: Speeding up floating point number reading
- References: <4958F028.4030304@domob.eu>
Daniel Kraft wrote:
> Hi all,
>
> as promised on PR 38654, I gave floating point reading a look. I used
> the attached program for testing with -O3 -static. It takes around 31s
> on my system with an unpatched gfortran 4.4.
>
> First, I tried to replace the strtod call in
> libgfortran/io/read.c:convert_real with a custom made parser according
> to the one I implemented for FreeWRL, and even got execution time to
> around 29s (a bit surprising, I though strtod must be well optimized).
>
> 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!
>
> 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'm going to work out a real patch, that handles all kinds, not just
> double, and in addition cleans up all now-useless stuff. Comments welcome!
>
> Yours,
> Daniel
>
Thanks
Mikael