Affinity: Address #67 & discussion in #70 #74
Conversation
Executors don't have to be about parallel execution. Thus, remove
references to "parallel execution," "parallel launch," and "parallel
region." The phrase "parallel region" is an OpenMP-ism that would need
definition anyway, and is better expressed using phrases like "the code
that would execute on ${HARDWARE}."
| @@ -221,7 +276,7 @@ An `execution_resource` is a lightweight structure which acts as an identifier t | |||
|
|
|||
| ### System topology | |||
|
|
|||
| The system topology is made up of a number of system-level `execution_resource`s, which can be queried through `this_system::get_resources` which returns a `std::vector`. A run-time library may initialize the `execution_resource`s available within the system dynamically. However, this must be done before `main` is called, given that after that point, the system topology may not change. | |||
| The system topology is made up of a number of system-level `execution_resource`s, which can be queried through `this_system::get_resources` which returns a `std::vector`. A run-time library may initialize the `execution_resource`s available within the system dynamically. However, `this_system::get_resources` must be thread safe and must initialize and finalize any third-party or OS state before returning. | |||
There was a problem hiding this comment.
If we don't want iterators to be invalidated, shouldn't this be std::list ?
| @@ -629,16 +684,19 @@ The free function `this_thread::get_resource` is provided for retrieving the `ex | |||
|
|
|||
| *Returns:* The `execution_resource` underlying the current thread of execution. | |||
|
|
|||
| > [*Note:* The `execution_resource` underlying the current thread of execution may not necessarily be reachable from "top-level" resources visible through `this_system`. *--end note*] | |||
There was a problem hiding this comment.
Is not clear to me what is the reason for the note (i have been on holiday so apologies if this has been discussed already)
There was a problem hiding this comment.
One of the things we discussed was whether some resources might not be accessible from the top level -- e.g., some GPU resources (like scratch memory) might only be available during execution on the GPU. One could thus access them through this_thread::get_resource (and possibly in other ways), but not from the top level this_system::get_resource.
This is also one of the reasons for execution_resource not to be reference counted (at least not all execution_resources). Otherwise, it would be bad for them to escape the scope of code executing on the GPU.
I was thinking about this Note last night, and realized that we may need more explanatory text about this. I'd like the PR to go through so it doesn't step on other PRs, but we should definitely write more about this.
|
This looks great, thanks! |
@AerialMantis
Address #67 by applying discussion in #70.
Update some references, including p0443.