Live data from Hacker News

Eager Execution: An imperative, define-by-run interface to TensorFlow

research.googleblog.com

21–30 of 41 posts

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#21

Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)

Based on your reasoning PyTorch is copying TensorFlow static optimizations and production capability with JIT and ONNX then? I've seen many folks requesting an imperative API.

You can't please everybody, as if they listen or not to users people still complain. If both are making effort to improve themselves though, the community has only to benefit from this competitiveness.

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#22

TensorFlow: everything to all people. Eager is actually not as innocent as "open-source projects borrowing the best parts from each other", as some commenters here suggest. Google is attempting to dominate the machine-learning API and the Python ecosystem for scientific computing. The company that controls the API influences which apps are built on it and how. Think about how Google bundled Android services on top of…

Huh? They're attempting to dominate the machine learning ecosystem by writing a bunch of free and high quality machine learning libraries? What exactly are they doing wrong?

I wouldn't compare a permissively licensed library to Android services at all.

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#23
post #16

Earlier quoted context omitted.

I think you mean Google is following the leadership of Chainer, like Facebook already does? PyTorch started as a Chainer fork. Its dynamic graph internals are all from Chainer.

This isn't art. There are no points for originality. If open source projects borrow the best parts from each other, that's a good thing.

It's not a bad thing. It's good for users. But give credit to the leaders in the field. If you make an iPod clone, you call it an iPod clone, not a clone of the Zume HD.

Chainer started it, was around years earlier, and it still has more users. So Google is not copying PyTorch, it's copying Chainer.

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#24

TensorFlow: everything to all people. Eager is actually not as innocent as "open-source projects borrowing the best parts from each other", as some commenters here suggest. Google is attempting to dominate the machine-learning API and the Python ecosystem for scientific computing. The company that controls the API influences which apps are built on it and how. Think about how Google bundled Android services on top of…

Huh? They're attempting to dominate the machine learning ecosystem by writing a bunch of free and high quality machine learning libraries? What exactly are they doing wrong? I wouldn't compare a permissively licensed library to Android services at all.

I'm surprised I have to write this, but Google is not a charity. They are pouring commercial resources into Tensorflow for a reason. That reason is Google Cloud. Tensorflow is a Trojan horse to get people to use Google Cloud and other paid Google products. How do I know this? Because Tensorflow works better on Google Cloud than anywhere else, and Google is making a concerted effort to catch up with AWS in cloud, mostly through machine learning.

I didn't compare Tensorflow to Android services. I said that Tensorflow would serve as the basis of a service bundle, much like Android did. Let's come back in a couple years and I'll tell you I told you so.

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#25
post #14

Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)

the question now is, are tensorflow eager's RNN as slow as pytorch's are?

(I'm author of the TF rnn api & tf.contrib.seq2seq)

There's a lot of work being done on this specific part. If you have a standard RNN architecture you want to run, you can probably use the cudnn code in tf.contrib.cudnn to get a super fast implementation.

There is some performance work that needs to be done on properly caching weights between time steps of an RNN if you use a tf.nn.RNNCell. Currently if you want to implement a custom architecture, or a seq2seq decoder, or an RL agent, this is the API you would want to use. Several of the eager benchmarks are based on this API; so that performance will only improve.

I'm hopeful that for the next major release, we'll also have support for eager in tf.contrib.seq2seq.

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#26
post #3
post #2

You can read out more about it in the blog post ( https://research.googleblog.com/2017/10/eager-execution-impe... ) or the README ( https://github.com/tensorflow/tensorflow/tree/master/tensorf... ). This is still a preview release, so you may hit some rough edges. Looking forward to your feedback as you try it out.

I'm on the team that worked on this -- happy to answer questions!

Hot damn this has got me all giddy. How will this work on single node multi-GPU systems? For example, with PyTorch you have to either use threading, multiprocessing, or even MPI. Can you think of a not-too-scary way to use eager execution with multiple GPUs?

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#27
post #25
post #14

Earlier quoted context omitted.

the question now is, are tensorflow eager's RNN as slow as pytorch's are?

(I'm author of the TF rnn api & tf.contrib.seq2seq) There's a lot of work being done on this specific part. If you have a standard RNN architecture you want to run, you can probably use the cudnn code in tf.contrib.cudnn to get a super fast implementation. There is some performance work that needs to be done on properly caching weights between time steps of an RNN if you use a tf.nn.RNNCell. Currently if you want to…

[deleted]

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#28
post #13

Announcing TensorFlow's new development roadmap mandate: copy everything PyTorch is doing :-)

I'm usually against this type of framework baiting, but being a tensorflow guy myself & having just spent the week coding with pytorch full time.... this is basically identical to pytorch

What are the strengths and weaknesses of each? I've been using keras but planning on diving into a real deal framework next. Tensorflow is appealing for the momentum it has in the community, but pytorch looks easier to learn.

Doing image classification, object localization, and homography (given an input image, which of my known template images is matches it and in what orientation).

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#29

Earlier quoted context omitted.

Huh? They're attempting to dominate the machine learning ecosystem by writing a bunch of free and high quality machine learning libraries? What exactly are they doing wrong? I wouldn't compare a permissively licensed library to Android services at all.

I'm surprised I have to write this, but Google is not a charity. They are pouring commercial resources into Tensorflow for a reason. That reason is Google Cloud. Tensorflow is a Trojan horse to get people to use Google Cloud and other paid Google products. How do I know this? Because Tensorflow works better on Google Cloud than anywhere else, and Google is making a concerted effort to catch up with AWS in cloud, most…

In what way is Tensorflow working better on Google Cloud? Are they tuning the ML code for specifics of their infrastructure or does Google Cloud just have more tooling for Tensorflow?

Re: Eager Execution: An imperative, define-by-run interface to TensorFlow

#30
post #26
post #3

Earlier quoted context omitted.

I'm on the team that worked on this -- happy to answer questions!

Hot damn this has got me all giddy. How will this work on single node multi-GPU systems? For example, with PyTorch you have to either use threading, multiprocessing, or even MPI. Can you think of a not-too-scary way to use eager execution with multiple GPUs?

We're still fairly early in the project, so for now threading is the only supported way.

We can do better, however, and we're working on ways to leverage the hardware better (for example, if you have no data-dependent choices in your model we can enqueue kernels in parallel on all GPUs in your machine at once from a single python thread, which will perform much better than explicit python multithreading).

Stay on the lookout as we release new experimental APIs to leverage multiple GPUs and multiple machines.

Post reply on HN