編譯 | 蘇宓
出品 | CSDN（ID：CSDNnews）
2023 年 10 月底，蘋果公司用 30 分鐘快速宣布了 M3 系列晶片及裝置的到來，彼時庫克形容道「它性能逆天、技術先進、能效非凡」。
新版本的釋出，吸引了不少果粉的目光。而對于科技公司而言，在員工入職時給配備一台 MacBook 電腦其實也不足為奇。是以，在最新搭載 M3 系列晶片的 MacBook 開啟售賣之後，不少員工想要作為首批體驗使用者能夠用上，而國外一家專門提供處理緊急事件軟體的開發商 incident.io 便是被員工追問是否購買新裝置的公司之一。
在 incident.io 内網中，有不少員工表示：
- 哇，如果我的筆記本電腦看起來那麼好，我的工作效率會提高多少？
- 如果我們的機器是深空黑的，也許我們會更安全🤔
面對員工熱火朝天的讨論，該公司 CTO Pete 回應道，“如果能證明這是值得的，那麼就會購買。”
此話一出，不少員工心動了。對此，在以 incident.io 産品經理 Lawrence Jones 為首的團隊迅速展開了行動，其在程式員的幫助下，首先開發了一款自定義的 Go 熱加載工具，并用此工具跟蹤開發者筆記本電腦的遙測資料（從 MacBook 内各種來源和子系統收集資料的最終結果），将這些資料加載到 OpenAI 最新的 GPT-4 模型中，然後進行分析，最終幫助公司衡量是否應該放棄現有的 M1/M2 裝置而花錢去購買最新的 M3 MacBook Pro 給程式員用。
接下來，我們将看看 Lawrence Jones 究竟是怎麼做的！
程式員的工作難以量化
對于 Incident.io 以及業界很多團隊而言，量化開發者的生産力是一件很難的事情，但是獲得更快的回報循環（feedback loop，通過識别問題、改進功能和驗證設計選擇來促進持續改進）可以有效提升開發者的效率。
在該公司内部，其本地開發中最常見的回報循環是：
- 編譯 Go monolith。
- 運作代碼生成：API 用戶端、接口等。
- 對前端/移動應用程式采用熱加載技術（在不重新開機服務的情況下讓更改的代碼生效）。
所有開發者都在自己的筆記本電腦上使用完全成熟的 Incident.io 環境進行本地開發：它允許在更改代碼和運作代碼之間實作 <30 秒的回報循環。
是以，編譯 Go 應用程式是這些循環中最頻繁也是最昂貴的步驟之一，代碼庫擁有接近 100 萬行的代碼。作為這些任務中最耗費資源的一項（就系統資源而言），倘若擁有更強大的硬體可能會更好。
基于此，Incident.io 團隊選擇 Go 編譯速度作為衡量 MacBook 性能的關鍵名額：現在該團隊隻需要測量它。
擷取遙測資料
據 Lawrence Jones 介紹，一直以來 incident.io 都是使用 codegangsta/gin（https://github.com/codegangsta/gin）作為 Go 程式的熱加載工具。它運作良好，每當代碼檔案發生變化時，它就會編譯并重新開機新版本的應用程式。不過，由于遇到一些難以解決的原因，incident.io 不得不考慮更換一種工具。
然而，當 Lawrence Jones 等人檢視其他熱加載工具時，沒有發現任何一款熱加載器可以提供給他們想要的跟蹤編譯程式時間擷取遙測資料（從 MacBook 内各種來源和子系統收集資料的最終結果）。
對于 Lawrence Jones 而言，其理想中的熱加載工具可以獲得：
- 系統尺寸：平台（M1/M2/M3）、總記憶體等。
- 運作時名額：作業系統、記憶體使用情況、電源、電池電量等。
- 遙測資料：總持續時間、Go 編譯階段、哪些檔案觸發了建構等。
由于沒有現成的替代方案，Lawrence Jones 決定建構自己的替代方案，以便根據其具體的需求進行定制。
本次實驗的主要動機是擷取遙測資料，是以這一過程一開始隻是一個簡單的 main.go，Lawrence Jones 和他的程式員同僚對其進行了調整，直到它可以從主機中提取上文所需的内容。
其實 Mac 電腦有許多二進制檔案可以幫助你完成此操作，如 memory_pressure、docker、sysctl 和 pmset，而代碼主要是執行和解析它們的輸出：
memoryFreeRegex := regexp.
MustCompile(`^System-wide memory free percentage:\s+(\d+)%`)
// Run memory_pressure...
memoryPressure, _ := exec.Command("memory_pressure").Output()
for _, line := range strings.Split(string(memoryPressure), "\n") {
if memoryFreeRegex.MatchString(line) {
// ...parse result!
ev.MemoryFree = memoryFreeRegex.FindStringSubmatch(line)[1]
}
} 一旦成功建構了系統和運作時收集器，封裝 Go 編譯指令就很簡單了，這樣就可以提取 bulid 的特定名額，如階段時間（連結器、編譯等），并跟蹤哪些檔案導緻觸發了 build。
最終，Lawrence Jones 從現有的 make run 目标運作熱加載程式。
“這對我們的工程團隊來說是個無形的改變，但卻意味着，現在每次建構完成後，我們都會向自己選擇的 HTTP 端點發送遙測事件。我們設定了一個 Fivetran Webhook 端點接收器（incident.io 内部的 ETL 工具），它可以将事件推送到我們的資料倉庫，僅此而已！”Lawrence Jones 說道。
最後，Lawrence Jones 獲得了判斷 Mac 性能所需的資料。
分析資料
根據上述步驟，Lawrence Jones 等人等待了幾周之後收集到了足夠大的資料集，緊接着，也就是進入了分析資料階段。不過，大多數開發人員都知道，即使在同一系統上，編譯時間也是千變萬化的。Go 編譯器尤其會對編譯過程進行大量緩存，是以即使是最強大的 M3，在沒有緩存的情況下編譯速度也要比有緩存的老式 Intel 版本的 MacBook 慢得多。
這意味 Lawrence Jones 不能直接比較不同平台的平均建構時間。
相反，他們需要真正深入挖掘底層資料，這提供了一個使用 OpenAI GPT-4 最新代碼解釋器的絕佳機會。
建立 OpenAI 助手
在使用 GPT-4 分析資料時，Lawrence Jones 分享了具體的流程：
- 将資料導出為 CSV：使用 BigQuery 導出了 select * except(payload) from developer__build_events 的結果。
- 建立一個"助手"，用提示詞幫助解釋實驗的目的，并向其提供包含資料的 CSV 檔案。
詳細來看，Lawrence Jones 使用了實驗性的 gpt-4-1106-preview 模型，并啟用代碼解釋器來進行資料分析。隻用了幾分鐘，助手便搭建好了，一切準備就緒後，它開始回答相關的資料分析問題。
清洗資料
此次 Lawrence Jones 一共收集到了 25k 條資料，所有資料是在一天中的所有時間、各種筆記本電腦和許多不同的條件下獲得的。
為了在平台之間進行良好的比較，也希望為這些編譯建立盡可能公平的比較，Lawrence Jones 删除了具有混雜因素的資料。
- 失敗或取消的編譯資料：如果有人在編譯完成之前退出，這相當于是一個半成品，需要剔除這些資料。
- 使用電池供電：OS X 會限制性能以延長電池壽命。
接下來，讓我們了解一下有多少編譯是不成功的，以及每個平台有多少編譯活動。
向 GPT-4 提問：
向我展示按機器平台分列的建構分布情況，其中平台按 M1 至 M3 排序，在平台類中 Pro 位于 Max 之前。
按編譯成功（退出狀态為 0 且未取消）與失敗對每個平台的建構次數進行拆分。
我是一個視覺學習者，我希望看到這樣的結果：我們按 M1 至 M3 對平台進行排序，在每個平台類别中，Pro 排序在 Max 之前。
也許這樣和 AI 聊天機器人對話感覺很奇怪，但它給出了我們想要的：
可以繼續對 GPT-4 說：
從現在開始，請從資料集中排除失敗的編譯。
當機器人說已從資料集中剔除了失敗的編譯。現在可以處理包含 12,525 個成功編譯的資料集。
假設使用電池供電的機器會受到限制，導緻建構時間不能很好地代表總體性能。Lawrence Jones 也想通過比較不同電源的同一平台的性能來确認這一點。
于是，他又問道：
僅關注 Apple M1 Pro 和 Apple M2 Max 平台的成功編譯，您能否直覺地比較不同電源的建構持續時間？
最終得到如下結果：
結果顯示，交流電通常更快。
繼續向 GPT-4 求解：
在你看來，使用交流電源還是電池電源會影響編譯性能嗎？
機器人回應道：
我将計算成功建構資料集的 t 檢驗并報告 p 值。低 p 值（通常小于 0.05）表明交流電源和電池電源在建構性能方面存在顯著差異。
...
負 t 統計量表明，交流電源的平均建構持續時間低于電池電源。此外，P 值約為 0.0014，遠低于 0.05 的常用臨界值，我們有足夠的證據來拒絕零假設。
鑒于這一統計檢驗的結果，我們可以得出結論：使用交流電源還是電池電源确實會影響所有平台的建構性能，使用交流電源的建構往往比使用電池電源的建構更快。
Lawrence Jones 表示，「這就說明了問題：從現在起，我們将隻考慮成功編譯+使用交流電源的電腦！」
比較 M1 和 M2
當 Lawrence Jones 進一步向 GPT-4 提問：
僅關注 M1 Pro 和 M2 Max（因為這些是我們擁有最多資料的平台），您可以繪制兩個直方圖來顯示成功的建構持續時間，并消除極端異常值。
總體而言，從下圖可以很明顯看出 M2 Max 在建構速度方面完全遠超 M1 Pro。
不過，也需要注意的是，這些 MacBook 的不同之處不僅僅是晶片組，還有記憶體：您能告訴我建構事件如何按機器平台和記憶體配置劃分嗎？GPT-4：以下是每個平台内每種記憶體配置的成功建構事件數：
- Apple M1 Pro （16GB）：5,235 次建構事件
- Apple M2 Pro （16GB）：1,927 次建構事件
- Apple M2 Max （32GB）：3,842 次建構事件
- Apple M3 Pro 18GB：321 次建構事件
- Apple M3 Pro （36GB）：899 次建構事件
- Apple M3 Max （36GB）：301 次建構事件
Lawrence Jones 表示，“我們的 M1 Pro 和 M2 Max 之間的比較有些不公平，因為 M2 均具有 32GB 記憶體，是 M1（16GB）的兩倍。”
這可能就是性能如此不同的原因（盡管聲稱 Apple 電腦需要很少的 RAM），并且在決定是否應該更新到什麼規格的 M3 時會很有用。
值得慶幸的是，資料集中有來自具有 16GB 記憶體的 M2 Pro 的 2k 建構事件，是以 Lawrence Jones 繼續問 GPT-4：
您能否重新繪制 Apple M2 Pro 16GB 和 Apple M2 Max 32GB 标準化建構持續時間的直方圖比較？
最終得到如下結果：
要知道 M2 Pro 和 M2 Max 基本上是相同的晶片，主要差別在于 Max 具有兩個額外的“節能”核心。這些核心的功能大約是性能核心的 1/5，并且對編譯 Go 程式的貢獻最小，是以對我們的建構持續時間也有最小的貢獻。
那麼，這種比較是非常有用的：它意味着 32GB 的影響很小，也許隻是有助于快速建構時間的更高密度，但總體而言不是很明顯。
比較 M3 的不同版本
從目前的情況來看，記憶體容量為 16GB 的 M2 Pro 似乎成本效益最高，速度幾乎是 M1 的兩倍，比 M2 Max 稍慢（即使 Max 的記憶體容量是 M1 的兩倍）。
現在，我們需要弄清楚 M3 與 M2 相比是否有明顯的改進，為此，Lawrence Jones 也購買了一些新的筆記本：
M3 Pro，12 核（6 個性能核，6 個能效核）
- 1 個 18GB 記憶體
- 1 個 36GB 記憶體
M3 Max，14 核（10 個性能核心，4個能效核）
- 1 個 36GB
總共三台筆記本電腦，Pro 的記憶體有所不同，而購買 Max 則是為了測量我們是否能看到額外的 4 個 P 核心有多大差别。
如果從 Pro 開始：
向我展示 M3 Pro 18GB 和 M3 Pro 36GB 的建構持續時間柱狀圖。
之前得出的結論是，記憶體對建構性能的影響不大，是以這些圖表看起來相似也就不足為奇了。
事實上，由于缺乏資料，M3 的建構次數遠遠少于其他平台。基于此，Lawrence Jones 将兩個 M3 Pro 的結果合并起來：
向我展示 M3 Pro 18GB 和 36GB 組合與 M3 Max 的建構持續時間直方圖，去除非常快的建構時間（<3 秒）。
同樣，在這裡遇到的資料要少得多，但即便如此，M3 Max 看起來并沒有比已經很快的 M3 Pro 做出任何真正出色的事情。
至少，不足以證明比基礎版 M3 Pro 漲價 60% 是合理的。
M3 MacBook Pro 能提效？程式員、産品經理自證後，CTO：你赢了，新電腦在路上了
M1、M2、M3 一起比較
到目前為止，Lawrence Jones 表示：
- 已經建立了 M1 機器的基準線。
- 确定 M2 機器的性能相當，與記憶體或附加核心無關。
- M3 在 Pro 和 Max 上也相似。
那麼，接下來，是時候全面了解這些平台的比較了……
向我展示比較所有平台和記憶體組合的建構持續時間直方圖，不包括在 <3 秒内完成的建構。
請重複上述操作，但每行使用一個直方圖，并将 M1、M2 和 M3 平台合并。
這清楚地表明：
- 使用 M1 筆記本電腦的使用者經常需要等待近 2 米才能完成建構。
- M2 是 M1 機器的重大更新。
- M3 是 M2 的漸進式改進。
建議：
- 我們應該将所有 M1 使用者更新到基本的 M3 Pro 機型。
- M2 使用者不需要更新。
完畢！
One More Thing
通過以上對不同記憶體的電腦進行比較，Lawrence Jones 坦言，從測試的建構持續時間上來看，看不到從 ~16GB → 32GB 的有意義的改進。
那麼記憶體大小對程式開發是否會帶來影響？
作為開發者其實不難了解，有時候建構耗時比較長的原因在于連結器上。在連結器中，編譯後的 Go 包被連接配接在一起形成一個可執行二進制檔案。
為了測試，Lawrence Jones 提問道：
在我們的資料集中有一個 build_stages 列。我們可以在資料集中添加一個新列，稱為“linker_time”，它源自 build_stages.link.duration_seconds。
GPT-4：
該 linker_time 列已成功添加到資料集中。新列反映了從 build_stages 列内的 JSON 結構中提取的 linker 階段（link.duration_seconds）的持續時間，機關為秒。
這很好了解，遙測事件包含連結/編譯的持續時間，是以 Lawrence Jones 可以告訴 GPT-4 在建構事件中建立一列 linker_time：
請按照之前指定的順序繪制每個平台和記憶體組合的 linker_time 直方圖，并根據機器記憶體是 16-18GB 還是 32-36GB 給每個直方圖塗上不同的顔色。
這看起來完全不同！也就是說，每台記憶體大于 30GB 的電腦（M1、M2 或 M3）幾乎都能在 20 秒内完成連結，隻有記憶體小于或等于 18GB 的機器才會在 >20秒内完成連結。
所有這一切都意味着，隻需象征性地增加記憶體成本，就推薦購買 36GB 的記憶體，即使你認為這隻是“為未來做準備”。
CTO：M3 已經在路上了！
根據以上測試，無可辯駁，新款深空黑色的 M3 Pro 筆記本電腦不僅在外觀上看起來“倍有面”，而且還可以提高程式員的效率，縮短傳遞時間。
對于這樣的測試結果，Incident.io CTO Pete 現身在内網上也迅速回複道：“好吧好吧你赢了！這是我聽過為了更新電腦而展開的最好論點，以及也親證了一個真正令人印象深刻和愉快的書面報告。不過，基于這些資料，我顯然預計到 2024 年，大家的生産率會相應提高 10%。”
具體來說，該公司決定将其 M1 版電腦更新到具有 36GB 統一記憶體的基礎款 M3 Pro，但現在使用 M2 的程式還需要再等待一段時間，因為 M2 的性能表現得也不錯。
原文位址：https://incident.io/blog/festive-macbooks