程式中的「零成本抽象」如何實現？

前言：在高可用架構後花園群的一次討論中，有網友對 rust 社群追捧的 async/await 不太理解，說起來這些特性在 .net 中十多年前就存在了。對於這一點，rust 社群普遍的觀點是， rust 的 async/await 實現是零成本抽象，在無需增加額外全域性成本，僅在設計層面就實現了對非同步程式設計模型的支援，因此它跟之前別的語言的實現以及意義還是略有不同。考慮到「零成本抽象」這個概念不太好理解，並且程式設計師**設計中也可以借鑑這些思路，所以高可用架構翻譯了 rust 核心開發工程師 withoutboats 這篇文章：零成本抽象。

零成本抽象的思想對於某些程式語言來說是非常重要的，比如 rust 和 c++，它們的目的是讓使用者能夠用相對較少的精力寫出效能優異的程式。由於這個思想對於 rust 的設計和我的工作來說是如此重要，所以我想通過本文**一下零成本抽象到底是什麼。

這個想法是由 c++ 的早期開發者 bjarne stroustrup 總結出來的。

不用的東西，你不需要為之付出代價；再進一步說，用到的東西，你也不可能做得更好。

bjarne stroustrup

（為了避免翻譯不夠信雅達而影響原意，譯者補充這句話英文原文如下：）

what you don』t use, you don』t pay for. and further: what you do use, you couldn』t hand code any better.

在這個定義中，有兩個因素構成乙個適當的零成本抽象。

然而，我認為需要關注的是零成本的抽象還有第三個要求，這一點經常被忽略，因為它是所有好的抽象的乙個需求，不管是不是零成本抽象。

對於零成本抽象來說，第三點其實特別重要，因為零成本抽象需要面對兩個不同的競爭者。一方面，它一定比自己手寫**的在效能引數相同的情況下更有優勢，這一點相當明確。但另一方面，它也一定比那些消耗效能以及使用非零成本的抽象要好。這並不意味著我們需要嚴格地比非零成本的抽象要好，因為效能成本是乙個因素，但我們確實得把控好這個距離，使得即使承擔額外的程式設計師開銷，你都會覺得「零成本」是值得的。

（我認為 rust 在某種程度上試圖欺騙了這一點，讓非零成本抽象的**不太好實現，從而讓人覺得零成本的抽象更好。我認為這是乙個錯誤，它傷害了語言的整體使用者體驗，可能讓一些人根本不願意使用它，從而傷害了我們的整體目標）。

我還想說的是，真正創造乙個零成本的抽象來實現這三點，是非常困難也是非常了不起的。rust 只有幾次真正出色地做到了這一點（都是極高的影響力），我參與了這些成功案例中的乙個，那當然是 async/await，感覺就像手握火種一樣。去年 9 月，我曾對一位朋友說，我擔心自己以後永遠也不可能做出這麼漂亮的工作（指的是 pin api），我確實有這種感覺。但我們很少有機會做出這麼偉大的事情，因為它的難度極高，而且還涉及到相當多的運氣成分（很多問題可能只是真正偉大的零成本抽象還沒有被發現，至少在之前的設計約束下）。

為了更明確表達我的觀點，我想列舉幾個 rust 中真正偉大的零成本抽象。

在其他領域，我們還沒有那麼成功地找到零成本抽象。這方面的乙個例子就是將 trait 物件作為動態排程多型的解決方案。(這裡要注意，這裡的動態排程是需求的一部分，所以虛擬呼叫不是非零成本的)。問題是物件的安全，以及有大小的型別（sized type）和非大小型別（unsized type）概念，型別轉換的不好的語法，使得 trait 物件在工作中真的很不方便；當我不得不使用它們時，我通常會很苦惱。至少在過去的 18 個月裡，我一直想真正挖掘這個問題空間，但其他的事情總是佔據了我的優先順序。

英文原文：

參考閱讀：

高可用架構

改變網際網路的構建方式

程式中的「零成本抽象」如何實現？

「免費」往往並非零成本

零成本提公升利潤的秘密

口碑化營銷零成本推廣

程式中的「零成本抽象」如何實現？

「免費」往往並非零成本

零成本提公升利潤的秘密

口碑化營銷 零成本推廣

相關推薦

口碑化營銷零成本推廣