Earlier quoted context omitted.
I think you had a justifiable devil's advocate until your claim about "Fragmenting" What exactly is so bad about competition?
What is so bad about standardization?
Choice.
Gluon – Deep Learning API from AWS and Microsoft
71–80 of 85 posts
Re: Gluon – Deep Learning API from AWS and Microsoft
#72Re: Gluon – Deep Learning API from AWS and Microsoft
#73Gluon is an attempt by Microsoft and Amazon to regain some influence in AI tools. Keras looked like it was going to become the standard high-level API, but now Theano is dead, and CNTK and MxNet are controlled by Google's rivals, and they're ganging up against Google's tools. Francois Chollet is committed to keeping Keras neutral, but he's still a Google engineer, and that probably makes Microsoft and Amazon nervous.…
Unlike Keras and Tensorflow, Gluon is Define-by-run Deeplearning framework like Pytorch, Chainer. Network definition/debugging/flexibility are really better with dynamic network (define-by-run). That's why Facebook seem to use Pytorch for research and caffe2 for deployment. Gluon/Mxnet can do both define-by-run with Gluon API and "standard" define-and-run with it's Module API.
I think you're both right here. Competition will force the other to innovate. I don't think end users lose by there being multiple interfaces even if fragmentation is ultimately what happens here.
Standard formats and interop will help fix that.
Re: Gluon – Deep Learning API from AWS and Microsoft
#74Earlier quoted context omitted.
What is so bad about standardization?
Choice.
Data scientists arguably have too much choice. 10 data scientists will have 50 different tools, can't share work or build on another's experiments or even remember what the result of an experiment were. those are some of the reasons why most data science projects fail. that and integrations. standardization has real benefits.
Re: Gluon – Deep Learning API from AWS and Microsoft
#75Earlier quoted context omitted.
https://jeffknupp.com/blog/2017/09/15/python-is-the-fastest-... > Python's Buffer Protocol: The #1 Reason Python Is The Fastest Growing Programming Language Today > The buffer protocol was (and still is) an extremely low-level API for direct manipulation of memory buffers by other libraries. These are buffers created and used by the interpreter to store certain types of data (initially, primarily "array-like" structu…
That doesn’t sound like a very satisfying reason to me. Isn’t a ByteArrayBuffer in Java pretty much the same (its underlying implementation is a char[] which can be used directly from C)? Is there perhaps another factor, such as an existing ecosystem or that it’s widely used in the academic field?
If you use direct allocation yes. Java has great facilities for direct memory management. (Look at the number of libraries like netty and co that exist). The problem with java is more the friction at getting at some of the lower level apis.
Python just has momentum and a fairly easy to use FFI.
Re: Gluon – Deep Learning API from AWS and Microsoft
#76Earlier quoted context omitted.
What is so bad about standardization?
Choice.
There's tradeoffs to choice. In the case of another commenter "too much choice" means a ton of churn and a lot of friction when it comes to building models.
I think there's always a trade off of innovation vs stability that people should be thinking about here.
Granted, things like the model formats should help long term, but for now we're going to be dealing with a ton of churn on APIs.
I'm sure another thing like dynamic graphs will come along and we'll need to update the apis.
I suspect keras will respond to this at some point by adding primitives for eager mode and the like.
I know both data scientists who need more advanced models and others who prefer the keras api just building off the shelf models.
Re: Gluon – Deep Learning API from AWS and Microsoft
#77Earlier quoted context omitted.
Choice.
Data scientists arguably have too much choice. 10 data scientists will have 50 different tools, can't share work or build on another's experiments or even remember what the result of an experiment were. those are some of the reasons why most data science projects fail. that and integrations. standardization has real benefits.
Of course standardization has benefits but how do you choose? Standardization only works if choice is eliminated so choice is a barrier to achieving standardization.
Re: Gluon – Deep Learning API from AWS and Microsoft
#78Earlier quoted context omitted.
Data scientists arguably have too much choice. 10 data scientists will have 50 different tools, can't share work or build on another's experiments or even remember what the result of an experiment were. those are some of the reasons why most data science projects fail. that and integrations. standardization has real benefits.
Of course standardization has benefits but how do you choose? Standardization only works if choice is eliminated so choice is a barrier to achieving standardization.
It often just comes down to project requirements.
Eg, what kind of model is required? How hard would it be to build with tool x?
For example, a big reason why a lot of computer vision research was built (and sorta still is because of momentum) on caffe was pre existing model zoos.
A big reason why people choose TF (despite lacking dynamic graphs) is just because of existing community.
Requirements for both papers as well as industry will continue to evolve. Each framework will have their own trade offs.
Re: Gluon – Deep Learning API from AWS and Microsoft
#79Why AWS and Microsoft?
Why not Amazon and Microsoft?
Re: Gluon – Deep Learning API from AWS and Microsoft
#80Earlier quoted context omitted.
Mostly because Python is a great "glue" language. It isn't performant enough to implement the actual low-level computation, but is better at running other applications, getting data from them, feeding them into other applications (a.k.a pipelines).
Sure but if I have invested a lot in MS technologies I am hesitant to learn and implement things in a completely new language if I can find something that is more fitting to the stack I already use.
Sure but if I have invested a lot in MS technologies I am hesitant to learn and implement things in a completely new language if I can find something that is more fitting to the stack I already use.
The rest of the ML world is in that exact situation, but on Python. They aren't going to throw away their familiar tools unless everyone else does too.