我的 JavaScript 比你的 Rust 更快
Josh Urbane 是一位從業(yè)多年的軟件架構(gòu)師，很喜歡在社交媒體分享技術(shù)觀點。近日，他寫了一篇文章，記錄了自己憑借經(jīng)驗贏了與新人開發(fā)者打賭的故事，而“我的 JavaScript 比你的 Rust 更快”的結(jié)論也是來自這個打賭。他的故事或許可以說明運行策略在研發(fā)實踐中的重要性。
對我來說，軟件架構(gòu)師這活兒最讓人開心的一點就是能指導(dǎo)開發(fā)者理解最新的概念、影響他們的技術(shù)判斷。有些開發(fā)者不是很囂張嗎，那就用理論加現(xiàn)實啪啪打他們的臉；架構(gòu)師還得負責(zé)營造出寓教于樂的學(xué)習(xí)氛圍，幫助年輕氣盛的開發(fā)者逐漸長大成熟。
最會讓我在心里暗爽的事兒就是一個愣頭青開發(fā)者突然跳出來、想要挑戰(zhàn)我的技術(shù)建議（從開發(fā)者的視角看，架構(gòu)師就是一幫總在提「錯誤」建議的傻瓜），而且賭上全部身家堅持認為自己的辦法更好。
問題是，我已經(jīng)干這行很久了，不用驗證我就知道問題的正確答案是什么。所以那就來唄，咱們手底下見真章，我把這段故事記錄了下來、在幾年后整理成了今天的這篇文章。
梭哈是一種“智慧”
老實講，下面要講的這個事已經(jīng)過去好幾年了，所以很多細節(jié)我已經(jīng)記不清楚。大體情況就是結(jié)合當(dāng)時團隊的知識儲備、可用工具庫和原有技術(shù)債務(wù)，我給出的建議是讓大家使用 Node.js。
一個新任初級開發(fā)者對自己剛拿到的計算機科學(xué)學(xué)士證書很有信心，想要用“炫技”的方式挫挫我的銳氣。他們聽說我是輔修的計算機科學(xué)，所以覺得我壓根不了解計算機底層原理。其實剛畢業(yè)那會我也認為自己很懂，但這行干久了，我越來越覺得計算機系統(tǒng)像是魔法……
他的信心并非毫無來由，這個結(jié)論如同“C++ 比 JavaScript 速度快”，基本屬于業(yè)界共識。但作為典型的架構(gòu)師，我仍然堅持認為“要視情況而定”。
更具體地講，“經(jīng)過充分優(yōu)化的 C++，確實比具有同等優(yōu)化水平的 JavaScript 跑得更快”，畢竟 JavaScript 有著無法避免的執(zhí)行開銷（即便如此，我們也可以把代碼編譯成靜態(tài)程序來獲得高度接近 C++ 的性能）。反正話已至此，那就梭了唄。
意外的是，JavaScript 代碼確實要比 C++ 版本更快一點，而且從架構(gòu)設(shè)計的角度來看，JS 版本可以由當(dāng)前團隊一力維護、不需要借助其他部門的技術(shù)能力。
還好還好，其實我也不敢百分之百確定自己是對的，但考慮到這個用例中的內(nèi)存對象大小可能是動態(tài)的、再加上那位年輕開發(fā)者確實經(jīng)驗不足，所以我愿意賭上一把。
JS 比 C++ 還快，怎么實現(xiàn)的？
我猜大多數(shù)開發(fā)者都理解不了這樣的結(jié)果。這明顯跟“編譯”語言快于“解釋”語言、“靜態(tài)”程序快于“VM”程序的基本原則背道而馳啊。但請注意，這些只是經(jīng)驗、而非真理。
我之前也提到，“優(yōu)化”才是決定速度的關(guān)鍵。畢竟即使 C++ 語言自身的性能優(yōu)勢再強，糟糕的編寫質(zhì)量也會讓程序身陷泥潭。另一方面，Node.js（使用基于 C++/C 的 V8 與 libuv 庫）則更具優(yōu)化空間，所以實際運行速度并不差。甚至可以說，質(zhì)量同樣差勁的 JS 和 C++ 程序，JS 的性能可能還更好一點。但這只是宏觀論述，下面咱們來看點細節(jié)。
內(nèi)存是關(guān)鍵
大多數(shù)開發(fā)者應(yīng)該很熟悉棧和堆的概念，但這種理解基本只停留在了表面——例如只知道棧是線性的，而堆就是帶有指針的“坨”（并非嚴格術(shù)語，大家能理解就行）。
更重要的是，棧和堆的概念對應(yīng)著多種實現(xiàn)和方法。底層硬件并不知道“堆”是個什么東西，因為內(nèi)存的管理方式是由軟件來定義的，而內(nèi)存管理方面的選擇必然會對程序的最終性能產(chǎn)生巨大影響。
大家也可以就這個問題深挖下去，很有意義也很有價值。現(xiàn)代硬件和內(nèi)核都相當(dāng)復(fù)雜，其中往往包含大量具有特殊用途的優(yōu)化機制，例如更高效地利用高級內(nèi)存布局。這意味著軟件可以（或者必須）借用由硬件提供的內(nèi)存管理功能。此外還有虛擬化的影響……這里就不多做展開了。
魔法的核心：垃圾回收
沒錯，Node.js 解決方案的啟動時間肯定更長，因為它需要通過 JIT 編譯器來實現(xiàn)腳本的加載和運行。不過一旦加載完成，Node.js 代碼其實反而擁有一項神秘的優(yōu)勢——垃圾回收機制。
而在 C++ 程序中，應(yīng)用程序往往會在堆中創(chuàng)建動態(tài)大小的對象，之后再將其刪除。這意味著程序的分配器必須一遍又一遍地在堆中分配和釋放內(nèi)存。這項操作本身速度較慢，而且實際性能基本由分配器中的算法決定。在多數(shù)情況下，dealloc 的速度會特別慢，即使是精簡后的 alloc 也沒好太多。
對于 Node.js 程序，這項絕技就是程序只運行一次就會退出。Node.js 同樣運行腳本并分配必要的內(nèi)存，但后面的刪除操作會由垃圾回收器挑選空閑時間再推遲執(zhí)行。
誠然，垃圾回收機制在本質(zhì)上并不比其他內(nèi)存管理策略更好或者更差（一切都是權(quán)衡），但在我們打賭的這個特定程序中，垃圾回收確實能顯著提升性能，因為這個程序壓根就沒真正運行過。我們只是把一大堆對象塞進內(nèi)存，再在退出時一次性丟棄。
垃圾回收肯定是有代價的，Node.js 進程占用的內(nèi)存容量明顯大于 C++ 程序。這就是“省 cpu= 費內(nèi)存”和“省內(nèi)存 = 費 cpu”的經(jīng)典難題，但我的目標(biāo)就是打那小子的臉，所以費點內(nèi)存也無所謂。
而我之所以能贏，是因為對方選擇了一個幼稚的策略。其實他要想贏，最好的辦法就是添加內(nèi)存泄漏，故意把所有分配都保留在內(nèi)存當(dāng)中。這樣 C++ 程序的內(nèi)存占用量還是更小，但速度卻比原先快得多。或者，他也可以用給棧分配緩沖區(qū)之類的設(shè)計來進一步提高性能，這種辦法在實際生產(chǎn)中其實經(jīng)常用到。
另外還有如何選擇性能基準(zhǔn)的問題。一般來說，大家比較的就是每秒操作數(shù)量。這里的 JS 對 C++ 就是個很好的例子，證明了“先理解總體性能成本，再做選擇”往往更加靠譜。在軟件架構(gòu)中，我們必須得時刻關(guān)注資源層面的“總體擁有成本”。
轉(zhuǎn)載請在文章開頭和結(jié)尾顯眼處標(biāo)注：作者、出處和鏈接。不按規(guī)范轉(zhuǎn)載侵權(quán)必究。
未經(jīng)授權(quán)嚴禁轉(zhuǎn)載，授權(quán)事宜請聯(lián)系作者本人，侵權(quán)必究。
本文禁止轉(zhuǎn)載，侵權(quán)必究。
授權(quán)事宜請至數(shù)英微信公眾號(ID: digitaling) 后臺授權(quán)，侵權(quán)必究。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）