4 ms·

> 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

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

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.