P1348 Discussion and Issue Tracking

Allowing shape type to be not size_t?

H. Lee Howes Don't we want the shape type as the return value rather than size_t?
David Hollman The shape_t of the polymorphic executor is size_t, and we didn't introduce anything that resembles a polymorphic wrapper for a more general shape type (I think actually executor_shape_t is even required to be size_t for now, even in the non-polymorphic case.)
Jared Hoberock Yes, I think that's correct that executor_shape_t<polymorphic-executor> is size_t, so it would make sense to make the polymorphic_query_result_t be either size_t or just executor_shape_t<polymorphic-executor>.
H. Lee Howes Even if it is fixed it seems cleaner to make it dependent to make the reason for the fixed type clear.
David Hollman The problem is that execution::executor<> is a template, it's not clear that executor_shape_t<executor<>> means much, and executor_shape_t<executor<maximum_occupancy_shape_t>> seems a bit circular (and not all that helpful)

"Resident" vs. "Simultaneously unblocked"

H. Carter Edwards Maybe use the phrase "simultaneously unblocked" somewhere? "Resident" is not a term in the draft IS. The term "Active" is used: "active handler" and "active execution". "Block" is defined in 3.6 as "wait for some condition (other than for the implementation to execute the execution steps of the thread of execution) to be satisfied before continuing execution past the blocking operation". Perhaps keep it simple as "simultaneously executing execution agents" or "concurrently executing execution agents". The term "concurrently executing threads" is used in 6.8.2.2.
Christian Trott How about scheduled or active? Does the current P0443 allow suspension of execution agents (i.e. the equivalent of suspending a CUDA block, to get another one swapped in?).
Lee Howes I don't think it precludes swapping out - but at the same time this query is to give an estimate, and it could be estimating the number without any swapping out. So simultaneously scheduled might be viable wording.
Christian Trott The main use case for Sandia is unique resource aquisition (i.e. stuff akin to pre allocate a buffer per active execution agent) where at a minimum I need to know how much I need to pre-allocate. After that I could use a lock/unlock mechanism. If stuff gets swapped out though, this won't work. I still could use this estimate to implement a persistent kernel thingy though, by (as you guys indicated above) only asking for as many execution agents as can run simultanteously and then schedule work myself.
Jared Hoberock My preference would be to tie the normative description of this property to execution agent lifetime, which we were careful to define in the introductory material of P0443. We may as well use that definition.
Carter Edwards Concern with "lifetime" is that a blocked or context-switched execution agent is considered "alive" and we don't want to include such agents in the count. More strongly leaning to "concurrently executing execution agents" because it (1) must be alive and (2) must be executing which (should) mean not-blocked and not-context-switched.
Jared Hoberock I don't think we can use the word "concurrently" at all if we want this property to apply to weaker agents, which we do.
David Hollman @Christian, what do you mean by lock/unlock mechanism? I don't think anything passed to bulk_execute can do things like acquire a lock, since they're not guaranteed to be concurrent. The intention is that you would ask for this number and call bulk_execute yourself with that number, doing the chunking manually.
Michael Garland I tend to prefer the characterization focused on "active" or "hardware" contexts. This keeps the description close in spirit to std::thread::hardware_concurrency, which is the analogous precedent for something like this in the existing IS.
David Hollman @Michael

Image Not Showing Possible Reasons

• The image file may be corrupted
• The server hosting the image is unavailable
• The image path is incorrect
• The image format is not supported

Learn More →

Carter Edwards Bulk execution doesn't prohibit the execution agent and invoked function object from being context switched or blocking. Let "Active" == "actively executing" == not blocked and not context switched? Or "Active" == active execution == actively consuming/occupying/… a hardware execution context?
Michael Garland That seems like an argument for focusing on "hardware" contexts or "physical" contexts or something of that nature.
Carter Edwards Vocabulary "occupy" is used for objects occupying storage/memory. Perhaps carry that term over to execution: an active execution agent occupies a hardware context, or an execution agent that is actively occupying a hardware context. So the term for the property is maximum_occupancy_shape_t maximum_occupancy(); So NVIDIA picked the best words years ago…
Lee Howes This is not a concurrency guarantee. It is perfectly fine to launch based on this number and then be context switched out. I don't think we should have any wording that implies anything stronger than that. All this is is a capacity clue - some value that could in principle execute at once, utilising the full set of hardware resources and maximising performance, or as close a guess to that as is reasonable.

Who is Driving

Michael Garland The draft says "should be passed to bulk_execute in order to drive the number of tiles". This seems like an incorrect characterization. It is the algorithm calling bulk_execute that is picking the number of tiles, not bulk_execute itself. And thus the algorithm that needs to tell bulk_execute how many tiles it wants to create.
David Hollman Yes, we need a better way to say something about the tiling. I agree that what we're querying is a value used to derive the tiling approach, not the tiling itself. How about something like "in order to, for instance, allow the algorithm to tile the work in a function passed to bulk_execute"?
Michael Garland Are we focusing specifically on the needs of parallel algorithms with this, or also trying to address some need of concurrent algorithms?
David Hollman I was focusing on the needs of the parallel algorithms specifically. Concurrent algorithms have to many other concerns.
Michael Garland Then I think it is reasonable to motivate this in the following way: We know that a general need of parallel algorithms is to decompose their work into tiles/blocks/pieces/whatever and that the choice of the number of tiles is a potentially important performance concern. This number provides guidance to the parallel algorithm calling bulk_execute to make an informed choice of what number of tiles they might want to use.
David Hollman @Michael, does the updated line 37 and the added line 53 address this concern?
Michael Garland I suggest something like this instead for line 37:

The intention is that the result of querying this property should be used to drive the decomposition of work into parts and passed to bulk_execute to specify the number of parallel agents needed.
David Hollman

Image Not Showing Possible Reasons

• The image file may be corrupted
• The server hosting the image is unavailable
• The image path is incorrect
• The image format is not supported

Learn More →

, maybe s/specify/express/?
Michael Garland Either is fine, although I think "specify" is reasonable, because you're telling bulk_execute precisely how many agents it will create. It has no discretion to launch any other number.

"Occupancy" instead of "coresidency"

Carter Edwards Vocabulary "occupancy" of execution agents with respect to execution context, mirrors vocabulary used for objects occupying storage.
David Hollman Is this w.r.t. the title? Does that change make more sense?
carter edwards "occupancy" instead of "coresidency" to leverage existing vocabulary, :-) circling all the way back to the beginning of discussion about "filling execution contexts"

carter edwards … maximum number of execution agents that can occupy available execution contexts
David Hollman s/available/associated/?

What is still missing from this paper?

David HollmanWed, Nov 7, 2018 3:34 PM I want to keep the paper short if possible, and I think it's pretty close to done. How close are we to a point where we want to stamp out a revision and upload it to the wiki?
Jared Hoberock (copied from comments) I think the paper could probably be shortened further. I'll add some inline notes, feel free to take them or ignore.
David Hollman (copied from comments) Sounds good. Didn't realize the comment feature (here) was separate from the inline comment feature…

Cutting the original first paragraph

Jared Hoberock Is this paragraph necessary?
David Hollman No, I think we can cut it.

Wording Discussion

Jared Hoberock "An optional query-only property" is redundant with the definition of maximum_occupancy_shape_t above. I think we can strike it.
Jared Hoberock Likewise, I think the final sentence of the above paragraph is redundant with other wording about how property queries are supposed to work.
David Hollman Is the optional part also redundant?
Jared Hoberock Yes, the optional part is redundant. All properties are optional.
David Hollman The last sentence is intended to address the difference from std::thread::hardware_concurrency(), which returns 0 when this happens. Maybe this should just be part of the note?
David Hollman Should we also say that the return must be nonzero?
Jared Hoberock I think saying the result is nonzero is useful. For the last sentence, my thinking was that if an executor can't provide an estimate, then it's obvious that they would not provide this query, and therefore can_query_v will be false.

Discussion of Title

Jared Hoberock I think a shorter title like "An Executor Property for Occupancy of Execution Agents" might seem less defensive :-)
David Hollman

Image Not Showing Possible Reasons

• The image file may be corrupted
• The server hosting the image is unavailable
• The image path is incorrect
• The image format is not supported

Learn More →

Agreed, and done. Any other thoughts by other authors? (For posterity, the old title was: "An Almost Trivial (But Vital) Extension to P0443 Providing a Property for Occupancy of Execution Agents")

Should this be phrased as a diff to P0443r9?

Jared Hoberock It might be most useful to present the proposed wording as a diff to P0443R9. Since this proposal is purely additive, that would mean indicating where in the <execution> synopsis it could go, and underneath which section the wording would be introduced.
David Hollman I'll ask Olivier what he prefers in this respect. It seems procedural.
David Hollman Olivier suggested we make it its own thing. It can still be part of r10 of executors (which will need to exist for wording purposes at the very least)

Done

(for now)

David Hollman The paper has been attached to the wiki