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
{{ message }}
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.
Currently MXNet relies on topological ordering of the graph when communicating between frontend languages and backend. This makes it hard to apply fusions in the graph, as they could change the topological order of graph inputs and so break passing of the inputs from frontend.
This could be solved by either moving to passing dictionaries (name, value) from frontend to the engine (which requires changing of C API) or making mappings inside Executor and CachedOp from the original topological ordering to the new one.
The text was updated successfully, but these errors were encountered:
I think this makes sense to me, since the original topological ordering didn't assume mutations like subgraphing and fusion. Related issue: #14727 . I think this may require changes to user facing APIs in symbol, module and gluon since at many places ordering of arg_arrays, grad_arrays and aux_arrays depend on the list_arguments and list_inputs which depend on the topo ordering.
Currently MXNet relies on topological ordering of the graph when communicating between frontend languages and backend. This makes it hard to apply fusions in the graph, as they could change the topological order of graph inputs and so break passing of the inputs from frontend.
This could be solved by either moving to passing dictionaries (name, value) from frontend to the engine (which requires changing of C API) or making mappings inside Executor and CachedOp from the original topological ordering to the new one.
The text was updated successfully, but these errors were encountered: