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
--
https://mail.python.org/mailman/listinfo/python-list
