處理器的微架構

一個民族有一些關注天空的人，他們才有希望。

　　我們在硬件構建的世界里編寫代碼，在CPU的跳動聲中運行代碼，如果不去關心這一切是如何實現的，我們程序的效率必定會達到一個認知的瓶頸。在那時，我們自以為自己的代碼已經達到完美，殊不知在那只是一個里程碑式的開始。

　　今天這篇文章主要談及的是處理器的微架構的流水線作業部分：

流水線

流水的思想

　　如果程序的執行被限定為逐步依次執行的話，那么提高CPU的速度無非是提升主頻、加快數據傳輸。然而數電的知識告訴我受限于三極管的高頻效應，當達到MHz級別之后，將元器件允許的頻帶每拓展100MHz都將是一個巨大的挑戰。而流水線的引入是一個巨大的突破，將頻帶的拓寬不再僅僅決定于硬件本身特性，更決定硬件電路的算法，而理解流水線的工作原理對理解多線程也有很大幫助。

　　借用了工廠中流水線的模型，我們把一條指令的實現分為幾個步驟交給幾個部件去實現（一般盡可能地分成等時長的步驟，否則可以增多執行長時間步驟的部件數量。）：取指令、譯碼、執行（這只是一個最基本的模型）。那么指令的實現就可以如下表示：

　　很顯然，在等時長的理想情況下，處理速度一下子變為了以前的三倍。（IF：取指令，ID：譯碼，EX：執行）

　　但是，等時長只是一個假設，如果（事實上也是肯定的）各個步驟長短不一，那就無法避免地會出現節拍混亂（即如前一指令EX還未執行完成，這一條EX卻已經開始了）。處理器采用寄存器作為緩沖，先把此時鐘周期完成的步驟的值存在寄存器中，然后再下一周期開始時才把數據傳給右端節拍。這樣，寄存器就像一個紅綠燈一樣，在同步操作中占有重要地位。

流水線的冒險

　　并行雖然加快了速度，卻不可避免地帶來了更多的硬件上的沖突，所以也可以是達到瓶頸后必經的歷練：

　　　　結構冒險：在當前后指令需要對同一資源進行訪問的時候發生。比如第一條指令的讀取存儲器步驟（MEM）與第四條指令的（從存儲器）取指令需要對同一存儲器進行訪問時，就會發生沖突。

　　

?　　　　　　這并不是程序員需要關心的，現代的硬件電路設計已經讓編譯器具有了智能調度的能力。

　　　　數據冒險：在第二條指令用到了第一條指令正在修改的數據時發生。這樣往往需要通過延遲一周期或者滿足一定條件地直接從寄存器中加載修改后的數據。

?

　　　　　　不得不說如果以一定次序進行編碼，并且編譯器采用順序執行（而非之后要提到的亂序執行），這是無法避免的損失。另外我們并不知道一條指令會被機器拆成多少個步驟，當然如果能降低毗鄰代碼的耦合度，則能對所硬件平臺都能避免數據冒險的發生。

　　　　控制冒險：在跳轉語句時發生。因為站在匯編語言的角度，一旦發生跳轉，幾條正在裝載的語句的步驟都失去了意義，根據不同的硬件平臺，消除這些加載的數據都會降低一定的效率。而當循環次數很多的時候，效率的降低將是非常明顯的。

　　　　　　然而這也不是程序員需要操作的事情（只是為了之后的理解），因為硬件邏輯在很大程度上規避了這樣的問題。通過之后提到的，記錄以往發生跳轉的記錄對此次跳轉位置進行記錄，然后從預測點開始預加載步驟，這樣就不會浪費資源，而在追求功耗的DSP中會講工作交給程序員。

從順序到亂序

　　因為硬件上的限制，訪問內存的速度是很慢的（當然還有一些其他的耗時間的操作，這只是一個例子）雖然一些編譯器能夠智能地根據數據的使用頻率將數據加載到不同級別的緩存當中，然而仍可以充分地利用等待讀取數據的時間：優先進行不依賴于正在被讀取的數據的指令。

　　首先需要知道如何判定是否相互依賴呢？應該找到兩條指令發生依賴關系原因，而它們往往是以下兩點（從匯編語言的角度）：

　　　　1、寄存器相關

　　　　　　在指令中用到了相同的寄存器，事實上它們并不一定有相關性，有可能只是因為可見的寄存器太少了。

　　　　2、控制相關

　　　　　　程序中的條件跳轉指令影響到了程序的走向。如緊跟在CMP指令后的JNZ指令。這里的優化主要是編譯器的工作，可以根據以往的經歷對未來的跳轉位置進行預測。

???

　　以上兩點提醒我以后編寫對效率要求很高的程序時：

　　　　1）盡量去除數據相關。例如：

x = a + b;y = x + c;z = y + d;

　　　　　　可以改寫為：

x = a + b;y = c + d;z = x + y;

?

　　　　2）盡量去除實際并不相關的相關。例如：

　　　　　　

C=A+B； F=D+E；

　　　　　　本來是不相關的，但是由于用戶可見的寄存器太少了，變量會映射到同一個寄存器上，它們就像偽軍一樣是可以爭取的對象，具體方法是通過對每條指令的目的寄存器映射到新的物理寄存器來解除依賴關系。（當然這樣費神的工作也只有核心程序值得這樣付出了）。

?

總結與思考

　　　有人說程序=算法+數據結構，然而我想這句話只適合很久的處理器結構，我想應該改寫為程序=算法+數據結構+底層優化。

　　　我們的客戶的耐心越來越少，而節約服務器的耗費也是一個讓人信服的理由，現在的電腦大多都是多核，在設計、編程時面向多線程進行開發能節省得更多，而這往往是一些細節，如果了解一些CPU的實現，在實現時也將多一份方向。另外在一些核心程序遇到瓶頸時（因為編譯器的優化也不是絕對智能的），可以試著查看匯編源碼，甚至可以針對程序所運行的機器對變量做一些調度（當然這也往往是在商業級的服務器中）。

　　　　

?

　　

轉載于:https://www.cnblogs.com/Trinidad/p/8724105.html

總結

以上是生活随笔為你收集整理的读书笔记5-处理器的微架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。