Rakudo takes a significant speed hit when in its own HLL

[Will Coleda]

On Thu, May 21, 2009 at 12:11 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Tue, May 19, 2009 at 03:35:31PM -0500, Patrick R. Michaud wrote:
>> [...]  As an example, running the "make spectest" target on
>> my machine takes 33m13 when Rakudo is running in the 'parrot' HLL,
>> but takes 50m26 when in the 'perl6' HLL.  (Yes, that's 50% slower.)
>
> After #parrotsketch yesterday, Allison and chromatic did some
> checking into the problem and determined that PMCProxy class
> objects were not being re-used properly when requested from HLLs
> other than 'parrot'.
>
> Parrot has also left open a "hole" whereby it's possible for subs
> in non-HLLs to directly use classes that are actually in the 'parrot'
> namespace.  In particular, doing something like C< $P0 = new ['Integer'] >
> from a HLL other than Parrot should return a "class not found"
> exception (unless the HLL has defined its own Integer class).
> Currently Parrot goes ahead and looks up the Integer PMC type
> from the parrot HLL anyway.
>
> Consider the following example:
>
>    .sub 'main'
>        $I0 = 1
>      loop:
>        unless $I0 <= 20000 goto done
>        $P0 = new ['Integer']
>        inc $I0
>        goto loop
>      done:
>    .end
>
> On my system, when the above is run from the 'parrot' HLL namespace,
> the program completes in ~0.041 seconds, when run from a non-Parrot
> HLL namespace it requires ~0.425s .  Yes, that's a 10x difference.
> It's likely due to Parrot repeatedly creating PMCProxy objects
> for Integer on each invocation of C<new> from the non-parrot HLL.
>
> To make it easier to build PMCs from classes in foreign HLLs,
> we're introducing the C<root_new> opcode.  Like C<new>, it
> accepts a Key or ResizableStringArray as an argument;
> but the identifier is relative to the root namespace instead
> of the current hll.  For example, the following will correctly create
> a parrot Integer PMC from any HLL namespace (and avoid
> creating/mis-caching a PMCProxy for Integer on subsequent
> invocations):
>
>    $P0 = root_new ['parrot';'Integer']
>
> I've added the C<root_new> opcode as of r39007.
> When the test program above is rewritten to use C<root_new>,
> it requires ~0.049s on my system regardless of the HLL
> in effect.
>
> I will also start migrating PGE and PCT to use the C<root_new>
> opcode instead of C<new>.  Languages that have been running in
> their own HLL namespaces should thus see a substantial improvement
> in parsing speed, and possibly execution speed as well.
>
> Pm
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

I have noticed that the [namespace children] test (show all the child
namespace of the top level tcl namespace, which is really the top
level 'tcl' namespace in parrot) is now failing. Instead of just ::tcl
(which is parrot's ['tcl'; 'tcl']), it now returns:

::CodeString ::ExceptionHandler ::Getopt::Obj ::MultiSub ::NCI ::Sub ::TclDict :
:TclList ::TclProc ::tcl ::Undef

If I replace the explicit calls to "new 'CodeString'" with "root_new [
'parrot'; 'CodeString' ]", then that namespace drops off the list
above. But I can't replace all of these, because I'm not explicitly
instantiating all of these. (i.e. NCI, Sub, MultiSub)

When did this behavior change? Is it possible that root_new is a just
a bandaid here and we really should make 'new' work the way it used
to?

-- 
Will "Coke" Coleda