December 31, 2024

高通骁龙X笔记本销量首次公布

根据市调机构Canalys的最新数据,截止2024年第三季度末,高通骁龙X系列笔记本迄今累计销量约为72万台,在全球PC市场上的份额仅为0.8%。

换言之,每卖出125台笔记本,才只有1台是骁龙的。

骁龙X系列笔记本从今年6月份起开始全面上市,第三季度销量环比大涨180%,也只是因为第二季度的起点基数太低了。

另外,第三季度AI PC的出货量为1330万台,占整个PC市场的20%。

事实上,高通虽然一再宣传骁龙X Elite的性能有多强悍,完胜Intel的酷睿Ultra 200V系列、AMD的锐龙AI 300系列,但对现实情况也心知肚明,制定的目标也非常理性:

预计到2029年,高通PC芯片业务收入40亿美元,希望能拿下非x86 AI笔记本市场30-50%的份额。

毕竟,x86市场可不是那么容易攻破的,高通必须首先好好解决兼容性太差、价格太高的尴尬。

值得一提的是,根据洛图科技(RUNTO)最新发布的报告,笔记本电脑屏幕的刷新率正在经历飞速的提升。

报告中指出,165Hz的刷新率已经超越了传统的60Hz,成为整体线上市场中最为主流的刷新率指标。

具体来说,在2024年的第三季度,拥有165Hz刷新率的笔记本电脑市场份额达到了29%,而60Hz刷新率的笔记本市场份额则降至24%。

回顾一年前的数据,我们可以看到一个截然不同的市场格局。当时,165Hz刷新率的笔记本市场份额仅为23%,而60Hz刷新率的份额则高达29%。

除了165Hz和60Hz之外,其他刷新率的市场份额相对稳定。

其中,90Hz刷新率的笔记本占比为8%,120Hz刷新率的占比为20%,144Hz刷新率的占比为10%,而240Hz及以上的高刷新率屏幕占比则为9%。

这些数据表明,虽然高刷新率屏幕的普及速度加快,但市场上仍然存在多样化的需求和选择。

December 30, 2024

Intel最新性能核Lion Cove微架构设计

导言

相比较AMD,Intel的微架构资料相对较少,软件优化手册也没看出太多东西,以前对Intel的微架构关注不多,所以也不清楚其进步性。尽管有分析说,Intel的本代桌面端升级并不明显,但出于对技术的研究,亦安还是收集一些资料分享。

概述

今年Intel发布的微架构叫Lunar Lake,其P核(性能核)代号是Lion Cove,本文主要关注Lion Cove。相比较前代的微架构,本代改变很大,至少从技术上讲是的,可能出于AI的原因,这几年各家CPU的微架构变化都很大。

和前代相比,Lion的发射宽度和Decode升级到8,这也是当前各家旗舰CPU的主流参数。预测器的L0 BTB由前代的128entry升级到256entry,覆盖的指令范围变得更大,但是L1和L2的BTB并没有作容量上的升级,对于方向预测器亦安没有找到相关的资料。

Micro-Op Cache由4096entry升级到5250entry,相比较AMD的Zen5的6K略低。有意思的是,对于DCache在传统的L1和L2之间插入了一级192KB的Cache,这是一个很有趣的设计,本文将48KB的Cache称为L0,192KB的Cache称为L1。L2的Cache由前代的2MB的大小升级为最高3MB,目前主流的旗舰CPU是2MB大小。

MMU

对于MMU的考量,Zen5和Lion的设计可以说天差地别,Lion的L1 TLB是Load和Store分开的,而Zen5是全相联的,这点设计我觉得没什么奇怪的,只要能接受延迟面积的因素,L1 TLB怎么设计都有道理。但同样是X86架构,AMD的L2 TLB是2048entry+1024entry+4096entry,而intel则是1024entry+1024entry,常规的聚合类的技术大家都是有的,但参数上居然有如此巨大的差距?AMD的巨大容量可以理解为它采用了非常激进的预取来掩盖页面翻译的延迟,但从intel的L1设计看,LS常用的页面应该是4KB和2MB,AMD给1G的页面单独给出了1024entry巨大的TLB还是挺奇怪的,只能理解为Zen5想压缩L2的延迟以及它可能测试了大量的未来可能需要的AI应用?不管怎么说,intel的MMU设计还是属于当前各家的主流设计范围内的,细节虽然不清楚,但MMU也不会太出花活。

DCache

从公开的资料看,此处的改变属于比较大的(执行单元和BPU没看到更多资料),在L0和L2之间插入了一个大小为192KB的L1 Cache(原本前代的L1 Cache对应本代的L0 Cache,只是个名字,也可以称为L1.5)。这种设计似乎脱离了各个厂商的主流设计L1/L2/L3,这就涉及到那个经典的问题“为什么Cache需要分级?应该分多少级呢?分级是怎么确定的?”。目前主流的厂商的CPU L2容量是2MB,而Lion的L2容量“最高到3MB”,我们知道Cache容量越大延迟越高,就设计水平以及使用的工艺都差不多的情况下,Intel应该很难使用3MB的L2的情况下将延迟压到和其它厂商一致,所以这个所谓L1(192KB)的Cache应该是了掩盖L2大容量带来的延迟而作的设计平衡。当然增加带宽也是可能的原因。

分支预测器

从Spec2K17分支预测的测试结果看,Lion和前一代相比没有太多进步,甚至有的方面有退步,而相比较Zen5综合似乎稍微弱一点,因为没有看到比较多的预测器参考资料,不好评价,但2taken/cycle这些都是有的,至于具体的算法没有找到资料。使用3级的BTB,资源大小似乎和前代没有变化,预测方向的算法不清楚,按照行业的主流设计应该还是Tage,不清楚具体的微架构设计与前代相比变化多少。

取指和解码

ICache是16路的64KB大小,取指带宽是128Byte/Cycle,Mop-Cache的带宽是12条指令,容量从4096增加到5250。decode是当前典型大核具有的8宽度,并且每个解码槽都可以为单线程提供服务。

Linux SWAP交换分区详解教程

引言

在早期,由于计算机内存资源有限,SWAP(交换空间)在Linux系统中扮演着至关重要的角色。SWAP允许系统将内存中不常用的数据移动到磁盘上,从而为正在运行的程序释放内存空间。尽管现代计算机通常拥有较大的内存,SWAP在服务器和工作站等长时间运行的系统中仍然非常重要。本文将详细介绍如何在Linux系统中创建和管理SWAP交换分区。

什么是SWAP交换空间

SWAP空间是硬盘上的一部分空间,被用作虚拟内存。当系统的物理内存(RAM)不足以容纳当前所有程序时,系统会将部分内存数据移动到SWAP空间,以便为其他程序腾出空间。虽然使用SWAP会降低系统性能,因为它涉及到磁盘I/O操作,但在内存不足的情况下,SWAP是必不可少的。

创建SWAP交换分区

方法一:使用实体分区创建SWAP

分区:使用gdisk工具在磁盘上创建一个新的分区,并设置其类型为Linux swap。 [root@vxbus ~]# gdisk /dev/vda Command (? for help): n Partition number (6-128, default 6): First sector (34-83886046, default = 69220352) or {+-}size{KMGTP}: Last sector (69220352-83886046, default = 83886046) or {+-}size{KMGTP}: +512M Hex code or GUID (L to show codes, Enter = 8300): 8200 Changed type of partition to 'Linux swap' 格式化:使用mkswap命令格式化新分区为SWAP格式。 [root@vxbus ~]# mkswap /dev/vda6 Setting up swapspace version 1, size = 524284 KiB no label, UUID=6b17e4ab-9bf9-43d6-88a0-73ab47855f9d 启用:使用swapon命令启用SWAP分区。 [root@vxbus ~]# swapon /dev/vda6 观察:使用free和swapon -s命令查看内存和SWAP的使用情况。 [root@vxbus ~]# free [root@vxbus ~]# swapon -s 持久化配置:将SWAP分区添加到/etc/fstab文件中,以便在系统启动时自动挂载。 [root@vxbus ~]# nano /etc/fstab UUID="6b17e4ab-9bf9-43d6-88a0-73ab47855f9d" none swap sw 0 0

方法二:使用文件创建SWAP

创建文件:使用dd命令创建一个SWAP文件。 [root@vxbus ~]# dd if=/dev/zero of=/tmp/swap bs=1M count=128 格式化:使用mkswap命令将文件格式化为SWAP格式。 [root@vxbus ~]# mkswap /tmp/swap 启用:使用swapon命令启用SWAP文件。 [root@vxbus ~]# swapon /tmp/swap 持久化配置:将SWAP文件添加到/etc/fstab文件中。 [root@vxbus ~]# nano /etc/fstab /tmp/swap none swap sw 0 0 启用所有配置的SWAP:使用swapon -a命令启用所有在/etc/fstab中配置的SWAP。 [root@vxbus ~]# swapon -a

结论

虽然现代计算机的内存容量已经很大,SWAP交换空间在某些情况下仍然是必需的。通过本文的教程,你可以学会如何在Linux系统中创建和管理SWAP交换分区,以确保系统在内存不足时能够正常运行。

英伟达最新 GB300 & B300 细节曝光

在 GB200 和 B200 发布仅 6 个月后,英伟达又推出了一款全新的 GPU,名为 GB300 和 B300。这次看似常规升级的背后,实则暗藏玄机。

B300 GPU 是基于台积电 4纳米工艺节点的全新流片,对计算芯片进行了优化设计。相比于B200,其性能的提升主要在以下两个方面:

  • 算力:FLOPS性能提升50%;功耗增加200W(GB300和B300 HGX的TDP分别达到1.4KW和1.2KW,前代则为1.2KW和1KW);架构改进和系统级增强,例如CPU和GPU之间的动态功率分配(power sloshing)。
  • 内存:HBM容量增加50%,从192GB提升至288GB;堆叠方案从8层HBM3E升级为12层;针脚速率保持不变,带宽仍为8TB/s。

为推理模型而生

内存的改进对于 OpenAI O3 这类大模型的训练和推理至关重要,因为随着序列长度的增加,KVCache也在增长,这限制了关键批处理大小和延迟。下图展示了英伟达当前几代 GPU 在处理 1k 输入令牌和 19k 输出令牌时的效能提升情况,这与OpenAI的o1和o3模型中的思维链(CoT)模式相似。

从 H100 到 H200,增加了更多、更快的内存:

  • 由于内存带宽的增加(H200为4.8TB/s,H100为3.35TB/s),在所有可比较的批处理大小下,交互性普遍提高了 43%。
  • 由于 H200 可以运行更大的批处理大小,每秒生成的令牌数是H100的3倍,从而使成本降低了约3倍。这一差异主要是由于KV缓存限制了总批处理大小。

更大的内存容量带来的好处是显著的:

  • 推理模型的请求和响应等待时间过长会带来糟糕的用户体验。如果可以提供更快的推理时间,将增加用户使用和付费的倾向。
  • 3 倍的成本差异是巨大的。
  • 最强大和最具差异化的模型可以比能力稍差的模型收取更高的费用。前沿模型的毛利率超过 70%,而在面临开源竞争的落后模型上,毛利率低于 20%。

当然,英伟达并不是唯一一家能够增加内存容量的公司。ASIC 也可以做到这一点,事实上,AMD 可能处于有利地位,因为他们的内存容量比英伟达更高,比如MI300X 的内存容量为 192GB,MI325X 的内存容量为 256GB,MI350X 的内存容量为 288GB……不过,黄仁勋手上还握有NVLink 这一利器。

当我们转向采用 GB200 NVL72 和 GB300 NVL72 的英伟达系统时,其性能和成本效益得到显著提升。NVL72在推理应用中的核心价值在于,它能够实现72个GPU以超低延迟协同作业,并共享内存资源。这也是全球唯一一款集全连接交换(all-to-all switched connectivity)与全规约运算(all reduce)能力于一身的加速器系统。

英伟达的 GB200 NVL72 和 GB300 NVL72 对实现许多关键功能至关重要:

  • 更高的交互性使得每个思维链的延迟更低。
  • 72 个 GPU 分散 KVCache,以实现更长的思维链,提高智能。
  • 与典型的 8 GPU 服务器相比,批处理扩展性更好,降低了成本。
  • 可以对同一问题进行更多样本搜索,以提高准确性和模型性能。

采用NVL72带来的经济效益提升了10倍以上,这一优势在长推理链的应用场景中尤为显著。此外,NVL72还是目前市场上唯一能够在大批量处理下,将推理长度扩展到10万以上令牌的解决方案。

为 GB300 重构供应链

对于 GB200,英伟达提供配备齐全的 Bianca 主板,该主板集成了Blackwell GPU、Grace CPU、512GB LPDDR5X内存以及集成在同一PCB上的电压调节模块VRM。此外,还配套提供了交换机托盘和铜质背板。然而,随着GB300的发布,供应链结构及产品配置作出了重大调整。

对于 GB300,英伟达不再提供完整的 Bianca 主板,而是提供搭载在“SXM Puck”模块上的 B300、BGA 封装的 Grace CPU ,以及由美国初创企业Axiado提供的基板管理控制器(HMC)。

最终客户将需要直接采购计算板上的其他组件,而第二级内存将从焊接式LPDDR5X改为可更换的LPCAMM模块,美光将成为这些模块的主要供应商。至于交换机托盘和铜质背板则保持不变,继续由英伟达提供。

转向 SXM Puck 为更多 OEM 和 ODM 厂商参与计算托盘制造打开了大门,以前只有纬创和富士康工业互联网(FII)能够制造 Bianca 计算板。这一转变对纬创在ODM领域的业务造成了显著影响,导致其Bianca主板的市场份额大幅下降。相比之下,富士康工业互联网通过独家生产SXM Puck及其插座,成功弥补了Bianca主板业务上的损失。英伟达目前正在积极寻找Puck和插座的其他供应商,但目前尚未有确定的新订单落地。

另一个重大转变是在电压调节模块(VRM)方面。虽然 SXM Puck 上仍保留一些 VRM 组件,但大部分板载 VRM 还是由超大规模制造商/OEM 直接从 VRM 供应商处采购。

英伟达在 GB300 平台上配备了 800G ConnectX-8 NIC,在 InfiniBand 和以太网上提供两倍的scale out带宽。由于上市时间复杂性以及决定不在Bianca主板上启用PCIe Gen 6技术,英伟达前段时间取消了 GB200 的 ConnectX-8。

相较于上一代ConnectX-7,ConnectX-8具有多项显著优势,除了双倍带宽外,它还拥有 48 个 PCIe 通道(而非 32 个 PCIe 通道),从而支持空冷MGX B300A等创新性架构设计。此外,ConnectX-8 还支持 SpectrumX,而在之前的 400G 产品中,SpectrumX 需要借助效率较低的Bluefield 3 DPU。

GB300 对超大规模云服务商的影响

受GB200和GB300发布延迟的影响,大量订单转向了英伟达价格更高的新一代GPU。近期,所有超大规模云服务商均已决定采用GB300。这一决定的部分原因在于GB300提供了更高的FLOPS算力和更大的显存容量,但同样重要的是,客户能够享有更多的系统定制自主权。

由于上市时间紧迫以及机架、冷却和供电密度方面的重大变化,超大规模云服务商无法在服务器层面对 GB200 做太多改动。因此,Meta不得不放弃从博通和英伟达多源采购网卡的希望,转而完全依赖英伟达。同样,谷歌也放弃了自家网卡,转而采用英伟达的产品。

对于拥有数千人团队、习惯于在CPU、网络直至螺丝和钣金等各个环节都严格优化成本的超大规模云服务商而言,这一情况着实难以接受。

最典型的例子是亚马逊,由于其选择了次优配置,导致总拥有成本(TCO)超出了参考设计的预期。具体来说,亚马逊采用了PCIe交换机和效率较低的、需要风冷散热的200G Elastic Fabric Adaptor NIC,这使得它无法像Meta、谷歌、微软、甲骨文、xAI和Coreweave等公司那样部署NVL72机架。由于亚马逊的内部网卡方案,它不得不采用NVL36,由于背板和交换机组件的增加,使得每个GPU的成本更高。总的来说,受限于定制化的不足,亚马逊的配置方案未能达到最优状态。

GB300为超大规模云服务商提供了定制主板、冷却系统等能力。这一灵活性使得亚马逊能够打造构建自己的定制主板,将原先采用风冷的组件(例如Astera Labs PCIe交换机)集成到水冷系统中。随着越来越多的组件转向水冷设计,加之预计在2025年第三季度K2V6 400G网卡将实现大规模量产,亚马逊有望重新采用NVL72架构,并显著提升其TCO效率。

然而,超大规模云服务商面临着一个重大挑战,即需要进行大量的设计、验证和确认工作。这无疑是他们有史以来所设计的最为复杂的平台之一(谷歌的TPU系统除外)。SemiAnalysis观察到,由于设计进度相对滞后,微软可能是最晚部署GB300的企业之一,他们在第四季度仍在采购GB200。

December 29, 2024

AI芯片新战役:ASIC登场,GPU失色

谈及AI芯片,公众首先映入脑海的往往是GPU的身影。

GPU在训练和运行大AI模型方面一直占据主导地位,其强大的并行处理能力让它在处理复杂计算任务时游刃有余。

然而由于一些原因,炙手可热的GPU正在面临一些挑战与局限性,使其 “AI宠儿” 的地位逐渐受到动摇。

风口上的GPU

关于GPU市场格局变动的原因,可归结为以下三大要素:

第一点,GPU已成为AI芯片领域竞争的核心焦点。目前,英伟达所产出的GPU主要被各大科技巨头所垄断。

近日,LessWrong网站上发表了一篇博客,根据公开数据对英伟达芯片的产量、各个AI巨头的GPU/TPU数量进行了估计。

其中微软目前拥有75万至90万块H100 GPU,预计到2025年这一数字将飙升至250万至310万块。谷歌的表现同样强势,现阶段掌握了100万至150万块H100,明年预计增加到350万至420万块。Meta拥有55万至65万块GPU,预计未来一年将增长至190万至250万块。此外,亚马逊当前拥有25万至40万块GPU,预计将在2025年达到130万至160万块。而新兴公司xAI也在迅速崛起,预计从10万块H100增长至55万至100万块。

这些数据充分反映出大型企业对AI算力的争夺已趋于白热化,尤其是微软和谷歌。

此外,Melius Research的分析师Ben Reitzes的报告显示,这些巨头正在特别购买英伟达的GB200芯片,其中微软下单量在70万至140万块之间,谷歌为40万块,亚马逊则购买了36万块,OpenAI也不甘示弱,至少拥有40万块GB200芯片。

科技巨头包揽英伟达GPU的同时,直接导致了中小型企业在获取GPU资源上面临严峻挑战。

第二点,GPU价格的飙升使得这些科技巨头在采购芯片时需要支付更高的成本。

据投行Raymond James的分析师估计,H100售价为2.5万至3万美元。 就算是价格、订购数量都按照区间的低端进行计算,微软也需要花费超过180亿美元用于购买GPU。

微软、亚马逊、谷歌等科技巨头正在全球范围内加速布局AI算力,以维持其市场竞争力。据报道,这些公司在AI相关项目和数据中心上的投资已超过400亿美元,并预计未来十年的支出将达到1万亿美元。

在众多花钱的项目中,购买GPU便是各家的当务之急。

日前,埃隆·马斯克的人工智能初创公司xAI已经向英伟达成功下单,订购了价值10.8亿美元的GB200 AI芯片,并凭借这笔巨额交易获得了优先交付的权利。

高昂的售价让科技巨头们压力倍增,叫苦不迭。

第三点,从另一角度来看,即便科技巨头暂且将成本因素置于次要地位,英伟达本身的供应不足状况仍使这些科技巨头忧心不已。

目前,英伟达的GPU垄断了约80%的AI半导体,制造在台积电进行。在后续的流程中,会利用CoWoS进行封装,但是CoWoS的产量目前是一个瓶颈。

另外,在CoWoS中,GPU周围放置了多个HBM(高带宽内存),这些HBM是堆叠的DRAM,也被认为是瓶颈之一。

在产能不足、巨头哄抢、售价高昂的背景下,大大小小众多企业开始积极探寻英伟达 GPU 的替代品,试图破解AI芯片市场的一家独大的现状。

AMD首席执行官苏姿丰(Lisa Su)也在前不久表示,随着行业将精力集中于更加标准化的模型设计,将有机会构建更多在可编程性和灵活性方面要求不那么高的定制芯片。这种芯片将更加节能、体积更小、成本更低。

“目前,GPU是大语言模型的首选架构,因为GPU在并行处理方面非常高效,但在可编程性方面有所欠缺,”苏姿丰说。“五年多后它还会是首选架构吗?我认为情况会发生变化。”

苏姿丰预计,五年或七年时间内GPU还不会失势,但会出现GPU以外的新势力。

那么,除了GPU,还有哪些类型的芯片能够胜任AI计算的任务呢?

AI芯片的另外两种主流选择

在近两年的技术浪潮中,另外两种芯片——FPGA与ASIC,也逐渐走进了大众的视野。

FPGA(Field Programmable Gate Array,现场可编程门阵列),是一种半定制芯片。用户可以根据自身的需求进行重复编程。FPGA 的优点是既解决了定制电路的不足,又克服了原有可编程器件门电路数有限的缺点,对芯片硬件层可以灵活编译,功耗小于 CPU、GPU;缺点是硬件编程语言较难,开发门槛较高,芯片成本、价格较高。FPGA 比 GPU、CPU 更快是因为其具有定制化的结构。

ASIC(Application Specific Integrated Circuit特定用途集成电路)根据产品的需求进行特定设计和制造的集成电路,其定制程度相比于 GPU 和 FPGA 更高。ASIC 算力水平一般高于GPU、FPGA,但初始投入大,专业性强缩减了其通用性,算法一旦改变,计算能力会大幅下降,需要重新定制。

从成本角度看,GPU、FPGA、ASIC 三种硬件从左到右,从软件到硬件,通用性逐渐降低、越专用,可定制化逐渐提高,相应的设计、开发成本逐渐提高,但是单位成本理论性能越高。

从运算速度来看,由于GPU架构固定,硬件原生支持的指令也固定。而FPGA和ASIC则是可编程的,因此,GPU的运算速度要逊色于FPGA和ASIC。

从功耗和时延角度来看,GPU的功耗远远大于FPGA和ASIC。GPU时延也高于FPGA、ASIC。 FPGA与ASIC的适用场景也不尽相同,就边缘AI而言,FPGA确实展现出了更高的适用性;ASIC的主要优势在于其针对特定任务的高度优化,这通常会导致更高的性能和更低的功耗(在大量生产时),也正因此,在AI计算应用中,业内对于ASIC的呼声似乎要略高于FPGA。

多家机构,看好ASIC

12月,博通的定制ASIC和英伟达GPU引起广泛讨论。

摩根士丹利12月15日发布研报《AI ASIC 2.0:潜在赢家》,认为ASIC凭借针对性优化和成本优势,有望逐步从英伟达GPU手中争取更多市场份额。

随着生成式AI应用的迅猛发展,全球AI计算需求呈现爆炸式增长。报告预计,到2027年,云端AI半导体市场规模将达到2380亿美元,而在乐观情境下甚至可能达到4050亿美元。

摩根士丹利预计,AI ASIC市场规模将从2024年的120亿美元增长至2027年的300亿美元,年复合增长率达到34%。

尽管英伟达的AI GPU性能卓越,但摩根士丹利认为,云服务提供商如谷歌、亚马逊和微软,仍在积极推动ASIC设计。这背后的驱动力主要有两个。

首先,是优化内部工作负载。通过开发自定义芯片,CSP可以更高效地满足其内部AI推理和训练需求。

其次,是更好的性价比。报告指出,虽然英伟达的GPU具备强大的计算性能,但其硬件价格高昂,特别是在AI训练过程中。相比之下,ASIC的单位成本更低,尤其是在大规模使用后。

巴克莱的另一份报告则预计,AI推理计算需求将快速提升,预计其将占通用人工智能总计算需求的70%以上,推理计算的需求甚至可以超过训练计算需求,达到后者的4.5倍。英伟达GPU目前在推理市场中市占率约80%,但随着大型科技公司定制化ASIC芯片不断涌现,这一比例有望在2028年下降至50%左右。

国际龙头,各自布局

博通,是AI市场的“新任宠儿”

截至12月13日收盘,美股又一家万亿美元市值芯片公司诞生。当天博通股价大涨超过24%,市值首次突破1万亿美元大关,也成为继英伟达和台积电之后,全球第三家市值过万亿美元的半导体行业公司。

博通股价大涨是在公司公布了好于预期财报之后。博通全年业绩显示,2024财年,全年营收达516亿美元,同比增长44%,其中AI和VMware两大业务板块成为核心增长引擎。

ASIC定制服务是博通半导体业务的一项重要收入来源,特别是在AI的驱动之下,博通来自与AI相关的ASIC定制服务营收正快速增长。

博通CEO陈福阳在近日的财报电话会上预测称,目前的三大科技客户将在2027财年花费600亿至900亿美元购买博通供应的人工智能组件。

业界分析,博通ASIC芯片的大客户包括谷歌、Meta;近期市场消息显示,苹果也有计划开发AI服务器芯片,合作方很有可能也是博通。

不仅如此,从美国目前对中国的禁售条款来看,ASIC芯片似乎始终被排除在外,博通也因此持续受益。

随着博通为云计算厂商定制更多AI芯片,这些厂商可能减少对英伟达芯片的依赖,有市场投资者担心英伟达未来的芯片需求可能有所缓解。

Marvell受到追捧

与博通业务模型类似的Marvell也在近日受到资本市场追捧。

12月初,Marvell已经发布了2025财年第三财季财报,期内公司实现营业收入15.16亿美元,同比增长7%、环比增长19%。其中数据中心相关收入同比增长98%、环比增长25%,这是公司旗下所有业务中唯一实现同比收入增长的业务类型。

Marvell总裁兼CEO Matt Murphy指出,这主要来自于AI定制化芯片需求支撑,此外还有云服务客户对于互联产品的持续性需求。预计这种趋势将延续到2026财年(约指2025公历年份)。

仅在12月,Marvell先是官宣与亚马逊云(AWS)扩大战略合作,宣布一项为期五年、跨代际产品的合作计划,涵盖Marvell旗下定制AI芯片、DSP、数据中心互联光模块、以太网交换机解决方案等多种类型,以支持AWS推进在数据中心计算、网络和存储等方面强化产品能力。不久还宣布推出业界首款3nm高速(1.6Tbps)互联平台。

博通和Marvell有类似的产业定位,并不聚焦于GPU这类通用的大规模并行计算芯片设计研发,而是更专注于帮助有芯片定制化需求的主流云服务厂商进行产品设计。这也是ASIC芯片相关业绩高速成长的原因。

谷歌,自研TPU

Google 早在 2013 年就秘密研发专注 AI机器学习算法芯片,并用于云计算数据中心,取代英伟达 GPU。

这款TPU自研芯片2016年公开,为深度学习模型执行大规模矩阵运算,如自然语言处理、计算机视觉和推荐系统模型。Google 其实在 2020 年的资料中心便建构 AI 芯片 TPU v4,直到 2023 年 4 月才首次公开细节。

值得注意的是TPU是一种定制化的 ASIC 芯片,它由谷歌从头设计,并专门用于机器学习工作负载。

2023年12月6日,谷歌官宣了全新的多模态大模型Gemini,并丢出了另一个重磅炸弹——全新的自研芯片TPU v5p,它也是迄今为止功能最强大的TPU。

随后在今年5月,谷歌又宣布了第六代数据中心 AI 芯片 Tensor 处理器单元--Trillium。

据悉,除了英伟达所占据的80%市场,其余20%的绝大部分由各种版本的谷歌TPU所控制。谷歌自身不出售芯片,而是通过其云计算平台租用访问权限。

微软:推出基于Arm架构的通用型芯片Cobalt、ASIC芯片Maia 100

2023年11月,微软在Ignite技术大会上发布了首款自家研发的AI芯片Azure Maia 100,以及应用于云端软件服务的芯片Azure Cobalt。两款芯片将由台积电代工,采用5nm制程技术。

Cobalt是基于Arm架构的通用型芯片,具有128个核心,Maia 100是一款专为 Azure 云服务和 AI 工作负载设计的 ASIC 芯片,用于云端训练和推理的,晶体管数量达到1050亿个。这两款芯片将导入微软Azure数据中心,支持OpenAI、Copilot等服务。

负责Azure芯片部门的副总裁Rani Borkar表示,微软已开始用Bing和Office AI产品测试Maia 100芯片,微软主要AI合作伙伴、ChatGPT开发商OpenAI,也在进行测试中。

不过,微软并不认为自己的 AI 芯片可以广泛替代英伟达的产品。有分析认为,微软的这一努力如果成功的话,也有可能帮助它在未来与英伟达的谈判中更具优势。

除了前述几家公司,Meta等科技行业领导者正积极加快自主研发芯片的步伐。这些努力不仅限于ASIC领域,还包括FPGA和RISC-V等多个方向,旨在降低对英伟达技术的依赖。

在科技行业中,不单单是这些头部企业有所动作。摩根士丹利在相关报告里对全球 ASIC 供应链展开了梳理,并且确定了六大潜在的优势方:

ASIC供应商方面,除了博通,Alchip(世芯电子)和Socionext也被视为ASIC市场的潜力股。其中,Alchip由于与AWS的深度合作,预计将在2026年显著提升市场份额。

电子设计自动化工具方面,Cadence有望实现结构性增长。

代工厂方面,台积电及其供应链伙伴将从ASIC设计与制造的快速增长中受益。

测试服务方面,Advantest是AI芯片测试领域的领先者,其在AI设备测试方面的专注将为其带来显著增长。

HBM方面,三星电子是非英伟达HBM市场份额领先者,将从ASIC需求增长中获益。

苹果,屡试“新果”

今年7月,苹果公司发布iPhone AI的首个预览版,随后发布论文,称其人工智能模型是在谷歌的TPU(张量处理单元)上训练的。论文中介绍了为支持Apple Intelligence功能而开发的基础语言模型,包括一个设计用于在设备上高效运行的约30亿参数模型和一个基于私有云计算的云侧大模型。

近日,苹果公司在亚马逊的AWS Reinvent大会上又高调宣布将使用亚马逊自家定制的AI芯片进行模型训练。根据苹果机器学习与人工智能高级总监Benoit Dupin的说法,苹果正在评估亚马逊最新的Trainium2芯片,尤其是其在预训练“苹果智能”(Apple Intelligence)模型方面的潜力。

这一迹象表明,在训练尖端人工智能方面,大型科技公司正在探索除英伟达GPU以外的其他替代方案。

长久以来,人工智能训练主要依赖于价格高昂的英伟达图形处理器。然而,云服务提供商与初创企业正积极研发成本更低的替代方案,并探索可能实现更高效处理的新途径。苹果采用定制芯片的做法,或许在向其他企业传递一个信号:非英伟达的训练方案同样也能奏效。

December 28, 2024

Serial Studio:多功能串口数据可视化工具

Serial Studio是一款基于Qt的多功能数据可视化工具。Serial Studio提供了一个灵活的解决方案,可适应各种用例,使其成为教育和专业环境的理想选择。

强大的跨平台兼容性

Serial Studio支持Windows、macOS和Linux三大主流操作系统,这意味着无论你使用哪种操作系统,都可以轻松地使用该工具。这避免了由于操作系统差异而导致的兼容性问题,极大地提高了开发效率和便利性。

灵活的数据源支持

该工具并非局限于单一数据源,而是支持多种数据采集方式,包括串口(硬件和软件串口)、MQTT、蓝牙低功耗(BLE)以及网络套接字(TCP/UDP)。这种广泛的兼容性使得Serial Studio能够连接各种嵌入式设备、传感器和网络服务,满足不同用户的需求。 例如,你可以轻松地将它连接到你的Arduino、ESP32、Raspberry Pi或其他任何具有串口、网络或BLE通信能力的设备。

自定义的可视化和帧分析

Serial Studio的核心优势在于其强大的自定义能力。用户可以使用各种小部件来定义和显示数据,并通过项目编辑器进行配置,以满足特定的需求。这使得你可以根据自己的项目需求,灵活地调整数据显示方式,例如图表、表格、仪表盘等。更重要的是,它允许用户修改JavaScript函数来解释传入的数据帧,这对于处理复杂的二进制格式或预处理原始传感器数据至关重要。这使得Serial Studio能够适应各种数据格式和协议,极大地扩展了其应用范围。

便捷的数据导出与MQTT集成

Serial Studio允许用户轻松地将接收到的数据保存为CSV文件,方便后续的分析和处理。 此外,它还集成了MQTT协议,可以进行MQTT数据的发布和接收。这意味着你可以通过互联网实时地监控和可视化来自世界各地的设备数据。这在远程监控、物联网应用等场景中具有显著的优势。

丰富的文档和示例

为了方便用户快速上手和深入学习,Serial Studio提供了丰富的文档和示例。其Wiki页面包含安装说明、快速入门指南、高级主题(包括数据流、帧解析和自定义仪表板构建)以及代码示例和项目解释,帮助用户循序渐进地掌握Serial Studio的使用方法。

易于编译和部署

Serial Studio基于Qt框架开发,只需安装Qt(最好安装所有插件和模块)即可编译。对于GNU/Linux系统,还需要安装libgl1-mesa-dev。 编译过程相对简单,通过CMakeLists.txt文件即可完成,即使对于没有经验的用户来说也相对容易上手。

总结

Serial Studio是一个功能强大且易于使用的串口数据可视化工具,它具有跨平台兼容性、灵活的数据源支持、自定义的可视化和帧分析能力以及便捷的数据导出和MQTT集成等诸多优势。 丰富的文档和示例进一步降低了学习和使用的门槛。无论你是经验丰富的嵌入式工程师,还是初学者,Serial Studio都能帮助你高效地进行数据采集、可视化和分析,显著提升你的工作效率。

December 27, 2024

BIOS 工程师日常工作是做什么的

2024年就业形势很不好,BIOS行业也陷入了低谷。尽管如此,BIOS工程师作为一个门槛相对比较高的职业,还是有不少人试图进入。于是,他们第一个问题就是“BIOS工程师日常工作是做什么的?”,作为一个BIOS资深业内人士,我最近经常被问到这个问题。今天统一回答一下,希望能给希望入行的读者描绘一副这个行业的总览图景,如果也能帮助即将踏入社会的准毕业生,那将是我的荣幸了。

总的来说,BIOS工程师是芯片产业中非常重要的角色,涉及的领域和职责从芯片原厂、独立BIOS供应商(IBV),到整机厂商都各不相同。为了更好地了解BIOS工程师的具体工作内容,我们可以从芯片产业的上游、中游和下游三个层次来分别探讨。这将有助于我们全面了解BIOS工程师在整个产业链中的作用。

上游:芯片原厂的BIOS工程师

在芯片产业的上游,如Intel、AMD等芯片原厂,主要是负责芯片设计和研发的公司。BIOS工程师在这里的工作,通常与芯片硬件的启动和基本功能的支持紧密相关。具体来说,他们需要确保新设计的芯片在硬件层面能够正常启动,各个设计功能能够正确初始化并运作正常,与操作系统顺利交互。此时,BIOS作为硬件与软件之间的桥梁,承担了关键的任务。

Intel开始测试第三代显卡架构Xe3

Battlemage Xe2架构的二代锐炫独立显卡还没发布,Intel已经开始加紧测试第三代了,也就是Celestial Xe3,依然是核显、独显两条路同时推进。

当然,核显的优先级更高,酷睿Ultra 200V就率先用上了低功耗版本的Xe2-LPG,而明年的Panther Lake,也就是酷睿Ultra 300的低功耗版本,则应该会首先用Xe3-LPG。

SiSotware数据库里就已经出现了Panther Lake的身影,检测显示有32个GPU CU单元,换算下来应该对应4个Xe3核心。

同时可以看到这颗处理器的功耗为25W,可能是U版本,也可能是H版本,而频率只有1.6GHz,工程样品都高不到哪里去。

Panther Lake处理器将首发采用Intel 18A制造工艺,今年8月的时候官宣已经点亮。

另外,Intel的一位架构师透露,Xe3系列有一个新的架构变种Xe3p,但未透露更多细节。

这里的p可能代表Plus,比如说一代就有过Xe-LPG+,明年的Arrow Lake-H系列笔记本就会用。

从目前看,Intel独立显卡至少至少也会做三代,大家倒是不必担心,至于更遥远的未来,无论哪家都只能走着瞧了。

酷睿Ultra 300系列还很远,Intel将在明年初发布酷睿Ultra 200S系列的主流版本,包括65W、35W,覆盖酷睿Ultra 9/7/5/3全系列,现在零售商又偷跑了。

来自加拿大的PC-Canada,在官网上列出了酷睿Ultra 9 285、酷睿Ultra 7 265/265F、酷睿Ultra 5 225/225F,确认了它们的存在。

当然,价格就不用看了,比K系列还要贵,显然是占位符。

根据之前爆料,65W型号其实还有酷睿Ultra 5 245/235,以及入门级的酷睿Ultra 3 215/205,但后两款的规格仍未确认。

35W型号主供OEM,已知只有两款,分别为酷睿Ultra 9 285T、酷睿Ultra 7 265T。

看到没?酷睿Ultra 9系列这次没有F无核显版。

一文看懂Infinity Fabric

自 Zen 以来,AMD 芯片一直使用多级互连来创建模块化系统,让 AMD 能够快速且廉价地实现高核心数。多个 Zen 核心在一个集群中共享一个 L3 缓存,称为核心复合体 (CCX)。CCX 通过 AMD 的 Infinity Fabric 访问系统的其余部分,这是一种灵活的互连,可让 AMD 根据需要调整系统拓扑。

自 Zen 2 以来,这意味着将 CPU 核心放在核心复合体芯片 (CCD) 上。CCD 连接到单独的 IO 芯片,该芯片与系统内存和较慢的组件(如 PCIe、SATA 和 USB)通信。这创建了一个中心辐射模型,让 AMD 的核心数量高于英特尔。

CCD 使用 Infinity Fabric On-Package (IFOP) 接口连接到 IO 芯片。在 Infinity Fabric 时钟 (FCLK) 下,CCD 的 IFOP 链路每周期提供 32 字节的读取带宽和每周期 16 字节的写入带宽。FCLK 通常远低于 L3 和核心时钟。在具有更快 DDR5 的较新 Zen 系统中,一个 IFOP 可能没有足够的带宽来饱和 DDR5 带宽。超过该潜在带宽限制后,DDR 内存无法提供足够的带宽来处理高核心数系统中所有核心的需求。

当然,也可能存在其他争用点。在 Zen 2 上,多个 CCX-es 可以争用一个 IFOP 接口。在这里,我将研究在多个点上推动带宽限制如何影响争用同一共享资源的延迟敏感线程。我不会在一个轴上显示延迟数据,在另一个轴上显示带宽数据,而是将延迟和带宽绘制为两个单独的系列,以显示延迟如何受到核心数量的影响。

Zen 4 是 AMD 现有的一代CPU ,由于它是我日常使用的台式机,因此是一个方便的测试平台。作为 Zen 系列的最新成员,它每个 CCD 都有一个八核 CCX。单个 Zen 4 核心可以以大约 50 GB/s 的速度从 3 GB 阵列读取数据,因此与之前的 Zen 一代相比,它可以消耗大量内存带宽。这应该会使任何瓶颈很容易被发现。我使用的是典型的 DDR5 配置,具有中等规格的 DDR5-5600。

在最小负载下,我的系统的 DRAM 延迟为 82-83 纳秒。延迟测试线程很快就会发现延迟更严重,因为其他核心的带宽需求开始填满整个内存子系统的队列。只需几个带宽测试线程就足以将 CCD 的内存子系统推到极限。

增加线程数会导致延迟飙升,可能是因为内核数量越多,队列容量的竞争就越激烈。当有五个带宽线程竞争时,延迟会超过 400 纳秒。

将带宽负载推向另一个 CCD 可显著改善延迟。当 CCD0 有一个核心需要带宽,而 CCD1 正在运行延迟测试时,我看到一个奇怪的延迟峰值。在 CCD0 上加载更多核心会奇怪地降低延迟,即使实现的带宽有所增加。我想知道 AMD 是否正在检测活动核心数,并开始保留队列条目,或者如果有足够多的核心需要高带宽,则以其他方式限制每个核心的带宽消耗。

带宽随延迟而提高。事实上,运行八个带宽测试线程的 CCD 可达到近 64 GB/s。当带宽测试线程不与延迟线程发生冲突时,AMD 似乎可以从 IFOP 接口获得出色的带宽效率。综合起来,这两个观察结果表明 AMD 的双 CCD 设置可以充当某种 QoS 机制。在一个 CCD 中包含带宽消耗大的代码可以让另一个 CCD 上的延迟敏感代码以最小的影响继续运行。

为了测试整个系统,我在添加带宽测试线程时切换了核心加载顺序,以便在 CCD 之间交替。这样我就可以使用两个 IFOP 链接,希望能够最大化内存带宽。当然,实现的带宽更高,并且使用几个带宽测试线程时,延迟仍然得到很好的控制。我还在每个 CCD 上运行一个带宽测试线程,实现了最大带宽。

但随着我生成更多带宽测试线程,情况迅速失控。我们可能正在考虑 CCD 和内存控制器级别的争用。这两个层的延迟似乎都是累加的,当延迟测试线程必须与 10 个以上的带宽消耗线程作斗争时,它的情况真的很糟糕。

此时,系统也开始出现异常。例如,打开任务管理器中的“详细信息”选项卡需要很长时间,尽管我的测试只为每个物理核心加载了一个线程。谢天谢地,我认为这是相当极端和非典型的工作负载。

硬件性能监控

从软件观察延迟很简单,但我可以通过询问硬件发生了什么来获取更多信息。Zen 4 的 L3 缓存具有性能监控功能。它的一项功能是随机采样 L3 未命中并跟踪其延迟。

虽然此性能监控事件与我的 C 和汇编代码一样提供了平均延迟的概念,但它们测量的并不完全相同。软件只能观察加载到使用延迟。这包括从核心内的地址生成到从内存层次结构中的某个位置获取数据的整个延迟。AMD 使用助记符“XiSampledLatency”来描述他们的事件。“Xi”是 Zen 的 L3 缓存复合体中的一个组件,可与系统的其余部分交互。很可能,它代表“外部接口”。它可能有一组队列来跟踪未完成的请求。采样延迟就像注意队列条目保持分配的时间一样简单。

由于此事件很可能在 Xi 中实现,因此它仅测量 L3 未命中后的延迟。从软件中看到的 DRAM 延迟将包括在许多其他层引入的延迟。这包括地址生成,以及在发现 L3 未命中之前检查每个缓存层。

因此,Xi 看到的延迟应该低于软件看到的延迟。不过,此事件对于查看内存子系统在 L3 未命中后的行为非常有用。Xi 的数据与我在全系统带宽测试开始时的软件观察结果大致相关,当时 CC1 运行延迟测试,而 CCD0 运行单个线程产生带宽负载。软件看到的延迟为 190 纳秒,而 CCD1 上的 L3 性能监控看到的延迟为 166 纳秒。

有趣的是,来自另一个 CCD 的性能监控数据表明 Zen 4 优先考虑了带宽消耗大的线程,而牺牲了对延迟敏感的线程。作为健全性检查,托管带宽测试线程的 CCD 的 L3 未命中带宽为 59 GB/s,几乎与我从软件中计算的结果完全一致。

一旦我生成更多带宽测试线程,性能监控数据表明平均延迟上升到 200 纳秒左右。但是,从延迟测试线程的软件观察结果来看,延迟超过了 700 纳秒。来自延迟测试线程的请求只占通过内存子系统的流量的一小部分,因此 Xi 看到的平均延迟不能反映我的测量结果,这是有道理的。

Zen 5 搭配快速 DDR5

Zen 5 是 AMD Zen 系列中最新、最出色的成员。它使用与 Zen 4 相同的 IO 芯片,但 CCD 有所变化。Cheese (George) 已将系统设置为非常快的 DDR5,并以稍高的时钟频率运行 Infinity Fabric 以启动。

我不会将此称为典型设置。DDR5-8000 套件价格昂贵。AMD 的评论指南建议将 6000 MT/s 作为最佳点。然而,这种配置可以让我们了解 Infinity Fabric 在大量内存带宽可用的情况下的性能。在单个 CCD 中,我不应该接近 DRAM 带宽限制。事实上,当我推到 IFOP 的带宽限制时,延迟要好得多。在高负载下,延迟也开始降低,这可能是由于非常快的 DRAM 配置。

单个 CCX 内的争用仍会增加延迟,但程度不如 Zen 4。Zen 5 内核也会像其前代产品一样单独消耗大量带宽。也许 CCX 级别的变化起了作用。在 Hot Chips 2024 上,AMD 展示了一张幻灯片,其中暗示每个 Zen 5 CCX 都有一对 XI。这两个 XI 加在一起可能比 Zen 4 上有更多的队列条目,幻灯片也暗示了这一点。

这可能会降低带宽需求大的线程独占所有队列条目并导致延迟敏感的线程无法工作的可能性。此外,在此设置中,IFOP 带宽仅覆盖 DDR5 带宽的 55%,而我的 Zen 4 系统上则为 71.4%。内存控制器上的负载较低,使其有更多空间来管理 DRAM 效率低下的问题,例如总线周转、刷新或存储体冲突。我怀疑 Zen 5 的更好表现归结于这两个因素的结合。

与 Zen 4 一样,CCD 边界可以将延迟敏感线程与带宽消耗大的代码隔离开来。在这个 Zen 5 系统上,更快的内存和更快的 Infinity Fabric 时钟使一切整体上变得更好。更重要的是,在 Zen 4 上观察到的具有一个带宽线程的延迟峰值消失了。

在 Zen 4 上,这种峰值一定是由 Infinity Fabric 中的某些因素引起的。毕竟,如果延迟和带宽测试线程位于不同的 CCD 上,它们就无法争夺相同的 XI 或 IFOP。即使 Zen 5 使用相同的 IO 芯片,AMD 可能已经调整了其流量管理策略,以更公平地为具有不同内存访问模式的核心提供服务。

当我加载两个 CCD 时,Ryzen 9 9950X 及其快速内存设置继续令人印象深刻。即使内存带宽超过 100 GB/s,延迟仍然得到很好的控制。这些 DDR5-8000 内存条 48 GB 套件的价格似乎为 250 美元。花这么多钱,你最好能得到一流的性能。

再次,我怀疑 AMD 做了一些调整以改善负载下的延迟。Zen 4 的疯狂 700 纳秒测量值已经消失。我并没有将 Zen 4 推向接近 DDR5 带宽限制,但 Zen 4 的性能监控数据表明延迟不应该远远超过 200 纳秒。

Zen 2:每个 CCD/IFOP 有两个集群

Zen 2 可能有点过时,但它确实首次推出了 AMD 的现代芯片组设置。更有趣的是,每个 CCD 有两个四核 CCX。这让我可以分别查看 CCX 级和 CCD 级瓶颈。

与 Zen 4 和 Zen 5 不同,我运行的 Zen 2 具有匹配的 FCLK 和 DRAM 速度。因此,一个 CCD 的 IFOP 带宽与 DRAM 带宽相匹配。Zen 2 从单个 CCX 实现了约 84.4% 的理论 DRAM 带宽。这个百分比比 Zen 4(71.4%)或 Zen 5(55%)要大。当然,这两代产品都实现了更好的绝对带宽。

延迟从 71.7 纳秒开始,当三个占用大量带宽的线程共享同一个 CCX 时,延迟会增加到 142.77 纳秒。但是,在一个 CCX 上运行的延迟测试线程与另一个 CCX 上的带宽负载相当隔离,即使两个 CCX 都位于同一个 CCD 上。这让我认为 CCX 的 XI 可能比下游的 IFOP 链路更成瓶颈。

在 CCD 内对两个 CCX 产生带宽需求会导致延迟增加。这并不奇怪,因为现在 CCX 的 XI 和 IFOP 都存在争用。不过,Zen 2 的表现还不错。285 纳秒的延迟并不好,但比 Zen 4 的单个 CCD 的 400 纳秒要好。在可比的 CCD 级争用测试中,Zen 5 比两者都好,约为 151 纳秒。

我认为 Zen 2 比 Zen 4 表现更好,因为 Zen 2 内核单独无法消耗那么多带宽。DRAM 延迟很高,这意味着您需要排队大量正在运行的请求才能维持高 DRAM 带宽。Zen 2 内核只能维持足够的正在运行的请求以实现 24-25 GB/s 的 DRAM 带宽。这远远低于 Infinity Fabric 或 DRAM 带宽限制,因此延迟测试线程很有可能为其自己的请求找到空闲的队列条目。

就像 Zen 4 和 Zen 5 一样,Zen 2 也可以从 CCD 级隔离中受益。与 Zen 5 一样,Zen 2 在单个带宽密集型线程中不会出现延迟峰值。但是,我怀疑这里是否有任何复杂的流量管理。同样,单个线程无法承受足够多的 L3 未命中来垄断下游队列。

退一步来说,Zen 2 的 DDR4 控制器在高负载下调度内存请求方面做得非常出色。尽管 Ryzen 9 3950X 被推得更接近其带宽极限,但它仍能够控制延迟。在 CCD1 的带宽中,从 CCD0 场景测试的延迟,3950X 保持的延迟比 7950X3D 更好。

加载两个 CCD 确实会增加延迟,但这比通过一个 CCD 的 IFOP 占用所有 DRAM 带宽要好。即使一个 IFOP 接口的带宽足以使 DDR4 控制器饱和,但同时使用两个 IFOP 接口可以提供更好的延迟。这可能是因为我此时只推动 DDR4 带宽限制,而不是同时推动 DDR4 和单个 IFOP 达到极限。

这些观察结果表明 CCX 内的争用是最成问题的,尽管 IFOP 接口上的争用也会稍微增加延迟。

Zen 2 还具有一对 XI 性能监控事件,用于跟踪平均 L3 未命中延迟。但是,Zen 2 以周期为单位进行更直接的测量,而不是随机采样请求。PPR 告诉您将延迟事件除以请求数以获得周期延迟。基本上,它告诉您解决Little 定律。反向工作,延迟事件随着 XI 每个周期的队列占用率而增加。

单独查看队列占用率数字会发现平均队列占用率约为 59-61,非常接近 64。遗憾的是,AMD 的 L3 性能计数器不支持计数掩码,但平均数字可能意味着每个 CCX 的 XI 都有 64 个队列条目。如果是这样,两个 CCX 加起来将有 128 个 XI 队列条目。

在 Hot Chips 33 上,AMD 展示了一张幻灯片,其中展示了 Zen 3 合并的八核 CCX 的 XI 有 192 个队列条目。

使用 Zen 5,AMD 可能每个 CCX 有 320 个 XI 队列条目,CCD 的两个 XI 块中每个块可能有 160 个条目。

不幸的是,我没有找到有关 Zen 4 的 XI 队列容量的任何信息。也许 Zen 4 增加了队列条目的数量,但还不足以适应 Zen 4 在内存级并行能力方面的大幅提升。

L2 和 L3 都获得了更大的未命中队列,以支持更多未完成的请求。

Kai Troester 在 AMD 2023 年 Hot Chips 演讲中介绍 Zen 4。

如果是这样,那就可以解释我在 Zen 4 上看到的一些奇怪的行为。队列条目当然不是免费的,更大的队列既需要占用空间又需要耗电。如果用户很少遇到这些限制,AMD 可以在 Zen 4 上做出合理的权衡。AMD 可能评估了许多程序并决定做出合理的权衡。我没有时间或资源去做全职员工能做的事情,但我可以举几个例子。

实践中的延迟和带宽

在这里,我以 1080P 运行 Cyberpunk 2077 的内置基准测试。我将游戏固定在不同的 CCD 上,运行了两次基准测试,这应该会使性能监控数据更容易解释。在非 VCache CCD 上,游戏看到 10-15 GB/s 的 L3 未命中流量。在 1 秒间隔内,带宽并不多,但带宽使用率在该采样间隔内可能不恒定。带宽需求的短暂峰值可能会被整个内存子系统中的队列平滑,但较长的峰值(仍然在纳秒级)可能会填满这些队列并增加访问延迟。其中一些可能发生在 Cyberpunk 2077 中,因为性能监控数据表明 L3 未命中延迟通常高于 90 纳秒。

将 Cyberpunk 2077 固定到 VCache 芯片上可显著减少 L3 未命中流量,这显示了拥有三倍 L3 容量的价值。L3 未命中的服务延迟也更低。在整个内存子系统中,更少的内存流量可减少排队延迟。因此,VCache 具有降低平均 DRAM 延迟的次要优势。这是一个强大的组合,并且反映在基准测试的输出中。Cyberpunk 2077 的基准测试在固定到非 VCache 芯片时平均为 122.34 FPS,在固定到 VCache 芯片时平均为 153.98 FPS。尽管时钟频率较低,但 VCache 芯片的性能提高了 25.8%。

退一步说,这两种情况都不会让游戏在内存子系统的任何位置突破带宽限制。两种情况下的延迟都得到了很好的控制,基准延迟对性能的影响比接近带宽限制导致的延迟更大。

GHPC 是一款坦克游戏,是另一个例子。模式类似,但带宽需求较低。VCache 再次通过在芯片上处理更多内存请求来显示其价值。同样,减少 L3 之后的内存子系统的负载可以降低平均 L3 未命中延迟。

博德之门 3 是一款角色扮演类游戏,玩家可以掷骰子和投掷物品。带宽需求每秒变化很大,但采样内存延迟仍然得到很好的控制。我们并没有接近 200 纳秒,这表明存在带宽瓶颈。

同样,Zen 4 的内存子系统没有承受太大压力。VCache 继续表现出色,将 L3 命中率从 31.65% 提高到 79.46%。但即使没有 VCache,也有足够的备用 Infinity Fabric 和 DDR5 带宽可供使用。

RawTherapee 是一款免费的开源原始文件转换程序。发烧友相机可以记录原始的 12 位或 14 位传感器数据,而不是经过处理的 JPEG。原始文件为摄影师提供了更多的编辑空间来调整曝光和白平衡。它们还允许编辑者在保留细节和降低噪点之间做出有意识的权衡。然而,图像处理可能需要大量计算。在这里,我将几个 45.7 兆像素的 D850 原始文件转换为 JPEG,并应用了曝光和降噪。

我没有将 RawTherapee 固定在 CCD 上,因为图像处理是一项并行任务,得益于高核心数(与大多数游戏不同)。相反,我同时为两个 CCD 记录数据。RawTherapee 的带宽需求非常大 - 足以填满队列,但通常不足以运行超过 1 秒的采样间隔。

这时,采样延迟数据就提供了有价值的见解。延迟峰值超过 200 纳秒,表明内存子系统已达到极限。

不过,并非所有多线程程序都会给内存子系统带来压力。我在后台运行视频编码作业的同时玩了《博德之门 3》。L3 未命中流量很大,但并不严重。延迟仍然在控制范围内,游戏大部分时间保持 60 FPS。

视频编码可能需要大量带宽,但 Ryzen 9 7950X3D 的 L3 缓存包含足够的带宽,可以避免 XI、Infinity Fabric 或 DRAM 控制器级别的争用。在某些采样间隔内,核外流量超过 85 GB/s,因此假设没有 L3 缓存的 Zen 4 设置将严重受到 DRAM 和 Infinity Fabric 瓶颈的影响。为了便于理解,以下是包含 L3 命中带宽的带宽图。

很久以前,AMD 的 Llano 或 Excavator 等芯片只有 1 MB 的 L2 缓存,没有 L3。大型 L3 缓存占用大量芯片面积并增加了复杂性,所以我理解为什么 AMD 在某些产品上省略了它。但我只能想象,即使是快速的 DDR5 设置,如果被一个假设的台式机芯片推动,也会有多么困难,该芯片有 16 个内核,每个内核有 1 MB 的 L2,没有 L3。内核和内存之间的任何互连也会负载很重。当然,这样的设置不存在是有原因的。

最后的话

AMD 成功的 Zen 系列基于具有多个互连级别的可扩展系统架构。但设计可扩展架构并不容易。一个级别的多个块可能必须通过下一个级别的瓶颈。如果许多核心要求尽可能多地使用带宽,队列可能会开始填满并导致延迟。这有可能产生“吵闹邻居”问题,即延迟敏感的代码会受到系统其他地方运行的带宽密集型代码的惩罚。

内存子系统级别的延迟是附加的。一个请求因等待 XI 队列条目而延迟了十几个周期,在争夺 IFOP 周期时,它将晚到几十个周期。IFOP 的任何额外延迟都意味着请求稍后会经过各种 Infinity Fabric 组件,依此类推。Zen 4 似乎受到复合延迟的影响最为严重,可能是因为 AMD 让单个内核消耗的带宽比以前多得多。但正如性能计数器和对 Zen 2 的观察所显示的那样,AMD 的 Infinity Fabric 和内存控制器在负载下保持合理延迟方面做得很好。CCX 级争用似乎导致了我看到的最严重的加载延迟峰值。

在大多数情况下,这些限制在典型的客户端应用程序中并不常见。游戏可能对延迟很敏感,但我测试的游戏不会产生足够的带宽需求来给内存子系统的某些部分带来压力。即使是线程良好的生产力工作负载也可能不会突破带宽限制,因为 AMD 的大型 L3 缓存可以包含大量内存访问。有些工作负载,如 RawTherapee,既难以缓存又线程良好。我不建议在游戏或其他延迟敏感程序的同时运行这样的工作负载。尽管如此,Zen 5 表明 AMD 正在关注确保延迟敏感任务的良好基准性能水平,即使在内存子系统非常繁忙的情况下也是如此。

VxWorks