> First about the Block.myChunk. Apparently the only place where this
> variable is needed apart from some printing functions is in
> Block.getChunk. The thing that caught my attention was following comment
> at that function in cyclic distribution:
>
> WANT:
> var distWhole = locDist(locid).myChunk.getIndices();
> return inds((...distWhole));
>
> However, as far as I can see the approach used in BlockDist is
> essentially same as the above. So, what are the limitations of the above
> way? The reason I'd like to know the limitations is because I haven't
> decided yet how generic distribution I'm trying to write. If I end up
> writing a distribution that could support arbitrary distributions of
> rectangular, densely indexed domains then the above limitation will be
> relevant. However, in more limited version where each locale is assigned
> one rectangular block I think that won't be a problem...
IIRC, I think the issue was that using this approach in Cyclic was likely
to ("more likely to than Block"? perhaps even "certain to"?) result in
integer overflow. The commit message for that commented out block of code
seems to suggest that I'm remembering correctly. That said, we've also
been throttling back our expectations as a project of what we expect to be
safe for maximal ranges or those that creep up on the minimal/maximal int
values (like the one mentioned in the commit message), so there's a chance
it may be less of an issue now than it was (?).
I was going to mention this yesterday, but didn't: IIRC, the Block
distribution stores each local block's portion of the index space not as a
subset of the boundingBox argument, but rather as a portion of the
(min(idxType)..max(idxType))**rank space. E.g., if I'm the initial
locale, I logically own {min(idxType)..n/2, min(idxType)..n/2} as my
portion of the 2D plane (given a bounding box of {1..n, 1..n}, and I
believe we store this domain for the purposes of simple intersection.
That said, there's no requirement for doing this, and for some time now I
think there's been an intention to store the local block as {1..n/2,
1..n/2} and then change the getChunk logic to deal with indices < (1,1)
more manually rather than relying on slicing. The motivation for this was
again to avoid the risks of doing math that might result in overflow out
at the extremes of the idxType's representation. As far as I can
remember, we've never implemented (and I'm too much of a rush to check
right now).
One more note is that the Cyclic distribution is not nearly as utilized as
Block (and therefore neither as commplete or performant).
> Then, about the targetLocales array. What's the rationale of having it
> have the same rank as the distribution? While I can see the sense in
> case of the block dist, I'm not sure how good the idea would be in my
> case. Is there any reason why the targetLocales array (and locDist and
> targetLocDom) couldn't always have a rank of 1 or an arbitrary rank
> decided by the policy object?
No, there's no requirement (that I can recall anyway) in the domain map
framework for the targetLocales array to have the same rank as the logical
domain being distributed. I think we just do this by convention for the
current domain maps for the reason you give -- it makes sense for
Block/Cyclic. And if it turns out that we do have a requirement like this
today, I think we'd want to relax it. Specifically, we want the ability
to do a recursive bisection style distribution that would want to store
its locales using a tree structure rather than a dense grid (though the
user probably would pass in a 1D collection of locales rather than the
tree structure itself).
-Brad
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
