[Python-Dev] RE: [Python-Dev] stackable ints [stupid idea (ignore) :v]

[Tim Peters]

[Guido]
>>> - On the other hand, a list of ints takes half the memory (given that
>>> most of those ints are not shared).

[Tim]
>> Isn't this 2/3 rather than 1/2?  [yadda yadda]

[Guido]
> An int is currently 3 units: type, refcnt, value.  (The sepcial int
> allocator means that there's no malloc overhead.)  A list item is one
> unit.  So a list of N ints is 4N units (+ overhead).  In the proposed
> scheme, there would be 2 units.  That makes a factor of 1/2 for me...

Well, if you count the refcount, sure <wink>.

Moving on, implies you're not contemplating making the descriptor big enough
to hold a float (else it would still be 4 units assuming natural alignment),
in turn implying that *only* ints would get the space advantage in
lists/tuples?  Plus maybe special-casing the snot out of short strings?

>> Well, Python already has homogeneous int lists (array.array),
>> and while they save space they suffer in speed ...

> Which would become faster with the proposed scheme since it would not
> require any heap allocation (presuming 2-unit structs can be passed
> around as function results).

They can be in any std (even reasonable) C (or C++).  If this gets serious,
though, strongly suggest timing it on important compiler + platform combos,
especially RISC. You can probably *count* on a PyObject* result getting
returned in a register, but depressed C++ compiler jockeys have been known
to treat struct/class returns via an unoptimized chain of copy constructors.
Probably better to allocate "result space" in the caller and pass that via
reference to the callee.  With care, you can get the result written into its
final resting place efficiently then, more efficiently than even a gonzo
globally optimizing compiler could figure out (A calls B call C calls D, and
A can tell D exactly where to store the result if it's explicit).

>> [other ramifications for
>>     "i = j + k"
>> ]

> I though this was assumed all the time?

Apparently it was!  At least by you <wink>.  Now by me too; no problem.

>> [refcount-on-int drivel]

> Don't get this -- there's no object on the heap to hold the refcnt.

I don't get it either.  Desperation?  The idea that incref/decref may need
to be treated as virtual methods (in order to  exempt ints or other possible
direct values) really disturbs me -- incref/decref happen *all* the time,
explicit integer ops only some of the time.  Turning incref/decref into
indirected function calls doesn't sound promising at all.  Injecting a
test-branch guard via macro sounds faster but still icky, and especially if
the set of exempt types isn't a singleton.

no-positive-suggestions-just-grousing-ly y'rs  - tim