Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
Weird Python Integers
11–20 of 150 posts
Re: Weird Python Integers
#12Lisp systems also have fixnums and bignums. For example a 64bit Common Lisp: MOST-NEGATIVE-FIXNUM, value: -1152921504606846976 MOST-POSITIVE-FIXNUM, value: 1152921504606846975 Fixnums are typically stored inline in data structures (like lists, arrays and CLOS objects). Bignums will be stored as a pointer to an heap-allocated large number. Data has tags and thus in a 64bit Lisp the fixnums will be slightly smaller tha…
The range varies across implementations: the above values correspond to 60 bits; most-positive-fixnum evaluates to 4611686018427387903 in the version of SBCL I am currently running, which corresponds to 62 bits of data.
Re: Weird Python Integers
#13Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
I don't know the internals of Python, but maybe checking if you need to refcount something is basically takes as long as actually just going ahead and doing it all the time anyway.
Re: Weird Python Integers
#14Nice article. I wrote a similar piece some time ago related to booleans, in case anybody is interested: https://blog.rmotr.com/those-tricky-python-booleans-2100d5df...
And to avoid issues with is/==, we recommend our students to always use == (except for `is None`). Also related piece:https://blog.rmotr.com/avoiding-being-bitten-by-python-161b0...
Re: Weird Python Integers
#15Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
Sure: CPython doesn't know statically that anything is "not an object", so your proposal adds an extra test to every incref and every decref. This is perceived as probably worse for performance. In 2002, a hacked CPython interpreter (source code long since lost, sorry!) saw a 5% performance decrease on pystone but a 14% performance increase on an integer-heavy workload. https://mail.python.org/pipermail/python-dev/2002-August/027...
Re: Weird Python Integers
#16Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
I'll probably eat my own words, but generally I believe CPython is meant to be easy to reason about, easy to read the code for and understand the implementation, and not to try to be meaningfully performant. I would bet the decision to refcount everything is to keep it simple.
Re: Weird Python Integers
#17Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
Sure: CPython doesn't know statically that anything is "not an object", so your proposal adds an extra test to every incref and every decref. This is perceived as probably worse for performance. In 2002, a hacked CPython interpreter (source code long since lost, sorry!) saw a 5% performance decrease on pystone but a 14% performance increase on an integer-heavy workload. https://mail.python.org/pipermail/python-dev/20…
Interesting, thanks for the link! Generally I've viewed writing as more expensive than reading, so I'd be curious if that behavior is still true on modern hardware.
Re: Weird Python Integers
#18Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
I don't know the internals of Python, but maybe checking if you need to refcount something is basically takes as long as actually just going ahead and doing it all the time anyway.
Yeah you might be right, it's hard to say. Generally I view writing as more expensive than reading so I don't know.
Re: Weird Python Integers
#19Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?
I'll probably eat my own words, but generally I believe CPython is meant to be easy to reason about, easy to read the code for and understand the implementation, and not to try to be meaningfully performant. I would bet the decision to refcount everything is to keep it simple.
Possibly, though it seems they do try to optimize things (they have an entire peephole optimizer).
Re: Weird Python Integers
#20You can also do a similar thing in Java, as illustrated in this answer on CodeGolf stackexchange: https://codegolf.stackexchange.com/a/28818
Indeed - the integer boxing cache is even required by the language spec!
http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#...
(here == means reference not value equality)
"If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b."