4 ms·

As a former Google Cloud employee, I think "stakes its future on TensorFlow" is overstating things. Maybe "Google executes clever strategy with TensorFlow, reap

by noahl 9y ago

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.

laingc 9y ago
apologies for sounding flippant, but my opinion can be summarised as follows: TensorFlow is Python/C++. Nice! Beam is Python/Java. Not nice.
Florin_Andrei 9y ago
> 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 9y ago
  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 9y ago
    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.
  - Florin_Andrei 9y ago
    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.
- yablak 9y ago
  Ticket reopened.
Eridrus 9y ago
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.

by noahl 9y ago

laingc 9y ago

apologies for sounding flippant, but my opinion can be summarised as follows: TensorFlow is Python/C++. Nice! Beam is Python/Java. Not nice.

Florin_Andrei 9y ago

> 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 9y ago
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 9y ago
  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.
- Florin_Andrei 9y ago
  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.
yablak 9y ago
Ticket reopened.

Eridrus 9y ago

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.