We are now waiting for a committer's review and merge.
ср, 22 мая 2019 г. в 22:14, Pedro Larroy :
> Thanks Aaron and Anton! Can we rebase to update the PR? Let me know
> how can I help further if you find some problems.
>
> On Wed, May 22, 2019 at 6:49 AM Aaron Markham
> wrote:
> >
> > I reop
Great! Thank you, Aaron. I have rebased it.
ср, 22 мая 2019 г. в 15:49, Aaron Markham :
> I reopened it for you.
>
> On Wed, May 22, 2019, 05:25 Anton Chernov wrote:
>
> > I don't have necessary rights to reopen this PR.
> >
> > пн, 20 мая 2019 г. в 08:00, Pedro Larroy :
> >
> > > Hi Anton, Stas
Thanks Aaron and Anton! Can we rebase to update the PR? Let me know
how can I help further if you find some problems.
On Wed, May 22, 2019 at 6:49 AM Aaron Markham wrote:
>
> I reopened it for you.
>
> On Wed, May 22, 2019, 05:25 Anton Chernov wrote:
>
> > I don't have necessary rights to reo
I reopened it for you.
On Wed, May 22, 2019, 05:25 Anton Chernov wrote:
> I don't have necessary rights to reopen this PR.
>
> пн, 20 мая 2019 г. в 08:00, Pedro Larroy :
>
> > Hi Anton, Stas.
> >
> > Can we reopen this PR and get it merged as per the data collected by
> Stas?
> >
> > https://git
I don't have necessary rights to reopen this PR.
пн, 20 мая 2019 г. в 08:00, Pedro Larroy :
> Hi Anton, Stas.
>
> Can we reopen this PR and get it merged as per the data collected by Stas?
>
> https://github.com/apache/incubator-mxnet/pull/12160
>
>
> https://cwiki.apache.org/confluence/display/M
Hi Anton, Stas.
Can we reopen this PR and get it merged as per the data collected by Stas?
https://github.com/apache/incubator-mxnet/pull/12160
https://cwiki.apache.org/confluence/display/MXNET/Benchmarking+MXNet+with+different+OpenMP+implementations
There are multiple issues that will be fixed
I would like to propose a possible alternative solution for consideration.
If keeping llvm OpenMP as a submodule is inevitable one could make
following adjustments:
Since compilers try to find their own OpenMP library implicitly, MXNet
needs to ensure that only the bundled version is found. There
Recent benchmarking results have been published here [1]. Experiments
compare different OpenMP implementations as well as binaries compiled with
different compilers including GCC, Clang and ICC.
During experimentation another issues with mixing up libraries was
identified and described here [2].
Hi Chris,
Following up on the issue, are all things resolved in the discussion?
If yes, I kindly ask you to reopen this PR and remove ‘requesting changes’
status:
https://github.com/apache/incubator-mxnet/pull/12160
Thank you.
Best
Anton
вт, 27 нояб. 2018 г. в 17:15, Anton Chernov :
> Anoth
Another thing to take into consideration:
All python artefacts that are created (PyPi) are built with make and are
not using the bundled OpenMP library.
One step for the switch to CMake to happen is the approval and merging of
the mentioned PR:
https://github.com/apache/incubator-mxnet/pull/1216
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 p
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 ca
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 me
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 ...
I'
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 beha
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 logic
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 bu
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 t
18 matches
Mail list logo
