|
來源：Digi-Key 作者：Lee Teschler 過去，在微處理器芯片剛剛問世的黑暗時代，工科大學(xué)生往往是在 DEC PDP-11 小型計(jì)算機(jī)等機(jī)器上首次嘗試正經(jīng)的計(jì)算機(jī)編程。除了盡力編寫能夠在 PDP-11 上正確運(yùn)行的程序外，當(dāng)時的學(xué)生還必須保證他們編寫的代碼緊湊。在早期計(jì)算機(jī)課程中，有一種情況會激怒老師，那就是提交一個本來用 15 行代碼就可以完成的 20 行匯編碼程序。他們出現(xiàn)這樣的反應(yīng)當(dāng)然不是沒有理由，因?yàn)楫?dāng)時的內(nèi)存非常昂貴。PDP-11 的讀/寫存儲器通常只能存儲 4,096 個 16 位字，該存儲器由 22 密耳磁芯組成，這些磁芯通過導(dǎo)線進(jìn)行訪問。 
Digital Equipment Corporation (DEC) 的 PDP-11 計(jì)算機(jī)。（圖片來源：flickr） 時至今日，您會發(fā)現(xiàn)編程課程仍然強(qiáng)調(diào)代碼緊湊的重要性。但有跡象表明，編程課程可能很快就不再只是要求編寫緊湊代碼，而是還會要求編寫能耗最低的軟件。 計(jì)算機(jī)代碼能效曾經(jīng)是一個小眾話題。以前主要是小型嵌入式系統(tǒng)的程序員對其感興趣，因?yàn)樵谶@類系統(tǒng)中，必須關(guān)注 MCU 的功耗，目的是最大限度地延長供電紐扣電池的壽命。現(xiàn)如今，軟件能效正在占據(jù)主流。越來越多的智能手機(jī)用戶避免使用計(jì)算密集型應(yīng)用程序，只為了多節(jié)省一點(diǎn)電量。甚至基于云的系統(tǒng)也會注重軟件能效，因?yàn)樗鼤绊憯?shù)據(jù)中心的碳排放。 乍看之下，您可能會覺得緊湊代碼已經(jīng)很節(jié)能。事實(shí)證明，這條經(jīng)驗(yàn)法則有時正確，但并非總是如此。此外，計(jì)算機(jī)程序的能效通常取決于編寫程序所用的語言。編譯語言比解釋語言或編寫虛擬機(jī)的語言更節(jié)能。但即使看似相互關(guān)聯(lián)的編譯語言，能效也可能存在很大差異。 葡萄牙的研究人員深入分析了能源、時間和內(nèi)存使用與節(jié)能編程之間的關(guān)系 (https://dl.acm.org/doi/10.1145/3136014.3136031)。他們分析了 27 種軟件語言的能效性能。為此，他們使用了最先進(jìn)的編譯器、解釋器和虛擬機(jī)，并觀察了運(yùn)行 13 個不同程序時發(fā)生的情況，利用這些程序比較了廣泛使用的算法采用各種常用編程語言時的實(shí)現(xiàn)情況。 例如，用某個基準(zhǔn)程序計(jì)算系統(tǒng)中多個粒子之間相互作用所需的時間。用另一個基準(zhǔn)程序分配和釋放大量二叉樹。再用一個基準(zhǔn)程序更新哈希表，并用該表來計(jì)算特定的 DNA 核苷酸序列。 研究人員發(fā)現(xiàn)，人們往往誤以為軟件的能耗與執(zhí)行時間成正比：運(yùn)行越快一定越好。由此認(rèn)為，縮短程序的執(zhí)行時間將會減少相同比例的能耗。但這種關(guān)系并不一定這么簡單，因?yàn)槟芎氖撬霉β逝c持續(xù)時間的乘積。因此，如果更快的程序在執(zhí)行時功耗更高，則其不見得能效更高。 最終，研究人員在幾個實(shí)例中發(fā)現(xiàn)，編程語言的能耗排名與其執(zhí)行時間的排名并不相同。例如，在涉及隨機(jī) DNA 序列生成和寫入的基準(zhǔn)測試中，F(xiàn)ortran 被證明是能效第二高的語言，但它在執(zhí)行時間方面卻排在第八位。在計(jì)算二叉樹時，Pascal 和 Chapel 語言的能耗相差在 10% 以內(nèi)，但 Chapel 的執(zhí)行時間卻少了約 55%。 研究人員的一些結(jié)論并不令人驚訝。其中一項(xiàng)發(fā)現(xiàn)是：總體而言，C 語言最快且最節(jié)能（57 J，平均執(zhí)行時間為 2,019 毫秒）。在 C 語言之后，執(zhí)行基準(zhǔn)測試所需能量和時間最少的四種語言分別是 Rust（59 J，2,103 毫秒）、C++（77 J，3,155 毫秒）、Ada（98 J，3,740 毫秒）和 Java （114 J，3,821 毫秒）。正如您所料，編譯語言比解釋語言或虛擬機(jī)語言更節(jié)能。編譯程序執(zhí)行解決方案平均消耗 120 J，而虛擬機(jī)和解釋語言分別消耗 5,760 J 和 2,365 J。 毫無意外，能效和執(zhí)行時間排在末位的五種語言均為解釋語言：能耗方面：Perl (4,604 J)、Python (4,390 J)、Ruby (4,045 J)、JRuby (2,693 J) 和 Lua (2,660 J)；執(zhí)行時間方面：Lua (16,7416 毫秒)、Python (14,5178 毫秒)、Perl (13,2856 毫秒)、Ruby (119,832 毫秒) 和 TypeScript (93,292 毫秒)。 研究人員還指出了大部分耗散能量的去向。基于 CPU 的能耗始終占所消耗能量的大多數(shù)。平均而言，無論編譯語言、解釋語言還是虛擬語言，CPU 能耗幾乎都高達(dá) 90%，其余為 DRAM 能耗。 總而言之，葡萄牙研究人員認(rèn)為，如果開發(fā)人員只考慮執(zhí)行時間和能耗，那么確定最佳軟件語言相對容易。但是，如果考慮內(nèi)存使用因素，則無法不假思索地做出選擇。 因此，對于地球來說有一個好消息：可以通過優(yōu)化軟件來提高能效。對于學(xué)習(xí)編程的學(xué)生而言有一個壞消息：現(xiàn)在，您不僅會因?yàn)樘峤坏某绦虿粔蚓o湊而讓編程老師不悅，程序的能效低也會有同樣的結(jié)果。 |
