[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6391] Re: lots of Threads

From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-11-16 10:59:07 UTC
List: ruby-talk #6391
On Thu, 16 Nov 2000, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
> 
> > If I have an array to be filled with computationally heavy stuff, 
> > I could use a load of Threads to populate it in parallel.  If I often
> > have to re-populate it, I don't want to kill them all off and start
> > them again.
> 
> But why would that be faster? Ruby threads can't take advantage of

I'm not sure that it would.  Certainly if I have to create and destroy
lots of threads it will be lots slower...

> multiple processors, so unless filling the array also involves waiting 

OK, I had a vague feeling that it could not...

> for I/O, I'd guess it would go slower with threads (as the old Coke ad 

The actual filling won't be using I/O but I will be shoving the contents
of the array out to tape, after I have filled it, and I'm now wondering
about the best way to tackle that producer-consumer problem.  Do I need
a Mutex.synchronize to access the buffer, or will Thread.stop, athread.run
give sufficient control?

I'm not sure how to optimise that though.  I think the tape has a buffer,
and I cannot see from 'ruby -r profile' how much time is really spent by
the CPU in handling the I/O, so I'm not sure how to optimise how much data
I create and then push out at once.
 
The tape seems very slow actually, but filling the array is also time
consuming.  The fastest way I have found seems to be to use collect! as
fill cannot take a block.

Hmm... is there a good reason why fill should not take a block?  If you
want to create new contents for an array, without reference to what was
there before, I think fill {...} could possibly be faster than
collect! {...}, because collect! must have the code for picking up the old
element values.


If you wonder what I'm doing with this tape:  Our backup has failed to
put 3GB on a 12/24 GB tape.  12/24 is without/with compression.  So I'm
writing random data to the tape (so it won't compress well) to see how
much fits on, and I'm expecting some kind of exception when I run out of
media.   If the diags from ufsdump were better I might not have to do
this.

> used to say).
> 
> 
> Dave
> 
> 
	Hugh



In This Thread