The Neural Doodle tool (https://github.com/alexjc/neural-doodle), which appeared on HN a couple months ago (https://news.ycombinator.com/item?id=11257566), is very difficult to set up without errors. Meanwhile, the included Docker container (for the CPU implementation) can get things running immediately after a 311MB download, even on Windows which otherwise gets fussy with machine learning libraries. (I haven't played with the GPU container yet, though)
Nvidia also has an interesting implementation of Docker which allows containers to use the GPU on the host: https://github.com/NVIDIA/nvidia-docker
- install the nvidia drivers, cuda and cudnn which all come as ubuntu packages.
- use anaconda for python
- conda install theano
- pip install tensorflow as per the website
- pip install keras
And voilà, I got my keras models running on my shinny new GTX 980.
Using Cuda packages results in Theano not working.
Is there a motivation for anaconda other than "it includes the stuff we usually need"? It strikes me as somewhat strange that anaconda is so often recommended but it forces a divergence from using the mainline packages with vanilla Python.
Anaconda does not force a "divergence" from using anything. You can still build and pip install to your heart's delight. It just provides a baseline of the more complex-to-build packages, all built in such a way as to be compatible with each other at the C level.
Cuda on the other hand is annoying because you have to both make sure the driver works with multiscreen setups and that cuda links against that driver correctly and uses a specific gcc version.
Pip and wheels are still not really suitable for scientific Python work, because the metadata facilities are not sufficiently rich to capture all the information needed for proper linking of native libraries. By contrast, in Anaconda, things like MKL linkage and Fortran compiler information can be used in the package metadata for dependency solving, to minimize these kinds of compatibility issues.
In terms of making these packages easier to build, that's really not actually where the problem is. The fact that numpy, scipy, cython, etc. need to have a shared compiler and build toolchain is really a result of operating systems and the C language ABI works.
This section should also have plenty of information for you if your goal is to integrate GPU support in your own container tool.
Code is here: https://github.com/beniz/deepdetect
There are differenciated CPU and GPU docker versions, and as mentioned elsewhere in this thread, they are the easiest way to setup even production system without critical impact on performances, thanks to nvidia-docker. It seems they are more popular than AMI within our little community.
I was reading the article and got to the part related to installing CUDA drivers.
I am currently on the market for a laptop which will be used for self-learning purposes and I am interested in trying GPU-based ML solutions.
In my search for the most cost-effective machine, some of the laptops that I came across are equipped with AMD GPUs and it seems that support for them is not as good as for their Nvidia counterparts: so far I know of Theano and Caffe supporting OpenCL and I know support might come in the future from TensorFlow , in addition I saw that there are solutions for Torch  although they seem to be developed by single individuals.
I was wondering if someone with experience in ML could give me some advice: is the AMD route viable?
I guess those days have gone.
Someone in the community also Dockerized Spark + Hadoop + OpenBlas:
The GPU release is coming out Monday.
We'll also make it so you can experiment with models etc from a notebook:
Not exactly for the python crowd (we mainly try to be an alternative for the jvm stack)
looks like there are seperate torch and caffe amis as well for amazon. Going to try later.
Going through the AWS audit does take a few days to say the least and can be a hassle at times, but usually we are pretty close to the latest master / release.
Would love to get some feedback from anyone who gives them a spin about what we could do better - or which AMIs we should add that people may find useful.
If you are not familiar with AWS, we have quick-start blog here as well:
It looks like this runs on GPU-less instances, as well as Gx-instances. So, how do you envision this being used? Would someone do prototyping on the cheap instances and then move up to the Gx instances for production? Is that move transparent?
For TensorFlow if an operation has both CPU and GPU implementations, the GPU devices will be given priority (if present on the instance) when the operation is assigned to a device. For Caffe we have both the GPU and CPU version installed.
Domino offers prebuilt deep learning environments on its data science platform. Tensorflow, PyCUDA, Theano, H2O, a variety of R deep learning packages, and many other tools are available.
The environments run on Amazon's Nvidia GRID and Tesla instances.
This post is a little old but will give you an idea as to what you can accomplish:
We offer select prospects access to GPU compute when trialing Domino. Let me know if your team is interested.
Seriously... why can't there be a better way of adding coprocessors to a machine? Like stacking some boxes, interconnected by parallel ribbon cable, or something like that?
We work with the ubuntu team on juju.
We are working very closely with canonical/IBM on the whole DL stack. You will also see some stuff from us and nvidia
here within the next month or so on making cuda a bit easier to setup in a normal data science "stack" eg: jvm/python hybrid product stacks. Cudnn has tricky licensing but it shouldn't be that bad to automate setting up the cuda part.
I will work out what we are allowed to do licemse wise. Reach out to email@example.com if that is interesting.
We have AMI, we have docker, we have (gasp) shell scripts. It's 2016, Why am I cutting and pasting between a web page and a console?
To my knowledge the only thing that does something like this well is oh-my-zsh. And look at the success they've had! So either do it right, or don't do it at all.
> ...as they're almost immediately outdated, and seldom updated.
Your second sentiment is the reason why I appreciate the "make a list"-style tutorials. When something inevitably goes out of date, I can at least see some of the narrative and reasoning for each step, instead of trying to debug someone's shell script that they've left to obsolescence.
Even better is when I have 3 such tutorial-lists to compare, making it easier to see which steps are integral and which steps were simply author-specific conventions.
Also you might not need to restart after you install the drivers, this is not Windows. (But there might be some rmmod/modprobe needed)
> If your deep learning machine is not your primary work desktop, it helps to be able to access it remotely
Yes, use ssh.
I have to agree. Especially when the Ubuntu package drivers ruin your system.
Windows has been able to hotswap graphics drivers (and recover from driver crashes) for years now.
Installing a broken driver may cause the machine to not boot, fair enough, but CUDA should be straightforward.