XLA: The TensorFlow compiler framework
tensorflow.org
tensorflow.org
Anyone know what the status is? When TPUs will be allowed to be used in Google Cloud?
I'm confused as to why they ever announced it at a big event like Google I/O rather than a paper or even a simple blog post if they aren't going to give people access to them. There's some hint of it being offered in conjunction with TF and other ML cloud offerings in the blog post[1], and this 'XLA compiler framework' looks it's related. But I'm still wondering how much time people have to wait.
[1]:https://cloudplatform.googleblog.com/2016/05/Google-supercha...
TPUs are only useful for prediction, not training, and for very high volumes of work where energy use is a major cost, so, it's for Google and FaceBook-type of situations. They are not designed as accelerated general purpose processors for deep learning.
Cheap inference can be done on CPUs as well, because production models can be optimized to only a small fraction of the computation (20x reductions are not impossible) by pruning neurons, weight quantization and other techniques.
My hunch is that TPUs work with a mix of 8 bit and 16 bit integer arithmetic on quantized networks with quantized data [1].
As far as I know nobody has managed to make SGD work properly with integer weights and that could be a reason why TPUs are not used for training (yet).
[1] https://petewarden.com/2016/05/03/how-to-quantize-neural-net...
I could be completely wrong though.
My lab-mate Jan Gosmann recently did something similar for our spiking neural network software Nengo [1]. Although it isn't Deep Learning, it also builds a computational graph of operations. He ended up optimising the layout of the operations in memory to increase the efficiency of Numpy operations and reduce the amount of time spent in Python. He's in the process of writing a paper about it.
JITs can take into account the actual data being processed. And most importantly here, its size.
Knowing the size will help with making chunks of work fit into L1, L2, L3 caches. Creating sensible SIMDs operations. Choosing what goes into a warp.
Also, sometimes it is better to rematerialize a computation than having stored it; and the threshold to do it depends on the space and computing costs.
Languages like Halide [1] let you hand-tune this threshold. I guess this is the kind of work XLA does here.
XLA also has an experimental ahead-of-time mode, which we think will be particularly interesting for some production and mobile deployments. This is all work in progress though, and we're looking forward to getting the community involved.
Unofficial answer: no promises, but it should be open-source soon. It may even be released in the next day or two. Watch this space!
https://github.com/tensorflow/tensorflow/commit/1e67c90e2cac...
https://github.com/tensorflow/tensorflow/tree/master/tensorf...
The corresponding documentation hasn't been pushed yet; I'll post a link when it is up.
Note that XLA is work in progress --- we're releasing the code early because we want to get the community involved. The GPU backend is in good shape, and improving by the day. We haven't had as much time to devote to the CPU backend, and it only has limited support for parallelism. Contributions welcome!