联想z500进入bios设置按哪个键()

其实联想z500进入bios设置按哪个键()的问题并不复杂，但是又很多的朋友都不太了解联想z500进入bios设置按哪个键()，因此呢，今天小编就来为大家分享联想z500进入bios设置按哪个键()的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

英特尔十一代酷睿微架构 Rocket-Lake 测试报告

英特尔十一代酷睿处理器微架构 Rocket-Lake 测试报告

日渐凌乱的舞步——从 Tick-Tock 到 PAO

所谓 Tick-Tock 是指英特尔在 2007 年发表的产品推出模型，含义并不复杂：

Tick：新的半导体制程

Tock：新的微架构

Tick-Tock 本身只是大家对“节拍”的读音，类似于中文里的“滴答”，而 Tick-Tock 产品发布模型就是指一波新制程然后一波新架构的产品发布节奏。

2007年的时候英特尔是处于怎样的业务环境呢？

如果翻开这段还很新鲜的历史，可以看到2007 年的时候，英特尔正处于从最后一代 Pentium 4（65nm Cedar Mill，2007 年 1 月发布）切换到 Core 2（65nm Conroe，2007 年 7 月发布）的转折点，和 AMD 之间自 K7 以来的竞争依然处于白热化阶段。

AMD 当时在 x64 指令集拿下一血，但是在制程稍微落后，K7 /K8 的微架构潜力基本到头，架构团队正在憋大招（然而这个大招事后看来真是一言难尽）。

英特尔当时原本计划是想要在 Netburst 上再赌一把推代号 Tejas 的新 Pentium 4，在英特尔的Netburst 愿景中，65nm 制程将有望实现 10GHz，Tejas 就是这样愿景下的架构。

最初的 Tejas 本来是基于 90nm，但是后来改为 65nm，为了配合 Tejas，英特尔弄出了现在已经绝迹的 BTX 主板规格（处理器位于主板左侧、扩展卡插槽位于右侧，和 ATX 完全相反），官方配的 Tejas 散热器也是极其硕大。

然而，Tejas 最终还是夭折了，基于 Conroe 的 Core 2 横空出世，全面扭转了 Pentium 4 逐渐下行的趋势。

英特尔的 Tick-Tock 至此正式展开布局，而AMD 开始陷入到长达 10 年的低迷中。

面临来自 AMD 的高强压力，正是 Tick-Tock 诞生的主要背景。

我们见证了在 Tick-Tock 的驱动下 Conroe 微架构及其衍生微架构的辉煌，但是到了 2016 年，英特尔认为 Tick-Tock 驱动模式下由于芯片微缩的成本越来越高，不符合经济性，因此宣布这个 10 年的产品发布模型终结，改为采用名为 Process–Architecture–Optimization（PAO，制程-架构-优化）的产品发布模型。

在 PAO 模式下，每个制程节点的产品从两代变成三代（以上），由此可见，PAO 产品策略诞生于一个竞争压力较小、新制程研发成本日益高涨、微架构潜力似乎还有挖掘空间的业务环境里。

如果说当年 AMD 的推土机采用 CMT 架构太“浪”了，那么英特尔这几年的 PAO 则更像一个财务先决下的保守型策略。

所幸的是英特尔底子远非其他半导体厂商所能比的，所以 PAO 这口饭倒是稳稳当当地吃了好些年，从 2014 年 8 月的 Broadwell（第一批 Broadwell 处理器属于 Core M 产品线，被定义为第四代 Core，不过台式版本被定义为第五代 Core）开始算，14 纳米缝缝补补，居然混了 7 年之久，这样的情况对其他头部处理器厂商来说是有点不可思议的。

上面的表格就是14nm 到 7 nm 制程上的 PAO 清单，说实话，如果没有这个表格的话，我相信很多人都会搞不清英特尔这几年到底干了些啥，一会儿 lake 一会儿 cove，这些代号到底是微架构还是芯片？现在这个表格基本上是一目了然。

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

PAO 从经济学的角度来说无可厚非，但是随之而来的问题是作为美国半导体扛把子的英特尔搞这套后，导致制程研发进度被人为拉长，以至于最近有人说是英特尔技术不行了，其实非也，最主要的问题还是 PAO 这套规划让英特尔的核心指导策略变得满足于对制程和微架构的精雕细琢（大家通俗点的说法就是挤牙膏）。

RocketLake 就是在 PAO 策略下的英特尔最新一代处理器架构，RocketLake 这个名字属于SoC 级别的微架构代号，桌面的 RocketLake-S 包含了代号是 Cypress Cove（微架构与 Sunny Cove 同代，因为使用 14nm 而名字上有不同）的 CPU 内核微架构、 32 个 EU 的 Xe-LP GT2 核显，对应的产品系列就是第十一代台式酷睿处理器。

正如我们前面的表格所展示的，RocketLake 属于架构前移，这里的前移含义是它采用的CPU 微架构 Cypress Cove源自 Sunny Cove，原本对应的制程并非 14 纳米优化，而应该是 10 纳米制程。

Sunny Cove 是 2019 年就推出的 CPU 内核微架构，笔记本/服务器版本的 SoC 微架构实现是大家耳熟能详的 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 编译程序的时候，需要特别指定优选 512-bit 寄存器（寄存器标识为 zmm）宽度才能实现 AVX-512 的 512 位版本（AVX512F）指令支持，只有这样才能编译出真正使用 zmm 寄存器的二进制对象文件。

英特尔的 OneAPI HPC 编译器则只要使用 icelake 旗标默认就会启用采用 zmm 或者说 AVX512F 指令。

见下图，红色高亮的就是表明编译出来的二进制文件包含了 zmm 寄存器调用（这里是 OneAPI HPC 编译 SPEC CPU 2017 的 503.bwaves 子项目为示例），此时程序将会采用含有 512 位版本的 AVX-512 指令执行：

总括而言，英特尔这些年微架构代号、产品型号、制程关联度如此复杂，即使是行内人也会感到各种迷惑，而这正是数年来英特尔在 PAO 策略下演绎的凌乱舞步。

RocketLake SoC微架构概况

RocketLake 是十一代桌面酷睿处理器的 SoC 微架构代号，均为 LGA 1200 引脚，Z400 系列(部分)和 Z500 系列芯片组主板都能提供支持，其中集成显卡的 K 系列有三个型号，见下表：

RocketLake 的 CPU 内核微架构代号是 Cypress Cove，在指令集方面具备 AVX512F、VNNI 等指令扩展，引入了比上一代微架构（CometLake）更大的重排序缓存（ReOrder Buffer）和一级数据缓存（L1 D-Cache），最高 8 个内核 16 线程（CometLake-S 最高可以 10 核 20 线程），周边高速互连方面实现了 PCIe 4.0 的支持（20 条 PCIe 4.0 信道），核显更新为性能显著提升（50%）的全新Xe-LP 架构GPU，支持更高规格的显示输出，与 PCH（南桥）连接的总线 DMI 3.0 信道数提升为 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 以太网WiFi 6U** 3.2 Gen 2*2封装芯片薄化提高散热效果

从这个列表看，和 Comet Lake 相比，Rocket Lake 的区别还是不少的，所欠缺的主要是制程依然属于 14 纳米节点。

Cypress Cove 微架构细节

Rocket Lake 中的 Cypress Cove 是 Sunny Cove 的变种，两者基本上就是一回事，所以我这里使用 wikichip 上的 Sunny Cove 微架构图来表展示：

我们接下来会使用 Travis Downs 的 robsize 等工具来验证一些微架构上的细节，例如 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 测试的**作系统版本为 Ubuntu 20.04.2 LTS (GNU/Linux 5.11.7-051107-generic x86_64)。分支预测惩罚/等效流水线深度测试

我们先看看 Cypress Cove 的分支预测惩罚周期数，这个数字可以反应处理器的等效整数流水线深度。

表中的左侧是以伪代码方式提供分支程序测试片段，以第 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 个周期来执行，在支持乱序执行、乱序 L/S 的处理器中，这个动作占用的流水线工位通常会被掩盖掉。

从测试结果来看，Cypress Cove 的动态分支预测失败惩罚比以前的 Coffee Lake 增加大约 0.5 到 2.5 个周期。

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

有理由相信 Cypress Cove 的流水线深度很可能比旧架构增加了两到三个工位，但是因为一些优化措施（例如微**作高速缓存？）使得分支预测失败惩罚导致的性能损失在很多情况下看上去还能接受。

Zen 3 由于引入了无气泡分支预测机制，所以可以在流水线深度和 Zen 2 一样的情况下让分支预测失败惩罚显著减少了 4 个周期，这点我去年的测试提到过。

从测试来看，Cypress Cove 的等效流水线深度大约是 14-22 级。

取指、解码能力测试

处理器的流水线可以分为取指、解码、执行、写回四个工位，其中前端（front-end）是指取指和解码，执行和写回被称为后端（back-end）。

对于现在的超标量流水线处理器说，每个周期可以执行多条指令，前端需要为后端提供匹配的取指、解码能力，同时为了保证流水线闲置执行单元不浪费，人们还引入了分支预测单元，根据预测结果决定是否将下一条指令先派发给后端闲置的单元执行，待分支确定是否选中后再决定是否保留计算结果或者重置流水线。

op cache 也被称作 micro-op cache 或者 L0 I-Cache，它里面存放的是若干段处理器认为会被近期重复使用的微**作（micro-ops），所谓的微**作是 x86 处理器为了简化后端设计引入的处理器本机指令，是已经经过解码器解码的长度固定的本机指令。

在循环语句里的指令在很多情况下都是不断重复的，这些指令以微**作的方式放在 uop cache 后，后面重复执行这些**作的话，就无须经过解码器这个工位，直接发往后端的队列里等待发射执行。

uop cache 在 x86 上的原型是当年 Pentium 4 引入的 Trace Cache，Trache Cache 需要消耗大量的芯片面积，但是这是提高超长流水线架构处理器性能重要的一环。在 Pentium 4 终止后，Trace Cache 的瘦身版就以 uop cache 的形式引入。

要想了解处理器的能力，取指、解码是我们首先想要了解的，在这里我们使用 nop、sub、prefix cmp 8 等三种指令来做测试，其中 nop 指令是看空**作指令，x86 的 nop 长度是 1 个 字节，sub 是减法指令，和加法指令 add 一样在 x86 中指令长度都是两个字节，prefix cmp 是 8 字节或者说 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 的位置实现最高大约 11.36 byte/cycle 的取指/解码性能（相当于每个周期 5.68 条 x86 sub 指令），而 Comet Lake 在 0~8MiB 的范围都是大约 8.6 byte/cycle，相当于每个周期 4.3 条 sub 指令。

从 sub 指令来看，Cypress Cove 可以放大约（等效） 1500 条 sub 指令解码后的微**作，此时的解码/执行性能比 Comet Lake 高大约 30%。Comet Lake 在这个测试中的瓶颈在解码或者执行端。

在 8 字节长的 x86 指令取指、解码测试中，Cypress Cove 做到了 0~11 KiB 的范围最高可以实现每周期 36 字节的取指带宽，相当于每个周期取指（以及解码、执行） 4.5 条 8 字节长指令，微**作高速缓存相当于可以存放 1375 条 8 字节长 x86 指令解码后的微**作。

Comet Lake 是 0-6KiB 处可以实现最高每周期 34.14 字节的取指带宽，相当于每周期取指 4.27 条 8 字节指令，微**作高速缓存相当于存放 750 条 8 字节长 x86 指令解码后的微**作。

由于本机代码或者说微**作的长度在不同的处理器上可能是不一样的，因此我们无法根据上面的测试结果字节给出不同处理器的具体微**作条目数，但是如果以字节位容量来表示的话，倒是可以参考我们上面的结果。

例如 Cypress Cove 的微**作高速缓存容量可能不低于 11 KiB，Zen 3 则是不低于 21 KiB(鉴于 AMD 没有说 Zen 3 微**作高速缓存容量有提升，因此我们之前估计这是由于 Zen 3 引入了微**作紧缩技术实现的)，实际的微**作高速缓存可能要比测试出来的字节值更大一些。

这里我们可以给出一个小结：

Cypress Cove 在等效解码和实际指令执行能力上有一定的提高，特别是 sub 这类指令，提升幅度大约大约 30%，达到了等效每周期 5.68 条 sub 指令，虽然这要比 AMD 每周期 5.98 条 sub 指令差一些，但也是非常不错的表现，这里主要归功于新的微**作缓存和更多的后端资源能实现每周期 6 条微**作的能力。Cypress Cove 的微**作高速缓存在带宽和容量都较 Comet Lake 有一定的提升，最高等效容量相当于 Comet Lake 的两倍（prefix CMP 指令的时候）。

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

分支预测器

英特尔并没有透露 Cypress Cove 和 Sunny Cove 的分支预测器细节，这基本上就是一个黑箱，大家感兴趣的话可以自己写代码逆向探测一下，不过，对于我们或者说客户来说可以透过处理器的**计数器来获知分支预测失误率，籍此了解新架构的分支预测器最终表现，我们这里使用 SPEC CPU2017 测试集来做分支预测的分析。

插播——关于 SPEC CPU 2017

本文会有大量的 CPU 2017 测试数据，为了让大家清楚这是一个什么东西，先让我在这里插一下相关的介绍，已了解的可以跳过本节。

CPU 2017 是非盈利机构 SPEC（标准性能评估公司）推出的 CPU 性能评估套件，SPEC 成立于 1998 年，会员包括 Intel、AMD、IBM、DELL、联想、华硕、技嘉等业界大公司，每隔大约 10 年就会推出一版新的 CPU 性能评估套件，CPU 2017 是该机构在 2017 年推出的，是所有处理器、电脑厂商做处理器性能评估的最重要手段之一（如果不是使用上有一定门槛，上面这句话的“之一”是可以省略的）。

SPEC CPU 的特点是由各个机构提供实际应用的源码，它的每一个子项目其实都是源自真实应用修改而来，其修改主要是针对可移植性和遵循的语言标准，例如 x264 的真实版本采用了大量的汇编代码，但是这样的形式不利于移植到不同指令集架构上测试，因此 CPU 2017 中的 x264 采用的是纯 C 语言版本。

和上一版本 CPU 2006 相比，CPU 2017 的代码已经全面更新，虽然依然使用 C/C++ 和 Fortran，但是相对以前的版本来说，已经变成了多语言的大混装，Fortran 语言同时出现在浮点和整数测试集，而非像以往那样只出现在浮点测试集。

CPU 2017 的规则更加严谨，speed 测试集允许使用 OpenMP 多线程处理，主要测试较大访存压力下的单任务多线程性能，而 rate 测试集则只允许单线程，禁止自动并行化，但是允许以多任务的方式跑多个 rate 测试，目的是测试吞吐率，单个 rate 任务的访存压力要比 speed 小很多。

不过 speed 测试集也不是全部项目都支持多线程，只有浮点密集型的 fpspeed 所有项目支持多线程，整数密集型的 intspeed 10 个子项目中只有最后的 657.xz_s（数据压缩）是支持多线程的。

这样的规则让以往 CPU 2006 以及更早版本中常见的编译器自动并行化“优化”手段被禁止使用，减少了测试结果的混乱（测试如果使用了编译器自动并行化后，实际上变成了编译器比拼），提高了可比性。

上面两个表格就是 CPU 2017 四组测试集的介绍，5 字头的都是 rate 测试、6 字头的都是 speed 测试，rate 不允许多线程或者自动并行化，但是可以同时跑多个相同实例的方式执行。speed 只有 fpspeed 是全部支持多线程，intspeed 只有 657.xz_s 支持多线程。

657.xz_s 的内存开销是 CPU 2017 单个子测试中名义最高的，根据观察起码需要 16GB 内存，但是实际上 fpspeed 对系统内存的需求更高，32 GB 内存的系统跑 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 实现，LLVM 那边的 Flang/F18 目前缺乏 codegen，只有语义等环节，AMD 的 AOCC 在页面介绍说是 LLVM 11，但是根据 Flang/F18 开发人员 Kiran Chandramohan 给我的回信，AOCC 的 Flang 其实是基于老 Flang（并入 LLVM 之前）的，所以 LLVM 的工具集并不完整，不适合作为我们的测试使用。GCC 的性能比比 AOCC 更快。Intel 编译器也是一个不错的选择，根据我的实测，跑起来会两边其实差不多，ICC 浮点会快一点点，整数一样。我们希望尽量公平一点，所以在区别极小的情况下，一律使用 GCC。此外，GCC 有些特性是我觉得很有用的，例如它提供了读取 native 微架构旗标时实际调用了哪些优化开关的功能。GCC 10.2 和当年我初次接触 的 GCC 4 相比已经有非常巨大的进步，不管是代码生成质量还是兼容性、文档和技术支持，都让我可以有把握排除一些测试中遇到的问题，例如 GCC 10 引入了一些优化开关的问题，经过查找文档后我自己解决，而 SPEC 那边也在稍早公布了相应的解决方案。

目前 SPEC CPU2017 的最新版本为 1.1.7，和之前的版本相比没有性能影响的更改，新旧版本的测试结果具有可比性，所以我们就不重复测试之前的平台，而 Core i9 11900K 则是采用最新的 1.1.7 来测试。

我们使用 SPEC CPU 2017 的 intrate 和 fprate 来做这个测试，具体结果见下表。

备注：

由于这次测试比较多，需要整理的数据比较多，表格中的动态指令数和分支指令书都是采集自 Zen 3 上的，不同处理器采用不同的编译器参数都会在指令数、不同类型指令数上存在一些差别，这里我给出的只是作为一个参考，等稍后有空我也许会把不同处理器的动态指令数也一并整理。表格中的 Rocket Lake测试并未使用 AVX512 调用 zmm 寄存器的指令，所以你可以把它们看作是 AVX2 或者 AVX512 的 256 位版优化下的结果。

正如上表的结果所示，Cypress Cove 的分支预测失误率相对于 Comet Lake 来说分别降低了 16% 到 25%，改进幅度要明显高于 Zen2 到 Zen3 的提升。

例如 505.mcf_r、526.blender_r，这两个项目的分支预测失误率就有显著的改进。

分支预测命中率提高会对实际性能产生积极的影响，有理由相信英特尔对 Cypress Cove 的分支预测器动了不小的手术。

乱序执行窗口

现代处理器为了追求指令并行（ILP）能力以求充分利用超标量的优势，都会在乱序执行能力上下功夫，要维持乱序执行，就需要为执行单元提供尽可能多的待发指令，这就涉及到 ReOrder Buffer（ROB）、Load Buffer 和 Store Buffer 这三个缓存器，前者可以让指令乱序执行后将结果依照原有的顺序重新排序，后两者可以让访存指令实现乱序执行。

首先让我们看看 ROB 的测试：

正如你所看到的，Cypress Cove 曲线在 352 处出现了明显的跳变，这个特征和 Sunny Cove 的 ROB 大小为 352 条目一样，说明 Cypress Cove 的 ROB 也是 352 个条目。我们注意到在大约 68、112、176 处也有可见的跳变，这可能是因为 ROB 本身也有一些多层次化设计。

Comet Lake 的 ROB 测试结果为 224 条目。

ROB 更大，意味着可选的乱序执行指令更多，指令并发的潜力也就越高。

接下来让我们看看推测寄存器堆大小。众所周知，x86 的寄存器数量是 8 个，x86_64 是 16 个，当处理器需要做推测执行（利用空余执行单元跑一些接下来可能会被用上也可能用不上的指令）的时候，就需要在乱序窗口里预留更多的物理寄存器，透过寄存器重命名技术，实现尽可能高的推测执行饱和度。

我们使用 robsize 同样的测试程序进行了物理寄存器堆（PRF）大小的探测。这里说明一下，我们前面的 ROB 大小探测使用的是 nop （空**作）指令，不占用任何寄存器，而接下来做的 PRF 大小推测测试，使用的是 add（加法）指令。

需要注意的是，物理寄存器堆里同时含有乱序执行中可用于推测执行的推测寄存器数量和已提交寄存器数量，因此这种测试方式不能把直观地把整个物理寄存器堆的大小给出来，它只能测量出可用于推测执行的寄存器数量。

从测试结果来看，Cypress Cove 可用于推测执行的物理寄存器要比 Comet Lake 多了大约 100 个或者说增加了 69%，算是可以和 ROB 匹配的较大提升了（Zen 3 在这个测试中是 128 个，具体见我之前的 Zen 3 微架构测试）。

接下来我们看看可用于推测执行的浮点物理寄存器，这里使用的时 AVX 指令。

正如你所看到的样子，Cypress Cove 可用于推测执行的物理浮点寄存器达到了大约 192 个，增加了大约 48 个或者说 33%（Zen 3 和 Zen 2 在这个测试中和 Comet Lake 一样都是 144 个，这个在我之前的 Zen 3 微架构测试中已经提及）。

Load/Store Buffer 大小测试

现在的处理器不仅可以乱序执行指令，还能乱序载入、存储数据，这就涉及到 Load/Store Buffer。x86 属于 CISC 指令集，它的指令里可以同时有访存、寄存器、立即数**作，在 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 相比基本上是一样的，采用了统一调度器，但是以 4个保留站(下图中的 RS 0、RS 1、RS 2、RS 3)的方式提供了不同的指令发射绑定。

图中咖啡色的单元属于 AVX512 执行单元，红色边框便是这些是向量（VEC）单元。

微架构总结表 Thermal Velocity Boost 与 Adaptive Boost 加速技术

英特尔有多种自动加速技术，例如 Turbo Boost 已经发展到 Turbo Boost Max 3.0，在 Comet Lake 则是引入了Thermal Velocity Boost（温控加速）的新加速技术。iTVB 的特点是在工况良好（温度不高于 70 摄氏度，主板供电充足）的情况下，优选体质最好的两个内核，让这两个内核运行于比 Turbo Boost Max 3.0相当或者更高的频率。

例如在 Core i9 11900K 上，在 iTVB 加持下两个优选核的频率可以达到 5.3GHz。

除了 iTVB 外，Rocket Lake 还引入了名为 Adaptive Boost（自适应加速）技术，和 iTVB 是双核加速相比，iAB 主要针对 3 到 8 核的加速，同样需要根据工况而定，在条件满足（100 摄氏度）的情况下，11900K 能实现全核 4.8GHz。

我们手头这颗 Core i9 11900K 是序号最后的两个（编号 6 和 编号 7 或者说第七个和第八个）内核可以运行于 5.3 GHz。

上图是我们运行 SPEC CPU 2017 时候的状态图，可以看到编号最后的两个内核此时正运行于大约 5.3GHz 的频率。

AVX512 降频效应显著改善

AVX512 是英特尔提出的 512 位宽的向量指令扩展，支持多种位宽的向量寄存器，一次执行 512 位指令看上去很美，但是最初的 AVX512 处理器存在一个严重的问题，那就是耗电高、发热大，为此英特尔引入了基于许可频率模式的降频设计，导致程序跑 AVX 512 代码路径时候的性能收益并不高。

Rocket Lake 在 AVX-512 实现上做了很大改进，能够在运行重载型AVX512 指令的时候保持全核 4.8GHz，相当于有没有 AVX512 对频率的影响都很低，当只有四核跑 AVX512 的时候更是不降频，四核依然保持 5.1GHz。这样的频率变化完全匹配前面提及的 iTVB/iAB。

备注：

在 AVX 512 指令中，重载型指令包括了整数乘法以及浮点计算。相对的，轻载型是指除了乘法之外的整数计算、逻辑**作、数组打乱（shuffling）。

重载型指令一般用于深度学习、数据分析、高性能计算、密码学（基于乘法的哈希化）；轻载指令一般用于文本处理、快速压缩打包、库例程的向量化（例如 C 语言里的 memcpy、Java 语言里的 System.arrayCopy）。

启用 iTVB 和 AB 时不同指令类型和频率的变化关系：

我们还使用 cpupower-gui 手动设置全核最高频率为 5.1GHz 时（意味着放弃 iTVB 的 5.3GHz 双核加速）还可以实现更少的频率波动：

从这个测试来看，从 Rocket Lake 开始，如果放弃 iTVB 的话，AVX-512 对频率的影响已经和其他类型指令一样，只要散热跟得上，就是可以随便使用的指令扩展了。

GPU

现在显卡市场由于挖矿狂潮导致**显卡动辄五六千元一张，例如 RTX 3060 官方定价 2499 元，但是由于英伟达开发者网站的管理人员手滑把去掉挖矿限制的驱动挂到网上，结果导致 RTX 3060 瞬间涨价到 6000 元，经销商眉开眼笑，老黄却因为赚不到这笔钱白头发又要多掉不少了。

**显卡价格昂贵，于是很多等等**已经转为核显**了，某种程度上，现在核显正是英特尔处理器的一大优势，要知道对手的 Ryzen 7 5000 系列消费者版本是没有集成任何显卡的，现在买 AMD Ryzen 7 5800X 回家后很可能要吃灰。

Rocket Lake 集成了代号 XeLP 的 UHD 750 核显，拥有 32 个 EU,相对上一代架构提升了 50% 的效能。

Xe GPU 架构是一个高度可配置的架构，例如完整的 EU 里是包括了单精度、双精度、扩展数学单元（相当于 NVIDIA 这边的 SFU）、矩阵扩展（XMX），其中双精度、XMX 都是属于可选项，UHD750 不具备这两个的单元。

此外，UHD750 也缺乏硬件光线**支持（见上图），因为在 DX 12_1 特性中光线**属于可选项。其他 DX12 特性例如 Mesh Shader 也是欠奉，VSR 支持 Tier 1。

根据我们的实测，UHD750 目前的单精度 OpenCL 性能大约是 640 GFLOPS，是上一代 UHD630（450 GFLOPS）的 1.4 倍多些。

如果说，Xe 架构是一个非常有看头的架构的话，UHD 750 只是一个**了好多地方的瘦身版，可以满足等等**最基本的 720p 级别网游需求。

实际性能测试测试平台介绍

感谢 AMD、映泰（BioStar）、华硕（ASUS）、阿斯加特（Asgard）对本工作室的大力支持，使得本次测试使用到的处理器、内存可以及时就位，如果没有这些基础硬件的来临，我现在应该会快乐地云测试。

主板：华硕 TUF Z590-Plus WIFI。

TUF 是英文 The Ultimate Force 的缩写，就是终极力量的含义，在华硕的产品线中最初代指强调具备耐久品质，浑身披甲是当时这个系列给我的印象。不过随着若干代产品的迭代，TUF 现在被**为入门游戏主板系列，再往上就是代表顶级的 ROG 系列。

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

在 PCIE 扩展槽方面，TUF Z590-Plus WIFI 提供了两条全长 PCIE x16 插槽，靠近 CPU 的那条可以运作与 PCIE x16 Gen 4.0，另一条则是 PCIE x4 Gen 3.0。

内存规格方面，TUF Z590-Plus WIFI 最高可以支持 128 GiB DDR4-4800，算是目前很满的规格了。

曜越科技 (Thermaltake) 大台风 240cm 一体化液冷散热器：

TT 的产品线现在基本上都是 RGB 化了，这款型号为大台风 240 一体化水冷也不例外，值得一提的是它的铜底板水冷头的正面采用可旋转设计并且内嵌了一个显示屏，可以显示当前的水温和水泵转速，配合主板上的 5V RGB 接口就可以实现同步等效。

冷排采用了 Z 字微水路设计，低蒸发水管全覆盖编织网，搭配的两个 12cm 风扇具备 2.3mmH2O 分压、31 dBA 噪音、每分钟转速 800-2100，可提供 70.5 CFM 的风量，用来** Core i9 11900K 再适合不过了。

大台风系列还有一款 360 一体化水冷，适合支持 360 水冷的机箱，如果是漫威迷的话，TT 还有复仇者联盟正版授权的联名款（钢铁侠和美国队长），我觉得也是非常炫酷的。

我觉得像 Core i9 11900K 这种旗舰处理器，虽然用重型风冷也许可以压住，但是现在市场上已经有许多成熟的一体化水冷产品，不妨考虑一下，也不一定 TT，其他牌子型号都值得考虑。

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

TT 还提供了两对 DDR4 3600 内存，型号是 ToughRam DDR4 4000 16GB 套装，这款内存强调坚固耐用，10 层 PCB 板两盎司敷铜，金手指镀金厚度为 10 微米，内置了 XMP 2.0 频率参数，实现一键设置。

虽然内存的个头比较高，但是我们用水冷呀，所以一点都不碍事，如果是巨型风冷的话，可能未必能顺利安装这种内存。用户可以透过 TT 提供的 ToughRam 软件查看内存的实时温度和频率。

SPEC CPU 2017——定频 4GHz

首先，我们使用同频率 4GHz 来测试，其中插播一片 10 年前的 Core i7 2600K：

从测试结果来看，在同频下 Rocket Lake 的单实例整数、浮点性能分别是 Zen3 的 92%、99% 以及 Comet Lake 的 112% 和 118%。

在多线程或者说 speed 测试中, Rocket Lake 的整数、浮点性能分别是 Zen3 的 91%、106% 以及 Comet Lake 的 111% 和 106%。

英特尔上一代架构或者说Comet Lake 虽然有 10 个内核，但除了 638.imagick_s （图像处理，浮点密集型）和 657.xz_s（文件压缩，整数密集型）外，看不出多出两个内核的优势。

SPEC CPU 2017——默认频率

默认频率是指 BIOS 内重置为出厂优化设置，**作系统将 CPU 电源管理设置为性能模式，此时 Rocket Lake 的 iTVB/iAB 加速管理将会被启用，Linux 在单实例测试中会优选其中两个工况良好的内核跑 5.3GHz。

从测试结果来看，在默认频率下 Core i9 11900K 的单实例整数、浮点性能分别是 Ryzen 7 5800X 的 99%、106% 以及 Core i9 10900K 的 116% 和 123%。

在多线程或者说 speed 测试中, Core i9 11900K 的整数、浮点性能分别是 Ryzen 7 5800X 的 98%、110% 以及 Core i9 10900K 的 115% 和 114%。

默频下 10900K 额外的两个内核完全看不到任何优势。

测试总结

从性能角度来看的话，Rocket Lake 的确较上一代 Comet Lake 有不少的性能提升，例如单线程浮点性能提升幅度接近 23%、整数 16%，两个值平均起来的话（19.5%）和英特尔说的提升了 19% 非常接近。

Rocket Lake 引入了 AVX-512，英特尔显然做了不少优化，从而让处理器可以在重载型 AVX-512 指令全核运行时依然保持非常高的速度（4.8 GHz），AVX-512 现在已经成为值得一试的指令扩展。

当然，Rocket Lake 的最大缺点是依然采用 14 纳米制程，这导致它的耗电和发热远远高于同期竞争对手 Zen 3，强烈建议用户需要配置水冷（水冷厂商在偷笑了）。

和 AMD 的 Zen 3 相比，Rocket Lake 还是比较称职的，至少性能上是很接近了，还有核显，AMD Ryzen 桌面消费者版本目前是欠缺核显的，在目前的显卡市场状况下，我相信 K 系列的十一代处理器销量很可能会维持在较高的水平，当然，你要是乐意花钱买片**显卡做亮机卡也是合情合理的。

最后，我想说的是很高兴听到英特尔将会重回 Tick-Tock 战略，挤牙膏同义词的 PAO 至少在一段时间里会被取消，英特尔今年下半年将会推出的下一代或者说第十二代架构 Alder Lake 应该非常值得期待，要知道这个玩意不仅是要和 AMD 竞争，而且还担当起了抗击苹果 Apple Silicon 的重任。

联想z500进入bios设置按哪个键()和联想z500进入bios设置按哪个键()的问题分享结束啦，以上的文章解决了您的问题吗？欢迎您下次再来哦！