--- Paul <[EMAIL PROTECTED]> wrote:
> > But what to do about matrix arithmetic and other simple threadable
> > tasks?
> >
> > sub m_add(@a, @b) {
> > my @result;
> > my $i, $j;
> > @result = @a;
> > for @result -> $i {:is threaded # Thread this block?
> > for @result[$i]; @b -> $j; $b {
> > $j += $b;
> > }
> > }
> > }
>
> isn't $i an element alias rather than an index there?
Yeah, but I'm assuming a 2d matrix. @result[$i] is another array.
> Basically, I just failed to parse all that. Sorry -- internal P6
> parser still incomplete.
No, just bad writing on my part. Sorry.
>
> > Conversely, I have absolutely no idea what to do about threading on
> a
> > per-data-object basis:
> >
> > sub m_add(@a is threaded, @b) {
> > ... What can the compiler figure out about threading @a?
> > }
>
> I'd say this is unlikely to work, but again, I haven't exactly
> thought it all through very thoroughly.
I'm pretty sure it *could* work. Likewise, I'm sure we could live
without this for the first release, if we but grab the namespace we
think we'll need in advance. That's why this stuff should all be hints
to the interpreter -- what the box is actually capable of is not
something we can know.
Certainly it's trivial to "thread" basic vector processing:
1. Get max# of useful threads (#cpu's - 1)?
2. Every computation of a threaded vector member gets allocated to
a new thread, round-robin.
3. Any read of a threaded vector member forces a join on the allocated
thread before proceeding.
This isn't optimal, but it would work. But knowing how much benefit
you're going to see will be part of the equation, too. So you want the
runtime to balance the startup/shutdown cost versus the execution cost,
if possible. Also, you want to favor threading when a blocking
operation might occur in the threadable code. That kind of stuff.
> > This is one of those cases where the really smart guys who used to
> > spend time recoding the fortran compilers for Vaxen might be able
> > clue us in on the "cool tricks for vector processing", but how
> > generalizable will it all be? (And, of course, is the internal
> > representation amenable to this?)
> > None of this addresses the issue of "explicit" threading -- cases
> > where the user wants to create and control her own threads.
>
> Or how they would interact. If you're doing implicit threading in a
> program using explicit threading, things could get REALLY
> tang-toungled....
Implicit threading must be transparent to the coder, or it's not
implicit, icit?
So if I have two explicit threads:
my ViewControlTask = new Task(...);
my ViewControlThread = new Thread(priority => 1,
task => ViewControlTask);
my ComputationTask = new Task(...);
my ComputationThread = new Thread(priority => 19,
task => ComputationTask);
Anything which happens *implicitly* in the ComputationTask must be
invisible to the coder. So the task will automatically be split and
automatically be joined (or not) based on the convenience of the
interpreter -- the only thing I'm doing in code is giving "hints" about
what can/should be split into threads.
So ideally, Parrot notices that I'm doing threads, or maybe that the
interpreter thinks that threads are going to be valuable. So it engages
the "threadomizer" and creates 8 OS level threads, one per CPU. Then
perl queries parrot, gets the number of threads created, and allocates
explicit threads and implicit threads accordingly -- this is what I
don't know how to do.
So there's a mixture:
ViewControlTask -----> -----> -----> --*--> -----> ----*> ----->
+ implicit thread 1 -----> -----/ \-----> --/
ComputationTask -----> -----> -----> -----> -----> * -----> ----->
+ implicit thread 1 -----> -----> -----> ---/
+ implicit thread 2 -----> -----> -----> ---/
+ implicit thread 3 -----> -----> -----> ---/
+ implicit thread 4 -----> -----> -----> ---/
=Austin
