Update proposed direction of P1795.

* Update the proposed direction to be more specific regarding the approach.
* Introduce a pseudo list of executor properties that are expected to be useful to applications utilizing topology discovery.

Author: AerialMantis

affinity/cpp-23/d1795r2.md

@@ -1,6 +1,6 @@
-# P1795r1: System topology discovery for heterogeneous & distributed computing
+# P1795r2: System topology discovery for heterogeneous & distributed computing
 
-**Date: 2019-11-23**
+**Date: 2020-01-10**
 
 **Audience: SG1, SG14**
 
@@ -18,6 +18,9 @@ This paper is the result of discussions from many contributors within SG1, SG14
 
 ### P1437r2 (PRA 2020)
 
+* Update the proposed direction to be more specific regarding the approach.
+* Introduce a pseudo list of executor properties that are expected to be useful to applications utilizing topology discovery.
+
 ### P1437r1 (BEL 2019)
 
 * Introduce terms of art for *system topology*, *system resource* and *topology traversal policy*.
@@ -110,29 +113,59 @@ Another example of this is that while Hwloc is highly used in many domains, it n
 
 # 5. Proposed direction
 
+## Overview
+
 This paper aims to build on the unified executors proposal, detailed in P0443 [[14]][p0443r11], so this proposal and any others that stem from it will target P0443 as a baseline, and aim to integrate with its direction as closely as possible.
 
-Below we outline a proposed direction:
+This paper proposes an interface which provides abstract representation of a system's resources and their connections and various properties, capabilities and limitations. This abstract representation will allow a diverse range of architectures both available now and to come in the future to be represented in C++ but without tying down the C++ abstract machine specific hardware definitions such as CPU, GPU, etc.
+
+The abstract representation will be an opaque representation of execution, memory, network and I/O resources and their connections to each other which can be traversed in a number of different ways using topology traversal policies, such as a containment hierarchy view, a memory-centric view or a network-centric view.
+
+The idea is that the C++ standard remains abstract and generic with simply a few standard topology traversal policies, while domains can create topology traversal policies which provide ways of discovering resources unique to their domain. For example a GPU vendor such as NVidia may want to define a policy which recognizes their GPUs or a mobile or embedded platform vendor such as ARM may want to define a policy which recognizes unique SoC architectures such as ARM bit little.
+
+This proposal will also propose a mechanism, likely extending the properties mechanism of the unified executors proposal, for querying properties, capabilities and limitations of the various resources within a system topology and their connections with each other.
+
+Finally this proposal will also propose an interface for creating creating executors and allocators or memory resources from a collection of resources discovered within the system topology.
+
+## Designed by example
 
-* Propose an abstract definition of an execution resource, as a hardware or software abstraction capable of creating execution agents.
+The ultimate goal for this proposal is to allow algorithm implementors the ability to author algorithms that are portable across a wide range of architectures and systems, without them having to know the architecture it's running on at all, and being able to operate solely in terms of an abstract system topology representation and it's properties.
 
-* Propose an abstract definition of an execution resource topology, as a non-hierarchical, non-acyclic graph of execution resources with various different kinds of connections.
+Therefore this proposal will take the approach of designing the interfaces described above using examples to test the suitability of the approach.
 
-* Propose an interface for inspecting a system's execution resource topology from various different perspectives, including, but not limited to:
-  * A depth-based view of the system as a containment hierarchy.
-  * A memory-centric view of which execution resources may access which memory regions, and the properties of that access.
-  * A network-centric view of how the execution resources and memory regions are connected.
+### Properties
 
-* Propose an interface for querying properties of an execution resource, reflecting the observable behaviors, capabilities and limitations of the architecture the execution resource represents.
+The first step in this is to identify the kinds of properties that various different kinds of systems and architectures would require in order to identify the kind of architecture of the system and optimise the algorithm for it. To this end this proposal proposes a pseudo list of properties that are expected to be or would like to be proposed in some form.
 
-* Propose an interface for querying the relative affinity properties between different execution resources and memory regions within a system's execution resource topology.
+For each resource within the system topology it would be beneficial to query:
+* Resource type, such as execution resource, memory resource, I/O resource, network resource, etc.
+* Connections it has with other resources (including multiple connections to the same resource).
+* Available concurrency.
+* Ability to be partitioned into other resources, and the possible levels of granularity of the partitioning.
+* Support for SIMD execution and the available SIMD ABIs and widths.
+* Hardware concurrency (mapped to the existing C++ function fo the same name).
+* Hardware constructive interference size (mapped to the existing C++ function fo the same name).
+* Hardware destructive interference size (mapped to the existing C++ function fo the same name).
+* Preferred bulk execution shape.
+* Maximum bulk execution shape.
+* Available memory.
+* Preferred memory allocation multiples.
+* Available affinity patterns.
+* Available work subdivision patterns.
+* Support for exceptions.
 
-* Propose an interface for binding execution agents and initialization of data to specific execution resources.
+For connections between resources within the system topology it would beneficial to query:
+* The type of connection, such as PCIe, DMA, etc.
+* Whether the connection can be used to access data.
+* The difference in depth, to represent hierarchical topologies.
+* The latency of the connection.
+* The bandwidth of the connection.
 
-As a result of the above this paper may also:
+For groups of resources within the system topology it would beneficial to query:
+* Support for pinned or shared memory.
+* Ability to composed a shared executor.
 
-* Propose a lifetime model for execution agents.
-* Propose some additions to the C\+\+ machine model to facilitate describing these additional properties.
+> [*Note:* This proposal is not proposing these properties, it is simply identifying a list of queries that would be useful in some form. *--end note*]
 
 # 6. Proposal