The HLL Performance Gap
Andrew Whitworth
wknight8111 at gmail.com
Wed Jul 22 00:22:09 UTC 2009
This is quite excellent analysis and a good summation of important points.
On Tue, Jul 21, 2009 at 7:31 PM, Geoffrey Broadwell<geoff at broadwell.org> wrote:
> 1. Add past_optimize and post_optimize passes to PCT. Start with just a
> single useful optimization in each.
>
> 2. Make it easy to plug in additional optimizations in a way that allows
> people to work in parallel on different optimizations without blocking
> on each other unduly.
Last summer this was actually a suggested GSOC project, although I
don't think there were any takers for it. So, there is some prior
thought put into it.
Good optimization steps are orthogonal and non-interacting. Any well
designed optimization system should make it perfectly possible for
people to develop stages in parallel and plug them in arbitrarily.
> 5. Analyze and micro-optimize Rakudo's per-scope boilerplate. Focus
> first on optimizations that other HLLs may be able to use for their own
> particular boilerplate hell.
A lot about the Rakudo boiler plate could definitely be optimized,
although I want to be careful that we worry about getting Rakudo more
feature complete before we start aggressive optimization.
That said, I think there are a lot of cases where special variables
could be created more lazily (and in some scopes not created at all if
not needed).
> 6. Reduce the overhead of PIR sub calls. I believe Allison is already
> working on refactoring that will help with this, but I suspect there
> will be more improvement possible even after her work is merged.
>
> 7. Allow lexical scopes to be separate from PIR subs. If sub calls
> become really cheap, this will be unnecessary. If sub calls remain
> expensive, this should be considered.
It may worthwhile to create a separate Sub-like object that is much
lighter weight (does not pass parameters or returns for example) and
only serves as a delimiter for lexical scopes. It would be nice if
Subs became so inexpensive, although having a separate such object
would enable Subs to do more then was strictly needed for a simple
lexical scope. One possible optimization step could be inlining of
subroutines like this where scope is not necessary.
All very good information and some very good ideas. I would like to
see much of this come to fruition sooner rather then later.
--Andrew Whitworth
More information about the parrot-dev
mailing list