Re: [MXNET 2.0 Wishlist] [DISCUSS] Single build system

[Qing Lan]

+1 to have a single build system

Currently the way of publish and the way of doing CI test is very different. 
The instruction shown on the website should match the way we deliver it to the 
users.
Having a single build process would simplify the maintainance cost and reach to 
the best performance.

Thanks,
Qing


From: Marco de Abreu 
Sent: Thursday, April 4, 2019 15:01
To: dev@mxnet.incubator.apache.org
Subject: Re: [MXNET 2.0 Wishlist] [DISCUSS] Single build system

+1 towards having a single build system

I'd like to add the benefit of this approach allowing us to have the same
build logic across all operating systems. It would be great if we could
make x86/Unix, x86/windows, x86/mac and ARM/Unix first class citizens from
the beginning.

-Marco

Kellen Sunderland  schrieb am Do., 4. Apr. 2019, 12:31:

> Hello MXNet devs,
>
> I'd like to start a thread discussing what our build system should look
> like in MXNet 2.0.  I'd propose that although the current make system has
> served us well in the past, we remove it along with the bump to 2.0.  The
> end goal I'd like to see is that we have a clean build system, without a
> bunch of conditional logic that makes contributing and testing MXNet a
> simpler process.  Additionally I'd propose we target a minimum cmake
> version of 3.7 for reasons described below.
>
> First I'd like to give some context on why I'd propose we don't just switch
> to cmake, but we also target a relatively new version (version 3.7 from
> Nov, 2016) of cmake.  The largest benefits in making this change would
> apply to CUDA builds where cmake itself has quite inconsistent
> functionality between versions.  One persistent annoyance I've had with
> cmake is that we've had conditional logic for the FindCUDA command which at
> one point targeted some modern cmake features, but then in subsequent
> versions of cmake the way these features works was tweaked, and now I find
> these cmake features are consistently broken to the point that I require a
> bunch of -D defines to compile properly or to use an IDE.  An additional
> CUDA related issue is that every time there's a new SM added to NVCC we
> have to make a few source changes to support it.  I could see this being
> problematic for users who may suddenly realize that due to their
> compilation settings, they may not actually be enabling the features they
> think they are with their shiny new GPUs.
>
> As an alternative if we, for example, target cmake 3.7 at a minimum, and we
> want to find cuda and then build a list of reasonable PTX/BINS we could use
> the following command[1]:
>
> 
> FindCUDA(...)
> ...
> CUDA_SELECT_NVCC_ARCH_FLAGS(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
>   LIST(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})
> 
>
> Simple, concise, and it would help to make the building experience more
> consistent across platforms, build environments and IDEs (looking at you
> CLion).  We'd of course need to do a little experimentation work to make
> sure that this does indeed work as intended, and can replace the currently
> complex findCuda logic we have in our build systems, but for the sake of
> the proposal let's assume these cmake commands do indeed work consistently
> as documented from cmake 3.7 onwards.
>
> To give users a chance to update their tooling I'd also suggest we begin
> warning users at least a release in advance that make based builds will be
> deprecated in MXNet 2.0 so they can begin migrating to cmake.  I'd also
> want to display deprecation messages for unused cmake flags (such as the
> profiler flag) for a release before the 2.0 release, and then remove them
> in 2.0.
>
> Of course not all users have cmake 3.7 on their systems, some of our
> employers force use to use ridiculously outdated linux distributions.  The
> good news for these users is that if we can offer Docker compilation with
> an image that has a supported version of cmake and we should be able to
> build a portable binary that work even with very old distributions of
> Linux.  Additionally installing cmake from source is also fairly
> straightforward [2] and works quite well on older distros in my experience.
>
> Looking forward to hearing what others think.  Any preferred build systems
> that you all would want to use?  Is cmake the right system to centralize
> on?  If so, is version 3.7 a reasonable minimum version to target?  Is the
> 2.0 release a good point at which we can think about simplifying build
> logic?
>
> 1: https://cmake.org/cmake/help/v3.7/module/FindCUDA.html
> 2: https://github.com/Kitware/CMake
>

Re: MXNet 1.4.1 Release Proposal

[Sheng Zha]

Thanks Hagay for proposing the release and for Junru to volunteer to drive
the release. I will help Junru as the committer for this release.

-sz

On Thu, Apr 4, 2019 at 2:18 PM Junru Shao  wrote:

> Hi Hagay,
>
> I have some experiences in MXNet development, and would love to volunteer
> for driving this release.
>
> Thank you so much!
>
> Best,
> Junru
>
> On Thu, Apr 4, 2019 at 1:51 PM Hagay Lupesko  wrote:
>
> > Hello MXNet community,
> >
> > As previously discussed in [0
> > <
> >
> https://lists.apache.org/thread.html/a5f444999bf428d06e691b1856392ae5ebb24a3485eaa484a73de10d@%3Cdev.mxnet.apache.org%3E
> > >],
> > and per the feedback from Pedro, Kellen and Sheng, I'd like to propose
> > releasing MXNet 1.4.1.
> > MXNet 1.4.1 is a patch release on top of 1.4.0 (following semver[1
> > ]), that includes backwards compatible bug fixes -
> a
> > couple I am aware of are mem leaks in Scala API, Gluon RNN and NDArrays.
> >
> > I went ahead and created a draft release page on CWiki [2
> > <
> >
> https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status
> > >],
> > thanks to Yuxi Hu for adding a mem leak fix, and thanks to Andrew Ayres,
> > Qing Lan and Sergey Sokolov for fixing bugs in 1.4.0 - I went ahead and
> > added your fixes to the list.
> >
> > Asking the community to:
> > (1) Any bug fix or regression you identified and fixed after 1.4.0
> release?
> > please add it to the release proposal wiki (or msg me on Slack if you
> don't
> > have write access, happy to do it).
> > (2) Any comments or suggestions on the release wiki? please leave
> comments
> > on the wiki or reply to this email.
> > (3) I am looking for volunteers to drive the release - ideally we'll have
> > two volunteers: a non-committer and a shepherd committer that can also
> help
> > with the logistics that require permissions. This is a great way to
> > contribute to the community and help MXNet!
> >
> > I plan to check-in in a few days and finalize the proposal, so timely
> > response is appreciated.
> >
> > Cheers,
> > Hagay
> >
> > [0]
> >
> >
> https://lists.apache.org/thread.html/a5f444999bf428d06e691b1856392ae5ebb24a3485eaa484a73de10d@%3Cdev.mxnet.apache.org%3E
> > [1] https://semver.org/
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status
> >
>

Re: MXNet 1.4.1 Release Proposal

[Junru Shao]

Hi Hagay,

I have some experiences in MXNet development, and would love to volunteer
for driving this release.

Thank you so much!

Best,
Junru

On Thu, Apr 4, 2019 at 1:51 PM Hagay Lupesko  wrote:

> Hello MXNet community,
>
> As previously discussed in [0
> <
> https://lists.apache.org/thread.html/a5f444999bf428d06e691b1856392ae5ebb24a3485eaa484a73de10d@%3Cdev.mxnet.apache.org%3E
> >],
> and per the feedback from Pedro, Kellen and Sheng, I'd like to propose
> releasing MXNet 1.4.1.
> MXNet 1.4.1 is a patch release on top of 1.4.0 (following semver[1
> ]), that includes backwards compatible bug fixes - a
> couple I am aware of are mem leaks in Scala API, Gluon RNN and NDArrays.
>
> I went ahead and created a draft release page on CWiki [2
> <
> https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status
> >],
> thanks to Yuxi Hu for adding a mem leak fix, and thanks to Andrew Ayres,
> Qing Lan and Sergey Sokolov for fixing bugs in 1.4.0 - I went ahead and
> added your fixes to the list.
>
> Asking the community to:
> (1) Any bug fix or regression you identified and fixed after 1.4.0 release?
> please add it to the release proposal wiki (or msg me on Slack if you don't
> have write access, happy to do it).
> (2) Any comments or suggestions on the release wiki? please leave comments
> on the wiki or reply to this email.
> (3) I am looking for volunteers to drive the release - ideally we'll have
> two volunteers: a non-committer and a shepherd committer that can also help
> with the logistics that require permissions. This is a great way to
> contribute to the community and help MXNet!
>
> I plan to check-in in a few days and finalize the proposal, so timely
> response is appreciated.
>
> Cheers,
> Hagay
>
> [0]
>
> https://lists.apache.org/thread.html/a5f444999bf428d06e691b1856392ae5ebb24a3485eaa484a73de10d@%3Cdev.mxnet.apache.org%3E
> [1] https://semver.org/
> [2]
>
> https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status
>

MXNet 1.4.1 Release Proposal

[Hagay Lupesko]

Hello MXNet community,

As previously discussed in [0
],
and per the feedback from Pedro, Kellen and Sheng, I'd like to propose
releasing MXNet 1.4.1.
MXNet 1.4.1 is a patch release on top of 1.4.0 (following semver[1
]), that includes backwards compatible bug fixes - a
couple I am aware of are mem leaks in Scala API, Gluon RNN and NDArrays.

I went ahead and created a draft release page on CWiki [2
],
thanks to Yuxi Hu for adding a mem leak fix, and thanks to Andrew Ayres,
Qing Lan and Sergey Sokolov for fixing bugs in 1.4.0 - I went ahead and
added your fixes to the list.

Asking the community to:
(1) Any bug fix or regression you identified and fixed after 1.4.0 release?
please add it to the release proposal wiki (or msg me on Slack if you don't
have write access, happy to do it).
(2) Any comments or suggestions on the release wiki? please leave comments
on the wiki or reply to this email.
(3) I am looking for volunteers to drive the release - ideally we'll have
two volunteers: a non-committer and a shepherd committer that can also help
with the logistics that require permissions. This is a great way to
contribute to the community and help MXNet!

I plan to check-in in a few days and finalize the proposal, so timely
response is appreciated.

Cheers,
Hagay

[0]
https://lists.apache.org/thread.html/a5f444999bf428d06e691b1856392ae5ebb24a3485eaa484a73de10d@%3Cdev.mxnet.apache.org%3E
[1] https://semver.org/
[2]
https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status

Re: Discussing plans for next MXNet releases

[Hagay Lupesko]

Thanks Kellen, Pedro and Sheng for the feedback.

Kellen -
- Thanks for proposing 1.5 features. Kindly note them on the issue Sheng
created: https://github.com/apache/incubator-mxnet/issues/14619
- For your 2.0 proposals - can you please update them in the issue Sheng
created: https://github.com/apache/incubator-mxnet/issues/9686
Pedro -
- Thank you for volunteering for 2.0 release!
- Thanks for referencing the Issue that tracks 2.0 API updates, looks like
Sheng updated it to track the broader 2.0 features.
Sheng -
- Agreed that each release should be managed separately, my intention was
to kick start thinking for MXNet short term and long term roadmap - we can
fork at this point.
- Thanks for creating the issues for 1.5 and 2.0 - the community can start
surfacing proposals there.
- Agreed that 1.4.1 should include fixes, not features. I'll start a
separate thread on that.

As discussed - we will have separate threads for each of the releases, and
I will start with 1.4.1

Cheers,
Hagay


On Tue, Apr 2, 2019 at 6:39 PM Sheng Zha  wrote:

> Hi Hagay,
>
> Thanks for taking the initiative. The proposed scope in this thread is in
> my opinion too large to fit in a single thread, so I'd suggest that we
> start separate threads for each individual release item. To elaborate on
> the reasons based on each individual item:
> - For 1.4.1 which is in the wiki page draft, I'd suggest refraining from
> adding new features there since patch release should be about bug fixes.
> - For 1.5, there are efforts such as AMP and general improvement for fp16
> support in operators, quantization efforts, etc., that should be included.
> I may have a bit more context on this so I'm happy to help initiate the
> discussion.
> - For 2.0, I think it would be more of a roadmap discussion at this stage.
>
> I hope this makes sense. Would you mind starting a thread focusing on 1.4.1
> patch release?
>
> -sz
>
>
> On Tue, Apr 2, 2019 at 5:06 PM Hagay Lupesko  wrote:
>
> > Dear MXNet community,
> >
> > I wanted to initiate a discussion about the plan and scope for the next
> > MXNet releases.
> > I suggest we focus on three releases, and get the process going in
> > parallel:
> > (1) 1.4.1 - patch release on top of 1.4.0 to address some perf
> regressions
> > and memory leaks I am aware of, such as the memory leak fixed on Scala [0
> > ]. I went ahead
> and
> > created a draft release proposal wiki [1
> > <
> >
> https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status
> > >
> > ].
> > (2) 1.5.0 - a minor release to add new features introduced since 1.4.0
> > release started (back in Nov 2018!), such as various performance
> > improvements: aggregate SGD, in-place updates in optimizers, gpu support
> > for image processing operators and many more features useful for MXNet’s
> > users.
> > (3) 2.0 - an exciting major release that will include major enhancements
> to
> > MXNet.
> >
> > Timeframes will probably vary based on the scope. I think we should plan
> to
> > start 1.4.1 release within a couple of weeks, 1.5.0 should target
> starting
> > once we release 1.4.1, and 2.0 timeline is TBD - but such a major release
> > will require more time to discuss and decide in the community.
> >
> > I was thinking to get started through:
> > (1) Draft proposals on CWiki, where the community can add content and
> > propose scope and features.
> > (2) Setup online meetings, where anyone can dial into, from anywhere,
> where
> > we will have a chance to discuss in voice+video.
> > (3) With (1)+(2) have a scope and timeline that the community, in large,
> > supports.
> >
> > Would be great to get the community's feedback and suggestions, and
> please
> > reply if you would like to be involved in the effort of supporting the
> > releases!
> >
> > MXNet is awesome, looking forward to working together to make it even
> > better!
> > Hagay
> >
> > [0] https://github.com/apache/incubator-mxnet/pull/14586
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/%5BDRAFT+PROPOSAL%5D+Apache+MXNet+%28incubating%29+1.4.1+Release+Plan+and+Status
> >
>

[Discussion] 1.5.0 roadmap

[Sheng Zha]

Hi all,

In order to coordinate efforts for the next 1.5.0 minor release, let's join the 
discussion here: https://github.com/apache/incubator-mxnet/issues/14619

Once we have some clarity on the items to track for 1.5.0 release from the 
discussion, we will come back to the list and propose a timeline for it. Thanks.

-sz

[MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

[Marco de Abreu]

Hello,

I'd like to start a discussion about something that I've noticed being
troublesome to maintain in the current version: Backend choices being made
at compile time.

Right now, the different backends and accelerators (CPU, cuda, mkl, AWS
elastic inference, (future) AMD, openblas,TVM, etc) are all scattered
across the different layers of MXNet. On one hand, we have compile time
flags that decide which backends are being compiled into the binary, while
at the same time choices can be made in the frontend during runtime.

At the moment, we have a lot of conditional build logic that picks
different parts. With the addition of MKLML and later MKLDNN the clear
separation of CPU and GPU got kind of broken up. While we have some places
where each code lives, in the end we resort to some files containing a lot
of conditional logic for the different backends (sorry I can't provide
links right now since I'm on mobile). To me this seems like a residue of
the fast development style from the early days (more processor statement
and less object orientation) while also having organic growth with new
accelerators. When I see how much AMD had to hack to fit in their
implementation, it seemed like we have to make this part more developer
friendly.

At the moment, every new flavour of MXNet has to be entirely recompiled.
This makes it hard for users to figure out which options to use, while it
makes it harder for us to test since the overhead to test every single
combination of compile parameters would be overwhelming.

I'd propose to have a clear class hierarchy based structure for
accelerators, operators and memory management. This structure can then be
implemented by the different backends. To reduce the compile burden, we
would introduce dynamic loading and split the different backends into
modules. These could then be developed, maintained and compiled on their
own and then placed in a "module" folder to be loaded at runtime. Adding a
new accelerator would be a matter of placing the precompiled binary into
the folder. The detailed configuration of that Backend would then be done
on runtime - the user shouldn't worry at the point of downloading mxnet
whether they want mkl, MKLDNN, mkl, openblas, atlas, TVM, cuda or what ever
else there is. I have an idea how we could help the user choosing, but
that's outside the scope of this proposal.

This would allow us to have a "core" MXNet that takes care of the engine,
scheduling, communication and all the other crucial parts. On the other
hand we could make MXNet less of a monolith and have clear interfaces. This
would also act as a forcing function because the different parts wouldn't
be intermingled but have to follow the common interface.

Of course this comes with the question what these interfaces would look
like. For operators, I'd like to propose getting inspiring (or fully
adapting) ONNX. For memory management and other Backend specific things we
could look at the current implementations and find a common ground.

Back when I had a community driven project, we heavily used this modularity
and it brought great benefits - besides the fact that our core was closed
source. It allowed community developers to act entirely independent from
other parts and even allowed them to add their own logic without having to
touch the core. Thinking about companies that implement their own backends
or have special tweaked operators without wanting to disclose them, this
structure would avoid them having to fork the project and then spend a lot
of effort porting the changes to the latest source release versions.
Instead, they would maintain their module and we as MXNet community would
only have to maintain these interfaces.

Right now this is a lot of prosa and basically a brain dump of my thoughts.
I'd be happy to follow up with details, but first I'd be curious what the
community thinks about this design.

Best regards,
Marco

Re: [MXNET 2.0 Wishlist] [DISCUSS] Single build system

[Marco de Abreu]

+1 towards having a single build system

I'd like to add the benefit of this approach allowing us to have the same
build logic across all operating systems. It would be great if we could
make x86/Unix, x86/windows, x86/mac and ARM/Unix first class citizens from
the beginning.

-Marco

Kellen Sunderland  schrieb am Do., 4. Apr. 2019, 12:31:

> Hello MXNet devs,
>
> I'd like to start a thread discussing what our build system should look
> like in MXNet 2.0.  I'd propose that although the current make system has
> served us well in the past, we remove it along with the bump to 2.0.  The
> end goal I'd like to see is that we have a clean build system, without a
> bunch of conditional logic that makes contributing and testing MXNet a
> simpler process.  Additionally I'd propose we target a minimum cmake
> version of 3.7 for reasons described below.
>
> First I'd like to give some context on why I'd propose we don't just switch
> to cmake, but we also target a relatively new version (version 3.7 from
> Nov, 2016) of cmake.  The largest benefits in making this change would
> apply to CUDA builds where cmake itself has quite inconsistent
> functionality between versions.  One persistent annoyance I've had with
> cmake is that we've had conditional logic for the FindCUDA command which at
> one point targeted some modern cmake features, but then in subsequent
> versions of cmake the way these features works was tweaked, and now I find
> these cmake features are consistently broken to the point that I require a
> bunch of -D defines to compile properly or to use an IDE.  An additional
> CUDA related issue is that every time there's a new SM added to NVCC we
> have to make a few source changes to support it.  I could see this being
> problematic for users who may suddenly realize that due to their
> compilation settings, they may not actually be enabling the features they
> think they are with their shiny new GPUs.
>
> As an alternative if we, for example, target cmake 3.7 at a minimum, and we
> want to find cuda and then build a list of reasonable PTX/BINS we could use
> the following command[1]:
>
> 
> FindCUDA(...)
> ...
> CUDA_SELECT_NVCC_ARCH_FLAGS(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
>   LIST(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})
> 
>
> Simple, concise, and it would help to make the building experience more
> consistent across platforms, build environments and IDEs (looking at you
> CLion).  We'd of course need to do a little experimentation work to make
> sure that this does indeed work as intended, and can replace the currently
> complex findCuda logic we have in our build systems, but for the sake of
> the proposal let's assume these cmake commands do indeed work consistently
> as documented from cmake 3.7 onwards.
>
> To give users a chance to update their tooling I'd also suggest we begin
> warning users at least a release in advance that make based builds will be
> deprecated in MXNet 2.0 so they can begin migrating to cmake.  I'd also
> want to display deprecation messages for unused cmake flags (such as the
> profiler flag) for a release before the 2.0 release, and then remove them
> in 2.0.
>
> Of course not all users have cmake 3.7 on their systems, some of our
> employers force use to use ridiculously outdated linux distributions.  The
> good news for these users is that if we can offer Docker compilation with
> an image that has a supported version of cmake and we should be able to
> build a portable binary that work even with very old distributions of
> Linux.  Additionally installing cmake from source is also fairly
> straightforward [2] and works quite well on older distros in my experience.
>
> Looking forward to hearing what others think.  Any preferred build systems
> that you all would want to use?  Is cmake the right system to centralize
> on?  If so, is version 3.7 a reasonable minimum version to target?  Is the
> 2.0 release a good point at which we can think about simplifying build
> logic?
>
> 1: https://cmake.org/cmake/help/v3.7/module/FindCUDA.html
> 2: https://github.com/Kitware/CMake
>

[MXNET 2.0 Wishlist] [DISCUSS] Single build system

[Kellen Sunderland]

Hello MXNet devs,

I'd like to start a thread discussing what our build system should look
like in MXNet 2.0.  I'd propose that although the current make system has
served us well in the past, we remove it along with the bump to 2.0.  The
end goal I'd like to see is that we have a clean build system, without a
bunch of conditional logic that makes contributing and testing MXNet a
simpler process.  Additionally I'd propose we target a minimum cmake
version of 3.7 for reasons described below.

First I'd like to give some context on why I'd propose we don't just switch
to cmake, but we also target a relatively new version (version 3.7 from
Nov, 2016) of cmake.  The largest benefits in making this change would
apply to CUDA builds where cmake itself has quite inconsistent
functionality between versions.  One persistent annoyance I've had with
cmake is that we've had conditional logic for the FindCUDA command which at
one point targeted some modern cmake features, but then in subsequent
versions of cmake the way these features works was tweaked, and now I find
these cmake features are consistently broken to the point that I require a
bunch of -D defines to compile properly or to use an IDE.  An additional
CUDA related issue is that every time there's a new SM added to NVCC we
have to make a few source changes to support it.  I could see this being
problematic for users who may suddenly realize that due to their
compilation settings, they may not actually be enabling the features they
think they are with their shiny new GPUs.

As an alternative if we, for example, target cmake 3.7 at a minimum, and we
want to find cuda and then build a list of reasonable PTX/BINS we could use
the following command[1]:


FindCUDA(...)
...
CUDA_SELECT_NVCC_ARCH_FLAGS(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
  LIST(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})


Simple, concise, and it would help to make the building experience more
consistent across platforms, build environments and IDEs (looking at you
CLion).  We'd of course need to do a little experimentation work to make
sure that this does indeed work as intended, and can replace the currently
complex findCuda logic we have in our build systems, but for the sake of
the proposal let's assume these cmake commands do indeed work consistently
as documented from cmake 3.7 onwards.

To give users a chance to update their tooling I'd also suggest we begin
warning users at least a release in advance that make based builds will be
deprecated in MXNet 2.0 so they can begin migrating to cmake.  I'd also
want to display deprecation messages for unused cmake flags (such as the
profiler flag) for a release before the 2.0 release, and then remove them
in 2.0.

Of course not all users have cmake 3.7 on their systems, some of our
employers force use to use ridiculously outdated linux distributions.  The
good news for these users is that if we can offer Docker compilation with
an image that has a supported version of cmake and we should be able to
build a portable binary that work even with very old distributions of
Linux.  Additionally installing cmake from source is also fairly
straightforward [2] and works quite well on older distros in my experience.

Looking forward to hearing what others think.  Any preferred build systems
that you all would want to use?  Is cmake the right system to centralize
on?  If so, is version 3.7 a reasonable minimum version to target?  Is the
2.0 release a good point at which we can think about simplifying build
logic?

1: https://cmake.org/cmake/help/v3.7/module/FindCUDA.html
2: https://github.com/Kitware/CMake

Re: Requesting slack access

[Hagay Lupesko]

Hi Xiuquan,

Slack invite sent - welcome to the MXNet community!
Please slack me @Hagay Lupesko - would love to chat about how you guys are
thinking about using MXNet.

Hagay

On Thu, Apr 4, 2019 at 1:24 AM Xiuquan Lv  wrote:

> Dear MXNet community,
>
>
>
>
> Please join me in the MXNet Slack Community.
>
>
>
>
> Thanks
>
> Xiuquan Lv

[RFC] Higher order gradient support in MXNet

[Lin Yuan]

Dear Community,

Higher order gradient calculation is required for many applications.
However, current MXNet only support higher order gradient for a very
limited number of operators.

We plan to support the higher order gradient calculation in the autograd
package. A design proposal is ready for review:
https://cwiki.apache.org/confluence/display/MXNET/Higher+Order+Gradient+Calculation

We will appreciate any help and feedbacks from the community.

Cheers!

Lin

Re: Reminder: MXNet Berlin User Group

[Chance Bair]

Correct, this is a pattern.  As I am a relatively new joiner to MXNet, it
might be good to elaborate on what users would want out of a remote user
group.  I would love to hear suggestions!

Chance Bair



On Thu, Apr 4, 2019 at 2:48 PM Isabel Drost-Fromm  wrote:

>
>
> Am 4. April 2019 13:29:28 MESZ schrieb Chance Bair :
> >Again, there were no attendees.
>
> Is that a pattern, or was that just the case for the past two events?
>
> If the former, maybe we could brainstorm here what could be done to make
> the offer more attractive?
>
>
> Isabel
>
> --
> This message was sent with K-9 from a mobile device with swipe to type
> enabled. I'm sorry for any embarrassing typos that slipped through.
>

Re: Reminder: MXNet Berlin User Group

[Isabel Drost-Fromm]

Am 4. April 2019 13:29:28 MESZ schrieb Chance Bair :
>Again, there were no attendees.

Is that a pattern, or was that just the case for the past two events?

If the former, maybe we could brainstorm here what could be done to make the 
offer more attractive?


Isabel

-- 
This message was sent with K-9 from a mobile device with swipe to type enabled. 
I'm sorry for any embarrassing typos that slipped through.

Re: Reminder: MXNet Berlin User Group

[Chance Bair]

Again, there were no attendees.

Chance Bair



On Thu, Apr 4, 2019 at 1:07 PM Isabel Drost-Fromm  wrote:

> On Tue, Apr 02, 2019 at 01:50:40PM +0200, Chance Bair wrote:
> > This is a friendly reminder that MXNet Berlin User Group will be held
> today
> > at 6pm-7pm (CEST) / 9am-10am (PST). More info here:
> >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+User+Groups+recurring+meetings
>
> Same question as last week: Would you please share more information on how
> the
> event turned out in terms of attendees, topics etc.?
>
>
> Isabel
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>

Re: Reminder: MXNet Berlin User Group

[Isabel Drost-Fromm]

On Tue, Apr 02, 2019 at 01:50:40PM +0200, Chance Bair wrote:
> This is a friendly reminder that MXNet Berlin User Group will be held today
> at 6pm-7pm (CEST) / 9am-10am (PST). More info here:
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+User+Groups+recurring+meetings

Same question as last week: Would you please share more information on how the
event turned out in terms of attendees, topics etc.?


Isabel

-- 
Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most 
likely involving some kind of mobile connection only.)

Requesting slack access

[Xiuquan Lv]

Dear MXNet community,




Please join me in the MXNet Slack Community.




Thanks

Xiuquan Lv