-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CP013: Differences in Affinity and Context papers #40
Comments
|
@hcedwar wrote:
Creating and managing simple data structures of execution resources seems like a thing people might like to do. For example, I might like to build a "distributed" data structure, keyed on the NUMA domain equivalent of "MPI process rank." I need some way to know what resources I'm using for different parts of the data structure. |
@hcedwar wrote:
I would prefer an array / span / range of resources, for the following reasons:
|
I'm trying to imagine what it would be like for new C++ programmers in 2020 who start using executors. Could we just add a static |
@hcedwar wrote:
To me, the main point of |
@hcedwar wrote:
|
@mhoemmen wrote:
For this use case do you think it would be nessesary for the @mhoemmen wrote:
I agree, by having the @mhoemmen wrote:
The way I see the @mhoemmen wrote:
In the current revision we have a @mhoemmen wrote:
That's right, atm, @mhoemmen wrote:
We had a discussion in a separate issue about what we want @mhoemmen wrote:
Yes that's right, you could potentially create any number of |
On yesterday's heterogeneous C++ telecom we decided:
In relation to the other points that were not discussed:
|
Differences in the intersection of papers Affinity - D0796r2 and Context - P0737r0.
std::thread
specific resource: Affinity definesexecution_resource
which is implied to be an execution resource that executesstd::thread
. Context definesthread_execution_resource_t
which is explicit about executingstd::thread
. Question: Should we lay the foundation for non-std::thread
execution resources (e.g, GPU) by embedding the name thread in the initially proposed execution resource?Affinity
execution_resource
is moveable and copyable, Contextthread_execution_resource_t
is neither moveable or copyable. Question: Should an execution resource be a PIMPL (pointer to implementation) value type or an immutable reference? Creating and managing vectors of execution resources requires PIMPL .Affinity has
std::vector<resource> execution_resource::resources() const noexcept;
and Context hasconst thread_execution_resource_t & thread_execution_resource_t::partition( size_t i ) const noexcept ;
. Related to the PIMPL question.Affinity has
std::vector<execution_resource> this_system::resources() noexcept;
and Context hasthread_execution_resource_t program_thread_execution_resource ;
. Question: Should there be a root execution resource that is a handle to the union of all individual execution resources? A root execution resource, by definition, has a vector of nested resources which is equivalent to the Affinity proposal's root vector of resources.Affinity
execution_context
hasname()
. Is this for the type of resource, denote the topological identity of the resource, or both? Context avoided the design point, for the initial proposal.Affinity
can_place_*
methods open the design point of placement without addressing how to query if placement has occurred or how placement can be performed. Context avoided the design point in the initial proposal.Affinity
execution_context
is constructed from anexecution_resource
without additional properties, implying 1-to-1 correspondence. Context execution context (concept) construction is undefined.The text was updated successfully, but these errors were encountered: