[email@example.com: cygwin-1.5.5 sscanf on floats: 20 times slower than 2 years ago]
Sat Nov 22 01:34:00 GMT 2003
Christopher Faylor wrote:
> On Fri, Nov 21, 2003 at 03:50:18PM -0500, J. Johnston wrote:
>>J. Johnston wrote:
>>>Wayne Hayes wrote:
>>>>>Since scanf and the floating point arithmetic is implemented in newlib,
>>>>>I've redirected this message there. Does anybody have an idea, what
>>>>>could slow down float scanning in sscanf by a factor of 20?
>>>>Thanks! Just to be pedentic, I realized that it's worse than a factor
>>>>My *entire simulation* slows down by a factor of 20; there's significant
>>>>other computation in it. So the scanf slowdown is probably closer to
>>>>hundreds of times. *Something* fishy must be going on. :-)
>>>The reason for the slow down is long double support. A new routine
>>>_strtold is used instead of _strtod_r. I am working on a patch to use
>>>the old routine for non-long-doubles to avoid the slow down.
>>Patch checked in.
> I'm generating a new snapshot now: http://cygwin.com/snapshots.html .
> It will be interesting to hear if this solves the problem.
> Btw, would using hardware floating point help here at all? I managed to
> get newlib to build with hardware floating point earlier but I wasn't
> sure what the consequences of doing that would be (other than the fact
> that cygwin wouldn't work on a x386).
The hardware float configuration option for newlib tells newlib to use
floating-point algorithms for various math routines. It won't fail on a machine
that does not have floating-point insns as the compiler will generate calls to
floating-point simulation but you will be better off just using the original
integral algorithms. The hardware float option would be useful on a machine
that had excellent floating-point insns that the compiler knows how to use.
In this particular case, sscanf is using stdlib conversion routines that can't
benefit from the hardware float option.
-- Jeff J.
More information about the Newlib