Agree, we should add the selection in the installation page for nightly build.
https://mxnet.apache.org/get_started?version=master=linux=python=pip=cpu#
> -Original Message-
> From: Haibin Lin
> Sent: Tuesday, December 17, 2019 2:40 PM
> To: dev@mxnet.incubator.apache.org
> Cc:
@wkcn could you explain your suggestion? calling gemm back into the framework
which gets dispatched to GPU or CPU?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
What's the point of having an API if you type erase it? Then you might as
well have a single function API with a type erased callback name to select
the function to call. In the end you move the burden away from the API to
the callers and inside the API to the dispatchers. For going this route of
https://github.com/apache/incubator-mxnet/pull/17012 should be also ported
to the release branch.
On Fri, Dec 20, 2019 at 1:39 PM Przemysław Trędak
wrote:
> That issue is now fixed in master, I am in the process of cherry-picking
> the fix to v1.6.x branch. I will prepare the RC1 once that is
Pybind is nice, I used Boost python many years ago, which I think is based
on. The problem with this is the hourglass C bindings, you have to go from
Python to C++ / Pybind, down to C and to the engine, this seems like a lot
of boilerplate.
On Mon, Dec 16, 2019 at 10:02 PM reminisce wrote:
>
@larroy indeed every solution has trade-offs, and these tradeoffs are discussed
in the above posts when we compare solutions, and they are backed by benchmarks
:) it would be great if you can also suggest potential tradeoffs here.
When you expose an API from typed language(c++) to a dynamic
Should we create a new branch for 2.0? I think we are also planing for 1.7.0
https://github.com/apache/incubator-mxnet/issues/16864
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
