Re: Slack

[Holger Kohr]

Hi Steffen,

yes, it's correct. Naveen already sent me an invitation, thanks for that!

/Holger

On 18/10/18 20:34, Steffen Rochel wrote:

Hi Holger - MXNet Slack is based on email. Is ho.k...@zoho.com correct?
Steffen

On Wed, Oct 17, 2018 at 12:03 PM Holger Kohr 
wrote:


Hi!

I'd like to join the MXNet Slack channel. My GH handle is @kohr-h.

Cheers,
Holger

Re: MXNet - Label Bot functionality

[Harsh Patel]

Hey,
After having my PR vetted and reviewed by some contributors, I would like
to move forward into the stage of putting this into production. I am asking
for MXNet committers to take a look at my PR regarding the Label Bot.
https://github.com/MXNetEdge/mxnet-infrastructure/pull/15. This will also
require access for a webhook - let's set this into motion. Thanks.

Best,
-Harsh

On Mon, Oct 15, 2018 at 4:05 PM Piyush Ghai  wrote:

> Hi Harsh,
>
> Good job! This is super cool! Especially bringing down the response time
> to under 20 seconds.
>
> Thanks,
> Piyush
>
>
> > On Oct 15, 2018, at 3:49 PM, Qing Lan  wrote:
> >
> > Hi Harsh,
> >
> > This new label bot design looks great! I would like to encourage people
> to review it and move forward to benefit the MXNet community.
> > Since this new design needs webhook support from Apache, let's go
> through the following steps to get this done:
> >
> > 1. Demo and contributors review stage: all contributors are encouraged
> to review the PR here:
> > https://github.com/MXNetEdge/mxnet-infrastructure/pull/15 and leave
> your thoughts so Harsh can apply them in his design.
> > 2. Committers review stage: Once all contributors think the design is
> good to go, let's get committers involved to get a review.
> > 3. Committers send request to Apache Infra to get the webhook setup.
> > 4. Harsh finally deploy the model and all of us can use it in
> incubator-mxnet repo!
> >
> > Some fun fact I would like to share:
> > 1. This new bot can recommend labels and reply to people who file it!
> > 2. It response time from 5mins -> less than 20 seconds
> >
> > Thanks,
> > Qing
> >
> > On 10/15/18, 11:11 AM, "Harsh Patel" 
> wrote:
> >
> >Hey,
> >I have a demo available that users and developers can play around
> with --
> >this is in regards to the post I had made regarding the updated label
> bot
> >functionality. This is available on my fork (
> >https://github.com/harshp8l/incubator-mxnet) if the developers would
> be
> >able to provide feedback that would be great.
> >The updated usage of this label bot:
> >To add labels: @mxnet-label-bot, add ['label1', 'label2']
> >To remove labels: @mxnet-label-bot, remove ['label1', 'label2']
> >To update labels: @mxnet-label-bot, update ['label3', 'label4']
> >(warning: with update - this will remove all other labels for a
> specific
> >issue and update only with the labels the user specifies). Thanks.
> >
> >My PR for reference:
> >https://github.com/MXNetEdge/mxnet-infrastructure/pull/15
> >
> >My Design:
> >
> https://cwiki.apache.org/confluence/display/MXNET/Machine+Learning+Based+GitHub+Bot
> >
> >Best,
> >-Harsh
> >
> >On Mon, Oct 15, 2018 at 12:54 AM Hagay Lupesko 
> wrote:
> >
> >> +1
> >> Thanks for the contribution!
> >>
> >> On Fri, Oct 12, 2018 at 1:41 AM kellen sunderland <
> >> kellen.sunderl...@gmail.com> wrote:
> >>
> >>> Awesome work!  Many thanks.
> >>>
> >>> On Fri, Oct 12, 2018, 1:19 AM Harsh Patel 
> >>> wrote:
> >>>
>  Hey,
>  I am looking to contribute to MXNet. I have a working implementation
> >>> based
>  on my proposed design structure according to this wiki page (
> 
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Machine+Learning+Based+GitHub+Bot
>  )
>  - under 7.
>  I have provided users with functionality allowing for adding,
> updating,
> >>> and
>  deleting labels for our issues. The response time with the bot to
> >> provide
>  the aforementioned functionality has been reduced as well. Users
> should
>  expect speedy updates to labels based on requests made to the label
> >> bot.
>  The total number of GitHub API calls have been further reduced as well
>  preventing potential bottlenecks that could result from GitHub.
>  I would like to have a webhook for this repo:
>  https://github.com/apache/incubator-mxnet so that this functionality
> >>> will
>  be used and tested by the developers here. Thanks.
> 
>  Best,
>  -Harsh Patel
> 
> >>>
> >>
> >
> >
>
>

Re: Apache MXNet (incubating) Python Docker Images

[Meghna Baijal]

Thank you Kellen and Steffen for your comments.
I will wait for some more time in case anyone has a different opinion, else
go ahead with the above recommendation.

Meghna



On Wed, Oct 17, 2018 at 10:18 PM Steffen Rochel 
wrote:

> +1 on Kellen’s comments and suggestion.
> On Wed, Oct 17, 2018 at 12:39 PM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > This feels like something we should get a little data on before making a
> > decision, but I also don't have a strong opinion.  I would bias towards
> > pushing something that might be imperfect and moving on to develop other
> > improvements for users rather than determining a 'perfect' solution.
> >
> > The questions/tradeoffs I see are (1) should we support multiple python
> > versions in the first place, which requires extra work on our part but
> > supports more users and (2) should we favor forwards or backwards
> > compatibility, i.e. should we prioritize supporting existing users or
> > prioritize making something that won't cause future problems for new and
> > exiting users.
> >
> > The best data I can find with a quick google is the annual Jetbrains
> survey
> > which shows python2 went from 47% in 2017 to 25% in 2018:
> > https://www.jetbrains.com/research/devecosystem-2017/python/
> > https://www.jetbrains.com/research/devecosystem-2018/python/
> >
> > So python2 usage is trending sharply down but is not yet low enough to
> > ignore which I think means we should try and support both on Dockerhub
> (1).
> >
> > I don't see backwards compatibility with existing Docker users is a major
> > concern given these Dockerfiles haven't been supported for a long time.
> I
> > would prioritize forwards compatibility (2) and assume we want to create
> > something that will remain compatible for as long as possible.
> >
> > So I would push both python2 and python3 images, but make python 3.5 the
> > default version, and python2 a version with a postfixed py2 tag in
> > Dockerhub.
> >
> > Thanks to Mu (and others?) for original creating this Dockerhub images, I
> > used to use them and found them very convenient, and to you Meghna for
> > updating them.  I think basing them on the pip packages is also a good
> way
> > to lower maintenance burden and make sure we leverage the great work
> Sheng
> > has done to create those packages.
> >
> > On Wed, Oct 17, 2018 at 11:52 AM Meghna Baijal <
> meghnabaijal2...@gmail.com
> > >
> > wrote:
> >
> > > Hi All,
> > >
> > > I am currently in the process of updating the python docker images for
> > > Apache MXNet such that they are built on top of the pip binaries.
> > > Until now these were built to use python 2.7 but with an upcoming PR I
> am
> > > also adding python 3.5 docker images. I would like to know the
> > community’s
> > > preference on whether I should keep the *Python 2.7 Docker image as the
> > > default or should I move to Python 3.5 as the default version*?
> > >
> > > [1] The new python2 dockerfiles and build script can be found here.
> > > <
> > >
> >
> https://github.com/apache/incubator-mxnet/tree/master/docker/docker-python
> > > >
> > > [2] The PR for python3 images is in progress and is here.
> > > 
> > >
> > > Thanks,
> > > Meghna Baijal
> > >
> >
>

Re: Slack

[Steffen Rochel]

Hi Holger - MXNet Slack is based on email. Is ho.k...@zoho.com correct?
Steffen

On Wed, Oct 17, 2018 at 12:03 PM Holger Kohr 
wrote:

> Hi!
>
> I'd like to join the MXNet Slack channel. My GH handle is @kohr-h.
>
> Cheers,
> Holger
>
>

Re: [Discussion] Separating PMC and Committership

[Naveen Swamy]

I suggest we discuss on what the revised criteria for committers will be
and how do committers move up to become a PMC member before voting on the
separation ? I would like to see if that helps grow the community before
Voting on this.

@Chris Olivier  Can you clarify what you mean by
bonafide intentions and other intangeables ?,
I would assume one can still consider them while you vote if you can
justify or support it and not be just based on how someone feels.

On Thu, Oct 18, 2018 at 8:29 AM Chris Olivier  wrote:

> IMHO it’s not a great idea to develop a hard criteria for committer and PMC
> as if it were some sort of checklist. If that were the case, then people
> would tend to be just laser-focused on checking items off the list rather
> than a bonafied drive to improve the product and the community.  It would
> also make it difficult to consider other intangeables in the decision.
>
>
> On Thu, Oct 18, 2018 at 5:43 AM Carin Meier  wrote:
>
> > Thanks Micheal for making the process clearer to me. It helps quite a
> bit.
> >
> > Also thanks to Chris and Steffen for your clarification and input.
> >
> > I think there are two issues that are intermingled in considering this.
> One
> > relates to separating levels of committer and PMC member. The other, as
> > Steffen pointed out, relates to the criteria which we use to consider
> > people for these levels of membership. I would propose that to make it
> > easier to achieve consensus, we consider them each as their own proposal.
> >
> > The proposal of separating levels of committer and PMC member can be
> > considered on the Apache definitions of rights and responsibilities here
> > https://www.apache.org/foundation/how-it-works.html#roles: Since the PMC
> > member has more rights and responsibilities than a committer, I think it
> > implies a stricter criteria, (although it would be unspecified in the
> > proposal).
> >
> > The proposal of redefining our project's criteria in respect to how we
> > consider nomination to those roles could be a separate discussion and
> vote
> > since there are other issues that we might want to tackle such as
> inclusion
> > of non-code contributions and general alignment to the Apache
> definitions.
> >
> > We can of course choose to tackle the proposal of redefining the criteria
> > first or do the separation of levels first since the discussion is
> already
> > in progress.
> >
> > Thoughts?
> >
> > - Carin
> >
> >
> >
> >
> >
> >
> > On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel 
> > wrote:
> >
> > > Haibin's proposed "For active contributors we first invite them to
> become
> > > our committers. Later on as they make significant contribution, we can
> > > invite them to PMC."
> > > Several people raised the question what defines "active contributors"
> and
> > > "make significant contribution". In my view the discussion has not
> > answered
> > > the questions and it is not clear to me what changes are proposed to
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> .
> > > I'm making the assumption that the proposal is to simplify the path for
> > > becoming a committer to grow the committer community. So far I have not
> > > heard what changes or simplifications are proposed. Without a change I
> > fail
> > > to see the benefit of this proposal to increase the number of
> committers.
> > > I agree that the path from committer to PMC member should be clarified
> as
> > > well and suggest to align with expectations and responsibilities of PMC
> > > members.
> > > I'm also under the assumption that the proposal only applies for future
> > > committers and PMC members, not for existing PMC members and this
> > > assumption should be clarified.
> > >
> > > Steffen
> > >
> > > On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier 
> > > wrote:
> > >
> > > > I believe the assumption has always been that current PMC members
> will
> > > > remain PMC members.
> > > >
> > > > On Wed, Oct 17, 2018 at 3:51 PM Michael Wall 
> wrote:
> > > >
> > > > > I too think separating committers from PMC is a good idea for your
> > > > project
> > > > > given the desire to grow committers and the concerns I have seen
> > trying
> > > > to
> > > > > add new committers.  I saw at least one other mentor, Jim on this
> > > thread
> > > > > too.
> > > > >
> > > > > Is the plan to leave all current PMC members in the PMC?  If that
> is
> > > not
> > > > > the plan, perhaps more discussion is required before moving on.
> > > > >
> > > > > Assuming you feel the discussion is done, someone needs to start a
> > > vote.
> > > > > This would be a procedural change as outlined on
> > > > > https://www.apache.org/foundation/voting.html
> > > > >
> > > > > If I were doing it, I would announce on this thread I am starting a
> > > vote
> > > > on
> > > > > this matter tomorrow or some specified time.  I might even outline
> > what
> > > > the
> > > > > vote will be.  This give people a chance to speak up if they think
> > more
> > > > 

Re: [Discussion] Separating PMC and Committership

[Chris Olivier]

IMHO it’s not a great idea to develop a hard criteria for committer and PMC
as if it were some sort of checklist. If that were the case, then people
would tend to be just laser-focused on checking items off the list rather
than a bonafied drive to improve the product and the community.  It would
also make it difficult to consider other intangeables in the decision.


On Thu, Oct 18, 2018 at 5:43 AM Carin Meier  wrote:

> Thanks Micheal for making the process clearer to me. It helps quite a bit.
>
> Also thanks to Chris and Steffen for your clarification and input.
>
> I think there are two issues that are intermingled in considering this. One
> relates to separating levels of committer and PMC member. The other, as
> Steffen pointed out, relates to the criteria which we use to consider
> people for these levels of membership. I would propose that to make it
> easier to achieve consensus, we consider them each as their own proposal.
>
> The proposal of separating levels of committer and PMC member can be
> considered on the Apache definitions of rights and responsibilities here
> https://www.apache.org/foundation/how-it-works.html#roles: Since the PMC
> member has more rights and responsibilities than a committer, I think it
> implies a stricter criteria, (although it would be unspecified in the
> proposal).
>
> The proposal of redefining our project's criteria in respect to how we
> consider nomination to those roles could be a separate discussion and vote
> since there are other issues that we might want to tackle such as inclusion
> of non-code contributions and general alignment to the Apache definitions.
>
> We can of course choose to tackle the proposal of redefining the criteria
> first or do the separation of levels first since the discussion is already
> in progress.
>
> Thoughts?
>
> - Carin
>
>
>
>
>
>
> On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel 
> wrote:
>
> > Haibin's proposed "For active contributors we first invite them to become
> > our committers. Later on as they make significant contribution, we can
> > invite them to PMC."
> > Several people raised the question what defines "active contributors" and
> > "make significant contribution". In my view the discussion has not
> answered
> > the questions and it is not clear to me what changes are proposed to
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer .
> > I'm making the assumption that the proposal is to simplify the path for
> > becoming a committer to grow the committer community. So far I have not
> > heard what changes or simplifications are proposed. Without a change I
> fail
> > to see the benefit of this proposal to increase the number of committers.
> > I agree that the path from committer to PMC member should be clarified as
> > well and suggest to align with expectations and responsibilities of PMC
> > members.
> > I'm also under the assumption that the proposal only applies for future
> > committers and PMC members, not for existing PMC members and this
> > assumption should be clarified.
> >
> > Steffen
> >
> > On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier 
> > wrote:
> >
> > > I believe the assumption has always been that current PMC members will
> > > remain PMC members.
> > >
> > > On Wed, Oct 17, 2018 at 3:51 PM Michael Wall  wrote:
> > >
> > > > I too think separating committers from PMC is a good idea for your
> > > project
> > > > given the desire to grow committers and the concerns I have seen
> trying
> > > to
> > > > add new committers.  I saw at least one other mentor, Jim on this
> > thread
> > > > too.
> > > >
> > > > Is the plan to leave all current PMC members in the PMC?  If that is
> > not
> > > > the plan, perhaps more discussion is required before moving on.
> > > >
> > > > Assuming you feel the discussion is done, someone needs to start a
> > vote.
> > > > This would be a procedural change as outlined on
> > > > https://www.apache.org/foundation/voting.html
> > > >
> > > > If I were doing it, I would announce on this thread I am starting a
> > vote
> > > on
> > > > this matter tomorrow or some specified time.  I might even outline
> what
> > > the
> > > > vote will be.  This give people a chance to speak up if they think
> more
> > > > discussion is needed.  Assuming no more discussion, start a [VOTE]
> > thread
> > > > on the dev list.
> > > >
> > > > I am used to seeing [VOTE] and [DISCUSS] in the subject line of such
> > > emails
> > > > but I didn't find any official guidance on that.  Maybe it is a
> project
> > > by
> > > > project decision, I did find
> > > >
> > https://cwiki.apache.org/confluence/display/EDGENT/Sample+process+emails
> > > .
> > > > I totally parsed right over the [Discussion] in the subject this
> thread
> > > but
> > > > I'll be on the look out for it in the future.
> > > >
> > > > Thanks
> > > >
> > > > Mike
> > > >
> > > > On Wed, Oct 17, 2018 at 6:05 PM Carin Meier 
> > > wrote:
> > > >
> > > > > Let me rephrase the question.
> > > > >
> > > > > 

Re: [Discussion] Separating PMC and Committership

[Carin Meier]

Thanks Micheal for making the process clearer to me. It helps quite a bit.

Also thanks to Chris and Steffen for your clarification and input.

I think there are two issues that are intermingled in considering this. One
relates to separating levels of committer and PMC member. The other, as
Steffen pointed out, relates to the criteria which we use to consider
people for these levels of membership. I would propose that to make it
easier to achieve consensus, we consider them each as their own proposal.

The proposal of separating levels of committer and PMC member can be
considered on the Apache definitions of rights and responsibilities here
https://www.apache.org/foundation/how-it-works.html#roles: Since the PMC
member has more rights and responsibilities than a committer, I think it
implies a stricter criteria, (although it would be unspecified in the
proposal).

The proposal of redefining our project's criteria in respect to how we
consider nomination to those roles could be a separate discussion and vote
since there are other issues that we might want to tackle such as inclusion
of non-code contributions and general alignment to the Apache definitions.

We can of course choose to tackle the proposal of redefining the criteria
first or do the separation of levels first since the discussion is already
in progress.

Thoughts?

- Carin






On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel 
wrote:

> Haibin's proposed "For active contributors we first invite them to become
> our committers. Later on as they make significant contribution, we can
> invite them to PMC."
> Several people raised the question what defines "active contributors" and
> "make significant contribution". In my view the discussion has not answered
> the questions and it is not clear to me what changes are proposed to
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer .
> I'm making the assumption that the proposal is to simplify the path for
> becoming a committer to grow the committer community. So far I have not
> heard what changes or simplifications are proposed. Without a change I fail
> to see the benefit of this proposal to increase the number of committers.
> I agree that the path from committer to PMC member should be clarified as
> well and suggest to align with expectations and responsibilities of PMC
> members.
> I'm also under the assumption that the proposal only applies for future
> committers and PMC members, not for existing PMC members and this
> assumption should be clarified.
>
> Steffen
>
> On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier 
> wrote:
>
> > I believe the assumption has always been that current PMC members will
> > remain PMC members.
> >
> > On Wed, Oct 17, 2018 at 3:51 PM Michael Wall  wrote:
> >
> > > I too think separating committers from PMC is a good idea for your
> > project
> > > given the desire to grow committers and the concerns I have seen trying
> > to
> > > add new committers.  I saw at least one other mentor, Jim on this
> thread
> > > too.
> > >
> > > Is the plan to leave all current PMC members in the PMC?  If that is
> not
> > > the plan, perhaps more discussion is required before moving on.
> > >
> > > Assuming you feel the discussion is done, someone needs to start a
> vote.
> > > This would be a procedural change as outlined on
> > > https://www.apache.org/foundation/voting.html
> > >
> > > If I were doing it, I would announce on this thread I am starting a
> vote
> > on
> > > this matter tomorrow or some specified time.  I might even outline what
> > the
> > > vote will be.  This give people a chance to speak up if they think more
> > > discussion is needed.  Assuming no more discussion, start a [VOTE]
> thread
> > > on the dev list.
> > >
> > > I am used to seeing [VOTE] and [DISCUSS] in the subject line of such
> > emails
> > > but I didn't find any official guidance on that.  Maybe it is a project
> > by
> > > project decision, I did find
> > >
> https://cwiki.apache.org/confluence/display/EDGENT/Sample+process+emails
> > .
> > > I totally parsed right over the [Discussion] in the subject this thread
> > but
> > > I'll be on the look out for it in the future.
> > >
> > > Thanks
> > >
> > > Mike
> > >
> > > On Wed, Oct 17, 2018 at 6:05 PM Carin Meier 
> > wrote:
> > >
> > > > Let me rephrase the question.
> > > >
> > > > Since I'm new to the committer/PMC process, I wondering what the next
> > > step
> > > > is in a proposed change of process like this.
> > > >
> > > > If we gauge that there is a significant enough interest do we
> propose a
> > > > vote? Is there enough interest and information to have a vote in this
> > > case?
> > > >
> > > > (Anyone feel free to answer the question - mentor or not :) )
> > > >
> > > > - Carin
> > > >
> > > > On Tue, Oct 16, 2018 at 7:48 PM Carin Meier 
> > > wrote:
> > > >
> > > > > This has been a very interesting discussion and I think it
> > underlined a
> > > > > desire to increase the committer pool and community for th

Re: Include MKLDNN into default mxnet pip package

[Pedro Larroy]

Very nice! 

Pedro

> On 17. Oct 2018, at 23:12, Alfredo Luque  
> wrote:
> 
> This is huge. Thanks for working on this. Is there a similar plan with eg;
> tensor-rt support being ported into the main cuda-9.x packages?
> 
> On October 17, 2018 at 2:10:20 PM, Alex Zai (aza...@gmail.com) wrote:
> 
> Hey all,
> We have been working hard these past few months to integrate and stabilize
> Intel’s MKLDNN deep learning CPU accelerator into Mxnet and have made
> incredible progress. On CPUs with AVX512 instructions (such as c5.18x) we
> have seen performance increase up to 12x and on other platforms (Macs,
> AVX2) we seen a speedup of 1.5+. Full list of benchmarks can be found here
> (
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95650764
> and https://github.com/apache/incubator-mxnet/pull/12591).
> 
> Currently, using this accelerator requires the developer to either pip
> install the mxnet-mkl version of mxnet or to build it themselves from
> source. Given that we should try to provide the best performance "out of
> the box” with mxnet we should include this in the default build. The mkldnn
> library is included with in the pip package build so it does not require an
> external dependency.
> 
> There were concerns that MKLDNN could cause regressions on certain
> platforms (as it did with the tensorflow version a while back); but we
> added a env flag (MXNET_MKLDNN_ENABLED) that allows users to turn of this
> feature during runtime. Please bring up any other concerns you may have and
> your thoughts on including this accelerator in the default build.
> 
> Best,
> Alex
> 
> —
> Alfredo Luque
> Software Engineer
> Machine Learning Infrastructure
> Airbnb
> San Francisco, CA

RE: Include MKLDNN into default mxnet pip package

[Zhao, Patric]

Thanks Alex for bringing up this proposal. As far as I know, applied to the 
MKL-DNN backend, MXNet is the most performant framework on CPU side now. 
Especially that the recent subgraph fusion feature boosts the performance a lot 
again. 
Thus, I think it’s worth to make it default and let more users leverage the 
benefits of it.

Regarding MKL-DNN integration, it’s a joint work and takes lots of effort from 
Amazon and Intel engineers, including Da, Jun, Haibin, Junyuan, Sheng, Marco, 
Chris (AWS) and Patric, Tao, Wenting, Rong , Jin, Shufan, Ashok (Intel).
We also got many great suggestions from MXNet community and learned much from 
those discussions. Here I personally want to appreciate Da Zheng for his great 
efforts in this project. 
As the main contributor, he plays an important role in the project, from the 
initial co-design, implementations to recent advanced subgraph feature and 
finally makes these good things happen.

I would like to thank Alex for stabilizing MKL-DNN backend by adding more tests 
for it and also environment variables so the user can switch between the 
original flow and MKL-DNN flow easily. 
His efforts are really helpful for pushing MKL-DNN backend from experimental 
toward GA.

MXNet community is one of the best groups and there're many intelligent people 
here. 

Thank you all for the strong support.

--Patric 

> -Original Message-
> From: Jun Wu [mailto:wujun@gmail.com]
> Sent: Thursday, October 18, 2018 6:29 AM
> To: dev@mxnet.incubator.apache.org
> Cc: d...@mxnet.apache.org; aza...@gmail.com
> Subject: Re: Include MKLDNN into default mxnet pip package
> 
> If my understanding is correct about the context, it should be acknowledged
> that the significant performance improvement comes from the Intel
> MKLDNN team's contribution in this PR:
> https://github.com/apache/incubator-mxnet/pull/12530.
> 
> On Wed, Oct 17, 2018 at 3:12 PM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
> 
> > First of all thanks to Intel for these improvements, really a great effort.
> >
> > What would the compatibility story look like for users that don't have
> > these AVX instructions?  Would there be any negative affect for AMD users?
> >
> > Regarding TensorRT: It's a possibility but not planned in the short
> > term. A few considerations would be the limits on PyPi package sizes
> > and the bloat incurred with TRT, the requirements of TRT to be
> > installed on the user side, and the TRT engine build times which are
> > non-trivial.  We can work towards fixing or working around these
> > issues in the future if default TRT is something the user community
> > would like to see for Cuda packages.  While the feature is
> > experimental we'll likely continue to use 'mxnet-tensorrt-cu92' and
> 'mxnet-tensorrt-cu90'.
> >
> > On Wed, Oct 17, 2018 at 2:12 PM Alfredo Luque
> >  wrote:
> >
> > > This is huge. Thanks for working on this. Is there a similar plan
> > > with
> > eg;
> > > tensor-rt support being ported into the main cuda-9.x packages?
> > >
> > > On October 17, 2018 at 2:10:20 PM, Alex Zai (aza...@gmail.com) wrote:
> > >
> > > Hey all,
> > > We have been working hard these past few months to integrate and
> > stabilize
> > > Intel’s MKLDNN deep learning CPU accelerator into Mxnet and have
> > > made incredible progress. On CPUs with AVX512 instructions (such as
> > > c5.18x) we have seen performance increase up to 12x and on other
> > > platforms (Macs,
> > > AVX2) we seen a speedup of 1.5+. Full list of benchmarks can be
> > > found
> > here
> > > (
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95650
> > 764
> > > and https://github.com/apache/incubator-mxnet/pull/12591).
> > >
> > > Currently, using this accelerator requires the developer to either
> > > pip install the mxnet-mkl version of mxnet or to build it themselves
> > > from source. Given that we should try to provide the best
> > > performance "out of the box” with mxnet we should include this in
> > > the default build. The
> > mkldnn
> > > library is included with in the pip package build so it does not
> > > require
> > an
> > > external dependency.
> > >
> > > There were concerns that MKLDNN could cause regressions on certain
> > > platforms (as it did with the tensorflow version a while back); but
> > > we added a env flag (MXNET_MKLDNN_ENABLED) that allows users to
> turn
> > > of this feature during runtime. Please bring up any other concerns
> > > you may have
> > and
> > > your thoughts on including this accelerator in the default build.
> > >
> > > Best,
> > > Alex
> > >
> > > —
> > > Alfredo Luque
> > > Software Engineer
> > > Machine Learning Infrastructure
> > > Airbnb
> > > San Francisco, CA
> > >
> >