PCC reordering idea (and probably branch)

Allison Randal allison at parrot.org
Thu Mar 15 23:46:43 UTC 2012


On 03/15/2012 03:59 PM, Vasily Chekalkin wrote:
> On Fri, Mar 16, 2012 at 4:14 AM, Allison Randal <allison at parrot.org> wrote:
>> This approach is not thread-safe. There's a very good reason for keeping
>> all data relevant to the call contained within the CallContext for that
>> call.
> 
> Really? How it's can be non-thread safe? And what other reasons for
> "keeping all data" in prematurely created CallContext?

Think of Erlang. Every subroutine is a safe point to split off parallel
execution, because every subroutine is a self-contained unit. This is
absolutely critical in moving toward modern concurrent implementations.
They can handle things like data-parallelism in the background
automatically. It doesn't make sense to jettison one of Parrot's best
features and take a step backward toward stack-like dispatch.

>> The main solution for the performance problem is to replace the GC with
>> a reasonably performant modern implementation. Another improvement would
> 
> Niiice. Do tell me. Especially because I've put about one year effort
> to bring Generational GC parrot. And it's maximum what we can do now.
> All other algorithms requires "movable" GCable (for compacting). And
> without rewriting whole PMC/Buffer handling in Parrot it's virtually
> impossible to implement.

Then maybe we should be looking at rewriting PMC/Buffer handling instead
of this. If the real problem is the fact that allocating CallContexts is
expensive, then attack the root and make it less expensive.

Do you have some profiling results that show where the current GC is
most expensive?

> Yes, "6model" is better foundation for implementing compacting than
> current PMC.data/VTABLE_mark approach. But it'sjust foundation and
> will require a lot of work to implement moving/compacting.

Something of a tangent, but how much of Parrot's current dispatch does
6model use? Anything? Parrot currently has a pile of pretty expensive
corner cases baked into dispatch that were added for Perl 6. But, if
Perl 6 isn't using them anymore, then ripping them out could give Parrot
some substantial speed gains (and improve maintainability at the same
time). The current multiple dispatch plumbing is a good example. It was
designed for Perl 6, but AFAIK, Perl 6 doesn't use it anymore.

>> be to make CallContexts lazy, so storage for registers isn't allocated
>> until it's absolutely needed (in some cases, never). Polymorphism can
> 
> No. Current approach is exactly this. And it's slow. Twice slower for
> the record. Because in 99% of the cases we are calling GC _twice_ to
> allocate CallContext.

Then we need to work on calling GC only once. Or allocate CallContexts
from a separate short-lived pool to isolate them from the main body of GC.

TMTOWTDI. Always.

>> help too, it may be appropriate for calls to C functions to use a much
> 
> No. Polymorphism will _slow_ things down. Me and chromatic broke "poor
> man VTABLE polymorphism" after landing of current PCC just to bring it
> on speed with previous one. And I'm talking about 30% performance
> improvement.

Based on what profiling results?

>> simpler CallContext that respects the same interface as the standard one.
> 
> Anyway, current PCC approach is wrong from the beginning. We always
> doing marshalling/demarshalling of arguments for all calls. And it's
> _slow_. Really really slow.

I'm all for speeding things up. And I'll be the first to admit that
Parrot's current dispatch system was only intended as a "temporary"
partial fix of the old dispatch system (which was a horrible mass of
spaghetti code.) But further fixes need to be based on profiling data,
and not sacrifice Parrot's key competitive features.

Allison


More information about the parrot-dev mailing list