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

Reply via email to