30 comments

[ 2.3 ms ] story [ 77.8 ms ] thread
Just got it working in docker hahaha.
I don't think docker supports GPU acceleration on windows. The linux subsystem doesn't have access to the GPU (CUDA).
Would Docker care? I had it running on an older Windows box for giggles using VirtualBox and the VM saw the AMD GPU once I adjusted the configs.

The VirtualBox VM for Docker is configured to run like mud.

Fantastic news! Previously, Windows users had to install and set up Docker (which involves setting up a virtual machine) to get it working. That took me nearly a day to get it all configured (thanks to complicated proxy settings at work).

And even then, there wasn't a good way for Tensorflow in a Docker container in a virtual machine to access the GPU.

I'm excited about this release!

If you're using a Virtual Machine, why would you need Docker? I think you can get GPU acceleration in a VM.
I think there is no PCIe passthrough for Windows hosts on Virtualbox, and that's required for using CUDA on a VM. You can get graphics acceleration on a VM under any kind of host, but it uses a virtual graphics card from Virtualbox instead of your actual card, so it does not work with CUDA.
This is correct, Linux works much. After for PCIe passthrough in VMs, both Virtualbox and VMware.

Very glad it's now on Windows though! Time to tinker once again.

Tensorflow also runs fine in Bash on Windows, although without GPU acceleration.
Yep, tensorflow was actually the reason I tried WSL. In my case, compiling tensorflow in WSL is also a lot faster than doing the same in Windows with CMake/MSBuild.
What you saved in compile time, you lost in runtime if you have a GPU.
does this have cuda support?
There's a link around here somewhere to an article that tells you. ;)
there is indeed. my comment was truly superfulous
Yes. The prebuilt binaries can be used with GPUs that support CUDA 8.0 and have compute capability 3.5 or 5.2. The package is now in PyPI, so you can install the latest version with `pip install tensorflow-gpu`.
I waited for over a year for Windows support and even tried using Windows subsystem for Linux(beta) in the anniversary update(It is a nightmare to develop on my files & repos were literaly dissappearing with out a trace).

No Thanx. My dualboot with Ubuntu works just fine.

I compiled it this weekend. It's based on CMake, MSBuild, and VC++. You just have to install the CMake, Visual C++, CUDA and CUDNN libraries, run cmake and then msbuild.

Performance is similar to what I see on the same machine in linux.

Note that the Windows version in PyPI seems to be for 64-bit Python only.
Finally, no more docker!
As someone who is stuck with a Windows at work, I love how Google is listening to what developers have to say.

TensorFlow has the potential of being the next big thing. You'd never see other companies (Microsoft for example) port their crown jewels like halo over to other systems. They begrudgingly port products in which they've lost market share to other rivals, mostly in an effort to appear relevant.

I do think the "Don't be evil" mantra is still alive.

Yeah I mean it's not like Microsoft has an open source innovative (more so than Tensorflow) deep learning toolkit...

https://github.com/microsoft/cntk

And it also runs on Linux, by the way.
What is more innovative about CNTK? I mostly use Keras on TF, but am interested in your thoughts.
Well apart from the 1-bit multi-GPU SGD (which isn't totally free unfortunately), the main thing is BrainScript (formerly the Network Description Language). This is a DSL that lets you define the neural network as a computational network (which is what it is) but also lets you trivially make it recurrent by using `x = PreviousValue(y)` and `x = FutureValue(y)`. CNTK then works out which subset of the network is recurrent and only unwraps that bit.

Other systems like Torch and Tensorflow generally only provide pre-defined recurrent layers, like LSTM and GRU. If you want to make your own you have to deal with a gaping hole in the documentation, and extremely hacky ways of defining recurrence which I honestly never worked out. CNTK makes it trivial.

I don't think acting out of self-interest (e.g. porting to get more developer interest) implies that the "Don't be evil" mantra is still alive (not sure if this is what you meant in your post, maybe it's just how I read it).

Maybe it goes without saying but Google really wants their framework to be THE framework for doing machine learning because it has so many benefits for them. For example, if you have the best ecosystem/framework for doing ML, chances are any newcomers to the field (some of whom will later be experts) will gain familiarity with it, which would make the hiring situation for your ML team much better.

Regardless, I'm in the same situation as you w.r.t. Windows at work and have the same reaction (love it and have been waiting for the port).

Only that the port is the result of several months of work in Microsoft which was contributed to TF.
Are you sure? I think most of the port work was done by a couple of Google developers.
Nice, I was just fixing some of their CMake configuration recently (still waiting for my other PR to be merged though)
From the changelog:

https://github.com/tensorflow/tensorflow/releases

> TensorFlow now builds and runs on Microsoft Windows (tested on Windows 10, Windows 7, and Windows Server 2016). Supported languages include Python (via a pip package) and C++. CUDA 8.0 and cuDNN 5.1 are supported for GPU acceleration. Known limitations include: It is not currently possible to load a custom op library. The GCS and HDFS file systems are not currently supported. The following ops are not currently implemented: DepthwiseConv2dNative, DepthwiseConv2dNativeBackpropFilter, DepthwiseConv2dNativeBackpropInput, Dequantize, Digamma, Erf, Erfc, Igamma, Igammac, Lgamma, Polygamma, QuantizeAndDequantize, QuantizedAvgPool, QuantizedBatchNomWithGlobalNormalization, QuantizedBiasAdd, QuantizedConcat, QuantizedConv2D, QuantizedMatmul, QuantizedMaxPool, QuantizeDownAndShrinkRange, QuantizedRelu, QuantizedRelu6, QuantizedReshape, QuantizeV2, RequantizationRange, and Requantize.

The best news in weeks - I've been shuttling my Jupyter notebooks between my work-provided Windows m/c and personal macbook just to be able to work on Tensorflow/keras.

Like others have pointed out already, the virtual machine route is just too laggy, even on high-memory machines.