You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mxnet.apache.org by GitBox <gi...@apache.org> on 2021/04/02 16:55:16 UTC

[GitHub] [incubator-mxnet] matteosal edited a comment on issue #20109: 2.0 migration guide?

matteosal edited a comment on issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109#issuecomment-812614000


   Ok I went looking for how the python wrapper ([symbol.py](https://github.com/apache/incubator-mxnet/blob/master/python/mxnet/symbol.py) and [executor.py](https://github.com/apache/incubator-mxnet/blob/master/python/mxnet/executor.py)) got adapted to work with the cached op API and I'm starting to get a feeling of the current scenario. Some questions:
   
   * One major difference is that while the the old C executor required arrays at construction time, cached op requires them at evaluation time (`MXInvokeCachedOp`). Cached op also has a flag called `static_alloc`. This suggests that when such flag is activated the graph is actually "compiled" and shipped to the execution device by `MXInvokeCachedOp`, similarly to what `MXExecutorBind` used to do (except `MXInvokeCachedOp` also immediately runs the graph). Is this reasoning correct? 
   * Following the reasoning of the previous point, calling `MXInvokeCachedOp` twice in a row specifying CPU and GPU devices (with `static_alloc = true`) will allocate the graph on both system memory and GPU memory. Is there a way to selectively free CPU or GPU memory?
   * Again on the same reasoning, what happens if `MXInvokeCachedOp` is called multiple times with NDArrays of different shapes? Will the arrays share memory?
   * What is the purpose of flags `forward_bulk_size` and `backward_bulk_size`?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@mxnet.apache.org
For additional commands, e-mail: issues-help@mxnet.apache.org