Dear MXNet community,
I propose to raise the minimal required cmake version that is needed to
build MXNet to 3.10 which was tagged on March 16 2018 [1].
The effort of repairing cmake scripts in general is targeting to deprecate
make and maintain only 1 build system.
*Need*
The build system is
Dear MXNet community,
I would like to drive attention to an important issue that is present in
the MXNet CMake build: usage of bundled llvm OpenMP library.
I have opened a PR to remove it:
https://github.com/apache/incubator-mxnet/pull/12160
The issue was closed, but I am strong in my oppinion
Thanks for the great summary, Anton. I'm curious that is there anybody builds
mxnet successfully with ICC/ICPC?
-Original Message-
From: Anton Chernov [mailto:mecher...@gmail.com]
Sent: Thursday, November 22, 2018 8:36 PM
To: d...@mxnet.apache.org
Subject: [Discussion] Remove bundled
3x less overhead*
On Thu, Nov 22, 2018 at 6:25 AM Chris Olivier wrote:
> someone is doing something unhealthy when they fork, which is causing an
> assertion in the openmp library. the same assertion that would fire in mkl,
> which is linked to libiomp5 (exact same omp library). this is new
The proposal here is not to eliminate the use of OpenMP but rather to use
the compiler's OpenMP implementation rather than a bundled one. I've been
bitten by issues with having multiple linked OpenMP implementations before
in another library and it was extremely difficult to debug.
It seems to
Thanks Anton for putting this together and your efforts here. I think
it's crucial that we maintain and bring the CMake system forward. I
have spent a lot of time dealing with CMake issues on different
platforms, we really increase developer productivity and platform
support by having a
i have not seen any proof that any crashes are due to llvm openmp usage.
On Thu, Nov 22, 2018 at 2:35 AM Anton Chernov wrote:
> Dear MXNet community,
>
> I propose to raise the minimal required cmake version that is needed to
> build MXNet to 3.10 which was tagged on March 16 2018 [1].
>
> The
Hi Chris,
Thank you for your answer. If you have noticed the initial email comes from
me, Anton Chernov (@lebeg on Github) and thus the proposal is not from any
'Ci' team that you've mentioned, but from me personally.
You are writing:
> someone is doing something unhealthy when they fork ...
Thank you for you answer, Chris.
> The whole “mixing omp libraries” is something that occurs in production
every day and certainly in everything that uses mkl.
I'm afraid this statement is wrong. Intel MKL-DNN strictly ensures that
this mixture is not happening:
"Intel MKL-DNN uses OpenMP* for
You can find relevant information regarding the profiling flag here:
https://github.com/apache/incubator-mxnet/issues/11563
чт, 22 нояб. 2018 г. в 16:06, Chris Olivier :
> what is meant by:
>
>
> *Profiling*
> The profiler is always on even for production release builds, because MXNet
> can
yes that flag can be removed. profiler should always be. built in
On Thu, Nov 22, 2018 at 7:44 AM Anton Chernov wrote:
> You can find relevant information regarding the profiling flag here:
>
> https://github.com/apache/incubator-mxnet/issues/11563
>
>
> чт, 22 нояб. 2018 г. в 16:06, Chris
someone is doing something unhealthy when they fork, which is causing an
assertion in the openmp library. the same assertion that would fire in mkl,
which is linked to libiomp5 (exact same omp library). this is new behavior
and most likely due to an error or suboptimal approach in the forking
Do you not work on CI mostly? My apologies for thinking that was some sort
of team effort between you and a few others that were passionate about CI
keeping the CI system running smoothly.
You have source code, you have the line the assertion is on. If you can’t
describe what’s going wrong that
Thanks everybody, I really appreciate it!
Today was a good day, there were no incidents and everything appears to be
stable. In the meantime I did a deep dive on why we has such a significant
performance decrease with of our compilation jobs - which then clogged up
the queue and resulted in 1000
added
On Thu, Nov 22, 2018 at 9:11 AM Vishaal Kapoor
wrote:
> Switched e-mails. Thanks!
> VIshaal
>
Thanks for bringing this up, Marco. It's really weird since most of those tests
listed in "worth noting" are not related to mkldnn backend.
I can understand that some tests for mkldnn operator may be slower because
MXNET_MKLDNN_DEBUG is enabled in the CI:
Good point, Tao!
Is this env enabled in all MKL-DNN CI?
> -Original Message-
> From: Lv, Tao A [mailto:tao.a...@intel.com]
> Sent: Friday, November 23, 2018 9:53 AM
> To: dev@mxnet.incubator.apache.org
> Subject: RE: MKLDNN performance in CI
>
> Thanks for bringing this up, Marco. It's
Thanks, it should be the most time-consuming parts.
@Marco, could you try to disable this env and see the performance again?
> -Original Message-
> From: Lv, Tao A [mailto:tao.a...@intel.com]
> Sent: Friday, November 23, 2018 10:26 AM
> To: dev@mxnet.incubator.apache.org
> Subject: RE:
Hello,
I have noticed that our Python tests have been increasing in duration
recently. In order to analyse this further, I created the PR [1] which
allows to record test durations. Please note that I did not dive deep on
these numbers and that they have to be taken with a grain of salt since
Happy Thanksgiving, everyone :)
Hi Marco,
Thanks to raising this question. We will look into the details for CI test
cases and Shufan will provide the 1:1 OP level performance data.
In general, the CI tests is not performant cases which covered the different
situations, even corner cases, for
I think yes, except the cpp test.
-Original Message-
From: Zhao, Patric [mailto:patric.z...@intel.com]
Sent: Friday, November 23, 2018 10:06 AM
To: dev@mxnet.incubator.apache.org
Subject: RE: MKLDNN performance in CI
Good point, Tao!
Is this env enabled in all MKL-DNN CI?
>
Okay, that makes sense. Thanks for the very detailed explanation!
Don't worry about speed in CI, especially the debug flag might be the
reason here. But I'm happy to leave it in since the task of CI is accuracy
and detailed reporting, but not speed :)
I just wanted to give a quick heads up in
Sure, good idea! https://github.com/apache/incubator-mxnet/pull/13379
-Marco
On Fri, Nov 23, 2018 at 3:38 AM Zhao, Patric wrote:
> Thanks, it should be the most time-consuming parts.
>
> @Marco, could you try to disable this env and see the performance again?
>
> > -Original Message-
>
23 matches
Mail list logo
