Home Original page

Challenge: optimizing isqrt

Dave Angel davea at davea.name
Tue Nov 25 19:46:21 EST 2014 
On 11/25/2014 02:31 PM, Serhiy Storchaka wrote:
> п'ятниця, 21-лис-2014 08:15:57 ви написали:
>> This looks very good indeed. As a matter of interest, is there any
>> particular reason you have used 2*b instead of b+b? Might b+b be faster
>> than b*2?
>
> Yes, it is slightly faster, but the effect is indiscernible in total
> time. But
> there is not harm to use b+b.
>
>> Also, in various lines, you use //2. Would >>1 be quicker? On reflection,
>> perhaps you have had to use //2 because >>1 cannot be used in those
>> situations.
>
> I thought this effect would be insignificant too. But actually it is
> measurable
> (about 10% for some input). Thanks, this optimization is worth to be
> applied.
>

Unfortunately, for many values, the version of the function with >>1 is 
slower.  It's only when the argument is bigger than 10**40 that it's as 
much as 1% faster.  But it's true that for really large values, it's 
quicker.

A quick test shows that 3.3 is about 20% faster for both these functions 
than 2.7.

My oversight earlier was assuming a native type.  Once you get into 
"longs" which aren't supported by the processor, the shift will likely 
become much faster than divide.

-- 
DaveA
More information about the Python-list mailing list