Dear MXNet community,
This is the 3-day vote to release Apache MXNet (incubating) version 1.5.0.
Voting on dev@ will start June 19, 23:59:59(PST) and close on June 22,
23:59:59.
1) Link to release notes:
https://cwiki.apache.org/confluence/display/MXNET/1.5.0+Release+Notes
2) Link to release c
"if you’re linking in two then you’re doing something wrong." Correct,
that's one thing I believe we've got consensus on. So let's call that out
as a bug to be fixed.
Let's move forward with some reproducible numbers and then discuss the pros
/ cons of which particular OMP implementation we shoul
Hi Chris
I would ask you to have a bit of patience and help us with your
experience in this matter. Nobody is ignoring anything, I think we are
individually gathering feedbacks and trying to understand the multiple
contributions done to this topic including yours, then go step by
step, understand
if you’re linking in two then you’re doing something wrong. You can see by
my email yesterday that only one is linked in. This is also the case with
the mkl version built by the Makefile — only the Intel OMP library is used
(no libgomp).
That being said, Do you have clear evidence that using Intel
+1 Would be best to have a controlled environment so we can reason
about how MXNet is being built and what libraries are linked. I'm
happy to help here. I would think docker won't have a big impact on
the measurement or distort the results much.
On Wed, Jun 19, 2019 at 10:28 AM kellen sunderland
I've also quite often seen two versions of OpenMP linked. I think we can
all agree we probably want to avoid linking in two libraries that do
effectively the same thing.
The performance questions should be fairly straight forward to demonstrate
right? Could we just collaborate on a few minimal D
Let's cancel this vote for now and move the OMP conversation to a
discuss thread as suggested here in order not to antagonize anyone.
Let's find the best solution, this is not about one upping anyone but
to gather facts and document what's going on.
Chris, would you be so kind to reopen the PR so
Just double checked CUDA 9, 10 and 10.1 all support SM3, so actually I
don't believe there's any need to drop SMs.
On Wed, Jun 19, 2019 at 9:56 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> I think where we're all going to have agreement is that we shouldn't have
> code targeting C
I think where we're all going to have agreement is that we shouldn't have
code targeting CUDA versions earlier than CUDA 9, or cuDNN versions earlier
than 6. We can go ahead and remove any code that targets those old
versions, and drop any SMs that are not supported by CUDA 9 / cuDNN 6. Id
sugges
Hi, Chris!
Stas here - I've gathered that performance data.
Sure thing, I can be wrong, but please elaborate a bit on what we are missing.
Be assured, intentional misdirection was never a case.
Thanks a lot for being constructive.
> Turning Intel OMP on and off (and MKL as well, since it tends
Good points anirudh. Generally I would understand N as being the major
versions. Speak we would maintain CUDA 9 and 10.1 in your given example and
drop 10.0 as soon as we verified that 10.1 is working. CUDA 9 would only be
dropped when 11 is released and tested.
At the same time, we would always o
11 matches
Mail list logo
