3 ms·

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

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

zebrafish 9y ago
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
hedgehog 9y ago
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.
Cacti 9y ago
Enterprise adoption is slowed by the lack of ML developers/researchers, not because of something as banal as language choice.
dgacmu 9y ago
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 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.
- naturalgradient 9y ago
  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.

zebrafish 9y ago

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

hedgehog 9y ago

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.

Cacti 9y ago

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

dgacmu 9y ago

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

naturalgradient 9y ago
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.