[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Concurent (using threads) slower than sequential -doubt

Yukihiro Matsumoto

10/6/2008 3:58:00 AM

Hi,

In message "Re: Concurent (using threads) slower than sequential -doubt"
on Mon, 6 Oct 2008 12:40:08 +0900, Carlos Ortega <caof2005@yahoo.com> writes:

|As you see, the thread based program run slower.
|I thought that by using threads it will be faster, but it didn't....Why
|is it slower?

Threads require context switching, so that they tend to run slower,
especially green threads like Ruby 1.8 has.

matz.

3 Answers

Robert Klemme

10/6/2008 9:40:00 AM

0

2008/10/6 Yukihiro Matsumoto <matz@ruby-lang.org>
>
> In message "Re: Concurent (using threads) slower than sequential -doubt"
> on Mon, 6 Oct 2008 12:40:08 +0900, Carlos Ortega <caof2005@yahoo.com> writes:
>
> |As you see, the thread based program run slower.
> |I thought that by using threads it will be faster, but it didn't....Why
> |is it slower?
>
> Threads require context switching, so that they tend to run slower,
> especially green threads like Ruby 1.8 has.

There is another issue which may easily have a more serious impact:
since all three files reside in the same directory they are read from
the same physical device (most likely a local (S)ATA disk). And since
these files are large chances are that they are spread over the disk
and do not fit into the operating systems buffer cache. This will lead
to reasonably more head movement and less efficient disk caching than
the sequential approach.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end

Carlos Ortega

10/6/2008 1:41:00 PM

0

Thank all of you (Matz, Charles and Robert)

Just one more doubt.....

Since the threads I created really resides as an array that holds
threads object I tried to access each one by using [ ] notation:

for t in m_threads
print t[:INDEX], "\n"
end

The interpreter does not throw any error, but results always indicate:
nil
nil
nil

I tried to verify if they are still running:

Thread.list.each{|t| p t}

Results were:
#<Thread:0x29c5fc0 run>
#<Thread:0x29c6100 run>
#<Thread:0x29c6240 run>
#<Thread:0x294c74c run>

So indeed they are running... the doubt is...why I can't access the
content of the array?
In fact in the statement
m_threads.each{ |t| t.join; result = t[:INDEX] + result; }

I just can compute result variable only after executing t.join..... if
I take out the t.join statement the interpreter throws an error:

PbaThreads.rb:10 : undefined method `+' for nil:NilClass (NoMethodError)

Could you clarify this, please.

Best Regards




Robert Klemme wrote:
> 2008/10/6 Yukihiro Matsumoto <matz@ruby-lang.org>
>>
>> In message "Re: Concurent (using threads) slower than sequential -doubt"
>> on Mon, 6 Oct 2008 12:40:08 +0900, Carlos Ortega <caof2005@yahoo.com> writes:
>>
>> |As you see, the thread based program run slower.
>> |I thought that by using threads it will be faster, but it didn't....Why
>> |is it slower?
>>
>> Threads require context switching, so that they tend to run slower,
>> especially green threads like Ruby 1.8 has.
>
> There is another issue which may easily have a more serious impact:
> since all three files reside in the same directory they are read from
> the same physical device (most likely a local (S)ATA disk). And since
> these files are large chances are that they are spread over the disk
> and do not fit into the operating systems buffer cache. This will lead
> to reasonably more head movement and less efficient disk caching than
> the sequential approach.
>
> Kind regards
>
> robert

--
Posted via http://www.ruby-....

Robert Klemme

10/6/2008 2:39:00 PM

0

2008/10/6 Carlos Ortega <caof2005@yahoo.com>:
> Thank all of you (Matz, Charles and Robert)
>
> Just one more doubt.....
>
> Since the threads I created really resides as an array that holds
> threads object I tried to access each one by using [ ] notation:
>
> for t in m_threads
> print t[:INDEX], "\n"
> end
>
> The interpreter does not throw any error, but results always indicate:
> nil
> nil
> nil
>
> I tried to verify if they are still running:
>
> Thread.list.each{|t| p t}
>
> Results were:
> #<Thread:0x29c5fc0 run>
> #<Thread:0x29c6100 run>
> #<Thread:0x29c6240 run>
> #<Thread:0x294c74c run>
>
> So indeed they are running... the doubt is...why I can't access the
> content of the array?
> In fact in the statement
> m_threads.each{ |t| t.join; result = t[:INDEX] + result; }
>
> I just can compute result variable only after executing t.join..... if
> I take out the t.join statement the interpreter throws an error:
>
> PbaThreads.rb:10 : undefined method `+' for nil:NilClass (NoMethodError)
>
> Could you clarify this, please.

Well, this is obvious: you cannot access the result before it's there.
Since you are setting this as the last statement in the thread you
need to wait (i.e. join) until the thread finishes.

Btw, you can use Thread#value for this. Here's a variant:


require 'benchmark'

files = (1..3).map {|i| "C:\\numbers#{i}.txt"}

Benchmark.bmbm 10 do |b|
b.report "threaded" do
threads = files.map do |file|
Thread.new file do |f|
File.open f do |io|
io.inject(0) {|sum, l| sum + l.to_i}
end
end
end

puts threads.inject(0) {|sum, th| sum + th.value}
end

b.report "sequential" do
puts files.inject(0) {|s, f|
File.open f do |io|
io.inject(s) {|sum, l| sum + l.to_i}
end
}
end
end


Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end