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
