新聞中心
上一篇文章中我論述了葉子內(nèi)聯(lián)leaf inlining是怎樣讓 Go 編譯器減少函數(shù)調(diào)用的開銷的,以及延伸出了跨函數(shù)邊界的優(yōu)化的機會。本文中,我要論述內(nèi)聯(lián)的限制以及葉子內(nèi)聯(lián)與棧中內(nèi)聯(lián)mid-stack inlining的對比。

成都創(chuàng)新互聯(lián)服務(wù)項目包括江達網(wǎng)站建設(shè)、江達網(wǎng)站制作、江達網(wǎng)頁制作以及江達網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,江達網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到江達省份的部分城市,未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
內(nèi)聯(lián)的限制
把函數(shù)內(nèi)聯(lián)到它的調(diào)用處消除了調(diào)用的開銷,為編譯器進行其他的優(yōu)化提供了更好的機會,那么問題來了,既然內(nèi)聯(lián)這么好,內(nèi)聯(lián)得越多開銷就越少,為什么不盡可能多地內(nèi)聯(lián)呢?
內(nèi)聯(lián)可能會以增加程序大小換來更快的執(zhí)行時間。限制內(nèi)聯(lián)的最主要原因是,創(chuàng)建許多函數(shù)的內(nèi)聯(lián)副本會增加編譯時間,并導致生成更大的二進制文件的邊際效應(yīng)。即使把內(nèi)聯(lián)帶來的進一步的優(yōu)化機會考慮在內(nèi),太激進的內(nèi)聯(lián)也可能會增加生成的二進制文件的大小和編譯時間。
內(nèi)聯(lián)收益最大的是小函數(shù),相對于調(diào)用它們的開銷來說,這些函數(shù)做很少的工作。隨著函數(shù)大小的增長,函數(shù)內(nèi)部做的工作與函數(shù)調(diào)用的開銷相比省下的時間越來越少。函數(shù)越大通常越復(fù)雜,因此優(yōu)化其內(nèi)聯(lián)形式相對于原地優(yōu)化的好處會減少。
內(nèi)聯(lián)預(yù)算
在編譯過程中,每個函數(shù)的內(nèi)聯(lián)能力是用內(nèi)聯(lián)預(yù)算計算的 1。開銷的計算過程可以巧妙地內(nèi)化,像一元和二元等簡單操作,在抽象語法數(shù)Abstract Syntax Tree(AST)中通常是每個節(jié)點一個單位,更復(fù)雜的操作如 make 可能單位更多??紤]下面的例子:
package mainfunc small() string {s := "hello, " + "world!"return s}func large() string {s := "a"s += "b"s += "c"s += "d"s += "e"s += "f"s += "g"s += "h"s += "i"s += "j"s += "k"s += "l"s += "m"s += "n"s += "o"s += "p"s += "q"s += "r"s += "s"s += "t"s += "u"s += "v"s += "w"s += "x"s += "y"s += "z"return s}func main() {small()large()}
使用 -gcflags=-m=2 參數(shù)編譯這個函數(shù)能讓我們看到編譯器分配給每個函數(shù)的開銷:
% go build -gcflags=-m=2 inl.go# command-line-arguments./inl.go:3:6: can inline small with cost 7 as: func() string { s := "hello, world!"; return s }./inl.go:8:6: cannot inline large: function too complex: cost 82 exceeds budget 80./inl.go:38:6: can inline main with cost 68 as: func() { small(); large() }./inl.go:39:7: inlining call to small func() string { s := "hello, world!"; return s }
編譯器根據(jù)函數(shù) func small() 的開銷(7)決定可以對它內(nèi)聯(lián),而 func large() 的開銷太大,編譯器決定不進行內(nèi)聯(lián)。func main() 被標記為適合內(nèi)聯(lián)的,分配了 68 的開銷;其中 small 占用 7,調(diào)用 small 函數(shù)占用 57,剩余的(4)是它自己的開銷。
可以用 -gcflag=-l 參數(shù)控制內(nèi)聯(lián)預(yù)算的等級。下面是可使用的值:
-gcflags=-l=0默認的內(nèi)聯(lián)等級。-gcflags=-l(或-gcflags=-l=1)取消內(nèi)聯(lián)。-gcflags=-l=2和-gcflags=-l=3現(xiàn)在已經(jīng)不使用了。和-gcflags=-l=0相比沒有區(qū)別。-gcflags=-l=4減少非葉子函數(shù)和通過接口調(diào)用的函數(shù)的開銷。2
不確定語句的優(yōu)化
一些函數(shù)雖然內(nèi)聯(lián)的開銷很小,但由于太復(fù)雜它們?nèi)圆贿m合進行內(nèi)聯(lián)。這就是函數(shù)的不確定性,因為一些操作的語義在內(nèi)聯(lián)后很難去推導,如 recover、break。其他的操作,如 select 和 go 涉及運行時的協(xié)調(diào),因此內(nèi)聯(lián)后引入的額外的開銷不能抵消內(nèi)聯(lián)帶來的收益。
不確定的語句也包括 for 和 range,這些語句不一定開銷很大,但目前為止還沒有對它們進行優(yōu)化。
棧中函數(shù)優(yōu)化
在過去,Go 編譯器只對葉子函數(shù)進行內(nèi)聯(lián) —— 只有那些不調(diào)用其他函數(shù)的函數(shù)才有資格。在上一段不確定的語句的探討內(nèi)容中,一次函數(shù)調(diào)用就會讓這個函數(shù)失去內(nèi)聯(lián)的資格。
進入棧中進行內(nèi)聯(lián),就像它的名字一樣,能內(nèi)聯(lián)在函數(shù)調(diào)用棧中間的函數(shù),不需要先讓它下面的所有的函數(shù)都被標記為有資格內(nèi)聯(lián)的。棧中內(nèi)聯(lián)是 David Lazar 在 Go 1.9 中引入的,并在隨后的版本中做了改進。這篇文稿深入探究了保留棧追蹤行為和被深度內(nèi)聯(lián)后的代碼路徑里的 runtime.Callers 的難點。
在前面的例子中我們看到了棧中函數(shù)內(nèi)聯(lián)。內(nèi)聯(lián)后,func main() 包含了 func small() 的函數(shù)體和對 func large() 的一次調(diào)用,因此它被判定為非葉子函數(shù)。在過去,這會阻止它被繼續(xù)內(nèi)聯(lián),雖然它的聯(lián)合開銷小于內(nèi)聯(lián)預(yù)算。
棧中內(nèi)聯(lián)的最主要的應(yīng)用案例就是減少貫穿函數(shù)調(diào)用棧的開銷。考慮下面的例子:
package mainimport ("fmt""strconv")type Rectangle struct {}//go:noinlinefunc (r *Rectangle) Height() int {h, _ := strconv.ParseInt("7", 10, 0)return int(h)}func (r *Rectangle) Width() int {return 6}func (r *Rectangle) Area() int { return r.Height() * r.Width() }func main() {var r Rectanglefmt.Println(r.Area())}
在這個例子中, r.Area() 是個簡單的函數(shù),調(diào)用了兩個函數(shù)。r.Width() 可以被內(nèi)聯(lián),r.Height() 這里用 //go:noinline 指令標注了,不能被內(nèi)聯(lián)。3
% go build -gcflags='-m=2' square.go# command-line-arguments./square.go:12:6: cannot inline (*Rectangle).Height: marked go:noinline./square.go:17:6: can inline (*Rectangle).Width with cost 2 as: method(*Rectangle) func() int { return 6 }./square.go:21:6: can inline (*Rectangle).Area with cost 67 as: method(*Rectangle) func() int { return r.Height() * r.Width() }./square.go:21:61: inlining call to (*Rectangle).Width method(*Rectangle) func() int { return 6 }./square.go:23:6: cannot inline main: function too complex: cost 150 exceeds budget 80./square.go:25:20: inlining call to (*Rectangle).Area method(*Rectangle) func() int { return r.Height() * r.Width() }./square.go:25:20: inlining call to (*Rectangle).Width method(*Rectangle) func() int { return 6 }
由于 r.Area() 中的乘法與調(diào)用它的開銷相比并不大,因此內(nèi)聯(lián)它的表達式是純收益,即使它的調(diào)用的下游 r.Height() 仍是沒有內(nèi)聯(lián)資格的。
快速路徑內(nèi)聯(lián)
關(guān)于棧中內(nèi)聯(lián)的效果最令人吃驚的例子是 2019 年 Carlo Alberto Ferraris 通過允許把 sync.Mutex.Lock() 的快速路徑(非競爭的情況)內(nèi)聯(lián)到它的調(diào)用方來提升它的性能。在這個修改之前,sync.Mutex.Lock() 是個很大的函數(shù),包含很多難以理解的條件,使得它沒有資格被內(nèi)聯(lián)。即使鎖可用時,調(diào)用者也要付出調(diào)用 sync.Mutex.Lock() 的代價。
Carlo 把 sync.Mutex.Lock() 分成了兩個函數(shù)(他自己稱為外聯(lián)outlining)。外部的 sync.Mutex.Lock() 方法現(xiàn)在調(diào)用 sync/atomic.CompareAndSwapInt32() 且如果 CAS(比較并交換Compare and Swap)成功了之后立即返回給調(diào)用者。如果 CAS 失敗,函數(shù)會走到 sync.Mutex.lockSlow() 慢速路徑,需要對鎖進行注冊,暫停 goroutine。4
% go build -gcflags='-m=2 -l=0' sync 2>&1 | grep '(*Mutex).Lock'../go/src/sync/mutex.go:72:6: can inline (*Mutex).Lock with cost 69 as: method(*Mutex) func() { if "sync/atomic".CompareAndSwapInt32(&m.state, 0, mutexLocked) { if race.Enabled { }; return }; m.lockSlow() }
通過把函數(shù)分割成一個簡單的不能再被分割的外部函數(shù),和(如果沒走到外部函數(shù)就走到的)一個處理慢速路徑的復(fù)雜的內(nèi)部函數(shù),Carlo 組合了棧中函數(shù)內(nèi)聯(lián)和編譯器對基礎(chǔ)操作的支持,減少了非競爭鎖 14% 的開銷。之后他在 sync.RWMutex.Unlock() 重復(fù)這個技巧,節(jié)省了另外 9% 的開銷。
名稱欄目:Go中對棧中函數(shù)進行內(nèi)聯(lián)
本文網(wǎng)址:http://www.dlmjj.cn/article/dpcgjig.html


咨詢
建站咨詢
