Front page | perl.perl5.porters |
Postings from December 2000
On Sun, Dec 17, 2000 at 10:25:50PM +0000, Nick Ing-Simmons wrote:
> >pp_divide seems to slow down a lot if given the integer first else FP
> >treatment, so I've not done that yet (will need to be FP if first operand
> >is integer and greater than the size NV preserves to make
> >0xFFFFFFFFFFFFFFFF / 3 work, but needing to even have that code can be
> >conditionally compiled in)
>
> Many machines are very slow doing integer divide. With a harware
> (floating point) multiplier it is quite easy to do
>
> N/M = N * (1/M) in floating point but you have to do tedious
>
> for 0..wordwidth
> subtract
> conditional fossicking
> shift
>
> for integer.
oh cool. So when I find
cutoff = STRTOL_ULONG_MAX / (unsigned LONG int) base;
cutlim = STRTOL_ULONG_MAX % (unsigned LONG int) base;
in glibc's strol.c (used by all the signed and unsigned as well as atol.c:
/* Convert a string to a long int. */
long int
atol (const char *nptr)
{
return strtol (nptr, (char **) NULL, 10);
}
[yes, sorry, as a result of that this whole message is now GPL version 2 or
later]
I should be really happy.
OK, it's not quite as bad as it may seem, as I know that / and % will be
calculated together, but when perl is always using base == 10 it would be
nice to get that calculation done by the compiler.
(in fact, I'm surprised that glibc doesn't special case base 10, branching
into it for base == 0 if needed)
[I'm looking at glibc 2.1.3, so I don't know what 2.2 does]
So it looks like we might get a speed kick from doing strtoul ourselves in
sv.c (as part of looks_like_number) hardwired for base 10.
As long as we don't mind losing locale based number grouping (whatever
that is, but it's compiled in in my copy of strtol - I disassembled it
and can see the pattern of code that's doing it)
We only need 1 function. strtol is strtoul with the - sign taken care of
separately, and atol was only really used on the assumption (hope) that it
might be faster than strtol for cases where we know it cannot overflow.
Nicholas Clark
Thread Previous
|
Thread Next