架構可以千變萬化，面向需求、綜合考量是王道。
來，簡單舉個例子。假設現在我們要設計一臺計算機的處理器部分的架構。現在擺在我們面前的有兩種選擇，多個單核CPU和單個多核CPU。

如果我們選擇多個單核CPU，那麼每一個CPU都需要有較為獨立的電路支援，有自己的Cache，而他們之間通過板上的匯流排進行通訊。假如在這樣的架構上，我們要跑一個多執行緒的程式（常見典型情況），不考慮超執行緒，那麼每一個執行緒就要跑在一個獨立的CPU上，執行緒間的所有協作都要走匯流排，而共享的資料更是有可能要在好幾個Cache裡同時存在。這樣的話，匯流排開銷相比較而言是很大的，怎麼辦？那麼多Cache，即使我們不心疼儲存能力的浪費，一致性怎麼保證？如果真正做出來，還要在主機板上佔多塊地盤，給佈局佈線帶來更大的挑戰，怎麼搞定？

如果我們選擇多核單CPU，那麼我們只需要一套晶片組，一套儲存，多核之間通過晶片內部匯流排進行通訊，共享使用記憶體。在這樣的架構上，如果我們跑一個多執行緒的程式，那麼執行緒間通訊將比上一種情形更快。如果最終實現出來，對板上空間的佔用較小，佈局佈線的壓力也較小。

看起來，多核單CPU完勝嘛。可是，如果需要同時跑多個大程式怎麼辦？假設倆大程式，每一個程式都好多執行緒還幾乎用滿cache，它們分時使用CPU，那在程式間切換的時候，光指令和資料的替換就要費多大事情啊！