Hi, > The number of tasks used to implement a forall loop is equal to the number > of tasks created by its leader or standalone iterator. For most of our > standard/built-in types (ranges, domains, arrays, Block, etc.) this tends > to be established by a global config named 'dataParTasksPerLocale' which > itself defaults to 'here.maxTaskPar' which is the amount of concurrency > that the tasking layer says it can support (which in turn tends to be the > number of processor cores on the locale) by default. >> 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. > I can't remember whether it was on this thread or another that I mentioned > an intention to support 'ref' members of classes/records as part of > upcoming work. Is the thing you wanted the ability to have a class that > is generic w.r.t. whether its fields are stored in place or by reference? >> 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? > I think the purpose of these is to do a deep copy rather than sharing. > Block.dsiClone() I suspect is rarely used in practice, as it would relate > to creating and copying variables of the domain map type, where most > current uses don't do a lot of first-class manipluation of index sets. > Block.dsiCreateReindexDist() is also used rarely, and we've recently been > discussing different approaches to handling reindexing because the current > interface causes challenges, both in implementation and optimization. > > There's a textfile: > > doc/[release/]technotes/README.dsi > > that describes the dsi interface, and may serve as a good reference, > though I haven't had the chance to spend much time with it myself. > > -Brad
06.02.2015, 23:42, "Brad Chamberlain" <[email protected]>: >> Thanks for explanation. Related to this, what kind of system is used to >> determine how many tasks are created per locale in forall loops? > > The number of tasks used to implement a forall loop is equal to the number > of tasks created by its leader or standalone iterator. For most of our > standard/built-in types (ranges, domains, arrays, Block, etc.) this tends > to be established by a global config named 'dataParTasksPerLocale' which > itself defaults to 'here.maxTaskPar' which is the amount of concurrency > that the tasking layer says it can support (which in turn tends to be the > number of processor cores on the locale) by default. >> 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. > > I can't remember whether it was on this thread or another that I mentioned > an intention to support 'ref' members of classes/records as part of > upcoming work. Is the thing you wanted the ability to have a class that > is generic w.r.t. whether its fields are stored in place or by reference? >> 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? > > I think the purpose of these is to do a deep copy rather than sharing. > Block.dsiClone() I suspect is rarely used in practice, as it would relate > to creating and copying variables of the domain map type, where most > current uses don't do a lot of first-class manipluation of index sets. > Block.dsiCreateReindexDist() is also used rarely, and we've recently been > discussing different approaches to handling reindexing because the current > interface causes challenges, both in implementation and optimization. > > There's a textfile: > > doc/[release/]technotes/README.dsi > > that describes the dsi interface, and may serve as a good reference, > though I haven't had the chance to spend much time with it myself. > > -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
