熟悉計算機體系結構是種什麼樣的體驗？

01-03

如題。

略懂體系結構。雖然本人也在IC幹了好幾年了，對於晶元設計的前端和後端基本都有見識，做過演算法，做過協議，研究過內存機制，也做過匯流排設計，對於CPU流水線，加法器乘法器都有接觸，設計過浮點運算部件，相關書籍以前也是樂於研究，但是工作內容限制（目前在做深度學習硬核加速器），一個項目幾十個人，基本都不需要懂太全面的知識，更多的只需要對一個局部有些了解，所以對我而言，懂體系結構更大的作用是來知乎裝逼，也沒感覺對工作有多少直接的促進。

個人感覺，作為一門基礎知識，學習就行了，但是除非真做這個，不然沒必然研究太深。就跟懂線性代數，統計微積分一樣，你學了那是應該的，但是呢，你一上班，發現人家早就把庫給你寫好了，調用一下就行了。所以總體感覺就是：很吊，然並卵。

很難，但越深入學習就越能體會其中的美。

熟悉體系結構就意味著要至少了解三個領域的知識：處理器微結構，操作系統和編譯器。這三者就像鐵三角一樣，改動其中一個，另外兩個也會跟著變。看一看體系結構領域的旗艦學術會議（比如ASPLOS/ISCA/MICRO）就能明白，所有文章都會討論這三個方面的問題。

下面說說我的一些膚淺的見解，大神們應該會**至少**有如下體驗：

1. 看到c/c++程序就能自行腦編產生彙編代碼，想到cache，想到ISA，想到性能。看到java/python程序就想著VM優化，就想到trace cache。不管什麼程序先抿一下哪段代碼是bottleneck，profiler一般用來做驗證抿對了。。。

2. parallelism和locality。會考慮怎麼提高程序的ILP/DLP和TLP。ILP一般依靠編譯器後端和微結構，這裡面就包括CPUpipeline的設計balance，多發射/超標量/超長指令字，用分支預測器在運行時擴大數據流圖等等技術；DLP一般要考慮如何使用SIMD/GPU來向量化；TLP就是要考慮如何利用多核/眾核加速程序，這裡面還要考慮同步。這三種並行性都還要考慮data locality，就是研究程序在什麼時候訪問什麼數據以及數據放在哪個memory里（register/cache/memory/disk？）更合適。在多線程的時候還要考慮cache coherence/false sharing/row buffer locality等等。

3. bandwidth 和 latency。會在在硬體或者軟體層面設計各種buffer來減少延遲，增加帶寬。這裡面要考慮cpu頻率，memory controller， MSHR；還要考慮各種互聯拓撲結構，routing policy裡面還要考慮要程序的QoS。

4. control flow 和 data flow，這個是個大坑，可以以後填。

9. 最重要的應該是看破一切，就好像駭客帝國里的neo，看到的一切都是代碼；而一切代碼又都會被編譯器/解釋器翻譯成彙編，然後通過操作系統載入在各種處理器上執行。

好不容易放假一天，趁坐著洗腳按摩的功夫怒答一波。看答案講沒用的人挺多啊，挺不解的。

我主要做架構，兼一個80人規模世界頂尖的處理器設計驗證實現團隊的manager，指導兄弟們最多的就是苦口婆心勸大家看《計算機體系結構量化研究方法》和《數據結構與分析》，前者是理解系統的基礎，後者是編碼的基礎。收效甚微，嗨 (ノ=Д=)ノ┻━┻

你們知道現在招聘正統一個體系結構背景，IC方向碩士或者博士多難么……有錢都招不到啊。嗨(┯_┯)

數據結構也是，『』16bits位寬寄存器，用五（六也行）級邏輯判斷其中有15個0和1個1『』，這麼道題目，面試無數，幾乎沒有人能答出來，連給我衍生『』14個0和2個1『』的機會都沒有。

回想一下，我是怎麼學的呢？數據結構是大學本科課程，比較感興趣，是少數幾個認真學習的課程之一，體系結構，原則上和我專業（通信）無關，但研究生老闆恰好是2000年左右國內一大批EE類國外圖書翻譯版的評委，實驗室一套全有，處於個人興趣自學了體系結構一書。回想起來，這兩本書貫穿了整個職業生涯。

表面上，體系結構很虛，確實像是裝逼專用，實際上，這是一種系統分析的語言和理解的基礎，學過的人和沒學過的人要聊起來，要達成理解的一致，光鋪墊熱身就要很久。要類比的話，學了牛頓三定律的人，通常就認為世界是醬紫了，而學過相對論甚至弦論，看待一件事物時會有另一種視角，就是跟一個認為兩個鐵球同時落地的人講光速恆定的趕腳。

體系結構就是如此，他用傳統CPU為視角，對最本質的基礎架構：馮諾依曼，進行了詳細的量化分析。我常常問手下的兄弟，為啥我們要做通用CPU，這個和做個GPU或者DSP，甚至火熱的TPU有啥區別呢？為啥要有CACHE呢？為啥要有MMU呢？ MSI和線中斷又是啥區別呢？這些問題的答案，匯聚到最終，也就是對馮諾依曼的理解了，看明白這點，面對火熱的TPU、寒武紀什麼的，很大程度就能理解他們本質上是在馮諾依曼的基礎上，在數據的時間性和空間性取了什麼巧了。

對實際工作來講，體系結構也是重要的，以ST驗證為例，不懂體系結構的人，看待一個系統，就只知道CPU在取指，錯一個bit就跑飛了，數據在匯流排上流動，亂七八糟，一個地址變化好幾次，定位起來困難死了，分不清MEMORY或IO屬性，不理解中斷嵌套的層次，更勿論虛擬化和docker…… 這樣的同志定位一個晶元系統性問題，得半年。

嗨，昨天還有人問我如果軟體寫錯程序，會不會踐踏堆棧，硬體要不要做一層地址判定保護…………這裡的同志覺得呢？

有時候我還在想，國內好的體系結構的學生少，是學校不教呢，還是老師不合格啊…… 舉個栗子，intel的skylake相比haswell一個大變化就是cache層次從inclusive變成exclusive，這個變化無論工業屆還是學術界都是重要的吧。那麼exclusive相比inclusive的優劣是什麼？誰都知道exclusive會有效增大cache容量，那為啥不第一天就用呢？面試國內體系結構相關的碩士博士，結果是知道這個變化的人就少之又少了，更勿論……

2017-05-02，更新提到的題目，16bits寄存器找1的verilog表達，回復中依舊無人答對。如下圖

看上去無人明白這個答案的意義，還是在講什麼加法器、迭代、二叉樹之類，哎

╮（╯＿╰）╭

瀉藥。

不懂體系結構，所以沒有體驗。。。

不過我猜，程序猿懂體系結構就和產品經理懂設計模式一樣，主要功能就是裝逼的。。。

每次優化程序以及演算法的時候，心理都想:那些純做演算法的肯定優化不到這裡。老子真牛逼。

可以為裝機和修電腦提供理論基礎（滾）

更加明白把幾行代碼縮成一行，少寫幾個局部變數，if寫成三目表達式，不用中間變數交換兩個變數，a = a + 1寫成a++，寫成a+=1

並不能讓程序變快

反而動不動就開全局大數組，十分有可能拖慢程序速度

自從讀完《計算機體系結構量化研究方法》寫C語言程序時會考慮 NUMA，Cache miss等各種影響。而且讀很多的頂級會議的並行計算論文，體系結構是基礎知識，肯定需要了解的。

目前基本上訓練到看看C語言結構體的設計就能大概知道這個程序的性能和編程人員的系統水平了。

還有一點，當你的程序需要進行性能優化控制在cpu cycle級別的時候，彙編，體系結構還有相關的編譯原理知識是必須要了解的，這樣的話那些perf tools的報告才能看懂。

最後還是要留下個人訂閱號，主要是IT技術相關。

http://weixin.qq.com/r/cETQyE-EjRLyrQur9xFi (二維碼自動識別)

感覺對一般碼農來說，計算機體系結構真沒什麼鳥用。

對做內核的，操作系統的，多核編程的，計算機體系結構還是很有用的。那些回答沒用的人，估計都是做上層應用的，或者只是專註做很小一部分功能的。不需要那麼多程序員去考慮這麼底層的事情，自然很多人認為體系結構只是裝逼用的。

Why is it faster to process a sorted array than an unsorted array? 這類問題一看標題就知道怎麼回事；
寫程序的時候忍不住去考慮細節：如何對Cache，分支預測器，甚至是OoO流水線友好。
看見卡吧圖吧的人討論處理器的時候，每次都需要忍住上去撕逼的衝動，告誡自己讀paper，碼代碼比較重要；
學習並行演算法的時候，忍不住去考慮這個演算法會不會因為Cache coherence性能很差；

暫時想到這麼多，吹比為主，答題為輔

我是做ic設計的。懂計算機體系結構，畢業時候，拿那些做cpu/gpu相關的offer拿到手軟吧。。。。

性能，功耗，面積，一個都不能少，優化晶元設計真是難上加難。。。

謝女神邀。

先碼後答，稍後奉上乾貨~

大學裡學過，就這種懂。

好處是知道某些同事在說什麼╮(╯▽╰)╭

熟悉計算機體系結構是種什麼樣的體驗不知道，但我知道招一個熟悉計算機體系結構的Java是很難的。

成為了一個繼會寫代碼，也能修電腦的程序員，寫代碼時會思考代碼在機器系統上是怎麼運行的，會考慮代碼背後的東西，l而不僅僅是實現邏輯。

懂一點，所以能給windows，寫點小feature。

看到這個問題差點笑出聲：這問題是自動生成的吧（一臉懵逼）

計算機硬體也有邏輯泄露嘛

面試的時候會聊得很開心，和面試官有種相見恨晚的感覺