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

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

About Parallel Disk IO

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

Contents

  About Parallel Disk IO Ramine <ramine@1.1> - 2015-01-12 15:09 -0800
    Re: About Parallel Disk IO Ramine <ramine@1.1> - 2015-01-12 15:50 -0800
    Re: About Parallel Disk IO Ramine <ramine@1.1> - 2015-01-12 15:52 -0800

#2794 — About Parallel Disk IO

Hello,


I have read the following webpage about Parallel Disk IO by Dmitry 
Vyukov, here it is:

http://www.1024cores.net/home/scalable-architecture/parallel-disk-io


Read it carefully and you will notice that it is not optimal,
cause a better way to do is that the threads must read directly from the 
harddisk, but you have to use my following mechanism: an independent 
thread from the readers threads will calculate the throughput of the 
system , since you have to read equal chunks of data from the file, and 
as the reader threads will process the data they will update a 
"counter"each time they process the chunk of data , and the independant 
thread that calculates the throughput will read the "counter" two times 
in an interverval of t and it will
calculate the throughput that is: (counter_2 - 
counter_1)*size_of_the_chunk_of_data / t,  and counter_2 - counter_1 is 
the time of the interval and the independant thread that calculates the 
throughput have to start more threads and it will recalculate the 
throughput and if the throughput goes up it will start more
threads, but if the throughput goes down it will take the previous count 
of the threads and it will start this count number of threads and blocks 
the other threads , this way my mechanism will more optimal than the 
Dmitry Vyukov mechanism, and the independant thread will follow the same 
mechanism throughout the duration of the reading of the file, that means 
it will start more threads and recalculate the throughput and if the 
throughput goes up it will start more threads, but if the throughput 
goes down it will take the previous count of the threads and start this 
count number of threads and it will blocks the other threads , this is 
my own mechanism that i am presenting to you and  i think it is more 
optimal than the Dmitry Vyukov way of doing.




Thank you for your time.



Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#2795

Hello,

If the chunks of data are not equal insize, the processing threads mcan 
update the counter of the total processed chunks of data and also they 
can update counter the total size of the data that has been processed 
and this way the independant thread that adjust the number of threads 
will do its calculation of the throughput with a mean size of the chunk
of data. That's the way to do it i think.


Thank you for your time.


Amine Moulay Ramdame.


On 1/12/2015 3:09 PM, Ramine wrote:
> Hello,
>
>
> I have read the following webpage about Parallel Disk IO by Dmitry
> Vyukov, here it is:
>
> http://www.1024cores.net/home/scalable-architecture/parallel-disk-io
>
>
> Read it carefully and you will notice that it is not optimal,
> cause a better way to do is that the threads must read directly from the
> harddisk, but you have to use my following mechanism: an independent
> thread from the readers threads will calculate the throughput of the
> system , since you have to read equal chunks of data from the file, and
> as the reader threads will process the data they will update a
> "counter"each time they process the chunk of data , and the independant
> thread that calculates the throughput will read the "counter" two times
> in an interverval of t and it will
> calculate the throughput that is: (counter_2 -
> counter_1)*size_of_the_chunk_of_data / t,  and counter_2 - counter_1 is
> the time of the interval and the independant thread that calculates the
> throughput have to start more threads and it will recalculate the
> throughput and if the throughput goes up it will start more
> threads, but if the throughput goes down it will take the previous count
> of the threads and it will start this count number of threads and blocks
> the other threads , this way my mechanism will more optimal than the
> Dmitry Vyukov mechanism, and the independant thread will follow the same
> mechanism throughout the duration of the reading of the file, that means
> it will start more threads and recalculate the throughput and if the
> throughput goes up it will start more threads, but if the throughput
> goes down it will take the previous count of the threads and start this
> count number of threads and it will blocks the other threads , this is
> my own mechanism that i am presenting to you and  i think it is more
> optimal than the Dmitry Vyukov way of doing.
>
>
>
>
> Thank you for your time.
>
>
>
> Amine Moulay Ramdane.
>
>
>
>
>

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

#2796

Hello,

If the chunks of data are not equal in size, the processing threads can 
update the counter of the total processed chunks of data and also they 
can update counter of the total size of the data that has been processed 
and this way the independant thread that adjust the number of threads 
will do its calculation of the throughput with a mean size of the 
chunkof data. That's the way to do it i think.


Thank you for your time.


Amine Moulay Ramdame.

[toc] | [prev] | [standalone]

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

csiph-web