[Python-Dev] Re: opcode performance measurements

[Samuele Pedroni]

From: Neal Norwitz <neal@metaslash.com>
> Why not assume the general case is the most common, ie, that the
> object is an instance of this class or one of its subclasses?
> That way you could do the specialization at compile time.  And
> for the (presumably) few times that this isn't true fallback to another
> technique, perhaps like HotSpot.
>
> Also, doesn't calling a base class method as:
> Base.method(self) # in particular __init__()
> vs.
> self.method()
>
> create problems if you specialize for a specific class?  Or does
> specialization necessarily mean for a subclass and all its base clases?

Puzzled. In Python you could specialization at MAKE_CLASS time,
which means rewriting all the direct and indirect superclasses methods
and the class method under the assumption that self is of the built class.
Doing so is probably too expensive. Typically specializing only
when a given method is actually called makes more sense.
Btw typical systems specialize and native-compile at the same time,
if you substract the native-compile part your cost equation change
a lot. Given that people can change self (although nobody does)
that you need data/control flow analysis, that's too bad:

def a(self):
   self = 3
   return self+1

Also:

  def __add__(self,o):
    ...

You cannot do anything special for o :(.


> [Jeremy] > Right, because with multiple inheritance you cannot make the
layout
> > of a subclass compatible with that of *all* superclasses, so simple
> > monomorphic inline caches will not work :(.
>
> ISTM that it would be best to handle single inheritance first.
> Multiple inheritance could perhaps be handled for the class with
> the most commonly referenced attribute (assuming 2+ classes don't
> define the same attr.  And use a fallback technique for all other cases.
>

How do you decide which are the most commonly referenced attributes?
<wink>

> > > We probably have to worry about a class or instance being modified in
> > > a way that invalidates the dlict offsets computed.  (Not sure here,
> > > but I think that's the case.)  If so, we probably need a different
>
> Right, if an attr is deleted, methods added/removed dynamically, etc.

It really depends on implementation details.

> > > object -- call it a template -- that represents the concrete layout
> > > and is tied to unmodified concrete class.  When objects or classes are
> > > modified in dangerous ways, we'd need to invalidate the template
> > > pointer for the affected instances.
>
> By using a template, doesn't that become a dict lookup again?

Tthe good thing about templates as idea is that they
could solve the zoo isssue.
You're right about lookup but to see the utility you should
bring per bytecode instr caches in the picture:

if obj.template == cache_line.template:
  use cache_line.cached_lookup_result
else:
   lookup and update cache_line

[The Self VM used maps (read templates) in such a way]

There is really a huge hack/implentation space to play with.

These comments are mainly informal,  if the interest
remain after the conference I will be pleased to partecipate
to more focused and into-the-details discussions.

regards, Samuele.