> As MXNet v1.3 is likely to be used a lot with Cuda 9.2 I believe the default
> behavior should be changed to use the bug-free but less efficient Kernel.
It would be crazy to do anything else, to be honest. Its a terrible philosophy
to say to users 'you can't rely on MXNet to have correct beha
Hi Hao,
Did you look at the AddTakeGrad for sparse gradient
https://github.com/apache/incubator-mxnet/blob/master/src/operator/tensor/indexing_op.cu#L77
? If I'm not mistaken, Leonard doesn't see nan values generated by the
sparse gradient kernel. The sparse kernel shares similar parallelization
Hi all,
Some preliminary benchmark results have been shared on the related PR, and
what we've found is that based on the sample benchmark with an input on
which the LargeBatch version is supposed to have a better performance,
there was no significant increase in performance compared with either the
If it is buggy, how does it matter if it is performant or not? I am not
seeing the rationale to make the correct version only opt-in.
On Mon, Jul 23, 2018 at 6:47 PM, Leonard Lausen
wrote:
> Currently the default kernel of nn.Embedding backward is known to be
> buggy on P3 instances or using Cu
Currently the default kernel of nn.Embedding backward is known to be
buggy on P3 instances or using Cuda 9.2 (though the issue also occurs on
other instances with earlier version of Cuda, but less often).
https://github.com/apache/incubator-mxnet/issues/11314
There is currently an opt-in for usin
