News for hackers. Stuff that matters.
Re:NVIDIA GeForce driver deployment in datacenters is forbid... by nl on Monday December 25, 2017 @12:37AM (#16002842)
OpenCL doesn't have an equivalent to CuDNN.

I'm not saying it's a great situation, I'm saying that NVidia has always had better libraries, tools and performance, and it isn't surprising that developers use them.

Deep learning is hard and slow enough without using second class tools.

Re:NVIDIA GeForce driver deployment in datacenters is forbid... by hedgehog on Monday December 25, 2017 @01:05AM (#16002928)
Much respect to NVIDIA and their software team but the situation is changing. PlaidML is like cuDNN for every GPU. Fully open source, faster in many cases than TF+cuDNN on NVIDIA, beats vendor tools on other architectures, Linux/Mac/Win. Supports Keras currently but more frameworks are not difficult (patches welcome).
Re:NVIDIA GeForce driver deployment in datacenters is forbid... by argonaut on Monday December 25, 2017 @03:17AM (#16003283)
The PlaidML benchmarks are suspect. They compare to Keras + Tensorflow, which is a really unfair comparison since 1) Tensorflow is probably the slowest of the big deep learning frameworks out there (compared to PyTorch, MXNet, etc.), and 2) Keras itself is quite slow. Keras is optimized more for ease of use, introduces lots of abstractions, and often doesn't take advantage of many TF optimizations, (for just one example until very recently Keras did not use TF's fused batch norm, which the TF docs claim provides a 10-30% speedup in overall network performance, which alone could be enough to account for many of the benchmarks showing PlaidML ahead).
Re:NVIDIA GeForce driver deployment in datacenters is forbid... by hedgehog on Monday December 25, 2017 @03:54AM (#16003381)
In my opinion it's extremely fair. The benchmarks are Keras+PlaidML compared to Keras+TensorFlow, it allows running exactly the same nets (just imported from the Keras included applications) and whatever penalty Keras might impose is equal in the two cases. Having one very direct comparison is actually why we constructed the tests that way (none of the other frameworks run on our high priority platforms).

That said we'd be pretty excited if someone wanted to add support for TF, PyTorch, MXNet, etc. We like Keras but are happy to have integrations for all frameworks. With work you could pair it with Docker and containerize GPU-accelerated workloads without the guests even needing to know what hardware it's running on. Lots of possibilities.

Re:NVIDIA GeForce driver deployment in datacenters is forbid... by argonaut on Monday December 25, 2017 @06:23AM (#16003719)
No, no, no.

> whatever penalty Keras might impose is equal in the two cases.

The penalty Keras imposes when using Tensorflow depends on its Tensorflow implementation. The penalty Keras imposes when using MXNet depends on its MXNet implementation. The penalty Keras imposes when using PlaidML depends on whatever the PlaidML devs implemented. When you build a Keras layer, it's calling different Keras code for each backend.

The comparison would be fair if Plaid claimed to be the fastest Keras backed, not if it were actually claiming to be faster than Tensorflow.

Re:NVIDIA GeForce driver deployment in datacenters is forbid... by nl on Monday December 25, 2017 @05:00AM (#16003515)
There was someone on reddit/ml who posted some pretty interesting numbers for training.

I think they have a lot of challenges ahead of them, but I’m still more optimistic about Plaid than AMD’s own efforts.

AMD says that they don’t care about ML[1], and their actions back that up.

Edit: and to be clear, I think comparing Keras+Plaid vs Keras+TF is an entirely valid thing to do. Lots of people work in Keras, and if you download a random NN code off github it likely to be Keras (or Pytorch now of course).

[1] https://www.reddit.com/r/MachineLearning/comments/66bgmf/com...

Re:NVIDIA GeForce driver deployment in datacenters is forbid... by ekelsen on Monday December 25, 2017 @02:09AM (#16003114)
PlaidML seems entirely geared towards inference (I only see batch size 1 anywhere). Training is important.
Re:NVIDIA GeForce driver deployment in datacenters is forbid... by hedgehog on Monday December 25, 2017 @03:36AM (#16003335)
Batch 1 inference on convnets is key for us internally but training does work pretty well. The underlying machinery can do much more. Here's a blog post that talks about how it works with some links to more detailed docs & the actual implementations:

http://vertex.ai/blog/tile-a-new-language-for-machine-learni...

Two of the big motivators for opening the code were 1) giving students taking the popular courses a way to get started with GPU in whatever machine they've got (recent Intel GPUs in say a MacBook Air are enough) and 2) giving researchers a platform where it's simple to add efficient GPU-accelerated ops.

For scale on #2 check out the entire implementation of convolution:

https://github.com/plaidml/plaidml/blob/master/plaidml/keras...

Re:NVIDIA GeForce driver deployment in datacenters is forbid... by nl on Monday December 25, 2017 @01:18AM (#16002978)
PlaidML is very promising I agree.
Re:NVIDIA GeForce driver deployment in datacenters is forbid... by tgtweak on Monday December 25, 2017 @01:03AM (#16002922)
> Amd does have a cudnn equivalent called MlOpen.
Re:NVIDIA GeForce driver deployment in datacenters is forbid... by nl on Monday December 25, 2017 @01:18AM (#16002975)
MIOpen could be great one day. ATM you still get random problems like this: https://github.com/ROCmSoftwarePlatform/MIOpen/issues/19

That's an order of magnitude worse performance than NVidia on ResNet 52 for 2 months with no real reason.

Great idea, but no one can use it reliably yet.