CP013: Thoughts about equality of execution resources

[AerialMantis]

trafficstars

Folowing on from our discussion regarding the lifetime of execution resources I have recently been thinking about how we should define equality of execution resources.

It would be very useful for users to be able to compare one execution resource against another, to check if they are pointing to the same underlying resource. However, this begs another quetion of whether execution resources should be required to be consistent identifiers.

For example, if you were to discover the system topology multiple times, should the same hardware resources always be represented by comparible execution resources? Or if you were to construct a particular type of execution context that does not require that it is constructed from an execution resource, but can return an execution resource, should it possible to compare this resource against the equivelant from a system topology discovery?

[mhoemmen]

I would very much like execution resources to be consistent. That would imply some kind of tracking of IDs, so they don't get reused in the case of devices whose availability changes over time. However, what does this mean in the case of a virtual machine that gets suspended and resumed on a different physical computer, possibly with a different architecture? What does "same resource" mean?

[AerialMantis]

I agree, I think usability would be greatly improved if we can guarantee that execution resources are consistent identifiers. Though this would have to imply some kind of global state, initialised on the first topology discovery so that any subsequent discoveries would yield the same identifiers (i.e. identifiers that would be equality comparable).

I think this would also solve the problem of what happens to an earlier topology query when a new one is performed if we guarantee each query would return the same identifiers.

In the case of a virtual machine, I think we should guarantee that the execution resource will always point the same underlying resource whether that be hardware or software (perhaps that could be some which is query-able, whether an executionr esource is hardware or software managed?). So this means that from a C++ perspective, the execution resources would still be comparable.

auto rootRes1 = std::this_system::discover_topology();
auto rootRes2 = std::this_system::discover_topology();

/* Requiring consistent identifiers would mean that this would result in true */
assert(rootRes1[0] == rootRes2[0])

auto rootRes = std::this_system::discover_topology();

auto context = vendor::some_execution_context();

/* Requiring consistent identifiers wouldalso mean that this would result in true in the case that the execution context uses the same execution resource */
assert(context.resource() == rootRes[0])

For the second case above, I think we would have to word the requirements for the execution resource context concept such that it is required to construct it's execution resource (i.e. what it returns from resource()) via this_system::discover_topology().

[mhoemmen]

perhaps that could be some which is query-able, whether an execution resource is hardware or software managed?

I'm not sure if a user-space C++ program can tell the difference. However, it would be a bit silly for a completely software-based virtual machine, with no connection to hardware parallelism, to present itself as having multiple NUMA affinity regions. Thus, perhaps it doesn't matter whether the execution resource is actual hardware; what matters is that the system doesn't lie in ways that will likely reduce performance and complicate users' code.