Name: TensorFlow內部：函數，而不是會話 (Inside TensorFlow: Functions, not sessions)
Uploaded: 2021-01-14T10:34:44.000Z
Duration: 46 min 9 s
Description: 【看影片學英語】數萬部 YouTube 影片，搭配英漢字典即點即查，輕鬆掌握單字發音與用法，長久累積看電影不必再看字幕。

here again to talk about functions not sessions.

This function is the new way of using graphs

All the material I'm going to cover here,

described in one of the RFCs in the TensorFlow community GitHub

So if you go to GitHub.com/tenso rflow/communities/rfcs,

you will see on our see an RFC with exactly this title

in there where we go for a bunch of the motivation and a bunch

on some nitty gritty details of the motivation

and more details about the implementation.

And things that if you're working on TensorFlow

and you're using functions to do something

or you're curious about function internals,

I hope to at least point you to the right

places to start reading the code to understand what's happening.

I'm mostly going to focus today on the high-level Python

And there's another training session later.

I think the title's going to be eager execution runtime.

That's going to focus more on the C++ side of stuff.

it helps if you understand where we're coming from,

which is the session about run world in TensorFlow one.

And I think in TF1, when TF was originally designed,

it was designed as a C++ runtime first and only later came

the API of graphs and sessions is pretty reasonable.

This connection is important because a runtime can

There are all sorts of in between things.

And to actually run computation, you just call session at run.

the names of your inputs, the names of your outputs,

the names of particular nodes that you want to run.

And the runtime will go do its thing and return to you

the results in C++ normal arrays that you can use to manipulate

So this is very nice and convenient if you're writing

in C++ and if you're programming at this level.

You generally write the code that looks like this once,

and you spend your entire life as a TensorFlow developer

writing the little part that I abstracted out

to say that just manually writing protocol buffers

So we very, very quickly decided this is not a good way to go

And the first version of the API was very explicit.

So you created a graph, and then every time you created an op,

and this is still fine because it's very explicit

that you're building a graph that then you're

This is not really idiomatic Python code.

So it's also very easy to see how to make

You just stick the graph in a global context manager

and add a bunch of operator overloads and things like that.

like what TensorFlow code looks like today, which

is a little unfortunate, because the same code, by reading it,

you can't really tell whether an object is a tensor,

this the third quantity et cetera, et cetera, that

Or if this is just a normal Python object or non-pi array.

and I think leads to a very unnatural programming model.

The session.run thing also has a granularity problem,

which is that in the way it was originally built,

the graph, like, the stuff that you pass a session of run,

is a quantum of all the stuff you want to execute.

And around it is this very rigid boundary

where you keep stuff in the host memory of your client program,

give it to session.run, and then get results back

So one example that I think is illustrative of why this is not

ideal is if you have a reinforcement learning agent

that's implemented over a recurrent neural network,

in that scenario, your agent's going to run a loop where it's

going to read an observation from your environment, which

is some arbitrary code that runs in your host,

字幕列表影片播放

TensorFlow內部：函數，而不是會話 (Inside TensorFlow: Functions, not sessions)

stuff

essentially

bunch

practice