Pyhon 2.x or 3.x, which is faster?

BartC bc at freeuk.com
Tue Mar 8 07:09:45 EST 2016


On 08/03/2016 11:45, Jussi Piitulainen wrote:
> BartC writes:
>
>> On 08/03/2016 02:47, MRAB wrote:
>>> On 2016-03-08 01:33, BartC wrote:
>>
>>>> Compared with 2.7, 3.4 above is spending nearly an extra ten seconds
>>>> doing .... what? I can't understand why someone just wouldn't care.
>>>>
>>> Part of it will be that Python 2 has 2 integer types: 'int' (fixed
>>> length) and 'long' (variable length).
>>>
>>> Originally, 'int' addition could overflow, but it was more friendly to
>>> promote the result to 'long' instead.
>>
>> That was my first thought on reading the thread and was going to post
>> that as the reason for 3 being a little more sluggish.
>>
>> But then I tested Python 2 (2.7.11), and I couldn't get integer
>> arithmetic to overflow at all!
>
> It overflows to the long type.

So the difference is that Py2 has int and long types, and overflows 
silently from int to long?

(That seems sensible enough; I wonder why they changed it? When int is 
64 bits, then probably 99.9% of code will not need anything more.)

> Replace 0, 100000000 and 1 with 0L, 100000000L and 1L in Python2 version
> of your while loop test to see the effect. When I tried it this morning,
> it almost closed the gap between 2.7 and 3.4 on my laptop. (I don't
> remember the minor versions.) The latter was still slower but not by
> much.

I tried that and it was 1 second slower than 3.4! (19 seconds compared 
with 18 seconds.)

That would at first sight offer a plausible explanation for the 
discrepancy (which IMO would be too big a cost for the minor benefit of 
a single integer type).

And maybe this particular combination of byte-codes just happened to 
show up the difference more dramatically.

But then, 3.1 took only 12.5 seconds; same byte-codes, same unified 
'long' type for integers...

-- 
Bartc





More information about the Python-list mailing list