maybe this? replicated var arr: [1..10] int;
that sounds like an interesting project / feature. would definitely simplify my work. On Thu, Jun 4, 2015 at 9:49 AM, Brad Chamberlain <[email protected]> wrote: > > We've definitely kicked around the notion of a replicated-per-locale > concept/sugar over the more explicit ReplicatedDist approach, but nobody's > run with that to any real extent. > > There is a developer-oriented pragma: > > pragma "locale private" > > (it was simply pragma "private" in 1.11) that has the effect of giving you > a copy of a variable per locale, but I don't know how robust it is and it > wasn't necessarily intended as an end-user capability (i.e., we'd rather > promote syntax for this if we promote it to the language/end-user). > > I don't think 'local' is the right keyword for this because it doesn't > suggest any notion of replication or per-locale nature. I'd also be > inclined to put any modifier before 'var' since it is arguably saying > something about the symbol as a whole rather than part of its type. > > -Brad > > > > > On Thu, 4 Jun 2015, Brian Guarraci wrote: > > A local data centric view would likely side step most, if not all of, the >> issues I've run into so far. And would certainly move the complexity to >> the compiler by definition. >> >> I wonder what the implications would be for ReplicatedDist type scenarios? >> I seem to spend a lot of time managing local access to objects / data >> hanging off a replicated domain. I often feel like there should be a more >> explicit mechanism, e.g.: >> >> var arr: local [1..10] int; >> >> >> would create a replicated copy of arr that was only accessible locally on >> each locale. >> >> >> >> >> >> On Thu, Jun 4, 2015 at 9:16 AM, Brad Chamberlain <[email protected]> wrote: >> >> >>> The local block has a number of challenges to its specification and use >>> that have caused us to explore data-centric means of getting the same >>> benefits without throwing such a big hammer. Ben's prototypical local >>> class pragma support that went into 1.11 is one example of this; the >>> notion of getting a "local array slice" that only supports access to >>> local >>> elements is a second. In my mind, one of the goals we're working toward >>> (ideally by 1.12, but it may take longer) is to deprecate the local block >>> altogether. This is part of the reason that (I believe) it's never made >>> it into the language spec. It's been viewed as more of a stopgap than a >>> desireable feature for a long time. >>> >>> I don't have as many thoughts about the serial block, in part because I >>> don't feel like it sees much use in practice. It could, arguably, make >>> sense to make it completely local to a given parallel construct or to >>> make >>> it lexically scoped. >>> >>> -Brad >>> >>> >>> On Thu, 4 Jun 2015, Michael Ferguson wrote: >>> >>> Hi Chapel Developers - >>>> >>>> It came up recently that local { } does not compose well >>>> with library code. By that, I mean that the library code >>>> won't necessarily function when it's in a local block. If >>>> the library code needs to communicate - it will fail if >>>> it's called from within a the local block, but the error >>>> message doesn't necessarily lead directly to the problem. >>>> >>>> I believe that the same problem also exists for serial >>>> blocks, but for a different reason. There, the library >>>> code might need to actually create multiple tasks in >>>> order for its algorithm to work. When it tries to synchronize >>>> those tasks, it will probably deadlock if they are not >>>> actually tasks but instead run serially. >>>> >>>> I have some questions about this dilemma. >>>> >>>> 1) Is there already a planned strategy for solving this >>>> problem, possibly by replacing local { } and serial { } >>>> with something else? >>>> 2) If we want to keep local { } and serial { } as >>>> performance optimizations, could we provide a way for >>>> library code to assert that it needs communication or >>>> task parallelism? Something like: >>>> >>>> proc libraryFnThatCommunicates() { >>>> assertNotInLocalBlock(); >>>> ... >>>> } >>>> >>>> and >>>> >>>> proc libraryFnThatSynchronizesSpawnedTasks() { >>>> assertNotInSerialBlock(); >>>> ... >>>> } >>>> >>>> >>>> 3) Another idea would be to only allow local/serial blocks >>>> to call functions that are marked in some way that >>>> they are compatible with local/serial blocks... >>>> but I think I prefer the assert method. >>>> >>>> 4) A completely different strategy would be to make >>>> better stack traces for failed tasks, including >>>> tracing through 'on' statements. >>>> >>>> Interested in your thoughts, >>>> >>>> -michael >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>>> _______________________________________________ >>>> Chapel-developers mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/chapel-developers >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Chapel-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/chapel-developers >>> >>> >>
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
