* Hrvoje Niksic:
"Alf P. Steinbach" <al...@start.no> writes:
* Hrvoje Niksic:
"Alf P. Steinbach" <al...@start.no> writes:
Speedup would likely be more realistic with normal implementation (not
fiddling with bit-fields and stuff)
I'm not sure I understand this. How would you implement tagged integers
without encoding type information in bits of the pointer value?
A normal tag field, as illustrated in code earlier in the thread.
Ah, I see it now. That proposal effectively doubles the size of what is
now a PyObject *, meaning that lists, dicts, etc., would also double
their memory requirements, so it doesn't come without downsides.
Whether it increases memory usage depends on the data mix in the program's
execution.
For a program primarily handling objects of atomic types (like int) it saves
memory, since each value (generally) avoids a dynamically allocated object.
Bit-field fiddling may save a little more memory, and is nearly guaranteed to
save memory.
But memory usage isn't an issue except to the degree it affects the OS's virtual
memory manager.
Slowness is an issue -- except that keeping compatibility is IMO a more
important issue (don't fix, at cost, what works).
On the
other hand, tagged pointers have been used in various Lisp
implementations for decades, nothing really "baroque" (or inherently
slow) about them.
Unpacking of bit fields generally adds overhead. The bit fields need to be
unpacked for (e.g.) integer operations.
Lisp once ran on severely memory constrained machines.
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
