---
title: P1348 Discussion
description: Issues and discussion pulled from the P1348 working paper during its creation in order to preserve a record of the discussions that took place.
---

P1348 Discussion and Issue Tracking
===================================

Allowing shape type to be not `size_t`?
---------------------------------------

> [name=H. Lee Howes] Don't we want the shape type as the return value rather than size_t?
> [name=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.)
> [name=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>`.
> [name=H. Lee Howes] Even if it is fixed it seems cleaner to make it dependent to make the reason for the fixed type clear.
> [name=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"
-----------------------------------------

> [name=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.
> [name=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?).
> [name=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.
> [name=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.
> [name=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.
> [name=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.
> [name=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.
> [name=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.
> [name=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.
> [name=David Hollman] @Michael :+1:
> [name=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?
> [name=Michael Garland] That seems like an argument for focusing on "hardware" contexts or "physical" contexts or something of that nature.
> [name=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...
> [name=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
--------------

> [name=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.
> [name=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`"?
> [name=Michael Garland] Are we focusing specifically on the needs of parallel algorithms with this, or also trying to address some need of concurrent algorithms?
> [name=David Hollman] I was focusing on the needs of the parallel algorithms specifically. Concurrent algorithms have to many other concerns.
> [name=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.
> [name=David Hollman] @Michael, does the updated line 37 and the added line 53 address this concern?
> [name=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._
> [name=David Hollman] :+1:, maybe s/specify/express/?
> [name=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"
------------------------------------

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

---

> [name=carter edwards] ... maximum number of execution agents that can occupy available execution contexts
> [name=David Hollman] s/available/associated/?

What is still missing from this paper?
--------------------------------------
> [name=David Hollman] [time=Wed, 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?
> [name=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.
> [name=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
------------------------------------
> [name=Jared Hoberock] Is this paragraph necessary?
> [name=David Hollman] No, I think we can cut it.

Wording Discussion
------------------
> [name=Jared Hoberock] "An optional query-only property" is redundant with the definition of `maximum_occupancy_shape_t` above. I think we can strike it.
> [name=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.
> [name=David Hollman] Is the optional part also redundant?
> [name=Jared Hoberock] Yes, the optional part is redundant. All properties are optional.
> [name=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?
> [name=David Hollman] Should we also say that the return must be nonzero?
> [name=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
-------------------

> [name=Jared Hoberock] I think a shorter title like "An Executor Property for Occupancy of Execution Agents" might seem less defensive :-)
> [name=David Hollman] :+1: 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?
--------------------------------------------

> [name=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.
> [name=David Hollman] I'll ask Olivier what he prefers in this respect. It seems procedural.
> [name=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)

> [name=David Hollman] **The paper has been attached to the wiki**