如何提升應用程式的運作速度

對于對吞吐量和延遲有極緻追求的程式來說，提升應用程式的運作速度無疑能夠顯著增強其核心競争力。下面就本人目前的認識簡要介紹如下，有不足之處，還望指正。

阻止CPU的切換

CPU的切換會給成勳的運作帶來非常大的損耗，主要是因為CPU切換帶來的是CPU對應的記憶體資料的洗禮，當程式運作的CPU發生切換時，由于目前的CPU架構大部分都是NUMA架構，記憶體控制器天然的會把記憶體進行切割，固定配置設定到各個CPU，這就使得如果運作程式的CPU發生切換時，就需要重建頁表，以建立虛拟記憶體和實際實體記憶體之間的映射關系，而這會極大的影響程式的運作速度。

解決方案：

為應用程式綁定CPU。

依據應用程式的特點開啟大頁記憶體

目前作業系統的記憶體都比較大，動辄幾十G非常常見，如果應用程式屬于高記憶體占用型，那麼使用預設的記憶體分頁大小（4KB）會使得虛拟記憶體和實體記憶體之間的頁表變大，增加了記憶體位址的檢索時間，同時也增大了快表失效的機率，如此将會增加CPU和記憶體互動的耗時，進而影響應用程式的響應時間。

當然對于記憶體占用比較小，且記憶體通路不随機的應用程式，則不需要開啟大頁記憶體，因為該類應用程式不會出現塊表失效的可能或者說極少出現。

解決方案：

開啟作業系統的大頁記憶體。

依據應用場景合理控制記憶體配置設定政策

NUMA架構決定了CPU對于local access的時間遠低于remote access，是以如果能夠根據應用場景合理的控制記憶體配置設定政策，同時配合CPU的綁定機制，可以使得應用程式在指定的CPU上運作且改CPU不會remote access去通路其他節點的記憶體，那麼就能夠最大限度的提升應用程式的運作速度。

NUMA架構

在NUMA架構出現前，CPU歡快的朝着頻率越來越高的方向發展。受到實體極限的挑戰，又轉為核數越來越多的方向發展。如果每個core的工作性質都是share-nothing（類似于map-reduce的node節點的作業屬性），那麼也許就不會有NUMA。由于所有CPU Core都是通過共享一個北橋來讀取記憶體，随着核數如何的發展，北橋在響應時間上的性能瓶頸越來越明顯。于是，聰明的硬體設計師們，先到了把記憶體控制器（原本北橋中讀取記憶體的部分）也做個拆分，平分到了每個die上。于是NUMA就出現了！

NUMA中，雖然記憶體直接attach在CPU上，但是由于記憶體被平均配置設定在了各個die上。隻有當CPU通路自身直接attach記憶體對應的實體位址時，才會有較短的響應時間（後稱Local Access）。而如果需要通路其他CPU attach的記憶體的資料時，就需要通過inter-connect通道通路，響應時間就相比之前變慢了（後稱Remote Access）。是以NUMA（Non-Uniform Memory Access）就此得名。