做編譯器優化開發是一種什麼樣的體驗?

跟普通軟體開發有什麼區別?


佔個坑聊點個人經驗。我主要參與的是JVM的JIT編譯器的研發,在編譯器研發中算是比較「偏門」的方向——跟傳統編譯器(例如C++編譯器)會有那麼點不同。

做編譯器優化是件有趣的事情。

天天盯著大量的日誌從屏幕上飄過,就為了抓住那麼一點線索 &<- 從這個意義上說其實我們做的事情跟許多別的領域的軟體開發是極其相似的。

然而也有不同的地方。我喜歡把當前工作區里的JVM設置為環境中的默認JVM,所以默認java、javac這些命令都會用我工作區里最新的build。這是許多編譯器開發者都喜歡做的「吃自己的狗食」(eat your own dog food)的一環。

這樣做最有趣的地方莫過於:有時候自己不小心引入了bug,別說想跑的Java測試用例,測試會直接掛在要編譯那個測試用例的javac進程上…嗯連Java源碼編譯到Class文件都編譯不了,因為javac也是用Java寫的,讓javac跑在有bug的JVM上它就先掛了。

還有許多糾結的事情。回頭大家感興趣我再寫些故事。

做編譯器優化,測試一直是個難題。有時候是問題本身麻煩,有時候是參與開發的人造成的麻煩。

例如,有一次我做了個特定形式的數組邊界檢查的優化,提交patch給組裡做peer review的時候,被要求要寫一個測試用例證明優化確實發生了。額滴個神,這要俺咋寫,難道要用白盒API(HotSpot VM專門為測試提供了一個WhiteBox testing API)去抓取生成的機器碼看是不是消除了若干個冗餘的邊界檢查么?但那樣測試就變得特別平台相關了啊,而且寫起來巨麻煩。

結果就不了了之了,那個patch現在還懸在半空沒check in。


我做過一個月不到的編譯器優化的工作,現在還是很懷念那段時間,天天人都處於某種亢奮狀態,覺得自己終於做上一份高大上的工作了,但是旋即項目cancel,全部工作移交老印.

但具體每天的工作,還是覺得很逗比.就是一個比較資深的同事覺得某個地方有優化機會,就開始做了,我把debug log parse一下,用graphviz輸出bb的圖,覺得某個地方的確可以優化,最後討論再三,覺得把一個控制循環展開的參數默認值設得更激進點即可,然後就這麼做了.然後跑SPEC,情況大好,蒙特卡洛的分數大漲30%.但是跑另外一個SPEC,分數微微降了1%.老闆們一合計,覺得客戶比較看重後一個SPEC,這個優化就不了了之.本來還想掙扎一下,但是項目被cancel,後面也就沒有辦法了


最近趕進度暫時沒時間好好回答,先佔個坑等閑一點再答

我接了GSoC2015里ruby jit的項目,任務要求是四個月從0開發一個jit(°ο°)當然我和mentor扯了半天絞盡腦汁說服他給我減了不少工作量,但剩下的還是夠喝一壺的

目前每天的感受就是亢奮並蛋疼著,每天晚上9點以後我都不敢想相關的內容否則肯定因為高度興奮導致失眠←_←

從上周開始正式動手寫,平均每寫一個小功能都會遇到一大堆奇怪的問題。不過每次一個問題一個問題的刷下來,成就感還是蠻大的,不過往往一天就過去了Orz所以我最近常有的狀態是先打幾行代碼,然後開始發獃狂躁亂竄然後瘋狂在紙上畫奇怪的圖案,然後再發獃,然後寫幾行代碼,如此循環。。。

飯吃完了,幹活去了。。。哪天再來寫


推薦閱讀:

如何看待以及理解Python的這種尾遞歸優化?
C#編譯期執行了哪些優化,對代碼做了哪些改變?

TAG:程序員 | 軟體開發 | 編譯器 | 性能優化 |