Custom ops should be able to set the inplace property.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17006#issuecomment-616807857
I am generally in favor of those deprecations. The scariest part is the removal
of `mx.module` API, so definitely `Gluon is on par with module in terms of
functionality and performance` is very important for this to be successful.
--
You are receiving this because you authored the thread.
What about `mx.io.ImageRecordIter`? Also, what about the return type of those
iterator - `mx.io` iterators return `mx.io.DataBatch`, will that be changed too?
@JanuszL FYI since DALI MXNet plugin produces `mx.io.DataBatch` and may be
affected.
--
You are receiving this because you are
Hi @anirudh2290, what is the status of this proposal? When do you think changes
will be ready?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/16431#issuecomment-545681158
@yzhliu No. What MXNet currently does is a scheme where, yes, each thread gets
assigned statically some number of elements, but it has a while loop for each
of them. The scheme I proposed has a single while loop that processes all
elements assigned to a given thread. There is a big difference
Hi @xidulu. I did not look at the differences in the implementation of
host-side vs device-side API for RNG in MXNet, but if they are comparable in
terms of performance, a possible better approach would be something like this:
- launch only as many blocks and threads as necessary to fill the
