Re: should vtables be vtables?

At 02:40 PM 6/13/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <dan@sidhe.org> wrote:
> > At 12:00 PM 6/13/2001 +0100, Dave Mitchell wrote:
> > >should we abandon vtables (ie arrays of fn pointers indexed by op),
> > >and just have a single hander function per type which has the op as an 
> arg?
> >
> > Are you talking vtables (which we're using for functions attached to data)
> > or the indirect opcode function table? If the former, we don't want to
> > abandon the idea for anything other than a crippling speed hit, since it
> > gives us a lot of flexibility cheaply. Abandoning a function table for the
> > ops for a switch means that extension opcodes are going to be slower than
> > normal ones--we'll essentially have to maintain both the switch and the
> > dispatch table.
>
>I'm talking about the former, ie calling a function in a vtable.
>The problem with vtables is that we get an explosion of micro functions,
>all containing similar chunks of code. If instead of providing a vtable,
>a PMC type just provides a since generic handler function, then each
>individual type gets to choose how to best dispatch its own functions.

Generic handler functions add a layer of overhead, and we're trying to skip 
that whenever we can.

Also, just because we have 10 or 20 vtables doesn't mean that they can't 
share functions. If we have an integer and float cache in the PMC, all 
sorts of different vtables can have pointers to the same function for the 
"return integer" function.

>I guess it depends to what extent we expect Perl to mess with vtables:
>if a particular PMC type gets to statically(ish) define its own vtable,
>a single handler *may* may make sense. If Perl is going to go around
>gratuitously altering vtable contents on the fly without the cooperation of
>that PMC type, then it's not a goer.

Well, odds are the vtable functions will mess with variable vtable pointers 
themselves. (Though not the tables)

Mutating vtable pointers can make things faster. For example, take the 
regular perl scalar. You do:

    $foo = "12";

and $foo gets the "just a string" vtable. Then do a:

    $bar = $foo + 12;

and the interpreter calls the get_integer function of $foo. That function 
unconditionally calls the string-to-integer conversion (since we know that 
we're a string--we don't have to check) then caches the value, changes the 
vtable pointer to the "just a string and integer" table, and returns the 
integer.

Later you do:

    $baz = $foo + 8;

and $foo's get_integer function unconditionally returns the cached integer. 
(The "just a string and integer" table needs not check to do a conversion, 
since we know the integer cache is valid, otherwise we'd have a different 
vtable...)

If after that you do:

    $foo += 1;

then $foo gets the "just an integer" vtable pointer jammed in it, and the 
dance starts all over again, more or less.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

• should vtables be vtables? by Dave Mitchell
• Re: should vtables be vtables? by Dave Mitchell
• Re: should vtables be vtables? by Dan Sugalski
• Re: should vtables be vtables? by Dan Sugalski
• Re: should vtables be vtables? by Bart Lateur