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
