leezu commented on a change in pull request #16465: [Gluon] [Fix] [WIP] Fix
HybridBlock when hybridize is not called
URL: https://github.com/apache/incubator-mxnet/pull/16465#discussion_r335090536
##########
File path: python/mxnet/gluon/block.py
##########
@@ -1054,34 +1098,16 @@ def register_op_hook(self, callback,
monitor_all=False):
def forward(self, x, *args):
"""Defines the forward computation. Arguments can be either
:py:class:`NDArray` or :py:class:`Symbol`."""
- flatten_args = _flatten([x] + list(args), 'inputs')[0]
- is_ndarray = None
- ctx = None
- exist_sym_nd = False
- for ele in flatten_args:
- if isinstance(ele, NDArray):
- if is_ndarray is False:
- raise ValueError('In HybridBlock, we do not support mixed
NDArrays and Symbols'
- ' types for the input.\n'
- 'Received types are: {}.'
- .format([type(ele) for ele in
flatten_args]))
- is_ndarray = True
- exist_sym_nd = True
- ctx = ele.context
Review comment:
As the previous implementation hasn't enforced all contexts being equal, we
shouldn't start picking a different array to determine the context. As you
stated above, it's valid to use a mix of `cpu, cpu_pinned, cpu_shared`
contexts.
For example, after your change, `cpu_pinned` or `cpu_shared` may be picked
as default context instead of `cpu` if the user passed a `cpu_pinned` or
`cpu_shared` as last argument. The extra overhead could cause a performance
regression (all parameters will be made available under default context).
No need to risk this given there is no advantage?
----------------------------------------------------------------
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:
us...@infra.apache.org
With regards,
Apache Git Services
