Hi,
> In the current copy of master, forall loops get translated into either:
>
> a) standalone parallel iterators (a new feature in 1.11), or
> b) leader-follower iterators
>
> Case (a) is used when a standalone parallel iterator is available and the
> forall loop is not a zippered iteration. Case (b) is used for zippered
> forall loops, or in the case that a standalone parallel iterator is not
> available. We're currently in the process of implementing standalone
> iterators for most of our domain maps (that's how new they are).
>
> In either case, for typical loop structures, you should think of the
> result of the forall as being rewritten into something like:
>
> coforall loc in targetLocales { // create per-locale task
> on loc do { // move task to locale
> coforall tid in ... { // create local tasks
> for i in ... { // do task-local work
> ...body of forall loop...
> }
> }
> }
> }
>
> where the coforalls and ons are typically in the leader/standalone
> iterator, the inner for is in the follower/standalone iterator, and the
> body is the body.
>
> The semantics of a coforall guarantees that the task which entered it
> won't complete until all of their iterations have completed, thus, it's
> correct that the leader/standalone iterator will not return until after
> all the loop bodies are executed (and this property is required in order
> to implement forall semantics properly).
Thanks for explanation. Related to this, what kind of system is used to
determine how many tasks are created per locale in forall loops?
>> In one of the previous post Brad described a cut distribution that
>> existed in ZPL. Do you know of any papers about that, or papers about
>> any other efficient ways of writing efficient, variable sized
>> distributions? My implementation isn't quite as efficient as I'd like,
>> though I'll see what kind of improvement some caching will bring...
>
> I don't know that there was anything particularly efficient about the cut
> distribution in ZPL that you're missing here. Chapel, in its current
> form, is known to result in suboptimal performance in many cases,
> particularly distributed memory runs (see $CHPL_HOME/PERFORMANCE). For
> what you're undertaking, I think the big question would be whether your
> distribution is significantly underperfoming Block when you use it to
> distribute things evenly. If so, that suggests that there's more that
> could be done to optimize it; if not, it suggests you're running into the
> Chapel status quo.
That's exactly what I tried to do, to compare my distribution with block dist.
I had time to implement some caching and privatization and they are making much
bigger difference than I had thought. Time required to set things up is much
longer, but in actual computations there seems to be now just a slight overhead
compared to the block dist, but memory usage is larger. I have a bit problems
testing things comprehensively, though, since I don't have access to a computer
cluster at the moment..
I wasn't very clear about what I meant by my question about references to
arrays. The problem is that, when making a privatized copy of policy object,
I'd like to be able to control which fields are copied to each locale and which
refer to the original object. I got around this problem by wrapping fields
(mostly arrays) that I don't want to be copied on privatization into a nested
class. This really isn't an optimal solution, because changing whether a field
should be copied by value or reference on privatization requires a lot of
changes in the code.
In methods where a distribution is assigned, copied, or new instance is created
(ie. Block.dsiClone, Block.dsiClone, Block.dsiCreateReindexDist...) would you
consider it more appropriate to create a new copy of the policy object or keep
a reference to the original one?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
