List of possible rakudo needs from Parrot

Patrick R. Michaud pmichaud at pobox.com
Thu Nov 5 09:14:18 UTC 2009


On Wed, Nov 04, 2009 at 03:30:35PM -0800, chromatic wrote:
> I think we have to make Rakudo's priorities for Parrot priorities for Parrot 
> committers.  We've done pretty well at guiding committers to specific tasks 
> when we have them.  My question is now "How do we pick what to work on that 
> helps Rakudo the most?"

Several things I can think of off the top of my head that would help Rakudo out:

1. Overall Parrot Performance.  This can be subdivided into several subtopics:
   A.  Although the new calling conventions are now performing at a level
       comparable to Parrot speed prior to the refactor, one of the primary
       purposes of the refactor was to set the stage to get a *substantial*
       improvement in the overall speed of subroutine calls, and this has
       yet to be acheived.  So while there are congratulations to be had all
       around on the PCC accomplishments thus far, in some ways the work 
       is actually yet incomplete.

   B.  Profiling.  The profiling tools are excellent -- where people
       help both Rakudo/NQP as well as Parrot itself is to be doing 
       profiles of the generated code.  I highly recommend profiling 
       things run in NQP -- it's much smaller than Rakudo, yet 
       representative of the issues facing all HLLs.

   C.  Review the code generated by the compiler tools and find places
       to reduce inefficiencies (both in what the compiler tools produce
       and what Parrot provides).  But BEWARE, for here be dragons, and
       I've already had a fair bit of frustration in discussing the issues
       with others on this front.  Many people look at the PAST/POST output 
       and quickly conclude that the tools are pretty stupid, because 
       they seem to produce terribly inefficient and convoluted code.  
       But PAST and POST aren't stupid -- rather, they're often doing 
       the only thing they can possibly do to make things work given 
       Parrot's underlying semantics and available opcodes.  The fetch
       and vivify operations are an example here -- PCT *by necessity*
       (because of Parrot's underlying limitations) has to generate 
       five or six lines of PIR for every fetch and vivify operation.
       In some very limited situations this can be optimized, but AFAICT
       in the common and general case it cannot.

       Iindeed, it was studying the PIR output of PCT that caused Austin 
       and Geoffrey to want to do something to make it more efficient 
       and proposed solutions to Trac.  Alas, both of their proposals
       were fundamentally flawed (which shows how easy it is to 
       over-simplify the problem), but from Austin's proposal we did
       eventually identify a very workable solution using new
       "fetch" and "vivify" opcodes.

2.  Develop a clean model for expressing HLL assignment and bind
    semantics commonly used by HLLs.  Currently Parrot's container/value
    and lvalue/rvalue semantics are seriously convoluted.  My preference 
    at this point would be to simply implement fetch/vivify opcodes
    while a plan for a cleaner model is being developed.  (Given the
    depth of the problems involved, I sincerely doubt a new model
    can be ready prior to 2.6.)

3.  Currently there are few mechanisms in Parrot for being able to 
    build constant HLL-specific data structures and have them frozen 
    into bytecode.  Instead, the data structures always have to be 
    rebuilt at runtime.  Indeed, this is one of the primary reasons why 
    Rakudo startup takes so long-- it's having to manually build a lot
    of the tables and data structures needed to perform compilation 
    and execution.  For every Perl 6 subroutine (including all
    of the operators and built-in methods), at program startup we have
    to run through a bunch of initialization code that builds the
    signature data structure for each sub and attaches it to the sub.
    (In our new version of Rakudo we're going to be doing a lot more
    of our constants initialization lazily at runtime, but it would be 
    far better if we didn't have to do it at runtime at all.)

4. Change Parrot's release expectations and support policies to 
   recognize the reality of HLL and Parrot development as they exist
   today, and not as they might exist in at some point in the future
   when things are "stable".  

   Official Parrot policy is that HLL developers and library
   writers are supposed to target "the latest supported (6-month) 
   release"; sometimes we give lipservice to the idea that HLLs
   should at least limit themselves to using monthly releases;
   the reality for Rakudo is that the absolute longest we've 
   been able to make use of any Parrot monthly release is five days.
   (The average is about two days, although sometimes the time
   is actually measured in hours.)

   The current reality is simply this:  Big changes to Parrot
   typically land in the hours following a monthly release.  Thus
   even though an important Parrot feature needed by a HLL might be
   completed in a branch in early April, it won't appear in trunk until
   after the April release, and it won't be in any "official" Parrot
   release until the following May, it won't be in a "supported release"
   until the following July.  If a deprecation was involved, it's not
   in a supported release until the following January.

   I'm not saying we should change the way changes get committed
   to Parrot; I am saying we should recognize that at this stage of
   HLL development on Parrot, six weeks, three months, and nine 
   months are awfully long times for HLL developers to be waiting 
   to officially release products that make use of new core Parrot 
   features.  Any decisions or statements that Parrot makes that 
   are based on HLL developers following the official policy
   are frankly ludicrous.

5. Come up with a good way to force a sub to exit, rolling up the
   intermediate call chain in the process.  Essentially this 
   perhaps comes down to invoking a sub's return continuation, 
   except that we also have to make sure that any exit handlers 
   for intermediate blocks in the chain are also executed in the
   process.  (For that matter, we have to figure out what subroutine 
   exit handlers might look like in order to accommodate this.)

6. Figure out a way for lexical symbols to refer to something other
   than a PMC.  Right now all lexical symbols must be PMCs, which
   severely limits the ways in which a HLL can try to influence
   code generation making use of lexical variables in Parrot.
   For Rakudo in particular, it means we have no real mechanism for 
   expressing "my int $a"  such that $a refers to an integer register 
   and also available in nested lexical scopes.

I'm sure other HLL folks can come up with more.  If you're wondering
why we haven't mentioned some of these before now, it's because
many of these are far less critical than other features we've
needed, and those critical needs weren't being timely addressed.

Thanks,

Pm


More information about the parrot-dev mailing list