【硅谷問道】Chris Lattner 訪談錄（上）

【硅谷問道】Chris Lattner 訪談錄（上）

話題

• Chris Lattner 是誰？
• Xcode 的編譯器 LLVM 背後有怎樣的故事？
• Swift 誕生的前世此生，封閉的蘋果爲什麼要擁抱開源？
• 說好的 ABI 穩定性什麼時候能推出？

Chris Lattner 是誰

 

教育背景

• 伊利諾伊大學 PHD

工做經歷

• 2005年 - 2017年供職蘋果，前開發部高級總監，架構師
• 2017年開始，擔任特斯拉副總裁，負責自動駕駛

主要成就

• Swift 之父，主要做者
• LLVM 之父，主要做者
• Clang 主要貢獻者

榮譽

• 2016年被評爲「創造將來的25位當世天才」
• 2013年得到 ACM 系統設計大獎

訪談實錄

自我介紹

1. 你怎麼看待本身？

我是個程序員。我喜歡寫代碼。我編程有很長時間了。

我在讀博的時候就開始寫 LLVM 了。當時 LLVM 是個人博士研究項目，我想把它作成工業界中顛覆性的產品。當時我異想天開，嘗試了各類架構設計，想解決以往編譯器全部的弊端 -- 結果固然沒有如願。我畢業後，就但願能接着搞 LLVM ，當時只有蘋果容許我入職以後繼續設計並實現 LLVM 。我想都沒想就加入了蘋果。

LLVM

2. 說說 LLVM（Low Level Virtual Machine）究竟是什麼吧

• 先說編譯器：編譯器是把程序員的代碼翻譯成機器能夠理解的語言的工具；
• 再談 LLVM：一個模塊化和可重用的編譯器和工具鏈技術的集合，Clang 是 LLVM 的子項目，是 C，C++ 和 Objective-C 編譯器，由於多模塊的複用，因此提供了驚人的快速編譯，比 GCC 快3倍。

3. LLVM 是一開始就做爲一個完整的編譯工具來使用的嗎？仍是有什麼其餘故事

LLVM 當時是爲了解決一個小問題而開發的：當使用OpenGL 函數庫的時候（Mac OS 10.4 和 10.5環境下），好比你要調用這個函數，glVertex3f()，編譯器必須將其轉化爲特定的GPU能夠理解的數據。可是這帶來一個問題：市面上有海量的GPU，每一個GPU的性能和參數也不盡相同，所要求的數據格式也不一樣。這時 LLVM 能夠產生很小的一部分代碼去解決這個問題，這是 LLVM 誕生的初衷。

4. LLVM 的 bytecode 和 Apple 如今的 bitcode 有什麼不一樣？

這是歷史遺留問題。一開始 LLVM 是開源的，全部代碼在轉成二進制時就叫作 bytecode -- 由於 java 當年就是這麼叫的。當時這一部分有不少問題：好比不能擴展，沒法兼容，很是脆弱。

而後就到了 LLVM 2.0，當時我從新設計了架構，採用的就是 Bitcode 機制。LLVM 2.0 將全部代碼以比特流(bit stream)而不是字節流(byte stream)的形式來編碼。這就是 bitcode 這一術語的由來。

主要的工做流程就是現將代碼轉成比特流，而後相應處理。處理完後再將編碼傳到其餘地方去。

5. Bitcode 這個機制比直接傳輸二進制有什麼好處

好處那是多了去了。首先 編譯器工做起來會愈來愈好。由於經過Bitcode機制，它能夠經過編譯不一樣代碼來存儲各類優化方法，這樣下次碰到相似代碼，它就會自動啓動相關優化機制，使得效率提高。還有個好處是 LLVM 可讓芯片的兼容性變得很好。由於 Apple 每一年都在芯片上推陳出新，它們轉化爲二進制的規則都不盡相同，LLVM 只要每次從新編碼並傳輸成比特流就行了。

固然 Bitcode 也不是萬能的。好比它不能解決 32位的 APP 在64位機器上的兼容問題。這個問題其實應該依靠代碼邏輯。

談管理

6. 在職業生涯中，你在 LLVM 上鞠躬盡瘁，但咱們發現這幾年你更多的工做是在管理上，你本身怎麼看這種轉變的？

我雖然作管理了，可是我依然喜歡寫代碼，並且我天天都寫，由於我就是個極客嘛。並且，其實我很早就開始作管理的工做了。不過我一直是做爲技術領導人的角色帶 2 到 3 我的的，我只是在寫代碼方面把把關，給他們提提建議這樣。

後來帶的人多了，隊伍也大了。我不只管程序員，還管小組經理和其餘技術領導人。雖然我一直喜歡寫代碼，可是管理對我來講是一個必需要去作的事。如今回過頭來，我以爲幹得還不錯。跟你們一塊兒工做以後我知道不少事協同工做效果更好，和同事交流你就會理解他們的想法，這樣我就能夠制定更好的計劃路線。

其實我沒感受整個過程有什麼不一樣。直到今天我還夜以繼日、廢寢忘食得寫代碼，我並非坐那邊動動嘴皮子，指揮別人幹活的老闆。我其實每一個週末都在寫代碼，我很忙的。

Swift

7. Swift 是如何誕生的？在蘋果這樣一個大廠，決定作出如此巨大的變革，同時仍是在封閉的環境下，你是如何一步步實現的？

首先，蘋果內部全部的項目都不盡相同 -- 工做流程、戰略規劃、實施細節，到最後發佈。Swift 也同樣，沒有可比性。由於蘋果自己就是小組單兵做戰模式 -- 每一個組負責不一樣的大方向，組裏本身計劃和工做，甚至招人都是各自招。

言歸正傳，契機發生在2010年了。當時好像是咱們剛剛完成了 Clang 對 C++的支持。你也知道 C++ 寫起來有多醜，可是作個編輯器支持 C++，完善 C++ 這門語言就是另外一回事了，咱們當時搞了很久終於完成的時候特別有成就感。固然 Clang 遠沒有到達完美的地步。

我又扯遠了。除了作 Clang 之外，不管是 C語言，C++，仍是 Objective-C，都有一些我不是很滿意的地方。因此我就想要不咱們搞個新的語言來吧。新的語言要越簡單越好。一開始你們都沒認真，後來我跟不少同事聊了以後以爲新語言的計劃可行，並且你們都很亦可賽艇。因而咱們就用業餘時間開始頂層設計和寫代碼。

如今問題來了，由於咱們已經有 Objective-C 了。雖然它有幾個地方很醜，好比總是用 "@"，每句結束了還要打分號，可是這些並不妨礙它是一門偉大的語言。因此，咱們爲何要開發新語言，而不是把精力花在優化 Objective - C 上？

 

緣由有三。

第一，若是咱們大幅優化 Objective - C，把不少 Swift 的特性加進去，這對開發者來講是災難性的，由於他們要對原來的 APP 要進行大幅修改；

第二，Objective - C 不少特性積重難返，好比它安全性上的問題；

第三，Objective - C 是基於 C 開發的語言，因此你不管怎麼優化，它必然有 C 語言自身的缺陷。

因而咱們就動手作 Swift 了，它的背後有着數百人的努力: 支持 Xcode，開發 Playground，兼容調試器和編譯器。我我的感到最驕傲的一點是，咱們並不打算本身內部把它作到完美 -- 咱們開源、咱們依靠社區，這樣一門語言才能在無數開發者的實戰中獲得檢驗和改進，我想這纔是 Swift 最棒的地方。

8. 你以前在優化 Objective-C 的時候，有沒有想到什麼地方是將來 Swift 能夠用獲得的？

ARC。咱們其實一直都在爭論是用垃圾回收機制（garbage collection）仍是 ARC，後來決定了是 ARC。

另外一個是模塊化，咱們也將這一部分的經驗帶到了 Swift 開發中。

其實，不少數組和字典方面的語法優化原本是計劃在 Objective - C 上面的。可是後來咱們開發了 Swift，因而這些改進被直接用在了新語言上，因此你們會在寫 Swift 的時候以爲似曾相識，由於原本這些就是 Objective-C 的升級版本嘛。

我能夠透露一個有意思的事情。咱們在作 Swift 的時候，不少 iOS 開發者，包括蘋果內部的工程師，都在吐槽咱們這幾年在 Objective - C 上毫無建樹，都在說大家爲何不作這個那個。咱們固然不能告訴他們咱們在全力開發 Swift，而他們所要的語法功能咱們都會給。

9. 蘋果內部對於 Swift 的使用狀況和開發是怎麼看得？

Swift 團隊對於開發上有明確的目標和計劃，應用二進制接口（ABI）的穩定性一直是咱們的首要目標。不少人很喜歡咱們開源的 Swift Playground。同時 iOS 系統內置的 Music App 也是 Swift 寫的。其實用不用 Swift 主要是技術和開發方面的考量，蘋果內部同時得兼顧穩定性和開發效率，這不是說你們喜不喜歡這個語言的問題。

Swift 剛發佈的時候，內部不少組都很驚訝：咱們已經有了 Objective-C，爲何還要搞新的 Swift？並且 Objective-C 自己就很不錯，開發起來也很順手。後來漸漸 Swift 成熟了，你們也愛上了這個新生兒。

內部其實對於 Swift 一個很大的顧慮在於，蘋果的全部開發必須兼容32位機器，而32位的應用都採用了 Objective-C 的 runtime 機制。這就要求 Swift 團隊也弄出個相似的機制，或者弄個兼容的方案，不然 Swift 沒法與 AppKit 適配。

10. 開源後的 Swift 發展態勢喜人，你對此有什麼見解？

開源以後，Swift 發展之好讓我咋舌，然而這也是問題所在。

當年咱們開源了 LLVM 和 Clang，它們也發展喜人。咱們的對手 AMD 們徹底跟不上咱們。可是跟 Swift 比起來，它們的發展也太慢了，LLVM 和 Clang 開源後徹底沒有 Swift 這麼火。

Swift 就不一樣了，開源一年以後，咱們就有了上百萬的開發者在使用這門語言 -- 我和不少有豐富開源經驗的老工程師都嚇了一跳，這簡直了！而後咱們天天收到無數的郵件和 pull requests，要求更新這個、要求優化那個，咱們的節奏徹底被打亂了。咱們如何規劃開發？咱們如何把 Swift 的開發導向一個正確的方向？這些問題隨着時間的推移和經驗的積累，慢慢找到了解決之道。

我如今以爲開源這個決定相當重要。一來你們會幫着優化；二來咱們有個巨大的論壇，在那裏你們能夠暢所欲言，全世界的人都在幫着 Swift 進步，這真的很棒。咱們雖然沒有一開始就具體計劃要開源，可是蘋果內部當時都以爲 Swift 確定有一天要開源。

蘋果與特斯拉

 

11. 蘋果好像一直是個封閉的公司，大家內部對於開源怎麼看？

蘋果其實有開源的傳統。 LLVM 雖然不是始於蘋果，可是最終是蘋果完成並將其開源。Clang 則完徹底全是生於斯開源於斯。還有其餘工具，好比 LLDB，libc+，以及compiler-rt 都是如此。

因此對於 Swift 來講，開源只是時間問題。當年從 Swift 1.0 到 Swift 2.0，一切都亂七八糟。當時咱們重點在開發錯誤處理機制，還有協議、拓展等一系列重要的功能。因此開源 Swift 1.0，並非一個好選擇，由於這些重要的東西都沒有，而這些開發是當務之急。當 Swift 2.0 到來的時候，咱們纔有空去開源、去作社區拓展和論壇搭建。開源社區能夠幫咱們修復細節，咱們這時候能夠更多的投入在架構設計上。

12. 蘋果最讓你懷念的是什麼？

蘋果是這樣一個公司，你能夠選擇你喜歡的東西，而後努力工做去實現它，最終你的工做會落實在產品上，影響億萬計的人。

有不少公司，你能夠努力工做，可是不必定能作你喜歡的東西；你作出來東西，可能會被束之高閣；你作的產品，也許最後很幸運的發佈，可是並不必定有不少人會用。在蘋果，你的工做能夠真正改變世界，頗有成就感。

13. 你以爲到特斯拉以後，還會努力爲 Swift 作出貢獻嗎？

特斯拉的工做很是有挑戰性，這是我最開心的地方。我如今還沒入職，因此也不知道我以後對 Swift 能作多少工做。也許我還會夜以繼日的發 Pull Request，也許我就週末寫寫 Swift 代碼。我應該會從各個方面 -- 不管是頂層設計仍是具體代碼實現，與蘋果的核心團隊合做，爲這個語言作貢獻。

其實我一直想說，Swift 只是我在蘋果工做的一小部分，我花了大量的時間在其餘事情上。實際上在蘋果我也就晚上或者週末有空寫寫 Swift。我但願到了特斯拉以後我還能花一樣的精力和時間在 Swift 上，畢竟我對這門語言統治世界充滿期待。

ABI 穩定性

14. 如今 Swift 已經到了第3個版本了。咱們也知道ABI穩定性的追求一直是大家的目標，可是它也一直被各類事情拖延。你對此有什麼計劃嗎？或者說你從拖延中學到了什麼經驗教訓嗎？

ABI 推遲有兩個緣由。

第一是由於 Swift 的開發進程中有不少不肯定性。當 Swift 開源之時，一堆人對咱們提 pull request，提各類各樣的 issue。這樣咱們就不得不去花大量的時間去維護開源社區，而不是專心去作計劃內的工做。

第二個緣由是，儘管穩定的 ABI 很重要，可是對於開發者來講，穩定的 ABI 對他們來講沒有明顯的好處，他們更關心是語法和兼容上的穩定和優化。因此咱們後來修改了計劃，語法和兼容上的穩定性被定爲是最早要實現的目標。這樣當 Swift 3.1 或者 Swift 4.0 出來的時候，你們不用擔憂語言上的轉化會讓 Xcode 崩潰，或是須要你們整個重構 APP。Swift 3.0 主要就是實現這個目標。

 

15. 穩定的 ABI 何時推出？他會趕在異步和併發模型以前嗎？

Swift 現有的內存管理機制對 ABI 穩定性形成了不小的影響。有些底層邏輯還須要調整，好比 getter 和 setter 的生成以及屬性的內存分配問題，蘋果內部正在作這件事，這以後咱們才能完成 ABI。至於併發模型啥的就跟 ABI 沒有關係了。

不少人擔憂 Swift 4.0 的時候蘋果能不能推出穩定的 ABI，由於畢竟工做量太大。ABI 的工做正在井井有理得進行，並且對於開源社區來說推出穩定的 ABI 相當重要。Ted （Chris Lattner 以後的 Swift 領導人）有一件事說對了，如今 Swift 當務之急就是讓編譯器更穩定，讓錯誤處理更方便，提升編譯速度，而且將 Swift 拓展到大規模系統中。

我在想 Swift 4.0 的時候究竟能看到什麼。也許沒有穩定的 ABI，可是必定會有重要的新功能加入。

ABI 將容許將來 Swift 版本開發的應用程序和編譯庫能夠在二進制層次上與 Swift 3.0 版本的應用程序和編譯庫相互調用。這樣，ABI的穩定性將保證必定程度的二進制兼容性，而且第三方更容易發佈二進制庫。另外，ABI 將容許刪除須要的 Swift 標準庫和二進制文件，就像目前狀況下經過Xcode建立的 iOS 和 OS X 應用程序同樣。

補充

 

LLVM.png

補充：LLVM的三層結構

• 第一層：Clang 編譯器，負責編譯各類語言
• 第二層：代碼優化器，經過模塊化操做優化代碼，是 Bitcode 邏輯的主要部分
• 第三層：代碼翻譯器，針對不一樣平臺和 GPU 將代碼翻譯成機器語言

補充：LLDB，llbc++，compile rt

• LLDB: 一個有着 REPL 的特性和 C++ ,Python 插件的開源調試器。LLDB 綁定在 Xcode 內部，存在於主窗口底部的控制檯中；
• libc++，libc++ ABI: 高性能 C++ 標準庫實現，支持 C++ 11
• compiler-rt：爲 LLVM 和 Clang 設計的編譯器擴展函數庫。針對 __fixunsdfdi 和其餘目標機器上沒有一個核心 IR (intermediate representation) 對應的短原生指令序列時，提供高度調優過的底層代碼生成支持。

ABI 是什麼？

Application Binary Interface，中文名：應用二進制接口。是 APP 和 操做系統、其餘應用之間的二進制接口。它包括如下細節：

• 數據類型的大小、佈局和對齊;
• 調用約定（控制着函數的參數如何傳送以及如何接受返回值），例如，是全部的參數都經過棧傳遞，仍是部分參數經過寄存器傳遞；哪一個寄存器用於哪一個函數參數；經過棧傳遞的第一個函數參數是最早push到棧上仍是最後；
• 系統調用的編碼和一個應用如何向操做系統進行系統調用；
• 以及在一個完整的操做系統ABI中，目標文件的二進制格式、程序庫等等。