Hi, and sorry about accidentally sending an empty message... > 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.
I'm trying to get chapel to spawn just one task per locale, but haven't had success yet. I tried using --dataParTasksPerLocale=1, however monitoring CPU load showed this didn't work. I also tried setting environment variable CHPL_RT_NUM_THREADS_PER_LOCALE. When that env var was set to 1, the program did hang. When set to 2, it did run, but three of eight logical cores (4 physical, 8 with HT) were loaded. Basically I'd just like to monitor how load is balanced across locales without having access to a cluster. I have chapel compiled with fifo and no hwloc, maybe this is the cause? Compiling chapel with qthreads and hwloc failed, IIRC error was that "no working instance of hwloc found". > 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? I think you mentioned that in this thread. Yes, pretty much that is what I want, except that certain fields should always be stored in place. But my current work-around of wrapping fields inside classes will do for now. I have c/c++ background where it has to be explicitly stated whether something is to be stored as pointer or in place, so I sometimes find it rather confusing that some types are implicitly stored/passed/copied/assigned as references while others are not... > 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. dsiClone is one of methods that isn't documented almost at all in that file. I tried just commenting in out, but apparently it is used in some of the most basic operations (creation, assignment, iteration etc. of domains/arrays). But knowing that I should make a deep copy is enough information for now, I think. In privatization, why are the dsiGetPrivatizeData() methods needed? Since dsiPrivatize(privatizeData) has access to "this", why can't it just get values from that? Also, is there a way to explicitly request a reprivatization? ------------------------------------------------------------------------------ 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
