--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- 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.
Ah. I should have seen that. (BTW, I personally find it slightly
amusing and certainly useful to reformat code to minimize space when
it's a quote of a quote of a quote, but still offer apologies for the
resulting mishmash.)
> > Basically, I just failed to parse all that. Sorry -- internal P6
> > parser still incomplete.
>
> No, just bad writing on my part. Sorry.
I disagree. Once I know what it's doing, it looks fine. :)
> > > 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.
ah -- and if it isn't feasable, the compiler just ignores those hints,
builds it the old-fashioned way, and goes on about it's business. If
the hardware and the OS provide sufficient support, on the other hand,
the compiler might take advantage of them when the code suggests it.
Ok, I could see that.
> 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.
More nightmares for the designers. :)
Maybe that's P8? :)
> > > 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?
lol -- but I don't necessarily *totally* agree. I make explicit use of
implicit behavior a little too much of the time, depending on what you
mean. I think the common term for it is "cryptocontext". :)
Still, your point is valid. "Implicit" threading (or anything else) is
something done quietly, like implicit dereferencing of arrays. I was
just thinking that if the user is using explicit threads, he might do
things that implicitly interfere with or receive interferance from
implicit threads.... but then, I can't exactly come up with an example,
so the point is probably entirely moot.
> 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.
Ok. I still say that should be pragmatic, though.
Easy enough in P6 to C<use implicit 'threads';> and have the language
magically morph to add those hints to the rest of the compilation
process.
BTW, what *is* the applicability of adverbs to C<use> statements?
Is that entirely bogus?
> 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.
Oh, well, I feel better! lol! ;o]
> So there's a mixture:
>
> ViewControlTask -----> -----> -----> --*--> -----> ----*> ----->
> + implicit thread 1 -----> -----/ \-----> --/
>
> ComputationTask -----> -----> -----> -----> -----> * -----> ----->
> + implicit thread 1 -----> -----> -----> ---/
> + implicit thread 2 -----> -----> -----> ---/
> + implicit thread 3 -----> -----> -----> ---/
> + implicit thread 4 -----> -----> -----> ---/
>
> =Austin
I'll bite.
But I still wonder if we're pipe dreaming?
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
