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


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

More precision...

Started byaminer <aminer@toto.net>
First post2014-04-27 23:18 -0700
Last post2014-04-27 23:21 -0700
Articles 2 — 1 participant

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


Contents

  More precision... aminer <aminer@toto.net> - 2014-04-27 23:18 -0700
    Re: More precision... aminer <aminer@toto.net> - 2014-04-27 23:21 -0700

#2282 — More precision...

Fromaminer <aminer@toto.net>
Date2014-04-27 23:18 -0700
SubjectMore precision...
Message-ID<ljkh87$kp1$5@news.albasani.net>
I wrote:
 > since the Chriss Thomasson algorithm uses less variables
 > than my  algorithm, 3 in total, that generate data  movements
 > between caches or from the memory susbsystem and the caches ,
 > and this has been a factor cause less variables means less
 > contention and less waiting time on a small number of threads and on 
 > a small  number of core,   so the Chriss Thomasson algorithm
 > has scored 33% more throughput than my algorithm , this is true only 
 > when there is fewer threads on fewer cores, as i have just explained, 
 > but as soon as you run my algorithm with mores threads on more and
 > more cores, my algorithm will score better throughput and will equal 
 > that of the Chriss Thomasson algorithm.


I correct a mistake, those variables in my algorithm that generate data 
movements between caches and between the memory system and the local 
caches, causes contention even on more and more cores with more and more 
threads. Just try to visualize it by simulating it on your head and you 
will understand it clearly, so the contention is a "factor" on my 
algorithm and in the Chriss Thomasson algorithm.

And since the pop() method of the Chriss Thomasson uses less variables
than my algorithm, those variables causes data movements on the "Bus",
and those data movements must be serialized on the Bus, that means
that the Chriss Thomasson algorithm causes less less contention in
this scenario this concurrent FIFO queue , and less contention
in this scenaio means less waiting time and less waiting time means more 
throughtput.



Thank you,
Amine Moulay Ramdane.


[toc] | [next] | [standalone]


#2284

Fromaminer <aminer@toto.net>
Date2014-04-27 23:21 -0700
Message-ID<ljkhf9$kp1$8@news.albasani.net>
In reply to#2282
I correct:

I wrote:
 > since the Chriss Thomasson algorithm uses less variables
 > than my  algorithm, 3 in total, that generate data  movements
 > between caches or from the memory susbsystem and the caches ,
 > and this has been a factor cause less variables means less
 > contention and less waiting time on a small number of threads and on 
 > a small  number of core,   so the Chriss Thomasson algorithm
 > has scored 33% more throughput than my algorithm , this is true only 
 > when there is fewer threads on fewer cores, as i have just explained, 
 > but as soon as you run my algorithm with mores threads on more and
 > more cores, my algorithm will score better throughput and will equal 
 > that of the Chriss Thomasson algorithm.


I correct a mistake, those variables in my algorithm that generate data 
movements between caches and between the memory system and the local 
caches, causes contention even on more and more cores with more and more 
threads. Just try to visualize it by simulating it on your head and you 
will understand it clearly, so the contention is a "factor" on my 
algorithm and in the Chriss Thomasson algorithm.

And since the pop() method of the Chriss Thomasson uses less variables
than my algorithm, those variables causes data movements on the "Bus",
and those data movements must be serialized on the Bus, that means
that the Chriss Thomasson algorithm causes less  contention in
this scenario of this concurrent FIFO queue , and less contention
in this scenario means less waiting time and less waiting time means 
more throughtput.



Thank you,
Amine Moulay Ramdane.



[toc] | [prev] | [standalone]


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


csiph-web