
Google Stakes Its Future on TensorFlow - jonbaer
https://www.technologyreview.com/s/608094/google-stakes-its-future-on-a-piece-of-software/
======
noahl
As a former Google Cloud employee, I think "stakes its future on TensorFlow"
is overstating things. Maybe "Google executes clever strategy with TensorFlow,
reaps rewards" is a better headline.

This is exactly the same strategy that Google is running with Apache Beam /
Cloud Dataflow - make an API that can run anywhere, then make it trivial to
use that API on Google Cloud. I think TensorFlow is doing better than Beam
because TensorFlow is more of an advance over the previous state of the art
than Beam was, and because Google has managed to grow a community around
TensorFlow.

~~~
Florin_Andrei
> _Google has managed to grow a community around TensorFlow_

I agree with your post.

But speaking about the community part, I am still irritated that there's no
official support for running TensorFlow on ARM / Raspbian / Raspberry Pi.
Maybe I'm an outlier, but to me it looks like such an obvious choice. Here's a
platform that lots of people are using for automation and robotics and
computer vision, and it could be their first contact with machine learning,
and you could basically lure them all in if you gave them an official release.

Sure, there's someone on GitHub who provides unofficial packages, and props to
him for the awesome work...

[https://github.com/samjabrahams/tensorflow-on-raspberry-
pi](https://github.com/samjabrahams/tensorflow-on-raspberry-pi)

...but I'd really like to see Google stepping in here and doing the obvious.

I've opened a feature request a while ago. Google closed the ticket, no
explanation:

[https://github.com/tensorflow/tensorflow/issues/5729](https://github.com/tensorflow/tensorflow/issues/5729)

~~~
khawkins
The trend in this field is to do both training and classifying remotely on a
desktop. It's hard to see the benefits of keeping everything on the same chip.
The primary reason would probably be latency in classification. One would have
to argue that remote is slower than local computation.

Remote involves sending the inputs/receiving the outputs and having the
computation be done on a desktop, which even at its most basic, is going to be
more powerful than an embedded. Local involves no communication, but has to
use slower computational system. Since the typical input/output is on the
order of a few MB, data transfer latency is likely to be low. Considering deep
nets require significant number crunching for evaluation, the advantage by
using a faster machine might make up for the data transfer losses. Thus while
there might be benefits here, they aren't going to spectacular.

~~~
saurik
In practice, there isn't always "a desktop" available, and so the choice is
between "a server" and "locally"; the latter avoids network connectivity
requirements and privacy implications.

------
obulpathi
AI is the future of Computing. TensorFlow has established itself as the
standard for machine learning. It has an amazing community, and love from
researchers as well. TensorFlow, along with Kubernetes, are positioning Google
Cloud as a strong contender in Cloud Computing Space. With Cloud TPU and Cloud
ML, Google has leaped few years ahead of other AWS and Azure.

~~~
gaius
But the funny thing is that lock-in is very low in this space, at least for
the actual ML part. 90-99% of the work in ML is in acquiring and cleaning the
data, feature engineering and so on. Once you have your training data in good
shape, the ML engine is basically pluggable - the only barrier to switching
from Azure, Google, AWS etc is the cost of moving the data, if you store it
"in the cloud" in the first place. The winner won't be the slickest API - it
will be whoever makes it easiest to migrate your data in, whether that's a
traditional DW, sensor data feeds or whatever. If you keep the data on-prem
you could switch with relatively minor effort.

~~~
Cacti
I'm not sure how much work you do in this area, but the only ML models that
are pluggable and easily moved are ones that are relatively outdated,
widespread, and thus provide little benefit over your competitors.

ML moves fast, and to keep up, you need to be using a flexible yet powerful
framework or you will run into major slowdowns in implementation time.
Tensorflow is that framework, and, by the way, it also happens to have the
best support for actually deploying your models across datacenters.

Migrating your data into some cloud provider is irrelevant and consumes maybe
3% of the total effort involved. Data is maybe 10%, and the rest is
developer/research time.

~~~
gaius
The quality of the ML model - provided is of the right family in the first
place of course - might move you a few percent. The quality of the data you
feed it - by an order of magnitude or more. That's why real data scientists
spend the vast majority of their time on prep work.

~~~
gaius
Replying to myself with an example of easy portability
[https://news.ycombinator.com/item?id=14728591](https://news.ycombinator.com/item?id=14728591)

------
williamstein
This seems like a pretty good “fluff piece” about Google’s cloud strategy,
which hinges on cloud-based machine learning. I’ve heared the same from Google
employees I’ve talked with. Interesting quote:

> “The head of Google’s cloud business, Diane Greene, said in April that she
> expects to take the top spot within five years...”

~~~
influx
See also "The Submarine":

[http://www.paulgraham.com/submarine.html](http://www.paulgraham.com/submarine.html)

------
naturalgradient
One thing I keep wondering as a daily TensorFlow user: If Google is staking
its future on TensorFlow, why is there such slow development on the Java/C++
version, which would be relevant to lots of enterprise users?

Namely, full support of symbolic differentiation and all operations and
optimisers ported. Having to define everything in python and then load the
graph definition into a poorly supported C++/Java wrapper is incredibly
tedious.

Surely, hiring 5 engineers per language team and having them port and maintain
versions would not be a big stretch to the budget.

Or is this an intentional strategy where the lack of language support forces
users to deploy their models on Google cloud workflows in lieu of being able
to easily integrate them into their big data pipelines (mostly JVM based)?

~~~
dgacmu
Not intentional. It's a question of resource allocation and not impairing
velocity.

Most ML researchers and leading-edge folks want Python, and there's always a
lot of demand for making things faster/easier/etc. Adding more first-class
languages is on the "should do" list, but it adds a long-lived support burden
to keep the language bindings in sync with the core. There are some fairly
deep questions about how to make it _easy_ to have good, first-class language
support across many languages without multiplying the work by a factor of N.
For example, Andrew Myers is spending some time on the team and has been
working on beefing up the Java support, but as you can probably infer from
this PR, it's ... complicated. The discussion in this PR is a pretty good
glimpse into some of the underlying issues surrounding first-class language
support.

[https://github.com/tensorflow/tensorflow/pull/11251](https://github.com/tensorflow/tensorflow/pull/11251)

So - your concern is absolutely founded, and is taken very seriously, but is
treated cautiously for bigger-picture reasons. I'd expect continued progress
on this front, but I wouldn't expect it on very short time horizons.

~~~
naturalgradient
Thank you for the response - I appreciate the complexity, I had just been
wondering if there was actually a full time team on it.

From my limited insight (we collaborate with Google Brain), it was my
impression that the core problem around such questions is that most research
engineers with the expertise to do this are (and I understand this very well
as a researcher) more interested in doing research than do full time language
porting, and I would expect that to be the case for almost anyone with the
expertise.

