Dan Sugalski wrote:
> At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
> >If the guts of a vtable implementation are ripped out and given an
> >op, isn't that inlining a PMC method? There doesn't seem much point
> >in replacing a dynamic vtable offset with a constant vtable offset.
> >The method really needs to be inlined -- either by copying the code
> >or by calling the implementation directly.
>
> We can't do that. PMCs, even statically typed ones, can change their
> vtables as they see fit. Also for this to be at all efficient we'd need to
> have all the common variable types vtables be available at compile time.
> That's not likely in the general case.
Isn't this a language decision and not a Parrot decision? Shouldn't Parrot
leave optimization strategy to the compiler?
I've been thinking of ways to speed up stuff like:
foreach my $x (@vector) {
$x *= $scale
}
also written
@vector ^*= $scale;
or even
for (my $i = 0; $i < @vector; ++$i) {
@vector[$i] *= $scale
}
If Perl can keep the loop index in an integer register, then Parrot
could use fast loop ops. IMHO there's no point in using fast loop ops
if taking the length of @vector is expensive.
It seems like Perl might have a tough time in general using non-PMC
registers. Is anybody working on the Perl code generator yet? I think
the code generator might influence op implementation.
- Ken
