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/03/31 16:50:43 UTC
[GitHub] [incubator-mxnet] matteosal opened a new issue #20109: 2.0 migration guide?
matteosal opened a new issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109
Is there a resource or set of resources for migrating a project to v2.0? I am specifically interesed to the C API. I have checked https://github.com/apache/incubator-mxnet/issues/17676 but it's not very specific apart from the `*Ex` functions removal/renaming.
For example everything related to executors, on which our code relies heavily, is gone in v2.0. This PR https://github.com/apache/incubator-mxnet/pull/18598 mentions "we will use cached_op_create/invoke in favor of graph executor c APIs" but I couldn't find detailed information on how to migrate code using the executor API to cached ops.
--
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
[GitHub] [incubator-mxnet] szha commented on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
szha commented on issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109#issuecomment-811360466
Thanks for bringing this up. Yes I think we definitely need a migration guide.
--
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
[GitHub] [incubator-mxnet] matteosal commented on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
matteosal commented 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. 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
[GitHub] [incubator-mxnet] szha commented on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
szha commented on issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109#issuecomment-814159283
Hi @matteosal. Thanks for looking into this.
> Is this reasoning correct?
Yes
> Is there a way to selectively free CPU or GPU memory?
Not yet, though this is indeed a useful functionality.
> what happens if MXInvokeCachedOp is called multiple times with NDArrays of different shapes? Will the arrays share memory?
When `static_alloc` is on and multiple calls with different shapes happen, cached op will enlarge the buffer size when necessary.
> What is the purpose of flags forward_bulk_size and backward_bulk_size?
These are flags for bulk execution. When bulk execution happens with `forward_bulk_size=x`, x number of operators will be executed in one call to the engine (scheduler) instead of x separate calls, so that the scheduling overhead is amortized.
--
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
[GitHub] [incubator-mxnet] matteosal commented on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
matteosal commented on issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109#issuecomment-820556774
More on the cached op flags:
> These are flags for bulk execution. When bulk execution happens with forward_bulk_size=x, x number of operators will be executed in one call to the engine (scheduler) instead of x separate calls, so that the scheduling overhead is amortized.
Since this is an option to set, I guess there is a downside to running a large number of operators in one call. What is it? Increased memory usage? Is there a similar tradeoff for `inline_limit`?
--
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
[GitHub] [incubator-mxnet] matteosal edited a comment on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
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
[GitHub] [incubator-mxnet] matteosal commented on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
matteosal commented on issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109#issuecomment-819665575
Another question: in v1.x it was possible to query executors for their allocated memory:
```
import mxnet as mx
sym = mx.sym.Convolution(
mx.sym.Variable('in'),
mx.sym.Variable('w'),
num_filter=16,
kernel=(3, 3),
no_bias=True
)
sym = mx.sym.relu(sym)
args = {'in': mx.nd.ones([64, 3, 300, 300]), 'w': mx.nd.ones([16, 3, 3, 3])}
ex = sym.bind(mx.cpu(), args)
print(ex.debug_str())
```
```
Symbol Outputs:
output[0]=relu0(0)
Variable:in
Variable:w
--------------------
Op:Convolution, Name=convolution0
Inputs:
arg[0]=in(0) version=0
arg[1]=w(0) version=0
Attrs:
kernel=(3, 3)
no_bias=True
num_filter=16
--------------------
Op:relu, Name=relu0
Inputs:
arg[0]=convolution0(0)
Total 346 MB allocated
Total 11 TempSpace resource requested
```
Is there a way to get the equivalent of the line "Total 346 MB allocated" with cached ops?
--
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
[GitHub] [incubator-mxnet] szha commented on issue #20109: 2.0 migration guide?
Posted by GitBox <gi...@apache.org>.
szha commented on issue #20109:
URL: https://github.com/apache/incubator-mxnet/issues/20109#issuecomment-819728978
Not yet. It would be great to add back that feature
--
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