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