提高核心數和改善架構，這兩種方案哪種更能提升 CPU 的性能？

01-08

題主前段時間和別人因為此事爭論，爭論的焦點是：
八核處理器是否有意義
題主認為，如果能提升每個核心的架構和性能或者cache和匯流排速度，不到萬不得已，則不需要盲目擴大核心數目，就像INTEL、蘋果、高通那樣，雖然核心數不多，但是性能卻依舊強勁，而且題主認為amd和聯發科性能並不好，而且經常發現部分核心處於空閑狀態
許可權狗則認為，核心數越多，並行計算的能力就越強，比如開gcc編譯，核心數越多，編譯速度越快，例如聯發科、AMD，單個核心性能弱，但是提高核心數來提高性能，且認為intel和高通是忽悠大眾
然後題主就被趕出了群，先不討論許可權狗的做法，題主想問，這兩種思想，哪種更正確

謝邀。核心數多或者少是普遍業界討論的話題，但我認為這根本不是問題，不同內核結構的比較非常麻煩，通常需要做一些量化研究來定量，而不同內核結構不同核心數量的整體cpu數量更加麻煩，還要涉及到核心數的利用率，問題的關鍵就在這裡——利用率，

①性能目標：計算機體系結構有兩個性能目標：延遲和吞吐。我舉個例子，一堆饅頭，一個人吃完一個饅頭的耗時時間就是延遲；能在既定時間內吃完多少個饅頭就是吞吐。你可以這麼想，一個人相當於一個核心，一個饅頭相當於一條指令。你要是提升延遲那你應該提升這一個人的速度，如果你提升吞吐則主要應該再多叫幾個人一起來做，雖然提升這一個人的速度也可以間接提升吞吐。

②數據類型：這裡還要講兩個大概的數據類型：大規模線性密集流計算和load／store小型離散。前者主要是高度對齊的MD（多數據流）無論是SIMD還是MIMD都是更重視吞吐，它主要是細粒度的數據級並行且指令和數據間幾乎沒有任何相關性，這樣並行起來更加容易；而後者處理的數據是離散型的，且指令和數據間有複雜的相關性，所以更加註重挖掘IPC也就是指令級的並行方式，重視單條指令的延遲和指令的吞吐。

③離散和密集：說到這裡基本也就明了了，挖掘單核性能更適合一般的load／store指令的IPC挖掘，這類數據集由於其離散的性質以及指令間複雜的邏輯關係導致多核並行化（也有其他方面的原因）不太好寫；但是對於SIMD密集流計算來說數據具有高度對齊性導致多核並行化更加好利用因此也就主要靠吞吐取勝——gpu就是這麼一個例子，數據間沒有任何相關性，且頂點和像素都採用四位元計算方式更容易並行，它就是SIMD的單指令多數據流處理方式，其處理的數據高度對齊。但是讓多核同時處理一個進程由於很多方面的原因不太容易並行，也就是對於多核的利用率不高。

④單核性能發展瓶頸：曾經20世紀70年代（還是80年代？最討厭記年份了咩）CPU的性能增長為每年25%，主要是靠技術驅動，後來80年代後每年增長為52%，主要依賴是體系結構的改進，當初也是超標量的黃金髮展時期，目前一大波通用計算超標量處理器上的技術都是當初先輩們的結果不斷改進過來或者遺留至今。然而後來學術界一些人已經預見到微結構上的瓶頸，這時候性能增長滑落到每年22%，最終2006年後業界紛紛轉向片上多核處理器發展方向，這一度也是現在仍然被學術圈的很多人認為是繼標量到超標量體系結構重大改變後的又一次重大改變，《計算機組成原理，硬體軟體介面》這本書是很多做體系結構得都熟知的一本書，基本每個學計算機方面的人都學過這本書，它給很多人帶來了不小的啟蒙，也是體系結構的「聖經」，由於講述的基礎，一般本科生都熟知，作為個已經CE的在讀Ph.D我也不再多贅述了。這本書里形容這次改變是滄海巨變，這可是個不小的評價。確實，在面臨功耗牆、物理設計瓶頸以及微結構本身ILP挖掘的瓶頸以及日益增長的數據需求來看明確的兩條路就是依託工藝加強mos管性能後提升時鐘頻率；要麼就是發展多核並行協同工作。

⑤總結：對於一種技術的應用的提升大與否、有用與否都是看使用場景的，這個就類似於體系結構已經重複很多遍的黃金法則——「權衡」的道理是一樣的，通用計算來說數據集的不同，一種技術帶來的提升有很大程度上的不同，所以需要看使用的場景的不同，單用一種數據集說是不嚴謹的，就如同一些外行喜歡單單用幾個Benchmark就定量CPU一樣。

ps：說來也趕巧，其實昨天還和破布一起討論了一下AVX對於x86在CPU指令集層面的整體改進，我們也是一致認為需要看使用的場景來進行判斷的。

ps2：題主有興趣可以來我們QQ群里坐坐，破布大叔也在，還有其他好幾個做體系結構相關的人士包括我，人雖然就幾個，但都是比較有技術實力的，也不會有許可權汪。上次那個群主說了一個什麼雙核處理器，其中一個核單獨作為分支預測器的奇葩思想（我從本科到之前研一一直都對分支預測有所深入研究，但也是沒有聽說過這種奇葩的設計，跟體系結構的思想都有所違背）然後破布大叔直接否定了後他們都快吵起來了，最後那個群主也沒把破布大叔踢了，反而還是非常敬重他的技術水平。

提高核心數和改善架構，這兩種方案哪種更能提升 CPU 的性能？

那當然是提高核心數提升更快，這可是立竿見影式的。而改善架構太難了。

--------------------------以下詳細解釋----------------------------------------

現在的用戶都是多任務運行，多任務多線程就可以被多核並行執行，處理速度明顯上升。另外單核已遇到瓶頸(上面的回答已經說得很好了)，instrction prediction/prefetch, branch prediticon, out-of-order excution等做了這麼多年，想提高已經很難了。想提升頻率也很難，若增加流水線級數問題很多，hazards太多，設計驗證都會很複雜，功耗太高。

多核不光是提高性能，一個很重要作用是降低頻率降低功耗。功耗三次方於頻率(電壓正相關於頻率)，頻率太高功耗就太高。舉個例子， L5630 (4 Cores @ 2.13 GHz)是40瓦，而E5640 Xeon (4 cores @ 2.66 GHz)是95瓦。現在用多核並行處理，無須太高頻率，無須太複雜單核設計，降低每個核研發難度，降低每個核功耗，以量取勝。隨著摩爾定律發展，現在單個晶元集成的transistor都能billions級的，有這麼多transistor就去堆核心呀，不然留著幹嘛，transistor已經不值錢了。

多核要考慮到Amdahl"s law(阿姆達爾定律_百度百科),但現在多核基本是大核+小核 (異構多核)，所以當有串列不可分割大任務就交給大核專註處理，其他的並行小任務交給其他核處理，處理速度明顯上升。在異構多核中，有些任務就可以交給專用core(核心)專註處理，這樣一些core就成變成ASIP(Application-specific instruction set processor，增加定製指令集)，甚至ASIC，性能比通用CPU高上百倍。

題主說的提升單核架構，不到萬不得已不堆核。真是站著說話不腰疼。單核做到極致的就那兩家，你以為MTK，AMD不想么？但這哪是說想就能辦到的，就算Intel也大概平均三年左右才升級一次架構，CPU性能提升的大頭來自於工藝。堆多核比提升單核容易多了，他們當然選擇最適合自己的。他們單核肯定也在做，只是單核提升真的很難，市場壓力又這麼大，當然優先選擇堆多核這種簡單粗暴見效快的，否則等他們單核做出突破時，黃花菜都涼了。Intel的多核也是相當牛了，64核，上百核的都有了。但消費者要求還沒那麼高，他們不急著放。

題主說提升cache，你是打算怎麼提升呢？若增加容量，是能減少cache miss，但一次訪問反而變慢，並且cache也很佔area。至於提升匯流排速度，多核中直接用上NoC(片上網路)，性能可比傳統匯流排強。

在不同場景，不同公司根據自身條件都會制定不同策略，空談哪種更合適沒有意義。但多核是晶元設計的趨勢，隨著用戶需求不斷上升，per die上能集成的transistor不斷增加，多核數量會越來越多。

工作日寫的稍微匆忙，待續-----

在另一個回答里對多核進行了詳細的解釋分析為什麼手機核心數目提升的比計算機快? - young cc 的回答

公說公有理，婆說婆有理，到底誰有理？

不看應用場合，認為一種解決方案可以解決所有問題是沒有道理的。

現實是玩的了架構的搞架構，玩不了架構的搞核心。

事實勝於雄辯。

關於這個問題，不論是在PC業還是在手機業都有著活生生的例子。

PC：

intel i7-4790k 四核CPU

全方位完勝

AMD 任何八核CPU

手機：

高通驍龍805 四核CPU

全方位完勝

MTK 任何八核、十核CPU

以上無論性能還是功耗，都是完勝，沒有絲毫可比性。

架構、工藝的重要性完勝核心數。

AMD就是活生生的例子，前車之鑒。

MTK這樣做，火的了一時，火不了一世。

有的軟體需要大量並不太複雜的並行行計算，多核心就好。比如我們cg中的渲染。

有的軟體很多功能只能單線程處理，提高核心速度就更適合。

看AMD現在的境遇就知道了。。。。

你要黑農企就直說，不用這麼拐彎抹角的。。。。。。。

農企也是很努力的！

他說的8核，聯發科是厲害，問題手機散熱不行，並不能很好的利用。amd桌面不知道，只知道筆記本帶a就是坑。

另外手機核數就是就是迷信

不提workloads而討論體系結構性能的都是耍流氓 =v=

聯發科的八核。。不可能同時開啟的。。熱散都物理條件都滿足不了。它這個多核不是為了全開並行加速，二十純粹為了大小核在恰當的應用場合切換。除了延遲和吞吐，現在手機最關心的就是功耗。大數據中心則關心單位運算量的功耗，因為電費佔大頭。

做體系結構的跑來說一句 NOC 現在不是bottleneck 很多app根本跑不到5%的NOC負載量所以現在基本體系結構不會在NOC方向上作出太大改變別的問題我覺得很難回答提高core count是為了scale out 但是app自身也有data dependency ....參見Amdahl"s law