Tensorflow sucks
21–30 of 133 posts
Re: Tensorflow sucks
#22Earlier quoted context omitted.
In my experience (computer vision, deep learning) PyTorch is substantially faster as well, especially in data augmentation where it’s not just a thin layer over cudnn. That said, you’re right. There’s no way I’d deploy it to production.
Nonsense, Pytorch is great in production. I use it for Mathpix (mathpix.com) which processes 20 million images per month.
Re: Tensorflow sucks
#23I'm open to a discussion about the downsides of tensorflow, which is why I read the article in the first place, but this post doesn't provide that.
Re: Tensorflow sucks
#24Wait, (s)he’s arguing that the code isn’t imperative enough, but the punchline is they don’t like having to type session.run? I don’t understand their vendetta against the graph, which is a powerful abstraction that lets you choose different backend, and let’s tensorboard show you an awesome view of your computation. Session.run isn’t hard to type and it takes at most a few days to grok that everything is lazily eval…
I believe the issue is that the code only actually runs when you calls session.run this makes debugging a nightmare. Sure TF can improve message, but it's not there yet. IMO, TF2 should make dynamic execution first class and switch easily to static graph when you need to deploy stuff.
Re: Tensorflow sucks
#25Earlier quoted context omitted.
Why wouldn't you deploy it in production - on server side at least?
Because TF lets you run _just_ the model, with no Python stuff at all. For us there is no “server side”, our stuff is deployed on prem. The fewer variables there are the easier our lives are going to be. Additionally, PyTorch download page warns you point blank that it’s an early version of the software and that you should “expect some adventures”. Adventures are fine for research, but inadvisable in production IMO.
Making it run at scale using something like kubernetes is more advanced stuff but still within good devops practices.
Unless, of course if you want to run on exotic HW, like TPUs. But that's an issue for Googlish scales.
Edit: BTW, if on premise you mean Windows client software your point is totally valid, Python would suck for this.
Re: Tensorflow sucks
#26> Pytorch’s interface is objectively much better than Tensorflow’s Ummm. No. 'Objectively' is utter nonsense. For an objective view we would need to define "better" first and measure both interfaces performance. I think it is preference. I prefer the Tensorflow interface and don't mind it's declarative style. However, if one wants to criticize something one could start with the static nature of Tensorflow (which you…
In my experience (computer vision, deep learning) PyTorch is substantially faster as well, especially in data augmentation where it’s not just a thin layer over cudnn. That said, you’re right. There’s no way I’d deploy it to production.
Disclaimer: I work on Caffe2 team (not on ONNX, though)
Re: Tensorflow sucks
#27Earlier quoted context omitted.
Nonsense, Pytorch is great in production. I use it for Mathpix (mathpix.com) which processes 20 million images per month.
Don't take this the wrong way, but 20M images per month is only about 20 qps or so (20M / 3600 / 730 => 7.6 qps, but that's unrealistically even). That's pretty manageable even on a single box, depending on the network and the size of the box. When people say they're concerned about a system in production, they often mean when needing to roll it out to many machines due to higher scalability requirements. Disclosure:…
Re: Tensorflow sucks
#28- Bloated build system that is near impossible to get working - who even uses maven ?! Pytorch/Caffe are super-simple to build in comparison; with Chainer, it's even simple: all you need is pip install (even on exotic ARM devices).
- The benefits of all that static analysis simply aren't there. In addition, PyTorch has a jit-compiler which one can argue lets one have their cake and eat it too.
- Loops are extremely limited. Okay, we know RNN/LSTMs aren't really TF's thing, but if you venture out to do something out of the ordinary even making it batch-size invariant is difficult. There isn't even a map-reduce op that works without knowing the dimension at compile time. You can hack something together by fooling one of those low level while_loop ops, but that just tells you how silly the whole thing is.
Re: Tensorflow sucks
#29An appropriate quote: "If you can't intelligently argue for both sides of an issue, you don't understand the issue well enough to argue for either." There are many people for whom the declarative paradigm is a huge plus. I would say there are at least 2 major approaches in running fast neural networks: 1. Figure out the common big components and make fast versions of those. 2. Figure out the common small components a…
Cannibalism rules!
Re: Tensorflow sucks
#30Earlier quoted context omitted.
In my experience (computer vision, deep learning) PyTorch is substantially faster as well, especially in data augmentation where it’s not just a thin layer over cudnn. That said, you’re right. There’s no way I’d deploy it to production.
Have you looked at ONNX? It is a neural network exchange format that, in particular, lets you deploy PyTorch models in production via Caffe2. Here is a tutorial: http://pytorch.org/docs/master/onnx.html Disclaimer: I work on Caffe2 team (not on ONNX, though)