Google Stakes Its Future on TensorFlow | Hacker News Reader

Google Stakes Its Future on TensorFlow

technologyreview.com

63 pointsjonbaer23 comments

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.

apologies for sounding flippant, but my opinion can be summarised as follows:

TensorFlow is Python/C++. Nice! Beam is Python/Java. Not nice.

> 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

...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

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.

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.

There are many, many cases where full standalone mode is the only one available, at least for classification. I would say this is actually the typical case.

Training is a different matter, of course. You want to do training on a fast GPU or something.

Ticket reopened.

Beam just seems like Google trying to somehow get on the Spark train without just running Spark, too bad Beam's support for analytic use cases sucks compared to Spark.

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.

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.

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.

I disagree with this. In my experience, improving your dataset quality (either via gathering more examples, getting more reliable labels, or doing better normalization) has yielded bigger gains than trying to use the latest and greatest model architecture for the problem. Linear and tree models are still widely used in applied problems.

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.

Replying to myself with an example of easy portability https://news.ycombinator.com/item?id=14728591

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...”

See also "The Submarine":

http://www.paulgraham.com/submarine.html

These sort of pieces make up a large part of Google's PR strategy now.

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)?

Probably the latter strategy. I could see an "enterprise tf" being built in java and licensed to people who need to integrate without using GCP

From outside it looks like a question of culture & focus, not some diabolical strategy. A company called Skymind has built a deep learning library called DL4J oriented towards enterprise use cases (Java support, integration with Hadoop etc), I think they're fairly successful.

Enterprise adoption is slowed by the lack of ML developers/researchers, not because of something as banal as language choice.

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

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.

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.

Reply on news.ycombinator.com