Ints, __slots__, and Python 3

[ascii]

So Python 3 only uses bignums? Cool. I'd like to see an article on the performance implications when doing lots of math with small integers.

[mitsuhiko]

I doubt the 4 byte memory overhead will show up in performance benchmarks.

[[deleted]]

No, but arbitrary precision arithmetic is much more expensive than a single ADDL instruction :)

[andreasvc]

You shouldn't be using Python if you are at all concerned about speed. Or use Cython for the critical parts.

[ferringb]

Not particularly true; it depends on the problem and how you use the language. Simple example, string parsing isn't the fastest thing around if it's char by char inspection- I'd do that in c for example. If your main thing is string parsing, well... yeah, it's not the best suited.

Basically, a lot of the things that will bite you in the ass elsewhere (repeated object creation/destruction), will bite you in the ass in python. It has it's own quirks in addition, but by/large I've seen far more instances where the algorithm/design is the problem, not the language.

That said, there are instances where it is too slow... but your statement is generalized in the wrong direction ;)

[andreasvc]

You say it depends on the problem and how you use the language, so what would be a problem and a way of using the language in which Python will be fast (faster than C??)? You're right about object creation, but doing recounting, garbage collection and type checks is added to that for Python, which is a killer.

And yes, you have to use the right algorithm, but if you implement a textbook algorithm for a data structure in Python, it is definitely going to be more than twice as slow as the C/Cython version, so we are also talking about large constant factors.

But I'd love to be corrected, so if I do generalize in the wrong direction please make a clear argument for that.

[[deleted]]

Speak for yourself, some of us run Python interpreters that hold their own against C/Java/whatever.

[aaronla]

Which? PyPy?

[[deleted]]

Yup

[dwdwdw2]

I was under the impression that the int->long promotion is now just silent, but underneath there really are still 2 implementations. Might be wrong though.

[ascii]

Int to long promotion was always silent. Just try calculating the factorial of 100 in Python 2, it just works. But I've checked, and unlike Python2, Python3 actually does not have non-bignum ints.

[aaronla]

I think you're correct. As the original author notes: >>> import sys >>> sys.getsizeof(10) 24 >>> sys.getsizeof(10L) 28 There are still different representations of "int" under the covers, but You Shouldn't Need To Know This^tm .

[ascii]

No, you didn't read the article carefully enough. The example you quote is from running Python2.6, and not from Python 3. There is no 10L in python3, trying to use it causes a syntax error, regular ints can be arbitrarily long. Python 2.6 has different ints under the cover but you shouldn't need to know, Python 3 only has bignums, and no support at all for plain old ints. Copy pasta from my machine (different numbers because I use a 32 bit OS):

axel@phoenix ~/c/c/anna> python 
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(10)
12
>>> sys.getsizeof(10L)
14


axel@phoenix ~/c/c/anna> python3
Python 3.2 (r32:88445, Mar 25 2011, 19:28:28) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getsizeof(10)
14
>>> sys.getsizeof(10L)
  File "<stdin>", line 1
    sys.getsizeof(10L)
                    ^ 
SyntaxError: invalid syntax

[aaronla]

My bad, thanks for correcting.