Hi, and thanks for you reply. Again I've got a few more questions... What would be the preferred way to define the aforementioned policy object? I was thinking of creating a base class and having the user derive policies from it. However, did I miss something, or can't methods be defined abstract? Also there is nothing similar to Java's interfaces in chapel, right?
Another question is, what is the current status of support for sparse domains? Ie. should I require each locale to have a continuous, rectangular block of data or not? John 23.01.2015, 20:54, "Brad Chamberlain" <[email protected]>: >> 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
