Need to include a fix for the test error
https://github.com/apache/incubator-mxnet/pull/15921#pullrequestreview-328686634
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
please answer the questions in my last email regarding the suspected issue
in mxnet as well as on that PR you opened.
On Sun, Dec 8, 2019 at 7:00 PM Lausen, Leonard
wrote:
> The assertion failure in the MXNet DEBUG build goes away by updating LLVM
> OpenMP
> to the latest released version. All
Thanks Chris for the elaboration.
> What the assert in question is trying to say is that mxnet code is calling
> into omp library after a fork, but before the omp library’s atfork()
> handler is called, so the omp library has not yet initialized a new team if
> threads. This looks to be the case
I agree with Marco that we should build as part of the Jenkins CD. Thanks Sam
and everyone involved to get an intermediate proprietary solution set-up, that
can ease developers lives.
When setting up the Jenkins CD, I suggest we use CMake to build the releases,
given the recent progress to
From Shanghai, the closest endpoint (automatically chosen endpoint) is in Tokyo
and download speed for mxnet-mkl was on average 1.7 MB/s with a maximum of 5
MB/s during my test.
On Sun, 2019-12-08 at 01:30 +, Sheng Zha wrote:
> > Heres a set of links for today’s builds
> >
> > (Plain mxnet,
Great investigation thank you. I have to agree with your analysis and for
helping resolving this long standing issue.
This will not repair the damage made to the community of losing 3-4
valuable contributors. Introducing a library that causes bugs then blocking
changes and locking gh issues which
Hi Leonard.
Are you saying that you have updated this library and the problems desribed
in the related tickets are no longer present?
P.
On Sunday, December 8, 2019, Lausen, Leonard
wrote:
> Thanks Pedro and Chris for your responses.
>
> After further investigation I find:
>
> 1) I don't think
This is actually useful information, thanks.
Still I don't see a justificqtion for vetoing being able to choose the
library at compile time. Fixing the issue you reasonably describe and being
able to choose are two orthogonal topics.
Thanks for the constructive information.
On Sunday, December
Thanks Ciyong,
Absolutely! Heres how a backward function is registered [1] and here’s an
example backward function for GEMM [2]. We’ll be working on documentation and a
blog post/tutorial soon, hopefully that will help clarify things as well.
Keep the questions coming!
Thanks,
Sam
[1]
Thanks Sheng,
Looks like 12/8 builds are working as expected too:
(Plain mxnet, no mkl no cuda)
https://repo.mxnet.io/dist/2019-12-08/dist/mxnet-1.6.0b20191208-py2.py3-none-manylinux1_x86_64.whl
(mxnet-mkl)
btw the call stack I am referring to below is the one where I explained
this problem before and after I got a hostile response, I locked the issue.
On Sun, Dec 8, 2019 at 7:24 AM Chris Olivier wrote:
> Again, here is what I suspect the bug is in mxnet:
>
> The way that advanced openmp libraries
Again, here is what I suspect the bug is in mxnet:
The way that advanced openmp libraries handle a fork is that they hook an
atfork() callback in which, in the new process, it creates a new “team” of
threads to use for its thread pool (since all of the thread handles in its
data structure belong
Thanks Pedro and Chris for your responses.
After further investigation I find:
1) I don't think https://github.com/apache/incubator-mxnet/issues/14979 is
caused by any incompatibility between gomp and llvm / intel omp. Rather it's
simply a problem of llvm / intel omp. See my comment to the issue
13 matches
Mail list logo
