讀書摘要-Efficient C++ performance programming techniques

Chp 1 The Tracing war story

 
    當你的代碼規模超過幾千行後，tracing就變得很必要了。

    當在一個很小卻被頻繁調用的函數中加入tracing 機制時，如果不注意的話，tracing可能會成數量級的降低系統的效能。

    在C++程式中，不必要的物件建構和銷毀，會帶來非常大的開銷。

    那些適合inline調用的函數，往往不適合當作tracing的目標。



Chp 3 Virtual Function

    程式語言的發展傾向於通過將更多的工作轉移到編譯器、解譯器、彙編器和連接器上，來使得編程的任務更為輕鬆。虛函數機制就是將類型解析的任務轉移到了編譯器身上。

    虛函數機制帶來的時間開銷有以下三點：

    1.建構函式中需要正確設定vptr
    2.函數調用需要通過指標間接進行
    3.虛函數的特性與inline難以協同工作

    這三點中，第三點對於效能的影響因素是最大的。


    當某個虛函數成為效能瓶頸時，解決方案有兩種──手動寫入程式碼執行類型判斷，或者通過模板參數機制。

    模板機制往往有較好的效能，因為它將類型解析從運行期前推至編譯期。

Chp 4 Return Value Optimization

    RVO的 基本思路是消除函數內部的局部變數，所有的操作都變為在要返回的臨時變數上直接進行。

    編譯器最佳化的基本前提是保持正確性;對於RVO，這並不總是件容易的事情;當函數中有多個return 語句，且返回的是不同的局部變數時，RVO顯然無法維持語意的正確性──因此，在這種情況下，RVO是不被啟用的。

    簡單的說，RVO的前提是函數的所有return 語句都返回同一個局部變數。

    雖然標準規定named or unamed return value 都可以被最佳化掉，但是從實現的角度來看，unamed return value 被最佳化掉的幾率更大。
   
    此外，啟用RVO還需要class 提供一個copy constructor，否則RVO會被靜悄悄的關閉。

Chp 5 Temporaries

    函數的RVO按照激進程度，大致可分為兩個程度

    1.    消除函數內部的局部變數，直接在要返回的臨時對象上執行各種操作；

    2.    在例如" T t=foo ()"的運算式中，將函數foo()要返回的臨時對象也消除掉，直接在最終對象上執行各種操作(這種最佳化的前提是"="的語意是初始化，而不是賦值)

Chp8  Inline Basics

    Inline的代價之一是導致了編譯時間的增長。


深刻理解函數調用的開銷

    IP( Instruction Pointer):通常也被稱為PC(program counter,程式記數器)，包含下一條指令的地址

    LR(Link Register):存放當前函數執行完返回後要執行的下一條指令的地址

    SP(Stack Pointer):記錄棧的使用方式

    AP(Arugment Pointer)：指明參數在棧中的位置

    FP(Frame Pointer) :用於分隔棧上不同的 function frame

    一般來說，函數調用和返回的開銷為25~100 cycle

    異常的存在會降低啟用RVO的可能性。

    Inline的一個重要優點在於減少了分支條件的影響；分支條件的存在，對於大量採用指令流水線預取技術的現代處理器，會造成顯著的效能下降。

    一方面，Inline消除了函數調用和返回對應的機器碼，程式的尺寸傾向於變小；另一方面，由於函數體的代碼重複出現，又傾向於增大程式尺寸。

   

Chp 9 Inlining—Performance Considerations

    Inline的優點在於消除函數調用的開銷；然而這隻是故事的一面。inline的意義還在於允許編譯器掌握更多的資訊，從而更好的進行"cross-all optimization"，在資訊更豐富的上下文環境下更好的進行最佳化。

    cross-call optimizaition 一般表現在將原本在運行期執行的運算提前在編譯期完成。

    與消除函數調用開銷相比，cross-call optimization 所產生的效能提高要更為明顯;然而另一方面，cross-call 嚴重依賴與編譯器的效能，可靠性不如前者。

    用類比的方法來說，對於Inline所能獲得的效能提升，cross-call optimization是兔子，而函數調用開銷的消除則是那隻烏龜。
   
    字面常量在最常見的最佳化中起著關鍵作用。

    要警惕inline可能導致的代碼膨脹，進而降低程式的局部性特性，增大cache miss的幾率，從而完全抵消甚至超出了inline所帶來的優點。

    此外，inline還會增加編譯依賴，任何對實現的修改都會導致依賴於該函數的模組的重新編譯。

Chp 12 引用計數

    毫無疑問，在減少記憶體消耗方面，引用計數是很好的機制；但涉及到速度問題，則沒有確定的答案。

    如果對象並不佔用很多資源，且系統中共用對象的情況並不頻繁，那麼引用計數會導致效能的下降──因為引用計數意味著原本在棧上分配的空間改為在堆上分配，這顯然相比之下是個更昂貴的操作，即引用計數對象在第一次建立時開銷是很大的。

    反過來，如果對象本身佔用的資源較大，且系統中共用對象的情形很頻繁，那麼採取引用計數則是最佳選擇。

Chp 14 Design Optimizations

    從根本上說，程式的靈活性和高效性是相互對立的兩個目標。

Chp 15 Scalability

SMP的基本特點

    1.    Multiple Processer
    2.    所有Processor在系統中處於同等地位
    3.    其它一切仍然是single的，如單一記憶體，單一核心代碼，單一運行隊列

    SMP的瓶頸在於Bus，常見的解決機制在於為每個Processor引入獨立的Cache，然而這又導致了Cache Coherence 問題，通常通過硬體級的更新協議來解決，對於軟體而言是透明的。

Thundering Herd(轟鳴的獸群)

    當多個Thread都在同一資源(例如lock)上suspend時，需要考慮當該資源被當前擁有者釋放時，應該如何處理這些suspend的Thread？

    1.    只喚醒其中一個Thread，例如優先順序最高，或者suspend時間最久的那個


    2.    喚醒在該資源上suspend的所有Thread，這將導致Thundering
Hurd現象──雖然所有Thread都被喚醒，但只有一個Thread最終能獲得資源，其它Thread在執行完開銷高昂的進程切換獲得CPU控制權後，能做得的只是再次suspend，這嚴重降低了效能。

    當Thundering Hurd發生的機率較大時(資源較少而Thread很多)，更多的Thread只會意味著更差的效能。

    Thundering Hurd的本質在於大量Thread在競爭少量資源。

Chp 16 System Architecture Dependency

Memory Hierarchies

    Access time is a latency issue: How long does it take to start getting data?  

    Width is bandwidth issues: How much data can I get once it starts arriving?


    This is akin to the notion of a fire hose: How long does it take to
open the valve, once it is open how much water does the hose deliver
per second, and how much water is in the trunk?
   
    Latency的提高速度不如Bandwidth的提高那麼快，對於記憶體和硬碟，都是如此。

    通常，L1 Cache和寄存器相比，在Latency上差別不大，但在Bandwidth上處於劣勢。