大家好我是老周。這幾天大家都在討論小米新 CPU 的曝光消息特別是“Xring O3”這個名字以及“單線程媲美蘋果多線程大幅領先”的說法。很多讀者私信問我怎么看這里先統一回復目前能看到的信息基本都是爆料和早期工程分析的階段沒有任何官方規格書所以這篇文章不打算對具體跑分和架構參數做“實錘”式解讀。我更想借著“Xring O3”這個名字把 CPU 核心設計里最關鍵、也最容易讓普通開發者混淆的幾個概念講清楚O3 是什么水平的設計Xring 在整顆芯片里到底干什么單線程與多線程性能分別由什么決定以及當我們看到一張 CPU 天梯圖時應該如何正確解讀。無論最后小米這顆芯片的實測結果如何讀懂這些底層原理比你記住任何一串跑分數字都更有價值。1. 背景為什么“新 CPU 單線程 多線程”值得關注先把這個話題放到一個大背景里看。消費級 CPU 市場過去幾年的競爭焦點頭一次變得這么清晰以前大家比的是核心數和主頻這幾年變成了比單核效能、能效比、緩存架構和互聯設計。“單線程媲美蘋果”這句話之所以能引起這么大討論是因為蘋果的 CPU 核心在單線程性能上長期處于標桿地位ARM 公版核心和 x86 陣營都在努力追趕。如果國產芯片真的能在單核性能上逼近甚至追平蘋果那說明其微架構設計已經有了質的變化而不是單純靠堆核心數量。“多線程性能大幅領先”則說的是另一條路線。單線程再強也有物理極限當你有足夠多的核心并且互聯總線能把各個核心高效協同起來多線程吞吐就會有明顯優勢。這里的核心不在于“有幾顆核”而在于核心之間的數據通路是否夠寬、夠快、夠穩定。而這恰恰是“Xring”這個名字可能要發揮作用的領域。對開發者而言理解這種變化的意義在于你寫的代碼能不能跑滿這顆 CPU取決于你的應用是單線程敏感型還是多線程吞吐型。如果你還停留在“CPU 性能等于主頻乘核心數”這個粗糙模型里那你在做性能優化和選型的時候會走很多彎路。2. 從 O3 說起亂序執行到底解決了什么問題2.1 從“按順序執行”到“亂序執行”先把 O3 的全稱說清楚O3即 Out-of-Order亂序執行。早期 CPU 執行指令是嚴格按程序順序來的取一條、譯碼、執行、寫回再來下一條。這種叫 in-order 順序執行。它的優點是設計簡單、功耗低、面積小缺點是執行單元經常閑著。舉例來說一條指令要讀取內存中的數據而內存延遲可能高達幾十甚至上百個時鐘周期。如果 CPU 按順序執行下一條指令哪怕不依賴這個數據也得傻等內存返回后才能動手。這就造成了大量流水線氣泡單線程性能上不去。亂序執行的核心思路就是在不改變程序最終語義的前提下允許后面的指令越過前面的指令先執行。說得直白一點CPU 會在內部把指令打亂順序把能先算的先算了把要等數據的操作放到一邊等數據到了再補上最后按原始程序順序提交結果。這樣一來執行單元的空閑時間大大減少單線程 IPC每時鐘周期執行指令數就能顯著提升。不過要提醒一句亂序執行不是萬能的它解決的是“指令級并行”的挖掘問題。如果你的代碼本身是一條又長又依賴的串行鏈那即便是再激進的 O3 引擎也幫不上太多忙。2.2 O3 處理器的關鍵組成ROB、調度器、寄存器重命名要理解 O3 是怎么實現的得認識幾個核心部件。第一個是 ROBReorder Buffer重排序緩沖。它負責記錄每條指令的原始順序。指令亂序執行完之后ROB 會確保按原始程序順序提交結果從而保證程序語義不被破壞。一旦發生分支預測錯誤ROB 還能把已經改動的狀態回滾。第二個是調度器Scheduler/Reservation Station。調度器負責看哪些指令的操作數已經準備好、執行單元是否空閑然后挑選可以發射的指令發給對應的執行單元。后端有幾套執行單元調度器就得盡量讓它們“雨露均沾”誰先具備條件誰先執行。第三個是寄存器重命名Register Renaming。這個名字看起來抽象其實解決的是“假依賴”問題。舉個例子程序里連續使用同一個寄存器但前后之間并沒有真正數據關聯只是復用了寄存器編號而已。如果不做處理后一條指令會被迫等待前一條釋放寄存器這就是寫后寫WAW和寫后讀WAR等假依賴。寄存器重命名會偷偷把程序里同一個邏輯寄存器映射到多個物理寄存器上從而解除這些假依賴讓更多指令能夠并行執行。這三個部件加上分支預測器和各級緩存構成了現代高性能 O3 核心的基本骨架。所以當爆料里提到“Xring O3”的時候可以合理推測這是一顆具備完整亂序執行能力的核心而不是以前那種偏簡單順序執行的設計。2.3 為什么單線程性能往往看 O3 是否激進單線程性能可以大致拆成三個維度的乘法關系單線程性能 主頻 × IPC × 實際利用率主頻大家比較好理解就是 CPU 每秒能跑多少個周期。IPC 則是每個時鐘周期能完成多少條指令這直接由微架構決定。O3 窗口越大、調度器越聰明、緩存命中率越高IPC 就越高。實際利用率則取決于分支預測準不準、指令緩存夠不夠大、同時訪問內存時能不能利用上內存級并行。“媲美蘋果”這類說法本質上是在說 IPC 和利用率達到了一個非常高的水準。后文我會給出結論不一定。這取決于實現細節——包括 L1 指令緩存的容量、L2 TLB快表的大小、預取器和譯碼器的設計等。真正可用的數據要等官方發布后才可通過 SPEC CPU 等標準測試獲得而不是通過手機上的幾個跑分 App 就能看出結果。3. Xring不只是“幾核拼在一起”3.1 片上互聯的演進總線 - 環形 - 網格“Xring”這個名字最直觀的理解是“某種環形總線結構”。這里不討論具體實現細節而是介紹一下環形總線在 CPU 中的定位。早期多核 CPU 內部使用的是共享總線架構所有核心、緩存、內存控制器都掛在同一條總線上。優點是實現簡單缺點是總線帶寬有限核心一多就會出現爭搶擴展性很差。后來業界開始用環形總線Ring Bus替代共享總線。環形總線可以看作 CPU 內部的一條環形車道每個核心、每塊緩存、每個 I/O 組件都在環上有一個“站點”數據像在環形車道上按固定方向跑。英特爾在酷睿系列上采用的是雙向環形總線一個環順時針走一個環逆時針走訪問數據時選擇更短的方向從而減少延遲。相比共享總線環形總線的優勢很明顯帶寬更高每個站點都有獨立接入點擴展性更好同時由于數據傳遞是點到點的避免了多個核心同時占用總線造成的沖突。它的局限性在于站點越多數據繞環一周的平均距離就越長訪問遠端緩存的延遲會隨之增加。所以當核心數量特別多時不少廠商又改用了網格互聯Mesh比如英特爾在 Skylake-SP 及之后的至強可擴展處理器上就大量采用 Mesh 架構。環形總線與網格互聯的選擇本質上是延遲與吞吐、面積與功耗之間的權衡。環形總線適合核心數量適中且需要低延遲訪問的場景網格互聯適合核心數量很大、需要更多并行帶寬的場景。3.2 環形總線與多線程吞吐的關系為什么一顆 CPU 的多線程性能會和內部互聯結構有關舉個簡單例子如果你有 8 個核心每個核心都在獨立算自己的數互不干擾那么互聯結構的影響可能不大但如果你的應用是多線程協作型的比如線程 A 算完中間結果要交給線程 B線程 B 又要讀取共享緩存中的某些數據那么數據在核心之間傳遞的速度就直接決定了整體吞吐。此時環形總線的帶寬和延遲就很重要了。帶寬決定了同一時間內能傳遞多少數據延遲決定了一次數據傳遞要等多少個周期。環形總線設計得好可以讓共享緩存訪問更快速、緩存一致性開銷更低、多線程協作的效率更高。所以“多線程性能大幅領先”如果成立多半不只是核心數量多而是互聯結構跟核心微架構配合得很好。3.3 從互聯結構理解“緩存一致性”這個隱形開銷講多線程就繞不開緩存一致性。每個 CPU 核心都有自己的 L1、L2 緩存多個核心共享 L3 緩存。同一個數據可能同時存在于多個核心的緩存中如果一個核心修改了它其他核心必須知道這個變化否則就會出現邏輯錯誤。這個讓所有核心的緩存視圖保持一致的機制叫做緩存一致性協議最常見的實現是 MESI 協議及其變種。一致性協議依賴互聯結構來廣播無效化消息、轉發數據請求。如果環形總線設計得好無效化消息能快速到達目標核心整體性能損失就小如果互聯設計得不好哪怕核心數再多多線程跑起來也會出現大量緩存一致性流量導致性能不升反降。這也能解釋為什么很多人跑多線程程序時發現核心利用率很高但并沒有線性加速——很大部分開銷都消耗在緩存一致性和鎖競爭上了。所以多線程性能不只是操作系統調度器的事芯片底層的緩存感知設計決定了你的線程之間的數據共享到底有多快。4. 單線程 vs 多線程為什么單獨看任何一個都不夠4.1 單線程性能的決定因素指令延遲是核心指標在單線程場景里最核心的指標是指令延遲也就是一條指令從進入到執行完成需要多少時間。具體來說單線程性能取決于以下因素分支預測器質量if/for/while 天天都在用分支預測一旦猜錯流水線前面干的所有活都要作廢。現代高性能核心的分支預測準確率通常能到 95% 以上但誤差哪怕是 1%在深度流水線下都是不小的性能損失。緩存命中率L1 緩存命中通常只需要幾個周期L2 十幾個周期L3 幾十個周期主存要幾百個周期。如果代碼數據訪問完全沒有局部性那就算核心再強也只能被內存延遲拖死。亂序執行窗口O3 引擎能同時跟蹤多少條指令、能調度多少條在途指令決定了執行單元能否被充分填滿。所以嚴格意義上講單線程性能并不只看主頻高低。一個主頻 3.0GHz 但 IPC 很高的核心完全可能超過主頻 3.5GHz 但 IPC 較低的核心。4.2 多線程性能的決定因素吞吐量受制于資源總量多線程性能靠的是并行吞吐量思路完全不同。在理想情況下n 個核心跑 n 條線程性能是單線程的 n 倍。但現實世界中這個比例幾乎不可能達到原因主要有三個每個核心仍然要共享內存帶寬、L3 緩存等資源線程同時訪問同一內存區域時會出現爭搶。線程之間的同步操作、鎖競爭、原子指令都會產生串行化的等待時間。不同應用的可并行度不一樣有的能輕松擴展到幾十個線程有的在 4 線程時就基本瓶頸了。多線程性能通常用 SPECrate、Cinebench 多核渲染、HandBrake 視頻編碼這類測試來衡量因為它們的并行度很高能比較充分地壓榨出多核性能。但要注意這些測試結果是“有條件的極限能力”。真實應用如果并行度不高那么多核再強也未必能從中受益。4.3 熱門語言與框架里的“多線程”誤區這部分值得單獨說一下因為很多人確實把它們弄混了。Redis 是單線程還是多線程答默認情況下Redis 的命令處理核心是單線程但 Redis 6.0 之后引入了多線程 I/O用于處理網絡讀寫。所以準確說法是“核心命令處理單線程網絡 I/O 可以多線程”。很多人只回答“單線程”容易被面試官認為知識沒有跟上版本。Python 的多線程為什么跑不滿 CPU因為 CPython 解釋器有一個全局解釋器鎖GIL同一時刻只允許一個線程執行 Python 字節碼。所以 CPU 密集型任務用 Python 多線程往往得不到理想加速但是 I/O 密集型任務比如網絡請求、文件讀寫多線程可以顯著改善響應速度因為在線程等待 I/O 時會釋放 GIL。Java 的多線程則沒有 GIL 這種限制。Java 的線程模型直接映射到操作系統線程可以通過線程池、并發工具類來實現真正的多核并行。但在高并發場景下要小心鎖競爭、偽共享False Sharing和線程上下文切換開銷。偽共享是個很容易踩的坑兩個線程各自修改不同的變量但這兩個變量恰好在同一個緩存行里每次修改都導致緩存行在兩個核心之間來回傳遞性能大幅下降。解決方式是做緩存行填充或讓變量錯開分布。C 的多線程是原生支持且性能可控的使用 std::thread 或線程池可以很自由地控制線程行為但同時也要求開發者對內存模型有較深理解否則很容易出現數據競爭和難以查明的并發 bug。這里想強調的是多線程性能是否跑得滿除了看 CPU 有多少核心還要看你的語言運行時是怎么調度、怎么加鎖、怎么處理共享內存的。你不能拿一份 GIL 受限的 Python 測試結果去判斷 CPU 多核性能不行這是兩碼事。4.4 如何用標準工具評估 CPU 性能常見評測方式有以下幾類SPEC CPU 2017業界認可度最高的 CPU 性能基準之一包含整數和浮點兩套測試分 speed單任務運行時間和 rate多任務吞吐量兩種模式。前面提到的“單線程媲美蘋果”通常就是在說 SPECspeed 類分數。Cinebench基于 Cinema 4D 的渲染測試單核和多核分數都很直觀是消費級 CPU 天梯圖常用的數據來源。Geekbench 系列跨平臺基準測試覆蓋場景豐富適合快速對比手機和電腦 CPU但其分數在學術界和服務器領域參考價值有限。實際業務負載壓測最可靠但仍然受限于環境。比如你對 Redis、MySQL、Nginx 做壓測要看 QPS、延遲和 CPU 占用率。這種測試的優點是貼近生產環境缺點是不同軟硬件配置下的結果差異很大很難橫向對比。此外還有 CPU 天梯圖比如服務器 CPU 天梯圖這種圖一般把 CPU 按綜合性能排成等級。看圖時需要留意它用的是單核分數還是多核分數、測試版本號是哪一個、是否包含功耗與價格因素。否則同型號 CPU 在不同天梯圖上的位次相差很遠導致用戶困惑甚至產生誤解。5. 假如有新 CPU 面世我們該關注哪些關鍵指標5.1 不應先看跑分先看三點IPC、功耗、生態對于“Xring O3”這種名稱我們在缺少官方數據時可以先建立一個通用評價框架之后等真機或評測出爐再按這個框架做比對。第一看 IPC 是否真的提升。如果新核心只是靠提升主頻來拉高單線程成績那它會面臨較明顯的功耗和散熱壓力。如果頻率基本不變而 IPC 明顯提升則說明亂序執行引擎、緩存系統、分支預測等微架構組件確實做了改進。這才是真正有含金量的進步。第二看能效比。芯片設計不能只看峰值性能還要看達到該性能需要多少功耗。同樣一顆核心如果 5W 功耗下能跑出 80% 的最大性能那放在移動設備里就會帶來更好的續航和溫控表現如果必須頂著 10W 才能跑滿持續負載下可能會迅速降頻。第三看生態兼容性。指令集、軟件生態、操作系統支持、編譯器優化這些決定了你買的 CPU 能不能真正跑起需要的軟件。如果編譯器還沒為它做調度優化那么即便微架構很先進在部分傳統 benchmark 上也可能拿不出亮眼成績。開發者尤其要關注這一塊因為再強的 CPU 也得通過工具鏈和運行時才能發揮出來。5.2 Benchmark 結果受版本與場景影響很大我之前遇到過不少朋友拿著 CPU 天梯圖去找性能問題結果發現完全對不上。這里需要說一下原因天梯圖上的分數是特定軟硬件環境下的產物不代表所有工作負載的通用表現。同樣是 SPEC CPU 2017int speed 和 int rate 反映的是不同的性能維度。前者側重單任務、單線程后者側重多任務、多線程吞吐。你拿 int speed 的排名去預測多核編譯速度自然不準。再比如 Cinebench它優化得非常好能調用所有核心并利用 SIMD 指令集。如果你的目標應用是一個優化較差的單線程程序那 Cinebench 多核高分對你沒有任何參考意義。所以正確姿勢是先明確 CPU 的典型負載是單線程敏感型還是多線程并行型再選對應的基準數據最后用真實負載驗證不要一概而論。5.3 另一個容易被忽視的指標內存子系統所有 CPU 性能最終都離不開內存子系統。即使核心計算能力再強如果內存帶寬不足、延遲過高數據進不來出不去執行單元照樣空轉。評估 CPU 時建議同時關注內存通道數雙通道、四通道還是八通道。相同頻率下通道越多理論帶寬越高多線程拷貝類任務受益明顯。內存頻率和延遲DDR4 和 DDR5 的差異主要在建模式上頻率越高、延遲越低對 IPC 越有利。緩存層級與容量L3 緩存越大能緩沖的工作集越大多核間共享數據的命中率越高。在做服務器選型時內存帶寬尤其重要。比如在高并發 Web 服務、大數據分析等場景CPU 計算時間往往只占一小段大量時間都花在等待內存數據上。如果只看 CPU 型號不看內存配置很容易出現“換了更強的 CPU 但業務性能沒提升”的困惑。6. 實際開發與運維中的高頻 CPU 場景6.1 硬件信息與狀態查詢很多開發者剛接觸 Linux 服務器時第一件事就是想知道這臺機器的 CPU 是什么。在 Linux 下可以用以下命令查看lscpu它會輸出 CPU 架構、核心數、線程數、主頻、緩存大小、支持的指令集等信息。想看得更細可以查看 /proc/cpuinfocat /proc/cpuinfo | grep model name | uniq cat /proc/cpuinfo | grep cpu cores | uniq cat /proc/cpuinfo | grep siblings | uniq其中 “cpu cores” 表示物理核心數“siblings” 表示邏輯處理器總數。兩者相除可以得到每個物理核心支持的線程數。比如 siblings 為 16、cpu cores 為 8說明啟用了超線程每個物理核心對應兩個邏輯處理器。如果是在 Windows 上最早在任務管理器里能看到邏輯處理器數如果需要更詳細的架構信息可以用 CPU-Z。這里還要提一個常見問題虛擬機里看到的 CPU 信息往往不準確。如果宿主機的 CPU 沒有啟用嵌套虛擬化或沒有正確透傳虛擬機看到的可能是一個通用的虛擬型號甚至出現“客戶機操作系統已禁用 CPU請關閉或重置虛擬機”的錯誤這通常是虛擬化設置問題不是 CPU 硬件損壞。6.2 實時監控 CPU 占用率與溫度程序性能出問題時CPU 占用率和溫度是最直接的兩個觀測指標。Linux 下可以用 top 或 htop 看進程 CPU 占用。更細粒度的可以用pidstat -p pid 1它能按進程每秒鐘輸出 CPU 使用情況非常適合排查某個線程是否在持續吃滿單核。CPU 溫度在 Linux 下可以用 sensors 命令查看sensorsWindows 下可以用 HWiNFO 或 AIDA64。服務器上則通常依賴 BMC/IPMI 來讀取 CPU 溫度和功耗比如ipmitool sensor還有一個高頻問題是 accounts-daemon 占用 CPU 很高這通常和桌面系統賬戶管理服務有關常見誘因是系統在后臺同步用戶信息或用戶目錄權限異常。排查方式一般是先確認是哪個進程在占用 CPU再根據進程名定位對應的服務而不是盲目 top 之后直接 kill 進程。之前有用戶發現 CTF 加載程序占用 CPU 過高后來定位到是輸入法相關組件的問題。此類問題通常需要從應用層調優與驅動層面去解決不要輕易對系統進程做強制終止操作。6.3 容器與虛擬化場景中的 CPU 限制現代應用大量跑在容器和虛擬化環境里這就涉及 CPU 配額問題。Kubernetes 中給 Pod 設置 CPU request 和 limit 后如果使用 CPU 節流throttling機制則當 Pod 使用超過 limit 時會觸發 CPU 限流。排查 K8s CPU 限流問題時可以看容器 cgroup 的 cpu.statcat /sys/fs/cgroup/cpu/cpu.statnr_periods 1000 nr_throttled 300 throttled_time 123456789如果 nr_throttled 比例很高說明容器經常被打到 limit 上限。這時需要評估是提高 limit還是優化應用本身的 CPU 使用模式而不是盲目加副本。CPU 壓力測試可以借助 stress-ng 等工具但測試前要先確認自己對生產環境的操作權限和可能影響。6.4 CPU 設計學習與仿真的啟發最后聊一個不少讀者感興趣的點很多人看到“O3”“Xring”這樣的詞會想自己去學 CPU 設計。網上也能看到 “RISC-V 單周期 CPU 實驗”、“CPU 設計實戰 Lab” 這類課程。這類實驗通常會讓你在 Verilog/SystemVerilog 里實現一個最簡單的單周期 RISC-V 處理器然后在 FPGA 上跑通指令集。單周期 CPU 是入門級的每條指令在一個時鐘周期內完成設計很簡單但主頻上不去。再往上做就是多周期流水線然后是經典五級流水線再到亂序執行。從“單周期”到“亂序”之間難度跨度非常大需要補充大量計算機體系結構知識。如果你是剛入門建議先跑通一個單周期 RISC-V 核再逐步往流水線和中斷設計擴展。這個過程能讓你更直觀地理解 O3 核心的復雜來源也有助于你以后真正讀懂 CPU 評測里的 IPC、流水線深度、分支預測器等術語。6.5 手機端與移動設備的 CPU 調度問題手機上的多核 CPU 還有一大特點就是大小核架構比如 ARM 的 big.LITTLE 或 DynamIQ。不同核的主頻和微架構不同操作系統在調度任務時需要根據任務類型分配到合適的核上。日常簡單操作放在小核重負載任務切到大核這就是“CPU 智能核心調度”要做的事。這也是為什么手機 CPU 評測不能只看“多核分數高低”。如果調度策略太激進很快就把大核用起來性能分是高了但功耗和發熱也隨之上升。如果調度策略太保守則應用啟動慢、幀率波動大。蘋果、高通、聯發科在這些方面的取舍各不相同芯片“能不能打”只是一個維度系統能否把芯片能力發揮出來同樣重要。7. 常見問題與排查思路整理一下日常開發中最常見到的 CPU 相關問題列出排查思路問題現象常見原因解決思路單線程程序性能不符合預期主頻和 IPC 之間不匹配代碼訪問局部性差確認程序是否受內存延遲限制嘗試提升緩存命中率多核 CPU 跑多線程提升不明顯應用并行度不足鎖競爭嚴重緩存一致性開銷大分析線程調度熱點減少共享數據寫操作避免偽共享進程 CPU 占用率長期 100%可能是死循環、忙等待或日志風暴用 top/pidstat 定位線程結合 jstack/perf 分析熱點容器 CPU 被限流應用變慢K8s limit 設置過低或突發流量沖擊查看 cpu.stat評估 limit 與副本數必要時優化代碼系統服務 CPU 占用異常高部分后臺服務或驅動異常定位具體進程檢查日志更新驅動謹慎再停用系統服務CPU 溫度過高觸發降頻散熱不足、硅脂老化、機箱風道不合理或負載過重先測溫和記錄負載確認是否為持續高負載再檢查散熱虛擬機報 CPU 錯誤BIOS 虛擬化未開啟或虛擬機配置不對檢查虛擬化開關確認虛擬 CPU 類型與宿主機兼容這些問題的共性是不要一上來就猜測是 CPU 性能不足而要先用監控工具拿到數據再做橫向對比。8. 總結如何看待“單線程媲美 X、多線程大幅領先”這類信息把前面說的內容匯總一下。第一單線程性能的關鍵在于微架構不是主頻數字。O3 亂序執行、分支預測、緩存子系統共同決定了 IPC這是“媲美蘋果”這類表述真正要關注的點。真正可信的驗證需要 SPEC CPU 等標準測試和實際應用負載而不是網上流傳的參數表。第二多線程性能是一個系統能力不只由核心數決定。核心間的環形互聯、緩存一致性協議、內存帶寬、調度器策略以及你的應用是否高并行度都直接影響最終吞吐。Xring 這種名字如果最后被證實是某種片上互聯結構那么它背后的設計取舍才是真正值得工程師研究的方向。第三評測數據要結合場景解讀。CPU 天梯圖上的分數也好網上爆料的成績也好都是在特定條件、特定測試版本下獲得的。你需要明確自己的典型負載類型然后選擇合適的指標來做參考。不要只看一個總分就下結論。第四無論新 CPU 最終表現如何現階段最好的學習姿勢是把“單線程、多線程、亂序執行、緩存一致性、智能調度”這些基礎概念真正吃透。這樣以后看到任何一顆新架構芯片的發布你都能快速看懂它的亮點在哪里、短板又可能出現在什么地方。如果你還想繼續深入學習建議按這個順序走先弄懂指令流水線再學亂序執行的基本機制然后去看真實處理器的微架構分析文章最后嘗試用 perf 或調優工具觀察你自己程序的 CPU 行為。這個過程比收藏一堆“CPU 天梯圖”要有用得多。好今天的分享就到這里。如果你覺得這篇文章對你有幫助可以收藏備用。后續等官方發布更多細節我也會繼續寫分析文章幫大家把架構變化和實際開發的關系講清楚。