Live data from Hacker News

Tensorflow sucks

nicodjimenez.github.io

21–30 of 133 posts

Re: Tensorflow sucks

#21
I feel like a lot a people in this thread are like "omg he said declarative is bad. but declarative programming is good! so he must be wrong about everything". And then they come up with arguments against the article and imply he is an idiot.

Re: Tensorflow sucks

#22
post #6

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

Just one instance of our product has to process 39 million inferences per month (number is dictated by frame rate), with predictable latency, 24x7, on both Windows and Linux.

Re: Tensorflow sucks

#23
There is little analytical or "detailed" about this post. The most complex model is y = 3*x, the author provides no evidence to back up any claims about adoption, difficulty of use, etc., and most of the author's complaints boil down to a lack of syntactic sugar.

I'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

#24

Wait, (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.

TensorFlow is introducing eager evaluation: https://github.com/tensorflow/tensorflow/tree/master/tensorf...

https://twitter.com/oshtim/status/879453382326353920

Re: Tensorflow sucks

#25
post #18

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

I understand the appeal, but IMO wrapping the Python stuff in a docker container is fairly simple.

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
post #6

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

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)

Re: Tensorflow sucks

#27
post #19

Earlier 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:…

That's a fair point, but just as a counterpoint, for plenty of people, 20M per month is a lot of traffic, and it's good and valid to hear about experiences of people putting PyTorch into production with this scale.

Re: Tensorflow sucks

#28
A few more for your selection,

- 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

#29

An 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…

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

Cannibalism rules!

Re: Tensorflow sucks

#30
post #6

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

If I want to export my own computational graph to ONNX, what is the first place I should look at? Do you know about any documentation or reference implementation of the format?
Post reply on HN