Ints and performance (was Re: PEP0238 lament)

[Peter Hansen]

Tim Peters wrote:
> 
> [Peter Hansen]
> > The interpreter currently has direct support for the most-used
> > integer operations, thus ensuring that this type has performance
> > reasonably close to the maximum feasible given the nature of
> > virtual machines.
> 
> Actually not close at all.  In, e.g.,
> 
>     k = i + j
> 
> we spend a lot more time fiddling with reference counts and memory
> management than doing the arithmetic!  But we'll ignore that since you're
> already happy <wink>.

Well, I knew all that of course, which is what I meant with "given 
the nature of virtual machines" (which have to do all those extra
goodies which make them so worthwhile).  I meant there is 
a spot reasonably close to the identification of the bytecode
operation where the integer operation is actually performed.
So close, in fact, that it is right in the interpreter core itself
very much like you might inline critical code with C macros.

This is in contrast to all other types (actually, I don't have 
the source in front of me, but do I recall floats being
optimized in the same way?) which end up executing the actual
operation (in C for builtins) way, way down the chain after a
horrendous series of indirections, virtual methods, dictionary
lookups, and so on (implemented in wonderfully elegant and 
rather efficient-looking code I readily agree).

> > Would the number system unification imply that this integer
> > optimization would be eliminated?
> 
> BTW, Python got along fine for years without any integer optimizations at
> all, but I agree that specialing-casing int + - and compares in the eval
> loop was a clear net win (for which you can, IIRC, thank Fredrik Lundh).

Thank you, Fredrik! :-)

That is my point, though.  These integer optimizations are, as we 
agree, a clear win.  Are these optimizations in danger of being impacted
as a result of this unification, or will we still be able to count 
on integer performance being significantly better than that of
less frequently used types.

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com