You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To mitigate this, this, we introduced a relatively fine grained `Extract*` API for interacting with the context. We can use the trait annotations produced by this system to infer which parts of the context are used on which graph evaluation paths during graph compile time.
20
+
To mitigate this, we introduced a relatively fine grained `Extract*` API for interacting with the context. We can use the trait annotations produced by this system to infer which parts of the context are used on which graph evaluation paths during graph compile time.
@@ -43,14 +42,13 @@ The input to all of nodes is of type `Context` which in of itself is just define
43
42
```rust
44
43
pubtypeContext=Option<Arc<OwnedContextImpl>>;
45
44
```
46
-
We use this unified dynamic context type because this means we only have to compile one version of a node and all nodes are compatible with each other but this is not a formal limitation (and should never be considered to be a given).
47
45
46
+
We use this unified dynamic context type because this means we only have to compile one version of a node and all nodes are compatible with each other but this is not a formal limitation (and should never be considered to be a given).
48
47
The different parts of the context (e.g. `Footprint`, `index`, ...) are called *features*.
49
-
50
-
It thus makes sense that we have to check the equality of `Context` objects to test if we can reuse a cached value or not. If as in the example above a node only relys on one part of the `Context` we don't really care if some other part has changed and the contexts can be considered equal for use in **this node**.
51
-
Cache nodes compare the equality of inputs based on the hash code. To stay compatible with the existing api, we can "zero out" parts of the `OwnedContextImpl` by setting unused variants to `None`. This is done by a context modification node which is placed into the graph by the compiler.
52
-
48
+
It thus makes sense that we have to check the equality of `Context` objects to test if we can reuse a cached value or not. If as in the example above a node only relies on one part of the `Context` we don't really care if some other part has changed and the contexts can be considered equal for use in **this node**.
49
+
Cache nodes compare the equality of inputs based on the hash code. To stay compatible with the existing API, we can "zero out" parts of the `OwnedContextImpl` by setting unused variants to `None`. This is done by a context modification node which is placed into the graph by the compiler.
53
50
The `ExtractAll` trait can be used to create a new Context based on the previous one which can be utilized by nodes which need to modify the context for their child nodes but don't depend on the data themselves.
The different `Extract*` traits are exported by the node macro and could thus be included as part of the document node definition to inform the compiler about features extracted in every node. Note that the `ExtractAll` will be ignored in this analysis. Any usages of partial context data are propagated downstream and all node are identified in which the number of extracted features changes between the upstream and downstream. At these locations a context modification needs to be inserted which "zeros" the data no longer used in the upstream part of the graph.
63
-
Note that the number of features extracted can usually only increase except for cases where a node decides to inject data into the the call chain.
60
+
The different `Extract*` traits are exported by the node macro and could thus be included as part of the document node definition to inform the compiler about features extracted in every node. Note that the `ExtractAll` will be ignored in this analysis. Any usages of partial context data are propagated downstream and all nodes are identified in which the number of extracted features changes between the upstream and downstream. At these locations a context modification needs to be inserted which "zeros" the data no longer used in the upstream part of the graph.
61
+
Note that the number of features extracted can usually only increase except for cases where a node decides to inject data into the call chain.
64
62
This will be the case when building lambda expressions, the node driving the lambda evaluation (e.g. a map or a fold node) would insert data such as the index into the call chain.
65
63
We might consider adding a special `Inject*` annotation in the future to indicate that the downstream of this node does not need to provide the feature even though the upstream does need it.
66
-
67
-
his can be implemented as a compiler pass similar to the compose node insertion.
68
-
64
+
This can be implemented as a compiler pass similar to the compose node insertion.
69
65
70
66
# Drawbacks
71
67
[drawbacks]: #drawbacks
72
68
73
-
Having an extra compiler pass will impact the performance sligtly although the impact is expected to be small because we already have a backlink structure and a topological sort of proto nodes which we can repurpose.
69
+
Having an extra compiler pass will impact the performance slightly although the impact is expected to be small because we already have a backlink structure and a topological sort of proto nodes which we can repurpose.
Moving this fine grained cache invalidation to a compiler pass allows us to implement this with a minimal impact on the graph runtime. Other options would consist of tracking the usage of features at graph runtime inducing overheads.
79
-
This is expected to have the biggest impact on real time application such as animation or when working with non-footprint aware nodes which would also benefit from this optimization.
80
-
81
-
# Prior art
82
-
[prior-art]: #prior-art
83
-
84
-
Discuss prior art, both the good and the bad, in relation to this proposal.
85
-
A few examples of what this can include are:
86
-
87
-
- For language, library, cargo, tools, and compiler proposals: Does this feature exist in other programming languages and what experience have their community had?
88
-
- For community proposals: Is this done by some other community and what were their experiences with it?
89
-
- For other teams: What lessons can we learn from what other communities have done here?
90
-
- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
91
-
92
-
This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your RFC with a fuller picture.
93
-
If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages.
94
-
95
-
Note that while precedent set by other languages is some motivation, it does not on its own motivate an RFC.
96
-
Please also take into consideration that rust sometimes intentionally diverges from common language features.
75
+
This is expected to have the biggest impact on real time applications such as animation or when working with non-footprint aware nodes which would also benefit from this optimization.
0 commit comments