關于 CPU

愿打開此篇對你有所幫助

@[toc]

這不，要做畢設了嘛。之前寫的那些項目勉勉強強能跑起來，但是性能方面是沒有太在意的，這次準備精打細算一番。看看瓶頸到底都在哪里。

32位CPU && 64位CPU

CPU 看了那么多，我們都知道 CPU 通常分為 32 位和 64 位，你知道 64 位相比 32 位 CPU 的優勢在哪嗎？64 位 CPU 的計算性能一定比 32 位 CPU 高很多嗎？

32 位 CPU 一次可以計算 4 個字節；

64 位 CPU 一次可以計算 8 個字節；

這里的 32 位和 64 位，通常稱為 CPU 的位寬。CPU 位寬越大，可以計算的數值就越大。

這并不代表 64 位 CPU 性能比 32 位 CPU 高很多，很少應用需要算超過 32 位的數字，所以如果計算的數額不超過 32 位數字的情況下，32 位和 64 位 CPU 之間沒什么區別的，只有當計算超過 32 位數字的情況下，64 位的優勢才能體現出來。

另外，32 位 CPU 最大只能操作 4GB 內存，就算你裝了 8 GB 內存條，也沒用。而 64 位 CPU 尋址范圍則很大，理論最大的尋址空間為 2^64。

CPU Cache && 內存 && 硬盤

認識一下CPU架構：

在網上（小林coding）看到這么一張圖：

生動形象吧。

曾經一直有個誤區，認為redis是和調用進程放在一塊兒的，后來才知道，進程存取redis也是要走 IO 的，那時候就不太理解，那 redis 是比MySQL 快在哪里了？我覺得其中有一個重要因素就是 redis 數據在內存里，MySQL 數據在磁盤上吧。

CPU 并不會直接和每一種存儲器設備直接打交道，而是每一種存儲器設備只和它相鄰的存儲器設備打交道。

比如，CPU Cache 的數據是從內存加載過來的，寫回數據的時候也只寫回到內存，CPU Cache 不會直接把數據寫到硬盤，也不會直接從

（圖片來源網絡）

另外，當 CPU 需要訪問內存中某個數據的時候，如果寄存器有這個數據，CPU 就直接從寄存器取數據即可，如果寄存器沒有這個數據，CPU 就會查詢 L1 高速緩存，如果 L1 沒有，則查詢 L2 高速緩存，L2 還是沒有的話就查詢 L3 高速緩存，L3 依然沒有的話，才去內存中取數據。

（圖片依舊來自網絡）

查看 1/2/3 級緩存大小

程序執行時，會先將內存中的數據加載到共享的 L3 Cache 中，再加載到每個核心獨有的 L2 Cache，最后進入到最快的 L1 Cache，之后才會被 CPU 讀取。

L1 Cache 通常會分為「數據緩存」和「指令緩存」，這意味著數據和指令在 L1 Cache 這一層是分開緩存的。index0是數據緩存，index1是指令緩存。

另外，你也會注意到，L3 Cache 比 L1 Cache 和 L2 Cache 大很多，這是因為 L1 Cache 和 L2 Cache 都是每個 CPU 核心獨有的，而 L3 Cache 是多個 CPU 核心共享的。

如何寫出讓 CPU 跑得更快的代碼？

這個問題可以翻譯為：如何寫出 CPU 緩存命中率高的代碼？

那我們需要來看一下什么叫CPU緩存命中（就是要用的數據在CPU緩存里邊唄）。

//查看 L1 數據緩存一次載入數據量的大小： cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

剩余的可以自己上網搜一下，無非就是教你怎么排版代碼順序。

按照內存布局順序訪問，將可以有效的利用 CPU Cache 帶來的好處，這樣我們代碼的性能就會得到很大的提升。

太細了，以我現在的認知水平，先記著吧。

如果是多核呢？雖然 L3 Cache 是多核心之間共享的，但是 L1 和 L2 Cache 都是每個核心獨有的，如果一個進程在不同核心來回切換，各個核心的緩存命中率就會受到影響，相反如果進程都在同一個核心上執行，那么其數據的 L1 和 L2 Cache 的緩存命中率可以得到有效提高，緩存命中率高就意味著 CPU 可以減少訪問 內存的頻率。

當有多個同時執行「計算密集型」的線程，為了防止因為切換到不同的核心，而導致緩存命中率下降的問題，我們可以把線程綁定在某一個 CPU 核心上，這樣性能可以得到非常可觀的提升。

進程綁核函數：sched_setaffinity

線程綁核函數：pthread_setaffinity_np

需要用到的小伙伴自行百度這兩個函數，有現成代碼拿去測試一下。

這些技巧在計算密集型的時候好用，如果是IO密集型的嘛，哈哈。不如想想SQL語句優化來的實在。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。