Hi Aroon --
From memory (i.e., I may not have this exactly right, but I think it's
close):
The current Chapel implementation makes parallelism illegal within all
iterators other than leader iterators, due to the fact that all other
iterator types are intended to support zippering and we didn't have a
clear vision about how to zipper iterators together that include
parallelism.
It may be that we could relax this constraint by looking at restricted
versions of parallelism, but I don't know that anyone has investigated
this since the original iterator implementation was done. For example:
* if the yield statements did not appear within a parallel task, would
that simplify the zippering?
* if the parallelism were constrained to be guaranteed to terminate before
the iterator completed (e.g., cobegins, coforalls, or begins within sync
statements), would that help?
I think the short answer is that we don't know the answers to these
questions (haven't put the time into it recently and can't recall all of
the original rationale offhand without doing archeology into email and
commit messages).
Another thing that's been in our minds for years, but never implemented,
is a "standalone" parallel iterator that is invoked when applying a forall
to a singleton (with no zippering). It's expected that this iterator
would also support parallel constructs. That said, I'm guessing this
wouldn't help you as the "follower" portion of a standalone iterator would
typically not require communication.
I believe that what you're trying to do (overlap communication with
computation in a follower iterator) is something that we'd also interested
in doing, but have not yet undertaken. To that end, I'd start by thinking
about how you would generate such a parallel follower iterator in a
zippered manner with other iterators. If you have a proposal that bears
weight, the compiler could be changed to implement that (though it may be
that you'd need to make those changes to have it occur in a timely
manner).
Hope this helps,
-Brad
On Fri, 8 Nov 2013, Aroon Sharma wrote:
Hi everyone,
I am trying to do some overlapping/synchronization of communication and
computation from within the follower iterator for arrays in the
CyclicDist module (albeit a version that I've modified). I have three
main "tasks/jobs/pieces of code" that I'd like to overlap/synchronize.
Let's call them get, yield, and put.
Get is responsible for retrieving a buffer of elements from a nonlocal
locale. Yield is yielding each element in the buffer. Put is writing
back these elements to the locale they belong to. These "tasks/jobs" are
running in a serial loop within the follower iterator.
I'd like to overlap these "tasks/jobs" so that the get call for the
second buffer can start while the first buffer is yielding and putting
back. A simplified way to envision this might be:
Get1Yield1Put1
Get2Yield2Put2
Get3Yield3Put3
.
.
.
To do this, I would like to create separate Chapel tasks from within the
follower iterator for get and put using "begin", and provide
synchronization using sync variables to block certain tasks from
executing before others finish. These "tasks/jobs" aren't doing any
yielding so it should be safe to do within the follower iterator.
However, I get the following error when creating new tasks within a
follower iterator:
error: invalid use of parallel construct within serial iterator
Can any of you recommend a way around this so I can accomplish this
overlapping/synchronization? Thanks.
Aroon Sharma
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
