Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 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
>90
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.
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 eac
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
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 a
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.
--
