@fhieber we are planning to release the first public beta on this somewhere in
August. At the moment we are finalizing some API changes and also validating
them in GluonNLP. We will publish a transition doc as part of the public beta.
--
You are receiving this because you are subscribed to
@szha is there a recent estimate on the timeline for MXNet 2.0? Would you
recommend to develop downstream toolkits (e.g. Sockeye) against the master
branch now or rather wait a little bit longer?
Is there already documentation on how to transition MXNet 1.x projects to 2.x?
--
You are
A quick comment: DGL contains all sampling implementation and no longer relies
on the implementation in MXNet. I think we should deprecate the graph sampling
implementation in MXNet.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
> @lilongyue the integration of bytePS to mxnet is in this PR #17555
that's great !
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/16167#issuecomment-605647115
@lilongyue the integration of bytePS to mxnet is in this PR
https://github.com/apache/incubator-mxnet/pull/17555
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/16167#issuecomment-605494475
@szha
i checked some docs and projects about distributed training ,
'Horovod' is project from uber team , 'Gloo' is project from facebook team.
The basic idea is to use trick from HPC computing field which is more efficient
then traditional param-server:
We use the c++ interface for inference on a sorting machine. But also we would
like to provide the users of our machines an easy and integrated user interface
for training new sorting recipes. Now we use python or Mathematica scripts
which is far of user friendly for non-programmers. So we want
> @kalcohol please create a new issue about "static linking lib is (very) far
> away from easy to use", describing your setup in more detail and potentially
> suggestions how to improve the user experience.
#17692 add this tiny requist.
--
You are receiving this because you were mentioned.
@kalcohol please create a new issue about "static linking lib is (very) far
away from easy to use", describing your setup in more detail and potentially
suggestions how to improve the user experience.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it
Thanks for this awesome work, it has benefited me a great deal.
Here are some disadvantages(may be) listed blow:
1. it seems that c and c++ interface both could work, but can not finish single
task only by one;
2. low bit training or inference is not available via c/c++(ver. 1.6.0 fix fp16
Is there a plan to remove the cudnn_off argument from the neural network
operators such as Dropout, Convolution, Pool etc. It creates a few usability
issues:
(1) Once a model is exported. It requires users to change this flag in all the
layers manually if they want to enable/disable cuDNN. When
@TaoLv one promising direction that the community is converging to is the
interface based on packed function (motivation as described by @tqchen in
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-56760).
What this means to the project is that the existing c API will be
> 3.1. C-API Clean-up
C-API is the foundational API in MXNet that all language bindings depend on.
@szha I'm looking at the item 3.1.2. Could you please explain the scope of
C-API? Do you mean those APIs sit in the src/c_api/ folder?
--
You are receiving this because you were mentioned.
Reply
+1 for using master branch for 2.0 development. I think we need 3 branches at
least:
1. master branch: for 2.0 development
2. v1.x: for 1.x development and maintenance
3. v1.7.x: for 1.7.x release
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on
In the past we always kept development on the master branch, thus how about
branching out 1.7.0 release branch and keeping development on master?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
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:
Once 1.6 release is complete, we will create a branch for MXNet 1.x for future
releases and start using master branch for 2.0 development.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The status of MXNet 2.0 project is tracked at:
https://github.com/apache/incubator-mxnet/projects/18. The status for each
project will be updated by the contributor who's driving it. If you have more
projects that you intend to drive please first discuss here.
--
You are receiving this
That's a bit what amalgamation part was for ? a simplified inference interface.
The last time I use amalgamation (some years ago) it was often break by update
and not really maintain.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
>
>
> @stereomatchingkiss good point. What are you using c/c++ api for?
1. Develop stand alone app on desktop and mobile
2. Wrapper of another language(ex : php)
3. Run the inference task on aws lambda, we do not want to prune the libs of
python manually if we could build a slim library of
@stereomatchingkiss good point. What are you using c/c++ api for?
--
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/16167#issuecomment-563883331
Any plan to simplify the build of c and c++ api for mxnet2.0?It is hard(or very
hard) to build a working version of mxnet with cpp api on different
platforms(windows, linux, mac), every new release of the mxnet may or may not
break somethings and we need to spend many hours to figure out how to
Just a quick cheer up for a new website of MXNet... its way more awesome and
beautiful than I expected.
Though minor bugs are still there, for ex- most of the link in the tutorials
are broken and not working.
Anyways great work so far.
--
You are receiving this because you were mentioned.
@pengzhao-intel a tentative target date is by end of Q1 2020.
@zachgk we will create a branch for 2.0. Initially we will keep master to be
1.x and have 2.0 in a new branch. After 1.6 release we will revisit how to make
the 2.0 branch the master.
--
You are receiving this because you are
Is there a plan to create a branch either for the 1.x version and have master
reflect 2.0 or to create a branch for the 2.0 version and keep master on 1.x
for now?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
@szha Really great proposal and we may want to add some items in 2.0 too.
Is there a timeline of 2.0?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/16167#issuecomment-531542441
# Overview
The purpose of this RFC is to organize and present the roadmap towards 2.0. As
2.0 will be a major release, changes that would break backward compatibility
are permissible.
The proposed changes in this RFC are either collected from past roadmap
discussions such as #9686, or are
27 matches
Mail list logo
