|
template<typename KeyT, IsKeyList InputsT, typename FunctionT>
requires std::constructible_from<std::decay_t<FunctionT>, FunctionT> |
| auto | make_computation (FunctionT &&function) |
| | Attach an output key and ordered input keys to a lambda, function, or other callable.
|
| |
template<typename KeyT, IsKeyList InputsT, typename FunctionT>
requires std::constructible_from<std::decay_t<FunctionT>, FunctionT> |
| auto | make_owning_computation (FunctionT &&function) |
| | Supply immutable shared handles to computed prerequisites so results can retain them without copying.
|
| |
template<typename ErrorT = std::string, IsComputationGraph GraphT, IsDependencyContext ContextT, typename ObserversT = Observers<>>
requires CanPrepare<GraphT, ContextT, ErrorT> && ObserversFor<ObserversT, GraphT, ContextT> && std::constructible_from<std::remove_cvref_t<GraphT>, GraphT> && std::constructible_from<std::remove_cvref_t<ObserversT>, ObserversT> |
| auto | make_computation_cache (GraphT &&graph, const ContextT &, ObserversT &&observers=ObserversT{}) |
| | Fix the graph's source types without retaining the supplied context or evaluating any computations.
|
| |
template<typename ErrorT = std::string, IsDependencyContext ContextT, typename... Computations>
requires CompatibleComputations<Computations...> && (std::constructible_from<std::remove_cvref_t<Computations>, Computations> && ...) && CanPrepare<ComputationGraph<std::remove_cvref_t<Computations>...>, ContextT, ErrorT> |
| auto | make_computation_cache (const ContextT &context, Computations &&... computations) |
| | Build a checked graph and an empty cache directly from named computations.
|
| |
template<typename... Computations>
requires CompatibleComputations<Computations...> && (std::constructible_from<std::remove_cvref_t<Computations>, Computations> && ...) |
| auto | make_computation_graph (Computations &&... computations) |
| | Reject duplicate producers and cyclic computational graphs at the declaration site.
|
| |
template<typename... Resources>
requires (IsResource<Resources> && ...) && misc::traits::all_unique_types_v<typename std::remove_cvref_t<Resources>::Key...> |
| auto | make_dependency_context (Resources &&... resources) |
| | Build a context whose schema follows directly from its resource keys and types.
|
| |
template<IsDependencyContext... Contexts>
requires (detail::combinable_resources(misc::concepts::ConcatT<typename Contexts::Resources...>{})) |
| auto | combine_dependency_contexts (const Contexts &... contexts) |
| | Copy disjoint resources and their tracking policies into one context; borrowed objects retain their original lifetime.
|
| |
template<typename KeyT, typename KeysT>
requires ContainsKey<KeyT, KeysT> |
| consteval std::size_t | key_index () |
| | Locate a declared key in its ordered list; absent keys are rejected at compile time.
|
| |
template<typename KeyT, typename BeforeT, typename AfterT>
requires NodeObserverCallbacks<std::decay_t<BeforeT>, std::decay_t<AfterT>> && std::constructible_from<std::decay_t<BeforeT>, BeforeT> && std::constructible_from<std::decay_t<AfterT>, AfterT> |
| auto | observe_node (BeforeT &&before, AfterT &&after) |
| | Bind before/after callbacks to a result key; callback captures determine any external storage lifetime.
|
| |
template<typename BeforeT, typename AfterT>
requires std::constructible_from<std::decay_t<BeforeT>, BeforeT> && std::constructible_from<std::decay_t<AfterT>, AfterT> |
| auto | observe_nodes (BeforeT &&before, AfterT &&after) |
| | Observe all executed nodes; cache construction checks the callback contract for every result key.
|
| |
template<typename InputT, typename ConsumerT, typename FunctionT>
requires std::constructible_from<std::decay_t<FunctionT>, FunctionT> |
| auto | observe_edge (FunctionT &&function) |
| | Bind a read-only callback to one input of one consumer; graph construction validates the edge and value type.
|
| |
template<typename... Registrations>
requires (detail::is_observer_v<std::remove_cvref_t<Registrations>> && ...) && (std::constructible_from<std::remove_cvref_t<Registrations>, Registrations> && ...) |
| auto | make_observers (Registrations &&... observers) |
| | Collect any number of registrations, including several observers of the same node or edge.
|
| |
| template<typename KeyT, typename ValueT, typename PolicyT = ValueSnapshot> |
| auto | own (ValueT &&value, PolicyT policy={}) |
| | Store a value in the context; rvalues transfer ownership and lvalues are copied.
|
| |
| template<typename KeyT, typename ValueT, typename PolicyT = ValueSnapshot> |
| auto | borrow (ValueT &value, PolicyT policy={}) |
| | Bind an existing object whose lifetime must cover every use of the context.
|
| |
| template<typename KeyT, typename ValueT, typename PolicyT = ValueSnapshot> |
| auto | borrow (const ValueT &&, PolicyT={})=delete |
| | Borrowed storage must never refer to a temporary, including a const temporary.
|
| |
| template<typename FunctionT> |
| auto | track_by (FunctionT &&function) |
| | Select the state that determines whether a source needs recomputation.
|
| |
template<typename PolicyT, typename ValueT>
requires SnapshotPolicyFor<PolicyT, ValueT> |
| const void * | source_identity (const PolicyT &policy, const ValueT &value) |
| | Views may identify their underlying resource; ordinary sources retain object identity.
|
| |
| template<NodeTimingClock Clock = SteadyNodeClock> |
| auto | time_graph_nodes (GraphTiming &timing, Clock clock={}) |
| | Opt into node timings; a custom clock supports deterministic accounting tests without sleeps.
|
| |
Computational Graphs
Demonstration code for how to use the SERiF computational graph system The broad idea here is that there are many calculations which depend on each other but which may not necessarily always need to be recomputed just because another part of the model has changed. We model this as a combination of an acyclic computational graph, defined at compile time, and a runtime cache of values. The general workflow is that a developer defines the "context" of the computational graph, think of this as all of the inputs to the graph, or maybe more specifically, anything that could change due to some external event (e.g. a time step, a newton step, etc...) This context is probably the most CS intensive part of this code as the developer needs to think about lifetimes and ownership.
Context Contexts are made with the make_dependency_context function, this accepts a variadic pack of bindings between a type and a runtime value. You can generate these yourself using the binding functions and types; however, we provide two convenience wrappers which generally developers should consider using.
- borrow: Used to bind a type to a reference to a value. This is useful for values which are owned by the caller and which the caller will manage the lifetime of (takes an lvalue).
- own: Used to bind a type to a value which is owned by the context (copies an lvalue or moves an rvalue) Each of these functions accepts a type as a template parameter and a runtime value as an argument. The type is used as an ID, this is key to understand, if we write
double x{1.0};
auto make_dependency_context(Resources &&... resources)
Build a context whose schema follows directly from its resource keys and types.
Definition dependency_context.hpp:101
auto borrow(ValueT &value, PolicyT policy={})
Bind an existing object whose lifetime must cover every use of the context.
Definition resource.hpp:68
we are not saying that x is of type keys::Input, this is clearly not the case. Rather, we are registering in the computational graph a binding between the type keys::Input and the runtime value x. Think of this as naming the various inputs to the graph.
Computations After defining a context we can define a computation, each computation defines a node, while its ordered input keys define the incoming edges. Consider the following example (assuming the context from above):
[](const double _x) -> double {
return _x * _x;
}
);
auto make_computation(FunctionT &&function)
Attach an output key and ordered input keys to a lambda, function, or other callable.
Definition computation.hpp:44
what we have defined here is a node which takes a single input tagged keys::Input and produces an output tagged as keys::Output. The input key declares an edge from that source to this node. Other nodes can use keys::Output as an input, and a successfully prepared result can be read with get or retained with share. These connections allow us to form a larger graph. Consider now the following code
struct tags {
struct X{};
struct Y{};
struct Output1{};
struct Output2{};
};
double x{1.0};
double y{2.0};
[](const double _x) -> double {
return _x * _x;
}
);
[](const double _x, const double _y) -> double {
return _x + _y;
}
);
we have now defined two computations, the first takes a single input, whichever input is tagged as tags::X and produces an output tagged as tags::Output1. The second computation takes two inputs, the first is the output of the first computation (lookup by the tag) and the second is whichever input is tagged as tags::Y, and produces an output tagged as tags::Output2. Note that the order of arguments to the lambda must be the same as the order of the tags in the InputList, the dependencies module will automatically order arguments based on the InputList. There is type checking to ensure that the types match, but if you have two inputs of the same type that are flipped there is no way for the system to inspect that and warn you. Further, depending on your compiler and flags there may be implicit casting between convertable types (e.g. int <-> double).
- Todo
- We may want to remove the ability to have implicit casting between types, this is a bit of a footgun and may lead to subtle bugs.
- Note
- This is primary goal of this system, split computations into small pieces with the ability to cache intermediate results and reuse as many of those intermediate results as we can can prove is safe to do. The whole reason this system is so complex is that very purpose. There is a fundamental problem with high dimensional stellar models, they are always going to be slow, therefore we need to accept some degree of complexity in order to make them tractable.
Computation Cache Once we have the computations we need to connect them together, generally use the helper function make_computation_cache which takes a context and a variadic pack of computations. There are a lot of compile time checks which run to ensure that the graph is valid, the context describes what is needed to compute the graph, and that each computation is valid. Generally if a static analysis error or compile error pops up here it probably means there is a mistake in the definition of the context or the computations. I've tried to make these errors as clear as possible; however, there is only so much that you can do with the C++ compiler. I recommend first checking, probably with a drawn-out diagram, that all the tags are correct and what you expect.
A developer can also choose to use the make_computation_graph function to explicitly name a graph. This is useful when naming or reusing a collection of computations (make_computation_cache calls make_computation_graph and then fixes the source types from the supplied context without retaining the context). Now consider the following code assuming the context and computations from above:
auto make_computation_cache(GraphT &&graph, const ContextT &, ObserversT &&observers=ObserversT{})
Fix the graph's source types without retaining the supplied context or evaluating any computations.
Definition computation_cache.hpp:318
At this point we have a cache which we can access various parts of; however, no computations have been run yet. To run a computation we must call try_prepare.
try_prepare returns std::expected: ordinary rejection is a value, and no candidate results or snapshots are published on failure. Exceptions from a callable or snapshot policy propagate with the same cache protection. Previously retained results remain valid, but get and share require a successful current preparation. Always check the report before reading results.
try_prepare takes the context and evaluates the requested nodes and their prerequisites, reusing unchanged results. By default every result is requested, so the first call evaluates the entire graph. RequestedResults can restrict evaluation to a branch.
auto report = graph_cache.try_prepare(context);
if (!report) {
return;
}
double func1_result = graph_cache.template get<tags::Output1>();
double func2_result = graph_cache.template get<tags::Output2>();
auto func1_status = report->template status<tags::Output1>();
auto func2_status = report->template status<tags::Output2>();
std::println("Func1 Result: {}, Func2 Result: {}, Func1 Status: {}, Func2 Status: {}", func1_result, func2_result, func1_status_string, func2_status_string);
std::unordered_map< PreparationStatus, std::string_view > preparation_status_name_map
Definition preparation.hpp:23
Now what we could do is change only one part of the input context and call try_prepare again. Lets say we change only y, such that only func2 is stale.
y = 3.0;
report = graph_cache.try_prepare(context);
if (!report) {
return;
}
double func1_result = graph_cache.template get<tags::Output1>();
double func2_result = graph_cache.template get<tags::Output2>();
auto func1_status = report->template status<tags::Output1>();
auto func2_status = report->template status<tags::Output2>();
std::println("Func1 Result: {}, Func2 Result: {}, Func1 Status: {}, Func2 Status: {}", func1_result, func2_result, func1_status_string, func2_status_string);
1.13.2