Shared vs non shared PMC timings
To estimate the costs of shared PMCs I have run this program[1], once with .Ref and once with .SharedRef. There are 2 major issues: 1) PMC initialization (new_p_ic_p): The shared PMC needs additionally the allocation of the synchronize structure and the MUTEX_INIT. 2) PMC access (set_p_i): locking/unlocking the mutex Here are snippets from the profile: with SharedRef CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms - --- -- -- 753 new_p_ic_p 100.157785 0.0016 905 set_p_i100.049269 0.0005 with Ref CODE OP FULL NAMECALLS TOTAL TIME AVG T. ms - --- -- -- 753 new_p_ic_p 100.051330 0.0005 905 set_p_i100.011356 0.0001 (Overall timings aren't really comparable, the SharedRef also does a LOCK for mark, which slows that down as well) Linux 2.2.16, Athlon 800, unoptimized Parrot build. leo [1] set I0, 10 set I1, 0 lp: new P0, .PerlInt new P1, .Ref, P0 # or .SharedRef set P1, I1 inc I1 lt I1, I0, lp end
RE: Shared vs non shared PMC timings
Leopold Toetsch wrote: (Overall timings aren't really comparable, the SharedRef also does a LOCK for mark, which slows that down as well) ?? Why'd you do that? Competetive threads MUST be suspended (most likely with their cooperation, not with an OS suspend call) during the mark phase. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: Shared vs non shared PMC timings
At 5:48 PM +0100 1/20/04, Leopold Toetsch wrote: To estimate the costs of shared PMCs I have run this program[1], once with .Ref and once with .SharedRef. There are 2 major issues: 1) PMC initialization (new_p_ic_p): The shared PMC needs additionally the allocation of the synchronize structure and the MUTEX_INIT. This is a one-time cost. If a PMC has one, it should stick around after the PMC is destroyed and put on the free list. 2) PMC access (set_p_i): locking/unlocking the mutex with SharedRef 905 set_p_i100.049269 0.0005 with Ref 905 set_p_i100.011356 0.0001 Yeah, that's about right. There is, unfortunately, little to be done about it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Shared vs non shared PMC timings
Dan Sugalski [EMAIL PROTECTED] wrote: At 5:48 PM +0100 1/20/04, Leopold Toetsch wrote: 1) PMC initialization (new_p_ic_p): The shared PMC needs additionally the allocation of the synchronize structure and the MUTEX_INIT. This is a one-time cost. If a PMC has one, it should stick around after the PMC is destroyed and put on the free list. Ah yep. Good idea. leo
Re: Shared vs non shared PMC timings
Gordon Henriksen [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: (Overall timings aren't really comparable, the SharedRef also does a LOCK for mark, which slows that down as well) ?? Why'd you do that? I didn't do it :) Pmc2c.pm is too dumb, it just puts a LOCK/UNLOCK pair around each vtable mthod, and no one is telling it that there are exceptions ;) leo
Re: Shared vs non shared PMC timings
At 6:49 PM +0100 1/20/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 5:48 PM +0100 1/20/04, Leopold Toetsch wrote: 1) PMC initialization (new_p_ic_p): The shared PMC needs additionally the allocation of the synchronize structure and the MUTEX_INIT. This is a one-time cost. If a PMC has one, it should stick around after the PMC is destroyed and put on the free list. Ah yep. Good idea. I'll admit, I'm tempted to make it part of the arena initialization cost -- when a new PMC arena is allocated because we're out of headers we just unconditionally give 'em all sync structs if we're running threaded. The only worry there is resource exhaustion. Rumor has it that some systems have a limited number of mutexes, but I've never actually seen one of them. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
