[wayne@cs.toronto.edu: cygwin-1.5.5 sscanf on floats: 20 times slower than 2 years ago]

[J. Johnston]

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 
>>>>of 20.
>>>>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).
> 
> cgf

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.