[Python-Dev] Parrot -- should life imitate satire?

[Samuele Pedroni]

Hi.

> > >
> > > The point is to put the commonly called things in the vtable in a way that
> > > you can avoid as much conditional code as possible, while less common
> > > things get dealt with in ways you'd generally expect. (Dynamic lookups 
> > with
> > > caching and suchlike things)
> >
> >If I'm right, you're designing a object-based VM.
> 
> More or less, yep, with a semi-generic two-arg dispatch for the binary 
> methods. The vtable associated with each variable has a fixed set of 
> required functions--add with 2nd arg an int, add with second arg a bigint, 
> add with second arg a generic variable, for example. Basically all the 
> things one would commonly do on data (add, subtract, multiply, divide, 
> modulus, some string ops, get integer/real/string representation, copy, 
> destroy, etc) have entries, with a catchall "generic method call" to 
> handle, well, generic method calls.
A question: when you say variable you mean variable (perl sense of that)
or object. It has already been pointed out but it's really confusing
from the point of view of python terminology. Will perl6 have only
variables which contain objects, truly references to objects like Python
or ...?
I should repeat that your explanation that assigment is somehow performed
calling a method on the "variable" is quiet a strange notion in general,
I can imagine having a slot called on assigment that eventually does a copy
or return just the object but assigment as an operation on the lvalue
is something very peculiar. I know that perl5 assignment is an operator
returning an lvalue, is this related?


> It's all designed with high-speed dispatch and minimal conditional branch 
> requirements in mind, as well as encapsulating all the "what do I do on 
> data" functions. Basically the opcodes generally handle control flow, 
> register/stack ops, and VM management, while actual operations on variables 
> is left to the vtable methods attached to the variables.
> 
> I expect things to get mildly incestuous for speed reasons, but I'm OK with 
> that. :)
> 
> >I don't how
> >typical is OO programming in Perl, but in Python that plays a central role,
> >if your long run goal is to compile to native code you should have
> >a "hard-wired" concept of classes and them like,
> 
> Yep. There's a fast "get name of object's class" and "get pointer to 
> object's class stash/variable table/methods/subs/<insert generic class 
> terminology here>".
> 
> >  because an operation
> >like getting the class of an instance should be as direct and fast as 
possible
> >if you want to use any of the "nice" optimization for a VM for a OO dynamic
> >language:
> >   inline polymorphic caches
> 
> Yup. I'm leaning towards a class based cache for inherited methods and 
> suchlike things, but I'm not sure that's sufficient if we're going to have 
> objects whose inheritance tree is handled on a per-object basis.
Make sense for the interpreted version, but for speed call-site
caches is far more promising when native compiling, but also more complicated. I 
imagine you already know e.g. the Self project literature.

> >   customization
> 
> Details? I'm not sure what you're talking about here.
Compiling different versions of the same method for example wrt to 
the receiver type in single dispatch case. See below

> >   or if/when possible: direct inlining.
> 
> Yep, though the potential to mess with a class' methods at runtime tends to 
> shoot this one down. (Perl's got similar issues with this, plus a few extra 
> real nasty optimizer killers) I'm pondering a "check_if_changed" branch 
> opcode that'll check a method/function/sub's definition to see if it's 
> changed since the code was generated, and do the inline stuff if it hasn't. 
> Though that still limits what you can do with code motion and other 
> optimizations.
> 
> >If any of the high-level OO system can not be used, you have to choose
> >a lower level one and map these to it,
> >a vtable bytecode mapping model is too underspecified.
> 
> Oh, sure, saying "vtable bytecode mapping model" is an awful lot like 
> saying "procedural language"--it's informative without actually being 
> useful... :)

I imagine you already know: especially when compiling to native code,
it is all a matter of optimizing for the common case, and be prepared
to be quiet slow otherwise, especially when dealing with dynamic changes,
both in Perl and Python there is no clear distiction from normal ops and
dynamic changes to methods... but in any case they are rare compared to the
rest. Threading adds complexity to the problem.

For the rest is just speed vs. memory, customization is a clear example
for that.

regards, Samuele Pedroni.