On 03/15/2012 03:59 PM, Vasily Chekalkin wrote: > On Fri, Mar 16, 2012 at 4:14 AM, Allison Randal <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
