Enhancement: fully anonymous barrier

[Former user]

Originally reported on Google Code with ID 76 ``` The value passed to upc_{notify,wait,barrier} is optional. However, unless the compiler can PROVE that a given instance can only match other calls with the same argument (or same LACK of argument), the fully general matching logic is required.

This "issue" is to request the addition, to the core UPC spec, of a fully anonymous variant of the barrier which is NOT permitted to match the existing upc_{notify,wait,barrier}, and which is able to operate with the full efficiency offered by barrier acceleration hardware now present in many high-end systems.

As a "lark" I suggest the following syntax: upc_barrier void;

In all seriousness, I propose: upc_anon_notify; upc_anon_wait; upc_anon_barrier; which are to be statements (just as the existing barrier-related ones). ```

Reported by `[e-mail]` on 2012-07-18 02:10:38

[Former user]

``` Counter-proposal: Another approach to the same issue is to leave the specification unchanged but encourage the implementation to provide an implementation-specific "don't check barriers" switch (probably at compile time), whereby the users asserts that all barriers "match" and globally disables the barrier checking logic (ie for production runs on fully debugged code).

This would achieve the performance goal by "bending" the rule about interrupting program execution upon mismatch, since the user has asserted no mismatches are present. If the assertion is wrong, he won't get the expected error message, but the implementation can call that "undefined". ```

Reported by `danbonachea` on 2012-08-03 13:34:47

[Former user]

``` Dan wrote:

Counter-proposal: Another approach to the same issue is to leave the specification

unchanged but

encourage the implementation to provide an implementation-specific "don't check barriers"

switch

(probably at compile time), whereby the users asserts that all barriers "match" and

globally disables

the barrier checking logic (ie for production runs on fully debugged code).

One possible argument against this counter-proposal is that it would be all-or-nothing (at least on the granularity of a compilation unit). Meanwhile, the "anon" could be applied on a per-call basis if desired.

Personally, I think there would be no harm in having both, but if we choose only one then Dan's suggestion of a "remove-the-training-wheels" switch (compile or runtime) is probably the better option. ```

Reported by `[e-mail]` on 2012-08-03 18:00:49

[Former user]

``` This is included the UPC collectives 2.0 (issue 42). Do we really need a separate incompatible proposal? ```

Reported by `[e-mail]` on 2012-08-03 18:39:55

[Former user]

``` Steven wrote:

This is included the UPC collectives 2.0 (issue 42). Do we really need a separate

incompatible proposal?

Sorry, I was unaware of (or had forgotten) the overlap/conflict with the Collectives 2.0 proposal.

As to the "do we need": I suspect that the UPC Collectives 2.0 proposal will take a significant amount of revision and discussion before it can be acceptable to the community. So, there may be a benefit to separating the issue of a fully-anonymous barrier to see it included in the spec earlier. However, if others don't agree I am willing to withdraw this proposal. ```

Reported by `[e-mail]` on 2012-08-03 19:39:14

[Former user]

``` I don't see any problem with trying to get something in earlier than the collectives 2.0 stuff, which as you said, will likely take a while to sort out. If we do go that route though, I'd like to avoid ending up with 3 separate incompatible barriers. It'd be nice to define things in such a way that we (implementers) can put something along the lines of

extern upccoll_handle_t _upc_anon_handle;

1. define upc_anon_notify upccoll_barrier( UPC_TEAM_ALL, &_upc_anon_handle )
2. define upc_anon_wait upccoll_wait( _upc_anon_handle )
3. define upc_anon_barrier upccoll_barrier( UPC_TEAM_ALL, NULL )

in a header somewhere when the collectives 2.0 are finalized, and not have to maintain 3 different barriers with slightly different semantics. ```

Reported by `[e-mail]` on 2012-08-03 21:40:49

[Former user]

``` We seem to be leaning towards resolving this issue by merely suggesting that implementers with hardware barrier support provide their users with an implementation-specific "remove-the-training-wheels" switch (compile or runtime) which tweak the guarantees of the existing upc_barrier construct, so no new upc_anon calls or spec changes are required.

When team barriers arrive there will be a second barrier construct (at least as the programmer sees it), but this is probably unavoidable without breaking backwards compatibility in a very fundamental way. ```

Reported by `danbonachea` on 2012-08-04 00:31:35

[Former user]

``` I don't like the introduction of new keywords (upc_anon_barrier) and think that the re-introduction of the term "anonymous" with a different meaning could be confusing to both users and implementers.

I think providing a vendor-specific configuration or runtime option that says "remove the training wheels" is OK, but will tend to be either under-utilized (as in "present" but "never used") or over-utilized (as in "always" - which side-steps valuable checks during the development phase.

I prefer re-defining anonymous barriers so that they only match anonymous barriers and thus barriers with id's match only barriers with id's. This of course is not backwards compatible which would make that proposal a candidate for spec. 1.4 and beyond. I realize that such an incompatible definition would face an uphill battle, but nevertheless I think that this would simplify both the definition and use of barriers and the implementation. This new definition of anonymous barrier behavior would still allow vendors to add specific optimizations that remove checks -- though perhaps the UPC specification would need to be tweaked so that the programs which fail the checks are programs exhibiting undefined behavior, rather than being erroneous? This would allow a debugging version of the runtime to issue errors/warnings about mis-matched id's, but would not require the checks in the production version of the library.

```

Reported by `gary.funck` on 2012-08-13 15:47:36

[Former user]

``` Set default Consensus to "Low". ```

Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

[Former user]

``` I support Gary's idea to modify the spec so that anonymous barriers cannot match named barriers.

Pairing an anonymous barrier with a named barrier is more likely a programming mistake rather than a useful intent.

upc_barrier; <-> upc_barrier 1; Is this really useful?

```

Reported by `[e-mail]` on 2012-08-27 20:47:48

[Former user]

``` Yili wrote:

I support Gary's idea to modify the spec so that anonymous barriers cannot match named barriers.

I think that is a possible approach for 2.0, but would break existing codes.

Pairing an anonymous barrier with a named barrier is more likely a programming mistake rather than a useful intent.

upc_barrier; <-> upc_barrier 1; Is this really useful?

Sure it is. Imagine some sort of application which has broken the computation into two classes and assigned a subset of the threads to each class (trivial case would be one master and THREADS=1 workers, but odd/even and others are possible). Since we don't yet have teams, any barrier that exists in the code must be entered by all of the threads. Yet the two classes are doing DIFFERENT work. So, it seems possible in this scenario that all "Class A" threads might issue a "upc_barrier 1" knowing that they are at some "stage 1". Meanwhile, the user's code is smart enough to have "Class B" threads enter the barrier at the right time, but not quite smart enough to know what "stage" the A's are at, and therefore they issue the anonymous "upc_barrier;". ```

Reported by `[e-mail]` on 2012-08-27 21:01:51

[Former user]

``` I agree with Paul that matching anonymous and named barriers can be a useful programming practice, which is why the 1.2 spec explicitly allows it. Changing this would break backward compatibility and is arguably not an improvement.

The original proposal was motivated entirely by performance, namely the desire to use anonymous hardware barrier support, and had nothing to do with debugging or usability. My proposal in comment #1 (implementation-specific "remove-the-training-wheels" switch) resolves the performance issue with no spec changes, and is forward-compatible with team barriers.

The only criticism I've heard for that proposal was from Gary: "I think providing a vendor-specific configuration or runtime option that says "remove the training wheels" is OK, but will tend to be either under-utilized (as in "present" but "never used") or over-utilized (as in "always" - which side-steps valuable checks during the development phase."

In response, my recommendation would be for platforms with hardware barrier support to auto-enable "remove the training wheels" when the user compiles with optimizations (-O), which they presumably already disable for debugging and enable for production. Of course implementations would be free to have a separate option, or only enable it for certain optimization levels, as appropriate for the implementation. Vendors worried about compliance could instead opt to issue a warning at program startup for the case: (optimization_enabled && hardware_barrier_supported && !remove_training_wheels) advising the user to compile with -Oremove_training_wheels for optimal barrier performance. I think this would alleviate Gary's concern of under-utilization.

This proposed resolution requires no spec changes, and could even be taken "right away" by 1.2 compilers. We already have such an option on at least one platform in BUPC.

```

Reported by `danbonachea` on 2012-08-28 20:25:16 - Labels added: Consensus-Medium - Labels removed: Consensus-Low

[Former user]

``` To clarify, the "remove the training wheels" switch I'm proposing that implementers provide should probably be an application-wide switch (ie environment variable or linker switch) rather than a per-module switch. The latter would cause problems if barriers were matched across modules which disagreed on whether barrier value checking should happen. A global, application-wide switch asserts that barrier values should be ignored for the entire application run, which corresponds to the user asserting his entire program is free of barrier-matching bugs and ready for production performance. ```

Reported by `danbonachea` on 2012-08-28 20:45:33

[Former user]

``` Mass change "Accepted" issues which haven't seen activity for over a month back to "New", for telecon discussion. ```

Reported by `danbonachea` on 2012-10-04 11:36:12 - Status changed: `New`

[Former user]

``` On the 10/5 telecon it was agreed this issue is resolved with NoChange.

Notes to the effect of comment #1 should be added to the advice to implementers document. ```

Reported by `danbonachea` on 2012-10-07 06:25:02

[Former user]

Reported by `danbonachea` on 2012-10-07 06:38:38 - Status changed: `NoChange`