C ++標准庫與凡人制作代碼+我在哪里可以找到來源？

Question

兩個，也許是微不足道的問題：

1.為什么我不能擊敗STD功能？

真。 我花了最后三天實現比std :: sort更快的東西，只是為了做到這一點。 它應該是一個introsort，我懷疑它使用單個pivot版本quicksort里面。 史詩失敗。 我的速度至少慢了兩倍。

在我的痛苦中，我甚至復制粘貼其他 - 頂級 - 程序員代碼。 徒勞無功。 我也對我的其他算法進行了基准測試...我的二進制搜索，以及upper_bound，lower_bound版本都被剝離了，實際上並沒有用更少的指令。 不過，它們的速度大約是其兩倍。

我問，為什么，為什么，為什么？ 這引出了我的下一個問題......

2.在哪里可以找到STL庫函數的源代碼？

當然，我想看看他們的消息來源！ 是否有可能編寫比這些更高效的代碼，或者我是否處於抽象級別與我的“簡單”main.cpp，我無法達到STL庫使用的優化？

我的意思是舉例......讓我們拿地圖......這是簡單的聯想容器。 文檔說它是用紅黑樹實現的。 現在......嘗試實現我自己的紅黑樹是值得的，或者他們帶着這種喜悅:-)遠離我，我應該把我得到的所有數據都扔到地圖容器中？

我希望這確實有意義。 如果沒有，請原諒我。

---

Answer 1

簡短的回答是“如果可以編寫更快的代碼來執行相同的操作，那么標准庫就已經完成了”。

標准庫是由聰明的人設計的，它成為C ++的一部分的原因是其他聰明的人認為它是聰明的。 從那以后，15年過去了， 其他聰明的人試圖采用這些規范並編寫絕對最有效的代碼來實現它們。

這是你想要與之競爭的很多聰明。 ;）

所以STL中沒有魔法，他們不會作弊，也不會使用你無法使用的技巧。 它經過精心設計，可以最大限度地提高性能。

關於C ++的事情是，它不是一種快速的語言。 如果你不小心，很容易引入各種低效：虛函數調用，緩存未命中，過多的內存分配，不必要的對象復制，所有這些都會削弱C ++代碼的性能，如果你不小心的話。

小心，您可以編寫與STL一樣高效的代碼。 它並不那么特別。 但總的來說，獲得更快代碼的唯一方法就是改變需求。 標准庫必須是通用的，以便在所有用例中盡可能地工作。 如果您的要求更具體，有時可以編寫有利於這些特定情況的專用代碼。 但是，在其他情況下，權衡是代碼要么不起作用，要么效率低下。

最后一點是STL如此聰明的原因以及為什么它被采用到標准中的一個關鍵部分是，它幾乎是零開銷。 許多語言的標准庫“足夠快”，但不如手動代碼快。 他們有一個排序算法，但它並不像你自己就地編寫它那么快。 它可能會在常見的“對象”基類中使用一些強制轉換，也可能在值類型上使用裝箱。 STL的設計使得幾乎所有東西都可以被編譯器內聯，產生的代碼相當於你自己手動編寫的代碼。 它使用模板專門針對您正在使用的類型，因此轉換為容器或算法所理解的類型沒有任何開銷。

這就是為什么很難與之競爭的原因。 這是一個非常有效的圖書館，它必須是。 根據普通C或C ++程序員的心態，特別是10 - 15年前， 沒有人會使用std::vector如果它比原始數組慢5％。 沒有人會使用迭代器和std算法，如果它們沒有自己編寫循環那么快。

因此，STL開創了許多聰明的C ++技巧，以便與手動C代碼一樣高效。

Answer 2

它們可能在很大程度上得到優化。 此類實現考慮了內存頁面錯誤，緩存未命中等。

獲取這些實現的來源取決於它們隨附的編譯器。 我想大多數編譯器（甚至微軟）都會允許你看到它們。

我認為最重要的事情是你要編譯的架構和你的程序將運行的操作系統（如果有的話）。 了解這些內容可以讓您精確定位硬件。

還有無數的優化技術。 這是一個很好的總結。 此外，全球優化是整個科學，因此肯定有許多東西需要學習。

這個網站上也有一些聰明的東西 。 Sok sikert！

Answer 3

查看代碼的反匯編版本與其代碼並進行比較可能會讓您了解為什么它們比您的更快。

為了制作更快的版本，從頭開始重新實現標准庫功能似乎是一件愚蠢的事。 嘗試修改他們的版本以實現目標會更好，盡管即便如此，您仍然需要了解底層平台才能判斷您所做的更改的價值。

我猜你要發布你的排序例程，它會在幾分鍾內被拆散，你會理解為什么你的版本比標准庫版本慢得多。

Answer 4

大多數IDE都有一個命令，可以使用編譯器的搜索路徑打開命名頭文件。 我經常使用它，並傾向於保持algorithm的代碼打開。

對我來說，你正在尋找的代碼是

/usr/include/c++/4.2.1/bits/stl_algo.h
/usr/include/c++/4.2.1/bits/stl_tree.h

請注意，很多人已經完成了關於排序和樹平衡的論文（我認為這些領域已被選中，我不會嘗試在那里進行研究），其中許多人可能比你更有決心制作GCC的標准庫快點。

也就是說，總是有可能利用特定於您的代碼的模式（一些子范圍已經排序，經常使用特定的小序列大小等）。

Answer 5

兩個答案，可能一般適用：

• 您可能無法實現更高效的算法版本，許多其他智能人員花費了更多時間進行優化。 憑借時間和測試，STD算法將非常好。

• 對於相同的算法，優化是對所有當前硬件和配置變化“非常困難”的事情。 舉一個例子，特定平台上算法性能的主要因素可能是其最常用的例程可以存儲在哪個級別的緩存中，這通常不是手工優化的。 因此，與您可以編寫的任何特定代碼相比，編譯器通常更多地是實際算法性能的一個因素。

但是，是的......如果你真的認真對待優化，那么請進入組裝並進行比較。 不過，我的建議是專注於其他事情，除非你的工作是優化你的實現或其他什么。 只是我的2c。