? ? 這一章才明確的進入計算圖的部分，前面使用的都還是立即執(zhí)行的代碼，但我理解，前面使用的eager execution應(yīng)該是計算圖的一種特化，本質(zhì)上是一樣的。

? ? 當(dāng)然對于從腳本語言這個方向先理解的人，把思路轉(zhuǎn)換為計算圖可能需要點兒時間，所以這一章的開頭做了大量說明，我基本上就略過了。

? ? 比較關(guān)鍵的是tf自己說的在圖上可以做什么優(yōu)化：

? ? 第一個constant folding我還特意查了一下，這是個源自編譯器的概念，就是把結(jié)果與輸入無關(guān)的東西先算出來之后固定下來，畢竟一個計算圖大概率是要迭代運行的，所以可以提前保留一些固定結(jié)果，當(dāng)然有經(jīng)驗的用戶大概也不會寫出這種代碼。

? ? 第二個關(guān)于圖的拆分，在Variable那一節(jié)的筆記里，我當(dāng)時認為tf的圖是按順序執(zhí)行的，現(xiàn)在看來他們也做了op之間的并行執(zhí)行，不過這里也說了，互相獨立的計算才可以被分開執(zhí)行，我覺得兩個使用了相同輸入tensor的op在tf里不一定能被判定為independent，所以輸入只讀的方式應(yīng)該是能更細的拆分計算圖的，雖然這個優(yōu)化極少產(chǎn)生實際作用。

? ? 最后一個比較關(guān)鍵，說的也比較模糊，有一些數(shù)學(xué)表達式是可以合并的，比如我們寫y=xw+b，通常聲明會在這里連接出兩個op，一個乘法一個加法，但如果有一個op是使用三個輸入，實現(xiàn)了xw+b這個操作的話，肯定會比操作兩次更快，雖然框架不可能覆蓋的了所有復(fù)雜情況。然而萬一他有這種細化操作（比如是cuda提供的），那么把乘法和加法兩個op合并成一個三輸入op就可以提速，我推測它干的就是這樣一個事。以前我們也提出過要做，但是我覺得這個也許能帶來提升，但需要框架對計算圖做大量的特判，我們那種就幾個人會用的小工具，不如顯示的直接調(diào)用三輸入的op來的更實際，所以一直就沒做。

? ? 從計算圖的定義來看，語法上跟我們以前大差不差，就是拿個函數(shù)包一下，雖然這里強調(diào)了與tf 1.0的語法產(chǎn)生了很大區(qū)別，但我相信這種包函數(shù)的方式無非是內(nèi)部幫你聲明了一個全局session，然后后面的op在定義時默認走了全局變量的那個session罷了，底層肯定是沒有大改動的（看c++那個示例就知道了）。

? ? 由于tf支持圖上的控制分支，也就是有專門的if op，所以如果你想要構(gòu)造這樣的圖，自然就需要用if op。以前我們沒想清楚條件和循環(huán)怎么在圖上體現(xiàn)，所以一般這種if條件就特化在了op里面，相當(dāng)于把多條件下的輸出合并。tf作為大公司當(dāng)然要支持各種情況了，按我理解他的這個autograph模塊，就是幫你把用戶隨意寫的py代碼轉(zhuǎn)換成計算圖的，比如大部分人不會知道判斷的地方要寫 if tf.greater(x, 0)，人家肯定直觀的寫 if x > 0，autograph就會幫你自動把這類代碼轉(zhuǎn)換。不過我覺得對于一部分高級用戶來說，他可能更喜歡自己掌控全部計算過程的方式，不喜歡有這種無法預(yù)知的不透明過程，對于大公司來說肯定可以做到盡善盡美，我們要是去做這種事情那就是純粹添亂了。

? ? Seeing the speed-up這個例子多少有點糊弄人，其實它做的事情就是算了一個矩陣的100次方，只不過是用循環(huán)實現(xiàn)的。聲明函數(shù)里，可以理解為每一個for里面的result都不再是最初那個result變量了，而是新生成的下游節(jié)點，于是這張圖是由100個乘法順序連接起來的。

? ? 而tf所謂的加速，大概率是將這100個連乘做了第三條優(yōu)化，合并成了更簡潔的計算式，也就是x^100，cuda內(nèi)部自然是做了快速冪的，證據(jù)就是，如果把for去掉，function里直接寫x**y，eager明顯比graph快很多。

? ? 當(dāng)然并不是graph沒用，對于大量的數(shù)據(jù)來說，肯定是graph更好，只是tf又想展示特性，又不能給文檔整太復(fù)雜，就弄了這么個tricky的例子。

? ? 至于他所謂的多態(tài)，我們以前的function是在調(diào)用的時候產(chǎn)生圖，然后外面再去多次執(zhí)行，而tf這里可以重復(fù)調(diào)用function，內(nèi)部會記錄下來造過的圖，當(dāng)輸入格式不匹配的時候就重新造一個，讓外界沒有感知。本來我認為就是把我們那種模式包裝的更人性化了一些，直到看見最后關(guān)于tracing的解釋才發(fā)現(xiàn)并不一樣。

? ? 所謂tracing應(yīng)該就是構(gòu)造圖，以及剪枝合并等等優(yōu)化這個過程。

? ? 從tf特別解釋了tracing對效率的影響來看，我大概理解他是怎么做數(shù)據(jù)流的了。我們以前在實現(xiàn)的時候，完整跑完一個計算圖是要走完全數(shù)據(jù)的，數(shù)據(jù)流是跑計算圖的必要條件，所以一個圖在聲明到運行完，跑完的是一整份數(shù)據(jù)的訓(xùn)練。

? ? 但是tf.function應(yīng)該針對的是一個mini batch的數(shù)據(jù)，這張圖跑完一次之后就是算出了一次梯度，至于流式數(shù)據(jù)是要在function外面再去包一層，這也是為什么function做成了重復(fù)調(diào)用時只有第一次生成計算圖。

? ? 包括文檔里也強調(diào)了，如果你的訓(xùn)練跑的特別慢，也許是哪里寫的不好導(dǎo)致了重復(fù)tracing，也就是每個mini batch都跑了一遍tracing，因為只有mini batch級的重復(fù)構(gòu)圖才能產(chǎn)生大幅拖慢訓(xùn)練的影響。