Re: PDD 2, vtables

Front page | perl.perl6.internals | Postings from February 2001

From:

Dan Sugalski

Date:

February 8, 2001 09:40

Subject:

Re: PDD 2, vtables

Message ID:

5.0.2.1.0.20010208123315.020e3eb8@24.8.96.48

At 12:12 PM 2/8/2001 +0000, Nicholas Clark wrote:
>On Wed, Feb 07, 2001 at 01:24:27PM -0500, Dan Sugalski wrote:
> > At 06:12 PM 2/7/2001 +0000, Nicholas Clark wrote:
>
> > >But I don't like the thought of going in and out of a lot of generic
> > >routines for
> > >
> > >$a = 3;
> > >$a += 2;
> > >
> > >when the integer scalar ought to know what the inside of another integer
> > >scalar looks like, and that 2 + 3 doesn't overflow.
> >
> > That particular case would get caught by the optimizer (I'd hope) so it'd
> > not be an issue anyway.
>
>Oops. Should have written it as
>
>sub foo {
>   $[0] += 2;
>}
>
>and somewhere else
>
>$a = 3; &foo ($a);

It's examples like these that make me wince at the things we can't do in 
the perl optimizer. (This is a great candidate for inlining, and we 
probably won't be able to.)

>but I agree - we need to time these things, not talk about them

Once we hammer out the vtable spec, I want to start writing code for the 
base vtable types. (Plain scalar, plain array, plain hash) I'm hoping this 
won't be hindered by the current licensing terms. (Which are laid out in 
http://archive.develooper.com/perl6-internals%40perl.org/msg01678.html for 
the interested)

> > >Hmm. += isn't another opcode
> > >it's a special case of a = b + c where the PMCs for a and b are the same
> > >thing. And I see no real reason why it can't be part of the + entry.
> >
> > Whether a special case in the code would get a speedup or not's up in the
> > air. (Is the test and branch faster than a generic doing it routine?) I'd
> > want to test that and see before I decided.
>
>Yes, we're trading size [data cache (larger virtual tables on scalars) +
>instruction cache (2 routines)] versus branch slowdown.  Or probably
>something more complicated than that.

And probably completely counter-intuitive on top of it. (Plus the 
performance characteristics will probably be completely opposite on x86 and 
Alpha/SPARC machines. That'd be about right)

>Hence your approach of make it flexible enough and try both.

Yep. Time it and try it, I think.

					Dan

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