On Thu, May 21, 2009 at 12:11 AM, Patrick R. Michaud <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
