block size of [*] should be capped at UPC_MAX_BLOCK_SIZE

[Former user]

Originally reported on Google Code with ID 31 ``` This addresses issue #2 on the UPC Language Specification list.

Currently footnote #7 (at the bottom of page #14) attached to the description of UPC_MAX_BLOCK_SIZE in 6.3.3 of the spec says:

7 e.g. shared [UPC MAX BLOCK SIZE+1] char x[UPC MAX BLOCK SIZE+1] and shared [*] char x[(UPC MAX BLOCK SIZE+1)*THREADS] are translation errors.

So, to me there appears to ALREADY be a limitation of the block size computed by '[*]' to be no larger then UPC_MAX_BLOCK_SIZE. The case of automatic block size is given as much attention as the explicit block size case (there is no constraint language in 6.5.1.1 to limit either).

I motion to dismiss as "WontFix" (or equivalent) unless I have totally missed to point of this "issue".

```

Reported by `[e-mail]` on 2012-05-22 01:41:06

[Former user]

``` Item 7 states:

7. value of [*] should be limited to max. block size.

The spec states at 6.5.1.1.14:

If the layout qualifier is of the form ‘[ * ]’, the shared object is distributed as if it had a block size of ( sizeof(a) / upc_elemsizeof(a) + THREADS - 1 ) / THREADS, where ‘a’ is the array being distributed.

The intent of the proposal is that the above calculation would be changed to read: MAX ((sizeof(a) / upc_elemsizeof(a) + THREADS - 1) / THREADS, UPC_MAX_BLOCK_SIZE), thus ensuring that the resulting calculated block size is within range.

If I were to rewrite the footnote example as follows, for example:

shared [*] char x[10*1024*THREADS];

and UPC_MAX_BLOCK_SIZE was hypothetically 1024, the proposal is that the declaration above would be equivalent to:

shared [1024] char x[10*1024*THREADS];

The problem with imposing the restriction stated in the footnote is that it is difficult for the programmer to apriori know the value of UPC_MAX_BLOCK_SIZE and it seems counter to the idea behind the use case of '[*]' -- that it adapts to the size of the array.

Note: there has been some discussion of deprecating '[*]', but there is no open issue documenting that proposal.

```

Reported by `gary.funck` on 2012-05-22 17:20:09

[Former user]

``` Gary wrote:

The intent of the proposal is that the above calculation would be changed to read: MAX ((sizeof(a) / upc_elemsizeof(a) + THREADS - 1) / THREADS, UPC_MAX_BLOCK_SIZE), thus ensuring that the resulting calculated block size is within range.

Sorry, I missed the point of the proposal entirely. My understanding of "limited" was that exceeding the value would be an error. I am rewording the Summary to hopefully make this clearer.

I am of the understanding that '[*]' is short-hand for "one (nearly) uniform block per thread". I believe that is the meaning most users will assign to it as well.

The introduction of MAX(foo, UPC_MAX_BLOCK_SIZE) would break the guarantee provided by the current definition that each thread has affinity to a *single* block with *contiguous* indices. It would also break any arithmetic that a user might be performing to compute the first local index for any given thread.

What I expect to see happen is that code that today won't compile (due to exceeding UPC_MAX_BLOCK_SIZE in the [*] computation) will instead compile and SILENTLY give wrong results because the user's code expected a single block per thread when performing some pointer-privatization optimization.

Additionally, the current specification for '[*]' yields as-equal-as-possible number of elements per thread. Introducing the ceiling would also move the layout farther from that expectation of near-uniform distribution (by adding a "granularity" of UPC_MAX_BLOCK_SIZE, which we assume to be large).

I am against this proposal as Gary has described it. If there were an alternative notation to request this new layout, then I might be able to get behind it. ```

Reported by `[e-mail]` on 2012-05-22 17:35:32

[Former user]

```

Re: deprecation of the '[*]' layout qualifier, I added a new item in the list of open issues and created issue #38 to track the issue.

```

Reported by `gary.funck` on 2012-05-22 21:31:08

[Former user]

``` As owner of this issue, and based on the comments so far, I propose we take NO ACTION with respect to UPC 1.3. Any changes, depreciation, or removal of '[*]' have a potentially significant impact on existing UPC code and this should be deferred to UPC 2.0. ```

Reported by `[e-mail]` on 2012-05-31 18:20:29

[Former user]

Reported by `[e-mail]` on 2012-06-01 03:19:45 - Labels added: Spec-2.0

[Former user]

Reported by `[e-mail]` on 2012-06-01 06:09:50 - Labels added: Milestone-Spec-2.0 - Labels removed: Spec-2.0

[Former user]

``` I concur with Paul in opposition to this proposal. The suggested "automatic capping" violates the spirit of what layout the user expects when he says [*], which could lead to subtle errors that only manifest at scale.

It seems far more intuitive to generate an error, and let the user insert the appropriate MAX(..., UPC_MAX_BLOCK_SIZE) expression if that's what he really wants.

Move to close with wontfix. ```

Reported by `danbonachea` on 2012-06-15 15:11:11

[Former user]

``` Something that may alleviate potential surprises is the acceptance of issue #21, which proposes the definition of suggested implementation limits. In this way, test programs, for example can at least test values of [*] up to the implementation-defined limit, and thus will be unlikely to break (due differing minimums) when moved from one test platform to another.

```

Reported by `gary.funck` on 2012-06-15 16:55:23

[Former user]

``` I am in agreement, based on the discussion above, that this proposal should be marked as "no change", and will update the status accordingly.

However, I will point out that documenting restrictions and/or constraints only in a footnote or an example makes it more difficult for both users and implementers to accurately and quickly understood the various required language semantic constraints. I could file another issue ticket on that topic, but for now there are more pressing issues.

Paul, since you're the owner of this issue - please re-open and/or change the status as you decide is appropriate, if you're not in agreement with this change in status.

```

Reported by `gary.funck` on 2012-07-02 16:00:54 - Status changed: `NoChange` - Labels added: Milestone-Spec-1.3 - Labels removed: Milestone-Spec-2.0

[Former user]

``` Unless others wish to lobby for moving the clarifying footnote into the body text, I am in agreement with Gary's "NoChange". ```

Reported by `[e-mail]` on 2012-07-02 17:18:20