標籤:style blog http io os 使用 sp for strong
引言
深入理解電腦系統,對我來說是部大塊頭。說實話,我沒有從頭到尾完完整整的全部看完,而是選擇性的看了一些我自認為重要的或感興趣的章節,也從中獲益良多,看清楚了電腦系統的一些本質東西或原理性的內容,這對每個想要深入學習編程的程式員來說都是至關重要的。只有很好的理解了系統到底是如何運行我們代碼的,我們才能針對系統的特點寫出高品質、高效率的代碼來。這本書我以後還需要多研究幾遍,今天就先總結下書中我已學到的幾點知識。
重點筆記
編寫高效的程式需要下面幾類活動:
- 選擇一組合適的演算法和資料結構。這是很重要的,好的資料結構有時能協助更快的實現某些演算法,這也要求編程人員能夠熟知各種常用的資料結構和演算法。
- 編寫出使編譯器能夠有效最佳化以轉換成高效可執行檔原始碼。因此,理解編譯器最佳化的能力和局限性是很重要的。編寫程式方式中看上去只是一點小小的變動,都會引起編譯器最佳化方式很大的變化。有些程式設計語言比其他語言容易最佳化得多。C語言的某些特性,例如執行指標運算和強制類型轉換的能力,使得編譯器很難對其進行最佳化。
- 並行技術,針對處理運算量特別大的計算,將一個任務分成多個部分,這些部分可以在多核和多處理器的某種組合上並行地計算。
讓編譯器展開迴圈
說到程式最佳化,很多人都會提到迴圈展開技術。現在編譯器可以很容易地執行迴圈展開,只要最佳化層級設定的足夠高,許多編譯器都能例行公事的做到這一點。用命令列選項“-funroll-loops”調用gcc,會執行迴圈展開。
效能提高技術:
- 進階設計,為手邊的問題選擇適當的演算法和資料結構,要特別警覺,避免使用會漸進地產生糟糕效能的演算法或編碼技術。
- 基本編碼原則。避免限制最佳化的因素,這樣編譯器就能產生高效代碼。
- 消除連續的函數調用。在可能時將計算移到迴圈外,考慮有選擇的妥協程式的模組性以獲得更大效率。
- 消除不必要的儲存空間引用。引入臨時變數來儲存中間結果,只有在最後的值計算出來時,才能將結果放到數組或全域變數中。
- 低級最佳化。
- 嘗試各種與數組代碼相對的指標形式。
- 通過開展通過展開迴圈降低迴圈開銷。
- 通過諸如迭代分割之類的技術,找到使用流水線化的功能單元的方法。
說到效能提高,可能有人會有一些說法:
(1)不要過早最佳化,最佳化是萬惡之源;
(2)花費很多時間所作的最佳化可能效果不明顯,不值得;
(3)現在記憶體、CPU價格都這麼低了,效能的最佳化已經不是那麼重要了。
……
其實我的看法是:我們也許不必特地把以前寫過的程式拿出來最佳化下,花費N多時間只為提升那麼幾秒或幾分鐘的時間。但是,我們在重構別人的代碼或自己最初開始構思代碼時,就需要知道這些效能提高技術,一開始就遵守這些基本原則來寫代碼,寫出的代碼也就不需要讓別人來重構以提高效能了。另外,有的很簡單的技術,比如說將與迴圈無關的複雜計算或大記憶體操作的代碼放到迴圈外,對於整個效能的提高真的是較明顯的。
如何使用代碼剖析程式(code profiler,即效能分析工具)來調優代碼?
程式剖析(profiling)其實就是在運行程式的一個版本中插入了工具代碼,以確定程式的各個部分需要多少時間。
Unix系統提供了一個profiling叫GPROF
,這個程式產生兩類資訊:
首先,它確定程式中每個函數花費了多少CPU時間。
其次,它計算每個函數被調用的次數,以執行調用的函數來分類。還有每個函數被哪些函數調用,自身又調用了哪些函數。
使用GPROF進行剖析需要3個步驟,比如來源程式為prog.c。
1)編譯: gcc -O1 -pg prog.c -o prog
(只要加上-pg參數即可)
2)運行:./prog
會產生一個gmon.out檔案供 gprof剖析器時候使用(運行比平時慢些)。
3)剖析:gprof prog
分析gmon.out中的資料,並顯示出來。
剖析報告的第一部分列出了執行各個函數花費的時間,按照降序排列。
剖析報告的第二部分是函數的調用曆史。具體例子可參考網上資料。
GPROF有些屬性值得注意:
- 計時不是很準確。它的計時基於一個簡單的間隔計數機制,編譯過的程式為每個函數維護一個計數器,記錄花費在執行該函數上的時間。對於已耗用時間較長的程式,相對準確。
- 調用資訊相當可靠。
- 預設情況下,不顯示庫函數的調用。相反地,庫函數的時間會被計算到調用它們的函數的時間中。
靜態連結和動態連結一個很重要的區別是:動態連結時沒有任何動態連結程式庫的代碼和資料節真正的被拷貝到可執行檔中,反之,連結器只需拷貝一些重定位和符號表資訊,即可使得運行時可以解析對動態連結程式庫中代碼和資料的引用。
儲存空間映射
指的是將磁碟上的空間映射為虛擬儲存空間地區。Unix進程可以使用mmap函數來建立新的虛擬儲存空間地區,並將對象映射到這些地區中,這屬於低級的分配方式。
一般C程式會使用malloc和free來動態分配儲存空間地區,這是利用堆的方式。
造成堆利用率很低的主要原因是片段,當雖然有未使用的儲存空間但不能用來滿足分配請求時,就會發生這種現象。
有兩種形式的片段:內部片段和外部片段。兩者的區別如下:
- 內部片段是在一個已指派的塊比有效載荷大時發生的。例如,有些分配器為了滿足對其約束添加額外的1字的儲存空間,這個1字的空間就是內部片段。它就是已指派塊大小和它們的有效載荷大小之差的和。
- 外部片段是當空閑儲存空間合計起來足夠滿足一個分配請求,但是沒有一個單獨的空閑塊足夠大可以來處理這個請求時發生的。
現代OS提供了三種方法實現並發編程:
- 進程。用這種方法,每個邏輯控制流程都是一個進程,由核心來調度和維護。因為進程有獨立的虛擬位址空間,想要和其他流通訊,控制流程必須使用處理序間通訊(IPC)。
- I/O多工。這種形式的並發,應用程式在一個進程的上下文中顯示地調度它們自己的邏輯流。邏輯流被類比為“狀態機器”,資料到達檔案描述符後,主程式顯示地從一個狀態轉換到另一個狀態。因為程式是一個單獨的進程,所以所有的流都共用一個地址空間。
- 線程。線程是運行在一個單一進程上下文中的邏輯流,由核心進行調度。線程可以看做是進程和I/O多工合體,像進程一樣由核心調度,像I/O多工一樣共用一個虛擬位址空間。
(1)基於進程的並發伺服器
構造並發最簡單的就是使用進程,像fork函數。例如,一個並發伺服器,在父進程中接受用戶端串連請求,然後建立一個新的子進程來為每個新用戶端提供服務。為了瞭解這是如何工作的,假設我們有兩個用戶端和一個伺服器,伺服器正在監聽一個監聽描述符(比如描述符3)上的串連請求。下面顯示了伺服器是如何接受這兩個用戶端的請求的。
關於進程的優劣,對於在父、子進程間共用狀態資訊,進程有一個非常清晰的模型:共用檔案表,但是不共用使用者地址空間。進程有獨立的地址控制項愛你既是優點又是缺點。由於獨立的地址空間,所以進程不會覆蓋另一個進程的虛擬儲存空間。但是另一方面處理序間通訊就比較麻煩,至少開銷很高。
(2)基於I/O多工並發編程
比如一個伺服器,它有兩個I/O事件:1)網路用戶端發起串連請求,2)使用者在鍵盤上鍵入命令列。我們先等待那個事件呢?沒有那個選擇是理想的。如果accept中等待串連,那麼無法響應輸入命令。如果在read中等待一個輸入命令,我們就不能響應任何串連請求(這個前提是一個進程)。
針對這種困境的一個解決辦法就是I/O多工技術。基本思想是:使用select函數,要求核心掛起進程,只有在一個或者多個I/O事件發生後,才將控制返給應用程式。
I/O多工優劣:由於I/O多工是在單一進程的上下文中的,因此每個邏輯流程都能訪問該進程的全部地址空間,所以開銷比多進程低得多;缺點是編程複雜度高。
(3)基於線程的並發編程
每個線程都有自己的線程上下文,包括一個線程ID、棧、棧指標、程式計數器、通用目的寄存器和條件碼。所有的運行在一個進程裡的線程共用該進程的整個虛擬位址空間。由於線程運行在單一進程中,因此共用這個進程虛擬位址空間的整個內容,包括它的代碼、資料、堆、共用庫和開啟的檔案。所以我認為不存線上程間通訊,線程間只有鎖的概念。
線程執行的模型。線程和進程的執行模型有些相似。每個進程的生明周期都是一個線程,我們稱之為主線程。但是大家要有意識:線程是對等的,主線程跟其他線程的區別就是它先執行。
一般來說,線程的代碼和本機資料被封裝在一個線程常式中(就是一個函數)。該函數通常只有一個指標參數和一個指標傳回值。
在Unix中線程可以是joinable(可結合)或者detached(分離)的。joinable可以被其他線程殺死,detached線程不能被殺死,它的儲存空間資源有系統自動釋放。
線程儲存空間模型,每個線程都有它自己的獨立的線程上下文,包括線程ID、棧、棧指標、程式計數器、條件碼和通用目的寄存器。每個線程和其他線程共用剩下的部分,包括整個使用者虛擬位址空間,它是由程式碼片段、資料區段、堆以及所有的共用庫代碼和資料區域組成。不同線程的棧是對其他線程不設防的,也就是說:如果一個線程以某種方式得到一個指向其他線程的指標,那麼它可以讀取這個線程棧的任何部分。
什麼樣的變數多線程可以共用,什麼樣的不可以共用?
有三種變數:全域變數、本地自動變數(局部變數)和本地靜態變數,其中本地自動變數每個線程的本地棧中都存有一份,不共用。而全域變數和靜態變數可以共用。
深入理解電腦系統9個重點筆記