CP013: Create a pseudo list of properties/queries (P1795)

[AerialMantis]

One aspect of the feedback from SG1 on P1795r1 at Belfast was that we need to demonstrate how the abstract topology discovery interface proposed would work in practice, and provide some examples of how properties of the system topology could be used generically within applications.

I think one of the first steps in this is to identify the potential abstract properties or queries that could be expressed generically, i.e. not pertaining to any particular kind of processor or system component.

So far I have the following list:

• Type of resource, i.e. execution, memory, network_io
• Parent-child connections between resources to identify hierarchy relationships.
• Processor-memory connections between resources to identify memory access capabilities.
• Processor-io connections between resources to identify external capabilities such as network ports.
• Available concurrency at a particular point in a hierarchy, i.e. the number of concurrent threads of execution available to that resource.
• Support for SIMD execution and the available SIMD ABIs and widths.
• Hardware concurrency (mapped to the existing function of the same name).
• Hardware constructive interference size (mapped to the existing function of the same name).
• Hardware destructive interference size (mapped to the existing function of the same name).
• Prefered bulk execution shape.
• Maximum bulk execution shape.
• Method of bulk execution work batching.
• Prefered size for bulk execution work batching.
• Relative latency of accessing different memory resources from different execution resources.
• Support for pinned/shared memory between execution resources.
• Support for exceptions.

We don't need to propose all of these properties now, but we can prepare a pseudo list of properties or queries for expositional purposes to demonstrate how algorithms could take advantage of this interface.

[AerialMantis]

Suggest having the abstraction of connections be more generic, i.e. simply having queries for the type of the resource and the resources that it is connected to.

We also want to be able to query the type of a connection between two resources - bandwidth, async DMAs, etc.

We may also want to reflect systems that have more than one connection between two resources.

We could try to write up a pseudo example that implements a matrix multiply algorithm for GPU, single socket CPU and NUMA using properties to differentiate the different architectures.

It would also be useful to be able to detect if a number of resources could be constructed into a single executor, it would be useful to have a notion of resource context compatibility and whether the implementation allows those resources to be composed. We don't want an OpenCL like hierarchy that includes the vendor of a resource, but having a query for the vendor would allow you to fin all devices of a particular vendor.

[AerialMantis]

I've created a PR which updates the proposed direction of the paper to clarify the approach being taken and adds the above pseudo list of properties that we expect to be useful when using topology discovery.

#113

[AerialMantis]

Feedback from SG1 at the Prague meeting:

• We should include audio devices as a type of resource.
• We should consider having properties which reflect the availability of resources (i.e. online or offline, static or dynamic), though this is a more advanced feature that should probably be considered though introduced later.