Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2115 > unrolled thread

My final thoughts...

Back to article view | Back to comp.programming.threads

Contents

  My final thoughts... aminer <aminer@toto.net> - 2014-03-18 19:54 -0700
    Re: My final thoughts... aminer <aminer@toto.net> - 2014-03-18 19:58 -0700
    Re: My final thoughts... Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2014-03-19 23:47 +0000

#2115 — My final thoughts...

Hello,

That's not the end of the story , here my final thoughts...

Look inside my RWLockX , inside WLock() we will read this:


repeat
  event2.setEvent;
  asm pause end;
  event2.resetEvent;
until nbr^.nbr=0;

I said before since the reader section is in general more scalable
so even if the above code will generate cache-coherence
traffic, i think that it will not slow or it will not slow by much the
reader threads cause the reader section is scalable or more scalable.

and inside RLock() we will read this:

LockedExchangeAdd(nbr^.nbr,1);
LockedExchangeAdd(FCount1^[myid].fcount1,-1);
event2.waitfor(INFINITE);
LockedExchangeAdd(FCount1^[myid].fcount1,1);;
LockedExchangeAdd(nbr^.nbr,-1);


the serial part inside this section above is too small so we will not
include it in the Amdahl equation


And about the following code inside RWLock():


for i:=0 to GetSystemThreadCount-1 do
   begin
     while (FCount1^[i].fcount1<>0)
       do
        begin
        end;
    end;

This code will lower the parallism step by step but
you still will have in average a decent parallelism...


So for a scenario of 0.1% of write, to be able to project scalability we 
just have to calculate the time that it takes to run 2000 times the 
writer section and this will constitute a good approximation for the 
serial part... and the parallel part is, in the best case, 2000000 times 
that we run the reader section minus 2000 times that we run the writer 
section this will give us the parallel part, and after that we will plug 
the results into the Amdahl equation and this will give us the projected 
scalability.

This has giving me the following results on my benchmarks this has
benn done with a  little bigger reader and writer section and
equal execution time of the reader and writer section, here is the results:

LW_RWLOCK and LW_RWLockX have scaled both of them to 88X

RWLockX have scaled to 11X

RWLock have scaled to 11X


And i have said also that:

This is not the end of the story cause you have to understand that if 
from the time t1 to the time t2 there is writes and reads and from the 
time t2 to time t3 there is only reads, so even if the time from t1 to 
t2 will add more to the overall time cause there is writes threads, the 
perceived throughput from time t2 to t3 will be higher and the waiting 
time from t2 to t3 will be lower cause all my RWLocks will be scalable 
from t2 to t3 and this will make my all my RWLocks useful cause for 
exemple the database clients from internet or intranet waiting from t2 
to t3 will be served more quickly and this is still useful and this will 
make my RWLocks still useful.



So to conclude:

I think that all the variants of my scalable RWLock 3.05 are useful
and especially my LW_RWLOCK and LW_RWLockX that scales better.


You can download my scalable RWLock 3.05 from:


http://pages.videotron.com/aminer/


Thank you,
Amine Moulay Ramadane.




Thank you,
Amine Moulay Ramdane,

[toc] | [next] | [standalone]

#2116

Hello,

This new and final calculations was done for a scalable reader section.



Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#2123

On Tue, 18 Mar 2014 19:54:54 -0700
aminer <aminer@toto.net> wrote:
> Hello,
> 
> That's not the end of the story , here my final thoughts...

I wish they were.  Sadly, not.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web