From: Carlos Ortega Date: 2008-10-06T22:41:00+09:00 Subject: Re: Concurent (using threads) slower than sequential -doubt 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: # # # # 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 >> >> In message "Re: Concurent (using threads) slower than sequential -doubt" >> on Mon, 6 Oct 2008 12:40:08 +0900, Carlos Ortega 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-forum.com/.