3 ms·

TensorFlow Lite sounds like a good idea, but they don't talk at all about how to build it. "Run this shell script" is neither saying what the requirements are,

TensorFlow Lite sounds like a good idea, but they don't talk at all about how to build it. "Run this shell script" is neither saying what the requirements are, nor does it give any idea about supported targets. How I hate this new trend of not documenting anything. This might be usable if it doesn't require Bazil. Requiring that makes deployment much, much heavier and makes the whole process significantly more complex. "Embedded"? Does that mean ARM to these folks who don't know how to version and how to document?

lovelearning 8y ago
I'm not a fan of Bazel either. Luckily, this doesn't require Bazel. Their guide [1] explains how to build using regular make for RPi. [1]: https://www.tensorflow.org/lite/rpi https://www.tensorflow.org/lite/rpi
- m0zg 8y ago
  I'm a big fan of Bazel (or its Google internal counterpart, Blaze). Such a big fan, in fact, that I even use it for Python projects, and package outputs into Google PAR: https://github.com/google/subpar https://github.com/google/subpar. As long as you stick with the official 4 Google languages (C++, Java, Python, Go) it doesn't get any better IMO, as far as build systems are concerned. I do wish it didn't require Java though.
  - lovelearning 8y ago
    I have a bad impression of Bazel for multiple reasons. I wanted to build TF on the Pi but at the time I assumed it required Bazel. Bazel had no ARM version (my experience was in mid-2017). I had to first build Bazel from sources. Failed a few times because its heap settings were too low, required a lot more swap and storage than I expected, and got the Pi so hot that I had to quickly setup some cooling fans around. A successful build took ~1.5 hours on a RPi 2. Then the full TF build using Bazel took some 10-11 hours. Finally, Bazel's command-lines - ex: "bazel build --config=opt -k //tensorflow/tools/pip_package:build_pip_package" - felt very counterintuitive and not easy to remember. For the first two problems, I learnt it the hard way that a cross-compilation environment is better than building on-device. The last one I still have a problem with.
    - m0zg 8y ago
      Bazel makes it reasonably straightforward to set up crosstool (a cross-compilation toolchain). That's how it's supposed to be done, whoever ported TFLite to Pi just probably neglected to provide a crosstool for it. It's a much better dev experience if you have a crosstool. Rebuilds on changes are near instantaneous and fully incremental. Toolchain can be set up to only be downloaded as needed. A good PR idea for someone, if it's not already done?
m0zg 8y ago
I managed to build it just fine. Their shell script didn't work for Raspberry Pi at the time, but fixing it was about 5 minutes of work.
pjmlp 8y ago
The way NDK related deployments work is still a joke in Android, despite some improvements to correct the situation. Most Google native libraries targeted to Android, instead of using Android tooling integration, tend to be some link to a github repository with an endless list of manual integration steps, including making use of Blaze. It is as if the teams don't know better, never used Apple or Microsoft's C++ SDKs, or at very least walked next door to check how one is supposed to do it on Android.

lovelearning 8y ago

I'm not a fan of Bazel either. Luckily, this doesn't require Bazel. Their guide [1] explains how to build using regular make for RPi. [1]: https://www.tensorflow.org/lite/rpi https://www.tensorflow.org/lite/rpi

m0zg 8y ago
I'm a big fan of Bazel (or its Google internal counterpart, Blaze). Such a big fan, in fact, that I even use it for Python projects, and package outputs into Google PAR: https://github.com/google/subpar https://github.com/google/subpar. As long as you stick with the official 4 Google languages (C++, Java, Python, Go) it doesn't get any better IMO, as far as build systems are concerned. I do wish it didn't require Java though.
- lovelearning 8y ago
  I have a bad impression of Bazel for multiple reasons. I wanted to build TF on the Pi but at the time I assumed it required Bazel. Bazel had no ARM version (my experience was in mid-2017). I had to first build Bazel from sources. Failed a few times because its heap settings were too low, required a lot more swap and storage than I expected, and got the Pi so hot that I had to quickly setup some cooling fans around. A successful build took ~1.5 hours on a RPi 2. Then the full TF build using Bazel took some 10-11 hours. Finally, Bazel's command-lines - ex: "bazel build --config=opt -k //tensorflow/tools/pip_package:build_pip_package" - felt very counterintuitive and not easy to remember. For the first two problems, I learnt it the hard way that a cross-compilation environment is better than building on-device. The last one I still have a problem with.
  - m0zg 8y ago
    Bazel makes it reasonably straightforward to set up crosstool (a cross-compilation toolchain). That's how it's supposed to be done, whoever ported TFLite to Pi just probably neglected to provide a crosstool for it. It's a much better dev experience if you have a crosstool. Rebuilds on changes are near instantaneous and fully incremental. Toolchain can be set up to only be downloaded as needed. A good PR idea for someone, if it's not already done?

m0zg 8y ago

I managed to build it just fine. Their shell script didn't work for Raspberry Pi at the time, but fixing it was about 5 minutes of work.

pjmlp 8y ago

The way NDK related deployments work is still a joke in Android, despite some improvements to correct the situation. Most Google native libraries targeted to Android, instead of using Android tooling integration, tend to be some link to a github repository with an endless list of manual integration steps, including making use of Blaze. It is as if the teams don't know better, never used Apple or Microsoft's C++ SDKs, or at very least walked next door to check how one is supposed to do it on Android.