其實聯(lián)想z500進入bios設置按哪個鍵()的問題并不復雜，但是又很多的朋友都不太了解聯(lián)想z500進入bios設置按哪個鍵()，因此呢，今天小編就來為大家分享聯(lián)想z500進入bios設置按哪個鍵()的一些知識，希望可以幫助到大家，下面我們一起來看看這個問題的分析吧！

英特爾十一代酷睿微架構 Rocket-Lake 測試報告

英特爾十一代酷睿處理器微架構 Rocket-Lake 測試報告

日漸凌亂的舞步——從 Tick-Tock 到 PAO

所謂 Tick-Tock 是指英特爾在 2007 年發(fā)表的產品推出模型，含義并不復雜：

Tick：新的半導體制程

Tock：新的微架構

Tick-Tock 本身只是大家對“節(jié)拍”的讀音，類似于中文里的“滴答”，而 Tick-Tock 產品發(fā)布模型就是指一波新制程然后一波新架構的產品發(fā)布節(jié)奏。

2007年的時候英特爾是處于怎樣的業(yè)務環(huán)境呢？

如果翻開這段還很新鮮的歷史，可以看到2007 年的時候，英特爾正處于從最后一代 Pentium 4（65nm Cedar Mill，2007 年 1 月發(fā)布）切換到 Core 2（65nm Conroe，2007 年 7 月發(fā)布）的轉折點，和 AMD 之間自 K7 以來的競爭依然處于白熱化階段。

AMD 當時在 x64 指令集拿下一血，但是在制程稍微落后，K7 /K8 的微架構潛力基本到頭，架構團隊正在憋大招（然而這個大招事后看來真是一言難盡）。

英特爾當時原本計劃是想要在 Netburst 上再賭一把推代號 Tejas 的新 Pentium 4，在英特爾的Netburst 愿景中，65nm 制程將有望實現(xiàn) 10GHz，Tejas 就是這樣愿景下的架構。

最初的 Tejas 本來是基于 90nm，但是后來改為 65nm，為了配合 Tejas，英特爾弄出了現(xiàn)在已經絕跡的 BTX 主板規(guī)格（處理器位于主板左側、擴展卡插槽位于右側，和 ATX 完全相反），官方配的 Tejas 散熱器也是極其碩大。

然而，Tejas 最終還是夭折了，基于 Conroe 的 Core 2 橫空出世，全面扭轉了 Pentium 4 逐漸下行的趨勢。

英特爾的 Tick-Tock 至此正式展開布局，而AMD 開始陷入到長達 10 年的低迷中。

面臨來自 AMD 的高強壓力，正是 Tick-Tock 誕生的主要背景。

我們見證了在 Tick-Tock 的驅動下 Conroe 微架構及其衍生微架構的輝煌，但是到了 2016 年，英特爾認為 Tick-Tock 驅動模式下由于芯片微縮的成本越來越高，不符合經濟性，因此宣布這個 10 年的產品發(fā)布模型終結，改為采用名為 Process–Architecture–Optimization（PAO，制程-架構-優(yōu)化）的產品發(fā)布模型。

在 PAO 模式下，每個制程節(jié)點的產品從兩代變成三代（以上），由此可見，PAO 產品策略誕生于一個競爭壓力較小、新制程研發(fā)成本日益高漲、微架構潛力似乎還有挖掘空間的業(yè)務環(huán)境里。

如果說當年 AMD 的推土機采用 CMT 架構太“浪”了，那么英特爾這幾年的 PAO 則更像一個財務先決下的保守型策略。

所幸的是英特爾底子遠非其他半導體廠商所能比的，所以 PAO 這口飯倒是穩(wěn)穩(wěn)當當?shù)爻粤撕眯┠辏瑥?2014 年 8 月的 Broadwell（第一批 Broadwell 處理器屬于 Core M 產品線，被定義為第四代 Core，不過臺式版本被定義為第五代 Core）開始算，14 納米縫縫補補，居然混了 7 年之久，這樣的情況對其他頭部處理器廠商來說是有點不可思議的。

上面的表格就是14nm 到 7 nm 制程上的 PAO 清單，說實話，如果沒有這個表格的話，我相信很多人都會搞不清英特爾這幾年到底干了些啥，一會兒 lake 一會兒 cove，這些代號到底是微架構還是芯片？現(xiàn)在這個表格基本上是一目了然。

最重要的是，你要知道這些年英特爾早就不再是 Tick-Tock 而是 PAO。

PAO 從經濟學的角度來說無可厚非，但是隨之而來的問題是作為美國半導體扛把子的英特爾搞這套后，導致制程研發(fā)進度被人為拉長，以至于最近有人說是英特爾技術不行了，其實非也，最主要的問題還是 PAO 這套規(guī)劃讓英特爾的核心指導策略變得滿足于對制程和微架構的精雕細琢（大家通俗點的說法就是擠牙膏）。

RocketLake 就是在 PAO 策略下的英特爾最新一代處理器架構，RocketLake 這個名字屬于SoC 級別的微架構代號，桌面的 RocketLake-S 包含了代號是 Cypress Cove（微架構與 Sunny Cove 同代，因為使用 14nm 而名字上有不同）的 CPU 內核微架構、 32 個 EU 的 Xe-LP GT2 核顯，對應的產品系列就是第十一代臺式酷睿處理器。

正如我們前面的表格所展示的，RocketLake 屬于架構前移，這里的前移含義是它采用的CPU 微架構 Cypress Cove源自 Sunny Cove，原本對應的制程并非 14 納米優(yōu)化，而應該是 10 納米制程。

Sunny Cove 是 2019 年就推出的 CPU 內核微架構，筆記本/服務器版本的 SoC 微架構實現(xiàn)是大家耳熟能詳?shù)?IceLake，對應的筆記本產品線為十代筆記本酷睿，服務器版本則是今年 4 月份才會推出的 IceLake-SP（屬于第三代 Xeon Scalable 處理器，采用 LGA 4189 引腳或者說對應 Socket P+ 插槽）。

在編譯器（GNU GCC、Intel OneAPI HPC、LLVM）中，RocketLake 和 IceLake 的架構旗標均為 icelake 或者 icelake-client。

在 gcc 和 llvm 中，icelake 或者 icelake-client 架構旗標默認不會開啟 AVX-512 的 512 位版本指令支持，只有 AVX-512 的 256 位指令版本支持，編譯出來的二進制文件里向量寄存器只有 xmm（128-bit）和 ymm（256-bit）兩種類型，即使已經使用了 -mavx512f 這個開關也是如此。

程序員使用 gcc 或者 llvm 編譯程序的時候，需要特別指定優(yōu)選 512-bit 寄存器（寄存器標識為 zmm）寬度才能實現(xiàn) AVX-512 的 512 位版本（AVX512F）指令支持，只有這樣才能編譯出真正使用 zmm 寄存器的二進制對象文件。

英特爾的 OneAPI HPC 編譯器則只要使用 icelake 旗標默認就會啟用采用 zmm 或者說 AVX512F 指令。

見下圖，紅色高亮的就是表明編譯出來的二進制文件包含了 zmm 寄存器調用（這里是 OneAPI HPC 編譯 SPEC CPU 2017 的 503.bwaves 子項目為示例），此時程序將會采用含有 512 位版本的 AVX-512 指令執(zhí)行：

總括而言，英特爾這些年微架構代號、產品型號、制程關聯(lián)度如此復雜，即使是行內人也會感到各種迷惑，而這正是數(shù)年來英特爾在 PAO 策略下演繹的凌亂舞步。

RocketLake SoC微架構概況

RocketLake 是十一代桌面酷睿處理器的 SoC 微架構代號，均為 LGA 1200 引腳，Z400 系列(部分)和 Z500 系列芯片組主板都能提供支持，其中集成顯卡的 K 系列有三個型號，見下表：

RocketLake 的 CPU 內核微架構代號是 Cypress Cove，在指令集方面具備 AVX512F、VNNI 等指令擴展，引入了比上一代微架構（CometLake）更大的重排序緩存（ReOrder Buffer）和一級數(shù)據(jù)緩存（L1 D-Cache），最高 8 個內核 16 線程（CometLake-S 最高可以 10 核 20 線程），周邊高速互連方面實現(xiàn)了 PCIe 4.0 的支持（20 條 PCIe 4.0 信道），核顯更新為性能顯著提升（50%）的全新Xe-LP 架構GPU，支持更高規(guī)格的顯示輸出，與 PCH（南橋）連接的總線 DMI 3.0 信道數(shù)提升為 8 條（增加了一倍）。

Comet Lake-S SoC 模塊圖：

Ice Lake-H SoC 模塊圖：

Rocket Lake-S SoC 模塊圖：

和 Comet Lake-S 相比，Rocket Lake-S 在 SoC 級別架構上的主要變化：

內核：Skylake → Cypress CoveGPU：Gen 9.5 → Gen 1224EU → 32 EU顯示輸出：DisplayPort 1.2 → DisplayPort 1.4HDMI 1.4b → HDMI 2.0b周邊設備接口：PCI Express 3.0 → PCI Express 4.0DMI 3.0 x4 → DMI 3.0 x8內存：DDR4-2933 → DDR4-3200芯片組400 系列芯片組 → 500 系列芯片組2.5G 以太網(wǎng)WiFi 6U** 3.2 Gen 2*2封裝芯片薄化提高散熱效果

從這個列表看，和 Comet Lake 相比，Rocket Lake 的區(qū)別還是不少的，所欠缺的主要是制程依然屬于 14 納米節(jié)點。

Cypress Cove 微架構細節(jié)

Rocket Lake 中的 Cypress Cove 是 Sunny Cove 的變種，兩者基本上就是一回事，所以我這里使用 wikichip 上的 Sunny Cove 微架構圖來表展示：

我們接下來會使用 Travis Downs 的 robsize 等工具來驗證一些微架構上的細節(jié)，例如 ROB、Load Buffer、Store Buffer 等大小等，此外我們還會使用 SPEC CPU 2017 做分支預測、IPC 的測試。

微架構測試說明：

我們的 Cypress Cove 測試都是采用最新的微碼（0x39）下進行； 微架構分析除了頻率延伸測試外都是鎖定 4GHz 下進行；測試主板為華碩的 TUF Gaming Z590-PLUS WIFI、Strix Gaming X570-E，內存配置為 4×8 GiB，dual-rank，DDR4-3600MHz;測試的 CPU 均為最終版本；Rocket Lake 測試的**作系統(tǒng)版本為 Ubuntu 20.04.2 LTS (GNU/Linux 5.11.7-051107-generic x86_64)。分支預測懲罰/等效流水線深度測試

我們先看看 Cypress Cove 的分支預測懲罰周期數(shù)，這個數(shù)字可以反應處理器的等效整數(shù)流水線深度。

表中的左側是以偽代碼方式提供分支程序測試片段，以第 7 個測試（Test 6）為例：

Test 6, N= 1, 8 br, MOVZX XOR ; if (c & mask) { REP-N(c^=v[c-256]) } REP-2(c^=v[c-260])

這段偽代碼包含了一個 MOVZX 內存載入**作指令，它需要額外的 5 到 6 個周期來執(zhí)行，在支持亂序執(zhí)行、亂序 L/S 的處理器中，這個動作占用的流水線工位通常會被掩蓋掉。

從測試結果來看，Cypress Cove 的動態(tài)分支預測失敗懲罰比以前的 Coffee Lake 增加大約 0.5 到 2.5 個周期。

其中，Test 65 Cypress Cove是 22.95 個周期，Coffee Lake 是 20.36 個周期。

有理由相信 Cypress Cove 的流水線深度很可能比舊架構增加了兩到三個工位，但是因為一些優(yōu)化措施（例如微**作高速緩存？）使得分支預測失敗懲罰導致的性能損失在很多情況下看上去還能接受。

Zen 3 由于引入了無氣泡分支預測機制，所以可以在流水線深度和 Zen 2 一樣的情況下讓分支預測失敗懲罰顯著減少了 4 個周期，這點我去年的測試提到過。

從測試來看，Cypress Cove 的等效流水線深度大約是 14-22 級。

取指、解碼能力測試

處理器的流水線可以分為取指、解碼、執(zhí)行、寫回四個工位，其中前端（front-end）是指取指和解碼，執(zhí)行和寫回被稱為后端（back-end）。

對于現(xiàn)在的超標量流水線處理器說，每個周期可以執(zhí)行多條指令，前端需要為后端提供匹配的取指、解碼能力，同時為了保證流水線閑置執(zhí)行單元不浪費，人們還引入了分支預測單元，根據(jù)預測結果決定是否將下一條指令先派發(fā)給后端閑置的單元執(zhí)行，待分支確定是否選中后再決定是否保留計算結果或者重置流水線。

op cache 也被稱作 micro-op cache 或者 L0 I-Cache，它里面存放的是若干段處理器認為會被近期重復使用的微**作（micro-ops），所謂的微**作是 x86 處理器為了簡化后端設計引入的處理器本機指令，是已經經過解碼器解碼的長度固定的本機指令。

在循環(huán)語句里的指令在很多情況下都是不斷重復的，這些指令以微**作的方式放在 uop cache 后，后面重復執(zhí)行這些**作的話，就無須經過解碼器這個工位，直接發(fā)往后端的隊列里等待發(fā)射執(zhí)行。

uop cache 在 x86 上的原型是當年 Pentium 4 引入的 Trace Cache，Trache Cache 需要消耗大量的芯片面積，但是這是提高超長流水線架構處理器性能重要的一環(huán)。在 Pentium 4 終止后，Trace Cache 的瘦身版就以 uop cache 的形式引入。

要想了解處理器的能力，取指、解碼是我們首先想要了解的，在這里我們使用 nop、sub、prefix cmp 8 等三種指令來做測試，其中 nop 指令是看空**作指令，x86 的 nop 長度是 1 個 字節(jié)，sub 是減法指令，和加法指令 add 一樣在 x86 中指令長度都是兩個字節(jié)，prefix cmp 是 8 字節(jié)或者說 64 位長的指令。

我們圖表中給出的測試結果基于這樣的指令：

[rep][addrovr]cmp eax, 0x7fffffff）

從 NOP 指令的解碼帶寬測試來看，Cypress Cove 的性能要比 Comet Lake 略高（4.4byte per cycle vs 4.3 byte per cycle），曲線非常都平緩，說明此時的瓶頸主要是在解碼器或者后端而非取指和指令緩存的帶寬。

在 sub 指令解碼測試中，Cypress Cove 可以在 0~3 KiB 的位置實現(xiàn)最高大約 11.36 byte/cycle 的取指/解碼性能（相當于每個周期 5.68 條 x86 sub 指令），而 Comet Lake 在 0~8MiB 的范圍都是大約 8.6 byte/cycle，相當于每個周期 4.3 條 sub 指令。

從 sub 指令來看，Cypress Cove 可以放大約（等效） 1500 條 sub 指令解碼后的微**作，此時的解碼/執(zhí)行性能比 Comet Lake 高大約 30%。Comet Lake 在這個測試中的瓶頸在解碼或者執(zhí)行端。

在 8 字節(jié)長的 x86 指令取指、解碼測試中，Cypress Cove 做到了 0~11 KiB 的范圍最高可以實現(xiàn)每周期 36 字節(jié)的取指帶寬，相當于每個周期取指（以及解碼、執(zhí)行） 4.5 條 8 字節(jié)長指令，微**作高速緩存相當于可以存放 1375 條 8 字節(jié)長 x86 指令解碼后的微**作。

Comet Lake 是 0-6KiB 處可以實現(xiàn)最高每周期 34.14 字節(jié)的取指帶寬，相當于每周期取指 4.27 條 8 字節(jié)指令，微**作高速緩存相當于存放 750 條 8 字節(jié)長 x86 指令解碼后的微**作。

由于本機代碼或者說微**作的長度在不同的處理器上可能是不一樣的，因此我們無法根據(jù)上面的測試結果字節(jié)給出不同處理器的具體微**作條目數(shù)，但是如果以字節(jié)位容量來表示的話，倒是可以參考我們上面的結果。

例如 Cypress Cove 的微**作高速緩存容量可能不低于 11 KiB，Zen 3 則是不低于 21 KiB(鑒于 AMD 沒有說 Zen 3 微**作高速緩存容量有提升，因此我們之前估計這是由于 Zen 3 引入了微**作緊縮技術實現(xiàn)的)，實際的微**作高速緩存可能要比測試出來的字節(jié)值更大一些。

這里我們可以給出一個小結：

Cypress Cove 在等效解碼和實際指令執(zhí)行能力上有一定的提高，特別是 sub 這類指令，提升幅度大約大約 30%，達到了等效每周期 5.68 條 sub 指令，雖然這要比 AMD 每周期 5.98 條 sub 指令差一些，但也是非常不錯的表現(xiàn)，這里主要歸功于新的微**作緩存和更多的后端資源能實現(xiàn)每周期 6 條微**作的能力。Cypress Cove 的微**作高速緩存在帶寬和容量都較 Comet Lake 有一定的提升，最高等效容量相當于 Comet Lake 的兩倍（prefix CMP 指令的時候）。

3、Cypress Cove 的 prefix CMP 指令效能要比 Zen 3 更高一些，但是微**作高速緩存等效容量要比 Zen 3 低一半。

分支預測器

英特爾并沒有透露 Cypress Cove 和 Sunny Cove 的分支預測器細節(jié)，這基本上就是一個黑箱，大家感興趣的話可以自己寫代碼逆向探測一下，不過，對于我們或者說客戶來說可以透過處理器的**計數(shù)器來獲知分支預測失誤率，籍此了解新架構的分支預測器最終表現(xiàn)，我們這里使用 SPEC CPU2017 測試集來做分支預測的分析。

插播——關于 SPEC CPU 2017

本文會有大量的 CPU 2017 測試數(shù)據(jù)，為了讓大家清楚這是一個什么東西，先讓我在這里插一下相關的介紹，已了解的可以跳過本節(jié)。

CPU 2017 是非盈利機構 SPEC（標準性能評估公司）推出的 CPU 性能評估套件，SPEC 成立于 1998 年，會員包括 Intel、AMD、IBM、DELL、聯(lián)想、華碩、技嘉等業(yè)界大公司，每隔大約 10 年就會推出一版新的 CPU 性能評估套件，CPU 2017 是該機構在 2017 年推出的，是所有處理器、電腦廠商做處理器性能評估的最重要手段之一（如果不是使用上有一定門檻，上面這句話的“之一”是可以省略的）。

SPEC CPU 的特點是由各個機構提供實際應用的源碼，它的每一個子項目其實都是源自真實應用修改而來，其修改主要是針對可移植性和遵循的語言標準，例如 x264 的真實版本采用了大量的匯編代碼，但是這樣的形式不利于移植到不同指令集架構上測試，因此 CPU 2017 中的 x264 采用的是純 C 語言版本。

和上一版本 CPU 2006 相比，CPU 2017 的代碼已經全面更新，雖然依然使用 C/C++ 和 Fortran，但是相對以前的版本來說，已經變成了多語言的大混裝，F(xiàn)ortran 語言同時出現(xiàn)在浮點和整數(shù)測試集，而非像以往那樣只出現(xiàn)在浮點測試集。

CPU 2017 的規(guī)則更加嚴謹，speed 測試集允許使用 OpenMP 多線程處理，主要測試較大訪存壓力下的單任務多線程性能，而 rate 測試集則只允許單線程，禁止自動并行化，但是允許以多任務的方式跑多個 rate 測試，目的是測試吞吐率，單個 rate 任務的訪存壓力要比 speed 小很多。

不過 speed 測試集也不是全部項目都支持多線程，只有浮點密集型的 fpspeed 所有項目支持多線程，整數(shù)密集型的 intspeed 10 個子項目中只有最后的 657.xz_s（數(shù)據(jù)壓縮）是支持多線程的。

這樣的規(guī)則讓以往 CPU 2006 以及更早版本中常見的編譯器自動并行化“優(yōu)化”手段被禁止使用，減少了測試結果的混亂（測試如果使用了編譯器自動并行化后，實際上變成了編譯器比拼），提高了可比性。

上面兩個表格就是 CPU 2017 四組測試集的介紹，5 字頭的都是 rate 測試、6 字頭的都是 speed 測試，rate 不允許多線程或者自動并行化，但是可以同時跑多個相同實例的方式執(zhí)行。speed 只有 fpspeed 是全部支持多線程，intspeed 只有 657.xz_s 支持多線程。

657.xz_s 的內存開銷是 CPU 2017 單個子測試中名義最高的，根據(jù)觀察起碼需要 16GB 內存，但是實際上 fpspeed 對系統(tǒng)內存的需求更高，32 GB 內存的系統(tǒng)跑 fpspeed 會比 16 GB 內存快上一截。這其實是因為 32 GiB 測試的時候一般是 4 條 8GiB 內存，內存運作在 dual-rank 模式，而 16 GiB 一般是兩條 8 GiB 內存，運作于單 rank 模式。

我這次主要使用 gcc/g++/gfortran 10.2 的 GCC 三套件外加 Jemalloc 內存分配庫進行測試，采用 GCC 而不是 ICC、AOCC、LLVM 的原因有三點：

GNU 這邊有完整的 gfortran 實現(xiàn)，LLVM 那邊的 Flang/F18 目前缺乏 codegen，只有語義等環(huán)節(jié)，AMD 的 AOCC 在頁面介紹說是 LLVM 11，但是根據(jù) Flang/F18 開發(fā)人員 Kiran Chandramohan 給我的回信，AOCC 的 Flang 其實是基于老 Flang（并入 LLVM 之前）的，所以 LLVM 的工具集并不完整，不適合作為我們的測試使用。GCC 的性能比比 AOCC 更快。Intel 編譯器也是一個不錯的選擇，根據(jù)我的實測，跑起來會兩邊其實差不多，ICC 浮點會快一點點，整數(shù)一樣。我們希望盡量公平一點，所以在區(qū)別極小的情況下，一律使用 GCC。此外，GCC 有些特性是我覺得很有用的，例如它提供了讀取 native 微架構旗標時實際調用了哪些優(yōu)化開關的功能。GCC 10.2 和當年我初次接觸 的 GCC 4 相比已經有非常巨大的進步，不管是代碼生成質量還是兼容性、文檔和技術支持，都讓我可以有把握排除一些測試中遇到的問題，例如 GCC 10 引入了一些優(yōu)化開關的問題，經過查找文檔后我自己解決，而 SPEC 那邊也在稍早公布了相應的解決方案。

目前 SPEC CPU2017 的最新版本為 1.1.7，和之前的版本相比沒有性能影響的更改，新舊版本的測試結果具有可比性，所以我們就不重復測試之前的平臺，而 Core i9 11900K 則是采用最新的 1.1.7 來測試。

我們使用 SPEC CPU 2017 的 intrate 和 fprate 來做這個測試，具體結果見下表。

備注：

由于這次測試比較多，需要整理的數(shù)據(jù)比較多，表格中的動態(tài)指令數(shù)和分支指令書都是采集自 Zen 3 上的，不同處理器采用不同的編譯器參數(shù)都會在指令數(shù)、不同類型指令數(shù)上存在一些差別，這里我給出的只是作為一個參考，等稍后有空我也許會把不同處理器的動態(tài)指令數(shù)也一并整理。表格中的 Rocket Lake測試并未使用 AVX512 調用 zmm 寄存器的指令，所以你可以把它們看作是 AVX2 或者 AVX512 的 256 位版優(yōu)化下的結果。

正如上表的結果所示，Cypress Cove 的分支預測失誤率相對于 Comet Lake 來說分別降低了 16% 到 25%，改進幅度要明顯高于 Zen2 到 Zen3 的提升。

例如 505.mcf_r、526.blender_r，這兩個項目的分支預測失誤率就有顯著的改進。

分支預測命中率提高會對實際性能產生積極的影響，有理由相信英特爾對 Cypress Cove 的分支預測器動了不小的手術。

亂序執(zhí)行窗口

現(xiàn)代處理器為了追求指令并行（ILP）能力以求充分利用超標量的優(yōu)勢，都會在亂序執(zhí)行能力上下功夫，要維持亂序執(zhí)行，就需要為執(zhí)行單元提供盡可能多的待發(fā)指令，這就涉及到 ReOrder Buffer（ROB）、Load Buffer 和 Store Buffer 這三個緩存器，前者可以讓指令亂序執(zhí)行后將結果依照原有的順序重新排序，后兩者可以讓訪存指令實現(xiàn)亂序執(zhí)行。

首先讓我們看看 ROB 的測試：

正如你所看到的，Cypress Cove 曲線在 352 處出現(xiàn)了明顯的跳變，這個特征和 Sunny Cove 的 ROB 大小為 352 條目一樣，說明 Cypress Cove 的 ROB 也是 352 個條目。我們注意到在大約 68、112、176 處也有可見的跳變，這可能是因為 ROB 本身也有一些多層次化設計。

Comet Lake 的 ROB 測試結果為 224 條目。

ROB 更大，意味著可選的亂序執(zhí)行指令更多，指令并發(fā)的潛力也就越高。

接下來讓我們看看推測寄存器堆大小。眾所周知，x86 的寄存器數(shù)量是 8 個，x86_64 是 16 個，當處理器需要做推測執(zhí)行（利用空余執(zhí)行單元跑一些接下來可能會被用上也可能用不上的指令）的時候，就需要在亂序窗口里預留更多的物理寄存器，透過寄存器重命名技術，實現(xiàn)盡可能高的推測執(zhí)行飽和度。

我們使用 robsize 同樣的測試程序進行了物理寄存器堆（PRF）大小的探測。這里說明一下，我們前面的 ROB 大小探測使用的是 nop （空**作）指令，不占用任何寄存器，而接下來做的 PRF 大小推測測試，使用的是 add（加法）指令。

需要注意的是，物理寄存器堆里同時含有亂序執(zhí)行中可用于推測執(zhí)行的推測寄存器數(shù)量和已提交寄存器數(shù)量，因此這種測試方式不能把直觀地把整個物理寄存器堆的大小給出來，它只能測量出可用于推測執(zhí)行的寄存器數(shù)量。

從測試結果來看，Cypress Cove 可用于推測執(zhí)行的物理寄存器要比 Comet Lake 多了大約 100 個或者說增加了 69%，算是可以和 ROB 匹配的較大提升了（Zen 3 在這個測試中是 128 個，具體見我之前的 Zen 3 微架構測試）。

接下來我們看看可用于推測執(zhí)行的浮點物理寄存器，這里使用的時 AVX 指令。

正如你所看到的樣子，Cypress Cove 可用于推測執(zhí)行的物理浮點寄存器達到了大約 192 個，增加了大約 48 個或者說 33%（Zen 3 和 Zen 2 在這個測試中和 Comet Lake 一樣都是 144 個，這個在我之前的 Zen 3 微架構測試中已經提及）。

Load/Store Buffer 大小測試

現(xiàn)在的處理器不僅可以亂序執(zhí)行指令，還能亂序載入、存儲數(shù)據(jù)，這就涉及到 Load/Store Buffer。x86 屬于 CISC 指令集，它的指令里可以同時有訪存、寄存器、立即數(shù)**作，在 SPEC CPU 2017 中，CINT 2017 和 CFP2017 的 LD/ST 指令占比就分別高達34% 和 39%， Load/Store Buffer 對 x86 的性能影響也是不容小覷的，。

Zen3：

Comet Lake：

Sunny Cove：

Load-Buffer：

Zen3：116

CML ：72

RKL ：128

Store-Buffer：

Zen3：64

CML ：56

RKL ：72

從測試結果來看，Cypress Cove 的 Load/Store Buffer 是三者中最高的，理論上 Cypress Cove 在亂序 L/S 能力上應該是當下最強的。

后端

Cypress Cove 的后端和 Sunny Cove 相比基本上是一樣的，采用了統(tǒng)一調度器，但是以 4個保留站(下圖中的 RS 0、RS 1、RS 2、RS 3)的方式提供了不同的指令發(fā)射綁定。

圖中咖啡色的單元屬于 AVX512 執(zhí)行單元，紅色邊框便是這些是向量（VEC）單元。

微架構總結表 Thermal Velocity Boost 與 Adaptive Boost 加速技術

英特爾有多種自動加速技術，例如 Turbo Boost 已經發(fā)展到 Turbo Boost Max 3.0，在 Comet Lake 則是引入了Thermal Velocity Boost（溫控加速）的新加速技術。iTVB 的特點是在工況良好（溫度不高于 70 攝氏度，主板供電充足）的情況下，優(yōu)選體質最好的兩個內核，讓這兩個內核運行于比 Turbo Boost Max 3.0相當或者更高的頻率。

例如在 Core i9 11900K 上，在 iTVB 加持下兩個優(yōu)選核的頻率可以達到 5.3GHz。

除了 iTVB 外，Rocket Lake 還引入了名為 Adaptive Boost（自適應加速）技術，和 iTVB 是雙核加速相比，iAB 主要針對 3 到 8 核的加速，同樣需要根據(jù)工況而定，在條件滿足（100 攝氏度）的情況下，11900K 能實現(xiàn)全核 4.8GHz。

我們手頭這顆 Core i9 11900K 是序號最后的兩個（編號 6 和 編號 7 或者說第七個和第八個）內核可以運行于 5.3 GHz。

上圖是我們運行 SPEC CPU 2017 時候的狀態(tài)圖，可以看到編號最后的兩個內核此時正運行于大約 5.3GHz 的頻率。

AVX512 降頻效應顯著改善

AVX512 是英特爾提出的 512 位寬的向量指令擴展，支持多種位寬的向量寄存器，一次執(zhí)行 512 位指令看上去很美，但是最初的 AVX512 處理器存在一個嚴重的問題，那就是耗電高、發(fā)熱大，為此英特爾引入了基于許可頻率模式的降頻設計，導致程序跑 AVX 512 代碼路徑時候的性能收益并不高。

Rocket Lake 在 AVX-512 實現(xiàn)上做了很大改進，能夠在運行重載型AVX512 指令的時候保持全核 4.8GHz，相當于有沒有 AVX512 對頻率的影響都很低，當只有四核跑 AVX512 的時候更是不降頻，四核依然保持 5.1GHz。這樣的頻率變化完全匹配前面提及的 iTVB/iAB。

備注：

在 AVX 512 指令中，重載型指令包括了整數(shù)乘法以及浮點計算。相對的，輕載型是指除了乘法之外的整數(shù)計算、邏輯**作、數(shù)組打亂（shuffling）。

重載型指令一般用于深度學習、數(shù)據(jù)分析、高性能計算、密碼學（基于乘法的哈?；?；輕載指令一般用于文本處理、快速壓縮打包、庫例程的向量化（例如 C 語言里的 memcpy、Java 語言里的 System.arrayCopy）。

啟用 iTVB 和 AB 時不同指令類型和頻率的變化關系：

我們還使用 cpupower-gui 手動設置全核最高頻率為 5.1GHz 時（意味著放棄 iTVB 的 5.3GHz 雙核加速）還可以實現(xiàn)更少的頻率波動：

從這個測試來看，從 Rocket Lake 開始，如果放棄 iTVB 的話，AVX-512 對頻率的影響已經和其他類型指令一樣，只要散熱跟得上，就是可以隨便使用的指令擴展了。

GPU

現(xiàn)在顯卡市場由于挖礦狂潮導致**顯卡動輒五六千元一張，例如 RTX 3060 官方定價 2499 元，但是由于英偉達開發(fā)者網(wǎng)站的管理人員手滑把去掉挖礦限制的驅動掛到網(wǎng)上，結果導致 RTX 3060 瞬間漲價到 6000 元，經銷商眉開眼笑，老黃卻因為賺不到這筆錢白頭發(fā)又要多掉不少了。

**顯卡價格昂貴，于是很多等等**已經轉為核顯**了，某種程度上，現(xiàn)在核顯正是英特爾處理器的一大優(yōu)勢，要知道對手的 Ryzen 7 5000 系列消費者版本是沒有集成任何顯卡的，現(xiàn)在買 AMD Ryzen 7 5800X 回家后很可能要吃灰。

Rocket Lake 集成了代號 XeLP 的 UHD 750 核顯，擁有 32 個 EU,相對上一代架構提升了 50% 的效能。

Xe GPU 架構是一個高度可配置的架構，例如完整的 EU 里是包括了單精度、雙精度、擴展數(shù)學單元（相當于 NVIDIA 這邊的 SFU）、矩陣擴展（XMX），其中雙精度、XMX 都是屬于可選項，UHD750 不具備這兩個的單元。

此外，UHD750 也缺乏硬件光線**支持（見上圖），因為在 DX 12_1 特性中光線**屬于可選項。其他 DX12 特性例如 Mesh Shader 也是欠奉，VSR 支持 Tier 1。

根據(jù)我們的實測，UHD750 目前的單精度 OpenCL 性能大約是 640 GFLOPS，是上一代 UHD630（450 GFLOPS）的 1.4 倍多些。

如果說，Xe 架構是一個非常有看頭的架構的話，UHD 750 只是一個**了好多地方的瘦身版，可以滿足等等**最基本的 720p 級別網(wǎng)游需求。

實際性能測試測試平臺介紹

感謝 AMD、映泰（BioStar）、華碩（ASUS）、阿斯加特（Asgard）對本工作室的大力支持，使得本次測試使用到的處理器、內存可以及時就位，如果沒有這些基礎硬件的來臨，我現(xiàn)在應該會快樂地云測試。

主板：華碩 TUF Z590-Plus WIFI。

TUF 是英文 The Ultimate Force 的縮寫，就是終極力量的含義，在華碩的產品線中最初代指強調具備耐久品質，渾身披甲是當時這個系列給我的印象。不過隨著若干代產品的迭代，TUF 現(xiàn)在被**為入門游戲主板系列，再往上就是代表頂級的 ROG 系列。

TUF Z590-Plus WIFI 在供電接頭方面采用了 24pin ATX 和 8+4 pin CPU 方案，14+2 相供電，擁有三個 M.2 接口（其中一個支持 x4 Gen 4.0 模式），集成了 Intel 2.5Gbps（基于 i225） 以太網(wǎng)和 WiFi 6**網(wǎng)，主板一共提供了 6 個 SATA 3.0 接口。

在 PCIE 擴展槽方面，TUF Z590-Plus WIFI 提供了兩條全長 PCIE x16 插槽，靠近 CPU 的那條可以運作與 PCIE x16 Gen 4.0，另一條則是 PCIE x4 Gen 3.0。

內存規(guī)格方面，TUF Z590-Plus WIFI 最高可以支持 128 GiB DDR4-4800，算是目前很滿的規(guī)格了。

曜越科技 (Thermaltake) 大臺風 240cm 一體化液冷散熱器：

TT 的產品線現(xiàn)在基本上都是 RGB 化了，這款型號為大臺風 240 一體化水冷也不例外，值得一提的是它的銅底板水冷頭的正面采用可旋轉設計并且內嵌了一個顯示屏，可以顯示當前的水溫和水泵轉速，配合主板上的 5V RGB 接口就可以實現(xiàn)同步等效。

冷排采用了 Z 字微水路設計，低蒸發(fā)水管全覆蓋編織網(wǎng)，搭配的兩個 12cm 風扇具備 2.3mmH2O 分壓、31 dBA 噪音、每分鐘轉速 800-2100，可提供 70.5 CFM 的風量，用來** Core i9 11900K 再適合不過了。

大臺風系列還有一款 360 一體化水冷，適合支持 360 水冷的機箱，如果是漫威迷的話，TT 還有復仇者聯(lián)盟正版授權的聯(lián)名款（鋼鐵俠和美國隊長），我覺得也是非常炫酷的。

我覺得像 Core i9 11900K 這種旗艦處理器，雖然用重型風冷也許可以壓住，但是現(xiàn)在市場上已經有許多成熟的一體化水冷產品，不妨考慮一下，也不一定 TT，其他牌子型號都值得考慮。

曜越科技 (Thermaltake) ToughRam DDR4 4000 16GB 套裝

TT 還提供了兩對 DDR4 3600 內存，型號是 ToughRam DDR4 4000 16GB 套裝，這款內存強調堅固耐用，10 層 PCB 板兩盎司敷銅，金手指鍍金厚度為 10 微米，內置了 XMP 2.0 頻率參數(shù)，實現(xiàn)一鍵設置。

雖然內存的個頭比較高，但是我們用水冷呀，所以一點都不礙事，如果是巨型風冷的話，可能未必能順利安裝這種內存。用戶可以透過 TT 提供的 ToughRam 軟件查看內存的實時溫度和頻率。

SPEC CPU 2017——定頻 4GHz

首先，我們使用同頻率 4GHz 來測試，其中插播一片 10 年前的 Core i7 2600K：

從測試結果來看，在同頻下 Rocket Lake 的單實例整數(shù)、浮點性能分別是 Zen3 的 92%、99% 以及 Comet Lake 的 112% 和 118%。

在多線程或者說 speed 測試中, Rocket Lake 的整數(shù)、浮點性能分別是 Zen3 的 91%、106% 以及 Comet Lake 的 111% 和 106%。

英特爾上一代架構或者說Comet Lake 雖然有 10 個內核，但除了 638.imagick_s （圖像處理，浮點密集型）和 657.xz_s（文件壓縮，整數(shù)密集型）外，看不出多出兩個內核的優(yōu)勢。

SPEC CPU 2017——默認頻率

默認頻率是指 BIOS 內重置為出廠優(yōu)化設置，**作系統(tǒng)將 CPU 電源管理設置為性能模式，此時 Rocket Lake 的 iTVB/iAB 加速管理將會被啟用，Linux 在單實例測試中會優(yōu)選其中兩個工況良好的內核跑 5.3GHz。

從測試結果來看，在默認頻率下 Core i9 11900K 的單實例整數(shù)、浮點性能分別是 Ryzen 7 5800X 的 99%、106% 以及 Core i9 10900K 的 116% 和 123%。

在多線程或者說 speed 測試中, Core i9 11900K 的整數(shù)、浮點性能分別是 Ryzen 7 5800X 的 98%、110% 以及 Core i9 10900K 的 115% 和 114%。

默頻下 10900K 額外的兩個內核完全看不到任何優(yōu)勢。

測試總結

從性能角度來看的話，Rocket Lake 的確較上一代 Comet Lake 有不少的性能提升，例如單線程浮點性能提升幅度接近 23%、整數(shù) 16%，兩個值平均起來的話（19.5%）和英特爾說的提升了 19% 非常接近。

Rocket Lake 引入了 AVX-512，英特爾顯然做了不少優(yōu)化，從而讓處理器可以在重載型 AVX-512 指令全核運行時依然保持非常高的速度（4.8 GHz），AVX-512 現(xiàn)在已經成為值得一試的指令擴展。

當然，Rocket Lake 的最大缺點是依然采用 14 納米制程，這導致它的耗電和發(fā)熱遠遠高于同期競爭對手 Zen 3，強烈建議用戶需要配置水冷（水冷廠商在偷笑了）。

和 AMD 的 Zen 3 相比，Rocket Lake 還是比較稱職的，至少性能上是很接近了，還有核顯，AMD Ryzen 桌面消費者版本目前是欠缺核顯的，在目前的顯卡市場狀況下，我相信 K 系列的十一代處理器銷量很可能會維持在較高的水平，當然，你要是樂意花錢買片**顯卡做亮機卡也是合情合理的。

最后，我想說的是很高興聽到英特爾將會重回 Tick-Tock 戰(zhàn)略，擠牙膏同義詞的 PAO 至少在一段時間里會被取消，英特爾今年下半年將會推出的下一代或者說第十二代架構 Alder Lake 應該非常值得期待，要知道這個玩意不僅是要和 AMD 競爭，而且還擔當起了抗擊蘋果 Apple Silicon 的重任。

聯(lián)想z500進入bios設置按哪個鍵()和聯(lián)想z500進入bios設置按哪個鍵()的問題分享結束啦，以上的文章解決了您的問題嗎？歡迎您下次再來哦！