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
We currently have large and similar match op.kind expressions in implementations of eg Session::execute and SymbolicStrategy::execute, all of which could be replaced by various impl DispatchKernel<S> for Operator potentially generated by operators! or enum_dispatch.
One complication is that some operators are special in the sense that they take advantage of being in an async context, including SaveOp and LoadOp. This is not something we can currently capture in the framework, but there are at least two solutions:
Don't use the framework for these special ops but instead implement DispatchKernels manually; disadvantage here is that we need to be careful to ensure consistency across the different sessions types, which is otherwise taken care of by the framework. Note also that some of the special operators will share the same logic in higher levels, say SaveOp on replicated placements.
Extend the framework to handle these special cases so that a pair of kernel functions (Self::sync_kernel_func, Self::async_kernel_func) can be given instead of currently only accepting a single one.
There may of course be other solutions and we should benefit from exploring this further before moving on to implementation.
The text was updated successfully, but these errors were encountered:
We currently have large and similar
match op.kind
expressions in implementations of egSession::execute
andSymbolicStrategy::execute
, all of which could be replaced by variousimpl DispatchKernel<S> for Operator
potentially generated byoperators!
orenum_dispatch
.One complication is that some operators are special in the sense that they take advantage of being in an
async
context, includingSaveOp
andLoadOp
. This is not something we can currently capture in the framework, but there are at least two solutions:DispatchKernel
s manually; disadvantage here is that we need to be careful to ensure consistency across the different sessions types, which is otherwise taken care of by the framework. Note also that some of the special operators will share the same logic in higher levels, saySaveOp
on replicated placements.(Self::sync_kernel_func, Self::async_kernel_func)
can be given instead of currently only accepting a single one.There may of course be other solutions and we should benefit from exploring this further before moving on to implementation.
The text was updated successfully, but these errors were encountered: