Open AerialMantis opened 6 years ago
Need to be able to query the context for a (single) resource object. Leading to having a resource object that is a specified subset of another resource. Leading to a constructor or member function that takes a selection-specification (e.g., array of ints) and gives back a resource handle. Leads to multiple resource objects referencing the same resource, which is OK because ownership is not implied. I'd go with constructor taking an existing resource and a selection-spec.
That's a good point, if we allow constructing an execution_context
from a set of execution_resource
s that could complicate the mapping of execution_context
s to execution_resource
s.
If I understand correctly you're proposing that the execution_context
be constructed with an execution_resource
and some form of array of indices, which specifies which member resources the context will manage? Something like:
execution_context partitionedContext(execRes, {0, 1, 2, 3});
We could make the default set be all member resources.
This would mean that you couldn't have an execution_context
with execution_resource
s at different levels, though perhaps this is a reasonable restriction.
Seems like a reasonable restriction to me. My concern is that we cannot assume all implementations of execution resource / context would allow for this fine-grained selection of resources.
Yes, I think this would have to be an optional feature as not all resources will be able to support this. The way I'd imagine this working is that an execution_resource
would have a certain level of concurrency, but also have a certain level of partition-ability, being essentially the number of member resources which can be iterated over. So, for example, you could have a CPU core resource which has 8 concurrency and 8 partition-ability so you would be able to partition each of the resources individually, and then you could have a GPU work group resource which has 64 concurrency but 0 partition-ability, so you can execute work on it but not partition it further.
It was raised that the current design limits the creation of an
execution_context
to a singleexecution_resource
therefore enforcing that theexecution_context
represent all memberexecution_resource
s. This excludes the case where you may want to, for example, create anexecution_context
from half the threads of a core. In this case, you would want to list theexecution_resource
s you want theexecution_context
to represent.For this we need to add an additional constructor to the
execution_context
or alter the existing constructor to allow it to take a set ofexecution_resource
s. Perhaps we could do this by providing partitioning algorithms which can partition anexecution_resource
in a particular way and return a new iterable which could then be passed to theexecution_context
constructor.