OC
Dell 一项测试比 MacBook 更省电:x86 追上 ARM 了吗
科技 · 2026-08-09 · 芯片与硬件 · 阅读 16

Dell 一项测试比 MacBook 更省电:x86 追上 ARM 了吗

作者:林岚|OC 开发者生态编辑

作者 林岚 林岚

Hackaday 转述了 Jeff Geerling 对 Dell XPS 13 与 MacBook Neo 的测试:在其 HPL Linpack 工作负载中,Intel Core 5 320 的 Dell 达到 6.21 Gflops/W,搭载 A18 Pro 的 MacBook Neo 为 5.38 Gflops/W。

一句话结论:这组数字说明一台低价 x86 笔记本可以在特定满载计算中达到很好的整机能效,但它不能证明 x86 指令集已经普遍超过 ARM,更不能代表 Dell 在所有续航、性能和散热场景都赢了 MacBook。

测试里的 Dell 输出 127.91 Gflops、整机功耗 20.6W;MacBook Neo 输出 57.012 Gflops、功耗 10.6W。用性能除以功耗,Dell 得到 6.21 Gflops/W,约高出 15%。在闲置与网页浏览场景中,两台机器的能耗也接近。

这确实值得关注。Intel 多年来在移动能效上承受 Apple Silicon 和 ARM 阵营压力,而 Core 5 320 所在的低价设备,已经不再必然以高耗电换取可接受性能。芯片制程、封装、核心设计、内存、固件和操作系统电源管理共同进步后,x86 笔记本可以进入过去很难做到的功耗区间。

能效结果被拆成芯片负载整机功耗散热与软件路径

为什么不能把结果归因于指令集

首先,两台机器不是只更换 CPU 架构的控制实验。Dell 和 MacBook 的芯片、内存、屏幕、散热、操作系统、编译器和数学库都不同。HPL 测试的是高密度浮点线性代数,结果会显著受向量指令、库优化、线程调度和内存带宽影响。

其次,MacBook Neo 使用的是原本面向手机体系的 A18 Pro,不是 MacBook Air 和 Pro 上的 M 系列芯片。拿这次结果外推成“Intel 超过 Apple Silicon”,会把 Apple 的不同产品级别混在一起。Geerling 的其他历史数据中,M4 Mac mini 在同类指标里仍达到 7.57 Gflops/W。

第三,能效不是只有一个数。Dell 在这项任务上用了约两倍功耗,也完成了超过两倍的计算;对插电科学计算,这可能是好结果。对电池设备,屏幕、视频解码、待机、无线网络、短突发任务和风扇策略同样决定实际续航。持续满载效率与“一天少充一次电”并不等价。

测试还显示 Mac 在集成显卡、音响和系统整洁度上占优,Dell 则更容易安装 Linux,并提供背光键盘。换句话说,这是一台具体产品开始变得有竞争力,而不是一条 CPU 架构定律被单项基准推翻。

应该怎样读这组数字

最合理的结论是,指令集不是移动能效的唯一决定因素。x86 的可变长指令和兼容负担会影响设计,但最终用户拿到的是完整 SoC 与整机。一个设计良好的 x86 芯片可以比一个定位更低或工作负载不占优的 ARM 芯片更高效,反过来也成立。

真正有价值的变化,是 Windows/Linux 阵营的轻薄本不再只能在性能、价格和续航中明显牺牲一项。若后续独立测试在视频会议、编译、浏览与待机中重复出现接近结果,才说明竞争格局发生了更广泛改变。

关键事实

  • HPL 测试中 Dell XPS 13 为 127.91 Gflops、20.6W,即 6.21 Gflops/W
  • MacBook Neo 为 57.012 Gflops、10.6W,即 5.38 Gflops/W
  • 两台机器采用不同芯片、系统和整机设计,结果不是单纯的 x86 与 ARM 对照实验
  • MacBook Neo 使用 A18 Pro,而不是性能与散热预算更高的 M 系列 Mac 芯片

OC 判断

Intel 值得为这台 Dell 的结果得到肯定,但标题最多应写“在一项测试中追上”,不能写“x86 证明比 ARM 高效”。当架构、芯片和整机被混成一个标签时,基准测试就很容易从数据变成阵营口号。

为什么重要

  • 对开发者:选择开发机时,应查看编译、容器、GPU 与目标语言的真实工作负载,而不是只看架构。
  • 对消费者:持续计算能效不能替代完整电池续航、噪音和温度测试。
  • 对芯片行业:ARM 的优势正在迫使 x86 厂商改善整个移动平台,而竞争已经反映到低价产品。

参考来源

相关阅读

基于标题、摘要和正文内容自动匹配。

更多科技

评论

围绕这篇文章补充信息、提出问题或分享观察。

0
暂无评论。

发表评论

继续看看 OC 用户围绕这个话题说了什么、做了什么。

相关帖子

更多

测试OurCoders能否发布照片

<p>今天小区的彩虹🌈<img src="https://share.icloud.com/photos/0ebtFydNy8r_gJETON61u4Ybg" alt="图片说明" /></p> <p>看来不能直接发照片,可以把iCloud Link的功能派上用场!</p>

梁建溢 15 45

做 AI 语音产品时,授权、撤回和审计日志应该怎么落地?

<p>最近看到越来越多关于声音授权的讨论。对开发者来说,真正麻烦的往往不是“模型能不能模仿”,而是授权如何进入系统、生成结果如何追溯,以及授权撤回后该怎么办。</p> <p>我们在做 FlowSpeech 时也碰到过类似问题。我的体会是,不要把“用户勾选过同意”当成一个布尔字段,而应该把它做成一组可以审计的业务对象。</p> <h2>1. 把声音资产和授权分开</h2> <p>声音文件只描述技术属性,例如哈希、上传者、存储位置和创建时间。授权记录则至少要包含授权主体、用途范围、地域、有效期、来源证据和当前状态。这样同一份声音用于个人试听、商业广告、公开播客时,可以绑定不同的授权,而不是共用一个模糊的 consent=true。</p> <h2>2. 每次生成都保存授权快照</h2> <p>生成任务不要只引用当前授权 ID。授权内容以后可能变更,如果任务只查最新状态,历史结果就无法解释。更稳妥的做法是在任务创建时保存授权版本、文本哈希、声音版本、模型版本和操作者。生成出的音频再记录 artifact_id,并反向关联任务。</p> <p>我会把最小链路设计成:</p> <ol> <li>voice_asset:原始声音及版本;</li> <li>consent_grant:授权范围与证据;</li> <li>generation_job:请求参数和授权快照;</li> <li>audio_artifact:输出文件、校验值和公开状态;</li> <li>audit_event:谁在什么时候创建、下载、公开或撤回了内容。</li> </ol> <h2>3. 撤回不是简单删除一行</h2> <p>授权撤回后,系统至少要阻止新任务,并把相关公开音频进入下架队列。已经交付给客户的文件是否能删除,要按照合同和产品能力区分,不能在界面上承诺技术上做不到的“全球删除”。更现实的状态机是 active、suspended、revoked、expired,并明确每个状态允许哪些动作。</p> <h2>4. 对外展示也要可验证</h2> <p>除了后台日志,公开音频最好带上来源标记或可查询的生成记录。水印不是万能方案,但“可识别的音频 + 可验证的元数据 + 清晰的举报入口”组合起来,比一句“AI 生成”更有用。</p> <p>我们现在做的 <a href="https://flowspeech.io/zh">FlowSpeech</a> 主要解决上下文感知、情绪和停顿控制。越往产品化走,越觉得声音效果只是前半程,权限边界和可追溯性才决定这类工具能不能长期使用。</p> <p>大家在实际项目里会把授权证据放在业务数据库、对象存储,还是单独的审计系统?如果授权撤回,你们通常怎么处理已经生成并交付的音频?</p>

FlowSpeech 0 1

你在用 Codex 的什么套餐,我是100美金的,已经想升级了

<p>你们呢?</p> <p>我最近主要是做了很多 Blender mcp 的事情,感觉效果很好,当然同时也很耗费 Token</p>

tinyfool 4 160

重返OurCoders

<p>从2014年以来好久没逛过这个谈论了,不知道这个谈论的运营现在怎么样,开发人员是不是原来的人,前端UI做得不太好</p>

梁建溢 5 36