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? > 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. 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. > 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. > 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. > 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. -- Bacek. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
