Apple uses a different model format[0], so tensorflow models need to be converted first before they can be used. So Apple would need to add support for this tensorflow lite/mobile model format to work in Core ML.
Another format is onnx [0], where Apple and Goodle don't seem to participate. I don't know the politics behind it but there should be a common format for all libraries/platforms.
onnx seems to be an initiative to try to allow Microsoft's and Facebook's AI platforms to compete with Tensorflow.
Considering Tensorflow is more a grab at developer mindshare than an ideal platform [for example, its performance lags by a factor of two behind MXNet and Torch], I think it's a smart plan.
I don't think the last sentence is fair to trensorflow. Torch has been around for ~15 years compared to the 3 of TF. You'd expect TF to catch up in terms of performance in the future.
Not necessarily. They are just data formats that encode the different weights and layers of the neurel net. (That is an oversimplification, but enough to give you a basic grasp of what is happening under the covers.) Apple is obviously investing a lot into CoreML, so expect some speed ups just due to effort but I would not expect factors of magnituite difference in performance. (This might be wrong as Tensorflow Lite is still quite immature, but as it matures I believe it will be comparable in performance.)
Would be super cool if they would even port their stuff to Web Assembly. Now we have some Android and some iOS solution, but webasm would be truly platform independent.
Doesn't JIT automatically SIMDifies some operations on arrays? Although I agree it would be better to have a control over that, instead of hoping JIT compiler would do the right thing.
Generic automatic vectorization remains very much an unsolved problem. Outside of very specific cases, even modern compilers very much suck at it. That's why most vectorizable libraries have hand-coded SSE/NEON assembly blocks. I would not expect a JIT, which has to be fast, to have time to auto-vectorize anything at all, much less to do it well.
Some people are wondering if Tensorflow Lite would support CoreML / iPhone's neural engine. Tensorflow is not supported with coremltools (but I suppose Google could contribute a patch for this). I'm not sure about the CoreML libraries on the phone but from my understanding it may work.
It looks like this issue has been resolved to a reasonable extent.
I just tried building TFLite for a lark on a Raspberry Pi 2 and succeeded without much hassle and any of that bazel nonsense. It's a standalone component - they provide a Makefile and I just had to run make.
The example label_image inference app took a bit more work - I had to write my own Makefile - but wasn't difficult. I'm able to run inference on images on RPi2 with both floating and quantized MobileNets tflite models. Will try videos now.
For anybody else interested in trying out TFLite on your desktop or Raspberry Pi or any SBC, I've put up instructions and Makefile at https://pastebin.com/LDEGyG46
I did not do any performance profiling yesterday. I am currently interested in deploying object detection models for video streams, and plan to do detailed profiling of those when ready.
That said, the label_image classification example does provide some timing information. On the 500x600px test image that comes with it, non-quantized classifier for 10 iterations took ~900 ms on a RPi2 while quantized took ~300 ms. The confidence values were much lower in the quantized version, but I didn't spot any major misclassification.
The training export from Google CloudML -> Tensorflow Lite is still not clear. Since the freeze_graph scripts use Bazel, it is hard to pull this off on the cloud
26 comments
[ 2.6 ms ] story [ 87.5 ms ] thread[0]https://developer.apple.com/documentation/coreml/converting_...
[0] https://onnx.ai/
Considering Tensorflow is more a grab at developer mindshare than an ideal platform [for example, its performance lags by a factor of two behind MXNet and Torch], I think it's a smart plan.
They very well may catch up, but that doesn't mean that hype and the Google name aren't the reason it's gotten popular.
https://developers.googleblog.com/2017/12/announcing-core-ml...
Keras is supported out of the box with the Tensorflow backend though. See https://medium.com/@JMangia/super-simple-end-to-end-test-of-... and https://github.com/apple/coremltools
It seems that it will be supported but there's no timeline.
I just tried building TFLite for a lark on a Raspberry Pi 2 and succeeded without much hassle and any of that bazel nonsense. It's a standalone component - they provide a Makefile and I just had to run make.
The example label_image inference app took a bit more work - I had to write my own Makefile - but wasn't difficult. I'm able to run inference on images on RPi2 with both floating and quantized MobileNets tflite models. Will try videos now.
For anybody else interested in trying out TFLite on your desktop or Raspberry Pi or any SBC, I've put up instructions and Makefile at https://pastebin.com/LDEGyG46
That said, the label_image classification example does provide some timing information. On the 500x600px test image that comes with it, non-quantized classifier for 10 iterations took ~900 ms on a RPi2 while quantized took ~300 ms. The confidence values were much lower in the quantized version, but I didn't spot any major misclassification.