Re: CUDA / CUDNN support revisited

2019-06-19 Thread kellen sunderland
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

Re: OMP

2019-06-19 Thread 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

Re: OMP

2019-06-19 Thread Pedro Larroy
+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

Re: CUDA / CUDNN support revisited

2019-06-19 Thread kellen sunderland
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

Re: [VOTE] Remove conflicting OpenMP from CMake builds

2019-06-19 Thread Pedro Larroy
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

Re: CUDA / CUDNN support revisited

2019-06-19 Thread Marco de Abreu
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

Re: OMP

2019-06-19 Thread Tsukrov, Stanislav
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

Re: OMP

2019-06-19 Thread Chris Olivier
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

Re: OMP

2019-06-19 Thread Pedro Larroy
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

Re: OMP

2019-06-19 Thread kellen sunderland
"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