Hi, thanks for you explanation about those caches, that is definitely enough information for now.
I tried creating a base policy class and deriving from it, but ran into problems with generics stuff. Namely, in my base class I have: param rank: int; type idxType; When trying to derive a class myPolicy from it I get error: unresolved type specifier 'myPolicy(rank=1, idxType=type int(64))' Trying to provide any user specifiec constructors just gets me different error messages... The more I think this the more I'd like to take the base class approach, so that default methods would be provided but they could be overridden if user so wants... Or does chapel have a way to check(at compile time) if a class has a method with given name? John 27.01.2015, 02:54, "Brad Chamberlain" <[email protected]>: >>>> Also would you mind giving a (very) brief explanation about the caching >>>> system used? Or point me to a relevant paper. >> I meant the one that's present in BlockDist.chpl file, called RAD cache. >> Or are there more than one in there...? Especially information related >> to stencils and ghost cells would be appreciated. > > There currently isn't support in BlockDist itself for stencil-style > caching at present. There's a start at how this might be added in > [test/release/]examples/benchmarks/miniMD/helpers/StencilDist.chpl, which > is itself a clone of BlockDist, extended to support halos/ghost cells > ("fluff"). The main downside of using StencilDist at present is that the > user is responsible for explicitly requesting the updates to the caches > (rather than having the compiler automatically insert those calls in order > to support the "plug-and-play" vision of domain maps with no code > changes). The miniMD code in that directory (and its parent) are the best > illustrations of this feature at present. > > The RAD cache is a different type of cache. It's designed to cache the > meta-data in the array class itself ("the dope vector" essentially) which > will permit one locale to index into another's memory in a single message. > I.e., if you own index (i,j) of a distributed array, I can either: > > (a) remotely access all the meta-data from your descriptor that I need to > do the indexing calculation to determine the element's address myself > (requires lots of gets); > > (b) ship you (i,j), have you do all the indexing and return a reference > to the array element (requires an active message); > > (c) cache all the meta-data from your descriptor such that, once I have > it, I can do the indexing locally (requires gets but only to populate > the cache; after that, remote accesses should be free). > > My high-level understanding of what's required to enable this optimization > for a given distribution is to identify which parts of the array > descriptor need to be cached to do this type of remote access. For the > changes to Block that we've discussed, I would guess no changes would be > required. (I also typically suggest that people not worry about this > optimization until they get things up and running). > > The best description of this that I'm aware of is in the commit messages > that added the capability. For example: > > https://github.com/bradcray/chapel/commit/633353f > https://github.com/bradcray/chapel/commit/fa9b841 > > though there may be other documentation. I can ask around if desired and > nobody else speaks up on this thread. > > -Brad ------------------------------------------------------------------------------ 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
